Painel de líderes

Depois de muita conversa interna e requisição de uma parte dos usuários ACBr, resolvemos estender o suporte ao Delphi 7 até Janeiro de 2017. Por que? Nossa principal motivação foi porque muita gente está pensando que quando chegasse o fim de agosto a compatibilidade com o Delphi 7 será simplesmente removida e seus aplicativos vão parar de funcionar. Infelizmente, algumas pessoas estão usando isso com um oportunismo, fazendo "terrorismo" nos usuários do projeto ACBr. Queremos que entendam que não é fácil manter a compatibilidade do projeto em tantas versões diferentes. E não estamos recebendo muita ajuda nessa área. É difícil manter compatibilidade com versões UNICODE quando nós mesmos não usamos. Mas então em janeiro meu aplicativo Delphi 7 deixará de funcionar com o ACBr? Não!!!! Seu aplicativo vai continuar funcionando. Isso é mentira, falácia, balela, uma grande prosopopéia para acalentar bovinos (conversa pra boi dormir). Então o ACBr não vai mais enviar alterações e correções de acordo com a legislação? Claro que vamos continuar enviando alterações e correções. Então não entendi... Pois é... Isso é o que a gente está tentando esclarecer... Deixa eu tentar... Como é o processo atualmente: Sempre que antes de enviar uma correção, alteração ou inclusão de nova característica, precisamos avaliar se vai funcionar no Delphi 7. Mas a maioria de nós não utiliza mais o Delphi 7. Então depois fazemos a correção, testamos na versão que utilizamos. Daí precisamos, por exemplo disparar uma máquina virtual, esperar ela carregar, copiar o novo código para a VM, fazer os testes no Delphi 7, voltar a máquina normal e só depois enviar ao SVN. Como queremos que seja o processo após janeiro de 2017: Fazemos a correção que precisamos, testamos nas versões que suportamos, e enviamos ao SVN. Mas e o Delphi 7? Os componentes até essa data vão continuar funcionando no seu Delphi 7. Mas a partir dessa data você deverá ter cautela para atualizar via SVN. Eventualmente, sem intenção, uma quebra de compatibilidade pode acontecer. Neste caso você sempre terá a opção de voltar para uma revisão que esteja funcionando. Mas se preferir poderá fazer algo: Corrigir você mesmo o problema; Encontrar algum voluntário para corrigir; Atualizar para uma IDE suportada; Quais as IDE suportadas? Lazarus ou Delphi 2009 ou posterior.

Olá para todos, Hoje fiz um grande commit no SVN, modificando todas as chamadas a diretivas de {$IFDEF CONSOLE} para {$IFDEF NOGUI}. O motivo é que conforme me explicaram na lista oficial do Lazarus, a compilação em Linux sempre traz a diretiva CONSOLE ligada, mesmo em uma aplicação Grafica (GUI).. Portanto, as verificações da diretiva CONSOLE do Linux poderiam causar problemas de compilação.. Também enviei modificações efetuadas pelo colega Luiz Camara, da lista de email "Lazarus Brazil" para que a compilação em Lazarus possa conviver pacificamente com outros projetos que também usam a Synapse e OpenSLL.... Isso pode requere um "Clean Up + Build All" na sua IDE do Lazarus... Espero não ter "quebrado" nenhum código, testei em Lazarus e Delphi e aparentemente está tudo OK... Se alguem notar algo errado (principalmente o pessoal do ACBrFramework), é só me avisar.. ficarei atento...

Bom dia senhores. Estou criando este tópico para discutir algo que já foi mencionado em outro tópico (pesquisei e encontrei), porém como no último comentário ninguém respondeu ao usuário, resolvi criar este. Link do tópico anterior: http://www.projetoacbr.com.br/forum/topic/30850-simples-nacional-e-pisntcofinsnt/ Enfim que tive o mesmo problema relatado no tópico anterior: Empresa do simples precisa utilizar produtos não tributados pelo PIS/COFINS. Como também foi relatado lá, um usuário entrou em contato com a SEFAZ de SP e esta disse que basta utilizar o grupo PISNT. Ainda, na especificação do SAT diz que "O uso do subgrupo PISSN/COFINSSN são para contribuintes do Simples Nacional." mas não diz que empresas do simples não podem utilizar outro grupo. E, para finalizar, fiz testes enviando o PISNT e COFINSNT para empresas do simples e funciona perfeitamente. Fiz uma alteração do pcnCFeW.pas, mas acredito não estar da melhor forma, porém, está funcionando. Fiz a primeira verificação como sendo se o grupo de pis/cofins se encaixa nos não tributados, para gerar o PISNT e COFINSNT. Talvez, ao invés disso, seria melhor deixar essa verificação como estava, e repeti-la na condição que verifica o cRegTrib = RTSimplesNacional. Se puderem analisar e ver a possibilidade de fazer a alteração nos fontes, senão teremos que sempre alterar manualmente. Um abraço e obrigado! pcnCFeW.pas

No svn a contribuição!

Entao sergio na verdade ele nem citava não viu .... Dava o erro mesmo e ficava naquilo de access violation... Ele registrava no log o access violation mas nao registrava a falta da zlib. Depois que eu coloquei aquela dll que vc me passou de 09.08 se nao me angano é que ele mostrou falta da zlib.... Ai eu formatei meu note novamente (Pela quinta vez rsrsrs), Delphi puro com Fortes,Fast e acbr e o detalhe que coloquei a zlib da pasta do linker manager na pasta do executavel do exemplo e eeee... Magicaaaaa rsrs.... Funcionou. Que fique registrado ai para os que tiverem o mesmo problema.... Abraços a todos ...

Bom dia! acho que seus fontes estão desatualizados pois peguei sua unit pra comparar e não tem diferença entre elas!

Bom dia Mauro, Desculpe pela demora em responder. Muito obrigado pela colaboração, já analisei e enviei para o repositório.

Boa noite Rick, Muito obrigado pela colaboração, já esta no repositório.

Sim... equipamento da CompSis, modelo MFE-WGM/8... Durante o mês de Julho, fizemos diversos teste de envio junto a Sefaz-CE para o ambiente de teste. Simulamos quase 4.000 vendas em um dia para envio pelo aparelho e funcionou perfeitamente com o ACBr.

Olá, Comecei a implementação do MFe/Ceará em Fevereiro, e utilizei o ACBr e emulador offline do SAT da Sefaz de São Paulo. Depois q concluirmos o desenvolvimento do módulo MFe (Ceará) na aplicação Comercial, a Sefaz-Ceará disponibilizou o aparelho do SAT (MFe) para testes e não tivemos nenhum problema com o ACBr. Atualmente já temos um cliente utilizando em modo de produção com a Sefaz monitorando o funcionamento do AC junto com o aparelho.

Obrigado pela notícia.

Resumindo: a máfia dos fabricantes de equipamentos de ECF + órgãos homologadores + interventores de equipamentos ECF .... continua. Nada muda. A não ser a sobrecarga de trabalho e de gasto com homologação e equipamentos de teste que nós, desenvolvedores, sempre tivemos. E o gasto exorbitante dos nossos clientes usuários de ECF que tem que comprar equipamentos caríssimos e pagar por intervenções que muitas vezes são referente a defeitos que já vem de fábrica ou da própria dll do fabricante que não dá retorno correto. Que País é esse? Me desanima não, Brasil.

Minha nossa... NFCe dentro do ECF 09/09... os caras acham que basta escrever um decreto e pronto... Isso tudo é vaidade, em não adotar o SAT de SP, que já está pronto e funcionando, e sem problemas de contingência off-line

Bom dia, Eu lhe pergunta, você chegou a instalar a JEDI? No meu caso, o problema era exatamente esta suite, a versão que eu tinha estava bugada para berlin, dai ao instalar ela, comprometia todo o resto, lembrando que o acbr faz uso de alguns units desta suite.... Lembrando também, que o fastreport que vem junto com o Berlin é o basic, isto que dizer que não dar suporte a script, alguns dos relatório do acbr são montado usando as versões completa... ficar atendo quanto a este detalhe.

Bom dia, Esse curso do Guinter Pauli é recente? Pergunto isso, porque vi um curso dele também com DataSnap em versões mais antigas do Delphi. Até usei como base para alguns projetos. Mas nas versões mais novas do Delphi, o REST com JSON foi muito melhorado e simples de implementar e entender. E o melhor de tudo é o resultado final (rapido, estável).

estou com um erro parecido, e utilizo o acbrmonitorplus 0.3.07.2, na impressao sai normal mas quando faço com o comando NFE.EnviarNFe e gero a nota pedindo para imprimir funciona normalmente, quando NFE.IMPRIMIRDANFE quando preciso re-imprimir ai sai igual a imagem em anexo, e estranho e que são os campos fixo do danfe, e não os dados que vem do XML

Bem sobre os erros na IDE, tratando-se dos que mencionei acima, trata-se da versão que foi instalada. Se baixar o .Iso completo do site e instalar, vai ver que resolve o erro mencionado acima!

Faça o seguinte: Baixe os 3 repositórios: 1. JCL: https://github.com/project-jedi/jcl/trunk/jcl 2. JVCL: https://github.com/project-jedi/jvcl/trunk/jvcl 3. JEDI: https://github.com/project-jedi/jedi/trunk (este repositório possui arquivos .inc que são necessários para compilar a JCL corretamente) Após baixar copie os arquivo do passo 3 para: <jcl>\source\include\jedi Execute o arquivo "Install.bat" que está na raiz do repositório JCL baixado, tudo normal sem nada diferente, siga o que ele indicar, talvez na aba 64 bits falte o diretóri, mas basta criar ele conforme ele informa. Execute o arquivo "install.bat" que está na raiz do repositório JVCL baixado, também tudo normal conforme indicado pelo instalador. Se seguir este passo-a-passo não tem erro, tudo funcionará normalmente.

Meu amigo, foi mal, pensei que a pesquisa no topo da pagina era genérica do google, dei uma olhada aki e tem vários tópicos relacionados, hoje a noite quando chegar em casa vou verificar com calma, pois este serviço que estou fazendo é "bico", não posso fazer aki na empresa. Valeu...

Precisaram mudar muita coisa ? Eu acreditava que era só declarar -dNOGUI nas opções de compilação...