Rejeição 238: como conferir a versão do XML e o serviço utilizado

A rejeição 238 indica que a versão informada na mensagem é superior à vigente no serviço que a recebeu. A correção depende de identificar qual XML foi enviado: uma solicitação de distribuição, um evento ou uma chamada de integração antiga. Não diminua números de versão por tentativa e erro.

Mensagem documentada: “Rejeição: Cabeçalho - Versão do arquivo XML superior a Versão vigente”.

Apesar da palavra “cabeçalho”, acrescentar o antigo SOAP Header não é a solução geral para NF-e ou NFC-e atuais. O leiaute 4.0 eliminou suas variáveis de controle. A 238, porém, continua prevista em documento específico de distribuição DF-e. Esses dois fatos precisam ser separados no diagnóstico.

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 238 pode indicar que a nota ainda não consta na base consultada. Confirme envio e autorização com o emitente e repita a consulta posteriormente. Esse aviso não pede mudança de versão do XML. NT 2026.003, seção 5.3.

Código 238 na consulta pública da NFC-e modelo 65

No Manual DANFE NFC-e v6.0, 238 avisa que a NFC-e ainda não consta na base consultada e orienta nova consulta posteriormente. A coluna Código pertence à consulta pública por chave ou QR; não define cStat de autorização e não pede redução da versão do XML. Manual v6.0, pp.38–40.

Confirme chave, ambiente e endereço oficial. O emitente deve verificar transmissão, falhas e protocolo. Repita a consulta posteriormente; se continuar ausente apesar da autorização, procure suporte ou SEFAZ. O aviso não comprova autorização, cancelamento ou necessidade de outra nota. O cronograma da NF-e Tipo 2 não determina o da NFC-e.

Em quais situações a 238 está documentada?

Distribuição DF-e, relacionada à NF-e modelo 55: a regra D04 da NT 2014.002 v1.40 verifica se a versão dos dados supera a vigente. Sua aplicação é facultativa. A D05, obrigatória, trata versão não suportada e retorna 239. O XML examinado é o pedido distDFeInt, não a nota armazenada no Ambiente Nacional. NT 2014.002 v1.40, seções 3.1 e 3.10.1.

“Facultativa” descreve a aplicação da validação pelo serviço; não permite ao contribuinte escolher uma versão incompatível. A publicação conserva a mensagem com “cabeçalho” na tabela de retornos, mas posiciona a D04 na validação da área de dados.

Prorrogação de industrialização, modelo 55: a NT 2015.001 v1.30 relaciona a 238 nas verificações de controle da chamada. O documento cita São Paulo e Minas Gerais como adotantes e diferencia as modalidades de implementação. Essas listas conservam terminologia do cabeçalho legado; não demonstram, isoladamente, sua exigência no endpoint atual. Confirme a operação e o contrato técnico da UF. NT 2015.001 v1.30, seções 6.6, 7.6 e 8.6.

EPEC da NFC-e, modelo 65: a NT NFC-e 2014.003 v1.02 também lista a 238 no controle de chamadas com cabeçalho. Entretanto, a própria publicação deixa adoção e entrada em vigência a critério da UF. Não presuma que o EPEC esteja disponível em todos os estados nem que esse cabeçalho continue exigido. NT NFC-e 2014.003 v1.02, seções 01 e 03.7.

Autorização atual de NF-e e NFC-e: o MOC 7.0 apresenta a B06 para versão não suportada, associada à 239. Também registra a eliminação das variáveis de SOAP Header no leiaute 4.0. Se a tela do emissor mostra 238 durante a emissão, obtenha o retorno original e confirme o serviço chamado antes de aplicar instruções antigas. MOC 7.0, Anexo I, seção 4.1.2, Visão Geral, seção 4.4.1.

O que significa “versão” nesse diagnóstico?

Cada informação tem uma função. A versão de uma Nota Técnica identifica o documento publicado; o atributo versao identifica o leiaute da mensagem; a versão do aplicativo identifica o programa. A declaração XML 1.0 identifica a linguagem XML.

Por isso, NT 2014.002 v1.40 não significa que todo pedido de distribuição deva receber versao="1.40". Da mesma forma, o leiaute 4.00 da nota não deve ser copiado automaticamente para consultas e eventos. Use o schema próprio da operação, com as atualizações implantadas no ambiente de destino.

Como investigar com o suporte

1. Preserve o cStat 238, o xMotivo integral, o horário e a operação executada. Verifique se o retorno veio da SEFAZ ou de uma validação do integrador.

2. Anote modelo, UF, ambiente e endereço exato do Web Service. Homologação e produção precisam ser avaliadas separadamente.

3. Solicite o XML realmente transmitido e identifique a tag raiz, o atributo de versão e, em integrações legadas comprovadas, os controles efetivamente exigidos pelo serviço.

4. Compare a solicitação com o schema e o WSDL oficiais daquele serviço. O WSDL é o contrato técnico que descreve como a chamada deve ser feita.

5. Corrija o gerador ou sua configuração e regenere a mensagem completa. Se houve alteração em conteúdo assinado, produza novamente a assinatura pelo emissor.

A TecnoSpeed recomenda conferir a versão gerada e adequá-la à aceita pelo destino. A referência daquele artigo é o MOC 6.00; sua orientação geral não comprova que a 238 tenha o mesmo alcance na autorização atual.

Na distribuição, o iLoveXML também orienta conferir o atributo de versão e a NT 2014.002 vigente. Essa orientação deve ser aplicada ao pedido de consulta.

O que fazer em cada cenário

O erro surgiu após uma atualização: confira se a versão implantada no emissor corresponde ao cronograma do serviço e do ambiente. Publicação da NT e disponibilidade operacional não são necessariamente simultâneas. Voltar uma versão sem analisar o conjunto pode introduzir outras incompatibilidades.

Somente a distribuição falha: ajuste a solicitação de distribuição. Não altere documentos já autorizados, não reinicie o controle de NSU como tentativa de corrigir versão e evite repetir consultas sem diagnóstico.

O XML vai para um endereço antigo ou para outra operação: corrija a seleção do destino. Uma mensagem válida para um serviço não necessariamente atende ao contrato de outro. Não mude dados fiscais verdadeiros para adequá-los ao endereço escolhido por engano.

Uma orientação manda inserir nfeCabecMsg: confirme sua data e escopo. A Presence publica um exemplo com versaoDados no SOAP Header. Essa referência histórica não deve substituir a regra do serviço atual.

A tela e o retorno técnico parecem divergir: peça o registro da origem da resposta. O manual da Oobj distingue respostas de sua integração das respostas da SEFAZ. O mesmo cuidado diagnóstico é útil em qualquer emissor, sem copiar seus campos proprietários.

Exemplo hipotético

Exemplo hipotético: após uma atualização, distDFeInt contém uma versão superior à aceita. O serviço aplica D04/238. O suporte corrige a configuração conforme o schema e verifica a resposta da consulta, sem reemitir notas.

Como confirmar a solução

Confira o resultado da mesma operação. Na distribuição, uma resposta válida pode informar documentos localizados ou ausência de documentos; ela não autoriza uma nota. Para um evento, confira seu retorno individual. Na autorização, procure o protocolo correspondente.

Se uma tentativa anterior de autorização ou evento ficou sem resultado conclusivo, consulte a situação antes de repetir a transmissão. A ausência da 238, sozinha, não comprova o sucesso final.

Revisão: 09/10/2026. A D04 foi conferida na NT 2014.002 v1.40. As menções legadas foram delimitadas; não houve teste em cada UF ou confirmação de exigência atual de SOAP Header nos serviços específicos.