arcodangeandClaude Opus 5
01441df5ea
L'opérateur a demandé « on ne peut pas emettre de facture en dollars ? ». Si, et
c'est même la bonne réponse ici — au point que la question avait déjà son créneau
au registre : adc-006 était Proposed depuis juillet, sa première question ouverte
étant mot pour mot « USD multicurrency invoices vs EUR-at-settlement ? ».
LE DÉFAUT. Le contrat fixe un prix EN DOLLARS — 2 500 USD en part fixe, 3 000 en
part différée — mais les factures étaient libellées en euros, contre-valeur figée
au taux du jour d'émission. Leur propre note l'avouait : « le montant
effectivement dû en euros sera arrêté au taux du jour du règlement ». Une facture
dont le montant affiché n'est pas le montant dû.
Le coût était réel et mesuré : FAC004, FAC006 et FAC009 ont dû être reprises le
même jour parce que leur contre-valeur ne correspondait pas aux virements reçus.
51,13 EUR d'encaissement manquaient aux livres.
Le client paie d'ailleurs en dollars : les euros reçus varient de 2 147,00 à
2 195,97 pour une prestation à prix fixe, signature d'un virement en devise
converti à l'arrivée par Wise, qui ne détient qu'un solde en euros.
LE DROIT. Une facture peut être libellée dans toute monnaie (CGI art. 289, II,
transposant la directive 2006/112 art. 230) ; seule la TVA à payer doit être
déterminée en euros, et il n'y en a pas — autoliquidation par un preneur hors UE.
Les LIVRES, eux, restent tenus en euros (C. com. art. L.123-22) : la
contre-valeur inscrite n'a pas bougé d'un centime.
PÉRIMÈTRE. Les quatre factures NON RÉGLÉES, aucune n'ayant été transmise :
FAC005, FAC007, FAC010, FAC011, toutes portées à 3 000,00 USD. Les quatre réglées
restent en euros — leur montant est exactement ce qui a été encaissé et rapproché
avec la banque. Chaque facture dit ainsi sa propre vérité.
CE QUE adc-006 DOIT CONSIGNER, ET CONSIGNE. adc-002 pose qu'« une facture validée
n'est jamais ajustée pour raison de change ». Trois l'ont pourtant été le 24/08.
L'opérateur l'a arbitré au motif qu'aucune n'avait été transmise au client, et
adc-006 supprime la situation qui rendait l'arbitrage nécessaire : une facture en
dollars n'a aucune raison d'être ajustée, son montant ne dépendant d'aucun taux.
adc-002 s'en trouve restreinte, pas abrogée — les écarts de change continuent
d'aller en 766 et 666, et deviennent le cas normal au lieu de l'exception.
test/setInvoiceCurrency.ts. Deux pièges consignés. `PUT /invoices/{id}` ACCEPTE
`multicurrency_code`, répond 200, et n'applique rien : seule l'interface change
la devise. Et ce changement ABÎME la ligne — Dolibarr recalcule le montant en
devise depuis les euros et le taux du dictionnaire, puis le changement de taux
fige la devise et recalcule les euros, si bien que la contre-valeur dérive. Le
script réunit donc les deux opérations, réécrit la ligne ENTIÈRE (le PUT n'est
pas un PATCH) et refuse si la contre-valeur euro a bougé d'un centime.
Le juge a relevé, à raison, que le titre du change-set débordait de son contenu :
le passage en devise est fait par le script, en amont. Accepté et consigné au
gate ; le manifeste n'a pas été retouché pour ne pas rompre l'empreinte sur
laquelle le gate est scellé. Son residual risk — vérifier la multidevise en
production — est honoré. Juge post-gate PASS sans dérive.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
fleet/profile/ — fiscal profile, compliance calendar, ADC register
The machine-readable business-rules surface the fleet reads (T10 TVA preparation, T03 VAT ventilation, T11 calendar & reminders): prompts stay thin and rule-free (fleet/README.md); the rules live here, dated and justified. Shipped by erp#54 per the PRD document surface and ADC framework.
Layout
| File | Role |
|---|---|
fiscal.yaml |
fiscal profile: entity, VAT position, rules — regime, VAT treatments, bookkeeping methods |
fiscal.schema.json |
JSON Schema for fiscal.yaml |
calendar.yaml |
compliance calendar: dated obligations the T11 reminder loop (erp#60) reads |
calendar.schema.json |
JSON Schema for calendar.yaml |
scripts/validate.py |
stdlib-only validator: schema + referential integrity (rule → ADC) |
decisions/ |
the ADC register (accounting decision records): adc-template.md + adc-NNN-<slug>.md |
The rule contract
Every fiscal.yaml rule carries:
effective_from/effective_until— dated validity (nulluntil = in force until superseded);decision: adc-NNN— the record indecisions/that justifies it.
So the chain écriture → règle → ADC → base légale resolves in four hops,
identically every time (PRD compliance § ADC rule 2, challenge C6). Dates in
both YAML files cite their source anchor as an inline comment (PRD <leaf> § <anchor>, verified against factory origin/main).
The ADC register (decisions/)
MADR-lite + accounting fields — see adc-template.md.
Frontmatter is machine-parsed (id, status, decided, effective dates,
supersedes/superseded_by); the body carries Context (fait générateur),
Decision, Base légale & doctrine, Alternatives rejected, Consequences,
QA & validation, References.
Status flow: Proposed → Accepted → Superseded-by-NNN, with four rules (PRD compliance § ADC):
- Immutable once Accepted (merged on main) — supersede, never edit (permanence des méthodes, PCG art. 121-5).
- Every fiscal.yaml rule cites its ADC — enforced by
scripts/validate.py, which also refuses a rule citing a non-Accepted record. - The annexe writes itself at close from the records Accepted and in force during the exercice.
- Proposed ADCs are the expert-comptable agenda. Agents draft, the operator Accepts — never the reverse.
Seed state: adc-001…005 are Accepted as formalizations of decisions the operator already made in practice (their sanity read is the erp#54 human gate — pre-merge amendments are draft edits, not supersedes); adc-006/adc-007 are Proposed stubs (retainer currency → erp#53; capital path → erp#51).
Validation
python3 fleet/profile/scripts/validate.py
Stdlib-only (no PyYAML, no jsonschema — runs anywhere, CI-able). It checks:
both YAML files against their schemas; every rule's decision resolves to
exactly one existing, Accepted ADC; unique ids; effective_from <= effective_until; calendar entries carry exactly one of due|recurrence
(unless pending-definition/conditional); ADC frontmatter/section hygiene.
Exit 0 = pass; warnings list what awaits operator verification
(month-precision dates, estimated entries).
To stay parseable, both YAML files are written in a strict subset: block
maps/lists, single-line scalars, one-line [flow] lists of scalars,
comments — no anchors, no multi-line scalars, no nested flow.
Calendar date precision: YYYY-MM-DD = exact; YYYY-MM = month window — the
source gives no day; verify on the authority's notice, never invent one.
Mutation policy
Changes arrive as PRs only — the T12 regulatory watch proposes a diff (what changed, source links, effective dates); a human reviews and merges (PRD task-inventory § T11 guardrail: "the calendar file is reviewed like code"; § T12: "the watch proposes, the human adopts"). Calendar entries sourced from mail content are human-confirmed (mail is untrusted input). No agent edits these files directly. A rule change moves its ADC in the same PR (supersede, never edit), and a schema change moves the validator with it — the repo-wide same-change freshness rule.
Facts not corroborated by the PRD
Flagged here honestly (and inline where used) — the PRD wins on conflict; these await operator/expert verification:
- SIREN 999657455 — from erp#54 + agent memory
arcodange-tva-fiscal; no PRD leaf states it. - Exact incorporation day — PRD says "mid-January 2026" only; rules use a
conservative
2026-01-01exercice-start bound. - July 2026 acompte exact day — PRD gives the month only (T10 trigger).
- CFE exact day + creation-year exoneration / initial 1447-C declaration — PRD says "December" only; the rest is to verify with the SIE.
- CA3 July/October/January windows — only the April window is PRD-anchored (roadmap, 2027-04-20); the others come from the erp#54 issue text.
- TVA credit amount (~223–267 EUR) — ERP reads (skill + memory); the PRD only says "in TVA credit — verify, don't assume".
- URSSAF échéancier cadence/nature — one known debit (2026-05-22, 493.00 EUR, erp#57); the PRD's "payroll dormant" assumption is under revisit in erp#57.
- BOI-BIC-CHG-20-30-10 tolerance cite (adc-003) and CCA formalities (adc-005) — general doctrine, queued for the expert-comptable.