Il existe deux générations d'EDI dans l'écosystème communautaire : l'ancienne, faite de modules d'import et d'export spécialisés, et la nouvelle — un cadre où chaque échange est un enregistrement avec son état, son format, sa destination et son historique.
Vingt-neuf modules composent ce cadre. C'est le dépôt le plus structuré de l'OCA, et le plus déroutant pour qui l'aborde module par module.
Résumé
Huit modules forment le noyau : les enregistrements d'échange avec leurs types, leurs vues par état et leur automatisation ; le module d'intégration qui les relie ; des états EDI assignables aux documents, avec leur circuit ; des gabarits d'échange ; un mécanisme de déduplication à l'envoi ; le stockage de métadonnées sur les documents ; et la gestion des données de tiers.
Six modules traitent les formats et les destinations : un socle d'échange par fichier XML, un type d'échange UBL et ses gabarits de tiers et d'adresse, l'envoi par stockage distant — SFTP notamment —, l'appel de services web, et des destinations personnalisées.
Trois modules traitent l'exécution : le passage des échanges en travaux de fond, son articulation avec le stockage distant, et le mécanisme de déduplication.
Douze modules enfin branchent les documents métier : les écritures comptables, les commandes de vente — avec leur variante UBL, leur sortie UBL, leur entrée, leur lien au stock et leur destination —, les commandes d'achat et leur sortie UBL, les produits et leurs colisages, et le stock.
L'essentiel
- Chaque échange est un enregistrement avec son état et son historique.
- Une vue des échanges en échec, qui manque à toute intégration maison.
- Des états EDI assignables aux documents, avec leur circuit.
- Des gabarits de génération plutôt que du code.
- L'envoi par SFTP ou par appel de service web.
- Les échanges exécutés en travaux de fond.
- Une déduplication à l'envoi.
- Le branchement ventes, achats, stock, produits et comptabilité.
Ce que ces modules ajoutent à l'instance
| Famille | Modules | Nombre |
|---|---|---|
| Noyau | edi_core_oca, edi_oca, edi_state_oca, edi_exchange_template_oca, edi_exchange_deduplicate_oca, edi_record_metadata_oca, edi_party_data_oca, edi_party_helper_oca | 8 |
| Formats et destinations | edi_xml_oca, edi_ubl_oca, edi_ubl_output_base_oca, edi_exchange_template_party_data, edi_storage_oca, edi_webservice_oca, edi_endpoint_oca | 7 |
| Exécution | edi_queue_oca, edi_storage_queue_oca | 2 |
| Documents métier | edi_account_core_oca, edi_account_oca, edi_sale_oca, edi_sale_input_oca, edi_sale_ubl_oca, edi_sale_ubl_output_oca, edi_sale_stock_oca, edi_sale_endpoint, edi_purchase_oca, edi_purchase_ubl_output_oca, edi_product_oca, edi_stock_oca | 12 |
Les menus : EDI ▸ Exchanges avec ses cinq vues — toutes, en échec, entrants, sortants, en attente —, EDI ▸ Paramètres de configuration ▸ States, EDI Endpoints et EDI Exchange Templates, plus Ventes ▸ Commandes ▸ EDI, Achats ▸ EDI et Facturation ▸ Comptabilité ▸ Exchange records.
Pourquoi un cadre plutôt que des modules
Une intégration EDI faite de scripts et de modules spécialisés fonctionne jusqu'au premier échec : un fichier refusé par le destinataire, et plus personne ne sait ce qui est parti, quand, ni pourquoi ça a échoué. Le cadre répond d'abord à cette question — chaque échange est un enregistrement.
edi_core_oca (version 18.0.1.8.0, la plus avancée du dépôt) définit les enregistrements d'échange, leurs types, l'automatisation de base et les vues. Les cinq vues du menu EDI ▸ Exchanges disent l'essentiel : tous, en attente, entrants, sortants, en échec.
edi_oca est le module d'intégration qui relie les briques entre elles. edi_state_oca permet d'assigner des états EDI aux documents concernés, avec un circuit d'états paramétrable.
edi_exchange_template_ocapermet de définir les échanges par gabarits, au lieu de code.edi_record_metadata_ocastocke des métadonnées sur les documents liés à un échange.edi_exchange_deduplicate_ocaintroduit une déduplication à l'envoi — pour ne pas transmettre deux fois le même document.edi_party_data_ocaetedi_party_helper_ocarécupèrent et configurent les informations de tiers nécessaires à un échange ; le second s'appuie sur les numéros d'identification de partenaire.
L'état EDI sur le document est ce qui manque le plus souvent : un commercial qui regarde une commande doit voir si elle a été transmise, acceptée ou refusée par le système du client — sans ouvrir un écran technique.
Les formats et les destinations
edi_xml_ocaest le socle d'échange par fichier XML.edi_ubl_ocadéfinit un type d'échange UBL, etedi_ubl_output_base_ocafournit les gabarits génériques de tiers et d'adresse au format UBL.edi_exchange_template_party_dataest la colle entre gabarits et données de tiers.edi_storage_ocapermet l'échange de fichiers via un stockage distant — SFTP notamment —, en s'appuyant sur le connecteur de stockage.edi_webservice_ocadéfinit l'intégration par appel de service web depuis un enregistrement d'échange.edi_endpoint_ocapermet de configurer des destinations personnalisées, sous EDI ▸ Paramètres de configuration ▸ EDI Endpoints.
Les trois modes de transport — fichier déposé, service web appelé, destination personnalisée — couvrent la réalité des échanges : la grande distribution dépose sur SFTP, les plateformes appellent des services, et certains donneurs d'ordre ont leur propre protocole.
L'exécution en travaux de fond
edi_queue_oca fait exécuter les échanges en travaux de fond via le module de files de travaux, et edi_storage_queue_oca articule cela avec le stockage distant.
Ce n'est pas un raffinement : un échange synchrone bloque l'utilisateur pendant l'appel au système distant, et une lenteur du destinataire devient une lenteur de votre ERP.
Brancher les documents métier
Douze modules branchent les documents d'Odoo sur le cadre. Le motif est régulier : un module de configuration, parfois un module de comportement, parfois une sortie UBL.
| Document | Modules | Menu |
|---|---|---|
| Écritures comptables | edi_account_core_oca, edi_account_oca | Facturation ▸ Comptabilité ▸ Exchange records ▸ Moves |
| Commandes de vente | edi_sale_oca, edi_sale_input_oca, edi_sale_ubl_oca, edi_sale_ubl_output_oca, edi_sale_stock_oca, edi_sale_endpoint | Ventes ▸ Commandes ▸ EDI ▸ Exchanges |
| Commandes d'achat | edi_purchase_oca, edi_purchase_ubl_output_oca | Achats ▸ EDI ▸ Exchanges |
| Produits et colisages | edi_product_oca | — |
| Stock | edi_stock_oca | — |
Les ventes sont les mieux outillées, avec six modules : la configuration, le traitement des commandes entrantes — qui s'appuie sur le module d'import de commandes de l'ancien dépôt —, la variante UBL, la sortie UBL (version 18.0.1.3.1, avec huit dépendances), le lien au stock, et la destination.
La chaîne de dépendances de la sortie UBL des ventes compte huit modules. Ce n'est pas de la complexité gratuite : chacun apporte une pièce — le format, les gabarits, les données de tiers, les états, le XML, le stock. Mais cela explique qu'une installation EDI compte trente modules et paraisse opaque.
L'ancienne génération de modules d'import et d'export est traitée dans importer une commande ou une facture reçue.
Limites connues
- Deux générations d'EDI coexistent dans l'écosystème : le dépôt
edi(modules spécialisés) etedi-framework(ce cadre). Choisir une approche, et savoir que le cadre réutilise certains modules de l'ancienne. - Le cadre demande un investissement initial : comprendre les enregistrements d'échange, les types et les gabarits avant de brancher un premier flux.
- La chaîne de dépendances est longue : la sortie UBL des ventes dépend de huit modules. Une montée de version demande de les vérifier tous.
edi_storage_ocadépend du connecteur de stockage (fs_storage) etedi_webservice_ocad'un module de services web : deux briques externes au dépôt.- L'exécution en travaux de fond exige une infrastructure de travailleurs surveillée : un travailleur arrêté et les échanges s'accumulent en attente.
- La déduplication se fait à l'envoi : elle ne protège pas d'un double traitement côté destinataire.
- Aucun de ces modules ne vaut agrément pour la réforme française : ils transportent et formatent, la conformité dépend de la plateforme.
Identité technique
Les vingt-neuf modules viennent du dépôt OCA edi-framework, branche 18.0 — dont les 30 modules sont désormais tous documentés ici. Treize sont en LGPL-3, seize en AGPL-3. Les dépendances externes : base_edi, base_ubl et sale_order_import du dépôt edi, fs_storage pour le stockage, webservice et endpoint pour les destinations, queue_job pour les travaux de fond, component_event pour les écouteurs, partner_identification pour les tiers, base_sparse_field pour les métadonnées.
Voir aussi UBL, Factur-X et l'envoi des factures.
Questions fréquentes
Quelle différence entre les dépôts edi et edi-framework ?
Deux générations. Le dépôt edi contient des modules d'import et d'export spécialisés par document et par format. edi-framework est un cadre où chaque échange est un enregistrement avec son état, son format, sa destination et son historique. Le cadre réutilise certains modules de l'ancienne génération.
Comment savoir ce qui a été transmis et ce qui a échoué ?
C'est précisément l'objet de edi_core_oca : chaque échange est un enregistrement, avec cinq vues sous EDI ▸ Exchanges — tous, en attente, entrants, sortants, en échec. Une intégration faite de scripts ne répond pas à cette question après le premier refus.
Un commercial peut-il voir si une commande a été transmise au client ?
Oui, avec edi_state_oca, qui assigne des états EDI aux documents avec un circuit paramétrable. C'est ce qui manque le plus souvent : voir sur la commande si elle a été transmise, acceptée ou refusée, sans ouvrir un écran technique.
Par quels moyens le cadre EDI peut-il envoyer un document ?
Trois : un fichier déposé sur un stockage distant (edi_storage_oca, SFTP notamment), un appel de service web (edi_webservice_oca), ou une destination personnalisée (edi_endpoint_oca). Cela couvre la réalité : la grande distribution dépose sur SFTP, les plateformes appellent des services.
Pourquoi une installation EDI compte-t-elle trente modules ?
Parce que chaque pièce est séparée : le format, les gabarits, les données de tiers, les états, le transport, le document métier. La sortie UBL des commandes de vente dépend à elle seule de huit modules. Ce n'est pas de la complexité gratuite, mais cela demande de documenter la chaîne avant une montée de version.
Se faire accompagner
Le choix entre les deux générations d'EDI est le premier arbitrage d'un projet d'échange, et il est rarement posé : les modules spécialisés vont plus vite sur un flux unique, le cadre devient indispensable dès qu'il y a plusieurs partenaires, plusieurs formats, ou une obligation de traçabilité.
Nous instruisons donc ce choix selon le nombre de flux prévus, puis nous documentons la chaîne de dépendances installée — parce que c'est elle qu'il faudra vérifier à chaque montée de version. Voir les prestations d'Atalios Consulting ou demander un rappel.
Pour aller plus loin
En résumé
Il existe deux générations d'EDI dans l'écosystème communautaire : des modules spécialisés, et un cadre où chaque échange est un enregistrement avec son état, son format et son historique. Vingt-neuf modules composent ce cadre. Parlons de vos échanges.
