采购标准流程及底层分析

fishswl

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.

计划订单？

对，答案就是它：这是一个计划订单。

每做一次Realese，PO_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再从Receving中Return 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了。这个时候，最好与业务人员商量一下了。

gaoyiming

赞一个
向lz学习

智者

LZ對數据研究的這麽透徹，精神可以值得大家學習！建議版主將此帖設為精華供大家互相學習！！:02526o2

skyczn

赞叹楼主深挖硬掘之精神，向你致敬.

sung

真是好帖 佩服

sunweijie22

太棒了,要求加精

boyle

大哥,你发表我的文章...至少要写个转发或者签上我的名吧.~~ 我是原文作者.

chance

果然是好帖啊~~~~~楼主强悍，学习

xdp4507

boyle 发表于 2008/1/10 21:09
大哥,你发表我的文章...至少要写个转发或者签上我的名吧.~~ 我是原文作者.

文章不错。
原著牛

flyhenry

what  I want to need is like this article,thanks for the writer and the author

aeschylus

回复 fishswl 的帖子

楼主分析得很好，学习了。

shanjinno1

最后那啥两个方法啊。。想得到最终入库接收的数量就是从物料事务处理表里去就是了。。po_line_id=24503那个测试图框第一列数据错乱，这个也能加精华？