arcodangeandClaude Opus 5
b745fdcb43
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]>
43 lines
2.2 KiB
Plaintext
43 lines
2.2 KiB
Plaintext
PREUVE — FAC009 n'a pas été transmise au client (2026-08-24)
|
|
|
|
FINDING 1 du juge : « last_main_doc présent, donc facture émise ».
|
|
Le juge confond PDF PRODUIT et facture TRANSMISE. Le PDF existe parce que
|
|
je l'ai produit ce matin pour assembler le dossier client ; il n'a été
|
|
envoyé à personne.
|
|
|
|
PDF sur disque : prospects/KissMetrics/relances/2026-08-24_dossier/FAC009-CL0001009.pdf
|
|
produit le : 24/08/2026 10:46:34
|
|
par : test/buildInvoicePdf.ts, dans la même session
|
|
|
|
message d'envoi : prospects/KissMetrics/relances/2026-08-24_slack_M4_et_FAC005.md
|
|
état : BROUILLON sur disque, jamais envoyé
|
|
déclaration de l'opérateur, session du 24/08 au matin :
|
|
« Je n'ai toujours pas envoyé le contrat et le dossier avec la facture d'août. »
|
|
|
|
Le dépôt 1_DOCUMENTS confirme que rien n'est parti : le dossier de relance
|
|
n'est même pas encore suivi en git.
|
|
?? prospects/KissMetrics/relances/
|
|
|
|
CONSÉQUENCE OPÉRATOIRE, que le juge a raison de faire apparaître : le PDF
|
|
sur disque porte 2 140,45 EUR et devient FAUX dès la correction appliquée.
|
|
Il DOIT être régénéré avant tout envoi. C'est acté comme suite obligatoire
|
|
de ce change-set, pas comme une intention.
|
|
|
|
FINDING 2 du juge : « emetteur null, attendu Kissmetrics Holdings Inc ».
|
|
Le champ est null sur TOUTES les lignes d'encaissement du compte Wise,
|
|
y compris les sept antérieures à toute intervention d'agent :
|
|
26/01/2026 50.00 EUR emetteur=None
|
|
05/02/2026 510.00 EUR emetteur=None
|
|
05/02/2026 510.00 EUR emetteur=None
|
|
12/03/2026 5100.00 EUR emetteur=None
|
|
20/04/2026 2550.00 EUR emetteur=None
|
|
29/05/2026 2145.92 EUR emetteur=None
|
|
25/06/2026 2145.92 EUR emetteur=None
|
|
20/07/2026 2185.00 EUR emetteur=None
|
|
17/08/2026 2164.75 EUR emetteur=None <- la ligne créée ici
|
|
|
|
L'API des règlements ne renseigne pas ce champ, et la méthode établie ne
|
|
l'a jamais renseigné. Le renseigner sur la seule ligne d'août romprait la
|
|
permanence des méthodes au lieu de la servir. L'émetteur est porté par le
|
|
num_payment (« VENDOR:DEV ») et par le commentaire du règlement.
|