web
You’re offline. This is a read only version of the page.
close
Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :

¿Porque migrar a Business Central desde NAV 4, 5 o 2009?

Francisco Bedolla Profile Picture Francisco Bedolla 1,123

Bueno, si la empresa tiene aun funcionando un NAV 4, 5 o 2009 es porque la aplicación sigue cubriendo las necesidades de la empresa además de que debe estar personalizada contando con desarrollos específicos y necesarios. Sin embargo, existen varias razones para actualizarse a la versión más reciente.

¿Cuál sería una buena razón para migrar de versión?

Empecemos por la aplicación y su funcionalidad

  • Nuevo modelo de dimensiones – Permitiendo así un control mas granular de las mismas además de reducir el tiempo de registro de las operaciones lo que implica menos bloqueos de tablas.
  • Tesorería – Se agrega un nuevo modelo de conciliaciones bancarias además del SEPA (que no funciona para México debido a la falta de soporte a estándares bancarios)
  • Contabilidad de costos – Las empresas centradas en la producción en particular no pueden sobrevivir sin una contabilidad de costos confiable porque solo conociendo los costos exactos de fabricación puede estar seguro de que está vendiendo sus productos al precio correcto, esto incluye:
    • Contabilidad de centros de coste
    • Plan de elemento de costo
    • Parámetros contables
    • Gestión del valor de referencia
    • Asignaciones
    • Costos planeados
    • Vistas de análisis
    • Contabilidad de unidades de costo
    • Contabilidad de gastos generales
    • Flujo de caja – Se utiliza el pronóstico de flujo de efectivo para generar predicciones del flujo de caja de una empresa. El flujo de caja de una empresa indica su situación financiera su solvencia y revela si la empresa puede cumplir con sus obligaciones financieras en una manera oportuna. Además, el flujo de caja es un término general para el estado de los activos monetarios de una Empresa, como saldos de efectivo, fondos de la demanda, cheques o fondos de giro. Sin embargo, otros activos de la compañía también contribuyen al flujo de caja, como valores y cuentas por cobrar Estos activos contribuyen al flujo de caja en diferentes ratios de caja
    • Ensambles – Sustituye el kitting de las versiones anteriores, para respaldar a las empresas que suministran productos a sus clientes mediante la combinación de componentes en procesos simples sin la necesidad de una funcionalidad de fabricación, incluye características para ensamblar elementos que se integran con características existentes, como ventas, planificación, reservas y almacenamiento.
    • Flujos de trabajo – Puede crear flujos de trabajo que conecten las tareas del proceso empresarial realizadas por diferentes usuarios. Las tareas del sistema, como la publicación automática, se pueden incluir como pasos en los flujos de trabajo, precedidas o seguidas por las tareas del usuario. Solicitar y otorgar aprobación para crear nuevos registros son pasos típicos del flujo de trabajo.
    • NAV universal App – En las versiones antiguas la conexión remota requiere Terminal Server, Citrix o software por el estilo, a partir de las versiones modernas, se utiliza el cliente de universal App para poder acceder al sistema, con Business Central, la manera mas simple es un navegador web.
    • Aprobaciones basadas en flujos de trabajo – El cambio es que anteriormente solo se podía “aprobar” en base a usuario y limite definido, con los flujos de trabajo, esta funcionalidad crece en cobertura y facilidad.
    • Programador de Tareas
    • Tareas
    • Empleados

Ahora bien, veamos las funcionalidades más técnicas

  • Integración con Sharepoint
  • Rapid Start Services
  • PowerBI
  • Integración con CRM
  • Mejor integración con Office
  • Flow
  • Cortana
  • Power Apps
  • Social Listening

Y las totalmente técnicas

  • Arquitectura de 3 capas – Servidor de Base de datos, Servidor de aplicación y cliente
  • Webservices
  • Powershell
  • Interoperabilidad NET
  • Multitenant
  • Múltiples instancias
  • API´s
  • Extensiones
  • SQL Azure

Respecto a las funcionalidades desarrolladas para adecuar NAV a las necesidades de la empresa, la recomendación es que dichos desarrollos sean analizados y valorados en conjunto con el partner a fin de determinar si el desarrollo puede ser sustituido por una funcionalidad estándar nueva, en caso de no ser posible, el siguiente paso debe ser buscar una extensión existente ya probada en el appsource y si no es así, evaluar si realmente se requiere dicha funcionalidad.

En el caso de que sea una funcionalidad totalmente necesaria, se deberá solicitar al partner un diseño de dicha funcionalidad en extensiones versión 2, esto es, un diseño basado en eventos de Business Central con extensiones de tablas, y páginas, codeunits nuevas y que el código estándar de Business Central no sea modificado de ninguna manera.

Asimismo, se debe tomar en cuenta que el cambio de tecnología afectará algunos desarrollos previos debido a que algunas funciones no serán soportadas. En una actualización de 2009 a 2017 hubo un “gran” problema debido a que, en 2009 al abrir productos, aparecía la ficha de producto y para ver el listado se debía utilizar F5 o llamar la lista y en la versión 2018 es exactamente al revés, primero aparece la lista y luego se debe abrir la ficha. Este tipo de “necesidades” deberá ser costoso ya que el cliente no esta buscando una funcionalidad que mejore o dé un valor agregado a su proceso de negocio, sino que está buscando una forma de trabajo conocida que puede ser sustituida por el usuario después de la capacitación.

Otras “personalizaciones” implican la personalización de las formas respecto al color o gráficos que no pueden ser realizadas en Business Central; muchas veces se cambiaba el color de la forma para que el usuario reconociera su “forma” con sus permisos y su operación; ahora existen los roles.

¿Pasar datos o no pasar datos? Esa es la cuestión.

Si durante el rediseño de los desarrollos se determino que los campos de todas las tablas eran necesarios y fueron transferidos a la nueva versión mediante extensiones, siempre será posible pasar los datos mediante Rapid Start sin embargo esto aplicaría mas para catálogos que para tablas de registro. En versiones de NAV, el hecho de actualizar permitía “migrar” los datos de una versión a otra ya que simplemente era restaurar la base en la versión nueva de NAV. Ahora, con las extensiones, tenemos algunos problemas para realizar esto.

Al crear una extensión de tabla, la tabla original queda sin cambios y se agrega una nueva tabla con un nombre especial y los campos agregados, por ejemplo:

Item – Tabla de productos

Item$208abaf6-da0c-4bca-bf8c-37094d15f4eb – Tabla de extensión de Item

Item$c526b3e9-b8ca-4683-81ba-fcd5f6b1472a – Tabla de una segunda extensión de Item

En una tabla como ítem o clientes o proveedores, no hay tanto problema, pero hablando de G/L Entry, aunque se podría buscar la forma, el tiempo requerido para esto implicaría mucho trabajo.

¿Qué hacer entonces con mis datos actuales?

Una opción es utilizar una herramienta de BI para poder unir ambas bases de datos y poder analizar históricos, esto lo podemos hacer directamente con SQL o podemos utilizar Power BI para este fin. La herramienta por utilizar estará definida por el tipo de despliegue (cloud o on-premise) y/o el expertise del personal de sistemas.

Finalmente, ¿vale la pena actualizarse?

Dynamics NAV tiene una gran fortaleza, ya sea con base nativa o con SQL, la integridad de los datos es muy buena, sus procesos son robustos y bien pensados, la capacidad de adecuarse a las empresas es una de las mejores en el mercado tomando en cuenta los tiempos requeridos para desarrollar, así como la facilidad para hacerlo. El hecho de cambiar de versión en este escenario (de un NAV 4, 5 o 2009 a Business Central) implica un gran cambio de tecnología y de alcance de la aplicación para obtener mejores capacidades de análisis, operación, facilidad de uso y toma de decisiones.

Este cambio será traumático, eso no se puede negar debido al gran gap entre versiones, sin embargo, siempre será mejor hacer este tipo de actualización dentro del “mismo sistema” sabiendo como funciona y que podemos esperar del mismo como baseline, que cambiar a otro donde incluso el tiempo de despliegue puede ser mucho mas largo o tener mas problemas de integración, desarrollo o utilización.

Comments

*This post is locked for comments