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
------------------------------
Original Message:
Sent: Mar 10, 2023 08:45
From: Pekka Mikkola
Subject: Representation of an Offer abiding TMF standards
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
------------------------------
Original Message:
Sent: Feb 28, 2023 18:09
From: Matthieu Hattab
Subject: Representation of an Offer abiding TMF standards
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
Original Message:
Sent: Feb 28, 2023 10:39
From: Koen Peeters
Subject: Representation of an Offer abiding TMF standards
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
ProductOffering 2:
- ProductSpecification 1
- Term
- MinimumContractDuration: 3 year
- Price
ProductOffering 3:
- ProductSpecification 1
- Not assigned to a category and therefore not selectable
- Term
- MinimumContractDuration: 1 year
- Price
ProductOffering 4:
- ProductSpecification 2
- Not assigned to a category and therefore not selectable
- Term
- MinimumContractDuration: 1 year
- Price
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
Original Message:
Sent: Feb 27, 2023 08:55
From: Matthieu Hattab
Subject: Representation of an Offer abiding TMF standards
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