vault backup: 2026-05-25 13:29:32
This commit is contained in:
Willie
4
.obsidian/workspace.json
vendored
4
.obsidian/workspace.json
vendored
@@ -186,6 +186,10 @@
|
|||||||
},
|
},
|
||||||
"active": "b06ed69835363258",
|
"active": "b06ed69835363258",
|
||||||
"lastOpenFiles": [
|
"lastOpenFiles": [
|
||||||
|
"prop-acc/一次性收费/场景-已收款作废.md",
|
||||||
|
"prop-acc/一次性收费/场景-超时未付自动作废.md",
|
||||||
|
"prop-acc/一次性收费/场景-跨渠道补缴.md",
|
||||||
|
"prop-acc/一次性收费/场景-B流-小程序下单+微信支付.md",
|
||||||
"prop-acc/一次性收费/场景-A流-前台购买IC卡.md",
|
"prop-acc/一次性收费/场景-A流-前台购买IC卡.md",
|
||||||
"prop-acc/一次性收费/概念-CollectionOrder与Receipt.md",
|
"prop-acc/一次性收费/概念-CollectionOrder与Receipt.md",
|
||||||
"prop-acc/一次性收费/概念-A流与B流.md",
|
"prop-acc/一次性收费/概念-A流与B流.md",
|
||||||
|
|||||||
128
prop-acc/一次性收费/场景-B流-小程序下单+微信支付.md
Normal file
128
prop-acc/一次性收费/场景-B流-小程序下单+微信支付.md
Normal file
@@ -0,0 +1,128 @@
|
|||||||
|
---
|
||||||
|
title: 场景 - B 流 - 小程序下单 + 微信支付
|
||||||
|
tags:
|
||||||
|
- prop-acc
|
||||||
|
- 一次性收费
|
||||||
|
- 业务场景
|
||||||
|
- B流
|
||||||
|
audience:
|
||||||
|
- 业户
|
||||||
|
- 业务人员
|
||||||
|
status: stable
|
||||||
|
last_reviewed: 2026-05-25
|
||||||
|
code_version: 2026-05-22
|
||||||
|
---
|
||||||
|
|
||||||
|
# 场景:小程序下单 + 微信支付
|
||||||
|
|
||||||
|
线上 B 流的标准路径。**业户自助、24h 可办、无需到柜台**。
|
||||||
|
|
||||||
|
> [!warning] 当前阶段
|
||||||
|
> 后端数据模型 + Action 已就绪(2026-05-21 落地)。**小程序 API + 支付网关回调 webhook 还在开发**。本场景描述的是上线后的完整体验。
|
||||||
|
|
||||||
|
## 典型情境
|
||||||
|
|
||||||
|
> [!example] 真实情境
|
||||||
|
> 小李,32 岁,周三晚上 9 点在家想给老婆买张游泳卡。物业前台早下班了,但他打开物业小程序,5 分钟搞定。
|
||||||
|
|
||||||
|
## 业户视角(您要做什么)
|
||||||
|
|
||||||
|
### 第 1 步:打开小程序
|
||||||
|
|
||||||
|
进入"我家 → 一次性收费"
|
||||||
|
|
||||||
|
### 第 2 步:选项目
|
||||||
|
|
||||||
|
页面上列出您能买的项目(IC 卡 / 装修证 / 泳票 / 充电桩电费 / ...)。点击"游泳卡"。
|
||||||
|
|
||||||
|
### 第 3 步:确认订单
|
||||||
|
|
||||||
|
- 项目:游泳卡(月卡)
|
||||||
|
- 单价:¥200
|
||||||
|
- 数量:1(可调)
|
||||||
|
- 金额:¥200
|
||||||
|
|
||||||
|
> [!info] 系统里发生了什么
|
||||||
|
> 您点"确认下单"后,系统**冻结当前价格**(以后涨价不影响您这单),给您一个订单号。
|
||||||
|
>
|
||||||
|
> 订单状态此刻:`Pending`(待付款),**30 分钟内有效**。
|
||||||
|
|
||||||
|
### 第 4 步:微信支付
|
||||||
|
|
||||||
|
跳转到微信支付页面,密码 / 指纹 / 扫脸付款。
|
||||||
|
|
||||||
|
### 第 5 步:小程序通知
|
||||||
|
|
||||||
|
支付成功后,小程序弹通知:**"已付款,可至前台领取游泳卡"** + 收据 PDF 自动生成,在"我的订单"里可下载。
|
||||||
|
|
||||||
|
> [!success] 完成
|
||||||
|
> 系统状态此刻:订单 `Completed`,收据 `Issued`,所有记录归档。
|
||||||
|
|
||||||
|
## 业务人员视角
|
||||||
|
|
||||||
|
> [!tip] 前台几乎不用操作
|
||||||
|
> 业户线上完成全部流程,**前台只需在业户来取货时核对订单号**:
|
||||||
|
>
|
||||||
|
> 1. 打开 Filament 后台 → 一次性收费
|
||||||
|
> 2. 搜业户的订单号(CO-xxx)
|
||||||
|
> 3. 确认状态是 Completed
|
||||||
|
> 4. 把游泳卡 / 物理凭证交给业户
|
||||||
|
|
||||||
|
不需要再录任何东西 —— **业户线上做完了所有数据录入**。
|
||||||
|
|
||||||
|
## 系统流程(技术视角)
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
sequenceDiagram
|
||||||
|
participant 业户
|
||||||
|
participant 小程序
|
||||||
|
participant 系统
|
||||||
|
participant 微信支付
|
||||||
|
participant 监听器
|
||||||
|
|
||||||
|
业户->>小程序: 选游泳卡、确认下单
|
||||||
|
小程序->>系统: POST /api/ad-hoc-events
|
||||||
|
系统->>系统: CreatePendingAdHocEventAction
|
||||||
|
系统->>系统: 1. 建 AdHocEvent (Pending)
|
||||||
|
系统->>系统: 2. 建 CollectionOrder (Pending, expires_at=now+30min)
|
||||||
|
系统-->>小程序: 返回订单号 CO-xxx + 支付参数
|
||||||
|
小程序->>微信支付: 拉起支付
|
||||||
|
业户->>微信支付: 输入密码 / 指纹
|
||||||
|
微信支付->>系统: POST /webhook/wechat-pay
|
||||||
|
系统->>系统: MarkAdHocEventPaidAction
|
||||||
|
系统->>系统: 1. 补支付字段到 CO
|
||||||
|
系统->>系统: 2. 翻 CO → Completed
|
||||||
|
系统->>系统: 3. 翻 AdHocEvent → Completed
|
||||||
|
系统->>系统: 4. 清 expires_at
|
||||||
|
系统->>监听器: 触发 CollectionOrderCompleted
|
||||||
|
监听器->>系统: 建 Receipt + ReceiptItem
|
||||||
|
系统-->>小程序: 推通知 + 收据 PDF
|
||||||
|
小程序-->>业户: 弹"已付款,可来取货"
|
||||||
|
```
|
||||||
|
|
||||||
|
## 常见问题
|
||||||
|
|
||||||
|
> [!question] 我下完单忘记付怎么办?
|
||||||
|
> 30 分钟内没付,订单**自动作废**,价格也释放。您可以重新下单,**但价格按当前价**(以防您预定旧价、等到打折涨价才付)。详见 [[场景-超时未付自动作废]]。
|
||||||
|
|
||||||
|
> [!question] 付了钱小程序没显示成功怎么办?
|
||||||
|
> 微信支付有可能延迟回调(几秒到几分钟)。**别重复支付**!等几分钟再看小程序"我的订单"。若 10 分钟还没更新,联系物业,他们能后台手动核实。
|
||||||
|
|
||||||
|
> [!question] 我可以让我儿子帮我下单吗?
|
||||||
|
> 完全可以,而且您可以**不用儿子付钱** —— 让儿子帮您下完单,您拿订单号到前台付现金即可。详见 [[场景-跨渠道补缴]]。
|
||||||
|
|
||||||
|
> [!question] 想换支付方式?微信换支付宝?
|
||||||
|
> 同一笔订单不能换。如果还没付,在小程序"我的订单"里**撤单**,重新下一单选支付宝。
|
||||||
|
|
||||||
|
## 异常分支
|
||||||
|
|
||||||
|
- 想取消未付订单 → 场景-取消-业户改主意主动撤单(待补)
|
||||||
|
- 超时没付了 → [[场景-超时未付自动作废]]
|
||||||
|
- 跨渠道支付 → [[场景-跨渠道补缴]]
|
||||||
|
- 付了款发现订单数据错 → [[场景-已收款作废]]
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[概念-A流与B流]] — 为什么 B 流要"下单 + 支付"两步
|
||||||
|
- [[概念-CollectionOrder与Receipt]] — 订单和收据生成时机
|
||||||
|
- [[概念-AdHocEvent状态机]] — Pending → Completed 流转
|
||||||
147
prop-acc/一次性收费/场景-已收款作废.md
Normal file
147
prop-acc/一次性收费/场景-已收款作废.md
Normal file
@@ -0,0 +1,147 @@
|
|||||||
|
---
|
||||||
|
title: 场景 - 已收款作废
|
||||||
|
tags:
|
||||||
|
- prop-acc
|
||||||
|
- 一次性收费
|
||||||
|
- 业务场景
|
||||||
|
- 取消退款
|
||||||
|
audience:
|
||||||
|
- 业户
|
||||||
|
- 业务人员
|
||||||
|
status: stable
|
||||||
|
last_reviewed: 2026-05-25
|
||||||
|
code_version: 2026-05-22
|
||||||
|
---
|
||||||
|
|
||||||
|
# 场景:已收款作废
|
||||||
|
|
||||||
|
业户**已经付了钱**,但因为各种原因(录错、反悔、退货)需要作废这笔交易。**走 VoidAction 路径**,系统级联废订单 + 收据,留完整审计。
|
||||||
|
|
||||||
|
## 典型情境
|
||||||
|
|
||||||
|
> [!example] 情境 1:职员录错金额
|
||||||
|
> 张阿姨买 IC 卡 ¥30,职员手滑录成 ¥300,业户付完发现不对。
|
||||||
|
>
|
||||||
|
> → 立刻作废 → 退还 ¥300 现金 → 重新录入正确金额 ¥30 → 业户重新付 ¥30。
|
||||||
|
|
||||||
|
> [!example] 情境 2:业户反悔
|
||||||
|
> 李先生买了张游泳卡 ¥200,出门走两步觉得不想要了。
|
||||||
|
>
|
||||||
|
> → 当场作废 → 退还 ¥200 现金。
|
||||||
|
|
||||||
|
> [!example] 情境 3:实物缺货
|
||||||
|
> 业户付了 IC 卡的钱,但当天工本卡库存为 0 制不了卡。
|
||||||
|
>
|
||||||
|
> → 作废订单 → 退还现金 → 等到货后业户再来。
|
||||||
|
|
||||||
|
## 业户视角
|
||||||
|
|
||||||
|
### 您看到什么
|
||||||
|
|
||||||
|
- 您付完钱后告诉职员要作废
|
||||||
|
- 职员当场操作,系统**几秒内完成**
|
||||||
|
- 现金当场退还(或微信原路退回)
|
||||||
|
- 您能收到**新的"作废收据"**或在小程序"我的订单"看到状态变 `已作废`
|
||||||
|
|
||||||
|
> [!success] 没有"二次扣款"风险
|
||||||
|
> 作废操作是**原子的**(整体成功或整体回滚)。不会出现"系统已退钱、但订单还显示已收款"的半成品状态。
|
||||||
|
|
||||||
|
## 业务人员视角
|
||||||
|
|
||||||
|
### 操作步骤
|
||||||
|
|
||||||
|
```
|
||||||
|
Filament 后台 → 一次性收费列表
|
||||||
|
├── 找到该订单(状态 Completed)
|
||||||
|
├── 点击行操作菜单
|
||||||
|
└── "作废"(红色危险按钮)
|
||||||
|
├── Modal 弹出
|
||||||
|
├── 必填:作废原因(详细文字,后续审计要看)
|
||||||
|
│ 例:"客户取消订单,现金已退还"
|
||||||
|
│ 例:"录入金额错误,客户付款后发现"
|
||||||
|
│ 例:"工本卡缺货,客户无法当场拿货"
|
||||||
|
├── 提交
|
||||||
|
└── 系统瞬间完成:
|
||||||
|
├── AdHocEvent → Voided
|
||||||
|
├── CollectionOrder → Failed
|
||||||
|
├── Receipt → Voided
|
||||||
|
└── meta 记 voided_at / voided_reason / voided_by
|
||||||
|
```
|
||||||
|
|
||||||
|
### 然后业务人员手动处理资金
|
||||||
|
|
||||||
|
> [!warning] 关键:**资金不会自动退**
|
||||||
|
> VoidAction 只更新数据库记录,**不会自动调用退款接口**。需要业务人员:
|
||||||
|
>
|
||||||
|
> - **现金支付**:从收银抽屉拿出对应金额还给业户
|
||||||
|
> - **微信支付**:在物业商户后台手动发起退款(微信会几小时内退到业户原账户)
|
||||||
|
> - **POS 刷卡**:在 POS 机上做"撤销"操作(只能当天)
|
||||||
|
>
|
||||||
|
> 如果业务方将来需要"作废 = 自动退款"的一体化,可以补 RefundAction。当前不做。
|
||||||
|
|
||||||
|
### 业务人员必须填的"作废原因"
|
||||||
|
|
||||||
|
> [!tip] 写清楚 = 自救
|
||||||
|
> 半年后审计来抽查,问"这笔为啥作废"。如果 voided_reason 只写"作废了" → 业务人员说不清。
|
||||||
|
>
|
||||||
|
> 推荐写法:
|
||||||
|
> - **谁要求作废**(客户主动 / 物业发现 / 系统异常)
|
||||||
|
> - **作废后资金处理**(已退现金 ¥X / 微信退款已发起 / 待退)
|
||||||
|
> - **是否同一笔后续会重做**(是 → 重新下单单号 / 否 → 完全取消)
|
||||||
|
|
||||||
|
## 系统流程
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
sequenceDiagram
|
||||||
|
participant 业务人员
|
||||||
|
participant Filament
|
||||||
|
participant 数据库
|
||||||
|
|
||||||
|
业务人员->>Filament: 选择已收款订单,点"作废"
|
||||||
|
Filament->>业务人员: 弹出 Modal,要求填作废原因
|
||||||
|
业务人员->>Filament: 提交(含原因)
|
||||||
|
Filament->>数据库: 开启事务
|
||||||
|
Filament->>数据库: 1. Receipt.void(reason) 翻 Voided
|
||||||
|
Filament->>数据库: 2. CollectionOrder.update(status=Failed, meta+voided_*)
|
||||||
|
Filament->>数据库: 3. AdHocEvent.update(status=Voided, meta+voided_*)
|
||||||
|
Filament->>数据库: 提交事务
|
||||||
|
Filament-->>业务人员: 作废成功通知
|
||||||
|
```
|
||||||
|
|
||||||
|
> [!info] 三表级联,一处失败全回滚
|
||||||
|
> Receipt 失败 → CollectionOrder 不动、AdHocEvent 不动。三张表要么全成功要么全回到原状,不会出现"事件作废了但收据还显示有效"的脏数据。
|
||||||
|
|
||||||
|
## 与 Pending 单作废的区别
|
||||||
|
|
||||||
|
| 维度 | Pending 单作废 | Completed 单作废(本场景) |
|
||||||
|
|---|---|---|
|
||||||
|
| 触发场景 | 业户撤单 / 超时 | 业户已付款后反悔 / 录错 |
|
||||||
|
| 是否级联废收据 | ❌ Pending 单没收据 | ✅ 收据翻 Voided |
|
||||||
|
| 资金 | 没收过,不用退 | **需手动退还**(系统不自动)|
|
||||||
|
| 操作复杂度 | 一键 | 一键 + 业务人员手动处理资金 |
|
||||||
|
|
||||||
|
## 常见问题
|
||||||
|
|
||||||
|
> [!question] 作废后还能"再恢复"成已收款吗?
|
||||||
|
> **不能**。Voided 是终态。要重做,**新建一单**即可(订单号会不同,审计独立)。
|
||||||
|
|
||||||
|
> [!question] 业务人员忘了写作废原因怎么办?
|
||||||
|
> Modal 表单**强制必填**,空着提交会被拒绝。
|
||||||
|
|
||||||
|
> [!question] 业户已经走了,我能事后作废吗?
|
||||||
|
> 技术上**可以**,但要**联系业户协调资金**(打电话叫人来拿钱、或微信转账)。原则上**当场处理最干净**。
|
||||||
|
|
||||||
|
> [!question] 这跟"退款"有什么区别?
|
||||||
|
> 作废 = "这笔交易不存在了,数据库标记废除"。退款 = "交易存在,但钱退回去了"。当前一次性收费**只做作废**,没有独立的退款流程。如果未来业务方需要"红字凭证 + 保留原单"的退款,会按保证金/预存款模块同款方式实现。
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[概念-AdHocEvent状态机]] — Completed → Voided 流转
|
||||||
|
- [[概念-CollectionOrder与Receipt]] — 三件套同步翻状态
|
||||||
|
- [[场景-A流-前台购买IC卡]] — 正向流程
|
||||||
|
- [[场景-B流-小程序下单+微信支付]] — 线上交易也可作废
|
||||||
|
|
||||||
|
## 待补场景
|
||||||
|
|
||||||
|
- 场景-取消-业户改主意主动撤单(Pending 单的撤单,业户在小程序操作)
|
||||||
|
- 场景-取消-录错金额作废重做(更详细的"作废+重做"组合流程)
|
||||||
142
prop-acc/一次性收费/场景-超时未付自动作废.md
Normal file
142
prop-acc/一次性收费/场景-超时未付自动作废.md
Normal file
@@ -0,0 +1,142 @@
|
|||||||
|
---
|
||||||
|
title: 场景 - 超时未付自动作废
|
||||||
|
tags:
|
||||||
|
- prop-acc
|
||||||
|
- 一次性收费
|
||||||
|
- 业务场景
|
||||||
|
- 取消退款
|
||||||
|
audience:
|
||||||
|
- 业户
|
||||||
|
- 业务人员
|
||||||
|
status: stable
|
||||||
|
last_reviewed: 2026-05-25
|
||||||
|
code_version: 2026-05-22
|
||||||
|
---
|
||||||
|
|
||||||
|
# 场景:超时未付自动作废
|
||||||
|
|
||||||
|
业户在小程序下单后**没有及时付款**,系统在订单到期后**自动作废**。
|
||||||
|
|
||||||
|
> [!warning] 实现状态
|
||||||
|
> 后端 `VoidAdHocEventAction` 已就绪。**自动扫描 scheduled job 尚未实现**(预定与 payment-gateway webhook 同期上线)。本场景描述上线后体验。
|
||||||
|
|
||||||
|
## 典型情境
|
||||||
|
|
||||||
|
> [!example] 真实情境
|
||||||
|
> 周三下午,陈先生在小程序上下单一张游泳卡 ¥200。下单完接了个电话,把这事忘了。
|
||||||
|
>
|
||||||
|
> 30 分钟后他想起来,打开小程序"我的订单",订单已经变成 "已作废"。原因栏写着:**[订单超时作废] expires_at 已过**。
|
||||||
|
|
||||||
|
## 业户视角
|
||||||
|
|
||||||
|
### 您看到什么
|
||||||
|
|
||||||
|
下单后超时未付,小程序"我的订单"里:
|
||||||
|
|
||||||
|
```
|
||||||
|
游泳卡(月卡)
|
||||||
|
订单号:CO-20260525-XXX
|
||||||
|
金额:¥200
|
||||||
|
状态:❌ 已作废
|
||||||
|
作废原因:订单超时未付款
|
||||||
|
```
|
||||||
|
|
||||||
|
> [!info] 不影响后续
|
||||||
|
> 您可以**立即重新下一单**。新订单按当前价格冻结(如果项目涨价了,以新价为准)。
|
||||||
|
|
||||||
|
### 为什么要超时?
|
||||||
|
|
||||||
|
> [!tip] 业户视角:为什么超时设计?
|
||||||
|
> 假设您下单不付款占着这个金额很久,后台一直把项目库存(比如装修证只有 100 张)留给您 —— 不公平。**超时机制让资源可循环**。
|
||||||
|
|
||||||
|
## 业务人员视角
|
||||||
|
|
||||||
|
### 业务人员一般不需要管
|
||||||
|
|
||||||
|
> [!success] 完全自动化
|
||||||
|
> Scheduled job 每隔一段时间(比如每小时)扫描全表,自动处理超时单。**前台不用做任何事**。
|
||||||
|
|
||||||
|
### 业务人员能看到什么
|
||||||
|
|
||||||
|
每个超时作废的订单在 Filament 后台:
|
||||||
|
- 状态:`Voided`
|
||||||
|
- meta 字段记录:`voided_at` / `voided_reason: "[订单超时作废]"` / `voided_by: null`(系统自动,无操作员)
|
||||||
|
|
||||||
|
### 如果业户来问"我的订单怎么没了"
|
||||||
|
|
||||||
|
```
|
||||||
|
1. 在 Filament 后台搜业户姓名 / 订单号
|
||||||
|
2. 找到 Voided 记录
|
||||||
|
3. 告诉业户:"您的订单在 X 月 X 日下午 X 点超时作废了,原因是没在 30 分钟内完成支付。请重新下单。"
|
||||||
|
```
|
||||||
|
|
||||||
|
## 系统流程
|
||||||
|
|
||||||
|
```mermaid
|
||||||
|
sequenceDiagram
|
||||||
|
participant 业户
|
||||||
|
participant 小程序
|
||||||
|
participant 系统
|
||||||
|
participant Scheduled Job
|
||||||
|
|
||||||
|
业户->>小程序: 下单游泳卡 ¥200
|
||||||
|
小程序->>系统: CreatePendingAdHocEventAction
|
||||||
|
系统->>系统: 建 AdHocEvent + CO,expires_at = now + 30min
|
||||||
|
系统-->>业户: 返订单号,等待支付
|
||||||
|
|
||||||
|
Note over 业户: 业户忘了付钱
|
||||||
|
|
||||||
|
Note over Scheduled Job: 每小时扫描一次
|
||||||
|
|
||||||
|
Scheduled Job->>系统: 查询 CO where status=pending AND expires_at < now()
|
||||||
|
系统-->>Scheduled Job: 返回所有超时 Pending 单
|
||||||
|
loop 对每个超时单
|
||||||
|
Scheduled Job->>系统: VoidAdHocEventAction
|
||||||
|
系统->>系统: 级联废 AdHocEvent + CO
|
||||||
|
系统->>系统: 写 meta.voided_reason = "[订单超时作废]"
|
||||||
|
end
|
||||||
|
|
||||||
|
业户->>小程序: 想起来要付钱
|
||||||
|
小程序->>系统: 查询订单
|
||||||
|
系统-->>小程序: 状态 Voided
|
||||||
|
小程序-->>业户: 显示"订单已作废,请重新下单"
|
||||||
|
```
|
||||||
|
|
||||||
|
## 几个常见超时周期(可配置)
|
||||||
|
|
||||||
|
| 项目类型 | 推荐超时 | 理由 |
|
||||||
|
|---|---|---|
|
||||||
|
| **泳票 / 充电桩** | 30 分钟 | 业户高频下完即付 |
|
||||||
|
| **IC 卡** | 2 小时 | 业户可能要查档案、对房号 |
|
||||||
|
| **装修证(单张)** | 1 天 | 装修公司可能要走内部审批 |
|
||||||
|
| **装修证(批量)** | 7 天 | 大公司付款流程长 |
|
||||||
|
|
||||||
|
> [!warning] 跨渠道补缴场景请用长 expires_at
|
||||||
|
> 跨渠道补缴([[场景-跨渠道补缴]])时,儿女线上下单、老人现场付款 —— 中间可能隔几天。**这种场景建议 expires_at 设 7 天**,避免老人到前台时单子已废。具体配置看每个 RatePlan 的设置。
|
||||||
|
|
||||||
|
## 常见问题
|
||||||
|
|
||||||
|
> [!question] 我的订单超时了能恢复吗?
|
||||||
|
> **不能**。超时作废是终态。直接重新下单。
|
||||||
|
|
||||||
|
> [!question] 重新下单价格会不会涨?
|
||||||
|
> **可能**。系统按下单**当时的价格冻结**;如果上次下单到现在物业调价了,新订单按新价。
|
||||||
|
|
||||||
|
> [!question] 我付款的瞬间订单刚好超时,会重复扣款吗?
|
||||||
|
> **不会**。系统在 `MarkAdHocEventPaidAction` 内部有事务保护:如果订单已被作废,支付回调会失败,微信会原路退回。
|
||||||
|
|
||||||
|
> [!question] 物业前台能"延长有效期"吗?
|
||||||
|
> 当前**不支持**。要延长只能业户自己重新下单。是否要支持手动延长是个业务决策,等业务方反馈再加。
|
||||||
|
|
||||||
|
## 系统配置(技术细节,业务人员可跳过)
|
||||||
|
|
||||||
|
- 扫描 job 在 `app/Console/Kernel.php` 注册,每小时跑一次
|
||||||
|
- 查询语句:`SELECT * FROM acc_collection_orders WHERE status='pending' AND expires_at < NOW()`
|
||||||
|
- 调用 `VoidAdHocEventAction::handle($event, '[订单超时作废] expires_at < now()')`
|
||||||
|
|
||||||
|
## 相关概念
|
||||||
|
|
||||||
|
- [[概念-AdHocEvent状态机]] — Pending → Voided 流转
|
||||||
|
- [[概念-CollectionOrder与Receipt]] — `expires_at` 字段挂在 CollectionOrder 上的设计原因
|
||||||
|
- [[场景-B流-小程序下单+微信支付]] — 业户下单的正向流程
|
||||||
|
- [[场景-跨渠道补缴]] — 长 expires_at 的典型用例
|
||||||
164
prop-acc/一次性收费/场景-跨渠道补缴.md
Normal file
164
prop-acc/一次性收费/场景-跨渠道补缴.md
Normal file
@@ -0,0 +1,164 @@
|
|||||||
|
---
|
||||||
|
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 流
|
||||||
Reference in New Issue
Block a user