Hva er INVRPT? Lagerrapport i EDI

INVRPT (Inventory Report) er meldingstypen som brukes til å rapportere lagerbeholdning mellom to parter. Den svarer på ett spørsmål: hva ligger hvor, akkurat nå?

Den skiller seg fra de andre EDI-meldingene på en måte som er verdt å forstå med en gang. ORDERS, DESADV og INVOIC dokumenterer hendelser, altså noe som har skjedd. INVRPT beskriver en tilstand på et gitt tidspunkt. Det høres ut som en detalj, men det er akkurat der de fleste problemene med lagerrapportering oppstår.

Hva er INVRPT?

INVRPT står for Inventory Report, og er en standardisert melding for å sende beholdningsinformasjon fra ett system til et annet.

Til forskjell fra ordre- og fakturameldingene er den ikke knyttet til en enkelt handel. Den er en oversikt, sendt med jevne mellomrom eller på forespørsel, og den er ofte en forutsetning for at motparten skal kunne planlegge noe: en bestilling, en påfylling eller et salg.

Meldingen er heller ikke obligatorisk på samme måte som kjernemeldingene i en handelsflyt. Mange leverandører driver i årevis uten å sende en eneste INVRPT. Den blir aktuell når noen andre trenger å vite hva du har, eller når du trenger å vite hva noen andre har på dine vegne.

Hva inneholder en lagerrapport?

Innholdet varierer med hva mottakeren har spesifisert, men kjernen går igjen.

Lokasjon. Hvilket lager rapporten gjelder, identifisert med lokasjonsnummer. En rapport uten entydig lokasjon er lite verdt hvis varene ligger flere steder.

Vare. GTIN per linje, og gjerne leverandørens eget varenummer i tillegg.

Antall. Hvor mye som finnes.

Type beholdning. Dette er det viktigste feltet, og det som oftest misforstås. Er tallet total beholdning, tilgjengelig beholdning, reservert, i bestilling, i transitt eller skadet? Samme vare kan ha flere linjer med ulik status. Vanlige beholdningstyper:

• Total beholdning
• Tilgjengelig beholdning
• Reservert
• I bestilling
• I transitt
• Skadet

Tidspunkt. Når snapshotet ble tatt. Uten dette vet ikke mottakeren hvor gammelt tallet er.

Batch og holdbarhet. Der det er relevant, som for mat og drikke, der beholdningen ikke er ett tall men flere partier med ulik dato.

Feltet for beholdningstype er verdt en ekstra tanke. Forskjellen mellom «vi har 400» og «400 er tilgjengelig for salg» er reservasjonene, og den forskjellen er hele grunnen til at noen selger varer som allerede er lovet bort.

Tre retninger meldingen brukes i

INVRPT går ikke alltid samme vei, og formålet endrer seg med retningen.

• Fra leverandør til kjøper. Du forteller kjøperen hva du har tilgjengelig, slik at de kan planlegge bestillinger etter faktisk kapasitet i stedet for etter antagelser.
• Fra lager til vareeier. Bruker du en tredjepartsoperatør, er dette meldingen som forteller deg hva som faktisk ligger på hylla deres. Uten den selger du mot din egen antagelse om beholdningen, ikke mot den reelle.
• Fra kjøper til leverandør. Kjøperen rapporterer hva de har igjen, og hvor raskt det går ut. Dette er grunnlaget for leverandørstyrt påfyll, der det er du som foreslår eller utløser neste leveranse i stedet for å vente på en bestilling.

Den siste varianten er den mest krevende og den mest verdifulle. Den flytter ansvaret for at hyllen ikke går tom fra kjøperen til deg, og forutsetter at du faktisk kan stole på tallene du får.

Snapshot, ikke transaksjon

Dette er kjernen, og det som skiller INVRPT fra resten av meldingsfamilien.

En DESADV sier «dette ble sendt». Den er sann i ettertid, uansett når du leser den. En INVRPT sier «dette ligger her», og den begynner å bli feil i det øyeblikket den er sendt.

	Transaksjonsmelding (f.eks. DESADV)	INVRPT
Beskriver	Noe som har skjedd	En tilstand akkurat nå
Forblir sann?	Ja, uansett når du leser den	Nei, blir feil fra og med sendetidspunktet
Erstatter forrige melding?	Nei, hver melding er sin egen hendelse	Ja, en full oversikt, ikke en justering

Konsekvensene av det er praktiske:

• Frekvens er en beslutning, ikke en teknisk innstilling. Rapporteres beholdningen én gang i døgnet, selger du mot gårsdagens lager. Det kan være helt greit hvis du bare leverer i faste bestillingsvinduer. Det er ikke greit hvis du også selger direkte.
• Tidsstempelet må brukes. Mottakeren må vite hvor gammelt tallet er for å kunne vurdere om det kan stoles på.
• Rapporter kan komme i feil rekkefølge. Kommer en eldre rapport etter en nyere, og systemet bare overskriver, har du nettopp erstattet riktige tall med gale.
• En rapport erstatter, den justerer ikke. De fleste oppsett behandler INVRPT som en full oversikt over lokasjonen, ikke som en endring siden sist. Er det ulik forståelse av dette mellom partene, blir avvikene raskt store.

Hva går galt?

Uklart hva tallet betyr. Den ene parten rapporterer total beholdning, den andre leser det som tilgjengelig. Oversalg følger.

• For sjelden oppdatering. Beholdningen er teknisk riktig og praktisk ubrukelig.
• Manglende batchnivå. For næringsmidler er totalen mindre interessant enn hvilke partier som finnes og hvor lenge de holder.
• Lokasjonen er for grov. Alt rapporteres som ett lager, mens varene i praksis står på flere steder med ulik tilgjengelighet.
• Ingen avstemming. Rapportene mottas, men sammenlignes aldri med en fysisk telling. Avviket oppdages når noe mangler.
• Rapporten stopper uten at noen merker det. Til forskjell fra en ordre som ikke kommer fram, gir en uteblitt lagerrapport ingen umiddelbar smerte. Systemet viser bare det siste tallet det fikk, og det ser helt normalt ut.

Det siste er den farligste. Sett opp varsling på at rapporten faktisk kommer, ikke bare på at innholdet er riktig.

Trenger du INVRPT?

Det avhenger av oppsettet ditt, og svaret er oftere nei enn for kjernemeldingene.

Du trenger å tenke på lagerrapportering hvis en tredjepart håndterer lageret ditt, hvis en kjøper har bedt om beholdningsdata, hvis du vurderer leverandørstyrt påfyll, eller hvis du selger gjennom flere kanaler mot samme beholdning.

Om det løses med INVRPT eller på annen måte, er et eget spørsmål. Beholdningsdata utveksles i dag like gjerne gjennom et API eller en direkte systemkobling. Hvilke meldinger og formater en bestemt kjøper krever, står i deres egen gjeldende implementasjonsguide, og kan endres.

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

Beholdning er sjelden et isolert problem. Den henger sammen med hva som er bestilt, hva som er reservert og hva som er sendt. Ligger ordre, lager og forsendelse i samme flyt, blir tilgjengelig beholdning et tall du kan selge på, ikke et anslag.

Er du usikker på om beholdningsdataene dine er gode nok til å selge på, tar vi gjerne en gjennomgang sammen med deg.

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.

Er INVRPT obligatorisk?

Sjelden på samme måte som ordre-, pakkseddel- og fakturameldingene. Den blir aktuell når en motpart trenger beholdningsdata fra deg, eller når du trenger dem fra et lager som håndterer varene dine. Hva en bestemt kjøper krever, står i deres gjeldende implementasjonsguide.

Hva er forskjellen på INVRPT og en lagerstatus i et system?

En lagerstatus er noe du ser i ditt eget system. INVRPT er en strukturert melding som sender den informasjonen til en annen part. Innholdet kan være det samme, men mottakeren er en annen.

Hvor ofte bør beholdningen rapporteres?

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

Kan vi bruke et API i stedet?

Ofte ja, hvis du eier begge sider av koblingen eller motparten tilbyr et dokumentert grensesnitt. Krever kjøperen en bestemt meldingstype, står det i deres implementasjonsguide, og da er det den som gjelder.

Hvorfor stemmer ikke lagertallene selv om rapporten kommer?

Vanligste årsak er at partene mener ulike ting med tallet, typisk total beholdning mot tilgjengelig beholdning. Nest vanligste er at rapporten er for gammel til å brukes slik den brukes. Sjekk begge før du leter etter feil i systemet.