Veierland, 1. påskedag 2025
I versjon 18.10 kom det en mulighet til å utsette oppdateringen av regnskapssaldoene; at det ikke skjer ved oppdatering av bunt, men på et senere tidspunkt – gjerne styrt av jobbplanleggeren, slik at saldo-oppdateringen skjer på natten. Dette er en problemstilling som bare er aktuell for de med svært mange transaksjoner. Den nye funksjonen kom som en konsekvens av en bekymring hos en virksomhet som ble usikker på om døgnet har nok timer (!) til å få faktureringen gjennom innen fristen for rapportering av resultat til morselskap. Dette er en virksomhet som har mer enn 3 millioner hovedbokstransaksjoner hver måned; de fleste fra salg. Selve faktureringen ble løst ved at det skrives ut det som teknisk sett er ordrebekreftelser i VBus, forkledd som faktura. Deretter konverteres alle ordre, ordrelinjer, ordredokumenter og ordredokumentlinjer – slik VBus gjør ved fakturering. Og så opprettes produkttransaksjoner og bilag til regnskapet. Det kan gjøres betydelig raskere enn det VBus gjør. Jeg har tidligere skrevet om transaksjonstunge miljøer – den gang med et eksempel fra en helt annen virksomhet. Løsningen med å skrive ut ordrebekreftelser forkledd som faktura, ble et langt skritt i riktig retning.
Men selve buntoppdateringen lot vi VBus ta seg av. Og denne er en flaskehals. Faktureringen kan kjøres i bakgrunn av VBS i mange parallelle prosesser, men praksis ikke buntoppdateringen. Årsaken er at for hver bilagslinje, låses hele den aktuelle saldo-tabell (kundesaldo om det er en kundetransaksjon, hovedboksaldo om det er en hovedboktransaksjon, etc.). Man kan stille seg spørsmål om hvorfor VBus låser hele tabellen, når vi vet at bare enkelte rader er i spill (bare de som gjelder den aktuelle kunde, leverandør, driftsmiddel eller hovedbokskonto). Det er fordi det muligens skal opprettes nye rader i tabellen og de kan ikke låses før de er opprettet. Dersom VBus hadde opprettet saldo-rader når nye perioder ble lagt inn, kunne VBus ha begrenset låsingen til de aktuelle radene. Men da ville saldo-tabellene ha blitt svært store. Konsekvensen er at når én bilagsrad blir oppdatert, låses saldo-tabellen slik at ingen andre kan oppdatere noen annen bilagsrad, før den første er ferdig. Da spiller det ingen rolle om faktureringen går i mange parallelle prosesser; når det kommer til buntoppdateringen skal hver bilagslinje gjennom samme kontrollpunkt – og i denne kontrollen er én ad gangen.
Det er altså for å møte denne utfordringen, at muligheten for å utsette oppdatering av regnskapssaldoer (se Regnskapsbehandling) ble introdusert i versjon 18.10. På pluss-siden jobber VBus for en gangs skyld med flere transaksjoner samtidig. Alle transaksjoner på samme hovedbokskonto, behandles under ett når hovedboksaldo oppdateres. Det kan allikevel bli flere oppdateringer av hovedboksaldo på samme konto, om de skal fordeles på flere perioder; VBus oppdaterer som vanlig bare én rad ad gangen, men det blir dramatisk færre oppdateringer enn ved den vanlige buntoppdateringen. Tilsvarende med kunde-, leverandør- og driftsmiddel-saldo. Jeg vil tro at dette har et potensiale for å kraftig redusere tiden til oppdatering av bilag, men det gjenstår å se i et transaksjonstungt miljø.
På minus-siden gjør VBus noe som er rart – og feil. Hvis det finnes en kundetransaksjon hvor saldo skal oppdateres, går VBus gjennom alle kunder med Ordresaldo tilvekst. Og her blir det feil – for det tas ikke hensyn til at denne allerede er oppdatert – og dermed kommer Ordresaldo tilvekst (fra ordre) på nytt hver gang menyvalget Oppdater regnskapssaldoer brukes fra bedriftsopplysninger. Hvis kreditt-kontroll ikke brukes, så spiller det kanskje ikke så stor rolle at Ordresaldo tilvekst er feil på kundesaldo-tabellen, men om det er mange kunder med Ordresaldo tilvekst, så tar denne oppdateringen nødvendigvis noe tid. Og her er noe som er viktig å være oppmerksom på: VBus låser alle saldo-tabellene mens saldo-oppdateringen skjer. Først behandles kunde-transaksjonene og da låses kundesaldo-tabellen. Deretter roter VBus det til med Ordresaldo tilvekst. Så behandles leverandørtransaksjoner – og da låses leverandørsaldo-tabellen. Deretter kommer hovedbokstransaksjoner, med låsing av hovedboksaldo-tabellen (men ikke saldo-tabellene for ansvarsenheter, uten at det gjør noe fra eller til i denne sammenhengen). Til slutt behandles driftsmiddeltransaksjoner, med låsing av driftsmiddelsaldo-tabellen. Låsingen oppheves først når alle saldo-tabellene er oppdatert. Ved registrering av salgsordre, vil VBus forsøke å oppdatere kundesaldo-tabellen med endring i Ordresaldo tilvekst. Mens regnskapssaldoene oppdateres, vil det ikke være mulig å lagre endringer på salgsordre som endrer Ordresaldo tilvekst, fordi kundesaldo-tabellen er låst. Det betyr at man må tenke grundig gjennom når regnskapssaldoene skal oppdateres, hvis utsatt saldo-oppdatering skal benyttes. Og – inntil dette er rettet – må kundesaldo regenereres umiddelbart etter at regnskapssaldoene er oppdatert dersom kreditt-kontroll er i bruk. Hvis du skulle være i tvil; feilen er ikke bare i versjon 18.10 – det er feil både i 19.00 og 19.10 også.
Da jeg fikk denne «løsningen» presentert av Visma, sa jeg at det ville være en bedre løsning om det var en mulighet på bunten å angi at oppdatering av regnskapssaldoene skulle utsettes. Dette fordi det bare være noen få typer av bunter (f.eks. bare de med Opprinnelse=9 fra faktureringen) som har et transaksjonsvolum som gjør at utsatt saldo-oppdatering er aktuelt. Og et relativt lite antall berørte konti. For de som jobber med andre deler av regnskapet, vil det være svært forstyrrende å hele tiden måtte vente på at regnskapssaldoene skal oppdateres. Det kan være fristende å tenke at man kan kjøre ut regnskapsrapporter og velge bort alternativet Les saldoer samlet (altså å lese transene), for når det lages rapporter så ignoreres transaksjoner hvor saldo ikke er oppdatert. I versjon 17.10 kom det en ny tabell, som egentlig er et view: Hovedbok periodesaldo. Denne er basert på transaksjonene alene – inklusive de som ikke er med i saldo, men jeg ville kvie meg for å åpne den i et transaksjonstungt miljø. Prøv før du går til lunch en dag og se om det har skjedd noe når du kommer tilbake. Mitt forslag om å gjøre utsettelse av saldo-oppdatering til en egenskap på bunten, falt som vanlig på stengrunn. Utviklingsavdelingen hadde bestemt seg for at deres løsning var den beste. Og de ombestemmer seg ikke før Dovre faller.
Jeg har skrevet en SQL-prosedyre som oppdaterer kundesaldoene – og som bare behandler relevante rader – og selvfølgelig uten å rote det til med Ordresaldo tilvekst. Jeg skal villig innrømme at det tok lengre tid enn jeg hadde tenkt, for den indre struktur i kundesaldo-tabellen er på ingen måte åpenbar – spesielt ikke det som skjer ved overgang fra ett år til et annet, men det får nå så være. Så om denne prosedyren kjøres før menyvalget Oppdater regnskapssaldoer brukes fra bedriftsopplysninger, så har du en effektiv saldo-oppdatering.
Resten av min blogg kan du lese her: frode.antun/VBus/blogg