Ir para conteúdo
  • Cadastre-se

dev botao

Duplicadade de CT-e com diferença na chave de acesso


Ver Solução Respondido por Italo Giurizzato Junior,
  • Este tópico foi criado há 1843 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

  • Moderadores
Postado

Significa que o CTe 476 da mesma série e emissor já existe.

Na mensagem de retorno do webservice deve constar a chave correta do CTe 476.

Basta consultar a chave pelo portal e pelas informações do CTe você deve ser capaz de saber o que houve.

  • Curtir 2
Equipe ACBr BigWings
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr

 

 

  • Consultores
  • Solution
Postado

Bom dia,

A rejeição referente a duplicidade só ocorre quando é enviado um outro documento com o mesmo numero e serie, ou quando se envia o mesmo documento pela segunda vez.

O que deve ter ocorrido:

1. Foi enviado o CT-e de numero 476 serie 1;

2. Ocorreu algum erro, do tipo timeout;

3. O usuário enviou novamente o mesmo CT-e;

Como a sua aplicação gera o XML antes do envio e não utiliza o mesmo cCT definido no envio anterior ocorreu a rejeição de duplicidade com diferença de chave.

Vamos a um exemplo:

Primeiro envio: CT-e de numero 476, série 1, cCT igual a 13

Segundo envio: CT-e de numero 476, série 1, cCT igual a 14

Se no primeiro envio apesar do erro de timeout a SEFAZ recebeu o CT-e e o autorizou, ao enviar pela segunda vez o mesmo CT-e a SEFAZ vai rejeitar pois já existe o CT-e de numero 476 e série 1, como o cCT é diferente vai acusar que a rejeição por duplicidade com diferente de chave, entenda diferença de chave como sendo cCT diferentes.

Como eliminar esse tipo de rejeição:

1. Ao salvar no banco de dados as informações referente ao CT-e, gere e armazene também junto com os demais dados o cCT (Código do Conhecimento de Transporte).

Esse código deve ser aleatório e temos uma função para isso: GerarCodigoDFe.

Devemos passar como parâmetro a essa função o numero do Conhecimento de Transporte - nCT.

2. Ao alimentar o componente com os dados do CT-e, devemos ler do banco de dados o campo que contem o código e atribuir a cCT.

Desta forma a chave que o componente gera será sempre igual, portanto com isso eliminamos a rejeição por diferença de chave.

3. Se ao enviar ocorrer erro, jamais envia novamente, pelo simples fato de não sabermos se o erro de conexão ocorreu durante o envio ou durante o retorno.

O correto neste caso é, carregar o XML do CT-e (que ocorreu erro de conexão) através do método LoadFromFile e em seguida executar o método Consultar.

Se o erro ocorreu no retorno, ao consultar novamente e se essa consultar for bem sucedida o XML do CT-e será atualizado com o protocolo de autorização caso ele tenha sido autorizado.

Por outro lado se o erro ocorreu durante o envio a SEFAZ vai retornar uma rejeição acusando que o CT-e não existe na base de dados, ai sim devemos enviar novamente.

Desta forma eliminamos de vez o problema de rejeição por duplicidade.

Espero ter ajudado.

  • Curtir 1
Consultor SAC ACBr

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

Projeto ACBr

Analista de Sistemas / Araraquara-SP

Araraquara - A era dos Trólebus

  • Este tópico foi criado há 1843 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.
Visitante
Este tópico está agora fechado para novas respostas
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.

The popup will be closed in 10 segundos...