Ciclo completo — Banco Fie
Un caso de Banco Fie recorrido de principio a fin: desde la planilla Excel que sube el banco hasta el cierre definitivo del caso, pasando por el analista y el tesorero. Se documenta cada bypass (SISE, SharePoint) y los valores que quedan en las tablas.
📁 Evidencias
Este flujo no descargó archivos. Sus 25 capturas están en la carpeta FB-FIE-ciclo-completo/; hacé clic en cualquiera para ampliarla.
⚠️ 2 hallazgo(s) en este flujo
Se marcó el siniestro como creado manualmente vía PUT /Claims/{id}/sise-number (SiseCreationStatus=SuccessfulManual), SIN llamar al SISE real de Mapfre ni a SharePoint. Es el mecanismo del propio producto para registrar un SISE creado a mano. Valor cargado en Claim: SiseNumber=2025-1286, InternalSiseId=INT-FIE-1286. HTTP 204. (paso 12)
send-to-treasury exige ≥1 archivo. Se generó un PDF mínimo de ejemplo en vez de un soporte real; se sube a SharePoint como cualquier adjunto. (paso 18)
Pantalla de login
Formulario de acceso: usuario y contraseña (se validan contra LDAP)
Login como andres.daleney
POST /v1/Authentication/login → HTTP 200. El backend valida contra LDAP y devuelve el JWT (un solo rol). Landing: /dashboard-page
Se prepara la planilla Excel de Banco Fie
Se genera el archivo que el banco enviaría: una fila con el asegurado «GOMEZ CICLOFIE MARIA» (CI 8811002), cobertura Muerte, póliza SISE 106884 (que debe existir como BranchPolicy, si no la carga se rechaza). Guardado en denuncia-FIE.xlsx. Formato exacto del mapper Banco Fie (26 columnas, fechas OADate, tabla de shared strings — sin ella el backend lee todo vacío).
Ir a «Ingreso de denuncias» desde el menú lateral
El Angular Router intercepta el click (el href del sidebar es path-based, no hash)
Pantalla de ingreso de denuncias
El analista elige el banco y arrastra la planilla. Es el punto de entrada de los casos al sistema (carga masiva).
El sistema creó el caso 1286 desde el Excel
POST /api/v1/app/File/upload → HTTP 200. Se creó el caso N° 1286 (id 01KXCQTS956MKPQPTY3JBDW91A), asegurado GOMEZ CICLOFIE MARIA, Banco Fie, tipo Muerte. Quedó en «Clasificación y análisis», asignado automáticamente por round-robin al analista del banco. Tablas: Claim + TechnicalSheet + ClaimAnalysisData + InsuranceFileHeader/Record + 2 filas en ClaimHistory (Created, StateChange).
Ir a «Mis casos» desde el menú lateral
El Angular Router intercepta el click (el href del sidebar es path-based, no hash)
El caso 1286 en la bandeja de análisis
El caso recién nacido aparece en «Clasificación y análisis», listo para que el analista lo trabaje.
Pantalla de análisis del caso (gestion-page)
El analista ve los documentos del caso (Certificado de defunción, Cédula del asegurado, Plan de pagos) con sus campos vacíos, a completar con los datos de los documentos escaneados.
El análisis con los documentos completados
Se completaron los tres documentos con los datos del asegurado, el certificado de defunción (causa, cobertura, país/provincia de ocurrencia) y el plan de pagos, usando el mismo endpoint que la pantalla (save-partial). Campos que quedan incompletos: ninguno. Tablas: DocumentAttributeValue por cada campo + proyección a ClaimAnalysisData.
El analista aprueba el análisis
PUT /api/v1/app/Claims/{id}/analised → HTTP 200. El caso pasa de «Clasificación y análisis» a «En proceso». Verificado por API: en InProcess = True. El backend calcula los montos a indemnizar según las fórmulas del banco y los guarda en ClaimAnalysisData. ClaimHistory: nueva fila StateChange(InProcess).
Intento de creación real del siniestro en SISE
POST /api/v1/app/Claims/Sise/CreateClaim/{id} → HTTP 200. En QA este endpoint llama al SISE REAL de Mapfre (no hay mock). Respuesta: {"status":"ValidationError","error":{"type":"ValidationError","message":"No se encontró póliza con número de operación 770002","description":"Error de validación de datos"},"messag. SISE RECHAZA la creación (error de negocio: la póliza/datos de ejemplo no existen en el maestro real de SISE). Por eso el flujo usa el bypass del producto para poder continuar.
El caso con su número SISE registrado
En la ficha del caso se ve el número SISE 2025-1286 (marcado como creación manual — bypass del SISE real).
El analista aprueba el pronunciamiento
PUT /api/v1/app/Claims/{id}/statement-approved → HTTP 200. El caso pasa a la etapa «Pronunciamiento». Verificado por API: en Statement = True. ClaimHistory: StateChange(Statement).
Se agrupa el caso hacia la aceptación del banco
POST /api/v1/app/Claims/group-claims → HTTP 200. Se crea un lote (grupo 01KXCQWVGEK35DPBXP5BW0NZ1C) con el caso — la regla exige que todos los casos del lote sean del mismo banco. El caso pasa a «Aceptación», esperando la decisión del tomador (banco). Tablas: ClaimAcceptanceGroup + ClaimAcceptanceGroupDetail.
El banco (tomador) acepta el siniestro
PUT group-claims/{g}/claims/{c}/approve → HTTP 204. Como el caso venía aprobado en pronunciamiento, pasa a «Tesorería». En Treasury = False.
El analista arma el grupo de pago de tesorería
POST /api/v1/app/Claims/state/treasury/grouped → HTTP 200. Se crea el grupo de tesorería 01KXCQXJAZ6X1NPFD8ZE58ZDP2 (GroupStatus=Created), otra vez con regla mismo-banco. Tablas: ClaimTreasuryGroup + ClaimTreasuryGroupDetail.
Se envía el grupo a tesorería con su soporte
POST send-to-treasury/user/{tesorero} → HTTP 204. El grupo se asigna al tesorero (GroupStatus=InTreasury). ⚠️ Este paso exige adjuntar al menos un archivo de soporte, que va a SharePoint — se subió un PDF de ejemplo generado por el flujo (bypass del documento real).
Pantalla de login
Formulario de acceso: usuario y contraseña (se validan contra LDAP)
Login como treasury1
POST /v1/Authentication/login → HTTP 200. El backend valida contra LDAP y devuelve el JWT (un solo rol). Landing: /tesorery-home-page
El tesorero registra el pago
POST payment-approval (rol Tesorero) → HTTP 204. El tesorero adjunta el comprobante de pago (PDF de ejemplo → SharePoint) y el grupo pasa a «Pagado por tesorería» (GroupStatus=PaidByTreasury). Tablas: Document (comprobante) por cada claim del grupo.
Pantalla de login
Formulario de acceso: usuario y contraseña (se validan contra LDAP)
Login como andres.daleney
POST /v1/Authentication/login → HTTP 200. El backend valida contra LDAP y devuelve el JWT (un solo rol). Landing: /dashboard-page
El grupo pagado se envía a cierre
PUT state/treasury/grouped/{g}/closure → HTTP 200. Cada caso del grupo pasa a «Cierre» (ClosedApproved) y el grupo queda Closed.
El caso queda CERRADO definitivamente
PUT /api/v1/app/Claims/{id}/close → HTTP 200. Estado final «Cerrado». El backend setea Claim.ResolutionDate y ElapsedTime (tiempo total del caso). Recorrido completo: Clasificación → En proceso → SISE → Pronunciamiento → Aceptación → Tesorería → Pago → Cierre.
