Voraussichtliche Lesedauer: 13 Minuten

Warum brauchen Sie eine Lagerregulierung? Warum ist die so langsam? Wieso können Sie nicht einfach den Einstandspreis korrigieren, wenn er sich mal geändert hat? Frage ich mich auch, seit Microsoft bei Navision Dynamics Attain bzw. Microsoft Business Central BC365 die Lagerregulierung eingeführt und immer schlimmer gemacht hat. Bei Navision Financials bis etwa version 4 gab es die übrigens nicht, sondern im wesentlichen die im folgenden beschriebene Logik. Wenn Programmierer ohne kaufmännische Kenntnisse etwas programmieren…

Warum ist die Einstandspreisberechnung von Navision / Business Central so kompliziert geworden?

Klar, die erste Antwort: Weil es Microsoft ist. Stimmt. OK. Die zweite Antwort: Weil Menschen dazu tendieren, lieber zu etwas Kompliziertem noch etwas mehr Kompliziertes hinzuzufügen. Das erlebe ich in jedem einzelnen Projekt. Dies wurde auch schon wissenschaftlich untersucht (hier die Studie)
Kommen wir aber nun lieber zu der sachlich korrekten, wenn auch nicht mehr zufrieden stellenden Antwort: Weil ein paar Kunden das so wollten.
Die Aufgabenstellung: Wir bestellen einen Artikel am 1.1.xx zu 10 Euro. Wir bekommen den Artikel am 1.2.xx geliefert. Wir verkaufen den Artikel am 15.2.xx zu 30 Euro. Wir erhalten die Einkaufsrechnung zu dem Artikel am31.3.xx über 15 Euro.
Der Kundenauftrag vom 15.2.xx wurde nun mit einem Einstandspreis von 10 Euro und einer Marge von 20 Euro verkauft.

In der Finanzbuchhaltung ist natürlich alles weiter völlig OK, da die Aufwendungen und die Erträge alle komplett korrekt gesammelt werden. Die Finanzbuchhaltung ist immer die höchste Stufe der Wahrheit.
Aber in der Warenwirtschaft haben wir nun einen Verkaufsvorgang mit einem DB von 20 Euro, wo in Wirklichkeit nur eine Deckung von 15 Euro erwirtschaftet wurde.

Unter dem Strich tut das niemanden Weh. Das Geheimnis ist der gleitende Einstandspreis, oft auch als Durchschnittlicher Einstands oder Mischpreis bezeichnet. Man nimmt einfach die alten Bestände mit dem alten Einstandspreis, rechnet den hinzukommenden Lagerwert dazu, und teilt durch den neuen Gesamtbestand. Voilá: Man hat einen gleitenden Einstandspreis, der dem realen Einstandspreis sehr gut folgt. Mal ist er etwas drunter, mal etwas drüber, aber im Mittel, im Durchschnitt, passt das ganz gut.

Das reichte einigen wenigen Kunden nicht. Diese Kunden wollten, dass der oben beschriebene Verkaufsvorgang korrekt mit einem Einstandspreis von 15 Euro statt 10 Euro geführt wird. Der eigentlich schon lange abgeschlossene Verkaufsvorgang musste also nach dem Eintreffen der Einkaufsrechnung korrigiert werden – er wurde reguliert.

Genau dies macht die Lagerregulierung: Sie prüft Verkaufsvorgänge auf die Korrektheit des dort jeweils genutzten Einstandspreises, und korrigiert bei Bedarf den Einstandspreis eines Verkaufvorgangs.
Das ist so kompliziert wie es sich anhört – und braucht dafür sehr viele Datenbank Transaktionen. Das Buchen und Regulieren braucht deutlich mehr Zeit, über einige Navisionversionen hinweg musste nur dafür in leistungstärkere Hardware investiert werden und/oder diese Lagerregulierung z.B. am Wochenende durchgeführt werden. Die allgemeine Empfehlung damals: Finger weg von der Lagerregulierung! Einfach weg lassen, nie aufrufen! Diese Situation hat sich so etwa mit Navision 2018 BC14 deutlich entspannt, da tut die Lagerregulierung dem Server nicht mehr so weh.

Und weil dies so kompliziert ist, darf man eben Navision nicht dazwischen fummeln. Die Felder Lagerabgangsmethode (mit den Optionen FiFo (First In First Out, z.B. Milchtüten, die schön ordentlich von hinten nachgefüllt werden), Lifo (Last In First Out, z.B. Sand auf einem Haufen, oder Milchtüten, die einfach nur von vorne wieder nachgefüllt werden), Durchschnitt (z.B. das Benzin im Erdtank bei der Tankstelle)) und den Einstandspreis später nicht mehr einfach so verändern. Und jede Preiskorrektur erfordert viel Aufwand über die Einstandspreis korrektur. Die Lagerabgangsmethode kann gar nicht korrigiert werden. Microsoft empfiehlt hier allen Ernstes, diesen Artikel durch einen neuen Artikel zu ersetzen, der korrekt eingerichtet wurde.

Für was braucht man diese „Exakte“ Einstandspreisberechnung?

Seit 1993 habe ich -zwischen weit über hundert Projektkunden- bis heute erst einen einzigen Kunden gehabt, der genau diese Deckungsbeitragsrechnung haben wollte. Auch eine längere Diskussion, dass er damit sich selbst eine Genauigkeit vorgaukelt, die er gar nicht erzielen kann, nützte nichts. Er hat durchaus meine Rechenbeispiel verstanden und musste mir auch Recht geben – bestand aber weiter auf einer korrekten Anwendung der Lagerregulierung – MIT einer einfachen Korrektur des Einstandspreises. Beide Funktionen zusammen gingen sich in seiner Navision-version gegenseitig aus dem Weg, und waren nur mit sehr viel Aufwand zu vereinen. Ich verdiene gerne Geld – aber nicht mit unsinnigen Tätigkeiten. Wir hätten nämlich die geforderte Lösung auch vieeeeel Einfacher haben können. Aber es sollte unbedingt über die Lagerregulierung laufen, und das war einfach unsinnig, das so umzusetzen. Er bekam dann von mir die gewünschte Funktion – und eine Abschlussrechnung mit Beendigung des Projektes.

Besonders die Begründung des Kunden für diesen Irrsinn fand ich bemerkenswert, und muss sie daher hier einmal wiedergeben. Die Außendienstler und Innendienstverkäufer sollten exakt feststellen, wie viel Sie mit einem bestimmten Auftrag verdient haben. Insbesondere und gerade deshalb, weil diese Personen verschiedenen Eingangsschargen gezielt für einen expliziten Verkaufsvorgang auswählen konnten. Und jede Charge sollte am ende, also auch, nachdem sich nachträglich noch Einstandspreise geändert haben, einen positionsgenauen Deckungsbeitrag ausweisen. Klingt erst einmal klug und somit lobenswert. Oder? Was ist jedoch die Konsequenz? Na klar! Die Vertriebsmitarbeiter haben natürlich jeweils genau die Chargen ausgesucht, welche den günstigsten Verkaufspreis und/oder höchsten Deckungsbeitrag ermöglichten. Die anderen, zu teuer eingekauften Chargen, wurden einfach nicht bebucht. In der Folge wurden natürlich auch schon einmal neue Einkäufe getätigt, wenn diese zu günstigeren Beschaffungskosten als die noch auf Lager liegenden Artikel versprachen. Lagerbestände wurden damit hochgefahren, die Lagerkapitalbindung erhöht.
Entsprach das logisch in Navision bzw. hier Business Central abgebildete Verkaufsverhalten der physikalischen Lagerbewegung? Natürlich nein! Im Lager wurden die Produkte nicht Chargenmassig erfasst und/oder verwaltet. Es wurde verkauft, was gerade gepickt wurde. Zumindest bei den meisten Produkten. Die Centgenaue Deckungsbeitragsberechnung war ein Bollwerk an Kompliziertheit, verschweißt mit einem prozessfixiertem Selbstbetrug. Und das schlimmste: Der Kunde hat mir zugestimmt. Er musste mir zustimmen, nachdem wir eine Lagerbegehung gemacht haben und den Lagerleiter zu diesem Thema befragt haben.
Einfach ist gut. Und: Einfach ist praktisch immer besser. Deshalb war es auch so einfach für mich, Mich von diesem Kunden nach diesem sehr speziellen Projekt zu trennen.

Wie die Einstandspreisberechnung von Navision wieder unglaublich einfach werden kann

Man vergisst dieses ganzen Hokus Pokus, und installiert sich -vereinfacht ausgedrückt- wieder die Einstandspreis vom „Nativen Navison“, auch als Classic Client bezeichnet. Das machte die Einstandspreisberechnung nämlich bis ca. 2003 so einfach, wie oben beschrieben.

(Alter Bestand * Alter Einstandspreis) + (Zugang * Neuer Einstandspreis)
===============================================
Neuer Bestand

Und genau diese Einstandspreisberechnung baue ich Ihnen auf Wunsch wieder in Ihr Navision Financials / Dynamics Attain oder Microsoft Business Central BC365 ein. Sie erhalten als einzige direkt sichtbare Änderung ein neues Feld in der Artikelkarte: Gleitender Einstandspreis.

Warenbezugskosten, Bezugsnebenkosten

Seit etwa der logischen 2009er Version gibt es die Artikelzuschläge und Artikelabschläge. Diese sind genau dafür gemacht, um im Verkauf Kupferzuschläge, Rohstoffzuschläge und andere Kosten der Warenabgabe in den Einstandspreis einzurechnen, und dadurch den Deckungsbeitrag eines Artikels zu verringern. Oder auch, z.B. bei Rabatten, zu erhöhen.
Die gleiche Funktion gibt es auch im Einkauf, und ist wie gemacht dafür, Warenbezugskosten, Frachtkosten etc. für Artikel im Einkauf mitzurechnen, und auch hier den Einstandspreis zu erhöhen.
Das ist, Microsoft-typisch, unglaublich kompliziert gelöst, und war anfangs auch voller Fehler. In den Navision / Business Central Versionen so etwa ab Nav 2015 funktioniert dies sehr zuverlässig, aber auch in den Vorversionen ist das gut zu benutzen, so lange nichts schief geht (Rechnungskorrekturen etc).

Was sind Warenbezugskosten?

Hauptsächlich z.B. Frachtkosten. Aber auch Zölle, Einlagerkosten, Lagerkosten im Allgemeinen zählen dazu. Spezialisten wir Kupferzuschläge oder generell Materialzuschläge sind wieder extra Spezialitäten. Aber gerade Kupferzuschläge lassen sich optimal mit der Zeilenart „Zu/Abschlag (Artikel)“ im Standard Navision erfassen, und werden daher hier ausgeklammert.

Erfassen von Bezugskosten

Generell unterscheiden sich die Bezugskosten in den meisten Firmen in 2 Arten:

• Direkte Bezugskosten. Diese können direkt einer Einkaufsrechnung zugeordnet werden. Portokosten sind so ein Klassiker: Wenn die Ware im Lager eintrifft, sind bereits die exakten Portokosten bekannt. Dies ist die einfachste Variante, und könnte sogar mit etwas Mühe oder Anpassung mit der Zeilenart „Zu/Abschlag (Artikel)“ im Standard Navision erfasst werden. Ebenso, wie bereits weiter oben erwähnt, Kupferzuschläge und andere Materialzuschläge. Gerade einzelne Sammelpositionen wie Porto kann allerdings auch einfacher mit der hier beschriebenen Bezugskostenfunktion erfasst werden.
• Nachgelagerte Bezugskosten. Hier sind Frachten & Zölle die Klassiker. Die Ware ist schon lange im Lager, die Einkaufsrechnung dazu bereits lange bezahlt, und dann kommen noch Frachtkosten oder Zollkosten. Diese sollen natürlich auch noch in die Einstandskosten des gekauften Artikels rein, und idealerweise auch noch die Deckungsbeiträge der in der Zwischenzeit fakturierten Kundenrechnungen verändern.
  „Eigentlich“ ist genau dies die Domäne der Lagerregulierung. Doch irgendwie hat die niemals so richtig funktioniert. Und ob Sie auch jemals richtig funktionieren wird? Ich weiß es nicht. Aber die Lagerregulierung macht auf jeden Fall viel Probleme. Das kann sie und konnte Sie vom ersten Tag an.

Hier setzt meine Lösung an, insbesondere für die nativen Navision-Versionen bis zur Version 2009R2. Wenn Sie an dieser Logik für ihr RTC-Navision (Navision 2013 bis Navision Dynamics / Microsoft Business Central 365) oder ihre BC 365 Lösung benötigen, sprechen Sie mich bitte an.

Erfassung von direkten Warenbezugsnebenkosten (Porto)

Wenn Sie Lieferanten haben, die fixe Bezugsnebenkosten vorgeben, z.B. 6,90 € Transportkostenanteil (TKA) pro Bestellung, so können Sie dies direkt im Lieferanten erfassen:

Alternativ können Sie auch pro Einkaufsrechnung die für diesen Vorgang gültigen Bezugsnebenkosten direkt in der Bestellung / in der Einkaufsrechnung erfassen.

Wichtig: Diese Kosten (MW) fließen bei Eingaben in dem Feld Kosten (MW) lediglich in den Einstandspreis ein! Sie erhöhen weder bei dieser Bestellung noch bei diesem Kreditoren einen Endbetrag der Rechnung! Dies ist eine rein statistische Einstandspreiserhöhung.

Sowohl die Verteilung der fiktiven Nebenkosten aus dem Feld Kosten (MW) wie auch die Verteilung der tatsächlich Bestellwert/Rechnungswert erhöhenden Zeilenbeträge werden von Navision auch bei jeder Buchung eines Beleges automatisch durchgeführt, ein „Vergessen“ dieser Verteilung ist unmöglich. Wichtig: Beide Kostenarten (sowohl die fiktive, nicht den Bestellwert/Rechnungswert erhöhende Kosten, wie auch die echten, den Bestellwert/Rechnungswert erhöhende Kosten) können auch beliebig gemischt verwendet werden. Es können auch pro Beleg beliebig viele Bezugsnebenkosten erfasst werden. Alle Sachkonten eines Beleges ergeben die Bezugsnebenkosten, die auf die Warenwerte des gleichen Beleges verteilt werden.

Diese Logik arbeitet in

• Einkaufsbestellungen
• Einkaufsrechnungen
• Einkauf Sammelrechnungen

Nachträgliches erfassen von Bezugskosten, z.B. Fracht

Gerade bei Überseegeschäften (Containerwaren) kommen zusätzliche Bezugskosten erst verspätet an, so z.B. Fracht & Zoll.

Auch für diese gibt es eine Lösung: Sie erfassen einen neuen Beleg, indem Sie die Fracht-, Speditions-, Zoll- oder sonstigen erweiterten Bezugskosten erfassen. Diesem Beleg ordnen Sie per „Add. Cost Document to“ die ursprüngliche, nun um die zusätzlichen Kosten höher zu bewertende Eingangsrechnung zu.

Beim Verbuchen dieses Belegs rechnet Navision die Einstandskosten in dem ursprünglichen Warenbeleg hoch, und erhöht auch die Einstandskosten in den betroffenen Artikeln.