# Come funziona l'integrazione EDI-ERP? Per l'integrazione EDI-ERP esistono tre strade diffuse: un'interfaccia di programmazione (API), tabelle di interfaccia in un database o lo scambio di file. Quale sia adatta lo decide di solito l'ERP: ciò che offre già costa quasi sempre meno che costruire qualcosa di nuovo. Più importante della strada tecnica è spesso l'abbinamento dei dati anagrafici, cioè quale codice articolo, quale cliente e quale unità di misura si intendono da entrambe le parti. ## Dove si colloca l'integrazione con l'ERP nel flusso EDI Una soluzione EDI ha due lati. Verso l'esterno parla con il partner, nel suo formato e sul suo canale di trasmissione (vedi [Canali di trasmissione](https://edi-service.eu/it/guida/canali-di-trasmissione-edi/)). Verso l'interno parla con il vostro ERP. In mezzo c'è il mapping, che traduce un ordine EDIFACT nella struttura che il vostro ERP capisce e, al contrario, una fattura dell'ERP nella INVOIC del partner. Il partner non vede nulla del lato ERP. Per lui conta solo che i messaggi arrivino puntuali e completi. Per voi è il lato ERP a decidere se gli ordini vengono creati come ordini cliente senza lavoro manuale e se avviso di spedizione e fattura nascono in automatico. Alcuni fornitori fatturano quindi a parte l'integrazione con l'ERP; EDI+EXPERTS, per esempio, nel listino indica per questo un'«offerta personalizzata». ## Tre strade per l'integrazione EDI-ERP ### Via API o webhook Molti ERP recenti offrono un'interfaccia di programmazione via HTTP, spesso come API REST. La soluzione EDI crea allora un ordine direttamente con una chiamata e l'ERP risponde subito con successo o errore. Per la direzione opposta l'ERP può attivare un webhook: al verificarsi di un evento, per esempio «consegna registrata», richiama un indirizzo del software EDI. È importante gestire le ripetizioni. Se la connessione si interrompe dopo l'invio, la soluzione EDI non sa se l'ordine è stato creato. La norma HTTP (RFC 9110) distingue per questo i metodi idempotenti, la cui ripetizione ha lo stesso effetto di una singola chiamata. In pratica: ogni ordine ha bisogno di una chiave univoca, così che un secondo tentativo non generi un ordine doppio. ### Tramite tabelle di interfaccia (staging su database) Molti ERP, soprattutto quelli più vecchi o di settore, hanno tabelle di importazione proprie. Il software EDI scrive un ordine come record in queste tabelle, spesso testata e righe separate, e imposta un campo di stato. Un programma nell'ERP preleva i record, li controlla, crea l'ordine e scrive il risultato. Il vantaggio: l'ERP mantiene il controllo sulle sue regole di verifica e lo stato di ogni record è tracciabile. Lo svantaggio: la soluzione EDI ha bisogno di accedere al database e il programma di prelievo nell'ERP deve essere attivo. Non scrivete mai direttamente nelle tabelle degli ordini vere e proprie dell'ERP. Così aggirate i suoi controlli, e un aggiornamento dell'ERP può rompere l'integrazione senza che ve ne accorgiate. ### Tramite file Quasi ogni ERP sa leggere e produrre file, di solito CSV, XML o JSON. Il software EDI deposita un file in una cartella, su un file server o via SFTP, e l'ERP lo importa a orari prestabiliti. Nella direzione opposta l'ERP esporta documenti di trasporto o fatture come file, che la soluzione EDI preleva. I file sono robusti e facili da controllare, perché si possono aprire e leggere. In compenso i riscontri arrivano in ritardo e gli errori di importazione si vedono spesso solo nel log dell'ERP. Concordate quindi regole fisse: nomi di file univoci, scrittura con un nome temporaneo e solo dopo la rinomina, cartelle separate per esiti positivi ed errori. ### L'IDoc come caso particolare Negli ambienti SAP è diffuso l'IDoc (Intermediate Document). SAP lo descrive come contenitore per lo scambio di dati tra sistemi SAP e sistemi esterni, composto da testata, segmenti di dati e record di stato. Un IDoc è quindi più un formato che una strada a sé; a seconda della configurazione viene trasmesso come file o tramite un'interfaccia. ## Le tre strade a confronto | | API o webhook | Tabelle di interfaccia | File | |---|---|---|---| | Riscontro | immediato | appena l'ERP ha elaborato il record | in ritardo, spesso tramite log | | Ricerca degli errori | tramite codici di risposta e log | stato per record nella tabella | leggere il file, cartella errori | | Requisito nell'ERP | API documentata | tabelle di importazione e programma di prelievo | funzione di importazione ed esportazione | | Accesso per il software EDI | rete e credenziali per l'API | accesso al database, possibilmente solo a queste tabelle | cartella o account SFTP | | Evitare ordini doppi | chiave univoca per operazione | chiave univoca nella tabella | nomi di file univoci, archiviazione dopo l'importazione | | Adatta per | ERP moderni, ERP in cloud | ERP con tabelle di importazione esistenti | quasi ogni ERP, anche i più vecchi | ## Il mapping dei dati anagrafici è il vero lavoro La maggior parte degli errori nell'integrazione EDI-ERP non nasce nella tecnica, ma nell'abbinamento di codici e unità di misura. - Codici articolo: il partner ordina con il suo codice materiale o con il GTIN, il vostro ERP conosce il vostro codice articolo. GS1 descrive il GTIN come il numero con cui un'azienda identifica in modo univoco le proprie unità commerciali. Serve un abbinamento curato, nell'ERP o nella soluzione EDI. - Partner e luoghi di consegna: il partner indica acquirente, luogo di consegna e destinatario della fattura di solito con il GLN. Il vostro ERP lavora con codici cliente e indirizzi di consegna. Ogni GLN deve essere abbinato a un record, altrimenti la merce arriva nel posto sbagliato. Altre informazioni in [GLN e altri codici identificativi](https://edi-service.eu/it/guida/gln-codici-identificativi-edi/). - Unità di misura: il partner ordina in pezzi, il vostro ERP gestisce l'articolo in cartoni da dodici pezzi. Senza conversione quantità e prezzi non tornano. - Prezzi e condizioni: se il prezzo nell'ordine differisce da quello nell'ERP, deve essere chiaro quale prevale e chi viene avvisato. ## Gestione degli errori e test Prevedete una strada per ogni errore. Un ordine con un codice articolo sconosciuto non deve né sparire né essere creato a metà. Va in un elenco degli errori con il file originale e un messaggio in chiaro, così che qualcuno possa correggerlo e reinserirlo. Chi riceve quale segnalazione dovrebbe essere stabilito prima dell'avvio. Testate l'integrazione prima su una società di test o su un ambiente di test dell'ERP. Fate passare lì esempi reali tratti dalla guida EDI del partner, anche quelli scomodi: annullamenti, consegne parziali, articoli sconosciuti, messaggi doppi. Solo quando questi casi funzionano correttamente l'integrazione può passare all'ambiente di produzione. Quali punti della guida contano per questo lo mostra la [checklist per la guida EDI](https://edi-service.eu/it/guida/linee-guida-edi-checklist/). ## Che cosa offre edi-service.eu sul lato ERP edi-service.eu collega il vostro ERP tramite tre adattatori generici: un adattatore REST e webhook, tabelle di interfaccia in un database e un adattatore per file CSV, XML o JSON. Un adattatore pronto per un determinato prodotto ERP non fa parte del perimetro, e nemmeno le modifiche all'ERP stesso. L'IA configura l'abbinamento prima in modalità TEST e lo porta in produzione solo dopo la vostra approvazione. Che cosa comprende il prezzo fisso è indicato alla voce [Prezzo](https://edi-service.eu/it/#preis). Se volete chiarire se il vostro ERP offre una delle tre strade, potete [inviare una richiesta](https://edi-service.eu/it/richiesta/). ## Domande frequenti ### Di quale interfaccia ha bisogno il mio ERP per l'EDI? Il vostro ERP ha bisogno di un modo per ricevere ordini e restituire consegne o fatture: un'API, tabelle di importazione o un'interfaccia file. Quasi ogni ERP offre almeno l'importazione di file. Quali strade esistano lo indica la documentazione dell'ERP oppure lo sa chi ne cura l'assistenza. ### L'ERP deve capire EDIFACT? No. La traduzione tra EDIFACT o VDA e il formato dell'ERP la fa il software EDI. L'ERP vede solo la propria struttura, per esempio un file CSV o una chiamata API. ### Che cos'è lo staging su database? Staging su database significa che i messaggi vengono passati tramite tabelle intermedie nel database. La soluzione EDI vi scrive, un programma nell'ERP legge, controlla e registra. Così le regole di verifica dell'ERP restano in vigore. ### Come si evitano ordini doppi? Ogni messaggio ha bisogno di una chiave univoca, per esempio partner più numero d'ordine. Software EDI ed ERP controllano prima della creazione se quella chiave esiste già. Questo protegge anche quando un partner invia lo stesso ordine due volte. ## Fonti - IETF: «RFC 9110, HTTP Semantics», (consultato il 16/10/2026) - SAP: «IDocs (SAP Library)», (consultato il 16/10/2026) - GS1: «Global Trade Item Number (GTIN)», (consultato il 16/10/2026) - GS1: «Global Location Number (GLN)», (consultato il 16/10/2026) - EDI-Experts Service GmbH: «Preise», (consultato il 16/10/2026)