US-020 — Instructivo al operador logístico

Detalle de la historia¶

Historia¶

Como operador logístico externo contratado para ejecutar un embarque, quiero recibir un PDF técnico con todos los datos necesarios de la operación, para ejecutar el servicio (ruta, modalidad, Incoterm, servicios contratados) sin tener que consultar a FleteChat por información que ya fue acordada.

Persona de usuario¶

Aplica al operador logístico externo (agente de carga, transportista internacional, agencia aduanal) que FleteChat tiene configurado como ejecutor para el tipo de operación. Es un tercero con rol profesional, no cliente final de FleteChat. Recibe el PDF por correo al email de coordinación operativa que FleteChat mantiene en su catálogo de operadores.

Contexto de negocio¶

El operador logístico externo ejecuta materialmente la operación internacional: reserva cupo, coordina puertos y terminales, tramita documentación aduanera, gestiona la trazabilidad, entrega al destino final. A diferencia del proveedor (origen de la carga), el operador logístico necesita el detalle técnico completo del embarque: modalidad, Incoterm, servicios contratados, instrucciones técnicas.

El PDF técnico estandariza ese intercambio. Evita errores de comunicación (un Incoterm mal interpretado entre DDP y DAP puede mover miles de dólares de lugar) y deja registro escrito del briefing que FleteChat entregó al operador.

Criterios de aceptación¶

Contenido del PDF¶

1. La cabecera incluye el logotipo y marca de FleteChat, el número de embarque ENNN del cliente, la referencia al código interno largo para auditoría y, cuando exista, el número de tracking externo del operador logístico (ver US-018 AC 10–12).
2. El cuerpo incluye: datos del embarque (origen, destino, modalidad, Incoterm, tipo de operación), detalles técnicos (servicios contratados con su descripción, tiempo de tránsito acordado, dimensiones, peso, valor declarado), datos del remitente y consignatario declarados en el formulario operativo, documentación que el operador debe gestionar conforme al servicio contratado, puntos de coordinación (quién recoge, dónde, cuándo, a quién entregar), contactos del equipo de FleteChat para incidencias. El cuerpo tiene secciones condicionales por Incoterm: cuando el Incoterm es DDP o DAP, aparecen las instrucciones específicas de tramitación aduanera y entrega final que corresponden al alcance del operador; cuando es FOB, CFR o CIF, aparecen las instrucciones específicas del tramo cubierto (entrega al puerto, contratación del flete principal, gestión del seguro del tramo correspondiente). Las secciones no aplicables se omiten del PDF.
3. Los datos provienen íntegramente de la cotización aprobada y del formulario operativo; FleteChat no rellena valores faltantes ni los infiere.
4. El PDF está en español neutro de Panamá por defecto; cuando el operador logístico declarado tiene idioma preferente distinto y soportado, se emite en ese idioma.

Emisión 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 equipo interno; ver historias correspondientes), y queda almacenado asociado al embarque ENNN.
2. La distribución se hace por correo al email de coordinación operativa del operador logístico configurado en el catálogo de FleteChat para el tipo de operación.
3. Cuando el operador logístico tiene aliados configurados en su catálogo (uno en origen y/o uno en destino, ver PR-236), el aliado correspondiente al tramo del embarque recibe el mismo PDF del operador como destinatario adicional. La distribución al aliado se hace por el mismo canal (correo) y con el mismo mensaje explicativo. El aliado es invisible al cliente final (PR-235): no se le notifica al cliente que el aliado existe, no aparece en su portal, su chat ni sus correos.
4. El correo incluye un mensaje explicativo identificando el origen (FleteChat), el número ENNN y qué se espera del operador logístico. El PDF va adjunto.
5. La generación y el envío quedan registrados en el audit log con destinatario, canal y resultado.

Re-envío y reemplazo¶

1. El operador de FleteChat puede reenviar el PDF al operador logístico desde el backoffice sin regenerarlo; el reenvío queda auditado.
2. Si cambia el operador logístico asignado al embarque (por ejemplo, FleteChat lo reasigna por disponibilidad), se regenera formalmente el PDF con el destinatario correcto; la versión anterior queda marcada como invalidada y el histórico refleja ambas. Ante reasignación, el operador anterior recibe un correo de desasignación (sin el PDF nuevo), el nuevo operador recibe el PDF actualizado, y el evento queda en audit log con ambos destinatarios. La distribución a aliados del operador anterior queda también desactivada; los aliados del operador nuevo entran al flujo (AC 7).

Visibilidad por destinatario¶

1. El PDF del operador logístico no se envía al cliente final. La regla PR-096 cubre la separación comercial/técnica; este AC reafirma que también la separación operativa es estricta: el cliente conoce el resultado (estatus del embarque, hitos), no el detalle del briefing entregado al operador.

Protección del contenido¶

1. El PDF contiene la información técnica necesaria para la ejecución; no contiene información comercial (precios cotizados al cliente final, descuentos corporativos, condiciones de pago). Lo comercial vive en los instructivos internos (ver historia del equipo FleteChat).
2. El enlace firmado al PDF vence en 72 horas por defecto (ver PR-095). Reenvíos posteriores requieren acción del operador de FleteChat.

Edge cases¶

• Servicio contratado que requiere un operador logístico específico declarado por el cliente (caso excepcional). El operador de FleteChat lo asigna manualmente antes de aprobar el embarque; el flujo estándar lo respeta.
• Operador logístico en idioma distinto de FleteChat y del sistema. Si el idioma preferente declarado está soportado, se emite en ese idioma; idiomas no soportados requieren handoff para traducción manual antes del envío.
• Caída del proveedor de correo al momento de enviar. FleteChat aplica la política de reintentos (ver historia de distribución automática de instructivos); si agotados los reintentos el envío sigue fallando, el embarque entra en estado distribución incompleta y el operador interviene.

Tamaño, prioridad y tipo¶

• Tamaño: M
• Prioridad: P0 — sin el PDF al operador logístico, la operación no puede ejecutarse.
• 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-093 — Emisión única al aprobar. El PDF del operador logístico se genera exactamente una vez al momento del click de aprobación formal del embarque.
• PR-094 — Canal correo. La distribución se hace por correo al email de coordinación operativa del operador logístico configurado en el catálogo de FleteChat. WhatsApp no se usa para operadores logísticos externos.
• PR-095 — Ventana del enlace firmado. El enlace al PDF vence en 72 horas por defecto. Es un parámetro configurable por FleteChat. Reenvíos posteriores requieren acción del operador.
• PR-096 — Separación comercial/técnica. El PDF del operador logístico no contiene información comercial del cliente final (precios cotizados, descuentos, condiciones de pago): sólo información técnica necesaria para ejecutar.
• PR-235 — Aliado del operador: destinatario operativo invisible al cliente final. Definida en US-012. En esta historia se materializa: el aliado recibe el mismo PDF operativo del operador (AC 7) y la responsabilidad operativa sigue siendo del operador titular; el cliente final no conoce ni recibe notificación de la existencia del aliado.
• PR-236 — Un aliado por origen y un aliado por destino por operador. Definida en US-012. Aplica en la distribución del instructivo: el aliado correspondiente al tramo (origen o destino) del embarque entra como destinatario adicional cuando existe.

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-093 a PR-096 y PR-235 a PR-236 (referenciadas) confirmadas por el cliente
• ⬜ Reglas de negocio aplicables aprobadas
• ⬜ Requerimientos funcionales aplicables aprobados
• ⬜ Historia aprobada formalmente por el cliente