Rejeição 242: como corrigir uma mensagem SOAP inválida

Na comunicação NF-e/NFC-e, a B00/242 indica nfeDadosMsg não encontrado no SOAP, inclusive por namespace divergente. Confira chamada completa e destino: validar só o XML fiscal não verifica o transporte.

Mensagem da regra B00: “Rejeição: Mensagem SOAP inválida”. Documentos anteriores e de serviços específicos também apresentam “Rejeição: Cabeçalho - Falha no Schema XML” ou referência ao elemento nfeCabecMsg ausente.

Identifique texto e operação: as descrições têm históricos e escopos distintos. Adicionar cabeçalho não é solução universal.

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 242 indica dia de emissão inválido. Peça ao suporte para conferir os dados da consulta com a emissão original. Não altere a data fiscal nem o SOAP para corrigir esse aviso. NT 2026.003, seção 5.3.

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

O Manual DANFE NFC-e v6.0 usa 242 para dia de emissão inválido na consulta. É Código de consulta pública, sem definir cStat da autorização nessa tabela. Nos QR v2 e v3 offline, o quarto parâmetro informa apenas o dia de dhEmi, com dois dígitos; não se coloca ali uma data completa. Manual v6.0, pp.22, 30 e 40.

Compare o QR decodificado com o XML original e confira o modo de emissão. Corrija a geração desse parâmetro se houver erro, preservando a data fiscal e respeitando o hash ou a assinatura da versão. Os leiautes online v2/v3 não possuem dia avulso; não o acrescente para atender ao aviso. Peça ao suporte que confira a implementação se o retorno contrariar o leiaute. Não altere o SOAP por causa dessa mensagem. NT 2025.001 v1.03, p.14.

O que mudou na interpretação da 242

SOAP é o padrão usado para transportar a solicitação ao Web Service. É possível que o XML da nota esteja correto, mas a mensagem que o entrega ao serviço esteja montada de forma incompatível.

A NT 2020.005 criou a B00 para facilitar esse diagnóstico: o parâmetro nfeDadosMsg não foi encontrado na mensagem SOAP, por ausência ou por possível diferença no namespace previsto. A regra é obrigatória. NT 2020.005 v1.21, seção 6.

Já o MOC registra que o leiaute 4.0 eliminou as variáveis de controle do antigo SOAP Header e as regras associadas a essas variáveis. Por isso, instruções antigas para acrescentar nfeCabecMsg, cUF e versaoDados não devem ser copiadas para a autorização atual. MOC 7.0, Visão Geral, seção 4.4.1.

A análise da TecnoSpeed sobre a NT 2020.005 também identifica a ausência do parâmetro e a divergência de namespace como pontos de diagnóstico.

nfeDadosMsg e nfeCabecMsg não são o mesmo elemento. O primeiro identifica a entrada de dados na regra B00; o segundo aparece nas orientações legadas de cabeçalho.

Qual ramo se aplica ao seu caso?

Autorização de NF-e/NFC-e, modelos 55 e 65: confira a chamada SOAP de autorização e a presença do parâmetro de entrada com o namespace correto para esse serviço. Validar somente o arquivo da nota não verifica toda essa comunicação.

Demais operações sujeitas ao grupo B geral do MOC: a B00 integra a seção 4.1.2. A lista antiga de serviços na página 23 da NT está tachada; não é extensão vigente independente. Confira contrato e regras da operação, sem presumir todos os eventos disponíveis para ambos os modelos. NT 2020.005 v1.21, página 23.

Prorrogação de industrialização, modelo 55: a NT 2015.001 v1.30 conserva a descrição de falha de schema do cabeçalho nas seções de controle de chamada. O documento identifica SP e MG como adotantes, com cronograma próprio para a modalidade completa de MG. Essa menção não comprova a exigência atual de nfeCabecMsg em todos os endpoints. Confirme o contrato técnico utilizado pela UF. NT 2015.001 v1.30, páginas 4 a 6 e 35.

EPEC da NFC-e, modelo 65: a NT 2014.003 v1.02 relaciona a 242 ao cabeçalho antigo, mas deixa a adoção e a data de implantação a critério da UF. A exigência contemporânea desse cabeçalho não foi comprovada nesta revisão. Antes de alterar a integração, confirme disponibilidade, versão e WSDL do serviço estadual. NT NFC-e 2014.003 v1.02, seções 01 e 03.7.

Gerenciamento do CSC da NFC-e: a A03 da especificação valida o cabeçalho nas operações de consulta, requisição e revogação. O documento mantém datas de vigência a definir; portanto, não prova implantação nacional. Uma rejeição técnica nessa solicitação não determina troca ou revogação do CSC. NT NFC-e 2014.001, páginas 3 e 7 a 9.

Como investigar com o suporte

1. Guarde cStat, xMotivo, horário e operação; diferencie retorno SEFAZ de aviso do integrador.

2. Anote modelo, UF, ambiente e endereço do Web Service.

3. Obtenha o SOAP enviado, não apenas o XML exportado da nota.

4. Compare método, parâmetro de entrada e namespace com o WSDL oficial, que define o contrato do serviço.

5. Corrija a montagem, valide e faça tentativa controlada. Se alterar conteúdo assinado, gere nova assinatura.

O manual de integração da Oobj distingue respostas produzidas pela integração das recebidas da SEFAZ. Essa separação ajuda a não tratar um aviso local como se fosse, necessariamente, o retorno original do autorizador.

O que fazer em cada cenário

nfeDadosMsg está ausente: o fornecedor deve corrigir a construção da chamada. Não acrescente esse texto a um campo de observações da nota: trata-se de um elemento técnico da comunicação.

Namespace errado: compare biblioteca, serviço e versão. Nome do elemento e namespace precisam coincidir com o contrato; não remova namespaces por substituição de texto.

Após atualização: compare mensagens antes e depois; confira transporte, contrato do serviço e schemas fiscais com o fornecedor.

A tela mostra “falha no schema do cabeçalho”: peça o xMotivo original e identifique o serviço. A Presence conserva uma orientação baseada no cabeçalho do MOC 6.00. Ela explica a origem de algumas instruções encontradas na internet, mas não substitui o contrato atual nem a B00.

Há suspeita de instabilidade: o Bling relata essa possibilidade em seu suporte. Confirme um aviso oficial ou evidências do incidente antes de concluir que basta aguardar. Uma mensagem montada de forma errada continuará errada depois da espera. Evite reenvios repetidos sem diagnóstico.

Exemplo hipotético

Exemplo hipotético: uma biblioteca envia à consulta de status o namespace da autorização e recebe 242. O suporte corrige o SOAP conforme o WSDL da consulta e verifica a resposta. Isso não autoriza notas nem exige alterar vendas.

Como confirmar a solução

Repita e acompanhe a mesma operação, agora com a chamada corrigida. Na autorização, confira o protocolo da nota; no evento, o resultado individual; em uma consulta, a resposta correspondente. Um XML local validado ou um serviço “em operação” não comprova autorização de uso.

Se uma tentativa anterior ficou sem resultado conclusivo, consulte a situação antes de retransmitir ou criar outro documento. Não altere número, série, destinatário ou valores para contornar a 242.

Revisão: 09/10/2026. Regra B00 cotejada com o MOC e com documentos de serviços. Referências a cabeçalho legado foram delimitadas; sua exigência atual não foi presumida nem testada por UF.