---
schema: "hl-changelog/v2"
ticket: "7607"
title: "供应商审批记录改按审批链推进显示并修正或签审批人"
consumer: "admin"
author: "lc(GIT)"
change_type: "修改接口"
backend_status: "deployed"
gateway_status: "verified"
frontend_status: "not_required"
frontend_owner: "mmg"
frontend_ref: ""
target_release: ""
verified_at: ""
status_note: "PR #7610 已合并 dev-v3，合并提交 ca8a825ec 由部署任务 96c7e363（User）与 ba727055（Resource）精确发布到 TEST 并经真实 Gateway 验证。本条更正 #7587：statusChangeText 的语义由供应商生命周期流转改为审批链推进，字段名与结构不变；同时修正或签节点的审批人、审批意见与完成时间。 前端实证 no-op（2026-09-13, mmg）：SupplierApprovalRecordsModal.vue:232 状态变化列 render 纯透传 statusChangeText 不解析不映射，口径变更自动生效；前端零引用 statusBefore/statusAfter（仅 #7587 注释提及），编码值域扩 L{级数}_{结果} 无影响；approverName/opinion/finishedAt 字段名/类型不变，已 || EMPTY 兜底直显。无业务改动，回写 not_required。"
updated_at: "2026-09-13"
base: "dev-v3"
---

# 供应商审批记录改按审批链推进显示并修正或签审批人

供应商详情「审批记录」列表的状态列改为表达**这一行审批推进了哪一步**，并修正或签节点把候选人记成审批人的缺陷。字段名、类型与响应结构均不变。前端（hl-admin e3ff8510）已在「动作」列后直显 `statusChangeText`，本次口径变更后该列自动显示新文案，**无需前端改代码**。

## 变更接口

| 方法 | 路径 | 行为变化 |
|---|---|---|
| GET | `/admin/supplier/items/{supplierId}/approval-history/page` | `statusBefore`、`statusAfter`、`statusChangeText` 取值口径变更；或签场景下 `approverName`、`opinion`、`finishedAt` 取值修正 |

## 一、状态列改为审批链推进（更正 #7587）

#7587 发布的是供应商生命周期流转（建档行「草稿 → 合作中」、拉黑行「暂停合作 → 黑名单」）。**该口径已作废**，现在这一列表示审批链推进：

| 场景 | statusChangeText | statusBefore | statusAfter |
|---|---|---|---|
| 建档审批第 1 级通过 | `草稿 → 1级通过` | `DRAFT` | `L1_APPROVED` |
| 第 2 级审批中 | `1级通过 → 2级审批中` | `L1_APPROVED` | `L2_PENDING` |
| 第 2 级通过 | `1级通过 → 2级通过` | `L1_APPROVED` | `L2_APPROVED` |
| 第 2 级驳回 | `2级驳回 → 草稿` | `L2_REJECTED` | `DRAFT` |
| 资料变更审批第 1 级通过 | `合作中 → 1级通过` | `ACTIVE` | `L1_APPROVED` |
| 资料变更审批第 1 级驳回 | `1级驳回 → 合作中` | `L1_REJECTED` | `ACTIVE` |
| 拉黑审批第 1 级通过 | `暂停合作 → 1级通过` | `SUSPENDED` | `L1_APPROVED` |

取值规则：

- **起点**：第 1 级为提交审批时的供应商状态；第 2 级起为上一级通过（能到达第 N 级即前 N-1 级都已通过）。驳回、撤销、建单失败行的起点是本级结果本身。
- **终点**：通过与在途行为本级结果；驳回、撤销、建单失败行为退回后的实际供应商状态——建档审批退回 `DRAFT`，资料变更与状态变更审批不改变状态，写回提交时的状态。
- **编码**：供应商状态端沿用 `DRAFT`/`VETTING`/`ACTIVE`/`SUSPENDED`/`BLACKLIST`/`ARCHIVED`；审批节点端为 `L{级数}_{该级结果}`，结果取 `APPROVED`/`PENDING`/`REJECTED`/`CANCELED`/`FAILED`，层级不可用的历史记录级数记 `0`。
- **中文措辞**与「层级」列一致（去掉「第」字），因此资料变更在途显示「1级审核中」而非「审批中」；本地自动审批、建单失败等没有层级的记录沿用其兜底文案，如「草稿 → 系统自动通过」「建单失败 → 草稿」。
- 任一端无法判定（历史状态快照缺失或不是已知状态）时，`statusChangeText` 为 `—`，两个编码字段为 `null`。
- 该列表达的是审批推进，与审批结论无关；审批结论仍看 `approvalStatusName`。

## 二、或签节点记录实际审批人

企微或签节点会列出全部候选成员，此前后端固定取候选列表第一位，导致：

- `approverName` 显示未曾操作的候选人（例如第 2 级实际由王骁通过，却显示金卫）；
- `opinion` 取到该候选人的空意见；
- `finishedAt` 因候选人 `sptime` 为 0 而返回 `null`。

现在取该节点实际完成操作的成员（会签取最后完成的一位），三者同步修正；节点整体仍在审批中、无人操作时维持原有展示。

**历史数据不回填**：已落库的审批详情快照保持原样，修复只对之后同步的审批生效；仍在途的审批会在下次拉取企微详情时自动纠正。

## 管理端接入事项

1. 该列直接展示 `statusChangeText`，不需要前端拼接箭头或翻译编码；字段始终有值。
2. 需要筛选或着色时用 `statusBefore`/`statusAfter` 编码，注意值域现在包含 `L{级数}_{结果}` 形式，不再只是供应商状态编码。
3. 审批人、审批意见、完成时间的字段与类型不变，或签场景下取值会与修复前不同，属于预期修正。

## 兼容性与未变化范围

- 字段名、JSON 类型、分页、排序、筛选参数与响应结构完全不变，前端无需改调用代码。
- 不新增接口、请求参数、业务错误码、Gateway 路由或权限点。
- 不修改数据库数据与表结构，不新增 migration，不回填历史快照。
- 不改变审批链路、状态机、企微提交与回调写入逻辑，也不影响变更记录接口与账户审批展示。
- 不修改配置、Redis、MQ 或跨服务写契约。