uniprop-manual/prop-acc/scenarios/adhoc/config-delist-item-handle-pending.md

title, aliases, tags, audience, status, sub_feature, last_review, code_version

title	aliases	tags	audience	status	sub_feature	last_review	code_version
prop-acc · adhoc · 场景 - 配置 - 下架收费项目并处理 Pending 单	prop-acc · 场景 - 配置 - 下架收费项目并处理 Pending 单 场景 - 配置 - 下架收费项目并处理 Pending 单 场景-配置-下架收费项目并处理Pending单	场景 prop-acc 一次性收费 业务场景 配置准备	业务人员	已发布	adhoc	2026-05-25	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 单

-- 找到所有相关 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 业户
培训	业务人员	业务人员(知道为啥找不到了)

系统流程

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