daniel.simoes

Apenas com o LOG gerado pelo ACBrECF poderemos saber o que exatamente o ACBrECF leu do ECF...

Uma resposta bem mais adequada para o caso da "LeituraX" viewtopic.php?p=2612#p2612

Rossine, vc pode criar um passo a passo para a reprodução do problema ?

Provavelmente vc precisa aumentar o TimeOut.... No meu caso, não trato a ReduçãoZ com try/except... pois o tempo pode variar muito de acordo com o ECF e com o movimento do usuário... Comando a RedZ e depois analiso o Estado do ECF... se ele estiver em estBloqueado a RedZ foi emitida com sucesso...

Basta vc programar algo no Evento ACBrECF.OnMsgPoucoPapel, que o ACBrECF não emitirá mais a msg O valor é de quantos em quantos segundos o ACBrECF verifica pela proximidade do fim do papel (pouco papel, e não fim de papel) O problema é realmente no sensor do ECF... Geralmente os ECFs da Bematech precisam de um ajuste no sensor da bobina... o até mesmo, inutilizar esse sensor com uma fita isolante, ou algo parecido

Acho que esse comando não foi implementado... Nunca vi a utilidade desse comando... lembre-se que o Cupom Adicional não é uma copia do Cupom anterior

Parece que elas foram realmente programadas com o "V" na frente... Por favor tente colar aqui uma imagem da Leitura X deste ECF... Mas esse é o LOG gerado pelo ACBrMonitor... copie aqui o LOG gerado pelo ACBrECF (veja na aba ECF do Monitor)

Somente o fabricante pode saber o que significa o "Cod 3"... - Tente com o programa de Demo da Bematech... - Verifique se todas as DLLs necessárias estão na pasta do Programa .EXE

Isso é uma características apenas de ECFs matriciais, que por determinação legal, emitem uma Leitura X sempre antes de um Relatório gerencial... Não há como mudar isso... Ou seja, não é o ACBr que faz isso, mas sim o ECF... (a não ser que vc troque de ECF )

Tudo que o TEFD faz é chamar o EXE do GP com ShellExecute... Parece ser um problema do GP e não do TEFD.... você pode deixar o nome do EXE vazio, assim o TEFD não tentará executa-lo e ele deverá ser executado manualmente (isso é permitido na homologação)

Vc não deve usar o Emulador e o Demo na mesma porta Serial... Veja o link: http://www.forumweb.com.br/foruns/topic ... -bematech/

Basicamente SIM... Apenas quando houver algum nova propriedade declarada como "Published", ou seja, que apareça no Object Inspector, é que é necessário re-instalar o Package (isso gera um novo arquivo .BPL que é utilizado pela IDE). Fora isso, desde que o seu LibPath esteja configurado corretamente com os diretórios dos fontes do ACBr, basta compilar o seu projeto.

Qual é o arquivo acusado de vírus ? E qual é o log de msg do VirusTotal ?

Junior, Atualmente no ACBr todas as rotinas são "componentes"... pois facilita o uso... seria necessário modificar isso... Quem é o autor original ? Também Seria necessário um Demo que atendesse duas necessidades: - Teste por completo e de preferencia de forma automatizada todas as propriedades e métodos do componente, - Demonstre/Ensine os usuários como usar o componente

Se o ECF for MFD vc poderia fazer o Download da memória MFD usando um aplicativo fornecido pelo Fabricante do ECF, e com esse mesmo programa, salvar o cupom em RTF ou TXT... Mas isso é muito, muito lento e difícil, pois os programas fornecidos pelos fabricantes não são muito amigáveis

Verifique se a pasta do ACBrDiversos está no seu LibPath do Delphi

SIM, já está no SVN

Consegui um desses, mas com conexão TCP/IP... mas infelizmente ainda não tive tempo nem de liga-lo Acho que seria o caso de criar um derivado desse componente para o pacote ACBrTCP

o valor estará em Resp.ValorTotal...

Os homologadores querem ter certeza que você tem domínio sobre os fontes responsáveis pelo TEF... por isso é bom ter conhecimento do ACBrTEFD

Thiago, por favor seja mais claro... não foi possível compreender o seu problema...

Tente assim: { Verificando se essa Resposta já foi cancela em outro arquivo } JaCancelado := False ; I := 0 ; while (not JaCancelado) and (I begin if (RespostasCanceladas[I] is TACBrTEFDRespTXT) or (Tipo = gpVeSPague) then begin with TACBrTEFDResp( RespostasCanceladas[I] ) do begin JaCancelado := (Resp.Rede = Rede) and (Resp.NSU = NSU) and (Resp.Finalizacao = Finalizacao) and (Resp.ValorTotal = ValorTotal) ; end; end else begin with TACBrTEFDResp( RespostasCanceladas[I] ) do begin JaCancelado := (Resp.DocumentoVinculado = DocumentoVinculado) ; end; end; Inc( I ) ; end; [/code] afinal sempre é bom verificar se a transação já foi cancelada

Hummm agora que notei o IF if RespostasCanceladas is TACBrTEFDRespTXT then (incrível como a gente esquece o que escreveu) Acho que a final de contas a sua alteração faz sentido... apenas no caso do SiTEF, que o cancelamento deve ser feito apenas 1 por documento (ele já cancela todas as transações pendentes para esse documento)... acho que o V&SPague não faz isso... Vou aplicar no SVN

O GP se comportará de forma muito estranha nesse teste (mas não lembro exatamente como)... Por favor entre em contato com as homologadoras e verifique... Na verdade, tudo que eles querem "verificar" e se a aplicação imprime o comprovante mesmo com o Valor diferente...

Analise o Log gerado pelo ACBrECF... veja se ele realmente mandou 2x o Item...