66 行
5.5 KiB
Markdown
66 行
5.5 KiB
Markdown
---
|
||
schema: "hl-changelog/v2"
|
||
ticket: "frontend-fleet-step4-confirm-continuity-sms"
|
||
title: "确认执行页 2 问题：①车辆接续只显示第一段车/师傅 ②「不发送短信」口径澄清（仅控制确认后行程短信）"
|
||
consumer: "admin"
|
||
author: "wx(GIT)"
|
||
change_type: "前端缺陷"
|
||
backend_status: "not_required"
|
||
gateway_status: "not_required"
|
||
frontend_status: "implemented"
|
||
frontend_owner: "mmg"
|
||
frontend_ref: "6709c157"
|
||
target_release: ""
|
||
verified_at: ""
|
||
status_note: "前端已实现：①Step4Confirm 新增 assignments prop（父层 confirmationAssignments），多段时遍历渲染每段「服务日期段+车辆+师傅」（confirmationSegments+segmentDateLabel，逐日 serviceDates 优先回退 startDate~endDate），单段/无接续回退单数 prop 旧行为不破；AssignModal 传 :assignments。②「不发送短信」提示改「仅不发送确认后的行程短信，派单通知短信仍会发送」。step4-confirm.spec 补 3 回归用例 5/5 过 + checkpoint 精确文件集全过。"
|
||
updated_at: "2026-08-10"
|
||
base: "dev-v3"
|
||
generated: "2026-08-10T10:20:00+08:00"
|
||
---
|
||
|
||
# 确认执行页 2 问题：车辆接续只显示第一段 + 「不发送短信」口径澄清
|
||
|
||
> 前端缺陷，后端能力已具备、无需改后端。待前端修复。
|
||
|
||
## 场景（车辆接续，订单 26-6436 周梦洁，order_id=2086270156475936769）
|
||
|
||
一个车辆槽位在多天内由不同车辆/司机接续服务：
|
||
- 8/23：蒙A-E2E01 道尔吉（driver_id=2065272150012444674，vehicle_id=2085284111341023234）
|
||
- 8/24~8/25：蒙A-E2E99 王信（driver_id=2067084362829979650，vehicle_id=2085539421276286978）
|
||
|
||
## 问题①：确认执行页「车·师傅」只显示第一段
|
||
|
||
**现象**：「车·师傅」只显示 蒙A-E2E01/道尔吉（第一段），没显示王信（第二段）；但「行程短信」行写「全部 2 个执行段·必选」（系统知道有 2 段）。
|
||
|
||
**定位（前端）**：`Step4Confirm.vue` 的 `vehicle`/`driver` 是**单数 prop**，父组件 `AssignModal.vue` 传入 `selVehicleObj`/`selDriverObj`（`useVehicleDriverPicker` 的当前活动槽位选中快照），模板只用 `vehicle?.plate`/`driver?.name` 渲染 1 组。**逐日车费同源**：`dailyVehicleFees` ref 由 `applyVehicleFeeDraft(assignment.dailyVehicleFees)` 填充，同样只取**活动槽位单段** assignment 的逐日费用——26-6436 只显示 8/23 ¥1000，缺 8/24-25 王信段（¥1000×2），最终总车费只 ¥1000。
|
||
|
||
**后端数据完整（已核实，无需后端改动）**：
|
||
- `GET /admin/fleet/board/orders/2086270156475936769` 的 `activeAssignments`（List\<CurrentAssignmentVO\>）返回**全部有效派车组**，每组含 vehiclePlate/vehicleModel/vehicleSeats/driverName/driverPhone（BoardOrderDetailVO 字段已核实）；
|
||
- `dailyVehiclePlan` 正确返回全部 2 车 2 司机（8/23 蒙A-E2E01/道尔吉 + 8/24-25 蒙A-E2E99/王信）。
|
||
|
||
**期望**：确认执行页遍历全部执行段（`confirmationAssignments`/`activeAssignments`）展示多段「车辆+师傅」以及**各段逐日车费与合计**（后端每段均返回 `dailyVehicleFees` 全部服务日快照 + `vehicleFeeTotal`），车务能核对完整执行信息与完整车费。
|
||
|
||
## 问题②：选「不发送短信」确认后司机仍收到短信——口径澄清
|
||
|
||
**定位（前后端逻辑均正确，非缺陷，建议前端补提示文案）**：
|
||
|
||
| 事实 | 证据 |
|
||
|------|------|
|
||
| 前端确认时实传 sendItinerarySms | 8/10 09:09 最终确认（王信 8/24-25 转 assigned）落库 `fleet_assignment.itinerary_sms_decision=0`；8/9 15:10 起历次确认均为 0 —— 前端传值正确 |
|
||
| 后端拦截正确 | decision=0 的确认均未创建 ITINERARY_SMS outbox 事件；全订单仅 1 条 ITINERARY_SMS 事件（event_id=2086286779542855682，8/9 11:01:44 创建、12:43 处理成功）对应 8/9 11:01 首次确认（decision=1，当时选择了发送短信） |
|
||
| 用户「仍收到短信」的真实来源 | ① 派单通知短信 `FLEET_DISPATCH_CREATED`（模板 SMS_510265061，**与行程短信同模板**）：由派单/改派 HOLD_NOTIFICATION 触发，派单时必发，不受 sendItinerarySms 控制——8/10 09:09:09 王信、09:22:39 道尔吉均在「不发送短信」确认（09:09:27）前后收到；② 8/9 11:01 首次确认（选择了发送短信）已发出的行程短信（12:32 发送），后取消改派无法撤回 |
|
||
|
||
**结论**：「不发送短信」只控制**确认后创建的行程短信事件**（FLEET_ITINERARY_READY），**不控制派单通知短信**（FLEET_DISPATCH_CREATED，派单时必发）。验收项「选不发送短信确认后不创建/不发送行程短信事件」在现行代码与 DB 事实下已成立。
|
||
|
||
**建议前端**：确认执行页选择「不发送短信」时提示「仅不发送确认后的行程短信，派单通知短信仍会发送」，避免车务误解。
|
||
|
||
## 变更接口
|
||
|
||
- 无后端接口变化。
|
||
|
||
## 验证证据
|
||
|
||
- DB 实证（TEST hl_fleet_service）：`fleet_assignment` 全史 16 行，itinerary_sms_decision 仅首次确认=1，其余全部=0；`fleet_assignment_insurance_outbox` 全史仅 1 条 ITINERARY_SMS（首次确认创建，SUCCESS）。
|
||
- DB 实证（TEST hl_user_service）：`notification_send_log` 仅 1 条 FLEET_ITINERARY_READY（8/9 12:32 发王信 185\*\*\*\*2756，status=0）；8/10 09:09/09:22 两条为 FLEET_DISPATCH_CREATED（派单短信）。
|
||
- 源码核实：`AssignmentService.confirmRequirement`/`confirm` 均 `if (sendItinerarySms)` 才 `writeItinerarySms`；`BoardOrderDetailVO.activeAssignments` 返回全部执行段。
|