Valdir Dill

Boa tarde, Estou anexando o AcbrNFeServicos.ini da forma com que tem que ficar para não dar esse erro. Se o responsável puder analisar e subir para o repositório...Aí resolve para todos que estão com esse problema com impressão da NFCe no PI. Obrigado! ACBrNFeServicos.ini

Boa tarde, Pelo que entendi, eu posso tanto enviar o arquivo AcbrNFeServicos.ini para o cliente e setar a propriedade ACBrNFe1.Configuracoes.Arquivos.IniServicos, como colocar a diretiva {$R 'ACBrNFeServicos.res' 'ACBrNFeServicos.rc'} no meu sistema. Ambos vão funcionar da mesma forma, certo? Uma dúvida: há alguma forma melhor de fazer isso, ou seja, é mais recomendável a diretiva ou enviar o arquivo junto na instalação? Quais os contras de um e de outro? Obrigado!

Obrigado. Mas me diga uma coisa, você usa essa opção de consulta do CPF do Acbr? Para você está funcionando beleza?

Duas informações adicionais que esqueci: - A consulta de CNPJ está tudo certo funciona tudo beleza; - Se eu colocar a URL - https://www.receita.fazenda.gov.br/Aplicacoes/SSL/ATCTA/CPF/ConsultaSituacao/captcha/gerarCaptcha.asp - do capctcha no browser, ele traz a imagem corretamente na tela do navegador. Obrigado!

Boa tarde, Há alguns dias começou a ocorrer um erro (print anexo) na consulta de CPF. O problema ocorre na atualização do captcha. Pensei que fosse problema na receita, mas como faz alguns dias já... Vi um post que poderia ser problema nas libeay32.dll e ssleay32.dll, mas copiei elas tanto para aplicação como para pasta system do Windows, sem resultados. Fiz um teste no demo do Acbr e o mesmo problema acontece. Alguma dica? Obriggado!

Bom dia, Obrigado Daniel, mas eu já havia lido esse tópico pelo menos umas 5 vezes, hehe! Mas agora com mais essa sua explicação acredito que estou começando a entender. O que eu estava fazendo era utilizar a opção 2 (abaixo), mas copiando todos os arquivos de \Acbr\DLLs\XMLSec\ E \Acbr\DLLs\XMLSec\MinGW\32. Por favor, veja se agora eu entendi corretamentos os procedimentos Opção 1 - Para usar openSSL 0.9.14 Usar as dlls de \Acbr\DLLs\OpenSSL\0.9.8.14 e também os arquivos do primeiro nível abaixo de \Acbr\DLLs\XMLSec Opção 2 - Para usar openSSL 1.0.2 Usar apenas os arquivos de \Acbr\DLLs\XMLSec\MinGW\32 e habilitar a diretiva no Acbr.inc Estão corretas essas afirmações? Eu fiz agora pela opção 2 e, aparentemente está tudo certo. Nos testes iniciais em laboratório não deu erro. Mas aí surge uma questão: nessa opção vou ter que distribuir todas as .dll junto com meu aplicativo? Pelo menos nos testes aqui em outra máquina que não a desenvolvimento, ele exigiu que se copiasse quase todas as .dll de \Acbr\DLLs\XMLSec\MinGW\32 para a pasta do aplicativo. Há alguma forma de contornar isso, ou seja, de não precisar enviar todas essas dll para o usuário final? Obrigado!

Pronto, habilitei. Porém agora passou a dar o erro no arquivo anexo. Procurei e tem um post aqui com esse erro. Ele recomenda copiar as .dll para a mesma pasta do .exe aplicativo. Todas as .dll da pasta \Dll do Acbr foram copiadas para a minha pasta, mas o erro persiste. Alguma sugestão? Obrigado

Não ativei. Pelo que entendi do post http ://www.projetoacbr.com.br/forum/topic/34177-acbrdfe-openssl-e-tls12/ eu deveria ativar essa diretiva se não quisesse instalar as .dll na máquina do cliente. Se em mando as .dll junto com o .exe, não precisaria ativar a diretiva. Entendi errado?

Exato. - \Acbr\DLLs\XMLSec\MinGW\32\ssleay32.dll - \Acbr\DLLs\XMLSec\MinGW\32\libeay32.dll - \ACBR\DLLs\XMLSec\libxmlsec-openssl.dll Está correto, certo?

Bom dia, Nenhuma dica? Desculpe insistir, mas estou com esse problema em vários clientes e não consegui fazer nenhum progresso na busca da causa/solução. O print que enviei no post inicial é de um teste que fiz no demo com um certificado de testes (associacao). Mas fiz mais outros 3 testes com certificados válidos de clientes e ocorre a mesma situação. O problema ocorre tanto em ACBrNFe1.NotasFiscais.Assinar, como em ACBrNFe1.NotasFiscais.Validar. Estranho que não esteja ocorrendo com outros colegas, pois, prá mim começou a acontecer depois da atualização de terça última e não fiz alterações nas minhas rotinas. Até porque, no demo do Acbr ocorre também o erro. Obrigado!

Boa tarde, Estou tendo erro de A.V. depois a atualização feita hoje. Testei inclusive no demo e ocorre na linha ao executar "NotaEhValida := SSL.Validar(AXML, GerarNomeArqSchema(ALayout, VerServ), Erro)", linha 333 da ACBrNFeNotasFiscais.pas. As configurações de SSL estão demonstradas no print anexo. Obs.: no debug consegui ir até a "function xmlReadFile (..." da libxml2.pas. Alguma sugestão? Obrigado!

Bom dia, Fiz alguns testes e realmente, ao desconectar o hardware, ocorre esse erro. Gostaria de solicitar que seja corrigida a palavra cripotografia. Ela aparece 3 vezes na unit function MsgErroGetCryptProvider: String, linha 125 da ACBrDFeWinCrypt.pas. Pode parecer pouca coisa essa letra, mas, no meu caso, onde trato os erros pelo texto (e.message) para poder dar uma mensagem mais transparente ao usuário, seu eu buscar por criptografia no erro, não localizaria criptografia. Obrigado!

Boa tarde, Tive várias ocorrência desse erro em vários clientes nos últimos dias. Não consegui identificar a causa, mas é muito provável que seja alguma instabilidade ou local ou no WS, pois alguns minutos depois, com uma nova tentativa, a nota simplesmente era transmitida normalmente. Abraços!

Bom dia Italo, Obrigado pela informação. Sua resposta é o que eu imaginava, ou seja, que as mudanças da Wincrypt seriam para todos os componentes de documentos eletrônicos. O que ocorreu é que eu tenho uma rotina que configura exatamente da mesma forma (em relação ao SSL), tanto o ACBRNFe e ACBRNFSe. Mas no ACBRNFSe deu um erro de 12002 (falha no envio da requisição). Esse erro ocorreu em um cliente e ainda não consegui reproduzi-lo aqui em laboratório para poder debugar. Vou tentar pesquisar mais. Mas beleza, está esclarecida a dúvida inicial. Obrigado!

Boa tarde, Talvez eu não tenha me expressado de forma correta, mas a dúvida maior não é o demo e sim se podemos configurar o TACBRNSFe com as mesmas inovações (WinCrypt) do TACBRNFe. Logicamente que me refiro ao parte do SSL -> TAcbrNFSe.Configuracoes.Geral.SSLLib := WinCrypt. Obrigado!

Bom dia, Pelo que vejo no demo da NFSe, a nova opção para substituição da Capicom pela WinCrypt ainda não está implementada, correto? Mas vai ser implementada, certo? Alguma previsão? Obrigado!

Bom dia, Tive esse erro na rotina ACBrNFe1.SSL.NumeroSerie := ACBrNFe1.SSL.SelecionarCertificado, mas apenas quando se selecionava um certificado A1 na lista de certificados. Mudei as rotinas do sistema para não deixar o operador cometer esse erro. Abraços

Bom dia, Certificado A3 da Caixa Econômica Federal. Usa o gerenciador Charismatics. http://www.caixa.gov.br/empresa/identidade-digital/Paginas/default.aspx Obrigado!

Debugado e não ocorreu nenhum erro. Chegou até na linha 566 com pfCallerFreeProv = true. Fiz outro teste informando a senha errada propositadamente. Aí deu o erro "O cartão não pode ser acessado porque o PIN errado foi apresentado" nessa procedure. Ou seja, o componente está recebendo a senha de forma correta, está testando ela e está passando, tudo certo. Já estamos ficando sem opções, hehe! Acho que vou tentar remover o Charismatics (gerenciador do certificado) e reinstalá-lo. Vi num post mais antigo um colega que estava com problema parecido e reinstalou o gerenciador e resolveu. O dele era Certisign, mas.... Obrigado!

Conforme relatei, eu já fiz esse teste de colocar a senha, inclusive no demo, sem resultados positivos. Mas agora me levantou uma dúvida. É possível eu setar a senha em um A3 e, com isso, ele não pedir mais a senha, ou seja, dispensaria a janelinha de login, é isso? Nunca consegui fazer isso. Eu atribuo a senha (ACBrNFe1.SSL.Senha := 'senha'), mas a janelinha do login é solicitada igual. Isso no caso da Capicom, pois no caso da libWinCrypt está com esse problema. Só me confirma isso então, se ACBrNFe1.SSL.Senha tiver valor, a janelinha de login do certificado NÃO deve aparecer? Se for isso, então deve ser algo no meu certificado ou no gerenciador dele. Obrigado

Concordo. Nitidamente é essa a impressão que dá. É como se a tela estivesse aberta aguardando se digitar a senha. Mas tive esse problemas da tela de senha ficar "por trás" no passado e posso garantir que a tela do certificado não está ativa, nem mesmo em segundo plano. Já fiz todas as análises possíveis no intuito de verificar se a telinha está em segundo plano, mas não está. Minha opinião é que tem alguma coisa impedindo que a tela seja apresentada Se configurar para Capicom, o problema não acontece.Além disso, com o F8 depois do break point o processo flui normal, mas com F9, não. Muito sinistro. Algum outro colega que acompanha este post já testou a nova libWinCrypt com A3? Talvez seja meu certificado ou máquina conflitando com alguma rotina nova do Acbr, sei lá. Obrigado!

Exato Daniel, congela nesse ponto. Olha outra coisa coisa que descobri agora: Se eu colocar um break point nessa linha 277 ( if not WinHttpSendRequest( pRequest,...) da ACBrWinHTTPReqResp.pas. Aí a compilação para ali. Então pressiono F9 e nada, fica congelado. Já fiz um teste aguardando 1 minuto. Se deixar sem break point, também não vai. Porém, se nesse break point eu pressionar F8 e não o F9, ele processa normal, ou seja, abre a telinha de login do certificado certinho. Será que não é alguma coisa no sistema do certificado ou da máquina? O estranho é que configurando para Capicom ele funciona, como sempre funcionou. Obrigado!

Bom fia, ACBrNFe1.SSL.Senha := 'senha', certo? Infelizmente não é o caso. Eu realmente não tinha colocado a senha. Mas fiz novos testes agora informando a senha do certificado e ficou na mesma. Testei tanto no meu sistema, como no demo. Obrigado!

Bom dia Daniel, Obrigado pelo retorno: Seguinte: Sobre o "código demais", ainda estamos aprendendo o que devemos e o que não devemos setar, hehe! Eu setei as 4 propriedades porque no demo também está setando. Então, se entendi corretamente a sua orientação, é preciso apenas atribuir um valor para Configuracoes.Geral.SSLLib. As outras 3 o componente assume automaticamente em consequência disso, está correto? Mudei a propriedade "Configuracoes.Geral.SSLHttpLib := httpWinINet" conforme você sugeriu e aí deu tudo certo. A telinha do login apareceu em 2 segundos. Obs.: 1) Na mudança acima, mantive Configuracoes.Geral.SSLLib := libWinCrypt; 2) Ao efetuar a mudança, o comportamento é o mesmo tanto no meu sistema, como no demo ACBR, ou seja, se deixo SSLHttpLib := httpWinINet, a tela de login do certificado aparece e o processo flui normalmente, mas se mudar para SSLHttpLib := httpWinHttp, a tela de login não aparece e a compilação vai só até essa linha da unit que informei no post inicial e trava. Não tenho como prosseguir com o debug a partir dali. Configuracoes.WebServices.TimeOut = 5000 Obrigado!

Boa tarde, A configuração ficaria assim, certo? acbreNFe1.Configuracoes.Geral.SSLLib := libWinCrypt; acbreNFe1.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; acbreNFe1.Configuracoes.Geral.SSLHttpLib := httpWinHttp; acbreNFe1.Configuracoes.Geral.SSLXmlSignLib := xsMsXml; Fiz essa mudança e a demora na rotina AcbreNFe1.SSL.CarregarCertificado continua(5 a 6 segundos). Mas agora há um outro problema. A execução simplesmente trava em um certo ponto. Consegui debugar até a linha 277 da ACBrWinHTTPReqResp.pas, ou seja, na rotina "if not WinHttpSendRequest( pRequest, LPCWSTR(wHeader), Length(wHeader), WINHTTP_NO_REQUEST_DATA, 0, Length(Self.Data), 0) then.... Depois disso não anda mais e nenhum erro acontece, nada.. Alguma dica? Obrigado! Desculpem a emenda, mas deixei de passar 3 informações que acho são importantes: 1 - Fiz todos os testes também no demo ACBR e o mesmo problema do travamento também ocorre; 2 - Não chega nem a ser mostrada a telinha de login do certificado; 3 - Se eu mudar para libCapicom ou libCapicomDelphiSoap, tanto no meu sistema, domo no demo ACBR aí funciona beleza. Obrigado!