Daniel Simoes

Acho que não será problema mudar para String... Vou testar no Lazarus e D7

Vamos tentar um pouco mais... Vamos observar a resposta do TimeOut... O que ocorre se vc enviar o comando como: function TACBrECFSwedaSTX.LeituraCMC7: AnsiString; begin Result := EnviaComando('24|1|0|1000'); end; [/code] Ou seja, com 1 segundo de TimeOut... Por favor copie o trecho do Log gerado pelo ACBrECF...

A Bematech não tem em sua DLL um comando que permita envio e recebimento direto de comandos... já conversei com o "Luize" sobre isso... mas acho que não existe nenhuma previsão de implementação...

Apliquei a seguinte correção nos fontes do SVN

O que ocorre se o usuário não inserir o cheque ? O que o ECF faz (ou envia) enquanto o Cheque não é posicionado ? Quanto tempo devemos considerar de TimeOut entre o 24+ e o próximo envio ? Sinto muito, mas acho que não serei capaz de fazer essa rotina sem um ECF para testes...

Não compreendi a sequencia de comandos necessária... Infelizmente acho que será muito difícil implementar isso sem um ECF para testes...

Tente no ECFTeste, porém sem inserir o cheque antes de comandar a leitura... O fato é que se o ECF responder com '+', a comunicação está encerrada.. ou seja, ele precisa responder '!'

Ok, obrigado pela informação... Vou modificar o componente para garantir que ele seja sempre enviado...

Mas o que é o campo 004 afinal ? O ACBrTEFD trabalha com diversos G.P.... e infelizmente não consigo lembrar de detalhes específicos de todos eles... Se a informação do 004 deve constar em todos, isso provavelmente deve ser alterado no componente...

E o que são todos esses números ?? De qual TEF estamos falando ??

Tópico dividido para uma melhor organização viewtopic.php?f=10&t=7145

Mas segundo a imagem que foi postada na resposta viewtopic.php?p=38606#p38606 ele deveria retornar "!0000"... Se não ocorrer o flag de mudança de status, não há como saber que devemos continuar lendo.... Tente com o Demo da Sweda em sua Impressora e observe os resultados

Não sei se compreendi o post... Más observe que os Métodos CRT e CHQ são functions, ou seja, retorna True apenas se a transação foi efetuada e aprovada com sucesso

No dedicado não há este problema, a confirmação ou não confirmação de um documento tem efeito sobre todas as transações efetuadas dentro dele... e não haverá impressão de Gerencial, apenas um aviso para o Operador reter o cupom...

Ola Augusto, Parabéns pela sua homologação... Sinto muito não ter aproveitado suas modificações nos fontes originais... mas através delas, acredito que consegui modificar a classe original para suportar o Cielo Premia e adicionar um tratamento na Inicialização para Confirmar as Transações pendentes no caso do Cupom já haver sido impresso com sucesso (isso já era feito na classe do CliSiTEF)... Se possível, por favor atualize sua cópia do SVN (após um backup dos seus fontes), e teste as alterações efetuadas... Sei que é difícil mexer nos seus fontes atuais, agora que já está homologado... mas se possível, por favor efetue testes nos pontos mais críticos, usando o projeto TEFDDemo.

Veja o documento "Fluxo múltiplos cartões", lá está a regra a seguir... Lembre-se que a transação TEF deve SEMPRE ser cancelada independente do estado do ECF.... De acordo com o documento "Fluxo múltiplos cartões", você deve ficar em loop até ser capaz de efetuar todos os Cancelamentos de Transações já confirmadas, e enviar a Não Confirmação para a última transação efetuada (pois ela ainda não foi confirmada)... Porém..... o CNC sempre imprime um relatório de cancelamento (gerencial)... Algo que vc não conseguirá efetuar com o ECF desligado ou com algum documento pendente, ou seja... Múltiplos Cartões no TEF discado tem muitos "furos"... mas não se preocupe com eles, o roteiro de testes é o guia a ser seguido, e todos os testes são de possível execução...

Ok... Enviei correções para o projeto abrir corretamente no D7... e as seguintes modificações

Mandei algumas alterações para o SVN, que devem nos fornecer melhor subsidio para uma implementação final... Fiz no escuro, baseado na Imagem fornecida pelo e-mail da Sweda... Vamos ver no que dá...

Humm.. pelo que notei tb pode ser necessário adicionar o erro '0' na lista...

Pelo que percebi do Emulador ele não responde com a mudança do Status.. não tenho como testar... Por favor tente modificar a Linha 715 para: if not (Erro in [ 52, 109,110, 200, 216, 240 ]) then (Adicione o 109,110 e 200 na lista de exceções de erro)

ACBrECF.procedure PafMF_GerarCAT52(const DataInicial, DataFinal: TDateTime; const DirArquivos: String); ( foi incluída recentemente nos fontes, embora essa função seja apenas um "wrapper" para o método há muito já existente: ACBrECF1.ArquivoMFD_DLL )

Vc deve buferizar todos os pagamentos, e só enviar para o ECF quando tudo estiver completo (atingir o Sub-Total do cupom)... Se não fizer dessa maneira nunca será compatível com o Cielo Premia.... Estou atualizando o Demo do TEFD com alguns exemplos...

Junior, Até onde sei, Saque é obrigatório.. (estive recentemente na Sw.Express e Certified) Sempre é o G.P. que fala com o Pin-Pad... no caso do SiTEF até existe um comando para vc mandar suas msgs ao PinPad... mas isso é outra estória... Todas as rotinas do ADM são tranquilas... no máximo um relatório será impresso...

Detectei o problema usando o D7, no XE2 abriu normalmente... Já envio uma correção assim como outras implementações que estou terminando

Acho que é algo no seu Delphi ou na instalação do ACBr, pq não temos relatos semelhantes de outros usuários... Infelizmente não uso (mais) o Delphi, uso Lazarus, seria bom se algum usuário de Delphi pudesse analisar...