Rejeição 789: indicador de contribuinte na NFC-e

O indicador examinado pela rejeição 789

A Rejeição 789, E16a-10, ocorre na NFC-e modelo 65 quando o indicador de inscrição estadual do destinatário, dest/indIEDest, é diferente de 9, Não Contribuinte. O campo é um indicador de situação do destinatário, e não o número da inscrição estadual. A condição da regra é a incompatibilidade do indicador com o modelo 65; ela não demonstra por si que o cadastro real deva ser alterado.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Os valores 1, 2 e 9 têm significados distintos

No leiaute, 1 representa contribuinte do ICMS, com informação de IE; 2 representa contribuinte isento de inscrição no cadastro de contribuintes; 9 representa não contribuinte, que pode ou não possuir IE no cadastro de contribuintes do ICMS. Contribuinte isento e não contribuinte não são sinônimos. Possuir um CNPJ também não prova automaticamente a condição de contribuinte. Na NFC-e, a nota do campo indIEDest determina valor 9 e ausência da tag IE do destinatário. Uma combinação estruturalmente possível no XML pode continuar incompatível com a regra fiscal do modelo.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Como comparar cadastro e XML sem decidir pelo retorno

Confira o participante real, sua situação documental/cadastral, o modelo pretendido e NFe/infNFe/dest/indIEDest no arquivo transmitido. Se o cadastro guarda situação confirmada, mas o XML recebe valor 1 ou 2 por padrão, investigue o mapeamento específico da NFC-e. Se a própria situação do destinatário ou o documento cabível são desconhecidos, leve a operação, destinação e cadastro oficial ao responsável fiscal antes de decidir a representação. A rejeição não autoriza trocar 1 por 9 em todos os clientes nem mudar o modelo sem avaliar a operação.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Exemplo de indicador herdado

Considere um emissor que usa o mesmo objeto de destinatário para NF-e e NFC-e. Ao gerar NFC-e, ele herda indIEDest=2 de um cadastro sem conferir o contexto. A E16a-10 alcança a combinação. O diagnóstico exige descobrir se o dado cadastral está correto e se a operação admite o documento pretendido. Se o cadastro foi classificado por suposição, obtenha a confirmação necessária. Se a integração alterou uma informação confirmada, corrija sua transformação. Nenhuma dessas hipóteses permite fabricar uma situação cadastral para satisfazer a validação.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Como verificar o próximo resultado

Preserve XML e retorno e compare o indicador e a presença de IE no grupo dest após uma correção comprovada na origem. A 790/E16a-20 trata de indIEDest na NF-e com exterior; não é a mesma regra da NFC-e. A 728 trata de falta de IE quando a NF-e indica contribuinte. Não transporte exigências entre modelos apenas pelo campo compartilhado. Gere o arquivo pelo emissor, preserve documentos assinados e autorizados e esclareça tentativas anteriores incertas antes de outro envio. Ausência de 789 não comprova autorização.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 Leiaute da NF-e e protocolo PL_010f_v1.04 / leiauteNFe_v4.00.xsd

Limite dos exemplos e da conferência

A aplicação depende da situação real do participante e do modelo cabível. Os valores de domínio são comparados textualmente, sem fabricar inscrição ou cadastro do destinatário. Nenhum exemplo desta página é um documento pronto para transmissão.