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 ordre­responser (les: ordre­bekreftelser), pakk­sedler og fakturaer. Dette angis i bedriftsopplysninger; Behandling Konfigurere AutoInvoice-konto:

 Et bilde som inneholder tekst

Automatisk generert beskrivelse

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å Leverings­alternativ. Dette kan enklest oppnås ved at leverandøren (selger) sender produkt­katalog 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 salgs­ordre eller fra bestillings­forslag – eller man kan ha en ekstern applikasjon som estimerer bestillings­behov. 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 Ordre­linje­memo. 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 utskrift­alternativet Skriv ut. Dette er det eneste utskrift­alternativet 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. Betalings­betingelsene 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å ordre­linjen, 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 spiker­matte på motor­veien. I et manuelt regime kan du selvfølgelig «blanke» ut Bestilt på ordre­linjen, skrive ut og sende ny bestilling med en kommentar av typen Vennligst se bort fra forrige bestilling. Men skal ordre­utvekslingen være effektiv for begge parter er det ikke plass for manuell overstyring. Der er selvfølgelig mulig, men det dreper gevinsten ved auto­matiseringen. I daglig­vare­bransjen som har holdt på med ordre­utveksling siden 1980-tallet (det er en stund siden) er det bøter til den som påfører mot­parten 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 transaksjons­tunge miljøer hvor alt skal håndteres urørt av menneske­hånd. Det er effektivt og helt nødvendig i en bransje med små marginer. Da skal det ikke mye manuelt arbeid til før deknings­bidraget 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 auto­matisert 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:

Et bilde som inneholder tekst

Automatisk generert beskrivelse

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 utskrifts­parameterne valgt Beskrivelse i aktuelt språk. Det er fort gjort å gå seg bort i alle mulighetene her. Men det som er velsignet med automatisk ordre­utveksling er at maskinene ikke bryr seg om det. Så lenge det er innenfor ramme­verket er det helt OK – og dette er tilleggs­informasjon 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:

Et bilde som inneholder bord

Automatisk generert beskrivelse 

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å ordre­linjene finner vi igjen som Fakt. beløp i fremt. i ordre­hode. Legger vi til mva, kommer vi til Ordre­saldo til­vekst. Regner vi det om til lokal valuta kommer vi til Ordre­saldo til­vekst (kr). Denne havner i kunde­saldo-tabellen og brukes til kreditt­kontrollen. Akkurat dette har ingen ting med ordre­utvekslingen å gjøre, jeg ville bare nevne det…

Husk at om avsender (kunde/kjøper) har registrert Rekvisisjonsnr eller Merket på sin innkjøps­ordre, så kommer disse felt ikke med på XML-bestillingen og heller ikke inn på salgs­ordren. Det som kunden har oppgitt som Vår ref. blir (naturlig nok) til Deres ref. på salgs­ordren. Men selv om XML-bestillingen inneholder opp­lysninger både om selger og det kunden har oppgitt som kontakt­person, så dukker ikke noe av dette opp på salgs­ordren. Og betalings­betingelsene på salgs­ordren 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 produkt­katalog fra leverandøren. Det er litt som når noen kommer inn på verksted med bilen som har knust høyre front­lykt. 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 fore­slåtte prisen, så får vi endre Pris (og evt. Rabatt %) slik at Pris etter rabatt blir lik Fore­slå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 ordre­bekreftelse tilbake. Nå er det viktig at Sende­måte for dok. er satt rett:

Et bilde som inneholder bord

Automatisk generert beskrivelse

At ordrebekreftelsen (og etter hvert faktura) skal på AutoInvoice er som forventet. At det ikke finnes tilsvarende alternativ for pakk­sedler er litt for­virrende, men det kommer jeg tilbake til. Når du skriver ut ordre­bekreftelsen 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 standard­vinduet er det en egen fane for å hente ordre­bekreftelse 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 dokument­endring…

… 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 Bedrifts­opplysninger) 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 salgs­ordre, ville parentesen rundt Bekreftet lev.dato på de allokerte salgs­orde­linjene 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 Leverings­dato 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 ordre­bekreftelse som har overskrevet den første. Den våkne har selv­følgelig sett at ordre­bekreftelse for salgs­ordre 2460 (den med fem hånd­klær og tre paraplyer) ble skrevet ut rett før ordre­bekreftelsen for salgs­ordre 2459 (den med 5 køller og 10 hånd­klær). Så de 10 Bekreftet på andre ordre­linje er altså fra den sist innleste ordre­bekreftelse. 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 transport­tid. Husk at Bekreftet lev.dato på en innkjøps­ordre­linje 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 Leverings­dato 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 frem­over i tid da ordre­bekreftelsen ble sendt. Det er fordi hele antallet ikke var tilgjengelig (Reserver­bart) 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å salgs­ordre­linjer uten noe Reserverbart mot lager, beregner VBus Bekreftet lev.dato ut fra Total lev.tid på Lager­saldo hvis ikke noe er i bestilling, og fra Ankomst­dato 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 ordre­utvekslingen å gjøre – så lar jeg det ligge nå. Det er vanskelig nok å holde tråden her. Men altså; vi ferdigmelder to køller på salgs­ordre 2459 og tre paraplyer på salgs­ordre 2460. Begge ordre­linjene gjelder innkjøps­ordre 2075 hos kunden. Og det skrives ut pakk­sedler.

Og som nevnt kan ikke pakkseddel sendes på AutoInvoice slik som bestilling, ordre­bekreftelse og faktura. Det er en viss rimelighet i dette; pakk­seddelen skal følge varene slik at de som gjennom­fører vare­mottaket hos kunden/kjøper får informasjon om kundens innkjøps­ordrenr 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å papirut­skriften. Dette har jeg skrevet om før; se snailmail – så jeg skriver ikke mer om dette nå. For i stedet for å sende kopi av pakk­seddelen på epost, sender vi pakk­seddelen fra dokument­arkivet til kunden via AutoInvoice. I det nye salgs­ordre­vinduet er det en egen fane for dette. Man kan bruke knappen [Send pakkseddel] eller bruke behandlings­valget Send til AutoInvoice. Hjelpe­teksten 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 dialog­boks hvor man kan angi dato og transport­tid og så blir Ord.linje­status oppdatert med Sendt fra leverandør og Ankomst­dato blir under­streket (hvis man har valgt dette i Visualisering). Og det samme skjer på allokerte salgs­ordre­linjer med Bekreftet lev.dato. Innkjøps­ordre­linjen(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 pakk­seddel. På samme måte som for ordre­bekreftelser slår VBus sammen de to pakk­sedlene som vitterlig ble sendt til ett inngående dokument med to Inngående dokument­endringer:

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

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 Ankomst­dato er under­streket. Legg merke til at dette også gjelder vare­partiene 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å ordre­bekreftelse og pakk­seddel, slik det gjør på bestilling og faktura. Jeg skulle virkelig ha ønsket meg en auto­matisk splitt av ordre­linjer 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 auto­matisere faktura­mottaket. 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 tid­krevende 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 transaksjons­gangen, må den over­vå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 antalls­omregning (altså bruk av Antall pr. enhet) eller Enhet med avvikende Pris må vi styre unna. På salgs­ordren 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å salgs­ordren, 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 fore­slåtte prisen, men det er ikke vanskelig å tenke seg situasjoner hvor erstatnings­produktet 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 behand­lingsvalget 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, Leverings­dato 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 behandlings­måten:

°         Unntas lagerhåndtering

°         Unntas fra: Ferdigmelding, Tilbakelevering, Akseptering, Sendt fra lev., Varemottak, Faktura­mottak, 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 ordre­bekreftelsen 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 faktura­mottaket 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.no