Face à l’échéance légale de la facturation électronique en France qui approche, et pour répondre aux besoins de plus en plus pressants de l’un de mes clients, j’ai décidé de prendre les devants. Au lieu d’attendre, j’ai développé un module Dolibarr dédié et j’ai le plaisir de le mettre aujourd’hui à disposition de la communauté en Open Source (licence GPLv3).
Qu’est-ce que fait le module ?
Actuellement en version Alpha, il permet de gérer les flux B2B français :
Annuaire National (Directory) : Recherche d’entreprises par nom/code postal et association en un clic du SIREN et des routes de livraison PEPPOL à vos fiches tiers.
Factures Émises (Ventes) : Génération automatique des fichiers au format certifié Factur-X (PDF avec XML embarqué) et transmission vers la plateforme partenaire.
Factures Reçues (Achats) : Récupération automatique et importation en tant que factures fournisseurs brouillons (avec liaison des tiers et ventilation des taux de TVA).
Déclaration des Paiements (E-Reporting) : Triggers automatiques sur les encaissements et les paiements, gérant le prorata de TVA sur encaissement pour les factures multi-taux.
Console d’Audit : Suivi complet et débogage de l’historique des appels API échangés avec les serveurs tiers.
Compatibilité Plateformes (PDP)
Le module est conçu pour s’interfacer avec deux plateformes :
SuperPDP : Les tests d’intégration ont été poussés au maximum en environnement de bac à sable (sandbox) et sont pleinement validés.
FactPulse : Le support technique de leur part ayant été très difficile à obtenir, l’intégration reste expérimentale et n’a pas pu être validée à 100 %.
Pourquoi ce dépôt séparé ?
Certains se demanderont peut-être pourquoi je n’ai pas directement proposé cela dans le dépôt officiel de modules communautaires de Dolibarr (dolibarr-community-modules). J’y ai pensé, mais le manque d’informations sur la façon d’y contribuer, sur la roadmap ou sur la répartition des tâches rend l’intégration un peu opaque. Pour répondre rapidement au besoin concret de mon client, j’ai donc choisi de lancer ce dépôt indépendant pour avancer efficacement, tout en restant bien sûr ouvert à toute discussion de convergence future.
Appel à retours & contributions
Le module est fonctionnel dans mon environnement de test, mais il n’a pas encore été éprouvé sur une grande variété de situations. C’est pourquoi je le publie aujourd’hui. Si vous êtes intéressés pour le tester en environnement de bac à sable (sandbox), remonter des bugs ou contribuer au code, vous êtes les bienvenus !
S’agissant d’une version Alpha, ne l’installez pas sur une instance de production.
Merci beaucoup pour ce module, j’étais en train de me poser la question si j’allais devoir aussi faire quelque chose de mon côté.
Je suis en train d’installer une version test 23.0.3 pour migrer dessus, j’installerai votre module dessus afin de faire quelques tests et voir s’il n’y a pas souci.
Bonjour, un compte Github et rien ne vous empêche d’ouvrir des issues voir de proposer des PR. Il y a une certaine organisation c’est certain mais tout développeur est le bienvenu
@+
je serais ravi de contribuer, mais ce repo n’est pas très clair : comment installer les modules communautaires dans dolibarr ? je dois zipper ce qui m’intéresse ou bien cloner le repo dans un répertoire précis de mon installation dolibarr ?
tous les bugs qui ont été remontés sont pour la plupart clôturés ce jour, reste 1 ou 2 cas bizarres de connexion SSL, et d’envoi de remise (qui sera fixé d’ici quelques minutes).
Merci pour votre vigilance et votre aide
J’ai une petite question. J’ai prévu de tester ca aussi. Pour faire des tests de bout en bout comme tu as fait, si j’ai bien compris on ne peut pas passer par leur sandbox. Il faut envoyer des factures réelles. C’est bien ça ?
Oui je suis en réflexion avec @aspangaro-Inovea pour mettre en place une sujet/chapitre dédié voir verrouillé car tout le monde intervient pour n’importe quoi.
Une salve de mises à jour depuis mon dernier message, avec un gros focus sur la conformité EN16931 — le format que les plateformes (PDP) valident réellement avant transmission. Je détaille, car plusieurs points répondent à des blocages concrets remontés ici et sur d’autres fils.
Le point le plus important : gestion automatique des lignes négatives (remises & acomptes)
C’est probablement la source de rejet la plus fréquente. Dolibarr encode certaines opérations comme des lignes de facture à montant négatif : remise globale, déduction d’acompte, avoir partiel intégré. Or la norme EN16931 interdit qu’une ligne de facture ait un prix négatif (règle BR-27). Résultat : la facture part, et la PDP la rejette à la validation. J’ai vu passer ce cas (« lignes en négatif refusées par SuperPDP ») et « jouer avec les quantités » n’y change rien, car c’est le prix qui est négatif, pas la quantité.
Le module gère désormais ça automatiquement, sans rien à faire de votre côté :
chaque ligne négative est convertie en remise au niveau document (bloc BG-20, la forme correcte au sens de la norme) ;
les totaux sont recalculés proprement : lignes positives (BT-106) et remises (BT-107) séparément, pour rester cohérent avec le contrôle de la plateforme ;
cas limite : si une facture ne contient que des lignes négatives, la transmission est bloquée avec un message clair — une facture 100 % négative doit passer par un avoir (que le module référence automatiquement à la facture d’origine, règle BR-55).
Concrètement : une facture avec acompte déduit ou remise commerciale globale se transmet maintenant normalement, là où un envoi brut serait refusé.
Autres corrections de conformité EN16931 récentes
Codes de catégorie TVA mappés dynamiquement (AE, K, G, Z, O, E) au lieu d’une valeur figée (#15)
Devise réelle de la facture (multicurrency_code) au lieu d’un EUR codé en dur (#19)
Unités de mesure alignées sur la nomenclature UN/ECE Rec.20 pour BT-130 (#23)
Bloc moyens de paiement BG-16 injecté dans le payload, via la classe native Account de Dolibarr (#17)
Suppression du faux numéro de TVA FR00000000000 (injecté seulement s’il existe réellement) (#18)
Blocage propre si l’adresse de l’émetteur manque ; champs d’adresse acheteur vides omis (#24)
Lignes de sous-total / titres de section ignorées dans le payload (suite #14)
Fournisseur (PDP)
Le module se concentre désormais sur SuperPDP, seule PDP agréée intégrée. Le connecteur FactPulse a été retiré (non agréé DGFiP). L’architecture reste prête à accueillir une autre PDP agréée si besoin.
Côté fonctionnel
Page « Tiers sans SIREN » avec recherche SIREN dans l’annuaire national via une fenêtre modale (#3693ad8)
Options d’activation indépendantes pour la facturation électronique et la gestion SIREN
Comme toujours : c’est non officiel, en alpha, et tous les retours de test sont les bienvenus — surtout sur des cas de factures « exotiques » (multi-taux, acomptes, avoirs), c’est ce qui fait progresser la conformité.
Nouvelle salve d’améliorations, toujours centrée sur la conformité EN16931 et remontée en partie grâce à vos retours.
Exonérations de TVA (mentions VATEX) — le gros morceau
Jusqu’ici le module mappait bien la catégorie de TVA (S, E, G, K, O, AE), mais il manquait le motif d’exonération que la norme EN16931 impose dès qu’une ligne n’est pas au taux standard. Sans lui, la plateforme rejette la facture avec l’erreur bien connue « Value of ram:ExemptionReasonCode is not allowed » (exports hors UE, franchise en base, livraisons intracommunautaires, autoliquidation…).
C’est désormais géré automatiquement :
Attribution du code VATEX (BT-121) et du libellé légal (BT-120) selon la catégorie : G → VATEX-EU-G, K → VATEX-EU-IC, AE → VATEX-EU-AE, O → VATEX-EU-O, E → VATEX-FR-FRANCHISE.
Regroupement correct par catégorie (BG-23) : une facture mixant plusieurs régimes exonérés produit bien un code distinct par catégorie.
Surcharge possible par facture ou par tiers via une liste déroulante des codes VATEX officiels (avec descriptions) — fini la saisie libre source de typos. Si vous choisissez un code sans texte, le motif légal est rempli automatiquement.
Un récapitulatif des mentions transmises s’affiche dans l’onglet Facturation Électronique de la facture, avec une alerte si un code personnalisé est appliqué à tort sur une facture multi-régimes.
Factures reçues (achats)
Bouton « Récupérer les nouvelles factures » pour interroger la plateforme à la demande.
Nouveau mode « téléchargement seul » (réglage Autoriser l’import) : si l’import est désactivé, aucune facture fournisseur n’est créée — vous pouvez uniquement télécharger le PDF/XML original de chaque facture reçue (la tâche cron respecte aussi ce réglage).
Bouton de téléchargement par ligne redimensionné (il était disproportionné).
Tests
Ajout de tests unitaires isolés sur le mapping VATEX, et vérification bout-en-bout des différents cas d’exonération (export, intracommunautaire, franchise, autoliquidation, hors champ, multi-régimes).
Toujours en alpha / sandbox uniquement, exclusivement sur SuperPDP (seule PDP agréée intégrée). Vos retours sur les cas exotiques (multi-taux, avoirs, régimes d’exonération particuliers) restent les bienvenus.
Qu’est-ce que fait le module ?
Compatibilité Plateformes (PDP)
Pourquoi ce dépôt séparé ?
Appel à retours & contributions
S’agissant d’une version Alpha, ne l’installez pas sur une instance de production.
Accès au projet
Dépôt GitHub - Dolibarr Facturation Électronique B2B
Le point le plus important : gestion automatique des lignes négatives (remises & acomptes)
Autres corrections de conformité EN16931 récentes
Côté fonctionnel
Factures reçues (achats)
Tests
