¿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: "Haben die sie denn nicht alle¿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.
Otro es el control de existencias. ¿Con qué hay que lidiar siempre? Control de existencias. Precios de coste reales. Precios de compra reales. Método de salida de existencias. «El precio de coste está regulado». ¿Qué? ¿Por qué? ¿Quién regula mi precio de coste? ¿Estamos en el comunismo con precios fijados por el Estado? ¿Y qué son estas partidas de cierre? ¿Qué me dice el precio de coste (esperado) y cuál es la diferencia con el precio de coste (real) o 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 esbozo, sin duda habrá que adaptarla en algunos detalles según sus especificaciones. Pero es un enfoque bastante pragmático para todos aquellos que llevan años preguntándose si alguna vez podrán obtener un valor de stock fiable y verificable de su Navision. Ponte en contacto conmigo si tú también quieres "Lo simple es lo bueno" 🙂 .
