Sistema para transportadora: rastreio, romaneio e comprovante

Um sistema de transportadora que funciona cobre o fluxo inteiro: cotação, coleta, emissão de documento fiscal, formação de carga, romaneio, expedição, entrega com comprovante, ocorrência, rastreio para o cliente e fechamento de frete do motorista. Mas o item que decide se o projeto vai vingar não é nenhum desses módulos no servidor. É o app do motorista funcionar sem sinal de internet, porque a estrada não tem cobertura contínua e a entrega acontece mesmo assim.

Cotação e coleta: onde o frete nasce

A cotação precisa refletir a tabela real da empresa, não uma média. Isso significa cálculo por faixa de peso, por rota, por tipo de mercadoria e, principalmente, por peso cubado: carga leve e volumosa ocupa espaço que carga densa não ocupa, e cobrar só por quilo faz a transportadora perder dinheiro em volume.

Uma cotação bem modelada guarda:

• Origem, destino e faixa de distância ou zona tarifária
• Peso real e peso cubado, com o fator de cubagem por modal
• Componentes separados: frete peso, frete valor, taxas, pedágio, ad valorem
• Validade da proposta, porque tabela sem validade vira desconto eterno
• Vínculo com o cliente e com a tabela contratada, quando existe contrato

Da cotação aceita nasce a ordem de coleta, que já entra na fila do motorista de coleta com endereço, janela de horário, contato e volume esperado.

CT-e e MDF-e: os documentos fiscais do transporte

O transporte tem documentos próprios. O CT-e documenta a prestação do serviço de transporte, e o MDF-e consolida os documentos que estão na viagem, amarrando carga, veículo e condutor. São documentos fiscais eletrônicos com autorização, cancelamento e encerramento próprios.

Do ponto de vista de sistema, três coisas importam: emitir a partir do dado que já existe na carga sem redigitação, tratar o retorno de rejeição com mensagem que a operação entenda, e não deixar manifesto aberto depois de a viagem terminar. Manifesto esquecido em aberto é problema que aparece semanas depois, sempre no pior momento.

Roteirização, formação de carga e romaneio

Roteirizar é decidir a ordem e o agrupamento. Formar carga é encaixar isso na capacidade do veículo, respeitando peso, cubagem, restrição de circulação e janela de entrega do destinatário.

O romaneio é o resultado dessa decisão em forma de documento operacional: a lista do que embarca, em que ordem, com que documento e para quem. Ele serve para três públicos ao mesmo tempo, e por isso precisa ser gerado pelo sistema e não montado à mão:

• Para a expedição, é a conferência do que sai
• Para o motorista, é a sequência de trabalho do dia
• Para o financeiro, é a base do fechamento de frete

Conferência de expedição por leitura de código, com bipe de volume, é um dos investimentos de melhor relação custo e benefício em transportadora. Ele elimina a classe de erro mais cara da operação, que é entregar o volume certo no endereço errado.

O app do motorista precisa presumir que não há rede

Esse é o ponto técnico central. Um app que só grava com conexão vai falhar exatamente onde o dado é gerado. O desenho correto é offline first:

• Banco local no dispositivo com a rota e os documentos do dia baixados antes da saída
• Fila de eventos gravada localmente: chegada, entrega, ocorrência, foto, assinatura
• Sincronização em segundo plano quando a rede volta, com reenvio automático
• Idempotência por identificador de evento, para reenvio não duplicar entrega
• Resolução de conflito com regra definida: entrega registrada em campo vence alteração feita no escritório depois, e o conflito fica registrado para auditoria
• Compressão de foto antes de subir, porque rede de estrada é lenta e franquia de dados é finita
• Indicador visível de quantos eventos ainda não subiram, para o motorista saber o estado real

O ponto da idempotência não é teórico. Sem ele, o motorista com sinal instável registra uma entrega e o servidor recebe três, e alguém no escritório passa a tarde limpando duplicidade.

Comprovante de entrega: foto, assinatura e geolocalização

O comprovante digital substitui a discussão de "entregou ou não entregou" por evidência. O conjunto mínimo é foto do local ou da mercadoria entregue, assinatura na tela com nome e documento de quem recebeu, coordenada geográfica no momento do registro e carimbo de data e hora.

Um detalhe que costuma passar batido: a hora do dispositivo não é confiável. O celular pode estar com relógio errado ou ajustado manualmente. Grave as duas, a hora do dispositivo e a hora em que o servidor recebeu, e mostre a diferença quando for grande. Em disputa com cliente, essa distinção é o que sustenta a evidência.

Ocorrência de entrega segue a mesma lógica de evidência: destinatário ausente, recusa, endereço não localizado e avaria precisam de motivo padronizado (nada de campo livre), foto obrigatória e regra do que acontece depois, se é reentrega, devolução ou contato comercial.

Cada etapa, o dado que ela gera e onde falha

Telemetria e apontamento manual resolvem coisas diferentes

Rastreador de veículo e telemetria informam posição, velocidade, tempo parado e às vezes temperatura de baú. Isso é ótimo para segurança de carga, controle de jornada e previsão de chegada. Mas telemetria não sabe que o destinatário recusou a mercadoria, nem que a caixa chegou amassada.

O apontamento do motorista no app é o que traz o evento de negócio. Os dois se completam: a posição do rastreador valida o apontamento, e o apontamento explica a parada que o rastreador registrou. Sistema que aposta só em telemetria acaba com um mapa bonito e nenhuma informação sobre o que aconteceu com a carga.

Rastreio para o cliente final e integração com o embarcador

Do lado de fora, o cliente quer duas coisas: saber onde está e não precisar ligar. Um link público com token por remessa, mostrando status, previsão e comprovante quando entregue, resolve a maior parte das ligações. Notificação por WhatsApp nos marcos principais (coletado, em rota, entregue, ocorrência) reduz o resto.

Para o embarcador e para o ERP dele, o caminho é integração por API ou por troca de arquivo, com os mesmos eventos. Quem opera para grandes embarcadores costuma ter que se adaptar ao formato do cliente, e isso deve ser tratado como conector separado, para que um cliente novo não exija mexer no núcleo do sistema.

Custo de dispositivo e conectividade entram na conta

Projeto de logística que ignora hardware quebra na implantação. Vale definir desde o início quem paga o aparelho, se é do motorista ou da empresa, qual o plano de dados e o que acontece quando o aparelho quebra em viagem. Aparelho pessoal reduz custo e cria problema de privacidade e de rotatividade. Aparelho da empresa custa mais e dá controle.

A escolha muda a arquitetura: com aparelho pessoal e variado, o app precisa ser tolerante a modelos antigos e memória limitada, e a compressão de foto deixa de ser detalhe e vira requisito. É o tipo de decisão que precisa ser tomada antes da primeira linha de código, não depois do primeiro piloto na estrada.