Daniel Simoes

Isso é uma característica do ECF... tudo que o ACBrECF faz é ler o retorno do ECF... (Veja no LOG gerado pelo ACBrECF)

Vc deve sempre usar ACBrECF.Ativar... Provavelmente a DLL do fabricante está prendendo a porta serial... Evite usar chamadas estáticas a DLL nos seus fontes...

Sem o LOG não há como analisar... basta você escrever um nome de arquivo na propriedade: ACBrECF.ArqLOG

Esse manual, descreve como instalar o programa do D-TEF e um Client para emular um TEF discado... SIM, é possível criar uma nova classe baseada em ACBrTEFDClass (TEF discado)... mas sinceramente, acho que não vale o esforço. A troca de arquivos TXT sempre será mais lenta... e não será sua aplicação que terá todo o controle do TEF... A instalação/configuração no usuário tb é mais complicada O ACBrTEFD já é compatível 2 TEFs dedicados... SiTEF (homologado) e V&SPague (quase homologado)... ambos com acesso direto, ou seja, sem troca de arquivos TXT. O custo de ambos é bem acessível (de 200,00 a 300,00 por mês)... entre em contato com a Dataregis para saber mais sobre o FastTEF (SiTEF) http://www.dataregis.com.br/solucoes_tef.shtml http://www.vespague.com.br/ Deve haver alguma documentação mais completa do D-TEF, que descreva o acesso direto (sem a necessidade do client, e sem troca de TXT)... isso sim seria interessante...

Flávia... o ECFTeste não envia nenhum MD5 no final... Verifique se isso não foi programado no ECF pelo método "Utilitários -> Identificar PAF".. se for o caso, use a mesma função para programar outra coisa

O problema parece ser no ECF... Pode ainda ser uma característica... veja o Retorno do comando 070 -- 14:42:49 DataMovimento TX -> [28]R[200]070[177] 14:42:49 RX [/code]Ou seja: 01/01/2000 Por favor entre em contato com o fabricante para obter mais informações sobre as condições de uso comando: FS+'R'+#200+'070'

Elton... O FastTEF é na verdade o SiTEF, mas distribuído pela DataRegis... (ou seja, não é o D-TEF, que é outro TEF dedicado)

No TEF discado, o CNF deve ser enviado, pois não pode ficar nenhuma transação aberta... para maiores explicações, leia o roteiro de múltiplos cartões do TEF discado... Não é conveniente comparar o D-TEF com TEF discado... a não ser que vc pretenda usa-lo no modo "Client" (ou algo parecido) o que não é bom para um TEF dedicado, pois os TXTs e o fluxo, nunca são 100% compatíveis... Por favor forneça mais informações sobre o D-TEF da Direção... acredito que ele seja semelhante ao SiTEF e ao V&SPague... para compatibiliza-lo com com o ACBrTEFD provavelmente será necessário criar uma nova classe...

Senhores, Se desejam submeter alterações nos fontes para analise, por favor anexem a Unit ou um Patch

Se for o mesmo ECF, o problema não está nele, e provavelmente é algo no driver do conversor... Observe que ele responde corretamente aos comandos FS: -- 07:23:39 29/01/2011 Ativar TX -> [28]R[200]082[188] 07:23:39 RX -- 07:23:39[/code] evite o uso de conversores USB... eles são muito problemáticos... em algumas situações param de funcionar, ou mudam de endereço... Use uma multi-serial PCI

Se deseja ajudar na resolução do problema, favor fornecer as informações solicitadas... Leia: viewtopic.php?p=2522#p2522

informe mais detalhes... Qual é o ECF ? marca/ Modelo / versão Copie o LOG gerado pelo ACBrECF

Em relação ao problema do SAQUE.. acho que realmente há um bug no componente... conforme relatado em: viewtopic.php?f=16&t=892

Não... pois ele pode cancelar qualquer transação do dia, e não apenas a última... Eu faço o contrário... quando cancelo o último cupom fiscal, verifico se houve pagamento com TEF, e dai sim, pergunto ao operador se ele quer cancelar a transação TEF

Nunca li nada sobre o D-TEF da direção... e provavelmente o ACBrTEFD não será compatível com ele... Mas vc descreveu o próprio fluxo de múltiplos cartões, coisa que o ACBrTEFD já faz com o discado...

Apenas a DLL é necessária (não precisa de .NET) No Linux o OpenSSL já é instalado por padrão, pois vários serviços dependem dele... Ou seja, no Linux provavelmente não será necessário distribuir a DLL Só agora notei que a Unit do Marco Ferrante "libeay32.pas" não está compilando no Linux (com o Lazarus)... estou tentando resolver isso... Também consegui outro avanço... O FPC (compilador do Lazarus) possui uma Unit nativa para acesso a algumas funções do OpenSSL... ela foi escrita com base no trabalho do Lucas (Synapse) e do Marco... Faltavam alguns métodos que estou usando... mas que já implementei nela.... No Windows tudo OK, vou testar no Linux... e depois preciso verificar a compatibilidade dessa Unit com o Delphi 7 e Delphi 2010 (Unicode) A grande vantagem dessa Unit do FPC é que a carga da DLL é feita de forma dinâmica... Ou seja, não dependerá da DLL para simplesmente executar o programa, mas acusará um erro caso alguma método do ACBrEAD seja chamado e a DLL não seja encontrada.

O fato do Windows ser 7/64 não influencia isso... O ACBrECF usa a comunicação direta com a serial... Se houvesse algum problema na comunicação serial, vc teria diversos outros problemas... Por favor me envie os LOG do mesmo teste em uma máquina que não seja Win7/64

Tente com o programa do fabricante... Tenha certeza de que essa porta funciona com algum outro programa

Por favor acessem o link abaixo: viewtopic.php?f=5&t=899

Olá pessoal, Estou concluindo uma ampla reforma na Unit ACBrEAD, que foi promovida a Componente... Com ela agora teremos os seguintes métodos: Procedure GerarChaves( var AChavePublica : AnsiString; var AChavePrivada : AnsiString ) ; function AssinarArquivoComEAD( const NomeArquivo: String) : AnsiString ; function VerificarEADArquivo( const NomeArquivo: String): Boolean ; overload ; function VerificarEAD( const AString : AnsiString): Boolean ; overload ; function VerificarEAD( const AStringList : TStringList): Boolean ; overload ; function VerificarEAD( const MS : TMemoryStream; EAD: AnsiString): Boolean ; overload ; Function GerarXMLeECFc( const NomeSwHouse, Diretorio : String ) : Boolean ; Procedure CalcularModuloeExpoente( var Modulo, Expoente : AnsiString ); Function CalcularChavePublica : AnsiString ; function CalcularMD5Arquivo( const NomeArquivo: String): AnsiString ; overload ; function CalcularMD5( const AString : AnsiString): AnsiString ; overload ; function CalcularMD5( const AStringList : TStringList): AnsiString ; overload ; function CalcularMD5( const MS : TMemoryStream): AnsiString ; overload ; function CalcularEADArquivo( const NomeArquivo: String): AnsiString ; overload ; function CalcularEAD( const AString : AnsiString): AnsiString ; overload ; function CalcularEAD( const AStringList : TStringList): AnsiString ; overload ; function CalcularEAD( const MS : TMemoryStream): AnsiString ; overload ; [/code] Para fazer essas funções usei uma Unit de "Marco Ferrante", chamada: [b]libeay32.pas[/b]... Com ela fica "possível" trabalhar com o OpenSSL de forma direta, ou seja, abrindo a [b]libeay32.dll[/b]... Link: http://www.disi.unige.it/person/Ferrant ... hiopenssl/ Portanto o ACBrEAD apenas dependerá dessa DLL para conseguir fazer todas as funções acima, e não mais executará chamadas "run" ao programa OpenSSL.exe... Outra vantagem é que agora o ACBrEAD não precisa mais gravar as chaves em disco, elas são manipuladas epenas na memória, e por um breve período de tempo (muito mais seguro) Em anexo está um exemplo do EADTeste.exe, em que estou trabalhando, e que permite comprovar o funcionamento... EADTeste.zip Note porém, que o EADTeste.exe depende da [b]libeay32.dll[/b] instalada no Path do Sistema Operacional ou na mesma pasta da aplicação... para iniciar a sua execução (você pode encontrar essa DLL em [b]ACBr\DLLs\OpenSSL[/b]) Isso ocorre, porque a Unit do Marco Ferrante faz ligações com a Libeay32.dll de forma estática... Ou seja, todo programa que fizer "Uses" dessa Unit ficará com a dependência dessa DLL para ser executado Isso não chega a ser um problema para programas como o EADTeste... mas vários componentes do ACBr usam a Unit ACBrEAD, e por consequência, tb ficarão com essa dependência... São eles: ACBrRFD e ACBrPAF... O ACBrRFD é usado pelo ACBrECF... Ou seja, qualquer aplicação que ficar uso de ACBrECF, ACBrRFD, ACBrPAF ou ACBrEAD ficará dependendo dessa [b]libeay32.dll[/b] para ser executada... [b]Agora a pergunta... [/b][b][color=#FF0000]Você acha que isso é um problema para a sua aplicação ? [/color][/b] Gostaria da opiniões dos usuários dos componentes do ACBr, antes de continuar com o próximo passo... Como alternativa, poderíamos: [b]- Deixar como está, causando a dependência de libeay32.dll[/b] (essa DLL já é distribuida com os fontes do ACBr, bastaria copia-la no mesmo diretório da sua aplicação... acredito que muitos já a possuem por causa do NFe... e no Linux ela já é nativa. Mas provavelmente receberíamos um grande "enxurrada" de perguntas sobre esse "erro") [b]- Modificar o ACBrEAD para sempre usar o OpenSSL.EXE[/b] (isso elimina a dependência, mas fica menos eficiente e elegante... além de menos seguro, pois as chaves sempre precisariam ser gravadas no disco) [b]- Modificar a Unit libeay32.pas para fazer a carga dinâmica.[/b] (isso seria o ideal, mas é extremamente difícil e trabalhoso...) EADTeste.zip

Humm... pensando bem, eu apenas homologuei TEF dedicado com o TEFD... Infelizmente não tenho conhecimento ou motivação para analisar isso a fundo... Acho que você está mais apto do que eu para sugerir modificações nos fontes.... Se desejar, por favor forneça as Unit modificadas ou um Patch

Todo banco exige essa "homologação" ... ou seja, todos nós temos que fazer isso.... Até o momento não tivemos nenhum problema com o Layout atual... até mesmo porque os layouts do ACBrBoleto vem de projetos que já existem a muito tempo... como gbBoleto e RLBoleto

Se desejar sugerir mudanças nos fontes, por favor anexe a Unit ou um patch para ser analisado... Este problema que você relatou, só ocorrerá se a propriedade AutoEfetuarPagamento = True, o que deve ser evitado... Pois quando essa propriedade é ativada, em alguns ECFs (como por exemplo na Bematech) não será possível abrir vários vinculados com o mesmo índice de forma de pagamento.... Quando AutoEfetuarPagamento = False, o ACBrTEFD imprime apenas um Pagamento de Cartão (com o Valor Total de todas as transações)... Abre apenas 1 vinculado, e imprime todos os comprovantes, de todos os cartões dentro desse vinculado... E também nesse caso, o Valor de Troco para o SAQUE funcionará corretamente

Por favor tente debugar... e se possível corrigir... Apesar de ter ajudado no desenvolvimento da versão do Quick do ACBrBoleto... não uso ele no meu dia a dia... Uso Lazarus e o Boleto com o LazReport ou FortesReport... Tenho apenas o Quick que vem com o Delphi 7, pode ser que seja necessário algum ajuste para essa nova versão do Quick, mas não terei ambiente necessário para realizar testes...

Thiago, A caixa se incomodou com isso ? Hoje em dia existem sites que emitem boletos bem "fora do padrão"... Antes de fazer qualquer modificação... Imprima um boleto e mande para o Banco analisar...