Excel 已生成，公式零错误。下面是这份分类的核心逻辑与分析（文件含汇总页 + 三个分类工作表，共68 张表）。
一、分类总览
分类 | 数量 | 含义 |
|---|---|---|
🟡接口可写 | 6 | 只能通过标准接口表 INSERT，由并发程序消费并清空 |
🔴禁止碰 | 60 | Oracle 内部程序/引擎维护，直写即破坏一致性 |
🟢只读 | 2 | 配置定义基表，运行期只查不改 |
合计 | 68 | — |
二、🟡 接口可写（唯一允许 INSERT 的入口）
这是整个 GL 唯一合法的"写入面"，共 6 张接口表：
表名 | 作用 | 消费程序 |
|---|---|---|
| 日记账导入（实际/预算/预留/统计） | Journal Import → 生成批/头/行 |
| 导入控制（GROUP_ID/状态） | Journal Import |
| 导入运行记录 | Journal Import |
| 预算导入，直接写 GL_BALANCES | Budget Import |
| 汇率自动加载 | Rate Loading → GL_DAILY_RATES |
| 增量跟踪余额 | 平衡接口 |
关键：写接口表 ≠ 写业务表。数据经校验→生成批头行→清空接口的闭环，你绝不能手动 INSERT 到
GL_JE_LINES或GL_BALANCES。
三、🔴 禁止碰（60 张，分四个"雷区"）
雷区 1：余额表（最致命，直写=对账永远不平）
GL_BALANCES、GL_BALANCES_DELTA、GL_DAILY_BALANCES、GL_AVERAGE_BALANCES、GL_STAT_BALANCES
→ 全部由Posting 程序 / Average Balance 程序维护。手工改一行，期间余额、YTD、ADB 全乱。
雷区 2：凭证流水
GL_JE_BATCHES、GL_JE_HEADERS、GL_JE_LINES、GL_RECURRING_BATCHES/LINES、GL_JE_SOURCES/CATEGORIES(_TL)
→ 由 Journal Import 或 UI 生成，含状态机（U/P/S/I）和 Who 字段，直写会绕过审批/追溯。
雷区 3：配置主数据（改了 = 会计设置崩）
账簿GL_LEDGERS*、科目GL_CODE_COMBINATIONS*、期间GL_PERIODS/GL_PERIOD_STATUSES、汇率GL_DAILY_RATES、预算GL_BUDGET_*、COAFND_ID_FLEX_*、合并/公司间/重估/分配/FSG 全部定义表。
雷区 4：跨模块衔接（GL 域但属 SLA 引擎）
GL_IMPORT_REFERENCES、XLA_AE_HEADERS、XLA_AE_LINES、XLA_DISTRIBUTION_LINKS
→ 由Create Accounting 维护，是"子模块→总账"追溯链，直写破坏审计。
四、🟢 只读（2 张）
FND_ID_FLEX_STRUCTURES、FND_ID_FLEX_SEGMENTS— 弹性域结构定义，运行时只查不改（决定哪个 SEGMENTn 对应哪段），修改走 AOL 配置。
五、为什么这样分：三条底层原则
- 余额永远由程序物化：
GL_BALANCES是快照聚合表，不是流水累加；直写它而不跑 Posting，凭证和余额必然不一致。 - 接口表是唯一受控入口：Oracle 把校验逻辑集中在 Journal Import，绕过它 = 绕过所有会计规则。
- R12 后 SLA 是单点真相源：XLA 由子账引擎管，GL 只消费，任何对
XLA_*/GL_IMPORT_REFERENCES的手写都会让"凭证追溯"断裂。
重要限定：表数量（68）来自上一轮的 ETRM 清单 + 本次官方文档核对；实际实例用SELECT COUNT(*) FROM dba_tables WHERE owner='GL' AND table_name LIKE 'GL%'会落在62~78 张（随补丁/版本变动）。接口表清单（GL_INTERFACE / GL_BUDGET_INTERFACE / GL_DAILY_RATES_INTERFACE）已由 Oracle 官方文档确认。
