EDIFACT-berichten: welke er zijn en hoe je ze leest

Een EDIFACT-bericht in twee zinnen

Een EDIFACT-bericht is één handelsdocument als tekstbestand, opgebouwd uit segmenten van drie letters met velden ertussen. Welk document het is, staat in de naam van zes letters in de kop van het bericht: ORDERS, ORDRSP, DESADV, INVOIC.

UN/EDIFACT is de standaard van de Verenigde Naties. In de Nederlandse handel werk je bijna altijd met EANCOM, de deelverzameling die GS1 daaruit heeft gemaakt: alleen de velden die de handel gebruikt, en GLN, GTIN en SSCC als vaste sleutels. Wat EDI in het algemeen is en hoe het bestand bij je afnemer komt, staat in wat is EDI. Deze pagina gaat over de berichten zelf.

Welke EDIFACT-berichten bestaan er?

GS1 publiceert de EANCOM-gidsen in de editie 2016, laatst bijgewerkt in augustus 2022, voor syntaxversie 3 en 4. Die editie bevat 49 berichten in acht groepen (eigen telling van de lijst bij GS1):

Een leverancier die aan een retailer of groothandel levert, heeft met een handvol daarvan te maken. Elk bericht heeft in EANCOM 2002 een eigen versienummer van de deelverzameling, dat los van de andere berichten wordt bijgewerkt:

Drie daarvan worden vaak vergeten bij het inrichten van een koppeling. ORDCHG wijzigt een order die al als verkooporder in je ERP staat. RECADV meldt dat de afnemer minder heeft ontvangen dan je DESADV aankondigde, en dat verschil komt terug op de factuur. REMADV vertelt welke facturen een betaling dekt, en zonder dat bericht wordt een verzamelbetaling met de hand afgeletterd. Hoe de pakbon is opgebouwd staat in wat is een DESADV.

Hoe lees je een segment?

Een segment begint met een label van drie letters en eindigt met een apostrof. Daartussen staan gegevenselementen, gescheiden door +. Een samengesteld element bestaat uit delen, gescheiden door :. Elk element heeft in de standaard een nummer, en veel elementen zijn een kwalificatie: een code die zegt wat de volgende waarde betekent. Twee datumsegmenten uit een order:

DTM+2:20261007:102'
DTM+64:202610070600:203'

Ontleed:

Het segment DTM komt in één order vaak vier of vijf keer voor. De kwalificatie bepaalt in welk veld van je ERP de datum hoort: 137 is de orderdatum, 2 de gewenste leverdatum, 63 en 64 het laatste en vroegste levermoment. Een koppeling die "de eerste DTM" als leverdatum neemt, zet bij de ene afnemer de orderdatum in het leverveld en bij de andere de juiste datum, afhankelijk van de volgorde in het bestand.

Zo werken ook de partijen. NAD+BY is de koper, NAD+DP het afleveradres, NAD+IV het factuuradres, NAD+SU de leverancier. Alle vier dragen ze een GLN van 13 cijfers. Wat een GLN is en waarom het afleveradres een eigen nummer heeft, staat in wat is een GLN.

Wat de berichtsoort en de functie zeggen

Het segment BGM zegt welk soort document het is en wat je ermee moet. In een ORDERS kent EANCOM onder meer deze soorten:

GS1 raadt aan de specifiekere code te gebruiken in plaats van de algemene 220. Voor je ERP maakt dat verschil: een afroep (226) hoort bij een raamorder die er al is en mag geen nieuwe verkooporder met de volledige hoeveelheid worden.

Het laatste element van BGM is de functie: 9 is een origineel, 5 vervangt een eerder bericht, 7 is een duplicaat dat de ontvanger zelf heeft opgevraagd, 31 is een kopie ter informatie. Een order met functie 7 of 31 die als nieuwe order wordt ingelezen, staat er daarna twee keer in.

Versies: D.96A, D.01B en de code in UNH

Elk bericht vermeldt in UNH op welke versie het is gebouwd:

UNH+1+ORDERS:D:01B:UN:EAN010'

D:01B is de EDIFACT-directory, de tweede release van 2001. EANCOM 2002 is gebouwd op D.01B, de oudere EANCOM 1997 op D.96A. EAN010 is het versienummer van de EANCOM-deelverzameling voor dit bericht. Een afnemer die nog EANCOM 1997 stuurt, levert andere segmenten en codes aan dan een afnemer op 2002, ook als het bericht dezelfde naam heeft.

Op die versiecode kun je niet blind vertrouwen. De GS1-gids voor ORDERS beschrijft versie 010 en noemt in de codelijst van hetzelfde element EAN011; de voorbeelden in dezelfde gids gebruiken EAN010. De Nederlandse handleiding voor de pakbon gebruikt in haar voorbeeld EAN007, terwijl de internationale gids versie 008 beschrijft. Welke code je afnemer verwacht en stuurt, staat in zijn profiel. Een koppeling leest de versie per bericht uit UNH en kiest daarop de mapping, in plaats van één versie aan te nemen.

Veldlengtes en referenties: waar je ERP en EDIFACT botsen

Elk element heeft een vaste maximale lengte. Een paar die bij een koppeling steeds terugkomen:

Naam en adres staan alleen in het bericht als een GLN niet volstaat; normaal is NAD+DP+8712300001237::9' genoeg. Moet de naam er toch in, dan gaat "Installatiebedrijf Van den Heuvel en Zonen B.V." van 47 tekens niet in één veld van 35. De koppeling knipt op een spatie: "Installatiebedrijf Van den Heuvel" (33 tekens) in het eerste veld en "en Zonen B.V." (13 tekens) in het tweede. 33 + 1 spatie + 13 = 47. Afkappen op 35 levert "Installatiebedrijf Van den Heuvel e" op.

De referentie in UNB heeft een eigen regel. Samen met de GLN van de afzender en de ontvanger maakt hij de interchange uniek, en GS1 raadt aan een nummer pas na minstens drie maanden opnieuw te gebruiken. Een teller van vier cijfers loopt tot 9.999. Bij 150 interchanges per dag is die na 9.999 / 150 = 66,7 dagen op en begint hij opnieuw, ruim binnen die drie maanden. De ontvanger ziet dan een referentie die hij al kent en kan het bestand als dubbel weigeren. Een referentie van datum plus volgnummer, 20261007-0001, is 13 tekens en past binnen de 14.

Het scheidingsteken voor decimalen is standaard een punt. Wil een afzender iets anders, dan staat dat in een UNA-segment voor de envelop. Zonder UNA gelden de standaardtekens : + . ? en '.

Wat betekent dit voor je koppeling?

Een EDIFACT-bericht is gestandaardiseerd tot op het element, maar welke berichten, welke kwalificaties en welke versie je afnemer gebruikt, verschilt per afnemer. De koppeling moet per bericht de juiste datum bij de juiste kwalificatie zoeken, de soort en de functie in BGM respecteren, de versie uit UNH lezen en op de terugweg binnen de veldlengtes blijven.

Wij bouwen die mapping tussen je ERP en je EDI-verbinding, per afnemer en per bericht, en draaien en bewaken hem daarna. Een bericht dat je afnemer afwijst, staat met de reden in het dashboard en wacht in de wachtrij tot het is opgelost. Meer op EDI koppeling, en per pakket op AFAS EDI koppeling en Exact Online EDI koppeling. Vertel welke berichten je afnemer vraagt, dan hoor je wat er aan je kant voor nodig is.