Re^2: Decimal Arithmetic

The place I'm having problems is with invoices in accounts payable. Each invoice I'm recording can have an arbitrary number of items that are purchased. Each invoice can also have a tax amount and a shipping/handling amount. The shipping and tax amounts need to be distributed to the accounts in which the invoice items are recorded. When I try to split these amounts, I'm getting rounding errors. (I'm using the Math::BigFloat library with an accuracy of 17 digits and a precision of 5 decimal places for my calculations.) Does this seem reasonable?

Comment on Re^2: Decimal Arithmetic

Replies are listed 'Best First'.
Re^3: Decimal Arithmetic by xdg (Monsignor) on Feb 06, 2007 at 02:43 UTC
When I try to split these amounts, I'm getting rounding errors. This sounds more like a business logic problem than a decimal precision problem. For example, I have $1.00 that I need to allocate out to 3 parties. If I just divide by 3 and round to the nearest penny, then everyone pays $0.33 and I'm short a penny. -xdg Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.	[reply]
Re^3: Decimal Arithmetic by rir (Vicar) on Feb 06, 2007 at 05:18 UTC
Splitting an invoice's lot-shipping charge so that it may be charged to accounts associated with specific line items is a task usually left to human judgement. There is no reason to imagine that items belong to the same freight-rate class, items are shipped from the same location, an item's shipping weight is consistent Aside from the above, freight may be put into the cost of the line items or to a general ledger account, like Inbound Freight; how formally this policy is determined can vary. All of which is just to say: Ouch! Be well, rir	[reply]
Re^3: Decimal Arithmetic by zentara (Cardinal) on Feb 06, 2007 at 14:08 UTC
*5 decimal places precision* It certainly seems reasonable to me, if you are calcuating to pennies. To be on the safe side, you could always round up/down (to the nearest penny) in favor of the customer. You could absorb the penny/per cost and raise your rate by a penny :-). If you need more accuracy, look at xs outputs faster than perl can keep up and use MPFR to as many decimal places of precision you want. I'm not really a human, but I play one on earth. Cogito ergo sum a bum	[reply]
Re^3: Decimal Arithmetic by dragonchild (Archbishop) on Feb 06, 2007 at 20:15 UTC
This is purely a design problem. Why do you have a price for each item, but only a total tax for the invoice? Why not have a price for each item, a tax for each item, and a S&H for each item? Then, you aggregate those as the total tax and total S&H for the invoice. If, as I suspect, the S&H won't be amenable to that kind of breakout, then that's where your business problem arises. My criteria for good software: Does it work? Can someone else come in, make a change, and be reasonably certain no bugs were introduced?	[reply]