Doctrine posée par l'opérateur le 13/08 : si une donnée fautive est déjà en
production et sans incidence insurmontable sur l'exercice, on ne force pas la
correction — on annote l'objet. Le registre reste append-only et l'écriture
n'est pas maquillée.
La règle est juste, son canal habituel est fermé ici : sur ce déploiement,
AUCUNE écriture sur une charge sociale n'aboutit — ni la date, ni le montant,
NI MÊME LA NOTE PUBLIQUE. Toutes passent par le même UPDATE et échouent sur
« multiple assignments to same column fk_user_modif » (erp#87).
Ce qui fonctionne est un autre chemin : attacher un document, le téléversement
n'étant pas un UPDATE sur l'objet. La charge n°1 (URSSAF 1re échéance, 493 EUR)
porte désormais deux pièces : l'appel de cotisations officiel, et une note de
correction expliquant que le 22/05 est la date du PRÉLÈVEMENT quand l'échéance
officielle est le 05/05 — 17 jours de retard, écart resté dans le même mois et
le même exercice.
annotateObject.ts écrit la note publique d'un objet et REFUSE explicitement
quand le bug la bloque. Ce garde-fou vient d'un faux positif qui a bien failli
passer : la page de retour de Dolibarr ré-affiche le texte soumis, si bien qu'un
contrôle « le texte est là » réussit sur un enregistrement qui n'a jamais eu
lieu. J'ai d'abord conclu que le chemin des notes échappait au bug — il ne lui
échappe pas. Relire l'objet, jamais la page de retour. Le script reste utile sur
les objets non affectés par erp#87.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
arcodangeandClaude Opus 5
775daacd18