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

Fulcrum est un produit cloud multitenant unique : tous les clients utilisent donc la même API. Le portail développeur la décrit comme une API publique permettant des « REST API calls directly into your Fulcrum site. » (appels REST API directement vers votre instance Fulcrum).

• Spécification. OpenAPI « Fulcrum PublicAPI » v1, téléchargeable à l’adresse https://api.fulcrumpro.com/swagger/v1/swagger.json. Fulcrum conseille de générer un client typé à partir de cette spécification. La page History répertorie chaque modification avec sa date.
• Hôtes. https://api.fulcrumpro.com pour les instances standard. Les instances ITAR utilisent api.fulcrumpro.us ; les jetons ITAR reçoivent une réponse 401 sur l’hôte .com.
• Conventions. Les listes s’obtiennent par POST .../list, avec les filtres dans le corps de la requête, une pagination par Skip et Take, et un tri par Sort.Field / Sort.Dir. De nombreux objets acceptent PUT ; les ordres de production acceptent aussi JSON Patch.

Points de terminaison utilisés pour l’intégration de l’ordonnancement :

La page des intégrations de Fulcrum est claire sur le travail à prévoir : « Every system is a little bit different and requires some configuration. » (Chaque système est un peu différent et nécessite une configuration.) C’est précisément cette configuration que l’équipe SkyPlanner prend en charge lors de la mise en place.

Fulcrum prend en charge les webhooks, configurés par un administrateur. Depuis septembre 2026, les webhooks en échec sont mis en pause puis retestés chaque jour, au lieu de faire l’objet de tentatives sans fin. La page History de l’API mentionne notamment les événements PurchaseOrderUpdated et ItemUpdated.

L’intégration récupère les données de Fulcrum selon les modalités suivantes :

• Les ordres de production ouverts sont interrogés à quelques minutes d’intervalle, avec un filtre sur scheduled et inProgress et la condition hasIncompleteOperations: true. C’est le filtre fourni par Fulcrum pour retrouver les données de sa page d’ordonnancement.
• Les commandes d’achat et les stocks sont récupérés avant chaque calcul du planning, ou à réception d’un webhook PurchaseOrderUpdated si celui-ci est configuré.
• Les articles, les gammes de fabrication, les équipements et les horaires des équipes sont récupérés à chaque modification ou chaque nuit.

Dans l’autre sens, les webhooks de SkyPlanner transmettent les modifications du planning dès qu’elles surviennent. Le renvoi des données vers Fulcrum repose donc sur les événements.

1. Chargement initial des données de base. Récupérez les articles, les matières, les gammes de fabrication, les postes de charge et les équipements, puis les horaires des équipes par service et les périodes d’arrêt. Chaque poste de charge Fulcrum devient un groupe de postes de travail dans SkyPlanner, dont les membres sont ses équipements. Les équipements sélectionnés pour chaque opération de gamme deviennent les postes de travail autorisés pour cette opération. Les équipements Unlimited Capacity, tels que les fours et les cabines de peinture, sont modélisés sous forme d’opérations par lots.

2. Synchronisation des ordres. Récupérez les ordres de production ouverts avec leurs articles à fabriquer et leurs opérations, ainsi que les commandes d’achat ouvertes et les stocks. SkyPlanner considère les matières commandées comme disponibles à la date de livraison de la commande d’achat et met le stock à jour lorsque celle-ci passe au statut Delivered. À chaque recalcul du planning, les stocks et les achats à recevoir sont vérifiés.

3. Renvoi du planning vers Fulcrum. Fulcrum calcule lui-même scheduledStartUtc, scheduledEndUtc et scheduledEquipmentId et les renvoie en lecture seule. La mise à jour d’une opération accepte customFields. SkyPlanner inscrit le début prévu, la fin prévue et le poste de travail dans les champs personnalisés de chaque opération de l’ordre de production, ainsi que la fin prévue dans un champ personnalisé de cet ordre. Les équipes commerciales et achats voient les dates de SkyPlanner sur l’ordre de production dans Fulcrum.

4. Déclarations en atelier. Les opérateurs enregistrent leur travail dans SkyPlanner avec Mobile Confirmations, Production Timer ou Quick Log Mode. SkyPlanner transmet les temps à Fulcrum via /api/job-tracking-timers/start et /stop, ou envoie une période de travail déjà terminée via /api/timers. Les quantités sont transmises via add-quantity-completed, et le décompte final avec les rebuts via complete. Le calcul des coûts de fabrication dans Fulcrum reste à jour en temps réel.

5. Responsabilités et gestion des conflits. L’ordonnanceur de Fulcrum « dictates the order of operations in Job Tracking. » (impose l’ordre des opérations dans Job Tracking). Choisissez donc un seul canal de lancement par opération : la file de travail des opérateurs dans SkyPlanner ou Fulcrum Job Tracking. Formalisez les règles avant la mise en production :

• Les effectifs sont pris en compte par équipe. Dans Fulcrum, le paramètre Max Equipment par équipe « is usually determined by how many people you have working in a certain area at that time. » (est généralement déterminé par le nombre de personnes travaillant dans une zone donnée à ce moment-là). Les opérateurs nommément identifiés et leurs horaires d’équipe sont configurés dans SkyPlanner. Les utilisateurs de /api/users fournissent les noms.
• L’ordonnancement se fait sur les équipements. Les postes de charge de Fulcrum regroupent des équipements interchangeables. Veillez à l’exactitude des équipements sélectionnés dans la gamme de fabrication : ils constituent les options parmi lesquelles le moteur choisit.
• Les ordres de fabrication regroupent plusieurs dossiers. Un ordre de fabrication regroupe les opérations de plusieurs dossiers de fabrication, par exemple pour une imbrication. Démarrer un chronomètre sur une opération regroupée déclenche en fait celui de l’ordre de fabrication, qui couvre toutes les opérations du groupe.
• Limites des chronométrages. Les plages de temps saisies rétroactivement via /api/timers « may not be in the future, older than 30 days, or longer than 7 days. » (ne doivent pas se situer dans le futur ni dépasser les limites d’ancienneté ou de durée indiquées). Transmettez les temps au fur et à mesure que les opérateurs les enregistrent.
• Les formats horaires diffèrent. Les horaires d’équipe utilisent des valeurs HHmm en heure locale, les arrêts et les dates planifiées sont en UTC, et les estimations des opérations sont exprimées en secondes.
• La mise à jour d’un équipement remplace l’enregistrement entier. Une requête PUT sur un équipement efface tout champ qu’elle omet. SkyPlanner lit les équipements sans jamais les modifier.
• Sites ITAR. Utilisez l’hôte .us et un jeton ITAR.