Cupom SAT autorizado em duplicidade

[sgeinformatica]

No dia 04/01 tivemos um problema inusitado, e descobrimos que o SAT registrou 3 vendas iguais
Entramos no site da secretaria da fazenda para consultar e encontramos 3 cupom sat 24390 / 24391 / 24392
Todos com mesmo valor, e mesmo nro. lancamento de venda 581637
No nosso sistema tem apenas 1 venda, e no log que registra as requisicoes tem apenas 1 requisicao para autorizar o cupom

No arquivo de LOG, ficou registrado que o programa de frente de caixa pediu autorização para imprimir o cupom as 10:04:34
Nos temos uma segunda aplicacao apenas para conversar com o SAT, e ele retornou que a autorizacao foi dada as 10:11:27
Isto é, 7 minutos depois
Nesse tempo a aplicacao ficou parada aguardando o retorno.
Depois disso apareceu 2 cupom extra autorizados.
A algum tempo atras se nao me engano, eu li aqui no forum, que o timeout para conversar com o SAT quem determina é DLL 

Se fosse nossa aplicacao que tivesse autorizado, teria mais 2 linhas de LOG para o mesmo nro. de venda, o que nao ocorreu.
Nos descobrimos isso, porque fiz um relatorio para mostrar nro. de cupom faltando num determinado periodo

A unica explicacao que chegamos que isso provavelmente deve ser algum falha de comunicacao da DLL com o SAT
Provavelmente a DLL tentou autorizar o cupom por 2 vezes, e somente na 3a que obteve reposta.
Eu imagino que o componente não deve ficar tentando autorizar o cupom varias vezes, o Daniel conseguiria responder isso melhor.
O SAT é da marca Elgin

Alguém já passou por isso?
 

[Sérgio Assunção]

Se foram autorizadas 3 vendas é porque foram enviados 3 requisições ao aparelho. Talvez o operador na ansiedade apertou o enter por diversas vezes e aplicação permitiu. Não é uma afirmação, mas sim uma hipótese.

[sgeinformatica]

Se isso tivesse acontecido, o log teria registrado mais de uma linha. Veja na tela que mandei em anexo, que foi requisitado apenas 1 vez

[Daniel Simoes]

Tudo que o ACBrSAT faz é chamar o método da DLL, e aguardar a resposta do método... o ACBrSAT nunca fala diretamente com o SAT

Veja o Log gerado pelo ACBrSAT... todos os envios e respostas ficam registrados nele...

Extraia o Log do SAT, e veja os envios de dados que a DLL fez ao SAT

[sgeinformatica]

Verdade, nem me lembrei desses 2 arquivos de LOG

Vou verificar e depois eu posto aqui o que encontrei

[sgeinformatica]

Daniel, no log do ACBrSAT apareceu as 3 requisições de venda

Na primeira venda me parece que esta normal.

 - 10:04:37:096 - -- 10:04:37:088 - numeroSessao: 283532 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?>

Ja na segunda venda, apareceu a seguinte mensagem : 

 - 10:09:10:840 - ACBrSAT.Inicializado
 - 10:09:14:053 - -- 10:09:14:004 - numeroSessao: 470985 - Comando: EnviarDadosVenda( <?xml version="1.0" encoding="UTF-8"?>

Sera que isso pode ter sido uma oscilação na energia e o aparelho de SAT desligou e ligou novamente?

Constatei que e o computador esta ligado apenas no estabilizador.

Mas o nosso frente de caixa fez apenas uma requisição. 

To meio perdido, não consigo imaginar a causa do problema

 

LOG_ABCrSAT.txt

[Daniel Simoes]

Se no Log do ACBrSAT há 3 requisições, então é porque a sua aplicação fez 3 requisições...

Repare que não há loops dentro do ACBrSAT, que poderiam ter causado esse tipo de problema...

[sgeinformatica]

Como eu poderia resolver isso?

No caso o ACBrSAT gera um numero de sessão automático quando utiliza o metodo ACBrSAT1.EnviarDadosVenda(ArquivoXml);

Eu posso gravar o numero da sessão na minha tabela utilizando o evento OnGetNumeroSessao

Se houvesse uma falha na aplicação e eu não obtivesse a resposta com o xml autorizado, como eu ainda tenho o numero da sessão, seria possível eu obter esse XML autorizado passando como parâmetro o numero da sessão ?

[Daniel Simoes]

Com o "OnGetNumeroSessao", você pode gerar o seu próprio numero de sessão...

Use o comando "ConsultarSessao", para saber o resultado dela... Se o CFe foi gerado, ele será devolvido a essa consulta, e o ACBrSAT preencherá o ACBrSAT.CFe

[sgeinformatica]

Os 3 arquivos XML estavam na pasta que o ACBrSAT gravou automaticamente.

Deve ter dado algum erro que eu nao sei qual é, o usuario deve ter fechado a aplicacao que faz a autorizacao, e como estava na fila a ser autorizado, então pediu autorizacao novamente.

Mas se minha aplicação for fechada, quando abre novamente e consulta pelo numero da sessao, ela nao existe mais.

Eu poderia dar carga do XML para dentro do meu sistema a partir do XML que fica na pasta que o ACBrSAT gerou.

O arquivo gerado fica com esse nome mais ou menos assim : AD35160160633369000244590000273170243907756934.xml

Antes de eu usar o metodo ACBrSAT1.EnviarDadosVenda(ArquivoXml) tem como eu saber esse nome?

[Daniel Simoes]

No XML (e na chave) existe o numero cNF que você determinou na sua aplicação...

 AD35160160633369000244590000273170243907756934.xml

<cNF>775693</cNF>

Use esse número para saber se o XML é referente a uma venda que você já enviou

[sgeinformatica]

Provavelmente o erro em nossa aplicação deve estar apos usar o método ACBrSAT1.EnviarDadosVenda(ArquivoXml)

Depois do método nós extraímos do XML o nro. do cupom, data e hora de emissão e mais algumas coisas, alem de gravar o XML no banco.

Para evitar esses erros no futuro, logo apos o ACBrSAT1.EnviarDadosVenda(ArquivoXml) vamos gravar um arquivo de log onde vai ter o caminho e nome completo do arquivo XML que o ACBrSAT acabou de salvar. Se acontecer algum erro e a aplicação fechar, quando abrir novamente temos condição e buscar o XML na pasta e subir para o banco.

Mas você comentou sobre a tag cNF, e nós não estávamos utilizando ela.

Olhei no manual e encontrei a seguinte descrição :

Código numérico que compõe a Chave de Acesso. Número aleatório gerado pelo emitente para cada CF-e para evitar acessos indevidos do CF-e.

Você sabe me dizer se eu mandar 2 cupom com o mesmo cNF, o SAT vai recusar o segundo?

[Daniel Simoes]

Humm.. me enganei, o cNF é gerado pelo SAT...

Acho que a sua estratégia é boa... crie um diretório de transações pendentes...e tudo que acabou de ser finalizado, grava lá... quando a aplicação subir, desfaz tudo que estiver lá...

[SisComp - Proc. de Dados]

Bom Dia a todos.

        sgeinformatica estou com o mesmo problema, tanto no SAT da DIMEP como no  Bematech. Você conseguiu alguma solução para esse problema ou tem alguma dica para me ajudar ? 

[sgeinformatica]

Ola Siscomp

Na realidade o problema era na nossa aplicacao. Nos temos uma tabela com a lista dos cupom a serem impressos.

Temos tambem uma aplicacao autonoma que serve apenas para ler essa tabela e autorizar o cupom.

O erro aconteceu logo apos o comando  ACBrSAT1.EnviarDadosVenda(ArquivoXml)

Nesse ponto o cupom ja havia sido autorizado, mas nao gravamos o XML no banco de dados, entao nosso programa autorizou a venda novamente.

Para resolver esse problema criamos um campo para controlar as requisicoes que ja foram feitas ao SAT.

Entao quando isso acontece, ao inves de autorizar o cupom uma segunda vez, o programa vasculha a pasta dos XML e grava no banco de dados.

 

 

[SisComp - Proc. de Dados]

Boa Tarde, sgeinformatica

   Muito obrigado pela atenção. No meu caso não fica gravado o 1º xml na pasta do sistema ou no banco de dados e o aparelho transmiti esse CFe ficando registrado o somente o último CFe transmitido. O que pudemos notar é que quando ocorre o retorno "Sat em processamento. Tente novamente" é que acontece o problema de duplicidade. Antes de enviar o EnviarDadosVenda verificamos se já existe o número de CFe  ou Chave de Acesso para não deixar o Sistema enviar novamente a mesma venda e mesmo assim ocorre o problema. 

 

Editado 14 Março, 2016 por SisComp - Proc. de Dados

[sgeinformatica]

voce esta usando o ACBrMonitorPlus ou vc desenvolveu um autorizador proprio?

[SisComp - Proc. de Dados]

Boa Tarde,

     Aqui utilizamos o autorizador próprio.

[sgeinformatica]

no meu caso o erro foi depois do comando  ACBrSAT1.EnviarDadosVenda(ArquivoXml)

mas o arquivo XML autorizado estava na pasta VENDAS

porque apos esse comando o componente do ACBrSAT já gravou o xml na pasta