[ic] Rounding and discounts

N.E.S.T. Solutions nest_consulting at yahoo.ca
Tue Jul 24 21:29:41 EDT 2007


> N.E.S.T. Solutions wrote:
> >
> > 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%)
> >   
> Nope. As I wrote earlier,
> 
> > 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
> >   
> 
> What I'm experiencing is in recording the order in the 
> database at the end of the transaction. The per-item actual 
> price is calculated by dividing the total for that item by 
> the quantity, and rounding so it fits into two decimal 
> places. As a result, I get $47.02.
> 
> Even if I calculated the per-item price by $49.95 * 0.95, I 
> would get $47.025. The problem here is not in understanding 
> how the math works, but in explaining to my client why the 
> customer is charged $141.07, but the database shows three 
> items of $47.02 each.
> 
> Likewise, a customer might wonder why they pay a one-penny 
> penalty for buying three items at one time, rather than three 
> items on three separate occasions.
> 
> I'm in the process of digging through our discount formula. 
> It used to look like this:
> 
>   sprintf('%0.2f', $s * $Scratch->{discount_percent})
> 
> where $s is the subtotal calculated by (quantity * 
> item_price). I think it needs to be:
> 
>    $q * sprintf('%0.2f', $p * $Scratch->{discount_percent})
> 
> where $q is the quantity and $p is the per-item 
> non-discounted price. However, this led to some other 
> glitches, so I can't declare victory just yet.
> 
> -- 
> Jeffery Boes  <><
> jeff at endpoint.com

Sorry, didn't quite look at it this way at first. As Paul said, it can
be done 
either way, depending on the preference over the final results and the
information 
you and your customer want to see.

In case of "bundle discounts", the way would be to add fields to get the
precise 
data written in the DB for further reporting and/or calculations, in
case of returns, 
refunds or whatever, so that the amounts work out to the penny.

I guess discounting on a per item basis may make things easier for
further processing if 
needed, to avoid dividing rounded totals. Someone has to lose the penny,
wether it's the 
customer or the merchant lies in the method used.

Martin H.
N.E.S.T. Solutions




More information about the interchange-users mailing list