vault backup: 2026-05-25 14:04:39

2026-05-25 14:04:39 +08:00
parent 0e53ade17c
commit 484d2e2e50
5 changed files with 682 additions and 17 deletions
--- a/.obsidian/workspace.json
+++ b/.obsidian/workspace.json
@@ -186,6 +186,9 @@
  },
  "active": "b06ed69835363258",
  "lastOpenFiles": [
+    "prop-acc/一次性收费/场景-配置-下架收费项目并处理Pending单.md",
+    "prop-acc/一次性收费/场景-配置-新增收费项目.md",
+    "prop-acc/一次性收费/场景-审计-作废事由抽查.md",
    "prop-acc/一次性收费/场景-审计-IC卡库存与售出数对账.md",
    "prop-acc/一次性收费/场景-收据-小程序自助下载PDF.md",
    "prop-acc/一次性收费/场景-收据-现场打印纸质收据.md",
@@ -209,9 +212,6 @@
    "prop-acc/一次性收费/场景-已收款作废.md",
    "prop-acc/一次性收费/场景-超时未付自动作废.md",
    "prop-acc/一次性收费/场景-跨渠道补缴.md",
-    "prop-acc/一次性收费/概念-CollectionOrder与Receipt.md",
-    "prop-acc/一次性收费/概念-A流与B流.md",
-    "prop-acc/index.md",
    "prop-acc/一次性收费",
    "prop-acc",
    "Untitled"
--- a/prop-acc/一次性收费/index.md
+++ b/prop-acc/一次性收费/index.md
@@ -40,7 +40,7 @@ code_version: 2026-05-22
 - [[概念-CollectionOrder与Receipt]] — 您买完后系统生成了什么
 - [[概念-AdHocEvent状态机]] — 一笔购买从下单到完成中间的几种状态

-## 场景手册(26 篇,15 篇已写)
+## 场景手册(26 篇,**全部完成 ✅**)

 ### 📦 A 流(线下前台,即收即付)

@@ -66,27 +66,27 @@ code_version: 2026-05-22
 ### ⚠️ 异常 / 故障

 - ✅ [[场景-异常-支付完成但实物发不出]]
- ⏳ 场景-异常-微信支付回调延迟
- ⏳ 场景-异常-业户重复下单
- ⏳ 场景-异常-支付分账失败
- ⏳ 场景-异常-同业户跨社区 Pending 单
+- ✅ [[场景-异常-微信支付回调延迟]]
+- ✅ [[场景-异常-业户重复下单]]
+- ✅ [[场景-异常-支付分账失败]]
+- ✅ [[场景-异常-同业户跨社区Pending单]]

 ### 🧾 收据 / 凭证

- ⏳ 场景-收据-现场打印纸质收据
+- ✅ [[场景-收据-现场打印纸质收据]]
 - ✅ [[场景-收据-重打丢失收据]]
- ⏳ 场景-收据-小程序自助下载 PDF
+- ✅ [[场景-收据-小程序自助下载PDF]]

 ### 📊 审计 / 对账

 - ✅ [[场景-审计-月底现金对账]]
- ⏳ 场景-审计-IC 卡库存与售出数对账
- ⏳ 场景-审计-作废事由抽查
+- ✅ [[场景-审计-IC卡库存与售出数对账]]
+- ✅ [[场景-审计-作废事由抽查]]

 ### 🔧 配置 / 准备

- ⏳ 场景-配置-新增收费项目
- ⏳ 场景-配置-下架收费项目并处理 Pending 单
+- ✅ [[场景-配置-新增收费项目]]
+- ✅ [[场景-配置-下架收费项目并处理Pending单]]

 ## 相关代码

@@ -94,7 +94,9 @@ code_version: 2026-05-22

 ---

-> [!todo] 还没写的场景
-> ⏳ 标记的 11 个场景会在后续批次补完。如果您当前关心的场景未写,告诉我可以优先。
+> [!success] 全部 26 场景 + 3 概念 + 1 模块总览 = **30 篇完成**
 >
-> 已完成 15 / 26 = **58% 进度**。剩余主要在异常 / 凭证 / 审计 / 配置 类别。
+> 写作日期:2026-05-25 一次性产出
+> 对应代码版本:2026-05-22(详见 `packages/prop-acc/issue.md` Q1/Q2)
+>
+> 如果发现遗漏的场景或需要补充的细节,告诉我,可以单独补充新文档。
--- a/prop-acc/一次性收费/场景-审计-作废事由抽查.md
+++ b/prop-acc/一次性收费/场景-审计-作废事由抽查.md
@@ -0,0 +1,231 @@
+---
+title: 场景 - 审计 - 作废事由抽查
+tags:
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 审计对账
+audience:
+  - 业务人员
+status: stable
+last_reviewed: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:作废事由抽查
+
+物业**财务 / 内审 / 上级** 定期抽查作废订单,验证**作废原因记录是否完整、合理**。防止业务人员**滥用作废功能**(挪用现金、做账漏洞)。
+
+> [!info] 为什么这个对账很重要?
+> 一次性收费的 [[场景-已收款作废\|已收款作废]] 涉及**资金退还**。如果业务人员说"作废了"但没真退,**或者作废用来掩盖之前的挪用**,系统层面看不出来 —— 必须靠**事由记录抽查**反向追查。
+
+## 典型情境
+
+> [!example] 真实情境
+> 6 月份内审来检查 5 月份记录:
+> - 5 月共有 8 笔已收款作废订单
+> - 总作废金额 ¥1,520
+>
+> 内审要求**逐笔出示作废原因 + 资金处理凭证**。
+
+## 业务人员视角(被抽查方)
+
+### 内审会问什么
+
+每笔作废订单,内审会问:
+
+| 问题 | 你要拿出的证据 |
+|---|---|
+| 为什么作废? | meta.voided_reason 完整记录 |
+| 谁审批的? | meta.voided_by 是 supervisor 级别员工 |
+| 资金怎么处理的? | 现金退还签字 / 微信退款记录 / POS 撤销凭证 |
+| 业户确认收到退款了吗? | 业户签字 / 微信沟通截图 |
+| 是否后续重新下单? | 如果是,关联新订单号 |
+
+### 准备资料
+
+```
+1. 拉出 5 月份所有作废订单
+2. 按订单号逐一整理:
+   ├── 截图 Filament 后台订单详情
+   ├── 截图 meta.voided_* 字段(JSON 格式)
+   ├── 附微信退款记录 / 现金签收单
+   └── 附业户沟通截图(如果有)
+3. 装订成册交内审
+```
+
+## 查作废订单的 SQL
+
+```sql
+SELECT
+    ahe.id,
+    ahe.created_at AS 创建时间,
+    ahe.meta->>'voided_at' AS 作废时间,
+    ahe.meta->>'voided_reason' AS 作废原因,
+    ahe.meta->>'voided_by' AS 操作员ID,
+    u.name AS 操作员姓名,
+    ahe.amount AS 金额,
+    rp.name AS 项目,
+    cup.user_id AS 业户ID
+FROM acc_ad_hoc_events ahe
+JOIN acc_rate_plans rp ON ahe.rate_plan_id = rp.id
+LEFT JOIN community_community_user_profiles cup ON ahe.community_user_profile_id = cup.id
+LEFT JOIN users u ON CAST(ahe.meta->>'voided_by' AS INTEGER) = u.id
+WHERE ahe.status = 'voided'
+  AND CAST(ahe.meta->>'voided_at' AS TIMESTAMP) BETWEEN '2026-05-01' AND '2026-05-31 23:59:59'
+ORDER BY ahe.meta->>'voided_at' DESC;
+```
+
+## 健康的作废 vs 可疑的作废
+
+> [!success] 健康的作废(对账通过)
+
+```
+voided_reason: "录入金额错误 ¥400 应为 ¥40。已通过微信原路退款 ¥400,
+              业户已确认收到。重新下一笔正确订单 CO-XXX。
+              处理人:王XX(夜班柜员)"
+voided_at: 2026-05-15 19:23:45
+voided_by: 5 (王XX)
+
+✅ 内审评价:
+- 原因清晰
+- 资金处理写明(微信原路退款)
+- 业户确认
+- 关联新订单(可追溯)
+```
+
+> [!failure] 可疑的作废(内审会盯)
+
+```
+voided_reason: "作废"
+voided_at: 2026-05-20 17:55:30
+voided_by: 5
+
+❌ 内审评价:
+- 原因仅一个字,无解释
+- 没说资金处理
+- 没说业户是否确认
+- 没说后续是否重做
+- **强烈建议核查:是否有挪用现金嫌疑**
+```
+
+## 抽查指标
+
+业务人员的"作废率"是一个重要指标:
+
+```
+作废率 = 作废订单数 / 总订单数
+
+健康水平:< 3%
+警戒水平:3% ~ 5%
+严重水平:> 5%(必须人工核查每笔)
+```
+
+某员工的作废率**显著高于团队均值** → 可能是工作能力差(经常录错)或可疑(挪用)。
+
+### 按员工统计
+
+```sql
+SELECT
+    u.name AS 员工,
+    COUNT(*) FILTER (WHERE ahe.status = 'voided') AS 作废笔数,
+    COUNT(*) FILTER (WHERE ahe.status = 'completed') AS 完成笔数,
+    ROUND(100.0 * COUNT(*) FILTER (WHERE ahe.status = 'voided')
+        / NULLIF(COUNT(*), 0), 2) AS 作废率
+FROM acc_ad_hoc_events ahe
+LEFT JOIN users u ON CAST(ahe.meta->>'voided_by' AS INTEGER) = u.id
+WHERE ahe.occurred_at >= '2026-05-01'
+GROUP BY u.id, u.name
+ORDER BY 作废率 DESC;
+```
+
+输出例:
+```
+员工     | 作废笔数 | 完成笔数 | 作废率
+李XX     |    1    |   320    |  0.31% ✅
+张XX     |    3    |   280    |  1.07% ✅
+王XX     |   12    |    95    | 12.63% ❌ 必查
+```
+
+## 系统流程
+
+```mermaid
+sequenceDiagram
+    participant 内审
+    participant 业务人员
+    participant Filament/DB
+    participant 业务流程
+
+    Note over 内审: 季度审计
+
+    内审->>Filament/DB: 拉作废订单 + meta
+    Filament/DB-->>内审: 8 笔 ¥1520
+
+    内审->>业务人员: 出示原因 + 资金凭证
+    业务人员->>业务人员: 整理资料(微信截图、签收单)
+    业务人员-->>内审: 交付
+
+    内审->>内审: 逐笔检查
+    alt 原因清晰 + 资金凭证完整
+        内审-->>业务人员: ✅ 通过
+    else 原因模糊 / 凭证不全
+        内审-->>业务人员: ❌ 要求补充说明
+        业务人员->>业务流程: 联系业户补凭证
+        业务人员-->>内审: 补充材料
+    end
+
+    Note over 内审: 整理审计报告 → 上报集团
+```
+
+## 防止作废滥用的设计
+
+> [!info] 系统设计上的几道防线
+>
+> 1. **作废必须填原因** —— Filament UI 强制必填 textarea
+> 2. **记录 voided_by** —— 留谁的责任
+> 3. **记录 voided_at** —— 留时间戳
+> 4. **不能修改 voided_reason** —— 写入后只读
+> 5. **作废后状态不可恢复** —— 不能事后"撤销作废"
+>
+> 这五道防线让作废操作**完全留痕**,事后审计有据可查。
+
+## 常见问题
+
+> [!question] 业务人员作废后能不能"修改作废原因"?
+> **不能**。meta 字段写入后不可修改。如果原因写错了,需要技术介入(直接改数据库)且留**修改记录**。
+
+> [!question] 内审能否要求**所有作废订单**逐笔检查?
+> 可以。健康的物业**所有作废都应该有可解释的原因**。如果某月作废多了一倍以上,**全数检查**是必要的。
+
+> [!question] 业户主动撤单(Pending 单)也要审吗?
+> 不需要。Pending 单作废**没有资金涉及**(业户没付款),审计风险低。但 voided_reason 也应该清楚(便于业户体验问题排查)。
+
+> [!question] 系统能不能自动报警"高作废率员工"?
+> 当前**没有自动报警**。可以挂 TODO:
+> - 定时 job(每日 / 每周)算每个员工作废率
+> - 超阈值的发邮件 / 微信通知管理员
+> - 等业务方明确反馈再做
+
+> [!question] 已经处罚过的员工,历史作废记录还能看到吗?
+> **能**。作废记录**永久保留**,即使员工离职、被开除,他名下的所有操作都在数据库里有据可查。
+
+## 与其他对账的对照
+
+| 对账类型 | 对账对象 | 重点 |
+|---|---|---|
+| [[场景-审计-月底现金对账\|现金对账]] | 系统订单 vs 物理现金 | 钱在不在 |
+| [[场景-审计-IC卡库存与售出数对账\|库存对账]] | 系统订单 vs 物理库存 | 货在不在 |
+| **作废事由抽查(本场景)** | 作废订单的 meta 字段 | **原因合不合理 + 责任清不清楚** |
+
+三种对账**完整覆盖** "钱、货、人" 三个维度。健康物业每月都做。
+
+## 相关概念
+
+- [[概念-AdHocEvent状态机]] — Voided 状态的不可逆性
+- [[场景-已收款作废]] — 作废操作的入口
+- [[场景-取消-录错金额作废重做]] — 健康的作废示例
+
+## 异常分支
+
+- 内审发现重大问题 → 报集团 / 公安(挪用)
+- 业务人员书写不规范 → 加强培训 + 重写 meta 模板
--- a/prop-acc/一次性收费/场景-配置-下架收费项目并处理Pending单.md
+++ b/prop-acc/一次性收费/场景-配置-下架收费项目并处理Pending单.md
@@ -0,0 +1,232 @@
+---
+title: 场景 - 配置 - 下架收费项目并处理 Pending 单
+tags:
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 配置准备
+audience:
+  - 业务人员
+status: stable
+last_reviewed: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:下架收费项目并处理 Pending 单
+
+物业要**停止销售某个收费项目**(夏季泳池关闭、活动结束、产品退市)。系统配置可以一键禁用,但**已有的 Pending 单要单独处理**,否则业户会困惑。
+
+## 典型情境
+
+> [!example] 真实情境
+> 9 月初,夏季泳池关闭,"亲子游泳课程 - 单次 ¥80" 不再销售。
+>
+> - 系统里**已有 3 笔 Pending 订单**(业户在 8 月末下了单但还没付款)
+> - 业户上小程序点开会看到"该项目已下架,请联系物业"
+
+## 业务人员视角
+
+### 完整下架流程
+
+```
+1. 禁用 RatePlan(停止上架)
+2. 处理已有 Pending 单(主动联系业户)
+3. 不动已 Completed 订单(历史交易完整保留)
+4. 通知客户群体(运营公告)
+```
+
+### 步骤 1:禁用 RatePlan
+
+```
+Filament 后台 → 收费配置 → 收费项目
+├── 找到"亲子游泳课程 - 单次"
+├── 编辑 → is_active 改为 ❌ false
+└── 保存
+```
+
+**效果**:
+- 小程序**不再展示**这个项目(已下单的不受影响)
+- Filament 后台前台**录新单时找不到这个项目**(只显示活跃的 RatePlan)
+- 历史订单**完全不变**(Completed / Voided / Pending 全保留)
+
+### 步骤 2:处理已有 Pending 单
+
+```sql
+-- 找到所有相关 Pending 单
+SELECT
+    ahe.id,
+    ahe.community_user_profile_id,
+    ahe.amount,
+    cup.user_id,
+    u.name AS 业户名,
+    u.phone
+FROM acc_ad_hoc_events ahe
+JOIN community_community_user_profiles cup ON ahe.community_user_profile_id = cup.id
+JOIN users u ON cup.user_id = u.id
+WHERE ahe.rate_plan_id = (SELECT id FROM acc_rate_plans WHERE name = '亲子游泳课程 - 单次')
+  AND ahe.status = 'pending';
+```
+
+输出例:
+```
+id   业户名   手机号        金额    创建时间
+105  李XX    138-XXXX-1234  80    2026-08-28
+108  王XX    138-XXXX-5678  80    2026-08-29
+112  陈XX    138-XXXX-9012  80    2026-08-30
+```
+
+### 步骤 3:逐一联系业户
+
+```
+对每笔 Pending 单:
+1. 微信 / 电话联系业户
+2. 告知"亲子游泳课程已下架,您还未付款的订单 CO-XXX 怎么处理"
+3. 业户选择:
+   ├── 不要了 → 立即取消订单([[场景-取消-业户改主意主动撤单]])
+   └── 还想要 → 婉拒(项目已下架),业户撤单
+4. Filament 后台 → 走 VoidAction 作废
+   ├── 作废原因写:"[项目下架] 亲子游泳课程已停售,业户 LXX 同意取消"
+   └── 提交
+```
+
+> [!warning] 不要等"自动超时"自然作废
+> 自然超时虽然会废,但业户**等到 30 分钟后才发现**,体验差。**主动联系 + 提前作废** 是友好做法。
+
+### 步骤 4:处理已 Completed 的订单
+
+> [!success] 不需要做任何事
+> 历史 Completed 订单**完整保留**:
+> - 业户已收到的服务正常使用
+> - 收据依然有效
+> - 财务月度数据正常
+>
+> 项目下架**不溯及既往**。
+
+### 步骤 5:发运营公告
+
+```
+通过小程序 / 公众号 / 业主群发公告:
+
+"亲爱的业主朋友们:
+
+由于夏季结束,「亲子游泳课程」自 9 月 1 日起停止销售。
+已购买的业主可继续使用至有效期满。
+8 月 31 日前未付款的订单将自动取消,请有疑问联系物业前台。
+
+感谢您的支持!
+鸿基物业服务中心
+2026-09-01"
+```
+
+## 与新增项目的对照
+
+| 维度 | [[场景-配置-新增收费项目\|新增]] | 下架(本场景) |
+|---|---|---|
+| 谁操作 | 管理员 | 管理员 |
+| 系统改动 | 创建 RatePlan | RatePlan.is_active = false |
+| 对历史订单 | 无影响 | 无影响 |
+| **对 Pending 单** | 无(新项目无 Pending)| **必须主动处理**(联系业户撤单) |
+| **客户沟通** | 上线公告 | **下架公告 + 一对一通知 Pending 业户** |
+| 培训 | 业务人员 | 业务人员(知道为啥找不到了) |
+
+## 系统流程
+
+```mermaid
+sequenceDiagram
+    participant 运营
+    participant 管理员
+    participant 后台
+    participant Pending业户
+    participant 业务人员
+
+    运营->>管理员: 停售决定 + 生效日期
+    管理员->>后台: 禁用 RatePlan
+    后台-->>管理员: ✅ is_active = false
+    后台-->>后台: 小程序自动隐藏项目
+
+    管理员->>后台: 查 Pending 单
+    后台-->>管理员: 3 笔待处理
+
+    管理员->>业务人员: 转交 3 笔的业户联系信息
+
+    loop 对每笔 Pending 单
+        业务人员->>Pending业户: 微信/电话联系
+        Pending业户-->>业务人员: 同意取消
+        业务人员->>后台: VoidAction (reason="项目下架")
+        后台->>后台: 订单 → Voided
+    end
+
+    管理员->>运营: 发下架公告
+```
+
+## 几种下架的边界情况
+
+### 边界情况 1:有未发货的 Completed 订单
+
+业户已付款 + 物业还没发货(走 [[场景-异常-支付完成但实物发不出]]) → **必须继续履约**:
+
+```
+1. 项目虽下架,但已收的钱要兑现承诺
+2. 物业继续提供服务给已付款业户
+3. 不需要 / 不能作废这些 Completed 订单
+```
+
+### 边界情况 2:业户要求继续下单
+
+```
+业户:"我老婆 9 月 5 日生日,想买课程券作礼物"
+业务人员:"很抱歉,这个项目已经下架了,我们 10 月份会有秋季新课程..."
+```
+
+下架后**绝对不能为单个业户复活项目** —— 否则其他业户问起来很难解释。**等再开课时正式上架**。
+
+### 边界情况 3:整个 RatePlan 类别下架(夏季所有泳池项目)
+
+```
+1. 多个 RatePlan 同时禁用
+2. 用 SQL 批量改 is_active = false
+3. 对每个 RatePlan 的 Pending 单分别处理
+4. 发统一的"夏季泳池关闭"公告
+```
+
+### 边界情况 4:数据库还要保留多久?
+
+> [!info] 永久保留
+> 即使下架几年,RatePlan 和关联的所有 AdHocEvent / CollectionOrder / Receipt **都不删除**。审计要求 + 业户可能事后查询。
+
+## 常见问题
+
+> [!question] 业户问"我半年前买的月卡能不能延期到下个夏季?"
+> 取决于物业政策。**系统不强制有效期** —— 业务人员可以人为协商:
+> - 物业愿意延期 → 业户继续使用,系统里不需要任何改动
+> - 物业不愿意延期 → 婉拒,告知"原月卡有效期已过"
+
+> [!question] 下架的项目能"复活"吗?
+> 能。Filament 后台 → 编辑 → is_active 改回 true。所有历史数据不丢,业户立刻又能在小程序看到。
+
+> [!question] 业户支付**正好与禁用同时发生**怎么办?
+> 极少见的竞争场景。系统侧:
+> - 业户付款 → 支付回调到达
+> - 此时 RatePlan 已禁用,但**订单关联的 RatePlan 数据库引用不会消失**
+> - 订单照常翻 Completed,业户拿到收据
+>
+> 业务侧:业务人员发现这种情况,**主动联系业户** + 提供服务(物业道义责任)。
+
+> [!question] 如何避免业务人员"误删 RatePlan"导致历史数据丢失?
+> 当前 Filament 后台**支持 RatePlan 删除**(物理删除)。**应该禁掉这个 UI 入口**,只允许禁用(is_active=false)。挂 TODO。
+
+> [!question] 大批量下架 + 大量 Pending 业户,人工联系不过来怎么办?
+> 可以**先群发通知** + 等 30 分钟自动作废。但**有现金价值的 Pending 单**(业户已经在前台付了一半钱的)还是要 1 对 1 沟通。
+
+## 相关概念
+
+- [[场景-配置-新增收费项目]] — 上架的反向流程
+- [[场景-取消-业户改主意主动撤单]] — Pending 单的标准撤单流程
+- [[场景-异常-支付完成但实物发不出]] — 已 Completed 订单的处理
+- [[场景-审计-月底现金对账]] — 下架月份的对账
+
+## 异常分支
+
+- 已 Completed 但未发货 → 继续兑现服务
+- Pending 业户突然失联 → 等自动超时作废
+- 业务人员误禁用 → 立刻启用,无影响
--- a/prop-acc/一次性收费/场景-配置-新增收费项目.md
+++ b/prop-acc/一次性收费/场景-配置-新增收费项目.md
@@ -0,0 +1,200 @@
+---
+title: 场景 - 配置 - 新增收费项目
+tags:
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 配置准备
+audience:
+  - 业务人员
+status: stable
+last_reviewed: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:新增收费项目
+
+物业要**开始售卖一种新东西**(比如夏季新增"亲子游泳课程券" / 增加"宠物登记牌"等)。需要先在系统里**配置一个新的收费项目**(`RatePlan`),业务人员才能在 Filament 后台和小程序里见到这个项目。
+
+> [!info] 这是配置任务,不是日常操作
+> 一般由**物业管理员 / 运营**做,**不是前台日常**。但所有业务人员都该理解流程,因为新项目上线后他们才能录单。
+
+## 典型情境
+
+> [!example] 真实情境
+> 鸿基物业 5 月份决定夏季新增"亲子游泳课程":
+> - 单次 ¥80(家长 + 1 个小孩)
+> - 月卡 ¥600(每周 2 次)
+> - 季卡 ¥1500
+>
+> 运营经理周一上线前要把这 3 个项目配进系统。
+
+## 业务人员视角
+
+### 第 1 步:与运营 / 财务对齐
+
+新增项目前确认:
+
+| 字段 | 谁决定 |
+|---|---|
+| 项目名称 | 运营(对外宣传)|
+| 单价 | 运营 + 财务(成本核算)|
+| **费用类型分类**(FeeType)| 财务(影响会计科目映射)|
+| 单位 | 运营("张 / 次 / 月 / 季")|
+| 计费方式 | 运营(固定金额 / 按数量 / 按用量)|
+| 是否打折 | 运营 |
+
+### 第 2 步:管理员后台新建 RatePlan
+
+```
+Filament 后台 → 收费配置 → 收费项目 → 新建
+```
+
+| 字段 | 填什么 |
+|---|---|
+| 社区 | 选要上线的社区(可多选 → 多个社区批量创建)|
+| 名称 | "亲子游泳课程 - 单次" |
+| 费用类型 | 选"康体活动"(或新建分类) |
+| 计费方式 | 固定金额 |
+| 单价 | 80 |
+| 单位 | 次 |
+| 是否启用 | ✅ |
+| 备注 | 上线日期 / 课程时间 / 注意事项 |
+
+### 第 3 步:重复创建月卡 / 季卡
+
+类似第 2 步,**3 个项目分别创建**:
+- 亲子游泳课程 - 单次 ¥80
+- 亲子游泳课程 - 月卡 ¥600
+- 亲子游泳课程 - 季卡 ¥1500
+
+### 第 4 步:小程序展示(B 流)
+
+> [!info] 自动同步
+> RatePlan 创建后,小程序**自动从同一张表读项目列表**,无需额外配置。**保存即上线**。
+
+### 第 5 步:培训业务人员
+
+```
+1. 通知前台员工:"6 月 1 日上线,这是 3 个新项目"
+2. 培训:
+   ├── 怎么在 Filament 后台录入(其实和 IC 卡完全一样)
+   ├── 价格 / 适用对象 / 课程时间
+   └── 业户常见问题怎么答
+3. 周日打印一份"项目说明"贴前台,方便临时翻
+```
+
+### 第 6 步:监控前几天
+
+```
+- 第 1-3 天:留心系统是否报错
+- 第 1 周:观察实际售卖情况
+- 与运营对齐:是否调价、是否加新项目
+```
+
+## 系统流程
+
+```mermaid
+sequenceDiagram
+    participant 运营
+    participant 财务
+    participant 管理员
+    participant 后台
+    participant 前台员工
+    participant 小程序
+    participant 业户
+
+    Note over 运营,财务: 上线前准备
+    运营->>财务: 新项目方案 + 单价
+    财务-->>运营: 确认费用类型映射 + 入账规则
+
+    管理员->>后台: 创建 RatePlan x 3
+    后台-->>管理员: ✅ 项目已启用
+
+    Note over 后台,小程序: 自动同步
+
+    管理员->>前台员工: 培训新项目
+
+    Note over 业户: 上线日
+
+    业户->>小程序: 看到新项目可选
+    业户->>前台员工: 也可来前台买
+    前台员工->>后台: 录单(同 IC 卡流程)
+```
+
+## 几个重要概念
+
+### RatePlan vs AdHocEvent
+
+> [!info] 关系
+> - **RatePlan**(收费项目):**项目定义**。"亲子游泳课程 - 单次" 是 1 个 RatePlan。
+> - **AdHocEvent**(一次性收费事件):**单笔交易**。某业户买了 1 张课程券 = 1 个 AdHocEvent,关联到对应的 RatePlan。
+>
+> 1 个 RatePlan 对应 **N 个 AdHocEvent**(售卖多少笔)。
+
+### FeeType(费用类型)
+
+> [!info] 会计科目分类
+> RatePlan 的 `fee_type_id` 决定**会计科目映射** —— 收的钱进哪个会计科目。
+>
+> 常见 FeeType:
+> - 物业费(主营业务收入)
+> - 水电气费(代收代缴)
+> - **康体活动**(其他业务收入)← 亲子游泳课程在这
+> - 装修管理费(其他业务收入)
+> - **门禁配套** ← IC 卡在这
+>
+> FeeType 的设置影响财务月度报表 + 凭证生成(凭证模块,待补)。
+
+## 常见问题
+
+> [!question] 新增项目能上线前测试一下吗?
+> 可以。建议:
+> - 测试社区(如有)创建 RatePlan
+> - 测试账号(运营 / 财务 + 1 个业户测试号)
+> - 业户测试号在小程序下单 + 付款 + 收据
+> - 测试通过再正式社区上线
+
+> [!question] 一次性配置多个社区怎么操作?
+> Filament 后台新建 RatePlan 时,**社区字段是多选**。一次保存可在多个社区同步创建。
+
+> [!question] 已上线的项目想改价格?
+> Filament 后台**直接编辑 RatePlan 的单价**。**改价不影响历史订单**(历史订单已冻结当时金额)。新订单按新价。
+
+> [!question] 已上线的项目想停止销售但不删除?
+> 把 RatePlan 的 `is_active` 改为 `false`(禁用)。详见 [[场景-配置-下架收费项目并处理Pending单]]。
+
+> [!question] 业务上要求"老人优惠 70% 折扣"怎么配?
+> 当前 RatePlan **没有"用户身份折扣"功能**。变通方案:
+> - 创建两个 RatePlan:"亲子游泳课程 - 单次"(¥80) + "亲子游泳课程 - 老人优惠"(¥56)
+> - 前台员工根据业户年龄选对的项目
+>
+> 长期方案:实现优惠规则引擎(挂 TODO,等需求量大再做)。
+
+> [!question] 业务上要求"前 100 人 8 折"怎么配?
+> 当前**完全不支持**(需要限购 + 计数功能)。挂 TODO。变通方案:运营手动统计,人工调整。
+
+## 上线检查清单
+
+```
+□ RatePlan 已创建(单次 / 月卡 / 季卡)
+□ 价格与运营确认一致
+□ FeeType 与财务确认正确
+□ 测试社区跑通(可选)
+□ 前台员工已培训
+□ 前台贴出"项目说明"
+□ 小程序已能看到项目
+□ 应急:发现问题怎么联系管理员
+```
+
+## 相关概念
+
+- [[概念-CollectionOrder与Receipt]] — RatePlan 影响订单生成
+- [[场景-A流-前台购买IC卡]] — 业务人员录单的标准流程
+- [[场景-B流-小程序下单+微信支付]] — 小程序自动展示
+- [[场景-配置-下架收费项目并处理Pending单]] — 停售流程
+
+## 异常分支
+
+- 上线后发现价格错 → 立刻禁用 + 修改 + 启用
+- 业户已下单的旧价不变(系统冻结) → 没问题,新订单走新价