Files
uniprop-manual/prop-acc/scenarios/adhoc-cross-channel-supplementary-payment.md
Willie b7c0cd6e0c P3+P4+P5: prop-acc 迁移到多域 UDAS,新建 4 域骨架与顶层入口
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>
2026-05-25 20:44:43 +08:00

5.6 KiB
Raw Blame History

title, aliases, tags, audience, status, last_review, code_version
title aliases tags audience status last_review code_version
prop-acc · 场景 - 跨渠道补缴
场景 - 跨渠道补缴
场景-跨渠道补缴
场景
prop-acc
一次性收费
业务场景
A流
B流
业户
业务人员
已发布 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: 老人

相关概念