Aloz 的 Oracle ERP 天地

直接就貼 Sample Code 上來 (以 Update "Schedule Ship Date" 為例)

DECLARE
  L_USER_ID NUMBER;
  L_RESP_ID NUMBER;
  L_APPL_ID NUMBER;
  L_HEADER_REC_IN OE_ORDER_PUB.HEADER_REC_TYPE;
  L_LINE_TBL_IN OE_ORDER_PUB.LINE_TBL_TYPE;
  L_ACTION_REQUEST_TBL_IN OE_ORDER_PUB.REQUEST_TBL_TYPE;
  L_HEADER_REC_OUT OE_ORDER_PUB.HEADER_REC_TYPE;
  L_LINE_TBL_OUT OE_ORDER_PUB.LINE_TBL_TYPE;
  L_HEADER_VAL_REC_OUT OE_ORDER_PUB.HEADER_VAL_REC_TYPE;
  L_HEADER_ADJ_TBL_OUT OE_ORDER_PUB.HEADER_ADJ_TBL_TYPE;
  L_HEADER_ADJ_VAL_TBL_OUT OE_ORDER_PUB.HEADER_ADJ_VAL_TBL_TYPE;
  L_HEADER_PRICE_ATT_TBL_OUT OE_ORDER_PUB.HEADER_PRICE_ATT_TBL_TYPE;
  L_HEADER_ADJ_ATT_TBL_OUT OE_ORDER_PUB.HEADER_ADJ_ATT_TBL_TYPE;
  L_HEADER_ADJ_ASSOC_TBL_OUT OE_ORDER_PUB.HEADER_ADJ_ASSOC_TBL_TYPE;
  L_HEADER_SCREDIT_TBL_OUT OE_ORDER_PUB.HEADER_SCREDIT_TBL_TYPE;
  L_HEADER_SCREDIT_VAL_TBL_OUT OE_ORDER_PUB.HEADER_SCREDIT_VAL_TBL_TYPE;
  L_LINE_VAL_TBL_OUT OE_ORDER_PUB.LINE_VAL_TBL_TYPE;
  L_LINE_ADJ_TBL_OUT OE_ORDER_PUB.LINE_ADJ_TBL_TYPE;
  L_LINE_ADJ_VAL_TBL_OUT OE_ORDER_PUB.LINE_ADJ_VAL_TBL_TYPE;
  L_LINE_PRICE_ATT_TBL_OUT OE_ORDER_PUB.LINE_PRICE_ATT_TBL_TYPE;
  L_LINE_ADJ_ATT_TBL_OUT OE_ORDER_PUB.LINE_ADJ_ATT_TBL_TYPE;
  L_LINE_ADJ_ASSOC_TBL_OUT OE_ORDER_PUB.LINE_ADJ_ASSOC_TBL_TYPE;
  L_LINE_SCREDIT_TBL_OUT OE_ORDER_PUB.LINE_SCREDIT_TBL_TYPE;
  L_LINE_SCREDIT_VAL_TBL_OUT OE_ORDER_PUB.LINE_SCREDIT_VAL_TBL_TYPE;
  L_LOT_SERIAL_TBL_OUT OE_ORDER_PUB.LOT_SERIAL_TBL_TYPE;
  L_LOT_SERIAL_VAL_TBL_OUT OE_ORDER_PUB.LOT_SERIAL_VAL_TBL_TYPE;
  L_ACTION_REQUEST_TBL_OUT OE_ORDER_PUB.REQUEST_TBL_TYPE;
  L_CHR_PROGRAM_UNIT_NAME VARCHAR2 (100);
  L_CHR_RET_STATUS        VARCHAR2 (1000) := NULL;
  L_MSG_COUNT             NUMBER := 0;
  L_MSG_DATA              VARCHAR2 (2000);
  L_NUM_API_VERSION       NUMBER := 1.0;
  
  CURSOR C_SO_DETAILS IS
    SELECT  OH.HEADER_ID
          , OL.LINE_ID
          , OH.ORDER_NUMBER AS SO_NUMBER
          , MSI.SEGMENT1
          , OL.LINE_NUMBER || '.' || OL.SHIPMENT_NUMBER AS LINE
          , OL.INVENTORY_ITEM_ID
    FROM    OE_ORDER_HEADERS_ALL OH
          , OE_ORDER_LINES_ALL OL
          , MTL_SYSTEM_ITEMS MSI
    WHERE   0 = 0
    AND     OH.HEADER_ID = OL.HEADER_ID
    AND     OL.INVENTORY_ITEM_ID = MSI.INVENTORY_ITEM_ID
    AND     MSI.ORGANIZATION_ID = OL.SHIP_FROM_ORG_ID
    AND     OL.LINE_ID = 1
    ;
BEGIN
  SELECT  USER_ID 
  INTO    L_USER_ID 
  FROM    FND_USER 
  WHERE   USER_NAME = 'ABC'
  ;
  
  SELECT  RESPONSIBILITY_ID
        , APPLICATION_ID
  INTO    L_RESP_ID
        , L_APPL_ID
  FROM    FND_RESPONSIBILITY_VL
  WHERE   RESPONSIBILITY_NAME LIKE 'Order Management Super User'
  ;
  
  FND_GLOBAL.APPS_INITIALIZE (L_USER_ID, L_RESP_ID, L_APPL_ID);
  
  FOR ISO_REC IN C_SO_DETAILS LOOP
    L_LINE_TBL_IN (1) := OE_ORDER_PUB.G_MISS_LINE_REC;
    
    L_LINE_TBL_IN (1).LINE_ID := ISO_REC.LINE_ID;
    L_LINE_TBL_IN (1).SCHEDULE_SHIP_DATE := SYSDATE; --TO_DATE(ISO_REC.UPDATE_SSD,'DD-MON-RRRR HH24:MI:SS');
    L_LINE_TBL_IN (1).OPERATION := OE_GLOBALS.G_OPR_UPDATE;
    
    OE_MSG_PUB.DELETE_MSG;
    
    OE_ORDER_PUB.PROCESS_ORDER (
        P_API_VERSION_NUMBER => L_NUM_API_VERSION
      , P_INIT_MSG_LIST => FND_API.G_FALSE
      , P_RETURN_VALUES => FND_API.G_FALSE
      , P_ACTION_COMMIT => FND_API.G_FALSE
      , P_LINE_TBL => L_LINE_TBL_IN
      , X_HEADER_REC => L_HEADER_REC_OUT
      , X_HEADER_VAL_REC => L_HEADER_VAL_REC_OUT
      , X_HEADER_ADJ_TBL => L_HEADER_ADJ_TBL_OUT
      , X_HEADER_ADJ_VAL_TBL => L_HEADER_ADJ_VAL_TBL_OUT
      , X_HEADER_PRICE_ATT_TBL => L_HEADER_PRICE_ATT_TBL_OUT
      , X_HEADER_ADJ_ATT_TBL => L_HEADER_ADJ_ATT_TBL_OUT
      , X_HEADER_ADJ_ASSOC_TBL => L_HEADER_ADJ_ASSOC_TBL_OUT
      , X_HEADER_SCREDIT_TBL => L_HEADER_SCREDIT_TBL_OUT
      , X_HEADER_SCREDIT_VAL_TBL => L_HEADER_SCREDIT_VAL_TBL_OUT
      , X_LINE_TBL => L_LINE_TBL_OUT
      , X_LINE_VAL_TBL => L_LINE_VAL_TBL_OUT
      , X_LINE_ADJ_TBL => L_LINE_ADJ_TBL_OUT
      , X_LINE_ADJ_VAL_TBL => L_LINE_ADJ_VAL_TBL_OUT
      , X_LINE_PRICE_ATT_TBL => L_LINE_PRICE_ATT_TBL_OUT
      , X_LINE_ADJ_ATT_TBL => L_LINE_ADJ_ATT_TBL_OUT
      , X_LINE_ADJ_ASSOC_TBL => L_LINE_ADJ_ASSOC_TBL_OUT
      , X_LINE_SCREDIT_TBL => L_LINE_SCREDIT_TBL_OUT
      , X_LINE_SCREDIT_VAL_TBL => L_LINE_SCREDIT_VAL_TBL_OUT
      , X_LOT_SERIAL_TBL => L_LOT_SERIAL_TBL_OUT
      , X_LOT_SERIAL_VAL_TBL => L_LOT_SERIAL_VAL_TBL_OUT
      , X_ACTION_REQUEST_TBL => L_ACTION_REQUEST_TBL_OUT
      , X_RETURN_STATUS => L_CHR_RET_STATUS
      , X_MSG_COUNT => L_MSG_COUNT
      , X_MSG_DATA => L_MSG_DATA
    );
    
    L_MSG_DATA := NULL;
    
    IF L_CHR_RET_STATUS <> 'S' THEN
      FOR IINDX IN 1 .. L_MSG_COUNT LOOP
        L_MSG_DATA := L_MSG_DATA || '  ' || OE_MSG_PUB.GET (IINDX);
      END LOOP;
    END IF;
    
    DBMS_OUTPUT.ENABLE (10000);
    DBMS_OUTPUT.PUT_LINE ('Sales Order => ' || ISO_REC.SO_NUMBER || ' - Line Number => ' || ISO_REC.LINE);
    DBMS_OUTPUT.PUT_LINE ('Return Status: ' || L_CHR_RET_STATUS);
    DBMS_OUTPUT.PUT_LINE ('Error Message: ' || L_MSG_DATA);
  END LOOP;
  
  COMMIT;
END;

如果你的 Responsibility 的 Menu 是套用標準的 OM Menu (ONT_SUPER_USER) 或 OM > Customer 功能是使用標準的 Submenu (ONT_CUSTOMERS), 那你有可能會遇到這個問題, 可是使用 AR 下的 Customer 正常....

Order Organizer 是很好用的查詢介面, 除了不能維護資料之外, 其他的功能都與 Sales Order 沒有太大的不同. 不過, 也是有它獨特的功能可以介紹, 就是自定查尋 (Query)

看到對岸論壇有人在問, Customer 主檔的 Business Purpose 中的 Location 欄位可不可以自動給值?

雄雄想到, 我們家的系統一直以來都是自動給值的 (序號), 所以這應該是有一個設定可以調整, 很快的就找到了 :

OM Superuser > Setup > Customers > System Options > Trans and Customers > Automatic Site Numbering

當這個設定有勾選, Location 欄位就會反灰, 在存檔後自動給予一編號, 反之, 則開放給使用者自行給予, 且為必填

但是有一點比較怪, 網路上有些資料或畫面會顯示出, Location 欄位會預設抓 Address 1 欄位值, 我就不確定是不是標準功能, 亦或是客製了

想要找看看, 在 11i 的版本中, 是不是 API 給 Blanket Sales Agreement (BSA) 使用, 結果很遺憾的沒有, 只有 R12 限定 (囧)

之前有寫過一篇 Defaulting Rule 與 Package (http://aloz0101.pixnet.net/blog/post/17066963), 不過裡面沒有提到 Defaulting Rule 的設定方式, 就用這篇來說吧

畫面路徑 : OM > Setup > Rules > Defaulting

範例功能 : 如何設定自動給 Subinventory

步驟 :

當 User 操作 RMA 單時, 選擇了 Reference 後, Book order 會發生 "Quantity cannot be greater than original quantity" 的錯誤訊息. 不過, 標準畫面很難查的出來是哪一張 RMA 單 Reference 了同一張單子, 所以無法處理.

SELECT OOH1.ORDER_NUMBER A1
     , OOL1.ORDERED_ITEM A2
     , OOL1.LINE_NUMBER A3
     , OOL1.ORDERED_QUANTITY A4
     , OOH1.FLOW_STATUS_CODE A5
     , OOH2.ORDER_NUMBER B1
     , OOL2.LINE_NUMBER B1
     , OOL2.ORDERED_QUANTITY B3
     , OOH2.FLOW_STATUS_CODE B4
     , OOH3.ORDER_NUMBER C1
     , OOL3.LINE_NUMBER C2
     , OOL3.ORDERED_QUANTITY C3
     , OOH3.FLOW_STATUS_CODE C4
   FROM ONT.OE_ORDER_HEADERS_ALL OOH1
      , ONT.OE_ORDER_LINES_ALL OOL1
      , ONT.OE_ORDER_LINES_ALL OOL2
      , ONT.OE_ORDER_HEADERS_ALL OOH2
      , ONT.OE_ORDER_LINES_ALL OOL3
      , ONT.OE_ORDER_HEADERS_ALL OOH3
  WHERE OOH1.HEADER_ID = OOL1.HEADER_ID
    AND OOL1.LINE_CATEGORY_CODE = 'RETURN'
    AND OOH1.ORDER_NUMBER = '當前的訂單編號'
    AND OOL1.REFERENCE_LINE_ID = OOL2.LINE_ID
    AND OOH2.HEADER_ID = OOL2.HEADER_ID
    AND OOL1.REFERENCE_LINE_ID = OOL3.REFERENCE_LINE_ID(+)
    AND OOH3.HEADER_ID(+) = OOL3.HEADER_ID
    AND OOH1.ORDER_NUMBER <> OOH3.ORDER_NUMBER

OM 模組底下有一個功能 : Processing Constraints (路徑 : Setup > Rules > Security > Processing Constraints), 此功能是用來定義, 在 OM 模組所屬的畫面, 什麼時候要做什麼, 什麼時候不能做什麼

畫面很簡單, 最上面的部份就是選擇 Application 與 畫面 (Entity)

中間的部分就是設定 Constraints 的地方 :

- Operation : 就是指定動作 (LOV 會因為 Entity 的不同而不同)

- Attribute : 讓你選擇特定欄位 (LOV 會因為 Entity 的不同而不同)

- User Action : 當條件成立時, 你所要執行的動作

最下面就是設定 Conditions :

- Group# : 條件可以設定群組, 群組編號相同就表示為 AND, 不同則為 OR

- Scope : Any / All

- Validation Entity : 選擇條件所在 Entity

- Record Set : Form 的 Data Block

- Validation Template : 驗證範本 (另一個彈性功能)

- User Message : 顯示給使用者看的訊息 (不見得會顯示, 要看你所設定的 User Action, 但是因為是必填, 所以一定要打)

附上目前有使用的功能 :

1. 修改 Ordered Quantity 時, 記錄 History

** Constraints **

- Operation : Update

- Attribute : Ordered Quantity

- User Action : Required History

** Conditions **

- Group# : 1

- Scope : Any

- Validation Entity : Order Header

- Record Set : Order

- Validation Template : Booked

- User Message : Ordered Quantity haved been updated!!

2. 當 Delivery 確認 (Firm) 後, 不允許修改 Order Line 的任一欄位

** Constraints **

- Operation : Update

- Attribute : 

- User Action : Not Allowed

** Conditions **

- Group# : 1

- Scope : Any

- Validation Entity : Order Line

- Record Set : Line

- Validation Template : Delivery Firm (自行客製)

- User Message : No Allowed Update!! This line which delivery is firmed. (因為此設定會讓使用者無法操作, 所以設定的 Message 會跳出來給使用者看)

上週發生了一個新的 Import Error : "Ship To is required on a booked order", 一直看 Ship To 相關欄位都看不出所以然, 後來才發現是別的欄位造成的

在之前的某篇文章有提到, Credit Check 中有一個功能 : Override Manual Release, 一直到昨天才發現我對這個功能的意義是錯的

當在設定 Blanket Sales Agreement 的 Document Sequence 時候, 切記, Document Sequence Type 只能設定 Automatic, 不能夠設定 Gapless 或 Manual (Metalink Doc ID : 375086.1)

如果設定成 Gapless 或 Manual 時, 會跳出 "Invalid Document Sequence. (Document Sequence=Manual Numbering)" 的錯誤訊息, 就算去 Update Table, 將 Type 欄位改為 Automatic 也是無法正確取號

只能手動將設定刪除, 再重新設定

 SELECT A.ROWID, A.*
   FROM FND_DOCUMENT_SEQUENCES A
  WHERE 0 = 0
    AND NAME LIKE 'Quote%(2010%' -- 依所設定的名稱搜尋;

 SELECT A.ROWID, A.*
   FROM FND_DOC_SEQUENCE_ASSIGNMENTS A
  WHERE 0 = 0
    AND CATEGORY_CODE = '1002'
    AND TO_CHAR(START_DATE, 'YYYY') = '2010';

因為我們有做訂單外部簽核, 簽核完之後都是走標準的 Order Import, 所以常常會遇到很奇怪的問題......

目前最常遇到的情形是, "Blanket sales agreement is locked by another user", 這個其實是老問題, 當初很直覺的覺得, 就是使用者忘了把 BSA 畫面關掉所致, 但是在最近幾次與使用者確認過後才發現好像不是這樣, 上 Metalink 才發現這是一個"問題"

(PS. 新版的 Metalink 在 Search 方面好像有強化, 比舊版更精準地查到我的問題)

Metalink Doc ID : 727777.1

Applies to:
Oracle EDI Gateway - Version: 11.5.10 to 11.5.10.2
This problem can occur on any platform.

Symptoms
-- Problem Statement:
On 11.5.10 in Production:
When attempting to import order lines which referencing the same blanket agreement number,
the following error occurs:

ERROR
"Blanket sales agreement is locked by another user. Please try later. Blanket Number: XXXX"

-- Steps To Reproduce:
The issue can be reproduced at will with the following steps:
1. Interface EDI 850 (POI) Multiple Sales Orders (Headers / Lines / Pricing Attributes) all
referencing the same Blanket Agreement Number on the Header and Line.
2. The first order record will import successfully but subsequent order records will fail with
error message on step 1 above.

Cause
This issue is described in Bug 4673289
ORDER IMPORT - BLANKET SALES AGREEMENT LOCKED BY ANOTHER USER

At this time, we do not lock the record before calculating the cumulative,
we do it in the memory, causing the locking issue.
Because of this limitation we are suggesting as a workaround to group by Customer.
That way every BSA will tie up with only one customer.
In this case - can send sold_to_org_id as a parameter to Order Import.

Solution

-- To implement the solution, please execute the following steps:

1. Go into the responsibility: Order management responsibility

2. Run order import by passing parameter 'number of instances' as 1

3. Retest the issue.

4. Migrate the solution as appropriate to other environments.

如果需要程式更新 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)

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 (詳細)

(持續更新....)

Oracle 本身已經有針對 Customer 的 Credit Limit 等資訊做簡單的歷史紀錄

Table : AR_CREDIT_HISTORIES

Trigger :

1. HZ_CUSTOMER_PROFILES_BRU => HZ_CUSTOMER_PROFILES

2. HZ_CUST_PROFILE_AMOUNTS_BRU => HZ_CUST_PROFILE_AMOUNTS

Metalink Doc. ID : 459456.1

User 在建立客戶主檔時, 發現客戶的國家不太正確, 去 Google 一下後發現, 新版的 ISO 跟 Oracle 的內容有一些不一樣, 自己先手動加一下比較快~~

需要手動新增的 Table :

1. FND_TERRITORIES

2. FND_TERRITORIES_TL

3. 一定會用到的資料 : ISO 3166-1 內容 ( 維基百科連結 )

4. Metalink 文件參考 : Doc ID : 232508.1