David,
I know what you're talking about now. Along those lines,
OrderItem.unitPrice is a currency-amount, OrderAdjustment.amount
and .recurringAmount are both currency-precise, but
InvoiceItem.amount is a currency-amount, so I have seen occasional
0.01 rounding errors in things like sales tax from order to invoice.
Maybe we should wrap all of these into one big JIRA issue and attack
it over time...
On Nov 21, 2006, at 11:58 PM, David E Jones wrote:
On Nov 21, 2006, at 10:52 PM, Si Chen wrote:
David,
Actually, the "bug" was fixed just by changing OrderItem.unitPrice
and InvoiceItem.amount to currency-precise. The truncation vs.
rounding behavior differs from database to database, and
postgresql truncates.
That would be the problem then... we shouldn't be leaving this sort
of thing to the database, the application should be making sure the
data is ready before persisting it. I haven't looked at this stuff
in a long time and while I think I remember some conversation about
it a while back I guess it hasn't been worked on yet.
I'm of course for changing these fields to currency-precise. I
was able to get OFBiz to work fine by changing all the named
fields and then changing UtilFormatOut.formatCurrency (see http://
issues.apache.org/jira/browse/OFBIZ-490)
What kind of potential bug would OrderItem/InvoiceItem calculated
item total fix? Are you thinking something like 999 * 0.4375 =
98.5625, so is that 98.56 or 98.57 kind of a thing?
The concern with this is usually that different companies may
calculate things differently, or that there could be something
funny in code somewhere that is recalculating things that result in
a difference between an order and an invoice amount, or a software
update that ends up changing an invoice total or makes an invoice
no longer add up to the persisted total. Because everything needs
to be rounded to 2 decimal places at some point in order to
actually do a financial transaction, this can happen.
It gets even worse for things like order changes, partial
fulfillment and partial invoicing, and so on. Of course, for an
order change things are recalculated so it's not such a big deal
just from that, but all potential problems are open game again.
This is why it's nice to have persisted sub-totals that are rounded
to 2 decimal places. The goal is to get the persisted stuff to the
point where there is no way to get different results for the total
calculations. This is another reason, BTW, why adjustments are
always flat amounts instead of having a percentage or per quantity
amount or that sort of thing like we did a long time ago. Of
course, they still have a currency-precise amount, so that just has
to be used judiciously and the code shouldn't be putting more than
2 decimals in there unless it is really required.
-David
On Nov 21, 2006, at 8:34 PM, David E Jones wrote:
On Nov 21, 2006, at 9:00 PM, Si Chen wrote:
David,
Yeah, I got quite a surprise when I created products with prices
like 0.4375 and they ended up being 0.43 in orders and on the
invoices!
This sounds like a bug, like something is truncating instead of
rounding...
I'm not sure why OrderItem.unitPrice should be different the
Product or SupplierProduct price? If someone wants to use a 3-
or 4-digit price, wouldn't they want it to be the unit price on
their orders?
There is a pretty big different between OrderItem and the Product
and SupplierProduct entities. The ProductPrice records represent
an offer from the company to a prospective customer. The
OrderItem record represents an offer from a customer to the
vendor and if accepted by the vendor becomes an agreement between
the two. When such an agreement is made it is for various
specific amounts. At this point some companies may still want to
have a precise amount.
By the time we get to an invoice we really need to have a fixed
amount that won't change by variations in the calculation, and I
guess that would be nice on the order as well. This was the
reason for having a 2 decimal place amount in these two places.
Also, InvoiceItem.amount is not the line item's total amount.
It is equivalent to the unitPrice on OrderItem, so ... that's
why I thought they should all be changed to currency-precise
Of course, for people who are using 2-decimal prices, none of
this would change things.
Reviewing it again based on the need for more precise prices
common in B2B situations where large quantities and very small
prices do happen perhaps what we should do is something like:
1. increase the precision of these fields, but after an initial
calculation they should be used for information purposes only
2. add a field to the OrderItem and InvoiceItem that represents
the calculated item total. This helps the display code so it
doesn't have to calculate it over and over, but more importantly
we now have a number that represents what the customer and vendor
agreed on for the specific quantity, which is what is really
important. This would only change if the order/invoice changes.
To simplify things, and I think make a more useful number, this
should _not_ include adjustments. It should simply represent the
total for the quantity and unit price.
Anyone else have any thoughts on this? Implementing this would
require a bit of effort so we should certainly discuss it first.
-David
On Nov 21, 2006, at 7:53 PM, David E Jones wrote:
On Nov 21, 2006, at 8:09 PM, Si Chen wrote:
Hi all-
I noticed that while Product.price is currency-precise,
certain fields which are related to it are only currency-
amount, causing loss of precision when original prices have 3
or 4 decimal places of precision. Specifically, I think the
following should all be changed to currency-precise:
SupplierProduct.lastPrice
OrderItem.unitPrice, unitListPrice, unitAverageCost,
unitRecurringPrice
InvoiceItem.amount
Is there any reason why these shouldn't be currency-precise?
Most of these look fine, but I'm not sure about
OrderItem.unitPrice, and I'm pretty uncomfortable with
InvoiceItem.amount.
OrderItem.unitPrice may be arguable because some calculation
may be done based on that, but the InvoiceItem.amount should be
something that never results in any surprises...
-David
Best Regards,
Si
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
Best Regards,
Si
[EMAIL PROTECTED]
