[ic] Rounding and discounts
paul at gishnetwork.com
Tue Jul 24 12:34:07 EDT 2007
interchange-users-bounces at icdevgroup.org wrote:
>> -----Original Message-----
>> From: interchange-users-bounces at icdevgroup.org
>> [mailto:interchange-users-bounces at icdevgroup.org] On Behalf Of Jeff
>> Boes Sent: Monday, July 23, 2007 5:00 PM
>> To: interchange-users at icdevgroup.org
>> Subject: [ic] Rounding and discounts
>> I have run across a situation that highlights what I think is
>> a problem in the way discounts are applied.
>> E.g., if I have a 5% discount for an item that costs $49.50,
>> and the cart contains three items, then the total is
>> ($49.50 * 3) * 0.95 = $141.075, which rounds to $141.07
>> That's because the IC code applies the discount to the cart
>> by multiplying the discount by the total cost for each item
>> in the cart (Vend::Interpolate::apply_discount).
>> However, this brings up an oddity: if I ask, "what is the
>> discounted price of each item?", the calculation of
>> $141.07 / 3 = $47.025, which rounds to $47.02
>> In other words, you get a different answer if you apply the
>> discount to each item's per-item price, round, and then
>> multiply by the quantity, than if you calculate the
>> undiscounted item subtotal, then discount, then round.
>> Have others encountered this problem before? Should discounts
>> and rounding be applied in a different way to avoid this?
>> Jeffery Boes <><
>> jeff at endpoint.com
> Hi Jeffery,
> Basic mathematics rules
> 49.50 * 0.95 = 47.025
> 49.5 * 3 * 0.95 = 141.075
> 141.075 / 3 / 0.95 = 49.50 (here you forgot the 95%)
> Rounding will offset the total from the exact amounts. The divided
> rounded total would not give you the exact single item pricing.
> Dividing the rounded total: 141.07 / 3 / 0.95 = 49.49824...
> I believe the code is doing things the way it should
> Martin H.
> N.E.S.T. Solutions
I am not certain, but I believe Jeff was asking about the code applying to
the total (one round) and alternatively using the code against the items
(many rounds). It is obvious that using it against one item as opposed to
many items creates a "unknown" WRT rounding.
16.24 * 11% = 1.7864 (1.79)
23.15 * 11% = 2.5465 (2.55)
37.07 * 11% = 4.0777 (4.08)
76.46 * 11% = 8.4106 (8.41)
I think the solution is to stick with one or the other and now show both
:-) Maybe show the per item as "estimated discount price:"
I don't think there is a bug with the code, but I suppose maybe it could be
implemented in a safer way to avoid this. The more "rounding" that occurs
in a calculation the more there is a chance for discrepancy.
More information about the interchange-users