Open APIs

Expand all | Collapse all

TMF622 and Billing Order - who notifies Billing?

  • 1.  TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Jun 17, 2019 07:25
    Hi,

    I tried to find an Open API for a Billing Order, that is, a Billing request which contains the ordered products of a customer as result of a TMF622 Product Ordering request.
    Being not successful with my search (TMF678 is only about invoice / bills itself) I am now wondering about the best way to inform Billing about new (or changed / deleted) products in the course of processing the product ordering request:

    The product ordering component (which implements TMF622) could
    1.  send some (to be defined) Billing Order request to the Billing system OR
    2.  merely update the product inventory (according to TMF637) according to the contained (new/modified/deleted) products in the product order. The product inventory then sends some change event (notification), and the Billing system reacts to this event.
    The first approach would implement a direct coupling between Product Ordering and Billing (but the question is which API would be the correct one?)
    whereas the second approach would decuple those components and use the notification mechanism of the product inventory instead.

    I would be glad to receive some hints / remarks in this matter. Maybe there exists already a related discussion but I didn_t manage to find such a thread.

    Best regards
    Thomas

    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------


  • 2.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Jun 18, 2019 05:18
    Edited by Michael Frandsen Jun 18, 2019 05:19

    Hi Thomas,

    Release 19 of TMForum Open APIs will help you. As release 18.5 cleaned up the service layer, the next release is focused on the product layer.

    So I guess the Customer Order Handling is supported by TMF622 Product Order Mgt. API.

    Within the Order Management you will deal with the following two:
    - Account Mgt. API (TMF666) which is (IMHO) the main source of the Customer Bill Management

      Excerpt TMF666: "It allows creation, update and retrieval of account information either in a B2B2C relationship context (creation of mass market customer billing account within a "Billing on Behalf of" process for example) or in a B2B context (creation of a billing/settlement account for a partner or B2B customer)."

    - Product Inventory Mgt. (TMF637)

    Both APIs are focused on the next release (19). As your colleagues Thomas (B) and Alexis seem to be part of the API Project they should be able to give you more information or help you to bring missing pieces to the TMForum.

    The Customer Bill Management API (TMF678) states in the explanation of the Customer Bill Resource:
    "The billing account receives all charges (recurring, one time and usage) of the offers and products assigned to it during order process." - That is why I conclude that the Account Mgt. API needs to be what you are looking for.

    Best regards
    Michael



    ------------------------------
    Michael Frandsen
    Vodafone Group
    ------------------------------



  • 3.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Jun 18, 2019 07:40
    Hi Michael,

    well, not quite... maybe my question was not stated clearly enough. IMHO a Billing accoount (TMF666) typically exists before a product order is launched (therefore the TMF622 product order references an existing Billing account).

    My question is how Billing will be informed about new/changed products  (with reference to a billing account) when a product order is being processed.

    Since such thing like a "Billing Order" does not seem to exist (at least I haven't found it so far) I assume that there is no direct interface between Product Ordering and Billing - unlike e.g. "Service Order". Instead my guess is that Product Ordering will update the product inventory, and the Billing system will retrieve Billing relevant information out of it (which is option b. in my previous post).

    BR Thomas

    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 4.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Jun 18, 2019 11:17
    Hi Thomas
    My suggestion would be that the billing/charging system would itself expose the Product Order API. All the information needed is already in the Product Order model, and crucially there is information there that would not necessarily be stored in the Product Inventory, for example one-time charges.
    The alternative that you suggest, of creating a new Billing Order model, seems to me less attractive, since I am not sure what differences there would be in the model.
    But maybe @Ludovic Robert, the API lead for TMF622, has a different perspective.



    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 5.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Jun 18, 2019 11:48
    Hi Jonathan,

    I guess that one-time charges are part of the ProductOffering Prices and are therefore contained in the product inventory via the Product-to-ProductOffering relation, so they could be retrieved from a Billing system.
    Note that I am not proposing to create a new BillingOrder model - but given that some Order Management system realizes the Product Ordering API, would it be reasonable that in addition some Billing system exposes the same API?

    The question behind is
    - whether Billing is being estimated as some component necessary for product order fulfillment (as for option a) OR
    - whether it can be safely decoupled from order fulfillment via product inventory (notifications) - because bills have another life cycles than orders (option b).

    BR Thomas

    ------------------------------
    Thomas Dupré
    Deutsche Telekom AG
    ------------------------------



  • 6.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Jun 18, 2019 12:51
    You are correct that the one-time charges arise from ProductOfferingPrice that get instantiated as ProductOrderPrice. But it is perhaps not a safe assumption that one-time charges would be instantiated as ProductPrice in the inventory. Why would I clog up my inventory with charges that have no meaning ongoing, and on the contrary could cause confusion if the end customer saw these charges in the inventory.
    So this may be an implementation decision, and I suggest not to rely on it.

    ------------------------------
    Jonathan Goldberg
    Amdocs Management Limited
    ------------------------------



  • 7.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Aug 21, 2019 10:41

    Hi @Jonathan Goldberg,

    So do we conclude that

    1) The Billing Account creation can be safely assumed to be out of scope of Product Ordering Domain, because Open API TMF622 only contains a reference to Billing Account and not the billing account entity information required to create it (same as Party/Customer Account) ?

    2) Secondly are we saying that Billing will need to updated from the Product Ordering domain for creation, modification & disconnection (basically impacts of product instance life cycle on the billing system) of the Product instances ? At-least this what we have seen in the older architectures right?



    ------------------------------
    Rabinder Devnani
    Sterlite Technologies Limited
    ------------------------------



  • 8.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Aug 21, 2019 12:54
    Hello Jonathan, Michael, Thomas,

    there are 2 possibilities:
    (1) Billing takes the product inventory data from the one and only product inventory managed by some CRM using the order management api (TMF622). In this case, there is no need for any notification of changes. This situation is in practical BSS environments unlikely due to many reasons (history of BSS, performance, responsibilities, ….).
    (2) Billing maintains a copy of the product inventory (following the idea of microservices and having therefore the need of independence). In this case there is a need to synchronize the product inventory with the copy of the billing part of the product inventory. TMF622 api, offered by billing, could be a possible solution. It should be consumed in every case the original inventory is changed by the "original" 622 api. (there might be the need for regular check of synchronicity, in order to assure the robustness of the overall BSS, this is not part of my discussion here)
    (2a) The synchronicity of a billing inventory could be assured by the technique of callback notifications (this is a defined resource in TMF637). Billing would be notified if there is a change in the product inventory.

    Prices: Every charge type including one time charges should be part of the inventory. But, depending on the way the business is driven, it is open whether it should be displayed to the customer. A use case could be the dispute about a bill together with billing history and contract history. I agree with Jonathan, that it is not safe to assume that this is implemented.

    Best regards
    Lucius
    (Deutsche Telekom)

    ------------------------------
    Dr. Lucius Gruber
    Deutsche Telekom AG
    ------------------------------



  • 9.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Dec 08, 2020 11:50

    I'm curious about the pattern discussed here where multiple applications implement the 622 specification.

    Does the billing component use polymorphism to extend the productOrder resource with a BillingOrder type? In that way billing exposes all 622 apis and notifications for a productOrder of type "BillingOrder"? CRM would then invoke POST /productOrder?@type=BillingOrder 

    Or is the billing system still operating on a productOrder resource maintained by the CRM system? How exactly does this interaction work?

    thanks
    Lynn
    @Jonathan Goldberg



    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------



  • 10.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Dec 08, 2020 15:41
    Picking up on this thread from last year...
    I'm interested in this view of exposing the Product Order API from a billing system or any other system other than the Customer Order Management system. By exposing the TMF622 API spec, do you mean that the billing system must support the creation and management of another PO resource which would be either identical to or a subset of the original PO it is derived from? Would the calling system such as a Customer Order Management system which has the original PO from the customer be initiating that through POST /productOrder that the billing system consumes, and would the billing also be issuing PO events for the same product order as the Customer Order Management system? The same questions could equally be posed regarding a Shipping system that needs a "shipping order" that contains just the physical goods products from the original product order.

    ------------------------------
    Marc Corlett
    Oracle Corporation
    ------------------------------



  • 11.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Feb 13, 2021 17:27
    Edited by Prakash Ranjan Feb 14, 2021 00:00

    Hi ,
    This has been interesting discussion starting almost 2 years back and I also had this question - How to trigger Billing for start /modify/stop charging with Open API .
    The inclination seems to reuse/extend TMF622 but I am not seeing concrete conclusion still. There are concerns/questions noted (last 2 post) of clear seggregation , Ownership of Entity and events etc - if we simply implement TMF622 for Billing Order without clearly defining how. 

    The related discussion I see in another thread , where similar requirement has been raised

    In my opinion -  Clean solution option would be to extend TMF622  with sub resource BillingOrder. This is being crucial step in order to cash journey - and should be covered explictly in Open API.
    (something similar pattern of resource modeling in TMF666 - with various Accounts: Party Account ,Billing account , Financial account etc…).

     Suppose we are waiting for TMF622 Lead  to confirm the direction? 

    ------------------------------
    Prakash Ranjan
    Infosys Architect
    ------------------------------



  • 12.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Feb 15, 2021 04:28
    Hi all

    Indeed a very interesting discussion.
    I'm almost certain that we would not design a BillingOrder as a sub-entity of ProductOrder. If we did design such an entity, it would be stand-alone, with perhaps a subset of the product order structure. We are already working on a separate object for a Shipping Order (in design at the moment, no published materials yet), so perhaps we would follow the same pattern.
    The thing is, not sure that a Billing/Charging system would be "interested" in creating an actual persistent BillingOrder entity. The interaction with the system is likely to be immediate and synchronous, and certainly not long-running in the way that an order is. A more plausible alternative would be to construct a task resource, something like NotifyProductOrderToBilling. The input payload could include relevant parts of the product order, and the output could include (perhaps) stuff that the Billing/Charging system created as a result of the notification.

    @Marc Corlett @Lynn Dueck apologies for the delay in reacting to this.
    @Ludovic Robert what do you think?​​​​​​​​

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



  • 13.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Feb 16, 2021 05:03
    Edited by Prakash Ranjan Feb 16, 2021 05:07
    Thanks Jonathan for acknowledging that its under consideration,
    To your question of whether Billing/Charging system would be "interested" in creating an actual persistent BillingOrder entity - Indeed its not going to long lived Order (unlike Product and shipping) , but still needed as sync API to trigger  Billing for start /modify/stop charging.  I am aware of couple of operator implementing such service API (eg SubmitBillingOrder).  Also some of COTS Billing product (eg CSGI Singleview) expects such API call as well.
    Typical key input parameters: 

    - Product Instance ( with ref to Recurring/ One time charge.)
    - Billing Account  ref ( which need to have this charge.),related Party ref
    - Service Reference , (for eg MSISDN.  Typically when Billing receives such order - it also have serviceidentifier which is meant for Usage guiding (rated/unrated) to particular Billing Account
    - Charge Start date , most of cases it could be same Product is successfully activated , but in few cases this can differ as well( eg start charging from next month..)

     Output
    Success/Failure


    ------------------------------
    Prakash Ranjan
    Infosys Architect
    ------------------------------



  • 14.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Feb 16, 2021 11:05
    Yes, thank you Jonathan and Prakash for your thoughts. I agree that billing/charging systems would not generally be interested in creating and managing an order resource which can be long-lived. Functionally, the billing/charging system isn't managing the delivery of the products so the order concept seems inappropriate, whereas a Shipping Order makes sense functionally, so I'm glad to hear that's being worked on.
    I like Prakash's suggestion that there should be an additional billing API to update items products, charges, discounts on a billing account. I think @Ludovic Robert similarly alluded to the need for an API for billing​​ items in another thread.

    ------------------------------
    Marc Corlett
    Oracle Corporation
    ------------------------------



  • 15.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Feb 17, 2021 09:10
    Hi @Jonathan Goldberg, if we assume billing will implement 622 product order then events will be confusing; Same event will be produced when CRM creates/updates a product order or when an OM creates/updates a product order intended for billing. If we are true to the spirit of REST then a new billing order resource is necessary even if it is a copy of the product order. We have similar concept in customer domain. If billing order is deemed unnecessary then we need to make sure at least the solution doesn't produce ambiguous events.​

    ------------------------------
    Adam Naser
    Oracle Corporation
    ------------------------------



  • 16.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Mar 02, 2021 13:56

    If billing implements 622 but uses the task resource pattern that @Jonathan Goldberg mentioned last, then there would not be ambiguous events between the systems. The task resource pattern has event notifications specific to the task resource not the main product order - so in this case NotifyProductOrderToBillingCreateEvent or NotifyProductOrderToBillingStateChangeEvent.

    OM would invoke POST /NotifyProductOrderToBilling on the billing system passing it the OM product order payload or some subset of this data.
    I assume billing would have an implementation choice on the short or long running task resource pattern. One results in a resource being created, and id being returned and events generated for that resource. The other does not require a resource to be created and no events to be generated.

    Is that correct Jonathan?



    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------



  • 17.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Mar 03, 2021 13:07
    Hi Lynn

    I think you meant to say in your first line: "If billing does not implement 622 but instead uses the task resource pattern ..."

    Please see my exposition here on the Task Resource pattern, I think you stated things correctly.

    Regarding the specific task for billing notification, I am not aware of plans to design this in the current round of Open API enhancements, but TMF is a member-driven and member-contributing organization, so maybe someone would want to take up the challenge.

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



  • 18.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Mar 04, 2021 13:12
    Yes you are correct Jonathan and thanks for the pointer to the Task Resource pattern!

    Lynn

    ------------------------------
    Lynn Dueck
    Oracle Corporation
    ------------------------------



  • 19.  RE: TMF622 and Billing Order - who notifies Billing?

    TM Forum Member
    Posted Mar 05, 2021 09:50
    Task Resource is one way as @Jonathan Goldberg has indicated and is likely the least intrusive way of implementing the integration for existing systems that have an activity-driven native API.

    Unfortunately it is still as proprietary as simply having another custom CRUD API or adding additional custom root or task resources to any other one of the existing TMF OpenAPIs.​

    For interoperability, I therefore like the idea of a dedicated model-driven API to provision billing which is not a BillingOrder API.​

    So, I guess everyone will go with task resources for now...

    Using SID model entities is certainly still best practice, even with task resources.

    ------------------------------
    Florian Wiesner
    Oracle Corporation
    Architect CX Industries
    ------------------------------