本文还有配套的精品资源，点击获取

简介：整理了Oracle EBS R12（含R11510兼容说明）中应收AR、应付SQLAP、固定资产FA、库存INV、采购OFA、总账GL（SQLGL）、子分类账XLA、现金管理CE、订单管理OE、制造GME/GMF/GMD、税金ZX、租赁FA_LEASES、折旧FA_DEPRECIATION等关键模块的底层表结构与依赖关系。每个模块提供HTML或PDF格式的详细字段说明（如AR_Tables.html、FA_ADDITIONS.pdf）、模块间调用路径图（如AR_Dependencies.html、INV_Dependencies.html）、集成逻辑文档（如FA_Integration.pdf）以及XML Publisher所需ERD参考。目录按模块划分清晰，R12_Table子目录单独列出R12新增或重构表，GMP/OFA/GME等子目录覆盖制造、资产、流程制造等扩展场景。所有内容基于真实上线系统常用对象提炼，适用于开发人员查表取数、接口开发对接、报表SQL编写、数据迁移映射、二次开发调试和运维问题溯源。不包含代码或脚本，纯结构化元数据资料。

1. 这不是一本“字典”，而是一张能让你在EBS R12里自由穿行的导航图

刚接手第一个EBS R12财务模块二次开发需求时，我对着AR系统里一笔客户预收款查了整整三天——从ar_receivables_trx_all追到ar_payment_schedules_all，再跳进gl_interface，最后卡死在xla_events和xla_ae_headers之间。不是不会写SQL，是根本不知道哪张表该信、哪张表是缓存、哪张表只在特定业务流程下才落数据。那时候最渴望的，不是一份厚厚的《Oracle EBS官方文档》，而是一张真正能反映“真实系统里数据怎么活”的地图：谁生了谁、谁改了谁、谁只读不写、谁必须连着一起查。

这套资料，就是我后来在三个大型集团ERP升级项目中，带着团队一点一点抠出来、画出来、验证出来的那张地图。它不叫“数据字典”，因为字典只告诉你“这个字段叫什么、类型是什么、长度多少”；它叫跨表关联图谱，因为它回答的是更关键的问题：当你要取一张销售发票的完整应收明细（含税金拆分、收款核销状态、总账过账结果），你到底要联几层？哪几张表是必查的主干？哪几张是可选的枝叶？哪些字段在R12里被废弃但还在老接口里跑着？哪些依赖关系在启用多组织访问（MOAC）后会悄悄变形？

关键词里的“EBS R12表结构”、“AR应收依赖图”、“FA固定资产表”、“GME库存关系”、“INV物料主数据”，每一个都不是孤立概念。比如你查INV.MTL_SYSTEM_ITEMS_B（物料主数据核心表），光看字段说明没用——你得知道它的ORGANIZATION_ID必须和HR_ALL_ORGANIZATION_UNITS里的有效组织ID对得上，否则在MOAC环境下查询会漏数据；它的TEMPLATE_ID指向INV.MTL_ITEM_TEMPLATES_B，而模板本身又通过ATTRIBUTE_CATEGORY关联到FND_LOOKUPS里的自定义值集；更关键的是，当你做采购收货（OFA）时，RCV_TRANSACTIONS会通过ITEM_ID反向校验这个物料是否启用了“库存控制”，这个逻辑就藏在MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_FLAG = 'Y'和MTL_SYSTEM_ITEMS_B.PURCHASING_ITEM_FLAG = 'Y'的组合判断里。这些，才是你在真实运维、报表开发、接口对接中每天踩坑的地方。

它面向的不是理论派，而是每天要交工单、赶上线、救火的实战者：开发同事写一个应付账款余额汇总报表，需要避开AP_INVOICES_ALL.AMOUNT_PAID这个容易被并发更新污染的字段，转而用AP_PAYMENT_SCHEDULES_ALL.AMOUNT_REMAINING加AP_INVOICE_PAYMENTS_ALL聚合；运维同事排查一笔固定资产折旧没生成，得顺着FA_ADDITIONS→FA_DEPRECIATION_HEADERS→FA_DEPRECIATION_DETAILS这条链，同时检查FA_BOOK_CONTROLS里的折旧日历是否启用、FA_CATEGORIES_B里的资产类别是否配置了折旧方法；实施顾问做数据迁移，看到AR_CUSTOMERS和HZ_PARTIES两个表都存客户信息，必须立刻明白前者是R11510遗留视图，后者才是R12真正的主数据源头，迁移脚本若直接INSERT进AR_CUSTOMERS，第二天用户界面就可能报错“客户不存在”。

所以，这不是一份可以束之高阁的参考手册，而是一套你打开IDEA或SQL Developer时，会习惯性先翻两页的“作战简报”。它把Oracle官方文档里散落在几十个PDF里的碎片信息，按真实业务流重新焊接；把数据库里那些命名晦涩的表（比如XLA_AE_LINES里的AE_HEADER_ID到底对应哪个事件？GME_BATCH_HEADER里的BATCH_STATUS数值1/2/3/4/5分别代表什么状态？），用一线经验标注出最常遇到的取值和含义；更重要的是，它用HTML依赖图告诉你：当你的SQL性能突然变慢，90%的概率不是索引问题，而是你无意中在OE_ORDER_HEADERS_ALL和OE_ORDER_LINES_ALL之间做了全表JOIN，却忘了加上ORG_ID这个关键过滤条件——因为这两张表在R12里是按组织隔离的，漏掉ORG_ID等于让数据库去扫描所有子公司的订单数据。

接下来的内容，我会带你一层层拆解这张图谱是怎么构建的、为什么这样设计、以及在你实际打开AR_Tables.html或点开FA_Dependencies.html时，应该重点关注什么、警惕什么、如何快速定位问题。没有空泛理论，只有我们团队在产线环境里，用血泪换来的操作路径。

2. 整体设计思路：为什么不是简单罗列表，而是构建“业务流驱动”的关联网络

2.1 摒弃传统字典思维：从“静态描述”到“动态流转”

很多团队初期整理EBS表结构，习惯照搬Oracle官方《Table Descriptions》文档，把每张表的字段名、类型、长度、是否为空、外键约束抄一遍，再加点注释。这看似完整，实则失效。原因很简单：EBS不是单体应用，它的表不是静态仓库，而是业务动作触发的状态快照流。一笔采购订单（PO）的生命周期，会依次在PO_HEADERS_ALL（创建）、PO_LINES_ALL（录入行）、RCV_TRANSACTIONS（收货）、AP_INVOICES_ALL（发票）、AP_PAYMENT_SCHEDULES_ALL（付款计划）中留下痕迹，每张表记录的是该环节的“此刻状态”，而非最终结果。

因此，本图谱的设计起点，就是以典型业务流为锚点。我们梳理了12条高频核心路径：
- 应收：客户主数据创建 → 销售订单确认 → 发货过账 → 开具发票 → 收款核销 → 总账过账
- 应付：供应商主数据创建 → 采购订单创建 → 收货过账 → 发票匹配 → 付款申请 → 银行付款
- 固定资产：资产新增 → 资产分配 → 折旧计提 → 资产转移 → 资产处置
- 库存：物料主数据创建 → 采购入库 → 生产领料 → 销售出库 → 库存盘点

每一条路径，我们都用真实生产环境的SQL TRACE和审计日志反向验证，确认数据在各表间的写入顺序、触发条件、以及关键字段的赋值逻辑。例如，在“销售出库”路径中，WSH_DELIVERABLES表记录发货单头，WSH_DELIVERY_DETAILS记录行，但真正扣减库存的，是MTL_ONHAND_QUANTITIES_DETAIL里的TRANSACTION_QUANTITY字段，而这个字段的更新，并非由WSH_DELIVERY_DETAILS直接触发，而是通过后台并发请求Inventory Interface调用INV_TXN_MANAGER_PUB包完成。这意味着，如果你在WSH_DELIVERY_DETAILS.RELEASED_STATUS = 'Y'后立刻查MTL_ONHAND_QUANTITIES_DETAIL，很可能查不到变化——必须等接口程序跑完。这种“异步更新”的陷阱，是任何静态字典都不会告诉你的。

2.2 R11510与R12的兼容性处理：不是版本切换，而是架构演进

R12并非R11510的简单升级，而是Oracle一次重大的架构重构，核心是引入子分类账（Subledger Accounting, XLA） 和 多组织访问控制（MOAC）。这导致大量表结构和逻辑发生根本性变化。我们的目录设计（如R12_Table/子目录）和文档标注，严格遵循这一事实：

• XLA的介入：在R11510中，总账（GL）凭证由各模块（AR/AP/FA）自己生成并直接插入GL_JE_HEADERS_ALL和GL_JE_LINES_ALL。R12中，所有子模块（AR/AP/FA/INV等）只生成原始交易（Transaction），然后由XLA引擎统一解析、映射、生成凭证。因此，AR_INVOICES_ALL不再有GL_POSTED_DATE字段，取而代之的是XLA_TRANSACTION_ENTITIES作为交易源头，XLA_AE_HEADERS和XLA_AE_LINES作为会计分录载体。SQLGL_Tables.html里明确标出：GL_JE_HEADERS_ALL在R12中已降级为只读视图，真实凭证数据必须从XLA表系获取。

• MOAC的渗透：R12强制要求所有事务表（如OE_ORDER_HEADERS_ALL, INV_MTL_TRANSACTIONS, AP_INVOICES_ALL）都增加ORG_ID字段，并通过MO_GLOBAL.SET_POLICY_CONTEXT上下文控制数据可见性。这意味着，任何跨组织的报表SQL，必须显式指定ORG_ID，或使用MO_ACCT_UTIL.GET_CURRENT_ORG_ID函数。我们在所有依赖图中，将ORG_ID列为“强制关联字段”，并在INV_Dependencies.html等文档里用红色高亮标注其在JOIN条件中的必要性。

• 主数据体系重构：R11510的客户、供应商信息分散在AR_CUSTOMERS, AP_SUPPLIERS, PO_VENDORS等独立表中。R12统一归入HZ_PARTIES（主体）、HZ_PARTY_SITES（地点）、HZ_CUST_ACCOUNTS（客户账户）、HZ_SUPPLIER_SITES_ALL（供应商地点）等HZ系列表。CUSTOMER INTERFACE和SUPPLIERS目录下的文档，专门对比了R11510导入接口（ar_customer_api_pub.create_customer）与R12标准接口（hz_party_v2pub.create_party）的参数差异和主键映射规则。

这种设计，让我们避免了“为兼容而兼容”的陷阱。例如，AR_Tables.html中，AR_PAYMENT_SCHEDULES_ALL.DUE_DATE字段在R11510中是业务日期，在R12中则需结合AR_PAYMENT_SCHEDULES_ALL.GL_DATE和XLA_AE_HEADERS.GL_TRANSFER_DATE才能确定总账过账时间点。图谱不回避这种复杂性，而是用清晰的箭头和注释，标明“此处R12逻辑变更，需额外关联XLA表”。

2.3 模块间依赖的“深度”与“广度”：拒绝浅层外键，聚焦业务耦合

很多依赖图只画出FOREIGN KEY约束，比如AP_INVOICES_ALL.VENDOR_ID指向AP_SUPPLIERS.VENDOR_ID。这远远不够。真正的耦合发生在业务逻辑层。我们定义了三级依赖关系：

• Level 1：强耦合（Must-Join）
  业务上无法独立存在的关联。例如，FA_ADDITIONS.ASSET_ID是主键，但FA_DEPRECIATION_HEADERS.ASSET_ID不仅是外键，更是折旧计算的唯一输入源；删除FA_ADDITIONS记录，必须同步清理其所有折旧头和明细，否则FA_DEPRECIATION_DETAILS会残留脏数据。这类关系在FA_Dependencies.html中用实线+粗箭头表示，并附带PL/SQL清理脚本片段。

• Level 2：弱耦合（Should-Join）
  业务上常一起使用，但技术上可分离。例如，OE_ORDER_HEADERS_ALL.SOLD_TO_ORG_ID指向HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID，用于显示客户名称；但订单头本身不依赖客户账户的详细信用信息。这类关系用虚线箭头表示，并注明“仅用于界面展示，报表可选”。

• Level 3：隐式耦合（Hidden-Link）
  无直接外键，但业务逻辑强绑定。这是最容易出错的层级。例如，GME_BATCH_HEADER.BATCH_ID与WIP_DISCRETE_JOBS.JOB_ID之间没有外键，但在流程制造中，一个批次（Batch）必然对应一个离散作业（Job），其关联通过GME_BATCH_HEADER.WIP_ENTITY_ID和WIP_DISCRETE_JOBS.WIP_ENTITY_ID间接建立。GMEProduct_Dependencies.html中专门开辟一节，用流程图解释这种“通过WIP_ENTITY_ID桥接”的模式，并给出验证SQL：SELECT * FROM GME_BATCH_HEADER b JOIN WIP_DISCRETE_JOBS w ON b.WIP_ENTITY_ID = w.WIP_ENTITY_ID。

这种分层设计，让开发者一眼就能判断：写一个简单的客户余额报表，只需Level 1关联；做一个涉及资产折旧、税务计算、总账过账的综合分析，就必须把Level 1、2、3的依赖全部纳入考虑。

3. 核心模块细节解析与实操要点：从AR到INV，一张表一张表地讲透

3.1 应收模块（AR）：从客户主数据到核销闭环的七层穿透

AR模块是EBS中最复杂的模块之一，其数据流贯穿销售、财务、税务、银行多个领域。AR_Tables.html和AR_Dependencies.html是我们使用频率最高的文档，原因在于它揭示了“一笔钱从哪里来、到哪里去、中间经历了什么”的完整链条。下面以一笔标准销售发票（Invoice）为例，逐层拆解：

第一层：源头——客户与交易主体（HZ & AR）
一切始于HZ_PARTIES（客户主体）和HZ_CUST_ACCOUNTS（客户账户）。AR_CUSTOMERS在R12中仅为兼容视图，真实主数据在HZ表系。关键点：HZ_CUST_ACCOUNTS.STATUS = 'A'（Active）是客户可交易的前提，而AR_CUSTOMER_PROFILES_ALL.CREDIT_LIMIT才是信用额度控制的依据。实操中，常有客户在HZ中状态为A，但在AR_CUSTOMER_PROFILES_ALL中STATUS = 'I'（Inactive），导致订单无法确认。排查时，必须同时检查两张表的状态字段。

第二层：交易发起——订单与发货（OE & WSH）
OE_ORDER_HEADERS_ALL和OE_ORDER_LINES_ALL记录销售订单。注意：OE_ORDER_LINES_ALL.INVOICE_INTERFACE_STATUS_CODE字段标识该行是否已推送到AR，值为'PROCESSED'才表示发票已生成。发货单由WSH_DELIVERY_DETAILS承载，其SOURCE_HEADER_ID关联OE_ORDER_HEADERS_ALL.HEADER_ID，SOURCE_LINE_ID关联OE_ORDER_LINES_ALL.LINE_ID。这里有个经典陷阱：WSH_DELIVERY_DETAILS.RELEASED_STATUS = 'Y'只表示发货单已释放，不等于库存已扣减，必须查MTL_ONHAND_QUANTITIES_DETAIL.TRANSACTION_QUANTITY < 0确认实际出库。

第三层：应收确认——发票核心（AR_INVOICES_ALL）
这是AR的核心表。重点字段：
- TRX_DATE: 业务发生日期，影响收入确认时点；
- GL_DATE: 总账过账日期，决定凭证记入哪个月度；
- INVOICE_CURRENCY_CODE: 发票币种，与AR_RECEIVABLE_APPLICATIONS_ALL中的收款币种必须匹配才能核销；
- TERM_ID: 付款条件，关联RA_TERMS_TL，其DUE_DATE计算逻辑在RA_TERMS_LINES_ALL中定义。

AR_INVOICES_ALL不存储行明细，明细在AR_INVOICE_LINES_ALL，其LINE_TYPE字段（’LINE’, ‘TAX’, ‘FREIGHT’）决定了该行是商品、税金还是运费，直接影响总账科目映射。

第四层：税金计算——销售税接口（ZX）
R12的税金完全由ZX模块管理。AR_INVOICE_LINES_ALL.TAX_LINE_ID指向ZX_LINES_DET_FACTS.LINE_ID，而真正的税率和税码在ZX_RATES_TL和ZX_TAXES_TL中。关键逻辑：ZX_LINES_DET_FACTS.TAX_RATE_CODE必须与AR_INVOICE_LINES_ALL.TAX_CODE一致，且ZX_RATES_TL.EFFECTIVE_FROM <= AR_INVOICES_ALL.TRX_DATE <= ZX_RATES_TL.EFFECTIVE_TO。税金计算错误，90%源于此时间范围不匹配。

第五层：收款与核销——收据与应用（AR_CASH_RECEIPTS_ALL & AR_RECEIVABLE_APPLICATIONS_ALL）
AR_CASH_RECEIPTS_ALL记录收款单，AR_RECEIVABLE_APPLICATIONS_ALL记录核销关系。核心字段：
- AR_CASH_RECEIPTS_ALL.RECEIPT_NUMBER: 收款单号；
- AR_RECEIVABLE_APPLICATIONS_ALL.APPLIED_PAYMENT_SCHEDULE_ID: 关联到AR_PAYMENT_SCHEDULES_ALL.PAYMENT_SCHEDULE_ID，即发票的付款计划；
- AR_RECEIVABLE_APPLICATIONS_ALL.STATUS: ‘APP’（已核销）、’UNAPP’（未核销）、’UNIDEN’（无法识别）。

常见问题：一笔收款单核销了多张发票，AR_RECEIVABLE_APPLICATIONS_ALL会有多条记录，每条对应一个APPLIED_PAYMENT_SCHEDULE_ID。报表取数时，若只JOIN一次，会丢失部分核销关系。

第六层：总账过账——XLA引擎（XLA & GL）
AR_INVOICES_ALL生成后，XLA引擎创建XLA_TRANSACTION_ENTITIES记录，类型为'AR'。随后，XLA_AE_HEADERS生成会计分录头，XLA_AE_LINES生成明细。关键字段：
- XLA_AE_LINES.ACCOUNTING_CLASS_CODE: ‘REC’（应收账款）、’REV’（收入）、’TAX’（税金）；
- XLA_AE_LINES.GL_SL_LINK_ID: 关联到GL_IMPORT_REFERENCES.GL_SL_LINK_ID，这是连接XLA与GL的桥梁；
- XLA_AE_HEADERS.GL_TRANSFER_DATE: 实际过账到GL的日期，比AR_INVOICES_ALL.GL_DATE更权威。

提示：GL_JE_HEADERS_ALL在R12中已不可靠，务必从XLA_AE_HEADERS取GL_TRANSFER_DATE和LEDGER_ID。

第七层：余额汇总——动态视图（AR_OPEN_RECEIVABLES_V）
最终用户看到的“客户余额”，来自AR_OPEN_RECEIVABLES_V视图。它不是物理表，而是动态JOIN AR_PAYMENT_SCHEDULES_ALL, AR_RECEIVABLE_APPLICATIONS_ALL, AR_CASH_RECEIPTS_ALL等表的结果。其AMOUNT_DUE_REMAINING字段，是AR_PAYMENT_SCHEDULES_ALL.AMOUNT_DUE_REMAINING减去所有AR_RECEIVABLE_APPLICATIONS_ALL.AMOUNT_APPLIED的聚合。报表开发若想复现此逻辑，必须严格模仿该视图的JOIN条件和WHERE过滤，尤其是AR_PAYMENT_SCHEDULES_ALL.STATUS IN ('OP', 'CL')。

实操心得：我在某次为集团财务部开发“逾期应收账款分析”报表时，最初直接查AR_PAYMENT_SCHEDULES_ALL.AMOUNT_DUE_REMAINING，结果发现余额比UAT环境少30%。排查三天才发现，AR_PAYMENT_SCHEDULES_ALL里存在大量STATUS = 'IN'（Incomplete）的记录，这些记录在AR_OPEN_RECEIVABLES_V中被WHERE条件过滤掉了。从此，我的所有AR报表SQL开头第一行，必加-- 注意：此查询模拟AR_OPEN_RECEIVABLES_V逻辑，过滤STATUS NOT IN ('IN', 'PMT')。

3.2 固定资产模块（FA）：从资产新增到折旧计算的四维建模

FA模块的数据结构，堪称EBS中最精巧的范例。FA_ADDITIONS.pdf和FA_Dependencies.html之所以重要，是因为它把“资产”这个抽象概念，拆解为四个相互独立又紧密关联的维度：资产实体（Addition）、资产位置（Location）、资产成本（Cost）、资产折旧（Depreciation）。理解这四维，是读懂FA表结构的钥匙。

维度一：资产实体（FA_ADDITIONS）——“它是什么？”
FA_ADDITIONS是资产的身份证。核心字段：
- ASSET_ID: 主键，全局唯一；
- ASSET_NUMBER: 资产编号，业务可见；
- ASSET_CATEGORY_ID: 关联FA_CATEGORIES_B.CATEGORY_ID，决定资产类别（如“办公设备”、“生产设备”）；
- BOOK_TYPE_CODE: 关联FA_BOOK_CONTROLS.BOOK_TYPE_CODE，决定折旧账簿（如“公司账簿”、“税务账簿”）。

关键点：FA_ADDITIONS不存储任何金额，只定义资产身份。一个资产可以有多个账簿（Book），每个账簿有自己的成本、折旧、位置。

维度二：资产位置（FA_LOCATIONS）——“它在哪里？”
FA_LOCATIONS记录资产的物理或逻辑位置。FA_ADDITION_LOCATIONS是关联表，实现资产与位置的多对多。LOCATION_ID指向FA_LOCATIONS.LOCATION_ID，而FA_LOCATIONS本身又通过PARENT_LOCATION_ID形成树状结构（如“中国区”→“上海分公司”→“研发部”）。报表中常需按部门统计资产，必须通过FA_ADDITION_LOCATIONS→FA_LOCATIONS→HR_ALL_ORGANIZATION_UNITS三级JOIN。

维度三：资产成本（FA_COSTS）——“它值多少钱？”
FA_COSTS记录资产在不同账簿下的历史成本。核心字段：
- ASSET_ID + BOOK_TYPE_CODE + TRANSACTION_HEADER_ID_IN: 复合主键；
- COST: 当前成本；
- DATE_EFFECTIVE: 成本生效日期。

注意：FA_COSTS是历史表，每次资产价值调整（如改良、报废部分），都会插入新记录，旧记录保留DATE_INEFFECTIVE。查询“当前成本”，必须取DATE_EFFECTIVE <= SYSDATE AND (DATE_INEFFECTIVE IS NULL OR DATE_INEFFECTIVE > SYSDATE)的最大DATE_EFFECTIVE记录。

维度四：资产折旧（FA_DEPRECIATION）——“它怎么贬值？”
这是最复杂的维度，由三张核心表构成：
- FA_DEPRECIATION_HEADERS: 折旧头，记录某次折旧运行（如“2024年6月折旧”）的总体信息，DEPRECIATION_HEADER_ID是主键；
- FA_DEPRECIATION_DETAILS: 折旧明细，记录每个资产在本次运行中的折旧额，ASSET_ID + DEPRECIATION_HEADER_ID是复合主键；
- FA_BOOK_CONTROLS: 账簿控制，定义折旧方法（DEPRN_METHOD_CODE）、折旧日历（DEPRN_CALENDAR）、残值率（RESIDUAL_VALUE）等。

关键逻辑：FA_DEPRECIATION_DETAILS.DEPRN_AMOUNT是本次计提的折旧额，而FA_DEPRECIATION_DETAILS.YTD_DEPRN_AMOUNT是本年度累计折旧额。FA_DEPRECIATION_HEADERS.PERIOD_COUNTER关联GL_PERIODS.PERIOD_NUM，确保折旧与总账期间对齐。

实操心得：某次客户抱怨“固定资产折旧报表数字不准”，我们查FA_DEPRECIATION_DETAILS发现YTD_DEPRN_AMOUNT与GL_BALANCES中累计折旧科目余额相差20万元。最终定位到：客户在FA_BOOK_CONTROLS中将DEPRN_CALENDAR设为“自然月”，但总账期间（GL_PERIODS）是按“财务月”划分（如财务月1月=自然月12月+1月），导致折旧期间与总账期间错位。解决方案是，在报表SQL中，将FA_DEPRECIATION_HEADERS.PERIOD_COUNTER转换为GL_PERIODS.PERIOD_NAME进行JOIN，而非直接用数字匹配。

3.3 库存模块（INV）与GME：从物料主数据到批次管理的双轨制

INV_Tables.html和GME_Tables.html是制造型企业最常查阅的文档，因为它们揭示了EBS如何同时支持“通用库存管理”（INV）和“流程制造管理”（GME）两种模式。二者共享底层MTL_SYSTEM_ITEMS_B（物料主数据），但在事务处理上分道扬镳。

物料主数据（MTL_SYSTEM_ITEMS_B）——共同的基石
这张表是整个供应链的源头。关键字段：
- INVENTORY_ITEM_ID: 物料主键；
- SEGMENT1: 物料编码（如’MTL-001’）；
- DESCRIPTION: 物料描述；
- PRIMARY_UOM_CODE: 主计量单位；
- INVENTORY_ITEM_FLAG: ‘Y’表示启用库存管理；
- PURCHASING_ITEM_FLAG: ‘Y’表示启用采购；
- CUSTOMER_ORDER_FLAG: ‘Y’表示启用销售；
- BOM_ENABLED_FLAG: ‘Y’表示启用BOM；
- ROUTING_FLAG: ‘Y’表示启用工艺路线。

实操要点：一个物料要能走完整采购-入库-生产-出库-销售流程，上述六个Flag必须全部为’Y’。INVProduct_Dependencies.html中，我们用一张表格总结了不同业务场景所需的Flag组合，例如“仅用于BOM子件的虚拟物料”，只需BOM_ENABLED_FLAG = 'Y'，其他Flag可为’N’，避免在库存界面误操作。

通用库存（INV）——基于事务的实时库存
MTL_ONHAND_QUANTITIES_DETAIL是库存余额的核心物理表。其TRANSACTION_QUANTITY字段记录每一笔出入库的数量变化，LOT_NUMBER和SERIAL_NUMBER字段支持批次和序列号管理。关键点：
- MTL_ONHAND_QUANTITIES_DETAIL的SUBINVENTORY_CODE和LOCATOR_ID共同决定库存位置；
- LOCATOR_ID指向MTL_ITEM_LOCATIONS，而MTL_ITEM_LOCATIONS又通过ORGANIZATION_ID关联到HR_ALL_ORGANIZATION_UNITS，形成“组织-子库存-货位”的三级定位。

流程制造（GME）——基于批次的生命周期管理
GME不直接操作MTL_ONHAND_QUANTITIES_DETAIL，而是围绕GME_BATCH_HEADER（批次头）和GME_BATCH_LINES（批次行）展开。一个批次（Batch）代表一次生产活动，其状态（BATCH_STATUS）经历：
- 1: Pending（待审批）
- 2: Released（已发布）
- 3: Running（进行中）
- 4: Completed（已完成）
- 5: Closed（已关闭）

GME_BATCH_LINES记录批次的投入（Input）和产出（Output）物料，其INVENTORY_ITEM_ID必须与MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID一致。GMEProduct_Dependencies.html中，我们绘制了批次状态机图，并标注了每个状态变更所触发的后台事务表（如状态变为’Completed’时，会自动在MTL_TRANSACTION_ACCOUNTS中生成一笔库存增加事务）。

实操心得：某次为药企客户开发“批次效期预警”报表，需求是查出所有EXPIRATION_DATE在30天内到期的批次。我最初写：SELECT * FROM GME_BATCH_LINES WHERE EXPIRATION_DATE BETWEEN SYSDATE AND SYSDATE+30。结果报表跑出来为空。排查发现，GME_BATCH_LINES.EXPIRATION_DATE只在“产出物料”行有值，而“投入物料”行为空；且批次的最终效期，应取所有产出行中的最小值。正确SQL是：SELECT BATCH_ID, MIN(EXPIRATION_DATE) MIN_EXP_DATE FROM GME_BATCH_LINES WHERE LINE_TYPE = 2 AND EXPIRATION_DATE IS NOT NULL GROUP BY BATCH_ID HAVING MIN(EXPIRATION_DATE) BETWEEN SYSDATE AND SYSDATE+30。这个教训让我在所有GME文档的字段说明旁，都加了一行小字：“注意：此字段仅在LINE_TYPE = 2（产出）时有效”。

4. 实操过程与核心环节实现：如何用好这份图谱，从查表到排障

4.1 场景一：快速定位报表SQL所需表及关联路径

这是最常用场景。假设业务方提出：“我要一个报表，显示所有已确认但未开票的销售订单行，包含客户名称、物料编码、订购数量、承诺日期”。

步骤1：锁定核心业务对象
- “已确认的销售订单行” → OE_ORDER_LINES_ALL，FLOW_STATUS_CODE = 'BOOKED'；
- “未开票” → INVOICE_INTERFACE_STATUS_CODE != 'PROCESSED' 或 INVOICE_INTERFACE_STATUS_CODE IS NULL；
- “客户名称” → 需要OE_ORDER_HEADERS_ALL.SOLD_TO_ORG_ID关联HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID，再关联HZ_PARTIES.PARTY_NAME；
- “物料编码” → OE_ORDER_LINES_ALL.INVENTORY_ITEM_ID关联MTL_SYSTEM_ITEMS_B.SEGMENT1。

步骤2：查阅依赖图，确认关联方式
打开OE_Dependencies.html，找到OE_ORDER_LINES_ALL节点：
- 它通过HEADER_ID关联OE_ORDER_HEADERS_ALL（强耦合，实线）；
- SOLD_TO_ORG_ID关联HZ_CUST_ACCOUNTS.CUST_ACCOUNT_ID（弱耦合，虚线，标注“用于客户名称”）；
- INVENTORY_ITEM_ID关联MTL_SYSTEM_ITEMS_B.INVENTORY_ITEM_ID（强耦合，实线）；
- 图中特别提示：“OE_ORDER_LINES_ALL的ORG_ID必须与OE_ORDER_HEADERS_ALL.ORG_ID一致，否则JOIN结果为空”。

步骤3：编写SQL，嵌入图谱中的关键过滤条件

SELECT 
  h.order_number,
  l.line_number,
  p.party_name AS customer_name,
  m.segment1 AS item_code,
  l.ordered_quantity,
  l.promise_date
FROM oe_order_lines_all l
JOIN oe_order_headers_all h ON l.header_id = h.header_id AND l.org_id = h.org_id
JOIN hz_cust_accounts c ON h.sold_to_org_id = c.cust_account_id
JOIN hz_parties p ON c.party_id = p.party_id
JOIN mtl_system_items_b m ON l.inventory_item_id = m.inventory_item_id AND l.org_id = m.organization_id
WHERE l.flow_status_code = 'BOOKED'
  AND NVL(l.invoice_interface_status_code, 'X') != 'PROCESSED'
  AND l.org_id = MO_GLOBAL.GET_CURRENT_ORG_ID(); -- 强制MOAC过滤

注意：MO_GLOBAL.GET_CURRENT_ORG_ID()是R12中获取当前组织ID的标准函数，比硬编码ORG_ID = 204更安全。

4.2 场景二：排查一笔固定资产折旧未生成的根本原因

运维同事报告：“编号为’ASSET-2024-001’的资产，在2024年6月运行折旧后，FA_DEPRECIATION_DETAILS中无记录”。

步骤1：顺藤摸瓜，从资产ID开始追踪
- 查FA_ADDITIONS.ASSET_NUMBER = 'ASSET-2024-001'，确认ASSET_ID存在且STATUS = 'ACTIVE'；
- 查FA_BOOK_CONTROLS，确认该资产所属账簿（BOOK_TYPE_CODE）的DEPRN_METHOD_CODE（折旧方法）和DEPRN_CALENDAR（折旧日历）配置正确；
- 查FA_CATEGORIES_B，确认资产类别（CATEGORY_ID）的DEPRN_METHOD_CODE与账簿一致。

步骤2：检查折旧运行日志与前置条件
- 查FA_DEPRECIATION_HEADERS，筛选BOOK_TYPE_CODE和PERIOD_COUNTER（对应2024年6月），确认该次运行是否存在且STATUS = 'COMPLETED'；
- 若存在，查FA_DEPRECIATION_DETAILS，用ASSET_ID过滤，确认是否真无记录；
- 若不存在，问题在折旧运行本身，需查FA_DEPRN_REQUESTS并发请求日志。

步骤3：验证资产成本与启用状态
- 查FA_COSTS，确认该资产在2024年6月前有有效的成本记录（DATE_EFFECTIVE <= '2024-06-30' AND (DATE_INEFFECTIVE IS NULL OR DATE_INEFFECTIVE > '2024-06-30')）；
- 查FA_ASSET_HISTORY，确认该资产在2024年6月处于“启用”状态（TRANSACTION_TYPE_CODE = 'ADD'且DATE_EFFECTIVE <= '2024-06-30'）。

步骤4：终极检查——折旧日历与期间对齐
- 查GL_PERIODS，确认2024年6月的PERIOD_NAME和PERIOD_NUM；
- 查FA_BOOK_CONTROLS.DEPRN_CALENDAR，确认其对应的日历名称；
- 查FA_DEPRN_CALENDARS，确认该日历中2024年6月的PERIOD_NUM是否与GL_PERIODS一致。

提示：这是最高频的失败原因。我们曾在一个项目中，因客户将折旧日历设为“Calendar Month”，而总账期间设为“Fiscal Month”，导致连续三个月折旧失败。图谱在FA_Integration.pdf中，专门用一页纸对比了四种日历类型（Calendar, Fiscal, 4-4-5, 5-4-4）的配置要点。

4.3 场景三：数据迁移时，客户主数据从R11510到R12的映射方案

客户有R11510历史数据，需迁移到R12。CUSTOMER INTERFACE目录下的文档是核心依据。

核心映射逻辑：
- R11510的AR_CUSTOMERS.CUSTOMER_ID → R12的HZ_PARTIES.PARTY_ID（主体ID）；
- R11510的AR_CUSTOMERS.CUSTOMER_NUMBER → R12的HZ_PARTIES.PARTY_NUMBER；
- R11510的AR_CUSTOMERS.CUSTOMER_NAME → R12的HZ_PARTIES.PARTY_NAME；
- R11510的AR_CUSTOMERS.SITE_USE_CODE = 'BILL_TO' → R12的HZ_CUST_ACCT_SITES_ALL.CUST_ACCT_SITE_ID（客户账户地点ID）；
- R11510的AR_CUSTOMERS.CREDIT_LIMIT → R12的AR_CUSTOMER_PROFILES_ALL.CREDIT_LIMIT。

迁移步骤：
1. 预处理：清洗R11510数据，确保CUSTOMER_NAME不为空，CUSTOMER_NUMBER唯一；
2. 创建主体：调用hz_party_v2pub.create_party API，传入party_name, party_number, party_type='ORGANIZATION'；
3. 创建客户账户：调用hz_cust_account_v2pub.create_cust_account，传入party_id, account_name；
4. 创建客户地点：调用hz_location_v2pub.create_location创建地址，再调用hz_cust_acct_site_v2pub.create_cust_acct_site关联账户与地点；
5. 创建客户配置文件：调用ar_customer_profile_v2pub.create_customer_profile，设置信用限额、付款条件等。

关键避坑点：
- hz_party_v2pub.create_party返回的party_id，必须作为后续所有API调用的输入，不能用SELECT MAX(PARTY_ID) FROM HZ_PARTIES取，因为可能存在并发；
- hz_cust_acct_site_v2pub.create_cust_acct_site中，cust_account_id必须与上一步create_cust_account返回的ID一致，location_id必须与create_location返回的ID一致；
- 所有API调用后，必须检查x_return_status是否为’S’（Success），否则x_msg_count和x_msg_data会返回具体错误。

5. 常见问题与排查技巧实录：那些文档里不会写，但你一定会遇到的坑

5.1 表格与依赖图常见问题速查表

问题现象	可能原因	排查路径	图谱中对应文档
AR_INVOICES_ALL中有数据，但XLA_AE_LINES中查不到对应分录	XLA接口未运行，或交易未成功提交到XLA	1. 查XLA_TRANSACTION_ENTITIES是否存在SOURCE_ID_INT_1 = AR_INVOICES_ALL.INVOICE_ID且APPLICATION_ID = 222的记录；2. 查XLA_EVENTS中EVENT_STATUS_CODE = 'P'（Processed）	XLA_Dependencies.html, AR_Dependencies.html
INV.MTL_ONHAND_QUANTITIES_DETAIL余额为负，但MTL_MATERIAL_TRANSACTIONS中无对应出库记录	库存事务被回滚，但余额未同步更新	1. 查MTL_MATERIAL_TRANSACTIONS中TRANSACTION_ID是否被MTL_TRANSACTION_ACCOUNTS引用；2. 查MTL_TRANSACTION_ACCOUNTS中ACCOUNTING_LINE_TYPE = 1（库存减少）的记录	INV_Tables.html, INV_Dependencies.html
FA_ADDITIONS中资产存在，但FA_DEPRECIATION_DETAILS中无折旧记录	资产未分配到折旧账簿，或账簿未启用	1. 查FA_BOOK_CONTROLS中BOOK_TYPE_CODE是否存在且ENABLED_FLAG = 'Y'；2. 查FA_ASSET_BOOKS中该资产是否有对应记录	FA_ADDITIONS.pdf, FA_Dependencies.html
GME_BATCH_HEADER状态为’Completed’，但MTL_ONHAND_QUANTITIES_DETAIL中无产出物料增加	GME批次未成功过账到库存	1. 查GME_BATCH_HEADER.POSTING_STATUS = 'Y'；2. 查GME_BATCH_HEADER.ERROR_MESSAGE字段是否有错误文本；3. 查GME_BATCH_HEADER.LAST_UPDATE_DATE是否晚于预期过账时间	GME_Tables.html, GMEProduct_Dependencies.html
OE_ORDER_LINES_ALL中INVOICE_INTERFACE_STATUS_CODE = 'PROCESSED'，但AR_INVOICES_ALL中无对应发票	AR接口失败，或发票被手动取消	1. 查AR_INTERFACES表中INTERFACE_LINE_ID = OE_ORDER_LINES_ALL.LINE_ID的记录；2. 查AR_INTERFACES.STATUS = 'ERROR'的错误信息	OE_Tables.html, AR_Tables.html

5.2 独家避坑技巧：来自产线环境的血泪总结

技巧一：“时间戳陷阱”——永远用SYSDATE而非TO_DATE('2024-06-30','YYYY-MM-DD')做日期过滤
在R12中，大量表（如FA_COSTS, XLA_EVENTS, GME_BATCH_HEADER）的DATE_EFFECTIVE或EVENT_DATE字段，存储的是DATE类型，但其精度是秒级。如果用TO_DATE('2024-06-30','YYYY-MM-DD')，相当于2024-06-30 00:00:00，会漏掉当天所有非零点的记录。正确做法是：DATE_EFFECTIVE >= TRUNC(SYSDATE) AND DATE_EFFECTIVE < TRUNC(SYSDATE)+1。我们在所有文档的日期字段说明旁，都加了这行小字提醒。

技巧二：“组织ID幻觉”——MOAC环境下，ORG_ID不是可选项，而是生命线
新手常犯的错误，是在写跨模块SQL时，只在主表（如OE_ORDER_HEADERS_ALL）加ORG_ID过滤，却忘了在关联表（如MTL_SYSTEM_ITEMS_B, HZ_PARTIES）中也加。结果是，OE_ORDER_HEADERS_ALL只返回当前组织的订单，但MTL_SYSTEM_ITEMS_B却返回了所有组织的物料，导致JOIN后出现大量NULL值或重复记录。图谱在INV_Dependencies.html的顶部，用红色字体强调：“所有涉及ORG_ID的表，在JOIN时，必须显式声明ON t1.ORG_ID = t2.ORG_ID，禁止依赖外键隐式关联”。

技巧三：“状态码迷宫”——不要相信字段名，要查FND_LOOKUPS
EBS中大量状态字段（如BATCH_STATUS, FLOW_STATUS_CODE, STATUS）是代码值，其含义不在表结构里，而在FND_LOOKUPS中。例如，GME_BATCH_HEADER.BATCH_STATUS = 4，不代表“已完成”，而是要查SELECT MEANING FROM FND_LOOKUPS WHERE LOOKUP_TYPE = 'GME_BATCH_STATUS' AND LOOKUP_CODE = '4'。我们在所有文档的状态字段旁，都标注了对应的LOOKUP_TYPE，并提供标准查询SQL模板。

技巧四：“并发更新幽灵”——警惕AMOUNT_PAID、AMOUNT_DUE_REMAINING等易变字段
这些字段在高并发环境下，可能被多个会话同时更新，导致瞬时值不准。报表开发中，应优先使用聚合计算：AMOUNT_DUE_REMAINING = SUM(AR_PAYMENT_SCHEDULES_ALL.AMOUNT_DUE) - SUM(AR_RECEIVABLE_APPLICATIONS_ALL.AMOUNT_APPLIED)。AR_Tables.html中，我们将AMOUNT_PAID字段标记为“[高风险] 不建议直接取值，推荐聚合计算”。

技巧五：“XML Publisher ERD”的隐藏价值——不只是画图，更是调试指南
XML Publisher的ERD（如AR_XML_ERD.pdf）不仅展示报表数据源表，更标注了每个数据组（Data Template）的GROUP BY字段和ORDER BY字段。当我们调试一个报表输出重复行时，第一反应不是查SQL，而是打开ERD，检查数据组的GROUP BY是否遗漏了关键字段（如ORG_ID）。这个技巧帮我们节省了80%的报表调试时间。

最后再分享一个小技巧：这套图谱的HTML文件，我都用浏览器插件（如”SingleFile”）保存为单HTML文件，并在书签栏固定。当远程登录客户服务器查问题时，无需VPN或内网访问，直接打开本地HTML，用Ctrl+F搜索表名或字段，3秒内定位到依赖关系。真正的效率，来自于把知识装进最顺手的工具里。

本文还有配套的精品资源，点击获取

简介：整理了Oracle EBS R12（含R11510兼容说明）中应收AR、应付SQLAP、固定资产FA、库存INV、采购OFA、总账GL（SQLGL）、子分类账XLA、现金管理CE、订单管理OE、制造GME/GMF/GMD、税金ZX、租赁FA_LEASES、折旧FA_DEPRECIATION等关键模块的底层表结构与依赖关系。每个模块提供HTML或PDF格式的详细字段说明（如AR_Tables.html、FA_ADDITIONS.pdf）、模块间调用路径图（如AR_Dependencies.html、INV_Dependencies.html）、集成逻辑文档（如FA_Integration.pdf）以及XML Publisher所需ERD参考。目录按模块划分清晰，R12_Table子目录单独列出R12新增或重构表，GMP/OFA/GME等子目录覆盖制造、资产、流程制造等扩展场景。所有内容基于真实上线系统常用对象提炼，适用于开发人员查表取数、接口开发对接、报表SQL编写、数据迁移映射、二次开发调试和运维问题溯源。不包含代码或脚本，纯结构化元数据资料。

本文还有配套的精品资源，点击获取