Rejeição 517: falta o atributo versao na raiz da mensagem fiscal

A rejeição 517, “Falha no schema XML – inexiste atributo versao na tag raiz da mensagem”, aponta uma informação estrutural ausente no XML enviado. O suporte do emissor precisa verificar a raiz da mensagem de dados e o atributo que declara seu leiaute. Trocar números de versão ao acaso pode apenas substituir essa falha por outra.

No MOC 7.0, a verificação D01b é facultativa e sucede uma falha de schema. O mesmo manual separa a ausência de versão na raiz do lote de autorização, associada a 568. O diagnóstico começa, portanto, pela pergunta: qual serviço e qual mensagem retornaram 517?

Há várias “versões” num único processo

Uma empresa pode usar um sistema comercial com versão própria, gerar documentos no leiaute 4.00 e transmitir eventos cuja estrutura segue outra versão. Esses números não precisam ser iguais. Atualizar o aplicativo não prova, por si só, que ele passou a declarar corretamente o atributo exigido.

Também há diferenças dentro do próprio XML. A declaração inicial pode indicar version="1.0", referente à linguagem XML. A mensagem fiscal usa o atributo versao, sem acento, ligado ao elemento indicado pelo schema. Escrever versão, version ou criar um elemento filho chamado versao não equivale ao atributo esperado.

Num evento, a versão da raiz envEvento, a versão de evento e a versão do detalhe têm lugares e funções diferentes. O campo verEvento e o atributo de detEvento não substituem automaticamente a informação da raiz. A versão da aplicação, quando informada em verAplic, tampouco satisfaz essa exigência.

Confira o contrato antes de escolher o valor

Para os serviços básicos apresentados no MOC, as referências documentais são:

• consReciNFe, consSitNFe e consStatServ: mensagens de consulta nos leiautes 4.00, cada qual com seu schema e finalidade

• inutNFe: solicitação de inutilização no leiaute 4.00

• ConsCad: consulta cadastral no leiaute 2.00, sem converter sua versão para a da NF-e

• envEvento: estrutura geral de recepção de eventos apresentada em envEvento_v1.00.xsd, com os detalhes definidos para cada tipo

• consGTIN: contrato de consulta da NT 2022.001, cujo atributo da raiz é obrigatório; a versão concreta depende do schema publicado para esse serviço

A numeração da nota técnica não é a versão a colocar no XML. NT 2020.001 v1.60, por exemplo, identifica uma revisão documental sobre manifestação; isso não autoriza preencher versao="1.60" em qualquer camada do evento.

Também não copie literalmente “v9.99” de um nome de schema apresentado no manual. Essa indicação genérica pede a seleção do arquivo correspondente à versão efetiva. O fornecedor deve confirmar o pacote oficial utilizado, seus arquivos dependentes e o serviço que o receberá.

Os ramos de evento exigem uma conferência própria

A ausência do atributo aparece nas regras gerais de EPEC da NF-e 55 e, separadamente, de EPEC da NFC-e 65. Ambos usam envEvento na mensagem externa, mas suas notas técnicas, campos e disponibilidade operacional não são intercambiáveis. Para NFC-e, confirme a adoção do EPEC pela UF; a documentação histórica não comprova aceitação universal.

Na manifestação do destinatário, a família de schema é envConfRecebto. No cancelamento, envEventoCancNFe; no cancelamento por substituição da NFC-e, envEventoCancSubst. A estrutura externa e o detalhe de cada evento devem ser conferidos conjuntamente.

Comprovante de entrega e cancelamento usam envEventoEntregaNFe e envEventoCancEntregaNFe. Insucesso e seu cancelamento utilizam envEventoInsucessoNFe e envEventoCancInsucessoNFe. Ator interessado e ECONF combinam a estrutura genérica envEvento com schemas específicos. Uma atualização de um desses módulos não garante atualização dos demais.

Para prorrogação de industrialização, a NT 2015.001 v1.30 distingue envPProrrogNFe, envCancelPProrrogNFe e envFiscoNfe. A raiz documentada também é envEvento. O terceiro contrato pertence à resposta da administração tributária; não se deve gerar uma resposta do Fisco em nome da empresa.

O BT 2018.002 v1.00 também documenta esse diagnóstico no Visto Eletrônico do Fisco: schema envVistoEletronico_v1.0.xsd, raiz envEvento e atributo versao obrigatório. É um evento de autoria da SEFAZ. Essa ocorrência serve para interpretar o retorno no contexto certo, sem atribuir à empresa a emissão de um visto ou presumir disponibilidade em todas as UFs.

Esses leiautes descrevem o atributo da raiz como obrigatório, com ocorrência 1-1 e formato de versão indicado no respectivo contrato. Não basta encontrá-lo em algum ponto do arquivo. Já um atributo presente, porém vazio, malformado ou com valor não suportado exige análise do schema e do retorno específico, em vez de presumir a mesma ausência da 517.

Localize onde a informação desapareceu

Um exemplo comum de investigação é o sistema produzir um evento completo, mas a integração reconstruir sua parte externa antes de transmitir. Se a reconstrução conserva os elementos e perde atributos, a prévia exibida ao usuário pode estar correta enquanto a mensagem final fica incompleta. É uma hipótese a testar, não uma conclusão automática sobre qualquer emissor.

Compare três pontos: saída do gerador, conteúdo após as transformações da integração e área de dados efetivamente enviada. Registre em qual deles versao deixa de existir. Se o atributo já falta no primeiro, revise a configuração ou atualização do módulo que gera aquela operação.

O roteiro recomendado é:

1. Identificar serviço, ambiente, modelo, tipo de evento quando houver e mensagem integral da rejeição

2. Guardar a tentativa para análise, sem modificar o arquivo de evidência

3. Validar uma cópia com o schema correspondente, conferindo a raiz, o nome exato do atributo e sua posição

4. Corrigir a geração ou transformação responsável e emitir novamente a solicitação pelo sistema

5. Conferir o novo retorno e a situação da operação, evitando repetição cega quando houver tentativa anterior inconclusiva

Na autorização, examine também a distinção com 568. Em documentação antiga, 517 aparecia em tabelas de serviços de lote sem a separação atual. Para registros históricos, use o manual da época; para integração atual, use seu contrato vigente.

O que não resolve a rejeição

Inserir versao em todos os elementos, substituir todas as versões por 4.00 ou apagar a validação local não demonstra conformidade. Tampouco é solução reconstruir indiscriminadamente cabeçalhos SOAP de exemplos antigos. Cabeçalho de transporte e atributo da mensagem fiscal são assuntos diferentes, dependentes do serviço e de sua geração.

A publicação paulista consultada marca D01b/517 como inativa, enquanto a mineira registra aplicação. O código pode variar conforme o autorizador; não se deve mudar UF, ambiente ou segurança para evitar a checagem. Mesmo sem um diagnóstico específico, o XML precisa cumprir o contrato.

Os guias práticos de Berga, Oobj e TecnoSpeed ajudam a investigar origem, montagem e schema; Oobj e TecnoSpeed foram lidos como contexto da rejeição genérica 215. A confirmação normativa vem dos documentos oficiais.

Preserve qualquer XML já autorizado. A correção deve acontecer no emissor ou na integração e passar novamente pelo fluxo de validação e assinatura cabível. Desabilitar certificados, verificações de assinatura ou mecanismos de segurança não corrige a falta de versao e cria um risco adicional.

Fontes consultadas

Base oficial preservada, lida em 10/10/2026: MOC 7.0, Anexo I, página 72, e MOC Visão Geral, contratos do capítulo 5; NT 2014.001 v1.41; NT 2014.003 v1.02; NT 2015.001 v1.30; NT 2018.004 v1.00; NT 2020.001 v1.60; NT 2020.007 v1.40; NT 2021.001 v1.01; NT 2022.001 v1.00; NT 2023.005 v1.02; NT 2024.002 v1.00; BT 2018.002 v1.00. Tabela paulista e regras mineiras, versão 2.00 de 13/03/2026. Não houve teste de transmissão por UF.

Leituras práticas: Berga: rejeição 517, Oobj: validação de schema e TecnoSpeed: falha de schema.