Open APIs

 View Only
Expand all | Collapse all

TMF620 - Modelling scaled prices

  • 1.  TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 23, 2023 14:19
    Edited by Marlon Almazan Mar 24, 2023 10:07

    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
    ------------------------------



  • 2.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 26, 2023 17:53

    You may find ideas on how to tackle this in IG1261 which describes a variety of Product Offering Modelling patterns.  

    Seeing that this example relates to Storage usage, I wonder if this is something that should be modelled as a recurring (monthly) charge that remains static (always charging the same amount for many months) or as a usage charge that varies based on the month's consumption.

    If the former, then you will want to model a price matrix based on quantity, where price varies based on tiers or clip levels as you have indicated.  I suspect you will need a price policy set for that.

    If the latter, with an expectation that the charge varies month to month, then you may be fine just providing a rate card or table in contract or quote language without having to specify a specific monthly charge. The billing component will then calculate that month's fees based on actual usage.



    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 3.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 27, 2023 11:28

    Hi Greg, thanks for your reply. The pattern document looks interesting. I'll need some time to understand it ;-)
    Actually our product is a recurring product and not a usage based one. So for now I will follow the way with the policy (Matthieu mentioned the same).

    Best regards 
    Marco



    ------------------------------
    Marco Kelterborn
    T-Systems International Services GmbH
    ------------------------------



  • 4.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 27, 2023 04:58

    Hi Marco,

    I would model quantity (e.g. disk space, memory size, number of vCPUs etc.) as a characteristic. The root product offering should contain all characteristics that drive prices. Your internal product catalog management implementation needs a mechanism to associate product characteristics with product offering price characteristics (prodSpecCharValueUse).

    Tiered prices are different ProductOfferingPrice entities. You can use the "Constraint" entity to differentiate between tiers. Of course, you have to sync these constraints with your pricing engine and billing component to correctly calculate prices.

    In case a product characteristic value changes during the billing period (e.g. upgrade of RAM or increase of disk space), the change should be reflected in the product inventory and timelined accordingly to correctly calculate prorates.

    Interestingly, it's quite common to have a single product instance (e.g. 1 virtual server) where pricing depends on components with quantities > 1 (e.g. 4 vCPU, 32GB RAM, 512 GB SSD). This video (see 1:15) shows behaviour of quantity characteristics during product configuration (CPQ).



    ------------------------------
    Bostjan Keber
    Marand, software ltd
    ------------------------------



  • 5.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 27, 2023 11:41

    Hi Bostjan,

    thanks for your answer.

    We use SAP technology (SAP Solution Configurator, SSC) to handle our configurations. This makes it easy for us to manage prices, product instances, and of course inventory changes.
    We are now looking for ways to transfer our internal product structures to the TMF620 in a standards-compliant way.

    You also mentioned the constraints or policies like Greg and Matthieu. So I'll take a look at that.

    And thanks for the very interesting link to the CPQ demo. This is a wonderful explanation of the calculation process. I really like it.

    Best regards
    Marco.



    ------------------------------
    Marco Kelterborn
    T-Systems International Services GmbH
    ------------------------------



  • 6.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 27, 2023 06:17

    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
    ------------------------------



  • 7.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 27, 2023 11:54

    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
    ------------------------------



  • 8.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 29, 2023 02:26

    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
    ------------------------------



  • 9.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 29, 2023 06:54

    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
    ------------------------------



  • 10.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 30, 2023 11:02

    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
    ------------------------------



  • 11.  RE: TMF620 - Modelling scaled prices

    TM Forum Member
    Posted Mar 30, 2023 11:45

    Hi Matthieu,

    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. 



    ------------------------------
    Bostjan Keber
    Marand, software ltd
    ------------------------------