Guide til integration af Oracle Fusion Cloud med SkyPlanner APS til produktionsplanlægning

Oracle Fusion Cloud giver et eksternt planlægningssystem tre veje til data:

1. REST API for Oracle Fusion Cloud SCM. Basisstien er /fscmRestApi/resources/11.13.18.05/. Et planlægningssystem bruger ressourcerne workOrders (med de underordnede ressourcer WorkOrderOperation, WorkOrderOperationResource og WorkOrderOperationMaterial), processWorkOrders, workDefinitions, workCenters, productionResources, calendars, itemsV2, itemStructures og inventoryOnhandBalances. Fremdrift registreres via operationTransactions, resourceTransactions og materialTransactions. Indkøbsordrer hentes fra purchaseOrders i Procurement REST API. (REST-endpoints)
2. File-Based Data Import (FBDI). Processen Import Work Orders opretter eller opdaterer produktionsordrer med tilhørende operationer og operationsressourcer ud fra en skabelon, og Import Work Order Resource Transactions indlæser ressourceposteringer. Oracle er tydelig om tidsaspektet: “This option isn’t suitable for importing manufacturing data on a real-time basis.” (Denne mulighed er ikke egnet til import af produktionsdata i realtid.) (kilde)
3. Oracle Integration (OIC). Oracles integrationsplatform håndterer dataflow mellem Fusion og andre systemer. En integrationsopskrift i Oracle Integration lytter efter hændelsen Work Order Status Change i Oracle Fusion Cloud Manufacturing (kilde). Brug den, hvis jeres virksomhed allerede anvender OIC.

REST er den primære vej til løbende detailplanlægning. FBDI egner sig til den første indlæsning af stamdata.

Data fra Oracle hentes via polling. Filtrerede REST-forespørgsler henter nye og ændrede produktionsordrer, statusændringer til frigivet, lagerbeholdninger og indkøbsordrer. Hyppigheden fastsættes for hver fabrik, fra med få minutters mellemrum for produktionsordrer til hver time for lagerbeholdninger. Hvis I bruger Oracle Integration, kan hændelsen Work Order Status Change udløse en øjeblikkelig læsning.

SkyPlanner sender webhooks, når tilstanden eller planen ændres, så tilbageskrivningen er hændelsesstyret.

1. Første indlæsning af stamdata. Hent varer, varestrukturer, arbejdsdefinitioner, arbejdscentre, produktionsressourcer og kalendere via REST, eller indlæs dem én gang fra FBDI-udtræk. Tag bevidst stilling til mapping af arbejdscentre: Et arbejdscenter med fire maskiner knyttet til samme ressource bliver til én gruppe af arbejdsstationer eller fire arbejdsstationer. Hver produktionsorganisation bliver til en gruppe af arbejdsstationer, så alle fabrikker indgår i én plan.

2. Synkronisering af produktionsordrer. Læs frigivne og ikke-frigivne produktionsordrer med tilhørende operationer og materialer samt åbne indkøbsordrer. SkyPlanner betragter bestilte materialer som tilgængelige på indkøbsordrens leveringsdato og opdaterer lagerbeholdningen, når indkøbsordren markeres som Delivered.

Planlæg produktionsordrer, ikke planlagte ordrer fra Supply Planning. Planlagte ordrer skal først omdannes til produktionsordrer i Oracle.

3. Tilbageskrivning af planen. Når planlægningsmotoren placerer eller flytter en opgave, udløser en webhook fra SkyPlanner et PATCH-kald til workOrders/{WorkOrderId}/child/WorkOrderOperation/{WorkOrderOperationId} med PlannedStartDate og PlannedCompletionDate. Oracles regel gælder: “The planned start date must not occur before the start date of the work order or after the finish date of the work order.” (Den planlagte startdato må ikke ligge før produktionsordrens startdato eller efter dens slutdato.) (kilde) Hvis den nye plan ligger uden for disse datoer, opdaterer integrationen derfor først datoerne i produktionsordrens hoved med PATCH og derefter operationerne.

4. Tilbagemeldinger fra produktionen. Operatørerne registrerer arbejdet med SkyPlanner Mobile Confirmations eller Production Timer, og tidsregistreringerne holder planen ajour. Færdigmeldte mængder sendes til operationTransactions, og arbejds- og maskintid sendes til resourceTransactions. Hvis fabrikken allerede indberetter i Oracle, læser SkyPlanner i stedet fremdriften derfra.

5. Regler for dataejerskab og konflikter. Skriv dem ned inden idriftsættelsen:

Vælg ét system til at skrive operationernes datoer. SkyPlanner kræver intet planlægningsarbejdsområde i Oracle og erstatter derfor Production Scheduling som det system, der skriver de planlagte datoer. Hvis Production Scheduling fortsat frigiver planer, skal dets organisationer holdes adskilt fra dem, SkyPlanner planlægger for.

• Standardplanlæggerens adfærd. Oracles planlægningsmotor uden kapacitetsbegrænsninger kører ved oprettelse og “certain update actions.” (visse opdateringshandlinger). Test i jeres miljø, hvilke opdateringer der genberegner datoer, og sørg for, at SkyPlanner er det sidste system, der skriver operationernes datoer.
• Produktionsordrernes tidsrammer. Operationernes datoer skal ligge inden for produktionsordrens start- og slutdato. Opdatér først ordrehovedet med PATCH.
• Basis Type. Ressourceforbruget er kun angivet pr. enhed, når Basis Type er Variable. Fixed betyder en fast tid pr. operation. Omregn ved import, ellers bliver alle varigheder forkerte.
• Diskret produktion og procesproduktion. Fabrikker med diskret produktion bruger workOrders, mens procesfabrikker bruger processWorkOrders. Map begge, hvis I har begge produktionstyper.
• Paginering. Oracle begrænser antallet af poster pr. REST-kald. Brug paginering i alle forespørgsler, og filtrér efter organisation og status.
• Kvartalsvise opdateringer. Oracle opdaterer Fusion hvert kvartal. Lås REST-versionen i stien, og test igen efter hver opdatering.
• Statusregler. Produktionsordrer med status Pending Approval eller lukket status bør ikke få nye datoer. Filtrér dem fra ved læsning.