Rejeição 516: raiz esperada da mensagem XML ausente

A rejeição 516, regra D01a, é um detalhamento de falha de schema: a tag raiz esperada para a mensagem não foi encontrada. O serviço efetivamente chamado determina essa raiz. Não existe uma raiz única que possa ser usada indistintamente em autorização, consulta e registro de eventos.

Nesta página:

• Por que é necessário identificar o serviço?
• Exemplo: retorno salvo usado como solicitação
• Como investigar namespace e encapsulamento?
• Qual resultado encerra essa etapa?

Por que é necessário identificar o serviço?

O MOC separa a linha 565, específica do lote de autorização, da linha 516, referente à mensagem. O contexto técnico da segunda linha é a mensagem do serviço efetivamente chamado. Confira método, endpoint, ambiente e mensagem original antes de escolher o schema.

D01a é facultativa e pode ser aplicada após uma falha D01. Portanto, o erro pode chegar com um código de schema mais geral, sem esse detalhamento. O diagnóstico não deve depender somente do título mostrado pela aplicação.

Fontes: MOC Anexo I, regra D01a.

Exemplo: retorno salvo usado como solicitação

Em um cenário hipotético, uma integração lê o arquivo de resposta de uma consulta e o passa a um método que espera a mensagem de entrada. Ambos são XML, mas têm raízes e estruturas diferentes. Renomear a raiz da resposta não a transforma em requisição.

Confronte o contrato de entrada com a área de dados enviada. Para registro de eventos, por exemplo, a parte geral usa envEvento e contém eventos; o resultado do registro possui outra função. Mantenha separados arquivos de solicitação, resposta e documento processado.

Fontes: MOC Anexo I, regra D01a.

Como investigar namespace e encapsulamento?

Compare o nome local da raiz e seu namespace. Uma tag escrita com o nome esperado, mas no namespace do SOAP ou sem o namespace fiscal, pode não ser reconhecida como a declaração exigida. Confira também se o cliente transmitiu um elemento XML ou uma string escapada indevidamente.

Faça essa leitura antes de editar qualquer documento. O contrato do serviço define a área de dados; o envelope SOAP não substitui sua estrutura. Corrija o componente que a montou, com validação integral da mensagem final.

Fontes: MOC Anexo I, regra D01a.

Qual resultado encerra essa etapa?

A validação local no XSD correto deve reconhecer a raiz e prosseguir pelos elementos e atributos. Ainda podem surgir ausência de versao, falhas de conteúdo ou de assinatura. A 517 detalha a ausência de versão nessa família; a 565 trata da raiz do lote de autorização.

A correção estrutural não confirma o resultado fiscal. Se uma tentativa anterior ficou sem resposta, esclareça seu estado e preserve os registros antes de executar novamente a operação solicitada.

Fontes: MOC Anexo I, regra D01a.

Limite do exemplo e preservação dos dados

A raiz esperada depende do método e da mensagem originais; a demonstração completa exigiria conteúdo operacional protegido. O cenário textual compara solicitação e resposta sem fabricar evento assinado. 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 D01a, código 516; 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.