En bref
- En XML, les préfixes (
rsm:,ram:) ne sont que des placeholders liés à des URI — c’est la recommandation W3C. - Les préfixes
rsm/ram/udt/qdtsont recommandés pour la lisibilité, maiscii:oufactx:peuvent être valides s’ils sont liés aux bonnes URI. - Ce qui est faux : URI différente de celle attendue par le schéma CII ciblé, URI mal orthographiée, ou mélange de vocabulaires UBL (
cbc:,cac:) et CII. - Vérifiez les URI complètes contre le XSD de votre édition ; les déclarations CII montrées ici se terminent par
:100. - Certaines normalisations CII sont couvertes par
/repair; transformer UBL en CII demande un mapping de syntaxe.
Ce que l’erreur veut dire
Factur-X est une instance du standard CII (Cross-Industry Invoice, UN/CEFACT). La recommandation W3C Namespaces in XML est explicite : le préfixe est un placeholder ; ce qui compte, c’est l’association entre le préfixe utilisé et la bonne namespace URI. Un élément foo:CrossIndustryInvoice peut être parfaitement valide si foo est lié à urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100. Les problèmes réels sont : (a) URI incorrecte (obsolète ou mal orthographiée), (b) mélange UBL/CII dans le même document.
Quand cette erreur arrive
Survient quand : (a) URI différente de celle attendue par le schéma (par exemple :99 au lieu de :100) ; (b) framework qui ré-écrit les namespaces et change les URI ; (c) utilisation accidentelle d’UBL (cbc:, cac:) au lieu de CII ; (d) mauvaise orthographe de l’URI CII.
Fragment XML avec une mauvaise URI et un élément UBL
Ce fragment est bien formé, mais ne respecte pas la structure CII. Une simple déclaration xmlns:cbc inutilisée ne suffirait pas à démontrer un mélange : c’est l’élément cbc:ID ci-dessous qui l’illustre.
<rsm:CrossIndustryInvoice
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:99"
xmlns:cbc="urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-2">
<cbc:ID>EXEMPLE-001</cbc:ID>
</rsm:CrossIndustryInvoice>Déclarations CII attendues pour ce fragment
Les déclarations ci-dessous corrigent les URI ; elles ne constituent pas une facture complète ni une preuve de validité XSD ou Schematron.
<rsm:CrossIndustryInvoice
xmlns:rsm="urn:un:unece:uncefact:data:standard:CrossIndustryInvoice:100"
xmlns:ram="urn:un:unece:uncefact:data:standard:ReusableAggregateBusinessInformationEntity:100"
xmlns:udt="urn:un:unece:uncefact:data:standard:UnqualifiedDataType:100"
xmlns:qdt="urn:un:unece:uncefact:data:standard:QualifiedDataType:100">
...
</rsm:CrossIndustryInvoice>Correction manuelle
Comparez chaque URI complète avec le schéma CII ciblé. Corrigez une URI erronée uniquement si le vocabulaire et la structure des éléments sont déjà CII ; remplacer un suffixe ou un préfixe ne convertit pas un document UBL. Les préfixes standards (rsm, ram, udt, qdt) sont RECOMMANDÉS pour la lisibilité et l’outillage, mais pas imposés par la norme — c’est l’URI qui valide, pas le préfixe. Les éléments métier UBL ne peuvent pas remplacer les éléments attendus par le schéma CII.
Réparable automatiquement par /repair ?
L’endpoint /repair peut appliquer les normalisations CII déterministes couvertes. Consultez le diff et la revalidation retournés : un mélange de structures UBL/CII exige un mapping, pas un simple renommage de namespace.
Et maintenant ?
Réparer mon Factur-X →
curl -X POST https://api.facturxapi.com/api/v1/repair \
-H "Authorization: Bearer VOTRE_CLE" \
-F "file=@./facture.xml"