【绩效】绩效考核、绩效档案
绩效考核模块，由 yudao-module-hrm 后端模块的 performance.assessment、portal.performance 包实现，前端实现在 @/views/hrm/performance/assessment 和 @/views/hrm/portal/performance 目录。
绩效考核是绩效计划启动后的运行过程：管理端负责启动计划、开启评分、发起绩效面谈、监控进度和归档；员工端负责指标填写、目标确认、自��� / 他评、结果审核、结果确认和申诉。
绩效流程由 HRM 自己的阶段状态机实现，不复用 BPM。模板与计划配置详见 《【绩效】绩效模板、绩效计划》。
本文涉及表如下图所示：
完整考核流程如下图所示：
# 1. 员工考核
员工考核，由 HrmPerformanceAssessmentController 提供管理端接口（/hrm/performance/assessment），由 HrmPortalPerformanceAssessmentController 提供员工端接口（/hrm/portal/performance/assessment）。
创建计划并确定参评范围时，每名员工会生成一条 hrm_performance_assessment；管理员启动计划后，系统再把计划快照物化为考核维度、指标和阶段，并激活第一个业务节点。
# 1.1 主表表结构
省略 creator/create_time/updater/update_time/deleted/tenant_id 等通用字段，下同
CREATE TABLE `hrm_performance_assessment` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '编号',
`plan_id` bigint NOT NULL COMMENT '绩效计划编号',
`employee_id` bigint NOT NULL COMMENT '被考核员工编号',
`status` tinyint DEFAULT '2' COMMENT '考核状态',
`process_status` tinyint DEFAULT '1' COMMENT '流程状态',
`stage_type` tinyint DEFAULT '0' COMMENT '当前阶段类型',
`stage_sort` int DEFAULT '0' COMMENT '当前阶段排序',
`score` decimal(10,2) DEFAULT '0.00' COMMENT '最终得分',
`result_level` varchar(64) DEFAULT NULL COMMENT '结果等级',
`coefficient` decimal(10,2) DEFAULT '1.00' COMMENT '绩效系数',
`target_confirmation_result` tinyint DEFAULT NULL COMMENT '目标确认结果',
`target_confirmation_comment` varchar(1000) DEFAULT NULL COMMENT '目标确认意见',
`target_confirmation_time` datetime DEFAULT NULL COMMENT '目标确认时间',
`self_comment` varchar(2000) DEFAULT NULL COMMENT '自评评语',
`reviewer_comment` varchar(2000) DEFAULT NULL COMMENT '他评评语',
`result_comment` varchar(2000) DEFAULT NULL COMMENT '结果评语',
`result_confirmation_time` datetime DEFAULT NULL COMMENT '结果确认时间',
`result_audit_status` tinyint DEFAULT NULL COMMENT '结果审核状态',
`result_audit_time` datetime DEFAULT NULL COMMENT '结果审核时间',
`result_audit_reason` varchar(1000) DEFAULT NULL COMMENT '结果审核原因',
`appeal_status` tinyint DEFAULT '0' COMMENT '申诉状态',
`appeal_reason` varchar(1000) DEFAULT NULL COMMENT '申诉原因',
`appeal_file_urls` varchar(2000) DEFAULT NULL COMMENT '申诉附件',
`appeal_submit_time` datetime DEFAULT NULL COMMENT '申诉提交时间',
`appeal_time` datetime DEFAULT NULL COMMENT '申诉处理时间',
`appeal_comment` varchar(1000) DEFAULT NULL COMMENT '申诉处理意见',
`archive_time` datetime DEFAULT NULL COMMENT '归档时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB COMMENT='HRM 员工绩效考核';
① plan_id + employee_id 表达「某个计划中的某名员工」。处理人和被考核人均关联 hrm_employee 表，任务执行时再通过员工的 user_id 校验当前账号。
② status 考核状态与计划状态同步（HrmPerformancePlanStatusEnum），process_status 流程状态（HrmPerformanceAssessmentProcessStatusEnum）区分进行中与已完成，stage_type 当前阶段类型（HrmPerformanceStageTypeEnum）见 §1.3 状态流转。三者含义不同，不能混用。
③ 枚举 target_confirmation_result 目标确认结果（HrmPerformanceConfirmationResultEnum）：0 驳回、1 通过。
④ 枚举 result_audit_status 结果审核状态（HrmPerformanceResultAuditStatusEnum）：1 审核中、2 已通过、3 已驳回、4 已取消。
⑤ 枚举 appeal_status 申诉状态（HrmPerformanceAppealStatusEnum，字典 hrm_performance_appeal_status）：0 无申诉、1 待处理、2 已通过、3 已驳回、4 已取消。同一考核同时只允许一条处理中的申诉。
⑥ 归档不会复制到另一套档案表，只更新计划与考核状态，并写入 archive_time。过程阶段、评分和动作记录继续保留，绩效档案页面直接读取这些数据。
该表包含 6 个运行子表。其中维度、指标和阶段在启动计划时由计划快照物化生成，评分、动作和申诉则在流��推进过程中写入：
| 表 | 关联字段 | 用途 |
|---|---|---|
hrm_performance_assessment_dimension | assessment_id | 计划指标维度快照 |
hrm_performance_assessment_quota | dimension_id | 运行指标、目标值、实际值和汇总分 |
hrm_performance_assessment_stage | assessment_id | 流程节点、处理员工、权重、状态和截止时间 |
hrm_performance_assessment_quota_score | assessment_stage_id | 某个评分阶段对某个指标的原始得分和评语 |
hrm_performance_assessment_action_record | assessment_id | 用户与系统动作，组成流程时间线 |
hrm_performance_assessment_appeal_record | assessment_id | 一次申诉选择重开的评分阶段 |
# 1.2 阶段表结构
hrm_performance_assessment_stage 是考核流程的运行节点，每名参评员工都有自己的一组阶段：
CREATE TABLE `hrm_performance_assessment_stage` (
`id` bigint NOT NULL AUTO_INCREMENT COMMENT '编号',
`assessment_id` bigint NOT NULL COMMENT '员工考核编号',
`type` tinyint NOT NULL COMMENT '阶段类型',
`name` varchar(128) NOT NULL COMMENT '阶段名称',
`handler_employee_id` bigint DEFAULT NULL COMMENT '处理员工编号',
`sort` int NOT NULL DEFAULT '0' COMMENT '排序',
`status` tinyint NOT NULL DEFAULT '0' COMMENT '状态',
`rater_type` tinyint DEFAULT NULL COMMENT '评分人类型',
`weight` decimal(10,2) DEFAULT NULL COMMENT '评分权重',
`scoring_type` tinyint DEFAULT NULL COMMENT '评分方式',
`visible_content` tinyint DEFAULT NULL COMMENT '可见内容',
`required_setting` bit DEFAULT NULL COMMENT '是否必填评语',
`reject_authority` bit DEFAULT NULL COMMENT '是否允许驳回',
`score` decimal(10,2) DEFAULT NULL COMMENT '阶段得分',
`result_level` varchar(64) DEFAULT NULL COMMENT '阶段等级',
`comment` varchar(2000) DEFAULT NULL COMMENT '评语',
`reject_reason` varchar(1000) DEFAULT NULL COMMENT '驳回原因',
`submit_time` datetime DEFAULT NULL COMMENT '提交时间',
`deadline_time` datetime DEFAULT NULL COMMENT '截止时间',
PRIMARY KEY (`id`)
) ENGINE=InnoDB COMMENT='HRM 绩效考核阶段';
① handler_employee_id 关联 HRM 员工，而不是后台账号；系统据此判断任务归属。
② 枚举 status 阶段状态（HrmPerformanceAssessmentStageStatusEnum，字典 hrm_performance_stage_status）：0 未处理、1 已处理、2 待处理、3 已驳回、4 处理中、5 已申诉。
③ deadline_time 主要用于申诉确认节点的超时处理，到期后由 HrmPerformanceAppealTimeoutJob 按计划配置自动通过或自动拒绝。
④ weight 评分权重、scoring_type 评分方式、visible_content 可见内容、reject_authority 是否允许驳回，都是从计划的 review_stages 快照解析而来。
维度、指标、评分、动作和申诉表结构
以下建表语句原样取自 yudao-module-hrm/src/test/resources/sql/create_tables.sql，因此保留单元测试使用的 H2 兼容语法和公共字段。
CREATE TABLE IF NOT EXISTS "hrm_performance_assessment_dimension" (
"id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY,
"assessment_id" bigint NOT NULL,
"name" varchar(255) NOT NULL,
"quota_type" tinyint DEFAULT NULL,
"weight" decimal(10, 2) DEFAULT NULL,
"remark" varchar(255) DEFAULT NULL,
"allow_edit" bit NOT NULL DEFAULT FALSE,
"sort" int NOT NULL DEFAULT 0,
"creator" varchar(64) DEFAULT '',
"create_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updater" varchar(64) DEFAULT '',
"update_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"deleted" bit NOT NULL DEFAULT FALSE,
"tenant_id" bigint NOT NULL DEFAULT 0,
PRIMARY KEY ("id")
);
CREATE TABLE IF NOT EXISTS "hrm_performance_assessment_quota" (
"id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY,
"assessment_id" bigint NOT NULL,
"dimension_id" bigint NOT NULL,
"preset" bit NOT NULL DEFAULT TRUE,
"name" varchar(255) DEFAULT NULL,
"description" varchar(1000) DEFAULT NULL,
"standard" varchar(1000) DEFAULT NULL,
"weight" decimal(10, 2) DEFAULT 100.00,
"score_type" tinyint DEFAULT NULL,
"target_value" varchar(1000) DEFAULT NULL,
"actual_value" varchar(1000) DEFAULT NULL,
"self_score" decimal(10, 2) DEFAULT 0.00,
"reviewer_score" decimal(10, 2) DEFAULT 0.00,
"final_score" decimal(10, 2) DEFAULT 0.00,
"sort" int DEFAULT 0,
"creator" varchar(64) DEFAULT '',
"create_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updater" varchar(64) DEFAULT '',
"update_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"deleted" bit NOT NULL DEFAULT FALSE,
"tenant_id" bigint NOT NULL DEFAULT 0,
PRIMARY KEY ("id")
);
CREATE TABLE IF NOT EXISTS "hrm_performance_assessment_quota_score" (
"id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY,
"assessment_stage_id" bigint NOT NULL,
"assessment_quota_id" bigint NOT NULL,
"score" decimal(10, 2) NOT NULL,
"comment" varchar(1000) DEFAULT NULL,
"creator" varchar(64) DEFAULT '',
"create_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updater" varchar(64) DEFAULT '',
"update_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"deleted" bit NOT NULL DEFAULT FALSE,
"tenant_id" bigint NOT NULL DEFAULT 0,
PRIMARY KEY ("id")
);
CREATE TABLE IF NOT EXISTS "hrm_performance_assessment_action_record" (
"id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY,
"assessment_id" bigint NOT NULL,
"stage_id" bigint DEFAULT NULL,
"employee_id" bigint DEFAULT NULL,
"type" tinyint NOT NULL,
"title" varchar(128) NOT NULL,
"content" varchar(2000) DEFAULT NULL,
"file_urls" varchar(2000) DEFAULT NULL,
"status" tinyint DEFAULT NULL,
"creator" varchar(64) DEFAULT '',
"create_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updater" varchar(64) DEFAULT '',
"update_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"deleted" bit NOT NULL DEFAULT FALSE,
"tenant_id" bigint NOT NULL DEFAULT 0,
PRIMARY KEY ("id")
);
CREATE TABLE IF NOT EXISTS "hrm_performance_assessment_appeal_record" (
"id" bigint NOT NULL GENERATED BY DEFAULT AS IDENTITY,
"assessment_id" bigint NOT NULL,
"stage_id" bigint NOT NULL,
"status" tinyint NOT NULL,
"creator" varchar(64) DEFAULT '',
"create_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"updater" varchar(64) DEFAULT '',
"update_time" timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
"deleted" bit NOT NULL DEFAULT FALSE,
"tenant_id" bigint NOT NULL DEFAULT 0,
PRIMARY KEY ("id")
);
① quota_score 保存每级评分的原始值，quota 保存自评、他评和最终汇总分。最终得分按「维度权重 × 指标权重 × 评分阶段权重」计算。
② action_record.type 动作类型见 HrmPerformanceAssessmentActionTypeEnum，覆盖提交指标、确认 / 驳回目标、提交 / 驳回评分、确认结果、提交申诉、审核与申诉的通过 / 驳回、超时自动处理和终止考核共 14 种，用于渲染流程时间线。
③ appeal_record 保存一次申诉中员工选择重开的评分阶段，状态见 HrmPerformanceAppealRecordStatusEnum：0 未处理、1 已处理。
# 1.3 状态流转
启动计划时，系统依次创建维度和指标、解析流程节点处理人、校验必办处理人已绑定后台账号，并激活首个节点。任一必办人无法解析或未绑定账号，启动失败。
阶段类型枚举 HrmPerformanceStageTypeEnum：
| 状态值 | 枚举 | 阶段 | 主要处理人 |
|---|---|---|---|
| 0 | NOT_STARTED | 未开始 | — |
| 1 | FILL_QUOTA | 员工填写 | 被考核员工 |
| 2 | TARGET_CONFIRM | 目标确认 | 上级、部门负责人或指定员工 |
| 3 | SELF_SCORE | 自评 | 被考核员工 |
| 4 | OTHER_SCORE | 他人评分 | 计划配置的评分员工 |
| 5 | RESULT_AUDIT | 结果审核 | 计划配置的审核员工 |
| 6 | RESULT_CONFIRM | 结果确认 | 被考核员工 |
| 7 | APPEAL_CONFIRM | 申诉确认 | 计划配置的申诉处理员工 |
| 8 | ARCHIVED | 归档 | 系统推进 |
| 9 | EXECUTING | 执行中 | 系统推进 |
| 10 | END | 结束 | 系统推进 |
考核主流程
员工填写(1) ──→ 目标确认(2) ──→ 执行中(9)
（可选） （可选） │ 管理员开启评分
↓
自评(3)/他人评分(4) ──→ 结果审核(5) ──→ 绩效面谈 ──→ 结果确认(6) ──→ 结束(10) ──→ 归档(8)
（可选） （可选）
│
└──员工申诉──→ 申诉确认(7)
│
┌───通过───────┘
↓
重开所选评分阶段 / 驳回则维持原结果
- 员工填写 / 目标确认：仅当计划的指标制定方式为「员工填写」时存在；目标确认还需开启
target_confirmation。 - 执行中 → 自评 / 他人评分：由管理员点击「开启评分」统一激活，不会自动开始。
- 结果审核 / 结果确认：分别由计划的
result_audit、result_confirmation开关控制，可以关闭。 - 申诉确认：员工在结果确认阶段不同意结果时发起，处理人按
appeal_stages逐级解析；超时由 HrmPerformanceAppealTimeoutJob 按appeal_timeout_action自动处理。
# 2. 完整流转
绩效是 HRM 中链路最长的模块，管理端和员工端要交替接力：管理员负责三个开关式动作（启动、开启评分、发起面谈），其余节点都由员工端的处理人完成。本节先把整条链路串起来，具体页面操作见 §3 管理端 和 §4 员工端。
# 2.1 管理端与员工端的接力
管理端 员工端
──────────────────────────────────────────────────────────────
① 启动计划 ─────────────────────────→ ② 制定指标（被考核人）
↓
③ 确认指标（上级）
↓
←──────────────── 全员进入「执行中」 ────┘
④ 开启评分 ─────────────────────────→ ⑤ 自评（被考核人）
↓
⑥ 他人评分（评分人）
↓
⑦ 审核结果（审核人）
↓
←──────────────── ���员评分与审核完成 ────┘
⑧ 发起绩效面谈 ─────────────────────→ ⑨ 确认结果（被考核人）
│
└─不同意─→ ⑩ 确认申诉（申诉处理人）
←──────────────── 全员考核结束 ──────────┘
⑪ 归档 ──→ 沉淀为绩效档案
管理端的三个动作都是批量闸门，必须等全员到位才会解锁：全员进入执行中才显示【开始评分】，全员完成评分与审核才显示【发起绩效面谈】，全员考核结束才显示【归档】。因此只要有一名员工卡住，整个计划就无法推进——这也是 §3.1 运行监控 里「参评员工」页签要支持按当前阶段筛选的原因。
# 2.2 分步对照表
以下是开满所有可选节点的完整配置。实际项目可以在计划中关掉目标确认、结果审核和结果确认，对应步骤会被跳过。
| # | 阶段 | 操作人 | 入口 | 完成后 |
|---|---|---|---|---|
| ① | — | 管理员 | KPI 考核 -> 计划详情【启动】 | 物化指标与阶段，激活首个节点 |
| ② | 员工填写(1) | 被考核人 | 员工端「指标填写」 | 进入目标确认，或直接进入执行中 |
| ③ | 目标确认(2) | 上级 / 指定人 | 员工端「指标确认」 | 通过则进入执行中，退回则回到 ② |
| ④ | 执行中(9) | 管理员 | KPI 考核列表【开始评分】 | 激活首个评分节点 |
| ⑤ | 自评(3) | 被考核人 | 员工端「指标评分」 | 进入下一评分节点 |
| ⑥ | 他人评分(4) | 计划配置的评分人 | 员工端「指标评分」 | 全部评分完成后进入结果审核 |
| ⑦ | 结果审核(5) | 计划配置的审核人 | 员工端「结果审核」 | 逐级通过后等待管理员发起面谈 |
| ⑧ | — | 管理员 | KPI 考核列表【发起绩效面谈】 | 激活结果确认，或直接结束 |
| ⑨ | 结果确认(6) | 被考核人 | 员工端「结果确认」 | 确认则结束，申诉则转 ⑩ |
| ⑩ | 申诉确认(7) | 计划配置的处理人 | 员工端「申诉确认」 | 通过则重开评分，驳回则维持原结果 |
| ⑪ | 归档(8) | 管理员 | KPI 考核列表【归档】 | 写入 archive_time，进入绩效档案 |
⚠️ 注意：①④⑧⑪ 四步是计划级操作，一次作用于全部参评员工；②③⑤⑥⑦⑨⑩ 是员工级任务，每名员工各自推进。
KPI 考核列表会根据不同计划的当前阶段，分别显示【开始评分】【发起绩效面谈】或【归档】操作。
# 2.3 四种回退路径
流程不是只能往前走。HRM 提供了四种回退机制，它们的触发人、影响范围和是否清空评分都不一样，容易混淆：
| 回退 | 触发人 | 触发位置 | 影响范围 | 已有评分 |
|---|---|---|---|---|
| 退回指标 | 目标确认处理人 | 「指标确认」【退回指标】 | 回到被考核人的指标填写 | 尚未开始评分，无影响 |
| 驳回上一阶段 | 当前评分人 | 「指标评分」【驳回上一阶段】 | 只重开上一个已完成评分阶段 | 删除该阶段的指标评分 |
| 结果审核驳回 | 结果审核人 | 「结果审核」选择驳回 | 重开审核人勾选的评分节点 | 只清空被勾选节点，其余保留 |
| 申诉通过 | 申诉处理人 | 「申诉确认」最终通过 | 重开员工申诉时选择的评分节点 | 清空最终得分、等级，系数重置为 1.00 |
┌──退回指标───────────────┐
↓ │
员工填写(1) ──→ 目标确认(2) ─────┘
┌──驳回上一阶段────┐
↓ │
自评(3) ──→ 他人评分(4) ──┴──→ 结果审核(5)
↑ ↑ │
│ └──────结果审核驳回──────────┘
│
└──────────申诉通过──────── 申诉确认(7)
- 退回指标和驳回上一阶段主要重开对应节点；结果审核驳回还会清空主表最终得分、等级、自评评语和评分人评语，把系数重置为 1.00，并清空全部指标的汇总评分，��待重新计算。未勾选节点的原始评分仍保留。
- 申诉通过会额外清空
score、result_level、self_comment和reviewer_comment，并把coefficient重置为 1.00，因为结果已经发给员工看过，必须重新产出。 - 驳回都需要填写原因，写入
hrm_performance_assessment_stage.reject_reason与动作记录，在流程时间线中可追溯。 - 申诉确认节点有
deadline_time，超时后由 HrmPerformanceAppealTimeoutJob 按计划的appeal_timeout_action自动通过或自动拒绝，不会一直挂起。
# 2.4 流程时间线
每一次提交、确认、驳回、申诉和超时自动处理，都会写入一条 hrm_performance_assessment_action_record（类型见 HrmPerformanceAssessmentActionTypeEnum，共 14 种）。管理端考核详情、员工端任务详情和绩效档案详情，都复用同一个 PerformanceProcessRecordTimeline.vue 渲染这条时间线，是排查「这个考核为什么卡住」最直接的入口。
# 3. 管理端
# 3.1 运行监控
对应 [HRM 人力资源 -> 绩效管理 -> KPI 考核] 菜单的计划详情，对应 yudao-ui-admin-vue3 项目的 @/views/hrm/performance/plan/detail 目录。
# 查询参评员工
「参评员工」页签展示当前阶段、处理人、分数和等级，可按姓名、工号或手机号、部门、聘用形式、员工状态、当前阶段和结果等级筛选，同时展示计划的阶段与等级统计。
# 查看员工考核详情
点击员工姓名进入 @/views/hrm/performance/assessment/detail/index.vue，查看考核概况、指标结果、各评分人得分和流程记录。
⚠️ 注意：管理端详情只读，不提供代替员工填写、评分或审核的操作。管理员能做的只有推进计划阶段。
# 推进或终止计划
KPI 考核列表展示整体进度，并按前置条件依次解锁【开始评分】【发起绩效面谈】【归档】；进行中计划也可以从【更多】点击【终止考核】。后端会再次校验状态和进度，终止后保留已经产生的指标、评分、阶段和动作记录，详见 《【绩效】绩效模板、绩效计划》§3.2 状态流转。
# 3.2 绩效档案
计划归档后，可从 [HRM 人力资源 -> 绩效管理 -> 绩效档案] 查询结果，对应 yudao-ui-admin-vue3 项目的 @/views/hrm/performance/assessment 目录。
# 列表
assessment/index.vue 按员工聚合展示最近考核计划、最近评分、最近等级和考核次数，可按员工姓名或工号筛选。列表只统计已归档考核，不会混入仍在运行或已终止的考核。
# 个人档案与单次考核
点击员工姓名进入 assessment/employee/index.vue，查询该员工的历次归档考核，并提供「考核计划」筛选项。点击考核方案名称进入 assessment/detail/index.vue，查看单次考核的指标得分与动作时间线。
# 删除员工全部档案
在绩效档案列表勾选一名或多名员工，点击【批量删除】。该操作需要 hrm:performance:archive:delete 权限，会清理所选员工的全部归档考核，不影响其他员工，也不会处理仍在运行的计划。
# 删除单次档案
进入个人档案后，可删除单次考核或勾选多次批量删除。后端只删除选中的归档记录；若该员工已无档案，页面返回档案列表。
# 4. 员工端
员工端由两个菜单组成：「我的考核」处理进行中的考核任务，「我的绩效档案」查看已归档的历史结果。
任务归属按员工判定
一个账号即使拥有 HR 管理菜单，也只能处理 handler_employee_id 与账号绑定员工相匹配的任务；被考核人的结果确认和申诉同样按当前账号绑定员工校验。
# 4.1 我的考核
对应 [HRM 人力资源 -> HRM 员工端 -> 绩效管理 -> KPI 考核] 菜单，对应 yudao-ui-admin-vue3 项目的 @/views/hrm/portal/performance/assessment 目录。
# 六类任务
页面由 PerformanceTaskTabs.vue 和 PerformanceTaskTable.vue 组合而成，提供六个任务页签，并按待办、已办或已申诉状态展示角标。关键字可匹配姓名、工号或考核名称。
| 任务页签 | 对应阶段 | 处理动作 |
|---|---|---|
| 指标填写 | 员工填写(1) | 制定指标 |
| 指标确认 | 目标确认(2) | 确认通过 / 退回指标 |
| 指标评分 | 自评(3) / 他人评分(4) | 提交评分 / 驳回上一阶段 |
| 结果审核 | 结果审核(5) | 审核通过 / 驳回并重开评分节点 |
| 结果确认 | 结果确认(6) | 确认结果 / 提交申诉 |
| 申诉确认 | 申诉确认(7) | 通过 / 驳回申诉 |
# 制定指标
在「指标填写 -> 待填写」中点击【制定指标】，打开 review/PerformanceQuotaForm.vue。员工只能在 allow_edit = true 的维度新增、修改或删除指标，并必须补足该维度的剩余权重。
提交后：未开启目标确认的考核直接进入执行中；已开启目标确认的考核则激活配置的确认节点。已填写页签仅提供【详情】，不能再次提交。
# 确认指标
在「指标确认 -> 待确认」中点击【去确认】，打开 process/PerformanceTargetConfirmForm.vue。处理人可【确认通过】，也可填写必填原因后【退回指标】。
通过后进入后续阶段；退回后重新激活被考核人的指标填写任务。
# 指标评分
在「指标评分 -> 待评分」中点击【去评分】，打开 review/PerformanceReviewForm.vue，填写每项分数和评语（是否必填由阶段的 required_setting 决定）。
输入变化时会试算最终得分：把已完成阶段与当前未提交分数合并计算，只有评分数据齐备时才展示最终等级。提交后，每个指标写入当前阶段的 hrm_performance_assessment_quota_score。
当前评分节点配置了 reject_authority 时，抽屉还显示【驳回上一阶段】：填写原因并确认后，重开上一已完成评分阶段并删除该阶段的指标评分。
# 审核结果
全部评分完成后，开启了结果审核的考核会进入「结果审核」。处理人点击【去审核】，打开 process/PerformanceHandleForm.vue：选择通过会继续下一级或后续流程；选择驳回时必须勾选需要重开的评分节点，只重开选中的评分阶段，不会清空其他已完成评分。
# 确认结果与提交申诉
管理员发起绩效面谈后，开启结果确认的考核会出现在「结果确认 -> 待确认结果」：
- 接受结果时点击【确认结果】并二次确认。
- 不同意且当前没有处理中申诉时点击【提交申诉】，在
process/PerformanceAppealForm.vue填写必填原因、选择希望重开的评分阶段并按需上传附件。
提交后记录转入「已申诉」，不能重复发起处理中申诉。
# 确认申诉
申诉处理人在「申诉确认 -> 待确认」中点击【去确认】，打开 process/PerformanceHandleForm.vue：
- 中间级通过：流转到下一级申诉处理人。
- 最终通过：清空最终得分、等级、自评评语和评分人评语，把系数重置为 1.00，并重开员工选择的评分阶段。
- 任一级驳回：维持原结果并结束考核。
# 查看考核详情
指标填写、结果确认的记录始终提供【详情】；指标确认、指标评分、结果审核和申诉确认在待办状态只显示对应的处理按钮，进入已办后才显示【查看】。
详情页按 id + stageId 查询与当前任务相匹配的考核、指标和阶段，并展示流程时间线，页面本身只读。
# 4.2 我的绩效档案
对应 [HRM 人力资源 -> HRM 员工端 -> 绩效管理 -> 我的绩效档案] 菜单，对应 yudao-ui-admin-vue3 项目的 @/views/hrm/portal/performance/assessment/history 目录。
# 查询本人档案
计划归档后，页面展示本人的计划周期、最终得分、等级、绩效系数和归档时间，可按考核名称筛选。后端按当前账号绑定员工限制数据范围。
# 查看归档详情
点击【查看】进入详情页，查询指标与评分结果，并加载共用的 PerformanceProcessRecordTimeline.vue 流程时间线。该页面只读，不显示管理端的删除按钮或员工任务处理按钮。
# 5. 定时任务与薪资衔接
① 申诉超时处理：HrmPerformanceAppealTimeoutJob 处理已超过 deadline_time 的申诉节点，按计划的 appeal_timeout_action 自动通过或自动拒绝，并写入动作记录。Job 本身不硬编码执行周期，需要在 [基础设施 -> 定时任务] 中配置。
② 薪资衔接：计划开启 sync_to_salary 并设置 paid_for_month 后，薪资模块只读取已归档考核的绩效系数；同一员工同月命中多个计划时，取最新归档记录。当前系数作为衔接数据提供，不会自动乘入月工资的工资项，详见 《【薪资】月度工资、工资条》。