diff --git a/changelogs-v2/2026-09/13_7439_团期车务地基-用车需求分家-修改接口-管理后台.md b/changelogs-v2/2026-09/13_7439_团期车务地基-用车需求分家-修改接口-管理后台.md index 4bad95c5..6b5b9478 100644 --- a/changelogs-v2/2026-09/13_7439_团期车务地基-用车需求分家-修改接口-管理后台.md +++ b/changelogs-v2/2026-09/13_7439_团期车务地基-用车需求分家-修改接口-管理后台.md @@ -78,7 +78,7 @@ base: "dev-v3" | 字段 | 位置 | 类型 | 必填 | 约束 | 说明 | |------|------|------|------|------|------| | id | Path | Long | ✅ | - | 订单 ID | -| kind | Body | String | ❌ | TRAVEL/TRANSFER | 需求类型，默认 TRAVEL；非法值实际返 400（Bean Validation 拦截，不是 809000，见下方错误响应说明） | +| kind | Body | String | ❌ | TRAVEL/TRANSFER | 需求类型，不传按 TRAVEL 处理（**建议显式传**，理由见六.7 影响评估）；非法值实际返 400（Bean Validation 拦截，不是 809000，见下方错误响应说明） | | fleet | Body | List | ✅ | @NotEmpty | 车型配置，两类需求都必填 | | pickupRequired | Body | Boolean | ❌ | - | 需接机 | | dropoffRequired | Body | Boolean | ❌ | - | 需送机 | @@ -691,7 +691,9 @@ GET /v3/admin/order/60123456789013/settlement/step3/vehicles | 错误码 | 触发条件 | 🖐 前端该怎么处置 | |--------|----------|------------------| | **809000** | `kind` 传了 TRAVEL / TRANSFER 之外的值 | 参数错误，按常规表单校验处理；正常调用不该出现 | +| **809001** | 同一订单**同一 kind** 已存在活跃需求时又提交了一条（重复提交 / 并发双击） | ⚠️ **不要自动重试**——只要那条活跃需求还在，重试永远是这个码。提示「该订单已有进行中的用车需求」并引导去看板刷新确认；需求被打回或完成后才能再提 | | **809002** | 提交 `TRANSFER`，但该单**大交通信息为空**，服务日派生不出来 | ⚠️ **不要提示「参数错误」或「稍后重试」**——这是数据缺口，必须给「**先去补大交通**」的引导，最好直接给一个跳到大交通填写页的入口。重试不会变好，补完大交通再提交才会好 | +| **809007** | 接送机需求的 `service_dates` 为空时被下游消费（存量迁移行未回填即被取用） | **前端拿不到这个码**——它在 `/v3/internal` 链路上由 fleet 侧触发，不经 `/v3/admin`。列在这里是为了错误码段位完整，以及说明它与 809002 的分工：**809002 = 提交时派生不出来**（前端可引导补大交通），**809007 = 提交时没派生、事后被消费**（属存量数据回填问题，需后端处理，前端无动作）。详见内部接口分册端点 3 | | **809008** | 该单**两类活跃需求并存**时，手录车费行没指定 `requirementKind` | 表单必填校验漏了；把该字段做成必选（两类并存时）即可 | | **809009** | 提交 `kind=TRANSFER`，而开关 `hl.order.requirement.transfer-kind-submit-enabled` **仍是默认的 false** | ⚠️ **按「功能未开放」提示**（例如「接送机需求提交尚未开放」），**不得**按参数错误处理、**也不得**提示「稍后重试」——开关不开，重试多少次都是这个码。本单交付时该开关就是关的，所以这是**当前的正常返回**，不是故障 | @@ -726,7 +728,7 @@ GET /v3/admin/order/60123456789013/settlement/step3/vehicles ## 六.7、影响评估 -- **向后兼容性**：部分。不传 kind 时按 TRAVEL 处理，但双需求时手录行必须指定 +- **向后兼容性**：部分。不传 kind 时服务端按 `TRAVEL` 处理，**现网代码可以不改**；但**建议 hl-ui 一律显式传 kind**——一旦该订单出现两类活跃需求，「不传」的语义就从「就是行程用车」变成了「碰巧落到行程用车上」，而这两者在代码里长得一模一样。双需求时手录行的 `requirementKind` 则是**必须**指定（缺失返 809008） - **前端同步上线**：是 ---