人走了，记录不能“空白”： MES×HR 离职人员下拉回显实战

业务场景SMT 车间MES 里的“换料记录、异常单、首件确认”等表单需要选择经办人/确认人。人员主数据来自 HR 系统。后来 HR 把离职人员状态置为“离职”MES 人员下拉默认只取在职人员。结果新表单好用了但历史表单上原经办人一旦离职下拉框就空白时间久了使用人员在查看表单时不知该表单的经办人、确认人为谁的问题。涉及系统HR 系统人员主数据权威源维护员工在职/离职状态、部门、工号、姓名。MES 系统生产工单、换料记录、异常单、首件确认等表单页面使用人员下拉业务表存经办人 ID。OA/BPM审批流审批记录里存了审批人姓名快照所以历史审批人基本正常。ERP接收 MES 工单完工、库存扣料等数据操作员字段多为文本用于和 MES 对账。原始需求业务提了两个看似矛盾的诉求新建表单时人员下拉不要显示几千人也不要让用户选到离职人员但查看历史表单时必须能看出当初是谁操作的不能因为人离职了就空白。IT 之前为了满足第一个诉求把下拉数据源一刀切过滤成“在职”结果历史单据经办人大量空白SMT 质量追溯和 ERP 对账都受影响。排查/分析过程先从 MES 历史换料记录页面开始查。选一条确认人已离职的单据页面确认人显示空白。打开浏览器网络请求发现下拉调的是 HR 人员选项接口参数是statusactive返回数据里没有这个离职人员。再查 MES 业务表发现只存了handler_id没有存姓名快照。查看页又复用了编辑页的下拉组件用人员选项去匹配 ID 对应的 label匹配不到就显示空。继续查 HR发现人员没有物理删除只是statusinactive姓名还在。OA 那边因为审批记录存了姓名快照所以历史审批人正常。根因是下拉数据源承担了历史回显职责且过滤条件一刀切。方案设计考虑了三种方案。方案 A下拉恢复全量人员。历史能显示但新建时列表太长还可能选到离职人员否决。方案 B每个页面单独改查看时单独查 HR 详情。页面太多工作量大容易漏风险高。方案 C公共人员下拉接口加includeIds默认只返回在职但把当前表单已选人员 ID 作为例外带出来离职人员标记“已离职”只用于回显不能新选查看页直接用姓名快照或文本显示。最终选 C因为改动集中在公共接口和公共下拉组件大部分页面不用大调能满足“正常显示”的目标。后续再补业务表姓名快照和提交校验放行原值。技术实现1表结构HR 人员表保留软删除字段如employee_id、name、status、leave_date、dept_id。MES 业务表增加handler_name、handler_dept_name快照字段保存时写入。2接口设计GET /api/common/employee-options?statusactiveincludeIds1001,1002后端 SQL 伪代码select * from hr_employee where status active or employee_id in (:includeIds) order by status, name;返回时对离职人员加 label[ { id: 1, name: 李四, status: active, label: 李四 }, { id: 1001, name: 张三, status: inactive, label: 张三已离职, disabled: true } ]3前端公共下拉组件加载选项时自动把当前值塞进includeIdsconst includeIds currentValue ? [currentValue] : []; const options await api.get(/common/employee-options, { status: active, includeIds: includeIds.join(,) });如果当前值还不在选项里就用业务表快照或单独查人员详情补一个 option至少显示“张三已离职”不能空白。4提交校验新建时校验必须在职编辑时如果经办人没变即使已离职也允许提交如果换了人新选人员必须在职。5查看页不再依赖下拉数据源直接显示handler_name离职状态动态补充为“张三已离职”查不到就显示“已离职人员(ID:1001)”。上线效果新建工单下拉从 3000 多人降到 800 多在职人员选择速度明显提升历史换料记录、异常单中涉及离职经办人的 600 多条记录恢复显示经办人空白率从约 5% 降到 0编辑历史单据不改经办人时不再报“人员必须在职”SMT 质量和 ERP 对账能追溯到具体操作人业务投诉下降。踩坑与反思一开始只改前端把离职人员硬塞进下拉结果新建时也能选到离职人员被业务发现后来加了disabled和后端校验才控制住。还遇到后端校验没放行原值编辑历史单直接报错。另外只存 ID 不存姓名快照人员改名或部门调整后历史显示会和当初不一致后来补了handler_name快照。如果重来应该一开始就把“人员状态”和“可选性”分开把“历史回显”和“新建选择”分开人员主数据坚持软删除业务表保存时冗余姓名快照能改公共组件和公共接口就不要逐页打补丁。