Nfce Timeout

[plenustech]

Bom dia a Todos !!!

Tenho a NFCe implementada e funcionando muito bem no meu Sistema, porém

em alguns casos como em Supermercado temos algumas insatisfações

quanto ao tempo de resposta principalmente quando a SEFAZ ou a Internet

estão com algum problema mais não estão sem serviço totalmente

ou seja o Serviço está muito lento. Neste caso tempo de Resposta é muito demorado

e as vezes me retorna indisponível e eu preciso enviar a NFCe em

contingência. O que eu queria é ter uma forma de diminuir o tempo de

resposta para que eu possa decidir para enviar em contingência.

 

Estou usando o componente com essas configurações.

 

         ACBrNFe1.Configuracoes.WebServices.Tentativas := 1;
         ACBrNFe1.Configuracoes.WebServices.AguardarConsultaRet := 3000;
         ACBrNFe1.Configuracoes.WebServices.AjustaAguardaConsultaRet := False;
         ACBrNFe1.Configuracoes.WebServices.IntervaloTentativas := 0;

 

Mesmo assim as vezes demora quase 1 minuto para o componente me devolver que não conseguiu

enviar em modo normal e eu preciso enviar a NFCe em contingência, isso em um supermercado gera filas enormes

dependendo do movimento. Estou usando a versão 0.5.0a do componente ACBrNFe.

 

Desde já agradeço a todos...

 

[Italo Giurizzato Junior]

Bom dia,

 

O lote a ser enviado contem apenas uma NFC-e?

 

Se sim, você esta setando como envio Síncrono?

 

Se sim, essas configuração não são utilizadas, uma vez que no envio Síncrono o que você tem como resposta da SEFAZ já é o protocolo de autorização.

 

No envio Assíncrono temos como resposta o numero do recibo e depois temos que realizar uma consulta e ai temos como resposta o protocolo de autorização.

 

Resumindo:

 

Síncrono: uma conexão e uma resposta

 

Assíncrono: duas conexões e duas respostas, podendo ocorrer mais, caso ao consultar (segunda conexão) não tivermos resposta de rejeição ou protocolo de autorização.

 

Observação, no modo Síncrono o lote só pode conter apenas uma nota.

 

Se você esta enviando em modo Síncrono, não tem muito o que fazer, ou o problema é com a SEFAZ ou é com a internet do seu cliente.

[plenustech]

Estou enviando em modo Sincrono, e só mando uma Nota.

(ao menos é um fiz  pra ser assim);

 

Ao inciar o envio eu dou um ACBrNFe.NotasFiscais.Clear;

//Carrego os dados de uma nota e envio

ACBrNFe.Enviar(1,False,True); //não imprimir pelo ACBr

//o Número 1 no Lote é apenas para não deixar o campo em branco ou com zero.

Será que estou fazendo da melhor maneira?

Editado 20 Março, 2015 por plenus

[Italo Giurizzato Junior]

Boa tarde,

 

O comando enviar esta correto. Como a SEFAZ no momento não faz uso do numero do lote, você pode enviar todos os lotes como sendo de numero 1.

 

Mas acredito que seria interessante você incrementar o numero do lote e ter registrado no banco de dados que a NFC-e de numero X foi enviada através do lote de numero Y na data Z.

[Dércio Luis Zanatta]

Em 20/03/2015 at 08:01, Italo Jurisato Junior disse:

Bom dia,

 

O lote a ser enviado contem apenas uma NFC-e?

 

Se sim, você esta setando como envio Síncrono?

 

Se sim, essas configuração não são utilizadas, uma vez que no envio Síncrono o que você tem como resposta da SEFAZ já é o protocolo de autorização.

 

No envio Assíncrono temos como resposta o numero do recibo e depois temos que realizar uma consulta e ai temos como resposta o protocolo de autorização.

 

Resumindo:

 

Síncrono: uma conexão e uma resposta

 

Assíncrono: duas conexões e duas respostas, podendo ocorrer mais, caso ao consultar (segunda conexão) não tivermos resposta de rejeição ou protocolo de autorização.

 

Observação, no modo Síncrono o lote só pode conter apenas uma nota.

 

Se você esta enviando em modo Síncrono, não tem muito o que fazer, ou o problema é com a SEFAZ ou é com a internet do seu cliente.

Boa tarde

Também notei esse problema em meus clientes e fiquei na dúvida. Se estou enviando no modo Síncrono, não deveria respeitar o Time Out configurado no componente propriedade "Time Out" e Numero de tentativas ?

[Italo Giurizzato Junior]

Boa noite Dércio,

Se tratando de NFC-e, podemos enviar o Lote no modo Síncrono ou Assíncrono.

No modo Síncrono o Lote só pode conter apenas UMA nota.

Já no modo Assíncrono o Lote pode conter de UMA até 50 notas.

No modo Síncrono o que temos como resposta assim que a nota é enviada é o resultado do seu processamento, ou seja, Autorização de Uso, Rejeição ou Uso Denegado.

Logo nesse modo não existem as consultas para obter o resultado do processamento do Lote.

[Dércio Luis Zanatta]

12 horas atrás, Italo Jurisato Junior disse:

Boa noite Dércio,

Se tratando de NFC-e, podemos enviar o Lote no modo Síncrono ou Assíncrono.

No modo Síncrono o Lote só pode conter apenas UMA nota.

Já no modo Assíncrono o Lote pode conter de UMA até 50 notas.

No modo Síncrono o que temos como resposta assim que a nota é enviada é o resultado do seu processamento, ou seja, Autorização de Uso, Rejeição ou Uso Denegado.

Logo nesse modo não existem as consultas para obter o resultado do processamento do Lote.

Certo, então nesse caso não tem como controlar um TimeOut ?

Ta bem complicado isso, pois o cliente é um supermercado. A Internet está muito estável, não ha problemas de conexão e mesmo assim, aleatoriamente demora 30, 40, em alguns casos até passa de minutos para retornar o erro. Não teria uma forma de controlar esse tempo ? 

 

[Dércio Luis Zanatta]

Tenho um caso aqui de uma NFCe que demorou 45 seg para retornar a resposta e retornou o erro interno 10060 HTTP:0. Entrei em contato com a SEFAZ e passei os dados da Nota. A nota está autorizada la e, segundo eles, demorou 4 sentésimos de segundo para autorizar.

Através disso da para concluir que o problema não deve estar no envio e sim na leitura do retorno da SEFAZ. A conexão com a internet do cliente é via Fibra e está super estável.  O que poderia estar causando essa demora toda, sendo que nota foi autorizada e retornou esse erro de conexão ?

 

[Juliomar Marchetti]

Bom dia!

olha só algumas coisas que pensei, windows e o defender interferindo ou o tal smatscreen, ou um antivirus ou ainda assim até mesmo o windows querendo bloquear o que é feito por sua aplicação por ela não ser confiável a ele!

ou um módulo de banco rodando e que faz com que congele algo da sua aplicação

ou ainda algo que esteja implementado na validação e tratamentos dentro de seu código que posso desconhecer!

uma boa era pegar o demo e tentar fazer testes com ele e ver se ocorre o mesmo!

[Dércio Luis Zanatta]

18 minutos atrás, Juliomar Marchetti disse:

Bom dia!

olha só algumas coisas que pensei, windows e o defender interferindo ou o tal smatscreen, ou um antivirus ou ainda assim até mesmo o windows querendo bloquear o que é feito por sua aplicação por ela não ser confiável a ele!

ou um módulo de banco rodando e que faz com que congele algo da sua aplicação

ou ainda algo que esteja implementado na validação e tratamentos dentro de seu código que posso desconhecer!

uma boa era pegar o demo e tentar fazer testes com ele e ver se ocorre o mesmo!

Bom dia Juliomar.

Na verdade já verifiquei tudo isso antes..  As máquinas estão sem nenhum anti-vírus, a demora ocorre mesmo quando chama o ACBRNFe1.Enviar (verifiquei isso através da gravação de logs)

Dificelmente vou conseguir chegar nessa situação pelo Demo, pois não ocorre sempre, ocorre aleatóriamente sem nenhuma lógica. Ocorre inclusive em conexões muito estáveis onde não teria muita chance de dar esses problemas de conexão. 

e tem mais..

Essas notas que ocorrem esse problema estão autorizadas no site da SEFAZ. Entrei em contato com o suporte da SEFAZ-RS e eles me passaram uma lista de todos os cupons feitos por esse emitente durante um dia todo. Todos autorizados em menos de 1 seg.

A impressão que da é que o WS está respondendo, mas o componente não está identificando essa resposta.

 

 

[Daniel Simoes]

Prezados,

O problema é no SEFAZ... não há como o componente se comportar de duas maneiras diferentes, se os mesmos comandos são enviados... (isso é logica de programação)

O problema ocorre, porque o Servidor está no ar... mas o WebService não... e com isso o Windows demora a dar o TimeOut

O mesmo assunto está sento tratado nesse post:

 

Em 08/11/2016 at 15:53, Dércio Luis Zanatta disse:

Tenho um caso aqui de uma NFCe que demorou 45 seg para retornar a resposta e retornou o erro interno 10060 HTTP:0. Entrei em contato com a SEFAZ e passei os dados da Nota. A nota está autorizada la e, segundo eles, demorou 4 sentésimos de segundo para autorizar.

Através disso da para concluir que o problema não deve estar no envio e sim na leitura do retorno da SEFAZ. A conexão com a internet do cliente é via Fibra e está super estável.  O que poderia estar causando essa demora toda, sendo que nota foi autorizada e retornou esse erro de conexão ?

 

Isso não é verdade...  uma vez o XML recebido pelo SEFAZ ele será processado em um supercomputador... (isso é rápido)

Mas o WebService em modo Sincrono, não para por ai... ele precisa lhe devolver a resposta do processamento... e é esse o problema no SEFAZ, ele não está lhe entregando a resposta

 

[Dércio Luis Zanatta]

26 minutos atrás, Daniel Simoes disse:

Prezados,

O problema é no SEFAZ... não há como o componente se comportar de duas maneiras diferentes, se os mesmos comandos são enviados... (isso é logica de programação)

O problema ocorre, porque o Servidor está no ar... mas o WebService não... e com isso o Windows demora a dar o TimeOut

O mesmo assunto está sento tratado nesse post:

 

Isso não é verdade...  uma vez o XML recebido pelo SEFAZ ele será processado em um supercomputador... (isso é rápido)

Mas o WebService em modo Sincrono, não para por ai... ele precisa lhe devolver a resposta do processamento... e é esse o problema no SEFAZ, ele não está lhe entregando a resposta

 

Só para constar.. A resposta do pessoal da SEFAZ:

A figura abaixo é do sistema interno da SEFAZ, e mostra as NFC-es provenientes da empresa com CNPJ 95.821.310/0012-36, que foram transmitidas na manhã do dia 08/11.

 

A seta indica a transmissão referente à NFC-e que vocês informaram, com chave de acesso 43161195821310001236650150000147029000147027.

 

A última coluna, mas à direita, mostra o tempo de processamento dessa nota na SEFAZ. Vocês podem ver, no local indicado, que o tempo de processamento dessa nota foi de 4 centésimos de segundo.

 

 

 

 

Portanto, nós não sabemos dizer qual é a causa da demora que está acontecendo. O que podemos dizer com certeza é que a causa da demora não é o tempo de processamento na SEFAZ.

 

Talvez a demora esteja relacionada com o log da empresa, ou com o processo de transmissão pela internet. Sugiro contatar o responsável pelo sistema da empresa, para verificar a questão.

 

 

 

 

 

 

 Esse assunto está mesmo sendo tratado em outro tópico, pelo que entendi é um problema no windows que não permite controlar o TimeOut. Apenas anexei a resposta aqui para constar mesmo.

Me desculpem se estou insistindo no assunto, mas é que esse problema está causando enormes transtornos no cliente, provocando demora no atendimento e filas que gera insatisfação dos consumidores.

 

 

Eduardo S. Benazzi

Auditor Fiscal da Receita do Estado

Equipe da NF-e

Receita Estadual – RS

Editado 10 Novembro, 2016 por Dércio Luis Zanatta

[Daniel Simoes]

Para uma resposta mais apurada do SEFAZ, seria necessário, um log de cada etapa, desde a chagada do XML enviado ao SEFAZ, até a devolução do XML de resposta por parte do SEFAZ...

[Dércio Luis Zanatta]

1 hora atrás, Daniel Simoes disse:

Para uma resposta mais apurada do SEFAZ, seria necessário, um log de cada etapa, desde a chagada do XML enviado ao SEFAZ, até a devolução do XML de resposta por parte do SEFAZ...

Daniel Simões.  Uma informação importante, acredito eu...

Eu atualizei os fontes do ACBR em 02/09/2016.  Antes disso, tinha os fontes de 06/01/2016.

Um cliente meu onde não tinha atualizado o sistema compilado com esses fontes do dia 02/09/2016, esse erro Interno: 10060 não ocorria. Acabei atualizar nesse cliente e o problema começo a ocorrer. Infelizmente não posso voltar os fontes do dia 06/01/2016 pro causa das alterações que foram feitas na DANFE que entraram em vigor no dia 01/10/2016.

Acredito que tenha alguma coisa a ver, pois é muita coincidência o erro passar a ocorrer exatamente depois de atualizar os fontes do ACBR.

Teria como ver se foi feita alguma alteração pertinente a envio Sícrnono usando OPENSSL depois de Janeiro de 2016. Talvez surja alguma idéia para resolver o problema.

 

 

 

[André Ferreira de Moraes]

Vc tem o sistema compilado com os fontes de 06/01? Com ele o problema nunca ocorre?

[Daniel Simoes]

Não creio ser algo nos fontes, pelos seguintes motivos:

- essas units não tem modificações a tempo

- o problema não ocorre com outros usuários do ACBR 

 

[Dércio Luis Zanatta]

13 minutos atrás, André Ferreira de Moraes disse:

Vc tem o sistema compilado com os fontes de 06/01? Com ele o problema nunca ocorre?

Acabei de confirmar.. É isso mesmo.. Nenhuma ocorrência do erro do dia 06/01/2016 até ontem . Hoje atualizei o executável compilado com os fontes do dia 02/09/2016 e já tem duas ocorrências.

Vou verificar em outro cliente agora...  Já posto o resultado.

 

Editado 10 Novembro, 2016 por Dércio Luis Zanatta

[Daniel Simoes]

A idéia sugerida pelo Andre... é testar em produção, com o executável antigo, hoje... ė isso que foi feito ?

[Dércio Luis Zanatta]

7 minutos atrás, Daniel Simoes disse:

A idéia sugerida pelo Andre... é testar em produção, com o executável antigo, hoje... ė isso que foi feito ?

Sim.. Já fiz isso..  Voltei o executável antigo e problema não ocorre mais...  Já confirmei isso em outro cliente também.

O problema somente ocorre se compilar com os fontes do ACBR atualizados no dia 02/09/2016.

[André Ferreira de Moraes]

Como vc chega a conclusão tão rapidamente q o executável antigo não dá problema sendo q com o executável novo só ocorreu 2 vezes hoje?

[Dércio Luis Zanatta]

1 minuto atrás, André Ferreira de Moraes disse:

Como vc chega a conclusão tão rapidamente q o executável antigo não dá problema sendo q com o executável novo só ocorreu 2 vezes hoje?

Chego a essa conclusão, pois foi atualizado somente em uma filial, nas outras está o dia todo com o executável antigo e não tem nenhuma ocorrência

 

[André Ferreira de Moraes]

Vc precisa testar na mesma máquina para ter certeza.

[Dércio Luis Zanatta]

3 minutos atrás, André Ferreira de Moraes disse:

Vc precisa testar na mesma máquina para ter certeza.

Ok. Vou fazer isso

 

[Dércio Luis Zanatta]

40 Min rodando com o executável antigo = Nenhuma ocorrência do erro

10 Min rodando com o executável novo = 3 ocorrências

 

[André Ferreira de Moraes]

Vc tem dois terminais? Deixe um rodando com o executável novo e outro com o antigo e anexe todos os logs gerados pelos dois com o horário em q o problema ocorre.