Vodnik za integracijo sistema Business Central s SkyPlanner APS za terminiranje proizvodnje

Integracija uporablja dva vmesnika, ki sta že vključena v Business Central:

1. API v2.0 za komercialne podatke in podatke o zalogah. Omogoča dostop do entitet items, itemVariants, itemLedgerEntries, locations, unitsOfMeasure, salesOrders, salesOrderLines, purchaseOrders, purchaseOrderLines, vendors, customers in employees. Proizvodnih entitet ne vključuje, zato se podatki o proizvodnji prenašajo prek drugega vmesnika.
2. Spletne storitve OData v4 za proizvodnjo. Vsako stran v sistemu Business Central lahko na strani Web Services objavite kot spletno storitev OData v4. Izberite vrsto objekta Page, ID strani in ime storitve ter nato označite Published. Končna točka je s tem aktivna, ne da bi morali pisati kodo AL ali namestiti razširitev. Integracija objavi standardne strani za sproščene proizvodne naloge, Prod. Order Routing Lines, delovne centre, strojne centre in tehnološke postopke, ki so dostopne na naslovu /ODataV4/Company('{name}')/{ServiceName}.

Objavljene strani omogočajo branje in pisanje. Microsoft navaja: “If an editable page is exposed as a web service, the data in the underlying table can be accessed and modified by an OData call,” (Če je stran, ki omogoča urejanje, izpostavljena kot spletna storitev, je mogoče s klicem OData dostopati do podatkov v pripadajoči tabeli in jih spreminjati), pri čemer se za posodobitve uporablja PATCH. Tako se planirani datumi zapisujejo nazaj v Business Central, prek iste strani in z istim preverjanjem veljavnosti, kot ju uporablja planer.

SOAP ne uporabljajte. Microsoft je spletne storitve SOAP označil kot zastarele, objavljanje Microsoftovih strani uporabniškega vmesnika prek SOAP pa bo odstranjeno v 2. valu izdaje 2026 (v29).

Business Central podpira naročnine na spletne kavlje prek POST /api/v2.0/subscriptions za entitete API v2.0, kot sta items in salesOrders. Veljajo naslednja pravila:

• Ustvarjanje naročnine zahteva potrditveno izmenjavo: vaša končna točka mora vrniti validationToken s statusom 200 OK.
• Naročnine potečejo po treh dneh. Obnovite jih s PATCH, pri čemer se ponovno izvede postopek potrditve povezave.
• Obvestila vsebujejo pot do vira, changeType in vaš clientState, ne pa celotnega zapisa. Zapis preberete naknadno.
• Obvestila prihajajo z zamikom: spletna različica Business Central po prvi spremembi počaka 30 sekund. Če se v tem času spremeni več kot 1.000 zapisov, prejmete eno obvestilo collection.
• V spletnem okolju je dovoljenih največ 200 naročnin na webhooke na okolje.

Proizvodni nalogi, vrstice tehnoloških postopkov in nabavni nalogi se preverjajo vsakih nekaj minut s poizvedovanjem po objavljenih straneh in entiteti purchaseOrders. S filtriranjem na odprte naloge in uporabo straničenja ostane število zahtev precej pod omejitvami sistema Business Central.

SkyPlanner ob spremembi stanja ali terminskega plana pošilja webhooke, zato povratno zapisovanje podatkov temelji na dogodkih.

1. Začetni prenos matičnih podatkov. Z objavljenih strani pridobite tehnološke postopke in proizvodne kosovnice s statusom Certified ter delovne in strojne centre, prek API v2.0 pa artikle in merske enote. Vsak delovni ali strojni center premišljeno preslikajte v delovni center v sistemu SkyPlanner: odločite se, ali bo delovni center s tremi strojnimi centri postal ena skupina delovnih centrov ali trije delovni centri.

2. Sinhronizacija nalogov. Z objavljenih strani preberite proizvodne naloge s statusom Released (in Firm Planned, če jih terminirate), skupaj z vrsticami tehnoloških postopkov in komponentami, prek API v2.0 pa še odprte vrstice nabavnih naročil. SkyPlanner obravnava naročeni material kot razpoložljiv na datum dobave nabavnega naročila in posodobi zalogo, ko naročilo dobi status Delivered. Pri terminiranju zato preverja tako zalogo kot pričakovane nabave.

Nikoli ne terminirajte proizvodnih nalogov s statusom Planned: Microsoft navaja, da jih Business Central “deletes them the next time you run planning.” (izbriše ob naslednjem zagonu planiranja). Planning Worksheet še naprej predlaga oskrbo, SkyPlanner pa potrjene naloge terminira glede na dejanske kapacitete.

3. Povratni zapis terminskega plana. Standardna stran Prod. Order Routing se objavi kot spletna storitev OData v4. Za vsako operacijo, ki jo je mehanizem razporedil ali premaknil, SkyPlanner pošlje zahtevo PATCH za ustrezno vrstico tehnološkega postopka z ETag v glavi If-Match. Nastavi polji Starting Date-Time in Ending Date-Time, ob premiku operacije na alternativni stroj pa še polji Type in No.

PATCH sproži prožilce strani in tabele, zato Business Central preveri veljavnost polj po lastni logiki, natanko tako kot pri planerjevem urejanju strani Prod. Order Routing. Ustrezno se posodobita tudi polji Starting Date-Time in Ending Date-Time v vrstici proizvodnega naloga. Količine, status in stroški ostajajo v pristojnosti sistema Business Central.

4. Potrjevanje dela v proizvodnji. Operaterji beležijo delo s SkyPlanner Mobile Confirmations ali Production Timer, časovni zapisi pa skrbijo za ažurnost terminskega plana. O proizvedenih količinah lahko v sistemu Business Central poročate kot doslej, prek Production Journal ali Output Journal.

Če želite povsem samodejno knjiženje proizvedenih količin in porabe, se v sistemu Business Central doda standardna stran API za knjiženje prek Output Journal. SkyPlanner nato za vsako operacijo knjiži pripravljalni čas, čas izvajanja in proizvedeno količino. Knjiženje posodobi Capacity Ledger Entries, proizvedena količina na zadnji operaciji tehnološkega postopka pa poveča zalogo artikla.

Za knjiženje proizvedenih količin izberite en kanal. Če knjižite tako iz sistema SkyPlanner kot iz Production Journal v sistemu Business Central, se vnosi podvojijo.

5. Pravila o pristojnosti za podatke in reševanju neskladij. Zapišite jih pred prehodom v produkcijo:

Glavni vir neskladij sta dejanji Refresh in Replan na proizvodnih nalogih. Microsoft navaja: “If you use the Refresh action to recalculate production order lines, Business Central deletes the existing production order lines and calculates new lines.” (Če z dejanjem Refresh ponovno izračunate vrstice proizvodnega naloga, Business Central izbriše obstoječe vrstice in izračuna nove.) Tudi Replan lahko spremeni potrebe po kapacitetah, ponovni izračun komponent pa “deletes previous changes in the components.” (izbriše prejšnje spremembe komponent).

Osveženi nalog obravnavajte kot novo različico, ga ponovno sinhronizirajte in prepustite ponovno terminiranje sistemu SkyPlanner. S funkcijo Autopilot SkyPlanner ob spremembah v proizvodnji samodejno ponovno terminira operacije.

• Enote v tehnoloških postopkih. Setup Time velja za posamezen proizvodni nalog, Run Time pa za posamezen proizvedeni artikel; vsak ima svojo vrednost Unit of Measure Code. Wait Time in Move Time ne zasedata kapacitet delovnega centra. Če je enota delovnega centra Days, en dan pomeni 24 ur, ne osemurne izmene. Enote pretvorite ob uvozu, sicer bodo vsa trajanja napačna.
• Neažurni koledarji. Kapacitete obstajajo šele, ko za plansko obdobje izvedete Calculate Work Center Calendar. Pred začetnim prenosom preverite polje Calendar Entries Available Until.
• Skrite kapacitete strojnih centrov. Če je Consolidated Calendar izklopljen, se planirajo le lastne kapacitete delovnega centra: “The machine center capacity is excluded.” (Kapacitete strojnega centra so izključene.) Kapacitete strojnih centrov berite neposredno, namesto da se zanašate na skupne vrednosti delovnega centra.
• Capacity in Efficiency. Business Central izračuna trajanje po formuli Run Time / Efficiency / Capacity, izračunani koledarski vnosi pa že upoštevajo obe vrednosti. Efficiency preslikajte v učinkovitost delovnega centra v sistemu SkyPlanner enkrat, ne dvakrat.
• Alternate Work Center je zgolj informativen podatek. Microsoft navaja, da “isn’t automatically included in planning processes.” (ni samodejno vključen v procese planiranja). Alternative izrecno modelirajte kot alternativne delovne centre v sistemu SkyPlanner.
• Omejevanje zahtev. V spletni različici omejitve veljajo za posameznega uporabnika, pri čemer storitvena identiteta šteje kot en uporabnik: 6.000 zahtev OData v drsečem 5-minutnem oknu in 5 sočasnih zahtev. Velikost strani je omejena na 20.000 zapisov, $batch na 100 operacij, časovna omejitev operacije pa je 8 minut. Ob prekoračitvi dovoljene pogostosti sistem vrne status 429. Namesto ponovnih prenosov vseh podatkov uporabljajte paketne zahteve, straničenje in poizvedovanje po spremembah.
• Licenciranje. Proizvodne funkcije so na voljo le v načinu Premium. Uporabniki z licenco Essentials se ne morejo prijaviti v podjetje, nastavljeno na Premium.