场景:同业户跨社区 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 自动关联)	已实现 ✅

异常分支

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

6.2 KiB Raw Blame History

场景:同业户跨社区 Pending 单

典型情境

业务人员视角

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

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

数据隔离的好处和代价

数据库设计的隔离机制

系统流程

常见问题

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

相关概念

异常分支

6.2 KiB

Raw Blame History