Daniel Simoes

Olá Pessoal Estou promovendo modificações em ACBrECFVirtual.pas, com o intuito de dar suporte as Alíquotas de Isenção do ISSQN, ou seja (FS1, NS1, IS1) Atualmente o ACBrECFVirtual, tem nas posições 0 a 2 alíquotas "FF", "II", "NN"... Elas foram criadas, quando iniciamos o desenvolvimento do ECF Virtual, emulando um ECF Bematech... Os problemas atuais são: - O Nome correto dessas alíquotas deveria ser "F1, I1, N1" - Não há suporte as alíquotas de Isenção do ISSQN, ou seja (FS1, NS1, IS1) O ECFVirtual, utiliza as primeiras posições da lista de Objetos de Alíquotas, para programas as alíquotas de Isenção. Essa programação é feita de maneira "hardcoded". Se inserirmos as novas alíquotas de Isenção de ISSQN, precisaremos "empurrar" as alíquotas existentes, para novos Índices. Ou seja, hoje a memória INI do ECFVirtual é salva como: [Aliquotas] 00=1|FF|0|T|0| 01=2|II|0|T|0| 02=3|NN|0|T|0| 03=4|04|18|T|1| 04=5|05|12|T|0| 05=6|06|5|S|0| passaria a ser: [Aliquotas] 00=1|F1|0|T|2| 01=2|I1|0|T|2| 02=3|N1|0|T|2| 03=4|FS1|0|S|2| 04=5|IS1|0|S|1| 05=6|NS1|0|S|3| 06=7|07|18|T|2| 07=8|08|12|T|1| 08=9|09|5|S|1| O ACBrECF já possui um código para interpretar a nomenclatura de alíquotas de Isenção. Exemplo: "NN" será interpretado como "N1", "FF", será interpretado como "F1", etc... O ACBrECF não terá problemas, se você busca as alíquotas pelo Valor e Tipo. Exemplos: "18", "5S", "17T" O problema ocorrerá apenas, se você busca a alíquota pelo índice. Exemplos: "T03", "T05", "S04" A Unit em anexo, já possui um código que verifica que a memoria do ECFVirtual, não possui suporte as alíquotas de isenção do ISSQN, e faz a atualização do arquivo .INI para o novo formato... (isso é executado apenas uma vez) Por favor analisem a questão, e o fonte em anexo.. e manifestem, se vocês consideram essa modificação ser um problema que poderá causar muito impacto nos usuários do ECFVirtual ACBrECFVirtual.pas PS: A Unit em anexo, ainda não foi enviada para o SVN

Parece ser um caso para você acionar o suporte da Embarcadero a fim de corrigir o seu problema de compilação por linha de comando

Não está relacionado... Por favor leia os tópicos sobre o suporte a D7

A Regra de rateio funciona e deve ser seguida... se não funcionasse o ECF teria problemas, correto? http://partners.bematech.com.br/bemacast/Paginas/post.aspx?idPost=5790

Veja no diretório raiz do ACBr o documento de boas ao Trunk2... Lá explica a hierarquia de dependência dos pacotes... Nao precisa recompilar o Lazarus a cada Package... deixe para recompilar apenas no final

Não creio que seja algo do lado do ACBr... - Não temos bug report semelhantes a esse no fórum - Você mesmo não tem o problema em outra máquina... A ultima sugestão é trocar de máquina...

Olá pessoal, acabo de enviar modificações recentes para o suporte a TLS 1.2 em OpenSSL, criei um tópico específico sobre o assunto:

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/

Acho que não é bom manter 2 componentes ACBrPosPrinter. Eles irão competir pela Porta

Apenas se você usar OpenSSL

Com a ajuda do @EliasCesar, efetuamos um refactoring nos fontes do componente ACBrBlocoX, removendo propriedades desnecessárias, e separando as classes em Units corretas O suporte nativo a compactação com FileZIP, está presente, porém só compatível com Lazarus ou Delphi XE2 ou superior... Para Delphis inferiores ao XE2, cabe ao programador, efetuar o Zip e encode 64 do XML, e informá-lo na propriedade "XMLZipado"

Como reproduzir o problema, com os demos do ACBr, da pasta Exemplos ?

O Fisco não usou GZip.. implementei uma versão com ZipFile... vou subir em breve

A pergunta é. Você conseguirá comprar um eCNPJ para a sua empresa? Fale com o seu contador

Submeta o XML se análise do InteliSAT da Tanca... Link para download no tópico anterior

Parece ser um problema no NCM, veja a Analise do XML, pelo InteliSAT da Tanca

Funciona se você enviar para o Emulador do Fisco ? pode ser que o SAT não esteja configurado para Regime Normal...

Verifique se você marcou o Flag EhCombustivel no Produto

O ECFVirtual não tem relação com o SPED

Como você está efetuando o ZIP do XML ? A implementação que fiz no ACBr , usando gzip não está sendo aceita

O ECFVirtual tenta se comportar da maneira mais semelhante a um ECF Real... Veja no ECFTeste, versão Lazarus, um exemplo de uso dos ECFs Virtuais SAT e NFCe

Adicionei o suporte a compactação nativa, dentro do ACBr...

Devido a reforma do WebService do BlocoX, precisamos da compactação... portanto foi adicionado os métodos abaixo

o que estou querendo dizer, é que NUNCA, deve ser manter o numero do certificado ajustado por Objetct Inspector... isso exigirá uma recompilação da sua aplicação, a cada mudança de numero do certificado... Cabe ao seu programa, desenvolver uma rotina para ler esse numero de algum INI, XML, Banco de dados, e atribui-lo em runtime ao componente

Isso é tudo que não se deve fazer... Veja no Demo do ACBrNFe, como ler o numero do certificado de um .INI e atribui-lo em runtime ao componente...