cancel
Showing results for 
Search instead for 
Did you mean: 

NFe devolução v 2.0 referencia v 1.0 - Erro 547

Former Member
0 Kudos

Bom dia pessoal,

Estamos com um problema de uma devolução de uma nota de 2009, aprovada e versão 1.1.

Quando enviamos a nota de entrada v 2.0 para aprovação ela retorna com o erro: 547 - Rejeição: Dígito Verificador da Chave de Acesso da NF-e Referenciada inválido .

Sabemos que no XML dessa nota de entrada vai a chave de acesso da nota referenciada e aparentemente essa chave para no validador nosso ou da SEFAZ.

Alguem saberia uma solução?

Obrigado desde já

Accepted Solutions (1)

Accepted Solutions (1)

former_member182114
Active Contributor
0 Kudos

Bom dia João P.

Esta rejeição vem da Sefaz, sugiro entrar em contato com ela e depois nos contar.

Lembro que durante o período de migração 1.10 para 2.00 alguns clientes tiveram problemas assim onde só poderiam processar 1.10 com 1.10 e 2.00 com 2.00, mas não me recordo de nenhum posicionamento oficial da Sefaz quanto a isso.

Atenciosamente, Fernando Da Ró

Answers (4)

Answers (4)

Former Member
0 Kudos

Bom dia Henrique,

Essa NFe31100961086336014406550070000220280293356669 é a chave de acesso do XML da nota v1.1 que foi aprovada pela SEFAZ em 2009. No GRC e no XML ela está dessa maneira, porém, no R3 consta para essa nota a chave de acesso 31100961086336014406550070000220280092992286.De alguma maneira, o Random number do R3 está diferente do GRC.

Quando enviamos a nota atual, de devolução (v2.0), no XML dessa vai a chave de acesso da nota v1.1, porém, o que está indo é o 31100961086336014406550070000220280092992286 e não o verdadeiramente aprovado 31100961086336014406550070000220280293356669.

Acredito que se eu corrigir o R3 para ficar de acordo com o GRC nessa nota v1.1, o numero correto vai ser enviado na nota atual e o problema vai ser corrigido. O que acha?

Muito Obrigado,

Joao

henrique_pinto
Active Contributor
0 Kudos

Provavelmente, porém seria crítico entender o que causou a diferença em 1o lugar.

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Bom dia,

Provavelmente funcionará.

@Henrique, no caso de ser uma nota feita em 2009 por um ERP (códigos) antigos acho que nem vale a pena investigar agora o erro provavelmente não acontece mais.

Atenciosamente, Fernando Da Ró

Former Member
0 Kudos

Boa tarde Senhores,

Analisando os campos que disse na nota referenciada Henrique, acredito que encontrei o problema.

A chave da nota de referenciada (saida) no XML da de devolução (entrada).

A chave da nota referenciada (saida) na j1b3n

31100961086336014406550070000220280092992286

A chave da nota de referenciada (saida) no XML enviado para Sefaz.

NFe31100961086336014406550070000220280293356669

Ha uma diferença no numero randomico e no digito verificador entre a chave no XML e no R3.

Não sei pq esse numero esta diferente nas tabelas do GRC e do R3 mas, acho que o procedimento é acertar a tabela j_1bnfe_active para o correto numero randomico da nota de saida no R3 correto?

Também nao consegui encontrar o motivo do erro ter acontecido.

Abraço e obrigado pela ajuda pessoal!

Joao

henrique_pinto
Active Contributor
0 Kudos

Olá Joao Paulo,

com relação à 3a chave de acesso que vc colocou, isso é a chave de acesso no XML original enviado pra SEFAZ?

Ou isso vc está criando agora?

Abs,

Henrique.

Former Member
0 Kudos

Bom dia,

Fernando,

O pessoal do Fiscal irá entrar em contato com a SEFAZ.

Henrique,

Realmente, a nota referenciada (v1.0) está com o número randomico 009299228.

A nota de devolução (v2.0) está com numero randomico 11112222 (O usuário alterou o número a princípio pensando que se tratava de problema na chave de acesso desse.)

No leiaute 1.0 esse número deveria ser diferente de 0? Como essa nota está aprovada, não teríamos então alguma possível ação?

Outro ponto que me ocorreu, essa nota 1.0 é de 2009, háveria um limite de tempo para a nota ficar armazenada no BD da SEFAZ?

Muito obrigado senhores!

henrique_pinto
Active Contributor
0 Kudos

Joao,

nao, o randomico da NFe original está ok.

Quis perguntar se o randomico da 2a estava ok.

Digo, cole aqui os seguintes campos do XML enviado pra SEFAZ:

chave de acesso (@Id)

codigo da UF (cUF)

data de emissão (ide/dEmi)

CNPJ do emissor (emit/CNPJ)

numero da NF-e (ide/nNF)

serie (ide/serie)

modelo (ide/mod)

tipo de emissao (ide/tpEmis)

numero randomico (ide/cNF)

digito verificador (ide/cDV)

Abs,

Henrique.

former_member182114
Active Contributor
0 Kudos

Bom dia João,

No leiaute 1.10 esse número deveria ser diferente de 0? Como essa nota está aprovada, não teríamos então alguma possível ação?

Não era obrigatório o 0 (os 9 numeros eram randômicos) mas a solução SAP sempre preencheu o primeiro dígito com 0 por saber do uso planejado futuro.

Outro ponto que me ocorreu, essa nota 1.0 é de 2009, háveria um limite de tempo para a nota ficar armazenada no BD da SEFAZ?

Não existe um tempo exato, isso varia de Sefaz pra Sefaz, mas já ouvi algo como 6 meses daí passa a dar 217 na consulta de status.

Porém salvo eventuais erros de validação na Sefaz a rejeição é pelo dígito, então a chave estaria errada ou seria por ser "inválida" quanto ao 2.0

Atenciosamente, Fernando Da Ró

henrique_pinto
Active Contributor
0 Kudos

Só pra garantir, o tpEmis não está indo com '0' na chave de acesso não né?

Seria o 1o digito do numero randomico de 9 digitos, no layout 1.10.

Abs,

Henrique.