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

L’interfaccia di integrazione documentata di Monitor G5 è la Monitor ERP API v1. Combina CQRS e REST e utilizza JSON su HTTPS. (Monitor ERP API)

• Le query leggono i dati tramite GET. Accettano opzioni in stile OData: $filter, $select, $expand, $orderby, $top e $skip.
• I comandi scrivono i dati tramite POST, ad esempio Manufacturing/ManufacturingOrderOperations/Update.
• Batch esegue più comandi in un’unica transazione atomica tramite POST /api/v1/Batch: vengono applicati tutti oppure nessuno. Aggiungete /Simulate o /Validate per provare un batch e annullarne le modifiche. È il modo sicuro per scrivere un intero piano di schedulazione. (Batch)

L’URL di base è https://{host}:8001/{languageCode}/{companyNumber}/api/v1/. Il numero dell’azienda combina il numero del database e l’ID dell’azienda, ad esempio 004.1.

Per le licenze, Monitor precisa: “It is free to query and extract information from the API for all our customers. However, in order to use commands and write data to the ERP system, you need to purchase Monitor ERP API.” (Per tutti i clienti, interrogare l’API ed estrarre informazioni è gratuito. Per usare i comandi e scrivere dati nell’ERP occorre invece acquistare Monitor ERP API.) Prevedete la licenza di scrittura nel progetto fin dal primo giorno. (api.monitor.se)

La documentazione della Monitor ERP API non descrive webhook né sottoscrizioni a eventi. Le modifiche vengono rilevate tramite polling:

• Common/EntityChangeLogs (dalla versione 2.33) restituisce ChangeType (Update, Create, Delete), EntityTypeId, EntityId e ModifiedTimestamp. Interrogatelo ogni pochi minuti e recuperate solo i record modificati. (EntityChangeLog)
• Filtrate le query sugli ordini di produzione per includere solo quelli aperti e paginate i risultati con $top e $skip.

SkyPlanner invia webhook quando cambiano lo stato o il piano di schedulazione: la scrittura dei dati in Monitor è quindi guidata dagli eventi.

1. Caricamento iniziale delle anagrafiche. Leggete centri di lavoro, righe delle operazioni, righe delle operazioni alternative, righe dei materiali, articoli e calendari. Definite con cura la corrispondenza tra ogni centro di lavoro di Monitor e quello di SkyPlanner. Un centro di lavoro di tipo Pool diventa un gruppo di centri di lavoro; i centri che lo compongono diventano quelli tra cui il motore può scegliere.

2. Sincronizzazione degli ordini. Leggete gli ordini di produzione aperti con i relativi nodi, operazioni e materiali, oltre alle giacenze e 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 passa allo stato Delivered. Dopo il primo caricamento, Common/EntityChangeLogs determina gli aggiornamenti incrementali.

3. Scrittura del piano di schedulazione in Monitor. Per ogni operazione collocata o spostata dal motore, SkyPlanner invia ManufacturingOrderOperations/Update con PlannedStartDate e PlannedFinishDate. Se il motore ha spostato un’operazione su un’altra macchina del pool, viene eseguito prima SetWorkCenter. I comandi relativi a un ordine vengono inseriti in un unico Batch, così Monitor li accetta tutti oppure nessuno. Durante i test, eseguite il batch tramite /Validate.

Nelle versioni di Monitor precedenti alla 24.5, non è possibile scrivere le date pianificate tramite Update. Utilizzate invece ManufacturingOrders/ReplanOperation (disponibile dalla versione 2.40) con StartDate e FinishDate e impostate RestrictToOrderBounds in base alle vostre regole.

4. Dichiarazioni di avanzamento dal reparto. Mantenete un solo canale di consuntivazione:

• Monitor resta il canale di consuntivazione. Gli operatori continuano a registrare gli avanzamenti tramite Recording terminal o l’integrazione con le macchine, come avviene oggi. SkyPlanner legge ManufacturingOrderOperationReportings per rilevare l’avanzamento e rischedula la produzione.
• SkyPlanner diventa il canale di consuntivazione. Gli operatori registrano il lavoro con Mobile Confirmations o Production Timer e SkyPlanner invia ReportManufacturingOrderOperation a Monitor tramite POST.

Consuntivare in entrambi i sistemi duplica tempi e quantità.

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

La principale fonte di conflitti è la modifica del piano delle priorità da parte dei pianificatori. Rescheduling according to New finish e il trascinamento delle righe in Priority planning sovrascrivono le date scritte da SkyPlanner. Quando la sequenza è gestita da SkyPlanner, Priority planning diventa una vista di consultazione. Con Autopilot, SkyPlanner ricalcola automaticamente la schedulazione quando cambia la produzione.

• Fattore di disponibilità. Monitor usa il fattore di disponibilità per passare dalla capacità lorda a quella netta; per un nuovo centro di lavoro il valore predefinito è 80 %. Applicatelo una sola volta: come efficienza in SkyPlanner oppure riducendo la durata dei turni, mai in entrambi i modi.
• Precisione temporale. Nei centri di lavoro gestiti con Day planning, la capacità è espressa come tempo base giornaliero, senza gli orari dei turni. Mappa in SkyPlanner i turni effettivi a partire dai calendari di produzione, in modo che le lavorazioni siano collocate all’interno dell’orario di lavoro.
• Tempo di coda e sovrapposizione. Le righe delle operazioni contengono il tempo di coda e la sovrapposizione in %. Stabilisci come mapparli in SkyPlanner durante la definizione del perimetro, altrimenti i tempi di attraversamento cambieranno dopo la messa in produzione.
• Pool. I centri di lavoro raggruppati in pool vengono pianificati in Pool planning, non in Priority planning. Leggi i centri di lavoro che compongono il pool, non soltanto la riga del pool.
• Requisiti di versione. La gestione delle date pianificate tramite Update richiede la versione 24.5. I campi di capacità dei centri di lavoro nell’API richiedono la versione 24.3 e OIDC richiede la 25.8. Verifica la build prima della definizione del perimetro.
• Rete e certificato. L’installazione locale di Monitor espone l’API sulla porta 8001 con un certificato autofirmato. SkyPlanner funziona nel cloud: occorre quindi prevedere una regola del firewall o un relay e configurare esplicitamente il certificato come attendibile.
• Licenze. Ogni applicazione di terze parti che scrive dati deve disporre di propri utenti con licenza API. Ogni sistema include un utente API di sola lettura.