NF-e e NFC-e
Rejeição 239: como corrigir uma versão de XML não suportada
A 239 indica versão XML não aceita pelo serviço. Confira operação, destino, ambiente e leiaute completo: trocar apenas o atributo versao pode deixar grupos e campos incompatíveis.
A 239 indica versão XML não aceita pelo serviço. Confira operação, destino, ambiente e leiaute completo: trocar apenas o atributo versao pode deixar grupos e campos incompatíveis.
Mensagem atual nas regras gerais do MOC: “Rejeição: Versão do arquivo XML não suportada”. Em documentos de alguns serviços e em sistemas emissores, também aparece “Rejeição: Cabeçalho - Versão do arquivo XML não suportada”.
A palavra “cabeçalho” não autoriza acrescentar um SOAP Header antigo à emissão atual. Na versão 4.0, o projeto eliminou as variáveis de controle desse cabeçalho; a conferência da versão continua existindo na regra B06. MOC 7.0, Anexo I, seção 4.1.2, MOC, Visão Geral, seção 4.4.1.
Se o código apareceu na consulta pública
Na consulta pública da NF-e modelo 55 com DANFE Simplificado Tipo 2, o código 239 indica divergência entre a UF da chave e a UF consultada. Confira a chave e o endereço estadual; não altere o XML fiscal. NT 2026.003, seção 5.3.
Código 239 na consulta pública da NFC-e modelo 65
O Manual DANFE NFC-e v6.0 também registra 239 para divergência entre a UF da chave e a UF indicada na consulta. É Código da consulta pública, sem definição de cStat de autorização nessa tabela. Não é uma ordem para trocar a versão do XML. Manual v6.0, pp.38–40.
Confira a chave original e seu código de UF; use o endereço oficial do emitente e ambiente. Se o QR aponta outra UF, corrija o gerador conforme sua versão. Preserve chave e dados fiscais: mudar seus caracteres ou atributo versao não corrige o destino errado.
As versões de uma integração não são todas iguais
A versão da Nota Técnica identifica a publicação; o atributo versao identifica o leiaute da mensagem. Schema, programa emissor e linguagem XML têm identificações próprias. “XML 1.0” na declaração não é o leiaute da NF-e. Cada mensagem deve seguir sua especificação, sem copiar o número da NT.
Confira o serviço antes de escolher a correção
Autorização de NF-e e NFC-e, modelos 55 e 65: revise a configuração de emissão e a geração integral do leiaute 4.00, com os schemas e as Notas Técnicas implantados no ambiente utilizado. O leiaute 4.00 continua recebendo alterações; seu número, sozinho, não identifica todos os campos vigentes. A B06 do MOC é obrigatória.
Consulta cadastral e demais consultas: confira a versão específica da mensagem de consulta. Não aplique automaticamente a versão da nota ao XML de uma consulta. A Sankhya documenta um caso de 239 causado por configuração de versão na consulta cadastral de MS. O parâmetro citado pertence àquele produto; serve como exemplo de onde procurar, não como procedimento universal.
Distribuição DF-e: o pedido distDFeInt tem versão própria. A D05 da NT 2014.002 v1.40 rejeita a versão de dados não suportada, com aplicação obrigatória. É um serviço de distribuição relativo à NF-e, modelo 55, e não uma autorização de uma nova nota. A versão 1.40 da NT não deve ser copiada para o atributo versao do pedido. NT 2014.002 v1.40, seções 3.1 e 3.10.1.
Eventos: confira a versão do lote e a do evento. Há previsão da 239 no EPEC, comprovante de entrega, insucesso de entrega e ator interessado da NF-e, modelo 55; no cancelamento por substituição da NFC-e, modelo 65; e no ECONF, modelos 55/65 conforme destino. Não use 4.00 automaticamente nos eventos. EPEC, NT 2014.001 v1.41, ECONF, NT 2024.002.
Consulta GTIN: a NT 2022.001 lista a 239 na validação inicial e na verificação de versão da área de dados. Corrija o pedido consGTIN; não substitua o GTIN cadastrado para contornar uma falha de versão. NT 2022.001, seções 04.5 e 04.6.
Prorrogação de industrialização e EPEC da NFC-e: os documentos desses serviços conservam referências à 239 no controle de chamadas com cabeçalho. A prorrogação se refere à NF-e, modelo 55; o EPEC da NFC-e, ao modelo 65. Essas referências não comprovam que um endpoint atual exija o cabeçalho legado. A disponibilidade e o contrato do serviço precisam ser confirmados na UF antes de qualquer alteração técnica.
Gerenciamento do CSC da NFC-e: a A02 prevê a 239 na consulta, requisição e revogação de CSC. A mensagem tem leiaute próprio, indicado como 1.00 naquela especificação. O documento deixa as datas de implantação a definir, portanto não demonstra disponibilidade nacional em 2026. Confirme o serviço da UF; uma falha de versão não justifica revogar um CSC. NT NFC-e 2014.001, páginas 3 e 7 a 9.
Como investigar com o suporte
Guarde cStat, mensagem, operação e origem da resposta.
Anote modelo, UF, ambiente, endereço, horário e versão do emissor.
Identifique raiz e atributo versao do XML enviado; nos eventos, confira lote e evento.
Compare especificação, schemas e WSDL oficiais do serviço. WSDL descreve seu contrato de comunicação.
Corrija a configuração e geração; regenere, valide e assine novamente se o conteúdo assinado mudou.
A TecnoSpeed ressalta que todo o leiaute deve acompanhar a versão informada. A TOTVS mostra um cenário de configuração antiga de emissão. Os nomes de telas desses produtos não são instruções de uso de outro emissor.
O que fazer em cada cenário
O programa ainda produz um leiaute descontinuado: solicite a atualização compatível com a operação. Trocar 3.10 por 4.00 em um editor não converte os grupos, campos e regras do arquivo antigo.
A mensagem está correta, mas foi ao serviço errado: corrija o endereço ou a seleção do serviço na integração. Não altere UF, ambiente ou dados fiscais do documento para fazê-lo caber no destino escolhido por engano.
Só a consulta ou o evento falha: corrija a configuração daquela operação. Uma autorização bem-sucedida não prova que todos os outros XMLs do emissor estejam usando suas versões corretas.
O problema começou após uma atualização: confira separadamente homologação e produção e o cronograma da alteração. Publicação de uma NT e implantação de suas mudanças podem ocorrer em datas diferentes. Não volte versões nem retire campos fiscais obrigatórios por tentativa e erro.
Exemplo hipotético
Exemplo hipotético: notas são autorizadas, mas uma configuração antiga da consulta cadastral provoca 239. O suporte identifica o XML dessa operação, ajusta seu módulo ao contrato e confere a resposta. As notas autorizadas permanecem intactas.
Como confirmar a solução
Confira o resultado da operação que falhou. Uma consulta precisa retornar sua resposta válida; um evento, seu resultado individual; uma autorização, o protocolo da nota. A aceitação de uma dessas operações não comprova o sucesso de outra.
Se alguma tentativa anterior terminou sem resposta conclusiva, consulte a situação antes de retransmitir. Não troque número ou série para contornar a 239.
Revisão: 09/10/2026. Versões documentais cotejadas com o índice oficial; sem testes em cada autorizador. Os ramos com cabeçalho legado foram mantidos como referência documental, sem afirmar sua exigência atual.
Referências complementares
Prorrogação, NT 2015.001 v1.30, seções 6.6, 7.6 e 8.6: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT+2015.001+-+v+1.30.pdf#page=35
EPEC NFC-e, NT 2014.003 v1.02, seções 01 e 03.7: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=HYPw%2BDBncKo%3D#page=9
Comprovante de entrega, NT 2021.001 v1.01: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT+2021_001_v1.01_Evento_Comprovante_Entrega_NFe.pdf#page=7
Insucesso de entrega, NT 2023.005 v1.02: https://dfe-portal.svrs.rs.gov.br/NFE/DownloadArquivoEstatico/?sistema=NFE&tipoArquivo=3&nomeArquivo=NT2023.005_v1.02+-+Evento+Insucesso+Entrega+NF-e.pdf#page=8
Ator interessado, NT 2020.007 v1.40: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=E1nOtSqZmEI%3D#page=8
Cancelamento por substituição, NT 2018.004: https://www.nfe.fazenda.gov.br/portal/exibirArquivo.aspx?conteudo=DEisbx2XCIs%3D#page=6