修正业务职责与主管关系事实（07-28-all-account-login-readiness）
这个提交包含在：
@@ -82,7 +82,7 @@
|
||||
|
||||
## 审批与通知
|
||||
|
||||
- 正式审批口径：`majianyong` 是员工可见的直属主管；`wangshunli` 是后台公司负责人，配置为 `ceo + admin`，不配置为普通 `manager`；`admin` 不代表业务审批权。
|
||||
- 正式审批口径：`majianyong` 是公司负责人 `ceo` 且不配置直属主管，当前唯一 active `manager` 向其汇报；`wangshunli` 只承担系统开发/系统管理，不配置正常业务审批角色；`admin` 不代表业务审批权。CEO 本人报销只有在 active 非本人财务兜底可解析时才能通过，否则必须阻断。
|
||||
- WOUA-FIX 后，`SMOKE001`、`SMOKE201`、`SMOKE301`、`SMOKE302`、`SMOKE401`、`T0000` 已作为缺企微测试数据软归档；后续真机或公网试运行不得再把这些账号作为当前执行账号。
|
||||
- 审批链正确性是业务逻辑验收，优先通过 PC 公网网页或自动化证明，不要求所有审批角色绑定企业微信。
|
||||
- 企业微信真机验收只覆盖工作台入口、绑定/免登录、移动布局、待办、详情、PDF 上传入口和通知 deeplink；当前 `oa_smoke_01 -> SMOKE002` 与 `oa_smoke_02 -> SMOKE101` 足够覆盖“提交人 + 审批人”的核心移动体验。
|
||||
|
||||
+1
-1
@@ -108,7 +108,7 @@
|
||||
- 缺直属主管、主管停用、主管链断裂或审批节点解析为申请人本人时，提交必须阻断并提示"未配置可审批人"或"当前审批规则未找到审批人"。
|
||||
- 只有审批规则显式配置老板/总经理或兜底审批节点，且目标不是申请人本人时，才进入 `CEO` 或其他非本人兜底审批人。
|
||||
- 不自动通过，不静默跳过，不用无条件升级 `CEO` 掩盖组织配置问题。
|
||||
- 当前正式运行口径：`majianyong` 是员工可见直属主管；`wangshunli` 是 `ceo + admin`，不配置为普通 `manager`；`admin` 不代表业务审批权。
|
||||
- 当前正式运行口径：`majianyong` 是公司负责人 `ceo` 且不配置直属主管；当前唯一 active `manager` 向其汇报。`wangshunli` 只承担系统开发/系统管理，不配置业务审批角色；`admin` 不代表业务审批权。CEO 本人报销目标由 active 非本人 `finance` 审批，当前实现缺口未修复时保持阻断。
|
||||
|
||||
### W-2 转审适用范围
|
||||
- 产品目标：转审是通用审批能力，目标覆盖报销、请假、采购、差旅。
|
||||
|
||||
+1
-1
@@ -123,7 +123,7 @@
|
||||
| `OALAUNCH1` | `issues/2026-05-23_16-49-39-oa-final-launch-readiness-v1.csv` | `EVIDENCE` | 历史最终启用门禁来源；真实业务闭环、连续 7 天、权限矩阵、备份恢复、数据治理培训、运营支持和 Day 7 人工决策要求仍可复用，但未来实际执行必须由新 Trellis task 承接。未取得新任务完整证据前不得宣布最终正式启用完成 |
|
||||
| `OMAT1` | `issues/2026-05-23_17-20-00-oa-maturity-gap-review-v1.csv` | `CURRENT` | 当前成熟度缺口审查台账：按 MAGI 审视/执行/提升轮次调查 hyb-oa 是否成熟，并对标国内主流 OA/协同/低代码/财务/资产系统；已补充国内对标来源、小团队取舍原则、用户决策回填和成熟度证据视图；所有问题和建议先记录为待用户采纳、暂缓或否决，不直接改业务代码 |
|
||||
| `OPOLICY1` | `issues/2026-05-24_01-20-52-oa-policy-system-alignment-v1.csv` | `CURRENT` | 当前制度与 OA 对齐合同：先调整外部制度包为小团队 V1，再回写 OA 事实源和启用门禁；制度参数、资料留存、用印台账、审批异常 SOP、制度签收和 P2 冻结进入 OALAUNCH1 数据治理门禁；现有合同台账、资产台账和公告能力可承载 V1，不立即做 schema 或业务代码改造 |
|
||||
| `OAFLOW1` | `issues/2026-05-24_19-03-07-oa-owner-application-fallback-approval-v1.csv` | `CURRENT` | 当前负责人本人申请兜底审批合同：`wangshunli/HYD000006` 本人报销不配置假直属主管、不允许自审、不把 `admin` 当业务审批权；报销审批规则新增 `ownerSelfFallbackRole`，首版只允许 `finance_mgr` 或置空，现有启用规则默认 `finance_mgr`，提交时生成新单审批快照并移除本人 `ceo` 节点和重复兜底角色；公网低风险验证需另行批准 |
|
||||
| `OAFLOW1` | `issues/2026-05-24_19-03-07-oa-owner-application-fallback-approval-v1.csv` | `CURRENT` | 负责人本人申请兜底机制仍有效，但当前人员职责已由用户修正：`majianyong` 是 `ceo` 且无直属主管，`wangshunli` 仅为系统开发/系统管理员，不参与正常业务审批；CEO 本人报销目标由 active 非本人 `finance` 审批。现有代码和启用规则仍限定 `finance_mgr`，而生产没有 active `finance_mgr`，因此后续最小权限修正完成前必须阻断，不得把历史 OAFLOW1 证据误读为当前已就绪 |
|
||||
| `OAFRONT6` | `issues/2026-05-25_12-29-03-oa-frontend-maturity-small-step-v1.csv` | `CURRENT` | 当前前端成熟化小步收口合同：承接 OAFRONT5 部署后 PC 硬问题清零和设计审计；路由标题修复、资产台账详情分区、移动视觉矩阵稳定等待、合同台账表单分组和长编号压缩均已实施部署，公网 PC 只读视觉矩阵复测 `PASS_PC_READONLY_VISUAL_READY` 且 `findingCount=0`；Portal 观察继续后置；本合同不写公网业务数据，不替代 OALAUNCH1 真实业务、备份恢复、7 天稳定化或 Go/No-Go |
|
||||
| `OAKISS1` | `issues/2026-05-25_20-53-34-oa-business-flow-kiss-review-v1.csv` | `CURRENT` | 当前全业务流程 KISS 审查合同：按 MAGI 审视/执行/提升轮次，对报销/OCR、审批、采购/费用、合同/项目、付款/AP、票据池、资产、权限、移动/企微入口逐项做自动化和人工步骤审查；输出 KISS 建议台账，不直接改业务代码；OALAUNCH1 真实业务闭环、备份恢复、7 天稳定化和 Go/No-Go 仍是正式启用前硬门禁 |
|
||||
| `PCDESIGN1` | `issues/2026-05-25_21-27-56-oa-pc-page-design-review-v1.csv` | `CURRENT` | 当前 PC 全页面设计审查合同：按 MAGI 审视/执行/提升轮次，以项目经理和设计总监视角盘点 45 条静态 PC 路由、A/B/C 页面分层、关键视觉矩阵和 KISS 建议；关键 PC 矩阵 `PASS_PC_READONLY_VISUAL_READY`，全静态路由扫描 `PASS_PC_STATIC_ROUTE_SCAN_READY`；建议优先收敛 HR/考勤边界、冻结模块入口、高密度 B/C 页默认视图和动态详情页证据，不直接改业务代码 |
|
||||
|
||||
+1
-1
@@ -53,7 +53,7 @@ R6 -> PC6 -> PA6 -> FL6 -> AP6 -> RI6 -> LP6 -> ME6/QG6 -> DG7/MRF7 -> MIA7 -> M
|
||||
- FIN-PROD-ENABLE 是公网付款批次正式常开合同：未重新部署业务代码；新增 QA-only 正式启用 runner 后完成公网正式验收，测试报销 `BX-20260517-0026` 完成审批、付款批次创建/复核、无回单执行阻断、回单上传/下载、付款执行、AP 导出和审计核验；公网移动矩阵 6 passed、企业微信渲染矩阵 8 passed；最终 `payment_batch_v1=force_on`，`erp_sync=force_off`。
|
||||
- ACCOUNTING-HANDOFF-V1 是月度代账交接 SOP 合同：公司无 ERP/独立财务系统，OA 侧交接资料固定为 AP 台账、报销导出、票据中心导出、付款批次/回单附件清单和审计日志；银行侧流水和回单原件由出纳从银行渠道导出交给代账人工核对，不导入 OA，不开发一键 zip 包。
|
||||
- SYSTEM-COMPLETE-GATE 是系统开发完成收口合同：公网 readiness、live smoke、PDF live OCR、正式 flag 状态、FINPROD/ACCTH 证据、移动/企业微信矩阵和文档事实源均通过；结论 `GO_TO_USE`，系统按首批正式能力可交付使用。
|
||||
- LAUNCH-OPS-V1 是正式使用首周运营保障合同：固定 `wangshunli` 为上线拍板、管理员复核和回滚决策人，`wangzhiling` 为出纳/付款执行和代账资料准备人；首周问题登记、每日巡检、暂停条件、代账交接节奏和可选功能冻结口径已回写现有手册。
|
||||
- LAUNCH-OPS-V1 是正式使用首周运营保障合同：`wangshunli` 负责系统上线、配置、运维和回滚，不承担正常业务审批或付款复核；业务复核由具备明确 `manager`/`ceo` 角色的非创建人处理，当前公司负责人为 `majianyong(ceo)`；`wangzhiling` 负责出纳/付款执行和代账资料准备。首周问题登记、每日巡检、暂停条件、代账交接节奏和可选功能冻结口径已回写现有手册。
|
||||
- REQ-COMPLETE-AUDIT 是系统完成门禁后的需求完成度复核合同：确认首批正式能力仍为报销、PDF OCR、审批、请假、采购、通知、移动/企业微信入口、财务台账、付款批次、银行回单附件和代账交接；考勤边界纠偏为“企业微信打卡做原始采集和风控，OA 不重造定位/人脸/Wi-Fi/排班/防作弊”。
|
||||
- ATTV1 是 REQ-COMPLETE-AUDIT 后的考勤统一入口实现合同：已部署到公网，关闭历史 OA 自建打卡 `attendance_v1`；新增 `attendance_unified_v1`、企微打卡摘要同步批次、补卡/外出/加班 OA 审批和月度考勤解释；公网复检 `/ready`、live smoke、PDF live OCR、移动/企业微信矩阵和考勤关键接口均通过，企微 live 同步缺 Secret 或 API 权限时记 `SKIP`，不使用企微原生审批，不保存完整位置、人脸、设备明文或原始 payload。
|
||||
- LAUNCH-AUTO-OPS-V1 是 ATTV1 后的正式启用自动化收口合同：新增当前正式状态 QA-only runner、live feature flag 只读检查和统一考勤 live 检查；本地门禁、公网 readiness、PDF live OCR、统一考勤检查、移动矩阵和企业微信 UA/渲染矩阵均通过。显式企微打卡同步检查返回 `SKIP wecom_checkin_sync_disabled`。实际公网 `payment_batch_v1=force_off`，与 FIN-PROD-ENABLE 记录的正式常开口径不一致，因此结论为 `PAUSE_FOR_FIX`；runner 已跳过付款批次写入，未切换 flag、未部署、未接真实支付或 ERP。
|
||||
|
||||
+10
-9
@@ -12,7 +12,7 @@
|
||||
**OSMOKE1 OA-only smoke 账号治理**：企业微信账号数量有限时，不再为了 OA 报销、资产、财务、AP、合同或权限回归额外申请企业微信账号。企微测试账号只服务 HR/考勤链路；公网 OA 自动化使用 OA-only smoke 账号，允许不绑定企微，但必须在 OA 内保持 active、角色正确且可登录。企微/OA 一致性审计会把私有 env 中列出、显式员工号 allowlist 命中，或符合 `SMOKE*`/`smoke-*`/`oa-smoke-*`/测试命名的 OA-only smoke 账号归为 `oaOnlySmokeExempted`，不再当作“缺企微账号”归档；真实员工不得用该命名绕过一致性治理。恢复账号必须先 dry-run，真实修复必须 `--apply` 且设置 `OA_ONLY_SMOKE_REPAIR_APPLY=1`，不得重置密码、不得打印凭据、不得影响真实员工。
|
||||
**OALAUNCH1 最终启用门禁**：ASSET1D 已完成资产台账公网部署、最小 UI 试录和 3 条脱敏 `EA-DOC` 受控导入；OAOPS1 自动巡检已具备公网只读证据，但正式启用前仍必须补齐真实业务闭环、权限矩阵、备份恢复演练、数据治理培训和 Day 7 Go/No-Go。新增 `scripts/qa/run-oa-final-launch-readiness.sh` 只聚合证据并输出 `PASS_OA_LAUNCH_READY`、`PASS_WITH_FINDINGS`、`PAUSED_MANUAL_CONFIRMATION` 或 `SKIP/BLOCKED_BY_EXTERNAL_CONFIG`；脚本不创建业务数据、不执行付款、不写企业微信、不做数据库恢复。未达到 `PASS_OA_LAUNCH_READY` 前，只能视为小团队稳定化收口中，不能宣布最终正式启用完成。
|
||||
**OPOLICY1 制度与 OA 对齐口径**：公司制度包已裁剪为“小团队 V1”执行口径，原则是先做到能执行、能留痕、能追责。制度参数、资料留存、用印台账、审批异常 SOP、制度签收和 P2 冻结边界进入 OALAUNCH1 数据治理门禁；预算硬控、复杂招采、电子签章、完整电子档案系统、ERP/银行深集成和 AI 自动改规则不作为正式启用前置条件。
|
||||
**OAFLOW1 负责人本人报销兜底审批**：`wangshunli/HYD000006` 作为 `ceo + admin` 提交本人报销时，不配置假直属主管，不允许自审，也不把 `admin` 当业务审批权。OA 报销审批规则新增 `负责人本人兜底角色(ownerSelfFallbackRole)`，当前推荐和默认回填为 `finance_mgr`。负责人本人无直属主管时，系统把第一层 `manager` 替换为 `finance_mgr`，并移除本人 `ceo` 节点和重复角色；若兜底角色没有 active 非本人持有人或兜底角色也由申请人本人持有，提交仍会阻断。
|
||||
**OAFLOW1 负责人本人报销兜底审批**：当前业务负责人是 `majianyong`（`ceo`），不配置直属主管且不允许自审；`wangshunli` 仅承担系统开发和系统管理，不是业务审批人。用户确认 CEO 本人报销应由财务审批。现有实现仍只允许 `finance_mgr` 作为 `ownerSelfFallbackRole`，而生产当前只有 active `finance`、没有 active `finance_mgr`，因此 CEO 本人报销在后续最小权限修正完成前会被阻断；不得用 `admin` 代批，也不得把系统管理员配置成假直属主管。
|
||||
|
||||
## 1. 适用范围
|
||||
- 适用于 `small_team_internal` 工作区模式。
|
||||
@@ -29,10 +29,10 @@
|
||||
2. 首批主路径优先保留：`Portal`、`审批待办`、`报销`、`票据/OCR`、`项目`、`采购/费用`、`合同/附件`、企微 HR/考勤镜像和 OA 应急接管状态。请假、补卡、外出、加班的正常提交入口后续迁往企业微信。
|
||||
3. `团队状态`、`周报`、`待办`、`公告`、`人员`、`资产` 可按真实试运行需要开启；`付款` 和 `应付账款` 已作为财务闭环正式能力面向出纳、财务和管理员开放，普通员工不显示该入口；`预算`、`AI`、完整差旅能力仍作为备用或历史能力，ERP 不再规划接入。
|
||||
4. 在 `用户管理` 中按推荐预设配置：老板 / 管理员 / 主管 / 员工。
|
||||
- 正式审批组织口径：`majianyong` 配置为员工可见直属主管和 `manager`；`wangshunli` 配置为后台公司负责人 `ceo + admin`，不配置为普通 `manager`。
|
||||
- 普通员工和专用测试员工的直属主管配置为 `majianyong`；`majianyong` 的直属领导配置为 `wangshunli`。
|
||||
- 正式审批组织口径：`majianyong` 配置为公司负责人 `ceo` 且不配置直属主管；`wangshunli` 仅配置系统开发/系统管理职责，不配置 `manager`、`ceo`、`finance` 或 `finance_mgr` 业务角色。
|
||||
- 普通员工配置有效直属主管；当前唯一 active `manager` 的直属主管配置为 `majianyong`。不得把 `wangshunli` 放入正常业务汇报或审批链。
|
||||
- `admin` 只代表系统管理权限，不代表业务审批权；需要业务审批时必须配置 `manager`、`ceo`、`finance`、`hr` 等正式业务角色。
|
||||
- 缺直属主管、主管停用、主管链断裂或审批节点解析到申请人本人时，应先修正组织或审批规则，不要用管理员账号代批。负责人本人报销只允许通过审批规则里的 `负责人本人兜底角色` 进入非本人复核，推荐 `finance_mgr`。
|
||||
- 缺直属主管、主管停用、主管链断裂或审批节点解析到申请人本人时，应先修正组织或审批规则，不要用管理员账号代批。CEO 本人报销只允许通过审批规则进入 active 非本人财务审批；当前 `finance`/`finance_mgr` 配置缺口未修复前保持阻断，不伪造成可用。
|
||||
5. 检查功能开关：
|
||||
- 建议开启：`portal_home_v1`、企业微信入口相关开关、报销/OCR、审批待办、请假、项目基础能力和 `payment_batch_v1`。
|
||||
- 按需开启：`announcements_v1`、`presence_board_v1`、`weekly_report_v1`、`employee_lifecycle_v1`、`hr_wecom_directory_sync_v1`、`todo_board_v1`、`global_search_v1`。
|
||||
@@ -177,9 +177,9 @@ ORDER BY priority;
|
||||
|
||||
管理要求：
|
||||
|
||||
1. 启用的报销金额规则建议均配置 `owner_self_fallback_role = 'finance_mgr'`。
|
||||
2. OAFLOW1 首版 `owner_self_fallback_role` 只允许 `finance_mgr` 或置空；不得配置为 `admin`、`ceo`、`hr`、`administration` 或其他非报销审批角色。
|
||||
3. `finance_mgr` 必须至少有 1 名 active 非本人持有人；否则负责人本人报销提交会阻断。
|
||||
1. 当前代码只允许 `owner_self_fallback_role = 'finance_mgr'` 或置空；生产虽已回填该值，但没有 active `finance_mgr` 持有人，因此 CEO 本人报销会阻断。
|
||||
2. 用户确认目标口径是由 active 非本人 `finance` 审批。后续修正必须同时检查 `owner_self_fallback_role` 和中/大额规则里的 `finance_mgr` 节点，保证最终快照不残留不可解析节点。
|
||||
3. 不得为省事把 `admin` 当业务审批角色，也不得仅为绕过阻断给财务人员附加超出实际职责的权限；优先按最小权限调整支持角色和规则。
|
||||
4. 提交后系统保存审批快照；之后修改规则只影响新单，不回写历史流程。
|
||||
|
||||
财务和系统管理员混授：
|
||||
@@ -310,7 +310,7 @@ WAPC2 请假/补卡只读 POC 操作口径：
|
||||
1. 员工在 OA 提交报销，发票/OCR 正式入口保持 PDF-only，图片只作为普通附件。
|
||||
2. 直属主管、财务或负责人按审批规则在 OA 内完成审批。
|
||||
3. `wangzhiling` 作为出纳，在付款批次中创建待付款批次，按批次准备对公银行付款。
|
||||
4. `wangshunli` 以管理员身份复核付款批次；管理员复核是当前明确业务选择，系统保留 maker-checker 和审计记录。
|
||||
4. 付款批次由非创建人且具备 `payment.batch.review` 与明确 `manager`/`ceo` 业务角色的人员复核；当前公司负责人为 `majianyong(ceo)`。`wangshunli` 的系统管理员身份不产生付款复核权。
|
||||
5. 出纳在 OA 外通过网银或银行渠道付款，然后在付款批次详情上传银行回单附件，补齐凭证号、付款日期和付款渠道。
|
||||
6. 出纳执行 OA 已付款标记；系统将报销单置为 `paid`，票据归档为 `archived`，AP 台账变为已付款状态。
|
||||
|
||||
@@ -342,7 +342,8 @@ WAPC2 请假/补卡只读 POC 操作口径：
|
||||
| 职责 | 负责人 | 处理范围 |
|
||||
| --- | --- | --- |
|
||||
| 上线拍板和回滚决策 | `wangshunli` | 判断继续、暂停、回滚或另建修复合同 |
|
||||
| 管理员复核 | `wangshunli` | 付款批次复核、权限和审计核查 |
|
||||
| 系统管理 | `wangshunli` | 账号、配置、部署、权限配置和审计核查；不处理付款批次或正常业务审批 |
|
||||
| 业务复核 | `majianyong` | 以 `ceo` 身份处理分配给本人的业务审批和付款批次复核；不得自审或复核本人创建的批次 |
|
||||
| 出纳/付款执行 | `wangzhiling` | 银行对公付款、回单上传、付款标记和代账资料准备 |
|
||||
| 问题登记 | `wangshunli` | 汇总问题、分级、每日收口和结论回写 |
|
||||
|
||||
|
||||
+13
-13
@@ -99,31 +99,31 @@ OA 中既有请假、补卡、外出、加班能力转为历史只读、镜像
|
||||
|
||||
| 人员 | 正式角色口径 | 配置要求 | 审批边界 |
|
||||
| --- | --- | --- | --- |
|
||||
| `majianyong` | 员工可见的直属主管 / `manager` | 普通员工直属主管配置为 `majianyong` | 处理普通员工低/中额单据和日常审批；本人申请不得自审 |
|
||||
| `wangshunli` | 后台公司负责人 / `ceo + admin` | 配置为 `ceo` 和 `admin`，不配置为普通 `manager` | 处理大额、高风险、例外事项和 `majianyong` 本人申请；本人申请不得自审 |
|
||||
| 专用测试员工 | 普通员工 / `employee` | 直属主管配置为 `majianyong` | 用于正式链路验收，不使用真实员工日常账号跑自动化 |
|
||||
| `majianyong` | 公司负责人 / `ceo` | 不配置直属主管；当前唯一 active `manager` 的直属主管配置为 `majianyong` | 处理 CEO 节点事项；本人申请不得自审，由财务兜底 |
|
||||
| `wangshunli` | 系统开发 / 系统管理员 | 不配置 `manager`、`ceo`、`finance` 或 `finance_mgr` 业务角色，不进入正常业务汇报链 | 只处理系统配置、账号、部署和运维，不处理正常业务审批 |
|
||||
| 普通员工 / 专用测试员工 | 普通员工 / `employee` | 配置 active 且具备对应业务审批权的直属主管 | 用于日常业务或正式链路验收；专用测试账号不替代真实员工结论 |
|
||||
|
||||
正式员工必须配置直属主管。缺直属主管、主管停用、主管链断裂或审批节点解析到申请人本人时，应阻断提交或阻断审批动作，并提示管理员修正组织或审批规则。不得用 `admin` 权限解释业务审批权，也不得用无条件升级 CEO 掩盖主数据错误。
|
||||
|
||||
### 2.4 OAFLOW1 负责人本人报销兜底审批
|
||||
|
||||
OAFLOW1 后，OA 主办的报销审批规则增加 `ownerSelfFallbackRole`。当公司负责人本人（当前业务口径为 `ceo` 角色）提交报销且直属主管节点无法解析时，系统使用审批规则上的非本人兜底角色替换第一层 `manager` 节点；当前推荐和默认回填为 `finance_mgr`。该规则只作用于新提交报销单，提交时保存 `workflow_steps_snapshot`，后续审批推进只读快照，不因之后修改审批规则而漂移。
|
||||
OAFLOW1 后，OA 主办的报销审批规则增加 `ownerSelfFallbackRole`。当公司负责人本人（当前为 `majianyong`，`ceo`）提交报销且直属主管节点无法解析时，系统应使用审批规则上的 active 非本人财务兜底替换第一层 `manager` 节点。用户确认目标审批人为现有 `finance`；当前代码仍只支持 `finance_mgr`，且生产没有 active `finance_mgr`，所以在后续最小权限修正完成前必须阻断，不能宣称 CEO 本人报销已可用。规则只作用于新提交报销单，提交时保存 `workflow_steps_snapshot`，后续审批推进只读快照，不因之后修改审批规则而漂移。
|
||||
|
||||
执行边界：
|
||||
|
||||
- 不把 `wangshunli/HYD000006` 配成假直属主管，不用组织主数据造假绕过流程。
|
||||
- 不给 `majianyong` 配置假直属主管，不用组织主数据造假绕过流程；`wangshunli` 仅为系统管理员，不进入业务审批链。
|
||||
- 不允许自审；若兜底角色也是申请人本人持有的角色，或没有 active 非本人持有人，提交必须阻断。
|
||||
- 不支持 `admin` 作为负责人本人报销兜底角色；`admin` 仍只代表系统管理权限，不代表业务审批权。
|
||||
- 当前首版只覆盖 OA 报销金额规则，不扩展到采购、合同、复杂 BPM 或自由流程。
|
||||
- 现有启用报销金额规则迁移时默认回填 `ownerSelfFallbackRole=finance_mgr`；OAFLOW1 首版只允许 `finance_mgr` 或置空，置空后负责人本人无主管申请将继续阻断。
|
||||
- 现有实现只允许 `ownerSelfFallbackRole=finance_mgr` 或置空。后续修正必须让 active 非本人 `finance` 可作为 CEO 兜底，并同步清理中/大额规则中不可解析的 `finance_mgr` 节点；完成前负责人本人申请继续阻断。
|
||||
|
||||
预期链路示例：
|
||||
|
||||
| 金额规则 | 原链路 | 负责人本人申请快照 |
|
||||
| --- | --- | --- |
|
||||
| 小额 | `manager -> finance` | `finance_mgr -> finance` |
|
||||
| 中额 | `manager -> finance_mgr` | `finance_mgr` |
|
||||
| 大额 | `manager -> ceo -> finance_mgr` | `finance_mgr` |
|
||||
| 小额 | `manager -> finance` | 目标：`finance`；当前因只支持 `finance_mgr` 而阻断 |
|
||||
| 中额 | `manager -> finance_mgr` | 目标：`finance`；当前兜底及原规则均需修正 |
|
||||
| 大额 | `manager -> ceo -> finance_mgr` | 目标：`finance`；移除本人 `ceo` 后仍须清理不可解析的 `finance_mgr` 节点 |
|
||||
|
||||
---
|
||||
|
||||
@@ -571,10 +571,10 @@ WF8 当前正式验收通道为站内通知和企业微信个人应用消息。
|
||||
| 撤回 | 申请人在未完成前撤回 | 流程终止或回到草稿；审批人待办失效 |
|
||||
| 转审 | 当前审批人填写原因并转给有权限人员 | 原审批人待办关闭；目标审批人产生新待办；历史显示转审链路 |
|
||||
| 无审批人阻断 | 提交时审批规则找不到审批人 | 提交失败，无半截流程，提示联系管理员 |
|
||||
| 正式主管链路 | 专用员工提交普通低/中额单据；`majianyong` 处理待办 | 待办分配给员工直属主管，审批历史显示 `majianyong` 处理 |
|
||||
| 公司负责人二审 | 专用员工提交高额、高风险或例外单据；`majianyong` 通过后进入 `wangshunli` | 串行节点完整，`wangshunli(ceo)` 作为老板/总经理节点处理 |
|
||||
| 主管本人申请 | `majianyong` 提交单据 | 主管本人不能自审，按组织链进入 `wangshunli(ceo)` 或明确非本人兜底节点 |
|
||||
| 公司负责人本人申请 | `wangshunli` 提交并触发老板/总经理节点 | 不允许自审；若无非本人兜底审批人，应阻断并提示管理员修正规则 |
|
||||
| 正式主管链路 | 专用员工提交普通低/中额单据；其 active 直属主管处理待办 | 待办分配给实际直属主管，审批历史与组织关系一致 |
|
||||
| 公司负责人二审 | 高额、高风险或例外单据进入 `ceo` 节点 | 串行节点完整，`majianyong(ceo)` 处理负责人节点 |
|
||||
| 主管本人申请 | 当前 `manager` 提交单据 | 主管本人不能自审，按组织链进入 `majianyong(ceo)` 或明确非本人兜底节点 |
|
||||
| 公司负责人本人申请 | `majianyong` 提交并触发负责人本人兜底 | 不允许自审；目标由 active 非本人 `finance` 审批，当前实现缺口未修复时应阻断 |
|
||||
| 系统管理员无业务审批权 | 仅 `admin` 角色账号尝试审批业务单据 | 服务端拒绝，不因 `admin` 权限生成审批历史 |
|
||||
| 并发处理 | 两个窗口同时处理同一任务 | 只有一个结果生效，另一个提示任务已变化 |
|
||||
| 通知失败不阻断 | 模拟企业微信通知发送失败 | 审批提交或处理成功，通知记录进入失败可重试 |
|
||||
|
||||
在新工单中引用
屏蔽一个用户