Painel de líderes

Porque a minha aplicação, quando compilada no Trunk2 exige as DLLs do XMLSec ? O Trunk2, tem a habilidade de suportar OpenSSL (XMLSec) e CAPICOM, na mesma aplicação... e no ACBrNFe, existe a Classe TDFeSSL, que permite configurar qual será a biblioteca de SSL em Design ou Run-time Para isso, basta mudar a configuração usando comandos como abaixo: ACBrNFe1.Configuracoes.Geral.SSLLib := libOpenSSL; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicom; ACBrNFe1.Configuracoes.Geral.SSLLib := libCapicomDelphiSoap; // Mesmo que "libCapicom", mas usando a Indy Porém, para efetuar essa "magica", precisamos compilar todas as Units que dão suporte a CAPICOM e OpenSSL\XMLSec, e elas injetam a dependência de DLLs externas Porque eu usaria o suporte a OpenSSL ? O OpenSSL é ótimo para certificados do tipo A1... pois você não precisa instalar o certificado no Windows... basta apontar o caminho do arquivo PFX e a Senha: ACBrNFe1.Configuracoes.Certificados.ArquivoPFX := edtCaminho.Text; ACBrNFe1.Configuracoes.Certificados.Senha := edtSenha.Text; Porque remover o suporte a uma das bibliotecas de SSL ? A desvantagem, é que a sua aplicação agora ficou dependente de mais DLLs, e para alguns pode ser um problema, distribuir e instalar as mesmas Onde eu encontro as DLLs ? \ACBr\DLLs\OpenSSL \ACBr\DLLs\XMLSec Para onde eu copio essas DLLs ? Você deve copiar TODAS as DLLs das pastas acima indicadas (e não apenas algumas). Você pode copiar para a mesma pasta da sua aplicação .EXE ou para o "System" do Windows Observe que, essas DLLs são 32 bits, e portanto só funcionarão para aplicações compiladas com um compilador 32 bits (que é o padrão para Delphi e Lazarus)... Uma aplicação 32 bits roda em um S.O. 64 bits, mas o oposto não ocorre... Considerando que essa DLLs são 32 bits, então: Se o seu Windows for 32 bits, copie para a pasta: C:\Windows\System32 Se o seu Windows for 64 bits, copie para a pasta: C:\Windows\SysWOW64 Se você estiver instalando DLLs de 64 bits em um Windows 64 bits, então a pasta correta é: C:\Windows\System32 (vai entender... pergunte pra Microsoft) Como eu removo a dependência ? Nunca usou o OpenSSL ? Nunca deseja usar ? Então você pode remover o suporte do ACBr ao OpenSSL/XMLSec, e com isso, remover a dependência de sua aplicação das DLLs do XMLSec.. Edite o ACBr.inc... Observe que no inicio do mesmo, existem as linhas abaixo: {.$DEFINE DFE_SEM_OPENSSL} {.$DEFINE DFE_SEM_CAPICOM} Apenas remova o ".", se quiser ativar a remoção... {$DEFINE DFE_SEM_OPENSSL} Por que mesmo assim, a sua aplicação fica dependente das DLLs do OpenSSL (libeay32.dll, ssleay32.dll) ? O ACBr usa o OpenSSL para várias outras tarefas, como: criptografia e assinatura (ACBrEAD), comunicação segura (ACBrMail, ACBrHttp)... e outras... Então hoje, elas sempre serão necessárias... essa dependência já existia no "Trunk1"

Olá pessoal, Depois de um empolgante trabalho em conjunto entre a equipe do ACBr e do Fortes Report CE... Temos o orgulho de apresentar a nova versão do Fortes Report CE, trazendo os seguintes benefícios: Diversos bugs corrigidos Suporte a Lazarus Suporte a D7 a Tokyo 10.2.2 em um único Package Instalador automatizado (frceInstall.exe) O Fortes Report CE poderá ser baixado pelo SVN ou GIT, ou ainda, baixado pelo FRCEInstall.exe, usando a integração com o SVN Para baixar o Fortes Report CE por SVN, use o endereço: https://github.com/fortesinformatica/fortesreport-ce/trunk Para baixar o Fortes Report CE por GIT, use o endereço: https://github.com/fortesinformatica/fortesreport-ce.git Lembre-se que você precisará remover qualquer outra versão do Fortes Report que existir em sua máquina antes de instalar a nova versão... Isso implica em: Remover o Package da versão antiga do Delphi Remover os diretórios da versão antiga do Lib Path do Delphi Apagar os fontes e DCUs, e BPLs da versão antiga Todos os pacotes do ACBr, que fazem referencia ao Fortes Report, estão nesse momento, sendo alterados para fazer uso do novo nome de pacote adotado pelo Fortes Report CE Delphi: frce.dpk; Lazarus: frce.lpk

Correto colega. Não estou solicitando nada, estou apenas apresentando as informações que constam no XML. Por outra visão, a explicação é bem simples, basta que "essa gente" leia com atenção a LC 123, especialmente o Artt. 23 e suas nuances. Se existem explicações que contestam as normas legais, infelizmente eu desconheço. Att.

Prates, as informações não devem aparecer nos devidos campos conforme o Manual Integração Contribuinte versão_4.01-NT 2009.006. e nota técnica 2009/004. Sugiro que informe em dados Adicionais as informações de Crédito de icms. Atenção as regras do manual. O que escrevo nas notas de simples nacional para crédito de icms : sString := ' - DOCUMENTO EMITIDO POR ME OU EPP OPTANTE PELO SIMPLES NACIONAL.;- PERMITE O APROVEITAMENTO DO CREDITO DE ICMS NO VALOR DE ' + FloatToStrF( NotaTemp.VCREDICMSSN, ffCurrency, 15, 2)+ ' ALIQUOTA DE ' + FloatToStr( GlobalValues.Emissor.EMI_PCREDSN)+'% , NOS TERMOS DO ART. 23 DA LC 123/2006;'; Entre em contato com um setor fiscal para o devido assunto.

Boa tarde Gabriel, Em função da grande diversidade da NFS-e, estamos migrando aos poucos. Em primeiro lugar pretendemos fazer com que o componente funcione para os provedores que seguem o padrão ABRASF versão 1.00 e que somente o Lote seja assinado ou os RPS. Depois vamos partir para os provedores que seguem o padrão ABRASF versão 2.00 e que somente o Lote seja Assinado ou os RPS. O passo seguinte é fazer funcionar os provedores da versão 1.00 cujo Lote e RPS são assinado, depois os provedores da versão 2.00 Cumprida essas 4 etapas vamos partir para os provedores que não seguem o padrão ABRASF que é o caso do ISSDsf e outros.

Isso ai, assim se faz a evolução, na hora de uma necessidade pontual, deve-se criar uma alternativa! Ou aprende na marra como se faz para corrigir o problema .