Rejeição 742: IPI na NFC-e ou NF-e com DANFE Tipo 2

A rejeição 742/O01-10 identifica grupo IPI em item de NFC-e 65 ou de NF-e 55 com DANFE Simplificado Tipo 2, tpImp=6. A presença do grupo é o critério, mesmo com imposto zero.

Qual IPI a regra procura

O grupo analisado está em infNFe/det/imposto/IPI. Dentro dele, cEnq identifica o enquadramento legal, e IPITrib ou IPINT representam a situação tributária. A O01-10 não exige um valor positivo para rejeitar a NFC-e: um grupo com situação não tributada também continua sendo IPI.

Isso é diferente de impostoDevol/IPI, grupo destinado ao IPI devolvido, que possui outra regra na NFC-e, a 390/UA01-20. Também é diferente de total/ICMSTot/vIPI: um total é campo de consolidação, e não substitui o grupo de tributação do item.

Fontes: MOC 7.0 Anexo I v7.00, p. 118, NT 2020.002 — IPI v1.01, p. 4–5, Leiaute NF-e/NFC-e — PL 010f v1.04.

Exemplo de configuração copiada de NF-e

Exemplo sintético: uma integração configurada para gerar NF-e 55 monta o grupo IPI de um item. Ao criar uma NFC-e 65, copia integralmente o bloco de impostos, incluindo IPI/IPINT, embora não exista vIPI positivo. O resultado satisfaz a condição da 742. Zerar um imposto não remove o grupo nem demonstra que a operação foi representada corretamente.

O diagnóstico compara modelo solicitado, modelo serializado em ide/mod e grupos efetivamente gerados para cada item. Se o modelo 65 está confirmado e a origem não previa IPI, o problema é a montagem indevida do grupo. Se os documentos da operação realmente exigem representação incompatível com o modelo selecionado, falta confirmar o documento cabível; não se resolve trocando o modelo apenas para passar na validação.

Não há XML operacional inventado para ilustrar uma combinação vedada. A comparação textual identifica o caminho a procurar no XML original protegido.

Fontes: MOC 7.0 Anexo I v7.00, p. 118, NT 2020.002 — IPI v1.01, p. 4–5.

Como corrigir o gerador sem apagar informação fiscal

Preserve o payload de origem e o XML rejeitado. Verifique se o grupo veio de um cadastro, padrão global, importação ou cópia de documento. Compare essa origem com os parâmetros fiscais confirmados. A ausência estrutural permitida pelo XSD não dispensa conferir o modelo e as regras de negócio.

Quando comprovada a inclusão indevida em uma NFC-e válida para a operação, corrija a geração na origem e confira os demais grupos e totais afetados. Não apague o cadastro fiscal do produto para todas as operações. Quando o tratamento fiscal ou modelo estiver indefinido, leve descrição da operação, documentação e origem do IPI ao responsável contábil. Valide a nova geração e acompanhe o retorno; esclarecer tentativa incerta antecede novo envio. A regra não apresenta dispensa geral de IPI por CRT para uma NFC-e.

Fontes: MOC 7.0 Anexo I v7.00, p. 118, NT 2020.002 — IPI v1.01, p. 4–5.

Quando a NF-e com DANFE Tipo 2 também entra na regra

A NT 2026.002 v1.11, p. 17, atualiza a O01-10: além da NFC-e, modelo 65, a restrição alcança a NF-e, modelo 55, com DANFE Simplificado Tipo 2, identificado por ide/tpImp=6. A linha está íntegra; não se deve aplicar a rasura de outras validações a esta regra. Uma NF-e 55 com outro tipo de impressão não entra nessa extensão apenas por conter IPI.

Confira ide/mod e ide/tpImp no XML da mesma tentativa, além do grupo IPI do item. Em cenário sintético, modelo 55 e tpImp=6 com esse grupo satisfazem a combinação descrita. Modelo 55 e tpImp=1 não satisfazem a condição de Tipo 2 desta regra; isso não valida automaticamente a operação ou seus demais campos. Os exemplos anteriores de modelo 65 continuam válidos e não são as únicas situações abrangidas.

O cronograma específico da ampliação registra homologação em 01/07/2026 e produção em 03/08/2026. Essas datas documentais não comprovam ativação individual de um autorizador. Não mude modelo ou tpImp verdadeiros para contornar o retorno: confirme o documento e a forma de emissão cabíveis e corrija somente a divergência demonstrada no gerador.

Fonte: NT 2026.002 v1.11, pp. 3 e 17.