Oslo, 31. desember 2022

Priser, rabatter og kostpriser

For 40 år siden var kunstig intelligens eller AI; Artificial intelligence som det heter på nynorsk – i vinden. Jeg husker at jeg i 1980 leste Douglas Hofstaters bok Gödel, Escher, Bach: An Eternal Golden Braid; A metaphoriacal fugue on minds and machines in the spirit of Lewis Carroll som han fikk Pullizer-prisen for. Boken omtales bare som GEB blant kjennere. Kurt Gödel var den som for nesten hundre år siden ble kjent for sitt teorem om at man (litt forenklet formulert) matematisk kan bevise et uendelig antall usannheter samtidig som det finnes et uendelig antall sannheter som ikke lar seg bevise. Det er vel som en middels norsk rettsak. Maurits Cornelis Escher var en grafiker hvor det ikke er noe galt med detaljene i bildene, men hvor det åpenbart er noe helt feil i helheten. Dette er bilder som ikke kan beskrives; de må oppleves. De som ikke kjenner Johann Sebastian Bach, har alvorlige hull i sin allmenn­kunnskap og jeg kan ikke annet enn å gi uttrykk for min dypeste medfølelse. Men det som binder de tre sammen er rekursjoner. Og det er ingen dissonans her, selv om det kunne virke slik.

Jeg husker ikke om det var i boken fra 1979 eller om det var i forordet til opplaget som ble skrevet til 20-års jubileet i 1999, at Hofstater skrev at han tenkte at en bil aldri ville kunne bli «smart» nok til å oppdage at en elg, syklist eller barn kom ut i vei­banen og reagere hensikts­messig raskere enn en edru sjåfør. Men så er det ingen som har vært i stand til å forestille seg den endring i kapasitet, volum, kostnad og hastighet som data­maskiner har gjennom­gått de siste 20 (for ikke å snakke om 40) år.

Nå er kunstig intelligens aktuelt igjen. Og vi har fått et mer nøkternt syn på det. Det er ikke som roboten i Douglas Adams’ The Hitchhiker’s Guide to the Galaksy som er trist og lei seg for sin inkompetanse; manglende evne til å gjøre alt det de andre kan. Eller som HAL i filen 2001: En romodyssé fra 1968. Vi snakker nå om maskinlæring, mønster- og adferd-gjenkjennelse. Og ser at dette tas inn i applikasjoner som Visma Business (VBus) som et ledd i å effektivisere daglig­dagse gjøre­mål. Jeg over­hørte her om dagen en hissig diskusjon mellom en kunde og en leverandør av en applikasjon (ikke VBus) hvor opp­gradering førte til at all tidligere maskin­læring gikk tapt. Vi har sannelig vendt oss til tanken om at maskinelt ervervet kunn­skap, er verdier som skal hegnes om.

Ett område hvor vi kunne trenge litt ekstra intelligens, er det å forstå hvordan Visma Business (VBus) henter priser og rabatter fra Pris- og rabatt­matrise (gjerne omtalt som Pris/rabatt-matrisen eller bare P/R-matrisen). Hjelpeteksten på området er ikke spesielt utfyllende. Gjennom de årene jeg har jobbet med VBus har jeg fått mange spørsmål om hvordan VBus henter pris, rabatt og kostpris til ordre­linje. Av grunner jeg ikke skal kjede dere med har jeg den siste tiden måtte foreta et dyp­dykk i denne delen av VBus og blir frem­deles (etter 20 år) over­rasket over hva VBus gjør. Men jeg drister meg til å gi en frem­stilling:

Det vanligste og enkleste oppsett er slik at det for hvert (eller i alle fall de fleste) produkt(er) legges inn én Innkjøpspris og én Utsalgspris på én og samme rad i Pris/rabatt-matrisen. På nye rader oppdaterer VBus Kostpris, som settes lik Innkjøpspris. Det spiller ingen rolle om man registrerer Kostpris eller Innkjøpspris; den andre følger automatisk etter på nye rader. I Ordrebehandling kan man angi Overskriv alltid pris i Pris- og Rabattmatrise og da vil VBus kopiere Innkjøpspris til Kostpris også ved endring av Innkjøpspris, men ikke omvendt. Når det legges inn et Antall på en salgs­ordre­linje vil VBus hente Utsalgspris fra Pris/rabatt-matrisen og bruke denne som Pris. Jeg kommer tilbake til fremmed valuta senere. Dersom en salgs­ordre­linje skal Unntas lager­håndtering, hentes også Kostpris fra Pris/rabatt-matrisen. For salgs­ordre­linjer som lager­håndteres, hentes kost­prisen fra Gj.snittlig kostpris (som før i tiden ble omtalt som FIFO-pris) på Lagersaldo.

Spesialpriser

Det kan legges inn priser som bare skal gjelde for enkelte kunder, prosjekter, enheter eller liknende. Det er her VBus har sin styrke. Når det legges inn en rad i Pris/rabatt-matrisen med ett bestemt Kundenr, så gjelder denne prisen bare for denne kunden. Legges det inn en rad i Pris/rabatt-matrisen med både ett bestemt Kundenr og ett bestemt Lagernr, så gjelder denne prisen bare for det som leveres fra dette lager til denne kunden. Det du legger inn av slike pris­styrende felt i Pris/rabatt-matrisen, virker avgrensende på når linjene blir relevante. Det er litt som når du kommer til billett­luka, forteller hva du vil ha og legger alle medlems/rabatt-kortene på bordet. Du kan være medlem av OBOS, Siviløkonomforeningen (som har byttet navn til noe annet), Polyteknisk forening, Coop; du kan ha Trumf-kort, Yx-kort, etc. De som står bak disse kortene, kan ha gjort avtaler med den du skal handle med og den som sitter i billett­luka sjekker hvilken avtale som gir gunstigste netto-pris for deg som kjøper. Det er mange felt som i tillegg til Produktnr kan brukes til denne avgrensningen: Strukturproduktnr, Inngår i struktur (se mer om strukturer nedenfor), Produktprisgr. 1, …2 og …3, Lagernr, Partinr, Kundenr, Kundeprisgr. 1, …2, …3, Lev.nr, Ans.nr, Ansattprisgr., Lønnssatsnr, Ordrenr, Ordreprisgr., Fra postnr, Til postnr, Leveringsbet., Leveringsmåte, alle 12 ansvarsenheter, Fra dato, Til dato, Enhet og Valuta (se mer om valuta nedenfor) for å nevne noen.

Et eksempel:

Normalprisen for produktet er 19.500, mens medlemmer får det for 18.500 og andels­eiere får det for 18.000. I perioden 15. april til 15. mai er prisen for «hvem som helst» satt til 18.500, mens medlemmer fremdeles får det for 18.000. Dersom prisen for «hvem som helst» i perioden 15. april til 15. mai var satt til 17.000, slik:

   

vil også medlemmer og andelseiere nyte godt av den gode prisen før sesong­start. Produktnr 5900 er «Start­pakke - Tiger Woods Pro» …

Valuta

Hvis pris i Pris/rabatt-matrisen er oppgitt uten valuta, forstås det som standard valuta, slik det er angitt i Bedriftsopplysninger. En ordre i fremmed valuta, vil først lete etter priser i Pris/rabatt-matrisen i samme valuta som ordren og bruke dem, om de finnes. Hvis ikke, brukes de prisene hvor det ikke er oppgitt valuta, og det regnes om til ordrens valuta med den valuta­kurs som er satt her. Merk at om du har lagt inn priser i NOK, så vil disse ikke bli benyttet på ordre i annen valuta, selv om det ikke finnes noen priser i ordrens valuta. Dette gjelder både kjøp og salg.

Rabatter

For de fleste vil det være enklere å prisdifferensiere med rabatter – og jeg er lei for det; men nå blir det brått mer komplisert. På ordre­linjen er det ikke bare én rabatt-kolonne, men seks (!) rabatt %-kolonner og seks (!) rabatt-beløp-kolonner. Fem av hver av disse (% og beløp) kan legges opp i Pris/rabatt-matrisen og det må angis hvilke rabatter som VBus skal søke etter (i Pris/rabatt-matrisen). Dette settes i Rabattforslag (i Bedrifts­opplysninger). Dersom det er angitt slik:

vil VBus lete etter Utsalgsrabatt % 1, Utsalgsrabattbel. 1 og Utsalgsrabatt % 2 (til salgs­ordre). Det er ikke mange som angir rabatt som et beløp ute hos kunder, men det kan brukes og det kan settes opp i Pris/rabatt­matrisen. På ordre­linen kan du altså ha seks rabatt % og samtidig seks rabatt­beløp på samme ordre­linje. Og de fem første av hver type kan hentes fra pris/rabatt-matrisen, mens Rab. % 6 og Rabattbeløp 6 kan brukes på ordre­linjen uten fare for at VBus foreslår noe. Hjelpe­teksten til disse felt er feil. Hvis vi har en ordre­linje med 100 i pris og rabatter slik:

så er grunnlaget for Rab. % 2, pris etter rabatt 1 (altså 80) – siden det er angitt i Kjederabatter at VBus skal trekke fra rabatt 1 (både % og beløp) ved beregning av Rab. % 2. Dersom dette ikke var valgt i Kjederabatter, ville Pris etter rabatt ha blitt 60. Overraskende for mange er at det inntil versjon 16.10 var mulig å endre Pris etter rabatt. Da ble avviket plassert i Rabattbeløp 6 slik at regne­stykket frem­deles stemte.

VBus søker flere ganger i Pris/rabatt-matrisen; først etter pris, deretter etter rabattene – ett søk for hver rabatt. VBus leter etter den beste kombinasjon av Pris og rabatter sett fra kjøpers ståsted (altså lavest mulig Pris etter rabatt). Dersom det i Rabattforslag er krysset av for Søk etter pris – rabatt­beløp vil VBus ikke lete etter rabatt­beløpene hver for seg, men lete etter laveste pris etter rabatt­beløpene (altså at utsalgs­rabatt­beløpene ligger på samme rad i pris/rabatt-matrisen som Utsalgspris).

Det er viktig at du bare ber VBus om å søke etter det du bruker. For de aller fleste vil det ikke være ønskelig å bruke mer enn én rabatt i % og ingen rabatt­beløp. Da er det viktig at det kun krysses av for nettopp dette – av to grunner. Det første gjelder hastighet; ikke be VBus gjøre mer enn nødvendig. Det andre gjelder brukerfeil; de gangene jeg har sett at noen har lagt inn utsalgs­rabatt­beløp i Pris/rabatt-matrisen, har det skjedd ved en inkurie. Det er best om VBus overser feilen. Det er ikke noe i veien for å bruke Rab. % 2 på ordre­linje selv om VBus ikke leter etter Utsalgsrabatt % 2 fra Pris/rabatt-matrisen. Da er det viktig å ha tenkt over om Rabatt % skal trekkes fra før beregning av Rab. % 2 eller ikke, så Kjederabatter kan være relevant selv om VBus ikke skal søke etter andre rabatt­forslag enn Utsalgsrabatt % 1.

Ofte vil rabatt være knyttet til kunder, prosjekter eller liknende uavhengig av produkt. For mange vil det være hensikts­messig å knytte produktene til en produkt­pris­gruppe og kundene til en kunde­pris­gruppe, f.eks. slik:

Da må den enkelte kunde som er andelseier settes opp med 1 [Andelseier] i Kundeprisgr. 1, mens medlemmene må ha 2 [Medlem] i Kundeprisgr. 1. Tilsvarende må alle produktene som det skal gis 10% rabatt på til medlemmer settes opp med 1 [Golfkøller og baller] i Produktprisgr. 1, mens de det skal gis 8% rabatt på (fremdeles til medlemmer) skal ha 2 [Traller og liknende] i Produktprisgr. 1. Det finnes tre kunde­pris­grupper som fungerer uavhengig av hverandre – og tre produkt­pris­grupper som også fungerer uavhengig av hverandre. Det kan finnes et alternativ 1 i Kundeprisgr. 1, som er noe helt annet enn alternativ 1 i Kundeprisgr. 2 og Kundeprisgr. 3. I eksempelet over får Andels­eiere 15 % rabatt på alt de kjøper uavhengig av Produktprisgr. 1. Hvis vi nå tenker at enkelte andels­eiere skal ha ekstra rabatt; f.eks. slik:  

 

Alternativt kan det settes opp slik:

Dette siste krever at det i Rabattforslag er krysset av for at det skal foreslås både Utsalgsrabatt % 1 og Utsalgsrabatt % 2 – og at det i Kjederabatter ikke er krysset av for Trekk fra … ved beregning av … Og så må det – når man ønsker at VBus skal foreslå pris eller rabatt (eller kostpris) ut fra rader i Pris/rabatt-matrisen uten Produktnr – krysses av for hvilke, i Pris/rabatt-krit.:

Kolonnen til venstre gjelder salg og utleie. Kolonnen i midten gjelder innkjøp. Siste kolonne gjelder andre ordre – og da i praksis kost­priser. Dersom det er lagt inn en rad i Pris/rabatt-matrisen f.eks. med et Kundenr, men uten Produktnr, vil VBus ignorere denne raden selv for ordre med samme Kundenr – når det ikke er krysset av for at VBus skal lete etter slike rader.

Brukes det flere rabattkolonner (enten det er i % eller beløp), må man tenke igjennom hvordan dette blir presentert på ordre­dokumentene. Et enkelt alternativ er å vise Pris etter rabatt i stedet for Pris og de ulike rabatt­kolonnene. Dersom man ikke bruker Kjederabatter og bare %-rabatter, kan man lage en beregnet kolonne, f.eks. slik:

I AutoInvoice vil bruk av mange ulike rabatter på samme ordrelinje, ikke skape noe problem. Auto­Invoice forholder seg bare til samlet rabatt omregnet til beløp på hver ordre­linje.

Dersom du ikke bruker Totalrabatt % (eller Totalrabattbeløp – merk at hjelpe­teksten omtaler feil kolonne) i ordre­hodet eller gruppe­rabatter, vil Fordelte rabatter vise den samlede linje­rabatten. Da kan du på ordre­dokumentene vise Pris, Antall, Beløp før rabatt, Fordelte rabatter og Beløp. Rabattene kan alternativt beregnes slik:

Når det kommer til bokføring av salgs- og utleie­inntekter, så bokføres Beløp før rabatt og Fordelte rabatter hver for seg. Det er egne konti for salg og rabatt i tabellen Avgifts- og bokføringsopplysninger og selv om du bruker samme konto for salg og rabatt, så blir det separate bilags­linjer i regn­skapet. Det kan være greit å være klar over at om man ikke gir rabatt, men pris­avslag – altså velger en annen pris enn den som VBus foreslår – så vil VBus bokføre pris­avslaget som rabatt. Når VBus henter Pris fra Pris/rabatt­matrisen settes samtidig Standardpris til det samme som Pris. Dersom du ikke ønsker at denne implisitte rabatten skal bok­føres på samme måte som eksplisitt gitt rabatt, må du i Beh.måte 3 krysse av for Ikke beregn rabatt ut fra standard­pris. Dette må altså gjøres på alle produkter om det skal gjøres helt konsekvent.

Negativ rabatt kalles tillegg i VBus. I Ordrebehandling kan du krysse av for å Bokføre tillegg på egne konti. Da må du i Avgifts- og bokføringsopplysninger legge inn kontonr på Avg.pl. tillegg og Avg.fritt tillegg samt eventuelt EU tillegg og/eller Eksport tillegg. De to siste gelder avgiftsfritt i kombinasjon med Område; henholdsvis 2 [Innenfor annet EU-land] og 3 [Utenfor EU/utenlands]. I Norge er det ikke nødvendig å spesifisere Område, slik det er for virksom­heter innen­for EU.

Pris- og rabatt-styrende kolonner

Produktnr er åpenbart en kolonne som er med på å bestemme prisen og/eller rabatten. Det samme er Kunde­pris­gruppene og Produkt­pris­gruppene (den siste brukes først og fremst til å bestemme rabatter i kombinasjon med andre kolonner). Og som vist i eksempelet over; Fra dato og Til dato. Faktisk kan alle kolonnene som er listet opp i dialogboksen Pris/rabatt-behandling i forrige avsnitt, brukes til å bestemme pris og rabatt. Det som legges i Pris/rabatt-matrisen virker begrensende; har du lagt inn en rad med f.eks. Lagernr=3, så gjelder denne linjen kun for ordrelinjer med Lagernr=3. Det som finnes på ordre­linjen, virker kvalifiserende. Ordre­linjer må ha alle de samme verdiene i samtlige av de pris­styrende kolonnene som er brukt i Pris/rabatt-matrisen for å kvalifisere seg til en pris/rabatt-linje. Hvis det på en rad i Pris/rabatt-matrisen både er angitt Lagernr og Leveringsmåte, er denne raden kun aktuell for ordre­linjer med samme Lagernr og Leveringsmåte.

Dato er marginalt annerledes; her skal datoen ligge innenfor Fra dato og Til dato, eventuelt frem til og med Til dato om Fra dato er blank – eller fra og med Fra dato om Til dato er blank. Det er samme logikk med Postnr. Merk at VBus bruker verdiene i ordre­hodet, om den tilsvarende verdien på ordre­linje er blank.

I tillegg til de kolonnene som er listet opp i Pris/rabatt-kriterier, er følgende felt også pris/rabatt-styrende: Ordrenr, Ordre­pris­gruppe og Lønnsatsnr.

Konkurrerende priser og rabatter

Siden det er så mange måter å angi spesialpriser og -rabatter, kan én og samme ordre­linje kvalifisere til flere spesial­priser. En kunde kan f.eks. ha forhandlet seg frem til spesielle priser på enkelte produkter. VBus må ta stilling til hvilken pris og hvilken rabatt som skal foreslås. For å gjenta: Det er som når du går i billettluka i Operaen og skal ha to billetter til Cosi fan tutte og spør om pris. Du legger alle medlem­s­kortene på bordet; Ekona, Polyteknisk forening, OBOS og kanskje et par andre. Vedkommende i luka sjekker hva som gir best uttelling og gir deg laveste pris og høyeste rabatt som du kvalifiserer til. Nøkternt sett er jeg usikker på om det er billett­luke i Operaen lenger, jeg tror den forsvant da de bygget om og plasserte suvenir-butikken der billett­luka var. Nok om det.

Når det legges opp spesialpriser på enkelte kunder eller kunde­pris­grupper, så kan det tenkes at de samme kundene også kvalifiserer for rabatt – men at det på spesial­prisen ikke skal gi rabatt i tillegg. Eller at prisen er avtalt for en bestemt periode og at kunden skal ha denne prisen, også i perioder hvor det kjøres pris­kampanjer med lavere pris til andre kunder. Løsningen på dette er å angi Faste priser/rab.:

Det VBus gjør er først å hente frem alle priser og rabatter som ordre­linjen kvalifiserer til. Hvis ordre­linjen er i fremmed valuta og ett (eller flere) av pris/rabatt-radene som ordre­linjen kvalifiserer til, er i samme valuta, så ignoreres alle de andre radene – uansett om noen av disse er merket med Ikke velg gunstigere; Utsalgs­pris og/eller Ikke rabatt % på Utsalgs­pris.

Dersom det blant de radene vi nå sitter igjen med, finnes en (eller flere) rader som er merket med Ikke velg gunstigere; Utsalgs­pris, så velges høyeste pris blant disse. Hvis ingen av alternativene er merket med Ikke velg gunstigere; Utsalgs­pris, så velges laveste pris. Det er samme logikk for utleie­pris og innkjøps­pris. Og for rabatt, enten det gjelder salg, utleie eller innkjøp.

Det er nok her mange av VBus-brukerne har gått seg vill i alternativene.

Kostpriser

For ordreliner som er unntatt lagerhåndtering hentes Kostpris fra Pris/rabatt-matrisen om det i Beh.måte 2 ikke er krysset av for Ikke hent kost­pris ved salg (eller … ved produksjon). For lager­håndterte ordre­linjer kommer Kostpris i utgangs­punktet fra Gj.snittlig kostpris (som før versjon 13.10 ble omtalt som FIFO-pris) på Lagersaldo, men det er to unntak. Hvis det i Pris/rabatt-behandling er valgt Kost­pris fra pris- og rabatt­matrisen hvis utsolgt; altså hvis det ikke er noe Reserverbart mot lager på Lagersaldo. Eller om det i Beh.måte 1 er krysset av for Hent kost­pris fra pris- og rabatt­matrisen. Vi anbefaler at det i Ordre­behandling er kysset av for Beregn gjennomsn. Kost­pris på ordre­linje. Alternativet finnes også i Beh.måte 3, men om det er satt i Ordre­behandling er det ikke nødvendig å sette det på alle produktene. Det som skjer når det er valgt Beregn gjennomsn. Kost­pris på ordre­linje, er at når det foretas en reservasjon på ordre­linjen, så beregner VBus den gjennom­snittlige kost­pris fra reservasjonsradene (som kommer fra varepartiene). For de som bruker produksjonsordre, er dette alternativet nødvendig for å få rett Kostpris på det som produseres. For salgs­ordre er det strengt tatt ikke nødvendig, for Produkttransaksjon og bok­føringen får allikevel korrekt kost­pris; du risikerer bare at Påløpte kostnader hittil (og totalt) blir feil både på ordre­linje og ordre – selv om det altså er korrekt i statistikk og regn­skap. Verre er det om det i Beh.måte 3 er krysset av for Beregn kostnad ut fra ordre­linjens kost­pris, for da blir bok­føringen av solgte varers kost lykkelig fri­koblet fra kost­prisen fra innkjøpet eller produksjonen – og du ender opp med en nokså tilfeldig lager­verdi i balansen.

Kostpriser brukes av VBus til å beregne kostnad ved salg, korreksjon og vare­forbruk (i produksjon). For så vidt også for lager­overførsel.

Utleie

På utleieordre henter VBus Utleiepris fra Pris/rabatt-matrisen, samt Utleierabatt % og/eller Utleierabattbeløp om dette er valgt i Rabattforslag. Det finnes ikke flere utleie­rabatter slik som på salg. VBus henter kost­priser og beregner Påløpte kostnader på ordre­linje på samme måte som ved salg, men på Produkttransaksjon er det ingen Påløpte kostnader. Det kan i Avgifts- og bokføringsopplysninger settes opp bok­føring av verdien som tas ut fra lager som tilbake­føres ved når varene tilbake­leveres. Jeg har skrevet om utleie tidligere, så jeg skriver ikke noe mer om dette her.

Men jeg får ta med noe om Erst.pris, som finnes på både i Pris/rabatt-matrisen og på ordre­linjen. Dette gjelder utlån og utleie. Når et utlån eller utleie avsluttes, brukes Tilbake NÅ eller Kasser NÅ alt avhengig av om produktet skal tilbake på lager eller ikke. Det finnes et tredje alternativ; Erstatt NÅ. Kolonnen Erst.pliktig oppdateres i stedet for Tilbakelevert og Kassert, reservasjonen trekkes tilbake, men det blir ikke dannet noe bokførings­bilag. Beholdningen (ut over Reservert og Reserverbart mot lager) påvirkes ikke. Erst.pris følger med fra Pris/rabatt-matrise til ordre­linje og videre til produkt­transaksjon. Men det skjer ikke noe mer lenger. I en sak fra begynnelsen av dette århundre, fant en hos Visma følgende: I fremtidige versjoner kan man tenke seg at programmet kan skyte inn ekstra linjer på fakturaene, hvor kunden blir fakturert for et erstatnings­beløp. Erstatnings­beløpet vil frem­komme som erstatnings­pliktig antall multiplisert med erstatnings­prisen. Det er vel lenge siden noen der, har tenkt noe i denne retning.

Innkjøp

På innkjøpsordre henter VBus Innkjøpspris, samt Innkjøpsrabatt % og/eller Innkjøpsrabattbel. om det er krysset av for dette i Rabattforslag. Det finnes ikke flere innkjøps­rabatter slik som på salg. Kostpris blir ikke hentet fra pris/rabatt-matrisen, men beregnet som Pris etter rabatt + påslag for Frakt 1 – 4, Toll og Kostprispåslag. Og omregnet til Kostpris (kr) fra Kostpris (i valuta). På lager­håndterte innkjøp brukes Kostpris (kr) til vare­partiets Kostpris (kr), om nødvendig omregnet til grunn­enhet.

Innkjøps- og utsalgspriser på samme rad

Det går fint å ha Innkjøpspris og Utsalgspris på samme rad også om de er i ulike valutaer, men om det er angitt Lev.nr for Innkjøpspris, så må Utsalgspris legges på egen rad.

Dersom det skal være mulig å kjøpe og selge i forskjellige enheter, f.eks. Stk og Pakke á 12, må Enhet legges på alle rader i Pris/rabatt-matrisen som gjelder de produkter som kan kjøpes og/eller selges i forskjellige enheter. I det hele tatt; om det legges begrensninger på en pris-linje, m.h.t. hvilke ordrelinjer den gjelder for – så gjelder begrensningen både på kjøp og salg. Innkjøpsvaluta og valuta (som gjelder salg; hjelpeteksten er ikke helt spot-on her) er unntaket som bekrefter regelen.

Sammenlikningsdato

I Sammenlikningsdato kan det velges hvordan VBus skal manøvrere mellom Fra dato og Til dato på radene i Pris/rabatt-matrisen. Normalt er det dagens dato som brukes, men i Sammenlikningsdato kan det angis at det er Transdato eller Ønsket/Bekreftet leveringsdato som skal benyttes. Dette er praktisk om nye priser legges inn i god tid før de skal gjelde og ordre­linjene registreres for levering fremover i tid. Jeg har sett et veldig rart tilfelle av feil ved bruk av Ønsket/Bekreftet leveringsdato, hvor det oppstår en SQL-feil i enkelte tilfeller, når det på en innkjøpsordrelinje legges inn ny Bekreftet lev.dato – uten at jeg klarer å se hva som skiller de som feiler, fra de som ikke feiler. Utviklingsavdelingen til Visma har for så vidt heller ikke funnet ut av det, men de er (etter sigende) på saken.

Antallsavhengige priser

VBus gjør oppslag i Pris/rabatt-matrisen ved endring i Antall, i utgangs­punktet ikke bare ved første registrering av Antall, men senere også om du i Behandlingsmåte ikke har krysset av for Ikke foreslå pris/rabatt på nytt. Årsaken til at Antall trigger oppslag i Pris/rabatt-matrisen er at pris kan være avhengig nettopp av Antall. Det er flere varianter her:

I Pris/rabatt-matrisen finner vi Antall 1, Antall 2, …, Antall 6 og Utsalgspris 2, Utsalgspris 3, …, Utsalgspris 7. Om du velger slik:

Skal det forslås slik: For Antall under første trinn (Antall 1) gjelder Utsalgspris. For Antall under andre trinn (Antall 2) gjelder Utsalgspris 2. Fra og med siste (og sjette) trinn (Antall 6) gjelder Utsalgspris 7. Personlig skulle jeg ønske meg en mer pedagogisk nummerering av trinnene, men det får så være. Som det fremgår, er dette mekanisme som bare gjelder salg.

Hvis det er krysset av i Splitt ordrelinje, så vil ordre­linjen splittes i inntil syv rader: Første rad får pris fra Utsalgspris og Antall lik Antall 1; andre rad får pris fra Utsalgspris 2 og Antall lik differansen mellom Antall 1 og Antall 2. Etc. inntil ordre­linjens opprinnelige Antall er fordelt på de (inntil) syv trinnene.

Den andre varianten er bruk av Minsteantall. Det kan brukes både på kjøp og salg – og det kan legges opp så mange trinn du vil.

Den tredje varianten har to former; Minstebeløp og Maks.beløp. Hvis Antall er så lavt at Antall x Pris blir mindre enn Minstebeløp, settes prisen tilstrekkelig høyt til at Antall x Pris= Minstebeløp. Det er altså Beløp før rabatt som skal minst være Minstebeløp. Tilsvarende gjelder for Maks.beløp.

Priser avhengig av mål eller vekt

På produkt kan det angis mål og vekt. Regnestykket er slik:

     Lengde x Bredde = Areal x Høyde = Volum x Densitet = Nettovekt + Tara = Bruttovekt

Densitet er det som ble omtalt som egenvekt da jeg gikk på skolen, men det er lenge siden. Densitet er vekt pr. volum­enhet. Et bedre norsk uttrykk er tetthet eller masse­tetthet. Vann har densitet på 1 (ved 20°C, ved ekvator og 1000 millibar om jeg husker skole­fysikken rett – hva er oddsen for dét?).

På ordrelinje har vi følgende felt: Lengde pr. enhet, Lengde, Bredde pr. enhet, Areal pr. enhet, Areal, Høyde pr. enhet, Volum pr. enhet, Volum, Densitet pr. enhet, Nettovekt pr. enhet, Nettovekt, Tara pr. enhet, Tara, Bruttovekt pr. enhet og Bruttovekt. Fra ordre­linje blir Lengde, Areal, Volum, Nettovekt, Tara og Bruttovekt summert opp i ordre­hodet.

På produktet finnes Prisenhet med disse alternativene:

Vi kan altså prise kjøp og salg i annen enhet enn handels­enheten. Parkett er typisk; selges i forbruker­markedet i pakker á seks bord, men prises i m². Eller tau; selges og prises i meter i forbruker­markedet, mens det i proff­markedet prises i kg. Slik også innenfor en del bygnings­materialer i stål og aluminium: Bjelker i ferdige lengder i ulike profiler og kvaliteter; prises i kg.

Bruttopriser

Prisene kan oppgis som pris inkl. mva og det må angis hvilke priser på linjen som er bruttopris:

Det er ikke noe krav at ordren er en brutto-ordre; VBus regner om brutto­prisen om til pris før mva på ordre­linjen.

Hva kolonnen Bruttopris avg.kode gjør, vet jeg ikke.

Spesielt om strukturer

Kolonnen Strukturproduktnr viser til ordrelinjer som er struk­turhode. Disse prisene brukes bare når produkt på ordre­linjen er et struktur­hode.

Kolonnen Inngår i struktur har disse alternativene:

og kan brukes til å avgrense om raden i Pris/rabatt-matrisen bare skal gjelde i det ene eller det andre tilfelle.

Pris beregnet som prosent-påslag på annen verdi

Med Uts.pris påslag % i kombinasjon med Uts.pris gr.lag, som har følgende alternativer:

 

kan man få VBus til å beregne utsalgsprisen. Felles for alle alternativene bortsett fra 4, er at Uts.pris påslag % og Uts.pris gr.lag må stå på samme rad som grunn­laget prisen skal beregnes fra. Det gjelder også rabatten i alternativ 2. Felles for alternativene 1 – 5 er at VBus ikke gjør eget oppslag for å finne rabatten; VBus foreslår bare rabatt ved bruk av alternativene 2 og 6.

Andre innstillinger i bedriftsopplysningene

Mange av innstillingene i Pris/rabatt-behandling er selv­forklarende, så jeg går ikke igjennom alle. Noen kan være greit å være oppmerksom på: Dersom du angir Kundenr i Pris/rabatt-matrisen, så er det Faktureres kundenr på salgs­ordre­linjen det er snakk om. Hvis du ønsker at dette skal viser til Kundernr på salgs­ordre­linjen kan du angi Henting av pris; Pris/rabatt på kjøper.

På utleieordre beregnes Beløp før rabatt normalt som Antall x Pris x Leietid. Men om det velges Henting av pris; Prisfaktor ved utleie så blir regne­stykket i stedet Antall x Pris x Prisfaktor.

På produktet kan det angis et Prisantall. I proff-markedet til elektronikk­bransjen hender det at det handles i esker á 100 stk, men eske er minste enhet som selges og kjøpes. Prisen er allikevel oppgitt i stk. På ordre­dokumenter bør det nok tas med Prisantall for å få regne­stykket til å henge sammen, men i bransjen mener de fleste at det er helt unødvendig for «alle» vet at noen av produktene prises i 100 stk, andre i 250 stk, etc. I Pris/rabatt-behandling angis det hva slags priser som pris­antall gjelder for.

Når det gjelder omkostninger, så viser jeg til det jeg tidligere har skrevet om inngående frakt.

Prisrefusjon og Transportavtaler har jeg ikke jobbet med, så jeg avstår fra å skrive noe om det.

Alternativet Optimalisering ble introdusert i versjon 8.02.4. Jeg ser av gamle notater at jeg ved en anledning, har gitt uttrykk for at jeg har forstått det. Men det har gått over (nå har jeg hatt Corona i mellom­tiden, kanskje det er årsaken til at dette ikke er like krystall­klart som før), så jeg gjengir heller svaret jeg fikk fra Visma:

Det er slik at om du har krysset av i Pris/rabatt-kriterier slik at Produkt­pris­gruppe 1 og Kunde­pris­gruppe 1 er kriterier for salg.

Og du har en rad i Pris/rabatt-matrisen (med f.eks. rabatt) uten Produktnr og heller ikke Produkt­pris­gruppe 1 eller Kunde­pris­gruppe 1, så vil VBus uten optimalisering ignorere denne raden.

Med optimalisering vil VBus bruke denne raden (gitt at det er den beste for kjøper) hvis ordre­linjen har en verdi i enten Produkt­pris­gruppe 1 eller Kunde­pris­gruppe 1.

Hvis Produkt­pris­gruppe 1 har verdien 1 og Kunde­pris­gruppe 1 har verdien 0 så gjør VBus følgende oppslag i Pris/rabatt­matrisen uten optimalisering:

SELECT * FROM PrDcMat WHERE ProdNo = '263' ORDER BY ProdNo ASC /*600*/

SELECT * FROM PrDcMat WHERE ProdNo = ' ' AND (ProdPrGr = 1) /*600*/

Med optimalisering blir det slik:

SELECT * FROM PrDcMat WHERE ProdNo = '263' ORDER BY ProdNo ASC /*600*/

SELECT * FROM PrDcMat WHERE ProdNo = ' ' AND (ProdPrGr = 1 OR CustPrGr = 0) /*600*/

Dermed finner VBus raden uten Produktnr eller de andre kriteriene, altså fordi null er en verdi det også skal søkes etter – når optimalisering er valgt.

 

Dersom ordrelinjen hverken har verdi i Produkt­pris­gruppe 1 eller Kunde­pris­gruppe 1, så vil VBus ikke søke etter noen rader uten Produktnr, noe som strengt tatt ikke er helt logisk.

Hvis ingen av kriteriene er valgt i Pris/rabatt-kriterier, så gjør VBus heller ikke noe søk etter rader uten Produktnr.

Dermed håper jeg at dette er klart som blekk – i alle fall for de som er litt smartere enn meg.

Etter å ha grublet på det et par timer, letter tåka. Dette er først og fremst nyttig om du har et oppsett med mange rader med andre verdier i Kunde­pris­gruppe 1 (i eksempelet fra Visma). Kort sagt er det mer effektivt om SQL-server plukker ut de relevante radene enn at VBus skal sile dem ut etterpå. Men du skal ha svært mange rader før det gjør noe fra eller til i ytelse; resultatet blir til syvende og sist det samme.

Jeg har jobbet mye med en kunde som har en velvoksen Pris/rabatt-matrise. De selger produkter som fremstår som svært homogene i markedet; for kundene er det ingen forskjell på det produktet som alle i markedet tilbyr. Det er lett å tenke at dette blir planke­kjøring i VBus, men kostnads­bildet er komplisert sammensatt. I VBus er dette løst som en struktur; kunden ser bare struktur­hodet (det er dette som dukker opp på faktura), mens kostnadene er fordelt på struktur­linjer med ulike produkter. Ett produkt går igjen i alle strukturene og på dette produktet finnes det om lag tre hundre tusen rader i Pris/rabatt-matrisen. Hver gang en struktur ekspanderes henter VBus alle 300.000 pris-radene og starter prosedyren for å finne rett (den gunstigste) pris innenfor det ramme­verket som er angitt. VBus bruker 3 til 4 sekunder på dette hver gang. Og det er ikke select’en på SQL-server som tar tid; det er det at VBus skal finne rett pris etterpå. I løpet av en måned dukker denne struktur­linjen opp om lag 350 tusen ganger. Denne ene pytta lille operasjonen tar altså 14 dager å gjennomføre. Det er halve måneden. Så er det noe mer som skal gjøres; det er 1,5 millioner andre ordrelinjer som i løpet av måneden også skal tildeles pris; ordrene skal ferdigmeldes, faktureres og bokføres. Her er det ikke nok med én server for å få jobbene gjort. Men følelsen av å ha nådd kapasitets­grensen. ble påtagelig for et par år siden. Så vi slo av standard pris­oppslag i VBus og erstattet det med en mer mål­rettet select, enn det å hente rubbel og bit fra Pris/rabatt-matrisen for produktet. Det ble en monster-select; den får plass på et A4-ark om du har godt syn. Det var effektivt. Moralen er at du skal aldri gjøre noe som SQL-server kan gjøre for deg.

Skulle jeg ønske meg noe i Pris/rabatt-matrisen på vegne av kunder, så måtte det være optimalisering av oppslaget når Produktnr er gitt.

Andre kolonner i Pris/rabatt-matrisen

Hvis Overstyrt beskrivelse er angitt i Pris/rabatt-matrisen og denne pris-raden blir valgt, vil ordre­linjens Beskrivelse endres tilsvarende. Dette er samme funksjonalitet som vi finner på Struktur-tabellen.

Veil.pris og Pristype legges til på ordrelinje fra samme rad som VBus finner Pris. Dersom du sliter med å finne ut hvilken rad i Pris/rabatt-matrisen som VBus faktisk velger, kan du sette Pristype like Linjenr i Pris/rabatt-matrisen. På den måten vil Pristype på ordre­linje vise til den valgte raden fra Pris/rabatt-matrisen.

Opplysning, Priskat.nr og Priskat.dato er rene opplysningsfelt uten annen funksjon enn å opplyse bruker. Det samme gjelder for så vidt også Inng.dok.nr. som viser til Inngående dokument.

Lønnsart og Strekkode finnes også i Pris/rabatt-matrisen, men det er uklart hvorfor. Så om noen kan gi en fornuftig forklaring på hva disse to kolonnene og for så vidt også Bruttopris avg.kode, gjør i Pris/rabatt-matrisen, er jeg lutter øre.

Prisjustering

Du kan markere alle eller utvalgte rader i Pris/rabatt-matrisen og foreta Prisjustering. Følgende dialog­boks dukker opp:

 

Dialogboksen er vel selvforklarende.

Prisliste

Fra tabellen Produkt kan du skrive ut en Prisliste, gitt at du har tabellen Pris og rabattmatrise synlig i samme vindu. Produkt-tabellen brukes for å lage et passende utvalg, mens kolonene i pris­lista kommer fra tabellen Pris og rabattmatrise. Selv om du kan velge Kundenr, får du ikke med rabattene som følger av f.eks. kunde­pris­grupper og/eller produkt­pris­grupper.

Et alternativ er å lage en prisliste-ordre, fortrinnsvis med Ordretype 6 [Ubehandlet ordre]. Her kan du legge inn alle produktene som du vil ha med på pris­lista og sette Antall til 1 på alle ordre­linjene. Så legger du inn rett kundenr i ordre­hodet og bruker meny­valget Rekalkuler priser. Hvis du har svært mange ordre­linjer i pris­liste-ordren, kan det tenkes at det går raskere om du benytter Behandlingsmåten Unnta fra totaler; inntekter og kostnader ved salg. Nå kan du skrive ut et ordre­dokument som du kan kalle prisliste.

Et annet alternativ er å sende produktkatalog til kunde via AutoInvoice.

 

 

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