Guide til SAP S/4HANA-integration med SkyPlanner APS til detailplanlægning

S/4HANA stiller integrationsgrænseflader til rådighed som frigivne OData-tjenester, der er opført på SAP Business Accelerator Hub (api.sap.com). Integrationen til detailplanlægning bruger OData V2-tjenester. IDocs og BAPIs findes stadig, men denne guide bruger de frigivne OData-API’er.

Autentificering efter udgave

• On-premise og Private Edition. Tjenesterne aktiveres i SAP Gateway med transaktionen /IWFND/MAINT_SERVICE. Integrationsbrugeren skal have de tilhørende autorisationsobjekter, for eksempel C_AFRU_AWK til tilbagemeldinger, C_AFKO_AWK til de varebevægelsesposter, der bogføres sammen med dem, og M_PLAF_ORG til planordrer.
• Public Edition. Tjenester stilles kun til rådighed via kommunikationsaftaler. Følg SAP’s vejledning til opsætning af indgående kommunikation, og opret en kommunikationsbruger, et kommunikationssystem og en kommunikationsaftale i appen Communication Arrangements ud fra et SAP-kommunikationsscenarie (SAP_COM_xxxx). Scenariet bestemmer, hvilke tjenester der stilles til rådighed, og hvilke godkendelsesmetoder der kan bruges:

– tokenbaseret: bearer-flows med OAuth, SAML eller OpenID Connect, hvor identiteten videreføres til en forretningsbruger – klientcertifikat – basic auth med en teknisk kommunikationsbruger

SAP anbefaler autentificering med token eller certifikat.

På SkyPlanner-siden er der et REST API med JWT-autentificering, dokumenteret i Swagger/OpenAPI (API-reference). Middleware håndterer derfor SAP-autentificering på den ene side og et JWT på den anden.

API’er til detailplanlægning

Tjeneste	Anvendte entiteter og handlinger	Formål
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; handlingerne ReleaseOrder, ReleaseOperation, ScheduleProductionOrderOperation	Ordrer, operationer, komponenter, PRT’er, status og tilbageskrivning af planen
API_WORK_CENTERS	A_WorkCenters, A_WorkCenterAllCapacity_2, A_WorkCenterCapacity, A_WorkCenterCapacityInterval_2, A_WorkCenterCapacityShift_2, A_WorkCenterCapPerBucket	Arbejdscentre, kapacitetskategorier, intervaller og skift
API_PRODUCTION_ROUTING	ProductionRoutingHeader, ProductionRoutingSequence, ProductionRoutingOperation, ProductionRoutingSubOperation, ProductionRoutingMatlAssgmt, ProductionRoutingOpCompAlloc	Standardruter til planlægning, før ordrer oprettes
API_BILL_OF_MATERIAL_SRV;v=2	MaterialBOM, MaterialBOMItem, MaterialBOMSubItem	Produktstruktur i flere niveauer
API_PRODUCT_SRV (Product Master A2X)	A_Product	Materialer (kaldet Product i API’et). SAP anbefaler nu API’et Product (Version 2) til de fleste produktentiteter
API_PLANNED_ORDERS	A_PlannedOrder, A_PlannedOrderComponent, A_PlannedOrderCapacity	Resultater fra MRP Live før konvertering
API_MATERIAL_STOCK_SRV	A_MaterialStock, A_MatlStkInAcctMod	Lagerbeholdning pr. fabrik og lagersted til vurdering af materialetilgængelighed
API_PURCHASEORDER_PROCESS_SRV	A_PurchaseOrder, A_PurchaseOrderItem	Åbne indkøbsordrer på indgående materialer
API_PROD_ORDER_CONFIRMATION_2_SRV	ProdnOrdConf2, ProdnOrdConfMatlDocItm; handlingerne GetConfProposal, GetGdsMvtProposal, CancelProdnOrdConf	Tilbagemeldinger og varebevægelser fra produktionsgulvet

I API’et til produktionsordrer identificeres operationer med nøglerne OrderInternalBillOfOperations og OrderIntBillOfOperationsItem, ikke med det operationsnummer, planlæggeren ser. I API’et til tilbagemeldinger bruger GetConfProposal derimod OrderID og OrderOperation til at identificere den samme operation. Gem både de interne nøgler og operationsnummeret i SkyPlanner fra første indlæsning.

Hændelser

S/4HANA udløser forretningshændelserne Production Order Created og Production Order Changed med ManufacturingOrder, ProductionOrder, ProductionOrderType og ProductionPlant i payloaden. Payloaden indeholder kun nøgler, så integrationen læser ordren og dens operationer igen. Changed-hændelsen udløses ved hver ændring af ordren, så brug debouncing til at samle hændelser, der kommer tæt efter hinanden. I den modsatte retning sender SkyPlanner-webhooks besked i realtid, når planen eller en opgaves status ændres.

Start med filer

Til prøveperioden eksporterer I produktionsordrer og arbejdscentre fra listerapporter i S/4HANA til Excel eller CSV og importerer dem i SkyPlanner. På den måde bliver planen afprøvet, før nogen går i gang med Gateway eller kommunikationsaftaler.

1. Indlæsning af stamdata. Indlæs materialer, styklister, arbejdscentre med deres kapacitetsintervaller og skift samt ruter. Afgør her, hvilket system der har ansvaret for skiftene. En fordeling, der fungerer: Fabrikskalenderen forbliver i S/4HANA, mens detaljerede skiftmønstre, fravær og overarbejde ligger i SkyPlanner, hvor planlæggerne ændrer dem dagligt.

2. Ordresynkronisering. Abonner på Production Order Created/Changed, eller brug polling af A_ProductionOrder_2 ud fra ændringstidsstemplet, hvis forretningshændelser ikke er sat op. Filtrer på fabrik, ordretype og status. Send ordrerne, når de oprettes, så SkyPlanner kan planlægge fremad, og frigiv dem i S/4HANA (ReleaseOrder eller ReleaseOperation), når SkyPlanner har lagt dem ind i planen.

3. Tilbageskrivning af planen. Når en SkyPlanner-webhook melder om en ændring i planen, kalder integrationen ScheduleProductionOrderOperation i API_PRODUCTION_ORDER_2_SRV for hver ændret operation. Den sender:

• ManufacturingOrder, OrderInternalBillOfOperations og OrderIntBillOfOperationsItem som nøgler
• OpSchedulingMode F (forlæns) med startdato og starttid fra SkyPlanner i OpSchedldStartDate og OpSchedldStartTime
• OpSchedulingStatus DISP (disponering) og den obligatoriske OpSchedulingStrategy M
• ETag i if-match

Alle operationer på en ordre sendes i ét change set i SkyPlanners rækkefølge, så S/4HANA fastlægger hele ordrens plan i ét kald. Mode K bruges aldrig: Den bevarer operationernes oprindelige datoer og ignorerer de datoer, der sendes.

SkyPlanner beregner operationernes varighed ud fra de samme standardværdier i ruterne og kapacitetsformler for arbejdscentrene, som S/4HANA bruger. Den slutdato, S/4HANA beregner ud fra den overførte startdato, stemmer derfor overens med planen i SkyPlanner. Efter hvert change set læser integrationen operationerne igen og markerer eventuelle datoafvigelser, så planlæggeren ser dem inden næste skift.

4. Tilbagemeldinger fra produktionsgulvet. Hver tidsregistrering fra Mobile Confirmations eller Production Timer bliver til en tilbagemelding i S/4HANA. En webhook fra SkyPlanner udløser en postering via ProdnOrdConf2 med godkendt mængde, kassation og aktivitetstider. Integrationen kalder først GetConfProposal, så S/4HANA foreslår mængder, aktiviteter, datoer og personaledata. GetGdsMvtProposal foreslår varebevægelserne.

Materialer på vej. Åbne indkøbsordrer indgår i den indgående synkronisering. SkyPlanner regner bestilte materialer som tilgængelige på indkøbsordrens forventede leveringsdato. Job, der venter på indkøbte komponenter, planlægges til den dag, materialerne ankommer, i stedet for at blive blokeret af dagens lagerbeholdning.

S/4HANA forbliver det autoritative system for varemodtagelser: Når en varemodtagelse bogføres, stiger lagerbeholdningen, og den åbne mængde på indkøbsordrelinjen falder. Næste synkronisering opdaterer lagerbeholdningen i SkyPlanner og markerer en fuldt modtaget indkøbsordre som Delivered. Efter en delmodtagelse står den resterende åbne mængde fortsat som på vej med datoen fra leveringsplanlinjen. SkyPlanners håndtering af indkøbsordrer er beskrevet i SkyPlanners dokumentation.

5. Regler for dataansvar. S/4HANA har ansvaret for mængder, styklister, ruter, kalkulation og status. SkyPlanner har ansvaret for rækkefølge, tildeling af arbejdsstationer og operationsdatoer. Lad aldrig begge systemer skrive til det samme felt. Hvis planlæggerne stadig flytter operationer i Capacity Scheduling Board, skal I afgøre, hvad der har forrang. Enten overføres deres ændring til SkyPlanner ved næste ordresynkronisering, eller også holdes det pågældende arbejdscenter uden for SkyPlanners område.

• Tilbageskrivning sker via et handlingskald med en ETag. Den dokumenterede metode til at planlægge en operation er ScheduleProductionOrderOperation, ikke et PATCH-kald på A_ProductionOrderOperation_2. Tilstand F planlægger forlæns fra en start, og B baglæns fra en afslutning, mens K og S beholder de eksisterende datoer og ignorerer dine. ETag i if-match dannes ud fra ordrens LastChangeDateTime (YYYYMMDDHHMMSS), så enhver ændring af ordren gør den forældet. Implementer læsning før skrivning og en kø til genforsøg.
• Kapaciteten ligger ikke i arbejdscentrets header. Den tilgængelige kapacitet bestemmes af kapacitetskategorien (001 maskine, 002 arbejdskraft), fabrikskalenderen og de intervaller og skift, der tilsidesætter kalenderen. Kapacitetsformler omregner rutens standardværdier til kapacitetsbehov til klargøring, bearbejdning og nedtagning. Læs A_WorkCenterCapacityInterval_2 og skiftentiteterne, og aftal, hvordan formlerne skal omsættes til varigheder i SkyPlanner.
• Der skal ryddes op i standardværdierne. Ruter, der vedligeholdes til kalkulation, indeholder ofte gennemsnitlige opstillingstider, eller opstillingen er registreret under den forkerte kapacitetskategori.
• Reglerne for tilbagemeldinger er strenge. SAP anbefaler batchkald til massebogføring. Et ændringssæt behandles efter alt-eller-intet-princippet, så én fejlbehæftet tidstilbagemelding blokerer resten af sættet. Annulleringer i en batch skal udføres i omvendt ConfirmationCount-rækkefølge. Du kan hverken blande tilbagemeldingstyper på samme ordre, bogføre varebevægelser uden en tilbagemelding eller tilbagemelde operationer, hvis triggerpunkter kræver en dialogboks.
• Kontrollér, om PP/DS er aktivt. Indlejret PP/DS kræver Customizing-aktiviteten Activate Advanced Planning and Scheduling og SAP HANA integrated liveCache. SAP sælger det som et separat produkt, SAP S/4HANA Manufacturing for planning and scheduling. Hvor det er aktivt, skal I for hvert materiale afgøre, hvilket system der planlægger: Materialer markeret til avanceret planlægning hører til PP/DS. SAP skriver også om API’et til planordrer: “Automatic integration to PP/DS is not enabled from this API.” (Automatisk integration til dette system er ikke aktiveret via dette API.)
• Måleenheder. Operationsmængder, ruternes basismængder og enheder til tilbagemelding kan være forskellige. Foretag en eksplicit omregning med operationens enhed, ikke materialets basisenhed.
• Forskelle mellem udgaver. SAP Learning viser, at den klassiske CM21/CM22-planlægningstavle erstattes af Manage Work Center Capacity, Capacity Scheduling Table og Capacity Scheduling Board. Public Edition stiller kun API’er til rådighed gennem kommunikationsscenarier, og tjenesteversionerne kan være anderledes end i en lokal installation. Rute-API’et kan ikke slette ruter eller opdatere materialetilknytninger. Under afklaringen fastlægger SkyPlanner-teamet tjenesteversionerne for hver kundes system ud fra opslaget for den pågældende version i API Business Accelerator Hub.
• Begrænsninger, som ruterne ikke rummer. Håndtér rækkefølgeafhængige omstillinger, værktøjskonflikter og operationer med flere operatører i SkyPlanner, ikke i ruternes standardværdier. Matricen for opstillingstid indeholder omstillingstider for hvert produktpar. Værktøjer fra ordrens PRTs er begrænsede ressourcer og kan kun bruges på én arbejdsstation ad gangen, og en operation kan kræve flere personer samtidig.