Rejeição 1172: verifique a classificação e o grupo de estorno do item

Quando a nota retorna 1172, comece pelo item apontado na resposta e pelo XML que foi transmitido. Há informação de estorno de crédito incompatível com a classificação enviada naquele cenário. A tarefa é localizar a origem da combinação: cadastro, configuração da operação ou geração pela integração. Repetir o envio sem esclarecer essa causa conserva o problema.

A mensagem documental é “Rejeição: Grupo de Estorno de Crédito informado indevidamente [nItem: 999]”. O marcador nItem indica o item a examinar; 999 não representa um produto obrigatório do cadastro. Essa mensagem não calcula o crédito da empresa nem determina, sozinha, o enquadramento correto da operação.

O que a validação compara

Na NT 2025.002-RTC v1.52 salva, página 65, a UB116-10 abrange NF-e 55 e NFC-e 65. Se o cClassTrib possui indicador que veda estorno, ind_gEstornoCred=0, o preenchimento de gEstornoCred é indevido. A condição relaciona a classificação do item com a presença do grupo. Não é uma comparação genérica de valores do estoque. [1]

O leiaute da página 27 vincula esse indicador à tabela de cClassTrib do IBS/CBS. Portanto, não conclua a permissão apenas pelo CST, pelo nome comercial do produto ou pela existência de um campo na tela. A classificação precisa corresponder à operação e sua linha precisa ser conferida pelo responsável fiscal. Nenhuma linha individual de tabela foi homologada nesta elaboração.

O mesmo leiaute apresenta o grupo com ocorrência 0–1. Isso descreve sua possibilidade estrutural, não uma autorização para preencher estorno em qualquer nota. Os campos vIBSEstCred e vCBSEstCred pertencem a esse grupo; não substituem os valores de tributação regular. Não houve validação XSD ou cálculo fiscal nesta etapa.

Uma exceção que não pode virar atalho

A UB116-10 declara exceção quando tpNFDebito=07, perda em estoque. É um cenário próprio, que exige verificar o fato, a finalidade e o tipo do documento. Não transforme venda, transferência ou ajuste financeiro em perda para alcançar essa exceção.

Na página 66, a UB116-20, código 1173, é do modelo 55: exige o grupo quando o indicador é 1 ou há tipo de débito 07. Ela trata de ausência de informação, enquanto a 1172 trata de presença indevida. A UB116-30, código 1174, também é do modelo 55 e tem condição monetária e exceção próprias. Não transporte essas colunas para a NFC-e 65. [1]

Antes de remover o grupo de uma nota de perda, confirme qual regra e qual cenário se aplicam. Uma correção automática que elimina todos os estornos pode criar uma nova omissão. A exceção documental não comprova direito fiscal individual nem a disponibilidade operacional de todos os ambientes.

Separe cadastro, cálculo e transmissão

Guarde o XML rejeitado, o retorno integral, horário, ambiente e versão do emissor. Localize o item pelo número devolvido e compare mercadoria, quantidade e natureza efetiva da operação. Confira também qual estabelecimento preparou a nota.

No item, verifique o cClassTrib enviado e a presença de imposto/IBSCBS/gEstornoCred. Na identificação da nota, examine modelo, finNFe e eventual tpNFDebito. Reúna a referência da tabela usada pelo emissor e a documentação fiscal que fundamentou sua escolha.

Uma tela atualizada não mostra necessariamente o arquivo daquela tentativa. Dados podem ter sido copiados de um documento anterior ou mantidos numa fila preparada antes de uma alteração. Também pode haver uma integração que inclua o grupo por padrão, sem avaliar o indicador correto.

Se o indicador não aparece na interface, não interprete essa falta como zero ou como permissão. Peça a identificação da linha e da versão de tabela utilizadas. Essas verificações distinguem erro de mapeamento de dúvida sobre o tratamento fiscal.

Correção conforme a origem

A classificação representa a operação, mas o grupo veio de uma configuração errada

Após confirmação fiscal, peça ao suporte que rastreie a opção ou rotina que acrescentou o estorno. Corrija sua origem e gere novamente o documento rejeitado pelo emissor. Confira o arquivo final, sem presumir que salvar o cadastro atualizou automaticamente uma nota já preparada.

Zerar valores não demonstra que o grupo deixou de existir. A 1172 examina sua presença no cenário vedado. Não edite XML assinado manualmente nem altere um documento autorizado. Preserve os arquivos usados para comparar o resultado.

A classificação enviada não corresponde ao fato

Leve à contabilidade os documentos e a descrição da operação. O responsável fiscal deve definir a classificação aplicável; o suporte ajusta o cadastro ou mapeamento que gerou a informação errada. Depois, confira os demais campos dependentes.

Não procure um código apenas porque ele permite estorno. Fazer dois campos combinarem tecnicamente não comprova adequação tributária. Da mesma forma, retirar um grupo realmente necessário não corrige uma classificação fiscal incorreta.

O arquivo retrata perda em estoque ou parece atender à regra

Confirme os requisitos do cenário real antes de qualquer mudança. Se o documento está corretamente identificado e a resposta continua contrariando a evidência, confira se o XML analisado é o transmitido e se o ambiente está certo.

Encaminhe a divergência ao suporte com modelo, versão, arquivos e retorno. Ele pode precisar envolver o autorizador. Não troque finalidade, tipo de débito, data ou operação por tentativa.

Exemplo fictício

Uma distribuidora envia NF-e de uma venda de caixas de embalagem. A equipe fiscal conferiu a classificação dos itens e seu indicador veda estorno. Após alteração no mapeamento da integração, o XML passa a incluir gEstornoCred no quarto item.

Na hipótese do retorno 1172, a equipe compara o arquivo com a configuração e identifica a inclusão automática. Corrige essa geração, preservando a venda, os produtos, destinatário e valores verdadeiros. O exemplo não escolhe uma classificação numérica nem comprova emissão ou autorização.

Resultado, calendário e escalonamento

Faça uma tentativa controlada depois da correção e leia a resposta completa. Outro código exige seu próprio diagnóstico. Considere a autorização somente quando chave, ambiente e protocolo estiverem conferidos; conserve o XML e o vínculo com a operação. Procure a contabilidade para classificação e cabimento, e o suporte para divergência entre configuração e transmissão.

O histórico salvo da NT inclui UB116-10/20/30 no pacote 1.30, com produção prevista em 02/02/2026, e alteração da UB116-10 na 1.51, prevista em 05/10/2026. O aviso ENCAT de 05/10 remarca as atualizações enumeradas da 1.52 para 26/10 em homologação e 16/11 em produção. Não estenda esse adiamento automaticamente às regras herdadas. [2]

São registros históricos de 10/10/2026. Esta elaboração local de 12/10 não fez consulta online, teste de emissão ou confirmação de implantação por UF/autorizador. As observações futuras de monofasia nas páginas próximas não foram usadas como dispensa de estorno ou tolerância da 1172.

Fontes

Elaboração documental v2 por IA em 12/10/2026. Não é revisão própria ou cruzada desta versão, aprovação, teste XSD ou entrega final. Capturas históricas e leitura local atual são atos separados.

1. NT 2025.002-RTC v1.52: TXT p.27, 65–66, UB116-10 e regras vizinhas; PNGs documentais 65/66 existentes realmente abertos, sem novo render. Não foram conferidas linhas individuais da tabela nem funcionalidade específica do ALRA.

2. Documentos SVRS e Avisos SVRS: corpos salvos e registros históricos; cronogramas TXT p.5–6. Nenhuma vigência operacional atual certificada.

3. TecnoSpeed, panorama RTC: único apoio prático local utilizado, adjacente, sem três guias específicos comprovados.

Sankhya1172/TOTVS1173 não são usados como apoio nesta v2: a recuperação166 não localizou seus corpos/atos no recorte e manteve o bloqueio bibliográfico. Os registros HTTP403 e a declaração antiga de leitura são distintos; não se afirma inexistência universal das páginas. V1, fontes e cruzada negativa anteriores permanecem intactas.