2 Order to Payment Business Process

This chapter describes the Order to Payment business process and features.

Overview of the Order to Payment Business Process

The Order to Payment business process encompasses activities related to order capturing, processing, fulfilling, and billing. This process deals with capturing the subscriber information, creating the order with suitable products and services as per their requirements, fulfilling the order to provision the required services and generating bills for the same.

The Order to Payment business process includes support for the following features:

• Subscriber Onboarding
• First-time Purchase of Products and Services
• Support for Multiple Pricelist and Currencies
• Applying Discounts as per the Discount Matrix
• Promotion Component Discount
• Time-Based Offers
• Override of Price and Discounts
• Offer Aggregation
• Compatibility Rules
• Eligibility Rules
• Support for Bulk Order
• Order Fallout Management

The sections that follow describe these features.

About Subscriber Onboarding

The Subscriber Onboarding feature creates subscriber data in BRM from order data while processing orders as part of order lifecycle management.

The journey of a subscriber’s purchase begins when they are prospects targeted by CSPs. This process starts with targeted marketing efforts to raise awareness about unique offerings and gain interest. Prospects then explore their options by reviewing detailed plan information, trial offers, and customer support resources. After a decision is made, prospects provide their details to create accounts with the CSP, becoming subscribers. Subscribers can then place orders for the desired services via Agent assistance. Ongoing follow-ups address concerns, ensure satisfaction, and foster long-term loyalty through personalized engagement strategies.

You capture account information when creating orders. You begin creating an order in Siebel CRM by searching for an existing account or creating a new account for a new subscriber.

Account information that you capture at order time includes billing preferences such as bill medium and frequency, payment type, billing type, billing contact, and bill cycle data. It also includes parent-child hierarchy relationships.

This feature creates subscriber data in BRM when you submit orders for processing and is supported for orders from Siebel CRM.

See About the Synchronize Fulfillment Order Billing Account Flow for more information about where subscriber synchronization fits in to order fulfillment.

About Create/Sync New Subscriber Account

Figure 2-1 illustrates the Create/Sync New Subscriber Account flow.

Figure 2-1 Create/Sync New Subscriber Account

Description of "Figure 2-1 Create/Sync New Subscriber Account"

Table 2-1 provides information on Siebel CRM attributes mapped to BRM as part of the Create/Sync New Subscriber Account flow.

Table 2-1 Siebel Entities Created or Synchronized to BRM

Entity or Attribute in the Siebel CRM	Entity or Attribute in BRM	Notes
Account	Account	BRM sets the account status to Active by default. If the billing account and service account on the order line are different, the Order to Cash business process creates a creates a /billinfo hierarchy and a two-level account hierarchy in BRM. The Siebel CRM service account is a BRM child account and the Siebel CRM billing account is the BRM parent account. If there is more than one billing account on the order, the first billing account is the parent account.
--	Account Number	Oracle AIA sets this to the Common ID.
Account Type	Account Type	Valid Siebel CRM Account Type values are Residential and Business. Uses the CUSTOMERPARTY_TYPECODE DVM.
Name	Company Name	Only set for Residential Account Types.
Currency	Currency	Uses the CURRENCY_CODE DVM.
Contact	--	The Order to Cash business process synchronizes the account's primary contact to BRM.
Mr/Mrs	Salutation	Uses the CONTACT_SALUTATION DVM.
First Name	First Name	--
Last Name	Last Name	--
Phone	Phone Number	The Order to Cash business process maps different Siebel CRM phone number types (home, work, fax, mobile) to BRM Phone Type and Number using the PHONENUMBER_TYPE DVM. The phone number format should match the supported format in BRM. See "Using BRM with Oracle Application Integration Architecture", "Validating Customer Contact Information" in Oracle Communications Billing and Revenue Management for more information about phone number formats.
Job Title	Job Title	--
Email	Email	--
Address	--	The Order to Cash business process synchronizes the account's primary address to BRM.
Address	Address	In addition to Address, fields for City, State, Postal Code, and Country are mapped. Uses the following DVMs: ADDRESS_COUNTRYID, ADDRESS_COUNTRYSUBDIVID, PROVINCE, STATE.
Billing Profile	BillInfo	--
Name	Name	--
Frequency	Billing Frequency in Months	Uses the CUSTOMERPARTY_BILLPROFILE_FREQUENCYCODE DVM
--	Currency	Integration passes account-level currency. Uses the CURRENCY_CODE DVM
Billing Schedule	Billing Day of Month	If the Billing Schedule is not set in and sent from Siebel CRM, then BRM defaults the Billing Day of Month. See "Setting Business Policies for Billing" in Oracle Communications Billing and Revenue Management Configuring and Running Billing Guide for more information about the billing schedule.
--	PayInfo	--
Payment Method	Payment Method	Only Bill Me, Credit Card or Auto-Debit is supported. Uses the CUSTOMERPARTY_PAYPROFILE_PAYMETHODECODE DVM.
Contact Last Name, First Name	Name	When the payment method is Bill Me, the Contact Name on the Siebel Billing profile is mapped to BRM PayInfo Contact Name. When the payment method is Credit Card or Auto-Debit, either the Credit Card owner name or Debit Account name is mapped to BRM PayInfo Contact Name.
Bill Media	Delivery Preference	Applicable only when the payment method is Bill Me. Uses the CUSTOMERPARTY_PAYPROFILE_DELIVERYPREF DVM.
Email Bill To	Email Address	Applicable only when the payment method is Bill Me.
Address	Address	In addition to Address, fields for City, State, Postal Code, and Country are mapped. Uses the following DVMs: ADDRESS_COUNTRYID, ADDRESS_COUNTRYSUBDIVID, PROVINCE, STATE.
Credit Card #	Credit Card Number	Applicable only when the payment method is Credit Card.
Expiration Month & Year	Credit Card Exp	Applicable only when the payment method is Credit Card.
Security Code	Security ID	Applicable only when the payment method is Credit Card.
Account #	Debit Num	Applicable only when the payment method is Auto-Debit.
Bank Routing #	Bank No	Applicable only when the payment method is Auto-Debit.
Bank Account Type	Type	Applicable only when the payment method is Auto-Debit.

Data Requirements for Creating a New Subscriber Account

The Order to Cash business process requires the following data to successfully create subscriber data in BRM:

• Account Type: Residential

• Account Class: Customer, Service, or Billing

• In Siebel CRM, accounts can have any number of contacts or addresses associated with them. BRM requires at least the following:

  • The primary contact for the account, including last name

  • The primary address for the account, including city, state or province, country, and zip or postal code

  • The contact and address associated with the billing profile, including city, state, and zip code

  • For a credit card payment method, the credit card number, expiration month and year, and cardholder's name (card verification value number is optional)

  • For an automatic debit payment method, the bank routing number and account number

All billing profiles for an account and its related parent and child accounts must have the same value for Bill Frequency.

Oracle AIA expects OSM to initiate the synchronization of subscriber accounts while it orchestrates orders. If you are using an order management system other than OSM, you must ensure that your system recognizes changes in the accounts that appear on sales orders, such as owner accounts, service accounts, and billing accounts, by identifying old and new accounts that appear in the ProcessSalesOrderFulfillmentEBM.

See the following for more information about expectations for order management systems other than OSM

• Table 5-3
• Communications Orders Dictionary
• Expectations from an Order Management System for Billing Integration

About Subscriber Management

Subscriber Management lets you synchronize subscriber information to BRM from Siebel CRM.

You create and update subscriber data in Siebel CRM and the Order to Cash business process synchronizes the account information to BRM during order processing. This is a one-way synchronization process; changes made to subscribers in BRM are not synchronized to Siebel CRM.

The process does not load subscriber data in bulk into BRM. Instead, it synchronizes new accounts and billing information to BRM while processing the first order for those accounts.

It also synchronizes updates to the accounts from Siebel CRM to BRM.

About Synchronizing Subscriber Account

When synchronizing subscriber account information, subscriber data is created in BRM from order data while processing orders as part of order lifecycle management.

You capture account information when creating orders. You begin creating an order in Siebel CRM by searching for an existing account or creating a new account for a new subscriber.

Account information that you capture at order time includes billing preferences such as bill medium and frequency, payment type, billing type, billing contact, and bill cycle data. It also includes parent-child hierarchy relationships.

Synchronizing subscriber account lets you do the following:

• Create/Sync Subscriber Account: Creates subscriber data in BRM when you submit orders for processing. Supported for orders from Siebel CRM.

• Update Subscriber Account: Updates existing subscriber data in BRM when you when you update accounts in Siebel CRM.

See About the Synchronize Fulfillment Order Billing Account Flow for more information about where subscribers synchronization fits in to order fulfillment.

For more information about implementing this flow, see Implementing the Synchronize Subscriber Account Flow.

About the Update Subscriber Account

When subscribers call to change their account information, such as contact, payment, billing, and hierarchical information, a customer service representative (CSR) updates the accounts in Siebel CRM. The Order to Cash business process synchronizes subscriber account updates to BRM in real time through the Update Subscriber Account integration flow.

Updates are synchronized to BRM only for accounts that have already been created with Siebel CRM through the Create/Sync Subscriber Account integration flow as part of the order fulfillment flow.

The process integration can optionally synchronize account status updates from Siebel CRM to BRM. See About Account Status Synchronization for more information.

Figure 2-2 illustrates how updating a subscriber account works.

Figure 2-2 Update Subscriber Account

Description of "Figure 2-2 Update Subscriber Account"

About Account Status Synchronization

You can synchronize account status changes from Siebel CRM to BRM. Account status synchronization enhances the process integration for collections management, which is delivered by the Cash to Care Business Process business process. Oracle recommends that you enable account status synchronization only if you are also using the process integration for collections management.

The Cash to Care Business Process synchronizes collections actions generated by BRM as credit alerts in Siebel CRM, where a CSR can take actions on the subscriber's account such as suspending or canceling services.

You can suspend or cancel services with change orders that are either manually submitted by a CSR or automatically generated based on credit alerts. You can also extend Siebel CRM to automatically generate change orders based on credit alerts. Using change orders ensure that service state changes are synchronized from Siebel CRM to BRM.

If you must inactivate a subscriber account due to continued delinquency, enabling account status synchronization ensures that account status change in Siebel CRM is synchronized to BRM.

Synchronizing account status to BRM is disabled by default. You can enable it by changing the value of the EnableAccountStatusSync property in the AIAConfigurationProperties.xml file. See Configuring Customer Management for more information.

When inactivating accounts in Siebel CRM, Oracle recommends the following:

• Inactivate accounts in Siebel CRM only after canceling all the services and account-level subscription products for that account in Siebel CRM. When you inactivate an account in Siebel CRM, the status change is immediately synchronized to BRM. BRM cascades status changes from the account to all of its /billinfo objects, so the services and products in BRM are canceled as well. If you inactivate the account before cancelling the services and products in Siebel CRM, they continue to appear active in Siebel CRM even after BRM cancels them.

• To avoid inadvertent inactivation of accounts with active services, Oracle recommends restricting the ability to inactivate accounts to particular Siebel CRM users and roles. Siebel CRM does not let you restrict account status changes in other ways.

See Oracle Application Integration Architecture Siebel CRM Integration Pack for Oracle Communications Billing and Revenue Management: Cash to Care Business Process Implementation Guide for more information about collections management.

About First-Time Purchase of Products and Services

The first-time purchase of products and services extends from the time a quote or order is created to the time when the goods and services are delivered and billed. Order to Cash works with Siebel CRM, Oracle Communications Order and Service Management (OSM), and Oracle Communications Billing and Revenue Management (BRM). You can integrate with other types of fulfillment systems, such as supply chain management and workforce management, or with alternative billing and order management systems as an extension project at implementation time.

Note:

First-time purchase is when a new customer is placing an order for products and services.

About Order Capture

The first-time purchase of products begins with the creation of a sales order to capture the particulars of the telecom order, which entails the services or assets requested by the subscriber, changes in service, or disconnection of services. It is captured and validated in Siebel CRM then submitted to OSM in the central order management (COM) role for fulfillment.

Figure 2-3 shows a typical order capture flow. The flow can vary depending on, for example, service family, subscriber segment, or line of business.

Order-based system interactions between different business support systems (BSS) and operational support systems (OSS) generally require order decomposition and orchestration to go through the order management layer. The process integration for order lifecycle management includes integration points for the following systems interactions:

• Qualify Subscriber Order: Validates the availability of a service design and the capacity to fulfill the subscriber order.

• Deliver Subscriber Order: Fulfills the products and services purchased by the subscriber or fulfills actions on existing subscriber assets.

Figure 2-3 Typical Order Capture Flow

Description of "Figure 2-3 Typical Order Capture Flow"

Figure 2-3 shows typical order activities for the CRM system and their integration points with the order lifecycle management activities.

A typical order capture progresses as follows:

1. A Customer Service Representative (CSR) creates a new subscriber account or searches for an existing subscriber account. CSRs can also capture subscriber information at other times, such as when creating or updating an opportunity or quote.

2. (Optional) The CSR runs a credit check on the new subscriber.

3. The subscriber chooses products and the CRM system validates the products.

4. The CSR prices the selected products and product options.

5. (Optional) The CSR checks the availability of any physical goods.

6. (Optional) The CSR reserves the resource for services such as phone numbers.

7. (Optional) The CSR subjects the order to technical service qualification and the Qualify Customer Order process starts.

8. (Optional) The CSR schedules an appointment with an engineer through a workforce management system.

9. The CSR submits the order and the Deliver Customer Order process starts.

About Sales Orders

Sales orders are orders that purchase products and services for subscribers. 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 subscriber 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 product offerings), 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/services.

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 2-2 defines and maps the terms from Siebel CRM to OSM.

Table 2-2 Order Term Mapping

Siebel CRM Term	OSM Term	Description
Open order	In-flight order	An order that has been submitted to fulfillment but is not yet complete.
Supplemental order	Revision order	A changed version of an in-flight/open order. See About Supplemental Orders.
Follow-on order	Follow-on order	A changed version of an in-flight/open order that has passed the point of no return. Fulfillment of the follow-on order waits until the fulfillment of the order item on which the follow-on order depends is complete. See About Follow-On Orders.
Modify order	--	An order to modify the attributes of assets on a completed order. There is no direct correlation in OSM; such orders are treated as new orders.
Future-dated order	Future-dated order	An order scheduled to start at a future date. See About Future-Dated Orders.

Sales orders are processed by the Process Sales Order Fulfillment Business Flow. For more information on implementing this flow, see Implementing the Process Sales Order Fulfillment.

About Deliver Subscriber Order

Figure 2-4 shows the typical application activities and interactions involved in delivering subscriber orders.

Figure 2-4 Deliver Subscriber Order

Description of "Figure 2-4 Deliver Subscriber Order"

The integration delivers subscriber orders as follows:

1. A new, revision, or follow-on order is submitted in Siebel CRM. The integration sends the order to OSM.

2. OSM does the following:

   1. Transforms and enriches the order by mapping order lines to fulfillment flows and enriching them with fulfillment metadata and other relevant data.

   2. Decomposes the order by dividing the order into order components and composing an orchestration plan to track order dependencies.

      The orchestration plan directs order fulfillment using pre-configured functions, such as synchronizing the subscriber into BRM, initiating and fulfilling billing, provisioning the order, shipping the order, and installing the order. Oracle AIA integrates the OSM fulfillment functions with BRM APIs, and custom integrations integrate OSM fulfillment functions with network inventory and activation system APIs.

      Orchestration plans are typically more complex than the flow in Figure 2-4. See the discussion of orchestration in Oracle Communications Order and Service Management Concepts for examples of a more detailed orchestrations plan.

   3. OSM manages order fallout by creating trouble tickets in Siebel CRM.

      The integration provides for detection, reporting, and resolution of order fulfillment fallout conditions such as validation, and fulfillment errors using Siebel CRM trouble tickets. System errors (such as an unreachable system) are handled differently.

      See Using Error Type to Control Response to Order Fallout for more information.

   4. Manages order status by mapping fulfillment function responses to common statuses. OSM updates Siebel CRM with relevant subscriber status and milestone values. It also updates Siebel CRM when order lines reach their point of no return to prevent the submission of new revisions.

About the Qualify Subscriber Order

Figure 2-5 shows the typical application activities and interactions involved in delivering subscriber orders.

Figure 2-5 Qualify Subscriber Order

Description of "Figure 2-5 Qualify Subscriber Order"

This flow starts with a request to qualify the technical validity of a subscriber order submitted from Siebel CRM to OSM.

OSM performs the same functions described in Figure 2-5, except that the metadata and the fulfillment functions are for qualifying the subscriber order rather than delivering the subscriber order. The billing, activation, and delivery activities are not part of qualifying orders. The two subflows also produce different order and order line status updates.

Product Definition and Mapping Design Considerations

This section discusses high-level considerations for defining your products and mapping them on orders to fulfillment functions at run time.

About Defining Products

Because the product and service definition methodology has the greatest effect on time to market and on the cost of an Order to Cash deployment, Oracle recommends a balanced approach that involves compromises between departments that result in simplified overall product life cycle and order life cycle.

For more information about defining products, see Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Mapping Orders to Fulfillment Functions

Order management systems act on subscriber orders, which are composed of order lines. Each order line is represented by an action and a subject. Actions are verbs that represent the nature of the subscriber request, such as ADD to purchase an offering or UPDATE to modify the subscription to an offering. A subject is the target of the action and can represent items such as an offering, an asset, or a discount.

Oracle recommends mapping each order line to a separate product specification. This approach helps achieve fast time-to-market and low-cost operations. The integration implements this recommendation by associating product offerings with a Siebel CRM product class and an OSM product specification using the Fulfillment Item Code attribute in Siebel CRM.

Mapping a subscriber order to a service order requires specific metadata modeled on products, product specifications, and service and resource configurations. In an Order to Cash deployment, OSM handles this mapping.

Figure 2-6 illustrates how an order management system in the integration uses the product model to map customer order lines to fulfillment functions.

Figure 2-6 Mapping Order Lines to Fulfillment Functions

Description of "Figure 2-6 Mapping Order Lines to Fulfillment Functions"

When a subscriber places an order, Siebel CRM copies product offering attributes to each order line. These attributes include Fulfillment Item Code, Product Type Code, and Billing Type. The integration uses these attribute values to determine the corresponding product specification. The Fulfillment Mode order header attribute determines the fulfillment request type (for example, Deliver or Qualify). The intersection of a product specification and fulfillment request type determines the fulfillment actions and dependencies involved. When combined for all order lines in an order, an order fulfillment plan is generated dynamically.

You can synchronize product classes from Siebel CRM to product specifications or conceptual model Product entities in OSM automatically using the Query Product Classes flow. See Oracle Communications Digital Business Experience Concept to Market Implementation Guide for more information.

Data Requirements for Order Lifecycle Management

Orders must include the following data to successfully process the order:

• An order must be of type Sales Order.

• For Siebel CRM, any price list specified on an order must match one created in Siebel CRM and configured in the PRICELIST domain value map (DVM). The default price list must also be configured in the AIAConfigurationProperties.xml file.

• If a price list is specified in the order header, any order lines that do not specify a price list will use the price list in the order header. If no price list is specified in the order header, each order line must specify a price list, with the exception of order lines for discounts synchronized from BRM as simple products in Siebel CRM. Price list information is not sent for billing discounts.

• Service bundle lines or account-level product lines must have a service account, a billing account, and a billing profile.

• Service bundle lines and simple service bundle lines must have a service ID before they are interfaced to a billing system.

• The following EBO attributes are mandatory for integration with OSM:

  • Order header: Order ID, Order Number, Revision, Fulfillment Mode, Order Type

  • Order line: Line ID, Base Line ID, Action Code, Product Name, Product Type

The Oracle AIA sales order enterprise business object is extensible and includes a vast set of attributes that are sufficient for most fulfillment systems.

About Supporting Multiple Price Lists on Orders

At order creation in Siebel CRM, the price list assigned to the subscriber'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 when the price lists are of the same currency.

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 Oracle Communications Digital Business Experience Concept to Market Implementation Guide 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.

Specifying Different Price Lists on New Orders

When you create a new order in Siebel CRM, the order can use the default price list for the order header, or you can specify a different one. You can also specify different price lists for the individual order lines when these price lists are of the same currency. If you submit the order without specifying a price list for an order line, OSM populates the empty order line with the price list specified for the order header.

Orders in Siebel CRM must have at least a default price list in the order header. Oracle recommends that you extend Siebel to enforce this requirement.

When you submit an order from Siebel CRM that includes a customizable product, such as a service bundle, a marketing bundle, or a non-service-bundle customizable product, Siebel CRM automatically assigns the price list for the customizable product to all order lines for components of the customizable product in the sales order ABM. You cannot change the price list for the order lines for components of the customizable product.

Table 2-3 shows an example of the order lines for a new Siebel CRM order. The table shows only the attributes relevant to this example.

Table 2-3 Example of Specifying Price Lists on a New Order

Line Number	Product	Action	Price List
1	Internet Access	Add	NA
2	Home Phone Service	Add	Premium Consumer Price List
2.1	Home Phone Access	Add	NA
2.2	Voicemail	Add	NA

When you submit the order in Table 2-3, Siebel CRM populates the price list for Home Phone Access and Voicemail products with Premium Consumer Price List. When AIA passes the order to OSM, OSM populates the Internet Access product with the price list specified for the order header and sends the order through the integration to BRM for billing.

For more information about the product models used, see "About the Product Models" in the Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Account and Billing Hierarchies

Account and billing hierarchies represent different types of relationships between accounts in Siebel CRM and BRM.

About Account Hierarchies

An account hierarchy represents the relationship in Siebel CRM between a parent and child account. In an account hierarchy, a parent can have more than one child, but a child can have only one parent.

In Siebel CRM, you can create account hierarchies with multiple levels of parents and children.

The integration does not automatically synchronize the account hierarchy to BRM. Instead, it creates account hierarchies in BRM when you submit an order where the billing account and service account on an order line are different. The integration creates the billing account as a BRM parent account and the service account as a BRM child account. If there are different billing accounts for the same service account on the different order lines, the integration sets the first billing account it encounters as the parent account in the hierarchy.

About Billing Hierarchies

A billing hierarchy represents the relationship in BRM between the /billinfo object for a child account and the /billinfo objects for one or more parent accounts. When you submit an order where the billing account and service account on an order line are different, the integration creates a billing hierarchy in BRM for the service account.

See the following topics for more information:

• See the discussion of hierarchical bill units in BRM Managing Accounts Receivable for more information about /billinfo hierarchies and how they relate to account hierarchies in BRM.

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

About Order Priority in Siebel CRM

By default, Siebel CRM provides the following order priority values:

• Low

• Medium

• High

• Urgent

When converting the Siebel CRM message to an EBM, the integration maps these values to integer values that are compatible with JMS priority.

JMS and the integration support priority values 0-9. You can extend Siebel CRM to support the full range of priority values by using the SWI_ORDER_JMS_PRIORITY mapping, which maps string values to integers. You must set up JMS compatibility properties on the Siebel CRM queue and make manual changes to seeded priority values.

See the discussion of modifying the order priority mapping in Siebel Order Management Guide Addendum for Communications, Employee Asset-Based Ordering for more information about priority values in Siebel CRM.

About Interfacing Orders to BRM

This section describes how order information is interfaced to BRM.

Creating and Updating Service Instances

The integration creates or updates service instances, purchased product instances, and discount instances in BRM depending on the action on the order line as follows:

• For order lines with the Add action, the integration creates new service instances, purchased product instances, and discount instances in BRM.

• For order lines with the Update action, the integration updates to the service identifier, billing account, billing profile, or price on existing service instances, purchased product instances, and purchased discount instances in BRM.

• For order lines with the Delete action, the integration cancels the BRM service instances, purchased product instances, and discount instances in BRM. Any refunds and proration are determined in BRM by product level controls.

• For order lines with a Move-Add or Move-Delete action, which are the result of transferring a service from one location to another in Siebel CRM, the integration moves the service instances, purchased product instances, and purchased discount instances in BRM. The integration also makes any updates to the service identifier, billing account, and billing profile. Move-Add and Move-Delete actions cannot include adding new assets or cancelling existing assets, only transferring assets.

About Price and Discount Overrides

When interfacing orders, the integration sends pricing information such as price or discount overrides, discounts, and one time penalty charges.

For price changes that occur within a billing cycle, the integration sends the price or discount overrides on a purchased product, the new price goes into effect from the following billing period, and no credits or debits are issued for the current period. To apply the new price immediately, submit an order to cancel the existing product, then submit another order to purchase the product at the new price.

For more information on applying one-time and penalty charges, see Applying One-time and Penalty Charges.

Applying Pricing or Discount Overrides

Pricing and discount overrides are controlled by the following order line attributes:

• Pricing Commit Type: Controls whether the difference between the list and the selling price (due to promotion bundling discounts, matrix discounts, or manual price overrides) on a purchased product is applied in BRM as a price or discount override. The BRM General Ledger component accounts for discount overrides but not price overrides.

  The integration uses this attribute as follows:

  • If the pricing commit type is set to Committed, the integration applies a price override in BRM.

  • If the pricing commit type is set to Dynamic, the integration applies a discount override in BRM and the Dynamic Discount Method attribute is used.

• Dynamic Discount Method: Controls whether a discount override is applied by percent or amount.

To use BRM pricing without any overrides for an order line, set the Pricing Commit Type to Dynamic and leave the discount blank.

BRM allows only one override for each charge or discount type for a single product. For example, if a BRM product is mapped to multiple events of the same type and synchronized to Siebel CRM as a complex product with multiple simple child products, the integration applies any override applied for one of the child products to all children of the complex product with the same charge or discount type.

Sending Price List Information

Orders submitted from Siebel CRM can specify a separate price list in the order header and at each order line. The integration includes the price list ID from the Siebel CRM sales order on the order messages sent to OSM and BRM.

BRM uses the rate plans associated with the price lists to charge the appropriate amount for the products or services purchased on the order lines.

Using Service Identifiers

When interfacing orders, the integration includes the service identifiers on the service bundle line to BRM. For telephony services, the service identifier is used as the phone number. For other services, it is used as the log in and password.

Communicating Promotion Information

To allow BRM to display promotion information on the invoice, the integration communicates the following information about the promotion when interfacing an order for billing:

• For new promotion purchases, the integration creates bundle instances under the billing account on the order line with the following information:

  • Promotion name

  • Promotion description

  • Effective start date: If there is a purchase date on the promotion order line, it is used. If not, the request date is used. If neither is available, BRM uses the current date by default.

• The integration creates the purchased product and discount instances for the respective purchased bundle instance. Such references are not created for products of type Item.

• As subsequent orders are processed, the integration creates new references as needed and maintains existing references such that the purchased products and discounts point to the bundle instance that is current.

• When a purchased promotion is canceled as part of a downgrade, upgrade, or cancellation, the integration cancels the bundle instance in BRM by specifying an effective end date. The integration uses the actual delivery date (on the order line canceling the promotion). If the actual delivery date is not available, it uses the request date.

No support is provided for translation of promotion name or description. Changing the name and description of the promotion (design time data) in Siebel CRM does not have any effect on transactions that have been submitted for processing and interfaced to billing.

Rolling Back Transactions

The integration service that interfaces the order to BRM either processes all of the lines on the incoming message or none of them. If an error occurs while it is processing the lines, then the entire transaction is rolled back.

See About Order Fallout Management for more information about order fallout.

About Supporting Balance Groups

The Order to Cash business process supports service-level and account-level balance groups.

A balance group is an object in the BRM database used for tracking account balances and bills. When you submit an order, the Order to Cash business process synchronizes service bundles as service instances in BRM and BRM tracks the balances for these services in balance groups. The billing profiles specified on the order are synchronized as bill units (/billinfo objects) in BRM.

When the Order to Cash business process creates a subscriber account in BRM during the Create/Sync Customer Account integration flow, it also creates a default account-level balance group pointing to a default bill unit associated with the primary billing profile for the account.

By default, the Order to Cash business process enables service-level balance groups to track the balances for each service separately. You can disable service-level balance groups to track all of the services on an account together in the default account-level balance group.

The default account-level balance group is used whether you enable or disable service-level balance groups. See About Tracking Account-Level Products in the Default Account-Level Balance Group for more information about how the default account-level balance group is used when service-level balance groups are enabled, and Working with Service-Level Balance Groups Disabled for more information about how the default account-level balance group is used when service-level balance groups are disabled.

Disabling Service-Level Balance Groups

To disable service-level balance groups:

1. Open the COMMS_AIA_HOME/source/soainfra/apps/AIAMetaData/config/AIAConfigurationProperties.xml file in AIA.

2. Search for the following element:

   <Property name="O2C.AccountLevelBalanceGroup">False</Property>
   

3. Set the O2C.AccountLevelBalanceGroup property to True:

   <ModuleConfiguration moduleName="BalanceGroupParameters">
     <Property name="O2C.AccountLevelBalanceGroup">True</Property>
   </ModuleConfiguration>

   Note:

   The O2C.AccountLevelBalanceGroup property is a system-level property. You enable or disable it for all accounts and services in the system.

4. Save and close the file.

5. Load the updated file to the Metadata Services (MDS) repository. See the discussion of uploading changed files to the Oracle Metadata Services repository in "Update Files to MDS" in the Oracle Application Integration Architecture Cloud Native Deployment Guide for more information.

If the O2C.AccountLevelBalanceGroup property does not exist in the properties file, service-level balance groups are disabled. You must add the property and set it to False if you want to enable service-level balance groups. For information about the additional steps required when adding properties to the AIAConfigurationProperties.xml file, see Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack.

If you enable service-level balance groups in an environment that has already processed orders, any services purchased when service-level balance groups were disabled continue to be tracked in the default account-level balance group. You cannot transfer these services to different accounts or assign them different billing profiles. To track these services in their own service-level balance groups, you must modify the services directly in BRM using opcodes.

If you disable service-level balance groups in an environment that has already processed orders, any services purchased when service-level balance groups were enabled continue to be tracked in their own service-level balance groups. You can still transfer these services to different accounts and assign them different billing profiles, but BRM tracks all new services under the account-level balance group and you cannot transfer them.

Working with Service-Level Balance Groups Enabled

When you work with service-level balance groups enabled, BRM tracks each service under its own balance group. Tracking services in service-level balance groups lets your customers do the following:

• Track services individually

• Pay for services of a single service account using multiple billing accounts

• Transfer services from one account to another

• Use sharing groups to share discounts, charges, and extended rating attributes

About Tracking and Billing Services with Service-Level Balance Groups Enabled

When you purchase multiple new services on one order, BRM tracks each service in a separate balance group. BRM bills the services based on which billing profile you assign each service. You can choose from the following options for billing services:

• Billing all services together: You assign all services the same billing profile.

  When you submit the order, BRM tracks each service in a separate balance group and the balance groups all point to the same bill unit. Figure 2-7 illustrates this option.

  Figure 2-7 Service-Level Balance Groups with a Shared Bill Unit

  
  

  
  Description of "Figure 2-7 Service-Level Balance Groups with a Shared Bill Unit"

  
  

• Billing all services separately: You assign each service a separate billing profile in Siebel CRM. When you submit the order, BRM tracks each service in a separate balance group and each balance group points to a separate bill unit. Figure 2-8 illustrates this option.

  Figure 2-8 Service-Level Balance Groups with Separate Bill Units

  
  

  
  Description of "Figure 2-8 Service-Level Balance Groups with Separate Bill Units"

  
  

• Billing some services together and others separately: You assign the same billing profile to some services and a separate billing profile to others in Siebel CRM. When you submit the order, BRM tracks each service in its own balance group. Some balance groups point to the same bill unit and others point to separate bill units. Figure 2-9 illustrates this option.

  Figure 2-9 Service-Level Balance Groups with Shared and Separate Bill Units

  
  

  
  Description of "Figure 2-9 Service-Level Balance Groups with Shared and Separate Bill Units"

  
  

About Tracking Services in Nested Service Bundles in Service-Level Balance Groups

Nested service bundles, including nested simple service bundles, must have the same billing profile as their parent service bundle. BRM tracks the nested service bundles in the same balance group as the parent service bundle.

When you submit an order from Siebel CRM, you must manually assign the nested service bundles the same billing profile as their parent service bundle.

Figure 2-10 illustrates how BRM tracks nested service bundles when service-level balance groups are enabled.

Figure 2-10 Balance Groups for Nested Service Bundles

Description of "Figure 2-10 Balance Groups for Nested Service Bundles"

In Figure 2-10, Wireless Service 2 is a service bundle nested within Wireless Service 1. Wireless Service 1 and Wireless Service 2 represent separate service instances in BRM, but BRM tracks both in the same balance group. You must assign the same billing profile to Wireless Service 1 and 2.

Because nested service bundles are tracked with their parent service bundle, you cannot transfer a nested service bundle by itself. You must transfer the parent service bundle and all of its components together.

About Tracking Service Bundles and Products Purchased on Change Orders in Service-Level Balance Groups

When you use change orders to purchase additional service bundles and products, you can purchase them separately or as components of an existing service bundle.

BRM tracks the new service bundles and products as follows:

• BRM tracks each service bundle purchased separately under its own balance group. You can assign any billing profile to separate service bundles.

• BRM tracks a product purchased separately from any service bundle or nested more than two levels within a service bundle in the account-level balance group. You can assign any billing profile to the new product, but the integration overrides your choice with the primary billing profile on the account.

• BRM tracks a product purchased as an addition to an existing service bundle in the same balance group as the parent service bundle. You must assign the same billing profile as the parent service bundle to the new product.

• BRM tracks service bundles that you purchase as additions to an existing service bundle in the same balance group as the existing service bundle when the existing service bundle was purchased after service-level balance groups were enabled. You must assign the same billing profile as the parent service bundle to the new service bundle.

  Note:

  If you submit an Update or Move-Add change order for a service bundle and add a new nested service bundle on the same order, BRM tracks the new nested service bundle in a separate balance group from the parent service bundle. If you want BRM to track the new service bundle in the same balance group as its parent service bundle, you must submit a separate order to add the new nested service bundle.

• BRM tracks service bundles that you purchase as additions to an existing service bundle in a new service-level balance group when the existing service bundle was purchased before service-level balance groups were enabled. BRM continues to track the parent service bundle in the account-level balance group. You can assign any billing profile to the new service bundle.

For more information about service bundles and their components, see Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Tracking Account-Level Products in the Default Account-Level Balance Group

BRM automatically tracks account-level products in the default account-level balance group created in the Create/Sync Customer Account integration flow. You can assign any billing profile to account-level products in Siebel CRM, but the integration overrides your choice with the primary billing profile on the account. You cannot transfer account-level products to different accounts or different billing profiles.

The account-level balance group of a nonpaying child account is associated with a non-paying bill unit, which points to the parent's paying bill unit. This parent bill unit is unrelated to the parent's account-level balance group. Figure 2-11 illustrates how BRM tracks account-level products for nonpaying child accounts.

Figure 2-11 Account-Level Products in Nonpaying Child Accounts

Description of "Figure 2-11 Account-Level Products in Nonpaying Child Accounts"

Working with Service-Level Balance Groups Disabled

When you work with service-level balance groups disabled, BRM uses the default account-level balance group to track and pay for all of their services together.

The default account-level balance group is created at the same time as the customer account in the Create/Sync Account integration flow. When service-level balance groups are disabled, BRM tracks all services and products for an account under this default account-level balance group. You cannot use sharing groups or split billing when service-level balance groups are disabled.

When you create subsequent orders for services (including nested service bundles and additional services purchased on change orders), you must use the same billing profile as the one selected on the first order.

Figure 2-12 illustrates how services are tracked under the account-level balance group.

Figure 2-12 Tracking Services in the Default Account-Level Balance Group

Description of "Figure 2-12 Tracking Services in the Default Account-Level Balance Group"

When you submit a single order for multiple products, the integration uses the billing profile of the first service on the order for all subsequent services on the same order. If an order for the services in Figure 2-12 assigned separate billing profiles to Wireless and Broadband, the result would remain the same because the billing profile for Wireless (the first service on the order) would be used for both services.

About Supporting Product Bundling

When you submit an order in Siebel CRM containing bundled products, the Order to Cash business process synchronizes the service bundles to service instances and the component products and discounts to purchased product and discount instances in BRM.

The Order to Cash business process synchronizes account-level products, account-level discounts, and any product or discount nested more than two levels below a service bundle to account-level purchased product and discount instances in BRM.

Note:

Because dynamic and relationship classes are not sent to BRM with the Siebel CRM order, they do not help determine a nested service bundle or nested product's parent.

See Oracle Communication Digital Business Experience Concept to Market Implementation Guide for more information about product bundling in Siebel CRM.

About Single-Phase and Two-Phase Billing

The Order to Cash business process supports both single-phase and two-phase billing. In single-phase billing, the order is interfaced to billing (or billing-fulfilled) after the service is provisioned. In two-phase billing, the order is billing-initiated before the service is provisioned, and is billing-fulfilled after service activation.

Choosing Between Single-Phase and Two-Phase Billing

Billing fulfillment scenarios lead to one of two fulfillment patterns, each of which must be supported by the order management implementation.

Single-Phase Billing

With single-phase billing, a service is interfaced to billing through billing fulfillment toward the end of the fulfillment flow, after the order is delivered and the actual delivery date is known.

You use single-phase billing in the following situation:

• When you do not have time lag or validation concerns. In this situation, interfacing to billing takes place after the service or product is made available to the subscriber.

  The date that a product is made available can vary based on jurisdiction and whether the product is a service or a physical good. For example, physical goods that require no network activation or on-site installation might be billed immediately after the goods are shipped. The exact timing is built into the fulfillment flows associated with the underlying product specification through the Actual Delivery Date and other billing date attributes.

Two-Phase Billing

With two-phase billing, the integration interfaces a service to billing twice:

• Billing initiation: The service and purchased products are interfaced early in the fulfillment flow and before actual delivery dates are known.

• Billing fulfillment: Accurate billing dates are updated in billing after the order is delivered and the actual delivery date is known.

You use two-phase billing in the following situations:

• Fulfillment latency: When operational or deployment conditions produce a time between the time a service is made available for subscriber use and the time the service is interfaced into billing.

  The time lag can cause errors in the usage records resulting in lost revenue. Rather than attempting to plan fulfillment of future-dated orders to meet the requested delivery date, build the fulfillment flow so that the Usage Start Date is set to the current date during billing initiation, and the Cycle Start Date is set to a distant future date. At billing fulfillment, the Cycle Start Date is then reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements.

• Validation latency: When you have inadequate controls to guarantee that orders are valid, resulting in a high rate of invalid orders, and the cost of delaying order line validation for interfacing to billing is high.

  In this situation, orders must be interfaced to billing early in the fulfillment flow to ensure that the order can be interfaced successfully later. Build the fulfillment flow so that the Purchase Start Date, the Usage Start Date, and the Cycle Start Date are set to a distant future date during Initiate Billing. At the time of Fulfill Billing, the Purchase Start, Usage Start Date, and Cycle Start Date are reset to match the Actual Delivery Date or Requested Delivery Date, depending on business practices and legal requirements.

Using Single-Phase Billing or Two-Phase Billing

To support various fulfillment latency requirements, the order billing interface can be called in two modes (by setting the ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentModeCode):

• INITIATE BILLING

• FULFILL BILLING

To enable single-phase billing, the order management system calls the order billing interface using only the FULFILL BILLING mode.

To enable two-phase billing, the order management system calls the order billing interface using the INITIATE BILLING mode before the service is provisioned and then after service activation, calls it using the FULFILL BILLING mode.

INITIATE BILLING Mode

You can design an order orchestration flow to interface the order to billing before the order is sent to provisioning. Calling the interface in INITIATE BILLING mode is optional. The billing interface is called with either of the following:

• The whole order: All of the lines on the order that are intended for a certain target billing system and related lines such as promotion lines.

• Order components: Promotion lines, service bundle lines and all service bundle component lines, and account-level products. All component lines for a single service bundle must be sent for billing initiation and fulfillment together. Any service bundle component lines sent only for billing fulfillment are not processed.

Depending on the requirements, you can set some or all of the following dates on new purchases of products or discounts to the future (in essence they are treated as inactive when interfaced to billing):

• Purchase Date (ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentOrderLine/FulfillmentOrderSchedule/PurchaseDate)

• Cycle Start Date (ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentOrderLine/FulfillmentOrderSchedule/CycleStartDate)

• Usage Start Date (ProcessFulfillmentOrderBillingEBM /DataArea/ProcessFulfillmentOrderBilling/FulfillmentOrderLine/FulfillmentOrderSchedule/ServiceUsageStartDate)

For promotion lines, only the purchase date is relevant.

To rate usage as soon as the service is activated but start the cycle fees at the date that the customer requested the service when there is a fulfillment latency between service activation and billing, have your order management system set the purchase and usage start dates to current and the cycle start date to the future when calling this service. See General Modeling and Implementation Recommendations for more information.

In this mode, the order interface to billing processes only new purchases of services or account-level products, or new purchases of products for existing services.

If a promotion is purchased as part of the new purchase, then that is also processed. One-time charges for actions such as Suspend, Resume, Move, and Disconnect and promotion penalties are not processed in this mode.

See Mapping Billing Dates for more information about how dates are set in BRM.

Handling Revision Orders

BRM prevents the caller from resetting purchase and cycle start dates when they become current. The integration does not reset the purchase date as part of billing-initiation revision processing, but resets the cycle start and usage start date if asked by the caller.

However, when billing initiation is called to process a revision on order lines that are billing initiated, and the call resets the cycle start date when the previously set date is current, then billing initiation fails with a BRM validation error.

General Modeling and Implementation Recommendations

The interface validates that the cycle date is set to the future for products of type Subscription or Discount. For products of type Item, the interface validates that the purchase date is set to the future. Oracle recommends that you set the future billing date to a year ahead of the due date when calling billing initiation.

The purchase, cycle start, or usage start dates is in the future if the following is true about the billing date:

billing date > (Fusion Middleware current time converted to UTC + (25 or FutureTimeThreshold hours, whichever is greater)).

where FutureTimeThreshold is the value of the FutureTimeThresholdForBillingDates Oracle AIA configuration property. This property has a default value of 8640 hours (360 days in hours).

If you are highly confident of the lead time required to activate the service, then you can lower the value of the FutureTimeThresholdForBillingDates property such that the order management system does not have to call fulfill billing to reset the dates that were set in initiate billing. This also allows the billing dates to naturally become current soon after the service is activated. You can set this property for each BRM instance.

If the FutureTimeThresholdForBillingDates property is not specified for a given billing instance, then the integration assumes the default value of 8640 hours (360 days).

Products of billing type Item must be purchased with a future date in billing initiation to enable the integration to cross-reference them and therefore avoid repurchasing them in billing fulfillment. The 25 hour minimum threshold is hard-coded to enable this.

BRM requires that the purchase date be before or equal to usage and cycle start dates. If the caller does not follow this for any line, then the billing interface (BRM ABCS) errors.

Recommendations for Purchase Fees or Activation Charges

BRM requires that the purchase date on a product be the same as or earlier than the usage start date. If activation (purchase fees) and usage charges were modeled on the same product to support the fulfillment latency situation, you must set both the purchase date and start usage date to current. However, if the subscriber cancels their order before the service was provisioned, you must manually process a refund of the activation charges to them. To avoid this manual process, you must model the activation (purchase) fee on a product of type Item, which is a separate product from the one on which the usage and cycle charges are modeled. Now to support the fulfillment latency situation, you set the purchase date for products of type Item to the future and set the purchase and usage start dates for the subscription products to current.

Recommendations for Discounts

If the service bundle includes products representing purchase or usage discounts, then to ensure that the subscribers get the discount, the purchase and usage start dates for the discount products must also be set to current when you are modeling the flow that sets the purchase and usage start dates to current for the subscription products.

FULFILL BILLING Mode

After provisioning is complete, the order orchestration flow can interface the order to billing in this mode. This is the default mode that the integration supports and is required to interface an order to billing.

In this mode, the integration processes all order lines that are sent on new orders or change orders. One-time charges for actions such as Suspend, Resume, Move, and Disconnect and promotion penalties are processed in this mode.

For order lines that have been interfaced in the INITIATE BILLING mode, the caller can now set a specific date (based on the actual delivery date) for those new purchases whose billing dates were earlier set to the future. Therefore, for the case in which only the cycle start date was set to the future during billing initiation, it must now be reset to the actual delivery date. For the case in which the purchase, cycle start, and usage start dates were set to the future, the caller must now set them to the actual delivery date.

The integration determines that an attribute has changed if prior value fields are populated. Your order management system must set the prior value fields for the following billing dates:

• PurchaseDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ PurchaseDate

• CycleStartDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ CycleStartDate

• ServiceUsageStartDate: ProcessFulfillmentOrderBillingEBM/DataArea/ProcessFulfillmentOrderBilling/ PriorFulfillmentOrder/FulfillmentOrderLine/FulfillmentOrderSchedule/ ServiceUsageStartDate

Caution:

If billing dates were set to current in billing initiation, resetting them in billing fulfillment causes a BRM error.

Assumptions and Constraints for Two-Phase Billing

1. For multi-event billing products, the integration honors billing dates (purchase start date -nrc_start_date, cycle start date - rc_start_date, usage start date - usage_start_date in Siebel CRM) on the parent complex product alone.

2. Billing initiation is optional, but billing fulfillment is mandatory for an order (or order lines) to be interfaced to billing.

3. The product that an order line references does not change after the line has been billing-initiated.

4. The order management system sends the one-time charge associated with a MACD action (Suspend, Resume, Move, Disconnect) with the service bundle on which the action is being performed.

5. Every Move-Add line on a Siebel CRM order has a matching Move-Delete (and vice versa). The order management system sends Move-Add lines along with the Move-Delete lines to billing.

6. After order lines are submitted for billing fulfillment, they are assumed to have hit a hard point of no return and cannot be revised in Siebel CRM.

7. Service ID is always sent as input to the billing interface (Initiation or Fulfillment).

See Mapping Billing Dates for more information about how dates are set in BRM.

About Time-Based Offerings on Orders

Time-based offerings let you use a Siebel CRM product class to set validity periods for products and discounts synchronized from BRM. You purchase time-based offerings on orders in the same way as other products and discounts and the integration calculates the validity periods as described in Supporting Time-Based Offerings on New Orders.

For information about creating time-based offerings and managing expired time-based offerings, see Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

Note:

If you are using an order management system other than OSM, Oracle recommends that you configure your system not to set end dates during billing initiation. End dates are not required for billing initiation, and setting them during billing initiation avoids the requirement to manage them as part of revisions.

OSM AIA cartridges do not set end dates during billing initiation.

Supporting Time-Based Offerings on New Orders

The integration processes new orders for time-based offerings as follows:

1. When you submit the order, Siebel CRM calculates the end date based on the start date (defaulted from the due date) and the Duration, DurationUnitOfMeasure, and DurationValidityStart transaction attribute values and sends the order through the integration to OSM for fulfillment.

2. When fulfilling the order, the OSM AIA cartridges set the purchase, cycle start, and usage start dates based on service actual delivery date and recalculates the end date.

3. When the order is billing fulfilled, the integration communicates the end date for the purchased product or discount to BRM.

4. OSM sends the actual start and end dates through the integration to Siebel CRM as part of the order update message.

For more information on time-based offerings for change orders, see Supporting Time-Based Offerings on Change Orders.

About Order Provisioning

Siebel CRM sends subscriber order fulfillment requests to OSM COM, which decomposes them into suborders called order components. OSM uses the integration to send order components that are targeted for provisioning to either OSM in the service order management (OSM SOM) role or other order management systems.

While provisioning the order, OSM SOM manages the order lifecycle events of the order. For Cancel and Revision requests from Siebel CRM, OSM generates and executes compensation plans to match the change. OSM also manages order data updates, status updates, and fallout incidents. Throughout the fulfillment process, OSM SOM sends status and data updates to OSM COM.

OSM manages provisioning using OSM Order-to-Activate cartridges, which interact with the Oracle Application Integration Architecture (Oracle AIA) interfaces. This document assumes that you have deployed the required cartridge. See Oracle Communications Order and Service Management Cartridge Guide for Oracle Application Integration Architecture for more information about Order-to-Activate cartridges.

For more information, see Implementing the Provision Order and Update Fulfillment Order Flows.

About Updating the Sales Order

This feature enables you to do the following:

• Update Sales Order Data

• Update Sales Order Status

About Updating Sales Order Data

OSM sends updated order data provided by downstream provisioning systems. For example, the service instance ID is blank on the sales order message from Siebel CRM. When a provisioning system assigns the service instance ID and sends a response to OSM, OSM sends an updated sales order message that includes the service instance ID to Siebel CRM.

Because revisions on the order can be submitted up until the point of no return, data updates sent from OSM before the point of no return could be lost. By default, OSM sends data updates only after an order line reaches the point of no return but before the order line is complete. If you are using an order management system other than OSM, ensure that your system follows this restriction.

About Updating Sales Order Status

OSM sends order and order-line level status updates to Siebel CRM to give visibility into order progress to customer service representatives and self-service customers. OSM automatically limits updates to those that are significant to the subscriber, and you can customize which updates are sent in the OSM Order to Activate cartridges.

You can configure and send order fulfillment statuses from OSM to your fulfillment systems and Siebel CRM. OSM translates the fulfillment function responses, each of which may contribute to different order line and order header status values, into common status attribute values.

The Order to Cash business process supports the order status attributes listed in Table 2-4.

Table 2-4 Order Status Attributes

Level	Attribute Name	Usage
Order Header	Fulfillment Status	Updates Siebel CRM with the current status of order fulfillment at a high level. The Fulfillment Status attribute tracks the order status while in fulfillment. Possible values include but are not limited to In Progress, Pending, Complete, Canceled, and Failed. The Fulfillment Status attribute is different from the Siebel CRM Status attribute. The Siebel CRM Status attribute tracks the order status across order capture and order fulfillment. The Complete and Canceled fulfillment status values only are reflected in the Siebel CRM Status attribute. The OSM cartridge implementer can configure the values for Fulfillment Status attributes.
Order Header	Status Context	Provides details about the current order status. OSM cartridge implementers can configure this value.
Order Line	Fulfillment Status	Updates Siebel CRM with the current status of order line fulfillment at a high level. Possible values include but are not limited to In Progress, Pending, Created, Complete, Canceled, and Failed. The OSM cartridge implementer can configure the values for Fulfillment Status attributes.
Order Line	Milestone	Indicates the most recent fulfillment milestone reached. Example milestones in OSM: SYNC CUSTOMER START: reached PROVISIONING START: reached FULFILL BILLING COMPLETE: reached The OSM cartridge implementer can configure the values for Milestone attributes.
Order Line	Status Context	Provides details about the current order line status. OSM cartridge implementers can configure this value to indicate: Required customer interaction. If delivery is expected to be delayed. The milestone or fulfillment function in which a failure occurred. The cause of a cancellation or who canceled an order.
Order Line	Point-of-no-return	Indicates if Siebel CRM should allow revisions to an order line or submission of previously created revisions to an order line. If a hard point of no return is established for an order line in OSM, OSM sends an update to Siebel CRM. Siebel CRM uses the point of no return to block users from revising order lines.
Order Line	Actual Delivery Date-Time	Indicates the date when the purchased product or service is considered available to the customer. This date may be the date physical goods are shipped, delivered, or their receipt acknowledged. For service-based products, this date is when the service is activated. This date is computed in the OSM fulfillment flow.
Order Line	Expected Delivery Date-Time	Indicates the expected delivery date for an order line. Siebel CRM provides this value by default. OSM uses this date to communicate changes for specific order line dates to Siebel CRM.

Because of the increased processing complexity of using different fulfillment status values for different services, Oracle recommends that you use a set of streamlined status values across product specifications. Using the streamlined values makes the status updates easier for your customers and customer service representatives (CSRs) to understand and lets you reuse the flow.

Use the following guidelines to help determine which status updates to send to Siebel CRM:

• Not all status changes are relevant to the CSR or the customer. Do not send irrelevant status updates.

• Not all status changes must be reflected instantly. Determine which status changes need to be sent instantly, such as reaching the point of no return, and which do not, and use a throttling mechanism to prevent performance and throughput problems which could result from too many status updates being sent at once.

• Always send Complete and Canceled statuses to Siebel CRM. These trigger actions in Siebel CRM as follows:

  • The Complete status indicates that a service is fulfilled and triggers Siebel CRM to create and update assets. The status can be set to Complete for a parent order line only after the order line and all of its subordinate order lines within the order hierarchy have completed fulfillment successfully.

  • The Canceled status excludes the order from a Siebel CRM calculation of the future state of the asset when creating follow-on or future-dated orders.

About Support for Discount Matrix

Discount matrix allows you to define pricing and discounts specific to subscriber and market segments. The discounts may vary by region or channels, other attributes outside of the product dimension to pricing and discounts. The discount matrix is defined by the product manager. If any discounts are defined according to discount matrix, then those discounts will be applied when orders are placed.

For more information about discount matrix, see Oracle Communications Digital Business Experience Concept to Market Guide.

About Promotion Component Discount

Promotion Component Discounts are the discounts that apply on the price of components (part of the package hierarchy) in the context of the package.

For example, if a voice service is given a discount of 10% when Package A is ordered by the subscriber but no discount when Package B is ordered. Here, the voice service is a component in packages, A and B. Thus, promotion component discounts are in the context of the package.

See Oracle Communications Digital Business Experience Concept to Market Guide for more information about promotion component discounts.

About Offer Aggregation

Offer aggregation refers to grouping of similar products that allow subscribers to select a given product offer from this group. Typically, offer aggregation is based on Product Line or Product Specification.

For example, grouping of similar devices based on Product Line, such as a mobile phone.

When ordering a package of choice, an asset that is part of the offer aggregation could be added as default, but the subscriber can choose to add any other asset as long as it is part of the same offer.

Offer aggregation could be modeled within a package, commercial bundle, or service bundle.

For more information, see the Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Compatibility Rules

Compatibility rules are defined to ensure that the appropriate combinations of products and services are offered to subscribers. The common use cases of such rules are a specific plan or package that may require the selection of a particular device, or choosing a device while limiting the accessories supported.

For example, if a customer wants to order a specific mobile accessory, a compatibility rule can be defined, stipulating that a specific mobile phone must be ordered as well.

Compatibility rules for product offerings are invoked during order creation in Siebel CRM.

For more information, see the Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Eligibility Rules

Eligibility rules define if a particular product offer can be purchased by a subscriber, based on various parameters such as Account Type, Country, City, Postal Code, etc.

For example, there might be eligibility rules that are defined to allow a particular product may only be purchased in selected cities of a particular country. So, while ordering, the application validates if the account data conforms to these rules and accordingly allows the order to be created. If the account data does not conform to the defined eligibility rules, then the product offer cannot be purchased by the subscriber.

Eligibility rules for product offerings are invoked during order creation in Siebel CRM. For more information, see the Oracle Communications Digital Business Experience Concept to Market Implementation Guide.

About Supporting Bulk Orders

Bulk orders can be created by CSR for multiple orders for different subscriber accounts by raising a bulk request. The bulk request uses a bulk request template and the CSR enters all the details into it.

Bulk orders can also be used to create new orders or asset-based (MACD) orders. For more information about asset-based orders, see About MACD Orders (Asset-Based Orders).

The bulk request template can also be used to create or modify multiple orders against multiple accounts.

For more information on using this feature, see the Siebel Order Management Guide.

About Order Fallout Management

Order Fallout Management helps you detect order fallout and notify the appropriate person so that you can correct failed orders. Oracle Application Integration Architecture (Oracle AIA) handles order exceptions with a detection and notification process that uses trouble ticketing for notification and tracking.

You can use Oracle AIA or Oracle Communications Order and Service Management (OSM) to initiate the creation of trouble tickets in Siebel CRM.

Order Fallout Management allows you to do the following:

• Create Trouble Ticket from Oracle AIA

  See About the Create Trouble Ticket from Oracle AIA Flow for more information.

• Create and Manage Trouble Ticket from OSM

  See About the Create and Manage Trouble Ticket from OSM Flow.

About the Create Trouble Ticket from Oracle AIA Flow

The Create Trouble Ticket from Oracle AIA flow provides trouble ticketing when OSM is not the central fulfillment system and is not used for order fulfillment and fallout management. In this flow, the Order to Cash business process provides services and artifacts to handle order fallout detection and notification.

The Order to Cash business process can also create trouble tickets in Siebel CRM when an order fails and an error is detected by the Oracle AIA error handler. Because the Order to Cash business process creates a trouble ticket for every fault message notification, you must model your processes to generate only one notification for each order failure.

Figure 2-13 illustrates the Create Trouble Ticket from Oracle AIA flow at a high level.

Figure 2-13 Creating Trouble Tickets from Oracle AIA

Description of "Figure 2-13 Creating Trouble Tickets from Oracle AIA"

When an error occurs in an edge application, such as in BRM while synchronizing subscribers or initiating billing, the edge application sends an error notification back to the ABCS that provided the order data. The ABCS sends a fault message to the Oracle AIA error handling framework.

When an error occurs in an Oracle AIA service, such as an ABCS or EBS, the service sends a fault message to the Oracle AIA error handling framework.

The Oracle AIA error handling framework initiates the Oracle AIA services that create trouble tickets in Siebel CRM.

For more information about the implementation of this flow, see Implementing the Create Trouble Ticket from Oracle AIA Flow.

About the Create and Manage Trouble Ticket from OSM Flow

The Create and Manage Trouble Ticket from OSM flow provides trouble ticketing when OSM is the central fulfillment system. When you install the Order to Cash for OSM business process option, the Order to Cash business process automatically uses OSM to manage order fallout.

Figure 2-14 illustrates the high-level process flow involved in using OSM for order fallout management.

Figure 2-14 Creating Trouble Tickets from OSM

Description of "Figure 2-14 Creating Trouble Tickets from OSM"

When an error occurs in an edge application, such as in BRM while synchronizing customers or initiating billing, the edge application sends an error notification back to the ABCS that provided the order data. The ABCS sends a fault message to the Oracle AIA error handling framework, which sends the message to OSM in the central order management role (OSM COM).

When an error occurs in an Oracle AIA service, such as an ABCS or EBS, the service sends a fault message to the Oracle AIA error handling framework, which sends the message to OSM COM.

When OSM COM receives errors from Oracle AIA or processing errors from within OSM, OSM COM manages the fallout with OSM-internal fallout management mechanisms, including compensation and orchestration of fallout orders. As part of fallout management, OSM can create trouble tickets and send them to Siebel CRM through Oracle AIA.

The Order to Cash business process creates trouble tickets on a per-order or per-application basis for failed orders that have been submitted from Siebel CRM as follows:

• The failure of different orders in the same application generates different trouble tickets.

• The failure of the same order in a different application generates a different trouble ticket. For example, if an order fails while initiating billing in BRM, and the same order fails while provisioning a service in OSM, the integration creates two trouble tickets for that order: one for the failure in BRM and one for the failure in OSM.

• Multiple order line item failures for the same order in the same application generate only one trouble ticket with the additional order line item failure information appended. For example, if three line items on an order fail during the service design phase of provisioning in OSM, the integration creates only one trouble ticket containing all three order line failures.

This flow operates under the following constraints:

• To cancel a failed order as part of error correction, you must cancel the order from OSM rather than Siebel CRM.

• You must ensure that any custom process flow that creates an order failure notification creates only one notification for each order failure.

• When an order revision from Siebel CRM fails upon arrival in OSM, a new trouble ticket for the revision is created, and any existing trouble ticket for the base order is preserved. You must manually close the trouble ticket for the revision that failed upon arrival.

For more information about the implementation of this flow, see Implementing the Create and Manage Trouble Ticket from OSM Flow.

About Order Fallout Management for Different Error Types

Oracle AIA manages order fallout for the following error types:

• System errors: Errors caused by infrastructure outages. See About Order Fallout Management for System Errors.

• Business errors: Errors caused by missing data. See About Order Fallout Management for Business Errors.

• Service: Errors caused by failed Oracle AIA services. See About Order Fallout Management for Service Errors.

About Order Fallout Management for Business Errors

Business failures are caused by business reasons unrelated to the Oracle AIA infrastructure. For example, a sales order that is missing critical data fails while being sent to Oracle Communications Billing and Revenue Management (BRM). Because the error occurs in the original message, you must revise the order in Siebel CRM to correct the error, then resubmit the order.

About Order Fallout Management for Service Errors

If an error occurs during an Oracle AIA service call, such as when an application business connector service (ABCS) calls an integrated application, the following occurs:

1. Detecting order fallout: An error occurs within an ABCS, it creates an error message, and the Oracle AIA error handling framework uses the message to create an enhanced fault message. See About Order Fallout Detection for more details.

2. Notifying someone of the fallout: For orders submitted from Siebel CRM, Oracle AIA creates a trouble ticket in Siebel CRM and Siebel CRM assigns the trouble ticket to a user and notifies the user. See About Order Fallout Notification for more details.

3. Correcting orders: The notified user resolves the issue and either resubmits the order or cancels it. See About Order Correction for more details.

About Order Fallout Detection

When an error occurs within any of the Oracle AIA order services, the ABCS creates an error message. The Oracle AIA Error Handling framework detects the error message and uses it to create an enhanced fault message that contains the following information:

• Faulting Service

• Error Code

• Error Severity

• Error Text

• Time of Failure

• Order ID

• Order Number

• Order Originating System Code

• Account ID

• Account Name

See Extending Fault Messages to Capture Order Fallout Information for more information about extending fault messages. See Oracle Fusion Middleware Infrastructure Components and Utilities User's Guide for Oracle Application Integration Architecture Foundation Pack for more information about the Oracle AIA Error Handling Framework.

The framework publishes the enhanced fault message to the AIA Error JMS topic, where the error handling listener picks it up. The listener submits the fault message to the order fallout services to create a trouble ticket in Siebel CRM.

Figure 2-15 illustrates order fallout detection when Oracle AIA initiates trouble ticket creation. When OSM initiates trouble ticket creation, the Oracle AIA error handling framework sends a notification to OSM, and OSM begins the process of notifying Siebel CRM.

Although the order can fail in any of the application tiers shown in the figure, this chapter discusses order failure only within Oracle AIA. Other applications and systems are outside the scope of the process integration for order fallout management.

Figure 2-15 Detection Flow from Oracle AIA for Order Fallout

Description of "Figure 2-15 Detection Flow from Oracle AIA for Order Fallout"

About Order Fallout Notification

Siebel CRM handles order fallout notification. After Oracle AIA sends an enhanced fault message to Siebel CRM and creates a trouble ticket using a web service operation, Siebel CRM processes the trouble ticket and assigns it to a fallout user according to the Siebel CRM assignment rules. Siebel CRM can create and send notification to the fallout user, who can then investigate the trouble ticket to correct the issue.

Figure 2-16 illustrates the process for order fallout notification.

Figure 2-16 Order Fallout Notification Flow

Description of "Figure 2-16 Order Fallout Notification Flow"

About Order Correction

After the trouble ticket is created in Siebel CRM and assigned to a fallout user, the fallout user can investigate the failure and correct the error to resolve the trouble ticket.

To correct errors in the base order, submit a revision order with updated data. The OSM Order to Activate cartridge closes any trouble tickets created to report the order fallout and fulfills the revision order.

Figure 2-17 illustrates the steps a fallout user takes to correct errors in a base order.

Figure 2-17 Siebel CRM Correction Flow for Order Fallout

Description of "Figure 2-17 Siebel CRM Correction Flow for Order Fallout"

To correct errors in the data from participating edge applications (such as BRM, Siebel CRM, or an inventory or activation system), update the data in the edge application and resume the order OSM in the central order management role (OSM COM).

For example, if an order fails because of bad billing profile information, correct the billing profile information in Siebel CRM. Oracle AIA synchronizes the changed information to BRM, and you can resume the order in OSM.

For errors that occur and are corrected in local fulfillment systems, submitting a revision order from Siebel CRM does not correct the error or close the trouble tickets. Because the revision order is identical to the base order, OSM ignores the revision. You must resume the order from OSM.

Figure 2-18 illustrates process of correcting order data errors in edge applications. The figure shows an option for updating the order status from the edge application, which sends the order update through Oracle AIA, and an option for updating the order status directly in OSM.

Figure 2-18 Local Correction Flow

Description of "Figure 2-18 Local Correction Flow"

Extending Fault Messages to Capture Order Fallout Information

Order Fallout Management uses the Oracle AIA error handling framework to capture order failure notifications when an ABCS or an Oracle AIA service fails.

For faults that occur within Oracle AIA, the fault messages contain all the required details of the failed order and do not require enrichment by the Oracle AIA error handling framework.

For faults that occur in edge applications, you must extend the messages to capture additional order failure information. See the discussion of extending fault messages in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for information about extending error handling.

Table 2-5 and Table 2-6 list the additional fields that you must add to the fault messages to capture order failure information.

Table 2-5 lists the order header-level fields to include in the fault messages.

Table 2-5 Order Header-Level Data

Field Name	Type	Description	Source	Optional
Order Originating System Code	ID	The system code of the Siebel CRM system from which the order was placed. It is required to cross-reference the IDs back to the appropriate Siebel CRM IDs.	Oracle AIA service	No
Sales Order Number	Alphanumeric	Alphanumeric identifier for the sales order number (Siebel CRM value).	Siebel CRM	Yes
Sales Order Revision Number	Numeric	Numeric field storing the sales order number (Siebel CRM value).	Siebel CRM	Yes
SalesOrderID	ID	Siebel CRM Sales Order ID. Required to create trouble tickets for the orders that fail even before hitting the central fulfillment system.	Siebel CRM	Yes
Account Name	AlphaNumeric	AlphaNumeric value identifying the Siebel CRM account name.	Siebel CRM	Yes
Account ID	ID	Siebel CRM Account ID. Required to create trouble tickets for the orders that fail even before hitting the central fulfillment system.	Siebel CRM	Yes
SalesOrderID (Common)	ID	Common Order ID. (Required when Oracle AIA creates the trouble tickets).	Oracle AIA service	No
AccountID (Common)	ID	Common Account ID.	Oracle AIA service	Yes
Order ID	ID	Alphanumeric identifier for the order. Assigned by fulfillment system to the order. The fulfillment system uses it to correlate the order back to the common order ID received for the original order. The common order ID is then mapped to the Siebel order ID by the Siebel ABCS.	Fulfillment System	No
Order Number	AlphaNumeric	User-friendly identifier for the order in the fulfillment system.	Fulfillment System	Yes
ProductID	AlphaNumeric	Alphanumeric identifier for the product used for the failed line or the product for the first order line in case of multiple line failures.	Siebel CRM or Oracle AIA service	Yes
Fulfillment System of Failure for Order	LOV	Part of the enterprise business object (EBO) header. Set to the fulfillment system in which the order failed. The Oracle AIA identifier for the fulfillment system is used.	Fulfillment system of Failure or Oracle AIA service	No
Service of Failure / FailureSubSystem	LOV	Identifies the Oracle AIA service, web service, application programming interface (API), or SubSystemCode (if available) where the order failed.	Fulfillment System of failure or Oracle AIA service	Yes
Message	Alphanumeric	Used for the message (error, warning, or other). It can also be used to return notification to subscribers or other systems. Not to be confused with the original input order message.	Fulfillment System of failure or Oracle AIA Service	Yes
Error Code	Alphanumeric	Used to return the error code from the downstream fulfillment system (if any).	Fulfillment System of failure or Oracle AIA service	No
Error Severity	LOV	Used to return the error severity from the downstream fulfillment system (if any).	Fulfillment System of failure or Oracle AIA service	Yes
Processing Number	ID	Identifier of the job ID assigned in case of batch or bulk orders.	Siebel CRM	Yes
Processing Type Code	Code	Code to identify the job type.	Siebel CRM	Yes
Processing Quantity	Quantity	Job cardinality - Total number of orders within the job.	Siebel CRM	Yes

See Guidelines for Ensuring that Oracle AIA Processes are Fallout-Compliant for more information about how to pass this information from the edge application or Oracle AIA service to the process integration for Order Fallout Management.

Table 2-6 lists order line item level fields to include in the fault messages. when the Oracle AIA service or the edge application identifies a particular order line item as responsible for the order failure. For system faults caused by network issues or system unavailability, the order lines may not actually add value to the trouble ticket and are not required.

Table 2-6 Order-Line Item-Level Data

Field Name	Type	Description	Source	Optional
Order Line Item ID	ID	Unique identifier for the order item.	Siebel CRM	No
Message	Alphanumeric	Used for error message. It can also be used to return notification to subscribers or other systems.	Fulfillment system of failure or Oracle AIA service.	Yes
Error Code	Alphanumeric	Used to return the error code from the downstream fulfillment system (if any).	Fulfillment system of failure or Oracle AIA service.	No
Error Severity	Alphanumeric	Used to return the error severity from the downstream fulfillment system (if any).	Fulfillment system of failure or Oracle AIA service.	Yes
StatusContext	LOV	Used to capture status-related display information or status-related information that is product-dependent. It can also be used to capture the current milestone within the provisioning system for the service associated with the order item.	Fulfillment system of failure or Oracle AIA service.	Yes
FailureSubSystemCode	LOV	Subsystem code or API where the order line has failed. Applicable for participating applications. If the fault is within Oracle AIA, the service which faulted is assumed as the subsystem of failure.	Fulfillment system of failure or Oracle AIA service.	Yes

To extend error handling, at a high level:

1. Extend the Oracle AIA fault message to capture the additional information in Table 2-5 and Table 2-6.

2. Extend the common error handler to:

   • Identify when a fault message is related to order failures.

   • Stamp the error type in the fault message as a JMSCorrelationID and invoke the appropriate fault extension handlers (in case of a partner link fault).

   • Publish to the AIA Error JMS Topic.

3. Create the Oracle AIA order fallout listener (AIAOrderFalloutJMSBridgeService), which:

   • Listens to all messages published to the AIA Error JMS Topic.

   • Picks up the messages that are specific to order fallout by looking at the correlation ID that contains the error type stamped by the Oracle AIA Common Error Handler.

   • Persists the fault message into a fallout queue (AIA_ORDERFALLOUTJMSQ).

4. Create the AIACOMOrderFalloutNotificationConsumer listener for the Order fallout queue that routes the fault message appropriately to the process integration for Order Fallout Management to create the trouble ticket.

See "Configuring Oracle AIA Processes for Error Handling and Trace Logging," Extending Error Handling in Oracle Fusion Middleware Developer's Guide for Oracle Application Integration Architecture Foundation Pack for more information about extending error handling.

Exception Handling

If an error occurs while the listeners are preparing the message for the invocation of the Oracle AIA service, then a standard Oracle AIA error handling framework notification is posted to the Oracle AIA error handling framework.