bnobre

Olá Italo, obrigado pelo retorno. O problema é que nessa tela de PDV possuo muitos objetos/eventos, será provável esquecer alguém. A possibilidade de ocorrer a execução de outros eventos durante o envio da NFCe, é muito remota, pois o tempo do envio é muito curto, portanto eu só saberia tempos depois, pois o tempo ainda variaria de cliente para cliente. Na verdade eu estou querendo uma solução definitiva nessa questão pra eliminar uma suspeita. Em 3 anos com o emissor de NFCe rodando nos clientes, sempre tive um "bug" e nunca consegui reproduzir em laboratório, eu DEDUZO que ele mora nesse detalhe. Em um universo de milhares de NFCes emitidas por mês, de dezenas de clientes que tenho, APENAS umas 10 apresentam um problema. O vPag difere do vNFe, e coincidentemente difere sempre faltando ou sobrando o valor referente ao último item da NFCe. Em algum momento o usuário consegue acrescer ou remover valores do vPag, e suspeito que é durante o envio. Eu nunca consegui reproduzir esse erro, nem ve-lo acontecendo, só tenho essa suspeita, pois tentei por exemplo durante o envio acrescer novos itens, e consegui... Por isso sei que é possível "algo" ocorrer durante o envio, e creio que a origem desse bug está nessa possibilidade de executar outros eventos durante a Splash Screen de envio. Já tive muito tempo pra analisar o código, corrigir falhas e até implementar melhorias, essa é a única anormalidade visível que tenho conhecimento, por isso preciso elimina-la, colocar nos clientes e esperar algumas semanas pra aí então eu ter certeza que eu estava no caminho certo. Se eu simplesmente deixar os objetos invisíveis, pode levar semanas para o erro ocorrer novamente e eu suspeitarei que faltou deixar invisível algum outro objeto. Entende?

Olá a todos, Na tela do meu PDV, no botão de fechamento da venda, dentre outros comandos, tenho o comando ACBrNFe1.Enviar responsável por enviar a NFCe. Normalmente quando acionamos o evento click de um botão, todos os comandos desse evento são executados e só depois novos eventos de outros objetos podem ser executados, mas não é o que acontece nesse caso. Reparei com um teste simples que na linha do comando ACBrNFe1.Enviar, durante a sua execução, onde é exibido a Splash Screen do envio, o usuário consegue executar outros eventos de outros objetos do aplicativo, conseguindo dessa forma, por exemplo, inserir novos itens na nota enquanto está ainda está sendo enviada, dentre outros, desde que o mesmo seja "muito rápido". Minha dúvida é, como bloquear totalmente a aplicação durante a execução do ACBrNFe1.Enviar? Quero que o mesmo tenha acesso a outros eventos como é de praxe, somente depois do encerramento do código referente ao evento ainda em processo, no caso o click do botão Enviar. Desde já agradeço a atenção de todos

Olá a todos. Atualmente preciso entrar em meu aplicativo emissor de NFe, copiar a chave de acesso da nota que quero e só então abrir o site da NFe pelo navegador, onde colo a chave e faço a consulta. Existe algum componente ou função no ACBr onde eu informe a string contendo a chave e abra automaticamente o navegador, no site de consulta da NFe e com a chave já preenchida? Desde já agradeço a atenção de todos

Olá Daniel, esse cenário que mencionou está perfeito pra mim: Pois aí só tenho que acrescentar/substituir as DLLs, sem mudar o executável... Eu assisti o vídeo e dei um curti :-). Só um detalhe, o que quer dizer essa "(Nota: o ACBr ainda não é compatível com a série 1.1)"???

Então... Na verdade pra mim tanto faz a XMLSec ou a LibXML2, só quero tentar facilitar a migração nos meus clientes, não ajustando o ACBr.inc para poder manter o executável atual nos meus clientes. Hoje no meu aplicativo eu posso por exemplo escolher como assinar (xmlsec ou libxml2), mas compilei ele sem nenhum ajuste no ACBr.inc. Muitos dos meus clientes usam WinXP e como você disse se eu usar XMLSec para TLS1.2 vou ter que ajustar o ACBr.inc. Posteriormente você comentou que posso também usar o LibXML2, mas disse que seria "ideal" fazer também um ajuste no ACBr.inc para tal. Na verdade não queria fazer ajuste nenhum no ACBr.inc e continuar assim usando o executável atual. Se eu usar simplesmente o LibXML2 e não fizer esse ajuste funcionará o TLS1.2 e consequentemente o envio na versao 4.00 no WinXP? Quais problemas posso ter não fazendo esse ajuste "ideal"? Desde já agradeço os esclarecimentos

Quais seriam os possíveis problemas em manter? Pergunto isso pois já tenho esse executável compilado em diversos clientes e nesse caso eu teria que compilar outro e substituir.

Então consigo usar OpenSSL + TLS 1.2 no Windows XP sem mexer no ACBr.inc apenas marcando xsLibXML2??? Se sim vai ficar perfeito.

Sim... Mas quero usar a OpenSSL, pois a vantagem é que não precisarei migrar o Windows XP em meus clientes.

Bom dia José, tudo bom? Então meu amigo, meu aplicativo emissor de NFC-e já permite que o próprio usuário altere o tipo do SSLType conforme sua dica acima, mas creio que somente isso não bastará, eu acho que você não está levando em consideração a necessidade, de acordo com o post do Daniel que mencionei no início, de precisar alterar o arquivo ACBr.inc no que diz respeito ao uso ou não do TLS 1.2. Observe que ao usar o NFe 4.0/TLS 1.2 tenho que compilar com o ACBr.inc usando {$DEFINE USE_MINGW} sem o ponto, e usando a NFe 3.10 tenho que compilar com o ACBr.inc usando o {.$DEFINE USE_MINGW} com o ponto. Ou eu compreendi errado???

Olá meu amigo... Mas com esse CNPJ ao lado esquerdo da razão social mesmo? Feio desse jeito!!!

Olá a todos, Uso em meu emissor NFCe o ACBrNFeDANFeESCPOS para impressões dos cupons NFCe. O problema é que após a última atualização que realizei em meus componentes, houve uma alteração visual drástica na impressão dos cupons. Na nova versão observem que o CNPJ está ao lado do nome da empresa, além de outras mudanças. Eu gostei do fato de estar mais enxuto, mas está muito estranho o CNPJ ao lado do nome da empresa. Isso é pra ficar assim mesmo ou está com algum problema?

Olá a todos, Graças a dica do Daniel é possível usar o OpenSSL e TLS1.2: Mas o problema, pelo o que eu entendi, é que tenho que compilar um executável se quiser usar o TLS1.2/NFe4.0,e outro para usar o padrão atual para o NFe3.10, fazendo as alterações devidas no ACBr.inc {.$DEFINE USE_MINGW}. Ninguém teria um código ou sugestão para eu tentar flexibilizar isso? Dessa forma eu teria a possibilidade, com o mesmo executável, de configurar o uso para a NFe3.10 ou NFe4.00, o que seria muito útil quando eu for migrar as versões nos clientes. Desde já agradeço a atenção de todos.

Olá a todos , reestruturei meu emissor NFCe no que diz respeito as configurações das propriedades de SSLCryptLib, SSLHttpLib, SSLLib, SSLXmlSignLib e SSLType, com isso agora eu tenho a flexibilidade de configurar tais opções conforme eu achar mais interessante, fugindo assim dos inconvenientes e limitações do Capicom usado por mim há anos em diversos clientes. Em ambiente de testes ficou legal, mas agora fui implantar em ambiente de produção em um dos meus clientes e tive um problema novo. Meu aplicativo emissor de NFCe basicamente verifica no ato do envio do cupom, em casos de exceção, se o erro contém a string "requisição não enviada" ou "tempo limite" , se positivo ele considera que houve queda de conexão e gera tal nota no modo contingência, do contrário exibe o erro para o usuário resolver, por exemplo: NCM Inválido, cEAN Inválido, etc. Meu aplicativo emissor funciona há anos nos clientes com essa regra e sempre fluiu bem, mas sempre usei as configurações padrão do ACBrNFe no que tange o SSL, basicamente sempre usei CAPICOM. Nesse cliente, que tem 3 caixas, optei por usar o OpenSSL e o certificado puxo direto do banco, perfeito. O problema é, no cliente já com tudo funcionando eu desliguei a conexão da internet e me surpreendi com o fato de ter surgido um novo retorno de exceção, até então não conhecido e consequentemente não tratável por mim nesses casos de falha de conexão: Em outra máquina deu: Por curiosidade mudei para Wincrypt, aí ao desligar a internet o erro retornado é: Outro detalhe, ao simular a queda de conexão em ambiente de testes no laboratório, só recebo os erros já conhecidos até então e tratados por mim, "requisição não enviada" ou "tempo limite". Portanto minhas dúvidas são: 1 - Esses novos tipos de erros referentes a queda de conexão foram consequência da troca do Capicom por OpenSSL, Wincrypt, etc? 2 - Se sim para a dúvida acima, qual a lista de erros que posso esperar e consequentemente tratar transformando em uma contingência? 3- Porque em ambiente de testes não recebo os mesmos erros desse cliente? PS: Em ambos os ambientes uso OpenSSL e Windows XP. Desde já agradeço a atenção de todos

Boa tarde cara, Então ... Basicamente a primeira coisa é fazer exatamente o que você disse, "obter o conteúdo do certificado .pfx e armazenar em seu banco de dados". No meu (onde uso o MySQL) armazeno o conteúdo do .pfx em um campo BLOB de uma tabela específica. Caso tenha dúvidas de como fazer isso não é difícil achar instruções na net, pois vai variar de acordo com o Banco de Dados e componentes de acesso ao mesmo que você utilizar. Aqui uso o ZeosLib e consigo importar o conteúdo do .pfx para o banco com o comando ZQuery1campoblob.LoadFromFile(enderecodopfx). Feito isso, aí sim você vai informar ao ACBrNFe1 o conteúdo do certificado que você armazenou em sua base, com o comando que o André informou, ACBrNFe1.Configuracoes.Certificados.DadosPFX. Também será necessário informar a senha (a mesma se fosse instalar o certificado) através de ACBrNFe1.Configuracoes.Certificados.Senha.

Uso a biblioteca Zeos e aparentemente consegui com o seguinte comando: zQuery1dadospfx.LoadFromFile(enderecodopfx); PS: dadospfx é o nome da coluna na tabela.

Cara, esquece tudo o que eu falei aqui. Esse projeto tem definido internamente um proxy e eu não lembrava, pois raramente modifico ele, visto que é para um cliente em específico, foi por isso que ficou dando erro. FALHA MINHA Mas eu agradeço todas as dicas e sugestões... Abraços

Não sei se ajuda, mas se coloco SSLXmlSignLib = xsXmlSec também dá "Erro Interno 10060/Erro HTTP: 500"

Vamos lá... Marquei a opção, mas ele fez muito rápido... Então eu executei manualmente o "apagarAcbr.bat" e esse sim demorou algum tempo... Depois de alguns minutos ele terminou e eu executei novamente o instalador. Mas o erro persiste.

Está atualizada sim, estou na revisão 14568.. Vou atualizar novamente com a revisão de agora, 14570, mas não localizei a opção "Limpar Tudo" no instalador... Não seria "Remover arquivos antigos do disco (pode demorar bastante)"?

Então, como a versão dos meus documentos eletrônicos estão em 3.10, não preciso do TLS 1.2, na verdade meu projeto que funcionava está igual, só atualizei o componente e começou a dar esse erro. No Windows 7 dá: "Erro Interno 10060/Erro HTTP: 500" As DLLs que uso do OpenSSL são da versão 0.9.8.14 e eu as salvo no diretório Windows, mas por precaução testei na pasta do aplicativo e o erro persiste. Como disse eu não uso o TLS 1.2, mas a nível de teste segui sua recomendação e deixei rigorosamente conforme sugerido no fórum que citou e inclusive a propriedade SSLXmlSignLib, que não é citada nesse post, eu deixei conforme sugestão do vídeo do Daniel = xsLibXml2. Ao fazer isso o erro mudou para o mesmo do Windows 7: Erro Interno 10060/Erro HTTP: 500. E quando eu volto para SSLXmlSignLib = xsMsXml o erro volta para o que eu citei no início do post, "PFXDataToCertContextWinApi: Falha em "PFXImportCertStore" Erro: 00000057".

Ok

Ok

Olá José, tudo bom? Bem, vamos lá... Meu Windows é XP e uso TLS_ALL, estou ciente da necessidade da atualização do Windows, mas observe que tenho o erro também com a OpenSSL que de acordo com o vídeo do Daniel sobre ACBrDFeSSL roda sem problemas e inclusive se eu quiser com o TLS1.2. Outro grande problema é que desenvolvi uma aplicação especificamente para um cliente que usa OpenSSL puxando o PFX do HD, após a atualização dos componentes também começou a dar esse erro ... Antes funcionava sem problemas e em qualquer Windows. Se achar válido vou testar em um Windows 7 atualizado, mas conforme disse meu intuito é usar via OpenSSL e estou tendo esse erro com o mesmo.

Reproduzi o erro no Demo, em anexo.

Testei em OpenSSL e o erro é o mesmo... E estou com as DLLs atualizadas