---
title: 场景 - 异常 - 同业户跨社区 Pending 单
tags:
  - prop-acc
  - 一次性收费
  - 业务场景
  - 异常故障
audience:
  - 业务人员
status: stable
last_reviewed: 2026-05-25
code_version: 2026-05-22
---

# 场景:同业户跨社区 Pending 单

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

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

## 典型情境

> [!example] 真实情境
> 周先生是连锁老板,**北京有住宅、上海有公寓**,两个小区都是同一物业公司"鸿基物业"管理。
>
> 一个周末他在北京住宅的小程序下单 IC 卡 ¥30(没付),又在上海公寓的小程序下单装修证 ¥150(没付)。
>
> 第二天他到**北京物业前台**问"我下了什么订单都还没付的?",职员只能查到**北京小区**的 1 笔。

## 业务人员视角

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

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

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

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

```sql
-- 数据库查询(超级管理员视角)
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] 代价:跨社区业户体验差
> - 跨社区业户感受不到"统一"
> - 前台无法跨社区帮业户查订单
> - 需要业户**自己记得在哪个社区下了什么单**

## 数据库设计的隔离机制

```mermaid
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
```

## 系统流程

```mermaid
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 单的统一生命周期

## 异常分支

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