Business Central integrācijas ceļvedis ražošanas grafiku sastādīšanai ar SkyPlanner APS

Integrācija izmanto divas saskarnes, kas jau ir iekļautas Business Central:

1. API v2.0 komercdatiem un krājumu datiem. Tā nodrošina piekļuvi items, itemVariants, itemLedgerEntries, locations, unitsOfMeasure, salesOrders, salesOrderLines, purchaseOrders, purchaseOrderLines, vendors, customers un employees. Tajā nav ražošanas entītiju, tāpēc ražošanas dati tiek iegūti ar otru saskarni.
2. OData v4 tīmekļa pakalpojumi ražošanas datiem. Jebkuru Business Central lapu var publicēt kā OData v4 tīmekļa pakalpojumu lapā Web Services. Izvēlieties objekta tipu Page, lapas ID un pakalpojuma nosaukumu, pēc tam atzīmējiet Published. Galapunkts ir gatavs darbam — nav jāraksta AL kods vai jāizvieto paplašinājums. Integrācijai tiek publicētas standarta lapas izlaistajiem ražošanas pasūtījumiem, Prod. Order Routing Lines, darba centriem, iekārtu centriem un tehnoloģiskajiem procesiem. Tās ir pieejamas adresē /ODataV4/Company('{name}')/{ServiceName}.

Publicētās lapas ļauj gan lasīt, gan rakstīt datus. Microsoft norāda: “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,” (ja rediģējama lapa ir publicēta kā tīmekļa pakalpojums, tās pamatā esošās tabulas datiem var piekļūt un tos mainīt ar OData izsaukumu). Atjaunināšanai izmanto PATCH. Šādi plānotie datumi tiek ierakstīti atpakaļ Business Central, izmantojot to pašu lapu un tās pašas pārbaudes, ko izmanto plānotājs.

Neizmantojiet SOAP. Microsoft ir atzinis SOAP tīmekļa pakalpojumus par novecojušiem, un 2026. gada 2. laidienu vilnī (v29) tiek noņemta iespēja publicēt Microsoft lietotāja saskarnes lapas kā SOAP pakalpojumus.

Business Central atbalsta tīmekļa aizķeru abonementus, izmantojot POST /api/v2.0/subscriptions, tādām API v2.0 entītijām kā items un salesOrders. Nosacījumi:

• Abonementa izveidei nepieciešama savienojuma apstiprināšana: jūsu galapunktam jāatgriež validationToken ar statusu 200 OK.
• Abonementu derīguma termiņš beidzas pēc trim dienām. Atjaunojiet tos ar PATCH, un savienojuma apstiprināšana notiks atkārtoti.
• Paziņojumos ir resursa ceļš, changeType un jūsu clientState, nevis pilns ieraksts. Pats ieraksts jānolasa pēc tam.
• Paziņojumi tiek nosūtīti ar aizkavi: Business Central tiešsaistes versija pēc pirmajām izmaiņām nogaida 30 sekundes. Ja šajā laikā mainīti vairāk nekā 1 000 ieraksti, par tiem pienāk viens collection paziņojums.
• Tiešsaistes versijā vienā vidē drīkst būt ne vairāk kā 200 tīmekļa aizķeru abonementu.

Ražošanas pasūtījumi, tehnoloģisko procesu rindas un iepirkuma pasūtījumi tiek aptaujāti ik pēc dažām minūtēm, izmantojot publicētās lapas un purchaseOrders. Atlasot tikai atvērtos pasūtījumus un iegūstot datus pa lapām, pieprasījumu skaits paliek krietni zem Business Central ierobežojumiem.

Kad mainās stāvoklis vai grafiks, SkyPlanner nosūta tīmekļa aizķeru paziņojumus, tāpēc datu ierakstīšanu atpakaļ sistēmā ierosina notikumi.

1. Sākotnējā pamatdatu ielāde. No publicētajām lapām iegūstiet tehnoloģiskos procesus un ražošanas BOM ar statusu Certified, kā arī darba centrus un iekārtu centrus, bet no API v2.0 — preces un mērvienības. Rūpīgi izvēlieties, kā katru darba centru vai iekārtu centru piesaistīt SkyPlanner darba centram: izlemiet, vai darba centrs ar trim iekārtu centriem kļūs par vienu darba centru grupu vai trim darba centriem.

2. Pasūtījumu sinhronizācija. No publicētajām lapām nolasiet ražošanas pasūtījumus ar statusu Released (un Firm Planned, ja arī tiem sastādāt grafiku), to tehnoloģiskā procesa rindas un komponentus, bet no API v2.0 — atvērtās iepirkuma pasūtījumu rindas. SkyPlanner uzskata pasūtīto materiālu par pieejamu iepirkuma pasūtījuma piegādes datumā un atjaunina krājumus, kad iepirkuma pasūtījumam piešķirts statuss Delivered. Tādējādi, sastādot grafiku, tiek pārbaudīti gan krājumi, gan gaidāmās iepirkumu piegādes.

Nekad nesastādiet grafiku ražošanas pasūtījumiem ar statusu Planned: Microsoft norāda, ka Business Central “deletes them the next time you run planning.” (dzēš tos nākamajā plānošanas palaišanas reizē). Planning Worksheet turpina piedāvāt apgādi, bet SkyPlanner sastāda apstiprināto pasūtījumu grafiku, ņemot vērā reālo jaudu.

3. Grafika ierakstīšana atpakaļ. Standarta lapa Prod. Order Routing tiek publicēta kā OData v4 tīmekļa pakalpojums. Katrai operācijai, ko plānošanas dzinis ir ieplānojis vai pārvietojis, SkyPlanner nosūta PATCH pieprasījumu attiecīgajai tehnoloģiskā procesa rindai ar If-Match ETag. Tas iestata laukus Starting Date-Time un Ending Date-Time, kā arī Type un No., ja operācija pārvietota uz alternatīvu iekārtu.

PATCH iedarbina lapas un tabulas trigerus, tāpēc Business Central pārbauda laukus pēc savas loģikas — tieši tāpat kā tad, kad plānotājs rediģē lapu Prod. Order Routing. Attiecīgi tiek atjaunināti arī ražošanas pasūtījuma rindas lauki Starting un Ending Date-Time. Daudzumus, statusu un izmaksas turpina pārvaldīt Business Central.

4. Ražošanas izpildes apstiprinājumi. Operatori reģistrē darbu ar SkyPlanner Mobile Confirmations vai Production Timer, un darba laika uzskaites ieraksti uztur grafiku aktuālu. Saražoto apjomu Business Central var uzskaitīt tāpat kā iepriekš, izmantojot Production Journal vai Output Journal.

Ja vēlaties pilnībā automātisku saražotā apjoma un patēriņa grāmatošanu, tiek pievienota standarta Business Central API lapa izlaides žurnāla grāmatošanai. Tad SkyPlanner katrai operācijai grāmato pārregulēšanas laiku, izpildes laiku un saražoto daudzumu. Grāmatošana atjaunina Capacity Ledger Entries, un pēdējā tehnoloģiskā procesa operācijā saražotās preces tiek pievienotas krājumiem.

Izvēlieties vienu saražotā apjoma grāmatošanas kanālu. Grāmatojot gan no SkyPlanner, gan no Business Central Production Journal, ieraksti dublējas.

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

Galvenais konfliktu avots ir ražošanas pasūtījumu darbības Refresh un Replan. Microsoft norāda: “If you use the Refresh action to recalculate production order lines, Business Central deletes the existing production order lines and calculates new lines.” (Ja ražošanas pasūtījuma rindu pārrēķināšanai izmanto darbību Refresh, Business Central dzēš esošās ražošanas pasūtījuma rindas un aprēķina jaunas.) Arī Replan var mainīt nepieciešamo jaudu, savukārt komponentu pārrēķināšana “deletes previous changes in the components.” (dzēš iepriekš veiktās izmaiņas komponentos).

Uztveriet atsvaidzinātu pasūtījumu kā jaunu versiju, sinhronizējiet to atkārtoti un ļaujiet SkyPlanner pārplānot grafiku. Izmantojot Autopilot, SkyPlanner automātiski pārplāno grafiku, kad ražošanā rodas izmaiņas.

• Mērvienības tehnoloģiskajos procesos. Setup Time attiecas uz ražošanas pasūtījumu, Run Time — uz vienu saražoto vienību, un katram ir savs Unit of Measure Code. Wait Time un Move Time nepatērē darba centra jaudu. Ja darba centra mērvienība ir Days, viena diena ir 24 stundas, nevis astoņu stundu maiņa. Importēšanas laikā pārrēķiniet mērvienības, citādi visi ilgumi būs nepareizi.
• Neaktuāli kalendāri. Jauda ir pieejama tikai pēc tam, kad attiecīgajam plānošanas periodam ir izpildīta darbība Calculate Work Center Calendar. Pirms sākotnējās ielādes pārbaudiet lauku Calendar Entries Available Until.
• Iekārtu centru jauda nav redzama. Ja Consolidated Calendar ir izslēgts, tiek plānota tikai paša darba centra jauda: “The machine center capacity is excluded.” (Iekārtu centra jauda netiek iekļauta.) Nolasiet iekārtu centru jaudu tieši, nevis paļaujieties uz darba centra kopsummām.
• Capacity un Efficiency. Business Central aprēķina ilgumu pēc formulas Run Time / Efficiency / Capacity, un aprēķinātajos kalendāra ierakstos abi lielumi jau ir ņemti vērā. Piesaistiet Efficiency SkyPlanner darba centra efektivitātei vienu reizi, nevis divreiz.
• Alternate Work Center ir tikai informatīvs. Microsoft norāda, ka tas “isn’t automatically included in planning processes.” (netiek automātiski iekļauts plānošanas procesos). Norādiet alternatīvas tieši kā SkyPlanner alternatīvos darba centrus.
• Pieprasījumu ierobežošana. Tiešsaistes versijā ierobežojumi attiecas uz katru lietotāju, un pakalpojuma identitāte tiek uzskatīta par vienu lietotāju: 6 000 OData pieprasījumu slīdošā 5 minūšu intervālā un 5 vienlaicīgi pieprasījumi. Lapas lieluma ierobežojums ir 20 000 ierakstu, $batch ierobežojums — 100 operāciju, un operācijas noildze iestājas pēc 8 minūtēm. Pārsniedzot pieprasījumu biežuma ierobežojumu, tiek atgriezts statuss 429. Pilnas datu pārlādes vietā apstrādājiet izmaiņas paketēs, iegūstiet tās pa lapām un aptaujājiet tikai izmaiņas.
• Licencēšana. Ražošanas funkcionalitāte ir pieejama tikai Premium režīmā. Lietotāji ar Essentials licenci nevar pierakstīties uzņēmumā, kuram iestatīts Premium režīms.