# 企业用工专家 — 功能补齐方案 > 日期:2026-07-30 > 依据:白话用工侠完整运行测试报告对比分析 > 优先级:🔴 高 / 🟡 中 --- ## 一、用工办理工作流系统(13类流程)🔴 ### 1.1 目标 实现统一的用工办理工作流系统,覆盖员工从录用到离职的全生命周期办理事项。 ### 1.2 13类流程定义 | 编号 | 流程名称 | 核心表单字段 | 关联模块 | |------|---------|------------|---------| | 1 | 员工录用 | 人员选择、入职时间、公司地址、部门、岗位、直属上级、联系方式、试用期薪酬、转正薪酬、携带材料 | 员工创建+合同起草 | | 2 | 员工入职 | 入职日期、岗位确认、合同签署方式、材料提交清单 | 员工状态→ACTIVE | | 3 | 自定义合同签署 | 合同模板选择、变量填充、签署方、期限 | 合同管理 | | 4 | 员工信息提交 | 信息变更字段、证明材料 | 员工档案更新 | | 5 | 员工转正 | 转正日期、转正薪资、考核结果 | 员工状态+薪资变更 | | 6 | 合同变更 | 变更类型、变更内容、生效日期 | 合同管理 | | 7 | 合同续签 | 续签次数、新期限、新薪资 | 合同管理 | | 8 | 合同中止 | 中止原因、中止期限、预计恢复日期 | 合同状态 | | 9 | 开具收入证明 | 用途、收入期间、接收方 | 文本模板渲染 | | 10 | 合同终止 | 终止原因、终止日期、经济补偿 | 合同状态+离职 | | 11 | 合同解除 | 解除原因、解除方式、协商/单方 | 已有 Termination 模块复用 | | 12 | 开具离职证明 | 离职日期、离职原因、接收方 | 文本模板渲染 | | 13 | 灵活用工 | 人员信息、用工类型、协议期限、计酬方式 | 合同管理(LABOR) | ### 1.3 数据模型设计 ```prisma // 用工办理流程 model WorkProcess { id String @id @default(cuid()) orgId String org Organization @relation(fields: [orgId], references: [id], onDelete: Cascade) type String // HIRE/ONBOARD/CUSTOM_CONTRACT/INFO_SUBMIT/CONFIRM/CHANGE/RENEW/SUSPEND/INCOME_CERT/TERMINATE/RESCIND/LEAVING_CERT/FLEXIBLE title String employeeId String? employee Employee? @relation(fields: [employeeId], references: [id]) status String @default("DRAFT") // DRAFT/PENDING_APPROVAL/APPROVED/REJECTED/EXECUTING/COMPLETED/CANCELLED formData Json // 表单数据 JSON documents Json? // 生成的文书列表 [{name, content, type}] approverId String? approvedAt DateTime? remark String? createdBy String createdAt DateTime @default(now()) updatedAt DateTime @updatedAt @@index([orgId, status]) @@index([orgId, type]) @@index([orgId, createdBy]) } ``` ### 1.4 前端架构 **新增页面**:`frontend/src/pages/WorkProcess.tsx` ``` 页面结构: ├── 发起办理(13类流程卡片选择) ├── 办理记录(列表+筛选:类型/状态/日期) ├── 办理草稿(仅 DRAFT 状态) └── 流程详情(步骤条+表单+预览+操作) ``` **流程详情组件**(通用 Wizard): - 步骤条:填写信息 → 预览文书 → 存草稿/提交 - 表单根据 `type` 动态渲染字段 - 预览:调用文本模板渲染接口生成文书 - 提交后根据流程类型执行对应业务逻辑 **复用已有模块**: - 合同解除(#11)→ 复用 `Termination.tsx` 的 Wizard 逻辑 - 合同续签(#7)→ 复用 `Contracts.tsx` 的合同管理逻辑 - 收入证明(#9)/ 离职证明(#12)→ 复用 `Templates.tsx` 的模板渲染 - 员工录用(#1)→ 复用 `roster/modals.tsx` 的添加员工逻辑 ### 1.5 后端接口 ``` POST /api/v1/work-processes # 创建办理(含草稿) GET /api/v1/work-processes # 列表查询(支持type/status筛选) GET /api/v1/work-processes/:id # 详情 PATCH /api/v1/work-processes/:id # 更新草稿 POST /api/v1/work-processes/:id/submit # 提交办理 POST /api/v1/work-processes/:id/approve # 审批通过 POST /api/v1/work-processes/:id/reject # 驳回 POST /api/v1/work-processes/:id/cancel # 撤销 DELETE /api/v1/work-processes/:id # 删除草稿 GET /api/v1/work-processes/:id/preview # 预览生成的文书 ``` ### 1.6 提交后业务联动 | 流程类型 | 提交后执行 | |---------|-----------| | HIRE | 创建员工记录 + 创建劳动合同 | | ONBOARD | 更新员工状态为 ACTIVE + 记录入职日期 | | CUSTOM_CONTRACT | 创建劳动合同 | | INFO_SUBMIT | 更新员工档案字段 | | CONFIRM | 更新试用期结束 + 调整薪资 | | CHANGE | 更新合同字段 + 记录变更历史 | | RENEW | 关闭旧合同 + 创建新合同 | | SUSPEND | 合同状态改为 SUSPENDED | | INCOME_CERT | 生成收入证明文书(不改变业务数据) | | TERMINATE | 合同状态改为 TERMINATED + 触发离职流程 | | RESCIND | 调用已有 Termination 逻辑 | | LEAVING_CERT | 生成离职证明文书 | | FLEXIBLE | 创建劳务协议合同 | ### 1.7 实现优先级 1. **Phase 1**:数据模型 + 基础 CRUD + 列表/草稿页面 2. **Phase 2**:员工录用、员工入职、合同续签、合同终止(4个高频流程) 3. **Phase 3**:剩余9类流程 + 文书预览生成 4. **Phase 4**:审批流程 + 办理记录导出 --- ## 二、企业自建文本库 🟡 ### 2.1 目标 允许企业创建、管理和复用自己的文本模板(合同、通知、协议等),与系统预置模板库并存。 ### 2.2 数据模型设计 ```prisma // 企业自建文本模板 model EnterpriseTemplate { id String @id @default(cuid()) orgId String org Organization @relation(fields: [orgId], references: [id], onDelete: Cascade) name String category String // CONTRACT/RULES/NOTICE/AGREEMENT/OTHER description String? content String @db.Text variables String[] // 变量名列表 status String @default("ACTIVE") // ACTIVE/ARCHIVED createdBy String createdAt DateTime @default(now()) updatedAt DateTime @updatedAt @@index([orgId, category]) } ``` ### 2.3 前端方案 **改造页面**:`frontend/src/pages/Templates.tsx` 在现有模板库页面顶部新增 Tab 切换: - **系统模板库**(现有功能不变) - **企业文本库**(新增) 企业文本库 Tab 内容: ``` ├── 查询栏(名称搜索 + 分类筛选) ├── 新建/编辑弹窗(名称、分类、变量配置、内容编辑) ├── 模板卡片列表(复用现有卡片样式) ├── 详情弹窗(变量填写 → 渲染 → 下载Word/复制) └── 操作:编辑、复制、删除、归档 ``` ### 2.4 后端接口 ``` # 现有模板路由:/api/v1/templates(系统预置,只读) # 新增企业模板路由:/api/v1/enterprise-templates GET /api/v1/enterprise-templates # 列表(支持category/search) POST /api/v1/enterprise-templates # 新建 GET /api/v1/enterprise-templates/:id # 详情 PUT /api/v1/enterprise-templates/:id # 更新 DELETE /api/v1/enterprise-templates/:id # 删除 POST /api/v1/enterprise-templates/:id/render # 渲染(复用现有 renderTemplate 逻辑) GET /api/v1/enterprise-templates/:id/download # 下载Word ``` ### 2.5 实现要点 - 变量提取:编辑内容时自动扫描 `{{变量名}}` 提取变量列表 - 渲染逻辑:复用 `template.service.ts` 的 `renderTemplate` 函数 - 内容编辑器:使用 textarea + 变量插入按钮(点击插入 `{{变量名}}`) - 权限:ADMIN/HR 可增删改,VIEWER 只读 --- ## 三、考勤/工资条发布流程 🟡 ### 3.1 考勤发布 #### 目标 HR 在考勤管理页面将月度考勤数据"发布"给员工,员工在员工端查看并确认。 #### 数据模型 ```prisma // 考勤发布记录 model AttendancePublish { id String @id @default(cuid()) orgId String org Organization @relation(fields: [orgId], references: [id], onDelete: Cascade) month String // 2026-07 title String // 如"2026年7月考勤表" status String @default("PUBLISHED") // PUBLISHED/CANCELLED publishDate DateTime @default(now()) createdBy String createdAt DateTime @default(now()) @@unique([orgId, month]) @@index([orgId, month]) } ``` #### 前端改造:`Attendance.tsx` 在「考勤确认」Tab 工具栏新增: - **「发布考勤表」按钮**:弹窗确认 → 选择月份 → 发布 - **「发布记录」入口**:查看历史发布记录,可取消发布 #### 后端接口 ``` POST /api/v1/attendance/publish # 发布考勤表 GET /api/v1/attendance/publish-records # 发布记录列表 POST /api/v1/attendance/publish/:id/cancel # 取消发布 ``` #### 员工端:`portal/` 新增考勤查看页面 ``` GET /api/v1/portal/attendance?month=2026-07 # 员工查看自己的月度考勤 ``` ### 3.2 工资条发布 #### 目标 HR 在薪税管理中将批次工资条"发布"给员工,员工在员工端查看并确认。支持定时发送。 #### 数据模型 复用已有 `Payslip` 模型,新增发布状态字段: ```prisma // 在 Payslip 模型新增字段 model Payslip { // ...已有字段 publishStatus String? // UNPUBLISHED/PUBLISHED/SCHEDULED publishedAt DateTime? scheduledAt DateTime? // 定时发送时间 confirmedAt DateTime? // 员工确认时间(已有) } ``` #### 前端改造:`Money.tsx` 在批次详情页新增: - **「发布工资条」按钮**:将批次内所有工资条标记为 PUBLISHED - **「定时发送」选项**:选择发送时间,到点自动发布 - **「定时发送记录」入口**:查看定时发送列表,可取消 #### 后端接口 ``` POST /api/v1/payroll/batches/:batchId/publish # 发布工资条 POST /api/v1/payroll/batches/:batchId/schedule # 定时发送 GET /api/v1/payroll/schedule-records # 定时发送记录 POST /api/v1/payroll/schedule/:id/cancel # 取消定时发送 ``` #### 员工端:已有 `portal/Payslip.tsx` - 发布前:员工端不显示该月工资条 - 发布后:员工端显示工资条,可查看和确认 - 定时发送:到点后状态从 SCHEDULED → PUBLISHED #### 定时发送实现 - 使用 `node-cron` 或现有定时任务机制 - 每分钟检查 `scheduledAt <= now && publishStatus = SCHEDULED` 的记录 - 自动更新为 PUBLISHED 并发送通知 --- ## 四、AI文件审查上传功能 🔴 ### 4.1 目标 在现有合同审查功能基础上,支持上传 doc/docx 文件,自动提取文本后进行 AI 审查。 ### 4.2 前端改造:`AIAssistant.tsx` ReviewTab 在现有粘贴文本输入框上方新增文件上传区域: ``` 合同审查 Tab 改造: ├── 文件上传区(新增) │ ├── 文书类型选择(劳动合同/协商解除/劳务协议/实习协议/保密协议) │ ├── 拖拽或点击上传 .doc/.docx 文件 │ ├── 文件大小限制:100MB │ └── 上传后自动提取文本并填入下方输入框 ├── 文本输入框(现有) ├── 开始审查按钮(现有) └── 审查结果展示(现有) ``` ### 4.3 后端改造 #### 文件上传接口 ``` POST /api/v1/ai/review/upload - multipart/form-data - 接收 doc/docx 文件 - 提取纯文本 - 返回 { text: "提取的文本内容" } ``` #### 文本提取方案 使用 `mammoth` 库提取 .docx 文本: ```typescript import mammoth from 'mammoth' // .docx 文件提取 const result = await mammoth.extractRawText({ buffer: req.file.buffer }) const text = result.value // .doc 文件(旧格式) // 方案1:使用 antiword 命令行工具 // 方案2:提示用户转换为 .docx // 推荐:仅支持 .docx,.doc 提示转换 ``` #### 完整审查流程 ```typescript // 1. 上传文件 → 提取文本 POST /ai/review/upload → { text } // 2. 前端将文本填入输入框(用户可编辑) // 3. 点击审查 → 调用现有 /ai/review 接口 POST /ai/review { contractText } → 审查结果 ``` ### 4.4 依赖安装 ```bash cd backend && npm install mammoth ``` ### 4.5 安全考虑 - 文件大小限制:100MB(`multer` limits) - 文件类型校验:仅 `.doc` 和 `.docx` - 提取后不保存原文件,仅返回文本 - 文本长度截断:超过 50000 字符时截断并提示 --- ## 五、实施计划 ### 5.1 优先级排序 | 优先级 | 功能 | 预估工作量 | 建议时间 | |--------|------|-----------|---------| | 🔴 高 | AI文件审查上传 | 1-2天 | 立即 | | 🔴 高 | 用工办理工作流 Phase 1-2 | 5-7天 | 本周 | | 🟡 中 | 企业自建文本库 | 2-3天 | 下周 | | 🟡 中 | 考勤发布 | 2天 | 下周 | | 🟡 中 | 工资条发布 | 2-3天 | 下周 | | 🔴 高 | 用工办理工作流 Phase 3-4 | 5-7天 | 第三周 | ### 5.2 总计 - **总工作量**:约 17-24 个工作日 - **建议分3周完成**: - 第1周:AI文件审查 + 用工办理Phase 1-2 - 第2周:企业文本库 + 考勤发布 + 工资条发布 - 第3周:用工办理Phase 3-4 + 联调测试 ### 5.3 数据库迁移 所有新增模型需要执行 `npx prisma db push` 同步到数据库。 --- ## 六、风险与注意事项 1. **用工办理工作流**是最复杂的功能,建议先实现4个高频流程(录用/入职/续签/终止),验证架构后再扩展 2. **企业文本库**的变量提取逻辑需与系统模板保持一致,复用 `renderTemplate` 函数 3. **工资条发布**涉及薪资敏感数据,需确保只有发布后员工端才能看到 4. **AI文件审查**的 .doc 旧格式支持有限,建议仅支持 .docx 并提示用户转换 5. **定时发送**需要确保服务器进程持续运行(PM2 已有保障)