Files

Willie b7c0cd6e0c P3+P4+P5: prop-acc 迁移到多域 UDAS,新建 4 域骨架与顶层入口

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>

2026-05-25 20:44:43 +08:00

3.9 KiB

Raw Blame History

title, aliases, tags, audience, status, last_review, code_version

title

aliases

CollectionOrder 与 Receipt

您在物业买东西,系统里实际生成的不是一条记录,而是三件套。理解了这三件套,就理解了财务系统大部分操作。

三件套是什么?

graph LR
    A[AdHocEvent<br/>一次性收费事件] --> B[CollectionOrder<br/>收款订单]
    B --> C[Receipt<br/>收据]
    C --> D[ReceiptItem<br/>收据明细行]

    classDef event fill:#fef3c7
    classDef order fill:#dbeafe
    classDef receipt fill:#dcfce7

    class A event
    class B order
    class C,D receipt

表	是什么	业户能看到?
AdHocEvent	"您买了什么"的业务记录(IC 卡 / 装修证 / 泳票)	❌ 内部
CollectionOrder	"怎么付的"的收款记录(微信 / 现金 / POS / 支付宝 / 银行卡)	✅ 订单号 CO-...
Receipt	"您付了钱"的收据	✅ 收据号 R-... 可打印/下载
ReceiptItem	收据上每行细目(例:IC 卡 × 1 = ¥30)	✅ 在收据里看到

业户视角

[!example] 业户视角:您拿到的东西

您去前台买了一张 IC 卡 ¥30,完成后:
物品本身:工本费一张实物 IC 卡
收据(PDF 或纸质):
收据 No: R-20260525-001
─────────────────────────
IC 卡(门禁)        ¥30.00
─────────────────────────
合计:              ¥30.00
支付方式:现金
收款人:张阿姨(柜台)
这张收据就是您的凭证。月底想对账?有收据号一查就知道。

业务人员 / 财务视角

[!example] 财务对账时

月底财务想知道这个月卖了多少 IC 卡,会查:

AdHocEvent 表 → 多少张 IC 卡售出,卖给谁

CollectionOrder 表 → 多少张订单是 "现金 / 微信 / 支付宝" 各多少

Receipt 表 → 已开收据多少张,作废多少张

三张表通过 ID 互相关联,任一张里查到一笔,都能反查到另外两张对应的行。

什么时候生成?

操作	AdHocEvent	CollectionOrder	Receipt
A 流前台买卡(即收即付)	立刻建	立刻建(Completed)	立刻自动生成
B 流小程序下单(尚未付款)	立刻建(Pending)	立刻建(Pending)	❌ 还没生成
B 流支付回调到达	翻为 Completed	翻为 Completed	此刻自动生成
作废订单	翻为 Voided	翻为 Failed	翻为 Voided

[!info] 收据怎么"自动生成" 系统监听一个叫 CollectionOrderCompleted 的事件 —— 任何时候订单状态变为 Completed,系统自动建一张 Receipt 并附明细。业户不用做任何操作。

为什么要这么设计?

[!tip] 为什么不只用一张表? 因为这三件事关注点不同:

AdHocEvent 关注"卖了什么、卖给谁"(业务面)

CollectionOrder 关注"钱怎么进来的、走哪个渠道"(财务/资金面)

Receipt 关注"给业户的凭证"(对外面)

同一笔交易,业务/财务/对外三个角度独立看,审计、对账、合规都清楚。

退款时的红字收据

[!warning] 退款也走这套链路退款时系统会生成一张负数的 CollectionOrder + Receipt(金额带负号),叫"红字凭证"。这是中国会计标准做法,详见保证金模块的退款场景文档(待补)。

一次性收费目前主要走作废而不是退款 —— 详见场景-已收款作废。

看完去哪?

想了解订单状态怎么变 → 概念-AdHocEvent状态机
想看真实例子 → 场景-A流-前台购买IC卡
想看跨渠道场景 → 场景-跨渠道补缴

3.9 KiB Raw Blame History Unescape Escape

CollectionOrder 与 Receipt

三件套是什么?

业户视角

业务人员 / 财务视角

什么时候生成?

为什么要这么设计?

退款时的红字收据

看完去哪?

3.9 KiB

Raw Blame History