feat(erp): cycle M4 KissMetrics, et les deux comptes bancaires ramenés au centime #96

Merged
arcodange merged 4 commits from arcodange/changeset-m4 into main 2026-08-24 13:13:44 +02:00
Owner

Cinq passages en production, tous appliqués et vérifiés, avec leurs artefacts de preuve. Au bout : l'ERP et la banque disent le même chiffre sur les deux comptes — Qonto 2 013,30 € et Wise 11 863,85 €, écart 0,00.

Le fait qui a débloqué le reste

L'opérateur a établi en session que KissMetrics n'a jamais reçu la moindre facture : le client payait le forfait de 2 500 USD sans pièce. Ça change deux choses — le ton de la relance, et la liberté de corriger des factures qu'on croyait entre ses mains.

Ce qui est en production

Cycle M4 et écarts bancairesruns/2026-08-24-m4-et-ecarts/
Tiers Anthropic PBC, sa facture de 90 € de juillet, le règlement Darnis de 262,20 €, et les deux factures M4.

Clause de pénalitésruns/2026-08-24-clause-bilingue/
Les factures M4 étaient sorties avec une clause amputée : sans traduction anglaise, sans la mention d'ordre public. Détecté par le contrôle des mentions obligatoires sur les PDF, avant tout envoi. C'est précisément la phrase sur laquelle repose la relance.

Encaissement du 17/08runs/2026-08-24-encaissement-m4/
2 164,75 € reçus de KissMetrics, non enregistrés. FAC009 avait donc été émise au taux du 24/08 alors que le contrat arrête le montant au taux du jour du règlement. Portée à 2 164,75 €, adossée au virement.

Reprise FAC004/FAC006 et réparation FAC009runs/2026-08-24-reprise-fac004-fac006/
Les deux portaient 2 145,92 €, le même montant repris d'un cycle à l'autre, quand la banque avait reçu 2 147,00 € et 2 195,97 €. 51,13 € d'encaissement manquaient. Portées au montant réel. Plus l'abonnement Anthropic d'août.

URSSAF, cashbacks, ristourne — hors pipeline (pas de route REST)
Deux échéances URSSAF, 493 € et 1 215 €, ni l'une ni l'autre enregistrée. Six cashbacks Wise et une ristourne Qonto.

Le juge

Six BLOCK dans la journée. Cinq étaient faux et sont outrepassés avec leur preuve mécanique dans 03-gate.json : l'art. 289 du CGI invoqué pour l'ordre paiement/facture qu'il ne régit pas ; une rédaction de référence supposée sans être lue ; un PDF produit confondu avec une facture transmise ; un champ emetteur null sur la seule ligne d'août alors qu'il l'est sur les huit précédentes.

Le sixième était juste, et il valait tous les autres. PUT /invoices/{id}/lines/{lid} n'est pas un PATCH : les champs absents du corps sont remis à zéro. Le juge a vu que desc était effacé et product_type ramené de service à produit — sans lui, deux factures partaient chez le client sans désignation. Et il a fait apparaître que FAC009, corrigée le matin, portait déjà le défaut en production. Réparé.

Le prompt de juge mérite un affinage : il tire l'art. 289 dès qu'il voit deux dates dans le désordre, et il conclut sans aller lire la pièce de référence quand elle est à un appel d'API. Hors périmètre de cette PR.

Les comptes du plan comptable

Écriture Compte Pourquoi
Cashback Wise 768 Le montant suit le SOLDE, pas les frais : ~0,5-0,6 % l'an, stable. Rémunération d'un solde, donc produit financier. Ni 763 (créances commerciales) ni 764 (VMP).
Ristourne Qonto 627 au crédit Typée qonto_fee par la banque, côté crédit : une remise sur service reçu diminue la charge, elle ne crée pas un produit.
URSSAF 641 SARL à l'IS : ce que la société verse pour son gérant majoritaire est une charge de personnel. Pas 646 (exploitant individuel, sociétés à l'IR), pas 645x (cotisations sur salaires, aucun salarié). Voir adc-009.

Le runbook des charges sociales disait 646 — corrigé, avec mention explicite que toute version portant 646 est périmée. Son exemple --period 2026 était par ailleurs invalide et faisait échouer la création sans message.

Les quatre scripts

buildInvoicePdf.ts — valider une facture par l'API ne produit aucun PDF ; builddoc répond 403 à tout scope agent. Passe par l'interface, puis relit le fichier par l'API.

setCompanyEmail.ts — le champ s'appelle mail, pas MAIN_INFO_SOCIETE_MAIL, malgré la constante qu'il alimente et la convention de tous ses voisins.

paySocialCharge.tsrecordSocialCharge.ts laissait la charge impayée et rien n'enregistrait le règlement ; c'est ce trou qui rendait les deux échéances URSSAF invisibles. Piège consigné : ne pas chercher « payée » dans la page, « ImPAYÉE » contient « payée » — une première version déclarait ÉCHEC sur un règlement abouti, ce qui pousse à rejouer donc à créer un doublon.

deleteInvoicePayment.ts — l'API ne sait pas supprimer un règlement. Deux verrous : tant que la facture est marquée payée le lien de suppression est absent, sans message ; et la confirmation est une modale jQuery dont les boutons n'ont ni name ni value.

Plan de test

  • Répétitions en bac à sable rafraîchi depuis la production avant chaque passage
  • Juges pré-gate — un PASS, cinq BLOCK analysés et outrepassés avec preuve écrite
  • Applications en production — toutes opérations ok
  • Juges post-gate — PASS sans dérive, tous
  • Relecture des objets : montants, échéances, notes, desc, product_type
  • Réconciliation bancaire complète : écart 0,00 sur Qonto et sur Wise
  • Contrôle des mentions obligatoires sur les sept PDF du dossier client

Ce qui reste à l'opérateur

Le contrat cadre et son avenant ne sont pas dans le dossier : aucun exemplaire signable n'existe: le contrat est un objet de l'ERP (CT2601-0001) sans pièce jointe. À joindre depuis ta source.

La décision n° 3 n'est pas signée. Vérifié en lisant les PDF : la n° 1 porte une signature manuscrite, la n° 2 une signature et un paraphe en pied de ses deux pages. La n° 3 n'a ni l'une ni l'autre. La n° 2 traîne par ailleurs trois champs AcroForm vides laissés par l'outil de signature.

Restant dû par KissMetrics : 7 718,76 €, dont 2 575,11 € échus (FAC005).

🤖 Generated with Claude Code

Cinq passages en production, tous appliqués et vérifiés, avec leurs artefacts de preuve. Au bout : **l'ERP et la banque disent le même chiffre sur les deux comptes** — Qonto 2 013,30 € et Wise 11 863,85 €, écart 0,00. ## Le fait qui a débloqué le reste L'opérateur a établi en session que **KissMetrics n'a jamais reçu la moindre facture** : le client payait le forfait de 2 500 USD sans pièce. Ça change deux choses — le ton de la relance, et la liberté de corriger des factures qu'on croyait entre ses mains. ## Ce qui est en production **Cycle M4 et écarts bancaires** — `runs/2026-08-24-m4-et-ecarts/` Tiers Anthropic PBC, sa facture de 90 € de juillet, le règlement Darnis de 262,20 €, et les deux factures M4. **Clause de pénalités** — `runs/2026-08-24-clause-bilingue/` Les factures M4 étaient sorties avec une clause **amputée** : sans traduction anglaise, sans la mention d'ordre public. Détecté par le contrôle des mentions obligatoires sur les PDF, avant tout envoi. C'est précisément la phrase sur laquelle repose la relance. **Encaissement du 17/08** — `runs/2026-08-24-encaissement-m4/` 2 164,75 € reçus de KissMetrics, non enregistrés. FAC009 avait donc été émise au taux du 24/08 alors que le contrat arrête le montant au taux du jour du règlement. Portée à 2 164,75 €, adossée au virement. **Reprise FAC004/FAC006 et réparation FAC009** — `runs/2026-08-24-reprise-fac004-fac006/` Les deux portaient 2 145,92 €, le même montant repris d'un cycle à l'autre, quand la banque avait reçu 2 147,00 € et 2 195,97 €. **51,13 € d'encaissement manquaient.** Portées au montant réel. Plus l'abonnement Anthropic d'août. **URSSAF, cashbacks, ristourne** — hors pipeline (pas de route REST) Deux échéances URSSAF, 493 € et 1 215 €, ni l'une ni l'autre enregistrée. Six cashbacks Wise et une ristourne Qonto. ## Le juge Six BLOCK dans la journée. **Cinq étaient faux** et sont outrepassés avec leur preuve mécanique dans `03-gate.json` : l'art. 289 du CGI invoqué pour l'ordre paiement/facture qu'il ne régit pas ; une rédaction de référence supposée sans être lue ; un PDF produit confondu avec une facture transmise ; un champ `emetteur` null sur la seule ligne d'août alors qu'il l'est sur les huit précédentes. **Le sixième était juste, et il valait tous les autres.** `PUT /invoices/{id}/lines/{lid}` n'est pas un PATCH : les champs absents du corps sont remis à zéro. Le juge a vu que `desc` était effacé et `product_type` ramené de service à produit — sans lui, deux factures partaient chez le client **sans désignation**. Et il a fait apparaître que FAC009, corrigée le matin, portait déjà le défaut en production. Réparé. > Le prompt de juge mérite un affinage : il tire l'art. 289 dès qu'il voit deux dates dans le désordre, et il conclut sans aller lire la pièce de référence quand elle est à un appel d'API. Hors périmètre de cette PR. ## Les comptes du plan comptable | Écriture | Compte | Pourquoi | | --- | --- | --- | | Cashback Wise | **768** | Le montant suit le SOLDE, pas les frais : ~0,5-0,6 % l'an, stable. Rémunération d'un solde, donc produit financier. Ni 763 (créances commerciales) ni 764 (VMP). | | Ristourne Qonto | **627** au crédit | Typée `qonto_fee` par la banque, côté crédit : une remise sur service reçu diminue la charge, elle ne crée pas un produit. | | URSSAF | **641** | SARL à l'IS : ce que la société verse pour son gérant majoritaire est une charge de personnel. Pas 646 (exploitant individuel, sociétés à l'IR), pas 645x (cotisations sur salaires, aucun salarié). Voir `adc-009`. | Le runbook des charges sociales disait 646 — corrigé, avec mention explicite que toute version portant 646 est périmée. Son exemple `--period 2026` était par ailleurs invalide et faisait échouer la création sans message. ## Les quatre scripts **`buildInvoicePdf.ts`** — valider une facture par l'API ne produit aucun PDF ; `builddoc` répond 403 à tout scope agent. Passe par l'interface, puis relit le fichier par l'API. **`setCompanyEmail.ts`** — le champ s'appelle `mail`, pas `MAIN_INFO_SOCIETE_MAIL`, malgré la constante qu'il alimente et la convention de tous ses voisins. **`paySocialCharge.ts`** — `recordSocialCharge.ts` laissait la charge impayée et rien n'enregistrait le règlement ; c'est ce trou qui rendait les deux échéances URSSAF invisibles. Piège consigné : ne pas chercher « payée » dans la page, **« ImPAYÉE » contient « payée »** — une première version déclarait ÉCHEC sur un règlement abouti, ce qui pousse à rejouer donc à créer un doublon. **`deleteInvoicePayment.ts`** — l'API ne sait pas supprimer un règlement. Deux verrous : tant que la facture est marquée payée le lien de suppression est **absent**, sans message ; et la confirmation est une modale jQuery dont les boutons n'ont ni `name` ni `value`. ## Plan de test - [x] Répétitions en bac à sable **rafraîchi depuis la production** avant chaque passage - [x] Juges pré-gate — un PASS, cinq BLOCK analysés et outrepassés avec preuve écrite - [x] Applications en production — toutes opérations ok - [x] Juges post-gate — **PASS sans dérive**, tous - [x] Relecture des objets : montants, échéances, notes, `desc`, `product_type` - [x] Réconciliation bancaire complète : **écart 0,00 sur Qonto et sur Wise** - [x] Contrôle des mentions obligatoires sur les **sept** PDF du dossier client ## Ce qui reste à l'opérateur **Le contrat cadre et son avenant** ne sont pas dans le dossier : aucun exemplaire signable n'existe: le contrat est un objet de l'ERP (`CT2601-0001`) sans pièce jointe. À joindre depuis ta source. **La décision n° 3 n'est pas signée.** Vérifié en lisant les PDF : la n° 1 porte une signature manuscrite, la n° 2 une signature **et** un paraphe en pied de ses deux pages. La n° 3 n'a ni l'une ni l'autre. La n° 2 traîne par ailleurs trois champs AcroForm vides laissés par l'outil de signature. **Restant dû par KissMetrics : 7 718,76 €**, dont **2 575,11 € échus** (FAC005). 🤖 Generated with [Claude Code](https://claude.com/claude-code)
arcodange changed title from WIP: feat(erp): cycle M4 KissMetrics, écarts bancaires comblés, clause de pénalités rétablie to feat(erp): cycle M4 KissMetrics, et les deux comptes bancaires ramenés au centime 2026-08-24 13:11:28 +02:00
arcodange added 4 commits 2026-08-24 13:13:17 +02:00
Deux passages gated en production, et l'outil qui manquait pour clore le dossier
client.

CYCLE M4 (2026-08-24-m4-et-ecarts). Cinq opérations : le tiers Anthropic PBC —
entité américaine, distincte d'Anthropic Ireland Limited — et sa facture de
90 EUR réglée le 19/07 ; le règlement Darnis de 262,20 EUR ; les deux factures
du cycle M4 (part fixe 2 500 USD → 2 140,45 EUR échéance 22/09, part différée
3 000 USD → 2 568,54 EUR échéance 23/11). Les trois écarts bancaires relevés
sont comblés ; Qonto tombe à 3 806,08 EUR.

Le juge pré-gate a bloqué : le règlement Darnis du 14/08 précède la facture
datée du 31/08. C'est un fait bancaire, pas une erreur de saisie — Darnis
facture en fin de mois — et adc-008 avait EXPRESSÉMENT prévu ce blocage et
autorisé le passage outre tracé. L'art. 289 du CGI qu'invoque le juge régit la
numérotation des factures ÉMISES, non l'ordre entre un paiement et sa facture ;
c'est la troisième fois de la session qu'il l'étend hors de son champ.

CLAUSE DE PÉNALITÉS (2026-08-24-clause-bilingue). Les factures M4 sont sorties
avec une clause AMPUTÉE : sans la traduction anglaise, sans la mention « Ces
stipulations sont des minima légaux d'ordre public auxquels il ne peut être
renoncé ». Détecté par le contrôle des mentions obligatoires sur les PDF —
avant tout envoi. La note publique est rétablie dans sa rédaction de référence,
à droit constant : aucun montant, aucune date, aucune ligne touchés.

Deux raisons de corriger plutôt que de laisser courir. La permanence des
méthodes (PCG art. 121-5, adc-011) : une clause légale identique doit être
rédigée identiquement, sans quoi la variation se lit comme une intention. Et le
fond : le destinataire est américain, c'est la version anglaise qui lui rend la
clause opposable en fait — et c'est sur elle que s'appuie la relance.

Le juge a bloqué là aussi, en supposant que la référence portait « ce montant ».
Il ne l'avait pas vérifié, et son propre residual risk demandait de le faire.
Vérification faite et consignée (02b-preuve-reference.txt) : FAC005 à FAC008
portent toutes « ce forfait », et la clause proposée leur est identique au
caractère près — 1283 car. Le finding était inversé.

test/buildInvoicePdf.ts. Valider une facture par l'API ne produit AUCUN PDF : le
fichier n'existe que si quelqu'un l'a demandé. `PUT /documents/builddoc` le
ferait mais répond 403 — ce droit n'est accordé à aucun scope agent. Le script
emprunte donc l'interface, puis relit le fichier par l'API : on ne croit pas la
page de retour, on vérifie que le PDF est déposé et lisible par un tiers.

Les deux juges post-gate passent sans dérive.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
L'en-tête de chaque facture portait `[email protected]` alors que
`static/config/company.json` porte `[email protected]`. La divergence
ne se voit nulle part dans l'ERP : elle ne s'est découverte qu'en relisant un PDF
destiné au client. Arbitrage de l'opérateur : l'adresse au nom de domaine de la
société est la bonne.

`GET /setup/company` répond 403 à tout scope agent (« open to admin users only »)
et aucune route REST n'écrit les constantes MAIN_INFO_SOCIETE_*. La fiche n'est
donc modifiable que par l'interface.

Deux pièges consignés dans le script. Le champ s'appelle simplement `mail` — pas
`MAIN_INFO_SOCIETE_MAIL`, malgré le nom de la constante qu'il alimente et malgré
la convention que suivent tous ses voisins du même formulaire. Et la page de
retour réaffiche la valeur soumise qu'elle ait été enregistrée ou non : le script
RECHARGE la page avant de vérifier.

Répété en bac à sable, puis appliqué en production. FAC009 et FAC010 régénérées.

FAC005, FAC007 et FAC008 gardent l'ancienne adresse, délibérément : elles ont été
émises sous celle-ci, et on ne réécrit pas un document daté pour le faire coller
à un état postérieur.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
L'opérateur a demandé si le versement de la semaine passée avait été pris en
compte. Il ne l'était pas — et la réconciliation menée en réponse a fait sortir
trois autres trous.

L'ENCAISSEMENT. KissMetrics a viré 2 164,75 EUR le 17/08 (Wise, réf.
VENDOR:DEV), soit 2 500,00 USD au taux du jour : la part fixe du cycle M4. Le
mouvement n'était pas enregistré, si bien que FAC009 a été émise le matin même
au taux du 24/08 (2 140,45 EUR) alors que le contrat arrête le montant dû « au
taux du jour du règlement ». La facture était fausse de 24,30 EUR, et déjà
payée.

Le précédent commandait la méthode : FAC008 avait été libellée 2 185,00 EUR,
exactement la somme reçue le 20/07, même schéma de règlement anticipé. Sur
arbitrage de l'opérateur, FAC009 est repassée en brouillon, portée à
2 164,75 EUR, revalidée sous le même numéro et la même date, puis adossée au
virement. Sa note reprend la rédaction de FAC008.

Le juge a bloqué en relevant que `last_main_doc` était présent — donc, selon
lui, facture émise. Il confond PDF PRODUIT et facture TRANSMISE : le PDF avait
été produit deux heures plus tôt par l'agent lui-même pour assembler le dossier,
et le message d'envoi est un brouillon jamais envoyé. Mais il a raison sur la
conséquence, et c'est le seul de ses findings de la journée qui apporte quelque
chose : le PDF sur disque devenait faux. Il a été régénéré aussitôt. Son second
finding — `emetteur` null — tombe : le champ est null sur les huit lignes
d'encaissement Wise antérieures ; le renseigner sur la seule ligne d'août
romprait la permanence des méthodes au lieu de la servir.

LES DEUX ÉCHÉANCES URSSAF. 493,00 EUR prélevés le 22/05 et 1 215,00 EUR le
17/08 n'étaient enregistrés ni l'un ni l'autre. Créés comme charges sociales —
pas comme factures fournisseur : l'URSSAF n'est pas un fournisseur — puis
réglés depuis Qonto.

test/paySocialCharge.ts comble un trou du chemin gated : recordSocialCharge.ts
crée la charge et la laisse impayée, et rien n'enregistrait le règlement. Tant
qu'il manque, le mouvement bancaire reste orphelin et le solde de l'ERP diverge
de celui de la banque — c'est ce qui laissait ces deux échéances invisibles.
Dolibarr n'expose aucune route REST pour les charges sociales, donc le pipeline
ne peut pas porter l'opération ; le script garde ce qu'il peut de sa discipline.

Trois pièges consignés dans le fichier, dont un qui a coûté une fausse alerte :
NE PAS chercher « payée » dans la page — « ImPAYÉE » contient « payée ». Une
première version déclarait ÉCHEC sur un règlement qui venait d'aboutir, ce qui
pousse à rejouer, donc à créer un doublon. On lit le montant restant dû.

LE RUNBOOK disait 646. C'est faux depuis adc-009 : dans une SARL à l'IS, ce que
la société verse à l'URSSAF pour son gérant majoritaire est une charge de
personnel, donc 641. Corrigé, avec la mention explicite que toute version
portant 646 est périmée. Ajouté aussi ce que la fiche de charge confirme à
l'écran — « Code comptable: Inconnu » : le type de charge ne pilote PAS le
compte sur ce déploiement, contrairement à ce que le runbook laissait croire.

Enfin l'exemple `--period 2026` du runbook était invalide : le script découpe la
valeur comme une date ISO et produisait `undefined/undefined/2026`, ce qui fait
échouer la création sans message.

Reste au tableau, documenté et non traité ici : six cashbacks Wise (11,13 EUR),
un remboursement Qonto (5,22 EUR), l'abonnement Anthropic du 19/08 (90,00 EUR,
reçu pas encore arrivé), et deux encaissements client sous-enregistrés — FAC004
et FAC006, 51,13 EUR reçus de plus que ce que l'ERP porte.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
Suite de la réconciliation ouverte par la question de l'opérateur. Après ce
passage, l'ERP et la banque disent le même chiffre sur les deux comptes :
Qonto 2 013,30 EUR et Wise 11 863,85 EUR, écart 0,00.

CE QUI A DÉBLOQUÉ LE RESTE. L'opérateur a établi que KissMetrics n'a JAMAIS reçu
la moindre facture — le client payait le forfait de 2 500 USD sans pièce. Rien
ne s'opposait donc à corriger des factures qu'on croyait entre ses mains.

FAC004 et FAC006 portaient toutes deux 2 145,92 EUR, le même montant repris tel
quel d'un cycle à l'autre, alors que la banque a reçu 2 147,00 EUR le 29/05 et
2 195,97 EUR le 25/06 : 2 500 USD à chaque fois, au taux du jour du paiement.
51,13 EUR d'encaissement manquaient aux livres. Leurs notes qualifiaient déjà
l'écart d'« écart de change » — défendable tant qu'on ne pouvait pas toucher aux
factures ; plus vrai maintenant qu'on le peut. Une facture, un règlement, une
ligne bancaire, le même chiffre.

RÉPARATION DE FAC009. `PUT /invoices/{id}/lines/{lid}` n'est PAS un PATCH : tout
champ absent du corps est remis à zéro. La correction appliquée ce matin ne
passait que subprice, pu_ht, qty et desc — `product_type` est donc retombé de 1
(service) à 0 (produit), faisant de FAC009 la seule ligne du registre typée
« produit » dans une société qui ne vend que des prestations et facture hors UE
sous l'art. 259-1° du CGI. Rétabli.

C'est le juge pré-gate qui l'a vu, sur la répétition de FAC004 et FAC006 — où le
même appel avait en plus effacé `desc` ENTIÈREMENT. Premier finding de la
journée qui apporte quelque chose de réel, et il aurait envoyé au client deux
factures sans désignation. Les charges de ligne sont désormais complètes.

test/deleteInvoicePayment.ts. Corriger une facture encaissée suppose de refaire
son règlement, et l'API REST ne sait pas le supprimer : `PUT
/invoices/{id}/payments` ne met à jour que son NUMÉRO. Deux verrous dans
l'interface, consignés dans le fichier : tant que la facture est marquée payée
le lien de suppression est simplement ABSENT — pas d'erreur, rien — il faut
d'abord la rouvrir ; et la confirmation est une boîte MODALE jQuery dont les
boutons n'ont ni name ni value, si bien qu'un sélecteur sur input[type=submit]
ne trouve rien et que la suppression n'a pas lieu, silencieusement. Sans
--payment, le script retrouve le règlement sur la fiche : coder en dur un
identifiant relevé en bac à sable est une façon commode de supprimer le mauvais.

ABONNEMENT ANTHROPIC D'AOÛT. 90,00 EUR du 19/08, reçu 2330-6710-2536 arrivé dans
books@ le 24/08. Second abonnement à usage interne, distinct du budget IA client.

CASHBACKS WISE — compte 768. Wise parle de « remise », mais le montant suit le
SOLDE et non les frais : 0,19 EUR sur ~510 EUR en mars, 4,97 EUR sur ~9 700 EUR
en août, soit ~0,5-0,6 % l'an, stable. C'est la rémunération d'un solde, donc un
produit financier. Le seul frais Wise de l'exercice est le forfait de 50 EUR du
26/01, sans rapport. Ni 763, qui vise les revenus de créances commerciales, ni
764, réservé aux valeurs mobilières de placement : 768.

RISTOURNE QONTO — compte 627 au crédit. L'opération est typée `qonto_fee` par la
banque elle-même, côté crédit : une remise sur un service reçu vient en
diminution de la charge, elle ne crée pas un produit.

PIÈGE CATALOGUÉ. bank-match.sh continuera d'afficher ces sept écritures en
BANK-ONLY : il ne rapproche que les RÈGLEMENTS de factures et ignore les
paiements divers. Les voir listées ne veut donc PAS dire qu'elles manquent —
c'est écrit dans known-patterns.json, sans quoi le prochain agent les
ressaisirait.

Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
arcodange force-pushed arcodange/changeset-m4 from c96deb5ad6 to 62fdd2325b 2026-08-24 13:13:17 +02:00 Compare
arcodange merged commit 58705fda56 into main 2026-08-24 13:13:44 +02:00
arcodange deleted branch arcodange/changeset-m4 2026-08-24 13:13:58 +02:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: arcodange-org/erp#96