采购标准流程及底层分析

1、创建一采购订单

   创建一采购订单行

   系统 默认设置 发运行及分配行

        可以追加 发运行及分配行

   如:创建一采购订单,编码为:5011050

 组织 PSH

 物品 BCD-16OS-D

SELECT * FROM po_headers_all ph WHERE ph.segment1 = '5011050'

 

PO_HEADER_ID

AGENT_ID

14553

201

 

SELECT* FROM po_lines_all pl WHERE pl.po_header_id = 14553 ;

PO_LINE_ID

16679

 

SELECT * FROM po_line_locations_all pll WHERE pll.po_header_id = 14553 AND pll.po_line_id = 16679 ;

LINE_LOCATION_ID

PO_HEADER_ID

PO_LINE_ID

16419

14553

16679

16420

14553

16679

 

SELECT * FROM PO_DISTRIBUTIONS_all WHERE line_location_id IN (16419,16420)

PO_DISTRIBUTION_ID

PO_HEADER_ID

PO_LINE_ID

LINE_LOCATION_ID

16819

14553

16679

16419

16820

14553

16679

16420

 

 

 

<上面的Sample中,第一行发运及分配行,都是系统自动创建的。数量等同于订单行的数量。第二行都是我追加的>

 

Add By Boyle.lee 2006/07/27

---------------------

在很多取数时,我们经常从Po_distirbutions_all 来取得分配的信息和转化率等信息。

但是,有时候取出来的数据从EBS上看来时,是采购行->发运行->分配行,在我们的测试数据中,是1:1:1的关系。那么

我们是否可以这样做:

select * from po_distribution_id pd where pd.po_line_id = Po.po_lines_all.po_line_id ?

结果是否如我们所想的是一条呢(无论在什么时候)。

 

答案是:

让我们来观察一下我们最新的一个测试数据

SELECT * FROM PO_DISTRIBUTIONS_all pd WHERE pd.po_line_id = 24503 ;

SOURCE_DISTRIBUTION_ID

273

7285

ORG_ID

INVENTORY

273

DESTINATION_TYPE_CODE

274

INVENTORY

DESTINATION_ORGANIZATION_ID

54630

274

ACCRUAL_ACCOUNT_ID

7285

54630

PO_DISTRIBUTION_ID

2223

7288

PO_HEADER_ID

24503

2223

PO_LINE_ID

54645

24503

LINE_LOCATION_ID

1001

54648

SET_OF_BOOKS_ID

19487

1001

CODE_COMBINATION_ID

30

19487

QUANTITY_ORDERED

 

30

PO_RELEASE_ID

30

643

QUANTITY_DELIVERED

0

30

QUANTITY_BILLED

0

0

QUANTITY_CANCELLED

2006-7-19

0

RATE_DATE

8.021

2006-7-19

RATE

PLANNED

8.021

DISTRIBUTION_TYPE

 

SCHEDULED

 

 

这时候,问题来了。

一个采购行对应有多个分配行?

原因是什么? 是我们只要取其中一个? 还是发运行有多个只需要从中选择一个? 还是程序出错了? 还是采购接收或者入库或者别的会自动产生多条数据?

答案应该只有一个,我们先来看看Oracle怎么说的:

If SOURCE_DISTRIBUTION_ID has a value, the distribution is

part of a planned purchase order release.

 

计划订单?

对,答案就是它:这是一个计划订单。

每做一次RealesePO_distributions_all就会新增一条记录。这是计划订单的特性。

PO_RELEASES_ALL contains information about blanket and planned

purchase order releases. You need one row for each release you issue

for a blanket or planned purchase order. Each row includes the buyer,

date, release status, and release number. Each release must have at least

one purchase order shipment (PO_LINE_LOCATIONS_ALL).

RELEASE_NUM is the number you assign to the release.

对,Release表也会相应的增加记录,针对计划采购订单。

 

由于此篇文章工作量大,所以,我们专门开一个章节来讲述计划订单。

 

-----------------

接收:

采购订单创建完成后,审核OK好了就可以做接收了。

*****在审批时,发现他们系统有客户化要求,即同一订单行不能出现两个发运行,所以没办法,把我追加的发运行删除了(此发运行对应分配行自动删除)。

接收可以分步完成。

如上面的数据。我们先接收第一行的3台中的1台。数据如下:

SELECT * FROM rcv_transactions rt WHERE rt.interface_source_code = 'RCV' AND po_header_id = 14553 AND po_line_id = 16679

 

 

 

 

TRANSACTION_ID

747003

TRANSACTION_TYPE

RECEIVE

QUANTITY

1

UNIT_OF_MEASURE

dozen

SHIPMENT_HEADER_ID

672003

SHIPMENT_LINE_ID

687003

INTERFACE_SOURCE_CODE

RCV

SOURCE_DOCUMENT_CODE

PO

DESTINATION_TYPE_CODE

RECEIVING

PRIMARY_QUANTITY

1

PRIMARY_UNIT_OF_MEASURE

dozen

PO_HEADER_ID

14553

PO_LINE_ID

16679

PO_LINE_LOCATION_ID

16419

PO_DISTRIBUTION_ID

 

再接收第一行的3台中的2台。差异数据如下:

SELECT * FROM rcv_transactions rt WHERE rt.interface_source_code = 'RCV' AND po_header_id = 14553 AND po_line_id = 16679

TRANSACTION_ID

747004

747003

SHIPMENT_LINE_ID

687004

687003

PRIMARY_QUANTITY

2

1

 

------------------------rcv_receiving_sub_ledger 接收事务处理产生的分配行。

接收事务处理:

接收之后,其实现在还并没有入库。我们要接着做接收事务处理。把采购接收的数据入库。

 

SELECT * FROM rcv_transactions rt WHERE rt.interface_source_code = 'RCV' AND po_header_id = 14553 AND po_line_id = 16679

TRANSACTION_ID

747004

747005

747006

747003

TRANSACTION_TYPE

RECEIVE

DELIVER

DELIVER

RECEIVE

QUANTITY

2

1

2

1

UNIT_OF_MEASURE

dozen

dozen

dozen

dozen

SHIPMENT_HEADER_ID

672003

672003

672003

672003

SHIPMENT_LINE_ID

687004

687003

687004

687003

INTERFACE_SOURCE_CODE

RCV

RCV

RCV

RCV

SOURCE_DOCUMENT_CODE

PO

PO

PO

PO

DESTINATION_TYPE_CODE

RECEIVING

INVENTORY

INVENTORY

RECEIVING

PRIMARY_QUANTITY

2

1

2

1

PRIMARY_UNIT_OF_MEASURE

dozen

dozen

dozen

dozen

PO_HEADER_ID

14553

14553

14553

14553

PO_LINE_ID

16679

16679

16679

16679

PO_LINE_LOCATION_ID

16419

16419

16419

16419

PO_DISTRIBUTION_ID

 

16819

16819

 

 

因为涉及入库操作,所以,在库存事务处理表中会留下相应的记录。即在Mtl_material_transactions表中,会存在相应的两条入库记录。

SELECT * FROM mtl_material_transactions mmt

TRANSACTION_ID

547128

547132

TRANSACTION_TYPE_ID

18

18

TRANSACTION_ACTION_ID

27

27

TRANSACTION_SOURCE_TYPE_ID

1

1

TRANSACTION_SOURCE_ID

14553

14553

TRANSACTION_QUANTITY

1

2

TRANSACTION_UOM

DZ

DZ

DISTRIBUTION_ACCOUNT_ID

4321

4321

TRANSACTION_SET_ID

547125

547130

RCV_TRANSACTION_ID

747005

747006

SOURCE_CODE

RCV

RCV

SOURCE_LINE_ID

747005

747006

 

 

 

以上,通过总结,主要有如下取数要求及判断逻辑

 

1、取已审批销售订单头和行的数据

   涉及表: Po_headers_all,Po_lines_all

   逻辑如下:

   限制头表的如下属性,并通过Po_header_id把头、行表关联起来

   APPROVED_FLAG      Y

   APPROVED_DATE      2006-4-25 下午 01:48:14 (需要确认客户的需求)

 

2、取订单与其发运的关系 (可能存在多次发运)

   涉及表: Po_headers_all,Po_lines_all,po_line_locations_all

   逻辑如下:

   限制头表条件1

   Po_line_locations通过po_line_id / (po_header_id,Po_line_id)关联起来。

  

3、取订单发运行与分配行的关系 (可能存在多个分配)

   涉及表: PO_DISTRIBUTIONS_all, Po_headers_all,Po_lines_all,po_line_locations_all

   逻辑如下:

   限制头表条件

   PO_DISTRIBUTIONS_all通过line_locations_id/(line_locations_id,Po_line_id)/(    line_locations_id,Po_line_id,po_header_id)与发运行关联起来。

  

3、取接收数据 (可能分多次接收)

   涉及表: Rcv_Transactions

   逻辑如下:

   TRANSACTION_TYPE                 RECEIVE

   INTERFACE_SOURCE_CODE     RCV

   SOURCE_DOCUMENT_CODE            PO

   DESTINATION_TYPE_CODE       RECEIVING

   PO_HEADER_ID                 关联至采购订单头

   PO_LINE_ID                        关联至采购订单行

   PO_LINE_LOCATION_ID            关联至发运行

  

 

5、取接收入库数据

   涉及表: Rcv_Transactions

   逻辑如下: (可能有多次接收入库)

   TRANSACTION_TYPE                                      DELIVER

   INTERFACE_SOURCE_CODE                             RCV

   SOURCE_DOCUMENT_CODE                        PO

   DESTINATION_TYPE_CODE                                   INVENTORY

   PO_HEADER_ID                                     关联至采购订单头

   PO_LINE_ID                                                关联至采购订单行

   PO_LINE_LOCATION_ID                                 关联至发运行

   PO_DISTRIBUTION_ID                                   关联至分配行

或者

   涉及表: mtl_material_transactions

   逻辑如下:(针对每一接收入库的操作,有一行对应的库存事务处理)

   TRANSACTION_TYPE_ID                                18 PO 接收)

   TRANSACTION_ACTION_ID                                  27 (接收至库存)

--   TRANSACTION_SOURCE_TYPE_ID     1 (采购订单)--如果需要明确到采购订单,可以调用此标识

--   TRANSACTION_SOURCE_ID   14553          --如果需要明确到采购订单(头),可以调用此标识

 

×××事务处理来源类型是 Oracle Inventory 计算事务处理费用时所依据的实体类型。它与事务处理活动一起唯一地标识您所执行的事务处理的类型。

 

BTW:

取退货的数量:

 

我做了个简单的测试。创建了一个PO,包含一条记录。100台。

接收了100

第一次退货至接收 10

      退货至供应商 21

记录如下

SELECT * FROM rcv_transactions rt WHERE rt.interface_source_code IS NULL AND po_header_id = 14601 AND po_line_id = 16741

TRANSACTION_ID

749013

749014

749015

TRANSACTION_TYPE

RETURN TO RECEIVING

RETURN TO RECEIVING

RETURN TO VENDOR

SOURCE_DOCUMENT_CODE

PO

PO

PO

DESTINATION_TYPE_CODE

RECEIVING

INVENTORY

RECEIVING

QUANTITY

10

21

21

UNIT_OF_MEASURE

dozen

dozen

dozen

SHIPMENT_HEADER_ID

674007

674007

674007

SHIPMENT_LINE_ID

689003

689003

689003

PO_HEADER_ID

14601

14601

14601

PO_LINE_ID

16741

16741

16741

PO_LINE_LOCATION_ID

16481

16481

16481

PO_DISTRIBUTION_ID

16861

16861

16861

 

从上述数据可以看出来

 

退货至接收时,产生一条记录,退货至供应商时,产生两条数据。

可见退货的实际顺序为: 库存----> 接收 ----> 供应商

 

同时,我们去查看MMT

SELECT * FROM mtl_material_transactions WHERE    TRANSACTION_SOURCE_TYPE_ID

TRANSACTION_ID

550160

550166

550170

TRANSACTION_TYPE_ID

18

36

36

TRANSACTION_ACTION_ID

27

1

1

TRANSACTION_QUANTITY

100

-10

-21

TRANSACTION_UOM

DZ

DZ

DZ

从上述数据可以看出来

 

不管是退货至接收还是退货至供应商,在事务处理中,都会产生两条记录。而且,数量符号与接收的数据正好相反。而且产生的记录都是RETURN TO RECEIVING

 

从业务的角度来说:

 退回至供应商一般是某批商品有问题。

 退回至接收一般是因为录入错误造成的。如来的货物是9台,录时录成了10台。我们可以用退回至接收1台。等待这一台来了后再做接收。

 

好,我们接下来把退货至接收的那条数据再次退货至供应商,看看发生了什么样的情况。

TRANSACTION_ID

749013

749014

749015

749016

TRANSACTION_TYPE

RETURN TO RECEIVING

RETURN TO RECEIVING

RETURN TO VENDOR

RETURN TO VENDOR

QUANTITY

10

21

21

10

UNIT_OF_MEASURE

dozen

dozen

dozen

dozen

SHIPMENT_HEADER_ID

674007

674007

674007

674007

SHIPMENT_LINE_ID

689003

689003

689003

689003

SOURCE_DOCUMENT_CODE

PO

PO

PO

PO

DESTINATION_TYPE_CODE

RECEIVING

INVENTORY

RECEIVING

RECEIVING

PO_HEADER_ID

14601

14601

14601

14601

PO_LINE_ID

16741

16741

16741

16741

PO_LINE_LOCATION_ID

16481

16481

16481

16481

PO_DISTRIBUTION_ID

16861

16861

16861

 

 

从上述数据可以看出来

 

新产生了一条记录,从Receving退货至Return To Vendor

而且,这条记录并没有记录PO_DISTRIBUTION_ID,即我们不能从退货至Receving再从RecevingReturn To Vendor中去查找他原始的位置。

    

所以,我们如果要取退货的数量,或者取订单的接受数量(在有退货的时候),需要从如下来取。

 

 涉及表: Rcv_Transactions

   逻辑如下: (可能有多次退货)

   TRANSACTION_TYPE                 RETURN TO RECEIVING

   INTERFACE_SOURCE_CODE    

   SOURCE_DOCUMENT_CODE            PO

   DESTINATION_TYPE_CODE      

   PO_HEADER_ID                 关联至采购订单头

   PO_LINE_ID                        关联至采购订单行

   PO_LINE_LOCATION_ID            关联至发运行

--------###   PO_DISTRIBUTION_ID           关联至分配行 (此处已经不准确)

 

但是,虽然我们再次做了退货,发现MMT的数据并没有改变。所以。我们可以直接从事务处理来取数。

 

或者

   涉及表: mtl_material_transactions

   逻辑如下:(针对每一退货至供应商的操作,有一行对应的库存事务处理)

   TRANSACTION_TYPE_ID           36 (向供应商退货)

   TRANSACTION_ACTION_ID      1 (从库存发放)

--   TRANSACTION_SOURCE_TYPE_ID 1 (采购订单)--如果需要明确到采购订单,可以调用此标识

--   TRANSACTION_SOURCE_ID   14601          --如果需要明确到采购订单(头),可以调用此标识

 

  

 

------------------------------------

--综上所述,最好的取采购订单入库数量(包括入库与退货)

--的方法为:

Way1

SELECT nvl(SUM(nvl(mmt.primary_quantity, 0)), 0)
 FROM rcv_transactions          rt,
       mtl_material_transactions mmt
 WHERE mmt.transaction_source_type_id =
1 --Purchasing Order
   AND rt.transaction_id = mmt.rcv_transaction_id;

 

Way2


SELECT nvl(SUM(nvl(mmt.primary_quantity,
0)), 0)
 FROM mtl_material_transactions mmt
 WHERE mmt.transaction_source_type_id =
1 --Purchasing Order
;

这两种方法。一般来说。大家无所谓选哪种方法。只要综合一下执行效率就行。

但是,这里面有一种情况,有时候,MMT里面有数据,而这些数据在RT中并不存在(RT异常)。这时候,我们就要想一下了。

如果我们要计算通过采购订单确认准确的库存量。我们也许只能取Way2了。这个时候,最好与业务人员商量一下了。

posted @ 2011-05-11 19:43  郭振斌  阅读(1867)  评论(0编辑  收藏  举报