Oslo, 8. oktober 2018

Det hender kunder forteller meg at rapportene fra Visma Rapportering ikke stemmer med Visma Business (VBus); at det er noe feil med åpne poster ett sted. Ofte handler det om inkonsistens i reskontro. Det kan man pådra seg om en skal oppheve matching på en post, men ikke opphever matchingen på motposten. Hadde en jurist gjort dette, ville han ha sagt at det har skjedd ved en inkurie. Fort gjort. Alle gjør slikt iblant. Jeg tok T-banen her om dagen; betalte med Ruter-appen, trodde jeg. Gikk i egne tanker og la telefonen i lomma etter å ha tykket på kappen merket «Bekreft kjøp». Det oppdaget jeg da det var kontroll der jeg gikk av. Ruter-kontrolløren oppdaget det også. Så jeg fikk en 1.200 kroners påminnelse om å sjekke at kjøpet faktisk blir gjennomført når jeg tar T-banen. Nok om det.

Er man i ferd med å oppheve bare den ene siden av en matching, så gir VBus en advarsel. Ikke alle leser meldingene som dukker opp. Og jeg innrømmer villig at ikke alle meldinger er like klare. En personlig favoritt er denne: The creator of this message did not specify a reason. Jeg blir så glad når jeg kommer over slike. Men advarselen ved ensidig matchingsoppheving er ganske godt formulert:

Skal man være pirkete (og det kan jeg være; man skal ikke slumse med språket, sier vi i vår familie) så er det internt i reskontroen inkonsistensen oppstår: Summen av åpne poster stemmer ikke med summen av transaksjoner på de berørte konti (kunder eller leverandører). Eller om du vil: På transaksjoner med Restbeløp=0 blir summen av Beløp ikke lik null. En naturlig konsekvens er at åpne poster ikke stemmer med hovedbok. Men i alle fall: Riktig svar på spørsmålet er NEI, som VBus faktisk anbefaler.

Har man først pådratt seg slik inkonsistens synes det godt i vindu for konsistenskontroll:

Noen har dette i en egen fane i et vindu som heter Oppdateringer. Andre har dette som en fane i et vindu med navn Avstemming under Regnskap -> Systemkontroll.

 

Har du kommet i uløkka og pådratt deg slik inkonsistens, må du lokalisere de(n) transaksjonen(e) hvor matching skulle ha vært opphevet. Prosedyren er først å finne hvilke(n) kunde(r) eller leverandør(er) det gjelder og deretter lokalisere postene det gjelder. Bruk vindu for Kundekontroll (eller Leverandørkontroll) og endre sortering slik at det bare vises bruddlinjer. Let etter rader hvor Beløp ikke er lik Restbeløp:

 

 

Dersom lista er lang så kan det være en idé å skrive den til Excel, legge til en kolonne som viser differansen mellom Beløp og Restbeløp og bruke filter i Excel til å finne de rader hvor differansen ikke er null. Når rett konto er funnet så endrer du sorteringen tilbake slik at detaljlinjene vises:

 

Nå må du lete etter de(n) rad(ene) hvor summen av matchingene (som vises nederst i vinduet) ikke er det samme differansen mellom Beløp og Restbeløp. Altså; for linjer hvor Beløp er lik Restbeløp skal det ikke være noen matchinger. For linjer med Restbeløp=0 skal summen av matchinger være lik Beløp. I eksempelet over ser vi at bilagsjournal 70, rev.nr 305 har null i restbeløp, men det mangler matchinger. Det er vel all grunn til å tenke at betaling med motref 1000468 opprinnelig var matchet mot denne faktura, men at matchingen på betalingen (bilagsjournal 131, rev.nr 27) er opphevet ensidig.

For å reetablere konsistens må matchingen på fakturaen også oppheves. Da får man selvfølgelig meldingen om at Summen av de utvalgte transaksjonene blir ikke 0. Og nå er det riktig å svare JA på spørsmålet om du vil fortsette.

 

Riktig metode for å oppheve matchinger er altså å markere begge postene som er matchet og så oppheve matchingen, slik:

 

Det er mulig å blokkere for å oppheve matchinger som ikke går i null i adgangskontrollen. Det anbefaler vi egentlig i alle adgangsgrupper:

Når denne begrensning er satt vil brukere som er i ferd med å pådra seg en inkurie, få denne meldingen i stedet:

Og så kan man sette opp en egen adgangsgruppe hvor det tillattes å oppheve til ubalanse hvis det skulle være behov for det.

 

Har du kommet i uløkka og den er blitt overstigelig, så ta kontakt med oss. Hvis vi har tilgang til SQL-server kan vi kjøre noen skript (som det heter på vårt stammespråk) som merker alle poster med matchingsfeil. Dette ligger utenfor brukerstøtteavtalen, men da har du det hele på plass i løpet av et par timer.

 

 

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