Cristiane - Afirmação
-
Total de ítens
73 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por Cristiane - Afirmação
-
-
Achei onde é o problema. É no:
C:\ACBr\Fontes\ACBrDFe\ACBrDFeCapicomDelphiSoap.pas
TDFeCapicomDelphiSoap.OnBeforePostPara 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?-
1
-
-
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.ConsultarNfsePorRpso 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 oACBRNFSe.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
-
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!
-
1
-
-
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?
-
1
-
-
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.
erro na unit ACBrDFeOpenSSL
em Dúvidas Gerais sobre o ACBr
Postado
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!