8 Understanding the Process Sales Order Fulfillment Business Flow

About the Process Sales Order Fulfillment Business Flow

The business flow is initiated when a Siebel CRM customer service representative (CSR) submits an order.

Siebel CRM adds the order message to a Java Messaging Service (JMS) queue, where a JMS consumer picks it up and passes it to the Oracle AIA integration. The integration transforms the message and passes it to OSM for processing.

The integration includes a Test Orchestration Process to test the ready-to-use order flow if you are not using OSM for order management. For production systems, you must replace the test orchestration process with your own order management system. See Oracle Application Integration Architecture Installation and Upgrade Guide for Pre-Built Integrations for more information about replacing the TOP.

About Sales Orders

Sales orders are orders that purchase products and services for customers. Siebel CRM submits orders and the integration sends the orders to OSM. Orders from Siebel CRM are composed of an order header and order lines. The order header includes attributes applicable to the customer and to all order lines. Order lines apply to particular products or services and are composed of a subject and an action.

Order line subjects in Siebel CRM can include but are not limited to simple and customizable products, discounts (modeled as simple products), service bundles, promotions, and pricing event products (used with multi-event billing products). When order line items are fulfilled and provisioned, they are called assets.

Siebel CRM supports the following order line actions:

• Add: Adds a new asset

  • Move-Add: Used when transferring an existing asset from one address to another to add the asset at the target location

  • Move-Delete: Used when transferring an existing asset from one address to another to delete the asset from the source location

• Delete: Disconnects/cancels an existing asset

• Update: Updates an attribute on an existing asset or product or service that has yet to be fulfilled.

• Suspend: Changes the status of an existing asset to Suspended.

• Resume: Changes the status of an existing asset from Suspended to Active.

You can revise orders in Siebel CRM several times before submitting them. Siebel CRM tracks these revisions and each revision replaces any previous revisions. Revisions internal to Siebel CRM are not considered OSM revision orders because they are not submitted for fulfillment.

When you submit an order, the integration uses the attributes on the order to populate cross-reference tables and pass the fulfillment information to OSM and BRM.

When OSM receives order information from the integration, OSM determines the point of no return as set for the order items. An order past the point of no return is not yet complete, but you can no longer revise it in Siebel CRM.

For more information about the point of no return, see OSM Concepts, and for information about setting a point of no return, see OSM Cartridge Guide for Oracle Application Integration Architecture.

Siebel CRM and OSM use different terms to refer to orders in different states of completion. This chapter uses the Siebel CRM term.

Table 8-1 defines and maps the terms from Siebel CRM to OSM.

Supporting Large Orders

A large order is a sales order with a large number of order lines, typically several hundred order lines. Both business-to-consumer scenarios (such as bulk price changes for all customers) and business-to-business scenarios (such as corporate orders for services in multiple offices) can result in large orders. See "Promotion Groups and Large Order Scenario" for a detailed example scenario that results in a large order.

By default, Oracle AIA can process orders with up to 1000 order lines with no significant impact on order processing time. For orders with greater than 1000 order lines, you can decrease order processing time by enabling the Process Large Order sub-flow within the Submitting Orders to OSM integration flow.

To decrease processing time to transform the order message as part of the Process Large Order sub-flow, Oracle AIA splits the order ABM message into multiple smaller messages, transforms the smaller ABMs into EBMs, and then merges the smaller transformed EBMs.

Figure 8-1 illustrates this process.

Figure 8-1 Processing a Large Order in an Oracle AIA Deployment

Description of ''Figure 8-1 Processing a Large Order in an Oracle AIA Deployment''

The OSM APIs, server, database, and O2A cartridges all help OSM orchestrate orders that have several thousand order lines.

The following properties in the AIAConfigurationProperties.xml file configure the Process Large Order sub-flow:

• The handleLargeOrderEnabled property specifies whether Oracle AIA uses the Process Large Order sub-flow to split large orders.

• The numOrderLinesInLargeOrder property specifies the number of order lines an order must have to be considered a large order.

• The numOrderLinesInMiniABM property specifies the number of order lines in a single small ABM.

For more information about these properties, see Table 25-6, "ProcessSalesOrderFulfillmentSiebelCommsReqABCSImpl Properties".

About Accepting Payments on Orders

The integration supports accepting payments from customers at order time.

Using Siebel CRM, you can accept the following methods of payment:

• Automatic debit

• Credit card

• Cash

• Wire transfer

• Check

You must set the payment status to New in Siebel CRM for payments included at order time.

You can record the payment against any billing profile that appears on the order or that has already been synchronized to BRM in a previous order. You can record multiple payments against a single billing profile or against multiple billing profiles.

For example, a new customer, Denise, sets up the following three billing profiles on her account:

• BP-D, which she will use for her own services

• BP-M, which she will use for her daughter Michelle's services

• BP-J, which she will use for her daughter Jessica's services

Denise wants to order wireless service for her daughters and pay for their phones at the same time. When placing the order, the customer service representative (CSR) assigns BP-M to Michelle's service and BP-J to Jessica's service. To record the payments for the phones, the CSR can only use BP-M or BP-J, because BP-D does not appear on the current order or any previous orders.

Supporting Multiple Price Lists on Orders

At order creation in Siebel CRM, the price list assigned to the customer's account is automatically assigned to the order header. You can specify a different price list for the order header and for the individual order lines.

At design time in Siebel CRM, you create price lists, add the default price list to the AIAConfigurationProperties.xml file, and add the default and any additional price lists to the PRICELIST domain value map (DVM) before synchronizing product from BRM. See "Working with Price Lists and Rate Plans at Design Time" for more information about creating price lists at design time.

OSM uses the price list information sent on a Siebel CRM order to initiate and fulfill billing in BRM using the correct rate plan.

Supporting Promotion Groups on Orders

Your customers can share charges, discounts, and special rating profiles by purchasing promotion groups.

You create promotion groups at design time in Siebel CRM. Each promotion group definition includes an owner membership product, a member membership product, and one or more reward products. See "About Promotion Groups" for more information about creating promotion groups at design time. At order time, you associate the membership products with your customers' accounts and services.

You include a promotion group on a sales order as described in the discussion of creating new promotion group instances in Siebel Order Management Guide Addendum for Communications, with the following modifications:

• Create the sales order from the promotion group owner's account.

• Associate owner membership products with any of the following:

  • Service bundle

  • Simple service bundle

  • Nested service bundle

  • Account, only in the following situations:

    • (Optional) In promotion groups that contain only chargeshare rewards

    • (Required) In promotion groups with a member membership product associated with a product promotion

• Do not associate the owner membership product with a product promotion or a service bundle within a product promotion.

• Associate member membership products with any of the following:

  • Service bundle

  • Simple service bundle

  • Product promotion

Table 8-5 shows some details from an example order placed from a corporate account. The order includes VoIP services for the corporate account and an employee, Andrew. It also includes a promotion group instance, promotion group memberships associated with the corporate and employee services, a recurring fee, and three shared rewards.

See "Synchronizing Promotion Groups" for details about how the integration implements this order in BRM.

You can include multiple promotion groups on a single order. However, if you are using multiple instances of BRM, you cannot use a single order for multiple promotion groups that include services from different BRM instances. You must use a separate order for each promotion group that includes services from a separate BRM instance.

Supporting Family Share Plans on Orders

Family share plans let a group owner share resources with group members, and the integration synchronizes family share plans from Siebel CRM to sharing groups in BRM. Family share plans do not add extra order lines for memberships. Instead, the integration uses order line attributes to create sharing groups in BRM.

The accounts that participate in a family share plan must be in an account hierarchy. You create the order for the family share plan from the parent account, and purchase the add-on services in the bundled promotion for the nonpaying child accounts. Use the parent account as the billing account on all services in the bundled promotion and use the nonpaying child account as the service account for the add-on wireless lines. You can use separate billing profiles for each service.

For example, Denise purchases the Wireless Family Share Plan bundled promotion shown in Figure 3-8, "Example of Modeling for a Family Share Plan" with add-on lines for her two children, Michelle and Jessica. Denise selects different service accounts for the services and different billing profiles of her billing account. Table 8-6 shows some of the details included on the order.

See "Synchronizing Family Share Plans" for details about how the integration implements this order in BRM.

When placing a new or change order for a family share plan bundled promotion, you can add only the service bundles that were defined as components of the promotion at design time. You cannot add other service bundles or existing assets from the parent or child account.

See the discussions of editing a bundled promotion and bundling components for a promotion in Siebel Order Management Guide Addendum for Communications for more information about adding service bundles and existing assets to bundled promotions.

Supporting Order Priority

You select order fulfillment priority in Siebel CRM when submitting orders. This priority affects the sequence in which orders are picked up from queues and processed in Oracle AIA and OSM. Orders with a higher priority take precedence over orders with a lower priority that have not yet started fulfillment.

The order priority set in Siebel CRM is honored by message queues, Oracle AIA, and OSM, unless data integrity dictates a different processing sequence, such as with updates to sales orders from OSM to Siebel CRM.

Supporting Split Billing on Orders

When placing orders from Siebel CRM, you can split bills for service bundles among multiple accounts for consumer and business customers.

You can split bills:

• For a nonpaying child account among multiple parent accounts and multiple billing profiles.

• For a paying child account among the child account and one or more parent accounts and multiple billing profiles.

• For multiple child accounts among multiple parent accounts on the same order.

You split bills on an order by specifying a billing account on the order line that is different than the service account.

For example, Scott subscribes to a double-play promotion that includes a wireless bundle and a broadband bundle. His father and mother, Duncan and Cathy, split the bill. Duncan pays for the wireless service and Cathy pays for the broadband service. In this situation, Scott's service account is a nonpaying child account.

The order lines for Scott's services would include the accounts shown in Table 8-7.

Alternatively, Scott could pay for his wireless service while one of his parents pays for his broadband service. In this situation, Scott's service account is a paying child account.

In the Siebel CRM account hierarchy, the service account on the order line must be subordinate to the billing account, but the service account does not need to be the immediate child of the billing account. For example, Scott's service account could be the child of Cathy's billing account, which in turn could be the child of Duncan's billing account.

When the service account for an order line is different than the billing account, the integration creates a /billinfo hierarchy for the service account while creating the account in BRM. See "Supporting Split Billing" for more information about the /billinfo hierarchy in BRM.

Either parent or child can pay for account-level products, but the same account must pay for all account-level products for the lifetime of the account. For example, if Cathy initially pays for Scott's account-level products, neither Duncan nor Scott can ever take over or pay for new account-level products for that account.

You can split the bills for service bundles and simple service bundles nested within service bundles. However, the same account must pay for the top-level service bundle and any service bundle component that is not a nested service bundle or a simple service bundle. For example, Scott's wireless bundle includes a nested service bundle representing voicemail, another nested service bundle representing SMS, and a one-time charge for activating the line. Scott's parents want to split the bill for these components. The CSR specifies Cathy's account and billing profile for the voicemail service bundle and Duncan's account and billing profile for the SMS service bundle. The CSR also specifies Cathy's account and billing profile for the top-level wireless service bundle and the one-time activation charge.

When legal owners are enabled and you are splitting bills between a self-paying child account and the legally-responsible parent account, you must submit separate orders for the self-paid and parent-paid services. See "Supporting Legal Owners on Orders" for more information about legal owners and how AIA supports split billing for legal owners.

Supporting Corporate Account Hierarchies on Orders

A corporate account hierarchy represents the relationship in the account management application between a corporation and its employees. You create account hierarchies in Siebel CRM and synchronize them to BRM at order time.

When placing orders for accounts in a corporate account hierarchy, the integration synchronizes the linear hierarchy of the service account and the billing account on the order. Any siblings of the accounts on the order that are not directly related to the service account or billing account are not synchronized.

Oracle recommends bundling account-level products on the order with a service. Bundling account-level products with services for corporate accounts prevents these products from being tracked in the account-level balance group, which gives you greater flexibility in transferring accounts to different hierarchies.

All accounts on the order must have the same account type. By default, the integration synchronizes the corporate hierarchy for accounts with the account type of BUSINESS. You can change this value in the O2C.CorporateHierarchyAccountType property of the AIAConfigurationProperties.xml file.

See "About Corporate Account Hierarchies" for more information about creating and synchronizing corporate account hierarchies and setting the type of account for which the integration synchronizes the hierarchy.

Supporting Legal Owners on Orders

When placing orders for customers who pay their own bills but cannot legally be held responsible for the charges that they incur, you can assign a legal owner to the bill. You assign a legal owner on an order by specifying an owner account on the order line in Siebel CRM that is different than the billing account.

Because each child account can have only one legal owner in BRM, you must ensure that the owner account for all order lines in one order in Siebel CRM is the same. When the integration detects that the owner or customer account and billing account on an order line are different, it creates a collections sharing group in BRM to represent the legal hierarchy.

You enable legal owners using the O2C.LegalGroup property in the AIAConfigurationProperties.xml file. By default, legal owners are disabled. See "Enabling and Disabling Legal Hierarchy Synchronization" for more information about enabling legal owners.

For more information about setting up legal hierarchies and synchronizing legal owners to BRM, see "About Legal Hierarchies".

Assumptions and Constraints for the Process Sales Order Fulfillment Business Flow

The assumptions and constraints for the Process Sales Order Fulfillment business flow are as follows:

• Siebel CRM implements service points as assets and you typically upload them into Siebel CRM from external sources. You should manage service points in a common place and share them between Siebel CRM and Network Inventory (Service and Resource Inventory). The integration assumes that at least one following statement is true:

  • The determination of service point in Siebel CRM is irrelevant to Service and Resource Inventory.

  • The determination of service point in Siebel CRM is replicated in Service and Resource Inventory (for example, the same result is achieved).

  • The service point attribute value is unique and common across Siebel and Service and Resource Inventory, such that Service and Resource Inventory can use the value directly.

  • The service point attribute value is a cross-reference that is understood by Service and Resource Inventory; no Oracle AIA cross-reference exists for this attribute.

• When you create a change order, leave it pending in Siebel CRM, and submit it at a later date, Siebel CRM ensures that the change order data is up to date with the actual data from the installed assets. Any customization of Siebel CRM or integration with a different CRM system must also ensure that pending orders are up to date before submitting them.

• If you submit a follow-on order before submitting the base order on which it depends, OSM processes this follow-on order as a base order. Submit base orders first to establish the follow-on order dependency in OSM.

• Mixing future-dated, follow-on, and revision orders requires a well-trained CSR because some scenarios could produce unintended results.

• Siebel CRM can capture revisions to order Due Date in Siebel CRM (Requested Delivery Date in Oracle AIA) and submit them to Oracle OSM.

• Revising the Requested Delivery Date for an order only affects OSM if the base order did not start fulfillment by the time OSM received the revision.