Files
uniprop-manual/prop-acc/scenarios/adhoc/cross-channel-supplementary-payment.md
Willie 35c0147a7b 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>
2026-05-25 20:55:59 +08:00

5.6 KiB
Raw Blame History

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 · 场景 - 跨渠道补缴
prop-acc · 场景 - 跨渠道补缴
场景 - 跨渠道补缴
场景-跨渠道补缴
场景
prop-acc
一次性收费
业务场景
A流
B流
业户
业务人员
已发布 adhoc 2026-05-25 2026-05-22

场景:跨渠道补缴

儿女在小程序帮老人下单,老人到前台付现金

这是 概念-A流与B流并存设计最有价值的副产物。其他物业系统通常做不到 —— 因为他们的"线上单"和"线下单"是两个独立流程,互不相通。

典型情境

[!example] 真实情境 李女士的妈妈(78 岁)住在北京小区,装修工人下周要进场,需要 5 张装修出入证。

李女士在上海工作,不能亲自去物业,但她能在小程序上下单,妈妈只需要拿着身份证到前台付现金取证

业户视角(您要做什么)

第 1 步:儿女在小程序下单

(在上海)李女士打开物业小程序:

  • 选项目:装修出入证 × 5
  • 单价 ¥10,合计 ¥50
  • 备注:"我妈下周二上午去取,身份证号 XXX"
  • 提交下单(不付款)

[!info] 关键 下单时不付款 —— 系统给一个订单号(CO-xxx)。订单状态:Pending,默认有效期可以延长(比如 7 天,后台可配)。

李女士把订单号微信发给妈妈,告诉她:"妈,这是订单号,你拿着去前台说。"

第 2 步:老人到前台

(在北京)妈妈拿身份证 + 现金 ¥50 去物业前台:

"我女儿在小程序订了 5 张装修证,订单号是 CO-20260525-XX。我来付钱拿证。"

第 3 步:前台核对 + 收款

职员在 Filament 后台搜订单号:

  • 找到 Pending 订单 CO-XXX,业户名是李女士妈妈,5 张装修证 ¥50
  • 点击"标记已收款" → 选支付方式"现金" → 提交

订单瞬间翻 Completed,收据生成。

第 4 步:老人拿证 + 收据

  • 5 张装修出入证当场交付
  • 收据可打印纸质或发到女儿微信(收据本身归属业户档案,任意指定接收方)

[!success] 完成 全程业户体验流畅:线上方便、线下办成。家庭场景里没有谁需要懂"系统怎么工作"。

业务人员视角

关键操作

Filament 后台 → 一次性收费列表
├── 切到 "待付款" tab(默认只看 Completed)
├── 搜业户名 / 订单号
└── 找到记录后,点行操作菜单
    └── "标记已收款" 按钮(MarkAdHocEventPaidAction)
        ├── Modal 弹出:选支付方式(现金/微信/POS)
        └── 提交

业务人员需要核对

[!warning] 务必核对

  1. 业户身份:身份证 vs 系统里登记的业户姓名是否一致
  2. 金额:订单冻结金额 vs 业户实付现金是否一致
  3. 明细:是不是业户本人订的(避免别人冒领)

后台技术细节

sequenceDiagram
    participant 儿女
    participant 小程序
    participant 系统
    participant 老人
    participant 前台

    儿女->>小程序: 帮妈妈下单 5 张装修证
    小程序->>系统: CreatePendingAdHocEventAction
    系统->>系统: 建 AdHocEvent(Pending) + CO(Pending, expires_at=7天后)
    系统-->>小程序: 返订单号 CO-xxx
    小程序-->>儿女: 显示订单号
    儿女-->>老人: 微信发订单号

    Note over 老人,前台: 几天后,老人到前台

    老人->>前台: 出示订单号 + 身份证 + 现金
    前台->>系统: 搜订单号
    系统-->>前台: 显示订单详情
    前台->>系统: 标记已收款 + 选"现金"
    系统->>系统: MarkAdHocEventPaidAction
    系统->>系统: 1. 补 CO 支付字段
    系统->>系统: 2. 翻 CO + AdHocEvent → Completed
    系统->>系统: 3. 触发 CollectionOrderCompleted
    系统->>系统: 4. 自动生成 Receipt
    系统-->>前台: 完成通知
    前台->>老人: 出装修证 + 给收据

为什么这个场景重要?

[!tip] 业务价值 中国家庭真实写照:子女在外地工作,老人留守原小区。物业要服务老人,但年轻人想用便利渠道帮忙。

传统物业系统强迫家庭"二选一"(要么子女线上全部办完含付款 / 要么老人现场全部办完),本系统让线上线下衔接无缝

常见问题

[!question] 订单号丢了怎么办? 前台可以用业户姓名 + 身份证号搜系统里所有 Pending 单。

[!question] 儿女下单时填错了金额怎么办? 老人到前台时,职员发现金额不对,可以作废原单(走 场景-已收款作废 的轻量版,Pending 单作废没收据可废),让儿女或老人在前台直接重新下一单 A 流

[!question] 跨城市可以吗? 完全可以。订单是物业系统里的数据,不绑定地理位置。儿女在哪个国家都行,只要老人到对应小区物业即可。

[!question] 多人同时帮老人下单怎么办? 老人会在系统里有多个 Pending 单。前台核对时一一处理,支付一笔结一笔

业户的"双向感觉"

journey
    title 业户体验地图
    section 儿女(线上视角)
      下单: 5: 儿女
      看到订单号: 5: 儿女
      不需付款: 5: 儿女
      不需关注后续: 4: 儿女
    section 老人(线下视角)
      拿订单号到前台: 5: 老人
      付现金: 4: 老人
      当场拿货: 5: 老人
      纸质收据: 5: 老人

相关概念