En fait la date de cotisation est en quelques sorte calculée par la fonction get_echeance (enfin date de cotisation + durée cotisation). Je pense qu'en la stockant dans une table, on ne s'affranchirait pas ne la nécessité de mettre automatiquement cette valeur à jour dans certains cas (ex: je me rends compte que j'ai saisi deux fois la même cotisation pour une personne l'année précédente, et il y a eu une nouvelle cotisation depuis).
Sans parler de paiement, il me semble qu'il faudrait différencier la date d'enregistrement et la date de cotisation. Deux cotisations n'ont aucune raison de se chevaucher.
On pourrait avoir ceci en années glissantes : quand on entre la première cotisation, elle démarre à la date d'enregistrement. Quand on entre une nouvelle cotisation pour un membre, la date d'enregistrement est "aujourd'hui", mais on pré-rempli la date de début de cotisation au lendemain de la fin de la précédente. Et on n'accèpte pas de cotisations qui se chevauchent.
Comme ça il n'y a plus de problème de calcul de fin d'adhésion : c'est le max de toutes les dates de fin. Et puis la date de fin d'adhésion est claire. Pour l'instant c'est un peu magique, pour peu qu'il y ait beaucoup de report. Il faut prendre sa calculatrice pour la connaître.
Ok, donc ça impliquerait d'avoir deux tables séparée, une pour les paiements, l'autres pour les contribution (avec liaison ou non avec un ou plusieurs paiements). C'est en effet envisageable même si c'est un "gros morceau" :). Ca tendrait vers un des projets auquel je pensais, à savoir la gestion comptable de l'association.
J'aimerai bien faire ça. Je suis optimiste en ce moment.
D'autre part il faudrait distinguer les cotisations des autres contributions. Parce qu'une donation ne doit pas alonger la durée de l'adhésion quand on est en années glissantes.
On peut tout à fait mettre 0 en prolongation d'adhésion pour une contribution afin qu'elle n'ait aucun influence sur l'échéance de l'adhésion.
Oui.
Laurent
Generated by mhonarc 2.6.10, Sun Nov 07 13:20:07 2004