| Article Index |
|---|
| Parliamo di EDI - Electronic Data Interchange - Parte I |
| Transcodifica dei PdV |
L'autore ha collaborato nel corso di numerosi anni al progetto di sistemi per il processo EDI per la maggior catena di vendita di Ottica e Lenti del panorama italiano, occupandosi in particolare del progetto del software di processo.
Parlare di EDI oggi non significa certamente trattare un argomento nuovo, al contrario. E tuttavia ci sono degli aspetti del problema che per la loro criticità meritano alcune riflessioni di approfondimento.
Alcuni di questi fattori, in base alla nostra esperienza maturata nel corso degli anni, sono spesso sottovalutati nell'impianto di un progettto EDI, e contribuiscono ad aumentarne le voci di rischio. Se non affrontati e risolti nel modo corretto, questi problemi si fossilizzano nel sistema una volta a regime, determinando costi nascosti, di entità non sempre trascurabile.
Con il termine EDI, acronimo di Electronic Data Interchange, si intende lo scambio, in modalità strutturata e controllata, di dati tra organizzazioni, utilizzando canali di comunicazione elettronici. In questo modo vengono scambiati, con modalità più o meno automatizzata, i vari documenti indispensabili per l'interazione commerciale tra due aziende: Ordine, Conferme d'Ordine, Avvisi di Ricevimento e Fatture.
Una volta a regime, il flusso EDI rappresenta una componente basilare del sistema Supply Chain con i fornitori e/o con i clienti per molte, se non tutte, le aziende odierne con le problematiche tipiche della grande distribuzione o comunque di una rete di vendita estesa.
Fra i molteplici aspetti da considerare nel progetto di un sistema EDI, vorrei mettere in evidenza i seguenti, come già detto spesso sottovalutati:
- Il problema della trans-codifica (mapping) dei codici articolo e dei codici dei punti vendita / magazzino tra cliente e fornitore
- Trattamento degli errori dei dati all'interno dei documenti EDI
La transcodifica dei codici articolo
Supponendo di identificare con C l'azienda cliente, e con F uno dei suoi fornitori, per ogni dato articolo venduto da F a C, i codici identificativi assegnati nelle due rispettive anagrafiche, salvo eccezioni del tutto particolari, non corrisponderanno. Ciò implica la necessità di sostituire all'interno dei vari documenti EDI tutti i riferimenti ad un articolo da un codice all'altro, e viceversa. E la tabella di transcodifica da utilizzare dipende ovviamente dal particolare fornitore (o cliente) cui è indirizzato (o da cui proviene) il documento.
Se da un lato è vero che le codifiche standard, tipo UPC o EAN possono venire in aiuto, anche in modo sostanziale, dall'altro è un fatto che la loro adozione non è ancora generalizzata nel panorama delle aziende, almeno al di fuori del circuito della grande distribuzione.
A complicare le cose poi c'è il fatto che talvolta, in alcuni settori di mercato particolari, non esiste un modo univoco e semplice di far corrispondere il codice di un articolo X dal fornitore al cliente. E' questo il caso, ad esempio, del mercato dell'ottica, e delle lenti oftalmiche in particolare. In questo caso infatti, sia il codice identificativo di una lente al mometo dell'ordine, sia quello utilizzato nei documenti relativi alla consegna (DDT e Despatch Advice) deve necessariamente contenere la serie di parametri costruttivi (i poteri della lente) indispensabili a distinguere la lente destinata all'occhio destro del sig. Rossi da quella per l'occhio sinistro del sig. Bianchi. E questo a parità di tipo di lente ovviamente. Ciò significa in pratica che le due lenti (quella per il sig. Bianchi e quella per il sig. Rossi) saranno identificate da due codici diversi dal fornitore, mentre corrisponderanno ad un unico articolo per il cliente, almeno dal punto di vista della valorizzazione a magazzino e della fatturazione.
Il processo di transcodifica non potrà non tenere conto di questo tipo di mapping non biunivoco, e dei relativi problemi di gestione.
