cMunFG do transporte na NF-e: município do fato gerador e rejeição 288

cMunFG em transp/retTransp contém o código do município de ocorrência do fato gerador do ICMS do transporte. O caminho é /nfeProc/NFe/infNFe/transp/retTransp/cMunFG. O campo identifica um município fiscal já definido; ele não determina, por si, onde o imposto é devido.

A origem correta envolve duas conferências diferentes: confirmar o município aplicável à prestação e localizar seu código na tabela IBGE. Saber que um código existe não prova que esse município corresponde à sua operação.

Não confundir com município do emitente ou da transportadora

O XML possui outros dados de município: endereços do emitente/destinatário, ide/cMunFG e transporta/xMun, entre outros. transporta/xMun é o nome do município do transportador; retTransp/cMunFG é um código associado ao fato gerador do transporte. A sede da transportadora, o destino da carga e o local fiscal da prestação não podem ser equiparados automaticamente.

Não use o identificador interno de uma cidade no ERP, CEP, código de UF ou código de outra tabela. O MOC X17, p.60 referencia a tabela IBGE; o campo usa sete dígitos. A API oficial de localidades do IBGE — Curitiba confirma nome Curitiba, UF PR e código 4106902 para o exemplo abaixo. Na operação real, consulte o município e a UF previamente definidos para a prestação; a existência desse código não escolhe o local fiscal.

Obrigatoriedade e formato no grupo

cMunFG aparece uma vez e é obrigatório quando retTransp está informado. O pai admite ausência no leiaute; a exigência do filho não obriga retenção em toda nota. A sequência coloca o município após CFOP. O tipo TCodMunIBGE do PL_010c exige sete algarismos, sem separadores.

Uma tag vazia não representa município desconhecido, e 0000000 não deve substituir informação pendente só porque tem sete caracteres. O formato é apenas uma etapa da conferência; a existência do código é verificada separadamente.

Exemplo: código conhecido, local apenas assumido

Fragmento parcial e sintético, não pronto para transmissão. A hipótese é que o município fiscal já foi confirmado como Curitiba, cujo código IBGE é 4106902. Valores e CFOP são demonstrativos, sem escolha de tratamento tributário:

<retTransp xmlns="http://www.portalfiscal.inf.br/nfe">
  <vServ>1000.00</vServ>
  <vBCRet>800.00</vBCRet>
  <pICMSRet>12.00</pICMSRet>
  <vICMSRet>96.00</vICMSRet>
  <CFOP>5352</CFOP>
  <cMunFG>4106902</cMunFG>
</retTransp>

O código resolve a representação da hipótese; não autoriza usar Curitiba só porque o emitente ou a transportadora esteja nessa cidade. A conta ilustrativa é exata, 800 × 12 ÷ 100 = 96, sem estabelecer base ou alíquota para a operação real.

Rejeição 288 e divergência sem rejeição

X17-10 trata código inexistente do município do fato gerador do transporte, com rejeição 288. Ao receber esse retorno, examine o cMunFG desse pai no XML enviado e confronte-o com a tabela oficial. Confira se a integração exportou ID interno, eliminou dígito, escolheu município de nome semelhante em outra UF ou usou base de localidades desatualizada.

Se o código existe, mas foi associado ao município errado para a prestação, a ausência de 288 não comprova adequação fiscal. É uma divergência de origem que requer confirmar o local fiscal com documentos da prestação, locais de início/fim e responsabilidade pela retenção. O artigo não decide essa vinculação jurídica.

Se o retorno for 755, confira modelo e tpImp: o problema é o pai retTransp na NFC-e ou na NF-e com DANFE Tipo 2, conforme NT 2026.002 v1.10a. O conjunto X tem cronograma de teste em 01/07/2026 e produção em 03/08/2026; não é prova de implantação de cada UF. Trocar o município não corrige grupo proibido.

Depois de confirmar a causa, corrija a tabela/mapeamento ou o parâmetro fiscal comprovadamente incorreto e confira a nova geração. Não substitua o município por outro existente para obter autorização, nem edite XML assinado. Veja retTransp para conferir o bloco inteiro.