Consola web

La consola de BeneficiosCenter es una SPA React servida por el mismo jar en /gestor/, con la misma familia visual que el gestor del Sistema de Premios: barra lateral fija, tablas limpias, un solo color de acento que toma la marca del cliente — para DINO, el lima #E0F848 (ver Marca blanca).

Dos roles, verificados en el servidor (INV-S04), no solo en la interfaz:

Rol	Puede
ADMIN	Ver y escribir en los cuatro ABM (Beneficios, Tipos de cliente, Sucursales, Usuarios) y en Auditoría.
OPERADOR	Solo lectura: ve las mismas pantallas con las acciones de escritura ocultas; cualquier intento de POST/PUT/DELETE contra la API de administración recibe 403 aunque se fuerce desde fuera de la consola.

Las capturas de esta página son de una corrida de humo real de la entrega 1 (dos usuarios: admin y smoke-operador).

Tema

Claro por defecto, con un toggle para pasar a oscuro — a diferencia de otras apps que siguen la preferencia del sistema operativo, la consola arranca siempre en claro salvo que la persona ya haya elegido oscuro antes. La elección manual se guarda en localStorage del navegador (no en el servidor) y se reaplica en la próxima visita; sin esa elección guardada, siempre es claro, sin importar el prefers-color-scheme del sistema.

Login

Formulario simple: usuario y contraseña contra Usuario (HTTP Basic stateless, ver ADR-003). El logo y el nombre del comercio (Supermercados DINO) vienen de la configuración de marca blanca.

Beneficios (vista ADMIN)

Pantalla inicial tras el login del ADMIN. Sidebar con los cinco ítems del rol: Beneficios, Tipos de cliente, Sucursales, Usuarios, Auditoría. El listado muestra nombre, porcentaje, vigencia, prioridad, tipos de cliente y estado de cada beneficio.

Captura desactualizada: formulario en la página, ahora es un diálogo modal

Esta captura es de la entrega 1, cuando el formulario de alta vivía embebido en la misma página. Desde la entrega 3 (AC-62/63), "Crear" abre el formulario en un diálogo modal (Radix Dialog) sobre un listado paginado de a 5 filas; "Editar" abre el mismo diálogo precargado con los datos de la fila elegida. No hay una captura nueva todavía en la evidencia recolectada.

El formulario expone todos los campos del modelo de dominio: nombre, descripción, porcentaje, prioridad (menor gana), estado, vigencia desde/hasta, franja horaria (vacío = todo el día), monto mínimo y tope de descuento opcionales, tipos de factura y días de la semana. Desde la entrega 3 (AC-65), el campo Sucursales dejó de ser una lista de casillas y pasó a un combobox buscable con chips removibles (MultiSelect): escribir filtra las opciones por texto, se pueden elegir varias, y dejarlo vacío sigue significando "todas las sucursales". Solo visible para ADMIN.

Patrón compartido: Beneficios, Sucursales, Tipos de cliente y Usuarios

Los cuatro ABM de la consola (Beneficios, Sucursales, Tipos de cliente, Usuarios) comparten el mismo patrón desde la entrega 3:

• Listado primero, paginado de a 5 filas (paginación en el cliente, sin parámetros nuevos en la API).
• Un botón "Crear" abre el formulario en un diálogo modal, vacío.
• "Editar" abre el mismo diálogo, precargado con los datos de la fila elegida.
• El OPERADOR sigue viendo exactamente el mismo listado, sin el botón "Crear" ni las acciones de "Editar"/"Eliminar" — el criterio de solo lectura (INV-S04) no cambió, solo la forma del ABM alrededor.

Auditoría (vista ADMIN)

Filtros por fecha (desde/hasta), sucursal (branchId) y requestId. El listado de consultas muestra fecha de recepción (en horario de Córdoba), request id, sucursal, latencia en milisegundos, resultado (OK, SIN_BENEFICIOS, ERROR_VALIDACION, NO_AUTENTICADA, ERROR_INTERNO) y marcas (por ejemplo REPETIDA o SUCURSAL_DESCONOCIDA). Esta captura corresponde a una corrida de humo con auth fallida a propósito: por eso predominan NO_AUTENTICADA y ERROR_VALIDACION.

Vista del OPERADOR

El OPERADOR (smoke-operador) ve la misma sección Auditoría, con los mismos filtros, pero sin ninguna acción de escritura disponible.

La pantalla de Beneficios del OPERADOR muestra el mismo listado que ve el ADMIN — acá con los tres beneficios del seed cargados (Jueves Dini Negocios 10%, Gift Card 5% Septiembre, Aniversario DINO 15%) — pero sin el botón "Nuevo beneficio" ni acciones de edición: compará con la captura del administrador más arriba.

Tablero (entrega 3 — pantalla de promociones)

El tablero (GET /api/admin/tablero, AC-29..31) sigue siendo la pantalla inicial de la consola, pero la entrega 3 (Q3) lo rediseñó como una pantalla de promociones, en tres bloques, cada uno con su propio estado de carga/error (una sección caída no vacía el resto):

1. Actividad por hora (AC-61) — reemplaza al embudo de captura como historia principal de apertura: un heatmap de 24 celdas (hora 0 a 23, siempre el día de hoy en zona Córdoba, GET /api/admin/tablero/por-hora), intensidad = cantidad de aplicados en esa hora. Debajo quedan, como contexto de apoyo, los contadores originales del tablero de entrega 2: consultas totales, porcentaje con beneficio y p99 de latencia.
2. Ranking por beneficio (AC-58) — tabla ordenable con GET /api/admin/tablero/captura: ofrecido vs. aplicado (bullet chart por fila), efectividad y descuento entregado por beneficio. Ver el contrato completo en Tablero — captura y actividad por hora.
3. Sala de control (AC-59) — semáforo (verde/ámbar/rojo, siempre con ícono y etiqueta, nunca solo color) para la tasa de aprobación y la tasa de rechazo, reutilizando GET /api/admin/tablero y GET /api/admin/tablero/resultados sin reimplementar nada; lista las sucursales desconocidas del rango como alerta con link directo a Sucursales, y un desglose por medio de pago.

El selector de rango (hoy por defecto, hasta 90 días) sigue aplicando al ranking y a la sala de control; la actividad por hora es siempre el día actual y no lo sigue — aclarado en la propia pantalla.

No hay captura disponible todavía en la evidencia recolectada para este rediseño (heatmap, ranking, sala de control) — las capturas de esta página siguen siendo las de la corrida de humo de entrega 1, previa al tablero.

Resultados de pago (entrega 3)

Pantalla nueva, ubicada junto al Tablero en el sidebar (/resultados-pago, AC-54). Mismos dos roles leen (INV-S04), mismo rango hoy-por-defecto con máximo 90 días que el Tablero (AC-52). Consume GET /api/admin/tablero/resultados — el contrato completo está en Pipeline de resultado de pago.

La diferencia con el Tablero, en una frase

El Tablero mide lo ofrecido: qué resolvió BeneficiosCenter antes de que el pago se intentara. Resultados de pago mide lo que pasó: si el autorizador aprobó, con qué cuenta pagó realmente el cliente, y cuánto descuento se hizo efectivo — datos que solo existen porque el GatewayQR se los reporta a /resultado después de cobrar (ver Pipeline de resultado de pago).

No hay captura de pantalla todavía en la evidencia recolectada — igual que el Tablero, la consola de esta pantalla no fue fotografiada. En su lugar, el panel de abajo muestra el diseño de la pantalla poblado con los números de la única corrida E2E verificada de esta entrega, contra el emulador del gateway — no es una captura ni un dato de producción.

El panel real ya incluye descuento consultado y conversión (V8)

Desde la migración V8, la pantalla agrega dos tarjetas más entre las de abajo: Descuento consultado (lo que el resolver cotizó al ofrecer cada beneficio) y Conversión (otorgado / consultado, en %) — junto a la tarjeta de descuento ya existente, ahora rotulada Descuento otorgado. El mockup de abajo es anterior a V8 y no las muestra todavía; el contrato completo de los tres campos está en Pipeline de resultado de pago.

Resultados de pago · hoy

100%

Tasa aprobación

$15.000

Descuento otorgado

990

Medio de pago usado

1

Con resultado

Medio de pago	Cantidad	%
990 · Dini Negocios	1	100%

Panel de Resultados poblado con la corrida E2E verificada (100.000 → 85.000, beneficio aplicado, cuenta 990). Datos del emulador, no de producción — ver E2E con GatewayQR para la corrida completa.

Otras pantallas de entrega 2 y 3

• Marca blanca en runtime: el logo, el color primario y el nombre del cliente se leen de GET /api/branding sin rebuild (ver Marca blanca).
• PWA: la consola es instalable, con manifest e iconos propios del cliente y service worker con fallback de navegación (AC-36).
• Exportación CSV de auditoría: desde la misma pantalla de Auditoría, con los filtros activos (AC-33).
• Resultados de pago: pantalla nueva de entrega 3 descrita arriba, con su propio contrato en Pipeline de resultado de pago.

Dónde sigue

• El detalle de cada rol y por qué la autenticación es HTTP Basic stateless, en ADR-003.
• Los criterios de aceptación que esta interfaz satisface, en Matriz de aceptación.