El viaje de un siniestro,
de la denuncia al pago.

Qué es el sistema

Un banco presta plata. El deudor firma un seguro de desgravamen. Si muere o queda inválido, el seguro paga la deuda — y este sistema gestiona todo ese proceso.

Los bancos aliados (Banco Sol, Banco Fie, Banco Ecofuturo y Banco Estatal) envían periódicamente planillas Excel con las denuncias de siniestros de sus deudores. El sistema las carga masivamente, crea un caso por cada denuncia y lo asigna a un analista (round-robin). A partir de ahí el caso recorre un flujo de etapas: análisis documental asistido por OCR, gestión médica cuando hace falta, pronunciamiento (aprobar o rechazar), aceptación del banco tomador, tesorería (pago) y cierre.

En el camino, el sistema crea el siniestro en SISE (el core asegurador de Mapfre), genera cartas y documentos PDF, y mantiene la trazabilidad completa en un historial de 7 etapas por caso.

Arquitectura

Dos repositorios propios, tres sistemas externos y un pipeline de OCR.

Roles y usuarios

Cuatro roles operativos. El JWT lleva UN solo rol; el guard del front cierra la sesión si el rol intenta entrar a una ruta ajena.

Usuarios del ambiente QA (snapshot de producción)

El flujo del siniestro

Ocho etapas (ClaimState) y veinte estados finos (ClaimStatus). Las transiciones viven como guardas en el agregado Claim del dominio; la UI las dispara con acciones dinámicas que el propio backend decide por caso.

Atajos reales del flujo: FreeCover salta la Gestión Médica · un caso Rechazado cuya carta el tomador acepta va directo a Cierre (no pasa por Tesorería) · Recalculation devuelve un caso hacia atrás para recalcular.

Cómo nace un caso

El banco envía su planilla Excel. El analista la sube en Ingresar denuncia (chip "Carga masiva" — la carga individual fue eliminada del producto). El backend la parsea con un mapper específico por banco (ExcelMapperFactory), crea InsuranceFileHeader/Record y por cada fila un Claim con su TechnicalSheet y ClaimAnalysisData, en etapa Clasificación y análisis, status Assignated, repartido round-robin entre los analistas del banco. En paralelo, el pipeline vision-gpt hace OCR de los documentos escaneados y puebla los atributos que el analista después verifica en pantalla.

El análisis documental (gestion-page)

Es la pantalla data-driven del analista: renderiza un panel por documento del caso (Certificado de Defunción, Cédula, Hoja de Riesgo…), y dentro, un campo por cada DocumentField definido en la base — el orden lo decide DisplayOrder (del back) y las etiquetas se traducen por banco vía i18n (documentAttributes.{DocumentType}-{FieldName}). Los campos DataType = "select" se vuelven combos: Causa→Cobertura y País→Provincia (encadenados; el municipio lo auto-resuelve el back). Guardar y continuar persiste parcial (y recarga la página); Aprobar ejecuta el análisis y mueve el caso a En proceso.

Las acciones son del backend, no del front

Cada fila de la bandeja trae del backend su lista actions[] según el estado del caso (statementapproved, statementrejected, generaterejectionletter, reassign, view, delete, sendtosise…). El front solo las mapea a íconos con tooltip. Por eso dos casos de la misma bandeja pueden mostrar acciones distintas — y por eso las pruebas E2E localizan las acciones por su tooltip.

Gestión médica

Si el caso lo requiere (y no es FreeCover), el analista lo envía al médico (endpoint con typo real: PUT /{claimId}/medicalMamagement/user/{userId}). El médico ve su propia bandeja con estados MedicalEvaluation, MedicalInformationRequest y AdditionalMedicalInformation; emite el informe médico (PDF generado desde plantilla AcroForm), pide documentación adicional o devuelve el caso ("Devuelto por Médico"). El campo información adicional del pedido está acotado a 100 caracteres, validados en el handler del backend además del corte del formulario (#1275). La decisión final sigue siendo del analista.

Pronunciamiento, aceptación y tesorería

El analista aprueba o rechaza el pronunciamiento por caso. Los casos pronunciados se agrupan en lotes del mismo banco que van a Aceptación del tomador; ahí se aprueban o rechazan por caso. Los aceptados llegan a Tesorería, donde conviven dos agrupaciones distintas: "Agrupar para tesorería" (grupo de pago interno: Creado → En Tesorería → Pagado/Rechazado, con numeración tipo 001/2024) y "Agrupar liquidación" (solicitud masiva de pago a SISE). El tesorero registra el pago adjuntando uno o varios comprobantes en la misma operación (#1273/#1278; el historial registra un solo evento por caso, no uno por archivo), y el cierre del grupo lleva cada caso a Cierre — propagando el flag real de beneficiario adicional del caso (#1294).

Integración SISE

SISE es el core asegurador de Mapfre: el siniestro "oficial" vive ahí. DHLBC le crea el siniestro, el sub-siniestro y las solicitudes de pago.

• Crear siniestro — POST /api/v1/app/Claims/Sise/CreateClaim/{claimId}. Se dispara con la acción sendtosise, visible en la bandeja En proceso solo si SiseCreationStatus ∈ {Pending, Failed}. Consulta la póliza (número de riesgo, moneda), aplica la regla de fecha según el largo de la póliza y manda el payload snake_case — incluidos cod_pais_ocurrencia, cod_pcia_ocurrencia y cod_municipio_ocurrencia (el municipio se auto-resuelve desde la provincia elegida en el análisis). En txt_responsable viaja el usuario SISE del analista responsable (User.SiseUserName, columna agregada en 2026-07; #1304): si el responsable no lo tiene configurado, la creación falla con error explícito — no hay fallback al UserName ni envío vacío. Estados: Pending → SuccessfulFromApp / SuccessfulManual / Failed.
• Sub-siniestro — si el Excel del banco marcó beneficiario adicional (HasAdditionalBeneficiary), tras crear el siniestro se intenta crear el sub-siniestro (montos Sepelio/PAPIT desde BranchPolicy) y se persiste su carátula PDF como documento del caso. No es bloqueante: si falla, el siniestro principal queda creado.
• Solicitud de pago / liquidación masiva — desde Tesorería, por caso o en bloque (CreateBulkPaymentRequest). La liquidación masiva no exige mismo banco, pero sí estado Liquidado.

Pantallas

Capturas reales del ambiente QA (2026-07-11), con la base migrada y datos de producción.

Otras pantallas documentadas en detalle en agentes/05-pantallas-front.md: pronunciamiento (lotes), aceptacion-page, tesorery-home-page (grupos, registro de pago), medical-home-page, admin-home-page (usuarios), reportes del supervisor, configuración (FreeCover, motivos), ingresar-denuncia (carga masiva con dropzone) y repositorio de casos.

El ambiente QA hoy

URL: https://dhdesa.lbc.bo/LBC/Aplicaciones/DHLbc/#/ (requiere VPN de LBC). Base LBCDEV reconstruida el 2026-07-11: snapshot de producción del 30/12/2025 + pase consolidado del WI #1229.

Casos por etapa (1.157 casos reales)

Bancos y parámetros

Las 82 BranchPolicy (53 + 21 + 8) son la configuración por póliza: banco, ramo, moneda, cartera, sepelio, PAPIT y tipo de pago (Parcial / Final). Ese último dato es clave y se malinterpreta seguido: el tipo_pago que viaja a SISE no se calcula por montos ni es un input del endpoint — es un atributo de la BranchPolicy (clave: banco + número de póliza SISE) que se copia a ClaimAnalysisData.PolicyholderPayment al crear el caso.

Qué agregó el pase #1229

• 8 tablas nuevas: Country (12), Province (10), Municipality (10), Branch (2), Cause (33), Coverage (50), BranchPolicy (82), ParameterCatalog (4).
• 21 columnas nuevas con backfill — las críticas: Claim.ResponsibleId (visible como "Analista responsable") y ClaimAnalysisData.BranchCode/Portfolio (sin ellas, gestion-page queda EN BLANCO — el backfill matcheó 1.081/1.081).
• 12 DocumentField nuevos tipo select (Causa/Cobertura/País/Provincia) y DisplayOrder backfilleado para el orden de los planes de pago por banco.
• Reparación del drift histórico: 11 cambios de tipo, 58 índices, 4 FKs, 2 defaults.

Historia del producto

622 Work Items en 14 sprints, de julio 2024 a julio 2026. El sistema se construyó etapa por etapa, en el mismo orden del flujo.

Abiertos conocidos

Estados verificados contra Azure DevOps el 2026-07-29. Los que no figuran acá se cerraron.

Glosario esencial

Los términos mínimos para seguir una conversación del proyecto. El glosario completo (~80 términos) está en agentes/07-glosario.md.

Desgravamen

Seguro que paga el saldo de la deuda bancaria si el deudor muere o queda inválido. El beneficiario real es el banco.

Denuncia / Caso / Siniestro

La denuncia es el aviso del banco; el sistema la convierte en un caso (Claim); el siniestro es su representación oficial en SISE.

Tomador

El banco que contrató la póliza colectiva. "Aceptación del tomador" = el banco acepta el pronunciamiento.

Etapa vs. estado

Etapa = ClaimState (las 8 estaciones del riel). Estado = ClaimStatus (los 20 matices dentro de cada etapa, ej. Assignated, PendingPayment).

FreeCover

Umbral de monto por banco bajo el cual el caso es fast-track y salta la auditoría médica.

Pronunciamiento

La decisión formal del asegurador sobre el caso: aprobado o rechazado (con carta).

Lote / Agrupación

Conjunto de casos del mismo banco que avanzan juntos: lotes de pronunciamiento→aceptación, grupos de pago en tesorería, liquidaciones SISE.

Carátula

PDF resumen del sub-siniestro creado en SISE, persistido como documento del caso.

Slag

Clave {DocumentType}-{FieldName} que identifica un campo del análisis; se usa para etiquetas i18n por banco y como selector de pruebas (data-slag).

Acción dinámica

Acción por fila que decide el backend según el estado del caso (actions[]); el front solo la dibuja.

SISE

Core asegurador de Mapfre donde vive el siniestro oficial. DHLBC le crea siniestros, sub-siniestros y solicitudes de pago.

Pase

El paquete de cambios (SQL + binarios) que lleva un ambiente a la versión nueva. El pase consolidado actual es el WI #1229.

Cómo se prueba (E2E)

La guía operativa completa — paso a paso por rol, con selectores y asserts — está en agentes/08-guia-e2e-playwright.md. Esto es el mapa.

Las reglas de oro

• Sesión: vive en sessionStorage; el guard cierra la sesión si el rol entra a una ruta ajena (ej. Supervisor → /#/home-page). Navegar mutando location.hash, nunca con page.goto() a mitad de flujo.
• Datos: las bandejas muestran solo los casos del analista logueado — usar analista.extra4 (528 casos, Banco Sol). Aceptación tiene 0 casos: hay que empujar uno por el flujo.
• Descargas: la API SIEMPRE devuelve JSON base64; el evento download lo fabrica el front (waitForEvent('download') funciona).
• Timing: "Guardar y continuar" recarga la página (window.location.reload()); "Aprobar" tiene un delay artificial de 3s+2s antes del redirect.
• Textos exactos: los dialogs de confirmación tienen textos literales (con typos reales) — los asserts deben copiarlos tal cual.

Los 9 escenarios planificados