P3 — prop-acc 30 文件迁移到多域 UDAS 结构:
- 3 概念:旧 prop-acc/一次性收费/概念-*.md
→ prop-acc/concepts/adhoc-*.md (kebab-case 英文)
- 25 场景:旧 prop-acc/一次性收费/场景-*.md
→ prop-acc/scenarios/adhoc-*.md
- 子文件夹 index.md → prop-acc/maps/knowledge-map.md (域内地图)
- prop-acc/index.md 重写为域首页(embed knowledge-map)
- 删除空目录 prop-acc/一次性收费/
每个迁移文件:
- title 加域前缀 "prop-acc · "
- aliases 含原 title (带空格) + 原文件名 basename (无空格),保证既有 [[...]] 引用解析
- status: stable → 已发布 / draft → 草稿 (UDAS 中文枚举)
- last_reviewed → last_review (UDAS 字段名)
- tags 补加 UDAS 类型分类 "概念" / "场景"
- 路径式 WikiLink 清除:
* [[../预存款/index|XX]] → [[预存款]]
* [[一次性收费/index|XX]] → [[prop-acc · 一次性收费索引]]
P4 — 4 个新业务域骨架:
- community (社区管理)
- administrative (行政人事)
- patrol (巡护工单)
- resident-portal (业户门户)
每域含 index.md (域首页) + maps/knowledge-map.md (域内地图模板)。
另补 cross/index.md + cross/maps/cross-domain-map.md。
P5 — 顶层入口:
- index.md: 站点首页 (Quartz 着陆点),embed domain-map
- maps/domain-map.md: 5 业务域 + cross 的索引表
迁移后状态:
- 共 50 篇 .md (30 原 + 8 跨域 stub + 4 域 index + 4 域 map + 2 cross + 2 root)
- 残留路径式 WikiLink: 0
- 残留英文 status: 0
- 残留 last_reviewed 字段: 0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
2.8 KiB
2.8 KiB
title, aliases, tags, audience, status, last_review, code_version
| title | aliases | tags | audience | status | last_review | code_version | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · AdHocEvent 状态机 |
|
|
|
已发布 | 2026-05-25 | 2026-05-22 |
AdHocEvent 状态机
[!info] 给谁看 这篇主要给业务人员和财务。业户只关心"我买完了没",不需要懂状态机。
每张一次性收费记录都有一个 status 字段,只有三种状态:
| 状态 | 中文 | 什么时候出现 |
|---|---|---|
Pending |
待付款 | B 流下单后未付款 |
Completed |
已收款 | A 流提交后 / B 流支付回调后 |
Voided |
已作废 | 走 VoidAction 后 |
状态流转图
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 变孤儿。所有"取消"统一走 场景-已收款作废 —— 留
voided_at/voided_reason/voided_by完整审计。
状态与 CollectionOrder / Receipt 的对应关系
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流
- 想看作废的真实例子 → 场景-已收款作废