4.4 KiB
FIT TA Record Locator 技术询问草稿（未发送）
请平台或 Oracle 技术人员提供一个明确示例：用哪个接口、把团号放进哪个参数，才能写入酒店页面的 TA Record Locator；保存后通过哪个查询字段能读回同一个值。需要同时覆盖新建和修改。有 Tour Code 时原样填写；没有时不提交此字段。用户已截图确认界面位置为 Stay Details → TA Record Locator。现有平台已提供预订新建、修改、查询接口，因此请先判断是否可以直接使用，而非假定要新增接口。
以下为可供技术人员处理的英文版本，无真实酒店、客人或凭据内容。
2026-09-18 更新：已找到官方数据字典将 Travel Agent Locator 关联到 EXTERNAL_REFERENCES.EXTERNAL_REFERENCE，条件为 EXTERNAL_REFERENCE_TYPE='TA_RECORD_LOCATOR'。现在请优先确认下面这一候选，不需要重新泛搜所有接口。证据和单笔只读查询步骤见专项核对。截图目标始终是 Stay Details 中的 TA 输入框。
Draft — FIT TA Record Locator REST contract clarification
This request is prepared for review only; it has not been sent.
We need to populate the OPERA Cloud reservation UI field TA Record Locator with an agency booking reference, and verify the value through OHIP REST for both new and updated individual reservations. The same reference may identify multiple actual reservation IDs.
Reviewed source: Oracle hospitality-api-docs, Property API 26.3.0.0, commit 4bd129b455bc5e3ab0f900ac47983611e58659b4, rest-api-specs/property/v1/rsv.json. The published middleware contract already exposes postReservation, putReservation, getReservation and searchHotelReservations with Oracle JSON documents. This contract review is not evidence that the deployed chain has successfully written the TA field.
The published searchHotelReservationsRequest defines taRecordLocatorList separately from customReference, GDS recordLocator and externalReferenceIds. We have not established the equivalent writable and readable property in the referenced createReservation, changeReservation or reservation schemas. The Block field reservationDetails.taRecordLocator is documented separately and is not assumed to apply to Reservation.
Oracle's Subject Area Definitions, PDF page 718 maps Travel Agent Locator to EXTERNAL_REFERENCES.EXTERNAL_REFERENCE where EXTERNAL_REFERENCE_TYPE = 'TA_RECORD_LOCATOR'. The RSV schema supports generic externalReferences entries containing id and idContext. Please confirm whether the following inferred candidate is supported for the Stay Details → TA Record Locator input in the target OPERA Cloud release:
{"externalReferences":[{"idContext":"TA_RECORD_LOCATOR","id":"<Tour Code / Block Name>"}]}
This is a candidate fragment, not a verified request. Its generic container paths are /reservations/reservation/0/externalReferences for postReservation, /reservations/0/externalReferences for putReservation and /reservations/reservation/0/externalReferences in getReservation responses. If this context value is not supported, please provide the correct writable and readable mapping instead.
Please provide:
- Supported REST operation and exact JSON path for creating the TA Record Locator on a new Reservation.
- Supported operation and JSON path for setting it on an existing Reservation, including omission vs clearing semantics and preservation of other references.
- getReservation response path and required fetchInstructions, or another supported synchronous readback operation.
- Relevant OPERA Controls, permissions and Reservation Protection behavior; restrictions on length/characters and using the same value on multiple reservations with one guest profile.
- Minimal redacted create, update, exact-detail GET and TA-filtered search examples, plus applicable OPERA/OHIP version.
Please confirm the actual Stay Details input, rather than only the existence of a generic External Reference entry. Custom Reference, GDS Record Locator and Reservation Guest Locator must not be substituted. The database mapping, a search parameter, business-event XML tag or GraphQL field alone does not establish the required REST write/read mapping.
No real hotel identifiers, guest names, credentials or booking data are included in this request.