Using Defaulting Rules in Oracle

Order Management
An Oracle White Paper
August 2000
revised November 2001
 Using Defaulting Rules in Oracle Order Management

EXECUTIVE OVERVIEW
Defaulting is the process by which values get into fields without someone having
to key them. In Release 11 and earlier, the Oracle Order Entry product contained
a feature called ‘Standard Value Rule Sets’ (SVRS) where you defined how you
wanted order attributes to be defaulted. In Release 11i Order Management, we
have a new defaulting paradigm called ‘Defaulting Rules’, which offers somewhat
differing functionality. This paper outlines the key differences between SVRS and
the new Defaulting Rules, with tips on how to use the new, more powerful
features.

INTRODUCTION
Users familiar with Order Entry’s Standard Value Rule Sets might look at Order
Management’s new Defaulting Rules framework and wonder ‘what happened
here?’. The user interface looks very different and very complex. And the
functionality seems to behave somewhat differently from the SVRS. The R11i
Order Management User’s Guide gives a good explanation of the new forms and
fields, but there are nuances of setup and use that are not obvious to the non-
technical reader or user.
This paper attempts to explain the key functional differences between the SVRS in
Order Entry and the Defaulting Rules in Order Management, and offer some
insight into making the rules work for you.

BACKGROUND
Standard Value Rule Sets provided great functionality for Order Entry users. But
they were very much tied to the architecture and functionality of the Order Entry
product. You could define sets of rules and attach them to order types. There
was a hard-coded list of sources for each particular data field. It was difficult to
extend or customize the rules.
In Order Management, the product architecture has been totally redone and the
product functionality has been greatly expanded. Every functional area had to be
re-designed and re-coded. Some of the enhancements that users had been
requesting in the area of SVRS could not be accommodated without revamping the
entire structure of defaulting. The design goal was to create a defaulting
framework that other products could use, too, since most applications need similar

Using Defaulting Rules in Oracle Order Management Page 1

capabilities. So the decision was made to design a more generic solution for
defaulting. The Defaulting Rules Framework is the result of that re-design.

FUNCTIONAL DIFFERENCES
To an Order Entry/Management user or implementer, the biggest difference from
SVRS is that with Defaulting Rules, you define a set of rules for each attribute on
the order header or line, and you define the conditions for when to use each rule.
This forces you to think of each attribute individually, instead of within the context
of an order type. But once you start thinking of attributes in this way, the new
framework seems more straightforward and intuitive.
The new framework also brings somewhat more flexibility in where you can
default from and to, as well as a way for you to invoke your own PL/SQL package
to perform more complex logic.

Key Enhancements
Some of the great new enhancements that this framework allows are:
• the ability to default the Order Type
• the ability to define defaulting rules for returns and return lines - they used to
be hard-coded.
• the ability to define formulas to create the defaulted data - see ‘Source of
Values’ section below.
• a clear distinction between ‘defaulting’ behavior and ‘cascading’ - see ‘Watch
Out For’ section below.

Terminology
Since Defaulting Rules are now generic, and potentially can be used by other
Oracle applications, we’re using more generic names for the things you default
from and to. ‘Attributes’ and ‘Entities’ are the things you default to. ‘Sources’ are
where things default from. See ‘Source of Values’ section below on all the various
places you can default from.

Attributes and Entities in Order Management

An ‘Entity’ in this context is a group of related attributes that roughly correspond
to a table or a form in Order Management. So we have ‘entities’ of Order Header,
Order Line, Order Price Adjustment, Line Price Adjustment, etc. Entities
correspond to ‘blocks’ in the old SVRS.
An ‘Attribute’ is a field or column that belongs to that entity. Therefore, the
‘ordered unit of measure’ is an attribute of the ‘Order Line’ entity. Attributes
correspond to ‘fields’ in the old SVRS. When you query up the Defaulting Setup
form for a particular entity, you’ll see a list of all the attributes for which you can
define defaulting rules. As in OE, you will not be able to define defaulting rules

Using Defaulting Rules in Oracle Order Management Page 2

 for descriptive flexfields, since their defaulting is controlled by AOL’s flexfield
routines.

Conditions
‘Conditions’ are rules you set up that will control when a particular group of
default sources will be looked at. You define one or more ‘condition validation
templates’ based on whatever common business rules you may have. You define
one or more of these condition templates per entity, and then you can use them over
and over for the attributes of that entity. For example, then, you might set up a
condition template for all return lines, or another one for all internal order lines.
The ALWAYS condition is seeded for each entity. If you are defining a set of
Conditions and using them in rules, be sure to place the ALWAYS condition last
in the Precedence for Defaulting Conditions.

Defining Condition Validation Templates

Once you query up the entity that you want to work with in the Defaulting Setup
Here is how you define Defaulting
form (use the flashlight icon to get the LOV of available entities), press the
Condition Templates.
Defaulting Condition Template button to get to the form to define the conditions.
You’ll see a form that lists all the conditions already defined for this entity. To add
a new one, go to a blank line (or use the green + icon to create a blank line) and
key in a name and description for your new condition.
The lower half of the form is where you enter the details of the condition you are
defining or viewing.
• The Group Number is just an arbitrary number you enter to control ‘and’
and ‘or’ conditions. You indicate that rules are to be connected by an ‘and’
rule by giving them the same group number, whereas rules you want to be
connected by ‘or’ should be given different group numbers.
• In the Attribute column, choose from the list of attributes you can base a
condition on. Available attributes that show up here are ones from this
entity that have the ‘Include in Building Defaulting Conditions’ checkbox
checked on the Defaulting Setup - Entity Attributes form. The only
attributes that have this checkbox checked are ones that are the source for a
dependency relationship. See section on Dependencies below. And you
cannot add to this list of attributes.
• In the Operator column, choose an operator from equal, not equal, greater
than, less than, not greater than or not less than.
• In the Value String column, key in (or choose from the LOV) the actual
value you want to compare to.

Sequence of Defaulting
On the main Defaulting Setup screen, where all the attributes of the entity are
listed, there is a column called ‘Defaulting Sequence’. This number determines the

Using Defaulting Rules in Oracle Order Management Page 3

order in which attribute defaulting takes place. When attributes have equal
sequence numbers, defaulting takes place alphabetically. All the attributes are
seeded with a sequence of 50. You can change these sequences, if you need
defaulting to happen in some different order. For example, you might define a
sourcing rule that says default attribute A on the line from attribute B on the same
line. In this case, you need to insure that the Attribute B gets its value before A is
defaulted, or the rule will not work as you expect.

Sources of Values
‘Sources’ are places where values can be defaulted from. Defaulting Rules provide
a variety of sources that you can use in building your defaults. Most of them will
be familiar to users of Oracle Order Entry.
• Constant Value - is simply a text string that will be used.
• Profile Option - is the value of a profile option. This can be a system
provided profile option, or a new profile option that you’ve defined just to
provide a defaulting value.
• Same Record - is the value of another attribute on the same entity (or record)
as the attribute you are defining the rule for. For example, you might set up
the Promise Date to default from the Request Date on the same line.
• Related Record - is the value of another attribute on a related entity (or
record). For example, you might set up the Ship Method on the line to
default from the Ship Method on the header. Or some attribute on the
order header might default from an attribute on the related customer record.
• System Variable - is the value of a system (server) variable, such as System
Date. For this type of source (and this type only), you can use an expression
containing a formula, for example, sysdate + 7.
• PL/SQL API - is where you provide your own routine to provide the
default. There are a few seeded defaulting rules that use this - for example,
defaulting of the currency on the order header from the set of books (SOB)
is seeded this way. . You can look at this attribute for an example of how to
specify a PL/SQL API or you can look in the ‘Rule Based Defaulting
Framework’ HLD for technical details.
• others - there are several esoteric source types relating to the Web App
Dictionary definitions for this attribute. Most people won’t want to use
these. They are documented in the ‘Rule Based Defaulting Framework’
HLD, if you really want to know.

Using Defaulting Rules in Oracle Order Management Page 4

 Defining Sourcing Rules
Here is how you define Default Sourcing
Rules.
Once you query up the entity that you want to work with in the Defaulting Setup
form and have defined your Conditions, you are ready to define your Sourcing
Rules. Select the attribute you want to work on, and then click on the Defaulting
Rules button to get to a form called Attribute Defaulting Rules. This form lists all
the conditions and rules that have been previously defined for this attribute. To
add a new condition and its rules, go to a blank line in the Defaulting Conditions
section of the form (or use the green + icon to create a blank line) and key in a
precedence and choose from conditions you have already defined. (The
precedence controls the sequence in which the conditions are evaluated.)
The lower half of the form is where you enter the details of the rule you are
defining or viewing for this condition. This set of defaulting rules will be used if its
corresponding Defaulting Condition is TRUE.
• The Sequence here controls the order in which the system attempts to locate
a default.
• In the Source Type column, choose from the list of Source Types as
described above.
• In the Default Source Value column, you specify the attribute or value you
want to use for the source. What you can choose here depends on the
Source Type you have selected. There is a good table in the Setup section of
the Oracle Order Management R11i User’s Guide that explains the various
options per Source Type. What you’ll see in this field is a flexfield whose
context is based on the Source Type. Then you can choose among pre-
seeded possible source attributes.
Similar to what occurred in Order Entry, you can’t default things from just
anywhere. The data type has to match that of the attribute you are defaulting, and
the source relationship has to be pre-defined.

Dependencies
Some attributes are dependent upon the value of other attributes on the same
record. If an attribute is changed, either by the user or by the system, any other
attribute that is dependent on it will be cleared and then re-defaulted. For
example, the Price List is dependent on Agreement. If the Agreement is changed,
the Price List will be cleared and re-defaulted. As of September 2000 (available via
patch for bug 1343621), functionality was changed for certain fields such that if re-
defaulting did not come up with a default for the dependent field, the old value
would be retained instead of clearing that value. These fields are: Price List,
Salesperson, Customer PO number, Order Type.
In the initial implementation of Defaulting Rules, dependencies are hard-coded.
See the ‘Rule Based Defaulting Framework’ HLD for a list of which dependencies
have been provided. Alternatively, you can also check current code in the

Using Defaulting Rules in Oracle Order Management Page 5

hardcoded dependencies package - OE_Dependencies (file:
$ONT_TOP/patch/115/sql/OEXUDEPB.pls) to get the latest list.
An enhancement request has been logged (1201256) to provide a form to allow
users to create their own dependencies. Until such time as that enhancement is
provided, if you need to create additional dependencies or disable existing
dependencies that you do not need, you can add code in a simple API hook -
package OE_Dependencies_Extn (the file name is
$ONT_TOP/patch/115/sql/OEXEDEPB.pls).
Adding dependencies via this hook is supported as long as the guidelines
documented in the file are followed. Following the guidelines also ensures that
patches do not over-write the changes introduced by users.
However, please note that:
i) The list of source/dependent attributes that can be used to setup the
dependencies is restricted. Please refer to comments in file OEXEDEPB.pls for
the complete list.
ii) Dependencies can be established only among attributes on the same entity, not
across entities i.e. changing an attribute on order header will NOT result in a
change to attributes on order line.

The code modifications are relatively easy. Below are examples to add to remove a
dependency.
Add a Dependency
User sets up a defaulting condition based on Order Type ‘A’ and uses this
condition to default Salesperson ‘A’ if Order Type is ‘A’. For this rule to work, a
new dependency needs to be enabled. The Source Attribute is Order Type, and
the Dependent Attribute is Salesperson. The entity on which this dependency
needs to be defined is Order Header so add the dependency code under the IF for
header entity.
IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
x_extn_dep_tbl(l_index).source_attribute := OE_HEADER_UTIL.G_ORDER_TYPE;
x_extn_dep_tbl(l_index).dependent_attribute := OE_HEADER_UTIL.G_SALESREP;
x_extn_dep_tbl(l_index).enabled_flag := 'Y';
l_index := l_index + 1;

Disable a Dependency
Updating Ship To on the order header results in Invoice To being cleared and/or
updated. The user deleted/disabled the defaulting rule to default Invoice To from
Ship To and still the behavior does not change. The reason is that there is a
hardcoded dependency of Invoice To on the Ship To field. To ensure that Invoice
To is not affected by a change to Ship To, the dependency of Invoice To on Ship
To should be disabled via this new hook. Source Attribute: Ship To; Dependent

Using Defaulting Rules in Oracle Order Management Page 6

Attribute: Invoice To.
IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
x_extn_dep_tbl(l_index).source_attribute := OE_HEADER_UTIL.G_SHIP_TO_ORG;
x_extn_dep_tbl(l_index).dependent_attribute :=
OE_HEADER_UTIL.G_INVOICE_TO_ORG;
x_extn_dep_tbl(l_index).enabled_flag := 'N';
l_index := l_index + 1;

If it is also required that updating Ship To should not change the value of Invoice
To on the order Line, the dependency should be separately disabled for the Line
entity.
ELSF p_entity_code = OE_GLOBALS.G_ENTITY_LINE THEN
x_extn_dep_tbl(l_index).source_attribute := OE_LINE_UTIL.G_SHIP_TO_ORG;
x_extn_dep_tbl(l_index).dependent_attribute := OE_LINE_UTIL.G_INVOICE_TO_ORG;
x_extn_dep_tbl(l_index).enabled_flag := 'N';
l_index := l_index + 1;

If, on the other hand, you want to create a dependency for a source or a dependent
attribute that is not listed in OEXEDEPB.pls, you have to do a little more.
This requires CUSTOMIZATION of existing packages. Patches in the future
might over-write your changes.

Adding a new Source Attribute:

For example, you want to make Shipping Method on the header dependent on
Shipment Priority. First you need to add a dependency in OEXDEPB.pls as
above with Source Attribute: Shipment Priority; Dependent Attribute: Shipping
Method. Since Shipment Priority is not listed as one of the source attributes
available on Order Header, you also need to CUSTOMIZE another entity specific
utility package.

Add the following statement in OE_Header_Util.Clear_Dependent_Attr (file:

OEXUHDRB.pls). If you want a change in the Shipment Priority on the order
line to also affect Shipping Method on the order line entity, code similar to the
following needs to be added to OE_Line_Util_Ext.
IF NOT OE_GLOBALS.Equal(p_x_header_rec.shipment_priority_code
,p_old_header_rec.shipment_priority_code)
THEN
l_index := l_index + 1.0;
l_src_attr_tbl(l_index) := OE_HEADER_UTIL.G_SHIPMENT_PRIORITY;
END IF

Using Defaulting Rules in Oracle Order Management Page 7

Adding a new Dependent Attribute:
For example, you may want Planning Priority on the line to be default based on
Demand Class. Again, you need to add a dependency in OEXDEPB.pls as above
with Source Attribute: Demand Class; Dependent Attribute: Planning Priority. If
Demand Class is not listed as one of the source attributes available on Order Line
entity, you need to go through the steps outlined earlier to add it as a source
attribute. And if Planning Priority is not listed as one of the dependent attributes
for order line entity, you also need to CUSTOMIZE another section of the entity
specific utility package.

First, add the following sub-procedure in OE_Line_Util_Ext.Clear_Dependents

(file: OEXULXTB.pls).
PROCEDURE PLANNING_PRIORITY IS
BEGIN
IF (p_initial_line_rec.PLANNING_PRIORITY = FND_API.G_MISS_CHAR
OR OE_GLOBAlS.Equal(p_initial_line_rec.PLANNING_PRIORITY
, p_old_line_rec.PLANNING_PRIORITY))
THEN
p_x_line_rec.PLANNING_PRIORITY := FND_API.G_MISS_NUM;
END IF;
END PLANNING_PRIORITY;

Note that for VARCHAR2 fields, you should replace G_MISS_NUM with
G_MISS_CHAR & for DATE fields, it should be G_MISS_DATE.
You also need to add a statement in the big IF loop in the main procedure to call
this new sub-procedure:
ELSIF l_dep_attr_tbl(I) = OE_LINE_UTIL.G_AGREEMENT THEN
AGREEMENT;

For adding dependent fields on Order Header entity, follow the above steps & add
similar code in header utility package - OE_Header_Util (file: OEXUHDRB.pls).

Controlling Changes
In Order Entry SVRS, there used to be two checkboxes on each rule line where
you could control changes to an attribute. You could check whether or not to
allow users to override a defaulted value (Override Allowed) and you could
control whether the rules should re-default over user-specified values (Override
User-Specified Values). These checkboxes often were viewed to be confusing and
to operate inconsistently. Order Management’s Defaulting Rules solved that
problem by getting rid of those checkboxes. Instead, you control who can change

Using Defaulting Rules in Oracle Order Management Page 8

data (and when) using the new Processing Constraints framework, regardless of
how or whether an attribute was defaulted. In addition, you have the ability when
you define Processing Constraints to indicate that you want the system to be able
to update an attribute, but a user cannot make changes.
The only time that Defaulting Rules result in a change to an existing attribute on
an entity is when that attribute has a dependency on another attribute that has
been changed.

Reports
There is a new report in Order Management that you can use to list the Defaulting
Rules you have set up. It replaces the old OE ‘Standard Value Rules Listing’. The
report is called ‘Defaulting Rules Listing’, and it has parameters to allow you to
limit the listing to a specific object (entity), attribute or condition.

WATCH OUT FOR

Here are some differences and limitations that you will need to understand:

Creating Conditions
Conditions give you powerful flexibility in designing how you will implement
defaulting for your company. However, there are a few behaviors to take into
consideration when creating Conditions.

What Attributes can you use?

Be aware that Conditions you create for an entity can only be based on attributes
that belong to that entity. Therefore, for example, you cannot set up a Condition
for a line attribute based on the order type because order type is a header attribute.
You’ll have to examine carefully your business rules so you can state Conditions in
terms of attributes on the same level. Fortunately, in Order Management, most
attributes (with few exceptions such as order type and currency) at the header are
also present at the line level. Even the sold-to customer is present as a line-level
attribute, even though the software enforces that the customer is the same
throughout an order. This way, the customer can be used in a condition template
for the line.

Sequencing of Attributes Used in Conditions

Sequencing of defaulting of attributes plays an important role in the correct design

of Conditions and Sourcing Rules. If you create a rule for attribute X based on a
Condition using attribute Y, you must be sure that attribute Y gets defaulted
before attribute X, or your Condition will not evaluate true. For example, if you
define a Condition for defaulting the Unit of Measure by using the Customer, it
will only work if you ensure Customer gets defaulted before UOM. And even
then, it will only work for the initial defaulting of the UOM field. And that is
because of Dependencies.

Using Defaulting Rules in Oracle Order Management Page 9

Dependencies of Attributes Used in Conditions

So you must also regard dependencies when you are building Conditions. If a
Condition involving attribute Y is used to setup the defaulting rule for attribute X,
then the rule will work during subsequent updates of attribute Y only if attribute X
is dependent on attribute Y. So in the UOM and Customer example above, if you
later change the Customer on the order, the UOM will not re-default based on the
new customer, because UOM is not dependent on Customer.

Defaulting vs. Cascading

In Order Management, a clear and unambiguous distinction has been made
between ‘defaulting’ and ‘cascading’, which will cause behavior different from what
we have become used to in R11 Order Entry. In OE, defaulting and cascading
were intermixed, making it sometimes difficult to predict what might happen when
an attribute at one level was changed. In OM, the defaulting logic will come into
play only when the record is initially created (when you click on a new record on
the form), or when an attribute upon which this attribute is dependent is changed.
Cascading, on the other hand, means replicating the value of an attribute down to
lower level entities. We do not perform cascading in Order Management. If you
want to change the value of attributes on existing rows, you need to use the new
mass change capability, where you multi-select the rows you want to change, and
then change them.
So what does this mean in real life? Here’s an example. Assume you have a
defaulting rule set up to default a line-level attribute such as Ship Method from the
header to the line. You create an order with several lines and use Ship Method A
for the header (and therefore the lines). Then you want to change the ship
method to Ship Method B. Changing this attribute at the header will result in any
subsequent new lines getting Ship Method B defaulted onto them. The existing
lines that have Ship Method A will not get changed to B as a result of your
changing the header attribute. You will need to use mass change to do that. The
good news is that the user has explicit and unambiguous control over what lines
get changed.

MIGRATION/UPGRADE FROM SVRS

Because of the magnitude of the changes to the fundamental architecture between
SVRS and Defaulting Rules, the decision was made to not upgrade any user-
defined SVRS. Defaulting Rules have been seeded that provide equivalent
functionality to the R11 seeded SVRS. There is a good table in Appendix E of the
Oracle Order Management R11i User’s Guide that lists all attributes of the Order
Header and Order Lines entities, and what the seeded defaulting rule is for each of
those attributes.

Using Defaulting Rules in Oracle Order Management Page 10

Users of Order Entry who created their own Standard Value Rules or customized
the seeded rule sets will need to carefully review the logic behind their changes or
customizations, and create equivalent Defaulting Rules for the attributes affected.
Typically a user will need to create Conditions corresponding to their particular
business need, and then create Defaulting Rules using those Conditions for the
necessary attributes.

EXAMPLE
All right now, let’s see how you can use Defaulting Rules in real life. Let’s take the
example of a very common business need - the need to default the Order Type
based on customer (sometimes) and otherwise based on user. This was something
that could not be done using SVRS in Order Entry. Order Type was one of those
things that always had to be keyed or selected from an LOV. But in Order
Management, you can write rules to default the Order Type.
Here’s the business requirement:
Some of your customers have such special processing requirements, that you have a
special order type set up just for them - all their orders generally are of that order type.
As a matter of fact, a bill-to location or a ship-to location of a customer might even
need to have its own special order type. However, for the general case, you would like
users in various departments to always enter orders of a particular type - Domestic
CSRs might enter orders of Order Type ‘Domestic’, whereas your Export Department
personnel might enter orders of Order Type ‘International’.
Here’s how you’d do this:
• First, create a new custom profile option that you’ll have the system
administrator use to specify the default order type for different
responsibilities or users.
• Second, create defaulting rules for entity: Order Header, attribute: Order
Type. Use the seeded condition ALWAYS, as you want to just set up one
set of rules. Have the defaulting precedence be:
5 Related Record Invoice-to: Order Type
10 Related Record Ship-to: Order Type
15 Related Record Customer: Order Type
20 Application Profile OMX: xxxxxxx (your new profile option)

• Finally, for customers with special order type needs, store their special order
type in their Customer, ship-to or bill-to record as required. You would
leave this field null for most customers, to let the profile option be used.
Then, as a customer is entered on an order, the defaulting code will look first at the
customer bill-to site for a default order type, then to the ship-to record, then to the

Using Defaulting Rules in Oracle Order Management Page 11

customer header, and finally to the new profile option.
For a closer look at exactly how to perform these setup steps, see the Defaulting
Demoshield in the OM Toolbox - it contains an example of setting up these exact
rules.

CONCLUSION
Oracle Order Management’s use of the new Defaulting Framework provides
powerful defaulting capabilities, if you know how to use them. You need to
thoroughly understand Conditions and Dependencies so that you can design how
your defaulting should occur. With correct definition and use of Defaulting Rules,
you can significantly reduce the amount of data that has to be keyed upon entering
an order, thus speeding input time and reducing keying errors.

Using Defaulting Rules in Oracle Order Management Page 12

Using Defaulting Rules in Oracle Order Management
August 2000
Revised September 2000 and November 2001
Author: Charlene Chandonia
Contributing Authors: Nithya Lakshmanan, Linda Henry

Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
U.S.A.

Worldwide Inquiries:
Phone: +1.650.506.7000
Fax: +1.650.506.7200
Web: www.oracle.com

This document is provided for informational purposes

only and the information herein is subject to change
without notice. Please report any errors herein to
Oracle Corporation. Oracle Corporation does not
provide any warranties covering and specifically
disclaims any liability in connection with this document.

Oracle is a registered trademark, and Oracle Order Management is a

trademark(s) or registered trademark(s) of Oracle corporation.
All other names may be trademarks of their respective owners.

Copyright © Oracle Corporation 2000

All Rights Reserved