Rafael Batiati

Boa tarde, Dê uma olhada no último tópico sobre o jACBrFramework. Ele foi praticamente reconstruído do zero. Basta chamar na classe ACBrECF um dos métodos leituraMemoriaFiscal Não se esqueça de colocar a ACBrFramework32.dll e a DLL do fabricante no seu path C:\Windows\System32 ou C:\Windows\SysWOW64 no caso de Windows 64bits. Abs.

Atualizado, pode baixar novamente.

Pessoal, Boas novidades. O projeto jACBrFramework passou por um grande refactoring, novas classes bases e reorganização dos pacotes. A classe ACBrECF (que agora fica no pacote jACBrFramework.serial.ecf.ACBrECF) está com todas as propriedade e métodos implementados. Só faltam alguns ajustes nos métodos que retornam/recebem classes complexas. Temos também suporte a eventos agora no Java (via Listeners), por enquanto apenas poucos eventos foram adicionados para fins de teste. Todos os eventos foram adicionados ao componente ACBrECF, veja no exemplo como utilizá-los. O ECF está bem mais completo que a versão anterior, e mais simples de manter. Com essas alterações novos componentes poderão ser adicionados mais facilmente, dispensando o uso de C++ para as chamadas nativas. Baixem os fontes e confiram. Qualquer dúvida/problema é só postar por aqui. Abs

André, Você tem razão. O campo ValorVendaBruta estava vindo sempre ZERO do ACBrFramework. Corrigido e comitado no SVN, basta baixar a nova versão. ATUALIZAÇÃO Para explicar melhor o funcionamento dos métodos DadosReducaoZ e DadosUltimaReducaoZ: O caso do DadosReducaoZ(), os valores vêm dos contadores atuais do ECF. Por exemplo, o campo ValorGrandeTotal é o mesmo valor informado no Ecf.GrandeTotal; Isso faz com que os dados sejam a "fotografia" do status do ECF no momento, por isso devem ser chamados antes de efetuar a redução. Depois da redução vários totalizadores serão zerados. Já o DadosUltimaReducaoZ() retorna os dados da RZ informados pelo ECF, nem todos os modelos suportam todos os dados, então o retorno desse método varia de fabricante a fabricante. Esse método precisa ser chamado após a RZ e antes do primeiro movimento. Lembrando que o GetDadosReducaoZ() se chamado antes da RZ retorna os contadores de ANTES da RZ, ou seja sem incremento no COO e CRZ. Abs.

Boa noite Marcelo Não tinhamos previsão de fazer o ACBrDIS no momento, mas como ele é bem simples de ser implementado no ACBrFramework, vamos encaixa-lo entre uma tarefa e outra. Em breve posto aqui. (...) Aproveitando, gostaria de deixar toda a comunidade/usuários bem a vontade para relatar dúvidas, problemas e também para fazer sugestões de componentes a serem implementados. É sempre bom ouvir a opinião de quem está usando. Abs.

Fazendo com JNA não seria mais necessário a dll ACBrFramework_JNI. Estou em vias de terminar o piloto dessas alterações, mas pelos testes que fiz acho que será a melhor solução. Assim que tiver novidades eu posto aqui. Abs,

Boa tarde Silas, Se você usa um windows 64 bits, por favor, coloque o seu executável para compilar em x86 ao invés de AnyCpu. A DLL ACBrFramework32.dll é 32 bits, dessa forma o seu executável também deve ser 32bits. Abs

@regys O cancelamento não altera o GT, correto, mas o que eu quis demonstrar é que o GT já não batia antes do cancelamento, dessa forma ele não deveria ser atualizado no AAC; No fim, o efeito foi o mesmo de recriar o arquivo. No passo 2 o certo é você não desconectar o AAC. Mas também deveria acusar divergência no cancelamento, o que levaria junto também a hora que fosse abrir um cupom fiscal. Fica a dúvida, se é algo interessante para o ACBr controlar ou fica a cargo de cada desenvolvedor controlar a situação. @cleber No pdv o AAC não é desconectado nunca, só desconectei nesse caso pra demonstrar uma situação de GT divergente. (...) Podemos pensar numa modificação para isso? Obrigado a todos.

Pessoal, preciso de um help O procedimento feito aqui pode ser reproduzido com o aplicativo ECFTeste.exe. 1. Conecto meu ECF a um AAC e faço uma venda. O GT é atualizado no AAC corretamente. 2. Desconecto o AAC e faço outra venda, o GT agora é divergente. 3. Conecto o AAC novamente e tento fazer mais uma venda. Recebo a mensagem que o GT não confere. OK. 4. Com o AAC ainda conectado, cancelo o ultimo cupom fiscal. Nesse momento, eu esperava receber a mesma mensagem de GT não confere, mas o cupom foi cancelado no ECF e o GT foi atualizado no AAC, permitindo a operação normal depois disso para novas vendas. Isso é algum comportamento do ACBr, é um bug, ou eu estou utilizando o componente de forma incorreta? No caso do cancelamento, eu sei que não deveria permitir essa função no PAF-ECF quando o GT está divergente, mas esperava que o próprio AAC fizesse essa validação. Utilizei o emulador Sweda nos testes. Obrigado.

Pessoal, Fiz um commit inicial do jACBrFramework usando o JNA ao invés do JNI. A classe Device foi toda implementada como modelo, mas no ACBrECF nem todos os métodos funcionam ainda, os métodos ainda declarados como "native" deverão ser substituídos pelos métodos que chamam o JNA. Acrescentei ao projeto as classes de interop com a DLL Nativa ACBrFramework32.dll. Elas contém TODAS as funções já implementadas no ACBrFramework32.dll, e foram feitas a partir dos arquivos de include .h usando o *JNAerator*, mas planejo adaptar o nosso DefExporter que já gera as declarações em C/C++ e VB6 para gerar em Java também. Há também a pasta \lib contendo os jars necessários para usar o jna, esses precisarão ser distribuídos juntos do jACBrFramework. (...) Essa é uma boa hora de revisar e inserir coisas que faltam no ACBrECF do jACBrFramework. O programa de exemplo teve um trecho comentado em decorrência disso, pois ainda falta implementar vários métodos. Em suma, tem menos coisas funcionando agora que antes com o JNI, mas em compensação temos o modelo de como fazer mais fácil. Esse commit é mais para partilharmos o progresso feito até agora e pensarmos juntos no que vai ser daqui pra frente. Pelo visto o projeto JNI será descontinuado e é bom focarmos os esforços nesse novo modelo. (...) Para os interessados em rodar o código, eu só consegui fazer funcionar colocando a ACBrFramework32.dll no Windows\System32 ou no Windows\SysWOW64 para Windows 64bits. Certamente tem como distribuir a dll junto dos jars, mas como não tive tempo ainda de pesquisar sobre isso, usei ela no path do windows mesmo. Atenção para incluir os .jars do JNA ao classpath e no caso de Windows 64its, executar numa JRE de 32bits para ser compatível com a DLL de 32bits. Abraços

Oi, No ACBr já existe o componente ACBrBal para manipular balanças. Esse componente está implementado no ACBrFramework e no ACBrFramework.Net. Para implementá-lo no jACBrFramework, você deveria usar via JNI as funções definidas no arquivo ACBrBAL.h ... ou esperar a conclusão do estudo pra decidir se vale a pena usar o JNA ao invés do JNI ... Usando o projeto RXTX você provavelmente implementou outro componente e não o ACBrBal, e isso foge do o foco dos projetos do ACBrFramework. Nosso objetivo é *apenas* disponibilizar os componentes ACBr para outras linguagens/plataformas. Não é nossa proposta criar novos componentes nem implementar do zero componentes já existentes no ACBr em outra linguagem de programação. Dessa forma nós ganhamos com o evoluções/correções/conhecimento já disponibilizados pela comunidade do ACBr no decorrer de vários anos de uso e teste desses componentes. (...) A geração dos arquivos PAF, Sintegra e Sped Fiscal já estão prontas no ACBrFramework e ACBrFramework.Net, e é o mesmo processo para trazê-las ao jACBrFramework. Abraços.

Oi Brian, Qual componente você está implementando? As contribuições para o projeto são feitas através da participação no fórum e envio dos códigos-fontes. Nos projetos da família ACBrFramework nós incluímos apenas os componentes baseados em interop com o ACBr, e os códigos-fonte podem ser enviados aqui pelo fórum. Nós seguimos um padrão de código estabelecido durante o desenvolvimento, para assegurar que as manutenções e evoluções possam ser feitas por qualquer pessoa, por isso é importante a comunicação entre os colaboradores. Projetos e componentes que não fazem parte do ACBr não são o foco do ACBrFramework, mas podem ser incorporados ao repositório do ACBr em outra seção se os administradores acharem interessante. (...) Tivemos mudanças recentes no projeto, você pode ler sobre isso nesse outro post: Inclusive estamos discutindo mudanças de arquitetura do projeto jACBrFramework para substituirmos as chamadas JNI escritas em C++ por JNA escritas diretamente em Java. Caso tenha interesse, vale a pena dar uma lida; Abraços.

Veja se você registrou o componente corretamente:

Tem duas, pois uma é feita pra .Net enquanto a outra é modificada para ActiveX A correta pra uso em VB6 é essa http://sourceforge.net/projects/acbrframework/files/ACBrFramework.Net.COM.zip/download Precisa registrar, como explicado no primeiro post. Não precisa de outras dlls, apenas essa. Abs

André, Experimente usar a função DadosReducaoZ() ao invés da DadosUltimaReducaoZ() No momento não tenho como testar, mas acho que é isso mesmo. Abs

É na verdade não é que nós demos "uma parada" na versão em Java ... mas na verdade não temos ainda colaboradores ativos pra desenvolvê-la, e tudo que fizemos no java até agora foi a título de "prova de conceito", apenas para demonstrar que é possível fazer e dar bases para novos colaboradores tocarem o projeto. Já em .Net é outro caso, pois .Net é a plataforma que nós usamos pra trabalhar profissionalmente e o desenvolvimento do ACBrFramework.Net acaba fazendo parte de nossas atividades diárias. Como todo framework pra Microsoft.Net ele funciona com qualquer linguagem .Net, seja C#, VB.Net, etc ... Temos os seguintes componentes: Para o PAF-ECF: ACBrECF, ACBrAAC, ACBrEAD, ACBrRFD, ACBrPAF, ACBrSintegra e ACBrSped; Para transações TEF discado e dedicado: ACBrTEFD Componentes auxiliares: ACBrBal (balança), ACBrLCB (leitor de código de barras), ACBrSMS (envio de SMS), ACBrIBGE, ACBrCEP e ACBrCNIEE (consultas), ACBrValidador que valida a maioria dos documentos como CPF, CNPJ, etc ... (...) O ACBrNFe, está em fase de desenvolvimento, não temos ainda uma previsão de lançamento, mas já analisamos e vimos que é bem possível fazê-lo. (...) O fato mais importante desse projeto, é que podemos disponibilizar esses componentes para outras linguagens de programação mas reproduzindo exatamente o mesmo comportamento e a mesma forma de uso dos componentes originais em Delphi. Assim ganhamos na correção de erros, inclusão de novas funções, evoluções, conhecimento do fórum, etc, etc. Dê uma lida aí nos outros fóruns e veja quanta coisa dá pra fazer com o ACBr. Abs

Olá Moacir, A home do projeto ACBrFramework: http://acbrframework.sourceforge.net/ Como baixar a versão compilada http://sourceforge.net/projects/acbrframework/files/ACBrFramework.Net%20Install.vsi/download Como baixar o código-fonte http://acbrframework.sourceforge.net/downloads/codigo-fonte/ Baixando o código fonte você terá os projetos Demo dos principais componentes. É só seguir como foi feito nos demos. O ACBrFramework.Net possui todos os componentes necessários para se criar um PAF-ECF. Você poderá ler a respeito nos fóruns dos componentes, que apesar de ser voltado pra turma de Delphi, possuem as mesmas funções e nomes e a mesma forma de uso no C#. Qualquer dúvida específica você pode postar aqui no forum do ACBrFramework. Abs,

Nossos problemas acabaram-se!! É possível fazer chamadas de callback nativo via JNA, http://stackoverflow.com/questions/11849595/how-to-use-jna-callback Então podemos esquecer o blá blá blá do post anterior, acho que vai dar certo sim. Começarei um trecho experimental como prova de conceito, dando certo eu posto aqui. Abs!

Falha nostra, pode atualizar pelo SVN.

Legal, vou fazer uns testes e ver se dá certo. Só vejo um problema nisso: os eventos. Os eventos são implementados como ponteiros de função chamados a partir do Delphi, é um callback na verdade. Provavelmente nem via JNI nem via JNA daria pra fazer isso. A única solução que eu vejo no momento é implementando o ponteiro de função no C++ e chamando o método em Java via JNI no momento que o callback rodar. Talvez usar o JNA e implementar apenas os eventos em JNI seja uma solução, não sei. (*EDITADO, é possível sim Callback pelo JNI, conforme post mais abaixo) Como a DLL nativa ACBrFramework32.dll não foi idealizada para ser usada diretamente, é preciso criar também os modelos de classes para dar sentido a API do ACBr. Por exemplo, faz muito mais sentido fazer assim: ACBrECF ecf = new ACBrECF() ecf.getDevice().setPorta("COM1"); Do que fazer assim: int handle = ACBrFramework.ECF_Create(); int ret = ACBrFramework.Device_SetPorta(handle, "COM1"); if (ret != 0) { throw new Exeception("Erro..."); } As classes ACBrECF e Device são na verdade "wrappers" para colocar sentido nas funções da DLL nativa. Ficaria algo assim, usando JNA: public void setPorta(string porta) { int ret = ACBrFramework.Device_SetPorta(porta); checkResult(ret); } Nesse ponto (opinião minha), o trabalho de implementar as chamadas da Library JNA para as classes Java é bem equivalente a implementar em C++ e apenas declarar o método native na classe. Só muda o local, em um você faz em C++ no outro faz em Java. No Java com JNA é o código acima, e no C++ com JNI o código abaixo: JNIEXPORT void JNICALL Java_jACBrFramework_ACBrDevice_setPorta(JNIEnv *env, jobject obj, jstring porta) { SetString(&DEV_SetPorta, env, obj, porta); } Mas claro que temos que levar outras coisas em conta, como facilidade no entendimento e manutenção do projeto. Vamos nos falando. Abs,

Acrescentando algo mais: Veja o projeto abaixo https://code.google.com/p/jnaerator/ Ele pode criar as interfaces JNA a partir dos headers C++ que já temos no JNI. Se der certo, é um bom caminho ... topa modificar os javas pra usar JNA ??? Abs!

Concorco 100% que implementar o JNI é um trabalhão. Mas precisamos dele porque o java não suporta chamar um método nativo diretamente, só através do JNI ou do JNA**. O que acontece com a darumaframework, é que na mesma DLL eles implementam tanto as chamadas nativas quanto as chamadas de JNI, sem precisar de 2 dlls. Pra fazermos o mesmo que a Daruma faz no ACBrFramework32.dll, precisaríamos fazer o JNI em Pascal. Não que seja impossível, mas vai depender de projetos de terceiros, pois a Sun/Oracle só suporta C/C++ **Outra saída que temos é usar o JNA ao invés do JNI. Isso dispensa o projeto em C++ e tornaria o código Java responsável pelas chamadas, da mesma forma como o .Net é hoje. A desvantagem do JNA é depender de pacotes específicos para isso. Como eu não trabalho diretamente com java não sei até onde seria exatamente um problema na prática. http://today.java.net/article/2009/11/11/simplify-native-code-access-jna Qualquer idéia pra facilitar/melhorar é bem vinda. Abs!

Cara, o funcionamento do TEFD é todo baseado em eventos, e ele precisa do ECF pra funcionar também. Eu sugiro finalizar o ECF primeiro pra depois pegarmos o TEFD com mais proveito. (...) Quanto ao projeto do SVN, você está baixando o código do lugar certo mesmo? a versão commitada do SVN chama-se ACBrFramework_JNI e jACBrFramework. https://acbr.svn.sourceforge.net/svnroot/acbr/ACBrFramework/jACBrFramework

Pessoal, Visando facilitar a vida dos novos colaboradores que estão entrando no projeto jACBrFramework, nós demos uma arrumada na casa. Temos algumas novidades no jACBrFramework e jACBrFramework_JNI: Refactory das classes bases do projeto (criação de ACBrInteropBase, ACBrClass e ACBrComposedClass) Agora a estrutura das classes em java estão mais parecidas com design usado nas classes do .Net; Isso nos leva a aplicar as mesmas soluções usadas no .Net para resolver os vários cenários de Interop com os objetos do ACBr. Criação da classe Device e inclusão da propriedade Device no ACBrECF Já usando a nova classe base ACBrComposedClass, a classe Device foi criada. Ela manipula as propriedades da comunicação serial. Agora é possível fazer algo assim: ACBrECF ecf = new ACBrECF(); ecf.getDevice().setPorta("COM1"); ecf.getDevice().setBaud(115200); Incluímos a título de exemplo apenas as propriedades getPorta/setPorta e getBaud/setBaud; As demais bastam ser adicionadas seguindo o mesmo modelo. Criação do projeto no NetBeans (descontinuado o projeto no Eclipse) O antigo projeto em Eclipse foi migrado para o NetBeans, por ser mais popular e mais fácil de usar. Em breve vamos migrar o projeto do JNI do Visual C++ para o NetBeans também. Atualização das libs e dos headers do ACBrFramework no projeto ACBrFramework_JNI Atualizamos o JNI para usar a última versão do ACBrFramework. Isso nos dá acesso às últimas correções/melhorias. (...) Planos para o futuro próximo: - Adicionar o suporte aos eventos do ACBr utilizando Listenners no java. Fundamental para implementar componentes orientados a eventos como o TEFD por exemplo; - Automatizar o processo de criação das libs e headers utilizados no ACBrFramework_JNI, para que tenhamos mais agilidade na hora de atualizar correções/modificações feitas; (...) Baixem o código pelo SVN e confiram. Qualquer dúvida sobre uso, ou desenvolvimento no java ou JNI é só postar aqui. E lembrando, para mantermos a compatibilidade das alterações feitas por todos os colaboradores, é fundamental que a participação no forum e o envio dos fontes alterados. Abraços!

xmaxmex, Os componentes AAC e EAD foram adicionados recentemente, baixe a dll mais atual pelo link de download ou pelo SNV. No projeto demo do VB6, elas estão apenas declaradas, mas sem uso, pois a parte do demo do AAC e EAD não existem nesse projeto. Caso você tenha interesse em adicionar os demos em VB6 pra esses componentes, basta seguir o que existe no aplicativo ECFTeste original em Delphi e postar o fonte que a gente atualiza no SVN. Temos planos de disponibilizar os componentes PAF e RFD para ActiveX dentro em breve. Abs,