Thanks for your insights.
Original Message:
Sent: Jan 17, 2024 06:34
From: Matthieu Hattab
Subject: Bundle Product Specification with characteristics
Sorry for replying on the old thread
what thread? it looks like you created a new post.
Regarding your interpretation of modeling characteristics, I agree that a composite ProductSpec (incorporating product characteristics, service spec, and resource spec) seems counterintuitive. An analogy from the "GB922 - Product" Information Model's product offering composite pattern might clarify this:
A BundledProductOffering is not directly associated with any ProductSpecification. Instead it contains ProductOfferings, each of which may in turn be a SimpleProductOffering that is associated with a ProductSpecification,
I'd expect the composite ProductSpec to align with this concept. Also, reviewing the conformance profile for the API might shed light on existing rules for the composite pattern.
My another question is, when to use composite product specification vs product specification relation.
For this, I recommend reading two documents:
- GB922 Product: It provides definitions and examples of both the composite pattern and the relationship pattern.
- IG1228: Focus on the order capture and Order Delivery use cases. They offer a Global Catalog view, demonstrating how ProdSpec relationships function. Note that there are no examples of ProdSpec bundles here.
In some scenarios, composite and relationships can achieve the same outcome. Relationships offer more flexibility with the attributes "type" and "role", refining business rules. They enable business rule creation between product specs/product offerings that aren't bundled.
For instance, selling the stand-alone ITPV ProductOffering requires the customer's service address to have internet connectivity, but not necessarily an internet subscription. This business rule is stored in the product catalogue as a relationship:
"IPTV productSpec requires internet connectivity productSpec," ("requires" being the relationship type attribute)
Such a rule couldn't be modeled with a composite/bundle ProductSpec, as IPTV is a stand-alone offer, not sold bundled with Internet.
the entity relationships pattern has more use cases at product offering level (static upsell etc) than at product spec level
My 2 cents.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jan 17, 2024 04:43
From: Mahesh Kothamasu
Subject: Bundle Product Specification with characteristics
Hi,
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
------------------------------