Oslo, 2. søndag i advent 2021
Versjon 16.10
Den er ikke sluppet enda, men den kommer etter planen i løpet av neste uke: Versjon 16.10 av VBus.
Jeg hadde ikke store forventninger til at denne skulle bringe noe spennende nytt, med det fokus som Visma nødvendigvis har hatt på mva i 2022 og satsingen på VBC. Men jeg tok feil (og det skjer jevnlig).
For fem år siden skrev jeg en trigger til lagersaldo-tabellen som fanget opp at lagersaldoen ble regenerert og endret teksten i kolonnen Endret av bruker ved å sette inn «Regenerert av» foran brukernavnet og legge inn dato og kl.sl. for regenereringen i Lageroppl. 2. Siden Endret av bruker endres straks noen gjør noe som påvirker Lagersaldo (og det skjer bare ved å tenke på den), så blir det lett å ta stilling til om det er noe poeng å regenerere lagersaldoen eller ikke – altså om lagersaldoen er endret siden siste regenerering eller ikke. Siden jeg har byttet forhandler i mellomtiden, har jeg (av juridiske hensyn) ingen idé om hvor mange som har denne triggeren installert. Men i versjon 16.10 kommer det en ny kolonne i tabellen Lagersaldo; Regenerert dato. Personlig skulle jeg ha ønsket meg Regenerert kl.sl. og Regenerert av i tillegg og kanskje et flagg at typen Endret etter siste regenerering, men det er bare fordi jeg er en gretten gammel gubbe. Bente (min meget bedre halvdel) kalte meg det i en samtale med ett av våre barnebarn – og det fant han umåtelig morsomt. Men jeg blir genuint glad når jeg ser at en spesialløsning, som jeg har installert hos mange, kan erstattes med av standardfunksjonalitet.
For tre år siden skrev jeg om lagertelling. Jeg var ikke innom telling gjennom året; det noen kaller rullerende lagertelling. Det skal jeg skrive om neste søndag. For å kunne tilfredsstille bokføringsforskriftens § 6-1 om dokumentasjon av varelager kan den (sitat): som fører et betryggende lagerregnskap … foreta opptelling i løpet av året, forutsatt at tilgang og avgang fra opptellingstidspunktet til regnskapsårets slutt kan dokumenteres på tilfredsstillende måte. Den som teller på lagersaldo, kan støtte seg til Forrige telledato og Forrige telt antall for å tilfredsstille dette kravet. Hvis du registrerer Serienr og/eller Holdbarhetsdato ved vareinngang, eller bruker annen Plassering enn Normal plassering på Lagersaldo, så må tellingen skje på Vareparti. Frem til og med versjon 16.01 finnes ikke Forrige telledato eller Forrige telt antall på Vareparti. Det kommer i versjon 16.10 – sammen med Forrige telt av.
På Ordrelinje er det en logikk omkring pris og beløp av typen: Pris – rabatter = Pris etter rabatt x Valutakurs = Pris etter rabatt (kr) og så fortsetter det med å gange opp med Antall for å komme frem til Beløp (kr). Det er ikke mulig å endre Pris etter rabatt, men frem til nå har det vært mulig å endre Pris etter rabatt (kr) og det er helt ulogisk. De som har gjort det har endt opp med nokså rar bokføring. Fra og med versjon 16.10 er det ikke mulig å endre Pris etter rabatt (kr) på annen måte enn ved å endre Pris, rabatter eller Valutakurs.
Det finnes en funksjon i VBus som heter Sanering av Produkttransaksjoner. Funksjonen har vært der lenge og flytter rader fra Produkttransaksjon til tvilling-tabellen Produkttransaksjon før komprimering. Språkbruken er litt inkonsistent, men det får så være. Disse to tabellene har identisk kolonnestruktur og de som har lagt DME-felt til på den ene tabellen, må legge de(t) samme felt til på den andre. Rutinen ber om en dato og flytter deretter rader med Trans.dato frem til og med denne dato fra den ene til den andre tabellen. Det fremgår ikke av hjelpeteksten, men for lagerhåndterte transaksjoner flyttes bare rader hvor partiet er slettet. Og slik at det ikke flyttes noen av transene om ikke alle transene på samme parti flyttes. Hensikten er å redusere størrelsen på tabellen Produkttransaksjon, noe som kan gi bedre ytelse siden tabellen oppdateres både ved ferdigmelding og fakturering. Personlig synes jeg det er litt klossete at kriteriet for flyttingen er knyttet til Trans.dato, som settes når ordrelinjen opprettes. Jeg synes det ville være mer naturlig å knytte kriteriet til når transaksjonen ble ferdigbehandlet, f.eks. Fakturadato, Realisert år/periode eller Regnsk. år/per. Jeg har som regel brukt egen prosedyre for å flytte rader hos kunder når problemstillingen kommer opp. Mange har vært skeptisk til å splitte statistikken på to tabeller på denne måten. Hos noen har vi satt opp en av Fri informasjon-tabellene som et view som viser begge tabellene. Hos andre har vi brukt DME til å gjøre det samme, noe som blir en langt bedre løsning. Men nå kommer dette i standard VBus.
For utenlandske virksomheter og for norske med import og/eller eksport, kan det være av interesse at det blir mulig å ha ulikt format på dato, kl.sl. og beløp. Det kommer et nytt felt i tabellen Språk; Områdeformat. Dette brukes på dokumenter som er språkstyrt.
Det har kommet nye SAF-T-konti. Husk å importere Standard_account.txt fra …\Visma\Business\Nor.Int-mappen til Standardkonto i VBsys etter at VBus er oppgradert til versjon 16.10.
Som jeg skrev forrige søndag, kommer det støtte for standardiserte kommentarer i mva-meldingen. Dette er nytt felt; Utvalgt merknad i tabellen Avg.kode forklaring.
Og så er det noen klipp og lim-problemer som er løst. Jeg trodde de egentlig ble løst i versjon 16.01, men da tok jeg vel feil der.
Av de mer eksotiske endringene nevner jeg bare at negativ Totalrabatt % fra 16.10 støtter når fakturaen sendes til Visma.net AutoInvoice. Men ikke Totalrabattbeløp.
Du kan lese om alt som er nytt i versjon 16.10 her.
Siden jeg ikke har skrevet noe om versjon 16 tidligere – bortsett fra om mva i 2022 – så kan jeg nevne at fra og med versjon 16.01 finnes VBus både som 32-bits og 64-bits versjon. Forskjellen er først og fremst hvor mye minne programmet kan disponere. Vi tester ut x64 i et transaksjonstungt miljø for tiden og er spent på om det gjør noen forskjell. Personlig er jeg skeptisk. VBus jobber med én transaksjon ad gangen og det er ikke effektivt. Jeg har skrevet om dette tidligere. Men jeg har tatt feil tidligere også – og det kommer til å skje på nytt. Vi holder på å sette opp et testmiljø hos en annen kunde og da er det viktig at TEST holdes adskilt fra PROD. Jeg glemte å endre SMTP-adresse i TEST-miljøet og brått gikk en ordrebekreftelse fra TEST ut til en kunde som meldt tilbake at han ikke hadde bestilt noe. SMTP-adressen ble endret raskt til en som hadde blokkering på utgående epost. Og så fikk jeg spørsmålet om jeg kunne garantere at det ikke ville skje blanding av TEST og PROD flere ganger. Jeg svarte – som sant er: Vi tror vi har kontroll, inntil det motsatte blir bevist.
Ellers var det ikke så mye spennende i 16.00, 16.01 eller 16.01.1 – men andre mener sikker noe annet.
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