For me, the request could be identical than yours:
ProductOfferingQualification:
Channel:
id: web
@type: productOfferingQualification
ProductOfferingQualificationItem:
action: add
ProductOffering:
id: 1
@type= ProductOfferingRef
and if you want to provide all information in the response, you could add some specialization and leveraging some polymorphism:
(sorry I drafted quickly some hope I did not miswritten attribute)
ProductOfferingQualification:
Channel:
id: web
@type: productOfferingQualification
ProductOfferingQualificationItem:
action: add
qualificationItemResult: alternate
unavailabbilityReason
code: 456
label: not available in this channel
ProductOffering:
id: 1
@type= ProductOfferingRef
alternateProduct
alternatProductOffering
@type= ProductOfferingRefWithChannel
id: 1
Channel:
id: store
id: telesale
This pattern will require you to specify in your swagger a ProductOfferingRefWithChannel classes and depending on the @type you use the standard class or the specialized one.
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------
Original Message:
Sent: Jul 15, 2021 05:10
From: Graeme Wilson
Subject: TMF679 Product Offering Qualification and per channel availability
Now I'm not so sure!
ProductOfferingQualification:
Channel: // set by the requester
ProductOfferingQualificationItem:
ProductOffering: // this is a ProductOfferingRef
I don't want to replace the ProductOfferingQualification.Channel property because that's set by the requester so it should be immutable. The Channel property that I was thinking of setting belongs on the ProductOfferingQualificationItem.ProductOffering but that's a ProductOfferingRef - so it doesn't have a channel property. In general this is pretty problematic anyway because POQ clients are going to need to dereference every single ProductOfferingRef in order to get the data they need to display to the customer - it would be very chatty. Is it acceptable to replace the ProductOfferingRef with an actual ProductOffering? I have seen this elsewhere in TMF APIs where you have a SomethingRefOrValue to indicate interchangeability.
------------------------------
Graeme Wilson
Zen Internet Ltd
Original Message:
Sent: Jul 15, 2021 04:35
From: Graeme Wilson
Subject: TMF679 Product Offering Qualification and per channel availability
Hi Jag,
thanks and I think I can see a solution here! The POQ API can return a product offering qualification item where the product offering that it contains has a channel property set to indicate whether the customer can buy in the current channel or needs to use an alternate channel. So the product offering would be marked as qualified and the channel property would indicate where the customer needs to get it from, if they can't get it in the current channel.
In TMF620 the ProductOffering has a Channel property which is an array of ChannelRef, but in TMF679 the ProductOfferingQualification has a Channel property which is a single ChannelRef - is that deliberate - it implies that a qualified product offering can only be qualified for one channel?
regards,
------------------------------
Graeme Wilson
Zen Internet Ltd
Original Message:
Sent: Jul 14, 2021 10:46
From: Sri Jagadish (Jag) Baddukonda
Subject: TMF679 Product Offering Qualification and per channel availability
Hi Graeme,
Based on your description, there are multiple actions with the need for more than one TMF Open API.
At a high level, the following sequence is the preferred approach
TMF 648 - Create Quote
TMF 645 - Service Qualification (Based on Installation Address and get the necessary params)
TMF 679 - Offer Qualification (Apply the channel and the result of 645)
Display the result.
It is better to have a message indicating the channel rather than "unavailable" in case the input channel does not match the channel configured in the Offer - channel relationship in the catalog.
Unavailable should be displayed only if 645 draws a blank
Or enhance the 679 which is an alternate approach
Hope this helps.
Regards,
------------------------------
Jag Baddukonda
CSGI
Original Message:
Sent: Jul 14, 2021 10:27
From: Graeme Wilson
Subject: TMF679 Product Offering Qualification and per channel availability
Thanks Jag and Jonathan. What we're doing is determining product offering qualification based on the channel AND the customer's installation address - so we can't determine qualification based on a channel attribute in the product catalogue. Effectively the qualified/unqualified decision is dynamic. My question is how we can return a product offering qualification item to the client that indicates that yes, the product offering is available to them but that the customer needs to contact us in a different channel to be able to obtain the offering? I'm thinking that we should return the product offering qualification item with a status of unqualified and with an eligibility unavailability reason code that indicates that a different channel needs to be used. Do you think that's reasonable?
------------------------------
Graeme Wilson
Zen Internet Ltd
Original Message:
Sent: Jul 14, 2021 09:41
From: Jonathan Goldberg
Subject: TMF679 Product Offering Qualification and per channel availability
Thanks Jag for this insight.
With that, we should recognize that the rules for product qualification are incompletely modeled at the catalog level (TMF620). So although I can run qualification check using TMF679, the basis for the qualification check cannot be fully authored at this time using the Open API model.
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
Original Message:
Sent: Jul 14, 2021 08:30
From: Sri Jagadish (Jag) Baddukonda
Subject: TMF679 Product Offering Qualification and per channel availability
Hi Greame,
To achieve this, the Channel - Product Offer relationship (available on certain channels) should be modelled in the Catalog.
The Channel should be one of the attributes that is passed in the API - 679, while fetching the Offers based on the Qualification criteria and the result would be Product Offers "qualified" for those channels.
Regards,
Jag
------------------------------
Jag Baddukonda
CSGI
Original Message:
Sent: Jul 13, 2021 11:18
From: Graeme Wilson
Subject: TMF679 Product Offering Qualification and per channel availability
Hi,
I have a question relating to how product offerings are shown as qualified or not on a per channel basis. When a customer is looking at our products there may be circumstances where we have a product that we can offer them but we can't let them self-serve - they need to speak with one of our team to be able to configure the product correctly. How would we represent that in a product offering qualification item? The product offering object has an isSellable property but that feels like it should be owned by the product catalogue and isn't a property that should be being set in product offering qualification. That leaves the qualificationItemResult but that is limited to qualified, unqualified and alternate. There isn't a way of capturing 'qualified, but not in this channel, only in channels x, y and z'. We thought about using alternateProductOfferingProposals but it isn't an alternate really - we want the customer to have the product but just want to direct them to a different channel. Has anyone had a similar situation and do you have suggestions for how we can model this?
regards,
Graeme.
------------------------------
Graeme Wilson
Zen Internet Ltd
------------------------------