Aller au contenu

Ironfang Finance - Référence des règles

UBL-SR-44 : Utiliser une seule référence de paiement pour tous les moyens de paiement de la facture

Deux valeurs de cbc:PaymentID diffèrent. Une facture a un seul avis de paiement : répétez la même valeur dans chaque cac:PaymentMeans, ou donnez-la une seule fois.

EN 16931Erreur : le document n'est pas valideChamps de base

Sur cette page

La réponse courte

UBL-SR-44 échoue lorsque le document contient des éléments cbc:PaymentID avec plus d'une valeur distincte. Dans l'exemple enregistré, le second cac:PaymentMeans demande PAYMENT-002 là où le premier demande PAYMENT-001. Choisissez la référence unique que l'acheteur doit indiquer et écrivez exactement cette valeur dans chaque moyen de paiement.

Plusieurs moyens de paiement sont permis, par exemple un pour chaque compte bancaire sur lequel l'acheteur peut payer, et chacun peut répéter la référence. Ce que le modèle ne peut pas exprimer, c'est une seconde référence, différente : il n'a qu'un seul champ d'avis de paiement pour toute la facture.

Ce que la règle vérifie

La règle s'exécute une fois par document et rassemble chaque cbc:PaymentID, où qu'il se trouve. Elle compte les valeurs distinctes et échoue à partir de deux ; le constat pointe sur la racine du document, et lors d'un essai avec trois moyens de paiement demandant trois références différentes, il n'y a eu qu'un seul constat.

Les répétitions et les absences sont permises. Lors d'un essai, retirer cbc:PaymentID du second moyen de paiement a réussi, et la facture corrigée donne PAYMENT-001 dans les deux.

Les valeurs sont comparées telles qu'elles sont écrites. Lors d'un essai, PAYMENT-001 avec un espace final et payment-001 en minuscules ont chacun compté comme une seconde référence et fait échouer la règle.

Deux références différentes dans un seul moyen de paiement échouent doublement. Lors d'un essai, un unique cac:PaymentMeans contenant PAYMENT-001 et PAYMENT-002 a signalé cette règle et UBL-SR-26, qui n'admet qu'un cbc:PaymentID par moyen de paiement ; la même valeur écrite deux fois n'y a signalé que UBL-SR-26.

TermeSignificationÉlément UBL
BT-83Avis de paiementcac:PaymentMeans/cbc:PaymentID
BG-16Instructions de paiementcac:PaymentMeans

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 :

  • La référence de paiement est générée par compte bancaire ou par canal de paiement, si bien que chaque cac:PaymentMeans reçoit la sienne.
  • Les échéances sont modélisées comme des moyens de paiement distincts, chacun avec la référence de son échéance.
  • Une référence est normalisée à un endroit et pas à un autre, ce qui laisse un espace final ou une casse différente dans une copie.

Comment corriger le document

  1. Déterminez la référence que l'acheteur doit indiquer en payant, par exemple le numéro de facture ou une référence créancier structurée.
  2. Écrivez exactement cette valeur, caractère pour caractère, dans le cbc:PaymentID de chaque cac:PaymentMeans qui en porte un, ou retirez-la de tous sauf un.
  3. Si vous avez besoin de références différentes pour différents comptes ou échéances, le modèle n'a pas de place pour elles. Gardez une référence et décrivez l'arrangement dans les conditions de paiement, cac:PaymentTerms/cbc:Note.
  4. Nettoyez et normalisez la référence une seule fois, avant de la copier dans chaque moyen de paiement.

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 : deux comptes, chacun avec sa propre référence de paiement

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-002</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Fragment de la facture corrigée : les deux comptes demandent PAYMENT-001

<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-001</cbc:ID>
    <!-- account name and branch omitted from this fragment -->
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>
<cac:PaymentMeans>
  <cbc:PaymentMeansCode>30</cbc:PaymentMeansCode>
  <cbc:PaymentID>PAYMENT-001</cbc:PaymentID>
  <cac:PayeeFinancialAccount>
    <cbc:ID>EXAMPLE-ACCOUNT-002</cbc:ID>
    <cbc:Name>Example Supplier Ltd</cbc:Name>
  </cac:PayeeFinancialAccount>
</cac:PaymentMeans>

Le second cac:PaymentMeans porte PAYMENT-002 dans la facture en échec et PAYMENT-001 dans la facture corrigée ; les deux documents proposent les deux mêmes comptes sous le code 30. Le document en échec ne signale que UBL-SR-44, sur la racine du document, puisque chaque moyen de paiement est complet et valide en lui-même.

Ce que le validateur a signalé

Enregistré avec phive 12.1.0 / phive-rules-peppol 4.5.6 / Saxon-HE 12.10, le moteur du validateur gratuit, sur des données synthétiques. Un résultat enregistré est une preuve de non-régression pour ces documents ; ce n'est pas une certification.

Où la règle s'applique

  • S'applique à Invoice et à CreditNote. Lors d'un essai, un avoir avec deux moyens de paiement demandant des références différentes a signalé cette règle.
  • Fait partie de la syntaxe UBL et est signalée à l'étape EN 16931 ; l'étape Peppol a validé la facture en échec enregistrée.
  • Le code du moyen de paiement est soumis à la même restriction à une seule valeur, imposée par UBL-SR-47. Lors d'un essai, modifier à la fois le code et la référence du second moyen de paiement a signalé les deux règles.
  • Un cbc:PaymentID vide compte aussi comme une valeur. Lors d'un essai, vider le second a signalé cette règle et PEPPOL-EN16931-R008.

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-28.1 : source vérifiée le 2026-09-28, explication mise à jour le 2026-09-28.

La définition officielle de UBL-SR-44 (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.