Open APIs

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

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.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

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?

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.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

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?

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.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

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.

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?

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.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

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.

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?

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.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

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

Original Message:
Sent: Apr 11, 2023 07:04
From: Myagaa Nm
Subject: Product and service condition

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

------------------------------
Myagaa Nm
MOBICOM CORPORATION LLC
------------------------------

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

Hi Myagaa,
in version 5 of TMF620 API this use-case will be realized using the Policy entity. A product offering will get a list of PolicyRefs.
You will obtain policy details using TMF723 API (still under development). Policies are ECA rules (on event if criteria are met perform an action).

As Bozidar wrote, TMF679 then computes policies in a given context (quote, cart, order) taking into account customer details, channel, sales rep, order/quote/cart content, existing inventory etc. In case you specify you need unqualified results when invoking the TMF679, the unavailability reason will be returned as EligibilityUnavailabilityReason.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

Hi Bostjan,
Thank you for your teply. When will tmf620 v5.0 be released?

Hi Myagaa,
in version 5 of TMF620 API this use-case will be realized using the Policy entity. A product offering will get a list of PolicyRefs.
You will obtain policy details using TMF723 API (still under development). Policies are ECA rules (on event if criteria are met perform an action).

As Bozidar wrote, TMF679 then computes policies in a given context (quote, cart, order) taking into account customer details, channel, sales rep, order/quote/cart content, existing inventory etc. In case you specify you need unqualified results when invoking the TMF679, the unavailability reason will be returned as EligibilityUnavailabilityReason.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

I believe the plan is to release v5 after Vienna SpecJam in June 2023. But it's not 100%, though.

Hi Bostjan,
Thank you for your teply. When will tmf620 v5.0 be released?

Hi Myagaa,
in version 5 of TMF620 API this use-case will be realized using the Policy entity. A product offering will get a list of PolicyRefs.
You will obtain policy details using TMF723 API (still under development). Policies are ECA rules (on event if criteria are met perform an action).

As Bozidar wrote, TMF679 then computes policies in a given context (quote, cart, order) taking into account customer details, channel, sales rep, order/quote/cart content, existing inventory etc. In case you specify you need unqualified results when invoking the TMF679, the unavailability reason will be returned as EligibilityUnavailabilityReason.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?

Thank you who replied for the question.

What I understood about offer, product, cfs and rfs is that when an offer is chosen by customer, product catalog and service catalog point what services will be activated.
I think product catalog also should store conditions to activate the offer. But characterstics are not enough to express the conditions. So where should the conditions are stored? In product catalog or in another system?