Painel de líderes

Ola Tem um baita erro de logica no teu código.... Vc esta chamando det.add pra cada propriedade q vc alimenta... Det.add adiciona o novo item e deve ser chamado uma vez apenas para criar o item na lista de itens. Confira novamente o código fonte do programa exemplo da NFe.... Att Ricardo

Olá pessoal, Acabei de enviar para o SVN, modificações para que o ACBrDFe e ACBrDFeOpenSSL suportem comunicação segura usando TLS 1.2 O componente ACBrNFe, já irá tentar ajustar a comunicação para TLS 1.2, se detectar que a versão é superior a 3.1 Atualizando o OpenSSL Para usar TLS 1.2, é necessário ter a versão do OpenSSL superior a 1.0.1, normalmente a versão usada é a 0.9.8.14, e portanto ela precisa ser substituída. Se você tentar utilizar uma versão inferior, o ACBrDFeOpenSSL acusará o seguinte erro: Porém não basta apenas baixar e copiar uma nova versão das DLLs do OpenSSL (libeay32.dll e ssleay32.dll). O problema, é que a libxmlsec, que se encontra na pasta: "ACBr\DLLs\XMLSec", não é compatível com OpenSSL superior a 0.9.8... e se você simplesmente atualizar as Libs do OpenSSL no seu sistema, provavelmente o ACBrNFe, passará a acusar Exceptions no momento de assinar o XML A solução, é utilizar um novo conjunto de DLLs, da OpenSSL e libXmlSec, libXML, e demais... você pode achar essas DLLs em: ftp://ftp.zlatkovic.com/libxml/ Essas DLLs foram compiladas com "MinGW", e portanto elas precisarão das DLLs de RunTime, da MinGW. Para sua conveniência, copiamos todas as DLLs necessárias para a pasta: \ACBr\\DLLs\XMLSec\MinGW. Observe que temos a versão 32 e 64 bits dessas DLLs... quais eu devo usar ? Em resumo, use 32 se o seu Compilador é 32 bits, e 64 apenas se você estiver usando um Compilador que gere .EXE em 64 bits... Leia esse tópico, para compreender melhor: Copie TODAS as DLLs (e não somente algumas) da pasta "\ACBr\DLLs\XMLSec\MinGW\32" ou "\ACBr\trunk2\DLLs\XMLSec\MinGW\64" (conforme o seu compilador), para o seu diretório de DLLs... (se não tem certeza para onde você deve copiar as DLLS, leia com atenção o Post indicado anteriormente) Outro problema, é que a MinGW, gera as DLLs com uma nomenclatura ligeiramente diferente do VisualC, exemplo: libxmlsec1.dll com MinGW, e "libxmlsec.dll" com VisualC. Portanto, o ACBr teria dificuldades em encontrar essas DLLs e carrega-las de forma dinâmica. Precisamos portanto, informar ao ACBr, que usaremos o conjunto de DLLs no formato da MinGW... Isso é feito, editando o arquivo: ACBr.inc. Repare que lá no final do ACBr.inc, temos a seguinte linha: {.$DEFINE USE_MINGW} Apenas remova o ".", alterando para: {$DEFINE USE_MINGW} Pronto... com isso você estará pronto para usar o ACBr com OpenSSL e TLS 1.2, seja em 32 ou 64 bits... Obrigado... e considere nos ajudar, contratando o SAC ocasionalmente: http://www.projetoacbr.com.br/forum/sacv2/sobre/ http://www.projetoacbr.com.br/forum/sacv2/questoes_importantes/ http://www.projetoacbr.com.br/forum/sacv2/cadastro/

Perfeito !, recompilei o ACBR depois de alterar o .INC e funcionou perfeitamente, uma ótima tratativa pra quem não pode sair do Windows 2003 Server e vai precisar usar o TLS 1,2 na NFE 4,0 com OPENSSL !

Bom dia. Curvelo e outra empresa, diferente de Sete Lagoas.. O e-mail do pessoal de la é [email protected] Você deve enviar um e-mail e solicitar uma chave "has" que eles vão te enviar. Hai você coloca em Configuracoes.Geral.SenhaWeb := utst_ChaveAcessoWeb; Configuracoes.Geral.Emitente.WebChaveAcesso := utst_ChaveAcessoWeb; Configuracoes.Geral.UserWeb := utst_CNPJ_Prestador; O problema na impressão que o xml deles esta retornando uma tag que o Acbr não identifica, ai a aliquota de icms sai com valor zerado...

Após ativar a diretiva, seu Delphi passará a ficar dependente das DLLs de: http://svn.code.sf.net/p/acbr/code/trunk2/DLLs/XMLSec/MinGW/32/

O Delphi morrer não acho que seja o caso, as versões mais novas(ex Tokyo) mostram que o produto recebe bons investimentos em termos de melhorias, especialmente no que tange a "face" servidora das aplicações, o grande entrave que vejo, pelo menos para nós mortais brasileiros, é o alto custo de se manter sempre atualizado, as licenças são bem caras se considerar ferramentas similares como o Intellij da JetBrains ou o Visual Studio C# da Microsoft. Sem contar que na minha opnião o comercial do Brasil é péssimo, mandei dois email para o [email protected] pedindo cotação e nunca me enviaram, não há opção de comprar o produto online, vc precisa entrar em contato, falta de uma loja online poderia agilizar, sei que não é do interesse pois assim séria possível comprar em loja online fora do Brasil já que o preço não é igual no mundo todo, do pouco que pesquisei pagamos bem caro nesse produto, não sei se é devido impostos ou custo de manter a equipe de vendas no Brasil. Se alguém vai acabar com o Delphi é política de licenças da Embarcadero que oferta um produto caro em relação as opções de mercado. Não opção de parcelamento acima de 4x, um desenvolvedor free lance jamais pode bancar em 4x um produto de quase 8 mil reais (Enterprise), a versão Professional é um piada pois não vir com o FireDAC completo para que vai usar o Delphi ...