8. november 2020
VBus versjon 13
Automatisk ordrematch og fakturamottak med AutoInvoice
For noen uker siden skrev jeg om Produktkatalog. Og 14 dager senere om ordreutveksling over AutoInvoice. I dag skriver jeg om rosinen i pølsa; automatisk fakturamottak med AutoInvoice:
Fakturamottaket – som skal knytte den inngående fakturaen til innkjøpsordren, slik at vi får rett kostpris på alle varer som kjøpes inn – er den enkeltoppgave som hos mange tar mest tid; og hvor gevinsten ved automatiseringen er størst. Legg merke til at det her, som ellers ved automatisering, er mottaker som først og fremst høster gevinsten.
Avsender (leverandøren/selger) må selvfølgelig ha registrert seg i AutoInvoice-portalen. Mottaker (kunde/kjøper) må i tillegg ha angitt
Vi fortsetter der vi slapp forrige gang. Kunden har registrert en innkjøpsordre og har sendt to bestillinger til leverandøren, som derfor har to salgsordrer hos seg – som begge viser til den samme innkjøpsordren hos kunden. Leverandøren har sendt to køller (fra leverandørens første innkjøpsordre) og tre paraplyer (fra den andre). Disse er mottatt hos kunden og innkjøpsordren er nå slik:
Leverandøren har altså to ordre og legger på 250 kroner i frakt (i hodet) på den ene ordren og fakturerer begge, men ikke som samlefaktura.
Hos kunden er må innstillingene være rett. I VDC (Visma Document Center) må det i Systeminnstillinger være krysset av for Utfør automatisk ordrematching for støttede dokumenter:
Og det må være satt opp at AutoInvoice er aktiv og Automatic order match som Ordredokumentprofil.
Når leverandørene legger på frakt trenger vi et produkt som kan brukes til bokføring av slike kostnader. Dette må vi angi som Frakt 4 i Bedriftsopplysninger. I tillegg må det legges opp et Produkt gebyrer og avrunding. Dette brukes til andre kostnader, som avgifter og avrunding:
For at VBus skal kunne skille frakt fra gebyrer og avrunding på den inngående faktura, må vi legge opp et Leveringsalternativ for Frakt med den beskrivelse som dukker opp i XML-meldingen:
Og jeg anbefaler på det sterkeste at det også hukes av for Ingen delvis fakturamottak for ordrematch. Uten dette valget vil det dannes bilag for deler av fakturaen – og det gir i mitt (nokså enkle) hode ingen mening.
Men hvis avvik skal tillates må vi angi hvor store avvik vi vil tolerere, både i kroner og prosent. Det må fylles ut verdier i Inngående faktura avvikstoleransebeløp og Inngående faktura avvikstoleranse %.
Hvor lang tid det tar fra leverandøren sender sin faktura på AutoInvoice til den dukker opp hos kunden kommer nok an på hvilken vei fakturaen skal gå. Men om både leverandøren og kunden bruker en Visma-løsning tar det om lag 10 minutter før den blir synlig i kundens AutoInvoice-portal. Hvor lang tid det deretter tar før VDC plukker den opp kan fremstå som litt tilfeldig. I versjon 15.00 eller tidligere tar det minst en time. Det er først i versjon 15.01 at VDC tar hensyn til at Finland (hvor Maventa holder til) ligger en time foran oss. Så er det slik at VDC ser etter nye fakturaer en gang i timen. Så om du ikke bruker versjon 15.01 kan det godt gå et par timer, men i det det daglige spiller det ingen rolle. Men om du skal sette opp AutoInvoice og ønsker å kontrollere at den kommer inn som den skal, er det mulig å endre intervallet mellom hver gang VDC ser etter nye fakturaer; helt ned til to minutter. I versjon 14 (og tidligere) kunne dette gjøres i VDC i Serverkonsoll med kommandoen SETPRIORITY 8 1. 8 er i denne sammenheng Task 8, mens 1 er intervall (regnet i enheter á to minutter for at det ikke skal bli for åpenbart). Så om du vil at VDC skal se etter nye inngående fakturaer hvert tiende minutt, så bruker du kommandoen SETPRIORITY 8 5. Klart som blekk?
I versjon 15 er det annerledes. På applikasjonsserver går det en rekke tjenester. En av disse heter «Visma Document Center Server». I versjon 15 er denne splittet i flere tjenester for å få bedre ytelse i transaksjonstunge miljøer og det er tjenesten «Visma Document Center Server AutoInvoice» som fra versjon 15 henter fakturaene fra AutoInvoice. Skal du endre innlesingsintervallet må du stanse denne tjenesten og kjøre den i konsollmodus. Og nå er det Task 1 som skal endres. Så her må du bruke kommandoen SETPRIORITY 1 1 for å endre intervallet til to minutter. Deretter kan du avslutte tjenesten (i konsollmodus) starte den på vanlig vis. Og for all del; når du er ferdig med testingen, sett intervallet tilbake til en gang i timen – det er hyppig nok for de fleste – altså slik: SETPRIORITY 1 30.
Men altså; leverandøren har to ordre og legger på 250 kroner i frakt (i hodet) på den ene ordren og fakturerer begge, men ikke som samlefaktura. De to fakturaene er slik for folk (PDF-utgaven):
og
Her ser vi igjen straffen for at det ble sendt to bestillinger fra samme orde; hadde alt blitt sendt på første bestilling ville leverandøren bare hatt én salgsordre og kunden hadde sluppet fakturagebyret. Så kunne PDF-utgaven med fordel ha hatt en henvisning til kundens ordrenummer, men det spiller i praksis ingen rolle for den automatiske behandlingen. For her ble det gjennomført to fakturamottak helt automatisk. Innkjøpsordren ser nå slik ut:
Vi ser at det automatisk er lagt til frakten som ble fakturert som Frakt og fakturagebyr og avrunding som Gebyr. Hvis du henter frem kolonnen Fakt. beløp hittil, så ser du at den er null for de linjene som er realisert. Det er litt synd – for det betyr at Fakt. beløp totalt helt misvisende er det samme som Fakt. beløp i fremt. Men slik er nå engang VBus når det gjelder innkjøpsordre.
Så går det kanskje noen dager og leverandøren får flere køller og håndklær inn på lager, ferdigmelder salgsordrene og siden det kom noen sure kommentarer om det fakturagebyret på den ene fakturaen, så tenker den som skal fakturere at da får vi samlefakturere de to ordrene når resten skal faktureres. Som tenkt så gjort. Fakturaen blir seende slik ut:
Den våkne ser at de to første linjene kommer fra første bestilling, mens den siste kommer fra andre bestilling. Og når denne fakturaen leses inn og behandles hos kunden kommer den ultimate straffen for å ha endret bestillingen – og laget to bestillinger fra samme innkjøpsordre. For siden det er to fakturalinjer (fra hver sin salgsordre) som viser til samme innkjøpsordrelinje så blir den første behandlet, men når VBus kommer til den andre, går det helt i ball:
Når jeg skriver dette, må jeg legge til noe om hvorfor. Jeg er ofte i samtaler med kunder om hva som kan skape problemer i den daglige drift. Ofte hører jeg kunder si at «dette er ikke noe problem for oss; det går helt greit i 98% av tilfellene». Det jeg hører, er bare at det går til helvete i 2% av tilfellene. Jeg er ikke prest, men jeg ser det allikevel som min oppgave å bidra til at ingen av mine kunder havner i helvete. Ikke engang i 2% av tilfellene. Så når jeg er opptatt av alt som kan gå galt, så er det for å styre kundene mine unna akkurat det.
På denne innkjøpsordren er det gjennomført to fakturamottak som har gått helt automatisk, men så har det altså stanset opp på det siste. Og det må vi følge opp. For hvert fakturamottak finnes det et dokument; den inngående fakturaen. Vi ser at de to første dokumentene har Ordrematch status 1 [Ferdiggjort gjennom automatisk matching]. Mens det siste har status 2 [Pågår]. I ordrehodet ser vi at Foreslått ordretotal netto er 19.680,30. Dette er hentet fra den inngående fakturaen. Man kan dobbeltklikke på XML data for å se fakturaen; ikke som PDF, men i et standardisert utseende:
Men så ser vi at det ikke er foretatt fakturamottak for de siste fem håndklærne. Regnskapsbilaget har blitt slik:
Vi ser altså at det er bokført deler av en faktura. Og det var dette vi ville unngå ved å krysse av for Ingen delvis fakturamottak for AutoInvoice i Ordrebehandling (i Bedriftsopplysninger). Men det ble gjennomført et delvis fakturamottak allikevel. Det som må gjøres her er å avbryte det pågående fakturamottaket:
Da forsvinner alle foreslåtte verdier og man kan gjennomføre manuelt fakturamottak på det som gjenstår. Fakturanr må endres, f.eks. ved å legge til et punktum;
Og så får man vurdere om det skal ryddes litt i reskontro og slå sammen de to bilagene, eller om det skal foretas to betalinger. Det siste går helt sikkert like greit. Siden begge betalingene henviser til KID, så vil leverandøren neppe registrere at det kom to betalinger i stedet for én.
Så kan man spørre seg om hva som ville ha skjedd om leverandøren ikke hadde valgt samlefakturering, men fakturert de to ordrene hver for seg. Da ville de ha gått rett igjennom begge to. Og det helt uavhengig av hvilken av dem som ble fakturert først.
Nå er det slik at de fleste fakturerer nokså umiddelbart etter at varene forlater leverandøren. Og det er nokså sannsynlig at varetransporten tar mer enn et par timer, så det er vel tenkelig at fakturaen har ankommet før varene. Og da ser det slik ut:
Forventet antall på faktura er Ferdigmeldt minus Fakt./real. (det som tidligere er fakturamottatt). Og siden varene enda ikke har ankommet vårt lager (og varemottak ikke er gjennomført), så forventer ikke VBus noen faktura riktig enda. Men så har det altså kommet to fakturaer. Den ene – med Ordrematch status = 2 [Pågår] har altså tre køller og 10 håndklær. Siden Foreslått antall (det antall som står på faktura) er større enn Forventet fakt.antall, så er Foreslått antall markert med rødt. Vi ser at sum Foreslått beløp på ordrelinjene er det samme som Foreslått ordretotal netto i ordrehodet. Dette er altså beløpet før mva på denne fakturaen. Den andre fakturaen har Ordrematch status = 8 [Avventer].
Så kommer varene og fakturamottaket gjennomføres. Det som nå skjer, er at fargen på Foreslått antall endres fra rødt til grønt. Nå kan vi gjennomføre fakturamottaket, slik:
Det kommer opp en standard dialogboks som ved manuelt fakturamottak og ordren ser nå slik ut:
Legg merke til at dokumentet som nettopp ble behandlet har nå fått Ordrematch status = 5 [Ferdiggjort manuelt]. Så markerer vi den fjerde raden i Dokumenttabellen; den med Ordrematch status = 8 [Avventer] og velger behandlingsvalget Ordrematch. Igjen kommer det opp en standard som ved manuelt fakturamottak, men vi velger [Avbryt] i dialogboksen. Da oppdateres ordren med foreslåtte verdier fra den siste fakturaen:
Og vi kan bruke behandlingsvalget Oppdater verdier og motta faktura.
Det hadde vært fint om fakturamottaket kunne skjedd automatisk som følge av varemottaket, men det er allikevel en ubetydelig oppgave i forhold til et manuelt fakturamottak på gamlemåten.
Litt mer om samlefaktura
La oss gå tilbake til da innkjøpsordren ble registrert og tenke at etter at den første bestillingen (på fem køller og ti håndklær) – hvor bestiller bestemte seg for å bestille fem håndklær til og tre paraplyer. I stedet for å øke antall på håndklær, legger vi inn en ny linje med håndklær slik at innkjøpsordrelinjene (egentlig bestillingslinjene) blir slik:
Vi har nå to linjer (#2 og #3) med håndklær. Men det hjelper ikke; det blir samme problem i fakturamottaket. Faktisk er det slik at det ikke er støtte for fakturaer hvor samme Produktnr figurerer mer enn en gang. Vi skal se på hva dette innebærer litt senere.
Men først, la oss legge opp et mer typisk scenario for samlefakturering. Det registreres to innkjøpsordrer, slik:
Vi skriver ut to bestillinger som leses inn som to salgsordre hos leverandøren som sender ordrebekreftelse i retur slik at vi får oppdatert prisene og så blir alt ferdigmeldt og samlefakturert. Det kommer altså én faktura til kunden og denne har referanse til én av innkjøpsordrene:
Og her glipper det grundig for VBus; dokumentet har Ordrematch status = 7 [Obligatorisk verdi mangler]. Det kunne ha vært en bedre forklaring her, men det er altså produkter på fakturaen som ikke finnes på ordren det vises til; Ordre-/bestillingsnummer 2099.
Det eneste tilfelle hvor VBus kan håndtere en samlefaktura er om alle salgsordrene viser til samme innkjøpsordre og samme Produktnr ikke finnes mer enn én gang. Så konklusjonen er rimelig klar. På avtalene du gjør med leverandørene dine og på bestillingene du sender til dem må du gjøre det klart at samlefaktura ikke vil bli akseptert og betalt. For eksempel slik: Faktura skal vise til denne ordre/bestilling og det skal ikke tas med leveranser fra andre ordre/bestillinger. Samlefaktura ikke vil bli betalt. Jeg ser ikke bort fra at det kan være vanskelig å få aksept for dette øst for Eufrat og Tigris, sør for Alpene og vest for Atlanteren, men prøv allikevel. Det er så mye tid å spare om man slipper behandling av samlefaktura i fakturamottaket. Dette er ikke det samme som å styre unna delleveranser og at en og samme innkjøpsordre blir fakturert flere ganger. Det er som vi ser helt uproblematisk. Det som er den største tidstyven er når det på en stor faktura, som i hovedsak gjelder en bestemt innkjøpsordre, er tatt med restleveranser fra andre innkjøpsordre.
Prisavvik
Dersom bestillingen sendes som AutoInvoice, leverandøren sender ordrebekreftelse tilbake og kunden oppdaterer sin innkjøpsordre – og tar stilling til eventuelt prisavvik før varer plukkes og sendes fra leverandøren, så har vi ryddet problemstillingen med prisavvik – og for så vidt bruk av erstatningsprodukter, utgåtte og ukjente produkter – før vi kommer til fakturamottaket. Det er en helt åpenbar fordel.
Men det er selvfølgelig mulig å gjennomføre automatisk fakturamottak, så lenge fakturaen har de samme produktene som innkjøpsordren (altså at Produktnr hos lev. er registrert i tabellen Leveringsalternativ). Hvis antall stemmer med det som er varemottatt og prisen stemmer med ordren, så gjennomføres fakturamottaket automatisk. Er det prisavvik som er større enn toleransegrensene, så blir fakturamottaket ikke gjennomført automatisk. Ordrematch status settes til 2 [Pågår]. Merk at disse grensene gjelder fakturatotalen inklusive frakt, gebyrer og mva – ikke den enkelte linje. Det er i praksis ingen kontroll på hva leverandøren legger til av frakt eller gebyrer, hverken i form av fakturagebyr eller spesialavgifter. Her må den enkelte vurdere hvor ofte og hvor inngående man vil etterkontrollere disse kostnadene.
Der hvor det er prisavvik vises Foreslått pris og Foreslått beløp med rød skrift. Det er lett forvirrende at også Foreslått antall er vist med rød skrift, siden antall er som forventet. Legg også merke til at de foreslåtte verdiene på Frakt-linjen er helt OK og skrevet med grønn skrift. Årsaken til at Foreslått mva.beløp i hodet ikke stemmer med summen av Foreslått mva.beløp på linjene er at det (av en elle annen grunn) ikke er foreslått noe mva-beløp på frakten. Men det spiller ikke så stor rolle, for når vi velger behandlingsvalget Oppdater verdier og motta faktura, så blir bokføringen og kostpris på varepartiene helt rett.
Noen ord om valuta
Dersom det registreres en innkjøpsordre i valuta som sendes til leverandøren med AutoInvoice, så står valutakoden på XML-meldingen, og når leverandøren leser bestillingen inn som en salgsordre hos seg, hentes valuta fra bestillingen. Dette forutsetter at korrekt ISO-kode (NOK, SEK, DKK, GBP, EUR, USD, etc.) er lagt inn i Valuta-tabellen. Valutakurs hentes fra Valuta-tabellen (evt. fra Valutakurs-tabellen om denne brukes). Kunde og leverandør har således forskjellige valutakurser på sine ordrer.
La oss si at kjøper (kunden) har registrert innkjøpsordren med Valutakurs = 11 NOK/GBP, mens kursen på salgsordren hos selger (leverandøren) ble 12 NOK/GBP. Og at det i Ordrepref. på salgsordren er krysset av for Valutakursjustering. Og at valutakursen på faktureringstidspunket har blitt til 10 NOK/GBP. Så legger vi 240,- inn som frakt i ordrehodet før fakturering. Husk at frakt i ordrehode er i NOK selv om fakturaen er i fremmed valuta. Fakturaen blir slik:
Det VBus gjør med 240 NOK i frakt, er å bruke valutakurs før valutakursjustering (12 NOK/GBP) og kommer frem til at vi skal fakturere 20 GBP. Men etter valutakursjustering (til 10 NOK/GBP) gir dette bare 200 NOK i inntekt...
Som vi ser er det fakturert med norsk mva i fremmed valuta og da sier bokføringsforskriftens § 5-5-1, punkt 6 at merverdiavgift skal angis i norske kroner. Så PDF-fakturaen over er litt mangelfull. Men det er lett å ordne i formularet; det er egne makroer for dette og i versjon 15.01 kom det sågar en ny makro for å kunne vise mva-grunnlaget i NOK. Strengt tatt ikke nødvendig slik forskriften er utformet, men det er ikke noe i veien for å ta det med.
Men nå er det jo ikke det som står på formularet (PDF-utgaven) som blir behandlet automatisk. Det er det som står i XML-fakturaen som blir behandlet. Og den er altså slik:
Det som står etter teksten «Valutakurs for avgiftsberegning: Fra GBP til NOK» gir ikke mening, men det gjør ikke noe siden MVA-beløpet er vist både i GBP og NOK, akkurat slik forskriften krever. Og hos kunden er innkjøpet ført i sin helhet med samme valutakurs som hos leverandøren (selger):
Det er noen som blir veldig forvirret av at de automatgenererte mva-postene ikke er ført i fremmed valuta, bare i NOK. Men det spiller strengt tatt ingen rolle. For dette er norsk mva. Det er fire øre differanse mellom det mva-beløp som fremgår av faktura og det som er bokført, men det er helt innafor. Ikke bare innafor; det er innertier!
Merk at prisen som oversendes i produktkatalogen er nettopris, altså pris etter rabatt. Så selv om leverandøren opererer med en pris før rabatt og en rabatt – så er det nettoprisen som oversendes på ordrebekreftelsen (og for så vidt på pakkseddelen), mens når det kommer til fakturamottaket så oppdateres innkjøpsprisen med pris før rabatt og rabatt, men rabatten ikke som en prosent-rabatt, men som en krone-rabatt. Dette spiller for så vidt ingen rolle hverken for bokføringen eller for kostprisen på varepartiene som kjøpes inn, men det kan være greit å vite for den som er kontrollfreak. Det kan være forvirrende for den som holder øye med Pris og Rabatt % uten å se på Rabattbeløp – for det er først når fakturamottaket gjennomføres at Pris og Rabattbeløp endres.
Og for den som måtte fundere; hvis det ikke er norsk mva på faktura skjer det ingen endring i valutakurs på innkjøpsordre. Og det er ikke støtte for valutakursjustering på innkjøpsordre, slik det er på salgsordre. Litt synd akkurat det; jeg foreslo dette for fem år siden, men det var ingen som synes det er en god idé (det heller).
Så kan det vel se ut som om «noen» har glemt angi Unntas lagerhåndtering på Gebyr-produktet, så da har vi vel om lag 53 gebyrer liggende på lager…
Noen ord om spesialavgift
Noen har varer som faktureres med spesialavgift. Den prisen som kommer med produktkatalog er før spesialavgift og det kommer ingen informasjon i produktkatalogen om at spesialavgiften kommer i tillegg, så her må man legge opp en hensiktsmessig behandling av slike varer manuelt. På denne ordren vet vi at leverandøren kommer til å belaste omtrent 2 % i frakt og en miljøavgift på 4 %. Innkjøpsordren er satt opp slik:
I Avgifts- og bokføringsopplysninger har jeg angitt følgende:
Innkjøp av frakt (og gebyrer) blir altså ført på konto 3460 Frakt, toll og spedisjon. Når det A. og b.-behandling er satt til 48 betyr det
og i denne sammenhengen er det vesentlige at fraktpåslaget bokføres ved innkjøp. Selv om kostprispåslag ikke er nevnt i A. og b.-behandling, så gjelder Bokfør debet/kredit frakt 1-4 og toll ved innkjøp også for kostprispåslag. Og så har jeg valgt å bokføre frakt og kostprispåslaget (altså ved innkjøp) til debet på samme konto som varekjøpet (altså her 1470) og til kredit på konto 4360 som er samme konto som brukes for innkjøp av frakt. Jeg har tidligere skrevet om behandling av inngående frakt, så jeg skriver ikke mer om dette nå. Jeg har for så vidt skrevet om bokføring av midlertidig lagerverdi ved ferdigmelding også, så jeg skriver ikke mer om det heller.
Fakturaen blir seende slik ut:
Når fakturamottaket er gjennomført, ser det slik ut i logistikk og regnskap:
Kostprisen på golfbilene er innkjøpspris + 2 % frakt og 4 % kostpristillegg (for spesialavgift), lagerverdien øker med hhv. 589.360 og 585.120 NOK; samlet 1.174.480 NOK. Det som blir bokført inn på konto 1470 er 1.108.000 + 22.160 + 44.320 = 1.174.480 NOK. Konto frakt (4360) belastes med den faktiske kostanden på 22.000 i frakt pluss den faktiske spesialavgiften på 44.320, altså 66.320 NOK. Samtidig godskrives den kalkulerte frakt og kostpristillegg; 66.480 NOK – slik at netto blir det en kredit på 120 NOK på fraktkonto. Dette er fordi den kalkulerte frakten på 2 % var litt større enn den faktiske frakten på 22.000 NOK. Men dette får vi si er innafor.
Og noen ord om ordrelinjer uten antall
Gamle vaner kan være vonde å vende. La oss tenke en innkjøpsordre som ser slik ut:
Når denne leses inn hos leverandøren som en salgsordre blir den slik:
Hvis ingen hos leverandøren gjør noe, men bare sender ordrebekreftelse i retur til kunden – som leser inn ordrebekreftelsen hos seg, så ser innkjøpsordren brått slik ut:
Så om kunden ikke våkner nå, står det om litt en funklende ny Golf Caddy bil – sort metallic 30Hk på tunet.
Ordrelinjer med behandlingsmåte Utelates på bestilling kommer ikke med. Hvis det i behandlingsmåte er angitt Undertrykk produktnr, så skjer ikke det. Derimot blir antall, pris, rabatt og beløp undertrykket på bestillingen hvis man har valgt dette i behandlingsmåte, men husk at Antall da settes til 1 på salgsordren hos leverandøren.
Så er det selvfølgelig en del formalkrav til faktura på AutoInvoice; at Produktnr, Antall, Pris, Rabatt, Beløp etc. ikke må undertrykkes – men dette er det skrevet meget om i andre fora, så det lar jeg ligge.
Konklusjon
Nå har jeg jobbet med Visma Business (VBus) i snart 20 år og har lest om og/eller fått presentert nyheter i VBus av forskjellig art. Det har naturligvis kommet mange spennende nyheter i løpet av disse årene – og jeg jubler for mange av dem. Men om man skal sortere nyhetene etter hvilke gevinst-potensiale de representerer – så er det ingen tvil: Dette er den viktigste nyheten på 20 år.
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
a: Smeltedigelen 1, 0195 Oslo