Log de Auditorías - Plenario v14

El Log de Auditorías es el visor de la tabla Plenario_Operaciones_Log: registra las operaciones auditadas del sistema (asientos, clientes, créditos, parámetros, cierres, transferencias, tickets, etc.), con el objeto involucrado serializado en JSON para poder revisar el estado guardado.

La ventana permite filtrar por rango de fecha y por tipo de log, ver el resultado en grilla y, con doble clic sobre una fila, abrir el detalle con el objeto serializado (y, en el caso de cierres automáticos, el desglose del proceso). El detalle se puede imprimir, exportar a PDF y exportar a Excel.

Es una herramienta de trazabilidad/diagnóstico: muestra qué operación se hizo, de qué tipo, su estado, origen/destino, quién y cuándo, más el JSON del objeto auditado.

Novedad de la versión 1.1: auditoría de las fichas maestras

Desde esta versión se auditan también el alta, la modificación y la baja de las fichas de Clientes, Proveedores y Proveedores Financieros, que antes no dejaban registro. La diferencia con el resto de los tipos es que la modificación se registra campo por campo: el detalle no muestra la ficha completa, sino únicamente los campos que efectivamente cambiaron, con su valor anterior y el nuevo.

Esto permite responder con precisión "quién le cambió el límite de crédito a este cliente y qué valor tenía antes", sin tener que comparar dos volcados de la ficha entera.

Novedad de la versión 1.2: auditoría de las alícuotas de percepción de clientes

Se incorpora el tipo de log Clientes_Percepciones, que registra cada alta, modificación y baja de una alícuota de percepción asignada a un cliente, con el valor anterior, el nuevo y de dónde salió el dato (padrón importado, padrón online, alícuota default, carga manual, importación de solicitudes o actualización masiva). Permite responder "¿qué alícuota de IIBB tenía este cliente, quién se la cambió y con qué fuente?".

El acceso suele requerir permisos que deben solicitarse al administrador del sistema.

Al abrir, el rango de fecha se inicializa al día actual (desde = hasta = hoy) y el tipo de log en "Todos". Se carga la grilla con las operaciones del rango/tipo, ordenadas de la más reciente a la más antigua.

El tipo de log se elige de una lista que corresponde al enum Tipo_Log (Asientos, Parámetros, Clientes, Crédito, Cierre, Factoring, Transferencias, Tickets, etc.). "Todos" (valor 0) no filtra por tipo.

Para auditar las fichas maestras, los tipos a elegir son:

El tipo Clientes_LimitesDeCredito es distinto: registra el alta de los límites de crédito del cliente, no los cambios de la ficha.

Para auditar las alícuotas de percepción de los clientes, elegí el tipo Clientes_Percepciones (ver la sección siguiente).

Tipo Clientes_Percepciones: alícuotas de percepción de clientes

Cada registro corresponde a una alícuota de percepción de un cliente (un impuesto y una provincia) que se dio de alta, se modificó o se dio de baja. El Tipo_Log_Id es el Id del cliente, así que filtrando por esa columna se ve toda la historia de percepciones de un cliente.

Ejemplos de Descripcion:

• Cambio de alícuota: IIBB - Buenos Aires: 1,50 % -> 3,00 % | Origen: …
• Alta: IIBB - Buenos Aires: 1,00 % (activa) | Origen: … o (inactiva).
• Baja: IIBB - Buenos Aires: 1,00 % dada de baja | Origen: …
• Sólo cambia el estado: IIBB - Buenos Aires: 1,00 % | se desactiva | Origen: … o | se activa.
• Grabación fallida: se agrega al final | Error: ….

Una grabación sin cambios reales (misma alícuota y mismo estado activo/inactivo) no se registra.

Origen del dato (texto que aparece después de "Origen:" en la descripción y en el detalle):

Cambio respecto de versiones anteriores: la actualización masiva online de percepciones de clientes ya no se registra bajo el tipo InfoAPI sino bajo Clientes_Percepciones. Las retenciones de proveedores actualizadas desde InfoAPI siguen registrándose bajo InfoAPI.

La grilla muestra una fila por operación auditada:

Es una pantalla de consulta y auditoría: no edita los registros.

Ventana de Detalle

El detalle muestra el objeto serializado de la operación:

• Para tipos normales: el JSON se presenta en una grilla vertical (clave/valor) con el título del Origen.
• Para Cierre de día automático (Tipo_Log = 13): se muestra el desglose del proceso (código de proceso, inicio, fin, resultado, tiempo transcurrido) en una grilla, con las filas expandidas.

• Para la modificación de una ficha maestra (Clientes, Proveedores, Inversores): se muestra la lista de campos que cambiaron, con tres datos por campo — Propiedad (el nombre del campo, en castellano: "Límite de crédito", "Teléfono", "Condición de IVA"), Anterior (el valor que tenía) y Nuevo (el valor que quedó). Si en el guardado no cambió ningún campo, no se genera registro.

• Para Clientes_Percepciones: se muestra el registro de la alícuota con los campos Id_Cliente, Id_Clientes_Percepciones, Accion, Tipo_Impuesto, Provincia, Alicuota_Anterior, Alicuota_Nueva, Activa_Anterior, Activa_Nueva y Origen. En un alta, los valores "Anterior" quedan vacíos.

En el alta y en la baja/reactivación de una ficha el detalle es más breve: deja constancia del usuario y del identificador de la ficha, porque los datos completos ya están en la propia ficha. El detalle campo por campo aplica solo a las modificaciones.

Un cliente reclama que le cambiaron el límite de crédito y hay que averiguar quién fue y qué valor tenía antes:

1. Herramientas → Log de Auditorías.
2. Ajustar el rango de fecha al período en que pudo haber ocurrido (por defecto viene el día de hoy).
3. En Tipo Log, elegir "Clientes". Buscar.
4. Ubicar el registro por Tipo_Log_Id (id del cliente); la columna Destino dirá "Modificar". Revisar Id_User_Add (quién) y Fecha_Add (cuándo).
5. Doble clic sobre la fila: el detalle lista los campos que cambiaron en ese guardado. Buscar la fila "Límite de crédito" y leer Anterior y Nuevo.
6. (Opcional) Exportar PDF/XLS desde el detalle para adjuntar a un ticket.

Si en el paso 4 el Destino dice "Nuevo", ese registro es el alta de la ficha, no una modificación. Y si dice "Eliminar" o "Reactivar", corresponde a la baja o la reactivación del cliente.

Caso: averiguar de dónde salió la alícuota de IIBB de un cliente.

1. Herramientas → Log de Auditorías, rango de fecha amplio y Tipo Log = "Clientes_Percepciones". Buscar.
2. Filtrar la columna Tipo_Log_Id por el Id del cliente.
3. Leer la Descripcion de cada registro: muestra la alícuota anterior y la nueva (por ejemplo IIBB - Buenos Aires: 1,50 % -> 3,00 %) y el Origen del dato (padrón importado con su vigencia, padrón online, alícuota default, carga manual, importación o actualización masiva).
4. Id_User_Add y Fecha_Add indican quién y cuándo. Con doble clic se ve el detalle completo (anterior/nuevo, estado activo y origen).

• El rango arranca en hoy: si buscás una operación vieja, ampliá el rango de fecha antes de Buscar.
• Acotá por Tipo Log para no recorrer todos los tipos cuando ya sabés qué operación buscás.
• Usá Tipo_Log_Id para encontrar el log de un registro concreto (por ejemplo, el id del crédito o del cliente).
• El doble clic es la forma de abrir el detalle; desde ahí exportás a PDF/Excel para evidencia.
• En las fichas maestras, la columna Destino te dice de una si el registro es un alta ("Nuevo"), una modificación ("Modificar"), una baja ("Eliminar") o una reactivación ("Reactivar"). Filtrando por esa columna aislás rápido lo que buscás.
• Si una ficha se guardó sin cambiar nada, no vas a encontrar un registro: la modificación solo se audita cuando algún campo cambió realmente.
• Para seguir la historia de percepciones de un cliente, usá el tipo Clientes_Percepciones y filtrá Tipo_Log_Id por el Id del cliente. Si buscás una actualización masiva online de percepciones anterior a este cambio, esos registros viejos están bajo el tipo InfoAPI.

El formulario FormPlenarioAuditoriasLog no ejecuta validaciones IsAllowedObject en su código: la búsqueda y el detalle se ejecutan directamente. El control de acceso se da por la visibilidad de la opción en el menú.

Basada en el análisis del formulario real de la v14.

Formularios principales

Formularios que generan la auditoría de fichas maestras

Las bajas de las tres fichas son lógicas (marcan el registro como eliminado), no borrados físicos; por eso existe la operación inversa "Reactivar".

Cómo se arma el detalle campo por campo

Al abrir la ficha para editar se toma una copia de los valores previos. Después de guardar con éxito, se comparan los campos uno a uno y se serializa en Objeto_Serializado solo la lista de los que cambiaron, con la forma Propiedad / Anterior / Nuevo. Si la lista queda vacía no se graba nada.

La lista de campos a comparar es explícita en cada formulario: al agregar un campo nuevo a una ficha hay que sumarlo también a esa lista, o el campo no se auditará (y no habrá ningún error que lo advierta).

La auditoría corre dentro de un Try/Catch propio que deriva a Functions.LogError: si algo fallara al registrar, no interrumpe ni revierte el guardado de la ficha.

Permisos reales

Tablas de base de datos principales

Relación con otros módulos / manuales

Notas para soporte

• El filtro de la consulta es: Tipo_Log (0 = Todos) y rango de Fecha_Add desde/hasta; orden descendente por Fecha_Add.
• Los tipos provienen del enum Tipo_Log del manager (1=Asientos, 3=Clientes, 4=Crédito, 10=Cierre, 11=Factoring, 13=Cierre_Dia_Automatico, 18=Transferencias, 26=Tickets, 33=LogError, 41=Clientes_LimitesDeCredito, 42=Inversores, 43=Proveedores, 45=Clientes_Percepciones, etc.).
• El detalle campo por campo de las fichas se serializa con Save_Plenario_Operaciones_Log1Async, pasando la lista de diferencias como modelo; no usa Save_Plenario_Operaciones_Log_ByIdAsync, así que no depende del switch de Get_Object_ById.
• En estos registros, la acción va en Destino ("Nuevo" / "Modificar" / "Eliminar" / "Reactivar") y el identificador de la ficha en Tipo_Log_Id. El Origen lleva el módulo ("Clientes", "Proveedores", "Prov. Financiero").
• Auditoría de fichas incorporada en los changesets 23505 (Prov. Financiero), 23506 (Proveedores) y 23556 (Clientes).
• El tipo 41 (Clientes_LimitesDeCredito) lo genera SaveLimites() en frmClientes_AddMod.vb y es independiente de la auditoría de la ficha: registra el alta del límite de crédito inicial del cliente.
• Tipo 45 Clientes_Percepciones (CS 23692, Ticket#117048). Lo registra clsClientes_percepciones (ClassVisualPlenarioNET\Common\clsClientes_percepciones.vb) al grabar (Alta/Modificación) y al eliminar (Baja), con Save_Plenario_Operaciones_Log1Async(Tipo_Log.Clientes_Percepciones, modelo, "Alícuotas de percepción del cliente", ok, Id_Cliente, accion, descripcion). El modelo serializado es Auditoria_Clientes_Percepciones (Id_Cliente, Id_Clientes_Percepciones, Accion, Tipo_Impuesto, Provincia, Alicuota_Anterior, Alicuota_Nueva, Activa_Anterior, Activa_Nueva, Origen). El origen lo informa quien graba en la propiedad Origen_Auditoria ("Sin especificar" si no se informa). Si la modificación no cambia Id_Percepciones_Alicuotas ni Is_Percepcion_Activa, no se registra. La auditoría va en un Try/Catch propio y nunca interrumpe la grabación. La actualización masiva por padrón (clsPagoFacil.Actualizacion_Alic_Percepcion_IIBB) no pasa por la clase: captura el antes/después con OUTPUT … INTO @Cambios y hace un INSERT INTO Plenario_Operaciones_Log en el mismo SQL, sólo para altas y cambios de alícuota; si ese insert falla no revierte la actualización. La masiva online de clientes (Actualizacion_Online_Alic_Percepcion_IIBB) dejó de usar Tipo_Log.InfoAPI; las retenciones de proveedores lo siguen usando.
• El detalle parsea Objeto_Serializado: con GetDetalle (JsonDataSource clave/valor) para casos normales, y con GetDetalleCierre (lista de Proceso) cuando Tipo_Log == 13.
• El título de diseño del form es "Registro de auditoria"; el caption funcional/menú es "Log de Auditorías". Verificar contra el binario instalado ante diferencias.