eliziorezende

Já descobri o problema Daniel. Nós utilizamos o jACBrFramework e ele está desatualizado, o método cancelaCupom não estava passando o número do cupom. Modificamos ele para passar o número 0 e funcionou perfeitamente. Obrigado.

Boa tarde Daniel, No ECFTeste o erro não acontece, mas você poderia nos dar uma luz? Estamos utilizando o trunk2 e nos dois casos chamamos o mesmo método para cancelar o cupom e o erro só acontece com cupom fechado. Abs

Boa noite pessoal. Não estamos conseguindo cancelar uma venda fechada na impressora Bematech MP-4200 TH FI II SB 01.00.02 O mais estranho é que o erro só ocorre com cupom fiscal fechado, se a venda estiver aberta, o cancelamento ocorre sem erros. E nos dois cancelamentos chamamos o mesmo método cancelaCupom. O erro é ----------------- ERRO ----------------- Erro retornado pela Impressora: BEMATECH Categoria: 2-Erro em parâmetro do comando Motivo: 2-Falta parâmetro no comando ---------------------------------------- A porta já está configurada em 115.200 e utilizando EcfEscECF Segue em anexo o log completo do erro. Qualquer ajuda será bem vinda. Abs logerro.txt

Sim, nós alteramos o jAcbrFramework para passar os parâmetros necessários para o cancelamento de desconto/acréscimo e também alteramos o projeto em lazarus implementando a função para a bematech. Como temos o PDV java, afetou os dois projetos.

Nós fizemos a alteração na última versão do trunk2 para a bematech, assim como umas mudanças no jacbr para a homologação. Quer que enviemos os códigos?

Boa tarde, Estou utilizando o Acbr com o modelo EscECF com a impressora fiscal Bematech MP-4200 TH FI II (USB). Quando faço a redução Z e chamo o método getDataHoraUltimaReducaoZ ele me retorna a data 1899/12/31 00:00:00 Alguém sabe o que pode estar ocorrendo ou passou por esse problema? Att,

Nesse caso estou apenas carregando a DLL, antes de usá-la acontece esse problema. Para carregar estamos utilizando System.loadLibrary("ACBrFramework32"); Att,

Fizemos o teste sim, mas não obtivemos sucesso. A questão do xms não creio que seja o problema, pois o xms é o tamanho do pool inicial de memória e o xmx seria o limite de alocação dessa memória. Ele vai alocando a medida que vai precisando. Mas realmente ainda não atualizamos para a versão 8 do java e nem verificamos a questão de antivirus. Vamos tentar essas opções por via das dúvidas, pois estamos sem mais alternativas.

Bom dia, Sim, inclusive quando volto o Acbr do trunk1 ele funciona normalmente. Sim, tentei com a DLL do repositório trunk2 e também gerei uma nova através do Lazarus, as duas opções deram o mesmo resultado. Att,

Bom dia, Para gravar log é só informar o caminho do arquivo de log através do método ACBrECF.setArqLOG(caminhoAbsoluto); Sim, todas as minhas dlls estão atualizadas, inclusive o ACBrFramework32.dll nós fizemos algumas modificações para a homologação. Por que retirar a DLL do system32 mudaria o cenário atual? Não seria correto deixar a dll no system32 ou syswow64? Por que a alteração do xms para 1024 teria algum efeito? Atenciosamente,

Boa tarde, Estávamos utilizando o trunk1 sem problemas, mas estamos migrando o nosso projeto para o trunk 2 e ao tentar carregar a bilbioteca AcbrFramework32.dll, acontece o erro abaixo, alguém poderia nos ajudar? Essa máquina tem 16GB de RAM. Acredito que memória não seja o problema. Mesmo recompilando o Acbr no trunk2 acontece o mesmo erro. A linha que dispara o erro é System.loadLibrary("ACBrFramework32"); An unhandled exception occurred at $49F8CB6A : EOutOfMemory : Out of memory $49F8CB6A java.lang.UnsatisfiedLinkError: C:\Windows\System32\ACBrFramework32.dll: Uma rotina de inicialização da biblioteca de vínculo dinâmico (DLL) falhou at java.lang.ClassLoader$NativeLibrary.load(Native Method) at java.lang.ClassLoader.loadLibrary1(ClassLoader.java:1965) at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1890) at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1880) at java.lang.Runtime.loadLibrary0(Runtime.java:849) at java.lang.System.loadLibrary(System.java:1088) at com.t2tierp.pafecf.view.Caixa.iniciaConfiguracaoImpressoraFiscal(Caixa.java:786) at com.t2tierp.pafecf.view.Caixa.<init>(Caixa.java:282) at com.t2tierp.pafecf.view.Caixa$40.run(Caixa.java:2386) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:312) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:745) at java.awt.EventQueue.access$300(EventQueue.java:103) at java.awt.EventQueue$3.run(EventQueue.java:706) at java.awt.EventQueue$3.run(EventQueue.java:704) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:76) at java.awt.EventQueue.dispatchEvent(EventQueue.java:715) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:242) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:161) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:150) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:146) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:138) at java.awt.EventDispatchThread.run(EventDispatchThread.java:91)

Bom dia. Em um de nossos clientes está ocorrendo um erro intermitente do AcbrEcf no método getEstado(). Esse erro ocorre em média de dois em dois dias. Alguém poderia nos ajudar? Ele dispara o erro e sai do sistema. Segue o log do Acbr e o Log do AccessViolation. hs_err_pid2068.log logacbr (2).txt

O cancelamento de desconto/acréscimo no item não estava implementado para a impressora bematech. Nós adicionamos essa implementação para a bematech, na Daruma estava funcionando corretamente.

Certo, nós implementamos esse requisito para atender a mudança da lei, então como fazer para contribuir nesse caso que talvez outras pessoas estejam precisando? Se mudar o java e não mudar o Lazarus irá quebrar, pois as classes wrappers mudaram.

Srs., Alguma posição sobre o código enviado? Será adicionado ao projeto? Abs