目前日期文章:200804 (3)

瀏覽方式: 標題列表 簡短摘要

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 的程式碼.

Aloz 發表在 痞客邦 留言(0) 人氣()

這篇算是個警訊吧,

如果有在使用 Oracle BI Publisher 寫報表, 而且你的 Word 有更新到 2003 SP3, 那編輯出來的 RTF 檔會有不相容的情況發生, 會造成產出的 PDF 檔沒有表頭表尾,  Metalink 目前沒有看到相關文章, 可能是因為 Word 2003 SP3 剛出沒有很久, 要嘛就等 Patch, 要嘛就先灌回 SP2, 請小心

Aloz 發表在 痞客邦 留言(0) 人氣()

我們家的 User 很喜歡系統發 Mail 通知他們一些事情, 可能這樣會讓他們覺得系統很聰明吧 , 所以, 這段時間 Alert 就寫了一堆 XD

一樣, 也是寫一些簡單的心得 :

- Alert 只能發出純文字的內容, 不能夾檔, 也不能用 HTML 去寫, 所以 Alert 不能跟 Notifications 一樣漂亮

- Alert 的觸發可以分成 Schedule 與 Event, Schedule 就是自己訂時間, 系統就依照 SQL 把串出來的資料寄出. Event 就是利用 DB Trigger 的方式觸發, 不過預設的 DB Trigger 是針對整個 Table, 如果需要針對特定欄位做觸發, 就需要自己手動去 Trigger 加條件. Alert 產生的 DB Trigger 有 Naming Rule, 所以很好分 : ALR_<TABLE_NAME>_<字尾>, 字尾就看你是 After Insert = IAR, After Update = UAR 來決定

- Event 的 Alert SQL 都必須要加上 XXX.ROWID = :ROWID, 這樣才能夠正確判斷出是哪一筆資料觸發了 Event

- 如果要針對同一個 Table 發出兩封不同的 Alert, 好像是因為 Trigger 無法區分, 會造成兩封會有衝突 (有一封會一直有 Error), 在沒找到解法前, 我的做法是 :
    A. 對個別的情況先寫各別的 DB Trigger, 把相關資料寫到 Temp Table
    B. Alert 的 Event 再針對 Temp Table 做監看即可

- 發出的信也可以分成兩種 : Detail 與 Summary, Detail 就是 SQL 串出幾筆, Mail 就寄出幾筆, Summary 就是可以有表頭表身, 那表身像表格, 標題是可以重複的. 我個人比較喜歡把 Event 的 Alert 發成 Detail, 而 Schedule 的 Alert 發成 Summary

- Summary 的表身資料, 每一行的最前面都必須要空兩格, 我也不知道為什麼, 只知道不空的話前兩個字會被截斷

- 每一封 Alert 都要設定 Actions (Mail內容), Action Sets, Alert Details, Alert Details 是比較容易被忘記的, 因為裡面的 Installations 沒有指定 APPS 的 OU 的話, 是不會正常動作的

- 如果內容有純數字資料, 建議去 Alert Details 裡定義最長長度, 這樣格式比較好抓不會亂跑

Aloz 發表在 痞客邦 留言(3) 人氣()

您尚未登入,將以訪客身份留言。亦可以上方服務帳號登入留言

請輸入暱稱 ( 最多顯示 6 個中文字元 )

請輸入標題 ( 最多顯示 9 個中文字元 )

請輸入內容 ( 最多 140 個中文字元 )

請輸入左方認證碼:

看不懂,換張圖

請輸入驗證碼