Dynamics Retail Discount Concurrency – Pricing Zone
We will share the top-level implementation of pricing zone in Dynamics Retail Discount Engine. In summary, if we can figure out best deal in a simple and fast way, go for it. If not, we try to reduce the size of discount knapsack problem. Lastly, if knapsack takes too long, resort to marginal value ranking algorithm.
Please bear with me as the post contains lots of information, some of which is dry. I will elaborate the details in other posts later.
- Load retail discount definitions from database by products and pricing info, like affiliation.
- Group sales lines into discountable item groups. From now on, we will use item group index to reference an item.
- For each discount, build basic lookups: item group index <=> discount line number (index of discount line definition).
- Process non-threshold discounts by priority. For each priority in descending order,
- Exclusive discounts first. For each discount, build additional lookups, for example for mix and match, item group index <=> line group, and streamline lookups, for example for discount offer (a.k.a. simple discount), reduce intra-overlapped discount line definitions per item group index.
- For each item group index, reduce simple competition if possible. (We will have more details in a separate post.)
- For (fully or partially) non-overlapped discounts, if we know a simple way to get best deal, go for it. We will have more details in a separate post. For example, for discount offer (a.k.a. simple discount), if an item group index isn’t overlapped with multiple discounts, then just apply the simple discount for it.
- For each fully non-overlapped discount, calculate discounts via knapsack algorithm for the best deal, if we can’t finish it in time, apply it in fast way while still striving for a great deal, but no guarantee for best deal.
- Now onto overlapped discounts. First, we divide them by item group indexes into multiple overlapped discounts. Usually it is one.
- For each overlapped discounts group,
- If all are compounded, apply them one by one, roughly speaking as in step 3 and 4.
- If it contains one mix and match with one line group and it is not least expensive, and rest are simple discounts, then we may optimize it in a fast way.
- If it contains one mix and match with one line group and it is least expensive, and rest are simple discounts, then we may partially optimize it in a fast way.
- We have no other choice but to invoke a knapsack algorithm with marginal value ranking algorithm as a backup plan.
- Process mix and match least expensive favoring retailer. If multiple, order them in some way, and apply one by one.
- Now best price and compounded discounts, repeat 1-7.
- Process threshold discounts by priority. For each priority in descending order,
Note: even if we cannot finish knapsack algorithm in time, the current best deal from the interrupted knapsack algorithm in many cases is the best deal, and in most cases beats the result from marginal value ranking algorithm. We select the better one from the two.
Again, the post is dry, but I hope you get some picture of what is going on. I will elaborate details in other posts.
Update: The following will be released soon in AX7. Pricing zone is to best price and compound within priority, and never compound across priorities. 
Related: Retail Discount Concurrency – Best Deal Knapsack Problem
Related: Dynamic Programming for Retail Discount Knapsack Problem
Related: Retail Discount Concurrency Control – Pricing Zone
Related: Retail Discount Knapsack – Marginal Value Ranking Algorithm I