Tesorería y cierre
La última etapa del siniestro: el analista agrupa los casos aprobados por el banco en grupos de pago, se los envía al tesorero con la solicitud firmada, el tesorero registra el pago con su comprobante (o lo rechaza), y el caso se cierra. Participan dos roles: el analista y el tesorero.
📁 Evidencias
Este flujo no descargó archivos. Sus 21 capturas están en la carpeta F08-tesoreria/; hacé clic en cualquiera para ampliarla.
⚠️ 3 hallazgo(s) en este flujo
GET /state/treasury/grouping devolvió 0 casos. Para ejercitar las agrupaciones hace falta ≥1 caso del mismo banco aprobado por el banco en Aceptación (cadena E2→E6). No se simuló ningún resultado. (paso 7)
GET /state/treasury/grouped devolvió 0 grupos y no se pudo crear uno nuevo desde los casos individuales. El resto del flujo (envío al tesorero, pago, cierre) no tiene datos para operar. (paso 9)
Acciones visibles en su bandeja: [1] grupo ? — acciones: (ninguna) (paso 12)
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
Consulta del estado real de la etapa Tesorería
Antes de tocar la pantalla se consulta la API con el token de la sesión. Casos individuales pendientes de agrupar (GET /state/treasury/grouping) → HTTP 200, 0 caso(s). Grupos de pago ya armados (GET /state/treasury/grouped) → HTTP 200, 0 grupo(s). Ojo: la bandeja clásica /state/Treasury NO existe para esta etapa (da 404); Tesorería usa estos dos endpoints propios.
El analista abre «Mis casos» directo en la pestaña Tesorería
El carrusel de etapas del home se posiciona en «Gestión Tesorería». A diferencia de las otras etapas, acá no hay una tabla única: aparece un grupo de pestañas con los dos momentos del pago.
Los dos sub-tabs de Tesorería
El tab Tesorería contiene 2 sub-pestañas: Casos individuales, Casos agrupados. «Casos individuales» lista los casos que el banco aprobó en Aceptación y esperan ser agrupados; «Casos agrupados» lista los grupos de pago ya armados con su numeración (tipo 001/2024).
Sub-tab «Casos individuales»
La tabla está VACÍA: ningún caso llegó aprobado desde la etapa Aceptación.
Sin casos individuales: se documenta la precondición faltante
Los casos llegan a esta tabla cuando el banco los aprueba en la etapa Aceptación (flujo F07). En esta corrida F05 (Pronunciamiento) y F07 (Aceptación) no pudieron fabricar esa precondición, así que no hay nada que agrupar. Las dos agrupaciones («Agrupar liquidación.» y «Agrupar para tesorería.») solo aparecen al seleccionar filas, por lo que tampoco pueden capturarse en pantalla.
Click en «Sub-tab «Casos agrupados»»
Cambia a la lista de grupos de pago ya armados (GET /state/treasury/grouped).
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
La bandeja del tesorero
El tesorero ve 1 grupo(s) que le enviaron a pagar, con su numeración, banco, fecha, cantidad de casos, monto y tiempo transcurrido. [1] grupo ? — acciones: (ninguna)
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 analista vuelve a Tesorería para cerrar el ciclo
Tras el pago del tesorero, el grupo vuelve a la vista del analista con la acción «Enviar a cierre».
Ningún grupo ofrece «Enviar a cierre»
La acción aparece cuando el tesorero registró el pago del grupo. Acciones vistas: (sin grupos)
El analista abre la bandeja Cierre
GET /state/Closure → HTTP 200, 0 caso(s) por cerrar. Acá terminan los casos cuyos grupos fueron pagados y enviados a cierre.




















