Un venditore apre la schermata dei lotti, cerca un codice e mostra una riga con quantità disponibile e data di scadenza. La dimostrazione sembra convincente. Ma se domani l'azienda dovesse ricostruire dove è finita una partita, quella schermata basterebbe? La risposta dipende dai collegamenti con ricevimento, ubicazioni, trasformazioni e documenti di uscita. Un elenco di identificativi descrive lo stock corrente; la rintracciabilità richiede una storia interrogabile.

Per valutare un software gestionale, il comitato di scelta dovrebbe chiedere una prova che parta dai propri processi, con dati di esempio anonimizzati. La prova non serve ad attribuire un voto universale al prodotto. Serve a scoprire come il sistema conserva le relazioni e quali passaggi rimangono manuali. Il risultato è utile anche quando l'azienda non opera in un settore regolato: lotti e seriali possono servire per qualità, assistenza, garanzie o gestione di prodotti soggetti a scadenza. Obblighi specifici, invece, dipendono dalla filiera e vanno verificati con specialisti.

Preparare un campione che contenga un'eccezione

Un campione troppo semplice produce una demo facile da superare. Meglio preparare due articoli e tre partite con condizioni diverse. Per esempio: un lotto ricevuto in due consegne, un altro in verifica qualità e un terzo con data di scadenza diversa. Aggiungere un ordine parziale, un trasferimento tra sedi e un reso. Tutti i codici possono essere fittizi, ma le quantità devono essere coerenti e controllabili. Il fornitore dovrebbe ricevere il caso prima della demo, così può predisporre i dati nella configurazione effettivamente proposta, e il comitato può osservare quali adattamenti sono necessari.

Un esempio simulato: l'articolo A arriva in due lotti, L1 da 20 pezzi e L2 da 15. Di L1, 8 pezzi partono al cliente Alfa e 4 al cliente Beta; altri 3 passano a una seconda sede. Due pezzi tornano dal cliente Alfa, ma devono essere verificati prima di tornare disponibili. La prova non dovrebbe concludersi con “il saldo è 20”. Occorre distinguere i pezzi fisicamente presenti, quelli disponibili, quelli in reso e quelli già consegnati. Il codice del lotto è solo la chiave di ricerca.

Eseguire la ricerca a monte

Si scelga un'unità consegnata o un prodotto finito e si chieda da quale partita proviene. La ricerca dovrebbe mostrare il documento di origine, il fornitore, la data di ricezione e la quantità pertinente. Se il prodotto è stato trasformato, serve il legame con i lotti dei componenti. Se un lotto esterno viene rinominato internamente, deve rimanere visibile la corrispondenza. Non basta che un operatore sappia dove cercare un file allegato: il percorso di ricerca deve poter essere ripetuto da una persona autorizzata che non ha assistito alla ricezione.

La presenza di più fornitori o di codici simili è una prova utile. Due fornitori potrebbero usare lo stesso codice lotto per articoli diversi. Il sistema deve identificare la partita nel contesto corretto, senza confondere codici esterni, codici interni e documenti. Se la ricostruzione richiede una tabella manuale, il comitato dovrebbe registrare chi la mantiene, con quale controllo e come verrà cercata in futuro.

Eseguire la ricerca a valle

Partendo dal lotto ricevuto, si chieda dove siano finite tutte le unità: sedi, ordini, documenti di trasporto, clienti, eventuali trasformazioni, resi e quantità ancora presenti. In un caso con ordine parziale, un documento può contenere unità di più partite. Il report deve distinguere quante unità di ciascun lotto sono andate a ciascuna destinazione. Anche una rettifica o un annullamento devono avere una spiegazione visibile; cancellare il collegamento originale può rendere la ricerca apparentemente pulita ma incompleta.

La seconda ricerca non è solo l'inversa della prima. Può attraversare trasferimenti, prelievi, produzione e consegne successive. Perciò va chiesto quale sistema è la fonte autorevole se il software gestionale, WMS e software di produzione sono integrati. Se il WMS registra il prelievo effettivo ma il software gestionale conserva il lotto inizialmente proposto, il report a valle può essere errato pur mostrando un campo compilato. La demo dovrebbe includere una sostituzione del lotto in fase di picking e la sua propagazione al documento finale.

Quadrare quantità e stati

Una prova utile termina con una quadratura: quantità ricevute, trasformate, trasferite, consegnate, restituite, rettificate e residue. La somma deve essere spiegabile, tenendo presente che un trasferimento interno cambia ubicazione ma non quantità aziendale. Anche gli stati contano. Merce in quarantena o in attesa di verifica può essere fisicamente presente senza essere vendibile. Se un report somma tutto come disponibile, la ricerca non aiuta a prendere decisioni sicure.

Il comitato dovrebbe prendere nota delle eccezioni. Che cosa accade se una data è stata inserita male? Si vede il valore precedente? Chi autorizza la modifica? Un reso senza etichetta può essere posto in verifica senza attribuirgli un lotto arbitrario? Una rettifica di quantità conserva motivo e autore? Non ogni azienda richiede lo stesso workflow, ma ogni passaggio manuale rilevante va dichiarato e assegnato a una persona o a una procedura.

Ripetere la prova con ruoli diversi

La prima esecuzione può essere guidata dal consulente del fornitore. La seconda dovrebbe coinvolgere una persona del magazzino o della qualità che userà davvero il sistema, con i permessi previsti per il suo ruolo. Chiedere la stessa ricerca senza conoscere in anticipo il percorso mette in evidenza la qualità delle etichette, dei filtri e delle istruzioni. Se per ricostruire una destinazione servono privilegi amministrativi, occorre stabilire chi risponderà durante un'assenza o un'urgenza. Se invece tutti possono modificare scadenze e stati, il problema è opposto: una ricerca rapida su dati alterabili non è una prova solida.

Conviene annotare il tempo impiegato solo come dato del test, non come promessa di prestazione futura. Una demo con pochi record e un consulente esperto non rappresenta il lavoro quotidiano con migliaia di partite. Conta di più identificare gli ostacoli: codice non trovato, quantità discordante, passaggio a un secondo sistema, documento corretto che non compare. Il verbale dovrebbe distinguere errore del campione, limite del prodotto e configurazione ancora da completare. Senza questa distinzione, un intoppo può essere giudicato troppo severamente oppure liquidato come dettaglio irrilevante.

Valutare il risultato senza confondere funzione e conformità

La prova può essere valutata con cinque domande semplici. Primo: la ricerca identifica una partita senza ambiguità? Secondo: collega documenti e movimenti in entrambe le direzioni? Terzo: distingue quantità e stati? Quarto: conserva modifiche ed eccezioni? Quinto: produce un'esportazione che un responsabile può verificare fuori dalla demo? Accanto a ogni risposta conviene registrare ciò che funziona nella versione proposta, ciò che richiede configurazione, integrazione o sviluppo, e ciò che rimane manuale.

Un esito positivo non equivale a conformità normativa. In ambito alimentare, l'articolo 18 del Regolamento (CE) 178/2002 disciplina la rintracciabilità, ma l'adempimento concreto dipende anche da processi, responsabilità e documentazione. In altri settori valgono requisiti differenti. Il fornitore può mostrare capacità tecniche; la verifica degli obblighi applicabili resta un lavoro dell'impresa con i propri esperti.

La guida alla gestione di lotti e scadenze  di Gestionale sul Web, il software gestionale in cloud, approfondisce il flusso operativo dal ricevimento al prelievo. Per chi seleziona un software gestionale, il passaggio decisivo è trasformare quelle esigenze in una prova ripetibile. Quando il lotto attraversa un'eccezione e la sua storia rimane leggibile, il comitato ha un'evidenza più solida di una lista di funzionalità spuntate.