2.7 KiB
2.7 KiB
目标前端
- 端类型:管理后台(Web)
- 目标仓库:
mmg/hl-ui(https://git.1814.love:8443/mmg/hl-ui.git) - 联调/验收环境:
http://192.168.100.160:9527 - 小程序、H5 及其他前端:无需处理
变更背景
订单改出发日期后,原入住日期已经配置的酒店不能静默平移到新日期。房务需要明确核对并逐条删除旧配房;旧配房未清完时禁止最终确认。
详情接口新增字段
GET /admin/house/orders/{orderId} 顶层新增:
{
"pendingRescheduleAssignments": [
{
"assignmentId": "99001",
"originalStayDate": "2026-07-22",
"hotelId": "8001",
"hotelName": "示例酒店",
"roomTypeId": "9001",
"roomTypeName": "普通标间",
"roomCategory": "STANDARD",
"roomCategoryLabel": "标间",
"roomCount": 2,
"assignmentStage": "FINAL_CONFIRMED",
"assignmentStageLabel": "最终确认",
"deleteEndpoint": "DELETE /v3/admin/order/assignments/99001"
}
]
}
assignmentStage 枚举:
| 值 | 中文 | 含义 |
|---|---|---|
UNCONFIRMED |
未单日确认 | 改期前仍处于询房/候选阶段 |
DAY_CONFIRMED |
单日确认 | 改期前已完成该日确认,但原需求未最终确认 |
FINAL_CONFIRMED |
最终确认 | 改期前所属住宿需求已经最终确认 |
数组为空表示没有改期旧配房待清理。旧配房不会再出现在当前 itinerary[].assignments,也不计入当前配房进度。
前端交互要求
- 在“订单调整提醒”的改期记录下展示
pendingRescheduleAssignments,每行至少显示:原日期、酒店、房型、数量、配房步骤。 - 每行提供“删除旧配房”,调用返回的
deleteEndpoint;成功后重新拉取详情。 - 只要数组非空,不允许用户最终确认,并显示后端
actions.canFinalize.disabledReason。 - 数组清空后再按后端
actions.canFinalize.enabled决定按钮状态,禁止前端自行推断。 - 删除仍可能因领取归属、房务写权限、并发修改或库存释放链路失败而报错,直接展示后端消息并刷新详情。
最终确认写口门禁
POST /admin/house/assignments/requirements/{requirementId}/finalize
若仍有旧日期配房,返回业务错误:
- code:
808183 - message:
改期前旧日期配房尚未清理,请逐条删除后再最终确认
该门禁由后端强制执行,前端禁用按钮仅用于交互提示。
兼容说明
- 字段为 additive;旧页面忽略新增字段不会影响反序列化。
roomTypeName在资源服务降级时可为空,前端回退roomCategoryLabel。assignmentId、hotelId、roomTypeId按字符串处理,禁止转 JavaScriptnumber。