Rejeição 517: atributo versao ausente na raiz da mensagem
Revisão editorial em 16 de out. de 2026. Confira as versões e condições das regras nas fontes do artigo.
A rejeição 517, regra D01b, detalha a falta do atributo versao na tag raiz da mensagem. É necessário localizar a raiz exigida pelo serviço chamado: versões encontradas em elementos internos podem ter outro significado.
Nesta página:
- Qual é o alcance da regra D01b para 517?
- Exemplo: verEvento preenchido, versão da mensagem omitida
- Como evitar corrigir o arquivo errado?
- O que verificar depois da inclusão correta?
Qual é o alcance da regra D01b para 517?
O MOC apresenta a 517 na linha geral de ausência de atributo versao e a 568 na linha específica do lote de NF-e. O diagnóstico precisa seguir o serviço efetivamente chamado e sua mensagem de entrada.
D01b é facultativa e pode detalhar falha de schema D01. Confira a raiz da mensagem, o atributo e a versão prevista no contrato. A declaração XML e as versões de SOAP ou TLS não substituem esse atributo.
Fontes: MOC Anexo I, regra D01b.
Exemplo: verEvento preenchido, versão da mensagem omitida
Em um registro de eventos hipotético, o integrador preenche verEvento dentro das informações do evento, mas omite a versão requerida na raiz da mensagem. O primeiro valor identifica o leiaute específico do evento; não preenche a exigência estrutural da raiz.
Compare os caminhos no arquivo de entrada e no XSD. Uma versão válida em um nível não torna completa a estrutura em outro. Corrija o componente que monta a mensagem geral, preservando as informações do evento e sua finalidade real.
Fontes: MOC Anexo I, regra D01b.
Como evitar corrigir o arquivo errado?
Identifique a requisição que foi efetivamente enviada. Arquivo de retorno, documento processado e mensagem de entrada podem conter atributos semelhantes. A correção deve ser feita no gerador ou no encapsulamento responsável pela requisição, antes de validar o conteúdo final.
Não copie o valor de versão de um exemplo de outro serviço. As atualizações de schemas, como as da NT 2026.004, devem ser consideradas com o serviço e ambiente correspondentes. Uma versão presente mas incompatível pode conduzir à 239.
Fontes: MOC Anexo I, regra D01b; NT 2026.004 — CNPJ alfanumérico.
O que verificar depois da inclusão correta?
Valide toda a mensagem no XSD oficial e confira sua assinatura quando exigida. Para eventos, ainda existem validações independentes de tipo, versão específica e detEvento: 491, 492 e 493. Passar na exigência da raiz não comprova registro do evento.
Se uma tentativa anterior não teve resposta conclusiva, esclareça seu resultado antes de repetir a operação. Mantenha os identificadores e o histórico em ambiente protegido, sem inventar valores ou alterar a finalidade fiscal para obter aceitação.
Fontes: MOC Anexo I, regra D01b.
Limite do exemplo e preservação dos dados
A estrutura concreta depende do serviço e do arquivo original protegido. O exemplo textual distingue atributos de níveis diferentes sem fabricar evento, chave ou assinatura. A conferência deve preservar o original e ocorrer em ambiente protegido; não publique certificado, senha, chave privada ou dados fiscais de clientes.
Fontes oficiais
- MOC 7.0 — Anexo I, versão 7.00. p. 72, regra D01b, código 517; quadro completo e notas da seção.
- MOC 7.0 — Visão Geral, versão 7.00. pp. 50–51 e 64, mensagem e schema; pp. 100–101, envEvento, versões e mensagem de retorno.
- NT 2026.004 — CNPJ alfanumérico, versão 1.01. pp. 3–4, cronograma e alcance dos schemas; pp. 5–14, campos alterados e mensagens de serviços, incluindo envEvento p. 10.