Voltar para o blog

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.

Blog ALRA
Capa ilustrada da ALRA: 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.

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

  1. Guarde cStat, mensagem, operação e origem da resposta.

  2. Anote modelo, UF, ambiente, endereço, horário e versão do emissor.

  3. Identifique raiz e atributo versao do XML enviado; nos eventos, confira lote e evento.

  4. Compare especificação, schemas e WSDL oficiais do serviço. WSDL descreve seu contrato de comunicação.

  5. 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

Pronto para dar o próximo passo?

Pronto para organizar sua empresa e ganhar mais tempo?

Teste grátis por 15 dias e descubra como a Alra pode transformar a gestão do seu negócio.