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

SYSPRO offre a uno schedulatore esterno due modalità di accesso ai dati:

1. e.net Solutions Business Objects. Consentono di richiamare dall’esterno la logica applicativa di SYSPRO, con dati XML in ingresso e in uscita. Esistono tre famiglie: Query (ad esempio WIPQBL, WIP Balance Query), Transaction o Post (ad esempio WIPTJB, WIP Job Creation and Maintenance) e Setup per le anagrafiche. I business object applicano gli stessi controlli delle schermate di SYSPRO e mantengono la compatibilità tra le versioni. La guida alle buone pratiche di SYSPRO è esplicita: “SYSPRO’s Business Objects are used to query and post data to SYSPRO.” (I Business Objects di SYSPRO servono a interrogare e registrare dati in SYSPRO.)
2. SYSPRO OData Service (OData v4). Offre accesso RESTful in sola lettura ai database aziendali e di sistema e alle Business Activity Queries, viste SQL definite in SYSPRO. È disponibile a partire da SYSPRO 8 2021 R2. Per SYSPRO Cloud ERP, “Syspro OData is the only mechanism available when applications need access to SYSPRO data.” (Syspro OData è l’unico meccanismo disponibile quando le applicazioni devono accedere ai dati di SYSPRO.)

I business object vengono richiamati tramite il servizio e.net Communications, utilizzando SYSPRO WCF Service o SYSPRO Web Service.

Master Data Take On (IMPIMP) importa fogli di calcolo tramite i business object Setup ed è utile per un caricamento una tantum delle anagrafiche. SYSPRO Harmony raggiunge il fine vita il 31 dicembre 2026: non basatevi quindi su questo prodotto per nuovi sviluppi.

SYSPRO non invia webhook in uscita. Electronic Signature Transaction Setup può attivare trigger, come l’invio di un’email o l’esecuzione di uno script VBScript, quando una transazione va a buon fine. SYSPRO precisa però: “It is not intended that triggers from e.net Business Objects fire VBScript triggers.” (Non è previsto che i trigger degli e.net Business Objects attivino trigger VBScript.)

Il lato SYSPRO viene quindi interrogato tramite polling. Le query dei business object o le richieste OData, filtrate per ordini di produzione aperti e modifiche recenti, rilevano i nuovi ordini da elaborare. La frequenza viene definita per ogni stabilimento: ogni pochi minuti per gli ordini di produzione, ogni ora per le giacenze.

SkyPlanner invia webhook quando cambia lo stato o la schedulazione: l’aggiornamento dei dati in SYSPRO è quindi basato sugli eventi.

1. Caricamento iniziale delle anagrafiche. Leggete Stock Codes, Structures and Routings, centri di lavoro, macchine e calendari tramite OData o business object Query. Definite con attenzione la corrispondenza dei centri di lavoro in SkyPlanner: un centro con quattro macchine diventa un gruppo di centri di lavoro oppure quattro centri di lavoro.

2. Sincronizzazione degli ordini di produzione. Leggete gli ordini effettivi con le relative operazioni e i materiali, 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.

Schedulate solo gli ordini di produzione effettivi. Le proposte d’ordine rimangono nell’istantanea MRP finché MRP Job Review non le trasforma in ordini di produzione.

3. Aggiornamento delle date in SYSPRO. Quando il motore colloca o sposta un’operazione, un webhook di SkyPlanner attiva una chiamata di registrazione al business object WIP Job Creation and Maintenance (WIPTJB). La chiamata imposta le date pianificate di inizio e fine dell’ordine di produzione. Il business object convalida la modifica esattamente come farebbe Job Entry.

4. Conferme dal reparto produttivo. Gli operatori registrano il lavoro con SkyPlanner Mobile Confirmations o Production Timer e i tempi registrati mantengono aggiornata la schedulazione. Siete voi a scegliere se trasferire i tempi effettivi a SYSPRO. Se scegliete di farlo, i tempi di attrezzaggio e lavorazione vengono inviati a Labor Posting per ogni operazione dell’ordine, mentre le quantità completate vengono inviate a Job Receipts. Altrimenti, la manodopera continua a essere inserita in SYSPRO come prima.

5. Responsabilità sui dati e regole per i conflitti. Documentatele prima della messa in esercizio:

Affidate a un solo sistema la scrittura delle date degli ordini di produzione. SkyPlanner non richiede alcun modulo di schedulazione di SYSPRO e sostituisce quindi Factory Scheduling, Visual APS o APS (Nexsys) nella scrittura delle date pianificate. Se uno di questi moduli continua ad aggiornarle, disattivate questa funzione per gli ordini schedulati da SkyPlanner. In Factory Scheduling, l’opzione di Job Entry è “Update planned dates to scheduled dates.” (Aggiorna le date pianificate con le date schedulate.)

• Ordini _TMP. Le simulazioni di carico a capacità finita in Job Entry possono creare ordini _TMP in WipMaster. Escludeteli con un filtro a ogni lettura.
• Operazioni avviate. Forward Finite Scheduling genera errori per le operazioni già avviate che non trovano posto nella schedulazione. Prima di ogni esecuzione, importate in SkyPlanner l’avanzamento delle operazioni, in modo che la schedulazione tenga conto del lavoro già svolto. Running Time Lock blocca poi la schedulazione delle ore successive.
• Unità di tempo dei cicli di lavorazione. I tempi di attrezzaggio, lavorazione, coda e movimentazione richiedono ciascuno l’unità e la base di calcolo corrette. I tempi di coda e movimentazione sono tempi di attesa, non tempi macchina. Convertiteli durante l’importazione, altrimenti tutte le durate risulteranno errate.
• Lavorazioni esterne. Offsite Days e Dock to Stock Days rappresentano tempi trascorsi, non capacità produttiva interna. Modellateli come fasi con la sola durata.