Cristiane - Afirmação

Eu atualizei o trunk2 e começou a dar o mesmo erro... Desinstalei todo o ACBr, limpei, baixei os fontes de novo e continuava o mesmo erro. Fiz isso que o Reginaldo Correa falou e funcionou tudo perfeitamente... Obrigada Reginaldo!

Achei onde é o problema. É no: C:\ACBr\Fontes\ACBrDFe\ACBrDFeCapicomDelphiSoap.pas TDFeCapicomDelphiSoap.OnBeforePost Para resolver a questão da NFS-e, precisa ser retirado o IF desta procedure, senão apresenta o erro "Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 12046". Fazendo isso, resolve o problema da NFS-e, mas acontece o erro na NF-e do crypt32.dll mencionado acima. Se arrumo uma coisa, estrago a outra... Preciso que os dois funcionem... Alguma solução por aí? Consegui resolver! Agora funciona para NF-e e para NFS-e. Entre colchetes tem o código anterior, subtituído pela linha acima. Tem que ficar exatamente assim... Será que dá para inserir esta alteração diretamente nos fontes do ACBR? C:\ACBr\Fontes\ACBrDFe\ACBrDFeCapicomDelphiSoap.pas TDFeCapicomDelphiSoap.OnBeforePost with FpDFeSSL do begin if (UseCertificateHTTP) then begin CertContext := Certificado as ICertContext; CertContext.Get_CertContext(HCertContext); InternetSetOption(Data, INTERNET_OPTION_CLIENT_CERT_CONTEXT, Pointer(HCertContext), SizeOf(CERT_CONTEXT)); { if not InternetSetOption(Data, INTERNET_OPTION_CLIENT_CERT_CONTEXT, Pointer(HCertContext), SizeOf(CERT_CONTEXT)) then raise EACBrDFeException.Create('Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: ' + IntToStr(GetLastError)); } end;

Depois que eu atualizei o ACBR (anteontem), ao fazer ACBrNFe.WebServices.StatusServico.Executar; apresenta a mensagem Access Violation at address 750F062C in module 'crypt32.dll'. Read of address 0000000C. Isto acontece em qualquer computador. Alguém está enfrentando esta situação?

Sim, Ítalo! Pode considerar funcionando o provedor Ábaco.

NFS-e de Rondonópolis/MT, provedor Ábaco, funcionando! Testado e hoje será colocado em produção no cliente.

Vamos soltar foguetes, Ítalo! O tempo reduziu para 8 a 10 segundos! Isto que deixei a primeira consulta com 5 segundos, as outras de 1 em 1... Ótimo!!!

DOCFABIO, A princípio, DNS de nosso provedor não faz sentido, pois Trunk1 funciona com rapidez, utilizando a mesma estrutura.

Ítalo, Depois de tantos testes, voltamos à estaca zero. E volta a velha pergunta: por que no Trunk1 era instantâneo e no Trunk2 leva em média 2 minutos para conseguirmos pegar um retorno?

Testes e mais testes. O problema está no comando Sleep do Delphi??? Debugando vai mais rápido, executando direto demora mais. Dá para melhorar o tempo (um pouco), trocando o intervalo. Eu usava 15 segundos, com 10 repetições, no máximo. Troquei para 1 segundo, com 1000 repetições. Aí ganha no último intervalo. Agora parei os testes.

A lentidão está em unit ACBrNFSeWebServices function TNFSeConsultarSituacaoLoteRPS.Executar: Boolean; Mas realmente não faz sentido demorar tanto.

Se configurar: ACBrNFSe.Configuracoes.Geral.ConsultaLoteAposEnvio := False; O Enviar fica instantâneo. O ACBRNFSe.ConsultarSituacao demora um pouco, mas não tanto quanto antes, quando era junto no comando Enviar (30 segundos ou 1 minuto). Testei mais outras vezes, e em algumas notas chega a levar 2 minutos para retornar o ConsultarSituacao.

Se eu deixar ACBrNFSe.Configuracoes.WebServices.AjustaAguardaConsultaRet := False; e não configurar as outras variáveis, o componente gera uma excessão como se o tempo de consulta fosse extrapolado.

A tela de retorno do protocolo é quase que instantânea. Mas como o componente está configurado para pegar o retorno de lote, até que este seja processado, aí é que fica lento. É tudo em um comando único.

Quando utilizo os comandos ACBRNFSe.ConsultarNfsePorRps ou ACBRNFSe.ConsultarNfsePorRps o retorno é imediato. Ou ACBRNFSe.ConsultarSituacao o retorno é imediato.

Configuração do componente: ACBrNFSe.Configuracoes.WebServices.AjustaAguardaConsultaRet := True; ACBrNFSe.Configuracoes.WebServices.AguardarConsultaRet := 5000;// 5 segundos ACBrNFSe.Configuracoes.WebServices.Tentativas := 10; ACBrNFSe.Configuracoes.WebServices.IntervaloTentativas := 15 * 1000; // 15 segundos Depois uso o ACBRNFSe.Enviar... Em relação ao retorno do protocolo, é instantâneo. Depois vai fazer a consulta, ai demora quase dois minutos para ter o retorno com o status 4. O AguardarConsultaRet não faz diferença, 5 segundos, 10 ou 1. Tentativas, se deixar poucas, corre o risco de não ter retorno. IntervaloTentativas, o padrão é 15 segundos, aí demora... Com 10 tentativas e intervalotentativas 5, retorna como lote não processado. Deixando os 15 segundos sempre processa, mas leva aquele tempão que o povo já está reclamando.