¿Crees que ganas suficiente respecto a lo que sabes?

Estos son los conocimientos que debes tener para ser el “Sheriff” del lugar.
A más skills, más sueldo.

Captura

Anuncios

Valoración y Variación de Existencias en Dynamics NAV

Un concepto desconocido, o poco comprendido, para algunos consultores y sobre todo programadores de Dynamics NAV es el tratamiento de los costes de inventario y su implicación en los balances y sobre todo la repercusión en el pago de impuestos, con lo que no es un concepto trivial sino todo lo contrario.

Para comprender su funcionamiento propongo un sencillo tutorial que desarrollaremos íntegramente en Dynamics NAV.

Vamos a crear dos productos. Al primero le llamaremos FIFO y, por supuesto, su método de valoración de existencias será FIFO. Al segundo le llamaremos MEDIO y por lo tanto su método de valoración de existencias será MEDIO.

Dynamics NAV (Navision) permite configurar cada producto con un sistema de valoración diferente.

Compra
Ahora vamos a crear una factura de compra en la que las líneas de la factura contendrán 2 líneas para el producto FIFO y 2 para el producto MEDIO. Lo que hacemos en una sola factura es una simulación de lo que ocurriría en la realidad con 4 facturas en distintos momentos, pero el efecto va a ser el mismo.

(NOTA: Se ha omitido la explicación de la parte de los “Costes Esperados” para simplificar la exposición)

Prod. Cant. Precio % Dto. Importe
FIFO 3 10€ 0 30€
FIFO 5 15€ 0 75€
MEDIO 3 10€ 0 30€
MEDIO 5 15€ 0 75€

Si ahora volvemos a la ficha de los productos, habiendo pasado antes el proceso “Valorar stock: movimientos de producto”, nos encontraremos que ambos muestran exactamente la misma información:

Prod. Invent. Coste Un.
FIFO 8 13,125€
MEDIO 8 13,125€

Es decir, el coste unitario es la suma del importe dividido por la suma de la cantidad,
105€ / 8 = 13,125€ y, como se puede observar, el método de valoración de existencias no afecta a las entradas, sólo a las salidas, como se verá más adelante.

Balances

La factura de compra ya está registrada, y ha imputado 210€ a la cuenta 600 de compras. En estos momentos tenemos una pérdida de 210€ pero esto no es del todo cierto ya que los productos están en almacén, o sea, se ha incrementado el activo y cuando se compra para el activo no se considera gasto, al menos de momento.

Para reflejar la situación correcta en los balances deberemos ejecutar el proceso “Registrar variación de inventario en contabilidad”. En nuestro caso lo ejecutaremos para los productos FIFO y MEDIO.

(NOTA: Siempre, antes de ejecutar el proceso “Registrar variación de inventario en contabilidad”, hay que ejecutar el proceso “Valorar stock: movimientos de producto”)

(NOTA: Hay un fallo en la CRONUS y se debe corregir la cuenta “Cuenta aplic. coste directo” de la configuración de combinación para el grupo contable producto / negocio respectivo. Debe ponerse la cuenta 6100001)

Para comprobar los asientos escribimos “registro contab” en el cuadro de búsqueda y seleccionamos la segunda opción. Al abrirse la ventana deberemos situarnos al final (CTRL + FIN). Aquí encontraremos dos asientos cuyo código de origen es COMPRAS para el primero y AJUEXIS para el segundo, pertenecientes a la compra y al asiento de variación de existencias respectivamente. Podemos analizarlos si se desea.

¿Cómo se han trasladado estos 2 asientos a los balances?

Cuenta de Resultados  
Ventas 0€
Compras -210€
Variación Existencias 210€
Resultado 0€

(NOTA: En realidad la cuenta 6100001 actuará como menos compra, pero aquí se separa para facilitar la comprensión)

Balance de Situación  
Activo 210€
Existencias 210€
Patrimonio 0€
Resultado 0€
Pasivo 210€
Proveedores 210€

(NOTA: Se ha omitido el tratamiento del IVA, así como algunas otras consideraciones, para facilitar la comprensión)

Para analizar qué repercusión tiene el método de valoración de existencias de los productos vamos a realizar 2 ventas separadamente, la primera para el producto FIFO y la segunda para el producto MEDIO.

Venta (MEDIO)

Vamos a realizar una venta de 4 unidades del producto MEDIO a un precio de 30€ unidad. Vamos a la ficha de los productos, habiendo pasado antes el proceso “Valorar stock: movimientos de producto”, y nos encontraremos con la siguiente información:

Prod. Invent. Coste Un.
FIFO 8 13,125€
MEDIO 4 13,125€

Es decir, el coste unitario del producto MEDIO no ha variado. Lógico, ya que las salidas se están valorando a coste medio y por tanto no tiene repercusión en el coste unitario actual a no ser que hubiera nuevas entradas a un coste distinto.

Balances (MEDIO)

La factura de venta ya está registrada, y ha imputado 120€ a la cuenta 700 de ventas. En estos momentos tenemos un beneficio de 120€ pero esto, como podemos suponer, no es cierto, hay que imputar la parte de los costes que antes hemos imputado al inventario.

Este sistema provoca que los costes se imputan en el momento en que se producen (en la venta) y no antes (en la compra). Forma parte del principio de devengo, el cual establece el criterio de imputación temporal de ingresos y gastos en función de la corriente real de bienes y servicios.

Para reflejar la situación correcta en los balances deberemos ejecutar el proceso “Registrar variación de inventario en contabilidad”.

¿Cómo se han trasladado estos 2 asientos a los balances?

Cuenta de Resultados  
Ventas 120€
Compras -210€
Variación Existencias (compra) 210€
Variación Existencias (venta MEDIO) -52,5€
Resultado (beneficio) 67,5€
Balance de Situación  
Activo 277,5€
Existencias 157,5€
Clientes 120€
Patrimonio 67,5€
Resultado (venta MEDIO) (120€ – 52,5€) 67,5€
 Pasivo 210€
Proveedores 210€

Como puede observarse hemos vendido 4 productos MEDIO por 120€ cuyo coste es de 52,5€ con lo que el beneficio obtenido ha sido de 120€ – 52,5€ = 67,5€

Y aquí se produce una de las preguntas interesantes: ¿Por qué el coste de los productos vendidos ha sido de 52,5€? En este caso es fácil porque al tener el método de valoración a Medio, en la salida así han sido valorados: 4 x 13,125€ = 52,5€

Veremos a continuación la diferencia con otros sistemas de valoración.

Venta (FIFO)

Vamos a realizar una venta de 4 unidades del producto FIFO a un precio de 30€ unidad. Vamos a la ficha de los productos, habiendo pasado antes el proceso “Valorar stock: movimientos de producto”, y nos encontraremos con la siguiente información:

Prod. Invent. Coste Un.
FIFO 4 15€
MEDIO 4 13,125€

Es decir, el coste unitario del producto FIFO ha variado. Como las salidas se están valorando a FIFO y ya han salido los 3 que valían 10€, sólo quedan en almacén los que costaron 15€.

Balances (FIFO)

Para reflejar la situación correcta en los balances deberemos ejecutar el proceso “Registrar variación de inventario en contabilidad”.

¿Cómo se han trasladado estos 2 asientos a los balances?

Cuenta de Resultados  
Ventas 240€
Compras -210€
Variación Existencias (compra) 210€
Variación Existencias (venta MEDIO) -52,5€
Variación Existencias (venta FIFO) -45€
Resultado (beneficio) 142,5€
Balance de Situación  
Activo 352,5€
Existencias 112,5€
Clientes 240€
Patrimonio 142,5€
Resultado (venta MEDIO) (120€ – 52,5€) 67,5€
Resultado (venta FIFO) (120€ – 45€) 75€
Pasivo 210€
Proveedores 210€

Como puede observarse hemos vendido 4 productos FIFO por 120€ cuyo coste es de 45€ con lo que el beneficio obtenido ha sido de 120€ – 45€ = 75€

Y aquí se produce la segunda de las preguntas interesantes: ¿Por qué en este caso el coste de los productos vendidos ha sido de 45€? Porque a diferencia del producto MEDIO en que todos los productos que salen son valorados por igual, en el producto FIFO se han valorado los productos uno a uno.

MEDIO

Cantidad Precio Coste
Entrada 3 10€ 30€
Entrada 5 15€ 75€
Salida -4 13,125€ -52,5€

FIFO

Cantidad Precio Coste
Entrada 3 10€ 30€
Entrada 5 15€ 75€
Salida -3 10€ -30€
Salida -1 15€ -15€

Conclusión

Hemos visto dos aspectos financieros muy interesantes.

El primero es el principio de devengo, en el que los costes hay que registrarlos cuando se producen y no antes, en nuestro caso cuando se produce la venta o el consumo. En Dynamics NAV, al ejecutar el proceso “Registrar variación de inventario en contabilidad” no nos pide una fecha de registro, ya que utilizará la fecha de los movimientos de valor de cada producto.

El segundo aspecto es la valoración de las salidas. Como los costes de inventario se imputan en el momento de la venta, y son calculados de diferentes formas según lo indicado en la ficha del producto, la cuenta de resultados arrojará un resultado u otro según el método utilizado.

Dynamics NAV (Navision) asegura el principio de devengo al calcular y registrar los costes de la venta en el momento en que ésta se produce.

Medir el muro construido (avance del proyecto)

En los proyectos informáticos es indispensable medir los metros de muro construidos, como decía un colega. Pero es obvio que al no poder medir algo físico, la subjetividad será el valor predominante: Para el programador está 90% acabado pero para el cliente apenas supera el 60%.

Desde mi punto de vista, el grado de avance es uno de los valores más importantes en la gestión de proyectos, ya que de él se deriva el KPI Desvío previsto. Su valor determina si vamos a ser capaces de terminar dentro del presupuesto y se mide calculando el diferencial entre el avance y el ejecutado en un momento dado.

% Desvío previsto = % Avance – % Ejecución

Por ejemplo, siguiendo con el enunciado del primer párrafo, y tomando como correcto el criterio sobre el grado de avance el del cliente, en un proyecto de 100 horas presupuestadas, hay 90 ejecutadas y un grado de avance del 60%. El presupuesto restante es de 10 horas pero quedan 40 por hacer, lo que significa un déficit previsto de 30 horas, un -30% de desvío previsto según la fórmula propuesta, 60% – 90%.

Por lo tanto, es importante certificar el grado de avance bastante a menudo porque en un momento determinado el % de desvío previsto se puede poner en negativo y cuando antes se detecte, antes se podrá gestionar.

KPIdesvioprevisto

En el ejemplo, en la semana 7 se lleva un 55% ejecutado pero con un grado de avance certificado del 50%, con lo que el % de desvío previsto ha empezado a ser negativo. Alarma importante para los responsables del proyecto que deberán empezar a gestionar las correcciones a aplicar.

¿Cómo certificar el grado de avance en proyectos informáticos?

La medición de “los metros de muro construidos” sólo es posible comparando los requisitos previamente aceptados con los realmente construidos, con lo que, cuanto menos conceptuales y más detallados sean, mejor se podrá realizar la comparación confrontándolos uno a uno. En la toma de requisitos hay que bajar a un nivel de detalle suficiente que permita inventariar, chequear y validar cada requisito construido y posteriormente aceptado por el cliente.

Por ejemplo, si el requisito es -construir un proceso que asistirá al usuario para que a partir de los datos registrados pueda liquidarlos entre sí- se debe construir una lista a partir de las respuestas a las siguientes preguntas de ejemplo:

  • ¿Deben aplicarse filtros a los datos al abrir la pantalla? ¿Cuáles?
  • ¿Se permite que el usuario deje liquidaciones sin terminar?
  • Y en ese caso, ¿las puede recuperar un usuario distinto?
  • ¿Qué criterios se han de cumplir para que una liquidación se pueda realizar?
  • ¿Es necesario que las liquidaciones pasen a un histórico?
  • ¿La pantalla debe mostrar registros ya liquidados?
  • ¿La pantalla debe mostrar registros en proceso de liquidación de otros usuarios?
  • Y en ese caso, ¿hay que establecer estados o códigos de colores?
  • ¿Una liquidación se puede deshacer?
  • Y en ese caso, ¿debe cumplir algún criterio para que se pueda?
  • Y en ese caso, ¿se borra del histórico o se añade una marca?
  • ¿Qué pasa con los registros no liquidados? ¿Tienen caducidad?
  • Y en ese caso, ¿qué se debe hacer con ellos?

En los proyectos informáticos en ocasiones ocurre que se lleva un 20% ejecutado y un avance del 80% pero para terminar se deba invertir más del 80%. Es la famosa norma de que el 20% final del proyecto nos va a tomar más del 80% del tiempo.

La cuestión principal es determinar el grade de avance lo más ajustado posible a la realidad. Medir lo construido, como si fuera un muro.

Creo que esta situación se produce por la falta de una lista de requisitos más o menos exhaustiva, ya que es en el 20% final cuando la persona que verifica y valida echa en falta esos pequeños detalles que hace que el desarrollo sea plenamente funcional y debido a ello se produzca la diferencia de criterios, pues para el programador el desarrollo hace lo que se pidió (liquidar entre sí datos registrados) pero para el cliente no es funcional (no hay históricos, no se pueden deshacer en caso de error, etc.).