Entendendo mensagem viagem no contexto do CT-e
O que é mensagem viagem na prática
A mensagem viagem é um arquivo XML que faz parte do lote de dados enviados pela SEFAZ para validação do Conhecimento de Transporte Eletrônico (CT-e). Ele não é um documento independente — funciona como uma camada adicional de autorização que acompanha o CT-e quando se trata de transporte de cargas em território nacional. A maioria dos sistemas gera esse arquivo automaticamente durante o processo de autorizacao, mas o cara que vai precisar mexer nisso no dia a dia quase sempre é quem enfrenta problemas com homologacao ou Rejeicao 270. Eu já passei madrugada inteiro brisando com isso quando uma transportadora de médio porte que eu consultava tentava enviar CT-e com varias viagens e o sistema deles gerava mensagem viagem com codigos de evento desatualizados. O problema mais comum que eu vejo não é a estrutura do XML em si — é a ordem em que os eventos chegam na SEFAZ. Eles precisam ser processados sequencialmente, senao o sistema rejeita sem motivo aparente.
Como gerar e validar a mensagem viagem corretamente
Vamos direto ao que funciona. Primeiro voce precisa ter o protocolo de autorizacao do CT-e em mos. Esse protocolo contem o numero de registro que sera usado para assinar digitalmente a mensagem viagem. Sem ele, o arquivo gerado simplesmente nao entra na SEFAZ. A estrutura basica do XML exige os campos infCTe, ide, emit, dest, and transportador. Se algum deles vier vazio, o Validador da SEFAZ corta na hora. O arquivo deve ser assinado com certificado A3 ou A1, e a assinantura precisa estar no formato det_CTe() conforme a especificacao tecnica da SEFAZ. Eu recomendo usar o metodo de assinatura via biblioteca nativa do seu sistema contable em vez de tentar montar o XML manualmente. A maioria dos erros que eu vejo vem justamente de gente montando tags com nomes quase certos mas com namespace errado.
Uma coisa que poucos sabem: a mensagem viagem tem um limite de caracteres no campo cMunCarreg que varia de acordo com a uf de carregamento. Se voce registrar um municipio com nome longo demais, o sistema pode aceitar a validacao local mas rejeitar na SEFAZ da destinacao. Eu resolvi isso criando uma tabela de mapeamento dos principais municipios com suas variantes de nomeacao oficial. Economiza meia hora de tentativa e erro em cada enviocampo.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Problemas comuns e workarounds
O erro 270 (rejeicao) aparece quando a mensagem viagem e o CT-e principal não estão sincronizados quanto ao horário de evento. Isso acontece com mais frequência em operações noturnas onde o sistema do cliente processa as autorizações fora do horário comercial e os timestamps ficam desfasados. A solução é forçar a sincronização do relógio do servidor antes do envio e usar a versão 4.00 do leiaute, que é mais tolerante com pequenas divergências de horário. Outro problema recorrente: sistemas mais antigos geram a mensagem viagem sem o grupo infMunCarreg quando o frete é isento. A SEFAZ aceita isso apenas em determinadas condições, e muitas vezes o validador local passa mas a SEFAZ rejeita. A correção é incluir o campo mesmo quando vazio, usando a tag vFrete=0 explicitamente. Eu costumo colocar isso como regra fixa nos meus layouts de geração automática.
Download e ferramentas úteis
O Manual de Orientações do Contribuinte da SEFAZ contém a especificação completa da mensagem viagem. A versão mais recente está disponível no portal da SEFAZ Nacional. Para quem quer testar sem depender de um sistema comercial, o ambiente de homologação da SEFAZ permite enviar arquivos de teste diretamente. O link oficial muda de tempo em tempo, mas sempre está em www.sefazvirtual.fazenda.gov.br sob a seção de CT-e. Existem validadores gratuitos que circulam em fóruns técnicos, mas a maioria não cobre todas as regras de negócio atuais. O validador oficial da SEFAZ é o único que reflete exatamente o que será aplicado na recepção. Eu uso ele antes de qualquer envio em produção, e antes dele uso uma validação local com esquema XSD próprio para evitar falhas óbvias.
Limitações que ninguém conta
Mensagem viagem não é solução para tudo. Ela funciona bem para CT-e padrão com um único remetente e um único destinatário. Quando você tem CT-e com várias subcontratações ou transporte multimodal, a coisa complica porque cada trecho pode exigir uma mensagem diferente. Nesses casos, a recomendação é segregar os serviços e emitir CT-e separados por trecho. Tentar empacotar tudo numa única mensagem viagem gera inconsistência de dados e rejeição segura. Também não adianta confiar cegamente na geração automática do sistema contábil. Eu já vi empresa tentar validar mais de 300 CT-e num único lote e a mensagem viagem foi gerada com IDs duplicados porque o sistema não esperou o retorno do primeiro lote. O resultado foi rejeição em massa e perda de prazos de entrega. O controle manual do sequenciamento dos eventos resolve isso.
