[FEATURE]: Instance de démonstration et de test Factur-e pour développeurs PA

bruno.d2b commented

2026-05-31 08:50:52 +02:00

Member

Description

Mettre à disposition dans le dépôt une instance Factur-e autoportée, que les
développeurs de PA peuvent monter en local (Docker Compose) pour valider leur
plateforme contre un émetteur/récepteur de factures EN 16931 + EXTENDED-CTC-FR.
Statut & évolution : Factur-e intègre aujourd'hui une connexion à SuperPDP
publiée ici est donc à usage de démonstration.
Elle permet en outre de réaliser un test BDD prototype déclenchant l'émission d'une
facture via le backend Factur-e (API directe en Bearer). Connexe aux besoins de
tests de conformité PA (cf. #27, #24).
Le développement du connecteur EsaLink prendra en compte la modélisation décrite
dans le module pdpconnectfr de Dolibarr. La cible est de connecter Factur-E sur
l'API PA_Communautaire dès sa définition.

Exemple

cd factur-e && ./init.sh → 5 services Docker healthy + 2 comptes pré-seedés
(Burger Queen 000000002 / Tricatel 000000001). On émet une facture
Burger Queen → Tricatel, observable côté PA en développement ; réception
symétrique ; statuts CDAR récupérés en polling.
L'API est pilotable en Authorization: Bearer (openapi.yaml, OpenAPI 3.1) :
on peut écrire un scénario BDD prototype (Gherkin) déclenchant POST /api/invoices
sur le backend Factur-E. Détails : factur-e/README.md.

## Description - Mettre à disposition dans le dépôt une instance Factur-e autoportée, que les développeurs de PA peuvent monter en local (Docker Compose) pour valider leur plateforme contre un émetteur/récepteur de factures EN 16931 + EXTENDED-CTC-FR. - Statut & évolution : Factur-e intègre aujourd'hui une connexion à SuperPDP publiée ici est donc à usage de démonstration. - Elle permet en outre de réaliser un test BDD prototype déclenchant l'émission d'une facture via le backend Factur-e (API directe en Bearer). Connexe aux besoins de tests de conformité PA (cf. #27, #24). - Le développement du connecteur EsaLink prendra en compte la modélisation décrite dans le module pdpconnectfr de Dolibarr. La cible est de connecter Factur-E sur l'API PA_Communautaire dès sa définition. ## Exemple - `cd factur-e && ./init.sh` → 5 services Docker healthy + 2 comptes pré-seedés (Burger Queen `000000002` / Tricatel `000000001`). On émet une facture Burger Queen → Tricatel, observable côté PA en développement ; réception symétrique ; statuts CDAR récupérés en polling. - L'API est pilotable en `Authorization: Bearer` (`openapi.yaml`, OpenAPI 3.1) : on peut écrire un scénario BDD prototype (Gherkin) déclenchant `POST /api/invoices` sur le backend Factur-E. Détails : `factur-e/README.md`.

bruno.d2b referenced this issue from a pull request that will close it,

2026-05-31 09:05:26 +02:00

Ajout d'une instance de démonstration/test Factur-e pour développeurs PA (Issue #44) #45

bruno.d2b added a new dependency

2026-05-31 09:06:41 +02:00

#45 Ajout d'une instance de démonstration/test Factur-e pour développeurs PA (Issue #44)

bruno.d2b commented

2026-06-06 06:53:14 +02:00

Author

Member

Correction du seed des comptes de tests (bug detecté lors de la demo)

Pour éviter que la recherche sur l'annuaire SuperPDP soit en erreur du fait du numero Sirene factice 00000000x, je mets à jour le cache applicatif de l'annuaire
Un TTL de 7 jours faisait expirer l'entrée du cash. Je l'ai passé à 100 ans ...

Correction du seed des comptes de tests (bug detecté lors de la demo) - Pour éviter que la recherche sur l'annuaire SuperPDP soit en erreur du fait du numero Sirene factice 00000000x, je mets à jour le cache applicatif de l'annuaire - Un TTL de 7 jours faisait expirer l'entrée du cash. Je l'ai passé à 100 ans ...

bruno.d2b commented

2026-06-18 10:04:29 +02:00

Author

Member

4.6 Générer et déposer une facture de test (générateur in-container)

Plutôt que de fabriquer un corps POST /api/invoices à la main (§4.5), un
générateur de factures (le harness) est livré avec l'instance. Il déroule
un cycle complet en pilotant l'API en Bearer : récupère un token via
/__dev/quick-login, charge une facture du corpus via /__dev/emission-fixtures,
l'émet (POST /api/invoices → dépôt PA réel), puis poll la fiche
jusqu'à observer ≥ 1 statut CDAR réel renvoyé par la PA (ou timeout). Idéal
pour produire un dépôt vers votre PA en développement en une commande.

Le générateur est un script Node 22 (fetch natif, aucune dépendance). Pas
besoin de Node sur votre poste : on l'exécute dans le conteneur api (qui
embarque Node 22). Le harness est extrait sur l'hôte dans runtime/src/scripts/
par init.sh ; on le copie dans le conteneur puis on le lance :

# 1. Copier le générateur dans le conteneur api (à refaire après un restart du
#    conteneur : /tmp y est éphémère).
docker compose -f docker-compose.yml cp runtime/src/scripts api:/tmp/harness

# 2. Le lancer (base-url = API interne au conteneur sur le port 3001, PAS 47281).
docker compose -f docker-compose.yml exec api \
  node /tmp/harness/dev/harness-pa.mjs \
  --base-url=http://localhost:3001 --email=bq@dev.factur-e.local

Pré-requis (sinon faux négatif) :

La stack tourne (./init.sh) et le compte émetteur Burger Queen
(bq@dev.factur-e.local) est connecté à SuperPDP en OAuth réel (§4.2 →
Connexion Plateforme Agréée). Sans cette connexion, POST /api/invoices
renvoie 503 et le harness sort un verdict clair « connecter la PA d'abord ».
La récupération des CDAR dépend du polling serveur (défaut 1 min dans
cet outil, cf. §4.4) — le round-trip prend donc jusqu'à ~1 min.

Options utiles :

--fixture=<id> choisit la facture du corpus (défaut fx-380-base-iban). La
liste des ids disponibles :
```
curl -s http://localhost:47281/__dev/emission-fixtures | jq
```
--email=<compte> cible un autre compte seedé (tricatel@dev.factur-e.local).
--timeout=<s> (défaut 300) / --tick=<s> (défaut 5) bornent le poll CDAR.

Le numéro de facture est rendu unique à chaque run (anti-collision sandbox
SuperPDP partagée). Code de sortie : 0 si le round-trip est complet (dépôt
accepté + ≥ 1 CDAR réel), 1 sinon — directement exploitable en script/CI côté
PA.

### 4.6 Générer et déposer une facture de test (générateur in-container) Plutôt que de fabriquer un corps `POST /api/invoices` à la main (§4.5), un **générateur de factures** (le *harness*) est livré avec l'instance. Il déroule un **cycle complet** en pilotant l'API en Bearer : récupère un token via `/__dev/quick-login`, charge une facture du corpus via `/__dev/emission-fixtures`, l'**émet** (`POST /api/invoices` → dépôt PA réel), puis **poll** la fiche jusqu'à observer ≥ 1 statut **CDAR réel** renvoyé par la PA (ou timeout). Idéal pour produire un dépôt vers votre PA en développement **en une commande**. Le générateur est un script **Node 22** (`fetch` natif, aucune dépendance). Pas besoin de Node sur votre poste : on l'exécute **dans le conteneur `api`** (qui embarque Node 22). Le harness est extrait sur l'hôte dans `runtime/src/scripts/` par `init.sh` ; on le copie dans le conteneur puis on le lance : ```bash # 1. Copier le générateur dans le conteneur api (à refaire après un restart du # conteneur : /tmp y est éphémère). docker compose -f docker-compose.yml cp runtime/src/scripts api:/tmp/harness # 2. Le lancer (base-url = API interne au conteneur sur le port 3001, PAS 47281). docker compose -f docker-compose.yml exec api \ node /tmp/harness/dev/harness-pa.mjs \ --base-url=http://localhost:3001 --email=bq@dev.factur-e.local ``` **Pré-requis (sinon faux négatif) :** - La stack tourne (`./init.sh`) et le compte émetteur **Burger Queen** (`bq@dev.factur-e.local`) est **connecté à SuperPDP en OAuth réel** (§4.2 → *Connexion Plateforme Agréée*). Sans cette connexion, `POST /api/invoices` renvoie **503** et le harness sort un verdict clair « connecter la PA d'abord ». - La récupération des CDAR dépend du **polling serveur** (défaut **1 min** dans cet outil, cf. §4.4) — le round-trip prend donc jusqu'à ~1 min. **Options utiles :** - `--fixture=<id>` choisit la facture du corpus (défaut `fx-380-base-iban`). La liste des ids disponibles : ```bash curl -s http://localhost:47281/__dev/emission-fixtures | jq ``` - `--email=<compte>` cible un autre compte seedé (`tricatel@dev.factur-e.local`). - `--timeout=<s>` (défaut 300) / `--tick=<s>` (défaut 5) bornent le poll CDAR. Le numéro de facture est **rendu unique à chaque run** (anti-collision sandbox SuperPDP partagée). **Code de sortie** : `0` si le round-trip est complet (dépôt accepté + ≥ 1 CDAR réel), `1` sinon — directement exploitable en script/CI côté PA.

bruno.d2b commented

2026-07-09 19:32:10 +02:00

Author

Member

Je suis en train de faire l'intégration EsaLink sur Factur-e, j'en ai profité pour faire (faire) deux schémas, le premier "SuperPDP Propriétaire versus SuperPDP AFNOR". Le deuxième la cible pour Factur-e.

Je mets le mermaid et les png.

@teddy.morel

Je suis en train de faire l'intégration EsaLink sur Factur-e, j'en ai profité pour faire (faire) deux schémas, le premier "SuperPDP Propriétaire versus SuperPDP AFNOR". Le deuxième la cible pour Factur-e. Je mets le mermaid et les png. @teddy.morel

schemas.md

6.4 KiB

Capture d’écran 2026-07-09 à 19.35.35.png

274 KiB

Capture d’écran 2026-07-09 à 19.33.38.png

234 KiB