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]>
ERP
CLI — bin/arcodange
Read-only operational CLI for the Arcodange Dolibarr at erp.arcodange.lab. One entry point, subcommands per domain:
bin/arcodange ping # Dolibarr version + liveness
bin/arcodange whoami # confirm auth as ai_agent
bin/arcodange invoice list # KissMetrics invoices with payment state
bin/arcodange invoice audit 12 # JSON facts + PDF mandatory-mention audit
bin/arcodange payments state # per-invoice TTC vs payments reconciliation
bin/arcodange payments timeline --year 2026 # cash receipts with cumulative balance
bin/arcodange tva summary # CA3-ready collectée − déductible per month
bin/arcodange thirdparty audit-all # completeness audit, country-aware
bin/arcodange templates inspect 1 # recurring template health (frequency, next fire, …)
bin/arcodange snapshot --out /tmp/erp.json # full state dump with content_hash
bin/arcodange help # full command tree
Read-only by design. The underlying API key (ai_agent) has no write permissions; corrections go through the Dolibarr UI.
Credentials. Reads .claude/skills/dolibarr/.env (mode 600, gitignored). Setup instructions: .claude/skills/dolibarr/README.md.
Source of behaviour. Each subcommand delegates to a script under .claude/skills/<skill>/scripts/. The skills' SKILL.md files document the business logic and are also discoverable by Claude Code via skill triggers.
Dolibarr
Premiers démarrages
Si l'application log au démarrage l'erreur suivante:
Importing custom SQL from update_table_ownership.sql ...
sed: couldn't open temporary file /var/www/scripts/before-starting.d/sedwHcRlQ: Read-only file system
Il faudra prendre la main du shell du pod et executer:
kubectl exec -n erp `kubectl get pod -n erp -l app.kubernetes.io/name=erp -o=name` -c erp -- sh -c 'PGPASSWORD=${DOLI_DB_PASSWORD} psql -U ${DOLI_DB_USER} -h ${DOLI_DB_HOST} -p ${DOLI_DB_HOST_PORT} ${DOLI_DB_NAME} \
-f /var/www/scripts/before-starting.d/update_table_ownership.sql'
Sous peine de ne plus avoir les droits de consulter la base de données une fois les crédentials mis à jour par vault. Dans ce cas executer la commande mais avec les credentials d'admin postgres.