Daniel Simoes

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)

Verifique se você tem as DLLs corretas do fabricante na mesma pasta do seu aplicativo... Ou se existem DLLs do fabricante antigas, no Path da máquina...

Pode ser quer o Driver do Windows não esteja corretamente instalado... Vc consegue imprimir uma página de testes do Windows ?