Open APIs

 View Only
  • 1.  Aggregate ProductOffering

    Posted Nov 22, 2018 10:28
    Hi,

    Is it possible to group several ProductOffering into one if they correspond to different characteristics of the product?
    For example, there are two Internet ProductOffering. The first one is for a speed of 100 Mbit / s and a periodic price of $ 10, and the second one is 50 Mbit / s and a periodic price of $ 7.
    Is it possible to aggregate them in one ProductOffering with two prices having different PricePolicy. The SID model does not prohibit this, but in "TMF620_Product_Catalog_Management" the ProductOfferingPrice does not correlate with prodSpecCharValueUse of ProductOffering.


    Thank you in advance.



    ------------------------------
    Artem Brayko
    "Rostelecom Information Technology"
    ------------------------------


  • 2.  RE: Aggregate ProductOffering

    TM Forum Member
    Posted Nov 24, 2018 16:17
    We plan to introduce Policy into the product catalog API TMF620. Due to priority shifts this will not happen in release 18.5 but we hope that it will happen in release 19.0. One of the use cases for Policy is indeed to allow prices to be set automatically based on characteristic values.
    Just as a general point, the business (marketing arm) of the telco needs to decide whether it is better to have a single offering with variation according to characteristic values, or rather to have multiple closed offerings. There are advantages in both strategies, multiple offerings are probably simpler to market and get consumer understanding (the price is very clear up-front), but can results in offering explosion and maintenance overhead.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 3.  RE: Aggregate ProductOffering

    Posted Nov 27, 2018 14:02
    Howdy, Artem, Jonathan, and all.

    There is a direct association shown below between ProdSpecCharValueUse and ProductOfferingPrice that would satisfy Artem's requirement if one offering is the business decision. Otherwise if two offerings are created I don't think there is a need for this association or the use of Policy.

    While a Policy could be used instead if there is a single offering  it would require creating a lot of Policy entity instances. Sometimes simple associations that represent a "policy/rule" are preferable. There is a section in the Root Business Entities guide book's section on Characteristics titled "Policy vs Simplicity" that provides a bit more detail about what I am stating here. The choice of which to use is up to the business implementing this part of the SID.



    ------------------------------
    John Reilly
    John P. Reilly Sole Trader
    ------------------------------



  • 4.  RE: Aggregate ProductOffering

    TM Forum Member
    Posted Nov 28, 2018 16:08
    Hi,

    I'm not sure it helps, but I can share our experience. At Marand, we developed a SID-based unified product catalog that drives most BSS components. To make a single internet product offering for all bandwidths possible, we extended our internal implementation of the SID with a concept called 'parametric price'.
    We simply associated characteristic's domain elements with price amounts. The simplest version is a single-characteristic price (e.g. bandwidth drives the amount selection). The more complex version is when several characteristics drive the amount selection (e.g. L1 technology {fiber, copper, LTE,...}, L2 technology {ADSL, VDSL,....}, and bandwidth).  The bandwidth characteristic is normally used for service provisioning, so the main benefit of characteristic-driven prices is to ensure OSS provisions the same characteristic value that BSS (billing) charges. This way, you prevent revenue leaks.

    On the other hand, we approached the solution with several product offerings when there was a necessity to establish relationships between the internet offering and different parent offerings (e.g. bundles), different child offerings (e.g. add-ons) or in case of different accounting rules based on the offering.

    Hope you'll find this useful.

    Regards,

    ------------------------------
    Bostjan Keber, Think!PLM product manager,
    Marand d.o.o.
    ------------------------------



  • 5.  RE: Aggregate ProductOffering

    Posted Nov 29, 2018 03:44
    In my view, the model should be like this. There is composition of ProductSpecification used, association between POP and ProductSpecification, and association between POP and ProdSpecCharValueUse.



    ------------------------------
    Artem Brayko
    "Rostelecom Information Technology"
    ------------------------------