OA请假审批遇到部门调整，未完成的单据怎样继续处理

员工调部门时，已经提交的请假单不宜直接重写全部审批人。按组织生效时间、未完成节点和已批准的业务规则，区分待办转交与历史留痕。

员工周一提交请假申请，周三调到另一个部门，原主管的待办里仍有这张单。新主管能否直接审批，旧主管是否还应看见，已经通过的节点要不要重新做？只更新员工档案中的部门名称，很难同时回答这些问题。

处理组织调整时，需要把“人员现在属于哪里”和“这张单据按什么规则流转”分开。下文以虚构情景说明OA实施时需要确认的问题；审批资格、生效时点、历史访问和转交权限，应由企业有权负责人根据自身制度决定。

先固定调整时间与单据当前进度

定位一张在途单据，可以记录申请标识、提交时间、提交时部门、组织调整的批准生效时间、已完成节点和当前待处理节点。调部门的登记时间未必就是生效时间，生效日期也不必与请假开始日期相同，应以企业批准的记录为准。

例如一张测试单提交时属于甲部门，主管节点尚未完成，员工次日进入乙部门。若没有这些时间与进度信息，系统很容易把所有未完成申请都送给新主管，或让旧主管永久保留处理权。先列明事实，再决定适用规则，能够减少事后争议。

在未完成节点上选择处理方式

常见候选有继续沿用提交时规则、将未完成节点转给新部门、退回后按新规则重新提交。三者都可能适合某些企业，不能直接选一个写成通用答案。需要比较的，是业务责任与处理影响。

涉及后续多个节点时，还要区分已经完成、正在等待和尚未生成的节点。不能把已完成意见改署名为新主管，也不能只转第一条待办，却让下一节点仍指向失效的组织关系。系统实现应执行确认过的选择，工程团队负责提供影响预览和测试结果。

流程快照与当前权限同时保留

保存提交时的流程信息，有助于解释历史，但不意味着冻结所有人的访问资格。旧主管离岗、账号停用或临时授权到期后，历史流程里出现他的名字，不能成为继续审批或读取敏感附件的理由。

可以分别保留流程适用版本、提交时组织信息、已发生的意见，以及当前允许谁查询和处理。权限应在可信服务端核对；前端移除待办按钮，不能代替拒绝旧账号直接请求接口。OWASP授权指南提出最小权限及每请求校验原则，本文据此建议把旧处理人的直接访问也纳入负例测试。

请假附件可能含敏感个人信息。新主管是否需要看完整附件，应依据实际用途与企业规则确认，不能因为转交了待办就开放全部历史资料。审批权、查询权和导出权可以具有不同边界，系统需明确表达。

用转交事件解释变化，保留原审批事实

一次转交记录可以包含单据标识、受影响节点、原处理人、新处理人、原因、批准人、生效时间和执行结果。页面应让下一位处理者理解为什么收到这张单，而不是只显示一个新的部门名称。

假设甲主管已通过第一节点，第二节点因人员调整需要转交，第一节点的意见仍属于甲主管当时作出的事实。新的组织展示可以单列当前部门，不覆盖历史身份。管理员纠正误转交时，也应保留更正记录和理由，而不是删除前一次事件，让单据看起来从未转过。

操作失败或结果未知时，先查节点是否已转交、待办是否已变化，再决定后续处理。重复执行不能制造两份有效待办。这里的目标是保留可追踪责任，具体重试与任务机制可沿用企业现有底座。

批量组织调整先预览影响

一次部门合并可能影响多张申请。执行前可以按单据与节点列出：哪些不受影响，哪些需要转交，哪些处理人已失去资格，哪些存在未确认规则。业务负责人逐类确认后，工程团队再在授权范围内处理。

无需把所有历史单据重跑。已结束单据通常关注历史可解释和查询权限，未完成单据才需要核对后续流转；是否重审已结束业务属于企业决策。影响清单也不能直接附完整请假理由和附件，采用必要标识与分类即可。

验收时用同一张单串起前后两次操作

在隔离环境准备自制员工、部门、审批人和申请，先完成一个节点，再调整部门并继续处理。除了正常路径，还应检查以下情景：

• 调整发生在提交前与提交后，单据选择的规则符合已批准口径。
• 原处理人仍有效、已离岗、临时授权到期，访问结果分别符合资格。
• 已完成意见没有被改名，未完成待办转交后可被正确找到。
• 重复转交没有增加第二份有效待办，失败后能够定位真实结果。
• 有权接单但无权查看附件的人员，无法通过直接链接取得附件。
• 调整被撤回或更正时，系统按确认流程处理并保留前后记录。

检查时要看每一步由谁处理、依据什么规则，以及是否还留有未确认事项。除了看单据是否完成，也要核对旧主管的处理权限、已完成意见和新主管收到的待办。正式使用前，还需确认组织同步实际采用的生效时间。

准备整体系统方案时，可参考ERP、CRM、OA选型指南，再通过企业系统开发服务梳理组织来源和审批衔接。把在途节点的处理依据说清楚，员工与主管才能知道单据由谁继续负责，维护者也能解释变化的来由。