Guide d’intégration de JobBOSS² pour l’ordonnancement de la production avec SkyPlanner APS

ECI publie ses API pour l’industrie, avec leurs spécifications OpenAPI, sur le site de documentation des API de production d’ECI. Deux sont utiles pour l’ordonnancement :

1. JobBOSS² API (v1). Une API REST au format JSON, propre à JobBOSS². Elle permet de lire et d’écrire les commandes, Order Line Items, Order Routings, Estimates, Routings, les matières, Job Requirements, Work Centers, Company Calendar, Employees, les commandes fournisseurs, Time Tickets et Time Ticket Details. ECI précise qu’elle « is currently only supported for JobBOSS² hosted (Cloud) customers. » (n’est actuellement prise en charge que pour les clients JobBOSS² hébergés dans le cloud).
2. ECI ERP API (v2.1). Une REST API commune à Deacom, M1 et JobBOSS². Pour JobBOSS², elle couvre les ordres de fabrication, leurs opérations et leurs matières, les articles et leurs opérations, les postes de charge, les lignes de commandes fournisseurs et les lignes de relevés de temps. ECI indique que « the actual ERP database could be a cloud hosted ERP or on premises install, » (la base de données ERP peut être hébergée dans le cloud ou installée sur site). C’est donc l’interface à utiliser pour JobBOSS² sur site.

Les deux API suivent les mêmes conventions : des expressions de filtrage telles que lastModDate[gte]=, un paramètre fields=, sort= et une pagination avec take et skip. La valeur par défaut de take est 200. « All dates submitted to the API are assumed to be in UTC. » (Toutes les dates transmises à l’API sont considérées comme étant en UTC.)

La règle d’ECI s’applique aux deux API : « All APIs must be activated by ECI before use. » (Toutes les API doivent être activées par ECI avant utilisation.) Contactez votre responsable de compte ECI dès le début du projet.

Aucune des deux API d’ECI ne documente de webhooks. Les données de JobBOSS² sont récupérées par interrogation périodique : filtrez les objets Order Line Items, Order Routings et les lignes de commandes fournisseurs sur lastModDate depuis la dernière exécution, puis paginez avec take et skip. La fréquence est définie pour chaque atelier : toutes les quelques minutes pour les ordres de fabrication, toutes les heures pour les stocks.

SkyPlanner envoie des webhooks lors d’un changement d’état ou d’une modification du planning. Le renvoi des données est donc déclenché par les événements.

1. Chargement initial des données de base. Lisez les objets Estimates, Routings, les matières, Work Centers, Company Calendar et Employees. Définissez soigneusement la correspondance des postes de charge : un poste de charge comprenant quatre tours devient un groupe de postes de travail ou quatre postes de travail, pour que SkyPlanner ordonnance le travail sur chaque machine.

2. Synchronisation des ordres de fabrication. Lisez les Order Line Items ouverts avec leurs Order Routings, Job Requirements et lignes de commandes fournisseurs ouvertes. SkyPlanner considère les matières commandées comme disponibles à la date de livraison de la commande fournisseur et met le stock à jour lorsque celle-ci passe au statut Delivered. Excluez les ordres de fabrication suspendus et clôturés.

3. Renvoi du planning. Lorsque le moteur positionne ou déplace une étape, un webhook SkyPlanner déclenche une requête PATCH vers /api/v1/orders/{orderNumber}/order-line-items/{itemNumber}/order-routings/{stepNumber}. Cette requête renseigne estimatedStartDate et estimatedEndDate en UTC, ainsi que workCenter et employeeCode si SkyPlanner a réaffecté l’étape à une autre machine ou à une autre personne. Les dates sont inscrites sur les étapes de fabrication déjà affichées dans Whiteboard, Planning Board et Scheduling Advisor.

4. Déclarations en atelier. Les opérateurs enregistrent leur travail avec SkyPlanner Mobile Confirmations ou Production Timer, et les relevés de temps maintiennent le planning à jour. Vous choisissez si les temps réels sont renvoyés vers JobBOSS². Si oui, chaque déclaration devient un Time Ticket Detail avec le temps de réglage, le temps de cycle et les quantités de pièces. Sinon, la collecte des données reste dans JobBOSS² et SkyPlanner lit l’avancement dans Order Routings.

5. Systèmes de référence et règles de gestion des conflits. Consignez ces règles avant la mise en production :

Désignez un seul système pour écrire les dates des étapes de fabrication. Pour les ordres de fabrication qu’il ordonnance, SkyPlanner remplace la replanification dans Whiteboard : les responsables de l’ordonnancement déplacent donc les opérations dans SkyPlanner, puis les dates sont transmises à JobBOSS².

• Hébergement ou installation sur site. JobBOSS² API s’adresse aux clients hébergés. Les installations sur site utilisent ERP API, dont la liste des ressources diffère. Choisissez la voie à suivre à l’étape 1.
• Tout en UTC. L’API lit et écrit les heures en UTC. Convertissez-les à l’heure locale de l’usine, sinon un début prévu à 7:00 sera décalé.
• Les machines derrière les postes de charge. Un poste de charge peut représenter une machine, un groupe de machines, une cellule ou des personnes. Le nombre de machines et la taille de l’équipe renseignés à chaque étape de la gamme indiquent à SkyPlanner combien de ressources sont nécessaires.
• Sous-traitance. Les étapes affectées à un fournisseur plutôt qu’à un poste de charge représentent un délai, et non une charge sur votre capacité. Modélisez-les comme des étapes définies uniquement par leur durée.
• Chevauchement et étapes sans surveillance. Des indicateurs permettent de préciser si les étapes d’une gamme peuvent se chevaucher ou s’exécuter sans surveillance. Transférez ces deux indicateurs pour planifier correctement le travail sans présence humaine.
• Unités de temps. Les temps de réglage et de cycle ont chacun leurs unités. Le temps d’attente, lui, n’est pas du temps machine. Convertissez les unités à l’importation, sinon toutes les durées seront fausses.
• Pagination. Par défaut, les pages contiennent 200 enregistrements. Gérez la pagination à chaque lecture.