Aloz 的 Oracle ERP 天地

Oracle OM 模組有一個功能, 是精華也是特色, 就是 OM 的 Defaulting Rule, 它可以讓 Superuser 設定每個層級所需要的資料, 個別來自於哪一個地方, 好比說 Payment Term, 它可以設定在很多地方, Customer Level / Site Level / Price List 等等, 這時就看公司的需要而自行定義.

大部份的 Defaulting Rule 都是 Seeded (System) 所設定, 也就是系統"不太想"讓你修改, 真的要改的話, 那就是拿出一千零一招 :
1. 先將 DEFCONDN_RULE.SYSTEM_FLAG 改成 N, 然後存檔
2. 修改 Defaulting Sourcing Rule
3. 記得要跑 Tools > Generate Defaulting Handler Package
4. 關掉畫面之後重新查詢, 系統會把 SYSTEM_FLAG 改回 Y

當我開始學習 OM 模組時, 顧問就告訴我 : "Defaulting Rule 只會在 Create 時產生作用", 如果這樣想, 那你就把 Oracle 想簡單了

事實證明, 再 Update 時, Defaulting Rule 也是會生效的, 拿最簡單的例子來說 : Ordered Date.

這個欄位應該是記錄 Sales Order Header 的建立日期或是拿來當做手動維護的接單日期, 理論上應該是只能在 Create 時被輸入或塞值, 但是如果 User 在 Book Order 之後去修改任一欄位, Ordered Date 就會被修改為 SYSDATE, 這就是因為 Defaulting Rule 在作用.

Oracle 也不認為這是 BUG, 因為每一間公司都會有它的定義, 所以 Oracle 只提供修改的方式 : 改 OE_DEPENDENCIES 或 OE_DEPENDENCIES_EXTN

OE_DEPENDENCIES 應該是用來定義欄位之間的主從關係, 當主欄位有任何變動時, 設定的從屬欄位就會依 Defaulting Rule 的設定去重抓資料, 修改這個 Package 比較有破壞力, 所以我覺得還是不要隨便修改比較好, 還是修改 OE_DEPENDENCIES_EXTN 就好. OE_DEPENDENCIES_EXTN 是可以把 OE_DEPENDENCIES 設定的主從關係, 做生失效的動作, 如果修改之後有任何問題,把程式碼刪除或失效就可以, 也可以比較可以判斷出做了哪些修改.

一樣拿 Ordered Date 來說, 因為在 OE_DEPENDENCIES 有定義與 Transaction Phase 的關係, 所以當 Transaction Phase 有變動, Ordered Date 都會去重抓 SYSDATE, 那我們可以在 OE_DEPENDENCIES_EXTN 的 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;

紅字的部分可以參考 OE_DEPENDENCIES 的程式碼, 其餘的部份都不會有變動, L_INDEX 好像一定要加, 因為 Package 裡面的 Example 是這樣寫的.

每個欄位的主從關係也可以參考 OE_DEPENDENCIES 的程式碼.