[EMAIL PROTECTED] 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

Répondre à