Using Defaulting Rules in Oracle Order Management

An Oracle White Paper August 2000 revised November 2001

There was a hard-coded list of sources for each particular data field. The user interface looks very different and very complex. The R11i Order Management User’s Guide gives a good explanation of the new forms and fields. You could define sets of rules and attach them to order types. and offer some insight into making the rules work for you. In Release 11 and earlier. but there are nuances of setup and use that are not obvious to the nontechnical reader or user. which offers somewhat differing functionality. 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 product architecture has been totally redone and the product functionality has been greatly expanded.Using Defaulting Rules in Oracle Order Management EXECUTIVE OVERVIEW Defaulting is the process by which values get into fields without someone having to key them. Every functional area had to be re-designed and re-coded. BACKGROUND Standard Value Rule Sets provided great functionality for Order Entry users. This paper attempts to explain the key functional differences between the SVRS in Order Entry and the Defaulting Rules in Order Management. with tips on how to use the new. 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 Oracle Order Entry product contained a feature called ‘Standard Value Rule Sets’ (SVRS) where you defined how you wanted order attributes to be defaulted. since most applications need similar Using Defaulting Rules in Oracle Order Management Page 1 . In Order Management. The design goal was to create a defaulting framework that other products could use. This paper outlines the key differences between SVRS and the new Defaulting Rules. It was difficult to extend or customize the rules. we have a new defaulting paradigm called ‘Defaulting Rules’. more powerful features. And the functionality seems to behave somewhat differently from the SVRS. too. But they were very much tied to the architecture and functionality of the Order Entry product. In Release 11i Order Management.

and potentially can be used by other Oracle applications. you define a set of rules for each attribute on the order header or line. The Defaulting Rules Framework is the result of that re-design. the new framework seems more straightforward and intuitive. See ‘Source of Values’ section below on all the various places you can default from. So the decision was made to design a more generic solution for defaulting. and you define the conditions for when to use each rule. 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. But once you start thinking of attributes in this way. as well as a way for you to invoke your own PL/SQL package to perform more complex logic. Order Price Adjustment.they used to be hard-coded. When you query up the Defaulting Setup form for a particular entity. So we have ‘entities’ of Order Header. instead of within the context of an order type. the biggest difference from SVRS is that with Defaulting Rules. the ‘ordered unit of measure’ is an attribute of the ‘Order Line’ entity. Terminology Since Defaulting Rules are now generic. This forces you to think of each attribute individually. Order Line. ‘Sources’ are where things default from. The new framework also brings somewhat more flexibility in where you can default from and to. we’re using more generic names for the things you default from and to.see ‘Source of Values’ section below.capabilities. the ability to define formulas to create the defaulted data . ‘Attributes’ and ‘Entities’ are the things you default to. FUNCTIONAL DIFFERENCES To an Order Entry/Management user or implementer. Entities correspond to ‘blocks’ in the old SVRS. a clear distinction between ‘defaulting’ behavior and ‘cascading’ . An ‘Attribute’ is a field or column that belongs to that entity. you will not be able to define defaulting rules Using Defaulting Rules in Oracle Order Management Page 2 . Line Price Adjustment. you’ll see a list of all the attributes for which you can define defaulting rules. As in OE.see ‘Watch Out For’ section below. 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 . Therefore. etc. Attributes correspond to ‘fields’ in the old SVRS.

• The Group Number is just an arbitrary number you enter to control ‘and’ and ‘or’ conditions. • In the Attribute column. greater than. For example. Defining Condition Validation Templates Here is how you define Defaulting Condition Templates. choose an operator from equal. You indicate that rules are to be connected by an ‘and’ rule by giving them the same group number. 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. The ALWAYS condition is seeded for each entity. you might set up a condition template for all return lines. where all the attributes of the entity are listed. or another one for all internal order lines. You define one or more of these condition templates per entity. • In the Value String column. Sequence of Defaulting On the main Defaulting Setup screen. choose from the list of attributes you can base a condition on. The only attributes that have this checkbox checked are ones that are the source for a dependency relationship. You define one or more ‘condition validation templates’ based on whatever common business rules you may have. not equal. not greater than or not less than. whereas rules you want to be connected by ‘or’ should be given different group numbers. This number determines the Using Defaulting Rules in Oracle Order Management Page 3 . See section on Dependencies below. And you cannot add to this list of attributes. then.for descriptive flexfields. less than. 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). 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. • In the Operator column. The lower half of the form is where you enter the details of the condition you are defining or viewing. You’ll see a form that lists all the conditions already defined for this entity. To add a new one. since their defaulting is controlled by AOL’s flexfield routines. there is a column called ‘Defaulting Sequence’. 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 . key in (or choose from the LOV) the actual value you want to compare to. press the Defaulting Condition Template button to get to the form to define the conditions. and then you can use them over and over for the attributes of that entity. Conditions ‘Conditions’ are rules you set up that will control when a particular group of default sources will be looked at.Entity Attributes form.

Using Defaulting Rules in Oracle Order Management Page 4 .is where you provide your own routine to provide the default. such as System Date. Or some attribute on the order header might default from an attribute on the related customer record. sysdate + the value of another attribute on a related entity (or record). you might set up the Ship Method on the line to default from the Ship Method on the header. They are documented in the ‘Rule Based Defaulting Framework’ simply a text string that will be used. • Same Record . you might set up the Promise Date to default from the Request Date on the same line. or the rule will not work as you expect. if you need defaulting to happen in some different order. . • PL/SQL API . Defaulting Rules provide a variety of sources that you can use in building your defaults. Sources of Values ‘Sources’ are places where values can be defaulted the value of a system (server) variable. For example. • System Variable . defaulting of the currency on the order header from the set of books (SOB) is seeded this way.order in which attribute defaulting takes place.there are several esoteric source types relating to the Web App Dictionary definitions for this attribute. you might define a sourcing rule that says default attribute A on the line from attribute B on the same line. 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. For this type of source (and this type only). you can use an expression containing a formula. for example. • Profile Option .for example. For example. if you really want to know. defaulting takes place alphabetically. you need to insure that the Attribute B gets its value before A is defaulted. • Constant Value .is the value of a profile option. • Related Record . or a new profile option that you’ve defined just to provide a defaulting value. When attributes have equal sequence numbers. Most of them will be familiar to users of Oracle Order Entry. You can change these sequences. This can be a system provided profile option. Most people won’t want to use these. For example. All the attributes are seeded with a sequence of the value of another attribute on the same entity (or record) as the attribute you are defining the rule for. In this case. There are a few seeded defaulting rules that use this . • others .

Then you can choose among preseeded possible source attributes. dependencies are hard-coded. 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. If an attribute is changed. you specify the attribute or value you want to use for the source. • In the Default Source Value column. you are ready to define your Sourcing Rules.) The lower half of the form is where you enter the details of the rule you are defining or viewing for this condition. Similar to what occurred in Order Entry. Customer PO number. This form lists all the conditions and rules that have been previously defined for this attribute. Once you query up the entity that you want to work with in the Defaulting Setup form and have defined your Conditions. If the Agreement is changed. This set of defaulting rules will be used if its corresponding Defaulting Condition is TRUE. The data type has to match that of the attribute you are defaulting. Alternatively. you can’t default things from just anywhere. Order Type. functionality was changed for certain fields such that if redefaulting did not come up with a default for the dependent field. • In the Source Type column. To add a new condition and its rules. These fields are: Price List. and the source relationship has to be pre-defined. Dependencies Some attributes are dependent upon the value of other attributes on the same record. Salesperson. As of September 2000 (available via patch for bug 1343621). you can also check current code in the Using Defaulting Rules in Oracle Order Management Page 5 . 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. the Price List is dependent on Agreement. the old value would be retained instead of clearing that value. either by the user or by the system. In the initial implementation of Defaulting Rules.Defining Sourcing Rules Here is how you define Default Sourcing Rules. • The Sequence here controls the order in which the system attempts to locate a default. See the ‘Rule Based Defaulting Framework’ HLD for a list of which dependencies have been provided. What you can choose here depends on the Source Type you have selected. (The precedence controls the sequence in which the conditions are evaluated. any other attribute that is dependent on it will be cleared and then re-defaulted. the Price List will be cleared and re-defaulted. choose from the list of Source Types as described above. What you’ll see in this field is a flexfield whose context is based on the Source Type. 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. For example.

x_extn_dep_tbl(l_index). l_index := l_index + 1. Source Attribute: Ship To. not across entities i.G_ENTITY_HEADER THEN x_extn_dep_tbl(l_index).source_attribute := OE_HEADER_UTIL. The entity on which this dependency needs to be defined is Order Header so add the dependency code under the IF for header entity. Adding dependencies via this hook is supported as long as the guidelines documented in the file are followed.G_ORDER_TYPE. However. ii) Dependencies can be established only among attributes on the same entity. 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’. Following the guidelines also ensures that patches do not over-write the changes introduced by users. Until such time as that enhancement is provided.dependent_attribute := OE_HEADER_UTIL. 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. the dependency of Invoice To on Ship To should be disabled via this new hook. changing an attribute on order header will NOT result in a change to attributes on order line. Below are examples to add to remove a dependency. For this rule to work.hardcoded dependencies package .e.pls for the complete list. Dependent Using Defaulting Rules in Oracle Order Management Page 6 . x_extn_dep_tbl(l_index).pls).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. To ensure that Invoice To is not affected by a change to Ship To.enabled_flag := 'Y'. please note that: i) The list of source/dependent attributes that can be used to setup the dependencies is restricted. IF p_entity_code = OE_GLOBALS.OE_Dependencies (file: $ONT_TOP/patch/115/sql/OEXUDEPB.G_SALESREP. you can add code in a simple API hook package OE_Dependencies_Extn (the file name is $ONT_TOP/patch/115/sql/OEXEDEPB. The Source Attribute is Order Type. Disable a Dependency Updating Ship To on the order header results in Invoice To being cleared and/or updated. and the Dependent Attribute is Salesperson. if you need to create additional dependencies or disable existing dependencies that you do not need. a new dependency needs to be enabled. The code modifications are relatively easy. Please refer to comments in file OEXEDEPB.

you want to create a dependency for a source or a dependent attribute that is not listed in OEXEDEPB.Clear_Dependent_Attr (file: OEXUHDRB.dependent_attribute := OE_HEADER_UTIL. l_index := l_index + 1. on the other hand.enabled_flag := 'N'. l_src_attr_tbl(l_index) := OE_HEADER_UTIL. Adding a new Source Attribute: For example. IF p_entity_code = OE_GLOBALS. ELSF p_entity_code = OE_GLOBALS.pls. Dependent Attribute: Shipping Method. This requires CUSTOMIZATION of existing packages.p_old_header_rec. you want to make Shipping Method on the header dependent on Shipment Priority. END IF Using Defaulting Rules in Oracle Order Management Page 7 . you have to do a little more.shipment_priority_code) THEN l_index := l_index + 1.G_ENTITY_HEADER THEN x_extn_dep_tbl(l_index).enabled_flag := 'N'.pls). If you want a change in the Shipment Priority on the order line to also affect Shipping Method on the order line entity. IF NOT OE_GLOBALS.G_SHIP_TO_ORG.G_SHIPMENT_PRIORITY.Equal(p_x_header_rec. you also need to CUSTOMIZE another entity specific utility package. If. Patches in the future might over-write your changes. l_index := l_index + 1.G_INVOICE_TO_ORG.dependent_attribute := OE_LINE_UTIL. code similar to the following needs to be added to OE_Line_Util_Ext.pls as above with Source Attribute: Shipment Priority. x_extn_dep_tbl(l_index).source_attribute := OE_LINE_UTIL.G_ENTITY_LINE THEN x_extn_dep_tbl(l_index). x_extn_dep_tbl(l_index). First you need to add a dependency in OEXDEPB. Since Shipment Priority is not listed as one of the source attributes available on Order Header. x_extn_dep_tbl(l_index). Add the following statement in OE_Header_Util. x_extn_dep_tbl(l_index).G_INVOICE_TO_ORG.0.source_attribute := OE_HEADER_UTIL. the dependency should be separately disabled for the Line entity. If it is also required that updating Ship To should not change the value of Invoice To on the order Line.Attribute: Invoice To.shipment_priority_code .G_SHIP_TO_ORG.

Controlling Changes In Order Entry SVRS.Clear_Dependents (file: OEXULXTB. you should replace G_MISS_NUM with G_MISS_CHAR & for DATE fields.G_AGREEMENT THEN AGREEMENT. Dependent Attribute: Planning Priority. you need to add a dependency in OEXDEPB.PLANNING_PRIORITY := FND_API.G_MISS_CHAR OR OE_GLOBAlS.PLANNING_PRIORITY)) THEN p_x_line_rec. it should be G_MISS_DATE.Equal(p_initial_line_rec.pls as above with Source Attribute: Demand Class. you control who can change Using Defaulting Rules in Oracle Order Management Page 8 . PROCEDURE PLANNING_PRIORITY IS BEGIN IF (p_initial_line_rec.Adding a new Dependent Attribute: For example. Note that for VARCHAR2 fields.pls). you also need to CUSTOMIZE another section of the entity specific utility package.PLANNING_PRIORITY = FND_API. Order Management’s Defaulting Rules solved that problem by getting rid of those checkboxes.PLANNING_PRIORITY . And if Planning Priority is not listed as one of the dependent attributes for order line entity.OE_Header_Util (file: OEXUHDRB. add the following sub-procedure in OE_Line_Util_Ext. you may want Planning Priority on the line to be default based on Demand Class. Instead. Again. 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). you need to go through the steps outlined earlier to add it as a source attribute. END PLANNING_PRIORITY. there used to be two checkboxes on each rule line where you could control changes to an attribute. For adding dependent fields on Order Header entity. p_old_line_rec. These checkboxes often were viewed to be confusing and to operate inconsistently. follow the above steps & add similar code in header utility package .G_MISS_NUM. If Demand Class is not listed as one of the source attributes available on Order Line entity.pls). END IF. 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. First.

for (and when) using the new Processing Constraints framework. but a user cannot make changes. there are a few behaviors to take into consideration when creating Conditions. it will only work if you ensure Customer gets defaulted before UOM. Sequencing of Attributes Used in Conditions Sequencing of defaulting of attributes plays an important role in the correct design of Conditions and Sourcing Rules. And even then. This way. You’ll have to examine carefully your business rules so you can state Conditions in terms of attributes on the same level. the customer can be used in a condition template for the line. attribute or condition. It replaces the old OE ‘Standard Value Rules Listing’. most attributes (with few exceptions such as order type and currency) at the header are also present at the line level. 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. 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. In addition. it will only work for the initial defaulting of the UOM field. if you define a Condition for defaulting the Unit of Measure by using the Customer. regardless of how or whether an attribute was defaulted. you have the ability when you define Processing Constraints to indicate that you want the system to be able to update an attribute. For example. or your Condition will not evaluate true. And that is because of Dependencies. you cannot set up a Condition for a line attribute based on the order type because order type is a header attribute. Even the sold-to customer is present as a line-level attribute. you must be sure that attribute Y gets defaulted before attribute X. Reports There is a new report in Order Management that you can use to list the Defaulting Rules you have set up. even though the software enforces that the customer is the same throughout an order. Fortunately. The report is called ‘Defaulting Rules Listing’. Therefore. 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. However. If you create a rule for attribute X based on a Condition using attribute Y. Using Defaulting Rules in Oracle Order Management Page 9 . and it has parameters to allow you to limit the listing to a specific object (entity). in Order Management.

Cascading In Order Management. You will need to use mass change to do that. means replicating the value of an attribute down to lower level entities. or when an attribute upon which this attribute is dependent is changed. and then change them. 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. you need to use the new mass change capability. which will cause behavior different from what we have become used to in R11 Order Entry. a clear and unambiguous distinction has been made between ‘defaulting’ and ‘cascading’. where you multi-select the rows you want to change. then the rule will work during subsequent updates of attribute Y only if attribute X is dependent on attribute Y. on the other hand. You create an order with several lines and use Ship Method A for the header (and therefore the lines). Defaulting Rules have been seeded that provide equivalent functionality to the R11 seeded SVRS. If a Condition involving attribute Y is used to setup the defaulting rule for attribute X. the decision was made to not upgrade any userdefined SVRS. The good news is that the user has explicit and unambiguous control over what lines get changed. In OE. If you want to change the value of attributes on existing rows. Using Defaulting Rules in Oracle Order Management Page 10 . The existing lines that have Ship Method A will not get changed to B as a result of your changing the header attribute. We do not perform cascading in Order Management.Dependencies of Attributes Used in Conditions So you must also regard dependencies when you are building Conditions. defaulting and cascading were intermixed. So what does this mean in real life? Here’s an example. MIGRATION/UPGRADE FROM SVRS Because of the magnitude of the changes to the fundamental architecture between SVRS and Defaulting Rules. Cascading. So in the UOM and Customer example above. the defaulting logic will come into play only when the record is initially created (when you click on a new record on the form). if you later change the Customer on the order. making it sometimes difficult to predict what might happen when an attribute at one level was changed. and what the seeded defaulting rule is for each of those attributes. Changing this attribute at the header will result in any subsequent new lines getting Ship Method B defaulted onto them. the UOM will not re-default based on the new customer. Defaulting vs. Assume you have a defaulting rule set up to default a line-level attribute such as Ship Method from the header to the line. In OM. because UOM is not dependent on Customer. Then you want to change the ship method to Ship Method B.

However.the need to default the Order Type based on customer (sometimes) and otherwise based on user. • Second. you can write rules to default the Order Type. ship-to or bill-to record as required. and create equivalent Defaulting Rules for the attributes affected. EXAMPLE All right now. as you want to just set up one set of rules. 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. 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. the defaulting code will look first at the customer bill-to site for a default order type. This was something that could not be done using SVRS in Order Entry. But in Order Management. whereas your Export Department personnel might enter orders of Order Type ‘International’. Use the seeded condition ALWAYS. You would leave this field null for most customers. Order Type was one of those things that always had to be keyed or selected from an LOV.all their orders generally are of that order type. create defaulting rules for entity: Order Header.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. Have the defaulting precedence be: 5 10 15 20 Related Record Related Record Related Record Application Profile Invoice-to: Order Type Ship-to: Order Type Customer: Order Type OMX: xxxxxxx (your new profile option) • Finally. Let’s take the example of a very common business need . and then create Defaulting Rules using those Conditions for the necessary attributes. let’s see how you can use Defaulting Rules in real life. for customers with special order type needs. you would like users in various departments to always enter orders of a particular type . attribute: Order Type.Domestic CSRs might enter orders of Order Type ‘Domestic’. then to the ship-to record. Then. as a customer is entered on an order. that you have a special order type set up just for them . for the general case. then to the Using Defaulting Rules in Oracle Order Management Page 11 . Here’s the business requirement: Some of your customers have such special processing requirements. to let the profile option be used. Typically a user will need to create Conditions corresponding to their particular business need. store their special order type in their Customer. Here’s how you’d do this: • First.

it contains an example of setting up these exact rules. Using Defaulting Rules in Oracle Order Management Page 12 . For a closer look at exactly how to perform these setup steps.customer header. see the Defaulting Demoshield in the OM Toolbox . CONCLUSION Oracle Order Management’s use of the new Defaulting Framework provides powerful defaulting capabilities. thus speeding input time and reducing keying errors. You need to thoroughly understand Conditions and Dependencies so that you can design how your defaulting should occur. and finally to the new profile option. if you know how to use them. you can significantly reduce the amount of data that has to be keyed upon entering an order. With correct definition and use of Defaulting Rules.

Linda Henry Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores.Using Defaulting Rules in Oracle Order Management August 2000 Revised September 2000 and November 2001 Author: Charlene Chandonia Contributing Authors: Nithya Lakshmanan. and Oracle Order Management is a trademark(s) or registered trademark(s) of Oracle Web: www. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this This document is provided for informational purposes only and the information herein is subject to change without notice. CA 94065 U.S.650.7000 Fax: +1. Please report any errors herein to Oracle Corporation. All other names may be trademarks of their respective owners.506.A. Worldwide Inquiries: Phone: +1. Copyright © Oracle Corporation 2000 All Rights Reserved . Oracle is a registered trademark.

Sign up to vote on this title
UsefulNot useful