Daniel Simoes

O Lazarus é "apaixonante"... é muito bom poder opinar e ajudar no desenvolvimento da própria ferramenta de trabalho... Se vc ainda não faz parte... recomendo essas listas: Lazarus-BR E a lista oficial... de alto-nível... mas capaz de encher uma caixa postal rapidamente http://lists.lazarus.freepascal.org/mai ... fo/lazarus

Muito bacana... com campos Memo ele cria um StringList... parabéns pelo seu trabalho, Já conhece esses Projetos semelhantes ? http://tiopf.sourceforge.net/ http://www.pressobjects.org/

Pode ser que a empresa de lacração não tenha feito um "bom serviço" e não tenha inserido a quebra de linha no Cliche.... Acho que podemos fazer essa atribuição num Try/Except... mas nesse caso a variável cEndereco sempre ficaria vazia

O ACBrECF tenta, na maioria das situações, abstrair as diferenças... Ou seja.... ACBrECF.LeituraX funciona em todos os modelos suportados por ele... Mas algumas coisas sempre mudam, como por exemplo os Indices das Formas de pagamento... a maioria usa 01, 02, 03... mas na Epson vc terá 1, 2... nas FiscNet (Elgin, Urano, ZPM, DataRegis) elas são mais exóticas ainda... Exemplo: -2 = Dinheiro,

A Daruma não possui emulador, e já declarou que nunca irá produzir um... Bematech, Sweda, Epson, e todas as "FiscNet" possuem ótimos emuladores...

Quando o cliente for utiliza-la ela deverá ser re-lacrada... Não é uma boa ideia usar ECFs lacrados, emprestados de cliente, para testes... Lembre-se que o Cliente paga imposto sobre todos os cupons emitidos... O ideal é ter um ECF para desenvolvimento... pois uma vez ou outra vc precisará dele... Quase todos os fabricantes tem condições especiais para ECFs para desenvolvedores...

SIM... mas vc deve compreender o que os fontes do componente fazem (em qual rotina isso é feito)... acompanhe o processo de inicialização do componente com o Debug... Na homologação é fundamental conhecer bem os fontes....

Vc deve enviar o comando de SubTotalização aplicando os 10%... antes de abrir para as formas de pagamento...

Oi Elton, Vc tem razão... Antes, no inicio do ACBr, tínhamos apenas um número de versão para tudo... que era o número da versão do ZIP com os fontes disponíveis para Download. Com a distribuição dos fontes apenas por SVN, isso perdeu completamente o sentido... e tb projeto cresceu muito, abraçando NFe, PAF, TEF e vários outros componentes, o que criou a necessidade de números de versões individuais para cada componente... Acho que cada componente deve ter seu próprio numero de versão... o que faz desnecessária a propriedade AboutACBr... Agradeço muito a sua ajuda para corrigirmos isso...

Sendo Java... Vc usa o ACBrMonitor ou a ACBr32.DLL ?

Para Desenvolvimento geralmente é utilizada um ECF "aberto", sem o lacre, pois em algumas situações é necessário fazer uma Intervenção Técnica... a titulo de exemplo durante a homologação PAF-ECF são realizadas várias Intervenções técnicas... Mas o que vc imprime não pode ser considerado um Cupom Fiscal, já que este equipamento não foi registrado no Posto Fiscal, ou está registrado como equipamento para desenvolvimento (o que é exigido em alguns estados)... Ou seja, o ECF de desenvolvimento se comportará de forma idêntica a um ECF lacrado, mas os documentos impressos não tem valor legal...

SIM... realmente estava... por favor veja: viewtopic.php?p=4459#p4459

AFF... Isso é que dá fazer as coisas de madrugada e com sono Já corrigi no SVN... Obrigado pelo aviso...

- o TCP é muito, muito mais rápido do que troca de arquivos TXT... - Vc pode operar uma máquina com ECF remotamente... (eu uso muito isso com Linux+SSH) Basta modifica na aba principal do ACBrMonitor... Sua aplicação tb deve estar apta a trabalhar com Socktes

A informação do Rodrigo está correta... Mas isso já deveria ter sido ajustado pelo lacrador, no momento da Intervenção Técnica

O ACBr não usa DLL, usa a comunicação direta pela Serial através da Classe SynaSer... Por favor anexe o manual do Fabricante (ou link para baixa-lo)

os métodos ACBrECF.Sangria e ACBrECF.Suprimento não estavam ajustando a variável "ComandoLOG" isso não explica o seu problema mas pode explicar pq o comando Sangria não apareceu no LOG Corrigi no SVN... pelo menos agora vc terá informação do momento em que o comando de Sangria foi enviado...

SIM vc está correto... Do jeito que está o NãoFiscalCompleto na Bematech sempre será impresso em modo de compatibilidade com a MP20, e não permitirá identificar o Cliente (CNPJ) (vou corrigir no SVN)

Oi Ivan, Em relação a Unit ACBrTEFDClass.pas Acho que podemos deixar apenas o Try Except que vc introduziu... { Enviando CNF ou NCN e apagando Arquivo de Backup } ArqBackup := Resp.ArqBackup ; while FileExists( ArqBackup ) do begin try if ImpressaoOk then self.CNF else self.NCN ; except end; DeleteFile( ArqBackup ) ; end ; [/code] Em relação a V&SPague... o que eles exigem durante a Inicialização da Aplicação quando há Transações Pendentes ? Se não me engano (não me lembro direito) no V&SPague tem um comando que retorna se há transações pendentes... não é preferível usa-lo ao invés dos arquivos de Backup ?

SIM... isso é mais comum.. ou seja, é abrir apenas um CCD (ou vinculado).... isso desde que você tenha apenas um pagamento com o total de todas as transações de todos os cartões passados no cupom (multiploscartoes)... Nesse caso, é possível imprimir todos os Comprovantes (em 2 vias) no mesmo vinculado ou CCD... O ACBrTEFD fará isso automaticamente, se você deixar a cargo dele a impressão das formas de Pagamento e fechamento do cupom... além de AutoEfetuarPagamento := False

izaiasavila, Parabéns pela sua homologação Obrigado pela sua correção e pelas suas valiosas dicas... Estou aplicando as modificações no SVN

A modificação invalidará o proposito do método, ou seja, o calculo do Exponente será errado... Veja esse tópico: viewtopic.php?f=5&t=964

nazarenoneto, Por favor seja mais específico... Exemplo: 1 - Ativar o ECF 2 - Selecionar a Aba DadosReduçao Z 3 - ..... ??

Parece ser um problema no seu G.P.... que aparentemente não responde ao comando ATV... Analise o LOG gerado pelo ACBrTEFD e observe o que ocorre durante a Inicialização

nos campos 030 e 031... por favor leia com atenção o Guia Técnico do Gerenciador Padrão... No ACBrTEFD vc pode acessar os campos como propriedades ou pelo Indice do Campo... Veja o exemplo extraído do Demo (estude o Demo em detalhes) procedure TForm1.ACBrTEFD1DepoisConfirmarTransacoes( RespostasPendentes: TACBrTEFDRespostasPendentes); var I : Integer; begin for I := 0 to RespostasPendentes.Count-1 do begin with RespostasPendentes[I] do begin Memo1.Lines.Add('Confirmado: '+Header+' ID: '+IntToStr( ID ) ); Memo1.Lines.Add( 'Rede: ' + Rede + ' NSU: ' + NSU + ' Valor: '+ FormatFloat('###,###,##0.00',ValorTotal)) ; Memo1.Lines.Add('Campo 11: ' + LeInformacao(11,0).AsString ); end; end; end; [/code] Observe que o campo 11 é capturado pelo Índice, enquanto NSU e Rede pela propriedade com o nome específico... A vantagem de usar as propriedades é que sua aplicação fica mais simples de migrar para um novo tipo de TEF, já que o ACBrTEFD tenta abstrair as diferenças entre eles, "mapeando" os diferentes retornos de cada classe TEF nas mesmas propriedades