Leandro Araújo

Olá... Gostaria apenas de informar que obtive um erro de AccessViolation ao realizar a consulta de NF-e/NFC-e quando utilizo a 'libCapicomDelphiSoap'. Aqui no Delphi o erro acontece na unit 'ACBrDFeCapicomDelphiSoap.pas', nas linhas 98-102: if (FpDFeSSL.UseCertificate) then begin CertContext := Certificado as ICertContext; CertContext.Get_CertContext(HCertContext); end; A propriedade Certificado (FCertificado) fica como 'nil'. Trocando para 'libCapicom' o erro não ocorre. Apenas reportando que tive esse problema, não encontrei uma solução programável, não sei se muitos utilizam a biblioteca com os componentes SOAP do Delphi. Obrigado.

Clientes com conexão ruim acontece com o mesmo código '10060', fora isso, não houve mais relato desse erro, se houve pelo menos foi com uma frequência muito baixa mesmo. Obrigado.

@Italo Jurisato Junior, apenas para fins de feedback, gostaria de dizer que a alteração a respeito da limpeza dos retornos dos webservices funcionaram perfeitamente, agora não tenho mais riscos de pegar o retorno/cStat de um envio anterior, paramos de ter erros com "falso positivo" de nota autorizada/rejeição. Muito obrigado.

Então @Daniel Simoes, atualizamos novamente as DLLs com as que vem no trunk2, e verificamos que tinha mais um componente com a opção 'Verificar Validade' marcada, dessa vez era um componente de NFS-e, desmarcamos e o erro parou de ocorrer, em raras vezes ocorre mas em clientes que possuem uma internet péssima. Com relação ao crash da tela branca utilizando Capicom em Windows Server 2008: Esse erro acontecia no trunk1, debugando conforme está no post citado acontecia o erro. Não tivemos mais ocorrências, é um episódio antigo, e pelo visto já foi sanado. Desculpem qualquer equívoco. Obrigado.

Sim, está desabilitado. Obrigado.

Boa tarde. Sim, é A1, e estamos utilizando com OpenSSL, e este erro HTTP está ocorrendo. Muitos de nossos clientes utilizam a aplicação via acesso remoto, rodando no Windows Server 2008, o motivo de utilizarmos OpenSSL nesse caso é um antigo problema de "crashes" (telas brancas) com o nosso aplicativo na versão Capicom nesse sistema operacional. Veja o tópico: http://www.projetoacbr.com.br/forum/topic/11467-msxml5dll-windows-x64/?do=findComment&comment=112857 Porém não sei se o mesmo já foi corrigido. Os nossos únicos clientes que utilizam Capicom são os que possuem certificados A3 mesmo, os quais OpenSSL não suporta. Observei esse erro HTTP após migrar para o trunk2, já tentei trocar a dll 'ssleay32' e aumentar os timeouts, mas não resolveu. Observação: O erro ocorre com pouca frequência em ambiente de homologação, porém em produção é notável. Obrigado.

Voltei as DLLs da versão '0.9.8.14', mas o erro interno 10060 Erro HTTP: 0 persiste em mais de um cliente. Já foram alteradas configurações de timeout e nada.

Experimentei trocar a dll 'ssleay32' da versão '0.9.8.14' para a versão '1.0.2.1', mas sem sucesso, porém o erro mudou para 'Erro interno: 10091 Erro HTTP: 500'.

Alguém já conseguiu resolver esse erro, sem ter que fazer alguma alteração? Obrigado.

Nunca vi, mas fiquei curioso a respeito. Tem a ver com esse link? https://www.oasis-open.org

Apenas uma sugestão, o projeto ACBr tem nos ajudado muito. Obrigado pela atenção.

Resolvi alterando a unit 'ACBrNFeWebServices.pas', incluindo um método '.Clear' para a classe 'TNFeRecepcao'. procedure TNFeRecepcao.Clear; begin Self.FLote := EmptyStr; Self.FRecibo := EmptyStr; // FNotasFiscais: TNotasFiscais; // Fversao: String; // FTpAmb: TpcnTipoAmbiente; // FverAplic: String; Self.FcStat := 0; // FcUF: integer; Self.FxMotivo := EmptyStr; Self.FdhRecbto := 0; // FTMed: integer; // FSincrono: Boolean; end; Dai antes de qualquer envio eu limpo para evitar algum engano no meu bloco except. // Limpando cStat, dhRecbto, xMotivo etc. ACBrNFe1.WebServices.Enviar.Clear; // ... ACBrNFe1.Enviar(FLote, FImprimir, FSincrono); ACBrNFe1.NotasFiscais.Items[0].GravarXML; //.... // No except: on E: EACBrDFeException do begin FCStat := ACBrNFe1.WebServices.Enviar.cStat; if FCStat <> 0 then begin // Aqui o cStat é tratado em 'ProcessarAposSucessoEnvioNFe'. end else begin // Algum outro erro (Falha de comunicação etc). 'ProcessarAposErroEnvioNFe'. end; end; O que acontece é que após um envio/consulta com sucesso (100), e ao se realizar outro envio/consulta e ocorrer um erro de comunicação por exemplo, ainda está setada a informação do cStat como 100 nos retornos do WebService, no caso apenas estou limpando esses valores, isso também para rejeições, as quais agora o componente lança uma exception e nos tratamentos de excessões pegamos o cStat da rejeição. Para mim esse procedimento foi necessário, pois utilizo o componente de NF-e em um DataModule, ou seja, o componente só é de fato "zerado" quando encerro a aplicação. Vai em anexo a unit 'ACBrNFeWebServices', com um pequeno teste, na linha 1218. Não sei, mas talvez seja necessário fazer para os outros webservices. Muito obrigado. ACBrNFeWebServices.pas Obrigado pela oportunidade Italo, teve um colega, o Waldir Paim, que fez uma alteração dessas também, apenas mandei o modo com que resolvi aqui no meu caso.

Também estou com o mesmo pensamento, e fui ver que algumas propriedades são read only. Seria possível o pessoal do ACBr criar um método '.Clear', algo assim, para não ter necessidade de darmos merge com nossas alterações "próprias"? ACBrNFe.WebServices.Enviar.Clear; ACBrNFe.WebServices.Clear; Muito obrigado.

Realmente, esse erro parece ser de tempo limite estourado. Verifiquei a seguinte descrição no arquivo '...\ACBr\Fontes\Terceiros\synalist\blcksock.pas' na linha 3209-3210 que é um erro de timeout. WSAETIMEDOUT: {10060} Result := 'Connection timed out'; Vou experimentar aumentar ainda mais os intervalos entre as tentativas para ver o que acontece. Obrigado.

Desculpe Daniel, é que acabei digitando o inicio do post e postei. Não se repetirá. Obrigado. Corrigindo: Erro Interno: 10060 Erro HTTP: 0

Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL. Também estamos com o mesmo problema aqui na empresa, no caso utilizando OpenSSL.* O problema que ocorre é que ao efetuar o envio de um lote, ocorre o erro: 'Erro Interno: 11001 Erro HTTP: 500'. Porém ao efetuar uma consulta recebo o retorno da nota autorizada, em alguns casos tenho que fazer mais uma requisição de consulta, pois o mesmo erro as vezes ocorre na consulta e em outros webservices. É como se algo estivesse bloqueado e dai quando faz mais um requisição desbloqueia. Fizemos semana passada a migração para o trunk2 do ACBr, deixando as mesmas configurações de webservice, timeout etc, não sei se tem a ver, porque clientes nossos que possuem o aplicativo compilado com o 'ACBr1' relataram o mesmo problema, então creio que não seja algo diretamente relacionado ao componente, porém esse erro não está nos afetando tanto pois o sistema possui um mecanismo para permitir gerar novamente uma nota somente se a mesma não foi de fato autorizada, enquanto isso o usuário só pode realizar a consulta, não fazer alterações entre outras coisas. Vamos realizar testes com Capicom também. Obrigado.

Também estamos com o meso problema aqui na empresa, no caso utilizando OpenSSL.

Fico feliz em ter ajudado. Obrigado.

Realizamos algumas mudanças e deixamos essa configuração apenas para quando ambiente estiver crítico...

O que fazemos no nosso sistema é que quando o mesmo está configurado para envio Assíncrono (Geralmente deixamos Assíncrono para NF-e, mesmo que seja 1 nota apenas, e Síncrono para NFC-e). No caso da NF-e, se estiver no assíncrono, nas rotinas de processamento a thread dá uma "dormida" por cerca de 2,5 segundos (esse tempo está exagerado... haha) e depois sim consulta o recibo, fizemos assim visando prevenir caso o processamento do 'lado servidor' não seja concluído a tempo e dar também uma "folga" no tempo de consulta do sistema. Qual a opinião de vocês? Obrigado pessoal...

Aproveitando o embalo do tópico... Com todo esse pessoal que estava na versão 2.00 da NF-e e mudaram repentinamente para a 3.10 (Sei que tem gente que mudou gradualmente), tem alguma implicação em enviar a NF-e somente no modo Síncrono ou seria melhor eu enviar no modo Assíncrono e dar um 'timeout/sleep' para minha rotina consultar o recibo, visto que os ambientes das Sefaz podem vir a sobrecarregar por esses dias.. ou não há necessidade disso? Obrigado.

Já utilizando o componente aqui. Parabéns... Obrigado.

Olá, boa tarde. Com relação ao meu problema de não conseguir imprimir corretamente e também da impressora saltar 4 etiquetas, o motivo foi de que faltava calibrar o sensor GAP. Abri o DiagTool, depois no grupo 'Printer Function' cliquei no botão 'Calibrate Sensor', vai abrir uma janela com a opções de calibração, selecionei a opção GAP em 'Media Type', depois no grupo 'Auto Calibration' cliquei em 'Calibrate'. A impressora puxou um pouco as etiquetas para dentro depois voltou, depois disso consegui imprimir corretamente. Fica a dica caso alguém esteja com problema de salto e impressão desconfigurada, experimente fazer a calibração do sensor, as vezes nossa pressa de não consultar o manual né... Obs.: Para mim não houve necessidade de atualizar o firmware. Obrigado a todos.

Entendido. Farei mais testes. Obrigado.

Olá Daniel, então, fiz uma restauração dos padrões de fábrica por um aplicativo disponibilizado pela própria Bematech. Estou em dúvidas, porque aqui quando estávamos com uma Zebra, informamos da propriedade 'Unidade' do componente o valor 'etqMilimetros', porém por esse aplicativo, quando peço para ele ler a configuração da impressora Bematech traz como polegadas, dai mesmo informando como 'etqPolegadas' no componente ACBrEtq ainda apresenta um comportamento peculiar.