Jump to content

dev botao

Rejeição: Digito Verificador da chave de acesso composta inválida


Go to solution Solved by marcelolours,
  • Este tópico foi criado há 2012 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Boa noite,

 

Parece meio bizarro até eu estava fazendo uma pergunta com essa mensagem de erro, mas passei a tarde tentando resolver essa situação e não consegui entender porque a nota está dando essa rejeição. 

Diz que o dígito verificador está inválido mas fazendo o cálculo dá pra ver que está certinho, a chave de acesso no xml é 52171201676996000112650100000102959000102959. Tenha uma meia dúzia de notas com esse problema, todas em sequência. 

Dentro do xml o valor dentro da tag de dígito é exatamente 9 <cDV>9</cDV>. Eu também verifiquei no xml todas as informações de CNPJ, estado, número da nota, tudo que está presente na chave está igual. 

 

Vocês tem ideia do porque esse problema está acontecendo?

 

Obrigado

Edited by lucasherrera
Link to comment
Share on other sites

16 hours ago, RicardoVoigt said:

Boa noite

2 detalhes q reparei na chave:

Serie 010

Emitida em contingencia tpemis=9

Confere com o conteudo do xml ?

Att

Ricardo

Confere, o caixa utilizado é 10 e a nota foi emitida em ambiente de contingência.

21 hours ago, BigWings said:

Em qual situação isso ocorre?

Pode fornecer o passo a passo, usando o demo do ACBrNFe para simular o erro?

Anexe o XML para análise.

O Xml é um de um cliente nosso, passar vai ter informações dele lá. 

Link to comment
Share on other sites

  • Moderadores
15 minutos atrás, lucasherrera disse:

Confere, o caixa utilizado é 10 e a nota foi emitida em ambiente de contingência.

O Xml é um de um cliente nosso, passar vai ter informações dele lá. 

E como fazer pra simular o erro?

A validação da chave está retornando como correta então é provável que seja algo no XML.

Sobre a privacidade do XML não tem nada nele que não possa ser obtido via consulta pública da chave de acesso.

A propósito, pela montagem da chave, sugiro fortemente que leia estes tópicos:

 

 

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link to comment
Share on other sites

40 minutes ago, BigWings said:

E como fazer pra simular o erro?

A validação da chave está retornando como correta então é provável que seja algo no XML.

Sobre a privacidade do XML não tem nada nele que não possa ser obtido via consulta pública da chave de acesso.

A propósito, pela montagem da chave, sugiro fortemente que leia estes tópicos:

 

 

Obrigado pela dica do cNF, vou ver de acertar isso. 

Vou anexar o xml 

 

p.xml

Link to comment
Share on other sites

  • Moderadores
12 minutos atrás, lucasherrera disse:

Obrigado pela dica do cNF, vou ver de acertar isso. 

Vou anexar o xml 

 

p.xml

Também não encontrei nada de errado no XML.

O validador da SEFAZ-RS também não acusou a rejeição de chave inválida.

Talvez seja um problema com a SEFAZ-GO, entre em contato com eles e questione a rejeição.

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link to comment
Share on other sites

  • 8 months later...
  • Membros Pro
7 minutos atrás, Thiago Ribeirao disse:

Segue a chave "52181113196296000290550010000001411000001414" @douglaswf

Me parece que o Sefaz  pode ter implementado uma checagem como já foi feito em outros estados que impede que o numero da NF seja exatamente igual ao Codigo Numérico. Faça um teste alterando ele que deve funcionar.

Pode consultar o Sefaz se for isso mesmo ou se for um erro, mas seria melhor adequar o sistema à pratica correta.

Edited by douglaswf
Link to comment
Share on other sites

  • Moderadores
9 minutos atrás, marcosrodrigues disse:
Errado: <dhEmi>2018-11-01T00:00:00-02:00</dhEmi>
Certo: <dhEmi>2018-11-01T00:00:00-03:00</dhEmi>
 
Para resolver basta  mudar o fuso horário do windows para UTC - 03:00  Brasília

Interessante.

Parece que o problema ocorre em virada de mês, nas horas finais ou iniciais do dia.

Dependendo o fuso horário a SEFAZ-GO pode estar interpretando que a nota foi emitida num mês ou no outro, o que alteraria a chave de acesso da nota.

Alguém tem os XML de envio e retorno com essa rejeição?

Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link to comment
Share on other sites

  • Membros Pro

Esse problema começou na data de hoje. Esse digito verificador nós não manipulamos, é feito via ACBRMonitor Plus. Nós criamos um arquivo .ini (anexado) e passamos as instruções pela função criar nfe. Temos outros clientes em outras unidades federativas que não estão com esse problema. Vi também que outros usuários estão relatando mesmo problema aqui no forúm. Aguardo um retorno. Obrigado

nfe-141.ini

Link to comment
Share on other sites

  • Consultores

Bom dia a todos,

Outra coisa, notem a postagem do Marcos Rodrigues a tag <dhEmi> só contem a data, a hora esta toda zerada, isso esta errado.

O correto é atribuir ao campo dEmi ao alimentar o componente a data e hora, em vez de atribuir somente a data em dEmi e a hora em hEmi.

  • Like 1
Consultor SAC ACBr

Italo Giurizzato Junior
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

Analista de Sistemas / e-mail: [email protected] / Fone: (16) 9-9701-5030 / Araraquara-SP

Araraquara - A era dos Trólebus

Link to comment
Share on other sites

1 hora atrás, Italo Jurisato Junior disse:

Bom dia a todos,

Outra coisa, notem a postagem do Marcos Rodrigues a tag <dhEmi> só contem a data, a hora esta toda zerada, isso esta errado.

O correto é atribuir ao campo dEmi ao alimentar o componente a data e hora, em vez de atribuir somente a data em dEmi e a hora em hEmi.

@Italo Jurisato Junior Obrigado pela observação! Irei analisar a questão!

  • Like 1
Link to comment
Share on other sites

  • Moderadores
25 minutos atrás, marcelolours disse:

Agora (14:40) estou com o mesmo problema mas com um cliente na BA.
Vejam que o ACBR está criando a chave com o mês 10. Detalhe que outros clientes estão funcionando e apenas esse cliente está com o executável compilado na última atualização do ACBR.

O que pode ser?

Essa mensagem é retornada pela SEFAZ, não quer dizer que o ACBr gerou essa chave.

Como disse mais acima, acredito que a SEFAZ está gerando a chave com o mês anterior, caso informe data e hora próxima a virada do mês, por causa do fuso horário a nota cai no mês anterior ou posterior.

Caso informe hora 00:00:00 e esteja com o fuso horário incorreto já foi mostrado pelos demais colegas que causa o erro.

Anexe os arquivos de envio e retorno da SEFAZ.

  • Like 1
Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

Link to comment
Share on other sites

  • Este tópico foi criado há 2012 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.