Anslået læsetid: 13 minutter

Hvorfor skal der laves vare regulering? Hvorfor går det så langsomt? Hvorfor kan man ikke bare rette kostprisen, når den engang har ændret sig? Det spørger jeg mig selv om, siden Microsoft lukkede for Navision Dynamics Attain eller Microsoft Business Central BC365 til den Lagerregulering blev introduceret og kun gjort værre. Hos Navision Financials op til omkring version 4 fandtes den i øvrigt ikke, men i det væsentlige den 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. Dette er også blevet undersøgt videnskabeligt (her studien)
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 lagerstyring har vi nu et salg med et DB (bidrag) på 20 euro, hvor der reelt kun blev genereret et dækning på 15 euro.

Alt i alt skader det ingen. Hemmeligheden er den glidende indkøbspris, ofte også kaldet gennemsnitlig indkøbspris eller blandingspris. 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á: Man har en glidende indkøbspris, der følger den reelle indkøbspris meget tæt. Nogle gange er den lidt under, nogle gange lidt over, men i gennemsnit, 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 der, 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 lagerreguleringen! Spring den over, kald den aldrig op! Denne situation er blevet betydeligt 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 Lagerudgangsmetode (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 bare genopfyldes bagfra), Gennemsnit (f.eks. benzinen på tankstationens tankanlæg)) og ikke længere nemt kan ændre indkøbsprisen. Og enhver prisjustering kræver en stor indsats via indkøbsprisjusteringen. Udgangsmetoden kan slet ikke justeres. Microsoft anbefaler seriøst at erstatte denne vare med en ny vare, der er konfigureret korrekt.

Til hvad 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 Lagerregulering – med en simpel korrektion af anskaffelsesprisen. Begge funktioner forstyrrede hinanden i hans Navision-version og kunne kun forenes med stor indsats. Jeg tjener gerne penge – men ikke på meningsløse aktiviteter. Vi ville nemlig have efterspurgte løsning også vieeeeel nemmere have kunnet. Men det skulle absolut køre via lagerreguleringen, og det var simpelthen meningsløst at implementere det sådan. Han fik så af mig den ønskede funktion – og en afsluttende faktura 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 salgsrepræsentanterne og de kontorbaserede sælgere 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. Er 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, som Øget lagerbinding af arbejdskapital.
Stemte det logiske salgsadfærd, der var afbildet i Navision eller her Business Central, overens med den fysiske lagerbevægelse? Selvfølgelig nejPå 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 centnøjagtige dækningsbidragsberegning var et bastion af kompleksitet, smeltet sammen med en 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 - anskaffelsesprisen fra „Native Navison“, også kendt som Classic Client, igen. Det gjorde anskaffelsesprisberegningen 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 anskaffelsespriser bygger jeg efter ønske ind i din Navision Financials / Dynamics Attain eller Microsoft Business Central BC365 igen. Du vil som den eneste direkte synlige ændring få et nyt felt i varekortet: Glidende anskaffelsespris.

Vareomkostninger, købsrelaterede omkostninger

Siden omkring den logiske 2009-version har der været vareopslag og vareafslag. Disse er netop designet til at inkludere kobberopslag, råvareopslag 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 øge enhedsprisen.
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 vareanskaffelsesomkostninger?

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

Registrering af tilknyttede 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 anskaffelsesprisen på den købte vare, og ideelt set også ændre dækningsbidragene på kunde fakturaer, 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 native 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, tal venligst til mig.

Registrering af direkte omkostninger ved vareanskaffelse (porto)

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

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

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 tilhørende omkostninger pr. dokument. Alle varekonti i et dokument udgør de tilhørende omkostninger, som fordeles på varernes værdier i samme dokument.

Denne logik virker i

• Indkøbsordrer
• Indkøbsregninger
• Indkøb Samlefakturaer

Efterfølgende registrering af omkostninger til tilknytning, f.eks. fragt

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

Til disse findes der også en løsning: Du opretter en ny 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 i den oprindelige varepost og øger også de oprindelige omkostninger i de berørte artikler.