Guide til ProShop ERP integration med SkyPlanner APS til produktionsplanlægning

ProShop tilbyder to integrationsveje til et eksternt planlægningssystem. Begge er beskrevet i ProShop API Developer Documents:

1. ProShop GraphQL API. “ProShop provides a GraphQL API, available via HTTP(S).” (ProShop stiller en GraphQL API til rådighed via HTTP(S).) Der er ét endpoint: Alle kald er HTTP POST til <proshop root>/api/graphql med query, variables og operationName i en JSON-body. Hvert modul har en forespørgsel i ental til én post og en forespørgsel i flertal til lister. Lister sideinddeles med pageSize (standard 20) og pageStart, returnerer records og totalRecords og accepterer argumenterne filter og query, som svarer til modulets Advanced Search. Skemaet understøtter introspektion. (Introduktion til ProShop API)
2. Recently Updated Records API. “A simple REST interface allows external integrations to request information between arbitrary points in time.” (En enkel REST-grænseflade lader eksterne integrationer hente oplysninger mellem vilkårlige tidspunkter.) Kald <proshop root>/recentlyupdatedrecords med start (ISO 8601) og eventuelt end og filterby, for eksempel workorders,workcells,purchaseorders,timetracking,deletions. ProShop-teamet skal først aktivere indekset. (Recently Updated Records API)

Skrivning sker via GraphQL-mutationer. Time Tracking Login er det dokumenterede eksempel, og skriveadgang tildeles pr. modul via scopes.

ProShops udviklerdokumentation beskriver hverken udgående webhooks eller GraphQL-abonnementer. Data fra ProShop hentes derfor med polling, og Recently Updated Records API holder ressourceforbruget nede: Hent alt, der er oprettet, ændret eller slettet siden sidste kørsel, filtreret til de posttyper, planen har brug for. Hent derefter de ændrede produktionsordrer via deres nummer med GraphQL. Ifølge ProShop er det hurtigere end at søge på lastModifiedTime.

Et typisk valg er at hente produktionsordrer og tidsregistreringer hvert femte minut og emner og indkøbsordrer hver time. SkyPlanner sender webhooks, når tilstanden eller planen ændres, så tilbageskrivningen er hændelsesstyret.

1. Første indlæsning af stamdata. Hent Parts, Work Cells, Users, Tools og Fixtures side for side med GraphQL-forespørgsler i flertal. Sæt pageSize højt ved første indlæsning, og gentag hentningen ud fra totalRecords. Fastlæg, hvordan arbejdscellerne skal mappes: Arbejdsceller, der repræsenterer maskiner, bliver til arbejdsstationer, og arbejdsceller, der repræsenterer personer, bliver til personale, så samme operation kan reservere en maskine og dens operatør samlet.

2. Synkronisering af produktionsordrer. Hent aktive produktionsordrer med tilhørende operationer, normtider og BOM-poster samt åbne indkøbsordrer. SkyPlanner regner bestilte materialer som tilgængelige på indkøbsordrens leveringsdato og opdaterer lagerbeholdningen, når indkøbsordren markeres som Delivered. Ændringer registreres via Recently Updated Records med filterby=workorders,purchaseorders,deletions.

3. Tilbageskrivning af planen. Når planlægningsmotoren placerer eller flytter en opgave, udløser en SkyPlanner-webhook en GraphQL-mutation, som sætter produktionsordrens planlagte datoer via en Authorization med workorders:w. ProShops prognose for rettidig levering og behovsdatoerne for indkøb baseres derefter på SkyPlanners datoer.

4. Tilbagemeldinger fra produktionen. Operatørerne registrerer arbejdet med SkyPlanner Mobile Confirmations eller Production Timer, og tidsregistreringerne holder planen ajour. I vælger, om den faktiske tid skal skrives tilbage til ProShop Time Tracking på produktionsordrens operation. Hvis ikke, registrerer operatørerne tiden i ProShop som hidtil, og SkyPlanner henter den via timetracking.

5. Dataejerskab og konfliktregler. Skriv dem ned inden idriftsættelsen:

Vælg ét system til at skrive produktionsordrernes datoer. Når SkyPlanner overtager planlægningen af en arbejdscelle, holder planlæggerne op med at ændre rækkefølgen på cellens liste i ProShop. Så konkurrerer de to planer aldrig.

• Normtiderne er afgørende. ProShop beregner varigheden ud fra estimerede omstillings- og cyklustider. Hent de aktuelle normtider, ikke det oprindelige estimat, og hold omstillingstid adskilt fra køretid, så omstillingsmatricen kan erstatte den faste omstillingstid.
• Personer som arbejdsceller. En arbejdscelle kan være en person. Knyt disse arbejdsceller til personale i SkyPlanner, ikke til maskiner. Ellers behandles hver operatør som en maskine, der kan køre parallelt med de øvrige.
• Time Tracking kræver en bruger. Siden april 2026 har mutationen Time Tracking Login haft kravet “requires user context” (kræver brugerkontekst) og er ikke tilladt med Client Credentials. Send operatørernes tidsregistreringer via OAuth 2.0 Authorization Flow, eller behold tidsregistreringen i ProShop, og læs den derfra.
• Aktivér ændringsindekset. Recently Updated Records virker først, når ProShop-teamet har aktiveret det. Bed om det i den første uge.
• ITAR-poster. ProShop filtrerer ITAR-begrænsede poster for hver forbindelse, og en indstilling i Developer System Config afgør, om de returneres som null-værdier eller udelades. Aftal, hvilke produktionsordrer integrationen har adgang til, og håndtér null-værdier ved hver læsning.
• Ekstern bearbejdning. Operationer hos leverandører tager tid, men belaster ikke din kapacitet. Modellér dem som trin, der kun optager tid.