Contexto
Debido a que todo es dinámico y puede cambiar, los datos de productos, clientes, órdenes de servicio, notas de venta y otros documentos y entidades del sistema pueden tener modificaciones en diferentes ocasiones durante su ciclo de vida, ya que por regla general la base de datos de un ERP debe ser una representación fiel de la realidad.
Sigue® ERP cuenta con una herramienta de Historial de Modificaciones, que en forma interna y transparente para los usuarios puede dejar registro detallado y accesible de todos los cambios ocurridos en la información, cuando los hacen ellos y, si corresponde, cuando los aplica el propio sistema.
Este recurso se suma al esquema de seguridad que permite definir usuarios, accesos, permisos, niveles y más; todo para que la información sea siempre verídica y segura, al tiempo que está disponible y es generada y aprovechada por toda la organización de forma integrada, ágil e intuitiva, conservando la reserva y confidencialidad donde y cuando sea adecuado.
Este registro de las Modificaciones se integra en la herramienta de Historial con la que cuentan los documentos y demás entidades, y que puede incluir las Autorizaciones y Bloqueos, los Seguimientos y los Hitos. Dicha herramienta está disponible en los menús de texto e icono en la parte superior de los navegadores y de la edición de registros.
Propósito y Resultados
En general, la revisión del historial de modificaciones de un documento o de otra entidad puede servir para detectar anomalías en la gestión, para tener pruebas de quien, cuando y que exactamente se modificó, para saber algo que antes estaba, pero ya no; sin importar que posteriormente haya habido más modificaciones, todas van dejando registro.
Este Histórico puede ser consultado por los usuarios desde los navegadores de tablas maestras y de cartolas y desde la edición de la entidad dentro del ERP.
Además, cuenta con información estructurada en formato JSON que puede ser aprovechada por análisis y estadísticas automatizados creados con herramientas como Microsoft Excel y Power BI, para las cuales se pueden generar las consultas correspondientes, que además se pueden pre grabar y ejecutar en el gestor de base de datos Principal del ERP.
Las estadísticas que se pueden generar mediante consultas o con herramientas externas, por rangos de tiempo, pueden consistir, por ejemplo, en saber que productos son los que más frecuentemente se quitan o reducen, cuantas unidades de esos productos han sido quitadas, cuantos documentos de un determinado tipo han sufrido una disminución de su monto total inicial.
Las estadísticas que se pueden generar del modo ya explicado, permiten hacer análisis que no se tienen en los informes regulares del sistema, pues estos últimos se basan en los documentos y entidades tal como se encuentran al momento de procesar o tal como se guardó cierta información cuando ocurrió el hecho.
Consideraciones importantes
Este recurso puede conservar los registros históricos generados por modificaciones en detalles o tablas hijas de entidades padres (productos, cuotas, documentos relacionados y otros de documentos; precios y componentes de productos; sucursales de clientes y proveedores; y más) aun cuando posteriormente esa línea hija o información sea eliminada, ocasión en que también se genera registro.
Adicionalmente, un documento anulado y cualquier entidad inactivada mantienen su historial de modificaciones y está accesible al usuario, y el historial de modificaciones de un documento u otra entidad eliminada puede ser rescatado de la base de datos si se requiere.
El usuario no requiere intervenir en nada, todo opera automáticamente al grabar el registro modificado (luego de cumplidas las validaciones y antes de grabar), también en ciertos procesos.
Algunas tablas de uso menor o de configuración del sistema pueden no contar con Histórico de Modificaciones; en su lugar cada registro indica la fecha, hora y usuario de creación y de última modificación.
Debido a que esta herramienta genera registros históricos, utiliza clave de Persona Responsable para identificar al usuario que responde por estos. Durante una sesión (acceso y permanencia en una misma tabla o recurso) usualmente el usuario se habría identificado antes con su contraseña de persona responsable exigida por alguna acción, si es así se asume dicha clave y no se solicita nuevamente. Además, se puede aprovechar y asumir internamente la contraseña ingresada la primera vez durante la sesión actual, si está así definido en la parametrización global (nGlbPswPerResModBor = 2).
Configuración y funcionamiento
Cuando se define en verdadero (.t.) el parámetro global del sistema (lGlbHistoryModifica) que por omisión es falso (.f.), la información de Histórico de Modificaciones que se genera y está disponible, además de alimentar la lista estándar de las ocasiones en que la entidad ha tenido modificaciones, en cada uno de esos registros deja un completo detalle de los cambios.
En la configuración del Gestor de Tablas Generales y de la Ayuda de Entidades, en el ID de cada tabla el campo ‘Privacidad / HisMod’ especifica si esta genera histórico de modificaciones, lo que aplica si el parámetro global está activo.
En ese mismo campo, cada campo referenciado define su Privacidad, pudiendo ser un dato público o uno reservado. Reservado significa que cuando es incluido en el detalle del historial porque es nuevo, modificado o eliminado, su contenido no es mostrado, sino que es reemplazado por la expresión “(reservado)”, su presencia deja constancia del cambio. Esto puede aplicar, por ejemplo, con las claves de persona responsable y similares.
Todos los datos del registro modificado (clientes, productos facturas, órdenes de servicios, abonos, etc.) son incluidos por omisión en el detalle para el usuario del Historial en cada modificación efectuada; sin embargo, por motivos prácticos, para todas las entidades que no se gestionan como tablas generales, en la configuración inicial de la ayuda de entidades solo se incluyen los que el usuario interviene directamente, más el monto Total en caso de documentos, y quizás otros que pueden ser necesarios; así usualmente se excluyen aquellos cuyo contenido cambia como consecuencia de la acción del usuario sobre otra información, aunque se puede indicar que si se incluyan si se quiere.
En la configuración del Gestor de Tablas Generales se define con que nombre se presentan sus datos en los respectivos registros. El historial de modificaciones aprovecha esos mismos nombres para mayor estandarización y comprensión. También aprovecha los atributos de formato y otros.
En la configuración de las Ayudas del Sistema se define el nombre, texto de ayuda, algunos formatos de presentación y otros atributos, para bases de datos, tablas, vistas, campos de tablas y vistas, y para otras entidades que pudiera requerirse. Esa información también es aprovechada por el historial de modificaciones con el objetivo de ser más estándar y familiar.
En el caso de los campos de tablas y vistas, gracias a la documentación dinámica integrada en el ERP, en el detalle del registro histórico generado estos se incluyen en el mismo orden en que son presentados y gestionados en la edición del registro de su entidad, facilitando la comprensión.
Los detalles o registros de tablas hijas de entidades padre (como los productos o servicios, cuotas o detalle de forma de pago y documentos relacionados de un documento; los precios y componentes de un producto; las sucursales de cliente y proveedores, etc.) en el Historial de Modificaciones son tratados en forma independiente. Por ejemplo, en los productos y servicios que incluye un documento, al eliminar un detalle del tipo Kit/Paquete, son quitados su registro padre y todos sus componentes, que para el documento son sus detalles. Entonces para el historial cada detalle agregado, modificado o eliminado, independiente de su tipo, es un elemento del registro generado y lo individualiza con la información que le corresponde.
Los datos de los detalles, del tipo que sea y de las entidades que sea, aplican también la lógica de ser incluidos dentro de su contexto en el mismo orden en que regularmente están en la línea de detalles del documento, y solo se incluyen los que efectivamente tienen información y/o cambios. Esto, que se logra mediante la configuración del sistema, puede cambiarse, pero se sugiere mantenerlo así pues se ha comprobado que es lo más adecuado.
El módulo propio de Administración de la Base de Datos del ERP, también aprovecha la información que se indica en los párrafos anteriores, para la documentación dinámica en tiempo real. Esto se describe en el capítulo respectivo de este manual.
Debido a que el ERP y esta información está en evolución constante, es posible que al acceder algunos datos/campos de tablas y vistas no estén documentados aún. En tal caso en el Histórico de Modificaciones y en el Gestor de base de datos Principal son incluidos a continuación de los que si están documentados, en el orden en que son encontrados en la estructura de la tabla o vista y con el nombre de campo que tiene en esa entidad; y el Gestor de base de datos Principal en lugar de mostrar los textos de ayuda al pie del diálogo y dar acceso a los enlaces y textos adicionales, indica que ese recurso aún no dispone de ayuda y sugiere avisar al administrador del sistema.
Respecto a la información guardada en formato JSON como fuente de análisis y estadísticas, en el Gestor de Tablas Generales y en la Ayuda de Entidades el campo ‘HisMod alimenta JSON’ en el IDE de cada tabla padre permite especificar si esta alimenta dichos datos estructurados, y en cada campo permiten definir si este específicamente lo hace, lo que aplica si la tabla lo hace. Si la tabla tiene tablas hijas o dependientes, aunque en estas últimas se puede especificar diferente, asumen lo mismo que su tabla padre; los campos de tablas hijas pueden definir ellos mismos si alimentan el JSON, lo que aplica cuando la tabla padre indica que sí.
De esa forma, por ejemplo, al modificar un registro de tipo de documentos, independientemente de que alimente el Histórico de Modificaciones para ser consultado por los usuarios, se puede especificar que la tabla no alimente el campo JSON; o al modificar un documento, se puede establecer que el campo observaciones no alimente el JSON, todo ello para no almacenar información que en realidad nunca será aprovechada.
Ejemplo
Un Ejemplo práctico, con una orden de Servicio que inicialmente vemos de esta forma
Le hacemos diversos cambios en una sola modificación, y queda de esta forma.
Y este es el registro del Historial de Modificaciones, donde está disponible al costado derecho el detalle de cada cambio hecho, porque está configurado que así sea.
Se observa que el documento, orden de servicio n°75000204, fue creado el 15/01/2023 a las 09:00 horas por el usuario llamado ‘granusuario’.
En el navegador vemos que actualmente acumula tres modificaciones, la más antigua el día 18/01/2023 a las 13:44 horas, y la más reciente, la nuestra, el día 20/01/2023 a las 10:54 horas; tres funcionarios la han intervenido, todos debidamente identificados con su clave de persona responsable en cada ocasión.
Como el cursor está posicionado en la modificación más reciente, la nuestra, el texto del costado derecho muestra el detalle de todos los cambios que en esa ocasión hicimos al documento, y que corresponden a este ejemplo.
En primer lugar, vemos los datos de cabecera y pie en los cuales el usuario hizo cambios y se ha configurado incluir. También se considera el monto total del documento porque, aunque no lo modifica el usuario directamente, si ha cambiado como resultado de las modificaciones hechas en los detalles de productos y servicios y en el descuento general del documento, y en la configuración hemos indicado que se incluya cuando cambia, por ser conveniente para el análisis de documentos. Los datos se incluyen en el orden previamente explicado.
En el caso de campos de texto o memos, como el de Diagnóstico, sabemos que fue modificado, que antes estaba vacío y que después quedó con 45 caracteres. El contenido de los memos no se muestra porque podrían contener una cantidad casi ilimitada de texto y resultaría inconveniente.
Luego vemos los cambios a los detalles, en este caso productos y servicios. Como se ha indicado aparecen ordenados por su posición o número de línea, y cada uno explica en que consiste el cambio.
En la configuración inicial de esta herramienta el código del producto está definido como dato obligatorio, por tanto, en el caso de detalles modificados es incluido como parte de su identificación si no ha cambiado (como en el detalle n°1), o con su antes y después si tiene cambio.
En caso de detalles eliminados y agregados el código siempre está incluido con todos los datos de esa línea que antes tuvieron y/o después tienen contenido.
En el caso de los registros modificados figuran 2 números de línea, el estándar que se refiere a la línea en que estaba antes, y el entre paréntesis que indica la línea donde quedó después, en esta modificación del documento.
Para explicar la capacidad de esta herramienta, en el ejemplo hemos insertado líneas, eliminado, modificado y agregado detalles, y cambiado más datos de los que usualmente se considerarían en modificaciones reales. Es interesante que aún se podrían hacer muestras más complejas, pero para el caso es suficiente.
Si un registro es regrabado sin hacerle modificaciones, el detalle correspondiente a ese cambio es “(regrabar registro, sin cambios)”.