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>
5.7 KiB
title, aliases, tags, audience, status, last_review, code_version
| title | aliases | tags | audience | status | last_review | code_version | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · 场景 - 异常 - 业户重复下单 |
|
|
|
已发布 | 2026-05-25 | 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 秒内不允许同样订单"硬性限制(会误伤合理场景)
系统流程
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状态机 — 每笔订单独立的状态
- 场景-取消-业户改主意主动撤单 — 撤销多余订单
- 场景-已收款作废 — 已付款的多余订单怎么退
- 场景-超时未付自动作废 — 未付款的多余订单会自动废
异常分支
- 全部都付了 → 场景-已收款作废 退多余的
- 业户坚持要全部 → 系统照单处理,留每笔独立收据