Daniel Simoes

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

Tenho usado alguns componentes da CCR - RXNew - VirtualTreeViewNew - ZVDateTimeControls (resolveu meu problema de Edits com Data e Hora)

SIM... basta você se comunicar com o ACBrMonitor por Sockets (TCP/IP)

O ACBrTEFD usará os arquivos da pasta de Backup para saber de todas as transações pendentes... Verifique se eles ainda estão lá na segunda tentativa...

Fechar o comprovante de Cancelamento não significa Cancelar o Cupom... O que eles não querem é que você imprima o comprovante de Cancelamento no Relatório/Vinculado que estava aberto para imprimir a Transação...

Muito obrigado pela sua contribuição... vou aplicar nos fontes...

Ótima escolha de IDE e de Banco de Dados... A ZeosDBO tb é show... Acho que os componentes do ACBr tb poderão lhe ajudar nessa tarefa... Se precisar de alguma ajuda com eles estamos por aqui...

Tente: ECF.DadosReducaoZ Veja: http://acbr.sourceforge.net/files/ECFDadosReducaoz.html (chame ele ANTES de comandar a Red.Z)

No trecho do Log não há chamada do método de Suprimento... Outra, a rotina de trabalho está errada... A Red.Z não deve ser tirada no inicio do Dia, e sim no FIM do Dia... pois ela bloqueia o ECF...