Open APIs

------------------------------
Chandan Kumar Soud
conology
------------------------------

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

Hi Jonathan,

I assumed for the situation you mentioned we are supposed to use the productRelationship attribute. If that is a wrong assumption, then what would be the use case for using productRelationship?

Best regards,

Chandan

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

Matthieu

Let me clarify, using the example for voicemail in my previous post. Let's assume (for the purposes of argument only) that:

• The voicemail is identical for mobile and VoIP (in terms of underlying network implementation)
• When a customer buys mobile or VoIP she will automatically get voicemail
• There is no separate price/charge for voicemail

In this situation, we can understand that voicemail will be modeled as a distinct product specification, and will be included as a direct child of the product specifications for both mobile and VoIP. There is no reflection at offering/price level of this voice mail.

This is what I meant when I said "sold indivisibly". When the VoIP or mobile spec is instantiated to the order/inventory as a Product, the voice mail will be instantiated as a sub-Product.

Of course if the telco business practice is to charge separately for voice mail, or to make it optional, the model would be different, there would be a bundling offering containing the main mobile offering and a separate offering for voice mail.

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

If above is the case, than can we say that above is a product offering and sub product is the other non sellable products such as Voice Service product, SMS Service product, Data Service product?

Matthieu

Let me clarify, using the example for voicemail in my previous post. Let's assume (for the purposes of argument only) that:

• The voicemail is identical for mobile and VoIP (in terms of underlying network implementation)
• When a customer buys mobile or VoIP she will automatically get voicemail
• There is no separate price/charge for voicemail

In this situation, we can understand that voicemail will be modeled as a distinct product specification, and will be included as a direct child of the product specifications for both mobile and VoIP. There is no reflection at offering/price level of this voice mail.

This is what I meant when I said "sold indivisibly". When the VoIP or mobile spec is instantiated to the order/inventory as a Product, the voice mail will be instantiated as a sub-Product.

Of course if the telco business practice is to charge separately for voice mail, or to make it optional, the model would be different, there would be a bundling offering containing the main mobile offering and a separate offering for voice mail.

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

Not sure what you mean "above" in "If above is the case".

Anyway I strongly advise you not to mix the terms Product and Service. In TM Forum vocabulary (SID, Open API, ODA, etc.) these are two different entities with different meanings. Yes, I know that the term Service is used informally in terms of what customers can buy, but this is very confusing.

If above is the case, than can we say that above is a product offering and sub product is the other non sellable products such as Voice Service product, SMS Service product, Data Service product?

Matthieu

Let me clarify, using the example for voicemail in my previous post. Let's assume (for the purposes of argument only) that:

• The voicemail is identical for mobile and VoIP (in terms of underlying network implementation)
• When a customer buys mobile or VoIP she will automatically get voicemail
• There is no separate price/charge for voicemail

In this situation, we can understand that voicemail will be modeled as a distinct product specification, and will be included as a direct child of the product specifications for both mobile and VoIP. There is no reflection at offering/price level of this voice mail.

This is what I meant when I said "sold indivisibly". When the VoIP or mobile spec is instantiated to the order/inventory as a Product, the voice mail will be instantiated as a sub-Product.

Of course if the telco business practice is to charge separately for voice mail, or to make it optional, the model would be different, there would be a bundling offering containing the main mobile offering and a separate offering for voice mail.

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

Ok, what i am asking is you mentioned in above thread a "main" mobile offering and a separate offering, now to identify that this is a main offering mandatory for customer while buying a connection and a secondary product offering which is optional for customer to buy, which are the tags in product offering API(TMF 620) and in ProductInventory API(TMF 637) which we can use to identify such offerings.

Not sure what you mean "above" in "If above is the case".

Anyway I strongly advise you not to mix the terms Product and Service. In TM Forum vocabulary (SID, Open API, ODA, etc.) these are two different entities with different meanings. Yes, I know that the term Service is used informally in terms of what customers can buy, but this is very confusing.

If above is the case, than can we say that above is a product offering and sub product is the other non sellable products such as Voice Service product, SMS Service product, Data Service product?

Matthieu

Let me clarify, using the example for voicemail in my previous post. Let's assume (for the purposes of argument only) that:

• The voicemail is identical for mobile and VoIP (in terms of underlying network implementation)
• When a customer buys mobile or VoIP she will automatically get voicemail
• There is no separate price/charge for voicemail

In this situation, we can understand that voicemail will be modeled as a distinct product specification, and will be included as a direct child of the product specifications for both mobile and VoIP. There is no reflection at offering/price level of this voice mail.

This is what I meant when I said "sold indivisibly". When the VoIP or mobile spec is instantiated to the order/inventory as a Product, the voice mail will be instantiated as a sub-Product.

Of course if the telco business practice is to charge separately for voice mail, or to make it optional, the model would be different, there would be a bundling offering containing the main mobile offering and a separate offering for voice mail.

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

If above is the case, than can we say that above is a product offering and sub product is the other non sellable products such as Voice Service product, SMS Service product, Data Service product?

Matthieu

Let me clarify, using the example for voicemail in my previous post. Let's assume (for the purposes of argument only) that:

• The voicemail is identical for mobile and VoIP (in terms of underlying network implementation)
• When a customer buys mobile or VoIP she will automatically get voicemail
• There is no separate price/charge for voicemail

In this situation, we can understand that voicemail will be modeled as a distinct product specification, and will be included as a direct child of the product specifications for both mobile and VoIP. There is no reflection at offering/price level of this voice mail.

This is what I meant when I said "sold indivisibly". When the VoIP or mobile spec is instantiated to the order/inventory as a Product, the voice mail will be instantiated as a sub-Product.

Of course if the telco business practice is to charge separately for voice mail, or to make it optional, the model would be different, there would be a bundling offering containing the main mobile offering and a separate offering for voice mail.

This recursion allows you to build a complex product that has multiple subproducts, which are nevertheless sold indivisibly. An example might be a mobile voice product with a mandatory voice mail. You might consider modeling the voice mail as a separate product so that it is clear to the customer that she is getting a voice mail. This would originate in the Product Catalog (TMF620) where you would have a structure of ProductSpecification.

There is no need to use this capability if your business doesn't require it.

------------------------------
Chandan Kumar Soud
conology
------------------------------

------------------------------
Chandan Kumar Soud
conology
------------------------------