Rejeição 925: idEstrangeiro informado junto com IE do destinatário

O conflito verificado pela rejeição 925

A Rejeição 925 corresponde à regra E03a-30: quando dest/idEstrangeiro é informado, não pode ser informada também a IE do destinatário em dest/IE. A regra abrange modelos 55 e 65. A NT 2019.001 v1.70 mantém essa condição; não é uma validação do dígito da IE nem uma consulta de cadastro para saber se o estrangeiro possui inscrição.

MOC — Anexo I, Leiaute e Regras de Validação 7.0 NT 2019.001 1.70

Os dois campos precisam pertencer ao mesmo destinatário

Em NFe/infNFe/dest, idEstrangeiro identifica o comprador estrangeiro; IE é a inscrição estadual do destinatário. Compare esses campos no mesmo XML enviado e não a IE de emit, retirada ou entrega. idEstrangeiro integra a escolha de identificação entre CNPJ, CPF e documento estrangeiro; IE aparece em outro ponto do grupo. Por isso um serializador pode manter uma IE antiga mesmo depois da mudança da alternativa de identificação. O fato de os elementos caberem no XSD não prova que sua combinação é admitida pela E03a-30.

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

Investigue o cadastro antes de retirar qualquer informação

Confira qual participante efetivamente consta do pedido, qual documento o identifica e de onde veio a IE. Uma troca de cadastro pode deixar dados de outro comprador; uma integração pode preencher IE usando um campo genérico da empresa emitente; ou o cadastro estrangeiro pode ter recebido uma inscrição sem comprovação. A correção deve decorrer dessa comparação. Não basta apagar a IE em todos os cadastros estrangeiros ou trocar idEstrangeiro por CPF: esses atalhos podem alterar informação verdadeira e afetar outras operações.

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: identificação mudou e a inscrição ficou

Imagine que uma integração troque a identificação de um comprador nacional para um comprador estrangeiro, preservando por engano a IE do registro anterior. O XML contém idEstrangeiro do destinatário selecionado e uma IE que não corresponde a ele. O diagnóstico se confirma pelo histórico do vínculo e pelo documento do comprador. Corrija a seleção ou o mapeamento que misturou os participantes e gere novamente. Se ambos os dados foram fornecidos deliberadamente, confirme a identidade e a situação cadastral com os documentos da operação antes de decidir qual representação é correta.

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 separar rejeições próximas e confirmar o resultado

A 210/E17-50 verifica validade da IE na NF-e; a 792/E17-40 confronta IE com endereço no exterior; a 925 verifica especificamente idEstrangeiro e IE juntos. Ausência de IE não representa zero nem a palavra ISENTO. Depois de corrigir a origem comprovada, confira a alternativa de identificação e o conteúdo de dest no novo XML, mantendo o original assinado e o retorno. Autorização exige resultado fiscal da mesma tentativa; comunicação anterior incerta deve ser esclarecida antes de retransmitir.

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 NT 2019.001 1.70

Limite dos exemplos e da conferência

A incompatibilidade exige conferir a identidade protegida do destinatário e a origem da IE. Exemplos textuais de coexistência preservam esses dados e evitam fabricar documento estrangeiro ou inscrição. Nenhum exemplo desta página é um documento pronto para transmissão.