# Re: percentage discount not calculating properly

• Subject: Re: percentage discount not calculating properly
• From: Chris Travers <..hidden..>
• Date: Wed, 24 Feb 2010 12:26:21 -0800

```On Wed, Feb 24, 2010 at 12:11 PM, Luke <..hidden..> wrote:
> On Wed, 24 Feb 2010, Chris Travers wrote:
>
>> This will affect the precision possible, not the method of calculating
>> the discount.
>
> Chris
>
> Irrespective of precision from the customer point of view, wouldn't it
> make some sense to do all internal calculations at the highest precision
> available, and only round at the end of, in this case, a line item?

This would be a substantial change in behavior with no regression and
I would want to see this better discussed before pushing something
like this even into a development branch, although I would like to see
this problem tacked heavily on 1.4 as we do the total rewrite of the
invoice system.  I am a little nervous about fractional cents floating
around and the possibility or bias in rounding that could develop.
>
> A slightly more complex method, of which I have not fully considered the
> ramifications, is to allow multiple stages of precision rounding.
>
> First stage (inside a line item): maximum precision
> Second stage (line total): user specified - higher = more accuracy
>        subtotal is based on second stage
>        taxes, etc. are calculated on second stage
> Third stage (total): user specified - the end result receivable
>
> It may be troublesome to do stages 2 and 3 given taxes, and the things
> we've been talking about re cash based handling of collected sales taxes,
> in which case stage 3 may need to move to stage 2.
>
> I envision it something like this:
>
> [S1] itemprice (imaginary) * discount (imaginary) = 105.04017437
> 105.04017437 * quantity (5) = 525.20087185
> [S2] 525.20087185 round to pre-subtotal precision (3): 525.201
> No tax or other subtotal to total modifiers
> [S3] total rounded to total precision (2) = 525.20
>
> I have run into companies which do all intra-invoice calculations at
> something like a precision of 4, but then round the subtotal to a
> precision of 2, most likely with a round in their favor (I.E. up).
> That's what I'm angling for here.

That might work.
>
>  > As we revise the invoicing system I would like to be able to handle
>> "lot prices" but some additional thought needs to go into how that
>> would work.
>
> Add a quantity field to the price matrix, and sort on quantity descending?

That's not really what I was envisioning.  More along the lines of:

Buy product X in cartons of 24 units for \$14.99 per carton.   Our
current approach doesn't work well here which is a major limitation
for many users.  However a lot could go the other way too.  However,
this would require rewriting the whole way we do COGS, not that such

Lots though could go the other way too, and allow for something like
"I will sell you X of product for Y price total."  These could be