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
170
prop-acc/scenarios/adhoc/cross-channel-supplementary-payment.md
Normal file
170
prop-acc/scenarios/adhoc/cross-channel-supplementary-payment.md
Normal file
@@ -0,0 +1,170 @@
|
||||
---
|
||||
title: prop-acc · adhoc · 场景 - 跨渠道补缴
|
||||
aliases:
|
||||
- prop-acc · 场景 - 跨渠道补缴
|
||||
- 场景 - 跨渠道补缴
|
||||
- 场景-跨渠道补缴
|
||||
tags:
|
||||
- 场景
|
||||
- prop-acc
|
||||
- 一次性收费
|
||||
- 业务场景
|
||||
- A流
|
||||
- B流
|
||||
audience:
|
||||
- 业户
|
||||
- 业务人员
|
||||
status: 已发布
|
||||
sub_feature: adhoc
|
||||
last_review: 2026-05-25
|
||||
code_version: 2026-05-22
|
||||
---
|
||||
|
||||
# 场景:跨渠道补缴
|
||||
|
||||
**儿女在小程序帮老人下单,老人到前台付现金**。
|
||||
|
||||
这是 [[概念-A流与B流|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] 务必核对
|
||||
> 1. **业户身份**:身份证 vs 系统里登记的业户姓名是否一致
|
||||
> 2. **金额**:订单冻结金额 vs 业户实付现金是否一致
|
||||
> 3. **明细**:是不是业户本人订的(避免别人冒领)
|
||||
|
||||
### 后台技术细节
|
||||
|
||||
```mermaid
|
||||
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 单**。前台核对时一一处理,**支付一笔结一笔**。
|
||||
|
||||
## 业户的"双向感觉"
|
||||
|
||||
```mermaid
|
||||
journey
|
||||
title 业户体验地图
|
||||
section 儿女(线上视角)
|
||||
下单: 5: 儿女
|
||||
看到订单号: 5: 儿女
|
||||
不需付款: 5: 儿女
|
||||
不需关注后续: 4: 儿女
|
||||
section 老人(线下视角)
|
||||
拿订单号到前台: 5: 老人
|
||||
付现金: 4: 老人
|
||||
当场拿货: 5: 老人
|
||||
纸质收据: 5: 老人
|
||||
```
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[概念-A流与B流]] — 共用一套表的关键设计决定
|
||||
- [[概念-CollectionOrder与Receipt]] — 订单状态如何流转
|
||||
- [[概念-AdHocEvent状态机]] — Pending → Completed
|
||||
- [[场景-B流-小程序下单+微信支付]] — 对比标准 B 流
|
||||
Reference in New Issue
Block a user