Daniel Simoes

Mas a sua alteração irá gerar um log com várias linhas vazias... não seria melhor desativar completamente o Log ?

Esse componente serve apenas para Testes, para simular um Emulador de ECF...

Apague a Unit com o erro e baixe novamente...

Você está confundindo Arredonda com ArredondaItemMFD... A primeira é programada na intervenção fiscal, e existe apenas em ECFs anteriores ao advento da MFD (matriciais), a segunda existem apenas na nova geração de MFDs... Ou seja, alguns modelos de MFD apenas Truncam, sempre... O que está ocorrendo, é que a classe da Bematech quando interrogada se o ECF "Arredonda" não está considerando se o ECF é ou não compatível com o ArredondaMFD... isso precisará ser revisto nos fontes

Eu imaginava que se tratava de um Num.Série da MFD especificamente... Se todos os ECFs se comportarem da mesma maneira, a propriedade NumSerieMFD poderia até mesmo ser removida dos fontes do ACBrECF...

O modelo ecfNaoFiscal NUNCA deve ser usado em clientes finais... isso seria uma clara sonegação de Imposto

Tente com o Demo da própria DataRegis... se a mesma mensagem aparecer, você tem como provar para eles que o problema é no Gerenciador do TEF... Aparentemente é alguma configuração no Gerenciador Padrão (nos arquivos .INI) Experimente usar os arquivos em anexo nesse post: viewtopic.php?f=16&t=42&hilit=cheques.ini&start=10#p251

Você programou corretamente o método OnInfoECF ? Veja o código fonte do Demo do ACBrTEFD procedure TForm1.ACBrTEFD1InfoECF(Operacao : TACBrTEFDInfoECF; var RetornoECF : String ); begin if not ACBrECF1.Ativo then ACBrECF1.Ativar; case Operacao of ineSubTotal : RetornoECF := FloatToStr( ACBrECF1.Subtotal-ACBrECF1.TotalPago ) ; ineEstadoECF : begin Case ACBrECF1.Estado of estLivre : RetornoECF := 'L' ; estVenda : RetornoECF := 'V' ; estPagamento : RetornoECF := 'P' ; estRelatorio : RetornoECF := 'R' ; estNaoFiscal : RetornoECF := 'N' ; else RetornoECF := 'O' ; end; end; end; end; [/code]

Desculpe-me mas não compreendi o que você quis dizer... Por favor use o Demo do ACBrTEFD e descreva um passo a passo de como reproduzir o problema

Sim, o código da Epson já está funcional... - Copie as DLLs da Epson na mesma pasta do ECFTeste. - Configure a porta como: "USB" (sem as aspas) - Clique em Ativar

Após ser muito questionado sobre o suporte a portas USB no ACBrECF, decidi fazer um esforço para criar uma maneira de tornar isso possível. Recentemente enviei para o SVN as seguintes modificações: Ou seja, isso faz com que o ACBrECF não utilize a classe Synapse para ter acesso direto a porta serial, mas que utilize um método (simples) da DLL do Fabricante para efetuar o envio / recebimento de dados ao ECF. A principal vantagem dessa abordagem, é conseguir suporte nativo a porta USB, provido pela DLL do Fabricante, o que pode ocasionar em um significativo aumento de velocidade em alguns casos. Atualmente o ACBrECF já tem uma certa dependência das DLLs dos fabricantes para a geração dos arquivos do PAF-ECF ou Ato Cotepe 17/04.. ou seja, o ACBrECF já possui código para carregar a DLL dinamicamente, e abrir e fechar a porta Serial (ou USB)... O que foi modificado nos fontes, é que caso o fabricante possua um método simples para Envio / Recebimento de pacotes de baixo nível, podemos deixar a comunicação do ECF a cargo da DLL, Atualmente apenas a classe da Epson foi modificada para permitir essa nova funcionalidade... Para que possamos ajustar as classes dos demais fabricantes, precisamos saber se os mesmos disponibilizam uma função parecida com o método usado pelo próprio ACBr: Function EnviaComando( cmd : AnsiString; lTimeOut : Integer): AnsiString; ( o retorno é a resposta do ECF no protocolo do mesmo ) O ACBrECF SEMPRE fará carga dinâmica da DLL não causando dependência estática à mesma no aplicativo Uma sugestão para o método da DLL do fabricante seria: DWORD ECF_Serial_Enviar_Dados( LPSTR Comando, WORD TimeOut, LPSTR Retorno) O próprio ACBr já é capaz de montar um pacote com toda a especificação do protocolo, apenas precisamos de um método que permita o envio/recebimento de dados... Outros métodos semelhantes também podem ser utilizados/adaptados, como por exemplo, enviar o Comando do ECF e Parâmetros separados por Pipe "|", etc... Agradeço a todos que puderem ajudar nessa empreitada... Por favor indiquem esse próprio post ao corpo técnico dos Fabricantes, assim podemos debater um modo de como implementar essa nova funcionalidade em todas as classes MFD

O Numero de série poderia ser buferizado após a 1a leitura depois da Ativação... na verdade isso era feito... Porém com o PAF-ECF, onde o ECF pode ser trocado no meio da venda, é importante ler sempre do ECF... Porém se o NumSerieMFD sempre for a mesma coisa que NumSerie, ele nem precisaria ser lido...

Você precisa cadastrar o seu software no Posto Fiscal Eletrônico https://www.fazenda.sp.gov.br/pfe/login.asp

O seu ECF está Arredondando, pois ele é compatível com o ArredondaItemMFD... Talvez a rotina que mostre o total em MemoBobina não esteja levando isso em consideração

Isso ainda não é algo trivial ou bem documentado... (pois pode haver variação por ECF) Qual a sequência de comandos que você está tentando ?

Pelo que notei a DLL do fabricante está mudando a velocidade do ECF em algumas situações... tente com 38400... se mesmo assim não funcionar, abra o XML de configuração gerado pela DLL do fabricante e verifique a Velocidade de comunicação

Pelo que você descreveu a impressora está efetuando Arredondamento... A propriedade ArredondaItemMFD ou ArredondaPorQtd estão ativadas ?

Acho que o suporte da Bematech é mais indicado para essa tarefa... aparentemente falta instalar algum driver para fazer a USB emular uma serial. Estou terminando uma reforma no ACBr que permitirá usar a DLL do fabricante para acessar o ECF. Na Epson já está funcionando, e usando a USB diretamente (sem emular uma Porta COM) tive uma melhora de quase 50%: Porém a implementação dessa funcionalidade depende da DLL do fabricante possuir uma funçõe de "baixo nível" para apenas enviar o pacote de dados já montado no protocolo e aguardar a resposta. Estou conversando com alguns fabricantes sobre isso...

Pelo que compreendi você afirma que: - O ECF efetua trancamento por hardware - O valor impresso no ECF não bate com o exibido no MemoBobina E isso mesmo ? Se SIM, por favor informe os valores de QTD e Prec. Unitário que isso ocorre

ok... mas não compreendi se é necessária ou não alguma correção nos fontes do ACBrECF, e se SIM, como ela seria...

Use Delphi apenas.... AssignFile, WriteLn, etc... (veja exemplos na unit ACBrDevice.pas)

Se tiver alguma sugestão de melhoria ou correção para os fontes por favor anexe as Units para analise...

Não há problema algum com chamada a métodos na sequencia ou de forma procedural... O problema ocorre quando você chama algum método dentro de algum Evento... que é o que parece estar ocorrendo pelo Log... Veja todos os lugares onde você lê o estado do ECF.. algum deles deve ser um evento, que é chamado mesmo quando o ECF está ocupado

Todo projeto de código aberto só cresce quando recebe ajuda dos seus usuários... Entretanto a Mudança não é trivial, pois não é um método a ser mapeado, mas sim um Objeto com várias propriedades... seria necessário bolar uma estratégia...

Realmente esses comandos ainda não foram "mapeados" no ACBrMonitor