Aguardando resposta3 itens
RESERVA
BKG-2026-4419 · Klang → Hamburg · 1×40HC
AceitarContraproposta
RESERVA
BKG-2026-4424 · Shanghai → Rotterdam · 2×40HC
AceitarContraproposta
RFQ
RFQ-2026-0188 · Port Klang → North Europe · Ocean FCL
Enviar cotação
REDE · PORTAL DE LOGÍSTICA
O cockpit onde seus despachantes trabalham. Com a identidade visual das suas operações.
Seu despachante te atualiza por e-mail. A equipe de dispatch registra marcos em uma planilha compartilhada que alguém vive esquecendo de atualizar. As datas de desembaraço alfandegário chegam como capturas de tela em PDF. As tabelas de frete ficam em uma pasta do SharePoint. Quando o contêiner atrasa, você fica sabendo pelo importador perguntando por quê. Seu "registro de embarque" é uma ficção reconstituída de três caixas de entrada e um WhatsApp.
O Portal logístico no TradeOS é um cockpit com a sua marca onde seus despachantes, corretores e transportadoras trabalham diretamente — mesmo banco de dados, limitado ao que precisam ver. A Inbox estruturada substitui e-mails avulsos. Marcos reais são registrados em máquinas de estado reais. Alfândega, dispatch, faturamento e conversas, tudo em um único registro. Identidade multi-tenant: um login, muitos workspaces de operador, cada um isolado. Gratuito para o prestador. Não substitui um TMS.
Agendar demonstraçãoVer preços →
Seções do portal
7 · inbox, embarques, dispatch, faturas e mais 3
Modos logísticos
Marítimo, aéreo, rodoviário, ferroviário, expresso e mais 3
Identidade multi-tenant
Um login, muitos workspaces de operador
Custo para o despachante
$0 · o operador paga pelo TradeOS
HPendrew EnergyÁrea de trabalho logística · Oceanway Forwarding, Klang
Trocar operador ▾
InícioCaixa de entrada · 4EmbarquesDespachoTarifasFaturas · 3MensagensConfigurações
Quarta-feira de manhã
Bom dia, Rachel. 4 itens exigem sua atenção hoje · 2 solicitações de reserva pendentes, 1 prazo de RFQ às 14h00, 1 exceção registrada durante a madrugada.
SITUAÇÃO GLOBAL
6 embarques ativos
Em risco1 exceção · crítica
CRÍTICO
SHP-2026-018 · Port of Klang — entrada no gate atrasada
Em mitigaçãoHoje5 compromissos
10:00Coleta · SHP-2026-026 · Long Beach
14:00Prazo RFQ-2026-0188 · Klang → N. Europe
18:00Prazo VGM · SHP-2026-024 · Ningbo
19:30Partida · SHP-2026-022 · Shanghai
22:15Chegada · SHP-2026-016 · Hamburg
Finanças$184,920 em aberto
Rascunhos2
Enviadas5
Em análise3
Aprovadas8
Paga · 30d14
Vencidas2
Contestadas1
O Painel Home real — faixa de boas-vindas, widget de mapa mundial com os embarques ativos em suas posições, fila de ações em duas colunas. Uma única chamada de backend (GET /portal/logistics/home) retorna tudo. O chrome de marca do operador (logotipo, cor, rótulo do workspace) é renderizado a partir das configurações de tenant do operador.
O MARCO QUE NUNCA É ATUALIZADO
É assim que a «visibilidade de embarques» realmente se parece hoje.
O agente de cargas é competente. O despachante é ágil. A página de rastreamento da transportadora existe. Nada disso ajuda quando o sistema de registro de um único embarque está dividido entre três caixas de entrada, duas planilhas, uma pasta no SharePoint e um grupo de WhatsApp em que ninguém está no mesmo fuso horário.
01 · OS MARCOS VIVEM EM UMA PLANILHA COMPARTILHADA
«Qual é a ETA?» — a resposta vem de uma aba que alguém esqueceu de atualizar.
Seu agente de cargas atualiza uma Google Sheet em uma cadência diferente da do importador que está te cobrando. O time de operações tem duas fontes de verdade — a planilha e a página de rastreamento da transportadora — e elas divergem em três dias. Quando você finalmente obtém a resposta, o container já passou pelo desembaraço aduaneiro sem que ninguém tenha percebido.
Planilha do agente→Registro do operador
Desvio de 3 dias·mesmo container
02 · AS ATUALIZAÇÕES ADUANEIRAS VIVEM EM THREADS DE E-MAIL
O despachante envia «protocolamos a declaração na terça» às 23h. Você lê na quinta.
O despachante aduaneiro é ágil, mas o canal dele é a caixa de entrada que estava aberta na hora. A notificação de liberação chega como anexo em PDF. Você a encaminha para a contabilidade, que não encontra o número da declaração porque está dentro do screenshot. O embarque sai com três dias de atraso porque ninguém sabia que tinha sido liberado.
E-mail despachante · PDF→Registro aduaneiro
3 dias de atraso·declaração enterrada no screenshot
03 · UM AGENTE, QUINZE PORTAIS
Seu agente ignora o portal que você enviou porque ele tem outros quinze.
Você implanta «seu» portal e pede ao agente de cargas que faça login para atualizar os marcos. Ele tem um para cada cliente. Não acessa nenhum deles de forma consistente. Seus dados ficam desatualizados no momento em que ele fecha a aba do navegador. O portal vira um sistema que o agente trata como obrigação — até deixar de tratar.
Mais um portal→Agente o ignora
1 login · muitas ops·usado por ser compartilhado
7 SEÇÕES · UM PORTAL
Cada tela em que o despachante trabalha, em uma única navegação.
Dados reais de LOGISTICS_NAV.flatLinks a partir de client/src/lib/navConfig.ts. A navegação inferior para dispositivos móveis usa os primeiros quatro itens: Home · Inbox · Embarques · Dispatch.
Início
Faixa de boas-vindas + mapa-múndi com Embarques ativos + fila de ações em 2 colunas (Needs Response, Em risco, Today, Money). Uma única chamada ao backend retorna todos os dados.
Caixa de entrada
A fila de respostas estruturadas. 3 sub-abas (reservas, RFQs, contestações), cada uma com as seções "Needs Action", "Awaiting Response" e "Recently Decided". Contrapropostas sem resposta são promovidas automaticamente após 48 h.
Embarques
5 abas — Tracking, Contêineres, Custos, Alfândega, Histórico. Uma única chamada ao backend (/shipments/overview/all) retorna todos os dados; as abas são projeções.
Despacho
Máquina de 11 estados para transporte rodoviário. assigned → accepted_by_driver → en_route_to_pickup → arrived → loaded → departed → en_route_to_delivery → arrived → unloaded → completed (+ ramo de falha). Conclusão condicionada ao POD.
Tarifas
Tabelas de tarifas com válido a partir de / válido até / versão / substituído por. Sobretaxas por linha, faixas de volume, cobrança mínima. Importação em massa de 1 a 500 linhas de forma atômica.
Faturas
Máquina de 10 estados. 3 tipos: por embarque, consolidado mensal, ad hoc. Ramo de contestação com rastreamento de resolução.
Mensagens
Mensagens em threads com escopo por conexão de operador. Vinculadas a uma entidade (reserva, RFQ, embarque, fatura). Notificações pela mesma infraestrutura dos demais portais.
A CAIXA DE ENTRADA · 1.252 LINHAS DE IU
A caixa de entrada do agente de cargas vive no seu registro — não em três threads de e-mail.
Três tipos de fluxo compartilham uma única fila porque, do ponto de vista do agente, todos seguem o mesmo padrão: ”resposta estruturada, prazo crítico, sou o gargalo” — solicitações de reserva, RFQs e disputas de fatura. A interface Inbox reúne tudo em uma fila com formulários de ação inline, de modo que o caminho padrão não exige nenhuma navegação.
Todos 12Reservas 4Cotações (RFQs) 5Disputas 3
Requer ação · 4
RESERVA
BKG-2026-4419
Klang → Hamburg · Ocean FCL · 1×40HC · pronto em 28 de maio
RESERVADESATUALIZADO · ACOMPANHAR
BKG-2026-4401 · counter-quoted
Ningbo → Hamburg · Contraproposta enviada há 51 h · aguardando operador
RFQ
RFQ-2026-0188
Port Klang → Norte da Europa · Ocean FCL · prazo 14:00 hoje (5 h)
DISPUTA
INV-2026-1142 · disputed
Cobrança de sobreestadia contestada · $1,840 · nota do operador ”navio chegou 2 dias antes do previsto”
Aguardando resposta · 5
5 cotações enviadas · aguardando decisão do operador · mais antiga 18h
Decididos recentemente · 3
2 cotações ganhas · 1 cotação perdida · expanda para ver
EMBARQUES · 5 ABAS · UMA ÚNICA CHAMADA BACKEND
Cinco projeções dos mesmos dados de embarque.
A superfície de trabalho principal do agente de cargas. GET /portal/logistics/shipments/overview/all retorna tudo em uma única chamada; a página mantém os dados em memória e os projeta por aba. Sem fan-out do navegador, sem recarregamento por aba.
Rastreamento
Mapa-múndi + lista com status, rota, último marco e exceções abertas. Clique em uma linha → expansão contextual com a cronologia completa de marcos e as exceções abertas para aquele embarque.
Planejamento de contêineres
Cada contêiner de cada embarque, com tipo, utilização (CBM / peso vs. máximo do contêiner), número de lacre e data de carregamento. A visão ”o que está carregado e onde”.
Custos e frete
Receita por embarque proveniente de faturas, valor pago, saldo em aberto. Totais agregados no topo. Acesse o detalhe da fatura a partir de qualquer linha.
Alfândega e Compliance
Declarações aduaneiras por embarque: jurisdição (ISO 3166), tipo de declaração (importação/exportação/trânsito), status (máquina de 7 estados), número da declaração, códigos HS declarados. Totais agregados desembaraçado/pendente/retido no topo.
Histórico
Consolidação cronológica de eventos, marcos e exceções de todos os embarques deste agente de cargas. Feed ordenado por tempo. A superfície do registro de auditoria.
MÁQUINAS DE ESTADO · APLICADAS NO BD
Seis ciclos de vida pelos quais o agente de cargas passa — sem nunca sair do seu registro.
Cada workflow possui uma state machine explícita — tipos enum do Postgres ou restrições CHECK. Regras de transição na camada de serviço validam quais estados podem avançar para quais. Sem strings mágicas, sem estado no lado da interface.
RESERVA · 6 ESTADOS
Aguardando aceitação→Contraproposta emitida→Aceito
Estados terminais: recusado · cancelado · expirado. A aceitação cria o embarque vinculado.
PEDIDO DE COTAÇÃO · 7 ESTADOS
Enviada→Cotada→Ganha
Ramificações: perdida · recusa de cotação · expirada · retirada. O backend impõe uma única cotação pendente por RFQ.
DESPACHO · 11 ESTADOS
Atribuído→Aceito pelo motorista→A caminho da coleta→Chegou ao ponto de coleta→Carregado→Partiu→A caminho da entrega→Chegou ao ponto de entrega→Descarregado→Concluído
Qualquer estado ativo pode transitar para failed com indicação de motivo. A conclusão exige que o POD seja capturado previamente (bloqueado por tooltip na interface).
FATURA · 10 ESTADOS
Rascunho→Submetida→Em análise→Aprovada→Agendada→Parcialmente paga→Paga
Ramificações: vencida · contestada · baixada. Três tipos de fatura: por embarque · consolidada mensal · ad hoc.
DECLARAÇÃO ADUANEIRA · 7 ESTADOS
Rascunho→Submetida→Aceita→Desembaraçada
Ramificações: retida (documentos / pagamento / inspeção pendentes) · questionada (a alfândega solicitou esclarecimentos) · rejeitada (terminal). Por jurisdição × tipo de declaração.
EXCEÇÕES · 3+3 ENUM
Info/Aviso/Crítico
Severidade × status. O status evolui conforme aberto → em mitigação → resolvido. Distinto de marcos — declarado, mitigação rastreada, resolução auditada.
8 MODOS LOGÍSTICOS · MODELOS DE MARCOS POR MODO
Oito modos logísticos — porque embarques reais não cabem em um único modelo.
O enum logistics_mode possui oito valores, cada um com seu próprio template de marcos por modo (validado no servidor, não via enum de banco de dados, permitindo adicionar novos marcos sem ALTER TYPE).
Marítimo FCL
Campos: número do contêiner, navio, viagem, número do BOL, VGM, portos de carga e descarga.
Marcos: reservado → VGM registrado → gate-in → carregado → partido → transembarcado → chegado → descarregado → alfândega → Entregue.
Marcos: reservado → VGM registrado → gate-in → carregado → partido → transembarcado → chegado → descarregado → alfândega → Entregue.
Marítimo LCL
Campos: CFS, BOL master e house, referência de consolidação, Packing List.
Marcos: reservado → recebido no CFS → consolidado → carregado → partido → chegado → desconsolidado → alfândega → Entregue.
Marcos: reservado → recebido no CFS → consolidado → carregado → partido → chegado → desconsolidado → alfândega → Entregue.
Aéreo
Campos: AWB, voo, ULDs, aeroportos, declaração de mercadorias perigosas.
Marcos: reservado → manifesto → entrega ao transportador → embarcado → em voo → pousado → recebido → alfândega → Entregue.
Marcos: reservado → manifesto → entrega ao transportador → embarcado → em voo → pousado → recebido → alfândega → Entregue.
Caminhão FTL
Campos: placa, motorista, semirreboque, contêiner, coleta e entrega em parada única.
Marcos: Autômato de dispatch completo com 11 estados (conforme acima).
Marcos: Autômato de dispatch completo com 11 estados (conforme acima).
Caminhão LTL
Campos: sequenciamento por parada, consolidação com remetentes mistos, POD assinado por parada.
Marcos: autômato de dispatch com ciclos de coleta e entrega em múltiplas paradas.
Marcos: autômato de dispatch com ciclos de coleta e entrega em múltiplas paradas.
Transporte local
Campos: chassi, agendamento portuário, liberação de retenção aduaneira, indicador de drop de contêiner ou descarga direta.
Marcos: autômato de dispatch + fluxo de agendamento portuário.
Marcos: autômato de dispatch + fluxo de agendamento portuário.
Ferrovia
Campos: vagão, trem, terminais, marcos de mudança de bitola.
Marcos: despachado → carregado → partido → fronteira → mudança de bitola → chegado → descarregado → entrega.
Marcos: despachado → carregado → partido → fronteira → mudança de bitola → chegado → descarregado → entrega.
Expresso / encomenda
Campos: número de rastreamento, transportador, tentativas de entrega last-mile, POD assinado.
Marcos: coletado → em trânsito → saiu para entrega → Entregue (ou devolvido).
Marcos: coletado → em trânsito → saiu para entrega → Entregue (ou devolvido).
UM AGENTE DE CARGAS · VÁRIOS OPERADORES
Um único login para o agente. Vários espaços de trabalho de operadores. Cada um isolado.
Um agente de cargas que atende Pendrew Energy, AcmeCorp, BioMed Global e outros sete clientes possui uma única linha de usuário, um único login e dez espaços de trabalho de operadores via tabela external_memberships (migração 121). Alterne com um clique. Reservas, tabelas de tarifas, marcos, faturas e conversas de cada operador são isolados por connection_id — não existe nenhum caminho de API pelo qual os dados se propaguem entre operadores.
Suas credenciais de API de transportadora residem no nível external_organization (migração 289) — configuradas uma única vez, criptografadas via plugin KMS e reutilizadas em cada espaço de trabalho de operador que você atende.
Pendrew Energy
AcmeCorp Trading
BioMed Global
+ 7 espaços de trabalho de operadores adicionais
Cada um isolado · operadores não veem os dados uns dos outros
CONFIDENCIALIDADE · ARQUITETURA
A confidencialidade entre operadores é imposta pela plataforma, não por políticas.
Arquitetura, não um acordo informal. Real redactFor(entity, row, viewerRole) em server/src/modules/portal-shell/redaction.ts — o mesmo padrão dos portais de fornecedor e cliente.
ESCOPO POR CONEXÃO
Cada consulta carrega um connection_id proveniente do JWT
Não existe nenhum caminho pela API do portal de logística que se propague entre operadores. Acessos entre operadores retornam 404 (não 403), de modo que a existência do recurso permanece oculta — verificado na suite de testes do projector (portal-logistics/__tests__/projector.test.ts).
REDAÇÃO EM NÍVEL DE CAMPO
A logística nunca vê valores comerciais
Preço de compra, preço de venda, margem, base de custo — removidos antes que o registro saia do banco de dados. As funções redactShipmentForClient e redactFor('shipment', raw, 'logistics') aplicam essa regra. A exceção é o BOL: os dados do consignatário exigidos por lei constam no documento BOL, regidos pela visibilidade orientada por Incoterms (próxima seção).
PRIVACIDADE DE TARIFAS
Suas tarifas com um operador não são visíveis para os demais
As tabelas de tarifas são limitadas por logistics_connection_id. O Marketplace de tarifas no lado do operador serve para comparar provedores (funcionalidade Solo+), não o contrário — os transitários não conseguem verificar ”quem obtém tarifas melhores do que as minhas”. Os resultados de RFQ (ganhos / perdidos) são exibidos ao próprio transitário, mas nunca agregados entre transitários.
INCOTERMS · CONFIGURAÇÃO DE VISIBILIDADE
O que o agente de carga visualiza depende de qual parte é o remetente legal.
O JSON visibility_config da conexão (coluna de migração 122; documentação do schema em 291) define a visibilidade por Incoterm para origem e destino — país / porto / cidade / factory_name / factory_address / full_address. Inclui também substituições por Incoterm e substituições de rótulos.
DDP · CIF · CFR
Operador = remetente legal de registro
A identidade do fabricante é abstraída nos documentos de embarque. O agente de carga vê o endereço do operador como origem; as configurações do tenant do operador controlam o campo do remetente no BOL. O nome do fabricante nunca é exibido ao agente de carga, salvo substituição explícita.
OrigemEndereço do operador ▸ Port Klang, MY
DestinoEndereço do consignatário ▸ Hamburg, DE
Remetente BOLEntidade jurídica do operador
FOB · EXW · FCA
Factory = remetente legal de registro
O fabricante é o remetente legal no BOL por exigência legal. O nome do fabricante e o endereço de coleta são visíveis ao agente de carga; a visibility_config ainda pode restringir o que o cliente downstream do operador visualiza (a ocultação no portal do cliente se aplica separadamente).
OrigemFactory ▸ Crescent Mfg, Klang
DestinoConforme Incoterm
Remetente BOLEntidade jurídica do fabricante
MOTORISTA · Oceanway
SHP-2026-026 · DRAYAGE
Long Beach Port → AcmeCorp DC, Compton
ESTADO ATUAL
Chegou ao local de coleta
PRÓXIMO
carregado → saído
Confirmar carregamento
PWA · tolerante a modo offline · sincroniza ao reconectar
MOTORISTA · PWA
O mesmo portal, restrito a ”apenas seus despachos.”
Os motoristas instalam o Portal logístico na tela inicial — manifest.webmanifest + service worker — fazem login uma única vez e acessam a fila de despacho filtrada para as atribuições em que são o motorista designado. Sem tarifas, sem faturas, sem outros embarques. Os marcos registram coordenadas GPS (latitude/longitude) e uploads de fotos; o POD exige assinatura, nome e cargo do signatário antes que a transição para completed seja permitida.
Seis valores de origem de marco são registrados por evento: user (entrada manual de operações), driver (captura mobile), carrier_api, ocr, scheduled_auto_advance, operator_override. A tabela de marcos é append-only — UPDATE é recusado por gatilho; correções inserem novas linhas com supersedes_milestone_id apontando para o registro original.
Transições automáticas orientadas por geofence, pipeline OCR para upload de BOL e aplicativos nativos iOS e Android estão no roadmap — o enum de origem do marco já reserva os respectivos slots.
CONTROLE POR NÍVEL · 15 FUNCIONALIDADES
Gratuito para o operador logístico. O tier do operador decide quais funcionalidades são exibidas.
O registro tier_features real (migração 291) define quinze gates de funcionalidades do portal logístico. Prestadores de serviços logísticos nunca veem um paywall; o tier do operador conectado decide o que está disponível no seu workspace para aquele operador.[Roadmap] As tags indicam funcionalidades cuja chave tier_feature existe, mas cuja implementação está prevista para após o lançamento.
Funcionalidade
Starter
Solo
Business
Enterprise
Reservas + Embarques + marcos manuais
✓
✓
✓
—
✓
PWA do motorista + registro móvel de marcos + POD
✓
✓
✓
—
✓
Upload de Documentos + compartilhamento por tag de visibilidade
✓
✓
✓
—
✓
Tabelas de tarifas + fluxo RFQ (reserva em 6 estados · RFQ em 7 estados)
✓
✓
✓
—
✓
Integração API de transportadora (project44 ativo; outros em desenvolvimento)
—
✓
✓
—
✓
Marketplace multi-transportadora (comparar cotações)
—
✓
✓
—
✓
Documentos aduaneiros automatizados (preenchimento de template por embarque)
—
—
✓
—
✓
Declaração direta US ABI/ACE (despachantes licenciados)
—
—
—
—
✓
Sugestões de consolidação por AIRoteiro
—
—
—
—
✓
Análises de desempenho cross-tenantRoteiro
—
—
—
—
✓
Agregação de reputação na redeRoteiro
—
—
—
—
✓
Consolidação multi-operadorRoteiro
—
—
—
—
✓
APIs de transportadora personalizadas · integração direta TMS · SAML SSO
—
—
—
—
✓
Roadmap = chave tier_features registrada na migração 291 (consulte db/migrations/291_logistics_tier_features_and_visibility_overrides.sql); a implementação de engine, agregação e UI será entregue após o lançamento conforme a Logistics Spec §19, §14, §25.
NO ROADMAP
O que está chegando ao Portal logístico.
A v1 traz sete seções, seis máquinas de estado, um registro de marcos somente de adição, identidade multi-tenant, redação em nível de campo, visibilidade orientada por Incoterms e tier gating em quinze chaves de funcionalidade. Diversas capacidades que o time de marketing gostaria de reivindicar já estão sinalizadas honestamente como roadmap.
01
Sugestões de consolidação por IA
A migração 290 entrega o esquema da tabela consolidation_groups. O mecanismo de sugestão que popula essa tabela é um processo em segundo plano pós-lançamento; a interface v1 ainda não exibe nada. Chave de funcionalidade de tier logistics.ai_consolidation_suggestions registrada para Business+.
02
Insights de desempenho entre tenants + reputação de rede
Chaves de funcionalidade de tier logistics.cross_tenant_insights e logistics.network_reputation_display registradas para Business+. O mecanismo de agregação e o limite anti-inferência de ≥3 operadores serão disponibilizados após o lançamento.
03
Consolidação multi-operador (Enterprise)
A consolidação entre operadores requer mecanismos de consentimento ainda não especificados. A migração 290 adia isso explicitamente — "intentionally NOT modelled here". Chave de funcionalidade de tier reservada.
04
Pipeline OCR para upload de BOL
O valor enum de fonte de milestone 'ocr' está registrado; o serviço OCR que processa uma imagem de BOL, extrai os campos de contêiner / embarcação / lacre / viagem e publica o milestone correspondente é pós-lançamento.
05
Transições automáticas baseadas em geofence
As transições de estado de dispatch na entrada/saída de geofence (arrived_at_pickup, arrived_at_delivery) não estão implementadas atualmente. A v1 captura o GPS no momento em que o motorista confirma o milestone; o avanço automático por geofence será adicionado posteriormente.
06
Cobertura de API de transportadoras — integrações diretas
Registro de integrações v1: project44 (live), Freightos Baltic / Xeneta / Drewry / MarineTraffic / Vizion (tarifas de frete + visibilidade AIS). As integrações diretas com Maersk / MSC / CMA CGM / ONE / HMM / Hapag-Lloyd, IATA Cargo IQ para aéreo e FedEx / UPS / DHL / USPS para expresso terrestre serão conectadas conforme as APIs subjacentes forem habilitadas. logistics_carrier_api_credentials.carrier_name é um campo TEXT livre, portanto adicionar uma transportadora não requer alterações no esquema.
07
Aplicativo nativo iOS / Android para motoristas
A PWA é a interface do motorista na v1 (manifest + service worker ativos em client/public/). Aplicativos nativos com autenticação biométrica, APIs de câmera nativas e notificações push são pós-lançamento.
08
Cadência de polling agendada das APIs de transportadoras
A tabela logistics_carrier_api_credentials possui uma coluna last_polled_at. O job agendado que consulta cada transportadora conectada conforme sua cadência (diária para marítimo, horária em trechos aéreos críticos, a cada 12h para ferroviário) é pós-lançamento.
FAQ
As perguntas que todo agente de carga faz primeiro.
Não. Não competimos com CargoWise, Magaya, Descartes nem Project44. Somos a camada de coordenação entre o seu TMS e o operador que o contratou. Mantenha seu TMS para operações internas; use o Portal logístico para o workflow do lado do operador que existe fora dele — reservas iniciadas pelo operador, visibilidade de marcos que o operador precisa, declarações aduaneiras sobre os Embarques do operador, tabelas de tarifas e RFQs que o operador consulta, e faturas de frete que o operador paga. A integração TMS para operadores com CargoWise / Magaya / Descartes está disponível no tier Enterprise.
Envie-nos sua lista de agentes de carga e uma reserva em andamento. Configuraremos um Portal logístico em sandbox e guiaremos um dos seus agentes em 30 minutos.
Envie um CSV dos seus principais agentes de carga e um Embarque em aberto. Configuraremos um Portal logístico em sandbox com a identidade visual do seu tenant, sua lista de agentes como external_organizations, e guiaremos um agente real pelo processo de aceitar um RFQ, registrar marcos, realizar uma declaração aduaneira e emitir uma fatura. Nenhum dado de demonstração. Seus agentes, seu Embarque.