43 #4573 配房询房即扣库存+单日确认requirementId+弹窗全态回显currentSelections(前端必改) 44 #4574 日历团数按团期折叠修复+某天下钻详情新端点 45 #4575 待办按订单聚合一行多类型标签+类型字典化(前端必改) 46 #4578 定制师联系房务未读角标unreadMessageCount+站内信标题团号·联系人 47 #4576 转单操作日志显示接收人真名+转单理由(知悉)
3.5 KiB
3.5 KiB
房务配房流程:询房即扣库存 + 单日确认带 requirementId + 配房弹窗全态回显(前端必改)
模块:房务管家 · 配房行程(管理后台) 类型:行为变更 + 出参新增字段(PR #4585/#4598/#4600 已合 dev-v3 + 测试服 R1/R2/R3 实测生效) 关联工单:#4573 / #4597 / #4599 日期:2026-06-28
1. 【阻塞修复·必改】单日确认改用 itinerary[].requirementId 拼 URL
房务测试反馈「第 1 天确认 OK、第 2 天选另一家酒店点确认报『缺少需求 ID, 暂无法确认』流程卡死」。
- 根因:前端单日确认依赖了上一步流程残留的 requirementId 临时态,切到第 2 天直接点确认时取不到。
- 后端已在订单详情
GET /admin/house/orders/{orderId}的itinerary[]每天 VO 新增requirementId字段(雪花,String 序列化),对所有天稳定一致。 - 前端必改:单日确认
POST /v3/admin/order/hotel-requirements/{requirementId}/assignments/days/{dayNumber}/confirm的requirementId一律取itinerary[该天].requirementId(不要依赖配房/询房流程的临时变量)。
2. 【行为变更·必知】「询房即扣库存」
业务规则调整:配房进入「询房中」(INQUIRING) 即立即扣减酒店库存(此前是「单日确认」才扣)。
POST /.../assignments(批量提交配房方案):提交后该天候选行进入询房中就已占用库存;库存不足在提交时即拒(返808901 房型库存扣减失败:数量不足或日历记录缺失)。- 单日确认
.../days/{dayNumber}/confirm:保留的候选不再重复扣;落选/未保留的候选软删并自动还原库存。 - 影响前端:①「库存不足」错误现在出现在提交配房这一步(不再是确认步);②取消选中/替换酒店后,被换掉的酒店库存会自动还原,无需前端干预。
3. 【出参新增·建议用】配房弹窗全态回显 currentSelections
房务测试反馈「选错酒店点确认后,再点配房不回显已选酒店、无法删除/替换」。
- 订单详情
itinerary[]每天 VO 新增currentSelections:该天当前全部 active 配房行(询房中 INQUIRING ∪ 已确认 CONFIRMED 的并集),每行带confirmStatus标识。 - 候选端点
GET /v3/admin/hotel-candidates的isCurrentlyAssigned/assignedRoomTypeId现在在询房中与已确认两个阶段都会标记(此前只认已确认)。 - 前端建议:再次打开配房弹窗时,用
currentSelections(或候选的isCurrentlyAssigned)回显/高亮该天当前已选酒店,支持删除/替换;不要只读旧的inquiringAssignments(确认后会变空)。旧字段currentAssignments(仅 CONFIRMED) /inquiringAssignments(仅 INQUIRING) 保留兼容。
4. 【入参校验】dayNumber 上界
POST /.../assignments 提交的 dayNumber 超过该需求应配晚数 → 返 808102 dayNumber 越界。前端按行程天数约束,勿提交越界天号。
测试服实测(R1/R2/R3)
- itinerary 每天 requirementId 非空;第 2 天换酒店确认成功无「缺少需求 ID」。
- 询房即扣:提交配房即 DB stock_used +N;确认保留不重扣;落选/替换/删除自动还原(stock 精确归还、不转负)。
- 库存不足在提交步即拒 808901(干净中文消息);填超量被拒后改小量重提同酒店可成功。
- currentSelections 含询房中+已确认两态行;候选两阶段都标 isCurrentlyAssigned。