Daniel Simoes

Estamos quase lá... retomei o contato com o André Munhoz... A nova MP4200, (que usa a classe ecfEscECF) já suportará USB, pois o driver da mesma irá criar uma porta Serial Virtual Nas tradicionais, MP4000, MP2100, estamos trabalhando em um novo método na DLL da Bematech que nos permitirá o uso da USB (semelhante ao que temos hoje com a Epson)

Lendo o Post notei que o protocolo SwedaSTX realmente suporta o envio de informações do Consumidor no rodapé... Apliquei modificações nos fontes do SVN que devem permitir essa funcionalidade... favor atualizar e testar...

Experimente ativar a propriedade ACBrECF.ArredondaPorQtd

Notei que você está usando um TimeOut = 3, que é muito baixo para alguns comandos... experimente aumenta-lo para 10

Se o programa está ficando na chamada do comando que usa a DLL do fabricante... então há algum problema com a correta instalação da DLL... Veja esse link:

Nossa recomendação é que todas as DLLs da Bematech e o arquivo BemaFi32.INI fiquem na mesma pasta do ACBrMonitor.exe Aqui uso as seguintes DLLs: BemaFI32.dll, BemaMFD.dll, BemaMFD2.dll, sign_bema.dll, BemaMFD2_MP4000THFI.dll

Alguns ECF não deixam essa informação persistente, (pode ser o caso da Sweda)... Em alguns outros modelos não há nem mesmo o suporte a esse campo especial para o MD5, nesse caso o ACBrECF abstrai a diferença e usa as linhas do Rodapé quando necessário

Tente modificar o Chr(140) para Chr(250)

A nova Bematech MP4200 não usa o protocolo ecfBematech e sim o novo protocolo definido no convênio 09/09... use o modelo ecfEscECF

Oi Alexandro, Desculpe-me por só agora entrar em contato.... Parece que você está fazendo um ótimo trabalho de analise e correção... por isso deixo você tentar mais um pouco Se precisar de alguma ajuda estarei mais atento nos próximos dias

Acho que sei do que se trata... Conversei com o Amarildo na FENACOM, ele estendeu o modelo ecfNaoFiscal para permitir o uso do mesmo com a NFCe... Estou trabalhando nisso, com o SAT e NFCe... Amarildo, muito obrigado pela sua contribuição... vou analisar e volto a postar...

O ACBrECF já tem métodos para gerar CAT52 e AtoCotepe1704 CAT52 só pode ser gerada se você estiver gerando o arquivo manualmente... isso é particularmente útil se você está gerando o arquivo a partir do seu Banco de Dados, o que é muito mais rápido e garante sempre a identificação do cliente AtoCotepe1704 deve necessariamente ser gerada pela DLL... (está na lei)... Ele irá ler as informações da MFD do ECF Não há problemas identificar o cliente no final do cupom... desde que o ECF suporte essa característica... Use ACBrECF1.IdentificaConsumidorRodape: Boolean para saber se o ECF tem essa característica. Se o ECF suportar, use: ACBrECF1.IdentificaConsumidor( CPF, NOME, ENDERECO ); antes de subtotalizar ou fechar o cupom

ACBrECF.EnviaComando( #27 + 'v' + #100 ) // enviando comando com 100 milisegundos

Tudo indica que você está usando uma DLL antiga... a Bematech modificou recentemente a maneira de nomear esse arquivo...

Eu ainda não testei o ACBrCTe no Linux, mas sim o ACBrNFe, que usa praticamente as mesmas bibliotecas... Aqui uso um Linux Mageia 2 32 bits Lazarus versão do SVN, e FPC 2.7.1 (baixado pelo SVN)

Já viu o Demo da pasta: C:\ACBr\Exemplos\ACBrETQ\Delphi ??

Obrigado pela colaboração... Vou analisar os fontes em breve...

Apliquei um amplo refactoring no componente ACBrConsultaCNPJ, pois o mesmo reescrevia alguns métodos que a classe mãe (ACBrSocket) já possuía... O motivo principal era que a consulta não estava funcionando em Linux, provavelmente devido a problemas de conversão de UTF8 e Ansi. A classe ACBrSocket já possuía tratamentos para converter UTF8 de e para Ansi, quando necessário... Também otimizei um pouco a rotina de captura dos campos do HTML.. A leitura do CNAE Principal e CNAE Secundário foi implementada

Parece que o problema é incompatibilidade da libxmlsec com Linux 64 bits... Não há solução para isso até o momento...

Fiz um pequeno ajuste para compatibilizar o componente com Lazarus, Adicionei o Demo que foi migrado para Lazarus por Roberto Brandão, Fiz um Refactoring de algumas funções que já existiam nos fontes do ACBr ou synapse: HTTPEncode -> synacode.EncodeURLElement; PosEx -> strutils.PosEx

Pode ser firewall... O protocolo "SVN" usa a porta 3690

Você pode tentar um novo checkout:

Veja esse tópico, (no antiga área do ACBr no ForumWeb) http://www.forumweb.com.br/foruns/topic/74093-pequenos-problemas-com-acbr/

Nossa intenção ao adotar a LGPL no ACBr era justamente permitir o uso dos componentes em projetos Comerciais... caso contrário nós mesmos como autores iniciais do projeto (DJSystem) não poderíamos comercializar os nossos programas que usam o ACBr Concordo que a LGPL se aplicaria melhor a projetos como o ACBrFramework... é realmente o mais correto seria usar uma licença parecida com a do Lazarus, LGPL modificada, pois os componentes ACBr são na maioria das vezes compilados estaticamente ao projeto final (assim como ocorre no Lazarus) Pretendo no futuro, rever a compatibilidade entre a LGPL que usamos com a LGPL modificada (pelo equipe do Lazarus)... para que isso fique mais claro. Mas fique tranquilo com isso, nossa intenção é permitir o uso dos componentes em Projetos Comerciais O ACBrMonitor por se tratar de um produto final, é G.P.L. Há várias formas de colaborar com o ACBr, contribuindo com fontes, com suporte, com divulgação, ou até mesmo financeiramente... Através do ACBrSAC

Realmente não existe tal retorno no ACBrECF... Podemos seguir dois caminhos: - Criar uma nova propriedade ACBrECF.DataEmissaoUltimaReducaoZ - Modificar a rotina GetDadosUltimaReducaoZ e inserir um novo campo na classe... Acredito que nem todos os ECFs tenham um comando específico para retornar essa informação (como o citado no tópico), e que alguns ECFs não retornarão essa informação nem mesmo na leitura dos dados da Ultima Reducao Z O que vocês acham ser o mais interessante ?