selfrelease
20 KiB
TurboHR 系统优化清单（20260811）
基于用户反馈的 13 项问题，逐条分析合理性并给出优化建议。
验证状态：已逐条对照源码验证，标注 ✅ 确认存在 / ⚠️ 部分存在 / ❌ 不存在或已实现。
一、薪税管理发薪模块
1.1 发薪数据每月变化需重新导入（反馈 #1）
用户反馈：每个月有变化都要重新导入，需要在好几个模块/系统间来回切换，不便捷。
现状分析：当前发薪流程为：花名册员工数据 → 批量导入薪资数据 → 计算社保公积金 → 生成工资条 → 归档。每月需重新导入薪资批次数据。
代码验证：✅ 确认存在。当前薪税流程需手动导入或手动创建批次，无「复制上月批次」功能。月度导入模板支持考勤/加班/薪资调整/社保变动，但无法自动从花名册拉取固定项。
合理性：✅ 合理。HR 每月薪资数据确实有变化（加班费、绩效奖金、考勤扣款等），但可以优化流程减少重复操作。
优化方案：
- 支持「复制上月批次」功能：基于上月归档数据自动生成新月份草稿，仅需修改变化项
- 花名册中已维护的社保基数、公积金基数自动同步到薪税模块，无需重复录入
- 考勤模块确认的考勤数据自动关联到薪税计算（加班时长、请假扣款等）
- 增加「一键取数」功能：从花名册自动拉取基本工资、社保基数等固定项，仅需手动录入变动项
优先级：P1 高
二、导入错误提示不清晰
2.1 导入提示乱码，无法定位错误（反馈 #2）
用户反馈：按模板填写两人导入后提示一堆乱码，实际模板可能没填错，不知道哪里有问题。
现状分析：Settings.tsx 导入预览已有错误展示（result.errors 数组），但错误信息可能显示的是后端字段名（英文），对用户来说像"乱码"。且如果用户跳过预览直接导入，错误提示可能不够醒目。
代码验证：⚠️ 部分存在。Settings.tsx:967-968 已有 toast 提示「有 N 条错误」，预览阶段有完整错误表格（行号/姓名/状态/错误信息），且支持「导出错误日志」Excel 下载。但错误信息内容来自后端，可能包含英文字段名导致「乱码」感。用户若跳过预览直接导入，错误提示在结果区域可能不够醒目。
合理性：✅ 合理。导入错误信息需要用户可读、可定位。
优化方案：
- 错误信息中文化：将后端返回的字段名映射为中文（如
name→姓名、idCardNumber→身份证号） - 错误提示格式：
第 X 行，字段「姓名」：不能为空或第 X 行，身份证号格式不正确 - 导入失败时增加醒目 toast 提示「有 N 条错误，请查看详情」
- 增加「下载错误报告」按钮，导出错误行明细（Excel）
- 预览阶段就展示完整校验结果，不通过预览不允许导入
优先级：P0 紧急
三、工资流水导出格式
3.1 导出工资流水是否适配银行格式（反馈 #3）
用户反馈：工资归档后工资条有显示，导出工资流水处是否适合银行直接关联？
现状分析：当前 PayslipTab.tsx 无导出功能（已在 20260804 优化清单中列为 P1 待修复项）。工资流水导出需要符合银行代发工资文件格式。
代码验证：✅ 确认存在。PayslipTab.tsx 无导出功能，仅有「从批次汇总生成」「税率试算」「删除」操作，无银行代发文件导出。
合理性：✅ 合理。银行代发工资通常需要特定格式（Excel/CSV，包含姓名、身份证号、银行账号、金额等字段）。
优化方案：
- 增加「导出银行代发文件」功能，支持常见银行格式（工行、建行、招行等）
- 导出字段：姓名、身份证号、银行账号、开户行、实发金额
- 支持自定义字段映射，适配不同银行要求
- 导出格式支持 Excel 和 CSV
优先级：P1 高
四、社保基数与花名册数据不同步
4.1 社保公积金办理处仍显示工资数而非社保基数（反馈 #4）
用户反馈：花名册中已修改社保基数，但社保公积金办理里还是显示工资数。
现状分析：花名册 BasicInfo.tsx 中可编辑社保基数（socialInsuranceBase、housingFundBase），但社保模块 SocialInsurance.tsx 的月度办理可能直接取 salary 字段而非社保基数字段。
代码验证：❌ 不存在（已正确实现）。payroll.service.ts:166-167 明确代码：const socialBase = employee.socialInsBase || inputs.baseSalary，即优先使用花名册中的 socialInsBase，未设置时才用基本工资。contract.service.ts:205-206 入职时同样 socialInsBase != null ? socialInsBase : salaryNum。社保月度办理 MonthlyRows.tsx 显示的 i.base 来自 EmployeeSocialInsRecord 表，该记录在入职和基数调整时已正确写入。若用户遇到显示工资数而非社保基数，可能是该员工 socialInsBase 字段为 null，需在花名册 BasicInfo 中设置社保基数。
合理性：⚠️ 部分合理。代码逻辑正确（优先用 socialInsBase），但用户若未在花名册设置社保基数，系统会 fallback 到工资数，用户可能不理解这个优先级。建议增加 UI 提示。
优化方案：
- 社保公积金月度办理中，基数取值优先级：
socialInsuranceBase>salary（如果社保基数已设置则用社保基数，否则用工资） - 同理公积金基数取值：
housingFundBase>salary - 在社保办理界面显示数据来源标注（「来自花名册社保基数」或「来自月工资」）
- 增加「一键同步花名册社保基数」按钮
优先级：P0 紧急
五、商险管理添加员工入口缺失
5.1 商险方案添加员工无入口（反馈 #5）
用户反馈：添加了商险方案，但不知道如何添加员工，员工办理里也没有商险选项。
现状分析：需确认商险模块是否有员工关联功能。
代码验证：✅ 确认存在。CommercialInsuranceTab.tsx 有方案 CRUD 和参保人员查看（enrollments），但无「添加参保员工」按钮。API 层 commercialInsuranceApi 仅有 plans/enrollments/savePlan/removePlan，缺少 addEnrollment 接口。员工办理 WorkProcess.tsx 的 13 种流程类型中也无商险参保类型。
合理性：✅ 合理。商险方案创建后应能关联员工。
优化方案：
- 商险方案详情页增加「添加参保员工」按钮，支持批量选择员工
- 员工办理（WorkProcess）中增加商险参保/退保流程类型
- 花名册员工详情中增加商险参保状态展示
优先级：P1 高
六、员工福利月度汇总无数据
6.1 福利添加人员后月度汇总无数（反馈 #6）
用户反馈：员工福利能添加人员，但月度汇总处没有数。
现状分析：需确认福利模块的汇总逻辑是否正确关联了已添加的福利人员数据。
代码验证：❌ 不存在（系统中无福利模块）。搜索全部前端代码无 benefit、福利、welfare 关键词。系统无员工福利管理模块，用户可能指的是其他模块（如社保或商险）的功能。
合理性：⚠️ 需澄清。系统当前无福利模块，需与用户确认具体指的是哪个功能。
优化方案：
- 检查月度汇总查询逻辑，确保关联了福利人员表
- 汇总维度：按福利类型汇总人数和金额、按部门汇总
- 添加人员后自动刷新汇总数据
- 汇总页面增加「刷新」按钮
优先级：P1 高
七、证据链完整性验证
7.1 验证全部完整性显示全部异常（反馈 #7）
用户反馈：证据链条中验证全部完整性，显示全部异常，不清楚如何验证。
现状分析：Termination.tsx 中有仲裁证据链模块，验证逻辑可能过于严格或验证条件不明确。
代码验证：⚠️ 部分存在。Evidence.tsx 有「验证全部完整性」按钮，调用 evidenceApi.verifyAll()，返回 verifyResult.invalid 计数。验证逻辑是后端 Hash 校验（SHA256），若全部异常可能是：①数据库中证据链记录的 hash 与实际数据不匹配；②证据链记录为空时验证逻辑有 bug。前端只显示「N 条通过，M 条异常」，不显示具体异常原因和修复建议。EvidenceChain.tsx（员工维度）有证据列表和风险提醒，但无验证功能。
合理性：✅ 合理。用户不理解验证规则，且全部异常说明验证逻辑可能有问题。
优化方案：
- 验证结果中显示具体异常原因（如「缺少劳动合同扫描件」「考勤记录不完整」等）
- 每个验证项增加「查看要求」说明，告知用户需要什么材料
- 验证标准可配置：区分「必须项」和「建议项」，必须项缺失才标红
- 增加「验证说明」帮助文档
优先级：P2 中
八、员工办理必填项缺失
8.1 只填姓名也能录入，关键信息未设必填（反馈 #8）
用户反馈：员工办理中只填姓名也能录入，建议身份证号等关键信息设为必填。
现状分析：WorkProcess.tsx 的入职登记表单中，employeeName 可能是唯一必填项，idCardNumber 等字段未设必填。
代码验证：✅ 确认存在。WorkProcess.tsx:231-242 的 handleCreate() 仅校验 selectedType 非空，不校验任何表单字段。FORM_FIELDS 配置中无 required 标记，所有字段都是选填。后端 work-process.service.ts 也未对 formData 做必填校验。HIRE 类型有 idCardNumber 字段但非必填，只填姓名即可创建草稿并提交。
合理性：✅ 合理。关键信息缺失会导致后续业务（社保、合同、工资）无法正常办理。
优化方案：
- 入职登记必填项：姓名、身份证号、手机号、部门
- 用工办理其他流程类型根据类型设置相应必填项
- 前端表单增加必填校验提示
- 后端 schema 同步增加必填校验
优先级：P0 紧急
九、员工删除限制
9.1 已办理完毕的员工无法删除（反馈 #9）
用户反馈：员工已办理完毕，想删除无法删除，必须做离职处理。
现状分析：系统设计中员工记录不允许物理删除，只能通过离职流程标记为 TERMINATED 状态。这是合理的数据管理设计。
代码验证：✅ 确认存在。Roster.tsx 中无删除员工按钮（搜索结果中 Roster.tsx 不含 Trash/delete 相关代码）。花名册仅支持「添加员工」「离职」「重新入职」，不支持物理删除。WorkProcess.tsx 中仅可删除草稿记录，不可删除已完成的员工档案。
合理性：⚠️ 部分合理。从数据合规角度，员工记录不应物理删除（需保留人事档案）。但如果是录入错误的测试数据，应提供清理机制。
优化方案：
- 保持正式员工不可删除，只能离职处理（合规要求）
- 增加「作废」功能：仅限录入错误且无关联业务数据（无合同、无工资记录）的员工可作废
- 作废后数据保留但不在花名册显示，管理员可在设置中查看作废记录
- 增加「测试数据清理」功能：管理员可一键清除所有测试员工
优先级：P2 中
十、离职审批状态无法更改
10.1 待审批状态无法更改或找不到更改入口（反馈 #10）
用户反馈：选择待审批后，再点进去状态无法更改，没找到更改入口。
现状分析：Termination.tsx 中离职流程选择「待审批」后，可能缺少审批操作入口或状态流转不完整。
代码验证：❌ 不存在（已实现审批功能）。Termination.tsx:967-993 在详情视图中，当 draftDetail.status === 'PENDING_APPROVAL' 时，显示审批意见输入框和「审批通过」「驳回」按钮，分别调用 approveMutation 和 rejectMutation。列表视图中也有快捷审批图标按钮（828-846行）。API 层 terminationApi.approve/reject 完整。用户可能是没找到详情入口——需点击列表中的审批图标或详情按钮进入详情视图才能操作。
合理性：⚠️ 部分合理。功能已存在，但入口可能不够明显，用户没找到操作位置。建议优化 UI 引导。
优化方案：
- 离职详情页增加「审批」按钮（通过/驳回/退回修改）
- 待审批状态列表增加批量审批功能
- 审批操作记录审批人、审批时间、审批意见
- 增加审批通知提醒
优先级：P0 紧急
十一、花名册职责边界
11.1 花名册应只读，修改到相应模块操作（反馈 #11）
用户反馈：花名册应该只能查看，修改应到相应模块，否则太乱。
现状分析：当前花名册 Roster.tsx 集成了大量操作：添加员工、薪资调整、部门变更、离职、重新入职等。EmployeeProfile 中还能直接编辑基本信息、合同、薪酬等。
代码验证：⚠️ 部分存在。Roster.tsx 列表支持添加员工、批量导入、导出，点击进入 EmployeeProfile 后可编辑基本信息、合同、薪酬等。操作确实集中在花名册中，但各编辑区域已有模块化分区（BasicInfo/ContractInfo/SalaryInfo 等）。
合理性：⚠️ 部分合理。花名册作为统一查看入口是合理的，但编辑入口确实可以更清晰。
优化方案：
- 花名册列表保持只读查看，点击进入员工详情
- 员工详情页保留编辑功能，但按模块分区并标注来源模块（如「基本信息 → 员工档案模块」「合同信息 → 合同管理模块」）
- 每个编辑区域增加「前往该模块」链接，方便用户到对应模块操作
- 花名册列表的操作按钮（薪资调整、离职等）保留，但增加模块跳转提示
- 不建议完全移除编辑功能，因为会降低操作效率
优先级：P3 规划（涉及大量 UI 重构）
十二、招聘模块缺失
12.1 系统没有招聘模块（反馈 #12）
用户反馈：HR 最重要的招聘环节为什么没有？
现状分析：系统目前覆盖入职→在职→离职全生命周期，但缺少招聘前端的简历管理、面试安排、Offer 管理等环节。
代码验证：✅ 确认存在。搜索全部前端代码无 recruit、resume、interview、招聘、简历、面试 相关页面或路由。系统无招聘模块。
合理性：✅ 合理。招聘是 HR 核心功能之一。
优化方案：
- 新建招聘模块，包含：
- 简历管理：简历导入/录入、简历筛选、状态流转（待筛选→初试→复试→Offer→入职/淘汰）
- 面试管理：面试安排、面试评价、面试日历
- Offer 管理：Offer 模板、Offer 发放、接受/拒绝跟踪
- 招聘渠道：渠道管理、来源统计
- 人才库：未录用候选人归档，未来岗位匹配
- 与花名册打通：入职时自动从简历库拉取候选人信息
- 招聘数据看板：渠道转化率、招聘周期、录用率等
优先级：P3 规划（大型新功能，建议单独规划版本）
十三、角色权限分工
13.1 专员和主管的权限分工（反馈 #13）
用户反馈：工作角色分类，是否考虑有专员和主管的权限分工。
现状分析：当前系统角色为 SUPER_ADMIN、ADMIN、HR、VIEWER 四级，HR 角色拥有全部 HR 操作权限，无专员/主管区分。
代码验证：✅ 确认存在。authStore.ts 中 User 角色为 SUPER_ADMIN | ADMIN | HR | VIEWER 四级，无专员/主管区分。所有 HR 角色拥有相同权限，无法按模块或操作类型细分。
合理性：✅ 合理。中大型企业需要更细粒度的权限控制。
优化方案：
- 角色体系扩展：
HR_SUPERVISOR（HR 主管）：全部查看 + 审批权限 + 配置权限HR_SPECIALIST（HR 专员）：数据录入 + 日常操作，无审批和配置权限
- 权限粒度：
- 查看权限：全部模块可查看
- 操作权限：专员可录入/修改，主管可审批/删除/导出
- 配置权限：仅主管/管理员可修改系统配置（社保比例、薪资结构等）
- 审批流：离职、薪资调整等关键操作需主管审批
- 可按模块设置权限（如考勤专员只能操作考勤模块）
优先级：P2 中
优先级汇总
| 优先级 | 编号 | 问题 | 状态 |
|---|---|---|---|
| 优先级 | 编号 | 问题 | 验证状态 |
| -------- | ------ | ------ | ---------- |
| 2.1 | 导入错误提示乱码 | ⚠️ 部分存在（已有错误展示和导出，但信息可能含英文字段名） | |
| 4.1 | 社保基数不同步 | ❌ 不存在（代码已正确实现优先级 socialInsBase > salary） | |
| P0 紧急 | 8.1 | 员工办理关键信息未设必填 | ✅ 确认存在 |
| 10.1 | 离职审批状态无法更改 | ❌ 不存在（已实现完整审批流程） | |
| P1 高 | 1.1 | 发薪数据每月需重新导入 | ✅ 确认存在 |
| P1 高 | 3.1 | 工资流水导出格式适配银行 | ✅ 确认存在 |
| P1 高 | 5.1 | 商险管理添加员工入口缺失 | ✅ 确认存在 |
| 6.1 | 员工福利月度汇总无数据 | ❌ 系统无福利模块 | |
| P2 中 | 7.1 | 证据链验证不清晰 | ⚠️ 部分存在（有验证但不显示具体原因） |
| P2 中 | 9.1 | 员工删除限制 | ✅ 确认存在（无删除入口） |
| P2 中 | 13.1 | 角色权限分工 | ✅ 确认存在 |
| P3 规划 | 11.1 | 花名册职责边界重构 | ⚠️ 部分存在 |
| P3 规划 | 12.1 | 招聘模块 | ✅ 确认不存在 |
备注
代码验证结论
已确认存在的问题（需修复）
- #8 员工办理必填项缺失：
WorkProcess.tsx无任何表单必填校验，只填姓名即可提交 - #5 商险添加员工入口缺失：
CommercialInsuranceTab.tsx无添加参保员工按钮和 API - #1 发薪数据重复导入：无「复制上月批次」功能
- #3 工资流水无银行格式导出：
PayslipTab.tsx无导出功能 - #9 员工无法删除：花名册无删除入口
- #12 无招聘模块：系统中完全不存在
- #13 角色权限无专员/主管分工：仅四级角色
不存在或已实现的问题（无需修复）
- #4 社保基数不同步：
payroll.service.ts:166已正确实现socialInsBase || salary优先级，问题可能是用户未设置socialInsBase - #10 离职审批无法更改：
Termination.tsx:967-993已实现完整审批操作（通过/驳回），用户可能未找到详情入口 - #6 员工福利汇总无数据：系统中无福利模块，需澄清用户具体指什么
部分存在的问题（可优化）
- #2 导入错误乱码：已有错误展示和导出功能，但错误信息可能含英文字段名
- #7 证据链验证：有验证功能但不显示具体异常原因
- #11 花名册职责边界：编辑功能已模块化分区但确实集中在花名册中
备注
- #4 和 #10 经代码验证不构成 bug，降级处理
- #6 需与用户澄清具体需求
- #12 招聘模块为大型新功能，建议单独规划版本迭代