[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: percentage discount not calculating properly

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.