Oracle Fusion Cloud integrācijas ceļvedis ražošanas grafiku sastādīšanai ar SkyPlanner APS

Oracle Fusion Cloud ārējai grafiku sastādīšanas sistēmai piedāvā trīs datu apmaiņas veidus:

1. Oracle Fusion Cloud SCM REST API. Pamatceļš ir /fscmRestApi/resources/11.13.18.05/. Grafiku sastādīšanas sistēma izmanto resursus workOrders (ar pakārtotajiem resursiem WorkOrderOperation, WorkOrderOperationResource un WorkOrderOperationMaterial), processWorkOrders, workDefinitions, workCenters, productionResources, calendars, itemsV2, itemStructures un inventoryOnhandBalances. Izpildes dati tiek nosūtīti uz operationTransactions, resourceTransactions un materialTransactions. Iepirkuma pasūtījumi tiek saņemti no Procurement REST API resursa purchaseOrders. (REST galapunkti)
2. File-Based Data Import (FBDI). Process Import Work Orders no veidnes izveido vai atjaunina ražošanas pasūtījumus, to operācijas un operāciju resursus, savukārt Import Work Order Resource Transactions ielādē resursu grāmatojumus. Oracle skaidri norāda uz laika ierobežojumu: “This option isn’t suitable for importing manufacturing data on a real-time basis.” (Šī iespēja nav piemērota ražošanas datu importēšanai reāllaikā.) (avots)
3. Oracle Integration (OIC). Oracle integrācijas platforma nodrošina datu plūsmas starp Fusion un citām sistēmām. Oracle Integration integrācijas veidne reaģē uz Oracle Fusion Cloud Manufacturing notikumu Work Order Status Change (avots). Izmantojiet to, ja jūsu uzņēmums jau lieto OIC.

Aktuālu grafiku sastādīšanai galvenais datu apmaiņas veids ir REST. FBDI ir piemērots sākotnējai pamatdatu ielādei.

Dati no Oracle tiek pieprasīti periodiski. Filtrēti REST vaicājumi iegūst jaunus un mainītus ražošanas pasūtījumus, izmaiņas pasūtījumu nodošanā izpildei, krājumu atlikumus un iepirkuma pasūtījumus. Biežumu nosaka katrai ražotnei: ražošanas pasūtījumus var nolasīt ik pēc dažām minūtēm, bet krājumus — reizi stundā. Ja izmantojat Oracle Integration, notikums Work Order Status Change var izraisīt tūlītēju datu nolasīšanu.

SkyPlanner nosūta tīmekļa aizķeres, kad mainās stāvoklis vai grafiks, tāpēc datu ierakstīšanu atpakaļ Oracle izraisa notikumi.

1. Sākotnējā pamatdatu ielāde. Nolasiet nomenklatūras vienības, to struktūras, darba definīcijas, darba centrus, ražošanas resursus un kalendārus, izmantojot REST, vai vienreiz ielādējiet tos no FBDI izvilkumiem. Rūpīgi izvēlieties darba centru atbilstību: darba centrs ar četrām viena resursa iekārtām kļūst par vienu darba centru grupu vai četriem darba centriem. Katra ražošanas organizācija kļūst par darba centru grupu, tāpēc visas ražotnes ir iekļautas vienā plānā.

2. Ražošanas pasūtījumu sinhronizācija. Nolasiet izpildei nodotos un vēl nenodotos ražošanas pasūtījumus kopā ar to operācijām un materiāliem, kā arī atvērtos iepirkuma pasūtījumus. SkyPlanner uzskata pasūtīto materiālu par pieejamu iepirkuma pasūtījuma piegādes datumā un atjaunina krājumus, kad pasūtījumam piešķirts statuss Delivered.

Sastādiet grafiku ražošanas pasūtījumiem, nevis Supply Planning plānotajiem pasūtījumiem. Vispirms plānotie pasūtījumi Oracle sistēmā jāpārvērš par ražošanas pasūtījumiem.

3. Grafika ierakstīšana atpakaļ. Kad plānošanas dzinējs ievieto vai pārvieto ražošanas uzdevumu, SkyPlanner tīmekļa aizķere ierosina PATCH pieprasījumu uz workOrders/{WorkOrderId}/child/WorkOrderOperation/{WorkOrderOperationId} ar PlannedStartDate un PlannedCompletionDate. Spēkā ir Oracle noteikums: “The planned start date must not occur before the start date of the work order or after the finish date of the work order.” (Plānotais sākuma datums nedrīkst būt pirms ražošanas pasūtījuma sākuma datuma vai pēc tā beigu datuma.) (avots) Tāpēc, ja jaunais grafiks pārsniedz šīs robežas, integrācija vispirms ar PATCH atjaunina ražošanas pasūtījuma galvenes datumus un pēc tam operāciju datumus.

4. Izpildes apstiprinājumi ražotnē. Operatori reģistrē darbu ar SkyPlanner Mobile Confirmations vai Production Timer, un laika uzskaites ieraksti nodrošina grafika aktualitāti. Izpildītos daudzumus nosūta uz operationTransactions, bet darbinieku un iekārtu darba laiku — uz resourceTransactions. Ja jūsu ražotne jau reģistrē izpildi Oracle sistēmā, SkyPlanner tā vietā nolasa izpildes datus no tās.

5. Atbildība par datiem un konfliktu risināšanas noteikumi. Dokumentējiet tos pirms palaišanas:

Izvēlieties vienu sistēmu, kas ieraksta operāciju datumus. SkyPlanner nav vajadzīga Oracle grafiku sastādīšanas darbvieta, tāpēc plānoto datumu ierakstīšanā tas aizstāj Production Scheduling. Ja Production Scheduling joprojām nodod grafikus izpildei, nodaliet tā organizācijas no tām, kurām grafikus sastāda SkyPlanner.

• Plānotāja noklusējuma darbība. Oracle plānošanas dzinējs, kas neņem vērā jaudas ierobežojumus, tiek palaists, izveidojot ražošanas pasūtījumu, kā arī veicot “certain update actions” (noteiktas atjaunināšanas darbības). Pārbaudiet savā vidē, kuri atjauninājumi pārrēķina datumus, un nodrošiniet, lai SkyPlanner operāciju datumus ierakstītu pēdējais.
• Ražošanas pasūtījumu laika robežas. Operāciju datumiem jāiekļaujas starp ražošanas pasūtījuma sākuma un beigu datumu. Vispirms ar PATCH atjauniniet galveni.
• Basis Type. Resursu patēriņš ir norādīts uz vienu vienību tikai tad, ja Basis Type vērtība ir Variable. Vērtība Fixed nozīmē fiksētu laiku vienai operācijai. Importēšanas laikā veiciet pārrēķinu, citādi visi ilgumi būs nepareizi.
• Diskrētā un procesu ražošana. Diskrētajā ražošanā izmanto workOrders, bet procesu ražošanā — processWorkOrders. Ja izmantojat abus ražošanas veidus, definējiet atbilstības abiem.
• Lappusošana. Oracle ierobežo ierakstu skaitu vienā REST pieprasījumā. Katrā vaicājumā izmantojiet lappusošanu un filtrējiet pēc organizācijas un statusa.
• Ceturkšņa atjauninājumi. Oracle atjaunina Fusion katru ceturksni. Norādiet ceļā fiksētu REST versiju un pēc katra atjauninājuma veiciet atkārtotas pārbaudes.
• Statusu noteikumi. Ražošanas pasūtījumiem ar statusu Pending Approval vai slēgtu statusu nedrīkst piešķirt jaunus datumus. Izslēdziet tos ar filtru datu nolasīšanas laikā.