giulianon

Boa tarde Daniel! Agora sim \o/ Fiz uns ajustes: - Aumentei pra 10 segundos o timeout da espera pelo cmc7, pois no modelo ST2000, essa leitura é mais lentinha, e estava retornando o erro que a ecf não estava respondendo durante a leitura. - Ajustei ali o retorno pra pegar exatamente o cmc7 function TACBrECFSwedaSTX.LeituraCMC7: AnsiString; var OldTimeOut: Integer; begin Result := EnviaComando('24|1|0|1000'); { Leitura do CMC7 deve retornar mais dados } OldTimeOut := TimeOut; try TimeOut := max(OldTimeOut,10); // Espere mais 10 segundos... GravaLog( ' Aguardando Resposta CMC7'); LeResposta; fpRespostaComando := fsRespostasComando ; // Respostas Acumuladas GravaLog( ' Retorno Completo: '+fpRespostaComando ); { Limpando de "fpRespostaComando" os Status não solicitados } fpRespostaComando := AjustaRetorno( fpRespostaComando ); GravaLog( ' Retorno Tratado: '+fpRespostaComando ); Result := copy(fpRespostaComando,35,36); // Verificar finally TimeOut := OldTimeOut; end; end; Bom acho que é isso. Agora posso mudar tudo pra ecfSwedaSTX. Muito obrigado mais uma vez, pela atenção e pela solução Daniel! Grande abraço! Att.

Bom dia Daniel! Testei novamente e aparentemente o resultado da CMC7 só não foi retornado pela função LeituraCMC7, pois observei no log que você colocou e nele tem o retorno. A função continua retornando o resultado do comando 24 bem sucedido. Segue anexo pra você dar uma analisada. Acho que está mais perto =) Att. acbrlog.txt

Bom dia Daniel! Teste feito, mas sem sucesso. Mesma coisa. No ecf teste, ao mandar ler o cmc7, recebo a resposta que comando de leitura foi executado com sucesso (24+) e para por ai. Segue log da operação conforme solicitado. Se tiver disponibilidade, posso lhe passar um acesso remoto da máquina que está a ecf, delphi com acbr, para que você possa acompanhar. Att. acbrlog.txt

Bom dia Daniel! A sequência seria: 1 - O comando 24 é enviado para ecf informando para ela entrar em "estado" de leitura de cmc7. 2 - A ecf responde com +24, informando que o comando foi processado com sucesso e entra em estado de leitura de cmc7. 3 - A partir desse momento, se o cheque já estava posicionado, ou caso ele seja posicionado nessa hora, as alterações de status (!) vão ser enviadas, e teria que iniciar o monitoramento do que vem da ecf, ignorando as alterações de status até o recebimento do cmc7. Aplicação (24) -> Ecf Aplicação (24+) <- Ecf Aplicação (24!0109) <- Ecf Aplicação (24!0200) <- Ecf Aplicação (24!0110...CMC7) <- Ecf Seria isso.

Testei. O ECFTeste se comporta de forma idêntica ao exemplo da sweda. Recebo a resposta de que o comando para leitura foi enviado com sucesso, e a partir dai a ecf fica aguardando para que o cheque seja inserido.

Ok! Vou testar.

Ah e outro detalhe Daniel! Conforme a imagem do post http://www.djsystem.com.br/acbr/forum/viewtopic.php?p=38606#p38606 Aquela primeira alteração de status (24+) antes do comando para leitura ser enviado, é informação de que o sensor identificou o cheque sendo inserido, mas no caso, sem ter enviado o comando para a leitura. Se eu ficar colocando o tirando o cheque, sem nunca enviar o comando para ler, fico recebendo essa alteração de status. Att.

Boa tarde Daniel! Demorei um pouco pra responder porque o exe da sweda, não sei porque raios trava quando abre a porta serial no meu pc. Bom ai instalei o Delphi 7 em outra máquina, e lá a leitura funcionou certinho. O que acontece é que aquela primeira linha que vem, sem a !, na verdade é a resposta da ecf que o comando 24 de leitura foi processado com sucesso. Tanto que eu fiz o seguinte, mandei fazer a leitura sem ter inserido o cheque, e ai vem essa resposta. A partir do momento que o cheque é inserido, ai sim vem as alterações de status (!). Att.

Bom dia Daniel! Já fiz update no svn e testei novamente, mas o retorno foi o mesmo. Depurando, percebi que não passa pelo bloco que você alterou, pois no retorno, o tipo é + em vez de ! if Result and (Tipo = '!') then // Bloco de Satus não solicitado, Verificando begin Erro := StrToIntDef( copy(Bloco,6,4), 0 ) ; if not (Erro in [ 0, 52, 110, 216, 240 ]) then begin GravaLog( ' VerificaFimLeitura: Bloco (!) Descartado: '+Bloco, True) ; Result := False ; end end ; Segue anexo o log para análise. Att. acbrlog.txt

Como não tenho D7, baixei a versão do ApdComPort, e fiz um teste com a ecf, e realmente, depois dessas alterações de "status", vem o código CMC7, conforme a tela do teste em anexo. Acho que o tratamento para o retorno desse comando, teria que ser diferente, certo? Att.

Boa tarde Daniel! No email da sweda:

Obrigado pela ajuda Daniel. Segue anexo o exemplo que me foi enviado pela Sweda. Att. Comunicação Direta - STX Vinculado e CMC7.zip

Bom dia Daniel! Depois de algum tempo consegui parar pra poder tentar implementar a leitura de CMC7 na classe ACBrSwedaSTX. É a única função que ainda me impede de mudar da classe ACBrSweda para ACBrSwedaSTX. Bom mas vamos lá! Seguindo o manual da sweda para o protocolo stx e um exemplo que solicitei a própria sweda, criei a função override na classe ACBrSwedaSTX com o comando para a leitura. function TACBrECFSwedaSTX.LeituraCMC7: AnsiString; begin result := EnviaComando('24|1|0'); end; O exemplo da sweda é feito com o AsyncFree usando os métodos do próprio componente para leitura e escrita, apenas fazendo o devido tratamento do retorno como segue abaixo. Function TForm1.LeituraBuffer(): String; // Leitura do Buffer Var Checksum : String; TResposta:string; retorno:string; tam: integer; LerBuffer:integer; begin Lerbuffer:=1; while LerBuffer =1 do begin retorno:= AfComPort1.readstring; tam:=Length(retorno); if (tam>1) and (retorno[tam-1] = #3) then // Etx begin TResposta := TResposta+ Copy(retorno,1, tam-1); Checksum:=CalculoCS(Pchar(TResposta)); if Checksum = retorno[tam] then Begin TResposta:=TResposta+ retorno[tam]; LerBuffer:=0; Result:=TResposta; AfComPort1.WriteChar(Char (6)); // enviar ACK para confirmar a leitura da REsposta break; end else begin Result:='#21'; AfComPort1.WriteChar(Char (21)); // enviar NACK para erro de leitura da REsposta LerBuffer:=0; Showmessage('Nak' + TResposta); break; end; end else if tam =0 then sleep (100) else begin TResposta:=TResposta+retorno; end; end; end; Ao executar o método implementado ali na classe ACBrSwedaSTX, a impressora faz o processo de leitura, puxando e ejetando o cheque normalmente, mas o retorno vem algo como na imagem em anexo. Uma coisa que eu percebi foi que esse retorno vem praticamente na hora que a ecf puxa o cheque, ou seja, bem antes dela efetivamente ler o cheque. Tentei mexer em timeout, mas não resolveu. Depurando até o método do synaser que faz a leitura da porta, pude perceber que o retorno vem exatamente como na imagem em anexo. Gostaria de uma ajuda pra tentar identificar onde pode estar o problema Agradeço desde já ao Daniel e aos colegas por qualquer dica, sugestão, etc. Att.

É verdade. Mas como eu procuro dar update e já instalar, o "sincronismo" fica mantido, =D. Att.

Ué! Então acho que eu to viajando. Sempre me baseio na opção Show Log do Tortoise. Achei que a linha em negrito era a revisão que eu tenho na minha máquina. o.O

No meu caso o paf opera integrado ao erp, e caso o cliente não pague no prazo previsto, o erp é bloqueado, impossibilitando que ele altere qualquer informação, como por exemplo preços, clientes, etc. Dessa forma as informações buscadas pelo paf junto ao erp para operar são desfasadas. No caso do pessoal que tem paf e erp em um sistema só, sugiro no caso do não pagamento, o bloqueio de funções ou telas de uso diário e essenciais para o trabalho. Dessa forma o acesso ao menu fiscal fica liberado conforme pede a lei, e você obriga o cliente a manter os pagamentos em dia. Att.

Qual emulador de porta serial você está usando? Já testou o com0com? Dê uma olhada nesse link Att.

Na teoria o foco fica com o teu sistema sim, mas como eu disse se você usa um tef que não é background esse foco pode ir pra outra janela. Também pode ter alguma dialog do teu sistema, dialog do teu sistema, ou mesmo uma dialog do windows (ex: relatório de erro) que pode aparecer. Essa "marvadas" acabam indo pra atrás da janela principal do sistema e ainda levam o foco. Eu não uso elas no pdv justamente pra evitar. Mensagem de qualquer tipo (erro,autenticação,confirmação) eu uso um form próprio pra exibir. A tecla fica reservada sim, mas você pode desativar a hotkey (UnRegisterKey) quando abrir em uma tela que precise usar essa tecla, e ativar novamente ao fechar a tela. Com essas duas medidas eu não tive mais problemas. Att.

Então Luciano. Seria alterar no registro do windows para o mesmo não iniciar o explorer e sim a sua aplicação. procedure GravarRegistro(const path, name, value: string; root: cardinal); begin with TRegistry.Create do try RootKey := root; OpenKey(path, False); WriteString(name, value); finally Free end end; Incluir no shell GravarRegistro('Software\Microsoft\Windows NT\CurrentVersion\Winlogon','shell','c:\seu_sistema.exe',HKEY_CURRENT_USER); Remover no shell GravarRegistro('Software\Microsoft\Windows NT\CurrentVersion\Winlogon','shell','',HKEY_CURRENT_USER); Foi assim que eu fiz. Criei no menu do sistema a opção para incluir e remover do shell. A opção para incluir uma tecla que jogue o foco para sua aplicação também é boa. // Declaração da procedure procedure WMHotkey(var Msg: TWMHotkey); message WM_HOTKEY; procedure WMHotkey(var Msg: TWMHotkey); begin case Msg.HotKey of 1: begin Application.BringToFront; end end; end; // Registra a tecla C (67) como tecla do foco RegisterHotkey(Handle, 1, 0, 67); UnRegisterHotkey(Handle, 1); É isso! Espero ter ajudado! Att.

Bom, eu tinha problemas nesse sentido, principalmente relacionados a abertura de janelas do client do tef. Então o primeiro passo foi usar um tef com client em background. Outra modificação foi colocar o sistema no shell, ou seja, não abrindo o explorer, para evitar os "balões" do windows e notificações de outros sistemas que também perdiam o foco. E por último coloquei no sistema uma hotkey, que em caso de perda do foco, o operador pressiona uma tecla joga o foco novamente na aplicação. Desde então não tive mais problemas com isso. Mas essa opção que você falou de não ter campos com foco também é possível, mas não creio que resolva, pois como eu disse, as vezes a aplicação como todo perde o foco.

Você disse que acontece no primeiro item, mas esse log que você postou trata da finalização do cupom. Pra poder tentar encontrar o problema seria interessante você conseguir um log completo onde ocorreu o problema. Outra coisa é que você está utilizando o a classe ecfSweda. Tente utilizar a classe ecfSwedaSTX que é a indicada para impressoras fisicais com MF. Att.

Esse tópico trata disso. Dê uma olhada. viewtopic.php?f=10&t=4477&p=22473&hilit=data+daruma#p22473 Att.

De uma olhada nesse tópico. Att.

Eu uso try except. try ACBrECF.AbreCupom(CPF, Cliente, Endereco); // grava dados except // trata end; Mas se quiser usar o try finally, consulte o estado da ecf antes de gravar para ver se o cupom foi realmente aberto. No exemplo ECFTeste.exe que acompanha a instalação do ACBr mostra como verificar o estado da ECF. De uma olhada no evento OnErrorAbreCupom também. Att.