Como integrar SASCAR ou Autotrac ao seu TMS (sem digitação dupla)

Hoje a operação trabalha com duas verdades. A telemetria mostra onde o caminhão está, a que velocidade anda, se o motorista parou para descansar. O TMS mostra a carga, o cliente, o frete e o prazo. Entre as duas telas existe uma pessoa com um teclado, copiando número de placa, horário de chegada e jornada de uma janela para a outra. É lento, é caro e, pior, está errado uma boa parte do tempo.

Este guia explica como ligar a sua plataforma de rastreamento — SASCAR, Autotrac, Omnilink e similares — diretamente ao TMS, para que a posição, a jornada e os eventos cheguem sozinhos. Sem redigitação, sem planilha no meio do caminho. É um texto de quem faz isso na prática: o que dá para automatizar, onde as integrações costumam quebrar e qual o primeiro passo concreto.

O sintoma é sempre o mesmo. Um analista abre o portal da SASCAR ou da Autotrac, olha o mapa, anota a chegada do veículo na doca e digita esse horário no TMS para baixar a viagem. À tarde, abre de novo para fechar a jornada do motorista — horas de direção, paradas, refeição — e transcreve para a folha. No fim do mês, alguém cruza tudo isso à mão para o faturamento e para o eSocial.

Cada transcrição é uma chance de erro. Um horário trocado vira uma jornada irregular no papel. Uma placa digitada errado vira uma viagem órfã. E o custo invisível é o tempo: duas, três horas por dia de gente cara fazendo trabalho de copiar e colar. A informação já existe — ela só não atravessa de um sistema para o outro.

Plataformas de telemetria sérias expõem uma API: um endereço de onde o seu TMS pode buscar os dados de forma programática, sem ninguém olhando a tela. SASCAR, Autotrac, Omnilink, Onixsat e Cobli oferecem isso. O trabalho de integração é construir a ponte entre essa API e o seu TMS — seja ele Rodopar, Sankhya, TOTVS ou um sistema próprio.

Na prática, a ponte faz três coisas:

• Lê a posição e os eventos da telemetria em intervalos curtos (a cada poucos minutos, ou via notificação quando algo acontece).
• Traduz o vocabulário de cada lado — a placa, o motorista e a viagem precisam ser o mesmo na telemetria e no TMS.
• Grava no TMS pela porta certa, atualizando a viagem, a jornada ou o evento sem que ninguém digite.

É o oposto de um robô que mexe na tela fingindo ser uma pessoa. É sistema conversando com sistema, pela porta que cada um já oferece.

Não é tudo ou nada. Dá para começar por um ponto e expandir. O que normalmente flui da telemetria para o TMS:

• Posição e rota: latitude, longitude e velocidade atualizadas no TMS, sem abrir o portal do rastreador. O analista vê tudo numa tela só.
• Chegada e saída (geocercas): quando o veículo entra ou sai de um cliente, de um CD ou de um pedágio, o evento dispara e baixa a etapa da viagem automaticamente. Fim do horário anotado a olho.
• Jornada do motorista: início de jornada, direção, paradas, refeição e descanso capturados pela telemetria e gravados no TMS — base limpa para o controle de jornada e o eSocial.
• Eventos e alertas: excesso de velocidade, desvio de rota, parada não prevista, violação de cerca. Chegam ao TMS para virar tratativa, não ficam presos no e-mail.
• Hodômetro e horímetro: quilometragem para manutenção preventiva e rateio de custo, sem alguém anotar na planilha.

Com esses dados dentro do TMS, o passo seguinte é natural: jogar tudo num painel de Power BI e finalmente ter indicadores de SLA, ociosidade e cumprimento de jornada que se atualizam sozinhos.

Integração de telemetria parece simples até o segundo mês. Os tropeços que mais vemos:

• Não casar a chave entre os sistemas. Se a placa, o ID do motorista ou o código da viagem não baterem entre telemetria e TMS, a integração grava nos registros errados. O primeiro trabalho é alinhar esse cadastro — antes de qualquer linha de código.
• Confundir fuso e horário. APIs costumam devolver horário em UTC. Gravar sem converter para o horário de Brasília gera jornada de três horas a mais ou a menos. É erro clássico e silencioso.
• Bater na API a cada segundo. Toda plataforma tem limite de requisições. Uma integração mal calibrada toma bloqueio e para de funcionar sem avisar. A ponte precisa respeitar o ritmo de cada fornecedor.
• Não tratar falha. Internet cai, a API da telemetria fica fora do ar por minutos. Se a ponte não reprocessa o que faltou, abrem-se buracos na viagem. Integração boa tem memória do que já leu e retoma de onde parou.
• Geocerca larga demais. Uma cerca de raio grande dispara chegada a 500 metros do cliente. O horário fica impreciso e o SLA, contestável. Vale calibrar cerca por cerca.

Não. A integração lê e escreve em paralelo à rotina — ninguém precisa apagar o caminhão da estrada ou suspender o faturamento. O portal da telemetria continua funcionando exatamente como antes; a ponte apenas passa a copiar o que importa para o TMS.

O caminho saudável é por etapas. Sobe-se a integração lendo os dados sem gravar, compara-se com o que a equipe digita à mão por alguns dias e só então liga-se a gravação automática. Quando a confiança chega, o trabalho manual desliga sozinho — porque já não faz diferença. A tecnologia desaparece para que o seu negócio apareça.

Antes de escrever qualquer integração, três perguntas resolvem 80% do projeto:

• Qual a plataforma de telemetria e você tem acesso à API? SASCAR, Autotrac e Omnilink liberam credenciais de API mediante contrato. Vale confirmar com o fornecedor que esse acesso está habilitado.
• Qual o TMS e por onde ele recebe dados? Rodopar, Sankhya e TOTVS têm formas próprias de entrada — API, banco ou importação. Isso define o lado de gravação da ponte.
• Qual dor dói mais hoje? Comece pelo que custa mais caro: na maioria das transportadoras é o controle de jornada e a baixa automática de viagem por geocerca.

Com isso na mão, um piloto pequeno — uma frota, um cliente, um tipo de evento — prova o valor em semanas, não em meses. É exatamente o que entregamos no diagnóstico gratuito: mapeamos a telemetria, o TMS e o caminho mais curto entre os dois.