Rafael Batiati

Bom dia! Sobre qual método/propriedade do componente ACBr você está falando? Há alguns dados (nome, clichê, CNPJ, endereço, etc.) que são definidos no momento do lacre da impressora, e não podem ser mudados posteriormente pela aplicação. Abs,

Perfeitamente Rodrigo! Como trabalhei no ACBr.NET principalmente para homologar o TEF Dedicado, do jeito que está ele tem me atendido, não tive novas necessidades ... Com mais gente usando o projeto, as necessidades surgem e teremos sim mais atividade no projeto! Antes da gente implementar qualquer coisa, acho importante decidirmos o que queremos implementar e dividir as tarefas. Estou bem disposto a trabalhar nisso. Abs,

Ainda não tivemos homologação do PAF; Até agora eu homologuei o TEF Dedicado usando o ACBr.NET, e tenho notícia de mais 1 projeto em C# trabalhando para homologar com o ACBr.NET O sistema de automação que trabalho ainda não foi homologado, mas certamente esse ano de 2012 faremos a homologação. Obrigado, Sinta-se a vontade, nosso ideal é ter a implementação do ACBr.NET "pau-a-pau" com as funcionalidades do ACBr em Delphi! Temos um longo caminho ainda! Abs,

Bom dia Jaime, Por enquanto o ACBr.NET somente suporta os componentes ACBrECF (ECF), ACBrBAL (Balança) e ACBrLCB (Leitor de código de barras); Os demais componentes estão em nosso plano, mas não temos previsão para desenvolve-los. Abs!

Alô, além de colocar a ADBr32.dll junto de seu executável (dentro da pasta bin\Debug ou bin\Release), note o seguinte: A DLL é 32bits, se o seu sistema operacional for de 64bits, vai dar essa falha. Para resolver isso, vá nas propriedades do projeto no Visual Studio e mude o target da compilação de "Any CPU" para "x86". Isso forçará o SO rodar seu aplicativo em modo 32bits e não 64bits nativamente. Abs,

Fala Bruno, boa noite. Recebi a impressora e fiz o teste. Era aquilo mesmo: O ACBr.Net na versão que vc deve estar usando só conecta na pora COM a 9600. Colocando pra 115200 e funcionou corretamente. Vou checar se a última versão está o SVN, e atualizo caso necessário. Abs,

Fala Bruno, Estranho mesmo, pois até no seu teste pelo emulador conectou, e pela impressora não. Há uma nova versão onde é possível configurar além do baudrate, a paridade e stopbits. Talvez seja isso. Vou ver se atualizo no SVN essa versão e vc testa novamente.

Eu só notei esses problemas usando o Lazarus: - A DLL compilada é bem maior em Lazarus que compilando no Delphi. - Tive problema com o ACBrBAL, o aplicativo dava pau ao abrir a balança. Não tive tempo de ver isso ainda, a minha DLL de produção é compilada em Delphi ainda. Abs,

Fala Bruno, Testei usando o emulador de ECF FiscNet da Urano, que é compatível com todos os modelos FiscNET (Urano, Elgin, ZPM, Olivetti, TermoPrinter, etc) http://www.urano.com.br/popup/logerII_2003/01.htm No ACBr.Net usei o protocolo FiscNet, conectando e funcionando corretamente. - Você testou usando o aplicativo ACBr.Net.ECFTeste.exe ou em sua aplicação? - Não será algo errado na configuração da porta serial, tipo baud rate, paridade, etc? - Pode nos enviar com maiores detalhes? **** Quanto abrir o projeto do ACBr32.DLL, você poderá usar o Delphi ou o Lazarus. Baixe todo o projeto pelo SVN. Abs,

Opa, valeu a dica. Vou atualizar os fontes incluindo esse encoding em todos os locais que tenhamos troca de strings com a DLL. Abs,

Opa, meus 5 centavos de opinião: Sou fã do projeto ACBr. Eu "vesti a camisa" e tento retribuir ao projeto o máximo que posso ... Já falei isso antes e repito: eu acho bizarramente mal feitas as DLLs distribuídas pelos fabricantes de ECF (todos eles), e o ACBr é um oasis dentro do universo de Automação Comercial. Assim, o sentimento é o mesmo: quanto mais "sabores" de ACBr tivermos, melhor para todos. O mercado precisa reagir, já basta a legislação incoerente e confusa que temos que seguir, não precisamos seguir também as DLLs incoerentes e confusas! Tecnicamente falando, a plataforma COM tem seus pontos fortes, pois consegue trazer uma API mais fiel à estrutura que existe nos componentes ACBr. Mas tem suas desvantagens, como baixa portabilidade (não roda em Linux) e dificuldade de interoperabilidade com Java; Desejo sorte no projeto, e pode contar com nossa ajuda no que for preciso. Abs,

Isso aí, o assembly .NET precisa ser compilado em x86 (32bits) para efetuar chamadas à DLLs nativas de 32bits. Poderíamos até compilar em 64 bits usando o Lazarus, mas por hora tem funcionado assim em 32bits. Abs,

Pessoal, Obrigado pela paciência, Em breve teremos uma nova atualização no SVN. Este post reúne tudo que foi feito e responde várias questões em aberto de outros posts, vamos lá: As principais mudanças são: ************* - Projeto compilado no Lazarus Antes eu usava o Delphi, como não o tenho mais, estou compilando no Lazarus. Os DEFINES CONSOLE e CDECL ou STDCALL devem ser inseridos no menu Project > Project Options > Compiler Options > Other > Custom Options: -dCONSOLE -dCDECL A única coisa "estranha" que eu notei é que compilando com Delphi, a DLL tinha cerca de 900Kb. Agora com Lazarus tem 1.6Mb! Alguém explica? ************* - Implementação de chamadas para configuração da serial no ECF: Bauds, DataBits, Parity, StopBits; Na DLL são funções ECF_GetBauds, ECF_SetBauds, ECF_GetDataBits, ECF_SetDataBits, etc ... E no ACBr.NET são propriedades da class ACBrECF. ************* - Implementado os métodos LeituraMemoriaFiscal e LeituraMemoriaFiscalSerial Na DLL são diversas funções (a DLL não suporta overload): ECF_LeituraMemoriaFiscalReducao ECF_LeituraMemoriaFiscalData ECF_LeituraMemoriaFiscalSerialReducao ECF_LeituraMemoriaFiscalSerialData ECF_LeituraMemoriaFiscalArquivoReducao ECF_LeituraMemoriaFiscalArquivoData No ACBr.NET são os métodos LeituraMemoriaFiscal e LeituraMemoriaFiscalSerial com diversos overloads. ************* - Bugs a serem corrigidos: Os métodos LeituraMemoriaFiscalSerial que retornam os dados lidos estão retornando as strings com caracteres inválidos. ************* - Novas implementações Falta implementar os métodos: LeituraMFDSerial EspelhoMFD_DLL PafMF_LX_Impressao PafMF_LMFC_Impressao PafMF_LMFC_Cotepe1704 PafMF_LMFS_Impressao PafMF_LMFS_Espelho PafMF_MFD_Cotepe1704 PafMF_RelMeiosPagamento PafMF_RelDAVEmitidos PafMF_RelIdentificacaoPafECF Alguém sabe como funcionam e quando são usados? ************* - jACBr e ACBr_ActiveX Não foi atualizado. Falta incluir os novos métodos e corrigir um bug pendente quanto ao retorno da Data do ECF; O ACBr_ActiveX foi apenas iniciado como um projeto em VB6. Falta ainda muita coisa pra ele. Se alguém estiver usando ou pretende usá-lo, avise para que possamos planejar algum andamento nele. ************* Abs!

hummmmm.... PInvokeStackImbalance was detected não é uma exception propriamente dita, e sim um "MDA". A condição de "Imbalance" é detectada por um MDA (Managed Debug Assistants), e jogadas como exception para alertar o desenvolvedor que algo potencialmente errado/perigoso pode estar acontecendo no código. Faça um teste simples: Compile o .NET em Release e rode, não vai acontecer pois só em Debug há MDAs. ************ Dúvidas e soluções: Por que isso acontece? Qual parte do código está errada ou perigosa? Sinceramente não sei. Eu vasculhei todo o código procurando uma declaração incorreta da DLL e não encontrei. Deve ter alguma coisa errada, mas ainda não sei onde. Por que em STDCALL isso não acontece? Porque o MDA "PInvokeStackImbalance" só é disparado quando a runtime detecta discordância entre os parâmetros passados para a DLL e o que a DLL espera. Como em STDCALL o mecanismo de passagem de parametros é diferente do CDECL, esse MDA não é acionado. Por que não usamos STDCALL de uma vez por todas então? Primeiro para poder suportar o jACBr: para linkar o código C++ do JNI com a DLL é preciso criar uma .lib a partir do código Delphi. A forma que encontrei ficou mais fácil com CDECL. Segundo para poder compilar no futuro a ACBr32.so e rodar em linux com jACBr e ACBr.NET (projeto Mono). Como é que eu rodo o ACBr.NET sem esse MDA? Basta desabilitar esse MDA especificamente para seu projeto: Vá no menu "Debug" > "Exceptions", Localize e expanda "Managed Debug Assistants" e desmarque "PInvokeStackImbalance" Qual o risco de desabilitar o MDA? Até agora comigo não aconteceu nada de errado. Mas é possível que essa condição de "Inbalance" gere falhas de memória em programas que são utilizados por longo tempo ... Isso será corrigido? Sendo sincero, eu tinha até me esquecido que isso acontecia. Mas prometo que vou revisar o código e procurar uma solução ou uma explicação racional pra isso! Como eu contribuo? Se você conseguir detectar qual(is) método(s) disparam esse MDA, podemos analisar com maior certeza e chegar numa solução definitiva. ************** Grande abraço!

Alo, Porque você está usando a DLL em STDCALL? A compilação em STDCALL deixaremos apenas para linguagens que requerem esse tipo de chamada, como VB6 e FoxPro. Em C# e Java é mais portátil e compatível utilizarmos as dlls em cdecl. Abs,

O roteiro é realmente diferente do TEF dedicado. Pelo que entendi, só as mensagens de origem do TEF requerem esse controle de tempo sem OK do operador. As mensagens originadas do ECF normalmente são tratadas como "tentar novamente" ou "cancelar".

Isso, é só apresentar a mensagem ao usuário. No caso das exceptions, eu mantive a opção tentar novamente ou cancelar. Que eu saiba, a única mensagem que fica apenas um tempo e some é a "transação aprovada". As mensagens de erro todas tinham confirmação do usuário. Mas deve ter diferenças no roteiro do TEF discado para o dedicado, não sei. Abs,

Isso mesmo. Mas fique atento pois o requisito não é tratar apenas o fim de papel, e sim qualquer outra indisponibilidade do ECF. Assim se você usar a exception vai tratar quando o ECF estiver desligado, sem papel, com a tampa aberta, em estado de erro, etc ... A mensagem de erro já vem apresentável ao usuário.

Não, o pouco papel é só pra informar ao usuário quando está acabando. o Sem papel é disparado como uma ACBrException, sempre que imprimir vc deve fazer um try ... catch observando isso (ECF desligado, sem papel, etc ... tudo vem por exception)

Sim, há a propriedade PoucoPapel na classe ACBrECF que fica true quando o papel está acabando. E quando é FIM DE PAPEL, o ACBr dispara uma ACBrException contendo a mensagem apropriada. Não há um evento "OnPoucoPapel", como nos componentes ACBr, daí você precisa verificar essa propriedade sempre que executar algum comando no ECF para saber se o papel está acabando.

Exatamente isso que eu tive que fazer. Mas a minha homologação foi com o SiTef, TEF Dedicado. Não sei quanto a homologação com TEF Discado. Como isso é um problema comum, já que é limitação do ECF, tente postar essa dúvida em outra área do fórum. Os usuários do ACBr Delphi/Lazarus possuem muito mais tempo de estrada que a gente! Abs,

Bem, vou te contar sobre a minha homologação, e isso é uma longa história: - Quando vc abre o vinculado, como o próprio nome diz, ele é "vinculado" ao número do cupom fiscal. E algumas impressoras permitem abrir mais de 1 vinculado para o cupom, outras não. Esse foi o meu caso, usando a bematech. - Aí o pessoal da homologação falou: Imprime tudo num vinculado só, tá tranquilo! Seria fácil, pena que no vinculado vem escrito a forma de pagamento e o valor pago... Assim eu não podia imprimir 2 comprovantes totalizando 20 reais, num único vinculado com valor de só 10 reais. - Aí o pessoal da homologação falou: Pra nós não tem problema se você agrupar os 2 cartões num pagamento só no ECF, desde que saiam os 2 comprovantes no vinculado. Aí eu implementei dessa forma: se você paga com 2 cartões, ao invés de sair 2 pagamentos no ECF, só sai 1 pagamento, e imprime 1 vinculado com os 2 comprovantes ... Eu lembro que essa solução gerou outros problemas. Não me recordo o que especificamente, mas tinha algo relacionado misturar cartão com dinheiro, etc .... Mas você tá no caminho certo!!! Boa sorte. Abs,

Oops, na minha versão tem esse método. Na DLL ele se chama ECF_FechaNaoFiscal. Vou dar uma revisada pra ver se o SVN não está desatualizado. Obrigado por avisar. Abs,

Opa, Cara não faço idéia. O Java normalmente requer que as dlls de JNI fiquem na raiz do classpath, você precisará adicionar a "ACBr32.dll" e a "ACBr32_JNI.dll". Não manjo muito de applets, se não tivesse rodado no windows 7 eu diria até que applet não roda JNI! Mas como rodou, deve ser alguma bobeirinha. *** Qual seu objetivo criando um applet para o ECF? Pretende fazer algo rodando em browser? Interessante ... Abs,

O Vinculado é fechado com o método FechaRelatorio(). No fim das contas o vinculado é um relatório ... tanto que caso haja falha na impressão do vinculado, é requisito você reimprimir usando um relatório gerencial. O método FechaCupom() é só pra cupom fiscal (venda), e o FechaNaoFiscal() só para comprovantes não fiscais.