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 一次修完，希望是不會有問題才是

也順便講一個算是烏龍吧

在 Shipping Transaction > (Tab Page) Delivery 中有一個 Ship Confirm 的按鈕，不用說就是出貨確認的按鈕，這個功能可以利用 Shipping 的權限控制來管控，可是在某一天我發現，我沒有開權限的 User 卻可以使用這個按鈕。我的天阿，這在我們公司可以是天大的問題，可是我查了設定與 User Actions，都沒有發現有任何不對的地方，可是 User 就是看的到也可以使用。

一度以為是之前 Log TAR 之後上的 Patch 有問題，還跑去 Submit new SR，但有一天回家後我突然想到，我好像對於 Ship Confirm 有做 Personalize，而我 Personalize 控制的就是按鈕的 Enable / Disable，隔天上班來確認，噗，還真的是勒，真是對 Oracle 有點不好意思，趕快把 SR 關了 XDDD

也因為這件事呢，我現在寫 Personalize 都不會隨便控制 Enable / Disable，能用 Displayed 就用吧

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 回應，原文貼上：

PROPOSED SOLUTION(S)
======================
Apply Patch. 5853601 Jan 2007, Order Management (11.5.10) Cumulative Patch

PROPOSED SOLUTION JUSTIFICATION(S)
====================================
The issue is resolved by upgrading to file <filename> and version <Version number> or higher.
The following bug outlines this solution:
Bug.Bug 5735404 AUDIT HISTORY CONSOLIDATOR NOT FUNCTIONING PROPERLY WITH DATE PROCESSING CONSTRA
The patch will do the following:
1. make Audit History Consolidator functioning properly for DATE attribute

SOLUTION / ACTION PLAN
=======================
To implement the solution, please execute the following steps:

1. Download and review the readme and pre-requisites for Patch. 5853601

2. Ensure that you have taken a backup of your system before applying the recommended patch.

3. Apply the patch in a test environment.

4. Confirm the following file versions:
OEXPPCHB.pls
You can use the commands like the following:
strings -a $ONT_TOP/patch/115/sql/OEXPPCHB.pls |grep '$Header'

5. Retest the issue.

6. Migrate the solution as appropriate to other environments.