Deelight writes:
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


Répondre à