Tiempo estimado de lectura: 13 minutos

¿Por qué necesita un ajuste de rodamientos? ¿Por qué es tan lento? ¿Por qué no puede simplemente corregir el precio de coste si ha cambiado? Me he estado haciendo la misma pregunta desde que Microsoft introdujo la Regulación de los rodamientos en Navision Dynamics Attain y Microsoft Business Central BC365 y lo hizo cada vez peor. Por cierto, Navision Financials hasta la versión 4 no tenía esto, sino esencialmente la lógica que se describe a continuación. Cuando programadores sin conocimientos comerciales programan algo...

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

Claro, la primera respuesta: porque es Microsoft. Correcto. DE ACUERDO. La segunda respuesta: Porque la gente tiende a preferir añadir algo más complicado a algo complicado. Esto es lo que me ocurre en cada proyecto. Dies wurde auch schon wissenschaftlich untersucht (hier die Studie)
Pero pasemos a la respuesta objetivamente correcta, aunque ya no satisfactoria: porque unos cuantos clientes lo querían así.
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.
Esto es tan complicado como parece, y requiere muchas transacciones en la base de datos. La contabilización y liquidación lleva bastante más tiempo, y durante varias versiones de Navision sólo fue necesario invertir en hardware más potente y/o realizar esta liquidación de almacén los fines de semana, por ejemplo. La recomendación general en aquella época era: ¡Manos fuera del ajuste de existencias! Déjalo, ¡nunca lo llames! Esta situación se ha aliviado considerablemente con Navision 2018 BC14, por ejemplo, ya que el control de existencias ya no perjudica tanto al servidor.

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 (por ejemplo, la gasolina en el depósito subterráneo de la gasolinera)) y no se limitan a cambiar el precio de coste más tarde. Y cada corrección de precios requiere un gran esfuerzo para corregir el precio de coste. El método de salida de stock no puede corregirse en absoluto. Microsoft recomienda seriamente sustituir este artículo por otro que se haya configurado correctamente.

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

Desde 1993, sólo he tenido un cliente -entre más de cien clientes de proyectos- que quería exactamente este cálculo del margen de contribución. Ni siquiera sirvió de nada una larga discusión sobre el hecho de que se estaba engañando a sí mismo creyendo una precisión que no podía alcanzar. Ciertamente entendió mi ejemplo de cálculo y tuvo que darme la razón - pero siguió insistiendo en la correcta aplicación de la Regulación de los rodamientos – CON una simple corrección del precio de coste. En su versión de Navision, ambas funciones se estorbaban mutuamente y sólo podían combinarse con mucho esfuerzo. Me gusta ganar dinero - pero no con actividades sin sentido. Podríamos haber tenido la la solución necesaria mucho más fácilmente. Pero era absolutamente necesario que funcionara a través del sistema de control de existencias, y simplemente no tenía sentido implementarlo de esa manera. Entonces recibió de mí la función deseada, y una factura final al terminar el proyecto.

La justificación de esta locura por parte del cliente me pareció especialmente notable, por lo que debo reproducirla aquí. Se suponía que los comerciales y los vendedores de oficina determinaban exactamente cuánto ganaban con un pedido concreto. Sobre todo y precisamente porque estas personas podían seleccionar diferentes lotes de entrada específicamente para un proceso de venta explícito. Y al final del día, cada lote debería mostrar un margen de contribución específico por artículo, incluso después de que los precios de coste hubieran cambiado posteriormente. A priori suena inteligente y, por tanto, loable. ¿Verdad? Pero, ¿cuál es la consecuencia? Por supuesto. Naturalmente, los vendedores seleccionan los lotes que ofrecen el precio de venta más favorable y/o el mayor margen de contribución. Los demás lotes, que se compraban a un precio demasiado elevado, simplemente no se reservaban. En consecuencia, también se realizaban nuevas compras, por supuesto, si prometían costes de adquisición más favorables que los artículos aún en stock. De este modo, se incrementaron las existenciasy y aumentó el compromiso de capital de inventario..
¿Se correspondía el comportamiento de las ventas mapeado lógicamente en Navision o aquí en Business Central con el movimiento físico de las existencias? Por supuesto que no.. Los productos no se registraban y/o gestionaban en el almacén por lotes. Los productos se vendían a medida que se recogían. Al menos para la mayoría de los productos. El cálculo exacto del margen de contribución en céntimos era un bastión de complejidad, soldado con un autoengaño fijado en el proceso. Y lo peor de todo es que el cliente estaba de acuerdo conmigo. Tuvo que darme la razón después de que hiciéramos una inspección del almacén e interrogáramos al jefe de almacén sobre el tema.
Lo sencillo es bueno. Y: lo sencillo es prácticamente siempre mejor. Por eso me resultó tan fácil separarme de este cliente después de este proyecto tan especial.

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

Y es precisamente este cálculo del precio de coste el que puedo incorporar de nuevo a su Navision Financials / Dynamics Attain o Microsoft Business Central BC365 a petición. El único cambio directamente visible es un nuevo campo en la ficha del artículo: Precio de coste móvil.

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

Los recargos por artículo y los descuentos por artículo están disponibles desde aproximadamente la versión lógica de 2009. Están concebidos precisamente para incluir en el precio de coste los recargos por cobre, los recargos por materias primas y otros costes de la venta de mercancías, reduciendo así el margen de contribución de un artículo. O para aumentarlo, por ejemplo en el caso de los descuentos.
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

Especialmente en el caso de las transacciones en el extranjero (mercancías en contenedores), los costes adicionales de adquisición, como fletes y derechos de aduana, sólo se producen con retraso.

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.