This chapter covers the following topics:
This chapter describes setup tasks that you must perform in Oracle Order Management (OM) that are specific to the Oracle Telecommunications Service Ordering (TSO) solution.
Among the Oracle Applications that are directly a part of the Oracle TSO solution, there are no dependencies to setting up Oracle Order Management. It is recommended that you set up Oracle Order Management first.
It is assumed, however, that Oracle Accounts Receivable has been implemented, or that your implementation has access to the APIs provided by Oracle Accounts Receivable.
Following is the setup checklist for implementing TSO-specific functionality for Oracle Order Management:
| Setup Step | Required/Optional |
|---|---|
| Implement Oracle Order Management | Required |
| Map Actions and Line Types | Required |
| Enable Recurring Charges | Required |
| Enable Payment Due with Order | Optional |
| Set Profile Options | Required |
| Assign Workflows to Transaction Types | Required |
| Set Up Additional Line Types | Optional |
| Create SFM-Enabled Order Header and Line Workflows | Optional |
| Remove the Fulfill Node in the OM Line Workflow | Optional |
For more information on setting up and using Oracle Order Management, refer to:
Oracle Order Management Implementation Manual
Oracle Order Management User's Guide
As an implementation requirement, map all Actions and Line Types associated with the Oracle Configurator Line Type Configurator Extension to the Order Line Type in Oracle Order Management Transaction Types setup.
Products with one-time and recurring charges are entered on separate transaction lines in the sales order. A folder-enabled column, labelled Charge Periodicity Code, is available on the order line to store and display the charge periodicity. Charge periodicity is the interval by which the price for a recurring charge has been set up on a price list (e.g., Monthly, Quarterly, Yearly). The charge periodicity indicates how often the customer account is charged. Order lines with a charge periodicity are considered recurring charge lines. Order lines without a charge periodicity are considered one-time charges. When ordering an item with a recurring charge, the charge periodicity is defaulted on the order line from the item master using the defaulting rules. For one-time charges (i.e., lines without a charge periodicity), the charge periodicity column displays as blank.
Setup of recurring charges in Oracle Order Management involves the following steps:
Set an Order Management profile option.
Set an Order Management system parameter.
Specify charge periodicity for items with recurring charges.
Modify UI to show charge periodicity.
See the sections below for more information.
Set the profile option, OM: UOM Class for Charge Periodicity, to Period. See the section, "Set Profile Options", later in this chapter for more details.
The Oracle Order Management system parameter, Enable Recurring Charges, controls the recurring charge feature and cannot be disabled once the parameter is set/enabled. Set the parameter to Yes. Consult the Oracle Order Management Implementation Manual for instructions detailing how to set system parameters.
For each TSO item requiring the use of recurring charges, specify the periodicity of the item. For these types of items, the periodicity is the unit of measure.
Steps
As Order Management Super User, navigate to the Master Items window and query the item.
In the Order Management tab for the item, specify a value of Monthly (or another value, as appropriate) in the Charge Periodicity field.
Modify the UI to display charge periodicity elements:
Add the Charge Periodicity field to the folder in the header block and line blocks in the Sales Order and Quick Sales Order forms (Oracle Order Management forms).
Add the Charge Periodicity field to the line region in the Order Details page using personalization (Order Information Portal).
For more information, refer to the Oracle Order Management Implementation Manual and the Oracle Application Framework Personalization Guide.
This section covers the high-level steps to enable Payment Due with Order functionality. Note the following:
A line is considered a pay now line if the pay now portion of the line is greater and 0 (zero).
The pay now payment term must have at least one installment with 0 (zero) days due.
A pay now portion of an order line is a sum of all installments with 0 (zero) days due.
The pay later payment term must have all installments with days due greater than 0 (zero).
Setting up Payment Due with Order involves defining business logic that will determine the “pay now” amount on an order. The following tasks must be performed:
Set an Order Management system parameter.
Set up payment term or terms.
Set up defaulting rules.
Set up credit checking rule.
Set item attributes.
Assign line workflows
Set up taxes.
Expose fields in the Order Management UI.
Set the Oracle Order Management system parameter, Installment Options, to Enable Pay Now. This system parameter was previously called Authorize First Installment Only. The system parameter cannot be changed if it is already set to Enable Pay Now or Authorize First Installment. The following table shows the implications of the various settings of the parameter.
| Parameter Value | Implication |
|---|---|
| Enable Pay Now | Enables Payment Due with Order functionality. |
| Authorize First Installment | Only the first installment of a payment is authorized. The amount authorized will be total of the first installment less down payment, if applicable |
| None | Does not enable the Payment Due With Order and Authorize First Installment functionality |
Set up a payment term in for Payment Due with Order. Payment terms that have one or more installments with Days Due set to zero will be used to identify the Payment Due with Order order lines.
Steps
As Order Management Super User, navigate to Setup, Orders, Payment Terms.
Enter a name for the payment term (e.g., Pay Now).
In order for the payment term to be a "pay now" payment term, ensure that no installment is allowed. You specify this by entering 0 (zero) in the Days Due field in the Payment Schedule region).
The item-level payment term determines if an order line is included in the Payment Due with Order amount. If the line is to be included in the Payment Due with Order amount, then the payment term should have Days Due set to zero. Implementers can set up a defaulting rule to automatically specify the line level payment terms based on business rules. Additionally, the sold-to customer type can be used to default different payment terms for B2B customers versus B2C customers.
Steps
As Order Management Super User, navigate to Setup, Rules.
Choose the Defaulting Application Name as Order Management.
Query for the Order Line entity and Payment Term attribute.
Set the Defaulting sourcing rule to Related Record.
Select the defaulting rules button.
Set the default source/value, related object to Inventory Item and related record to Payment Term.
Implementers also should set up defaulting rules to default Credit Card as the payment type. The payment type, Credit Card, is seeded so that processing can be immediate (non-deferred). To ensure that credit card is authorized at booking, the Defer Payment Processing Flag should be set to No.
Specify the credit check rule at ordering for the transaction type being used for the order, so that credit card can get authorized.
Steps
As Order Management Super User, navigate to Setup, Credit, Define Credit Check Rules.
Either create a credit check rule or use an existing one and specify this credit check rule in the transaction type for the order.
For each TSO inventory item that will have a Payment Due with Order amount, set the Payment Terms field to the Pay Now payment term. Also, enable the Invoiceable Item and Invoice Enabled check boxes.
Assign the following workflow processes to the line transaction types that will be used:
Line Flow - Generic, Bill Only with Payment Assurance
Line Flow - Generic, with Payment Assurance
Consult the Oracle Order Management Implementation Manual for instructions.
To include tax in the pay now portion, set up the tax to be calculated at the entry point. And tax should not be set up to be "inclusive" in the lines.
Using folder modification technology available in Oracle Forms, implementers can modify the UI to display Payment Due with Order amount elements. Following are the suggested modifications for Payment Due with Order functionality. Add the First Installment fields and the Due with Order checkbox to the header folders in the Payments and Line Payments forms.
Quick Sales Orders form: Add the Initial Due Balance field in the order folder under the Main tab
Payments form (available from the Quick Sales Orders form):
Add the Due with Order checkbox.
Add the Initial Due Subtotal, Tax, Charges, and Total fields.
Set the profile options listed in this section.
This profile option indicates which Oracle application software is launched to enter configuration information when selecting the Configurator button from the Sales Order window. Set to Yes to integrate with Oracle Configurator in the Oracle TSO Solution. For more information, see the Oracle Order Management Implementation Manual.
Set the profile option, OM: UOM Class for Charge Periodicity, to Period. This profile option specifies which unit of measure (UOM) class stores the available charge periodicities.
When a header attribute is updated and the lines are entered, any header changes are cascaded down to the lines. In the reconfiguration flow, the header information will be derived from the item instance that was selected, together with any Oracle Order Management defaulting rules. Because the header information defaults from the information available for the selected item instance in the installed base, there is a high possibility that the header information will need to be updated after the order is created. For this reason, it is necessary to provide an option to cascade many of the changes to the order header to the respective fields on the order line of the order. The profile option, OM: Sales Order Form: Cascade Header Changes to Line, determines the cascading behavior. Following are the profile option settings:
Automatic: The system cascades the header attributes to lines whenever a header attribute is cascaded
Askme: The user is given a choice to cascade or not
Manual: The user must manually change the values for the attributes on the lines; the system doesn’t cascade the changes from header to lines.
You can set up additional customized Line Types for reconfigurations.
For instructions on how to set up additional Line Types, refer to the steps for defining Transaction Types in the Oracle Order Management Implementation Manual. For information on setting up the Line Type that ensures that orders pass into Oracle Service Fulfillment Manager, see the Oracle Service Fulfillment Manager Implementation Guide.
For more information on related TSO setup for Line Types, see the section, "Line Type Configurator Extension", in the chapter, Set Up Oracle Configurator Extensions.
The Fulfill activity is an OM Order Line activity that calls the PL/SQL procedure named OE_FULFILL_WF._FULFILLMENT to perform fulfillment for an order line. The Fulfill activity contains the following attributes:
Fulfillment Activity Name
Completion Result
Inbound Fulfillment Activity Name
Inbound Completion Result
The Fulfill activity coordinates the fulfillment of lines so that they progress together to invoicing. It applies to Models and kits (shippable and non-shippable lines), fulfillment sets, and service lines attached to goods. The Fulfill activity also derives and stores additional data needed for Oracle Daily Business Intelligence (DBI) and service lines. The Fulfill activity is contained in the seeded data file, oexwford.wft, and is associated with the OM Order Line item type. Note that in WF, Fulfill is an “activity” and not a “node”.
This step is required only if you are using Oracle Service Fulfillment Manager (SFM).
To enable the flow of order from Oracle Order Management to Oracle Service Fulfillment Manager, you must make some required customizations to Oracle Order Management's Workflow processes. This enables fulfillment of provisionable items from Oracle Order Management by way of SFM. For more information, see the chapter, Set Up Oracle Service Fulfillment Manager.
Removing the Fulfill node in the Oracle Order Management line workflow is optional.
The Fulfill node does the following:
Performs a gating activity for Components of a configuration.
Ensures that all the lines in a configuration are fulfilled together.
As a consequence of the gating activity, the update of Oracle Installed Base occurs only after fulfillment of all the Components of a configuration. In the business-to-business communications world, especially in the data services like Frame Relay, provisioning of Components may occur days or months apart from each other.
Because of the gating activity of the Fulfill node in the Order Management line workflow, the updating of installed base does not occur until provisioning of all the Components of the configuration occur. For example, this might be three months after provisioning the first Component. This can result in the installed base not accurately reflecting all of the customer's current services. To avoid this issue, it is recommended that you replace the Fulfill node with one that stamps fulfilled flag, the fulfillment date, and the fulfillment quantity for each order line.
Oracle Installed Base does not process an order line without a fulfillment date. It is essential that if you remove the Fulfill node, you replace it with a node that stamps the fulfilled flag, the fulfillment date, and the fulfilled quantity of each order line.
You should replace the Fulfill node only if your implementation requires that the order lines of a Container Model are fulfilled independently of each other.
For more information, see:
Oracle Order Management Implementation Manual
Oracle Order Management User's Guide
Keep the following design tips in mind as you implement and use the Oracle TSO Solution with Oracle Order Management:
You cannot reconfigure Container Models after booking. You can always reconfigure Container Models when the order is in the negotiation phase. If the order is in the Entered state, you can reconfigure Container Models only if the line workflow that is attached to the line types is the same. For more information, see the appendix, Assumptions and Restrictions.
Payment terms that have one or more installments with days due equal to zero are used to mark pay now order lines.
A payment term may consist of pay now and pay later portions.
Implementers should define their defaulting rules to assign payment terms to order lines. The seeded Party Type is a defaulting attribute that can be used in the condition template, since it is common that the party type of the customer (B2B or B2C) determines if an amount on an order line needs to be paid now or not. Party Type is available on the order header and the order line.
The warehouse for a recurring charge line should not be changed during the reconfiguration flow. Thus, if a recurring charge line had warehouse W1 during the initial configuration, then it should have W1 during the reconfiguration process.
The workflow needs to be modified for the disconnect flow of a shippable line, so that it doesn’t interface to shipping.