Problema No Acbrpaf

[xyberx]

 Semana passada homologamos aqui na Faesa, e tivemos os seguintes problemas :

 

 1 - O campo VL_TOTAL do RegistroD2.RegistroD3 quando o valor era 4,20 o registro gerado em TXT estava dando o valor 4.19 e o valor do item era 4,20 dando diferença de valor, para acertar para homologação fiz VL_TOTAL      := StrToFloat(FormatFloat('###########0.001', ibqRegistroD3.FieldByName('VALOR_LIQUIDO').AsCurrency)) aí funcionou.

 

 2 - o Campo de número do DAV foi exigido que fosse preenchido com zeros a esquerda ao invés de espaços.

      RegistroD2

      NUM_DAV        := FormatNumDAV(ibqRegistroD2ID_COD.AsString);

 

      onde

 

       Function FormatNumDAV(Valor : String; LengthS : Integer = 12) : String;

       Var

        I : Integer;

       Begin

        Result := Valor;

        For I := Length(Valor) To LengthS Do

         Result  := '0' + Result;

       End;

 

 Os casos acima foram resolvidos deste jeito porém caso for ajustado no ACBrPAF farei as alterações no meu código para ficar certo com o ACBr.

 

 VLW a todos e mais uma homologação feita com ACBr....

[Régys Silveira]

Quanto ao ponto 1, o ACBrPAF somente grava o que foi passado ele não efetua nenhum cálculo então não tem como ele arredondar ou mudar o valor, inclusive fiz testes aqui com valores bem quebrados, ele grava sempre o que passo.

 

Quanto ao ponto 2, alguns homologadores não aceitam com zeros e outros não aceitam com espaços então o caminho é enviar já formatado ao componente para que ele grave como foi pedido.

[xyberx]

Quanto ao ponto 1, o ACBrPAF somente grava o que foi passado ele não efetua nenhum cálculo então não tem como ele arredondar ou mudar o valor, inclusive fiz testes aqui com valores bem quebrados, ele grava sempre o que passo.

 

Quanto ao ponto 2, alguns homologadores não aceitam com zeros e outros não aceitam com espaços então o caminho é enviar já formatado ao componente para que ele grave como foi pedido.

 

 Bom no caso 1, acho que este você pode ter se enganado, pois o valor era o mesmo, e caso tenha algo que faça trunc isso pode ocorrer, tanto que no meu caso tive que coloca o 0,001 a mais no valor para ele deixar o valor com os 4,20 corretos, até porque antes de fazer o que fiz, conferi o retorno do dado que vinha do Dataset, verifiquei várias coisas e somente isso resolveu.

 Quando se usa trunc para retirar zeros pode sim ocorrer essas coisas, quando eu trabalhava em uma grande contabilidade aqui de vitória tive problema similar e tive que retirar o trunc e fazer um copy da parte decimal pois dava arredondamentos em alguns casos esporádicos e por incrível que pareça deu comigo na homologação a mesma situação mais como eu já havia passado por isso, fiz o teste conforme citei acima e aí sim funcionou.

 

 o campo que apresentou a diferença foi VLT_DAV        := StrToFloat(FormatFloat('###########0.001', ibqRegistroD2TOTAL_LIQUIDO.AsCurrency)); do RegistroD2. 

 Só errei em enumerar mais a solução foi a mesma. quando você ia no item, se não me engano o valor era formatado com #0,000 e o valor do DAV era #0,00 e no caso do #0,00 dava esse erro de valor.

 Só aconteceu com agente aqui no item que o valor dele era 4,20 em outros DAVs não dava esse erro, no Banco estava correto, no Delphi vinha o valor correto mais no arquivo apresentava a diferença sitada.

 

 Inclusive várias pessoas que conheço também tiveram problemas de arredondamento no Delphi e a solução segue sempre a mesma lógica : http://fabio.omachi.com.br/?p=228 a que uso ou http://gustavohinterholz.blogspot.com.br/2011/11/funcao-de-arredondamento.htmlque é mais gambiarra.

 O caso da que uso fiz exatamente igual a do fabio porém em 2009 que foi quando tive esse problema a outra solução é muito mais gambiarra mais funfa também.

 

 Caso precisem de alguma coisa, acho que estou com o Banco da homologação aqui separado mais não consigo posta pois não tenho espaço para anexo...

Editado 2 Dezembro, 2014 por xyberx

[EMBarbosa]

Sobre esse caso 1, pode ser um problema semelhante ao que foi apresentado na função LFill. Vejam

 

Talvez fosse bom um test case para validar a necessidade da alteração.

[Régys Silveira]

Se não for incomodo poderia me enviar o banco por email, assim eu posso entender melhor o que houve, talvez o tipo de dado utilizado ou que seja um bug no componente, porque aqui realmente não acontece utilizando o firebird e numeric.

 

Se possível enumerar o registro que deu o problema.

[xyberx]

Se não for incomodo poderia me enviar o banco por email, assim eu posso entender melhor o que houve, talvez o tipo de dado utilizado ou que seja um bug no componente, porque aqui realmente não acontece utilizando o firebird e numeric.

 

Se possível enumerar o registro que deu o problema.

 

 Manda um mail pra mim que te passo o anexo [email protected] ou [email protected] é na hora....

 Já até separei o banco aqui pra você....achei o da homologação....

Editado 2 Dezembro, 2014 por xyberx

[xyberx]

 Manda um mail pra mim que te passo o anexo [email protected] ou [email protected] é na hora....

 Já até separei o banco aqui pra você....achei o da homologação....

 

 Conforme o combinado, enviado para seu email...VLW

[xyberx]

Se não for incomodo poderia me enviar o banco por email, assim eu posso entender melhor o que houve, talvez o tipo de dado utilizado ou que seja um bug no componente, porque aqui realmente não acontece utilizando o firebird e numeric.

 

Se possível enumerar o registro que deu o problema.

 

 E aí amigão, conseguiu dar uma olhada no problema ???

[Régys Silveira]

Recebi o arquivo, mas ainda não tive tempo de olhar com calma, assim que conseguir já retorno aqui no tópico.

[xyberx]

Recebi o arquivo, mas ainda não tive tempo de olhar com calma, assim que conseguir já retorno aqui no tópico.

 

 Show, no aguardo...

 Apesar de já ter dado uma solução para homologação, mais se alguém precisar por enquanto, pode usar a solução citada que vai funcionar...VLW

[EMBarbosa]

Sobre esse caso 1, pode ser um problema semelhante ao que foi apresentado na função LFill. Vejam

 

Talvez fosse bom um test case para validar a necessidade da alteração.

Respondendo minha própria pergunta.

Este caso está relacionado com o caso do LFill apresentado no outro tópico.

 

Adicionei hoje testes unitários expondo todos esses problemas.  Só faltou o link pra esses tópicos... 

 

Até semana que vem vou poder resolver esse problema, espero que definitivamente.  

 

EDIT: Para reproduzir, não é necessário outro Banco de dados. Basta apenas modificar no programa de exemplo do ACBrPAF a linha no uFormPrincipal.pas do método btn.RegistrosPAFClick conforme abaixo:

      for j := 1 to 2 do
      begin
        with RegistroD3.New do
        begin
          DT_INCLUSAO   := DATE;
          NUM_ITEM      := i;
          COD_ITEM      := '10';
          DESC_ITEM     := 'descricao do item';
          QTDE_ITEM     := 10.00;
          UNI_ITEM      := 'UN';
          VL_UNIT       := 1.00;
          VL_DESCTO     := 0.00;
          VL_ACRES      := 0.00;
          VL_TOTAL      := 4.20; //<---- Erro no arredondamento na hora que gera o arquivo.
          SIT_TRIB      := 'T'; // T, S, I, N, F
          ALIQ          := 7.00; // SOMENTE QUANDO T E S
          IND_CANC      := 'N';
          DEC_QTDE_ITEM := 2;
          DEC_VL_UNIT   := 2;

Editado 19 Dezembro, 2014 por EMBarbosa
Adicionada info de como reproduzir no programa de exemplo

[EMBarbosa]

O Daniel postou uma correção para esse problema hoje. E pelos meus testes está tudo OK.
Eu na correção do Daniel. Mas após analisar melhor, achei por bem deixar as modificações dele, inclusive nas units de teste.

 

Abaixo a explicação:

Hmm... entendi o que acontece para retornar apenas a string com o delimitador, mesmo o valor não sendo zero.

O fato é que o número de decimais passado por parâmetro ao método LFill é 6.
Neste caso, o TruncFix será calculado de 0,00000001 * 100000 (= 0,001) e retornará 0.
Daí, na chamada do próximo LFill será passado para o parâmetro Nulo como True.
Embora o valor inicial tenha sido diferente de 0, o atual vai ser e isso resultará na string só com o delimitador.

Isso poderia ser alterado passando "(Nulo) and (Value = 0)" como parâmetro ao invés de apenas a variável nulo, como abaixo:

  if (strCurMascara <> '#') and (strCurMascara <> '') then
     Result := FDelimitador + FormatCurr(strCurMascara, Value)
  else
  begin
     AInt := TruncFix(Value * intP);
     Result := LFill(AInt, Size, ((Nulo) and (Value = 0)), Caracter); //<- Considerar a situação inicial e não apenas a variável Nulo
  end;
end;

Só que eu imagino que isso talvez não seja o esperado. Então preferi não fazer essa alteração.

Então estou deixando isso documentado aqui no fórum para futura referência.

[xyberx]

 Pelo que entendi vocês usam TRUNC que nunca recomento, no meu caso como trabalhei com escrita fiscal e contabilidade com Delphi, ao invés de TRUNC eu copiava até a quantidade de casas que eu queria, não tinha arredondamento e vinha o número exato que eu queria, pq o TRUNC é meio variável de acordo com o tipo numérico que se usa, talvez não seria adequado fazer o que eu falei, copiar a parte do valor ao invés de Truncar-lo????

[EMBarbosa]

No contexto apresentado, não foi detectado nenhum problema. Você tem algum exemplo em que pode gerar problema?

[xyberx]

No contexto apresentado, não foi detectado nenhum problema. Você tem algum exemplo em que pode gerar problema?

 

 Só o do Banco que mandei para o Regis mesmo, nele tem a linha exata que me deu o problema... caso queira o mesmo para testes mande um mail para [email protected] com o assunto relativo ao tópico que lhe mando o Banco, como era banco de homologação os dados não são de clientes mesmo é tranquilo...

[EMBarbosa]

Só o do Banco que mandei para o Regis mesmo, nele tem a linha exata que me deu o problema... caso queira o mesmo para testes mande um mail para [email protected] com o assunto relativo ao tópico que lhe mando o Banco, como era banco de homologação os dados não são de clientes mesmo é tranquilo...

Ah, obrigado. Mas o problema que você citou já foi corrigido juntamente com outros problemas semelhantes conforme os posts acima e no tópico que eu mencionei antes.

Se tiver outros casos no BD que não estejam sendo resolvidos pelo código atual, cujo commit foi feito hoje, aí sim eu gostaria de ver os valores.

Mas não precisa do BD. Só dos valores mesmo.

 

Ah, e obrigado por ter reportado o erro.

[xyberx]

 VLW. Não esquenta que não somente usamos, mais ajudamos a construir algo mais utilizável, se não posso no momento contribuir com códigos, posso contribuir com testes, o importante é todos ajudarem, pois vejo que ferramenta aberta tem 98% sugas e 2% ajuda....

 Eu tinha um site de Torrents há um bom tempo, sei como é isso kkkkk....