Résumé des épisodes précédents : Le 25 décembre 2015, Akretion a développé [ l’importation de factures PDF régulières ] (http://www.akretion.com/blog/akretions-christmas-present-for- the-odoo-community) via l’utilisation de la bibliothèque [invoice2data] (https://github.com/m3nu/invoice2data). Cette solution nécessite le développement d’un [modèle d’importation de facture] (https://github.com/m3nu/invoice2data/tree/master/invoice2data/templates) pour chaque fournisseur. Ce modèle de facture doit être mis à jour lorsque la présentation de la facture est modifiée par le fournisseur, ce qui constitue un inconvénient majeur. Les clients d’Akretion ont découvert cet inconvénient quelques semaines après le déploiement de la solution en production. Akretion a migré son serveur Odoo de v7 à v8 (avec le moteur de reporting * Webkit * en v7 vers * Qweb * en v8) . Cette migration a changé la disposition des factures d’Akretion. l’importation des factures d’Akretion a été interrompue parce que le modèle de facture d’Akretion nécessitait une mise à jour.
Pour surmonter cet inconvénient, la solution consistait à passer à la facturation électronique. Quelques mois plus tard, en mars 2016, Akretion [a annoncé] (http://www.akretion.com/blog/akretion-publishes-zugferd-modules-to-create-and-import-electronic-invoices-with-odoo) le support de la génération de factures [ZUGFeRD] (http://www.ferd-net.de/). Une facture ZUGFeRD est une facture PDF avec un fichier XML incorporé au format CII (Facture inter industries). ZUGFeRD est le format de facture électronique officiel pour l’Allemagne. La contribution d’Akretion a également bénéficié du support de l’importation de factures UBL (Universal Business Language), utilisées par plusieurs pays d’Europe du Nord et qui constitue également la base du [format e-fff] (http: //www.e-fff .be) utilisé en Belgique. Depuis avril 2016, les factures d’Akretion France sont conformes à ZUGFeRD et les clients d’Akretion peuvent les importer dans Odoo grâce au module * account \ _invoice \ _import \ _zugferd *. Utiliser le format ZUGFeRD pour les factures d’Akretion était une bonne chose … mais le bénéfice pour les clients d’Akretion était encore limité.
Le 1er janvier 2015, Akretion [a déployé en production un Odoo v8] (http://www.akretion.com/blog/barroux-abbey-deploys-odoo-version-8-with-akretion ) à l’Abbaye de Barroux (http://www.barroux.org/). Le 1er mai 2015, [l’abbaye de Randol] (http://www.randol.org/) a déployé Odoo v8 en production et le 1er janvier 2016 le [ Le monastère de La Garde] (http://www.la-garde.org/) a également adopté Odoo v8. Chaque abbaye possède un magasin de vente au détail qui vend la production des moines ainsi que les produits artisanaux d’autres abbayes (avec des livres, des CD, des objets religieux, etc.). Le miel et les sandales produits par le monastère de La Garde sont vendus à l’abbaye de Barroux par exemple; le nougat et les biscuits produits par l’abbaye de Barroux sont vendus à l’abbaye de Randol et au monastère de La Garde, etc. Lorsque le développement des factures de ZUGFeRD a été achevé, j’ai suggéré au moine responsable des finances de l’abbaye de Barroux qu’il déployer le module pour générer des factures ZUGFeRD sur le serveur Odoo de l’abbaye. De cette façon, l’abbaye de Randol et le monastère de La Garde pourront importer les factures de l’abbaye de Barroux dans leur ERP Odoo sans codage manuel, ce qui permettra de gagner du temps pour des choses plus importantes. Mais la réponse du moine n’était pas celle que je m’attendais: il m’a dit que, comme une facture de fournisseur provisoire est générée automatiquement à partir du bon de commande, il n’y avait pas de réel avantage à utiliser des factures électroniques! Le vrai bénéfice serait d’utiliser des commandes électroniques à la place …
J’ai donc décidé de continuer le développement pour supporter les commandes électroniques! J’ai commencé à chercher la meilleure solution pour les commandes électroniques. Je voulais garder la bonne idée de la norme ZUGFeRD pour avoir des documents PDF avec un fichier XML intégré. Mais quel format était le mieux adapté pour décrire une commande en XML? J’ai découvert que [UBL] (http://ubl.xml.org/) (Universal Business Language) était le meilleur format pour le travail. La norme UBL est à la fois simple et précise. Elle est devenu la norme [ISO / IEC 19845] (http://www.iso.org/iso/catalogue_detail.htm?csnumber=66370) en décembre 2015 (voir [annonce officielle] (http: //www.prweb .com/releases/2016/01/prweb13186919.htm)). UBL est déjà largement adopté pour les factures électroniques en Europe du Nord, en Belgique (la [norme e-fff] (http://www.e-fff.be)), en Turquie ([format UBL-TR] (http: / /www.efatura.gov.tr)) et en [Australie] (http://ubl.xml.org/news/australia-choses-ubl-for-whole-of-economy-einvoicing). En France, [EDF] (https://www.edf.fr/), la compagnie nationale d’électricité, propose déjà d’envoyer ses factures au format UBL (voir [leurs spécifications] (https://entreprises.edf.com /fichiers/fckeditor/Commun/Entreprises/pdf/Guide%20technique%20facture%20EDF%20en%20XML%20V1.2.pdf)). La norme UBL prend en charge le codage XML de nombreux documents commerciaux: commandes et factures, mais aussi catalogues de produits, demandes de devis, devis, bordereaux d’expédition, lettres de voiture, certificats d’origine, etc.
Aujourd’hui, Akretion annonce la disponibilité d’une liste UBL pour Odoo afin de gérer les commandes d’achat et de vente dans Odoo:
- le module * purchase\ _order \ _ubl * intègre un fichier XML UBL de demande de devis (RFQ) dans chaque fichier PDF RFQ généré par Odoo.
- le module * sale \ _order \ _import \ _ubl * importe les fichiers XML UBL RFQ (ou le fichier PDF avec un fichier XML incorporé) pour générer de nouveaux devis.
- le module * sale \ _order \ _ubl * intègre un fichier XML UBL de devis dans chaque fichier de devis PDF.
- le module * purchase \ _order \ _import \ _ubl * importe les devis pour mettre à jour les prix et / ou les quantités sur les demandes de devis.
- lorsque le bon de commande est approuvé dans Odoo, le module * achat \ _order \ _ubl * intègre un fichier XML de commande UBL dans le fichier PDF du bon de commande.
- le module * sale \ _order \ _import \ _ubl * importe les fichiers XML d’ordre UBL pour mettre à jour les devis (ou créer de nouveaux devis).
- lorsque la commande est acceptée et que la commande de vente est confirmée dans Odoo, le module * sale \ _order \ _ubl * intégrera un fichier XML * UBL * de commande simple dans le fichier PDF de confirmation de commande d’Odoo.
A la fin du flux de vente, lorsque les marchandises ont été expédiées avec succès, le fournisseur peut générer une facture ZUGFeRD avec le module * account \ _invoice \ _zugferd *; cette facture électronique sera utilisée par le client pour mettre à jour le projet de facture fournisseur généré par Odoo. Pour le paiement, les [modules SEPA de l’Odoo Community Association] (https://github.com/OCA/bank-payment) peuvent être utilisés par le client pour générer un fichier XML de virement SEPA (avec le module * compte \ _banking \ _sepa \ _credit \ _transfer *) ou par le fournisseur pour générer un fichier de prélèvement SEPA (avec le module * account \ _banking \ _sepa \ _direct \ _debit *).
Ce processus est illustré dans le diagramme ci-dessous:
S’il vous plaît regarder [ce screencast] (http://public.akretion.com/odoo_electronic_orders_ubl.ogv) (19 minutes de long, 141 Mo, ou regarder en qualité inférieure sur [Youtube] (https://youtu.be/bs8GPYlHa9Y) ) qui montre une démo d’un flux de travaux d’approvisionnement entre un fournisseur et un client, de la demande d’offre à la facturation. Avec ce screencast, vous comprendrez tous les avantages des piles UBL et ZUGFeRD d’Odoo développées par Akretion.
Le support des commandes électroniques et des factures électroniques avec les standards ZUGFeRD et UBL dans Odoo utilise 23 modules OCA ([Odoo Community Association] (https://odoo-community.org/)) situés dans 2 projets OCA différents:
- le projet [edi] (https://github.com/OCA/edi/tree/8.0),
- le projet [partner contact] (https://github.com/OCA/partner-contact/tree/8.0).
Ces modules utilisent la nouvelle API d’Odoo et la plupart d’entre eux ont une suite de tests automatisée. Ces modules sont pour Odoo v8 mais la plupart ont été porté sur Odoo v9 ou v10.
L’abbaye de Barroux, l’abbaye de Randol et le monastère de La Garde on été les premiers utilisateurs de ces modules à échanger des commandes et des factures. Leurs retours a été essentiels pour affiner la pile UBL d’Odoo.
Après ce premier déploiement, la prochaine étape consistera à tester l’interopérabilité de la pile UBL d’Odoo avec d’autres ERP. Selon [ce blog] (https://blog.tradeshift.com/ubl-is-o-o- international-standard-so-now-what/), les solutions Oracle, SAP et Microsoft ERP supportent maintenant UBL nativement ou via des modules complémentaires tiers.
Alexis de Lattre, qui a développé la pile UBL d’Odoo, déclare: « Le développement de la pile UBL d’Odoo est probablement ma plus grande contribution en matière d’opensource! Je suis très enthousiaste au sujet du potentiel des commandes électroniques basées sur UBL et des factures électroniques pour les transactions B2B. J’espère que nous n’aurons pas à attendre trop longtemps avant d’avoir incorporé des fichiers XML UBL dans la plupart des commandes PDF et des factures PDF! “
Cette contribution opensource vous est proposée gratuitement par Akretion sous la licence [AGPL] (https://www.gnu.org/licenses/agpl.html). Si vous avez des commandes ou des factures UBL réelles, nous vous serions reconnaissants de nous en transmettre une copie afin que nous puissions améliorer notre connaissance du standard UBL et affiner la pile UBL d’Odoo (nous conserverons ces fichiers confidentiels à moins que vous nous donnez une autorisation explicite pour les publier).
