10. Reportes, dashboard y actividad

Cubre el dashboard (resumen mensual), los 14 endpoints de reports, y activity_logs (auditoría). El aislamiento entre empresas de estos tres módulos ya se prueba a fondo en 2. Aislamiento multi-tenant (MT-21 a MT-23) — aquí se prueba que los números y filtros sean correctos, no la seguridad.

Historial de ejecución

Ciclo	Fecha	Ejecutado por	Casos ejecutados	Resultado
1	—	—	—	Pendiente

Dashboard

CP DASH-01: Dashboard del mes actual, sin filtro de tienda, con datos de varias tiendas

Resultado esperado: totales de ventas/ingresos/gastos/compras sumando todas las tiendas de la empresa.

Resultado obtenido: Pendiente.

CP DASH-02: Dashboard filtrado por una tienda específica

Resultado esperado: los mismos totales, pero acotados solo a esa tienda — comparar manualmente contra los números reales creados en pruebas anteriores.

Resultado obtenido: Pendiente.

CP DASH-03: Dashboard de un mes sin ninguna venta/gasto/compra registrada

Resultado esperado: todos los totales en 0, daily_stats con todos los días en 0 (no debe faltar ningún día del mes ni romperse el gráfico), recent_sales como lista vacía (no null).

Resultado obtenido: Pendiente.

CP DASH-04: Ventas en estado held — ¿cuentan en total_sales/total_revenue?

Objetivo: confirmar si el dashboard incluye órdenes en espera (todavía no cobradas) en los totales de ingresos, lo cual inflaría artificialmente las ventas del día.

Resultado obtenido: Pendiente.

CP DASH-05: Parámetro month/year fuera de rango (ej. month=13, year=1800)

Resultado esperado: no debe causar un error 500; debería devolver datos vacíos o normalizar el valor.

Resultado obtenido: Pendiente.

Reportes

Para cada uno de los 14 reportes, probar al menos: (a) sin filtros, (b) con date_from/date_to, (c) con store_id, (d) un rango de fechas sin resultados.

Caso	Reporte	Qué verificar en particular
REP-01	`reports/sales`	que `status="held"` se distinga claramente de `"paid"`/`"outstanding"` en la columna de estado
REP-02	`reports/daily-sales`	que excluya explícitamente `status="held"` (confirmado en el código) — una orden en espera no debería contar como venta del día en este reporte específico, a diferencia de lo que hay que confirmar en DASH-04
REP-03	`reports/monthly-sales`	consistencia de los totales anuales contra la suma manual de `daily-sales` del mismo rango
REP-04	`reports/payments`	que agrupe correctamente por `method` (cash/card/transfer/gift_card) y que el total coincida con `reports/sales`
REP-05	`reports/best-sellers`	que el orden sea realmente por unidades vendidas descendente, y que el límite de 50 productos no oculte silenciosamente productos relevantes en un catálogo grande
REP-06	`reports/expenses`	filtro combinado de fecha + tienda
REP-07	`reports/purchases`	que `status` refleje correctamente compras con saldo pendiente
REP-08	`reports/return-orders`	que el total devuelto no se reste visualmente de las ventas en este mismo reporte (son tablas separadas)
REP-09	`reports/adjustments`	diferenciar visualmente `type="addition"` de `type="subtraction"`
REP-10	`reports/bookings`	filtro de fecha sobre `date` de la reserva, no sobre `created_at`
REP-11	`reports/customers`	sin filtro de tienda ni fecha en el backend — confirmar que la pantalla no sugiere falsamente que se puede filtrar por algo que el backend ignora
REP-12	`reports/products`	que `value` (`price * quantity`) sea coherente con lo visto en Inventario general
REP-13	`reports/stores`	que la tienda sin ninguna venta/gasto en el rango aparezca con 0, no ausente de la lista
REP-14	`reports/registers`	filtro combinado de fecha + tienda + usuario

Resultado obtenido de REP-01 a REP-14: Pendiente — llenar fila por fila.

CP REP-15: date_from posterior a date_to (rango invertido)

Resultado esperado a verificar: ¿el backend lo detecta y devuelve vacío/error, o simplemente no encuentra nada porque la condición SQL >= date_from AND <= date_to nunca se cumple, sin ningún aviso de que el rango está mal escrito?

Resultado obtenido: Pendiente.

CP REP-16: Exportar/imprimir un reporte (si existe esa opción en el frontend)

Resultado esperado: confirmar si existe función de exportar a CSV/Excel/PDF; si no existe, anotarlo como posible mejora, no como bug.

Resultado obtenido: Pendiente.

Actividad (activity log)

CP ACT-01: Confirmar qué acciones quedan registradas

Objetivo: el middleware solo registra una lista fija de rutas (crear venta, eliminar venta, crear compra/gasto/devolución/ajuste, abrir/cerrar caja, reservas, movimiento de gift card, crear tienda/producto/usuario, eliminar usuario).

Pasos: ejecutar una acción que no esté en esa lista (ej. editar un producto, crear una categoría) y confirmar que, efectivamente, no aparece en el log.

Resultado esperado a verificar: si el negocio espera auditar también ediciones/borrados de productos, categorías, clientes, etc., esto es una brecha de auditoría real a reportar — no es un bug, es una limitación de alcance del middleware actual.

Resultado obtenido: Pendiente.

CP ACT-02: Filtro de fecha en el log de actividad

Resultado esperado: date_from/date_to funcionan sobre created_at del log.

Resultado obtenido: Pendiente.

CP ACT-03: El log muestra el nombre del usuario, no solo el ID

Resultado esperado: el JOIN con users debe mostrar first_name + last_name; si el usuario que hizo la acción fue borrado después, confirmar qué se muestra (¿nombre en blanco, “usuario eliminado”, o el registro desaparece del log?).

Resultado obtenido: Pendiente.

CP ACT-04: Volumen — crear 1000+ acciones y verificar el límite del listado

Objetivo: el endpoint tiene Limit(1000) fijo en el código.

Resultado esperado a verificar: confirmar si el frontend avisa de alguna forma que hay más de 1000 registros y no se están mostrando todos, o si simplemente corta la lista sin ningún aviso (dando una falsa sensación de que esos fueron todos los eventos).

Resultado obtenido: Pendiente.

Notas de usabilidad y sugerencias

Se completa durante la ejecución.