Guida all’integrazione di ProShop ERP per la schedulazione della produzione con SkyPlanner APS

ProShop offre due modalità di accesso a uno schedulatore esterno, descritte nei ProShop API Developer Documents:

1. ProShop GraphQL API. “ProShop provides a GraphQL API, available via HTTP(S).” (ProShop mette a disposizione un’API GraphQL accessibile tramite HTTP(S).) L’endpoint è unico: ogni chiamata è una richiesta HTTP POST a <proshop root>/api/graphql con query, variables e operationName nel corpo JSON. Ogni modulo dispone di una query al singolare per un solo record e di una query al plurale per gli elenchi. Gli elenchi sono paginati tramite pageSize (valore predefinito 20) e pageStart, restituiscono records e totalRecords e accettano gli argomenti filter e query, che rispecchiano la funzione Advanced Search di ciascun modulo. Lo schema supporta l’introspezione. (Introduzione all’API di ProShop)
2. Recently Updated Records API. “A simple REST interface allows external integrations to request information between arbitrary points in time.” (Una semplice interfaccia REST consente alle integrazioni esterne di richiedere informazioni relative a un intervallo di tempo a scelta.) Chiama <proshop root>/recentlyupdatedrecords con start (ISO 8601) e i parametri facoltativi end e filterby, ad esempio workorders,workcells,purchaseorders,timetracking,deletions. Prima occorre che il team ProShop abiliti l’indice. (Recently Updated Records API)

Le scritture avvengono tramite le mutation GraphQL. L’esempio documentato è Time Tracking Login; l’accesso in scrittura viene concesso per ciascun modulo tramite gli scope.

La documentazione per sviluppatori di ProShop non descrive webhook in uscita né sottoscrizioni GraphQL. I dati di ProShop vengono letti tramite polling, che la Recently Updated Records API rende poco oneroso: basta richiedere tutti i record creati, modificati o eliminati dall’ultima esecuzione, filtrando per i tipi di record necessari alla schedulazione. Gli ordini di produzione modificati vengono poi recuperati per numero tramite GraphQL: secondo ProShop, questo metodo è più veloce delle query basate su lastModifiedTime.

Una scelta tipica è un ciclo di cinque minuti per gli ordini di produzione e la rilevazione dei tempi, e un ciclo orario per gli articoli e gli ordini di acquisto. SkyPlanner invia webhook quando cambiano lo stato o il programma di produzione, quindi la scrittura dei dati in ProShop è guidata dagli eventi.

1. Caricamento iniziale delle anagrafiche. Scorri le pagine di Parts, Work Cells, Users, Tools e Fixtures con le query GraphQL al plurale. Imposta un valore elevato per pageSize al primo caricamento e ripeti le richieste fino a coprire totalRecords. Definisci la corrispondenza delle celle di lavoro: quelle associate alle macchine diventano centri di lavoro, quelle associate alle persone diventano personale. In questo modo, la stessa operazione può impegnare contemporaneamente una macchina e il suo operatore.

2. Sincronizzazione degli ordini di produzione. Leggi gli ordini di produzione attivi con le relative operazioni, i tempi obiettivo e i record BOM, insieme agli ordini di acquisto aperti. SkyPlanner considera il materiale ordinato disponibile alla data di consegna dell’ordine di acquisto e aggiorna le giacenze quando l’ordine viene contrassegnato come Delivered. Le modifiche vengono rilevate tramite Recently Updated Records con filterby=workorders,purchaseorders,deletions.

3. Scrittura del programma in ProShop. Quando il motore colloca o sposta un’operazione, un webhook SkyPlanner attiva una mutation GraphQL che imposta le date pianificate dell’ordine di produzione, usando un’Authorization con workorders:w. La previsione di ProShop sul rispetto delle consegne e le date di fabbisogno degli acquisti si basano quindi sulle date di SkyPlanner.

4. Consuntivazioni in reparto. Gli operatori registrano il lavoro con SkyPlanner Mobile Confirmations o Production Timer e le registrazioni dei tempi mantengono aggiornato il programma. Puoi scegliere se inviare i tempi effettivi a ProShop Time Tracking, associandoli all’operazione dell’ordine di produzione. In caso contrario, gli operatori continuano a registrare i tempi in ProShop come prima e SkyPlanner li legge tramite timetracking.

5. Responsabilità sui dati e regole per i conflitti. Mettile per iscritto prima della messa in produzione:

Scegli un solo sistema per scrivere le date degli ordini di produzione. Quando SkyPlanner gestisce la schedulazione di una cella di lavoro, i pianificatori smettono di riordinarne l’elenco in ProShop, così i due programmi non entrano mai in conflitto.

• I tempi obiettivo determinano tutto. ProShop calcola la durata a partire dai tempi stimati di attrezzaggio e di ciclo. Acquisisci i tempi obiettivo attuali, non la stima originale, e separa l’attrezzaggio dal tempo di lavorazione, così che la matrice dei tempi di attrezzaggio possa sostituire il singolo valore di attrezzaggio.
• Celle di lavoro che rappresentano persone. Una cella di lavoro può essere una persona. Associa queste celle al personale di SkyPlanner, non alle macchine, altrimenti ogni operatore diventa una macchina in parallelo.
• Time Tracking richiede un utente. Da aprile 2026 la mutation Time Tracking Login “requires user context” (richiede un contesto utente) e non è autorizzata con Client Credentials. Invia i tempi degli operatori tramite OAuth 2.0 Authorization Flow, oppure continua a registrare le timbrature in ProShop e leggile da lì.
• Abilita l’indice delle modifiche. Recently Updated Records funziona solo dopo l’abilitazione da parte del team ProShop. Richiedila nella prima settimana.
• Record soggetti a ITAR. ProShop filtra i record soggetti alle restrizioni ITAR per ciascuna connessione; un’opzione di Developer System Config stabilisce se restituirli come valori null o escluderli. Concorda quali ordini di produzione saranno visibili all’integrazione e gestisci i valori null a ogni lettura.
• Lavorazioni esterne. Le operazioni presso i fornitori incidono sui tempi, non sulla capacità interna. Modellale come fasi con la sola durata.