Open APIs

 View Only
Expand all | Collapse all

Clarifications on Bundling, Price Placement, and ProductOffering in Quote & Order APIs

  • 1.  Clarifications on Bundling, Price Placement, and ProductOffering in Quote & Order APIs

    TM Forum Member
    Posted May 13, 2025 04:07

    Hi there,

    I hope you're all well. We're currently implementing Quote Management, Product Ordering, and Product Inventory flows based on TMF Open APIs, and we've come across a few points where documentation and examples suggest one approach, but we're unsure whether alternative approaches are equally valid or even preferable.

    I'd be grateful for your insights on the following:

    1) Flat vs Nested Structure for Bundled Products

    In the official examples for Quote, ProductOrder, and ProductInventory, bundled items are usually represented using a flat productOrderItem array, with relationships marked via productOrderItemRelationship.type = "bundles".
    However, the productOrderItem and quoteItem schemas also support nesting. Since our product catalog is modelled with a nested bundle structure (parent ProductOffering containing child offerings), it feels more natural and cleaner to mirror this in orders and quotes via nesting.
    Is nesting an equally valid and recommended approach to represent bundled products, especially when it reflects the hierarchy of the catalog? Are there cases where one method is preferred over the other?

    Nested structure as it appears in product catalog:

    "quoteItem": [
        {
          "id": "1",
          "@type": "QuoteItem",
          "action": "add",
          "quantity": 1,
          "productOffering": {
            "@type": "ProductOfferingRef",
            "id": "<UID_FOR_MSB_BUNDLE>",
            "name": "Managed Security Box Bundle"
          },
          "quoteItem": [
            {
              "@type": "QuoteItem",
              "id": "1.1",
              "action": "add",
              "productOffering": {
                "@type": "ProductOfferingRef",
                "id": "<UID_FOR_MSB>",
                "name": "Managed Security Box"
              },
              "quantity": 1
            },
            {
              "@type": "QuoteItem",
              "id": "1.2",
              "action": "add",
              "productOffering": {
                "@type": "ProductOfferingRef",
                "id": "<UID_FOR_COMMITMENT>",
                "name": "Commitment"
              },
              "quantity": 1
            }
          ]
        }
      ]


    Flat structure as appears in open api examples:

    "quoteItem": [
        {
          "@type": "QuoteItem",
          "id": "1",
          "action": "add",
          "productOffering": {
            "@type": "ProductOfferingRef",
            "id": "<UID_FOR_MSB_BUNDLE>",
            "name": "Managed Security Box Bundle"
          },
          "quantity": 1,
          "quoteItemRelationship": [
            {
              "@type": "QuoteItemRelationship",
              "id": "2",
              "relationshipType": "bundles"
            },
            {
              "@type": "QuoteItemRelationship",
              "id": "3",
              "relationshipType": "bundles"
            }
          ]
        },
        {
          "@type": "QuoteItem",
          "id": "2",
          "action": "add",
          "productOffering": {
            "@type": "ProductOfferingRef",
            "id": "<UID_FOR_MSB>",
            "name": "Managed Security Box"
          }
        },
        {
          "@type": "QuoteItem",
          "id": "3",
          "action": "add",
          "productOffering": {
            "@type": "ProductOfferingRef",
            "id": "<UID_FOR_COMMITMENT>",
            "name": "Shipping"
          },
          "quantity": 1
        }
      ]

    2) Difference Between item.price and item.product.price in quote and product order

    We've noticed that both quoteItem and productOrderItem support placing price either directly on the item or under the nested product field.
    What's the semantic or functional difference between item.price and item.product.price in the context of TMF APIs? When should one be preferred over the other?


    3) Difference Between item.productOffering and item.product.productOffering in quote and product order

    Similarly, we see both productOffering on the item level and within the product object. Could you clarify the distinction between item.productOffering and item.product.productOffering?
    Are both required in certain cases, or is one merely a convenience reference? What's the best practice here?

    Many thanks in advance for any guidance you can offer. We appreciate the work that has gone into these APIs and just want to ensure we're applying them in the most compliant and future-proof way.

    Kind Regards,

    M.



    ------------------------------
    Martin Barnas
    T-Mobile Czech & Slovak Telekom, a.s.
    ------------------------------


  • 2.  RE: Clarifications on Bundling, Price Placement, and ProductOffering in Quote & Order APIs

    TM Forum Member
    Posted May 13, 2025 06:29

    hi,

    Flat vs Nested Structure

    It's seems to be common trait of some pre-sales/sales TMF apis to have either relationships or nested structure. TMF637 and 670 also use the relationship pattern.

    I don't know the guiding principle behind this approach. but typically:

    • For POST operations for instance, a cart, it makes sense to have a nested structure instead of the client orchestrating the different bundle components described in the relationship.
    • For GET operations, relationships are better:
      •  you only query and get what you need, if you need more, ask more. so the client need to orchestrate more API calls (for us, we wait for user intent, like click on the TV component in the UI, which will trigger a new API call with TMF637 for that product specifically.
        it is much more resource efficient (energy, CPU...) efficient, you have better response time as query less data. Payload are much smaller, the cognitive load for devs is much better.

    prices

    I don't recall the price fields you mention. Can you use these instead (extract from cart api)?:

    for product vs product offering

    • reference a Product Offering id if the product in the cart is a new sale, for a new instance of an offer in the product catalogue
    • reference a Product Id if the product in the cart is an existing product from the product Inventory. In that case, you're also required to add the product offering Id under it.

    the product configuration API has the same relationships and product id fields.

    there is a strong bond between the cart and the product configurator, so the cart needs to store all product-related ids.



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

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