Hva er EDI-validering?

EDI-validering er kontrollen som avgjør om en EDI-melding godtas eller avvises. Meldingen prøves mot syntaksregler, strukturkrav, kodeverk og handelspartnerens forretningsregler før den behandles videre. Består meldingen, går den til bokføring eller sending. Feiler den, stoppes den, og avsenderen får en feilmelding som peker på hvilket segment eller felt som er årsaken.

Nøkkelpunkter:

• Meldinger som feiler, bokføres ikke, og hindrer dermed at feil data sprer seg videre i lager og regnskap.
• Validering skjer på fire punkter: ved opprettelse, før sending, ved mottak og i testfasen før produksjonssetting.
• Kontrollene dekker seks regelkategorier, fra tegnsett til forretningslogikk.
• En melding kan være syntaktisk feilfri og likevel avvises på forretningsregler.
• Mottakeren kvitterer med CONTRL for syntaksfeil og APERAK for applikasjonsfeil.
• Valideringsreglene konfigureres per handelspartner, selv når samme standard brukes.

Hvordan fungerer EDI-validering?

Hvilke typer regler kontrolleres under EDI-validering?

Når skjer EDI-validering?

Tidspunkt	Hvem validerer	Hva det fanger
Ved opprettelse i avsendersystemet	Avsender	Manglende data i ERP før meldingen bygges
Før sending	Avsender	Format- og regelbrudd mot mottakerens spesifikasjon
Ved mottak	Mottaker	Alt avsenderen ikke fanget, pluss mottakerens egne data
I testfasen	Begge	Systematiske feil i mappingen, før produksjonssetting

Utgående validering handler om å oppfylle mottakerens krav før meldingen forlater huset. Innkommende validering handler om det motsatte: å beskytte egne systemer mot feil i eksterne data.

De fleste norske kjeder krever at leverandøren dokumenterer korrekt validering i et testmiljø før tilgang til produksjon gis. Testfasen er ofte den lengste delen av en onboarding.

Hvilke systemer utfører EDI-validering?

Valideringen kjøres av EDI-konvertere, integrasjonsplattformer eller gateway-løsninger hos handelspartneren. Disse systemene lagrer regelsettene, utfører kontrollene, genererer kvitteringsmeldinger og produserer feilmeldinger ved avvik.

Et poeng som ofte undervurderes: valideringslogikken konfigureres per handelspartner. To kjeder kan bruke samme EDI-standard og likevel ha ulike krav til hvilke segmenter som er obligatoriske, hvilke kodeverk som gjelder, og hvor strenge forretningsreglene er. Et oppsett som passerer valideringen hos én mottaker, kan avvises hos den neste uten at noe er galt med meldingen i seg selv.

Valideringsmotoren fungerer dermed som et kontrollag mellom dokumentopprettelse og operativ behandling, med ett regelsett per relasjon.

Hva skjer når en EDI-melding feiler validering?

Meldingen stoppes, og avsenderen varsles med en strukturert feilmelding. I EDIFACT-baserte oppsett skjer varslingen gjennom to meldingstyper:

• CONTRL – teknisk kvittering. Bekrefter at meldingen er syntaktisk gyldig, eller rapporterer at den ikke er det.
• APERAK – applikasjonskvittering. Rapporterer feil som oppstår i mottakerens forretningssystem etter at syntaksen er godkjent.

En melding kan altså passere CONTRL og likevel avvises via APERAK. Får du CONTRL uten APERAK, betyr det som regel at meldingen er teknisk mottatt, men ikke nødvendigvis behandlet.

Selve avvisningen består av fire deler:

1. Identifisering av hvilket segment eller felt som feilet
2. Beskrivelse av regelbruddet, normalt med en feilkode
3. Varsling til avsender
4. Stans i videre behandling

Avsenderen må rette dataene, generere meldingen på nytt og sende den igjen. Det avgjørende er at meldinger som feiler, ikke bokføres i lager-, regnskaps- eller logistikksystemer. Feilen forblir isolert til den ene meldingen i stedet for å forplante seg.

Ved gjentatte avvisninger ligger årsaken sjelden i den enkelte meldingen. Da er det som regel mappingen eller masterdata som må gjennomgås.

Hvorfor er validering nødvendig i varehandelen?

I integrerte handelsmiljøer skjer ordrebehandling, lageroppdatering, fakturering og rapportering automatisk. Ingen leser meldingene manuelt. Dermed er valideringen den eneste kontrollen som står mellom en feil i dataene og en feil i driften.

Systemene er avhengige av korrekte produktidentifikatorer, riktig pris- og avgiftsinformasjon, gyldige ordrereferanser og strukturert rapporteringsdata. Uvaliderte meldinger kan forstyrre:

• Lagersynkronisering – beholdningen avviker mellom leverandør og kjede
• Økonomisk avstemming – fakturaer matcher ikke ordre og mottak
• Ordreoppfyllelse – leveranser bygger på feil antall eller feil vare
• Regulatorisk rapportering – underlaget som skal dokumenteres, er feil

Verdien av streng validering ligger i at feilen fanges på det billigste tidspunktet. En avvist melding koster minutter å rette. Den samme feilen oppdaget ved fakturakontroll fire uker senere koster en kreditnota, en purring og en telefonsamtale.

Oppsummering

• Meldinger som feiler, bokføres ikke, og feilen holdes isolert.
• EDI-validering kontrollerer at meldinger oppfyller strukturelle, datamessige og forretningsmessige krav.
• Validering skjer ved opprettelse, før sending, ved mottak og i testfasen.
• Seks regelkategorier kontrolleres, fra tegnsett til forretningslogikk.
• CONTRL dekker syntaks, APERAK dekker applikasjonsnivå. Én godkjenning betyr ikke at begge er bestått.
• Reglene konfigureres per handelspartner, så et oppsett som virker mot én kjede kan feile mot neste.

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-validering og EDI-mapping?

Mapping handler om å oversette data mellom interne systemer og EDI-formatet: hvilket ERP-felt som havner i hvilket segment. Validering handler om å kontrollere resultatet: om meldingen følger standarden og oppfyller handelspartnerens regler. Mapping sørger for at dataene havner riktig sted; validering sørger for at de faktisk er korrekte. Feil i mappingen gir som regel systematiske valideringsfeil, altså samme feil på hver melding, mens feil i dataene gir sporadiske avvisninger.

Kan en EDI-melding være teknisk korrekt og likevel feile valideringen?

Ja, og det er den vanligste typen avvisning i et etablert oppsett. En melding kan ha helt korrekt syntaks og struktur, men bryte forretningsregler eller mangle obligatoriske felt. Typiske eksempler er et GTIN som ikke finnes i mottakerens varekatalog, en MVA-kode utenfor gyldig kodeverk, et ordrenummer som ikke kan gjenfinnes, eller en linje der antall ganget med pris ikke stemmer med linjebeløpet. Dette er grunnen til at validering ikke bare er en teknisk kontroll, men også en forretningsmessig kvalitetssikring.

Hva er forskjellen på CONTRL og APERAK?

CONTRL er en teknisk kvittering som bekrefter eller avviser meldingens syntaks. APERAK er en applikasjonskvittering som rapporterer feil oppstått i mottakerens forretningssystem etter at syntaksen er godkjent. En melding kan passere CONTRL og likevel avvises via APERAK, for eksempel fordi et varenummer er ukjent. I praksis betyr det at mottatt CONTRL ikke er en bekreftelse på at meldingen er behandlet, bare på at den var lesbar.

Hvorfor er streng validering kritisk i varehandel og distribusjon?

Fordi ingen leser meldingene manuelt. Ordre, lageroppdateringer, fakturering og rapportering skjer automatisk, og valideringen er den eneste kontrollen mellom dataene og driften. Uvaliderte meldinger kan gi feil i lagerbeholdning, avvik i økonomisk avstemming, forsinket ordreoppfyllelse og feil underlag for regulatorisk rapportering. Kostnaden ved å fange feilen ved sending er minutter; kostnaden ved å fange den ved fakturakontroll er en kreditnota og manuell oppfølging.

Hvorfor avvises meldingene våre hos én kjede, men ikke hos en annen?

Fordi valideringsreglene konfigureres per handelspartner. To mottakere kan bruke samme EDI-standard og likevel ha ulike krav til hvilke segmenter som er obligatoriske, hvilke kodeverk som er gyldige, og hvor strenge forretningsreglene er. Hver kjede publiserer sin egen implementasjonsguide. Et oppsett som er godkjent mot én mottaker må derfor testes på nytt mot neste, og onboarding gjøres per relasjon.

Hva gjør vi hvis samme feil kommer igjen på hver melding?

Systematiske avvisninger peker sjelden på den enkelte transaksjonen. Kommer samme feilkode på alle meldinger av en type, ligger årsaken normalt i mappingen eller i masterdata. Sjekk først om feltet i det hele tatt er mappet, deretter om verdien finnes i ERP-et, og til slutt om kodeverket stemmer med mottakerens guide. Sporadiske avvisninger på enkeltmeldinger peker derimot på datakvalitet i den enkelte ordren eller fakturaen.

Ønsker dere å gjennomgå et eksisterende valideringsoppsett, eller sikre at meldingsutvekslingen oppfyller handelspartnerens krav? Kundan bistår med analyse, testing og teknisk implementering.