Lecciones aprendidas en nuestro tercer despliegue exitoso con MSDYN365FO

Siguiendo la filosofía de la compañía, queremos compartir diferentes vivencias reales que nos han sucedido en nuestra última implantación con Microsoft Dynamics 365 Finance and Operations (en adelante MSDyn365FO) este año 2018. El motivo no es otro que prevenir, aconsejar y, en la medida que podamos, poner sobre aviso al resto de compañeros y Partners del canal, ya que nos reafirmamos en que intentar arrancar 365 como hemos estado haciendo de forma tradicional en el pasado, está muy ligado a un posible fracaso.

No es oro todo lo que reluce, ni en AXAZURE somos magos del producto (esto que vaya por delante), se ha sufrido y trabajado muy duro, pero por fin podemos decir que están funcionando otro paquete importante de usuarios Enterprise y mucho más numeroso como Activity.

Pero centrémonos en los puntos que han supuesto los mayores retos y de los que, como no puede ser de otra forma, hemos aprendido:

• LIBRETA DE DIRECCIONES GLOBAL: El punto de partida en escenarios en los que un cliente, puede ser el día de mañana proveedor, empleado, contacto… en la misma empresa o en otra del grupo, para evitar duplicidades dentro de MSDyn365FO se debe de partir siempre de su libreta de direcciones (en el módulo Común). De esta manera, creando los datos identificativos ya sea Persona Física u Organización, permitirá que desde dicha entidad se pueda crear el cliente, proveedor, contacto, empleado… sin necesidad de volver a completar sus datos. Aquí, es importante entender que el campo NIF de siempre (TAXExemptNumber) comienza a tener menor peso en la aplicación puesto que será el Id. de Registro de la propia Libreta, la que permitirá identificar la tipología de documento asociado (NIF, NIE, Pasaporte…). Esta tabla tiene sus peculiaridades a la hora de ser cargada vía data packages y es bastante sencillo cometer errores, por ejemplo, debido a la vigencia que tienen las direcciones (fecha desde y hasta), si no se utiliza un criterio lógico para indicar el propósito de la dirección y su vigencia puede resultar que generen duplicidades muy fácilmente.

• DATAPACKAGES:  De forma complementaria al punto anterior, es de vital importancia entender la forma de subir maestros en el sistema, sobre todo cuando se deben subir los mismos datos en diferentes empresas (un proveedor, por ejemplo). Hay que entender que la primera vez que subamos un registro de este tipo, este creará la libreta de direcciones, es por ello que la siguiente vez habrá que exportar su id de parte y su id de ubicación, para que no se repitan direcciones. Nuestra recomendación interna antes de aventurarse, es crear un registro a mano y exportarlo para revisar cuales son las fechas máximas y mínimas de esa entidad, en algunos casos pueden ser 01/01/1900 pero en otros como los id de registro son 02/01/1900… nunca está de más revisarlo antes de cargar una nueva entidad con fechas de validez. Aunque se pueden subir entidades como la libreta y las direcciones de forma individual, recomendamos usar las entidades finales añadiendo el id de parte (Customer v3, vendors v2, etc). Especial cuidado al cargar las tablas de contactos con el id de dirección, ya que se debe hacer referencia a una dirección “especial”.

• PARÁMETROS DE CARGA DE MAESTROS: Para aquellos ficheros en los que exista mucha información es importante editar los parámetros de carga, pudiendo incorporar caché de miles de registros con 5 o 10 tareas de ejecución en paralelo.

• WORKSPACES CON PowerBI EMBEBIDOS NO FUNCIONAN: Esta situación está corroborada por Microsoft y son conscientes de la necesidad. La situación es que si por algún motivo necesitáis incorporar Categorías de Cuentas Principales diferentes a las que Contoso propone porque el cliente lo requiere, los PowerBI financieros, como por ejemplo, «Visión General del CFO» no se cargarán con datos.

• REFRESCAR BASE DE DATOS: Leed con atención este artículo ya que deja muy claro qué es lo que se perderá al refrescar la base de datos entre entornos. Para nosotros fue crítico el cambiar cada vez los endpoints del SII para llevarlos al servicio de pruebas cuando refrescábamos PROD en UAT y los endpoints que teníamos con otros aplicativos.

• SERVIDOR DE CORREO: Al configurar una cuenta de correo de la organización del cliente es importante darle permisos para que envíe en nombre del resto de usuarios. Hay procesos por lotes que usan la cuenta del servidor (por ejemplo, los workflows) pero hay otros que usan la cuenta del usuario (ejemplo al enviar un documento) y en ese caso dará error si no está dicha configuración

• PLANTILLAS DE MAIL: Si vamos a enviar mails con los workflows comentar que el enlace “linktoweb” no funciona correctamente, por lo que es mejor reemplazarlo por el link directo a “mis actividades”, así mismo, el código html “/p” y las tablas deforman el formato, recomendamos sustituir las tablas por imágenes vinculadas y los saltos de párrafo por los de línea “/b”

• FICHEROS ADJUNTOS: Al previsualizar ciertos formatos PDF, el sistema muestra la información incorrecta, en estos casos se puede modificar la configuración para que el sistema use el visor del ordenador en vez del integrado, solucionando el problema.

• WORKFLOW ENTIDADES EXTERNAS: No se deben añadir usuarios con roles externos (ej. proveedores) en los workflows ya que estos no pueden crear tareas para otros usuarios (salvo cambios en la seguridad) y tendremos errores.

• DESPLIEGUE ABORTADO: Este quizás fue la incidencia más difícil de gestionar ya que a día de hoy no hemos tenido respuesta por parte de los ingenieros de Microsoft a pesar de haber solicitado el log. Por las noches, es el momento en el que solicitamos desplegar nuevos cambios que han sido previamente validados en UAT y en una ocasión, recibimos un mensaje vía LCS que el proceso había sido abortado (como os digo no sabemos la razón).  El impacto que esto supone en teoría, es no poder desplegar últimos cambios validados el día anterior, pero durante ese día y de forma aleatoria (tuve la gran suerte de vivirlo en el mío), teníamos usuarios que al acceder a determinados formularios (por ejemplo, la cabecera del Pedido de Venta), recibíamos errores cuyo mensaje hacía referencia a la localización de la India. «Missing SalesTable2LineField.lineUpdateDescription implementation for field TCSGroup_IN on table SalesTable.» Durante este día, os podéis imaginar la impotencia de no saber qué pasaba a determinados usuarios, no teníamos una explicación lógica y lo único que pedimos fue paciencia hasta el siguiente despliegue. Al día siguiente se solventó el problema sin aun saber lo que pudo suceder.

Como podéis identificar, esto solo es una muestra de las pequeñas/grandes peculiaridades que tiene el proceso de implantación con MSDyn365FO en un escenario 100% cloud computing. El producto es joven y necesita recorrido, necesita profesionales, necesita proyectos y multitud de escenarios e industrias para seguir puliéndose, pero de lo que estamos seguros es que estamos trabajando con el ERP líder de mercado y estamos deseando que llegue el día en el que haya una única versión para todos – ”One version for all customers”.

¡Hasta la próxima!