Open APIs

 View Only
  • 1.  TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Apr 20, 2021 08:14

    Hello,

    I have a question regarding ProductPrice resource exposed in TMF 637 API in a flatten way, compared with SID model where the ProductPrice can be composed of multiple prices. Flattening a complex structure of composite prices with multiple alterations at different layers can be quite a challenge considering their stacking and sequencing. Having this in mind, we would like to understand how these use cases are handled at API level as we are missing the reasons/concerns for not exposing the hierarchy at API level as well.

    Following a similar approach as for Product Offering Prices (considering that a ProductPrice is an instantiation of a ProductOfferingPrice),  and trying to add a new attribute bundledProductPricesRelationship (similar with bundlePopRelationship) for exposing the bundled product prices (as references) it's not feasible as long as we don't have APIs to expose the ProductPrice resource only, therefore we are thinking to add a new attribute – bundledProductPrices ( List of ProductPrice) in order to expose the entire product price hierarchy.

    We would like to keep the resources as per Open API , so we are keen to receive guidance from your side on this topic.

    Thanks in advance,
    Mihaela

     



    ------------------------------
    Mihaela Bordean
    IBM Corporation
    ------------------------------


  • 2.  RE: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Apr 21, 2021 01:43
    Hi Mihaela
    As a general rule (not just here), we find that when mapping between the SID and the Open API, a lot of flattening takes place, and indeed other simplifications. This is due to the different purposes of the models:
    • The SID is a canonical, normalized information model that describes the service provider business. It is not intended for direct implementation (as far as I am aware) in databases or in APIs
    • The Open API needs a practically usable resource model for REST API payloads.
    Specifically for product pricing, my personal opinion is that you would need to have a very good and convincing use case to have complex prices. I suggest that if relevant you present the use case to the community forum and we can then discuss how the Open API model could represent, both in catalog and in the inventory.
    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: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Nov 14, 2023 06:14

    Hello Jonathan, 

    As a follow-up to your answer given to Mihaela, I have come up with an example of a composite price that we want to map to a flat list of prices, but we struggled to find a correct way and we want to see what is your approach. In the example below, on the left side is the Product Offering Price structure, and on the right side is one of our options for flattening the price.
    We assumed that the composite prices (the ones in blue) only exist in the catalog for grouping other prices, and they may not have a correspondent price in the billing system, so in the flattened list we put only the prices that have an actual value to be charged and have a billing correspondent. The price alteration from example (PA 3.3) is linked to each product price to which it is applied (as we have a relation between PriceAlteration and ProductPrice at API level). 

    Besides this example we may have a case when all the prices have a correspondent in billing (including the composite ones in blue). Then, what prices should appear in the flat list in order to be sure of the following (?): 
      1. All the information required by the billing system is provided. 
      2. There is no duplicate information in the flattened list that may lead to charging the same price more than once by the billing system; Duplicate information may appear if, for example, both POP2.1 and its children (POP3.1 and POP3.2) are provided in the flattened list. 
      3. The billing system understands how to apply correctly the price alterations to the product prices.

    We would like to see what is your approach to mapping the price from the example above.
    I hope I explained well enough to be understood by everyone.

    Thanks in advance! 
    Razvan.



    ------------------------------
    Boldor Razvan
    IBM Corporation
    ------------------------------



  • 4.  RE: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Nov 15, 2023 01:16

    Hi Boldor

    The ProductOfferingPrice model in TMF620 allows complex price relationships, so there is nothing stopping you from creating the tree structure. You have strict containment (bundledPopRelationship) and reference (popRelationship) available, if there is such a need. If you create such structures in your product + pricing catalog, it's up to the billing and/or charging system in your deployment to interpret the structure correctly.

    The simplification that I was talking about was in the class structure; we only have a single class for offering price, as against the SID that has all the variations for OC, RC, UC, discount, etc.



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



  • 5.  RE: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Nov 16, 2023 06:45

    Hi Jonathan, 

    It is possible that I did not express myself correctly. 
    The problem is not with the ProductOfferingPrice model, which allows the recreation of the tree structure at API level (using bundledPopRelationship and popRelationship). The problem is with the ProductPrice model, which keeps the same tree structure as ProductOfferingPrice model, but the relations between ProductPrices at API level are no longer there. 

    If we have the Product Price structure shown above, taking into account that for Product Prices we don't have any relation at the API level, how should this be mapped to a flat list of prices in order to be sure that the information from the list is interpreted correctly by the billing system (or any other system that may need pricing information for a product) ?. As I said in the previous message, mapping all product prices to the flat list may lead to duplicating the information (if PP2.1 and its child prices, PP3.1 and PP3.2). 

    This product price structure is from a real-world case for which we can't find a way of mapping the tree structure to a flat list. It would help us to know why TMForum chose to expose the ProductPrice in a flattened way and not keep the same relations between Product Prices as for Product Offering Prices. 

    Have you thought of a general rule for mapping the tree structure of a Product Price to a flat list when the decision to flatten the Product Price structure at API level was made? 

    Thanks in advance! 
    Razvan.



    ------------------------------
    Boldor Razvan
    IBM Corporation
    ------------------------------



  • 6.  RE: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Dec 04, 2023 06:25

    Sorry for the delay in the answer, and I'm afraid you may not be satisfied.
    But ProductPrice has a reference to the corresponding catalog POP - so if the tree structure is of critical importance you can recover it by following the catalog references.



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



  • 7.  RE: TMF637 ProductPrice (exposing CompositeProdPrice)

    TM Forum Member
    Posted Nov 14, 2023 06:35
    Edited by Boldor Razvan Nov 14, 2023 06:37

    Ignore this message (it was duplicating the message above).