I was reviewing the Dynamic Deal outlined in IG1261 and would like more information to facilitate its implementation. The document provides details through a table as specified.
In the CPQ session mentioned earlier, there is a price rule for product offerings. However, in TMF 620, there doesn't seem to be a specific location designated for storing such rules. Is it possible that these rules are encompassed within the price policy?
Examining the sample below may provide further insights.
It looks like TMF671 model.
If the designated location for storing this rule is within the price rules, could you specify which product offering is associated with this policy? As there multiple product offering participating in CPQ session.
Could you offer a use case or design reference for implementing the dynamic deal design pattern using TMF 620?
Thanks in advance.
In version 5 of TMF620 Product Catalog Management API, we have introduced references to the new Policy API. Using the Policy API would allow you to model and author rules such as the one you state, in the Event/Condition/Action paradigm, as presented in the Information Framework (SID) model.
If we consider above example, there are three product offerings selected in CPQ session , then which policy reference will work ?
Or we need to use BundleProductOffering as container then that BundleProductOffering points to that policy which contains action '10% off on MRC' .
BundProductOffering BD(refers policy id) Product Offering A Product Offering B Product Offering C
Here bundle offers static relationship , but the design pattern is dynamic deal, can you illustrate a clear example with policy reference.
I apologize that I didn't fully examine the nature of your query in my previous answer.
Creating a bundling product offering would indeed be one way to go, and it has the advantage of making the benefit very clear to the purchaser.
But if you want to apply the benefit dynamically, we are talking about a Promotion, which has it's own dedicated API TMF671. The idea of a promotion is to create a set of criteria, and apply the promotion action when the criteria are satisfied. TMF671 is a design-time API, where you define the rules of the promotion. There is no corresponding runtime API at this time.