L'opérateur a demandé « on ne peut pas emettre de facture en dollars ? ». Si, et
c'est même la bonne réponse ici — au point que la question avait déjà son créneau
au registre : adc-006 était Proposed depuis juillet, sa première question ouverte
étant mot pour mot « USD multicurrency invoices vs EUR-at-settlement ? ».
LE DÉFAUT. Le contrat fixe un prix EN DOLLARS — 2 500 USD en part fixe, 3 000 en
part différée — mais les factures étaient libellées en euros, contre-valeur figée
au taux du jour d'émission. Leur propre note l'avouait : « le montant
effectivement dû en euros sera arrêté au taux du jour du règlement ». Une facture
dont le montant affiché n'est pas le montant dû.
Le coût était réel et mesuré : FAC004, FAC006 et FAC009 ont dû être reprises le
même jour parce que leur contre-valeur ne correspondait pas aux virements reçus.
51,13 EUR d'encaissement manquaient aux livres.
Le client paie d'ailleurs en dollars : les euros reçus varient de 2 147,00 à
2 195,97 pour une prestation à prix fixe, signature d'un virement en devise
converti à l'arrivée par Wise, qui ne détient qu'un solde en euros.
LE DROIT. Une facture peut être libellée dans toute monnaie (CGI art. 289, II,
transposant la directive 2006/112 art. 230) ; seule la TVA à payer doit être
déterminée en euros, et il n'y en a pas — autoliquidation par un preneur hors UE.
Les LIVRES, eux, restent tenus en euros (C. com. art. L.123-22) : la
contre-valeur inscrite n'a pas bougé d'un centime.
PÉRIMÈTRE. Les quatre factures NON RÉGLÉES, aucune n'ayant été transmise :
FAC005, FAC007, FAC010, FAC011, toutes portées à 3 000,00 USD. Les quatre réglées
restent en euros — leur montant est exactement ce qui a été encaissé et rapproché
avec la banque. Chaque facture dit ainsi sa propre vérité.
CE QUE adc-006 DOIT CONSIGNER, ET CONSIGNE. adc-002 pose qu'« une facture validée
n'est jamais ajustée pour raison de change ». Trois l'ont pourtant été le 24/08.
L'opérateur l'a arbitré au motif qu'aucune n'avait été transmise au client, et
adc-006 supprime la situation qui rendait l'arbitrage nécessaire : une facture en
dollars n'a aucune raison d'être ajustée, son montant ne dépendant d'aucun taux.
adc-002 s'en trouve restreinte, pas abrogée — les écarts de change continuent
d'aller en 766 et 666, et deviennent le cas normal au lieu de l'exception.
test/setInvoiceCurrency.ts. Deux pièges consignés. `PUT /invoices/{id}` ACCEPTE
`multicurrency_code`, répond 200, et n'applique rien : seule l'interface change
la devise. Et ce changement ABÎME la ligne — Dolibarr recalcule le montant en
devise depuis les euros et le taux du dictionnaire, puis le changement de taux
fige la devise et recalcule les euros, si bien que la contre-valeur dérive. Le
script réunit donc les deux opérations, réécrit la ligne ENTIÈRE (le PUT n'est
pas un PATCH) et refuse si la contre-valeur euro a bougé d'un centime.
Le juge a relevé, à raison, que le titre du change-set débordait de son contenu :
le passage en devise est fait par le script, en amont. Accepté et consigné au
gate ; le manifeste n'a pas été retouché pour ne pas rompre l'empreinte sur
laquelle le gate est scellé. Son residual risk — vérifier la multidevise en
production — est honoré. Juge post-gate PASS sans dérive.
Co-Authored-By: Claude Opus 5 (1M context) <[email protected]>
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 theerp-sandboxinstance 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.ts—fillForm,toggleOnOff, CKEditor/ACE helpers.scripts/admin/moduleSetup.ts—configureModule,enableApiModule.scripts/admin/userSetup.ts—createUser,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.tswill not have a UI to drive, and the selectors inmoduleSetup.ts/userSetup.tsare 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) |