Guide d’intégration d’Odoo à SkyPlanner APS pour l’ordonnancement de la production

Anticipez cette suppression dès maintenant. Odoo a prévu de supprimer XML-RPC et JSON-RPC dans Odoo 22 (automne 2028) et Odoo Online 21.1 (hiver 2027). Pour la version 19.0, développez sur JSON-2. Pour les bases plus anciennes, isolez les appels RPC derrière un adaptateur unique : la montée de version ne nécessitera ainsi qu’une seule modification. Les contrôleurs personnalisés utilisant @route(type='jsonrpc') ne sont pas concernés par cette suppression.

Authentification

Créez un utilisateur dédié à l’intégration, avec des droits de lecture sur Manufacturing et Inventory et des droits d’écriture sur les ordres de fabrication. Générez sa clé dans Preferences > Account Security > New API Key. En version 19.0, les clés sont valides pendant trois mois au maximum. Le middleware doit donc gérer leur rotation et déclencher une alerte en cas d’échec d’authentification. Sans ces mécanismes, une clé expirée interrompt la synchronisation sans que personne ne le remarque. Côté SkyPlanner, l’API REST utilise JWT : le middleware conserve donc les deux jeux d’identifiants.

Chaque appel JSON-2 s’exécute dans sa propre transaction SQL. Une écriture répartie sur plusieurs appels n’est donc pas atomique. Effectuez les écritures ordre de fabrication par ordre de fabrication et journalisez chaque résultat.

Événements

Odoo transmet les modifications au moyen de règles d’automatisation. Une règle sur mrp.production ou mrp.workorder, avec le déclencheur On create and edit (à la création et à la modification) et l’action « Send Webhook Notification » (envoyer une notification webhook), envoie une requête POST contenant les champs sélectionnés vers une URL. Créez cette règle dans Studio ou, en mode développeur, depuis le formulaire Automation Rules (règles d’automatisation). Complétez-la par une interrogation périodique avec search_read sur write_date pour récupérer les imports et les modifications que la règle n’a pas captés. Dans l’autre sens, les webhooks SkyPlanner transmettent les changements de planning et d’état dès qu’ils se produisent.

Les noms de champs varient selon les versions. En 19.0, chaque base répertorie ses modèles, champs et méthodes à l’adresse /doc ; sur les versions antérieures, appelez fields_get. Établissez les correspondances à partir de ces informations, pas de mémoire.

«  POST /json/2/mrp.workorder/write Authorization: bearer <api-key> {"ids": [4711], "vals": {"date_start": "2026-11-03 06:00:00", "date_finished": "2026-11-03 09:30:00", "workcenter_id": 7}} « 

JSON-2 reçoit chaque argument de méthode par son nom, ainsi que ids et context : l’argument de write(vals) est donc transmis sous la clé vals. Sur les versions 16.0 à 18.0, le même appel passe par execute_kw(db, uid, key, 'mrp.workorder', 'write', [[4711], vals]) via XML-RPC ou JSON-RPC. En 16.0, les clés sont date_planned_start et date_planned_finished. Les dates et heures sont transmises en UTC. Quelques règles permettent de fiabiliser l’écriture :

• Envoyez les deux dates dans le même appel.
• N’ajoutez workcenter_id que si le moteur a choisi une machine de remplacement.
• Modifiez uniquement les champs d’ordonnancement, jamais les quantités ni les nomenclatures.

L’écriture des dates déplace la réservation du poste de charge dans Odoo. Les vues de planification d’Odoo affichent ainsi le planning de SkyPlanner.

Remontée des données de l’atelier vers Odoo. Les opérateurs enregistrent leur travail dans SkyPlanner Mobile Confirmations. Pour chaque confirmation, l’intégration appelle create sur mrp.workcenter.productivity (JSON-2 : POST /json/2/mrp.workcenter.productivity/create avec vals_list). Elle renseigne workorder_id, workcenter_id, date_start, date_end et un loss_id de type Productive. Les temps et les coûts de main-d’œuvre sont alors enregistrés dans Odoo.

Lorsqu’une opération est terminée, l’intégration renseigne la quantité produite et appelle button_finish sur l’ordre de fabrication. Une fois le dernier ordre de fabrication terminé, l’ordre de production est prêt pour l’appel à button_mark_done. Chaque confirmation n’est enregistrée qu’une fois, et l’identifiant de son enregistrement Odoo est conservé avec le relevé de temps SkyPlanner. Ainsi, une nouvelle tentative d’envoi du webhook ne crée jamais de second Time Log.

Dans les usines qui utilisent l’application Enterprise Shop Floor, le flux est inversé : SkyPlanner lit l’état des ordres de fabrication et qty_produced, puis Autopilot recalcule automatiquement le planning lorsque la production évolue.

Système maître. Consignez les règles par écrit avant la mise en production :

Les planificateurs ne doivent plus utiliser les boutons Plan et Unplan d’Odoo pour les ordres de production ordonnancés par SkyPlanner. Sinon, Odoo réserve ses propres créneaux à la place des dates définies par SkyPlanner.

• Champs de date renommés. Jusqu’à la version 16.0, date_planned_start et date_planned_finished contenaient les dates prévues, et date_start/date_finished les dates réelles. À partir de la version 17.0, date_start et date_finished correspondent aux dates prévues. Une correspondance reprise d’un projet en 16.0 interprète les dates réelles comme des dates prévues sur 17+, sans signaler d’erreur.
• Les dates des ordres de fabrication correspondent à des réservations. En 19.0, date_start et date_finished sur mrp.workorder sont calculés à partir d’un enregistrement resource.calendar.leaves (leave_id) dans le calendrier du poste de charge. Écrire les dates sur l’ordre de fabrication met à jour cette réservation. N’écrivez jamais directement dans la table des absences.
• Les ordres de fabrication démarrés bloquent la déplanification. Odoo refuse de déplanifier un ordre de production lorsque « Some work orders have already started » (certains ordres de fabrication ont déjà démarré). Lors de la réécriture, ignorez les ordres de fabrication à l’état progress ou done et ne déplacez que ceux qui n’ont pas démarré.
• Des durées qui évoluent. Les opérations réglées sur Computed tirent leur durée des derniers ordres de fabrication (10 par défaut), avec application du coefficient Time Efficiency. Réglez-les sur Fixed pour l’essai, ou acceptez que les données d’entrée évoluent. Les opérations sont définies dans chaque nomenclature, sans référentiel commun de gammes de fabrication : chaque nomenclature doit donc être fiabilisée séparément.
• Des calendriers mal configurés. Chaque poste de charge doit disposer d’un calendrier d’horaires de travail. Le planificateur d’Odoo recherche un créneau jusqu’à 700 jours à l’avance, puis s’arrête avec le message « Impossible to plan the workorder » (impossible de planifier l’ordre de fabrication). Corrigez les calendriers avant le premier chargement.
• Unités de mesure. mrp.bom.line possède son propre product_uom_id, qui peut différer de l’unité de stock du produit. Effectuez la conversion avant de vérifier la disponibilité des matières.

C’est la réécriture des données dans Odoo qui donne à l’intégration sa valeur au quotidien. Une fois ce flux en place :

• Les ordres de fabrication Odoo disposent de dates concrètes. Le moteur Arcturus AI ordonnance tous les ordres de production ouverts en quelques secondes. Les dates et les postes de travail qu’il choisit sont enregistrés dans mrp.workorder et affichés dans les vues de planification d’Odoo.
• Plus de réordonnancement manuel. Autopilot recalcule automatiquement le planning lorsque la production change, et le webhook transmet les nouvelles dates à Odoo.
• L’atelier assure le retour d’information. Les opérateurs enregistrent leur travail sur téléphone ou tablette avec Mobile Confirmations, Production Timer et Quick Log Mode. Les Time Logs sont transmis à Odoo pour la gestion des stocks et le calcul des coûts. L’ordonnancement et l’exécution sont réunis dans un seul outil, aussi bien avec Community qu’avec Enterprise.
• Le planning intègre des contraintes qu’Odoo ne gère pas. Une matrice des temps de changement de série définit, pour chaque paire de produits, les temps de transition selon leur ordre de passage. Les outils sont des ressources à capacité finie partagées entre les machines, et une opération peut mobiliser plusieurs opérateurs simultanément. Le moteur se tourne vers des machines ou du personnel de remplacement lorsque la ressource principale est indisponible. Les dates réécrites dans mrp.workorder respectent toutes ces contraintes.
• Les arrivées de matières guident le planning. Le stock disponible et les commandes fournisseurs ouvertes dans Odoo alimentent l’ordonnancement en fonction des matières. Les composants commandés sont considérés comme disponibles à la date de livraison de la commande fournisseur, et le stock est mis à jour lorsque celle-ci passe au statut Delivered. Pour chaque opération, la disponibilité des matières est vérifiée en tenant compte du stock en entrepôt et des livraisons attendues.

Vous pouvez évaluer le planning avant tout travail d’intégration. Lancez l’essai gratuit de 30 jours à partir d’exports CSV et retrouvez vos propres ordres de fabrication Odoo sur le diagramme de Gantt, avec jusqu’à 20 postes de travail et sans carte bancaire. Les tarifs commencent à 199 € par mois, avec 5 postes de travail inclus, une facturation mensuelle et une résiliation possible à tout moment. L’intégration fait l’objet d’un devis préalable adapté à vos processus et à vos besoins, présenté avec votre abonnement : vous connaissez ainsi le coût total avant de commencer. Découvrez les fonctionnalités et nos clients, ou réservez une démo.