P3.5: prop-acc 启用子模块嵌套(adhoc/),应对大型业务域扩展
背景: 单纯按 UDAS 严格扁平,prop-acc/scenarios/ 装齐 7 子模块后预计 100-150 篇 .md 单一文件夹,Explorer 无法浏览、Quartz folder page 无法阅读。 扩展规则(已写入 SKILL.md 多域章节 + multi-domain.md 第 10 节): - 单类型文件夹文件数 > 30 且能按业务子模块分组时,启用嵌套 - 路径:<domain>/<type>/<sub-feature>/<file>.md - 文件名去 <sub-feature>- 前缀(路径已表达) - title 三段式:<domain> · <sub-feature> · <名> - frontmatter 新增 sub_feature 字段(便于 RAG 过滤) - 跨子模块文档落在 <domain>/<type>/(不进子文件夹),与"跨域→cross/"对称 本次迁移: - prop-acc/concepts/adhoc-*.md (3) → prop-acc/concepts/adhoc/*.md - prop-acc/scenarios/adhoc-*.md (25) → prop-acc/scenarios/adhoc/*.md - 每个文件:title 加 adhoc 段、aliases 追加旧 prop-acc · 前缀形式(兼容)、 新增 sub_feature: adhoc 字段 WikiLink 解析未受影响: - 既有 [[场景-A流-...]] 等 200+ 引用通过 aliases (含旧 basename) 解析 - 新引用可用 [[adhoc · 前台购买 IC 卡]] 或 [[prop-acc · adhoc · 前台购买 IC 卡]] - 各域 knowledge-map.md 内 WikiLink 全部仍有效 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This commit is contained in:
Willie
238
prop-acc/scenarios/adhoc/config-delist-item-handle-pending.md
Normal file
238
prop-acc/scenarios/adhoc/config-delist-item-handle-pending.md
Normal file
@@ -0,0 +1,238 @@
|
||||
---
|
||||
title: prop-acc · adhoc · 场景 - 配置 - 下架收费项目并处理 Pending 单
|
||||
aliases:
|
||||
- prop-acc · 场景 - 配置 - 下架收费项目并处理 Pending 单
|
||||
- 场景 - 配置 - 下架收费项目并处理 Pending 单
|
||||
- 场景-配置-下架收费项目并处理Pending单
|
||||
tags:
|
||||
- 场景
|
||||
- prop-acc
|
||||
- 一次性收费
|
||||
- 业务场景
|
||||
- 配置准备
|
||||
audience:
|
||||
- 业务人员
|
||||
status: 已发布
|
||||
sub_feature: adhoc
|
||||
last_review: 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 业户突然失联 → 等自动超时作废
|
||||
- 业务人员误禁用 → 立刻启用,无影响
|
||||
Reference in New Issue
Block a user