Jacopo,
I posted something on this before. As with all rounding, there will be losses (or pluses). It
doesn't matter how many decimal places you do your rounding with. The eventual invoices going out
to the customers is the weak link! Those invoices have 2 decimal places, which means a rounding
action is already done there.
One idea is to keep the total in view, and then compensate for rounding discrepancies in the last
invoice.
Say you have 3 invoices. For the first 2, you send those invoices out with rounding as usual. The
last invoice will take the correct total and deduct the amounts from past invoices. Whatever is
"extra/less" in the final invoice, label it as "rounding adjustments". That way, no matter what
the rounding discrepancies, the final invoice will always bring the total invoiced amount to the
correct figure.
Jonathon
Jacopo Cappellato wrote:
Unfortunately, there are still some rounding issues when sales taxes are
involved.
After some research, I think I have found where the problem is:
OrderPaymentPreference.maxAmount (the field where the auth/captured
amount is stored) has 2 decimal digits; the field OrderAdjustment.amount
has 3 decimal digits; the number of digits (set in the arithmetic
properties file) for sales taxes is 3.
My guess is that somewhere we move a 3 decimal number (without proerly
rounding it as we do with the order grand total) to a 2 decimal field
(maxAmount) and so the db approximate the number for us (in a different
way from the grand total).
The end result is this:
https://demo.hotwaxmedia.com/ordermgr/control/orderview?orderId=WSCO10001
The order total is $18.83 (rounded from 18.825)
The amount auth/captured/invoiced is $18.82
Any hints on how we can fix this?
Jacopo
