【轉】采购标准流程及底层分析
2012-05-08 10:11
162 查看
1、创建一采购订单
创建一采购订单行
系统 默认设置 发运行及分配行
可以追加 发运行及分配行
如：创建一采购订单，编码为：5011050
组织 （PSH）
物品 BCD-16OS-D
<上面的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 ?
结果是否如我们所想的是一条呢（无论在什么时候）。
答案是： 否
让我们来观察一下我们最新的一个测试数据
这时候，问题来了。
一个采购行对应有多个分配行？
原因是什么？ 是我们只要取其中一个？ 还是发运行有多个只需要从中选择一个？ 还是程序出错了？ 还是采购接收或者入库或者别的会自动产生多条数据？
答案应该只有一个，我们先来看看Oracle怎么说的：
计划订单？
对，答案就是它：这是一个计划订单。
每做一次Realese，PO_distributions_all就会新增一条记录。这是计划订单的特性。
对，Release表也会相应的增加记录，针对计划采购订单。
由于此篇文章工作量大，所以，我们专门开一个章节来讲述计划订单。
-----------------
接收：
采购订单创建完成后，审核OK好了就可以做接收了。
*****在审批时，发现他们系统有客户化要求，即同一订单行不能出现两个发运行，所以没办法，把我追加的发运行删除了（此发运行对应分配行自动删除）。
接收可以分步完成。
如上面的数据。我们先接收第一行的3台中的1台。数据如下：
再接收第一行的3台中的2台。差异数据如下：
SELECT * FROM rcv_transactions rt WHERE rt.interface_source_code = 'RCV' AND po_header_id = 14553 AND po_line_id = 16679
------------------------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
因为涉及入库操作，所以，在库存事务处理表中会留下相应的记录。即在Mtl_material_transactions表中，会存在相应的两条入库记录。
SELECT * FROM mtl_material_transactions mmt
以上，通过总结，主要有如下取数要求及判断逻辑
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
从上述数据可以看出来
退货至接收时，产生一条记录，退货至供应商时，产生两条数据。
可见退货的实际顺序为: 库存----> 接收 ----> 供应商
同时，我们去查看MMT表
SELECT * FROM mtl_material_transactions WHERE TRANSACTION_SOURCE_TYPE_ID
从上述数据可以看出来
不管是退货至接收还是退货至供应商，在事务处理中，都会产生两条记录。而且，数量符号与接收的数据正好相反。而且产生的记录都是RETURN TO RECEIVING。
从业务的角度来说：
退回至供应商一般是某批商品有问题。
退回至接收一般是因为录入错误造成的。如来的货物是9台，录时录成了10台。我们可以用退回至接收1台。等待这一台来了后再做接收。
好，我们接下来把“退货至接收”的那条数据再次“退货至供应商”，看看发生了什么样的情况。
从上述数据可以看出来
新产生了一条记录，从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 --如果需要明确到采购订单（头），可以调用此标识
------------------------------------
--综上所述，最好的取采购订单入库数量（包括入库与退货）
--的方法为：
这两种方法。一般来说。大家无所谓选哪种方法。只要综合一下执行效率就行。
但是，这里面有一种情况，有时候，MMT里面有数据，而这些数据在RT中并不存在（RT异常）。这时候，我们就要想一下了。
如果我们要计算通过采购订单确认准确的库存量。我们也许只能取Way2了。这个时候，最好与业务人员商量一下了。
创建一采购订单行
系统 默认设置 发运行及分配行
可以追加 发运行及分配行
如：创建一采购订单，编码为：5011050
组织 （PSH）
物品 BCD-16OS-D
SELECT * FROM po_headers_all ph WHERE ph.segment1 = '5011050'
|
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. |
由于此篇文章工作量大，所以，我们专门开一个章节来讲述计划订单。
-----------------
接收：
采购订单创建完成后，审核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 | |
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 |
接收事务处理：
接收之后，其实现在还并没有入库。我们要接着做接收事务处理。把采购接收的数据入库。
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 | |
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了。这个时候，最好与业务人员商量一下了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 【轉】采购标准流程及底层分析
- 标准的Windows蓝屏故障的分析、处理流程和VMware服务错误记录
- 采购标准流程及底层分析
- SylixOS中MTD调用底层接口流程分析
- 采购标准流程及底层分析
- 采购标准流程及底层分析
- android_framework日记3-MT流程底层消息机制分析
- SylixOS中MTD调用底层接口流程分析
- Realtek 2861 7.1方案 底层接口API调用流程分析
- 深入浅出从底层分析 Redis client/server交互流程（干货）
- 分析数据在协议栈底层的流程
- HEVC码率控制算法研究与HM相应代码分析（一）——HEVC标准及编码流程介绍
- 传统三单匹配的制造业采购付款流程风险和弊端分析
- RTSP协议分析与标准RTSP服务端与客户端交互流程
- PO(采购)流程影响会计的环节分析
- 分析springmvc底层调用流程
- nova boot代码流程分析(四)：nova与neutron的l2 agent(neutron-linuxbridge-agent)交互
- lk启动流程分析
- FFMpeg对MPEG2 TS流解码的流程分析[2]
- (7)Launcher3分析之拖动图标的流程——按下