Ir para conteúdo
  • Cadastre-se

dev botao

  • Este tópico foi criado há 1680 dias atrás.
  • Talvez seja melhor você criar um NOVO TÓPICO do que postar uma resposta aqui.

Recommended Posts

Postado

Boa noite, Esta acontecendo uma situação em um cliente que não sei mais o que verificar, e gostaria de ajuda para tenta entender e localizar o problema, que é:

- Venda 1, com valor de R$1,00 aprovada as 08h

- Venda 2, com valor de R$2,00 aprovada as 08:02h

- venda 3, com valor de R$3,00 aprovada as 08:03h

 

aqui começa o problema, porque aparece na sefaz esporadicamente que a venda 2 no valor de R$2,00 foi transmitida várias vezes, sendo que meu pdv enviou apenas 1 unica vez.

Na sefaz consta a venda 2, porém consta venda 10, venda 15, venda 20 e etc todas com os mesmos itens, com o mesmo valor, porém com chaves diferentes, protocolos de aprovação diferentes, numero de cupons diferentes...porém meu pdv mandou apenas 1 vez essa venda.

coloquei log antes de chamar o metodo enviar para poder registrar todas os xmls que são transmitidos e nao foi registrado a transmissao dessas outras vendas.

Solicitei ao cliente que formatasse a maquina onde o pdv esta rodando, supondo que poderia ser alguma aplicação que estivesse pegando o xml enviado indevidamente, mas 

mesmo assim, continua acontecendo de forma esporádica o problema. Na pasta de backup dos xmls nao consta esses xmls indevidos.

o que me intriga mais é que os dados da venda são os mesmos, porem numero, chave, protocolo e horario de envio são diferentes.

Um detalhe importante que notei é que dessas vendas indevidas, o horário de autorização são bem proximos, tipo, de 2 a 5 segundos a diferença entre eles, e que a hora da autorização é anterior a hora de emissão.

 

image.png.2b901f5ea4fe74435348187b6f0fc6e9.png

 

essa é a unica prova que algo está bem estranho nesse cliente, e somente nesse. Alguem tem uma ideia do que possa ser, ou alguma sugestão a ser verificada?

 

  • Consultores
Postado

Bom dia,

Quanto ao horário de emissão em relação ao de autorização, se não me falha a memória existe uma tolerância de 5 minutos.

Neste caso o relógio do computador esta adiantado em 10 segundos em relação ao do servidor do webservice, portanto esta dentro da tolerância de 5 minutos.

A sua aplicação não tem nenhuma rotina que dispara automaticamente o envio da nota com outro numero caso o envio anterior não tenha sido realizado com sucesso?

Com certeza após o envio e obter o protocolo de autorização a sua aplicação atualiza o registro dessa nota no banco de dados como enviada e protocolada.

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

  • Fundadores
Postado

Eu não creio que seja um erro de duplicação, no SEFAZ... (nunca soube de um erro dessa natureza, do lado deles)

Algumas teorias...

  • O cliente não tem mesma máquina, algum serviço de "mensageria",  ou algo semelhante, que pudesse fazer o envio dos XMLs sem que o seu sistema, tenha conhecimento ?
  • O Cliente não usa nenhum outro programa emissor ?
  • Não poderiam ser testes do Suporte ?
Consultor SAC ACBr

Daniel Simões de Almeida
O melhor TEF, é com o Projeto ACBr - Clique e Conheça
Ajude o Projeto ACBr crescer - Assine o SAC

Projeto ACBr     Telefone:(15) 2105-0750 WhatsApp(15)99790-2976.

Postado
5 horas atrás, Italo Jurisato Junior disse:

Bom dia,

Quanto ao horário de emissão em relação ao de autorização, se não me falha a memória existe uma tolerância de 5 minutos.

Neste caso o relógio do computador esta adiantado em 10 segundos em relação ao do servidor do webservice, portanto esta dentro da tolerância de 5 minutos.

A sua aplicação não tem nenhuma rotina que dispara automaticamente o envio da nota com outro numero caso o envio anterior não tenha sido realizado com sucesso?

Com certeza após o envio e obter o protocolo de autorização a sua aplicação atualiza o registro dessa nota no banco de dados como enviada e protocolada.

Boa tarde,

Nossa aplicação nao tem outro fluxo de envio fora o da venda, e mesmo assim coloquei logs para capturar todos os dados antes do envio pelo componente, e nao consta nada dessa numerações. Nas pasta de logs e xmls de retorno que configuramos no componente nao tem nenhum registro dessas vendas, e da mesma forma no banco esses registros nao existem. Não sei mais o que pensar porque conectei na maquina pra me certificar q nao existe um programa  fazendo esse envio.

  • Solution
Postado
1 hora atrás, Daniel Simoes disse:

Eu não creio que seja um erro de duplicação, no SEFAZ... (nunca soube de um erro dessa natureza, do lado deles)

Algumas teorias...

  • O cliente não tem mesma máquina, algum serviço de "mensageria",  ou algo semelhante, que pudesse fazer o envio dos XMLs sem que o seu sistema, tenha conhecimento ?
  • O Cliente não usa nenhum outro programa emissor ?
  • Não poderiam ser testes do Suporte ?

Boa tarde, na sefaz consta todas essas vendas, vi em uma pagina q o cliente tem acesso. Coloquei uma informação no xml para que fosse identificado quando o envio fosse pela minha aplicação, e todos os cupons indevidos constam essa informação, mas por mais q parece ser um problema da aplicação já garanti  por logs de todos as maneiras que nao foi um envio pelo fluxo de vendas. O que me chama atenção é que muitos desses envios pelo horario  da recepção deles na sefaz, o aplicação estava parada, nao estava sendo utilizada...vejo isso pelos logs dela, e o intervalo e envio desse casos indevidos é de 2 a 5 segundos, e no ultimo caso q analisamos o registro de uma venda esta la na sefaz 60 vezes em um intervalo entre eles de poucos segundos. O fato dessas vendas indevidas ser a mesma e so mudar o numero do cupom e a chave me faz pensar que nao seria alguem do suporte, pois teria q ficar editando o xml, enfim. Gerei uma versao onde nao vou salvar o arquivos de backup, pra ter certeza q não tem algum processo ou programa ou pessoa capturando esses arquivos e enviando. Ate sexta devo ter uma retorno se mudou algo. 

  • Curtir 4
×
×
  • 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.