Daniel Simoes

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...

Bacana... Qualquer duvida é só postar...

Não compreendi a pergunta 1... O ACBrECF não acumula nenhum valor... quem acumula é o ECF... (veja na LeituraX ou Redução Z)... tudo que o ACBrECF faz é ler esses valores do ECF toda vc que vc chama essa propriedade.... Por favor leia a cartilha do ECF... http://www.sweda.com.br/cartilha.aspx

Por favor veja esse link: viewtopic.php?f=10&t=696&p=3707#p3707

Há algo muito estranho nesse ECF... ele está respondendo como se o modelo fosse uma FS345 Veja esse trecho do LOG, onde o ACBrECF tenta detectar o modelo do ECF... Primeiro o ACBrECF manda o comando no formato do protocolo da FS600 (FS + 'R' + [200]+'082'), porém o ECF não o reconhece: Logo depois ele manda no formato da FS345 onde o ECF responde com o código :10043, correspondente a FS345 A partir desse ponto o ACBrECF tratará esse ECF como uma FS345 Foi feita alguma configuração nesse ECF para que ele se comporte em modo de compatibilidade com a FS345 ? Experimente aumentar o TimeOut para 10, pode ser que o ECF esteja demorando mais do que o normal para responder ao comando inicial

Acredito que não... a não ser que vc tb queira fazer múltiplos cartões na mesma venda... Mas o ideal é consultar os homologadores...

Infelizmente não tenho tempo para me dedicar a esse assunto no momento... Vou tentar homologar com uma Epson (ou Bematech)... mas tb tenho uma Daruma FS600, quem sabe consigo fazer os ajustes...

A Saque funciona em alguns TEFs... como por exemplo do TEF dedicado, que tem campo específico para isso... No TEF discado ela não existe, use a propriedade ValorTotal e compare com o Valor que vc enviou...

Acho que detectei o problema... Quando o Memo Interno do ACBrMonitor atinge mais de 1000 linhas, ele tenta apagar as linhas iniciais... causando uma enorme lentidão... Já corrigi o problema... Aumentei o limite para 10000 linhas, e re-escrevi a rotina de descarte das linhas iniciais.. As modificações já estão no SVN

SAOliveira, Por favor envio o LOG do ACBrECF desde o inicio (ativar)... Vc falou que se trata de um ECF Daruma FS600, mas o log se comporta como se fosse de uma FS345... Preciso verificar se há algum problema na identificação inicial do ECF...

Provavelmente vc está informando errado o Índice da Forma de Pagamento a ser utilizada para a impressão do Vinculado para o ACBrTEFD... (Veja no log do ACBrECF a verdadeira msg de erro)

Sim... os LOGs estão corretos... e com eles podemos ver que o retorno do ECF está correto, e sempre é o mesmo... e que o ACBrMonitor tb está respondendo corretamente de acordo com a sintaxe do manual, que é: IIIITDDDDDDDDDDDDDDDDDDDDDDD Onde: IIII = índice da Forma de Pagamento usado pelo ACBrECF T = Permite Vinculado - Se sim V senão vazio DDDD = Descrição da Forma de Pagamento com 30 caracteres Veja: http://acbr.sourceforge.net/ACBrMonitor ... mento.html Provavelmente o problema está na sua rotina de interpretação do retorno, que deve estar ignorando o flag "V"

Sim... essa verificação foi implementada em TACBrECF.LinhaRelatorioGerencial... se vc usar as DLLs dos Fabricantes e não o ACBrECF... será necessário escrever sua própria verificação

O ACBrTEFD é projetado para compatibilizar vários TEFs diferentes com o TEF discado... por isso a assinatura do comando tem todos esses parâmetros... Analise os fontes do arquivo... ACBrTEFDVeSPague.pas tudo que ele usa é o NSU Function TACBrTEFDVeSPague.CNC(Rede, NSU : String; DataHoraTransacao : TDateTime; Valor : Double) : Boolean; var Retorno : Integer; ListaParams : AnsiString ; begin ListaParams := '' ; if NSU '' then ListaParams := 'transacao_nsu="'+Trim(NSU)+'"'; Retorno := FazerRequisicao( fTransacaoCNC, 'CNC', Valor, '', ListaParams ) ; if Retorno = 0 then Retorno := ContinuarRequisicao( True ) ; { True = Imprimir Comprovantes agora } Result := ( Retorno in [0,1] ) ; ProcessarResposta ; { Faz a Impressão e / ou exibe Mensagem ao Operador } end; [/code]

Acho que esse é o problema... Esse projeto é um Fork do Fortes Report... (existem vários Fork do Fortes) Pelo que ouvi falar o projeto original está em: http://sourceforge.net/projects/fortesreport/

Tente o protocolo ecfFiscNet O ACBrECF só funcionará se o driver USB instalar um virtualizador de porta serial (geralmente é isso que ocorre)... Se for esse o caso, use a porta COM criada no Window (veja em Gerenciador de Dispositivos)

Verifique se vc está com a última cópia do Fortes Report instalada corretamente...