采购订单,有标准采购订单、计划类采购订单、一揽子采购协议等。
我们现在就分别来讲述这三者的差别,并在此章节着重讲述计划类采购订单。
一、采购订单
标准采购订单(从一供应商处做一次性物料或服务的采购)
建议:当你与供应商确认了采购对象(物料或服务), 数量, 发货计划, 但是不存在长期的约定时, 可使用标准采购订单.
合同采购订单(为一种协议,在该协议上只确定总金额数)
建议:该类型订单使用于你未确定购买对象,只确定供应商和购买金额的情况. 例如: 百货公司进货需要根据市场变化来决定购买对象.因此可以先确定供应商和购买总金额, 在实际需要时,才决定购买的内容.
一揽子协议(为一种协议,在该协议上决定了购买对象)
建议:当你与供应商仅确认了采购对象(物料或服务), 或者加上购买价格时, 你可使用此种订单类型. 该订单类型适用于, 当你未能肯定购买数量和需要时间时建立此种类型订单. 在需要时, 才建立一揽子协议的发放来决定数量和时间通知供应商.
计划采购订单(为长期供货订单)
建议:该订单类型适用于长期稳定的供货需求.可事先与供应商谈妥购买对象, 购买金额, 购买数量和一个长远的到期日.在需要供货时, 建立计划采购订单发放来通知供应商供货.
二、各采购订单做成测试
标准采购订单: 详见:采购标准操作及数据做成
合成采购订单: 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'(一揽子采购