Oracle OM Defaulting Rules – Document 414120.1

OM_Defaulting (Discusses how to create custom PL/SQL API source)

DEF_RULE

Source: Document 414120.1

Oracle Order Management – Version 11.5.10.0 and later
Oracle iStore – Version 12.0.6 and later
Information in this document applies to any platform.
OEXOEORD.fmb, OEXDEFWK.fmb
***Checked for relevance on 27-NOV-2013***

Background docs locally:
OM_Defaulting
DEF_RULE

Purpose

Order Management Suite – Defaulting Library

This document lists notes used for Defaulting within Order Management.

Questions and Answers

  1. Note 1320122.1  OM-DEF: Defaulting Rules – FAQ
    This note reviews the following subjects:

    1. General Defaulting Rule setup
    2. Importance of running the Defaulting Generator concurrent program
    3. Running the Defaulting Rules Listing Report
    4. Important notes to keep in mind when working with Defaulting Rules
    5. How to add PL/SQL API as Defaulting Source
    6. How to add a Dependency in package OEXEDEPB.pls ($ONT_TOP/patch/115/sql/OEXEDEPB.pls )
  2. Note 122461.1  ORDER MANAGEMENT DEFAULTING – USING DEFAULTING RULES IN ORACLE ORDER MANAGEMENT
    This paper attempts to explain the key functional differences between the SVRS in Order Entry and the Defaulting Rules in Order Management, and offers some insight into making the rules work for you.
  3. Note 391576.1 The Defaulting Rule for Tax Exempt Attribute is Not Working Properly
    This note explains the standard functionality and a work around for this issue
  4. Note 371305.1 How To Use The Currency From The Customer In The Defaulting Rules?
    This note explains how to default currency from the customer record “Profile: Amounts.”
  5. Note 343123.1 OEXOEORD: Ship To Contact Name Does Not Default Into Order Header
    This note explains the setup issue for defaulting the Ship to Contact Name.
  6. Note 391357.1 OEXOEORD: Default Rule Value Overridden When Price List Entered
    This note explains why after upgrading to 11.5.10.2 from 11.5.8. When you select the currency CAD, the system defaults the value of ‘Corporate’ for conversion type. But after selecting a Canadian price list, the conversion type becomes blank.
  7. Bug 5991020 Default Value for DFF doesn’t get populated if navigation is changed.
    Descriptive Flexfields are not like other fields which have standard functionality. DFF fields are highly customizable and any functionality can be attached to them by each customer. In this case the DFF is being given a functionality wherein the DFF value is dependant on Ship To. Some other customers might have defined the functionality of the DFF to be dependant on some other field. So it is not possible for OM to seed any dependancy between any of the standard fields and DFF fields. It is upto the customer to define the full functionality of the DFF fields and write custom code to ensure that these fields are populated appropriately. In this case FND defaults the DFF values only when the DFF window is invoked for the first time. If user invokes the DFF and goes back and populates / changes the Ship To and navigates back to the DFF, system does not re-default the values. This is because system is not aware of any dependancy between any of the standard fields and the DFF field. In this case we suggest customer to write custom code in When-Validate-Trigger to ensure that the DFF has a valid value and that it is a valid value. Customers can use either CUSTOM.pll or forms personalizations for this.
  8. On 11.5.10 in Production: Find the request date is changed on the order line the following attributes are cleared and re-defaulted:
    > Price list
    > Ship-to
    > Bill-to
    > Warehouse
    > Freight Terms
    > Payment Terms
    > Ship MethodReview the OEXEDEPB.pls file – be sure it simulates x_extn_dep_tbl (l_index).dependent_attribute :=  OE_LINE_UTIL.G_INVOICING_RULE;
    x_extn_dep_tbl (l_index).dependent_attribute := OE_LINE_UTIL.G_SHIP_TO_ORG;
  9. BUG 6139896 Defaulting Rules are not working for Shipping Method on the Order Line.
    The defaulting rule for the shipping method on the order line was defined to pull the value from the shipping method on the order header. When the ship_to on the order header was changed, the defaulting rule for the shipping method on the order header did not return a value. Therefore NULL was cascaded to shipping method on the order line. Once the defaulting rule for the order header was corrected, NULL was no longer cascaded to the order line.
  10. BUG 6139502 Defaulting Rule not working for Customer Location.Payment Term
    In order for the customer location to be considered as a source for the payment term on the order header the location must be defined as usage sold_to in Receivables. If the customer location is selected manually, the Patch 5124805 must be installed so that the payment term is a dependent attribute on the customer location.
  11. Note 394099.1 OEXOEORD: ‘Ship Method’ Re-Defaults When ‘Ship To’ Is Changed
    Whenever an attribute is changed, all attributes that directly or indirectly
    depend on it are cleared and re-defaulted. This is the current expected behavior.It is possible to control to a certain extent the dependency between
    attributes. For details on controlling
    attribute dependencies, please see Note 113634.1 to customize defaulting using API hook
    – package OE_Dependencies (the file name is OEXUDEPB.pls).
  12. Note 748269.1 Changes On Order Header Cause Ordered And Request Dates To Re-Default
    Changes On Order Header Cause Ordered And Request Dates To Re-Default
    Transaction phase code itself is indirectly dependent on ship to location.
    Disable dependency between ORDERED_DATE and TRANSACTION_PHASE
    at the header level.Use code in OEXEDEPB.pls :

    IF p_entity_code = OE_GLOBALS.G_ENTITY_HEADER THEN
    x_extn_dep_tbl(l_index).source_attribute:=OE_HEADER_UTIL.G_TRANSACTION_PHASE;
    x_extn_dep_tbl(l_index).dependent_attribute:=OE_HEADER_UTIL.G_ORDERED_DATE;
    x_extn_dep_tbl(l_index).enabled_flag := ‘N’;
    l_index := l_index + 1;
  13.  Note 834630.1 Why FOB Field Get Blank After Pricing Date Update?
    FOB Point is dependent on the pricing_date field. There is a dependency (defined in the file OEXUDEPB.pls) which causes the FOB to be cleared whenever the pricing_date is changed. This is the designed behavior.
  14.  Note 985053.1 WHY DOES ORDER ‘ITEM IDENTIFIER TYPE’ FIELD AUTO CHANGING AFTER UPDATING SHIP TO
    There is a seeded dependency between the Ship to and Item Identifier.
    You can disable this dependency by disabling it in OEXEDEPB.pls :

    ELSIF p_entity_code = OE_GLOBALS.G_ENTITY_LINE THEN
    — Sample Code for Disabling dependency of Invoice To on Ship To
    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_ITEM_IDENTIFIER_TYPE;
    x_extn_dep_tbl(l_index).enabled_flag := ‘N’;
    l_index := l_index + 1;
  15.  Note 987363.1 R12: Tax Code re-defaulting after manual adjustment and then changing the Request Date.
    This is standard behaviour given the seeded defaulting rules framework in place.
    A potential “work-around” should this behaviour not be desired is to utilise the defaulting “extensions” framework to “disable” the Request date – Tax Code relationship as detailed in Note 122461.1 Using Defaulting Rules in Oracle Order Management.
  16.  Note 731485.1 OEXOEORD: Tax Code Gets Re-Defaulted After Booking Order1. Change the Tax Code only after the Line is scheduled. But with this approach, when ever
    Schedule Ship Date changes, Tax Code will get re-defaulted.or

    2. Disable the seeded dependency between Schedule Ship Date and Tax Date. This you can do by adding code in OE_DEPENDENCIES_EXTN package. Below code can be used to do the same :

    l_index := 1;
    x_extn_dep_tbl(l_index).source_attribute := OE_LINE_UTIL.G_SCHEDULE_SHIP_DATE;
    x_extn_dep_tbl(l_index).dependent_attribute := OE_LINE_UTIL.G_TAX_DATE;
    x_extn_dep_tbl(l_index).enabled_flag := ‘N’;
    l_index := l_index + 1;
  17.  Note 1088777.1 Payment Term And Shipping Method Are Nulled After Save Order
    Payment_term and shipping_method are dependent on price_list.Disable the dependency of SHIPPING_METHOD and PAYMENT_TERM on PRICE_LIST
    using the hook OE_Dependencies_Extn (File: $ONT_TOP/patch/115/sql/OEXEDEPB.pls) so that SHIPPING_METHOD and PAYMENT_TERM will not be cleared when changing the price list.
  18.  Note 579027.1 How to get Payment Term to not redefaultIt needs to be understood that the field payment term is a dependent attribute for around 6 attributes which are (Agreement, Invoice_to_org, Ship_to_org, Sold_to_org,Price_list, Blanket_number). So upon changing any of these attributes, payment term will get cleared and redefaulted.Ship_to_org has price_list and invoice_to_org as dependent attributes. In the
    above case, even though the dependency between ship_to and payment term is disabled, upon changing ship_to, invoice_to_org and price_list will get cleared and redefaulted and since payment term is dependent on both of them, even it would get cleared and redefaulted.

    So if you do not want the payment term to be redefaulted, you have to disable the dependency between invoice_to_org and payment_term and also between price_list and payment term by befining the payment term as the dependent attribute.

  19. Currently the defaulting rules for Payment Term does not support defaulting from the customer address profile.You can choose to defaultt the Payment term from Ship To,  Bill to or Customer Location.
    Order management picks payment terms from sold_to site usage if the defaulting rule is set to related record customer location .Payment term .
    If the defaulting rule is : CustomerLocation. PaymentTerm => we default the value from Customer -> Address -> Sold_To -> PaymentTerm.There is an enhancement request :
    Bug 4531198 DEFAULT PAYMENT TERMS FROM BILL-TO CUSTOMER PROFILE

References

BUG:5331735 – DEFAULTING GENERATOR HAS ERROR IN LOG, DEFAULTING RULE NOT WORKING
BUG:5402563 – OEXOEORD: DEFAULT CONVERSION TYPE OVERRIDDEN WHEN SELECTING PRICELIST
BUG:5512474 – THE DEFAULTING RULE FOR THE TAX EXEMPT ATTRIBUTE IS NOT WORKING PROPERLY
BUG:5944651 – BLANKET SALES AGREEMENT – PATCH 5614571 SOLUTION. CANNOT USE.
BUG:5991020 – DEFAULT VALUE DOESN’T GET POPULATED IF NAVIGATION IS CHANGED.
NOTE:987363.1 – R12: Tax Code re-defaulting after manual adjustment and then changing the Request Date.
NOTE:985053.1 – WHY DOES ORDER ‘ITEM IDENTIFIER TYPE’ FIELD AUTO CHANGING AFTER UPDATING SHIP TO
NOTE:343123.1 – OEXOEORD: Ship To Contact Name Does Not Default Into Order Header
NOTE:371305.1 – How To Use The Currency From The Customer In The Defaulting Rules?
BUG:6139502 – ONDEMAND:DEFAULTING RULES NOT WORKING FOR: CUSTOMER LOCATION.PAYMENT TERM
NOTE:731485.1 – OEXOEORD: Tax Code Gets Re-Defaulted After Booking Order
BUG:5124805 – HIGH CPU IN DB2 ACCESSING A PARTITIONED TABLE VIA THE GATEWAY
BUG:6139896 – DEFAULTING RULE NOT WORKING FOR SHIPPING METHOD ON ORDER LINE
NOTE:1088777.1 – Payment Term And Shipping Method Are Nulled After Save Order
NOTE:113634.1 – OM-DEF: Defaulting Rules – Setup
NOTE:122461.1 – Using Defaulting Rules in Oracle Order Management
NOTE:1320122.1 – OM-DEF: Defaulting Rules – FAQ
BUG:5282526 – CODEFIX:PROBLEM WITH DEFAULTING RULES
NOTE:373670.1 – Defaulting Generator Has Error In Log, Defaulting Rule Not Working
NOTE:391357.1 – OEXOEORD: Default Rule Value Overridden When Pricelist Entered
NOTE:391576.1 – The Defaulting Rule For The Tax Exempt Attribute Is Not Working Properly
NOTE:394099.1 – OEXOEORD: ‘Ship Method’ Re-Defaults When ‘Ship To’ Is Changed
NOTE:414115.1 – Order Management Defaulting Overview
NOTE:579027.1 – How to get Payment Term to not redefault
NOTE:748269.1 – Changes On Order Header Cause Ordered And Request Dates To Re-Default
NOTE:834630.1 – Why FOB Field Get Blank After Pricing Date Update?

Leave a Reply