docs(changelog): 团期「查看需求」Tab 缺失清单改显团号、需求状态列漏看车侧缺失（前端缺陷，交 mmg）

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-24 09:52:37 +08:00
@@ -0,0 +1,114 @@
+---
+schema: hl-changelog/v2
+ticket: "frontend"
+title: "「查看需求」Tab 缺失清单改显团号、需求状态列漏看车侧缺失"
+consumer: admin
+author: "wx(GIT)"
+change_type: "前端缺陷"
+backend_status: "not_required"
+gateway_status: "not_required"
+frontend_status: "pending"
+frontend_owner: "mmg"
+frontend_ref: ""
+target_release: "v2.1"
+verified_at: ""
+status_note: "2026-09-24 发现两处前端缺陷，均不涉及后端改动。①顶部缺失清单用订单号标识户，应改为团号（团号已由接口 GroupBatchOrderItemRespVO.teamNo 提供）；②需求状态列只判住宿缺失，未考虑车侧缺失导致「住宿不缺但车侧缺」的户显示「已齐备」不符实。两项改动的数据来源均已在现有接口提供，后端零改动。"
+updated_at: "2026-09-24"
+base: dev-v3
+---
+
+# 「查看需求」Tab：缺失清单用订单号改为团号、需求状态列漏看车侧缺失
+
+> **页面**: 管理后台 → 团期详情 → 「查看需求」Tab
+> **文件**: `src/views/order-v2/batch/detail/components/RequirementTab.vue`（hl-ui `v2.1` 分支，读的是 commit `04e08d1a9ddb`）
+> **日期**: 2026-09-24
+> **影响范围**: 前端。所有团期所有用户
+
+---
+
+## 一、问题 1：顶部缺失清单用订单号标识户，应改为团号
+
+### 现象
+
+顶部「仍有子订单需求缺失，暂不能整团确认」提示框内，三处缺失列表用订单号标识每户：
+
+| 列表 | 渲染字段 | 代码行 |
+|---|---|---|
+| 住宿缺失 | `missingItems` 渲染 `m.orderNo \|\| String(m.orderId)` | 约第 102 行 |
+| 车侧缺失 | `vehicleMissingItems` 渲染 `v.orderNo` | 约第 114-117 行 |
+| 接送机缺口 | `transferGapItems` 渲染 `t.orderNo \|\| String(t.orderId)` | 约第 138 行 |
+
+实例：测试服团期「第3期 10月8日出发团」，户「王二麻子」在这些列表显示为 `HL20260922161158291`（订单号），但下方名单表同一户显示为 `26-2355`（团号）。
+
+### 修法
+
+统一改为显示**团号**，与下方名单表一致。
+
+数据来源：同页名单表每行（接口 `GroupBatchOrderItemRespVO`）已带 `teamNo` 字段（团号，来自 `order_main.team_no`；**订金支付成功后生成，未付订金为 null**）。按 `orderId` 在名单行中查找对应 `teamNo`。
+
+**兜底规则**：
+- `teamNo` 为 null（未付订金的户）或名单里查不到该 orderId 时，回落现有显示（订单号）
+- 整团级车侧条目（`orderNo`/`orderId` 为空，例「团期「第3期 10月8日出发团」尚未形成正式用车需求」）保持现状，不加户标识
+
+### 验证
+
+现有接口数据已足够，后端零改动。
+
+---
+
+## 二、问题 2：需求状态列只看住宿缺失，车侧缺失的户显示「已齐备」
+
+### 现象
+
+名单表「需求状态」列（`key: 'requirementStatus'`，约第 854-876 行）自相矛盾：
+
+实例：同一团期户「王二麻子」（团号 26-2355）
+- 「需求审核」列显示「车 未提交」
+- 顶部提示框列出「该户尚未提交行程用车需求，请先让定制师提交后再整团提交车务」（后端码 809122）
+- 但「需求状态」列却显示绿色「已齐备」
+
+### 根因
+
+「需求状态」列的判定逻辑只查 `missingMap`（由住宿侧 `checkResult.missing` 建立，约第 469 行），而 `checkResult.vehicleMissing` 完全未参与。
+于是「住宿不缺但车侧有缺」的户落到「预检已加载且不在缺失清单」分支，错误显示「已齐备」。
+
+### 修法
+
+判「已齐备」必须同时满足：
+1. 不在住宿 `missing` 里（现有逻辑）
+2. `vehicleMissing` 里没有 `orderId` 等于本户的条目（新增，字符串比较）
+
+**显示规则**：
+- 车侧命中时显示红色缺失标签，文案用该条目的 `detail` 字段（后端返回的人话，与整团确认时报错逐字相同，可直接展示）
+- 同一户车侧可能有多条条目（后端「全部列出、不按户合并」），显示第一条即可，或自行决定合并方式
+- 住宿与车侧都命中时两类缺失都要能看出来
+- 整团级车侧条目（`orderId` 为空）不归到任何一户，不影响每户这一列（它已在顶部提示框单独展示）
+
+### 后端契约
+
+`GroupBatchRequirementCheckRespVO.VehicleMissingItem` 各字段：
+- `reason`：缺失原因编码（本例为 `HOUSEHOLD_REQUIREMENT_NOT_SUBMITTED`）
+- `groupCode`：涉及的乘车分组编码（如 `BUS`），无分组维度时为 null。**注意它不是团号**，团号只在名单行的 `teamNo`
+- `tripDate`：涉及的日期，无日期维度时为 null
+- `orderId`：涉及的子订单 ID，为空表示整团级条目
+- `orderNo`：子订单号快照
+- `detail`：人话描述，与整团确认时报错逐字相同，可直接展示
+
+后端零改动。
+
+### 测试覆盖
+
+`__tests__/RequirementTab.spec.js` 现有测试（第 139-140 行、529-530 行）只喂了住宿侧数据，修后建议补一条用例：「住宿不缺但车侧有本户条目 → 不显示已齐备」。
+
+### 验证
+
+现有接口数据已足够，后端零改动。
+
+---
+
+## 三、业务边界
+
+- **两项均不依赖后端改动**。修法所需数据已由现有接口提供（名单表 `teamNo`、`vehicleMissing` 字段）
+- **问题 1**：团号为 null（该户未付订金）时回落订单号，所以同一提示框里可能同时出现团号和订单号，属预期
+- **问题 2**：只影响「需求状态」列的显示；「整团确认需求」按钮是否可点仍以接口 `ready` 为准，前端不要自己重算
+- 后端有三条错误报文（809121 / 809112 / 809114）的 `msg` 里仍拼着订单号或雪花 ID，已另开后端工单 wx/HL#8306 改成团号；前端直接展示 `msg`，不需要为此改代码