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
-
-
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. -
Estou com o mesmo problema na Thema, que utiliza o método Enviar.
Está assinando o RPS corretamente, mas apresenta o erro:
Erro ao ajustar INTERNET_OPTION_CLIENT_CERT_CONTEXT: 12046ACBrDFeCapicomDelphiSoap.pas
TDFeCapicomDelphiSoap.OnBeforePost
na linha 107 ele causa a excessão.
Agora não sai mais nota alguma, não faz mais nada.
Nota: acabei de atualizar todos os fontes.
-
Ontem eu resolvi atualizar a minha pasta ACBR. Cheguei a excluir todos os arquivos, baixei de novo e compilei tudo de novo.
Está apresentando erro de compilação no
ACBREad.pas
procedure TACBrEAD.LerChaveModuloExpoente(Modulo, Expoente: AnsiString);
Na linha 496:
RSAKey.e := bnMod;
RSAKey.d := bnExp;O que precisa ser feito?
-
Agora sim! Ibirubá/RS, pela Digifred, funcionando.
Segunda-feira vai para produção.
-
1
-
-
Ainda referente a Ibirubá - Digifred:
Usei o método Gerar. Tudo certo, retornou a mensagem em tela com situação 4.
Neste momento preciso dos retornos.
ACBrNFSe.NotasFiscais.Items[0].NFSe.Situacao está branco.
Protoco é 0
CodigoVerificacao está preenchido
Numero vem com 201600000000354 (exemplo, grande este número, é isso mesmo?)
NomeArq vem preenchido e gerou o XML
Aí tentei utilizar o método ConsultarLoteRps, mas não faz sentido, pois não gerou um lote.
Como faço para pegar a situação? Quando utilizamos Gerar, as respostas vem em outros campos?
Só falta isso para eu conseguir implementar Digifred no meu sistema.
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!