05 septiembre 2011

Ley contra la morosidad: Los informes


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).





Accede al curso de Dynamics NAV


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


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.




Accede al curso de Dynamics NAV


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

Ley contra la morosidad: Objetos para Microsoft Dynamics NAV

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




Accede al curso de Dynamics NAV

25 abril 2011

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



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.




Accede al curso de Dynamics NAV



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

23 marzo 2011

Costes V: Liq. por nº orden

¿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.



Accede al curso de Dynamics NAV


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

15 marzo 2011

Modelo 347

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.»



Accede al curso de Dynamics NAV



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

01 febrero 2011

Ley contra la morosidad

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.



Accede al curso de Dynamics NAV



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