Dynamics Retail Discount Tribe – Discount Totaling
A tribe starts with a history. In enterprise POS (EPOS) in AX6 (a.k.a. Dynamics AX 2012), sales line totaling, which covers discount totaling, and taxes, etc., is called all over the place. In AX7 (a.k.a. Dynamics 365), the situation is better as it is wrapped in totaling service, which is called in few places.
Let’s summarize what discount totaling does:
- For fresh discount calculation, figure out exact discount amount for each discount line.
- For price-lock items – think order pick up, return, etc. – prorate discount amount if quantity is different from the original quantity on the sales line.
The fundamental question: why do we even need a discount totaling in the first place? Or if we have already calculated discounts, why do we need to total discounts again? A partner actually ran into the issue in AX6. They customized pricing engine, only to realize that totaling overrides the result.
As of this writing, we have not got rid of discount totaling, but we are able to contain it inside price engine, i.e. commerce runtime (CRT) totaling service no longer calls discount totaling because price engine has taken care of it already. In the future, we will think of whether and how to remove it.
For price-lock items, it is trivial. Nothing more I want to say.
For fresh discount calculation, we have two cases.
Non-compounded discount lines
Either sales line will have only one non-compounded discount line, nothing else. The calculation is straightforward and we ensure no negative discount and no negative net amount.
Deal/unit price: effective amount = (discountable base amount – unit price) * quantity
Amount off: effective amount = unit amount * quantity
Percentage: effective amount = discountable base amount * (percentage / 100) * quantity
Compounded discount lines
For each compounded discount line, the basic of calculating effective amount is the same, except that discountable base amount may be adjusted. In addition, the order of applying compounded discounts is important, and this is where two discount concurrency control models differ and we have detailed explanations in two posts:
Discount totaling for best price within priority and compound across
Discount totaling for best price and compound within priority and no compound across, a.k.a. pricing zone