Usuario de Dynamics NAV 20xx – Seguimos revisando la migración/reimplementación

Sigamos con el tema de la migración de 20xx a Business Central.

Si quieres ver el articulo previo, da clic aquí

Una de las primeras tareas debe ser la revisión de código actual para evaluar cual o cuales escenarios serán factibles y de ahí, definir el mejor acorde a la estrategia de crecimiento.
Lógicamente, también se deben revisar los procesos actuales, validar cuales se mantienen desde 2013 y porque, cuales cambiaron y porque, cuales se pueden mejorar con las nuevas funcionalidades y cuales procesos nuevos se integrarán en esta reimplementación.

Spoiler Alert, en esta ocasión, me enfocaré en la parte técnica por lo que hablaré mucho de código y herramientas en lugar de procesos de negocio.

Actualmente se cuenta con cierta cantidad de tablas modificadas y/o creadas para dar soporte a la operación; así mismo tablas, codeunits, etc.
En el nuevo esquema de programación, los objetos del BaseApp se “extienden” por lo que hablamos de tablas y extensiones de tablas lo que implica incrementar el número de objetos a crear/modificar.
De inicio, debemos pensar en los escenarios posibles sobre el On-premise:

• Modificar el BaseApp – Esto permite “ahorrar” en objetos y mantener el diseño original de 20xx facilitando así la migración y puesta en marcha ya que todo esta funcionando. Esto también condena a Business Central y al cliente a “seguir atado al pasado” y continuar manejando estructuras antiguas dejando de lado la posibilidad de ir actualizando su backoffice.
• Extender – Esto implica invertir en redefinir todo a través de extensiones de objetos lo que implica que se está adhiriendo a un esquema PTE aún en On-premise. Esta arquitectura deberá cumplir con las reglas de Microsoft para funcionar tanto en On-premise como en SaaS lo que implica crear y mantener una plataforma privada estilo Azure para que, en un futuro y si es factible económicamente, migrar a la nube pública desde la nube privada.

Hay que tomar en cuenta que mi enfoque es el de extender pensando en habilitar un crecimiento futuro por lo que desde este punto descarto la primera opción.
Este segundo escenario implica analizar los cambios originales y transferirlos a extensiones pero no solo es copy&paste, se debe analizar cuales campos si y cuáles no.
Ejemplo, tabla cliente

• Se tiene un campo llamado “Partner Type” con id 50013 que es un option y coincide con el campo 132 con el mismo nombre y mismas opciones, pero tipo enum lo que es mas correcto para la aplicación.
• Se tienen los campos 50033 UsoCFDI y 50040 RegimeFiscal mismos que Microsoft agregó en una versión posterior con los campos 27000 y 27002.
• Tiene campos para dirección de entrega que yo eliminaría y utilizaría la tabla Ship-to Address.

Este análisis debe realizarse por cada tabla modificada en conjunto con el equipo de programadores del cliente para asegurarnos que hablamos el mismo lenguaje y que los cambios en las estructuras de las tablas de Business Central sean tomados en cuenta en el rediseño de el punto de venta para que la integración sea más correcta.

Ahora bien, se debe ir revisando el código que toca tanto los objetos de NAV como los objetos que no son de NAV e ir “definiendo y agrupando” las funcionalidades para irlas separando por áreas funcionales o por extensiones de manera que sea una construcción manejable y con vistas a permitir una extensión posterior.

¿A que me refiero con esto?

Los desarrollos del cliente se pueden agrupar en:

• Integración de POS que incluye temas de clientes, productos, almacenes, cobros, ventas, etc.
• Reembolsos.
• Compras.
• Facturación electrónica.
• Contabilidad electrónica.

En lugar de hacer una extensión monolítica, será mas conveniente separarla en varias extensiones de manera que cada una pueda ir creciendo acorde a sus propias necesidades y también permitir definir cuales ya no se migrarán.

La integración con el POS se divide en:

• Contratos Corporativos.
• Contratos personales, Ventas de accesorios y equipos con cobro.
• CRM.

Entonces convendría descomponer la integración en al menos esos temas que podrían ser manejados por separado.

Temas importantes son detectar las modificaciones en los objetos de la aplicación en NAV2013 y determinar como realizarlos en Business Central, recordemos que no podemos extender una codeunit así que se debe buscar el cambio, comparar contra la nueva versión de la codeunit y buscar el evento que se ajuste para poder suscribirse al mismo y obtener el resultado buscado.

En otros casos, se realizaron cambios en las acciones de las paginas mismos que deben replicarse o, cambiar a suscripciones a eventos.

Estas ultimas dos imágenes, tienen que ver con un registro automático de transferencias. esto podría ser una extensión por si misma dado que es una funcionalidad especifica, acotada y se puede encapsular.

Después de agregar campos a una tabla y pagina, terminamos con lo siguiente:

Ahora bien, falta poner la traducción a es-MX, la seguridad y probar todo antes de pasarlo a productivo.

Tenemos que realizar este tipo de trabajo por cada cambio detectado

1. Buscar los cambios.
2. Aislar el cambio y ver porque es el cambio.
3. Revisar si la funcionalidad es requerida aún.
4. Revisar si hay algo en la nueva aplicación que realice este comportamiento.
5. Si ya hay algo, validar con el usuario si es viable utilizarlo y da el mismo resultado.
6. Si no hay funcionalidad estándar, entonces revisar como se integrará al sistema la extensión determinando como y donde se realizara la suscripción al evento correspondiente y/o
7. Extender tablas, paginas, reportes, etc.
8. Agregar permisos, traducciones (las normas establecidas por Microsoft y la comunidad es programar todo en INGLES y luego agregar la traducción).
9. Probar, probar, probar y ya una vez probado, publicar la extensión.

Si lo que buscamos es darle al cliente una extensión que, inicialmente se use en on-premise y permita en un futuro ir a SaaS, debemos de respetar las normas, hay partners que no cuidan lo del lenguaje y cuando se quiere publicar en SaaS se encuentran errores o faltantes de etiquetas, seamos proactivos y veamos a futuro.