Comment ça marche
Peppol en clair : ce qu’est une facture électronique structurée, et à quoi sert Peppol Generator.
Peppol, en bref
Peppol est un réseau européen qui permet d’envoyer des documents commerciaux (factures, commandes…) d’un logiciel à un autre, dans un format standard. Chaque entreprise se connecte au réseau via un point d’accès (Access Point).
Une facture Peppol n’est pas un PDF : c’est un fichier structuré (XML) que le logiciel du destinataire lit et intègre automatiquement, sans saisie manuelle.
Comment ça s’articule
De la norme à la livraison, quatre briques s’empilent.
La norme européenne — Elle définit QUELLES informations un document doit contenir (le vendeur, les lignes, la TVA…). C’est le socle sémantique.
Le profil Peppol — Une version d’EN 16931 restreinte à un usage précis (un « CIUS », pour Core Invoice Usage Specification), avec les règles métier précises que le réseau attend.
La syntaxe — COMMENT les données du document s’écrivent concrètement en XML : les balises et leur ordre imposé.
La livraison — Le document va de l’émetteur au destinataire, via leurs points d’accès. (Hors du périmètre de cet outil.)
Ce que fait cet outil
Il génère des fichiers Peppol XML d’exemple — factures et notes de crédit au format BIS Billing 3.0 (UBL 2.1) — utiles pour tester un système, illustrer un cas ou développer une intégration.
Saisie guidée, XML généré en temps réel, validation en continu, puis export.
L’outil s’arrête à la génération du fichier : l’envoyer sur le réseau Peppol n’est pas son rôle.
Les règles, et ce qu’on vérifie
Peppol définit des centaines de règles ; cet outil en vérifie une partie.
Ces règles viennent de deux sources :
- Les Business Rules de la norme européenne EN 16931 (BR-…).
- Les règles propres à Peppol (PEPPOL-EN16931-R…).
Sur le réseau, ces règles sont vérifiées de façon exhaustive par des Schematron officiels — des fichiers de validation exécutés par les points d’accès, à l’émission comme à la réception de chaque document.
Peppol Generator n’exécute pas ces Schematron. Il vérifie un sous-ensemble de ces règles, réécrites pour fonctionner dans le navigateur, pendant la saisie puis lors de la validation finale.
Un document validé ici n’est donc pas garanti accepté par le réseau : c’est le point d’accès qui en fait le contrôle complet.
Contrôlé à la saisie et à la validation : une erreur s’affiche si la règle n’est pas respectée.
- Les champs obligatoires : numéro, dates, devise, parties, pays, identifiants, désignation des lignes, …
- Au moins une ligne de facture (BR-16)
- Une référence acheteur ou de commande (R003)
- Au moins un identifiant pour le vendeur (BR-CO-26)
- Une échéance ou des conditions de paiement dès qu’un montant est dû (BR-CO-25)
- Un taux de TVA cohérent avec la catégorie (BR-S-05, BR-Z-05, …)
- L’IBAN présent pour un virement (BR-61)
- Le format de l’adresse e-mail de contact
- La quantité de base du prix strictement positive (R121)
- Si une ligne a une période, une date de début ou de fin doit être renseignée, voire les deux ; et la fin ne doit pas être avant le début (BR-CO-20, BR-30)
- Un motif d’exonération est présent dès qu’une ligne ne porte pas de TVA (BR-E-10, BR-AE-10, …)
Correct par construction : rien à corriger.
- Les totaux et les arrondis, dérivés des lignes (BR-CO-10 → 17, BR-DEC-…)
- Les valeurs issues de listes de codes — devise, pays, unité, catégorie de TVA, … — via des menus fermés (BR-CL-…)
- L’ordre des balises dans le XML, produit par un sérialiseur typé