计划采购订单
采购订单，有标准采购订单、计划类采购订单、一揽子采购协议等。
我们现在就分别来讲述这三者的差别，并在此章节着重讲述计划类采购订单。
一、采购订单
标准采购订单(从一供应商处做一次性物料或服务的采购)
建议:当你与供应商确认了采购对象(物料或服务), 数量, 发货计划, 但是不存在长期的约定时, 可使用标准采购订单.
合同采购订单(为一种协议，在该协议上只确定总金额数)
建议：该类型订单使用于你未确定购买对象，只确定供应商和购买金额的情况. 例如: 百货公司进货需要根据市场变化来决定购买对象.因此可以先确定供应商和购买总金额, 在实际需要时,才决定购买的内容.
一揽子协议(为一种协议,在该协议上决定了购买对象)
建议:当你与供应商仅确认了采购对象(物料或服务), 或者加上购买价格时, 你可使用此种订单类型. 该订单类型适用于, 当你未能肯定购买数量和需要时间时建立此种类型订单. 在需要时, 才建立一揽子协议的发放来决定数量和时间通知供应商.
计划采购订单(为长期供货订单)
建议:该订单类型适用于长期稳定的供货需求.可事先与供应商谈妥购买对象, 购买金额, 购买数量和一个长远的到期日.在需要供货时, 建立计划采购订单发放来通知供应商供货.
二、各采购订单做成测试
标准采购订单： 详见：采购标准操作及数据做成
合成采购订单： 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'; | ||||||
|
表结构特征：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'; | ||||||
|
表结构特征：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'; | ||||||
|
表结构特征：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 | ||||||||||||||||||||||||||||||
|
分配行：
|
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 | ||||||||||||||||||||||||||
|
这个时候，我们看不出来什么特别的地方，发运行中一行，分配行中也是一行。
订单->发运行->分配行
这时候因为还没有做订单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的，此处未列出来） | |||||||||||||||||||||||||||||||||||||||||||||
|
分配行：
|
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 | |||||||||||||||||||||||||||||||||||||||
|
发放头（通过订单头来取得）
|
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_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'(一揽子采购协议)，相对应的发放行也会增加（发放行从发运行直接取数）。
3. 接收入与库
好了。我们既然做了发放，那么，相对应的接收与入库是怎么进行的？是否和标准订单行一样了？
开始！
我们既然把刚才数量的10台又发放2台。
那么，就有两次发放了。
(发放时，我们针对采购订单进行两次不同的发放，那么，主键是PO+Release Number，
如果我们在同一发放内，进行多次发放，那么，主键是PO+Version
所以，发放的主键应该是 PO+Release Number+Version)
在接收中，可以取到我们发放后的订单行。后面进行的入库与标准订单也是一样的操作了。
我们看看接收的画面：
接下来的流程我们就不看了。此处的弹性域是可以更改OC 价格的。这个价格就是最终的接收行价格(IV)。
