Estimeret læsetid: 13 minutter

Hvorfor skal der laves lagerregulering? Hvorfor går det så langsomt? Hvorfor kan man ikke bare rette kostprisen, når den har ændret sig? Det spørger jeg mig selv om, siden Microsoft indførte lagerreguleringen i Navision Dynamics Attain eller Microsoft Business Central BC365 og kun har gjort det værre siden. Hos Navision Financials op til omkring version 4 fandtes den i øvrigt ikke, men i den væsentlige logik, der er beskrevet i det følgende. Når programmører uden kommerciel viden programmerer noget...

Hvorfor er beregningen af standardomkostninger i Navision / Business Central blevet så kompliceret?

Okay, det første svar: Fordi det er Microsoft. Korrekt. Okay. Det andet svar: Fordi mennesker har en tendens til at tilføje noget endnu mere kompliceret til noget, der allerede er kompliceret. Det oplever jeg i hvert eneste projekt. Det er også blevet undersøgt videnskabeligt (her er studiet)
Lad os imidlertid hellere vende tilbage til det sagligt korrekte, omend ikke længere tilfredsstillende, svar: Fordi et par kunder ønskede det.
Opgaveformuleringen: Vi bestiller en vare den 1.1.xx til 10 euro. Vi modtager varen den 1.2.xx. Vi sælger varen den 15.2.xx til 30 euro. Vi modtager indkøbsfakturaen for varen den 31.3.xx på 15 euro.
Kundeordren fra den 15.2.xx er nu solgt med en indkøbspris på 10 euro og en avance på 20 euro.

I den finansielle bogføring er alt naturligvis stadig helt i orden, da udgifter og indtægter alle indsamles helt korrekt. Den finansielle bogføring er altid den højeste grad af sandhed.
Men i lagerstyringen har vi nu et salg med et DB (dækningsbidrag) på 20 euro, hvor der reelt kun blev genereret et dækningsbidrag på 15 euro.

Samlet set skader det ingen. Hemmeligheden er den svingende kostpris, ofte også kaldet gennemsnitlig indkøbspris eller kostpris. Man tager simpelthen de gamle lagre med den gamle indkøbspris, lægger den tilkommende lagerforøgelse til og dividerer med det nye samlede lager. Voilá: Så har man en svingende indkøbspris, der følger den reelle indkøbspris meget tæt. Nogle gange er den lidt under, nogle gange lidt over, men gennemsnitligt, passer det ganske godt.

Det var ikke nok for enkelte få kunder. Disse kunder ønskede, at den ovenfor beskrevne salgsproces blev korrekt ført med en indkøbspris på 15 euro i stedet for 10 euro. Den faktisk allerede for længst afsluttede salgsproces måtte derfor korrigeres efter modtagelsen af indkøbsfakturaen – den blev reguleret.

Netop dette gør lagerreguleringen: Den tjekker salgstransaktioner for korrektheden af den anvendte indkøbspris, og korrigerer indkøbsprisen for en salgstransaktion om nødvendigt.
Det er lige så kompliceret, som det lyder – og kræver derfor rigtig mange database transaktioner. Bogføring og regulering tager betydeligt længere tid, på tværs af flere Navision-versioner har det været nødvendigt kun at investere i mere kraftfuld hardware til dette og/eller udføre denne lagerregulering f.eks. i weekenden. Den generelle anbefaling dengang: Hold dig væk fra lagerregulering! Spring den over, åbn den aldrig! Denne situation er blevet betydeligt mere afslappet omkring Navision 2018 BC14, da lagerreguleringen ikke længere belaster serveren så hårdt.

Og fordi dette er så kompliceret, må man ikke rode med Navision. Felterne lagerafgangsmetode (med mulighederne FiFo (Først ind, først ud, f.eks. mælkekartoner, der pænt fyldes op bagfra), LIFO (Sidst ind, først ud, f.eks. sand på en bunke, eller mælkekartoner, der kun genopfyldes forfra), Gennemsnit (f.eks. benzinen på tankstationens tankanlæg)) og indkøbsprisen kan ikke længere nemt ændres. Og enhver prisjustering kræver en stor indsats via indkøbsprisjusteringen. Lagerafgangsmetoden kan slet ikke justeres. Microsoft anbefaler seriøst at erstatte denne vare med en ny vare, der er konfigureret korrekt.

Hvorfor er der brug for denne „præcise“ beregning af indkøbspris?

Siden 1993 har jeg – blandt langt over hundrede projektkunder – kun haft én enkelt kunde, der præcis ønskede denne dækningsbidragsberegning. Selv en længere diskussion om, at han dermed narrede sig selv til en nøjagtighed, han alligevel ikke kunne opnå, hjalp intet. Han forstod ganske vist mit regneeksempel og måtte også give mig ret – men insisterede fortsat på en korrekt anvendelse af lagerreguleringen – med en simpel korrektion af indkøbsprisen. Begge funktioner forstyrrede hinanden i hans Navision-version og kunne kun forenes med stort besvær. Jeg tjener gerne penge – men ikke på meningsløse opgaver. Vi kunne nemlig have fået den efterspurgte løsning meeeget nemmere. Men det skulle absolut køre via lagerreguleringen, og det var simpelthen meningsløst at implementere det sådan. Han fik så den ønskede funktion af mig – og en slutfaktura med afslutning af projektet.

Jeg fandt kundens begrundelse for dette vanvid særligt bemærkelsesværdig og må derfor gengive den her. Det var meningen, at sælgerne i marken og på kontoret skulle bestemme præcis, hvor meget de tjente på en bestemt ordre. Især og netop fordi disse mennesker kunne vælge forskellige indgående partier specifikt til en eksplicit salgsproces. Og i sidste ende skulle hvert parti vise et varespecifikt dækningsbidrag, selv efter at kostpriserne efterfølgende var blevet ændret. Det lyder umiddelbart smart og derfor prisværdigt. Gør det ikke? Men hvad er konsekvensen? Ja, selvfølgelig! Salgspersonalet valgte naturligvis de partier, der gav den mest fordelagtige salgspris og/eller det højeste dækningsbidrag. De andre partier, som blev købt til en for høj pris, blev simpelthen ikke bogført. Derfor blev der naturligvis også foretaget nye indkøb, hvis de lovede gunstigere indkøbsomkostninger end de varer, der stadig var på lager. Varelagerne blev dermed øget, og lagerbindingen blev øget.
Stemte den logiske salgsadfærd, der var afbildet i Navision eller her Business Central, overens med den fysiske lagerbevægelse? Selvfølgelig ikke! På lageret blev produkterne ikke registreret og/eller administreret efter batch. Der blev solgt, hvad der lige var blevet plukket. I hvert fald for de fleste produkter. Den nøjagtige dækningsbidragsberegning var et bastion af kompleksitet, smeltet sammen med et procesorienteret selvbedrag. Og det værste: Kunden gav mig ret. Han måtte give mig ret, efter at vi havde foretaget en lagergennemgang og spurgt lagerchefen om dette emne.
Enkelt er godt. Og: Enkelt er praktisk talt altid bedre. Derfor var det også så nemt for mig at skille mig af med denne kunde efter dette meget specielle projekt.

Hvordan varens kostprisberegning i Navision kan blive utrolig nem igen

Man glemmer alt dette hokus pokus og installerer - forenklet sagt - indkøbsprisen fra det oprindelige Navison, også kendt som Classic Client, igen. Det gjorde indkøbsprisberegningen så nem, som beskrevet ovenfor, indtil ca. 2003.

(Gammel beholdning * Gammel indkøbspris) + (Tilgang * Ny indkøbspris)
===============================================
Ny beholdning

Og præcis denne beregning af indkøbspriser bygger jeg efter dit ønske ind i Navision Financials / Dynamics Attain eller Microsoft Business Central BC365 igen. Du vil som den eneste direkte synlige ændring få et nyt felt i varekortet: kostpris.

Vareomkostninger, købsrelaterede omkostninger

Siden den logiske 2009-version har der været varetillæg og vareafslag. Disse er netop designet til at inkludere kobbertillæg, råvaretillæg og andre omkostninger ved vareudlevering i indkøbsprisen ved salg, og derved reducere dækningsbidraget for en vare. Eller også at øge det, f.eks. ved rabatter.
Den samme funktion findes også i indkøb og er som skabt til at medregne varekøbsomkostninger, fragtomkostninger osv. for varer i indkøb, og også her for at øge indkøbsprisen.
Dette er, typisk for Microsoft, utroligt kompliceret løst og var i starten også fyldt med fejl. I Navision / Business Central versionerne fra omkring Nav 2015 fungerer dette meget pålideligt, men også i tidligere versioner er det godt at bruge, så længe intet går galt (fakturakorrigeringer mv.).

Hvad er vareomkostninger?

Primært f.eks. fragtomkostninger. Men også told og lageromkostninger hører dertil. Specialiteter som kobbertillæg eller generelle materialetillæg er igen særlige ting. Men netop kobbertillæg kan optimalt registreres med linjetypen „Tillæg/fradrag (vare)“ i standard Navision og udelades derfor her.

Registrering af købsrelaterede omkostninger

Generelt skelnes der i de fleste virksomheder mellem 2 typer af indkøbsomkostninger:

• Direkte tilknyttede omkostninger. Disse kan direkte tilknyttes en indkøbsfaktura. Portoomkostninger er et klassisk eksempel: Når varen ankommer til lageret, er de præcise portoomkostninger allerede kendte. Dette er den simpleste variant og kunne endda, med lidt besvær eller tilpasning, registreres med linjetypen „Tillæg/rabat (vare)“ i standard Navision. Ligeså, som nævnt ovenfor, kobbertillæg og andre materialetillæg. Især individuelle samleposter som porto kan dog også nemmere registreres med den her beskrevne funktion for tilknyttede omkostninger.
• Efterfølgende omkostninger. Her er fragt og told klassikerne. Varen har længe været på lager, indkøbsfakturaen er for længst betalt, og så kommer der fragtomkostninger eller toldomkostninger. Disse skal naturligvis også medregnes i indkøbsprisen på den købte vare, og ideelt set også ændre dækningsbidragene på kundefakturaer, der er udstedt i mellemtiden.
  Egentlig er det præcis dette, der er lagerreguleringens domæne. Men på en eller anden måde har den aldrig rigtig fungeret. Og om den nogensinde kommer til at fungere ordentligt? Det ved jeg ikke. Men lagerregulering giver bestemt mange problemer. Det kan den, og den har kunnet det fra dag ét.

Her starter min løsning, især til de oprindelige Navision-versioner op til version 2009R2. Hvis du har brug for denne logik til din RTC-Navision (Navision 2013 til Navision Dynamics / Microsoft Business Central 365) eller din BC 365-løsning, kontakt mig gerne.

Registrering af direkte vareomkostninger (porto)

Hvis du har leverandører, der angiver faste ekstra omkostninger, f.eks. 6,90 € i transportomkostninger (TKA) pr. ordre, kan du indtaste dette direkte på leverandøren:

Alternativt kan du også angive de omkostninger, der gælder for denne transaktion, direkte i indkøbsordren / indkøbsfakturaen.

Vigtigt: Disse omkostninger (MW) indgår kun i indkøbsprisen, når de indtastes i feltet omkostninger (MW)! De øger hverken et samlet faktureringsbeløb for denne ordre eller for denne kreditor! Dette er en rent statistisk forøgelse af indkøbsprisen.

Både fordelingen af de fiktive omkostninger fra feltet omkostninger (MW) og fordelingen af de rækker, der øger den faktiske ordreværdi/faktureringsværdi, udføres automatisk af Navision ved hver bogføring af et bilag, så det er umuligt at „glemme“ denne fordeling. Vigtigt: Begge omkostningstyper (både den fiktive, ikke de omkostninger, der øger ordreværdien/faktureringsværdien, samt de reelle omkostninger, der øger ordreværdien/faktureringsværdien), kan også blandes vilkårligt. Der kan også registreres et vilkårligt antal tilknyttede omkostninger pr. dokument. Alle varekonti i et dokument udgør de tilknyttede omkostninger, som fordeles på vareværdien i samme dokument.

Denne logik virker i

• Indkøbsordrer
• Indkøbsfakturaer
• Indkøb samlefakturaer

Efterfølgende registrering af købsrelaterede omkostninger, f.eks. fragt

Netop ved oversøiske handler (container gods) kommer der forsinkede ekstra indkøbsomkostninger, f.eks. fragt og told.

Til disse findes der også en løsning: Du opretter et nyt bilag, ved at indtaste fragt-, speditør-, told- eller andre udvidede tilknyttede omkostninger. Til dette bilag tildeler du via „add. cost document to“ den oprindelige indgående faktura, der nu skal værdiansættes højere med de ekstra omkostninger.

Ved bogføring af denne post beregner Navision de oprindelige omkostninger på den oprindelige varepost og øger også de oprindelige omkostninger ved de berørte varer.