Oracle® Application Integration Architecture Oracle Communications Order to Cash Integration Pack Implementation Guide for Siebel CRM, Oracle Order and Service Management, and Oracle Billing and Revenue Management Release 11.2 Part Number E26501-02 |
|
|
PDF · Mobi · ePub |
This chapter provides an overview of the Synchronize Fulfillment Order Billing Account business flow and discusses solution assumptions and constraints.
This chapter includes the following section:
This business flow is enabled using the Oracle Communications Order to Cash Siebel Customer Relationship Management (Siebel CRM), Oracle Order and Service Management (Oracle OSM), and Oracle Billing and Revenue Management (Oracle BRM) pre-built integration options.
Communications service providers (CSPs) do not want to overburden Oracle BRM with all of the customer information in their Siebel CRM system. Instead, they want the ability to create the necessary customer data in Oracle BRM only as it is needed; that is as part of the order fulfillment process.
To Synchronize Fulfillment Order Billing Account(s), the process integration for order lifecycle management (OLM) provides the following service:
CommsProcessFulfillmentOrderBillingAccountListEBF: This creates customer data in Oracle BRM when called as part of the order fulfillment process.
This service takes an order as input and collates order data and then calls other enterprise billing services (from the Customer Management Process Integration) to create accounts and their components (such as billing preferences and payment methods) referenced on an order in a target Oracle BRM instance. This service can be invoked from an order orchestration flow from within an order management system, such as Oracle OSM, to create customer data in Oracle BRM.
For more information about calling this service, see Appendix H, "Expectations from a COM System for Billing Integration."
For more information about the Customer Management process integration, see Chapter 18, "Understanding the Process Integration for Customer Management."
For more information, see Appendix C, "OLM - Mapping Billing Dates" and Appendix E, "OLM - Examples of Changing the Paying Parent on Subordinate Accounts."
Figure 10-1 shows the order interface to customer data in Oracle BRM.
The CommsProcessFulfillmentOrderBillingAccountListEBF service processes only lines with the actions of ADD, UPDATE, and MOVE-ADD and ignores the others. This service considers the following kinds of order lines for customer data collation:
For lines whose billing type is Service Bundle, Item, Subscription, or Discount, it considers Service Account, Billing Account, and Billing Profile.
For lines whose product type is Promotion, it includes only Billing Account.
All other lines are ignored.
The result of calling this service is the creation of customer data such as accounts, bill-infos, and pay-infos in Oracle BRM.
Customer creation that occurs in Oracle BRM as part of order fulfillment using the service InterfaceOrderToCustomerEBF cannot be undone:
The service does not support the ability to inactivate or delete accounts, bill-infos, or pay-infos in Oracle BRM.
Calling the CommsProcessFulfillmentOrderBillingAccountListEBF again with the same input as before has no effect.
If the service is called with references to different customer data than before, the service detects the delta and creates just the account, bill-infos, and pay-infos that do not exist in Oracle BRM.
When the service account on a service bundle or account-level product line is different from the bill-to account, the service account is created as a nonpaying subordinate account under the bill-to account in Oracle BRM; that is, it results in the creation of a paying hierarchy in billing:
A paying hierarchy, when created, cannot be undone simply by the cancellation of the original Siebel CRM order.
If the service is called to update an existing paying hierarchy (for example, to set the paying account for a subordinate account to a different paying account), to undo that update (because the Siebel CRM order requesting the change was canceled), the order management system must rework the message such that it is a call to update the hierarchy to a previous state.
For information about what Siebel account information is sent to Oracle BRM see Section 18.4.1, "Create/Sync Account Integration Flow."
Table 10-1 summarizes what is expected from the order management system (that is calling this service) in terms of action on the line. Oracle OSM and OSM AIA cartridges obey these expectations.
Table 10-1 Actions on Order Line Expectations Summary
Original Action on Order Line | Is this the first time the order line is being processed by customer sync or is it a revision? | What is occurring on the revision (that is relevant to customer sync) | Expected Action on compensation order line, set by Order Management | Comments |
---|---|---|---|---|
ADD |
First time |
Not applicable |
ADD |
-- |
ADD |
Revision |
No changes to service account, billing account, or billing profile |
NONE |
No changes for customer sync to process. |
ADD |
Revision |
Changes to service account, billing account, or billing profile |
UPDATE |
From a customer sync perspective, the fact that it is a revision is irrelevant in that it just checks whether the customer data referenced on the order exists in Oracle BRM; if not, it creates it. If customer sync is using the original ADD line, a billing hierarchy is created, and on the revision the attributes that affect the hierarchy are changing, then it makes the required change. The order management system indicates which attributes have changed by populating the prior value fields for the changed attributes. Prior value fields are specifically used in flagging and determining that a paying hierarchy change has occurred. |
ADD |
Revision |
Cancellation. Manifests as a missing line on the revision. |
DELETE |
This action is ignored by the customer sync. If the ADD line added a new account, bill-info, and pay-info, and then the request for a new purchase was canceled, then those entities are not inactivated or deleted. If the ADD line created a paying hierarchy, and then the request for new purchase was canceled, then the paying hierarchy stays in place. |
UPDATE |
First time |
Not applicable |
UPDATE |
Expects prior value fields to be populated. |
UPDATE |
Revision |
No changes to service account, billing account, or billing profile |
NONE |
No changes for customer sync to process. |
UPDATE |
Revision |
Changes to service account, billing account, or billing profile |
UPDATE |
From a customer sync perspective, the fact that it is a revision is irrelevant in that it just checks whether the new set of customer and billing profiles exist in Oracle BRM; if not, it creates it. If customer sync is using the original UPDATE line a billing hierarchy is created or updated, and on the revision the attributes that affect the hierarchy are changing, then it makes the required change. The order management system indicates which attributes have changed by populating the prior value fields for the changed attributes. |
UPDATE |
Revision |
Cancellation. Manifests as a missing line on the revision or the action changing to a "-" (NONE). |
UPDATE |
If the original update line created a new account and billing profile in Oracle BRM, then it cannot be undone. For the attributes that have changed on the original line, the order management system flips the values (old, new) on the compensation line. For the case in which a hierarchy has been updated, this in essence reverts that update. |
MOVE-ADD |
First Time, but can change billing account and billing profile as part of a move-add. |
Not Applicable |
MOVE-ADD |
Expects prior value fields to be populated for values that are changing from an existing asset. |
MOVE-ADD |
Revision |
No changes to service account, billing account, or billing profile* |
NONE |
No changes for customer sync to process. |
MOVE-ADD |
Revision |
Changes to service account, billing account, or billing profile* |
MOVE-ADD |
From a customer sync perspective, the fact that it is a revision is irrelevant in that it just checks whether the new set of customer and billing profiles exist in Oracle BRM; if not, it creates it. If customer sync is using the original UPDATE line, a billing hierarchy is created or updated, and on the revision the attributes that affect the hierarchy are changing, then it makes the required change. The order management system indicates which attributes have changed by populating the prior value fields for the changed attributes. |
MOVE-ADD |
Revision |
Manifests as a missing line on the revision or the action changing to a "-" (In essence the line is canceled). |
MOVE-ADD |
If the original MOVE-ADD line created a new account and billing profile in Oracle BRM, then it cannot be undone. For the attributes that have changed on the original line, the order management system flips the values (old, new) on the compensation line. For the case in which a hierarchy has been updated, this in essence reverts that update. |
* Billing integration supports only changes to billing account and billing profile as part of MOVE-ADD.
Caution:
The process integration for billing management (delivered in the Agent Assisted Billing Care pre-built integration) assumes that a given billing profile is synchronized to a single billing system. It does not support the ability to query data for the same billing profile from multiple billing system. For that reason, if that process integration is in use, then the same billing profile must not be used on an order for services that are fulfilled in different billing systems.
For more information about this assumption, see the billing management chapter in the Oracle Application Integration Architecture Siebel CRM Integration Pack for Oracle Communications Billing and Revenue Management: Agent Assisted Billing Care Implementation Guide.
For solution assumptions and constraints for this business flow, see Section 12.8, "Solution Assumptions and Constraints."