Saltar a contenido

US-032 — Reportes estructurados de embarques

Detalle de la historia

Historia

Como operador de FleteChat que analiza la operación, quiero ver reportes de embarques agrupados por cliente, por origen, por destino o por modalidad, para entender la operación desde distintas perspectivas y tomar decisiones comerciales informadas.

Persona de usuario

Aplica a los operadores de FleteChat con rol admin u operator. El rol price_manager no tiene acceso a estos reportes.

Contexto de negocio

Los operadores necesitan ver la operación agregada, no embarque por embarque. Preguntas típicas: "¿qué clientes concentran más embarques?", "¿qué rutas crecieron mes a mes?", "¿qué modalidad domina por tipo de cliente?". Cada pregunta tiene una dimensión de agrupación distinta y un conjunto de filtros propio.

En v1.0 FleteChat ofrece cuatro vistas estructuradas —una por cada dimensión de agrupación natural (cliente, origen, destino, modalidad)—, con filtros combinables para acotar el universo analizado. Las vistas son consultables en el backoffice y exportables a CSV o Excel (.xlsx) para análisis externo, con default según el perfil del cliente (PR-246, US-028).

Criterios de aceptación

Vistas disponibles

  1. El backoffice ofrece cuatro vistas separadas, accesibles desde el menú de reportes: a. Por cliente: agrupa embarques por cliente (titular de la cuenta). b. Por origen: agrupa por ciudad / puerto de origen. c. Por destino: agrupa por ciudad / puerto de destino. d. Por modalidad: agrupa por modalidad (aéreo, LCL, FCL-20', FCL-40', etc.).
  2. Cada vista muestra, por cada grupo: identificador del grupo, cantidad de embarques, total facturado, embarque más reciente y estatus más frecuente entre los embarques del grupo.

Filtros y comportamiento

  1. Cada vista acepta filtros combinables: rango de fechas, modalidad (cuando no es la dimensión de agrupación), estatus, cliente (cuando no es la dimensión), origen y destino (idem).
  2. Los filtros son AND por defecto, editables en línea. Cambiar un filtro re-consulta la vista.
  3. La tabla es paginada y ordenable por cualquiera de las columnas numéricas y por identificador del grupo.
  4. Desde cada fila del grupo, el operador puede hacer drill-down a una vista de embarques individuales que cumplen el filtro de la fila.

Acceso y export

  1. Los reportes son accesibles únicamente a admin y operator. Al rol price_manager se le deniega el acceso con un mensaje claro de permisos insuficientes.
  2. Cada vista exporta a CSV y a Excel (.xlsx) con los filtros aplicados; la exportación respeta el agrupamiento. El drill-down ofrece los dos formatos. El default por solicitud sigue PR-246 (definida en US-028): Excel para clientes con nivel corporativo asignado, CSV para el resto. El operador puede sobrescribir el default al exportar.
  3. Cada generación y export queda registrado en el audit log.

Coherencia con otras vistas

  1. Los mismos datos consultados en las cuatro vistas estructuradas y en la consulta conversacional de reportes (ver historia correspondiente) son coherentes entre sí: el conteo total para un mismo filtro es idéntico en todas las vistas.

Incoterm visible para el operador

  1. El Incoterm del embarque es visible para el operador del backoffice en (a) el detalle de cada embarque, (b) la tabla de listado de embarques (como columna opcional configurable por usuario) y (c) los reportes estructurados como columna disponible. El Incoterm no se incluye en el resumen al cliente (consistente con US-023 AC 8).

Naming "Servicio" — i18n con valor placeholder

  1. El término visible de la dimensión "Servicio" en reportes, listados y formularios se difiere hasta que Zeverium entregue la matriz de servicios/tarifas (§7.3 del análisis de impacto, en progreso por Zeverium al 2026-05-27). Mientras tanto, el sistema muestra un placeholder identificable y todo el contenido del label se sirve desde el catálogo de internacionalización del producto para que el cambio sea editorial, no de código.

Edge cases

  • Volumen alto en una vista específica (por ejemplo, cientos de clientes con operaciones). La tabla pagina; el drill-down y el export funcionan sobre el conjunto filtrado completo.
  • Cliente eliminado que aparece en la vista "por cliente". Se muestra como "cliente eliminado" con el identificador interno para trazabilidad, sin exponer datos personales.
  • Nueva modalidad agregada al catálogo. Aparece automáticamente en la vista "por modalidad" una vez hay al menos un embarque con esa modalidad.
  • Operador aplica filtros que dejan la vista vacía. La vista muestra estado vacío con mensaje y sugiere relajar filtros.

Tamaño, prioridad y tipo

  • Tamaño: M
  • Prioridad: P1 — herramienta analítica base del backoffice.
  • Tipo: feature

Premisas

La historia está redactada bajo las siguientes premisas. Si alguna cambia, la historia debe revisarse y ajustarse en consecuencia. Todas deben ser confirmadas por el cliente antes de cerrar la historia.

  • PR-133 — Cuatro dimensiones de agrupación en v1.0. Las dimensiones soportadas en v1.0 son cliente, origen, destino y modalidad. Otras dimensiones (nivel corporativo, Incoterm, servicio) quedan para versiones posteriores.
  • PR-134 — Drill-down al detalle del embarque. Cada fila de una vista agregada permite hacer drill-down a una tabla de embarques individuales que cumplen el filtro de la fila.
  • PR-135 (obsoleta, 2026-05-27) — La premisa original declaraba "Sin export a Excel en MVP". El refinamiento del feedback #54 (Zeverium, 2026-05-26) reincorpora Excel: la exportación admite CSV y Excel (.xlsx) según PR-246 (definida en US-028). Esta premisa queda retirada; permanece listada solo para trazabilidad histórica.

Refinamiento y Definition of Ready

Notas

Fecha Participantes Acuerdo / Nota
2026-04-19 Kaeus Versión inicial.
2026-04-19 Kaeus Aprobación interna: pase a 🔵 Refinada.
2026-05-27 Kaeus v2.0 — Refinamientos derivados del feedback de Zeverium consolidado en docs/spec/customer-feedback/impact-analysis-2026-05.md. AC 11 (Incoterm visible en detalle, listado y reportes del operador; comentario #48). AC 12 (naming "Servicio" via i18n con placeholder; comentarios #58 y #76, depende de matriz §7.3 en progreso por Zeverium).
2026-05-27 Kaeus v2.0 (corrección) — Resolución del conflicto cross-historia con PR-246 (US-028). PR-135 (sin export a Excel) queda retirada: el refinamiento del feedback #54 reincorpora Excel. AC 8 actualizado a "CSV + Excel con default por perfil del cliente (PR-246)". Contexto de negocio actualizado para mencionar ambos formatos.
2026-05-27 Kaeus v2.0 (corrección de calidad) — AC 7 reformulado para retirar el código HTTP "403" del AC narrativo (denegación de acceso en términos observables). AC 12 reformulado para retirar el detalle de implementación ("label", "i18n", sintaxis t('dim.service')) y describir el comportamiento en términos funcionales (término visible diferido, placeholder identificable, cambio editorial). Defectos §2 del quality-review-v2.0.md.

Checklist

  • ✅ Historia escrita en formato Como / Quiero / Para
  • ✅ Persona de usuario identificada
  • ✅ Contexto de negocio documentado
  • ✅ Criterios de aceptación observables y pass/fail
  • ✅ Edge cases relevantes listados
  • ✅ Tamaño y prioridad asignados
  • ⬜ Premisas PR-133 y PR-134 confirmadas por el cliente (PR-135 retirada por refinamiento 2026-05-27)
  • ⬜ Reglas de negocio aplicables aprobadas
  • ⬜ Requerimientos funcionales aplicables aprobados
  • ⬜ Historia aprobada formalmente por el cliente