---
schema: "hl-changelog/v2"
ticket: "5899"
title: "修复改订单人数后车务未重走配车——换版后自动重新盖章抵消作废定稿"
consumer: "admin"
change_type: "修复"
author: "wx(GIT)"
backend_status: "deployed"
gateway_status: "not_required"
frontend_status: "not_required"
frontend_owner: "mmg"
frontend_ref: ""
target_release: ""
verified_at: "2026-08-12"
status_note: "后端已修复并部署测试服，API 实测通过。修改订单人数/车型等（服务日期窗不变）的换版后，车务看板正确回到「待派车」，订单侧停留在「待配」，不再被自动拉回「配车完成」；车务重新确认后订单正常推进。改行程天数/改出发日期不受影响。"
updated_at: "2026-08-12"
base: "dev-v3"
---

# 修复：改订单人数后车务未重走配车——换版后自动重新盖章抵消作废定稿（#5899）

> **服务**: hl-fleet-service
> **PR**: #5903（已合并 dev-v3 并部署测试服）
> **日期**: 2026-08-12
> **背景**: 订单修改人数后，订单侧短暂显示「待配」又立刻回到「配车已完成」，车务侧看板没有重走配车流程，仍保持「配车完成」，待派车 tab 无此单。

---

## 修复内容（对前端透明，无接口契约变化）

**根因**：`AssignmentService.expandFromRequirementInTransaction` 换版时同事务内先后执行两个互相矛盾的动作：

1. `invalidateDispatchPlanForMigratedRows`（#5851）换版平移后作废定稿——清 `dispatch_plan_finalized`/`dispatch_plan_generation`，意图让车务重走配车。
2. `publishDailySnapshotIfComplete`（#5810）紧接着发现「行都 assigned 且无 finalized」→ 走 `markDispatchPlanGeneration` **自动重新盖章**（finalized=1、归属=新需求）→ 发 `DailyVehicleSnapshotChangedEvent.finalPlan` → 订单被拉回 `VEHICLE_DONE`。

**修复**：`publishDailySnapshotIfComplete` 检测到归属旧需求的陈旧定稿行时（`hasStaleFinalizedPlanRows` 命中）直接返回，不自动盖章/发 finalPlan。车务 confirm 时归属被重新盖成当前需求，守卫自然放行，闭环保留。

**影响范围**：仅服务日期窗不变的换版（改人数/车型/座位）。改行程天数/改出发日期时日期校验本就返回 false，不误触发。

## 行为变化

| 场景 | 旧 | 新 |
|---|---|---|
| 改人数后（服务窗不变） | ❌ 看板停留「配车完成」，订单误拉回 DONE，车务没机会重走配车 | ✅ 看板回到「待派车」，订单停留「待配」，等车务重新确认 |
| 车务重新确认 | ✅ 正常盖章并推进订单 | ✅ 不变（守卫放行） |
| 改行程天数/改出发日期 | ✅ 正常 | ✅ 不变 |

## 验证证据（测试服 API 实测，订单 2086270141158346754）

修改订单人数（10→11）后实测：

- 需求换版 v4，`status=PENDING`（不再自动拉回 DONE）
- fleet 派单行 `dispatch_plan_finalized=0`、`plan_finalized_requirement_id` 保留旧 v3（归属证据）
- 车务看板卡片：`finalizedByFleet=False`、`staleFinalizedPlan=True` → 「待派车」tab
- 订单侧 VEHICLE：`PROCESSING 待配 | 配车待配`（不再误显示「配车已完成」）

后端 PR #5903 已合并 dev-v3 并部署测试服，fleet-service 健康。前端无改动，无需联调。