RuoYi Office 文档

Appearance

SpringBoot+Vue3 绩效考核批次工作台：1个页面收口9个阶段——从建批次到发布归档 ​

🌐 在线演示：https://ruoyioffice.com/web/ | 📦 GitHub：ruoyi-office | 📦 GitCode：ruoyi-office | 📦 Gitee：ruoyi-office | 💬 微信：17156169080（备注「RuoYi Office」） 绩效考核真正难的不是“给员工打分”，而是 HR 在一个批次里要连续处理参与范围、模板匹配、主评关系、目标确认、自评、上级评、校准、结果确认、批次审批和归档。任何一环散落在不同菜单，HR 就只能靠 Excel 和聊天记录追进度。RuoYi Office 把这些动作收口到同一个批次工作台，并用可核对的状态计数回答三个问题：现在到哪一步、还有多少人没完成、下一步能不能操作。 绩效考核批次工作台 - 从草稿预览到发布归档的全景▲ 全景图说明：主链路覆盖“草稿预览→发布→目标确认→自评→上级评→校准→结果确认→批次审批→发布/归档”；下方同步展示 13 项主链路 stageStats 口径，并把 exceptionCount 作为独立异常监控项。

引言：为什么绩效批次需要“工作台”？ ​

绩效批次工作台是以单个考核周期为边界的运营控制面，用于汇总该批次的配置、执行、结果与流程状态。 它不是再造一个统计驾驶舱。 驾驶舱回答“整体绩效表现如何”，工作台回答“这个批次下一步该做什么”。 分散菜单时，HR 常见的操作路径是：

  1. 在周期列表创建批次。
  2. 去计划列表确认是否生成目标。
  3. 去评估关系页面查主评人。
  4. 去个人任务菜单看自评和评审。
  5. 去校准页面查看待办。
  6. 去结果列表生成结果。
  7. 去结果确认单发起批次审批。
  8. 审批后再回周期列表确认发布状态。 菜单本身没有错。 问题在于“一个批次”被拆成了多个局部视角。
典型问题分散页面下的表现工作台收口后的回答
发布前是否有人可参与发布后才发现无人或模板未匹配草稿阶段先预览匹配人数与未匹配人数
主评关系是否完整自评完成后才暴露缺主评发布前预览关系异常，发布后进入异常池
当前卡在哪一环HR 逐页统计状态概览直接展示目标、自评、评审、校准、确认计数
是否可以发批次审批靠人工判断是否齐套后端返回未完成数与可发起标记
发布后是否还能修改缺少明确动作边界只有结果已发布状态允许归档
当前产品没有引入“自动催办”，也没有完整 360 度多角色评价闭环。
真实落地的是以“主评关系”为核心的上级评审链路，以及草稿预览、阶段统计、结果生成、批次审批和归档。
这条边界非常重要：系统能力应该按已经运行的代码描述，而不是按未来蓝图宣传。

一、设计目标：把批次推进变成一条可见主线 ​

1.1 一个批次，九个业务阶段 ​

工作台把批次生命周期整理为九个连续阶段：

序号阶段核心动作数据依据
1草稿预览预览参与人、模板命中与主评关系PerformancePeriodPreviewRespVO
2发布生成计划、计划项与评估关系publishAndGenerate
3目标确认员工确认，或按方案跳过并系统确认requireGoalConfirm
4自评员工逐项评分与说明考核单状态 10
5上级评主评人完成评审考核单状态 20
6校准HR 校准分数、等级与系数考核单状态 30
7结果确认员工确认结果或进入申诉支线状态 40/63
8批次审批所有任务完成后发起结果审批完成状态 50/64
9发布/归档审批通过发布结果，随后归档周期状态 5→6
“九阶段”不是九张新表，也不是九套独立流程。
它是一条围绕周期、计划、考核单、结果和批次结果审批单组织的业务主线。

1.2 三类数据在工作台汇合 ​

工作台加载三组明细：

  • plans：目标确认单，回答目标是否已确认。
  • bills：绩效考核单，回答自评、评审、校准和结果确认进度。
  • results：绩效结果，回答结果是否生成、确认和发布。 另外还有一组评估关系：
  • 草稿状态读取预览关系，不落库。
  • 发布后读取已落库关系。
  • 有异常码的关系进入异常池。 前端通过 Promise.all 并行加载计划、考核单和结果。 页面分页请求上限按后端 PageParam 的 200 条约束设置。 因此当前统计口径是“工作台已加载的本批次明细”。 对于超过 200 人的批次，若后续要做严格全量统计，应将聚合口径下沉到后端专用统计接口。 这是源码边界，而不是可以忽略的细节。

1.3 工作台不替代个人任务页 ​

批次工作台面向 HR 或批次管理人。 个人任务工作台面向员工、主评人和校准办理人。 绩效任务工作台 - 个人待办与已办任务▲ 截图说明：个人任务工作台承接员工自评、上级评审、校准和结果确认的办理；批次工作台只汇总本批次进度并提供详情跳转，不把个人待办口径混入批次统计。 两者分工如下：

视角主要用户回答的问题典型操作
批次工作台HR、绩效管理员某批次整体推进到哪里发布、查异常、生成结果、发批次审批、归档
个人任务工作台员工、主管、HR 办理人我当前有哪些绩效任务自评、上级评、校准、结果确认
绩效驾驶舱管理层、HRBP多批次结果表现如何公司/部门筛选、趋势与分布分析

二、草稿预览：发布前先发现配置问题 ​

2.1 预览不是“假数据”，而是发布模拟 ​

草稿预览会按周期范围查询在职员工。 查询条件可包含公司、部门、岗位、职位和员工状态。 离职与退休员工会被排除。 随后系统为每名员工匹配当前方案下启用的绩效模板。 模板匹配不是只看模板名称，而是按组织与岗位条件逐项判断。 匹配成功后，系统继续预览主评关系。 这意味着 HR 在发布前就能看到：

  • 范围内有多少员工。
  • 有多少员工匹配到模板。
  • 有多少员工没有匹配模板。
  • 预计生成多少条评估关系。
  • 有多少条关系存在异常。
  • 当前方案是否需要目标确认。
  • 发布时是否会自动确认目标。

2.2 预览响应保留了发布决策所需字段 ​

下面是 PerformancePeriodPreviewRespVO 的真实裁剪。 它同时承载参与人、模板和关系预览，不需要前端拼接多个猜测口径。

java
public class PerformancePeriodPreviewRespVO {
    private Long periodId;
    private Integer matchedCount;
    private Integer unmatchedCount;
    private Integer relationCount;
    private Integer abnormalCount;
    /** 关联方案是否需要目标确认：0 跳过 / 1 需要 */
    private Integer requireGoalConfirm;
    /** 发布时是否自动确认目标并生成考核单 */
    private Boolean autoConfirmOnPublish;
    private List<ParticipantItem> participants = new ArrayList<>();
    private List<RelationItem> relations = new ArrayList<>();
    @Data
    public static class ParticipantItem {
        private Long employeeId;
        private String employeeNo;
        private String employeeName;
        private Long deptId;
        private String deptName;
        private Long templateId;
        private String templateName;
        private Boolean matched;
    }
}

这段响应模型对应三个发布前检查点：

  1. matchedCount 为零时，前端禁用发布。
  2. unmatchedCount 大于零时，页面提示这些员工不会生成目标确认单。
  3. abnormalCount 和关系中的异常码用于定位缺主评等问题。

2.3 模板匹配采用“越具体越优先” ​

后端会为符合条件的模板计算匹配分。 部门命中权重高于公司，岗位与职位也会增加匹配分。 最终选择分数最高的模板。 这解决了一个常见冲突： 企业可能同时配置“全公司通用模板”和“研发部门专用模板”。 研发员工同时满足两者时，应优先命中更具体的研发模板。 但预览也明确暴露未命中人员。 系统不会为未命中模板的员工凭空生成空计划。

2.4 草稿态关系只展示，不提前落库 ​

前端 displayRelations 在草稿状态下读取 preview.relations。 这些行使用临时负数 ID，仅用于表格渲染。 页面会标注“发布后落库”。 草稿阶段也不允许直接更换主评人，按钮显示“发布后可改”。 这样做避免了草稿反复调整范围时残留失效关系。 发布完成后，页面切换到真实关系列表，才允许更新主评人。 ​

三、发布批次：一次事务落地计划与关系 ​

3.1 发布不是只改一个状态 ​

publishAndGenerate 的职责是发布并生成执行数据。 它先检查周期仍处于草稿状态，再完成发布配置校验，最后生成绩效计划。 配置校验覆盖：

  • 已选择绩效方案。
  • 周期开始日期不晚于结束日期。
  • 自评截止不早于周期结束。
  • 上级评截止不早于自评截止。
  • 校准截止不早于上级评截止。
  • 结果发布日期不早于校准截止。
  • 方案下存在启用模板。
  • 模板至少配置了指标项。
  • 方案存在启用的等级规则。 这些校验让“发布”成为明确的数据边界。 发布后的批次不再允许按草稿方式编辑。

3.2 计划、指标项、关系按顺序生成 ​

下面是 generatePerformancePlan 的真实裁剪。 它展示了模板匹配、计划项复制、关系生成和目标确认策略的先后顺序。

java
for (EmployeeDO employee : employees) {
    PerformanceTemplateDO template = matchTemplate(templates, employee);
    if (template == null) {
        unmatchedNames.add(StringUtils.defaultIfBlank(
                employee.getName(), String.valueOf(employee.getId())));
        continue;
    }
    List<PerformanceTemplateItemDO> templateItems =
            performanceTemplateItemMapper.selectListByTemplateId(template.getId());
    PerformancePlanDO plan = createOrUpdatePlan(period, employee, template);
    performancePlanItemMapper.deleteByPlanId(plan.getId());
    for (PerformanceTemplateItemDO item : templateItems) {
        performancePlanItemMapper.insert(new PerformancePlanItemDO()
                .setPlanId(plan.getId())
                .setIndicatorId(item.getIndicatorId())
                .setIndicatorName(item.getIndicatorName())
                .setTargetValue(item.getTargetValue())
                .setWeight(item.getWeight()));
    }
    participantCount++;
}
performanceEvalRelationService.generateByPeriod(id);
autoConfirmPlansIfSchemeSkipsGoalConfirm(period.getSchemeId(), id);

真实执行顺序可以概括为：

  1. 按批次范围找到员工。
  2. 为员工匹配模板。
  3. 创建或更新计划。
  4. 将模板指标复制为计划项。
  5. 汇总参与人数。
  6. 生成评估关系并回填计划主评人。
  7. 若方案跳过目标确认，则系统批量确认计划。 评估关系必须先于自动确认。 因为系统确认计划后会创建考核单，而考核单需要使用计划上的主评信息。

3.3 无模板人员不会阻塞所有可用人员 ​

如果部分员工未匹配模板：

  • 已匹配员工正常生成计划。
  • 未匹配员工姓名会写入周期备注并记录警告日志。
  • 页面预览会提前展示未匹配人数。 只有当一个人都无法匹配时，发布才会失败。 这比“有一人配置异常就让整个批次无法发布”更符合大型组织的实际运维方式。 同时，它也保留了异常可追溯性。

四、目标确认可选：需要确认，或发布时自动确认 ​

4.1 目标确认是方案级策略 ​

方案字段 requireGoalConfirm 定义目标是否需要员工确认：

配置值业务含义发布后的行为
1 或空值需要目标确认生成待确认计划，员工确认后生成考核单
0跳过目标确认系统确认计划，并自动生成考核单
默认值按“需要确认”处理。
这避免旧方案缺少字段时意外跳过员工确认。

4.2 跳过确认不是跳过绩效流程 ​

跳过目标确认只省略“员工确认目标”这一环。 它不会跳过：

  • 计划生成。
  • 评估关系生成。
  • 考核单生成。
  • 自评。
  • 上级评。
  • 校准。
  • 结果确认。 后端通过 confirmTargetBySystem 复用计划确认逻辑。 确认后的计划会创建考核单并启动主流程。 前端发布确认框会明确提示： “方案已跳过目标确认，发布后将自动确认并生成考核单与评估关系。”

4.3 自动确认具备幂等保护 ​

系统遍历本批次计划时，会跳过已经确认且存在确认时间的计划。 这样重复执行生成逻辑时，不会把正在考核中的计划状态打回。 “可重试但不倒退”是批量业务操作的重要底线。 ​

五、阶段时间线：日期约束与业务状态分开表达 ​

5.1 六个日期节点 ​

工作台顶部提供六步时间线：

  1. 周期开始。
  2. 周期结束。
  3. 自评截止。
  4. 上级评截止。
  5. 校准截止。
  6. 结果发布。 绩效批次工作台列表 - 批次入口与状态▲ 截图说明：批次列表提供进入工作台的统一入口；批次编码、方案、周期范围、参与人数和状态用于快速定位当前要推进的考核周期。 时间线表达“计划时间”。 周期状态表达“业务进度”。 两者不能混为一谈。 例如，自评截止日期到了，不代表所有员工已经自评完成。 工作台仍然以考核单状态统计实际完成情况。

5.2 日期在草稿阶段维护 ​

工作台提供日期编辑表单。 日期组件统一使用 YYYY-MM-DD。 后端在发布时再次校验时间先后关系。 因此前端日期控件只是交互入口，后端校验才是最终约束。

5.3 当前步骤由周期状态映射 ​

周期状态映射到时间线高亮：

  • 草稿：停在起点。
  • 已发布或目标确认阶段：进入周期执行。
  • 考核进行中：推进到自评相关阶段。
  • 待校准：高亮校准。
  • 待确认：高亮结果发布前阶段。
  • 已发布或已归档：时间线完成。 这不是定时任务自动推进。 它是当前周期状态的可视化映射。

六、13 项主链路统计 + 1 项异常计数 ​

6.1 为什么不是一句“完成率” ​

单一完成率会掩盖卡点。 10 个人的批次，5 人待自评、5 人待校准，总完成率可能看起来一样，但处理责任完全不同。 工作台因此按阶段拆分统计。 PeriodStageStats 在源码中共有 14 个字段。 其中 exceptionCount 是独立异常监控项。 其余 13 个字段构成主链路统计口径。

6.2 真实统计字段 ​

类别字段计算口径
关系relationCount当前预览或已落库评估关系总数
异常exceptionCount有 exceptionCode 的关系数，独立于主链路
目标planTotal本批次加载的计划总数
目标planPendingConfirm计划状态等于 1
目标planConfirmed计划状态大于等于 2
考核billTotal本批次加载的考核单总数
考核waitSelfReview考核单状态 10
考核waitLeaderReview考核单状态 20
考核waitCalibration考核单状态 30
考核waitResultConfirm考核单状态 40 或 63
考核billFinished考核单状态 50 或 64
结果resultTotal本批次结果总数
结果resultPendingConfirm结果状态 1
结果resultPublished结果状态大于等于 3
如果按用户可见主链路统计，就是 13 项。
如果按 TypeScript 接口字段总数，就是 14 项。
两种说法并不冲突，前提是明确异常计数单列。

6.3 状态归类代码 ​

下面是 stage-stats.ts 中最核心的真实裁剪。 它将考核单状态归入互斥阶段，避免同一张单重复计数。

typescript
let waitSelfReview = 0;
let waitLeaderReview = 0;
let waitCalibration = 0;
let waitResultConfirm = 0;
let billFinished = 0;
for (const bill of bills) {
  const status = bill.status ?? 0;
  if (status === 10) {
    waitSelfReview += 1;
  } else if (status === 20) {
    waitLeaderReview += 1;
  } else if (status === 30) {
    waitCalibration += 1;
  } else if (status === 40 || status === 63) {
    waitResultConfirm += 1;
  } else if (status === 50 || status === 64) {
    billFinished += 1;
  }
}

63 是申诉结果确认阶段。 64 是申诉完成。 因此批次工作台的“结果确认”和“已完成”统计兼容申诉支线终态。 但本文不把申诉展开成主角。 工作台的核心仍是批次主链路收口。

6.4 进度条如何计算 ​

前端使用： Math.round((part / total) * 100) 当总数为零时直接返回零，避免除零和 NaN。 目标确认进度以 planConfirmed / planTotal 计算。 各考核环节以阶段人数除以 billTotal。 结果进度以 resultPublished / resultTotal 计算。 绩效批次工作台概览 - 阶段统计与进度▲ 截图说明：概览同时显示评估关系、异常关系、目标确认单、考核单，以及待自评、待评审、待校准、待结果确认、已完成和绩效结果分布；每个数字都能回到计划、考核单或结果明细。

6.5 统计和操作必须使用同一状态源 ​

工作台顶部的提示语也读取 stageStats：

  • 进行中展示待目标确认、待自评、待评审。
  • 待校准展示 waitCalibration。
  • 待确认展示 waitResultConfirm。
  • 已发布提示可以归档。 这样可以避免“卡片显示 3 人待确认，但按钮提示 2 人”的口径漂移。

七、从自评到结果确认：考核单承载节点推进 ​

7.1 考核单是执行阶段主线 ​

计划确认后，系统创建 PerformanceAssessmentBillDO。 初始状态为待自评：

  • status = 10
  • currentNodeKey = self_review
  • 当前处理人为被考核员工 创建完成后启动主流程。 主流程以被考核人的系统用户身份发起。 这样自评任务不会错误落到发布批次的管理员名下。

7.2 四个主要节点 ​

节点 key页面名称状态变化主要办理人
self_review自评填报10→20被考核员工
leader_review评审填报20→30主评人
hr_calibration校准填报30→40校准办理人
result_confirm结果确认40→50被考核员工
自评提交时，系统校验每个计划项都必须有分数和说明。
上级评提交后，当前节点推进到校准。
校准提交后，系统生成或刷新原始结果，并进入结果确认。
员工确认后，考核单进入完成状态。

7.3 业务状态优先，流程任务做同步 ​

真实实现中，业务 API 会先推进 currentNodeKey 和业务状态。 随后尝试同步办结同名流程任务。 如果流程任务因运行环境或许可等原因暂未同步，日志记录告警，但业务状态不会被旧流程任务覆盖回退。 这项处理解决了一个典型问题： 员工明明已经提交自评，页面却仍显示“自评填报”。 工作台统计以业务考核单状态为准，因此不会被滞后的流程展示拖回上一阶段。

7.4 主评关系决定评审办理人 ​

员工提交自评后，系统优先使用考核单上的 leaderUserId。 如果为空，再从本批次评估关系查询主评人。 这就是为什么发布前预览和发布后异常池很重要。 主评关系不是装饰信息，而是上级评任务的办理依据。 当前版本围绕一个“主评人”完成上级评。 它没有宣称已经实现同事、下属、跨部门等完整 360 度多角色加权评价。 ​

八、生成结果：把过程分数收口成结果记录 ​

8.1 工作台提供显式“生成结果” ​

在周期状态 1～4 之间，结果 Tab 显示“生成结果”按钮。 点击后调用按周期生成绩效结果接口。 弹窗明确提示： “按当前目标确认与考核数据生成本批次绩效结果；已有结果将被覆盖计算。” 这让 HR 能在发起批次审批前主动刷新结果。

8.2 校准时也会刷新个人结果 ​

校准提交会调用 refreshBillFinalResult。 结果记录包含：

  • 周期与计划。
  • 员工、公司和部门。
  • 最终得分。
  • 等级。
  • 系数。
  • 结果类型与状态。
  • 发布、签字和薪资同步状态。
  • 结果快照。 因此“生成结果”不是第一次出现结果的唯一入口。 它更像按批次重新聚合和补齐。

8.3 结果明细和确认环节并列展示 ​

工作台结果 Tab 上半部分展示绩效结果。 下半部分展示处于结果确认相关状态的考核单。 这解决了两个不同问题：

  • 结果表回答“算出了什么”。
  • 考核单回答“员工确认到哪一步”。 不能只看结果条数就判断批次已经完成。

九、发起批次结果审批：完成齐套才允许提交 ​

9.1 前后端双重门禁 ​

工作台根据周期详情中的两个字段控制批次审批按钮：

  • unfinishedAssessmentTaskCount
  • canStartBatchResultApproval 后端按本周期考核单总数和完成数计算。 完成状态只认 50 和 64。 如果没有考核单，或者完成数少于总数，不能发起。 前端禁用按钮只是交互提示。 提交结果审批单时，后端会再次执行完成校验。

9.2 审批前会重新生成并聚合结果 ​

结果审批单预览与保存共用 aggregatePeriodResults。 它会先按周期生成结果，再计算：

  • 员工人数。
  • 平均分。
  • 绩效金额合计。
  • 等级分布。
  • 考核单总数与完成数。 这保证审批人看到的是发起时的最新批次结果，而不是旧缓存。

9.3 审批通过才发布整批结果 ​

下面是 PerformanceResultConfirmBillServiceImpl 的真实裁剪。 审批通过回调发布结果，并把周期推进到状态 5。

java
@Override
@Transactional(rollbackFor = Exception.class)
public void onProcessApproved(String businessKey) {
    Long id = Long.parseLong(businessKey);
    PerformanceResultConfirmBillDO bill =
            performanceResultConfirmBillMapper.selectById(id);
    if (bill == null) {
        return;
    }
    performanceResultService.publishPerformanceResultsByPeriod(
            bill.getPeriodId());
    performancePeriodMapper.updateById(
            new PerformancePeriodDO()
                    .setId(bill.getPeriodId())
                    .setStatus(5));
}
private void validateAssessmentTasksFinished(Long periodId) {
    long total = performanceAssessmentBillMapper
            .selectCountByPeriodId(periodId);
    long finished = performanceAssessmentBillMapper
            .selectCountByPeriodIdAndStatuses(periodId, List.of(50, 64));
    if (total <= 0 || finished < total) {
        throw exception(PERFORMANCE_RESULT_CONFIRM_BILL_TASK_UNFINISHED);
    }
}

这里有两个清晰边界：

  1. 创建结果不等于发布结果。
  2. 发起审批不等于审批通过。 只有流程审批通过，整批结果才正式发布。

十、发布后归档：给活动批次一个明确终点 ​

10.1 只有状态 5 可以归档 ​

工作台的归档按钮仅在周期状态等于 5 时可用。 后端 validateCanArchive 也执行相同校验。 归档后周期状态更新为 6。 这意味着：

  • 草稿不能归档。
  • 进行中不能归档。
  • 待校准或待确认不能归档。
  • 结果审批尚未通过不能归档。
  • 结果已发布后才允许归档。

10.2 归档不是删除 ​

归档保留：

  • 周期信息。
  • 计划和计划项。
  • 评估关系。
  • 考核单。
  • 评分与校准记录。
  • 绩效结果。
  • 批次结果审批单。 页面提示“批次已归档，仅供查阅”。 归档的价值是把批次从活动集合移出，同时保留审计与复盘数据。

10.3 删除只属于干净草稿 ​

后端删除周期要求状态仍为草稿。 如果已经存在计划、结果或已发起的结果审批单，也不能删除。 因此生命周期的末端动作是归档，不是删除。 ​

十一、前端工作台的交互设计 ​

11.1 顶栏只保留三个主动作 ​

顶栏主动作是：

  • 发布。
  • 批次审批。
  • 归档。 刷新预览、重新生成关系、刷新页面和返回列表放在“更多”中。 主按钮数量少，能让 HR 更容易判断下一步。 每个按钮都由真实状态控制，不是始终可点后再报错。

11.2 一个提示条解释当前状态 ​

progressTip 根据周期状态生成提示。 草稿时显示匹配人数、未匹配人数和目标确认策略。 进行中显示异常关系和各阶段待办。 待校准、待确认、已发布、已归档分别给出下一步。 提示条不是自动催办。 它只把当前数据翻译成可操作说明。

11.3 七个 Tab 收纳明细 ​

Tab展示内容可执行动作
概览阶段统计、进度条、当前提示判断下一步
评估关系草稿预览或落库关系刷新预览、重生成、发布后更换主评
异常池带异常码的关系更换主评
目标确认本批次计划查看计划详情
自评状态 10 的考核单查看考核单
评审状态 20 的考核单查看考核单
结果结果明细与确认环节考核单生成结果、查看详情
校准人数在概览中统计。
实际校准办理仍通过对应任务入口完成。
工作台没有伪造一个未经实现的批量校准按钮。

11.4 草稿与发布后使用不同数据源 ​

loadRelations 会先判断是否草稿：

  • 草稿：调用参与人预览接口，清空已落库关系列表。
  • 非草稿：清空预览数据，读取周期评估关系。 刷新时必须先加载周期状态，再决定读取哪种关系。 代码中明确采用： await loadPeriod(); 然后并行加载关系和阶段明细。 这个顺序避免页面从草稿发布后仍读旧预览。

十二、能力边界：本文没有写进不存在的功能 ​

12.1 当前没有自动催办 ​

工作台展示待办数量和阶段提示。 当前产品没有实现定时短信、站内信或企业微信自动催办。 因此不能把“可看见待办”宣传成“自动催办”。

12.2 当前不是完整 360 度评价 ​

当前评估关系重点是主评人。 考核单主线是员工自评与上级评。 虽然数据模型可以继续扩展多角色关系，但当前页面和服务没有形成完整的同事评、下属评、跨部门评与多角色权重汇总闭环。

12.3 当前批次统计受分页上限影响 ​

前端每类明细请求 pageSize: 200。 常规中小批次可以直接使用。 超大批次需要后端聚合接口，才能保证统计不受前端分页影响。

12.4 归档是状态封存，不是数据冷存储 ​

归档把周期状态推进到 6。 它没有把历史数据迁移到独立归档库。 历史记录仍在业务表中查询。 ​

十三、技术亮点总结 ​

设计点真实实现业务价值
草稿预览参与人、模板、关系一次返回发布前发现配置问题
精确模板匹配公司/部门/岗位/职位条件评分通用模板与专用模板可并存
发布生成事务周期、计划、计划项、关系统一生成避免半发布状态
目标确认开关requireGoalConfirm适配“需确认”和“直接下达”
系统自动确认confirmTargetBySystem跳过确认时仍复用完整后续流程
阶段时间线六个业务日期节点计划时间一屏可见
阶段统计13 项主链路 + 1 项异常计数卡点可量化
业务状态优先currentNodeKey 与状态推进避免流程任务滞后造成页面回退
结果显式生成按周期刷新结果审批前确保结果最新
批次审批门禁只认完成状态 50/64未齐套不能发布
审批回调发布onProcessApproved计算与正式发布解耦
发布后归档周期状态 5→6活动批次有明确终点

十四、快速体验 ​

14.1 在线体验 ​

演示地址：https://ruoyioffice.com/web/账号：admin密码：admin123建议路径：HRM 人力资源 → 绩效管理 → 考核周期 → 批次工作台

14.2 推荐体验步骤 ​

  1. 新建一个草稿绩效批次，选择绩效方案和组织范围。
  2. 进入批次工作台，查看参与人数、模板匹配和评估关系预览。
  3. 检查未匹配模板人数和异常关系。
  4. 确认阶段时间线中的六个日期顺序。
  5. 发布批次，观察计划、计划项与评估关系落库。
  6. 分别测试“需要目标确认”和“跳过目标确认”的方案。
  7. 从个人任务工作台完成自评、上级评、校准和结果确认。
  8. 回批次工作台查看阶段计数变化。
  9. 在结果 Tab 生成本批次结果。
  10. 所有考核单完成后，发起批次结果审批。
  11. 审批通过后确认周期状态变为结果已发布。
  12. 最后执行归档，确认批次进入只读查阅状态。

14.3 本地启动 ​

后端使用 Spring Boot 3.5，前端使用 Vue3 与 TypeScript。

powershell
cd ruoyi-office
mvn -P boot -DskipTests compile
powershell
cd ruoyi-office-vben
pnpm dev:antd

14.4 源码入口 ​

平台地址说明
GitHubhttps://github.com/yuqing2026/ruoyi-office查看后端工程与版本历史
GitCodehttps://gitcode.com/zhouzhongyan/ruoyi-office国内网络访问入口
Giteehttps://gitee.com/yqzy1688/ruoyi-office镜像与交流入口
基础能力、扩展模块、授权范围和商业支持请以仓库说明与咨询结果为准。
本文不宣称所有模块都免费开源。

十五、适合推广到哪些业务 ​

“批次工作台”不是绩效专属 UI。 只要业务具备“批次 + 多参与人 + 多阶段 + 最终发布”结构，都可以复用这套设计：

  • 年度人才盘点。
  • 员工能力测评。
  • 试用期批量转正评估。
  • 供应商年度考评。
  • 项目里程碑验收。
  • 培训考试批次。
  • 奖金分配确认。 可复用的核心不是某个按钮，而是四个抽象：
  1. 发布前预览。
  2. 发布后生成执行数据。
  3. 按状态聚合阶段进度。
  4. 结果审批通过后发布并归档。

常见问题（FAQ） ​

1. 绩效批次工作台和绩效驾驶舱有什么区别？ ​

批次工作台面向单个周期的执行推进，关注参与人、关系异常、目标确认、自评、评审、校准、确认、审批和归档。 绩效驾驶舱面向跨批次分析，关注公司、部门、平均分、等级分布等管理指标。

2. 发布批次前能看到哪些问题？ ​

可以看到参与人匹配数、未匹配模板人数、预计评估关系数、异常关系数，以及方案是否要求目标确认。 匹配人数为零时不能发布。

3. 跳过目标确认会不会跳过员工自评？ ​

不会。 系统只自动完成目标确认并生成考核单，后续自评、上级评、校准和结果确认仍按正常流程执行。

4. 为什么工作台写“13 项统计”，源码接口却有 14 个字段？ ​

源码接口有 14 个字段。 其中 13 个属于关系、目标、考核和结果主链路，exceptionCount 是单独的异常关系监控项。 本文按“13 项主链路 + 1 项异常计数”准确表述。

5. 系统是否已经支持自动催办和完整 360 评价？ ​

当前产品没有实现自动催办。 当前真实主线是员工自评、主评人上级评、HR 校准和结果确认，也不应描述为完整 360 度多角色加权评价。

6. 什么时候可以归档绩效批次？ ​

只有批次结果审批通过、绩效结果正式发布、周期状态为 5 时才能归档。 归档后状态为 6，历史计划、考核单、结果和审批记录仍保留。 ​

结语 ​

绩效批次工作台的价值，不是把所有页面机械塞进一个大页面。 它真正完成了三件事： 第一，发布前用预览暴露参与人、模板和关系问题。 第二，发布后用 13 项主链路统计和 1 项异常计数持续量化进度。 第三，用“结果生成→批次审批→审批通过发布→归档”把批次收口到明确终态。 从产品设计看，这是一种“以业务对象为中心”的导航方式。 HR 不必记住每个功能在哪个菜单，只需要进入当前批次，查看状态并执行下一步。 从工程实现看，它没有绕过原有计划、考核单、结果和流程服务，而是把这些能力编排到一个统一操作面。 这让工作台既能快速落地，也能保持状态来源一致。 如果你的系统也有“功能都做了，但运营人员仍靠 Excel 追进度”的问题，可以先问一句： 是不是缺少一个围绕批次、项目或订单的全生命周期工作台？ 欢迎在评论区交流：你们的绩效考核最容易卡在目标确认、自评、主管评审，还是结果发布？ ​

💡 想实际体验绩效考核批次工作台？

🌐 在线演示：https://ruoyioffice.com/web/（账号 admin / 密码 admin123）

📦 源码仓库：GitHub | GitCode | Gitee

💬 产品与技术咨询：添加微信 17156169080，备注「RuoYi Office」

⭐ 如果这篇真实源码拆解对你有帮助，欢迎收藏、转发并关注后续 HRM 专题。

联系我们

获取报价、演示和二开方案

微信咨询二维码

微信咨询

17156169080

添加时备注「RuoYi Office」

在线体验商业版