Panel de detalle del bundle CTR
Al seleccionar un bundle en la lista, el panel derecho muestra todos los protocolos, el estado de firmas, las acciones disponibles y el historial del bundle.
Header del bundle
El header muestra los datos de identificación del bundle: código, cliente, descripción del equipo, email del técnico, ID del protocolo ITS Lab, orden de trabajo y tipo de servicio. También muestra el estado actual y el contador de protocolos completados.
Los botones del header son:
- ↓ ITS Lab — ejecuta un pull de datos desde ITS Lab para actualizar equipos, estándares y solventes en todos los protocolos. Solo visible cuando el bundle no está cerrado.
- ↻ — recarga los datos del bundle desde el servidor sin navegar fuera del panel.
- ? — abre la ayuda contextual de esta pantalla.
- Cerrar — cierra el panel de detalle.
Los botones de PDF (👁 Ver borrador y Descargar PDF) no están en el header: aparecen en la fila de acciones del bundle, junto con las firmas. Ver Ver y descargar PDF.
Panel de firmas
Muestra el estado de las dos firmas reguladas del bundle:
| Firma | Rol | Estado | Qué muestra cuando está firmado |
|---|---|---|---|
| Técnico responsable | Técnico asignado o Admin | Pendiente / ✓ Firmado | Email del firmante y timestamp en ART |
| Verificador QA | Admin/QA (≠ técnico) | Pendiente / ✓ Firmado | Email del firmante y timestamp en ART |
Separación de funciones. El verificador no puede ser la misma persona que firmó como técnico. El sistema lo bloquea y no muestra el botón de firma al técnico que ya firmó en ese rol.
Todas las acciones disponibles
Acciones sobre el bundle (fila de acciones)
| Acción (label en la UI) | De → A / Estado | Endpoint | Quién puede | Firma | Condiciones |
|---|---|---|---|---|---|
| Firmar como técnico | En ejecución → Pend. revisión | POST /ctr/{id}/sign/technician |
Técnico asignado o Admin (ctr.bundle.execute) | 🔐 Reauth + motivo ≥15 | Todos los protocolos Completados o No ejecutados. Si falta alguno, el botón dice "Completar protocolos primero". |
| Firmar como verificador | Pend. revisión → Cerrado | POST /ctr/{id}/sign/verifier |
Admin/QA ≠ técnico (segregación) | 🔐 Reauth | Cierra definitivamente · crea el evento QEM automático si hay discrepancias · notifica el cierre a ITS Lab |
| Retirar firma | → En ejecución | POST /ctr/{id}/withdraw |
Técnico / QA / Admin | 🔐 Reauth | Requiere ≥1 firma activa · la firma no se borra: queda marcada como retirada (registro append-only) |
| 🔓 Reabrir bundle | Cerrado → En ejecución | POST /ctr/{id}/reopen |
Admin/QA (ctr.bundle.reopen) | 🔐 Reauth + motivo ≥15 | Ver Reabrir bundle cerrado · bloqueado si el servicio en ITS Lab está Finalizado/Cancelado |
| 👁 Ver borrador | En ejecución / Pend. revisión | — | Usuarios con acceso al bundle | No | Vista previa del PDF con marca de agua BORRADOR |
| Descargar PDF | Solo Cerrado | — | Usuarios con acceso al bundle | No | Modal con selector de carátula y variante Cliente / Interno · "Forzar regeneración" solo Admin/QA |
| + Agregar IDT al bundle | En ejecución | — | Usuarios con acceso al bundle | No | Incorpora un nuevo protocolo; los datos preexistentes se mantienen |
| 🎓 Seleccionar cert TMS | En ejecución / Pend. revisión | — | Usuarios con acceso al bundle | No | Certificados del técnico del bundle · ver Certificado TMS |
Acciones por protocolo
| Acción (label en la UI) | Disponible en | Endpoint | Firma | Condiciones |
|---|---|---|---|---|
| 📎 Rawdata | En ejecución | — | Operativa (borrado con motivo) | Subida múltiple con hash SHA-256, reorden ▲▼, borrado con motivo · inmutable tras la firma del técnico |
| Cambiar (reemplazar IDT) | En ejecución | — | No | Deshabilitado si el protocolo está Completado o No ejecutado |
| Quitar | En ejecución | — | No | Deshabilitado si el protocolo está Completado o No ejecutado |
| No ejecutado | En ejecución | — | Justificación ≥15 caracteres | El protocolo cuenta como completo a efectos de la firma del técnico |
| 🔓 Reabrir (protocolo) | Protocolo Completado | POST /ctr/{id}/protocols/{pid}/reopen | 🔐 Reauth | Solo si el bundle aún no tiene firma de técnico · el protocolo vuelve a En curso para corregirlo sin reabrir todo el bundle |
El botón "Firmar como técnico" aparece deshabilitado si no todos los protocolos están Completados o No ejecutados. El texto del botón cambia a "Completar protocolos primero" para indicar qué falta.
Alerta de certificado TMS faltante. Si el bundle no tiene un certificado TMS vinculado, el panel muestra un banner de alerta. Seleccioná el certificado del técnico antes de cerrar el bundle para que aparezca en la sección CERTIFICADOS del PDF cliente.
Pull de datos de ITS Lab
El botón ↓ ITS Lab del header actualiza los datos precargados en todos los protocolos del bundle consultando la API de ITS Lab en tiempo real. Esto actualiza:
- Datos de equipos: marca, modelo, número de serie, ID interno, ubicación
- Datos de estándares y solventes del catálogo
- Número de orden de trabajo asociada
El header muestra la fecha y hora del último pull exitoso. Si el bundle nunca tuvo un pull, aparece "Aún no se realizó un pull de ITS Lab". El botón desaparece cuando el bundle está cerrado.
Certificado TMS
El panel 🎓 Seleccionar cert TMS aparece cuando el bundle está en En ejecución o Pendiente revisión. Permite vincular el certificado de competencia del técnico al bundle para evidenciar que estaba habilitado para ejecutar los protocolos.
Hacé clic en el botón correspondiente en la fila de acciones.
El panel lista los certificados TMS del técnico del bundle (consulta GET /tms/users/{technician_id}/certificates). Por defecto el sistema usa el más reciente; podés elegir otro.
El certificado elegido queda vinculado al bundle y se incluye en la sección CERTIFICADOS del PDF cliente.
Si el técnico no tiene certificado vinculado, el panel muestra un banner de alerta de certificado TMS faltante.
Ejecutar un protocolo IDT
Cada protocolo IDT del bundle se muestra como una sección expandible. Dentro encontrás el formulario con todos los campos definidos en el Form Builder de ese IDT:
- Campos precargados desde ITS Lab: equipos, estándares, solventes — verificá que los valores sean correctos antes de continuar
- Campos manuales: resultados de medición, temperaturas, masas, observaciones — ingresalos y presioná Guardar
- Puntos de firma (
signature_point): campos que requieren firma electrónica individual, con reautenticación por cada campo firmado - Cuando terminaste, usá el botón "Marcar protocolo como completado" — con todos los protocolos Completados (o No ejecutados) se habilita la firma del técnico
Gestión de rawdata
Para cada protocolo podés adjuntar los archivos de datos crudos del instrumento: cromatogramas, espectros, impresiones de calibración, capturas de pantalla del instrumento, etc.
Subir rawdata
Hacé clic en el botón 📎 Rawdata dentro del protocolo. Podés seleccionar múltiples archivos a la vez. Cada archivo se sube con su hash SHA-256 de integridad y aparece en la lista del protocolo al completarse el upload.
Reordenar rawdata
Usá los botones ▲ / ▼ junto a cada archivo para cambiar su orden. El orden determina cómo aparecen en el informe final.
Eliminar rawdata
El ícono de papelera elimina el archivo. Esta acción requiere ingresar un comentario de motivo y queda registrada en el audit trail.
Una vez que el técnico firmó el bundle, los rawdata quedan inmutables. No podés agregar, reordenar ni eliminar archivos después de la firma. Si hay un error, hay que retirar la firma (o reabrir el bundle si ya está cerrado).
Agregar, cambiar o quitar IDTs del bundle
Mientras el bundle está En ejecución:
- + Agregar IDT al bundle (fila de acciones): incorpora un nuevo protocolo. Los datos preexistentes se mantienen.
- Cambiar (en cada protocolo): reemplaza el IDT del protocolo por otro (por ejemplo si se usó la versión incorrecta).
- Quitar (en cada protocolo): elimina el protocolo del bundle.
Cambiar y Quitar se deshabilitan cuando el protocolo está Completado o marcado como No ejecutado. Para modificarlo, primero reabrí el protocolo (🔓, solo posible si el bundle no tiene firma de técnico).
Discrepancias y creación automática de eventos QEM
El CTR está integrado con el módulo QEM mediante el flujo WF-CTR-QEM:
- Al completar un protocolo: si el formulario contiene resultados con valor "No Cumple" / FAIL / DEV / desviación, se abre un modal que sugiere crear una discrepancia QEM. Si aceptás, la discrepancia se crea en la misma transacción que la completitud del protocolo.
- Al cerrar el bundle (firma del verificador): el sistema vuelve a detectar discrepancias en los resultados y crea el evento QEM automático correspondiente.
Trazabilidad de desvíos. Ningún resultado fuera de especificación queda sin evento de calidad asociado: la detección corre tanto al completar cada protocolo como al cierre del bundle.
Takeover: continuar el bundle de otro técnico
Si un Admin o QA continúa, completa o firma un bundle asignado a otro técnico, el sistema aplica un takeover:
- El bundle se reasigna al actor como técnico del bundle.
- La reasignación queda registrada en el audit trail como
ctr:bundle_takeover. - La carátula del PDF muestra como "Técnico ejecutor" a quien realmente ejecutó — no a quien creó el bundle.
La segregación de funciones sigue vigente después de un takeover: quien quedó como técnico ejecutor no puede firmar como verificador de ese bundle.
Ver y descargar el PDF del bundle
Las dos acciones de PDF están en la fila de acciones del bundle:
- 👁 Ver borrador (En ejecución / Pendiente revisión): genera una vista previa del PDF con marca de agua BORRADOR, útil para verificar el contenido antes de firmar.
- Descargar PDF (solo Cerrado): abre un modal donde elegís:
- Carátula: seleccionada automáticamente según la matriz Carátulas↔IDTs, o elegida manualmente.
- Variante: Cliente o Interno — la descarga de la variante interna queda registrada en el audit trail.
- Forzar regeneración: checkbox visible solo para Admin/QA, que regenera el PDF en lugar de servir el ya generado.
El PDF sellado incluye:
- Carátula regulatoria con código del bundle, cliente, equipo, datos del servicio, fecha de creación del bundle y el técnico ejecutor real
- Tabla de firmas con nombre, rol, timestamp y prefijo del token de reautenticación
- Todos los campos completados de cada protocolo, organizados por sección — los valores marcados N/A en equipos/estándares se vuelcan como "N/A" en la celda correspondiente de la grilla
- Sección CERTIFICADOS: certificados tomados de un snapshot de ITS Lab con deduplicación, más el certificado TMS seleccionado (variante cliente)
- Lista de rawdata adjunto con nombre de archivo y hash de integridad
Reabrir un bundle cerrado
En casos excepcionales (error en los datos, rawdata faltante, protocolo incorrecto), Admin/QA (permiso ctr.bundle.reopen) pueden reabrir un bundle ya cerrado con 🔓 Reabrir bundle. Esta acción:
- Requiere reautenticación y un motivo de mínimo 15 caracteres
- Retira todas las firmas existentes (técnico y verificador) — las firmas no se eliminan, quedan en el registro como retiradas
- Resetea los protocolos Completados → En curso y limpia las firmas de los puntos de firma (
signature_point) - Revoca los tokens de descarga de PDF emitidos
- Devuelve el bundle a En ejecución para un nuevo ciclo de firmas; el motivo queda en el audit trail
Bloqueo por estado del servicio. La reapertura se bloquea si el servicio asociado en ITS Lab está Finalizado o Cancelado.
ALCOA+ — Legible, permanente. Las firmas retiradas quedan en el historial del bundle con el estado "Firma retirada" y el motivo registrado. No se puede eliminar un registro de firma, solo marcarlo como retirado.
¿Solo necesitás corregir un protocolo? Si el bundle todavía no tiene firma de técnico, usá 🔓 Reabrir sobre el protocolo Completado (con reautenticación): vuelve a En curso sin tocar el resto del bundle.
Preguntas frecuentes
Cuando se retira una firma (ya sea con "Retirar firma" o por reapertura del bundle), la firma original no se borra — queda en el registro marcada como retirada, con el email del firmante y el motivo. El panel de firmas muestra el estado actual (Pendiente) pero podés ver el historial completo en el audit trail del bundle.
Completar los campos no alcanza: tenés que presionar el botón "Marcar protocolo como completado" dentro del protocolo. Verificá además que no queden campos obligatorios sin valor ni puntos de firma pendientes en secciones colapsadas.
El pull actualiza los campos de tipo equipment, standard y solvent que se precargan automáticamente. Los campos de tipo text, number, textarea y date que ingresaste manualmente no se modifican.
Sí. Un protocolo marcado como "No ejecutado" (con justificación de mínimo 15 caracteres) cuenta como "completo" a efectos del bundle — permite que el técnico firme aunque ese protocolo no tenga datos. El motivo de no ejecución queda registrado en el informe final.
Es el comportamiento de takeover: cuando un Admin/QA continúa, completa o firma un bundle de otro técnico, el bundle se reasigna a quien realmente ejecutó, la reasignación queda en el audit trail (ctr:bundle_takeover) y la carátula del PDF muestra "Técnico ejecutor" con ese usuario.