# OA 和人力不用分两套：SpringBoot + Vue3 一体化系统，源码可二开


员工从研发部调到项目部，人事档案改了，OA 里发起申请却还是原部门；主管换了，新申请依然找到原来的负责人。

这类问题看起来只是“有个字段没同步”，实际会一路影响人员选择、审批路由和数据权限。两套系统各自维护一份组织和人员，时间一长，谁的数据才是准的就说不清了。

**OA 和人力一体化，真正值得做的是让同一个人在不同业务里有明确的关联，让一次人员变更有清楚的生效规则。** 不是把两个菜单放到同一个首页，也不是把所有资料塞进一张用户表。

下面用 Spring Boot + Vue3 的 RuoYi Office，沿着组织、员工、调动审批和工作台这条线，看看源码里怎样连接这些部分，客户定制又该改在哪里。

![SpringBoot加Vue3一体化系统，OA与人力不用分两套](https://developer.qcloudimg.com/http-save/yehe-12798805/19f2fee6c90448ff88720db895a8a322.png)

*▲ 封面基于真实系统界面素材合成；下文配图为原始系统截图。*

## 一、组织共用标识，业务保留自己的职责

假设 OA 里有一个“研发部”，人力系统里也有一个“研发部”。名称一样，不代表程序知道它们是同一个部门。名称会改，也可能在不同公司下重复，用名称匹配很容易留下隐患。

组织关联应当落到稳定的部门 ID 上。页面展示名称，业务判断使用 ID；公司和部门也要分清，不能因为都出现在组织树里，就拿一个字段混着存。

RuoYi Office 的员工档案 `EmployeeDO` 中，既有部门和公司关联，也保留了与系统用户的关联。下面是字段摘录，省略注解及其他人事资料，不是完整实体类：

```java
private Long deptId;
private String deptName;
private Long companyId;
private String companyName;
private Long userId;
private Boolean userGenerated;
```

这几个字段能帮助开发者先理清三件事：员工属于哪个组织，是否关联登录账号，以及档案和账号之间靠什么定位。

但存了 ID 和名称，还需要确定各自用途。当前组织名称用于日常展示，历史申请上的部门名称可能需要保留提交时的口径。不能仅凭字段存在，就认定系统已经替所有单据保存好了历史快照。

![人力资源组织架构图中的公司与部门关系](https://developer.qcloudimg.com/http-save/yehe-12798805/40bd785efe446927e9af459f3f974238.png)

*▲ 组织架构视图。组织关系可以共用，业务资料和可见范围仍需分别管理。*

对于二开项目，先确认组织数据由哪里维护、业务选择器引用哪套 ID，比先把两个页面的样式统一更重要。已有外部组织系统时，也应建立明确的 ID 对照关系，而不是每次按名称临时查找。

## 二、员工档案和登录账号关联，而不是合并

员工档案关心的是入职、岗位、合同、教育经历等人事资料。登录账号关心的是谁能进入系统、拥有哪些角色、能执行哪些操作。两者有关联，但不是同一种数据。

例如，待入职人员可以先有档案，不一定立即开通账号；一些系统服务账号，也不应被当成正式员工参与考勤。把员工 ID 直接当作用户 ID 使用，会让这类场景越来越难处理。

在 `EmployeeServiceImpl` 的档案更新逻辑里，只有员工已经生成用户，且关联的 `userId` 存在时，才进入账号同步方法。下面是该方法的部分摘录，省略了其他基础资料字段：

```java
AdminUserUpdateReqDTO userUpdateReqDTO = new AdminUserUpdateReqDTO();
userUpdateReqDTO.setId(userId);
userUpdateReqDTO.setUsername(employee.getEmployeeNo());
userUpdateReqDTO.setNickname(employee.getName());
userUpdateReqDTO.setDeptId(employee.getDeptId());
adminUserApi.updateUser(userUpdateReqDTO);
```

这里不是再创建一个同名账号，而是通过已经关联的用户 ID 更新指定账号。员工工号用于用户名，姓名用于昵称，部门信息也通过明确的接口传递。

二开时，这种关联比“查到同名的人就更新”可靠得多。但同步哪些字段仍要有边界：基础联系信息可以按既定规则同步，薪资、证件和劳动合同不应该为了调用方便一起塞进用户接口。

还要注意更新入口。通过档案服务修改资料会走上述逻辑，其他业务如果直接更新员工表，并不会因为用了同一张表，就自动执行这个 Java 方法。

## 三、人事调动要分清审批通过和资料生效

调动申请很适合检验一体化是否落到了业务上。它不只是一个带审批按钮的表单，还要回答：改的是谁、从哪里调到哪里、什么时候开始使用新资料。

![人事调动录入表单中的原新部门与生效设置](https://developer.qcloudimg.com/http-save/yehe-12798805/d47abbb7fa76df51916cb44d1c38787d.png)

*▲ 调动申请的录入态，可配置新旧组织信息和生效方式；此图不是已完成调动的结果记录。*

`EmployeeTransferBillServiceImpl` 的流程状态回写中，有下面这段判断。代码为原方法的局部摘录，单据读取、校验和状态保存已省略：

```java
if (APPROVE.getStatus().equals(status)) {
    if (Boolean.TRUE.equals(bill.getEffectiveImmediately())) {
        updateEmployeeFromTransferBill(id);
    }
}
```

条件很明确：审批通过，并且选择立即生效，才在这个分支更新员工档案。更新方法会依据调动单，把新部门、公司、职位、职务等信息写回档案。

这也说明，“审批通过”和“资料生效”不能随便画等号。约定下个月调动，就需要有按日期执行、失败处理和结果核对的机制，不能在审批完成当天提前改成新部门。

还需要区分另一层边界：这里的档案更新方法直接调用员工 Mapper，并没有调用上一节的账号同步方法。因此，不能把这段实现理解为账号组织、角色权限和已有待办都自动跟着变了。

客户如果要求调动后这些内容一起调整，就应分别落实对应处理。尤其是正在审批的旧申请，保留原审批人还是转交新负责人，需要业务规则决定，而不是简单执行一次“全量同步”。

## 四、统一工作台，业务单据仍由各自模块负责

员工日常使用系统，不会先想“这个功能属于 OA 还是 HRM”。他需要的是找到申请入口，看到待办，再打开对应单据处理。

统一工作台能把这个使用路径缩短。用车、用印、请假、入职等申请可以从同一个入口进入处理，而不用让使用者在多个系统之间反复切换。

![统一工作台展示用车用印请假和员工入职等待办](https://developer.qcloudimg.com/http-save/yehe-12798805/4d411151218fdd93602b2702d33572a5.png)

*▲ 工作台中的多种业务待办。统一的是处理入口，不代表不同业务共用一套明细字段。*

前端接入新单据时，可以沿用统一的任务入口，再打开相应业务详情；后端则由对应业务服务处理审批结果。例如调动单负责人员资料变更，用车单负责自己的业务状态，不需要为了出现在同一个列表里，把两者改成一个巨大的通用服务。

这对维护也有好处。新增一类人事申请，重点是补齐业务表单、流程接入和结果处理，而不是再做一套登录、首页和待办。

不过，“任务已处理”与“后续动作已完成”仍要分开理解。审批成功后还有外部系统调用时，最好让操作结果可查询、失败原因可定位。用户看到的是一次操作，开发者仍需把各段状态交代清楚。

## 五、共享人员资料，不等于共享所有权限

一体化容易带来一个误区：既然 OA 和人力用的是同一批人，所有页面都可以直接取完整员工对象。

实际上，发起用车申请可能只需要姓名和部门；人事专员维护档案需要更多资料；工资、证件和合同又有不同的访问范围。前端不显示某一列，并不等于接口返回它就是安全的。

二开时可以把检查落到具体请求上：人员选择接口只返回选择所需字段；档案详情检查角色和数据范围；敏感资料的查询与导出单独控制。不要为了一个下拉框，把完整档案传到浏览器。

组织变更也会影响权限口径。一个人本月调到新部门，不代表上月提交的申请应该被重新解释为新部门的业务。当前组织用于当前授权，历史单据保留什么信息，要根据审计与统计需求设计。

验收时不妨准备两个账号：一个部门负责人，一个普通员工。分别检查调动前后的新申请、历史单据和人员查询结果。比一直使用管理员账号演示，更容易发现“不该看到却看到了”的问题。

## 六、源码二开，先确定客户真正需要改变的环节

对接客户时，“OA 和人力打通”往往只是一句话。落到开发，可以先拿一次调动做验证：档案更新了什么，账号跟不跟着改，新申请怎么选审批人，旧申请又怎么处理。

如果只改录入字段，工作主要在表单、接口和存储；如果改生效规则，就要进入业务服务；如果接客户原有身份系统，还要明确同步方向及冲突处理。把这些分开，才知道现成系统覆盖了什么、项目仍需交付什么。

RuoYi Office 提供 Spring Boot + Vue3 的系统基础和相应版本源码，可在授权范围内进行二次开发。公开仓库与商业版本不是同一范围：社区开源版已停止维护，保留基础学习体验；完整 OA、人力能力以商业版本清单和合同为准。

客户项目部署也不等于可以转售或再授权源码，部署数量、交付方式受协议限制；客户直接获得源码访问权需书面许可，对外 SaaS 运营不包含在现有客户部署授权中。

**一套系统的价值，是让组织、人员和审批之间的关系能看懂、能维护、能按客户规则调整。** 页面放在一起只是开始，资料由谁更新、什么时候生效、谁有权查看，才决定了后续能否用得顺。



![RuoYi Office 企业管理一体化平台](https://developer.qcloudimg.com/http-save/yehe-12798805/b0cfbc2d41731785fda5a9f0a81e4860.png)

员工从研发部调到项目部，人事档案改了，OA 里发起申请却还是原部门；主管换了，新申请依然找到原来的负责人。

OA 和人力不用分两套：SpringBoot + Vue3 一体化系统，源码可二开

OA 和人力放在同一个菜单里，不等于数据已经打通。以 Spring Boot + Vue3 的 RuoYi Office 为例，从组织标识、员工与账号关联、人事调动审批和统一工作台出发，讲清一体化系统如何减少重复维护，以及二次开发时必须分清的权限、生效时间和授权边界。

后端

架构设计

前端

OA与人力一体化系统基于SpringBoot+Vue3实现组织人员统一管理，通过稳定ID关联部门与员工，人事调动支持审批后即时或定时生效，统一工作台整合多业务待办，数据权限独立控制，源码可二次开发。

代码解释

路由

SaaS

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

OA 和人力不用分两套：SpringBoot + Vue3 一体化系统，源码可二开-腾讯云开发者社区-腾讯云

OA 和人力不用分两套：SpringBoot + Vue3 一体化系统，源码可二开

OA 和人力不用分两套：SpringBoot + Vue3 一体化系统，源码可二开

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐