Rafael Batiati

Lembro que já discutimos sobre implementar o TEF dedicado no ACBr, Achei um trecho interessante da conversa no antigo fórum do ACBr, lá no ForumWeb http://www.forumweb.com.br/foruns/topic ... f__st__100 A conclusão que chegamos foi que atualmente só fazemos TEF via SiTEF. Assim é muito mais fácil implementar na linguagem de destino. Só se um dia tivermos vários fornecedores (como temos vários ECFs), usar o ACBr como uma interface padrão para todos eles seria vantajoso. Abs

Sim, eu homologuei o tef com a ACBr.Net e usando a DLL do SiTef (Tef dedicado da software express) Você está homologando TEF discado ou dedicado? O componente do ACBr (acho) que é só pra TEF Discado. Como meu aplicativo só usa TEF dedicado, eu não inclui ele na ACBr32.dll. *** O caso do Alt+F4 e outros atalhos do windows, existem na API do windows chamadas próprias para isso. Como um aplicativo de AC não deve ser minimizado nem fechado, esse requisito também foi naturalmente cumprido durante o desenvolvimento. Mas como eu disse, acho que essas funções devem pertencer ao escopo na sua aplicação (e não da DLL do ACBr ou do SiTef). Se você desenvolve uma automação em Clipper, bloquear o teclado seria bem diferente de uma automação em Java ou de outra em Delphi. Meu aplicativo por exemplo é desenvolvido em WPF, e as DLLs que usam diretamente a API do windows fazem uma bagunça danada na interface gráfica. De uma olhada nesse post: http://bytes.com/topic/c-sharp/answers/ ... sc-alt-tab Abs,

Alô, Em algumas bibliotecas de componentes de automação comercial existem funções de bloquear teclado e mouse, nas dlls da bematech, daruma, etc. Eu particularmente acho um design incorreto uma DLL de comunicação com equipamentos manipular a camada de interface gráfica com o usuário, ainda mais a ACBr32.DLL que pretende trabalhar com várias linguagens e sistemas operacionais. Em meu aplicativo de automação, esse requisito foi naturalmente cumprido mantendo os inputs desabilitados enquanto o TEF trabalha. Vou verificar se o ACBr possui a função equivalente e se dá pra implementar na DLL. ******** Para ajudar no projeto, baixe o código fonte pelo SVN e dê um "passeio" por ele. Você pode ajudar de diversas formas: - Reportando bugs e necessidades enquanto desenvolve seu aplicativo usando o ACBr. - Implementando novas funções - Criando aplicativos de exemplo - Divulgando o projeto Fique a vontade para perguntar. Abs,

Oi Nelio, Obrigado por apontar essa falha, realmente não tem essa propriedade nem na ACBr32.dll nem no .Net Desculpe minha demora, ... pretendo atualizar o projeto logo, e vou incluir essas propriedades além dos métodos de leitura de memória. Abs,

Isso aí, Como funciona os métodos LeituraMemoriaFiscal ? Ele faz a leitura e retorna algo, ou salva num arquivo em disco?

Ok! Muito bom, vamos lá ... - Os requisitos LMFC, LMFS exite no ACBr, vou implementar as chamadas correspondentes no ACBr32.DLL; - "Espelho MFD" e "Arq. MFD" (!!! corrijam-me, pois não sei se é isso !!!) é para operação com ECFs sem MFD. Esses arquivos vão sendo gerados durante a operação, certo? Se for isso mesmo, vou implementar as chamadas correspondentes que habilitam a geração desses arquivos. - "Movimento por ECF" e "Meios de Pagto" (!!! corrijam-me, agora sei menos ainda !!!) creio que são relatórios que você deverá consultar na base de dados de seu aplicativo e emití-los no ECF utilizando o relatório gerencial. As chamadas de relatório gerencial já estão implementadas no ACBr32.DLL - Assinatura digital: vou incluir o suporte a assinatura digital, mas ainda não sei se utilizo a chamada via ACBr ou se implementamos isso nativamente nas linguagens de destino, pois o .NET e Java possuem formas bem práticas de fazer isso. **** Assim que atualizar o SVN eu posto novidades aqui, Abs,

Olá Nelio, Abri o tópico "PAF-ECF com ACBr32.DLL ..." no fórum veja em viewtopic.php?f=19&t=2839 Basta começar por lá, exponha suas dúvidas e qual requisito do PAF-ECF. Vamos buscar as respostas entre os demais usuários do ACBr e atualizar o ACBr32.DLL se necessário. Abs,

Pessoal, Como todos sabem, o projeto ACBr32.DLL e seus derivados ACBr.Net, jACBr e ACBr ActiveX estão sendo desenvolvidos para permitir o uso do ACBr em outras linguagens e plataformas de desenvolvimento. Esse tópico tem como finalidade ouvir e auxiliar quem utiliza esses projetos na implementação dos requisitos do PAF-ECF, e com isso alcançar um estágio de maturidade e confiabilidade equivalente aos componentes ACBr nativos para Delphi. Exponha suas dúvidas e qual requisito do PAF-ECF. Vamos buscar as respostas entre os demais usuários do ACBr e atualizar o ACBr32.DLL se necessário. Por favor, não esqueça de citar a linguagem de programação/plataforma e o projeto utilizado. Abs,

Opa, vamos trocar opiniões! Eu encorajo você a continuar usando o ACBr.NET em seu projeto, pois comecei a implementar o ACBr.NET justamente para homologar o PAF no aplicativo de automação de minha empresa. Vou contar um pouco da história: Quando comecei a estudar o universo de automação comercial, percebi que as DLLs e APIs fornecidas pelos fabricantes de ECF são uma piada de mal gosto, totalmente inconsistentes e mal documentadas. Assim optei por apoiar o ACBr ao invés de criar e manter uma camada de abstração para suportar 2 ou 3 dos principais fornecedores de ECF. Quase a totalidade do que temos hoje do ACBr32.DLL e do ACBr.NET foi desenvolvido com o tempo da minha empresa, durante o horário de trabalho, como parte do projeto de automação comercial em que eu estava trabalhando. Resultado: Um sucesso! Conseguimos em pouquíssimo tempo e suportar uma gama muito maior de ECFs! Funciona perfeitamente bem! Agora a situação no presente: Homologamos nosso aplicativo no TEF Dedicado (SiTef) usando o ACBr.NET. Não homologamos o PAF ainda, fui alocado em outros projetos e só agora estamos retomando. Tenho total interesse e disponibilidade em fazer o ACBr.NET ter tudo o que for necessário para homologar o PAF; E vou precisar muito de sua ajuda, pois não faço idéia ainda de quais são os itens do "check-list" para ter o menu fiscal funcionando! Só devo me aventurar nisso daqui a uns meses. Sugiro abrirmos aqui um tópico aqui para o "PAF-ECF com ACBr.NET" onde podemos trocar idéias sobre quais os requisitos, e vamos implementado um a um. Que acha?? Abraços!

Boa pergunta, Acho que essa função foi uma das quais não foram implementadas ainda. Vou fazê-la e atualizar o SVN Abs,

Oi Fabrício, Não entendi direito a situação, mas deixa eu tentar: Acho que você não está conseguindo debugar o componente ACBr.NET, não é? Verifique se a compilação está em "Debug" ao invés de "Release", e existe uma diretiva "Inserir informações de DEBUG" na propriedade do projeto, verifique ela também. E por último, veja se o aplicativo host está referenciando corretamente o projeto do ACBr.NET. Abs,

Para boletos, um bom projeto opensource e bem completo é o Boleto.NET http://boletonet.codeplex.com Aqui em nossa empresa não usamos ele, nós desenvolvemos nosso próprio componente há alguns anos atrás (quando existiam poucas opções para .net). Atualmente existem vários, inclusive pagos. Sempre dou preferência a projetos OpenSource com atividade séria e constante, se fosse usar um componente, usaria este. A NFE não conheço para indicar, mas como disse está em meus planos implementá-la no ACBr.NET Abs,

Bom dia Thiago! O ACBr é muito mais completo que o ACBr32.DLL e o ACBr.Net. Os componentes de UI como o de validação e de boleto fogem do escopo da DLL e não estarão disponíveis (mas existem outras alternativas no ambiente .NET para isso). A nfe, temos planos para suportá-la em breve. Atualmente temos suporte completo apenas ao ECF e a Balança; Abraços,

Hehehe, Você não sabe xongas, e eu não sei milongas!!! Vergonhoso, admito, mas só sei o básico de object pascal e da IDE do Delphi. Mas você está certo, não há $DEFINE em lugar nenhum do código, esses defines são feitos nas propriedades do projeto (em Delphi), e admito (vergonhoso novamente), eu não achei a tela equivalente na IDE do Lazarus. O que precisa fazer é remover o STDCALL dos defines e colocar o CDECL em seu lugar. Quer que eu compile a DLL em CDECL e te envie em quanto isso? Daniel, pode nos ajudar com o Lazarus? Abs!

Ooops, Vou dar uma olhada nisso, deve esta havendo algum probleminha ao converter a data/hora retornada do formato do Delphi pro Java .... Por hora, tente subtratir 1600 anos da data .. é um workarround meio bizarro, mas vai funcionar (E sim, o jACBr existe sim!!!) Abs!

Oi Lindenberg, Isso só ocorre com a LeituraX ou com todos os métodos? Abs,

Oi Fabrício, Cara, a ACBrDLL possui os defines pra compilar tanto em STDCALL quanto em CDECL. No Delphi, na propriedade do projeto vc coloca os defines usados na compilação. Até agora estamos fazendo assim: A compilação "default" é em CDECL pra funcionar mais facilmente para criar o .lib (a biblioteca de vínculo estático, usada pra compilar os programas em C; Não confundir com a .lib usada em linux) Funcionaria em STDCALL, mas a diferença básica entre um método de chamada e o outro, é que o STDCALL deixa a cargo da linguagem que fez a chamada realizar a limpeza da pilha de memória dos parâmetros usados, enquanto a CDECL deixa a cargo da DLL fazer isso. Pra usar STDCALL teria que fazer um trabalhinho extra em colocar e manter o tamanho dos parâmetros na definição da .lib. Até onde eu sei o Delphi não compila uma .lib, então esse processo de criá-la é bem manual. Como tenho planos em compilar ela pra linux e rodar em Java e Mono, acho que o CDECL vai ser o caminho mais natural, acho que o linux não suporta o STDCALL. O VB6, FOXPRO, e outras linguagens não fazem chamadas em CDECL, aí temos que manter uma versão da DLL em STDCALL pra elas. **** No seu caso, é só colocar o CDECL nos defines do projeto e compilar, mantendo o CDECL no C#. Qualquer dúvida, estamos aí. Abs,

Oi Wilson, Verifique a declaração da API e o tipo de dados utilizado como parâmetro, pois esses métodos que retornam Double e Date possuem um parâmetro byRef Double (64bits na maioria das linguagens, inclusive no VB6). Fico aguardando seu código.

Oi Wilson, Eu uso o projeto no Delphi 6, mas tem um projeto Lazarus também; Não posso te ajudar muito quanto a isso. Pascal eu até sei pro gasto, mas não sou familiarizado com a IDE do delphi, Só sei mesmo abrir o projeto e compilar Quanto às declarações: DllImport int ECF_GetUltimoErro(const ACBR_HANDLE ecfHandle, PCHAR buffer, const int bufferLen); Sempre que for "const" utilize ByVal no VB6, o resto é ByRef. O tipo String no VB6 deve sempre ser ByVal, mesmo que não seja "const" O tipo Integer é Long no VB6. Ficaria assim: Public Declare Function ECF_GetUltimoErro Lib "ACBr32" (ByVal ecfHandle As Long, ByVal buffer As String, ByVal bufferLen As Long) As Long *** Mas tem um probleminha: A ACBr32.DLL é compilada em cdecl (tem um post sobre isso no arquivo do fórum). O VB6 só funciona com DLL stdcall ... pra resolver isso, o projeto em Delphi tem um DEFINE que compila num ou noutro modo. Portanto se você usar a mesma DLL do projeto C/C++, ACBr.NET ou jACBr, o VB6 vai reclamar. Utilize a versão em anexo aqui. *** E vou te passar em anexo um pedaço do projeto em VB6 que estou fazendo; Vamos juntar o que temos que anda mais rápido. Abra o projeto ACBr.vbg que contém o OCX e um Form de teste; Não está concluído ainda mas já tem o caminho iniciado. Qualquer coisa, diga aí o que achou. Abs, ACBr_ActiveX.zip

Mil desculpas, houve algum problema com minha senha do sourceforge (resetaram ela devido ao evento mundial do resete sua senha ... ahhh, e pra ajudar o email que eu tenho cadastro lá não está mais ativo ... ahhh2), por isso não consegui fazer o checkin e acabei não dando retorno aqui no fórum também. Mas segue em anexo o ACBr.h atualizado. Estou desenvolvendo o exemplo em VB, que será composto de um componente OCX e um exemplo. Acho que em Access o componente OCX pode ser interessante. Vou tentar postar alguma coisa funcionando o mais breve. Abs, ACBr_H.zip

Oi Wilson, Acabo de atualizar o ACBr.h no SVN com as definições da balança. São as declarações iniciadas por "BAL_". Não incluí o LCB porque está incompleto ainda, como em meu aplicativo eu uso LCB via teclado, acabei não terminando ele. O jACBr está no mesmo pé, sem suporte ao BAL_ e ao LCB_, vou trabalhar nisso assim que houver necessidade. Me dê mais detalhes de como vc está usando a DLL, será legal trocarmos essa experiência.

Oi Wilson, Será um prazer ajudar; Vou aprontar um exemplo e atualizar o projeto. Assim que estiver pronto eu posto aqui. Abs.

Boa noite, Me explica melhor qual chamada vc está fazendo e qual linguagem está utilizando ... Mas acho que o problema todo é que o modelo_ecf espera uma constante que identifica o modelo, e não uma string. Experimente passar conforme as constantes abaixo: ECF_Modelo_Nenhum 0 ECF_Modelo_NaoFiscal 1 ECF_Modelo_Bematech 2 ECF_Modelo_Sweda 3 ECF_Modelo_Daruma 4 ECF_Modelo_Schalter 5 ECF_Modelo_Mecaf 6 ECF_Modelo_Yanco 7 ECF_Modelo_DataRegis 8 ECF_Modelo_Urano 9 ECF_Modelo_ICash 10 ECF_Modelo_Quattro 11 ECF_Modelo_FiscNET 12 ECF_Modelo_Epson 13 ECF_Modelo_NCR 14 ECF_Modelo_SwedaSTX 15 No seu caso, utilize 4 Abs

Boa noite! Você pode baixar o projeto pelo SVN; Na pasta Projetos\ACBr32_DLL você encontrará a DLL compilada e exemplos para .NET, Java, C/C++ e FoxPro. Qualquer dúvida, estamos aí. Abs

Oi Endrigo, Bem, não tivemos ainda planos de suportar o NFe e DANFE no ACBr32. Por enquanto apenas os ECFs, Balança e LCB são suportados. Vou dar uma olhada pra ver se é viável. Sobre o limite de 26 parâmetros, você não teria o mesmo problema usando ActiveX? Talvez o ACBrMonitor seja uma boa saída para vc, pois a interface é feita com arquivo TXT, sem esse limite. Abs,