165 lines
5.5 KiB
Markdown
165 lines
5.5 KiB
Markdown
---
|
||
title: 场景 - 跨渠道补缴
|
||
tags:
|
||
- prop-acc
|
||
- 一次性收费
|
||
- 业务场景
|
||
- A流
|
||
- B流
|
||
audience:
|
||
- 业户
|
||
- 业务人员
|
||
status: stable
|
||
last_reviewed: 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 流
|