Re: percentage discount not calculating properly

[Chris Travers <..hidden..>]

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
would be a bad thing.

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
defined ahead of time and function kind of like ad-hoc assemblies
(i.e. not stocked separately from sale).

One might even allow the extended price to be user-editable.

Best Wishes,
Chris Travers