Open APIs

  • 1.  How to return costs in TMF645?

    TM Forum Member
    Posted Nov 02, 2021 10:31
    We have a requirement to return costs for various options as part of service qualification API call 645. This means we need to add the resource for cost in the 645 resource model?
    What is a recommended extension pattern ?
    There is no cost associated with the Service in the SID as far as I can tell.

    Regards

    Milind

    ------------------------------
    Milind Bhagwat
    BT Group plc
    ------------------------------


  • 2.  RE: How to return costs in TMF645?

    TM Forum Member
    Posted Nov 03, 2021 02:02

    Hi Milind,

    I believe I have seen Product Spec costs in SID (model is not at my fingertips) but don't recall same for service and not sure if it was associated with resource either. 

    My guess is that "money" is a concern of the Product domain. 

    Are you trying to support a use case for qualifying based on service costs (vs pricing to customer)? 



    ------------------------------
    Greg Herringer
    IBM Corporation
    ------------------------------



  • 3.  RE: How to return costs in TMF645?

    TM Forum Member
    Posted Nov 03, 2021 02:29
    Hi
    Colleagues from Telstra ( @Varun Nair @Abdul Majid Hussain​​ ) were working on an API that represents costs.
    I'm not sure what the status is, maybe they can enlighten. I'm sure that more interest from the community will help make a case for such an API.

    ------------------------------
    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.
    ------------------------------



  • 4.  RE: How to return costs in TMF645?

    TM Forum Member
    Posted Nov 03, 2021 04:38
    Hi Jonathan

    I was involved in the initial work with Telstra on the service cost API requirements. However our requirements are different where we have a number of service delivery options with cost that we want to maintain at the CFS level and then feed that to the product layer. We are thinking of APIs like 645 and 633 as candidates for extension with service cost information.

    My view was that we should model service cost similar to product cost with the structure of the cost object similar to the price object.

    Regards

    Milind

    ------------------------------
    Milind Bhagwat
    BT Group plc
    ------------------------------



  • 5.  RE: How to return costs in TMF645?

    TM Forum Member
    Posted Nov 03, 2021 04:35
    Hi Greg

    Yes, the requirement is to return a number of options for service delivery with associated costs.

    Regards

    Milind

    ------------------------------
    Milind Bhagwat
    BT Group plc
    ------------------------------



  • 6.  RE: How to return costs in TMF645?

    Posted Nov 04, 2021 10:08
    Edited by SriJagadish (Jag) Baddukonda Nov 04, 2021 11:35
    If we extrapolate this "requirement", the API TMF645 should not return the cost. It should only return the Service feasibility results. The results should be applied to the Order configuration / Shopping cart and evaluated against the catalog rules (for configuration and pricing).
    Based on the attributes in the response of 645, the above action i.e. pricing and configuration evaluation will price the cart correctly.

    If you have the price being returned as part of 645 for whatever reason, then in those cases the cart evaluation & pricing should not happen and implementing both will result in an incomplete / non eligible Order configuration / cart configuration.
    It is good to follow this Architectural principle even for OffNet scenarios.

    ------------------------------
    Jag Baddukonda
    CSG
    ------------------------------



  • 7.  RE: How to return costs in TMF645?

    TM Forum Member
    Posted 30 days ago
    Hi all,

    We have adapted a number of API to have a "cost" model similar to the "price" model used for product and productOffering.
    For Resource related API's and for Work related API's this works quite nicely.
    For Service related API's my experience is that this is less suitable as you will quickly end up doing things like aggregating costs of underlying Resources and Work together with a deprecations for your network over the services. That brings all sorts of issues such as diminishing cost when you have more services on your network or even sudden drops in costs when certain equipement is completely depreciated.

    We have abonded using this for services and only use it for Resources and Work. For Services it seems more appropriate to keep costs in general ledger.

    Regards

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