LinkMachine - Easy Industria 4.0

Buongiorno,

stiamo implementando una tabella eventi produzione (pezzo buono/scarto/setup/fermo) e poi dobbiamo “portare” i risultati in ERP.
Il timore: creare doppioni o incongruenze quando si rielabora (correzioni scarti, ritardi, ecc.).

Quale strategia usate per garantire che ERP riceva dati coerenti e “idempotenti”?

Ciao,

la parola chiave è: ID evento univoco.
Noi in ERP scriviamo movimenti che includono id_evento come chiave.
Se arriva lo stesso id_evento, ERP lo ignora (o fa UPSERT).
Così puoi reinviare senza paura (idempotenza).

Approccio “pulito”:

1) Produzione genera solo eventi immutabili (append-only).
2) ERP riceve movimenti collegati a id_evento.
3) Le correzioni non sovrascrivono: generano eventi di rettifica (es. SCARTO_RETTIFICA -1).

Questo mantiene audit e coerenza contabile.

Ok, quindi: mai “update” sugli eventi, solo nuovi eventi.

Domanda pratica: e se l’operatore registra 10 pezzi in blocco (fine turno)?
Meglio 10 eventi da 1 o 1 evento con quantita=10?

Noi facciamo 1 evento con quantita=10 (timestamp corretto).
Se vuoi tracciabilità fine (seriale/qualità per pezzo) allora eventi singoli.
Per KPI/contabilità spesso basta evento aggregato.

Regola utile:

- eventi “macro” con quantita (avanzamenti)
- eventi “micro” solo quando serve (pezzo critico / non conformità)

In ERP, tratta i macro-eventi come movimenti “a quantità”, non come seriali.

Ultimo dubbio: se cambia lotto/ordine, come evitate che “pezzi tardivi”
finiscano nel lotto sbagliato (es. la macchina continua 2 minuti)?

Noi obblighiamo CAMBIO_LOTTO solo a macchina ferma.
In più: se arrivano eventi con timestamp precedente, vanno al lotto precedente.
Serve un timestamp affidabile (macchina o gateway).

Confermo:

- CAMBIO_LOTTO ammesso solo in condizioni controllate (fermo / fine ciclo)
- report giornaliero che segnala eventi fuori sequenza (timestamp incoerenti)

Sono quelli che creano discrepanze a fine mese.