feat(erp): indemnité d'occupation janv→juil 2026 (1 483,23 €) — paiements divers, sans tiers (#89)
Co-authored-by: Gabriel Radureau <[email protected]>
This commit was merged in pull request #89.
This commit is contained in:
@@ -0,0 +1,59 @@
|
||||
# Run abandonné — mauvaise modélisation, pas mauvaise exécution
|
||||
|
||||
Ce dossier de preuve est conservé parce qu'il documente une **erreur de
|
||||
conception rattrapée avant d'atteindre la production**. Les artefacts (01 à 04)
|
||||
décrivent un change-set qui n'a jamais été appliqué.
|
||||
|
||||
## Ce qui était proposé
|
||||
|
||||
Créer un tiers fournisseur « Radureau Gabriel », lui adresser 7 factures
|
||||
fournisseur d'indemnité d'occupation, et régler chacune par le compte courant
|
||||
d'associé — la voie `adc-005`.
|
||||
|
||||
## Pourquoi c'était faux
|
||||
|
||||
**Le gérant n'est pas un fournisseur de sa société.** Lui ouvrir une fiche
|
||||
fournisseur le fait apparaître au grand livre auxiliaire, dans les balances âgées
|
||||
et dans les états de dettes fournisseurs. C'est mot pour mot l'objection déjà
|
||||
opposée à l'URSSAF dans `RUNBOOK_charges_sociales.md` — et je l'ai reproduite en
|
||||
la contredisant.
|
||||
|
||||
Le contrôle qui aurait dû le révéler existait pourtant : les 8 dettes déjà
|
||||
portées au compte courant sont toutes des factures de **fournisseurs réels**
|
||||
(La Poste, Greffe, Infogreffe, Qonto), payées personnellement, le règlement
|
||||
transitant par le compte courant. Le tiers y est toujours le fournisseur, jamais
|
||||
le gérant. Il suffisait de regarder l'existant.
|
||||
|
||||
## Ce qui a arrêté le change-set
|
||||
|
||||
Un **403** à l'étape `apply` : le scope `prod-write` exclut délibérément le droit
|
||||
122 « Créer/modifier les tiers », avec ce commentaire dans `test/scopes.ts` —
|
||||
*« No thirdparty creation […] those are rehearsed then applied by a human when
|
||||
they are genuinely needed »*. La restriction a fait office de garde-fou pour une
|
||||
raison qui n'était pas la sienne. La production n'a rien reçu.
|
||||
|
||||
C'est ensuite l'opérateur qui a posé la bonne question : faut-il vraiment un
|
||||
tiers pour une dette envers le compte courant de l'associé ?
|
||||
|
||||
## Ce qui a été fait à la place
|
||||
|
||||
Sept **paiements divers** (`test/recordVariousPayment.ts`) sur le compte bancaire
|
||||
`CCA1` (id 3, numéro comptable 45511), code comptable `613000 - Locations`,
|
||||
sens débit :
|
||||
|
||||
débit 613000 Locations (la charge)
|
||||
crédit 45511 G. RADUREAU, compte courant (la dette envers l'associé)
|
||||
|
||||
Aucun tiers, aucune facture, aucune pollution du grand livre auxiliaire.
|
||||
|
||||
## Ce que ce run apprend au harness
|
||||
|
||||
- Le pipeline ne porte que du REST. `/variouspayments` répond « API not found »,
|
||||
donc la bonne opération lui échappe — comme les charges sociales. La couverture
|
||||
du promote gated est plus étroite qu'elle en a l'air, et le choix de
|
||||
l'instrument comptable décide de la voie disponible.
|
||||
- Le verdict pré-gate (BLOCK sur la chronologie, art. 289) portait sur un
|
||||
détail réel mais mal qualifié, et **passait à côté du défaut structurel**. Un
|
||||
juge qui lit le change-set sans lire l'existant ne peut pas voir qu'un modèle
|
||||
contredit celui déjà en place. Piste : donner au juge l'état observé, pas
|
||||
seulement le manifeste.
|
||||
Reference in New Issue
Block a user