ccdi/docs/superpowers/specs/2026-04-23-bidding-supplier-enterprise-detail-design.md

招投标详情弹窗供应商企业信息查看设计文档

1. 背景

当前“招投标信息维护”页面已经支持在详情弹窗中查看供应商明细列表，供应商行中也已经保留了统一信用代码字段。

仓库中同时已经存在独立的“实体库管理”模块，底层使用 ccdi_enterprise_base_info 表，并提供了现成的企业详情查询接口 GET /ccdi/enterpriseBaseInfo/{socialCreditCode}。

本次需求不是新建企业信息维护能力，也不是扩展招投标详情聚合接口，而是在现有招投标详情弹窗中，为供应商列表补充一个最短路径的“企业详情查看”入口。

2. 目标

在招投标信息维护页面的详情弹窗中：

• 为供应商明细列表新增“操作”列
• 每行新增“详情”按钮
• 点击后只按供应商统一信用代码查询实体库企业详情
• 若能查到企业，则通过弹窗展示实体库全部字段
• 若查不到企业，或者当前供应商没有统一信用代码，则统一提示“暂无企业信息”

3. 非目标

• 不改造招投标新增/编辑弹窗中的供应商录入逻辑
• 不改造招投标详情接口返回结构，不在详情接口中聚合企业详情
• 不新增按企业名称模糊查询或兜底查询
• 不跳转到“实体库管理”页面查看
• 不为企业详情弹窗增加编辑、删除、跳转等附加操作
• 不新增后端接口

4. 现状分析

4.1 已有基础

仓库中已经具备以下可复用基础：

• 招投标详情弹窗页面：ruoyi-ui/src/views/ccdiPurchaseTransaction/index.vue
• 实体库前端 API：ruoyi-ui/src/api/ccdiEnterpriseBaseInfo.js
• 实体库详情接口：GET /ccdi/enterpriseBaseInfo/{socialCreditCode}
• 实体库详情展示字段口径：ruoyi-ui/src/views/ccdiEnterpriseBaseInfo/index.vue

4.2 当前缺口

当前招投标详情弹窗的供应商明细仅支持只读查看以下字段：

• 排序
• 中标结果
• 供应商名称
• 统一信用代码
• 联系人
• 联系电话
• 银行账户

但尚未提供从供应商直接查看实体库企业详情的入口，因此用户无法在招投标详情场景下快速确认该供应商在实体库中的完整企业信息。

5. 方案比较

5.1 方案一：在招投标详情弹窗中直接新增企业详情二级弹窗

做法：

• 在供应商明细表新增“操作”列和“详情”按钮
• 点击后调用现有实体库详情接口
• 查询成功则在当前页面内打开只读企业详情弹窗

优点：

• 改动范围最小
• 不改后端
• 不影响实体库管理页面现有逻辑
• 最符合本次“最短路径实现”的要求

缺点：

• 企业详情展示结构会在招投标页面内复用一份

5.2 方案二：抽取通用企业详情组件供多个页面复用

做法：

• 将实体库管理页面现有详情展示抽成独立组件
• 招投标详情弹窗和实体库管理页面共同复用该组件

优点：

• 后续多个页面查看企业详情时更统一

缺点：

• 会额外改造现有实体库管理页面
• 本次改动面超出当前需求

5.3 方案三：改造招投标详情后端接口，聚合返回企业详情

做法：

• 后端在查询招投标详情时，顺带按供应商统一信用代码查询实体库
• 前端点击时直接展示已返回的企业详情

优点：

• 前端点击时无需追加请求

缺点：

• 后端改动范围扩大
• 会给现有详情接口增加本次非必须数据
• 不符合最短路径原则

5.4 结论

采用方案一：在招投标详情弹窗中直接新增“操作列 + 企业详情二级弹窗”，并复用现有实体库详情接口。

6. 总体设计

6.1 模块边界

本次只改前端页面：

• ruoyi-ui/src/views/ccdiPurchaseTransaction/index.vue

复用现有前端 API：

• ruoyi-ui/src/api/ccdiEnterpriseBaseInfo.js

不新增后端 Controller、Service、Mapper、SQL 和菜单权限配置。

6.2 页面交互

在“招投标信息详情”弹窗中的供应商明细表新增“操作”列。

交互规则固定如下：

1. 每行固定显示一个“详情”按钮
2. 点击后只读取当前行 supplierUscc
3. 若 supplierUscc 为空，直接提示“暂无企业信息”
4. 若 supplierUscc 不为空，则调用现有实体库详情接口
5. 若接口返回企业详情，则打开只读企业详情弹窗
6. 若接口查不到企业，则提示“暂无企业信息”

6.3 弹窗层级

• 一级弹窗：现有“招投标信息详情”弹窗
• 二级弹窗：新增“企业信息详情”弹窗

二级弹窗在当前页面内打开，不跳转页面，也不关闭一级弹窗。

6.4 权限口径

本次不新增权限控制，也不对按钮做权限显隐控制。

具体口径固定如下：

• 供应商明细表中的“详情”按钮固定显示
• 前端不新增 v-hasPermi 限制
• 本次不新增菜单权限配置，不调整现有角色授权
• 若接口因权限或其他原因请求失败，前端仍统一按“暂无企业信息”处理

因此本次方案仍按纯前端页面改造收口，不扩展为权限链路改造需求。

7. 数据口径设计

7.1 查询口径

企业详情查询只允许按统一信用代码命中：

• 查询字段固定为 supplierUscc
• 不按 supplierName 查询
• 不做统一信用代码查询失败后的名称兜底

7.2 展示字段

企业详情弹窗展示字段与“实体库管理”页面现有详情弹窗保持同口径，展示全部现有详情字段：

• 统一社会信用代码
• 企业名称
• 企业类型
• 企业性质
• 行业分类
• 所属行业
• 成立日期
• 注册地址
• 法定代表人
• 法定代表人证件类型
• 法定代表人证件号码
• 经营状态
• 风险等级
• 企业来源
• 数据来源
• 创建时间
• 股东1
• 股东2
• 股东3
• 股东4
• 股东5

8. 前端实现设计

8.1 状态设计

在 ccdiPurchaseTransaction 页面内新增企业详情查看状态：

• enterpriseDetailOpen：企业详情弹窗开关
• enterpriseDetailLoading：企业详情请求中状态
• enterpriseDetailData：企业详情数据对象

8.2 行为设计

点击供应商行“详情”按钮时，执行以下流程：

1. 读取当前供应商行 supplierUscc
2. 若为空，则直接提示“暂无企业信息”
3. 若不为空，则置 enterpriseDetailLoading = true
4. 调用 getEnterpriseBaseInfo(supplierUscc)
5. 请求成功且返回有效详情数据时：
   • 写入 enterpriseDetailData
   • 打开 enterpriseDetailOpen
6. 请求失败、接口返回空数据或记录不存在时：
   • 不打开详情弹窗
   • 统一提示“暂无企业信息”
7. 请求结束后恢复 loading 状态

8.3 关闭设计

企业详情弹窗关闭时清空本次详情数据，避免下一次打开时短暂残留上一次企业信息。

9. 错误处理设计

错误处理口径统一如下：

• 供应商没有统一信用代码：提示“暂无企业信息”
• 统一信用代码存在但实体库查不到：提示“暂无企业信息”
• 接口请求失败：提示“暂无企业信息”
• 接口因权限校验失败：提示“暂无企业信息”

本次不区分“缺失统一信用代码”“企业不存在”“接口异常”“接口权限失败”四类用户提示文案，统一收敛为同一提示，避免页面出现多套业务语义。

10. 测试设计

10.1 验证范围

本次为纯前端改动，复用现有后端详情接口，因此后续实施阶段只需要输出前端实施计划，不需要新增后端实施计划。

10.2 核心验证场景

• 供应商有统一信用代码，且实体库存在对应企业时，点击“详情”能打开企业详情弹窗并展示完整字段
• 供应商没有统一信用代码时，点击“详情”提示“暂无企业信息”
• 供应商有统一信用代码但实体库不存在对应企业时，点击“详情”提示“暂无企业信息”
• “详情”按钮固定显示，不因实体库权限做前端显隐控制
• 关闭企业详情弹窗后，再查看另一家供应商时，不残留上一家企业详情数据

10.3 测试执行要求

• 前端相关命令执行前，先通过 nvm use 切换项目 Node 版本
• 使用真实业务页面进行浏览器验证，不使用 prototype 页面
• 验证结束后关闭测试过程中启动的前端进程和浏览器进程

11. 实施文档要求

由于本次需求只涉及前端改动，实施阶段只输出一份前端实施计划，保存到：

• docs/plans/frontend/

实施完成后补充一份实施记录，优先保存到：

• docs/reports/implementation/

12. 最终结论

本次采用“前端页面最小改造 + 复用实体库现有详情接口”的方案，在不新增后端链路、不引入名称兜底查询、不扩展页面职责的前提下，为招投标详情弹窗中的供应商明细补充企业详情查看能力。

该方案满足以下约束：

• 只按统一信用代码查询
• 查不到统一提示“暂无企业信息”
• 查到后通过弹窗展示实体库全部字段
• 保持实现路径最短，不引入超出需求范围的扩展设计