106 行
5.1 KiB
Markdown
106 行
5.1 KiB
Markdown
# 产品口径文档
|
||
|
||
> 来源：2026-03-25 产品需求梳理会话
|
||
> 适用版本：R35 之后
|
||
|
||
---
|
||
|
||
## 平台边界
|
||
|
||
### P0-1 OA 唯一审批中心
|
||
- `hyb-oa` 是公司唯一业务主系统和唯一审批中心。
|
||
- 报销、采购、费用、合同、请假、补卡、外出、加班、出差等正式审批，都必须在 OA 内提交、审批、留痕、归档。
|
||
- 企业微信原生审批不作为公司正式审批入口；不得出现一部分审批在企业微信、一部分审批在 OA 的割裂口径。
|
||
- 企业微信只作为基础设施：手机工作台入口、免登/绑定、通讯录身份、消息通知、打卡原始采集。
|
||
|
||
### P0-2 企业微信打卡与 OA 考勤口径
|
||
- 企业微信打卡用于原始采集，保留其定位、人脸、Wi-Fi、规则与设备能力。
|
||
- OA 后续可同步企业微信打卡原始记录，并结合 OA 内的请假、补卡、外出、加班审批形成正式考勤口径。
|
||
- 请假、补卡、外出、加班等考勤修正审批仍在 OA 完成，不走企业微信审批。
|
||
- 第一阶段不新增打卡 API 同步实现，先冻结边界，避免在审批中心收口时扩大战线。
|
||
|
||
---
|
||
|
||
## 请假模块
|
||
|
||
### 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 转审适用范围
|
||
- 转审是通用审批能力，支持：报销、请假、采购、差旅
|
||
- 条件：只能转给具备对应单据审批权限的人
|
||
- 当前代码仅限报销，需移除 `entity_type !== "reimbursement"` 的硬限制
|
||
|
||
### W-3 转审次数上限
|
||
- 上限保留 3 次，超过后拒绝继续转审
|
||
- 超限后不自动转给固定角色；要求当前审批人自行处理或由管理员走代理机制
|
||
|
||
### W-4 并行会签
|
||
- 当前阶段不做并行会签
|
||
- 大额采购等双签场景，优先做串行多节点（两步顺序审批），不引入并行会签模型
|
||
|
||
---
|
||
|
||
## 通知渠道
|
||
|
||
### N-1 三渠道联动策略
|
||
- 审批类高优先级事件默认三渠道并发：站内通知 + 企微 + 邮件
|
||
- 当前不做用户级"关某渠道"配置
|
||
- 后续通知量上来后再做订阅偏好管理
|
||
|
||
---
|
||
|
||
## Portal 首页
|
||
|
||
### P-1 经理视图判断逻辑
|
||
- 现状：用 `system.users` 或 `report.dashboard.view` 判断，不准确
|
||
- 口径：有任一**审批权限**（`*.approve`）或**域管理权限**（`*.manage` 非 `view_all`）的用户进入经理视图
|
||
- 实现时建议提取 `isManagerRole(permissions)` 工具函数统一判断
|
||
|
||
---
|
||
|
||
## 权限模型
|
||
|
||
### 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` 但不拥有实物调拨权限，这是有意设计
|