简介面向 Oracle EBS R12 开发与运维人员的表结构参考合集聚焦数据模型与数据库架构的梳理适合从事财务、供应链、人力资源等模块二次开发、日常维护和系统升级的初中级工程师用来查证表间关系与字段含义。压缩包共 114 个文件以 58 个 PDF 和 56 个 HTML 为主前者便于离线阅读与打印归档后者适合在浏览器中按模块快速跳转检索整体约 6.01MB轻量易携带。内容覆盖数据字典的用法以及 GL、AP、AR、FA、PO、INV、OE、PER、PS 等模块的核心交易表说明总账分录头行、采购订单头、订单头、员工主数据与项目表之间的关联方式并延伸到自定义报表、触发器、存储过程的开发思路、职责与角色的权限控制、数据迁移升级中的转换规则与校验要点。已有 1605 人学习下载。1. 命名先于建模为什么 R12 的表名本身就是一份结构说明第一次翻 Oracle EBS R12 表结构的人几乎都会被同一件事绊住PO_HEADERS_ALL 里没有“订单号”这种字段只有 ORG_ID、SEGMENT1、ATTRIBUTE1 到 ATTRIBUTE15会计科目也不是一列而是一个叫 CODE_COMBINATION_ID 的整数。直觉会说这是历史包袱其实正相反——这些看不懂的部分才是主干业务字段只是挂在主干上的叶子。R12 的数据模型不是按业务实体一张张画出来的而是框架层先定了一副外骨骼多组织列、审计列、弹性域、多语言表家族、接口表规范模块再把自己的字段塞进这副骨架里。所以读 R12 表结构的顺序是反的先认骨架再看业务。骨架就那么几条规则认全之后任何一张陌生表打开三分钟内就能判断出它的组织维度、语言维度、可扩展字段和审计口径。2. ORG_ID 的两副面孔一张表怎么被切成 N 个组织的数据2.1 三套组织实体两个不同的列名EBS 里所有组织最终都落在 HR_ALL_ORGANIZATION_UNITS 这一张表上所谓“业务实体”“库存组织”“HR 组织”只是给这条记录打上不同的分类标签。对外常见的 ORG_ORGANIZATION_DEFINITIONS是按分类过滤出来的一层视图方便你按“库存组织”这个身份去挑组织而不是再去 join 分类表。问题出在列名上。财务和采购侧的表用 ORG_ID语义是业务实体Operating Unit库存和物料侧的表用 ORGANIZATION_ID语义是库存组织。两个概念、两个列名却经常被当成同一个东西。PO_HEADERS_ALL.ORG_ID 是下单的那个 OUMTL_ONHAND_QUANTITIES.ORGANIZATION_ID 是货在哪个子库存所属的库存组织二者在数值上可能相同也可能完全不同——因为一个 OU 下可以挂十几个库存组织。常见的实现思路是这样库存组织在 HR 组织体系里有一条记录同时在 MTL_PARAMETERS 里有一行参数成本方法、默认科目、是否主组织ORG_ID 和 ORGANIZATION_ID 通过组织表关联起来。所以跨模块写报表时如果拿 PO 的 ORG_ID 去 join 库存表的 ORGANIZATION_ID数据不会报错只会安静地错。还有一类更隐蔽的情况某些多组织表的 ORG_ID 允许为空代表“跨组织共享的全局行”比如主组织里的主物料。这类行在按组织过滤时容易被整体丢掉报表数字就少一块。2.2 MOAC 怎么把谓词加到你没写的 SQL 上R12 的多组织访问控制MOAC最反直觉的一点是你写SELECT * FROM PO_HEADERS_ALL如果环境配好了返回的并不是全表。谓词是被数据库层加进去的。早期版本的做法是“表 安全视图”物理表不带后缀对外暴露一个带 ORG_ID 过滤的 _ALL 视图靠 CLIENT_INFO 里的组织上下文过滤。R12 之后基本翻了过来——物理表就叫 _ALL 并且带 ORG_ID 列安全通过 VPD虚拟专用数据库策略在会话级织入上下文由 MO_GLOBAL 这个包维护可见组织集合则由“MO: 安全配置文件”这类配置文件决定。在 SQL*Plus 或者第三方客户端里直连这套上下文是空的于是出现两种极端现象要么一行都查不到要么看到了全表——取决于策略有没有启用、连接的是不是 APPS。要让会话“像 EBS 表单里那样”工作得手动初始化-- 模拟一次 EBS 会话先初始化应用上下文再设定组织访问模式 BEGIN FND_GLOBAL.APPS_INITIALIZE( user_id 1012345, -- FND_USER.USER_ID随便一个有权限的用户 resp_id 50617, -- FND_RESPONSIBILITY.RESPONSIBILITY_ID resp_appl_id 201 -- 该职责所属 APPLICATION_ID201 采购 ); -- 第一个参数S 单组织M 多组织按安全配置文件 -- 第二个参数单组织时传入具体的 ORG_ID MO_GLOBAL.SET_POLICY_CONTEXT(S, 204); END; /参数的含义直接决定你看到什么resp_id决定了哪些菜单和职责级配置文件生效SET_POLICY_CONTEXT(S, 204)把当前会话锁到 204 这个组织上。日常排查里最常犯的错是只初始化了 APPS 上下文却忘了设组织或者反过来设了组织但职责跟模块不匹配结果策略织入的谓词和你想的不是一套。2.3 先确认它到底是表还是视图不同版本、不同补丁级别下同一个对象名可能是表、可能是视图、可能挂着策略也可能什么都没有。与其背结论不如每次花十秒查一下-- 1) PO_HEADERS_ALL 到底是物理表还是视图 SELECT object_name, object_type FROM all_objects WHERE owner APPS AND object_name IN (PO_HEADERS_ALL, PO_HEADERS); -- 2) 如果挂着 VPD 策略策略名和实现包会直接告诉你过滤逻辑在哪 SELECT object_name, policy_name, package, function, enable FROM dba_policies WHERE object_name PO_HEADERS_ALL;第一条查询回答“我查的是不是真表”第二条回答“谓词是谁加的”。package列通常指向 MO 相关的包policy_name一般带_MO或_POLICY后缀具体名字各模块不完全一致以查询结果为准。把这两条当成固定动作比记“某表是视图”可靠得多因为升级、打补丁、克隆环境都可能改变答案。真正危险的操作是为了“看全数据”去直接读底座表、或者用高权限账号绕开策略做报表。这种 SQL 在测试环境跑得很欢上了生产就是跨组织串数据对账时根本找不到原因。我见过最典型的现场是一张跨 OU 的应收明细某个 OU 的数字翻了一倍最后发现是视图被绕过、同一批发票被两个组织各算了一次。3. 后缀家族与 WHO 列_ALL、_B、_TL、_VL 到底谁在替你干活3.1 WHO 五列记录的信息比想象中多也比想象中少几乎每张业务表末尾都有五列CREATED_BY、CREATION_DATE、LAST_UPDATED_BY、LAST_UPDATE_DATE、LAST_UPDATE_LOGIN。它们是框架层统一加的模块不用管所以你不能指望某个模块“记得更细”。并发请求写入的数据还会额外带四个字段REQUEST_ID、PROGRAM_APPLICATION_ID、PROGRAM_ID、PROGRAM_UPDATE_DATE用来回答“这批数据是哪个请求跑出来的”。LAST_UPDATE_LOGIN 存的不是用户 id而是登录会话的标识一般对应 FND_LOGINS 里的登录记录。它能区分“同一个人换了三次会话改的数据”这在追责时很有用——但很多做数据修复的脚本不会维护它直接 update 完之后这一列还是旧值追溯链就断在这里。这五列常被误当成两个东西用都很容易出问题。一是当成严格审计它只记最后一次修改中间过程没有二是当成增量抽取的水位线靠 LAST_UPDATE_DATE 拉增量会漏掉补录的历史单据、后台直接改库的数据、同一秒内的多次提交。真正要增量得靠 CREATION_DATE 加回退窗口或者干脆上日志/物化视图。顺带说一个相关的细节EBS 主键基本由序列生成形如 PO_HEADERS_S所以 id 是跳号的、不连续的。别拿 id 的差值估单据量也别按 id 排序当业务时间顺序用。3.2 后缀就是语义认错了 join 就错同一张业务对象在 R12 里往往有一窝名字后缀不是随便起的后缀含义能不能直接当业务表查_ALL带 ORG_ID 的多组织物理表可以但要受组织策略约束_B多语言改造后的底座表只存与语言无关的列可以但描述类字段不在这里_TL翻译表每个语言一行必须带语言条件否则行数翻倍_VL底座表 join 翻译表之后的视图推荐取描述字段走它_INTERFACE接口表外部数据进 EBS 的入口可以查但不能当权威数据源_ERRORS接口校验失败明细只用于排错_CONTROL接口批次控制存 GROUP_ID、总数、总额用于判断批次是否平衡INTERFACE、ERRORS 和 CONTROL 这一组是 R12 里对“外部系统灌数据”的标准回答数据先落到接口表用一个 GROUP_ID 标识批次控制表记录这批数据的条数和金额合计导入程序先比对控制表再逐行校验失败的落到错误表里带原因。所以查接口问题时永远先看控制表的总数和总额对不对再看单行——顺序反了会在几千行里瞎找。3.3 _TL 表为什么总让报表行数翻倍多语言表的设计是“每个翻译语言一行”。一条物料在 _TL 里可能有 ZH、US、JA 三行SOURCE_LANG 标记哪一行是录入时的原始语言。如果你只写join ... on id id一条物料立刻变成三条金额类报表直接放大三倍——这种错很常见而且因为数字“看起来合理”往往对账时才被发现。正确写法是把语言锁死SELECT msib.segment1 AS item_code, msitl.description AS item_desc FROM mtl_system_items_b msib JOIN mtl_system_items_tl msitl ON msitl.inventory_item_id msib.inventory_item_id AND msitl.organization_id msib.organization_id -- 组织也要带上 AND msitl.language USERENV(LANG) -- 关键锁定语言 WHERE msib.organization_id 204;USERENV(LANG)在 EBS 表单会话里由 ICX 层设好直连客户端里往往是空的这时要显式赋一个合法语言代码。别凭感觉写 ZHS 之类的猜测值从 FND_LANGUAGES 里查当前安装的语言代码或者干脆用_VL视图让它替你处理这一层。用_VL也不是万能的视图内部的过滤同样依赖会话语言语言没设对描述字段就是空。所以看到“描述全空但数据都在”第一反应应该是语言上下文而不是数据没录。4. 弹性域科目和自定义字段为什么都不在业务表里4.1 一个整数换来的是千万级组合表会计科目在 EBS 里不是字符串是一条记录的主键CODE_COMBINATION_ID业内简称 CCID。所有子模块AP 发票行、GL 分录行、FA 资产引用科目时都只存这个整数。代价是 GL_CODE_COMBINATIONS 这张表会膨胀得离谱段值组合一旦被使用过就会生成一行并长期保留几千万行是常态。表结构上是宽表——CODE_COMBINATION_ID、CHART_OF_ACCOUNTS_ID、SEGMENT1 到 SEGMENT30、ENABLED_FLAG、SUMMARY_FLAG、START_DATE_ACTIVE、END_DATE_ACTIVE、TEMPLATE_ID。为什么不用 EAV一行一个段值因为科目是“写少读多”的极端场景。宽表意味着一行就能拼出完整科目串不用 join 三十次代价是列多、索引宽插入校验慢。常见的实现是给 CHART_OF_ACCOUNTS_ID 加各段建唯一索引防止重复组合所以那张索引本身就非常宽——这也是组合表插入慢、批量建组合要格外小心的原因。SUMMARY_FLAG 是另一个容易踩的点标记为汇总的组合用于报表汇总不能用于实际录入TEMPLATE_ID 非空的则是模板组合也不是真科目。过滤条件写错报表里就会混进“看起来像科目”的假行。4.2 段结构是数据不是代码关键的地方在于SEGMENT5 到底叫“产品”还是“项目”不是由数据库列名决定的而是由元数据决定的。同一个 SEGMENT5在不同客户的账套里含义可以完全不同。所以拿到一份表结构资料看到 SEGMENT1..30 不要急着猜去查这三张表-- 结构 - 段 - 值集确认某个 SEGMENT 列到底对应什么段 SELECT fifs.id_flex_structure_name, fifseg.segment_num, fifseg.application_column_name AS column_name, -- 就是 SEGMENT1..30 fifseg.flex_value_set_id, fvs.flex_value_set_name, fvs.validation_type FROM fnd_id_flex_structures fifs JOIN fnd_id_flex_segments fifseg ON fifseg.id_flex_num fifs.id_flex_num JOIN fnd_flex_value_sets fvs ON fvs.flex_value_set_id fifseg.flex_value_set_id WHERE fifs.id_flex_code GL# -- GL# 是会计科目弹性域的固定编码 AND fifseg.application_id 101 -- 101 GL ORDER BY fifseg.segment_num;id_flex_code GL#和application_id 101是这段查询的两个常量换成别的弹性域就要跟着换比如资产、成本科目各有自己的 flex code本文还有配套的精品资源点击获取