Aloz 的 Oracle ERP 天地

每次突然要用什麼函數, 都要上 Google 去找, 乾脆整理起來

不然每次都忘記要重找

錯誤訊息 : Not all rows have been retrieved. Data may be inaccurate.

原因 : 資料筆數超出限制

解法 : 修改設定

1. Tools -> Options -> Query Governor (to set up permanently)
2. Tools -> Retrieve all rows (to get all rows for particular workbook)

如果需要程式更新 Sales Order 上的 Sales Person, 除了 OE_ORDER_HEADERS_ALL 與 OE_ORDER_LINES_ALL 之外, 還必需更新 OE_SALES_CREDITS, 原因如下 :

- AR 的 Receivable 如果設定某節段要抓 Sales Person 的設定, 會去參考 OE_ORDER_LINES_ALL 的 Sales Person (SALESREP_ID)

- AR 的 Revenue 如果設定某節段要抓 Sales Person 的設定, 會去參考 OE_SALES_CREDITS 的 Sales Person (SALESREP_ID)

如果需要整行變色, 一個欄位寫 Set Item Property, 這樣太累了, 如果欄位又多, 更是不可能, 上網找了資料後, 整理了寫法如下

1. 先設定 Form 的 Visual Attribute, 屬性就設定 Background Color 為需要的顏色

2. 在所需要觸發的 EVEN Trigger (ex: BLOCK 的 POST_QUERY) 之下, 呼叫以下 Procedure

揀貨 (Pick) 分為兩段, 第一段是在 OM 中的 Pick Release, 第二段則是 INV 的 Move Order, Pick Release 會產生一張 Move Order, 此時會決定揀貨的來源倉儲位置, 與目的倉儲. Oracle 標準的 Pick Rule 功能, 可以幫助我們設定很多不同的來源與目的倉儲.

設定的部份分為三部份 : Order / Shipping / Inventory

Inventory 的部份, 就是設定來源與目的倉儲的地方, 依照每一個 Subinventory設定的不同, Pcik Rule 的設定方式也不相同

-範例1

來源倉可以不設定儲位, 就表示這個倉裡面的所有儲位都可以揀. 目的倉如果本身就沒有儲位, 那也就不用指定 (虛擬倉比較會有這樣的設定)

-範例2

如果 ERP 沒有設計特定的出貨倉, 又因為來源倉儲不能完全等於目的倉儲 (A1 -> A1 是不行的), 所以可以在原倉設定一虛擬儲位

-範例3

當然也可以直接設定來源倉儲, 這樣就只能揀該倉儲位的東西 (儲位打一下馬賽克 XD)

另外, 如果目的倉是有儲位的, 但沒有設定, 這樣在第二段的揀貨會失敗

Credit Hold 目前使用到的有幾種類型 : Overall Limit Exceeded, Order Limit Exceeded, Overdue Invoices Found

因為類型只在於 Hold Comment 不同, Hold Type 都一樣 (Credit Check Failure), 所以, 類型不同的 Credit Hold 不會重疊

之前有發現到一個問題, 我這邊需要設定兩段的 Credit Check Rule, 一段設在 Booking 時, 另一段要設在 Picking, 而且兩段的 Check Rule 完全不一樣.

Booking 時就是比較一般的 Check (Open SO, Open AR ... 等等), 但是 Picking 就""只要""檢查是否有 Open AR 已經 Overdue 超過 31 天, 也就是說, Open SO / Open AR 都不看.

但是 Oracle 的 Credit Check Rule 畫面, 強迫使用者 Open SO 與 Open AR 一定要擇其一, 該如何設定只看 Overdue 呢?

1. Exposure 頁面只選擇 "Include Open receivables Balance"

2. Open Receivables Days 設定 "-1"

設定為空值應該表示為全看, 設定為 0 還是會算到當天立的 AR

3. Maximum Days Past Due 就依照需要設定天數即可 (我們是超過 30 天, 所以就設定 31)

Order Import 時, 最主要的動作可以分為三大類 : Split, Update 與 Cancel, 原本以為在 Split 的同時, Update 也是可以一並處理的, 但是一直會出現一個問題, 就是 Sales Order Line (OE_ORDER_LINES_ALL) 與 Shipping Transaction (WSH_DELIVERY_DETAILS) 資料不一致, 再清楚一點說, 就是 OE_ORDER_LINES_ALL 的資料會與 Import 資料完全相同, 但是 WSH_DELIVERY_DETAILS 卻還是 Import 前的資料, 用以下範例解釋問題 :

Step 1. 先 Import 一張訂單, Line 1.1 是 100 個, Shipping Method 為 A

Step 2. Split Line 1.1

            Line 1.1 變為 90 個, Shipping Method 改為 B

            Line 1.2 為 10 個, Shipping Method 也為 B

Step 3. Import Split Line

把 Split Line 與目前 Shipping Method 資訊寫進 Interface

=> 此時, Split Line 沒有問題, 但是 Sales Order Line 的 Shipping Method 會改為 B, 但是 Shipping Transaction 的 Shipping Method 仍為 A

=> 這一個動作就是問題所在, 因為 Oracle 認為, Split 與 Update 都不同的動作, 所以在 Import 時做兩個動作是不正確的, 也就是 Step 3 應該拆成 :

Step 3. Import Split Line : 只放最少資訊, 用來達成 Split 的動作 (Metalink Doc ID : 394124.1)

Step 4. Import Update Line : 再將其他欄位一次 Update 進系統

補充 :

(1) 訂單 Import 前的畫面是經過客製, 使用者先將所有訂單資料填寫完之後, 再使用 Oracle Standard Import Function 進到 OM 系統

(2) Oracle 說明文號 : 866882.1

(3) 此問題會發生在 Ship To Customer / Ship To Address / Ship To Contents / Shipping Method

- ID 欄位與 Meaning 欄位同時給值 : 例如 Ship to Org 與 Ship to Org ID 同時都有給值, Oracle 只會抓去 ID 值, 並且有 Warning 提示

- 當該訂單 Line 有任一條處於 "Closed" 時, Order Header 不允許修改任何欄位

- Order Date 是決定是否可以使用 Blanket Number / Price List / Order Type / Line Type 的欄位

- Interface 與 Table 的 Link 為 ORIG_SYS_DOCUMENT_REF (Header) 與 ORIG_SYS_LINE_REF (Line) 欄位

- 如果 Import 的動作有 Cancel Line + Create Line, 並且 Header Ordered Date 大於系統日加 30 天, 根據標準 OM Workflow 設定, Order Header Close 時間為 Ordered Date + 30, 所以, 系統會認為 Cancel Line 的動作會造成 Header 的關閉, 所以不允許 Create Line 這一條的動作, 整個 Import 會等於 Error, 所以, 不是將這兩個動作分開 Import, 就是調整 OM Workflow 的設定 (可參考 Metalink Doc ID: 141919.1)

- Order Import 需要的 Share Pool 不算低, 如果 ERP Server 的 Share Pool 很吃緊, Order Import 的使用率又高, 最好把整個 Import 的 Package 保留在記憶體中 (可參考 Metalink Doc ID: 436947.1)

- Order Import 時, 不能同時 Split 與 Update (詳細)

(持續更新....)