P3 — prop-acc 30 文件迁移到多域 UDAS 结构:
- 3 概念:旧 prop-acc/一次性收费/概念-*.md
→ prop-acc/concepts/adhoc-*.md (kebab-case 英文)
- 25 场景:旧 prop-acc/一次性收费/场景-*.md
→ prop-acc/scenarios/adhoc-*.md
- 子文件夹 index.md → prop-acc/maps/knowledge-map.md (域内地图)
- prop-acc/index.md 重写为域首页(embed knowledge-map)
- 删除空目录 prop-acc/一次性收费/
每个迁移文件:
- title 加域前缀 "prop-acc · "
- aliases 含原 title (带空格) + 原文件名 basename (无空格),保证既有 [[...]] 引用解析
- status: stable → 已发布 / draft → 草稿 (UDAS 中文枚举)
- last_reviewed → last_review (UDAS 字段名)
- tags 补加 UDAS 类型分类 "概念" / "场景"
- 路径式 WikiLink 清除:
* [[../预存款/index|XX]] → [[预存款]]
* [[一次性收费/index|XX]] → [[prop-acc · 一次性收费索引]]
P4 — 4 个新业务域骨架:
- community (社区管理)
- administrative (行政人事)
- patrol (巡护工单)
- resident-portal (业户门户)
每域含 index.md (域首页) + maps/knowledge-map.md (域内地图模板)。
另补 cross/index.md + cross/maps/cross-domain-map.md。
P5 — 顶层入口:
- index.md: 站点首页 (Quartz 着陆点),embed domain-map
- maps/domain-map.md: 5 业务域 + cross 的索引表
迁移后状态:
- 共 50 篇 .md (30 原 + 8 跨域 stub + 4 域 index + 4 域 map + 2 cross + 2 root)
- 残留路径式 WikiLink: 0
- 残留英文 status: 0
- 残留 last_reviewed 字段: 0
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
7.8 KiB
title, aliases, tags, audience, status, last_review, code_version
| title | aliases | tags | audience | status | last_review | code_version | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| prop-acc · 场景 - 配置 - 下架收费项目并处理 Pending 单 |
|
|
|
已发布 | 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 业户突然失联 → 等自动超时作废
- 业务人员误禁用 → 立刻启用,无影响