From 144dea0d578a9ecfed49a0a7511fcb6aaa05a1d2 Mon Sep 17 00:00:00 2001 From: Willie Date: Mon, 25 May 2026 13:49:34 +0800 Subject: [PATCH] vault backup: 2026-05-25 13:49:34 --- .obsidian/workspace.json | 3 + prop-acc/一次性收费/index.md | 27 +- prop-acc/一次性收费/场景-审计-月底现金对账.md | 253 ++++++++++++++++++ .../场景-异常-支付完成但实物发不出.md | 156 +++++++++++ prop-acc/一次性收费/场景-收据-重打丢失收据.md | 154 +++++++++++ 5 files changed, 580 insertions(+), 13 deletions(-) create mode 100644 prop-acc/一次性收费/场景-审计-月底现金对账.md create mode 100644 prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md create mode 100644 prop-acc/一次性收费/场景-收据-重打丢失收据.md 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 系统记录
CollectionOrder 表] --> D{对账} + B[B 收据汇总
Receipt 表] --> D + C[C 物理现金
抽屉点数] --> 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[正常完成
系统无异常] + B -->|不能| D{业户选哪条路?} + D -->|路线 A 等几天| E[系统无改动
物业内部登记] + D -->|路线 B 退钱| F[走 VoidAction
退款] + E --> G[几天后补发
系统无改动] + + 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卡]] — 原始收据生成 +- [[场景-已收款作废]] — 作废后的收据状态 + +## 异常分支 + +- 收据上信息错(房号串错) → 走 [[场景-已收款作废]] + 重做 +- 业户要的不是收据是发票 → 单独发票申请流程(超出本系统)