简介一套针对Oracle ERP R12系统的表结构参考文档面向ERP实施顾问、开发人员及数据库运维者用于快速定位业务模块对应的后台表及字段关系。资源共112个文件其中58个PDF提供各模块表结构的完整说明与关联梳理54个HTML按模块独立组织便于在浏览器中对照查阅压缩包整体仅3.42MB轻量易取。内容覆盖AR应收、INV库存、SQLAP应付、SQLGL总账、XLA子分类账、OFA固定资产、CE现金管理、OE订单录入等核心模块也包含GMD、ZX等扩展主题基本囊括R12常用业务领域的表结构要点。目前已有390人学习适合在开发排错、接口设计或二次开发时作为速查手册。借助模块化目录可快速比较同类单据的主子表及关联外键提升对Oracle ERP R12数据模型的整体认知。1. Oracle ERP R12表结构实施顾问的查表地图接到某制造业客户的需求说应付模块月末核销对不上账。我翻出 AP_INVOICES_ALL、AP_PAYMENT_SCHEDULES_ALL、AP_INVOICE_PAYMENTS_ALL 三张表关联字段挨个试折腾了一个下午才发现漏了付款计划状态。这类问题对 EBS 开发来说不陌生——oracle erp r12表结构 的熟悉程度直接决定排查效率。这份资源把 GL、AP、AR、PO、INV、OE 六大核心模块的关键表、字段含义和表间关联整理成了可检索的参考手册实施顾问、二次开发、数据迁移人员都能照着查不用再对着几百张表瞎猜。2. 表结构总览模块前缀、表分类与核心表族清单EBS R12 的表名看起来随机实际有一套机械的命名规则。掌握这套规则面对一个新需求时能在一分钟内圈定候选表范围。2.1 模块前缀与表分类一眼判断表的业务归属R12 表名的前三位字符通常是模块前缀这是最直接的定位线索。GL_ 开头的表属于总账AP_ 开头的表属于应付AR_ 开头的表属于应收PO_ 开头的是采购RCV_ 开头的是接收MTL_ 开头的是库存事务SO_ 和 OE_ 开头的是订单销售。再加上 FND_ 开头的基础数据表比如 FND_LOOKUP_VALUES 存放所有下拉列表值FND_FLEX_VALUES 存放弹性域值。后缀规则同样关键。_ALL 结尾的表是多组织基表存储所有 OU经营单位的数据比如 AP_INVOICES_ALL 存所有 OU 的发票。_B 结尾是基表_T 是翻译表_VL 和 _V 是视图。开发时优先查视图更安全但视图底层往往关联多张表性能敏感的场景还是直接查 _ALL 基表更可控。_INTERFACE 和 _STAGING 结尾是接口表数据导入流程中临时存放待处理数据。想快速摸清某个模块有哪些表直接查数据字典。以下 SQL 列出所有 AP 前缀的表SELECT table_name, num_rows, last_analyzed FROM all_tables WHERE table_name LIKE AP\_% ESCAPE \ ORDER BY table_name;逻辑说明LIKE AP\_%配合ESCAPE \把下划线当作普通字符匹配避免_被通配符吃掉这是查表名时最容易写错的地方。num_rows是统计信息里的估算行数不是实时值last_analyzed如果为 NULL说明这张表从没收集过统计信息后面查询执行计划可能偏掉。提示多组织相关的基础数据表不一定带 _ALL比如 MTL_SYSTEM_ITEMS_B 就是物料主数据基表要靠 ORGANIZATION_ID 字段区分组织。2.2 核心表族清单从业务模块到具体表名下面这张表是从实施和开发角度整理的核心表族覆盖最常见的查数场景模块头表行/明细表关联/接口表总账 GLGL_JE_HEADERS 凭证头GL_JE_LINES 凭证行GL_IMPORT_REFERENCES 导入来源应付 APAP_INVOICES_ALL 发票头AP_INVOICE_DISTRIBUTIONS_ALL 分配行AP_PAYMENT_SCHEDULES_ALL 付款计划应收 ARAR_TRANSACTION_ALL 事务头AR_TRANSACTION_LINES_ALL 事务行AR_RECEIPT_APPLICATIONS_ALL 收款核销采购 POPO_HEADERS_ALL 采购单头PO_LINES_ALL 采购单行PO_DISTRIBUTIONS_ALL 分配行库存 INVMTL_SYSTEM_ITEMS_B 物料主数据MTL_ONHAND_QUANTITIES 现有量MTL_TRANSACTION_ACTIONS 事务类型订单 OESO_HEADERS_ALL 订单头SO_LINES_ALL 订单行OE_ORDER_HEADERS_ALL 查询视图查某张表有哪些字段用下面这条 SQL支持任意表名SELECT column_name, data_type, data_length, nullable FROM all_tab_columns WHERE table_name UPPER(tbl) ORDER BY column_id;逻辑说明tbl是 SQL*Plus 的替换变量交互式输入表名即可DATA_LENGTH是字段长度写定长字符字段时有用NULLABLE显示字段是否允许为空核对数据插入失败时先看这个。值得留意的是all_tab_columns只能看到当前数据库账号有权限的表如果查不到先确认账号的权限范围。3. 财务核心GL、AP、AR 三模块的表链与关键字段财务模块是 R12 里表关系最密集的区域。很多开发卡在“不知道从哪张表入手”本质是没有把业务事件到表链的映射关系理清。3.1 总账模块凭证、预算与科目组合的落表逻辑R12 里总账模块的核心变化是用 LEDGER_ID 取代了 11i 的 SET_OF_BOOKS_ID。凭证头存在 GL_JE_HEADERS凭证行存在 GL_JE_LINES行上的 CODE_COMBINATION_ID 指向科目组合。科目组合的段值明细则要进一步查 GL_CODE_COMBINATIONS 表不过在大多数报表场景里你只需要 CODE_COMBINATION_ID 做关联键不需要展开段值。实际排查时最常用的是查某个账套某段时间的凭证及其借贷金额SELECT gje.je_header_id, gjh.name AS je_name, gjh.status AS je_status, gjh.ledger_id, gje.line_num, gje.code_combination_id, gje.entered_dr, gje.entered_cr FROM gl_je_headers gjh JOIN gl_je_lines gje ON gje.je_header_id gjh.je_header_id WHERE gjh.ledger_id :ledger_id AND gjh.default_effective_date BETWEEN :start_date AND :end_date ORDER BY gje.je_header_id, gje.line_num;逻辑说明gjh.status的常见取值是 U未过账和 P已过账对账时一般只取 Pentered_dr和entered_cr是凭证输入币种的金额而accounted_dr和accounted_cr才是本位币金额。境外子公司场景下这两个字段经常被搞混。这段 SQL 能查出凭证本身但查不到凭证来源。真正从业务模块追溯总账要用 GL_IMPORT_REFERENCES 承接。它记录每一条凭证行是从哪个模块的哪张单据导入的字段 REFERENCE_SEC_NAME 存来源模块名比如 AP_INVOICESREFERENCE_SEC_NUM 存来源单据号。当 AP 发票和总账凭证对不上时这条链路是关键。3.2 应付与应收发票、付款与事务处理的核心表链应付模块的核心链路由四张表撑起AP_INVOICES_ALL 存发票头AP_INVOICE_DISTRIBUTIONS_ALL 存分配行发票金额如何分摊到科目AP_PAYMENT_SCHEDULES_ALL 存付款计划应付日期、到期日、状态AP_INVOICE_PAYMENTS_ALL 存实际的付款记录。付款状态是排查高频字段payment_status_flag常见的值包括 NONE无需付款、NEVER从未付款、PARTIALLY部分付款、PAID已付清。查供应商付款情况时最容易翻车的地方就是一票多付——一张发票被分两次付款后付款表里出现两行直接联表会导致发票金额翻倍。SELECT aia.invoice_num, aia.invoice_date, aia.invoice_amount, aps.payment_status_flag, aps.amount_due_remaining, COUNT(aip.invoice_payment_id) AS payment_cnt FROM ap_invoices_all aia LEFT JOIN ap_payment_schedules_all aps ON aps.invoice_id aia.invoice_id LEFT JOIN ap_invoice_payments_all aip ON aip.invoice_id aia.invoice_id WHERE aia.vendor_id :vendor_id GROUP BY aia.invoice_num, aia.invoice_date, aia.invoice_amount, aps.payment_status_flag, aps.amount_due_remaining;逻辑说明两张 LEFT JOIN 保证没有任何付款记录的发票也能查出来payment_cnt用 COUNT 统计付款次数一眼能看出哪些发票存在一票多付。amount_due_remaining是剩余应付金额核对“到底还欠多少钱”时以这个字段为准不要拿 invoice_amount 减 payment_amount 自己算——舍入规则不一致会对不上。应收侧的表结构与应付对称。AR_TRANSACTION_ALL 是事务头表发票、贷项通知单等AR_TRANSACTION_LINES_ALL 是事务行AR_CASH_RECEIPTS_ALL 存收款AR_RECEIPT_APPLICATIONS_ALL 存收款与发票的核销关系。业务上查“某客户还有多少应收未收”本质是 AR_TRANSACTION_ALL 与 AR_RECEIPT_APPLICATIONS_ALL 的差集计算。需要注意应收模块的老表名在 11i 叫 RA_CUSTOMER_TRX_ALL升级到 R12 后换成了 AR_TRANSACTION_ALL网上很多旧教程的表名已经过时。4. 供应链核心PO、INV、OE 的主数据与事务表链供应链模块的表链逻辑比财务更直观典型特征是“头表-行表-分配表”三层结构贯穿采购、库存、销售全流程。4.1 采购模块从请购到入库的主表链采购单据的完整链路是请购单PR→ 采购单PO→ 接收RCV→ 入库INV。请购单头表是 PO_REQ_HEADERS_ALL行表是 PO_REQ_LINES_ALL采购单头表是 PO_HEADERS_ALL行表是 PO_LINES_ALL接收事务记录在 RCV_TRANSACTIONS到货头在 RCV_SHIPMENT_HEADERS。很多人一上来就查 PO_LINES_ALL 找物料却不知道物料编码在 MTL_SYSTEM_ITEMS_B 里需要靠 ITEM_ID 字段关联。一条 SQL 串起采购单主链路SELECT poh.segment1 AS po_number, pol.line_num, pol.item_id, msib.segment1 AS item_code, pol.quantity, NVL(rt.transaction_type, NOT_RECEIVED) AS receive_status FROM po_headers_all poh JOIN po_lines_all pol ON pol.po_header_id poh.po_header_id LEFT JOIN rcv_transactions rt ON rt.po_line_id pol.po_line_id LEFT JOIN mtl_system_items_b msib ON msib.inventory_item_id pol.item_id AND msib.organization_id poh.org_id WHERE poh.segment1 :po_number;逻辑说明segment1是单据编号的可读字段PO 号、发票号、物料编码这类业务编号都放在 segment1而表内的主键是po_header_id、item_id这类 ID 字段两者不要混淆。LEFT JOIN rcv_transactions是为了查那些还没到货的采购单行NVL把它们显示为 NOT_RECEIVED。物料关联必须带上组织条件msib.organization_id poh.org_id这是多组织架构下最常见的漏写条件。从采购单到入库单的事务流转记录在 MTL_TRANSACTION_ACTIONS它的 TRANSACTION_TYPE_ID 对应库存事务类型比如采购订单接收、销售订单发货。报表上“本月收货金额”这类指标往往需要从 MTL_MATERIAL_TRANSACTIONS 里按事务类型聚合而不是直接查 PO 表。4.2 库存与销售物料主数据与订单履约的关联路径物料主数据存在 MTL_SYSTEM_ITEMS_B现有量存在 MTL_ONHAND_QUANTITIES。库存查询的常见场景是按物料编码查各仓库的可用量SELECT msib.segment1 AS item_code, moq.organization_id, moq.subinventory_code, moq.primary_quantity, moq.quantity_reserved FROM mtl_system_items_b msib JOIN mtl_onhand_quantities moq ON moq.inventory_item_id msib.inventory_item_id AND moq.organization_id msib.organization_id WHERE msib.segment1 :item_code AND moq.organization_id :org_id;逻辑说明primary_quantity是主单位下的现有库存数量quantity_reserved是预占数量真正的可用量是两者之差。MTL_ONHAND_QUANTITIES按物料组织子库存一行行存所以同一物料会返回多行每个子库存一行。做库存汇总报表时记得按组织 GROUP BY。销售侧的表链与采购对称SO_HEADERS_ALL 是订单头SO_LINES_ALL 是订单行。订单行的状态字段是 FLOW_STATUS_CODE值域由订单工作流定义常见的有 ENTERED、BOOKED、CLOSED 等。如果只是想快速查订单头和行用 OE_ORDER_HEADERS_ALL 和 OE_ORDER_LINES_ALL 视图更方便它们已经把多组织环境和部分状态逻辑处理好了。不过视图性能一般生产环境大批量查询还是建议直接查基表。5. 避坑排查直接查询 EBS R12 表的五个常见坑直接查 R12 表结构有一堆靠文档看不出来的坑。每一条都是实际翻车换来的教训按“现象 → 原因 → 解决”列出。5.1 不带 ORG_ID 条件查出所有 OU 的数据现象查询 AP_INVOICES_ALL 只查一家公司的发票结果返回了几十家公司的数据。 原因_ALL 结尾的基表存储所有经营单位的数据单 OU 查询必须显式过滤组织。 解决要么在 WHERE 条件里加org_id :org_id要么用多组织访问策略初始化会话BEGIN FND_GLOBAL.APPS_INITIALIZE(:user_id, :resp_id, :resp_appl_id); MO_GLOBAL.SET_POLICY(S); END;逻辑说明MO_GLOBAL.SET_POLICY(S)表示启用单组织访问模式之后查询 _ALL 表时系统会自动附加组织过滤条件。但这种方式依赖当前职责的 MOAC 配置写脚本时不如显式加org_id条件直观可控。5.2 一票多付导致行数翻倍现象发票头表关联付款表后SUM 出来的金额比发票总额大。 原因AP_INVOICES_ALL 与 AP_INVOICE_PAYMENTS_ALL 是一对多关系两张表直接 JOIN 后行数放大。 解决先确认两头表的粒度再决定聚合方式。查汇总金额时先 GROUP BY 发票再关联付款表。5.3 日期查询少了当天数据现象查某天数据总差几条把时间范围放宽一天就对了。 原因EBS 的 DATE 字段带时分秒用BETWEEN :start_date AND :end_date时end_date 传入的是当天 00:00:00当天晚些时候的数据被漏掉。 解决统一用TRUNC(gjh.default_effective_date) BETWEEN TRUNC(:start_date) AND TRUNC(:end_date)或者把结束日期加上 0.99999 的时分秒。5.4 失效物料和已结束供应商混入报表现象报表里出现大量 ENABLED_FLAG 为 N 的停用物料。 原因基础数据表的 ENABLED_FLAG 和 END_DATE 控制业务数据有效性查询时没过滤。 解决物料主数据查询加上msib.enabled_flag Y供应商查询加上aps.end_date IS NULL OR aps.end_date SYSDATE。这个条件看似多余但直接影响下游数据质量。5.5 NUM_ROWS 统计滞后导致执行计划走偏现象查 MTL_MATERIAL_TRANSACTIONS 大表时全表扫描一条查询跑十几分钟。 原因数据字典里的统计信息没更新优化器误判表很小。 解决对目标表重新收集统计信息BEGIN DBMS_STATS.GATHER_TABLE_STATS( ownname INV, tabname MTL_MATERIAL_TRANSACTIONS, cascade TRUE ); END;逻辑说明cascade TRUE表示同时收集表的索引统计信息。生产环境执行前确认业务低峰期避免收集过程中占用资源。这条经验在数据迁移项目里尤其重要——大批量插入后统计信息往往严重滞后。6. 进阶技巧用外键关系把表结构变成排查工具掌握单表结构只是第一步真正值钱的是把表之间的外键关系串成业务链路。R12 的数据字典里ALL_CONSTRAINTS 存了全部外键约束ALL_CONS_COLUMNS 存了外键对应的字段。我习惯在排查前先跑一遍外键查询把几张核心表的关系画出来再写业务 SQL。SELECT ac.constraint_name, ac.table_name AS child_table, aic.column_name AS child_column, acp.table_name AS parent_table, acpc.column_name AS parent_column FROM all_constraints ac JOIN all_cons_columns aic ON aic.constraint_name ac.constraint_name JOIN all_constraints acp ON acp.constraint_name ac.r_constraint_name JOIN all_cons_columns acpc ON acpc.constraint_name acp.constraint_name AND acpc.position aic.position WHERE ac.constraint_type R AND ac.table_name UPPER(:child_table) ORDER BY ac.constraint_name, aic.position;逻辑说明constraint_type R表示外键约束position字段用来匹配复合外键中的列顺序复合外键场景下漏了这个条件会产生笛卡尔积。执行后能看到目标表引用了哪些父表、通过哪个字段关联这套信息比 ER 图更贴近真实环境。把外键关系套到业务场景里就形成了完整的反推链路。比如从 AP 发票追到总账凭证链路是 AP_INVOICES_ALL发票头→ AP_INVOICE_DISTRIBUTIONS_ALL分配行→ GL_IMPORT_REFERENCES导入来源→ GL_JE_LINES凭证行→ GL_JE_HEADERS凭证头。排查业务数据差异时沿着这条链路每层做一次聚合比对能迅速定位是哪个环节断了。有了这个思路表结构就不再是死记硬背的字段清单而是可以按业务事件动态串联的地图。某次月末对账我对 AP 发票和总账凭证的差异直接从 GL_IMPORT_REFERENCES 反查来源单据十分钟定位到一张手工调整凭证没关联来源。从那以后我每次接到新模块的查询需求都强制先跑一遍外键查询把链路画出来再写业务 SQL省掉的返工时间远超这点准备成本。希望帮到你。本文还有配套的精品资源点击获取