rejeição 680 - duplicidade chave de acesso...

[Former Member]

caros...

estou com um caso aqui.

foi efetuado um pedido de compras e efetuada duas entradas parciais.

a segunda entrada foi estornada pela MR8M e, depois, feita a entrada novamente (mesma NF-e de referência).

após isso, foi feita uma MIRO de crédito referente à essa segunda entrada para geração da NF-e de devolução de compra.

ao ser enviada para validação da SEFAZ, está ocorrendo a rejeição 680 Duplicidade de NF-e referenciada (Chave de Acesso referenciada mais de uma vez).

visualizando o xml, vemos que a tag NFref e refNFe está sendo gerada duas vezes, conforme abaixo:

- <NFref>

  <refNFe>42130803346055000146550010000037081288643823</refNFe>

  </NFref>

- <NFref>

  <refNFe>42130803346055000146550010000037081288643823</refNFe>

  </NFref>

alguém já teve caso semelhante...???

pesquisei e não encontrei nada a respeito.

[Former Member · Accepted solution]

André,

Identificamos o mesmo problema no nosso projeto.

Após a entrada da NT003/2013, sempre que para uma mesma NFe a ser devolvida, possuir um outro docnum porém estornado, a Badi parece carregar indevidamente as duas referencias indevidamente, a original e a estornada. Tanto que se você tentar devolver uma NFe sem estorno anterior, o erro não ocorrerá.

Se você tem tempo habil, sugiro abrir chamado na SAP, pois aqui vamos tentar tratar direto na Badi.

Depois da uma revisada na nota em seu ambiente.

Note 1860005 - NF-e Nota Técnica 2013.003

Grato.

Bruno Ferrari

[Former Member · Accepted solution]

oi Bruno...

passamos o detalhamento do debug pro cliente e o mesmo, como não tinha urgência, decidiu por abrir chamado na SAP.

esse processo ele vai fazer diretamente e sem envolvimento, inicial, aqui da Consultoria, mas estamos esperando que ele nos informe da resposta da SAP.

tivemos outro caso idêntico em outro cliente, mas como era um caso único, ele optou por uma solução de contingência, a eliminação de uma das linhas debug.

segundo o ABAP que fez o debug, no comportamento atual do programa, quando ele efetua um select na J_1BNFE_ACTIVE, ele encontra dois documentos (devido à chave de acesso) e, mesmo tendo um deles com a marcação de eliminado, o programa continua considerando ele.

segundo o ABAP, daria pra utilizar um enhancement para limpar o item marcado como eliminado e considerar somente o documento válido.

[former_member182114 · Accepted solution]

Bom dia pessoal,

Mesmo que optando por resolver em casa, vale sempre um chamado à SAP para correção do standard.

Atenciosamente, Fernando Da Rós

[Former Member · Accepted solution]

agora a pouco, recebi uma ligação do primeiro cliente que havia tido esse problema e que tinha optado pela solução de contorno, a exclusão do registro duplicado via debug.

tiveram um novo problema idêntico lá.

devido à urgência, tratamos novamente com uma solução de contorno, excluindo o registro duplicado via debug, mas orientamos/solicitamos que abram chamado na SAP para este problema ser tratado no standard.

estamos aguardando retorno dos dois clientes a respeito da abertura do chamado...

[Former Member · Accepted solution]

André, bom dia!

Realmente muitos clientes estão relatando o problema, tendo em vista a SEFAZ ter iniciado a validação dessa tag com a NT003.

Favor nos informe a resposta da SAP e uma eventual nota corretiva.

Muito obrigado.

Bruno Ferrari

[Former Member · Accepted solution]

buenas...

acabei de receber retorno do primeiro cliente que abriu chamado junto à SAP.

relatou:

"A SAP orientou aplicar as notas 1876338 e 1885959 e, feito isto, o problema foi solucionado: a nota de crédito passou a referenciar a entrada correta, desconsiderando os documentos estornados."

passei a info pro segundo cliente nosso e eles irão aplicar essas notas internamente e depois informar se o resultado foi OK pra eles tb...

[Former Member · Accepted solution]

Boa tarde!

Obrigado por replicar a informação.

Grato.