US-021 — Instructivo interno de FleteChat

Detalle de la historia¶

Historia¶

Como personal operativo de FleteChat, quiero contar con un PDF interno completo del embarque, para gestionar la operación con toda la información (técnica, comercial, contable y de contactos) disponible en un único documento.

Persona de usuario¶

Aplica a los operadores de FleteChat con rol admin u operator que gestionan embarques en el backoffice. No aplica a clientes finales, proveedores ni operadores logísticos externos (que reciben los PDFs específicos de sus historias).

Contexto de negocio¶

Los PDFs del proveedor (US-019) y del operador logístico externo (US-020) son externos: tienen información acotada a lo que cada actor necesita y excluyen lo comercial por acuerdo. El equipo de FleteChat, en cambio, necesita la vista completa del embarque: cotización con el precio cobrado al cliente, nivel corporativo aplicado, datos operativos, instrucciones a proveedor y operador logístico, contactos de todas las partes, historial de aprobación con fecha y contacto que aprobó formalmente.

Ese documento es la referencia única para resolver dudas operativas internas, atender reclamos, auditar la operación, o retomar el embarque si cambia el operador responsable interno.

Criterios de aceptación¶

Contenido del PDF¶

1. La cabecera incluye marca interna, número ENNN del cliente, código interno largo y fecha de emisión.
2. El cuerpo incluye: datos completos de la cotización aprobada (código CNNN, ruta, modalidad, Incoterm, desglose de cargos con precios, vigencia, nivel corporativo aplicado si hubiera), datos del cliente y contacto que aprobó formalmente (titular o colaborador, fecha/hora del click, canal), datos del formulario operativo (remitente, consignatario, mercancía, documentación, observaciones), copia embebida o referenciada de los PDFs externos (proveedor y operador logístico) con sus destinatarios, estado inicial del embarque y contactos de soporte de FleteChat para la operación.
3. Los datos provienen íntegramente de la cotización aprobada, del formulario operativo y del catálogo de FleteChat; FleteChat no infiere valores.
4. El PDF está en español neutro de Panamá.

Acceso y distribución¶

1. El PDF se genera una sola vez al momento de la aprobación formal del embarque, junto con los otros instructivos (proveedor y operador logístico).
2. La distribución es interna: el PDF queda accesible desde el backoffice al rol admin y al rol operator. No se envía por correo automático a nadie externo ni se expone por WhatsApp al cliente final.
3. El operador puede descargarlo o visualizarlo desde la ficha del embarque en el backoffice; la acción queda registrada en audit log (acceso, descarga, impresión).
4. El rol price_manager no tiene acceso a este PDF (no gestiona embarques); los otros roles del backoffice siguen lo definido en la historia de acceso y seguridad.

Regeneración¶

1. Cuando cambia algún dato del embarque que afecta los otros instructivos (proveedor, operador logístico), el PDF interno se regenera en lote junto con los afectados; el histórico preserva todas las versiones con fecha y motivo (ver historia de distribución automática).
2. Una regeneración del PDF interno no se envía externamente por sí sola: sólo se propaga a los externos cuando el dato afectado los afecta y la política de regeneración así lo indica.

Edge cases¶

• Operador consulta el PDF de un embarque de otro operador del mismo FleteChat. El acceso por rol lo permite: los embarques de FleteChat son visibles al equipo completo; la segregación por cliente final aplica al cliente final, no al equipo interno.
• Price_manager intenta acceder al PDF. El backoffice responde con 403 o equivalente; la acción queda registrada en audit log.
• Descarga del PDF interno fuera del backoffice (por ejemplo, email entre operadores). La descarga es una operación permitida: la responsabilidad del uso posterior recae en el operador que descargó, registrado en audit log.

Tamaño, prioridad y tipo¶

• Tamaño: S
• Prioridad: P0 — sin documento interno completo, la gestión operativa y la auditoría se complican.
• 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-097 — Emisión única al aprobar y regeneración controlada. El PDF interno se genera exactamente una vez al momento del click de aprobación formal y se regenera cuando cambia algún dato que afecta los instructivos relacionados. El histórico preserva todas las versiones.
• PR-098 — Acceso interno por rol. El PDF interno es accesible desde el backoffice a los roles admin y operator. El rol price_manager no tiene acceso. Otros roles siguen la política de la historia de acceso y seguridad.
• PR-099 — No exposición externa automática. El PDF interno no se envía por correo automático ni por WhatsApp a actores externos. Su distribución es manual bajo responsabilidad del operador que decide compartirlo, registrada en audit log.

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