ACBrECF Problema estranho com redução Z

[dantemartins]

Escrevi uma rotina pra logar as Reduções Z da seguinte forma:

    AssignFile(LogRedZ, ExtractFilePath(Application.ExeName) + '\Log\RedZ-' + FormatDateTime('yyyymmdd',gdtMovimento) + '.log');

    Rewrite(LogRedZ);

    WriteLn(LogRedZ, ' <<>>>>>>> Dados da Redução ANTES da REDUÇÃO Z ser comandada <<<<<<<>>');

    ACBrECF1.Ativar;

    Write(LogRedZ, ACBrECF1.DadosReducaoZ);

    WriteLn(LogRedZ, '');

    WriteLn(LogRedZ, '');

    WriteLn(LogRedZ, ' <<>>>>>>> Dados da Redução DEPOIS da REDUÇÃO Z ser comandada <<<<<<<>>');

    ACBrECF1.ReducaoZ;

    Write(LogRedZ, ACBrECF1.DadosReducaoZ);

    CloseFile(LogRedZ);

    ACBrECF1.Desativar;

Apenas em alguns logs aparece o "DEPOIS", e a Red. Z na impressora é feita normalmente...

[Régys Silveira]

O método ACBrECF1.DadosReducaoZ deve sempre ser chamado antes de emitir a redução Z, se emitido depois as informações são zeradas.

[dantemartins]

O método ACBrECF1.DadosReducaoZ deve sempre ser chamado antes de emitir a redução Z, se emitido depois as informações são zeradas.

Acho que você não entendeu.

O problema é que não é gravada a segunda parte, é como se após comandada a redução Z fosse abortada a procedure.

E pior, não é sempre, pois tem vezes que tem as duas partes do log (antes e depois da red z).

[Daniel Simoes]

Use um Try Except e faça o tratamento do Erro (exception) levantado

[André Ferreira de Moraes]

Após a redução Z use ACBrECF.DadosUltimaReducaoZ.

[dantemartins]

Use um Try Except e faça o tratamento do Erro (exception) levantado

Está dentro de um try/except.... não da erro algum, só não executa o restante da procedure... sinistro...

[Daniel Simoes]

isso é o correto... Se houver exception em: ACBrECF1.DadosReducaoZ o resto das linhas nunca será executado...

[dantemartins]

isso é o correto... Se houver exception em: ACBrECF1.DadosReducaoZ o resto das linhas nunca será executado...

Acontece assim:

1 - No arquivo de log aparece as informações do primeiro ACBrECF1.DadosReducaoZ, portanto o metodo foi executado corretamente.

2 - É chamado o metodo ACBrECF1.ReducaoZ, pois o comando é executado na Impressora Fiscal.

3 - As veses grava e as vezes não no log a segunda chamada a ACBrECF1.DadosReducaoZ. É como se abortasse a execução da procedure logo após a chamada a ACBrECF1.ReducaoZ (vezes sim, vezes não).

[Régys Silveira]

Funciona assim,

Utilize ACBrECF1.DadosReducaoZ para obter os dados da redução Z antes de executar o método ACBrECF1.ReducaoZ, se executar depois ele realmente sai em branco, sem nada.

Utilize ACBrECF1.DadosUltimaReducaoZ para obter os dados da redução Z depois de emitida a Redução Z.

Essa é a forma correta de utilizar os métodos.

[Vially Israel]

Acho que entendi o problema...

no caso o log "Depois da Redução Z ser comandada" hora é gravada e hora não é... é isso mesmo?

Caso seja, em um teste aqui que eu precisei fazer algo parecido com oq vc fez (executar um determinado comando após a redução z) aconteceu a mesma coisa.

O que deu pra entender (no meu caso) é que mesmo quando a impressora está emitindo a redução z, em um determinado momento (não sei se por problema do ecf ou do acbr) o status passa a ficar livre, que teoricamente a redução estaria impressa, e ao tentar executar o próximo comando (procedure) na impressora, por ela ainda está imprimindo a redução z, mostraria status como ocupado e daria um erro.

[Daniel Simoes]

Sim, isso é possível... pois a redução Z é demorada, e o tempo pode variar...

O ACBrECF implementa em cada classe um mecanismo para saber se o ECF está ocupado, imprimindo... Geralmente isso é feito solicitando o flag de Satus ou ainda a Data/hora do ECF... se o mesmo não for capaz de responder, ele (ACBrECF) entende que o ECF está ocupado imprimindo

Pode ser que o ECF tenha sido capaz de responder a essa solicitação entre o término da Impressão do relatório e no inicio da impressão do BitMap

[Vially Israel]

Daniel foi o que me veio na cabeça também, eu acho que quando ela termina de imprimir os dados da redução z e vai começar a imprimir o bitmap nessa fração de segundos a impressora fica livre e volta a fica ocupada.

Mas isso é tempo suficiente para um teste retornar status livre

[Daniel Simoes]

Acho que isso não deva ocorrer em todos os ECFs...

Qual era mesmo a marca e modelo do ECF ?

[Vially Israel]

Comigo aconteceu na Bematech MP 2100 e na Daruma FS700

[Daniel Simoes]

Estranho pois uso no dia a dia esses ECFs, e não tive problemas semelhantes...

[Vially Israel]

Eu acho que vai depender do tamanho do bitmap, quando é apenas um "quadrado" parece (não lembro, eu fiz o teste a um bom tempo) que dá certo, mas quando são vários (o que é comum na bematech) já não da mais certo.

[Régys Silveira]

Aqui eu imprimo reduções Z com mais de 1 metro de comprimento tanto na Daruma quanto na Bematech e não acontece isso não, são vários quadrados de bitmap.

[nazarenoneto]

Se no caso for gerado uma exception de access violation, posso ser que o problema seja o seguinte. No evento OnBobinaAdicionaLinhas do ACBrECF, estaja igual ao demo que tem o seguinte código:

  WB_LoadHTML(wbBobina, mBobina.Text);

  Application.ProcessMessages ;


  WB_ScrollToBottom(wbBobina);

Que serve justamente para simular a bobina da impressora.

Mas provavelmente você esteja passando um TWebBrowser (wbBobina) que não foi criado ou instanciado, dai o exception.

Mas isso se você utilizar esse comando para reproduzir sua bobina.

[dantemartins]

O meu problema é que chamo ACBrECF1.DadosReducaoZ para pegar os dados necessários para SINTEGRA e SPED, chamo uma rotina que insere numa tabela (firebird) e aproveito pra salvar num txt, chamo ACBrECF1.ReducaoZ e a impressora emite a Red Z de boa, na sequencia eu leio novamente ACBrECF1.DadosReducaoZ e gravo no txt, meio que como uma prova de que foi executada msm.

Isso tudo ta dentro de um bloco try/except, se sair sem erros é chamado o commit pra gravar as informações no DB.

Não da erro algum, nada aparece no log (txt) nem na tela da aplicação. Pro operador parece ter dado tudo certo, mais os dados não foram comitados no DB e a segunda parte do log, ou seja, a segunda vez que chamo ACBrECF1.DadosReducaoZ e gravo no txt simplesmente não aparece.

Como já disse em post anterior, parece que durente o processo de execução da Red Z a procedure que a chamou é abortada...

Uma informação que fiquei sabendo esses dias é que o Cliente usa um "adaptador usb" pra ligar a Impressora Fiscal e um PINPAD (TEF) na mesma porta...

De longe fica muito difícil debugar, sou de Curitiba/PR e o Cliente está em Goiás

[EMBarbosa]

Olá Dante,

Não há uma possibilidade de algum dos comandos do ACBrECF gerar uma exceção (Exception) mas seu software não estar logando a mesma? Pergunto pois tive um problema parecido mas com o Firebird. Ele não conseguia abrir a porta de eventos e gerava erro na aplicação só no modo debugger. Foi difícil descobrir o erro, mas conseguimos verificando o arquivo firebird.log na pasta do Firebird.

[André Ferreira de Moraes]

O meu problema é que chamo ACBrECF1.DadosReducaoZ para pegar os dados necessários para SINTEGRA e SPED, chamo uma rotina que insere numa tabela (firebird) e aproveito pra salvar num txt, chamo ACBrECF1.ReducaoZ e a impressora emite a Red Z de boa, na sequencia eu leio novamente ACBrECF1.DadosReducaoZ e gravo no txt, meio que como uma prova de que foi executada msm.

Isso tudo ta dentro de um bloco try/except, se sair sem erros é chamado o commit pra gravar as informações no DB.

Não da erro algum, nada aparece no log (txt) nem na tela da aplicação. Pro operador parece ter dado tudo certo, mais os dados não foram comitados no DB e a segunda parte do log, ou seja, a segunda vez que chamo ACBrECF1.DadosReducaoZ e gravo no txt simplesmente não aparece.

Como já disse em post anterior, parece que durente o processo de execução da Red Z a procedure que a chamou é abortada...

Uma informação que fiquei sabendo esses dias é que o Cliente usa um "adaptador usb" pra ligar a Impressora Fiscal e um PINPAD (TEF) na mesma porta...

De longe fica muito difícil debugar, sou de Curitiba/PR e o Cliente está em Goiás

Após emitir a redução Z vc deve chamar o comando ACBrECF.DadosUltimaReducaoZ.

[dantemartins]

Após emitir a redução Z vc deve chamar o comando ACBrECF.DadosUltimaReducaoZ.

Devo entender que o meu problema é que estou chamando uma segunda vez a mesma função e não deveria faze-lo... é isso?

Eu entendi que, para obter os valores da ultima redução Z deve-se chamar "DadosUltimaReducaoZ" e não "DadosReducaoZ" como estou fazendo, mais meu objetivo era ter uma leitura com os dados antes da redução e depois uma leitura depois, a que traz os dados zerados mesmo, como uma prova em TXT que o comando foi executado com sucesso.

Dada a forma da ultima resposta eu poderia pensar que o fato de eu chamar uma segunda vez "DadosReducaoZ" estaria provocando o problema que eu estou tendo, mais se fosse isso, não explicaria a intermitencia do problema, pois não é sempre que acontece.

[dantemartins]

Qual seria a melhor forma de testar se já é possível mandar outro comando a impressora?

Testar o estado seria satisfatório?

Testar algumas vezes pra ter certeza ?

[Daniel Simoes]

Qual seria a melhor forma de testar se já é possível mandar outro comando a impressora?

Testar o estado seria satisfatório?

Testar algumas vezes pra ter certeza ?

é exatamente isso que o ACBrECF faz quando a propriedade AguardaImpressao := True

Veja nos fontes o método Interno: VerificaFimImpressao

[Endrigo Rodrigues]

Tente o seguinte:

  ECF_ACBR.Device.ProcessMessages := False;