Duplicidade de NF-e

Question

Boa tarde pessoal,
hoje emitimos 2 NFe's no ambiente de DEV no do cliente. As NFe's são:
33100407005330000119550023000004150577201076
33100407005330000119550023000004160209120157
No SAP PI verifiquei que as duas notas foram colocadas no mesmo lote 501.
As duas NFe's foram encaminhadas para a Sefaz e a mesma rejeitou. Segue o XML:
Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e Rejeicao: Duplicidade de NF-e </xMotivo></infProt></protNFe></protNFeStr>
  </protNFeString>
  </nfeRetRecepcaoResponse>
Posteriormente, executei o botão "Consulta do status" no GRC e recebi o retorno:
<ns2:cStat>562</ns2:cStat>
<ns2:xMotivo>Rejeicao: Codigo Numerico informado na Chave de Acesso difere do Codigo Numerico da NF-e</ns2:xMotivo>
Na transação SNUM, o intervalo de numeração se encontra com valor de 510 e o lote foi gerado com o número 501.
Alguém já viu isso?
A duplicidade de NFe pode estar ligada ao fato de no mesmo lote ter 2 NFe's?
Como faço para ter

Answer 1

Bom dia pessoal,
Este código de status novo é para uma situação antiga que normalmente tinha como resultado um 204 e mesmo o Status Query não resolvia a questão.
Onde é comum: DEV/QAS
Motivo: É comum após refresh ou por não existir na empresa uma separação de numeração entre os ambientes chegar até a Sefaz uma mesma numeração porém com chave diferente (normalmente o aleatório). Neste caso, de fato são notas diferentes, geradas em ambientes diferentes, porém com mesma numeração.
Motivo adicional: Mesmo que você tenha vários ambientes DEV/QAS a Sefaz tem apenas 1 ambiente de homologação, e não faz distinção sobre o seu ambiente.
Solução: Customize sua numeração de forma a não conflitar os ambientes, ex.: DEV client xxx de 1 a 100000, DEV client yyy de 100001 a 200000, QAS clilent bbb de 200001 a 300000... E por aí vai.
Observação: Em caso de refresh de ambiente, fazer um backup antes da numeração atual e reinserí-la antes de liberar o ambiente.
Pode também acontecer em produção, porém é raro e normalmente denota uma falha no momento em que estava sendo criada a nota. Se acontecer a criação/transmissão ao GRC, porém por falha de update o ERP "esqueceu" da numeração aleatória então criará novamente e para o GRC/Sefaz será uma nova nota.
Solução para este caso: Investigação no ERP sobre quais chaves, possíveis erros, investigação no GRC para saber as chaves envolvidas e na Sefaz para saber qual é a que foi autorizada. Por fim, acertar o ambiente na mão conforme o encontrado na Sefaz.
@Bernardo, sim o decouple reduz quase a zero a possibilidade disto acontecer em produção por falhas de sistema.
Atenciosamente, Fernando Da Rós
@Sergio, se sua questão foi respondida ou quando for poderia fechá-la (marcar como respondida). Verifiquei que você tem várias questões abertas e isto confunde o fórum. Total Questions:  82 (47 unresolved)
Edited by: Fernando Ros on Apr 26, 2010 8:20 PM