hl-api-changelog/changelogs-v2/2026-09/13_7607_供应商审批记录改按审批链推进显示并修正或签审批人-修改接口-管理后台.md

schema, ticket, title, consumer, author, change_type, backend_status, gateway_status, frontend_status, frontend_owner, frontend_ref, target_release, verified_at, status_note, updated_at, base

schema	ticket	title	consumer	author	change_type	backend_status	gateway_status	frontend_status	frontend_owner	frontend_ref	target_release	verified_at	status_note	updated_at	base
hl-changelog/v2	7607	供应商审批记录改按审批链推进显示并修正或签审批人	admin	lc(GIT)	修改接口	deployed	verified	not_required	mmg				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。	2026-09-13	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 或跨服务写契约。