EDI mot 3PL og WMS: integrasjon for e-handelslager

EDI mot 3PL og WMS betyr at to atskilte dataflyter må håndteres samtidig: meldinger til kjeden (ORDERS, ORDRSP, DESADV, INVOIC) og data mellom deg og lageroperatøren. Lageret snakker aldri direkte med kjeden, så du er fortsatt avsender og ansvarlig for begge lag selv når driften er satt bort.

Setter du bort lageret, flytter du ikke ansvaret. Du legger til et ledd.

Det er den enkleste måten å si det på, og det er også det som oftest blir undervurdert når en produsent går fra eget lager til en tredjepartsoperatør. Varene håndteres av noen andre, men kjeden holder fortsatt deg ansvarlig for at pakkseddelen stemmer og at leveransen kommer fram som avtalt.

Om det fungerer, avgjøres nesten alltid av integrasjonen mellom systemet ditt og lagerets, og av hvor godt du forsto den før du signerte.

To integrasjonslag som blandes sammen

Dette er kjernen, og forvirringen her forklarer de fleste skuffelsene.

Lag 1: mellom deg og kjøperen. Kjeden sender ORDERS (bestilling). Du svarer med ORDRSP (ordrebekreftelse), sender DESADV (pakkseddel/forsendelsesvarsel) når varene går, og INVOIC (faktura) når de skal betales. Kravene står i kjedens egen gjeldende implementasjonsguide, og de gjelder deg som leverandør.

Lag 2: mellom deg og lageret. Du forteller lageret hva som skal plukkes og sendes. Lageret forteller deg hva som faktisk ble sendt, hva som kom inn, og hva som ligger på hylla. Dette er en avtale mellom dere to. Ingen kjede er involvert.

Lageret snakker ikke med kjeden. Det gjør du.

Det betyr at 3PL-operatøren leverer innholdet du trenger for å oppfylle lag 1, men de oppfyller det ikke på dine vegne. Data om hva som ble pakket kommer fra dem. Meldingen til kjeden er fortsatt din, med dine identifikatorer og referanse til din ordre.

Blander du de to lagene, ender du med å tro at «3PL-en tar seg av EDI-en». Det gjør de sjelden, i hvert fall ikke slik du tenker.

Hva «vi støtter EDI» faktisk kan bety

Dette er verdt å be om presisering på i første møte, for uttrykket brukes om minst tre ulike ting.

Vi kan ta imot plukkinstrukser elektronisk. Det vanligste. De har et grensesnitt for å motta ordrelinjer fra deg, ofte via fil eller API, av og til via EDI-melding. Dette er lag 2, og det er nyttig, men det sier ingenting om kjedekravene dine.

Vi kan generere forsendelsesdata i strukturert form. Bedre. De returnerer hva som faktisk ble pakket, med kollinumre, slik at du kan bygge en korrekt DESADV.

Vi kan sende meldinger til kjeden i ditt navn. Sjeldnere, og det som faktisk kreves hvis du vil at de skal håndtere lag 1. Da må de kunne bruke dine identifikatorer, følge kjedens gjeldende implementasjonsguide og gå gjennom kjedens test- og godkjenningsprosedyre.

De tre høres like ut i en salgspresentasjon. De er helt ulike i drift. Spør hvilken av dem det dreier seg om, og be om å få se hvordan det er løst for en eksisterende kunde med samme kjedekrav som deg.

Hva som må flyte mellom deg og lageret

Uansett hvilken teknologi som velges, er det disse dataene som må gå begge veier.

Fra deg til lageret: varestamdata med GTIN og pakningshierarki, innmelding av varer som kommer inn, plukk- og sendeinstrukser med mottakeradresse og leveringskrav, og eventuelle spesialkrav per kjede.

Fra lageret til deg: bekreftelse på mottatte varer, hva som faktisk ble plukket og sendt, kollinumre, løpende beholdning, avvik og returer.

Beholdningen er den som skaper mest støy i praksis. Selger du mot en beholdning som oppdateres én gang i døgnet, selger du mot gårsdagens lager. For en produsent som både leverer til kjeder og selger direkte, er det nok til å skape oversalg.

Kollinumrene er den andre. DESADV bygger på dem, og de må genereres etter en struktur kjeden godtar. Avklar tidlig hvem som genererer dem, deg eller lageret, og at nummerserien ikke kolliderer.

Det som ofte glemmes for mat- og drikkeprodusenter

En 3PL bygget for generell netthandel håndterer esker. Det er ikke helt det samme som å håndtere næringsmidler.

Batch og holdbarhet. Kan lageret plukke på batchnivå, og styre etter holdbarhetsdato? Uten det mister du sporbarhet, og du kan ikke svare presist ved en tilbakekalling.

Riktig rotasjon. Plukkes eldste vare først, og kan det dokumenteres?

Temperatur og håndtering. Krav som følger av produktet, og som må stå i avtalen.

Særavgift. For drikkevarer henger avgiftshåndtering sammen med hva som faktisk er utlevert og når. Ligger den informasjonen hos lageret, må den tilbake til deg i en form du kan rapportere fra.

Pant og retur. Håndteres det i det hele tatt, og hvordan registreres det?

Dette er spørsmål som ikke stilles i en generisk 3PL-vurdering, og som er dyre å oppdage etterpå.

Hva du bør avklare før du signerer

1. Hvilket av de tre nivåene av «EDI-støtte» tilbyr de? Be om et konkret svar, ikke et ja.
2. Hvem genererer kollinumre, og etter hvilken struktur?
3. Hvor ofte oppdateres beholdningen, og hvordan kommer den inn i systemet ditt?
4. Hvem står som avsender på meldingene til kjeden? Og er identifikatorene dine, ikke deres?
5. Kan de plukke på batch og holdbarhet?
6. Hva skjer når en kjede endrer implementasjonsguiden sin? Hvem tilpasser, og hvem betaler?
7. Hvem får avvisningsmeldingen når noe feiler? Går den til lagerets innboks, kan det gå dager før du vet det.
8. Hva skjer med dataene hvis dere avslutter samarbeidet? Både beholdningshistorikk og forsendelsesdokumentasjon.

Punkt åtte blir nesten aldri stilt, og det er det som gjør en overgang vanskelig senere.

Kort oppsummert

• Å sette bort lageret flytter arbeidet, ikke ansvaret. Kjeden forholder seg fortsatt til deg.
• Det er to integrasjonslag: mellom deg og kjøperen, og mellom deg og lageret. Lageret snakker ikke med kjeden.
• «Vi støtter EDI» kan bety tre helt ulike ting. Be om presisering.
• Beholdningsoppdatering og kollinumre er de to tekniske detaljene som oftest skaper problemer.
• For mat og drikke er batch, holdbarhet, særavgift og pant spørsmål en generisk 3PL sjelden har svar på.
• Avklar hvem som eier meldingene, dataene og tilpasningsjobben før avtalen signeres.

Spørsmål og svar

Ofte stilte spørsmål om EDI mot 3PL og WMS: integrasjon for e-handelslager

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

Kan 3PL-operatøren sende DESADV til kjeden for oss?

Noen kan. Det forutsetter at de kan sende med dine identifikatorer, følge kjedens gjeldende implementasjonsguide og gjennomføre kjedens test- og godkjenningsprosedyre. Spør konkret om de har gjort det før mot den kjeden du leverer til, og ikke bare om de «støtter EDI».

Trenger vi et eget WMS når 3PL-en har sitt?

Som regel ikke. Poenget er at du må ha en beholdning og en ordreflyt du kan selge og fakturere fra, som stemmer med det lageret faktisk har. Om det ligger i et eget WMS eller i systemet du allerede bruker, er mindre viktig enn at de to henger sammen.

Hva er forskjellen på et WMS og et ERP i denne sammenhengen?

Et WMS styrer hva som skjer inne på lageret: mottak, plassering, plukk og pakking. Et ERP styrer handelen: ordre, beholdning på et overordnet nivå, fakturering og regnskap. Ved bruk av 3PL er WMS-et som regel lagerets, mens handelen fortsatt er din.

Hvor ofte bør beholdningen oppdateres?

Så ofte som salget ditt krever. Selger du bare i faste bestillingsvinduer mot kjeder, kan daglig være nok. Selger du også direkte, bør oppdateringen skje nær sanntid, ellers selger du varer som allerede er plukket.

Hva skjer hvis lageret sender feil?

Kjøperen forholder seg til deg, fordi avtalen er deres med deg. Hvordan ansvaret fordeles mellom deg og lageret følger av avtalen dere har, og det bør være avklart før det oppstår.

Skal du vurdere et lageroppsett?

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 følger kundene gjennom hele EDI-onboardingen.

Det som avgjør om et 3PL-samarbeid fungerer, er sjelden lageret i seg selv. Det er om ordre, beholdning og forsendelsesdata henger sammen på din side, slik at lageret kan levere data inn i en flyt som allerede virker.

Ønsker du heller at noen andre drifter både systemet og selve lagerdriften, er dette noe Local Logistics tilbyr som en kombinert løsning.

Vurderer du å sette bort lageret, er det verdt å gå gjennom dataflyten før avtalen signeres. Ta en gjennomgang med oss, så ser vi på hva som må være på plass.