Estrarre Dati da un DDT in PDF e Convertirlo in CSV

Il problema sembra piccolo: hai un PDF, ti serve un CSV. Ci sono decine di convertitori online che promettono di farlo in un clic.

Il motivo per cui non funzionano è che la conversione non è il problema. Il problema è che un DDT non è una tabella: è un documento con una testata, un corpo tabellare, dei totali e una quantità imprecisata di righe che non sono righe articolo — descrizioni che continuano sulla riga successiva, note di trasporto, subtotali, contributi ambientali. Un convertitore che non sa distinguerle produce un file che si apre correttamente ed è sbagliato, che è la peggiore delle due condizioni.

Questa pagina spiega i quattro modi in cui la cosa si può fare, quando ciascuno regge e dove si rompe.

Cosa vuol dire davvero "estrarre i dati" da un DDT

Ci sono due gruppi di campi, con problemi diversi.

La testata — fornitore, partita IVA, numero documento, data, destinazione, causale del trasporto, riferimento all'ordine. Sono valori singoli, sparsi sul foglio in posizioni che cambiano da fornitore a fornitore. Difficoltà: trovarli.

Le righe articolo — codice, descrizione, quantità, unità di misura, prezzo unitario, sconto, importo. Sono una struttura ripetuta. Difficoltà: mantenerne l'integrità.

Il secondo gruppo è quello che decide se un metodo funziona. La testata la si trova in qualche modo anche a occhio; le righe articolo sono dove tutto si rompe, e sono l'unica parte che serve davvero se il DDT deve poi essere confrontato con un ordine o con una fattura.

Metodo 1 — Copia-incolla a mano

Funziona. Costa quattro-cinque minuti per documento con poche righe, molto di più con venti.

Il limite non è il tempo: è che introduce errori silenziosi. Una cifra invertita in una quantità non produce nessun segnale — il numero è plausibile, il file è valido, il gestionale lo accetta. Se ne accorge il magazzino tre settimane dopo, quando l'inventario non torna, e a quel punto ricostruire quale documento fosse sbagliato costa più di tutto il tempo risparmiato.

Quando ha senso: sotto i cinque documenti al giorno, o per un fornitore occasionale.

Metodo 2 — Convertitore PDF → Excel generico

È la strada che quasi tutti provano per prima, ed è quella che fallisce nel modo più insidioso.

Questi strumenti ricostruiscono le colonne dalla posizione dei caratteri sulla pagina. Non hanno alcuna idea di cosa sia una quantità o un prezzo: vedono testo a coordinate diverse e ne deducono una griglia. Basta poco per far saltare la deduzione:

• una descrizione articolo che va a capo — la riga successiva diventa una riga a sé, con le colonne numeriche vuote
• una tabella che continua sulla pagina successiva ripetendo l'intestazione — l'intestazione diventa una riga di dati
• un subtotale o un contributo ambientale in mezzo alle righe — entra nel conto degli articoli
• due colonne troppo vicine — i valori si fondono in una cella sola

Ognuno di questi casi produce un file che si apre normalmente. L'errore non si vede finché qualcuno non lo cerca.

C'è poi il secondo problema, che nessun convertitore generico affronta: anche se l'estrazione fosse perfetta, il CSV che esce ha le colonne nell'ordine del documento del fornitore, non nell'ordine che il tuo gestionale si aspetta. Serve comunque una mappatura, e va rifatta per ogni fornitore.

Quando ha senso: per leggere una tabella una volta sola, mai per un flusso ricorrente.

Metodo 3 — Un template per ogni fornitore

Il salto di qualità: si dice al sistema, una volta, dove si trovano i campi sul documento di quel fornitore. Da lì in poi li legge sempre nello stesso posto.

Funziona bene, ed è la tecnologia che ha retto il mercato per vent'anni. Ha due limiti, entrambi strutturali:

1. Il costo iniziale scala con i fornitori. Con quaranta fornitori sono quaranta configurazioni, ognuna da fare con un documento vero in mano.
2. Il fornitore cambia layout quando gli pare. Aggiorna il gestionale, sposta il logo, aggiunge una colonna. Il template salta e nessuno lo sa finché i dati non arrivano vuoti o sbagliati.

Il secondo limite è quello che nella pratica affossa questi progetti: la manutenzione non finisce mai, e ricade su chi non ha tempo di farla.

Quando ha senso: pochi fornitori, ad alto volume, con documenti stabili nel tempo.

Metodo 4 — Interpretare il documento invece di mapparlo

L'approccio che i sistemi moderni usano: non si dice al sistema dove guardare, ma cosa cercare. Il modello legge il documento e riconosce che quella è una quantità e quell'altro un prezzo unitario per come sono fatti e per il contesto in cui stanno, non per la loro posizione in millimetri.

Le conseguenze pratiche:

• Nessuna configurazione iniziale. Un fornitore nuovo funziona al primo documento.
• Il cambio di layout non rompe niente. Il logo spostato è irrilevante se non stavi guardando la posizione.
• Le righe articolo restano intere. Una descrizione che va a capo viene ricongiunta alla sua riga, perché il sistema capisce che quel frammento di testo non è un articolo nuovo.

Ha un limite proprio, e va detto: non è deterministico. Un template sbagliato produce sempre lo stesso errore; un modello che interpreta può sbagliare una volta e non la successiva. La contromisura è che ogni campo estratto porti con sé un punteggio di affidabilità: i valori letti in modo incerto arrivano segnalati e vengono guardati, invece di passare silenziosamente come farebbe una cifra digitata male.

C'è poi il caso della scansione. Se il PDF è nativo — generato dal gestionale del fornitore — il testo è già dentro il file e va letto direttamente: passarlo per un riconoscimento ottico introdurrebbe errori invece di toglierne. L'OCR serve solo per scansioni e foto (e da solo non basta a leggere un DDT), e un sistema serio distingue i due casi da solo senza chiederlo.

Come si verifica il risultato

Qualunque metodo si usi, tre controlli automatici coprono la quasi totalità degli errori:

1. La somma delle righe torna con il totale di testata? È il controllo più potente perché è l'unico completamente indipendente: se una riga è stata persa o duplicata, il totale non torna.
2. Il numero di righe estratte corrisponde a quelle sul documento? Intercetta la riga saltata a fine pagina.
3. I campi obbligatori ci sono tutti? Numero documento, data, fornitore. Un documento senza numero non è importabile e va fermato prima, non dopo.

Un quarto controllo, dove disponibile, è confrontare il DDT con l'ordine d'acquisto: se sono arrivate quantità che nessuno aveva ordinato, prima ancora di essere un problema di magazzino potrebbe essere un errore di lettura.

Dal CSV al gestionale: l'ultimo metro

Un CSV corretto non è ancora un documento registrato. Il gestionale si aspetta un tracciato preciso — nomi e ordine delle colonne, separatore, formato di data, separatore decimale. In Italia questo dettaglio non è banale: molti gestionali vogliono il punto e virgola come separatore di campo e la virgola come separatore decimale, che è esattamente la combinazione che rompe un CSV generato con impostazioni anglosassoni.

BolleFlow produce direttamente il tracciato di TeamSystem, Zucchetti, SAP (IDoc XML), Sistemi, Passepartout e Arca Evolution, sia per i DDT sia per le fatture, così il passaggio di rimappatura sparisce. Con l'agente locale il file viene anche depositato nella cartella di import del gestionale e verificato.

In sintesi

Il modo più rapido per capire quale serve nel proprio caso è provare con i documenti veri, non con un esempio pulito: prendi il DDT del fornitore che ti dà più fastidio — quello con venti righe e le descrizioni lunghe — e guarda cosa esce. Il piano gratuito copre 25 documenti al mese.

BolleFlow fa questa lettura su DDT di qualunque fornitore, senza disegnare un template per ciascuno.

Continua da qui

• Software di estrazione dati DDT: come funziona
• Portare i DDT letti dentro il gestionale
• Digitalizzare i DDT dei fornitori: guida operativa
• Confrontare DDT, ordine e fattura
• DDT: cos'è e cosa deve contenere