hl-api-changelog/changelogs-v2/2026-10/03_8578_接送机派车行按航班日自动置接送标志-修复-管理后台.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	8578	接送机用车需求派车时按航班日自动置接送标志，主路径派齐后最终方案可发布；接口契约不变	admin	wx(GIT)	修复	deployed	verified	not_required					接口路径、入参、出参、错误码均不变；变化的是接送机（TRANSFER）用车需求经派车接口建派单行时，接机日、送机日的派单行由后端自动标为接机车、送机车，主路径派齐后接送机门禁可以满足、最终方案可以发布。	2026-10-03	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
• PR: wx/HL#8595
• 后端：@wx