feat(erp): encaissement KissMetrics du 17/08, deux échéances URSSAF, règlement des charges sociales

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]>

.claude/skills/dolibarr-sandbox-write/RUNBOOK_charges_sociales.md

@@ -6,32 +6,41 @@ fois, elle doit en coûter deux minutes ensuite.
 
 ## Pourquoi ce n'est pas une facture fournisseur
 
-L'URSSAF n'est pas un fournisseur. Sa cotisation va au compte **646**
-(cotisations personnelles du dirigeant), pas au compte fournisseur — l'inscrire
-en facture fournisseur pollue le grand livre auxiliaire, les balances âgées et
-les états de dettes fournisseurs.
+L'URSSAF n'est pas un fournisseur. L'inscrire en facture fournisseur pollue le
+grand livre auxiliaire, les balances âgées et les états de dettes fournisseurs :
+elle se saisit comme **charge sociale**.
 
-**645 contre 646**, la distinction qui décide de tout :
+## Le compte : 641, et non 646
 
-| Compte | Pour qui |
-| --- | --- |
-| 645 | cotisations **patronales sur salaires** — suppose des salariés |
-| **646** | cotisations **personnelles du dirigeant TNS** |
+> [!IMPORTANT]
+> Ce runbook a d'abord dit **646**. C'était faux, et `adc-009` l'a tranché.
+> Si tu lis une version qui dit 646, elle est périmée.
 
-Arcodange n'a aucun salarié et Gabriel est gérant associé unique d'une SARLU,
-donc **TNS** : tout va en 646. Le compte 645 doit rester vide.
+| Compte | Pour qui | Arcodange |
+| --- | --- | --- |
+| 645x | cotisations **patronales sur salaires** — suppose des salariés | non : aucun salarié, l'opérateur n'est pas employeur |
+| 646 | cotisations de l'**exploitant individuel**, sociétés à l'**IR** | non : Arcodange est une SARL à l'**IS** |
+| **641**, sous-compte dédié | la société prend en charge les cotisations personnelles de son **gérant majoritaire** — c'est un complément de rémunération | **oui** |
 
-Dans Dolibarr, cela se pilote par le **type de charge**, jamais par une saisie
-manuelle du compte :
-
-- `Securite sociale (URSSAF / MSA)` → régime salarié → 645
-- **`Securite sociale des indépendants (URSSAF)`** → TNS → 646 ← **celui-ci**
+Le raisonnement tient en une phrase : dans une société à l'IS, ce que la société
+verse à l'URSSAF pour son gérant majoritaire n'est pas un prélèvement de
+l'exploitant, c'est une **charge de personnel**. D'où 641. Voir `adc-009` pour la
+démonstration complète, y compris la déductibilité intégrale de la CSG/CRDS pour
+la société — à ne pas confondre avec le sort de la CSG à l'impôt sur le revenu
+personnel du gérant (art. 62 CGI), qui est une autre question.
 
 > [!WARNING]
-> Le code comptable de chaque type vit dans **Configuration → Dictionnaires →
-> Types de charges sociales**. Vérifier une fois que la ligne « indépendants »
-> porte bien 646 : si elle porte autre chose, le bon type enverra quand même
-> l'écriture au mauvais compte. Non vérifié à ce jour.
+> **Le type de charge ne pilote PAS le compte sur ce déploiement.** Les lignes du
+> dictionnaire `Configuration → Dictionnaires → Types de charges sociales` sont
+> **sans code comptable** — vérifié. Choisir « Securite sociale des indépendants
+> (URSSAF) » ne suffit donc pas à envoyer l'écriture en 641 : l'affectation se
+> fait au moment du transfert en comptabilité, ou par le sous-compte porté sur
+> l'écriture. Ne pas croire qu'un bon type suffit.
+
+Le type retenu reste **`Securite sociale des indépendants (URSSAF)`** : le gérant
+associé unique d'une SARLU est TNS, affilié à la Sécurité sociale des
+indépendants, et non assimilé salarié. C'est exact sur le fond même si ça
+n'emporte aucune conséquence comptable automatique ici.
 
 ## La commande