PEPPOL-EN16931-R010 : Ajouter l'adresse électronique de l'acheteur

La réponse courte

PEPPOL-EN16931-R010 échoue lorsque la partie acheteur, cac:AccountingCustomerParty/cac:Party, ne contient aucun cbc:EndpointID. Ajoutez-y l'adresse électronique de l'acheteur, comme premier enfant de cac:Party, avec un attribut schemeID pour le schéma sous lequel elle est émise.

La valeur doit venir de l'acheteur. C'est son adresse : elle a donc sa place dans les données de référence du client, à côté de son nom et de son numéro de TVA, et non dans une valeur par défaut appliquée par l'émetteur.

Ce que la règle vérifie

Le test porte sur l'existence d'un enfant cbc:EndpointID dans le cac:Party de l'acheteur. Rien d'autre n'est examiné sur l'élément : ni son texte, ni son schemeID.

Un cbc:EndpointID vide satisfait donc cette règle et échoue ailleurs. Avec schemeID="0088" et sans contenu, le document signale PEPPOL-EN16931-R008 pour l'élément vide et PEPPOL-COMMON-R040 pour le format GLN, et PEPPOL-EN16931-R010 reste muette.

Le côté vendeur relève d'une règle distincte, PEPPOL-EN16931-R020. Supprimer les deux adresses produit les deux constats ; la présence de l'une ne satisfait jamais la règle de l'autre.

Comment une intégration en arrive là

Causes possibles, déduites de la forme de la règle et non d'une utilisation mesurée :

• Les fiches clients ont été créées avant la mise en place de l'envoi par Peppol et n'ont pas de champ, ou pas de valeur, pour une adresse électronique.
• Le point d'accès connaît l'adresse et l'utilise pour le routage, mais elle n'est jamais transmise au composant qui construit le XML.
• L'acheteur n'est identifié que par cac:PartyIdentification/cbc:ID ou par un numéro d'immatriculation légale, ce que le mapping supposait suffisant.
• Un modèle partagé avec une sortie uniquement EN 16931 omet l'élément, car le modèle de base ne l'exige pas.

Comment corriger le document

1. Obtenez l'adresse électronique de l'acheteur et son schéma auprès de l'acheteur, ou de l'étape d'intégration qui enregistre la manière dont il reçoit les documents.
2. Stockez les deux parties, code de schéma et identifiant, sur la fiche client. Un champ de texte libre qui les mélange, comme 0088:7300010000001, doit être scindé avant de pouvoir être mappé.
3. Émettez cbc:EndpointID comme premier enfant de cac:AccountingCustomerParty/cac:Party, avec l'identifiant comme contenu et le code de schéma dans schemeID. Placé après cac:PostalAddress, l'élément enfreint l'ordre des enfants UBL et l'étape XSD rejette le document avant que cette règle ne s'exécute.
4. Refusez de construire le document lorsque l'acheteur n'a pas d'adresse électronique, au lieu d'émettre un élément vide ou une valeur provisoire.

Valider votre facture corrigée

Avant et après

Ce sont des extraits, pas des documents complets. Les documents synthétiques complets dont ils proviennent sont liés ci-dessous.

Fragment de la facture en échec : l'élément Party de l'acheteur n'a pas d'EndpointID

<cac:AccountingCustomerParty>
  <cac:Party>
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

Fragment de la facture corrigée : l'élément Party de l'acheteur commence par son EndpointID

<cac:AccountingCustomerParty>
  <cac:Party>
    <cbc:EndpointID schemeID="0088">7300010000001</cbc:EndpointID>
    <cac:PostalAddress>
      <cbc:StreetName>2 Example Street</cbc:StreetName>
      <!-- rest of the address omitted from this fragment -->
    </cac:PostalAddress>
    <!-- legal entity omitted from this fragment -->
  </cac:Party>
</cac:AccountingCustomerParty>

La seule différence est la ligne cbc:EndpointID dans le cac:Party de l'acheteur, présente dans le fichier corrigé et absente du fichier en échec. Le document en échec ne signale que PEPPOL-EN16931-R010, et seulement à l'étape Peppol : la règle EN 16931 relative à l'adresse de l'acheteur, BR-63, teste le schemeID d'un élément existant et n'a rien à tester ici. La valeur de l'exemple est un GLN d'exemple.

Où la règle s'applique

• S'applique aux documents UBL Invoice et CreditNote. La partie acheteur a le même chemin dans les deux, et un avoir sans l'élément signale le même constat unique.
• L'exigence est propre à Peppol. EN 16931 laisse l'adresse électronique de l'acheteur facultative, et l'étape EN 16931 passe donc.
• Une adresse bien formée qui passe cette règle, BR-63 et BR-CL-25 n'est toujours qu'une chaîne de caractères dans un document. Le validateur n'interroge ni l'annuaire Peppol ni un SMP : il ne peut donc pas vous dire si l'acheteur est enregistré ou en mesure de recevoir le document.

Règles liées

• PEPPOL-EN16931-R020 exige de la même manière l'adresse électronique du vendeur
• BR-63 exige un attribut schemeID sur l'EndpointID de l'acheteur
• BR-CL-25 vérifie le code de schéma par rapport à la liste de codes EAS
• Parcourir toutes les règles de la référence
• Contexte (en anglais) : How Peppol invoice validation actually works

Portée et source

Rédigé pour Peppol BIS Billing 3.0.21 (May 2026), EN 16931 1.3.16, tel qu'appliqué aux documents Invoice et CreditNote en UBL 2.1. D'autres profils, syntaxes et versions peuvent définir cet identifiant autrement. Version du catalogue d'aide 2026-09-24.1 : source vérifiée le 2026-09-24, explication mise à jour le 2026-09-20.

La définition officielle de PEPPOL-EN16931-R010 (en anglais) contient le texte normatif et le test. Cette page en est notre explication, pas une copie.

Cette aide ne modifie pas le verdict du moteur. Corriger ce constat ne signifie pas que le document passe toutes les étapes de validation, et la validation ne certifie pas la conformité juridique ou fiscale et ne transmet aucun document via Peppol.