Daniel Simoes

Faz muito tempo que escrevi essas rotinas e realmente não lembro de todos os passos... Lembro porém, que inicialmente usávamos a linha de comando (o que era muito mais simples, mas menos seguro, para Desktop) http://www.madboa.com/geek/openssl/#digest-file

SIM, ficará mais lento... Esse parâmetro efetua uma pausa de N milissegundos antes de enviar o próximo comando ao ECF...

Anexe o Log no momento onde você faz o pagamento

Você está fazendo errado... A forma de pagamento Dinheiro na FiscNet é -2 Vc deve usar o índice de forma idêntica ao retornado pelo ACBrECF, em CarregaFormadPagamento Lembrando que cada marca tem uma metodologia de índice

Não.. o Bartender envia toda a etiqueta como uma Imagem... usando o driver da impressora do windows... funciona bem (rápido) se você irá imprimir várias etiquetas iguais...

Não.. Isso é controlado pela impressora Mas vc pode imprimir apenas a barra, e depois posicionar um texto logo abaixo com o mesmo conteúdo numérico

não com o Tipo de Código EAN13... tente usando o tipo 3of9 ou 2of5

EAN-13 SEMPRE tem digito verificado... caso contrário não é EAN13 Se você quer código livre use outro formato, como 3of9

No site do fabricante

Não é nada comum ter falhas no envio dos comandos: Isso está ocasionando a duplicação... o ACBrECF não detecta o ACK do ECF e transmite o comando novamente.. Deve ser algum problema no seu virtualizador de Portas Seriais...

Não compreendi a sua mensagem... A impressora não imprimirá códigos EAN com o digito verificador inválido... mas acho que você pode mandar 12 caracteres e deixar que ela calcule o 13°

Difícil... não parece estar relacionado ao ACBrECF, e sim do seu sistema... O Demo é a prova disso... Você programou algum dos eventos do componente ? O único jeito é ir passo a passo com Debug desde o início...

Não há um bug assim... caso contrário ninguém conseguiria usar o ACBrMonitor... Uma analise dos Logs gerados pelo ACBrMonitor e ACBrECF deve resolver esse mistério

Pode ser direitos de permissão no compartilhamento... Experimente modificar em ACBrDevice.pas as seguintes linhas: 55 {$IFDEF FPC} 56 {$DEFINE Use_Stream} 57 {$ENDIF} para: {$DEFINE Use_Stream}

A descrição do motivo da alteração está no Changelog do ACBrTEF

A Epson não retorna a Data do Movimento nos Dados da última Redução Z... Veja: //Esta função utiliza o comando "Obter Totais da Jornada (09 0D)", que aceita //como parâmetro um CRZ. Então para obter os totais da última redução, passamos o //CRZ atual, que guarda o número da última redução Z. Os campos retornados pelo //comando estão abaixo: //Campo Tipo Tamanho //1-Número da Redução Z N 4 //2-Número do COO N 6 //3-CRO N 6 //4-Venda Bruta Diária N 14 //5-Total F N 13 //6-Total I N 13 //7-Total N N 13 //8-Total FS N 13 //9-Total IS N 13 //10-Total NS N 13 //11-Total Canc. ICMS N 13 //12-Total Canc. ISS N 13 //13-Total Canc. NF N 13 //14-Total Desc. ICMS N 13 //15-Total Desc. ISS N 13 //16-Total Desc. NF N 13 //17-Total Acre. ICMS N 13 //18-Total Acre. ISS N 13 //19-Total Acre. NF N 13 //20-Total ICMS N 13 //21-Total ISS N 13 //22-Total NF N 13 //23-Data de Fechamento RZ (D) 8 //24-Hora de Fechamento RZ (H) 6 //25-Totalizador Geral N 17 //n+25-Percentual do Totalizador parcial N 4 //n+26-Total vendido N 13 Então como o ACBrECFEpson faz ? Ora, o projeto ACBr é código aberto, lembra ? Então basta abrir a sua IDE no fonte ACBrECFEpson.pas e procurar por: "DadosUltimaReducaoZ" Agora lendo os fontes com mais calma, veja as observações existentes na linha 3328 de ACBrECFEpson.pas { Epson não retorna a Data do Movimento e SIM a Data de Fechamento da Z tentando descobir se o Fechamento ocorreu no dia correto do movimento } if (not (ECFEst in [estBloqueada, estRequerX])) and // Ainda não abriu a Jornada (DataFechaZ < DataMov) then begin if DateOf( DataFechaZ ) = DateOf( DataMov ) then DataMov := EndOfTheDay( IncDay( DateOf( DataFechaZ ), - 1) ) else DataMov := DataFechaZ; end; Como você pode ver, nem sempre o truque acima irá funcionar...

Pode ser algo no cabo da USB... pois quando a USB é removida, a porta serial é removida do Windows

No SiTef (usado a CliSiTef) as transações são atômicas (semelhante a uma transação de Banco de Dados)... Ele confirma ou cancela todas as pendentes...

Vc precisa achar uma fonte que dê o efeito desejado.. Veja esse manual, que é mais completo (mas em inglês) https://svn.code.sf.net/p/acbr/code/tools/Argox/PPLA&PPLB.pdf

Na IDE do Delphi você pode desabilitar "Stop on Delphi exceptions"

Sim... notei que há um bug relacionado a isso no Demo... mas como vc disse, basta restaurar o estado de fCancelado para False... Atualmente fiz várias modificações no meu Demo (experiências) e por isso não posso commitado.. Quando tiver um tempo reverto as modificações e corrijo esse bug...

o componente não foi projetado para ser usando sem ECF... Precisará de uma grande reforma... ou a criação de outro componente... Outra alternativa são os ECFs virtuais...

Notei que há muitos erros de transmissão do comando ao ECF... e isso faz com que o componente envie novamente o comando... Provavelmente há alguma configuração no driver que possa melhorar a comunicação... (como baixar os buffers da porta serial)

Realmente não há memória para o DadosUltimaReducaoZ no .INI... (mas isso é de possível de implementação) O Número de Série e outras propriedades do ECFVirtual você deve definir no próprio componente ACBrECFVirtualNaoFiscal

Experimente um nome de compartilhamento mais simples... \\localhost\PPLA ou ainda tente com o @ \\localhost\@PPLA