Oslo, 02.11.2019

VBus, versjon 14.01.1

Godot kom, snudde i døra, ble borte en stund før han dukket opp igjen. Og ikke alt han har i sekken er like bra.

For ett år siden skrev jeg om den nye designet i VBus; Nordic Cool 3.0 og hvordan vinduene i Byrå-versjonen av VBus har fått et løft. Men ikke i standard VBus og at mens vi venter (på Godot), er det ikke så vanskelig å konvertere eksisterende vinduer til dette designet.

I august skrev jeg om ryktene om Godots ankomst.

Vel, Godot kom 16. september, men snudde i døra (ble trukket tilbake) og dukket ikke opp igjen før 10. oktober – da som versjon 14.01.1. Og med denne altså nye vinduer i Nordic Cool 3.0. Omsider.

De nye vinduene er ikke umiddelbart tilgjengelig, slik de er i Byrå-versjonen. Man må kopiere de vinduene man vil bruke fra en mappe med navnet 999. Standard layouts. Og selv om det er gjort et godt stykke arbeid, er det noe som mangler i finish’en på noen av dem. På noen skjermer kommer deler av sideelementene på utsiden av skjermen. Det skal ikke så mye til for å rette opp dette på de vinduene som man ønsker å benytte, men personlig hadde jeg ønsket meg at de var noe bedre i designet. Og på samme måte som med de gamle standard­vinduene er det fremdeles noen irriterende feil i utvalgene, så snakk med forhandleren din før du tar dem i bruk.

Merk at på nyinstallasjonene er det de nye vinduene som er standard vinduer.

For de som bruker EDI-klokka og legger inn edi (eller xml) -meldinger både i IMPORTS-mappa og ORDERSR-mappa, f.eks. ved at det legges inn endrede kunde­opplysninger i IMPORTS, så har det vært ganske irriterende at ORDERS-meldingene har blitt lest inn før IMPORTS. Vi har sett mange kreative løsninger for å sørge for at IMPORTS-meldingene leses først – og jeg skal ikke gå igjennom alle de fikse variantene vi har kommet over. For, fra og med versjon 14.01.1, leser EDI-klokka IMPORTS først og de andre mappene med ordre etterpå. Dermed er det mange kreative løsninger som kan skrotes og man kan gjøre det som er intuitivt; legge meldinger om å opprette og/eller endre kunder, prosjekter, produkter etc. i IMPORTS-mappa og ordrene som skal leses, endres eller behandles i sine respektive mapper uten å tenke på innlesningsrekkefølge.

Og så har det kommet en ny charmerende funksjon. Om du har åpnet et vindu, gått til en bestemt side og plassert markøren på en bestemt rad og en bestemt kolonne, så kan du høyre­klikke og velge alternativet Få delbar lenke. Denne kan du f.eks. lime inn i en epost og når mottaker av eposten klikker på lenka, vil han eller hun (om nødvendig starte VBus) åpne dette vinduet og plassere markøren på den linjen og i den kolonnen som du hadde plassert markøren i (altså på stammespråket til VBus: I det aktive sideelement, på den aktive raden og i den aktive kolonnen). Fikst når du har spørsmål om noe du har fått øye på i VBus. Merk at du ikke kan gjøre dette fra et vindu som ikke er lagret (evt. endret uten at endringen er lagret). Skal du benytte deg av denne muligheten, så bør du gi beskjed til de som oppgraderer VBus hos deg, for det må gjøre noen innstillingsendringer i Windows for å få det til å virke, men det er fort gjort.

Selv om det er mye bra nytt i versjon 14.01.1 – les releasenotes – så er det noe som ikke er så bra. En del av de som har sendt fakturaer til AutoInvoice har fått dem avvist av PEPPOL med en melding som innledes med:

XML Invalid | [BR-CO-14]-Invoice total VAT amount BT-110 = Σ VAT category tax amount BT-117 ....

Det er ikke lett å få øye på hva som er galt, men jeg anbefaler å bruke behandlingsmåten Ikke beregn rabatt ut fra standardpris som du finner under fanen Priser i behand­lingsmåte på produkt og ordre­linje. Det er åpenbart feil i versjon 14.01.1 at den XML som lages i noen tilfeller får med et segment som ikke skulle være der eller har feil beløp i segmentet. Jeg skal spare dere for detaljene om hvorfor det blir feil i enkelte tilfeller og ikke i andre – selv til samme kunde, men det har med hvordan VBus behandler standardprisen å gjøre.

Siden det å endre denne behandlingsmåten faktisk også påvirker bokføringen av fakturaen, tenker jeg det er greit å skrive noe om hva Ikke beregn rabatt ut fra standard­pris faktisk betyr i VBus: I norsk standard konto­plan er konto 3080 Rabatter avg.pl. og 3180 Rabatter avg.fritt. Og om man bruker konto 3000 til Salg avg.pl. og 3100 Salg avg.fritt, så er det helt i henhold til standard kontoplan.

Har vi et produkt med pris (i Pris/rabatt-matrisen) satt til 100 så vil det selvfølgelig være denne prisen som VBus foreslår på nye ordrelinjer. Hvis vi nå gir 10% rabatt blir det bokført 100 til kredit på konto 3000 eller 3100 (altså tilsvarende Beløp før rabatt) og 10 til debet på konto 3080 eller 3180 (altså rabatten). Det er til å forstå.

Dersom vi i stedet for å gi rabatt endrer prisen fra 100 til 90, så betrakter VBus dette som en implisitt rabatt og bokføringen blir den samme. Til dette bruker VBus kolonnen som heter Standardpris som tildeles samme verdi som Pris ved oppslag i Pris/rabatt-matrisen. Du kan endre prisen, men ikke Standardpris. Og om du endrer prisen så beregner VBus den implisitte rabatten i en kolonne som heter Fordelte rabatter. Det er på denne måten VBus allikevel klarer å bokføre den implisitte rabatten på rabattkontiene.

Hvis man ikke har pris i Pris/rabatt-matrisen, så settes Standardpris til det Pris er første gang ordren lagres. For diverse­produkter hvor prisen kalkuleres individuelt på hver enkelt ordrelinje, kan man få nokså store forskjeller mellom Pris og Standardpris. Det gir i slike tilfeller ingen mening å splitte inntekten på en salgs­konto og en rabatt­konto. Derfor kan man sette behandlings­måten Ikke beregn rabatt ut fra standardpris på produkter og ordrelinjer hvor standard­beregningen ikke passer. Og det er flere VBus-brukere som ønsker at bare eksplisitt rabatt (det som følger av Rabatt %) skal bokføres på rabattkonti. Da setter man denne behandlingen på alle produkter.

Slik versjon 14.01.1 lager XML til AutoInvoice, så anbefaler vi denne innstillingen på alt som skal denne veien. Vi får tro at det kommer en versjon 14.01.2 om ikke lenge. Alternativt må vi vente på 14.10 som kommer i desember. Men for å sørge for at inntektene strømmer inn som de skal frem til ny versjon er installert, så anbefaler vi altså endring i behandlingsmåten. Snakk med forhandleren din om å legge inn en sekvens i ordrelagringsprosedyren som gjør dette automatisk, så slipper du å tenke på det.

 

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

 

 

Frode Antun

Løsningsrådgiver

m: + 47 911 46 751

e: frode.antun@amesto.no

a: Smeltedigelen 1, 0195 Oslo

w: amestosolutions.no