Open APIs

 View Only

  • 1.  Product qualification APIs

    TM Forum Member
    Posted Sep 23, 2019 01:53
    Hi all,

    I have a question regarding product offering qualification API. I see that there are two cases for using it:
    1. New offers
    2. Existing offers
    For the second case, the offer will be come from Product inventory and sent to Product qualification API for finding the offers that complete the existing one.

    But can this be used to check if the customer is allowed to upgrade or change her/his offer?
    • If yes, does it need a new attribute like "isExistingProductChange" : false||true (similar to "provideAlternative": true) to differentiate this case from completing an existing product?
    • If no, should the logic be like the first case where a new offer is sent to API? but then how to handle restrictions related to offers?

    The reason behind asking this is for upgrade offer case, there may be some restrictions on how to upgrade (e.g. more than 6 months of using old offer) or services may not be cancelled during the upgrade (e.g. existing mobile roaming).

    ------------------------------
    Ahmad Samra
    ------------------------------


  • 2.  RE: Product qualification APIs

    TM Forum Member
    Posted Sep 24, 2019 17:28
    Hello Ahmad

    The API allows requester to specify a product identifier. A product identifier is a identifier of an existing  product in inventory ( an instance of a product offering or a product specification). So il you want to check that an existing product could be upgraded, for me you have to fill this product id and provide target configuration to be qualified. The presence of the product.id is for me covering implicitly  what you have in mind with the isExistingProductChange.

    Additionally in release 19 we add the action attribute. Thing will be then very explicit because for example with action add is for new offering qualification, change you request a change qualification, remove a termination qualification.

    Hope it helps
    Ludovic



    ------------------------------
    Ludovic Robert
    Orange
    ------------------------------

    Original Message


  • 3.  RE: Product qualification APIs

    TM Forum Member
    Posted Sep 29, 2019 16:20
    Hi Ahmad,

    productOfferingQualification is indeed also intended for implementing the business logic of what upgrades are allowed.

    For existing Products the product attribute must be provided so that the business logic can look up the product in the inventory.
    The provideAlternatives flag should be set to true for finding allowed upgrades or downgrades.
    Based of the startDate of the product and on of the terms of the product (ex. minimum commitment period) the business logic can determine which actions are permitted.

    Regards

    ------------------------------
    Koen Peeters
    Ciminko Luxembourg
    ------------------------------

    Original Message


  • 4.  RE: Product qualification APIs

    TM Forum Member
    Posted Sep 30, 2019 01:34
    Thank your Ludovic and Koen for your answers. 
    I was reading the updated document of Product qualification in the last couple of days. I think introducing the action attribute is a great help as it will ease the implementation of the business logic for each qualification case. And it will make it one of the most heavily used APIs whenever an interaction is triggered for a Party from any channel. But if that is the case, I have two questions:

    1. Can the API response be extended to include attributes related to prices/charges? The reason behind that is in case of upgrading or downgrading an existing product, the prices/charges may differ from customer to customer depending on the business logic/needs. For an example, if the customer is VIP, no charges are applicable. If the customer is a normal customer and her/his subscription is more than 3 years, installation charge is only applicable. If the customer is a new customer, all charges are applicable. So, in this sense, the qualification APIs will provide the qualified products for upgrade/downgrade case along with the applicable price/charge.
    2. Having the action attribute added to the qualification APIs and if extending the API response to have price/charge attributes is fine, can this API be used to handle all service requests' actions? For example, if a customer wants to suspend for some time or terminate her/his subscription based on the contract terms, it will provide whether it is qualified to do so based on the existing product and what charges the customer has to pay.


    ------------------------------
    Ahmad Samra
    Tecnotree
    ------------------------------

    Original Message