vault backup: 2026-05-25 13:54:35
This commit is contained in:
Willie
177
prop-acc/一次性收费/场景-异常-同业户跨社区Pending单.md
Normal file
177
prop-acc/一次性收费/场景-异常-同业户跨社区Pending单.md
Normal file
@@ -0,0 +1,177 @@
|
||||
---
|
||||
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 单的统一生命周期
|
||||
|
||||
## 异常分支
|
||||
|
||||
- 业户记不清在哪个社区下的单 → 集团总部协助查询
|
||||
- 业户希望取消所有未付单 → 在各社区小程序逐一取消
|
||||
Reference in New Issue
Block a user