Jérémie Gimenez

D'accord, il s'agit bien alors de ce que j'avais en tant qu'historique, pour le client dont je parlais. Effectivement, une vue d'ensemble de tout ce qu'on a fait avec une entreprise client n'est pas toujours présente ; du coup, quand on la crée, on voit ressurgir pas mal de soucis des années précédentes. La question est alors, par exemple : "je corrige le statut d'une facture (qui était restée en «attente règlement» depuis 2013, par erreur) et je veux que cette correction se fasse simultanément dans la facture ET dans la ligne RECAP correspondante". Ma pratique est la suivante : - dans la table Recap, j'ai une rubrique a_statut, de type texte avec auto-entrée SANS l'option "ne pas remplacer valeur existante" - dont la formule est : Si ( zkk_1 = 1 ; Cas ( id_facture ; recap_facture::statut ; id_devis ; recap_devis::statut ; id_appel ; recap_appel::statut ; id_contrat ; recap_contrat::statut ) ) Là-dedans, le SI zkk_1 = 1 permet de déclencher facilement une mise à jour. Ensuite, à chaque fois que je modifie un enregistrement source, je fais un Définir rubrique zkk_1 = 1 pour rafraîchir l'ensemble des rubriques a_ de l'enregistrement Recap lié. NB : les rubriques ainsi reportées ne doivent pas être légion non plus. Dans ce genre de situation, a_date, a_numero, a_libelle, a_statut devraient suffire. Ensuite, les rubriques "notes", "à surveiller", "à rappeler le xx/xx", "OK RàS", etc. peuvent suffire à entretenir une table d'historique efficace. Et bientôt, de faire du suivi en cherchant tous les clients possédant une ligne d'historique ayant la case "à surveiller"cochée, etc.

Siso, Quelles données doivent passer par quelles vérifications/corrections ? S'agit-il de "rafraîchir" nos enregistrements Historique ? De vérifier la validité des enregistrements sources (évènements et règlements) ? ou autre…

Bonjour Siso, Je propose une solution moins technologique, mais qui peut servir, selon l'utilisation de ta TE "mixte". Contexte : un ancien client voulait un historique de chacun de ses clients, dans une TE montrant pêle-mêle les échanges téléphoniques, les devis, les factures, les contrats, les règlements et les RDV d'intervention. ET, il voulait pouvoir ajouter des notes dans chacune de ces lignes d'historique, ainsi qu'une notion "incident", et une notion "à rappeler le xx/xx/xxxx". Dans cette situation, j'ai opté pour une table Historique contenant id_appel, id_devis, id_facture, id_contrat, etc. ainsi que d_notes, d_incident, d_date_rappel, pour les informations de suivi. Au niveau du schéma des relations, cela revient à la Previous situation du lien de Fabrice. Après, je rapatriais dans chaque ligne d'historique les infos clés des différentes tables concernées : a_date, a_numéro (numéro de devis, de facture, de contrat), juste le nécessaire mais de façon indexable. De cette façon, on n'a dans la TE que des rubriques mémorisées de la table Historique (ne surtout pas afficher via l'historique les enregistrements des différentes tables, sinon on retombe dans la lenteur). Cela impose d'entretenir l'enregistrement de Historique à chaque fois qu'on crée, modifie ou supprime un élément lié au client. Résultat final : un peu de travail de script tout au long de la vie des devis, factures, etc. ; mais aucun travail à faire au moment d'afficher l'historique du client et l'affichage est immédiat. Inconvénient évident : on multiplie les données, ce qui n'est pas orthodoxe. Exemple, la date d'un devis se trouve enregistrée et indexable à 2 endroits, l'enregistrement Devis et l'enregistrement Historique correspondant. En contre-partie, les notions de suivi, "notes", "incident survenu", "à rappeler le" sont centralisées dans la table Historique et non clairsemées dans les tables Devis, Facture, Contrat, etc. C'était juste une illustration, sans savoir si cela peut correspondre à ta situation… Bon début de semaine ! Jérémie

C'est un plaisir. Bonne journée ! 🙂

Voici la chose, telle que je la comprends : Handisport.fmp12

Salut @fabriceN, Si je comprends bien la logique des "pelotons", on doit obtenir le même temps même si on a >3 secondes par rapport au premier, du moment qu'on n'a pas >3 secondes par rapport au coureur juste devant nous. Dans la capture, issue de ton fichier, on devrait avoir 2:35:10 tout le long, et non pas un saut à :14 puis un autre à :18. @handisport, je dis pas une bêtise ?

Bonjour Andromar, Je vois 2 possibilités : - jouer sur le trait de contour : si le corps du modèle est gris, tu peux avoir le jeu de case à cocher de fond blanc, avec un contour blanc d'épaisseur 10, ça donne pas mal - aller trifouiller dans le CSS, mais c'est compliqué et, après vérification, FMP refuse de prendre en considération l'attribut padding à l'intérieur de la classe checkbox_set:normal .self { Bonne journée ! Jérémie

Bonjour Matessias, Bravo pour ce mot d'enthousiasme matinal ! Suggérons à Filemaker de faire la prochaine Devcon à Madagascar 😉 Bonne journée !

Bonjour Nicolas, Belle et fine observation ! Et surtout, très beau fichier de démonstration. J'avoue que je ne vois pas la logique dans ce comportement de Filemaker, puisqu'on voit les enregistrements liés. On devrait donc pouvoir les trouver en mode recherche. NB : comme je ne voyais pas apparaître le mot "marron" au debugger, j'ai ajouté un Valider enregistrement avant le Exécuter recherche. Ceci m'a permis de vérifier que le Définir rubrique par nom ne posait pas de souci. En outre, même en faisant la recherche manuellement, on constate le souci. J'ai déjà rencontré cette situation, où la recherche via une TE ne fonctionne pas, alors qu'on a le résultat sous les yeux en mode utilisation. Simplement, je n'ai pas eu ta patience (ni ta rigueur scientifique) et j'ai passé la rubrique cible par un booléen jamais vide (qui prend 0 si vide, par entrée automatique sans option "ne pas remplacer"). Du coup, je n'ai pas idée du vrai pourquoi du comment… Bonne journée, Jérémie

Bonjour, D'accord, merci pour ces infos. Je ne connais guère-du-tout le cyclisme. Du coup, effectivement, il te faut au moins les 2 variables décrites plus haut. Si tu veux noter "premier" et "dernier" à chaque début et fin de peloton, ça t'oblige à des petits jeux dans la boucle. A savoir : quand tu arrives sur le coureur x, que tu constates qu'il est à plus de 3 secondes du coureur x-1, tu peux lui attribuer "premier", revenir sur x-1, lui attribuer "dernier", puis revenir sur x et continuer la boucle. NB : tu avais dit "inférieur ou égal à 3 secondes", et là tu as indiqué "cassure supérieure ou égale à 3 secondes". Le "ou égal" ne peut être utilisé que dans un des 2 cas. Il faut éclaircir la question : à pile 3 secondes, est-ce qu'on est dans le peloton ou est-ce qu'on en inaugure un nouveau ? NB 2 : tu pourrais également renseigner pour chaque coureur une rubrique Peloton, dans laquelle tu mettrais "Peloton 1", "Peloton 2", etc. Cette rubrique te permettrait ensuite une jolie présentation en vue liste, avec une ligne de récapitulatif à chaque peloton Bonne journée, Jérémie

Bonjour handisport, J'avoue être un peu surpris par ce besoin, mais la solution est effectivement une boucle permettant de comparer chaque enregistrement au précédent. Cependant, j'ai 2 observations : - je te conseille vivement d'avoir une rubrique "temps corrigé" à part, et de ne pas agir sur "temps réel mesuré" (ton second message laisse penser que tu fais ainsi, donc c'est bon), - il faut élucider le cas que j'ai copié depuis ton message, qui semble paradoxal. En effet, si on compare le coureur 9 et le 6, on à 6 secondes d'écart, or dans ton résultat souhaité, tu leur donnes bien le même temps corrigé. Cela implique de jouer sur 2 variables : - la variable $t de Fabrice, qui conserve 02:50:02 jusqu'à la fin du groupe, - une variable $u qui prendrait la nouvelle valeur dans chaque enregistrement, et qui servirait pour la comparaison. Ainsi, quand on arrive au joueur 9, on comparerait son temps de 02:50:08 avec $u, qui contiendrait 02:50:06 ; et constatant que l'écart est inférieur à 3, on appliquerait le temps $t, lui-même n'ayant pas été modifié depuis le coureur 6 puisque aucun écart n'a dépassé 3 secondes depuis. C'est tout de même très particulier, et ça laisse envisager que si les 11 joueurs sont espacés de 3 secondes, ils reçoivent tous le même temps corrigé. Est-ce ce qu'on cherche ? Bonne journée, Jérémie

Bonjour Marc, Effectivement, la seconde fois, j'ai pu descendre le fichier Jeune.fmp12. L'architecture est déjà fort riche. A mon sens, les besoins que tu décris, les totaux de médailles, sont à gérer avec des rubriques statistiques, en vue liste. Exemple : si tu affiches une liste des résultats triés par pays, avec un sous-récapitulatif basé sur pays, tu pourras y mettre 3 rubriques statistiques Décompte de Med_gold, Décompte de Med_argent, etc. Bonne journée ! Jérémie

Bonjour Parou, En débutant Filemaker, il est important d'explorer les menus, notamment le menu Affichage. Vous découvrirez nombre de choses, y compris la réponse à votre question ET l'ensemble des raccourcis clavier disponibles. NB : inutile de préciser que le menu Enregistrements > Supprimer tous les enregistrements n'est pas forcément à tester ! 😅 Bonne journée et bonnes explorations de Filemaker, Jérémie

Bonjour Marc, Sans compte Dropbox (et je ne compte pas en créer un), je ne peut voir ton fichier. Peut-être pourrais-tu préciser la question ici… Bonne journée ! Jérémie

Bonjour Ben, Je pense en effet qu'il faut te baser sur la table des résultats. Et surtout, qu'un modèle de liste bien fait répondrait peut-être à tes besoins. J'entends par là une liste avec des sous-récapitulatifs (parti, scrutin) et des rubriques statistiques (total, moyenne). Bonne journée, Jérémie