Rafael Batiati

Oi Marcelo, O problema basicamente é que o .Net não permite você manipular controles de interface gráfica a partir de outra Thread. No seu caso, não seria possível alterar o Text do Label a partir do evento, pois o evento roda numa thread diferente do Form. Para tanto seria necessário usar o Form.Invoke/Form.BeginInvoke. (...) Para resolver isso, eu alterei o código do ACBrFramework.Net para disparar os eventos sempre na thread do controle que declara os eventos. Assim vai funcionar na maioria dos casos. Baixe a última versão que terá essas modificações aplicadas. (...) Percebi também que o UltimoCódigo retorna uma string vazia, e a propriedade UltimaLeitura é que retorna a string preenchida. Alguém sabe a diferença entre elas?

Ah, além de estar usando a mesma porta do ACBR, o seu emulador está em MIT (Modo de intervenção Técnica) ... cuidado pois várias coisas não vão funcionar corretamente. Desative o MIT antes.

Oi Diogenes, No seu caso, vc criou a COM2 <-> COM3, ou seja, o ACBr deve abrir a porta COM2 e o Emulador Sweda a COM3. Vi no seu screenshot que ambos estão abrindo a COM3, assim dá acesso negado a um dos dois. Abs!

Alô pessoal, A coisa funciona assim: Sempre precisamos chamar o método GetDadosReducaoZ() ou GetDadosUltimaReducaoZ() antes de chamar o GetDadosReducaoZClass(); Nem todos os ECFs suportam o GetDadosUltimaReduçãoZ() ... Eu utilizo o GetDadosReducaoZ() logo após antes de emitir a ReducaoZ(), e os contadores são preenchidos normalmente. ATUALIZAÇÃO: (28/02/2012) 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. *** O pessoal do ACBr lançou uma alteração ontem, que vai nos interessar bastante. Segue o changelog abaixo, vou implementar isso no ACBrFramework assim que possível. Data: 20/11/2012 -- ACBrECF -- (por: DSA) [*] Refactoring em método: GetDadosReducaoZ e MontaDadosReducaoZ -- ACBrECFClass -- (por: DSA) [*] Refactoring em método: GetDadosReducaoZ e MontaDadosReducaoZ [*] Classe TACBrECFDadosRZ modificada para conter o método MontaDadosReducaoZ [-] Método TACBrECFDadosRZ.MontaDadosReducaoZ, modificado para montar .INI apenas com as variaveis que foram realmente informadas (eliminando problema de registradores zerados) [+] Inserido método TACBrECFDadosRZ.CalculaValoresVirtuais para calcular valores que não tenham sido retornado pelo ECF como: TotalOperacaoNaoFiscal, TotalICMS, TotalISSQN, ValorVendaBruta, VendaLiquida Abs,

Oi Marcelo, O TEFD do ACBrFramework.Net ficou pronto sim, e suporta o TEF Attuar via troca de arquivos, assim como o ACBr. Para configurar as pastas dos arquivos, você deverá acessar as propriedades do attuar, por exemplo: acbrTefd.TEFAttuar.ArqReq = @"c:\auttar_tefip"; Qualquer dúvida, é só postar. Abs

Baixa a versão pelo SVN, lá em ACBrFramework.OCX tem o módulo ACBrBAL.pas que contém as declarações de funções pro VB6. Mas não foram implementadas em um componente ainda, como é o ECF. Se você quiser fazê-lo, pode contar com a gente pra qualquer esclarecimento. E não esqueça de depois postar o código-fonte aqui pra atualizarmos o SVN. Abs!!!

Amigos, Temos a satisfação em apresentar o novo componente ACBrTEFD implementado no ACBrFramework.Net! Agora já é possível utilizá-lo na plataforma .Net, com todos os eventos e características disponíveis na versão delphi dos componentes ACBr. Baixem pelo SVN a última versão, lá temos também o projeto TEFDDemo muito completo exemplificando como utilizar o componente em conjunto com o ECF. O comportamento do componente ACBrTEF e o projeto TEFDDemo foram inteiramente espelhados nos componentes ACBr originais, portanto qualquer dúvida sobre seu funcionamento, o Wiki e o fórum sobre o TEFD será um valioso material de pesquisa. Veja abaixo o TEF rodando com o emulador da Sweda e o Pay&Go: (...) Outra grande novidade que temos é a criação da página do ACBrFramework http://acbrframework.sourceforge.net O objetivo dessa página é centralizar os downloads e informações específicas sobre nosso projeto. Lá é possível encontrar downloads das últimas versões estáveis sem precisar baixar pelo SVN. Essa página é apenas para termos um ponto central de divulgação do projeto, todos os outros recursos como Fórum, Repositório de SVN, Wiki e etc continuam no mesmo lugar, sob o projeto ACBr. Não deixem de conferir e postar aqui sugestões, críticas, dúvidas, bug reports e o que mais quiserem! Grande abraço. Equipe ACBrFramework http://acbrframework.sourceforge.net

Desculpa, não fui claro ... Acho que o ACBr não possui a implementação do método cancelaItemVendidoParcial para o Ecf EPSON. Poderia confirmar isso pra gente?

Exatamente, só isso que deve fazer! É realmente simples, não acha? Essa função é simples, não tem argumentos nem retorno. Fique atento a funções mais complexas que trabalham com string e outros objetos que precisam ser removidos da memória. Sempre procure uma função semelhante já implementada pra tomar como modelo. E não se esqueça de detalhar num TXT as coisas que você implementou, pra depois nós atualizarmos o SVN. Abs!

Nesse caso, acho que o próprio componente ACBr não possui a implementação para a EPSON. Precisamos verificar isso.

Excelente, vamos lá a sua pergunta: Ok, essa classe é sua aplicação, que na prática vai ser uma janela do seu PDV ou outra coisa parecida. Agora vamos ao jACBrFramework: Sim, sua aplicação está chamando o método abreCupom() que no jACBrFramework possui um override que chama o método nativo abreCupom(cpfCnpj, nome, endereco) que não possui implementação, há apenas a declaração do que será feito via JNI, assim: public native void abreCupom(String cpfCnpj, String nome, String endereco) throws ACBrException; Esse método nativo carrega o ACBrFramework_JNI.dll feito em C++, que chama a seguinte função: JNIEXPORT void JNICALL Java_jACBrFramework_ACBrECF_abreCupom(JNIEnv *env, jobject obj, jstring cpfCnpj, jstring nome, jstring endereco); Essa chamada ao JNI é feita por convenção de nomes, onde o nome da função precisa ser Java___(JNIEnv *env, jobject obj, ); Se o nome estiver diferente, ou os argumentos incorretos, não funciona... rsrsrs O C funciona com o arquivo de header (.h) que contém apenas a declaração das funções, e o arquivo .cpp (ou .c) que contém a implementação. Assim, o JACBrECF.h e o JACBrECF.cpp são declaração e implementação das funções JNI do ECF. é a implementação da função Java_jACBrFramework_ACBrECF_abreCupom que fica no JACBrECF.cpp que chama o ACBrFramework32.dll, utilizando o arquivo ACBrECF.h que contém as declarações das funções que existem no ACBrFramework32.dll; Assim: JNIEXPORT void JNICALL Java_jACBrFramework_ACBrECF_abreCupom(JNIEnv *env, jobject obj, jstring cpfCnpj, jstring nome, jstring endereco) { INTPTR handle = GetACBrHandle(env, obj); jboolean isCopy = (jboolean)false; const char* nCpfCnpj = env->GetStringUTFChars(cpfCnpj, &isCopy); const char* nNome = env->GetStringUTFChars(nome, &isCopy); const char* nEndereco = env->GetStringUTFChars(endereco, &isCopy); //CHAMADA DA FUNÇÃO DECLARADA NO ACBrECF.h e IMPLEMENTADA PELA ACBrFramework32.dll int ret = ECF_AbreCupom(handle, (PCHAR)nCpfCnpj, (PCHAR)nNome, (PCHAR)nEndereco); env->ReleaseStringUTFChars(cpfCnpj, nCpfCnpj); env->ReleaseStringUTFChars(nome, nNome); env->ReleaseStringUTFChars(endereco, nEndereco); CheckResult(env, handle, ret); } Note no código acima a chamada a função ECF_AbreCupom que foi implementada em Delphi, usando diretamente o componente ACBr. É mais ou menos isso. Abs!

Legal, vejo que estamos indo bem! Vamos lá: Você precisa setar o caminho do seu JDK, onde fica instalado o Java. O compilador vai usar o jni.h e o linker vai usar o jvm.lib No VS fica assim: Vá em propriedades do projeto, clique em "C/C++" e indique o caminho do include Depois clique em "Linker", "Input" e indique o caminho do jvm.lib Esses arquivos ficam sempre no diretório de instalação do JDK. (...) Sim, você pode compilar em 64bits; Mas note que pra fazer isso, você precisará referenciar a lib 64bits e o ACBrFramework64.dll. No Java, também será necessário carregar o JNI correto, dependendo da plataforma, hoje é feito somente isso: //Carrega a biblioteca de chamadas nativas JNI System.loadLibrary("ACBrFramework_JNI"); Java 7 vai funcionar, qualquer versão igual ou superior ao JDK que você usou pra compilar o JNI vai funcionar. (...) As funções disponíveis no ACBrFramework estão todas declaradas nos arquivos .h. Enquanto na DLL as funções são estáticas, na classe Java temos os métodos declarados da forma OO, como classes que modelam o comportamento dos componentes o mais próximo possível do ACBr Delphi, para que possamos nos beneficiar dos exemplos, foruns, documentações, etc. O jACBrFramework só faz chamadas ao que está implementado no JNI, que por sua vez foi exposto do componente ACBr. (...) Revisei os posts antigos, e não tem código-fonte em anexo. Mas eu convido todos vocês interessados a participar aqui do fórum, e da evolução do jACBrFramework. Estou disponível para ajudar sempre. Abs!

Fechou então, Se está aqui no fórum deve ter um anexo também. Eu devo ter dado mole e não atualizado o SVN. Vou dar uma olhada nisso. (...) O JNI não é complicado, na verdade a implementação dos componentes é uma inversão do que é feito nas outras linguagens; Em C# por exemplo, nós declaramos só a assinatura da função nativa e implementamos toda sua chamada na classe em C#. No JNI nós temos que implementar tudo isso em C/C++ e no Java declaramos apenas sua assinatura. É um trabalho bem equivalente, mas depende apenas da facilidade que o programador tiver com cada linguagem. Se você seguir o que já tem implementado como modelo fica fácil de fazer a maioria das funções. Vou implementar o disparo de evento na classe Java pra servir de modelo também. Se você tiver dúvida sobre alguma coisa é só postar aqui. O projeto foi feito em Microsoft Visual C++, mas pode ser compilado em gcc, C++ Builder ou qualquer outro. Abs!

Bom dia! Pegue a última versão do projeto jACBrFramework, vai solucionar o problema de falha. Nós trocamos o namespace do projeto e não atualizamos em alguns pontos do JNI ... agora tá correto. (...) Eu conferi os métodos implementados no jACBrFramework, e realmente não constam os métodos acima que você listou. Pode me confirmar se a versão da T2Ti possui esses métodos implementados? Caso positivo, vou entrar em contato com eles para ver se gostariam de colaborar com o projeto, ao invés de desenvolver uma versão isolada. (...) Chegou a olhar o código do JNI? O que achou? Qualquer dúvida, fique a vontade. Abs.

Alô, boa noite!!! Sim, eu conheço o trabalho do pessoal da T2Ti, só que eles utilizam uma versão bem antiga do jACBr Aliás, nós mudamos de nome, agora é jACBrFramework e a implementação nativa é feita pelo ACBrFramework_JNI. Esse projeto ACBrFramework_JNI é escrito em C++ utilizando as interfaces nativas do Java (JNI) para fazer a comunicação entre a DLL e o Java. Como nós não temos colaboradores em Java, com o passar do tempo a versão .Net do ACBrFramework teve muitos mais recursos implementados que a versão Java. Você pode começar baixando a última versão do projeto pelo SVN e dando uma olhada geral. Nosso repositório mudou também, está em https://acbr.svn.sourceforge.net/svnroo ... rFramework *** É possível sim implementar o JNI usando Lazarus. Só que dentro do JDK só tem disponível as libs e .h para uso em C/C++, mas há uma forma de fazer o mesmo usando Lazarus. http://javafree.uol.com.br/artigo/87149 ... elphi.html Nós fizemos o JNI em C++ pois temos mais familiaridade com C++ e podemos usar as interfaces padrão de qualquer JDK. *** Dê uma olhada em tudo, e poste aqui pra nós qualquer dúvida ou intenção que tenha de implementar algo. Teremos o maior prazer em ajudar a tocar o jACBrFramework pra frente! Abs!

Oi Jackson, usando o ACBrFramework (agora nós mudamos de nome, não é mais ACBr32), o acesso é feito como nos componentes ACBr, ou seja, comunicação direta ao ECF, sem o ACBrMonitor e sem a DLL do fabricante também. O nosso projeto tem crescido bastante, a já temos implementado outros componentes além do ECF, como o BAL, AAC, PAF, EAD, Sintegra, e outro ainda virão. Mas todo esse crescimento deixou as outras linguagens que suportamos em grande defasagem, pois nos dedicamos principalmente ao .Net, e muitas vezes não sobra tempo de atualizar os exemplos. Portanto, gostariamos SIM de toda a ajuda possível para podermos manter o projeto também para outras linguagens. Leias os últimos posts desse tópico, e veja se você tem alguma sugestão. Se tiver exemplos de código das chamadas da DLL em sua linguagem, podemos fazer um Export das chamadas já implementadas pra você testar. Teremos muitos ajustes a fazer, Abs!

http://www.djsystem.com.br/index.php/pr ... gorised/16 Lá você poderá contratar o SAC. Abs!

Use o campo ECF.MFAdicional Ele retorna o campo a ser preenchido nesse registro. Abs!

oi, experimenta usar o GetDadosReducaoZ, para retornar a redução que você acabou de fazer. acbrECF.ReducaoZ(); acbrECF.GetDadosReducaoZ (); var reducaoZ = acbrECF.GetDadosReducaoZClass(); Eu testei o GetDadosUltimaReducaoZ e este realmente veio vazio. Mas é o comportamento do ACBr mesmo. Não sei se é porque o ECF não teve ainda um documento impresso após a redução Z. Abs,

Cara, mil desculpas ... você tem toda a razão Eu ainda tenho muito a aprender sobre o ACBr!!! Bem, agora que nós já temos suporte a Eventos como no Delphi, e o evento ACBrECF.BobinaAdicionaLinhas poderá ser implementado sem problemas no ACBrFramework.Net!!! Eu posto aqui quando estiver disponível. Abs!!!

Oi André, Mostrar na tela o cupom fiscal foge da proposta do ACBr. Nesse caso isso é uma particularidade que o software de AC deve implementar da forma que desejar ... Mas em outra mão, o ACBr suporta um tipo de ecf "não fiscal" que permite escrever num arquivo de texto um layout muito parecido com um cupom fiscal. Você poderia comandar duas instância do ACBrECF, uma manipulando o ECF real, e outra escrevendo em arquivo texto. Dessa forma você poderia exibir o conteúdo desse TXT na tela. Não sei se ia ficar muito bom, é só uma idéia... Abs!

Alô pessoal, Temos algumas grandes novidades no projeto ACBrFramework! 1 - Agora temos suporte a Eventos! Isso mesmo, disparo de eventos são suportados nos componentes ACBrFramework.Net da mesma forma que nos componentes ACBr em Delphi. Isso nos dá excelentes possibilidades, pois poderemos portar componentes como o ACBrTEFD e outros que fazem uso intenso de eventos! Pra começar, implementamos os eventos OnPoucoPapel do ACBrECF, OnGetChavePublicae OnGetChavePrivada do ACBrEAD e ACBrAAC e os eventos OnLePeso do ACBrBAL. 2 - Instalador do ACBrFramework.Net Baixe o pacote de instalação abaixo: ACBrFramework.Net Install.rar O pacote é auto-instalável e já cria o toolbox no Visual Studio com os componentes do ACBrFramework. Só clicar e usar! Ou baixe via Nuget http://nuget.org/packages/ACBrFramework Obs: Via Nuget não instala na Toolbox. Estamos aí, fiquem a vontade pra qualquer dúvida, sugestão ou bate-papo! Abs, ACBrFramework.Net Install.rar

Não mudou, continua do mesmo jeito. Mas novas funções foram acrescentadas. As funções que recebem Inteiros, Strings, etc são fáceis de resolver. O problema são as funções que recebem estruturas de dados contendo vários campos, arrays, etc. Essas eu não sei qual a forma correta de chamar em Harbour/xBase. Veja alguns exemplos abaixo: A função ECF_GetPorta Function ECF_GetPorta(const ecfHandle: PECFHandle; Buffer : pChar; const BufferLen : Integer) : Integer Pode ser facilmente chamada em Harbour/xBase assim: NDLL:=Dllload("ACBrFramework32.dll") nRetorno:=DLLCALL(NDLL,32,"ECF_GetPorta", iECFHandle, @porta) Agora, uma função mais complexa, como ECF_GetComprovanteNaoFiscal eu não sei como chamar no Harbour/xBase: type TComprovanteNaoFiscalRec = record Indice : array[0..3] of char; Descricao : array[0..29] of char; PermiteVinculado : Boolean; FormaPagamento : array[0..3] of char; Total : Double ; Contador : Integer; end; Function ECF_GetComprovanteNaoFiscal(const ecfHandle: PECFHandle; var retComprovanteNaoFiscal : TComprovanteNaoFiscalRec; const index : Integer) : Integer A dúvida que tenho é como vamos fazer para declarar e passar um tipo complexo como TComprovanteNaoFiscalRec no Harbour/xBase. Nesse ponto é que preciso de ajuda dos especialistas nessa linguagem. ********** Pensamos em criar métodos alternativos que retornam/recebem essas informações complexas como strings, aí no Harbour/xBase o programador deveria pegar a substring de cada campo. Além dessa abordagem nos dar um bom trabalho de duplicar certas funções fazendo a transformação dos argumentos em strings, não sabemos se seria a forma mais fácil de se fazer esse trabalho em Harbour/xBase. Dicas? Sugestões? Comentários? Abs!

Alô! lucimauro Obrigado por sua paciência!!! Cara, como vc deve saber, o ACBr.Dll mudou pra ACBrFramework. Estamos trabalhando num projeto chamado DefExporter pra ele, esse DefExporter vai exportar todas as declarações da DLL pra C/C++, VB6 e xBase (Harbour, Clipper, FoxPro, etc) .... Isso vai nos poupar do trabalho de ficar atualizando as declarações toda vez que algo novo é implementado. Pra C/C++ e VB6 tá funcionando que é uma maravilha, mas pra xBase/Harbour tá difícil. Por isso eu venho aqui pedir a ajuda da galera que usa e conhece essa linguagem: 1 - Em algumas funções, precisamos passar um estrutura de dados (como uma classe com alguns campos, tipo uma Aliquota do ECF por exemplo). Como é que vocês fazem isso em xBase/Harbour? Achei esse doc, mas acho que deve ter jeito mais fácil: http://msdn.microsoft.com/en-us/library ... h5(v=vs.80).aspx 2 - Idem ao 1, algumas funções passam e recebem Arrays ... como se faz isso? 3 - Tem alguma diferença ou incompatibilidade entre a forma de usar em Harbour e em xBase ? Agradeço toda ajuda e palpites! Abs!

Opa, boa noite! Estamos com o ACBrFramework.Net a todo vapor, ele é feito em C# e serve a qualquer linguagem .Net. Já temos ECF, Balança, LCB, PAF, AAC e EAD implementados. Estamos trabalhando em Sintegra e Sped no momento. Nosso objetivo é ter sempre o ACBrFramework em paridade de funções com o ACBr, e principalmente reproduzindo a mesma API e os mesmos comportamentos, assim um fórum serve pra todos. Para outras linguagens temos o jACBrFramework, que foi bem iniciado e serve como base pra quem quiser levá-lo adiante. Está parado mas tem boa parte do ECF implementado e funcionando. E o ACBrFramework.OCX feito em VB, é um componente ActiveX, tá no mesmo pé do projeto em Java, esperando alguém com o "sopro-da-vida" hehehe! Seja bem vindo, e sinta-se em casa. Pode baixar o projeto e se quiser colaborar com algo, poste seu código aqui que nós avaliamos e mandamos ver pro SVN! Grande abraço.