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>
5.6 KiB
title, aliases, tags, audience, status, last_review, code_version
| title | aliases | tags | audience | status | last_review | code_version | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · 场景 - 跨渠道补缴 |
|
|
|
已发布 | 2026-05-25 | 2026-05-22 |
场景:跨渠道补缴
儿女在小程序帮老人下单,老人到前台付现金。
这是 概念-A流与B流并存设计最有价值的副产物。其他物业系统通常做不到 —— 因为他们的"线上单"和"线下单"是两个独立流程,互不相通。
典型情境
[!example] 真实情境 李女士的妈妈(78 岁)住在北京小区,装修工人下周要进场,需要 5 张装修出入证。
李女士在上海工作,不能亲自去物业,但她能在小程序上下单,妈妈只需要拿着身份证到前台付现金取证。
业户视角(您要做什么)
第 1 步:儿女在小程序下单
(在上海)李女士打开物业小程序:
- 选项目:装修出入证 × 5
- 单价 ¥10,合计 ¥50
- 备注:"我妈下周二上午去取,身份证号 XXX"
- 提交下单(不付款)
[!info] 关键 下单时不付款 —— 系统给一个订单号(CO-xxx)。订单状态:
Pending,默认有效期可以延长(比如 7 天,后台可配)。
李女士把订单号微信发给妈妈,告诉她:"妈,这是订单号,你拿着去前台说。"
第 2 步:老人到前台
(在北京)妈妈拿身份证 + 现金 ¥50 去物业前台:
"我女儿在小程序订了 5 张装修证,订单号是 CO-20260525-XX。我来付钱拿证。"
第 3 步:前台核对 + 收款
职员在 Filament 后台搜订单号:
- 找到 Pending 订单 CO-XXX,业户名是李女士妈妈,5 张装修证 ¥50 ✅
- 点击"标记已收款" → 选支付方式"现金" → 提交
订单瞬间翻 Completed,收据生成。
第 4 步:老人拿证 + 收据
- 5 张装修出入证当场交付
- 收据可打印纸质或发到女儿微信(收据本身归属业户档案,任意指定接收方)
[!success] 完成 全程业户体验流畅:线上方便、线下办成。家庭场景里没有谁需要懂"系统怎么工作"。
业务人员视角
关键操作
Filament 后台 → 一次性收费列表
├── 切到 "待付款" tab(默认只看 Completed)
├── 搜业户名 / 订单号
└── 找到记录后,点行操作菜单
└── "标记已收款" 按钮(MarkAdHocEventPaidAction)
├── Modal 弹出:选支付方式(现金/微信/POS)
└── 提交
业务人员需要核对
[!warning] 务必核对
- 业户身份:身份证 vs 系统里登记的业户姓名是否一致
- 金额:订单冻结金额 vs 业户实付现金是否一致
- 明细:是不是业户本人订的(避免别人冒领)
后台技术细节
sequenceDiagram
participant 儿女
participant 小程序
participant 系统
participant 老人
participant 前台
儿女->>小程序: 帮妈妈下单 5 张装修证
小程序->>系统: CreatePendingAdHocEventAction
系统->>系统: 建 AdHocEvent(Pending) + CO(Pending, expires_at=7天后)
系统-->>小程序: 返订单号 CO-xxx
小程序-->>儿女: 显示订单号
儿女-->>老人: 微信发订单号
Note over 老人,前台: 几天后,老人到前台
老人->>前台: 出示订单号 + 身份证 + 现金
前台->>系统: 搜订单号
系统-->>前台: 显示订单详情
前台->>系统: 标记已收款 + 选"现金"
系统->>系统: MarkAdHocEventPaidAction
系统->>系统: 1. 补 CO 支付字段
系统->>系统: 2. 翻 CO + AdHocEvent → Completed
系统->>系统: 3. 触发 CollectionOrderCompleted
系统->>系统: 4. 自动生成 Receipt
系统-->>前台: 完成通知
前台->>老人: 出装修证 + 给收据
为什么这个场景重要?
[!tip] 业务价值 中国家庭真实写照:子女在外地工作,老人留守原小区。物业要服务老人,但年轻人想用便利渠道帮忙。
传统物业系统强迫家庭"二选一"(要么子女线上全部办完含付款 / 要么老人现场全部办完),本系统让线上线下衔接无缝。
常见问题
[!question] 订单号丢了怎么办? 前台可以用业户姓名 + 身份证号搜系统里所有 Pending 单。
[!question] 儿女下单时填错了金额怎么办? 老人到前台时,职员发现金额不对,可以作废原单(走 场景-已收款作废 的轻量版,Pending 单作废没收据可废),让儿女或老人在前台直接重新下一单 A 流。
[!question] 跨城市可以吗? 完全可以。订单是物业系统里的数据,不绑定地理位置。儿女在哪个国家都行,只要老人到对应小区物业即可。
[!question] 多人同时帮老人下单怎么办? 老人会在系统里有多个 Pending 单。前台核对时一一处理,支付一笔结一笔。
业户的"双向感觉"
journey
title 业户体验地图
section 儿女(线上视角)
下单: 5: 儿女
看到订单号: 5: 儿女
不需付款: 5: 儿女
不需关注后续: 4: 儿女
section 老人(线下视角)
拿订单号到前台: 5: 老人
付现金: 4: 老人
当场拿货: 5: 老人
纸质收据: 5: 老人
相关概念
- 概念-A流与B流 — 共用一套表的关键设计决定
- 概念-CollectionOrder与Receipt — 订单状态如何流转
- 概念-AdHocEvent状态机 — Pending → Completed
- 场景-B流-小程序下单+微信支付 — 对比标准 B 流