hl-api-changelog/changelogs-v2/2026-07/56_4907_订单调整保留配房与房务驳回定制师待办-管理后台.md
2026-07-12 02:52:40 +08:00

5.2 KiB

【行为变更·管理后台】订单调整保留配房与房务驳回定制师待办(#4907

服务:hl-order-service-v3

生效分支:dev-v3

接口结构:无新增字段、无新增前端接口;沿用订单调整、房务详情、最终确认和房务驳回现有接口

1. 订单调整后的房务口径

定制师通过以下接口修改行程天数、出发日期或出行人数:

POST /v3/admin/order/{orderId}/adjustment/submit

后端现在按最新行程重新对齐住宿需求逐晚结构。既有配房不会被自动删除;真正改出发日期时,仍在新行程晚数范围内的配房会按 dayNumber 自动平移入住日期:

调整项 前端应展示的结果
增加行程天数 原晚次配房保持;新增夜显示待配房
减少行程天数 需求夜数减少;多余旧配房继续显示,等待房务人工清空/替换
修改出发日期 stayDate = 新出发日期 + dayNumber - 1;酒店、房型、房间数、价格、扣库存选择和备注原样保留;配房退回询房中重新确认
同时改日期和天数 新行程范围内的配房自动平移;新增夜为空待配;超出新晚数的旧配房不自动删除
修改出行人数 原配房继续显示;完整配房回到待最终确认,不完整则回配房中

新增夜允许空候选占位,roomCount 未填或为 0 均可提交;负数仍会被后端拒绝。前端不要为了绕过校验自行填造假的间数。

改期库存原子性

  • deductInventory=false:只平移订单配房快照,不操作资源库存。
  • deductInventory=true:后端先逐晚预占新日期库存;全部成功后才修改订单、行程、需求和配房日期,并释放旧日期库存。
  • 任意新日期库存不足或日历缺失:整次订单调整返回 808901;订单日期、需求版本、配房和旧库存全部保持原样,已临时预占的新日期库存自动补偿。
  • 前端收到 808901 时只提示库存不足,不得将本地表单当作已保存。

房务人工修改配房

房务仍通过现有配房提交接口按晚次替换:

POST /v3/admin/order/hotel-requirements/{requirementId}/assignments

同一 dayNumber 可重新选择 hotelIdroomTypeIdroomCount。入住日期由后端按当前行程与 dayNumber 计算,不能沿用前端缓存的旧日期;替换后重新进入询房/确认流程。

2. 最终确认

POST /admin/house/assignments/requirements/{requirementId}/finalize
  • 没有任何配房时允许最终确认,用于客人自行解决住宿的场景。
  • 一旦存在任意配房,所有 active 配房必须已确认,并按晚次精确覆盖当前行程住宿日期。
  • 缺夜、多余夜、日期不匹配或存在未确认配房返回:
{
  "code": 808181,
  "message": "已有配房与当前行程不一致,请先补配、替换或清空",
  "data": null
}

前端收到该错误后保留当前配房数据,提示房务逐日处理;不得清空页面状态或隐藏超出新行程的旧配房。

3. 房务驳回后的定制师待办

POST /v3/admin/order/{orderId}/hotel-requirement/supplier-reject
Content-Type: application/json

{
  "returnRemark": "酒店无法满足当前房型,请重新确认需求"
}

驳回成功后,后端会为原定制师显式创建一条待办:

{
  "todoType": "ASSIGN_ROOM",
  "todoLabel": "房型需求 · 已打回",
  "status": "PENDING",
  "assigneeRoleKey": "CUSTOMIZER",
  "relatedBizType": "HOTEL_REQUIREMENT",
  "relatedBizId": "2075933198734303233"
}

该待办与订单当前是否仍处于“补出行人资料”阶段无关。定制师待办页按现有待办接口正常展示并跳转订单调整即可。

4. 前端验收

  1. 增天后原配房不消失,新增夜可单独配房;不再出现 roomCount 必须 > 0
  2. 改期后原配房按晚次自动平移日期,酒店、房型、房间数和价格快照不变,状态退回询房中。
  3. 改期同时增减天数时,新范围内配房平移、新增夜为空、超范围旧配房保留。
  4. 房务可按晚次替换日期对应的酒店、房型和房间数。
  5. 扣库存配房改期成功时旧库存释放、新库存扣减;任一晚不足时整单不变。
  6. 减天后的多余旧配房继续显示,最终确认被后端阻断,直到人工清空/替换。
  7. 修改人数后已有配房保持,房务重新最终确认。
  8. 零配房订单允许最终确认。
  9. 房务驳回后,原定制师能看到“房型需求 · 已打回”待办。
  10. 历史需求和旧配房均继续展示,不得只渲染当前需求而丢失历史证据。

5. 后端验证证据

  • PRwx/HL#4910wx/HL#4911wx/HL#4913
  • 测试环境部署任务:440ed4d18086/8186 双实例均 UP
  • 模块全量5499 项;与 clean baseline 相同的既有 5 项失败,无新增回归
  • 网关全流程报告:D:/work2/HL-v3/.tmp/house-adjustment-flow-probe-20260712-024715.json
  • 实测通过:增晚、减晚、人数变化、改期+增晚同次提交、酒店/房型/房间数替换、入住日期对齐、人工清空、零配房最终确认、房务驳回待办、库存成功迁移、库存不足整单回滚