3.7 KiB
Modello concettuale iniziale
Il modello deve essere abbastanza generale da non ripetere i limiti del legacy, ma non cosi' astratto da bloccare lo sviluppo.
Entita' principali
Convenzione audit comune
Tutte le tabelle persistenti di dominio devono avere un blocco audit standard.
Campi minimi:
- created_by;
- created_at;
- updated_by;
- updated_at;
- deleted_by;
- deleted_at.
Questa forma e' volutamente esplicita per rendere semplice interrogare il database anche senza passare dall'applicazione.
Le cancellazioni fisiche devono essere evitate nelle tabelle operative. La regola di default e' il soft delete:
deleted_at valorizzato = record cancellato logicamente
deleted_at nullo = record attivo
Per tabelle molto semplici o di sistema si puo' valutare una convenzione piu' compatta, ma il default del progetto resta il blocco audit esplicito.
Quando serve ricostruire la sequenza completa degli eventi, il blocco audit della riga non basta. In questi casi si usa anche AuditEvent, che registra azione, utente, timestamp, origine, valori prima/dopo e riferimento alla transazione.
LogisticUnit
Rappresenta una qualsiasi unita' fisica movimentabile.
Esempi:
- pallet;
- cassa;
- cartone;
- bobina;
- contenitore;
- roll;
- collo;
- unita' specifica del cliente.
Attributi iniziali:
- codice barcode;
- tipo unita';
- stato logico;
- peso lordo;
- peso netto;
- tara;
- dimensioni;
- volume;
- data creazione;
- origine dati;
- riferimento ERP.
Una LogisticUnit puo' esistere in FlyWMS Core anche prima del primo movimento fisico registrato nel WMS.
In questo caso la sua origine e' ERP e la sua posizione iniziale e' una location virtuale di ingresso, normalmente NON_SHELVED.
LogisticUnitContent
Descrive il contenuto di una unita' logistica.
Serve per gestire:
- una UDC con un solo lotto;
- una UDC con piu' lotti;
- una UDC con piu' articoli;
- quantita' parziali.
Location
Rappresenta una posizione logica o fisica.
Tipi iniziali:
- magazzino;
- area;
- corsia;
- scaffale;
- livello;
- cella;
- location virtuale.
Le location virtuali sostituiscono i codici convenzionali legacy.
Location virtuali obbligatorie nella prima versione:
- NON_SHELVED;
- SHIPPED.
Location virtuali opzionali o future:
- RECEIVING;
- QUALITY_HOLD;
- DAMAGED;
- STAGING.
Ogni location virtuale deve avere codice interno, label utente e, se necessario, barcode convenzionale configurabile.
InventoryMovement
Registra ogni movimento.
Campi concettuali:
- unita' logistica;
- location sorgente;
- location destinazione;
- operatore;
- timestamp;
- causale;
- documento sorgente;
- origine del movimento;
- transazione.
Il movimento deve essere espresso sempre come trasferimento:
from_location -> to_location
Le due operazioni elementari esposte al barcode sono:
- prelievo: rimozione da una location sorgente;
- versamento: inserimento in una location destinazione.
Nel modello applicativo un'azione operativa puo' combinare prelievo e versamento in una sola transazione.
CurrentInventory
Rappresenta la giacenza corrente materializzata.
Puo' essere calcolata dai movimenti oppure mantenuta come tabella aggiornata per performance.
Stati logici iniziali
- PRODUCED_BY_ERP;
- RECEIVED;
- NON_SHELVED;
- SHELVED;
- RESERVED_FOR_PICKING;
- SHIPPED;
- BLOCKED;
- UNKNOWN.
Relazione con ERP
Il modello deve prevedere una fonte ERP per le LogisticUnit.
Il primo obiettivo non e' importare tutto l'ERP, ma creare una vista o tabella di staging che dica:
- codice UDC;
- data creazione;
- articolo o articoli;
- lotto o lotti;
- quantita';
- peso;
- dimensioni;
- documento o contesto di origine;
- stato ERP rilevante.
Le UDC presenti nello staging ERP ma non ancora movimentate nel WMS devono risultare in CurrentInventory come NON_SHELVED logiche.