EBS |
您所在的位置:网站首页 › 怎么关联采购计划信息 › 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'(一揽子采购 |
今日新闻 |
推荐新闻 |
CopyRight 2018-2019 办公设备维修网 版权所有 豫ICP备15022753号-3 |