Rafael Batiati

Oi André, bom dia. Ao que parece, o relatório impresso está correto, é esse mesmo. O quê exatamente você esperava imprimir? Talvez o Regys possa nos ajudar: Existe outro relatório disponível no ACBr? Abs!

Oooopa! Vc chegou em boa hora. Nós estamos reestruturando todo o projeto, agora ele se chama ACBrFramework. Temos além do ECF os componentes PAF, AAC, EAD e Sintegra implementados, e tá aumentando. Fizemos uma estrutura bem legal pra permitir compilar em 32 e 64 bits, e em STDCALL para o VB também. E desenvolvemos um utilitário chamado DefExporter que gera os arquivos do VB6 contendo as declarações da DLL, isso nos ajuda a manter os projetos sempre sincronizados Enfim, remodelamos e melhoramos muita coisa, que ficou mais fácil de fazer agora. Baixe a última versão dos fontes e veja como o novo projeto ACBrFramework.OCX está mais simples de manter. Pode me mandar o que você tiver aí por email ou anexando aqui no fórum, que eu dou uma boa olhada. Sua ajuda será muito bem vinda. Abs!

Bom pessoal, Estamos aqui hoje para falar sobre a mudança do nome dos projetos da família ACBr32.dll. Como o projeto vem crescendo, buscamos um nome que refletisse de forma clara a natureza "Multi-Plataforma" e "Multi-Liguagem" de nosso projeto. Atualmente o nome "ACBr32.DLL" não reflete mais a realidade: - Ela pode ser compilada tanto em 32 quanto em 64 bits. - Ela pode ser uma DLL para windows ou um .SO para Linux/Posix - Ela é também um completo Framework escrito em .Net (ACBr.Net) e em Java (jACBr) que provê as principais funções do ACBr para essas linguagens. Com isso veio a necessidade de um novo nome, para um novo conceito: O ACBrFramework. Nesta família ACBrFramework, teremos: - ACBrFramework: Biblioteca nativa escrito em Delphi, para prover os componentes ACBr para qualquer linguagem/plataforma. - ACBrFramework.Net: Framework escrito em C# para qualquer linguagem .NET - jACBrFramework: Framework escrito em JAVA em C++ para a plataforma Java - ACBrFramework.OCX: Framework escrito em VB6 para qualquer linguagens que utilize controles ActiveX. - Outras linguagens: Exemplos de uso do ACBrFramework para c/C++, xBase (FoxPro, Clipper, Harbour), etc ... Logo teremos todos os componentes e funções necessarias para ser homologado o PAF-ECF em qualquer dessas plataformas! Atenciosamente, Equipe ACBrFramework.

Eu uso a DLL do fabricante diretamente, mandando comandos para a impressora. Como eu preciso de códigos de barras e estilos de texto (negrito, italico, etc) eu uso a DLL; Mas se você só usa texto simples, pode enviar diretamente para a porta COM ou LPT1 que a grande maioria de impressoras aceita isso. Pra vc que está num servidor ASP.NET e quer imprimir na máquina do cliente, considere usar impressoras Ethernet, tanto Bematech quanto Daruma possuem modelos ligadas na rede e não são mais caras que as outras. *** O pessoal mais antigo aí do ACBr pode confirmar isso pra gente: É possível imprimir um texto qualquer numa impressora não fiscal por algum componente do ACBr?

Sim, são vários fabricantes e várias implementações. Eu atualmente distribuo DLLs da Daruma, Bematech e Diebold para emissão de tickets em impressoras de cozinha. A bematech ainda é um inferno, pois tem versões da MP2032.dll específica pra certo modelo, aí tenho que distribuir 5 versões diferentes da mesma DLL... é isso mesmo. ** Existe sim o ACBr.NET.dll que é o ACBr para .NET; Mas até onde seu sei ACBr não manipula impressoras texto não fiscais. Seria realmente muito útil para quem utiliza essas impressoras poder contar com um componente igual ao ACBrECF. Abs,

Creio que o ACBr não seja o mais indicado para lidar com Impressoras não Fiscais. Eu costumo fazer isso utilizando a DLL do fabricante.

Adriano, Se você baixou usando o SVN, está tudo junto na pasta do projeto, uma solução do VS2010 em \ACBr32_DLL\ACBr.Net onde o projeto ACBr.Net.ECFTeste é o demo do ACBr.Net Abs,

oi Adriano, seja bem vindo. O ACBr não é bem um "pool", mas sim uma suite de componentes que atende a diversos requisitos para implementação de um PAF/ECF. O ACBrECF é um componente do ACBr que implementa os protocolos de comunicação com as principais ECFs do mercado, nativamente, sem dependências das DLLs dos fabricantes. Veja os modelos suportados: http://acbr.sourceforge.net/drupal/?q=node/13 Mas o ACBr suporta também balanças, leitores de código de barras, impressoras de cheques, geração de arquivos para o PAF, e várias outras coisas. O uso é muito simples, algo que em VB6 seria como o código abaixo: Dim ecf as ACBrECF set ecf = new ACBrECF() ecf.Modelo = ACBrModeloECF.Bematech ecf.Porta = "COM1" ecf.Ativar() ecf.AbreCupomFiscal() Qualquer ECF pode ser comandado da mesma forma, bastando trocar o modelo de ACBrModeloECF.Bematech para qualquer outro, com o ACBrModeloECF.Daruma por exemplo. *** Os componentes ACBr são desenvolvidos em Delphi, e o projeto ACBr32.dll é um esforço para torná-lo operável em outras linguagens como C#, VB.NET, Java, VB6, Clipper, etc... Atualmente o ACBr.NET é a mais completa implementação. Existem outros, como o jACBr em Java e o ACBrActiveX, feito em VB6 para uso em linguagens que suportam ActiveX, mas estão em fase bem inicial ainda. Para uso em outras linguagens, há também outra alternativa, o ACBrMonitor, que é um aplicativo externo que recebe e executa comandos via arquivo texto ou sokets TCP/IP. *** Você pode baixar o código fonte pelo SVN Saiba mais sobre o SVN: http://acbr.sourceforge.net/drupal/?q=node/37 O projeto está ACBr.NET está em Projetos\ACBr32_DLL\ACBr.Net; Depois de baixar, basta referenciar a DLL em sua aplicação. Qualquer dúvida, fique a vontade.

oi, tenho sim. Estamos mexendo no ECF, e o arquivo está ainda meio bagunçado. Na verdade estamos organizando o arquivo de forma a facilitar atualizar as declarações de quem utilizar a DLL. Temos que pensar em poder atualizar de forma fácil as declarações de quem usa dBase, Visual Basic, C/C++, Java e C#. Atualmente apenas o C# está 100% atualizado. Acho que essa semana fechamos isso, eu posto aqui. Abs

Alô pessoal, Recebemos a contribuição do colega Rafael Teno Dias que implementou as funções de DAV e MFD. Já estão disponíveis no SVN! Abs

Alô pessoal, Recebemos a contribuição do colega Rafael Teno Dias que implementou as funções de DAV e MFD. Já estão disponíveis no SVN! Abs

Oi Dzales, Eu não entendi muito bem qual componente você está usando, mas vamos ver se eu consigo te esclarecer, Se você está se referindo ao ACBRX, projeto desenvolvido e mantido pelo pessoal da EasySoftware (http://easysoftware.net.br/acbrx.html), São componentes ActiveX baseados no ACBr, até onde eu sei não é possível executar ActiveX no Linux. Talvez eles possam te ajudar com alguma informação a mais. Caso você esteja se referindo ao ACBr32.DLL, é tecnicamente possível de ser compilado para Linux e utilizado em qualquer linguagem neste sistema operacional. Mas nunca precisamos fazer isso até o momento ... Neste caso, acho que por restrições dos requisitos do PAF/ECF não é possível desenvolver aplicativo PDV rodando em browser. Não conheço muito de php, não sei se dá pra fazer alguma coisa parecido com "desktop" pra passar pela homologação. Poste mais detalhes, Abs!

Desculpe, falha de comunicação. (...) Nesse arquivo .prg não existem todas as funções atuais, acredito que continha todas na época em que ele foi implementado, mas agora com certeza há outras funções novas. Eu posso atualizá-lo com todas as funções atuais do ACBR32.DLL sim. O que eu quiz dizer é que, se vou criar as declarações, já não seria melhor colocá-las na sintaxe do DLLLoad e DLLCall? Por isso, se você tiver um exemplo de código, posta ele aí que eu sigo na mesma sintaxe. Abs

ok então, eu achei que você ia implementar usando o DLLLoad e DLLCall. Nesse .prg tem todas as chamadas pra operação do ECF, eu vou atualiza-lo pra constar as chamadas mais recentemente implementadas (acho que foi Velocidade e paridade da porta COM e DadosReduçãoZ ... tenho que olhar) Assim que pronto eu posto aqui Abs,

Oi lucimauro, que bom que vc teve sucesso. Cara, o único arquivo que temos contendo todas as declarações é o .PAS do Delphi, que implementa as funções, e o .CS do C# que faz a chamada a 100% das funções. Os demais exemplos, estão incompletos, alguns com muitas chamadas implementadas, outros nem tanto. Posta pra mim um trecho do seu código com as declarações, eu vou fazer uma lista de todas as funções na mesma sintaxe; Depois você testa e vê se vai funcionar. Abs,

a variável iECFHandle é um integer, e representa um ponteiro para o ACBr32.DLL localizar o componente ACBr. o componente possui uma função ECF_Create onde o valor do handle é retornado por referência iHandle = 0 ret = ECF_Create(@iHandle) a partir do ECF_Cretate, todas as funções precisam desse parâmetro para funcionar. no fim do uso, a função ECF_Destroy deverá ser chamada para que o componente possa ser destruído e liberado da memória. Dá uma olhada no exemplo em FoxPro, lá tem as declarações e a forma de uso. Eu não entendo muito dessa linguagem, esse exemplo em FoxPro foi contribuição de um colega. Mas posso te ajudar no que for possível quanto ao uso da DLL. Se você conseguir fazer um código de exemplo em Harbour, poste aqui que eu posso disponibilizá-lo no SVN. Abs!

Oi lucimauro, A darumaframework.dll é uma DLL nativa assim como o ACBr32.dll. A forma de uso das duas segue o mesmo princípio. Existem duas formas de fazer o link com uma DLL: Uma é usando as declarações estáticas para o compilador entender que essas funções devem ser chamadas de uma DLL externa: DECLARE INTEGER ECF_Ativar IN ACBr32.DLL INTEGER iECFHandle E outra é utilizando vínculo dinâmico, que deve ser o seu caso: NDLL:=Dllload("ACBr32.dll") nRetorno:=DLLCALL(NDLL,32,"ECF_Ativar ", iECFHandle) As funções do Dllload e DllCall presentes no Clipper/FoxPro/Harbour, fazem o carregamento da DLL e a chamada da função. Eu particularmente prefiro as declarações estáticas, pois não é preciso repetir a string com o nome da função e da dll em cada chamada. Se não for bem isso que você queria saber, poste um trecho do seu código ao chamar alguma função do darumaframework.dll pra eu entender, blz! Abs.

Sim, a DLL é compatível com qualquer linguagem de programação. Dê uma olhada no exemplo que temos em FoxPro (na pasta Projetos\ACBr32_DLL\ACBr_FoxPro) que lá tem a declaração das funções da DLL e suas chamadas, acho que esse exemplo em FoxPro vai servir pro Harbour. Qualquer dúvida quanto a declaração das funções e uso da DLL, fique a vontade. Abs,

Atualizei os fontes no SVN ... muito obrigado pela contribuição. Qualquer apoio que você precisar para evoluir isso aí, pode contar com a gente. Obrigado.

Obrigado xmaxmex ... Se você quiser postar os códigos em VB6 do ACBrActiveX eu atualizo o SNV com eles. Esse o projeto ACBrActiveX nós iniciamos apenas como um conceito, mas não evoluímos muito além disso. Se você for utilizar o ACBrDLL com o VB6 pode contar conosco para qualquer esclarecimento na hora de implementar. Abs!

Alô Sensum... Essas funções não foram implementadas ainda. Você as fez corretamente no código que enviou, tem como testar o Espelho MFD no utilitário ECFTeste que vem junto do ACBrMonitor? Você está usando emulador ou impresora? Eu estou tendo problemas com erro de comunicação em alguns computadores usando o emulador da bematech. De qualquer forma, essas funções serão implementadas, logo que estiverem ok eu posto um resultado aqui, ok. Abs!

Pessoal, Temos novidades no ACBrDLL e ACBr.Net: O componente ACBrAAC foi implementado! Com ele é possível cumprir de forma fácil os requisitos do PAF relacionados ao uso de Arquivo Auxiliar Criptografado. Para quem interessar, basta baixar os fontes do SNV e dar uma olhada no aplicativo de exemplo do ACBr.Net *** E tem mais boas notícias: Temos mais um desenvolvedor contribuindo para o projeto. Com isso começaremos a ver mais progresso no trabalho. Nessa empreitada nosso objetivo é desenvolver os componentes necessários para total apoio ao cumprimento dos requisitos do PAF-ECF: ACBrAAC, ACBrPAF e ACBrSintegra. Quem estiver em processo de desenvolvimento/homologação do PAF utilizando o ACBrDLL ou o ACBr.Net e quiser contribuir será de grande valia. Precisamos principalmente de dicas, conselhos e palpites sobre a utilização na prática desses componentes, e sugestões de outros componentes a serem migrados. ****** Pra finalizar com más notícias: Sinto dizer que o jACBr está ficando pra trás. Com as novas evoluções do ACBrDLL e do ACBr.Net não estamos tendo tempo necessário para evoluir o jACBr, e a defasagem de recursos entre eles já é bem grande. Por isso procuramos alguém disposto a adotar esse belo filhote da raça Java com pedigree em OO ****** Qualquer dúvida, sugestão é só falar Abs!

Pessoal, desculpe a dúvida primária, mas preciso de uma confirmação pra saber se entendi certo o que li nas outras perguntas aqui do fórum Como alguns devem saber, eu tenho trabalhado com os projetos ACBr32.dll, ACBr.Net e o jACBr .... manjo quase nada de Delphi, portanto tenham paciência comigo ... rsrs Estou iniciando a implementação do meu PAF/ECF usando o ACBr.Net (finalmente!!), e preciso esclarecer algumas coisas sobre os componentes ACBrAAC e ACBrPAF. 1. Como funciona o ACBrAAC e o ACBrPAF? Vi que nele há todas as informações sobre meu PAF e minhas impressoras autorizadas, etc... Mas onde isso se encaixa exatamente? 2. Ao definir a propriedade ACBrECF.AAC eu vou gerar um arquivo criptografado de TODAS as impressoras ou só do ECF em questão? 3. Esse arquivo é criado em cada PDV? De onde viriam os dados que alimentam a criação dos arquivos, como as impressoras autorizadas? 4. Quando o arquivo for deletado, ele será recriado com base em quais dados? 5. O fato de setar o AAC para o ECF faz com que o GT seja atualizado no arquivo de configuração? Alguém tem algum material pra indicar, onde eu possa entender melhor isso? Precisando decidir se os componentes ACBrAAC e ACBrPAF serão implementados no pacote do ACBr32.dll ou se é mais simples, implementar as funções semelhantes diretamente em .Net. Toda ajuda é bem vinda. Abs,

Bom dia Rodrigo, Que boa notícia, conseguiu homologar seu aplicativo usando o ACBr.NET? Mantenha-nos informado quanto a isso. Abs,

Oi Rodrigo, boa noite! Essas chamadas não estão implementadas na ACBr32.DLL; Vou fazê-las assim que possível e posto novo comentário. *** Eu também gostaria de esclarecimento, acho que o pessoal do ACBr poderá nos ajudar quanto a isso: Eu acho que essas chamadas específicas não são parte do protocolo do ECF, e dependem da dll do fabricante. Não sei o porquê dessa limitação, mas acredito que as dlls deverão ser colocadas junto à aplicação. Abs!