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

[lucasherrera]

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

Editado 7 Fevereiro, 2018 por lucasherrera

[BigWings]

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.

[RicardoVoigt]

5 horas atrás, lucasherrera disse:

52171201676996000112650100000102959000102959

Boa noite

2 detalhes q reparei na chave:

Serie 010

Emitida em contingencia tpemis=9

Confere com o conteudo do xml ?

Att

Ricardo

[lucasherrera]

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á. 

[BigWings]

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:

 

 

[lucasherrera]

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

[BigWings]

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.

[lucasherrera]

Está certo então, vou fazer uma consulta no Sefaz.

 

Obrigado pelas respostas

[marcelolours]

Estou com esse problema. Apareceu de repente.
O código funciona e de repente começou a dar essa mensagem. É problema na SEFAZ GO?

Att

[p.emoraes]

9 horas atrás, marcelolours disse:

Estou com esse problema. Apareceu de repente.
O código funciona e de repente começou a dar essa mensagem. É problema na SEFAZ GO?

Att

Estou com o mesmo problema em GO, oque pode ser? alguém tem alguma ideia?

 

[Thiago Ribeirao]

Bom dia, estou com mesmo problema em um cliente do Estado de GO, problema na sefaz do Estado de GO?

[douglaswf]

Pode citar uma chave de exemplo?

[Thiago Ribeirao]

Segue a chave "52181113196296000290550010000001411000001414" @douglaswf

[douglaswf]

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.

Editado 1 Novembro, 2018 por douglaswf

[marcosrodrigues]

Pessoal, liguei no Sefaz e o problemas e as informações das seguinte tag:

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

[BigWings]

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?

[IMATECH]

Problema são os micros que estão ajustando para o horário de verão automaticamente

Correção: Só corrigir o relógio do micro ( desativar horário de verão automático )

[Thiago Ribeirao]

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

[Thiago Ribeirao]

O problema era o fuso horario mesmo, entrei nas configurações de data/hora no windows, deu certo. Obrigado pela ajuda.

[Italo Giurizzato Junior]

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.

[marcosrodrigues]

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!

[marcelolours]

Eram 23:38 dia 31/10 quando fui enviar a nota. O que observei foi que o ACBR gerou a chave (não sei como) já no mês 11.
O horário no PC e na Sefaz estavam iguais.

Aguardei 30 minutos e enviei de novo e deu certo.

[marcelolours]

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?

[marcelolours]

Porque está acontecendo isso? O XML está sendo gravado com o ano e mês correto. Mas no xMotivo está mês 10.
O problema deve ser na Sefaz, certo?

[BigWings]

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.