简介Oracle ERP R12表结构参考文档面向实施顾问、运维人员和二次开发工程师系统梳理应收(AR)、库存(INV)、应付(SQLAP)、总账(SQLGL)、资产(OFA)、现金管理(CE)、订单管理(OE)、制造(GMD)、税务(ZX)、子分类账(XLA)等核心模块的业务表与关键字段帮助理解业务数据在底层表间的流转关系。压缩包共112个文件含58个PDF与54个HTMLPDF便于离线研读、标注与打印HTML适合在浏览器中按超链接逐表跳转包体仅3.42MB轻巧易携带。已有390人学习下载适合需要开展数据迁移、报表开发、接口设计或系统集成的技术人员也能帮助Oracle EBS初学者快速建立模块-表-字段的整体认知。文档按模块分目录组织每张表均给出字段名、类型及主外键关联提示部分表格还附有与相关模块的引用关系既可作为日常工作的速查手册也可作为R12表结构培训的配套材料便于按需查阅与对照学习。1. Oracle ERP R12 表结构先搞清楚它是一套“业务账本”而不是一堆表接到一个 R12 相关的报表或接口需求很多人第一反应是打开 PL/SQL Developer 敲 SELECT结果在表里翻了大半天数据对不上、组织对不上、甚至表都没找对。oracle erp r12表结构这套东西的难点从来不是 SQL 语法而是它背后的业务记账逻辑发票、采购单、库存事务、总账凭证之间靠什么字段串联多组织环境怎么过滤R12 引入的子分类账 XLA 又怎么和 11i 的旧习惯冲突。这篇文章想讲清楚三件事核心模块的表长什么样、用什么方法定位表、以及查询时会踩哪些坑。适合做报表开发、接口对接、数据迁移的顾问和开发也适合刚接触 EBS 生态的 DBA 快速建立一张“表结构地图”。2. 四大核心模块的表结构拆解AP/AR/GL/INV 的看家表R12 的表结构是有规律可循的标准表大多带_ALL后缀表示多组织共享不带_ALL的表要么是公共主数据要么是视图。你只要抓住每个模块里那两三张“看家表”后面一切都好办。下面按业务链条把应付、应收、总账、库存四个模块的核心表拆开看。模块核心表一句话定位APAP_INVOICES_ALL / AP_INVOICE_DISTRIBUTIONS_ALL发票头与分配行ARHZ_CUST_ACCOUNTS / AR_TRX_ALL客户账户与应收事务GLGL_JE_HEADERS / GL_JE_LINES / GL_JE_BATCHES凭证批、头、行INVMTL_SYSTEM_ITEMS_B / MTL_MATERIAL_TRANSACTIONS物料主数据与事务历史2.1 AP 模块从 AP_INVOICES_ALL 到发票分配行应付模块的查询需求70% 都落在“这个供应商的发票进来没有、过账没有”。R12 里发票头的主表是AP_INVOICES_ALL比 11i 多了_ALL后缀别再用AP_INVOICES去查。发票分配行在AP_INVOICE_DISTRIBUTIONS_ALL一张发票可能有多行分配每行对应一个科目。SELECT ai.invoice_num, -- 发票编号业务上的发票号 ai.invoice_date, -- 发票日期 ai.invoice_amount, -- 发票金额 ai.payment_status_flag, -- 付款状态N未付Y已付 po.vendor_name, -- 供应商名称 aid.distribution_line_number, -- 分配行号 aid.code_combination_id -- 科目组合ID关联GL_CODE_COMBINATIONS FROM ap_invoices_all ai LEFT JOIN ap_suppliers po -- R12里供应商主表叫AP_SUPPLIERS ON ai.vendor_id po.vendor_id LEFT JOIN ap_invoice_distributions_all aid ON ai.invoice_id aid.invoice_id WHERE ai.invoice_date TRUNC(SYSDATE) - 30 ORDER BY ai.invoice_date DESC;这条 SQL 的关键在关联方式AP_INVOICES_ALL和分配行之间通过INVOICE_ID关联供应商通过VENDOR_ID关联到AP_SUPPLIERS。R12 里AP_VENDORS这个旧名还在但它已经变成视图底层指向AP_SUPPLIERS你自己连的时候直接用AP_SUPPLIERS更省心。CODE_COMBINATION_ID在 R12 里仍然存在但要注意科目描述要再去关联GL_CODE_COMBINATIONS这是后面避坑章节要展开的重点。2.2 AR 模块TCA 架构下的客户主数据与事务表应收模块是 R12 表结构变化最大的地方。如果你还在用 11i 的习惯去查AR_CUSTOMERS大概率能查到数据但它已经不是主数据源头了。R12 的客户主数据已经迁移到 TCA 架构核心表是HZ_PARTIES自然人/组织的基本信息、HZ_CUST_ACCOUNTS客户账户、HZ_CUST_ACCT_SITES_ALL客户账户地点。AR_CUSTOMERS在 R12 里更多是兼容视角。SELECT ha.customer_name, -- 客户名称来自HZ_PARTIES hca.account_number, -- 客户账户编号 hcas.site_use_code, -- 地点用途BILL_TO / SHIP_TO hcas.status, -- 地点状态A有效 hcsa.location -- 地点描述来自HZ_LOCATIONS FROM hz_cust_accounts hca LEFT JOIN hz_parties ha ON hca.party_id ha.party_id LEFT JOIN hz_cust_acct_sites_all hcas ON hca.cust_account_id hcas.cust_account_id LEFT JOIN hz_cust_site_uses_all hcsa ON hcas.cust_acct_site_id hcsa.cust_acct_site_id WHERE hca.status A AND hcas.status A AND hcas.site_use_code BILL_TO;TCA 查询的关键是不要从AR_CUSTOMERS出发而是从HZ_CUST_ACCOUNTS出发。HZ_CUST_ACCT_SITES_ALL存地点HZ_CUST_SITE_USES_ALL存这个地点是开票地址还是收货地址。四张表串起来才能拿到“哪个客户的哪个地点用来开票”。应收事务本身在AR_TRX_ALLR12 中通常以视图形式出现底层由多组织访问控制管理查应收余额时再关联AR_PAYMENT_SCHEDULES_ALL拿到期日和已收金额。2.3 GL 模块GL_JE_HEADERS 背后的凭证链路总账模块的表结构相对稳定核心是凭证批、凭证头、凭证行三层GL_JE_BATCHES→GL_JE_HEADERS→GL_JE_LINES。日常查询“某个月哪些凭证还没过账”或者在接口里判断凭证是否已导入成功都是围绕这三张表。SELECT gjb.name AS batch_name, -- 凭证批名称 gjh.je_header_id, -- 凭证头ID gjh.name AS je_name, -- 凭证名称 gjh.status AS je_status, -- U未过账P已过账 gjl.je_line_num, -- 行号 gjl.code_combination_id, -- 科目组合ID gjl.entered_dr, -- 原币借方 gjl.entered_cr -- 原币贷方 FROM gl_je_batches gjb JOIN gl_je_headers gjh ON gjb.je_batch_id gjh.je_batch_id JOIN gl_je_lines gjl ON gjh.je_header_id gjl.je_header_id WHERE gjh.period_name 2025-05 AND gjh.status P ORDER BY gjh.je_header_id, gjl.je_line_num;这里有一个 R12 特有的过滤习惯凭证行里STATUS只有U未过账、P已过账两种状态最常用但在接口场景里你还要留意POSTED_DATE字段是否为 NULL这是“已经入账但还没写日期”的典型状态。凭证行金额记住一点ENTERED_DR和ENTERED_CR是原币金额ACCOUNTED_DR和ACCOUNTED_CR才是本位币金额。跨国业务里这两个值经常不一样做报表时先确认需求要哪个币种口径。2.4 INV 模块物料主数据与库存事务库存模块的查询也很有代表性。物料主数据在MTL_SYSTEM_ITEMS_B字段名带_B表示这是基础表存储结构化的物料属性描述性的可翻译字段在MTL_SYSTEM_ITEMS_TL翻译表。库存余额在MTL_ONHAND_QUANTITIES视图里底层是MTL_ONHAND_QUANTITIES_DETAIL等表。事务历史在MTL_MATERIAL_TRANSACTIONS这张表几乎记录了所有库存进出动作。SELECT msi.segment1 AS item_code, -- 物料编码 msi.description AS item_desc, -- 物料描述 msi.primary_uom_code AS uom, -- 主计量单位 mtr.transaction_id, -- 事务ID mtr.transaction_date, -- 事务日期 mtr.transaction_quantity, -- 事务数量正入负出 mtr.transaction_type_name -- 事务类型采购入库/销售出库/杂项 FROM mtl_system_items_b msi JOIN mtl_material_transactions mtr ON msi.inventory_item_id mtr.inventory_item_id WHERE msi.segment1 LIKE RM% AND mtr.transaction_date TRUNC(SYSDATE) - 7;注意物料关联事务表用的是INVENTORY_ITEM_ID加上ORGANIZATION_ID两个字段一起锁定的。MTL_SYSTEM_ITEMS_B里的物料编码字段叫SEGMENT1而不是ITEM_CODE这是很多新手做接口时第一个翻车点。MTL_MATERIAL_TRANSACTIONS的TRANSACTION_QUANTITY是带方向的入库为正、出库为负。查询消耗类报表时记得用负值过滤不要把正负混在一起求和。3. 在 R12 里定位表结构的三条路数据字典、界面反查与 MOAC 环境知道模块核心表还不够实际项目里你往往是拿到一个业务需求要从中文描述反推出表名和字段名。R12 里定位表结构有三条路用数据字典按关键词搜、通过界面操作反查、以及设置多组织环境。3.1 用 ALL_TAB_COLUMNS 和 FND_* 字典按关键词找表R12 的表注释分两层底层的ALL_TAB_COLUMNS有字段名和数据类型但中文业务注释经常是空的真正的业务注释在 EBS 应用层字典表FND_TABLES和FND_COLUMNS里。所以排查注释问题之前先记住两条 SQL。-- 按字段注释里的中文关键词找表 SELECT table_name, column_name, comments FROM all_tab_columns WHERE comments LIKE %发票% AND owner APPS ORDER BY table_name; -- 按表注释里的业务关键词找表 SELECT table_name, table_type, table_comment FROM all_tab_comments WHERE table_type TABLE AND comments LIKE %客户% ORDER BY table_name;如果ALL_TAB_COLUMNS查出来COMMENTS为空别急着下结论再查FND_COLUMNS。R12 里应用层的字段语义往往在FND_COLUMNS和FND_DESCRIPTION上。一个稳定的做法是先用ALL_TAB_COLUMNS定位物理表再用FND_COLUMNS补语义两边对照后写到自己的速查表里。搜索关键词时优先用模块词发票、供应商、凭证不要用太宽的词信息、备注否则一张报表要捞上百张表没意义。3.2 从录入界面反查业务表EBS 的“检查”追数三板斧遇到“界面上有这个字段但不知道存在哪张表”的情况最经典的三板斧是这样第一打开 EBS 的“帮助”-“诊断”-“检查”功能鼠标点击界面上的字段会弹出该字段对应的表名和列名第二用FND_FORM_FUNCTIONS反查当前功能菜单绑定的表单名称再去找这个表单对应的基表第三开启 SQL Trace 抓当前会话的后台 SQL操作一次界面后台跑的 SQL 会直接带出表名。-- 通过功能名称反查表单与核心表 SELECT fff.function_name, fff.user_function_name, ffv.form_name, ffv.application_id FROM fnd_form_functions fff LEFT JOIN fnd_form_vl ffv ON fff.form_id ffv.form_id WHERE fff.user_function_name LIKE %发票% ORDER BY fff.function_name;这里的逻辑是每个 EBS 界面功能都有一条FND_FORM_FUNCTIONS记录绑定一个FORM而FORM背后往往有主表信息。配合第三种方式更直接——一个会话里跑一次业务操作然后看V$SQL里最近执行的语句表名自然浮出水面。做报表开发时前两个方法足够定位到“大概哪几张表”SQL Trace 是最后的兜底别一上来就全开 Trace影响生产环境性能。3.3 多组织下的环境设置没配 MOAC 就别谈查数据R12 的多组织访问控制MOAC是表结构查询里最容易被忽略的前提条件。同样的AP_INVOICES_ALL表不同操作单位OU看到的数据集合可能完全不同。EBS 界面上通过职责自动控制但用 SQL 客户端直连数据库时必须手工设置环境否则就是“有表却查不到数据”的经典翻车现场。-- 设置当前会话的MOAC环境以某OU为例 BEGIN fnd_global.apps_initialize( user_id 1314, -- APPS用户ID自查fnd_user resp_id 51513, -- 职责ID自查fnd_responsibility resp_appl_id 202 -- 职责所属应用ID自查fnd_application ); mo_global.init(M); -- M多组织模式 mo_global.set_policy_context(S, 113); -- 113为业务实体ID END; /设置完成后你的会话里查AP_INVOICES_ALL会自动按照当前 OU 的访问权限过滤数据。用 TOAD 或 SQL Developer 连数据库做报表的时候每次都先跑这段初始化脚本再查业务表。很多“半夜数据对不上”的问题都出在这——白天在 EBS 界面上看到的数据和晚上 SQL 里查出来的不一样因为两边 MOAC 上下文不一致。设置里的113是HR_OPERATING_UNITS里的ORGANIZATION_ID从哪里拿查询HR_OPERATING_UNITS再结合HR_ALL_ORGANIZATION_UNITS_TL的名称来确认。4. 跨模块表关联链路从采购到总账的主键流转单独看一张表谁都会真正值钱的技能是跨模块串联一张采购入库单怎么变成应付发票又怎么变成总账凭证。R12 的跨模块链路比 11i 清晰得多主键流转是有固定套路的。4.1 采购到应付用 PO_HEADER_ID 和 VENDOR_ID 搭桥采购订单头在PO_HEADERS_ALL采购订单行在PO_LINES_ALL。应付发票匹配采购单后并不直接在发票表上存采购单号而是通过PO_HEADER_ID存“来源单据 ID”。查询“这张发票是从哪张 PO 来的”走的就是这张桥。SELECT ai.invoice_num, ph.segment1 AS po_number, -- PO单号 pl.line_num AS po_line, -- PO行号 aid.amount AS distribution_amt FROM ap_invoices_all ai JOIN ap_invoice_distributions_all aid ON ai.invoice_id aid.invoice_id LEFT JOIN po_headers_all ph ON aid.po_header_id ph.po_header_id LEFT JOIN po_lines_all pl ON aid.po_line_id pl.po_line_id WHERE ai.invoice_date TRUNC(SYSDATE) - 90 AND aid.po_header_id IS NOT NULL;这里的关键字段是AP_INVOICE_DISTRIBUTIONS_ALL里的PO_HEADER_ID和PO_LINE_ID业务含义是“发票分配行匹配的采购单头与采购单行”。匹配不是发生在发票头上而是发生在分配行上因为一张发票可能同时匹配多个 PO。PO_HEADERS_ALL.SEGMENT1才是人看的单号PO_HEADER_ID是对外接口用的数字主键。报表里不要把两张表直接通过单号关联要先用 ID 关联再展示号码否则遇到 PO 单号被修改、历史单据迁移等情况会直接关联不上。4.2 应付到总账XLA 子分类账的三层结构R12 最大的表结构变化就是 XLA 子分类账架构。AP、AR、INV 等模块过账时不再直接往GL_JE_LINES写数据而是先写入 XLA 的三层表XLA_TRANSACTION_ENTITIES事务实体、XLA_AE_HEADERS会计事件头、XLA_AE_LINES会计事件行。查“某张发票生成了什么凭证”不再去 GL 硬翻而是查 XLA。SELECT ae_header.ae_header_id, -- 会计事件头ID ae_header.gl_transfer_status, -- 是否已转入GLY/N ae_line.account_class, -- 科目类型ASSET/LIABILITY等 ae_line.code_combination_id, ae_line.entered_dr, ae_line.entered_cr FROM xla_transaction_entities entity JOIN xla_ae_headers ae_header ON entity.entity_id ae_header.entity_id JOIN xla_ae_lines ae_line ON ae_header.ae_header_id ae_line.ae_header_id WHERE entity.source_table AP_INVOICES_ALL -- 来源表 AND entity.source_id_int 1234567; -- 来源ID发票ID关联逻辑是XLA_TRANSACTION_ENTITIES.SOURCE_ID_INT存的是来源表的主键 ID例如AP_INVOICES_ALL.INVOICE_IDENTITY_ID把实体和会计事件头串起来AE_HEADER_ID再串到行。做了一次这张查询你就理解为什么 R12 里不推荐直接看 GL 了——XLA 层保留了完整的业务事件上下文从发票到凭证的所有过程可以全程追踪。后来我从 11i 迁移项目里学到的教训是直接查GL_JE_LINES也能查到 R12 的凭证但DESCRIPTION字段往往是从 XLA 复制过来的信息已经被截断只有 XLA 表里有完整的来源说明。4.3 库存事务到成本凭证MTL_TRANSACTION_ID 的追踪路库存模块过账到总账在 R12 里也走 XLA但关联方式和 AP 不太一样。库存事务MTL_MATERIAL_TRANSACTIONS.TRANSACTION_ID会直接作为XLA_TRANSACTION_ENTITIES.SOURCE_ID_INT出现所以追踪一次出库怎么变成成本凭证按下面这条路走SELECT mtr.transaction_id, mtr.transaction_date, mtr.transaction_type_name, mtr.transaction_quantity, ae_header.gl_transfer_status, ae_line.code_combination_id, ae_line.accounted_dr, ae_line.accounted_cr FROM mtl_material_transactions mtr JOIN xla_transaction_entities entity ON mtr.transaction_id entity.source_id_int AND entity.source_table MTL_MATERIAL_TRANSACTIONS JOIN xla_ae_headers ae_header ON entity.entity_id ae_header.entity_id JOIN xla_ae_lines ae_line ON ae_header.ae_header_id ae_line.ae_header_id;如果查出来的GL_TRANSFER_STATUS是N说明库存事务还没过账这时候凭证侧肯定查不到先排查过账请求是否跑完。ACCOUNTED_DR/ACCOUNTED_CR才是成本金额ENTERED_DR/ENTERED_CR在这个场景下通常是零因为库存事务本身没有原币概念。这条链路在做成本分析时特别常用——把出货事务、成本科目、凭证状态一次串出来省掉来回切模块的时间。5. 避坑R12 表结构查询里最常见的五个翻车现场多年做 EBS 数据开发我攒下来的大部分经验都是从“查不到数据”里长出来的。下面这五个场景出现频率最高每条都是按现象、原因、解决三个层次来还原现场。5.1 有表无数据ORG_ID 过滤与 MOAC 初始化现象在 TOAD 里直连数据库查AP_INVOICES_ALL返回空但 EBS 界面里明明有几十条发票或者同一张表在公司 A 的数据能看到切到公司 B 就少了半年的记录。原因R12 的多组织控制表结构没有变但直连数据库时没人替你做 MOAC 初始化查询不受 OU 过滤反而查到了全库数据或者因为ORG_ID为空被业务视图自动过滤掉。解决先执行上文的FND_GLOBAL.APPS_INITIALIZE和MO_GLOBAL.SET_POLICY_CONTEXT再执行业务查询如果只查一张带_ALL后缀的表还可以手动加WHERE org_id 具体OU_ID但跨模块查询时务必做完整初始化半初始化比不初始化还坑。5.2 CODE_COMBINATION_ID 是一串数字科目却看不到现象查出发票分配行的CODE_COMBINATION_ID 12345678没法向业务解释这个科目是什么直接写到报表里对方看不懂。原因R12 的科目结构在GL_CODE_COMBINATIONS里被拆成了多个段SEGMENT1公司、SEGMENT2部门、SEGMENT3科目等而不是一个直接的描述字段。解决每次需要科目文本时关联GL_CODE_COMBINATIONS并把段拼接起来SELECT gcc.code_combination_id, gcc.segment1 || - || gcc.segment2 || - || gcc.segment3 AS account_text FROM gl_code_combinations gcc WHERE gcc.code_combination_id 12345678;SEGMENT的个数不是固定的不同公司实施时段的含义不同。做报表前先查FND_ID_FLEX_STRUCTURES和FND_ID_FLEX_SEGMENTS确认该账本的段结构再去拼ACCOUNT_TEXT。直接拼写死三段换一个实施环境就会错位。5.3 中文注释查不到数据字典用错了现象在ALL_TAB_COLUMNS里按中文关键词搜字段返回空结果但界面上明明有“供应商名称”这个字段。原因R12 应用表的字段业务注释不是放在 Oracle 数据字典里而是放在 EBS 应用字典FND_COLUMNS里ALL_TAB_COLUMNS的COMMENTS列大部分都是空的。解决用FND_COLUMNS搜索或把两条字典结果合起来看。我一般会先跑一次数据字典采集脚本把ALL_TAB_COLUMNS、FND_TABLES、FND_COLUMNS共同字段汇总到一张本地表里之后搜注释一次查全不来回切工具。5.4 同名视图和表混淆多组织的“表/视图”双轨现象查AR_TRX_ALL能查出一部分数据换成某个标准报表查同一时间段数据对不上或者在某张视图里写UPDATE报错。原因R12 里有大量以_ALL结尾的视图它们底层是安全策略控制的逻辑视图并不是真正的堆表物理表在APPSSchema 下也确实存在但 MOAC 用的业务视图会按 OU 过滤直连物理表则可能看到全部 OU 或一个空壳。解决先确认你连的是基表还是视图。用如下语句查看对象类型SELECT owner, object_name, object_type FROM all_objects WHERE object_name AR_TRX_ALL;如果结果是VIEW业务报表尽量走视图不要自己拼物理表重复实现 OU 过滤逻辑。对视图做UPDATE常常报“数据修改操作未通过安全策略”之类的错这是正常保护机制不是权限被裁剪。5.5 日期字段看着没错一跑就是乱码/错位现象查INVOICE_DATE用WHERE invoice_date 2025-05-01一条都查不出来或者从接口收到的日期字符串01-MAY-25转成日期类型时报格式错误。原因R12 的日期字段是标准DATE类型NLS 会话参数决定了字符串比较的格式TOAD 里默认 TO_DATE 格式和 EBS 数据库会话可能不一致。解决统一使用TO_DATE显式转换并带全格式串WHERE invoice_date TO_DATE(2025-05-01,YYYY-MM-DD) AND invoice_date TO_DATE(2025-05-02,YYYY-MM-DD);日期区间右边界用开区间避免漏掉当天 23:59:59 的数据。还有个额外经验R12 的取消日期CANCELLATION_DATE通常不是NULL而是 0001 年的底值查询时要么加NVL要么加IS NULL判断不处理就会把已取消单据也算进来。6. 进阶技巧把 R12 表结构变成你自己的速查知识库走到这一步你已经不是“遇到表查字典”的阶段了而是可以建立一个“从业务问题到关键表”的速查知识库。这个知识库不用工具就用 SQL 定期采集元数据然后按业务模块归档。我自己的习惯是维护一张R12_TABLE_QUICK_REF表字段就四列业务场景、主表名、关键字段、查询要点。-- 采集常用表和字段的基础元数据按模块过滤 SELECT tc.table_name, tc.column_name, tc.data_type, tc.data_length, cc.comments -- 应用层字段注释 FROM all_tab_columns tc LEFT JOIN fnd_columns fc ON tc.table_name fc.table_name AND tc.column_name fc.column_name LEFT JOIN fnd_columns_tl cc ON fc.column_id cc.column_id WHERE tc.owner APPS AND tc.table_name IN ( AP_INVOICES_ALL, AP_INVOICE_DISTRIBUTIONS_ALL, PO_HEADERS_ALL, GL_JE_HEADERS, GL_JE_LINES, MTL_SYSTEM_ITEMS_B, XLA_AE_HEADERS, XLA_AE_LINES ) ORDER BY tc.table_name, tc.column_id;这段 SQL 的价值不在于功能多高级而在于它把物理字段和应用注释一次性对齐。每个月跑一次把结果导成表或文本文件存档形成你自己的表结构快照。当月底出现“上周还能查、今天查不了”的问题时对比快照就能很快发现是不是有人改了字段或者视图被重新编译过。另外一个实用习惯从业务需求倒推表而不是从表倒推需求。接到“查应付账款余额”先想清楚余额的定义是“已过账未付款”然后走AP_INVOICES_ALL过滤PAYMENT_STATUS_FLAG和POSTED_DATE而不是把 AP 相关表全部拉出来一个个看。这个方法能帮你把几十张相关表压缩到两三条链路上。我做过的大大小小的项目大多数翻车不是 SQL 写得不对而是表选错了。现在每次做新报表我都先花十分钟把表结构链路画清楚——主表、关联字段、OU 过滤条件、日期口径确认无误再动手这个习惯省下的返工时间足够让我多写好几个报表。希望这篇 R12 表结构的拆解能帮你少踩几个我以前踩过的坑也祝你第一次查表就能命中。本文还有配套的精品资源点击获取