OA 和人力不用分两套：SpringBoot + Vue3 一体化系统，源码可二开
员工从研发部调到项目部，人事档案改了，OA 里发起申请却还是原部门；主管换了，新申请依然找到原来的负责人。
这类问题看起来只是“有个字段没同步”，实际会一路影响人员选择、审批路由和数据权限。两套系统各自维护一份组织和人员，时间一长，谁的数据才是准的就说不清了。
OA 和人力一体化，真正值得做的是让同一个人在不同业务里有明确的关联，让一次人员变更有清楚的生效规则。 不是把两个菜单放到同一个首页，也不是把所有资料塞进一张用户表。
下面用 Spring Boot + Vue3 的 RuoYi Office，沿着组织、员工、调动审批和工作台这条线，看看源码里怎样连接这些部分，客户定制又该改在哪里。
▲ 封面基于真实系统界面素材合成；下文配图为原始系统截图。
一、组织共用标识，业务保留自己的职责
假设 OA 里有一个“研发部”，人力系统里也有一个“研发部”。名称一样，不代表程序知道它们是同一个部门。名称会改，也可能在不同公司下重复，用名称匹配很容易留下隐患。
组织关联应当落到稳定的部门 ID 上。页面展示名称，业务判断使用 ID；公司和部门也要分清，不能因为都出现在组织树里，就拿一个字段混着存。
RuoYi Office 的员工档案 EmployeeDO 中，既有部门和公司关联，也保留了与系统用户的关联。下面是字段摘录，省略注解及其他人事资料，不是完整实体类：
private Long deptId;
private String deptName;
private Long companyId;
private String companyName;
private Long userId;
private Boolean userGenerated;
这几个字段能帮助开发者先理清三件事：员工属于哪个组织，是否关联登录账号，以及档案和账号之间靠什么定位。
但存了 ID 和名称，还需要确定各自用途。当前组织名称用于日常展示，历史申请上的部门名称可能需要保留提交时的口径。不能仅凭字段存在，就认定系统已经替所有单据保存好了历史快照。
▲ 组织架构视图。组织关系可以共用，业务资料和可见范围仍需分别管理。
对于二开项目，先确认组织数据由哪里维护、业务选择器引用哪套 ID，比先把两个页面的样式统一更重要。已有外部组织系统时，也应建立明确的 ID 对照关系，而不是每次按名称临时查找。
二、员工档案和登录账号关联，而不是合并
员工档案关心的是入职、岗位、合同、教育经历等人事资料。登录账号关心的是谁能进入系统、拥有哪些角色、能执行哪些操作。两者有关联，但不是同一种数据。
例如，待入职人员可以先有档案，不一定立即开通账号；一些系统服务账号，也不应被当成正式员工参与考勤。把员工 ID 直接当作用户 ID 使用，会让这类场景越来越难处理。
在 EmployeeServiceImpl 的档案更新逻辑里，只有员工已经生成用户，且关联的 userId 存在时，才进入账号同步方法。下面是该方法的部分摘录，省略了其他基础资料字段：
AdminUserUpdateReqDTO userUpdateReqDTO = new AdminUserUpdateReqDTO();
userUpdateReqDTO.setId(userId);
userUpdateReqDTO.setUsername(employee.getEmployeeNo());
userUpdateReqDTO.setNickname(employee.getName());
userUpdateReqDTO.setDeptId(employee.getDeptId());
adminUserApi.updateUser(userUpdateReqDTO);
这里不是再创建一个同名账号，而是通过已经关联的用户 ID 更新指定账号。员工工号用于用户名，姓名用于昵称，部门信息也通过明确的接口传递。
二开时，这种关联比“查到同名的人就更新”可靠得多。但同步哪些字段仍要有边界：基础联系信息可以按既定规则同步，薪资、证件和劳动合同不应该为了调用方便一起塞进用户接口。
还要注意更新入口。通过档案服务修改资料会走上述逻辑，其他业务如果直接更新员工表，并不会因为用了同一张表，就自动执行这个 Java 方法。
三、人事调动要分清审批通过和资料生效
调动申请很适合检验一体化是否落到了业务上。它不只是一个带审批按钮的表单，还要回答：改的是谁、从哪里调到哪里、什么时候开始使用新资料。
▲ 调动申请的录入态，可配置新旧组织信息和生效方式；此图不是已完成调动的结果记录。
EmployeeTransferBillServiceImpl 的流程状态回写中，有下面这段判断。代码为原方法的局部摘录，单据读取、校验和状态保存已省略：
if (APPROVE.getStatus().equals(status)) {
if (Boolean.TRUE.equals(bill.getEffectiveImmediately())) {
updateEmployeeFromTransferBill(id);
}
}
条件很明确：审批通过，并且选择立即生效，才在这个分支更新员工档案。更新方法会依据调动单，把新部门、公司、职位、职务等信息写回档案。
这也说明，“审批通过”和“资料生效”不能随便画等号。约定下个月调动，就需要有按日期执行、失败处理和结果核对的机制，不能在审批完成当天提前改成新部门。
还需要区分另一层边界：这里的档案更新方法直接调用员工 Mapper，并没有调用上一节的账号同步方法。因此，不能把这段实现理解为账号组织、角色权限和已有待办都自动跟着变了。
客户如果要求调动后这些内容一起调整，就应分别落实对应处理。尤其是正在审批的旧申请，保留原审批人还是转交新负责人，需要业务规则决定，而不是简单执行一次“全量同步”。
四、统一工作台，业务单据仍由各自模块负责
员工日常使用系统，不会先想“这个功能属于 OA 还是 HRM”。他需要的是找到申请入口，看到待办，再打开对应单据处理。
统一工作台能把这个使用路径缩短。用车、用印、请假、入职等申请可以从同一个入口进入处理，而不用让使用者在多个系统之间反复切换。
▲ 工作台中的多种业务待办。统一的是处理入口，不代表不同业务共用一套明细字段。
前端接入新单据时，可以沿用统一的任务入口，再打开相应业务详情；后端则由对应业务服务处理审批结果。例如调动单负责人员资料变更，用车单负责自己的业务状态，不需要为了出现在同一个列表里，把两者改成一个巨大的通用服务。
这对维护也有好处。新增一类人事申请，重点是补齐业务表单、流程接入和结果处理，而不是再做一套登录、首页和待办。
不过，“任务已处理”与“后续动作已完成”仍要分开理解。审批成功后还有外部系统调用时，最好让操作结果可查询、失败原因可定位。用户看到的是一次操作，开发者仍需把各段状态交代清楚。
五、共享人员资料，不等于共享所有权限
一体化容易带来一个误区：既然 OA 和人力用的是同一批人，所有页面都可以直接取完整员工对象。
实际上，发起用车申请可能只需要姓名和部门；人事专员维护档案需要更多资料；工资、证件和合同又有不同的访问范围。前端不显示某一列，并不等于接口返回它就是安全的。
二开时可以把检查落到具体请求上：人员选择接口只返回选择所需字段；档案详情检查角色和数据范围；敏感资料的查询与导出单独控制。不要为了一个下拉框，把完整档案传到浏览器。
组织变更也会影响权限口径。一个人本月调到新部门，不代表上月提交的申请应该被重新解释为新部门的业务。当前组织用于当前授权，历史单据保留什么信息，要根据审计与统计需求设计。
验收时不妨准备两个账号：一个部门负责人，一个普通员工。分别检查调动前后的新申请、历史单据和人员查询结果。比一直使用管理员账号演示，更容易发现“不该看到却看到了”的问题。
六、源码二开，先确定客户真正需要改变的环节
对接客户时，“OA 和人力打通”往往只是一句话。落到开发，可以先拿一次调动做验证：档案更新了什么，账号跟不跟着改，新申请怎么选审批人，旧申请又怎么处理。
如果只改录入字段，工作主要在表单、接口和存储；如果改生效规则，就要进入业务服务；如果接客户原有身份系统，还要明确同步方向及冲突处理。把这些分开，才知道现成系统覆盖了什么、项目仍需交付什么。
RuoYi Office 提供 Spring Boot + Vue3 的系统基础和相应版本源码，可在授权范围内进行二次开发。公开仓库与商业版本不是同一范围：社区开源版已停止维护，保留基础学习体验；完整 OA、人力能力以商业版本清单和合同为准。
客户项目部署也不等于可以转售或再授权源码，部署数量、交付方式受协议限制；客户直接获得源码访问权需书面许可，对外 SaaS 运营不包含在现有客户部署授权中。
一套系统的价值，是让组织、人员和审批之间的关系能看懂、能维护、能按客户规则调整。 页面放在一起只是开始，资料由谁更新、什么时候生效、谁有权查看，才决定了后续能否用得顺。
