Tiempo estimado de lectura: 13 minutos

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 Regulación de los rodamientos 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…

¿Por qué se ha complicado tanto el cálculo del precio de coste de Navision / Business Central?

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. Esto es lo que me ocurre en cada proyecto. 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.
La tarea: Pedimos un artículo el 1.1.xx a 10 euros. Recibimos el artículo el 1.2.xx. Vendemos el artículo el 15.2.xx por 30 euros. Recibimos la factura de compra del artículo el 31.3.xx por 15 euros.
El pedido de 15.2.xx ya se ha vendido con un precio de coste de 10 euros y un margen de 20 euros.

En la contabilidad financiera, por supuesto, todo sigue estando completamente bien, ya que los gastos y los ingresos se recogen de forma totalmente correcta. La contabilidad financiera es siempre el nivel más alto de la verdad.
Pero en la gestión de mercancías tenemos ahora una operación de venta con una DB de 20 euros, cuando en realidad sólo se ganó una cobertura de 15 euros.

La conclusión es que no hace daño a nadie. El secreto es el precio de coste móvil, a menudo denominado precio de coste medio o precio mixto. Simplemente se toman las existencias antiguas al precio de coste antiguo, se añade el valor de las existencias y se divide por las nuevas existencias totales. Voilá: Tiene un precio de coste móvil que sigue muy bien el precio de coste real. A veces es un poco más bajo, a veces un poco más alto, pero por término medio se ajusta bastante bien.

Esto no fue suficiente para algunos clientes. Estos clientes querían que la transacción de venta descrita anteriormente se registrara correctamente con un precio de coste de 15 euros en lugar de 10 euros. Por tanto, la operación de venta, que en realidad se había realizado hacía mucho tiempo, tuvo que corregirse después de la llegada de la factura de compra: estaba regulada.

Esto es exactamente lo que hace el control de existencias: comprueba las transacciones de venta para ver si el precio de coste utilizado en cada caso es correcto, y corrige el precio de coste de una transacción de venta si es necesario.
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.

Y como esto es tan complicado, no se puede trastear con Navision entre medias. Los campos Método de salida de existencias (con las opciones FiFo (First In First Out, por ejemplo, cartones de leche rellenados por detrás), Lifo (Last In First Out, por ejemplo, arena amontonada o cartones de leche rellenados por delante), Promedio (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.

¿Para qué necesita este cálculo "exacto" del precio de coste?

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 Regulación de los rodamientos – 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. De este modo, se incrementaron las existenciasy y aumentó el compromiso de capital de inventario..
Entsprach das logisch in Navision bzw. hier Business Central abgebildete Verkaufsverhalten der physikalischen Lagerbewegung? Natürlich no.! 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.

Cómo el cálculo del precio de coste de Navision puede volver a ser increíblemente sencillo

Olvídese de todo este embrollo y -por decirlo llanamente- vuelva a instalar el precio de coste del "Navison nativo", también conocido como cliente clásico. Hasta aproximadamente 2003, esto hacía que el cálculo de los precios de coste fuera tan sencillo como se ha descrito anteriormente.

( Stock antiguo * Precio de coste antiguo) + (Adquisición * Precio de coste nuevo)
===============================================
Nuevo stock

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.

Costes de adquisición de bienes, costes de adquisición auxiliares

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.
La misma función también está disponible en compras, y está diseñada para incluir costes de aprovisionamiento de mercancías, costes de transporte, etc. para artículos en compras, y para aumentar el precio de coste aquí también.
Como es típico de Microsoft, la solución es increíblemente complicada y al principio también estaba llena de errores. En las versiones de Navision / Business Central a partir de Nav 2015 aproximadamente, funciona de forma muy fiable, pero también es bueno utilizarlo en las versiones anteriores, siempre y cuando nada falle (correcciones de facturas, etc.).

¿Qué son los costes de abastecimiento de materias primas?

Principalmente los costes de transporte, por ejemplo. Pero también se incluyen los derechos de aduana, los gastos de almacenaje y los costes de almacenamiento en general. Especialidades como los recargos por cobre o los recargos por material en general son de nuevo especialidades extra. Pero los recargos de cobre en particular pueden introducirse de forma óptima con el tipo de línea "Recargo/Descuento (Artículo)" en Navision estándar, por lo que se excluyen aquí.

Registro de los costes de adquisición

En general, los costes de aprovisionamiento en la mayoría de las empresas difieren en 2 aspectos:

• Costes directos de adquisición. Pueden asignarse directamente a una factura de compra. Los gastos de envío son un clásico: cuando la mercancía llega al almacén, ya se conocen los gastos de envío exactos. Esta es la variante más sencilla, e incluso podría introducirse con un poco de esfuerzo o ajuste con el tipo de línea "Adición/Descuento (artículo)" en Navision estándar. Del mismo modo, como ya se ha mencionado anteriormente, los recargos por cobre y otros recargos por material. Sin embargo, las partidas colectivas individuales, como los gastos de envío, también pueden introducirse más fácilmente con la función de costes de aprovisionamiento aquí descrita.
• Costes descendentes de aprovisionamiento. Los transportes y los derechos de aduana son aquí los clásicos. La mercancía lleva mucho tiempo en el almacén, la factura de compra lleva mucho tiempo pagada, y luego están los gastos de transporte y aduanas. Por supuesto, éstos también deben incluirse en el precio de coste del artículo adquirido y, en el mejor de los casos, también modifican los márgenes de contribución de las facturas de los clientes que se han facturado entretanto.
  "En realidad", este es precisamente el ámbito de la regulación bursátil. Pero, de algún modo, nunca ha funcionado realmente. ¿Y si alguna vez funcionará correctamente? No lo sé. Pero en cualquier caso, la regulación de los rodamientos causa muchos problemas. Puede hacerlo y lo ha hecho desde el primer día.

Aquí es donde entra mi solución, especialmente para las versiones nativas de Navision hasta la versión 2009R2. Si necesita trabajar en esta lógica para su RTC Navision (Navision 2013 a Navision Dynamics / Microsoft Business Central 365) o su solución BC 365, póngase en contacto conmigo..

Registro de los costes accesorios directos para la adquisición de bienes (franqueo)

Si tiene proveedores que especifican costes de entrega fijos, por ejemplo 6,90 € de participación en los gastos de transporte (TKA) por pedido, puede introducirlo directamente en el proveedor:

Alternativamente, también puede introducir los costes de entrega válidos para esta transacción directamente en el pedido/factura de compra para cada factura de compra.

Importante: ¡Estos costes (MW) sólo se incluyen en el precio de coste cuando se introducen en el campo Costes (MW)! No aumentan el importe final de la factura para este pedido o para este proveedor. Se trata de un aumento puramente estadístico del precio de coste.

Tanto la distribución de los costes adicionales ficticios del campo Costes (MW) como la distribución de los importes de línea que incrementan realmente el valor del pedido/valor de la factura son realizadas automáticamente por Navision cada vez que se contabiliza un documento; es imposible "olvidar" esta distribución. Importante: Ambos tipos de costes (costes ficticios que No aumentan el valor del pedido/valor de la factura así como costes reales que aumentan el valor del pedido/valor de la factura) pueden mezclarse como se desee. También puede introducirse cualquier número de costes de entrega por documento. Todas las cuentas de mayor de un documento dan lugar a los costes de entrega, que se distribuyen entre los valores de las mercancías del mismo documento.

Esta lógica funciona para

• Pedidos de compra
• Facturas de compra
• Facturas colectivas de compra

Introducción posterior de costes de referencia, por ejemplo, transporte

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

También existe una solución para esto: Usted introduce un nuevo documento introduciendo los costes de transporte, expedición, aduanas u otros costes de aprovisionamiento ampliados. Asigne el documento original, que ahora tiene un valor superior por los costes adicionales, a este documento mediante "Añadir. Cost Document to", asigna la factura recibida original, que ahora se valorará más por los costes adicionales, a este documento.

Al contabilizar este documento, Navision extrapola el precio de coste en la entrada de mercancías original y también aumenta el precio de coste en los artículos afectados.