Historial y audit trail del documento
Todo lo que ocurre con un documento queda registrado permanentemente. Esta página explica cómo leer el historial, qué significa cada evento y cómo exportarlo.
ALCOA+ — Contemporaneous, Attributable, Legible. El audit trail es append-only: ningún evento puede modificarse ni eliminarse una vez registrado. Cada entrada tiene timestamp UTC del servidor, usuario, acción y valores antes/después.
¿Qué registra el audit trail?
El historial captura automáticamente cada acción significativa sobre el documento, incluyendo:
- Creación del documento, de cada versión y de cada anexo
- Cada transición de estado (borrador → revisión → aprobado → vigente → obsoleto)
- Subida o reemplazo del archivo fuente
- Cambios en el schema de formulario (IDT)
- Vínculos de relación y vínculos a Change Controls
- Generación del PDF sellado y del template.docx
- Obsoletización explícita y obsoletización automática al efectivizar una nueva versión
Cómo leer el historial
El historial en la pestaña Historial del panel de detalle muestra los eventos de la versión actual, agrupados por día. Cada entrada tiene:
| Columna | Descripción |
|---|---|
| Fecha y hora | Timestamp en zona horaria argentina (ART). El sistema almacena en UTC y convierte para mostrar. |
| Usuario | Email del actor que ejecutó la acción. |
| Acción | Nombre del evento en formato legible (ver tabla de eventos abajo). |
| Comentario | La justificación regulatoria ingresada por el usuario en la firma, si aplica. |
El historial se muestra paginado de a 50 eventos, con controles de paginación para recorrer el resto. Para el historial completo de todos los documentos, usá el módulo Audit Trail bajo Admin.
Tipos de eventos más frecuentes
| Evento | ¿Qué significa? |
|---|---|
document:created | Se creó el documento y su primera versión en borrador. |
document:annex_created | Se creó un anexo del documento (se suma al bundle). |
document:legacy_annex_created | Se registró un anexo legacy (migrado, pre-eQMS). |
document:file_updated | Se adjuntó o reemplazó el archivo fuente. |
document:submitted_for_review | El documento fue enviado a revisión (borrador → en revisión). |
document:review_rejected | El revisor rechazó la revisión y devolvió a borrador. |
document:review_approved | El revisor aprobó (en revisión → revisado). |
document:approval_rejected | Se rechazó una instancia de aprobación (la versión volvió a un estado anterior). |
document:sector_approved | El aprobador de sector aprobó formalmente (revisado → en entrenamiento). |
document:sector_rejected | El aprobador de sector rechazó y devolvió a borrador. |
document:sector_rejected_to_review | El aprobador de sector devolvió al revisor (revisado → en revisión). |
document:effectivized | El documento fue efectivizado (en entrenamiento → vigente). Se generó el PDF sellado. |
document:auto_obsoleted | Esta versión fue reemplazada automáticamente por una nueva versión vigente. |
document:obsoleted | El documento fue obsoletizado explícitamente (vigente → obsoleto). |
document:link_cc | Se vinculó un Change Control al documento. |
document:new_version_started | Se inició una nueva versión (v2.0, v3.0, etc.) en borrador. |
cdms:new_version_cc_created | Se generó automáticamente un Change Control al iniciar una nueva versión. |
Ver el detalle de un evento
Hacé clic en cualquier fila del historial para abrir el detalle del evento. Muestra:
- Comentario regulado — la justificación de la firma, destacada visualmente
- Antes / después —
old_valueynew_valueen formato JSON user_email— el email del actor que ejecutó la acciónclient_ip— la IP del cliente desde donde se ejecutó- Metadata — información adicional como el ID de aprobación, hash del PDF o prefijo del token de firma
En el campo new_value del evento document:effectivized podés encontrar el pdf_hash (SHA-256) del PDF sellado. Este hash permite verificar criptográficamente que el PDF descargado es idéntico al original almacenado.
Exportar el historial a PDF
El historial ofrece dos reportes en PDF:
- PDF por versión — el botón de impresora genera un PDF A4 del audit trail de la versión actual, con encabezado (código, título, versión, área), la tabla de eventos y la fecha de generación.
- Botón "Versiones" — genera un reporte consolidado del ciclo completo del documento, de la v1.0 a la vN, útil para reconstruir toda la historia del documento en un solo PDF.
Ambos son reportes de solo lectura, útiles para auditorías externas o para compartir el historial con terceros sin acceso al sistema.
El PDF exportado no tiene valor regulatorio propio — es una representación de los datos en el sistema al momento de la exportación. El audit trail oficial y de referencia es siempre el que está en la base de datos del sistema.
Audit trail del módulo CDMS
La vista Audit Trail CDMS (accesible desde el menú lateral bajo CDMS) muestra el historial completo de todos los documentos del módulo, no solo de uno en particular. Tiene filtros por:
- Tipo de evento (acción)
- Usuario
- Rango de fechas
- Documento específico
Esta vista es la fuente principal para revisiones periódicas del sistema y auditorías internas. Los administradores y el equipo de Calidad la usan para verificar el cumplimiento de los procesos regulados.
Preguntas frecuentes
No. El audit trail es append-only y está protegido a nivel de base de datos. No existe ninguna función en el sistema que permita modificar o eliminar registros del historial. Esto es un requisito de 21 CFR Parte 11.
El sistema almacena todos los timestamps en UTC (hora universal). La vista en pantalla los convierte a ART (UTC-3 / UTC-2 en verano) para facilitar la lectura. El PDF exportado también muestra ART. En auditorías internacionales, referenciá siempre el valor UTC.
document:auto_obsoleted en mi documento?›Porque se efectivizó una nueva versión del mismo documento. El sistema obsoletiza automáticamente la versión anterior al activar la nueva. Este evento no requiere ninguna acción de tu parte. Si en cambio ves document:obsoleted, el documento fue obsoletizado explícitamente con el botón "Obsoletizar".
Guarda el prefijo del token de reautenticación (los primeros caracteres, no el token completo), el tipo de firma, el ID del registro de aprobación y la IP del cliente. Esto permite correlacionar el evento con el registro de aprobación correspondiente en una auditoría.