Open APIs

Hi TM Forum Experts,

I have few queries on tmf620 v5.0 updates related to ProductOffering and ProductOfferingPrice objects (w.r.t. v4.1.0)-

Fields:

1. priceAlteration- It appears that, "priceAlteration" entity is no longer defined in v5.0  POP. As a producer of tmf api v5.0, what should be the alternative to 'priceAlteration'in v5.0 ? 
   1. May be the fields of 'priceAlteration' be included to POPRef (like the GET response payload has percentage, priority etc) OR since 'priceAlteration' is optional attribute so it can still be part of POPRef as extension API (considering only mandatory fields affect the CTK). or probably any other suggestion ?
2. policy- As per the v5.0 spec, this seems to be a replacement of 'constraints' entity, there is no difference in the sub-resource fields as well so in high level can be considered that the 'constraint' is given more relevant name in v5.0 ?

Attributes:

• Mandatory Attributes [POST]- "lastUpdate": Could please help to understand the significance of marking 'lastUpdate' as mandatory field ? what should be the lastUpdate value when creating the POP ?

• Patchable Attributes [PATCH]- "priceType": "priceType" is not listed in the non-patchable attributes list, meaning POP can be modified from 'charge' to 'discount', should that use case be allowed ?

Thanks in advance !!

------------------------------
Vivek Raghuwanshi
Oracle Corporation
------------------------------

Hi,

According to the 620 API V5 documentation priceAlterations are now managed with popRelationship.
a personal feedback: There is some merit in moving priceAlteration into popRelationship but I hope it will be consistent accross APIs. For instance, the product Inventory TMF637 API V5 still uses "priceAlteration". 

The policy entity has existed in the Information framework (SID) for many years (ref GB922 - common). There is an API (TMF723).

on creating a resource, lastUpdated = created.

If the product manager mistakenly use 'discount' instead of 'charge', they should be allowed to update their POP to fix it.

The TMF APIs are templates, you can choose what to use and you're allowed to customise the API to suit your own need.

My 2 cents,

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 15, 2024 11:11
From: Vivek Raghuwanshi
Subject: TMF620 v5.0 Updates: PO and POP Objects Fields & API Attributes

Hi TM Forum Experts,

I have few queries on tmf620 v5.0 updates related to ProductOffering and ProductOfferingPrice objects (w.r.t. v4.1.0)-

Fields:

1. priceAlteration- It appears that, "priceAlteration" entity is no longer defined in v5.0  POP. As a producer of tmf api v5.0, what should be the alternative to 'priceAlteration'in v5.0 ? 
   1. May be the fields of 'priceAlteration' be included to POPRef (like the GET response payload has percentage, priority etc) OR since 'priceAlteration' is optional attribute so it can still be part of POPRef as extension API (considering only mandatory fields affect the CTK). or probably any other suggestion ?
2. policy- As per the v5.0 spec, this seems to be a replacement of 'constraints' entity, there is no difference in the sub-resource fields as well so in high level can be considered that the 'constraint' is given more relevant name in v5.0 ?

Attributes:

• Mandatory Attributes [POST]- "lastUpdate": Could please help to understand the significance of marking 'lastUpdate' as mandatory field ? what should be the lastUpdate value when creating the POP ?

• Patchable Attributes [PATCH]- "priceType": "priceType" is not listed in the non-patchable attributes list, meaning POP can be modified from 'charge' to 'discount', should that use case be allowed ?

Thanks in advance !!

------------------------------
Vivek Raghuwanshi
Oracle Corporation
------------------------------

pirceAlteration- yeah, it would be good if it is consistent across apis, and in order to be conformance to 5.0.0, perhaps it can still be used as extension.

policy- does that mean, policy and constraint both are different sub-resources and can be defined at the same time ? Or the 'policy' should be considered as a new sub resource.

lastUpdate- the real creation time can be set from business logic at server side. Since it is mandatory attribute, assuming that, it has be sent in request payload but, the time in request payload may not be the real time of creation.

lifecycleStatus- Similar to lastUpdate, the lifecycleStatus real time status can be set at server side or should the client be allowed to send  lifecyclestatus in payload.

Hi,

According to the 620 API V5 documentation priceAlterations are now managed with popRelationship.
a personal feedback: There is some merit in moving priceAlteration into popRelationship but I hope it will be consistent accross APIs. For instance, the product Inventory TMF637 API V5 still uses "priceAlteration". 

The policy entity has existed in the Information framework (SID) for many years (ref GB922 - common). There is an API (TMF723).

on creating a resource, lastUpdated = created.

If the product manager mistakenly use 'discount' instead of 'charge', they should be allowed to update their POP to fix it.

The TMF APIs are templates, you can choose what to use and you're allowed to customise the API to suit your own need.

My 2 cents,

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 15, 2024 11:11
From: Vivek Raghuwanshi
Subject: TMF620 v5.0 Updates: PO and POP Objects Fields & API Attributes

Hi TM Forum Experts,

I have few queries on tmf620 v5.0 updates related to ProductOffering and ProductOfferingPrice objects (w.r.t. v4.1.0)-

Fields:

1. priceAlteration- It appears that, "priceAlteration" entity is no longer defined in v5.0  POP. As a producer of tmf api v5.0, what should be the alternative to 'priceAlteration'in v5.0 ? 
   1. May be the fields of 'priceAlteration' be included to POPRef (like the GET response payload has percentage, priority etc) OR since 'priceAlteration' is optional attribute so it can still be part of POPRef as extension API (considering only mandatory fields affect the CTK). or probably any other suggestion ?
2. policy- As per the v5.0 spec, this seems to be a replacement of 'constraints' entity, there is no difference in the sub-resource fields as well so in high level can be considered that the 'constraint' is given more relevant name in v5.0 ?

Attributes:

• Mandatory Attributes [POST]- "lastUpdate": Could please help to understand the significance of marking 'lastUpdate' as mandatory field ? what should be the lastUpdate value when creating the POP ?

• Patchable Attributes [PATCH]- "priceType": "priceType" is not listed in the non-patchable attributes list, meaning POP can be modified from 'charge' to 'discount', should that use case be allowed ?

Thanks in advance !!

------------------------------
Vivek Raghuwanshi
Oracle Corporation
------------------------------

contraints should  be ignored. I think I read Jonathan saying this entity will disappear completely and replaced by Policy, which has been cleary defined in details in the SID.

pirceAlteration- yeah, it would be good if it is consistent across apis, and in order to be conformance to 5.0.0, perhaps it can still be used as extension.

policy- does that mean, policy and constraint both are different sub-resources and can be defined at the same time ? Or the 'policy' should be considered as a new sub resource.

lastUpdate- the real creation time can be set from business logic at server side. Since it is mandatory attribute, assuming that, it has be sent in request payload but, the time in request payload may not be the real time of creation.

lifecycleStatus- Similar to lastUpdate, the lifecycleStatus real time status can be set at server side or should the client be allowed to send  lifecyclestatus in payload.

Hi,

According to the 620 API V5 documentation priceAlterations are now managed with popRelationship.
a personal feedback: There is some merit in moving priceAlteration into popRelationship but I hope it will be consistent accross APIs. For instance, the product Inventory TMF637 API V5 still uses "priceAlteration". 

The policy entity has existed in the Information framework (SID) for many years (ref GB922 - common). There is an API (TMF723).

on creating a resource, lastUpdated = created.

If the product manager mistakenly use 'discount' instead of 'charge', they should be allowed to update their POP to fix it.

The TMF APIs are templates, you can choose what to use and you're allowed to customise the API to suit your own need.

My 2 cents,

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

Matthieu Hattab
Lyse Platform

Original Message:
Sent: May 15, 2024 11:11
From: Vivek Raghuwanshi
Subject: TMF620 v5.0 Updates: PO and POP Objects Fields & API Attributes

Hi TM Forum Experts,

I have few queries on tmf620 v5.0 updates related to ProductOffering and ProductOfferingPrice objects (w.r.t. v4.1.0)-

Fields:

1. priceAlteration- It appears that, "priceAlteration" entity is no longer defined in v5.0  POP. As a producer of tmf api v5.0, what should be the alternative to 'priceAlteration'in v5.0 ? 
   1. May be the fields of 'priceAlteration' be included to POPRef (like the GET response payload has percentage, priority etc) OR since 'priceAlteration' is optional attribute so it can still be part of POPRef as extension API (considering only mandatory fields affect the CTK). or probably any other suggestion ?
2. policy- As per the v5.0 spec, this seems to be a replacement of 'constraints' entity, there is no difference in the sub-resource fields as well so in high level can be considered that the 'constraint' is given more relevant name in v5.0 ?

Attributes:

• Mandatory Attributes [POST]- "lastUpdate": Could please help to understand the significance of marking 'lastUpdate' as mandatory field ? what should be the lastUpdate value when creating the POP ?

• Patchable Attributes [PATCH]- "priceType": "priceType" is not listed in the non-patchable attributes list, meaning POP can be modified from 'charge' to 'discount', should that use case be allowed ?

Thanks in advance !!

------------------------------
Vivek Raghuwanshi
Oracle Corporation
------------------------------