Diseña un sitio como este con WordPress.com
Comenzar

Sustituyendo reports en Business Central

Una de las constantes en el desarrollo de Business Central, y sobre todo hasta la aparición de las reportextensions, ha sido y es la modificación o personalización de los reports estándar.

En muchas ocasiones lo que hacemos es duplicar el report estándar, y trabajar en el diseño o código de dicho report para ajustarlo al requerimiento.

Si se trata de formatos de documentos finalmente tendríamos que indicar en la ventana de «selección de informes» correspondiente cuál es el report que queremos que se lance desde ese momento, asociado al documento en cuestión. Pero, ¿qué ocurría si queremos sustituir un report estándar que no es configurable por una ventana de «selección de informes»?

Es bastante común que la solución pase por ocultar la acción que invoca al report estándar y añadir nuestra acción que llama a nuestro report. Incluso en el peor de los casos añadimos nuestra acción sin ocultar la acción estándar.

Pero existe una técnica para hacer que, cuando se lance la ejecución de un report del sistema, se «intercepte» esa ejecución y se lance otro report que a nosotros nos interese. Esto hace el proceso mucho más limpio y transparente para el usuario, y nos evita tener que buscar en qué puntos de la aplicación se lanza el report a sustituir.

La clave está en la codeunit «ReportManagement» y concretamente en el evento «OnAfterSubstituteReport». Si nos suscribimos a ese evento veremos que tendremos dos parámetros (ReportId y NewReportId), en el primero de ellos indicamos el identificador del report a sustituir, y en NewReportId indicamos el identificador del report que queremos que se lance realmente.

Por ejemplo, si suponemos que queremos sustituir el report «G/L – VAT Reconciliation» por uno propio (llamémosle «JAL_G/L – VAT Reconciliation») sería:

Ya está aquí Dynamics 365 Business Central 2021 Wave 2

Llegó octubre y como estaba previsto ya está publicada la versión correspondiente de Business Central. Concretamente es Business Central 2021 Wave 2 (o BC19).

Enlaces de interés:

Ya está aquí Dynamics 365 Business Central 2021 Spring release (wave 1)

Desde ayer 01/04/21 está liberada la versión 2021 wave 1 de Business Central (Business Central 18). Ya está disponible para nuevos clientes y en las próximas semanas se irá desplegando para los tenants ya existentes de la versión anterior (2020 wave 2).

Así mismo, ya está disponible para su descarga como contenedor Docker.

Enlaces de interés:

Fin de soporte de las distintas versiones de Dynamics NAV

Esta semana pasada ha acabado el soporte oficial de la versión 2015 de Dynamics NAV, y hay usuarios (y no sólo usuarios) que no acaban de tener claro hasta cuándo está soportada la versión de Dynamics NAV en uso, y lo que implica.

CicloVidaProducto

Cosas que se desprenden del gráfico (y deberían ser sabidas por quien compra/vende el producto):

  • El periodo de soporte de cada versión del producto es de 5 años aproximadamente desde su lanzamiento (no desde que se implanta en cliente).
  • Una vez pasada la fecha de fin de soporte Microsoft no lanzará actualizaciones/correcciones para dicha versión de producto.
  • Evidentemente es necesario tener el brep en vigor para poder aplicar las actualizaciones de producto.
  • Una vez el producto no esté soportado, puede seguir en uso y actualizándose por parte del partner. También se puede extender el soporte de Microsoft durante un tiempo… pagando, claro (ver columna con fecha tope de soporte extendido).

Esta información está en el siguiente enlace: Ciclo de vida de producto

Demo de Dynamics Saturday 2018 en github (Testing con Business Central)

Sólo hace un año y medio de que la compartí en el Dynamics Saturday Madrid 2018, pero aún así creo que ya toca compartir el código de la demo de automated testing. Recuerdo las características de la misma:

  • Para un cliente se pueden definir «homologaciones» de grupos de productos, con una fecha de caducidad.
  • En el envío de la mercancía se comprueba si la combinación cliente/tipo de producto (del producto de la línea) es válida, teniendo en cuenta la fecha.
  • Hay dos codeunits de testeo:
    • Codeunit 50000. Veréis que no tiene «sustancia», es la que usé en la charla para explicar el comportamiento de las codeunits de testing.
    • Codeunit 50001. Es donde están las funciones de testing propiamente dichas de la funcionalidad. Se testean los casos definidos en la charla.

Y como es lógico, dudas y cuestiones al respecto en el repositorio de la extensión.

 

Sesiones de Business Central en el Dynamics Saturday Madrid 2019

El pasado 25 de mayo tuvo lugar en las instalaciones de Microsoft Ibérica el tercer Dynamics Saturday Madrid que una vez más colmó las expectativas de afluencia y calidad en las sesiones, además de servir de punto de encuentro entre toda la comunidad Dynamics en todas su vertientes.

sfsfs

Por la parte de Business Central, tuvimos seis sesiones que tocaron de todo un poco (novedades, desarrollo, integraciones, explotación de datos), y por suerte podemos compartir y rememorar con los videos de las sesiones (aunque lamentablemente la cámara se desenfocara en algunos momentos). Cronológicamente:

 

  • Pablo Espartero. «Tips & tricks para desarrollo en Business Central con Visual Studio Code».

 

  • Francisco Gómez e Iván Capilla. «Novedades de Business Central en Spring Release ’19»

 

  • José Ángel López. «Conectando Business Central con el mundo»

 

  • Ana María Bisbé. «Power BI – Herramienta de BI».

 

  • Reyes Palma y José María Pedraza. «Que tus modelos en Power BI no sean sólo datos».

 

  • Javier Armesto. «Tus datos por las nubes. Inelligent Cloud e Intelligent Cloud Extension».

 

  • Miguel Llorca. «Presente y futuro de Business Central».

Uso del lenguaje «español tradicional» en traducciones xliff para extensiones de NAV/Business Central

Como muchos ya sabréis, para traducir las extensions a los distintos idiomas es recomendado por Microsoft el uso de traducciones por medio de archivos xliff. Bueno, eso si hablamos de traducciones en extensions para NAV 2018 o Business Central, porque si hablamos de apps destinadas a ser publicadas en appsource… es requisito obligatorio.

Por tanto, el proceso pasa por crear nuestros archivos xliff con las traducciones a cada uno de los idiomas. Un archivo para el inglés UK, otro para el inglés US, otro para el francés, otro para el español ES… o no ¿Por qué?

Pues porque en Business Central nos encontramos con que hay dos idiomas «Español (España)»:

spanishtwins

Que en realidad se corresponden con los siguientes:

  • Español (Ordenación internacional), que se corresponde con el 1034.
  • Español (Ordenación tradicional), que se corresponde con el 3082.

Y aquí viene venía el problema, el complemento de lenguaje AL de Visual Studio Code hasta diciembre de 2018 sólo permitía el uso del idioma «es-ES» (que se corresponde con el 1034):

es-es

Y nos encontrábamos con el problema de que si el usuario elegía el idioma «español (ordenación tradicional)» no veía los textos de la extensión o app traducidos al español, lo cuál era bastante común porque por algún motivo insospechado (como hemos visto en la imagen anterior) en la lista de idiomas no se diferencian.

Por suerte, en la actualización de la CU 3 de Business Central se ha resuelto este problema. La versión 2.1.69331 (en adelante) del complemento del lenguaje AL para Visual Studio Code ya incluye el soporte a la ordenación tradicional del idioma español y podemos incluir las traducciones en dicho idioma.

allanguageversion

Lo único que tenemos que hacer es crear un archivo xlif de la forma habitual, preparado para traducir el idioma «es-ES_tradnl».

es-es_tradnl

Y resuelto, si tenemos los dos archivos xlif con las traducciones (uno para «es-ES», y otro para «es-ES_tradnl»), cubrimos ambos idiomas «Spanish (Spain)».

 

Cómo ver las tablas en Dynamics 365 Business Central

Es de las cosas que primero se cuestiona alguien (consultor o técnico) que se inicia en Business Central y viene del «universo NAV»:

«¿Cómo se puede ver el contenido de una tabla? Antes hacía Run y podía abrirlas».

La solución es tan simple como usar la siguiente URL:

https://businesscentral.dynamics.com/?table=XXXX (Business Central on cloud)

https://NombreDeDominioServidor/Instancia/?table=XXXX (Docker, o Business Central on premise)

XXXX es el id de la tabla deseada, claro.

En mi caso que trabajo con un docker al que he llamado «D365BC», y suponiendo que quiero «ver» la tabla 18 (Customer):

ViewCustomerTableBC

Si lo que queremos es ver la tabla pero de otra empresa distinta a la que nuestro usuario tiene predefinida, debemos incluir el nombre de la empresa en la URL de la siguiente manera:

https://businesscentral.dynamics.com/?company=NombreEmpresa&table=XXXX (Business Central on cloud)

https://NombreDeDominioServidor/Instancia/?company=NombreEmpresa&table=XXXX (Docker, o Business Central on premise)

Otra opción, si estamos creando un proyecto AL, es configurar el launch.json para que abra la tabla que nos interese al publicar el proyecto (lo veo menos útil que la técnica anterior).

LaunchJsonForViewCustomerTableBC

A tener en cuenta:

  • En todo momento hablamos de «ver»… dicho de otra manera, NO se pueden hacer inserciones, modificaciones ni eliminaciones de registros.
  • Es necesario que nuestro usuario tenga permiso:
    • De lectura sobre dicha tabla que se quiere consultar (lógicamente).
    • De ejecución sobre la tabla 1350 (Run table).
  • No se pueden consultar tablas virtuales ni la mayoría de las tablas de sistema (en el siguiente enlace viene descrita la lista de tablas excluídas).

Fuente: Developer and IT-Pro Help for Dynamics 365 Business Central

Microsoft publica en youtube el contenido del programa «Ready to Go» de Dynamics Learning Portal

Como es sabido, Microsoft está celebrando desde el día de hoy el tradicional Directions NA en San Diego. Para los que tengan algo de memoria es el evento donde el año pasado se anunció el «apocalipsis» (NAV se llamaría Business Central, no habría versión 2018 on-prem y desaparecía por tanto el lenguaje C/AL), y posteriormente ante las protestas y presiones se decidió dar marcha atrás y liberar la versión de NAV 2018 on-prem tal y como la conocemos.

Mientras esperamos a ver si definitivamente se libera la nueva versión de Dynamics 365 Business Central, o al menos se da a conocer la fecha de la liberación de la misma, Microsoft ha lanzado dos grandes noticias relacionadas con la formación en lenguaje AL y el desarrollo de extensiones:

  • Microsoft Learn, que a priori parece un híbrido (gratuito) entre Microsoft Virtual Academy y Dynamics Learning Portal. Estaremos atentos en la evolución en cuanto a contenidos (a día de hoy no he visto nada de D365BC).
  • Y la sorpresa de que se empiezan a liberar los contenidos del programa «Ready to Go» de Dynamics Learning Portal en youtube, y por tanto de manera gratuita. Lo hacen a través de la siguiente cuenta.

En definitiva, recursos no nos faltan para empezar (el que aún no lo haya hecho) a desarrollar para D365BC… y gratis.

Test Automation para Dynamics NAV y Business Central – I (o has perdido demasiado tiempo)

Los que trabajamos con Navision NAV Dynamics 365 for Finantials Dynamics 365 Business Central somos un público fácil y agradecido. ¿Que nos ponen colorines para destacar las palabras clave y reservadas? Aplaudimos. ¿Que nos activan intellisens 10 años más tarde que al resto? Aplaudimos. ¿Que nos dan acceso a interoperabilidad con librerías .net? Aplaudimos (porque podemos derivar marrones a los frikis del departamento de .net).

Sin embargo también tenemos fama de ser demasiado «estáticos». Trabajamos con un ecosistema más o menos cerrado que manejamos al dedillo, y todo lo que se salga de esas paredes de cristal nos da mucho canguelo.

Es por ésto que estamos acostumbrados a pasar los días dentro de la terrorífica «rutina del desarrollo NAV». A saber:

(Ésto es una generalización, basada en algunas experiencias pasadas. No debe tomarse al pié de la letra. O sí. Yo que sé)

1.- El consultor viene de unas apacibles y placenteras jornadas en casa del cliente. Normalmente cargado con una maleta llena de sueños y de promesas más o menos realizables. Con suerte, en la maleta también a veces viene documentación más o menos concreta de lo que hay que realizar.

2.- Con dicha información (ya digo que más o menos completa) el responsable técnico traduce los requisitos funcionales (con más o menos fortuna) a un diseño técnico.

3.- El programador (con más o menos fortuna) interpreta el diseño técnico y lo implementa. Comprueba que compilan los objetos. No tiene ni idea de lo que hay que probar, así que devuelve los desarrollos (y se pone otro disco de Daft Punk).

4.- El responsable técnico hace algunas comprobaciones con referencia al diseño técnico y envía los objetos a la velocidad de la luz al funcional. Igual sí sabe algo mejor de qué va el desarrollo, pero no está en sus funciones probar el desarrollo (o no se lo dijeron).

5.- El funcional comprueba (en el mejor de los casos) que los desarrollos funcionan, y normalmente no hacen lo que quiere. En este caso, volvemos al punto 2 sin pasar por la casilla de salida y sí por la casilla de «técnicos molestos porque no se explicó bien lo que había que hacer».

6.- Varias iteraciones de los pasos anteriores después, el consultor finalmente valida los desarrollos y los expone al cliente. Muy probablemente el cliente no valida los desarrollos o los modifica, y o bien el consultor realiza ajustes en casa del cliente (¡¡!!) o bien volvemos al paso 2. En este caso pasando por la casilla de «consultores y técnicos molestos porque el cliente no explicó bien lo que quería».

7.- A los técnicos se les acumula trabajo planificado con las correcciones anteriores, las jornadas se alargan, el malestar crece y las existencias de café decrecen. Se consigue contentar al cliente tras varias amenazas de impago y varias llamadas de gerencia. Todos los estamentos dicen que es la última vez. Un par de días después volvemos al paso 1.

Y así pasamos los días. ¿Es la única forma de hacer las cosas? Evidentemente, no.