# 智慧康养服务商管理系统 模块规划

---

## 1. 模块定位

智慧康养服务商管理系统是连接**平台（政府/运营方）与服务供给侧（服务商/从业人员）** 的 B2G/B2B/B2C 三维业务系统，负责服务商的注册准入、资质审核、人员管理、服务范围配置、订单履约管理、信用评分和 IoT 服务监控（500+ 终端）。

本系统是整个平台"服务能力供给"的核心，服务商数量与质量直接决定居家养老、社区助餐等业务的履约能力。

---

## 2. 建设目标

1. 实现服务商在线注册申请→政府资质审核→平台入驻的完整准入流程
2. 管理服务商人员档案、技能认证、绩效考核
3. 支持服务商自主配置服务范围（区域）和服务项目（价格/时长）
4. 构建服务商信用体系，基于服务完成率、评分、投诉率等维度动态评分
5. 提供服务监控能力，对 500+ IoT 终端和服务执行进行实时追踪

---

## 3. 核心功能范围

### 3.1 一级模块

- 服务商注册与审核
- 服务商档案管理
- 服务人员管理
- 服务范围与项目管理
- 订单管理
- 绩效与考核体系
- 信用评分体系
- 服务监控

### 3.2 二级模块

- **注册审核**：服务商申请→资质材料上传→审核→入驻通知→账号激活
- **档案管理**：基本信息、营业执照、服务许可、合同管理、开票信息
- **人员管理**：招募、技能认证（护工/护士/医生证）、排班、考勤
- **服务范围**：地图选区设置服务覆盖区域、可承接服务类型
- **订单管理**：待接单队列、执行中订单、历史订单、订单异常处置
- **绩效考核**：月度绩效报表、服务完成率、评分均值、投诉率分析
- **信用评分**：综合评分算法（完成率/投诉/证书效期等），等级标签
- **服务监控**：500+ IoT 终端状态汇总、告警统计、设备分布地图

### 3.3 核心功能说明

| 功能          | 描述                                                                  | 技术要点                     |
| ------------- | --------------------------------------------------------------------- | ---------------------------- |
| 资质审核流程  | 材料OCR识别 + 人工审核 + 多级批准                                     | OCR + 工作流引擎             |
| 服务区域配置  | 地图绘制多边形服务区域                                                | 高德地图绘图API + 多边形存储 |
| 信用评分算法  | 加权综合评分 = 完成率×40% + 评分均值×30% + 投诉率×-20% + 证书效期×10% | 定期计算任务                 |
| 500+ 设备监控 | 实时展示所有设备在线率、告警数、最近上报                              | MQTT状态聚合 + 分页仪表盘    |
| 订单分析      | 服务商维度的订单量/收入/退款分析                                      | 统计服务 + 图表              |

---

## 4. 与现有 mall 的关系

**契合度：B（中契合，商家管理可参考）**

mall 具备完整的商家（Merchant）管理体系，与本系统存在结构性相似：

| 能力                 | mall 现状               | 可复用程度                       |
| -------------------- | ----------------------- | -------------------------------- |
| 商家注册与审核       | 有（资质上传+人工审核） | B - 可参考审核流程，但字段需扩展 |
| 商家商品/服务管理    | 有（商品目录+SKU）      | B - 服务目录可参考，去除库存概念 |
| 订单管理（商家侧）   | 有（接单/拒单/发货）    | B - 参考状态机，改造为服务型订单 |
| 商家账单/提现        | 有                      | B - 可直接复用或少量改造         |
| 商家评分/评价        | 有                      | B - 扩展为信用评分体系           |
| **服务人员管理**     | **无**                  | **须新建**                       |
| **IoT设备监控**      | **无**                  | **须新建**                       |
| **地理服务区域配置** | **无**                  | **须新建**                       |
| **信用评分算法**     | **无**                  | **须新建**                       |
| **政府准入审批**     | **无**                  | **须新建（B2G部分）**            |

**建设路径：mall 商家管理基础 + 大量独立微服务扩展**

建议在独立系统中参考 mall 商家管理的设计模式（审核流程、账单结算），但不在 mall 内部改造，以避免电商逻辑与医养业务逻辑的交叉污染。

---

## 5. 规划判断

**mall + 独立微服务（以独立为主，参考 mall B 级能力）**

- 服务商端：uni-app（小程序）
- 平台管理端：Vue3 Web
- 服务端：独立服务商服务（参考 mall 商家服务的设计架构）
- IoT监控层：依托 IoT 管理（16）和安全系统（09）的数据聚合

---

## 6. 需新增业务能力

1. **服务商准入评审**：资质材料多维度核验（国标服务资质要求）
2. **从业人员证件管理**：护理员/护士/医生证有效期自动预警
3. **地理服务区域可视化配置**：服务商在地图上自助划定服务范围
4. **信用评分引擎**：可配置权重的综合信用评分，等级自动更新
5. **服务商资金分账**：订单完成后自动结算到服务商子账户
6. **IoT监控聚合**：500+ 设备按服务商维度聚合展示状态

---

## 7. 需新增数据模型

| 模型                         | 关键字段                                                                                        |
| ---------------------------- | ----------------------------------------------------------------------------------------------- |
| `service_provider`           | id, name, biz_license_no, service_license_no, district_code, credit_score, credit_grade, status |
| `provider_qualification_doc` | provider_id, doc_type, doc_url, ocr_result(JSONB), expire_date, verify_status                   |
| `provider_staff`             | id, provider_id, name, cert_type, cert_no, cert_expire, skill_tags, status                      |
| `provider_service_area`      | provider_id, polygon_points(JSONB), effective_date                                              |
| `provider_service_catalog`   | provider_id, service_catalog_id, price, min_duration_min, max_concurrent                        |
| `provider_order`             | id, provider_id, order_id (ref home_service_order), status, staff_id                            |
| `provider_credit_record`     | id, provider_id, score_before, score_after, reason, calc_at                                     |
| `provider_wallet`            | provider_id, balance, frozen_amount, last_settled_at                                            |

---

## 8. 需新增技术栈 / 第三方能力 / 中间件

| 类别     | 技术选型                  | 用途                     |
| -------- | ------------------------- | ------------------------ |
| GIS      | 高德地图绘图API           | 服务区域多边形绘制与存储 |
| OCR      | 腾讯云OCR                 | 营业执照/证书自动识别    |
| 分账     | 微信商户分账 / 支付宝分账 | 服务费用自动分账给服务商 |
| 定时任务 | XXL-JOB                   | 每日信用评分重算         |
| 消息推送 | 微信模板消息              | 审核结果、订单通知       |

---

## 9. 外部系统对接关系

| 对接方             | 内容                     | 方式     |
| ------------------ | ------------------------ | -------- |
| 审批系统（04）     | 服务商资质审批结论       | 内部API  |
| 居家养老管理（10） | 服务员派单、订单数据     | 内部API  |
| IoT管理（16）      | 设备监控数据聚合         | 内部API  |
| 数据库系统（02）   | 服务商档案写入、人员档案 | 内部API  |
| mall支付（19）     | 服务费支付与分账         | 支付网关 |
| 政府监管（01）     | 服务商信用、服务量统计   | 内部API  |

---

## 10. 风险与边界

| 风险                     | 说明                             | 应对                                          |
| ------------------------ | -------------------------------- | --------------------------------------------- |
| 服务商造假资质           | 伪造营业执照或资质证书           | OCR + 人工双重验证 + 工商查询API（⚠️ 待确认） |
| 分账合规                 | 资金分账需满足第三方支付监管要求 | 使用持牌支付机构的分账功能                    |
| 信用评分算法公平性       | 新入驻服务商样本量少，评分不准确 | 新商家保护期机制（前30单不计负评）            |
| 边界：不含服务员劳动合同 | HR管理和劳动合同不在本系统范围   | 仅管理技能资质和绩效，不涉及劳动关系          |

---

## 11. 实施优先级与分期建议

**优先级：P1**

| 分期   | 内容                                     | 前置条件                   |
| ------ | ---------------------------------------- | -------------------------- |
| 第一期 | 服务商注册审核 + 人员管理 + 服务目录配置 | 审批系统（04）就绪         |
| 第二期 | 订单管理 + 服务区域配置 + 结算分账       | 居家养老（10）订单系统就绪 |
| 第三期 | 信用评分 + IoT监控 + 绩效报表            | IoT管理（16）就绪          |

---

## 12. 结论

服务商管理系统是平台服务能力的供给端，mall 商家管理体系（审核流程、账单结算）对本模块具有中等参考价值（B级），但服务人员证件管理、地理服务区域、IoT监控等核心医养特性能力须独立建设。

**建议参考 mall 商家管理的设计模式独立建设**，通过API对接 mall 支付分账能力，避免在 mall 内部直接改造带来的代码耦合风险。
