Dados Redução Z

[Ivan de Souza]

Bom dia a todos!

 

Estou tendo problemas de gravação da redução Z e gostaria de saber qual é o indicado nesse caso: uso o DadosReducaoZ antes ou depois de emitir a Redução Z?

 

Fiz vários testes e o que se comportou melhor foi antes da ReduçãoZ. Mas uma coisa que eu notei é que há uma intermitência de erros na hora da geração desses dados. Ora vem faltando valor total de ISSQN, outras vem faltando todos os valores totais, GRG, etc ...

 

Eu uso assim:

 

frmPrincipal.ecfImpressora.DadosReducaoZ;

cEcfSerie := frmPrincipal.ecfImpressora.DadosReducaoZClass.NumeroDeSerie;
cCRZ := IntToStr(frmPrincipal.ecfImpressora.DadosReducaoZClass.CRZ+1);
cCOO := IntToStr(frmPrincipal.ecfImpressora.DadosReducaoZClass.COO+1);
cCRO := IntToStr(frmPrincipal.ecfImpressora.DadosReducaoZClass.CRO);
dDataMovimento := frmPrincipal.ecfImpressora.DadosReducaoZClass.DataDoMovimento;

rVendaBruta := frmPrincipal.ecfImpressora.DadosReducaoZClass.ValorVendaBruta;

iCCF := frmPrincipal.ecfImpressora.DadosReducaoZClass.CCF;
iCFD := frmPrincipal.ecfImpressora.DadosReducaoZClass.CFD;

 

etc .... depois grava na minha base e tiro a redução.

 

Para os testes, uso uma Daruma FS700 a 115200. Em alguns clientes com Bematech 2100 a 9600 de velocidade costuma nem ler essas informações. Alguma dica sobre o correto uso dessa função para resolver esse problema?

 

Obrigado a todos!

 

Ivan

[Daniel Simoes]

Você deve usar a leitura de DadosReducaoZ instantes antes de emitir a Z... e está correto o procedimento de somar 1 ao CRZ e COO

Esse método é mais seguro, pois ele lê cada registrador/totalizador individualmente

 

Após a Z todos os registrador/totalizador são todos zerados.. então chamar DadosReducaoZ não funcionará... Após a Z use DadosUltimaReducaoZ.

Esse método usa comando específico do ECF para retornar em um "linguição de dados" as informações da última Z emitida... Porém, a informação retornada depende muito de cada fabricante... e muitos dos registradores/totalizadores não são retornados, por isso eles são preenchidos na Classe como "-1" ou "" (vazio)

 

O ideal é usar ambos os métodos... e fazer uma mesclagem com as informações de ambos, dando preferência a informação de DadosUltimaReducaoZ (caso ela exista)

[Régys Silveira]

Escrevi um pequeno artigo sobre esse assunto, se for do interesse dê uma conferida em: http://www.regys.com.br/lendo-dados-da-reducao-z-utilizando-o-acbr/

[Ivan de Souza]

Regys, o link que vc passou está quebrado. Gostaria de ler seu artigo.

 

Daniel, então eu terei que pegar as informações de DadosReducaoZ antes da RZ e de DadosUltimaReducaoZ depois da RZ para finalmente mesclar e gravar na minha base, certo?

[Ivan de Souza]

Agora o link funcionou. Obrigado, Regys!

[Daniel Simoes]

Regys, o link que vc passou está quebrado. Gostaria de ler seu artigo.

 

Daniel, então eu terei que pegar as informações de DadosReducaoZ antes da RZ e de DadosUltimaReducaoZ depois da RZ para finalmente mesclar e gravar na minha base, certo?

 

Sim, tomando o cuidado para desprezar as informações inválidas (que o ECF não retornou) em DadosUltimaReducaoZ

[Ivan de Souza]

Ok, Daniel, Muito obrigado!

 

Vou testar aqui e posto o resultado!

[Ivan de Souza]

Daniel,

 

Fiz do jeito que você me sugeriu, porém quando mando executar o comando DadosUltimaReducaoZ ele me dá a mensagem de erro:

 

"01/02/13" is not a valid date and time.

 

Essa é a data que meu ECF está atualmente. E esse erro é dentro da classe.

 

Sabe me dizer o que pode ser?

 

Obrigado,

 

Ivan

[Régys Silveira]

Você tem como depurar e verificar o exato ponto onde o erro ocorre, porque aqui tanto com Daruma quanto com Bematech funcionou 100%.

[Ivan de Souza]

Depurei aqui e ele me traz:

 

DataDoMovimento := StringToDateTime( copy(RetCmd,1,2)+DateSeparator+

copy(RetCmd,3,2)+DateSeparator+

copy(RetCmd,7,2), 'dd/mm/yy' );

 

Isso dentro da classe da Daruma.

Daí teria que mudar na classe, pois a maioria dos formatos de data vem no formato "dd/mm/yyyy".

 

Sugestões?

[Ivan de Souza]

Se eu colocar no meu fonte:

 

 

FormatSettings.ShortDateFormat := 'dd/MM/yy';

FormatSettings.DateSeparator := '/';

 

antes de gerar os DadosUltimaReducaoZ funciona 100%

[Daniel Simoes]

Qual a versão do seu Delphi ?

 

O que vc está fazendo já é (ou deveria ser) feito pela function ACBrUtil.StringToDateTime

 

Function StringToDateTime( const DateTimeString : String;
   const Format : String = '') : TDateTime ;
 Var
    OldShortDateFormat, AStr : String ;
begin
  OldShortDateFormat := ShortDateFormat ;
  try
     if Format <> '' then
        ShortDateFormat := Format ;

     AStr := Trim( StringReplace(DateTimeString,'/',DateSeparator, [rfReplaceAll])) ;
     AStr := StringReplace(AStr,':',TimeSeparator, [rfReplaceAll]) ;

     Result := StrToDateTime( AStr ) ;
  finally
     ShortDateFormat := OldShortDateFormat ;
  end ;
end ;

[Régys Silveira]

Depurei aqui e ele me traz:

 

DataDoMovimento := StringToDateTime( copy(RetCmd,1,2)+DateSeparator+

copy(RetCmd,3,2)+DateSeparator+

copy(RetCmd,7,2), 'dd/mm/yy' );

 

Isso dentro da classe da Daruma.

Daí teria que mudar na classe, pois a maioria dos formatos de data vem no formato "dd/mm/yyyy".

 

Sugestões?

O padrão ddmmyy e o padrão de retorno adotado para essa informação no ECF Daruma, por isso que foi programado assim.

Estranho no seu não rodar, aqui está rodando 100%, qual é o ambiente que está utilizando?

[Ivan de Souza]

Uso Delphi XE3, Windows 7 64 bits, MySql 5.0 Community.

 

Nos testes que eu fiz, tanto o DadosReducaoZ e DadosUltimaReducaoZ trouxeram as mesmas informações. Inclusive não trouxeram o Geral de Operação Não Fiscal.

[Daniel Simoes]

Pode ser isso... no XE2, mudou o tratamento a todos "FormatSettings"...

 

Pelo que analisei rapidamente... em vários pontos do código podem haver problemas... pois em vários momentos é usada a modificação de ShortDateFormat

[Ivan de Souza]

Eu faço esse tratamento dentro do meu fonte sempre que preciso gravar os dados no banco, pois gravo com comandos SQL. Então eu faço:

 

FormatSettings.DecimalSeparator := SEPARADOR_DECIMAL_BD[1];
FormatSettings.DateSeparator := SEPARADOR_DATA_BD[1];
FormatSettings.ShortDateFormat := FORMATO_DATA_BD;

 

mudando para as configurações do banco e

 

 

FormatSettings.DecimalSeparator := SEPARADOR_DECIMAL_SOFT[1];
FormatSettings.DateSeparator := SEPARADOR_DATA_SOFT[1];
FormatSettings.ShortDateFormat := FORMATO_DATA_SOFT;

voltando para as configurações do painel de controle.

 

Então sempre que puxar os dados da redução ou qualquer outro comando do ECF vou ter que mudar para o padrão de comunicação do ECF?

[EMBarbosa]

O Delphi XE3 acho que aposentou de vez o padrão antigo de formatação que não era ThreadSafe.

 

Acho que deveríamos estudar uma maneira de atualizar o código do ACBr para que ficasse compatível com todas versões do Delphi.

 

As funções de conversão que aceitam um parâmetro de formatação estão disponíveis desde o Delphi 7 e acredito que estejam disponíveis no Lazarus também. Mesmo porque quem usa o ACBr num sistema Multithread corre risco de perder essa formatação ou atrapalhar o funcionamento do aplicativo em outro lugar.

[EMBarbosa]

Então sempre que puxar os dados da redução ou qualquer outro comando do ECF vou ter que mudar para o padrão de comunicação do ECF?

 

Esse é um meio incorreto de utilizar as funções. Seu aplicativo não funcionaria corretamente num ambiente com várias trheads. O correto seria criar uma instância de um TFormatSettings e passá-lo como parâmetro para as funções de formatação.

[Daniel Simoes]

O Lazarus já sinaliza o uso direto dos registradores de TFormatSetting como depreciado, ou seja a mudança seria compatível com o Lazarus

 

O problema são as IDEs Delphi inferiores ao XE2

[EMBarbosa]

Daniel,

 

 até onde sei, não há problema nenhum com o Delphi 7 e superiores. Existe a classe o record TFormatSettings no Delphi 7.

[Daniel Simoes]

Uma possível correção seria:

 

{$IFDEF DELPHIXE_UP}FormatSettings.{$ENDIF}ShortDateFormat := 'dd/mm/yy' ;
{$IFDEF DELPHIXE_UP}FormatSettings.{$ENDIF}DateSeparator := '/' ;

 

Em muitos lugares o código existente poderia ser substituído por uma chamada a ACBrUtil.StringToDateTime

 

Mesmo assim daria um trabalho insano...

[Ivan de Souza]

Um trabalho insano mas necessário caso se busque a compatibilidade do ACBr com todas as versões do Delphi.

Mas acho que por enquanto isso pode ficar a cargo do programador em colocar em sua versão Delphi as alterações necessárias, tais como faço no meu fonte.

Acredito que mesmo num sistema MultiThread funcionaria o uso do FormatSettings antes do comando ACBr. 

[Daniel Simoes]

ilsousa,

 

Nem todas as classes de ECF usam "dd/mm/yy"... ou seja, o seu código ainda pode "quebrar"

[EMBarbosa]

Acredito que mesmo num sistema MultiThread funcionaria o uso do FormatSettings antes do comando ACBr. 

 

Não. Só funciona se você não manipular datas em outras threads. Mesmo assim, se você estiver usando a formatação do sistema operacional, nada garante que um outro aplicativo faça o mesmo e atrapalhe o funcionamento do seu aplicativo.

[Ivan de Souza]

ilsousa,

 

Nem todas as classes de ECF usam "dd/mm/yy"... ou seja, o seu código ainda pode "quebrar"

 

Entendi. Isso acontece com o separador de decimal também? Ele usa o DecimalSeparator = '.' ?