Open APIs

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?

Hi Varun,

To my knowledge, there is no such specific way to say that a product offering is prepaid or postpaid, but you have several alternatives to model that. Right now, the following come to mind:

• You may extend the Product Offering class with Prepaid and Postpaid Product Offering specific classes. Regarding the API, this will be reflected in the field @type of the Product Offering resource.
• You may use a characteristic associated with the product offering. For example, one named 'contract_type' that could take the value 'prepaid' or 'postpaid'.
• You may just classify prepaid and postpaid offerings into different categories.

Hope it helps.

Best regards,

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?

Hi Varun, Abel,

A productOffering doesn't have to be specific for Prepaid or Postpaid. If needed to restrict the use of productOfferings this is usually done through MarketSegment by having separate Prepaid and Postpaid. A ProductOffering then targets a marketsegment.

The SID model provides a converged billing model that allows a customer to be set up with CustomerBillingAccounts that have a creditlimit and a set of balances. 

A customer with a credit limit of 0 can basically only consume services via its prepaid balances.

In that sense prepaid or postpaid is a marketsegment and customers in that marketsegment get their CustomerBillingAccount set up in a particular way.

Regards

Hi Varun,

To my knowledge, there is no such specific way to say that a product offering is prepaid or postpaid, but you have several alternatives to model that. Right now, the following come to mind:

• You may extend the Product Offering class with Prepaid and Postpaid Product Offering specific classes. Regarding the API, this will be reflected in the field @type of the Product Offering resource.
• You may use a characteristic associated with the product offering. For example, one named 'contract_type' that could take the value 'prepaid' or 'postpaid'.
• You may just classify prepaid and postpaid offerings into different categories.

Hope it helps.

Best regards,

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?

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?

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!

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?

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?

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!

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?

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.

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?

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!

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?

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)?

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.

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?

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!

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?

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)?

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.

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?

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!

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?

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?

There is an existing way to specify pre vs post paid products in the current structure since it is a payment method distinction.
Using PriceType and RecurringChargePeriod highlighted below...

You could also make use of Categories or Catalog if you want to group products that way and create a Prepaid and Postpaid specific view.

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?

Hello, @Theuns van Onselen,

There are some principles that we should adhere to when modeling data entities:

Entity-Attribute-Value (EAV) Model: This model separates the entity (your product offering), the attribute (price type, for example), and the value (one-time or recurring). This separation allows for more flexibility and scalability, accommodating products with diverse pricing structures.

Single Responsibility Principle: A class (or in this case, a data entity) should have only one reason to change. Applying this to data modeling suggests that the price entity should only be responsible for pricing information, not for determining the type of product offering.

Data Integrity and Semantics: Using price type alone to infer the nature of the product offering can lead to semantic confusion and potential data integrity issues, especially when products have mixed pricing models. example:
An post-paid offer can have 3 POPs: a recurring charge, a usage charge and a one-time charge (i.e. for activation fee etc).
and if we consider bundle product offering, then things get even more complicated as the bundle can have bundledproductofferings with different price types (a handset paid one time + data paid every month)

Regarding your suggestion about using "Payment method". I suspect you didn't mean to use "payment method" but "price type".
"Payment method" does not belong to the Product domain but to the Party domain. you can find it in the SID dictionary:

My 2 cents

There is an existing way to specify pre vs post paid products in the current structure since it is a payment method distinction.
Using PriceType and RecurringChargePeriod highlighted below...

You could also make use of Categories or Catalog if you want to group products that way and create a Prepaid and Postpaid specific view.

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?

Hello, @Theuns van Onselen,

There are some principles that we should adhere to when modeling data entities:

Entity-Attribute-Value (EAV) Model: This model separates the entity (your product offering), the attribute (price type, for example), and the value (one-time or recurring). This separation allows for more flexibility and scalability, accommodating products with diverse pricing structures.

Single Responsibility Principle: A class (or in this case, a data entity) should have only one reason to change. Applying this to data modeling suggests that the price entity should only be responsible for pricing information, not for determining the type of product offering.

Data Integrity and Semantics: Using price type alone to infer the nature of the product offering can lead to semantic confusion and potential data integrity issues, especially when products have mixed pricing models. example:
An post-paid offer can have 3 POPs: a recurring charge, a usage charge and a one-time charge (i.e. for activation fee etc).
and if we consider bundle product offering, then things get even more complicated as the bundle can have bundledproductofferings with different price types (a handset paid one time + data paid every month)

Regarding your suggestion about using "Payment method". I suspect you didn't mean to use "payment method" but "price type".
"Payment method" does not belong to the Product domain but to the Party domain. you can find it in the SID dictionary:

My 2 cents

There is an existing way to specify pre vs post paid products in the current structure since it is a payment method distinction.
Using PriceType and RecurringChargePeriod highlighted below...

You could also make use of Categories or Catalog if you want to group products that way and create a Prepaid and Postpaid specific view.

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?

Hello Theuns,
Maybe I misunderstood you my comment is specifically related to this text:

• My opinion is that it is not a payment method distinction. (I use the TMF definition of payment method). Reason is that CSP can sell both pre and post paid subscriptions using the exact same payment method (for instance Paypal or direct debit, stripe, Klarna etc).
• Using priceType and RecurringChargePeriod is not good enough. priceType "describes the price such as recurring, one time and usage."
  • While "recurring" clearly hints that the POP is for a "postpaid" subscription, which value are you going to use to define pre-paid?
  • using "one time" does not indicate that the she subscription is pre-paid. It could also be an activation charge (that exists for both for pre and post paid POs) or simply the price of a tangible good, which is not a subscription. 

pre vs postpaid is simply a payment timing question, (SID has some mention of "payment timing" but it's not associated to the product domain.

I also did some research on TMF confluence. I found 2 other suggestions:

• the Analytics Big Data Repository (ABDR) data entity definitions suggests to add a new attribute in the SID called subscription type with values = (prepaid, postpaid, hybrid…). This would be the best solution and is what OP is actually asking. That way you have the information available at marketing level (the PO) and can be used to better target certain customer segment, market etc.
• The SID actually suggests to use networkProdSpec, it has an attribute called isUsageMonitoring. when set to N, "corresponds to a blocked package (aka prepaid package)" (GB922 product). This approach is great because it allows a distinction the difference at functional level. ProdSpec. I think OP wants a distinction at marketing level (PO)
• Product Category would be nice but they don't exist in the SID at product offering level. they only exist at productSpec level. 
• product catalogue category is not ideal because catalogue category is a way to organise your offers that are sellable as standalone offers.
  But. CSPs have many product offerings that are not in the product catalogue because  isSellableStandAlone = N but as still sellable as part of a bundle.

Hello, @Theuns van Onselen,

There are some principles that we should adhere to when modeling data entities:

Entity-Attribute-Value (EAV) Model: This model separates the entity (your product offering), the attribute (price type, for example), and the value (one-time or recurring). This separation allows for more flexibility and scalability, accommodating products with diverse pricing structures.

Single Responsibility Principle: A class (or in this case, a data entity) should have only one reason to change. Applying this to data modeling suggests that the price entity should only be responsible for pricing information, not for determining the type of product offering.

Data Integrity and Semantics: Using price type alone to infer the nature of the product offering can lead to semantic confusion and potential data integrity issues, especially when products have mixed pricing models. example:
An post-paid offer can have 3 POPs: a recurring charge, a usage charge and a one-time charge (i.e. for activation fee etc).
and if we consider bundle product offering, then things get even more complicated as the bundle can have bundledproductofferings with different price types (a handset paid one time + data paid every month)

Regarding your suggestion about using "Payment method". I suspect you didn't mean to use "payment method" but "price type".
"Payment method" does not belong to the Product domain but to the Party domain. you can find it in the SID dictionary:

My 2 cents

There is an existing way to specify pre vs post paid products in the current structure since it is a payment method distinction.
Using PriceType and RecurringChargePeriod highlighted below...

You could also make use of Categories or Catalog if you want to group products that way and create a Prepaid and Postpaid specific view.

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?

Hello Theuns,
Maybe I misunderstood you my comment is specifically related to this text:

• My opinion is that it is not a payment method distinction. (I use the TMF definition of payment method). Reason is that CSP can sell both pre and post paid subscriptions using the exact same payment method (for instance Paypal or direct debit, stripe, Klarna etc).
• Using priceType and RecurringChargePeriod is not good enough. priceType "describes the price such as recurring, one time and usage."
  • While "recurring" clearly hints that the POP is for a "postpaid" subscription, which value are you going to use to define pre-paid?
  • using "one time" does not indicate that the she subscription is pre-paid. It could also be an activation charge (that exists for both for pre and post paid POs) or simply the price of a tangible good, which is not a subscription. 

pre vs postpaid is simply a payment timing question, (SID has some mention of "payment timing" but it's not associated to the product domain.

I also did some research on TMF confluence. I found 2 other suggestions:

• the Analytics Big Data Repository (ABDR) data entity definitions suggests to add a new attribute in the SID called subscription type with values = (prepaid, postpaid, hybrid…). This would be the best solution and is what OP is actually asking. That way you have the information available at marketing level (the PO) and can be used to better target certain customer segment, market etc.
• The SID actually suggests to use networkProdSpec, it has an attribute called isUsageMonitoring. when set to N, "corresponds to a blocked package (aka prepaid package)" (GB922 product). This approach is great because it allows a distinction the difference at functional level. ProdSpec. I think OP wants a distinction at marketing level (PO)
• Product Category would be nice but they don't exist in the SID at product offering level. they only exist at productSpec level. 
• product catalogue category is not ideal because catalogue category is a way to organise your offers that are sellable as standalone offers.
  But. CSPs have many product offerings that are not in the product catalogue because  isSellableStandAlone = N but as still sellable as part of a bundle.

Hello, @Theuns van Onselen,

There are some principles that we should adhere to when modeling data entities:

Entity-Attribute-Value (EAV) Model: This model separates the entity (your product offering), the attribute (price type, for example), and the value (one-time or recurring). This separation allows for more flexibility and scalability, accommodating products with diverse pricing structures.

Single Responsibility Principle: A class (or in this case, a data entity) should have only one reason to change. Applying this to data modeling suggests that the price entity should only be responsible for pricing information, not for determining the type of product offering.

Data Integrity and Semantics: Using price type alone to infer the nature of the product offering can lead to semantic confusion and potential data integrity issues, especially when products have mixed pricing models. example:
An post-paid offer can have 3 POPs: a recurring charge, a usage charge and a one-time charge (i.e. for activation fee etc).
and if we consider bundle product offering, then things get even more complicated as the bundle can have bundledproductofferings with different price types (a handset paid one time + data paid every month)

Regarding your suggestion about using "Payment method". I suspect you didn't mean to use "payment method" but "price type".
"Payment method" does not belong to the Product domain but to the Party domain. you can find it in the SID dictionary:

My 2 cents

There is an existing way to specify pre vs post paid products in the current structure since it is a payment method distinction.
Using PriceType and RecurringChargePeriod highlighted below...

You could also make use of Categories or Catalog if you want to group products that way and create a Prepaid and Postpaid specific view.

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?