Veiledning i Oracle Fusion Cloud-integrasjon for produksjonsplanlegging med SkyPlanner APS

Oracle Fusion Cloud gir et eksternt planleggingssystem tre veier for datautveksling:

1. REST API for Oracle Fusion Cloud SCM. Basisbanen er /fscmRestApi/resources/11.13.18.05/. Et planleggingssystem bruker ressursene workOrders (med underressursene WorkOrderOperation, WorkOrderOperationResource og WorkOrderOperationMaterial), processWorkOrders, workDefinitions, workCenters, productionResources, calendars, itemsV2, itemStructures og inventoryOnhandBalances. Fremdrift registreres i operationTransactions, resourceTransactions og materialTransactions. Innkjøpsordrer hentes fra purchaseOrders i Procurement REST API. (REST-endepunkter)
2. File-Based Data Import (FBDI). Prosessen Import Work Orders oppretter eller oppdaterer produksjonsordrer med tilhørende operasjoner og operasjonsressurser fra en mal, mens Import Work Order Resource Transactions laster inn ressursregistreringer. Oracle er tydelig på tidsaspektet: «This option isn’t suitable for importing manufacturing data on a real-time basis.» (Dette alternativet egner seg ikke til å importere produksjonsdata i sanntid.) (kilde)
3. Oracle Integration (OIC). Oracles integrasjonsplattform håndterer dataflyten mellom Fusion og andre systemer. En integrasjonsoppskrift i Oracle Integration lytter etter hendelsen Work Order Status Change i Oracle Fusion Cloud Manufacturing (kilde). Bruk denne løsningen hvis bedriften allerede bruker OIC.

REST er hovedveien for løpende produksjonsplanlegging. FBDI egner seg til den første innlastingen av grunndata.

Data hentes fra Oracle med polling. Filtrerte REST-spørringer henter nye og endrede produksjonsordrer, statusendringer til frigitt, lagerbeholdninger og innkjøpsordrer. Hyppigheten fastsettes per fabrikk: Produksjonsordrer hentes med noen minutters mellomrom og lagerbeholdninger hver time. Hvis dere bruker Oracle Integration, kan hendelsen Work Order Status Change utløse en umiddelbar innlesing.

SkyPlanner sender webhooks når tilstanden eller planen endres, så tilbakeskrivingen er hendelsesstyrt.

1. Første innlasting av grunndata. Les inn artikler, artikkelstrukturer, arbeidsdefinisjoner, arbeidssentre, produksjonsressurser og kalendere via REST, eller last dem inn én gang fra FBDI-uttrekk. Vær bevisst på hvordan arbeidssentrene kobles: Et arbeidssenter med fire maskiner knyttet til samme ressurs blir til én arbeidsstasjonsgruppe eller fire arbeidsstasjoner. Hver produksjonsorganisasjon blir til en arbeidsstasjonsgruppe, slik at alle fabrikkene inngår i én plan.

2. Synkronisering av produksjonsordrer. Les inn frigitte og ikke-frigitte produksjonsordrer med tilhørende operasjoner og materialer, samt åpne innkjøpsordrer. SkyPlanner regner bestilte materialer som tilgjengelige på innkjøpsordrens leveringsdato og oppdaterer lagerbeholdningen når innkjøpsordren merkes som Delivered.

Legg produksjonsordrer i planen, ikke planlagte ordrer fra Supply Planning. Planlagte ordrer må først bli produksjonsordrer i Oracle.

3. Tilbakeskriving av planen. Når planleggingsmotoren plasserer eller flytter en jobb, utløser en webhook fra SkyPlanner et PATCH-kall til workOrders/{WorkOrderId}/child/WorkOrderOperation/{WorkOrderOperationId} med PlannedStartDate og PlannedCompletionDate. Oracles regel gjelder: «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 startdatoen må ikke være før produksjonsordrens startdato eller etter produksjonsordrens sluttdato.) (kilde) Hvis den nye planen går utenfor disse datoene, oppdaterer integrasjonen derfor først datoene i produksjonsordrens hode med PATCH, og deretter operasjonene.

4. Tilbakemeldinger fra produksjonen. Operatørene registrerer arbeid med SkyPlanner Mobile Confirmations eller Production Timer, og tidsregistreringene holder planen oppdatert. Ferdigstilte mengder registreres i operationTransactions, mens arbeids- og maskintid registreres i resourceTransactions. Hvis fabrikken allerede rapporterer i Oracle, henter SkyPlanner fremdriften derfra i stedet.

5. Regler for dataeierskap og konflikter. Dokumenter dem før produksjonssetting:

Velg ett system som skriver operasjonsdatoer. SkyPlanner trenger ikke noe planleggingsarbeidsområde i Oracle og erstatter derfor Production Scheduling som systemet som skriver planlagte datoer. Hvis Production Scheduling fortsatt frigir planer, må organisasjonene der holdes atskilt fra dem SkyPlanner planlegger for.

• Standard oppførsel i planleggingsmotoren. Oracles motor uten kapasitetsbegrensninger kjører ved oppretting og ved «certain update actions.» (visse oppdateringshandlinger). Test i ditt miljø hvilke oppdateringer som beregner datoene på nytt, og sørg for at SkyPlanner er det siste systemet som skriver operasjonsdatoer.
• Tidsrammer for produksjonsordrer. Operasjonsdatoene må ligge mellom produksjonsordrens start- og sluttdato. Oppdater ordrehodet med PATCH først.
• Basis Type. Ressursforbruket gjelder per enhet bare når Basis Type er Variable. Fixed angir en fast tid per operasjon. Regn om ved import, ellers blir alle varigheter feil.
• Diskret produksjon og prosessproduksjon. Anlegg med diskret produksjon bruker workOrders, mens prosessanlegg bruker processWorkOrders. Sett opp datakobling for begge hvis dere bruker begge produksjonsformene.
• Paginering. Oracle begrenser antall poster per REST-kall. Bruk paginering i alle spørringer, og filtrer på organisasjon og status.
• Kvartalsvise oppdateringer. Oracle oppdaterer Fusion hvert kvartal. Lås REST-versjonen i stien, og test på nytt etter hver oppdatering.
• Statusregler. Produksjonsordrer med status Pending Approval eller lukket status bør ikke få nye datoer. Filtrer dem bort ved lesing.