Problemas no Código de Barras e Valor Total (diferença de 0,01 centavos)

[farnetani]

Pessoal estou com um problema inusitado, ou seja, só acontece

numa respectiva máquina do cliente. Na minha máquina quando vou

simular a mesma situação não se repete. O problema na verdade está

aleatório, ou seja, de vez em quando acontece na máquina dela.

 

O problema está relacionado ao código de barras e o valor do boleto que

está apresentando uma diferença de 0,01 centavos no código de barras.

 

Estou com os componentes atualizados.

 

Alguém saberia me dizer o que pode ser isso? Sinistro demais!

 

O problema é que isso está causando um problema inclusive no fechamento da contabilidade (diferenças de 0,01).

A princípio acho que o problema poderia estar até mesmo no Sistema Operacional / Processador...porque nos meus

fontes não existe programação pra esse tipo de situação acontecer.

Segue a tela em anexo.

 

[Juliana Tamizou]

Boa noite.

A informação utilizada para montar a linha digitável e imprimir o valor do boleto vem da mesma propriedade e o componente não faz nada para alterar. O mesmo ocorre em outro computador do cliente?

Att.

[farnetani]

Pois é...o mais interessante, o erro acabou de acontecer. 

Foi isso que eu analisei também.

Mas foi assim, acabei de fazer o teste e o aconteceu o erro de diferença pra maior de 0,01.

Aí fechei todo o sistema e gerei novamente e foi certo.

O que pode ser isso? Já formatamos a máquina e instalamos novamente o windows 7 (original).

Pode ser problema da máquina?

[farnetani]

Juliana, o que eu notei é como se o componente em alguns casos tivesse carregado 0,01 centavos de diferença. Isso também aconteceu na hora de gerar o arquivo remessa. Fechando o sistema e reabrindo novamente o erro desaparece. Tenho a suspeita que o problema está relacionado ao processador/memória do micro, pois o mesmo já foi formatado (eliminando o sistema operacional e vírus).

[Lucas Fernando Matias]

Farnetani, bom dia.

Você descobriu do que se trata este problema ?

É que eu estou com o mesmo problema, estou com os fontes atualizados pelo Trunk2.

Em um primeiro momento achei que seria algum problema de arredondamento, então antes de passar qualquer informação ao boleto já me certifiquei que estou utilizando sempre 02 casas decimais, exatos 2 casas, já passo arredondado e mesmo assim o problema persiste, mas assim como no seu caso, as vezes aparece as vezes não aparece.

Se achou a solução ou a fonte do problema e puder compartilhar eu agradeço.

[farnetani]

Pois é...também fiz como você, utilizei um rounddec para me certificar que eu não estivesse fazendo besteira.

O que notei foi que isso ocorre quando eu utilizo o componente AcbrNFse...a solução para o problema foi 

fechar o sistema após a nota ser emitida/gerada e abrir novamente...RESUMINDO, não achei aonde está

o problema, mas ao meu ver, é como se ficasse esse 0,01 na memória...O que fiz também para evitar isso

foi tipo uma verificação no arquivo REMESSA, ou seja, após eu gerar o arquivo eu valido ele novamente

buscando o título e comparando...pois mesmo eu informando por exemplo (as vezes) 120,00, ele insistia

em jogar 120,01...já pensei que pudesse ser vírus, etc...mas NOTEI isso, depois que eu utilizo as funcionalidades

do componente ACBRNFSe e já gero o boleto, o mesmo pega esse 0,01 a mais vindo do NADA!!!

Se vc descobrir, por favor compartilhe!!!

Abraço!

[Agnaldo Prates]

Boa tarde.

Não foi com o Boleto mas, com a NFe houve um caso desses comigo. Depois de analisar todo o meu código descobri que havia uma varável que era alimentada e ao final do processo esta não era zerada o seu valor.

Debuguei todo o AcbrBoleto, em especial a Unit referente ao Itau, e não observei nada de anormalidade. É importante que ao gerar o boleto certifique que é exatamente aquele valor se não há uma variável perdida com o 0,01 centavo.

[JoaoPauloRicardo]

boa tarde, eu não se o o vosso problema é parecido com o que tivemos aqui. mas durantes uns tempos tb nos apareceu esse problema (diferenças de 0.01 nos totais). depois de perder tempo (mto tempo), acabei por chegar a conclusão que o problema não é somente programação, era o firebird mesmo e o raio da virgula flutuante quando se fazem os arredondamentos (isto também está relacionado com o modo de criar os campos, tem de escolher o tipo certo para evitar este problema, que sucede em especial nos campos float) . 

resumindo uma longa história, pk trocar os tipos de campo não era possível de momento, acabei por recalcular e controlar os totais num array, garantindo assim 100% de valores corretos quando vou lançar na nfe. Tudo isto para dizer que é possível que o código esteja correto, mas são os dados que estragam tudo.

[Lucas Fernando Matias]

Exato, em um primeiro momento achei que fosse exatamente este ponto flutuante, então modifiquei toda a rotina a fim de sempre trabalhar com 2 casas, tanto no banco como no Delphi, mas ainda assim quando achei que tinha solucionado o problema me ligaram da empresa com o problema em evidência mais uma vez.

Acabo de subir uma atualização, dando um CLEAR na NFe, que foi a única coisa que não fiz ainda.

Estou de olho aqui para ver se encontro, se tudo correr bem eu atualizo o post com o que eu fiz bem detalhado com código e tudo mais, para que vocês vejam e possivelmente terem alguma ideia.

OBS: Meu banco é o Santander

[Lucas Fernando Matias]

Pessoal, depois de dar muita cabeçada resolvi o problema.

Antes eu estava utilizando o componente: ACBrBoletoFCFortes1

Agora utilizo o componente: ACBrBoletoFCFR1

Neste componente novo, eu indico o arquivo .FR3 e tudo está correndo bem, no componente anterior (ACBrBoletoFCFortes1), as linhas no momento da geração do PDF saiam em determinadas vezes tortas, e é geralmente quando acontecia algo assim que dava a diferença de 0,01 Cent.

Não me aprofundei nos fontes do ACBR, mas foi isso que reparei aqui e que resolveu meu problema.
Agradeço a todos os membros do ACBR e demais participantes do fórum por toda ajuda prestada.

Muito obrigado

[Lucas Fernando Matias]

É pessoal... problema novamente.

Ficou alguns dias bonitinho e apareceu novamente o problema da diferença de 0,01, revendo tudo.

Ocorre que essa imagem é o espelho do que acontece aqui, essa imagem é do amigo que abriu o tópico, farnetani.

Novo teste, agora estou retirando os dados que eu passava zerados como por exemplo:
//        PercentualMulta := 0;
//        ValorAbatimento := 0;
//        ValorMoraJuros  := 0;
//        ValorDesconto   := 0;
//        ValorAbatimento := 0;
//        DataDesconto    := 0;
//        DataAbatimento  := 0;

Vou continuar minha busca, se alguém estiver com o mesmo problema estou a disposição para conversar a respeito.

[Lucas Fernando Matias]

No demo não deu o erro aqui no meu PC, só dá na máquina do Cliente, não dá em todos os boletos, é hora sim e hora não...

Eu estive analisando ontem a montagem do código de barras do boleto function TACBrBancoSantander.MontarCodigoBarras ( const ACBrTitulo: TACBrTitulo) : String;.
OBS: No meu caso é o Santander.

Nesta linha, reparei que dependendo das configurações do sistema operacional ele não retorna o valor com 2 casas decimais, quando o final é zero.

                      IntToStrZero(Round(ACBrTitulo.ValorDocumento*100),10) + //Valor nominal

 

Então modifiquei para que não houvesse nenhuma alteração no valor, devido a multiplicação por 100, formatei para ser apresentado com 2 casas decimais e removi todos os pontos e virgulas do valor.

                      IntToStrZero(
                                    StrToInt64(
                                               StringReplace(
                                                             StringReplace(
                                                                           FormatFloat('0.00', ACBrTitulo.ValorDocumento),
                                                                           '.', '', [rfReplaceAll]
                                                                          ),
                                                             ',', '', [rfReplaceAll]
                                                             )
                                               ),
                                  10) + //Valor nominal

Está tudo funcionando normal depois desta alteração, 100% correto, hoje todos os boletos gerados foram correto, porém gosto de deixar mais tempo em testes, vou confirmar semana que vem se está tudo correndo bem, mas já adianto que pela quantidade de boletos que já emitimos hoje, com certeza está funcionando, antes o erro aparecia aleatoriamente com uma quantidade menor de emissões...

[Juliana Tamizou]

Bom dia.

Recentemente foi adicionada ao svn uma alteração na função RoundABNT() a qual tinha um comportamento semelhante ao descrito neste tópico, tente realizar testes utilizando esta função no lugar do Round().

Att.

[Lucas Fernando Matias]

Confirmando, assim como mencionei acima, os erros realmente pararam após a alteração descrita acima, já faz mais de uma semana, gerando diariamente gerando diversos boletos.

Porém reconheço que foi uma forma arcaica, a forma como eu fiz, mas eu precisava testar daquela maneira, ela não arredonda, então vou seguir o conselho da Juliana Tamizou, estou iniciando os testes utilizando a RoundABNT().

Obrigado Juliana Tamizou.

[lavaprato]

Boa tarde, venho informar que esse erro ainda persiste na versão mais atualizada do ACBr, tive que modificar todos os .pas para poder fazer certo o calculo do código de barras @Juliana Tamizou, teria uma reposta de atualização?

 

[José M. S. Junior]

Em 28/08/2019 at 16:22, lavaprato disse:

Boa tarde, venho informar que esse erro ainda persiste na versão mais atualizada do ACBr, tive que modificar todos os .pas para poder fazer certo o calculo do código de barras @Juliana Tamizou, teria uma reposta de atualização?

 

Bom dia

Por favor, descreva um passo a passo de como simular esse problema utilizando o Demo ACBrBoleto. E se conseguiu solucionar por favor anexe os fontes modificados...

[Kelvin Alexandre Ferreira]

Boa tarde!

Deparei com o mesmo problema que consta aqui, debugando o código (ACBrBancoBradesco.pas), observei que a função Round() usada nas linhas 117, 476 e 759 por vezes acabava gerando este 0,01 centavo de diferença. Fiz um ajuste no código, o qual estou postando em anexo. Vale lembrar que deixei um tempo aqui gerando boletos com a alteração, antes de manifestar aqui no fórum, já que este problema ocorria em boletos aleatórios. Depois que alterei meu fonte não deu mais problemas. 

ACBrBancoBradesco.pas

[Juliana Tamizou]

Bom dia.

Obrigada pela contribuição, foi adicionada para análise.

Att.

[José M. S. Junior]

Em 29/01/2020 at 18:39, Kelvin Alexandre Ferreira disse:

Boa tarde!

Deparei com o mesmo problema que consta aqui, debugando o código (ACBrBancoBradesco.pas), observei que a função Round() usada nas linhas 117, 476 e 759 por vezes acabava gerando este 0,01 centavo de diferença. Fiz um ajuste no código, o qual estou postando em anexo. Vale lembrar que deixei um tempo aqui gerando boletos com a alteração, antes de manifestar aqui no fórum, já que este problema ocorria em boletos aleatórios. Depois que alterei meu fonte não deu mais problemas. 

ACBrBancoBradesco.pas 92 kB · 0 downloads

Boa tarde

Qual o valor informado que causa a diferença de 0,01 centavo? Poderia passar os valores para que possamos simular o problema? 

Precisamos testar para aplicar a melhor solução, visto que o componente precisa seguir as regras de arredondamento estipuladas no manual...

[Kelvin Alexandre Ferreira]

Em 28/02/2020 at 14:03, José M. S. Junior disse:

Boa tarde

Qual o valor informado que causa a diferença de 0,01 centavo? Poderia passar os valores para que possamos simular o problema? 

Precisamos testar para aplicar a melhor solução, visto que o componente precisa seguir as regras de arredondamento estipuladas no manual...

Bom dia, José, este caso está acontecendo de forma aleatória, com valores aleatórios, discutindo com meus colegas, acabamos por acreditar que a função de arredondamento  Round() pode estar pegando algum lixo na memória. Um exemplo seria um boleto no valor de 381,40, que gerou um código de barras com final "38141",  mas mesmo assim quando tentei gerar outro boleto no mesmo valor os dados saíram corretos.

[Kelvin Alexandre Ferreira]

Em 30/01/2020 at 08:25, Juliana Tamizou disse:

Bom dia.

Obrigada pela contribuição, foi adicionada para análise.

Att.

 

Em 06/03/2020 at 09:24, Kelvin Alexandre Ferreira disse:

Bom dia, José, este caso está acontecendo de forma aleatória, com valores aleatórios, discutindo com meus colegas, acabamos por acreditar que a função de arredondamento  Round() pode estar pegando algum lixo na memória. Um exemplo seria um boleto no valor de 381,40, que gerou um código de barras com final "38141",  mas mesmo assim quando tentei gerar outro boleto no mesmo valor os dados saíram corretos.

Bom dia!

Estou a alguns meses testando a alteração que fiz nos fontes, somente tive este problema com 0,01 centavos depois do refactory que teve no ACBrBoleto, mas de qualquer forma eu atualizei meus fontes e alterei novamente o ACBrBoleto.pas (Linha 4357, trocada a função Round por TruncFix ). Não tive mais problemas com o 0,01 centavos na geração do código de barras do boleto. Entretanto, observei que mesmo assim o registro do boleto estava sendo feito com esta diferença, portanto tive que alterar também a unit ACBrBancoBradesco.pas, (linha 382, mesma troca de função). Desde então não tenho mais deparado com este problema. Segue em anexo os arquivos para análise.

ACBrBoleto.pas ACBrBancoBradesco.pas

[Juliana Tamizou]

Boa tarde.

Para nós o grande problema é que nunca fomos capazes de reproduzir tal situação, e como foi citado pelo @José M. S. Junior pode ser complicado mexer nisso.

No momento o mesmo está de férias,  quando ele retornar podemos ver a opinião dele novamente.

Att.

[Kelvin Alexandre Ferreira]

17 horas atrás, Juliana Tamizou disse:

Boa tarde.

Para nós o grande problema é que nunca fomos capazes de reproduzir tal situação, e como foi citado pelo @José M. S. Junior pode ser complicado mexer nisso.

No momento o mesmo está de férias,  quando ele retornar podemos ver a opinião dele novamente.

Att.

Bom dia!

Tudo bem Juliana, eu entendo a situação, até mesmo eu tive problemas para reproduzir aqui, eu tive que ficar testando várias vezes para reproduzir uma única vez, com o mesmo boleto, ao passo que na máquina do cliente, a cada 15 boletos gerados em média saia um com a diferença de valor. Vou aguardar a análise então do @José M. S. Junior. 

[José M. S. Junior]

Em 12/08/2020 at 10:44, Kelvin Alexandre Ferreira disse:

Bom dia!

Estou a alguns meses testando a alteração que fiz nos fontes, somente tive este problema com 0,01 centavos depois do refactory que teve no ACBrBoleto, mas de qualquer forma eu atualizei meus fontes e alterei novamente o ACBrBoleto.pas (Linha 4357, trocada a função Round por TruncFix ). Não tive mais problemas com o 0,01 centavos na geração do código de barras do boleto. Entretanto, observei que mesmo assim o registro do boleto estava sendo feito com esta diferença, portanto tive que alterar também a unit ACBrBancoBradesco.pas, (linha 382, mesma troca de função). Desde então não tenho mais deparado com este problema. Segue em anexo os arquivos para análise.

Este problema realmente parece ser algo muito específico no ambiente, até mesmo por ser aleatório... Caso contrário teria muitos relatos sobre isso...

Note que o campo "ValorDocumento" tem um SET setValorDocumento, onde sempre ANTES de chegar na geração do código de barras ou na remessa, passa por essa função e já realiza o arredondamento de duas casas seguindo padrão ABNT. Quando chega na função MontarCodigoBarras, o "round" apenas utiliza o valor inteiro (já multiplicado por 100). 

Certifique se realmente não está chegando o valor com 3 casas decimais na procedure "setValorDocumento". Por exemplo 381,406, nesse caso sim arredondaria com 0,01 centavo. 

Poderíamos alterar conforme sugerido, mas note que todas os campos de valores e todas as classes de Bancos utilizam o round, nesse caso afetaria todos os demais valores também... e o ideal seria revisar todo o componente Boleto se fosse o caso. 

[Kelvin Alexandre Ferreira]

Boa tarde @José M. S. Junior!

Realmente é bem especifico este caso, raramente consegui reproduzir em meu ambiente, acontecia sempre na máquina do cliente, neste caso, segundo os testes, ficou constatado que a dízima era criada depois de aplicado o Round(), ou seja, mesmo que o valor já chegasse formatado, ele arredondava diferente depois de aplicado o Round(). Por conta disso que estamos propondo a alteração com o uso da função TrunkFix() do ACBr, que até então não apresentou problemas nem para este cliente em específico, nem para os demais que estão usando o mesmo sistema.