FW-XML-001 : Corriger un XML que l'analyseur refuse de lire

FW-XML-001 est un diagnostic propre à Ironfang. Ce n'est pas une règle EN 16931 ni Peppol BIS Billing, et les autres validateurs ne le signalent pas sous cet identifiant.

La réponse courte

FW-XML-001 est un identifiant qui nous est propre. Il ne fait pas partie d'EN 16931 ni de Peppol, et vous ne le trouverez pas dans leurs listes de règles. Il signifie que l'étape XML a refusé le document avant qu'aucune règle de facture ne soit examinée : le texte n'est pas du XML bien formé, il est dans un encodage que nous n'acceptons pas, ou il contient une construction que nous bloquons par sécurité.

Les étapes XSD, EN 16931 et Peppol sont toutes signalées comme sautées ; le résultat ne dit donc encore rien du contenu de la facture. Corrigez le fichier pour qu'il puisse être analysé, validez de nouveau et attendez-vous à voir apparaître les vrais constats.

Ce que la règle vérifie

Bonne formation. Les documents tronqués, les balises non fermées ou mal appariées, un & ou un < nu dans le texte, les caractères de contrôle, un second élément racine, du texte après la racine et une entrée qui n'est pas du tout du XML ont chacun été refusés lors d'un essai. Pour ces cas, le constat indique la ligne et la colonne où l'analyseur s'est arrêté.

La déclaration XML, lorsqu'elle existe, doit être la toute première chose du fichier. Une ligne vide ou tout autre texte avant elle est refusé. Un document sans aucune déclaration est accepté.

Encodage. UTF-8 est accepté avec ou sans marque d'ordre des octets. UTF-16 n'est accepté qu'avec une marque d'ordre des octets et une déclaration qui lui correspond. Tout le reste est refusé, y compris un ISO-8859-1, windows-1252 ou US-ASCII déclaré, même lorsque les octets sont du pur ASCII, ainsi que des octets non valides pour l'encodage déclaré.

Constructions interdites. Tout DOCTYPE est refusé, avec ou sans déclarations d'entités. De même toute référence d'entité autre que les cinq prédéfinies, ce qui fait échouer les noms HTML comme  . Tout élément dans un espace de noms XInclude est refusé où qu'il se trouve ; ce constat ne porte aucun emplacement.

Ne sont pas refusés : les références de caractères numériques comme  , & et les autres entités prédéfinies, les sections CDATA, les commentaires et les instructions de traitement.

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 :

• Le XML est assemblé par concaténation de chaînes ou par un modèle texte, et un nom comme Smith & Sons y entre sans échappement.
• Le fichier a été tronqué par un envoi échoué, une limite de taille en amont ou un flux qui n'a pas été vidé.
• L'exportateur écrit un ancien encodage mono-octet, ou déclare UTF-8 tout en écrivant des octets dans un autre encodage.
• Le XML est encodé en base64 ou enveloppé dans une enveloppe JSON avant l'envoi, si bien que ce qui arrive dans le corps XML n'est pas du XML.
• Une étape de journalisation ou de modèle place une ligne vide ou une séquence d'octets devant la déclaration XML.
• L'outil de génération ajoute un DOCTYPE, ou le texte contient des entités HTML copiées depuis un formulaire web.

Comment corriger le document

1. Allez à la ligne et à la colonne indiquées dans le constat et regardez ce qui s'y trouve. Pour un fichier tronqué, c'est la fin du document.
2. Générez le XML avec une bibliothèque XML et non en joignant des chaînes, afin que le texte soit échappé et les balises équilibrées pour vous.
3. Écrivez le fichier en UTF-8 et déclarez-le en UTF-8, ou omettez la déclaration. Assurez-vous que rien ne précède la déclaration.
4. Envoyez les octets XML eux-mêmes, comme corps brut de la requête ou comme partie document d'une requête multipart : pas en base64, pas dans du JSON.
5. Retirez tout DOCTYPE, les déclarations d'entités et les éléments XInclude. Remplacez les entités HTML nommées par le caractère lui-même ou par une référence numérique.
6. Validez de nouveau. Les étapes sautées vont maintenant s'exécuter, et le document peut signaler des règles qu'il ne pouvait pas atteindre auparavant.

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.

Illustration, pas un fichier d'exemple téléchargeable : un document coupé au milieu d'une balise fermante

<cac:Price>
  <cbc:PriceAmount currencyID="EUR">500</cbc:PriceAmount>
</c

Illustration : le même document complet, avec chaque élément fermé jusqu'à la racine

<cac:Price>
  <cbc:PriceAmount currencyID="EUR">500</cbc:PriceAmount>
</cac:Price>
<!-- the enclosing cac:InvoiceLine and the Invoice root are then closed in turn -->

L'entrée en échec s'arrête au milieu d'une balise fermante, si bien que l'analyseur atteint la fin du fichier avec des éléments encore ouverts. Le document ne signale que FW-XML-001, à l'étape XML ; les étapes XSD, EN 16931 et Peppol sont sautées. Ces fragments sont des illustrations écrites à la main d'un cas de régression. Il n'existe pas de paire téléchargeable pour ce diagnostic, car le fichier en échec n'est par définition pas un document utilisable.

Où la règle s'applique

• S'applique à tout ce qui est soumis, quoi que ce soit censé être. Le type de document ne peut pas compter, car l'entrée n'a jamais été lue comme Invoice ou CreditNote.
• Il s'agit d'un diagnostic Ironfang. Un autre validateur décrira la même entrée avec ses propres mots, et peut être plus ou moins strict sur DOCTYPE et les encodages.
• Il est distinct des limites de taille et de forme. Un corps vide est signalé comme FW-INPUT-001, et les documents trop profondément imbriqués ou comportant trop d'éléments ont leurs propres identifiants FW-XML. Les corps compressés et les archives sont refusés par l'API avec une réponse 415 avant le début de la validation ; ils ne produisent donc pas ce constat.
• Un XML bien formé qui ne suit pas le schéma UBL est un autre échec : il est signalé par l'étape XSD, pas ici.

Règles liées

• PEPPOL-EN16931-R008 couvre les éléments bien formés mais vides, que l'analyseur accepte et que Peppol refuse
• BR-01 est l'une des premières règles de contenu qu'un document rencontre une fois analysé : l'identifiant de spécification doit être présent
• PEPPOL-EN16931-R004 vérifie ensuite que l'identifiant de spécification est celui de Peppol Billing
• Parcourir toutes les règles de la référence
• Contexte (en anglais) : How Peppol invoice validation actually works

Portée et source

Décrit comment Ironfang Finance traite les entrées avant la validation. Cela s'applique à chaque jeu de règles proposé par le validateur. Version du catalogue d'aide 2026-09-24.1 : source vérifiée le 2026-09-24, explication mise à jour le 2026-09-20.

Contrat de validation d'Ironfang (en anglais)

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.