Re: percentage discount not calculating properly

[Luke <..hidden..>]

On Wed, 24 Feb 2010, Chris Travers wrote:

> On Wed, Feb 24, 2010 at 12:11 PM, Luke <..hidden..> wrote:
> > On Wed, 24 Feb 2010, Chris Travers wrote:

[.]
> >  > 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.

Before I answered originally, I went and looked up lot pricing, to make 
sure my understanding of the term was correct.
Where I saw it discussed, the idea seemed to be one of stepped discounts.

1-99: $50 (actually, you wouldn't have to specify this)
100-500: $40
500-750: $35
750-infinity: $30

So my suggestion of:

> > Add a quantity field to the price matrix, and sort on quantity descending?

Related to that.
If the quantity is higher than the highest qty in the price matrix, use 
that qty's price.
Step down from there.
If it is lower than the lowest, use the sellprice.

> 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,

Couldn't you use assemblies for that?  (N.B. I've never used them, so have 
limited knowledge.)
To cover that situation, I've usually just created a "case" item, separate 
from the product, with manual calculations.  No big deal.

While we're on this, how about a minimum quantity option?  I am thinking 
of products sold by the foot, which must be sold at a start of say 25 
feet.
(I had an SL customer with this situation.)

> 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).

Done now by some creative arithmetic on the invoice's per item prices.

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

Which, as a quick fix in 1.2, would present a clugie solution to the 
percentage discount problem.  This is better than no solution at all.
At least it lets the user make the invoice "look good" and calculate right 
following the line item.

Luke