Open APIs

 View Only
Back to discussions
Expand all | Collapse all

productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

  • 1.  productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 09, 2025 08:28

    Hi all,

    I would like to post a question here, and apologize if this was already discussed in some other thread - I couldn't find it with search. 

    Let's assume we have 4 product specification - 1 composite and 3 atomic, related to this composite product specification. 

    We have product offering deriving from composite product specification.

    On product offering we are defining prodSpecCharValueUse - list of characteristics and their values. 

    My question is - are all those characteristics from prodSpecCharValueUse belonging to only this composite product specification? Or, can we have on our product Offering (deriving from composite prodSpec) prodSpecCharValueUse belonging to some of those 3 atomic product specification?

    Thanx,

    Dragana



    ------------------------------
    Dragana Popović
    ZIRA Ltd.
    ------------------------------


  • 2.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 05:20
    Edited by Imene Tekaya Jul 10, 2025 11:27

    Hello,

    On productOffering , the parameter isBundle can be used to determine if the productOffering is a bundle of productOffering or single. Then  the values of "prodSpecCharValueUse"  that follow will be related to the productOffering in question, whether atomic or composite 

    erratum: A CompositeProductOfferingSpecification in not directly associated with any productSpec, below details

    ------------------------------
    Imene Tekaya
    Sofrecom Tunisie
    ------------------------------

    Original Message


  • 3.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 08:30

    @Imene Tekaya,
    Your statement is not correct. Please refer to the rule in GB922:
    "A CompositeProductOfferingSpecification is not directly associated with any ProductSpecification. Instead, it contains ProductOfferingSpecifications, each of which may in turn be an AtomicProductOfferingSpecification that is associated with a ProductSpecification..."

    In layman's term, a bundle product offering cannot have a relationship with product specification, therefore bundle product offering cannot have a prodSpecCharValueUse relationship. You can also test it with the TMF620 conformance test, it will fail if you have a PS associated to a bundle PO



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

    Matthieu Hattab
    Digital Sales Domain Architect
    Lyse Tele AS
    ------------------------------

    Original Message


  • 4.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 06:05
    Edited by MMH HH Jul 10, 2025 06:06

    AFAIK, there is nothing in the Spec that prevents this. A `ProductOffering` can refer to `CharacteristicSpecification` in any `ProductSpecification` (it need not even be related to the ProductOffering in anyway). However, I'm not sure if this is frowned upon.



    ------------------------------
    Manu
    ------------------------------

    Original Message


  • 5.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 08:07

    Hi,

    In TMF620_Product_Catalog_userguide, it is stated for productOffering.prodSpecCharValueUse: "It should be noted that characteristics which their value(s) addressed by this object must exist in corresponding product specification."

    Now - I can interpret this "corresponding product specification" as THE product specification out product offer is deriving from.

    In that case, it means that productOffering.prodSpecCharValueUse can be referenced only to one product specification, the one product offer belongs to. 

    Also - from my point of view, I do not see a point that prodSpecCharValueUse under one product offer is referencing to some other product specification to fetch characteristic(s), since characteristics are reusable, and you can attach all needed characteristics to product specification where you need them. 

    Of course, there might be some use cases where it makes sense, to have prodSpecCharValueUse referencing to different product specifications.

    So this is my concern, how to understand this model of prodSpecCharValueUse and usability

    regards,

    Dragana



    ------------------------------
    Dragana Popović
    ZIRA Ltd.
    ------------------------------

    Original Message


  • 6.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 09:52

    I tend to agree with you. However, if we see closely, the `prodSpecCharValueUse` object has a reference to `ProductSpecification`. If a PO was to refer to only its own PS, then I feel there was no need for this. I'm planning to use this to create reusable CS in a common specification and refer them in different PO's (though not sure if this is the intended way for this).



    ------------------------------
    Manu
    ------------------------------

    Original Message


  • 7.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 11:09

    I tend to agree with you. However, if we see closely, the `prodSpecCharValueUse` object has a reference to `ProductSpecification`. If a PO was to refer to only its own PS, then I feel there was no need for this.

    I think you mean PSCVU (prodSpecCharValueUse is the relationship between PO and PSCVU) has a reference to ProductSpecification and for some reason I don't understand why it is.... optional.

    I wonder what use cases would use the relationship and what use cases would not.



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

    Matthieu Hattab
    Digital Sales Domain Architect
    Lyse Tele AS
    ------------------------------

    Original Message


  • 8.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

    TM Forum Member
    Posted Jul 10, 2025 10:56
    Edited by Matthieu Hattab Jul 10, 2025 11:55
    Hi Dragana,
    An example would have helped a lot but I understand you, y    ou've touched on a modelling challenge in the TM Forum SID
    Here's the situation you described (correct me if I'm wrong):
    • atomicProductOffering (PO)
      • has one CompositeProductSpecification (CPS)
        • has its own characteristics: C1, C2
        • contains:
          • AtomicProductSpecification 1
            • has its own characteristics: C3, C4
          • AtomicProductSpecification 2
            • has its own characteristics: C5, C6
          • AtomicProductSpecification 3
            • has its own characteristics: C7, C8
    Your question:
    How (if at all) does the CompositeProductSpecification become aware of all characteristics (char), fron C1 to C8 so you can use prodSpecCharValueUse between the ProductOffering and the chars

    short answer:

    There is no automatic aggregation or projection  to "surface" char of contained elements at the parent/root CompositeProductSpecification level in the SID or TMF620.

    Long answer:

    You could still implement a projection/aggregation in your product catalogue application before it generates the TMF620 payload but that's an implementation question outside the scope of TM forum and TMF620.

    Alternatively, you could investigate how to model awareness or exposure of all Characteristics (root and child level) using Manual Characteristic aggregation (you declare all char at the composite level or use Characteristic mapping (ProductSpecCharRelationship) These are not clean solutions but worth exploring.

    Or simply create separate POs, one per PS and then bundle the POs.

    Be mindful of other services that have a mandatory dependency on TMF620. Usual suspects are:

    • product configurator (TMF679, TMF760)
    • POCV (cart, order, quote...) sales capture APIs

    Especially TMF760 (or any configurator API, the challenge is the same)! It may be challenging to correctly expose the char in the computedProductConfiguration payload, which is often presented to the end users to customise the offer (BSS UI, self-service portal)

      Hopefully the owners of the SID product model and/or TMF620 will read your post and shed some light. 
      Bundling productSpecification is an interesting topic we rarely explore!



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

      Matthieu Hattab
      Digital Sales Domain Architect
      Lyse Tele AS
      ------------------------------

      Original Message


    • 9.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

      TM Forum Member
      Posted Aug 07, 2025 04:11

      Can a PSCVU have characteristics of all linked/referenced atomic PSs under a Bundle/Composite PS linked to a Product Offer?

      Answer from : Google Gemini 2.5 Pro: 

      Yes, absolutely. That is the designed purpose and a key strength of the ProductSpecificationCharValueUse (PSCVU) feature within the TMF 620 framework.

      A single Product Offering (PO) can indeed define, constrain, or override characteristics for any or all of the atomic Product Specifications (PSs) that are nested within its main composite PS.

      How It Works

      The prodSpecCharValueUse attribute in a ProductOffering is an array. You can add an entry to this array for every single characteristic you want to define, regardless of which underlying atomic PS it belongs to.

      The key to making this work is that each entry in the ProductSpecificationCharValueUse array includes a reference to the specific Product Specification that owns the characteristic.

      Let's revisit our "Smart Home Security Kit" example:

      • Product Offering (PO): "Premium Security Offer"

      • Composite PS: "Smart Home Security Spec"

      • Atomic PS #1: "Smart Doorbell Spec" (ID: PS-Doorbell-01) has a characteristic color.

      • Atomic PS #2: "Indoor Camera Spec" (ID: PS-Camera-01) has a characteristic resolution.

      To create a "Premium" offer that defines both the camera's resolution and the doorbell's color, the prodSpecCharValueUse section of your ProductOffering payload would look like this:

      <response-element class="" ng-version="0.0.0-PLACEHOLDER"></response-element>

      JSON 
      {
  "id": "PO-Premium-Kit",
  "name": "Premium Security Offer",
  "isBundle": true,
  "productSpecification": {
    "id": "PS-Composite-Kit",
    "href": "/api/productCatalog/v4/productSpecification/PS-Composite-Kit"
  },
  "prodSpecCharValueUse": [
    {
      "name": "resolution",
      "value": "4K",
      "productSpecification": {
        "id": "PS-Camera-01",
        "href": "/api/productCatalog/v4/productSpecification/PS-Camera-01"
      }
    },
    {
      "name": "color",
      "value": "Graphite",
      "productSpecification": {
        "id": "PS-Doorbell-01",
        "href": "/api/productCatalog/v4/productSpecification/PS-Doorbell-01"
      }
    }
  ]
}

      <response-element class="" ng-version="0.0.0-PLACEHOLDER"></response-element>

      As you can see, the prodSpecCharValueUse array contains two objects:

      1. The first one sets the resolution to "4K" and explicitly points to the "Indoor Camera Spec" (PS-Camera-01).

      2. The second one sets the color to "Graphite" and explicitly points to the "Smart Doorbell Spec" (PS-Doorbell-01).

      Why This Is a Powerful Concept

      This capability is fundamental to achieving commercial agility and a clean product catalog:

      • Decoupling: It separates the "what" (the technical specifications) from the "how you sell it" (the commercial offer).

      • Reusability: You can have one master "Smart Home Security Spec" bundle and use it to create endless commercial variations (e.g., "Basic Kit," "Premium Kit," "Black Friday Special Kit") just by changing the PSCVU values at the offer level.

      • Eliminates Catalog Bloat: You avoid creating dozens of nearly identical Product Specifications for each minor commercial variation.

      The limitation you described in your CPQ system is a critical one because it prevents you from leveraging this core, value-driving feature of the TMF 620 API.



      ------------------------------
      Shaik Karimulla
      Saudi Telecom Company
      ------------------------------

      Original Message


    • 10.  RE: productOffering.prodSpecCharValueUse can be referenced to one or more productSpecifications

      TM Forum Member
      Posted Aug 07, 2025 10:23

      @Shaik Karimulla,

      careful with AI tools, they tend to always find an answer even when there is none or it's wrong. The JSON looks pretty wrong and doesn't represent the answer to your question. for instance, you cannot have (isBundle = true) on the ProductOffering (PO)and reference a ProductSpecification (PS).


      We know that the       TMF620 Product Catalog Conformance document does not provide conditions for PSCVU (it says to look at a section of the document that does not exist).

      This means we can have many interpretations.

      We have to think of a pragmatic guideline (until TMF clarifies).

      This means we should think from the TMF620 API  consumer perspective.

      The Product Configurator* (TMFC0027), exposed via the queryProductConfiguration operation (TMF760), is the only consumer expected to enforce or interpret PSCVU constraints. So the rule must make sense to the API client. TMFC0027 consume TMF620 and through an orchestration of different API calls must be able to surface constrained characteristic in order to enforce the PSCVU rule.
      * "Product Configurator" is a rather functional and uninspiring name and your ISV may use a different term (CPQ, Commerce Composer...) but if we sell configurable offers to our customer, we use a Product Configurator!

      The only viable scenarios I can see are:

      ✅if the PO is atomic

      1. The PSCVU references a characteristic that belongs to the same PS (atomic or composite) as the PO's associated ProductSpecificationRef.

        1. this is your example, if (isBundle = fasle)

      2. The PSCVU references a characteristic that belongs to a nested PS within a composite PS used (ProductSpecificationRef) by the PO.

      ⚠️If the PO is a bundle

      1. The PSCVU references a characteristic that belongs to a PS associated with a nested atomic PO (at any depth) within the bundle (maybe even consider ProductRelationship if we're not using bundle product to enforce dependencies)

        1. I've modelled such configurations before, and it can become very complex to surface deeply nested characteristics. Good practices must guide catalogue modelling here.

      ❌ What won't work

      Let's say we define this:

      Premium Security PO constrains the value "Classical" of the "Genre" characteristic from the "Music" PS.

      But there is no relationship, no Music PS or PO bundled (at any depth) or referenced in Premium Security.

      Product configurator will not surface the "Genre" characteristic. The constraint becomes orphaned, and the TMF760 API will not understand or apply it.

      My two cents!



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

      Matthieu Hattab
      Digital Sales Domain Architect
      Lyse Tele AS
      ------------------------------

      Original Message