25. oktober 2020

VBus versjon 13

Automatisk ordreutveksling over AutoInvoice

For noen uker siden skrev jeg om Produktkatalog.

I dag handler det om å automatisere ordrebehandlingen med AutoInvoice. Litt skjematisk ser det slik ut:

Forutsetningen for at selger kan mota kjøpers bestilling og automatisk behandle den som en salgsordre er at leverandøren (selger) kan Motta ordrer og kunden (kjøper) kan Motta ordreresponser (les: ordrebekreftelser), pakksedler og fakturaer. Dette angis i bedriftsopplysninger; Behandling ► Konfigurere AutoInvoice-konto:

I tillegg må begge parter ha registrert GTIN item no på produktene eller så må kjøper (kunden) i sitt system ha registrert Produktnr hos lev. på Leveringsalternativ. Dette kan enklest oppnås ved at leverandøren (selger) sender produktkatalog til kunden (kjøper) som importerer denne i sitt system – i alle fall for de produktene som kunden har tenkt å bestille fra leverandøren. Men produktkatalog skrev jeg om forrige gang, så jeg skriver ikke mer om det nå.

Bestilling fra kjøper/kunde

I VBus kan en innkjøpsordre oppstå på mange måter; registreres manuelt, genereres fra salgsordre eller fra bestillingsforslag – eller man kan ha en ekstern applikasjon som estimerer bestillingsbehov. Jeg går ikke mer inn på dette. Det som er viktig er at leverandøren det skal bestilles fra er satt opp med bestillinger på AutoInvoice i Sendemåte for dok.:

På bestillingen har vi tidligere vært opptatt av at du (i utskriftsparameterne) kan Ta med leverandørens produktnr og beskrivelse evt. Beskrivelse i aktuelt språk og for ikke snakke om Ordrelinjememo. Glem det. Alt det er for folk. Og denne bestillingen skal behandles maskinelt. Når du skriver ut bestillingen er det viktig at du bruker utskriftalternativet Skriv ut. Dette er det eneste utskriftalternativet som forholder seg til det som er angitt i Sendemåte for dok. Og det er viktig at du godkjenner «utskriften». For det er først når du godkjenner bestillingen at den blir sendt til leverandøren. Du får da meldingen om at overføringen til AutoInvoice var vellykket:

Merk at om du har registrert noe i feltet Rekvisisjonsnr, så kommer det overraskende nok ikke med på XML-bestillingen, selv om du har tatt det med på PDF-utgaven. Det samme gjelder Merket. Men Vår ref. kommer med. Det samme gjelder Navn og E-postadresse både til Selger/innkjøper og Kontaktperson. Betalingsbetingelsene tas med i XML, men bare som en beskrivende tekst. På linjene kommer Produktnr hos lev, Beskrivelse, Antall, EDI-enhet og Pris. Hvis det ikke ligger noe Enhet på ordrelinjen, eller en Enhet uten EDI-enhet i Enhet-tabellen, så legges det ut ZZ som EDI-enhet i XML-bestillingen.

Det som fungerer dårlig i et automatisert system er folk som ombestemmer seg. Det er like effektivt som spikermatte på motorveien. I et manuelt regime kan du selvfølgelig «blanke» ut Bestilt på ordrelinjen, skrive ut og sende ny bestilling med en kommentar av typen Vennligst se bort fra forrige bestilling. Men skal ordreutvekslingen være effektiv for begge parter er det ikke plass for manuell overstyring. Der er selvfølgelig mulig, men det dreper gevinsten ved automatiseringen. I dagligvarebransjen som har holdt på med ordreutveksling siden 1980-tallet (det er en stund siden) er det bøter til den som påfører motparten manuelt arbeid, som f.eks. å sende meldinger som må trekkes tilbake eller har et annet format eller innhold enn det som er avtalt. Men der snakker vi om transaksjonstunge miljøer hvor alt skal håndteres urørt av menneskehånd. Det er effektivt og helt nødvendig i en bransje med små marginer. Da skal det ikke mye manuelt arbeid til før dekningsbidraget fra transaksjonen er spist opp. Men for å illustrere, la oss si at vi vil ha 15 håndklær og så legger vi på noen paraplyer når vi først er i gang og sender en bestilling til (uten å tukle med det som er Bestilt) fra samme ordre:

Lett stresset som jeg er etter å ha oppdaget at jeg skulle ha flere håndklær og noen paraplyer etter å ha sendt den første bestillingen – jeg har tross alt fått streng instruks om at ting må være korrekt hele tiden – så legger jeg ikke merke til at den siste linjen mangler pris. Slikt straffer seg i et automatisert system.

Når du sender to bestillinger fra samme innkjøpsordre vil leverandøren din ha to ordrer som skal matches mot din ene. Straffen kommer, men det skal jeg komme tilbake til.

I dokumentarkivet kan du se om bestillingene er sendt til AutoInvoice og om overføringen var vellykket:

Den våkne legger selvfølgelig merke til at det er sendt to bestillinger fra ordre 2075 og at Antall på linjen med håndklær er 5, siden det allerede er bestilt 10 fra før. Og så er det i utskriftsparameterne valgt Beskrivelse i aktuelt språk. Det er fort gjort å gå seg bort i alle mulighetene her. Men det som er velsignet med automatisk ordreutveksling er at maskinene ikke bryr seg om det. Så lenge det er innenfor rammeverket er det helt OK – og dette er tilleggsinformasjon for folk som maskiner ignorerer. Den manglende prisen er det verre med…

Selv om du i dokumentarkivet kan se at bestillingene er sendt til AutoInvoice, må du inn i AutoInvoice-portalen (som du kan vise i et vindu i VBus) for å se om den har kommet helt frem til mottaker:

Også her ser vi at det er sendt bestilling fra ordre 2075 to ganger.

Salgsordre hos selger/leverandør

I det nye standardoppsettet har salgsordrevindu en egen side for å laste ned nye dokumenter. Når det er lastet ned nye inngående ordre dukker de opp her.

Det er mulig å se på PDF-vedlegget om du vil se hva som er bestilt (som blir til salgsordren). Det er mulig å se på XML-vedlegget også, men det er virkelig for spesielt interesserte. Men konseptet er strengt tatt at det skal lages salgsordre with no questions asked for å bruke en nynorsk formulering. Her kan den nye funksjonen i VBus for tidsstyrte oppgaver (jobber) være nyttig; både nedlastning og behandling (som å lage salgsordre) kan automatiseres. Og i AutoInvoice behandling kan du angi Behandle inngående dokumenter automatisk.

Når det er laget salgsordre vil de ligge klare for å sende ut ordrebekreftelse:

Her ser vi altså at det har blitt to salgsordrer som viser til samme Ordrenr hos k/l. Hvis noen lurer på hvem k/l er, så er det altså kunde/leverandør. Eller om du vil; motpart. Sum Beløp på ordrelinjene finner vi igjen som Fakt. beløp i fremt. i ordrehode. Legger vi til mva, kommer vi til Ordresaldo tilvekst. Regner vi det om til lokal valuta kommer vi til Ordresaldo tilvekst (kr). Denne havner i kundesaldo-tabellen og brukes til kredittkontrollen. Akkurat dette har ingen ting med ordreutvekslingen å gjøre, jeg ville bare nevne det…

Husk at om avsender (kunde/kjøper) har registrert Rekvisisjonsnr eller Merket på sin innkjøpsordre, så kommer disse felt ikke med på XML-bestillingen og heller ikke inn på salgsordren. Det som kunden har oppgitt som Vår ref. blir (naturlig nok) til Deres ref. på salgsordren. Men selv om XML-bestillingen inneholder opplysninger både om selger og det kunden har oppgitt som kontaktperson, så dukker ikke noe av dette opp på salgsordren. Og betalingsbetingelsene på salgsordren hentes fra kunden, ikke fra XML-bestillingen.

Legg merke til at Pris og Rabatt % kommer fra Pris/rabatt-matrisen (som vanlig i VBus), mens Forestått pris er den pris som kunden har på sin bestilling. Hvem som har gjort feil her er ikke godt å si. Enten har leverandøren endret Pris uten å varsle kunden eller så har kunden unnlatt å lese inn og behandle produktkatalog fra leverandøren. Det er litt som når noen kommer inn på verksted med bilen som har knust høyre frontlykt. Verkstedet kan bytte lykta, men ikke fortelle hvordan den ble knust.

Legg merke til at om Pris etter rabatt avviker fra Foreslått pris, så vises både Pris og Foreslått pris med rød skrift. Dersom vi har lovet kunden den foreslåtte prisen, så får vi endre Pris (og evt. Rabatt %) slik at Pris etter rabatt blir lik Foreslått pris. Da endres fargen til sort. Eller om vi tenker at det er kunden som ikke har fulgt med i timen (Gud forby), så lar vi Pris og Rabatt % stå som de er og sender ordrebekreftelse tilbake. Nå er det viktig at Sendemåte for dok. er satt rett:

At ordrebekreftelsen (og etter hvert faktura) skal på AutoInvoice er som forventet. At det ikke finnes tilsvarende alternativ for pakksedler er litt forvirrende, men det kommer jeg tilbake til. Når du skriver ut ordrebekreftelsen får du meldingen om Vellykket overføring til AutoInvoice.

Vi finner ordrebekreftelsene igjen i dokumentarkivet:

Og vi finner dem selvfølgelig i AutoInvoice-portalen:

Og vi kjenner igjen Tilknyttet dokument som Ordrenr hos k/l.

Bekreftelse hos kjøper/kunde

Tilbake hos kjøper/kunde – som først sendte bestillingen på AutoInvoice. I det nye standardvinduet er det en egen fane for å hente ordrebekreftelse fra leverandøren. Etter å ha kikket på [Last ned nye dokumenter] ser vi ett dokument som viser til ordre 2075:

Rent umiddelbart hadde vi forventet to inngående ordreresponser (les: ordrebekreftelser), men om vi kobler inn tabellen Inngående dokumentendring…

… ser vi at det ligger to meldinger der som begge er respons på ordre 2075.

Så når vi klikker på knappen [Oppdater ordre] ser vi hva som skjer med denne ordren:

For det første ser at Ord.linjestatus er endret; linjene er Bekreftet av leverandør. Dersom du i Visualisering (i Bedriftsopplysninger) har valgt

… så ser du at parentesen rundt Ankomstdato forsvinner når innkjøpsordrelinjen er Bekreftet av leverandør. Og om bestillingen var generert fra en salgsordre, ville parentesen rundt Bekreftet lev.dato på de allokerte salgsordelinjene også forsvinne. Viktigere er EDI-status. Denne har nå fått farger; rødt om noe er feil, gult hvis noe bør kontrolleres og grønt om alt er OK. Vi ser her at både Pris og Leveringsdato er endret av leverandør. Litt forvirrende er det at det ser ut som om bare 10 av de 15 håndklærne er bekreftet av leverandør. Her er det nok den sist innleste ordrebekreftelse som har overskrevet den første. Den våkne har selvfølgelig sett at ordrebekreftelse for salgsordre 2460 (den med fem håndklær og tre paraplyer) ble skrevet ut rett før ordrebekreftelsen for salgsordre 2459 (den med 5 køller og 10 håndklær). Så de 10 Bekreftet på andre ordrelinje er altså fra den sist innleste ordrebekreftelse. Her kommer altså straffen for å rote med bestillingen.

Så må vi ta stilling til om dette er endringer vi kan akseptere eller om bestillingen skal annulleres. Det er ikke noe funksjon for å annullere en bestilling over AutoInvoice, så det må gjøres manuelt (som før). Vi aksepterer endringen, men ser at vi har glemt å legge inn transporttid. Husk at Bekreftet lev.dato på en innkjøpsordrelinje er når varene går ut fra leverandørens lager, så når vi legger til Transp.tid kommer vi til Ankomstdato:

Når vi gjør dette så oppdateres ikke bare Ankomstdato, men også EDI-status som har blitt grønn for de to linjene hvor hele antallet er Bekreftet, og sort for den andre linjen hvor VBus ikke har fått med seg at hele antallet faktisk er bekreftet. Viktigere er det at opplysninger om at Pris og Leveringsdato er endret av leverandør forsvinner. VBus oppfatter det at vi endrer Transp.tid som en aksept av disse endringene.

Hvis vi manuelt bekrefter linjen med håndklær;

… så blir EDI-status grønn også for denne linjen.

Pakkseddel hos selger/leverandør

Det går noen dager og så blir de tre paraplyene på salgordre 2460 plukket. Når det kommer til stykket, var det to køller tilgjengelig på lager også. De blir også plukket. Så kan man reise spørsmål om hvorfor Bekreftet lev.dato ble satt fremover i tid da ordrebekreftelsen ble sendt. Det er fordi hele antallet ikke var tilgjengelig (Reserverbart) fra lager. VBus setter Bekreftet lev.dato til den dato hvor hele antallet kan leveres. Ideelt sett burde ordrelinjen ha blitt splittet i to; en linje for de som kan leveres med det samme og en annen for det antallet hvor varene først må kjøpes inn. På salgsordrelinjer uten noe Reserverbart mot lager, beregner VBus Bekreftet lev.dato ut fra Total lev.tid på Lagersaldo hvis ikke noe er i bestilling, og fra Ankomstdato på det som er i bestilling dersom det som er i ordre ikke er høyere. Litt komplisert å beskrive den prosessen, og siden den ikke har noe med ordreutvekslingen å gjøre – så lar jeg det ligge nå. Det er vanskelig nok å holde tråden her. Men altså; vi ferdigmelder to køller på salgsordre 2459 og tre paraplyer på salgsordre 2460. Begge ordrelinjene gjelder innkjøpsordre 2075 hos kunden. Og det skrives ut pakksedler.

Og som nevnt kan ikke pakkseddel sendes på AutoInvoice slik som bestilling, ordrebekreftelse og faktura. Det er en viss rimelighet i dette; pakkseddelen skal følge varene slik at de som gjennomfører varemottaket hos kunden/kjøper får informasjon om kundens innkjøpsordrenr og hva som ligger i pakken. Noen har valgt å sende denne på epost samtidig og da kan man oppleve at bokstavene g, j, p, q og y blir barbert nedentil på papirutskriften. Dette har jeg skrevet om før; se snailmail – så jeg skriver ikke mer om dette nå. For i stedet for å sende kopi av pakkseddelen på epost, sender vi pakkseddelen fra dokumentarkivet til kunden via AutoInvoice. I det nye salgsordrevinduet er det en egen fane for dette. Man kan bruke knappen [Send pakkseddel] eller bruke behandlingsvalget Send til AutoInvoice. Hjelpeteksten er kanskje lett forvirrende her, for dette handler ikke om å sende den på nytt til AutoInvoice, men å sende den første gang.

VBus kvitterer med at det var vellykket overføring til AutoInvoice og på statuslinjen nederst til venstre står det som forventet: 2 rader behandlet.

Registrering av varer på vei hos kjøper/kunde

På innkjøpsordren finnes det et menyvalg (både på linje og i ordrehodet) som heter Sendt. Det dukker da opp en dialogboks hvor man kan angi dato og transporttid og så blir Ord.linjestatus oppdatert med Sendt fra leverandør og Ankomstdato blir understreket (hvis man har valgt dette i Visualisering). Og det samme skjer på allokerte salgsordrelinjer med Bekreftet lev.dato. Innkjøpsordrelinjen(e) blir i tillegg oppdatert med Sendt dato. Det er dette som nå blir automatisert.

I det nye innkjøpsordrevinduet, siden for Varemottak er det egen underside for å hente pakkseddel. På samme måte som for ordrebekreftelser slår VBus sammen de to pakksedlene som vitterlig ble sendt til ett inngående dokument med to Inngående dokumentendringer:

Og når vi behandler dokumentet (på samme måte som for ordrebekreftelsen), oppdateres innkjøpsordrelinjene:

Vi ser at de to innkjøpsordrelinjene er merket med Sendt dato og Ankomstdato er satt til tre dager etter Sendt dato. Og vi ser på Ord.linjestatus at disse to radene er Sendt fra leverandør slik at Ankomstdato er understreket. Legg merke til at dette også gjelder varepartiene som har et antall I tilgang.

Så er det greit å merke seg at det i VBus ikke finnes noe antallsfelt for det som er sendt. Så her ser det ut som at hele antallet er sendt, selv om det bare er to køller som faktisk er sendt. Litt ergerlig er det at PDF-versjonen ikke følger med på ordrebekreftelse og pakkseddel, slik det gjør på bestilling og faktura. Jeg skulle virkelig ha ønsket meg en automatisk splitt av ordrelinjer i slike tilfeller. Men slik er nå engang VBus.

Neste uke kommer varene og da dukker det vel opp en faktura også. Da skal jeg skrive om hvordan vi kan automatisere fakturamottaket. Men først, litt om hva som kan gå galt før vi kommer så langt.

Bestillinger med feil

Orden i grunndata er viktig. Det å rette feil i et automatisert system kan være mer tidkrevende enn i et manuelt system. Men det kommer til å skje at noen gjør noe galt som forårsaker at prosessen stanser. Selv om vi får god flyt i transaksjonsgangen, må den overvåkes. Da er det viktig å vite hva vi skal se etter.

Vi har tidligere sett på hva som skjer om kunden oppgir feil Pris på sin bestilling. Og antallsomregning (altså bruk av Antall pr. enhet) eller Enhet med avvikende Pris må vi styre unna. På salgsordren brukes Stand. enhet fra produkt, ikke fra bestillingen. Men hva om kunden bestiller varer som ikke er i leverandørens sortiment? Vi tenker en bestilling som ser slik ut:

Problemet er bare at produkt 268 er utgått, produktene 271 og 272 er erstattet av hhv. 273 og 274 – og at produkt 298 ikke finnes hos leverandøren. Så når leverandøren leser inn bestillingen som en salgsordre blir den slik:

For leverandøren er det ikke så lett å se at kunden faktisk har bestilt andre produkter enn de som står på salgsordren, bortsett fra at ingen vil finne på å bestille produktet UTGÅTT. Man får en viss indikasjon ved at prisen er et godt stykke unna den foreslåtte prisen, men det er ikke vanskelig å tenke seg situasjoner hvor erstatningsproduktet har samme pris som det som blir erstattet. Her skulle jeg ønske meg at bytte av produkt klarere ble flagget for leverandøren.

Bestillinger med produkter som ikke blir funnet er enklere. Her er beskrivelsen klar som blekk – og for sikkerhets skyld skrevet i rød skrift.

Endringer som leverandøren gjør

For å finne ut hva kunden egentlig har bestilt, finner vi frem det inngående dokumentet og bruker behandlingsvalget Vis dokument(er):

Hvis det finnes en PDF-utgave av bestillingen så vil VBus både vise XML og PDF. Vi tenker oss at leverandøren gjør følgende endringer på salgsordren:

Vi blanker ut Produktnr UTGÅTT og legger inn en egnet Beskrivelse. Det som gjør at teksten blir rød er at linjen har Opprinnelse=17 [AutoInvoice], har en Foreslått pris, men mangler Produktnr. Så legger vi til en linje et annet produkt som vi tenker kan passe. Legg merke til kolonnen Ekstern ID. Denne viser til Linjenr på kundens innkjøpsordre. Den nye linjen mangler Ekstern ID siden denne ikke finnes på kunden innkjøpsordre.

Så skriver vi ut og sender ordrebekreftelsen på AutoInvoice. Som PDF ser den slik ut:

Men når denne ordrebekreftelsen leses inn hos kunden som har sendt bestillingen, blir det slik hos kunden:

De linjene hvor Produktnr er erstattet med noe som finnes også hos kunden ser vi at EDI-status settes til 65537 som betyr at Linje er endret og Produktet er erstattet. På de andre linjene som ble Bekreftet ser vi at EDI-status settes enten til 4097 som betyr at Linje er endret og Antall bekreftet eller 6145 som betyr at Linje er endret, Leveringsdato endret og Antall bekreftet. Der hvor leverandøren lett optimistisk foreslo Produktnr 311 uten å sjekke om dette produktet finnes hos kunden, ser vi i Beskrivelse hva som gikk feil. EDI-status 32771 betyr Linje er endret, Linje er lagt til av leverandør og Produktet finnes ikke. Klarere enn dette kan det vel ikke formuleres. Du trenger ikke lære alle de verdiene som EDI-status kan ha. Det er nok å dobbelt-klikke (eller skrive *) i feltet, så kommer forklaringen opp.

De to linjene som ikke blir bekreftet er det verre med. Her er EDI-status 1 som bare betyr at Linje er endret. For på XML-meldingen er slik vi forventer at den skal være (utdrag for linje 2):

    <cac:OrderLine>

    <cac:LineItem>

      <cbc:ID>2</cbc:ID>

      <cbc:LineStatusCode>3</cbc:LineStatusCode>

      <cbc:Quantity unitCode="ZZ">0</cbc:Quantity>

      <cac:Delivery>

        <cac:PromisedDeliveryPeriod>

          <cbc:StartDate>2020-10-24</cbc:StartDate>

          <cbc:EndDate>2020-10-24</cbc:EndDate>

        </cac:PromisedDeliveryPeriod>

      </cac:Delivery>

      <cac:Price>

        <cbc:PriceAmount currencyID="NOK">0</cbc:PriceAmount>

        <cbc:BaseQuantity>0</cbc:BaseQuantity>

      </cac:Price>

      <cac:Item>

        <cbc:Name>Wilson Deep Red Tour Men 3-PW, stål er utgått av sortiment</cbc:Name>

        <cac:SellersItemIdentification>

<cbc:ID />

        </cac:SellersItemIdentification>

      </cac:Item>

    </cac:LineItem>

    <cac:OrderLineReference>

      <cbc:LineID>2</cbc:LineID>

    </cac:OrderLineReference>

  </cac:OrderLine>

XML-meldingen viser med all tydelighet at Produktnr er blank, at Beskrivelse er endret, at Antall og Pris er satt til 0.

Et alternativ er at begge parter blir enige om å legge opp to produkter, f.eks. UTGÅTT og UKJENT som kan være satt opp med behandlingsmåten:

° Unntas lagerhåndtering

° Unntas fra: Ferdigmelding, Tilbakelevering, Akseptering, Sendt fra lev., Varemottak, Fakturamottak, Rekalkulering av priser, Generer innkjøps- /prod. Ordrer

° Utelates på: Forespørsler, Bestilling, Produktbestilling, Tilbud, Leveransebeskjeder, Plukklister, Pakksedler, Fraktbrev og Faktura

° Undertrykk: Produktnr, Antall, Pris og rabatt, Beløp

° Unnta fra totaler: Inntekter, Kostnader ved salg, Kostnader ved produksjon, Vekt og volum

° Unnta fra statistikkføring: Inntekter, Kostnader ved salg, Kostnader ved produksjon

° Ikke hent: Utsalgspris, Kostnader ved salg

° Beregning av priser: Ikke foreslå pris/rabatt på nytt

° Oppgi beskrivelse

° Behandlingsmåte sperret for redigering

Vi bruker Produktnr UKJENT på linje 8:

Legg merke til at vi må legge inn et Antall for at linjene skal komme med på ordrebekreftelsen, men det holder med 1. Når ordrebekreftelsen leses inn hos kunden blir det slik:

Det er litt irriterende at Beskrivelse hentes fra produktet og ikke fra ordrebekreftelsen. Det er ikke noe poeng for leverandøren å legge inn en melding i Beskrivelse, for den kommer ikke frem til kunden. Det hadde også vært praktisk om VBus hadde tatt vare på opprinnelig Produktnr og Beskrivelse, f.eks. i Trans.opplysn.2 og Trans.opplysn.2, men det er enkelt å ordne med ordrelagringsprosedyren.

Jeg er usikker på om det er noen moral i denne historien, men om det er – så må det være omtrent slik: Ha stålkontroll på grunndata og ikke tukle med ordrene.

For om du har alt på stell, så kommer fakturamottaket til å gå raskt.

Men det skal jeg skrive om neste gang.

Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg

Frode Antun

Løsningsrådgiver

amesto

                   Solutions

m: + 47 911 46 751

e: frode.antun@amesto.no

a: Smeltedigelen 1, 0195 Oslo

w: amestosolutions.no