Re: percentage discount not calculating properly

[David Godfrey <..hidden..>]

HI Chris,

referring to an earlier email from yourself....

On Wed, Feb 24, 2010 at 1:13 AM, Luke <..hidden..> wrote:
> > On Tue, 23 Feb 2010, Bob Miller wrote:
> >
> > See David's message for a supposed fix, but as for what's going on...:
> >
>> >> One of my clients has recently noticed a slight peculiarity in the
>> >> percentage discount, and I have been able to verify it.
>> >> For example, sell 252 items at $1.05 with a 15% discount.  By my 
handy
>> >> dandy calculator application, 252*1.05*.85=224.91.  However, on the
>> >> invoice, the total calculated is $224.28.  It is a small difference,
>> >> however, it grows when more items are sold.  When we put on another
> >
> > Your math is not the math which the program does.  It does
> > this:
> > 1.05 * 0.85 * 252.  That would still be okay, until you show your work.
> >
> > 1.05 * 0.85 = 0.8925
> > 0.8925 Internal round to 2 decimal places = 0.89
> > 0.89 * 252 = 224.28
> >

That's the way this is handled currently.
>>>>>End Old EMAIL

Chris Travers wrote:
> On Wed, Feb 24, 2010 at 10:10 AM, David Godfrey <..hidden..> wrote:
> > Hi Chris,
> >
> > Sorry, I thought you mentioned having fixed this particular issue already.
> >
> > It must have just been a discussion of the issue and it's complexities
> Nope, that was an order of operations issue involving discounts,
> rounding, and sales tax.
> Best Wishes,
> Chris Travers

As I read Bobs description of his problem, I understand it to be 
primarily that, an order of operations issue.
Luke stated that the software is calculating as per
round( round(price*discount) * quantity)
while the expected order would be (preferably)
round(quantity*price*discount) or at least
round( round(quantity*price) * discount)

My memory says that this is what we had discussed
(in relation to AP irrc) and that you had provided a fix in 1.2.19
either of the 2nd two options would be a marked improvement over the old 
method.

I will try and test 1.2.19 / 1.2.20 to see if this behavior has actually 
changed.

I agree that precision is also an issue, but the change to order of 
execution minimises the discrepancy to small amounts that a client is 
more likely to accept.

Regards
David Godfrey