FAQ

Que veulent dire les codes BT-34, BT-71, BG-13 ?

Ce sont les noms officiels des cases du formulaire commun à toute la facturation électronique européenne, la norme EN 16931. Plutôt que de dire "le nom du client", qui se traduit différemment dans chaque pays et chaque logiciel, la norme dit BT-44, et tout le monde parle de la même chose.

Deux préfixes seulement :

• BT (Business Term) : une information élémentaire, une seule valeur. BT-1 est le numéro de facture, BT-2 sa date, BT-9 la date d'échéance.
• BG (Business Group) : un groupe qui rassemble plusieurs BT. BG-13 est le bloc "informations de livraison", qui contient le nom du destinataire (BT-70), l'identifiant du lieu (BT-71) et l'adresse (le sous-groupe BG-15).

Les numéros ne suivent aucune logique thématique : ils ont été attribués dans l'ordre de rédaction de la norme. BT-34 et BT-49 se ressemblent beaucoup (ce sont les deux adresses de routage, vendeur et client) alors que leurs numéros sont éloignés.

Vous croiserez aussi des codes commençant par BR (Business Rule), par exemple BR-57. Ce ne sont pas des cases mais des règles de contrôle : BR-57 dit que si l'adresse de livraison est présente, le pays de livraison doit l'être aussi. Quand une plateforme refuse une facture, elle cite en général le BR qui a échoué, et c'est la meilleure piste pour comprendre ce qui manque.

Les champs les plus souvent cités par les plateformes, et où ils se règlent dans Dolibarr :

Le module affiche "Votre numéro de TVA est vide"

Rendez-vous dans Accueil > Configuration > Société et renseignez le numéro de TVA intracommunautaire de votre société. Ce numéro est obligatoire pour générer un XML Factur-X conforme.

Pour les sociétés françaises, le numéro de TVA est au format FR suivi de 11 chiffres (exemple : FR12345678901).

Le module affiche des erreurs sur les informations du client

Ouvrez la fiche tiers de votre client et vérifiez que les champs suivants sont renseignés :

• Nom de la société
• Adresse (rue)
• Code postal
• Ville
• Pays
• SIREN ou SIRET (identifiant professionnel, selon le pays)

Pour les clients français, si le SIRET est renseigné mais pas le SIREN, le module déduit automatiquement le SIREN (les 9 premiers chiffres du SIRET). Si le numéro de TVA intracommunautaire manque, le module tente de le calculer à partir du SIREN.

Le validateur signale "BR-FR-12/BT-49 : le BT-49 est obligatoire"

Le BT-49 est l'adresse de facturation électronique de votre client. Le module la renseigne dans cet ordre :

1. le champ Identifiant Peppol/FacturX spécifique (BT-49) de la fiche tiers,
2. à défaut, l'adresse email du client (celle du contact de facturation s'il en existe un, sinon celle du tiers), transmise avec le code de schéma EM.

Si aucune des deux n'est renseignée, le champ est volontairement omis du XML : un élément vide serait lu comme une adresse manquante et mal formée par les plateformes. C'est ce que signale BR-FR-12.

Pour le corriger, renseignez l'un ou l'autre sur la fiche du client, puis régénérez le PDF. Pour un particulier, seule l'adresse email est envisageable : il n'a pas d'identifiant de routage, et il ne faut surtout pas en inventer un.

Le module vous prévient désormais dès la génération du PDF, sans attendre le passage dans un validateur. La règle symétrique BR-FR-11 s'applique à votre propre adresse (BT-34), configurée dans l'onglet Point d'accès du module.

Je facture un particulier et le module réclame un numéro de TVA

Ouvrez la fiche du tiers et positionnez le champ Type du tiers sur la valeur Particulier, puis régénérez le PDF. Le module cesse alors de réclamer le numéro de TVA (BT-48) et l'identifiant professionnel SIREN ou SIRET (BT-47), que la norme EN 16931 rend facultatifs pour une facture adressée à un particulier.

La case Assujetti à la TVA de la fiche tiers ne suffit pas : Dolibarr la coche par défaut sur tout nouveau tiers, particulier compris. Seul le champ Type du tiers permet au module de savoir à qui il s'adresse.

Le numéro de TVA du particulier reste absent du XML même si un SIREN a été saisi par erreur sur sa fiche : aucun numéro n'est calculé à partir de ce SIREN.

La facture n'a pas pu être transmise (livraison intracommunautaire)

Quand une facture comporte une livraison intracommunautaire (au moins une ligne exonérée de TVA, au taux 0, au titre de l'article 262 ter du CGI / article 138 de la directive TVA), la norme EN 16931 et le profil XRechnung exigent des champs supplémentaires. Si l'un d'eux manque, la facture est refusée à la transmission avec un message du type :

Elle n'a pas pu être transmise car des champs sont manquants sur la facture.

Voici les trois exigences possibles et la façon de les satisfaire.

Le motif d'exonération de TVA (BT-121 et BT-120)

Dès qu'une ligne est exonérée, il faut justifier pourquoi. Le module fournit pour cela un champ complémentaire sur la facture :

1. Ouvrez la facture, dans le bloc des champs complémentaires.
2. Renseignez le champ Code d'exonération de TVA (liste déroulante VATEX).
3. Pour une livraison intracommunautaire, choisissez VATEX-EU-IC (Livraison intracommunautaire).

À partir de ce code, le module renseigne automatiquement le code du motif (BT-121) et son libellé (BT-120) dans le XML, et il en déduit la catégorie de TVA EN 16931 correcte (K pour l'intracommunautaire, AE pour l'autoliquidation, G pour l'export, etc.).

Ces deux champs sont portés par la ventilation de TVA de la facture, et uniquement là : la norme ne les prévoit pas au niveau des lignes, où seules la catégorie et le taux de TVA ont leur place. Les lignes exonérées portent donc la catégorie déduite du code, sans le motif. Certains validateurs, dont DATEV, refusent une facture qui répète le motif sur chaque ligne.

La liste des codes provient d'un dictionnaire (Accueil > Configuration > Dictionnaires > "Codes d'exonération de TVA (VATEX)") où vous pouvez activer ou désactiver les codes selon vos besoins. Ce dictionnaire est partagé avec le module peppol : si vous utilisez les deux modules, le code saisi sur la facture sert aux deux.

La date de livraison (BT-72) ou la période de facturation (BG-14)

Pour une livraison intracommunautaire, il faut prouver quand la livraison a eu lieu. L'un des deux suffit :

• BT-72 : la date effective de livraison. Le module la reprend depuis le bon d'expédition lié (date de livraison de l'expédition) ou, à défaut, depuis la date de livraison de la commande liée. Si aucune des deux n'est disponible, le module utilise la date de la facture.
• BG-14 : la période de facturation (date de début et date de fin).

Pour fiabiliser ce point, renseignez la date de livraison sur la commande ou créez l'expédition liée avec sa date.

Le pays de destination (BT-80)

Pour une livraison intracommunautaire, le code pays du destinataire (BT-80) devient obligatoire : c'est lui qui matérialise que les biens quittent le territoire.

Le module construit le bloc destinataire à partir du contact de livraison de la facture. Solution :

1. Ouvrez la facture, onglet Contacts/adresses.
2. Ajoutez un contact de type Livraison client dont l'adresse comporte bien un pays renseigné.

Si ce contact n'a pas d'adresse propre, le module reprend celle du tiers.

Quand la facture ne comporte aucun contact de livraison et qu'une catégorie de TVA exonérée (K intracommunautaire, AE autoliquidation, G export) rend BT-80 obligatoire, le module prend le pays du tiers facturé comme pays de destination : c'est ce que signifie une facture sans adresse de livraison distincte. Renseigner le contact de livraison reste préférable dès que le lieu de livraison diffère de l'adresse de facturation.

Sur une facture sans ligne exonérée, rien ne change : si aucun pays n'est trouvé, l'adresse de livraison est omise en entier plutôt que transmise incomplète, car la règle BR-57 rend BT-80 obligatoire dès que l'adresse de livraison est présente. Le motif est écrit dans dolibarr.log.

Je suis auto-entrepreneur en franchise en base de TVA

Une entreprise en franchise en base (article 293 B du CGI) facture sans TVA. Dans le XML, ses lignes doivent porter la catégorie de TVA E (exonération), avec le code d'exonération VATEX-FR-FRANCHISE. Une facture transmise avec une autre catégorie est refusée par la plateforme (SuperPDP renvoie par exemple l'erreur 213 sur les éléments de TVA).

N'utilisez pas le code Non soumis à la TVA (VATEX-EU-O) : il produit la catégorie O, réservée aux opérations situées hors du champ de la TVA, ce qui n'est pas le cas d'une franchise en base.

La façon la plus simple :

1. Dans Accueil > Configuration > Société ou Organisation, cochez Non assujetti à la TVA.
2. Laissez vide le champ Code d'exonération de TVA de vos factures.

Le module applique alors de lui-même VATEX-FR-FRANCHISE à toute facture à 0 % sans code d'exonération. Un code choisi sur la facture reste prioritaire : si une facture relève d'un autre motif, renseignez-le.

Vous pouvez aussi choisir Franchise en base de TVA (France) dans le champ Code d'exonération de TVA de chaque facture. Si ce choix n'apparaît pas dans la liste, activez-le dans Accueil > Configuration > Dictionnaires > "Codes d'exonération de TVA (VATEX)". Le module l'active de lui-même à sa prochaine réactivation.

Une facture déjà générée avec la mauvaise catégorie doit être régénérée (bouton Générer de la fiche facture) avant d'être transmise à nouveau.

Identifiants par pays dans le XML Factur-X

Le module remplit le bloc SpecifiedLegalOrganization (BG-4 vendeur, BG-7 acheteur) du XML en fonction du pays du tiers :

Allemagne : il n'existe pas de code ISO/IEC 6523 officiel pour le HRB. La pratique X-Rechnung / KoSIT consiste à transmettre le numéro de registre du commerce sans schemeID, ce que fait le module. Il est lu dans le champ Handelsregister-Nummer (Id. prof. 3) de la fiche société ; s'il est vide, le bloc est omis plutôt que rempli avec un autre identifiant. Un numéro de registre saisi dans l'Id. prof. 1, comme l'indiquait une ancienne version de cette page, est encore repris, avec un avertissement dans dolibarr.log : déplacez-le dans l'Id. prof. 3.

Le USt-IdNr (numéro de TVA intracommunautaire) et la Steuernummer (numéro fiscal) ne passent pas par ce bloc. Le USt-IdNr est transmis dans BT-31, depuis le champ "Numéro de TVA" de la fiche société. La Steuernummer est transmise dans BT-32, depuis le champ Steuernummer (Id. prof. 1) : elle suffit au contrôle du numéro de TVA pour une société qui n'a pas de USt-IdNr. Si l'Id. prof. 1 contient en fait le USt-IdNr (l'interface anglaise de Dolibarr le libelle ainsi) ou un numéro de registre, BT-32 n'est pas émis.

Cas Chorus Pro (France) : le tableau ci-dessus décrit le mode standard EN 16931 (SIREN, schemeID="0002"). Chorus Pro exige au contraire le SIRET à 14 chiffres (schemeID="0009") dans ce même bloc. Si vous déposez sur Chorus Pro, cochez la case "Facture pour Chorus Pro" sur la facture, sinon Chorus rejette le dépôt avec le message "l'identifiant doit être égal à 14". Détails dans la page Chorus Pro.

À quoi correspond BT-29 (identifiant du vendeur) ?

BT-29 est un identifiant de votre société distinct de l'identifiant légal (BT-30) et du numéro de TVA (BT-31) : SIRET, GLN, numéro attribué par votre client... Il est facultatif et peut être répété. Son code de schéma ISO/IEC 6523 (BT-29-1) indique de quel type d'identifiant il s'agit.

Le module le renseigne automatiquement à partir de la fiche de votre société (Configuration > Société/Organisation), à deux endroits du bloc vendeur :

<ram:SellerTradeParty>
  <ram:ID>12345678900012</ram:ID>                              <!-- BT-29 sans schéma -->
  <ram:GlobalID schemeID="0009">12345678900012</ram:GlobalID>  <!-- BT-29 avec son schéma (BT-29-1) -->
  <ram:Name>MA SOCIETE</ram:Name>
  ...
</ram:SellerTradeParty>

L'identifiant que votre client vous a attribué

Beaucoup de clients, en Allemagne notamment, attribuent un numéro à chacun de leurs fournisseurs (la Lieferantennummer) et demandent à le retrouver sur vos factures. Ce numéro change d'un client à l'autre : il se saisit sur la fiche de chaque tiers client, dans le champ Notre identifiant chez ce client (BT-29).

Quand il est renseigné, le module l'envoie en premier ram:ID du bloc vendeur, sans schéma, et garde ensuite l'identifiant de votre société :

<ram:SellerTradeParty>
  <ram:ID>LIEF-4711</ram:ID>                                   <!-- attribué par ce client -->
  <ram:ID>12345678900012</ram:ID>                              <!-- identifiant de votre société -->
  <ram:GlobalID schemeID="0009">12345678900012</ram:GlobalID>
  ...
</ram:SellerTradeParty>

Pour une société allemande, qui n'a pas d'identifiant de société à cet endroit, c'est le seul BT-29 de la facture. Le champ apparaît sur les fiches tiers après la désactivation puis la réactivation du module qui suivent sa mise à jour.

Les options de la configuration

Deux options de la configuration agissent sur GlobalID seulement, ram:ID n'est pas concerné :

• Désactiver l'ID global (FACTURX_GLOBAL_IDENTIFIER_DISABLE) le supprime.
• Identifiant global personnalisé (FACTURX_GLOBAL_IDENTIFIER_CUSTOM) le remplace par la valeur saisie au format schéma:identifiant, par exemple 0088:3012345678901 pour un GLN. C'est aussi le moyen d'émettre un GlobalID quand le module ne connaît pas de schéma pour votre pays. Une valeur qui ne respecte pas ce format est ignorée, et la raison est écrite dans dolibarr.log.

L'identifiant saisi dans l'onglet Point d'accès de la configuration n'a aucun effet sur BT-29 : il alimente BT-34, l'adresse électronique de votre société (voir ci-dessous). Les deux peuvent reprendre le même numéro, mais pas pour le même usage : BT-29 dit qui vous êtes, BT-34 où vous joindre sur le réseau des plateformes.

Si la case "Facture pour Chorus Pro" est cochée sur la facture, BT-29 est entièrement omis, identifiant attribué par le client compris : Chorus Pro identifie le vendeur par le SIRET placé dans l'identifiant légal (BT-30).

BT-34 est absent de mes factures, à quoi correspond-il ?

BT-34 est l'adresse électronique de votre société : l'identifiant sous lequel les plateformes de facturation électronique vous reconnaissent comme émetteur. C'est l'équivalent, pour le réseau des plateformes, de votre adresse e-mail pour le courrier. Son pendant côté client est BT-49.

Concrètement, il sert à deux choses : permettre au destinataire de savoir de quelle entreprise vient la facture au sens du réseau (et pas seulement d'après le nom écrit dessus), et lui permettre de vous répondre par le même canal (accusé de réception, acceptation, rejet).

Dans le XML, il se présente ainsi, à l'intérieur du bloc vendeur :

<ram:SellerTradeParty>
  <ram:Name>MA SOCIETE</ram:Name>
  <ram:DefinedTradeContact>...</ram:DefinedTradeContact>       <!-- contact vendeur -->
  <ram:URIUniversalCommunication>
    <ram:URIID schemeID="0225">518704522</ram:URIID>           <!-- BT-34 -->
  </ram:URIUniversalCommunication>
</ram:SellerTradeParty>

Notez que le contact vendeur et BT-34 sont voisins, pas imbriqués : ce sont deux informations indépendantes.

Les raisons pour lesquelles il peut manquer

1. L'option "Désactiver le contact vendeur" est cochée (corrigé en 1.6.135).

Jusqu'à la version 1.6.134, cette option (FACTURX_GLOBAL_TRADECONTACT_DISABLE) supprimait aussi BT-34, alors qu'elle ne devait retirer que le nom et le téléphone du commercial. C'est la cause la plus fréquente, et la plus déroutante : rien dans l'intitulé de l'option ne laisse deviner qu'elle emporte l'adresse de routage. Mettez le module à jour : les deux sont désormais indépendants, et vous pouvez masquer le contact vendeur sans perdre BT-34.

2. Aucun identifiant configuré et aucune adresse e-mail.

Le module utilise d'abord l'identifiant saisi dans la configuration, et à défaut votre adresse e-mail avec le schéma EM. Si les deux manquent, il n'y a rien à écrire. Jusqu'à la version 1.6.134, un élément vide était tout de même produit :

<ram:URIUniversalCommunication/>

Ce qui, pour un validateur ou une plateforme, revient à une absence de BT-34, en plus d'être malformé. Depuis 1.6.135, plus rien n'est émis dans ce cas et la raison est écrite dans dolibarr.log. La vraie solution reste de renseigner l'un des deux : voir la section suivante.

3. La valeur saisie est mal formée.

Si l'identifiant ne respecte aucun des deux formats acceptés, le module bascule sur l'e-mail et affiche un avertissement à la génération du PDF. BT-34 est alors présent, mais contient une adresse e-mail au lieu de votre identifiant de routage, ce qui ne permet pas le routage.

Comment vérifier

Ouvrez le XML embarqué dans le PDF (voir plus bas) et cherchez URIUniversalCommunication dans le bloc SellerTradeParty. Si l'élément est absent ou vide, cherchez facturx dans dolibarr.log : le module y écrit systématiquement ce qu'il a fait de BT-34, y compris la raison quand il n'écrit rien.

Comment faire pour que les champs BT-49 (acheteur) et BT-34 (vendeur) soient renseignés ?

BT-49 et BT-34 sont les adresses électroniques de routage sur le réseau de facturation électronique : BT-49 identifie votre client (le destinataire), BT-34 identifie votre société (l'émetteur). Ils servent au point d'accès / PDP/PA pour acheminer la facture.

Le module remplit ces champs selon une règle simple : dès qu'une adresse de facturation électronique est renseignée et exploitable, elle est écrite dans le XML. Il n'est pas nécessaire d'avoir choisi un point d'accès dans le module : la plupart des utilisateurs passent par une plateforme tierce (PDP/PA) qui se contente de lire le XML. Si aucune adresse n'est renseignée, le module retombe automatiquement sur l'adresse e-mail (schéma EM), ce qui reste conforme mais n'active pas le routage. Seule exception : pour votre propre société, quand elle est française, le SIREN est utilisé avant l'e-mail (voir BT-34 ci-dessous).

Les deux formats acceptés

Une adresse de facturation électronique est toujours composée d'un identifiant (SIREN, SIRET, GLN...) et d'un code de schéma de la liste EAS / ISO-IEC 6523, qui indique de quel type d'identifiant il s'agit. Le code de schéma comporte toujours 4 chiffres : 0225 (identifiant de facturation électronique français), 0009 (SIRET), 0002 (SIREN), 0088 (GLN), 0208 (numéro d'entreprise belge), etc.

Selon la plateforme qui vous documente, les deux parties sont écrites dans un ordre ou dans l'autre. Le module accepte les deux :

Comme un code de schéma fait 4 chiffres alors qu'un SIREN en fait 9 et un SIRET 14, le module reconnaît l'ordre tout seul. Utilisez la valeur exacte que votre plateforme vous a communiquée, sans la réécrire.

BT-49 -- adresse électronique de l'acheteur

Sur la fiche du tiers client, renseignez le champ "Identifiant Peppol/FacturX spécifique (BT-49)". Pour un client français, y coller son SIREN ou son SIRET suffit : le code de schéma 0225 est ajouté automatiquement. Le bouton "Rechercher l'identifiant Peppol/FacturX" de la fiche tiers interroge l'annuaire public, et "Vérifier sur l'annuaire Peppol public" permet de contrôler une valeur déjà saisie.

Si le champ est vide, le module utilise l'e-mail du client (celui du contact de facturation en priorité, sinon l'e-mail du tiers) avec le schéma EM.

BT-34 -- adresse électronique du vendeur

Dans l'onglet Point d'accès de la configuration du module, renseignez le champ "Adresse de facturation électronique de votre société (BT-34)" (FACTURX_AP_SENDER_ID). Pour une société française, votre SIREN ou votre SIRET seul suffit : le code de schéma 0225 est ajouté automatiquement. Ce champ est visible que vous ayez sélectionné un point d'accès ou non.

Si le champ est vide et que votre société est française, le module utilise son SIREN avec le code de schéma 0225 : c'est l'identifiant sous lequel toute entreprise française figure dans l'annuaire. Le SIREN est lu sur la fiche de votre société (Id. prof. 1), ou déduit des 9 premiers chiffres du SIRET (Id. prof. 2). Un avertissement le signale à chaque génération, jusqu'à ce que le champ soit renseigné.

Ce repli évite un rejet bien réel. Avec une adresse e-mail en BT-34, SuperPDP ne reconnaît pas l'émetteur comme une entreprise française et classe la facture comme internationale ("B2BInt"). Il refuse alors toute facture qui mélange biens et services, avec le message "B2BInt invoice cannot contain a mix of goods and services".

Pour une société étrangère, ou une société française dont la fiche ne porte ni SIREN ni SIRET, le module utilise l'e-mail du vendeur (contact commercial lié à la facture, sinon l'e-mail de votre société) avec le schéma EM.

Depuis la version 1.6.135, l'option Désactiver le contact vendeur (FACTURX_GLOBAL_TRADECONTACT_DISABLE) n'emporte plus BT-34 avec elle : les deux éléments sont voisins dans le XML mais indépendants. Avant cette version, cocher cette option supprimait aussi l'adresse électronique du vendeur, sans le dire.

N'utilisez pas le champ e-mail pour y loger votre identifiant de routage. C'est une erreur fréquente quand l'adresse électronique ne sort pas dans le XML. Elle produit un XML incohérent, car le champ e-mail alimente aussi le bloc contact du vendeur. Saisissez l'identifiant dans le champ prévu ci-dessus et laissez une vraie adresse e-mail dans le champ e-mail.

"L'adresse de facturation électronique est mal formée"

Ce message apparaît à la génération du PDF quand le champ est renseigné mais que le module n'y reconnaît pas une adresse exploitable. Les deux ordres de saisie sont acceptés indifféremment : 494895360:0225 (identifiant puis code de schéma, usage français) et 0225:494895360 (code de schéma puis identifiant, usage Peppol). Le code de schéma fait toujours 4 chiffres, ce qui permet de le reconnaître quel que soit sa place.

Un SIREN ou un SIRET français seul suffit. Depuis la version 1.6.135, saisir 494895360 ou 49489536000035 sur une fiche française suffit : le module ajoute le code de schéma 0225 et n'affiche aucun message. Il le fait sans réserve quand la valeur est le SIREN ou le SIRET du tiers lui-même, et par déduction, avec une trace dans le journal, quand elle en a seulement la forme.

Restent signalés les cas où le module ne peut rien conclure :

La facture est tout de même générée, avec l'adresse e-mail en remplacement, mais votre plateforme ne pourra pas router la facture tant que la saisie n'est pas corrigée. Le module n'invente jamais de code de schéma dans ces cas : un identifiant transmis sous un mauvais schéma désigne un participant qui n'est pas le bon, ce qui est pire qu'une adresse absente.

Comment vérifier que le XML est bien présent dans le PDF ?

Ouvrez le PDF avec Adobe Acrobat Reader (version bureau, pas le navigateur). Dans le panneau latéral, cliquez sur l'icône de trombone (pièces jointes). Le fichier factur-x.xml doit apparaître. Vous pouvez l'extraire et l'ouvrir avec un éditeur de texte pour vérifier son contenu.

Vous pouvez aussi utiliser un validateur en ligne comme Factur-X Validator pour vérifier la conformité du XML.

Le PDF n'est pas modifié / pas de XML embarqué

Vérifiez les points suivants :

1. Le module est bien activé dans la configuration des modules
2. La facture est une facture client (le module ne traite pas les factures fournisseur)
3. Il n'y a pas d'erreur affichée lors de la génération du PDF
4. L'option PDF_SECURITY_ENCRYPTION n'est pas activée (cette option casse de nombreuses fonctionnalités PDF)
5. Le mécanisme de hook n'est pas en conflit avec un autre module

Si le problème persiste, consultez les logs de Dolibarr (dolibarr.log) pour trouver des messages d'erreur liés à Facturx.

L'extension PHP GD ou zlib manque

Le module nécessite les extensions PHP GD et zlib pour fonctionner. Installez-les via votre gestionnaire de paquets :

# Debian / Ubuntu
apt install php-gd

# CentOS / RHEL
yum install php-gd

L'extension zlib est généralement incluse par défaut dans PHP. Redémarrez votre serveur web après l'installation.

L'option PDF_SECURITY_ENCRYPTION est active

Si un message d'avertissement s'affiche sur la page de configuration à propos de PDF_SECURITY_ENCRYPTION, cette option cachée de Dolibarr est activée. Elle interfère avec la génération de PDF et doit être désactivée :

1. Rendez-vous dans Accueil > Configuration > Divers
2. Recherchez la constante PDF_SECURITY_ENCRYPTION
3. Supprimez-la ou mettez sa valeur à 0

Ma facture est refusée avec "The Item net price (BT-146) shall NOT be negative"

Le message complet ressemble à ceci, avec les règles BR-27, BR-28 et, sur la plateforme française, BR-FR-DEC-03 :

[BR-27]-The Item net price (BT-146) shall NOT be negative. BR-FR-DEC-03/BT-148 : Le montant "-3.00" est invalide.

La facture comporte une ligne au prix unitaire négatif, en général une remise saisie à la main comme une ligne de facture ordinaire (par exemple "Remise commerciale, -3,00 EUR"). La norme EN 16931 l'interdit : le prix d'un article ne peut jamais être négatif.

Vous n'avez rien à changer à votre façon de saisir. Le module convertit désormais toute ligne au total négatif en remise au niveau de la facture (bloc BG-20 du XML) : le montant y figure en positif, accompagné du libellé de la ligne comme motif, de sa catégorie de TVA et de son taux. La ligne disparaît des lignes de facture du XML et les totaux sont ajustés en conséquence (le total des lignes ne compte plus la remise, qui est reportée dans le total des remises). Le net à payer est inchangé, et le PDF reste identique à ce que vous voyez dans Dolibarr.

Cette conversion ne s'applique pas aux avoirs, dont toutes les lignes sont négatives par nature : le type de document indique déjà le sens du montant, et les lignes y sont transmises en positif.

Je facture en devise étrangère, quels montants partent dans le XML ?

Ceux de la facture, dans sa devise. Si vous établissez une facture en dollars, le XML porte USD comme devise du document (BT-5) et tous ses montants sont les montants en dollars : prix unitaires, totaux de lignes, remises et majorations, ventilation de TVA, acomptes et totaux généraux. Le XML décrit ainsi la même facture que le PDF que votre client a sous les yeux.

Dolibarr conserve deux jeux de montants sur une facture en devise étrangère : ceux de la devise de facturation, qui sont imprimés sur le PDF, et ceux de la devise comptable de votre société, qui servent à votre comptabilité. Seuls les premiers partent dans le corps du XML.

La TVA est en plus exprimée dans votre devise comptable (champs BT-6 et BT-111), avec le taux de conversion de la facture. C'est une obligation pour un vendeur français -- l'article 289 du CGI veut que le montant de la taxe à payer soit libellé en euros -- et c'est de toute façon ce dont la comptabilité de votre client a besoin. Sur une facture exonérée, dont la TVA est nulle, ces deux champs sont omis, comme la norme le prévoit.

Vous n'avez rien à paramétrer : le module se fonde sur la devise de la facture telle qu'elle est enregistrée dans Dolibarr. Vérifiez simplement que le taux de conversion porté par la facture est celui que vous voulez voir dans le document : c'est lui qui sert au calcul de la TVA en devise comptable.

Quelle unité part dans le XML (BT-130) ?

Celle de la ligne de facture. Le module lit l'unité de mesure de chaque ligne -- la colonne Unité, alimentée par le dictionnaire Accueil > Configuration > Dictionnaires > "Unités" -- et la traduit en code de la liste UN/ECE Recommandation 20, que la norme EN 16931 attend dans BT-130. Une prestation facturée en heures part donc en HUR, un poids en kilogrammes en KGM, une surface en mètres carrés en MTK.

Les 37 unités livrées avec Dolibarr sont toutes traduites (poids, longueurs, surfaces, volumes, pièce, lot, durées) et vous n'avez rien à paramétrer.

Ligne sans unité : le XML porte H87 (pièce). Une installation qui n'a jamais renseigné d'unité voit donc un XML inchangé.

Unité ajoutée à la main : le dictionnaire des unités est modifiable. Si vous y créez une unité, saisissez directement le code Rec 20 dans sa colonne Code -- par exemple KWH pour un kilowattheure, KMT pour un kilomètre, NPR pour une paire -- et il partira tel quel dans le XML. Un code sans équivalent Rec 20 retombe sur H87, et la raison est écrite dans dolibarr.log.

Facture de synthèse : les lignes regroupées portent le code de l'option "Code unité des lignes agrégées" (LS, forfait, par défaut), pas l'unité des lignes d'origine. Les lignes non regroupées gardent la leur.

Tous les codes émis ont été contrôlés contre la liste de codes du schematron EN 16931 : aucune unité ne peut faire rejeter une facture qui passait auparavant.

Les factures de situation ne fonctionnent pas

Les factures de situation ne sont pas supportées par le standard Factur-X. Le module détecte ce type de facture et affiche un avertissement. Aucune solution de contournement n'est disponible : c'est une limitation du standard lui-même.

Comment fonctionne la référence acheteur (BT-10) ?

BT-10 est alimenté par le champ complémentaire Code service (CHORUS / BT-10) de la facture, pas par le champ natif Réf. client. Ce champ est créé par le module ; il n'apparaît sur les factures qu'après désactivation puis réactivation du module, et à condition que l'option Désactiver la prise en charge de Chorus soit décochée.

Son nom vient de Chorus Pro, où il porte le code service du service acheteur, mais il sert à toute plateforme qui réclame une référence acheteur. C'est notamment lui qui porte la Leitweg-ID exigée par le profil allemand XRechnung (règle BR-DE-15) : l'interface allemande du module le nomme d'ailleurs "Leitweg-ID / Käuferreferenz (BT-10)".

Le champ Réf. client de la facture ne part pas dans BT-10 mais dans BT-13 (référence de la commande acheteur), et seulement en repli : le module prend d'abord le champ complémentaire N° d'engagement, puis à défaut Réf. client, puis à défaut la référence client de la commande liée. C'est cette valeur de repli qui est limitée à 50 caractères, avec un avertissement affiché au-delà.

L'avertissement "Code service / référence acheteur absent (BT-10)" ne s'affiche que sur les factures identifiées comme destinées à Chorus Pro. Sur une facture destinée à une autre plateforme, rien ne signale l'absence de BT-10 avant le refus du validateur.

Enfin, le champ Réf. commande acheteur (BT-132) ne porte que le numéro de la ligne dans le XML : la norme ne prévoit rien d'autre à cet endroit, et un validateur qui y trouve le numéro de commande le signale sur chaque ligne de la facture (avertissement CII-SR-108). Le numéro de commande lui-même est donc placé au niveau de la facture : dans BT-13 s'il est libre, sinon en document référencé de type 130. Il n'est jamais perdu, sauf sur une facture Chorus Pro dont le n° d'engagement est déjà renseigné, cette plateforme refusant les documents référencés sans pièce jointe.

À quoi correspond le champ BT-71 et comment le renseigner ?

BT-71 est l'identifiant du lieu de livraison dans la norme EN 16931. Il appartient au bloc "informations de livraison" (BG-13), aux côtés du nom du destinataire (BT-70), de l'adresse de livraison (BG-15, dont le pays BT-80) et de la date effective de livraison (BT-72).

Ce que c'est, et ce que ce n'est pas

BT-71 n'est pas une adresse : c'est un code qui désigne un lieu précis, quand votre client en exploite plusieurs (entrepôts, magasins, chantiers, plateformes logistiques). Il répond à la question "lequel de vos sites a été livré ?", là où l'adresse répond à "où".

Deux usages courants :

• un GLN (Global Location Number, 13 chiffres), identifiant normalisé attribué par GS1, très répandu en grande distribution ;
• un code convenu entre vous et votre client (code magasin, code entrepôt, numéro de chantier), sans normalisation particulière.

Ne le confondez pas avec deux champs voisins :

Où le saisir

Le lieu de livraison, dans Dolibarr, c'est le contact de livraison : son nom alimente BT-70 et son adresse alimente BG-15. Le module y ajoute un champ pour l'identifiant.

1. Ouvrez la fiche du contact qui représente ce lieu de livraison (Tiers > fiche du client > onglet Contacts/adresses, puis le contact concerné).
2. Renseignez le champ Identifiant du lieu de livraison (BT-71).
3. Sur la facture, onglet Contacts/adresses, vérifiez que ce contact est bien rattaché avec le type Livraison client.

Vous ne saisissez donc l'identifiant qu'une seule fois, sur le contact. Ensuite :

• si votre client est toujours livré au même endroit, rattachez ce contact de livraison à ses factures et l'identifiant suit tout seul ;
• si une facture concerne un autre site, rattachez-lui le contact de livraison correspondant : c'est l'identifiant de ce contact-là qui partira ;
• les contacts d'une commande sont recopiés sur la facture qui en est issue, le contact de livraison de la commande est donc repris sans rien faire.

Le champ n'apparaît sur les fiches contact qu'après désactivation puis réactivation du module : c'est à ce moment que Dolibarr crée les champs complémentaires du module.

Quel format saisir

Comme pour l'adresse de facturation électronique (BT-49), un code de schéma ISO/IEC 6523 fait toujours 4 chiffres, ce qui permet au module de reconnaître l'ordre de saisie tout seul. Le schéma 0088 est celui des GLN ; c'est de loin le plus fréquent ici.

Utilisez la valeur exacte communiquée par votre client, sans la réécrire. En particulier, si votre client vous donne un GLN sans mentionner de schéma, saisissez-le seul : le module n'invente pas de code de schéma.

Ce que ça produit dans le XML

Avec un identifiant normalisé (0088:3123456789012) :

<ram:ShipToTradeParty>
  <ram:GlobalID schemeID="0088">3123456789012</ram:GlobalID>  <!-- BT-71 -->
  <ram:Name>Entrepôt Nord</ram:Name>                          <!-- BT-70 -->
  <ram:PostalTradeAddress>                                    <!-- BG-15 -->
    <ram:PostcodeCode>44000</ram:PostcodeCode>
    <ram:LineOne>12 rue de la Logistique</ram:LineOne>
    <ram:CityName>Nantes</ram:CityName>
    <ram:CountryID>FR</ram:CountryID>                         <!-- BT-80 -->
  </ram:PostalTradeAddress>
</ram:ShipToTradeParty>

Avec un code libre (MAGASIN-42), l'identifiant sort en <ram:ID>MAGASIN-42</ram:ID> sans attribut de schéma, à la place du GlobalID.

Quand BT-71 n'est pas transmis

• Le champ est vide : rien n'est émis, et c'est parfaitement conforme. BT-71 est facultatif dans l'EN 16931 : aucune facture n'est rejetée parce qu'il manque. Un validateur peut le signaler en information, jamais en erreur bloquante.
• La facture n'a pas de contact de livraison : le module n'a aucun lieu de livraison à décrire, donc pas d'identifiant à transmettre. Rattachez le contact à la facture (onglet Contacts/adresses, type Livraison client).
• La valeur contient un ":" sans code de schéma à 4 chiffres (par exemple SITE:NORD) : elle est transmise entière, telle quelle, comme un code libre. Un avertissement est écrit dans dolibarr.log pour signaler qu'aucun schéma n'a été reconnu, mais rien n'est perdu ni tronqué.

Puis-je utiliser le module avec un modèle PDF ODT ?

Oui, à condition que votre Dolibarr convertisse les documents ODT en PDF. Le module Facturx intervient après la génération du PDF (hook afterPDFCreation), quel que soit le modèle d'origine.

Deux possibilités pour que la conversion ODT vers PDF fonctionne :

• Configurer LibreOffice sur votre serveur pour la conversion native de Dolibarr
• Utiliser le module DoliPDF de CAP-REL, qui assure cette conversion

Une fois le PDF généré, le module Facturx y intègre automatiquement les métadonnées XML.

Comment contacter le support ?

Deux options :

1. Depuis Dolibarr, rendez-vous dans la page Support du module (onglet à côté de Réglages et À propos). Remplissez le formulaire avec la description de votre problème. Les informations techniques (version du module, de Dolibarr, de PHP) sont pré-remplies.

2. Contactez directement CAP-REL via le formulaire de contact.