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
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.
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.
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.
Ignore this message (it was duplicating the message above).