简介《Oracle EBS R12表结构》是一份面向EBS实施、开发与运维人员的专题参考系统整理R12版本数据库表结构帮助读者透过数据模型理解各业务模块之间的关联方式。压缩包共114个文件以58个PDF说明文档和56个HTML页面相配合整体6.01MBPDF可通读框架HTML适合按模块快速定位查询。该资料已有1598人学习下载。内容沿财务、供应链、人力资源、项目、销售服务等主线展开涉及总账、应付、应收、资产、采购、库存、订单等核心表的用途与字段要点同时结合数据字典、二次开发、权限控制及数据迁移等实践角度给出解析便于日常维护时排查问题也能为定制报表、接口开发或系统升级提供结构层面的支持。对于希望系统掌握EBS数据架构的初学者和有经验的技术人员而言是一份能直接对照查用的实用参考。1. Oracle EBS R12 表结构用一张采购发票把多组织模型串起来好几年前第一次在 Oracle EBS R12 环境做报表抽取业务方把“采购入库、应付发票、总账分录串成一条链路”的需求丢到我桌上。我抱着 AP_INVOICES_ALL、RCV_TRANSACTIONS、GL_DAILY_BALANCES 这些表来回 JOIN卡了快两天最后发现真正挡住我的不是 SQL 写法而是 EBS R12 表结构里那套组织隔离逻辑_ALL 后缀怎么读、ORG_ID 该不该过滤、账套 LEDGER_ID 和 COA 的关系在哪张表里。这份表结构资料讲的就是这套规则与核心基表清单能解决三件事看到表名就能判断它是主数据、事务还是接口表知道 OU、SOB、COA 三者的绑定关系拿到一个单据号能从业务表一路追到总账。适合做 EBS 报表、数据抽取、迁移集成的从业者也适合刚从纯数据仓库转过来、还没摸清 EBS 表命名规律的同事。2. 表名后缀先读懂_ALL、_B/_TL、_INTERFACE 在 R12 里是什么分工2.1 后缀规则与三类基表看到表名能先分类EBS R12 有几千张表但规律性很强。我拿到一个表名的第一反应不是打开 PL/SQL Developer 去查数据而是先看后缀后缀决定了这张表是不是带组织隔离、是不是多语言表、是不是给导入程序用的。_ALL 结尾的表是多组织Multi-Org安全表最典型的是 AP_INVOICES_ALL、PO_HEADERS_ALL、RA_CUSTOMER_TRX_ALL。它存的是所有 OUOperating Unit的数据区分不同业务实体靠 ORG_ID 字段。不带 _ALL 的同名对象比如 AP_INVOICES是基于 _ALL 表建的视图通常会按当前会话的 OU 过滤数据。EBS 表单界面上查到的数据来自这种单 OU 视图而跨 OU 做报表时必须查 _ALL 表这是一个很容易被忽略的分水岭。后缀示例用途_ALLAP_INVOICES_ALL多 OU 数据表带 ORG_ID 字段_B / _TLAP_TERMS_B / AP_TERMS_TL多语言表_B 存基础列_TL 存翻译列_VLAP_TERMS_VL把 _B 与 _TL JOIN 起来的语言视图_INTERFACEAP_INVOICES_INTERFACE标准接口表供导入程序读取无后缀视图AP_INVOICES单 OU 视图界面默认访问对象_S / _TMP少量序列视图、临时表一般不用来取数然后是三类基表的划分。第一类是主数据表存物料、供应商、会计科目这类静态数据典型的是 MTL_SYSTEM_ITEMS_B、AP_SUPPLIERS、GL_CODE_COMBINATIONS。这类表通常以 _ID 字段做主键变动频率低但也最容易被当成事务表过度 JOIN。第二类是事务头表表名里带 HEADERS 或 TRXPO_HEADERS_ALL、AP_INVOICES_ALL、RA_CUSTOMER_TRX_ALL 都属于这一类。第三类是事务行与分配表表名带 LINES、DISTRIBUTIONS例如 PO_LINES_ALL、PO_DISTRIBUTIONS_ALL、AP_INVOICE_LINES_ALL、AP_INVOICE_DISTRIBUTIONS_ALL。判断技巧很简单先看后缀判断隔离方式再看表名第二段判断主数据、头、行还是分配。遇到 RCV_TRANSACTIONS 这类没有 HEADER 也没有 LINE 的事务表就往“事务明细”方向归类。这套规则适合大部分标准表少数例外比如 GL_JE_HEADERS 不带 _ALL因为它按 LEDGER_ID 隔离而不是 ORG_ID后面第 3 章会专门讲。遇到带 _B 和 _TL 的表查询时把两张表 JOIN_B 提供主数据和 ID_TL 提供当前语言描述列。比如要取付款条款名称查 AP_TERMS_VL 视图最省事如果视图不存在就手动 JOIN AP_TERMS_B 与 AP_TERMS_TL关联条件除了 term_id 相等还要加 AP_TERMS_TL.language USERENV(LANG)。这里一定要注意_TL 表按语言拆行漏掉 language 条件后一条主数据会翻出多语言行描述字段会重复金额不会翻倍但结果集会让人误以为主数据本身重复。2.2 用数据字典拉出表结构一条 SQL 生成建表说明书知道了表名下一步是看字段。EBS 环境里不一定要装 data model 文档Oracle 数据字典本身就是最靠谱的表结构说明书。我常用下面这条 SQL一次把字段、类型、长度、可空性和注释全列出来SELECT tc.table_name, tc.comments AS table_comment, cc.column_id, cc.column_name, cc.data_type, cc.data_length, cc.nullable, ccc.comments AS column_comment FROM all_tab_comments tc LEFT JOIN all_tab_columns cc ON cc.owner tc.owner AND cc.table_name tc.table_name LEFT JOIN all_col_comments ccc ON ccc.owner tc.owner AND ccc.table_name tc.table_name AND ccc.column_name cc.column_name WHERE tc.owner APPS AND tc.table_name AP_INVOICES_ALL ORDER BY cc.column_id;逻辑说明all_tab_comments 存表级注释all_tab_columns 存字段元数据all_col_comments 存字段注释三张字典表通过 owner、table_name、column_name 关联。owner 固定写 APPS因为 EBS 的应用对象都挂在 APPS Schema 下table_name 必须大写Oracle 存储对象名默认大写。参数说明把 table_name 换成任何你关心的表比如 MTL_SYSTEM_ITEMS_B就能看到物料主数据的全部字段。如果只想确认某一个字段存在于哪些表里把 WHERE 条件改成 column_name ORG_IDtable_name 用 LIKE 限定前缀就能快速判断哪些模块受 OU 隔离。注意owner、table_name 都要用大写。Oracle 数据字典对大小写敏感拼小写会查不到。有人习惯用 DESC ap_invoices_all 看字段但 DESC 看不到注释也看不到表级业务说明字段一多就分不清哪个是哪个。数据字典 JOIN 的好处是注释、类型、长度、可空性一屏显示还能按 column_id 排序。对着一张 300 多字段的大表注释就是救命的索引。这个查询是我做表结构速查字典的基础。第一次拿到新环境时我会把这张查询的结果固化成一个视图第 5 章会给出可直接创建的版本。另外补一个模糊找表的习惯EBS 里同一个业务概念可能出现在多个模块SELECT table_name, comments FROM all_tab_comments WHERE owner APPS AND table_name LIKE AP\_INV% ESCAPE \ AND comments IS NOT NULL ORDER BY table_name;逻辑说明LIKE 后面用了反斜杠转义把下划线当作普通字符匹配避免IN 统配掉字符串ESCAPE 告诉 Oracle 反斜杠是转义符。参数说明前缀改成 PO、MTL_、RA_、XLA_就能按模块扫出所有相关表。看 comments 字段能快速辨识业务含义。3. 核心表关系从 OU、SOB、COA 到 PO-AP-GL 的跨模块链路3.1 三张组织主表OU 如何绑定 SOB 与 COAEBS R12 的表结构难点不在单张表而在组织模型。R12 把多组织架构做成了一组独立表搞懂它们看 _ALL 表时才清楚 ORG_ID 背后到底代表什么。第一张是 HR_ALL_ORGANIZATION_UNITS它把 OU、库存组织、HR 部门等所有组织实体统一存起来字段 ORGANIZATION_ID、NAME、TYPE 是定位组织的入口。第二张是 HR_OPERATING_UNITS 视图专门过滤出 OU 类型适合业务上“列出所有 OU”的查询。第三张是 ORG_ORGANIZATION_DEFINITIONS它负责把 OU 与账套绑定里面 SET_OF_BOOKS_ID 指向 GL_LEDGERS 的 LEDGER_IDCHART_OF_ACCOUNTS_ID 指向科目表结构。R12 的账套主表是 GL_LEDGERS它替代了早期 EBS 版本的 GL_SETS_OF_BOOKS。有些老资料还教人查 GL_SETS_OF_BOOKS但我在某个 12.2 环境里碰到过兼容视图数据为空的情况。所以查账套信息我统一走 GL_LEDGERS。用一条 SQL 把 OU、账套、币种、科目表串起来SELECT hou.organization_id AS ou_id, hou.name AS ou_name, ood.set_of_books_id, gl.name AS ledger_name, gl.currency_code, gl.chart_of_accounts_id FROM hr_operating_units hou LEFT JOIN org_organization_definitions ood ON ood.organization_id hou.organization_id LEFT JOIN gl_ledgers gl ON gl.ledger_id ood.set_of_books_id ORDER BY hou.organization_id;逻辑说明HR_OPERATING_UNITS 先过滤出 OUORG_ORGANIZATION_DEFINITIONS 通过 organization_id 补上账套 IDGL_LEDGERS 再补账套名称、币种和科目表。LEFT JOIN 是为了把没有任何账套绑定的 OU 也显示出来避免排查 OU 配置问题时漏行。参数说明如果只要某一个 OU在最后加 WHERE hou.organization_id :ou_id如果只想找主账套可以再加条件 gl.ledger_category_code PRIMARY。这个字段在 GL_LEDGERS 里用来区分主账套与二级分类账交叉验证时经常要用到。提示R12.2 在线环境里优先用 GL_LEDGERS不要依赖 GL_SETS_OF_BOOKS 兼容数据。另外GL_CODE_COMBINATIONS 是科目组合表CODE_COMBINATION_ID 是它的主键。几乎所有模块的分配表都会引用 CODE_COMBINATION_ID再通过它带出 BALANCE_SEGMENT 等段值。这张表也是跨模块对账的公共枢纽。3.2 跨模块串表从采购单一路追到总账分录表结构资料最终要落到业务链路上。我拿最常见的“采购入库 → 应付发票 → 总账”举例。这条链路涉及四组表PO_、RCV_、AP_、XLA_。先看入口PO_HEADERS_ALL 与 PO_LINES_ALL 分别存采购单头和行PO_DISTRIBUTIONS_ALL 把采购行分配到费用或库存账户它同时带 PO_HEADER_ID、PO_LINE_ID 和 CODE_COMBINATION_ID是 PO 与总账的第一个桥。收货在 RCV_TRANSACTIONS。这张事务表记录接收、入库、退货等动作有 PO_HEADER_ID、PO_LINE_ID、TRANSACTION_TYPE、TRANSACTION_DATE。它和 PO 的关联用采购单和行两个维度注意同一次收货可能拆出多行事务。应付发票的入口是 AP_INVOICES_ALL头表AP_INVOICE_DISTRIBUTIONS_ALL 是分配行表里面关键字段是 PO_DISTRIBUTION_ID 和 CODE_COMBINATION_ID负责把发票费用关联到采购分配与科目。从这个字段 JOIN PO_DISTRIBUTIONS_ALL就能实现“发票号 → 采购单号”的反查SELECT aia.invoice_id, aia.invoice_num, aid.po_distribution_id, pod.po_header_id, poh.segment1 AS po_number, aid.amount FROM ap_invoices_all aia JOIN ap_invoice_distributions_all aid ON aid.invoice_id aia.invoice_id JOIN po_distributions_all pod ON pod.po_distribution_id aid.po_distribution_id JOIN po_headers_all poh ON poh.po_header_id pod.po_header_id WHERE aia.invoice_num INV-2024-001;逻辑说明AP_INVOICE_DISTRIBUTIONS_ALL 是发票分配表存了 PO_DISTRIBUTION_ID所以能从发票反查采购分配再回到采购单头。这里没有直接 JOIN AP_INVOICE_LINES_ALL因为一张发票行的分配可能跨多个采购行分配表更适合做金额对账。参数说明invoice_num 换成你要追踪的发票编号如果要做批量抽取把它改成日期过滤 aia.invoice_date BETWEEN ... AND ... 更高效。不建议用 AP_INVOICES_ALL 的 PO_NUMBER 字段直接关联 PO_HEADERS_ALL那是文本字段录入不规范会造成大量漏配。发票最终进总账走的是 XLASubledger Accounting。XLA_TRANSACTION_ENTITIES 记录业务单据对应的“事件实体”XLA_AE_HEADERS 是分录头XLA_AE_LINES 是分录行。下面这条 SQL 是所有对账场景里复用率最高的SELECT xte.source_table, xte.source_id_int_1, xah.event_id, xah.ledger_id, xal.code_combination_id, xal.accounted_dr, xal.accounted_cr FROM xla_transaction_entities xte JOIN xla_ae_headers xah ON xah.entity_id xte.entity_id JOIN xla_ae_lines xal ON xal.ae_header_id xah.ae_header_id WHERE xte.source_table AP_INVOICES_ALL AND xte.source_id_int_1 :invoice_id;逻辑说明XLA_TRANSACTION_ENTITIES 的 SOURCE_TABLE 存来源表名SOURCE_ID_INT_1 存来源表主键 IDAP 发票 ID 对应 AP_INVOICES_ALL.INVOICE_ID。JOIN XLA_AE_HEADERS 后拿到 EVENT_ID 与 LEDGER_ID再 JOIN XLA_AE_LINES 拿到账户组合与借贷金额。参数说明把 AP_INVOICES_ALL 换成 AR_CASH_RECEIPTS_ALL、RA_CUSTOMER_TRX_ALL 等来源表把 :invoice_id 换成对应主键这条 SQL 就能通用于几乎所有子模块到总账的追溯。用 XLA 做追溯比直接查 GL_JE_LINES 稳因为 GL 接口导入和 XLA 分配两条路径都存在XLA 才是 R12 的标准分录来源。很多做报表的人会纠结到底从 GL_DAILY_BALANCES 取数还是从 XLA 取数。我一般的原则是余额型报表用 GL_DAILY_BALANCES按 EFF_DATE 与 PERIOD_NAME 过滤流水型对账用 XLA_AE_LINES因为它有明确的 EVENT_ID 和 LINE_NUMBER能追溯回业务单据。两套口径对不上时优先怀疑期间开关未开、重运行了总账导入、或者 XLA 里存在未过账事件。顺手给出一张常用模块基表清单方便建立全局印象模块头表行/分配表备注INVMTL_SYSTEM_ITEMS_BMTL_ONHAND_QUANTITIES、MTL_MATERIAL_TRANSACTIONS物料主数据、现有量、库存事务POPO_HEADERS_ALLPO_LINES_ALL、PO_DISTRIBUTIONS_ALL采购头行与分配APAP_INVOICES_ALLAP_INVOICE_LINES_ALL、AP_INVOICE_DISTRIBUTIONS_ALL供应商主数据在 AP_SUPPLIERSARRA_CUSTOMER_TRX_ALLRA_CUSTOMER_TRX_LINES_ALL、RA_CUST_TRX_LINE_GL_DIST_ALL应收事务与分配GLGL_LEDGERSGL_CODE_COMBINATIONS、GL_DAILY_BALANCES账套与科目组合XLAXLA_TRANSACTION_ENTITIESXLA_AE_HEADERS、XLA_AE_LINES子分类账标准分录表名不要死记把第 2 章的命名规则套上去头表、行表、分配表一眼就能分出来。4. 表结构查询与对账避坑五个真实翻车场景与解法4.1 直接查单 OU 视图导致数据“莫名”变少现象拿到别人写的报表SQL 里用的是 AP_INVOICES跨 OU 汇总时发现发票总数比应付模块的总数少但分 OU 看又不缺。原因AP_INVOICES 是基于 AP_INVOICES_ALL 建的视图自动带了当前会话 OU 过滤。在 PL/SQL Developer 里直接查会话没有预设 OU视图有时只返回其中一个 OU 的数据有时返回空表现很随机。解决报表统一查 _ALL 表手动用 ORG_ID 过滤。跨 OU 汇总不加 ORG_ID分 OU 汇总用 HR_OPERATING_UNITS 列表驱动过滤。我在新环境接需求时会先跑一遍第 3 章的 OU 清单把 OU 与 ORG_ID 印在脑里避免被界面视图“帮忙”过滤掉不知道。4.2 金额对不上原始币种与 XLA 本位币要分清现象做应付发票与总账对账发现 AP_INVOICES_ALL 里发票金额合计和 GL 余额差了汇率折算的部分。两张表明明同一个 OU、同一期间怎么都平不上。原因AP 发票头表里 INVOICE_CURRENCY_CODE 存的是发票原始币种AMOUNT 字段在跨币种时不是本位币。而 XLA_AE_LINES 的 ACCOUNTED_DR 与 ACCOUNTED_CR 是按账套本位币入账的。直接拿发票金额与总账金额比较遇到 USD 发票入 CNY 账套的案例就会翻车。解决涉及金额对账一律以 XLA_AE_LINES 的 ACCOUNTED_DR / ACCOUNTED_CR 为准不要拿 AP 头表或分配行的原始金额做最终对比。要展示原始币种时用 INVOICE_CURRENCY_CODE 与汇率字段换算并确认 FND_CURRENCY 里的精度设置。另一条习惯两个金额口径做差时先看币种是否一致再看是“含税价”还是“不含税价”AP 的税额在头表 TAX_AMOUNT 字段分配行金额往往不含税。提示金额对账先统一币种再统一税额口径否则差异分析会耗掉半天时间。4.3 日期显示 16-APR-24NLS 格式与日期字段类型现象查询 RCV_TRANSACTIONS 时TRANSACTION_DATE 显示成 16-APR-24放进 Excel 后月份和年份被拆错按月份汇总时数据错位。原因EBS 标准日期字段大部分是 DATE 类型显示格式由客户端 NLS_DATE_FORMAT 决定。16-APR-24 是会话默认的显示文本不是数据本身的问题。另外少数接口表把日期存成 CHAR 或 NUMBER比如 20240416 格式TO_DATE 时格式字符串没对上也会报错或解出错误日期。解决查询语句里统一显式格式化SELECT TO_CHAR(TRANSACTION_DATE, YYYY-MM-DD)日期过滤用 TO_DATE(:date_str, YYYY-MM-DD)别用 LIKE 去匹配日期文本。遇到看起来像日期但不是 DATE 类型的字段先查 ALL_TAB_COLUMNS 的 DATA_TYPE再决定是否要字符串截断转换。4.4 按字段名猜外键JOIN 出来全是重复数据现象想查供应商名称看到 AP_INVOICES_ALL 里有 VENDOR_ID直接 JOIN PO_VENDORS结果一条发票带出多条供应商记录聚合后金额膨胀。原因EBS 的供应商主数据在 R12 里统一放在 AP_SUPPLIERSPO_VENDORS 是早期模块或兼容视图的一部分字段关联关系不能靠名称猜。更常见的是EBS 很多表之间没建物理外键外键关系维护在表结构文档和 ERD 里靠字段名“看上去像”去 JOIN 最容易翻车。解决先查 ALL_CONSTRAINTS 确认主外键查询写法如下SELECT c.constraint_name, c.constraint_type, cc.column_name FROM all_constraints c JOIN all_cons_columns cc ON cc.owner c.owner AND cc.constraint_name c.constraint_name WHERE c.table_name AP_INVOICES_ALL AND c.constraint_type IN (R, P) ORDER BY c.constraint_type, cc.position;逻辑说明constraint_type 为 R 表示外键P 表示主键这个查询能列出 AP_INVOICES_ALL 的真实外键关系比翻文档快。参数说明把表名换成任何怀疑 JOIN 关系的表。如果 ALL_CONSTRAINTS 查不到外键EBS 里很常见就用 DBA_VIEWS 查视图定义文本里对底表的引用或者拿第 2 章的字典查询按字段名反查所有表。关系确认后再写 JOIN能省下大量对数据的时间。4.5 版本差异R12.1 和 R12.2 的账套表完全不一样现象网上找的表结构文档写的是 GL_SETS_OF_BOOKS照着查 12.2 环境账套数据为空。换回 GL_LEDGERS 才查出数据。原因R12 引入 GL_LEDGERS 作为主账套表GL_SETS_OF_BOOKS 属于兼容层。某些 12.2 环境里兼容数据没有同步维护老文档直接套上去就空了。类似的情况还出现在供应商表早期资料写 PO_VENDORSR12 主表是 AP_SUPPLIERS和部分 HR 组织表上。解决新环境动手前先确认版本。登录页能看到应用 Release 号数据库版本用 SQL*Plus 查 v$version遇到文档与现场不一致以 ALL_TAB_COLUMNS 实际字段为准。我一般会把第 2 章的字典查询跑一遍目标表如果字段和文档对不上就按数据字典重写 SQL不再纠结资料出处。毕竟表结构资料是索引数据字典才是现场真相。5. 把表结构反向工程成速查字典一个视图加两个验证技巧5.1 用数据字典视图把几百张表变成一份速查清单与其每次敲第 2 章的查询不如直接建一个视图。下面这段 SQL 我在多个环境里用过建在 APPS 下名字可以自己改注意别和标准对象冲突CREATE OR REPLACE VIEW xx_apps_table_dict AS SELECT tc.owner, tc.table_name, tc.comments AS table_comment, cc.column_id, cc.column_name, cc.data_type || ( || cc.data_length || ) AS data_type, cc.nullable, ccc.comments AS column_comment FROM all_tab_comments tc LEFT JOIN all_tab_columns cc ON cc.owner tc.owner AND cc.table_name tc.table_name LEFT JOIN all_col_comments ccc ON ccc.owner tc.owner AND ccc.table_name tc.table_name AND ccc.column_name cc.column_name WHERE tc.owner APPS AND tc.table_name NOT LIKE SYS% AND tc.table_name NOT LIKE X%DBMS%;参数说明视图名用自定义前缀避免覆盖标准对象WHERE 条件排除了系统表。建好后一条 SELECT * FROM xx_apps_table_dict WHERE table_name AP_INVOICES_ALL 就能当表结构文档用。想找“哪些表有 ORG_ID”时执行 SELECT table_name FROM xx_apps_table_dict WHERE column_nameORG_ID GROUP BY table_name几秒就能扫完整个 APPS Schema。5.2 让线索倒过来从界面表单反查基表字段第二个技巧是反向验证。EBS 表单界面里按 Help 菜单打开 About Oracle Applications在 Release 输入框里输入开启诊断的关键字然后从 Help Diagnostics Examine 进入。点击界面任意字段Examine 窗口会显示当前 Form 的 Block、Field以及它对应的 Table 和 Column。这个功能用来确认“界面上这个字段到底存到哪张表哪个列”比去数据字典猜快得多。第三个技巧是数据链路验证。我在跟踪一条采购发票进总账时会先在 AP 模块录一张测试发票只录一行金额做完整结算和过账然后用第 3 章的 XLA 查询反查。由于测试数据金额唯一即使链路某一步 JOIN 错了数字差异会非常明显。这个“标黄测试数据”的习惯帮我抓出过不少因为视图缓存和接口表残留数据导致的追数错误。从那以后我每次拿到新的表结构需求都强制自己先跑一遍 xx_apps_table_dict再看一眼表单 Examine最后用一条最小测试单据验证链路少走一半冤枉路。希望帮到你。本文还有配套的精品资源点击获取