Open APIs

Hi Varun

Bear in mind that Product Order is simply a container for Order Items. The action that you want to take is encoded in each order item.

Presumably you would use a Modify action, and update the ProductTerm with the new contract end date.

Perhaps @Olivier Arnaud might want to expand?

Hope it helps

Hi Jonathan, Thanks for your response - This helps.

However, one query with respect to new contract end date, we can't see any contract end date attribute mentioned in ProductTerm or on Product resource in general.

How, is this expected to be realized and/work with renewals if it can be illustrated with a sample example?

Hi Varun

Bear in mind that Product Order is simply a container for Order Items. The action that you want to take is encoded in each order item.

Presumably you would use a Modify action, and update the ProductTerm with the new contract end date.

Perhaps @Olivier Arnaud might want to expand?

Hope it helps

we use an alternative solution to Jonathan and Olivier's suggestion of updating the product term end date:

• You have a history of the different product terms
• you only use the latest active product terms (as defined in your product catalogue)
• in our case, instantiating a new product term can also instantiate benefits. Our most used product term is the "12-month commitment" that customer can choose in exchange of a discount (also defined in TMF620).

we also have cases where renewal is no longer possible because the product offering is end of sale. 

Customers still "renew" by upgrading to a new offer (which will have its own product term) and terminate/update the current product instances in the inventory.

@Olivier Arnaud; @Jonathan Goldberg, are you involved in writing TMF622? The documentation shows 2 UC:

• Use case 1 (UC1): Acquisition
• Use case 2 (UC2): Modification

It seems all the JSON examples in the document only caters for UC1.
for UC2, I would have expected productOrderItem[] with "action": "modify",

Hi @Matthieu Hattab

thanks, yes I was involved on the v5 migration for this API. I create a JIRA to keep this idea of having examples of modification (and termination).

we use an alternative solution to Jonathan and Olivier's suggestion of updating the product term end date:

• You have a history of the different product terms
• you only use the latest active product terms (as defined in your product catalogue)
• in our case, instantiating a new product term can also instantiate benefits. Our most used product term is the "12-month commitment" that customer can choose in exchange of a discount (also defined in TMF620).

we also have cases where renewal is no longer possible because the product offering is end of sale. 

Customers still "renew" by upgrading to a new offer (which will have its own product term) and terminate/update the current product instances in the inventory.

@Olivier Arnaud; @Jonathan Goldberg, are you involved in writing TMF622? The documentation shows 2 UC:

• Use case 1 (UC1): Acquisition
• Use case 2 (UC2): Modification

It seems all the JSON examples in the document only caters for UC1.
for UC2, I would have expected productOrderItem[] with "action": "modify",

Thanks @Olivier Arnaud and @Matthieu Hattab - This approach looks cleaner - Create instance of ProductTerm with "validFor" attribute defining the start date and end date of ProductTerm. And, when the product is renewed, it leads to creation of a new instance of ProductTerm again with its "validFor" attribute defined.

But, on a closer look, we could observe that OrderTerm defined against ProductOrderItem resource doesn't have any attribute "validFor" defined. So, when a POST ProductOrder API request would be invoked, how will consuming system understand that it is request for renewal of Product? The request for renewal could be with same productTerm as previous one or a different one.

There could be variety of use cases -

UC 1: ProductTerm is still active but is nearing end Date as specified by validFor and customer wishes to renew the Product upfront even before the actual expiry

UC 2: ProductTerm is expired recently and customer wishes to renew the Product

Hi @Matthieu Hattab

thanks, yes I was involved on the v5 migration for this API. I create a JIRA to keep this idea of having examples of modification (and termination).

we use an alternative solution to Jonathan and Olivier's suggestion of updating the product term end date:

• You have a history of the different product terms
• you only use the latest active product terms (as defined in your product catalogue)
• in our case, instantiating a new product term can also instantiate benefits. Our most used product term is the "12-month commitment" that customer can choose in exchange of a discount (also defined in TMF620).

we also have cases where renewal is no longer possible because the product offering is end of sale. 

Customers still "renew" by upgrading to a new offer (which will have its own product term) and terminate/update the current product instances in the inventory.

@Olivier Arnaud; @Jonathan Goldberg, are you involved in writing TMF622? The documentation shows 2 UC:

• Use case 1 (UC1): Acquisition
• Use case 2 (UC2): Modification

It seems all the JSON examples in the document only caters for UC1.
for UC2, I would have expected productOrderItem[] with "action": "modify",