Oracle EBS 实战排查：GL 日记账“找不到审批人”的底层逻辑剖析-LiaoDev's Blog

在日常的 Oracle EBS 远程运维支持中，总账（GL）模块的凭证审批工作流（GL Journal Approval Workflow）是一个经常容易卡壳的地方。最近接手了一个非常典型的工单：新入职的财务人员在提交特定账套的日记账时，系统直接报错提示“找不到审批人”，而老员工做同样的操作却一切正常。

今天就来复盘一下这个问题的排查过程，以及 EBS 寻找审批人的底层逻辑。

1. 故障现象描述

前端业务关键用户反馈了如下情况：

老员工 A： 提交账套 101 的凭证，审批人自动找到 主管 X；提交账套 102/103 的凭证，审批人自动找到 主管 Y。一切正常。
新员工 B： 提交账套 102/103 的凭证，审批人也是 主管 Y（正常）；但在提交账套 101 的凭证时，点击“审批”按钮后，工作流报错，提示找不到审批人。

从现象来看，系统的功能和工作流引擎本身没有宕机，问题大概率出在基础数据配置上。

2. 核心逻辑推演

在 EBS 中，当你点击“审批”按钮触发 GLBATCH 工作流时，系统寻找审批人主要依赖两个核心设置的交叉验证：

HR 员工/主管层级结构 (Supervisor Hierarchy)： 决定了“汇报线”。
总账授权限制 (GL Authorization Limits)： 决定了“审批额度”。

系统会顺着提交人的 HR 主管汇报线一级一级往上找，直到找到一个拥有该分类账（Ledger）足够审批额度的主管为止。如果找遍了整条汇报线都没人有权限，就会报错。

基于上述逻辑，我做出了一个初步推断：新员工 B 的汇报线上，没有任何人配置了 101 账套的审批额度。

3. 后台 SQL 溯源实战

为了验证推断，不再盲目查前端界面，直接通过后台数据库用两段 SQL 脚本把底牌翻出来。

第一步：对比两人的 HR 主管链条

我们需要弄清楚新老员工的汇报线到底有什么区别。

SQL

SELECT
    emp.full_name "制单人",
    emp.employee_number "员工编号",
    sup1.full_name "直接主管(1级)",
    sup2.full_name "二级主管(2级)",
    sup3.full_name "三级主管(3级)"
FROM per_all_people_f emp
LEFT JOIN per_all_assignments_f asg 
    ON emp.person_id = asg.person_id 
    AND TRUNC(SYSDATE) BETWEEN asg.effective_start_date AND asg.effective_end_date 
    AND asg.primary_flag = 'Y'
LEFT JOIN per_all_people_f sup1 
    ON asg.supervisor_id = sup1.person_id 
    AND TRUNC(SYSDATE) BETWEEN sup1.effective_start_date AND sup1.effective_end_date
LEFT JOIN per_all_assignments_f asg2 
    ON sup1.person_id = asg2.person_id 
    AND TRUNC(SYSDATE) BETWEEN asg2.effective_start_date AND asg2.effective_end_date 
    AND asg2.primary_flag = 'Y'
LEFT JOIN per_all_people_f sup2 
    ON asg2.supervisor_id = sup2.person_id 
    AND TRUNC(SYSDATE) BETWEEN sup2.effective_start_date AND sup2.effective_end_date
WHERE emp.full_name IN ('老员工A', '新员工B')
  AND TRUNC(SYSDATE) BETWEEN emp.effective_start_date AND emp.effective_end_date;

查询结果暴露出明显差异：

老员工 A 的链条：老员工 A -> 主管 X -> 主管 Y
新员工 B 的链条：新员工 B -> 主管 Y -> 部门总监 Z

新员工 B 的汇报线完美避开了主管 X。

第二步：核对总账授权额度

接下来，查一下这些涉及到的主管们，究竟手里握着哪些账套的权限。

SQL

SELECT
    papf.full_name "审批人姓名",
    gl.name "分类账名称",
    gl.short_name "分类账简称",
    gal.authorization_limit "审批额度"
FROM gl_authorization_limits gal
JOIN gl_ledgers gl ON gal.ledger_id = gl.ledger_id
JOIN per_all_people_f papf ON gal.employee_id = papf.person_id
WHERE TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date
  AND papf.full_name IN ('主管X', '主管Y', '部门总监Z') 
ORDER BY papf.full_name, gl.name;

查询结果直接破案： 只有 主管 X 拥有 101 账套的审批权限。主管 Y 和 部门总监 Z 都没有 101 账套的额度。

4. 根因总结与解决方案

水落石出：当新员工 B 提交 101 账套凭证时，系统去找她的直接主管 Y，发现没有额度；继续往上找总监 Z，还是没有额度；最终走到汇报线尽头，抛出“找不到审批人”的错误。而老员工 A 提交 101 账套时，她的第一级主管就是 X，权限匹配，审批正常。

这本质上是一个 HR 汇报线与总账审批额度不匹配的业务设置问题。

查明技术根因后，将选择权交还给业务部门，提供了两套解决方案：

方案 A（修改审批权限）： 如果业务确认主管 Y（或总监 Z）有资格审批 101 账套的凭证，请由拥有总账超级用户权限的管理员前往前端 设置 -> 员工 -> 限制 (Setup > Employees > Limits) 界面，为主管 Y 增加一条 101 账套的授权额度。
方案 B（修改 HR 汇报线）： 如果业务规定 101 账套的凭证必须由主管 X 审批，那说明新员工 B 的 HR 汇报线挂错了。需要人力资源去系统里将新员工 B 的直接主管从主管 Y 更改为主管 X。

最终，业务部门根据实际的组织架构调整，选择了方案 A，在前台增加了权限记录，凭证流转恢复正常。

运维心得： 很多看似复杂的系统报错，只要理清了底层表结构和系统流转的校验逻辑，用几段简单的 SQL 就能迅速锁定靶心。

目录CONTENT

Oracle EBS 实战排查：GL 日记账“找不到审批人”的底层逻辑剖析