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

34 KiB
原始文件 Blame 文件历史

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

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

相关文档:


1. 项目目标与当前路线

1.1 背景

海音达需要一套适合 10 人以下科技公司的轻量 OA,用来把报销、采购、费用、合同、项目资料、财务闭环、审计和关键行政数据集中到一个可审计、可回归、可持续迭代的系统中。WFOC 起产品方向调整为“企微优先 + OA 无痛接管”;DBWFOC 进一步修正边界:能复用企业微信成熟功能的 HR/考勤员工日常场景优先使用企业微信,OA 做按域镜像、人工接管、恢复回写、财务闭环和审计中台;采购、合同、项目、财务和高敏附件仍由 OA 主办和存储。

1.2 总目标

  • HR/考勤员工日常审批优先复用企业微信成熟能力;OA 同步按域镜像并保留人工接管和恢复回写能力。
  • 报销、PDF 发票 OCR、发票查重、付款批次、银行回单、AP 台账、代账交接和财务审计继续由 OA 主办。
  • 企业微信作为手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡、人事助手和 HR/考勤员工日常审批主操作端。
  • 采购、费用、合同、项目、报销、付款、AP、代账交接和敏感附件不迁移到企业微信原生审批或企业微信附件;企业微信只发送脱敏提醒和 OA deeplink。
  • PC 用户可直接访问 OA;手机端优先从企业微信工作台进入 OA 移动端。
  • 后续开发必须先有需求事实源和 Issue CSV 执行合同,避免边想边做。

1.3 当前平台边界

平台 定位 首批使用方式 不承担
hyb-oa 财务主系统、OA 主办业务系统、按域镜像、接管和审计中台 报销、发票、OCR、付款批次、银行回单、AP 台账、代账交接、采购/合同/项目轻台账、企微 HR/考勤数据镜像和应急接管 重造企业微信成熟打卡、人事和 HR/考勤员工日常审批能力;把 OA 主办高敏数据全量镜像到企微
企业微信 HR/考勤员工日常主操作端、移动入口和消息通道 通讯录、人事助手花名册、打卡规则/排班/日报/月报、请假/补卡/外出/加班审批、假期余额、工作台入口和脱敏消息 财务附件主库、报销 OCR、付款批次、代账交接、采购/合同/项目附件主库、OA 审计主库
飞书 已废弃路线 不进入首批实现 不接入身份、审批、通知、文档或项目主线

1.4 WFOC 需求分层

层级 主办方 目标
企微主办层 企业微信 通讯录、人事助手花名册、打卡规则/排班/日报/月报、请假/补卡/外出/加班审批、假期余额。
OA 镜像层 OA 按域同步企微主办的人员、部门、HR/考勤审批单、打卡、规则、附件、回调和操作日志,形成可查询、可导出、可审计的副本。
OA 接管层 OA 企微不可用时由管理员人工开启 oa_hr_emergency_mode_v1,员工通过 OA 账号密码提交 HR/考勤类应急申请。
恢复回写层 OA + 企业微信 API 企微恢复后由 wecom_recovery_writeback_v1 对应急数据执行 dry-run、自动回写、失败重试和冲突清单。
财务主办层 OA 报销、PDF 发票 OCR、发票查重、付款批次、银行回单、AP 台账、代账交接继续 OA 主办,不迁移到企微。

无痛切换是长期目标,不代表本轮已实现完整替代。完整镜像按域定义:企微主办域镜像到 OA;OA 主办域不反向全量镜像到企微,只发送脱敏标题、业务类型、业务编号、状态和 OA 链接。后续必须按 wecom_hr_master_sync_v1、wecom_native_approval_mirror_v1、oa_hr_emergency_mode_v1、wecom_recovery_writeback_v1 和 wecom_ruleops_v1 分阶段拆 Issue CSV。

1.5 DBWFOC 数据边界修正

  • 企业微信成熟功能可以作为产品流程、字段、交互和规则参考;参考不等于把业务数据托管到企业微信。
  • HR/考勤员工日常审批第一阶段仅限请假、补卡、外出、加班和相关假期余额/考勤解释。
  • 采购、费用、合同、项目、报销、付款批次、AP、代账交接和审计继续 OA 主办;审批动作、附件查看、下载、导出和审计仍以 OA 服务端权限为准。
  • 采购单附件、合同正文、供应商报价、项目敏感资料、发票原件、银行回单、付款资料和代账资料不上传到企业微信原生审批或企业微信附件。
  • OA 主办审批仍可通过企业微信个人应用消息提醒;消息只包含脱敏摘要和 OA deeplink,点击后通过企业微信免登录或账号绑定回到 OA 目标审批页处理。

2. 软件开发项目流程

后续所有非微小改动按标准软件开发流程推进。流程目标不是增加仪式感,而是保证每轮都有清晰需求、可执行方案、可验证结果、可回滚边界和可追溯记录。

阶段 目标 输入 输出 门禁
1. 需求收集与边界确认 明确为什么做、谁使用、解决什么流程问题 用户反馈、试运行问题、业务制度、当前 PRD 和模块规约 需求描述、目标角色、主流程、必须做、暂不做、验收口径 需求不清不得进入开发;高风险歧义必须先澄清
2. 需求文档冻结 形成产品、开发、测试共同事实源 主 PRD、模块规约、产品口径文档、历史 Issue 更新后的 PRD 或模块规约 没有事实源更新,不拆开发 Issue
3. Issue CSV 执行合同拆分 把需求拆成可独立验收的任务 已确认需求文档 issues/YYYY-MM-DD_HH-mm-ss-<slug>.csv CSV 必须校验通过;每个 Issue 写清范围、验收、测试、依赖
4. 技术方案设计 明确怎么实现和怎么回滚 Issue CSV、现有代码、数据模型、接口和权限规则 实现方案、接口/数据变更说明、风险和回滚策略 涉及权限、状态机、迁移、审批规则时必须写回滚策略
5. 开发实现 按 Issue 实现后端、前端、脚本或文档 已批准方案和 Issue CSV 代码或文档变更、必要测试用例、变更说明 不顺手改无关问题;跨端任务先稳定后端契约再接前端
6. 代码审查与自查 发现行为回归、权限泄漏、状态非法跳转和漏测 完整 diff、Issue CSV、测试结果 Review 意见、修复记录或确认无阻断问题 涉及权限模型、workflow、数据迁移、审批规则时必须重点审查
7. 测试与回归 证明单点和业务链路都可用 变更内容、Test_Method、回归脚本、手工验收步骤 命令结果、业务流程验证结果、失败项和修复记录 后端、前端、PC、移动、企业微信入口按影响范围验证;不能假通过
8. 部署与发布准备 确认环境、配置、资源和回滚路径可用 已验证变更、部署脚本、配置清单、回滚策略 部署记录、/ready 检查、资源版本、配置复核 未部署不得告知用户可去公网或企业微信真机测试
9. 业务验收 让目标角色按真实路径确认结果 已部署环境、验收账号、样例数据、验收清单 验收结论、遗留问题、是否进入试运行 用户或指定验收人未确认前,不把体验问题视为关闭
10. 复盘与下一轮规划 把反馈转成下一轮可执行任务 验收反馈、线上问题、回归缺口、试运行记录 新需求、缺陷清单、下一轮 Issue CSV 草案 不直接把反馈插入开发;先回到需求和 Issue CSV

2.1 本项目执行约束

详细测试、视觉验证、SKIP、状态回填和回归门禁以 测试规约与回归门禁 为准;Issue 生命周期、review、commit、工作区和交付输出以 开发交付与变更管理规约 为准。

  • 所有非微小改动必须先有需求事实源和 Issue CSV 执行合同。
  • 开发前必须说明实现方案;需求或方案不清时先澄清,不靠代码试错。
  • Dev_Status、Review1_Status、Regression_Status 只能在对应验证通过后更新为 DONE。
  • 后端变更至少执行 Prisma 校验、语法检查和相关业务回归;前端变更至少执行 typecheck、build,并按影响范围补 Playwright 或人工视觉验证。
  • 涉及 PC、手机、企业微信入口的改动,必须验证入口、布局、deeplink 和移动端体验。
  • 涉及生产、公网、企业微信真机或真实 OCR 的结论,必须以部署后 live smoke 为准;未配置真实条件时必须明确 SKIP 和原因。
  • 提交应按清晰主题小批次完成,commit message 使用中文并引用 Issue ID。

2.2 REQ8 当前需求状态表

分类 当前口径
当前已实现 / 已收口 R6 小范围试运行主链路;PC6/PA6/FL6/AP6/RI6/LP6;ME6 自动化、公网和代表性真机门禁;MIF7/MIF7T 移动信息架构与真机反馈整改;MIF7TD 公网部署、匿名复检和带凭据 live smoke/OCR。
R7 必需 用户确认参与人、角色、时间窗口、回滚联系人、问题登记负责人和每日收口节奏;R7E 公网健康、public bundle、带凭据 live readiness、公网移动矩阵、核心业务流和账号角色只读门禁通过;阻断问题为 0。
R7 后优化 UX8 真实反馈池、iPhone 12 间距观察项、详情字段扫读性二次优化、移动采购创建能力评估、组织账号主数据治理、图片 OCR 能力、转审扩展和邮件通道完整验收。
明确不做 / 当前冻结 ERP 未来不接入 OA;真实支付、图片 OCR、银行流水导入、完整差旅、复杂 BPM、审批设计器、预算重型控制继续不进入当前路线;AI 只允许草拟规则和 dry-run,人工确认后才能写入企微配置。企业微信原生审批从整体冻结调整为 HR/考勤员工日常审批优先复用,采购、费用、合同、项目、财务和报销仍由 OA 主办。

2.3 P2T 候选优先级

P2T 只做排序和边界确认,不进入当前实现。候选项按 R7 真实反馈和上线风险再拆新 Issue:

优先级 候选 当前边界
P2-1 企微 HR 主数据与 OA 镜像治理 WFOC 后改为企微/人事助手为员工主数据源,OA 同步员工档案、账号、角色、绑定和审计;HCLT 仍作为 OA 写企微能力证据,后续方向是先企微后 OA
P2-2 审批与通知扩展 转审扩展到请假/采购/差旅拆 W2F;邮件通道和三渠道完整验收另决策;不引入复杂 BPM
P2-3 OCR 与票据增强 当前试运行继续 PDF-only;图片 OCR、批量样票和异步体验需另补样票、隐私处理和 provider 回归
P2-4 费用/预算/项目轻量增强 可评估费用提示和项目关联增强;预算重型控制和正式成本核算继续冻结,ERP 不再作为后续接入项
P2-5 运维上线增强 备份恢复演练、SLO 门禁和正式上线准备需单独窗口;不在 R7E 预检中做真实恢复

ERP 已从“冻结待办”调整为“未来不接入 OA”。其他冻结项不是永久删除,而是当前 MVP/R7 不启动:AI 自动处理、完整差旅、复杂 BPM、审批设计器、预算重型控制。企业微信原生审批不再整体冻结,HR/考勤员工日常审批按 WFOC/DBWFOC 口径优先复用。


3. 用户角色与典型场景

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

4. MVP 模块优先级

优先级 模块 目标 主入口 验收口径
P0 统一审批和镜像中心 财务、报销、采购、合同等 OA 主办审批继续在 OA;HR/考勤员工日常审批改为企微主办、OA 镜像 PC 审批待办、移动审批、企微审批镜像 OA 主办审批可处理;企微主办审批可同步、查询、审计和应急接管
P0 企业微信基础设施 手机入口、免登、通知、打卡、人事助手、HR/考勤员工日常审批主操作端 企业微信自建应用 海音达工作台、企微打卡、企微审批、人事助手 员工优先在企微完成成熟流程,OA 获得按域镜像和审计
P0 人事生命周期 企微/人事助手主源,OA 同步员工、账号、权限、绑定和离职停用 企业微信人事/通讯录、OA 人员管理 先企微后 OA;OA 可审计、可接管、可在恢复后回写
P0 报销/发票/OCR 员工自助报销,财务可查重和导出 报销、移动报销、票据中心 上传、OCR、查重、绑定、审批、付款闭环
P0 请假与考勤镜像/接管 请假、补卡、外出、加班优先企微审批,OA 同步按域镜像并保留应急提交 企业微信审批、OA 考勤镜像、OA 应急模式 企微正常时员工走企微;企微不可用时管理员人工开启 OA 接管
P1 采购/费用审批 小团队采购和费用事项留痕 采购、审批待办 申请、附件、审批、状态更新可用
P1 合同与附件归档 管合同编号、责任人、归档位置和非涉密附件 合同/项目资料或项目页 能登记、查询、关联项目和审批记录
P1 项目轻管理 把费用、采购、差旅、周报挂到项目 项目、Portal、周报 能看项目事项、风险、费用摘要,不做重型排产
P2 预算/支付/AI 在试运行稳定后按真实反馈增强运营能力 管理员备用入口 另立 Issue CSV,不进入首批验收;ERP 不进入路线

5. 统一审批中心需求

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

5.1 范围

WFOC/DBWFOC 后审批分为两类:OA 主办审批和企微主办审批。OA 主办审批仍在 OA 内提交、审批、留痕、归档;企微主办审批仅限 HR/考勤员工日常审批第一阶段,在企业微信内发起和处理,OA 同步按域镜像、附件、审批历史、回调和审计,并在企微不可用时人工接管。

  • 报销、费用、采购。
  • 合同相关审批和合同台账维护。
  • 资产领用、归还、调拨、盘点中的需要留痕动作。
  • 后续新增财务、采购、合同、项目类业务审批,默认进入 OA 审批中心。

请假、补卡、外出、加班等 HR/考勤员工日常审批优先复用企业微信原生审批,OA 不再重复开发成熟员工日常流程;旧 OA 提交能力只作为 oa_hr_emergency_mode_v1 应急入口保留。采购、费用、合同、项目和财务类 OA 主办审批不进入企业微信原生审批,企业微信只做脱敏提醒和回 OA 处理入口。

5.2 审批能力

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

5.3 数据与留痕

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

5.4 验收

  • 审批人可在 PC 和移动端看到待办。
  • 审批动作完成后,业务单据状态、审批历史、通知和审计记录一致。
  • OA 主办审批的企业微信提醒点击后回到 OA 页面处理;企微主办审批由企业微信处理,OA 同步结果和审计镜像。

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

本章保留总纲口径。报销、发票、OCR、附件、查重、财务复核、付款、导出、费用类型矩阵、人工验真和验收数据集,以 需求 - 报销发票 OCR 规约 作为后续开发拆分依据;历史细则继续参考 报销与发票规则。

6.1 用户流程

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

6.2 发票与附件管理

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

6.3 财务导出

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

6.4 验收

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

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

本章保留总纲口径。请假、补卡、外出、加班的角色、字段、状态、审批规则、团队状态、日历和考勤解释细节,以 需求 - 请假考勤修正规约 作为后续开发拆分依据。

7.1 边界

  • 企业微信打卡用于原始采集和规则执行,保留其定位、人脸、Wi-Fi、排班、设备和防作弊能力。
  • OA 不重造企业微信打卡规则、定位、人脸识别、排班或防作弊引擎。
  • 请假、补卡、外出、加班等考勤修正申请优先在企业微信原生审批中提交和处理。
  • OA 通过 wecom_native_approval_mirror_v1 同步企微审批、打卡记录、规则、日报、月报和异常摘要,形成按域镜像和考勤解释。
  • 企业微信不可用时,管理员可人工开启 oa_hr_emergency_mode_v1,临时开放 OA 提交和审批;应急单据带 EMERGENCY 标记并进入恢复回写队列。

7.2 用户流程

  • 员工正常在企业微信提交请假、补卡、外出或加班申请。
  • 主管或 HR 正常在企业微信审批;OA 同步审批详情、审批历史、附件、状态回调和假期余额。
  • 审批通过后,OA 使用企微审批和打卡数据更新团队状态、日历和考勤镜像。
  • 企微故障时,管理员人工开启 OA 应急模式;企微恢复后,OA 通过 wecom_recovery_writeback_v1 dry-run 后自动回写,冲突进入人工确认。

7.3 验收

  • 请假提交、审批、撤回、驳回后状态正确。
  • 已批准请假能影响团队状态或日历展示。
  • 企微正常时员工优先在企业微信提交请假、补卡、外出和加班;OA 展示同步记录和应急入口状态。

7.4 当前完成度校正

REQAUD 复核后,ATTV1 已按“企业微信打卡、OA 审批解释”口径进入实现,本章当前完成度按以下口径读取:

项目 当前状态 说明
请假申请、审批、撤回、编辑和移动查看 DONE 已有 leave_requests、统一审批、PC/移动页面和回归证据。
请假影响团队状态/日历 DONE 已批准请假可进入团队状态和日历展示。
企业微信入口、免登/绑定、通知和 HR/考勤审批 REPLANNED_BY_WFOC 企业微信继续作为入口、身份和提醒;HR/考勤员工日常审批优先在企微处理,OA 同步镜像;OA 主办审批仍回 OA。
企业微信打卡运营使用 DONE 员工继续按公司要求在企业微信打卡;这是企业微信侧能力,不代表 OA 已同步打卡 API。
企业微信打卡 API 同步到 OA PARTIAL 已新增 attendance_unified_v1 同步批次和打卡摘要表;有已授权调用打卡 API 的自建应用 Secret/API 权限时可同步,缺配置时按 SKIP 记录,不伪造通过。WECOM_CHECKIN_SECRET 显式优先,未配置时复用已授权工作台应用的 WECOM_AGENT_SECRET。
员工补卡申请审批 DONE 已新增 OA 考勤修正申请,补卡只解释企微缺卡,不向企业微信写回。
外出申请审批 DONE 已新增外出修正申请和 OA 审批,用于月度考勤解释;不重造企微定位风控。
加班申请审批 DONE 已新增加班修正申请和 OA 审批,记录加班事实和补偿口径。
历史 OA 极简打卡 attendance_v1 FROZEN_CLOSED OA 自建上下班打卡、管理员补卡和自建月度统计已从正式入口关闭;旧 API 保留但返回 409,历史表不删除。

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

本章保留 P1 总纲口径。采购/费用、合同归档、项目轻管理的字段、状态、权限、异常、验收场景和后续开发拆分建议,分别以 需求 - 采购费用审批规约、需求 - 合同附件归档规约、需求 - 项目轻管理规约 作为后续开发依据;审批动作、状态机、权限和留痕仍以 需求 - 统一审批中心规约 为总依据。

8.1 采购和费用审批

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

8.2 合同与附件归档

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

8.3 项目轻管理

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

8.4 验收

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

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

本章保留总纲口径。企业微信入口、免登/绑定、通讯录身份、消息通知、deeplink 和打卡原始采集边界,以 需求 - 企业微信基础设施规约 作为后续开发拆分依据。

9.1 自建应用

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

9.2 免登与绑定

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

9.3 消息通知

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

9.4 打卡原始采集

  • 企业微信打卡数据、打卡规则、日报和月报是 OA 考勤镜像的原始来源。
  • attendance_unified_v1 当前只同步打卡摘要、批次、脱敏错误码和 raw hash;WFOC/DBWFOC 后续目标是扩展为打卡规则、排班、记录、日报、月报和异常摘要按域镜像。
  • 正式考勤统计必须结合企微请假/补卡/外出/加班审批、OA 应急单和恢复回写结果。

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

10.1 权限原则

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

10.2 审计要求

以下动作必须可追溯:

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

10.3 数据安全

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

10.4 非功能要求

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

11. 暂不做范围

首批 MVP 不做以下事项:

  • 不接入飞书,不保留飞书登录、通知、审批、文档或项目管理路线。
  • 不把企业微信原生审批用于报销、财务付款、采购、合同、项目等 OA 主办流程;HR/考勤员工日常审批按 WFOC/DBWFOC 口径优先复用企微。
  • 不开发复杂 BPM 流程设计器,不做并行会签建模。
  • 不依赖付费低代码平台、付费第三方应用或付费项目管理套件。
  • 不重造企业微信打卡的定位、人脸识别、Wi-Fi、排班规则。
  • 不做完整 CRM、ERP、PLM、甘特排产或项目组合管理。
  • 不把聊天记录、会议纪要、涉密合同正文或敏感报价长期保存在 OA。

12. MVP 验收标准

12.1 产品验收

  • 老板能在 OA 中看到审批待办、项目/费用摘要和关键风险。
  • 员工能在 OA 完成报销、采购等 OA 主办申请,并在企业微信完成请假、补卡、外出、加班等 HR/考勤申请。
  • 审批人能在 OA 处理 OA 主办待办,并在企业微信处理 HR/考勤原生审批;OA 能同步镜像。
  • 财务能完成发票查重、付款标记和导出。
  • 管理员能维护人员、权限、企业微信入口和基础配置。
  • 企业微信作为 HR/考勤员工日常审批主操作端,OA 作为按域镜像和应急接管;不得产生无法对账的双轨审批。

12.2 流程验收

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

12.3 工程验收

  • Issue CSV 校验通过。
  • 文档 diff 检查通过。
  • 涉及后端时执行 Prisma、语法和相关回归脚本。
  • 涉及前端时执行 typecheck、build 和相关 Playwright。
  • 涉及公网或企业微信真机时,必须部署后检查 /ready、前端资源和真实入口。
  • 测试和提交证据必须符合 测试规约与回归门禁 与 开发交付与变更管理规约。

13. 后续 Backlog

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

  • 企业微信打卡 live 同步验证和真实考勤数据口径稳定化。
  • 补卡、外出、加班的真实使用反馈体验优化。
  • 合同台账、合同编号、合同审批和离线档案号的细化。
  • 预算控制和付款/AP 运营真实使用反馈优化;ERP 不再规划出站凭证或实时集成。
  • 项目轻管理与周报、待办、费用、采购、差旅的进一步联动。
  • 全量 E2E 稳定性清理和移动视觉回归。
  • 生产备份恢复演练、并发试运行和正式上线复核。

14. 文档维护规则

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