dev #2
@@ -28,7 +28,7 @@
|
||||
- 改造招投标信息维护新建、导入链路中的供应商实体补入
|
||||
- 新增企业来源 `SUPPLIER=供应商`
|
||||
- 保证中介库管理新增、导入实体时风险等级默认为高风险
|
||||
- 补充对应后端、前端、SQL 与测试文档
|
||||
- 补充对应后端、前端与测试文档
|
||||
|
||||
### 2.3 非本次范围
|
||||
|
||||
@@ -88,64 +88,22 @@
|
||||
- 供应商明细包含供应商名称和统一信用代码
|
||||
- 当前不会补入实体库
|
||||
|
||||
## 4. 方案对比
|
||||
## 4. 实现方案
|
||||
|
||||
### 4.1 方案 A：新增后端内部实体库自动补全服务
|
||||
### 4.1 新增后端内部实体库自动补全服务
|
||||
|
||||
做法：
|
||||
本次采用单一路径实现：
|
||||
|
||||
- 新增一个内部复用能力，统一接收统一社会信用代码、企业名称、企业来源、数据来源和操作人
|
||||
- 各业务 Service 在成功落业务数据前调用
|
||||
- 已存在则不处理，不存在则插入最小实体记录
|
||||
|
||||
优点：
|
||||
采用该方案的原因：
|
||||
|
||||
- 规则集中，避免四处重复
|
||||
- 新建与导入可复用同一口径
|
||||
- 后续新增业务来源时扩展点明确
|
||||
|
||||
缺点：
|
||||
|
||||
- 需要各业务链路接入该内部服务
|
||||
|
||||
### 4.2 方案 B：各业务 Service 内分别查询和插入实体库
|
||||
|
||||
做法：
|
||||
|
||||
- 在每个业务 Service 中独立编写实体库查询和插入逻辑
|
||||
|
||||
优点：
|
||||
|
||||
- 单个文件内改动直观
|
||||
|
||||
缺点：
|
||||
|
||||
- 重复逻辑多
|
||||
- 来源、风险等级、并发重复处理容易不一致
|
||||
- 后续维护成本高
|
||||
|
||||
### 4.3 方案 C：数据库层通过 `INSERT IGNORE` 或 `ON DUPLICATE KEY` 处理
|
||||
|
||||
做法：
|
||||
|
||||
- 导入和新建时组装实体记录，直接通过 SQL 忽略重复或重复更新
|
||||
|
||||
优点：
|
||||
|
||||
- 批量性能好
|
||||
|
||||
缺点：
|
||||
|
||||
- 业务语义沉入 SQL
|
||||
- 新建和导入仍需额外分支
|
||||
- 容易误更新已存在实体
|
||||
|
||||
### 4.4 选型结论
|
||||
|
||||
采用方案 A。
|
||||
|
||||
原因：
|
||||
|
||||
- 满足最短路径实现
|
||||
- 业务规则集中可测
|
||||
- 不改变前端交互
|
||||
@@ -169,12 +127,12 @@
|
||||
| `social_credit_code` | 来源业务中的统一社会信用代码 |
|
||||
| `enterprise_name` | 来源业务中的企业名称或供应商名称 |
|
||||
| `ent_source` | 按业务来源映射 |
|
||||
| `risk_level` | 仅中介来源默认为 `1`，其他来源为空 |
|
||||
| `risk_level` | 仅中介来源默认为 `1`，其他来源按 `NULL` 落库 |
|
||||
| `data_source` | 新建为 `MANUAL`，导入为 `IMPORT` |
|
||||
| `created_by` | 当前操作人 |
|
||||
| `updated_by` | 当前操作人 |
|
||||
|
||||
其他实体字段保持为空。
|
||||
其他实体字段保持为空。自动补入能力必须使用独立插入路径，不复用实体库管理手工新增中要求风险等级必填的校验逻辑；员工亲属、信贷客户、供应商三类自动补入记录必须显式保证 `risk_level` 按 `NULL` 落库，不能吃到历史表默认低风险值。
|
||||
|
||||
### 5.3 企业来源映射
|
||||
|
||||
@@ -187,12 +145,11 @@
|
||||
| 信贷客户实体关联 | `CREDIT_CUSTOMER` | 空 |
|
||||
| 招投标供应商 | `SUPPLIER` | 空 |
|
||||
|
||||
需要新增企业来源枚举和字典：
|
||||
需要新增企业来源枚举：
|
||||
|
||||
- 编码：`SUPPLIER`
|
||||
- 名称：`供应商`
|
||||
- `SUPPLIER("SUPPLIER", "供应商")`
|
||||
|
||||
实体库管理页面应能正常显示和筛选“供应商”。
|
||||
企业来源选项由现有 `EnterpriseSource` 枚举接口下发，实体库管理页面应通过该接口正常显示和筛选“供应商”。
|
||||
|
||||
### 5.4 同批重复规则
|
||||
|
||||
@@ -316,17 +273,15 @@
|
||||
|
||||
自动补入实体库时，企业名称为空或超过长度不单独新增兜底规则，沿用各业务现有字段校验结果。
|
||||
|
||||
## 9. 前端与字典
|
||||
## 9. 前端与枚举
|
||||
|
||||
前端不新增交互。
|
||||
|
||||
需要同步新增或调整：
|
||||
|
||||
- 企业来源枚举新增 `SUPPLIER=供应商`
|
||||
- 字典数据新增供应商选项
|
||||
- 实体库管理页面企业来源下拉、列表、详情中的枚举展示能正确显示“供应商”
|
||||
|
||||
如果当前前端企业来源完全来自字典接口，则只需补 SQL 字典；如果存在本地枚举映射，则同步补充映射。
|
||||
- 后端 `EnterpriseSource` 枚举新增 `SUPPLIER("SUPPLIER", "供应商")`
|
||||
- 现有企业来源枚举接口应返回供应商选项
|
||||
- 实体库管理页面企业来源下拉、列表、详情中的枚举展示应能正确显示“供应商”
|
||||
|
||||
## 10. 测试设计
|
||||
|
||||
@@ -338,6 +293,8 @@
|
||||
- 员工亲属实体关联导入：成功行补入实体库，失败行不补
|
||||
- 中介实体关联新建：实体库无记录时补入 `INTERMEDIARY`，风险为 `1`
|
||||
- 中介实体关联导入：原实体不存在场景由失败改为成功
|
||||
- 中介库管理新增实体：未填写风险等级时写入 `riskLevel=1`
|
||||
- 中介库管理导入实体：成功记录写入 `riskLevel=1`
|
||||
- 信贷客户实体关联新建：实体库无记录时补入 `CREDIT_CUSTOMER`，风险为空
|
||||
- 信贷客户实体关联导入：成功行补入实体库，失败行不补
|
||||
- 招投标新建：供应商统一信用代码存在时补入 `SUPPLIER`，风险为空
|
||||
@@ -345,6 +302,7 @@
|
||||
- 已存在实体不覆盖原有名称、来源、风险等级、数据来源
|
||||
- 同批重复统一社会信用代码只补一次，首次名称生效
|
||||
- 并发或插入重复时按已存在处理
|
||||
- 员工亲属、信贷客户、招投标供应商自动补入记录的 `risk_level` 为 `NULL`
|
||||
|
||||
### 10.2 前端测试
|
||||
|
||||
@@ -367,7 +325,7 @@
|
||||
|
||||
## 11. 实施文档要求
|
||||
|
||||
本次功能涉及后端服务、SQL 字典和前端枚举展示，因此后续实施计划需要拆分：
|
||||
本次功能涉及后端服务、企业来源枚举和前端枚举展示，因此后续实施计划需要拆分：
|
||||
|
||||
- 后端实施计划：`docs/plans/backend/`
|
||||
- 前端实施计划：`docs/plans/frontend/`
|
||||
|
||||
Reference in New Issue
Block a user