price lists can be “stacked”, but this sets a hierarchy of prices… Lets say that you have multiple price lists, and you have assigned them all to one customer (or customer group)
| price list | Expires | Type | Name |
|---|---|---|---|
| HOTPL1 | date in the past | price list | May HOT SALE Price List |
| HOTPL2 | Future date | price list | August HOT SALE Price List |
| DPL2 | Future date | price list | Distributor Price LIst |
| DDL2 | Future date | Discount | Distributor Discount |
| RPL1 | date in the past | price list | Retail Price list |
| RDL1 | date in the past | Discount | Retail Discount |
| RPL2 | Future date | price list | Retail Price list |
| RDL2 | Future date | Discount | Retail Discount |
What the system generally does, is it searches from the top down and stops searching when it finds both a price and a discount to apply. For example, someone purchases a part that is on the HOTPL1… it will skip that price list because it is expired, and then look in HOTPL2. If it finds it, then it takes that price, and continues looking for an active discount price list until it finds one and then stops.
IF after all the searching it doesn’t find a price, then it falls back to the sales price that is stored in the part table (bad in my opinion, but that is for another day).
So, in my opinion, it is best to create a “retail price list” that is all-encompassing, including ALL part numbers. This price should be the fall back (bottom) price that is included to all customers & distributors. Then you also create special price lists that are put in front of that base price.