Open APIs

 View Only
  • 1.  What is a Usage to be considered?

    TM Forum Member
    Posted Nov 10, 2020 09:43
    Dear colleagues,

    I am in the process of mapping our business objects to the entities contained in the open API TMF635 "Usage Management" and I have trouble understanding how to incorporate recurring fees into the data model. I understand Usage is "An occurrence of employing a Product, Service, or Resource for its intended purpose, which is of interest to the business and can have charges applied to it.". As such the usage should also represent a recurring fee created by our rating engine on a recurring basis. In that case, however, a RatedProductUsage would immediately be associated with the Usage, as there is no representation of the unrated recurring fee in our systems.
    Is my understanding correct?

    Thanks a lot in advance for your thoughts on this.

    ------------------------------
    Carsten Zimmermann
    Deutsche Telekom AG
    ------------------------------


  • 2.  RE: What is a Usage to be considered?

    TM Forum Member
    Posted Nov 10, 2020 11:22
    Hi Carsten
    In the Open API model, a recurring fee is modeled as a ProductPrice (in the inventory), derived from a ProductOfferingPrice (in the catalog).
    These are visible in the respective APIs (TMF637 and TMF620).
    The existence of such a fee will eventually cause an AppliedCustomerBillingRate (ACBR) to be generated onto the periodic bill (TMF678).
    Usage is not the same as recurring - in the case of very fine-grained usages (e.g. telephone calls) - the usage records will be rated and aggregated into ​ACBR, while coarse-grained usages (e.g. consuming digital content) could be considered in some billing models as individual one-time charges.

    You can of course model a usage allowance that gives e.g. 100 SMS messages per billing period, for which a recurring charge of 2 Euro is paid.

    Hope it helps

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



  • 3.  RE: What is a Usage to be considered?

    TM Forum Member
    Posted Nov 18, 2020 07:30
    Hello Jonathan,
    thanks for the information. This solves my issue.
    Best
    Carsten

    ------------------------------
    Carsten Zimmermann
    Deutsche Telekom AG
    ------------------------------



  • 4.  RE: What is a Usage to be considered?

    Posted Dec 05, 2021 04:57
    Jonathan, "eventually" -- yes.
    What about immediate API where you feel the journey of unrated periodic charging should start?

    I feel it well may be some subclass of Usage. It will be in spirit (below), would it not?

    /**
    * An occurrence of employing a Product, Service, or Resource for its intended
    * purpose, which is of a billing system's interest and can have charges applied
    * to it. It is comprised of characteristics, which represent attributes of usage.
    */
    public abstract class Usage {...}


    ------------------------------
    ALEXANDER PETROSSIAN
    TO BE VERIFIED
    ------------------------------



  • 5.  RE: What is a Usage to be considered?

    TM Forum Member
    Posted Dec 05, 2021 05:17
    Not sure I follow you, Alexander.
    If you are looking for the ability to query unbilled usage charges, then I believe you have that in Usage Consumption Management API TMF677. Check it out and see if it is relevant.

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



  • 6.  RE: What is a Usage to be considered?

    Posted Dec 17, 2021 08:44
    I was thinking about putting external usage inside my system in SID-like class.
    Maybe, as you wrote before, I'm looking for a good container to pass external events inside us.

    There is a general 688 Event infrastructure, we could model external events as descendants from TMF688_EventManagement::Event.
    But that API does not explicitly support responses and is async, would need correlation between requests and responses.

    Our external equipment does not like to wait and I'm looking for something syncronous.

    Thanks for your attention, Jonathan!

    ------------------------------
    ALEXANDER PETROSSIAN
    TO BE VERIFIED
    ------------------------------