La facturation électronique obligatoire repose sur deux formats structurés — UBL et CII — et sur un format hybride, Factur-X, qui embarque le second dans un PDF. Derrière les modules fonctionnels, un socle technique fait le travail : générer, analyser, envoyer.
Douze modules communautaires composent ce socle. Les connaître explique pourquoi une installation de facturation électronique compte trente modules.
Résumé
Quatre modules forment le socle UBL : un module de fondations — menu racine EDI, organisation —, les briques communes du standard, les méthodes de génération d'un fichier XML depuis les données Odoo, et les méthodes d'analyse d'un fichier reçu.
Quatre modules forment le socle de facture hybride : les fondations de Factur-X et ZUGFeRD, le socle de génération d'un PDF à XML embarqué, la compatibilité avec le moteur de rapport bureautique, et le raccordement des codes de moyen de paiement européens aux factures électroniques du standard Odoo.
Quatre modules enfin traitent l'envoi : l'envoi du PDF d'une facture vers un système externe par appel HTTP, selon la méthode de transmission définie sur la facture ; son passage en traitement asynchrone ; le placement de ses identifiants dans un fichier serveur ; et un socle de contrat de paiement rattachant un partenaire à un mode de transmission.
L'essentiel
- UBL est la norme ISO/IEC 19845 depuis janvier 2016.
- Génération et analyse UBL sont deux modules distincts.
- Factur-X 1.0 correspond à ZUGFeRD 2.1.
- Un socle de PDF à XML embarqué, indépendant du format.
- L'envoi d'une facture par appel HTTP, selon sa méthode de transmission.
- L'envoi rendu asynchrone, pour ne pas bloquer l'utilisateur.
- Les identifiants d'envoi hors base, dans un fichier serveur.
- Les codes de moyen de paiement européens sur les factures électroniques.
Ce que ces modules ajoutent à l'instance
| Module | Version | Ce qu'il apporte |
|---|---|---|
base_edi | 18.0.1.0.2 | Les fondations : un menu racine EDI et l'organisation (LGPL-3) |
base_ubl | 18.0.1.0.0 | Les briques communes du standard UBL (ISO/IEC 19845) |
base_ubl_generate | 18.0.1.0.1 | Les méthodes de génération d'un fichier UBL |
base_ubl_parse | 18.0.1.1.0 | Les méthodes d'analyse d'un fichier UBL reçu |
base_facturx | 18.0.1.0.0 | Les fondations de Factur-X et ZUGFeRD |
account_einvoice_generate | 18.0.1.0.0 | Le socle de génération d'un PDF à XML embarqué |
account_invoice_facturx_py3o | 18.0.1.0.0 | La compatibilité avec le moteur de rapport bureautique |
account_edi_ubl_cii_payment_unece | 18.0.1.0.0 | Les codes de moyen de paiement européens sur les factures UBL et CII |
account_invoice_export | 18.0.1.0.1 | L'envoi du PDF vers un système externe par appel HTTP |
account_invoice_export_job | 18.0.1.0.0 | Cet envoi rendu asynchrone |
account_invoice_export_server_env | 18.0.1.0.0 | Ses identifiants dans un fichier serveur |
base_ebill_payment_contract | 18.0.1.0.0 | Un contrat de paiement reliant partenaire et mode de transmission |
Les menus : un menu racine EDI, et Facturation ▸ Clients ▸ eBill Payment Contract.
Le socle UBL
UBL n'est pas un format propre à Odoo ni à l'Europe : c'est la norme ISO/IEC 19845 depuis janvier 2016. Un fichier UBL émis par Odoo se lit par n'importe quel système conforme — et c'est précisément l'objet de la réforme de la facturation électronique.
base_ubl fournit les briques communes : schémas, structures, correspondances. Il ne fait rien d'utile seul.
Deux modules en dérivent, et la séparation est volontaire :
base_ubl_generatefournit les méthodes de génération d'un XML UBL depuis les données Odoo — partenaires, adresses, lignes, montants. Il dépend du module de codes d'unité de mesure européens.base_ubl_parsefournit les méthodes d'analyse d'un fichier UBL reçu, et d'extraction des informations métier.
Un émetteur n'a besoin que du premier ; un destinataire que du second. Les deux ensemble couvrent les deux sens de la réforme — émission et réception.
base_edi (LGPL-3) pose simplement le menu racine EDI et l'organisation. C'est une dépendance de confort, pas une fonctionnalité.
L'émission conforme à la norme européenne est traitée dans Factur-X et EN 16931.
Le socle de facture hybride
base_facturx pose les fondations de Factur-X et ZUGFeRD — et le README indique le point important : Factur-X 1.0 correspond à ZUGFeRD 2.1. Ce sont deux noms pour le même format, l'un français, l'autre allemand.
Le format hybride est la réponse pragmatique à un problème réel : un fichier XML est illisible par un humain, un PDF est illisible par une machine. Factur-X embarque le premier dans le second — le comptable ouvre un PDF, le système lit un XML.
account_einvoice_generate pose le socle commun de génération d'un PDF à XML embarqué, indépendamment du format. Il ne produit aucun format particulier : c'est la couche sur laquelle les modules de format se branchent.
account_invoice_facturx_py3opermet aux factures générées par le moteur de rapport bureautique — gabarits de traitement de texte — de bénéficier de la génération Factur-X.account_edi_ubl_cii_payment_unecerelie les codes de moyen de paiement européens aux factures UBL et CII générées ou importées par le module standard d'Odoo.
Le dernier corrige un manque concret : un code de moyen de paiement normalisé est obligatoire dans une facture conforme, et le standard d'Odoo ne dispose pas du référentiel complet.
Les référentiels de codes européens — taxes, unités de mesure, moyens de paiement — sont traités dans la facturation électronique française.
Envoyer une facture vers un système externe
account_invoice_export envoie le PDF d'une facture client vers un système externe par appel HTTP, en s'appuyant sur la méthode de transmission définie sur la facture. Il ajoute un bouton d'envoi.
C'est le mécanisme générique : la plateforme de dématérialisation, le portail client, le système du donneur d'ordre. Tout destinataire qui accepte un dépôt par appel HTTP.
account_invoice_export_jobrend cet envoi asynchrone, via le module de files de travaux. L'utilisateur ne reste pas bloqué devant un service distant lent.account_invoice_export_server_envplace les paramètres de connexion — adresse, utilisateur, mot de passe — dans un fichier de configuration serveur plutôt que dans la base.
Le dernier est celui qu'on oublie et qui compte : sans lui, les identifiants de la plateforme de dématérialisation sont dans la base — donc dans chaque copie de production restaurée pour recette, qui peut alors déposer de vraies factures.
base_ebill_payment_contract pose un socle de contrat de paiement rattachant un partenaire à un mode de transmission, sous Facturation ▸ Clients ▸ eBill Payment Contract.
Limites connues
- Dix de ces douze modules ne font rien de visible : ce sont des socles. Les installer sans module de format ou de flux n'apporte rien.
- La génération et l'analyse UBL sont séparées : vérifier lequel des deux votre flux demande.
base_facturxdépend de trois modules de codes européens : taxes, paiements et unités de mesure.account_invoice_exportenvoie par appel HTTP : le format attendu par le destinataire est à vérifier, le module ne fait pas de transformation.- L'envoi asynchrone exige une infrastructure de travailleurs surveillée : un travailleur arrêté, et les factures ne partent plus sans message visible.
- Les identifiants en fichier serveur demandent le module d'environnement serveur : une brique de plus, et une procédure de déploiement.
- Aucun de ces modules ne vaut agrément : la conformité à la réforme française dépend de la plateforme utilisée, non du format généré.
Identité technique
Les douze modules viennent du dépôt OCA edi, branche 18.0 — 36 modules au total. Onze sont en AGPL-3, base_edi est en LGPL-3. Les dépendances : base pour les socles, account pour les factures, uom_unece, account_tax_unece et account_payment_unece pour les codes européens, account_edi_ubl_cii pour le raccordement au standard Odoo, queue_job pour l'asynchrone, server_environment pour les identifiants, report_py3o pour le moteur bureautique, account_invoice_transmit_method pour les méthodes de transmission.
Voir aussi importer une commande ou une facture reçue pour le reste du dépôt.
Questions fréquentes
Qu'est-ce que le format UBL exactement ?
Universal Business Language, devenu la norme ISO/IEC 19845 en janvier 2016. Ce n'est pas un format propre à Odoo ni à l'Europe : un fichier UBL émis par Odoo se lit par n'importe quel système conforme. base_ubl en fournit les briques communes, base_ubl_generate les méthodes d'émission et base_ubl_parse celles de réception.
Factur-X et ZUGFeRD sont-ils deux formats différents ?
Non : le README de base_facturx l'indique explicitement — Factur-X 1.0 correspond à ZUGFeRD 2.1. Deux noms pour le même format, l'un français, l'autre allemand. Le principe : un XML structuré embarqué dans un PDF, lisible par un humain et par une machine.
Peut-on envoyer les factures Odoo vers une plateforme externe ?
Oui : account_invoice_export envoie le PDF par appel HTTP selon la méthode de transmission définie sur la facture. Ajoutez account_invoice_export_job pour que l'envoi soit asynchrone, et account_invoice_export_server_env pour sortir les identifiants de la base.
Pourquoi sortir les identifiants de la plateforme de la base de données ?
Parce qu'une copie de production restaurée pour recette les emporte, et peut alors déposer de vraies factures sur la plateforme. account_invoice_export_server_env les place dans un fichier de configuration serveur. C'est le module qu'on oublie et qui évite l'incident.
Ces modules suffisent-ils pour la facturation électronique obligatoire ?
Non. Ils génèrent, analysent et envoient des formats conformes, mais aucun ne vaut agrément : la conformité à la réforme française dépend de la plateforme de dématérialisation utilisée, non du format produit. Ce sont des socles techniques, pas une solution de bout en bout.
Se faire accompagner
La facturation électronique est le sujet où la confusion entre format et conformité coûte le plus cher : générer un Factur-X valide ne rend pas une entreprise conforme, et une plateforme agréée n'exempte pas de produire un format correct. Les deux sont nécessaires.
Nous séparons donc explicitement les deux dans un projet — le format que votre Odoo produit, la plateforme par laquelle il transite — et nous sortons les identifiants de la base avant la première émission réelle. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
La facturation électronique repose sur deux formats structurés — UBL, norme ISO depuis 2016, et CII — et sur Factur-X, qui embarque le second dans un PDF. Douze modules composent le socle technique qui génère, analyse et envoie. Parlons de votre conformité.
