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.
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?
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]
