Wat is EDI en wat is een EDI-koppeling?

EDI in twee zinnen

EDI is het uitwisselen van handelsdocumenten als gestructureerd bestand tussen de systemen van twee bedrijven. De afnemer stuurt een order die het ERP van de leverancier zonder overtypen kan inlezen, en de leverancier stuurt orderbevestiging, pakbon en factuur op dezelfde manier terug.

Het woord "EDI-koppeling" heeft twee betekenissen die vaak door elkaar lopen. Soms is de verbinding met de handelspartner bedoeld: de lijn of de postbus waarover de bestanden gaan. Meestal is de vertaling bedoeld tussen het EDI-bericht en je eigen administratie. GS1 Nederland noemt dat laatste mapping: het bericht omzetten naar een formaat dat je systeem automatisch verwerkt. Volgens GS1 heb je daar een EDI-module of vertaalsoftware voor nodig, plus iemand die zowel je systeem als de EDI-standaard kent om de mapping te definiëren. Beide kanten moeten mappen: de verzender en de ontvanger.

In welk formaat: EDIFACT, EANCOM en X12

Er zijn twee grote families. UN/EDIFACT is de internationale standaard met berichten die een naam hebben: ORDERS, DESADV, INVOIC. X12 is de Noord-Amerikaanse standaard met genummerde berichten: 850, 856, 810.

EDIFACT bevat voor elk bericht veel meer velden dan één sector nodig heeft. GS1 maakt er daarom een deelverzameling van voor de handel: EANCOM. De huidige versie is EANCOM 2002, gebaseerd op EDIFACT-directory D.01B. Daarbovenop legt GS1 Nederland per sector vast welke velden verplicht zijn en hoe ze worden gevuld. Er zijn handleidingen voor levensmiddelen en drogisterij, doe-het-zelf, tuin en dier, gezondheidszorg en mode, in EANCOM en in XML.

Voor een koppeling telt vooral de onderste laag. Twee afnemers op hetzelfde sectorprofiel vragen in de praktijk niet precies hetzelfde.

Hoe ziet een EDI-bericht eruit?

Een EDIFACT-bestand is platte tekst, opgebouwd uit segmenten. Elk segment begint met drie letters en eindigt met een apostrof. Dit is een order van een distributiecentrum aan Bakker Installatie B.V., ingekort tot twee regels:

UNB+UNOA:4+8712300000018:14+8712345000011:14+20261005:0812+4711'
UNH+1+ORDERS:D:01B:UN:EAN010'
BGM+220+4500012345+9'
DTM+137:20261005:102'
NAD+BY+8712300000018::9'
NAD+SU+8712345000011::9'
NAD+DP+8712300001237::9'
LIN+1++8712345104825:SRV'
QTY+21:48'
LIN+2++8712345104993:SRV'
QTY+21:30'
UNS+S'
CNT+2:2'
UNT+13+1'
UNZ+1+4711'

Het bericht zit in een envelop. UNB opent de envelop met afzender en ontvanger als GLN en referentie 4711; UNZ sluit hem met het aantal berichten en dezelfde referentie. Binnen de envelop opent UNH het bericht en sluit UNT het af. De tellers moeten kloppen, anders wordt het bestand geweigerd voordat iemand de inhoud leest:

• UNT+13: van UNH tot en met UNT staan 13 segmenten: UNH, BGM, DTM, drie keer NAD, twee keer LIN en QTY, UNS, CNT en UNT. Dat is 1 + 1 + 1 + 3 + 4 + 1 + 1 + 1 = 13.
• CNT+2:2: twee artikelregels.
• UNZ+1+4711: één bericht in de envelop, referentie gelijk aan die in UNB.

De scheidingstekens zijn vast: + tussen elementen, : binnen een element, ' aan het eind van een segment. Komt een van die tekens in de data voor, dan krijgt het een ? ervoor. Een klantnaam als BAKKER'S moet als BAKKER?'S in het bestand, anders eindigt het segment na de R en is de rest van de regel onleesbaar. En bij tekenset UNOA mogen alleen hoofdletters: een artikelomschrijving met kleine letters wordt geweigerd.

Welke berichten gaan er heen en weer?

Een EDI-order is zelden één bericht. Dit zijn de vijf berichten die rond één order kunnen lopen:

APERAK is een bericht van de applicatie, niet van de vertaalsoftware. Volgens EANCOM bevestigt hij dat de order in de applicatie van de ontvanger is aangekomen, met de fouten die daar zijn gevonden, en niet alleen dat het bestand binnen is. Welke van de vijf je afnemer echt vraagt, staat in zijn eigen afspraken. Hoe de pakbon is opgebouwd staat in wat is een DESADV, de berichten een voor een in EDIFACT-berichten.

Bij een afspraak met ORDERS, APERAK, DESADV en INVOIC ontvang je per order één bericht en verstuur je er drie. Tien orders zijn 10 berichten in en 10 × 3 = 30 berichten uit, 40 in totaal. Een deellevering voegt per extra zending een DESADV en een INVOIC toe: dezelfde tien orders met elk één nalevering geven 30 + 10 × 2 = 50 uitgaande berichten.

Vier manieren om met een afnemer te verbinden

Hoe het bestand bij de afnemer komt, staat los van wat erin staat. Er zijn vier gangbare vormen:

AS2 is vastgelegd in RFC 4130: het bestand gaat ondertekend en versleuteld over HTTPS, en de ontvanger stuurt een ondertekende ontvangstbevestiging terug, de MDN. Bij een broker controleer je periodiek je postbus. GS1 Nederland raadt aan om per organisatie één postbus te gebruiken, zodat ontvangstbevestiging, pakbon en factuur naar hetzelfde adres gaan.

Web-EDI lost de verplichting op en houdt het handwerk in stand: elke order wordt alsnog overgetypt, alleen in een ander scherm. Bij een broker of een directe lijn blijft de vraag hoe het bericht in het ERP komt. Dat is de mapping, en die doet het netwerk niet.

EDI of API?

Beide verbinden systemen, op een andere manier:

In een orderstroom met een retailer zitten ze vaak naast elkaar: EDI naar de afnemer, een API naar je ERP of webshop. Hoe een API-koppeling werkt staat in wat is een API-koppeling.

Wat betekent dit voor je koppeling?

Het EDI-bericht is gestandaardiseerd; je eigen administratie niet. Een ORDERS wordt pas een verkooporder als de GLN van de afnemer een debiteur heeft, de GTIN een artikel in de juiste verpakkingseenheid, en het afleveradres een GLN die je ERP kent. Op de terugweg moet het ERP de geleverde aantallen, de SSCC's en de factuurgegevens precies zo aanleveren als het profiel van de afnemer vraagt.

Wij bouwen die koppeling tussen je ERP en je EDI-verbinding, per afnemer en per bericht, en draaien en bewaken hem. Een bericht dat wordt geweigerd staat met de reden in het dashboard en wordt niet stil overgeslagen. Meer op EDI koppeling en in het overzicht van koppelingen tussen je webshop, ERP en de systemen erachter. Vertel welke afnemer om EDI vraagt, dan hoor je welke berichten en velden dat betekent.