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>

prop-acc/scenarios/adhoc-exception-payment-split-failure.md

@@ -0,0 +1,138 @@
+---
+title: prop-acc · 场景 - 异常 - 支付分账失败
+aliases:
+  - 场景 - 异常 - 支付分账失败
+  - 场景-异常-支付分账失败
+tags:
+  - 场景
+  - prop-acc
+  - 一次性收费
+  - 业务场景
+  - 异常故障
+audience:
+  - 业务人员
+status: 草稿
+last_review: 2026-05-25
+code_version: 2026-05-22
+---
+
+# 场景:支付分账失败
+
+业户付款成功,但**物业商户号到结算账户的分账失败**。属于支付平台异常,本系统侧只能等通知 + 人工干预。
+
+> [!warning] 进阶场景,本系统弱介入
+> 分账是**微信/支付宝商户后台**的功能,本系统侧基本看不到这一步。本文档仅作为应急参考。
+
+## 什么是"分账"?
+
+> [!info] 一图看懂
+> ```
+> 业户付款 → 微信支付收钱 → 微信商户号(物业)→ 分账到物业银行账户
+>            ✅ 这一步是支付         ✅ 这一步是分账(本场景关心)
+> ```
+> 
+> 大多数小型物业**不需要分账**(钱直接从微信结算到对公账户)。**需要分账的场景**:
+> - 物业方 + 物业服务集团 + 项目方三家**按比例分钱**
+> - 上市物业集团 + 全国各分公司**按地域分账**
+> - 委托管理模式(开发商 vs 物业公司 二八分)
+
+## 典型情境
+
+> [!example] 真实情境
+> 鸿基物业管理集团旗下小区,业户用小程序付了 ¥3000 装修押金。
+>
+> 微信支付成功 → 钱进鸿基物业商户号。商户号配置了分账规则:
+> - 70% 给小区项目方
+> - 30% 给鸿基集团运营费
+>
+> 第二天集团财务发现:小区项目方收到 ¥2100 ✅,**集团运营费 ¥900 没有收到** ❌。
+
+## 业务人员视角
+
+### 这种问题怎么发现?
+
+业务人员**不会主动发现** —— 通常是:
+- 集团财务月底对账 → 发现少了一部分
+- 微信商户后台**邮件通知**"分账失败"
+
+> [!warning] 关键
+> 系统侧的 `CollectionOrder` **状态依然是 Completed** —— 因为业户支付的钱**确实进了商户号**,只是后续分账失败。系统层面无错。
+
+### 处理流程
+
+```
+1. 登录微信支付商户后台 → 分账记录
+2. 找到失败的分账记录,看失败原因:
+   ├── 接收方账户冻结
+   ├── 分账方金额不足(剩余金额已分完)
+   └── 接收方未签约接收能力
+3. 联系微信客服 / 修复配置
+4. 重试分账 (通常 30 天内可重试)
+```
+
+### 本系统侧需要做什么?
+
+**几乎不用** —— 本系统已经"收到了钱"(从业户视角钱付完了)。分账是物业内部账务问题。
+
+> [!info] 但如果分账失败导致需要"全单退款给业户":
+> - 业务人员走 [[场景-已收款作废]] 标记订单作废
+> - 微信商户后台**手动发起退款**给业户
+> - 业户拿回钱,后续物业再处理内部账务
+
+## 系统流程
+
+```mermaid
+sequenceDiagram
+    participant 业户
+    participant 微信支付
+    participant 物业商户号
+    participant 项目方账户
+    participant 集团账户
+    participant 系统
+
+    业户->>微信支付: 付款 ¥3000
+    微信支付->>物业商户号: ¥3000 入账
+    微信支付->>系统: webhook → MarkAsPaid
+    系统-->>业户: 订单 Completed,收据生成
+
+    Note over 业户,系统: 业户视角:一切正常
+
+    Note over 物业商户号: 系统自动触发分账
+    物业商户号->>项目方账户: 分账 ¥2100 ✅
+    物业商户号->>集团账户: 分账 ¥900 ❌ (接收方账户冻结)
+
+    Note over 业务人员: 第二天集团对账才发现
+```
+
+## 常见问题
+
+> [!question] 业户会感知到分账失败吗?
+> 不会。从业户视角,**钱付完订单完成**,完美无瑕。
+
+> [!question] 财务多久能发现?
+> 取决于对账频率。建议物业**至少每周对一次分账记录**,而不是等月底。
+
+> [!question] 系统能监控分账状态吗?
+> 当前**没有集成**。可以挂 TODO:
+> - 微信商户号开放分账状态查询 API
+> - 系统每天定时查最近 7 天的分账状态
+> - 失败的发警报到物业财务
+
+> [!question] 分账失败 30 天没解决,钱会怎样?
+> 微信会**原路退回给业户**(钱回到业户原微信)。这种情况业户会突然收到一笔退款,**联系不上业户解释** = 麻烦。所以**分账失败 30 天前必须处理**。
+
+## 简化场景:不需要分账的物业
+
+> [!success] 大多数小型物业:跳过本场景
+> 单一物业公司,微信商户号直绑对公账户,**无需分账配置**。本场景对你们不适用。
+
+## 相关概念
+
+- [[概念-CollectionOrder与Receipt]] — 系统侧"收钱"的语义边界
+- [[场景-B流-小程序下单+微信支付]] — 业户付款正向流程
+- [[场景-审计-月底现金对账]] — 多渠道对账
+
+## 待补
+
+- **系统集成分账状态监控**:挂 TODO,等真正出现分账失败客诉再做
+- **多商户/多账户场景的会计科目对接**:超出一次性收费模块范围,与凭证模块相关(待补)