Defaulting Rules in Order Management

Defaulting Rules in Order Management

Sales order Defaulting rules determine how certain fields in Order Management. The defaulting rules are applicable for below entities:

• Order Header,
• Order Lines,
• Order Payments

Navigation: OM Superuser Responsibility à Setup à Rules à Defaulting

Below is the defaulting Setup Screen. This is the main screen, where the entity object is selected and its defaulting rules are defined. This form contains “Defaulting Condition Templates” & “Defaulting Rules”.

Defaulting Condition Templates:

This helps to define the default conditioning templates. Custom as well as Seeded validation templates are available. Check box helps to determine whether the validation is Seeded or not.

Condition name “Always” is Generic Condition. It is applicable to define the validation is generic condition. It is a seeded validation.

Default Rules:

Based on the Attribute Defaulting selection, the defaulting Rules can be defined. Below screenshot is applicable for “Ordered Date” Attribute.

Source Type:

Source Types 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.

Source Types	Explanation
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.
PLSQL 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.

In order management, sometimes defaulting rules are driven by source and dependent attributes. This means that whenever you change source, you can derive dependent attribute value based on source value.

For example, if you give order type as "Standard", you can derive value for "Shipping Method" from transaction type setup using pl/sql API. But this dependency between order type and shipping method must be defined in file $ONT_TOP/patch/115/sql/OEXUDEPB.pls. If you open this file, you can see dependency written as below between order type and shipping method. Hence your defaulting rule for shipping method will work fine just by writing simple logic in pl/sql API.

IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
     --  Populate dependent attributes for one source at a time.
     l_index := OE_HEADER_UTIL.G_ORDER_TYPE * G_MAX ;
     g_dep_tbl(l_index +4 ).attribute  := OE_HEADER_UTIL.G_SHIPPING_METHOD;
............

However, there are many attributes for which dependency is not defined in file OEXUDEPB.pls. So, oracle has provided an extension package - OE_DEPENDENCIES_EXTN which we also call as hook.

You can write simple piece of code in this package and compile it to define dependency between any of the OM attributes.

Below is one more example:

Example 1 (Header Tab): If you want to derive value for FOB_POINT based on value input in END_CUSTOMER, you can perform below steps to achieve it.

a) Define your defaulting rule for Order Header entity, Attribute - Shipping method and source as PL/SQL API. Write simple logic in your pl/sql procedure to derive fob_point value from hz_cust_accounts based on end_customer_id value (cust_account_id)                
 
b) Write below code in package - OE_DEPENDENCIES_EXTN and compile it.

IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
 
x_extn_dep_tbl(l_index).source_attribute := OE_HEADER_UTIL.G_END_CUSTOMER;
x_extn_dep_tbl(l_index).dependent_attribute := OE_HEADER_UTIL.G_FOB_POINT;
x_extn_dep_tbl(l_index).enabled_flag := 'Y';      
l_index := l_index + 1;                

c) Run concurrent program " Defaulting Generator" from SRS window  

References:

Doc 414120.1- Order Management Suite - Defaulting Library (Doc ID 414120.1)

Note 122461.1 - Order Management Defaulting - Using Defaulting Rules in Oracle Order Management