Ordrestatus og sporing i e-handel vs ORDRSP

Kort svar på e-handel vs ORDRSP: de svarer på to helt ulike spørsmål, og det er derfor de ikke lar seg oversette direkte.

En ordrestatus i en nettbutikk svarer på «hvor er varen min?». En ORDRSP svarer på «kan du levere det jeg bestilte?». Det første handler om forsendelsen, det andre om avtalen.

Bygger du en bestillingsløsning ved siden av kjedehandelen, er dette skillet verdt å forstå før du designer statusvisningen. Ellers ender du med å love kunden informasjon systemet ditt ikke har.

To ulike spørsmål

ORDRSP er ordrebekreftelsen i EDI. Den sendes fra selger til kjøper som svar på en mottatt ordre, og den tar stilling til innholdet linje for linje: kan du levere alt, deler av det, til avtalt pris og til avtalt tid? Det er et kommersielt svar, ikke en oppdatering.

Ordrestatus i e-handel er en tilstand kunden kan se, som regel presentert som en tidslinje: bekreftet, under behandling, sendt, levert. Den oppdateres underveis, og formålet er å berolige kunden slik at de ikke må ta kontakt for å høre hvor bestillingen er.

Den viktigste forskjellen ligger i hva som skjer etterpå. En ORDRSP med endringer er en beskjed om at avtalen ble en annen enn det kjøperen bestilte. En statusoppdatering endrer ingenting kommersielt. Den forteller bare hvor noe befinner seg i prosessen.

Hva skiller dem?

	ORDRSP	Ordrestatus i e-handel
Svarer på	Kan du levere dette?	Hvor er varen min?
Retning	Selgers system til kjøpers system	Selgers system til et menneske
Antall	Én melding, eventuelt en ny ved endring	Løpende oppdateringer
Innhold	Bekreftelse, endring eller avvisning per linje	Tilstand i en prosess
Konsekvens	Endrer hva som faktisk er avtalt	Endrer ingenting, informerer
Frist	Kjøperen setter ofte en svarfrist	Ingen frist utenfra
Hva som skjer ved feil	Ordren stopper eller avvises	Kunden ringer

Linjen om frist overrasker mange som kommer fra netthandel. Kjedene beskriver i sine egne gjeldende implementasjonsguider hvilke meldinger som kreves og hvordan de skal besvares, inkludert forventninger til svar. En uteblitt ORDRSP er ikke en manglende hyggelighet, det er et avvik.

Hvilken EDI-melding svarer til hvilken status?

Her ligger det praktiske svaret for deg som skal vise status til en direktekunde.

En e-handelsstatus slår sammen flere ulike hendelser til én tidslinje. I EDI er de samme hendelsene separate meldinger med hvert sitt formål.

Status kunden ser	Hva den bygger på i EDI
Bestilling mottatt	Ordren er registrert i systemet
Bekreftet	ORDRSP er sendt, med eller uten endringer
Delvis bekreftet	ORDRSP med linjeendring eller restnotering
Pakket og sendt	DESADV er sendt
Sporing tilgjengelig	Kollinumre fra DESADV, koblet mot transportørens sporing
Fakturert	INVOIC er sendt

Poenget: statusen «sendt» kommer ikke fra ORDRSP. Den kommer fra DESADV. Bygger du statusvisningen på ordrebekreftelsen alene, får kunden aldri vite når varen faktisk gikk ut.

Sporing er et eget lag igjen. DESADV forteller hva som ble sendt og på hvilke kolli. Hvor pakken befinner seg underveis vet transportøren, ikke EDI-flyten. Skal kunden se sporing, må kollinummeret kobles videre til transportørens system.

Hva går galt når de behandles likt

Bekreftelsen presenteres som en forsendelse. Kunden ser «bekreftet» og forventer at varen er på vei. Den er bare akseptert.

Delleveranser vises ikke. ORDRSP kan bekrefte fire av seks linjer. Viser statusen bare «bekreftet», oppdager kunden avviket når esken kommer.

Endringen forsvinner. En ORDRSP med endret antall eller dato er kommersielt viktig. Komprimeres den til et grønt hakemerke i portalen, mister kunden informasjonen som betydde noe.

Sporing loves uten dekning. Statusvisningen har et sporingsfelt fordi nettbutikkmalen har det, men ingen har koblet kollinummeret til transportøren. Feltet står tomt, og kunden ringer.

Direktekunder får dårligere informasjon enn kjedene. Kjeden får ORDRSP og DESADV automatisk. Direktekunden får en tidslinje som stopper på «under behandling», fordi ingen koblet de samme hendelsene til portalen.

Det siste er verdt å merke seg. Har du allerede EDI mot kjedene, finnes hendelsene du trenger. De er bare ikke gjort tilgjengelige for den andre kanalen.

Hva du bør avklare

1. Hvilken hendelse utløser hver status kunden ser? Skriv det ned per statustrinn før noe bygges.
2. Hvordan vises en delvis bekreftelse? Dette er det vanligste avviket, og det trenger sin egen visning.
3. Hvor kommer «sendt» fra? Hvis svaret ikke er DESADV eller tilsvarende, er statusen et gjett.
4. Kobles kollinummer videre til transportøren? Og hva vises hvis koblingen mangler?
5. Hva ser kunden når noe feiler? En stoppet ordre trenger en synlig tilstand, ikke stillhet.
6. Får direktekunder samme informasjonsnivå som kjedene? Hvis ikke, hvorfor?
7. Hva skjer ved endring etter bekreftelse? Både kjeden og direktekunden må få vite det, men på hver sin måte.

Punkt fem er det som oftest mangler. En ordre som har stoppet i integrasjonen ser i portalen ut som en ordre som bare tar litt tid.

Hvordan Kundan jobber med dette

Kundan-plattformen dekker EDI, CRM, ordre, lager, fakturering, særavgiftshåndtering og bookingfunksjonalitet, og kombinerer programvare, integrasjoner og operative arbeidsflyter i én plattform. Vi leverer EDI-integrasjoner mot norske kjøperkjeder, blant annet Vinmonopolet, ASKO, COOP, REMA, NorgesGruppen, Megaflis og Optimera, og utvikler nettsider, nettbutikker og skreddersydde digitale løsninger for små og mellomstore bedrifter.

Ligger kjedehandelen og direktesalget i samme flyt, er hendelsene som skal drive statusvisningen allerede der. Da handler det om å bestemme hva kunden skal se, ikke om å bygge et nytt datagrunnlag.

Skal du vise ordrestatus til direktekundene dine, er det verdt å bestemme hvilken hendelse som utløser hvilket trinn før løsningen designes. Ta en gjennomgang med oss, så ser vi på hva flyten din faktisk kan vise.

Spørsmål og svar

Ofte stilte spørsmål om Ordrestatus og sporing i e-handel vs ORDRSP

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

Er ORDRSP det samme som en ordrebekreftelse i en nettbutikk?

Ikke helt. Begge bekrefter at bestillingen er mottatt, men en ORDRSP tar også stilling til om du kan levere det som ble bestilt, linje for linje, og kan endre eller avvise deler av ordren. En automatisk bekreftelses-e-post fra en nettbutikk gjør normalt ikke det.

Kan vi vise sporing til kunden basert på EDI-meldingene?

Delvis. DESADV forteller hva som ble sendt og på hvilke kolli, og kollinummeret er utgangspunktet for sporing. Selve sporingen underveis kommer fra transportøren, så koblingen må gjøres mot deres system.

Hvorfor får kjedene mer informasjon enn direktekundene våre?

Fordi kjedene krever det, og fordi meldingene går automatisk mellom systemer. Direktekunder får bare det noen har valgt å vise dem. Hendelsene finnes som regel allerede.

Må vi sende ORDRSP hvis kunden bestiller i portalen vår?

Nei, ikke som EDI-melding. ORDRSP er en melding mellom systemer i en EDI-utveksling. En portalkunde skal ha den samme informasjonen, men presentert i grensesnittet de bruker.

Hva bør vi vise når en ordre er delvis bekreftet?

Hvilke linjer som er bekreftet, hvilke som er endret eller utgår, og hva som skjer videre med restene. Dette er den statusen som skaper flest henvendelser hvis den skjules.