文件
hyb-oa/docs/海音达OA-MVP需求规格说明书.md
T

18 KiB
原始文件 Blame 文件历史

海音达 OA 系统 - MVP 需求规格说明书

版本:2.0 日期:2026-05-09 范围:10 人以下科技公司试运行 MVP 需求基线 状态:当前 PRD 主事实源

相关文档:


1. 项目目标与当前路线

1.1 背景

海音达需要一套适合 10 人以下科技公司的轻量 OA,用来把报销、请假、采购、费用、合同、项目资料、审批和基础行政动作集中到一个可审计、可回归、可持续迭代的系统中。系统不追求一次性替代所有办公平台,而是先解决公司内部最容易割裂、最需要留痕的业务流程。

1.2 总目标

  • hyb-oa 是唯一业务主系统和唯一正式审批中心。
  • 所有正式审批在 OA 内提交、审批、留痕、归档。
  • 企业微信只作为基础设施:手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡原始采集。
  • PC 用户可直接访问 OA;手机端优先从企业微信工作台进入 OA 移动端。
  • 后续开发必须先有需求事实源和 Issue CSV 执行合同,避免边想边做。

1.3 当前平台边界

平台 定位 首批使用方式 不承担
hyb-oa 唯一业务主系统和审批中心 审批、报销、发票、OCR、请假、采购、合同台账、项目资料、审计归档 聊天、会议、在线文档协作
企业微信 基础设施 手机入口、免登/绑定、通知 deeplink、通讯录身份、打卡原始采集 正式审批流、财务附件主库、业务单据主库
飞书 已废弃路线 不进入首批实现 不接入身份、审批、通知、文档或项目主线

2. 软件开发项目流程

后续所有非微小改动按以下流程推进:

  1. 需求收集与边界确认:明确目标用户、业务流程、必须做、暂不做、验收标准。
  2. 需求文档冻结:更新本文件或对应规则文档,形成产品、开发、测试共同事实源。
  3. 执行合同拆分:新建 issues/YYYY-MM-DD_HH-mm-ss-<slug>.csv,写清范围、验收、测试、依赖。
  4. 技术方案设计:明确接口、数据模型、权限、状态机、前端入口、回滚策略。
  5. 开发实现:按 Issue 分后端、前端、QA 阶段推进,不顺手做无关改动。
  6. 测试与回归:先单点验证,再业务流程回归,最后做 PC/移动/企业微信入口验证。
  7. 部署与验收:部署后检查 /ready、前端资源、关键路径、企业微信真机入口。
  8. 复盘与下一轮规划:把试运行反馈转成新 Issue CSV,不直接插入开发。

3. 用户角色与典型场景

角色 主要目标 高频动作 关键要求
老板/总经理 看清公司待办、费用、项目风险和审批瓶颈 审批大额事项、看项目和费用摘要、处理关键待办 少打扰、信息集中、审批记录可信
管理员/HR 维护人员、入口、制度、请假和基础行政 员工管理、请假/补卡审核、公告、入离职、权限配置 配置清晰、可回退、有审计
部门主管/项目负责人 管团队交付和日常审批 审批报销/请假/采购、查看团队状态、跟进项目事项 待办清楚、移动端可处理
普通员工 快速提交申请和查状态 报销、上传发票、请假、补卡、外出、加班、采购申请、周报 手机好用、字段少、失败提示明确
财务 管报销、发票、付款和导出 发票查重、OCR 修正、付款标记、财务导出 数据完整、附件可追溯、重复票据可控
系统管理员 保障系统可用和可维护 部署、备份、恢复、日志、功能开关、企业微信配置 不泄露密钥、可定位问题、可回滚

4. MVP 模块优先级

优先级 模块 目标 主入口 验收口径
P0 统一审批中心 所有正式审批在 OA 内处理 PC 审批待办、移动审批 能提交、审批、驳回、退回、转审、留痕
P0 企业微信基础设施 手机入口、免登、通知、打卡原始采集 企业微信自建应用 海音达工作台 手机进入 /mobile,通知 deeplink 回 OA
P0 报销/发票/OCR 员工自助报销,财务可查重和导出 报销、移动报销、票据中心 上传、OCR、查重、绑定、审批、付款闭环
P0 请假与考勤修正审批 请假、补卡、外出、加班等修正都在 OA 内审批 请假、移动审批、团队状态 审批后团队状态和考勤口径不破坏
P1 采购/费用审批 小团队采购和费用事项留痕 采购、审批待办 申请、附件、审批、状态更新可用
P1 合同与附件归档 管合同编号、责任人、归档位置和非涉密附件 合同/项目资料或项目页 能登记、查询、关联项目和审批记录
P1 项目轻管理 把费用、采购、差旅、周报挂到项目 项目、Portal、周报 能看项目事项、风险、费用摘要,不做重型排产
P2 预算/支付/ERP/AI 在试运行稳定后增强运营能力 管理员备用入口 另立 Issue CSV,不进入首批验收

5. 统一审批中心需求

本章保留总纲口径。审批中心的角色、入口、状态、动作、权限、异常、留痕和验收细节,以 需求 - 统一审批中心规约 作为后续开发拆分依据。

5.1 范围

OA 是公司唯一正式审批中心。以下审批必须在 OA 内提交、审批、留痕、归档:

  • 报销、费用、采购。
  • 合同相关审批和合同台账维护。
  • 请假、补卡、外出、加班、出差。
  • 资产领用、归还、调拨、盘点中的需要留痕动作。
  • 后续新增业务审批,默认也进入 OA 审批中心。

企业微信原生审批不作为公司正式审批入口,不允许形成“一部分审批在企业微信、一部分审批在 OA”的双轨口径。

5.2 审批能力

  • 支持草稿、提交、审批中、通过、驳回、退回、撤回、转审、完成等状态语义。
  • 审批链优先采用串行多节点;当前阶段不做并行会签。
  • 大额或高风险单据通过审批规则配置多级审批,不通过硬编码角色分叉。
  • 当前审批人只能处理分配给自己的待办,或者处理分配给自己角色且权限匹配的待办。
  • 转审必须记录原因,转给具备对应审批权限的人,并保留转审历史。
  • 单据编号由 OA 生成和保存;报销单、采购单、合同编号等应使用统一编号规则或对应业务编号规则。

5.3 数据与留痕

  • 所有审批动作写入工作流历史。
  • 关键例外动作写入审计日志,包括重复发票例外、付款标记、权限变更、附件下载、通知重试。
  • 企业微信消息只包含脱敏标题、业务编号、状态和 deeplink,不包含涉密正文、完整发票、合同正文或敏感报价。

5.4 验收

  • 审批人可在 PC 和移动端看到待办。
  • 审批动作完成后,业务单据状态、审批历史、通知和审计记录一致。
  • 企业微信提醒点击后回到 OA 页面处理,不能在企业微信原生审批里完成正式审批。

6. 报销、发票、OCR、附件与财务导出

本章保留总纲口径。报销、发票、OCR、附件、查重、财务复核、付款和导出的细化要求,以 需求 - 报销发票 OCR 规约 作为后续开发拆分依据;历史细则继续参考 报销与发票规则。

6.1 用户流程

  1. 员工在 PC 或手机端创建报销草稿。
  2. 上传发票图片、PDF 或必要附件。
  3. 系统执行 OCR,识别发票代码、号码、金额、日期、销方、购方等关键字段。
  4. 员工确认或修正识别结果,补充费用明细和说明。
  5. 系统做发票查重和基础校验。
  6. 员工提交报销,进入 OA 审批流。
  7. 审批通过后,财务复核并标记付款。
  8. 财务按期间、状态、项目、人员导出报销和发票数据。

6.2 发票与附件管理

  • 发票和附件原始文件以 OA/对象存储为主,不依赖企业微信长期保存。
  • 同一发票不得被重复报销;如确需例外,必须由授权财务角色填写原单号和原因。
  • OCR 失败时允许重试和人工修正,但必须保留失败原因和修正痕迹。
  • 报销完成后,相关发票进入已使用或归档状态,不能被普通员工再次绑定到新单据。
  • 普通员工只看到“添加发票、上传附件、提交审批、查看状态”等业务语言,不暴露内部发票池概念。

6.3 财务导出

  • 财务可按报销状态、付款状态、员工、部门、项目、期间筛选导出。
  • 导出数据应包含业务编号、申请人、实际报销人、金额、费用类型、发票摘要、审批状态和付款状态。
  • 导出不得包含未授权敏感字段明文。

6.4 验收

  • 手机拍照或上传发票后,能完成 OCR、查重、绑定、提交。
  • 报销审批通过后,财务能付款标记并导出。
  • 重复发票、OCR 失败、附件缺失、金额不一致等异常有明确提示。

7. 请假、补卡、外出、加班与考勤口径

7.1 边界

  • 企业微信打卡用于原始采集,保留其定位、人脸、Wi-Fi、排班和设备能力。
  • OA 不在首批重造打卡规则、定位、人脸识别或排班引擎。
  • 请假、补卡、外出、加班等考勤修正申请在 OA 内提交和审批。
  • 后续可同步企业微信打卡原始记录,再结合 OA 审批形成正式考勤口径。

7.2 用户流程

  • 员工在 OA 提交请假、补卡、外出或加班申请。
  • 主管或 HR 在 OA 审批。
  • 审批通过后,团队状态、日历和后续考勤统计使用 OA 的审批结果。
  • 企业微信打卡异常不直接等于最终考勤异常,最终口径以 OA 汇总为准。

7.3 验收

  • 请假提交、审批、撤回、驳回后状态正确。
  • 已批准请假能影响团队状态或日历展示。
  • 文档和界面不引导员工去企业微信原生审批提交请假或补卡。

8. 采购、费用、合同与项目资料

8.1 采购和费用审批

  • 员工可提交采购或费用申请,填写用途、金额、项目、供应商、附件和期望时间。
  • 主管、财务或老板按规则审批。
  • 审批通过后形成可追溯记录,可关联预算、项目、付款和合同资料。
  • 首批优先支持轻量申请和审批,不做复杂招采流程。

8.2 合同与附件归档

  • 合同管理首批以台账为主:合同编号、名称、客户或供应商、项目、金额、负责人、状态、归档位置。
  • 非涉密附件可进入 OA;涉密合同正文、敏感报价、成本细节和客户敏感资料不得进入公网 OA。
  • 合同编号应由 OA 统一生成或由管理员登记后校验唯一性。
  • 合同相关审批和变更记录应回到 OA 留痕。

8.3 项目轻管理

  • 项目页只做轻量管理:成员、里程碑、任务、风险、交付记录、费用/采购/差旅关联。
  • 不做重型甘特图、资源排产、CRM 或完整项目组合管理。
  • 员工的报销、采购、差旅、周报和待办应尽量关联项目,减少另建表格。

8.4 验收

  • 采购申请可提交、审批和查看状态。
  • 合同台账能记录编号、责任人、归档位置和项目关联。
  • 项目视图能汇总关键事项,不要求替代专业项目管理工具。

9. 企业微信基础设施需求

9.1 自建应用

  • 公司只维护一个企业微信自建应用,建议命名为 海音达工作台。
  • 手机端默认入口进入 /mobile。
  • PC 浏览器和普通账号密码登录默认进入 /portal。
  • 企业微信入口失败时必须保留账号密码登录回退路径。

9.2 免登与绑定

  • 支持企业微信 OAuth 或免登后识别员工身份。
  • 首次未绑定时,员工可使用账号密码登录后在个人设置中完成绑定。
  • 一个企业微信身份不得绑定多个员工。
  • 员工离职或账号停用后,企业微信入口也不得继续进入业务系统。

9.3 消息通知

  • 企业微信消息只做提醒,审批动作必须回到 OA 页面完成。
  • 消息内容最小化:标题、业务编号、状态、处理入口。
  • 发送失败应可重试,不阻断主业务提交或审批。
  • 不在消息中发送合同正文、完整发票、敏感报价、银行卡、身份证等敏感内容。

9.4 打卡原始采集

  • 企业微信打卡数据可作为后续同步来源。
  • 首批不新增企业微信打卡 API 同步实现。
  • 正式考勤统计必须结合 OA 的请假、补卡、外出、加班审批结果。

10. 权限、审计、数据安全与非功能要求

10.1 权限原则

  • 后端是权限单一事实源;前端按钮显隐不等于授权。
  • 普通员工只能看和处理自己的单据。
  • 审批人只能处理分配给自己的待办或自己角色范围内的待办。
  • 财务可处理发票、付款和导出,但不默认拥有系统管理权限。
  • HR/管理员可维护人员、组织和基础配置,但敏感操作必须审计。
  • 老板/总经理可查看公司级摘要和处理关键审批,但仍应保留操作留痕。

10.2 审计要求

以下动作必须可追溯:

  • 登录、退出、绑定、解绑、账号停用。
  • 单据提交、审批、驳回、退回、撤回、转审。
  • 发票上传、OCR 重试、人工修正、重复例外、附件下载。
  • 付款标记、财务导出、合同归档、权限变更。
  • 企业微信通知发送失败、重试和配置异常。

10.3 数据安全

  • 密码、密钥、令牌不得写入文档、日志或前端包。
  • 银行卡、身份证、手机号等敏感字段对外响应应脱敏。
  • 附件下载应有鉴权和有效期控制。
  • 涉密合同正文、详细报价、成本细节、敏感客户资料不进入公网 OA。
  • 生产环境必须有数据库和文件存储备份,并定期做恢复演练。

10.4 非功能要求

  • PC 和移动端都应覆盖高频流程。
  • 10 人以下团队的常用列表和表单应保持快速响应。
  • 关键错误需要给出可操作提示,例如未绑定、权限不足、审批人缺失、OCR 失败、重复发票。
  • 部署后必须能通过 /ready 检查服务状态。
  • 新功能应有可复现测试步骤,无法自动化时写清人工验收步骤。

11. 暂不做范围

首批 MVP 不做以下事项:

  • 不接入飞书,不保留飞书登录、通知、审批、文档或项目管理路线。
  • 不使用企业微信原生审批作为正式审批流。
  • 不开发复杂 BPM 流程设计器,不做并行会签建模。
  • 不依赖付费低代码平台、付费第三方应用或付费项目管理套件。
  • 不重造企业微信打卡的定位、人脸识别、Wi-Fi、排班规则。
  • 不做完整 CRM、ERP、PLM、甘特排产或项目组合管理。
  • 不把聊天记录、会议纪要、涉密合同正文或敏感报价长期保存在 OA。

12. MVP 验收标准

12.1 产品验收

  • 老板能在 OA 中看到审批待办、项目/费用摘要和关键风险。
  • 员工能在 PC 或手机端完成报销、请假、采购等核心申请。
  • 审批人能在 PC 和移动端处理待办。
  • 财务能完成发票查重、付款标记和导出。
  • 管理员能维护人员、权限、企业微信入口和基础配置。
  • 企业微信只作为入口和提醒,不产生正式审批分叉。

12.2 流程验收

场景 验收步骤
报销主流程 上传发票 -> OCR -> 绑定明细 -> 提交 -> 审批 -> 付款 -> 导出
重复发票 上传已使用发票 -> 系统阻断 -> 财务授权例外需原因和原单号
请假流程 员工提交请假 -> 主管审批 -> 团队状态或日历更新
采购流程 员工提交采购 -> 审批通过或驳回 -> 状态和附件可追溯
企业微信入口 手机企业微信进入 /mobile -> 账号已绑定则直达,未绑定可回退账号密码
企业微信通知 收到审批提醒 -> 点击 deeplink -> 回到 OA 审批页处理
文档门禁 新需求先更新 PRD 或规则文档,再拆 Issue CSV,不直接开发

12.3 工程验收

  • Issue CSV 校验通过。
  • 文档 diff 检查通过。
  • 涉及后端时执行 Prisma、语法和相关回归脚本。
  • 涉及前端时执行 typecheck、build 和相关 Playwright。
  • 涉及公网或企业微信真机时,必须部署后检查 /ready、前端资源和真实入口。

13. 后续 Backlog

后续事项必须另立 Issue CSV,不直接进入当前 MVP:

  • 企业微信打卡 API 同步和考勤汇总报表。
  • 补卡、外出、加班的完整移动端体验强化。
  • 合同台账、合同编号、合同审批和离线档案号的细化。
  • 预算控制、支付批次、AP 运营和 ERP 出站凭证增强。
  • 项目轻管理与周报、待办、费用、采购、差旅的进一步联动。
  • 全量 E2E 稳定性清理和移动视觉回归。
  • 生产备份恢复演练、并发试运行和正式上线复核。

14. 文档维护规则

  • 本文件回答“要做什么、为什么做、先做什么、不做什么、如何验收”。
  • docs/product-decisions.md 记录已经拍板的产品口径。
  • docs/feature-matrix.md 记录已经实现了什么和证据在哪里。
  • issues/*.csv 是每轮开发执行合同。
  • 需求变化必须先更新本文件或对应规则文档,再创建新的 Issue CSV。
  • 不批量回改旧 Issue CSV 来伪造一致性;历史计划保留为历史快照。