Camino con SUB-SINIESTRO — Banco Sol
Un caso con beneficiario adicional que habilita el sub-siniestro en SISE: documenta el límite (el sub-siniestro necesita el SISE real).
📁 Evidencias
Este flujo no descargó archivos. Sus 15 capturas están en la carpeta FA-SUBSINIESTRO/; hacé clic en cualquiera para ampliarla.
⚠️ 1 hallazgo(s) en este flujo
La creación del sub-siniestro depende de que SISE acepte la creación del siniestro principal. Como el SISE real rechaza los datos de ejemplo, el sub-siniestro no se genera. El bypass manual (sise-number) marca el principal como SuccessfulManual pero NO crea el sub-siniestro (eso solo ocurre por la vía SISE real). Para validar el sub-siniestro de punta a punta hace falta un caso con datos reales aceptados por SISE. El resto del ciclo sí se completa sobre el siniestro principal. (paso 5)
Pantalla de login
Formulario de acceso: usuario y contraseña (se validan contra LDAP)
Login como analista.extra4
POST /v1/Authentication/login → HTTP 200. El backend valida contra LDAP y devuelve el JWT (un solo rol). Landing: /dashboard-page
Caso con BENEFICIARIO ADICIONAL creado (N° 1290)
El Excel marcó beneficiario adicional (columna 26 = 'X'), lo que habilita la creación de un SUB-SINIESTRO en SISE (con su carátula). hasAdditionalBeneficiary=None. HTTP 200.
Caso aprobado → En proceso
El caso avanza a En proceso, listo para crear el siniestro (y su sub-siniestro) en SISE.
Intento de creación real en SISE (con sub-siniestro)
POST Sise/CreateClaim → HTTP 200. Si SISE aceptara, crearía el siniestro Y el sub-siniestro del beneficiario adicional (con montos Sepelio/PAPIT y su carátula PDF). Respuesta: {"status":"ValidationError","error":{"type":"ValidationError","message":"No se encontró póliza con número de operación 123456","description":"Error de.
Aprobado el pronunciamiento
PUT /statement-approved → HTTP 200. Va a Pronunciamiento.
Agrupado hacia la aceptación del tomador
POST group-claims → HTTP 200, grupo 01KXCR6XAWDQWMMA5B95F8EW0R.
El banco acepta → Tesorería
PUT approve. El caso pasa a Tesorería.
Grupo de tesorería armado
POST treasury/grouped → HTTP 200, grupo 01KXCR7BVZPC99CTYTPN8XZFXP.
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
Tesorería: enviado y pagado
El grupo se envía a tesorería (con soporte) y el tesorero registra el pago. Se muestra la bandeja real del tesorero.
Pantalla de login
Formulario de acceso: usuario y contraseña (se validan contra LDAP)
Login como analista.extra4
POST /v1/Authentication/login → HTTP 200. El backend valida contra LDAP y devuelve el JWT (un solo rol). Landing: /dashboard-page
El caso queda CERRADO
PUT /close → HTTP 200. Estado final: Close. Ciclo completo del camino alternativo.
