实现M002 V3 P0.1 Parent Group路由修订
This commit is contained in:
@@ -0,0 +1,92 @@
|
||||
# 修改预订
|
||||
|
||||
## 适用业务
|
||||
|
||||
用于当前邮件要求修改既有:
|
||||
|
||||
- FIT Reservation
|
||||
- Group Block
|
||||
- 日期、晚数、房型、房量、人数、价格、Rate Code、备注或其他订单细节
|
||||
|
||||
## 支持的修改
|
||||
|
||||
- `update_stay_dates`
|
||||
- `update_nights`
|
||||
- `update_room_type_or_quantity`
|
||||
- `update_guest_count`
|
||||
- `manual_rate_code_or_settlement_price`
|
||||
- `update_fix_charge`
|
||||
- 与主修改同现的 guest request 线索
|
||||
|
||||
## 不适用
|
||||
|
||||
- Parent-to-child allocation creation,child creation 走 `New Booking`。
|
||||
- 旧 Group Code 改新 Group Code,走 `AMEND GROUP CODE`。
|
||||
- 只有 extra bed,走 `Trace`。
|
||||
- 只有 voucher/payment evidence。
|
||||
- 只有 Rooming List。
|
||||
- 动作只在历史邮件中。
|
||||
- 纯确认或信息消息不属于 Update;其中包含具体预订补充信息时按 `Trace` 处理。
|
||||
- 独立的部分 Allotment / Control Block 房量、日期或范围维护,以及明确保留 parent 余量继续使用;当前不支持,不得输出 Update 或 `Allotment Maintenance`。整封邮件只有该意图时走 S10;同邮件另有支持事件时按 `03-current-content-completeness.md` 进入 `unhandled_current_intents`。
|
||||
|
||||
## 必要证据
|
||||
|
||||
普通候选事件需要:
|
||||
|
||||
- 当前 amendment action。
|
||||
- existing target key 或唯一目标绑定。
|
||||
- reliable before/after 或明确 change detail。
|
||||
- 涉及入住、离店或晚数时,按 `54-stay-date-parsing.md` 解析并保留日期证据。
|
||||
- 系统上下文支持继续处理。
|
||||
- 涉及必需房型、Rate Code 或 Fix Charge 时,必须由对应 reference 唯一支持;业务必需字段不唯一时不得用 downstream hard validation 代替人工确认。
|
||||
|
||||
## Before / After
|
||||
|
||||
可得时保留:
|
||||
|
||||
```json
|
||||
{
|
||||
"before_after": [
|
||||
{
|
||||
"field": "arrival_date",
|
||||
"before": "",
|
||||
"after": "",
|
||||
"evidence": ""
|
||||
}
|
||||
]
|
||||
}
|
||||
```
|
||||
|
||||
当前 amendment 类型和 Update subtype 已确定、但无法建立可靠 before/after 时,保留 `Update Booking / Amendment` 并附非空 `manual_review`。
|
||||
|
||||
日期相关 before/after 必须保留 `hotel_date_raw`、`tour_date_raw`、`action_date_raw`、`sheet_month_year` 和 `date_inference_basis`,如适用。
|
||||
|
||||
## Linked Trace
|
||||
|
||||
Extra bed、Meeting、meal、arrival notice、room preference/setup、已确定的 payment information 或其他具体预订补充信息与有效 update 同现时:
|
||||
|
||||
- 输出主 `Update Booking / Amendment`。
|
||||
- 按目标输出一个 linked `Trace`;同一目标的多条补充信息合并。
|
||||
- 补充信息即使只是告知,也生成 Trace。
|
||||
- Update 已完整承接的 before/after 核心字段不得重复写成 Trace。
|
||||
|
||||
如果当前只有 Trace 补充信息,或只要求 add/update/cancel extra bed,不创建 Update 事件。
|
||||
|
||||
## Fix Charge
|
||||
|
||||
Fix Charge 可通过 Update 维护,但必须确认目标和动作类型:add、update 或 cancel。Update 及 subtype 已知、但目标、动作或金额不安全时,保留 `Update Booking / Amendment` 并附非空 `manual_review`;只有 Update subtype 本身无法确定时才使用 Fallback。
|
||||
|
||||
## 业务复核
|
||||
|
||||
当前证据已经能确定 `event_type=Update Booking / Amendment` 及其 Update subtype 时,以下问题保留原业务事件,并使用非空、完整的 `manual_review`:
|
||||
|
||||
- 原订单找不到或目标不清。
|
||||
- 前置任务未完成或系统上下文阻塞。
|
||||
- before/after 不可靠。
|
||||
- 必需 room mapping、Rate Code 或 price 不唯一。
|
||||
- Fix Charge 动作或金额不清。
|
||||
- QBD/LianTai 当前行已确定为 Update,但 row、highlight 或 strikethrough 证据不完整。
|
||||
|
||||
保留已确认的 before/after、目标候选和原始字段;缺失字段使用 RFC 6901 JSON Pointer 写入 `manual_review.missing_fields[]`。
|
||||
|
||||
只有当前动作无法在 New Booking、Update Booking、Cancel 或 Amend Group Code 之间确定,或者 Update subtype 本身无法确定时,才输出 `event_type=Need Manual Review` 的 Fallback 复核。
|
||||
Reference in New Issue
Block a user