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]
