diff --git a/changelogs-v2/2026-07/20_4773_房务驳回住宿需求重新入抢单池-前端待处理-管理后台.md b/changelogs-v2/2026-07/20_4773_房务驳回住宿需求重新入抢单池-前端待处理-管理后台.md
new file mode 100644
index 0000000..82bdee2
--- /dev/null
+++ b/changelogs-v2/2026-07/20_4773_房务驳回住宿需求重新入抢单池-前端待处理-管理后台.md
@@ -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`。
+- 没有选择任何酒店/房型时，不能提交“确认配房”。