EBS 第一個項目 學習總結 ---- 發運模塊

EBS 組織架構：

（一）業務組（BG）

（二）法律實體（LE）

（三）業務實體（OU）

（四）庫存組織（INV）

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

（六）HR組織

（七）多組織接入控制

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

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

必要表的信息：

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 銷售訂單的號碼進行查詢。

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

Requested Qty 是 需要的數量
Shipped Qty 是 要發運的數量
BackOrdered Qty 是要延交的數量

Serial Number 是序列號 序列號不是必須的，如果物料啟動了序列號控制才會有，Org Code 是當前的庫存組織， subinventory 子庫存
如果想要發運的話 必須要分配物料號，

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

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

點擊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。

P_action_code 有很多值：

--RE-OPEN   讓status處于重新打開狀態
--DELETE    刪除物料號
--CONFIRM 進行Ship Confirm操作 其實對應的是下圖的Ship confirm，和Actions內的操作：

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將單開文章講解。如果有不對的地方希望大家評論給予建議，謝謝。

生活不易，碼農辛苦
如果您覺得本網站對您的學習有所幫助,可以手機掃描二維碼進行捐贈