cMsg em infProt: código da mensagem adicional da SEFAZ
<cMsg>nfeProc › protNFe › infProt › cMsgRevisã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
- Leiaute NF-e/NFC-e — PL_010f_v1.04: TProtNFe, linhas 6686–6770.
- Tipos básicos NF-e/NFC-e — PL_010f_v1.04: TChNFe, TProt, TStat, TAmb, TVerAplic, TMotivo e TDateTimeUTC.
- NT 2025.002 RTC — 1.52: seção 5.1, p. 11; PR03–PR90, p. 13.
- NT 2026.002 — autorização com alerta e DANFE Simplificado Tipo 2 — 1.11, setembro de 2026: cronograma p. 3; autorização/alertas pp. 4–5; protocolo pp. 5–6.
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