Histórico de pedidos procesados en un trabajo por lote

AX 2009

Tenemos el siguiente escenario:

El proceso de contabilización de pedidos de compra o, por ejemplo, el de preparación de pedido de venta (aplica a todas las contabilizaciones de compras/ventas) lo configuramos para ser procesado por lote:

1.- Usando el ejemplo de los pedidos de compra vamos a Proveedores > Periódico > Actualización de pedidos de compra > Pedido de compra.

2.- Marcamos Selección posterior, vamos al botón Selección e indicamos los criterios de selección, en este caso podría ser Estado del documento = Ninguno. Aceptamos.

3.- Configuramos el lote haciendo clic en el botón Lote e indicamos la periodicidad (de modo que suceda varias veces, que sea recurrente). Aceptamos y la aplicación nos da un mensaje de que el proceso de ha incorporado a la cola de lotes.

Nuevo registro de histórico de pedidos procesados en el lote

A medida que el lote comienza a procesar cada ejecución del trabajo de contabilización de acuerdo a la periodicidad definida, veremos que la aplicación va mostrando un histórico de los pedidos que han sido procesados en ese lote:

1.- Vamos a Base > Consultas > Trabajo por lotes, seleccionamos el que hemos configurado y lanzado anteriormente. Pulsamos el botón Ver tareas y luego el botón Parámetros.

Lo que allí vemos NO es lo que el sistema está seleccionando en ese momento, se trata de todos los pedidos que se han procesado en todas las ejecuciones del lote.

Lo que sucede es que en AX 2009 se incorporó una mejora para poder retener este histórico y poder saber qué ha sido procesado por el lote, para ello asigna el mismo valor de Número de parámetro (campo ParmId) a todas las contabilizaciones realizadas por ese lote (casos de las tablas PurchParmTable, PurchParmLine, SalesParmTable y SalesParmLine).

La aplicación no está duplicando los registros que selecciona para cada ejecución del lote, para eso usará los criterios de selección insertados al configurar el lote.

Además hay que tener en cuenta que puede suceder que pasado un tiempo desde la activación de ese trabajo por lotes veamos, por ejemplo, un pedido de compra que si lo consultamos está en estado Facturado. Esto es porque en su momento, cuando se contabilizó mediante este lote estaba en estado Abierto y se incluyó, pero luego ese pedido siguió su camino terminando en su facturación, pero seguiremos viendo el pedido en el histórico del lote porque en algún momento fue procesado por ese trabajo por lotes.

Los registros que aquí vemos también los podemos consultas desde los históricos de pedidos de compras o ventas:

Proveedores > Consultas > Historial > Pedido de compra > Pedido de compra (según nuestro ejemplo, pero pudiera ser cualquier de los otros historiales como Albarán, Factura, etc), tendrán el Nº de parámetro asignado por el trabajo por lote y el estado “Ejecutado”.

En Clientes se encuentra en > Consultas > Historial > Pedido de venta.

Para saber qué Nº de parámetro tiene asignado el trabajo por lotes para todas sus ejecuciones, puedes verlo en el formulario de parámetros, accediendo al Filtro avanzado:

Es importante distinguir entre este histórico y el que vemos al pulsar el botón “Historial de trabajos por lotes” desde el formulario principal de Trabajo por lotes. Aquí lo que tenemos es el registro de las ejecuciones del lote, todas las ocurrencias que han sucedido, pero no tenemos la información de qué pedidos se han procesado en cada ejecución, que es lo que podemos visualizar desde el formulario de Parámetros.

Posible consecuencia

Si el número de pedidos procesados es muy alto y el trabajo por lotes no tiene fecha fin, lo que puede ocurrir es que la información de histórico de pedidos vaya creciendo y veamos allí cada vez más registros lo que puede acarrear problemas de rendimiento.

Para ello podría incorporarse un nuevo índice en la tabla PurchParmTable con los campos ParmId, TableRefId and ParmJobStatus que son los que usa en la construcción de la consulta al procesar los pedidos.

En el caso de procesamiento de pedidos de venta, sería la tabla SalesParmTable y el índice sería con los campos ParmId y ParmJobStatus.

Nota: esto es una recomendación que debe ser probada en el escenario correspondiente.

Por otra parte, también puede considerarse la limpieza periódica del historial de contabilizaciones. Ya sea las de compras: Proveedores > Consultas > Historial > Pedido de compra o las de ventas: Clientes > Consultas > Historial > Pedido de venta, sería cuestión de analizar que antigüedad de historial se necesita y qué registros podrían ser eliminados para disminuir el tamaño de la tabla. Esto en función de las necesidades de negocio del cliente. Es importante considerar que sólo deben eliminarse los registros en estado “Ejecutado”, los que estén en estado “Esperando” o “Error” debe ser evaluados aparte.

Marialecia Guada

Dynamics AX Support Services