Erro Qtd Enviada <> Qtd Cupom - Daruma Fs600 E Fs700

[ericserafim]

Caros,

 

Preciso de ajuda na seguinte situação:

 

Meu cliente possui várias lojas com ecf FS700 e FS600, em algumas lojas ocorre do cupom sair com a quantidade digitada no sistema diferente da impressa no cupom, ou seja a impressora recebeu uma quantidade inferior a digitada no sistema.

 

Ativei o log dos comandos enviados e notei que o envio do comando para a rotina vende item, fica diferente no parâmetro quantidade quando o erro acontece, isso vendendo a mesma quantidade do mesmo produto ou produto diferente (aqui tanto faz, o problema está na quantidade e não no preço).

 

Isso ocorre de forma aleatória na mesma ECF vendendo os mesmos produtos e mesma quantidade. Em um dos casos o cliente reiniciou o PC e tudo voltou a funcionar!

 

A impressora está configurada para 3 casas decimais na quantidade e o parâmetro DecimaisQtd também está com 3.

 

Segue o log dos comandos:

 

Quando o erro não acontece, note que a quantidade é enviada com 3 casas decimais.

17:38:16:064 VendeItem( 013759 , RICCA PINCA DEPIL POTE UNID , FF , 1 , 0,98 , 0 , UN , $ , D , -1 )

                TX -> [FS]F[207]1700010000000098000000000000018013759        UN ARICCA PINCA DEPIL POTE UNID[255]e

17:38:16:376 RX <- :0000000[207]003000000000098[CR][250]

 

 

Quando o erro acontece, note que quantidade é enviada com 2 casas decimais.

17:55:21:001 VendeItem( 018282 , VEFIC SEC ESMALTE 200ML , FF , 1 , 12,98 , 0 , UN , $ , D , -1 )

                TX -> [FS]F[207]1700001000001298000000000000018018282        UN AVEFIC SEC ESMALTE 200ML[255]s

17:55:21:298 RX <- :0000000[207]001000000000130[CR][251]

 

Segue um exemplo de cupom impresso onde o problema ocorre.

 

Gostaria de saber se alguém tem ideia porque este erro ocorre?

 

[Juliomar Marchetti]

Pode o log completo pra poder ajudar!

[ericserafim]

Segue o log, a última venda do arquivo é a que está com erro.

ECF_Log.txt

[Daniel Simoes]

No modelo da Daruma, você não deve modificar o numero numero de casas decimais do Preço ou Qtd por código...  Esse ECF não suporta mudar essa propriedade, que deve ser definida no momento da lacração

 

O componente lê do ECF o numero de casas decimais programados e ajusta nas propriedades...

[Daniel Simoes]

Como esse problema é recorrente... Apliquei uma modificação nos fontes da Daruma para ignorar a modificação de DecimaisQtd e DecimaisPreco

Rev: 7079

[ericserafim]

Olá Daniel,

Estamos nos desviando do problema... Se o componente ignora esta propriedade porque lê da ecf e mesma está configurada para 3 casas na quantidade, porque o envio do comando vendeitem é enviado com 2 casas?

Vide os detalhes na primeira iteração.

Grato

[Daniel Simoes]

Por que em algum momento nos seus fontes, após ter ativado o componente, você provavelmente está modificando o valor dessa propriedade...

 

Veja: Se um bug tão básico assim existisse... Teríamos MUITOS pedidos de suporte aqui no fórum.. pois isso inviabilizaria o uso dessa classe..

 

- Use o seu Debug... pare na linha 2294 de ACBrECFDaruma.pas e veja o valor de fpDecimaisQtd e fpDecimaisPreco... observe como essa variáveis influenciam a montagem da String que é enviada para o ECF

 

- Teste com o ECFTeste

 

- Teste com os novos fontes...

[ericserafim]

Daniel,

 

Como dito o problema acontece as vezes... quanto a modificar a propriedade fpDecimaisQtd depois de ativar, não procede, visto que configuro o componente e somente depois o método Ativar é invocado.

Sim eu notei que o comando utiliza este field para enviar para a serial e justamente por este motivo que estou intrigado com esse erro esporádico.

 

O que o cliente me relatou é que o problema acontece no meio da tarde, ou seja, depois de realizar diversas vendas no ECF.

Pegando a configuração da máquina que opera com a ECF, notei que a mesma roda Windows XP com apenas 256MB de RAM, com processador celeron...

 

Olhando com mais detalhe o comando de vendeItem, notei que o mesmo utiliza a função POWER que é assembler puro em todas os seus overloads, o que me ocorre é um possível problema de memória, seria possível isso estar gerando esta inconsistência na rotina POWER?

[Daniel Simoes]

Acho pouco provável... a explicação mais simples é alguma condição muito específica estar modificando as propriedades de QtdDecimais...

 

Hoje ha um "SetQtd..." (vazio), na classe da Daruma... você poderia modificá-lo para gravar algo no Log e com isso tentar entender de onde ele poderia estar vindo...

[ericserafim]

Obrigado Daniel,

 

 

Já realizei a geração do log quando a propriedade é alterada, agora é aguardar o uso do cliente para eu tentar descobrir qual sequência de comandos está alterando as decimais da quantidade.

 

Retorno com os resultados

[ericserafim]

Daniel,

 

Problema resolvido, acontece que me determinado momento (sequência de ações) o meu sistema estava enviando os dados novamente para o componente e ativando o mesmo sem desativar, neste caso alguns comandos de inicialização não eram executados, deixando a propriedade DecimaisQtd com 2.

 

Agradeço a ajuda.