Open APIs

 View Only
  • 1.  Representation of an Offer abiding TMF standards

    Posted Feb 24, 2023 05:55

    Hi all, A complete beginner here. 

    I need to represent a Telecom bundle in TMF620 Product Catalog. But I cannot fit in the following particular offer.

    A bundle of costing 5$ with 5GB data, 1000 mins and 1000 SMS. If a subscriber buys this bundle for more than 3 times, the subscriber will be able to buy the same bundle at a discounted price(3$) or with an increased allowance(8GB).

    Also, we are configuring different price for different terms of the same offering. How to convert this to TMF standard.

    Appreciate any help.

    Thanks.



    ------------------------------
    Manoranjan Ramamoorthy
    ZOHO Corporation Private Limited
    ------------------------------


  • 2.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Feb 26, 2023 09:43

    Hi Manoranjan

    Thanks for your question. The challenge here is that the basic catalog model in TMF620 does not have any expression of business rules. So in v5 we are enhancing the API and model to add a Policy reference, and a separate Policy Management API that allows authoring of Policies. A Policy rule has an event that activates the rule, a condition that determines if the outcome will happen or not, and an action that is the outcome. This flexible Policy rule should allow you express pricing rules such as in your example.

    The API finalization for v5 is still in progress, but you can find a draft swagger for TMF723 Policy Management at the early access Open API table here:

    https://projects.tmforum.org/wiki/pages/viewpage.action?pageId=128855518

    Hope it helps



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 3.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Feb 27, 2023 08:55

    Also, we are configuring different price for different terms of the same offering. How to convert this to TMF standard.

    This is already supported by current API (V4.x) you have a relationship between the POP and the product term.

    A easy example (also illustrated in GB922 Product, under chapter "Product Offering Terms") of how this is used is:

    the recurring price is €6 per month if the contract duration is 1 year
    but only €5 per month if the contract duration is 2 years.

    By the way, In addition to Jonathan's suggestion of using Policies, TM Forum also suggests (in GB922 - Product) that "Product Terms" can be used to model discount based on the quantity ordered (aka volume discount). Such discount would have to be related to a product term that your customer and your enterprise would have to sign.

    so in short, you shouldn't have to wait for the API v5.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 4.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Feb 28, 2023 10:40

    Hi,

    It is obviously possible to design complex logic with business rules in a catalog.

    Most of the time this can be also solved by just creating a flat list of ProductOfferings. (This is how things were done when we still had paper catalogs)

    productSpecification 1:

    • 5 Gb Data
    • 1000 SMS
    • 1000 Min voice

    productSpecification 2:

    • 8 Gb Data
    • 1000 SMS
    • 1000 Min voice

    ProductOffering 1:

    • ProductSpecification 1
    • Term
      • MinimumContractDuration: 1 year
    • Price
      • €5

    ProductOffering 2:

    • ProductSpecification 1
    •  Term
      • MinimumContractDuration: 3 year
    • Price
      • €4

    ProductOffering 3:

    • ProductSpecification 1
    • Not assigned to a category and therefore not selectable
    •  Term
      • MinimumContractDuration: 1 year
    • Price
      • €3

    ProductOffering 4:

    • ProductSpecification 2
    • Not assigned to a category and therefore not selectable
    •  Term
      • MinimumContractDuration: 1 year
    • Price
      • €5

    ProductOffering 5:

    • Bundles
      • ProductOffering 3
      • minCardinality: 3
      • maxCardinality: 10

    ProductOffering 6:

    • Bundles
      • ProductOffering 4
      • minCardinality: 3
      • maxCardinality: 10

    Category

    • name: selectable options
    • contains
      • productOffering 1: 1 year contract
      • productOffering 2: 3 year contract
      • productOffering 5: 1 year contract, >=3, discounted price
      • productOffering 6: 1 year contract, >=3, more Data

    I hope this helps.



    ------------------------------
    Koen Peeters
    OryxGateway
    ------------------------------



  • 5.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Feb 28, 2023 15:48

    Thanks Matthieu and Koen for your additional insights.

    The advantage of Koen's approach is that there is a very clear offering, the customer chooses that offering and we know what to do. The disadvantage is what we call "offering explosion", the number of offerings increases according to the cartesian product of all the different configuration value combinations.



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
    ------------------------------



  • 6.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Feb 28, 2023 18:09

    Denormalizing product offering to avoid logic is a risky proposition. It was possibly unavoidable decades ago, but today with multi-channel commerce where product portfolio simplification and customer experience should be top priorities. I've done and seen this several times before and all I remember is too much human errors, too much testing, massive data maintenance (PCM of course but also PIM/CMS/PXM, DAM) long time-to-market, expensive, complex, not scalable, not future proof and a product model that doesn't take into account customer experience.

    Then, this approach could work with simple volume discount but is not realistic with tiered volume discount (as the unit price change for each additional ordered unit)

    Another thing to keep in mind: working with tiered volume discount, especially in the B2B enterprise market, can mean calculating the projected product count (number of subscriptions in the product inventory + number of subscriptions in open carts/orders) to determine what discount applies to the current order. e.g. if customer already bought 10 subscriptions last month and today, they buy 2 more subscriptions (projected product count = 12), today's order with only these 2 extra products would still need the highest discount (as if customer had bought the 12 product offers at once)

    My 2 cents.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------



  • 7.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Mar 10, 2023 10:12

    Hello all,

    Question for Jonathan, Matthieu and other:

    When serious B2B Business is actually making Quotes and Contracts more or less like Matthieu described "Why this B2B Product Offering pricing model (Let's call it Solution pricing) is not covered in TMF SID model or other applicable TAM/ODA/eTOM Use Cases ? We can't even call pricing as "Bundle pricing" when bundles are considered as "fixed PO construction" but in practical Complex B2B cases, Solution is varying a lot, case by case. Sure certain "Solution package trends" can be recognized and should be storable to Catalog with "sample pricing from the last cases".



    ------------------------------
    Pekka Mikkola
    Telia Company
    ------------------------------



  • 8.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Mar 13, 2023 11:27

    Hi folks, I have been working with the ODA Transformation Guides stream, managed by @David Milham  and I am authoring a guide describing the differences between B2C and B2B/B2B2x concerns when implementing an ODA transformation.  The topic of "serious B2B Business" figures prominently.  I am about 2/3rds the way complete on this guide.  Once a review draft is complete, I can let folks here know that it is available for review and comment.



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



  • 9.  RE: Representation of an Offer abiding TMF standards

    TM Forum Member
    Posted Mar 13, 2023 14:27

    TMF620 is only a rather basic representation of the product offering, its specifications, prices and a bunch of relationships that can represent some simple pricing business rules, for example:

    • when a Price is applicable to a specific product term (productOfferingTerm)
    • or when a price is applicable to a specific characteristic value (prodSpecCharValueUse).

    The SID has a much more complete model for prices.

    When pricing calculation get complicated (and when vendors also need to show their prowess!), then TMF620 is content with just providing a policy Id (API v5) or a contraint Id (API v4) or a PricingLogicAlgorithm (API v4). 
    Which means the product catalogue component wouldn't contain any pricing policy or algorithm. Just their Ids. All the price policies, price algorithms, price constraints etc would be stored, maintained in the pricing engine. (TMF has this huge monolith-style component  called "TMFC002 Product Order Capture & Validation" that would store these pricing policies etc)

    For very simple pricing rules, say sales channel-specific pricing where a offer sells for €5 over the phone channel and €4 over the web channel, the API is already unable to do show that. however, the good news is you can also extend TMF620 and create a new relationship between POP and SalesChannel.

    • some basic common-sense rules and prices. It's difficult to use by front end directly, except to show the "starting at" price. you really need a pricing engine that fetches product offering and prices with TMF620 and return to the client (front end etc) calculated prices with TMF679. 

    Most vendors already have their own pricing solution they implemented years before TMF620 or TMF679 ever existed

    Beyond the "classic" ProductOfferingPrices relationships present in TMF620, "Price policies" is what most vendors would need to use to implement their pricing functionalities and distinguish from each other in the software market.



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------