Visualiseur de factures UBL
UBL 2.1Ouvrez une facture ou un avoir UBL 2.1 et lisez-le comme un document : parties, lignes, ventilation de TVA, totaux et modalités de paiement, à côté du XML brut et du modèle analysé.
Votre document ne quitte jamais votre poste — le fichier est lu et analysé dans cet onglet du navigateur.
Déposez un document XML ici, ou choisissez un fichier
Lu dans votre navigateur. Jamais transmis. Jusqu’à 12.0 MB.
Ce que fait ce visualiseur
Une facture UBL est un document XML profondément imbriqué. La lire dans un éditeur de texte suppose de suivre dans quel cac:Party on se trouve et de rapprocher mentalement cac:TaxTotal de cac:LegalMonetaryTotal. Cet outil le fait pour vous : il résout le document en objets métier décrits par la norme et les présente comme une facture, tout en gardant la source à un onglet de distance.
Trois vues sont disponibles. Aperçu restitue la facture. XML brut réindente et met en évidence la source avec les numéros de ligne. Données analysées montre l’objet exact que ce site a construit à partir de votre fichier, ce qui est précisément ce que l’on veut lorsqu’un champ n’apparaît pas là où on l’attend.
Des espaces de noms, pas des préfixes
L’erreur la plus répandue dans l’outillage UBL fait maison consiste à rechercher les chaînes littérales cac: et cbc:. Ces préfixes sont des conventions et ne font pas partie de la norme. Une facture conforme peut associer l’espace de noms UBL Common Basic Components à n’importe quel préfixe, ou en faire l’espace de noms par défaut sans aucun préfixe : c’est toujours le même document.
Ce visualiseur résout chaque élément par URI d’espace de noms et nom local, en parcourant les enfants directs plutôt qu’en cherchant parmi les descendants. Une facture utilisant foo: et bar: s’analyse donc exactement comme une facture aux préfixes conventionnels, et un nom de vendeur n’est jamais récupéré par accident dans une structure imbriquée.
Ce que lit le visualiseur
- Identité du document — numéro de facture, dates d’émission et d’échéance, code de type de document, devise, référence acheteur, période de facturation, notes et leurs qualifiants de sujet.
- Parties — nom commercial et raison sociale enregistrée distingués, adresse électronique, identifiants de partie avec leur schéma, immatriculations à la TVA et autres, adresse postale et coordonnées.
- Lignes — quantité avec code d’unité, prix net et quantité de base, identifiants d’article, catégorie de taxe classifiée et montant net de ligne.
- TVA — chaque
cac:TaxSubtotalavec sa catégorie, son taux, sa base taxable, son montant de taxe et son motif d’exonération. - Totaux — total des lignes, remises, majorations, montants hors taxes et toutes taxes comprises, acompte, arrondi et montant dû.
- Paiement — code de moyen de paiement, identifiant de compte ou IBAN, titulaire du compte, BIC, informations de rapprochement et conditions de paiement.
Les valeurs sont affichées telles qu’écrites
Montants, quantités et dates conservent le texte exact trouvé dans le document à côté de la valeur interprétée. Si un montant vaut 1 234,56 plutôt qu’un décimal XSD valide, le visualiseur vous montre cette chaîne au lieu d’afficher discrètement un nombre qui ne figure pas dans votre fichier. C’est délibéré : un outil de débogage qui corrige vos données en silence masque justement l’anomalie que vous cherchiez.
À lire également
Pour la structure sous-jacente à ces éléments, voyez UBL 2.1 pour la facturation ; pour le modèle sémantique que mettent en œuvre UBL et CII, voyez EN 16931. Si votre fichier est une Cross Industry Invoice UN/CEFACT plutôt qu’un document UBL, utilisez le visualiseur CII. Pour valider une facture UBL 2.1 face au schéma et aux règles EN 16931, utilisez le validateur UBL.
Questions fréquentes
Mon document est-il transmis quelque part ?
Non. Le fichier est lu par votre navigateur via l’API File et analysé par son propre analyseur XML. Il n’est jamais envoyé à un serveur, jamais écrit en stockage et jamais inclus dans une mesure d’audience. Vous pouvez le vérifier en ouvrant l’onglet réseau de votre navigateur pendant que vous ouvrez un fichier : aucune requête n’est émise.
Quelles versions d’UBL sont prises en charge ?
Les documents UBL 2.1 Invoice et CreditNote, c’est-à-dire ce sur quoi reposent EN 16931, Peppol BIS Billing 3.0 et la plupart des profils CIUS européens. Les documents UBL 2.0 et 2.2 s’affichent généralement correctement eux aussi, car les éléments de facture que lit ce visualiseur sont inchangés, mais ils ne constituent pas une cible prise en charge.
Le visualiseur dépend-il des préfixes cac: et cbc: ?
Non, et cela compte davantage qu’il n’y paraît. En XML, un préfixe n’est qu’un alias local pour une URI d’espace de noms : une facture UBL parfaitement valide peut utiliser foo: et bar: à la place. Ce visualiseur résout chaque élément par son URI d’espace de noms et son nom local, de sorte que tout document conforme s’analyse à l’identique, quels que soient les préfixes choisis par son émetteur.
Cet outil me dit-il si mon document est conforme ?
Ce visualiseur confirme que le fichier est du XML bien formé et qu’il s’agit d’un document UBL, et il le dit explicitement ; les couches de schéma et de règles sont affichées comme « non exécutées » ici, car un visualiseur ne les exécute pas. Pour valider, utilisez le validateur UBL, qui exécute le schéma XML de l’OASIS et les règles de gestion EN 16931 et rend un verdict par couche.
Que se passe-t-il avec un fichier mal formé ?
Vous obtenez le diagnostic de l’analyseur lui-même, avec la ligne et la colonne du premier problème lorsque le navigateur les indique, ainsi qu’une suggestion sur sa cause habituelle. Les documents contenant une déclaration DOCTYPE sont refusés d’emblée : les DTD sont le point d’entrée des attaques XXE et par expansion d’entités, et aucune facture légitime n’en a besoin.