Get best of the week

Desarrollo del primer proyecto en la plataforma de Microsoft Dynamics 365 para Finanzas y Operaciones

¡Hola a todos! Mi nombre es Tanya, soy el líder del equipo de desarrollo de Axapta en Lamoda. Este artículo discutirá el desarrollo de nuestro primer proyecto en la plataforma Microsoft Dynamics 365 For Finance and Operations.

imagen

Hablaré sobre los enfoques que usamos, sobre los errores que se cometieron, compartiré mi conocimiento y experiencia adquirida. Este artículo puede ser de interés para aquellos que comienzan a desarrollar un proyecto en D365 o simplemente lo piensan.

Esta es una transcripción gratuita del informe de la reunión de Mycrosoft Dynamics 365 & Power Platform Meetup.

Objetivo del proyecto y fundamentos técnicos


Nuestra filial alemana compra bienes y los vende a una entidad legal rusa. Anteriormente, utilizamos el sistema Tsenit, que nos permitía mantener registros solo a nivel de datos financieros, pero no podía hacer frente a las tareas de bienes y logística. Para resolver estos problemas, teníamos herramientas adicionales. Los datos se almacenaron en varias bases de datos a la vez. Todo esto afectó negativamente la velocidad y confiabilidad de todo el sistema.

Queríamos que el sistema contable ayudara a la sucursal alemana a presentar informes, pagar impuestos y aprobar auditorías. El ERP pasado apenas resolvió estos problemas, por lo que decidimos desarrollar y lanzar nuestro propio sistema de contabilidad. Se suponía que nuestro ERP combinaría finanzas, contabilidad y logística de sucursales en un solo circuito. Como software principal, elegimos Microsoft Dynamics 365, el antiguo Dynamics AX, también conocido como Axapta.

El componente comercial se describe en el artículo "Tecnología, Outsourcing y Mentalidad" . Aquí hablaremos sobre la implementación técnica. Entonces, necesitábamos automatizar varios procesos comerciales:

  • Compra de bienes de proveedores;
  • Venta a una entidad legal rusa;
  • Integración entre D365 y Ax2012, el sistema contable de una entidad jurídica rusa;
  • ;
  • .

En el proyecto, decidimos implementar la solución en la nube Microsoft Dynamics 365, ya que la oficina alemana no tenía la infraestructura de TI para implementar la aplicación, ni las personas responsables de ella. Para pequeñas sucursales remotas, el esquema SaaS es óptimo, ya que le permite obtener todo el software necesario y los entornos de desarrollo para comenzar la implementación, inmediatamente después de firmar el contrato con el proveedor.

Teníamos plazos ajustados: era necesario completar todo el desarrollo en 3 meses. Dado que en el antiguo sistema la contabilidad de productos se realizaba en hojas de cálculo, transferir el conjunto completo de datos históricos sería una tarea imposible en medio de un año fiscal. Pero al comienzo del período del informe, es suficiente transferir solo saldos. Por lo tanto, fue necesario lanzarlo el 1 de enero de 2019 o posponerlo para otro año.

Nuestro equipo no tenía experiencia en desarrollo en D365. A pesar de todas las circunstancias, planeamos comenzar este proyecto lo más rápido posible. A continuación, describiré por separado todas las etapas de desarrollo. Me detendré en cada iteración en detalle: qué experiencia obtuvimos y qué errores cometimos.

Primera iteración, modificaciones en la versión de aplicación 7.3



imagenPara comenzar a trabajar rápidamente, primero desarrollamos una arquitectura de aplicación simple. Consistió en entornos de desarrollo: entornos DevBox de 1 nivel. Todos los componentes se instalaron en un servidor / máquina virtual: Application Object Server (AOS), base de datos, Dynamics 365 Retail and Management Reporter.

Para las pruebas, decidimos utilizar el entorno SAT: prueba de aceptación estándar de 2 niveles.

El entorno de 2 niveles es un entorno de caja múltiple, cuyos componentes están instalados en varios servicios en la nube y generalmente incluyen más de un servidor de objetos de aplicación (AOS). De hecho, está lo más cerca posible de un entorno productivo, por lo que decidimos probarlo.

Implementamos los primeros entornos de desarrollo en la infraestructura local existente, pero su capacidad no era suficiente para el desarrollo posterior del proyecto. Por lo tanto, cuando dos desarrolladores más se unieron al proyecto, implementamos DevBox de manera rápida y elegante para ellos en la nube.

Nuestros entornos en la nube se administraron a través del portal de servicios Lifecycle.

Habiendo terminado con los entornos, el equipo comenzó a desarrollarse. Configuramos el entorno de desarrollo en Visual Studio y los conectamos al control de versiones de Azure DevOps, habiendo creado previamente una rama para descargar el código. A continuación, desarrollamos un enfoque para el desarrollo y la transferencia de cambios al entorno SAT.

No hay capas en la arquitectura D365; todo el código estándar se ha establecido en el modelo. Las modificaciones se transfirieron al entorno SAT a través del portal LCS con un paquete que contiene un modelo compilado.
– , – , .

Para comenzar, implementamos la modificación más simple y más común: agregar un nuevo campo a la tabla estándar, inicializarlo al crear el registro y enviarlo al formulario estándar.

imagen

Incluso en un proyecto tan simple, hay nuevos tipos de objetos. Hicimos una extensión para agregar nuevos campos a la tabla estándar. Para llevar el campo al formulario estándar, creamos un nuevo tipo de objeto: una extensión para el formulario. Y para inicializar el campo, creamos una clase que extiende los métodos de tabla. Permitió inicializar el campo al crear el registro.

imagen

En una modificación tan simple, vimos uno de los principios básicos de D365: no un cambio, sino una extensión de los objetos estándar.

La siguiente modificación fue la creación de una nueva forma. Ahora, al crear un formulario, era necesario especificar su patrón.Un patrón es un patrón que define completamente la estructura de diseño de un formulario. Hasta que reproduzcamos completamente la estructura establecida en la plantilla, nuestro formulario no se compilará. Es imposible cambiar la plantilla del formulario terminado. Por lo tanto, antes de comenzar el desarrollo, pensamos de antemano cómo se vería nuestra forma.

imagen

imagen

imagen

También conservamos la capacidad de gestionar el diseño del formulario nosotros mismos. Si indicamos patrón - Personalizado, entonces somos totalmente responsables del diseño del formulario: qué objetos había en él y con qué anidamiento.

imagen

imagen

imagen

Conclusiones después de la primera iteración.


1. No cambie el estándar, solo amplíelo.

2. Consulte el modelo si usamos sus objetos en otro modelo. Esta es una de las diferencias entre los modelos D365 de las versiones anteriores: existe un objeto en un solo modelo.

3. Existen limitaciones para cambiar las propiedades de los objetos estándar. No todas las propiedades de los campos estándar se pueden cambiar en sus extensiones de objetos estándar. Por ejemplo, la extensión de la tabla PurchTable es el campo LineDisc. Podemos controlar la visibilidad del campo y la etiqueta, y las propiedades como obligatorias y editables no se pueden cambiar.

imagen

4. No hay trabajos en D365, todo se hace a través de clases.

5. Vencimos a los modelos demasiado finamente, y resultó que nuestro principio de "una modificación = un modelo" no funciona.

Segunda iteración y transición a un modelo


Al comienzo de la segunda iteración, teníamos dos modelos que se referían entre sí. Debido a esto, ya no pudimos transferir estas modificaciones de forma independiente. Por lo tanto, decidimos trabajar en un nuevo modelo, en el que era necesario transferir todas las modificaciones existentes.
Un modelo en D365 es una colección de archivos de origen ubicados en un directorio separado. Al compilar, se recopilan en una biblioteca separada que tiene un enlace con otras bibliotecas.

Por lo tanto, la fusión en un modelo en DevBox se redujo a transferir archivos de un directorio a otro y eliminar directorios antiguos.

Entonces, creamos un nuevo modelo, obtuvimos su última versión en cada DevBox y luego continuamos trabajando dentro del marco de un modelo en entornos de desarrollo.

Naturalmente, ya hemos transferido un par de modelos para probar en el entorno SAT. Por lo tanto, era necesario eliminarlos y lanzar uno nuevo.

Todas las actualizaciones del entorno SAT se realizaron mediante paquetes, incluida la eliminación de modelos. Creamos un paquete con modelos vacíos que deben eliminarse y agregamos un script con los nombres de estos modelos. Luego recolectamos un paquete con un nuevo modelo y lo colocamos en el entorno SAT. Por lo tanto, SAT obtuvo un nuevo modelo.

Cuando se combinaron los modelos, notamos que cada desarrollador nombra las extensiones de los objetos a su manera. Acordamos las reglas para nombrar objetos de acuerdo con la plantilla: PurchTable.LamodaModelFormExtension, PurchTableTypeLamodaModelClass_Extension .

También acordamos en el equipo que para un objeto estándar creamos solo una extensión y hacemos cambios a todo.

Seleccioné algunas modificaciones interesantes que hicimos en esta etapa. Muestran posibles enfoques de desarrollo en D365.

Tarea 1

Al contabilizar la factura del pedido de ventas, fue necesario reemplazar el número de factura con el número del pedido. Para hacer esto, definimos una clase estándar con la posibilidad de extensión, lo que nos permitió realizar esta modificación.

imagen

Hicimos una extensión a la clase estándar SalesInvoiceJourCreate. Hay Siguiente en su método getNumAndVoucher (): este es nuestro nuevo súper, habla de llamar al código del método estándar. Después de llamar al código estándar, reemplazamos el número de factura con el valor deseado.
Este es uno de nuestros enfoques de desarrollo: usar extensiones y agregar nuestro propio código antes o después (como opción, tanto antes como después) de la ejecución del código estándar.

Tarea 2

Era necesario cambiar la visualización de los totales de la orden de compra: agrupe los totales por el número de factura del proveedor de las líneas de la orden de compra. En este caso, no encontramos un lugar para la expansión sin reducir a la mitad el rendimiento, por lo que creamos nuestra propia versión de los resultados sin tocar los estándares.

imagen

Tarea 3
Otra modificación interesante: en las líneas del formulario de pedido de compra, era necesario agregar campos de la lista de artículos con la capacidad de filtrar. En versiones anteriores, la modificación era completamente poco interesante y se resolvió simplemente agregando una tabla como fuente de datos al formulario y superponiendo los dos métodos.

En la versión 7.3, no pudimos extender los métodos a una fuente de datos de formulario estándar. Para filtrar y no crear un nuevo formulario para esto, agregamos view como fuente de datos al formulario.

La capacidad de extender los métodos al origen de datos apareció en la versión 8.1 de D365.

imagen

Conclusiones después de la segunda iteración.


En esta etapa, hemos desarrollado las modificaciones básicas necesarias para lanzar el proyecto.

  1. Introdujimos las reglas para nombrar extensiones. No solo ayudaron a que los nombres fueran coherentes y comprensibles, sino que simplificaron aún más la actualización, ya que nuestros nombres no coincidían con los nombres de los objetos estándar del service pack.
  2. Me gustó lo rápido que ocurre la referencia cruzada cuando se construye un proyecto o modelo; está muy convenientemente organizado en esta versión.
  3. La actualización de modelos en diferentes tipos de entornos ocurre de diferentes maneras. Estábamos convencidos de ello en un ejemplo de fusión de modelos.
  4. Antes de comenzar el desarrollo de una nueva modificación, debe obtener la última versión del modelo, ya que el desarrollo se lleva a cabo dentro del marco de un modelo.
  5. El mecanismo de la entidad de datos para cargar y descargar datos en Excel al actualizar los datos en el producto resultó ser muy conveniente. Nuestro departamento de Datos y Análisis ahora lo está utilizando para recuperar datos de nuestro D365 basado en la nube.

Hicimos el desarrollo principal a tiempo. Go Live salió, el modelo está en producción. Y nos enfrentamos al problema de lanzar solo modificaciones probadas dentro del modelo. También queríamos facilitar el proceso de depuración durante la prueba de modificaciones y acelerar la actualización del entorno de prueba.

Como funciona ahora


En la última iteración, agregamos dos entornos: compilación y prueba. Después de que todos los entornos se configuraron y verificaron, simplificamos las pruebas y aprendimos a lanzar solo modificaciones probadas dentro del modelo.

Para las pruebas, implementamos un entorno de 1 nivel y lo conectamos a la rama de desarrollo en el sistema de control de versiones. La actualización ahora consistía en obtener la última versión del modelo en sí y su ensamblaje. En este entorno, debutamos, como en el DevBox habitual.

imagen

Los paquetes de compilación para lanzamiento ahora se llevan a cabo en un nuevo entorno de compilación. Las modificaciones probadas se transfirieron a una nueva sucursal en el sistema de control de versiones mediante conjuntos de cambios (paquetes de cambios cargados en el sistema de control de versiones), en un principio desde el principio hasta el último.

Luego, implementamos el paquete en el entorno SAT donde se realizaron las pruebas de los usuarios, después de lo cual programamos el paquete en el portal LCS para su lanzamiento en el producto. Así que configuramos el proceso de lanzamiento utilizando el entorno de compilación.

Y decidimos no revisar los proyectos, sino los conjuntos de cambios para modificación, subidos al control de versiones.

La primera actualización de la versión en la nube


Trabajamos en la versión en la nube, por lo que necesitábamos actualizarnos regularmente. La primera actualización fue una transición de la versión 7.3 a la versión 8.0. Tomó alrededor de dos semanas.

Por supuesto, creamos los principales problemas para nosotros mismos, pero también ganamos:

  1. No acordamos de inmediato las reglas para nombrar objetos estándar. En la primera actualización, nuestros nombres de objetos coincidieron con los nombres de los objetos en el service pack.
  2. Al actualizar entornos en la nube, necesariamente cerramos sesión en las máquinas AOS, de lo contrario el proceso de actualización no podría completarse con un usuario conectado.
  3. El paquete de actualización para entornos de producción y SAT necesitaba combinarse con el paquete del modelo.

Hoy, la actualización de todos nuestros entornos demora aproximadamente de 3 a 4 días y se lleva a cabo sin la participación de los desarrolladores. Incluso podemos lanzar un lanzamiento al mismo tiempo que la actualización, lo principal es que la compilación, el SAT y el producto tienen la misma versión.

El proceso de actualización consiste en descargar el paquete de actualización en el portal lcs. El DevBox y la prueba se actualizan primero, luego se actualiza la compilación, los últimos son SAT y prod.

Resultados de todo el primer proyecto


  • Hemos adquirido experiencia en la construcción de la arquitectura de la aplicación D365.
  • Desarrolló un nuevo enfoque para la revisión de código.
  • Creamos las reglas para transferir bases de datos a DevBox (en D365 es importante realizar pruebas iniciales en DevBox, y ahora incluso estamos probando desarrolladores en DevBox).
  • Escribió pautas de desarrollo en D365.
  • Aprendí a desarrollar en la nube.

Toda esta experiencia nos ayudó a desarrollar el proyecto más cuidadosamente. Ahora que conocemos las capacidades del sistema, podemos construir más correctamente la arquitectura, o más bien establecer tareas. Los procesos acumulados en torno al proyecto facilitan la conexión de desarrolladores que escriben por primera vez con D365.

More articles:


All Articles