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.

Vou testar em separado, aí te falo.

Ítalo, Eu uso o componente configurado para consulta automática. O que demora, sim, é o retorno. E se configurar um tempo menor para a consulta do retorno, ele falha ao trazer o retorno. Acontece tanto em ambiente de homologação quanto de produção.

Disseram que é provedor Awatar https://www.awatar2.net.br/notafiscal/NF/Mobile/Index1.aspx

Já foi implementada a NFS-e para Juazeiro/BA, provedor Awatar?

Leandro, funcionou! Agradeço muito por ter postado sua solução, pois eu estava com problemas em vários clientes. Obrigada!

Italo, funcionou com a sugestão do Leandro Couto, lá do outro tópico. O que eu fiz aqui pra mim e deu certo, pros provedores Thema e ISSNET, na unit ACBrDFeCapicomDelphiSoap, la linha 106, tem uma exception.. eu tirei ela, deixei somente assim. if (UseCertificate) then InternetSetOption(Data, INTERNET_OPTION_CLIENT_CERT_CONTEXT, Pointer(HCertContext), SizeOf(CERT_CONTEXT)); nos arquivo INI, deixei UseCertificado=1 e no componente lib = libCapicomDelphiSoap. Sempre que atualizo os componente, entro nessa unit e modifico... Esta situação não deveria ser tratada?

Por causa desta situação, tenho clientes parados e estou com a arma na cabeça, já. E não faço ideia de como resolver este problema.

Bom dia, Italo! Fiz o teste solicitado, agora retorna "Impossível assinar. Componente configurado para não usar Certificado". Também está configurado: [Assinar] RPS=0 Lote=1 URI=0 Recepcionar=0 ConsSit=0 ConsLote=0 ConsNFSeRps=0 ConsNFSe=0 Cancelar=1 RpsGerar=0 LoteGerar=1 RecSincrono=0 Substituir=0

Estou com o mesmo erro. Inclusive em um executável meu que já funcionava, emitia notas normalmente com o Thema e com o ISSNET, e agora apresenta "Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 12046" no Enviar. Com o provedor Digifred está normal, pois utiliza o método Gerar.

Ao utilizar o método Enviar, está retornando a mensagem: Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 12046 Os fontes estão atualizados e os .ini também. Peguei um executável meu que estava funcionando em cliente (já tinha enviado notas com ele), mas que parou de funcionar também, com o mesmo erro. O provedor em questão é o Thema.