Rejeição 239: versão do XML não suportada pelo serviço

A rejeição 239, regra B06, indica que o serviço não suporta a versão de XML informada. É necessário identificar qual mensagem e qual atributo de versão estão em análise. A versão do XML fiscal não é a versão do SOAP, do TLS ou do aplicativo emissor.

Nesta página:

• Quais versões devem permanecer separadas?
• Exemplo: leiaute novo enviado ao endpoint antigo
• Como escolher o schema de conferência?
• Qual a diferença entre 239, 517 e 568?

Quais versões devem permanecer separadas?

A declaração XML identifica a linguagem XML e sua codificação. O atributo versao da raiz informa a versão do leiaute daquela mensagem. SOAP e TLS têm seus próprios padrões. Em eventos, verEvento identifica ainda o leiaute específico do evento. Alterar uma dessas versões não substitui as outras.

Identifique a raiz e o atributo efetivamente enviados e confronte-os com o contrato do endpoint. O número de uma Nota Técnica ou o nome de um pacote de schemas não é necessariamente o valor que deve constar em versao.

Fontes: MOC Anexo I, regra B06.

Exemplo: leiaute novo enviado ao endpoint antigo

Considere uma aplicação atualizada para gerar a mensagem corrente, mas que mantém uma URL antiga de serviço. O XML pode validar no XSD local e ainda ser incompatível com o endpoint chamado. A correção pode estar no roteamento e no cliente de integração, não no conteúdo comercial.

Também existe a hipótese inversa: endpoint correto e gerador antigo. Compare geração, serialização e configuração realmente carregadas. Não troque apenas o texto do atributo; uma mudança de leiaute exige que toda a estrutura corresponda à versão anunciada.

Fontes: MOC Anexo I, regra B06.

Como escolher o schema de conferência?

Use o pacote oficial vigente para o serviço, modelo e ambiente, com suas dependências e notas posteriores. A NT 2026.004, por exemplo, atualizou campos para CNPJ alfanumérico em várias mensagens. Um schema antigo pode produzir falhas locais que não refletem o contrato atualizado.

Cronograma publicado e instalação efetiva no autorizador são evidências distintas. Registre as versões e o ambiente quando houver divergência. Não reduza validações nem remova caracteres legítimos para acomodar um schema desatualizado.

Fontes: MOC Anexo I, regra B06; NT 2026.004 — CNPJ alfanumérico.

Qual a diferença entre 239, 517 e 568?

A 239 trata de versão não suportada. A 517 detalha ausência de atributo versao na raiz de uma mensagem; a 568 faz esse detalhamento no lote de autorização. Ter um atributo presente não garante que seu valor é aceito. Após corrigir a causa, valide sintaxe, XSD e assinatura do conteúdo final. O retorno fiscal é necessário para concluir o resultado; tentativas incertas devem ser consultadas antes de novo envio.

Fontes: MOC Anexo I, regra B06.

Limite do exemplo e preservação dos dados

Compatibilidade depende da mensagem original e do endpoint efetivo; um XML inventado não comprovaria suporte no autorizador. O exemplo compara gerador, schema e serviço sem documento operacional. 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. 71, regra B06, código 239; quadro completo e notas da seção.
• MOC 7.0 — Visão Geral, versão 7.00. pp. 52 e 64, comunicação e eliminação do SOAP Header específico; pp. 71 e 85, mensagens e atributos.
• 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.