uniprop-manual/prop-acc/scenarios/adhoc-exception-cross-community-pending.md

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

title	aliases	tags	audience	status	last_review	code_version
prop-acc · 场景 - 异常 - 同业户跨社区 Pending 单	场景 - 异常 - 同业户跨社区 Pending 单 场景-异常-同业户跨社区Pending单	场景 prop-acc 一次性收费 业务场景 异常故障	业务人员	已发布	2026-05-25	2026-05-22

场景:同业户跨社区 Pending 单

业户在多个社区(物业项目)都有房子,小程序里能下单任一社区的一次性收费。可能产生跨社区的待付单 + 跨渠道补缴的复杂场景。

[!info] 不算 bug,但需要业务人员理解 本系统天然按社区(community_id)隔离数据。但同一个业户在多社区有不同房子时,他/她的订单分布在不同社区的数据空间。

典型情境

[!example] 真实情境 周先生是连锁老板,北京有住宅、上海有公寓,两个小区都是同一物业公司"鸿基物业"管理。

一个周末他在北京住宅的小程序下单 IC 卡 ¥30(没付),又在上海公寓的小程序下单装修证 ¥150(没付)。

第二天他到北京物业前台问"我下了什么订单都还没付的?",职员只能查到北京小区的 1 笔。

业务人员视角

关键约束:Filament 默认只显示当前社区

登录 Filament → 切换社区(顶栏选择器)
├── 北京小区 → 看到周先生的 IC 卡订单
├── 上海小区 → 看到周先生的装修证订单
└── 切换社区 → 看不到另一社区的订单

如何帮业户查全部跨社区订单

步骤 1:理论上的全局视角

-- 数据库查询(超级管理员视角)
SELECT
    ahe.id,
    ahe.community_id,
    c.name AS 社区名,
    rp.name AS 项目,
    ahe.amount,
    ahe.status,
    ahe.created_at
FROM acc_ad_hoc_events ahe
JOIN community_communities c ON ahe.community_id = c.id
JOIN acc_rate_plans rp ON ahe.rate_plan_id = rp.id
WHERE ahe.community_user_profile_id = (
    SELECT id FROM community_community_user_profiles
    WHERE user_id = (SELECT id FROM users WHERE phone = '13800138000')
)
  AND ahe.status = 'pending';

步骤 2:实际操作

[!warning] 普通业务人员通常无法跨社区查询 物业前台员工只能登录自己负责的社区。跨社区查询需要总部管理员。

业务流程上的应急方案:

• 业户在哪个社区前台,就办哪个社区的订单
• 让业户自己去另一个社区的小程序入口查另一笔订单
• 集团总部如有需要可以总部协调跨社区客服

数据隔离的好处和代价

[!success] 好处:数据干净

• 北京小区的财务对账只看北京数据
• 上海小区的财务对账只看上海数据
• 互不影响 = 各社区独立运营

[!warning] 代价:跨社区业户体验差

• 跨社区业户感受不到"统一"
• 前台无法跨社区帮业户查订单
• 需要业户自己记得在哪个社区下了什么单

数据库设计的隔离机制

graph TD
    A[全国业户档案<br/>users 表] -->|user_id| B[业户在北京<br/>CUP id=100]
    A -->|user_id| C[业户在上海<br/>CUP id=200]

    B -->|community_user_profile_id| D[北京 IC 卡订单<br/>community_id=1]
    C -->|community_user_profile_id| E[上海 装修证订单<br/>community_id=2]

    F[北京前台<br/>登录到 community_id=1] -.->|看不到| E
    G[上海前台<br/>登录到 community_id=2] -.->|看不到| D

    classDef user fill:#fef3c7
    classDef profile fill:#dbeafe
    classDef order fill:#dcfce7
    classDef frontdesk fill:#fee2e2

    class A user
    class B,C profile
    class D,E order
    class F,G frontdesk

系统流程

sequenceDiagram
    participant 业户
    participant 北京小程序
    participant 北京前台
    participant 上海小程序
    participant 上海前台
    participant 系统

    业户->>北京小程序: 下单 IC 卡
    北京小程序->>系统: 建 Pending 单 (community_id=1)
    业户->>上海小程序: 下单装修证
    上海小程序->>系统: 建 Pending 单 (community_id=2)

    Note over 业户: 第二天到北京前台

    业户->>北京前台: 我的所有待付单是?
    北京前台->>系统: 查 community_id=1
    系统-->>北京前台: 只返回北京 IC 卡单
    北京前台-->>业户: 您有 1 笔待付:IC 卡

    Note over 业户: 业户困惑:"我记得还有一笔啊"

    业户->>业户: 想起来 → 去上海小程序查
    业户->>上海小程序: 查我的订单
    上海小程序-->>业户: 找到上海装修证单

常见问题

[!question] 业户能在北京小程序里看到上海订单吗? 不能。小程序默认按当前社区隔离。业户切换社区才能看另一社区的订单。

[!question] 如果是集团连锁物业,有"统一业户视图"吗? 当前没有。如果业务方明确需要,可以挂 TODO 做一个"业户中心"页面,跨社区聚合该业户的所有订单。优先级看实际需求。

[!question] 跨社区补缴可以吗? 不能。北京 Pending 单只能在北京前台用现金补缴。上海前台搜不到这笔订单。

[!question] 业户回家发现两笔都到期了,怎么办? 两笔都自动作废,业户重新在对应社区下单即可。详见 场景-超时未付自动作废。

[!question] 同一业户在 5 个社区都有房,管理上会乱吗? 业户需要自己管理(记录每个社区的房号、订单)。这是"多社区业户"的固有复杂性,不只是本系统的问题 —— 物业管理本质如此。

跨社区业户的常见需求与方案

需求	当前方案	长期方案
跨社区查所有订单	业户自己切社区查	业户中心(挂 TODO)
跨社区合并支付	不支持	支付聚合(技术复杂,挂 TODO)
跨社区合并发票	不支持(发票本来就独立)	发票合并(财务侧支持)
跨社区免重复绑定	系统已支持(同 user_id 自动关联)	已实现 ✅

相关概念

• 概念-CollectionOrder与Receipt — 每笔订单绑定 community_id
• 场景-跨渠道补缴 — 同社区内的跨渠道场景
• 场景-超时未付自动作废 — Pending 单的统一生命周期

异常分支

• 业户记不清在哪个社区下的单 → 集团总部协助查询
• 业户希望取消所有未付单 → 在各社区小程序逐一取消