薪酬管理整体设计方案

文档说明

生成日期：2026-04-18
适用范围：ruoyi-office 人力资源模块薪酬管理功能整体设计
文档用途：作为薪酬管理一期建设蓝图，用于指导后续后端、PC 端、UniApp 移动端、BPM 流程、菜单权限与数据建模的统一实现

设计目标：在现有人力模块已具备组织架构、人事档案、人事异动、考勤、假期、招聘管理能力的基础上，补齐薪酬管理功能，并形成“薪资规则配置 -> 员工薪资档案 -> 月度核算 -> 审批确认 -> 发薪登记 -> 工资条发布 -> 台账归档”的业务闭环。

一、产品定位与设计原则

1.1 产品定位

本产品的薪酬管理定位不是独立薪资 SaaS，也不是大型集团薪酬中台，而是企业一体化 HRM 平台中的薪酬子域。因此整体设计应服务以下目标：

与组织架构、人事档案、人事异动、考勤、假期、招聘、后续绩效模块天然打通。
面向中国本地化中型企业，优先支撑月度发薪闭环与常见合规场景。
兼顾通用性与可扩展性，既能支撑标准白领月薪场景，也为后续制造业计时计件、提成奖金、复杂成本分摊预留扩展空间。

1.2 设计原则

复用优先：复用现有 HRM + BPM + 字典 + 附件 + UniApp 审批 架构，不引入独立薪酬技术框架。
闭环优先：一期优先跑通标准月结闭环，而不是先做复杂分析或外部直连。
规则与结果分离：规则可持续调整，期间核算结果必须快照化、可追溯。
主数据统一：组织、员工、部门、岗位、公司、字典、流程状态均复用现有平台基础能力。
PC 主操作、移动端补协同：复杂配置、批量核算与异常处理以 PC 为主，移动端优先支持工资条查看和审批协同。

二、一二期边界划分

2.1 一期范围

一期围绕标准薪酬闭环建设，包含以下能力：

薪酬主体管理
薪酬方案管理
薪资项目管理
计薪规则管理
社保公积金规则管理
个税规则管理
员工薪资档案
调薪申请与审批
月度薪资批次
数据准备与试算
异常校验与确认
发薪登记
工资条发布与员工查看
薪资台账与基础人工成本统计

2.2 二期范围

二期作为增强能力扩展：

离职结薪批次
补发追扣批次
与绩效考核的深度联动
复杂提成、计件、佣金
多主体复杂成本分摊
预算控制、调薪沙盘、薪酬带宽分析
银行报盘、税局/社保平台深度对接

2.3 一期明确不做

为保证一期交付聚焦，以下内容不纳入一期：

银行直连自动发薪
税局接口直报与社保公积金官方平台直连
多国家、多币种、多税制薪酬
复杂销售激励与制造业计件工资中台
全量 BI 大屏和预算体系

三、业务总体蓝图

3.1 核心闭环说明

HR 先维护薪酬主体、方案、项目和规则。
员工入职或录用转入时，生成员工薪资档案初始版本。
转正、调岗、调级、调薪、离职等人事事件驱动薪资档案版本变更。
月度薪资批次汇总档案、考勤、假期、绩效、导入项等期间数据。
系统完成试算并输出异常项。
HR 完成校验后发起薪资确认审批。
审批通过后登记发薪，并发布工资条。
期间结果形成台账快照，支撑后续追溯和统计分析。

四、领域模型设计

4.1 子域划分

薪酬管理建议拆分为五个子域：

薪酬设置域：管理薪酬主体、方案、薪资项目、计薪规则、社保公积金和个税规则。
薪资档案域：管理员工定薪、调薪、停薪复薪、生效版本、专项扣除等信息。
薪资核算域：管理月度批次、数据准备、试算、异常校验、确认和发薪。
员工服务域：管理工资条模板、发布、签收、我的工资查看。
统计台账域：管理薪资明细快照、部门成本、异常台账和导出报表。

4.2 核心对象

4.2.1 薪酬主体

建议命名：SalarySubject

职责：

标识发薪主体、纳税主体、社保公积金缴纳主体
关联公司、法人、发薪账户
作为薪酬方案和薪资批次的组织边界

4.2.2 薪酬方案

建议命名：SalaryPlan

职责：

管理发薪周期、计薪口径、适用组织和员工类型
绑定薪资项目、计薪规则、社保公积金和个税规则
作为员工薪资档案的规则来源

4.2.3 薪资项目

建议命名：SalaryItem

职责：

管理应发、应扣、实发、公司成本相关项目
支撑固定项、公式项、导入项、系统取数项等类型
控制核算顺序和工资条显示顺序

建议首期标准项目：

基本工资
岗位工资
绩效工资
固定补贴
加班费
缺勤扣款
其他应发
社保个人
公积金个人
个税
其他应扣
实发工资
公司社保
公司公积金
人工成本

4.2.4 计薪规则

建议命名：SalaryRule

职责：

定义项目计算方式、计算顺序、取整方式、上下限和启用状态
管理固定值、公式模板、外部取数、条件适配
统一承接假期计薪比例、缺勤扣款、加班口径等参数

4.2.5 员工薪资档案

建议命名：EmployeeSalaryArchive

职责：

作为员工薪酬主档
记录员工所属薪酬主体、方案、发薪方式、银行卡、专项扣除等基础信息
挂接当前生效的薪资版本

4.2.6 员工薪资版本

建议命名：EmployeeSalaryArchiveVersion

职责：

记录每次定薪、调薪、转正定薪、岗位变更定薪的生效版本
管理生效日期、失效日期、固定工资项和补贴项
支撑期间回溯和历史对比

4.2.7 调薪申请单

建议命名：SalaryChangeBill

职责：

管理员工调薪申请、审批、生效日期与变更原因
审批通过后驱动薪资档案版本更新
与现有人事调动中的“调薪”场景逐步收口

4.2.8 薪资批次

建议命名：SalaryBatch

职责：

管理期间、主体、批次类型、状态、负责人、审批状态
作为月度核算、补发追扣、离职结薪等批次容器
锁定本次核算的规则快照和输入快照

4.2.9 薪资明细

建议命名：SalaryBatchEmployee

职责：

记录员工在某薪资批次下的项目明细、应发应扣、实发和公司成本
保存异常标签、计算日志摘要和结果快照
作为工资条和统计报表的数据来源

4.2.10 薪资确认单

建议命名：SalaryPayrollConfirmBill

职责：

管理批次确认审批与发薪前审核
固化批次确认口径、审批意见和审批链路
审批通过后允许发薪登记和工资条发布

4.2.11 工资条

建议命名：SalaryPayslip

职责：

面向员工展示脱敏后的薪资结果
记录发布时间、查看状态、签收状态
支撑 PC 端和移动端自助查询

4.3 状态机建议

4.3.1 薪资档案状态

草稿
生效中
已失效

4.3.2 调薪单状态

草稿
审批中
审批通过
已生效
审批拒绝
已撤回
已取消

4.3.3 薪资批次状态

草稿
数据已准备
试算完成
异常处理中
待审批
已确认
已发薪
已归档

五、菜单与页面设计

5.1 PC 端菜单建议

建议在 hrm 下新增 salary 子域，拆分为以下菜单：

薪酬设置
员工薪资档案
调薪管理
薪资核算
工资条管理
薪资统计

建议页面路径：

views/hrm/salary/setting/subject
views/hrm/salary/setting/plan
views/hrm/salary/setting/item
views/hrm/salary/setting/rule
views/hrm/salary/setting/social-rule
views/hrm/salary/setting/tax-rule
views/hrm/salary/archive
views/hrm/salary/change-bill
views/hrm/salary/batch
views/hrm/salary/payslip
views/hrm/salary/statistics

5.2 页面形态建议

配置类页面：复用普通 CRUD index.vue + data.ts + modules/form.vue 模式
薪资档案：复用 list + info 独立页模式
调薪单：复用 BPM list + info 模式
薪资批次：采用“列表 + 批次详情”管理形态，详情页内承载批次汇总、员工明细、异常处理和发布动作
工资条：后台支持列表和发布管理，员工端支持查看与签收

5.3 UniApp 范围建议

移动端首期仅支持以下能力：

我的工资条
调薪审批/查看
薪资确认单审批/查看

移动端首期不承载：

薪酬设置
员工薪资档案维护
批量试算
异常处理台账

六、与现有模块的打通设计

6.1 招聘与入职

录用审批中的薪资方案引用、薪资说明仅作为录用口径。
入职单审批通过后，除创建员工档案外，还应同步初始化员工薪资档案。
入职阶段支持填写试用期薪资、转正后薪资、固定补贴、发薪账户等基础信息。

6.2 人事异动

转正：可触发薪资版本切换，例如试用期工资转正式工资。
调岗、调级、调公司：驱动薪资方案、薪资主体或固定项变化。
调薪：建议从泛人事调动中逐步沉淀为独立 SalaryChangeBill。
离职：进入离职结薪口径，首期先预留接口，二期形成独立结薪批次。

6.3 考勤与假期

薪酬不直接读取原始打卡记录，而应读取已结算的考勤结果。
假期规则中的带薪属性和薪酬比率直接作为计薪规则输入。
缺勤、病假、事假、加班、补卡影响需沉淀为标准薪资输入项。
薪酬批次在取数时应锁定期间口径，避免数据在审批过程中反复波动。

6.4 绩效

一期以“导入/接口取数”方式接入绩效工资。
二期再与绩效模块做强绑定，支持自动奖金项、调薪建议和绩效分布分析。

6.5 组织与权限

薪酬主体与组织公司可一一映射，也需支持一个组织下多发薪主体的扩展。
所有薪酬页面需控制数据权限和字段脱敏。
工资条应默认按员工本人可见，HR 和财务按权限角色查看。

七、BPM 设计策略

7.1 一期建议新增的 BPM 单据

建议一期新增两个核心 BPM 单据：

HRM_SALARY_CHANGE_BILL
- 作用：调薪申请、审批、定生效日
- 结果：审批通过后生成新的薪资档案版本
HRM_SALARY_PAYROLL_CONFIRM_BILL
- 作用：月度薪资确认、发薪审批
- 结果：审批通过后允许批次进入发薪登记与工资条发布

7.2 可选方案

薪资档案初始化 不建议单独做 BPM 单据，优先由入职单审批通过后直接驱动档案初始化。

7.3 BPM 复用策略

后端复用现有 HRM 流程单据模式：

在 HrmBillTypeEnum 中新增薪酬单据枚举
在 service/salary/ 下实现 FlowBillService
通过 HrmFlowBillServiceFactory 统一注册
使用现有 bill_code + process_instance_id + process_status 通用字段

前端复用现有 BPM 表单模式：

列表页使用 useVbenVxeGrid
详情页使用 BasicForm
通过 computeBusinessFormReadonly 控制只读
审批节点继续使用字段权限动态控制能力

八、数据模型建议

8.1 表结构总原则

BPM 单据主表遵循现有 HRM 流程单据规范。
配置与结果分表设计，避免核算结果受后续规则变更影响。
期间结果必须保留快照字段，不依赖运行时重新拼装。
员工薪资结构采用“主表 + 版本表 + 明细项表”设计，便于回溯。
附件统一走 AttachmentService，不在业务主表保存 URL 字符串。

8.2 建议核心表

8.2.1 配置类

hrm_salary_subject
hrm_salary_plan
hrm_salary_plan_item
hrm_salary_rule
hrm_salary_social_rule
hrm_salary_tax_rule

8.2.2 主数据类

hrm_employee_salary_archive
hrm_employee_salary_archive_version
hrm_employee_salary_archive_item

8.2.3 业务批次类

hrm_salary_change_bill
hrm_salary_payroll_confirm_bill
hrm_salary_batch
hrm_salary_batch_employee
hrm_salary_batch_employee_item
hrm_salary_payslip

8.3 关键字段建议

8.3.1 `hrm_employee_salary_archive`

建议字段：

employee_id
employee_name
company_id / company_name
dept_id / dept_name
salary_subject_id
salary_plan_id
current_version_id
pay_method
bank_name
bank_account
tax_city
social_city
housing_fund_city
status

8.3.2 `hrm_employee_salary_archive_version`

建议字段：

archive_id
version_no
effective_date
expire_date
source_type
source_bill_id
salary_structure_json
remark
status

8.3.3 `hrm_salary_batch`

建议字段：

batch_code
batch_name
salary_subject_id
period_year
period_month
batch_type
data_prepare_status
calc_status
approve_status
pay_status
employee_count
total_payable
total_deduct
total_actual
remark

8.3.4 `hrm_salary_batch_employee`

建议字段：

batch_id
employee_id
employee_name
company_id / company_name
dept_id / dept_name
archive_version_id
work_days
attendance_days
payable_amount
deduct_amount
actual_amount
company_cost_amount
exception_flag
exception_tags
calc_snapshot_json

九、月度核算流程设计

9.1 数据准备

月度薪资批次的数据准备建议分为六类输入：

员工基础信息：在职状态、组织信息、入转调离结果
薪资档案信息：生效版本、固定工资项、补贴项
考勤结果：应出勤、实出勤、迟到早退、缺勤、加班
假期结果：请假类型、天数、薪酬比率、是否计薪
绩效结果：绩效工资、奖金、系数
导入项：其他应发应扣、补发、追扣

9.2 试算顺序建议

固定工资项
按出勤折算项
假期计薪项
加班项
绩效项
导入应发项
导入应扣项
社保公积金个人部分
个税
实发工资
公司社保公积金与人工成本

9.3 异常校验建议

首期建议支持以下异常：

员工无薪资档案
批次期间找不到生效版本
考勤数据缺失
假期数据异常
金额突增或突减
实发为负数
社保公积金规则缺失
个税规则缺失
同一员工重复入批次

十、实现建议与落地顺序

10.1 后端落地建议

在 yudao-module-hrm 下新增：

controller/admin/salary/
service/salary/
dal/dataobject/salary/
dal/mysql/salary/
convert/salary/
controller/admin/salary/vo/

实现顺序建议：

先建配置类和薪资档案
再建调薪单 BPM
再建薪资批次和试算
最后补工资条和统计

10.2 Web 前端落地建议

在 ruoyi-office-vben/apps/web-antd/src/ 下新增：

api/hrm/salary-subject/
api/hrm/salary-plan/
api/hrm/salary-item/
api/hrm/salary-rule/
api/hrm/employee-salary-archive/
api/hrm/salary-change/
api/hrm/salary-batch/
api/hrm/salary-payslip/

页面目录建议：

views/hrm/salary/setting/subject/
views/hrm/salary/setting/plan/
views/hrm/salary/setting/item/
views/hrm/salary/setting/rule/
views/hrm/salary/archive/
views/hrm/salary/change-bill/
views/hrm/salary/batch/
views/hrm/salary/payslip/
views/hrm/salary/statistics/

10.3 UniApp 落地建议

在 ruoyi-office-uniapp/src/ 下新增：

api/hrm/salary-change/
api/hrm/salary-payslip/
pages-hrm/salary-change/
pages-hrm/payslip/

其中：

salary-change 复用现有 BPM 单据列表、创建、详情模式
payslip 优先做“我的工资条列表 + 明细查看”

十一、分阶段实施路线

Phase 1：建底座

薪酬主体
薪酬方案
薪资项目
计薪规则
社保公积金规则
个税规则
员工薪资档案
入职联动建档

Phase 2：跑闭环

调薪单 BPM
月度薪资批次
数据准备
试算
异常校验
薪资确认审批
发薪登记
工资条发布

Phase 3：补强联动

离职结薪批次
补发追扣
绩效深度联动
多维人工成本统计
移动端增强

十二、关键结论

薪酬模块首期核心不在复杂激励，而在“规则配置 + 数据联动 + 月结闭环 + 结果追溯”。
录用、入职、转正、调岗、调薪、离职应共同驱动员工薪资档案生命周期。
考勤与假期不应只做展示，而应成为薪酬批次试算的标准输入。
一期最关键的两个 BPM 单据是调薪单和薪资确认单。
移动端首期聚焦工资条查看和审批协同，不承载复杂后台配置。

薪酬管理整体设计方案 ​

文档说明 ​

一、产品定位与设计原则 ​

1.1 产品定位 ​

1.2 设计原则 ​

二、一二期边界划分 ​

2.1 一期范围 ​

2.2 二期范围 ​

2.3 一期明确不做 ​

三、业务总体蓝图 ​

3.1 核心闭环说明 ​

四、领域模型设计 ​

4.1 子域划分 ​

4.2 核心对象 ​

4.2.1 薪酬主体 ​

4.2.2 薪酬方案 ​

4.2.3 薪资项目 ​

4.2.4 计薪规则 ​

4.2.5 员工薪资档案 ​

4.2.6 员工薪资版本 ​

4.2.7 调薪申请单 ​

4.2.8 薪资批次 ​

4.2.9 薪资明细 ​

4.2.10 薪资确认单 ​

4.2.11 工资条 ​

4.3 状态机建议 ​

4.3.1 薪资档案状态 ​

4.3.2 调薪单状态 ​

4.3.3 薪资批次状态 ​

五、菜单与页面设计 ​

5.1 PC 端菜单建议 ​

5.2 页面形态建议 ​

5.3 UniApp 范围建议 ​

六、与现有模块的打通设计 ​

6.1 招聘与入职 ​

6.2 人事异动 ​

6.3 考勤与假期 ​

6.4 绩效 ​

6.5 组织与权限 ​

七、BPM 设计策略 ​

7.1 一期建议新增的 BPM 单据 ​

7.2 可选方案 ​

7.3 BPM 复用策略 ​

八、数据模型建议 ​

8.1 表结构总原则 ​

8.2 建议核心表 ​

8.2.1 配置类 ​

8.2.2 主数据类 ​

8.2.3 业务批次类 ​

8.3 关键字段建议 ​

8.3.1 hrm_employee_salary_archive ​

8.3.2 hrm_employee_salary_archive_version ​

8.3.3 hrm_salary_batch ​

8.3.4 hrm_salary_batch_employee ​

九、月度核算流程设计 ​

9.1 数据准备 ​

9.2 试算顺序建议 ​

9.3 异常校验建议 ​

十、实现建议与落地顺序 ​

10.1 后端落地建议 ​

10.2 Web 前端落地建议 ​

10.3 UniApp 落地建议 ​

十一、分阶段实施路线 ​

Phase 1：建底座 ​

Phase 2：跑闭环 ​

Phase 3：补强联动 ​

十二、关键结论 ​

薪酬管理整体设计方案

文档说明

一、产品定位与设计原则

1.1 产品定位

1.2 设计原则

二、一二期边界划分

2.1 一期范围

2.2 二期范围

2.3 一期明确不做

三、业务总体蓝图

3.1 核心闭环说明

四、领域模型设计

4.1 子域划分

4.2 核心对象

4.2.1 薪酬主体

4.2.2 薪酬方案

4.2.3 薪资项目

4.2.4 计薪规则

4.2.5 员工薪资档案

4.2.6 员工薪资版本

4.2.7 调薪申请单

4.2.8 薪资批次

4.2.9 薪资明细

4.2.10 薪资确认单

4.2.11 工资条

4.3 状态机建议

4.3.1 薪资档案状态

4.3.2 调薪单状态

4.3.3 薪资批次状态

五、菜单与页面设计

5.1 PC 端菜单建议

5.2 页面形态建议

5.3 UniApp 范围建议

六、与现有模块的打通设计

6.1 招聘与入职

6.2 人事异动

6.3 考勤与假期

6.4 绩效

6.5 组织与权限

七、BPM 设计策略

7.1 一期建议新增的 BPM 单据

7.2 可选方案

7.3 BPM 复用策略

八、数据模型建议

8.1 表结构总原则

8.2 建议核心表

8.2.1 配置类

8.2.2 主数据类

8.2.3 业务批次类

8.3 关键字段建议

8.3.1 `hrm_employee_salary_archive`

8.3.2 `hrm_employee_salary_archive_version`

8.3.3 `hrm_salary_batch`

8.3.4 `hrm_salary_batch_employee`

九、月度核算流程设计

9.1 数据准备

9.2 试算顺序建议

9.3 异常校验建议

十、实现建议与落地顺序

10.1 后端落地建议

10.2 Web 前端落地建议

10.3 UniApp 落地建议

十一、分阶段实施路线

Phase 1：建底座

Phase 2：跑闭环

Phase 3：补强联动

十二、关键结论