70 行
2.7 KiB
Markdown
70 行
2.7 KiB
Markdown
# 房务已最终确认后仍应允许房务直接修改配房（前端待处理）
|
||
|
||
- 日期：2026-07-03
|
||
- 端：管理后台
|
||
- 页面：房务管家 / 房务订单详情弹窗
|
||
- 示例订单：`HL20260703140009401`
|
||
- 订单 ID：`2072923329412427777`
|
||
- 当前状态：房务已最终确认，详情展示“已完成 / 配房进度 2/2”
|
||
- 当前结论：前端拦截口径错误。房务可以直接修改，不需要定制师重新提出修改；完成后的任何状态都可以修改。
|
||
|
||
## 现象
|
||
|
||
在房务详情弹窗里，订单已经完成配房并最终确认。
|
||
|
||
房务点击住宿行「配房」时，前端弹出：
|
||
|
||
```text
|
||
配房已最终确认，不可直接修改；如需变更请由定制师重新调整需求
|
||
```
|
||
|
||
这个提示和拦截不符合业务口径。
|
||
|
||
## 正确业务口径
|
||
|
||
房务侧可以直接修改配房结果。
|
||
|
||
- 不需要定制师重新提出修改需求。
|
||
- 已最终确认也可以改。
|
||
- 已完成配房也可以改。
|
||
- 任意房务状态下，只要房务有操作入口，都应允许进入修改/重新配房流程。
|
||
|
||
也就是说，前端不能因为以下状态阻断房务修改：
|
||
|
||
- `houseStatus=CONFIRMED`
|
||
- 页面展示“已完成”
|
||
- 页面展示“已最终确认”
|
||
- 住宿行展示“已确认 / 已配房 / 已完成”
|
||
- 配房进度 `2/2`
|
||
|
||
## 前端处理要求
|
||
|
||
请移除房务侧这个拦截：
|
||
|
||
```text
|
||
配房已最终确认，不可直接修改；如需变更请由定制师重新调整需求
|
||
```
|
||
|
||
调整为：
|
||
|
||
1. 房务在已最终确认/已完成/已回配状态下点击「配房」，仍进入配房编辑或重新配房流程。
|
||
2. 不要求定制师先提出修改需求。
|
||
3. 不因为已完成状态隐藏或禁用房务修改入口。
|
||
4. 若需要当前住宿行 ID、assignmentId、requirementId，请从当前房务详情数据中取，不要用“已最终确认”作为前端阻断条件。
|
||
5. “修改需求”是定制师侧调整需求的入口；房务侧修改配房是另一条操作链路，不能混为一谈。
|
||
|
||
## 后端接口说明
|
||
|
||
本次无后端接口变更。
|
||
|
||
后端当前已有配房行数据，页面能展示酒店、房型、价格、确认状态，说明房务 assignment 上下文存在。
|
||
|
||
前端需要放开状态判断，继续调用现有房务配房/修改配房接口链路。
|
||
|
||
## 验收标准
|
||
|
||
- `HL20260703140009401` 已最终确认后，房务点击住宿行「配房」不再出现“不可直接修改，请由定制师重新调整需求”的提示。
|
||
- 已完成配房订单可以由房务直接进入修改/重新配房流程。
|
||
- 不需要定制师先发起修改需求。
|
||
- 待配房、配房中、待最终确认、已完成等任意房务状态下，房务修改入口逻辑一致可用。
|