Guide til ProShop ERP-integrasjon for produksjonsplanlegging med SkyPlanner APS

ProShop gir eksterne planleggingssystemer to tilkoblingsmuligheter, beskrevet i ProShop API Developer Documents:

1. ProShop GraphQL API. «ProShop provides a GraphQL API, available via HTTP(S).» (ProShop tilbyr et GraphQL API som er tilgjengelig via HTTP(S).) Det finnes ett endepunkt: Alle kall sendes som HTTP POST til <proshop root>/api/graphql med query, variables og operationName i JSON-kroppen. Hver modul har en spørring i entall for enkeltposter og en spørring i flertall for lister. Listene deles inn i sider med pageSize (standard 20) og pageStart, returnerer records og totalRecords og godtar argumentene filter og query, som tilsvarer modulens Advanced Search. Skjemaet støtter introspeksjon. (Introduksjon til ProShop API)
2. Recently Updated Records API. «A simple REST interface allows external integrations to request information between arbitrary points in time.» (Et enkelt REST-grensesnitt lar eksterne integrasjoner be om informasjon mellom vilkårlige tidspunkter.) Kall <proshop root>/recentlyupdatedrecords med start (ISO 8601) og eventuelt end og filterby, for eksempel workorders,workcells,purchaseorders,timetracking,deletions. ProShop-teamet må først aktivere indeksen. (Recently Updated Records API)

Data skrives via GraphQL-mutasjoner. Time Tracking Login er det dokumenterte eksempelet, og skrivetilgang gis per modul gjennom tilgangsomfang (scopes).

ProShops utviklerdokumentasjon beskriver ingen utgående webhooks eller GraphQL-abonnementer. Data fra ProShop hentes med polling, og Recently Updated Records API gjør dette lite ressurskrevende: Be om alt som er opprettet, endret eller slettet siden forrige kjøring, filtrert på posttypene planen trenger. Hent deretter de endrede produksjonsordrene etter nummer via GraphQL. ProShop opplyser at dette er raskere enn å søke etter lastModifiedTime.

Et vanlig valg er å hente produksjonsordrer og tidsregistreringer hvert femte minutt, og deler og innkjøpsordrer hver time. SkyPlanner sender webhooks når status eller planen endres, så tilbakeskrivingen er hendelsesstyrt.

1. Første innlasting av grunndata. Hent Parts, Work Cells, Users, Tools og Fixtures side for side med GraphQL-spørringer i flertall. Sett pageSize høyt ved første innlasting, og bruk totalRecords til å styre løkken. Avklar hvordan arbeidscellene skal kobles: Maskinceller blir arbeidsstasjoner, og personceller blir personell, slik at samme operasjon kan reservere både maskin og operatør samtidig.

2. Synkronisering av produksjonsordrer. Les inn aktive produksjonsordrer med operasjoner, normtider og BOM-poster, samt åpne innkjøpsordrer. SkyPlanner regner bestilt materiale som tilgjengelig på innkjøpsordrens leveringsdato og oppdaterer lagerbeholdningen når innkjøpsordren merkes som Delivered. Endringer oppdages gjennom Recently Updated Records med filterby=workorders,purchaseorders,deletions.

3. Tilbakeskriving av planen. Når planleggingsmotoren plasserer eller flytter en jobb, utløser en SkyPlanner-webhook en GraphQL-mutasjon som setter produksjonsordrens planlagte datoer, med en Authorization som har workorders:w. ProShops prognose for levering til rett tid og behovsdatoene for innkjøp bygger da på datoene fra SkyPlanner.

4. Bekreftelser fra produksjonsgulvet. Operatørene registrerer arbeid med SkyPlanner Mobile Confirmations eller Production Timer, og tidsregistreringene holder planen oppdatert. Dere velger om faktisk tidsbruk skal skrives tilbake til ProShop Time Tracking på den aktuelle operasjonen i produksjonsordren. Hvis ikke registrerer operatørene tid i ProShop som før, og SkyPlanner leser den via timetracking.

5. Regler for dataeierskap og konflikter. Dokumenter dem før produksjonssetting:

Velg ett system som skriver datoene på produksjonsordrene. Når SkyPlanner planlegger en arbeidscelle, slutter planleggerne å endre rekkefølgen i listen for denne cellen i ProShop. Da konkurrerer aldri de to planene.

• Normtidene avgjør alt. ProShop beregner varigheten ut fra estimert omstillingstid og syklustid. Hent gjeldende normtider, ikke det opprinnelige estimatet, og skill omstillingstid fra kjøretid. Da kan matrisen for omstillingstid erstatte den ene faste omstillingsverdien.
• Arbeidsceller som er personer. En arbeidscelle kan være en person. Koble disse til personell i SkyPlanner, ikke til maskiner. Ellers blir hver operatør en parallell maskin.
• Time Tracking krever en bruker. Siden april 2026 har Time Tracking Login-mutasjonen hatt kravet «requires user context» (krever brukerkontekst), og den er ikke autorisert med Client Credentials. Send operatørtid via OAuth 2.0 Authorization Flow, eller behold tidsregistreringen i ProShop og les den derfra.
• Få aktivert endringsindeksen. Recently Updated Records fungerer først når ProShop-teamet har aktivert den. Be om dette i den første uken.
• ITAR-begrensede poster. ProShop filtrerer ITAR-begrensede poster per tilkobling. En innstilling i Developer System Config avgjør om de returneres som nullverdier eller utelates. Avtal hvilke produksjonsordrer integrasjonen skal ha tilgang til, og håndter nullverdier ved hver lesing.
• Ekstern bearbeiding. Operasjoner hos leverandører tar tid, men belaster ikke din kapasitet. Modeller dem som trinn som bare tar tid.