Problema Com Duplicidade E Perda De Xml

[GustavoKato]

Boa tarde, caros colegas...

Ontem (12/12/2012) ocorreu  um problema na SEFAZ de SP e ocasionou uma série de problemas.

Desenvolvi meu próprio gerenciador/monitor de ct-es o qual lê os xmls da base de dados, transmite e grava o retorno. Porém com a lentidão/queda da SEFAZ, retornou o erro "Rejeição: Uso indevido", assim, o usuário gerou o XML novamente ocasionando a criação de uma nova Chave e novo arquivo, e ao tentar transmitir, retornou erro de duplicidade, pois os CT-es foram autorizados porém o retorno veio incorreto. Resumindo, sobrescreveu o XML antigo (autorizado) e criou outro com o mesmo número de conhecimento.

 

Se não bastasse, o site não está permitindo realizar o download do XML autorizado, minha dúvida é: Há alguma forma de carregar o XML e alterar alguns campos e gerar novamente sem alterar a Chave (function TCTeW.GerarXml)?

 

por ex:

if CTe.infCTe.ID = '' then

  GerarChave();

[Italo Giurizzato Junior]

Boa tarde Gustavo,

 

Altere a sua aplicação de tal forma que após o XML ter sido gerado e enviado, impressa que seja gerado novamente o XML para o mesmo conhecimento. Caso ocorra o problema de enviar e não obter o retorno com o protocolo de autorização, crie um botão que permita selecionar o Conhecimento enviado mas não protocolado, feita a escolha carrega-se o XML do mesmo para o componente e realiza-se uma consulta, isso faz com que se o mesmo realmente foi enviado e já foi processando o XML vai receber as tags do protocolo de autorização.

 

A titulo de exemplo, estude os fragmentos de código ( em formato TXT) que estão dentro da pasta ...\Exemplos\ACBrCTe.

[Alexsander]

Outra dica: usar números aleatórios na tag cNF, conforme sugere o manual.

Assim, se por algum motivo gerar novamente o XML, pelo menos não sobrescreve.

[GustavoKato]

Boa tarde Gustavo,

 

Altere a sua aplicação de tal forma que após o XML ter sido gerado e enviado, impressa que seja gerado novamente o XML para o mesmo conhecimento. Caso ocorra o problema de enviar e não obter o retorno com o protocolo de autorização, crie um botão que permita selecionar o Conhecimento enviado mas não protocolado, feita a escolha carrega-se o XML do mesmo para o componente e realiza-se uma consulta, isso faz com que se o mesmo realmente foi enviado e já foi processando o XML vai receber as tags do protocolo de autorização.

 

A titulo de exemplo, estude os fragmentos de código ( em formato TXT) que estão dentro da pasta ...\Exemplos\ACBrCTe.

Italo, criei a rotina de consulta do estatus do CT-e, porém quando retorna com rejeição permito q o usuário altere os dados e gere novamente o XML (não é gerado o arquivo, somente gravado na base de dados) e foi o q aconteceu, entretanto neste caso o CT-e foi autorizado mas retornou Rejeição (deve ser algum problema quando o SEFAZ está instável).

 

 

Outra dica: usar números aleatórios na tag cNF, conforme sugere o manual.

Assim, se por algum motivo gerar novamente o XML, pelo menos não sobrescreve.

são usados números aleatórios, gravo o XML em um campo onde a chave é Empresa e Conhecimento. Ou seja, só gravo XML em arquivo depois que o mesmo foi autorizado

 

 

 

Obrigado pelo retorno.

[Doni Delphi]

Gustavo

 

Não sei como sua aplicação trabalha, mas voce já leu a Nota Técnica 2012/006

[GustavoKato]

Doni, já sim... fiz alguns ajustes mas acho que só a rotina de consulta de status do ct-e não esteja 100% correta.

[Márcio B.]

Boa tarde Gustavo,

 

Altere a sua aplicação de tal forma que após o XML ter sido gerado e enviado, impressa que seja gerado novamente o XML para o mesmo conhecimento. Caso ocorra o problema de enviar e não obter o retorno com o protocolo de autorização, crie um botão que permita selecionar o Conhecimento enviado mas não protocolado, feita a escolha carrega-se o XML do mesmo para o componente e realiza-se uma consulta, isso faz com que se o mesmo realmente foi enviado e já foi processando o XML vai receber as tags do protocolo de autorização.

 

A titulo de exemplo, estude os fragmentos de código ( em formato TXT) que estão dentro da pasta ...\Exemplos\ACBrCTe.

 

Boa noite,

 

 

Sei que o tópico é antigo mas gostaria de deixar um "situação".

 

Há muito tempo fiz o programa para recuperar as tags da forma que esta nos exemplos do ACBr. Mas quando fiz a remontagem destas tag usando o "ACBrCTe1.Consultar;" o contador de um cliente informou que o XML que eu havia "remontado" esta errado. Analisando o xml realmente encontrei diferença nas tags: DigestValue e SignatureValue entre o XML consultado e o que baixei do site da receita. O contador deste meu cliente me chamou a atenção dizendo que o correto era o da receita e que este "remontado" não é fiscalmente aceitável.

 

Caso alguém com mais conhecimento contabil e fiscal, do que eu, quiser dar a sua opnião eu agradeço.

 

 

Márcio

Editado 9 Dezembro, 2014 por W32Blood

[Italo Giurizzato Junior]

Bom dia Márcio,

 

Podemos dizer que o XML de um documento fiscal eletrônico para ter validade jurídica tem que possui 3 seções:

 

1. conteúdo do documento fiscal;

2. assinatura digital;

3. informações sobre o protocolo;

 

As TAGs: DigestValue e SignatureValue estão contidas no grupo <Signature>, ou seja a seção "2", não podemos comparar o conteúdo dessas duas TAGs elas sempre serão diferentes, uma vez que a SignatureValue traz a assinatura e a DigestValue traz uma especie de checksum da seção "1".

 

Se você observar na seção "3", mais precisamente o grupo <infProt> possui uma TAG chamada digVal esta sim deve ser comparada com a TAG DigestValue, elas devem possui e mesmo conteúdo.

 

Se digVal for igual a DigestValue e cStat = 100 (Autorizado o uso) podemos dizer que o XML em questão é um Documento Fiscal Eletrônico com validade jurídica.

[Márcio B.]

Bom dia Márcio,

 

Podemos dizer que o XML de um documento fiscal eletrônico para ter validade jurídica tem que possui 3 seções:

 

1. conteúdo do documento fiscal;

2. assinatura digital;

3. informações sobre o protocolo;

 

As TAGs: DigestValue e SignatureValue estão contidas no grupo <Signature>, ou seja a seção "2", não podemos comparar o conteúdo dessas duas TAGs elas sempre serão diferentes, uma vez que a SignatureValue traz a assinatura e a DigestValue traz uma especie de checksum da seção "1".

 

Se você observar na seção "3", mais precisamente o grupo <infProt> possui uma TAG chamada digVal esta sim deve ser comparada com a TAG DigestValue, elas devem possui e mesmo conteúdo.

 

Se digVal for igual a DigestValue e cStat = 100 (Autorizado o uso) podemos dizer que o XML em questão é um Documento Fiscal Eletrônico com validade jurídica.

 

 

Bom dia,

 

 

Realmente a SignatureValue está diferente entre os dois arquivos.

 

Quanto a comparação da digVal para DigestValue:

 

- No XML da receita:

 

<DigestValue>9zeyZFoKUFcBnu7pj1qIBpuPMzk=</DigestValue>

<digVal>9zeyZFoKUFcBnu7pj1qIBpuPMzk=</digVal>

 

- No XML que Foi consultado:

<DigestValue>e9rCsIcuohcj4co5bsT7bPOs8wY=</DigestValue>

<digVal>9zeyZFoKUFcBnu7pj1qIBpuPMzk=</digVal>

 

Por esta diferença acredito que o contador tenha razão.

 

E também acredito que o usuário ficou tentando mandar o arquivo varias vezes e foi criado outro arquivo xml.

 

Vou criar um teste para evitar que cada fez que ele clique gere um novo arquivo e apenas consultar o primeiro.

 

Márcio

[Leandro Miler Santana]

      Caro amigo GustavoKato.

 

      Se você for gerar o CTe no ACBrCTE sempre com números aleatórios diferentes, realmente sempre vai gerar Chaves diferentes.

 

      Quando você for gerar o CT-e, no AcbrCTE você terá que especificar o número aleatório que será usado para calcular o dígito da chave do CT-e. Este número você tem que gravá-lo no seu banco de Dados, para se for preciso gerar o XML novamente, este número aleatório você utiliza o mesmo número já gravado. Desta forma, todas as vezes que você for gerar o XML, o sistema irá gerar a mesma Chave.

 

       Este número aleatório tem que ser informado no campo

 

       Ide.cCT:=iNum;       // Codigo aleatorio gerado para cada CTe

 

       Espero ter ajudado.

 

       Abraços.

 

[Wislei de Brito Fernandes]

Boa tarde,

 

Gostaria da ajuda de vocês para o seguinte problema.

 

Hoje pela manhã, o WebService de MG estava com uma instabilidade tremenda, e em um de nossos clientes, durante a emissão de um CT-e, ele recebeu a mensagem: Lote em processamento.

 

Neste caso, o CT-e foi recebido pelo WebService, mas não conseguiu enviar o retorno do processamento do mesmo.

 

Ao invés do meu cliente aguardar e tentar reenviar/consultar este CT-e novamente mais tarde, ele alterou o tipo de emissão para 5 - FS-DA, imprimiu o DACTE e liberou o carregamento.

 

Agora a tarde, ao tentar autorizar este CT-e em FS-DA, recebeu a seguinte Rejeicao: Existe CT-e ja autorizado com a mesma serie e numero.

 

Eu já tentei de todas as formas tentar consultar este CT-e ou voltar o tipo de emissão para 1 - Normal, mas todas as tentativas sem sucesso para obter os dados de autorização.

 

Eu estou suspeitando que ao emitir o CT-e em FS-DA, a chave aleatória foi sobreposta à primeira. =/

 

Vocês tem alguma sugestão para me dar?

 

Atenciosamente.

[Italo Giurizzato Junior]

Bom dia Wislei,

 

Você não tem o XML do CT-e que foi enviado segundo o tipo: Normal?

 

Se sim, basta carrega-lo com o loadfromfile e executar o consultar.

 

Outra coisa, altere a sua aplicação de tal forma que impeça o usuário a fazer essa bobagem.

[Wislei de Brito Fernandes]

Bom dia Italo,

 

Conseguimos resolver o problema ao verificar na pasta em que armazenamos os XML's constavam os dois arquivos (com o tipo de emissão 1 e 5).

 

Então fizemos como você sugeriu, realizamos uma consulta carregando o XML correto e deu tudo certo.

 

Já fizemos o devido tratamento também para isso não ocorrer novamente.

 

Mais uma vez, muito obrigado pela atenção.

 

Atenciosamente.