US-031 — Reporte de cotizaciones no aprobadas

Detalle de la historia¶

Historia¶

Como operador de FleteChat que monitorea la operación comercial, quiero un reporte de cotizaciones emitidas que no llegaron a aprobarse, para identificar oportunidades perdidas, patrones comunes y clientes a los que vale la pena contactar proactivamente.

Persona de usuario¶

Aplica a los operadores de FleteChat con rol admin u operator. El rol price_manager no tiene acceso a este reporte (no gestiona relación comercial con clientes).

Contexto de negocio¶

Una cotización emitida que nunca se aprueba es información valiosa: cuando se repite un patrón (mismo cliente, misma ruta, misma modalidad), la causa puede ser precio, tiempo de respuesta, desajuste con lo que el cliente esperaba, o simplemente que el cliente cambió de plan. Sin una vista que agregue estas cotizaciones, la información se pierde entre miles de registros operativos.

El reporte vive en el backoffice y se accede bajo demanda. Muestra las cotizaciones emitidas cuyo ciclo de aprobación no se completó (cotización vencida sin aprobar, cotización cancelada por el cliente, cotización abandonada por el cliente sin avanzar). Filtros típicos: rango de fechas, cliente, modalidad. El objetivo es accionable: identificar oportunidades, no producir un dashboard estadístico.

Criterios de aceptación¶

Acceso¶

1. El reporte está disponible en el backoffice de FleteChat a los roles admin y operator. El rol price_manager recibe 403 si intenta acceder.
2. El reporte se genera bajo demanda a partir de los filtros que el operador define; no hay generación programada en v1.0.

Contenido¶

1. El reporte incluye todas las cotizaciones cuyo estado final es "no aprobada" en alguna de sus variantes: vencida sin aprobarse, cancelada por el cliente, abandonada por el cliente (por ejemplo, nunca confirmó intención).
2. Cada fila muestra: código corto CNNN, cliente (nombre del titular), contacto que cotizó (titular o colaborador), fecha de emisión, fecha de vencimiento, ruta (origen/destino), modalidad, total cotizado y motivo del no-aprobación (vencida, cancelada, abandonada).
3. La tabla es ordenable por columnas y paginada cuando el volumen es alto.

Filtros¶

1. Filtros disponibles: rango de fechas (de emisión), cliente (por nombre o código), modalidad, nivel corporativo (si aplica), motivo del no-aprobación.
2. Los filtros son combinables con AND. Pueden guardarse como vista favorita del operador para reutilizar.

Export y trazabilidad¶

1. El reporte se puede exportar a CSV desde la misma vista, con los filtros aplicados.
2. Cada generación y export queda registrado en el audit log (operador, filtros, timestamp, cantidad de filas).

Edge cases¶

• Cotización vencida pero re-cotizada automáticamente (ver historia de vigencia y expiración). La cotización original aparece como "vencida sin aprobarse"; la re-cotización derivada es una fila propia con su propio estado final.
• Cotización de un cliente que ya no existe (eliminación de datos ejercida por el cliente, ver historia de eliminación de datos). La fila muestra "cliente eliminado" y el código CNNN para trazabilidad, sin exponer datos personales.
• Operador aplica filtros que producen cero resultados. La vista muestra estado vacío con mensaje y sugiere relajar filtros.
• Volumen muy alto (miles de filas). La tabla pagina y el export CSV se genera con streaming para no bloquear el backoffice.

Tamaño, prioridad y tipo¶

• Tamaño: S
• Prioridad: P1 — valor comercial claro, no bloquea la operación cotidiana.
• 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-130 — Categorías de no-aprobación. Las cotizaciones "no aprobadas" se clasifican en vencida, cancelada por el cliente, abandonada (el cliente nunca confirmó intención). Otras categorías se evalúan en versiones posteriores.
• PR-131 — Acceso por rol. El reporte es accesible únicamente a admin y operator. El rol price_manager no tiene acceso.
• PR-132 — Generación bajo demanda. En v1.0 no hay generación programada ni envío automático por correo del reporte. El operador lo consulta desde el backoffice cuando lo necesita.

Refinamiento y Definition of Ready¶

Notas¶

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-130 a PR-132 confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente