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