vault backup: 2026-05-25 13:44:33
This commit is contained in:
146
prop-acc/一次性收费/场景-取消-录错金额作废重做.md
Normal file
146
prop-acc/一次性收费/场景-取消-录错金额作废重做.md
Normal file
@@ -0,0 +1,146 @@
|
||||
---
|
||||
title: 场景 - 取消 - 录错金额作废重做
|
||||
tags:
|
||||
- prop-acc
|
||||
- 一次性收费
|
||||
- 业务场景
|
||||
- 取消退款
|
||||
audience:
|
||||
- 业务人员
|
||||
status: stable
|
||||
last_reviewed: 2026-05-25
|
||||
code_version: 2026-05-22
|
||||
---
|
||||
|
||||
# 场景:录错金额作废重做
|
||||
|
||||
业务人员**手滑录错金额**(常见:多打/少打一个零、串到隔壁字段)的修正流程。
|
||||
|
||||
## 典型情境
|
||||
|
||||
> [!example] 真实情境
|
||||
> 周末下午泳池前台高峰期,职员小赵给陈太太录入泳票订单:
|
||||
> - **应该录**:¥40(2 张 × ¥20)
|
||||
> - **实际录**:¥400(数量栏串到金额栏)
|
||||
>
|
||||
> 陈太太微信支付完跳出来,看到收据写 ¥400 当场愣住:"这怎么扣这么多?!"
|
||||
|
||||
## 业务人员视角
|
||||
|
||||
### 应急步骤(2 分钟内搞定)
|
||||
|
||||
```
|
||||
1. 当场承认错误,安抚业户
|
||||
"对不起阿姨,这是我录错了,我马上给您处理。"
|
||||
|
||||
2. 在 Filament 后台找到这笔订单
|
||||
├── 状态 Completed
|
||||
├── 金额 ¥400
|
||||
└── 业户名:陈太太
|
||||
|
||||
3. 走 VoidAction(作废)
|
||||
├── 必填作废原因:
|
||||
│ "录入金额错误,实际应为¥40。
|
||||
│ 已向业户致歉,通过微信原路退款 ¥400。
|
||||
│ 重新建一笔正确订单。"
|
||||
├── 提交
|
||||
└── 系统瞬间:订单 → Voided, 收据 → Voided
|
||||
|
||||
4. 微信商户后台发起退款 ¥400(原路退回业户)
|
||||
|
||||
5. 重新录入正确订单
|
||||
├── 数量:2
|
||||
├── 金额:¥40
|
||||
├── 支付方式:现金(因为业户当面拿现金给你)
|
||||
├── 备注:"对上一笔订单 CO-XXX 作废后重做"
|
||||
└── 提交
|
||||
|
||||
6. 给业户出新收据
|
||||
```
|
||||
|
||||
### 关键细节
|
||||
|
||||
> [!warning] 关键:**作废 + 重做必须连贯**
|
||||
> 中间不要去做别的事,容易忘记重做。**一气呵成最稳妥**。
|
||||
|
||||
> [!tip] 重做时的支付方式怎么填?
|
||||
> - 业户原本微信付的 ¥400 已经在退款中(需要几小时到账)
|
||||
> - **重新付 ¥40 走现金最简单**(业户钱包随便拿)
|
||||
> - 也可以让业户重新微信支付 ¥40(完全一笔新交易)
|
||||
> - **不建议**:让业户等微信退款到账后再交 —— 业户体验差
|
||||
|
||||
## 与"已收款作废"的区别
|
||||
|
||||
| 维度 | 已收款作废([[场景-已收款作废]]) | 录错重做(本场景)|
|
||||
|---|---|---|
|
||||
| 触发场景 | 业户反悔、缺货、退货 | 业务人员录入失误 |
|
||||
| 是否重做 | **不重做**(纯取消)| **必须重做**(业户确实要这个商品)|
|
||||
| 复杂度 | 1 步:作废 | 2 步:作废 + 重做 |
|
||||
| 资金 | 全额退给业户 | **退原金额** + **重收正确金额** |
|
||||
| 业户体验 | 一切照常,只是没了 | 短暂困惑,但快速纠正 |
|
||||
|
||||
## 系统流程
|
||||
|
||||
```mermaid
|
||||
sequenceDiagram
|
||||
participant 业户
|
||||
participant 业务人员
|
||||
participant 系统
|
||||
participant 微信商户
|
||||
|
||||
业户->>业务人员: 出示错单 ¥400
|
||||
业务人员->>系统: 找到 Completed 订单
|
||||
业务人员->>系统: VoidAction (reason="录入金额错误...")
|
||||
系统->>系统: AdHocEvent → Voided
|
||||
系统->>系统: CollectionOrder → Failed
|
||||
系统->>系统: Receipt → Voided
|
||||
系统-->>业务人员: 作废成功
|
||||
业务人员->>微信商户: 后台发起退款 ¥400
|
||||
微信商户-->>业户: 几小时内到账
|
||||
|
||||
Note over 业户,业务人员: 同时,重新录入正确订单
|
||||
|
||||
业户->>业务人员: 拿出现金 ¥40
|
||||
业务人员->>系统: 新建 AdHocEvent (¥40, 现金)
|
||||
系统->>系统: 一气呵成三件套
|
||||
系统-->>业务人员: 完成
|
||||
业务人员->>业户: 新收据 + 实物
|
||||
```
|
||||
|
||||
## 常见问题
|
||||
|
||||
> [!question] 重做的订单要不要在备注里写"对应原作废订单"?
|
||||
> **强烈建议**。写"对上一笔订单 CO-XXX 作废后重做"。这样:
|
||||
> - 财务对账时能看出"这两笔金额是同一笔业务"
|
||||
> - 半年后审计抽查,能反查到完整事件
|
||||
|
||||
> [!question] 业户离开物业前没发现错单,事后才发现怎么办?
|
||||
> 一样走作废 + 退款,但**沟通成本高**:
|
||||
> - 联系业户:"系统发现一笔订单可能有误..."
|
||||
> - 业户确认是否要重做
|
||||
> - 退款走微信(原路)
|
||||
> - 重做订单如果要新付款,**线上付款最方便**(让业户在小程序重新下单 + 支付)
|
||||
|
||||
> [!question] 业务人员自己发现录错 vs 业户发现录错,处理方式有区别吗?
|
||||
> 没区别。但**业务人员自己发现要立刻处理**,不要等业户来质疑。
|
||||
|
||||
> [!question] 高峰期录单忙容易错,有什么预防方法?
|
||||
> 1. **金额自动填**:在 Filament 后台,选 RatePlan 后金额自动算出 = `unit_price × quantity`,不要手改
|
||||
> 2. **复核机制**:提交前 Modal 弹"确认 ¥XXX?" 让业务人员肉眼复核
|
||||
> 3. **拆分付款步骤**:先收钱 + 数现金,再录入(确保实收金额对得上)
|
||||
|
||||
## 系统设计上的预防
|
||||
|
||||
> [!info] Filament Modal 已有的保护
|
||||
> 当前 `CreateAdHocEvent` 表单:
|
||||
> - 选 RatePlan 后**单价 + 总金额自动填**(避免手输错)
|
||||
> - 提交前 Modal 显示金额(让业务人员肉眼复核)
|
||||
> - 提交后给 success toast 通知(业务人员能即时看到结果)
|
||||
>
|
||||
> 如果还是错了 —— 通常是高峰期注意力分散,需要业务培训提醒。
|
||||
|
||||
## 相关概念
|
||||
|
||||
- [[概念-AdHocEvent状态机]] — Completed → Voided
|
||||
- [[场景-已收款作废]] — 基础作废流程
|
||||
- [[场景-A流-前台购买IC卡]] — 录入的正向流程
|
||||
Reference in New Issue
Block a user