Re: [Galette-devel] Re: Cotisation par exercice

[Deelight <deelight@xxxxxxxxxx>]

laurent.pelecq@xxxxxxxxxx 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