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.

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.).

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. Si aucun pays n'est trouvé nulle part, l'adresse de livraison est omise en entier plutôt que transmise incomplète : la règle BR-57 rend BT-80 obligatoire dès que l'adresse de livraison est présente, une adresse sans pays échouerait donc à la validation à coup sûr. Le motif est écrit dans dolibarr.log.

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. Le USt-IdNr (numéro de TVA intracommunautaire allemand) et la Steuernummer (numéro fiscal) ne passent pas par ce bloc : ils sont transmis respectivement dans BT-31 (TVA) et BT-32 (n° fiscal).

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.

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.

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)". 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). Ce champ est visible que vous ayez sélectionné un point d'accès ou non.

Si le champ est vide, 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 ni l'un ni l'autre des deux formats. Les cas les plus courants :

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 ne devine pas la valeur manquante : corrigez le champ signalé dans le message, sur la fiche du tiers pour BT-49 ou dans la configuration du module pour BT-34.

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

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 client (BT-10) ?

Le module utilise le champ Réf. client de la facture Dolibarr pour le champ BT-10 du XML Factur-X. Ce champ est limité à 50 caractères. Si la valeur dépasse cette limite, un avertissement s'affiche.

À 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.