b7c0cd6e0c
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>
168 lines
5.7 KiB
Markdown
168 lines
5.7 KiB
Markdown
---
|
||
title: prop-acc · 场景 - 异常 - 业户重复下单
|
||
aliases:
|
||
- 场景 - 异常 - 业户重复下单
|
||
- 场景-异常-业户重复下单
|
||
tags:
|
||
- 场景
|
||
- prop-acc
|
||
- 一次性收费
|
||
- 业务场景
|
||
- 异常故障
|
||
audience:
|
||
- 业户
|
||
- 业务人员
|
||
status: 已发布
|
||
last_review: 2026-05-25
|
||
code_version: 2026-05-22
|
||
---
|
||
|
||
# 场景:业户重复下单
|
||
|
||
业户在小程序里**同一项目下了多笔订单**,可能是误操作、可能是网络不畅以为没下成功。
|
||
|
||
## 典型情境
|
||
|
||
> [!example] 情境 1:网络卡顿
|
||
> 周三下午,陈先生小程序下单游泳卡 ¥200。点完"下单"按钮后**页面卡了 5 秒没反应**,他不耐烦又点了一次。
|
||
>
|
||
> 5 秒后,**系统里有两笔 Pending 订单**。
|
||
|
||
> [!example] 情境 2:误操作
|
||
> 王女士下单后,**手机退到后台又重新打开**,看到一笔"待付款"以为是上次没付的旧单,又点了"重新下单"。
|
||
>
|
||
> 实际上系统里**第一笔单还在 Pending**,她又下了第二笔。
|
||
|
||
> [!example] 情境 3:批量场景
|
||
> 装修公司下单 8 张装修证,然后**忘了已经下过**,5 分钟后又下了 8 张。
|
||
>
|
||
> 系统里现在有 16 张待付款的装修证 + 16 个 CollectionOrder。
|
||
|
||
## 业户视角
|
||
|
||
### 您看到什么
|
||
|
||
打开小程序"我的订单 → 待付款":
|
||
|
||
```
|
||
🟡 待付款
|
||
├── 游泳卡 × 1 ¥200
|
||
│ 下单于 10:05
|
||
│ [立即支付] [取消订单]
|
||
│
|
||
└── 游泳卡 × 1 ¥200 ← 重复的!
|
||
下单于 10:05
|
||
[立即支付] [取消订单]
|
||
```
|
||
|
||
### 您应该怎么办
|
||
|
||
> [!tip] 简单选择
|
||
> - **只付 1 笔**(选你认为有效的那笔,通常是早的)
|
||
> - **取消另 1 笔**(走 [[场景-取消-业户改主意主动撤单]])
|
||
> - 另 1 笔不取消也行,**30 分钟后系统自动作废**
|
||
|
||
> [!warning] 千万不要"为了保险都付了"
|
||
> 都付了 → 系统记两笔有效订单 → 你被扣两次钱。要退款要联系物业,流程慢。**只付 1 笔 + 取消另 1 笔** 最干净。
|
||
|
||
## 业务人员视角
|
||
|
||
### 业户来问"我下了几个订单不知道是不是都有效"
|
||
|
||
```
|
||
1. Filament 后台 → 搜业户姓名 / 手机号
|
||
2. 切到"待付款 (Pending)" tab
|
||
3. 看是否有同一项目的多笔 Pending 单
|
||
4. 与业户确认:
|
||
├── 想要 1 笔 → 留 1 笔,作废其余
|
||
└── 全部要 → 不动,让业户每笔单独支付
|
||
5. 作废多余的 Pending 单(走 [[场景-取消-业户改主意主动撤单|主动撤单流程]])
|
||
```
|
||
|
||
### 如果业户已经把多笔都付了
|
||
|
||
```
|
||
1. 确认哪几笔是"真的要"、哪几笔是"重复多余的"
|
||
2. 多余的走 [[场景-已收款作废]]
|
||
├── 作废订单 + 收据
|
||
└── 退款(微信 / 现金 / POS)
|
||
3. 给业户确认"已退 X 元到您原微信账户"
|
||
```
|
||
|
||
## 系统视角:为什么没自动防重?
|
||
|
||
> [!info] 系统**故意不防**
|
||
> 原因:**有些业务场景就是要重复下单**!例如:
|
||
> - 业户买 3 张游泳卡分给家人,**故意拆 3 笔**(便于送人时给收据)
|
||
> - 业户买 IC 卡当礼物,要拿 5 张不同收据
|
||
>
|
||
> **系统无法判断**"这是误操作的重复" vs "故意拆笔",所以**不做自动拦截**。
|
||
|
||
### 前端小程序的弱防护
|
||
|
||
> [!tip] 建议小程序层做防抖
|
||
> 业户连点 "下单" 按钮,小程序应该:
|
||
> - 第一次点击后**禁用按钮 2 秒**
|
||
> - 显示 loading,防止重复点
|
||
> - 但不做"15 秒内不允许同样订单"硬性限制(会误伤合理场景)
|
||
|
||
## 系统流程
|
||
|
||
```mermaid
|
||
sequenceDiagram
|
||
participant 业户
|
||
participant 小程序
|
||
participant 系统
|
||
|
||
业户->>小程序: 第 1 次点"下单"
|
||
小程序->>系统: POST /api/ad-hoc-events
|
||
Note over 系统: 网络卡顿,响应延迟
|
||
系统-->>小程序: ✅ 订单 1 创建
|
||
|
||
业户->>小程序: 第 2 次点"下单" (误以为第一次没成功)
|
||
小程序->>系统: POST /api/ad-hoc-events
|
||
系统-->>小程序: ✅ 订单 2 创建
|
||
|
||
Note over 业户: 业户切到"我的订单"
|
||
|
||
业户->>小程序: 看到 2 笔 Pending
|
||
业户->>业户: 困惑
|
||
|
||
Note over 业户: 推荐:取消 1 笔
|
||
|
||
业户->>小程序: 取消订单 2
|
||
小程序->>系统: DELETE /api/ad-hoc-events/{order-2}
|
||
系统->>系统: VoidAdHocEventAction
|
||
业户->>小程序: 支付订单 1
|
||
小程序->>系统: 完成订单 1
|
||
```
|
||
|
||
## 常见问题
|
||
|
||
> [!question] 系统能不能做"30 秒内不允许同一业户下同样订单"?
|
||
> 技术上可以加。但会误伤"故意拆笔"的场景(业户为家人买、要多张收据)。**当前选择不做硬限制**,靠 UI 弱防护(按钮防抖)+ 业务人员人工处理已经够。
|
||
|
||
> [!question] 一个业户最多能有多少笔 Pending 单?
|
||
> **无上限**。但**单超过 100 笔的业户**会触发反爬虫(虽然当前没装) —— 这种通常是 API 误用 / 攻击场景,与正常业户无关。
|
||
|
||
> [!question] 业户重复下单影响库存吗?
|
||
> 当前**系统不管物理库存**(IC 卡库存盒、装修证存货数)。库存管理是物业内部独立流程。重复下单只是**数据库里多了几笔记录**,实物没消耗。
|
||
|
||
> [!question] 业户付了 2 笔重复订单,2 笔都生成了收据,财务对账时会发现吗?
|
||
> 会发现 —— 月底对账时,**同一业户同一时段 2 笔同样金额** 会引起注意。建议:
|
||
> - 业务人员主动联系业户确认
|
||
> - 不论是否重复都按收据数对账
|
||
> - **物业可以发起退款**(走 [[场景-已收款作废]] 作废其中 1 笔)
|
||
|
||
## 相关概念
|
||
|
||
- [[概念-AdHocEvent状态机]] — 每笔订单独立的状态
|
||
- [[场景-取消-业户改主意主动撤单]] — 撤销多余订单
|
||
- [[场景-已收款作废]] — 已付款的多余订单怎么退
|
||
- [[场景-超时未付自动作废]] — 未付款的多余订单会自动废
|
||
|
||
## 异常分支
|
||
|
||
- 全部都付了 → [[场景-已收款作废]] 退多余的
|
||
- 业户坚持要全部 → 系统照单处理,留每笔独立收据
|