diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json
index 78bb244..412892f 100644
--- a/.obsidian/workspace.json
+++ b/.obsidian/workspace.json
@@ -186,6 +186,9 @@
   },
   "active": "b06ed69835363258",
   "lastOpenFiles": [
+    "prop-acc/一次性收费/场景-审计-月底现金对账.md",
+    "prop-acc/一次性收费/场景-收据-重打丢失收据.md",
+    "prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md",
     "prop-acc/一次性收费/场景-取消-录错金额作废重做.md",
     "prop-acc/一次性收费/场景-取消-业户改主意主动撤单.md",
     "prop-acc/一次性收费/场景-B流-小程序下单+支付宝.md",
diff --git a/prop-acc/一次性收费/index.md b/prop-acc/一次性收费/index.md
index 4686d99..b0bee55 100644
--- a/prop-acc/一次性收费/index.md
+++ b/prop-acc/一次性收费/index.md
@@ -40,33 +40,32 @@ code_version: 2026-05-22
 - [[概念-CollectionOrder与Receipt]] — 您买完后系统生成了什么
 - [[概念-AdHocEvent状态机]] — 一笔购买从下单到完成中间的几种状态
 
-## 场景手册(26 篇,5 篇已写)
+## 场景手册(26 篇,15 篇已写)
 
 ### 📦 A 流(线下前台,即收即付)
 
 - ✅ [[场景-A流-前台购买IC卡]]
-- ⏳ 场景-A流-前台购买装修出入证
-- ⏳ 场景-A流-前台购买泳票
-- ⏳ 场景-A流-前台办理充电桩电费充值
-- ⏳ 场景-A流-装修公司批量采购出入证
+- ✅ [[场景-A流-前台购买装修出入证]]
+- ✅ [[场景-A流-前台购买泳票]]
+- ✅ [[场景-A流-前台办理充电桩电费充值]]
+- ✅ [[场景-A流-装修公司批量采购出入证]]
 
 ### 📱 B 流(线上小程序)
 
 - ✅ [[场景-B流-小程序下单+微信支付]]
-- ⏳ 场景-B流-小程序下单+支付宝
-- ⏳ 场景-B流-小程序下单 30 分钟内完成支付
+- ✅ [[场景-B流-小程序下单+支付宝]]
 - ✅ [[场景-跨渠道补缴]] — 儿女线上下,老人前台付
 
 ### ❌ 取消 / 退款
 
-- ⏳ 场景-取消-业户改主意主动撤单
+- ✅ [[场景-取消-业户改主意主动撤单]]
 - ✅ [[场景-超时未付自动作废]]
 - ✅ [[场景-已收款作废]]
-- ⏳ 场景-取消-录错金额作废重做
+- ✅ [[场景-取消-录错金额作废重做]]
 
 ### ⚠️ 异常 / 故障
 
-- ⏳ 场景-异常-支付完成但实物发不出
+- ✅ [[场景-异常-支付完成但实物发不出]]
 - ⏳ 场景-异常-微信支付回调延迟
 - ⏳ 场景-异常-业户重复下单
 - ⏳ 场景-异常-支付分账失败
@@ -75,12 +74,12 @@ code_version: 2026-05-22
 ### 🧾 收据 / 凭证
 
 - ⏳ 场景-收据-现场打印纸质收据
-- ⏳ 场景-收据-重打丢失收据
+- ✅ [[场景-收据-重打丢失收据]]
 - ⏳ 场景-收据-小程序自助下载 PDF
 
 ### 📊 审计 / 对账
 
-- ⏳ 场景-审计-月底现金对账
+- ✅ [[场景-审计-月底现金对账]]
 - ⏳ 场景-审计-IC 卡库存与售出数对账
 - ⏳ 场景-审计-作废事由抽查
 
@@ -96,4 +95,6 @@ code_version: 2026-05-22
 ---
 
 > [!todo] 还没写的场景
-> ⏳ 标记的 21 个场景会在后续批次补完。如果您当前关心的场景未写,告诉我可以优先。
+> ⏳ 标记的 11 个场景会在后续批次补完。如果您当前关心的场景未写,告诉我可以优先。
+>
+> 已完成 15 / 26 = **58% 进度**。剩余主要在异常 / 凭证 / 审计 / 配置 类别。
diff --git a/prop-acc/一次性收费/场景-审计-月底现金对账.md b/prop-acc/一次性收费/场景-审计-月底现金对账.md
new file mode 100644
index 0000000..d298760
--- /dev/null
+++ b/prop-acc/一次性收费/场景-审计-月底现金对账.md
@@ -0,0 +1,253 @@
+---
+title: 场景 - 审计 - 月底现金对账
+tags:
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 审计对账
+audience:
+  - 业务人员
+status: stable
+last_reviewed: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:月底现金对账
+
+财务每月月底**核对前台收的现金**与**系统记录**是否一致。也叫"日结" / "月结"。
+
+> [!info] 给谁看
+> 主要给**财务人员**。业户不需要懂这部分。
+
+## 典型情境
+
+> [!example] 真实情境
+> 5 月 31 日,物业财务王姐准备月度结账。她要核对一次性收费 5 月份**前台收的现金总额**是否等于**收银抽屉的实际现金**。
+
+## 核心问题:三个数要对得上
+
+```mermaid
+graph LR
+    A[A 系统记录<br/>CollectionOrder 表] --> D{对账}
+    B[B 收据汇总<br/>Receipt 表] --> D
+    C[C 物理现金<br/>抽屉点数] --> D
+    D --> E[✅ 三方一致]
+    D --> F[❌ 不一致 → 追查]
+
+    classDef record fill:#dbeafe
+    classDef physical fill:#fef3c7
+    classDef result fill:#dcfce7
+    classDef fail fill:#fee2e2
+
+    class A,B record
+    class C physical
+    class E result
+    class F fail
+```
+
+如果三者一致,**通过**。如果不一致,需要逐笔排查。
+
+## 业务人员视角(财务)
+
+### 步骤 1:拉系统数据
+
+在 Filament 后台:
+
+```
+路径 1:CollectionOrders 列表
+├── 筛选:collection_completed_at 在 2026-05-01 ~ 2026-05-31
+├── 筛选:collection_type = AdHoc
+├── 筛选:payment_method = "现金"
+└── 求和:actual_amount
+
+得到 → A 系统记录(现金部分)
+```
+
+或直接走 SQL:
+
+```sql
+SELECT
+    COUNT(*) AS 订单数,
+    SUM(actual_amount) AS 现金总额
+FROM acc_collection_orders
+WHERE collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
+  AND collection_type = 'ad_hoc'
+  AND payment_method LIKE '%现金%'
+  AND status = 'completed';
+```
+
+### 步骤 2:对照 Receipt 表(验证内部一致)
+
+```sql
+SELECT
+    COUNT(r.id) AS 收据数,
+    SUM(r.amount) AS 收据总额
+FROM acc_receipts r
+JOIN acc_collection_orders co ON r.collection_order_id = co.id
+WHERE co.collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
+  AND co.collection_type = 'ad_hoc'
+  AND co.payment_method LIKE '%现金%'
+  AND r.status = 'issued';
+```
+
+**A 和 B 应该完全相等**(因为每笔订单生成一张收据,金额完全对应)。如果不等 → 数据库不一致问题,**严重**,要技术介入。
+
+### 步骤 3:点物理现金
+
+财务到前台:
+1. 打开收银抽屉
+2. 数所有钞票 + 硬币
+3. 减掉初始备用金(通常 ¥500-1000)
+4. 得到 C 现金部分
+
+### 步骤 4:对照 A vs C
+
+| 情况 | 含义 | 处理 |
+|---|---|---|
+| **A = C** | ✅ 完美对账 | 月底归档,提现到银行 |
+| **A > C**(系统多)| 现金少了 | 找差额:可能丢失 / 找零错 / 员工挪用 |
+| **A < C**(现金多)| 现金多了 | 找差额:可能少录单 / 找零少给 / 业户给多了没退 |
+
+差额 ≥ ¥10 都要逐笔排查。
+
+### 步骤 5:逐笔排查(差额情况)
+
+```
+1. 列出所有现金订单清单(订单号 + 金额 + 时间 + 业户)
+2. 对照前台手工日志(如果有)/ 监控录像
+3. 找到可疑的几笔:
+   ├── 录入时间晚了几小时(可能延后录入)
+   ├── 金额特殊(整数 / 没零头)
+   └── 业户名字可疑
+4. 联系业户 / 当事员工核实
+```
+
+## 多渠道场景
+
+实际场景不只有现金。一次性收费可能有 5+ 种支付渠道:
+
+| 渠道 | 对账依据 |
+|---|---|
+| 现金 | 收银抽屉点数 |
+| 微信支付 | 微信商户后台流水 |
+| 支付宝 | 支付宝商户后台流水 |
+| POS 刷卡 | 银行账单 |
+| 银行转账 | 对公账户流水 |
+
+**每种渠道独立对账**:
+
+```sql
+SELECT
+    payment_method,
+    COUNT(*) AS 订单数,
+    SUM(actual_amount) AS 总额
+FROM acc_collection_orders
+WHERE collection_completed_at BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
+  AND collection_type = 'ad_hoc'
+  AND status = 'completed'
+GROUP BY payment_method;
+```
+
+输出例:
+```
+现金       125 笔  ¥3,820
+微信       42 笔   ¥1,260
+支付宝     18 笔   ¥540
+POS刷卡    8 笔   ¥280
+─────────────────────────
+合计       193 笔  ¥5,900
+```
+
+财务对照每个渠道的外部对账单。
+
+## 系统流程
+
+```mermaid
+sequenceDiagram
+    participant 财务
+    participant Filament/DB
+    participant 前台
+    participant 微信商户
+    participant 支付宝商户
+    participant 银行
+
+    财务->>Filament/DB: 月度筛选 + 求和(按支付方式)
+    Filament/DB-->>财务: 各渠道金额
+
+    财务->>前台: 点物理现金
+    前台-->>财务: 抽屉总额
+
+    财务->>微信商户: 查流水
+    微信商户-->>财务: 微信总收款
+
+    财务->>支付宝商户: 查流水
+    支付宝商户-->>财务: 支付宝总收款
+
+    财务->>银行: 查对公账单
+    银行-->>财务: 转账 + POS 流水
+
+    财务->>财务: 逐渠道对账
+    财务->>财务: 不一致逐笔排查
+```
+
+## 常见问题
+
+> [!question] 系统多了 ¥30,可能是什么原因?
+> - 业户付完拿走货,职员忘了给找零(¥50 收 ¥20 商品,找零给少了)
+> - 当天工作交接,前班的现金没全部移交
+> - 销售退款没退,系统已记作废但前台没退现金给业户
+
+> [!question] 系统少了 ¥50,可能是什么原因?
+> - 漏录单(收了钱忘录系统)
+> - 找零给多了
+> - 业务人员临时挪用(严重,要核查)
+
+> [!question] 每次差几块钱(< ¥10)能忽略吗?
+> **不建议**。差小钱不一定是 bug,但**长期累积** + **不追究** = 内部审计黑洞。建议:
+> - 差 < ¥10 也记录追查
+> - 差 ≥ ¥100 当周必查清
+
+> [!question] 业务人员能修改历史订单的支付方式吗?
+> **不能**(订单 Completed 后不可编辑)。如果发现某笔订单的 payment_method 录错(比如填了"现金"实际是"微信"),走 [[场景-已收款作废]] + 重新录入。
+
+> [!question] 月底前的几小时高峰怎么处理?
+> 5 月 31 日 23:59 录入的订单 vs 6 月 1 日 00:01 录入,在 SQL 里**严格按时间戳归属**。建议月底前后 30 分钟**减少操作**,避免跨月归类争议。
+
+## 月度报表的标准格式(建议)
+
+```
+=== 一次性收费 2026 年 5 月对账报告 ===
+
+【系统数据】
+现金:    ¥3,820  (125 笔)
+微信:    ¥1,260  (42 笔)
+支付宝:  ¥540    (18 笔)
+POS刷卡: ¥280    (8 笔)
+─────────────────────
+合计:    ¥5,900  (193 笔)
+
+【外部数据】
+收银抽屉点数:        ¥3,820  ✅
+微信商户后台:        ¥1,260  ✅
+支付宝商户后台:      ¥540    ✅
+银行 POS 入账:       ¥280    ✅
+
+【差额追查】
+无
+
+【作废订单(对照)】
+本月作废:   3 笔  ¥150
+其中 Pending 作废:  2 笔(超时/撤单)
+其中 Completed 作废: 1 笔(已退款 ¥30,银行原路)
+
+【签字】
+财务:______ 物业经理:______ 日期:______
+```
+
+## 相关概念
+
+- [[概念-CollectionOrder与Receipt]] — 三件套数据是对账的核心
+- [[场景-A流-前台购买IC卡]] — 现金交易的入口
+- [[场景-B流-小程序下单+微信支付]] — 微信渠道数据来源
+- [[场景-B流-小程序下单+支付宝]] — 支付宝渠道数据来源
+- [[场景-已收款作废]] — 作废订单对对账的影响
diff --git a/prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md b/prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md
new file mode 100644
index 0000000..dad98da
--- /dev/null
+++ b/prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md
@@ -0,0 +1,156 @@
+---
+title: 场景 - 异常 - 支付完成但实物发不出
+tags:
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 异常故障
+audience:
+  - 业户
+  - 业务人员
+status: stable
+last_reviewed: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:支付完成但实物发不出
+
+业户**钱已经付了**,但物业**无法当场交付实物**(IC 卡缺货、装修证用完、泳票打印机坏)。
+
+## 典型情境
+
+> [!example] 情境 1:IC 卡缺货
+> 业户付了 ¥30 买 IC 卡,职员去拿卡发现工本卡盒空了(下一批要 3 天后才到)。
+>
+> → 业户已经付钱了,卡当场拿不到。
+
+> [!example] 情境 2:打印机坏
+> 业户付完游泳票钱,前台打印机卡纸,纸质票出不来。
+>
+> → 业户已经付钱了,纸质票当场拿不到。
+
+> [!example] 情境 3:装修证人脸照片采集设备故障
+> 业户付完装修证钱,采集工人人脸照片的设备故障。
+>
+> → 业户已经付钱了,出入证制作不了。
+
+## 业户视角
+
+### 您能选两条路
+
+> [!tip] 路线 A:等
+> 物业承诺**X 天内补发**,您下次来或物业送到您家。
+> - 钱不退,订单状态依然 Completed
+> - 物业**口头/微信承诺** 但不在系统里改任何东西
+
+> [!tip] 路线 B:退
+> 您当场说"算了,我退钱不要了"。
+> - 走 [[场景-已收款作废]] 流程
+> - 钱退给您
+> - 订单作废
+
+**业户体验差异**:
+- 路线 A:不退钱,但要相信物业 "几天后补"
+- 路线 B:钱拿回来,自己改天再来或转去别处买
+
+## 业务人员视角
+
+### 推荐处理流程
+
+```
+1. 第一时间承认问题,**当面致歉**
+   "不好意思阿姨,这批 IC 卡正好用完了,新货要 3 天后到。"
+
+2. 给业户两个选项:
+   ├── 路线 A:登记 + 承诺(信任成本低,业户感觉好)
+   └── 路线 B:立刻退款(钱安全,但流程多)
+
+3. 业户选 A:
+   ├── 在内部"待补发"清单登记:
+   │   - 订单号 CO-XXX
+   │   - 业户名 + 电话
+   │   - 承诺日期
+   ├── 系统里订单**不需要任何改动**
+   ├── 几天后货到:
+   │   - 通知业户来取
+   │   - 业户来取,核对订单号 + 给货
+   │   - **系统里依然不需要任何改动**(订单已 Completed)
+
+4. 业户选 B:
+   ├── 走 [[场景-已收款作废]] 作废订单
+   ├── 退还现金 / 微信退款
+   └── 业户离开
+```
+
+### "待补发清单"建议
+
+> [!warning] 系统外的事但很重要
+> 系统不管"业户付了钱但还没拿货"。物业需要**自己维护一份补发清单**(Excel / 小程序待办 / 物业群通知都行)。
+>
+> 关键字段:
+> - 订单号(便于反查)
+> - 业户姓名 + 电话(便于联系)
+> - 承诺补发时间
+> - 实际补发时间(已补发后填)
+> - 责任人(谁负责跟进)
+
+### 路线 A 的财务一致性
+
+> [!success] 钱货分离对账上没问题
+> 业户付了钱、订单 Completed → 系统记录已收款。
+> 业户拿货发生在几天后 → 不影响财务记录(系统只管"收钱"这一步)。
+>
+> 月底对账 = 看 CollectionOrder 总额。物理库存盘点是另一个独立流程(超出本系统范围)。
+
+## 系统流程对比
+
+```mermaid
+graph TD
+    A[业户付款] --> B{物业能当场发货?}
+    B -->|能| C[正常完成<br/>系统无异常]
+    B -->|不能| D{业户选哪条路?}
+    D -->|路线 A 等几天| E[系统无改动<br/>物业内部登记]
+    D -->|路线 B 退钱| F[走 VoidAction<br/>退款]
+    E --> G[几天后补发<br/>系统无改动]
+
+    classDef happy fill:#dcfce7
+    classDef exception fill:#fef3c7
+    classDef refund fill:#fee2e2
+
+    class A,C happy
+    class B,D,E,G exception
+    class F refund
+```
+
+## 常见问题
+
+> [!question] 业户选了路线 A,几天后还没拿到货怎么办?
+> 物业内部问题。建议:
+> - 设置闹钟提醒(承诺日 ± 1 天)
+> - 主动联系业户 "您的 IC 卡到了,什么时候来取?"
+> - 业户不耐烦了 → 走路线 B 退款
+
+> [!question] 业户选了路线 A,但后来联系不上了怎么办?
+> 经过 30 天还联系不上业户:
+> - 留个长期备忘录
+> - 系统里订单依然 Completed(财务上"已收款已交付"的法律事实)
+> - 实物 IC 卡放在物业保管,业户随时可来取
+
+> [!question] 业务人员能在系统里标记"已收款未发货"吗?
+> 当前**没有这个状态**。如果需要,可以:
+> - 临时方案:在订单 `remark` 字段写"待补发,缺 IC 卡"
+> - 长期方案:加一个 `delivery_status` 字段(待补发/已补发),挂 TODO 等需求明确
+
+> [!question] 路线 B 退款时,微信支付几天才退到账,业户在意吗?
+> 部分业户会在意。可以**当场垫现金给业户**(¥30 这种小额完全可以),系统里依然走微信退款 —— 业户拿了现金不再焦虑,几天后微信钱也到账了(物业自己消化)。
+
+## 相关概念
+
+- [[概念-CollectionOrder与Receipt]] — 收款记录与物理交付是两件事
+- [[场景-已收款作废]] — 路线 B 的基础流程
+- [[场景-A流-前台购买IC卡]] — 正向交付流程
+
+## 异常分支(更进一步的异常)
+
+- 业户付完想马上退 → 直接走 [[场景-已收款作废]]
+- 路线 A 等了一个月还没货 → 走 [[场景-已收款作废]] 退款
diff --git a/prop-acc/一次性收费/场景-收据-重打丢失收据.md b/prop-acc/一次性收费/场景-收据-重打丢失收据.md
new file mode 100644
index 0000000..7a74089
--- /dev/null
+++ b/prop-acc/一次性收费/场景-收据-重打丢失收据.md
@@ -0,0 +1,154 @@
+---
+title: 场景 - 收据 - 重打丢失收据
+tags:
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 收据凭证
+audience:
+  - 业户
+  - 业务人员
+status: stable
+last_reviewed: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:重打丢失收据
+
+业户**事后说收据丢了**,要求物业**补打或重发**。
+
+> [!success] 系统已支持
+> 后端已有 PDF 下载路由(`packages/prop-acc/routes/tenant.php`)。本场景描述前台 + 业户的两种重打路径。
+
+## 典型情境
+
+> [!example] 真实情境
+> 张阿姨 3 个月前买了张 IC 卡 ¥30,需要找物业开发票报销公司。当时拿的是纸质收据,现在找不到了。来物业问:"能不能再打一份给我?"
+
+## 业户视角
+
+### 路径 A:业户自己在小程序下载
+
+> [!tip] 推荐这个最方便
+> 业户**自助操作**,不用麻烦前台。
+
+1. 打开小程序 → 我家 → 我的订单
+2. 在"已完成"列表找到那笔订单
+3. 点订单详情 → 右上角 [下载收据]
+4. PDF 自动下载,微信里可保存/分享
+
+### 路径 B:让前台职员帮忙
+
+业户不会用小程序时:
+
+1. 到物业前台
+2. "我 3 月份买的 IC 卡,收据丢了,能不能再给我一份?"
+3. 报房号 / 大致日期 / 订单号(如果记得)
+4. 职员搜系统、重新打印 / 发微信
+
+## 业务人员视角
+
+### 操作步骤
+
+```
+1. 打开 Filament 后台 → 一次性收费
+2. 搜业户(按房号、日期、订单号)
+3. 找到目标订单,点击进入详情
+4. 找到关联的 Receipt
+5. 点"下载 PDF"或"打印"按钮
+6. 把 PDF 发到业户微信,或纸质打印当场给
+```
+
+### 重要:**不要新建一笔订单**
+
+> [!warning] 关键
+> 不要因为业户说"收据丢了"就**重新录一笔订单** —— 这会变成系统里**多了一笔不存在的交易**,财务多收一份钱。
+>
+> **正确做法**:用原订单**重新生成一份 PDF**。原 Receipt 不变(状态仍是 Issued),只是文档**被重新渲染**。
+
+### 收据号会变吗?
+
+**不会**。重打的收据**收据号、金额、日期** 全部和原始收据一样。这是"重打",不是"新开"。
+
+## 系统流程
+
+```mermaid
+sequenceDiagram
+    participant 业户
+    participant 前台/小程序
+    participant 系统
+    participant PDF生成器
+
+    业户->>前台/小程序: 我要补一份收据
+    前台/小程序->>系统: GET /receipts/{id}/pdf
+    系统->>系统: 找到 Receipt 数据
+    系统->>PDF生成器: 渲染收据 PDF
+    PDF生成器-->>系统: PDF 二进制流
+    系统-->>前台/小程序: 返回 PDF
+    前台/小程序-->>业户: 下载/打印
+```
+
+> [!info] 系统里发生了什么
+> - Receipt 表**没有任何写操作**(没改也没新增)
+> - 只是用现存数据**重新生成 PDF**
+> - 重打多少次都不会影响财务记录
+
+## 几种特殊情况
+
+### 业户的订单已被作废
+
+如果业户找到的订单是 **Voided 状态**(走过作废流程):
+
+```
+Filament 后台显示:
+├── Receipt 状态:Voided
+├── PDF 上会有水印 / 字样:"已作废"
+└── 业户拿这张是"作废凭证",不是有效收据
+```
+
+> [!warning] 业户可能会问"作废凭证能报销吗?"
+> 不能(财务上这笔交易不存在了)。要重新报销,需要重新交易 + 拿新收据。
+
+### 业户记不清是什么时候买的
+
+```
+1. 让业户回忆大致月份 / 商品类型
+2. Filament 后台用业户 ID + 商品类型筛选
+3. 列出该业户**所有历史订单**让业户认领
+```
+
+### 业户要发票而不是收据
+
+> [!info] 收据 ≠ 发票
+> - **收据**:系统自动生成,证明"我付了钱"
+> - **发票**:税务凭证,需要走**开票流程**(国税局接口)
+>
+> 一次性收费当前**只生成收据**,不开发票。业户要发票需要走单独的发票申请流程(超出本系统范围)。
+
+## 常见问题
+
+> [!question] 业户说"前台给的收据上日期是错的"?
+> 收据日期 = 订单的 `collection_completed_at`(收款完成时间)。如果业户付款时间和系统时间不一致(罕见),需要技术排查时间同步问题。**业务上可以加备注说明**。
+
+> [!question] PDF 能不能加密 / 防伪?
+> 当前未实现。如果有需要(防业户 PS),可以在 PDF 加二维码 + 收据号哈希,业户扫码到物业小程序验真。**等业务方反馈再做**。
+
+> [!question] 重打的次数有限制吗?
+> 没限制。每次重打都从数据库实时生成,**不影响其他数据**。
+
+> [!question] 业户能查到所有历史收据吗?
+> 在小程序"我的订单"里能看到**所有自己的订单**(无时间限制)。每笔订单都能重新下载收据。
+
+> [!question] 业务人员能帮业户**删掉**一笔订单 / 收据吗?
+> **不能**。Delete 入口在前台已经移除(详见 [[概念-AdHocEvent状态机]])。如果业户希望"这笔订单不存在",走 [[场景-已收款作废]] 即可 —— Receipt 状态翻 Voided 但记录仍在,方便审计。
+
+## 相关概念
+
+- [[概念-CollectionOrder与Receipt]] — Receipt 是只生成不可改的凭证
+- [[场景-A流-前台购买IC卡]] — 原始收据生成
+- [[场景-已收款作废]] — 作废后的收据状态
+
+## 异常分支
+
+- 收据上信息错(房号串错) → 走 [[场景-已收款作废]] + 重做
+- 业户要的不是收据是发票 → 单独发票申请流程(超出本系统)