# Hoe werkt de EDI-koppeling met het ERP? Voor de EDI-koppeling met het ERP zijn er drie gangbare routes: een programmeerinterface (API), interfacetabellen in een database of de uitwisseling van bestanden. Welke past, bepaalt meestal het ERP: wat het al biedt, is bijna altijd goedkoper dan iets nieuws bouwen. Belangrijker dan de technische route is vaak de koppeling van stamgegevens: welk artikelnummer, welke klant en welke eenheid aan beide kanten bedoeld is. ## Waar de ERP-koppeling in het EDI-proces zit Een EDI-oplossing heeft twee kanten. Naar buiten praat ze met de partner, in zijn formaat en via zijn communicatieprotocol (zie [communicatieprotocollen](https://edi-service.eu/nl/kennisbank/edi-communicatieprotocollen/)). Naar binnen praat ze met uw ERP. Daartussen zit de mapping, die een EDIFACT-order vertaalt naar de structuur die uw ERP begrijpt, en omgekeerd een factuur uit het ERP naar de INVOIC van de partner. De partner ziet niets van de ERP-kant. Voor hem telt alleen dat berichten op tijd en volledig aankomen. Voor u bepaalt de ERP-kant of orders zonder handwerk als verkooporders worden aangemaakt en of verzendbericht en factuur automatisch ontstaan. Sommige aanbieders rekenen de ERP-koppeling daarom apart af; EDI+EXPERTS noemt daarvoor in de prijslijst een “offerte op maat”. ## Drie routes voor de EDI-koppeling met het ERP ### Via API of webhook Veel nieuwere ERP-systemen bieden een programmeerinterface via HTTP, vaak als REST-API. De EDI-oplossing maakt een order dan rechtstreeks aan met een aanroep, en het ERP antwoordt direct met succes of fout. Voor de andere richting kan het ERP een webhook activeren: bij een gebeurtenis, zoals “levering geboekt”, roept het een adres van de EDI-software aan. Belangrijk is hoe met herhalingen wordt omgegaan. Breekt de verbinding na het verzenden af, dan weet de EDI-oplossing niet of de order is aangemaakt. De HTTP-norm (RFC 9110) onderscheidt daarom idempotente methoden, waarbij herhaling hetzelfde effect heeft als één enkele aanroep. In de praktijk betekent dat: elke order heeft een unieke sleutel nodig, zodat een tweede poging geen dubbele order oplevert. ### Via interfacetabellen (DB-staging) Veel ERP-systemen, vooral oudere of branchespecifieke, hebben eigen importtabellen. De EDI-software schrijft een order als records in deze tabellen, vaak kop en regels apart, en zet een statusveld. Een programma in het ERP haalt de records op, controleert ze, maakt de order aan en schrijft het resultaat terug. Het voordeel: het ERP houdt de controle over zijn validatieregels, en de status van elk record is na te gaan. Het nadeel: de EDI-oplossing heeft toegang tot de database nodig, en het ophaalprogramma in het ERP moet draaien. Schrijf nooit rechtstreeks in de eigenlijke ordertabellen van het ERP. Daarmee omzeilt u de controles, en een update van het ERP kan de koppeling ongemerkt breken. ### Via bestanden Bijna elk ERP kan bestanden inlezen en uitvoeren, meestal als CSV, XML of JSON. De EDI-software zet een bestand in een map, op een bestandsserver of via SFTP, en het ERP importeert het op vaste tijden. In de andere richting exporteert het ERP pakbonnen of facturen als bestand, dat de EDI-oplossing ophaalt. Bestanden zijn robuust en gemakkelijk te controleren, omdat u ze kunt openen en lezen. Terugmeldingen komen wel vertraagd, en importfouten ziet u vaak pas in het logboek van het ERP. Spreek daarom vaste regels af: unieke bestandsnamen, schrijven onder een tijdelijke naam en pas daarna hernoemen, aparte mappen voor succes en fouten. ### IDoc als bijzonder geval In SAP-omgevingen is het IDoc (Intermediate Document) gangbaar. SAP beschrijft het als container voor gegevensuitwisseling tussen SAP-systemen en externe systemen, bestaande uit kop, gegevenssegmenten en statusrecords. Een IDoc is daarmee eerder een formaat dan een eigen route; afhankelijk van de inrichting wordt het als bestand of via een interface verstuurd. ## De drie routes vergeleken | | API of webhook | Interfacetabellen | Bestand | |---|---|---|---| | Terugmelding | direct | zodra het ERP het record heeft verwerkt | vertraagd, vaak via logboek | | Foutopsporing | via antwoordcodes en logboeken | status per record in de tabel | bestand lezen, foutmap | | Voorwaarde in het ERP | gedocumenteerde API | importtabellen en ophaalprogramma | import- en exportfunctie | | Toegang voor de EDI-software | netwerk en toegangsgegevens voor de API | databasetoegang, bij voorkeur alleen tot deze tabellen | map of SFTP-account | | Dubbele orders voorkomen | unieke sleutel per transactie | unieke sleutel in de tabel | unieke bestandsnamen, archiveren na import | | Geschikt voor | moderne ERP-systemen, cloud-ERP | ERP met bestaande importtabellen | bijna elk ERP, ook oudere | ## Mapping van stamgegevens is het eigenlijke werk De meeste fouten bij de EDI-koppeling met het ERP ontstaan niet in de techniek, maar bij het koppelen van nummers en eenheden. - Artikelnummers: de partner bestelt met zijn materiaalnummer of met de GTIN, uw ERP kent uw eigen artikelnummer. GS1 beschrijft de GTIN als het nummer waarmee een bedrijf zijn handelseenheden eenduidig identificeert. U hebt een onderhouden koppeltabel nodig, in het ERP of in de EDI-oplossing. - Partners en afleverlocaties: de partner noemt koper, afleverlocatie en factuurontvanger meestal met een GLN. Uw ERP werkt met klantnummers en afleveradressen. Elke GLN moet aan een record zijn gekoppeld, anders belandt de levering op de verkeerde plek. Meer daarover onder [GLN en andere identificaties](https://edi-service.eu/nl/kennisbank/gln-locatiecode/). - Eenheden: de partner bestelt per stuk, uw ERP voert het artikel als doos van twaalf stuks. Zonder omrekening kloppen aantallen en prijzen niet. - Prijzen en voorwaarden: wijkt de prijs in de order af van de prijs in het ERP, dan moet vaststaan welke prijs geldt en wie een melding krijgt. ## Foutafhandeling en testen Plan voor elke fout een route. Een order met een onbekend artikelnummer mag niet verdwijnen en ook niet half worden aangemaakt. Hij hoort in een foutenlijst met het originele bestand en een begrijpelijke melding, zodat iemand hem kan corrigeren en opnieuw kan inlezen. Wie welke melding krijgt, moet vóór de start vaststaan. Test de koppeling eerst tegen een testadministratie of testomgeving van het ERP. Speel daar echte voorbeelden uit de handleiding van de partner door, ook de vervelende: annuleringen, deelleveringen, onbekende artikelen, dubbele berichten. Pas als deze gevallen goed verlopen, hoort de koppeling in de productieadministratie. Welke punten in de handleiding daarvoor belangrijk zijn, laat de [checklist voor de EDI-handleiding](https://edi-service.eu/nl/kennisbank/edi-handleiding-checklist/) zien. ## Wat edi-service.eu aan de ERP-kant biedt edi-service.eu koppelt uw ERP via drie algemene adapters: een REST- en webhookadapter, interfacetabellen in een database en een bestandsadapter voor CSV, XML of JSON. Een kant-en-klare adapter voor een bepaald ERP-product hoort niet bij de omvang, evenmin als aanpassingen in het ERP zelf. De AI richt de koppeling eerst in de TEST-modus in; naar productie gaat ze pas na uw goedkeuring. Wat in de vaste prijs is inbegrepen, staat onder [Prijs](https://edi-service.eu/nl/#preis). Wilt u nagaan of uw ERP een van de drie routes biedt, dan kunt u een [aanvraag indienen](https://edi-service.eu/nl/aanvraag/). ## Veelgestelde vragen ### Welke interface heeft mijn ERP nodig voor EDI? Uw ERP heeft een manier nodig om orders te ontvangen en leveringen of facturen uit te voeren: een API, importtabellen of een bestandsinterface. Bijna elk ERP biedt minstens bestandsimport. Welke routes er zijn, staat in de documentatie van het ERP of weet uw ERP-partner. ### Moet het ERP zelf EDIFACT begrijpen? Nee. De vertaling tussen EDIFACT of VDA en het formaat van het ERP doet de EDI-software. Het ERP ziet alleen zijn eigen structuur, bijvoorbeeld een CSV-bestand of een API-aanroep. ### Wat is DB-staging? DB-staging betekent dat berichten via tussentabellen in de database worden overgedragen. De EDI-oplossing schrijft erin, een programma in het ERP leest, controleert en boekt. Zo blijven de validatieregels van het ERP van kracht. ### Hoe voorkom ik dubbele orders? Elk bericht heeft een unieke sleutel nodig, bijvoorbeeld partner plus ordernummer. De EDI-software en het ERP controleren vóór het aanmaken of deze sleutel al bestaat. Dat beschermt ook als een partner dezelfde order twee keer stuurt. ## Bronnen - IETF: “RFC 9110, HTTP Semantics”, (geraadpleegd 16-10-2026) - SAP: “IDocs (SAP Library)”, (geraadpleegd 16-10-2026) - GS1: “Global Trade Item Number (GTIN)”, (geraadpleegd 16-10-2026) - GS1: “Global Location Number (GLN)”, (geraadpleegd 16-10-2026) - EDI-Experts Service GmbH: “Preise”, (geraadpleegd 16-10-2026)