[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

Répondre à