Project

General

Profile

Actions

Evolution #737

closed

Date de contribution différente de date de début de l'adhésion

Added by Raphaël Hertzog almost 11 years ago. Updated over 10 years ago.

Status:
Fermé
Priority:
Normal
Category:
Core
Target version:
Start date:
10/28/2013
Due date:
% Done:

100%

Estimated time:

Description

Dans le cas d'un renouvellement, on est amené à saisir des contributions pour des adhésions qui n'ont pas encore expirées. Je veux saisir une contribution au 28 octobre pour un renouvellement d'adhésion qui prendra effet au 26 novembre... or je ne peux pas saisir 28 octobre comme date de contribution car galette me répond qu'il a conflit avec la période d'adhésion actuelle. Or pour mon enregistrement en comptabilité je veux absolument saisir la date réelle de contribution quelque part...

De deux chose l'une, soit galette gère une date de contribution distincte de la date de début de l'adhésion (et dans ce cas, il utilise la date saisie comme date de contribution et calcule la date de début de l'adhésion automatiquement avec la fin de la période précédente si cette date est dans le futur) soit galette supprime cette vérification et nous laisse saisir des adhésions qui se recoupent partiellement...

Actions #1

Updated by Johan Cwiklinski almost 11 years ago

Raphaël Hertzog a écrit :

Dans le cas d'un renouvellement, on est amené à saisir des contributions pour des adhésions qui n'ont pas encore expirées. Je veux saisir une contribution au 28 octobre pour un renouvellement d'adhésion qui prendra effet au 26 novembre... or je ne peux pas saisir 28 octobre comme date de contribution car galette me répond qu'il a conflit avec la période d'adhésion actuelle. Or pour mon enregistrement en comptabilité je veux absolument saisir la date réelle de contribution quelque part...

La date de début à saisir, c'est la date à laquelle prend effet la cotisation, elle doit donc être au 26/11. Lors de la création d'une contribution, une date de création est enregistrée avec la date du jour, qui est juste présente à titre informatif.
La requête SQL qui en résulte (si l'entrée est saisie le 28/10) :

INSERT INTO galette_cotisations
  (id_cotis, id_adh, id_type_cotis, montant_cotis, type_paiement_cotis, info_cotis, date_enreg, date_debut_cotis, date_fin_cotis, trans_id) 
  VALUES
  (91, 43, 1, '5.00', 0, '', '2013-10-28', '2013-11-26', '2014-11-26', NULL);

Du coup, le seul problème à mon sens, c'est peut-être que la date de la contribution ne peut être que la date du jour ; mais ça ne change strictement rien quant aux règles de calcul des contributions (auxquelles je ne veux pas vraiment toucher).

Actions #2

Updated by Raphaël Hertzog almost 11 years ago

Oui dans ce cas la seule chose à faire c'est de permettre d'éditer la date d'enregistrement de la contribution. La date du jour est une bonne valeur par défaut mais cela doit pouvoir être modifié au moment de la saisie.

Actions #3

Updated by Fr cero almost 11 years ago

J'ai le même souci avec ces dates, par exemple lors d'une transaction il est demandé une date, pour des raisons comptables il est souvent pratique d’indiquer la date de signature du chèque qui peut être antérieure à la date de saisie par le trésorier. Ensuite cette transaction est ventilée et la date saisie est enregistrée dans trans_date mais n'est pas dupliquée dans la table des cotisations . C'est étonnant d'autant plus que la transaction peut ne pas concerner une cotisation mais un achat d'objets ou un don. En quoi la date de début de cotisation est elle concernée ? Ne serait il pas plus judicieux que la date saisie en transaction soit dupliquée dans date_enreg ? Je suis en train d’écrire un plugin de remise de chèques en banque (choix entre 2 dates de cotisation/transaction) et cette subtilité des dates ne me facilite pas la tâche. Comme le suggère Raphaël à minima il serait utile pour les admin de pouvoir accéder à date_enreg en saisie de cotisation et en ventilation d'une transaction.

Actions #4

Updated by Johan Cwiklinski almost 11 years ago

  • Tracker changed from Anomalie to Evolution
Actions #5

Updated by André LEFRANC over 10 years ago

Cette divergence de date pose un problème lors de l'édition des contributions.
  • Il est bon que la date d'enregistrement soit la date de l'écriture dans Galette : Qu'elle ne soit pas modifiable lors de la saisie est intéressant, elle rend compte de l'état du travail : ie une secrétaire très en retard cela se détecte ainsi. Pour des raisons d'exercice ensuite dans phpMyAdmin je corrigerai pour que le reçu pour don et cotisation (plugin non officiel) soit conforme à la date d'enregistrement qui doit être la date de crédit en banque (cas d'un paiement CB ou d'un virement).
  • mais le problème est lorsque l'on veut établir une liste de contribution: la recherche entre deux dates se fait non pas sur la date d'enregistrement mais sur la date de début de l'adhésion. Du coup quelqu'un qui en avril règle une cotisation qui ne peut que suivre à partir de septembre n'apparaît pas dans la liste avec filtre du 15/0/2014 au 30/04/2014, parce que l'adhérent était déjà cotisant jusqu'au 16/09/2014 d'où impossible de comparer avec un état des cotisation sur une période donnée...
Actions #6

Updated by André LEFRANC over 10 years ago

pour tenter de résoudre le problème :
j'ai repéré dans contributions.php ligne 102 return 'date_debut_cotis'; que je remplace par return 'date_enreg'; mais cela n'est pas suffisant
dans protected function getDefaultOrder() {
return 'date_debut_cotis';
}
comment faire quel autre fichier intervient ?

Actions #7

Updated by Johan Cwiklinski over 10 years ago

  • Status changed from Nouveau to In Progress
  • Assignee set to Johan Cwiklinski
  • Category set to Core
  • Target version set to 0.8.0
Actions #8

Updated by Johan Cwiklinski over 10 years ago

André LEFRANC a écrit :

dans protected function getDefaultOrder()

Ça ne sert qu'à définir l'ordre d'affichage par défaut ; rien à voir avec le présent problème.

Actions #9

Updated by Johan Cwiklinski over 10 years ago

  • % Done changed from 0 to 100
  • Status changed from In Progress to Résolu
Actions #10

Updated by Johan Cwiklinski over 10 years ago

  • Status changed from Résolu to Fermé
Actions

Also available in: Atom PDF