Comentarios sobre Microsoft Dynamics NAV (Navision)

Sessiones de formación online: SCM (Supply Chain Management)

2011-12-13T11:51:00.000+01:00

Cómo ya he comentado en anteriores posts, estoy siguiendo una serie bimensual de sesiones online de formación acerca de los costes de Microsoft Dynamics NAV.

No son las únicas sesiones online que se están realizando. Ayer descrubrí que desde Microsoft España se están realizando también sesiones de formación online, en español, sobre SCM (Supply Chain Management).

La primera sesión se realizó el pasado mes de octubre, aunque el vídeo está disponible en la web del Partner Learning Center.

En estas sesiones explican bugs detectados, explican funcionalidad, cuestiones de diseño, comentan entradas publicadas en el blog del equipo de Microsoft Dynamics NAV, etc.

En la sesión de octubre, se explicaron las siguientes entradas de blog:

Are reservations being impacted with stock adjustments?

Reservations vs. costing application: should both be consistent?

Requisition vs. Planning worksheet: why having two planning tools?

Rounding in ERP world

Puede parecer que son pequeñas cosillas, pero es importante que nos suene todo un poco para tener argumentos para responder a preguntas varias que nos plantean los clientes.

Para la siguiente sesión, que se realizará este próximo viernes, se comentarán nuevos posts del blog:

http://blogs.msdn.com/b/nav/archive/tags/scm/

Se hablará principalmente de la Hoja de Planificación de Microsoft Dynamics NAV. El que esté interesado en esta herramienta, no se puede perder la próxima sesión!

Cristina Nicolàs

Dynamica

Herramienta para la detección y corrección de errores en los costes (2009)

2011-11-21T13:15:00.000+01:00

Tal y como comenté en el post "Sesiones de formación sobre los costes de NAV", tenía que salir una herramienta para la detección y corrección de costes para Microsoft Dynamics NAV 2009.

Pues bien, esta herramienta está disponible desde el 9 de Noviembre, os lo podéis descargar de aquí (acceso a PartnerSource es requerido).
Según dijeron, además, publicarán un artículo de Knowledge Base sobre la herramienta. Dieron el número de KB, pero lo acabo de buscar y parece que aún no está disponible.

Y siguiendo con el tema de sesiones de formación, precisamente mañana hay una nueva sesión. Microsoft ha anunciado que hablará de la herramienta que aquí presento. Si a alguien le interesa, el link para registrarse es éste.

Yo asistiré a la formación. Después de escuchar lo que puedan explicar y de analizar la herramienta, publicaré un nuevo post con los comentarios que considere oportunos.

Cristina Nicolàs
Dynamica

Más datos para la empresa de demostración CRONUS

2011-10-31T11:13:00.001+01:00

Microsoft Dynamics NAV viene con una empresa de demostración llamada CRONUS España S.A.
El propósito de esta empresa es el de poderla utilizar con fines demostrativos y formativos.
Pero tiene una pequeña carencia: hay pocos datos.
Pocos clientes y proveedores, con pocos movimientos (muchos tienen la supuesta carga inicial de saldo y nada más), pocos productos con pocos movimientos, etc.

Microsoft ha anunciado hoy mismo que habrá disponible una nueva empresa CRONUS con más y mejores datos para Microsoft Dynamics NAV 2009 R2.

76 nuevos clientes y 32 direcciones de envío
Procesados 11.000 pedidos de venta y 800 pedidos de compra
88.000 movimientos de contabilidad más
32.000 movimientos de inventario más
CRONUS tiene ahora 2,4 millones de registros (hasta ahora tenía 61.210)

Esta nueva empresa de demostración está disponible desde hoy mismo en la versión internacional W1 y en las localizaciones de algunos países.

Para España estará disponible en Diciembre de 2011. Estaremos pendientes del día exacto.

Cristina Nicolàs

Dynamica

Herramienta para la detección y corrección de errores en los costes (3.xx)

2011-10-10T15:53:00.002+02:00

Tal y como comenté en un post anterior, recientemente descubrí que existe una herramienta para la detección y corrección de errores en los costes de Microsoft Dynamics NAV.

Comenté que existia una vieja herramienta, publicada en el año 2003 y destinada a las versiones 3.xx de Navision (también funciona, aunque no en todos los casos, para las versiones 4.xx). Comenté que en breve saldrá una nueva herramienta para NAV 2009 (que será válida también para NAV 5.xx).

Prometí analizar y postear sobre la vieja herramienta. Aquí lo teneis:

Para empezar, dejar muy y muy claro que la herramienta es una guía y no un manual completo. El informe de detección de errores cubre los errores típicos que se habían detectado en el momento de desarrollarla. La parte de corrección de errores explica y guía sobre cómo proceder, pero en ningún caso provee una herramienta que lo haga de forma automática.

El informe de detección de errores recorre todos los movimientos de producto y sus tablas relacionadas (movimientos de valor y liquidaciones, básicamente) para determinar si los datos son coherentes o no: comprueba que exista almenos un movimiento de valor por cada movimiento de producto, que los valores de los campos Positivo y Pendiente sean correctos (comparándolos con la cantidad y la cantidad pendiente, respectivamente), que el signo de la cantidad pendiente sea el mismo que el de la cantidad, que la cantidad pendiente no sea mayor que la cantidad, que el valor del campo "Valorado a coste medio" en todos los movimientos de valor de un mismo movimiento de producto sea el mismo y que sólo es "Sí" para los productos valorados a coste medio, etc.
Si la herramienta detecta cualquier incoherencia, nos lo mostrará para que sepamos qué incoherencias hay y podamos proceder a su corrección.

El descrito es el test básico de la herramienta. Existen otro tipos de tests:

Test de cantidad; Cantidad en movimientos de producto vs cantidad en liquidaciones.La cantidad y cantidad pendiente en un movimiento de producto se debe corresponder con las cantidades registradas en las liquidaciones.No hay liquidaciones repetidas
Test de cantidades liquidadas; el signo (positivo o negativo) de las cantidades en el movimiento y en la liquidación se corresponden, la cantidad pendiente en un movimiento de entrada se corresponde con la suma de las cantidades de las liquidaciones realizadas, un movimiento no se ha liquidado contra si mismo
Test de relaciones entre entradas y salidas para productos valorados a coste medio; principalmente cuestiones relacionadas con el campo "Valorado a coste medio"
Test de "Valorado a coste medio" y sus liquidaciones; si el movimiento se ha valorado a coste medio, que no se hayan liquidado costes
Test de la Fecha de Valoración; que la fecha de valoración de una salida no sea anterior a la fecha de valoración de la entrada contra la que ha sido liquidada

Es posible que todo esto os suene a chino. Son comprobaciones sobre el funcionamiento interno de los costes de Microsoft Dynamics NAV.
La cuestión es: si en cualquier de estos tests, se detectan incoherencias, el resultado del proceso de Valoración de Stocks es completamente impredecible. Así que... mejor arreglar todo aquello que se haya detectado incoherente o incorrecto.

El documento que acompaña la herramienta explica algunos casos (para los que ya había sus correspondientes hotfixes y por tanto ya no deberían producirse) en qué se podían producir incoherencias.
Yo añado una nueva casuística (quizá algún día haga un post con un ejemplo práctico paso a paso): cuando a alguien le da por cambiar el método de valoración de existencias de un producto. Sabeis que Navision no permite hacerlo si el producto tiene movimentos. Sabeis también que para un programador de NAV es muuuuuuuy fácil hacer que si que se permita. Lo que quizá no sabeis es que a la larga acaba generando inconsistencias en los datos (las que yo conozco almenos, detectables por esta herramienta) y lleva a resultados impredecibles (redondeos enormes, por ejemplo).

Hasta aquí perfecto. Y qué debemos hacer en caso que encontremos alguna incorrección en nuestros datos?
Pues hay dos cosas que debemos hacer: corregir el código para que el error no se vuelva a producir y corregir los datos.

Para corregir el código, deberíamos buscar hotfixes publicados por Microsoft. En principio, el bug debería estar ya solucionado y aplicando un hotfix nos debería bastar.
Para corregir los datos... la herramienta habla de ser extremadamente cautelosos, de hacer pruebas exhaustivas en un entorno de pruebas antes de implementarlo en nuestra base de datos real.
Cómo he comentado un poco más arriba, no hay ningún proceso para corregir los datos de forma automática. Esta tarea queda para nosotros, los desarrolladores de Navision. Lo que está bien de la herramienta, pero, es que explica, por ejemplo, cómo marcar movimientos de producto para que sean valorados de nuevo por el proceso de valoración de stocks. Explica también otros campos involucrados en los costes que hay que tener en cuenta.
Esto está muy bien. Lo que hubiera dado yo por tener una guía como esta cuando he tenido que corregir algo de costes, en lugar de darme de tortas con el código para descubrir lo que aquí se explica...

La documentación que acompaña la herramienta explica también paso a paso cómo se crean los movimientos de producto y de valor, cómo se liquidan, cómo se marcan para que el proceso de valoración de stocks pase por éstos movimientos, y finalmente, explica cómo funciona el proceso de valoración de stocks. Por fin! Había seguido algunas veces el código de este proceso, y la verdad es que nunca había entendido nada!

En resumen, con la herramienta de detección de errores en los costes podemos detectar si tenemos incoherencias en los costes. En caso de tenerlas y tener que hacer alguna corrección, no hay nada que lo haga de forma automática, porqué la corrección a realizar depende mucho de cada caso particular, pero tenemos una guía sobre qué tener en cuenta para que la corrección sea exitosa.
Para aquel que quiera profundizar un poco en el funcionamiento interno de los costes, bajaros y leed con atención la documentación. Os resultará útil.
Aquí va el link.

Cristina Nicolàs
Dynamica

Propiedad Editable de los campos mostrados en una página

2011-10-06T14:56:00.000+02:00

El cliente RTC de Microsoft Dynamics NAV salió hace ya unos cuantos años. Seguramente muchos técnicos de Navision enseguida se pusieron a trabajar con él y dominan ya a la perfección cómo programar páginas, cómo cambian las páginas respecto a los formularios y todo este tipo de cosas.
Por desgracia, no es mi caso. Intento estar siempre al día, pero en el caso del RTC, no lo he estado demasiado. He mirado documentación, por supuesto, pero hasta ahora aún he trabajado para clientes que estaban en versiones anteriores de Microsoft Dynamics NAV.
Ahora me pongo a programar para el RTC, que es un mundo completamente nuevo para mi, y empiezo a descubrir cómo hacerlo, los pequeños trucos, etc.
Estará desfasado, sí, pero voy a hacer unos cuantos posts explicando aquellos pequeños trucos y cosas varias que vaya encontrando.

Dicho esto, empiezo con el primer truco, el que da nombre al título de este post:
Propiedad Editable de los campos mostrados en una página

En un formulario, la propiedad Editable de un control (TextBox, CheckBox, etc.) mostrado en el formulario es un valor fijo que acepta los valores Sí y No.
La propiedad, pero, puede cambiarse en tiempo de ejecución asignando un nuevo valor a la propiedad con una sentencia como la siguiente:
CurrForm."Nombre del Control".EDITABLE(NuevoValorDeLaPropiedad);

En las páginas, este comportamiento es distinto. La propiedad Editable de los controles acepta una expresión booleana. Pero no existe una función para cambiar la propiedad en tiempo de ejecución, es decir, no se puede escribir una sentencia como la siguiente:
CurrPage."Nombre del control".EDITABLE(NuevoValorDeLaPropiedad);

Cómo podemos entonces reproducir el comportamiento de hacer un campo Editable/No Editable en tiempo de ejecución?
La herramienta de transformación de formularios a páginas hace lo siguiente:
* Declara una variable global, de tipo boolean, a la que llama NombreDelControlEditable
* Cambia la sentencia
CurrForm."Nombre del Control".EDITABLE(NuevoValorDeLaPropiedad);
por
NombreDelControlEditable := NuevoValorDeLaPropiedad;
* Asigna la variable global creada a la propiedad Editable del control

Podéis ver un ejemplo de lo comentado en la ficha del cliente (Form 21 y Página 21). En la ficha del cliente, el estándar de Microsoft Dynamics NAV hace editable el campo Contacto en función de si hay o no un Nº contacto.

Cristina Nicolàs
Dynamica

Sesiones de formación sobre los costes de NAV

2011-10-03T17:27:00.002+02:00

El pasado 27 de septiembre tuve la oportunidad de asistir a un evento organizado por Microsoft llamado "What's up in Dynamics NAV Inventory Costing". Se trata de una iniciativa de formación online, sesiones formativas a través de Live Meeting. La de la semana pasada fue la primera que trataba el área de costes de Navision. Cada 2 meses se celebrará una sesión parecida. La próxima ya tiene fecha: el 22 de noviembre. Allí estaré para escuchar lo que puedan explicar.

En la primera sesión explicaron algún bug conocido en el área de costes de Microsoft Dynamics NAV, explicaron cómo se asignan las fechas de registro cuando se ejecuta el proceso de valoración de stocks (haciendo un repaso histórico de cómo ha ido cambiando a lo largo de las diferentes versiones), también cómo se asignan las fechas de registro cuando se registran los costes en la contabilidad.
Todo muy interesante. Me ayudó a hacer un repaso de cosas que más o menos sabía, algunas que quizá tenía un poco olvidadas y sobre todo, a profundizar un poco en algunos detalles.

Pero lo más interesante, sin duda, fue descubrir que existe una herramienta llamada "Costing Error Detection Tool". No tenía ni idea que existiera una herramienta cómo esta. En cualquier caso, pero, la herramienta actual está más que desfasada (se hizo en 2003, para las versiones 3.xx). Pero, notícia importante, en unas 2 semanas debería estar disponible para descarga en la Partner Source la misma herramienta para Microsoft Dynamics NAV 2009 (servirá también para las versiones 5.xx, pues los costes no han cambiado).

La herramienta, así a grosso modo, incluye:
* Informe de detección de errores.
El informe testeará las cantidades, liquidaciones, fechas de registro, costes esperados, etc.
Debería recorrer toda la información sobre costes en una empresa y comprobar que todos los datos sean los esperados.
* Documentación
- Explicación del diseño del área de costes: las diferentes tablas involucradas, cómo se tratan las transerencias, cómo se tratan las liquidaciones fijas, etc.
- Explicación sobre la corrección de datos

Sin duda estaré pendiente cuando salga esta herramienta para analizarla y sacar mis propias conclusiones.

De momento, probaré con la herramienta actual. Para quien la quiera ver también, éste es el link para la descarga.
según dijeron, la herramienta salió para detectar errores que se habían producido en los costes (y liquidaciones de productos) al migrar de versiones anteriores a las versiones 3.xx. La herramienta es válida también para las versiones 4.xx de Navision (excepto para productos valorados a coste medio, y aún menos para productos valorados a coste medio con movimientos de transferencia).

Yo me acabo de descargar la herramienta actual. En cuanto la haya analizado os lo haré saber.

Cristina Nicolàs
Dynamica

NAVtechDays 2011

2011-10-03T01:46:00.001+02:00

El 29 y 30 de septiembre se realizó en Bélgica una conferencia organizada por mibuso dirigida a técnicos que trabajan con Microsoft Dynamics NAV: NAVtechdays 2011

Tuve la gran suerte de poder asistir a tal evento, en el que se vieron nuevos aspectos de la próxima versión de Navision, pero también cosas de versiones que ya están en el mercado.
Fue realmente interesante, la verdad. En los próximos días escribiré sobre las impresiones recogidas en el evento.

También hubo tiempo para lo social. Me gustó poder conocer a gente con la que hemos coincidido mucho en tipsdbits, a JAJ y a kitik (aunque a kitik la tengo ya más que vista), pero también a otra gente cómo los compañeros canarios. Desde aquí un saludo para todos.

Y también tiempo para el turismo. Antwerpen es una ciudad preciosa. Y aprovechando el viaje, me quedé el fin de semana en Bélgica y visité también Gent y Brugge. Todas ellas ciudades encantadoras, de verdad, os las recomiendo.

Cristina Nicolàs

Dynamica

Ley contra la morosidad: Los informes

2011-09-05T17:35:00.000+02:00

Con la funcionalidad liberada por Microsoft para adecuarse a la Ley contra la morosidad en España, venían 2 nuevos informes (hay que actualizar la licencia para poderlos usar): Cliente - pagos vencidos y Proveedor - pagos vencidos.

Tras analizarlos, mi indignación, expresada ya en el post anterior, no ha hecho más que crecer.
El informe Cliente - pagos vencidos mira las facturas de los clientes y su fecha de pago, y da un resumen estadístico del número de pagos realizados dentro y fuera del período de vencimiento de las facturas.

Parece correcto, pero, se excluyen de este informe todas aquellas facturas que han generado uno o varios efectos. La factura no se ha liquidado contra un pago sinó contra un efecto, y es el efecto el que se ha liquidado contra el pago. El informe no tiene en cuenta la factura (porque no se ha liquidado contra un pago y por tanto no se puede comparar la fecha de vencimiento contra la fecha de pago), ni tampoco el efecto (porque sólo mira facturas).

Y además, lo dicho, sólo tiene en cuenta facturas ya pagadas. Para que la estadística fuera un poco mejor podría también tener en cuenta facturas no pagadas aún, que podrían estar aún dentro del plazo o se podrían haber pasado ya...

Idem en el informe de proveedores.

Esperamos un año a que Microsoft haga cambios para adecuarse a la ley.
Y cuando por fin aparecen:
Las modificaciones que se realizan son mínimas y no tienen en cuenta algunos aspectos de la ley.
Las modificaciones no tienen en cuenta funcionalidades de la localización española de Microsoft Dynamics NAV.

Que alguien me lo cuente porqué no entiendo nada.

Cristina Nicolàs
Dynamica

Ley contra la morosidad: impresiones sobre la nueva funcionalidad

2011-09-05T14:49:00.000+02:00

Tenemos ya disponibles los objetos para adecuar Microsoft Dynamics NAV a la Ley de Morosidad. En este otro post tenéis los links para la descarga.

Hace ya unos cuantos meses, cuando anuncié que Microsoft estaba trabajando en una funcionalidad para adecuarse a esta ley (podéis leer el post aquí), explicaba que lo que no controlaba Navision era el hecho que la fecha de vencimiento debería calcularse en base a la fecha de entrega (o recepción) de los bienes o prestación de los servicios. Tampoco controlaba el hecho que en una misma factura pueden juntarse varias entregas, siempre y cuando el período entre entregas no sea superior a los 15 días, caso en el qué la fecha de vencimiento debería calcularse en base a la fecha correspondiente a la mitad del período que se factura.
Comentaba que del modo cómo trabaja Navision respecto al cálculo de las fechas de vencimiento, nos bastaba con definir nuevos términos de pago y poner (manualmente) las fechas de emisión del documento adecuadas.

Las expectativas que tenía para la funcionalidad que Microsoft ha desarrollado, eran principalmente que de algún modo se tuvieran en cuenta las fechas de registro de los albaranes, para el cálculo de la fecha de vencimiento, y también para no permitir juntar albaranes cuya diferencia entre fechas de registro fuera superior a 15 días.

Dicho esto y tras haber analizado los cambios en la funcionalidad de cálculo de fechas de vencimiento que introduce esta herramienta, he de decir que me siento completamente decepcionada y que creo que la herramienta liberada por Microsoft es deficiente. Lo que cambia respecto a lo que venía siendo el estándar de Microsoft Dynamcics NAV es tan poco, y además se podía ya obtener casi el mismo resultado mediante la correcta configuración de los términos de pago, que, sinceramente, tras tantos meses de espera desde la modificación de la ley (que es de Julio de 2010), creo que es indignante lo que han hecho. Parece que han hecho algún pequeño cambio sólo para poder decir que no han pasado olímpicamente del tema.

¿Qué cambios introduce la nueva funcionalidad?
Se introduce un nuevo campo en la configuración de los Términos de Pago, llamado "Nº máximo de días hasta la fecha de vencimiento".
El cálculo de la fecha de vencimiento se sigue haciendo en base a la Fecha de Emisión del Documento. Si el cálculo del vencimiento según el término de pago se pasa del nº de días especificado en el mismo, entonces el límite especificado en este nuevo campo es el que queda como fecha de vencimiento.
Al tener en cuenta días de pago y períodos de no pago, Microsoft Dynamics NAV siempre acababa estableciendo fechas de vencimiento posteriores a la calculada inicialmente por el término de pago. Ahora es capaz también de ir hacía atrás en el cálculo del vencimiento, para cumplir con el máximo de días establecido.
Si encuentra cualquier tipo de incongruencia de fechas, nos deja la fecha de vencimiento en blanco y es el usuario quien debe introducirla de forma manual.

Para quien usa la casuística simple de cálculo de fechas de vencimiento (cálculo basado única y exclusivamente en Términos de Pago), la nueva funcionalidad liberada por Microsoft no aporta absolutamente nada. Si antes tenía términos de pago para cálculo a 30D, 60D, 90D, etc., y ahora el máximo número de días permito son 60... no necesito nada nuevo... dejo de utilizar todos aquellos términos de pago con un cálculo superior a estos 60 días, definiendo nuevos términos de pago si lo considero oportuno... y listos!

Cuando se combinan los términos de pago con días de pago y con períodos de no pago, entonces la funcionalidad parece que sí que sirve de algo. Sabéis que utilizando los días de pago y los períodos de no pago, la fecha de vencimiento final siempre es igual o superior al término de pago. Entonces no nos basta con definir los términos de pago para adecuarse a la ley y dejar de utilizar los que establecieran períodos más grandes. La nueva funcionalidad también prevee que la fecha final pueda ser inferior a lo calculado inicialmente por el término de pago.

Por ejemplo:
Utilizo un Término de Pago llamado 30D (que calcula el vencimiento a 30 días). Establecemos que el nº máximo de días son 45.
El día de pago para el cliente es el día 15.
El período de no pago es del 01/08/2012 hasta 31/08/2012

Fecha emisión documento: 27/01/2012
Fecha vencimiento antes de la nueva herramienta: 15/03/2012 (27/01 + 30D = 26/02/2012. Lo llevamos hasta el siguiente día 15 que es el 15/03/2012)
Fecha vencimiento: 15/02/2012 (Antes se calculaba 15/03, que es posterior a los 45 días máximos, de modo que lo lleva al anterior día 15, el 15/02)

Fecha emisión documento: 27/06/2012
Fecha vencimiento antes de la nueva herramienta: 15/09/2012 (por el término de pago debería ser 15/08/2012, pero como es un período de no pago, lo lleva hasta el siguiente día 15, el 15/09/2012)
Fecha vencimiento: 15/07/2012 (Antes se calculaba 15/09/2012, que no cumple con los 45 días máximos, de modo que lo lleva al anterior día 15, el 15/07)

Algo hemos avanzado con la nueva funcionalidad, no puedo negarlo. Pero a grosso modo funciona del mismo modo en cómo ya venía funcionando Microsoft Dynamics NAV.
Faltan muchas otras cosas:
¿dónde se tiene en cuenta la fecha de entrega o recepción de los bienes? No hubiera sido tan difícil utilizar de algún modo las fechas de registro de los albaranes...
¿dónde se tiene en cuenta que no se puede juntar en una misma factura entregas realizadas con más de 15 días de diferencia?
¿hay algún control sobre los productos perecederos, de los que la ley habla específicamente para establecer condiciones diferentes?

Nada, no hay nada. Lo tiene que controlar el usuario de forma manual.

Estoy de acuerdo que hay muchas leyes y dentro de estas, mucha variabilidad, y que un ERP no tiene porque recogerlo absolutamente todo. Al final realmente todo queda bajo responsabilidad del usuario. Qué sé yo, la administración establece por ejemplo las fechas en las que hay que presentar las declaraciones de IVA, por ejemplo, y el ERP no lo tiene en cuenta para nada, puedes calcular y registrar la declaración de IVA a posteriori si quieres, que no se va a quejar ni te va a advertir ni nada. Cierto, el ERP no tiene porque recoger absolutamente todo aquello que establecen las leyes...

De todos modos, esta herramienta se ha quedado tan, pero que tan corta, que no puedo más que sentirme decepcionada e indignada.

Cristina Nicolàs
Dynamica

Ley contra la morosidad: Objetos para Microsoft Dynamics NAV

2011-09-05T10:37:00.001+02:00

Hace ya unos cuantos meses anuncié que Microsoft estaba desarrollando una funcionalidad para Microsoft Dynamics NAV que tuviera en cuenta la nueva ley contra la morosidad.

Hoy anuncio que los objetos de esta nueva funcionalidad están ya disponibles para ser descargados en la PartnerSource y también en la CustomerSource.

Aquí van los links:
Versión 5.0 SP1 Descarga en PartnerSource Descarga en CustomerSource
Versión 2009 SP1 Descarga en PartnerSource Descarga en CustomerSource

Cristina Nicolàs
Dynamica

Costes VI: Liq. por nº orden en producto valorado a Medio

2011-04-25T22:38:00.001+02:00

En un post anterior, Costes V: Liq. por nº orden explicamos cómo alterar la liquidación de los movimientos de producto. Vimos que esa alteración en la liquidación alteraba también el coste de la salida realizada (de hecho, ese era el propósito del ejemplo que hicimos). El ejemplo con el que ilustramos el post era de un producto valorado con el método de valoración de existencias FIFO. Vimos que la última salida que registramos no tomaba el coste de la entrada que le hubiera tocado según el FIFO, sino que cogió el coste de la entrada que a nosotros nos interesó.

El método FIFO asigna a una salida el coste de una entrada, igual cómo lo hace también el LIFO, el Estándar o el Especial. Usando el campo adecuado, hicimos que en vez de coger el coste de la entrada que le tocaba, cogiera el de otra entrada distinta, pero aún así, poca cosa cambia respecto al concepto que estos métodos de valoración de existencias.

Pero con el Medio... ¿qué pasa con el Medio? ¿Qué ocurriría si realizáramos los mismos ejemplos con un producto valorado a Medio? Alteramos la liquidación. Vale, muy bien. Pero en teoría no deberíamos alterar los costes, puesto que en el método de valoración de existencias Medio, el coste que se le da a una salida no es el coste específico de una de las entradas. Se le da más bien el coste medio existente a la fecha de la salida, del modo explicado en el primer post de la serie de costes: Costes I: Métodos de Valoración de Existencias.

Veamos con un ejemplo qué efecto tiene el uso del campo "Liq. por nº orden" en un producto valorado según el método de valoración de existencias Medio.

Cómo se puede ver en la imagen, se han realizado 3 entradas, una con un coste unitario de 10, la segunda con un coste unitario de 10,5 y la última con un coste unitario de 11. El coste medio actual, tal y como se puede ver en la ficha del producto es 10,42.

Entonces, una salida liquidada contra la última de las compras, ¿qué coste tomará? ¿El coste medio actual del producto? ¿O el coste de la entrada seleccionada?

Hagamos la prueba y lo veremos:

El coste ha sido el de la entrada seleccionada. Además, si nos fijamos en el nuevo coste unitario en la ficha del producto, veremos que éste se ha actualizado, de modo que la parte de la entrada que ha salido liquidada de este modo no ha sido tenida en cuenta en el cálculo del coste unitario del producto.

Este comportamiento es adecuado para el supuesto planteado en el post anterior. Hacíamos una compra de urgencia más cara de lo habitual. Sabíamos que la venta posterior tomaba el stock de esta compra de urgencia, de modo que queríamos reflejar esa situación para que el beneficio en esa venta fuera el correcto.
Y en este caso, así es, la venta toma el coste de esta última entrada, de modo que el beneficio será el correcto, y además, esta compra de urgencia no nos ha alterado el coste medio del producto. Perfecto.

Cristina Nicolàs
Dynamica

Costes V: Liq. por nº orden

2011-03-23T23:03:00.001+01:00

¿Liq. por nº orden? ehem...perdón... ¿y eso que es?

El título que he escogido no es especialmente definitorio, pero si continuais leyendo lo entendereis, porque hablo de un campo en Navision llamado así.

El post de hoy está relacionado con Costes I: Métodos de Valoración de Existencias y también con Costes IV: Liquidación de productos.

En el primer post de la serie de Costes, realizamos exactamente los mismos movimientos de producto para diferentes productos, cada uno usando un método de valoración de existencias distinto, cubriendo así todos los métodos de valoración de existencias utilizables en Microsoft Dynamics NAV.

Explicamos cómo se calculaban los costes en los movimientos de producto. Implícitamente, el cálculo de los costes nos está diciendo cómo se liquidan los movimientos de productos (de qué entrada coge el stock un movimiento de salida). Este último punto es el que se puede ver y comprobar del modo explicado en el cuarto post de la serie de costes.

Siguiendo los ejemplos proporcionados, e incluso haciendo ejemplos propios y observando el campo Cantidad Pendiente en los movimientos de producto tras cada registro, veremos que la liquidación de movimientos de producto se realiza del siguiente modo:

FIFO: Liquidación de movimientos siguiendo un método FIFO
LIFO: Liquidación de movimientos siguiendo un método LIFO
Estándar: Liquidación de movimientos siguiendo un método FIFO
Medio: Liquidación de movimientos siguiendo un método FIFO
Especial: Liquidación de movimientos siguiendo un método FIFO dentro del mismo Nº lote y Nº serie seleccionado a la salida

Quizá os preguntéis si hay algún modo de alterar la liquidación de movimientos de productos (y por ende el coste de los mismos). En algunos casos nos podría resultaría útil.

Pensemos en el siguiente supuesto: Tengo en stock un cierto producto que un cliente necesita. Cuando lo voy a entregar al cliente, me doy cuenta que tiene algunos defectos y que no puede utilizarse. Un nueva compra del producto tardaría días en llegar, pero el cliente lo necesita de forma urgente. Existe la posibilidad de obtener el producto ese mismo día comprándolo a otro proveedor, pero el precio del mismo es significativamente más elevado.

El margen de beneficio de este producto es de un 20%. Comprándolo a este otro proveedor, obtendremos un beneficio de tan sólo un 5%, pero tendremos a un cliente satisfecho, de modo que decidimos proceder de este modo.

En el momento en que se registra la venta, se encuentran en el stock las 2 unidades del producto: la defectuosa (aún no se ha tramitado la devolución o está pendiente de ser revisada o reparada) y la urgente, siendo la defectuosa la primera que entró en stock.

Imaginemos que el método de valoración de existencias de ese producto es FIFO. Si registramos la venta sin más, la venta nos cogerá el coste de la primera de las unidades, la defectuosa, de un coste inferior.

Cuando dentro de un tiempo hagamos un análisis de costes, beneficio, etc., todos los informes nos dirán que nuestro beneficio en esa venta fue del 20%.

En realidad, pero, sabemos de forma fehaciente que la venta se realizó de la segunda de las unidades del producto, de modo que el beneficio fué muy inferior.

Tras el supuesto teórico, vuelvo a lanzar la misma pregunta: es posible alterar la liquidación de movimientos de productos (y por ende el coste de los mismos)?

La respuesta es sí. Menos mal. Si llego a definir todo este supuesto para decir que no se puede y terminar el post, no hubiera tenido demasiada gracia.

La "alteración", puede hacerse en el mismo momento del registro, y puede hacerse también a posteriori.

En el post de hoy explicaremos que se puede forzar una cierta liquidación de movimientos de productos en el momento del registro usando un campo llamado "Liq. por nº orden". Otro día explicaremos cómo hacerlo a posteriori.

"Liq. por nº orden". El nombre del campo no es especialmente descriptivo, pero si miramos la ayuda de Navision dice:

"Este campo se utiliza si la cantidad que aparece en la línea del diario debería liquidarse sobre un documento ya registrado. Si es así, introduzca el número de movimiento del producto sobre el que debería liquidarse la línea del diario."

Quizá la ayuda tampoco diga mucho, pero es un comienzo.

Para empezar, diremos que este campo lo podemos encontrar en los documentos de venta y de compra, en los diarios de productos, en los diarios de fabricación, etc.

Si en una línea en cualquier de los sitios que hemos dicho, introducimos un número de producto y posteriormente desplegamos el campo "Liq. por nº orden", se nos mostrarán todos los movimientos de entrada del producto que se encuentran en stock (es decir, aquellos que tienen cantidad pendiente). De entre las entradas mostradas, debemos seleccionar aquella a la que queremos dar salida.

Vamos a verlo en un ejemplo práctico:

Tenemos un producto con un método de valoración de existencias FIFO.

De este producto hemos realizado 2 entradas de 10 y 5 unidades, a un coste de 10 y 11 por unidad respectivamente.

Además, hemos realizado una salida de 3 unidades.

La situación actual del producto es la que se muestra en la siguiente imagen

Ahora procedemos a realizar una nueva venta. Aunque la primera de la entradas aún tiene cantidades en stock (7 unidades), queremos que la venta tome el stock de la segunda de las entradas aunque por FIFO le tocaría coger el stock de la primera de ellas.

Pues bien, creamos un documento de venta, introducimos el producto y la cantidad a vender, y en el campo "Liq. por nº orden" seleccionamos la segunda de las entradas (en el ejemplo, el movimiento Nº 323).

Registramos ahora el pedido de venta, y cuando analizemos los movimientos realizados en el producto veremos que hemos conseguido lo que queríamos porque, tal y como se ve en la imagen que viene a continuación:

1. La cantidad pendiente de la primera de las entradas sigue siendo 7

2. La cantidad pendiente de la segunda de las entradas ha cambiado, siendo ahora 3

3. El coste unitario de la venta que acabamos de registrar ha sido de 11

Cristina Nicolàs

Dynamica

Modelo 347

2011-03-15T12:34:00.001+01:00

El Modelo 347 es la declaración anual de operaciones con terceras personas y debe presentarse antes del 31 de Marzo.

En el BOE de 30 de Noviembre de 2010 (http://www.boe.es/boe/dias/2010/11/30/pdfs/BOE-A-2010-18367.pdf) aparecía publicada la órden EHA/3061/2010, por la que se modificaba el modelo 347 vigente hasta el momento.

En el nuevo modelo, debe aparecer un nuevo campo en las posiciones 130 a 133 de los registros tipo 2, con el siguiente contenido:

«Ejercicio: Se consignarán las cuatro cifras del ejercicio en el que se hubieran declarado las operaciones que dan origen al cobro en metálico por importe superior a 6.000 euros.»

Microsoft ha liberado las modificaciones en la creación del modelo 347 para Microsoft Dynamics NAV 2009 SP1, para cumplir así con las nuevas especificaciones.

Éste es el enlace para la descarga del nuevo objeto.

Edito para poner también el enlace para la descarga del objeto para la NAV 5 SP1: https://mbs.microsoft.com/customersource/downloads/taxupdates/msd_nav5declaration347updates2011spain.htm

Cristina Nicolàs

Dynamica

Ley contra la morosidad

2011-02-01T19:06:00.001+01:00

El pasado 6 de Julio de 2010 aparecía publicada en el BOE una ley para luchar contra la morosidad en España.
(http://www.boe.es/boe/dias/2010/07/06/pdfs/BOE-A-2010-10708.pdf)

Esta ley modifica los plazos de pago de forma progresiva hasta 2013, según el tipo de empresa. Hasta este punto, todo bien. Para reflejar esto en Navision basta con tener definidos los Términos de Pago adecuados, que calculen la fecha de vencimiento según la nueva ley. Ningún problema.

Pero... la ley modifica también otros aspectos.

Por ejemplo, el artículo 4 de la ley establece que la fecha de vencimiento de las facturas debe calcularse en función de la fecha de recepción de las mercancías o prestación de servicios.

También establece que podrán agruparse en una misma factura varias entregas, siempre y cuando el periodo entre entregas no sea superior a 15 días. En este caso, la fecha de vencimiento deberá calcularse en base a la fecha correspondiente a la mitad del periodo que se factura.

En Navision sabemos que la fecha de vencimiento de la factura se calcula en base a la Fecha de Emisión del Documento (de la factura).

Para poder calcular correctamente el vencimiento de las facturas, pues, nos basta con definir los Términos de Pago adecuados, asignarlos a nuestros clientes y proveedores, y, en cada factura, poner la Fecha Emisión Documento adecuada.

Seguramente, pero, lo que querríamos es que Navision nos supiera poner él solito la Fecha Emisión Documento adecuada en función de las fechas de registro de los albaranes (si es que los hay), que nos controlara que no juntemos albaranes de periodos superiores a 15 días, etc.

Esto... de momento no lo hace.

Pero, y ahí va la noticia, Microsoft ha anunciado hoy mismo que desarrollará esta funcionalidad para Microsoft Dynamics NAV. Dicha funcionalidad debería estar disponible para comienzos del tercer trimestre de 2011.

El anuncio no especifica en qué consistirá la funcionalidad. Espero que lo detallen más adelante.

Cristina Nicolàs

www.dynamica.es

Integración de Microsoft Dynamics NAV con Microsoft Office Excel

2011-01-11T16:13:00.000+01:00

Cada vez es mayor la integración de Microsoft Dynamics NAV con toda la suite de Microsoft Office.

Desde versiones tempranas existe algún tipo de exportación a Excel, cómo la exportación de un Presupuesto Contable. Sin embargo, estas exportaciones eran muy pocas y muy localizadas en ciertos sitios de Navision.

Para exportaciones más generalizadas a Excel de cualquier información, hasta Microsoft Business Solutions 4.03 no nos quedaba otra que recurrir a Copiar – Pegar.
En Microsoft Dynamics NAV 5.0 se introdujo una forma más elegante de realizar exportaciones a Excel usando los botones de exportación que encontramos en la barra de herramientas.

De este modo podíamos exportar información que se encontrara en formularios, especialmente en los de tipo lista, pero seguíamos sin poder exportar de forma estándar y generalizada información obtenida a través de un informe.

Con la nueva interfaz de usuario introducida con Microsoft Dynamics 2009, el cliente RTC o cliente de roles, esto, por fin, ya es posible! No es algo nuevo, lo sé, pues dicha versión vió la luz ya a finales del año 2008, pero lo cierto es que no he tenido ocasión de trabajar en exceso con este nuevo cliente y por eso hasta el momento no hablo de ello.

Vamos al tema que nos ocupa:
Cualquier informe de Navision que se saque a través del cliente RTC tiene ahora la opción de ser guardado en Excel o en formato pdf. Una gran opción, sin duda!

Cristina Nicolàs
Dynamica

Costes IV: Liquidación de productos

2011-01-11T15:35:00.002+01:00

Os habéis fijado alguna vez en un campo llamado “Cantidad pendiente” en los movimientos de productos de Microsoft Dynamics NAV?

La ayuda de Navision dice:
Campo Cantidad pendiente
Si el movimiento es un aumento (una compra o una entrada), este campo mostrará la parte del campo Cantidad que hay en stock. Si el movimiento es una disminución (una venta o una salida), el campo mostrará la cantidad que resta por liquidar por medio de un movimiento de aumento.

Es decir, el campo cantidad pendiente muestra la cantidad de un cierto movimiento de producto que aún no ha sido liquidada (casada, matada, saldada, gastada, finiquitada) contra ningún otro movimiento.
En ocasiones nos interesará saber contra qué otros movimiento/s ha sido liquidado un cierto movimiento. En un movimiento de salida, por ejemplo, puede que nos interese saber de qué entrada ha tomado el stock para poder así entender el coste que ha tomado.
Es posible saberlo situándonos sobre un movimiento y viendo la Información relacionada de liquidación, en concreto, los Movs. conciliados.

En la imagen, buscamos contra qué movimientos ha sido liquidado un movimiento de venta de 25 unidades y vemos que 5 unidades han salido de una entrada por orden de producción de 5 unidades (documento 1011001), y que las otras 20 unidades han salido de otra entrada por orden de producción de 27 unidades en este caso (documento 1011002).

Edito para puntualizar: la pantalla Movs. Conciliados sólo mostrará información cuando se realiza liquidación de costes. Es decir, para productos cuyo método de valoración de existencias sea cualquiera de los existentes excepto la valoración a Coste Medio

Cristina Nicolàs
Dynamica

Costes III: Coste esperado vs Coste real

2010-12-28T13:35:00.001+01:00

Quizá os habeis fijado alguna vez que en Navision hay campos de coste esperado y campos de coste real. ¿Qué se entiende por coste esperado y qué se entiende por coste real?
El coste esperado de un movimiento de producto es la previsión del coste que va a tener ese movimiento antes de que el mismo haya sido facturado.

Imaginemos un movimiento de producto causado por el registro de un albarán de compra.
Ha llegado el material al almacén, con su correspondiente albarán y hemos procedido a registrar la entrada en Navision. Esto nos ha generado un movimiento de producto de tipo Compra. Si tras el registro vamos a ver el movimiento, veremos que tenemos coste en el campo "Importe coste (Esperado)" y que el "Importe coste (real)" es 0.
Esto es así porque en este momento aún no tenemos la factura de compra, que es quien nos dará el coste definitivo.
El coste esperado del movimiento se ha calculado en base al precio de compra informado en el pedido de compra.

En el momento en que registremos la factura de compra, si volvemos a fijarnos en el movimiento de producto, veremos que ahora tenemos 0 como "Importe coste (Esperado)" y el valor que corresponda (según el precio informado en la factura) como "Importe coste (Real)".

Fijaos además, que si se hace facturación parcial del pedido de compra, va disminuyendo el valor del coste esperado* (la parte correspondiente a la cantidad ya facturada) y va aumentando el valor del coste real (la parte correspondiente a la cantidad ya facturada).

Hay movimientos que no van a tener una factura asociada, como los ajustes de inventario o las transferencias entre almacenes. ¿Qué pasa con estos movimientos? ¿Se quedan con coste esperado y no van a tener nunca coste real? No no, en estos casos, aunque no haya factura, Navision los trata como facturados ya desde un inicio. De modo que es justo al revés, estos movimientos van a tener siempre coste real y nunca coste esperado.

* Esto es así a partir de Microsoft Business Solutions 4.0. En versiones anteriores, el valor del coste esperado no dismunuía, aparecía siempre el coste esperado original, aunque el movimiento estuviera ya completamente facturado.

Cristina Nicolàs
Dynamica

La introducción de fechas

2010-12-27T16:07:00.002+01:00

Navision dispone de formas bastante rápidas de introducir fechas. Y no sólo fechas, también hay formas rápidas de hacer filtros de fecha.

Hay algunas formas de introducir fechas que ya conocía, pero lo cierto es que hoy mismo, después de 4 años trabajando con Navision, he descubierto algunas formas que me han parecido curiosas y que quiero compartir con vosotros.

Imaginemos que hoy es 2 de diciembre de 2010 (02/12/2010) y que estoy utilizando como fecha de trabajo el 30 de noviembre de 2010 (30/11/2010)

Empiezo con las que ya conocía:

• h: hoy. Si escribimos h en un campo de fecha, el sistema pone la fecha de hoy

• t: trabajo. Si escribimos t en un campo de fecha, el sistema pone la fecha de trabajo

• No es necesario que escribamos el carácter de separación entre día, mes y año

• En caso de escribir el carácter de separación, podemos utilizar múltiples caracteres: barra (/), guión (-), punto (.), coma (,), dos puntos (:), punto y coma (;), de hecho, me da la sensación que podemos utilizar cualquier cosa que no sea un número

• Podemos escribir sólo el día, y Navision completará la fecha con el mes y el año de la fecha de trabajo

• Podemos escribir sólo el día y el mes, y Navision completará la fecha con el año de la fecha de trabajo

Y ahora las que no conocía y he descubierto hoy mismo:

• Para obtener las fechas de los días de la semana correspondientes a la semana de la fecha de trabajo podemos usar l (lunes), m (martes), mi (miércoles), j (jueves), v (viernes), s (sábado), d (domingo), o incluso escribir parte o todo el nombre de la semana

• Podemos crear los filtros de fecha más comunes (filtro de año y filtro de mes) de utilizando las letras a (año) y p (periodo), para poner filtro del año actual y del mes (periodo contable)* actual. Utilizando a-1, construiríamos el filtro de fechas para el año anterior, del mismo modo que p-1 crearía el filtro de fechas para el periodo contable anterior

* Para que esta opción funcione adecuadamente, los períodos contables deben existir en Navision

Cristina Nicolàs
Dynamica

Costes II: Los redondeos

2010-10-12T17:54:00.000+02:00

Los movimientos de producto llevan detrás de si movimientos de valor, que son los que dan la valoración final al movimiento de producto.

Un movimiento de producto puede tener múltiples movimientos de valor: movimientos de valor que dan un primer coste esperado, movimientos de valor que añaden costes indirectos, movimientos de valor que quitan coste esperado y dan coste real, movimientos de valor que añaden o quitan valor por desviaciones, movimientos de valor que revalorizan un movimiento de producto, y, finalmente, movimientos de redondeo.

Hoy nos fijaremos en los redondeos.

¿Porqué se producen los redondeos?

Pues, porque cuando un producto se queda a 0 de stock, su valoración final debería ser 0 también. Hay ocasiones en que esta situación no se da y los redondeos sirven precisamente para que se cumpla la regla.

En el ejemplo quedará muy claro.

Compro una CAJA de 3 unidades de un cierto producto a un coste unitario (la CAJA) de 10€.

Las unidades las vendo por separado. Cada una de las unidades sale a un coste unitario de 3,33€ (10/3=3,33)

Movimiento	Cantidad	Coste
Compra	3	10
Venta	-1	-3,33
Venta	-1	-3,33
Venta	-1	-3,33
	0	0,01

Fijaos en esto. Al final, tenemos stock 0 pero valor 0,01€. No puede ser. Algo habrá qué hacer. En este caso, Navision lo que hace es hacer un movimiento de redondeo de un importe de 0,01€ en alguno de los movimientos. Le quita un céntimo de coste al movimiento de entrada, o bien le da un céntimo de coste más a una de las tres salidas. De este modo, problema resuelto.

Cristina Nicolàs

Dynamica

Costes I: Métodos de Valoración de Existencias

2010-06-09T01:33:00.004+02:00

Navision y los costes, los costes y Navision.

Estoy segura que más de uno y más de una se ha vuelto majara intentando comprender cómo funcionan. Al menos a mi me ha pasado.

He seguido movimientos de productos y sus costes arriba y abajo en centenares de ocasiones para poder explicar porqué un determinado movimiento ha tomado un valor en particular, porqué el valor final del inventario a una fecha determinada es el que es, o porqué un ajuste positivo o una devolución de venta ha tomada un coste de lo más extraño y ha destrozado la valoración del producto en cuestión.

Todos los ejemplos que mostraré han sido realizados con Microsoft Dynamics NAV 2009 SP1.

A medida que se han ido sucediendo las versiones, ha habido mejoras en el tema de costes, de modo que es posible que algún ejemplo comentado en este post no sea reproducible en versiones anteriores.

Dado que el tema de los costes de productos da para mucho, haré entregas por fascículos.

El primer fascículo será Métodos de Valoración de Existencias.

En los próximos fascículos veremos cómo añadir coste a nuestros productos a través de los cargos de producto, el porqué de los movimientos de Redondeo o de los movimientos de Desviación, cómo revalorizar movimientos de producto, el informe de Valoración del Inventario, el proceso de valoración de stocks, Coste Esperado vs Coste Real, cómo deshacer una liquidación de costes, etc. etc.

No será en este orden, pero. Era un simple brainstorming que quiero que quede por escrito para tener ideas para otro día que quiera escribir otro post…

Métodos de Valoración de Existencias

Para cada producto de Navision, podemos seleccionar el Método de Valoración de Existencias que queremos que se realice del mismo. Si vamos a la ficha de un producto cualquiera, a la pestaña Facturación, y desplegamos el campo Valoración Existencias, veremos que existen 5 métodos de valoración: FIFO, LIFO, Especial, Medio y Estándar.

Es muy importante que seleccionemos adecuadamente el método de valoración de nuestros productos ANTES de realizar cualquier movimiento con ellos. Cuando un producto tiene ni que sea un único movimiento, ya no es posible cambiar su método de valoración. Ni siquiera puede cambiarse el método cuando dejamos el producto con stock 0. Lo que cuenta es si hay o no hay movimientos.

Vamos a explicar cómo se comporta cada uno de los métodos:

FIFO

FIFO es el acrónimo de First-In-First-Out (el primero en entrar es el primero en salir).

En este caso, el primer coste en entrar es el primer coste en salir, de modo que como valoración de nuestro inventario, siempre tendremos los costes de las últimas entradas. Vamos a verlo en un ejemplo:

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100

Tenemos un movimiento de entrada inicial de 100 unidades a un coste unitario de 1, que ha sido causado por una compra

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50

Posteriormente, hay un movimiento de salida de 50 unidades causado por una venta. Esta salida toma el mismo coste unitario que la primera entrada que encuentra a la que aún le queda cantidad en stock. En este caso, la primera y única compra.

Antes de la venta, 100 de las 100 unidades de la compra estaban en stock. Después de la venta, la compra tendrá aún 50 de las 100 unidades en el stock.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50
Compra	15-ene	100	1,6	160

Se realiza una nueva compra. En esta ocasión el producto nos ha salido algo más caro, hemos comprado a 1,6 la unidad.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50
Compra	15-ene	100	1,6	160
Venta	17-ene	-20	1	-20

Tenemos ahora una venta, una salida. Cómo hemos dicho, la salida toma el coste unitario de la primera entrada que encuentre que aún tenga cantidad en el stock.

A la primera compra, aún le quedan 50 unidades en el stock, de modo que es de este movimiento del que se toma el coste unitario.

Después de este movimiento, a la compra inicial aún le quedarán 30 unidades en el stock.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50
Compra	15-ene	100	1,6	160
Venta	17-ene	-20	1	-20
Venta	25-ene	-30	1	-30

Y otra venta. Precisamente de 30 unidades, las que nos quedaban disponibles de la primera compra. Así que, esta venta aún puede tomar el coste de esa primera compra.

Tras este movimiento, a la primera compra ya no le quedarán unidades en stock, de modo que ya no podrá propagar su coste a ninguna otra salida.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50
Compra	15-ene	100	1,6	160
Venta	17-ene	-20	1	-20
Venta	25-ene	-30	1	-30
Venta	02-feb	-10	1,6	-16

No paran las ventas. ¿Qué coste deberá tomar esta última venta de 10 unidades? Pues, como ya hemos dicho, el coste de la primera entrada que encuentre que tenga cantidades aún en el stock.

A la primera compra ya no le queda nada. Se ha vendido toda. Tendremos que buscar la siguiente entrada, que en este caso será la del 15 de enero. Por eso esta última venta toma un coste unitario de 1,6.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50
Compra	15-ene	100	1,6	160
Venta	17-ene	-20	1	-20
Venta	25-ene	-30	1	-30
Venta	02-feb	-10	1,6	-16
Compra	05-feb	50	0,896	44,8

Finalmente, realizamos una nueva compra, esta vez más barata que en ocasiones anteriores.

Al final, ¿qué Cantidad tenemos en nuestro almacén y qué importe representa?

Lo podemos calcular fácilmente como suma de la cantidad y como suma del importe de cada uno de los movimientos respectivamente.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe
Compra	01-ene	100	1	100
Venta	02-ene	-50	1	-50
Compra	15-ene	100	1,6	160
Venta	17-ene	-20	1	-20
Venta	25-ene	-30	1	-30
Venta	02-feb	-10	1,6	-16
Compra	05-feb	50	0,896	44,8
		140		188,8

Es decir, a 5 de febrero tenemos en el almacén un total de 140 unidades de este producto, por un importe de 188,8 (cosa que nos da un coste promedio de 1,34857 por unidad que se encuentra actualmente en el stock).

Y para que veáis que efectivamente Navision se comporta de este modo, aquí van los pantallazos de estos mismos movimientos realizados con Navision:

Los movimientos generados:

El stock que aparece en la ficha del producto:

El resultado de la valoración de existencias a 05/02/2011 y el coste promedio unitario

LIFO

LIFO es el acrónimo de Last-In-First-Out (el último en entrar es el primero en salir).

En este caso, el último coste en entrar es el primer coste en salir, de modo que como valoración de nuestro inventario, siempre tendremos los costes de las primeras entradas.

Realizaremos el mismo ejemplo de entradas y salidas que el utilizado en el anterior método de valoración de existencias. De este modo, podremos fácilmente comparar los resultados finales de los diferentes métodos.

Recordemos que los movimientos realizados en el ejemplo son los siguientes:

Movimiento	Fecha	Cantidad	Coste Unitario
Compra	01-ene	100	1
Venta	02-ene	-50
Compra	15-ene	100	1,6
Venta	17-ene	-20
Venta	25-ene	-30
Venta	02-feb	-10
Compra	05-feb	50	0,896

Nos falta saber el coste que toman las diferentes salidas. Lo veremos paso a paso.

Cuando se realiza la primera venta, la del 02/01, la última (y de hecho única) entrada que aún tiene cantidades en stock es la compra del día 01/01, de modo que la salida tomará el coste unitario indicado en esa entrada, que en este caso es 1. Tal y como se ve en la imagen, el importe coste de la salida es 50 (50*1), y al primer movimiento de compra le quedan aún 50 unidades en el stock.

Posteriormente realizamos una nueva compra. 100 nuevas unidades a 1,60 la unidad.
Ahora mismo tenemos una primera entrada a la que le quedan 50 unidades en stock, y una segunda entrada a la que le quedan 100 unidades en stock

Cuando se realiza la segunda venta, la del 17/01, que coste debería tomar? Siendo LIFO, pues la de la última entrada que aún tenga unidades en stock, que en este caso es la segunda compra, la del 15/01 a 1,6 de coste unitario, que por 20 unidades vendidas, dan un importe en coste de 32.

Ahora las cosas están así:
01/01 Compra de 100 unidades a 1. Cantidad pendiente 50
15/01 Compra de 100 unidades a 1. Cantidad pendiente 80

Tenemos 2 ventas más, de 30 y 10 unidades respectivamente. Ambas cogerán el coste de la última de las entradas, que cuando le restemos estas 40 unidades, aún tendrá 40 unidades pendientes.
Si miramos los movimientos de producto que ha realizado Navision, veremos que así es.

Al final de todos estos movimientos tenemos 140 unidades por un importe de 158,8 (cosa que nos da un coste promedio por unidad de 1,13429)

Medio

Este método de valoración de existencias valora los productos según su coste medio.

Este método es el único en el que una salida no toma el coste de una entrada en particular, sino que toma como coste un coste medio calculado a partir de todos los movimientos previos del producto.

Cada vez que se realiza una entrada para el producto, se calcula el coste medio, y este es el coste que se aplica a todas las salidas posteriores… hasta que una nueva entrada hace que se calcule de nuevo el coste medio.

Veamos de nuevo el mismo ejemplo que hemos utilizado para el FIFO y para el LIFO.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe	Coste medio del producto
Compra	01-ene	100	1	100	1

Primer movimiento. Se calcula el coste medio del producto. Dado que es el único movimiento, el coste de este producto es el coste medio actual del producto.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe	Coste medio del producto
Compra	01-ene	100	1	100	1
Venta	02-ene	-50	1	-50	1

Mientras no haya una nueva entrada, el coste medio no se altera y las salidas se realizan a este coste medio

Movimiento	Fecha	Cantidad	Coste Unitario	Importe	Coste medio del producto
Compra	01-ene	100	1	100	1
Venta	02-ene	-50	1	-50	1
Compra	15-ene	100	1,6	160	1,4

Una nueva entrada fuerza el recalculo del coste medio.

Ahora mismo en el inventario hay 150 unidades (suma de las cantidades hasta este movimiento 100-50+100 = 150) a un importe de 210 (suma de los importes de los movimientos hasta este 100-50+160 = 210). 210 repartidos entre 150 unidades dan un coste medio de 1,4

Movimiento	Fecha	Cantidad	Coste Unitario	Importe	Coste medio del producto
Compra	01-ene	100	1	100	1
Venta	02-ene	-50	1	-50	1
Compra	15-ene	100	1,6	160	1,4
Venta	17-ene	-20	1,4	-28	1,4
Venta	25-ene	-30	1,4	-42	1,4
Venta	02-feb	-10	1,4	-14	1,4

Al nuevo coste de 1,4 calculado es al que se van a realizar todas las salidas mientras no haya una nueva entrada que haga que se recalculo el coste medio.

Movimiento	Fecha	Cantidad	Coste Unitario	Importe	Coste medio del producto
Compra	01-ene	100	1	100	1
Venta	02-ene	-50	1	-50	1
Compra	15-ene	100	1,6	160	1,4
Venta	17-ene	-20	1,4	-28	1,4
Venta	25-ene	-30	1,4	-42	1,4
Venta	02-feb	-10	1,4	-14	1,4
Compra	05-feb	50	0,896	44,8	1,22

El nuevo coste unitario se calcula del mismo modo que antes.

Hay 140 unidades en stock (100-50+100-20-30-10+50) por un importe de 170,8 (100-50+160-28-42-14+44,8), cosa que da un nuevo coste unitario de 1,22.

En Navision, efectivamente, los movimientos se han realizado del modo que hemos detallado.

Estándar

El estándar es el método de valoración de existencias más adecuado para aquellos productos que se fabrican.

La liquidación de costes, la forma en que los costes se propagan, es exactamente la misma que en el método de valoración FIFO.

La diferencia entre FIFO y estándar es la forma en cómo se recogen los costes en los movimientos de entrada.

En todos los métodos de valoración, el coste de las entradas se recoge de la factura de compra (si la entrada ha sido provocada por una compra), de lo que el usuario haya indicado manualmente cómo coste unitario al realizar un ajuste positivo o del coste promedio actual del producto cuando se realiza una devolución de venta (si no se hace una devolución exacta de coste, esto lo veremos en algún fascículo posterior).

Cuando se utiliza una valoración Estándar, lo que cuenta es lo que indique el campo Coste Estándar de la ficha del producto.

Todas las entradas se valoran a este coste unitario.

El coste estándar de un producto valorado a estándar puede indicarse de forma manual en el campo adecuado de la ficha del producto

Existe también un proceso para realizar el cálculo del coste estándar de un producto. En el caso de los productos fabricados, Navision calcula el coste del producto en cuestión cómo suma de los costes de sus componentes (la lista de materiales de producción) y de la ruta necesaria para fabricarlo.

Dado que podemos ir modificando manualmente el coste estándar, o bien se puede ir modificando con el proceso de cálculo del coste estándar, diferentes entradas de un mismo producto pueden ir tomando diferentes costes (el indicado en la ficha del producto en el momento de realizar el movimiento).

Así pues, podemos tener diferentes entradas a diferentes costes, y después diferentes salidas, que van tomando el coste de las entradas según un método FIFO.

En próximos posts, veremos detalladamente el proceso de cálculo del coste estándar.

Especial

Este método de valoración puede utilizarse única y exclusivamente con productos a los que hagamos un seguimiento por número de serie específico. Específico significa que vamos a indicar el Nº serie en todos y cada uno de los movimientos que realicemos del producto en cuestión.

La liquidación de costes se comportará de un modo parecido al FIFO o al LIFO, en el sentido en qué para una salida, se coge el coste de una entrada en particular. En este caso, pero, no se cogerá de la primera o la última entrada que aún tenga cantidades en stock, sino que se cogerá del movimiento de entrada en qué entró el número de serie que hayamos seleccionado a la salida.

Imaginemos del ejemplo que hemos venido analizando hasta el momento, que en la primera compra han entrado los Nº serie de SER001 a SER100, y que en la segunda compra han entrado los Nº serie de SER101 a SER200.

En la primera de las ventas, sólo tenemos en stock las cantidades de la primera compra, de modo que la salida tendrá que coger números de serie del primer rango.

Pero… en la segunda y posteriores ventas, podemos seleccionar cantidades de la primera o de la segunda entrada. Incluso, de las 20 unidades de la segunda venta, podemos haber cogido parte de una de las entradas y parte de la otra de las entradas.

La segunda de las ventas puede coger costes muy distintos dependiendo de que números de serie seleccionemos. Podemos haber seleccionado 1 de la primera entrada y 19 de la segunda, 2 de la primera y 18 de la segunda, etc.

Cdad. Primera entrada	Coste unitario	Importe	Cdad. Segunda entrada	Coste Unitario2	Importe2	Importe total del movimiento
1	1	1	19	1,6	30,4	31,4
2	1	2	18	1,6	28,8	30,8
3	1	3	17	1,6	27,2	30,2
4	1	4	16	1,6	25,6	29,6
5	1	5	15	1,6	24	29
6	1	6	14	1,6	22,4	28,4
7	1	7	13	1,6	20,8	27,8
8	1	8	12	1,6	19,2	27,2
9	1	9	11	1,6	17,6	26,6
10	1	10	10	1,6	16	26
11	1	11	9	1,6	14,4	25,4
12	1	12	8	1,6	12,8	24,8
13	1	13	7	1,6	11,2	24,2
14	1	14	6	1,6	9,6	23,6
15	1	15	5	1,6	8	23
16	1	16	4	1,6	6,4	22,4
17	1	17	3	1,6	4,8	21,8
18	1	18	2	1,6	3,2	21,2
19	1	19	1	1,6	1,6	20,6

Tal y como se muestra en la tabla, el segundo movimiento de venta puede tomar cualquier importe entre 20,6 y 31,4, dependiendo de qué hayamos seleccionado para vender.

En resumen, hemos hecho los mismos movimientos en diferentes productos, cada uno valorado según un método de valoración de existencias diferente. El coste de las entradas es exactamente el mismo en todos los casos. Lo que varía dependiendo del método escogido es el coste que toman las salidas, cosa que hace que la valoración final de nuestro inventario sea diferente para cada caso, tal y como se puede ver en la siguiente imagen:

NOTA: Nótese que he obviado en esta imagen los productos valorados a Especial y a Estándar. El especial lo he obviado por la variabilidad que tiene. El estándar… porque tal y como he comentado, la valoración en las salidas es la misma que en el FIFO, de modo que el resultado final es el mismo, y porque, para qué voy a esconderme, se me ha olvidado cambiar el Coste Estándar en la ficha del producto antes de cada entrada para que las entradas cogieran el coste que me interesaba para el ejemplo, y ahora tengo muy pocas ganas de repetir los movimientos.

Cristina Nicolàs
Dynamica

Help! Ayúdame!

2010-01-15T14:39:00.003+01:00

Navision es un ERP bastante completo, con muchas funcionalidades. Tanta funcionalidad nos lleva a tener un número elevado de campos en muchas tablas. En la mayoría de ocasiones, no los rellenamos por no ser de interés para nuestra actividad, pues hacen referencia a una funcionalidad que no utilizamos. Otras veces, los podríamos utilizar y nos serían útiles, pero no lo hacemos por puro desconocimiento.
Nadie, ni siquiera los más expertos y entendidos en Navision, saben para qué sirven todos y cada uno de los campos que hay en todas y cada una de las tablas que conforman el programa. Pero esto no tiene porque ser un problema. Como en la vida misma, es mucho más importante saber dónde buscar información, que tener esa información almacenada directamente en el disco duro de nuestro cerebro.
En muchas ocasiones, el mismo nombre del campo nos da una idea de qué información contiene y de para qué puede servir. Es decir, el sentido común en Navision funciona.

Cuando en la ficha de un producto veo un campo que se llama “Cdad. en pedidos de venta”, mi sentido común me dice que debe indicar la cantidad que hay de ese producto en pedidos de venta. Y mi sentido común acierta.

Cuando en la ficha de un producto veo un campo que se llama “Valoración Existencias”, mi sentido común me dice que debe indicar el tipo de valoración que se hace de las existencias de este producto. Y mi sentido común, de nuevo, acierta. Pero después veo que hay diferentes opciones (FIFO, LIFO, Especial, Medio y Estándar, en este caso), y puede que me plantee qué significa cada una de ellas y qué diferencia hay. Si la curiosidad me corroe y quiero saberlo (el saber no ocupa lugar, dicen), puedo probar a mirar la Ayuda de Navision.

Hay que decir que a veces la ayuda de Navision realmente ayuda… y otras veces… bueno, digamos que no ayuda tanto.
En cualquier caso, primero debemos saber cómo llegar a la ayuda de Navision. Hay 3 opciones para ello.

La primera, en la barra de herramientas, le damos al interrogante, y vamos a Ayuda de Microsoft Dynamics NAV.

Esta es la ayuda general. Desde aquí podemos buscar por algún tema en concreto, buscar en un módulo en concreto o directamente leernos toda la ayuda de principio a fin.

La segunda y la tercera opción, nos llevan directamente al tema que nos preocupa en cada momento.
En toda pantalla de Navision, en la esquina inferior derecha encontraréis un botón Ayuda, que nos abrirá, dentro de la ayuda general de Navision, directamente la página de ayuda correspondiente a la pantalla en la que nos encontramos.
Si estando en la ficha de un producto, le damos al botón Ayuda, nos llevará a una página de la ayuda titulada Ventana Ficha producto.
Si hacemos lo mismo pero estando en la ficha de un proveedor, nos llevará a una página de ayuda titulada Ventana Ficha proveedor.
Y si le damos a este mismo botón pero del informe Estadísticas compras, nos llevará a una página de la ayuda titulada Informe Estadísticas compras.
Podría seguir poniendo ejemplos similares, pero me parece que ya habéis visto por donde van los tiros.

Con la tercera opción, vamos a una ayuda aún más específica. ¿Que estoy en la ficha de un producto y quiero saber qué dice la ayuda del campo Inventario? Pues muy fácil, me coloco encima del campo Inventario, le doy a la tecla F1 del teclado, y Navision me lleva a una página de la ayuda llamada Campo Inventario.
Este era fácil, yo ya sabía que el campo Inventario de la ficha del producto me dice las existencias que hay en stock de este producto. Lo que quizá no sabía, y la ayuda me lo ha dicho, es que puedo poner un filtro por almacén, por ejemplo, para que el campo Inventario me diga las existencias en stock de este producto, pero sólo en un almacén en concreto.

En ocasiones intentamos ir a una ayuda específica, de campo, de pantalla o de proceso, y Navision nos lleva a un tema más general. Cuando ocurre esto, significa que no hay una entrada en la ayuda para el tema específico que queríamos consultar.

Cómo decía anteriormente, la ayuda de Navision a veces ayuda, y a veces no ayuda en absoluto.
Por ejemplo, vamos a la ficha del producto y en la pestaña Almacén hay un campo llamado Utilizar tránsito directo. Es un campo de tipo Sí/No, de modo que la intuición nos lleva a pensar que si lo marcamos, indicamos que queremos utilizar tránsito directo, y si lo desmarcamos, indica que no queremos utilizar tránsito directo. Pero, ¿qué será esto del tránsito directo? Preguntémosle a la ayuda, nos decimos, y nos colocamos encima del campo y le damos a F1.
La ayuda nos dice: La opción de este campo indica si se permite el tránsito directo de este producto. En este momento esbozamos en nuestro rostro una pequeña sonrisa irónica y pensamos: Gracias ayuda de Navision, no sé qué haría yo sin ti!

Cierto es que esta ayuda no nos ha aportado demasiado. Nos ha dicho lo que ya sabíamos, pero no lo que no sabíamos y queríamos saber. Pero tranquilos que no está todo perdido. Probemos a ir a la ayuda general y a hacer una búsqueda por tránsito directo. Acabaremos descubriendo la utilidad de este campo.

Amigos, la conclusión del artículo de hoy es que la ayuda de Navision, igual que la ayuda y los manuales de muchos otros programas informáticos, es útil. Acostumbraos a consultarla y ganareis mucho, seguro.

Cristina Nicolàs
Dynamica