EBS 第一个项目 学习总结 ---- 发运模块

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 销售订单的号码进行查询。

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 是要延交的数量

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

Serial Number 是序列号 序列号不是必须的。假设物料启动了序列号控制才会有。Org Code 是当前的库存组织， subinventory 子库存

假设想要发运的话 必需要分配物料号，

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界面，

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将单开文章解说。假设有不正确的地方希望大家评论给予建议。谢谢。