Daniel Simoes

Sim, é o mesmo caso que o Juliomar está falando... Talvez seja mais elegante criar propriedades para essas funcionalidades... Alguém se habilita ?

Veja no Demo do TEFD como adicionar linhas na Requisção antes do envio para o TEF procedure TForm1.ACBrTEFD1AntesFinalizarRequisicao(Req : TACBrTEFDReq); begin if Req.Header = 'CRT' then Req.GravaInformacao(777,777,'TESTE REDECARD'); Memo1.Lines.Add('Enviando: '+Req.Header+' ID: '+IntToStr( Req.ID ) ); end;

Acho que nunca consegui essa informação no emulador do TefDial... mas no emulador do SiTEF funciona...

Vale lembrar que se você usar a Serial do Host através de uma máquina Virtual, ainda há outra camada... A máquina virtual provê um túnel que acessa a serial do Host, e nesse caso, no lado da máquina virtual não há como saber se a Serial no Host é USB ou uma Serial física

Tente esse fragmento de código: { Atualizando TEFLOG com Transações CANCELADAS } for I := 0 to ACBrTEFD1.RespostasPendentes.Count-1 do begin with ACBrTEFD1.RespostasPendentes[I] do begin { Se tiver NSU da Transação Cancelada atualize em TEF Log } if (pos(Header, 'ADM|CNC') > 0) and (NSUTransacaoCancelada <> '') then

O NSU da transação original você deve saber... afinal ele é parâmetro necessário para o CNC, ou seja, foi você mesmo que informou o CNC para o TEFD OnDepoisConfirmarTransacoes só será disparado em transações que precisam de confirmação (CNF)... ATV por exemplo, não dispara o mesmo

Talvez o tópico seja esse:

Você poderia usar o modelo gpTefDial e configurar os diretórios para onde está o Cliente do SiTEF

Você poderia usar o modelo gpTefDial e configurar os diretórios para onde está o Cliente do SiTEF

Por favor abra um novo tópico para um outro assunto... Leia as regras: http://www.projetoacbr.com.br/forum/index.php?/forum-3/announcement-1-sim-n%C3%B3s-temos-regras/

Acho que não temos nada do gênero... Porém SIM, seria interessante desenvolver... Se possível (e permitido), anexe a documentação no Tópico

Vá por partes... isole o problema... primeiro tenha certeza de que as DLLs do fabricante estão corretamente instaladas... Use o Demo em Delphi do próprio fabricante e tente gerar o arquivo... tendo sucesso nessa etapa,a faça testes no ECFTeste... mais um sucesso, agora sim, teste na sua aplicação... contate o suporte do fabricante se tiver problema logo no primeiro passo...

Você deve ter resolvido o seu problema devido a outro ajuste... Pois no seu fonte, você continua usar a função antiga... BematechFunctionDetect( 'Bematech_FI_ArquivoMFD',@xBematech_FI_ArquivoMFDPath ); ou seja, apenas o nome da variável que contem o endereço para o método que foi modificada...

Se desejar sugerir alguma correção, por favor anexe os fontes alterados para analise... Evite o máximo possível o uso de APIs do Windows, já que o ACBr é multiplataforma... Se compreendi o problema, a DLL está gerando o arquivo em pasta diferente da informada no BemaFi32.INI ? Se SIM, isso me parece mais um Bug da DLL A DLL está na mesma pasta da sua aplicação ?

No tópico 1 a classe está vazia porque você não chamou ACBrECF1.DadosReducaoZ para popular ela...

Pode ser que o tamanho de área do código esteja muito pequeno (espremido)... ou a temperatura da Impressora muito alta (borrando)...

Experimente simplesmente remover todos os Casts... Eles foram inseridos mais para evitar Warnings do D2007 em diante... o problema é que nesse caso pode ser que atrapalhemos a vida desses usuários... Mudar simplesmente os casts para ACBrStr() com certeza traria perda de informação importante... O ACBrECF usa muito AnsiString como um "String binário"... o ACBrStr tentaria interpretar isso... Acho que alguma diretiva de compilação como: {$H+} pode resolver o seu problema...

Acho que o método poderia ser modificado para incluir um último parâmetro que pode default recebesse False, algo como: function TACBrCNIEE.BuscarECF(const AMarca, AModelo, AVersaoSB: String; RemoveEspacos : Boolean = False): TACBrCNIEERegistro; if RemoveEspacos then begin MarcaAtual := StringReplace(MarcaAtual,' ','', [rfReplaceAll]); ModeloAtual := StringReplace(ModeloAtual,' ','', [rfReplaceAll]); VersaoAtual := StringReplace(VersaoAtual,' ','', [rfReplaceAll]); end; Assim não afetaria o código de projetos já existentes...

O valor de IntervaloAposComando está muito alto... isso deixará tudo mais lento... mas realmente ele pode resolver problemas de comunicação... eu uso valores de 0 a 100 Anexe o LOG com o erro para analise...

Mude isso no seus fontes, e provavelmente você terá seus problemas corrigidos... ACBrECF1.Device.ProcessMessages := False ; Isso fará o ACBrECF interromper a Thread principal (o Application) enquanto ele trabalha... Porém seu programa pode ter o efeito de ficar "congelado" em algumas situações de comunicação demorada... Ou seja, o mesmo comportamento das DLLs ...

Não consegui decifrar no Log o que houve... aparentemente foi o que você disse mesmo... o ECF estar em um estado não confiável devido a troca de protocolo... Recebimento Não fiscal é uma confusão... Cada ECF trabalha de uma maneira para Sangria/Suprimento e recebimento não fiscal... o método "NaoFiscalCompleto" tenta abstrair essas diferenças

Leia o manual de PPLA e PPLB disponível em: https://acbr.svn.sourceforge.net/svnroot/acbr/tools/Argox/

Tente com o Demo em Delphi da própria Bematech... se nem nele funcionar, só o suporte da Bematech poderá resolver... Meu palpite é que você está tentando gravar o arquivo em C:\... Hoje em dia o Windows não permite isso

Acho que você já leu no tópico que a Zebra não usa PPLA... Porem, sem uma impressora para testes será praticamente impossível...

O EasyTEF é outro componente, comercial, e com um excelente suporte... No video ele usa o ACBrECF para permitir o uso de Linux nos exemplos... O ACBrTEFD é o componente do ACBr para TEF discado e dedicado... (o ACBrTEFD nasceu bem depois do EasyTEF)