diff --git a/.obsidian/workspace.json b/.obsidian/workspace.json index 8dc4fe8..92eba3f 100644 --- 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" diff --git a/prop-acc/一次性收费/index.md b/prop-acc/一次性收费/index.md index b0bee55..9b8816b 100644 --- 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) +> +> 如果发现遗漏的场景或需要补充的细节,告诉我,可以单独补充新文档。 diff --git a/prop-acc/一次性收费/场景-审计-作废事由抽查.md b/prop-acc/一次性收费/场景-审计-作废事由抽查.md new file mode 100644 index 0000000..c8ec530 --- /dev/null +++ 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 模板 diff --git a/prop-acc/一次性收费/场景-配置-下架收费项目并处理Pending单.md b/prop-acc/一次性收费/场景-配置-下架收费项目并处理Pending单.md new file mode 100644 index 0000000..a36d7c3 --- /dev/null +++ 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 业户突然失联 → 等自动超时作废 +- 业务人员误禁用 → 立刻启用,无影响 diff --git a/prop-acc/一次性收费/场景-配置-新增收费项目.md b/prop-acc/一次性收费/场景-配置-新增收费项目.md new file mode 100644 index 0000000..f0ee9f2 --- /dev/null +++ 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单]] — 停售流程 + +## 异常分支 + +- 上线后发现价格错 → 立刻禁用 + 修改 + 启用 +- 业户已下单的旧价不变(系统冻结) → 没问题,新订单走新价