10 OLM - Understanding the Synchronize Fulfillment Order Billing Account Business Flow

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:

Section 10.1, "Synchronize Fulfillment Order Billing Account Overview"
Section 10.2, "Solution Assumptions and Constraints"

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.

10.1 Synchronize Fulfillment Order Billing Account Overview

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.

Figure 10-1 Synchronize Fulfillment Order Billing Account - Interfacing Customer Data to Billing

This image is described in surrounding text.

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.

10.2 Solution Assumptions and Constraints

For solution assumptions and constraints for this business flow, see Section 12.8, "Solution Assumptions and Constraints."