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 allmennkunnskap 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 veibanen og reagere hensiktsmessig 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 datamaskiner har gjennomgå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 dagligdagse gjøremål. Jeg overhørte her om dagen en hissig diskusjon mellom en kunde og en leverandør av en applikasjon (ikke VBus) hvor oppgradering førte til at all tidligere maskinlæring gikk tapt. Vi har sannelig vendt oss til tanken om at maskinelt ervervet kunnskap, 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 rabattmatrise (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 ordrelinje. Av grunner jeg ikke skal kjede dere med har jeg den siste tiden måtte foreta et dypdykk i denne delen av VBus og blir fremdeles (etter 20 år) overrasket over hva VBus gjør. Men jeg drister meg til å gi en fremstilling:
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 salgsordrelinje vil VBus hente Utsalgspris fra Pris/rabatt-matrisen og bruke denne som Pris. Jeg kommer tilbake til fremmed valuta senere. Dersom en salgsordrelinje skal Unntas lagerhåndtering, hentes også Kostpris fra Pris/rabatt-matrisen. For salgsordrelinjer som lagerhåndteres, hentes kostprisen 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 prisstyrende felt i Pris/rabatt-matrisen, virker avgrensende på når linjene blir relevante. Det er litt som når du kommer til billettluka, 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 billettluka 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 andelseiere 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 sesongstart. Produktnr 5900 er «Startpakke - 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 valutakurs 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å ordrelinjen 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 Bedriftsopplysninger). Dersom det er angitt slik:
vil VBus lete etter Utsalgsrabatt % 1, Utsalgsrabattbel. 1 og Utsalgsrabatt % 2 (til salgsordre). 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/rabattmatrisen. På ordrelinen kan du altså ha seks rabatt % og samtidig seks rabattbeløp på samme ordrelinje. Og de fem første av hver type kan hentes fra pris/rabatt-matrisen, mens Rab. % 6 og Rabattbeløp 6 kan brukes på ordrelinjen uten fare for at VBus foreslår noe. Hjelpeteksten til disse felt er feil. Hvis vi har en ordrelinje 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 regnestykket fremdeles 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 – rabattbeløp vil VBus ikke lete etter rabattbeløpene hver for seg, men lete etter laveste pris etter rabattbeløpene (altså at utsalgsrabattbelø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 rabattbelø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 utsalgsrabattbelø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å ordrelinje 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 rabattforslag enn Utsalgsrabatt % 1.
Ofte vil rabatt være knyttet til kunder, prosjekter eller liknende uavhengig av produkt. For mange vil det være hensiktsmessig å knytte produktene til en produktprisgruppe og kundene til en kundeprisgruppe, 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 kundeprisgrupper som fungerer uavhengig av hverandre – og tre produktprisgrupper 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 Andelseiere 15 % rabatt på alt de kjøper uavhengig av Produktprisgr. 1. Hvis vi nå tenker at enkelte andelseiere 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 kostpriser. 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å ordredokumentene. Et enkelt alternativ er å vise Pris etter rabatt i stedet for Pris og de ulike rabattkolonnene. 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. AutoInvoice forholder seg bare til samlet rabatt omregnet til beløp på hver ordrelinje.
Dersom du ikke bruker Totalrabatt % (eller Totalrabattbeløp – merk at hjelpeteksten omtaler feil kolonne) i ordrehodet eller grupperabatter, vil Fordelte rabatter vise den samlede linjerabatten. Da kan du på ordredokumentene 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 utleieinntekter, 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 bilagslinjer i regnskapet. Det kan være greit å være klar over at om man ikke gir rabatt, men prisavslag – altså velger en annen pris enn den som VBus foreslår – så vil VBus bokføre prisavslaget som rabatt. Når VBus henter Pris fra Pris/rabattmatrisen settes samtidig Standardpris til det samme som Pris. Dersom du ikke ønsker at denne implisitte rabatten skal bokføres på samme måte som eksplisitt gitt rabatt, må du i Beh.måte 3 krysse av for Ikke beregn rabatt ut fra standardpris. 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 virksomheter innenfor EU.
Pris- og rabatt-styrende kolonner
Produktnr er åpenbart en kolonne som er med på å bestemme prisen og/eller rabatten. Det samme er Kundeprisgruppene og Produktprisgruppene (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å ordrelinjen, virker kvalifiserende. Ordrelinjer må ha alle de samme verdiene i samtlige av de prisstyrende 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 ordrelinjer 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 ordrehodet, om den tilsvarende verdien på ordrelinje er blank.
I tillegg til de kolonnene som er listet opp i Pris/rabatt-kriterier, er følgende felt også pris/rabatt-styrende: Ordrenr, Ordreprisgruppe og Lønnsatsnr.
Konkurrerende priser og rabatter
Siden det er så mange måter å angi spesialpriser og -rabatter, kan én og samme ordrelinje kvalifisere til flere spesialpriser. 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 medlemskortene 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 billettluke i Operaen lenger, jeg tror den forsvant da de bygget om og plasserte suvenir-butikken der billettluka var. Nok om det.
Når det legges opp spesialpriser på enkelte kunder eller kundeprisgrupper, så kan det tenkes at de samme kundene også kvalifiserer for rabatt – men at det på spesialprisen 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 priskampanjer 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 ordrelinjen kvalifiserer til. Hvis ordrelinjen er i fremmed valuta og ett (eller flere) av pris/rabatt-radene som ordrelinjen kvalifiserer til, er i samme valuta, så ignoreres alle de andre radene – uansett om noen av disse er merket med Ikke velg gunstigere; Utsalgspris og/eller Ikke rabatt % på Utsalgspris.
Dersom det blant de radene vi nå sitter igjen med, finnes en (eller flere) rader som er merket med Ikke velg gunstigere; Utsalgspris, så velges høyeste pris blant disse. Hvis ingen av alternativene er merket med Ikke velg gunstigere; Utsalgspris, så velges laveste pris. Det er samme logikk for utleiepris og innkjøpspris. 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 kostpris ved salg (eller … ved produksjon). For lagerhåndterte ordrelinjer kommer Kostpris i utgangspunktet 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 Kostpris fra pris- og rabattmatrisen 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 kostpris fra pris- og rabattmatrisen. Vi anbefaler at det i Ordrebehandling er kysset av for Beregn gjennomsn. Kostpris på ordrelinje. Alternativet finnes også i Beh.måte 3, men om det er satt i Ordrebehandling er det ikke nødvendig å sette det på alle produktene. Det som skjer når det er valgt Beregn gjennomsn. Kostpris på ordrelinje, er at når det foretas en reservasjon på ordrelinjen, så beregner VBus den gjennomsnittlige kostpris 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 salgsordre er det strengt tatt ikke nødvendig, for Produkttransaksjon og bokføringen får allikevel korrekt kostpris; du risikerer bare at Påløpte kostnader hittil (og totalt) blir feil både på ordrelinje og ordre – selv om det altså er korrekt i statistikk og regnskap. Verre er det om det i Beh.måte 3 er krysset av for Beregn kostnad ut fra ordrelinjens kostpris, for da blir bokføringen av solgte varers kost lykkelig frikoblet fra kostprisen fra innkjøpet eller produksjonen – og du ender opp med en nokså tilfeldig lagerverdi i balansen.
Kostpriser brukes av VBus til å beregne kostnad ved salg, korreksjon og vareforbruk (i produksjon). For så vidt også for lageroverfø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 utleierabatter slik som på salg. VBus henter kostpriser og beregner Påløpte kostnader på ordrelinje 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 bokføring av verdien som tas ut fra lager som tilbakeføres ved når varene tilbakeleveres. 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å ordrelinjen. 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øringsbilag. Beholdningen (ut over Reservert og Reserverbart mot lager) påvirkes ikke. Erst.pris følger med fra Pris/rabatt-matrise til ordrelinje og videre til produkttransaksjon. 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 erstatningsbeløp. Erstatningsbeløpet vil fremkomme som erstatningspliktig antall multiplisert med erstatningsprisen. 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øpsrabatter 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å lagerhåndterte innkjøp brukes Kostpris (kr) til varepartiets Kostpris (kr), om nødvendig omregnet til grunnenhet.
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 ordrelinjene 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 utgangspunktet 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 ordrelinjen 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 ordrelinjens 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. volumenhet. Et bedre norsk uttrykk er tetthet eller massetetthet. Vann har densitet på 1 (ved 20°C, ved ekvator og 1000 millibar om jeg husker skolefysikken 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 ordrelinje blir Lengde, Areal, Volum, Nettovekt, Tara og Bruttovekt summert opp i ordrehodet.
På produktet finnes Prisenhet med disse alternativene:
Vi kan altså prise kjøp og salg i annen enhet enn handelsenheten. Parkett er typisk; selges i forbrukermarkedet i pakker á seks bord, men prises i m². Eller tau; selges og prises i meter i forbrukermarkedet, mens det i proffmarkedet prises i kg. Slik også innenfor en del bygningsmaterialer 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 bruttoprisen om til pris før mva på ordrelinjen.
Hva kolonnen Bruttopris avg.kode gjør, vet jeg ikke.
Spesielt om strukturer
Kolonnen Strukturproduktnr viser til ordrelinjer som er strukturhode. Disse prisene brukes bare når produkt på ordrelinjen er et strukturhode.
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 grunnlaget 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 selvforklarende, 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å salgsordrelinjen det er snakk om. Hvis du ønsker at dette skal viser til Kundernr på salgsordrelinjen 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 regnestykket i stedet Antall x Pris x Prisfaktor.
På produktet kan det angis et Prisantall. I proff-markedet til elektronikkbransjen 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å ordredokumenter bør det nok tas med Prisantall for å få regnestykket 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 prisantall 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 mellomtiden, kanskje det er årsaken til at dette ikke er like krystallklart 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 Produktprisgruppe 1 og Kundeprisgruppe 1 er kriterier for salg.
Og du har en rad i Pris/rabatt-matrisen (med f.eks. rabatt) uten Produktnr og heller ikke Produktprisgruppe 1 eller Kundeprisgruppe 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 ordrelinjen har en verdi i enten Produktprisgruppe 1 eller Kundeprisgruppe 1.
Hvis Produktprisgruppe 1 har verdien 1 og Kundeprisgruppe 1 har verdien 0 så gjør VBus følgende oppslag i Pris/rabattmatrisen 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 Produktprisgruppe 1 eller Kundeprisgruppe 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 Kundeprisgruppe 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 plankekjøring i VBus, men kostnadsbildet er komplisert sammensatt. I VBus er dette løst som en struktur; kunden ser bare strukturhodet (det er dette som dukker opp på faktura), mens kostnadene er fordelt på strukturlinjer 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 rammeverket 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 strukturlinjen 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 kapasitetsgrensen. ble påtagelig for et par år siden. Så vi slo av standard prisoppslag i VBus og erstattet det med en mer målrettet 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 ordrelinjens 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å ordrelinje 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 dialogboks 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 prislista kommer fra tabellen Pris og rabattmatrise. Selv om du kan velge Kundenr, får du ikke med rabattene som følger av f.eks. kundeprisgrupper og/eller produktprisgrupper.
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å prislista og sette Antall til 1 på alle ordrelinjene. Så legger du inn rett kundenr i ordrehodet og bruker menyvalget Rekalkuler priser. Hvis du har svært mange ordrelinjer i prisliste-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 ordredokument 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