Einfache Lagerwertermittlung in Navision / Business Central

Navision · Shopware · App

Was muss ich einstellen, um einen korrekten Lagerwert zu erhalten?
Warum kann Navision nicht einfach einen richtigen Lagerwert ermitteln?
Wie ermittle ich einen korrekten Lagerbestand / Lagerbestandswert?
Wie ermittelt Navision oder Business Central eigentlich den Einstandspreis?

Wenn Sie meine Seiten hier schon ein bisschen durchstöbert haben, dann erahnen Sie es: Ich liebe (und lebe) Navision. Und so nach und nach auch Business Central. Aber trotzdem gibt es so ein paar Dinge in Navision / Business Central, da fragt man sich doch: „Haben Die sie denn nicht alle? Oder spinne ich?“. Das Microsoft (bzw. der ursprüngliche Hersteller Navision) seit 1993 keine vernünftig eingerichteten bzw. vorbereiten Zugriffsrechte mitliefert, ist so ein Punkt davon, wo ich mich echt an den Kopf fasse.

Ein anderer ist die Lagerregulierung. Mit was muss man sich da alles herumschlagen. Lagerregulierung. Faktische Einstandspreise. Faktische Einkaufspreise. Lagerabgangsmethode. „Einstandspreis ist reguliert“. Was? Warum? Wer reguliert hier meinen Einstandspreis? Sind wir im Kommunismus mit staatlich regulierten Vorgabepreisen? Und was sind diese Abschlussposten? Was sagen mit der Einstandspreis (erwartet) und was ist der Unterschied zu Einstandspreis (tatsächl.) bzw. Einstandspreis (tatsächlich)?

Historie

„Früher war alles besser“… Nein, war es natürlich nicht. Gerade bei Warenwirtschaftsystemen und Finanzbuchhaltungen waren die Programme / Systeme nie einfacher zu bedienen als heute. Aber um mit den damaligen IT-Ressourcen rationell umzugehen, waren einige Dinge einfacher und funktionaler als heute. Z.B. wurde früher der Ø Einstandspreis (Gleitender Einstandspreis) ganz einfach so ermittelt:

Navision berechnete bis etwa zur Version 2.60 den gleitenden Einstandspreis sehr einfach mit alten Bestandswert und neuem Bestandswert

Diese einfache Lösung hatte sehr viel Eleganz. So konnte z.B. eine Fehlerhafte Einkaufsrechnung (z.B. mit einer falschen Einheit) Kinderleicht korrigiert werden: Artikelstamm aufrufen, Ø Einstandspreis korrigieren, und schon war alles wieder gut.

Dementsprechend einfach wurde auch der Lagerwert ermittelt: Bestand pro Artikel x Einstandspreis pro Artikel, das ganze aufsummiert, und fertig war der Lagerbestand.

Hintergrund

Diese Supereinfache Methode von früher hatte aus Sicht von Microsoft 2 Nachteile:
a) Der gleitende Einstandspreis folgte den Einkaufsrechnungen, nicht den Einkaufslieferungen. Bei Zugängen durch Fertigung konnte sich der gleitende Einstandspreis noch langsamer an die Preisentwicklung anpassen. Dies war im allgemeinen kein Problem, da über Monate oder das Jahr gemittelt der gleitende Einstandspreis ja immer noch passte. Wenn er einmal zu langsam anstieg (oder abfiel), dann verzögerte sich ja auch sein Abstieg (oder Steigerung). So in etwa stimmte das dann schon im Jahr.

Viel wichtiger war es, auch Bezugsnebenkosten korrekt in den Einstandspreis einfließen zu lassen. Hierzu gibt es auch schon eine Lösung von mir, die demnächst hier veröffentlicht wird.

b) Es gab kaum eine praktikable Möglichkeit, einen gleitenden Einstandspreis für die Vergangenheit zu ermitteln, also z.B. zum 31.12.2020. Navision und Business Central hatten ja noch nie Probleme damit, Bestände zu jedem beliebigen Zeitpunkt zu ermitteln. Aber ein durchschnittlicher Einstandspreis zu einem beliebigen Datum? Das war mit dieser genial einfachen Lösung leider nicht möglich.

Einfach bei jedem Warenzugang den alten Ø Einstandspreis zusätzlich im Warenposten speichern? Nein. Das könnte ja jeder verstehen, jeder nachrechnen und nachvollziehen. Das ist zu einfach für Microsoft.

c) Wenn man es schon richtig kompliziert macht, dann packen wir auch noch eine 3. „Lösung“ mit rein! Problem: Eine Ware wird zum 1.2. geliefert. Bis zu diesem Zeitpunkt hatte Sie einen gleitenden (durchschnittlichen) Einstandspreis von 5 Euro. Am 2.2. wird sie zu 8 Euro verkauft (geliefert & berechnet). Der Deckungsbeitrag ist also 3 Euro. Am 3.2. kommt die Einkaufsrechnung: 7 Euro. Der gleitende Einstandspreis im Artikelstamm wird entsprechend angepasst. Die bereits gebuchte Verkaufsrechnungarbeitet speichert aber noch immer den ursprünglichen Einstandspreis von 5 Euro, obwohl die Deckung, der Deckungsbeitrag sich nun schon reduziert hat.

Wie weiter oben erwähnt: Über eine längere Laufzeit macht das nichts aus, das „mittelt sich weg“.

Lösung Microsoft

Microsoft führte die Lagerregulierung ein, die die erwähnten Probleme tatsächlich löste, … zumindest theoretisch. Praktisch war es dann leider so, dass dieses Vorgehen mehr Probleme als Lösungen verursachte und verursacht. Wenn Sie diesen Artikel hier lesen, wissen Sie, was ich meine.

Lösung Thöne

Back to the roots! Zumindest für die Lagerbewertung habe ich daher einen sehr einfachen (!) Bericht erstellt, welcher einfach wieder so rechnet wie früher… im Prinzip.

Screenshot Navision bzw. Business Central RTC Aufruf der einfachen Lagerwertermittlung / einfache Lagerbewertung
Berichtsanforderung / Report Startbildschirm der einfachen Lagerberwertung /einfache Lagerwertermittlung

Was macht Navision bzw. Business Central hier nun? Erst einmal den Lagerbestand zum Stichtag (hier: 14.7.21) ermitteln.
Je nach Einstellung wird dann noch der zu diesem Stichtag gültige Einkaufspreis gezogen (aus den Einkaufspreisen). Oder eben der Ø Einstandspreis aus den letzten 3 vor diesem Stichtag liegenden Einkäufen.

„Selbstverständlich“ können Sie die Liste dann noch beliebig sortieren, z.B. nach höchsten Lagerwert, Alphabetisch, Artikelart oder was auch immer. Wenn wir uns schon mit RDLC herumquälen müssen, dann wollen wir ja auch etwas davon haben.

Diese Lösung ist als Gerüst zu verstehen, sicherlich muss da noch im Einzelnen etwas nach Ihren Vorgaben angepasst werden. Aber es ist halt ein pragmatischer Ansatz für alle, die sich schon seit Jahren Fragen, ob Sie wohl jemals einen belastbaren und prüfbaren Lagerbestandswert aus ihrem Navision herausbekommen. Sprechen Sie mich an, wenn Sie auch „Einfach ist gut“ wünschen 🙂