Aller au contenu

gcroset

Membres
  • Compteur de contenus

    156
  • Inscription

  • Dernière visite

À propos de gcroset

  • Rang
    100
  • Date de naissance 25/03/1946

Profil général

  • Genre
    Homme
  • Lieu
    Lausanne
  • Intérêts
    Ballade

Profil FileMaker

  • FM Conférence
    Un jour j'irai !
  • FM
    FMP15A, FMP16A
  • OS
    OSX 10.13
  • Certification
    --Non certifié--
  1. Importer un PDF dans une rubrique Conteneur (Résolu)

    Hello Voilà, votre proposition fonctionne à merveille. Je vais pouvoir l'appliquer lorsque je crée des attestations ou rempli des formulaires inclus dans ma base. Merci encore pour votre aide. Avec mes cordiales salutations. Gaston
  2. Importer un PDF dans une rubrique Conteneur (Résolu)

    Grand merci, je vais tester tout ça demain, et ferai un retour de mon test. J'apprécie les découvertes. Avec mes meilleures salutations. Gaston
  3. Importer un PDF dans une rubrique Conteneur (Résolu)

    Merci pour la réponse, je viens d'essayer de modifier la variable $nomdocpdf en mettant ($chemin/$nomdoc), amis là il me donne le même message avec un "?" à la place du nom du document. J'ai essayé différente façon de définir cette variable, mais je plante lamentablement. Gaston
  4. Bonjour La question a déjà peut-être été traitée, mais je ne l'ai pas trouvée. Mon problème: j'ai une OT_courrier et une TA_document. Lorsque je créer une lettre, je voudrais qu'en plus de l'impression cela enregistre la lettre en PDF sur le bureau, puis j'ouvre la TA_document, je créé un nouvel enregistrement, j'active la rubrique Conteneur et j'insère le PDF. Mais voilà, lorsque le script doit importer le PDF, il me dit "le fichier xxxxxx.PDF est requis pour effectuer cette opération, mais introuvable. Dans le script en annexe, j'ai bien une variable pour le Chemin "$Chemin", une pour le nom "$nomdoc" du document et une "$nomdocpdf" qui intègre le Chemin et le nom pour lui indiquer ce qu'il doit aller chercher pour l'insertion. Il me créer bien l'enregistrement, mais n'insère pas le PDF. Je tourne en rond depuis un moment. Merci si une bonne âme peut me mettre sur la piste. Bonne journée. Avec mes meilleures salutations. Gaston script lettre.pdf
  5. Calcul automatique au lancement

    Bonsoir Gérard, Après un long silence, partagé entre réflexions, essais divers, et voyages, je reviens te donner des nouvelles. Je me trouvais en difficulté devant ta proposition de ExecuterSQL, je ne maîtrise ni l'anglais, ni ce genre d'instruction y relative. J'ai donc opté pour l'utilisation d'une TA intermédiaire, TA_calcul_pecule_journalier, traitée comme une application de facturation, comme tu me le proposais plus haut. Cela fonctionne, donc je suis satisfait. Merci encore pour tes réflexions. Belle fin de journée. Avec mes cordiales salutations. Gaston
  6. Calcul automatique au lancement

    Bonsoir Gérard Merci pour ton souci d'essayer de me proposer des solutions. Je vais devoir me pencher sur ExecuterSQL, notion que j'ai pas vu jusqu'à maintenant, mais en voilà l'occasion. Ces prochains jours je vais être absents, plus tourné vers des activités festives. Donc je reprendrais cela dès mon retour, fin de semaine prochaine. J'avais aussi pensé traiter ce problème comme pour une facture avec plusieurs lignes, facture que j'efface lorsque la personne part de la Communauté. Je te redirai alors où j'en suis. Merci encore et bonne soirée. Gaston
  7. Calcul automatique au lancement

    Bonjour Gérard Cette nuit une idée m'est venue, et si j'essayais de résoudre cela en créant une rubrique Date_décompte, qui serait la date de modification du tarif "Pecule_jour" et servirait de départ au nouveau décompte de jour une rubrique Jour_décompte, qui serait alimentée par le nb de jour avant la modification une rubrique Montant_pecule, qui serait alimentés par le montant du pécule avant le jour de modification du tarif "Pecule_jour" et gérer tout cela au travers d'un script sur modification de la rubrique Tarif, cela éviterait de créer une TA supplémentaire, non? Actuellement, j'ai une rubrique calcul "Nb_jours" dans la TA_séjour, et une rubrique nombre "Calcul_pecule" dans la TA_pecule. Un script qui part de la TA_contact et qui va sur la TA_pecule afficher les fiches du pécule du Contact, et calculer le nb de jour, et le montant du pécule. Voir copie écran déjà donnée. Je me dis que dans un script avec un déclencheur sur la rubrique Tarif, je devrais définir une variable Date_décompte, qui me prenne la date de modification, une variable Montant_pecule qui me prenne le résultat de Calcul_pecule avant la modification du Tarif une variable qui prenne le nb de jour avant la modification du tarif Ces variable servant à Définir les rubriques ci-dessus, et reprisent dans les différents calculs du nombre total de jour et du montant total du pécule. L'objet de tout cela est que chaque fois que je vais dans la fiche de pécule du Contact, j'aie à l'écran le montant global du pécule et nombre de jour, le jour de la consultation des fiches Pécule de ce Contact . Le changement de tarif n'est pas courant, il peut très bien ne pas varier durant plusieurs années. Mon exposé n'est peut-être pas très clair, mais il montre l'état de ma réflexion, qui devrait encore être creusé et mieux spécifié, mais je ne désespère pas. Je garde aussi l'idée de créer une fiche, mais cela suppose alors que je crée une TA_calcul, non? Bonne fin de journée Gaston
  8. Calcul automatique au lancement

    Bonjour Merci pour ta réponse. C'est une direction à laqelle je pensais effectivement, mais comme je ne veux pas, lorsque j'imprime le récapitulatif du pécule, ou un état chaque mois, me trouver avec 1 ligne par jour, soit 365 lignes pour l'année, j'imaginais créer une TA_calcul qui me créerait les lignes et me rapatrierait le total de l'état au jour X dans la TA_pécule. Mais là, comme le programme ne sera pas activé tous les jours, il faut qu'au travers d'un calcul, il identifie la dernière fois que le programme a été ouverte, et me crée, à l'ouverture du programme, autant de lignes que de jours où le programme n'a pas été activé, et c'est là que je me demande si je ne construis pas une "usine à gaz" Je me demandais s'il n'y avait pas une manière plus simple de résoudre mon souci. Je vais tout de même essayer avec une TA_calcul et voir ce que cela donne. Bonne journée. Gaston
  9. Calcul automatique au lancement

    Bonjour Pour un programme qui gère le pécule de personnes accueillies temporairement, dans une Communauté. Soit : - Une TA_parametre, qui me permet de définir certains paramètres identifiants la structure - Une TA_contact - Une TA_ séjours, qui gère la date d’arrivée, de départ, et le nb de jours de présence (Date_actuelle - date_arrivée+1). - uneTA_pecule, qui gère le pécule des personnes accueillies, pécule composé de plusieurs éléments, dont plus particulièrement d’un pécule journalier, calculé en rapport au nombre de jour passé dans la communauté. Jusque là pas de problème. Lorsque je vais dans la TA_pecule, il me calcule la somme du pécule journalier, (voir copie écran), donc mise à jour de la somme chaque fois que j’ouvre le programme. Si je décide de modifier le montant du pécule journalier, il me fait le calcul sur tous les jours de présences avec le nouveau tarif, et c’est ce que je ne veux pas. Il doit prendre en compte le nouveau tarif seulement depuis le moment où je le change. J’ai pensé créer une TA_calcul_pecule, qui me créerait, à l’ouverture du programme, pour chaque jour un enregistrement et me rapatrierait la somme dans ma TA_pecule, ce qui serait une manière de résoudre mon souci. Mais là, un autre problème, surgit, il faut que le programme soit activé chaque jour, alors qu’il ne sera utilisé que 2 ou 3 fois dans la semaine, voir moins. Je devrais alors avoir une "moulinette" qui identifie la date à laquelle le programme a été utilisé pour la dernière fois, et calculer le nombre de jours sans utilisation, de façon à me créer autant d’enregistrements dans la TA_calcul_pecule. Petite précision, je ne suis pas un professionnel de la programmation, et je pense que je me complique la vie et créant une « usine à gaz ». Les utilisateurs aimeraient que chaque fois qu’ils ouvrent le programme, le programme calcul automatiquement la somme du pécule à la date du jour de l’utilisation Je recherche donc une piste que me permette d’atteindre la solution à mon souci, passager je l’espère. Merci par avance. Gaston
  10. Bonjour Eric Voilà, j'ai adopté ta proposition, qui est plus simple que ce que j'avais fait. Cela m'a permis de découvrir une autre méthode de recherche, merci. Cela m'a permis de simplifier le script. Lorsqu'on est amateur, on a tendance à compliquer les choses. Du coup, j'ai reproduit le script pour une recherche sur les titres de séjours, et tout est bien dans le meilleur des monde. Bonne journée. Avec mes cordiales salutations. Gaston
  11. La nuit porte conseil Il suffisait de mettre la condition Si ( Not EstVide ( TA_compagnons::Validite_passeport )) au départ. Je l'avais déjà essayée, mais avec l'erreur de mettre si(Not EstVide ( TA_compagnons::Validite_passeport ); Mois_passeport=1)). Là je pense que tout est bon, selon les tests que je viens de faire. Je vois ton message après avoir fait mes essais. Merci, je vais aussi tester ta solution. Bonne journée. Avec mes cordiales salutations.
  12. Mais, autre souci: Tout marche, pour autant que j'aie eu une fiche qui me donne le mois courant pour les passeports. Comme je travaillais sur une copie, je mets les rubriques validité_passeport à zéro, donc pas de date pour celles en test, et là lorsque j'ouvre à nouveau ma base, il me produit 24 fiches de rappel, soit une par personne. Certaines avec des points d'interrogation pour la date de rappel, qui correspond aux personnes qui n'ont pas de dates de validité car nous n'avons pas d'éléments, et pour celles dont la rubrique validité est remplie, il me donne la date réelle de validité-délai. Je mets une date 3 mars 2017 sur une fiche, et là tout fonctionne. J'ai essayé dans le script, de définir la rubrique "Mois_recherche" sur 1 (premier mois de l'année) au départ ou Mois (Obtenir ( DateActuelle), car c'est celle utilisée dans la recherche, et cette rubrique est remise à jour lorsque j'ai défini par une variable le mois de recherche, mais là pas plus de résultats. Au départ de la base, je dois avoir au moins une fiche qui est dans le mois actuel, même si ce n'est pas la réalité. Après lorsque le mois passe au suivant, pas de souci, e ce que j'ai remarqué et changeant la date de mon ordinateur. Faut-il créer une fiche bidon?
  13. Voilà, tout est rentré dans l'ordre. Il s'agissait de bien mettre les lignes de scripts au bon endroit. Du coup, cela fonctionne pour les passeports et les titres de séjours. Merci Eric de m'avoir mis sur la piste. Bonne et belle journée Avec mes cordiales salutations. Gaston
  14. Je suis sur la bonne piste. J'ai créé une rubrique nombre "Mois_recherche", et dans le script, je définis la rubrique par la valeur de la variable $date2. Du coup le je change le paramètre de recherche de la date validité_passeport à Mois_recherche = $date2. Le problème que je dois encore résoudre, c'est que pour qu'il me prenne tout, je dois faire deux fois le script, pour les deux contacts, mais je ne désespère pas.
  15. Bonjour Eric A force de ramer, je vais attaquer la falaise 😅. Il est vrai que je n'ai pas une maîtrise de pro de FileMaker, mais je ne vais pas arrêter pour autant 😉 J'ai créé ma rubrique calcul, qui affiche bien 1. Dans mes conditions de recherche, j'ai ajouté la rubrique "Date_recherche_passeport = 1" Pas plus de résultat. Il y a quelques chose que je comprends pas et je ne le vois pas. Je joins des copies écran qui illustrent mon propos et remet le script. Je précise que ce script fait partie du script d'ouverture. Merci pour ton aide. Avec mes cordiales salutations. Document2.pdf Document1.pdf
×