P3.5: prop-acc 启用子模块嵌套(adhoc/),应对大型业务域扩展

背景:
单纯按 UDAS 严格扁平,prop-acc/scenarios/ 装齐 7 子模块后预计 100-150
篇 .md 单一文件夹,Explorer 无法浏览、Quartz folder page 无法阅读。

扩展规则(已写入 SKILL.md 多域章节 + multi-domain.md 第 10 节):
- 单类型文件夹文件数 > 30 且能按业务子模块分组时,启用嵌套
- 路径:<domain>/<type>/<sub-feature>/<file>.md
- 文件名去 <sub-feature>- 前缀(路径已表达)
- title 三段式:<domain> · <sub-feature> · <名>
- frontmatter 新增 sub_feature 字段(便于 RAG 过滤)
- 跨子模块文档落在 <domain>/<type>/(不进子文件夹),与"跨域→cross/"对称

本次迁移:
- prop-acc/concepts/adhoc-*.md (3)  → prop-acc/concepts/adhoc/*.md
- prop-acc/scenarios/adhoc-*.md (25) → prop-acc/scenarios/adhoc/*.md
- 每个文件:title 加 adhoc 段、aliases 追加旧 prop-acc · 前缀形式(兼容)、
  新增 sub_feature: adhoc 字段

WikiLink 解析未受影响:
- 既有 [[场景-A流-...]] 等 200+ 引用通过 aliases (含旧 basename) 解析
- 新引用可用 [[adhoc · 前台购买 IC 卡]] 或 [[prop-acc · adhoc · 前台购买 IC 卡]]
- 各域 knowledge-map.md 内 WikiLink 全部仍有效

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Willie
2026-05-25 20:55:59 +08:00
parent e9ed756fc4
commit 35c0147a7b
28 changed files with 84 additions and 28 deletions

View File

@@ -0,0 +1,85 @@
---
title: prop-acc · adhoc · AdHocEvent 状态机
aliases:
- prop-acc · AdHocEvent 状态机
- AdHocEvent 状态机
- 概念-AdHocEvent状态机
tags:
- 概念
- prop-acc
- 一次性收费
- 核心概念
audience:
- 业务人员
status: 已发布
sub_feature: adhoc
last_review: 2026-05-25
code_version: 2026-05-22
---
# AdHocEvent 状态机
> [!info] 给谁看
> 这篇主要给**业务人员**和**财务**。业户只关心"我买完了没",不需要懂状态机。
每张一次性收费记录都有一个 `status` 字段,只有三种状态:
| 状态 | 中文 | 什么时候出现 |
|---|---|---|
| `Pending` | 待付款 | B 流下单后未付款 |
| `Completed` | 已收款 | A 流提交后 / B 流支付回调后 |
| `Voided` | 已作废 | 走 VoidAction 后 |
## 状态流转图
```mermaid
stateDiagram-v2
[*] --> Pending: B 流 小程序下单
[*] --> Completed: A 流 前台即收即付
Pending --> Completed: 业户付款<br/>(回调 或 前台补缴)
Pending --> Voided: 业户撤单<br/>或 超时未付
Completed --> Voided: 录错作废
```
## 每种状态下能做什么
| 当前状态 | 编辑(Edit) | 作废(Void) | 删除(Delete) |
|---|---|---|---|
| **Pending** | ✅ 可改业户、金额等 | ✅ 跟 Completed 一样级联废 CO | ❌ 已禁用 UI 入口 |
| **Completed** | ❌ 不可改(审计要求) | ✅ 级联废 CO + Receipt | ❌ 已禁用 UI 入口 |
| **Voided** | ❌ | ❌ 已经废了 | ❌ |
> [!warning] 为什么禁用 Delete?
> 删除是无审计的物理操作,B 流的 Pending 单删掉会让关联的 CollectionOrder 变孤儿。所有"取消"统一走 [[场景-已收款作废\|VoidAction]] —— 留 `voided_at` / `voided_reason` / `voided_by` 完整审计。
## 状态与 CollectionOrder / Receipt 的对应关系
```mermaid
stateDiagram-v2
state "Pending<br/>AdHocEvent + CO(Pending)<br/>没收据" as P
state "Completed<br/>AdHocEvent + CO(Completed)<br/>+ Receipt(Issued)" as C
state "Voided<br/>AdHocEvent + CO(Failed)<br/>+ Receipt(Voided)" as V
[*] --> P: B 流下单
[*] --> C: A 流即收即付
P --> C: 支付完成
P --> V: 业户撤 或 超时
C --> V: 已收款作废
```
详见 [[概念-CollectionOrder与Receipt]] 关于这三张表的关系。
## 状态相关的几个时间字段
- `created_at` —— 记录何时创建(下单时间)
- `occurred_at` —— 业务发生时间(可能与 created_at 不同,业务自定义)
- `meta.voided_at` —— 作废时间(如果走过 VoidAction)
- `meta.voided_reason` —— 作废原因(运营/财务追溯)
- `meta.voided_by` —— 谁作废的(责任追溯)
## 看完去哪?
- 想了解 CollectionOrder 和 Receipt 状态如何联动 → [[概念-CollectionOrder与Receipt]]
- 想了解 A/B 两种流程的区别 → [[概念-A流与B流]]
- 想看作废的真实例子 → [[场景-已收款作废]]