Hva er EDI-testing?

EDI-testing er verifiseringsprosessen som bekrefter at en leverandørs EDI-meldinger oppfyller handelspartnerens tekniske og forretningsmessige krav før produksjonssetting. Meldingene sendes i et eget testmiljø, valideres mot partnerens regelsett, og korrigeres til alle påkrevde meldingstyper er godkjent. Først da åpnes produksjonskommunikasjon. Testfasen fungerer som kontrollbarrieren mellom konfigurasjon og aktiv handel.

Nøkkelpunkter:

• Godkjenning er ikke permanent: meldinger kan avvises i produksjon hvis reglene endres.
• Hver meldingstype må bestå valideringen separat, ikke som samlet pakke.
• Testmiljøet speiler produksjonens valideringslogikk, men påvirker ikke reelle handelsdata.
• Kontrollene dekker syntaks, obligatoriske felt, identifikatorer og forretningsregler.
• Testresultater kommer som kvitteringsmeldinger og valideringsrapporter med feilkoder.
• Testing gjelder også eksisterende leverandører som gjør vesentlige systemendringer.

Hvorfor kreves EDI-testing?

Hvem må gjennomføre EDI-testing?

Hvilke meldinger inngår i testløpet?

Testomfanget defineres av mottakerens tekniske dokumentasjon. Et typisk løp omfatter:

Melding	Hva som testes	Retning
ORDERS	Innlesing og tolkning av innkjøpsordre	Inn
ORDRSP	Generering av ordrebekreftelse	Ut
DESADV	Forsendelsesmelding med korrekte identifikatorer	Ut
INVOIC	Faktura med referanser og avgiftslogikk	Ut
Rapporterings- og etterlevelsesmeldinger	Der mottakeren krever det	Ut

Hver meldingstype valideres separat. En leverandør kan altså ha godkjent ORDERS og likevel stå fast på INVOIC, som er den meldingen med flest avhengigheter til de øvrige.

Hvilket testmiljø brukes?

Handelspartneren stiller normalt et dedikert testmiljø til disposisjon. Miljøet:

• Speiler produksjonsmiljøets valideringslogikk
• Tar imot testmeldinger uten å påvirke reell handel
• Returnerer strukturerte tilbakemeldinger og feilmeldinger

Skillet mellom test og produksjon er det som gjør det trygt å feile. En avvist testmelding koster ingenting; den samme feilen i produksjon stopper en faktisk leveranse eller betaling.

Verdt å merke seg: testmiljøet speiler valideringslogikken, men ikke nødvendigvis masterdataene. Et varenummer som finnes i test kan mangle i produksjon, og omvendt. Det er en vanlig kilde til avvisninger rett etter produksjonssetting.

Hvilke kontroller gjennomføres under testing?

Valideringen skjer på flere nivåer, i stigende rekkefølge fra det tekniske til det forretningsmessige. Se EDI-validering for hvordan nivåene fungerer i detalj.

Nivå	Hva som kontrolleres	Typisk feil
Syntakskontroll	Meldingsstruktur, segmentrekkefølge, kvalifikatorer og skilletegn	Ugyldig struktur, manglende avslutning
Obligatoriske felt	Påkrevde identifikatorer og segmenter, format på datoer og beløp	Manglende lokasjonskode, feil datoformat
Identifikatorverifisering	Godkjente varenummer eller GTIN, leverandør-ID, lokasjonskoder	GTIN som ikke finnes i mottakerens katalog
Forretningsregler	Samsvar mellom ordre, forsendelse og faktura, mengder, pris- og avgiftslogikk	Fakturert mengde avviker fra levert

Rekkefølgen har praktisk betydning. Feiler meldingen på syntaksnivå, sier feilmeldingen ingenting om innholdet, fordi valideringen aldri kom så langt. Bare meldinger som oppfyller alle nivåene blir godkjent.

Hvordan mottar leverandøren testresultater?

Resultatene formidles gjennom kvitteringsmeldinger og valideringsrapporter. I EDIFACT-baserte oppsett er kvitteringene CONTRL for syntaks og APERAK for applikasjonsfeil; i XML-baserte oppsett brukes partnerens egne rapportformater.

Rapportene viser:

• Hvilke meldinger som er godkjent
• Hvilke som er avvist
• Feilkoder for hvert avvik
• Hvilket segment eller felt som må korrigeres

Feil må rettes i kilden, ikke i den enkelte meldingen, før ny innsending. Retter man bare testmeldingen, går den gjennom, mens produksjonsoppsettet fortsatt er feil.

Hva skjer hvis meldinger ikke består testen?

Ved avvisning returneres valideringsfeilene, konfigurasjonen eller datagrunnlaget må korrigeres, korrigerte meldinger sendes på nytt, og en ny valideringsrunde gjennomføres. Testingen fortsetter til alle påkrevde meldinger er godkjent.

Gjentatte avvik bør ikke behandles som enkelthendelser. Kommer samme feilkode tilbake runde etter runde, ligger årsaken normalt i mappingen eller i masterdata, ikke i testmeldingen. Å rette symptomet per melding forlenger testløpet uten å løse noe.

Gjentatte feil forsinker produksjonsgodkjenning, og i praksis er det testfasen som avgjør hvor lang en onboarding blir.

EDI-testing mot Vinmonopolet

Vinmonopolet krever gjennomført og godkjent testing før produksjonskommunikasjon åpnes. Testingen inngår i den samlede leverandør-onboardingen.

Merk formatet: Vinmonopolet krever full EDI XML-kommunikasjon av alle grossister, ikke EDIFACT eller EANCOM. En leverandør som allerede har et EDIFACT-oppsett mot dagligvarekjedene kan derfor ikke gjenbruke det. Mapping, referanselogikk og validering må bygges særskilt. Se Vinmonopolet EDI-krav for hva fakturameldingen konkret må inneholde.

Før første testinnsending bør disse punktene være avklart:

• Gjeldende versjon av XML-schemaet
• At masterdata er korrekt registrert hos Vinmonopolet
• Referansemapping mellom ORDERS, ORDRSP, DESADV og faktura
• MVA- og særavgiftsregler for de aktuelle produktene
• Feltmapping mellom ERP-systemet og XML-strukturen
• Rutiner for håndtering av avvisninger i drift

Detaljerte krav følger av Vinmonopolets gjeldende implementeringsguide, som er den eneste autoritative kilden. Kontroller alltid mot gjeldende versjon.

Når er EDI-testingen fullført?

Testingen anses som fullført når:

• Alle påkrevde meldinger er validert uten feil
• Sikker kommunikasjon fungerer stabilt over flere innsendinger
• Kvitteringsmeldinger håndteres korrekt i begge retninger
• Formell produksjonsgodkjenning er gitt av handelspartneren

Det tredje punktet glemmes ofte. Å sende en gyldig melding er ikke nok; leverandøren må også kunne lese og handle på kvitteringene som kommer tilbake. Et oppsett som ignorerer APERAK-meldinger vil ikke oppdage at fakturaer avvises i produksjon.

Hva endres etter godkjent testing?

Etter godkjenning får leverandøren tilgang til produksjonsmiljøet. Innkjøpsordre mottas elektronisk, ordrebekreftelser, forsendelsesmeldinger og fakturaer sendes via EDI, og manuell håndtering av de strukturerte dokumentene opphører.

Fra dette punktet må all dokumentutveksling følge det godkjente oppsettet. Meldinger sendt utenom, eller i et annet format, behandles ikke.

Hvilke løpende krav gjelder etterpå?

Godkjenning er ikke et sluttpunkt. Etter produksjonssetting må leverandøren:

• Overvåke meldingsavvisninger fortløpende
• Vedlikeholde mappingen når felter eller kodeverk endres
• Oppdatere oppsettet ved endringer i mottakerens spesifikasjoner
• Reteste ved større ERP- eller middleware-endringer
• Opprettholde samsvar med gjeldende valideringsregler

Løpende etterlevelse er en forutsetning for å beholde produksjonstilgangen. Den vanligste årsaken til at et fungerende oppsett plutselig feiler, er en endring på den ene siden som ikke er speilet på den andre.

Hvordan bistår Kundan med EDI-testing?

Vi følger leverandører gjennom testløpet, fra teknisk mapping til produksjonsgodkjenning:

• Konfigurasjon av mapping mot mottakerens meldingsformat
• Klargjøring av testmeldinger
• Analyse av valideringsfeil og feilkoder
• Koordinering av korrigeringsrunder
• Kontroll av kommunikasjonsoppsett
• Planlegging av produksjonssetting

Det meste av arbeidet i et testløp går med til å tolke feilkoder og finne ut hvor i kjeden avviket faktisk oppstår. Det er der en strukturert prosess sparer mest tid.v.

Oppsummering

• EDI-testing er obligatorisk før produksjonssetting hos handelspartnere som krever det.
• Testingen validerer struktur, obligatoriske felt, identifikatorer og forretningsregler.
• Et eget testmiljø speiler produksjonens valideringslogikk uten å påvirke reell handel.
• Alle meldingstyper må bestå individuelt.
• Produksjon åpnes først etter formell godkjenning.
• Mot Vinmonopolet gjelder EDI XML, ikke EDIFACT.
• Løpende etterlevelse og retesting kreves for å beholde produksjonstilgang.

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 et EDI-testmiljø?

Et EDI-testmiljø er en separat instans hos handelspartneren hvor leverandører kan sende meldinger uten å påvirke reelle handelsdata. Miljøet speiler produksjonens valideringslogikk og returnerer de samme feilkodene, slik at oppsettet kan verifiseres før det tas i bruk. Merk at testmiljøet speiler valideringsreglene, men ikke nødvendigvis masterdataene: et varenummer som finnes i test kan mangle i produksjon.

Må alle EDI-meldinger testes før produksjon?

Ja. Meldinger som ORDERS, ORDRSP, DESADV og INVOIC må bestå både teknisk og forretningsmessig validering hver for seg. Godkjenning av én meldingstype gir ikke klarering for de andre. INVOIC er normalt den vanskeligste, fordi den har referanseavhengigheter til alle de foregående meldingene i kjeden.

Kan meldinger avvises etter at testingen er godkjent?

Ja. Produksjonsgodkjenning bekrefter at oppsettet var korrekt på godkjenningstidspunktet, ikke at det vil forbli det. Meldinger som ikke oppfyller gjeldende valideringsregler avvises også i produksjon. Endringer i handelspartnerens implementasjonsguide, i egne masterdata eller i ERP-systemet kan alle utløse avvisninger uten at noen har rørt EDI-oppsettet.

Hvor lang tid tar et testløp?

Det varierer med antall meldingstyper, hvor godt masterdata er ryddet, og hvor raskt korrigeringsrunder kan gjennomføres på begge sider. I praksis er det sjelden selve konfigurasjonen som tar tid, men rundene med avvisning, feilsøking og ny innsending. Å avklare schemaversjon og masterdata før første innsending er det enkelttiltaket som kutter mest tid.

Hvilket format krever Vinmonopolet i testing?

Vinmonopolet krever full EDI XML-kommunikasjon av alle grossister, etter sin egen implementasjonsguide. Det er ikke EDIFACT, EANCOM eller EHF over Peppol. En leverandør med et eksisterende EDIFACT-oppsett mot dagligvarekjedene må bygge et separat oppsett mot Vinmonopolet, med egen mapping, referanselogikk og validering.

Må vi teste på nytt hvis vi bytter ERP-system?

Vinmonopolet krever full EDI XML-kommunikasjon av alle grossister, etter sin egen implementasjonsguide. Det er ikke EDIFACT, EANCOM eller EHF over Peppol. En leverandør med et eksisterende EDIFACT-oppsett mot dagligvarekjedene må bygge et separat oppsett mot Vinmonopolet, med egen mapping, referanselogikk og validering.