Pular para o conteúdo
Fiscal ProBiblioteca
NF-e e NFC-e · Suplemento, assinatura e protocolo

cMsg em infProt: código da mensagem adicional da SEFAZ

<cMsg>nfeProc › protNFe › infProt › cMsg

Revisão editorial em 15 de out. de 2026. As versões e condições das regras estão indicadas ao longo do artigo.

cMsg, em /nfeProc/protNFe/infProt/cMsg, é o código de uma mensagem adicional da SEFAZ para o emissor. Ele deve ser lido com o xMsg do mesmo par. Não é o código principal de resultado da nota, que está em cStat.

Onde o código aparece e o que seu formato permite

No XSD PL_010f_v1.04, cMsg vem depois de xMotivo dentro de uma sequência opcional cMsg/xMsg que pode repetir até cinco vezes. Quando essa sequência ocorre, cada cMsg precede seu xMsg. O código é uma string com um a quatro algarismos; o tipo não define, sozinho, o significado de cada número.

Não interprete cMsg=100 como autorização por analogia com cStat=100. São domínios com funções diferentes. Não elimine zeros de início nem converta códigos em valores de cálculo sem necessidade: preserve o conteúdo recebido.

Como a NT 2026.002 atualiza a sequência de mensagens

A NT 2026.002 v1.11, pp. 5–6, atualiza o grupo PR13 para 0..5 ocorrências e xMsg para até 255 caracteres. Isso resolve a indicação histórica de 0..1/200 na tabela da NT 2025.002 v1.52. O schema PL_010f_v1.04 já contempla os limites atualizados.

Há uma diferença mais específica a preservar na leitura das declarações: PR14 continua tabulando cMsg como 0..1 dentro da sequência, enquanto o XSD consultado exige cMsg e xMsg em cada ocorrência. Para validação estrutural, confira o pacote aplicável; para leitura e armazenamento, preserve o que veio no original. Não fabrique código ausente nem descarte texto por essa diferença localizada. Se o original não satisfizer o pacote selecionado, registre versão e erro para diagnóstico.

Fragmento e dois cenários de leitura

Fragmento sintético lexical de cMsg isolado, parcial em relação ao par e ao protocolo. O valor 7 não é apresentado como código oficial de uma mensagem específica:

<cMsg xmlns="http://www.portalfiscal.inf.br/nfe">7</cMsg>

Em uma resposta com resultado individual de autorização e mensagem adicional, cMsg deve ser tratado como informação suplementar; não desfaz nem substitui o resultado principal. Em outra resposta com rejeição, uma mensagem adicional também não converte a rejeição em autorização. Em ambos os casos, leia cStat/xMotivo primeiro e depois cada par adicional.

Como diagnosticar código sem texto ou mensagens trocadas

Se a aplicação exibe um código sem texto, compare o XML original: o mapper pode ter descartado xMsg ou reduzido uma lista a um único valor. Se vários códigos mostram o mesmo texto, confira o pareamento pela sequência recebida. Não agrupe por índice de duas listas reconstruídas que possam ter ordem diferente.

Não invente descrição a partir do número isolado e não use cMsg para decidir reenvio. Preserve chave, ambiente, cStat/xMotivo e as mensagens completas. A ausência da sequência opcional é permitida; não é necessário criar um código neutro.

Como cMsg participa da autorização com alerta

Na NT 2026.002 v1.11, o resultado de autorização com alerta usa cStat=120, inicialmente para NFC-e. O código do alerta é retornado em cMsg e seu motivo em xMsg. O código principal continua em cStat, com descrição em xMotivo: não classifique o documento pelo número de cMsg.

A regra não fatal registra o alerta e continua o processamento. Somente os cinco primeiros alertas identificados são retornados; a lista não é uma garantia de que nenhuma outra inconsistência exista. Se uma regra fatal rejeitar a nota, o retorno pode conter o código da rejeição e os alertas encontrados até ali.

Exemplo sintético: uma resposta tem resultado principal de rejeição e traz um alerta adicional. A presença de cMsg não converte o resultado em autorização com alerta. Em outra resposta, cStat=120 informa autorização; o alerta deve ser analisado sem corrigir e retransmitir a nota autorizada apenas para eliminá-lo. Se a nota autorizada fora de prazo contiver alerta, a NT também determina 120.

O cronograma da estrutura de alertas prevê teste em 01/09/2026 e produção em 05/10/2026. A mudança para 14/12/2026 de I08-180, BA02-35 e VC02-40 não deve ser atribuída a essa estrutura.

Leituras relacionadas

Fontes oficiais

Referência técnica para integração

XPath completo
/nfeProc/protNFe/infProt/cMsg
Namespace
http://www.portalfiscal.inf.br/nfe
Leiaute
4.00 · PL_010e_v1.02
Ocorrências no XSD
1–1 no contexto do elemento pai
Tipo
inline:xs:string · string
Preenchimento no catálogo
Condicional

A ocorrência vale dentro da estrutura XML: um campo obrigatório em um grupo opcional não torna esse grupo obrigatório. A aplicação fiscal depende da operação e da versão da regra.

pattern
[0-9]{1,4}
whiteSpace
preserve