Skip to content

Hva er EDI-mapping?

EDI-mapping forklart: Hvordan data oversettes mellom systemer

EDI-mapping er oversettelsen mellom interne dataformater i et ERP-system og det standardiserte formatet handelspartneren krever — begge veier. Hvert felt i ERP-et kobles til et bestemt segment og dataelement i meldingen, med regler for konvertering, kodeverk og struktur. Mappingen er den delen av et EDI-oppsett som avgjør om meldingene godkjennes, og den vanligste årsaken til at de ikke gjør det.

Nøkkelpunkter:

  • Mapping kobler ERP-felt til meldingssegmenter, med transformasjons- og valideringsregler.
  • Målformatet bestemmes av mottakeren: EDIFACT/EANCOM eller XML, avhengig av hvem du sender til.
  • Mapping forutsetter at masterdata finnes i ERP-et — den kan ikke skape verdier som mangler.
  • Feil i mappingen gir systematiske feil: samme avvisning på hver melding av en type.
  • Hver handelspartner har sin egen spesifikasjon, så mappingen gjøres per relasjon.
  • ERP-oppgraderinger er den vanligste årsaken til at en fungerende mapping slutter å virke.

Hvordan ser en mapping ut?

I praksis er en mapping en tabell over koblinger. Et forenklet utdrag:

ERP-feltEDI-segmentMerknad
CustomerNumberNAD+BYKjøperidentifikasjon, normalt med GLN
ProductIDLINVarelinje, normalt med GTIN
InvoiceAmountMOABeløp, med kvalifikator for hvilken type
DeliveryDateDTMDato, med kvalifikator for hvilken dato

Kvalifikatorene er det som ofte overrasker ved første oppsett. Segmentet alene sier ikke nok: NAD brukes flere ganger i samme melding med ulike kvalifikatorer for kjøper, selger og leveringsadresse, og MOA brukes både for linjebeløp, avgiftsbeløp og totalsum. Mappingen må treffe riktig kombinasjon av segment og kvalifikator, ikke bare riktig segment.

Se EDIFACT for hvordan segmentstrukturen er bygget opp.

Hvordan fungerer EDI-mapping i praksis?

EDI-mapping forklart: Hvordan data oversettes mellom systemer

Prosessen har tre steg:

  1. Inndata fra ERP. Systemet genererer forretningsdata som ordre, leveranser eller fakturaer i sitt eget format.
  2. Mapping-regler. Hvert datafelt kobles til riktig segment og format. Dette omfatter datakonvertering (for eksempel datoformat), kodelister (landkoder, måleenheter) og strukturelle regler for hierarkiet i meldingen.
  3. Utdata som EDI-melding. Resultatet er en strukturert melding — ORDERS, ORDRSP, DESADV eller INVOIC — klar for sending.

Mappingen går begge veier. Innkommende meldinger oversettes motsatt vei, fra meldingsformat til ERP-struktur, og krever sitt eget regelsett.

Hvorfor er EDI-mapping nødvendig?

Hvorfor er EDI-mapping nødvendig?

EDI-mapping er nødvendig fordi interne systemer ikke bruker samme struktur eller standard som EDI.

Uten mapping:

  • Data kan ikke tolkes korrekt av mottakers system
  • Meldinger blir avvist i validering
  • Forretningsprosesser stopper

Mapping sikrer:

  • Strukturert datautveksling
  • Kompatibilitet mellom systemer
  • Validerbare meldinger i henhold til EDI-standarder

I norske retail-systemer (ASKO, Vinmonopolet og Rema 1000) er korrekt mapping en forutsetning for å kunne sende og motta EDI-meldinger.

Hva består en mapping av?

KomponentInnhold
KildedataInterne felt og tabeller i ERP-systemet
MålstrukturSegmenter og dataelementer i mottakerens format
TransformasjonsreglerKonvertering av formater og verdier, for eksempel dato og desimaler
ValideringsreglerKontroll av at obligatoriske felt finnes og har riktig format
KodekonverteringOversettelse fra interne koder til standardiserte, som GS1 og ISO

Kodekonverteringen er ofte den mest arbeidskrevende delen. Interne varegrupper, måleenheter og avgiftskoder må kobles til mottakerens kodeverk, og de to listene er sjelden bygget etter samme logikk.

Hvilket format mappes det til?

Målformatet bestemmes av mottakeren, ikke av leverandøren:

MottakerMålformat
Dagligvarekjeder og grossisterEDIFACT, normalt gjennom GS1s EANCOM-delsett
VinmonopoletEDI XML etter egen implementeringsguide
Offentlig sektor, fakturaEHF over Peppol

Konsekvensen er at en leverandør som selger til flere typer mottakere trenger flere mappinger fra samme ERP-data. Kildedataene er de samme; målstrukturen er ikke det.

Hva mapping ikke kan fikse

Mappingen kan bare flytte data som finnes. Mangler GTIN på varen eller GLN på lokasjonen i ERP-systemet, kan ingen mapping fylle inn verdiene. Det samme gjelder felt mottakeren krever, men som ERP-et ikke har: da må feltet opprettes eller utledes før mappingen kan fullføres.

Dette er grunnen til at rydding av masterdata bør skje før mappingarbeidet starter. Rekkefølgen omvendt fører til at mappingen bygges rundt hull som må lukkes senere.

Hvilke feil oppstår ved feil EDI-mapping?

FeiltypeHva som skjer
Feil segmentplasseringMeldingen avvises på strukturkontroll
Manglende obligatoriske feltAvvisning, ofte med uklar feilkode
Feil format på dato eller desimalerAvvisning på dataelementnivå
Ugyldige identifikatorer (GLN, GTIN)Avvisning på kodelistekontroll
Uoverensstemmelse mellom meldingerFaktura matcher ikke ordre eller leveranse

Det diagnostiske skillet som sparer mest tid: feil i mappingen gir systematiske avvisninger — samme feilkode på hver melding av en type — mens feil i dataene gir sporadiske avvisninger på enkelttransaksjoner. Kommer samme feil tilbake runde etter runde, er det ikke meldingen som skal rettes.

Se EDI-feil for hvordan rotårsaken lokaliseres, og EDI-validering for hvilke nivåer kontrollen dekker.

Hvordan implementeres EDI-mapping?

Mappingen konfigureres i en EDI-programvare eller integrasjonsplattform, basert på handelspartnerens spesifikasjon. Arbeidet krever kjennskap til målformatet, forståelse av de interne datastrukturene, og en presis definisjon av hvert felt og hver regel.

Deretter følger testing i mottakerens testmiljø, hvor struktur, obligatoriske felt og datakvalitet kontrolleres før produksjonssetting.

Mappingen er ikke ferdig når den er satt opp. De to vanligste årsakene til at en fungerende mapping slutter å virke:

  • ERP-oppgradering. Feltnavn, datatyper eller eksportformat endres, og mappingen peker på noe som ikke lenger finnes.
  • Oppdatert implementeringsguide. Mottakeren endrer obligatoriske felt eller kodeverk, uten at noe er endret på leverandørsiden.

Begge tilfeller krever ny testing. Se ERP-EDI integrasjon for hvordan koblingen mot ERP-systemet settes opp og vedlikeholdes.

Viktige konklusjoner om EDI-mapping

  • Mapping oversetter mellom ERP-felt og meldingssegmenter, begge veier.
  • Målformatet bestemmes av mottakeren; flere mottakere betyr flere mappinger.
  • Segment alene er ikke nok — kvalifikatoren avgjør hvilken bruk segmentet har.
  • Mapping kan ikke skape data som mangler i ERP-systemet.
  • Systematiske avvisninger peker på mappingen, sporadiske på datakvaliteten.
  • Mappingen må vedlikeholdes ved ERP-endringer og oppdaterte guider.

Trenger du hjelp med EDI-mapping?

Kundan bistår med oppsett, validering og vedlikehold av mapping mot norske handelspartnere, slik at meldingene er korrekt strukturert før de sendes til test og produksjon.

Ofte stilte spørsmål om EDI-mapping

Her svarer vi på de vanligste spørsmålene vi får fra nye og eksisterende kunder.

Mapping er oversettelsen mellom interne data og meldingsformatet: hvilket ERP-felt som havner i hvilket segment. Integrasjon er den samlede løsningen som kobler ERP-systemet til handelspartneren, og omfatter i tillegg kommunikasjonskanal, validering, feilhåndtering og overvåking. Mapping er altså én komponent i integrasjonen, men den som oftest avgjør om oppsettet fungerer.

Alle. De vanligste er ORDERS for innkjøpsordre, ORDRSP for ordrebekreftelse, DESADV for pakkseddel og INVOIC for faktura. Hver meldingstype har sin egen struktur og sitt eget sett obligatoriske felt, og må mappes separat. Godkjent mapping for én meldingstype gir ikke klarering for de andre.

Det avhenger av mottakeren. Dagligvarekjedene bruker i hovedsak EDIFACT gjennom GS1s EANCOM-delsett, Vinmonopolet krever EDI XML etter sin egen implementeringsguide, og faktura til offentlig sektor går som EHF over Peppol. En leverandør som selger til flere typer mottakere trenger derfor flere mappinger fra de samme ERP-dataene.

Meldingene avvises under validering, og avvisningen gjentar seg på hver melding av samme type til mappingen er rettet. Det stopper ordrebehandling, forsinker leveranser og hindrer fakturaer i å bli behandlet. Fordi feilen ligger i oppsettet og ikke i transaksjonen, hjelper det ikke å rette den enkelte meldingen.

Gjennom testmiljøet hos den aktuelle handelspartneren, hvor struktur, obligatoriske felt, kodeverk og datakvalitet kontrolleres. Kravene varierer mellom mottakerne — sjekk alltid gjeldende spesifikasjon hos den enkelte. Et oppsett som er godkjent hos én mottaker må testes på nytt mot neste.

Ja. En fungerende mapping kan slutte å virke uten at noen har rørt EDI-oppsettet. En ERP-oppgradering kan endre feltnavn, datatyper eller eksportformat, slik at mappingen peker på noe som ikke lenger finnes. Handelspartneren kan også oppdatere sin implementeringsguide. Begge deler krever gjennomgang og som regel ny testing.