Option field type vs. State Management

I do not like to use the Option field type for two reasons:

  • If you want to use, or replicate, the same field in others tables, you must remember where you have the same field because if you make a change you must replicate this change to all other tables.
  • If you add a new option, you must add it to the end to avoid that all your code point to a wrong option. To avoid it, you can do two things. The first is to save all your code in text format, add the option, load the text code, fix it and compile it. The second is to use numeric values instead the text options, like IF myTable.Status = 4 THEN instead of IF myTable.Status = myTable.Status::Sent THEN

The above mentioned has given me more than one headache in situations where I had the same field in multiple tables and I have had to add one or several options, because most likely all code compiles and does not give any error, but really is not correct.

State Management. The Basis

Due to this, I have been using a homemade functionality that I have called “State Control”. The “State Control” not only allows me to prevent against the annoying effects of add a new state to the flow control but it permits to the end user to change them (as long as it has not effect in the logic). Furthermore we can add a little of workflow behaviour, how we will see later.

The “State Control” prevents against the annoying effects of add a new state to the flow control

It is very simple. We start with two tables, one table to define the flow of state, and other for to control of the “current” state of something. Let us see it with an example.

table1

We are going to use the fixed description (with the hope that it is not going to change) in the code, and we could use the free description to paint it on the page or factbox.

table2

The state control table has relation of 1:1 with any other table of the system. The state control code can be the primary key of the related table. Although could also be a code auto-generated and linked with the table to control its states.

code1

This is an example of how we can write code similar to the Option field type.

Later, if someone want to add some state to the flow it is such easy as add a register into State Flow table, like follow.

table3

And, of course, your code has remained intact.
Now, you can add the code for the new state.

code2

Furthermore, the same state flow can be reused as many times as you want.

State Management. Adding more functionality

To make the “State Control” more useful we are going to add some columns in the State Flow table.

table4

First of all, we need add some code to the table we want to control the state.

code3

table5

And, optionally, we can move to backward and forward.

code4

table6

Even we can offer to user, across a standard dialog page, for he choose one.

code5

table7

And put it to the state appropriate.

code6

table8

We can also ask the “State Control” for the states we can move, using the “States Admitted”.

code7

Also, we can have a Codeunit subscribed to State Control Management CU for to program the business logic needed.

code8

In this example, something or someone wanted to change the state of a Ticket to Solved and a business rule has prevented it and send it to Cancelled state, because the customer had overdue balance.

table9

Finally we need a Factbox to display information about the state of control. Something like this.

state-control

State Management. To finish

A lot of new things can be make over the “State Control” functionality. Here I put a few of them.

Expirations
When a register of the State Control table has no changes for more than an established period of time, established in State Flow table, a background process can automatically change its state to another state like waiting state or something like that.

Notifications
In the State Flow table we could add a check to indicate that someone (the owner, the customer, the manager, etc.) should be notified, and of course, point out where this person can be found.

By this way, when the State Control Management CU make a change of state, automatically will send a notification to whom corresponds or raise an event.

Approvals
From the previous feature, or similar to the previous feature, we could force that a third people must approve a register of the State Control table for allow the change of the state.

Log
Every time a register of the State Control changes, we could write in a State Control Log table and we could write down who and when the change of the state was realized.

Times
From the State Control Log table we could determine how long a State Control has stayed in a determinate state, or who has less things in a determinate state, for example.

Progress
A panel that shows the percentage of completion with two lists, one that shows the stages completed and other that show stages pending.

 

NOTE: This is my first post written in English. I am apology for the mistakes.

Microsoft Flow: ¿Quiere recibir un email cuando se cree un nuevo pedido en NAV?

Vamos a ver un ejemplo como utilizando Microsoft Flow, conectado a nuestro Dynamics NAV y utilizando el correo electrónico, podemos notificar a quien queramos de cosas que suceden, por ejemplo al crear un nuevo pedido.01

En primer lugar deberemos dirigirnos a Microsoft Flow y, mediante nuestra cuenta empresarial de Office 365 o nuestra cuenta personal de Outlook.com, acceder a la plataforma.

Seguidamente deberemos crear 2 conexiones, una a Dynamics NAV y otra a una plataforma de correo electrónico que nos permita enviar mensajes. En mi caso voy a usar Outlook.com, que es la misma que he utilizado para acceder a la plataforma.

Vamos con la primera de ellas. Nos dirijimos a Conexiones.02

Y acto seguido, creamos la conexión.
03

Al crear una nueva conexión deberemos buscar Microsoft Dynamics NAV entre la lista de servicios.

04

Y posteriormente indicar los parámetros de conexión al servicio de publicación oData. Si lo desea puede utilizar el Navision publicado en Navitecnia para hacer esta prueba. Si decide utilizar el suyo propio deberá reemplazar las URLs, usuarios y contraseñas aquí indicados.
05

Los datos de conexión al Navision de demo de Navitecnia son:

OData Feed URL: http://nav.navitecnia.com/UNSECURE/OData/
Username: Navitecnia
Password: Navitecnia2017
Company: Cronus España S.A.

Luego debemos crear la segunda conexión a una plataforma de envío de correo electrónico, que como he mencionado, en mi caso voy a utilizar Outlook en la que, evidentemente, deberé autentificarme con mis datos de acceso.06

Bien, y ahora ya podemos crear el flujo.
06.PNG

Elijo crear plantilla desde cero, busco desencadenadores para Dynamics NAV y escojo el desencadenador de cuando se cree un registro.08

Y luego al “estirar” del Table Name, escojo Sales Order.09.PNG

Al añadir un nuevo paso, tengo 2 opciones, añadir nueva acción o añadir nueva condición. Este último caso podría utilizarlo, por ejemplo, para ser notificado de los pedidos que vengan de la web, si tengo manera de descriminarlos.11.PNG

Y está claro que al añadir una condición voy a tener 2 resultados: verdadero o falso. Entonces puedo indicarle la acción a ejecutar en cada caso.12

Voy a indicarle qué acción ejecutar en caso de que la condición sea verdadera. Y le voy a ordenar que envie un email a través de Outlook.13

Le mandamos un email a administración para que, antes de nada, comprueba el pago.14

Y si la condición es negativa, le mandamos un email a almacén para que proceda con el envío.
15.PNG

Así es como queda finalmente mi flujo.16.PNG

Finalmente, solo nos queda probar si funciona. Para ello voy a Dynamics NAV a crear un pedido.17.PNG

Y efectivamente, al momento me llega un email notificándome de la creación del pedido.18

Como podeis observar, la cantidad de cosas a hacer es muy grande ya que en este ejemplo me he limitado a enviar un email pero se pueden hacer otras muchas acciones.

Solo añadir que personalmente me gustaría que existiera una opción de “crear registro en NAV” o “ejecutar WS en NAV” para que la interacción en el flujo fuera completa, aunque espero que en un futuro la haya.

 

¿Modifico código o hago una extensión?

Los problemas del Open Source

Con el fin de permitir la alteración del código estándar, desde siempre, Dynamics NAV ha sido open source, lo cual ha le ha otorgado una aurea de simplicidad precisamente debido a lo sencillo de alterar dicho código.

El código se alberga en la misma base de datos de Dynamics NAV sin ofuscar, con lo que el acceso a dicho código por parte de terceros, otros partners por ejemplo, ha sido siempre posible.

Éste, siempre ha sido un punto de discordia referente a la propiedad intelectual, ya que utilizar este código en beneficio propio por parte de otro distinto al creador, en España, es “causa penal”.

Como es lógico este modelo tiene ventajas e inconvenientes. La principal ventaja es la simplicidad nombrada anteriormente, además de la libertad del cliente final a la hora de sustituir a su proveedor. El principal inconveniente es el “upgrade” y cambios de versión del sistema. Recordemos que Microsoft está liberando un upgrade mensual.

Aunque Microsoft ha trabajado mucho en estos últimos tiempos en aras de favorecer la migración de código, no se ha conseguido automatizar al 100%, con lo que unos días de parada del sistema y la intervención de un técnico siempre es requerida.

Mucha parte de la “beauty of simplicity” de Dynamics NAV ha sido debido a su modelo Open Source

¿Sería Closed Source la solución?

El lenguaje de programación de Dynamics NAV, C/AL, no está orientado a objetos con lo que los programadores de Dynamics NAV no podemos ni sustituir ni complementar lo que el código estándar hace mediante la herencia de clases estándar en nuestras propias clases.

Sin embargo, C/AL está orientado a eventos, lo que significa que la mayoría de cosas que pasan durante la ejecución, desencadenan un evento, como por ejemplo: abrir o cerrar un formulario, insertar un registro en una tabla, modificar la información de un determinado campo, el registro de una factura, y así muchísimas más. Es lo que Microsoft ha denominado como Eventing.

Como programador ¿y si pudiera suscribirme a determinados eventos y asegurarme así ser llamado cuando ocurran? Esto me permitiría no tener que alterar el código estándar. Perfecto, esto son las extensiones. Es lo que se denomina decoupling, y este desacoplamiento permite que mi código sea totalmente independiente. Entonces, si es independiente ¿por qué debo hacerlo visible a los demás? Bienvenido a la discordia. Microsoft cierra el código de las extensiones, es decir, protege la propiedad intelectual del creador.

El modelo Closed Source tiene más implicaciones que las meramente técnicas, pues el creador debería depositar el código en una agencia de Escrow.

La discordia, Open vs Closed

La discordia viene porque algunos (veteranos) profesionales de Dynamics NAV estamos enamorados de esta “beauty of simplicity” que, por el hecho de ser open source, siempre ha caracterizado a Dynamics NAV, y, aunque nos encantan las extensiones, nos aterramos si pensamos que Microsoft puede algún día llegar a prohibir modificar código estándar, aunque si bien es cierto que no hay absolutamente ninguna noticia en este sentido.

Este pensamiento está fundamentado en que actualmente Dynamics 365 (Project Madeira) tiene extensiones, algunas de ellas programadas por la propia Microsoft, y es de suponer que Dynamics NAV 2017 va a seguir el mismo camino. Con esta acción, Microsoft está dejando de publicar código abierto en Dynamics NAV, que todos podíamos ver, estudiar y modificar, para pasar a liberar funcionalidades en modo de código cerrado.

¿Es Microsoft el único creador de funcionalidad que debería programar sin utilizar el modelo de extensiones?

Entonces qué, ¿modifico código o hago una extensión?

Si modifico código, va a ser rápido y simple, con lo que será barato, hasta que llegue el momento de hacer “upgrade” donde habrá un mínimo de intervención manual para poder mover dicho código. Con lo que lo de barato no va a ser cierto.

Si modifico código, va a facilitar que el cliente final pueda fácilmente cambiarse de partner, aunque esto podría entrar en conflicto con las leyes sobre protección de la propiedad intelectual.

Si hago una extensión, será algo más complejo de desarrollar, pero como anuncia la técnica del decoupling, tendré un código independiente que no altera el código estándar con lo que se está garantizando que los futuros upgrades serán 100% automáticos, sin intervención humana.

Además, como creador, estaré protegiendo mi propiedad intelectual aunque seguramente esto puede dificultar el hecho de que el cliente final pueda cambiar de partner al no tener el código fuente. Eso sí, deberé depositarlo en una agencia de Escrow.

¿Supondrá el modelo de extensiones otro cambio importante como lo fue el paso de Classic a Roles?

Mi opinión personal

Mi opinión personal es que las extensiones son fantásticas para los ISV, ya que favorecen la repetibilidad, su despliegue en multitenant y protegen la propiedad intelectual.

Son medianamente fantásticas para los VAR, ya que en ocasiones requieren lo mismo que un ISV, pero en ocasiones necesitan la “simplicity”, es decir, solucionarlo ahora, rápido y tocando código estándar que de otra manera sería imposible. Es decir, se necesita acceso al código fuente estándar para siempre. Sobre todo en los upgrades.

Son nefastas si las utiliza Microsoft, ya que desde siempre ha liberado funcionalidad en modo Open Source estándar, el cual podemos estudiar y alterar si conviene. Las extensiones, en este caso, no aportan ninguna ventaja.

Y para el cliente, depende. Si su solución se basa en un vertical especializado de un ISV seguramente le interesará el modelo de extensiones, ya que favorece la continua actualización y evolución independiente tanto de Dynamics NAV estándar como del vertical, al estar ambos “decoupled”.

Si su solución se basa en una personalización, es probable que lo que más le interese sea disponer del código fuente para asegurar la evolución de su Dynamics NAV. En este punto creo que lo más conveniente es el modelo de extensiones, por los motivos expuestos en el párrafo anterior, pero disponiendo del código fuente.

Como mantener la sincronía del código compilado que se está ejecutando con el código fuente entregado al cliente es complicado y difícil de comprobar por el cliente, éste debe ser cauteloso. Si no tiene la certeza de que este punto se va a cumplir, opte por el sistema tradicional, es decir, sin el uso de extensiones.

Grupos Contables en Dynamics NAV

Título: Grupos Contables en Dynamics NAV
URL: https://www.youtube.com/watch?v=jdXCK31yNF4
Nivel: Intermedio
Audiencia: Usuarios, Técnicos, Consultores
Categoría: Técnico, Funcional
Requisitos: Vídeo: Introducción al funcionamiento de Dynamics NAV

En este video se muestra el funcionamiento de los grupos contables del ERP Microsoft Dynamics NAV.

¿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

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.

Introducción al funcionamiento de Dynamics NAV

Título: Introducción al funcionamiento de Dynamics NAV
URL: https://www.youtube.com/watch?v=UeDTTGUeSNo
Nivel: Introductorio
Audiencia: Usuarios, Técnicos, Consultores
Categoría: Técnico, Funcional
Requisitos: Vídeo: ¿Qué es Dynamics NAV?

En este video se muestran los primeros pasos en el funcionamiento del ERP Microsoft Dynamics NAV.