Академический Документы
Профессиональный Документы
Культура Документы
Management
Matthew McPeak
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.
COLLABORATE 14
Page 1
Figure 1
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.
Figure 3
COLLABORATE 14
Page 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
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.
COLLABORATE 14
Page 8
Figure 6
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
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.
COLLABORATE 14
Page 11
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
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.
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
Order Headers
Order Lines
Order Payments
Order Price
Adjustments
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
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
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
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