hyb-oa/docs/产品口径.md

产品口径文档

来源：2026-03-25 产品需求梳理会话 适用版本：R35 之后

---

平台边界

P0-1 企微优先 + OA 镜像/接管

• WFOC 起，能用企业微信成熟能力的 HR/考勤员工日常审批优先使用企业微信；OA 做按域镜像、人工接管、恢复回写、财务闭环和审计中台。
• DBWFOC 后固定数据边界：企业微信成熟功能可作为流程、字段、交互和规则参考，但不默认成为高敏业务数据托管处。
• 报销、采购、费用、合同、项目、财务付款、AP 台账、代账交接、审计和敏感附件仍由 OA 主办，在 OA 内提交、审批、留痕、归档。
• 请假、补卡、外出、加班等 HR/考勤员工日常审批优先在企业微信原生审批中提交和处理，OA 同步按域镜像；企业微信不可用时由管理员人工开启 OA 应急模式。
• 企业微信作为手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡、人事助手和 HR/考勤员工日常审批主操作端；OA 主办审批通过企业微信个人应用消息发送脱敏提醒并 deeplink 回 OA 处理。
• 采购单附件、合同正文、报价、供应商资料、发票、银行回单和代账资料不上传到企业微信原生审批或企业微信附件。
• 简写口径：采购不进企微原生审批，合同不进企微原生审批，附件不进企微附件；企微只做提醒、入口和免登录回 OA。

P0-2 企业微信打卡与 OA 考勤口径

• 企业微信打卡用于原始采集，保留其定位、人脸、Wi-Fi、规则与设备能力。
• OA 后续同步企业微信打卡规则、排班、记录、日报、月报和 HR/考勤审批镜像，形成正式考勤口径。
• 请假、补卡、外出、加班等考勤修正正常在企业微信完成；OA 只在应急模式下接管，并在企微恢复后 dry-run 和自动回写。
• 后续实现必须另建 wecom_hr_master_sync_v1、wecom_native_approval_mirror_v1、oa_hr_emergency_mode_v1、wecom_recovery_writeback_v1 或 wecom_ruleops_v1 合同。

P0-3 按域镜像定义

• 企微主办域镜像到 OA：通讯录/人事助手、打卡、请假、补卡、外出、加班、假期余额和 HR/考勤规则。
• OA 主办域不反向全量镜像到企微：报销、采购、费用、合同、项目、付款批次、AP、代账交接和审计只发送脱敏消息、状态和 OA 链接。
• “无痛接管”长期目标只针对必要业务连续性，不承诺把所有 OA 高敏附件和财务资料复制到企业微信。

---

请假模块

L-1 团队日历可见性

• HR / Admin（具备 leave.view_all + leave.manage）：看全员
• 部门经理（具备 leave.view_all，仅限本部门）：看本部门
• 普通员工：不可见团队日历 Tab

实现要点：前端 canViewAll 判断需区分"HR 全员视图"和"经理部门视图"，查询时经理视图需传 departmentId 过滤。

L-2 草稿与已驳回请假的编辑

• draft 和 rejected 状态的请假支持原单编辑后再提交
• 不要求"撤回再新建"；直接在已有单据上修改字段后重新 submit
• 实现时需要 leave.edit_own（或直接在现有权限下放开）并在 submit 路由内允许此两种状态

L-3 审批中请假的撤回

• 申请人可主动撤回 reviewing 状态的请假，撤回后状态回 draft
• approved 后不允许直接撤回，需走销假/更正流程（后续另立需求）
• 当前状态：撤回已实现，此条为确认口径，无需改代码

L-4 leave.approve vs leave.manage

• leave.approve：仅表示"处理分配给自己的审批任务"，不赋予查看全量的权利
• leave.manage：HR/行政运营权限，包括查看全量、人工纠偏/取消、余额与规则维护
• leave.manage 不允许静默改写历史申请内容（需留审计痕迹）

---

审批流 / 工作流

W-1 无直接经理时的阻断规则

• 正式员工必须配置直属主管；缺直属主管属于组织主数据错误。
• 缺直属主管、主管停用、主管链断裂或审批节点解析为申请人本人时，提交必须阻断并提示"未配置可审批人"或"当前审批规则未找到审批人"。
• 只有审批规则显式配置老板/总经理或兜底审批节点，且目标不是申请人本人时，才进入 CEO 或其他非本人兜底审批人。
• 不自动通过，不静默跳过，不用无条件升级 CEO 掩盖组织配置问题。
• 当前正式运行口径：majianyong 是员工可见直属主管；wangshunli 是 ceo + admin，不配置为普通 manager；admin 不代表业务审批权。

W-2 转审适用范围

• 产品目标：转审是通用审批能力，目标覆盖报销、请假、采购、差旅。
• 条件：只能转给具备对应单据审批权限的人，且不得绕过必经老板、财务或 HR/行政节点。
• 当前实现状态：转审路由仍使用 expense.transfer 前置权限，approvalTransfer 专门留痕仍以报销为主；跨域转审扩展不作为当前 R7 硬门禁。
• 后续若要覆盖请假、采购或差旅，拆 W2F follow-up，先评审权限、状态机、转审链路、通知和历史留痕。

W-3 转审次数上限

• 上限保留 3 次，超过后拒绝继续转审
• 超限后不自动转给固定角色；要求当前审批人自行处理或由管理员走代理机制

W-4 并行会签

• 当前阶段不做并行会签
• 大额采购等双签场景，优先做串行多节点（两步顺序审批），不引入并行会签模型

---

通知渠道

N-1 三渠道联动策略

• 产品目标：审批类高优先级事件可支持站内通知 + 企业微信个人应用消息 + 邮件。
• 当前 R7 验收口径：以站内通知 + 企业微信个人应用消息和 deeplink 为主；邮件通道是否进入验收另拆 Issue。
• 当前不做用户级"关某渠道"配置
• 后续通知量上来后再做订阅偏好管理

---

Portal 首页

P-1 经理视图判断逻辑

• 当前状态：Portal 经理/角色能力已通过 buildRoleCapabilities 类逻辑按角色和权限承载。
• 口径：有任一审批权限（*.approve）或域管理权限（*.manage 非 view_all）的用户进入经理视图
• 后续可选择提取 isManagerRole(permissions) 共享工具减少重复，但这不是当前 R7 阻断项。

---

权限模型

R-1 view_all vs manage 语义定义

• view_all：对应域全量数据只读可见
• manage：域内管理与运营动作权限（如人工纠偏、配置维护、取消操作）
• manage 不是 approve 的别名，也不等于"可任意改历史数据"

R-2 报销/费用金额分层审批

• 需按金额分层，但通过审批规则配置实现（工作流步骤条件），不通过拆 manager/ceo 权限组实现
• 权限层面两个角色都保留 expense.approve，具体金额阈值在工作流定义里配置

R-3 资产转移权限

• asset.transfer 只给 administration / 资产管理员
• finance_mgr 有 asset.manage 但不拥有实物调拨权限，这是有意设计