Open APIs

 View Only
Expand all | Collapse all

Prepaid vs. Postpaid Product offerings in TMF Open API

  • 1.  Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 15, 2024 16:38

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


  • 2.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 16, 2024 02:51

    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,



    ------------------------------
    Abel Ruiz Huerta
    alvatross
    ------------------------------



  • 3.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 16, 2024 11:54

    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



    ------------------------------
    Koen Peeters
    OryxGateway FZ LLC
    ------------------------------



  • 4.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 16, 2024 15:49

    An interesting discussion.

    In Amdocs best practice we distinguish directly between prepaid and postpaid offerings, by extending the vanilla TMF model. We then use this to qualify for specific customer types and other factors, for example to offer only prepaid offerings to customers with high credit risk.

    But there are many ways to skin a cat, as they say, and other suggestions made on this thread could be equally valid. I would not recommend, however, using characteristics for this purpose - for taking decisions in software it's more robust to have strongly-typed properties.



    ------------------------------
    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: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 17, 2024 08:36

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



  • 6.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 25, 2024 21:48

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



  • 7.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Jan 31, 2024 06:49

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



  • 8.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted Feb 01, 2024 10:00

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



  • 9.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    Posted Feb 01, 2024 10:58
    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.

    Thanks,

    A close up of a logo  Description automatically generated

     

    Theuns van Onselen

     

    Senior Solution Architect:

    EBS - Architecture

       0112893000

     

      

     

      Theuns.vanOnselen@multichoice.co.za



    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.







  • 10.  RE: Prepaid vs. Postpaid Product offerings in TMF Open API

    TM Forum Member
    Posted 30 days ago

    Are we still discussing modelling pre-paid vs post paid?
    It doesn't seem so. price, "billing system" RFSS etc seem like a different conversation. It's best to create a separate thread else it's very difficult to follow the conversation



    ------------------------------
    Kind regards,

    Matthieu Hattab
    Lyse Platform
    ------------------------------