Rejeição 239 — Cabeçalho - Versão do arquivo XML não suportada

O que é esta rejeição?#

A Rejeição 239 é retornada pela SEFAZ quando o sistema identifica o seguinte problema na NF-e: Cabeçalho - Versão do arquivo XML não suportada. A nota fiscal não foi autorizada e precisa ser corrigida antes de ser retransmitida.

Este código indica que rejeição: Cabeçalho – Versão do arquivo XML não suportada.

Causas comuns#

• O XML contém erros de formatação, namespaces inválidos ou codificação incorreta
• A versão do layout XML não é suportada ou é superior à vigente na SEFAZ
• Há caracteres especiais, espaços ou quebras de linha indevidas no XML
• O XML deve usar codificação UTF-8 sem BOM (Byte Order Mark)

Como resolver#

1. Valide o XML com um parser antes de enviar — ele deve ser bem-formado (well-formed)
2. Use apenas o namespace padrão da NF-e: http://www.portalfiscal.inf.br/nfe
3. Salve o XML com codificação UTF-8 sem BOM
4. Atualize a versão do layout no sistema emissor para a versão vigente aceita pela SEFAZ
5. Remova caracteres de edição (tabs, espaços extras) do início e fim do XML

Verificações analíticas#

• Se o atributo versao do elemento NFe (ex: versao='4.00') não corresponder exatamente à versão declarada no campo verProc ou se contiver espaços, zeros à esquerda ou caracteres invisíveis ao redor do valor numérico, então o parser da SEFAZ interpreta a versão como não suportada: extraia o atributo versao via XPath e compare seu valor byte a byte com a string literal '4.00', rejeitando qualquer variação como '4.0', ' 4.00' ou '04.00'.
• Se o namespace xmlns declarado no elemento raiz NFe não for exatamente 'http://www.portalfiscal.inf.br/nfe' (sem barra final, sem variação de capitalização, sem namespace adicional não declarado no schema) e ao mesmo tempo o CRT do emitente for 1 (Simples Nacional) com CSOSN diferente dos códigos válidos 102/103/300/400/500/900, então o XML possui dupla inconsistência estrutural e tributária: corrija primeiro o namespace para o valor canônico e em seguida alinhe o CSOSN ao regime do emitente antes de reenviar.
• Se dhEmi e dhSaiEnt estiverem presentes e o intervalo entre elas for superior a 24 horas em uma NF-e com tpEmis=1 (emissão normal, sem contingência) e finNFe=1 (NF-e normal), e simultaneamente o campo tpNF=1 (saída) com CFOP iniciado em 6 (operação interestadual), então a defasagem entre emissão e saída pode indicar que o XML foi gerado em modo offline e reenviado sem ajuste do tpEmis para o código de contingência adequado (5=EPEC ou 7=SVC), o que também corrompe a validação de cabeçalho: verifique se o XML original foi produzido em contingência e atualize tpEmis, cNF e dVerProc de forma consistente.
• Se o valor de vICMSDeson for maior que zero e o campo motDesICMS estiver ausente ou contiver código fora do conjunto {3,9,12} para operações com CFOP 6.108 ou 6.109 (exportação indireta), e ao mesmo tempo pRedBC estiver preenchido com percentual diferente de zero sem que vBCRed reflita o cálculo vBC * (pRedBC/100), então há tripla inconsistência entre desoneração, redução de base e valores calculados que frequentemente coexiste com erros de encoding quando o gerador do XML serializa campos numéricos com separador decimal vírgula em vez de ponto: valide que todos os campos monetários usam ponto como separador e que motDesICMS pertence ao domínio permitido pelo schema 4.00.
• Se infRespTec estiver ausente no XML e o campo CNPJ do emit for diferente do CNPJ do desenvolvedor do sistema emissor declarado no credenciamento da SEFAZ, ou se autXML não listar o CNPJ/CPF do transportador quando transp/modFrete for 0 ou 1 e o campo CNPJ de transporta estiver preenchido, então a ausência desses elementos obrigatórios causa falha de schema que a SEFAZ pode reportar como rejeição 239 antes mesmo de alcançar a validação de regra de negócio: confirme que o bloco infRespTec está presente e bem-formado com idCSRT e hashCSRT calculados corretamente via SHA-1(CSRT+CNPJ emit) para evitar que o validador de estrutura aborte na fase de parsing.