4.4 KiB
4.4 KiB
房务驳回住宿需求后重新进入抢单池闭环（前端待处理）
- 日期：2026-07-06
- 端：管理后台
- 工单：
#4773 - 页面：房务详情弹窗、订单详情 v2 行程安排/住宿安排、选择酒店弹窗
- 后端分支：
fix/4773-house-reject-requirement
业务口径
房务配置不了当前住宿需求，且该需求还没有任何一天配置房间时，可以驳回当前“生效需求”。
驳回后的旧需求只作为历史证据保留，不能修改、删除、配房、替换房型、最终确认。定制师重新提出住宿需求时，必须创建全新需求版本，并重新进入抢单池。
同一订单同一时刻只能有一条生效住宿需求。前端的“修改需求”只能修改当前生效需求；当前没有生效需求但最新版本为驳回时，定制师应走“新提交住宿需求”。
如果当前需求已经配置了任意一天房间，不能再驳回，前端应引导房务走“替换/修改配房”。后端也会硬拦截。
新增接口
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 |
驳回 |
前端处理要求
- 房务详情弹窗新增“驳回需求”入口。
- 房务管理员和超级管理员都应能看到“驳回需求”按钮。
- 只允许对当前生效需求展示“驳回需求/修改/配房/替换/最终确认”等动作。
- 当前需求已有任意配房行时，“驳回需求”应置灰或隐藏，提示“已有配房，不能驳回，请走替换/修改配房”。
- 旧驳回需求只读展示，不允许修改、删除、配房、替换房型、最终确认。
- 驳回弹窗必须填写驳回原因
returnRemark。 - 驳回成功后订单详情顶部住宿子流程展示为“驳回”。
- 定制师重新提交住宿需求后，前端应看到新版本进入“待配房/抢单池”。
选择酒店弹窗
“定制师推荐”标记只能按 hotelId 判断，不要按酒店名称判断。
原因：同名酒店可能有多条资源记录。定制师选酒店时传的是酒店 ID，后端已改为只按 hotelId 命中；前端如果仍按名称渲染，会出现两个同名酒店都显示“定制师推荐”的错误。
配房提交兼容
配房提交项 sellPrice 允许不传。后端会优先用本项 sellPrice，未传时用所选房型协议价兜底；两者都没有时才报错。
前端仍建议优先传当前行展示的结算价，但不要因为 sellPrice 缺失在页面层阻断替换配房流程。
配房提交 items 不能为空。前端不要允许“没有选择任何酒店/房型”的空方案调用确认配房；后端会返回错误，防止空保存把旧配置清掉。
验收标准
- 房务管理员 / 超级管理员在房务详情可看到“驳回需求”按钮。
- 当前需求没有任何配房行时才能驳回；已配置任意一天房间时不能驳回。
- 驳回时必须输入原因。
- 驳回后订单详情住宿流程节点显示“驳回”。
- 驳回后的旧需求只读，不再出现修改/替换/最终确认入口。
- 定制师重新提交后生成新需求版本，重新进入抢单池。
- 选择酒店弹窗同名不同 ID 酒店只标记实际被定制师选择的
hotelId。 - 没有选择任何酒店/房型时，不能提交“确认配房”。