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

[NecBrasil]

Boa tarde,

Fiz a emissão de um CT-e de número 475 porém quando fui emitir outro CT-e com o mesmo CNPJ emissor com o número 476 apareceu o erro de duplicidade.

Estou rodando em ambiente de homologação.

35191147698881000120570010000004761000000140-cte.xml35191147698881000120570010000004751000000100-cte.xml

[BigWings]

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.

[Italo Giurizzato Junior]

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.

[NecBrasil]

Obrigado, problema resolvido.

[Italo Giurizzato Junior]

Obrigado por reportar.

Fechando. Para novas dúvidas, criar um novo tópico.