Calculation needed...

[macmangler]

If a product costs $1.00 if you buy 1-100, but costs $0.85 if you buy 101-250 and so fourth.... what calculation would I use here.

Any help or advice appreciated!

Thanks,

Mike

[Ender]

Depends on the "so forth". How many pricing breaks could there be? Could the quantities for each product break be different or are they always the same?

[macmangler]

Someone could orders thousands... and there may be as many as 5 price breaks.

[LaRetta]

I don't know how your current pricing is structured, Mike. Ideally, you should have a Products table WITHOUT a price field. An attached table (to Products) called Prices would hold multiple price breaks (sometimes many records for one product; sometimes only one record). This allows flexibility for special sales, grouping products, and using RECORDS to hold each specific 'price break' group. Pricing for the fields can use either 'cents' to discount or percentages, and you specify the break points. When quantity is ordered, the correct charge is pulled into your LineItem.

If you hard-code these percentage discounts into a calculation then you will always have to modify it. Might this vary product-to-product, year-to-year, customer-to-customer and so forth? Flexibility is the key to good pricing and that can only be accomplished with a good relational structure. Otherwise, you will be continually adding fields and tweaking your calcs.

[Vaughan]

"If you hard-code these percentage discounts into a calculation then you will always have to modify it."

Unless the calculation is in a text field that is processed using the Evaluate() function... I've always thought Evaluate would be ideal for situation like this. Gets rid of a whole table.

[stuj1026]

Case(amt<50;150;amt<101;140;amt<401;130;amt<801;120;amt<1001;110;amt<2000;100;amt<4000;90;amt<10000;70;amt<20000;50;amt>20000;30)

and so forth

Stu

[macmangler]

THANKS!! This is helpful!