---
schema: "hl-changelog/v2"
ticket: "8578"
title: "接送机用车需求派车时按航班日自动置接送标志，主路径派齐后最终方案可发布；接口契约不变"
consumer: "admin"
author: "wx(GIT)"
change_type: "修复"
backend_status: "deployed"
gateway_status: "verified"
frontend_status: "not_required"
frontend_owner: ""
frontend_ref: ""
target_release: ""
verified_at: ""
status_note: "接口路径、入参、出参、错误码均不变；变化的是接送机（TRANSFER）用车需求经派车接口建派单行时，接机日、送机日的派单行由后端自动标为接机车、送机车，主路径派齐后接送机门禁可以满足、最终方案可以发布。"
updated_at: "2026-10-03"
base: "dev-v3"
---

# 车务派车：接送机派车行按航班日自动置接送标志

> **服务**: hl-fleet-service
> **关联 Issue**: #8578
> **关联 PR**: #8595（合并提交 0f19f383fa）
> **部署状态**: 测试环境已部署并经网关实测，见「五、实测验证」
> **影响范围**: 管理后台车务派车（单派 `POST /admin/fleet/assignments`、批派 `POST /admin/fleet/assignments/batch`）之后的接送机门禁与最终方案发布结果——不改任何请求或响应字段

---

## ⚠️ 关键变化

- **以前**：派车接口建派单行时，接送标志（接机车 / 送机车）一律写 0。接送机订单只走「派车 → 确认」主路径时，接送机门禁结构性无法满足，批派响应恒为 `finalPlanPublished=false`、`finalPlanNotPublishedReason=GATE_UNSATISFIED`，只能再去第③步「接送机配置」手工勾选才放行。
- **现在**：接送机（TRANSFER）用车需求的派单行，服务日是大交通声明的接机日则自动标为接机车，是送机日则自动标为送机车。接机日、送机日都派了车，门禁即满足，最终方案在派车这一步就能发布。
- **前端无需改代码**：请求体、响应结构、错误码都没变。

---

## 一、背景

接送机门禁要求大交通声明的每个接机日都有接机车、每个送机日都有送机车。门禁读的是派单行上的接送标志，而派车接口建行时从不置这两个标志，所以门禁在主路径上永远不满足，最终方案永远不发布。

---

## 二、后端改动

- 建派单行的入口 `AssignmentService#doCreateInLock` 在逐日建行时，按该行服务日置接送标志。单派与批派都经过这个入口。
- 接机日、送机日两个日期集直接取自门禁判定用的 `PickupDropoffGateResolver`，建行口径与门禁口径同源，不会出现「建行认为是接机车、门禁不认」的分叉。
- 只对 TRANSFER 用车需求自动置位。TRAVEL（旅游）用车需求的某个行程日不一定是航班日，系统不做推断，派单行仍写 0，与改前一致。

---

## 三、对前端的影响

### 可观察到的行为变化

- 接送机订单在派车向导里把接机日、送机日都派上车后，批派响应 `finalPlanPublished=true`，`pickupDropoffGate.satisfied=true`，不需要再进第③步手工勾选。
- 只派了接机日、没派送机日时，门禁按设计仍不满足：`finalPlanPublished=false`、`finalPlanNotPublishedReason=GATE_UNSATISFIED`，缺的日期列在 `pickupDropoffGate.missingDropoffDates`（或 `missingPickupDates`）里。补派缺的那一天即可。
- 订单「确认核对清单」的用车项（`VEHICLE_DONE`）随门禁满足变为通过。

### 字段口径（均未变化）

批派响应的 `finalPlanPublished`、`finalPlanNotPublishedReason`、`pickupDropoffGate`（`arrivalRequiredDates`、`departureRequiredDates`、`missingPickupDates`、`missingDropoffDates`、`declared`、`satisfied`）都是既有字段，含义不变。

---

## 四、覆盖范围与边界

- **只影响修复部署后新建的派单行**。已经存在的派单行，接送标志保持原值。需要改的，仍在第③步用 `PUT /admin/fleet/assignments/pickup-dropoff-config` 调整。该接口行为不变：在门禁已满足的订单上按相同取值再提交一次，返回成功，`finalPlanPublished=true`，`requirementReopened=false`。
- **TRAVEL 订单零变化**：无接送机声明时 `pickupDropoffGate.declared=false`、`satisfied=true`，最终方案照常发布。
- **派车弹窗两种进入方式提交的日期范围不同**：按日格进入只提交该日，按车辆槽位统一选择提交整段日期（hl-ui `v2.1` 分支 `AssignModal.vue`）。只按日格派了接机日时，门禁显示缺送机日属于正常结果，不是前端提交形状的缺陷。

---

## 五、实测验证（测试环境）

2026-10-03，测试服 hl-fleet-service 部署提交 `89c87fd21`（已包含修复提交 `0f19f383fa`），经网关实测：

| 场景 | 结果 |
|------|------|
| 接送机订单（接机日 2027-05-10、送机日 2027-05-15），只走「派车 → 确认」主路径，不调接送机配置 | 批派响应 `finalPlanPublished=true`，`pickupDropoffGate.satisfied=true`，`missingPickupDates`、`missingDropoffDates` 均为空 |
| 同一订单 `GET /v3/admin/order/{orderId}/confirm-checklist` | `VEHICLE_DONE` 为 `passed=true` |
| 阴性对照：只派接机日（2027-06-10），没派送机日（2027-06-16） | `finalPlanPublished=false`，`finalPlanNotPublishedReason=GATE_UNSATISFIED`，`missingDropoffDates=["2027-06-16"]` |
| 门禁已满足后，按相同取值再调 `PUT /admin/fleet/assignments/pickup-dropoff-config` | `finalPlanPublished=true`，`requirementReopened=false` |
| TRAVEL 订单同批次对照 | `pickupDropoffGate.declared=false`、`satisfied=true`，`finalPlanPublished=true` |

---

## 关联

- Issue: [wx/HL#8578](https://git.1814.love/wx/HL/issues/8578)
- PR: [wx/HL#8595](https://git.1814.love/wx/HL/pulls/8595)
- 后端：@wx