I would use this:
ProductOfffering -> ProductOffferingPriceRefOrValue -> POPAlteration
"POPAlteration = sub-resource Is an amount, usually of money, that modifies the price charged for an order item"
Normally you do not send a price, because the product catalog will have the default price. It is only if you have to override it for a reason. Normally, a discount offering item should be loaded to alter a price.
This electronic communication and the attached file(s) are subject to a disclaimer which can be viewed at https://www.multichoice.co.za/wp-content/uploads/2017/08/MultiChoice-email-disclaimer.pdf. If you are unable to view the disclaimer, please email disclaimer@multichoice.co.za for a copy.
Original Message:
Sent: 2/1/2024 9:17:00 AM
From: Claudia Ivette Falcon Mata
Subject: RE: Prepaid vs. Postpaid Product offerings in TMF Open API
Question,
If I had a Product OfferingPrice, and I need to inform this to my Billing System, with tech specs I need to map this POP to a RFSS (Because is a technical spec)?
------------------------------
Claudia Ivette Falcon Mata
Thinkskink
------------------------------
Original Message:
Sent: Jan 31, 2024 06:49
From: Matthieu Hattab
Subject: Prepaid vs. Postpaid Product offerings in TMF Open API
another approach could be to use attribute "referredType". An example I used for prices was set up as follow: Say we have 2 ProductOfferingPrice: a charge and a discount. In the API @referredType would show either:
- "@referredType": "ProductOfferingPriceCharge"
- "@referredType": "ProductOfferingPriceAlteration"
(a second attribute was also needed to indicate the type of alteration: "priceType": "discount")
you should be able to adopt a similar approach with product offering. TMF630 has more details on this "polymorphism" pattern.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jan 25, 2024 21:48
From: Varun Pandhi
Subject: Prepaid vs. Postpaid Product offerings in TMF Open API
Thanks everyone for the inputs.
In our implementation, we mandatorily need to specify at the time of product offer creation how charging will be done (Full lump sum payment at the time of purchase, postpaid (at end of each billing period), Prepaid (At start of each billing period) or via some external engine).
I believe since it needs to be specified upfront, we can't go via the Category because Category is optionally associated to Product Offering in TMF 620 Data Model. And, even if we do so, it would mean 4 different categories out of which one needs to be mandatorily included in POST request for Product Offering which might not fly per the cardinalities defined in TMF 620.
Regarding the other option of extending TMF data model for the same, based on what I read through in TMF 630, there are few options -
- Option 1: Create a class extended from TMF Base class for "ProductOffering" and including the new attribute in extended class
- Option 2: Include the new attribute in extendedSchema for "ProductOffering" (Don't sub class)
- Option 3: Use of characteristic pattern (Can be ignored as per previously highlighted responses)
Is there a real distinction/recommendation on when we should use Option 1 or 2 (or 3 too?) ?
Moreover, in this particular case, can we define a data type for new attribute for something equivalent to List of Values? I have seen String, Id, Integer only as possible data types of attributes in TMF Data model thus far. Is there a master list of available data types for use which can be referenced?
------------------------------
Varun Pandhi
Infosys
Original Message:
Sent: Jan 17, 2024 08:36
From: Matthieu Hattab
Subject: Prepaid vs. Postpaid Product offerings in TMF Open API
Hello,
It really depends what you need to achieve. some examples we implemented
- organise the customer front-end so they see prepaid and postpaid offers are displayed differently (different web pages etc)
- a good solution is to use Product Catalogue and Catalogue categories
- Manage a product porftfolio or group product with common characteristics
- a good solution is to use Product Line or Product Category (which can be nested, linked etc). see GB922 Product for details, It's not supported by the 620 API, though.
- I would love TMF to introduce product line and category at product offering level, (not just prodspec) so marketeers have more flexibility to organise or tag product offers from a marketing and sales perspective. You can use a PIM (product information management) for that purpose or even a CMS.
there could be more use cases, for billing, pricing, common qualification rules... with different solutions.
On a old project, we had to use the Product offering related pricetype (recurring vs one-time) to distinguish prepaid from postpaid because this distinction was used to trigger a credit check (if the product has a recurring charge).
PS: I would avoid Market Segment. It's not meant to group product offering. to group the target audience of a product offering. you use market Segment to group Parties (customers, GeographicAreas, SalesChannels). As the information model writes, "MarketSegments are the target of MarketingCampaigns, ProductOfferings, ProductPromotions...)
PS: I also see that prepaid and postpaid no longer mean what they used to mean 10 years. My ISP use the term "prepaid" for my internet subscription because the invoice is sent and must be paid a month before the service is delivered!
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jan 15, 2024 16:37
From: Varun Pandhi
Subject: Prepaid vs. Postpaid Product offerings in TMF Open API
Hi all,
Is there a way to distinguish between Prepaid vs. Postpaid product offerings in TMF APIs? If yes, how can this be achieved? Or does TMF provide distinction of Postpaid vs. Prepaid at a different resource than Product Offerings?
------------------------------
Varun Pandhi
Infosys
------------------------------