Daniel Simoes

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

Parece ser um problema no seu gerenciador padrão... experimente remove-lo e instalar novamente...

Experimente não informar a chave na aba do ACBrMonitor... Mas qual seria a vantagem de não assinar os arquivos ?

Então não comprendi porque você está tentando ler o IntPos.001, sendo que o ACBrTEFD é quem faz isso... Por favor estude detalhadamente o demo do ACBrTEFD na pasta exemplos...

Você está usando o ACBrTEFD ?

Acho que o jeito é estudar os manuais da DLL e os fontes da classe do GP Direção no ACBrTEFD...

Entendo... acho que nesse caso seria necessário uma nova classe... V&Spague e SiTef se comportam da maneira que você descreveu

Qual modelo de GP você está ativando ? Provavelmente você usou tefDial o Direção entrou em modo de emulação do GP Padrão

O erro é forçado por código... se você não programar esses eventos o componente não funcionará corretamente... Estude o código fonte do Demo do ACBrTEFD antes