Cálculo sencillo del valor de almacén en Navision / Business Central

¿Qué tengo que configurar para obtener un valor de stock correcto?
¿Por qué Navision no puede determinar un valor de almacén correcto?
¿Cómo puedo determinar un nivel de existencias/valor de existencias correcto?
¿Cómo determina Navision o Business Central el precio de coste?

Si ya ha navegado un poco por mis páginas aquí, lo adivinará: me encanta (y vivo) Navision. Y así, poco a poco, Business Central también. Pero aún así, hay algunas cosas en Navision / Business Central que hacen que te preguntes: "¿están locos?¿O estoy loco yo? El hecho de que Microsoft (o más bien el fabricante original de Navision) no haya suministrado ningún derecho de acceso configurado o preparado de forma sensata desde 1993 es uno de esos puntos que realmente me hacen rascarme la cabeza.

Otra es la regulación de los rodamientos. ¿Con qué hay que lidiar? Regulación de stock. Precios de coste reales. Precios de compra reales. Método de liquidación de existencias. "Precio de coste regulado". ¿Qué? ¿Por qué? ¿Quién regula aquí mi precio de coste? ¿Estamos en el comunismo con precios por defecto regulados por el Estado? ¿Y qué son estas partidas de cierre? ¿Qué me dice el precio de coste (previsto) y cuál es la diferencia entre el precio de coste (real) y el precio de coste (efectivo)?

Eche un vistazo también a este artículo, puede que responda a alguna de sus preguntas...?

Historia

"Todo era mejor en el pasado"... No, claro que no. Especialmente con los sistemas de gestión de mercancías y la contabilidad financiera, los programas / sistemas nunca fueron más fáciles de usar que hoy en día. Pero para tratar racionalmente los recursos informáticos de la época, algunas cosas eran más sencillas y funcionales que hoy. Por ejemplo, en el pasado, el precio de coste medio (precio de coste móvil) se calculaba de forma bastante sencilla:

Esta sencilla solución tenía mucha elegancia. Por ejemplo, corregir una factura de compra incorrecta (por ejemplo, con una unidad incorrecta) era un juego de niños: Llamar al maestro de artículos, corregir el precio medio de coste, y todo volvía a estar bien.

En consecuencia, el valor de las existencias también se determinaba de forma sencilla: Existencias por artículo x precio de coste por artículo, se sumaba todo y ese era el valor de las existencias.

Contexto

Este método super sencillo del pasado tenía 2 desventajas desde el punto de vista de Microsoft:
a) El precio de coste variable seguía lasfacturasde compra, no lasentregasde compra. En el caso de las adiciones por producción, el precio de coste variable podía ajustarse aún más lentamente a la evolución de los precios. Por lo general, esto no suponía un problema, ya que, promediado a lo largo de los meses o del año, el precio de coste variable seguía ajustándose. Si subía (o bajaba) demasiado despacio, se retrasaba su caída (o subida). Así que era más o menos correcto para el año.

Era mucho más importante incluir correctamente los costes accesorios en el precio de coste. Ya he ideado una solución para ello, que se publicará aquí próximamente.

b) Apenas había forma viable de determinar un precio de coste móvil para el pasado, por ejemplo, a 31.12.2020. Navision y Business Central nunca han tenido problemas para determinar las existencias en cualquier momento. ¿Pero un precio de coste medio en cualquier fecha? Lamentablemente, esto no era posible con esta solución ingeniosamente sencilla.

¿Simplemente almacenar el antiguo precio de coste Ø en la partida de mercancías para cada entrada de mercancías? No. Cualquiera podría entender eso, cualquiera podría calcularlo y entenderlo. Eso es demasiado fácil para Microsoft.

c) Si lo complicas mucho, ¡incluyamos también una 3ª "solución"! Problema: Un producto se entrega el 1.2. Hasta ese momento tenía un precio de coste móvil (medio) de 5 euros. El 2.2. se vende (se entrega y se factura) a 8 euros. Por tanto, el margen de contribución es de 3 euros. El 3.2. llega la factura de compra: 7 euros. El precio de coste variable en el maestro de artículos se ajusta en consecuencia. La factura de venta que ya se ha contabilizado, sin embargo, sigue almacenando el precio de coste original de 5 euros, aunque la cobertura, el margen de contribución, ya se ha reducido.

Como ya se ha dicho, esto no importa a largo plazo, ya que "se compensa".

Solución Microsoft

Microsoft introdujo la regulación de existencias, que en realidad resolvía los problemas mencionados... al menos en teoría. En la práctica, por desgracia, este enfoque causó y sigue causando más problemas que soluciones. Si lees este artículo aquí, sabrás a qué me refiero.

Solución Thöne

¡Back to the roots! Por lo tanto, al menos para la evaluación del stock he creado un informe muy sencillo (!), que simplemente vuelve a calcular como antes... en principio.

¿Qué hace aquí Navision o Business Central? En primer lugar, determina las existencias en la fecha clave (aquí: 14.7.21).
Dependiendo de la configuración, se toma el precio de compra válido en esta fecha clave (de los precios de compra). O el precio de coste medio de las 3 últimas compras anteriores a esta fecha clave.

"Por supuesto", luego puedes ordenar la lista como quieras, por ejemplo, por el valor más alto de las existencias, por orden alfabético, por tipo de artículo o por lo que sea. Si tenemos que luchar con RDLC, entonces queremos sacar algo de ello.

Esta solución debe entenderse como un framework, ciertamente algo tiene que ser adaptado en detalle según sus especificaciones. Pero se trata de un enfoque pragmático para todos aquellos que llevan años preguntándose si algún día obtendrán un valor de existencias fiable y verificable de su Navision. Ponte en contacto conmigo si tú también quieres "Lo simple es lo bueno" 🙂 .