CPQ never executes qualification and pricing rules. Both functions are a part of the product configuration component. The rationale is simple - we want to keep CPQ FE as simple as possible because the same qualification & pricing logic applies to various channels (e.g. ordering, selfcare, partner portal, mobile app etc.). So the logic has to be encapsulated in a component that is used across different FEs/channels.
Regarding your question - we actually extended TMF679 with returnPrices boolean (similarly to provideOnlyAvailable which is part of the standard). We didn't want to pass a "fields" query parameter in POST request as it's not a common practice and is not defined in the 679 swagger for POST operation.
Original Message:
Sent: Mar 30, 2023 11:02
From: Matthieu Hattab
Subject: TMF620 - Modelling scaled prices
Hi Bostjan,
I have a question regarding your use of 679 in your "discovery phase"/catalogue browsing.
when you use POST /queryProductOfferingQualification to your "CPQ" component, will the CPQ also run qualification rules or just compute prices?
do you have a suggestion on how I could use the API (POST queryPoQ) to only run qualification rules or pricing rules or both?
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Mar 29, 2023 06:53
From: Bostjan Keber
Subject: TMF620 - Modelling scaled prices
Hi Ibiso,
I wrote an article that describes interactions between EM, product qualification (TMF679), product catalog management (TMF620), and product configuration. The article is similar to IG1228, but perhaps it highlights different aspects. Mayou you will find it useful.
In IG1228, you probably noticed that the product configurator ODA component exposes two APIs - TMF679 (product offering qualification) and TMFXXX (product configuration). TMF XXX is still under construction. Qualification API (679) interprets product rules and calculates pricing in a context of a quote, cart, or order in the qualification (i.e. commercial eligibility evaluation) step. Once the user selects a specific product offering, the TMF XXX API is engaged to calculate a product configuration in a given context.
In our implementation, we return prices in the qualification step already (679). In the "discovery" phase, when a user browses the product catalog, we want to provide pricing information taking contextual information into account (channel, customer etc.). Pricing information is returned as a response to POST queryPoQ, specifically as POQItem.ProductOfferingRef.ProductOfferingPrice. For ProductOfferingRef->ProductOfferingPrice expand functionality, please refer to TMF630 API design guidelines.
In your case, however, I believe the coming TMF XXX API should be used as you need pricing in the product configuration step.
------------------------------
Bostjan Keber
Marand, software ltd
Original Message:
Sent: Mar 29, 2023 02:25
From: Ibiso Partington
Subject: TMF620 - Modelling scaled prices
Indeed option B is looking more appealing. However, I am struggling to understand how to get TMF620 and TMF679 to work together to get the price value, despite looking at the IG1228 document. Any help appreciated!
------------------------------
Ibiso Partington
Hansen Technologies
Original Message:
Sent: Mar 27, 2023 11:53
From: Marco Kelterborn
Subject: TMF620 - Modelling scaled prices
Hello Matthieu,
thanks for your explanation.
In fact, we have recurring charges. The amount of storage can be any value between 200 and unlimited (Probably not really unlimited but a lot ;-)) in increments of 100. So there is no way to model separate values in a list. Instead, we use an integer field where the user can enter a number.
So I am going to look at option B.
And thanks for the literature recommendations. I'll have a look at them.
Best regards
Marco.
------------------------------
Marco Kelterborn
T-Systems International Services GmbH
Original Message:
Sent: Mar 27, 2023 06:17
From: Matthieu Hattab
Subject: TMF620 - Modelling scaled prices
you mentioned that the product is either RAM or Storage.
your price examples suggests usage price (price per unit). but your diagram suggest recurring charges.
When we sell virtual equipments (server, VPN...) and offer different level of RAM, I think we have maybe 5 levels (16 GB, 32 GB, 64GB, 128GB), which we modeled as characteristic (RAM) with a list of characteristic values (xxx GB) and each charValue has a 1:1 relationship with a POP (exactly as suggested by Bostjan).
Are you actually offering to your customers more than 100 levels of RAM (i.e. can I order 7GB or RAM or 54 GB or RAM?)
In any case, if you have a Price per GB for your recurring charge, then you can either:
A. map POP with each charValue (use PriceProductSpecificationCharacteristicUse - see TMF620 documentation). it's the classic approach to such requirements, but in your case, it could be a lot of maintenance, depending on how many RAM quantity can be ordered by customers
B. use a policy ("policy" should replace "Constraint" in API v5) then you only need 1 POP and that POP doesn't have a price value but a policy Id. TMF620 would then only presents the policy Id associated to the recurring POP.
this means TMF620 will not show the price to pay, just the policy Id. To get the actual price value, you will use TMF679. This is explained in IG1228, where you can find use cases on how to use TMF620 and TMF679.
also highly recommend to read:
- IG1228 on how to use TMF620 together with TMF679 (TMF679 will give the price value)
- GB922 - Product, which has multiple examples on how to model prices in various complex scenarios
Hope this helps.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Mar 23, 2023 09:45
From: Marco Kelterborn
Subject: TMF620 - Modelling scaled prices
Hello Experts,
we have a product offering with a price that depends on the quantity of the product. For example this could be a product such as RAM or Storage, with the following prices.
from 1 GB to 10 GB --> 0,03 EUR/GB
from 11 GB to 100 GB --> 0,02 EUR/GB
from 101 GB to unlimited --> 0,01 EUR/GB
Do you have a suggestion for how I can model this for the TMF620?
Currently, we are considering the following structure (see following object diagramm):
Our product "Disk Storage Entry" has a monthly recurring price with 372 EUR for 1 GB. We would add some more "Money" instances with the prices for the other scale level.
The question is now how can we add the specific scale level for such a Money instance?
We would be grateful for any suggestions.
Best regards
Marco
------------------------------
Marco Kelterborn
Deutsche Telekom IT GmbH
------------------------------