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

L’intégration repose sur deux interfaces déjà fournies avec Business Central :

1. API v2.0 pour les données commerciales et les stocks. Elle expose items, itemVariants, itemLedgerEntries, locations, unitsOfMeasure, salesOrders, salesOrderLines, purchaseOrders, purchaseOrderLines, vendors, customers et employees. Elle ne propose aucune entité de fabrication : les données de production passent donc par la seconde interface.
2. Services web OData v4 pour la fabrication. Toute page Business Central peut être publiée comme service web OData v4 depuis la page Web Services. Choisissez le type d’objet Page, l’ID de la page et un nom de service, puis sélectionnez Published. Le point de terminaison est alors actif, sans code AL ni extension à déployer. L’intégration publie les pages standard des ordres de fabrication lancés, des Prod. Order Routing Lines, des postes de charge, des centres machine et des gammes de fabrication, accessibles sous /ODataV4/Company('{name}')/{ServiceName}.

Les pages publiées sont accessibles en lecture et en écriture. Microsoft précise : « If an editable page is exposed as a web service, the data in the underlying table can be accessed and modified by an OData call, » (si une page modifiable est exposée en tant que service web, un appel OData permet de consulter et de modifier les données de la table sous-jacente), avec PATCH pour les mises à jour. C’est ainsi que les dates planifiées sont renvoyées dans Business Central, via la même page et les mêmes contrôles de validation que ceux utilisés par un planificateur.

Écartez SOAP. Microsoft a déprécié les services web SOAP, et la publication de pages de l’interface Microsoft via SOAP est supprimée dans la vague 2 de la version 2026 (v29).

Business Central permet de créer des abonnements aux webhooks via POST /api/v2.0/subscriptions sur les entités API v2.0 telles que items et salesOrders. Voici les règles à respecter :

• La création d’un abonnement nécessite un échange de validation : votre point de terminaison doit renvoyer le validationToken avec le statut 200 OK.
• Les abonnements expirent au bout de trois jours. Renouvelez-les avec PATCH : la procédure de validation de connexion est alors relancée.
• Les notifications contiennent le chemin de la ressource, changeType et votre clientState, mais pas l’enregistrement complet. Vous récupérez l’enregistrement ensuite.
• Les notifications sont différées : Business Central en ligne attend 30 secondes après la première modification. Si plus de 1 000 enregistrements sont modifiés pendant cet intervalle, ils sont regroupés dans une seule notification collection.
• Le nombre d’abonnements aux webhooks est limité à 200 par environnement en ligne.

Les ordres de fabrication, les lignes de gamme et les commandes fournisseur sont récupérés par interrogation périodique, toutes les quelques minutes, sur les pages publiées et sur purchaseOrders. Le filtrage sur les ordres et commandes ouverts, associé à la pagination, maintient le nombre de requêtes largement en deçà des limites de Business Central.

SkyPlanner envoie des webhooks lorsque l’état ou le planning change. Le renvoi des données repose donc sur les événements.

1. Chargement initial des données de base. Récupérez les gammes de fabrication et les nomenclatures de production au statut Certified, ainsi que les postes de charge et les centres machine, depuis les pages publiées. Récupérez les articles et les unités de mesure via l’API v2.0. Définissez soigneusement la correspondance entre chaque poste de charge ou centre machine et les postes de travail SkyPlanner : décidez si un poste de charge comprenant trois centres machine doit devenir un groupe de postes de travail ou trois postes de travail.

2. Synchronisation des ordres. Lisez les ordres de fabrication au statut Released (et Firm Planned, si vous les ordonnancez), avec leurs lignes de gamme et leurs composants, depuis les pages publiées. Récupérez également les lignes de commandes d’achat ouvertes via l’API v2.0. 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. L’ordonnancement tient ainsi compte à la fois du stock et des achats à recevoir.

N’ordonnancez jamais les ordres de fabrication au statut Planned : selon Microsoft, Business Central « deletes them the next time you run planning. » (les supprime lors du prochain calcul de planification). La Planning Worksheet continue de proposer des approvisionnements, tandis que SkyPlanner ordonnance les ordres fermes en fonction de la capacité réelle.

3. Renvoi du planning vers Business Central. La page standard Prod. Order Routing est publiée comme service web OData v4. Pour chaque opération placée ou déplacée par le moteur, SkyPlanner envoie une requête PATCH sur la ligne de gamme correspondante avec l’ETag If-Match. Cette requête renseigne Starting Date-Time et Ending Date-Time, ainsi que Type et No. lorsque l’opération a été affectée à une machine de remplacement.

L’appel PATCH exécute les déclencheurs de la page et de la table. Business Central valide donc les champs selon sa propre logique, exactement comme lorsqu’un planificateur modifie la page Prod. Order Routing. Les champs Starting et Ending Date-Time de la ligne d’ordre de fabrication sont mis à jour en conséquence. Business Central conserve la gestion des quantités, des statuts et des coûts.

4. Déclarations en atelier. Les opérateurs enregistrent leur travail avec SkyPlanner Mobile Confirmations ou le Production Timer, et les relevés de temps maintiennent le planning à jour. La production peut être déclarée dans Business Central comme auparavant, depuis le Production Journal ou l’Output Journal.

Si vous souhaitez que la production et les consommations soient comptabilisées de façon entièrement automatique, une page API standard de Business Central est ajoutée pour valider les écritures de l’Output Journal. SkyPlanner comptabilise alors le temps de réglage, le temps d’exécution et la quantité produite par opération. La validation met à jour les Capacity Ledger Entries, et la déclaration de production sur la dernière opération de la gamme fait entrer l’article en stock.

Choisissez un seul canal pour comptabiliser la production. Si vous utilisez à la fois SkyPlanner et le Production Journal de Business Central, les écritures seront en double.

5. Règles de responsabilité et de gestion des conflits. Consignez-les avant la mise en production :

Les principales sources de conflit sont les actions Refresh et Replan sur les ordres de fabrication. Microsoft précise : « If you use the Refresh action to recalculate production order lines, Business Central deletes the existing production order lines and calculates new lines. » (Si vous utilisez l’action Refresh pour recalculer les lignes d’ordre de fabrication, Business Central supprime les lignes existantes et en calcule de nouvelles.) Replan peut également modifier les besoins en capacité, et le recalcul des composants « deletes previous changes in the components. » (supprime les modifications précédemment apportées aux composants).

Traitez un ordre actualisé comme une nouvelle version, synchronisez-le à nouveau et laissez SkyPlanner recalculer l’ordonnancement. Avec Autopilot, SkyPlanner recalcule automatiquement l’ordonnancement lorsque la production change.

• Unités dans les gammes de fabrication. Setup Time s’applique à l’ordre de fabrication, Run Time à chaque article produit, et chacun possède son propre Unit of Measure Code. Wait Time et Move Time ne consomment pas de capacité du poste de charge. Si l’unité du poste de charge est Days, un jour correspond à 24 heures, et non à un poste de huit heures. Convertissez les durées à l’importation, sinon elles seront toutes erronées.
• Calendriers obsolètes. La capacité n’existe qu’après l’exécution de Calculate Work Center Calendar sur l’horizon concerné. Vérifiez le champ Calendar Entries Available Until avant le chargement initial.
• Capacité des centres machine masquée. Lorsque Consolidated Calendar est désactivé, seule la capacité propre au poste de charge est planifiée : « The machine center capacity is excluded. » (La capacité des centres machine est exclue.) Lisez directement la capacité des centres machine plutôt que de vous fier aux totaux des postes de charge.
• Capacity et Efficiency. Business Central calcule la durée selon la formule Run Time / Efficiency / Capacity, et les écritures de calendrier calculées intègrent déjà ces deux paramètres. Appliquez Efficiency au rendement du poste de travail SkyPlanner une seule fois, pas deux.
• Alternate Work Center est fourni à titre informatif. Microsoft précise qu’il « isn’t automatically included in planning processes. » (n’est pas automatiquement pris en compte dans les processus de planification). Modélisez explicitement les solutions de remplacement sous forme de postes de travail alternatifs dans SkyPlanner.
• Limitation des requêtes. Les limites de la version en ligne s’appliquent par utilisateur, et un principal de service compte comme un utilisateur : 6 000 requêtes OData sur une fenêtre glissante de 5 minutes et 5 requêtes simultanées. La taille des pages est limitée à 20 000 enregistrements, un $batch à 100 opérations, et une opération expire après 8 minutes. Tout dépassement du débit autorisé renvoie le code 429. Regroupez les requêtes, paginez les résultats et interrogez uniquement les modifications plutôt que de recharger toutes les données.
• Licences. Les fonctions de fabrication ne sont disponibles que dans l’expérience Premium. Les utilisateurs disposant d’Essentials ne peuvent pas se connecter à une société configurée en Premium.