This action might not be possible to undo. Are you sure you want to continue?
An Oracle White Paper August 2000 revised November 2001
and offer some insight into making the rules work for you. There was a hard-coded list of sources for each particular data field. 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. Every functional area had to be re-designed and re-coded. The design goal was to create a defaulting framework that other products could use. It was difficult to extend or customize the rules. we have a new defaulting paradigm called ‘Defaulting Rules’. You could define sets of rules and attach them to order types.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. But they were very much tied to the architecture and functionality of the Order Entry product. which offers somewhat differing functionality. too. with tips on how to use the new. BACKGROUND Standard Value Rule Sets provided great functionality for Order Entry users. And the functionality seems to behave somewhat differently from the SVRS. the product architecture has been totally redone and the product functionality has been greatly expanded. In Release 11 and earlier. 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?’. more powerful features. but there are nuances of setup and use that are not obvious to the nontechnical reader or user. In Order Management. This paper outlines the key differences between SVRS and the new Defaulting Rules. since most applications need similar Using Defaulting Rules in Oracle Order Management Page 1 . 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. This paper attempts to explain the key functional differences between the SVRS in Order Entry and the Defaulting Rules in Order Management. The R11i Order Management User’s Guide gives a good explanation of the new forms and fields. The user interface looks very different and very complex. In Release 11i Order Management.
see ‘Watch Out For’ section below. Order Price Adjustment.capabilities. Order Line. 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 . Entities correspond to ‘blocks’ in the old SVRS. As in OE. ‘Sources’ are where things default from. etc. Terminology Since Defaulting Rules are now generic. as well as a way for you to invoke your own PL/SQL package to perform more complex logic. you will not be able to define defaulting rules Using Defaulting Rules in Oracle Order Management Page 2 . The new framework also brings somewhat more flexibility in where you can default from and to. and you define the conditions for when to use each rule. But once you start thinking of attributes in this way. you’ll see a list of all the attributes for which you can define defaulting rules. Line Price Adjustment. So we have ‘entities’ of Order Header. you define a set of rules for each attribute on the order header or line. 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.they used to be hard-coded. An ‘Attribute’ is a field or column that belongs to that entity. FUNCTIONAL DIFFERENCES To an Order Entry/Management user or implementer. the biggest difference from SVRS is that with Defaulting Rules. a clear distinction between ‘defaulting’ behavior and ‘cascading’ . The Defaulting Rules Framework is the result of that re-design. Therefore. the new framework seems more straightforward and intuitive. instead of within the context of an order type. the ability to define formulas to create the defaulted data . Attributes correspond to ‘fields’ in the old SVRS.see ‘Source of Values’ section below. See ‘Source of Values’ section below on all the various places you can default from. ‘Attributes’ and ‘Entities’ are the things you default to. This forces you to think of each attribute individually. When you query up the Defaulting Setup form for a particular entity. and potentially can be used by other Oracle applications. the ‘ordered unit of measure’ is an attribute of the ‘Order Line’ entity. we’re using more generic names for the things you default from and to. So the decision was made to design a more generic solution for defaulting.
See section on Dependencies below. 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 . The only attributes that have this checkbox checked are ones that are the source for a dependency relationship. there is a column called ‘Defaulting Sequence’. not greater than or not less than. then. key in (or choose from the LOV) the actual value you want to compare to. Defining Condition Validation Templates Here is how you define Defaulting Condition Templates. This number determines the Using Defaulting Rules in Oracle Order Management Page 3 . Conditions ‘Conditions’ are rules you set up that will control when a particular group of default sources will be looked at. • In the Attribute column. The lower half of the form is where you enter the details of the condition you are defining or viewing. where all the attributes of the entity are listed. You define one or more of these condition templates per entity. greater than. For example. The ALWAYS condition is seeded for each entity. You indicate that rules are to be connected by an ‘and’ rule by giving them the same group number. You’ll see a form that lists all the conditions already defined for this entity. choose from the list of attributes you can base a condition on.for descriptive flexfields. And you cannot add to this list of attributes. If you are defining a set of Conditions and using them in rules. since their defaulting is controlled by AOL’s flexfield routines. Sequence of Defaulting On the main Defaulting Setup screen. whereas rules you want to be connected by ‘or’ should be given different group numbers. • The Group Number is just an arbitrary number you enter to control ‘and’ and ‘or’ conditions. you might set up a condition template for all return lines. To add a new one. and then you can use them over and over for the attributes of that entity. not equal. or another one for all internal order lines. press the Defaulting Condition Template button to get to the form to define the conditions.Entity Attributes form. choose an operator from equal. You define one or more ‘condition validation templates’ based on whatever common business rules you may have. • In the Operator column. • In the Value String column. less than. 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. 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). be sure to place the ALWAYS condition last in the Precedence for Defaulting Conditions.
They are documented in the ‘Rule Based Defaulting Framework’ HLD. you can use an expression containing a formula. . • Related Record . sysdate + 7. There are a few seeded defaulting rules that use this . if you need defaulting to happen in some different order. In this case. Most of them will be familiar to users of Oracle Order Entry. • PL/SQL API . When attributes have equal sequence numbers. you might set up the Promise Date to default from the Request Date on the same line.for example. Most people won’t want to use these. you might set up the Ship Method on the line to default from the Ship Method on the header.is the value of a system (server) variable.is the value of another attribute on the same entity (or record) as the attribute you are defining the rule for.is where you provide your own routine to provide the default. defaulting takes place alphabetically. For this type of source (and this type only). • System Variable . 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. Using Defaulting Rules in Oracle Order Management Page 4 . This can be a system provided profile option.is simply a text string that will be used. for example. Defaulting Rules provide a variety of sources that you can use in building your defaults. you might define a sourcing rule that says default attribute A on the line from attribute B on the same line. if you really want to know. • Constant Value . Or some attribute on the order header might default from an attribute on the related customer record.order in which attribute defaulting takes place. All the attributes are seeded with a sequence of 50. For example. • Profile Option . You can change these sequences. you need to insure that the Attribute B gets its value before A is defaulted. or a new profile option that you’ve defined just to provide a defaulting value.is the value of a profile option. defaulting of the currency on the order header from the set of books (SOB) is seeded this way. • Same Record . For example. • others . such as System Date. Sources of Values ‘Sources’ are places where values can be defaulted from.is the value of another attribute on a related entity (or record).there are several esoteric source types relating to the Web App Dictionary definitions for this attribute. For example. or the rule will not work as you expect.
If an attribute is changed. functionality was changed for certain fields such that if redefaulting did not come up with a default for the dependent field. dependencies are hard-coded. In the initial implementation of Defaulting Rules. Order Type. you can also check current code in the Using Defaulting Rules in Oracle Order Management Page 5 . and then click on the Defaulting Rules button to get to a form called Attribute Defaulting Rules. either by the user or by the system. The data type has to match that of the attribute you are defaulting. the Price List is dependent on Agreement. • In the Source Type column. choose from the list of Source Types as described above. and the source relationship has to be pre-defined. This form lists all the conditions and rules that have been previously defined for this attribute. Then you can choose among preseeded possible source attributes. What you can choose here depends on the Source Type you have selected. the Price List will be cleared and re-defaulted. you specify the attribute or value you want to use for the source. any other attribute that is dependent on it will be cleared and then re-defaulted. Once you query up the entity that you want to work with in the Defaulting Setup form and have defined your Conditions. What you’ll see in this field is a flexfield whose context is based on the Source Type. Dependencies Some attributes are dependent upon the value of other attributes on the same record. Salesperson. • In the Default Source Value column. This set of defaulting rules will be used if its corresponding Defaulting Condition is TRUE. Similar to what occurred in Order Entry. 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.Defining Sourcing Rules Here is how you define Default Sourcing Rules. See the ‘Rule Based Defaulting Framework’ HLD for a list of which dependencies have been provided. These fields are: Price List. Select the attribute you want to work on. Alternatively.) The lower half of the form is where you enter the details of the rule you are defining or viewing for this condition. you can’t default things from just anywhere. If the Agreement is changed. For example. To add a new condition and its rules. the old value would be retained instead of clearing that value. (The precedence controls the sequence in which the conditions are evaluated. • The Sequence here controls the order in which the system attempts to locate a default. you are ready to define your Sourcing 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. As of September 2000 (available via patch for bug 1343621). Customer PO number.
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’. the dependency of Invoice To on Ship To should be disabled via this new hook. x_extn_dep_tbl(l_index). The user deleted/disabled the defaulting rule to default Invoice To from Ship To and still the behavior does not change. l_index := l_index + 1. Adding dependencies via this hook is supported as long as the guidelines documented in the file are followed. Source Attribute: Ship To. ii) Dependencies can be established only among attributes on the same entity. An enhancement request has been logged (1201256) to provide a form to allow users to create their own dependencies.pls for the complete list. The Source Attribute is Order Type. However. you can add code in a simple API hook package OE_Dependencies_Extn (the file name is $ONT_TOP/patch/115/sql/OEXEDEPB.enabled_flag := 'Y'. For this rule to work. The reason is that there is a hardcoded dependency of Invoice To on the Ship To field.OE_Dependencies (file: $ONT_TOP/patch/115/sql/OEXUDEPB. The code modifications are relatively easy. Following the guidelines also ensures that patches do not over-write the changes introduced by users. Please refer to comments in file OEXEDEPB.hardcoded dependencies package . Disable a Dependency Updating Ship To on the order header results in Invoice To being cleared and/or updated. Until such time as that enhancement is provided. x_extn_dep_tbl(l_index).G_SALESREP.G_ORDER_TYPE. IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN x_extn_dep_tbl(l_index).pls). changing an attribute on order header will NOT result in a change to attributes on order line. not across entities i.e.source_attribute := OE_HEADER_UTIL.pls) to get the latest list. To ensure that Invoice To is not affected by a change to Ship To.dependent_attribute := OE_HEADER_UTIL. if you need to create additional dependencies or disable existing dependencies that you do not need. The entity on which this dependency needs to be defined is Order Header so add the dependency code under the IF for header entity. and the Dependent Attribute is Salesperson. please note that: i) The list of source/dependent attributes that can be used to setup the dependencies is restricted. a new dependency needs to be enabled. Dependent Using Defaulting Rules in Oracle Order Management Page 6 .
Patches in the future might over-write your changes. If you want a change in the Shipment Priority on the order line to also affect Shipping Method on the order line entity. If.enabled_flag := 'N'. ELSF p_entity_code = OE_GLOBALS. on the other hand.G_SHIPMENT_PRIORITY.Equal(p_x_header_rec. you have to do a little more. x_extn_dep_tbl(l_index).0.pls.pls).source_attribute := OE_HEADER_UTIL. you want to make Shipping Method on the header dependent on Shipment Priority. This requires CUSTOMIZATION of existing packages. Dependent Attribute: Shipping Method. If it is also required that updating Ship To should not change the value of Invoice To on the order Line.source_attribute := OE_LINE_UTIL. END IF Using Defaulting Rules in Oracle Order Management Page 7 . l_index := l_index + 1.dependent_attribute := OE_LINE_UTIL.G_ENTITY_HEADER THEN x_extn_dep_tbl(l_index).enabled_flag := 'N'. you want to create a dependency for a source or a dependent attribute that is not listed in OEXEDEPB. Since Shipment Priority is not listed as one of the source attributes available on Order Header.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. x_extn_dep_tbl(l_index).G_INVOICE_TO_ORG.p_old_header_rec.shipment_priority_code . the dependency should be separately disabled for the Line entity. you also need to CUSTOMIZE another entity specific utility package.G_SHIP_TO_ORG. code similar to the following needs to be added to OE_Line_Util_Ext. Add the following statement in OE_Header_Util.Attribute: Invoice To. l_index := l_index + 1.dependent_attribute := OE_HEADER_UTIL. IF p_entity_code = OE_GLOBALS.shipment_priority_code) THEN l_index := l_index + 1.G_INVOICE_TO_ORG.G_SHIP_TO_ORG. x_extn_dep_tbl(l_index). l_src_attr_tbl(l_index) := OE_HEADER_UTIL.Clear_Dependent_Attr (file: OEXUHDRB. Adding a new Source Attribute: For example.pls as above with Source Attribute: Shipment Priority. IF NOT OE_GLOBALS.
you need to go through the steps outlined earlier to add it as a source attribute. you also need to CUSTOMIZE another section of the entity specific utility package. END PLANNING_PRIORITY. follow the above steps & add similar code in header utility package . you control who can change Using Defaulting Rules in Oracle Order Management Page 8 .pls as above with Source Attribute: Demand Class. And if Planning Priority is not listed as one of the dependent attributes for order line entity. you should replace G_MISS_NUM with G_MISS_CHAR & for DATE fields.pls). you need to add a dependency in OEXDEPB. 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).PLANNING_PRIORITY .G_AGREEMENT THEN AGREEMENT. p_old_line_rec.G_MISS_CHAR OR OE_GLOBAlS. Instead. PROCEDURE PLANNING_PRIORITY IS BEGIN IF (p_initial_line_rec.Adding a new Dependent Attribute: For example.Clear_Dependents (file: OEXULXTB. it should be G_MISS_DATE. Order Management’s Defaulting Rules solved that problem by getting rid of those checkboxes.G_MISS_NUM. Again. Dependent Attribute: Planning Priority.PLANNING_PRIORITY = FND_API.PLANNING_PRIORITY)) THEN p_x_line_rec. 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. For adding dependent fields on Order Header entity. Controlling Changes In Order Entry SVRS.PLANNING_PRIORITY := FND_API. First. These checkboxes often were viewed to be confusing and to operate inconsistently. If Demand Class is not listed as one of the source attributes available on Order Line entity.Equal(p_initial_line_rec. add the following sub-procedure in OE_Line_Util_Ext. there used to be two checkboxes on each rule line where you could control changes to an attribute.OE_Header_Util (file: OEXUHDRB. END IF. you may want Planning Priority on the line to be default based on Demand Class.pls). Note that for VARCHAR2 fields.
for example. you cannot set up a Condition for a line attribute based on the order type because order type is a header attribute. Using Defaulting Rules in Oracle Order Management Page 9 . It replaces the old OE ‘Standard Value Rules Listing’. you must be sure that attribute Y gets defaulted before attribute X. For example. or your Condition will not evaluate true.data (and when) using the new Processing Constraints framework. If you create a rule for attribute X based on a Condition using attribute Y. 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 customer can be used in a condition template for the line. The report is called ‘Defaulting Rules Listing’. Fortunately. 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. Even the sold-to customer is present as a line-level attribute. In addition. 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. and it has parameters to allow you to limit the listing to a specific object (entity). it will only work for the initial defaulting of the UOM field. This way. Therefore. attribute or condition. However. And that is because of Dependencies. You’ll have to examine carefully your business rules so you can state Conditions in terms of attributes on the same level. most attributes (with few exceptions such as order type and currency) at the header are also present at the line level. And even then. in Order Management. but a user cannot make changes. regardless of how or whether an attribute was defaulted. Reports There is a new report in Order Management that you can use to list the Defaulting Rules you have set up. you have the ability when you define Processing Constraints to indicate that you want the system to be able to update an attribute. even though the software enforces that the customer is the same throughout an order. it will only work if you ensure Customer gets defaulted before UOM. there are a few behaviors to take into consideration when creating Conditions. if you define a Condition for defaulting the Unit of Measure by using the Customer. 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 then change them. Assume you have a defaulting rule set up to default a line-level attribute such as Ship Method from the header to the line. Cascading In Order Management. You create an order with several lines and use Ship Method A for the header (and therefore the lines). if you later change the Customer on the order. 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. which will cause behavior different from what we have become used to in R11 Order Entry. the defaulting logic will come into play only when the record is initially created (when you click on a new record on the form). a clear and unambiguous distinction has been made between ‘defaulting’ and ‘cascading’.Dependencies of Attributes Used in Conditions So you must also regard dependencies when you are building Conditions. So what does this mean in real life? Here’s an example. and what the seeded defaulting rule is for each of those attributes. MIGRATION/UPGRADE FROM SVRS Because of the magnitude of the changes to the fundamental architecture between SVRS and Defaulting Rules. because UOM is not dependent on Customer. Cascading. We do not perform cascading in Order Management. or when an attribute upon which this attribute is dependent is changed. defaulting and cascading were intermixed. Defaulting vs. Then you want to change the ship method to Ship Method B. you need to use the new mass change capability. The good news is that the user has explicit and unambiguous control over what lines get changed. means replicating the value of an attribute down to lower level entities. In OE. So in the UOM and Customer example above. 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. then the rule will work during subsequent updates of attribute Y only if attribute X is dependent on attribute Y. where you multi-select the rows you want to change. the UOM will not re-default based on the new customer. making it sometimes difficult to predict what might happen when an attribute at one level was changed. In OM. Defaulting Rules have been seeded that provide equivalent functionality to the R11 seeded SVRS. on the other hand. the decision was made to not upgrade any userdefined SVRS. If a Condition involving attribute Y is used to setup the defaulting rule for attribute X. If you want to change the value of attributes on existing rows. Using Defaulting Rules in Oracle Order Management Page 10 .
• Second. However. and create equivalent Defaulting Rules for the attributes affected. create defaulting rules for entity: Order Header. and then create Defaulting Rules using those Conditions for the necessary attributes. ship-to or bill-to record as required. store their special order type in their Customer. attribute: Order Type. to let the profile option be used. 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. then to the Using Defaulting Rules in Oracle Order Management Page 11 . as a customer is entered on an order. Let’s take the example of a very common business need . you would like users in various departments to always enter orders of a particular type .all their orders generally are of that order type. You would leave this field null for most customers.the need to default the Order Type based on customer (sometimes) and otherwise based on user. a bill-to location or a ship-to location of a customer might even need to have its own special order type. As a matter of fact. that you have a special order type set up just for them . let’s see how you can use Defaulting Rules in real life. EXAMPLE All right now. Order Type was one of those things that always had to be keyed or selected from an LOV. as you want to just set up one set of rules. But in Order Management. for customers with special order type needs. Here’s the business requirement: Some of your customers have such special processing requirements. Use the seeded condition ALWAYS. you can write rules to default the Order Type. Then. 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. whereas your Export Department personnel might enter orders of Order Type ‘International’. for the general case. the defaulting code will look first at the customer bill-to site for a default order type.Domestic CSRs might enter orders of Order Type ‘Domestic’. Here’s how you’d do this: • First.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. This was something that could not be done using SVRS in Order Entry. then to the ship-to record. Typically a user will need to create Conditions corresponding to their particular business need.
it contains an example of setting up these exact rules.customer header. and finally to the new profile option. see the Defaulting Demoshield in the OM Toolbox . 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. thus speeding input time and reducing keying errors. CONCLUSION Oracle Order Management’s use of the new Defaulting Framework provides powerful defaulting capabilities. you can significantly reduce the amount of data that has to be keyed upon entering an order. For a closer look at exactly how to perform these setup steps. if you know how to use them. Using Defaulting Rules in Oracle Order Management Page 12 .
A. CA 94065 U. and Oracle Order Management is a trademark(s) or registered trademark(s) of Oracle corporation. Worldwide Inquiries: Phone: +1.650.Using Defaulting Rules in Oracle Order Management August 2000 Revised September 2000 and November 2001 Author: Charlene Chandonia Contributing Authors: Nithya Lakshmanan. Copyright © Oracle Corporation 2000 All Rights Reserved . Please report any errors herein to Oracle Corporation.S.7200 Web: www.650. Oracle Corporation does not provide any warranties covering and specifically disclaims any liability in connection with this document.506. Linda Henry Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores. All other names may be trademarks of their respective owners. Oracle is a registered trademark.com This document is provided for informational purposes only and the information herein is subject to change without notice.506.7000 Fax: +1.oracle.