Milestone ultima alpha
This commit is contained in:
170
spec_barcode_wms_aggiornata.rtf
Normal file
170
spec_barcode_wms_aggiornata.rtf
Normal file
@@ -0,0 +1,170 @@
|
||||
{\rtf1\ansi\deff0
|
||||
{\fonttbl
|
||||
{\f0 Segoe UI;}
|
||||
{\f1 Consolas;}
|
||||
}
|
||||
\fs24
|
||||
\pard\b\f0\fs32 Specifica Form Barcode WMS\par
|
||||
\pard\b0\fs22 Documento di lavoro aggiornato per replica Python del client barcode C# con miglioramenti di usabilita'.\par
|
||||
\par
|
||||
\pard\b 1. Obiettivo operativo\par
|
||||
\pard\b0 La form barcode guida il magazziniere in movimenti WMS di due tipi:\par
|
||||
\pard\li360 - prelievo verso la cella virtuale 9000000\par
|
||||
\pard\li360 - versamento verso una cella reale di magazzino\par
|
||||
\pard\li0 Entrambe le operazioni usano lo stesso motore di movimento DB; cambia la destinazione operativa.\par
|
||||
\par
|
||||
\pard\b 2. Code F1 / F2\par
|
||||
\pard\b0 Il comportamento reale ricostruito e confermato e' il seguente:\par
|
||||
\pard\li360 - F1 = coda ad alta priorita', cioe' picking list prenotata (IDStato = 1)\par
|
||||
\pard\li360 - F2 = coda a bassa priorita', cioe' coda non prenotata (IDStato = 0)\par
|
||||
\pard\li0 Dall'interfaccia backoffice si puo' prenotare una sola picking list per volta. La lista prenotata entra in F1; la seconda coda operativa viene proposta con F2.\par
|
||||
\par
|
||||
\pard\b 3. File C# analizzati\par
|
||||
\pard\b0\li360 - FSkMovimenti.cs\par
|
||||
\pard\li360 - FSkAccettazione.cs\par
|
||||
\pard\li360 - FRMagViewLayout.cs\par
|
||||
\pard\li360 - GridViewColumnButtonMenu.cs\par
|
||||
\pard\li360 - script.sql\par
|
||||
\par
|
||||
\pard\b 4. Comandi principali della form C#\par
|
||||
\pard\b0\li360 - F1 / H Priority: imposta iStatoPkPallet = 1 e carica la prossima riga da XMag_ViewPackingList con IDStato = 1\par
|
||||
\pard\li360 - F2 / L Priority: imposta iStatoPkPallet = 0 e carica la prossima riga da XMag_ViewPackingList con IDStato = 0\par
|
||||
\pard\li360 - Enter / Salva: esegue il movimento quando i campi sono completi\par
|
||||
\pard\li360 - F4 / Elimina: forza uno scarico verso 9000000\par
|
||||
\par
|
||||
\pard\b 5. Significato reale dei campi nella form legacy\par
|
||||
\pard\b0 La UI C# e' poco intuitiva perche' i nomi dei campi non spiegano il flusso.\par
|
||||
\pard\li360 - txtDocRif\par
|
||||
\pard\li720 etichetta visibile: Pallet\par
|
||||
\pard\li720 significato reale: barcode del pallet letto o da confermare\par
|
||||
\pard\li360 - txtBarcode\par
|
||||
\pard\li720 etichetta visibile: Cella\par
|
||||
\pard\li720 significato reale: destinazione operativa; nel picking viene impostata a 9000000\par
|
||||
\pard\li360 - lblTesto1\par
|
||||
\pard\li720 e' il vero indicatore di stato; viene usato anche come barra colorata\par
|
||||
\pard\li360 - lblTesto2\par
|
||||
\pard\li720 Documento nella fase di proposta picking; riga informativa variabile nella fase di conferma\par
|
||||
\pard\li360 - lblTesto3\par
|
||||
\pard\li720 cliente / nazione nella fase di proposta picking; riga informativa variabile nella fase di conferma\par
|
||||
\pard\li360 - lblTesto4\par
|
||||
\pard\li720 pallet atteso nella fase di proposta picking; riga informativa variabile nella fase di conferma\par
|
||||
\par
|
||||
\pard\b 6. Query principale F1 / F2\par
|
||||
\pard\b0 Metodo chiave nel C#: \f1 GetDatiPallet("", "", idStato)\f0\par
|
||||
\pard\li360 Query:\par
|
||||
\pard\li720\f1 SELECT TOP 1 * FROM XMag_ViewPackingList WHERE Ordinamento > 0 AND IDStato = {idStato} ORDER BY Ordinamento\f0\par
|
||||
\pard\li0 Effetto reale:\par
|
||||
\pard\li360 1. viene scelta la prossima UDC della coda selezionata\par
|
||||
\pard\li360 2. vengono riempiti i label con ubicazione, documento, cliente e pallet atteso\par
|
||||
\pard\li360 3. il campo Cella viene impostato a 9000000\par
|
||||
\pard\li360 4. l'operatore legge il pallet nel campo Pallet\par
|
||||
\pard\li360 5. se il pallet coincide con quello atteso, viene eseguito il prelievo\par
|
||||
\par
|
||||
\pard\b 7. Reset dei campi e barra rossa / verde\par
|
||||
\pard\b0 Ricostruzione aggiornata dal C#:\par
|
||||
\pard\li360 - non emerge un pulsante esplicito che entri formalmente in una "modalita' versamento"\par
|
||||
\pard\li360 - i reset vengono fatti in modo automatico dentro \f1 GetDatiPallet(...)\f0\ e \f1 GetDatiPalletLotto(...)\f0\par
|
||||
\pard\li360 - all'inizio di questi metodi il C# pulisce i label, azzera \f1 txtDocRif\f0\ e imposta \f1 lblTesto1.BackColor = Red\f0\par
|
||||
\pard\li360 - quando il dato viene trovato correttamente, \f1 lblTesto1\f0\ passa a \f1 LightGreen\f0\ o \f1 GreenYellow\f0\par
|
||||
\pard\li0 Quindi la "barra rossa / verde" ricordata dall'operatore coincide con \f1 lblTesto1\f0, non con un controllo separato.\par
|
||||
\par
|
||||
\pard\b 8. Validazione dello scan\par
|
||||
\pard\b0 Metodo chiave: \f1 SalvaOk()\f0\par
|
||||
\pard\li360 - se \f1 txtBarcode = 9000000\f0, il pallet letto in \f1 txtDocRif\f0\ deve coincidere con \f1 lblTesto4\f0\par
|
||||
\pard\li360 - se non coincide: errore \f1 Errata Lettura\f0\ e blocco operazione\par
|
||||
\pard\li360 - se coincide: chiamata a \f1 Ricevi(...)\f0\par
|
||||
\pard\li0 Questa e' la protezione che impedisce di scaricare il pallet sbagliato durante il picking.\par
|
||||
\par
|
||||
\pard\b 9. Esecuzione del movimento\par
|
||||
\pard\b0 Metodi chiave nel C#:\par
|
||||
\pard\li360 - \f1 Ricevi(...)\f0\par
|
||||
\pard\li360 - \f1 spt_SaveStoredProcedure(...)\f0\par
|
||||
\pard\li0 Stored procedure usata:\par
|
||||
\pard\li360\f1 sp_xMagGestioneMagazziniPallet\f0\par
|
||||
\pard\li0 Parametri principali:\par
|
||||
\pard\li360 - IDOperatore\par
|
||||
\pard\li360 - BarcodeCella\par
|
||||
\pard\li360 - BarcodePallet\par
|
||||
\pard\li360 - NumeroCella\par
|
||||
\pard\li0 Dopo il movimento il C# richiama ancora \f1 GetDatiPallet(sBarcodePallet, sBarcodeCella, iStatoPkPallet)\f0.\par
|
||||
\pard\li0 I messaggi di conferma vengono quindi scritti a valle della transazione DB, non prima.\par
|
||||
\par
|
||||
\pard\b 10. Convenzioni logistiche emerse dalla verifica sul campo\par
|
||||
\pard\b0 La verifica con il magazziniere ha chiarito il significato delle celle convenzionali usate dai fallback del sistema.\par
|
||||
\pard\li360 - 9000000 = destinazione logica di input usata dalla form per il prelievo\par
|
||||
\pard\li360 - 9999 = locazione convenzionale 7G.1.1\par
|
||||
\pard\li360 - 1000 = locazione convenzionale 5E1.1\par
|
||||
\pard\li0 Questo significa che:\par
|
||||
\pard\li360 - una UDC prelevata dalla picking list finisce logicamente verso 9000000, ma viene poi rappresentata operativamente come 7G.1.1\par
|
||||
\pard\li360 - una UDC non scaffalata nella picking list viene proposta con la locazione convenzionale 5E1.1\par
|
||||
\pard\li0 I fallback che sembravano "sporchi" nel codice sono quindi parte della semantica reale del magazzino.\par
|
||||
\par
|
||||
\pard\b 11. Comportamento osservato nel prelievo picking list\par
|
||||
\pard\b0 Flusso operativo confermato:\par
|
||||
\pard\li360 1. il magazziniere preme F1 o F2\par
|
||||
\pard\li360 2. il barcode mostra la prossima UDC della coda scelta con la sua locazione\par
|
||||
\pard\li360 3. l'operatore legge il pallet atteso\par
|
||||
\pard\li360 4. il movimento parte verso la destinazione logica 9000000\par
|
||||
\pard\li360 5. alla conferma compare \f1 Ok Scarico\f0\ nella prima label\par
|
||||
\pard\li360 6. compare \f1 7G.1.1\f0\ come locazione convenzionale di spedito\par
|
||||
\pard\li360 7. dopo il tempo della logica lato server viene proposta la UDC successiva\par
|
||||
\pard\li0 Questo comportamento percepito dall'operatore e' compatibile con il fatto che le label vengano aggiornate dopo il ritorno della stored.\par
|
||||
\par
|
||||
\pard\b 12. Caso UDC non scaffalata\par
|
||||
\pard\b0 Nella vista SQL la UDC non scaffalata usa un fallback tecnico, ma per l'operatore la locazione visibile e significativa e':\par
|
||||
\pard\li360 - 5E1.1\par
|
||||
\pard\li0 Quindi il client Python non deve mostrare soltanto la stringa tecnica `Non scaff.`, ma deve privilegiare la convenzione operativa 5E1.1 dove il legacy la rende significativa.\par
|
||||
\par
|
||||
\pard\b 13. Legame con la prenotazione della picking list\par
|
||||
\pard\b0 La prenotazione backoffice chiama:\par
|
||||
\pard\li360\f1 sp_xExePackingListPallet\f0\par
|
||||
\pard\li0 Effetto DB:\par
|
||||
\pard\li360 - mette \f1 Celle.IDStato = 1\f0\ sulle celle del documento prenotato\par
|
||||
\pard\li360 - se richiamata di nuovo, riporta \f1 IDStato = 0\f0\par
|
||||
\pard\li360 - scrive il documento in \f1 LogPackingList\f0\par
|
||||
\pard\li0 Dopo ogni prelievo, \f1 sp_xMagGestioneMagazziniPallet\f0\ richiama:\par
|
||||
\pard\li360\f1 sp_ControllaPrenotazionePackingListPalletNew\f0\par
|
||||
\pard\li0 Questa procedura ri-prenota automaticamente le celle residue della picking list attiva.\par
|
||||
\pard\li0 Quindi:\par
|
||||
\pard\li360 - F1 continua a scorrere la picking list prenotata residua\par
|
||||
\pard\li360 - F2 continua a scorrere la coda non prenotata\par
|
||||
\par
|
||||
\pard\b 14. Tempi percepiti dall'operatore\par
|
||||
\pard\b0 Nel C# non emerge un vero timer di reset a 2 secondi. Il ritardo percepito dal magazziniere e' piu' coerente con:\par
|
||||
\pard\li360 - tempo di transazione DB\par
|
||||
\pard\li360 - tempo di riesecuzione della logica server\par
|
||||
\pard\li360 - tempo di riaggancio alla UDC successiva\par
|
||||
\pard\li0 Quindi il "reset" percepito e' in realta' la finestra temporale durante cui il terminale attende l'esito e poi aggiorna le label.\par
|
||||
\par
|
||||
\pard\b 15. Allineamento richiesto nel client Python\par
|
||||
\pard\b0 Da mantenere uguale al C# e alla prassi operativa:\par
|
||||
\pard\li360 - una sola picking list prenotata per volta\par
|
||||
\pard\li360 - F1 legge IDStato = 1\par
|
||||
\pard\li360 - F2 legge IDStato = 0\par
|
||||
\pard\li360 - proposta UDC ordinata da DB\par
|
||||
\pard\li360 - movimento tramite la stessa stored legacy \f1 sp_xMagGestioneMagazziniPallet\f0\par
|
||||
\pard\li360 - validazione del pallet atteso prima del prelievo verso 9000000\par
|
||||
\pard\li360 - visualizzazione di 7G.1.1 come locazione convenzionale di spedito\par
|
||||
\pard\li360 - visualizzazione di 5E1.1 per le UDC non scaffalate\par
|
||||
\par
|
||||
\pard\b 16. Criticita' di usabilita' della form legacy\par
|
||||
\pard\b0\li360 - etichette fuorvianti: Cella e Pallet non spiegano cosa va letto in quel momento\par
|
||||
\pard\li360 - il valore 9000000 compare senza contesto esplicito\par
|
||||
\pard\li360 - non e' chiaro visivamente se si sta lavorando in F1 o in F2\par
|
||||
\pard\li360 - la validazione contro il pallet atteso non e' evidente a schermo\par
|
||||
\pard\li360 - il flusso dipende da reset e colori impliciti, quindi richiede addestramento\par
|
||||
\par
|
||||
\pard\b 17. Specifica proposta per il nuovo client Python barcode\par
|
||||
\pard\b0 Replica funzionale fedele, ma con UI piu' guidata.\par
|
||||
\pard\li360 - una sola finestra tkinter pura\par
|
||||
\pard\li360 - service layer separato dalla UI\par
|
||||
\pard\li360 - repository layer separato dall'accesso SQL\par
|
||||
\pard\li360 - focus sempre sul campo scansione corretto\par
|
||||
\pard\li360 - stato visivo chiaro: F1, F2, versamento, conferma\par
|
||||
\pard\li360 - messaggi espliciti per l'operatore: cosa leggere adesso\par
|
||||
\pard\li360 - barra stato grande con colori coerenti al legacy\par
|
||||
\pard\li360 - gestione esplicita delle locazioni convenzionali 5E1.1 e 7G.1.1\par
|
||||
\par
|
||||
\pard\b 18. Conclusione\par
|
||||
\pard\b0 Il comportamento C# della form barcode e' abbastanza chiaro: e' piu' coerente di quanto sembri, ma e' esposto con una UI poco autoesplicativa. Il client Python deve quindi mantenere la semantica legacy lato DB e coda operativa, ma renderla finalmente leggibile e stabile per l'operatore.\par
|
||||
}
|
||||
Reference in New Issue
Block a user