Hva er EDIFACT? Forklart for leverandører – Kundan

EDIFACT (UN/EDIFACT – United Nations Electronic Data Interchange for Administration, Commerce and Transport) er den internasjonale standarden for elektronisk utveksling av forretningsdokumenter mellom systemer. Standarden definerer faste meldingsstrukturer for ordre, ordrebekreftelser, pakksedler og fakturaer, slik at to systemer kan utveksle data uten manuell registrering.

Merk: «EDI FACT» i to ord er en vanlig skrivemåte, men det finnes ingen egen standard med det navnet. Det er samme standard som EDIFACT.

Nøkkelpunkter:

• EDIFACT forvaltes av UN/CEFACT og brukes internasjonalt på tvers av bransjer.
• I varehandelen brukes som regel EANCOM, GS1s delsett av UN/EDIFACT.
• Norske kjeder publiserer egne implementasjonsguider som definerer hvilke segmenter og koder som er obligatoriske.
• Vanlige meldingstyper er ORDERS, ORDRSP, DESADV, INVOIC, INVRPT og PRICAT.
• Meldinger valideres på tre nivåer: syntaks, forretningsregler og datakonsistens.
• Mottaker kvitterer med CONTRL for syntaks og APERAK for applikasjonsfeil.

Hva er EDIFACT?

Er «EDI FACT» og EDIFACT det samme?

Ja. EDIFACT er ett ord og ett standardnavn. Skrivemåten «EDI FACT» dukker opp fordi forkortelsen ser ut som to deler – «EDI» og «FACT» – men den siste delen er ikke et selvstendig begrep. Navnet står for Electronic Data Interchange for Administration, Commerce and Transport, og hele forkortelsen hører sammen.

Det finnes heller ingen egen norsk EDIFACT-variant. Det som varierer fra land til land og fra kjede til kjede, er implementasjonen, ikke standarden:

Nivå	Hva det er	Hvem forvalter det
UN/EDIFACT	Selve syntaksen og de internasjonale meldingstypene	UN/CEFACT
EANCOM	GS1s delsett av UN/EDIFACT, tilpasset varehandel	GS1
Implementasjonsguide	Hvilke segmenter og koder den enkelte kjeden krever	Den enkelte kjeden

Når en norsk dagligvarekjede sier at de «krever EDIFACT», mener de i praksis EANCOM-baserte meldinger satt opp etter deres egen implementasjonsguide.

For en generell innføring i hva EDI er, se Hva er EDI og hvordan fungerer det?

Hvordan fungerer EDIFACT?

Hvilke dokumenttyper sendes med EDIFACT?

EDIFACT dekker hele transaksjonsflyten i varehandelen. De vanligste meldingstypene:

Melding	Hva den brukes til	Retning
ORDERS	Innkjøpsordre	Kjede → leverandør
ORDRSP	Ordrebekreftelse	Leverandør → kjede
DESADV	Pakkseddel og forsendelsesmelding	Leverandør → kjede
INVOIC	Faktura og kreditnota	Leverandør → kjede
INVRPT	Lagerstatusrapport	Begge veier
PRICAT	Pris- og produktkatalog	Leverandør → kjede
CONTRL	Teknisk kvittering	Mottaker → avsender
APERAK	Applikasjonskvittering med feilmelding	Mottaker → avsender

Hvilke standarder gjelder i norsk varehandel?

Norske dagligvare- og elektronikkjeder bygger EDI-oppsettet sitt i tre lag:

• UN/EDIFACT definerer syntaks og meldingstyper.
• EANCOM, GS1s delsett av UN/EDIFACT, velger ut de elementene varehandelen faktisk trenger og knytter dem til GS1-nøklene GTIN, GLN og SSCC. GS1 Norge forvalter dette i Norge.
• Kjedens egen implementasjonsguide angir hvilke segmenter, koder og dataelementer som er obligatoriske mot akkurat den mottakeren.

Det siste laget er grunnen til at et EDI-oppsett som fungerer mot én kjede ikke nødvendigvis fungerer mot neste. Onboarding må gjøres per handelspartner, og testfasen tar normalt lengst tid.

Et konkret eksempel på hvordan én innkjøper formulerer kravene sine, finner du i Vinmonopolets EDI-krav.

Hva er de tekniske kravene for EDI FACT?

For å bruke EDIFACT må leverandøren ha et systemmiljø som kan generere, validere, sende og motta standardiserte meldinger. Minimumskravene:

• ERP- eller lagersystem med strukturert dataeksport
• EDI-konverter eller integrasjonsmodul som oversetter mellom internt format og EDIFACT-segmenter
• Mapping-oppsett i tråd med mottakerens spesifikasjon
• Sikker kommunikasjonsløsning – AS2, SFTP eller VAN
• Validering på både format- og innholdsnivå

Kjedene stiller i tillegg ofte krav om GLN-registrering, definerte MVA- og prisstrukturer, håndtering av kvitteringsmeldinger, og testing med godkjenning før produksjonssetting. De fleste krever at leverandøren dokumenterer korrekt validering i et eget testmiljø før tilgang til produksjon gis.

Hvordan sikres etterlevelse i EDI FACT?

Etterlevelse følger av strukturert validering, testing og bruk av kvitteringsmeldinger. Valideringen skjer på tre nivåer:

Nivå	Hva som kontrolleres	Hva som feiler
Syntaks	EDIFACT-struktur og segmentrekkefølge	Ugyldig segment, feil rekkefølge, manglende UNT
Forretningsregler	Obligatoriske felter og koder etter kjedens krav	Manglende GLN, ugyldig MVA-kode
Datakonsistens	Produktnummer, mengder og prislogikk	GTIN som ikke finnes i katalogen, sum som ikke stemmer

Feiler en melding, blir den avvist. Leverandøren mottar en feilmelding som peker på hvilket segment eller dataelement som er feil, og må korrigere før ny innsending.

Kvitteringene kommer i to former: CONTRL bekrefter at meldingen er syntaktisk gyldig, mens APERAK rapporterer feil oppstått i mottakerens applikasjon etter at syntaksen er godkjent. En melding kan altså passere CONTRL og likevel avvises via APERAK.

Løpende etterlevelse krever overvåking av meldingslogger, feilmeldinger og kvitteringsstatus. Når en kjede oppdaterer implementasjonsguiden sin, må endringene implementeres før frist for å unngå driftsavbrudd.

Hvorfor krever norske kjeder EDIFACT fra leverandører?

Kjedene håndterer transaksjonsvolumer som ikke lar seg behandle manuelt. Standardisert meldingsutveksling gjør det mulig å ta imot ordre, kontrollere produkt- og prisdata, og validere fakturaer før betaling – uten menneskelig inngripen i normalflyten.

For leverandøren er konsekvensen at EDI ikke er en effektiviseringsøvelse, men et vilkår for å handle. Manglende eller feilaktig oppsett kan gi:

• Forsinket ordrebehandling
• Avviste fakturaer og forlenget betalingstid
• Avvik i lagerbeholdning mellom partene
• Midlertidig stans i handelen inntil oppsettet er rettet

Fungerer oppsettet, går ordre, leveranser og fakturaer gjennom uten manuell oppfølging. Feiler noe i valideringen, stopper flyten umiddelbart. Det er denne binære karakteren som gjør riktig oppsett og løpende overvåking viktig.

Hvorfor er EDI FACT påkrevd for leverandører?

EDI FACT er en forutsetning for effektiv ordrebehandling, lagerstyring og økonomisk avstemming mellom leverandør og kjede.

Varehandel i Norge er avhengig av automatiserte prosesser. Manuell dokumentutveksling skaper forsinkelser og øker risikoen for feil. EDI FACT sikrer strukturert og standardisert kommunikasjon som er tilpasset kjedens ERP- og lagersystemer.

Manglende etterlevelse kan føre til:

• Forsinket ordrebehandling

• Avviste fakturaer

• Avvik i lagerbeholdning

• Midlertidig stans i handel

Standardisert EDI-kommunikasjon gjør det mulig for kjedene å håndtere store transaksjonsvolumer med minimal manuell inngripen. For leverandøren betyr dette forutsigbar drift og stabil elektronisk samhandel.

Hvordan støtter Kundan implementering av EDI FACT?

Kundan leverer EDI-integrasjon for leverandører som handler med norske dagligvare- og elektronikkjeder. Arbeidet tar utgangspunkt i mottakerens spesifikasjon og leverandørens eksisterende systemer.

Vi bistår med:

• Analyse av kjedens implementasjonsguide
• Oppsett av ERP-til-EDI-mapping
• Konfigurasjon av meldinger (ORDERS, ORDRSP, DESADV, INVOIC, INVRPT)
• Implementering av valideringsregler
• Oppsett av sikker kommunikasjon (AS2, SFTP, VAN)
• Testing og onboarding mot kjeden
• Overvåking og håndtering av feilmeldinger i drift

Skal du etablere EDI mot en ny kjede, eller opplever avviste meldinger, fakturafeil og forsinkelser i et eksisterende oppsett, er en gjennomgang av mapping og valideringsregler normalt første steg.

Trenger du en stabil og godkjent EDI FACT-løsning?

Hvis du skal etablere EDI mot en norsk kjede – eller opplever avviste meldinger, fakturafeil eller forsinkelser – bør implementeringen gjennomgås grundig.

Kundan bistår leverandører med:

• Analyse av kjedens spesifikasjoner

• Korrekt mapping og oppsett

• Testing og godkjenning

• Stabil produksjonssetting

• Løpende oppfølging og feilhåndtering

Ta kontakt for en uforpliktende gjennomgang av din EDI FACT-løsning.

Det er enklere å gjøre det riktig fra start enn å rette opp feil i etterkant.

Spørsmål og svar

Ofte stilte spørsmål

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

Hva er forskjellen mellom EDI FACT og EDIFACT?

Det er ingen forskjell. EDIFACT er ett ord, og «EDI FACT» er bare en vanlig skrivemåte av samme forkortelse. Navnet står for Electronic Data Interchange for Administration, Commerce and Transport, og hele forkortelsen hører sammen. Det finnes heller ingen egen norsk EDIFACT-variant. Det som varierer, er implementasjonen: EANCOM er GS1s delsett av UN/EDIFACT for varehandel, og hver kjede publiserer i tillegg sin egen implementasjonsguide som angir hvilke segmenter og koder som er obligatoriske.

Hva er forskjellen mellom EDI og EDIFACT?

EDI er den generelle metoden for elektronisk dokumentutveksling mellom systemer, uavhengig av format. EDIFACT er én bestemt meldingsstandard som definerer hvordan dataene skal struktureres og tolkes. En virksomhet kan altså drive med EDI uten å bruke EDIFACT – for eksempel via EDI XML eller EHF over Peppol. I norsk dagligvarehandel er EDIFACT, gjennom EANCOM, likevel det mest utbredte formatet for ordre- og leveransemeldinger.

Hvilke meldinger kan sendes med EDIFACT?

De vanligste er ORDERS for innkjøpsordre, ORDRSP for ordrebekreftelse, DESADV for pakkseddel og forsendelsesmelding, og INVOIC for faktura og kreditnota. I tillegg brukes INVRPT for lagerstatus og PRICAT for pris- og produktkatalog. Mottakeren returnerer CONTRL som teknisk kvittering og APERAK ved applikasjonsfeil. Hvilke meldinger som er aktuelle, avhenger av hva den enkelte handelspartneren krever.

Hvilke systemer trenger en leverandør for å bruke EDIFACT?

Leverandøren trenger et ERP- eller lagersystem som inneholder transaksjonsdataene, en EDI-konverter eller integrasjonsplattform som oversetter mellom internt format og EDIFACT-segmenter, en mapping mellom ERP-felter og segmenter, og en sikker kommunikasjonskanal som AS2, SFTP eller VAN. I tillegg må virksomheten ha GLN på sine lokasjoner og GTIN på varene, siden disse identifikatorene brukes i selve meldingene.

Hvordan er en EDIFACT-melding bygd opp?

En EDIFACT-melding består av segmenter med faste treboks-koder, i en definert rekkefølge. UNB og UNZ rammer inn utvekslingen, UNH og UNT rammer inn den enkelte meldingen. BGM angir dokumenttype og nummer, DTM inneholder datoer, NAD identifiserer partene med GLN, LIN angir varelinjen med GTIN, og QTY, PRI og TAX inneholder henholdsvis antall, pris og MVA. Hvert segment består av dataelementer med definert format og lengde.

Hva skjer hvis en EDIFACT-melding avvises?

Meldingen blir ikke behandlet, og avsenderen mottar en kvittering som peker på feilen. CONTRL rapporterer syntaksfeil – ugyldig segment, feil rekkefølge, manglende avslutning. APERAK rapporterer feil som oppstår i mottakerens applikasjon etter at syntaksen er godkjent, for eksempel et GTIN som ikke finnes i katalogen. Feilen må rettes og meldingen sendes på nytt. Gjentatte avvisninger kan gi forsinket betaling, og i noen tilfeller gebyr.

Hvorfor krever norske varekjeder EDIFACT fra leverandører?

Kjedene håndterer transaksjonsvolumer som ikke lar seg behandle manuelt. Standardisert meldingsutveksling gjør det mulig å motta ordre automatisk, kontrollere produkt- og prisdata, og validere fakturaer før betaling. For leverandøren betyr det færre avviste meldinger, raskere transaksjonsbehandling og mer forutsigbar drift – men også at oppsettet må være riktig fra start, siden flyten stopper helt når valideringen feiler.

Oppsummering

Riktig mapping og validering avgjør om flyten går gjennom eller stopper helt.

EDIFACT er den internasjonale standarden; «EDI FACT» er samme sak, skrevet i to ord.

I varehandelen brukes EANCOM, GS1s delsett av UN/EDIFACT, med GTIN og GLN som identifikatorer.

Hver kjede publiserer sin egen implementasjonsguide, og onboarding må gjøres per handelspartner.

Meldinger valideres på syntaks, forretningsregler og datakonsistens, og kvitteres med CONTRL og APERAK.