Rafael Batiati

Código do ACBr e ACBrFramework C# atualizado com a propriedade Margem na classe ConfigBarras
 
Lembrando que só foi implementado para os ECFs Bematech
 
Observações importantes:
 
Segundo o manual, cada unidade equivale a 0.125mm de espaçamento
 
A margem necessária para centralizar o código de barras vai depender do tamanho e do tipo de código utilizado; é necessário testar cada caso para determinar a margem mais adequada.
 
Quando a propriedade "ConfigBarras.MostrarCodigo" é definida como True, o texto numérico impresso acima ou abaixo do código de barras não segue o alinhamento definido na propriedade Margem; para centralizar o texto é necessário inserir espaços, exemplo:
acbrECF.ConfigBarras.MostrarCodigo = true; acbrECF.ConfigBarras.Margem = 50; acbrECF.LinhaRelatorioGerencial(" <inter>12345678</inter>"); Qualquer coisa é só falar
Abs!

Dessa vez eu não entendi .. rsrs
 
Você estava tentando ou não substituir os códigos do GAS pelo ACBr?
Vc pretente usar a implementação do ACBr do SAT-CFe no GAS?
 
De qualquer forma, fica uma leitura sobre o ACBr e o SAT-CFe
http://anfm.blogspot.com.br/2013/02/acbrsat-primeiros-passos-do-sat-cfe-com.html
 
Abs

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

Bos noite Marcos,
 
Temos um tópico exatamente sobre isso ""

 
Por favor, continue por lá, e evite postar antes de pesquisar, assim mantemos os tópicos mais organizados e fáceis de consultar.
Abs!

Ok, que bom, a JRE parece estar ok agora.
 
Vamos ao outro problema.
Pelo que parece você está usando a jACBr, uma versão ***muito antiga*** do nosso projeto, que agora se chama jACBrFramework.
 
O JNI é muito temperamental com essas coisas, pois se sua ACBrECF está no package jACBr ele procura o método jACBr_ACBrECF_create pra executar. Mas em nossa nova versão, o package foi renomeado para jACBrFramework, e consequentemente no JNI existe agora um método também chamado jACBrFramework_ACBrECF_create.
 
Ou seja, ou você usa o jACBr com a ACBr32.dll e a ACBr_JNI.dll ou você migra para o jACBrFramework e usa a ACBrFramework32.dll e o ACBrFramework_JNI.dll. Pelo que eu vi no seu projeto, você está usando as DLLs novas e o jar antigo.
 
Abs

Bom dia Valdecir,
 
Cara deixa eu tentar te ajudar:
 
1- A ACBr32.dll não existe mais há quase 1 ano.
Esse projeto deu lugar para o ACBrFramework, e não se limita apenas a uma DLL, é um framework completo de alto nível para ser usado em várias linguagens e plataformas.
 
2- Não faz sentido nenhum usar a ACBr32.dll no C#, pois existe o ACBrFramework.Net que é a suite com atualmente 17 componentes do ACBr portados para .Net e com suporte completo a todo a a API (classes, propriedades, métodos, eventos, enums, etc) do ACBr.
 
Dê uma atualizada aí:
 
Saiba mais sobre o ACBrFramework:
http://acbrframework.sourceforge.net
 
Como baixar o código fonte:
http://acbrframework.sourceforge.net/downloads/codigo-fonte/
 
Download compilado:
http://sourceforge.net/projects/acbrframework/files/
 
Abs!

Resposta no outro post, por favor continue por lá:
 

Opa, falha nossa!
O projeto de exemplo ECFTeste foi colocado em modo Console pra .... fazer um teste 
 
Já arrumei, baixe novamente pelo SNV, e fique sossegado a aplicação é um Windows Application nativo sem tela do DOS!
Abs

Pelo visto você atachou o evento com um += ao componente ...  depois fechou o form que declarava o método que foi atachado.
E quando você chama o evento novamente, ele não consegue usar o controle, pois já foi fechado.
 
Você deve fazer o += para atachar o evento, e ao fechar o form, o -= para remover.
Abs

Provavel que seja o caminho dos seus fontes,

Você tem que baixar o conteúdo dos repositórios do ACBr e do ACBrFramework, e colocá-los lado a lado dentro de uma mesma pasta,
ex:
c:\Projetos\ACBr
c:\Projetos\ACBrFramework

Abs!

O setOperador do jACrFramework é o equivalente à propriedade "Operador" do ACBrECF.
Setar essa propriedade apenas faz com que o ECF chame o IdentificaOperador antes de abrir os documentos;
O comportamento vai depender do modelo do ECF que você está usando.

Como o comportamento do jACBrFramework é o mesmo do ACBr, sugiro você dar uma estudada aqui no fórum nos tópicos sobre o componente ACBrECF, tem muita coisa legal lá.

Dá uma lida nesse post:
viewtopic.php?f=10&t=1174&hilit=Operador


Abs,

Valeu LuizPaulo, projeto de demo simples e direto ao ponto!!!

Corrigi o problema nos registros R1 e R2 do PAF, estavam declarados errados no código do ACBrFramework.Net, isso causava o problema.
Baixe a última versão do SVN e confira aí se funcionou.



Não tem de quê pedir desculpas, estamos aí pra contribuir com o projeto mesmo, a ajuda de vocês é importante pois deixa o código cada vez mais estável.
Continuem usando e postando, quanto mais melhor.

Aproveitando o bonde, peço para sempre que possível ao postar já adiantar um demo com o código pra reproduzir o erro, pois isso nos poupa um trabalhão até chegar ao real problema.
Abs!

Oi Marcelo,
Provavelmente algum campo do registro foi setado como nulo,
Para evitar problemas assim, os métodos que enviam as strings para o ACBr foram alterados para permitir trabalhar com valores nulos.
Baixe a última versão do SVN e confira.

Mas verifique também seu código, pois se o campo for realmente requerido para a operação, você poderá receber outra exception vinda dos componentes ACBr.
Abs,

Por favor, não faça a mesma pergunta em vários tópicos.
Respondido no outro tópico

viewtopic.php?f=19&t=8070&start=20#p45595

Opa, que bom, gosto de ver a comunidade Java na ativa !!! heheehe
Vamos lá ...



Eu não entendi sua pergunta.
Tenta me esclarecer: O cupom vinculado é pra imprimir o texto retornado pelo TEF?
Se for eu acredito que não terá diferença pra você se o pagamento for em 1 ou 12 parcelas, uma vez que no ECF haverá apenas 1 pagamento registrado, e essa informação de parcelamento vai constar apenas no texto retornado pelo TEF, sem interferência sua.

Fico no aguardo...
abs!

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?

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

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.

Ok, pela seu printscreen, vc definiu a porta do exemplo como COM6, e o emulador de ECF como COM5, certo?
Não é necessário ter o Delphi pra rodar, a DLL é nativa e não tem dependências.

Não entendi como vc quer definir a porta no ACBr?
No código em java, usa-se ACBrECF ecf = new ACBrECF(); e depois ecf.setPorta("COM6");
No exemplo, o prompt pergunta a porta do ECF, basta digitar COM6 mesmo.



Eu já passei por problema parecido com o emulador de porta. O comando "abre cupom" é enviado mas o emulador não responde, nem executa nem dá erro. Depois o próximo comando falha com a mensagem "comando não executado".
Como eu disse, passei por isso numa máq Win7 64bits, usando o Free VirtualSerialPort; Consegui reproduzir o mesmo erro usando o ECFTeste.exe do ACBrMonitor. Com a impressora real funcionou normalmente, por isso constatei que o problema deveria ser do emulador de portas no Win7 64.

Como vc está dizendo que seu windows é 32bits, não sei ao certo o que pode ser.
Faz um teste com o ECFTeste.exe; basta baixar o ACBrMonitor e executar esse utilitário que está dentro da pasta do ACBrMonitor; Lá vc encontra "Testar cupom fiscal" que faz exatamente o que esse nosso exemplo faz: abre o cupom e vende alguns itens.

Abs,