Los códigos QR están muy presentes en nuestras vidas como una forma de compartir información, URL u otros datos de una forma rápida y sencilla.
En este post vamos a ver cómo mostrar uno en un formulario o informe SSRS de Dynamics 365 usando una librería que se incluye en nuestras máquinas de desarrollo: QRCoder.
Continue Reading Añadir un código QR a informes y formularios de Dynamics 365
Ahora que Microsoft va a actualizar los entornos sandbox adicionales de Dynamics 365 Finance and Operations, los partners y clientes solo nos tendremos que ocupar de los entornos hospedados en la nube (cloud-hosted environments), como hemos hecho siempre.
Estoy seguro de que cada equipo gestiona esto a su manera, quizá dejando que cada desarrollador actualice su máquina, o que hay alguien en el partner que se lo hace. Y eso en el mejor de los casos, quizá nadie actualiza las máquinas de desarrollo…
Si quieres saber más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
¡Hoy os traigo un script de PowerShell que podemos ejecutar en un pipeline para actualizar automáticamente todas las máquinas de desarrollo!
Continue Reading Actualizar máquinas con pipelines y d365fo.tools
Crear un paquete o modelo es una de las primeras cosas que haremos cuando empecemos a programar en un nuevo proyecto.
Es algo muy básico, pero sigo viendo algunos problemas sobre esto, malas prácticas que pueden convertirse en problemas en el futuro.
Continue Reading Planificación de modelos y paquetes
¿Necesitas obtener el precio de un artículo que tiene un acuerdo comercial, ya sea de compra o de venta? ¡Pues aquí tenemos a nuestra amiga la clase PriceDisc para salvarnos!
Esto es uno de esos post referencia que escribo para el Adrià del futuro, porque es algo que olvido con una facilidad pasmosa.
Existe un método obsoleto, creo que el findItemPriceAgreement, para obtener el precio, pero está obsoleto como acabo de decir. Así que lo más sencillo es usar la clase PriceDisc que sustituye al método obsoleto.
Para usarlo sólo tenemos que instanciar un objeto de tipo PriceDiscParameters y llamar a sus métodos parm. Luego creamos otro objeto de tipo PriceDisc usando el método newFromPriceDiscParameters y pasándole el de tipo PriceDiscParameters, y… bueno, mejor echa un ojo al código:
public static Amount getPrice(AccountNum _accountNum,
CurrencyCode _currencyCode,
InventDim _inventDim,
ItemId _itemId,
ModuleInventPurchSales _module,
TransDate _date,
Qty _qty,
UnitId _unitId,
PriceGroupId _priceGroupId)
{
PriceDiscParameters priceDiscParameters = PriceDiscParameters::construct();
priceDiscParameters.parmAccountNum(_accountNum);
priceDiscParameters.parmCurrencyCode(_currencyCode);
priceDiscParameters.parmInventDim(_inventDim);
priceDiscParameters.parmItemId(_itemId);
priceDiscParameters.parmModuleType(_module);
priceDiscParameters.parmPriceDiscDate(_date);
priceDiscParameters.parmQty(_qty);
priceDiscParameters.parmUnitId(_unitId);
PriceDisc priceDisc = PriceDisc::newFromPriceDiscParameters(priceDiscParameters);
priceDisc.findPrice(_priceGroupId);
return priceDisc.price();
}Y nada, ya está, eso es todo. Sé que es una entrada bastante estúpida, pero yo también lo soy y se me olvidan estas cosas.
Ha pasado un tiempo desde que escribí el post “Es Dataverse el futuro de las apps de Finance and Operations?”, y cuando lo escribí Dataverse todavía se llamaba CDS y pasó por un par de cambios de nombre más.
¿Ha cambiado algo desde que escribí ese post? ¿Todavía veo a Dataverse como el futuro de las aplicaciones de Finance and Operations? Bueno, ahora sabemos algunas cosas más, y se han publicado nuevas funcionalidades.
Así que echémosle un ojo a la bola de cristal a ver que vemos dentro…
Podemos pensar en la convergencia de la plataforma como el proceso que va a llevar está llevando a Dynamics 365 Finance and Operations y la Power Platform más cerca, y haciéndonos así la vida un poco más fácil cuando queremos integrar ambos.
Si quieres aprender más sobre la convergencia entre FnO y Power Platform, lee esto:
Y también estas sesiones en YouTube (en inglés):
Estad atentos al canal de YouTUbe de ANZD365 FinOpsTeam porque ahora mismo están emitiendo una serie de charlas sobre convergencia y se va a publicar más contenido durante los próximos fines de semana.
Recuerdo la primera vez que configuré Dual Write en un entorno cuando todavía estava en preview. Todo era manual y había parte de prueba y error en el proceso.
¿Has desplegado un entorno de Finance and Operations últimamente? Hay una sección para Dataverse, y después de marcar un check, va a desplegar de forma automática un entorno de Dataverse que se enlazará al de FnO que estamos desplegando. ¡Una vez estén listos, configurar Dual Write es facilísimo!
¿Y las Virtual Entities qué? Las podemos usar en nuestras soluciones de Power Platform en lugar del conector de Finance and Operations. Esto también hará la vida de los desarrolladores de Dataverse más fácil, porque podrán acceder a los datos del ERP de una forma que están acostumbrados y conocen bien.
Todos los add-ins que podemos instalar para extender Finance and Operations se están instalando en Dataverse. ¿Tienes que instalar el add-in de Visibilidad de Inventario o el de Export to Azure Data Lake add-ins? ¡Pues primero necesitarás enlazar un entorno de Dataverse!
No creo que ni a corto ni medio plazo, pero igual en un futuro lejano… o quizá nunca. Si veis la charla de Sunil Garg, deja muy claro que, ahora mismo, hacer que el ERP y CRM/Dataverse convivan en la misma base de datos no está en los planes de la convergencia. ¡Pero por lo menos ya estamos todos en los mismos servidores elastic-pool de Azure SQL!
También pienso que dada la naturaleza transaccional del ERP es un poco difícil que esto ocurra. Pero quién sabe, porque el producto está evolucionando a tal velocidad que, quizá, algún día, lo veamos.
Si desarrollas X++ igual te estás preguntando: “Con todo esto de la convergencia, debería ir aprendiendo sobre la Power Platform?”.
¡Por supuesto que deberías! Pero no porque X++ vaya a desaparecer, esto lo deja clarísimo Sunil Garg en su sesión del Pakistan UG “Finance Operation & Power Platform convergence roadmap” (minuto 9:25).
Pero los desarrolladores de X++ tenemos que dejar de pensar que somos SOLO desarrolladores de X++. Juanan y yo lo hemos dicho en varias de nuestras charlas, ya no somos solo desarrolladores de X++. Primero, el cambio a Azure y ahora la irrupción de la Power Platform: tenemos que pensar en todo esto como herramientas que complementan nuestros desarrollos en X++. Y no solo complementar, en algunos casos incluso sustituirlos, como sería usar Logic Apps para conectar a un servidor FTP.
Si quieres leer más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
Mover datos desde producción a un entorno sandbox es algo que tenemos que hacer regularmente para tener datos reales para testear o debugar. Es un proceso lento que requiere de bastante tiempo y que se puede automatizar como expliqué en el post LCS DB API: automatizando la copia de la DB de Prod a Dev.
En este post voy a añadir un paso adicional al refresco de la base de datos: restaurar un data package (DP). ¿Por qué? Porque estoy seguro que todos necesitamos cambiar parámetros o endpoints en los entornos de test después de un refresco desde prod.
Puedes leer más sobre la API REST del DMF, que voy a usar, leyendo este post de Fabio Filardi: Dynamics 365 FinOps: Batch import automation with Azure Functions, Business Events and PowerBI.
Puedes aprender más sobre la API REST de LCS leyendo estos posts que escribí hace un tiempo. Te puede interesar leerlos porque voy a dar por explicadas algunas cosas que voy a referenciar en este post:
En un post anterior vimos como crear data entities personalizadas para usar en Dual-write.
I ahora quizás te estás preguntando, y ¿cómo muevo los mapeos de Dual-write a un entorno de test o producción desde el entorno de desarrollo? ¿Tengo que hacer otra vez todo lo que he hecho en desarrollo en un entorno Sandbox?
Afortunadamente no, no tenemos que hacer todo de nuevo a mano, podemos usar una solución de Dataverse para copiar los mapeos de Dual-write entre entornos.
Si quieres leer más sobre Dual-write puedes:
Ha pasado un tiempo desde que escribí sobre Application Checker en 2019, y aquí vuelvo a estar. En este post voy a hablar sobre SocrateX y XQuery también, y veremos cómo generar los archivos y bases de datos para analizar el código.
Si quieres aprender más sobre App Checker o SocrateX, puedes leer estos recursos además del post que he enlazado arriba:
Dual-write lleva con nosotros casi dos años ya. Es una de las formas que tenemos de integrar Dynamics 365 Finance and Operations y Dataverse junto a las Virtual Entities.
La solución estándar viene con varias entidades listas para sincronizar. Esta ha sido una de las mejoras que se han introducido desde que Dual-write salió en preview, cuando Juanan y yo hicimos la demo en el Dynamics Saturday de Madrid de 2019.
¿Pero qué pasa si lo que queremos es desarrollar una Data entity personalizada de MSDyn365FO y usarla en Dual-write? Pues es muy fácil, pero hay algunas cosas que tenemos que tener en cuenta.
Continue Reading Desarrollar entidades personalizadas para Dual-write
Llega el fin de las máquinas Tier-1 gestionadas por Microsoft, y esto nos deja sin la capacidad de poder sincronizar la DB o ejecutar tests, a no ser que despleguemos una nueva máquina de build en nuestra suscripción o la de nuestro cliente. Por supuesto esto puede traer preocupación por los costes de esta máquina, y para eso tenemos Azure DevTest Labs.
He escrito este post gracias a la sesión de Joris de Gruyter en la pasada DynamicsCon: Azure Devops Automation for Finance and Operations Like You’ve Never Seen! Y también ha habido bastante investigación y (un monton de) prueba y error por mi parte hasta que todo ha funcionado.
Si quieres saber más sobre builds, releases y el ALM de desarrollo de Dynamics 365 puedes leer mi guía sobre MSDyn365 y Azure DevOps ALM.
Continue Reading Azure DevTest Labs: builds para Dynamics 365 FnO