Guide till integration med Oracle Fusion Cloud för produktionsplanering med SkyPlanner APS

Oracle Fusion Cloud erbjuder tre vägar för datautbyte med ett externt planeringssystem:

1. REST API för Oracle Fusion Cloud SCM. Bassökvägen är /fscmRestApi/resources/11.13.18.05/. Ett planeringssystem använder resurserna workOrders (med underresurserna WorkOrderOperation, WorkOrderOperationResource och WorkOrderOperationMaterial), processWorkOrders, workDefinitions, workCenters, productionResources, calendars, itemsV2, itemStructures och inventoryOnhandBalances. Återrapportering skickas till operationTransactions, resourceTransactions och materialTransactions. Inköpsorder hämtas från purchaseOrders i Procurement REST API. (REST-endpoints)
2. File-Based Data Import (FBDI). Processen Import Work Orders skapar eller uppdaterar tillverkningsorder med tillhörande operationer och operationsresurser utifrån en mall. Import Work Order Resource Transactions läser in resursrapportering. Oracle är tydliga om tidsaspekten: ”This option isn’t suitable for importing manufacturing data on a real-time basis.” (Det här alternativet är inte lämpligt för import av tillverkningsdata i realtid.) (källa)
3. Oracle Integration (OIC). Oracles integrationsplattform hanterar flöden mellan Fusion och andra system. En färdig integrationsmall i Oracle Integration lyssnar på händelsen Work Order Status Change i Oracle Fusion Cloud Manufacturing (källa). Använd den om företaget redan kör OIC.

REST är huvudvägen för planering i realtid. FBDI passar för den första inläsningen av grunddata.

Data från Oracle hämtas genom pollning. Filtrerade REST-frågor hämtar nya och ändrade tillverkningsorder, statusändringar till frisläppt, lagersaldon och inköpsorder. Intervallet bestäms per fabrik: med några minuters mellanrum för tillverkningsorder och upp till en gång i timmen för lagersaldon. Om ni använder Oracle Integration kan händelsen Work Order Status Change utlösa en omedelbar läsning.

SkyPlanner skickar webhooks när status eller planen ändras. Återskrivningen är därmed händelsestyrd.

1. Första inläsning av grunddata. Läs in artiklar, artikelstrukturer, tillverkningsdefinitioner, produktionsgrupper, produktionsresurser och kalendrar via REST, eller gör en engångsinläsning från FBDI-utdrag. Mappa produktionsgrupperna med omsorg: om en produktionsgrupp innehåller fyra maskiner som motsvarar samma resurs blir den en gruppering av produktionsgrupper eller fyra produktionsgrupper. Varje tillverkningsorganisation blir en gruppering av produktionsgrupper, så att alla fabriker ingår i en och samma plan.

2. Synkronisering av tillverkningsorder. Läs in frisläppta och ej frisläppta tillverkningsorder med tillhörande operationer och material samt öppna inköpsorder. SkyPlanner räknar beställt material som tillgängligt på inköpsorderns leveransdatum och uppdaterar lagersaldot när inköpsordern markeras som Delivered.

Planera tillverkningsorder, inte planerade order från Supply Planning. Planerade order omvandlas först till tillverkningsorder i Oracle.

3. Återskrivning av planen. När planeringsmotorn placerar eller flyttar en operation utlöser en webhook från SkyPlanner ett PATCH-anrop till workOrders/{WorkOrderId}/child/WorkOrderOperation/{WorkOrderOperationId} med PlannedStartDate och PlannedCompletionDate. Oracles regel gäller: ”The planned start date must not occur before the start date of the work order or after the finish date of the work order.” (Det planerade startdatumet får inte ligga före tillverkningsorderns startdatum eller efter dess slutdatum.) (källa) Om den nya planen hamnar utanför dessa datum uppdaterar integrationen därför först datumen i tillverkningsorderns huvud med PATCH och därefter operationerna.

4. Återrapportering från produktionen. Operatörerna registrerar arbetet med SkyPlanner Mobile Confirmations eller Production Timer, och tidsregistreringarna håller planen aktuell. Färdiga kvantiteter skickas till operationTransactions och arbets- och maskintid till resourceTransactions. Om fabriken redan rapporterar i Oracle läser SkyPlanner i stället in produktionsutfallet därifrån.

5. Regler för dataägarskap och konflikter. Dokumentera dem före driftstart:

Låt bara ett system skriva operationernas datum. SkyPlanner behöver inget arbetsområde för planering i Oracle och tar därför över från Production Scheduling som det system som skriver planerade datum. Om Production Scheduling fortfarande frisläpper planer måste dess organisationer hållas åtskilda från dem som SkyPlanner planerar.

• Standardbeteende för planeringsmotorn. Oracles planeringsmotor utan kapacitetsbegränsningar körs när en order skapas och vid ”certain update actions” (vissa uppdateringsåtgärder). Testa i er miljö vilka uppdateringar som räknar om datumen och se till att SkyPlanner är det sista systemet som skriver operationernas datum.
• Tillverkningsorderns tidsram. Operationernas datum måste ligga mellan tillverkningsorderns start- och slutdatum. Uppdatera först orderhuvudet med PATCH.
• Basis Type. Resursåtgången anges per enhet endast när Basis Type är Variable. Fixed innebär en fast tid per operation. Räkna om vid importen, annars blir samtliga varaktigheter fel.
• Diskret tillverkning och processtillverkning. Fabriker med diskret tillverkning använder workOrders, medan processfabriker använder processWorkOrders. Mappa båda om ni har båda tillverkningsformerna.
• Paginering. Oracle begränsar antalet poster per REST-anrop. Använd paginering för varje fråga och filtrera på organisation och status.
• Kvartalsvisa uppdateringar. Oracle uppdaterar Fusion varje kvartal. Lås REST-versionen i sökvägen och testa på nytt efter varje uppdatering.
• Statusregler. Tillverkningsorder med status Pending Approval eller stängd status bör inte få nya datum. Filtrera bort dem vid inläsning.