Jump to content
  • 0

Deux conditions à remplir


Artcharo
 Share

Question

Bonjour,

Je suis nouveau avec FileMaker Pro

Dans une base de contact de membres, j'essaie d'indiquer les infos de renouvellement d'adhésion.
J'ai donc deux tables : Contacts et Renouvellement. 
Dans mon modèle de contact, j'ai intégré mes infos de renouvellements qui consistent en deux informations :
- Champ de date : date d'un renouvellement
- Case à cocher : Coché s'il s'agit d'une renouvellement payant.

J'essaie d'afficher dans un champ STATUT la mention "OK" ou "ÉCHU" selon deux conditions :
- Le membre doit avoir renouvelé dans les 365 derniers jours ET
- Le renouvellement doit être payant.

Donc, si la dernière ligne indique une date récente, mais que la case n'est pas cochée, le champ "STATUT" devrait indiquer "ÉCHU".

Sur la 1ere ligne, ça fonctionne, mais lorsque j'entre un second renouvellement, je n'arrive pas à conditionner sur le dernier enregistrement. ... donc si le renouvellement précédent (trop ancien) était payant, peu importe que le nouveau le soi ou pas, si la date du nouveau renouvellement est récente, il considère les deux conditions remplies. 

J'ai essayé avec DERNIERE(), mais j'ai cru comprendre que ça renvoyait le dernier non vide... 

Y a t il une solution à ce problème?

Voici le calcul que j'ai mis dans mon champ "STATUT"
Si (And((Obtenir(DateActuelle) - ObtenirDate(Derniere (Renouvellements::Renouvellement))) < 365;Derniere (Renouvellements::Type_renouv)="Avec cotisation"); "OK";"ÉCHU")

Merci beaucoup pour votre aide.

Link to comment
Share on other sites

9 answers to this question

Recommended Posts

  • 0

Bonjour,

Dans la table Renouvellement, il y aura un enregistrement par année (ou autre période) et cet enregistrement unique vaudra pour tous les membres ? Ou bien un enregistrement par membre et par période ?

Bonne journée,

Jérémie

Link to comment
Share on other sites

  • 0

Bonjour @Artcharo

Le plus simple pour récupérer le dernier renouvellement est de trier la relation par ordre décroissant de renouvellement (dans la définition de la relation du gestionnaire de base de données - ou au besoin créer une relation triée pour la cause). Ainsi depuis la fiche du membre, le premier enregistrement lié correspond au dernier renouvellement. Et la formule devient donc

Si ( ( obtenir (dateactuelle) - Renouvellement::Renouvellement ) < 365 AND Renouvellement::Type = "Avec cotisation" ; "OK" ; "ECHU" )

Attention ce calcul ne peut être mémorisé car il doit être réévalué chaque fois qu'on en a besoin vu que la date actuelle change chaque jour 😉

De ce fait, toutes recherches ou exploitations autres du statut seront ralenties.

Je conseillerais de travailler avec des déclencheurs qui à la création ou modification d'un renouvellement mettent à jour le statut de la fiche du membre.

La formule serait donc exploitée dans un pas de script afin d'écrire dans la rubrique de statut la bonne valeur.

 


bien à toi,

Tanguy

Link to comment
Share on other sites

  • 0

@Tanguy Colles Hmmm, il y a deux raisons pour lesquelles ce calcul ne peut être mémorisé :

  • celle que tu as dite : la date actuelle change tous les jours
  • celle pour laquelle du propose un contournement : la référence à un champ lié

Reste que la première sera toujours vraie. Donc à moins de modifier chaque jour la rubrique avec un script serveur par exemple (et donc dates de modifications modifiées…) il n'y a pas moyen.

Si c'est un problème, alors on peut contourner en stockant le statut dans une autre table, mais ça pose d'autres problèmes (affichage en liste…)

Selon le volume de données attendu, le calcul non mémorisé n'est pas forcément à proscrire.

Link to comment
Share on other sites

  • 0
Il y a 21 heures, Jérémie Gimenez a dit :

Bonjour,

Dans la table Renouvellement, il y aura un enregistrement par année (ou autre période) et cet enregistrement unique vaudra pour tous les membres ? Ou bien un enregistrement par membre et par période ?

Bonne journée,

Jérémie

Chaque membre renouvelle quand il veut... parfois 1x/an parfois moins souvent... quand il a besoin de services chez nous en fait... donc non, il n'y a pas de date unique de renouvellement pour tous. 

Link to comment
Share on other sites

  • 0
Il y a 3 heures, Artcharo a dit :

Chaque membre renouvelle quand il veut... parfois 1x/an parfois moins souvent...

Dans ce cas, pour ma part, je ferais :

  • dans la table Contact :
    • une rubrique date_derniere_adhesion
    • une rubrique reglement_recu "oui/non" (ou booléen)
    • une rubrique calculée "à jour de cotisation ? oui/non" (selon les 2 rubriques précédentes)
  • dans la table Adhésion :
    • un enregistrement pour chaque adhésion ou renouvellement
    • une rubrique date_recu (date actuelle par défaut)
    • une rubrique date_reglement_recu
  • un processus "renouvellement reçu" :
    • définir Contact::date_derniere_adhesion
    • remettre Contact::reglement_recu sur "non"
    • ajouter un enregistrement dans la table Adhésion
  • un processus "règlement reçu" :
    • remettre Contact::reglement_recu sur "oui"
    • compléter Adhésion::date_reglement_recu
    • NB : le bouton "règlement reçu" se trouverait dans la table externe Adhésion, uniquement si l'Adhésion n'a pas encore sa date reglement_recu

De cette façon, on voit facilement si le membre est à jour ou non. On n'est pas tributaire de la table Adhésion pour établir son état "à jour".

En parallèle, la surveillance des "adhésions non encaissées" se fait dans la table Adhésion. Cette table sert aussi d'historique du membre.

Link to comment
Share on other sites

  • 0
Le 28/01/2022 à 02:45, Jérémie Gimenez a dit :

Dans ce cas, pour ma part, je ferais :

  • dans la table Contact :
    • une rubrique date_derniere_adhesion
    • une rubrique reglement_recu "oui/non" (ou booléen)
    • une rubrique calculée "à jour de cotisation ? oui/non" (selon les 2 rubriques précédentes)
  • dans la table Adhésion :
    • un enregistrement pour chaque adhésion ou renouvellement
    • une rubrique date_recu (date actuelle par défaut)
    • une rubrique date_reglement_recu
  • un processus "renouvellement reçu" :
    • définir Contact::date_derniere_adhesion
    • remettre Contact::reglement_recu sur "non"
    • ajouter un enregistrement dans la table Adhésion
  • un processus "règlement reçu" :
    • remettre Contact::reglement_recu sur "oui"
    • compléter Adhésion::date_reglement_recu
    • NB : le bouton "règlement reçu" se trouverait dans la table externe Adhésion, uniquement si l'Adhésion n'a pas encore sa date reglement_recu

De cette façon, on voit facilement si le membre est à jour ou non. On n'est pas tributaire de la table Adhésion pour établir son état "à jour".

En parallèle, la surveillance des "adhésions non encaissées" se fait dans la table Adhésion. Cette table sert aussi d'historique du membre.

Merci beaucoup pour les réponses et les idées.
 

J'ai tenté une autre approche un peu moins "user friendly" qu'espéré mais bon.
Le membre peut renouveller soit gratuitement, soit en payant une cotisation. Le fait de renouveler avec cotisation lui donne accès à des services différents que s'il renouvelle gratuitement. L'objectif est pour moi d'afficher sur la fiche de membre s'il a accès aux services ou pas. J'espérais faire fonctionner ça avec une case à cocher, mais je me rends compte que c'est plus compliqué et, je dois bien l'avouer, étant novice avec FMP. je me suis un peu perdu dans la proposition. Alors j'ai plutôt fait deux rubriques de dates dans la table des renouvellements. Une pour le renouvellement avec cotisation et l'autre sans cotisation. À l'usage, quand un membre renouvelle, on indique la date dans la bonne colonne (avec ou sans cotisation). Techniquement, ça veut dire que sur une ligne j'ai une date soit dans la rubrique "avec cotisation" ou dans la rubrique "sans cotisation".
Ensuite, ma formule de calcule va seulement devoir être conditionnée par la dernière entrée "avec cotisation" et peu importe s'il y a une date dans la rubrique "sans cotisation".  Ça a l'effet souhaité.

Par contre, je me demande : dans vos messages, il est fait mention de problèmes potentiels du au fait que le calcul soit non mémorisé en raison de la référence à date actuelle. Qu'est-ce que ça signifie exactement? Qu'est-ce que ça pourrait occasionner comme problèmes plus tard?

Merci beaucoup.
François

Link to comment
Share on other sites

  • 0

Bonjour François,

La discussion indexable VS non mémorisé peut s'exprimer ainsi, dans ta situation :

  • «FileMaker, cherche-moi tous les adhérents dont la rubrique indexable Date_cotisation est ≥ à aujourd'hui - 1 an»
  • «FileMaker, cherche-moi tous les adhérents dont l'enregistrement lié dans la table des cotisations possède une Date_cotisation ≥ à aujourd'hui - 1 an»

sont deux requêtes qui renvoient les mêmes résultats, mais la seconde demande plus de travail informatique. A partir d'un certain nombre d'enregistrements, on peut observer des lenteurs.

Cela est-il parlant ?

Jérémie

Link to comment
Share on other sites

  • 0
Il y a 6 heures, Jérémie Gimenez a dit :

Bonjour François,

La discussion indexable VS non mémorisé peut s'exprimer ainsi, dans ta situation :

  • «FileMaker, cherche-moi tous les adhérents dont la rubrique indexable Date_cotisation est ≥ à aujourd'hui - 1 an»
  • «FileMaker, cherche-moi tous les adhérents dont l'enregistrement lié dans la table des cotisations possède une Date_cotisation ≥ à aujourd'hui - 1 an»

sont deux requêtes qui renvoient les mêmes résultats, mais la seconde demande plus de travail informatique. A partir d'un certain nombre d'enregistrements, on peut observer des lenteurs.

Cela est-il parlant ?

Jérémie

Donc si je comprends bien, aussitôt qu'on fait référence à un enregistrement d'une table liée, ça complexifie le calcul. Dans les deux cas, le calcul Date_cotisation > à aujourd'hui - 1 an est le même.
Merci pour les explications :)

François

Link to comment
Share on other sites

  • 0
Il y a 13 heures, Artcharo a dit :

aussitôt qu'on fait référence à un enregistrement d'une table liée, ça complexifie le calcul

Exactement.

L'autre avantage quand on entretient (par script, en général) une rubrique Date_cotisation à 'intérieur même de la table Membre, c'est qu'on peut la retrouver intacte dans d'autres occurrences de cette table. On n'est pas obligé d'avoir une occurrence de la table Adhesion reliée à chaque occurrence de la table Membre.

Tu n'en es peut-être pas encore au stade d'avoir plusieurs occurrences de la table Membre, mais ça viendra peut-être…

NB : un calcul non mémorisé (qui n'est pas forcément à proscrire, comme le dit @fabriceN) possède aussi cet avantage de fonctionner dans toutes les occurrences de la même table ; il fait un calcul à un endroit du schéma des relations, selon une occurrence liée, et rend le résultat consultable même en d'autres occurrences..

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Answer this question...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...