Daniel Simoes

Entendo... desculpe-me se pareci rude... mas o Nick não é comum.... por favor tente usar uma Assinatura com a sua identificação profissional... Isso com certeza trará mais credibilidade para você... Tente esse programa: http://www.djsystem.com.br/djnfp-envio- ... -lote.html

Acho que um mínimo de procedimento é necessário quando tenta se manter um forum sério... Qual a finalidade (ou vantagem) desse anonimato ? Por favor corrija o Nick ou terei que excluir...

Mande o LOG... nele tem a mensagem correta do Erro...

Prezado.... como você espera ser levado a sério com um Login chamado "Ninguem" ?? (por favor tente corrigir isso)

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