Tag Archives

Adaptaciones de AX para la ley del IVA 2010

0 , , , , 0

Microsoft lleva ya algún tiempo publicando información y objetos actualizados para adaptar nuestro AX a la nueva reforma europea de la ley del IVA 2010. Han creado un punto de partida donde recopilan toda esta información y descargas llamada AX VAT 2010 Landing Page en PartnerSource.

De entre toda esa información cabe destacar la descarga de los nuevos objetos para:

Así como los whitepapers:

Entre otras muchas cosas!

Valor devuelto, no funciona en sub-modelos heredados

0 , , , , 0

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:

PBATableVariable.Vartype            == PBAvartype::Datatype     &&

por:

PBATableVariable.Vartype            &= PBAvartype::Datatype     &&

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

0 , , , , 0

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:

graphicControl = element.design().controlName('Graphic');

por:

graphicControl = element.design().controlName("@SYS40661");

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

0 , , , , 0

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:

dataSource.object(valueTmpBuildForm.activeField()).enabled(enabled);
dataSource.object(valueTmpBuildForm.activeField()).mandatory(mandatory);
dataSource.object(valueTmpBuildForm.activeField()).visible(visible);

y sustituimos por este:

if(dataSource.object(valueTmpBuildForm.activeField()).enabled() != enabled)
    dataSource.object(valueTmpBuildForm.activeField()).enabled(enabled);
if(dataSource.object(valueTmpBuildForm.activeField()).mandatory() != mandatory)
    dataSource.object(valueTmpBuildForm.activeField()).mandatory(mandatory);
if(dataSource.object(valueTmpBuildForm.activeField()).visible() != visible)
    dataSource.object(valueTmpBuildForm.activeField()).visible(visible);

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

0 , , , , 0

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:

class SysFileDeploymentFileJAEEIcon extends SysFileDeploymentFile
{
   public Filename filename()
   {
       return 'jaestevan.png';
   }

   //AOSRunMode::Server
   protected FilenameOpen sourcePath()
   {
       return "C:\\Archivos de programa\\Microsoft Dynamics AX\\50\\Application\\Share\\Include\";
   }

   //AOSRunMode::Client
   protected FilenameSave destinationPath()
   {
       return xInfo::directory(DirectoryType::Include);
   }
}

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:

static void JAEE_SysFileDeployment(Args _args)
{
   container           classes;
   SysFileDeployment   sysFileDeployment;
   container           classVersion;
   classId             classId;
   ;

   classId = classNum(SysFileDeploymentCesserIcon);
   sysFileDeployment = classfactory.createClass(classId);
   classes += [[classId,sysFileDeployment.getServerVersion()]];

   classVersion = conpeek(classes, 1);
   classId = conpeek(classVersion, 1);

   sysFileDeployment = classfactory.createClass(classId);
   sysFileDeployment.setServerVersion(conpeek(classVersion, 2));
   sysFileDeployment.run();
}

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.

Descarga