b7c0cd6e0c
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.9 KiB
2.9 KiB
title, aliases, tags, audience, status, last_review, code_version
| title | aliases | tags | audience | status | last_review | code_version | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · A 流与 B 流 |
|
|
|
已发布 | 2026-05-25 | 2026-05-22 |
A 流与 B 流
一次性收费支持两条独立购买路径,底层用同一套数据表,差别只在用户怎么发起。
一句话区别
[!tip] 通俗版
- A 流:您到柜台找物业阿姨,付了钱当场出货
- B 流:您自己在小程序下单,微信付完,过来取(或者送到家)
对照表
| 维度 | A 流(线下即收即付) | B 流(线上订单—支付分离) |
|---|---|---|
| 典型用户 | 老人、不会用手机的业户 | 年轻业户、工作日没空到前台的人 |
| 触发动作 | 业户走到前台 | 小程序下单 |
| 付款时机 | 当场付(现金 / POS / 微信扫码) | 下单时锁定金额、付款分离 |
| 生效时机 | 即时 — 一笔操作完成所有 | 两步:下单 → 支付回调 |
| 失败模式 | 几乎不可能(人在柜台) | 可能超时未付、可能支付掉单 |
| 取消方式 | 走 场景-已收款作废 流程 | 改主意可主动撤;或超时自动作废 |
系统视角(流程图)
sequenceDiagram
participant 业户
participant 前台
participant 小程序
participant 系统
participant 支付网关
Note over 业户,系统: A 流(线下即收即付)
业户->>前台: 我要买 IC 卡
前台->>系统: 录入业户、项目、金额、付现金
系统->>系统: 一气呵成:建事件 + 建订单 + 建收据
系统-->>业户: 打印 / 微信收据立马拿到
Note over 业户,支付网关: B 流(订单—支付分离)
业户->>小程序: 下单 IC 卡
小程序->>系统: 建事件(Pending) + 建订单(Pending)
系统-->>业户: 锁价格、给您订单号
业户->>支付网关: 微信付款
支付网关->>系统: 支付回调
系统->>系统: 更新订单(Completed) + 自动出收据
系统-->>业户: 小程序通知:已付款,可来取货
为什么要两套?
[!info] 业户视角
- 老人不会用小程序 → A 流照顾他们
- 年轻人不想跑前台 → B 流方便
- 同一项业务两种付款方式都能用
[!info] 系统视角 两套共用同一张
AdHocEvent表 + 同一张CollectionOrder表。差别只在:
- A 流一气呵成创建后,状态直接
Completed- B 流先创建为
Pending,等支付回调才翻Completed这种设计的好处是跨渠道补缴天然支持 —— 详见 场景-跨渠道补缴。
看完去哪?
- 想了解购买后系统记了什么 → 概念-CollectionOrder与Receipt
- 想了解订单的几种状态 → 概念-AdHocEvent状态机
- 想看真实例子 → 场景-A流-前台购买IC卡 或 场景-B流-小程序下单+微信支付