diff --git a/README.md b/README.md index f567b02..b0ca069 100644 --- a/README.md +++ b/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) diff --git a/docs/specs/01_visione_prodotto.md b/docs/specs/01_visione_prodotto.md index bbea726..7e88e5f 100644 --- a/docs/specs/01_visione_prodotto.md +++ b/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. - diff --git a/docs/specs/03_modello_concettuale.md b/docs/specs/03_modello_concettuale.md index 87faf95..c73c1b6 100644 --- a/docs/specs/03_modello_concettuale.md +++ b/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. diff --git a/docs/specs/04_configurabilita_iniziale.md b/docs/specs/04_configurabilita_iniziale.md index 367bf6f..3ddf0d8 100644 --- a/docs/specs/04_configurabilita_iniziale.md +++ b/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. diff --git a/docs/specs/05_roadmap.md b/docs/specs/05_roadmap.md index 8073c78..2ce13f7 100644 --- a/docs/specs/05_roadmap.md +++ b/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. - diff --git a/docs/specs/06_wizard_installazione.md b/docs/specs/06_wizard_installazione.md new file mode 100644 index 0000000..d131a2e --- /dev/null +++ b/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. +