Aloz 的 Oracle ERP 天地

這個功能我已經是第二次做SR了，看來問題還真多
不過還好，第三天就給我一個 Patch 了

---

明確的問題發生原因也不是太確定，但是我自己試出來的原因是，如果在 Run "Audit History Consolidator" 這一隻 Request 時，它抓取到多筆的 SO Change Records，就會造成拋到 OE_AUDIT_ATTR_HISTORY的資料會有垃圾。垃圾的意思是說，我明明改的是 Order Qty，它會記錄到沒錯，但是卻可能多記了一筆  Unit Selling Price = New Order Qty 的 Record，這筆 Record 就是我指的"垃圾資料"
這個問題 Oracle 給我了一個 Patch : 5753510，不大不小，聽 DBA 說這是 OM 的整體修正 Patch，把一段時間累積下來的 BUG 一次修完，希望是不會有問題才是

Oracle OM 標準的 Quote 只能產生一張 Sales Order，這個機制對我們來說並不適合，所以我們轉而使用 Blanket Sales Agreement (BSA)。
BSA 可以重複不斷的產生 Sales Order，也可以綁價格表 (Price List)，當然也可以設定使用時間區間。
但是，打訂單的時候我們發現，如果去修改 Request Date，系統應該是要重新抓取對應到的 Blanket Line，卻沒有抓到造成 SO Line 的 Blanket Line Number 欄位被清空，進而發出 Note Message；如果再修改一次 Request Date，這次就抓到了。就演變成改一次不可以，改第二次可以的錯誤循環。
一樣，我去 Oracle Log TAR，Oracle 似乎不認為這是 BUG (?)，所以給我以下的修正方式：
Package Name：OE_Dependencies_Extn
在 ELSIF p_entity_code = OE_GLOBALS.G_ENTITY_LINE THEN 底下新增下列 Code：
-- to disable dependency G_REQUEST_DATE -> G_BLANKET_LINE_NUMBER,
x_extn_dep_tbl(l_index).source_attribute := OE_LINE_UTIL.G_REQUEST_DATE;
x_extn_dep_tbl(l_index).dependent_attribute := OE_LINE_UTIL.G_BLANKET_LINE_NUMBER;
x_extn_dep_tbl(l_index).enabled_flag := 'N';
l_index := l_index + 1;
oe_debug_pub.add('G_BLANKET_LINE_NUMBER', 1);

就解決了我的問題。

我們對於訂單資料需要做很多的控管，尤其在 Book 之後更是重要。
Oracle OM 有提供一種功能：Audit History
IT 可以幫助 User 很快很直接的設定要控管的欄位，可在 OM > Setup > Rules > Security > Processing Constraints 中設定。
但是，看似完美的功能，卻發現了一個 BUG (BUG# 5735404)
這個功能對於「日期」欄位會發生 SQL Error，經過Log TAR之後，Oracle 告訴我這是一個 Internal BUG，也有一個對應的 Internal Patch，所以，直接在 Metalink 上找不到。
Patch Number：5853601
以下為 Oracle SR 回應，原文貼上：