Files
erp/test
arcodangeandClaude Opus 5 fcddcae47b 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]>
2026-08-24 13:12:34 +02:00
..
2025-08-08 17:57:56 +02:00

test — Dolibarr UI automation (Deno + Playwright)

A small Deno + Playwright POC that drives the Dolibarr admin UI in the fr-FR locale. Playwright fills the same forms a human admin would, so the automation works even where the REST API can't (e.g. generating an API key, which is encrypted with the instance's own DOLI_INSTANCE_UNIQUE_ID).

Layout

  • main.ts — original entrypoint (first install, company/display/module setup).
  • provisionSandbox.ts — entrypoint that provisions the erp-sandbox instance for the AI agent (enable REST API, create a write-scoped user, generate its API key).
  • scripts/login.ts — admin login / logout / whoami helpers.
  • scripts/forms.tsfillForm, toggleOnOff, CKEditor/ACE helpers.
  • scripts/admin/moduleSetup.tsconfigureModule, enableApiModule.
  • scripts/admin/userSetup.tscreateUser, assignRights, generateApiKey.

Configure

Copy .env.example to .env and fill it in. .env, *.key, and .ai_agent_sandbox.key are gitignored — never commit secrets.

cp .env.example .env

Lock the installer (after a fresh install via main.ts)

Dolibarr keeps its web installer reachable until an install.lock file exists. After a fresh install (the main.ts flow), create it in the target pod — for the sandbox:

kubectl -n erp-sandbox exec \
  "$(kubectl get pod -n erp-sandbox -l app.kubernetes.io/instance=erp-sandbox -o name)" -- \
  /bin/sh -c 'touch /var/www/documents/install.lock && chown www-data:www-data /var/www/documents/install.lock'

The path is the Dolibarr data root (/var/www/documents, a PVC) — that's where Dolibarr checks, and being on the PVC the lock persists across pod restarts. For prod, swap to -n erp -l app.kubernetes.io/instance=erp. A sandbox seeded from prod still needs this: the seed (see ../ops/sandbox/) copies the DB + documents/mycompany, not install.lock.

Provision the sandbox

Provisions erp-sandbox.arcodange.lab: enables the REST API module, creates the write-scoped ai_agent_sandbox user, grants it its write rights, and has Dolibarr generate the user's API key. The key is written to test/.ai_agent_sandbox.key (gitignored) — it is never printed.

cd test
deno run --allow-all provisionSandbox.ts

Populate .env from the erp-sandbox namespace secrets first. secretkv carries the app env (including DOLI_ADMIN_PASSWORD); vso-db-credentials carries the database password:

# Admin password (key DOLI_ADMIN_PASSWORD inside the secretkv secret)
kubectl get secret secretkv -n erp-sandbox \
  -o jsonpath='{.data.DOLI_ADMIN_PASSWORD}' | base64 -d

# Database password (key `password` inside vso-db-credentials)
kubectl get secret vso-db-credentials -n erp-sandbox \
  -o jsonpath='{.data.password}' | base64 -d

Set in .env:

DOLIBARR_ADDRESS=https://erp-sandbox.arcodange.lab
DOLI_ADMIN_LOGIN=admin
DOLI_ADMIN_PASSWORD="<from secretkv above>"
DOLI_DB_PASSWORD="<from vso-db-credentials above>"
# Optional — otherwise a random password is generated and only the API key emitted:
# AI_AGENT_SANDBOX_PASSWORD="<choose one>"

After it runs

The generated API key lands in test/.ai_agent_sandbox.key. Next step (not automated by this POC): load it into the dolibarr skill's sandbox config / Vault at kvv2/erp-sandbox/ai_agent.

Important

The sandbox Dolibarr is not installed/provisioned yet (empty DB, fresh install wizard). Until the install wizard has been completed against the sandbox, provisionSandbox.ts will not have a UI to drive, and the selectors in moduleSetup.ts / userSetup.ts are best-effort (Dolibarr 22 conventions, not verified live). Confirm them on the first real run.

Write rights granted

The ai_agent_sandbox user is created non-admin and granted (the authoritative list is WRITE_IDS in provisionSandbox.ts):

Module rights ids
facture lire=11, creer=12
societe lire=121, creer=122, client voir=262
societe contact lire=281, creer=282
fournisseur lire=1181, facture lire=1231, facture creer=1232
produit lire=31, creer=32
banque lire=111
user lire=251 — requis par le probe armé GET /users/info (checkpoint status/relink-env)