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
------------------------------
Original Message:
Sent: Jan 30, 2025 02:58
From: Jan Brnka
Subject: TMF620 - ProductOffering-BundledProductSpecification
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.
Original Message:
Sent: Apr 26, 2020 08:22
From: Jonathan Goldberg
Subject: TMF620 - ProductOffering-BundledProductSpecification
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.
Original Message:
Sent: Apr 24, 2020 13:48
From: Leena Jain
Subject: TMF620 - ProductOffering-BundledProductSpecification
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
------------------------------