20472427 oracle order management defaulting rules

Using Defaulting Rules in OracleOrder Management

An Oracle White PaperAugust 2000revised November 2001

Using Defaulting Rules in Oracle Order Management Page 1

Using Defaulting Rules in Oracle Order Management

EXECUTIVE OVERVIEWDefaulting is the process by which values get into fields without someone havingto key them. In Release 11 and earlier, the Oracle Order Entry product containeda feature called Standard Value Rule Sets (SVRS) where you defined how youwanted order attributes to be defaulted. In Release 11i Order Management, wehave a new defaulting paradigm called Defaulting Rules, which offers somewhatdiffering functionality. This paper outlines the key differences between SVRS andthe new Defaulting Rules, with tips on how to use the new, more powerfulfeatures.

INTRODUCTIONUsers familiar with Order Entrys Standard Value Rule Sets might look at OrderManagements new Defaulting Rules framework and wonder what happenedhere?. The user interface looks very different and very complex. And thefunctionality seems to behave somewhat differently from the SVRS. The R11iOrder Management Users Guide gives a good explanation of the new forms andfields, but there are nuances of setup and use that are not obvious to the non-technical reader or user.

This paper attempts to explain the key functional differences between the SVRS inOrder Entry and the Defaulting Rules in Order Management, and offer someinsight into making the rules work for you.

BACKGROUNDStandard Value Rule Sets provided great functionality for Order Entry users. Butthey were very much tied to the architecture and functionality of the Order Entryproduct. You could define sets of rules and attach them to order types. Therewas a hard-coded list of sources for each particular data field. It was difficult toextend or customize the rules.

In Order Management, the product architecture has been totally redone and theproduct functionality has been greatly expanded. Every functional area had to bere-designed and re-coded. Some of the enhancements that users had beenrequesting in the area of SVRS could not be accommodated without revamping theentire structure of defaulting. The design goal was to create a defaultingframework that other products could use, too, since most applications need similar


capabilities. So the decision was made to design a more generic solution fordefaulting. The Defaulting Rules Framework is the result of that re-design.

FUNCTIONAL DIFFERENCESTo an Order Entry/Management user or implementer, the biggest difference fromSVRS is that with Defaulting Rules, you define a set of rules for each attribute onthe 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 contextof an order type. But once you start thinking of attributes in this way, the newframework seems more straightforward and intuitive.

The new framework also brings somewhat more flexibility in where you candefault from and to, as well as a way for you to invoke your own PL/SQL packageto perform more complex logic.

Key EnhancementsSome 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 tobe hard-coded.

the ability to define formulas to create the defaulted data - see Source ofValues section below.

a clear distinction between defaulting behavior and cascading - see WatchOut For section below.

Terminology Since Defaulting Rules are now generic, and potentially can be used by otherOracle applications, were using more generic names for the things you defaultfrom and to. Attributes and Entities are the things you default to. Sources arewhere things default from. See Source of Values section below on all the variousplaces you can default from.

Attributes and Entities in Order Management An Entity in this context is a group of related attributes that roughly correspondto a table or a form in Order Management. So we have entities of Order Header,Order Line, Order Price Adjustment, Line Price Adjustment, etc. Entitiescorrespond to blocks in the old SVRS.

An Attribute is a field or column that belongs to that entity. Therefore, theordered unit of measure is an attribute of the Order Line entity. Attributescorrespond to fields in the old SVRS. When you query up the Defaulting Setupform for a particular entity, youll see a list of all the attributes for which you candefine defaulting rules. As in OE, you will not be able to define defaulting rules


for descriptive flexfields, since their defaulting is controlled by AOLs flexfieldroutines.

Conditions Conditions are rules you set up that will control when a particular group ofdefault sources will be looked at. You define one or more condition validationtemplates based on whatever common business rules you may have. You defineone or more of these condition templates per entity, and then you can use them overand over for the attributes of that entity. For example, then, you might set up acondition 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 ofConditions and using them in rules, be sure to place the ALWAYS condition lastin the Precedence for Defaulting Conditions.

Defining Condition Validation Templates Once you query up the entity that you want to work with in the Defaulting Setupform (use the flashlight icon to get the LOV of available entities), press theDefaulting Condition Template button to get to the form to define the conditions.Youll see a form that lists all the conditions already defined for this entity. To adda new one, go to a blank line (or use the green + icon to create a blank line) andkey 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 aredefining or viewing.

The Group Number is just an arbitrary number you enter to control andand or conditions. You indicate that rules are to be connected by an andrule by giving them the same group number, whereas rules you want to beconnected by or should be given different group numbers.

In the Attribute column, choose from the list of attributes you can base acondition on. Available attributes that show up here are ones from thisentity that have the Include in Building Defaulting Conditions checkboxchecked on the Defaulting Setup - Entity Attributes form. The onlyattributes that have this checkbox checked are ones that are the source for adependency relationship. See section on Dependencies below. And youcannot add to this list of attributes.

In the Operator column, choose an operator from equal, not equal, greaterthan, less than, not greater than or not less than.

In the Value String column, key in (or choose from the LOV) the actualvalue you want to compare to.

Sequence of Defaulting On the main Defaulting Setup screen, where all the attributes of the entity arelisted, there is a column called Defaulting Sequence. This number determines the

Here is how you define DefaultingCondition Templates.


order in which attribute defaulting takes place. When attributes have equalsequence numbers, defaulting takes place alphabetically. All the attributes areseeded with a sequence of 50. You can change these sequences, if you needdefaulting to happen in some different order. For example, you might define asourcing rule that says default attribute A on the line from attribute B on the sameline. In this case, you need to insure that the Attribute B gets its value before A isdefaulted, or the rule will not work as you expect.

Sources of Values Sources are places where values can be defaulted from. Defaulting Rules providea variety of sources that you can use in building your defaults. Most of them willbe 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 systemprovided profile option, or a new profile option that youve defined just toprovide 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 upthe Promise Date to default from the Request Date on the same line.

Related Record - is the value of another attribute on a related entity (orrecord). For example, you might set up the Ship Method on the line todefault from the Ship Method on the header. Or some attribute on theorder header might default from an attribute on the related customer record.

System Variable - is the value of a system (server) variable, such as SystemDate. For this type of source (and this type only), you can use an expressioncontaining a formula, for example, sysdate + 7.

PL/SQL API - is where you provide your own routine to provide thedefault. 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 tospecify a PL/SQL API or you can look in the Rule Based DefaultingFramework HLD for technical details.

others - there are several esoteric source types relating to the Web AppDictionary definitions for this attribute. Most people wont want to usethese. They are documented in the Rule Based Defaulting FrameworkHLD, if you really want to know.


Defining Sourcing Rules

Once you query up the entity that you want to work with in the Defaulting Setupform and have defined your Conditions, you are ready to define your SourcingRules. Select the attribute you want to work on, and then click on the DefaultingRules button to get to a form called Attribute Defaulting Rules. This form lists allthe conditions and rules that have been previously defined for this attribute. Toadd a new condition and its rules, go to a blank line in the Defaulting Conditionssection of the form (or use the green + icon to create a blank line) and key in aprecedence and choose from conditions you have already defined. (Theprecedence 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 aredefining or viewing for this condition. This set of defaulting rules will be used if itscorresponding Defaulting Condition is TRUE.

The Sequence here controls the order in which the system attempts to locatea default.

In the Source Type column, choose from the list of Source Types asdescribed above.

In the Default Source Value column, you specify the attribute or value youwant to use for the source. What you can choose here depends on theSource Type you have selected. There is a good table in the Setup section ofthe Oracle Order Management R11i Users Guide that explains the variousoptions per Source Type. What youll see in this field is a flexfield whosecontext is based on the Source Type. Then you can choose among pre-seeded possible source attributes.

Similar to what occurred in Order Entry, you cant default things from justanywhere. The data type has to match that of the attribute you are defaulting, andthe source relationship has to be pre-defined.

Dependencies Some attributes are dependent upon the value of other attributes on the samerecord. If an attribute is changed, either by the user or by the system, any otherattribute that is dependent on it will be cleared and then re-defaulted. Forexample, 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 viapatch for bug 1343621), functionality was changed for certain fields such that if re-defaulting did not come up with a default for the dependent field, the old valuewould 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 dependencieshave been provided. Alternatively, you can also check current code in the

Here is how you define Default SourcingRules.


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 allowusers to create their own dependencies. Until such time as that enhancement isprovided, if you need to create additional dependencies or disable existingdependencies 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 guidelinesdocumented in the file are followed. Following the guidelines also ensures thatpatches 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 thedependencies is restricted. Please refer to comments in file OEXEDEPB.pls forthe complete list. ii) Dependencies can be established only among attributes on the same entity, notacross entities i.e. changing an attribute on order header will NOT result in achange to attributes on order line.

The code modifications are relatively easy. Below are examples to add to remove adependency.

Add a Dependency

User sets up a defaulting condition based on Order Type A and uses thiscondition to default Salesperson A if Order Type is A. For this rule to work, anew dependency needs to be enabled. The Source Attribute is Order Type, andthe Dependent Attribute is Salesperson. The entity on which this dependencyneeds to be defined is Order Header so add the dependency code under the IF forheader 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/orupdated. The user deleted/disabled the defaulting rule to default Invoice To fromShip To and still the behavior does not change. The reason is that there is ahardcoded dependency of Invoice To on the Ship To field. To ensure that InvoiceTo is not affected by a change to Ship To, the dependency of Invoice To on ShipTo 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 InvoiceTo on the order Line, the dependency should be separately disabled for the Lineentity.

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 dependentattribute that is not listed in OEXEDEPB.pls, you have to do a little more.

This requires CUSTOMIZATION of existing packages. Patches in the futuremight over-write your changes. Adding a new Source Attribute:

For example, you want to make Shipping Method on the header dependent onShipment Priority. First you need to add a dependency in OEXDEPB.pls asabove with Source Attribute: Shipment Priority; Dependent Attribute: ShippingMethod. Since Shipment Priority is not listed as one of the source attributesavailable on Order Header, you also need to CUSTOMIZE another entity specificutility 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 orderline to also affect Shipping Method on the order line entity, code similar to thefollowing 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 onDemand Class. Again, you need to add a dependency in OEXDEPB.pls as abovewith Source Attribute: Demand Class; Dependent Attribute: Planning Priority. IfDemand Class is not listed as one of the source attributes available on Order Lineentity, you need to go through the steps outlined earlier to add it as a sourceattribute. And if Planning Priority is not listed as one of the dependent attributesfor order line entity, you also need to CUSTOMIZE another section of the entityspecific 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 withG_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 callthis 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 & addsimilar 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 whereyou could control changes to an attribute. You could check whether or not toallow users to override a defaulted value (Override Allowed) and you couldcontrol whether the rules should re-default over user-specified values (OverrideUser-Specified Values). These checkboxes often were viewed to be confusing andto operate inconsistently. Order Managements Defaulting Rules solved thatproblem by getting rid of those checkboxes. Instead, you control who can change


data (and when) using the new Processing Constraints framework, regardless ofhow or whether an attribute was defaulted. In addition, you have the ability whenyou define Processing Constraints to indicate that you want the system to be ableto update an attribute, but a user cannot make changes.

The only time that Defaulting Rules result in a change to an existing attribute onan entity is when that attribute has a dependency on another attribute that hasbeen changed.

Reports There is a new report in Order Management that you can use to list the DefaultingRules you have set up. It replaces the old OE Standard Value Rules Listing. Thereport is called Defaulting Rules Listing, and it has parameters to allow you tolimit 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 implementdefaulting for your company. However, there are a few behaviors to take intoconsideration when creating Conditions.

What Attributes can you use? Be aware that Conditions you create for an entity can only be based on attributesthat belong to that entity. Therefore, for example, you cannot set up a Conditionfor a line attribute based on the order type because order type is a header attribute.Youll have to examine carefully your business rules so you can state Conditions interms of attributes on the same level. Fortunately, in Order Management, mostattributes (with few exceptions such as order type and currency) at the header arealso present at the line level. Even the sold-to customer is present as a line-levelattribute, even though the software enforces that the customer is the samethroughout an order. This way, the customer can be used in a condition templatefor the line.

Sequencing of Attributes Used in Conditions Sequencing of defaulting of attributes plays an important role in the correct designof Conditions and Sourcing Rules. If you create a rule for attribute X based on aCondition using attribute Y, you must be sure that attribute Y gets defaultedbefore attribute X, or your Condition will not evaluate true. For example, if youdefine a Condition for defaulting the Unit of Measure by using the Customer, itwill only work if you ensure Customer gets defaulted before UOM. And eventhen, it will only work for the initial defaulting of the UOM field. And that isbecause of Dependencies.


Dependencies of Attributes Used in Conditions So you must also regard dependencies when you are building Conditions. If aCondition 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 Xis dependent on attribute Y. So in the UOM and Customer example above, if youlater change the Customer on the order, the UOM will not re-default based on thenew customer, because UOM is not dependent on Customer.

Defaulting vs. Cascading In Order Management, a clear and unambiguous distinction has been madebetween defaulting and cascading, which will cause behavior different from whatwe have become used to in R11 Order Entry. In OE, defaulting and cascadingwere intermixed, making it sometimes difficult to predict what might happen whenan attribute at one level was changed. In OM, the defaulting logic will come intoplay only when the record is initially created (when you click on a new record onthe 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 tolower level entities. We do not perform cascading in Order Management. If youwant to change the value of attributes on existing rows, you need to use the newmass change capability, where you multi-select the rows you want to change, andthen change them.

So what does this mean in real life? Heres an example. Assume you have adefaulting rule set up to default a line-level attribute such as Ship Method from theheader to the line. You create an order with several lines and use Ship Method Afor the header (and therefore the lines). Then you want to change the shipmethod to Ship Method B. Changing this attribute at the header will result in anysubsequent new lines getting Ship Method B defaulted onto them. The existinglines that have Ship Method A will not get changed to B as a result of yourchanging the header attribute. You will need to use mass change to do that. Thegood news is that the user has explicit and unambiguous control over what linesget changed.

MIGRATION/UPGRADE FROM SVRS Because of the magnitude of the changes to the fundamental architecture betweenSVRS and Defaulting Rules, the decision was made to not upgrade any user-defined SVRS. Defaulting Rules have been seeded that provide equivalentfunctionality to the R11 seeded SVRS. There is a good table in Appendix E of theOracle Order Management R11i Users Guide that lists all attributes of the OrderHeader and Order Lines entities, and what the seeded defaulting rule is for each ofthose attributes.


Users of Order Entry who created their own Standard Value Rules or customizedthe seeded rule sets will need to carefully review the logic behind their changes orcustomizations, and create equivalent Defaulting Rules for the attributes affected.Typically a user will need to create Conditions corresponding to their particularbusiness need, and then create Defaulting Rules using those Conditions for thenecessary attributes.

EXAMPLE All right now, lets see how you can use Defaulting Rules in real life. Lets take theexample of a very common business need - the need to default the Order Typebased on customer (sometimes) and otherwise based on user. This was somethingthat could not be done using SVRS in Order Entry. Order Type was one of thosethings that always had to be keyed or selected from an LOV. But in OrderManagement, you can write rules to default the Order Type.

Heres the business requirement:

Some of your customers have such special processing requirements, that you have aspecial 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 evenneed to have its own special order type. However, for the general case, you would likeusers in various departments to always enter orders of a particular type - DomesticCSRs might enter orders of Order Type Domestic, whereas your Export Departmentpersonnel might enter orders of Order Type International.

Heres how youd do this:

First, create a new custom profile option that youll have the systemadministrator use to specify the default order type for differentresponsibilities or users.

Second, create defaulting rules for entity: Order Header, attribute: OrderType. Use the seeded condition ALWAYS, as you want to just set up oneset 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 ordertype in their Customer, ship-to or bill-to record as required. You wouldleave 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 thecustomer 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 DefaultingDemoshield in the OM Toolbox - it contains an example of setting up these exactrules.

CONCLUSIONOracle Order Managements use of the new Defaulting Framework providespowerful defaulting capabilities, if you know how to use them. You need tothoroughly understand Conditions and Dependencies so that you can design howyour 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 enteringan order, thus speeding input time and reducing keying errors.

Using Defaulting Rules in Oracle Order ManagementAugust 2000Revised September 2000 and November 2001Author: Charlene ChandoniaContributing Authors: Nithya Lakshmanan, Linda Henry

Oracle CorporationWorld Headquarters500 Oracle ParkwayRedwood Shores, CA 94065U.S.A.

Worldwide Inquiries:Phone: +1.650.506.7000Fax: +1.650.506.7200Web: www.oracle.com

This document is provided for informational purposesonly and the information herein is subject to changewithout notice. Please report any errors herein toOracle Corporation. Oracle Corporation does notprovide any warranties covering and specificallydisclaims any liability in connection with this document.

Oracle is a registered trademark, and Oracle Order Management is a trademark(s) or registered trademark(s) of Oracle corporation.All other names may be trademarks of their respective owners.

Copyright Oracle Corporation 2000All Rights Reserved

20472427 oracle order management defaulting rules

Documents