Guide d’intégration d’Epicor Kinetic pour l’ordonnancement de la production avec SkyPlanner APS

Epicor indique : « All Kinetic services, including business objects, processes, reports, BAQs, and Epicor Functions, are accessible through REST endpoints. » (Tous les services Kinetic, y compris les objets métier, les processus, les rapports, les BAQ et les Epicor Functions, sont accessibles via des points de terminaison REST.) Une intégration pour l’ordonnancement repose sur quatre technologies Epicor :

1. Kinetic REST API v2 (OData v4). Les objets métier sont exposés sous forme de services nommés Erp.BO.<Name>Svc. Le chemin habituel est /api/v2/odata/{Company}/Erp.BO.{Svc}/{EntitySet}. REST v1 existe toujours, mais il s’agit d’une version héritée : développez donc sur la v2. Vérifiez les jeux d’entités et les méthodes de votre version dans REST Help à l’adresse /api/help/v2/.
2. Business Activity Queries (BAQ) via REST. Une BAQ est exposée à l’adresse /api/v2/odata/{Company}/BaqSvc/{BAQ}/Data. C’est une solution pratique pour extraire les données de planification en joignant JobHead, JobOper, JobMtl, PartWhse et PORel en un seul appel (exemple de la communauté).
3. Epicor Functions (EFx). Ces fonctions côté serveur peuvent être appelées à l’adresse /api/v2/efx/{Company}/{Library}/{Function}. Epicor précise qu’elles « can be triggered from multiple entry points, including BPMs, REST services, schedules, and application events. » (peuvent être déclenchées depuis plusieurs points d’entrée, notamment les BPM, les services REST, les tâches planifiées et les événements de l’application).
4. Directives BPM. Les Method Directives et les Data Directives se déclenchent lorsqu’un ordre de fabrication ou une opération change. Elles peuvent appeler une fonction qui transmet les données à un système externe.

Pour les fichiers, DMT prend en charge les imports et les exports BAQ assurent les extractions. Epicor propose aussi Epicor Automation Studio, qu’il décrit comme « a low-code app for integration-led automations » (une application low-code pour les automatisations reposant sur l’intégration). Évitez l’accès direct à la base de données : REST, les BAQ et les fonctions s’utilisent de la même manière sur site et sur Kinetic Cloud.

Epicor ne documente aucune API générique de webhooks sortants. Les changements de Kinetic parviennent donc à SkyPlanner de l’une des deux manières suivantes :

• Sur événement. Une directive BPM Data Directive sur JobHead ou JobOper appelle une Epicor Function, qui transmet l’ordre de fabrication modifié à l’API REST de SkyPlanner.
• Interrogation périodique. Une BAQ filtrée sur la date de modification s’exécute à quelques minutes d’intervalle ou toutes les heures. Cette approche est plus simple à maintenir et à remettre en service après un incident.

Dans l’autre sens, SkyPlanner transmet les changements d’état et de planning via ses webhooks. Votre middleware ou un point de terminaison EFx les reçoit et les écrit dans Kinetic.

1. Chargement initial des données de base. Récupérez les articles, les groupes de ressources, les ressources, les capacités, les calendriers et les employés. Créez les postes de travail SkyPlanner à partir des ressources Kinetic, et les groupes de postes à partir des groupes de ressources. Pour les lectures volumineuses, paginez les résultats avec $top et $skip, ou extrayez les données en masse via une BAQ.

2. Synchronisation des ordres. Envoyez les ordres de fabrication lancés et fermes avec leurs opérations et leurs matières. Récupérez l’arborescence de l’ordre avec GetDatasetForTree ou une BAQ, plutôt qu’entité par entité. Laissez les ordres MRP non fermes dans Kinetic jusqu’à leur affermissement. En parallèle de la lecture des stocks, synchronisez les échéances ouvertes des commandes fournisseurs avec leurs dates prévues. SkyPlanner considère les matières commandées comme disponibles à la date de livraison et met le stock à jour lorsque la commande fournisseur passe au statut Delivered. L’ordonnancement tient ainsi compte à la fois du stock et des achats attendus.

3. Réécriture du planning dans Kinetic. Le webhook de SkyPlanner transmet le début, la fin et le poste de travail planifiés pour chaque opération à un point de terminaison EFx (/api/v2/efx/{Company}/{Library}/{Function}). La fonction écrit les données via le moteur d’ordonnancement de Kinetic, le même objet métier qui sous-tend l’ordonnancement dans Job Entry et les tableaux d’ordonnancement (exemple de la communauté) :

1. ScheduleEngine.GetNewParamsForJob construit le jeu de données du moteur d’ordonnancement pour l’ordre de fabrication.
2. La fonction définit le numéro d’ordre de fabrication, les séquences d’assemblage et d’opération ainsi que la date et l’heure de début planifiées, puis appelle ScheduleEngine.MoveJobItem.
3. Si SkyPlanner a placé l’opération sur une autre ressource du groupe, ScheduleEngine.ChangeResource l’y déplace. À lui seul, MoveJobItem conserve la ressource par défaut du groupe.
4. La fonction verrouille l’ordonnancement de l’ordre de fabrication (JobHead.SchedLocked, l’option Lock dans Job Entry), afin que Global Scheduling conserve les dates de SkyPlanner.

Regrouper ces appels dans une seule Epicor Function garantit une écriture atomique pour chaque ordre de fabrication et permet d’ajouter vos propres validations. Si un site préfère se passer de fonction personnalisée, la même séquence peut s’exécuter par des appels REST directs à Erp.BO.ScheduleEngineSvc. N’écrivez jamais directement dans ResourceTimeUsed ni dans les champs de date de JobOper : cela contourne le moteur et désynchronise les affectations des tableaux d’ordonnancement.

4. Déclarations d’atelier. Les opérateurs enregistrent leur travail dans SkyPlanner avec Mobile Confirmations, Production Timer ou Quick Log Mode. Chaque relevé de temps clôturé devient une déclaration de main-d’œuvre dans Kinetic via Erp.BO.LaborSvc : StartActivity et EndActivityByEmp pour l’activité en cours, ou Labors avec Update pour les saisies a posteriori. Si votre site exige une approbation, incluez submitForApproval dans le flux et dans le périmètre des autorisations.

5. Responsabilité des données et gestion des conflits. Consignez ces règles avant la mise en production :

Les ordres de fabrication ordonnancés par SkyPlanner sont verrouillés pour l’ordonnancement : Global Scheduling ne modifie donc pas leurs dates. Conservez l’ordonnancement Kinetic pour les ressources que SkyPlanner ne planifie pas.

La mise en œuvre est généralement achevée dans les semaines qui suivent le début de l’accompagnement. Un projet Kinetic comprend :

1. Un essai de 30 jours à partir d’exports CSV ou Excel des ordres de fabrication, des opérations et des ressources, avant tout développement.
2. La clé API, le périmètre d’accès, un compte utilisateur dédié à l’intégration et les BAQ lues par celle-ci.
3. La mise en correspondance des données de base : aptitudes, groupes de ressources, ressources, calendriers et salariés avec les postes de travail, groupes, horaires d’équipe et membres du personnel de SkyPlanner.
4. Le chargement initial des articles, des méthodes de fabrication (BOM et opérations) et des ressources.
5. Synchronisation des ordres de fabrication et des commandes fournisseurs (dates prévues de PORel), ainsi que du stock PartWhse.
6. Réécriture des dates planifiées des opérations dans Kinetic via ScheduleEngineSvc (MoveJobItem, ChangeResource), au sein d’une Epicor Function, avec verrouillage de l’ordre de fabrication.
7. Transmission des déclarations d’atelier sous forme de déclarations de main-d’œuvre via LaborSvc.
8. Des tests en parallèle du planning Kinetic actuel, puis la mise en production.

Chaque usine utilise Kinetic à sa manière. Les gammes de fabrication fondées sur les aptitudes, les calendriers des groupes de ressources, la conception des BAQ, les directives BPM et les méthodes de réécriture propres à chaque version varient d’un site à l’autre. Bien les configurer fait la différence entre un planning auquel les ordonnanceurs font confiance et un planning qu’ils doivent retravailler.

1. L’équipe SkyPlanner configure l’intégration lors de la mise en place et en assure le support après la mise en production. Elle établit les correspondances pour vos ressources, vos ordres de fabrication et vos échéances de commandes d’achat, puis configure les lectures BAQ, les déclencheurs BPM et la fonction de réécriture. Elle connecte l’API REST et les webhooks de SkyPlanner à Kinetic REST v2. Le support se poursuit lorsque vos BAQ, vos BPM ou votre version de Kinetic changent.
2. Votre partenaire Epicor. Les partenaires qui développent déjà des BAQ, des BPM et des Epicor Functions peuvent utiliser la même API REST documentée de SkyPlanner. Elle permet de lire et d’écrire les ordres, les produits, les matières, les étapes de fabrication et les pointages.
3. Vos propres développeurs. Vos équipes internes expérimentées avec Kinetic REST peuvent développer directement, ou dans Automation Studio si vous l’utilisez. Une clé API SkyPlanner suffit pour commencer (tutoriel d’intégration), et l’équipe SkyPlanner vous aide au besoin. La documentation du produit est accessible à tous dans la documentation SkyPlanner.

Ce même schéma associant API et webhooks fonctionne en production avec d’autres ERP, par exemple chez UTU. Chez Laboratory & Allied, l’équipe informatique interne a réalisé l’intégration SAP Business One en grande partie elle-même, avec l’aide de SkyPlanner.

Quelle que soit l’approche, le point de départ reste le même : commencez par l’essai gratuit de 30 jours avec des imports CSV, validez le planning, puis développez l’intégration. Les tarifs démarrent à 199 € par mois pour 5 postes de travail, avec facturation mensuelle et résiliation à 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.