Estimated reading time: 13 minutes

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 Stock regulation 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…

Why has Navision / Business Central's cost price calculation become so complicated?

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. This is what I experience in every single project. 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.
The task: We order an item on 1.1.xx at 10 Euro. We get the article delivered on 1.2.xx. We sell the article on 15.2.xx for 30 Euro. We receive the purchase invoice for the article on31.3.xx for 15 Euro.
The sales order from 15.2.xx has now been sold with a cost price of 10 Euro and a margin of 20 Euro.

In the financial accounting, of course, everything continues to be completely OK, since the expenses and the income are all collected completely correctly. Financial accounting is always the highest level of truth.
But in the inventory management we now have a sales transaction with a DB of 20 euros, where in reality only a cover of 15 euros was earned.

The bottom line is that it doesn't hurt anyone. The secret is the moving cost price, often called the average cost or blended price. You simply take the old inventory at the old cost price, add in the inventory value being added, and divide by the new total inventory. Voila: You have a moving cost price that follows the real cost price very well. Sometimes it is a little lower, sometimes a little higher, but on average, it fits quite well.

This was not enough for a few customers. These customers wanted the sales transaction described above to be correctly managed with a cost price of 15 euros instead of 10 euros. The sales transaction, which had actually been completed a long time ago, therefore had to be corrected after the purchase invoice arrived - it was regulated.

This is exactly what warehouse regulation does: it checks sales transactions for the correctness of the cost price used there in each case, and corrects the cost price of a sales transaction if necessary.
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.

And because this is so complicated, you can't mess with Navision in between. The fields Stock Disposal Method (with the options FiFo (First In First Out, e.g. milk cartons that are refilled nice and neat from the back), Lifo (Last In First Out, e.g. sand in a pile, or milk cartons that are simply refilled from the front), Average (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.

What do you need this "exact" cost price calculation for?

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 Stock regulation – 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. Inventories were thus ramped up,, and inventory capital commitment increased..
Entsprach das logisch in Navision bzw. hier Business Central abgebildete Verkaufsverhalten der physikalischen Lagerbewegung? Natürlich not! 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.

How Navision's cost price calculation can become incredibly simple again

You forget all this hocus pocus, and install - in simple terms - the purchase price of the "Native Navison", also called Classic Client. This made the cost price calculation until about 2003 as simple as described above.

(Old inventory * Old purchase price) + (Receipts * New purchase price)
===============================================
New inventory

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.

Cost of goods purchased, incidental costs of purchase

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.
The same function is also available in Purchasing, and is designed to include the cost of goods purchased, freight costs, etc. for items in Purchasing, and to increase the cost price here as well.
This is, typical for Microsoft, incredibly complicated solution, and was initially also full of errors. In the Navision / Business Central versions from about Nav 2015 onwards, this works very reliably, but it is also good to use in the previous versions, as long as nothing goes wrong (invoice corrections, etc.).

What are goods purchase costs?

Mainly freight costs, for example. But also customs duties, warehouse costs, storage costs in general are part of it. Specialists like copper surcharges or material surcharges in general are again extra specialties. But especially copper surcharges can be entered optimally with the line type "Surcharge/Discount (Article)" in the standard Navision, and are therefore excluded here.

Recording of procurement costs

Generally speaking, the purchase costs in most companies differ into 2 types:

• Direct purchase costs. These can be directly assigned to a purchase invoice. Postage costs are such a classic: When the goods arrive in the warehouse, the exact postage costs are already known. This is the simplest variant, and could even be entered with a little effort or customization with the line type "Addition/Discount (Item)" in standard Navision. Likewise, as mentioned above, copper surcharges and other material surcharges. However, especially individual collective items such as postage can also be recorded more simply with the reference cost function described here.
• Downstream procurement costs. Freight and customs duties are the classics here. The goods have been in the warehouse for a long time, the purchase invoice has been paid for a long time, and then there are freight costs or customs duties. These should of course also be included in the cost price of the purchased item, and ideally also change the contribution margins of the customer invoices that have been invoiced in the meantime.
  "Actually", this is exactly the domain of the stock regulation. But somehow it has never really worked. And whether it will ever work properly? I don't know. But the bearing regulation definitely causes a lot of problems. It can and has been able to do that from day one.

This is where my solution comes in, especially for the native Navision versions up to version 2009R2. If you need to work on this logic for your RTC Navision (Navision 2013 to Navision Dynamics / Microsoft Business Central 365) or your BC 365 solution, please contact me..

Recording of direct goods purchase incidental costs (postage)

If you have suppliers who specify fixed delivery costs, e.g. 6.90 € transport cost share (TKA) per order, you can enter this directly in the supplier:

Alternatively, you can also enter the delivery costs valid for this transaction directly in the purchase order/purchase invoice for each purchase invoice.

Important: These costs (MW) are only included in the cost price when entered in the field Costs (MW)! They do not increase a final invoice amount for this order or for this vendor! This is a purely statistical cost price increase.

Both the distribution of the fictitious additional costs from the field Costs (MW) as well as the distribution of the actual order value/invoice value increasing line amounts are also carried out automatically by Navision with each posting of a document, a "forgetting" of this distribution is impossible. Important: Both types of costs (fictitious costs that not increase the order value/invoice value as well as real costs that increase the order value/invoice value) can be mixed. It is also possible to enter any number of delivery costs per document. All G/L accounts of a document result in the delivery costs, which are distributed to the goods values of the same document.

This logic operates in

• Purchase orders
• Purchase Invoices
• Purchase collective invoices

Subsequent recording of reference costs, e.g. freight

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

There is also a solution for this: you enter a new document by entering the freight, forwarding, customs or other extended procurement costs. To this document you assign the original, now higher valued by the additional costs, via "Add. Cost Document to", you assign the original incoming invoice, which is now to be valuated higher by the additional costs.

When posting this document, Navision extrapolates the cost price in the original goods receipt, and also increases the cost price in the affected items.