Dércio Luis Zanatta

Mais um log... Nesse caso demorou 58 seg para retornar a mensagem Erro interno 10091 HTTP:500 NFCe: 31783 11112016.txt

Segue log de outro terminal... nesse deu o erro interno 10060 HTTP:0 NFce: 17775 11112016.txt

Segue log gerado no cliente Veja que tem vários cupons autorizados normamente e na sequencia tem um erro interno. O Erro ocorreu na NFCe de número 31783 Aguardo.. 11112016.txt

Implentei o log e fiz um teste aqui em homologação. Veja em anexo se é disso que vc precisa. 11112016.txt

Desculpe.. Não uso o ACBRMonitor, por isso não tenhos os fontes do mesmo, mas seria apenas implementar exatamente como vc exemplificou acima ?

Desculpe.. Não tenho nada programado nesse Evento.. Vou estudar no Demo como Faz e vou implementar.. Verifiquei que no Demo Também não tem nada nesse Evento.. Vc poderia me explicar ou exemplificar como deve ser implementado nesse evento ?

Onde fica gravado esse log ? Qual o nome do arquivo ?

Anexo os xmls emitidos no cliente ontem em um terminal. A nota 19800 ocorreu o problema do Erro interno 10060 HTTP:0 Não consegui anexar todos os arquivos ultrapassa 2MB, mesmo compactado. Caso precisar de mais alguma coisa, estou a disposição. 19800-env-lot.xml 19800-env-lot-soap.xml 19801-env-lot.xml 19801-env-lot-soap.xml 19801-pro-lot-soap.xml

Não consegui copiar os arquivos do cliente, mas o problema ocorreu aqui em homologação tb.. Segue anexo os arquivos da NFCe que ocorreu o problema. Nesse caso, demorou 26 seg para retornar o erro.. Não tem os arquivos pro_lot, apenas os env-lot. Acredito eu que é pq deu o erro e não recebeu o retorno da SEFAZ. Amanhã vou ver se consigo alguns arquivos dos clientes ai posto aqui.. 568-env-lot.xml 568-env-lot-soap.xml 43161195821310000183650110000005681000005680-nfe.xml

Tira uma dúvida... Fui copiar os arquivos agora e notei que essa pasta está enorme.. com um monte de arquivos, pois vem salvando tudo a muito tempo. Isso não poderia estar causando a lentidão, ou seja... Não pode estar demorando para gravar os arquivos de retorno na pasta ?

Só para confirmar.. Para configurar o componente a salvar todos os arquivos, faço assim ? ACBrNFe1.Configuracoes.Geral.Salvar := True ; ACBrNFe1.Configuracoes.Arquivos.Salvar:=True ; ACBrNFe1.Configuracoes.WebServices.Salvar:=true ;

Nesse cliente, tem somente um terminal por filial.. São postos de combustível.. O que posso fazer é mandar os logs de uma filial que está usando o executável antigo e outra que está usando o executável novo... Que arquivos vc precisa exatamente ?

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

Ok. Vou fazer isso

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

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.

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.

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.

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

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.

Bom dia. É mesmo uma "sinuca de bico", pois o problema está causando grandes transtornos em supermercados. Mesmo com Internet estável, via Fibra, sem nenhuma perda de sinal, ocorrem vários envios que demoram cerca de um minuto para retornar o erro interno 100600 HTTP:0 O pior é que a nota fica autorizada na SEFAZ e eu tenho que emitir em contingência off line por receber essa mensagem de erro ! Sendo assim, as chaves ficam diferentes e tem que ser feitos vários tratamentos para reennviar essa nota depois.

Olá amigo.. Eu não uso o ACBRMonitor, uso o componente ACBRNFe1 no Delphi e estou enfrentando um problema parecido com o seu. No meu caso não é em todas as Notas, mas aleatóriamente em algumas. Estou tratando desse assunto com o Daniel, mas a solução parece que vai demorar um pouco para sair...

Será que seria possível incrementar isso na própria função Acbrnfe.enviar do componente ? Peso que seria bem interessante poder ter controle de TimeOut direto na função.

Ola Daniel. Me desculpe a ignorância, mas não conheço essa de usar Thread.. Vc pode exemplificar como seria para controlar o timeout da função AcbrNfe1.Enviar ?

Bom dia Tenho esse problema em vários clientes. Até acredito que seja um problema de conexão, mas o maior problema é o tempo que demora para retornar o erro de conexão. Tenho casos que demora mais de 1 min ! Isso causa muitos transtornos em supermercados, pois as filas se acumulam em dias de muito movimento. O ideal seria se pudesse configurar esse Time Out. Ex: Aguarda no máximo 10 seg e já retorna o erro de conexão !