---
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 业户突然失联 → 等自动超时作废
- 业务人员误禁用 → 立刻启用,无影响