Facture de marchandises étendue
Une facture de marchandises complète dans le profil EXTENDED, reconstruite étape par étape : six lignes avec indications de conditionnement et remises sur article, deux taux de TVA, des remises au niveau du document, des frais de transport, un escompte, ainsi qu’un destinataire des marchandises et un destinataire de la facture différents de l’acheteur.
Ce n’est pas un exemple quelconque, mais la facture d’exemple
officielle X19_01_Warenrechnung issue de la documentation
Factur-X / ZUGFeRD (jeu d’exemples FeRD, ZUGFeRD 2.5.0, profil
EXTENDED). Le code ci-dessous produit exactement ce document – champ par
champ, dans le même ordre. Placez le XML de référence à côté de la sortie et
vous verrez la même structure arborescente.
Certains liens de cette page mènent à la documentation approfondie dans l’espace client et demandent une connexion.
Sur le plan métier, il s’agit d’une livraison d’un grossiste en alimentation vers un magasin de supermarché. C’est précisément ce mélange qui rend l’exemple instructif : presque chaque champ qui soulève des questions au quotidien y apparaît au moins une fois.
Les sections ci-dessous s’enchaînent. Tous les extraits appartiennent à un seul programme et peuvent être écrits les uns après les autres dans cet ordre. Les commentaires citent à chaque fois les numéros de l’EN 16931 et de l’extension ZUGFeRD EXTENDED ; la référence vous donne pour chaque numéro l’élément XML correspondant.
Tous les champs EXTENDED de cet exemple – nom de document, indicateur de
test, destinataire de la facture, indications de conditionnement, composants
d’une unité de vente, frais de transport et bases d’imposition
étendues – ne sont écrits que si l’enregistrement final se fait
effectivement en Profile.Extended. Un profil plus petit n’est
pas une erreur ; les champs disparaissent alors simplement sans un mot.
1. En-tête de facture
CreateInvoice définit les trois mentions obligatoires de
l’en-tête : numéro de facture (BT-1), date de facture (BT-2) et devise de
facturation (BT-5). Tout le reste est ensuite rattaché à l’objet retourné.
2. Notes en texte libre
Le texte libre aboutit dans ram:IncludedNote (BG-1). Deux codes
pilotent son exploitabilité automatique : subjectCode (BT-21,
UNTDID 4451) dit de quoi parle la note, contentCode
(BT-X-5) est un bloc de texte normalisé supplémentaire.
Les deux codes ne se combinent pas librement :
ST1, ST2 et ST3 appartiennent à
AAK (accords de remise et de bonus), EEV,
WEB et VEV à AAJ (réserve de propriété).
Les textes des notes, les noms de produits et les motifs de remise restent en allemand sur toute cette page : ce sont les données de la facture de référence officielle, et les traduire romprait la comparaison avec elle.
3. Vendeur
SetSeller remplit ram:SellerTradeParty (BG-4). Outre
l’adresse, la partie porte deux identifiants : le numéro de fournisseur
interne (id, BT-29) et le GLN (globalID avec le schemeID
0088). Le contact, l’adresse électronique et
l’immatriculation fiscale s’ajoutent par des méthodes dédiées.
4. Acheteur
ram:BuyerTradeParty (BG-7) fonctionne de façon identique. Un point
important pour comprendre les sections suivantes : l’acheteur est ici le
siège – la livraison va à un magasin, la facture à un troisième site.
5. Références de documents dans l’en-tête
Quatre références rattachent la facture au reste du flux documentaire : commande, fiche de données de facturation, bon de livraison et date de livraison. D’autres types de référence – numéros de projet et de contrat par exemple – sont décrits dans Références de documents.
6. Destinataire des marchandises et de la facture
Le destinataire des marchandises (BG-13) et celui de la facture (BG-X-36) ne sont
pas définis par des méthodes Set… mais comme des objets
Party. Le destinataire des marchandises ne porte ici qu’un GLN et
aucune ID interne ; ShipToContact.OrgUnit ajoute en plus le service du
magasin au document.
7. Lignes de facture
Six lignes (BG-25), chacune avec sa particularité. Le motif récurrent est le même dans les six :
| Paramètre | Code BT | Signification |
|---|---|---|
lineID |
BT-126 | Numéro de ligne. S’il est omis, FactoorSharp l’attribue automatiquement – voir Numéros de ligne. |
id |
BT-157 | GTIN avec le schemeID 0160 (GS1), en FactoorSharp GlobalIDSchemeIdentifiers.EAN. |
sellerAssignedID |
BT-155 | Référence article du fournisseur. |
buyerAssignedID |
BT-156 | Référence article de l’acheteur pour la même marchandise. |
grossUnitPrice |
BT-148 | Prix brut, c’est-à-dire le prix catalogue avant remise sur article. |
netUnitPrice |
BT-146 | Prix net après remise sur article – la base du total de ligne. |
lineTotalAmount |
BT-131 | Total de ligne = netUnitPrice × billedQuantity. |
PackageQuantity / PackageUnitCode |
BT-X-9 | Unité d’expédition, EXTENDED uniquement. XCT = carton, XBC = caisse, XBO = bouteille, XPX = palette. |
Ligne 1 – attribut d’article et unité d’expédition
La ligne la plus simple : aucune remise, un attribut d’article (BG-32) et l’indication du nombre de cartons dans lesquels la marchandise est livrée. Les attributs d’article ont une page à eux : Caractéristiques produit.
Ligne 2 – remises sur article dans le prix brut
Ici, prix brut et prix net diffèrent parce que deux remises sur article entrent en
jeu. Ces remises ne se situent pas au niveau du document mais comme
ram:AppliedTradeAllowanceCharge à l’intérieur du prix brut
(BT-147).
Les montants s’entendent par unité, pas pour toute la ligne : 1,50 − 0,03 − 0,02 = 1,45. FactoorSharp ne calcule pas le prix net – vous le définissez, et les remises l’expliquent.
Ligne 3 – remise en nature
Dix pièces de la même marchandise sans facturation. La ligne reste dans le document pour que la quantité livrée reste traçable, mais contribue 0,00 € au total. Le motif figure à côté comme description de ligne (BT-154).
Lignes 4 et 5 – unités divergentes et référence acheteur
La ligne 4 montre que l’unité de facturation et l’unité d’expédition peuvent différer : facturée en caisses, expédiée en bouteilles. La ligne 5 est la consigne d’emballages correspondante et porte en plus la référence article de l’acheteur (BT-156).
Ligne 6 – palette mixte et ses composants
La palette est facturée comme une seule ligne, mais son contenu est décomposé via
IncludedReferencedProducts (BG-X-1). Cette indication est purement
informative : les prix et les taxes restent attachés à la ligne parente.
8. Remises au niveau du document
Deux remises – l’une en pourcentage, l’autre en montant fixe
– sont représentées par ram:SpecifiedTradeAllowanceCharge
(BG-20).
Une remise au niveau du document ne vaut jamais que pour un taux de TVA. Comme ce document mêle 19 % et 7 %, chaque remise doit être créée deux fois, avec la base de calcul correspondante. Deux remises deviennent ainsi quatre appels. L’ordre dans le XML correspond à l’ordre des appels dans le code.
Les bases de calcul ne sont pas simplement les totaux de ligne : pour 19 %, les lignes 1, 4 et 5 donneraient ensemble 326,50 €, mais seuls 280,00 € ont été convenus – la consigne d’emballages et une partie de la marchandise sont exclues de la remise. Pour 7 %, c’est le total complet des lignes 2, 3 et 6 qui s’applique : 130,70 €.
9. Frais de transport
Les frais logistiques ont un élément dédié en CII et ne sont pas la même chose
qu’un supplément ordinaire via AddTradeCharge. Dans
XRechnung,
l’élément n’est pas autorisé ; en ZUGFeRD EXTENDED, il l’est.
10. Ventilation de la TVA
Un groupe ram:ApplicableTradeTax (BG-23) est obligatoire par
combinaison de taux et de catégorie de TVA – donc deux ici. FactoorSharp ne
fait pas les sommes lui-même ; les valeurs viennent de votre comptabilité et sont
définies explicitement. Le calcul de ce document :
| Champ | 19 % (lignes 1, 4, 5) | 7 % (lignes 2, 3, 6) |
|---|---|---|
lineTotalBasisAmount |
326,50 | 130,70 |
allowanceChargeBasisAmount |
−5,60 − 2,50 + 3,00 = −5,10 | −2,61 − 0,50 = −3,11 |
basisAmount |
326,50 − 5,10 = 321,40 | 130,70 − 3,11 = 127,59 |
taxAmount |
321,40 × 19 % = 61,066 → 61,07 | 127,59 × 7 % = 8,9313 → 8,93 |
Le supplément pour les frais de transport entre dans la ligne à 19 % avec un signe positif, les remises avec un signe négatif. Pour en savoir plus sur les montants de TVA, en particulier avec une devise fiscale divergente, voir Montants de TVA.
11. Condition de paiement avec escompte
L’escompte ne figure pas seulement comme phrase en texte libre, mais aussi de
façon exploitable automatiquement dans le XML – c’est le rôle de
PaymentTermsType.Skonto.
12. Totaux du document
SetTotals écrit ram:SpecifiedTradeSettlementHeaderMonetarySummation
(BG-22). Ces valeurs aussi sont définies, pas calculées :
| Code BT | Paramètre | Calcul |
|---|---|---|
| BT-106 | lineTotalAmount |
100,00 + 72,50 + 0,00 + 180,00 + 46,50 + 58,20 = 457,20 |
| BT-108 | chargeTotalAmount |
3,00 (frais de transport) |
| BT-107 | allowanceTotalAmount |
5,60 + 2,61 + 2,50 + 0,50 = 11,21 |
| BT-109 | taxBasisAmount |
457,20 + 3,00 − 11,21 = 448,99 |
| BT-110 | taxTotalAmount |
61,07 + 8,93 = 70,00 |
| BT-112 | grandTotalAmount |
448,99 + 70,00 = 518,99 |
| BT-113 | totalPrepaidAmount |
0,00 – aucun acompte. La façon de détailler les acomptes est décrite sous Acomptes. |
| BT-115 | duePayableAmount |
518,99 − 0,00 = 518,99 |
13. Enregistrement
Ce n’est qu’à l’enregistrement que se décide quels champs définis ci-dessus atterrissent réellement dans le XML. Version, profil et syntaxe vont ensemble :
La façon de produire la même facture en PDF/A-3 avec XML intégré est décrite dans Travailler avec des fichiers PDF ; les autres manières d’enregistrer figurent sous Charger et enregistrer.
14. Contrôle croisé
Comme la cible est un fichier de référence connu, le résultat se vérifie
directement : le fichier produit doit présenter la même structure arborescente que
X19_01_Warenrechnung.xml du jeu d’exemples FeRD. Les nombres se
comparent numériquement, de sorte que 1.00 et 1.0000
comptent comme égaux – FactoorSharp écrit les prix de manière adaptative avec
deux décimales.
Quant à savoir si la facture respecte également le jeu de règles, vous le vérifiez soit dans le navigateur, soit directement depuis votre code. Pour le regard d’un humain sur le document, le visualiseur produit une version lisible :
C’est une simple vue, ni document juridique ni PDF ZUGFeRD hybride – détails sous Représentation visuelle.