Daniel Simoes

Estamos com planos de suportar o TEF Direção em breve (talvez 1 mês)... Mas através do uso da DLL, e não da troca de arquivos... e nesse caso, o fluxo é completamente diferente... Já existe um tópico aqui no fórum onde um colaborador (MarcioDC) forneceu uma classe já funcional

Se a transação já foi confirmada somente a opção de Cancelamento é possível para desfaze-la... ou seja, não há como enviar um desfazimento para ela...

Ivan, Como isso deveria ser implementado em ACBrECFFiscNet.pas

Marcelo, Em qual linha exatamente ocorre o erro ?

Use o comando da DLL e ative o corte.... após isso provavelmente o ECF manterá a configuração...

landbrasilbr, Copie o LOG do Erro em Texto... a mensagem de erro, na sua imagem está truncada..

Por favor copie aqui as mensagens de erro extamente como elas aparecem...

Com a Zeos 7 só tive problemas com MySQL... (uso em Lazarus) Funcionou muito bem com FireBird e SQLite O FireBird 2.5 é fantástico, o suporte a UTF8 irá acabar de vez com problemas de Collete, e de buscas com ou sem acentos, maiúsculas e minúsculas

Estude o Demo detalhadamente... todos os retornos do ACBrECF são tratados lá... Use ACBrECF.Cliche Sobre o papel, pode ser problema no sensor... caso contrário a mensagem (ou o seu evento) já haveria de ser disparado... Se você programou o OnMsgPoucoPapel, cabe a você exibir a mensagem como (e se) quiser

Consegui reproduzir o problema, e adicionei pequenas correções em ACBrTEFDClass.pas que devem resolver... Por favor atualize pelo SVN e teste novamente...

Acho sua abordagem uma péssima ideia... Seu programa ficará muito muito lento dessa maneira... Desabilitar o ACBrECF.Device.ProcessMessages impede que o ACBrECF chame esse método do objeto Application internamente Ou seja, a sua aplicação pode "congelar" a interface, quando o ACBrECF estiver ocupado lendo algo do ECF, mas por causa disso mesmo o teclado tb não será lido... Seria o mesmo efeito que você já observou quando usando as DLLs dos fabricantes

Usar o comando: ACBrECF1.Device.ProcessMessages := False; pode resolver o seu problema... O mecanismo da Fila, é recomendado para caixas com vendas muito rápidas

Não analisei o código por ser muito extenso... mas não há como o ACBrECF fazer algo sem o mesmo ter sido comandado... Ative o LOG do ACBrECF e veja os comandos enviados para a impressora... Uma diferença básica do ACBrECF e as DLLs é que o ACBrECF não irá "travar" a sua interface quando a impressora estiver efetuando algo... isso ocorre poque o ACBrECF roda na mesma Thread que o seu aplicativo, e as DLLs rodam em um processo separado do EXE... Experimente desativar as chamadas de ProcessMessages do ACBrECF ACBrECF1.Device.ProcessMessages := False; O ideal é implementar um mecanismo de fila... Vc pode ler mais sobre isso nesse post (do forum antigo) http://www.forumweb.com.br/foruns/topic ... -com-acbr/

Do jeito que está expondo o seu Retaguarda é parte do PAF-ECF, e deverá ser homologado em conjunto...

Isso é configurado durante a lacração do ECF

durante esse teste eu rodei o meu aplicativo "editor" do AAC (semelhante ao Demo do ACBr)... Ou seja rodei ele com o PAF aberto, alterei pelo editor e salvei...

Esse homologador está "inventando moda"... O Ato Cotepe não fala nada disso... Criptografado = embaralhado... ou seja a ideia é realmente não dar a menor pista da informação oculta pela criptografia... Não é aceito usar um programa para "abrir" o Arq.Auxiliar Cripotografado, e alterar a informação ? (Há um novo Demo para o ACBrAAC que permitiria isso)

Estranho pois uso no dia a dia esses ECFs, e não tive problemas semelhantes...

Marcio, Não é possível usar o Exemplo já existente ?

SIM...Observe no Laudo, que ele é valido por 1 ano... Isso tb é descrito no Ato Cotepe... Até porque de um ano para cá, o Ato Cotepe já teve umas 5 atualizações (está muito, muito mais difícil)

O TEFD não suporta o TEF da Direção (ainda) Atualmente todos os TEFs permitem homologação remota... SiTEF, discado, etc

Acho que isso não deva ocorrer em todos os ECFs... Qual era mesmo a marca e modelo do ECF ?

Sim, isso é possível... pois a redução Z é demorada, e o tempo pode variar... O ACBrECF implementa em cada classe um mecanismo para saber se o ECF está ocupado, imprimindo... Geralmente isso é feito solicitando o flag de Satus ou ainda a Data/hora do ECF... se o mesmo não for capaz de responder, ele (ACBrECF) entende que o ECF está ocupado imprimindo Pode ser que o ECF tenha sido capaz de responder a essa solicitação entre o término da Impressão do relatório e no inicio da impressão do BitMap

Não é permitido imprimir um CPF inválido... deixe em branco...

Johnprogrammer, Muito obrigado pela sua contribuição... já enviei para o SVN, pasta: \ACBr\Exemplos\ACBrAAC\Delphi2