Ghid de integrare ProShop ERP pentru programarea producției cu SkyPlanner APS

ProShop oferă unui sistem extern de programare două căi de integrare, descrise în documentația ProShop API pentru dezvoltatori:

1. ProShop GraphQL API. “ProShop provides a GraphQL API, available via HTTP(S).” (ProShop oferă un API GraphQL, disponibil prin HTTP(S).) Există un singur endpoint: fiecare apel este o cerere HTTP POST către <proshop root>/api/graphql, cu query, variables și operationName în corpul JSON. Fiecare modul are o interogare la singular pentru o singură înregistrare și una la plural pentru liste. Listele sunt paginate cu pageSize (implicit 20) și pageStart, returnează records și totalRecords și acceptă argumentele filter și query, care corespund funcției Advanced Search din fiecare modul. Schema permite introspecția. (Introducere în API-ul ProShop)
2. Recently Updated Records API. “A simple REST interface allows external integrations to request information between arbitrary points in time.” (O interfață REST simplă permite integrărilor externe să solicite informații pentru orice interval de timp.) Apelați <proshop root>/recentlyupdatedrecords cu start (ISO 8601) și, opțional, cu end și filterby, de exemplu workorders,workcells,purchaseorders,timetracking,deletions. Echipa ProShop trebuie mai întâi să activeze indexul. (Recently Updated Records API)

Scrierea datelor se face prin mutații GraphQL. Exemplul documentat este Time Tracking Login, iar accesul de scriere se acordă pentru fiecare modul prin permisiuni de tip scope.

Documentația ProShop pentru dezvoltatori nu descrie webhook-uri de ieșire sau abonamente GraphQL. Datele din ProShop sunt preluate prin interogare periodică, iar Recently Updated Records API reduce costul acestei operații: solicitați tot ce a fost creat, modificat sau șters de la ultima rulare, filtrând după tipurile de înregistrări necesare programării. Apoi preluați prin GraphQL comenzile de producție modificate, după număr. ProShop precizează că această metodă este mai rapidă decât interogarea după lastModifiedTime.

O alegere obișnuită este un ciclu de cinci minute pentru comenzile de producție și pontaj și unul de o oră pentru piese și comenzile de achiziție. SkyPlanner trimite webhook-uri când se modifică starea sau programul de producție, astfel încât scrierea datelor înapoi este declanșată de evenimente.

1. Încărcarea inițială a nomenclatoarelor. Parcurgeți înregistrările Parts, Work Cells, Users, Tools și Fixtures pagină cu pagină, folosind interogări GraphQL la plural. Setați o valoare mare pentru pageSize la prima încărcare și continuați iterarea pe baza totalRecords. Stabiliți maparea celulelor de lucru: cele care reprezintă utilaje devin centre de lucru, iar cele care reprezintă persoane devin personal, astfel încât aceeași operație să poată rezerva simultan un utilaj și operatorul său.

2. Sincronizarea comenzilor de producție. Citiți comenzile de producție active cu operațiile, timpii-țintă și înregistrările BOM aferente, precum și comenzile de achiziție deschise. SkyPlanner consideră materialul comandat disponibil la data de livrare din comanda de achiziție și actualizează stocul când aceasta este marcată Delivered. Modificările sunt detectate prin Recently Updated Records cu filterby=workorders,purchaseorders,deletions.

3. Scrierea programului de producție înapoi în ProShop. Când motorul plasează sau mută o operație, un webhook SkyPlanner declanșează o mutație GraphQL care stabilește datele planificate ale comenzii de producție, folosind o Authorization cu workorders:w. Prognoza ProShop privind respectarea termenelor și datele de necesar pentru achiziții se bazează apoi pe datele din SkyPlanner.

4. Confirmări din atelier. Operatorii înregistrează munca folosind SkyPlanner Mobile Confirmations sau Production Timer, iar înregistrările de timp mențin programul de producție la zi. Dumneavoastră alegeți dacă timpul efectiv lucrat este trimis înapoi în ProShop Time Tracking pentru operația aferentă comenzii de producție. Dacă nu, operatorii pontează în ProShop ca înainte, iar SkyPlanner citește datele prin timetracking.

5. Responsabilitatea pentru date și regulile de soluționare a conflictelor. Documentați-le înainte de punerea în producție:

Alegeți un singur sistem care să scrie datele comenzilor de producție. După ce SkyPlanner preia programarea unei celule de lucru, planificatorii nu mai schimbă ordinea listei acelei celule în ProShop. Astfel, cele două programe nu intră niciodată în conflict.

• Timpii țintă sunt decisivi. ProShop calculează durata pe baza timpilor estimați de pregătire și de ciclu. Preluați timpii țintă actuali, nu estimarea inițială, și separați timpul de pregătire de timpul de execuție, astfel încât matricea timpilor de pregătire să poată înlocui valoarea unică de pregătire.
• Celule de lucru care reprezintă persoane. O celulă de lucru poate fi o persoană. Asociați aceste celule cu personalul din SkyPlanner, nu cu utilajele; altfel, fiecare operator devine un utilaj care lucrează în paralel.
• Time Tracking necesită un utilizator. Din aprilie 2026, mutația Time Tracking Login „requires user context” (necesită contextul unui utilizator) și nu este autorizată prin Client Credentials. Transmiteți timpii operatorilor prin OAuth 2.0 Authorization Flow sau păstrați pontajul în ProShop și citiți-l de acolo.
• Activați indexul modificărilor. Recently Updated Records funcționează doar după ce echipa ProShop îl activează. Solicitați activarea în prima săptămână.
• Înregistrări supuse restricțiilor ITAR. ProShop filtrează înregistrările supuse restricțiilor ITAR pentru fiecare conexiune, iar o opțiune din Developer System Config stabilește dacă acestea sunt returnate ca valori null sau sunt omise. Stabiliți de comun acord la ce comenzi de producție are acces integrarea și tratați valorile null la fiecare citire.
• Prelucrări externalizate. Operațiile efectuate de furnizori înseamnă timp scurs, nu consum din capacitatea proprie. Modelați-le ca etape care au doar durată.