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.
------------------------------
Original Message:
Sent: Feb 13, 2021 17:27
From: Prakash Ranjan
Subject: TMF622 and Billing Order - who notifies Billing?
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
Original Message:
Sent: Dec 08, 2020 15:34
From: Marc Corlett
Subject: TMF622 and Billing Order - who notifies Billing?
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
Original Message:
Sent: Jun 18, 2019 11:05
From: Jonathan Goldberg
Subject: TMF622 and Billing Order - who notifies Billing?
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
Original Message:
Sent: Jun 18, 2019 06:58
From: Thomas Dupré
Subject: TMF622 and Billing Order - who notifies Billing?
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
Original Message:
Sent: Jun 18, 2019 04:56
From: Michael Frandsen
Subject: TMF622 and Billing Order - who notifies Billing?
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
Original Message:
Sent: Jun 17, 2019 04:03
From: Thomas Dupré
Subject: TMF622 and Billing Order - who notifies Billing?
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
- send some (to be defined) Billing Order request to the Billing system OR
- 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
------------------------------