Fonctionnement des cotisations et activités (à partir de 2020)

(Reprise des infos de [ce ticket])

La partie "cotisations" est renommée en "cotisations et activités". En interne dans le code on utiliserait simplement "activité".

Une activité pourrait donc être :

  • ponctuelle (enregistrée à la date de paiement ou à une autre date libre)
  • valide pour une période donnée en jours (à partir d'une "date initiale de validité" qui pourra être la date d'enregistrement du paiement mais aussi une date au choix dans le passé ou dans le futur).
  • valide pour une période donnée en dates fixes (définies lors de la création et de la configuration de l'activité)

Remarque: Le troisième cas est juste un cas particulier du second, dans lequel la date initiale de validité est simplement fixée à l'avance.

Une activité serait gratuite ou aurait zéro, un ou plusieurs tarifs. "zéro" si l'activité est à prix libre. La cas "gratuit" est probablement à traiter différemment du cas "prix libre".

On pourrait inscrire un membre à une activité, en le marquant comme "à jour" ou "en attente", et en indiquant le tarif auquel il est soumis. Il ne pourrait pas être soumis à plusieurs tarifs en même temps.

Remarque: Dans le cas de l'activité à prix libre, le tarif auquel le membre est soumis ne pourra être indiqué qu'après que sa cotisation ait été enregistrée. Car avant cela, on ne sait pas combien le membre va cotiser...

Pour chaque activité on pourrait lier des écritures et faire le solde pour voir s'il a tout payé. Ceci permet de gérer les paiements en plusieurs fois.

L'interface de gestion des activités associées à un membre doit permettre de le marquer comme "à jour" ou "en attente" pour chaque activité (et éventuellement aussi modifier la date initiale de validité).

Il doit y avoir une interface permettant de marquer comme "à jour" tous les membres "en attente" d'une activité dont le solde atteint ou dépasse le tarif auquel ils sont soumis. Cela serait fait automatiquement?

Le statut "à jour" (pour chaque activité où il est inscrit) est associé à une date d'expiration et stocké associé au membre, il n'est plus calculé à la volée, ce qui simplifie le code, mais empêche d'avoir les changements répercutés sur les membres si on modifie une cotisation/activité.

À moins de proposer, lors de la modification de la cotisation, de recalculer automatiquement tous les statuts et les dates d'expiration (en fonction des montants et des dates initiales de validité enregistrées pour chaque membre)...

Après avoir créé un membre, la page suivante qui sera présentée est l'inscription à une ou plusieurs activités / cotisations, permettant de tout faire d'un coup.

Comme aujourd'hui, la fiche d'un membre devra montrer les cotisations qui lui sont associées, en séparant celles "à jour" et "en attente", et aussi l'historique de cotisation et les montants.

Comme aujourd'hui, une autre interface doit montrer la liste des cotisations et pour chacune, la liste des membres "à jour" et "en attente" (avec éventuellement possibilité d'envoyer un message à une sélection de membres, parmi non seulement ceux "en attente", pour des relances, mais aussi parmi ceux "à jour", par exemple pour une annonce liée à l'activité).

Il faudrait aussi permettre quelque part d'associer (et de dissocier) d'un seul coup plusieurs membres à une activité. C'est en particulier important après la création d'une nouvelle activité (par exemple, au début de chaque année pour la nouvelle cotisation annuelle). Cela pourrait se faire aussi via la iste déroulante qui est en bas de la page de résultats de recherche avancée.

Dans ce nouveau système, le statut "à jour" ou "en attente" serait donc une valeur fixe inscrite dans la base de données. Du coup, il serait très utile d'inclure dans les recherches avancées la possibilité de chercher sur le statut d'une cotisation, le solde et les dates initiales et d'expiration.

Évolution possible dans le futur

  • possibilité de laisser le membre choisir quel tarif il veut payer (pour le moment il ne pourrait pas changer de tarif lui-même).

Questions

  • Dans ce nouveau système, le statut et le montant sont donc définis individuellement pour chaque membre (ainsi que la date initiale des activités en période donnée, et évetuellement la date des activités ponctuelles). Le reste est fixé dans la définition de l'activité (i.e. montant -hors cas libre-, durée de la période, dates fixes, etc.). Ne faudrait-il pas prévoir aussi les cas où la durée de la période et/ou la date initiale peuvent être individualisables?

Un exemple (peut-être un peu tiré par les cheveux?): L'inscription à l'activité est de 10 EUR par mois. Si le membre paye 50 EUR, on enregistre 5 mois de validité à partir d'une certaine date initiale (qui peut ou pas être celle du paiement).