Interfaces, échanges et rendez-vous : points d'entrée, imports, agenda

Faire entrer et sortir des données d'un ERP prend quatre formes : un point d'entrée que l'on déclare sans écrire de module, un appel sortant vers un service tiers, un fichier déposé sur un serveur, et un agenda qui s'échange avec le reste du monde.

Vingt-quatre modules communautaires les couvrent, et terminent le catalogue hors localisations étrangères.

Résumé

Huit modules traitent les points d'entrée : le socle qui les déclare depuis l'interface, l'authentification par clé d'API, le cache avec son préchauffage, la sérialisation JSON paramétrable, un service web sortant avec son référentiel de connexions, sa variante hors base, et un point d'entrée de catalogue produit.

Trois modules traitent les imports par sessions : un moteur d'import avec ses sources, ses types et ses jeux d'enregistrements, son volet produits, et une source de fichiers sur un serveur distant.

Six modules traitent les échanges avec une plateforme espagnole de dématérialisation : le socle, l'envoi des factures, l'import des commandes de vente, l'envoi des bons de livraison, et deux modules de correspondance des unités secondaires.

Cinq modules traitent l'agenda : la description sur sa propre page, la couleur par type d'événement, l'export et l'import de fichiers d'agenda, et une application de réservation de ressources avec ses combinaisons, ses types et ses horaires.

Deux modules enfin ajoutent les modes de paiement sur les factures et sur les commandes de vente, et un dernier empêche la suppression automatique des SMS envoyés.

L'essentiel

• Un point d'entrée HTTP déclaré depuis l'interface.
• Un cache de réponse avec préchauffage.
• Un service web sortant avec son référentiel de connexions.
• Un moteur d'import par sessions avec ses sources.
• Une source de fichiers sur un serveur distant.
• Des échanges de factures avec une plateforme de dématérialisation.
• Un export et un import de fichiers d'agenda.
• Une réservation de ressources avec créneaux et portail.

Ce que ces modules ajoutent à l'instance

Les menus : Paramètres ▸ Technique ▸ Endpoints et Paramètres ▸ Technique ▸ WebService Backend ; une application Importer avec ses backends, ses jeux d'enregistrements, ses sources et ses types ; Ventes ▸ Analyse ▸ Voxel order Jobs ; Calendrier ▸ Calendar Event Type, Calendrier ▸ Configuration ▸ Export to Ics File et ▸ Import Ics File ; une application Réservations de ressources ; Facturation ▸ Configuration ▸ Gestion ▸ Modes de paiement.

Déclarer un point d'entrée sans écrire de module

La demande la plus fréquente d'un intégrateur tiers est la plus coûteuse à satisfaire : « exposez-moi cette donnée sur une adresse ». Écrire un module pour chaque adresse demandée produit un dépôt maison de vingt modules d'une page, qu'il faudra migrer.

endpoint (version 18.0.1.1.4, LGPL-3) répond autrement : les points d'entrée se déclarent depuis l'interface, sous Paramètres ▸ Technique ▸ Endpoints — une adresse, une méthode, un traitement. Il repose sur le module de gestion de routes et sur un module d'aide aux appels distants.

• endpoint_auth_api_key ajoute l'authentification par clé d'API, avec ses groupes de clés.
• endpoint_cache ajoute un cache de réponse, et endpoint_cache_preheat son préchauffage par tâche de fond — remplir le cache avant la première demande.
• endpoint_jsonifier permet de paramétrer la sérialisation JSON du point d'entrée : décrire la forme de la réponse, plutôt que l'écrire.

endpoint_product_catalog est le seul module de son dépôt : il expose un catalogue produit sur un point d'entrée, en s'appuyant sur les assortiments.

Pour une API plus structurée, avec routes typées et journal d'appels, voir exposer une API depuis Odoo.

Appeler un service tiers

L'inverse du point d'entrée est l'appel sortant. webservice (version 18.0.1.1.2, AGPL-3) fournit une définition abstraite de service web avec son référentiel de connexions sous Paramètres ▸ Technique ▸ WebService Backend : adresse, mode d'authentification, en-têtes.

Sans ce référentiel, chaque module qui appelle un service tiers porte sa propre adresse et son propre identifiant, en dur ou dans un paramètre système. Le jour où le service change d'adresse, il faut les retrouver un par un.

webservice_server_env permet de décrire ces connexions hors base, dans un fichier d'environnement : la recette appelle le bac à sable, la production le service réel, sans modifier la base.

Ce mécanisme de configuration hors base est traité dans le socle technique.

Importer par sessions, depuis un fichier déposé

connector_importer (version 18.0.1.2.1, AGPL-3) traite les sessions d'import : une application Importer avec ses backends, ses jeux d'enregistrements, ses sources et ses types d'import. Il s'appuie sur le cadre de connecteurs et sur la file de travaux de fond.

La différence avec l'import natif d'Odoo est celle entre un geste et un processus. L'import natif est un fichier qu'un utilisateur dépose une fois, dans sa requête. Une session d'import est un type déclaré, une source surveillée, des lignes en erreur consultables et un rejeu possible.

• connector_importer_product facilite la définition des imports de produits.
• connector_importer_source_sftp ajoute une source capable de lire des fichiers sur un serveur distant — le fichier est déposé par un tiers, l'import se déclenche seul.

C'est le trio qui transforme un échange de fichiers récurrent en flux : un partenaire dépose son tarif chaque nuit, la session le prend, et les lignes en erreur sont lisibles le matin.

Le stockage externe des pièces jointes est traité dans stockage externe.

Les échanges avec une plateforme de dématérialisation

Six modules intègrent une plateforme espagnole de dématérialisation nommément désignée dans leurs README. edi_voxel_oca est le socle ; il dépend de la comptabilité, du référentiel de pays normalisé, des informations client sur le produit, de la file de travaux et des rapports XML.

• edi_voxel_account_invoice_oca envoie les factures à la plateforme.
• edi_voxel_sale_order_import_oca importe les commandes de vente qui en viennent, avec son suivi de tâches sous Ventes ▸ Analyse ▸ Voxel order Jobs.
• edi_voxel_stock_picking_oca envoie les bons de livraison.
• edi_voxel_secondary_unit_oca et edi_voxel_sale_secondary_unit_oca font correspondre les codes d'unité de la plateforme aux unités secondaires d'Odoo.

Ce lot n'a pas d'usage en France : la plateforme visée est espagnole, et la réforme française s'appuie sur d'autres formats et d'autres plateformes. Il est documenté ici parce qu'il montre la forme complète d'une intégration de dématérialisation — socle, envoi, import, correspondance d'unités.

Pour la France, voir le socle EDI : UBL et Factur-X et le cadre EDI de l'OCA.

L'agenda et les réservations

Quatre petits modules corrigent l'agenda d'Odoo : calendar_event_description_layout place la description sur sa propre page du formulaire, calendar_event_type_color colore la vue selon le type d'événement, et deux modules ajoutent l'export et l'import de fichiers d'agenda au format standard, sous Calendrier ▸ Configuration.

L'import et l'export de fichiers d'agenda sont la seule façon simple de faire circuler un planning hors d'Odoo : un fichier que n'importe quel agenda sait lire, sans synchronisation bidirectionnelle à surveiller.

resource_booking (version 18.0.1.0.14, AGPL-3) est le module substantiel du dépôt : une application Réservations de ressources avec ses types, ses combinaisons de ressources, ses ressources, leurs temps libres et leurs horaires de travail. Il s'appuie sur le portail — le client réserve lui-même — et sur un module de durée de créneau.

C'est la prise de rendez-vous communautaire : un type de réservation, une durée, des ressources qui doivent être libres ensemble, et un créneau proposé au client sur le portail.

Trois modules isolés

account_payment_base_oca (version 18.0.1.8.0) étend les objets de paiement natifs d'Odoo, avec son référentiel sous Facturation ▸ Configuration ▸ Gestion ▸ Modes de paiement. account_payment_base_oca_sale ajoute le mode de paiement sur la commande de vente — le choix est fait à la vente, pas à la facture.

Ces deux modules forment une alternative au lot principal de paiement bancaire : ils vivent dans un dépôt séparé parce qu'ils proposent une autre façon de modéliser la même chose. Ils ne s'installent pas ensemble sans examen.

sms_no_automatic_delete empêche la suppression automatique des SMS envoyés : Odoo les purge, ce module les conserve. C'est une exigence de preuve — savoir ce qui a été envoyé, et quand.

Limites connues

• Un point d'entrée déclaré depuis l'interface est du code exécutable saisi en base : il doit être réservé à un groupe restreint, et relu comme du code.
• Le cache de point d'entrée ne sait pas ce qui est périmé : son préchauffage dépend de la file de travaux, donc de son exploitation.
• Les six modules de dématérialisation visent une plateforme espagnole : ils n'ont pas d'usage dans la réforme française, qui s'appuie sur d'autres formats et d'autres plateformes.
• Le moteur d'import par sessions dépend du cadre de connecteurs et de la file de travaux : c'est une infrastructure, pas un bouton d'import.
• La source de fichiers distante suppose un stockage externe déclaré : le module ne gère pas la connexion, il l'utilise.
• L'import et l'export de fichiers d'agenda ne sont pas une synchronisation : un fichier part, un fichier entre, et rien ne se tient à jour tout seul.
• La réservation de ressources expose le portail : ouvrir la prise de rendez-vous à l'extérieur demande une revue des droits et des créneaux publiés.
• Les deux modules de paiement alternatifs ne s'ajoutent pas au lot principal : ils modélisent la même chose autrement, et le choix se fait avant l'installation.
• Conserver les SMS envoyés a un coût de volume : la purge native existe pour une raison.

Identité technique

Les vingt-quatre modules viennent de six dépôts OCA, branche 18.0 — web-api, web-api-contrib, connector-interfaces, edi-voxel, calendar, bank-payment-alternative et connector-telephony —, désormais tous documentés ici. Dix-sept sont en AGPL-3, sept en LGPL-3. Les dépendances : endpoint_route_handler, rpc_helper, auth_api_key_group, jsonifier, component, component_event, connector, queue_job, storage_backend_sftp, server_environment, product_assortment, base_iso3166, product_customerinfo, report_xml, stock_picking_invoice_link, onchange_helper, product_secondary_unit, sale_order_secondary_unit, product_expiry, sale_stock, account_payment_method_base, web_calendar_slot_duration, resource, portal, calendar, sms et mail.

Voir aussi le socle technique et identité fédérée, clés d'API et jetons.

Questions fréquentes

Peut-on exposer une adresse HTTP dans Odoo sans écrire de module ?

Oui, avec endpoint : les points d'entrée se déclarent sous Paramètres ▸ Technique ▸ Endpoints — une adresse, une méthode, un traitement. C'est du code exécutable saisi en base, donc à réserver à un groupe restreint et à relire comme du code. Une clé d'API, un cache et une sérialisation paramétrable s'y ajoutent.

Comment éviter qu'une adresse de service tiers soit écrite en dur dans dix modules ?

Avec webservice : un référentiel de connexions sous Paramètres ▸ Technique ▸ WebService Backend, avec son adresse, son authentification et ses en-têtes. webservice_server_env les décrit même hors base — la recette appelle le bac à sable, la production le service réel, sans modifier la base.

Quelle différence avec l'import natif d'Odoo ?

Celle entre un geste et un processus. L'import natif est un fichier déposé une fois, dans la requête de l'utilisateur. connector_importer déclare un type d'import, une source surveillée — y compris un serveur distant —, et laisse les lignes en erreur consultables et rejouables. En échange, il demande le cadre de connecteurs et la file de travaux.

Les modules edi_voxel_* servent-ils pour la facturation électronique française ?

Non : la plateforme visée est espagnole, nommément désignée dans leurs README. La réforme française s'appuie sur d'autres formats et d'autres plateformes. Ces modules restent intéressants comme modèle d'intégration complète — socle, envoi, import, correspondance d'unités.

Odoo Community sait-il gérer une prise de rendez-vous ?

Avec resource_booking : des types de réservation, des combinaisons de ressources qui doivent être libres ensemble, leurs horaires et leurs temps libres, et un créneau proposé au client sur le portail. Ouvrir cela à l'extérieur demande une revue des droits et des créneaux publiés.

Se faire accompagner

Ce lot est celui des frontières : ce qui entre, ce qui sort, et ce qui s'échange. Il contient à la fois les outils les plus utiles d'une intégration — déclarer un point d'entrée, surveiller un dépôt de fichiers — et le piège le plus fréquent : un point d'entrée est du code saisi en base, qu'aucune relecture ne verra passer.

Nous déclarons donc les points d'entrée comme du code, avec leur clé d'API et un groupe restreint, et nous préférons une session d'import surveillée à un fichier déposé à la main — parce que c'est la seule forme qui laisse une trace le matin. Voir les prestations d'Atalios Consulting ou demander un rappel.

Pour aller plus loin

• Le socle technique d'Odoo
• Exposer une API depuis Odoo

En résumé

Faire entrer et sortir des données d'un ERP prend quatre formes : un point d'entrée déclaré sans écrire de module, un appel sortant vers un service tiers, un fichier déposé sur un serveur, et un agenda qui s'échange. Vingt-quatre modules les couvrent. Parlons de vos intégrations.