EBS 組織架構：

（一）業務組（BG）

（二）法律實體（LE）

（三）業務實體（OU）

（四）庫存組織（INV）

（五）公司成本中心（Cost Center）

（六）HR組織

（七）多組織接入控制

Sale Order 銷售訂單 的 Ship Confirm 發運功能模塊：

在做狀態變化時候要記得對WHO字段進行狀態的改動。

必要表的信息：

oe_order_headers_all 訂單頭信息表

oe_order_lines_all

--header_id=oe_order_headers_all.header_id
--訂單行信息表

這里面有一個概念：

比方

ORDER_NUMBER 訂單編號 為 101852

這里有兩個訂單頭。

HEADER_ID：A HEADER_ID：B

而LINE_NUMBER的概念就是在這兩個訂單里。屬于同一行的 例如以下：

HEADER_ID：A B

LINE_NUMBER：1 LINE_ID：A1 LINE_ID：B1

LINE_NUMBER：2 LINE_ID：A2 LINE_ID：B2

LINE_NUMBER：3 LINE_ID：A3 LINE_ID：B3

銷售訂單是這樣一種邏輯關系。

oe_order_headers_all 中的重要字段：

HEADER_ID 訂單頭id

REQUEST_ID 并發請求的id
ORG_ID 業務實體的id
SHIP_TO_ORG_ID 收貨方組織id
SHIP_FROM_ORG_ID 發貨方組織id

oe_order_lines_all中的重要字段
HEADER_ID 訂單頭id
REQUEST_ID 并發請求的id
ORG_ID 組織的id
LINE_ID 訂單行id
LINE_NUMBER 訂單行number
SHIP_TO_ORG_ID 收貨方組織id
SHIP_FROM_ORG_ID 發貨方組織id

wsh_delivery_details
--source_header_id=oe_order_headers_all.header_id
--source_line_id=oe_order_lines_all.line_id
物料發運明細信息表
DELIVERY_DETAIL_ID 物料單的id
SOURCE_HEADER_ID 訂單頭id
SOURCE_LINE_ID 訂單行id
CUSTOMER_ID 客戶id
INVENTORY_ITEM_ID 相應物料表的物料id
ORGANAZATION_ID 庫存組織的id
REQUESTED_QUANTITY 請求的數量
SHIPPED_QUANTITY 發運的數量
SUBINVENTORY 子庫存的名稱
RELEASED_STATUS 當前物料的狀態
ORG_ID 業務實體的id
REQUEST_ID 并發請求的id
LOCATOR_ID 庫存中貨位號

LOT_NUMBER 物料的批號

wsh_delivery_assignments
--delivery_detail_id=wsh_delivery_details.delivery_detail_id
--連接wsh_delivery_details和wsh_new_deliveries的信息表
--此階段連接wsh_delivery_details

DELIVERY_ID 發貨號
DELIVERY_DETAIL_ID 物料id

mtl_serial_numbers
記錄物料序列號的當前狀態的信息表
INVENTORY_ITEM_ID 物料id
SERIAL_NUMBER 序列號

mtl_serial_numbers_temp
序列號和物料單的相應表
由transaction_temp_id進行關聯

發運模塊，能夠理解為將保留庫中的物料拿出來進行發貨，發運確認完畢則代表這物權的轉移。發運中的延交情況非常多，比方當你要發貨的物品數量不足以滿足買方的數量，則能夠延遲交貨，等到數量滿足了一起交貨。

做發運模塊主要是當物料挑庫完畢后，得到一堆物料單，然后為每個物料單生成物料號，物料號是為了讓發運時知道。該發運哪些物料，物料號的生成有多種情況。

發運模塊的界面操作：
登錄，找一個具有訂單管理職責。進入到 事務處理中。

能夠依據ORDER NUMBER 銷售訂單的號碼進行查詢。

<img src="http://img.blog.csdn.net/20140828164651939?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3ljMTk5Mjcz/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

這里的每一條都相應一個物料單。

Detail是物料編號
Item Name是物料的名稱。
Delivery是物料的發貨號
Line Status 是 物料的當前狀態，狀態是Staged/Pick Confirm狀態是要進行發運的。
Next Step 是 物料的下一個狀態
Order 是訂單編號

Requested Qty 是 須要的數量
Shipped Qty 是 要發運的數量
BackOrdered Qty 是要延交的數量
<img src="http://img.blog.csdn.net/20140828164630312?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3ljMTk5Mjcz/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">
Serial Number 是序列號 序列號不是必須的。假設物料啟動了序列號控制才會有。Org Code 是當前的庫存組織， subinventory 子庫存
假設想要發運的話 必需要分配物料號，
<img src="http://img.blog.csdn.net/20140828164700281?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3ljMTk5Mjcz/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

在這里選擇操作，當前自己知道的就是僅僅有 ：
Split Line 分行，當啟動序列號的時候。分行規則臨時不了解，可是會自己主動給分出來的行分配之前有的序列號。
Lauch Pick Release 自己主動挑庫。這個操作能夠對Backordered或 Ready to Release 的進行挑庫，這個時候會自己主動為這個物料單進行挑庫，而且分配發貨號。
挑庫，能夠理解為。將自己庫存中的物料發放到保留庫中。保留庫中的物料是以后不能被動的，以為他們已經都分配完了，等待發運。而庫存中的物料是還能夠分配的。
Auto-create Deliveries 自己主動分配物料發貨號

對于圖中藍字那行的。這個時候能夠進行發運，進入Delivery界面，

<img src="http://img.blog.csdn.net/20140828164946706?

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQvd3ljMTk5Mjcz/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/SouthEast" alt="">

點擊Ship Confirm。進行發運。

這里要進行一些說明，

ShipConfirm Rule 里的是當前系統已經定義好的發運規則。

這里的 點擊Ship Entered Quantities ，在右面選擇你要對未知的數量的物料的發運方式，
比如 Requested Qty = 10 shipped qty = 5 backordered qty = 3 ，那么未知數量就是2
假設選擇ship，則對未知的數量2的進行發運操作，就是發運7個。延交3個
假設選擇Backorder，則對未知的數量2進行延交操作。就是發運5延交5
假設選擇Stage，則對未知的數量歸回到Staged/Pick Confirm狀態。

這個配合以下的

假設勾選，則對于回到Staged/Pick Confirm狀態的自己主動分配發貨號。

假設選擇Cyclecount 。則對未知數量的物料回歸到Staged/Pick Confirm狀態，而且shipped Qty數量為空。

Ship All就是將全部的物料都發運。

其它的也一樣意思。
這里要注意，發運后的物料單還要做一個 Trip Stop 停靠站操作，才算發運成功，這個業務臨時還不清楚是什么意思。

代碼實現上遠遠比界面復雜的多，首先要介紹幾個用到的API。

wsh_deliveries_pub.delivery_action(p_api_version_number => 1.0,
                                       p_init_msg_list      => fnd_api.g_true,
                                       x_return_status      => lv_return_status,
                                       x_msg_count          => ln_msg_count,
                                       x_msg_data           => lv_msg_data,
                                       p_action_code        => 'CONFIRM',
                                       p_delivery_id        => 104483, 
                                       p_delivery_name      => 104483,
                                       p_sc_action_flag     => 'C',
                                       p_sc_close_trip_flag => 'Y',
                                       x_trip_id            => ln_trip_id,
                                       x_trip_name          => lv_trip_name);

這里的傳入參數，能夠有：

P_action_code 有非常多值：

'PLAN','UNPLAN','PACK','CONFIRM',
'RE-OPEN','IN-TRANSIT','CLOSE', 'ASSIGN-TRIP','UNASSIGN-TRIP','AUTOCREATE-TRIP', 'WT-VOL', 'PICK-RELEASE', 'DELETE'

我知道的僅僅有，

--RE-OPEN 讓status處于又一次打開狀態
--DELETE 刪除物料號
--CONFIRM 進行Ship Confirm操作 事實上相應的是下圖的Ship confirm，和Actions內的操作：

p_sc_action_flag  ： ship confirm option - 'S', 'B', 'T', 'A', 'C'

這個就相當于

S 是 Ship B是backorder T是stag C是CycleCount A是Ship All

而其它參數如 ：

p_sc_intransit_flag ： 是 圖上的 Set Delivery In-transit 是否勾選， Y 是 N 否

p_sc_close_trip_flag：是 圖上的 Close Trip是否勾選， Y 是 N 否

p_sc_stage_del_flag：是 圖上的 Create Delivery for Staged Quan..是否勾選。 Y 是 N 否

p_sc_trip_ship_method：是 圖上的 Ship Method 輸入的varchar2 類型，能夠為null

p_sc_actual_dep_date： 是圖上Actual Departure Date 。null 則自己主動賦值為當前時間

p_sc_defer_interface_flag：圖上 Defer Interface是否勾選。Y 是 N 否

其它API將單開文章解說。假設有不正確的地方希望大家評論給予建議。謝謝。

總結

以上是生活随笔為你收集整理的EBS 第一个项目 学习总结 ---- 发运模块的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。