arcodangeandClaude Opus 5
8fe740896b
L'appel de cotisations URSSAF 2026 (PDF officiel du 09/07) a permis de qualifier l'imputation, restée explicitement ouverte dans le runbook. La réponse contredit ce qui y était écrit. Le compte 646 est réservé à l'entreprise individuelle et aux sociétés à l'IR : il ne s'applique pas à une SARL à l'IS. La prise en charge par la société des cotisations de son gérant majoritaire est un complément de rémunération — compte 641, sous-compte dédié, déductible. 645 et 631/633 restent vides : aucun salarié, l'opérateur n'est pas employeur. Piège corrigé au passage : la mention « CSG déductible fiscalement » de l'appel vise l'IR personnel du gérant (art. 62 CGI), pas l'IS de la société. Pour la SARL la CSG/CRDS est intégralement déductible — la réintégration annoncée dans un premier temps était un raisonnement d'entreprise individuelle mal transposé. Le runbook affirmait aussi que le type de charge Dolibarr pilotait le compte. Faux : la colonne « Code comptable » du dictionnaire est vide pour tous les types, TAXSSI compris (vérifié cellule par cellule), et le module comptabilité n'est pas déployé. La carte affiche « Code comptable: Inconnu ». L'ERP porte les faits, pas les écritures. Deux corrections de fond sur les dates et les montants : - les dates de l'échéancier sont des dates d'ÉCHÉANCE (le 5 du mois), pas de débit bancaire — 05/05 et non 22/05, ce qui rend visible le retard de 17 jours ; - les 3 041 EUR sont PROVISOIRES, assis sur un forfait début d'activité, et seront régularisés. L'assiette est la rémunération du gérant, jamais le CA. Enfin, découvert en tentant la correction de date : aucune charge sociale n'est modifiable sur ce déploiement. Toute édition, même du seul montant, échoue sur « multiple assignments to same column fk_user_modif » — ChargeSociales::update() génère un UPDATE que PostgreSQL rejette (42601) là où MySQL passe. Le défaut est propre à cet objet ; la mise à jour d'un tiers via REST fonctionne. La date doit donc être juste à la création. updateSocialCharge.ts conserve le cas de reproduction et diagnostique l'erreur au lieu de la subir. Le justificatif officiel est attaché aux trois charges de production. 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.