Implementing Defaulting Rules and Processing Constraints in Order

Management
Matthew McPeak

Tempus Consulting Group

Introduction
To help maximize the efficiency and accuracy of users, Order Management provides two complementary
features: Defaulting Rules and Processing Constraints.
Defaulting Rules allow you to configure Order Management to automatically populate fields based on
business rules and configurations, reducing the amount of information that users must enter manually.
Processing Constraints allow you to define rules so that, when manual user entry is required, users are
constrained to making only those changes that are consistent with your established business rules.
These features, working together, allow your users to enter sales orders and returns as quickly and as
accurately as possible.
This paper provides a through treatment of both features, covering both the functional setups and the
technical work required to implement and make the most of these powerful features.

Defaulting Rules Overview

A Defaulting Rule on a field is an ordered set of Conditions, each containing an ordered set of Default
Sources.
To derive the default value for a field, Order Management will evaluate each condition in order. For each
condition that applies to the fields record (e.g., to the order header or order line), Order Management
will evaluate each default source in order. The first default source that returns a non-blank value will be
the fields default value.
For example, Oracles seeded defaulting rules cause the Price List field to be defaulted from the
associated agreement, if present. If not present, it comes from the Ship To Customers price list. If that is
not present, it comes from the Order Types price list. The screenshot in Figure 1 indicates how this is set
up.

COLLABORATE 14

Page 1

Figure 1

Defaulting Condition Templates

(Setup Rules Defaulting (B) Defaulting Condition Templates)
Before setting up defaulting rules, you may need to define one or more Condition Templates that will
control when your rules apply.
For example, before you can define rules to control how fields default on, say, Export orders, you need
to define a Defaulting Condition Template to tell Order Management what an Export order is.
In Figure 2, we see how this is done. The Export Order condition will be true for any order or return
where the Order Type is between Export Abu Dhabi and Export Yemen.
Notice that both rules share the same Group # (i.e., 10). Rules that have the same Group # are
considered an AND condition. Sets of rules that have different Group #s are evaluated with an OR
condition. This is important! If the rules in Figure 2 were in different groups (say, 10 and 20), then
the Condition Template would be true for any order or return where either of the rules were true (and
that would be every single sales order and RMA, in this case).

COLLABORATE 14

Page 2

Figure 2

Also note the inexact way that the rule is built. For example, this rule will have to be modified if our
business ever starts exporting products to Zimbabwe.
A more flexible way to work might be to register an Is Export Order? DFF on the Order Type and build
the Defaulting Condition Template using that DFF. Unfortunately, this is not possible. Defaulting
Condition Templates can only be built using simple comparisons (equals, not equals, greater than, less
than, etc) with core attributes of the entity to which the rule applies.
For example, for the Order Header entity, you may only build Defaulting Condition Templates on these
fields:

Accounting Rule
Accounting Rule
Duration
Agreement
Bill To
Booked
Cancelled
Created By
Currency
Customer
Deliver To Org

COLLABORATE 14

Demand Class
FOB Point
Fulfillment Set
Invoicing Rule
Line Set
Open
Order Source
Order Type
Ordered Date
Org
Party Type

Payment Type
Price List
Request Date
Salesperson
Ship To
Source Document
Type
Transaction Phase
Warehouse

Page 3

You cannot build Defaulting Condition Templates on DFFs of the entity and you cannot build them on
any attributes of related entities (e.g., non-identifying attributes of the Order Type, like the Order Types
Price List).
In practice, this is not a serious limitation because the Defaulting Rules themselves (i.e., the rules that get
evaluated when a Defaulting Condition Template is true) can use any logic you want (using PL/SQL).
So, if you cannot define the Defaulting Condition Template the way you want, you can just use the
Always generic condition and just have the PL/SQL logic for your rule check the exact condition logic
you need (returning no value for the Defaulting Rule if the conditions are not met). There will be more
on this later.

Defining a Custom Always Condition

Most of the Defaulting Rules seeded by Oracle use the Always condition. Since seeded Defaulting
Rules cannot be modified (only disabled), you will need to define a custom Always condition if you
want to replace the Oracle-seeded rule with a custom rule.
A custom Always condition should always be true. Figure 3 shows a sample always condition.

Figure 3

COLLABORATE 14

Page 4

Defaulting Setup Entity Attributes

(Setup Rules Defaulting (B) Defaulting Condition Templates)
Each entity has a set of attributes that participate in the Defaulting Framework. This set is visible in the
Defaulting Setup screen (Figure 4).

Figure 4

You can use this screen to alter the sequence in which fields are defaulted, but you cannot add fields to
the list.
The Include in Building Defaulting Conditions checkbox indicates whether each field may be used in
Defaulting Condition Templates for the entity (see above). It is informational only you may not change
the value of the check box.
The Defaulting Sequence column specifies the order in which the defaulting framework will execute each
attributes Defaulting Rules. Generally, it is best to arrange things so that attributes have a higher
Defaulting Sequence than the fields on which they depend.
In practice, however, it is not important to spend a lot of time getting the sequence exactly right. Oracle
Order Management will iterate through the list of attributes several times if it needs to. For example,
suppose you have defaulting rules like this:

COLLABORATE 14

Page 5

Sequence
10
20

Attribute
Ordered Date
Pricing Date

30

Request Date

Rule
SYSDATE
Request Date
Ordered Date
1st day of current month

You might expect that the Pricing Date would always be defaulted to the Ordered Date, since the Request
Date comes later in the Defaulting Sequence and, so, would always be blank when the Pricing Date
defaulting rules are followed. However, the fact is that Oracle Order Management will handle this
situation just fine. It will follow these steps:
Iteration
1
1

Sequence
10
20

1
2

30
20

Action
Default Ordered Date = SYSDATE
Default Pricing Date to Request Date (which equals missing value) needs
to be defaulted in next iteration
Default Request Date = 1st of Month
Default Pricing Date = Request Date (1st of Month)

Oracle is able to handle this correctly because it is able to differentiate between a field that is blank
(technically: NULL) and a field that has not yet been defaulted (technically: FND_API.G_MISS_DATE, in
this example).
So, it is good to arrange the attributes in a logical order, but do not worry about it too much. Sometimes,
there is no perfect order, and that is fine.

Defaulting Rules
(Setup Rules Defaulting (B) Defaulting Rules)
For a given attribute, the actual Defaulting Rule consists of a set of Defaulting Conditions, each having a
set of Default Sources.
Figure 5 shows a customized rule for the Invoicing Rule attribute of the Order Header entity. In this
example, there are two sets of rules: one for Export Orders (our custom Defaulting Condition
Template) and one for Always. The groups are evaluated according to the Precedence field, so if you
use the Always condition, it is important to make it last.
Within the Export Order condition, there are two rules, which will be executed in order of their
Sequence. The first rule calls a custom PL/SQL API to derive the default value. The second rule, which
will be called only if the first rule returns a blank value, sets the default value to a constant value of
Advance Invoice

COLLABORATE 14

Page 6

Figure 5

COLLABORATE 14

Page 7

There are various Source Types of Defaulting Rule sources:

Source Type
Application Profile
Constant Value
PL/SQL
Related Record

Same Record

System Variable

WAD-Attribute
/
WAD-Object Attribute

Description
Use a profile option value at the default value
Use a constant value as the default value
Use the return value of a custom PL/SQL function as the default value
Use the value of an attribute from a related record as the default value. E.g.,
default Order Line Bill-To using the Order Header Bill-To.
Most, if not all, attributes are restricted to using only the same attribute from
the related record. That is, for example, an Order Line can default its Bill-To
from the Order Headers Bill-To, but not from the Order Headers Ship-To.
Use the value of an attribute from the same record as the default value. E.g.,
default the Pricing Date from the Request Date.
You can use any other field as the default value, even fields of different data
types and fields that are not themselves part of the Defaulting Framework (like
Descriptive Flexfields).
Use the value of a SQL expression as the default value.
E.g.,
FND_GLOBAL.USER_NAME or SYSDATE. The SQL expression (but not the
runtime value of the expression) is limited to 30 characters.
Use the default value from the Web attribute (or Web Object attribute) from
the AK Developer repository.
WARNING: Be careful about using these types. They are generally not helpful
or necessary and (in R12.1 at least) cause the underlying defaulting handler
package to be invalid. In other words, using them will cause all of the
defaulting rules for the attribute to stop working.

Defaulting Generator Concurrent Program

After making changes to Defaulting Rules, you must run the Defaulting Generator Concurrent Program.
This program reads your Defaulting Framework setups and uses them to generate the equivalent
PL/SQL package code, which is actually used by Order Management at runtime.
If you are only changing the Defaulting Rule for one attribute, you can submit the program for just that
entity/attribute using the Generate Defaulting Handler Package menu item under the Tools menu
on the Defaulting Rules form.
If you change Defaulting Condition Templates or Attributes Defaulting Sequences, you should submit
the Defaulting Generator program from the Reports, Requests -> Run Requests navigation path in Order
Management. See Figure 6 for an example of how to run this program to regenerate all the defaulting
packages for the Order Header entity.

COLLABORATE 14

Page 8

Figure 6

Implementing Defaulting Rules in PL/SQL

When the Source Type of a Defaulting Rule is PL/SQL API, you must specify the name of a package
function that you have installed to implement the defaulting logic. See Figure 7 for an example.

Figure 7

The package name and function do not have to exist in the database when you define the Defaulting
Rule, but they must exist by the time you run the Defaulting Generator concurrent program.

COLLABORATE 14

Page 9

The custom package function you develop must conform to the following API:
Parameter
P_DATABASE_OBJECT_NAME
P_ATTRIBUTE_CODE

Type
IN
IN

Data Type
VARCHAR2
VARCHAR2

Purpose / Description
Oracle passes the value of Attribute1 and
Attribute2 from the Defaulting Rules
Flexfield form for these parameters (see
Figure 7).
You may leave them blank in the setups,
but specifying them can be useful if you
configure multiple Defaulting Rules to
call the same custom function.

(Return Value)

Return
Value

See below

Using one function for multiple rules is

not best practice, but can be done if you
have two attributes that implement
similar logic (e.g., Freight Terms and Ship
Method).
Any non-NULL return value will be used
as the attributes default value.

Return Value Data Type

The custom PL/SQL function can return whatever data type (VARCHAR2, NUMBER, or DATE) that you
like, so long as it is possible to do an implicit type conversion from that data type to the data type of the
attribute being defaulted.
It is good practice to have your function return the correct data type for the attribute, but not absolutely
necessary. Just remember that, if you return a VARCHAR2, say, for a DATE attribute, your return value
will be converted to a date using an implicit type conversion. So, you would have to store the DATE
value in the VARCHAR2 using the current NLS date format instead of, for example, using
FND_DATE.CANONICAL_TO_DATE.
Returning NULL
If a custom PL/SQL function returns NULL, Oracle will automatically evaluate the next Defaulting Rule
for the attribute, if there is one.
Suppose you want to implement a defaulting rule for the Customer PO attribute using the following
logic:

If the Sales Order has an associated Agreement, use the Customer PO number from the
Agreement, even if the Customer PO number on the Agreement is NULL.
If the Sales Order has no associated Agreement, then use ATTRIBUTE7 from the Bill To
Customer.

Rules like this can be difficult, because the Defaulting Framework will execute the second rule whenever
the first rule returns NULL. There is no way to tell it to accept a NULL from the first rule as the final
answer.

COLLABORATE 14

Page 10

The easiest way to implement such a requirement is to build a custom PL/SQL function that performs
both steps and make that the only rule for the attribute. This is best way to control the logic completely
and prevent Oracle from using ATTRIBUTE7 in situations where the Sales Order is associated with an
Agreement that has no Customer PO specified.
Accessing the Current Row
To access the current record being defaulted, use the package variables provided by Oracle. For the
Order Header and Order Line entities, these are:
Entity
Order Header
Order Line

Package Variable
ONT_HEADER_DEF_HDLR.G_RECORD.field_name
ONT_LINE_DEF_HDLR.G_RECORD.field_name

Do not attempt to query the current record from the database, unless you are specifically looking for prechange values! The users latest values may not have been posted to the database by the Sales Order form
yet (so the database record may not exist or it may have outdated values). The package variables are the
only way to get the current value for attributes in the current record.
Note that Oracle does post the Order Header information to the database before allowing navigation to
the Order Lines. So, it is safe to query the Order Header record from the database if you are in a default
rule for the Order Lines entity. In fact, that is the proper way to do it: do not attempt to access the
package variable for one entity from a defaulting rule on a different entity.

Checking for Required Fields

It is possible (common, in fact) for Oracle to invoke your custom PL/SQL function before all the
attributes used in your logic have been valued).
You should check for these situations. If a field is NULL, it means it has been defaulted to NULL and you
may execute your logic.
However, if any required field is FND_API.G_MISS_xxx (e..g,
FND_API.G_MISS_NUM) is means that the field has not yet been defaulted.
If any of the required fields are G_MISS_xxx, you can either return NULL or the appropriate
G_MISS_xxx. Returning G_MISS_xxx from your PL/SQL function will force Oracle to iterate through all
the attributes again and try again to default this field in that next iteration (and, hopefully, the missing
required fields will have been given default values by then).
Be careful about doing this! Oracle will only go through a limited number of iterations before it gives up
and returns an error to the user.

Dependent Attributes and Re-Defaulting

Oracle Order Management has built-in relationships telling it which fields are dependent on which other
fields. Whenever a user or process changes a field, Oracle will automatically clear and re-default the
values for its dependent fields.
For example, Oracle knows that the Price List on an Order Header is dependent on the Bill-To Customer.
If a user changes the Bill-To Customer on an Order Header, Oracle will automatically clear the Price List
and re-execute its Defaulting Rules based on the new customer.

COLLABORATE 14

Page 11

Changing Dependent Attributes at Design Time

If you do not like Oracles built-in dependency relationships, you can change them by adding appropriate
PL/SQL code in the OE_DEPENDENCIES_EXTN package. This package is delivered by Oracle
Corporation as part of the Oracle e-Business Suite. However, unlike most standard packages, Oracle
allows and expects its customers to modify it.
For example, if you want your users to be able to change the Ship-To customer on an Order without redefaulting the Bill-To customer, you can remove the dependency relationship by adding this code to
OE_DEPENDENCIES_EXTN.LOAD_ENTITY_ATTRIBUTES:
IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
-- Custom Code: Remove dependency of Invoice To on Ship To
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;

Or, you may want to add a new dependency. If you want Oracle to re-default the Freight Terms
whenever the Ship Method is changed, you would add this code:
IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
-- Custom Code: Make freight terms dependent on the shipping method
x_extn_dep_tbl(l_index).source_attribute := OE_HEADER_UTIL.G_SHIPPING_METHOD;
x_extn_dep_tbl(l_index).dependent_attribute := OE_HEADER_UTIL.G_FREIGHT_TERMS;
x_extn_dep_tbl(l_index).enabled_flag := 'Y';
l_index := l_index + 1;

However, that second method adding a new dependency relationship only works for fields that
already have at least one dependent field in the standard Defaulting Framework.
If the source field does not already have dependent fields, you must also customize package
OE_HEADER_UTIL (or OE_LINE_UTIL, for dependencies among Order Line attributes). See MetaLink
Note: 113634.1 for Oracles description of why this is OK to do.
The sample code below shows an OE_HEADER_UTIL customization that will add Shipping Method as a
field that can be used as a source in dependency relationships. Without this code, the sample code above
(in OE_DEPENDENCIES_EXTN) will not achieve the desired goal of re-defaulting Freight Terms
whenever the Ship Method changes.
PROCEDURE Clear_Dependent_Attr

-- Custom Code: (see Metalink note 113634.1)

-- The following comment line must remain unchanged!
-- *** CUSTOMIZATION_INSTALLED ***
-- The above line is checked by other code to ensure that the customization has
-- not been overwritten by a patch.
IF NOT
OE_GLOBALS.Equal(p_x_header_rec.shipping_method_code,
p_old_header_rec.shipping_method_code)
THEN
l_index := l_index + 1.0;
l_src_attr_tbl(l_index) := OE_HEADER_UTIL.G_SHIPPING_METHOD;

COLLABORATE 14

Page 12

END IF;
-- END Custom code

Clear_Dependents
(p_src_attr_tbl
=>
,p_initial_header_rec
,p_old_header_rec
=>
,p_x_header_rec
=>
,p_x_instrument_id =>
,p_old_instrument_id

l_src_attr_tbl
=> p_initial_header_rec
p_old_header_rec
p_x_header_rec
p_x_instrument_id
=> p_old_instrument_id);

Notice the comment line containing the text *** CUSTOMIZATION_INSTALLED ***. It is a good
practice to include something like that and look for it in the initialization code of any custom package
used for defaulting. E.g., XXCUST_OM_DEFAULTING_PKG in the sample rules shown earlier.
For example:
CREATE OR REPLACE PACKAGE BODY XXCUST_OM_DEFAULTING_PKG AS
-- Custom Defaulting PL/SQL Functions go here
----------------------------------------------------------------------- Package Initialization
-- This runs before the first call to this package from each database session
-- Checks to ensure that customizations to base Oracle packages are installed
---------------------------------------------------------------------BEGIN
SELECT count(*)
INTO l_cnt
FROM dba_source
WHERE name = 'OE_HEADER_UTIL'
AND owner = 'APPS'
AND type='PACKAGE BODY'
AND
text like '%*** CUSTOMIZATION_INSTALLED ***%';
IF l_cnt = 0 THEN
fnd_message.set_name('ONT','OE_WF_EXCEPTION');
fnd_message.set_token('EXCEPTION','Fatal
Error!
Customizations
to
package OE_HEADER_UTIL have not been installed or have been over-written.
This message is generated from XXCUST_OM_DEFAULTING_PKG.
Developers can
refer to that package''s code comments for more information.');
app_exception.raise_exception;
END IF;
END xxcust_om_defaulting_pkg;
Following this practice will help make it obvious if and when your customizations to OE_HEADER_UTIL
are overwritten by an Oracle patch.

Changing Dependent Attributes at Run Time

It is also possible to change dependency relationships at run-time, to prevent unwanted re-defaulting in
particular situations.

COLLABORATE 14

Page 13

For example, suppose you have a custom item-supersession process in which that the item ordered by the
user may automatically be changed to an equivalent item based on a set of (custom) supersession rules
(and item availability, of course). Such a customization might be implemented in the Order Line
Workflow, but the exact details are beyond the scope of this paper.
When the supersession customization determines that it needs to change the item on a Sales Order line,
you do not want other, dependent fields, say the ship-to customer to clear and re-default (as you would
usually want to have happen in the case where the user was manually changing the item).
To temporarily disable the relationship, you need to save the existing dependency relationships, alter
them, call Oracles Process Order API to make the desired changes, and then re-instate the original
dependency relationships. Like this (this code would be somewhere in the supersession customizations
code):
DECLARE
l_save_dep_tbl
oe_dependencies.dep_tbl_type;
l_message
VARCHAR2 (400);
BEGIN
l_save_dep_tbl := oe_dependencies.g_dep_tbl;
-- Temporarily disable OE dependency between
-- inventory_item_id and ship_from_org_id
FOR i IN oe_line_util.g_inventory_item * oe_dependencies.g_max ..
(oe_line_util.g_inventory_item + 1) * oe_dependencies.g_max - 1
LOOP
IF oe_dependencies.g_dep_tbl.EXISTS (i) THEN
IF oe_dependencies.g_dep_tbl (i).attribute =
oe_line_util.g_ship_from_org THEN
oe_dependencies.g_dep_tbl (i).enabled_flag := 'N';
END IF;
END IF;
END LOOP;
-- Call PROCESS ORDER API
xxcust_supersession_pkg.process_order_lines
-- Restore original dependency relationships
oe_dependencies.g_dep_tbl := l_save_dep_tbl;
END;
In this example, the code disables the relationship between INVENTORY_ITEM_ID and
SHIP_FROM_ORG_ID just prior to calling Oracles Process Order API. After the call finishes, the custom
code immediately restores the original relationships.
Because Oracles dependency relationships are stored in PL/SQL package variables, changing them at
runtime affects only the current database session. There is no danger of another process being affected by
these changes, even if the other process happened to be running at the same time.

COLLABORATE 14

Page 14

Processing Constraints Overview

Processing Constraints are rules controlling what changes can be made, when they can be made, and by
whom.
Most Processing Constraints prohibit certain changes from being made in certain circumstances, but they
can also be configured to allow the change but trigger some additional action like an audit trail or an
integration event.
Unlike Defaulting Rules, which are aimed at eliminating manual data entry altogether, Processing
Constraints are aimed at ensuring that manual data entry, when required, is done correctly and in
conformance with your business rules.
Processing Constraints can be configured to govern changes on the following Order Management entities:

Order Headers
Order Lines
Order Payments
Order Price
Adjustments

Order Sales Credits

Sales Agreement
Headers
Sales Agreement
Lines

Line Payments
Line Price
Adjustments

Validation Templates
(Setup Rules Security Validation Templates)
Validation Templates are pre-defined conditions that can be used in Processing Constraints to control
when a change is allowed or disallowed. They must be defined ahead of time so that they can be
referenced in Processing Constraints.
The Validation Template shown in Figure 8 can be used by Processing Constraints to allow or disallow
changes depending on whether the Sales Order is booked.

COLLABORATE 14

Page 15

Figure 8

As you can see in Figure 8, there are three types of Validation Templates: Workflow (WF), PL/SQL API
(API), and Table-based (TBL).
Table-based Validation Templates are the most simple. To define one, you simply choose a column, an
operation (e.g., equal to) and a Value. If the resulting expression is true (e.g., Booked = Yes) for the
entity then the Validation Template is true.
You can have multiple expressions for a single table-based Validation Template. When you do, the
expressions are combined with an AND condition. That is, all of the expressions must be true for the
Validation Template to be true.
Workflow-based Validation Templates, like the one shown in Figure 9 are true when the entitys
workflow has the specified workflow activity in the specified status. If the specified status is Complete,
you may also, optionally, limit the Template to a particular Activity Result (e.g., APPROVED or
REJECTED).

COLLABORATE 14

Page 16

Figure 9

PL/SQL API-based Validation Templates, like the one shown in Figure 10, are true or not-true depending
on the output of a custom PL/SQL procedure.

Figure 10

COLLABORATE 14

Page 17

The PL/SQL package procedure for an API-based Validation Template must adhere to a specific API, as
follows:
PROCEDURE is_dealer_terminated (
p_application_id
p_entity_short_name
p_validation_entity_short_name
p_validation_tmplt_short_name
p_record_set_tmplt_short_name
p_scope
p_result

IN
IN
IN
IN
IN
IN
OUT NOCOPY

NUMBER,
VARCHAR2,
VARCHAR2,
VARCHAR2,
VARCHAR2,
VARCHAR2,
NUMBER);

The API should set P_RESULT to 1 to make the condition true. 0 means false.
As for PL/SQL-based Defaulting Rules, it is not safe to access the current record from the database, as it
may not yet have been posted by the Sales Order form. Instead, you must access the current record using
package variables supplied by Oracle. For Order Headers and Order Lines, these are:
Entity
Order Header
Order Line

Package Variable
oe_header_security.g_record.field_name
oe_line_security.g_record.field_name

Note that the package variables for Processing Constraints are not the same as the package variables for
Defaulting Rules.
Example
Suppose we have a DFF, ATTRIBUTE17 on the Order Header that contains an EXPEDITED BY
username. Suppose users can uses this field to affect our companys scheduling process to cause a
particular order to be prioritized as highly as possible.
According to our companys business rules, when a user expedites an Order, he or she must put in his or
her own user name. To implement a Processing Constraint to enforce this rule, we must first define a
PL/SQL-based Validation Template backed by PL/SQL code like this:
PROCEDURE is_expedited_by_invalid (p_application_id
IN
NUMBER,
p_entity_short_name
IN
VARCHAR2,
p_validation_entity_short_name
IN
VARCHAR2,
p_validation_tmplt_short_name
IN
VARCHAR2,
p_record_set_short_name
IN
VARCHAR2,
p_scope
IN
VARCHAR2,
x_result
OUT NUMBER) IS
l_header_id
NUMBER := oe_header_security.g_record.header_id;
l_expedited_by
oe_order_headers_all.attribute17%TYPE
:=
oe_header_security.g_record.attribute17;
l_debug_level
CONSTANT NUMBER := oe_debug_pub.g_debug_level;
BEGIN
IF l_debug_level > 0 THEN
oe_debug_pub.add
('ENTERING
XXCUST_OM_CONSTRAINTS_PKG.is_expedited_by_invalid',
1);
END IF;
IF l_expedited_by IS NULL THEN
-- A NULL value is OK

COLLABORATE 14

Page 18

x_result := 0;
IF l_debug_level > 0
oe_debug_pub.add
value is OK', 1);
END IF;
ELSIF l_expedited_by =
-- Setting it to the
x_result := 0;

THEN
('EXITING

XXCUST_OM_CONSTRAINTS_PKG.is_expedited_by_invalid,

fnd_global.user_name THEN
current user is OK

IF l_debug_level > 0 THEN

oe_debug_pub.add
('EXITING
XXCUST_OM_CONSTRAINTS_PKG.is_expedited_by_invalid,
value is OK', 1);
END IF;
ELSE
-- Technically, we should check whether the user is leaving the value unchanged, since
-- that would be "OK" also (and should result in a return value of "0". However, this
-- processing constraint is only fired if ATTRIBUTE17 is being updated, so we already
-- know that the user is NOT leaving the value unchanged.
x_result := 1;
IF l_debug_level > 0 THEN
oe_debug_pub.add
('EXITING
value is *not* OK', 1);
END IF;
END IF;

XXCUST_OM_CONSTRAINTS_PKG.is_expedited_by_invalid,

RETURN;
END is_expedited_by_invalid;

The functional setups for this example Processing Constraint will be shown below.

Record Sets
(Setup Rules Security Record Sets)
For a given Processing Constraint, you may want to allow or deny a change based on whether a
Validation Template is true of either any or all of a set of related records.
For example, suppose you want to create a processing constraint that will prevent users from changing
the ordered quantity on a Sales Order line if any line in the same ship set has been fulfilled. Figure 11
shows how to do that.

COLLABORATE 14

Page 19

Figure 11

The key part of Figure 11 is that it refers to a Record Set that tells Oracle how to identify the set of rows
for which to evaluate the Validation Template. Also note that the Scope of the rule is Any. If it were
set to All then users would be able to change the Ordered Quantity as long as there was at least one
line in the Ship Set that was not yet fulfilled.
The setup for the Ship Set Record Set is shown in Figure 12.

COLLABORATE 14

Page 20

Figure 12

Any Order Line sharing the same Header and Ship Set as the record being changed will be in the Record
Set.
You may define your own Record Sets, as needed. You may base them on any columns in the entity,
including Descriptive Flexfields.

Processing Constraints
(Setup Rules Security Processing Constraints)
Figure 13 shows a Processing Constraint controlling changes to a custom Descriptive Flexfield
(ATTRIBUTE17: Expedited By). See above for the custom code that implements the Validation
Template used.

COLLABORATE 14

Page 21

Figure 13

Each constraint has a set of basic fields, a set of conditions (in the Conditions tab), and (optionally) a set
of Responsibilities (in the Applicable To tab) that are either constrained by or exempted from the rule.
The basic fields of a Processing Constraint are shown below.
Field
Operation
Attribute

User Action

Description / Purpose
Indicates which operations will be disallowed by the Processing Constraint.
Allowed values are Create, Update, Delete, and Cancel.
(Only when Operation is Update). Indicates the attribute for which the
constraint will prohibit updates. If left blank, the constraint will prohibit updates
to all attributes.
NOTE: Unlike Defaulting Rules which do not operate on Descriptive Flexfields,
Processing Constraints can be defined to enforce rules on Descriptive Flexfields.
Indicates the action that the rule will enforce whenever the selected Operation is
attempted. The most common action is Not Allowed, meaning the system will
prevent the Operation from succeeding.
Other possible User Actions include various combinations of the following:
Generate Version archive the old version of the entity and allow the
change to affect a new version.
Require History Allow the operation, but record in Audit Trail history
Require Reason Allow the operation, but require the user to enter a
reason and, optionally, a comment.

COLLABORATE 14

Page 22

Applies To
System Changes
User Changes
Enabled
System

Raise Integration Event Allow the operation, but raise a Business

Event (i.e., oracle.apps.ont.oi.xml_int_status)

Indicates the transaction phase (i.e., Negotiation or Fulfillment) in which the

Constraint is in effect. Leave blank to affect both phases.
Indicates whether changes made by Order Management logic (such as by a
Defaulting Rule) are allowed to ignore the constraint.
Indicates whether the constraint limits user-initiated changes immediately or only
after the record has been saved to the database.
Indicates whether the Processing Constraint is enabled (i.e., currently being
enforced)
Indicates whether the Processing Constraint is required to preserve the integrity
of the Order Management application. System constraints can neither by changed
nor disabled.

The actual rules of the Processing Constraint are specified in the Conditions tab, which includes the
following fields.
Field
Group #

Scope
Validation Entity
Record Set

Not
Validation Template
Enabled
System
User Message

Description / Purpose
Indicates how each condition relates to the other conditions in the Processing
Constraint.
Conditions having the same Group # are related via a logical AND. Conditions
having different Group #s are related via a logical OR.
Indicates whether a condition requires the Validation Template to be true for
any record in the Record Set or for all records in the Record Set.
Indicates which entity is checked by the Condition
Indicates the set of records checked by the Condition. If Scope is Any, then the
Condition is true if the Validation Template applies to any record in the set. If
Scope is All, then the Condition is true only if Validation Template applies to all
of the records in the set.
You may only choose Record Sets for the selected Validation Entity. Also, if the
Validation Entity is not the same as the entity of the Processing Constraint itself,
then you may only choose the Record Set that is based on the Validation Entitys
primary key.
If checked, then the Condition is true only if the Validation does not applied to the
records in the Record Set (any or all of them, depending on the Scope).
The Validation Template that defines the actual logic of the Condition (e.g., Order
is Booked, Line is Cancelled, Dealer is Active).
Indicates whether the Condition is currently being enforced.
Indicates whether the Condition is required to preserve the integrity of the Order
Management system. System Conditions may neither be changed nor disabled.
The message to be displayed to the user when the Condition is true and the
attempted operation is being disallowed.
NOTE: this field is required and, in cases where several Conditions share the

COLLABORATE 14

Page 23

same Group # (i.e., a logical AND condition), all of the user messages from the
Group will be displayed. This is usually not desirable, so it is good practice to put
the User Message on the first condition of the Group only, and use a period (.)
for the other Conditions User Messages.

Once the base field of the Processing Constraint and the Conditions are specified, you may optionally
specify a set of responsibilities that are either bound by the constraint or allowed to ignore the constraint.
Figure 14 shows how this is done. In the example shown, the Processing Constraint will be enforced in
all responsibilities except Order Management Super User.

Figure 14

Generating Validation Packages

(Setup Rules Security Generate Constraints Validation Packages)
After any changes to Validation Templates, Record Sets, or Processing Constraints, you must run the
Generate Constraints Validation Packages concurrent program. This program takes the Processing
Constraint setups you have entered and uses them to generate PL/SQL code that will enforce them at
runtime.

Summary
Defaulting Rules and Processing Constraints are powerful frameworks for improving the speed
(defaulting rules) and accuracy (processing constraint) with which users can enter and maintain Sales
Orders and Returns in Order Management.
Both frameworks are robust enough that they are used by Oracle itself to enforce the rules that are
delivered as part of the native application functionality. Both frameworks are extensible in that they
allow you to integrate custom PL/SQL logic into the framework, allowing you to implement business
rules of any level of complexity.

COLLABORATE 14

Page 24