Rejeição 779: NCM incompatível com a NFC-e

A rejeição 779, regra I05-30, indica NCM incompatível com a NFC-e, modelo 65. Isso é diferente de código incompleto ou inexistente. O MOC registra a condição de incompatibilidade sem fornecer, nessa linha, uma lista nacional de NCM proibidos ou um código substituto. A resposta técnica começa pela classificação e pelo XML do item, preservando a mercadoria real. MOC 7.0, página 90

A observação da página 94 do MOC registra I05-30 como implementação futura, sem produção até a publicação do manual. A documentação consultada não comprova uma ativação posterior universal nem fornece uma lista nacional de NCM incompatíveis. Diante de mensagem 779, confirme se ela veio da SEFAZ ou de uma validação local do emissor, a UF, o ambiente e a condição efetivamente aplicada. MOC, página 94

O que a mensagem permite concluir?

Ela identifica uma incompatibilidade com o modelo 65 no item indicado; não determina que o NCM esteja errado para o produto. Localize ide/mod, o atributo det/@nItem e det/prod/NCM no XML enviado. Guarde o retorno completo, o ambiente e a UF/autorizador. Uma classificação correta para a mercadoria e uma restrição de documentação por NFC-e são questões distintas. Não altere o NCM só porque outro código foi aceito em uma emissão diferente.

Como distinguir 777, 778 e 779?

A 777/I05-10 examina a exigência de NCM completo. A 778/I05-20 compara a existência na tabela sob suas condições. A 779/I05-30 examina compatibilidade com NFC-e. Portanto, oito posições e existência no Classif não encerram o diagnóstico da 779. O Classif ajuda a conferir descrição, vigência e ato do código, mas sua tabela de nomenclatura não se apresenta como lista de autorização de cada operação em NFC-e. MOC, página 90 Classif oficial

Quais dados separam erro de cadastro e restrição do documento?

Compare a ficha técnica, a identificação e os documentos de origem do produto com a classificação previamente confirmada, o cadastro do emissor e o NCM do XML. Se a integração enviou outro código, há uma divergência de representação a corrigir na origem. Se enviou exatamente o código confirmado, registre a regra e peça a verificação da condição aplicada pelo autorizador para esse modelo, período e operação. A linha I05-30 do MOC, isoladamente, não sustenta uma lista universal de produtos proibidos. MOC, I05-30

Exemplo: código correto no cadastro, diferente no XML

Cenário sintético: uma integração usa uma categoria comercial para preencher o NCM, ignorando a classificação confirmada no cadastro. O arquivo enviado recebe outro valor e retorna 779. A comparação revela onde o dado mudou; a correção é preservar a classificação confirmada na geração, seguida de conferência do modelo e da operação.

Em outro cenário sintético, cadastro e XML coincidem e o código existe na tabela oficial. Isso não prova falha do cadastro nem autoriza escolher outro NCM. O responsável fiscal precisa confirmar o documento cabível para aquela operação, com as características do produto e a exigência da UF; o suporte técnico precisa correlacionar o retorno com a tentativa e a regra aplicada.

Como encaminhar um caso que depende da UF?

Reúna o código e a regra completos, modelo, data, ambiente, UF/autorizador, item, classificação confirmada e fundamento que sustenta a documentação da operação. Compartilhe apenas o necessário por canal protegido, sem publicar o XML ou dados de participantes. Uma resposta útil do suporte deve indicar a condição oficial ou a diferença comprovada entre origem e XML.

Não mude produto, NCM ou modelo para forçar autorização. Se outro documento for cabível, essa decisão precisa estar confirmada para a operação; a rejeição sozinha não a toma. Os exemplos não fabricam NCM ou XML operacional porque a classificação e a restrição dependem dos dados reais. Preserve documentos autorizados e esclareça tentativas incertas antes de reenvio.