Aloz 的 Oracle ERP 天地

之前有發現, RA_CUSTOMERS 這 View 的 Customer Name 從 360 被截斷為 50 ( Link )

前幾天又發現, 在 Blanket Sales Agreement 這個畫面中, 也出現類似的問題, 問題出在另外一個 View : OE_SOLD_TO_ORGS_V ( Oracle 的工程師是認為不會有公司名稱那麼長的嗎 )

上 Oracle Metalink 查, 很幸運的, 很快就找到, 文中也附上了 Patch, 不過, 下載這個 Patch 竟然要跟 Oracle 先要密碼才能用, 看來, Oracle 也還沒對這個 Patch 做驗證動作, 還是先等一等吧~

Oracle Metalink Doc ID : 788448.1 ( Link )

Patch Number : 7539013

想要修改 Order Type / Line Type 的名稱, 但是已經有存在的訂單, Oralce 是不允許修改的.

要找到修改的 Table 不是難事, 問題都是改完才發現

Oralce 分別在 Shipping Transaction 與 MRP 部份, 特別針對 Sales Order 的 Order Type 做抄寫動作, 也就是在自家的 Table 中, 把該 Sales Order 的 Order Type 做紀錄. 直接的影響就是在 Pick 時, 如果只改了其中之一, 就會造成 Pick 不過. 需要修改的 Table 如下

 

• OE_TRANSACTION_TYPES_TL

• WSH_DELIVERY_DETAILS

• MTL_SALES_ORDERS

當 User 打一張 RMA 類型的訂單時, Return Reason 欄位是必填的,

但, 裡面的內容不夠要怎麼增加呢?

Path : OM Superuser > Setup > QuickCodes > Receivables

Type : CREDIT_MEMO_REASON

最近突然發現, Oracle 標準 Report 中的 Credit Exposure Report, 有客戶的 Exposure 沒有正確的計算出來, 而跑到 Unchecked Exposure 這個欄位裡面, 去 Metalink 查詢後才發現問題出在 Customer Credit Profile 的設定

Oracle Metalink 上找到的答案

---

While creating usage rule, you may have certain currencies to be excluded from the rule set.

(N) OM -> Setup -> Credit -> Define Usage Rules

The rule set can be assigned to ct/site/profile.

(N) OM -> Setup -> Credit -> Assign Usage Rules

Transactions on this currencies will be excluded while calculating exposure. If the exclude flag is set for any currency the exposure for the same is displayed as unchecked exposure.

Unchecked Exposure displays exposure, that was not accounted by any credit profile. The calculation is same as normal exposre calculation. The only difference is excluded currencies will be passed to the procedure get_exposure.

Exposure is calculated based on the credit check rule where the ct can specify what all values should be included in calculating the exposure. How
credit check rule is used, is mentioned in Oracle Implementation guide. This exposure will be based on currencies as per credit usage rule.

If the credit usage rule is saying to exclude some currencies, the exposure for the same will appear as Unchecked Exposure.

Blanket Sales Agreements (BSA) 在 Oracle OM 中蠻特殊的功能, 因為好像很少人在用

我們是有用到, 不過是代替 Quote 來使用, 因為 BSA 可以連接到價目表 (Price List), 在特定的條件下還蠻好用的

◎ 我認為的優點

1. 可連接價目表 (Price List): 若訂單是屬於量產品, 這會是不錯的功能

2. 代替 Quote 使用: 一樣, 若價格固定的訂單, 可以直接使用 BSA 來產生很多張訂單

3. 在畫面上即可統計該 BSA 產生的 Amount

4. 指定單價的維度可以有: All Items / Item Category /  Customer Item / Internal Item, 其中, All Items 需要另外指定到 UOM

◎ 我認為的缺點

1. 不是每個商業模式都能適用: 如果單價是浮動, 或著不是 Item Base 的訂單, 就會很難使用到 BSA, 或著只是取個號碼當成 Quote 單號

2. (不是缺點的缺點) BSA 的生效期間是與 Sales Order Header 的 Order Date 與 Sales Order Line 的 Request Date 有關

先前有一篇文章是與上面這點有關的 Patch, 可一起參考 http://aloz0101.pixnet.net/blog/trackback/f0af3fdfad/11594719

---

再補充一下我們這邊的應用:

如前面所說, 我們是把 BSA 當成 Quote 使用, 所以, 當 Quote 要產生之前, 使用者就會來 BSA 取號, 也就是先建立單頭. 然後等內容確定之後, 再將內容補上, 所謂的內容就是那個 Item 要賣多少錢等等. 全部的資料建立完並且確認無誤之後, 使用者就會按下 Submit Draft, 此 BSA 就會正式生效, 使用者也無法再針對內容做修改 (P1). 這樣的預期效果是, 如果使用者在建立訂單後, 單價與 BSA 不符合, 就很容易的判斷出來 (P2), 以達到稽核的功效.

P1. 可以透過利用 Profile 來做設定

P2. 因為公司產業特性問題, 我們是允許使用者修改訂單預設單價的

最近在研究 OAF 與 Oracle Workflow 的整合作法, 沒有心得, 只能寫些小東西....

今天突然發現, 我平時很常用的 View : RA_CUSTOMERS 有個問題, Customer Name 被截斷

原始的 Table : HZ_PARTIES, PARTY_NAME 是有 360 Bytes, 可是這個 View 卻用了 Substr 把 Customer Name (Party Name) 截斷成 50 Bytes,

完全不明白為什麼, 只好自己產生客製 View, 然後改所有的程式..........

我一直以為在 OE_ORDER_LINES_ALL 中的 FLOW_STATUS_CODE 會等於 Form 上的 Status, 只不過一個是 Code, 一個是 Meaning, 但是, 很不巧的發現, Oracle 偷偷的留一手.....

當該 Line 已做了 Pick 時, Form 上雖然顯示 "Picked", 但在 Table 所記錄的 FLOW_STATUS_CODE 仍是 "AWAITING_SHIPPING", 不確定原因是啥, 不過 Oracle 在 Metalink 也都沒做任何的解釋, 其實就只是用了一個 Package 去做轉換的動作罷了

OE_LINE_STATUS_PUB.GET_LINE_STATUS ( LINE_ID, FLOW_STATUS_CODE)

該死的 Oracle

最近公司內部稽核對於 Oracle 的 Credit Check Rule 做了檢查, 結果發現, Credit Exposure Report 的結果不等於實際上在 Credit Check Rule 中的設定, 更奇怪的問題是, 也不是全錯, 而是對錯各半.

後來針對這個"神奇"的現象去查才發現, 我們有針對特定的 Line Type, 利用 Defaulting Rule 去套用沒有 Credit Check 的 Payment Term, 以避免該 Line 被 Credit Hold.

在實做上 Oracle 也確實的有達到這個效果, 但是 Exposure Report 確沒有考慮到這個狀況, 而把這個 Line Type 的 Total Amount 算進去. 更嚴格的說, Oracle 是直接看 Order Amount 去計算, 沒有進到 Line 裡面仔細的計算. (Oracle Metalike Doc. 558473.1)

---

上週針對這個問題 Log TAR, 結果被印度人秒殺, 理由竟然是他們仍在處理中 (從 2004 年處理到現在?), 所以我今天 Log 了生平的第一個 Level 1

---

好吧, 看來小公司對於 Oracle 也沒什麼辦法, Oracle 不願意承認與處理這個問題, 那只好不用 Oracle 的 Credit Check, 自己客製吧.......

Credit Hold 在 OM 大部份的情況都會是自動產生, 所以 Comments 可以讓我們了解它是為了什麼而被 Credit Hold, 例如, Over Credit, 有 Overdue 的 Invoice 等.

原本我一直以為 Hold Comments 是 "必定" 存在的, 結果也如往常, 並不是, 我是有發現一個例子 :

1. 先找一個已經 Over Credit Limit 的客戶
2. 產生一張有值訂單, 並且 Book Order
3. 因為該客戶 Credit 已經滿了, 所以 Booking 時會提醒你訂單將會被 Credit Hold
4. 使用 Additional Line Information 就可以看到 Credit Hold Comments
5. Release Credit Hold
6. 提高 Line Total and Save Order
7. 因為 Order Status = 'Booked', 所以系統只會給一個 MsgBox 告知會被 Credit Hold

"Some Lines are placed on credit check hold. Please see the Additional line information window for hold details"

8. 由上訊息可以知道, Oracle 也是請 User 使用 Additional Line Information 查詢 Hold 的原因, 但這時候可以發現, Hold Comments 並沒有值

我相信這個只是其中一個 Scenario, 所以我就 Log TAR.........

---

Oracle 的印度"朋友"給我一個蠻有趣的回應: 用 View Open Message (Process Messages) 去看, 但是我去看 Table, 這邊只會記錄 Open 的訊息, 如果該 Credit Hold 被 Release, Hold Comments 就會不見, 所以這個"建議"就被我否決了

---

(2008/07/01)
有 patch 囉....^O^

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

1. Download and review the readme and pre-requisites for Patch 6856362 , when released.

ETA for this patch is 31-July-2008

Beginning September 1, 2006, Order Management Suite Development is introducing the release of regular and scheduled rollup patches in a number of pro
duct areas.

You may refer Note 396910.1 -- Order Management Suite Patching Strategy For One-Off Requests and RUPs

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:

OEXVCRLB.pls 115.48.11510.18

You can use the commands like the following:

strings -a $ONT_TOP/patch/115/sql/OEXVCRLB.pls |grep '$Header'

5. Retest the issue.

6. Migrate the solution as appropriate to other environments.

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

正式上線還真夠忙的，每天光修問題看設定就花掉一整天的時間 Orz

上線之後遇到比較大的問題是 Oracle 的 Credit Check Rule，不過網路上對這方面的討論好像不多(還是我找不到 @@")，簡單的寫點心得

---

Credit Check 要正常運作有三個地方要同時設定，缺一不可：
1. Customer / Address Profile
2. Order Transaction Type
3. Payment Term

其中，Transaction Type 的設定要配合 Main Page 的 Credit Check 設定 Check Rule，而且只能設定在 Order Type 上，不能設在 Line Type。

---

Credit Check Rule 設定：
1. Credit Check Level / Credit Hold Level
    這個很明白，不過如果 Check Level 要 by Line，Exposure 的 "Use Pre-Calculated Exposure" 會被強制打勾，那在被打勾的情況之下，"Initialize Credit Summaries" 就要安排定期執行，Customer 的 Credit Limit 才會被 Refresh
2. Override Manual Release / Days to Honor Manual Release
    簡單的說，就是該訂單如果被 Release Hold，幾天之內不會再被套用該 Check Rule
3. Exposure
    這個頁面就是選擇 Credit 要計算到的數值，一般比較常用的就是：
    A. Include Open Receivable Balance (Open AR)
    B. Include Uninvoice Orders (Open SO)
    C. Include Orders Currently On Hold
    D. Maximum Days Past Due
    不過，Oracle 也大多數的系統一樣，不會計算在 AR Interface 的資料，但是如果 AR 的 Autoinvoice 有常常執行的話，這個問題就不算大

---

雖然 Oracle 只能針對 Order Type 去設定要不要做 Credit Check，但是一個 Order Type 可以有很多 Line Type，對我們公司來說，有些 Line Type 是不需要 Check Credit 的，可是 Oracle 又不能針對 Line Type 去設定是否檢查，所以我利用 OM 模組特有的 Defaulting Rule + Payment Term (No Credit Check) 去達成；不過這樣的設定當然還是有風險，因為 Defaulting Rule 只是幫 User 把預設值帶出來，如果 User 還是有權力把預設值改掉，那效果就不見了。

這篇是直接引述 Metalink 上，有關如果改變 Sales Order Header Close 週期的文章，參考參考

---

Applies to:

Oracle Order Management - Version: 11.5.9
Information in this document applies to any platform.

Goal

"Checked for relevance on 27-Oct-2007"

How to change the Workflow so that the Order Header Closes as soon as all the lines are Closed ?

Solution

There is a standard WorkFlow Wait process defined just before the Close Header WF process, that waits for the end of the month in which the Sales order was created, before closing the Sales Order. This is to ensure that there is enough time to add new items to a Sales Order before it is closed, in case the customer wants to call back and add aditional items to the same Sales Order.

It is possible to open the OEOH workflow by connecting to the database using the WF Builder and then change this setting.

Open the Process "Close - Order" and then Right Click on the WAIT-1 that is just before the "CLOSE_WAIT_FOR_L" In the Properties, Choose Node Attributes Tab and place cursor on the "Day of the month" and remove the Value that is currently set as "Last".

Instead, set this Node Attribute same as the other Wait further down in this flow.
Change the setting as Wait Mode as Releative Time and then set the Relative Time as 1.

With this setting, as soon as all the Lines are closed, the Header will become eligible to be closed.

This will affect only new orders that uses this newly modified Flow. For the existing orders, one needs to wait till the end of the month - the month in which the Sales Order was created. Pls note that this happens only for the month the Sales order is created. For eg. if 9 of the 10 lines in a Sales Order created in July was closed and the 10th line is closed on Augst 1st, the Sales Order will Close on August 1st itself and will NOT wait till the end of August. FYI.

If there is a TEST instance where there are sample Orders, one can open the Work Flow in the Sysadmin User and System Administrator Responsibility and try and do a Skip on this Wait, so that this progresses further. If that is successful and satisfactory, one can do that in PROD too. Pls note that Support and DEV generally recommends not doing Expedite -> Skip or Expedite -> Retry unless has been consulted.

公司為依照部門對 Sales Order 這個畫面做很多功能區分，好比說誰能做 Release Hold 阿等等，除了要控制 Sales Order 的 Insert / Update / Delete Allowed 之外，Actions 的控制也是關鍵。

絕大多數的 Action 都是在 Menu 之下的 Function，不過，因為它是 Oracle，所以一定有例外 (爆)

-== 一定都會有 ==-
- Additional Order Information
* Apply Automatic Attachments ( 非 Query_Only 才會有 )
- Promotion/Pricing Attributes
- Version History
- View Adjustments
- View Blanket Sales Agreements
- View Reasons
- View Shipping Status
( 開 Form 來看，都是寫死在 Action LOV 裡面 )

-== Action Name 不等於 Function Name ==-
- Spit Line = Sales Orders: Schedule Orders

還有新的發現再補上囉~

這幾天都在研究 Sales Order 的 Actions List, 大部份都很簡單, 就是用 Function 的方式掛上去,

可是, 似乎有些是預設一定會有的,

1. Additional Order Information
2. Apply Automatic Attachments (*)
3. Promotion/Pricing Attributes
4. Version History
5. View Adjustments
6. View Blanket Sales Agreements
7. View Reasons
8. View Shipping Status

(*) 如果 Form 是 Query_Only, 這個 Action 不會出來

其實, 出來也沒差, 但是就想說如果是用不到的功能, 就想要把它 Disable

那, 目前仍是無解

好幾天沒寫了 @@"

離上線越來越近，莫名的狀況也越來越多。目前發現比較奇怪的問題有兩個：

1. Customer Profile Class

公司的 Credit Profile Class 是建立在 Customer Level，之前都沒有什麼問題，卻在 PROD 環境發現，明明 User 在建立客戶時，已經有給公司規範的 Profile Class，竟然在存檔之後，重新查詢發現被改回 Default。導致 User 要重新維護 Profile Class、Collector、Credit Limit。

目前仍未解決！

(2008-02-05) 問題解決了，一樣，上個 Patch ：5026759 

2. Party Number and Customer Number

這個問題更怪，我不知道 Oracle 定義 Party 用意在哪，至少我們公司不太需要用到，可是卻常常發生，User 明明建立兩個客戶 (A / B)，Oracle 卻把它視為同一個 Party (Party Name = A)，造成 Party Number 相同 Customer Number 不同的情形。更怪的事，其中一個 Customer Name 就不見了，改了 A 客戶，B 客戶的名字也會被改，反之亦然。算 BUG 嗎？我不知道 Orz

在設定 PROD 環境時，突然發現雖然價格表(Price List)已經建立，User也選的到，可以系統一樣告訴User：帶不出價格，原因就是有一隻Program沒跑。

Responsibility：Oracle Pricing Manager
Patch：Report
Request Name：Build Attribute Mapping Rules