AcumatiCares
Resumen de funciones de auditoría
Comencemos con un repaso de lo que es la Auditoría en Acumatica y cómo configurarla. El ERP de Acumatica permite a un usuario rastrear los cambios realizados en casi cualquier campo de Acumatica.
Supongamos que desea realizar un seguimiento siempre que se modifique el valor de una línea de crédito para un cliente y cuando se modifique la línea de dirección 2, así como cualquier cambio en un atributo de cliente de INDUSTRIA.
Seleccione la pantalla de mantenimiento de Clientes en la pantalla de Auditoría y observe que varias tablas y campos podrían estar ya seleccionados para usted. Asuma que esto podría estar ya configurado y nuestra solución necesita enfocarse solamente en el campo o campos que nos interesan. Necesitaremos incluir Customer, BACCOUNT y CSANSWERS para los atributos. Cuando haya terminado de seleccionar las tablas y campos adecuados, asegúrese de marcar la casilla Activo para iniciar la auditoría.
Ahora podemos probar un cambio. Abra ABC Holdings o cualquier cliente y cambie el límite de crédito. Estoy usando la base de datos de Demostración de Ventas, así que voy a cambiar la línea de crédito a $123,456.78. Voy a cambiar la línea de dirección 2 a Suite 122, y voy a añadir un atributo de BANKING.
Si a continuación abre la pantalla Historial de auditorías de Acumatica, podrá ver los cambios realizados.
Lo que ocurre entre bastidores
En primer lugar, veamos la tabla AuditHistory en SQL.
Observe que no sólo el cliente ABCHOLDING tuvo cambios, sino que otros 2 clientes también los tuvieron. Pero no los hemos tocado. Vea si puede adivinar por qué mientras continuamos. Explicaré más en la próxima sección.
Lo que vemos al revisar la tabla AuditHistory son dos registros para nuestro cliente, uno para la tabla Customer y otro para la tabla base BAccount.
- El BatchID nos dará una agrupación de cuando se hizo un cambio. En mi ejemplo, he cambiado tres cosas diferentes en la pantalla del cliente, por lo que todas ellas se agruparon de forma ordenada
- ChangeID será un ID único de cada cambio
- En Operación verá una U de actualizado y una I de insertado
- TableName nos indica obviamente qué tabla se ha modificado
- CombinedKey proporcionará información sobre qué registro maestro se ha modificado
- El campo ModifiedFields del registro del cliente nos indica qué campo se ha modificado
No hace falta decir que nunca queremos leer SQL directamente en el mundo de Acumatica, así que echemos un vistazo a lo que obtenemos al leer los registros de AuditHistory desde la capa de acceso a datos.
He creado un botón en la pantalla de mantenimiento de clientes para una depuración rápida y mostrarte todos los extras que obtienes.
GIST: https://gist.github.com/JACOBNOTES/f7e1c49abe27b476fe6701d11c5127ae
Cuando depuro esta línea de código y examino la colección HistoryRecords puedo ver que obtenemos el mismo recuento de registros que vimos en SQL. Vamos a desglosar lo que vemos.
En la CombinedKey de este registro, tenemos el valor BACCOUNT.ACCTCD que nos indica el cliente que se ha modificado.
En el campo ModifiedFields, tenemos un par clave/valor separado por un "\0". Podemos analizar estos datos en un diccionario que nos indica qué campo se modificó y a qué valor se cambió. Fíjate que esto no se ve con una simple consulta SQL a la tabla. En su código, espere que esto pueda contener más de un par de valores como verá más adelante.
Para los cambios de dirección, ahora tenemos un ejemplo de más de un par clave-valor en el campo ModifiedFields. No cambiamos directamente el RevisionID pero la lógica de negocio en la pantalla sí lo hizo, así que tenlo en cuenta si sólo quieres rastrear campos muy específicos, tendrás que filtrar lo que no necesites.
El valor CombinedKey para un cambio de dirección contendrá un valor de cadena que representa el int AddressID, que puede comprobar haciendo una consulta rápida. La lección aquí es que el CombinedKey no siempre contendrá el valor ACCTCD, podría llevar el ID de registro, por lo que tendrá que convertirlo de una cadena a un valor int en algunos casos.
En las auditorías de atributos aparecen cosas aún más interesantes.
Aquí nuestro par clave-valor en el campo CombinedKey representa un GUID NoteID que apunta al BACCOUNT por NoteID donde se produjo el cambio.
El valor de NoteID está separado por "\0", que indica qué clave de atributo ha cambiado, que en este caso era "INDUSTRY". Dado que el TableName es CSANSWERS, podría contener cualquier atributo que hubiera cambiado.
Los campos ModifiedFields para atributos siempre tendrán "Value" parseado por el nuevo valor que es BNK para Banca.
Esta consulta muestra la coincidencia de qué cliente fue cambiado.
Otros puntos de vista
En nuestra primera sección, señalé que más de un cliente se disparó como cambiado cuando sólo hice un cambio en ABCHOLDING. Esto se debe a la naturaleza de las cuentas hijo de los clientes. ABCVENTURES y ABCSTUIDOS son cuentas hijas de ABCHOLDING y bajo la lógica de negocio y configuración de Acumatica están forzadas a compartir la información de límite de crédito por lo que cambiar una desencadenó el mismo cambio para las otras dos. Es importante esperar que ocurran rarezas como ésta, por lo que necesitará hacer mucha programación defensiva y pruebas para acomodar sus objetivos de solución.
Espero que este BLOG le resulte útil al proporcionarle información básica que podría necesitar al diseñar una solución programática que requiera extraer información de auditoría de Acumatica.
¡Feliz codificación!
