RED · PORTAL DE LOGÍSTICA
Su transitario le actualiza por correo. El equipo de expedición publica hitos en una hoja de cálculo compartida que alguien sigue olvidando refrescar. Las fechas de despacho de aduanas llegan como capturas de pantalla en PDF. Las tarifas viven en una carpeta de SharePoint. Cuando el contenedor se retrasa, se entera por el importador que pregunta por qué. Su «registro de envío» es una ficción reconstruida a partir de tres bandejas de entrada y un WhatsApp.
El Portal de Logística en TradeOS es una cabina de marca en la que sus transitarios, agentes y transportistas trabajan directamente: la misma base de datos, acotada a lo que necesitan ver. La Bandeja estructurada reemplaza el correo improvisado. Los hitos reales aterrizan en máquinas de estado reales. Aduanas, expedición, facturación y conversaciones, todo en un registro. Identidad multiinquilino: un login, muchos espacios de trabajo de operador, cada uno aislado. Gratis para el proveedor. No es un reemplazo de TMS.
Solicitar una demoVer precios →
Secciones del portal
7 · bandeja, envíos, expedición, facturas, y 3 más
Modos logísticos
Marítimo, aéreo, camión, ferrocarril, exprés, y 3 más
Identidad multiinquilino
Un login, muchos espacios de trabajo de operador
Coste para el transitario
$0 · el operador paga por TradeOS
El panel de Inicio real: franja de saludo, widget de mapamundi con los envíos activos en sus posiciones, cola de acciones de dos columnas. Una sola llamada al backend (GET /portal/logistics/home) lo devuelve todo. La identidad de marca del operador (logo, color, etiqueta de espacio) se renderiza desde los ajustes del inquilino del operador.
EL HITO QUE NUNCA SE ACTUALIZA
El transitario es competente. El agente es rápido. La página de seguimiento del transportista existe. Nada de eso ayuda cuando el sistema de registro de un solo envío está repartido entre tres bandejas de entrada, dos hojas de cálculo, una carpeta de SharePoint, y un grupo de WhatsApp en el que nadie está en el mismo huso horario.
01 · LOS HITOS VIVEN EN UNA HOJA DE CÁLCULO COMPARTIDA
Su transitario actualiza una hoja de Google a un ritmo distinto que el importador que le persigue. El equipo de ops tiene dos fuentes de verdad —la hoja de cálculo y la página de seguimiento del transportista— y discrepan en tres días. Para cuando saca la respuesta, el contenedor ha despachado aduanas sin que nadie lo note.
02 · LAS ACTUALIZACIONES DE ADUANAS VIVEN EN HILOS DE CORREO
El agente de aduanas es rápido pero su canal es la bandeja de entrada que tuviera abierta en ese momento. La notificación de liberación llega como adjunto en PDF. Se la reenvía a contabilidad, que no encuentra el número de entrada porque está dentro de la captura de pantalla. El envío sale tres días tarde porque nadie sabía que estaba despachado.
03 · UN TRANSITARIO, QUINCE PORTALES
Monta «su» portal y le pide a su transitario que inicie sesión para actualizar hitos. Tiene uno para cada cliente. No revisa ninguno de forma consistente. Sus datos se quedan obsoletos en el momento en que cierra la pestaña del navegador. El portal se convierte en un sistema que el transitario trata como una tarea pesada, hasta que deja de serlo.
7 SECCIONES · UN PORTAL
El LOGISTICS_NAV.flatLinks real de client/src/lib/navConfig.ts. La navegación inferior móvil usa las primeras cuatro: Inicio · Bandeja · Envíos · Expedición.
Franja de saludo + mapamundi con envíos activos + cola de acciones de 2 columnas (Necesita Respuesta, En Riesgo, Hoy, Dinero). Una sola llamada al backend lo devuelve todo.
La cola de respuesta estructurada. 3 subpestañas (reservas, RFQ, disputas), cada una con secciones Necesita Acción / Esperando Respuesta / Decididas Recientemente. Auto-promoción a las 48 h en contraofertas obsoletas.
5 pestañas: Seguimiento, Contenedores, Costes, Aduanas, Historial. Una llamada al backend (/shipments/overview/all) lo devuelve todo; las pestañas son proyecciones.
Máquina de 11 estados para el transporte terrestre. assigned → accepted_by_driver → en_route_to_pickup → arrived → loaded → departed → en_route_to_delivery → arrived → unloaded → completed (+ rama failed). Finalización condicionada al POD.
Hojas de tarifas con valid-from / valid-to / version / superseded-by. Recargos por línea, niveles por volumen, cargo mínimo. Importación masiva de 1-500 líneas atómica.
Máquina de 10 estados. 3 tipos: por envío, mensual consolidada, ad-hoc. Rama de disputa con seguimiento de resolución.
Mensajería en hilos acotada por conexión de operador. Adjunta a la entidad (reserva, RFQ, envío, factura). Notificaciones vía el mismo tejido que los otros portales.
LA BANDEJA · 1,252 LÍNEAS DE UI
Tres tipos de flujo de trabajo comparten una cola porque desde la perspectiva del transitario son todos «respuesta estructurada, con presión de tiempo, yo soy el cuello de botella»: solicitudes de reserva, RFQ, y disputas de facturas. La superficie de la Bandeja los pone en una cola con formularios de acción en línea, de modo que la ruta común no necesita navegación.
5 cotizaciones enviadas · esperando decisión del operador · la más antigua hace 18 h
2 cotizaciones ganadas · 1 cotización perdida · expandir para ver
ENVÍOS · 5 PESTAÑAS · UNA LLAMADA AL BACKEND
La superficie de trabajo principal del transitario. GET /portal/logistics/shipments/overview/all lo devuelve todo una vez; la página lo mantiene en memoria y lo proyecta por pestaña. Sin fan-out desde el navegador, sin re-fetch por pestaña.
Mapamundi + lista con estado, ruta, último hito, excepciones abiertas. Haga clic en una fila → expansión en línea que muestra la línea de tiempo completa de hitos + las excepciones abiertas de ese envío.
Cada contenedor en cada envío, con tipo, utilización (CBM / peso vs máximo del contenedor), nº de precinto, fecha de carga. La vista «qué hay cargado dónde».
Ingresos por envío de las facturas, importe pagado, pendiente. Totales agregados arriba. Profundice en el detalle de la factura desde cualquier fila.
Presentaciones de aduanas por envío: jurisdicción (ISO 3166), tipo de declaración (importación/exportación/tránsito), estado (máquina de 7 estados), número de declaración, códigos HS presentados. Agregado despachado/pendiente/retenido arriba.
Fusión cronológica de eventos + hitos + excepciones de todos los envíos de este transitario. Feed ordenado por tiempo. La superficie del registro de auditoría.
MÁQUINAS DE ESTADO · APLICADAS EN LA BD
Cada flujo de trabajo tiene una máquina de estado explícita: tipos enum de Postgres o restricciones CHECK. Las reglas de transición en la capa de servicio validan qué estados pueden pasar a cuáles. Sin cadenas mágicas, sin estado del lado de la UI.
RESERVA · 6 ESTADOS
Alts terminales: declined · cancelled · expired. Aceptar crea el envío enlazado.
RFQ · 7 ESTADOS
Ramas: lost · declined_to_quote · expired · withdrawn. El backend impone una-cotización-pendiente-por-RFQ.
EXPEDICIÓN · 11 ESTADOS
Cualquier estado activo puede transicionar a failed con un motivo. La finalización requiere capturar primero el POD (condicionada por tooltip en la UI).
FACTURA · 10 ESTADOS
Ramas: overdue · disputed · written_off. Tres tipos de factura: per_shipment · monthly_consolidated · ad_hoc.
PRESENTACIÓN DE ADUANAS · 7 ESTADOS
Ramas: held (pendiente de docs / pago / inspección) · queried (aduanas hizo una pregunta) · rejected (terminal). Por jurisdicción × declaration_type.
EXCEPCIONES · ENUM 3+3
Gravedad × estado. El estado se mueve open → mitigating → resolved. Distinto de los hitos: declarada, mitigación rastreada, resolución auditada.
8 MODOS LOGÍSTICOS · PLANTILLAS DE HITOS POR MODO
El enum logistics_mode tiene ocho valores, cada uno con su propia plantilla de hitos por modo (validada del lado del servicio, no vía enum de BD, para que se puedan añadir nuevos hitos sin ALTER TYPE).
UN TRANSITARIO · MUCHOS OPERADORES
Un transitario que sirve a Pendrew Energy, AcmeCorp, BioMed Global, y otros siete obtiene una fila de usuario, un login, diez espacios de trabajo de operador vía la tabla external_memberships (migración 121). Cambie con un clic. Las reservas, hojas de tarifas, hitos, facturas y conversaciones de cada operador están aisladas por connection_id: no hay ruta de API a través de la cual los datos se difundan entre operadores.
Las credenciales de su API de transportista viven a nivel de external_organization (migración 289): se configuran una vez, se cifran vía el plugin de KMS, se reutilizan en cada espacio de trabajo de operador que sirve.
CONFIDENCIALIDAD · ARQUITECTÓNICA
Arquitectura, no apretón de manos. redactFor(entity, row, viewerRole) real en server/src/modules/portal-shell/redaction.ts: el mismo patrón que los portales de proveedor y de cliente.
ALCANCE POR CONEXIÓN
No hay ruta a través de la API del portal de logística que se difunda entre operadores. El acceso entre operadores devuelve 404 (no 403), de modo que se oculta la existencia del recurso, verificado en la suite de pruebas del proyector (portal-logistics/__tests__/projector.test.ts).
REDACCIÓN A NIVEL DE CAMPO
Precio de compra, precio de venta, margen, base de coste: eliminados antes de que la fila salga de la base de datos. Las funciones reales redactShipmentForClient y redactFor('shipment', raw, 'logistics') lo imponen. La excepción es el BOL: los datos del destinatario requeridos legalmente aparecen en el documento BOL, gobernados por la visibilidad guiada por Incoterm (siguiente sección).
PRIVACIDAD DE TARIFAS
Las hojas de tarifas están acotadas por logistics_connection_id. El marketplace de tarifas del lado del operador existe para comparar entre proveedores (función Solo+), no al revés: los transitarios no pueden enumerar «quién más obtiene una tarifa mejor que yo». Los resultados de RFQ (ganada / perdida) se muestran al propio transitario pero nunca se agregan entre transitarios.
INCOTERMS · CONFIG DE VISIBILIDAD
El JSON visibility_config de la conexión (columna de la migración 122, documentación de esquema en la 291) establece la visibilidad por incoterm para origen y destino: país / puerto / ciudad / factory_name / factory_address / full_address. Más anulaciones por incoterm y anulaciones de etiqueta.
DDP · CIF · CFR
La identidad de la fábrica se abstrae en los documentos de envío. El transitario ve la dirección del operador como origen; los ajustes del inquilino del operador impulsan el campo de expedidor del BOL. El nombre de la fábrica nunca se renderiza al transitario salvo anulación explícita.
FOB · EXW · FCA
La fábrica es el expedidor legal en el BOL porque tiene que estar ahí legalmente. El nombre de la fábrica y la dirección de recogida son visibles para el transitario; el visibility_config aún puede restringir lo que ve el cliente posterior del operador (la redacción del portal de cliente se aplica por separado).
CONDUCTOR · PWA
Los conductores instalan el Portal de Logística en su pantalla de inicio —manifest.webmanifest + service worker—, inician sesión una vez, y obtienen la cola de expedición acotada a las asignaciones donde son el conductor asignado. Sin tarifas, sin facturas, sin otros envíos. Los hitos capturan lat/lng GPS y subidas de fotos; el POD requiere firma + nombre del firmante + cargo del firmante antes de que se permita la transición completed.
Se registran seis valores de origen de hito por evento: user (entrada manual de ops), driver (captura móvil), carrier_api, ocr, scheduled_auto_advance, operator_override. La tabla de hitos es de solo adición: el trigger rechaza UPDATE, las correcciones insertan filas nuevas con supersedes_milestone_id apuntando al original.
Las auto-transiciones por geocerca, el pipeline de OCR para subida de BOL, y las apps nativas iOS / Android están en la hoja de ruta: el enum de origen de hito ya reserva sus espacios.
RESTRICCIÓN POR NIVEL · 15 CLAVES DE FUNCIÓN
El registro real tier_features (migración 291) define quince restricciones de función del portal de logística. Los proveedores de logística nunca ven un muro de pago; el nivel del operador conectado decide qué está disponible en su espacio de trabajo para ese operador. [Roadmap] las etiquetas marcan las funciones cuya clave tier_feature existe pero cuya implementación es posterior al lanzamiento.
Hoja de ruta = clave tier_features registrada en la migración 291 (véase db/migrations/291_logistics_tier_features_and_visibility_overrides.sql); la implementación de motor / agregación / UI aterriza tras el lanzamiento según la Especificación de Logística §19, §14, §25.
EN LA HOJA DE RUTA
La v1 lanza siete secciones, seis máquinas de estado, registro de hitos de solo adición, identidad multiinquilino, redacción a nivel de campo, visibilidad guiada por Incoterm, y restricción por nivel en quince claves de función. Varias capacidades que al equipo de marketing le encantaría reclamar están marcadas honestamente como hoja de ruta.
01
La migración 290 lanza el esquema de la tabla consolidation_groups. El motor de sugerencias que puebla esta tabla es un trabajo en segundo plano posterior al lanzamiento; la UI v1 aún no muestra nada. Clave de función de nivel logistics.ai_consolidation_suggestions registrada para Business+.
02
Claves de función de nivel logistics.cross_tenant_insights y logistics.network_reputation_display registradas para Business+. El motor de agregación y el umbral anti-inferencia de ≥3 operadores aterrizan tras el lanzamiento.
03
La consolidación entre operadores requiere mecánica de consentimiento aún no especificada. La migración 290 lo difiere explícitamente: «intencionadamente NO modelado aquí». Clave de función de nivel reservada.
04
El valor del enum de origen de hito 'ocr' está registrado; el servicio de OCR que ingiere una imagen de BOL, extrae los campos de contenedor / buque / precinto / viaje, y publica el hito correspondiente es posterior al lanzamiento.
05
Transiciones de estado de expedición en la entrada / salida de geocerca (arrived_at_pickup, arrived_at_delivery): no implementadas actualmente. La v1 captura el GPS en el momento en que el conductor toca el hito; el auto-avance desde geocerca viene más tarde.
06
Registro de integración v1: project44 (en vivo), Freightos Baltic / Xeneta / Drewry / MarineTraffic / Vizion (visibilidad de tarifa de flete + AIS). Las integraciones directas con Maersk / MSC / CMA CGM / ONE / HMM / Hapag-Lloyd, IATA Cargo IQ para aéreo, y FedEx / UPS / DHL / USPS para exprés aterrizan a medida que se conectan las API subyacentes. logistics_carrier_api_credentials.carrier_name es TEXT de texto libre, así que añadir un transportista no requiere cambios de esquema.
07
La PWA es la superficie de conductor v1 (manifest + service worker en vivo en client/public/). Las apps nativas con autenticación biométrica, API de cámara nativas, y notificaciones push son posteriores al lanzamiento.
08
La tabla logistics_carrier_api_credentials tiene una columna last_polled_at. El trabajo programado que sondea cada transportista conectado según su cadencia (diaria para marítimo, horaria en tramos aéreos críticos, 12 h para ferrocarril) es posterior al lanzamiento.
FAQ
No. No competimos con CargoWise, Magaya, Descartes, ni Project44. Somos la capa de coordinación entre su TMS y el operador que le contrató. Conserve su TMS para las operaciones internas; use el Portal de Logística para el flujo de trabajo del lado del operador que vive fuera de él: reservas que el operador inicia, visibilidad de hitos que el operador necesita, presentaciones de aduanas contra los envíos del operador, hojas de tarifas y RFQ que el operador consulta, y facturas de flete que el operador paga. La integración de TMS para operadores con CargoWise / Magaya / Descartes está en el nivel Enterprise.
Envíe un CSV de sus principales transitarios y un envío abierto. Pondremos en marcha un Portal de Logística en entorno de pruebas con la marca de su inquilino, su lista de transitarios como external_organizations, y guiaremos a un transitario real por aceptar un RFQ, publicar hitos, presentar aduanas, y emitir una factura. Sin datos de demo. Sus transitarios, su envío.