docs(changelog): 车务§13.5未派看板数据打通(#4284/4286/4295)+车辆VIN错误码600107→600113(#4279) — 管理后台
这个提交包含在:
父节点
1e9f9ad881
当前提交
79468ab61f
@ -0,0 +1,37 @@
|
||||
# 车辆档案: VIN 重复错误码 600107 → 600113
|
||||
|
||||
> **服务**: hl-fleet-service
|
||||
> **PR**: #4279
|
||||
> **Issue**: #4278
|
||||
> **日期**: 2026-06-23
|
||||
> **影响范围**: 管理后台 · 车辆管理(新增/编辑车辆时 VIN/车架号重复校验)
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 关键变化
|
||||
|
||||
新增/编辑车辆时**车架号(VIN)已存在**的业务错误码,从 **600107** 改为 **600113**(message 不变,仍为「车架号已存在」)。
|
||||
|
||||
- 以前:VIN 重复返 `code=600107`
|
||||
- 现在:VIN 重复返 `code=600113`
|
||||
- 同时 **600107 现在专指另一含义**:车型「型号已配置价格,不能删除」(`MODEL_HAS_PRICING`)
|
||||
|
||||
**前端只要按 `message` 文案展示则无需改动**(文案没变)。**只有当前端对 `code=600107` 写了特殊分支逻辑时,才需把「VIN 重复」分支改判 `600113`**,否则会把 VIN 重复误判成「型号已配价不能删」。
|
||||
|
||||
---
|
||||
|
||||
## 一、背景
|
||||
|
||||
600107 此前被**两个**业务错误码同 owner(hl-fleet-service)双占:车辆档案的「VIN 重复」与车型库的「型号已配价不能删」。错误码 Registry 不校验同 owner 段内重叠,导致前端拿到 600107 无法区分到底是哪种错误。第 3 轮审计整改:把「VIN 重复」让位下移到车辆档案段下一空闲码 600113,600107 归还车型库专用。
|
||||
|
||||
## 二、变更错误码清单
|
||||
|
||||
| 含义 | 旧 code | 新 code | message | 触发场景 |
|
||||
|------|--------|--------|---------|----------|
|
||||
| VIN/车架号已存在 | 600107 | **600113** | 车架号已存在 | 新增/编辑车辆,VIN 与库内已有车辆重复 |
|
||||
| 型号已配价不能删 | (600107 双占) | 600107(独占) | 型号已配置价格… | 删除车型时该型号已挂价格日历 |
|
||||
|
||||
## 三、前端动作
|
||||
|
||||
- 默认展示后端 `message`:**无需改动**。
|
||||
- 若有针对 `600107` 的特殊 UI 分支:将「VIN 重复」判定改为 `600113`。
|
||||
@ -0,0 +1,37 @@
|
||||
# 车务派单: §7.2「未派看板」数据打通(定制师提用车需求 → 自动出现未派车)
|
||||
|
||||
> **服务**: hl-order-service-v3 + hl-fleet-service
|
||||
> **PR**: #4284 / #4286 / #4295
|
||||
> **Issue**: #4283 / #4285 / #4295
|
||||
> **日期**: 2026-06-23
|
||||
> **影响范围**: 管理后台 · 车管控制台(§7.2 矩阵未派清单 / §7 矩阵甘特)
|
||||
|
||||
---
|
||||
|
||||
## ⚠️ 关键变化(数据打通,**接口契约不变**)
|
||||
|
||||
§13.5 用车需求 → 派单 expand 链路已打通并经测试服真实数据 e2e 验证。**`GET /admin/fleet/matrix/unassigned-orders` 等 §7 看板接口的请求/响应结构没有任何改动**,唯一变化是:**这些接口现在会返回真实的未派车占位数据**(此前因 expand 未接线、看板长期为空)。
|
||||
|
||||
车管控制台可以开始用真实数据联调 §7 矩阵 / §7.2 未派清单了。
|
||||
|
||||
---
|
||||
|
||||
## 一、未派数据怎么产生 / 怎么消失(前端理解数据流即可,无需调用 expand 接口)
|
||||
|
||||
| 触发动作(已有接口) | 结果(§7.2 未派看板) |
|
||||
|---|---|
|
||||
| 定制师提交用车需求 `PUT /v3/admin/order/{id}/vehicle-requirement`(fleet[] 填 N 个车型) | 对应订单在未派清单出现 **N 行**未派占位(一车型一行,按 fleetItemIndex 区分) |
|
||||
| 定制师**改提**用车需求(同接口,PENDING_EDIT/DONE_ADJUST) | 未派行按新需求刷新;旧需求的未派占位自动清除(#4295 修复,**不再残留孤儿**) |
|
||||
| 订单取消 `POST /v3/admin/order/{id}/cancel/pre-trip` | 该订单的未派占位自动从看板消失 |
|
||||
| 车管在看板对某未派行配车(§8 派单) | 该行从「未派」转入「已派」 |
|
||||
|
||||
## 二、测试服 e2e 实证(已验证,可放心联调)
|
||||
|
||||
- 核心订单提 2 车型用车需求 → §7.2 未派看板即时出现 2 行(车型/接送日期/紧急徽标 T-N 正确)。
|
||||
- 订单取消 → 2 行未派占位即时消失。
|
||||
- 改提需求(1 车→2 车)→ 看板正好 2 行(#4295 修复前会残留 1 条孤儿,现已修复)。
|
||||
|
||||
## 三、前端动作
|
||||
|
||||
- **无接口改动,无需改代码**。§7 / §7.2 看板接口照原契约调用即可。
|
||||
- 若此前因看板返回空数据而无法联调,现可用真实数据继续。
|
||||
正在加载...
x
在新工单中引用
屏蔽一个用户