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

1Qué 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.

2Arquitectura

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

3Roles 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)

4El 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"). 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 con su comprobante, y el cierre del grupo lleva cada caso a Cierre.

5Integració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). 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.

6Pantallas

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.

7El 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

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.

8Historia 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.

9Glosario 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.

10Có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