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 nontechnical 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 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
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
form (use the flashlight icon to get the LOV of available entities), press the 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
Here is how you define Defaulting
Condition Templates.
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.
Defining 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 preseeded 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 redefaulting 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 Here is how you define Default Sourcing
Rules.
Using Defaulting Rules in Oracle Order Management Page 6
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
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
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
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.
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 userdefined 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.
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 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.
Reference:
Charlene Chandonia. Oracle Corporation. 2001
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 nontechnical 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 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
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
form (use the flashlight icon to get the LOV of available entities), press the 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
Here is how you define Defaulting
Condition Templates.
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.
Defining 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 preseeded 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 redefaulting 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 Here is how you define Default Sourcing
Rules.
Using Defaulting Rules in Oracle Order Management Page 6
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
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
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
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.
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 userdefined 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.
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 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.
Reference:
Charlene Chandonia. Oracle Corporation. 2001
No comments:
Post a Comment