Activa Noticias » abril 20, 2017

Daily Archives: abril 20, 2017

TECNOLOGIA

Reconciliación de Lotes de Ventas para Empresas

Published by:

4b7f31c3-8e16-438e-9183-afd53ffc1e35

Hace ya tiempo, Mariano Gómez escribió un artículo sobre el tema Reconciling SOP Batches. Microsoft Dynamics GP en su versión actual aún no ha incorporado la conciliación de los lotes de ventas.

El script precedente de http://www.tiiselam.com/ muestra solamente los lotes con inconsistencias y sus diferencias en el caso de existir.

La primera versión del script de update de Mariano funcionaba con perfección, mas estaba basado en cursores. Entonces actualizó el artículo y lo optimó. De forma casual cuando hice la mía era bastante semejante a la de Mariano, con una pequeña diferencia. Solo actualiza los batch que tienen diferencia y no todos, lo que desde mi punto de vista tiene sentido. El script es el siguiente:

De este modo, si no existen lotes inconsistentes no efectúa ninguna actualización.

En la Parte II, voy a enseñar de qué forma hacer el llamado a un Stored Procedure desde Dexterity. En la actualidad, el procedimiento de VBA no lo aconsejo, debido a que no es soportado por el WebClient.

Reconciliación de Lotes (Batch) de Ventas (SOP) Parte II

En la parte I llegué hasta el script de SQL que actualizaba solamente los lotes inconsistentes de ventas.

Resumiendo, si el stored procedure existe lo suprime ya antes de crearlo y después de creado le asigna permiso de ejecución a DYNGRP. Ya antes de ejecutar este stored procedure se ha de estar situado en la base de datos de la compañía adecuada. Recuerden proseguir las mejores prácticas y siempre y en toda circunstancia hacer backup de la base de datos ya antes de cualquier cambio!!!

Si llegan a ejecutar el stored procedure van a ver que devuelve el número de transacciones que actualiza.

En Fabrikam, Inc. de manera predeterminada hay un lote de ventas llamado SOP ORDERS y volvemos el total de transacciones en 0 con el primer UPDATE. Con el segundo volvemos el monto total del lote en 0. Pueden ejecutar solo uno o bien los 2 para crear las inconsistencias y ejecutar el stored procedure para probar. Asimismo pueden ejecutarlo sobre otros lotes y hacer las pruebas.MSDGreatPlains

Con esto la una parte de SQL está finalizada. Ahora entramos con el código de Dexterity. Cada stored procedure de SQL debe tener su contraparte equivalente del lado de Dexterity llamado Prototype Procedure y debe llamarse de igual forma que se definió en SQL. Debe contener la definición de los factores que recibe el stored procedure y el valor que devuelve. De momento, este stored procedure no recibe factores. Más adelante lo voy a estar alterando para crear una nueva versión que recibe factores.

Lo idóneo de este desarrollo es que quede totalmente integrado con el proceso de conciliación de Microsoft Dynamics GP. ¿Qué es lo que significa esto? Que después de ejecutar el botón “Procesar” se ejecuta el código original de los programadores de Microsoft, después de esto debo ejecutar el stored procedure que he creado y siguiente a esto se ejecuta el reporte de status de la conciliación. El detalle es que las correcciones que ejecutemos en el update no va a ser reflejados en el reporte de conciliación. Estudiando un tanto, ví que la ejecución del proceso de conciliación ejecuta el reporte desde una tabla que llena en la ejecución llamada SOP_Error_Log_TEMP (SOP50700). Los primeros siete SEQNUMBR de la tabla representan el encabezado del reporte. Como tengo la información de los lotes que se marchan a actualizar (script de la parte I de este artículo) puedo completar la tabla y entonces puedo llenar el reporte.

Realmente para llegar a solución debí hacer varias pruebas. La primera prueba que hice fue con Trigger de Foco sobre el botón de Procesar. Esta sería la manera de meditar obvia y lo razonable sería ejecutar el código tras la ejecución de código original. ¿Cuál fue el resultado? El código de conciliación del script de SQL se ejecutaba ya antes que el código de conciliación de Microsoft. En condiciones en que la que la base de datos solo tiene inconsistencias que han de ser corregidas por el script de SQL o bien solo por el código de Microsoft no hay inconvenientes, mas si se combinan los 2 sí, debido a que el código de Microsoft debe ejecutarse primero. ¿Por qué razón? Primero he de ser conciliado cada documento, línea de detalle con encabezado, que es la conciliación que efectúa el código de Microsoft y después puede ser ejecutado la conciliación de SQL, en caso contrario acabamos produciendo más inconsistencias. Es extraño de qué forma es programado esta alternativa de conciliación por la parte de los programadores de Microsoft, mas me dí cuenta que el programa tiene el acontecimiento que comienza la impresión en el Artículo de la la ventana, con lo que la solución fue poner un Trigger de Foco en el Artículo de la ventana ya antes del código original.

De forma adicional alteré el código del script de SQL para alterar el contenido de la tabla de impresión, de modo de reflejar los cambios efectuados por la actualización. Ahora el script de SQL recibe como factor de ID del usuario que está ejecutando la conciliación.

Con estos cambios ahora podemos probar la aplicación en modo test o bien creando el chunk. Estas pruebas las he ejecutado en la versión dos mil dieciseis de Microsoft Dynamics GP, mas he de ser válido para las versiones precedentes. Cualquier duda que tengan pueden contactarme para preguntarme.