Hello Iulia
1) for my perspective TMF679 is mainly designed for commercial eligibility because it works at product level. I will more recommend service qualification API for technical eligibility. From an implementation perspective this could trigger some challenge because need to mix 2 calls but usually these API supplier components are not the same (Commercial catalog vs feasability check component).
Adding max/min could be an interesting idea to improve the API - it is true that sometimes a given customer could not buy more than X occurences of same offer. A Change request should be trigger for this.
2) For me the price are not supposed to be retrieved by POQ. For consistence we use same ProductRefOrValue class for all product API so that why you have this productPrice.
Hope it helps
Ludovic
------------------------------
Ludovic Robert
Orange
My answer are my own & don't represent necessarily my company or the TMF
------------------------------
Original Message:
Sent: Mar 27, 2020 07:52
From: Iulia Pasca
Subject: TMF679 ProductOfferingQualification API
Hello,
I have a couple of questions regarding this API:
-> since this API is supposed to be used for evaluating the technical and commercial eligibility is there any intention to also return the cardinality (min, max) of the eligible product offerings? currently the only indication is the qualified/unqualified status at ProductOfferingQualificationItem level (qualificationItemResult)
-> is this API also supposed to return the prices for the product offerings in the given context? according to the Resource Model diagram prices should be returned only for existing products (which I assume are products from inventory or that were already added to the cart)
Have a great day,
Iulia
------------------------------
Iulia Pasca
IBM Corporation
------------------------------