Hvad skal jeg indstille for at få en korrekt lagerværdi?
Hvorfor kan Navision ikke bare bestemme en korrekt aktieværdi?
Hvordan bestemmer jeg et korrekt lagerniveau/lagerværdi?
Hvordan bestemmer Navision eller Business Central kostprisen?
Hvis du allerede har kigget lidt på mine sider her, så har du nok gættet det: Jeg elsker (og lever) Navision. Og efterhånden også Business Central. Men der er stadig et par ting i Navision/Business Central, som får en til at tænke: „Har de dem ikke alle sammen?? Eller er jeg skør?“. Den Microsoft (eller den oprindelige producent Navision) har ikke leveret nogen fornuftigt opsatte eller forberedte adgangsrettigheder siden 1993, er en af de ting, der virkelig får mig til at klø mig i hovedet.
En anden er justering af lejer. Hvad skal man altid forholde sig til? Regulering af lagre. Faktiske kostpriser. Faktiske indkøbspriser. Metode til bortskaffelse af lager. „Kostprisen er reguleret“. Hvad er det? Og hvorfor? Hvem regulerer min kostpris her? Er vi i kommunismen med statsregulerede målpriser? Og hvad er disse slutposter? Hvad fortæller kostprisen (forventet) mig, og hvad er forskellen mellem kostprisen (faktisk) og kostprisen (faktisk)?
Tag også et kig på denne artikel her, den besvarer måske også et af dine spørgsmål?
Historie
„Alting var bedre før i tiden“... Nej, selvfølgelig var det ikke det. Især når det gælder varestyringssystemer og finansbogholderi, har programmerne/systemerne aldrig været nemmere at bruge, end de er i dag. Men for at rationalisere brugen af IT-ressourcer dengang var nogle ting enklere og mere funktionelle, end de er i dag. For eksempel blev den gennemsnitlige kostpris (glidende kostpris) tidligere beregnet ganske enkelt:
Denne enkle løsning var meget elegant. For eksempel kunne en forkert købsfaktura (f.eks. med en forkert enhed) rettes meget nemt: Ring op til varemasteren, ret Ø kostpris, og alt var godt igen.
Lagerværdien blev beregnet tilsvarende enkelt: Lager pr. vare x kostpris pr. vare, det hele blev lagt sammen, og lagerbeholdningen var klar.
Baggrund
Denne superenkle metode fra fortiden havde to ulemper set fra Microsofts synspunkt:
a) Den bevægelige kostpris fulgte købsprisen.fakturaer, ikke indkøbeneLeverancer. I tilfælde af tilførsler gennem produktionen kunne den glidende kostpris tilpasse sig endnu langsommere til prisudviklingen. Dette var generelt ikke et problem, da den glidende kostpris i gennemsnit over måneder eller året stadig var passende. Hvis den steg (eller faldt) for langsomt, blev dens fald (eller stigning) også forsinket. Dette var nogenlunde korrekt for året.
Det var meget vigtigere at inkludere leveringsomkostningerne korrekt i kostprisen. Jeg har allerede en løsning til dette, som snart vil blive offentliggjort her.
b) Der var næppe nogen praktisk måde at bestemme en glidende kostpris for fortiden, f.eks. pr. 31. december 2020. Navision og Business Central har aldrig haft problemer med at bestemme lagre på et hvilket som helst tidspunkt. Men en gennemsnitlig kostpris på en given dato? Det var desværre ikke muligt med denne genialt enkle løsning.
Bare gemme den gamle gennemsnitlige kostpris i vareposten, hver gang der tilføjes varer? Nej. Det kan enhver forstå, og enhver kan genberegne og forstå det. Det er for nemt for Microsoft.
c) Hvis vi gør det rigtig kompliceret, så inkluderer vi også en 3. „løsning“! Problem: Et produkt bliver leveret den 1. februar. Indtil dette tidspunkt havde det en glidende (gennemsnitlig) kostpris på 5 euro. Den 2. februar bliver det solgt (leveret og faktureret) til 8 euro. Dækningsbidraget er derfor 3 euro. Købsfakturaen kommer den 3. februar: 7 euro. Den bevægelige kostpris i varekartoteket justeres i overensstemmelse hermed. Den salgsfaktura, der allerede er bogført, gemmer dog stadig den oprindelige kostpris på 5 euro, selvom dækningsbidraget nu allerede er blevet reduceret.
Som nævnt ovenfor: over en længere periode betyder det ikke noget, det „udligner sig selv“.
Microsoft-løsning
Microsoft indførte storage regulation, som faktisk løste de førnævnte problemer ... i hvert fald i teorien. I praksis har denne tilgang desværre skabt og skaber fortsat flere problemer end løsninger. Hvis du læser artiklen her, ved du, hvad jeg mener.
Løsning Thöne
Tilbage til rødderne! I det mindste til aktieevalueringen har jeg derfor lavet en meget enkel (!) rapport, som blot beregner som før... i princippet.
Hvad gør Navision eller Business Central her? Først og fremmest bestemmes lagerbeholdningen på nøgledatoen (her: 14.7.21).
Afhængigt af indstillingen tages den købspris, der er gyldig på denne nøgledato (fra købspriserne). Eller den gennemsnitlige kostpris fra de sidste 3 køb før denne skæringsdato.
„Man kan selvfølgelig sortere listen, som man vil, f.eks. efter højeste lagerværdi, alfabetisk, varetype eller andet. Hvis vi skal kæmpe med RDLC, så vil vi gerne have noget ud af det.
Denne løsning skal forstås som en ramme; den skal helt sikkert tilpasses i detaljer i henhold til dine specifikationer. Men det er en ret pragmatisk tilgang til alle dem, der i årevis har spekuleret på, om de nogensinde vil få en pålidelig og verificerbar lagerværdi fra deres Navision. Tal til mig, hvis du også vil have „Simpelt er godt“ 🙂.