vault backup: 2026-05-25 13:49:34
This commit is contained in:
Willie
@@ -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% 进度**。剩余主要在异常 / 凭证 / 审计 / 配置 类别。
|
||||
|
||||
253
prop-acc/一次性收费/场景-审计-月底现金对账.md
Normal file
253
prop-acc/一次性收费/场景-审计-月底现金对账.md
Normal file
@@ -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流-小程序下单+支付宝]] — 支付宝渠道数据来源
|
||||
- [[场景-已收款作废]] — 作废订单对对账的影响
|
||||
156
prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md
Normal file
156
prop-acc/一次性收费/场景-异常-支付完成但实物发不出.md
Normal file
@@ -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 等了一个月还没货 → 走 [[场景-已收款作废]] 退款
|
||||
154
prop-acc/一次性收费/场景-收据-重打丢失收据.md
Normal file
154
prop-acc/一次性收费/场景-收据-重打丢失收据.md
Normal file
@@ -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卡]] — 原始收据生成
|
||||
- [[场景-已收款作废]] — 作废后的收据状态
|
||||
|
||||
## 异常分支
|
||||
|
||||
- 收据上信息错(房号串错) → 走 [[场景-已收款作废]] + 重做
|
||||
- 业户要的不是收据是发票 → 单独发票申请流程(超出本系统)
|
||||
Reference in New Issue
Block a user