Difference between revisions of "BigDecimal"

From ADempiere
Jump to: navigation, search
This Wiki is read-only for reference purposes to avoid broken links.
 
(what about Amt datatype?)
 
Line 19: Line 19:
  
 
Why this is, I don't know, but it took me a lot of trying to round the incoming double when it wasn't the double that was the problem.
 
Why this is, I don't know, but it took me a lot of trying to round the incoming double when it wasn't the double that was the problem.
 +
by [[User:Dantam]]
 +
 +
=Notes=
 +
Your figures will appear with only 2 decimal points regardless if you set the DataType to Amount (amt) in the Application Dictionary's Table and Field window. - [[User:Red1|Red1]]
  
 
[[Category:Developer documentation]]
 
[[Category:Developer documentation]]

Latest revision as of 16:26, 3 November 2008

In Adempiere many numbers (such as prices and costs) are stored internally as the java type BigDecimal.

If you are setting prices programmatically you might experience strange rounding behaviour of the BigDecimal class, especially if you are creating high numbers from the datatype double.

What happens is that you get a number similar to 42107.339999999997 when what you inserted was 42107.34. To be sure that you get correct BigDecimals you can create the BigDecimal using a string instead of a double.

Ie:

Write:

BigDecimal d = new BigDecimal(new Double(42107.34).toString());

Don't write:

BigDecimal d = new BigDecimal(42107.34);

Why this is, I don't know, but it took me a lot of trying to round the incoming double when it wasn't the double that was the problem. by User:Dantam

Notes

Your figures will appear with only 2 decimal points regardless if you set the DataType to Amount (amt) in the Application Dictionary's Table and Field window. - Red1