Vodnik za integracijo ProShop ERP za terminiranje proizvodnje s SkyPlanner APS

ProShop zunanjemu sistemu za terminiranje omogoča dva načina povezave, opisana v dokumentaciji ProShop API Developer Documents:

1. ProShop GraphQL API. “ProShop provides a GraphQL API, available via HTTP(S).” (ProShop ponuja GraphQL API, ki je dostopen prek HTTP(S).) Na voljo je ena končna točka: vsak klic je zahteva HTTP POST na <proshop root>/api/graphql s polji query, variables in operationName v telesu JSON. Vsak modul ima poizvedbo v ednini za posamezen zapis in poizvedbo v množini za sezname. Seznami se delijo na strani s parametroma pageSize (privzeto 20) in pageStart, vračajo records in totalRecords ter sprejemajo argumenta filter in query, ki ustrezata funkciji Advanced Search posameznega modula. Shemo je mogoče pregledati z introspekcijo. (Uvod v ProShop API)
2. Recently Updated Records API. “A simple REST interface allows external integrations to request information between arbitrary points in time.” (Preprost vmesnik REST zunanjim integracijam omogoča pridobivanje podatkov za poljubno časovno obdobje.) Pokličite <proshop root>/recentlyupdatedrecords s parametrom start (ISO 8601) ter neobveznima parametroma end in filterby, na primer workorders,workcells,purchaseorders,timetracking,deletions. Ekipa ProShop mora najprej omogočiti indeks. (Recently Updated Records API)

Zapisovanje poteka prek mutacij GraphQL. Dokumentirani primer je Time Tracking Login, pravice za zapisovanje pa se dodelijo za vsak modul posebej z obsegi pravic.

Razvijalska dokumentacija sistema ProShop ne opisuje izhodnih spletnih kavljev ali naročnin GraphQL. Podatki na strani sistema ProShop se pridobivajo s periodičnim poizvedovanjem, Recently Updated Records API pa pri tem zmanjša obremenitev: zahtevajte vse zapise, ustvarjene, spremenjene ali izbrisane od zadnjega izvajanja, in jih filtrirajte po vrstah zapisov, ki jih potrebuje terminski plan. Nato prek GraphQL pridobite spremenjene delovne naloge po številki. ProShop navaja, da je to hitreje kot poizvedovanje po lastModifiedTime.

Običajna izbira je petminutni cikel za delovne naloge in evidence časa ter urni cikel za dele in nabavna naročila. SkyPlanner ob spremembi stanja ali terminskega plana pošilja spletne kavlje, zato povratno zapisovanje temelji na dogodkih.

1. Začetni prenos matičnih podatkov. S poizvedbami GraphQL v množini po straneh preberite Parts, Work Cells, Users, Tools in Fixtures. Za prvi prenos nastavite visoko vrednost pageSize in ponavljajte poizvedbe glede na totalRecords. Določite preslikavo delovnih celic: strojne delovne celice postanejo delovni centri, delovne celice za osebe pa osebje. Tako lahko ista operacija hkrati rezervira stroj in njegovega operaterja.

2. Sinhronizacija delovnih nalogov. Preberite aktivne delovne naloge z operacijami, ciljnimi časi in zapisi BOM ter odprta nabavna naročila. SkyPlanner naročeni material šteje kot razpoložljiv na datum dobave nabavnega naročila in posodobi zalogo, ko je naročilo označeno kot Delivered. Zaznavanje sprememb poteka prek Recently Updated Records s parametrom filterby=workorders,purchaseorders,deletions.

3. Povratni zapis terminskega plana. Ko mehanizem za terminiranje razporedi ali premakne operacijo, spletni kavelj sistema SkyPlanner sproži mutacijo GraphQL, ki nastavi planirane datume delovnega naloga z uporabo Authorization s pravico workorders:w. ProShop nato pri napovedi pravočasne izvedbe in datumih potreb za nabavo uporablja datume iz sistema SkyPlanner.

4. Potrditve iz proizvodnje. Operaterji beležijo delo s SkyPlanner Mobile Confirmations ali Production Timer, časovni zapisi pa skrbijo za ažurnost terminskega plana. Sami izberete, ali se dejanski čas zapisuje nazaj v ProShop Time Tracking na ustrezno operacijo delovnega naloga. Če ne, operaterji čas še naprej beležijo v sistemu ProShop, SkyPlanner pa ga bere prek timetracking.

5. Pravila o lastništvu podatkov in reševanju neskladij. Zapišite jih pred prehodom v produkcijsko uporabo:

Za zapisovanje datumov delovnih nalogov izberite en sistem. Ko SkyPlanner prevzame terminiranje delovne celice, planerji v sistemu ProShop ne spreminjajo več vrstnega reda na njenem seznamu. Tako si terminska plana nikoli ne nasprotujeta.

• Normirani časi odločajo o vsem. ProShop izračuna trajanje na podlagi ocenjenih časov priprave in ciklov. Pridobite trenutne normirane čase, ne prvotne ocene. Čas priprave ločite od časa izvajanja, da lahko matrika pripravljalno-zaključnih časov nadomesti enotno vrednost za pripravo.
• Delovne celice, ki predstavljajo osebe. Delovna celica je lahko tudi oseba. Takšne celice preslikajte med osebje v SkyPlanner, ne med stroje, sicer bo vsak operater obravnavan kot vzporedni stroj.
• Time Tracking potrebuje uporabnika. Od aprila 2026 mutacija Time Tracking Login »requires user context« (zahteva uporabniški kontekst) in ni dovoljena s Client Credentials. Čas operaterjev zapisujte prek OAuth 2.0 Authorization Flow ali pa še naprej beležite čas v ProShop in ga od tam berite.
• Omogočite indeks sprememb. Recently Updated Records deluje šele, ko ga omogoči ekipa ProShop. Za vklop zaprosite že v prvem tednu.
• Zapisi z omejitvami ITAR. ProShop filtrira zapise z omejitvami ITAR za vsako povezavo posebej. Nastavitev v Developer System Config določa, ali se vrnejo kot vrednosti null ali pa se izpustijo. Dogovorite se, kateri delovni nalogi bodo dostopni integraciji, in pri vsakem branju ustrezno obravnavajte vrednosti null.
• Zunanja obdelava. Operacije pri zunanjih izvajalcih pomenijo pretečeni čas, ne porabe vaših zmogljivosti. Modelirajte jih kot korake, ki imajo le trajanje.