docs: 房务驳回住宿需求前端通知
这个提交包含在:
父节点
d1b8a3ef15
当前提交
7515b06fd9
@ -0,0 +1,95 @@
|
||||
# 房务驳回住宿需求后重新进入抢单池闭环(前端待处理)
|
||||
|
||||
- 日期:2026-07-06
|
||||
- 端:管理后台
|
||||
- 工单:`#4773`
|
||||
- 页面:房务详情弹窗、订单详情 v2 行程安排/住宿安排、选择酒店弹窗
|
||||
- 后端分支:`fix/4773-house-reject-requirement`
|
||||
|
||||
## 业务口径
|
||||
|
||||
房务配置不了当前住宿需求,且该需求还没有任何一天配置房间时,可以驳回当前“生效需求”。
|
||||
|
||||
驳回后的旧需求只作为历史证据保留,不能修改、删除、配房、替换房型、最终确认。定制师重新提出住宿需求时,必须创建全新需求版本,并重新进入抢单池。
|
||||
|
||||
同一订单同一时刻只能有一条生效住宿需求。前端的“修改需求”只能修改当前生效需求;当前没有生效需求但最新版本为驳回时,定制师应走“新提交住宿需求”。
|
||||
|
||||
如果当前需求已经配置了任意一天房间,不能再驳回,前端应引导房务走“替换/修改配房”。后端也会硬拦截。
|
||||
|
||||
## 新增接口
|
||||
|
||||
```http
|
||||
POST /v3/admin/order/{id}/hotel-requirement/supplier-reject
|
||||
Content-Type: application/json
|
||||
|
||||
{
|
||||
"returnRemark": "房型库存不足,需要定制师重新确认"
|
||||
}
|
||||
```
|
||||
|
||||
说明:
|
||||
|
||||
- `id`:订单 ID。
|
||||
- `returnRemark`:必填,驳回原因。
|
||||
- 仅驳回当前 active 住宿需求。
|
||||
- 只有当前需求没有任何 active 配房行时允许驳回;配置了一天也不能驳回。
|
||||
- 后端会把旧需求置为 `REJECTED_TO_CONSULTANT` 或 `REJECTED_TO_ADMIN`,并 `isActive=false`。
|
||||
- 订单主流程从 `PENDING_CONFIRM` 回退到 `RESOURCE_PREPARING`。
|
||||
- 订单详情住宿子流程展示应变成“驳回”,不是“配房处理中”。
|
||||
|
||||
## 状态字典
|
||||
|
||||
后端补充了状态字典,前端可按字典渲染中文,不要写死:
|
||||
|
||||
| 字典 | 说明 |
|
||||
|------|------|
|
||||
| `order_requirement_status` | 订单房/车需求对外状态 |
|
||||
| `house_status` | 房务作业状态 |
|
||||
| `house_assign_confirm` | 配房行确认态 |
|
||||
|
||||
`order_requirement_status` 中:
|
||||
|
||||
| value | label |
|
||||
|-------|-------|
|
||||
| `PENDING` | 待配 |
|
||||
| `PROCESSING` | 处理中 |
|
||||
| `DONE` | 已完成 |
|
||||
| `PENDING_REVIEW` | 待审核 |
|
||||
| `REJECTED_TO_CONSULTANT` | 驳回 |
|
||||
| `REJECTED_TO_ADMIN` | 驳回 |
|
||||
|
||||
## 前端处理要求
|
||||
|
||||
1. 房务详情弹窗新增“驳回需求”入口。
|
||||
2. 房务管理员和超级管理员都应能看到“驳回需求”按钮。
|
||||
3. 只允许对当前生效需求展示“驳回需求/修改/配房/替换/最终确认”等动作。
|
||||
4. 当前需求已有任意配房行时,“驳回需求”应置灰或隐藏,提示“已有配房,不能驳回,请走替换/修改配房”。
|
||||
5. 旧驳回需求只读展示,不允许修改、删除、配房、替换房型、最终确认。
|
||||
6. 驳回弹窗必须填写驳回原因 `returnRemark`。
|
||||
7. 驳回成功后订单详情顶部住宿子流程展示为“驳回”。
|
||||
8. 定制师重新提交住宿需求后,前端应看到新版本进入“待配房/抢单池”。
|
||||
|
||||
## 选择酒店弹窗
|
||||
|
||||
“定制师推荐”标记只能按 `hotelId` 判断,不要按酒店名称判断。
|
||||
|
||||
原因:同名酒店可能有多条资源记录。定制师选酒店时传的是酒店 ID,后端已改为只按 `hotelId` 命中;前端如果仍按名称渲染,会出现两个同名酒店都显示“定制师推荐”的错误。
|
||||
|
||||
## 配房提交兼容
|
||||
|
||||
配房提交项 `sellPrice` 允许不传。后端会优先用本项 `sellPrice`,未传时用所选房型协议价兜底;两者都没有时才报错。
|
||||
|
||||
前端仍建议优先传当前行展示的结算价,但不要因为 `sellPrice` 缺失在页面层阻断替换配房流程。
|
||||
|
||||
配房提交 `items` 不能为空。前端不要允许“没有选择任何酒店/房型”的空方案调用确认配房;后端会返回错误,防止空保存把旧配置清掉。
|
||||
|
||||
## 验收标准
|
||||
|
||||
- 房务管理员 / 超级管理员在房务详情可看到“驳回需求”按钮。
|
||||
- 当前需求没有任何配房行时才能驳回;已配置任意一天房间时不能驳回。
|
||||
- 驳回时必须输入原因。
|
||||
- 驳回后订单详情住宿流程节点显示“驳回”。
|
||||
- 驳回后的旧需求只读,不再出现修改/替换/最终确认入口。
|
||||
- 定制师重新提交后生成新需求版本,重新进入抢单池。
|
||||
- 选择酒店弹窗同名不同 ID 酒店只标记实际被定制师选择的 `hotelId`。
|
||||
- 没有选择任何酒店/房型时,不能提交“确认配房”。
|
||||
正在加载...
x
在新工单中引用
屏蔽一个用户