Oslo, 1. juni 2025

Endret 1. februar 2026

Allokeringer i VBus

For 14 dager siden skrev jeg om bestillingsforslag. Det passer best for varer som normalt skal være på lager, som vi helst ikke bør gå tom for – slik at vi kan levere når kundene etterspør og gi høy service-grad. Mange har i sitt sortiment varer som ikke bestilles før det dukker opp en ordre. Noen kaller dette for skaffevarer. I VBus heter det bestillingsvare og er en egenskap i behandlingsmåte:

Et bilde som inneholder tekst, skjermbilde, display, nummer

KI-generert innhold kan være feil.

Det er ingen annen funksjonalitet i denne egenskapen enn at det på ordrelinjen er en kolonne med navnet Best.vare som visualiserer dette med en x – noe som gjør det lett å se hvilke varer som må bestilles. Bestillingsvarer skal lagerhåndteres på samme måte som varer som normalt lagerføres. Og har du tjenester som kjøpes inn for videresalg eller bruk i produksjon, vil jeg anbefale at også disse blir lagerhåndtert, men på eget «lager» (med annet Lagernr enn vanlige varer) slik at det ikke blir et spørsmål om dem ved lagertelling. Regnskapsmessig skal disse ha en verdi i balansen som andre varer og utgiftsføres når de selges, evt. inngår som varer i arbeid om det er «vareforbruk» i produksjon. Fordelen med at slike tjenester er lagerhåndtert, er at kostpris blir rett også om tjenesten videreselges eller brukes i produksjon, før inngående faktura mottas.

Best.vare kan brukes i utvalg (egentlig er det bitverdi 524288 i Beh.måte 1). I vindu for bestillingsforslag kan man med fordel sørge for at bestillingsvarer ikke vises, mens det i vindu for salgsordre med fordel kan kolonnen vises, f.eks. slik:

Et bilde som inneholder tekst, skjermbilde, nummer, programvare

KI-generert innhold kan være feil.

 

Her er det satt opp en egen fane for ordrelinjer med bestillingsvarer. Det gjør det enkelt å markere alle radene og bruke menyvalget

Et bilde som inneholder tekst, nummer, Font, line

KI-generert innhold kan være feil.

 

Det blir laget én eller flere innkjøpsordre, som blir allokert til salget. Koblingen er Allok. ordrenr og Allokert ordrelinjenr. på salgsordrelinjene og Ordregr.lagsnr på innkjøpsordren. Allokert viser til det antall som er allokert mot innkjøpsordren. Dette er samtidig Reservert mot tilgang:

Legg merke til at Kostpris og Kostpris (kr) nå er endret. Opprinnelig kom dette fra Gj.snittlig kostpris på lagersaldo, mens de nå har fått kostprisen fra de allokerte innkjøpsordrelinjene. Litt eiendommelig er det at Kostvalutanr og Kostvalutakurs på salgsordrelinjene ikke er oppdatert, men det skjer straks du endrer noe på innkjøpsordren, enten det er endring av valutakurs, pris, rabatt, fraktpåslag, transporttid eller gjennomfører menyvalg som Bekreftet, Sendt, Ferdigmeld, etc. Bekreftet lev.dato blir også endret; den blir nå det samme som Ankomstdato på innkjøpsordrelinjene.

Personlig synes jeg det er praktisk å ha innkjøpsordren i samme vindu:

Et bilde som inneholder tekst, skjermbilde, Font, programvare

KI-generert innhold kan være feil.

Hvis Val.kurs på innkjøpsordren eller Pris, Rabatt % eller Frakt 1 endres på innkjøpsordrelinjen – slik at Kostpris (kr) endres, så endres også Kostpris og Kostpris (kr) på salgsordrelinjene. Og om Bekreftet lev.dato eller Transp.tid endres på innkjøpsordrelinjen – slik at Ankomstdato endres, så endres Bekreftet lev.dato på salgsordrelinjen tilsvarende. Når det gjennomføres varemottak av innkjøpsordren, blir reservasjonene på salgsordrelinjene endret fra Reservert mot tilgang til Reservert mot lager, slik at disse varene ikke kan selges til andre.

Behandlingsvalget Generer innkjøps/produksjonsordrer kan gjennomføres på ordren i stedet for på ordrelinjene. Da blir det laget innkjøpsordre for alle salgsordrelinjene, bortsett fra de som i Behandlingsmåte Unntas fra Generer innkjøps- /prod. ordrer.:

Et bilde som inneholder tekst, skjermbilde, display, nummer

KI-generert innhold kan være feil.

Merk at det blir laget innkjøpsordre også for ordrelinjer som er unntatt lagerhåndtering – hvis det ikke er satt slik restriksjon.

Det er mulig å generere ordre fra salgsordrelinjer som tilhører flere salgsordre – eller fra mange salgsordre. Et eksempel på dette:

Selskapet er i bransjen for sportsklær. I god til før neste sesong får de laget 50 modeller og inviterer alle sine 100 kunder til visning. Kundene får en frist for å bestille varer. Noen av modellene kan leveres i ulike farger. Alle kan leveres i forskjellige størrelser (XXS – 3XL). I Pris/rabatt-matrisen legges det opp innkjøps- og utsalgspris for de 50 modellene, selv om det på grunn av varianter på farge og størrelse blir 500 produktnr. Når alle kundene har sendt inn sine ordre er det nesten 50.000 salgsordrelinjer fordelt på 100 salgsordre. De 50 modellene produseres av 5 leverandører, i snitt 10 modeller pr. leverandør. Det genereres innkjøpsordre fra de 100 salgsordrene. Det resulterer i 5 innkjøpsordre med i snitt 100 innkjøpsordrelinjer på hver innkjøpsordre – totalt 500 innkjøpsordrelinjer. Varemottaket og fakturamottaket blir betydelig enklere.

Relevante innstillinger

I Bedriftsopplysninger finnes Best.gen.behandling, hvor de fleste relevante innstillingene velges:

Et bilde som inneholder tekst, elektronikk, skjermbilde, display

KI-generert innhold kan være feil.

Hvis det ikke er krysset av for Vis dialog ved generering av ordrer fra salgsordrer, vil de valgene som er gjort her, alltid bli brukt. Ved å vise dialogen, vil brukeren få mulighet til å velge i hvert enkelt tilfelle. Merk at dette også gjelder om du genererer ordre fra produksjonsordre. Da er det vareforbrukslinjene (de med Trans.type=5) som er «original linje» og som det opprettes innkjøps- eller produksjonsordre til.

Flere av valgene under overskriften Innkjøp / Produksjon har to avkrysningsbokser. Boksen til venstre gjelder der det blir laget innkjøpsordre, mens den andre gjelder der det blir produksjonsordre. Det er på Leveringsalternativ hvor det krysses av i kolonnen Produksjon, at man setter at det skal lages produksjonsordre i stedet for innkjøpsordre – og hvis det ikke er krysset av for Bruk normal leverandør fra lagersaldoer, så velger VBus det leveringsalternativ som kommer øverst (gitt at du ikke har satt opp en avvikende sortering). Strengt tatt det leveringsalternativ med lavest Sort.sekv.nr.

Kopier leveringsadr. fra original ordre betyr at innkjøpsordren (eller produksjonsordren) arver leveringsadressen fra salgsordren. Det passer ved direkteleveranser; at leverandøren ikke sender varene til vårt lager, men direkte til kunden. Dette må ikke forveksles med Ordretype 2 [Direkteordre] som er noe helt annet. Det får selvfølgelig konsekvenser for gjennomføringen av varemottaket, siden dette må baseres på informasjon om at varene er sendt, f.eks. pakkseddel.

Ett produkt pr. ordre betyr at det blir laget én ordre for hvert produkt. Det er noe jeg anbefaler for produksjon. Da åpnes det for å velge de tre Kopier-alternativene som er grået ut i bildet over.

Som det er nevnt i eksempelet med sportsklær, blir salgsordrelinjer med samme Produktnr og Lagernr slått sammen, med mindre det er valgt Kopier hver ordrelinje separat. Det kan være relevant om du har salgsordre hvor samme Produktnr finnes på flere ordrelinjer, men med ulik Ønsket lev.dato. Et eksempel fra byggevarebransjen: Kunden skal bygge hus og garasje. Det bestilles Leca til grunnmuren, men garasjen skal ikke påbegynnes før huset er ferdig. Altså forskjellig Ønsket lev.dato. Når Kopier hver ordrelinje separat er valgt, blir det mulig å velge de fire Kopier-alternativene som er grået ut i bildet over.

Kopier behandlingsmåte fra original linje er nok bare relevant om behandlingsmåten på salgsordrelinjene er endret og du ønsker samme endring også på de genererte ordrelinjene.

Kopier kostpris til pris fra original linje er bare aktuelt når det genereres innkjøpsordre, men gjør det altså mulig å legge inn innkjøpsprisen i kolonnen Kostpris på salgsordrelinjen. Her er det mulig å rote det til. Hvis innkjøpsordren blir i fremmed valuta, må du angi rett Kostvalutanr på salgsordrelinjene, for VBus kopierer ikke bare Kostpris til Pris, men også Kostvalutanr til Valutanr og Kostvalutakurs til Valutakurs. Selv om du har gjort det rett og alt ser rett ut på innkjøpsordren, så får du et problem hvis du vil endre Valutakursen på innkjøpsordren før fakturamottaket. For Valutakurs på innkjøpsordrelinjene er ikke duplisert fra innkjøpsordren, slik at Valutakurs må endres på linjene i stedet for i hodet. I tillegg er det slik at påslag for frakt og toll som er lagt inn på leveringsalternativ blir ignorert. Det er mange som har rotet det til for seg med bruk at dette alternativet.

Kopier ansvarsenheter fra original linje gjør akkurat det. Ansvarsenheter kan legges på aktør (kunde, leverandør, etc.), på produkt, ordre, etc. De som er registrert på original linje (salg- eller vareforbruk i produksjon) blir kopiert over til innkjøpsordrelinjen, mens de som ikke er i bruk på original linje får tildelt verdi som VBus ellers gjør.

Kopier selger/innkjøper fra original linje gjør også akkurat det; samme logikk som for ansvarsenheter.

Fyll opp minimum beholdning fra lagersaldotabellen vil i tillegg til ordregrunnlaget, lage en bestilling slik at når alt som er registrert av kjøp og salg er ferdigmeldt og fakturert, så vil Fysisk beholdning bli lik Min.beh.. I eksempelet med sportsklær; når alle salgsordrene er registrert, vil lagersaldo vise samlet salg pr. produkt i kolonnen I ordre (og i Avgang). Ved å legge inn et antall i Min.beh., blir bestillingen tilsvarende høyere. Da vil Antall på innkjøpsordrelinjen være høyere enn Allokert og differansen vil være Ikke allokert. Ved varemottak vil det som er allokert bli Reservert mot lager, mens resten blir Reserverbart mot lager. Antallet som blir bestilt med dette antallet er i praksis Beh. inkl. endr. + Min.beh. og kan sammenliknes med et bestillingsforslag med metoden I henhold til beholdningsendringer og Aggregeringsnivå satt til 3 [Totalt].

Bestill økonomisk innkjøpsmengde fra leveringsalternativ eller lagersaldo vil avrunde oppover slik at antallet som bestilles er delelig med Øk.innk.m.. Her er hensikten at om en vare må kjøpes inn f.eks. i esker á 12 stk., settes Øk.innk.m. til 12 og antallet på innkjøpsordrelinjen avrundes oppover til noe som er delelig med Øk.innk.m.. Er ordregrunnalget 25 stk, blir Antall på innkjøpsordren 36 stk. Dette kan settes både på lagersaldo og på leveringsalternativ og om det er satt begge steder, men med forskjellig økonomisk innkjøpsmengde, så er det leveringsalternativ som brukes.  

Avrundingsregler fra lagersaldo fungerer på samme måte som Bestill økonomisk innkjøpsmengde, men krever at Avrund.måte på lagersaldo er satt til 1 [oppover] og at Avrunding (fremdeles på lagersaldo) er satt. Forskjellen er at Øk.innkj.m. er i grunnenhet, mens Avrunding er i innkjøpsenhet. Dette betyr at om Antall pr. enhet på leveringsalternativ f.eks. er 12 kan Avrunding settes til 1. Er ordregrunnlaget 25 (i grunnenhet), blir bestillingen på 3 enheter á 12 stk. – altså 36 grunnenheter.

Hvis du bruker antallsomregning ved kjøp (altså Antall pr. enhet) er det enklest å bruke avrunding. Ellers spiller det neppe noen rolle om det brukes økonomisk innkjøpsmengde eller avrunding. I prinsippet kan begge brukes, men det er neppe hensiktsmessig. Hvis du gjør det, så husk at økonomisk innkjøpsmengde brukes først og deretter avrunding.

Andre innstillinger

I Ordrebehandling (i bedriftsopplysninger) er ett av alternativene Hent kostpris og dato etter generering av ordre. Dette kom (etter at jeg foreslo det) fordi VBus i hine hårde dager ikke oppdaterte salgsordren før noe ble endret på innkjøpsordren. VBus setter Kostpris og Kostpris (kr) på salgsordrelinjen ved registrering av Antall til det som er Gj.snittlig kostpris på lagersaldo, som kan være noe annet enn den kostprisen vi får når det genereres et nytt innkjøp. Jeg har derfor alltid anbefalt å ha på dette valget, men en eller annen gang i årenes løp er VBus endret, slik at du får rett kostpris på salgsordren enten det er krysset av for Hent kostpris og dato eller ikke. Derimot er det slik at om det er krysset av for dette, får du feil Bekreftet lev.dato på salgsordrelinjen. Den blir satt lik Bekreftet lev.dato på innkjøpsordrelinjen, ikke Ankomstdato som er rett. Men om du ikke krysser av for Hent kostpris og dato blir det rett. Jeg anbefaler derfor ikke å krysse av for dette. Men du må ha valgt Beregn gj.snittlig Kostpris på ordrelinjene.

Siden endringer i Ankomstdato på innkjøpsordrelinjen fører til samme endring på Bekreftet lev.dato på salgsordrelinjen, blir salgsordrelinjen merket i Ord.linjestatus med at den er Klar for leveransebeskjed. Jeg har skrevet om leveringsdato tidligere, så jeg skriver ikke noe mer om dette her. Men om kunden har Ønsket lev.dato på julaften og vi får melding fra leverandøren om en tidligere leveringsdato og dermed en tidligere Ankomstdato enn julaften, så blir det litt klønete at Bekreftet lev.dato på salgsordrelinjen er tidligere enn Ønsket lev.dato. Så jeg foreslo et mulighet til å få velge Ikke flytt bekreftet leveringsdato på salgsordre tidligere enn ønsket leveringsdato. Dette ble implementert, men ikke helt slik jeg forslo: I Beregning av leveringsdatoer (i bedriftsopplysninger) er det tatt inn en mulighet til å velge Ikke flytt bekreftet leveringsdato tidligere på ordre. Her er det vel noe som ble lost in translation, da dette gikk til utvikling. For når dette er valgt, så vil endinger i Ankomstdato ikke reflekteres i Bekreftet lev.dato på salgsordrelinjer, hvis Ankomstdato er tildligere enn Ønsket lev.dato (på salgsordrelinjen). Altså om Ønsket lev.dato er på julaften, Ankomstdato i første omgang er på nyttårsaften (slik at også Bekreftet lev.dato på salgsordrelinjen blir på nyttårsaften), vi velger flyfrakt med en Transp.tid på 2 dager i stedet for de vanlige 14 og får en Ankomstdato på 19. desember, så er Bekreftet lev.dato på salgsordrelinjen fremdeles nyttårsaften, selv om levering på julaften har blitt mulig. Det jeg ønsket meg er at Bekreftet lev.dato på salgsordrelinjen da ble på julaften, men slik er det altså ikke.

Om du ikke har valgt Ikke flytt bekreftet leveringsdato tidligere på ordre som en generell regel i Beregning av leveringsdatoer (i bedriftsopplysninger), kan det velges for enkelte ordre i Ordrepref.. Det kan settes på kunden i Kundepref. og da vil nye ordre få satt dette i Ordrepref..

Forutsetningen for at kostpris på salgsordrelinjene blir oppdatert med kostpris på innkjøpsordrelinene, er at dette er valgt i Oppd. kost på ordrene. Men da Ikke flytt bekreftet leveringsdato tidligere på ordre ble implementert, ble kostpris på salgsordre bare oppdatert hvis Bekreftet lev.dato ble oppdatert. Jeg foreslo at dette ble endret slik at kostpris ble oppdatert, selv om Bekreftet lev.dato ikke ble endret. Dette ble tatt inn som et valg i Oppd. kost på ordrene: Ignorer datoer. Jeg la vel til en kommentar om at Ikke flytt bekreftet leveringsdato tidligere ikke var helt slik jeg hadde foreslått. Hjelpeteksten til Ignorer datoer er ikke helt spot on. Det står: Det blir ikke tatt hensyn til datoen og ordrelinjene blir oppdatert [med rett kostpris]. Feltet Bekreftet lev.dato blir oppdatert med Ankomst/avgangsdato fra innkjøps-/produksjonsordrelinjer, som da viser når varen er tilgjengelig for levering. Første setning er rett. Andre er feil. Hjelpeteksten til Oppdater kostpris på ordrer er heller ikke spot on. Det står: Ved oppdatering av salgsordrelinjer med verdier fra innkjøps-/produksjonsordrelinjer som de er hardt eller løst bundet til, vil kostprisene samtidig oppdateres dersom du har krysset av i feltet Oppdater kostpris på ordrer, når Bekreftet lev.dato er lik eller eldre enn Ankomst/avgangsdato på innkjøpet/produksjonen. Siste del av setningen skal være: når Ønsket lev.dato er lik eller tidligere enn Ankomst/avgangsdato på innkjøpet/produksjonen.

Ikke alle mine forslag har havnet i hovedarkivet til utviklingsavdelingen, selv om det ikke nødvendigvis blir helt som jeg har forslått.

Jeg anbefaler at det krysses av både for Oppdater kostpris på ordrer og Ignorer datoer i Oppd. kost på ordrene.

I Reservasjonsbehandling (i bedriftsopplysninger) må det være krysset av for Ved varemottak; Harde bindinger for at det ved varemottak av innkjøpsordren skal bli gjennomført en reservasjon mot lager på de allokerte salgsordrelinjene. Harde bindinger i denne sammenheng er altså allokeringer.

Endring av antall på allokerte ordrelinjer

Antall + Ferdigmeldt på en innkjøpsordrelinje kan være større enn Allokert, men ikke mindre. Det betyr at om Antall skal økes på en allokert salgsordrelinje, må du først sørge for at det er tilstrekkelig Ikke allokert på innkjøpsordrelinjen. Altså om nødvendig øke Antall på innkjøpsordrelinjen før du øker Antall på salgsordrelinjen. Merk at om noe er Ferdigmeldt på innkjøpsordren, så er det ikke sikkert at du kan øke Antall på salgsordrelinjen. Ikke allokert er AntallAllokert. Og du kan ikke øke Antall på salgsordrelinjen med mer enn Ikke allokert (på innkjøpsordrelinjen). Litt rart egentlig at Ferdigmeldt ikke tas med i beregningen av Ikke allokert. Men slik er nå engang VBus. Løsningen blir å legge opp en ny salgsordrelinje med tillegget i Antall og generere en ny innkjøpsordre. Eller legge til en ny ordrelinje på den eksisterende innkjøpsorden og allokere manuelt (se nedenfor).

Omvendt om Antall skal reduseres; da må reduksjonen skje på salgsordrelinjen først og deretter eventuelt på innkjøpsordrelinjen. Det er ikke nødvendig å redusere Antall på innkjøpsordrelinjen. Hvis du ikke gjør det vil reduksjonen på salgsordrelinjen dukke opp som Ikke allokert (med mindre noe er Ferdigmeldt). Og så det helt åpenbare; hvis Antall på innkjøpsordren skal endres, må leverandøren varsles. Er varene sendt fra leverandør er vel løpet kjørt for å redusere Antall.

Hjelpeteksten til Ikke allokert kunne også være bedre. Det står: Hvor mye som ikke har blitt allokert, det vil si differansen mellom feltene Mengde og Allokert. Men det er ikke noe som heter Mengde på ordrelinjen i VBus. Det burde ha stått differansen mellom Antall og Allokert.

Oppheving av allokering

Det er mulig å oppheve allokering. Det gjøres ved å slette Allokert ordrenr på salgsordrelinjen. Da forsvinner Allokert både på salg- og innkjøpsordrelinjen. På innkjøpsordrelinjen blir Ikke allokert det samme som Antall. Dette kan gjøres på mange salgsordrelinjer samtidig. For lenge siden var det slik at dette måtte gjøres på én og én linje ad gangen (og med lagring for hver linje), men slik er det heldigvis ikke lenger.

Manuell allokering

Dersom det finnes en innkjøpsordrelinje med Ikke allokert, kan du allokere manuelt ved å legge inn Ordrenr til innkjøpsordren i feltet Allokert ordrenr på salgsordrelinjen. Og som i eksempelet med sportsklær over, kan du allokere flere salgsordrelinjer til samme innkjøpsordrelinje – så lenge det er noe som Ikke allokert på den. VBus finner selv frem til rett Linjenr på innkjøpsordren og legger det inn i Allokert ordrelinjenr på salgsordrelinjen. VBus sørger hele tiden for at sum Allokert på salgsordrelinjene er det samme som Allokert på innkjøpsordrelinjen. På samme måte som ved oppheving av allokeringer, kan du gjennomføre manuell allokering på mange salgsordreliner samtidig.

Jeg har jobbet med noen virksomheter som bruker allokering i stort omfang og når det kom inn en salgsordre fra en viktig kunde, så hendte det at en ivrig selger la merke til at det var en bestilling med Ankomstdato innen Ønsket lev.dato til den viktige kunden, men at denne bestillingen var allokert til annen salgsordre. Og for å tilfredsstille den viktige kunden, opphevet han allokeringen på den andre salgsordren og gjennomførte en manuell allokering til den viktige kunden. Det ble ikke noen god stemning blant selgerne i den virksomheten og de fikk etter hvert noen ganske sure kunder som ikke fikk varene på den dato som fremgikk av ordrebekreftelsen. Selv om noe er mulig i VBus, er det ikke sikkert det er smart. Slik reallokering blir fort tidkrevende hvis det skjer i stort omfang. Å sette opp logging av endringer av kolonnen Allokert ordrenr, gjerne med krav til kommentar, kan være et tiltak for å unngå lite hensiktsmessig reallokering.

   

Resten av min blogg kan du lese her: frode.antun.no/VBus/blogg 

 

frode@antun.no