[EMAIL PROTECTED] a écrit :
Je viens de comprendre ;-) En fait ce n'est pas compliqué. Dans les
préférences on met la date de fin d'exercice. Mais elle ne sert qu'a
préremplir la date de fin de cotisation. C'est plus pratique. Si
quelqu'un paie en avance, on change la date de fin pour mettre l'année
suivante.
Le problème est que la date de fin de cotisation doit pouvoir être
recalculée à partir des cotisations (par exemple si on coche/décoche la
case 'exempt de cotisation' ou si on supprime une cotisation. Il faut
donc pouvoir gèrer cette petite particularité. La valeur de
'date_echeance' permet juste de ne pas avoir a effectuer ce calcul 50
fois lorsqu'on affiche la liste des adhérents.
Ce cas se retrouve cependant dans le mode de calcul actuel, on les jours
d'adhésions restants sont reportés. Dans les cotisations par exercice,
on reporte en fait une année lorsque l'adhérent se réinscrit avant
l'échéance.
Ca explique pourquoi la fonction get_echeance est si compliquée.
Yep, c'est pour cette raison. Et c'est aussi pour cette raison que
j'utilise le champ date_echeance pour stocker son resultat et éviter
d'avoir à le recalculer à chaque fois. Je met à jour ce champ uniquement
lorsqu'il y a une action imposant sa mise à jour.
En fait ça soulève un problème plus complexe. C'est qu'il y a une
confusion entre la date de paiement et la date de cotisation. Quand je
paie en avance, c'est le paiement qui est en avance. La cotisation ne
débute qu'à la fin de la précédente. Ca évite de reporter les durées.
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).
Il faudrait indiquer les deux dates. Mais il y a un autre problème que
m'a expliqué notre trésorier. Ce qui serait intéressant, c'est de garder
la trace des paiements (sans faire de compta). Par exemple paiement par
chèque n°0000 montant 30 euros. Mais un paiement peut correspondre à
plusieurs chose : la cotisation + une donation ou 1 tee-shirt de l'asso.
Voire le paiement de la cotisation d'un autre (celui de son conjoint par
exemple).
Il faudrait donc pouvoir faire comme ceci : j'enregistre un paiement
chèque n°0000 à la date xx, ou CB ou virement. Puis je passe à l'écran
des contributions pour dire à quoi ça correspond. Sachant que je peux
entrer plusieurs contributions jusqu'à ce que la somme des contributions
soit égale au montant du paiement.
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.
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.
Ce sont de gros changements. Est-ce que ça vous paraît bon dans le
principe ?
Pour le premier point, je pense qu'il faut coder une variante de la
fonction get_echeance. Pour le second, il semble en effet intéressant de
différencer les paiements et les cotisations. Ca ouvrirait la voie à
l'utilisation de Galette pour la compta de l'asso.
Frédéric