Update specifiche progetto inventario
This commit is contained in:
Samuele Locatelli
+142
-3
@@ -6,24 +6,163 @@
|
||||
- [MP.INVENTORY](#mpinventory)
|
||||
- [Schema generale](#schema-generale)
|
||||
- [Funzionalita](#funzionalita)
|
||||
- [Use cases](#use-cases)
|
||||
- [Inventario oggetti (A): Noti, Univoci](#inventario-oggetti-a-noti-univoci)
|
||||
- [Inventario oggetti (B): Noti, non univoci](#inventario-oggetti-b-noti-non-univoci)
|
||||
- [Inventario oggetti (C): Non noti](#inventario-oggetti-c-non-noti)
|
||||
- [Pagine](#pagine)
|
||||
- [Document revision](#document-revision)
|
||||
- [Sessioni](#sessioni)
|
||||
- [Acquisizione](#acquisizione)
|
||||
- [Invio Inventari](#invio-inventari)
|
||||
- [Revisione Documento](#revisione-documento)
|
||||
|
||||
<div style="page-break-after: always; visibility: hidden"></div>
|
||||
|
||||
# Schema generale
|
||||
|
||||
Di seguito lo schema generale del pacchetto opzionale MP.INVENTORY
|
||||
|
||||
## Funzionalita
|
||||
|
||||
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 eprché 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)
|
||||
* eventualemtne 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)
|
||||
|
||||
Operativamente una volta letti questi codici i dati sono presentati all'operatore per conferma, no è prevista rettifica da parte dell'operatore.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
|
||||
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
|
||||
|
||||
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 compelta contestuale (con menù laterale)
|
||||
* possibilità di inserimento nuova sessione di inventario (con nome, descrizione, dataora avvio)
|
||||
* possibilità di chiudere le sessioni aperte di inventario (non rendendo possibile ulteriore aggiunta di letture/giacenze)
|
||||
|
||||
### Acquisizione
|
||||
|
||||
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 richeista
|
||||
* 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 MoonProIS del cliente (e quindi con logiche diverse per ogni caso).
|
||||
|
||||
La conferma dell'utente sarà encessaria, 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 aprte di EgalWare).
|
||||
|
||||
<div style="page-break-after: always; visibility: hidden"></div>
|
||||
|
||||
# Document revision
|
||||
# Revisione Documento
|
||||
|
||||
| Date | Edit | Version | Note |
|
||||
|------------|----------------|:-------:|-----------------:|
|
||||
| 2022.11.10 | S.E. Locatelli | 0.1 | Initial draft |
|
||||
|
||||
|
||||
Binary file not shown.
Reference in New Issue
Block a user