# Règles métier

Statut: référence métier  
Public: exécutifs, mainteneurs, testeurs  
Dernière révision: 2026-06-01

Ce document rassemble les règles que l'application doit respecter. Pour les parcours complets, voir [Processus applicatifs](20_PROCESSUS.md).

## Accès, identité et groupes

- Un membre se connecte dans un groupe précis.
- Les données d'un groupe ne doivent pas être visibles ou modifiables depuis un autre groupe.
- Le compte `Sysadmin` existe au déploiement initial avec le PIN `0000`.
- `Sysadmin` a tous les accès.
- `Sysadmin` ne peut pas être supprimé.
- `Sysadmin` peut impersonifier un membre.
- Une session impersonifiée conserve l'identité du sysadmin responsable.
- Un membre inactif ne peut pas se connecter.
- Un PIN doit avoir 4 chiffres.
- L'identifiant de connexion est unique dans un groupe.
- L'option `Se souvenir de moi` ne doit être utilisée que sur un appareil personnel.

## Groupe de démonstration

- Une installation vanille crée `Groupe Démonstration`.
- `Groupe Démonstration` est protégé contre la suppression.
- Le bouton `Réinit` du groupe de démonstration recrée les données fictives.
- Les autres groupes ne doivent pas être modifiés par la réinitialisation du groupe de démonstration.
- Les groupes sont listés alphabétiquement, sauf le groupe de démonstration qui reste en bas.

## Membres

- Le prénom et le téléphone sont requis pour un membre ordinaire.
- La désactivation agit seulement sur le droit de connexion.
- La réactivation restaure le droit de connexion.
- Le droit à l'oubli anonymise au lieu de supprimer.
- Le droit à l'oubli conserve l'ID et le prénom.
- Le droit à l'oubli efface les informations de contact, le nom, la date d'abstinence, les préférences et les abonnements push.
- Un membre ne doit pas pouvoir détruire l'historique relationnel du groupe.

## Invitations

- Une invitation appartient à un groupe.
- Une inscription par invitation crée le membre dans le groupe de l'invitation.
- Un code d'invitation ne peut être utilisé qu'une seule fois.
- Un code expiré est refusé.

## Permissions

- Les permissions viennent des postes actifs.
- Les permissions de modules sont associées aux postes.
- Les exécutifs ont accès aux fonctions de gestion courante.
- Les responsables de service peuvent recevoir des modules spécialisés.
- Le frontend peut masquer un module, mais le backend doit refuser l'action non autorisée.

## Postes, candidatures et mandats

- Un poste appartient à un groupe.
- Un poste peut être actif ou aboli.
- Un poste aboli n'est pas proposé comme poste à pourvoir.
- Un membre peut postuler à un poste disponible.
- Un exécutif peut proposer un autre membre.
- Une affectation active lie un membre, un poste et une date de début.
- Un poste déjà affecté ne doit pas être affecté une deuxième fois tant que le mandat est actif.
- Terminer un mandat conserve l'historique.
- Une affectation ou nomination produit une décision de type `Nomination`.
- Une nomination exige proposeur et secondeur.

## Rencontres

- Les dates de rencontres doivent respecter le jour configuré du groupe.
- Les listes de dates doivent être présentées en ordre chronologique inverse lorsque cela réduit le risque de choisir la mauvaise année.
- Une rencontre indique une date, une heure, un sujet et un animateur.
- L'animateur par défaut est le membre occupant le poste d'animateur lorsque connu.
- Une rencontre peut avoir une collecte.
- Une rencontre peut avoir plusieurs ventes.
- Une rencontre peut avoir plusieurs remises statistiques de jetons ou gâteaux.
- Le rapport PDF d'une rencontre regroupe les intrants de cette rencontre.

## Assemblées

- Les assemblées sont des réunions d'affaires planifiées selon les paramètres du groupe.
- Le paramètre mensuel indique première, deuxième, troisième, quatrième ou dernière réunion du mois.
- La page d'une assemblée sert d'ordre du jour.
- Le rapport PDF d'assemblée sert de procès-verbal imprimable.
- Les présences alimentent le rapport.
- Le lien invité donne accès en lecture seule pendant une période contrôlée.

## Procès-verbaux et rapports adoptés

- L'adoption d'un procès-verbal exige un proposeur et un secondeur.
- L'adoption du rapport du trésorier exige un proposeur et un secondeur.
- Un rapport peut être corrigé avant adoption.
- Une fois adopté, un rapport est cristallisé, historisé, consultable et imprimable.
- Le rapport du trésorier doit être adopté avant de décider des contributions.

## Gouvernance

- Une proposition n'a pas de type au départ.
- Une proposition doit avoir un objet.
- Une proposition peut être secondée avec `Je seconde`.
- Un exécutif peut seconder pour un autre membre.
- Sysadmin peut seconder ses propres propositions et nominations.
- Une décision de groupe exige proposeur et secondeur.
- Une décision exige les sections `ÉTANT DONNÉ QUE` et `LE GROUPE A DÉCIDÉ DE`.
- Les types de décisions sont `Résolution`, `Nomination` et `Contribution`.
- Les préfixes sont `RES`, `NOM` et `DON`.
- Une proposition rejetée est conservée.
- Le rejet exige une raison dans `ÉTANT DONNÉ QUE`.

## Collectes

- Une collecte appartient à une rencontre.
- Une rencontre ne doit pas avoir plus d'une collecte.
- La saisie de collecte est réservée aux postes autorisés, notamment exécutifs.
- Une collecte reçue par le trésorier augmente l'encaisse.
- La date comptable de réception d'une collecte est la date de la collecte.

## Ventes et inventaire

- Une vente de littérature est saisie lors d'une rencontre.
- Une vente de littérature diminue l'inventaire.
- Une vente de jetons est saisie lors d'une rencontre.
- Une vente de jetons diminue l'inventaire de jetons.
- L'argent d'une vente est à recevoir par le trésorier.
- La réception d'une vente augmente l'encaisse.
- Une remise de jeton ou gâteau est statistique et n'affecte pas l'inventaire.

## Dépenses

- Un membre soumet une dépense en son nom.
- Un exécutif peut soumettre une dépense pour un autre membre.
- La date de dépense est la date de soumission, sauf saisie à posteriori autorisée pour sysadmin.
- Les dépenses sont traitées dans le module `Trésorerie`.
- Une dépense cash diminue l'encaisse au traitement.
- Une dépense par chèque ou virement crée un engagement jusqu'au débit bancaire.
- Une dépense par chèque ou virement ne peut pas être acceptée si le solde bancaire ne permet pas d'engager le montant.
- Une demande rejetée est effacée.

## Trésorerie

- `transactions_comptables` est la source de vérité des soldes banque et encaisse.
- L'encaisse est disponible mais séparée de la banque.
- Le solde disponible est le solde bancaire moins engagements et réserves.
- Le solde disponible n'est pas une réserve.
- Le total des réserves fait partie de la position de trésorerie.
- Les réserves ne doivent pas dépasser ce que la banque permet de couvrir.
- Le montant d'une réserve change par mouvement de réserve, pas par modification directe.
- Une réserve peut être supprimée seulement si son solde est zéro.
- Les virements entre disponible et réserves apparaissent au registre.
- Les transactions du registre sont affichées les plus récentes d'abord.

## Dépôts, retraits et dons

- Un dépôt peut provenir de l'encaisse.
- Un dépôt peut provenir d'un don direct.
- Un don direct augmente la banque sans diminuer l'encaisse.
- Un dépôt depuis l'encaisse augmente la banque et diminue l'encaisse.
- Un retrait augmente l'encaisse et diminue la banque.

## Contributions

- `Donner au suivant` crée une décision de type `Contribution`.
- Une contribution exige proposeur et secondeur.
- Une contribution doit avoir un destinataire.
- `District 87-16` est créé au déploiement initial.
- `District 87-16` est protégé contre la suppression.
- Une contribution doit être traitée par la trésorerie pour affecter les soldes.

## Rapports

- L'état des résultats est intégré à la trésorerie.
- Le rapport PDF mensuel utilise l'état des résultats du mois précédent.
- Les positions de trésorerie du rapport PDF sont celles du dernier jour du mois précédent.
- Le registre PDF des décisions affiche `LE GROUPE A DÉCIDÉ DE` comme résolution lorsque ce champ existe.
- Le sommaire du registre de décisions ne doit pas être ajouté s'il n'apporte pas de valeur.

## Journal et historique

- Les actions modifiantes réussies sont journalisées.
- Le journal doit indiquer le membre ayant causé le changement.
- L'historique détaillé peut indiquer l'ancienne valeur et la nouvelle valeur.
- La raison de modification est déterminée automatiquement par l'application.
- Le journal doit être filtrable et lisible sous forme de tuiles.

## Notifications

- Les notifications sont optionnelles.
- Chaque membre choisit les catégories qui l'intéressent.
- Une action peut produire une notification selon son domaine.

## Mode papier et continuité

- Les rapports doivent soutenir l'impression format lettre.
- Le groupe doit pouvoir continuer une rencontre ou assemblée sans l'application.
- Les données papier peuvent être ressaisies plus tard.