SpringBoot3+Vue3 员工全生命周期：入转调离如何衔接账号、权限、资产与交接

SpringBoot3+Vue3 员工全生命周期：入转调离如何衔接账号、权限、资产与交接

🌐 文档地址 ：https://ruoyioffice.com

👇 文章底部获取源码和演示地址 👇

💬 ：17156169080（获取产品咨询）

员工入职时要建档和开账号，转正时可能改变薪酬和任职状态，调动时要换部门和岗位，离职时又要停用账号、归还资产、交接工作。很多系统把这四件事做成四个菜单，结果是人事单据已经审批通过，账号还没停；部门变了，权限却仍沿用旧范围；离职完成了，项目待办还找不到接替人。

▲ 员工身份贯穿入职、转正、调动和离职，资源变化要经过生效门槛，并按责任域分别执行。

本文把现有源码能确认的账号联动写成已实现，把权限收敛、资产归还和工作接替写成需要按模块落地的协同设计。

一、员工生命周期不是四个状态，而是一条身份主线

员工档案是身份主线，人事变更单是事件记录，账号、权限和资产是被影响的资源。

如果每个模块都维护一份员工名称和部门文本，变化发生后很难判断哪个系统是权威。

对象	负责什么	不负责什么
员工档案	员工身份、组织、岗位、任职状态	不直接执行所有资源交接
人事变更单	申请、审批、变更类型、生效日期	不等于已执行
系统账号	登录身份、启停状态	不等于全部业务权限
组织权限	数据范围、角色和菜单	不等于资产归属
资产与工作	领用物品、项目任务、交接责任	不应被人事表单随意覆盖

1.1 审批通过和生效日期是两个时点

调动申请 9 月 20 日审批通过，生效日期可能是 10 月 1 日。

如果审批回调马上把部门改成新部门，9 月剩余时间的考勤、审批和数据范围就可能被提前切换。

因此，人事变更至少要有申请状态、审批状态、执行状态和生效日期。

审批通过只说明"允许发生"，到达生效日才说明"应该执行"。

1.2 离职也不是一键停用

停用账号是一个明确动作，但离职还涉及待办、资产、合同、邮箱、项目任务和数据保留。

系统可以先完成账号停用，再把其他资源列成待交接清单，不要为了"一键完成"把所有动作伪装成同步完成。

二、四个阶段如何共用一套身份

▲ 员工详情页用于确认身份、组织和任职字段；变更单引用员工 ID，而不是只保存姓名。

2.1 入职：先建立身份，再建立资源

入职单通常包含员工基础信息、组织、岗位、入职日期、试用期和账号生成选项。

入职审批通过后，员工档案才能成为其他模块可引用的身份。

如果账号创建失败，档案是否可以先保存，要在产品上明确：

• 强一致模式：账号失败则入职执行失败，进入补偿；
• 弱一致模式：档案先完成，账号进入待处理；
• 人工确认模式：人事人员看到失败原因后重试。

不要在代码里隐含选择其中一种。

▲ 入职单与档案是两个阶段：表单记录过程，档案承载后续业务身份。

2.2 转正：改变任职阶段，不应复制新员工

转正通常会影响薪酬方案、岗位标准、合同状态或考勤规则。

它应引用原员工 ID，记录转正日期和前后差异，而不是再生成一份新档案。

薪酬模块按生效版本计算的能力，正是为了支持这种"同一身份、不同期间规则"。

2.3 调动：组织变化和权限变化不必同一秒完成

调动单可以记录原部门、新部门、原岗位、新岗位、生效日期和交接人。

审批通过后，系统可以先通知双方准备交接；到生效日再执行组织和权限变化。

▲ 调动单要把目标组织、岗位和生效日期写清，避免把审批时间误当成变更时间。

2.4 离职：账号停用有源码依据，交接仍要逐项负责

员工离职服务中可以看到，当员工存在系统用户时，调用用户接口更新账号状态为禁用。

这是一项已能从源码确认的联动。

但资产归还、项目接替和权限收敛涉及资产、项目、系统权限等多个模块。

如果没有对应的接口和执行记录，就不能写成"离职单自动完成全部交接"。

▲ 离职涉及申请、最后工作日和账号生效等日期，日期不同会影响不同资源动作。

三、用协同矩阵代替"状态万能化"

▲ 员工档案、人事变更单、账号权限和资产交接分别承担不同责任；虚线部分代表需要按模块落地的协同设计。

3.1 档案行：身份发生什么变化

入职建立身份，转正更新任职阶段，调动更新组织岗位，离职结束在职状态。

这四个动作应该写入档案或档案版本，并保留生效时间。

3.2 账号权限行：能否登录只是第一层

账号状态是登录层面。

部门、岗位、角色、数据范围和代理人是权限层面。

离职时停用账号并不代表历史数据全部转移；调动时更新部门也不代表所有业务权限都应自动增加。

建议把权限变化拆成可审计动作：新增、移除、继承、临时授权和收回。

3.3 资产与工作行：需要接收人和结果

资产交接不能只显示"已处理"。

至少要有资产、原责任人、接收人、交接日期、盘点结果和差异说明。

项目工作交接还要有任务、当前进度、接替人和确认人。

这类记录可以由离职单发起，但不应由 HR 服务直接替代资产和项目服务写库。

四、生效任务为什么要独立出来

▲ 审批通过后先登记生效时间，到期再执行资源变化；执行结果回写人事单据。

生效任务可以由定时任务、消息或人工执行入口承担。

关键是它要能被重试、被审计、被观察。

4.1 生效动作应该幂等

同一调动单重复执行，不应重复新增角色、重复发送通知或重复创建交接任务。

动作需要以变更单 ID 和资源类型作为幂等键。

例如：

public void executeChange(Long billId) {
    ChangeBill bill = validateEffectiveBill(billId);
    if (!bill.isApproved() || bill.getEffectiveAt().isAfter(now())) {
        throw exception(CHANGE_NOT_EFFECTIVE);
    }
    String actionKey = billId + ":ACCOUNT";
    if (executionLogService.exists(actionKey)) {
        return;
    }
    executionLogService.start(actionKey, bill.getEmployeeId());
    try {
        employeeService.applyOrganization(bill.getEmployeeId(),
                bill.getTargetDeptId(), bill.getTargetPostId());
        executionLogService.success(actionKey);
    } catch (Exception ex) {
        executionLogService.fail(actionKey, ex.getMessage());
        throw ex;
    }
}

这段代码只表示执行日志的组织方式，不能靠"先查日志再执行"单独保证幂等。

生产实现需要唯一业务键和原子抢占，成功记录才允许跳过；失败记录应进入重试，执行中的超时记录需要核对目标状态。

真实权限更新也需要按项目权限模型扩展。

4.2 执行失败不能吞掉人事结果

如果账号停用成功，资产交接创建失败，人事单据应显示"部分完成"或"待补处理"，而不是继续显示完全成功。

错误信息要落在责任域中，方便 HR 知道应该联系哪个模块。

4.3 通知不等于执行

给新部门负责人发通知，只说明提醒已经发出。

不代表权限已经改变，也不代表资产已经交接。

通知记录和执行记录要分开。

4.4 生效任务的状态机

建议把资源执行任务拆成 PENDING、RUNNING、SUCCESS、FAILED 和 CANCELLED 五种状态。

PENDING 表示审批已通过但还未到执行时间，RUNNING 表示当前有执行者，SUCCESS 表示责任域已返回成功，FAILED 表示需要重试或人工处理，CANCELLED 则用于变更单撤回或生效日期被重新调整的情况。

状态机的价值在于让 HR、IT 和资产管理员看到同一条事实。

如果账号停用成功、资产交接失败，任务状态可以分别为 SUCCESS 和 FAILED，人事单据整体显示"部分完成"。

不要把所有下游结果压缩到变更单的一列 status 中。

状态	是否可重试	谁负责处理	页面提示
待生效	否	定时任务 / HR	等待生效日期
执行中	通常否	当前责任域	正在执行
已完成	否	只读追踪	已完成
失败	是	对应模块管理员	需要补处理
已取消	否	HR	变更已撤回

4.5 失败补偿要避免重复副作用

失败重试前，先查询目标模块是否已经产生结果。

例如账号接口返回超时，不能直接假设没有停用成功；应通过用户状态查询或幂等接口确认，再决定是否重试。

补偿记录要包含原始请求摘要、目标模块、重试次数、最后错误和人工备注。

如果某项必须人工确认，状态应保持"待人工处理"，而不是定时任务无限重试。

4.6 账号、代理人与待办转交

账号停用解决的是登录入口，离职和调动还会影响待办归属。

流程待办可能属于员工本人、部门负责人或某个业务角色，不能简单地把所有待办都转给 HR。

建议先按流程类型定义可转交策略：审批中的单据、只读抄送、历史已办和定时任务分别处理。

转交时记录原处理人、接收人、流程实例、节点、原因和有效期。

临时代理到期后，未处理待办要回到明确的升级队列。

4.6.1 账号与员工档案要分层

员工档案可以保留离职人员的历史任职记录，系统账号则按安全策略停用。

二者通过稳定的 userId 或 employeeId 关联，而不是共用登录名和当前部门文本。

这样做能支持重新入职、跨租户迁移和历史审批查询。

重新入职时可以创建新的任职周期，但要明确是否复用原系统账号，避免把旧权限和新岗位混在一起。

4.6.2 待办转交的示意代码

public void transferPendingTasks(Long employeeId, Long receiverId,
        LocalDateTime expireAt) {
    List<Task> tasks = taskService.findTransferable(employeeId);
    for (Task task : tasks) {
        String key = task.getId() + ":" + receiverId;
        if (transferLogService.exists(key)) {
            continue;
        }
        taskService.transfer(task.getId(), receiverId,
                "HR_LIFECYCLE", expireAt);
        transferLogService.record(key, employeeId,
                receiverId, expireAt);
    }
    auditService.record("TASK_TRANSFER", employeeId, receiverId);
}

这段代码仍需要结合流程引擎的节点权限、会签规则和候选人表达式。

关键是把"转交一次"做成可查询、可幂等的动作，而不是直接修改待办表中的用户 ID。

五、账号停用的真实实现边界

离职服务已有的核心联动是 adminUserApi.updateUserStatus。

下面在该调用外加入执行日志和审计的扩展示意，executionLogService 与 auditService 不是此处已有源码的直接摘录。

if (employee.getUserId() != null) {
    Long userId = employee.getUserId();
    String actionKey = resignation.getId() + ":DISABLE_USER";
    if (!executionLogService.exists(actionKey)) {
        executionLogService.start(actionKey, userId);
        try {
            adminUserApi.updateUserStatus(
                    userId,
                    CommonStatusEnum.DISABLE.getStatus());
            executionLogService.success(actionKey);
            auditService.record("USER_DISABLED", userId);
        } catch (Exception ex) {
            executionLogService.fail(actionKey, ex.getMessage());
            throw ex;
        }
    }
}

这段逻辑说明离职流程会联动系统用户状态。

它没有说明：

• 角色是否自动回收；
• 个人数据是否转移；
• 待办是否批量转交；
• 资产是否自动归还；
• 邮箱和第三方账号是否同步停用。

这些都需要对应模块提供接口，并在交接清单上留下结果。

六、权限收敛要按"新增、继承、临时"区分

调动后权限变化通常有三类：

1. 新岗位应得到的基础权限；
2. 原岗位仍需保留的历史查看权限；
3. 为交接设置的临时权限。

如果直接用新部门覆盖旧权限，可能导致历史单据不可见。

如果全部保留，又会让员工继续访问不应访问的数据。

可以为临时授权设置过期日期，并在权限页面显式显示来源。

权限系统不应只显示最终角色，还要能解释"为什么拥有这个权限"。

6.1 权限变化的四层边界

第一层是登录状态，决定账号能否进入系统。

第二层是组织关系，决定员工属于哪个租户、部门和岗位。

第三层是角色与菜单，决定可以操作哪些功能。

第四层是数据范围和业务授权，决定可以查看哪些单据、项目或客户。

调动时只更新第二层，未必足够；离职时只关闭第一层，也未必安全。

不同层次的变更应由对应服务执行，并在同一张人事变更单下汇总结果。

权限层	常见动作	失败后的处理
登录	启用、停用、锁定	重试用户接口
组织	更新部门、岗位、汇报关系	回滚或人工确认
角色	增加、移除、继承角色	生成权限差异
数据	收紧范围、保留只读、临时授权	到期回收

6.2 临时权限必须有到期任务

调动交接常需要保留原部门的只读权限，或允许新岗位提前查看部分资料。

这类权限不能直接并入永久角色，否则几个月后没人知道为什么仍然可以访问。

临时授权至少包含来源单据、授权人、开始时间、结束时间和回收结果。

定时任务在结束时间到达后执行回收，失败时生成待处理记录。

页面应同时展示永久权限、继承权限和临时权限，帮助管理员解释权限来源。

6.3 代理人和数据范围要分别确认

流程待办转交给新负责人，不代表新负责人自动获得旧部门全部数据权限。

同样，保留历史数据只读权限，也不代表可以继续审批新单据。

待办代理和数据授权应分别审批、分别记录。

七、交接清单的产品设计

交接清单适合作为人事变更单的子任务，而不是一段备注文本。

清单类型	最小字段	完成条件
资产	资产编号、状态、接收人、差异	盘点确认
项目任务	任务、进度、接替人	接替人确认
审批待办	流程、节点、代理人	待办已转交
权限	权限项、处理动作、执行时间	收敛或临时授权完成
文件	业务单据、访问责任	保留或移交完成

交接项可以由不同责任人处理，HR 只负责整体跟踪。

当某一项失败时，系统要显示具体失败原因，而不是把整张离职单卡成一个不透明状态。

7.1 资产交接至少需要三类身份

资产记录要区分原责任人、当前保管人和最终接收人。

员工离职后，资产可能先由部门管理员盘点，再由新员工签收，中间还可能进入仓库。

如果只有一个 userId 字段，系统无法表达这段过程。

推荐的最小模型如下：

数据对象	关键字段	作用
交接单	billId、employeeId、生效日期	说明为什么发起交接
交接项	assetId、原责任人、接收人、状态	逐项跟踪资产
盘点记录	数量、成色、照片、差异	记录现场事实
签收记录	签收人、时间、备注	证明交接完成

资产模块可以订阅人事变更事件，但应自行校验资产状态。

已报废、已借出或处于盘点中的资产不能被离职单直接标记为已归还。

public void createAssetHandover(Long resignationId,
        Long employeeId, Long receiverId) {
    List<AssetDO> assets = assetService.findByHolder(employeeId);
    for (AssetDO asset : assets) {
        if (!asset.isCanHandover()) {
            handoverMapper.insertBlocked(resignationId,
                    asset.getId(), asset.getBlockReason());
            continue;
        }
        handoverMapper.insertItem(resignationId, asset.getId(),
                employeeId, receiverId, "PENDING");
        auditService.record("ASSET_HANDOVER_CREATED", asset.getId());
    }
    handoverMapper.updateSummary(resignationId);
}

7.2 工作交接不是资产清单的复制

项目任务、客户联系人、共享文件和审批待办有不同的交接规则。

项目任务需要确认进度和风险，客户联系人需要确认后续责任人，文件则需要按业务权限继续可见。

建议每类工作建立独立子任务，再由人事变更单聚合进度。

7.3 离职后的数据保留

账号停用后，历史审批、考勤、薪资和项目记录仍需按权限查询。

删除员工档案或把姓名替换成空值，会破坏审计和业务统计。

更稳妥的做法是保留不可变的历史身份标识，同时限制新的业务操作入口。

个人敏感信息的脱敏、导出和保留期限应遵循企业制度。

数据保留不等于允许原账号继续登录，也不等于所有管理员都能查看完整字段。

八、验收场景

建议覆盖：

1. 入职审批通过后账号创建成功。
2. 账号创建失败，档案和执行状态是否可解释。
3. 转正日期晚于审批日期，薪酬版本按生效日切换。
4. 调动审批通过但未到生效日，组织和权限保持原状态。
5. 到达生效日后，组织、权限和交接任务分别执行。
6. 离职账号停用成功但资产交接失败，显示部分完成。
7. 重复执行同一变更单，不重复创建资源。
8. 代理人只能接收允许转交的待办。
9. 历史业务数据仍按授权范围可追溯。
10. 变更执行失败可重试并留下审计。

验收时建议把每个场景拆成"审批前、审批后、生效时、执行后、重试后"五个观察点。

例如调动单在审批后不应立即改变部门；到生效时间后先生成组织变更任务，再执行权限差异；如果权限接口失败，员工档案应能显示已变更但权限待处理。

8.1 需要特别关注的边界

边界场景	预期行为
生效日期被修改	旧任务取消，新任务重新排期
员工重复入职	明确复用账号还是创建新账号
离职单撤回	未执行任务取消，已执行动作进入补偿
资产盘点有差异	交接项转人工处理，不自动完成
代理人离职	待办进入上级或指定升级队列
租户切换	人事身份和系统账号不能跨租户串联
历史权限查询	只读历史记录，不开放新操作

8.2 从日志反查责任域

一次员工变更可能产生多条执行日志。

日志中应保留变更单 ID、资源类型、目标 ID、请求摘要、执行人、开始时间、结束时间和结果。

HR 先看到总体结果，再根据失败项跳转到账号、权限、资产或流程模块。

如果日志只写"执行失败"，开发和实施都无法判断是接口超时、字段校验失败还是权限不足。

错误信息需要对人友好，对系统可检索，并避免直接把敏感凭证写入日志。

8.3 把真实履历沉淀为回归样本

可以准备一名员工从入职到离职的完整样本，再准备一名经历调动和临时代理的样本。

每次修改人事服务、用户接口、权限服务或资产接口后，按时间顺序重放这些样本。

回归断言不应只检查最终状态。

还要检查每个生效日期前后的部门、岗位、账号、角色、待办、资产交接和审计日志。

如果一个动作被重复执行，断言资源数量和日志数量都不会增加。

对于失败场景，记录故障注入点，例如账号接口超时、资产服务返回校验错误、流程引擎拒绝转交。

验证系统能够恢复到可解释状态，并允许责任人从失败节点继续处理。

多租户场景还要把"同一个 employeeId"理解为租户内身份，而不是全局身份。

所有执行任务、审计日志和资源查询都要带上租户上下文。

跨租户导入员工时，先建立身份映射，再创建账号和权限，不能直接复用旧租户的角色 ID。

组织树调整也会影响生命周期任务。

如果员工调动前部门被合并，任务执行时应重新校验目标部门和岗位是否仍然有效。

目标组织不存在时，任务进入人工处理，不能把空部门写入档案后继续执行。

员工历史数据查询同样要区分当前权限与历史权限。

离职管理员可以查看必要的档案和交接结果，但不应因此获得员工曾经负责客户的全部业务数据。

权限服务需要提供面向历史记录的只读授权，而不是简单恢复原角色。

从产品体验看，员工详情页可以增加一条"生命周期时间线"，按入职、转正、调动和离职展示审批时间、生效时间、执行结果和责任人。

时间线只呈现事实，不直接替代各模块的处理页面。

点击某个节点后，HR 能看到对应单据、执行日志和失败补偿入口，IT 能看到账号与权限动作，资产管理员能看到盘点与签收记录。

同一条时间线把不同责任域串起来，能够减少跨部门反复确认。

时间线中的每个节点都应携带租户、员工和变更单身份。

这样导出和审计时仍能准确定位来源。

生命周期时间线是各责任域事件的聚合视图，而不是另一份主数据。下游事件延迟时显示待同步，补偿完成后追加结果，始终保留原单据入口。如此才能解释"人事已经生效、权限仍待处理"的中间状态，而不把未完成动作隐藏起来。

九、快速体验

在线演示地址为 https://ruoyioffice.com/web/，账号 admin / admin123。

可从 HRM 员工档案、入职、转正、调动和离职页面按时间顺序体验。

截图中的页面来自不同阶段，不能理解为同一名员工的完整真实履历。

源码入口包括员工变更服务、员工档案服务、用户状态接口和前端 HRM 单据页面。

阅读时要区分已实现的账号联动与跨域协同建议。

常见问题

员工调动审批通过后要立刻换部门吗？

不一定。

如果单据有生效日期，应在生效日期执行；审批通过只代表允许执行。

离职单能自动完成资产归还吗？

只有在资产模块提供明确接口、交接字段和执行记录时才能做到。

不能因为离职服务停用了账号，就推导资产也已归还。

调动后旧权限要全部删除吗？

要根据历史查看、交接和数据安全要求区分。

基础权限、临时权限和历史只读权限应分别治理。

人事档案和系统账号应该共用一张表吗？

不建议。

员工档案是 HR 身份，系统账号是登录身份，二者通过 userId 等稳定关系关联。

为什么需要执行日志？

因为审批、到期生效和资源动作可能跨越多个系统。

执行日志能支持幂等、重试和责任追踪。

结语

员工全生命周期的核心不是把四张单据连起来，而是让同一个员工身份在不同时间点，以明确责任影响账号、权限、资产和工作。

审批通过、到达生效日、资源执行完成，三个时点分开以后，系统才不会用一个"已完成"掩盖未完成的交接。

如果这篇对你有用，点个「在看」或收藏。

🌐 演示地址 ：https://ruoyioffice.com/web

📦 GitHub 源码 ：https://github.com/yuqing2026/ruoyi-office

📦 Gitee 源码 ：https://gitee.com/yqzy1688/ruoyi-office

💬 微信：17156169080（获取产品咨询）

打开演示地址直接查看系统。