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

L’interface d’intégration documentée de Monitor G5 est Monitor ERP API v1. Elle associe CQRS et REST, avec des échanges JSON sur HTTPS. (API de Monitor ERP)

• Les Queries lisent les données avec GET. Elles acceptent les options de type OData : $filter, $select, $expand, $orderby, $top et $skip.
• Les Commands écrivent les données avec POST, par exemple Manufacturing/ManufacturingOrderOperations/Update.
• Batch exécute plusieurs commandes dans une seule transaction « tout ou rien » via POST /api/v1/Batch. Ajoutez /Simulate ou /Validate pour tester un lot de commandes puis annuler la transaction. Cette méthode permet d’écrire un planning complet en toute sécurité. (Batch)

L’URL de base est https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Le numéro de société combine le numéro de base de données et l’identifiant de la société, par exemple 004.1.

Concernant les licences, Monitor précise : « It is free to query and extract information from the API for all our customers. However, in order to use commands and write data to the ERP system, you need to purchase Monitor ERP API. » (Tous nos clients peuvent interroger l’API et en extraire des informations gratuitement. En revanche, l’utilisation des commandes et l’écriture de données dans l’ERP nécessitent l’achat de Monitor ERP API.) Prévoyez la licence d’écriture dès le début du projet. (api.monitor.se)

La documentation de l’API de Monitor ERP ne décrit ni webhooks ni abonnements aux événements. Les changements sont détectés par interrogation périodique :

• Common/EntityChangeLogs (à partir de 2.33) renvoie ChangeType (Update, Create, Delete), EntityTypeId, EntityId et ModifiedTimestamp. Interrogez ce point de terminaison à quelques minutes d’intervalle et ne récupérez que les enregistrements modifiés. (EntityChangeLog)
• Filtrez les requêtes sur les ordres de fabrication pour ne retenir que les ordres ouverts et paginez les résultats avec $top et $skip.

SkyPlanner envoie des webhooks lorsque l’état ou le planning change. Le renvoi des données vers Monitor est donc déclenché par les événements.

1. Chargement initial des données de base. Lisez les postes de charge, les lignes d’opération, les lignes d’opération alternatives, les lignes de matières, les articles et les horaires. Définissez soigneusement la correspondance entre chaque poste de charge et un poste de travail SkyPlanner. Un poste de charge de type Pool devient un groupe de postes de travail. Les postes de charge qu’il regroupe deviennent les postes de travail entre lesquels le moteur choisit.

2. Synchronisation des ordres. Lisez les ordres de fabrication ouverts avec leurs nœuds, leurs opérations et leurs matières, ainsi que le stock et les commandes d’achat ouvertes. 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. Après le premier chargement, les mises à jour incrémentales s’appuient sur Common/EntityChangeLogs.

3. Renvoi du planning vers Monitor. Pour chaque opération placée ou déplacée par le moteur, SkyPlanner envoie ManufacturingOrderOperations/Update avec PlannedStartDate et PlannedFinishDate. Lorsque le moteur a déplacé une opération vers une autre machine d’un pool, SetWorkCenter est exécuté en premier. Les commandes d’un même ordre sont regroupées dans un seul Batch : Monitor les accepte donc toutes ou n’en accepte aucune. Pendant les tests, exécutez le lot de commandes avec /Validate.

Dans les versions de Monitor antérieures à 24.5, les dates prévues ne sont pas modifiables via Update. Utilisez à la place ManufacturingOrders/ReplanOperation (à partir de 2.40) avec StartDate et FinishDate, et configurez RestrictToOrderBounds selon vos règles.

4. Déclarations en atelier. Conservez un seul canal de déclaration :

• Monitor reste le canal de déclaration. Les opérateurs effectuent leurs déclarations sur le Recording terminal ou via l’intégration des machines, comme aujourd’hui. SkyPlanner lit ManufacturingOrderOperationReportings pour suivre l’avancement et recalcule le planning.
• SkyPlanner devient le canal de déclaration. Les opérateurs enregistrent leur travail avec Mobile Confirmations ou Production Timer, et SkyPlanner envoie ReportManufacturingOrderOperation à Monitor.

Déclarer dans les deux systèmes comptabilise les temps et les quantités en double.

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

Les conflits viennent principalement des planificateurs qui continuent à modifier le planning des priorités. La fonction Rescheduling according to New finish et le déplacement de lignes dans Priority planning écrasent les dates écrites par SkyPlanner. Dès que SkyPlanner gère la séquence, Priority planning ne sert plus qu’à la consultation. Avec Autopilot, SkyPlanner recalcule automatiquement le planning lorsque la production évolue.

• Coefficient de disponibilité. Monitor applique un coefficient de disponibilité pour passer de la capacité brute à la capacité nette. Il est de 80 % par défaut pour un nouveau poste de charge. Appliquez-le une seule fois : soit via le rendement dans SkyPlanner, soit en réduisant les horaires d’équipe, jamais les deux.
• Précision horaire. Pour les postes de charge en mode Day planning, la capacité est exprimée en temps de base par jour, sans horaires d’équipe. Reproduisez les horaires d’équipe réels dans SkyPlanner à partir des calendriers de production, afin que les tâches soient planifiées pendant les heures de travail.
• Temps d’attente et chevauchement. Les lignes d’opération comportent un temps d’attente et un chevauchement en %. Définissez lors du cadrage la correspondance de chacun dans SkyPlanner, sinon les délais changeront après la mise en production.
• Groupes de postes. Les postes de charge regroupés se planifient dans Pool planning, et non dans Priority planning. Lisez les postes de charge qui composent le groupe, pas seulement la ligne du groupe.
• Versions requises. L’écriture des dates planifiées via Update nécessite la version 24.5. Les champs de capacité des postes de charge dans l’API nécessitent la version 24.3, et OIDC la version 25.8. Vérifiez le numéro de build avant le cadrage.
• Réseau et certificat. Lorsque Monitor est installé sur site, son API est accessible sur le port 8001 avec un certificat autosigné. SkyPlanner fonctionne dans le cloud : prévoyez donc une règle de pare-feu ou un relais et configurez explicitement la confiance accordée au certificat.
• Licences. Chaque application tierce qui écrit des données doit disposer de ses propres utilisateurs API sous licence. Chaque système est livré avec un utilisateur API en lecture seule.