and I would also ignore versioning, can't see any purpose to have version on POP entity. If you want to change the discount %, just create a new POP and expire the previous discount (you can reactivate it later if you need to)
Original Message:
Sent: Jan 23, 2025 04:13
From: Matthieu Hattab
Subject: Making use of SID entities to implement discounts
I recommend ignoring status fields and relying solely on dates to manage the POP lifecycle. We once had an ecom system that only used status fields and it led to the same poor experience you quoted: wake up at midnight to manually activate or deactivate prices.
But we also had a CRM that linked status and dates, each status had its own start and end date, which was quite useful.
That said, you can set up a batch process to automate status changes, provided you also have dates on the POP to control the batch job effectively.
at API level, you can also set the status dynamically, based on the dates. you would only have 2 status, though.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Tele AS
Original Message:
Sent: Jan 22, 2025 16:35
From: MMH HH
Subject: Making use of SID entities to implement discounts
Another way, I'm thinking we can do this is, _not_ to use POPrelationship but update the POP in the PO object itself. So, the PO object will have 2 POPs.
I'm showing the picture below to show entities, and some of their important attributes (version, lifecycleStatus, validFor). Could you please correct me if I'm wrong and answer few of questions I posed?
Note the lifecycleStatus, validFor attribute values. Are these correct?
Also, I don't seem to find a way to set the values for them properly when I want to introduce them beforehand (e.g. I don't want to do the changes at the exact time when my discount should become active, i.e. 31/01/2025 midnight). Is there a way to say 'update lifecycleStatus to "Launched" on 1/2/2025'.
------------------------------
MMH HH
Vodafone UK Ltd
Original Message:
Sent: Jan 22, 2025 13:21
From: MMH HH
Subject: Making use of SID entities to implement discounts
Thanks for the response, Matthieu. I've seen this and trying to get my head around actually implementing this.
* Create a plan POP (for monthly recurring price of the plan) - "Unlimited Max Monthly Recurring Charge v1" (£10 per month)
* with infinite validFor
* Create a plan PO, "Unlimited Max", with the price/charge "Unlimited Max Monthly Recurring Charge v1"
* with infinite 'validFor'
* Create a discount POP - "£5 off monthly recurring charge" (£5 per month)
* with infinite 'validFor'
* with applicationDuration '6 months'
* Update discount POP with the plan POP - "Unlimited Max Monthly Recurring Charge v2" ---- (bump the version as we are updating the entity)
* (popRelationship "Unlimited Max Monthly Recurring Charge v2" -> discountedBy -> "£5 off monthly recurring charge" with validFor {01.02.2025, 01.03.2025})
* what's the lifecycle status and validFor for "Unlimited Max Monthly Recurring Charge v1"?
* what's the lifecyclestatus and validFor for "Unlimited Max Monthly Recurring Charge v2"?
* Update PO to use this new POP version - PO1v2
* what's the lifecycle status and validFor for "Unlimited Max" v1?
* what's the lifecycle status and validFor for "Unlimited Max" v2?
I am not able to appreciate the value of 'validFor' if it's applicable for the entire lifecycle of the entity. We want to say 'Launched' during some period but as per my understanding validFor is for the entire lifecycle _not_ just the Launched status.
One more thing - I don't see much use of 'version' if we have to update the dependent entities anyway. It's not too different than creating a new object.
Please let me know if I'm missing something.
------------------------------
MMH HH
Vodafone UK Ltd
Original Message:
Sent: Jan 22, 2025 08:00
From: Matthieu Hattab
Subject: Making use of SID entities to implement discounts
hi,
You will find all answers to this question in GB922 - Product Guide, I think there is even an example exactly like yours, or close enough.
do keep in mind a discount, a price whatever its nature (recurring, usage...), a tax are all represented by the "product Offering Price" root class.
Then you create sub-classes to represent discount, markup etc.
This is the diagram I always use and it explains everything:
Source: GB922 - Product Figure Pr.13 - Complete Product Offer Price Model
TMF APIs mostly follow the same pattern.
My 2 cent discount
PS: this the API community. We have the ODA community to ask and answer SID questions.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
Original Message:
Sent: Jan 17, 2025 07:26
From: MMH HH
Subject: Making use of SID entities to implement discounts
Hi,
The question I'm asking might be very basic; please bear with me. I would like to understand how things should work in the following scenario.
Imagine today is 17th Jan. There is a pay monthly mobile plan, "Unlimited Max" that is currently £10 recurring charge a month. I want to introduce "6 months half price" discount from 1st Feb to 1st Mar. So any customer who buys this plan between 1st Feb to 1st Mar will have to pay £5 per month for the initial 6 months. After that they will start paying £10 per month. Any customer who buys this plan outside this period (1st Feb to 1st Mar), will pay £10 per month.
I want to implement this discounting using SID entities. Can someone please explain the state of ProductOffering, ProductOfferingPrice (and any other entities) required to accomplish the same (how will they look like before the discount is effective, during the discount and after the discount has expired)?
------------------------------
MMH HH
Vodafone UK Ltd
------------------------------