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.3 KiB
5.3 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] 真实情境 周末下午泳池前台高峰期,职员小赵给陈太太录入泳票订单:
- 应该录:¥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 步:作废 + 重做 |
| 资金 | 全额退给业户 | 退原金额 + 重收正确金额 |
| 业户体验 | 一切照常,只是没了 | 短暂困惑,但快速纠正 |
系统流程
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] 高峰期录单忙容易错,有什么预防方法?
- 金额自动填:在 Filament 后台,选 RatePlan 后金额自动算出 =
unit_price × quantity,不要手改- 复核机制:提交前 Modal 弹"确认 ¥XXX?" 让业务人员肉眼复核
- 拆分付款步骤:先收钱 + 数现金,再录入(确保实收金额对得上)
系统设计上的预防
[!info] Filament Modal 已有的保护 当前
CreateAdHocEvent表单:
- 选 RatePlan 后单价 + 总金额自动填(避免手输错)
- 提交前 Modal 显示金额(让业务人员肉眼复核)
- 提交后给 success toast 通知(业务人员能即时看到结果)
如果还是错了 —— 通常是高峰期注意力分散,需要业务培训提醒。
相关概念
- 概念-AdHocEvent状态机 — Completed → Voided
- 场景-已收款作废 — 基础作废流程
- 场景-A流-前台购买IC卡 — 录入的正向流程