From 1df4ac1a01f2e4ae2b42ae8bdbbefa6128b982b6 Mon Sep 17 00:00:00 2001 From: API Changelog Bot Date: Sun, 12 Jul 2026 14:18:14 +0800 Subject: [PATCH] =?UTF-8?q?docs(house):=20=E9=80=9A=E7=9F=A5=E5=89=8D?= =?UTF-8?q?=E7=AB=AF=E6=8E=A5=E5=85=A5=E5=8D=95=E6=9D=A1=E9=85=8D=E6=88=BF?= =?UTF-8?q?=E6=99=9A=E6=AC=A1=E8=B0=83=E6=95=B4?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- ...调整保留配房与房务驳回定制师待办-管理后台.md | 80 +++++++++++++++++-- 1 file changed, 74 insertions(+), 6 deletions(-) diff --git a/changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md b/changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md index 4ac9844..0494408 100644 --- a/changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md +++ b/changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md @@ -4,7 +4,11 @@ > > 生效分支：`dev-v3` > -> 接口结构：无新增字段、无新增前端接口；沿用订单调整、房务详情、最终确认和房务驳回现有接口 +> 接口结构：新增“单条配房晚次与资源原子调整”接口；其余沿用订单调整、房务详情、最终确认和房务驳回现有接口 +> +> 后端状态：PR [#4915](https://git.1814.love:8443/wx/HL/pulls/4915) 已合并；测试环境部署任务 `b60dccde` 成功，`8086/8186` 双实例 UP +> +> 联调证据：2026-07-12 网关三场景探针通过，覆盖跨晚次原子移动、订单改期库存迁移、库存不足补偿和房务驳回待办 ## 1. 订单调整后的房务口径 @@ -33,15 +37,79 @@ POST /v3/admin/order/{orderId}/adjustment/submit - 任意新日期库存不足或日历缺失：整次订单调整返回 `808901`；订单日期、需求版本、配房和旧库存全部保持原样，已临时预占的新日期库存自动补偿。 - 前端收到 `808901` 时只提示库存不足，不得将本地表单当作已保存。 -### 房务人工修改配房 +### 房务人工修改单条配房 -房务仍通过现有配房提交接口按晚次替换： +当前前端仅在 `ItineraryPanel.vue` 只读显示日期，并通过整晚 `POST assignments` 做“配房/替换”。这不能安全实现“把 6 月 1 日的既有配房移动到 6 月 5 日”：若前端组合调用新增目标行和删除原行，中间任一步失败都会造成配房或库存半套。 + +请为每条既有配房增加“调整”入口，统一调用以下原子接口： ```http -POST /v3/admin/order/hotel-requirements/{requirementId}/assignments +PUT /v3/admin/order/hotel-requirements/{requirementId}/assignments/{assignmentId}/placement +Content-Type: application/json + +{ + "dayNumber": 5, + "hotelId": "200001", + "roomTypeId": "300001", + "roomCategory": "DELUXE", + "roomCount": 2, + "protoPrice": "520.00", + "settlementPrice": "480.00", + "settleType": "sign", + "deductInventory": true, + "syncProtocolPrice": false, + "syncSettlementPrice": false, + "syncSettleType": false, + "remark": "改期后重新询房" +} ``` -同一 `dayNumber` 可重新选择 `hotelId`、`roomTypeId`、`roomCount`。入住日期由后端按当前行程与 `dayNumber` 计算，不能沿用前端缓存的旧日期；替换后重新进入询房/确认流程。 +成功响应： + +```json +{ + "code": 200, + "message": "成功", + "data": null, + "success": true +} +``` + +字段规则： + +| 字段 | 必填 | 说明 | +|---|---|---| +| `dayNumber` | 是 | 目标晚次，从当前详情 `days[]` 选择。必须按当前行程映射：若出发日已从 6 月 1 日改为 6 月 5 日，则 6 月 5 日是当前第 1 晚，传 `1`，不是按“日期中的 5”传 `5` | +| `hotelId` | 是 | 目标酒店 ID，字符串透传 | +| `roomTypeId` | 是 | 目标房型 ID，字符串透传 | +| `roomCategory` | 是 | 房型字典 code | +| `roomCount` | 是 | 目标房间数，必须大于 0 | +| `deductInventory` | 是 | 是否扣系统库存；缺失返回 `808124` | +| `protoPrice` / `settlementPrice` | 否 | 不传时按目标房型和目标入住日读取资源价格日历；金额按字符串提交 | +| `settleType` | 否 | `cash` / `sign` / `company` | +| 三个 `sync*` | 否 | 仅用户明确选择同步时传 `true` | +| `remark` | 否 | 不传时保留原备注 | + +前端交互要求： + +1. 目标日期不是自由输入框。下拉选项来自当前详情的有效住宿晚次，展示“第 N 晚 / 日期 / 城市”，提交其 `dayNumber`；不要提交 `stayDate`。 + 如果订单已改期但某条历史配房仍显示 6 月 1 日，当前行程第 1 晚已是 6 月 5 日，则房务选择“第 1 晚 / 6 月 5 日”提交；后端会把同一配房 ID 的 `stayDate` 更正为 6 月 5 日。 +2. 同一弹窗必须允许同时修改目标晚次、酒店、房型、房间数、是否扣库存、协议价、结算价、支付方式和备注。 +3. 后端按当前 `order_itinerary_day` 推导并保存 `stayDate`。旧配房 ID 不变，成功后该行退回 `INQUIRING`，前端关闭弹窗并重新加载详情。 +4. 扣库存场景由后端先占目标库存、提交后释放原库存；失败时原配房和原库存不变。前端禁止再组合调用“目标晚新增 + 原晚删除”。 +5. 现有整晚 `POST /v3/admin/order/hotel-requirements/{requirementId}/assignments` 继续用于新增候选和同晚整组对账，不替代本接口的跨晚次原子移动。 + +主要错误码： + +| code | 处理 | +|---|---| +| `808102` | 目标晚次已不在当前行程，刷新详情后重选 | +| `808117` | 目标晚已有同酒店、同房型、同库存口径配房，提示合并房间数 | +| `808124` | 未选择是否扣库存 | +| `808125` | 配房或行程被并发修改，刷新详情后重试 | +| `808126` | 原配房声明扣库存但缺少可释放的持有日志；禁止继续调整，需先核对库存 | +| `808130` | 目标房间数小于已录入的家庭分房条数 | +| `808901` | 目标日期资源库存不足；保留原页面数据 | ## 2. 最终确认 @@ -94,7 +162,7 @@ Content-Type: application/json 1. 增天后原配房不消失，新增夜可单独配房；不再出现 `roomCount 必须 > 0`。 2. 改期后原配房按晚次自动平移日期，酒店、房型、房间数和价格快照不变，状态退回询房中。 3. 改期同时增减天数时，新范围内配房平移、新增夜为空、超范围旧配房保留。 -4. 房务可按晚次替换日期对应的酒店、房型和房间数。 +4. 房务可把单条既有配房原子移动到另一当前有效晚次，并同时修改酒店、房型、房间数和库存口径；日期始终与目标晚次一致。 5. 扣库存配房改期成功时旧库存释放、新库存扣减；任一晚不足时整单不变。 6. 减天后的多余旧配房继续显示，最终确认被后端阻断，直到人工清空/替换。 7. 修改人数后已有配房保持，房务重新最终确认。