Open APIs

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

Hi Varun

This relationship can be for Product catalog itself, agreement, order, asset(product inventory).

For Product Order - TMF622: Relevant entities are:

ProductOrderItem : Bundle offer and child offer(s) , for each there will be one ProductOrderItem record.

OrderItemRelationship : Relationship between bundle and child products

OrderPrice ->price

(TMF page Reference : https://projects.tmforum.org/wiki/x/DTTVBg)

For Product Inventory - TMF637 :

The related entities are :

Product Entity : here relevant fields for Bundle or child product , there is isBundle field

ProductRelationship : Relationship between bundle and child products

ProductPrice : Product and price association.

(TMF Reference : https://projects.tmforum.org/wiki/x/LzTVBg) 

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

Hi Sarbari

Thanks for your answer.

You can certainly have product offering price (POP) at the bundle level, and thus have different pricing for different bundles.

But I think that Varun wants to attach multiple POPs to the simple product offering, and according to which bundle is being used select the relevant POP. This would be similar to the ProductSpecCharUse pattern, which limits characteristic values in the context of a specific product offering.

In short, we don't have this currently in the TMF620 model, and it needs discussion with the SID (information framework) team as well, since they have views on best-practice catalog modeling.

Hi Varun

This relationship can be for Product catalog itself, agreement, order, asset(product inventory).

For Product Order - TMF622: Relevant entities are:

ProductOrderItem : Bundle offer and child offer(s) , for each there will be one ProductOrderItem record.

OrderItemRelationship : Relationship between bundle and child products

OrderPrice ->price

(TMF page Reference : https://projects.tmforum.org/wiki/x/DTTVBg)

For Product Inventory - TMF637 :

The related entities are :

Product Entity : here relevant fields for Bundle or child product , there is isBundle field

ProductRelationship : Relationship between bundle and child products

ProductPrice : Product and price association.

(TMF Reference : https://projects.tmforum.org/wiki/x/LzTVBg) 

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

Thanks Jonathan for the response and clarifications.

Can you please help point to someone who can provide views from SID perspective on this just to ensure that we are not missing out on any best practice for catalog modelling?

Hi Sarbari

Thanks for your answer.

You can certainly have product offering price (POP) at the bundle level, and thus have different pricing for different bundles.

But I think that Varun wants to attach multiple POPs to the simple product offering, and according to which bundle is being used select the relevant POP. This would be similar to the ProductSpecCharUse pattern, which limits characteristic values in the context of a specific product offering.

In short, we don't have this currently in the TMF620 model, and it needs discussion with the SID (information framework) team as well, since they have views on best-practice catalog modeling.

Hi Varun

This relationship can be for Product catalog itself, agreement, order, asset(product inventory).

For Product Order - TMF622: Relevant entities are:

ProductOrderItem : Bundle offer and child offer(s) , for each there will be one ProductOrderItem record.

OrderItemRelationship : Relationship between bundle and child products

OrderPrice ->price

(TMF page Reference : https://projects.tmforum.org/wiki/x/DTTVBg)

For Product Inventory - TMF637 :

The related entities are :

Product Entity : here relevant fields for Bundle or child product , there is isBundle field

ProductRelationship : Relationship between bundle and child products

ProductPrice : Product and price association.

(TMF Reference : https://projects.tmforum.org/wiki/x/LzTVBg) 

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

Try @Kevin Scaggs or @Cecile Ludwichowski

------------------------------
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: Jan 25, 2024 08:07
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Thanks Jonathan for the response and clarifications.

Can you please help point to someone who can provide views from SID perspective on this just to ensure that we are not missing out on any best practice for catalog modelling?

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Jan 24, 2024 11:38
From: Jonathan Goldberg
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi Sarbari

Thanks for your answer.

You can certainly have product offering price (POP) at the bundle level, and thus have different pricing for different bundles.

But I think that Varun wants to attach multiple POPs to the simple product offering, and according to which bundle is being used select the relevant POP. This would be similar to the ProductSpecCharUse pattern, which limits characteristic values in the context of a specific product offering.

In short, we don't have this currently in the TMF620 model, and it needs discussion with the SID (information framework) team as well, since they have views on best-practice catalog modeling.

------------------------------
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: Jan 24, 2024 07:04
From: Sarbari Saha
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi Varun

This relationship can be for Product catalog itself, agreement, order, asset(product inventory).

For Product Order - TMF622: Relevant entities are:

ProductOrderItem : Bundle offer and child offer(s) , for each there will be one ProductOrderItem record.

OrderItemRelationship : Relationship between bundle and child products

OrderPrice ->price

(TMF page Reference : https://projects.tmforum.org/wiki/x/DTTVBg)

For Product Inventory - TMF637 :

The related entities are :

Product Entity : here relevant fields for Bundle or child product , there is isBundle field

ProductRelationship : Relationship between bundle and child products

ProductPrice : Product and price association.

(TMF Reference : https://projects.tmforum.org/wiki/x/LzTVBg) 

------------------------------
Sarbari Saha
Infosys

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

Thanks @Matthieu Hattab for the response.

Hi @Jonathan Goldberg: Seems like Policy rules is the way recommended by SID to address such use cases. Your views? And, whether its supported or planned to be supported in Open APIs?

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Jan 31, 2024 13:04
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

As stated in my suggestion, I elaborated my suggestion specifically with TMF720 V5 API as it's the first version that supports Policy ABE.

Thanks @Matthieu Hattab for the response.

Hi @Jonathan Goldberg: Seems like Policy rules is the way recommended by SID to address such use cases. Your views? And, whether its supported or planned to be supported in Open APIs?

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

Hi @Matthieu Hattab: TMF 720 talks about Digital Identity Management. I believe you are referring to TMF 620 API V5 here which has PolicyRef as a resource in ProductOffering and ProductOfferingPrice resource models.

But, the API still doesn't seem to detail out Policy resource as such and how it defines overriding the prices of component product offerings in context of the bundle.

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Feb 12, 2024 07:41
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

As stated in my suggestion, I elaborated my suggestion specifically with TMF720 V5 API as it's the first version that supports Policy ABE.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 06, 2024 15:13
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Thanks @Matthieu Hattab for the response.

Hi @Jonathan Goldberg: Seems like Policy rules is the way recommended by SID to address such use cases. Your views? And, whether its supported or planned to be supported in Open APIs?

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Jan 31, 2024 13:04
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

Yes that is correct and that's the intended purpose.
Your pricing engine reads the product definition with TMF620, gets the policy Id associated with the POP and then use a policy engine (aka BRMS) to compute the correct price.
You were recommended to read the suggested GB922 - Product document. It has examples of pricing based on policy. I highly suggest you do.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 12, 2024 22:21
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi @Matthieu Hattab: TMF 720 talks about Digital Identity Management. I believe you are referring to TMF 620 API V5 here which has PolicyRef as a resource in ProductOffering and ProductOfferingPrice resource models.

But, the API still doesn't seem to detail out Policy resource as such and how it defines overriding the prices of component product offerings in context of the bundle.

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Feb 12, 2024 07:41
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

As stated in my suggestion, I elaborated my suggestion specifically with TMF720 V5 API as it's the first version that supports Policy ABE.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 06, 2024 15:13
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Thanks @Matthieu Hattab for the response.

Hi @Jonathan Goldberg: Seems like Policy rules is the way recommended by SID to address such use cases. Your views? And, whether its supported or planned to be supported in Open APIs?

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Jan 31, 2024 13:04
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

Hi @Matthieu Hattab: Yes, we did go through GB922 - Product document. Also, as per what we understand that when you say a Policy engine you are referring to this computation of price being managed in an external system with details of price computation not being Open API compliant. Please confirm.

Also, when we went through the GB 922 document, we could find a whole Product Price Rule model for which we couldn't find a full map back in TMF 620 Open API.

Also, couldn't find any real example for this particular use case changing price for a component Product offering in context of bundle in GB922.

As per what @Jonathan Goldberg suggested using a pattern similar to the ProductSpecCharUse pattern could be another option if we were to introduce this in the Open API model.

Need opinions/suggestions from TMF SID and Open API teams responsible for GB 922 and TMF 620 respectively.

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Feb 13, 2024 05:02
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Yes that is correct and that's the intended purpose.
Your pricing engine reads the product definition with TMF620, gets the policy Id associated with the POP and then use a policy engine (aka BRMS) to compute the correct price.
You were recommended to read the suggested GB922 - Product document. It has examples of pricing based on policy. I highly suggest you do.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 12, 2024 22:21
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi @Matthieu Hattab: TMF 720 talks about Digital Identity Management. I believe you are referring to TMF 620 API V5 here which has PolicyRef as a resource in ProductOffering and ProductOfferingPrice resource models.

But, the API still doesn't seem to detail out Policy resource as such and how it defines overriding the prices of component product offerings in context of the bundle.

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Feb 12, 2024 07:41
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

As stated in my suggestion, I elaborated my suggestion specifically with TMF720 V5 API as it's the first version that supports Policy ABE.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 06, 2024 15:13
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Thanks @Matthieu Hattab for the response.

Hi @Jonathan Goldberg: Seems like Policy rules is the way recommended by SID to address such use cases. Your views? And, whether its supported or planned to be supported in Open APIs?

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Jan 31, 2024 13:04
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------

the policy component, which manages policies (design and runtime) is a separate component.
DROOLS is a well known open source policy engine and I heard one CSP that already uses it.

It is true that GB922 doens't have all possible scenarios. They are so many of them!

Your next step is to understand how the policy data model works and how you can use it. Consider searching the TMF communities on policy, it was already discussed before.

If you only need opinions/suggestions from TMF SID and Open API teams responsible, I suggest you contact your TMF account manager and they can arrange for a workshop with relevant people. We've done it several times and it's part of your TMF subscription.

EDIT:
@Varun Pandhi

Go to this page, you will see powerpoint and word files that has information on policy and prices (you need to be a member of the API project to see this page)

as for using "ProductSpecCharUse", I think you meant "prodSpecCharValueUse" ("ProductSpecCharUse" does not exist in TMF620).
 yes, it can work too. We actually used it ourselves!
but I don't like this design because it's not what productspec are meant to represent.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 13, 2024 06:38
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi @Matthieu Hattab: Yes, we did go through GB922 - Product document. Also, as per what we understand that when you say a Policy engine you are referring to this computation of price being managed in an external system with details of price computation not being Open API compliant. Please confirm.

Also, when we went through the GB 922 document, we could find a whole Product Price Rule model for which we couldn't find a full map back in TMF 620 Open API.

Also, couldn't find any real example for this particular use case changing price for a component Product offering in context of bundle in GB922.

As per what @Jonathan Goldberg suggested using a pattern similar to the ProductSpecCharUse pattern could be another option if we were to introduce this in the Open API model.

Need opinions/suggestions from TMF SID and Open API teams responsible for GB 922 and TMF 620 respectively.

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Feb 13, 2024 05:02
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Yes that is correct and that's the intended purpose.
Your pricing engine reads the product definition with TMF620, gets the policy Id associated with the POP and then use a policy engine (aka BRMS) to compute the correct price.
You were recommended to read the suggested GB922 - Product document. It has examples of pricing based on policy. I highly suggest you do.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 12, 2024 22:21
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi @Matthieu Hattab: TMF 720 talks about Digital Identity Management. I believe you are referring to TMF 620 API V5 here which has PolicyRef as a resource in ProductOffering and ProductOfferingPrice resource models.

But, the API still doesn't seem to detail out Policy resource as such and how it defines overriding the prices of component product offerings in context of the bundle.

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Feb 12, 2024 07:41
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

As stated in my suggestion, I elaborated my suggestion specifically with TMF720 V5 API as it's the first version that supports Policy ABE.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Feb 06, 2024 15:13
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Thanks @Matthieu Hattab for the response.

Hi @Jonathan Goldberg: Seems like Policy rules is the way recommended by SID to address such use cases. Your views? And, whether its supported or planned to be supported in Open APIs?

------------------------------
Varun Pandhi
Infosys

Original Message:
Sent: Jan 31, 2024 13:04
From: Matthieu Hattab
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hello,

You have a few options here to achieve your requirement (some of them are probably explained in GB922 - Product).
since we now have API V5, I'm gonna use that version to leverage the new price policy entity.

for argument's sake, I will assume that PO 1, 2 and 3 are isSellable=Y but PO 4 and 5 are isSellable=N

• Policy 1 describes that POP €80 overrides POP €100 if PO 3 is sold in the context of PO 1
• Policy 2 describes that POP €90 overrides POP €100 if PO 3 is sold in the context of PO 2

that's what we commonly called BOM Pricing or component-based pricing. the price of the bundled PO (= the component) is overriden by another price according to the policy.

How does it look like for the end-user?
Engagement Management will display these 3 product offerings:
PO 1 -> Starting at €80 (it's starting at because the final price will depend of the optional selection of PO 4, which would increase the total price for the bundle)

PO 2-> Starting at €90

PO 3 -> €100

the "pricing Engine" (TMF calls it "product Configurator" TMFC027) will calculate the €80 price by rolling up all the prices of POs that exist in the bundle if the cardinality is min 1.

If customer opens the product configurator for PO 1, they will see that PO 3 is priced at €80 thanks to the €80 price alteration that overrides the normal price of €100. the Policy could be a price matrix where conditions are set.
I implemented this exact solution many times decades ago in the manufacturing industry (HP, IBM Ricoh...) for configurable machines (e.g. CPU abc costs  €3000 when bought with server 1 but  €2500 when bought with server 2)

There are other modelling options (constraints, POPrelationship. Maybe even using characteristics, which I wouldn't recommend) , where you can specify a relationshipType and role. However POPrelationship alone is not enough, you need a relationship to the bundles (PO 1 or PO 2) so the pricing engine knows what to do.
worse case scenario, if your pricing engine is really dumb, you could even duplicate PO 3 (PO 3a and PO 3b) as long as both PO3a and b use the same product spec.
lastly you could also differenciate the prices with 2 discounts that are, again, dynamically instanciated based on which bundle is contextualised.

I do recommend reading GB922 - Product, though, Cécile wrote most of the examples :-)

My 2 cents.

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: Jan 23, 2024 17:02
From: Varun Pandhi
Subject: Support for Different prices of same bundledProductOfferings in context of different Product Offerings

Hi all,

How does TMF Open API support defining different prices for a bundledProductOffering in context of different product offerings (IsSellable = true, IsBundle = true)?

Sample depiction as below:

• BPO 2 when sold as part of PO 1 has POP P1
• BPO 2 when sold as part of PO 2 has POP P2.

Please suggest.

------------------------------
Varun Pandhi
Infosys
------------------------------