La funzionalità principale del sw è quella di effettuare l'inventario (periodico) del magazzino e di conseguenza produrre un "point in time state reference" sulle giacenze (ovvero la fotografia di uno stato magazzino valido in un dato istante temporale).

Questo perchè ovviamente un magazzino è un oggetto live in cui i vari oggetti entrano/escono in modo continuo e quindi le gacenze cambiano secondo la registrazione di ogni movimento ingresso/uscita materiale.

In generale l'approccio desiderato è quello di

aprire una sessione di inventario:
- definita da data-ora + nome
- il nome ad esempio indica di quale magazzino si stia facendo l'inventario (per differenziare ad esempio grezzi, semilavorati, finiti, ...)
permettere ad 1+ devices di lavorare sulla sessione di inventario
collezionare una serie di letture di barcode / QRCode
generare una situazione finale di stato magazzino acquisito

Le funzionalità cambiano a seconda del tipo di oggetto letto, poiché avremo

(A) codici univoci assoluti
- ad esempio sono i codici UDC generati da sistemi MAPO, dove ogni oggetto ha un codice univoco
- permette di determinare con precisione
- articolo
- lotto
- quantità
- ...
- è possibile discriminare l'operazione di lettura in modo assoluto (oggetto mai letto / oggetto già acquisito)
(B) codici NON univoci, verificabili da MAPO
- si tratta ad esempio di codici lotto generati esternamente
- lo stesso codice può essere associato a vari oggetti fisici (es un codice univoco di lotto materia prima, che è condiviso da n scatole recanti lo stesso identico codice)
- eventualmente esistono informazioni di tipo aggregato relative al codice che permettono di avere
  - quantità globale
  - numero colli globale
  - stato globale (es approvato/non approvato)
- esempio sono i lotti materia prima generati da un sistema ERP esterno quale ARCA (Edilchimica)
(C) codici NON verificabili da MAPO
- si tratta ad esempio di codici lotto generati esternamente
- questi valori NON sono verificabili su un database esterno (quindi non si sa se siano validi o meno)
- non è dato sapere se siano univoci (un codice distinto per ogni collo) oppure condivisi (stesso codice su più colli)

Use cases

I casi d'uso previsti sono i seguenti

Inventario oggetti (A): Noti, Univoci

In questo caso si tratta di ogetti tipo (A), con codici univoci e certi, che permettono di sapere univocamente

se il codice sia già stato acquisito o meno
i dati corretti associati al codice (quantità, lotto, articolo)
Verifiche varie di coerenza (già spediti, Lotto\Articolo NULL, Pezzi a 0)
Invio di tutti i dati come "Forzati" in quanto sicuramente corretti.

Operativamente una volta letti questi codici i dati sono presentati all'operatore per conferma, non è prevista rettifica da parte dell'operatore (prevedere eventualmente modifica di quantità opzionale).

Questo significa che è possibile avere in uscita liste di giacenza

certe/certificabili
complete
senza "errori di doppia lettura"
con allocazione certa di lotti/articoli
con verifica coerenza informazioni

Sono esempio di questo tipo di giacenze

i finiti con etichette generate da MAPO.MAG
i semilavorati con etichette generate da MAPO.MAG

Inventario oggetti (B): Noti, non univoci

In questo caso si tratta di ogetti tipo (B), con codici NON univoci ma verificabili, che permettono di sapere

i dati associati al codice (quantità totale, lotto, articolo, numero colli)

Però non è possibile sapere

la quantità effettiva per collo
se il codice sia stato acquisito più volte (per errore) o meno

Operativamente una volta letti questi codici dovrà svolgersi il seguente processo

verifica se il codice sia già stato letto e salvato in MAPO
verifica di eventuale quantità unitaria già confermata
in alternativa lettura da ERP del codice e riconoscimento, con proposta quantità/collo, articolo e lotto, poi salvata in MAPO
richiesta all'operatore di verifica che si tratti di prima lettura (per evitare doppie letture l'operatore dovrebbe marcare/siglare ogni collo con un simbolo/data/etichetta comprovante l'effettuata lettura inventario')
presentazione all'operatore dei dati per conferma OBBLIGATORIA ad ogni lettura
Salvataggio, in caso di modifica dei valori proposti la prima volta, della "Forzatura", previo controllo della presenza del lotto all'interno delle anagrafiche

Questo significa che è possibile avere in uscita liste di giacenza

con possibili "errori di doppia lettura"
con allocazione certa di lotti/articoli di quanto riconosciuto
con verifica coerenza informazioni dei codici riconosciuti

Sono esempio di questo tipo di giacenze

materie prime con etichette NON generate da MAPO.MAG
i semilavorati con etichette NON generate da MAPO.MAG
i finiti con etichette NON generate da MAPO.MAG

Inventario oggetti (C): Non noti

In questo caso si tratta di ogetti tipo (C), con codici ignoti e non verificabili. Questo significa che non è possibile sapere

i dati di base associati al codice (quantità totale, lotto, articolo, numero colli)
se il codice sia stato acquisito più volte (per errore) o meno

Operativamente una volta letti questi codici dovrà svolgersi il seguente processo

verifica se il codice sia già stato letto e salvato in MAPO
verifica di eventuale quantità unitaria già confermata
in alternativa proposta quantità/collo, articolo e lotto a partire dall'ultimo valore letto di tipo (C), salvataggio successivo in MAPO del codice + dati specifici
richiesta all'operatore di verifica che si tratti di prima lettura (per evitare doppie letture l'operatore dovrebbe marcare/siglare ogni collo con un simbolo/data/etichetta comprovante l'effettuata lettura inventario')
presentazione all'operatore dei dati per conferma OBBLIGATORIA ad ogni lettura
Salvataggio, in caso di modifica dei valori proposti la prima volta, della "Forzatura", previo controllo della presenza del lotto all'interno delle anagrafiche

Questo significa che è possibile avere in uscita liste di giacenza

con possibili "errori di doppia lettura"
SENZA informazione certa di lotti/articoli
SENZA verifica coerenza informazioni dei codici riconosciuti

Sono esempio di questo tipo di giacenze

etichette di fornitori esterni

Pagine

Sessioni Inventario

rif tab: InveSess

In questa pagina saranno visualizzate le sessioni di inventario, con le seguenti specifiche:

tabella record standard
filtro principale tra "in corso" e già chiuse
gestione filtri completa contestuale (con menù laterale)
possibilità di inserimento nuova sessione di inventario (con nome, descrizione, dataora avvio, magazzino)
possibilità di chiudere le sessioni aperte di inventario (non rendendo possibile ulteriore aggiunta di letture/giacenze)

Acquisizione

rif tab: InveScanData

La pagina di acquisizione è quella principale tramite smart device, e ha le seguenti caratteristiche

ottimizzata per smart-device / handheld device (es DataLogic Memor10, viewscreen da 320x480 pixels)
ottimizzata per input da barcode/qrcode continuo
con processo input simile ad altri applicativi (MP.MAG, CTRACK, GMW, ...)
con conferma button-based ove richiesta
con gestione colori esplicita (es green = OK, RED = error, YELLOW = richiesta conferma utente...)

il sistema dovrà processare ogni valore letto e nel minor tempo possibile capire quale caso d'uso sia in corso tra (A), (B) e (C) e di conseguenza proporre opzioni all'operatore

Invio Inventari

La pagina invio serve a prendere gli inventari acquisiti e inviarli al gestionale esterno tramite stored procedure ospitate sui db MoonPro_IS del cliente (e quindi con logiche diverse per ogni caso).

La conferma dell'utente sarà necessaria, da valutare se inserire uno stato inventario (in corso, chiuso, trasferito) per evitare doppio trasferimento e permettere un ri-trasferimento solo tramite sblocco admin da DB (=solo da parte di EgalWare).

Invio aggregato dei dati di

Magazzino (Codice Gestionale), Lotto, Articolo, quantità, Tipo Lettura (A,B,C), Flag Forzatura Lotto\Articolo

Revisione Documento

Date	Edit	Version	Note
2022.11.10	S.E. Locatelli	0.1	Initial draft
2022.11.10	Gian / Zac	0.2	Second draft
2022.11.16	Zac	0.3	Aggiunta condizione modifica previo controllo esistenza