[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.
> 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.