Produkt som ansvarsenhet
Veierland, 4. mai 2025
Visma skrev i vedlegg B til releasenotes for versjon 8.02: Det langsiktige målet er å få på plass en én-til-én-relasjon mellom produkttransaksjoner og de tilsvarende regnskapstransaksjonene. Det er snart 12 år siden versjon 8 kom og vi har ikke kommet nevneverdig nærmere dette målet, enn vi var den gang. Det var realisasjonsjournalene som skulle skape broen mellom produkttransaksjonene i logistikken og hovedbokstransaksjonene i regnskapet. Det var en del som ikke kom på plass før i versjon 10. Jeg skrev om dette med stor begeistring i 2019, se Kontrollsporet, den gang med henvisning til versjon 14. Også her var det en del grelle feil, men de verste ble rettet i versjon 15. Etter versjon 15 har det vel ikke skjedd noe særlig mer enn at en feil i behandlingen av Regnsk. år/per. (ved bokføring av korrigerte kostnader), ble rettet i versjon 18.
Forutsetningen for å få komplette realisasjonsjournaler er at det settes opp bokføring av midlertidig lagerverdi ved kjøp, produksjon og salg. Da får man en bokføring ved ferdigmelding som reverseres ved realisering (fakturamottak eller fakturering). Ulempen ved bokføring av midlertidig lagerverdi, er at ferdigmeldingen ikke kan trekkes tilbake med negativt antall i Ferdig NÅ. Dette er en show-stopper hos de fleste for bruk på kjøp og salg, selv om noen bruker det på produksjon. Heller ikke der er det spesielt nyttig, se Produksjon.
En enkel løsning for å få en én-til-én-relasjon mellom produkttransaksjoner og de tilsvarende regnskapstransaksjonene, er å sette opp produkt som ansvarsenhet. Det må være en av de seks siste (7-12). Dersom noen av produktene har Produktnr på mer enn 10 tegn, må det brukes ansvarsenhet 7. Kopier alle produktene med nr og beskrivelse til denne ansvarsenheten. Kopier deretter Produktnr inn i kolonnen Produkt* på tabellen Produkt. Jeg har satt en * på navnet for å unngå sammenblanding med tabellen Produkt. Deretter angis på tabellen Hovedbokskonto hvilke konti som skal ha med Produkt* på bilag (og transaksjoner). Med dette er splitten på plass.
Jeg illustrerer dette med et eksempel:
1. Det er ikke noe på lager av det som brukes i produksjon av traller, så det kjøpes inn 10 rammer og 50 hjul som varemottas (ferdigmeldes) i februar.
2. Det produseres 10 traller i februar.
3. Det selges to traller, ett hjul og noe andre handelsvarer som faktureres i februar.
4. Det gjennomføres lagertelling i slutten av februar som viser at det på lager bare er fem hjul, men også ett stativ.
5. Inngående faktura for rammer og hjul har dato i mars og prisen på hjul er litt høyere enn forventet. Fakturamottak gjennomføres i mars.
6. Produksjon realiseres i mars.
Det er i dette eksempelet ikke satt opp bokføring av midlertidig lagerverdi. Relevante A&B-opplysninger er slik:
Det må i Regnskapsbehandling være krysset av for Hovedbokstransaksjoner pr. faktura (anbefalt), Hovedbokstrans. pr. ordre ved postering fra produkttrans og Selgende ansvarsenheter som lagerførende.
Jeg har i dette eksempelet brukt løsningen som jeg skrev om i Korreksjonsbilag fra logistikken, slik at bilagsteksten på bilag med opprinnelse 16 og 40 blir mer forklarende.
Og for anledningen har jeg tenkt at jeg ikke trenger detaljert bokføring av handelsvarer, så jeg har opprettet et Produkt* med Produkt*nr «H-varer» og navnet «Handelsvarer» - og satt opp alle handelsvarene opp med dette Produkt*.
Bilagene blir slik:
Kjøp
Jeg har tatt med Opprinnelig pris, frakt, kostpris og verdi selv om vi ikke har bokføring av midlertidig lagerverdi ved kjøp. Dette fordi vi finner igjen den opprinnelige kostprisen i vareforbruket i produksjon og i solgte varers kost senere. Kolonnene med mørk blå kolonneoverskrift er beregnet. Vi ser at realisasjonsjournallinjene mangler både Lagerbevegelse og Lagerverdi. Disse dukker bare opp ved bokføring av midlertidig lagerverdi. Og så ser vi at i bokføringen splittes vare-verdien i innkjøpsverdi (med fradrag for inngående mva) og frakt-påslaget – uten at denne splitten vises på realisasjonsjournallinjene:
Legg merke til at Frakt 1 på produkttransaksjonene er kroner pr. enhet, selv om det på ordrelinjene er angitt som et %-påslag og uavhengig av hvilken valuta det kjøpes inn i. At denne blir summert av VBus gir ingen mening. Legg også merke til at bilagslinjene for fraktpåslaget ikke viser til fakturaen de er beregnet fra, bare ordren.
Produksjon
Jeg har skrevet om produksjon flere ganger tidligere. For å få rett Regnsk. år/per. på produkttransaksjonen til det som er produsert etter realisering, er det i ordrehodet på produksjonsordren lagt inn dato for realisering i kolonnen Fakturadato før realiseringen ble gjennomført.
Det som blir bokført som vareforbruk i produksjon (Trans.type=5) er den opprinnelige lagerkostnaden og beløp på det som ikke er lagerhåndtert.
Endringen i lagerverdi er kostnaden til montering og lakkering som blir aktivert i lager ved produksjonen. Selv om realisasjonslinjene ble enkle å forstå i dette enkle tilfelle, er de ikke alltid slik. Se produksjon.
Salg
Vi ser at vi klarer å spore bilagslinjene tilbake til produkttransaksjonene, uten å gå via realisasjonsjournallinjene, selv om vi ikke har splitt på Produkt*, men her har jeg satt opp fire beregnede kolonner (markert med mørk blå kolonne-overskrift) som hjelper:
VBus bokfører salgsinntektene brutto (før rabatt, inkl. mva) ved faktureringen (Opprinnelse=9). Derfor er det nyttig å se på Beløp før rabatt og Fordelte rabatter på produkttransaksjonene og sammenlikne de med Beløp ekskl. mva på bilagslinjene. Og ved fakturering er det Opprinnelig lagerkostnad som bokføres. Og dersom kostnaden senere blir endret er det Endring i varekost på produkttransaksjonene som må sammenliknes med beløpene på bilag med opprinnelse=40.
Personlig synes jeg kolonnen Lagerkostnad (kr) har feil navn. På salg er Lagerkostnad negativ, mens på kjøp er Lagerkostnad positiv. Kolonnen kunne med fordel hete «Endring i lagerverdi».
Med bokføring av midlertidig lagerverdi ved salg, ville vi ha fått transaksjoner fra ferdigmelding og reversering ved fakturering. Da ville vi også ha fått realisasjonsjournallinjer (fra ferdigmeldingen) med Lagerbevegelse og Lagerverdi. Men med den bedrøvelige konsekvens at ferdigmeldingen ikke kan trekkes tilbake med negativt antall i Ferdig NÅ.
Lagertelling
Ved lagertelling blir det laget to bilagsrader pr. lagersaldo-rad som korrigeres. Eller pr. vareparti om tellingen skjer på lagersaldo. Hvert par havner i hver sin bunt, slik at det kan bli mange bunter etter en omfattende lagertelling. Ved telling på lagersaldo hvor beholdningen reduseres, kan dette berører flere varepartier. Her blir det alltid laget én realisasjonsjournallinje pr. produkttransaksjon. Ved telling på lagersaldo som reduserer beholdningen på flere partier, vil det være en produkttransaksjon og en tilhørende realisasjonsjournallinje for hvert parti – men fremdeles bare én bunt med to linjer for lagersaldo-raden som er telt.
De to varepartiene som ble redusert ved tellingen hadde urealisert lagerøkning da tellingen skjedde. Hjulene var innkjøpt og varemottatt, men ikke fakturamottatt. Tralla var produsert, men produksjonen var ikke realisert. Transaksjonene fra tellingen fikk derfor en foreløpig kostpris og det er denne kosten som bokføres i første omgang. Etter hvert som vareinngangen (kjøp og produksjon) blir realisert – og her med annen kostpris enn opprinnelig – blir endringen i varekost bokført med Opprinnelse=40
Korreksjon av kostnader
Korreksjon av kostnader er for så vidt gjennomgått over, men en samlet oversikt:
Legg merke til at bunten «arver» valuteringdato fra fakturadato i fakturamottaket (og datoen for realisering av produksjo), mens bilagslinjene får andre valuteringsdatoer. Dette fordi det i Bokføringstilfeller er valgt Sett val.dato for kostnadskorrigeringer = fakturaens val.dato. Det som gjelder lagertelling, får valuteringsdato fra telledato, mens det som gjelder vareforbruk i produksjon får dagens dato som valuteringsdato (altså den dagen fakturamottaket ble gjennomført).
Litt mer om bokføring av midlertidig lagerverdi og realisasjonsjournaler
Midlertidig lagerverdi handler om verdiendringen på varelager på transaksjoner hvor ferdigmeldingen ikke endrer realisert beholdning. Dette gjelder kjøp, produksjon (men bare det som produseres, ikke vareforbruket) og salg.
Forutsetningen for komplette realisasjonsjournaler er at det er krysset av for bokføring av midlertididig lagerverdi både i Bokføringstilfeller og Behandlingsmåte. Da får man realisasjonsjournaler og regnskapsbilag ved ferdigmelding. På disse realisasjonsjournallinjene får vi Lagerbevegelse og Lagerverdi – sammen med Bokført verdi. Det må settes opp konti for bokføring, se Kontrollsporet.
Hvis det ikke er valgt bokføring av midlertididig lagerverdi i Bokføringstilfeller, spiller det ingen rolle om det er valgt i Behandlingsmåte eller ikke. Da blir realisasjonsjournalene som vist i dette eksempel.
Hvis det er valgt bokføring av midlertididig lagerverdi i Bokføringstilfeller, men ikke i Behandlingsmåte, blir det ikke laget realisasjonsjournallinjer, hverken ved ferdigmelding eller realisering (fakturamottak/fakturering). Hvis du tenker at du vil bokføre midlertidig lagerverdi på noen, men ikke alle produkter, er konsekvensen altså at du på de produktene hvor midlertidig lagerverdi ikke bokføres – så får du heller ikke realisasjonsjournaler ved realisering. Det er uheldig om du tenker at realisasjonsjournalene kan hjelpe deg med sporingen mellom logistikk og regnskap
Det blir alltid laget realisasjonsjournaler på transaksjoner som endrer realisert beholdning ved ferdigmelding; altså vareforbruk og korreksjoner – inkl. lagertelling. Og ved korrigerte kostnader på avgangstransaksjoner.
Hvis du ikke har ledig ansvarsenhet som kan brukes til Produkt*
Et alternativ kan da være å sette opp Ordreline som ansvarsenhet.
Ekstra opplysninger fra ordrelinje til bilag (og hovedbokstransaksjoner)
Det kan settes opp en trigger som henter relevante verdier som A&B-gruppe, Kontosett og Lagernr fra ordrelinje. Dette forutsetter at samme Produkt* bare finnes én gang på ordren (hvilket vil være normalen om hvert Produktnr har sitt eget Produkt*. Og så fungerer det ikke ved samlefakturering eller samlefakturamottak, siden bilagene da mangler ordrenr.
Hovedbokstransaksjonene i eksemplene over blir da slik:
En av fordelene med å oppdatere kolonnen Produktnr på bilagslinjene, er at opplysninger fra Produkt-tabellen kan hentes til oppdaterte bilag og hovedbokstransaksjoner. Husk at beskrivelsen på ordrelinje kan overstyres, slik at den ikke nødvendigvis er den samme som på Produkt-tabellen. Det samme gjelder A&B-gruppe. Og kontosett kommer vanligvis fra kunde eller leverandør, men kan også overstyres. Så det kan være nyttig å plassere disse i egne kolonner som Ekstern referanse 1-3.
Et eksempel på innkjøp av to handelsvarer, salg av de samme to, lagertelling (reduksjon) og deretter fakturamottak med korrigert kost – og for gøy skyld også med bokføring av midlertidig lagerverdi både ved kjøp og salg:
Selv om det bare er seks transaksjoner i logistikken, så blir det rikelig med transaksjoner i regnskapet.
Det er ikke produkt som ansvarsenhet som bidrar til at vi får så mange transaksjoner i regnskapet. Slik ville det ha vært også uten Produkt*. Dersom produktene 167 og 168 var tildelt hvert sitt Produkt* (slik som 136, 136-1 og 136-2 i forrige eksempel), ville vi fått fire regnskapstransaksjoner til fra salg og tre til fra kjøp. Bokføring av midlertidig lagerverdi og transaksjoner fra lagertelling lar seg knytte til produkttransaksjoner, uten å ha produkt som ansvarsenhet.
Bokføring av korrigerte kostnader, de med Opprinnelse=40, er det verre med. I de aller fleste tilfeller får vi to bilagslinjer pr. produkttransaksjon. Men ikke alltid. I noen få tilfeller, både fra salg og lagertelling, kan VBus lage bilagslinjer basert på flere produkttransaksjoner – også slike som har ulike ansvarsenheter. Jeg har ikke funnet noe klart mønster annet enn at rekkefølgen på realisasjonsjournallinjene er den samme som rekkefølgen på bilagslinjene. Her vil man ha stor nytte av å ha produkt som ansvarsenhet – og la Produkt* samsvare helt med Produktnr, altså ikke bruker noe felles Produkt* slik som «H-varer» i eksempelet over.
Ikke så trigger-happy?
Ikke alle er glade i triggere. Hvis du ser at du trenger f.eks. A&B-gruppe, Kontosett og lagernr plassert i Ekstern referanse 1-3, men kvier deg for å ha en trigger – så kan dette løses med en nattjobb i stedet.
Kort oppsummert
Ambisjonen som Visma skrev om i vedlegg B til releasenotes for versjon 8.02: … å få på plass en én-til-én-relasjon mellom produkttransaksjoner og de tilsvarende regnskapstransaksjonene – kan altså (i all hovedsak) realiseres innenfor standard VBus.
Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg