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

[Deelight <deelight@xxxxxxxxxx>]

laurent.pelecq@xxxxxxxxxx a écrit :
> > 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.

Le résultat serait différent par rapport à ce qui est fait actuellement. 
 Dans le fonctionnement actuel (années glissantes):

- si on a une cotisation le 01/01/2004, elle court jusqu'au 31/12/2004
- si on a une nouvelle costisation le 05/01/2005, elle court jusqu'au 
04/01/2006.

On considèré que la personne n'était plus adhérente du 01/01/2005 au 
04/01/2005. Ca permet notamment de ne pas se planter pour une personne 
qui avait résilié son adhésion, et qui se réinscrit au bout d'un certain 
temps.

Dans le contexte actuel, il faut considèrer date_cotisation comme la 
date de début de cotisation (mais qui n'est pas ajustée en cas de 
chevauchement - seul le calcul de la fin d'adhésion en tient compte). On 
pourrait cependant adapter le formulaire de saisie de cotisation pour 
imposer à l'administrateur de saisir une date de début de cotisation qui 
ne chevauche pas la précédente. Cependant je trouve la méthode actuelle 
plus souple puisqu'elle n'impose pas cette restriction à 
l'administrateur, et elle se débrouille avec ce qu'on lui fournit.

Enfin si on part sur l'idée de ce champ je pense qu'il faudrait le 
préremplir de cette manière :

- Année glissantes :
  - si c'est une premiere cotisation, date du jour
  - si c'est une nouvelle cotisation, date prévue de fin de la
    précédente adhésion si elle court encore, et date du jour si elle
    est révolue. On considère donc que la personne n'était plus
    adhérente entre les deux (comme c'est le cas actuellement). Libre à
    l'administrateur de modifier la date de cotisation pour qu'elle
    corresponde à la fin de la précédente adhésion.

- Par exercice
  - si c'est une premiere cotisation, date définie de début d'exercice,
    pour la période en cours (on considèrerait que l'adhérent s'inscrit
    pour l'exercice en cours, et pas le prochain... mais il faudrait
    eventuellement en discuter pour voir ce qui concient le mieux)
  - si c'est une nouvelle cotisation, date définie de début  		
    d'exercice pour l'année en cours, on la suivante l'adhésion n'était
    pas révolue.

Il y a tout de même quelquechose qui me pose un peu problème avec ce 
fonctionnement, c'est que cas de saisie d'une ancienne cotisation pour 
un membre, les échéances ne sont pas recalculées.

Quand on installe Galette, il y a généralement une phase on l'on saisit 
toutes les cotisations des membres, sur une ou plusieurs années. Dans 
l'état actuel, l'ordre de saisie importe peu puisque l'échéance est 
dynamiquement recalculée. Avec ce nouveau système, il faudrait 
absolument saisir les cotisations dans l'ordre pour que l'échéance soit 
correcte...

> 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.

Elle est calculée par Galette heureusement, mais sans Galette c'est 
effectivement à la calculatrice qu'il faudrait la trouver :)

> > 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.

Libre à toi de tenter le coup alors :)

Frédéric