Definisci requisiti fondanti FlyWMS Core

This commit is contained in:
2026-06-30 16:51:37 +02:00
parent 3c97dbe313
commit a2520ff84c
6 changed files with 295 additions and 6 deletions

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.

View File

@@ -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.