Original Message:
Sent: May 18, 2024 15:44
From: Varun Pandhi
Subject: Renewal Product Order support in TMF 622
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
------------------------------
Varun Pandhi
Infosys
Original Message:
Sent: May 16, 2024 10:28
From: olivier arnaud
Subject: Renewal Product Order support in TMF 622
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).
------------------------------
olivier arnaud
Orange
Original Message:
Sent: May 16, 2024 09:14
From: Matthieu Hattab
Subject: Renewal Product Order support in TMF 622
we use an alternative solution to Jonathan and Olivier's suggestion of updating the product term end date:
Instead of modifying the existing term in our product inventory, we will let the current product term expire naturally and create a new term upon renewal. This approach offers several advantages:
- 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"
,
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: May 13, 2024 04:29
From: Varun Pandhi
Subject: Renewal Product Order support in TMF 622
Hi all,
We understand that TMF 622 Product Order Management API is the common API used to support different order types for a typical Telecom operator. These different order types could be New Provide, Change, Cancel Product, Renewal etc.
As per general understanding, renewal order would refer to customer requesting to renew the contract for his/her already bought products as the product nears end of contract term.
While looking at user guide for TMF 622 Product Order Management API, we couldn't decipher how would a renewal order look like where we want to extend the End date of Product. And, typically, how would an application distinguish this type of order from other different order types (like New Provide, Change, Cancel Product etc.)?
On a side note, currently there is no attribute similar to ExpirationDate on Product to hold the date when product will expire.
Can anyone please help here, possibly with an example?
------------------------------
Varun Pandhi
Infosys
------------------------------