Open APIs

 View Only
  • 1.  TMF620 - ProductOffering-BundledProductSpecification

    TM Forum Member
    Posted Apr 24, 2020 13:49
    Edited by Leena Jain Apr 24, 2020 13:50
    Hi All,

    Let say a BundledProductSpecification is created of two SimpleProductSpecifications (prodspec1 & prodspec2). BundledProductSpecification has characteristics (x,y,z) and SimpleProductSpecifications has its own characteristics (a,b,c)

    If a productOffering is created with a BundledProductSpecification, the productSpecificationCharacteristics (a,b,c) of SimpleProductSpecifications can be inherited as 'ProductSpecificationCharacteristicValue' and allowed to be modified at product offering level?


    ------------------------------
    Leena Jain
    ------------------------------


  • 2.  RE: TMF620 - ProductOffering-BundledProductSpecification

    TM Forum Member
    Posted Apr 26, 2020 08:23
    Hi Leena

    First, we should be clear that there is no given relationship between the characteristics of the bundling product specification and the contained product specifications. One use case for bundling at specification level is when specifications are complex and could cause confusion if everything was placed in one specification. Another use case could be when you want to re-use a specification, e.g. assuming that there were no commercial considerations voicemail could be re-used (perhaps) in mobile voice, VoIP, or even PSTN.

    The product offerings used to sell the bundle spec refer directly only to the bundle spec, say VoIP. But with the ProductSpecificationCharacteristicValueUse in product offering, you can "reach" into the contained simple product spec and restrict the list of valid values differently as needed for each offering that sells VoIP.

    Hope it helps

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



  • 3.  RE: TMF620 - ProductOffering-BundledProductSpecification

    Posted Jan 10, 2024 20:34

    Hi Jonathan,

    Sorry for replying on the old thread. While i was going through this thread, i find it a little difficult to correlate between your explanation here and TMF620 List Product Specifications API.

    Screenshots from the doc regarding this API:

    Product Specification with isBundle = true

    And it has list of product specifications.

    As against my understanding, it (bundling product specification) has product characteristics attached to it. As per what i understand from your previous explanation, bundling product specification is just a virtual entity that groups bundled product specifications and these bundled product specifications are nothing but simple/atomic product specifications which has characteristics attached to it. 

    My another question is, when to use composite product specification vs product specification relation.

    Can you shred some light on these items please ?



    ------------------------------
    Mahesh Kothamasu
    SP Telecommunications Pte Ltd
    ------------------------------



  • 4.  RE: TMF620 - ProductOffering-BundledProductSpecification

    TM Forum Member
    Posted 20 days ago

    Hi @Jonathan Goldberg.

    This is very good question from Mahesh: "when to use composite product specification vs product specification relation". What's your experience?



    ------------------------------
    Jan Brnka
    T-Mobile Czech & Slovak Telekom, a.s.
    ------------------------------



  • 5.  RE: TMF620 - ProductOffering-BundledProductSpecification

    TM Forum Member
    Posted 19 days ago

    hi,

    it's the same as productoffering bundling vs productoffering relationships.

    bundling PS is static, there are no nuances. if you want to model a mobile subscription in a very simple product offering, you could bundle PS (sim card, voice, data...) needed to realise the offer.
    There is a very old example in GB922, I think in the "common" guide not in the product guide, with a toyota yaris that bundles PS because the various PS are always realised together.

    if you use a Product Configurator to assist customer in personalising their offer, composite PS works very well. You can present all the characteristic together.

    relationships is more powerful and offer nuances. It's particularly pertinent for business rules (require, exclude, recommend, depends etc)

    There are many examples, for instance in IG1228, check the PS relationships 

    If you have a business rules that says "TV Decoder" PS requires "IPTV" PS, you can create a single relationship between the 2 PS to enforce your business rule, instead of creating tens of relationships between product offerings. relationships between PS (or even between PO) are great if you product catalogue is based on "soft" bundles.

    Matthieu


    PS Jonathan is now a pensioner and has left his company.



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

    Matthieu Hattab
    Lyse Tele AS
    ------------------------------