197 lines
9 KiB
Markdown
197 lines
9 KiB
Markdown
# 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.
|
|
|