# @mostajs/encaissement — fiche LLM
> Le REGISTRE des règlements — tous moyens, tous canaux — chaîné, et sa CLÔTURE (ticket Z).

- Version: 0.2.0 · Licence: AGPL-3.0-or-later · Auteur: Dr Hamid MADANI <drmdh@msn.com>
- Chemin: mostajs/mosta-commerce-stack/mosta-encaissement · Dépend de `@mostajs/paiement-contrat`

## RÔLE — LA FRONTIÈRE, ET POURQUOI ELLE ÉTAIT MAL PLACÉE
Trois modules se partagent l'encaissement, chacun avec SON interlocuteur :
- `@mostajs/paiement-tpe` → l'**APPAREIL** (autonome, CAISSE 3.2, nexo…)
- `@mostajs/payment` → la **BANQUE** (Stripe, Chargily, SATIM…)
- `@mostajs/encaissement` → la **TRACE** ← ce module

⚠️ `Reglement` vivait dans `paiement-tpe` par accident d'histoire : le terminal fut le premier moyen
implémenté, et l'entité a suivi. Or **espèces, virement, carte et terminal alimentent TOUS le même
registre**. Un règlement en espèces n'a aucun terminal.

## EXPORTS
- Entités : `ReglementSchema`, `ClotureSchema`, `SCHEMAS_ENCAISSEMENT`
- Registre : `creerRegistre({ depot, now? })` → `{ dernier, ecrire, verifier }`
- Clôture : `creerCloture({ depot, reglements, numerotation, devise, now?, exercice? })`
  → `{ apercu, clore, verifier, liste, derniere, cumuls }`
  · `apercu({ type? })` · `clore({ type?, par? })` · `cumuls()` — type ∈ `TYPES_CLOTURE`
  · `exercice` = `{ mois, jour }`, défaut année civile (donnée du COMPTABLE, pas une constante)
- `TYPES_CLOTURE` : `['journaliere', 'mensuelle', 'annuelle']` — la doctrine les déclare
  « cumulatives et impératives » (BOI-TVA-DECLA-30-10-30)
- Chaînage (réexporté du contrat) : `empreinteDe`, `verifierChaine`, `aSigner`, `CHAMPS_SIGNES`
- `@mostajs/encaissement/register` → `register(registry)` — **sans lui, les tables ne sont jamais créées**

## LES TROIS GARANTIES
1. **Append-only** — ni `update` ni `delete`. Ce n'est pas un oubli.
2. **Chaîné** — chaque règlement porte l'empreinte du précédent : une altération faite AILLEURS
   (accès à la base, restauration partielle) devient DÉTECTABLE.
3. **Clôturable** — une clôture arrête un total, le date, le numérote **sans rupture** et le fige.

## LES CUMULS (0.2.0) — NF525 §6.4.2.2
Chaque clôture porte `grandTotalPrecedent`, `cumulExercice`, `exerciceDebut`,
`totalPerpetuelAbsolu` et `totalPerpetuelReel`. Le perpétuel ne se remet **jamais** à zéro.

## PIÈGES
- ⚠️ **LES PÉRIODIQUES AGRÈGENT DES CLÔTURES, JAMAIS DES RÈGLEMENTS.** Recalculer depuis les
  règlements donnerait un second chemin vers le même chiffre, et deux chemins divergent : un
  règlement écrit après coup avec une date antérieure serait vu par l'un et pas par l'autre. La
  somme des Z **est** le mois.
- ⚠️ **UNE PÉRIODIQUE *REPORTE* LE PERPÉTUEL, elle ne l'incrémente pas.** L'incrémenter compterait
  chaque règlement deux fois — et le défaut serait invisible, les totaux de période restant justes.
- ⚠️ **LA SIGNATURE EST VERSIONNÉE** (champ `v`). `verifier()` choisit l'algorithme d'après LA
  LIGNE, jamais d'après la version du code : les clôtures écrites en 0.1.x restent vérifiables
  **sans migration**. Ne jamais toucher à `CHAMPS_V1`.
- ⚠️ **AUCUN AMORÇAGE DE COMPTEUR n'est offert, et c'est délibéré.** Reprendre à la main le cumul
  d'un système antérieur est contraire à la norme : *« en cas de changement de matériel ou de
  logiciel, tous les compteurs repartent de zéro ; les compteurs de l'ancien système doivent être
  archivés et sécurisés »*. Une valeur saisie n'est attestée par rien et détruirait la propriété
  que le compteur établit. Un report éventuel se déclare et s'affiche **hors** des compteurs signés.
- ⚠️ **La fenêtre d'une journalière part de la dernière JOURNALIÈRE**, pas de la dernière clôture
  tous types confondus : une mensuelle intercalée ne consomme aucun règlement.
- ⚠️ **L'algorithme de chaînage n'est PAS ici** : il est dans `@mostajs/paiement-contrat`, pur, pour
  que `payment` et `paiement-tpe` calculent la MÊME empreinte. Deux implémentations divergentes
  produiraient deux chaînes incompatibles.
- ⚠️ **`numerotation` doit être `resetEvery: 'never'`.** Un numéro qui repart à 1 chaque jour ne
  prouve rien : c'est l'absence de trou dans une suite CONTINUE qui montre qu'aucune clôture n'a
  été supprimée.
- ⚠️ **La fenêtre d'une clôture est `]précédente, MAINTENANT]`** : un règlement daté dans le futur
  n'est pas couvert, et un règlement écrit APRÈS avec une date ANTÉRIEURE ne l'est pas non plus.
  On ne peut pas l'empêcher ; `verifier()` le **détecte** en recomptant.
- ⚠️ **Un règlement REFUSÉ n'entre pas dans la recette** : le compter gonflerait le total d'un
  argent jamais entré.
- ⚠️ **Le NON-VENTILÉ est compté à part** (règlements antérieurs à `ventilationTva`). L'additionner
  en silence ferait une clôture dont la somme des taux ne retombe pas sur le total — et une TVA
  sous-évaluée.
- ⚠️ **CONCURRENCE** : deux écritures simultanées bifurquent. `verifier()` le signale ; sur un parc
  à plusieurs caisses, sérialiser en amont.
- `paiement-tpe` ≥ 0.4.0 réexporte `ReglementSchema` et `creerRegistre` **par compatibilité**
  (déprécié) : les retirer sèchement ferait disparaître la table `reglements` sans erreur au
  démarrage.
