Thanks Matthieu,
I would say yes, am agree with you. Specially about TMF620 should remain as dumb as possible, but, normally depending on business decisions, there are two kind of eligibility rules. First type are about rules like "some offers are defined for only customers with golden badge". Normally based on marketing decisions, they let other customers to see these offers, in order to encourage them to improve their account and get a golden badge! From my point of view these kind of rules can be handled using qualification API and referenced rules to catalogue as you rightly said.
In this case, for instance If customer selects this offer, qualification result would return unqualified and he/she can not buy that, but still it's available while browsing the catalogue (And normally number of such offers should not be too much (for example 10 percentage, otherwise it's giving a bad sense to customers).
And the second kind of rules are those which can (or is more efficient to) be used for filtration purpose. I mean, when i'm not eligible, then i should not see these offers while browsing the catalogue. For example let's say if i am a tourist customer, i should only see offers which are defined for me. I would say for this kind of offers, using rule is practically hard. Because API should evaluate each offer individually and if the number of offers in the catalogue are too much, then it's difficult to return a clean list of eligible offers in an acceptable response time. So i would say in this kind of cases, using marketSegment and filtering with proper parameters like GET .../productOffering?marketSegment.customerType=Tourist&&...marketSegment.gender=male&&marketSegment.age=28 and so on will work more efficiently.
------------------------------
Arash Zolfaghari
Tecnotree
------------------------------
Original Message:
Sent: Apr 17, 2023 08:53
From: Matthieu Hattab
Subject: Product and service condition
Arash,
I would avoid as much as possible using SID entities exposed by TMF 620 API to represent eligibility rules (or any rules for that matter)
- the TMF 620 resource model is very limited and static and companies have unlimited variations of business rules.
- the TMF 620 resource model cannot represent any degree of complexity. Try doing "if, then else" with 620!
Policy is the way forward and TMF620 should remain as dumb as possible and only provide a rule id and let another specialist do the job.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform
------------------------------
Original Message:
Sent: Apr 17, 2023 07:58
From: Arash Zolfaghari
Subject: Product and service condition
These kind of rules can be defined as MarketSegment. Based on SID definition MarketSegments can be simple or complex. For example, one MarketSegment may be consumer customers, one may be all states west of the Mississippi, and another may be all consumer customers who live in California, have a family income over $50,000 a year, and use the Internet regularly.
------------------------------
Arash Zolfaghari
Tecnotree
Original Message:
Sent: Apr 12, 2023 09:21
From: Myagaa Nm
Subject: Product and service condition
Let's say for postpaid plan, it has condition like customer must not under 18. If customer is under 18, he/she not allowed to get the plan. So, where will the conditions stored in tmforum's open api?
------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
Original Message:
Sent: Apr 12, 2023 04:26
From: Matthieu Hattab
Subject: Product and service condition
Hello,
the product catalogue, as exposed by TMF 620, contains information that can be seen as "condition". For instance, cardinality of bundle components, relationships (depends, concerns, exclude etc) between product specifications or between product offerings etc.
What conditions do you have in mind? Some examples could be helpful.
------------------------------
Kind regards,
Matthieu Hattab
Lyse Platform