EBS-计划采购订单信息及接口数据

采购订单

采购订单，有标准采购订单、计划类采购订单、一揽子采购协议等。

我们现在就分别来讲述这三者的差别，并在此章节着重讲述计划类采购订单。

一、采购订单

标准采购订单(从一供应商处做一次性物料或服务的采购)

建议:当你与供应商确认了采购对象(物料或服务), 数量, 发货计划, 但是不存在长期的约定时, 可使用标准采购订单.

合同采购订单(为一种协议，在该协议上只确定总金额数)

建议：该类型订单使用于你未确定购买对象，只确定供应商和购买金额的情况. 例如: 百货公司进货需要根据市场变化来决定购买对象.因此可以先确定供应商和购买总金额, 在实际需要时,才决定购买的内容.

一揽子协议(为一种协议,在该协议上决定了购买对象)

建议:当你与供应商仅确认了采购对象(物料或服务), 或者加上购买价格时, 你可使用此种订单类型. 该订单类型适用于, 当你未能肯定购买数量和需要时间时建立此种类型订单. 在需要时, 才建立一揽子协议的发放来决定数量和时间通知供应商.

计划采购订单(为长期供货订单)

建议:该订单类型适用于长期稳定的供货需求.可事先与供应商谈妥购买对象, 购买金额, 购买数量和一个长远的到期日.在需要供货时, 建立计划采购订单发放来通知供应商供货.

二、各采购订单做成测试

标准采购订单： 详见：采购标准操作及数据做成

合成采购订单： 28008环境- PO Number: 10001124

发现：合同采购协议特征： 1.只入金额和供应商;

2.需要审批;

3：后续采购订单怎么确立？

SELECT ph.Type_Lookup_Code,ph.segment1 po_number,ph.po_header_id FROM po_headers_all ph WHERE ph.segment1 ='10001124';

TYPE_LOOKUP_CODE PO_NUMBER PO_HEADER_ID CONTRACT 10001124 2741

表结构特征：1. 头表有值，行表没值

2. 头表中TYPE_LOOKUP_CODE为'CONTRACT'

一揽子采购协议：28008环境－Po Number:10001125

发现：一揽子采购协议特征：1.确认物料和单价。但没有确定数量

2.需要审批

3.后续用发放来做

SELECT ph.Type_Lookup_Code,ph.segment1 po_number,ph.po_header_id FROM po_headers_all ph WHERE ph.segment1 ='10001125';

TYPE_LOOKUP_CODE PO_NUMBER PO_HEADER_ID BLANKET 10001125 2742

表结构特征：1. 头行表有值

2. 头表中TYPE_LOOKUP_CODE为'BLANKET'

计划采购订单：28008环境－Po Number:10001131

发现：计划采购订单特征： 1.确认物料和单价、数量

2.需要审批

3.后续用发放来做

SELECT ph.Type_Lookup_Code,ph.segment1 po_number,ph.po_header_id FROM po_headers_all ph WHERE ph.segment1 ='10001131';

TYPE_LOOKUP_CODE PO_NUMBER PO_HEADER_ID PLANNED 10001131 2767

表结构特征：1. 头行表有值

2. 头表中TYPE_LOOKUP_CODE为'PLANNED'

三 着重介绍计划采购订单

我们开始对此计划采购订单进行一个着重的介绍，因为除普通订单外，计划和一揽子采购协议都存在发放的概念。我们就以计划订单为Sample来介绍。

主要想了解的内容是：

1. 发放是怎么进行的？

2. 分配行是怎么根据发放来增加的。

3. 计划类订单和普通订单有什么区分和共通之处。

根据以上三点和我们已经存在的文档《采购标准操作及数据做成》，我们来对此类订单进行分析。

1. 先看看此订单的分配行有什么特征

此订单我们只做了一个订单行。先来检查一下是否这样。。

Po_line_id 9789 item_id 100 Unit_price 485.22

存在一行记录。

再看看发运及分配行

发运行

SELECT pll.line_location_id, pll.po_line_id, pll.quantity, pll.quantity_received, pll.quantity_accepted, pll.quantity_rejected, pll.quantity_billed, pll.quantity_cancelled, pll.quantity_shipped, pll.ship_to_location_id, pll.price_override, pll.approved_flag, pll.shipment_type, pll.closed_flag, pll.Org_Id FROM po_line_locations_all pll WHERE po_line_id = 9789

LINE_LOCATION_ID PO_LINE_ID QUANTITY QUANTITY_RECEIVED QUANTITY_ACCEPTED QUANTITY_REJECTED QUANTITY_BILLED QUANTITY_CANCELLED QUANTITY_SHIPPED SHIP_TO_LOCATION_ID PRICE_OVERRIDE APPROVED_FLAG SHIPMENT_TYPE CLOSED_FLAG ORG_ID 18236 9789 10 0 0 0 0 0 162 485.22 Y PLANNED 102

分配行：

SELECT pd.po_distribution_id, pd.po_header_id, pd.po_line_id, pd.line_location_id, pd.set_of_books_id, pd.quantity_ordered, pd.quantity_delivered, pd.quantity_billed, pd.quantity_cancelled, pd.destination_type_code, pd.destination_organization_id, pd.Org_Id, pd.distribution_type FROM po_distributions_all pd WHERE pd.po_header_id =2767 AND pd.po_line_id =9789

PO_DISTRIBUTION_ID PO_HEADER_ID PO_LINE_ID LINE_LOCATION_ID SET_OF_BOOKS_ID QUANTITY_ORDERED QUANTITY_DELIVERED QUANTITY_BILLED QUANTITY_CANCELLED DESTINATION_TYPE_CODE DESTINATION_ORGANIZATION_ID ORG_ID DISTRIBUTION_TYPE 7976 2767 9789 18236 1001 10 0 0 0 INVENTORY 141 102 PLANNED

这个时候，我们看不出来什么特别的地方，发运行中一行，分配行中也是一行。

订单->发运行->分配行

这时候因为还没有做订单Release，所以，Po_release_all中还没有存在记录。

结论一：在未做Release时，计划订单和普通订单在记录上是没有太多差异的。

Po_release_all 没有记录（发放）

好，接下来我们来做发放，主要测试一下多次发放。

2. 第一次发放，3Pc（共10）。已批准。

我们看看各数据变化

发运行

SELECT pll.line_location_id, pll.po_line_id, pll.quantity, pll.quantity_received, pll.quantity_accepted, pll.quantity_rejected, pll.quantity_billed, pll.quantity_cancelled, pll.quantity_shipped, pll.ship_to_location_id, pll.price_override, pll.approved_flag, pll.shipment_type, pll.closed_flag, pll.Org_Id FROM po_line_locations_all pll WHERE po_line_id = 9789 --(这里面，如果存在发放的话，是会有Po_release_id的，此处未列出来）

LINE_LOCATION_ID PO_LINE_ID QUANTITY QUANTITY_RECEIVED QUANTITY_ACCEPTED QUANTITY_REJECTED QUANTITY_BILLED QUANTITY_CANCELLED QUANTITY_SHIPPED SHIP_TO_LOCATION_ID PRICE_OVERRIDE APPROVED_FLAG SHIPMENT_TYPE CLOSED_FLAG ORG_ID 18236 9789 10 0 0 0 0 0 162 485.22 Y PLANNED 102 18237 9789 3 0 0 0 0 0 162 485.22 Y SCHEDULED 102

分配行：

SELECT pd.po_distribution_id, pd.po_header_id, pd.po_line_id, pd.line_location_id, pd.set_of_books_id, pd.quantity_ordered, pd.quantity_delivered, pd.quantity_billed, pd.quantity_cancelled, pd.destination_type_code, pd.destination_organization_id, pd.Org_Id, pd.distribution_type FROM po_distributions_all pd WHERE pd.po_header_id =2767 AND pd.po_line_id =9789

PO_DISTRIBUTION_ID PO_HEADER_ID PO_LINE_ID LINE_LOCATION_ID SET_OF_BOOKS_ID QUANTITY_ORDERED QUANTITY_DELIVERED QUANTITY_BILLED QUANTITY_CANCELLED DESTINATION_TYPE_CODE DESTINATION_ORGANIZATION_ID ORG_ID DISTRIBUTION_TYPE 7976 2767 9789 18236 1001 10 0 0 0 INVENTORY 141 102 PLANNED 7977 2767 9789 18237 1001 3 0 0 0 INVENTORY 141 102 SCHEDULED

发放头（通过订单头来取得）

SELECT pr.po_release_id, pr.po_header_id, pr.release_num, pr.revision_num, pr.approved_flag, pr.release_type, pr.org_id FROM po_releases_all pr WHERE pr.po_header_id = 2767

PO_RELEASE_ID PO_HEADER_ID RELEASE_NUM REVISION_NUM APPROVED_FLAG RELEASE_TYPE ORG_ID 646 2767 1 0 Y SCHEDULED 102

发放行

实际上，发放行就来来源于po_line_locations_all ，我们在上面看到的Release_type中，新增了SCHEDULED的条数，而这些数据，正是由于发放产生的。

我们这里测试的是计划订单，如果是一揽子采购协议的话，Release_type是BLANKET的。

所以，从这里就可以非常清楚的了解到这种变化了。

也许，大家原有的疑问中：如为什么Ship Location里面有多条记录，而我只能查到一条呢？

我们把这个Form所涉及的View让大家看看也许大家就了解了

分解以后的语句中关键的一句是：

pll.shipment_type IN

('STANDARD', 'PLANNED', 'PRICE BREAK', 'RFQ', 'QUOTATION')

~~~~~~~~~~~~~~~~~~~~

还用解释吗？shipment_type 状态已经说明了这一切。

结论二：在做Release时，发运行和分配行根据发放次数动态增加，产生的Shipment Type为'SCHEDULED'（计划订单），

和'BLANKET'(一揽子采购