Definisci requisiti fondanti FlyWMS Core

README.md

@@ -16,6 +16,9 @@ Questo repository nasce come riprogettazione del prototipo `ware_house`, con l'o
 - Rendere configurabili gli aspetti che cambiano da cliente a cliente, senza costruire un sistema eccessivamente teorico.
 - Preparare un modello location compatibile con FlyWMS Mapper e con la futura mappatura tramite drone.
 - Integrare ERP esterni, inizialmente con forte attenzione a SQL Server e a scenari legacy.
+- Ridurre il client barcode a due operazioni elementari: prelievo e versamento, con il contesto gestito dal sistema.
+- Rendere visibili nel WMS le unita' di carico fin dal momento in cui nascono nell'ERP.
+- Guidare l'installazione con un wizard che costruisce configurazione, magazzini, celle, location virtuali e parametri operativi.
 
 ## Documentazione iniziale
 
@@ -24,4 +27,4 @@ Questo repository nasce come riprogettazione del prototipo `ware_house`, con l'o
 - [Modello concettuale iniziale](docs/specs/03_modello_concettuale.md)
 - [Configurabilita' iniziale](docs/specs/04_configurabilita_iniziale.md)
 - [Roadmap pragmatica](docs/specs/05_roadmap.md)
-
+- [Wizard di installazione](docs/specs/06_wizard_installazione.md)

docs/specs/01_visione_prodotto.md

@@ -28,7 +28,48 @@ Questo consente di distinguere:
 - UDC spedite;
 - anomalie rilevate da operatori o da FlyWMS Mapper.
 
+## Requisiti fondanti rispetto al prototipo ware_house
+
+### Barcode essenziale
+
+Il client barcode deve permettere il minor numero possibile di azioni esplicite.
+
+La teoria operativa iniziale e':
+
+- prelievo;
+- versamento.
+
+Carico, scarico, picking, spedizione, riallocazione e presa in carico sono interpretazioni di contesto intorno a queste due operazioni elementari.
+
+Il barcode non deve chiedere all'operatore di ragionare sul modello dati. Deve guidarlo con messaggi minimi e stati chiari.
+
+### UDC visibili dalla nascita ERP
+
+Una unita' di carico deve essere visibile in FlyWMS Core dal momento in cui nasce nell'ERP, anche se non e' ancora stata letta o movimentata in magazzino.
+
+Se l'ERP dichiara una UDC prodotta, FlyWMS Core deve poterla mostrare come disponibile in una location virtuale iniziale, normalmente:
+
+- NON_SHELVED;
+- "Non scaff.";
+- barcode convenzionale configurabile, ad esempio 9001000.
+
+Questo supera il limite legacy in cui una UDC entra nel WMS solo alla prima lettura barcode o alla prima registrazione in una tabella movimenti.
+
+### Installazione configurabile
+
+FlyWMS Core deve essere installabile in aziende diverse mediante un wizard guidato.
+
+Il wizard deve raccogliere le risposte operative del cliente e generare:
+
+- configurazione applicativa;
+- struttura magazzini;
+- struttura location;
+- tipologie UDC;
+- location virtuali;
+- regole minime di movimento;
+- mappature ERP;
+- tabelle e dati iniziali necessari.
+
 ## Obiettivo commerciale
 
 FlyWMS Core deve essere anche un prodotto-vetrina: abbastanza concreto da dimostrare valore operativo, abbastanza configurabile da adattarsi a piu' clienti, abbastanza semplice da poter essere realmente completato e mantenuto.
-

docs/specs/03_modello_concettuale.md

@@ -33,6 +33,10 @@ Attributi iniziali:
 - 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.
@@ -60,15 +64,20 @@ Tipi iniziali:
 
 Le location virtuali sostituiscono i codici convenzionali legacy.
 
-Esempi:
+Location virtuali obbligatorie nella prima versione:
 
 - NON_SHELVED;
-- SHIPPED;
+- 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.
@@ -85,6 +94,19 @@ Campi concettuali:
 - origine del movimento;
 - transazione.
 
+Il movimento deve essere espresso sempre come trasferimento:
+
+```text
+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.
@@ -102,3 +124,20 @@ Puo' essere calcolata dai movimenti oppure mantenuta come tabella aggiornata per
 - 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.

docs/specs/04_configurabilita_iniziale.md

@@ -9,6 +9,15 @@ L'obiettivo non e' creare subito un motore universale, ma rendere configurabili
 - connessione ERP;
 - mappatura campi ERP verso FlyWMS;
 - tipi di unita' logistica;
+- struttura del contenuto UDC;
+- peso, dimensioni, volume e unita' di misura;
+- numero di magazzini;
+- struttura fisica dei magazzini;
+- numero scaffali;
+- numero campate;
+- numero livelli;
+- numero celle per campata/livello;
+- dimensioni scaffali e celle;
 - location virtuali;
 - codici barcode convenzionali;
 - regole base di movimento;
@@ -34,3 +43,21 @@ Ogni configurazione deve risolvere un caso reale.
 
 Se una configurazione non ha ancora un caso reale, va documentata come possibilita' futura ma non implementata subito.
 
+## Configurazione tramite wizard
+
+La configurazione iniziale non deve essere solo un file tecnico.
+
+Deve esistere un wizard di installazione che ponga domande consequenziali e generi la configurazione iniziale.
+
+Il wizard deve consentire almeno:
+
+- definizione magazzini;
+- definizione struttura scaffali;
+- definizione celle;
+- definizione location virtuali;
+- definizione tipi UDC;
+- definizione mappatura ERP;
+- definizione soglie operative;
+- generazione tabelle o dati iniziali.
+
+La logica di generazione deve essere ripetibile e versionata, cosi' da poter ricostruire una installazione o migrare un cliente.

docs/specs/05_roadmap.md

@@ -14,6 +14,8 @@
 - definire layer servizi;
 - definire API interne;
 - creare configurazione connessione ERP/WMS;
+- progettare wizard installazione;
+- progettare generazione struttura magazzino;
 - creare logging e audit robusti;
 - creare struttura test.
 
@@ -24,7 +26,7 @@
 - movimenti UDC;
 - giacenza corrente;
 - storico movimenti;
-- client barcode minimale;
+- client barcode minimale basato su prelievo e versamento;
 - picking list base.
 
 ## Fase 3 - Integrazione ERP
@@ -35,6 +37,16 @@
 - stato UDC prodotta ma non presa in carico;
 - dashboard UDC da stoccare.
 
+## Fase 3.bis - Wizard cliente
+
+- flusso domande installazione;
+- generazione magazzini;
+- generazione scaffali/celle;
+- generazione location virtuali;
+- generazione tipi UDC;
+- validazione configurazione;
+- esportazione/importazione configurazione.
+
 ## Fase 4 - Collegamento Mapper
 
 - modello coordinate location;
@@ -51,4 +63,3 @@
 - scenario picking;
 - scenario mappa/drone simulata;
 - documentazione commerciale e tecnica.
-

docs/specs/06_wizard_installazione.md

@@ -0,0 +1,168 @@
+# Wizard di installazione
+
+Il wizard di installazione e' un requisito fondante di FlyWMS Core.
+
+Lo scopo e' trasformare il prodotto da applicazione rigida a pacchetto installabile in aziende diverse.
+
+Il wizard deve raccogliere informazioni operative e generare una configurazione coerente.
+
+## Principi
+
+- Il wizard deve porre domande consequenziali.
+- Ogni risposta deve influenzare solo le domande successive rilevanti.
+- La configurazione generata deve essere salvabile, esportabile e versionata.
+- La generazione del database deve essere ripetibile.
+- Le tabelle di sistema non devono essere create in modo casuale, ma tramite migrazioni o generatori controllati.
+
+## Flusso iniziale proposto
+
+### 1. Identita' installazione
+
+Domande:
+
+- nome azienda;
+- nome sito;
+- lingua principale;
+- timezone;
+- database target;
+- ambiente: test, produzione, demo.
+
+Output:
+
+- configurazione installazione;
+- prefissi e label principali.
+
+### 2. Connessione ERP
+
+Domande:
+
+- ERP presente;
+- tipo database ERP;
+- connessione;
+- schema/database sorgente;
+- vista o query UDC prodotte;
+- vista o query articoli;
+- vista o query lotti;
+- vista o query documenti/picking.
+
+Output:
+
+- connettore ERP;
+- mappatura iniziale campi;
+- query di test.
+
+### 3. Unita' di carico
+
+Domande:
+
+- quali tipi di UDC esistono;
+- il contenuto e' mono-articolo o multi-articolo;
+- il contenuto e' mono-lotto o multi-lotto;
+- peso e dimensioni arrivano dall'ERP o sono calcolati;
+- barcode UDC e' generato dall'ERP o da FlyWMS;
+- quali attributi sono obbligatori.
+
+Output:
+
+- tipi UDC;
+- schema contenuto;
+- regole di validazione;
+- mapping ERP verso LogisticUnit e LogisticUnitContent.
+
+### 4. Location virtuali
+
+Location obbligatorie:
+
+- NON_SHELVED;
+- SHIPPED.
+
+Domande:
+
+- label utente;
+- barcode convenzionale;
+- significato operativo;
+- visibilita' nelle dashboard;
+- uso nei movimenti barcode.
+
+Output:
+
+- location virtuali iniziali;
+- codici convenzionali;
+- regole di movimento base.
+
+### 5. Struttura magazzino
+
+Domande:
+
+- numero magazzini;
+- per ogni magazzino: nome, codice, descrizione;
+- numero aree;
+- numero scaffali;
+- numero corsie;
+- numero campate;
+- numero livelli;
+- numero celle per campata/livello;
+- dimensioni fisiche;
+- capacita' stimata;
+- barcode location.
+
+Output:
+
+- gerarchia location;
+- celle generate;
+- codici location;
+- dati utili a FlyWMS Mapper.
+
+### 6. Barcode e terminali
+
+Domande:
+
+- risoluzione terminale;
+- input con enter automatico;
+- tasti funzione disponibili;
+- modalita' RDP o locale;
+- operazioni abilitate.
+
+Regola iniziale:
+
+Il barcode espone due operazioni elementari:
+
+- prelievo;
+- versamento.
+
+Il contesto applicativo decide se l'operazione vale come carico, scarico, picking o spedizione.
+
+### 7. Regole operative
+
+Domande:
+
+- soglia UDC non scaffalate;
+- soglia UDC prodotte ma non prese in carico;
+- autorizzazioni operatori;
+- blocchi su incongruenze;
+- movimenti consentiti;
+- audit obbligatorio.
+
+Output:
+
+- regole base;
+- messaggi utente;
+- controlli runtime.
+
+## Output tecnico del wizard
+
+Il wizard deve generare:
+
+- file configurazione installazione;
+- script/migrazioni database;
+- dati iniziali;
+- mapping ERP;
+- eventuali viste di staging;
+- report riepilogo installazione.
+
+## Nota architetturale
+
+La configurazione non deve generare codice applicativo diverso per ogni cliente.
+
+Deve generare dati e parametri usati da un motore applicativo comune.
+