diff --git a/MP.INVENTORY/README.md b/MP.INVENTORY/README.md
index b85799a8..6af58510 100644
--- a/MP.INVENTORY/README.md
+++ b/MP.INVENTORY/README.md
@@ -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)
# 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).
-# Document revision
+# Revisione Documento
| Date | Edit | Version | Note |
|------------|----------------|:-------:|-----------------:|
| 2022.11.10 | S.E. Locatelli | 0.1 | Initial draft |
-
diff --git a/MP.INVENTORY/README.pdf b/MP.INVENTORY/README.pdf
index 7e51398b..dc8a34ff 100644
Binary files a/MP.INVENTORY/README.pdf and b/MP.INVENTORY/README.pdf differ