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

Re: percentage discount not calculating properly

On Wed, Feb 24, 2010 at 1:30 PM, Luke <..hidden..> wrote:

> 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
Yep, we need to add something like that as well.

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

Not really.  You can't really purchase an assembly and break it apart
this way because there is no really good way of handling the costing.
this is something else we need to work on.

On the sales side a lot price would be better than an assembly because
it could be "stocked" at time of sale, eliminating a problem with
inventory counts if these are never stocked.....  OTOH, the volume
pricing might work there just as well.  The main benefit would be on
the pruchase side though.

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

I am thinking more ahead to 1.4.  I expect to look at precision
handling today.  The more I think about it the more I think I
committed a fix for this some time ago but I am not sure....

Best Wishes,
Chris Travers