Rejeição 411: versaoDados ausente e os limites do cabeçalho SOAP

A rejeição 411, com a mensagem “Campo versaoDados inexistente no elemento nfeCabecMsg do SOAP Header”, descreve a falta de uma informação de versão em um contrato que utiliza esse cabeçalho. A providência inicial é identificar o serviço e a interface acionados. Informar “4.00” em todo cabeçalho não é uma correção universal: os serviços comuns migrados para a NF-e 4.00 passaram a dispensar nfeCabecMsg.

Há documentação específica que ainda contém o código, especialmente nos eventos de prorrogação de industrialização. As referências de EPEC da NFC-e e administração do CSC também o registram, com limites de versão e disponibilidade. Este artigo orienta a análise desses retornos sem tratar 411 como uma regra geral atual da autorização de NF-e ou NFC-e.

Por que existem tantas versões diferentes?

Na rotina do emissor, “versão” pode representar coisas distintas: a edição de uma nota técnica, o leiaute da NF-e, a mensagem de um serviço, o detalhe de um evento ou a versão do próprio aplicativo. Esses números não são intercambiáveis.

Nos contratos com nfeCabecMsg, versaoDados informa a versão do leiaute XML transportado na área de dados da chamada. Ela não é automaticamente igual à edição do MOC, nem à versão comercial do ERP. Em uma mensagem de evento, é necessário observar também os atributos versao e o campo verEvento definidos em seu leiaute.

Essa separação evita um erro frequente de manutenção: atualizar o corpo XML e deixar o componente de comunicação com um contrato anterior. O inverso também pode ocorrer, quando se muda um parâmetro de versão sem atualizar a estrutura que será enviada.

O que mudou nos serviços 4.00

A retirada do SOAP Header está descrita na NT 2016.002 e confirmada no MOC 7.0, seção 4.4.1. As antigas regras de controle foram eliminadas nos serviços relacionados à migração. A lista inclui autorização, retorno de autorização, inutilização, consultas e os eventos enumerados pela nota técnica.

Se uma emissão comum, configurada para NFeAutorizacao4, devolve uma mensagem sobre versaoDados ausente no cabeçalho, o suporte deve verificar a URL realmente usada, o método e o WSDL. Este último descreve os parâmetros técnicos da interface. Uma biblioteca antiga ou uma configuração isolada pode continuar montando a chamada de maneira incompatível com o destino pretendido.

O correto é resolver essa incompatibilidade. Acrescentar nfeCabecMsg a um serviço que já não o exige pode mascarar o diagnóstico. A existência da 411 em uma lista comercial de rejeições, sem versão e serviço associados, não recria a obrigação retirada.

Como interpretar os ramos específicos

Pedido de prorrogação e seu cancelamento. Na NT 2015.001 v1.30, de dezembro de 2024, as seções 6.6 e 7.6 ainda relacionam 411. O contexto é a NF-e modelo 55 de remessa para industrialização e seus eventos próprios: 111500/111501 para pedidos e 111502/111503 para cancelamentos. A versão 1.30 é a edição da nota técnica; não deve ser copiada para versaoDados por esse motivo. O contrato e o pacote de schemas do evento determinam os valores aceitos.

Resposta do Fisco à prorrogação. A seção 8.6 também contém 411. Esse ramo corresponde a eventos da administração tributária. A empresa não deve trocar o tipo do evento para tentar transmitir uma resposta fiscal. O documento menciona SP e MG como adotantes, sem comprovar oferta nacional ou uniformidade de implementação.

EPEC da NFC-e, modelo 65. A NT 2014.003 v1.02 preserva a mensagem na seção 03.7. O portal paulista apresenta serviços específicos de EPEC e informa que, em produção, a Sefaz só o ativa diante de indisponibilidade da autorização normal. Não se deve usar automaticamente a versão da autorização comum da NFC-e nessa mensagem, nem confundir esse evento com o EPEC da NF-e modelo 55.

Administração do CSC. O manual NT NFC-e 2014.001 v1.00 contém A16 para versaoDados e identifica seus leiautes próprios. As datas de vigência permanecem “a definir” no documento. Há anúncio de implementação no Amazonas em 2015, que não comprova disponibilidade em 2026. O manual é uma referência para interpretar um contrato, sem provar a oferta atual do Web Service. Não há motivo para gerar, revogar ou divulgar um CSC apenas porque faltou uma informação de versão.

Um diagnóstico em cinco passos

1. Recolha cStat e xMotivo completos. Confirme se a mensagem foi devolvida pela Sefaz ou traduzida pelo ERP. Anote a operação, o modelo, a UF, o tipo de evento e o ambiente.

2. Compare a URL e o método efetivamente chamados com a documentação da interface correspondente. A versão selecionada numa tela não basta para demonstrar qual serviço recebeu a mensagem.

3. Identifique as versões do XML principal, do lote e do evento, quando houver. Peça ao suporte que mostre qual configuração controla cada uma, sem presumir que todas devam ser iguais.

4. Somente se o contrato exigir nfeCabecMsg, confira a presença de versaoDados no lugar e namespace corretos e sua correspondência com o leiaute esperado. Caso o serviço dispense o grupo, ajuste a integração ao contrato sem cabeçalho.

5. Valide a mensagem com os schemas aplicáveis e faça um envio controlado. Leia o retorno completo da operação, inclusive o resultado individual do evento, quando existente.

Como exemplo, uma empresa pode emitir NF-e 4.00 e utilizar uma mensagem de evento com leiaute próprio. Copiar “4.00” para versaoDados só porque a nota está nessa versão mistura estruturas diferentes. Também seria incorreto adotar “1.30” porque esse número aparece na capa da nota técnica de prorrogação. O suporte deve localizar a versão da mensagem no contrato exato.

Quando o retorno muda, o diagnóstico também muda

A 411 descreve ausência de versaoDados. Rejeições sobre versão não suportada, falta do atributo versao na raiz ou divergência entre cabeçalho e mensagem têm verificações próprias. Nos contratos que as preveem, podem aparecer códigos como 239, 517 e 545. Não se deve tratar qualquer problema de versão como se fosse o mesmo campo ausente.

Após a correção, uma nova rejeição pode mostrar que a chamada avançou para outra etapa. Isso ainda não confirma autorização ou registro do evento. Se uma tentativa anterior tiver resultado incerto, consulte a situação antes de retransmitir; preserve o vínculo entre documento, evento e retorno. Não altere o XML de uma nota já autorizada para ajustar a versão de uma chamada posterior.

Prevenção e segurança

Mantenha o emissor, os schemas e as configurações de serviço compatíveis entre si. Registre separadamente homologação e produção, inclusive em módulos auxiliares. Ao atualizar a integração, teste as operações utilizadas pela empresa, e não apenas a autorização da nota.

Compartilhe com o suporte apenas o necessário: mensagem de retorno, versão, serviço, ambiente e trechos técnicos protegidos. Certificado digital, senha, chave privada e segredo do CSC não são necessários para explicar qual campo de versão faltou. A correção deve preservar tanto a integridade fiscal quanto a segurança do estabelecimento.

Fontes e limites da consulta

Verificação documental em 10/10/2026, utilizando capturas oficiais preservadas e páginas públicas consultadas nesta data. A presença do código na documentação não certifica sua ativação em todas as interfaces estaduais.

• MOC 7.0, Visão Geral, seção 4.4.1 e NT 2016.002 v1.61, seção 2.2

• NT 2015.001 v1.30, prorrogação

• NT NFC-e 2014.003 v1.02, EPEC e manual de administração do CSC v1.00

• Sefaz-SP: serviços da NFC-e e condições do EPEC

• Referências práticas comparadas: FlexDocs, consulta cadastral multiversão, NFePHP, pedido de prorrogação e DataPlace, migração para NF-e 4.00 e seção SOAP. Exemplos antigos e tabelas agregadas foram usados com ressalvas de serviço e versão, sem reproduzir uma exigência universal de cabeçalho.

• Sefaz-AM, anúncio histórico de implantação do WS-CSC, 05/02/2015