68 lines
6.8 KiB
Markdown
68 lines
6.8 KiB
Markdown
# OHIP FIT UPDATE 字段与对应 CP23
|
||
|
||
本地纯准备与读回组件已实现，当前不注册 worker、不执行酒店写入。完整 FIT UPDATE 尚未完成。
|
||
|
||
## 业务行为
|
||
|
||
输入是员工已确认的完整日期、房型房数、Rate Code、原文 Note 和本次 Excel 引用。先通过 CP7 保存实际 Reservation 全集，再由 CP8/10 提供完整旧详情与来源可证的 Note。CP23 在内存中把每笔旧 Reservation 对应到一项新的正房量，构造最小更新，并比较后续实际查询。
|
||
|
||
- 同一笔原订三间，更新为两间：直接提交 `numberOfUnits=2`，不用取消一笔预订。
|
||
- 多个房型改日期：原房型能双向唯一对应时保留各自 Reservation ID。
|
||
- 多段相同房型改成不同房型：日期能双向唯一对应时保留各段 ID。
|
||
- 先固定住期与房型同时未变的唯一项；其余日期/房型线索合并判断，不能任意设优先级；最后仅剩一笔与一项时才可唯一消去。
|
||
- 日期和房型线索冲突、多个相同房型全部改日期、旧编号数与正房量项数不同、已拆分多笔不能唯一分配，均在返回任何请求前拒绝。不会按数组/编号顺序、房数相似度或姓名猜测，也不自动新建、取消、归零、拆分或合并旧 Reservation。
|
||
|
||
这是保守的一对一范围，不等于任意已拆分 FIT 的重组能力。其他拓扑要取得明确的原生规则和可审计的分配依据后再扩展，不能将这项技术限制解释为用户批准自动取消。
|
||
|
||
## 分层和输入边界
|
||
|
||
`HotelFitUpdateAllocationResolver` 属于 workflow 纯业务计算，只消费业务 DTO。`HotelFitUpdateAllocation` 保存对应依据与原 CP1 计划。`OhipFitUpdateBookingConverter` 将原确认及显式房型/Rate 映射转换为原生请求；`OhipFitUpdateReadbackConverter` 负责酒店响应身份检查与逐字段观察。
|
||
|
||
准备时必须满足：
|
||
|
||
- 同 execution/确认版本/酒店/环境/Tour Code 的完整实际父编号绑定；scope 必须已保存。
|
||
- 原查询不早于执行更新时间或绑定时间，来源匹配不早于原查询且不晚于当前时间。
|
||
- 每笔状态 Reserved/DueIn、相同主 Guest Profile、原房费段完整连续覆盖入住日至离店日前一天、每晚同房型同数量。逐日 Rate 不同本身不改变房量对应。
|
||
- 每笔旧业务 Note 的实际 ID、原文摘要和历史证据键均已提供；不以同名或文本相似替代来源。Note 与酒店不匹配、原文已变或重复编号时拒绝。
|
||
- 新参数通过 CP1 完整范围验证；原生房型映射不得冲突，Rate 和正房量房型代码长度不超过20。Note 原文不修剪、不翻译，不能为空或包含非法控制字符。
|
||
|
||
Prepared 固定原确认摘要、绑定、每笔请求/主客档/旧 Note 投影/对应依据、准备时间和内容摘要。摘要用来检测变化，不是授权凭证；`executionEnabled=false`。后续执行必须另行在原执行行锁中持久冻结并检查租约、阶段、调用来源和附件计划，不能将此对象直接当作可发送授权。
|
||
|
||
## 原生请求
|
||
|
||
公开目录本轮观察为 **0.7.0**：`putReservation` → `PUT /api/v1/reservations/{reservationID}`，能力组 `reservations.write`，确认写入且未知结果先读回。此版本仅为公开目录观察，未读取消费密钥、变更授权或验证酒店配置。
|
||
|
||
Oracle固定契约为26.3.0.0，提交 `dd631fbd5d0fce74a7dbdf96b43f07ce587211f2`：
|
||
|
||
| 业务值 | 原生字段 |
|
||
| --- | --- |
|
||
| 实际预订编号 | 路径 Reservation ID 与 `reservations[0].reservationIdList` 的 id/type |
|
||
| 入住/离店 | `roomStay.arrivalDate/departureDate` |
|
||
| 房型、房数、Rate Code | `roomStay.roomRates[0].roomType/numberOfUnits/ratePlanCode` |
|
||
| 每晚覆盖范围 | `start=入住日`，`end=离店日前一天` |
|
||
| 原业务 Note | `comments[0].id`；仅提交 `comment.text.value` 新原文 |
|
||
|
||
PUT 根 `reservations` 与其 `comments` 均是数组。GET 的编号含 `idContext` 时用于身份核对，但 PUT `uniqueID_Type` 不接受该字段，不照搬读模型。官方内嵌示例的 comments 对象与定义数组冲突；采用固定 schema 并保留原生 UAT 验证门槛。
|
||
|
||
不提交其他备注、价格金额、Guest/Account/Contact、GC、BTQR、成人数或其他 NEW 默认字段；不伪造 TA recorder 字段。
|
||
|
||
Oracle用户手册说明 Rooms 可填写所需房数，多房预订在分配实体房间前需拆分；这不是本项目主动拆分或取消的授权：[Updating Reservations, 26.3](https://docs.oracle.com/en/industries/hospitality/opera-cloud/26.3/ocsuh/t_managing_reservations_editing_reservation_stay_details.htm)。`numberOfUnits` 定义未设最小值，不证明 0 可用来消除旧 Reservation。
|
||
|
||
## 查询与部分结果
|
||
|
||
精确 `getReservation` 请求 Reservation、Comments、RateInfoDetails。身份、酒店、编号、分页或整体响应时间不可信时拒绝整份结果。其余分别返回 DATES、ROOMS、RATE、NOTE、OTHER_NOTES、GUEST、ACTIVE_RESERVATION 的一致/不符/不可用，字段缺失不能用请求值补齐。
|
||
|
||
逐日或多段房费必须完整连续且无重叠；可以按任意顺序返回。NOTE 必须仍是原实际 ID，新文本与输入逐字相同，原类型、酒店、内部/保密标志、标题、通知位置、语言不变。OTHER_NOTES 检查全部原有其他备注的这些字段仍在且未变；允许独立新增其他备注，其正文不放入本业务观测投影。创建者/修改时间等审计字段以及配置派生的类型描述不作为不可变内容。
|
||
|
||
为此扩展内部 `HotelBookingPriorData.Note`，CP8和CP10两个读取器同时保存标题、通知位置、语言；旧六字段快照可反序列化为新增字段null。Prepared/readback/旧Note的 `toString` 不输出业务正文。
|
||
|
||
`mappedFieldsMatch()` 只代表本组件七项一致，`businessComplete()` 始终false。TA recorder、Excel替换及持久执行仍列为缺口，不能由查询匹配将 UNKNOWN 调用提升为已成功或允许重发。
|
||
|
||
## 本地验证与后续
|
||
|
||
新增88项合成测试通过；相关1057项通过（零失败/错误/跳过），包含固定官方 schema、来源转换、顺序交换、日期与房型冲突、3→2直接改数、旧现场/来源/权限/时间拒绝、逐字段部分失败、备注保留和旧快照兼容。完整后端 verify 结果见[证据](../../../.project-docs/50-evidence/topics/2026-09-16-ohip-fit-update-fields-cp23.md)。
|
||
|
||
下一 checkpoint 接不可变计划/真实 worker、逐笔 journal、CP18全部Excel、失败事实与恢复，并复用本轮准备结果而不随新配置重算。FIT TA recorder准确REST读写字段、原生最小更新保留行为、房数变更、平台权限/配置、真实MySQL和Oracle UAT继续待验。
|
||
|
||
没有真实业务调用、凭据读取、数据库迁移、前端修改、运行启用、平台改动、提交或部署。默认 Pending 保持。
|