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

QAD propose trois voies d’accès à un outil d’ordonnancement externe :

1. QAD QXtend Inbound (QXI). QAD le décrit comme « a Web services-based, SOAP-compliant, XML framework, enabling complete platform-independent access to QAD Enterprise Applications business functionality. » (un cadre XML fondé sur les services web et conforme à SOAP, donnant un accès complet aux fonctions métier de QAD Enterprise Applications, indépendamment de la plateforme). Chaque requête est un QDoc qui exécute un programme QAD avec les mêmes contrôles de validation que son écran et renvoie un QDoc de réponse. Les QDocs fournis comprennent maintainItemMaster, maintainRouting et maintainPurchaseOrder. Pour les programmes sans QDoc fourni, l’outil QGen de QAD établit la correspondance avec le programme du menu : « QGen is used to map custom programs or QAD Enterprise Applications programs that do not have released QDoc schemas and events files. » (QGen sert à établir les correspondances pour les programmes personnalisés ou les programmes QAD Enterprise Applications dépourvus de schémas QDoc et de fichiers d’événements fournis). QAD utilise lui-même cette voie : « QAD Production Scheduler uses QAD QXtend to update work orders. » (QAD Production Scheduler utilise QAD QXtend pour mettre à jour les ordres de fabrication). (Guide QXtend)
2. QAD QXtend Outbound (QXO). QXO « exports user-configurable business objects as XML QDocs out of QAD products. » (exporte depuis les produits QAD des objets métier configurables par l’utilisateur sous forme de QDocs XML). Les objets métier standard comprennent Item, Product Structure, Routing, Work Center, Department, Inventory Transaction et Inventory Status.
3. REST APIs pour les documents métier. Depuis Adaptive ERP 2022.1, « Query REST APIs are now available for business documents, » (des REST APIs de requête sont désormais disponibles pour les documents métier), avec filtrage, tri, pagination et récupération partielle des données. Elles sont documentées dans Swagger sur votre instance (notes de version).

Les écritures passent par QXtend. Les lectures passent par QXO et les REST APIs de requête.

QXtend Outbound est le mécanisme de QAD pour suivre les modifications de données. « A change occurs to watched data in QAD Enterprise Applications. Change notifications are written out to the qxevents database. » (Lorsqu’une donnée surveillée est modifiée dans QAD Enterprise Applications, des notifications de modification sont enregistrées dans la base qxevents.) QXO génère ensuite les QDocs et les transmet « to a directory location where the subscriber polls for and picks up new QDocs, » (vers un répertoire que l’abonné interroge pour récupérer les nouveaux QDocs), ou à un service web à l’écoute sur une URL.

SkyPlanner s’abonne en tant que service web aux publications de QXO et interroge périodiquement les REST APIs de requête pour tout ce que QXO ne couvre pas. Work Order ne fait pas partie des objets métier standard de QXO. L’intégration ajoute donc un objet métier QXO sur les tables des ordres de fabrication (wo_mstr, wr_route), ou interroge les ordres de fabrication via les REST APIs de requête à intervalles de quelques minutes.

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

1. Chargement initial des données de base. Récupérez les articles, les structures produit, les gammes de fabrication, les postes de charge et les calendriers via QXO ou les REST APIs de requête. Définissez soigneusement la correspondance des postes de charge : un poste de charge comprenant quatre machines devient un groupe de postes de travail ou quatre postes de travail. Les lignes de production répétitive de Production Line Maintenance peuvent aussi devenir des postes de travail.

2. Synchronisation des ordres de fabrication. Récupérez les ordres de fabrication planifiés fermes et lancés, avec leurs gammes et leurs composants, ainsi que 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.

Ordonnancez les ordres de fabrication, et non les ordres planifiés du MRP. Les ordres planifiés doivent d’abord devenir des ordres de fabrication planifiés fermes ou lancés dans QAD.

3. Renvoi des dates du planning vers QAD. Lorsque le moteur positionne ou déplace un ordre, un webhook SkyPlanner déclenche un QDoc QXtend Inbound sur Work Order Maintenance (16.1). Celui-ci fixe la date de lancement à celle de la première opération planifiée et la date d’échéance à celle de la dernière. QXtend exécute le programme avec les contrôles de validation de QAD et renvoie un QDoc de réponse que l’intégration vérifie.

La séquence des opérations sur chaque machine reste dans SkyPlanner et est transmise aux opérateurs via Mobile Confirmations. L’intégration évite ainsi le blocage des gammes que QAD applique aux ordres lancés.

4. Déclarations en atelier. Les opérateurs saisissent leur travail avec SkyPlanner Mobile Confirmations ou Production Timer. Ces relevés de temps maintiennent le planning à jour. Vous choisissez si les temps réels sont renvoyés vers QAD. Si oui, les temps de préparation et d’exécution sont transmis à Labor Feedback by Work Order pour chaque opération, et les quantités terminées à Work Order Receipt. Sinon, les temps de main-d’œuvre restent saisis dans QAD comme auparavant.

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

Désignez un seul système pour écrire les dates des ordres de fabrication. SkyPlanner n’a besoin d’aucun module d’ordonnancement QAD. Il remplace donc les consoles d’ordonnancement ou les autres outils d’ordonnancement pour l’écriture des dates des ordres qu’il ordonnance.

• Relances du CRP. Le CRP réordonnance toutes les opérations ouvertes des ordres de fabrication sélectionnés. QAD ne conserve les dates saisies manuellement que si « you also adjusted the work order release and due date to match, » (vous avez également ajusté les dates de lancement et d’échéance de l’ordre de fabrication pour qu’elles correspondent), ce qui est précisément ce que SkyPlanner écrit. Exécutez le CRP après la réécriture, ou excluez les ordres ordonnancés par SkyPlanner.
• Les gammes sont figées après le lancement. « Once the work order status is Exploded, Allocated, or Released, no more changes can be made to the routing. » (Une fois l’ordre de fabrication au statut Exploded, Allocated ou Released, la gamme de fabrication ne peut plus être modifiée.) Lisez la gamme au moment du lancement et ne modifiez les gammes que sur les ordres planifiés ou planifiés fermes.
• Unités de temps des gammes. Les temps de réglage et d’exécution constituent de la charge, tandis que « queue, wait, and move times are excluded from load calculations. » (les temps de file d’attente, d’attente et de transfert sont exclus des calculs de charge). Dans SkyPlanner, modélisez ces derniers par des étapes qui ne comptabilisent que du temps et vérifiez si le temps d’exécution est défini par unité ou par ordre.
• Capacité de traitement de QXtend. QAD avertit que « UI API adapter performance may be unacceptable when processing high volumes of data or real-time transactions. » (les performances de l’adaptateur UI API peuvent être insuffisantes pour traiter de gros volumes de données ou des transactions en temps réel). N’envoyez que les ordres modifiés, par lots, et utilisez les QDocs natifs lorsqu’ils existent.
• Domaines et sites. Les installations QAD multidomaines gèrent les postes de charge et les ordres de fabrication par domaine et par site. Associez chaque site du périmètre à un groupe de postes de travail distinct.
• Production répétitive et production discrète. Les lignes Advanced Repetitive utilisent des programmes de production répétitive, et non des ordres de fabrication. Déterminez lors du cadrage quelles lignes seront ordonnancées par SkyPlanner.