Guide d’intégration de SAP S/4HANA pour l’ordonnancement de la production avec SkyPlanner APS

S/4HANA propose des services OData publiés pour ses intégrations, répertoriés sur le SAP Business Accelerator Hub (api.sap.com). L’intégration d’ordonnancement repose sur des services OData V2. Les IDocs et les BAPI existent toujours, mais ce guide utilise les API OData publiées.

Authentification selon l’édition

• Sur site et Private Edition. Les services s’activent dans SAP Gateway avec la transaction /IWFND/MAINT_SERVICE. L’utilisateur d’intégration doit disposer des objets d’autorisation correspondants, par exemple C_AFRU_AWK pour les confirmations, C_AFKO_AWK pour les postes de mouvements de marchandises comptabilisés avec celles-ci et M_PLAF_ORG pour les ordres planifiés.
• Public Edition. Les services sont exposés uniquement au moyen d’accords de communication. En suivant la procédure SAP de configuration des communications entrantes, vous créez un utilisateur de communication, un système de communication et un accord de communication dans l’application Communication Arrangements, à partir d’un scénario de communication SAP (SAP_COM_xxxx). Ce scénario définit les services exposés et les méthodes d’authentification disponibles :

– par jeton : flux OAuth, SAML ou OpenID Connect avec jeton bearer et propagation d’identité vers un utilisateur métier – par certificat client – par authentification de base avec un utilisateur technique de communication

SAP recommande l’authentification par jeton ou par certificat.

Côté SkyPlanner, une API REST avec authentification JWT est documentée au format Swagger/OpenAPI (référence de l’API). Le middleware gère donc l’authentification SAP d’un côté et un jeton JWT de l’autre.

API pour l’ordonnancement de la production

Service	Entités et actions utilisées	Usage
API_PRODUCTION_ORDER_2_SRV (Production Order, Version 2)	A_ProductionOrder_2, A_ProductionOrderItem_2, A_ProductionOrderOperation_2, A_ProductionOrderComponent_2, A_ProductionOrderStatus_2, A_ProductionRsceTools_2 ; actions ReleaseOrder, ReleaseOperation, ScheduleProductionOrderOperation	Ordres, opérations, composants, moyens auxiliaires de fabrication (PRT), statuts, renvoi du planning
API_WORK_CENTERS	A_WorkCenters, A_WorkCenterAllCapacity_2, A_WorkCenterCapacity, A_WorkCenterCapacityInterval_2, A_WorkCenterCapacityShift_2, A_WorkCenterCapPerBucket	Postes de charge, catégories de capacité, intervalles et équipes
API_PRODUCTION_ROUTING	ProductionRoutingHeader, ProductionRoutingSequence, ProductionRoutingOperation, ProductionRoutingSubOperation, ProductionRoutingMatlAssgmt, ProductionRoutingOpCompAlloc	Gammes de fabrication standard pour planifier avant la création des ordres
API_BILL_OF_MATERIAL_SRV;v=2	MaterialBOM, MaterialBOMItem, MaterialBOMSubItem	Structure produit à plusieurs niveaux
API_PRODUCT_SRV (Product Master A2X)	A_Product	Articles (appelés Product dans l’API). SAP recommande désormais l’API Product (Version 2) pour la plupart des entités produit
API_PLANNED_ORDERS	A_PlannedOrder, A_PlannedOrderComponent, A_PlannedOrderCapacity	Résultats de MRP Live avant conversion
API_MATERIAL_STOCK_SRV	A_MaterialStock, A_MatlStkInAcctMod	Stocks par division et magasin, pour déterminer la disponibilité des matières
API_PURCHASEORDER_PROCESS_SRV	A_PurchaseOrder, A_PurchaseOrderItem	Commandes d’achat ouvertes pour les matières attendues
API_PROD_ORDER_CONFIRMATION_2_SRV	ProdnOrdConf2, ProdnOrdConfMatlDocItm ; actions GetConfProposal, GetGdsMvtProposal, CancelProdnOrdConf	Confirmations et mouvements de marchandises provenant de l’atelier

Dans l’API des ordres de fabrication, les opérations sont identifiées par la combinaison de OrderInternalBillOfOperations et OrderIntBillOfOperationsItem, et non par le numéro d’opération visible par le planificateur. Dans l’API des confirmations, GetConfProposal désigne la même opération avec OrderID et OrderOperation. Enregistrez les clés internes et le numéro d’opération dans SkyPlanner dès le premier chargement.

Événements

S/4HANA émet les événements métier Production Order Created et Production Order Changed, dont la charge utile contient ManufacturingOrder, ProductionOrder, ProductionOrderType et ProductionPlant. Cette charge utile ne contient que des clés : l’intégration relit donc l’ordre et ses opérations. L’événement Changed se déclenche à chaque modification de l’ordre ; prévoyez une temporisation pour regrouper les déclenchements rapprochés. Dans l’autre sens, les webhooks SkyPlanner envoient une notification en temps réel lorsque le planning ou l’état d’une opération change.

Démarrer avec des fichiers

Pour l’essai, exportez les ordres de fabrication et les postes de charge depuis les rapports de listes de S/4HANA au format Excel ou CSV, puis importez-les dans SkyPlanner. Vous validez ainsi le planning avant toute intervention sur Gateway ou sur les accords de communication.

1. Chargement des données de base. Chargez les articles, les nomenclatures, les postes de charge avec leurs intervalles de capacité et leurs horaires d’équipe, ainsi que les gammes de fabrication. Déterminez à ce stade quel système fait autorité pour les horaires d’équipe. Une répartition qui fonctionne : le calendrier d’usine reste dans S/4HANA, tandis que les horaires détaillés des équipes, les absences et les heures supplémentaires sont gérés dans SkyPlanner, où les planificateurs les modifient au quotidien.

2. Synchronisation des ordres. Abonnez-vous aux événements Production Order Created/Changed ou, si les événements métier ne sont pas configurés, interrogez A_ProductionOrder_2 en utilisant l’horodatage de modification. Filtrez par division, type d’ordre et statut. Envoyez les ordres dès leur création pour que SkyPlanner puisse anticiper la planification, puis libérez-les dans S/4HANA (ReleaseOrder ou ReleaseOperation) une fois que SkyPlanner les a ordonnancés.

3. Renvoi du planning. Lorsqu’un webhook SkyPlanner signale une modification du planning, l’intégration appelle ScheduleProductionOrderOperation dans API_PRODUCTION_ORDER_2_SRV pour chaque opération modifiée. Elle transmet :

• ManufacturingOrder, OrderInternalBillOfOperations et OrderIntBillOfOperationsItem comme clés
• OpSchedulingMode avec la valeur F (au plus tôt), et le début prévu par SkyPlanner dans OpSchedldStartDate et OpSchedldStartTime
• OpSchedulingStatus avec la valeur DISP (affectation) et le champ obligatoire OpSchedulingStrategy avec la valeur M
• l’ETag dans if-match

Toutes les opérations d’un même ordre sont regroupées dans un seul change set, selon la séquence définie dans SkyPlanner. S/4HANA peut ainsi affecter l’ensemble du planning de l’ordre en un seul appel. Le mode K n’est jamais utilisé : il conserve les dates initiales des opérations et ignore les dates transmises.

SkyPlanner calcule les durées des opérations à partir des mêmes valeurs standard de gamme et des mêmes formules de capacité des postes de charge que S/4HANA. La date de fin calculée par S/4HANA à partir de la date de début transmise concorde donc avec le planning SkyPlanner. Après chaque change set, l’intégration relit les opérations et signale tout écart de date. Le planificateur en prend connaissance avant la prise de poste de l’équipe suivante.

4. Confirmations de l’atelier. Chaque relevé de temps issu de Mobile Confirmations ou de Production Timer devient une confirmation S/4HANA. Le webhook SkyPlanner déclenche l’envoi d’un ProdnOrdConf2 avec la quantité bonne, le rebut et les temps d’activité. L’intégration appelle d’abord GetConfProposal pour que S/4HANA propose les quantités, les activités, les dates et les données du personnel. GetGdsMvtProposal propose les mouvements de marchandises.

Approvisionnements attendus. Les commandes d’achat ouvertes font partie de la synchronisation entrante. SkyPlanner considère les matières commandées comme disponibles à la date de livraison prévue sur la commande d’achat. Les travaux en attente de composants achetés sont planifiés au jour de leur arrivée, au lieu d’être bloqués par le niveau de stock actuel.

S/4HANA reste la référence pour les réceptions : lorsqu’une entrée de marchandises est enregistrée, le stock augmente et la quantité restant à recevoir sur le poste de commande d’achat diminue. La synchronisation suivante met à jour le stock dans SkyPlanner et attribue le statut Delivered à toute commande d’achat entièrement réceptionnée. Après une réception partielle, la quantité restante reste attendue à la date de son échéance de livraison. La gestion des commandes d’achat dans SkyPlanner est décrite dans la documentation SkyPlanner.

5. Répartition des responsabilités. S/4HANA fait autorité pour les quantités, les nomenclatures, les gammes de fabrication, le calcul des coûts et les statuts. SkyPlanner fait autorité pour la séquence, l’affectation aux postes de travail et les dates des opérations. Ne laissez jamais les deux systèmes écrire dans le même champ. Si les planificateurs déplacent encore des opérations dans Capacity Scheduling Board, déterminez ce qui prévaut. Soit la prochaine synchronisation des ordres reprend leur modification dans SkyPlanner, soit le poste de charge concerné reste hors du périmètre de SkyPlanner.

• Le renvoi des données passe par un appel d’action avec un ETag. La méthode documentée pour ordonnancer une opération est ScheduleProductionOrderOperation, et non une requête PATCH sur A_ProductionOrderOperation_2. Le mode F ordonnance au plus tôt à partir d’une date de début et le mode B au plus tard à partir d’une date de fin, tandis que K et S conservent les dates existantes et ignorent les vôtres. L’ETag dans if-match est construit à partir du champ LastChangeDateTime de l’ordre (YYYYMMDDHHMMSS) : toute modification de l’ordre le rend donc obsolète. Prévoyez une lecture avant écriture et une file d’attente pour les nouvelles tentatives.
• La capacité ne se trouve pas dans l’en-tête du poste de charge. La capacité disponible dépend de la catégorie de capacité (001 machine, 002 main-d’œuvre), du calendrier d’usine ainsi que des intervalles et des équipes qui dérogent à ce calendrier. Les formules de capacité convertissent les valeurs standard des gammes de fabrication en besoins de réglage, de traitement et de démontage. Lisez A_WorkCenterCapacityInterval_2 et les entités relatives aux équipes, puis convenez de la façon de convertir ces formules en durées dans SkyPlanner.
• Les valeurs standard doivent être fiabilisées. Les gammes tenues à jour pour le calcul des coûts contiennent souvent des temps de réglage moyens, ou des temps de réglage imputés à la mauvaise catégorie de capacité.
• Les règles de confirmation sont strictes. SAP recommande les appels par lots pour les enregistrements en masse. Un ensemble de modifications est traité intégralement ou pas du tout : un seul bon de temps erroné bloque donc tout le reste de cet ensemble. Les annulations dans un lot doivent être exécutées dans l’ordre inverse de ConfirmationCount. Vous ne pouvez pas mélanger les types de confirmation sur un même ordre, comptabiliser des mouvements de marchandises sans confirmation, ni confirmer des opérations dont les points de déclenchement nécessitent une boîte de dialogue.
• Vérifiez si PP/DS est actif. La version intégrée de PP/DS nécessite l’activité Customizing Activate Advanced Planning and Scheduling et SAP HANA integrated liveCache. SAP la commercialise en tant que produit distinct, SAP S/4HANA Manufacturing for planning and scheduling. Lorsqu’elle est active, déterminez pour chaque article quel système assure l’ordonnancement : les articles marqués pour la planification avancée relèvent de PP/DS. SAP précise également pour l’API des ordres planifiés : « Automatic integration to PP/DS is not enabled from this API. » (L’intégration automatique à ce module n’est pas activée depuis cette API.)
• Unités de mesure. Les quantités des opérations, les quantités de base des gammes et les unités de confirmation peuvent différer. Effectuez explicitement les conversions en utilisant l’unité de l’opération, et non l’unité de base de l’article.
• Différences entre éditions. SAP Learning montre que le tableau de planification classique CM21/CM22 est remplacé par Manage Work Center Capacity, Capacity Scheduling Table et Capacity Scheduling Board. Public Edition n’expose les API que par des scénarios de communication, et les versions de services proposées peuvent différer de celles des installations sur site. L’API des gammes ne permet ni de supprimer des gammes ni de mettre à jour les affectations d’articles. Lors du cadrage, l’équipe SkyPlanner fixe les versions de services pour le système de chaque client, en s’appuyant sur l’entrée de l’API Business Accelerator Hub correspondant à cette version.
• Contraintes non prises en compte dans les gammes. Gérez dans SkyPlanner les changements de série dépendant de la séquence, les conflits d’outillage et les opérations nécessitant plusieurs opérateurs, plutôt que dans les valeurs standard des gammes. La matrice des temps de réglage contient les temps de changement de série pour chaque paire de produits. Les outils issus des PRT de l’ordre sont des ressources à capacité finie, utilisables sur un seul poste de travail à la fois, et une opération peut nécessiter plusieurs personnes simultanément.