Qual a melhor solução para cálculo financeiro?

10 respostas
Pilantra

Olá galera.

Eu fiz uma aplicação de cobrança, que utiliza o BigDecimal para fazer os cálculos financeiros. Acredito que seja a melhor a opção.

Porém, no relatório apareceram os seguintes valores:

20,68, 190.64, 190.64 e 190.64. E a soma 592.61. Mas quando a pessoa vai somar pela calculadora, dá 1 centavo a menos, dando 592.60.

Entretanto, isso não é um erro, pois os números na verdade são, 20.6800, 190.6440, 190.6440 e 190.6440. Então a soma dá 592.6120.

A conta não está errada, e eu não posso apresentar 3 casas decimais.

Tentei usar os ROUNDS da vida, mas mesmo assim ficou estranho, uma hora subia 2 centavos, e outra hora ficava do mesmo jeito. Eu utilizo o NumberFormat para apresentar os dados em formato monetário. E parece que ele está cortando o 592.6120 apenas.

Qual a forma que vocês utilizam para trabalhar com dinheiro?

Grato desde já.

10 Respostas

luciano2

Usa ROUND_UNNECESSARY

Assim ele mostra o valor real, seu problema Está ocorrendo porque quando você corta as casas decimais ele arredonda para baixo ou para cima dependendo do valor da 3 casa.

rod

Você pode usar a própria classe BigDecimal para definir a quantidade de casas decimais assim como a forma com que ela irá arredonda o seu valor.
Exemplo:

BigDecimal bigDecimal = new BigDecimal( 123.123456789 ).setScale( 2, BigDecimal.ROUND_HALF_EVEN );

Note que além do ROUND_HALF_EVEN existem outras formas de arredondamento.

sergiotaborda

Pilantra:
Olá galera.

Eu fiz uma aplicação de cobrança, que utiliza o BigDecimal para fazer os cálculos financeiros. Acredito que seja a melhor a opção.

Porém, no relatório apareceram os seguintes valores:

20,68, 190.64, 190.64 e 190.64. E a soma 592.61. Mas quando a pessoa vai somar pela calculadora, dá 1 centavo a menos, dando 592.60.

Entretanto, isso não é um erro, pois os números na verdade são, 20.6800, 190.6440, 190.6440 e 190.6440. Então a soma dá 592.6120.

A conta não está errada, e eu não posso apresentar 3 casas decimais.

Trabalhar com dinheiro não é trivial. BigDecimal não garante todas as operações porque é decimal. Operação com dinheiro são operações sobre inteiros. Pois é! Primeiro é preciso entender esse conceito. ficar arredondando as coisas não adianta nada.
A pergunta é, como obteve o numero 190.6440 ?

Pilantra

luciano@@ eu nem testei esse porque pelo que vi no javadoc ele lançava uma exception. Vou fazer esse teste.

rlazoti Eu já defini o bigdecimal assim ao instanciar ele, e arredondava da maneira que eu expliquei, as vezes 2 centavos pra cima, ou não mudava.

sergiotaborda esse valor chegou devido a uns cálculos de juros, correção monetária, multa, etc. E tendo o valor total, foi divido e chegado a esse valor de 190.6440. Dai quando formata com o NumberFormat ele parece ‘cortar’.

luciano2

Não é que ele corte, é uma regra de arredondamento.

Exemplo:
0,121 = 0,11

0,125 = 0,12

0,126 = 0,13

sergiotaborda

Pilantra:
luciano@@ eu nem testei esse porque pelo que vi no javadoc ele lançava uma exception. Vou fazer esse teste.

rlazoti Eu já defini o bigdecimal assim ao instanciar ele, e arredondava da maneira que eu expliquei, as vezes 2 centavos pra cima, ou não mudava.

sergiotaborda esse valor chegou devido a uns cálculos de juros, correção monetária, multa, etc. E tendo o valor total, foi divido e chegado a esse valor de 190.6440. Dai quando formata com o NumberFormat ele parece ‘cortar’.

Vc sabe que não pode usar “cortes” em calculos intermediários, certo ? numberFormat apenas pode ser usado na UI.

Mas como que o acumulo de juro dá três cifras iguais de 190.6440 ?

sergiotaborda

luciano@@:
Não é que ele corte, é uma regra de arredondamento.

Exemplo:
0,121 = 0,11

0,125 = 0,12

0,126 = 0,13

Não. Esse arredondamento só é feito pelo BigDecimal se vc aplicitar o ROUND_HALF_EVEN, o numberformat não arredonda,ele corta mesmo.

luciano2

AH!!! NumberFormat ta explicado, antes de formatar é necessário fazer o arredondamento correto.

sergiotaborda

.

E

Pilantra:
20,68, 190.64, 190.64 e 190.64. E a soma 592.61.

Quando você vai calcular as parcelas, normalmente uma (a primeira ou a última) deve ser diferente das outras, até para compensar o fato que é impossível dividir 1,00 em 3 parcelas de 0,33 e não ficar devendo alguma coisa.
Você deve fazer algumas contas para poder compensar esse fato - isso é inevitável. Pergunte ao cliente se ele prefere que a primeira prestação seja diferente ou se a última é que deve ser diferente.

Criado 28 de maio de 2010
Ultima resposta 28 de mai. de 2010
Respostas 10
Participantes 5