Corrige le bilan pour les numéros de comptes complétés (455100, 281000…)

[jcnoir]

Closes #65

Problème

Avec un plan de comptes aux numéros complétés à 6 chiffres ou plus — la forme
standard des exports FEC des logiciels comptables (455100, 281000/210000…) —
le gabarit bilan de generate-statements.js affiche un bilan faussement
déséquilibré alors que la balance est équilibrée. Détail et reproduction minimale
dans l'issue liée.

Correctif (volontairement minimal — 22+/4−, un seul fichier)

• Dettes : a === '455' → a.startsWith('455') (compte courant d'associé et
  ses subdivisions PCG, ex. 4551 « Principal ») ; même correction pour 487x (PCA).
• Amortissements/dépréciations : la règle historique d'appariement
  '28' + suffixe est conservée telle quelle ; les comptes 28x/29x qu'elle
  ne rattache à aucune ligne d'immobilisation sont désormais ajoutés sur leur
  propre ligne dans la colonne Amort./Déprec. — le total actif reste donc exact
  quel que soit le plan de comptes.
• Dépréciations 29x : incluses dans ce même traitement (elles étaient
  exclues de l'actif immobilisé sans jamais être réintégrées).

Tests effectués

1. Non-régression sur le journal d'exemple du repo — bilan.md généré
   avant/après le patch est byte-identique (diff vide) :

   $ node scripts/generate-statements.js   # avant puis après
   Actif  : 12 914,77 EUR / Passif : 12 914,77 EUR   (identiques)
   $ diff bilan-avant.md bilan-apres.md              (vide)
   

2. Reproduction minimale de l'issue (journal 5 lignes) :

   avant : Actif 1 300,00 / Passif 100,00 — ATTENTION : bilan desequilibre de 1 200,00 EUR
   après : Actif 1 200,00 / Passif 1 200,00 — Le bilan est equilibre.
   

3. Comptabilité réelle (SASU au régime réel, plan de comptes à 6 chiffres,
   33 écritures, 20 comptes) :

   avant : Actif 3 181,39 / Passif -1 047,98 — Ecart de 4 229,37 EUR
   après : Actif 3 039,91 / Passif 3 039,91 — Le bilan est equilibre.
   

   avec 455100 au passif (4 087,89) et l'amortissement 281000 (141,48)
   déduit de l'actif ; la balance générée concorde compte par compte avec celle
   du logiciel comptable d'origine.

4. Suite de tests du repo :

   $ npm run test:calc
   Deterministic calculation tests passed.
   

[romainsimon]

Merci, le problème de l’issue #65 est réel, mais cette implémentation ne le corrige pas complètement.

Le calcul actuel construit le compte d’amortissement avec :

'28' + acct.substring(1)

Pour l’immobilisation 210000, cela produit 2810000, et non 281000. Le compte n’est donc pas apparié : il est affiché sur une ligne séparée avec un brut vide et un net négatif. Le total peut rester arithmétiquement équilibré tout en produisant un bilan trompeur.

Deux autres cas restent incorrects :

• les comptes 29x ne sont jamais appariés à l’immobilisation correspondante ;
• si la balance contient un 28x/29x sans compte brut détecté, la condition if (immoAccounts.length > 0) fait disparaître entièrement cette dépréciation du bilan.

La suite npm run test:calc passe, mais elle ne couvre aucun de ces scénarios. Merci d’ajouter des fixtures automatisées pour 210000/281000, une subdivision du type 218300/281830, un compte 29x et le cas d’un 28x orphelin. L’issue #65 doit rester ouverte jusque-là.

[jcnoir]

Corrigé — les trois points :

• Appariement : par racine de compte (zéros finaux retirés, puis le 8/9 en 2e position) — 281000 est apparié à 210000, 281830 à 218300, 280000 à 200000, et 28183 à 2183 (comportement historique conservé : bilan du journal d'exemple byte-identique vs master). Plus de ligne séparée à brut vide pour un amortissement appariable.
• 29x : appariés par la même règle (291000 → 210000), cumulés avec les 28x dans la colonne Amort./Déprec. de l'immobilisation.
• Orphelins : le traitement des 28x/29x sans immobilisation brute est sorti du if (immoAccounts.length > 0) — la dépréciation reste visible sur sa propre ligne et comptée dans le total actif (avant : elle disparaissait et l'actif était surévalué d'autant).

L'appariement refuse les cas indécidables plutôt que de trancher arbitrairement : un 28/29 nu (non ventilé — impossible à répartir entre 20, 21…) et une racine ambiguë (21 et 210000 coexistant dans la même balance) restent sur leur propre ligne, total inchangé.

Six fixtures ajoutées à npm run test:calc : 210000/281000, 218300/281830, dépréciation 29x, 28x orphelin, 28 nu, collision de racines — chacune vérifiée en échec avant le correctif.

[jcnoir]

Et merci beaucoup pour ce projet, c'est très utile !