Diciembre '2009

Valor devuelto, no funciona en sub-modelos heredados

Al configurar una variable de modelo de producto, existen dos opciones para configurar como se comportará esta variable en caso de utilizar modelos heredados (un modelo de producto ejecuta otro modelo de producto):

Product Builder | Variables

La opción "Valor devuelto" no funciona en AX 3 y 4 (el problema esta corregido en la 2009) debido a un fallo en la programación de las clases estándar del configurador de producto.

Para solucionarlo editar el método de clase \Classes\PBATreeNodeCompile\PBAVarMethods() en su línea #101 y modificar la línea:

[snippet|type=xpp|csid=20|tagstyle=block|lineNumbering=|numberStart=]

por:

[snippet|type=xpp|csid=21|tagstyle=block|lineNumbering=|numberStart=]

Después de este cambio será necesario compilar todos los modelos de producto para volver a generar sus clases corregidas.

Error en modelo de producto con opciones de gráfico AX4

Si AX 4 está configurado en un idioma que no es inglés (yo lo he probado en castellano pero entiendo que funcionará de la misma manera en otros idiomas), al ejecutar un modelo de producto al que se hayan configurado opciones de gráfico, AX mostrará un error de ejecución. Es un error de traducción del estándar que ya está corregido en la versión 2009.

Para solucionarlo, editar el método de clase \Classes\PBAFrontEndControlWin\run(), en su línea #8, y modificar la línea:

[snippet|type=xpp|csid=18|tagstyle=block|lineNumbering=|numberStart=]

por:

[snippet|type=xpp|csid=19|tagstyle=block|lineNumbering=|numberStart=]

Después de este cambio será necesario compilar todos los modelos de producto para volver a generar sus clases.

Optimización de rendimiento para Product Builder

El configurador de producto de AX es uno de los módulos que personalmente mas me gustan de este ERP. Su potencia y utilidad son innegables pero también lo és que no resulta demasiado eficiente en algunos casos. Uno de sus puntos débiles es el rendimiento al mostrar los formularios configurables y para ello se ha publicado en el blog Dynamics AX Live un interesante y sencillo truco para reducir el tiempo de carga de los formularios del PB.


La idea es no forzar a AX a aplicar propiedades de estos formularios que ya están aplicadas, cosa que el estándar sí hace, y con esto se reducirán muchísimas llamadas al formulario sobre todo en los que dispongan de muchas variables.


Para ello iremos al método SetControlProperties de las clases PBAFrontEndControl y PBAFrontEndControlWin y buscamos el siguiente código:


[snippet|type=xpp|csid=14|tagstyle=block|lineNumbering=|numberStart=]


y sustituimos por este:


[snippet|type=xpp|csid=15|tagstyle=block|lineNumbering=|numberStart=]


Mientras escribía este post he recordado que tengo un documento en alguna parte de mi disco duro con un par de bugs localizados en el estándar del Product Builder. En cuanto lo encuentre los publicaré.

HOWTO: AX - Distribuir ficheros con SysFileDeployment

A veces es util poder distribuir a los clientes de AX ficheros auxiliares que van a necesitar para la ejecución del programa, por ejemplo, controles ocx, librerias dll, iconos, imágenes, etc.

Gracias a André Arnaud, que amablemente respondió a una duda mía en los foros de la Microsoft Dynamics Community he descubierto el framework de AX SysFileDeployment que viene perfecto para esta tarea.

La idea de este framework es heredar clases para indicar a AX qué ficheros deben copiarse a la parte cliente cada vez que se realiza una nueva instalación de AX. Este framework tiene bastantes limitaciones pero la ventaja es que en su código se gestiona bastante bien el tema de permisos para copiar ficheros situados en el servidor hacia el cliente.

Comparto las pruebas que yo he realizado por si a alguien le pudieran servir. En primer lugar, hay que generar una nueva clase heredada de SysFileDeploymentFile indicando a AX qué fichero hay que copiar, dónde esta y hacia donde copiarlo. Esta es la estructura básica de la clase heredada, que esta bien autodocumentada por si se necesita mas personalización:

[snippet|type=xpp|csid=13|tagstyle=block|lineNumbering=|numberStart=]

Una de las limitaciones de este framework es que sólo se ejecuta la primera vez que se ejecuta el cliente en un equipo determinado. Por tanto para distribuir nuevos ficheros o para hacer pruebas, como es mi caso, habría que modificar el método applBuildNo() de la clase ApplicationVersion, para forzar al sistema a actualizar la versión. Haciéndolo de este modo, AX detectará que tenemos ficheros pendientes de actualizar en el servidor y nos mostrará el siguiente diálogo:

SysFileDeploymentFile

Como no me apetecía andar modificando la build de mi entorno de pruebas, he hecho un pequeño Job que simula el código que se ejecutaría automáticamente de manera normal:

[snippet|type=xpp|csid=12|tagstyle=block|lineNumbering=|numberStart=]

Otra de las desventajas es que parece que esta clase no funciona demasiado bien en AX 4. Yo las pruebas que acabo de hacer en 2009 SP1 sí han funcionado, salvo un pequeño problema con las rutas de origen/destino, supongo que por ejecutar todo el entorno en la misma máquina (cliente, aplicación, AOS, ..).

A partir de aquí que cada uno investigue lo que necesite.

HOWTO: AX - Expandir LMAT por código

AX nos deja expandir, o explotar, una línea de lista de materiales (L.MAT, o BOM en inglés) de manera que podamos manejar sus elementos al mismo nivel que el artículo L.MAT. La funcionalidad se llama Expandir L.MAT y la podemos ver, por ejemplo, en las líneas de un pedido:

Explode BOM | Expandir L.MAT

Esta función nos presenta un formulario para elegir las líneas que queremos "Explotar" fuera de la lista de materiales para su tratamiento:

Explode BOM | Expandir L.MAT

El código que este formulario ejecuta para realizar la expansión de la L.MAT se encuentra, en el caso de líneas de pedido de venta, en la tabla SalesLine) concretamente en el método: SalesLine.expandBOM(), por tanto para simular esta funcionalidad en X++, el mínimo código que podemos utilizar es el siguiente:

[snippet|type=xpp|csid=10|tagstyle=block|lineNumbering=|numberStart=]

y digo mímino porque la línea se insertará con la mayoría de sus opciones por defecto, por lo que es seguro que habra que añadir código extra para completar los datos necesarios según las necesidades.