518 lines
22 KiB
Markdown
518 lines
22 KiB
Markdown
# 预订任务信息系统业务需求说明书
|
||
|
||
版本：V1.0
|
||
日期：2026-07-18
|
||
状态：业务交付基线
|
||
当前运行边界：尚未接入 PMS API
|
||
|
||
## 1. 文档目的
|
||
|
||
本说明书用于向信息系统开发人员说明酒店预订任务工作台及任务详情页的业务要求。本文只规定业务目标、业务数据、页面行为、状态和操作结果，不规定数据库、接口或代码实现方式。
|
||
|
||
开发完成后的系统应让酒店预订与运营人员能够：
|
||
|
||
- 查看由来源邮件触发的订单任务；
|
||
- 核对 Agent 识别出的预订业务参数；
|
||
- 按既定权限补正或改选参数；
|
||
- 分别确认每张业务任务卡；
|
||
- 清楚区分待确认、人工复核、已完成、已终止和异常阻断；
|
||
- 在没有 PMS API 时明确知道“信息系统已确认”不等于“PMS 已执行”。
|
||
|
||
## 2. 范围与排除项
|
||
|
||
### 2.1 本次包含
|
||
|
||
- 来源邮件及附件的任务内展示；
|
||
- Group 与 Fit 预订任务；
|
||
- New Booking、Update Booking、Cancel Booking；
|
||
- Basic Information、房间信息、Trace、任务详情内嵌 Rooming List、Payment；
|
||
- 纯通知任务；
|
||
- 人工复核、查单校验、逐卡确认、确认后锁定；
|
||
- 人工终止、异常订单和后续异常阻断；
|
||
- 当前无 PMS API 时的信息系统内业务结果。
|
||
|
||
### 2.2 本次不包含
|
||
|
||
- 根级 Invoice 页面。该页面属于独立信息系统，不要求 Agent 提供参数；
|
||
- 根级 `/rooming-list` 页面。该页面同样属于独立信息系统；
|
||
- Agent 如何识别、提取、训练或调用 Skill；
|
||
- 数据库、接口、服务拆分和代码方案；
|
||
- 真实 PMS API 尚未提供的请求、失败、重试和回执规则。
|
||
|
||
## 3. 业务参与方与完整链路
|
||
|
||
目标完整链路为：
|
||
|
||
`邮件历史线程 → Agent 识别业务与定位参数 → 信息系统查单、展示、校验和接受人工确认 → PMS API 执行 → PMS 返回结果`
|
||
|
||
各方业务责任如下：
|
||
|
||
- 邮件与历史线程：提供当前业务要求及历史定位信息；
|
||
- Agent：判断具体业务类型，给出目标订单及邮件要求的目标参数，并在需要时标记人工复核；
|
||
- 信息系统：按目标订单组织任务，查询当前订单，展示和校验数据，接受用户按权限修改并记录最终确认；
|
||
- PMS：未来负责真实的新建、更新、取消和备注等酒店业务操作，并返回真实结果。
|
||
|
||
当前没有 PMS API，因此信息系统不得把缺失的 PMS 能力转移给 Agent，也不得伪造 PMS 成功、编号或回执。
|
||
|
||
## 4. 订单任务与任务卡
|
||
|
||
### 4.1 订单任务单位
|
||
|
||
一笔订单任务由“同一来源邮件 + 同一目标订单”确定。
|
||
|
||
- 同一封邮件涉及多个订单时，按目标订单拆成多笔订单任务；
|
||
- 同一封邮件中属于同一订单的主预订事件、Trace、Rooming List 和 Payment，聚合到同一个任务详情；
|
||
- 订单任务只是聚合容器，真正独立确认和锁定的单位是任务卡。
|
||
|
||
### 4.2 普通预订任务的卡片顺序
|
||
|
||
固定顺序为：
|
||
|
||
`Basic Information → 房间信息 → Trace → Rooming List → Payment → 邮件展示`
|
||
|
||
- Basic Information、房间信息、邮件展示固定出现；
|
||
- Trace、Rooming List、Payment 按 Agent 是否识别出对应业务决定；
|
||
- 不存在对应业务时直接跳过，不显示空卡、占位卡或统一“条件卡片”容器；
|
||
- Voucher 已并入 Payment，不存在独立 Voucher 卡。
|
||
|
||
### 4.3 纯通知任务
|
||
|
||
没有形成具体预订业务任务时，页面只显示邮件展示卡：
|
||
|
||
- 不显示 Basic Information、房间信息或其他业务卡；
|
||
- 邮件展示卡是唯一可确认任务卡；
|
||
- 用户点击“确认”后任务完成；
|
||
- 仅打开页面不会自动完成；
|
||
- 不提供人工终止，不调用 PMS，也不修改订单。
|
||
|
||
## 5. 通用任务卡规则
|
||
|
||
### 5.1 独立确认
|
||
|
||
Basic Information、房间信息，以及实际出现的 Trace、Rooming List、Payment，分别是独立任务卡。
|
||
|
||
- 每张卡有自己的“确认”按钮；
|
||
- 不存在订单任务级的全局确认按钮；
|
||
- 点击某张卡的“确认”只提交、执行并锁定该卡；
|
||
- 一张卡的问题不阻塞同一订单任务中的其他合法卡片。
|
||
|
||
普通预订中的邮件展示卡只是来源证据，不显示“确认”；纯通知中的邮件展示卡例外，是唯一可确认卡。
|
||
|
||
### 5.2 确认前编辑与草稿
|
||
|
||
- 用户只能按各字段既定权限编辑；人工复核不等于所有字段都能自由输入；
|
||
- 未确认修改只保留在当前页面，离开后无需保存；
|
||
- 不自动保存，也不提供“保存草稿”；
|
||
- 信息系统长期保留 Agent 原始值与用户最终确认值，不保存每一次中间编辑历史。
|
||
|
||
### 5.3 确认后锁定
|
||
|
||
- 每张卡只能确认一次；
|
||
- 确认后卡片永久锁定，不能再次编辑、确认或重新执行；
|
||
- 信息系统不能从已完成卡片复制或创建新业务任务；
|
||
- 新任务只能由新的邮件或其他程序输入再次触发 Agent 后产生；
|
||
- 执行后发现错误，不能修改旧任务伪装成回滚。未来可直接在 PMS 中纠正，后续新任务再读取 PMS 最新数据。
|
||
|
||
### 5.4 卡片状态
|
||
|
||
任务卡业务状态包括：
|
||
|
||
- 待确认；
|
||
- 待确认 + 需人工复核；
|
||
- 已完成；
|
||
- 已终止。
|
||
|
||
“需人工复核”是待确认卡上的附加标记，不是每张卡都必经的独立步骤。
|
||
|
||
### 5.5 订单任务汇总状态
|
||
|
||
- 所有可执行卡均未完成：待处理；
|
||
- 至少一张完成且仍有卡未完成：处理中；
|
||
- 所有可执行卡均完成：已完成；
|
||
- 任一卡触发订单级终止：已终止；
|
||
- 异常订单后续新任务被阻断：异常阻断。
|
||
|
||
订单任务不显示“已完成 2/5”等进度计数。单卡的“需人工复核”不上卷为订单级状态或额外提示。普通预订邮件证据卡不参与状态汇总。
|
||
|
||
## 6. 人工复核、系统查单校验与卡型错误
|
||
|
||
### 6.1 人工复核
|
||
|
||
人工复核由 Agent 针对已经确定的具体业务卡给出。
|
||
|
||
- 卡片仍使用原业务类型，不生成独立人工复核卡；
|
||
- 页面显示“待确认 + 需人工复核”；
|
||
- 用户查看原邮件，按该卡原有字段权限补正或核对；
|
||
- 数据满足校验后，直接点击同一个“确认”完成；
|
||
- 不设置“确认修改”“解除复核”或二次确认步骤；
|
||
- 无法确定具体业务类型时走纯通知，不生成 Fallback 或 Need Manual Review 卡。
|
||
|
||
### 6.2 已有订单的唯一匹配门槛
|
||
|
||
Update、Cancel、Trace、Rooming List、Payment 等已有订单业务，必须先唯一匹配订单。
|
||
|
||
- Group 使用 Group Code，即 Block Name；
|
||
- Fit 使用 Confirmation Number；
|
||
- 当前无 PMS API 时查询信息系统已有订单；未来有 API 时查询 PMS；
|
||
- 查询到 0 笔或多笔都不允许系统自动选择；
|
||
- 匹配前仍显示完整业务卡，但只有定位字段可编辑，其余字段可见但禁用，“确认”不可用；
|
||
- 统一提示：“未唯一匹配到订单，请核对 Group Code / Confirmation Number”；
|
||
- 如果 Agent 没有要求人工复核，系统查单失败仍保持“待确认”，不能自行追加“需人工复核”。
|
||
|
||
### 6.3 卡型错误
|
||
|
||
用户发现 Agent 漏识别、误识别或生成错误卡型时：
|
||
|
||
- 信息系统不自动重跑 Agent；
|
||
- 用户不能在详情页自行新增、删除或切换业务卡；
|
||
- 用户从任一未完成预订业务卡触发“终止任务”；
|
||
- 纯通知任务不存在人工终止。
|
||
|
||
## 7. Basic Information 卡
|
||
|
||
字段固定为：`Account → Market → Source`。
|
||
|
||
- 三项都只能从信息系统已有目录中选择，不允许自由输入；
|
||
- Account 没有 Manual 选项；
|
||
- 系统根据 Account 目录关系自动带出 Market 与 Source；
|
||
- 用户仍可在已有目录中分别改选 Account、Market、Source；
|
||
- 没有可靠 Account 或目录无法匹配时，该卡进入人工复核，用户从已有目录补选；
|
||
- 如果系统目录本身缺少选项，应走主数据维护，不能在任务卡临时输入新值。
|
||
|
||
当前无 PMS API 时，点击“确认”只保存最终 Account、Market、Source，卡片变为已完成并锁定，不产生任何 PMS 成功语义。
|
||
|
||
## 8. 房间信息卡的公共业务结构
|
||
|
||
### 8.1 Group 与 Fit
|
||
|
||
Group：
|
||
|
||
- 卡头显示 Group；
|
||
- 对象标识为 Block Name；
|
||
- `Block Name = Group Code`，它是邮件中的团号，不是住客姓名；
|
||
- 显示 Group Booking Status，受控值为 TEN、DEF、INQ。
|
||
|
||
Fit：
|
||
|
||
- 卡头显示 Fit；
|
||
- 对象标识为 Name；
|
||
- 不再使用 Con. No. 或 `Block Name/Con. No.` 组合名称。
|
||
|
||
### 8.2 订单级字段
|
||
|
||
- Block Name 或 Name；
|
||
- 入住日期；
|
||
- 离店日期；
|
||
- Nights；
|
||
- 订单级 Rate Code，只显示一次；
|
||
- Breakfast；
|
||
- Group 额外显示 Group Booking Status。
|
||
|
||
### 8.3 房型行
|
||
|
||
每行固定为：`RoomType → 房量 → Adult（每间）`。
|
||
|
||
- 允许多行房型；
|
||
- RoomType 只能从信息系统已有房型选择；
|
||
- 房量为正数，用户可修改；
|
||
- Adult 表示每间成人数，不是该行成人总数；
|
||
- Adult 由 RoomType 的系统映射产生，普通房间信息卡中不允许直接修改；
|
||
- 同一 RoomType 只有 Adult 不同时才允许拆成多行；
|
||
- Rate Code 不放在房型行内，也不按 Rate Code 拆分房型。
|
||
|
||
### 8.4 字段规则
|
||
|
||
- 入住与离店日期可由用户纠错；任一缺失进入人工复核；
|
||
- Nights 由系统根据日期计算，不由用户覆盖；
|
||
- Rate Code 必填、无默认值，只能从系统已有值选择；
|
||
- Group 固定包含早餐；Fit 的 Breakfast 由 Rate Code 规则派生，不能直接修改；
|
||
- 普通 Group New 初始状态为 TEN；Proposal 为 INQ；Group 的 Rooming List 或 Payment 确认后处理为 DEF；
|
||
- 用户可在卡片确认前从 TEN、DEF、INQ 中受控改选 Group Booking Status。
|
||
|
||
### 8.5 Fit Name 生命周期
|
||
|
||
- 首封邮件已有真实住客姓名：直接使用真实姓名创建；
|
||
- 首封邮件没有真实姓名但有 Booking Code：以 Booking Code 临时作为 Name，信息完整，不触发人工复核；
|
||
- 后续邮件提供真实姓名：通过正式 Update Booking 更新同一订单的 Name；
|
||
- 更新为真实姓名后，Booking Code 不再作为订单关联键或 PMS Name；
|
||
- 已有 Fit 订单后续操作使用 Confirmation Number 定位，不使用 Name。
|
||
|
||
### 8.6 PMS 创建结果
|
||
|
||
未来 PMS New Booking 成功后：
|
||
|
||
- Group 返回 Block ID；
|
||
- Fit 返回 Confirmation Number；
|
||
- 两项均在房间信息卡和执行结果/订单信息区域显示；
|
||
- 两项只读，不允许用户修改；
|
||
- 当前无 PMS API 时不得生成模拟值，显示“未接入 PMS API”。
|
||
|
||
## 9. New Booking
|
||
|
||
- 展示完整目标预订信息；
|
||
- 用户按各字段权限在确认前纠错；
|
||
- Group Code 同时作为 Block Name；
|
||
- Fit 没有真实姓名时使用 Booking Code 作为初始 Name；
|
||
- Group 普通预订初始 TEN，Proposal 初始 INQ；
|
||
- 确认后原 New Booking 卡永久锁定；
|
||
- 创建后的任何变化都属于新的 Update Booking，不能重新打开原 New Booking。
|
||
|
||
当前无 PMS API时：
|
||
|
||
- 保存用户最终确认的完整目标预订参数；
|
||
- 房间信息卡变为已完成并锁定；
|
||
- 结果明确显示“信息系统已确认，未调用 PMS”；
|
||
- 不显示“创建成功”，不生成 Block ID 或 Confirmation Number。
|
||
|
||
## 10. Update Booking
|
||
|
||
### 10.1 定位与当前订单
|
||
|
||
- Group 一律使用 Group Code / Block Name 定位，不优先使用 Block ID；
|
||
- Fit 一律使用 Confirmation Number 定位，不使用 Name；
|
||
- 当前订单参数由信息系统查询取得，Agent 不提供原参数。
|
||
|
||
### 10.2 页面展示
|
||
|
||
- 显示修改后的完整最新订单；
|
||
- 对发生变化的字段突出显示“原参数 → 修改后参数”；
|
||
- 日期变化同时显示系统重新计算的 Nights；
|
||
- 房型或房量变化时，分别展示修改前完整房型清单和修改后完整房型清单；
|
||
- 不追踪某一原房型行如何新增、删除、拆分或转换；
|
||
- Rate Code 在建单时确定，不属于 Update 可修改字段；
|
||
- Fit Name、日期、RoomType 和房量可作为 Update 内容。
|
||
|
||
### 10.3 当前无 PMS API
|
||
|
||
- 确认后保存最终修改后参数；
|
||
- 把最终变化应用到信息系统内的本地订单最新数据，供后续无 API 任务查询；
|
||
- 卡片变为已完成并锁定；
|
||
- 结果显示“信息系统已确认，未调用 PMS”；
|
||
- 不生成新的 PMS 标识或 PMS 更新回执。
|
||
|
||
## 11. Cancel Booking
|
||
|
||
- Group 与 Fit 都只允许整单取消；
|
||
- 页面先调出并只读展示完整当前订单；
|
||
- 不存在修改后参数，只表达“将取消整笔订单”；
|
||
- 减少房量、删除房型、修改日期或修改 Name 都属于 Update，不属于 Cancel。
|
||
|
||
当前无 PMS API时：
|
||
|
||
- 保存整单取消意图、目标订单和确认时展示的原订单参数；
|
||
- 保留订单及所有历史，将本地订单标记为已取消；
|
||
- 卡片变为已完成并锁定；
|
||
- 结果显示“信息系统已确认，未调用 PMS”；
|
||
- 不删除订单、不清除 PMS 标识，也不伪造 PMS 已取消；
|
||
- 后续仍可定位该记录，但新的 Update、Trace、Rooming List、Payment 显示“订单已取消”并禁止确认。
|
||
|
||
## 12. Trace 卡
|
||
|
||
### 12.1 出现与数量
|
||
|
||
- New Booking 和 Update Booking 可以带 Trace；Cancel Booking 不会带 Trace；
|
||
- 未识别出 Trace 时不显示；
|
||
- 同一订单只显示一张 Trace 卡，卡内可以包含多条事项；
|
||
- Trace 关联整笔订单，不默认拆成日期、房间或住客级任务；
|
||
- Trace 与 Rooming List 没有业务前后置关系。
|
||
|
||
### 12.2 普通备注
|
||
|
||
每条普通备注包含：
|
||
|
||
- 事项内容：由 Agent 根据邮件提炼，确认前允许用户修改；
|
||
- Department：只能选择信息系统预设部门或组合部门，确认前允许改选。
|
||
|
||
没有可识别事项内容就不存在该 Trace item，不创建空事项。
|
||
|
||
### 12.3 加床备注
|
||
|
||
加床备注默认事项内容为 `SET EXTRA BED`，并显示：
|
||
|
||
- 目标 RoomType；
|
||
- 加床房间数量；
|
||
- 加床后 Adult（每间）；
|
||
- Department。
|
||
|
||
业务规则：
|
||
|
||
- 目标 RoomType 只能从当前预订已有房型中选择；
|
||
- 加床房间数量允许用户修改；邮件只写单数“加床”且无其他数量时，默认 1 间；
|
||
- 加床后 Adult 由系统按当前 Adult +1 产生初始值，用户可在 Trace 卡确认前修改；
|
||
- 页面把三项相邻回显，例如 `TWN × 1｜Adult 3`；
|
||
- Adult 表示加床后的每间成人数，不表示加床房间数量；
|
||
- Department 应由 Agent提供受控值；如果运行异常导致缺失，信息系统以 `FO+HSK` 兜底并允许用户改选；
|
||
- 加床可以与蜜月布置等普通备注同时存在；
|
||
- 目标房型缺失或不属于当前订单，说明订单关联或解析错误，整笔订单需要人工核对。
|
||
|
||
### 12.4 当前无 PMS API
|
||
|
||
- 点击“确认”保存卡内全部最终事项和确认时间；
|
||
- 卡片变为已完成并锁定；
|
||
- 结果显示“信息系统已确认，未调用 PMS”；
|
||
- 不宣称 Department 已同步、Trace 已写入 PMS或加床已生效；
|
||
- 不改写房间信息卡或订单房间汇总。已锁定 Trace 中的 `TWN × 1｜Adult 3`只表示已确认的目标参数。
|
||
|
||
## 13. 任务详情内嵌 Rooming List
|
||
|
||
### 13.1 业务范围
|
||
|
||
- 只有 Agent 识别出 Rooming List 时才显示；
|
||
- 只适用于 Group，Fit 不会有 Rooming List；
|
||
- 一封邮件涉及多个订单时按订单拆任务；
|
||
- 同一 Group 后续收到新版 Rooming List 时，为新邮件创建新任务并关联原订单，旧任务与旧邮件保留；
|
||
- 使用 Group Code / Block Name 查询原 Group 订单，不优先使用 Block ID；
|
||
- 原始附件只在邮件展示卡查看，不在 Rooming List 卡重复展示。
|
||
|
||
### 13.2 当前简化展示
|
||
|
||
当前尚无 PMS API，本阶段只要求识别任务并展示类似标准表格的卡片。表头显示以下 12 个业务字段：
|
||
|
||
`Name → First Name → Arrival → Departure → Room Type → Rate Code → Number of Rooms → Adults → Children → Payment Type → Accompanying Guests → Nationality`
|
||
|
||
- Line 如显示，只是前端辅助序号；
|
||
- 表格内容可以使用演示数据，不要求证明已经准确转换原附件；
|
||
- 当前不要求真实逐位住客解析、同住分组、复杂编辑、分页、固定列、Excel 下载或手工导入 PMS；
|
||
- 用户点击“确认”后卡片完成并锁定；
|
||
- 当前确认只表示信息系统已确认，未调用 PMS；
|
||
- Group Booking Status 按业务规则处理为 DEF；
|
||
- 未来取得 PMS API 后，重新确认真实住客、字段、校验和执行参数，直接通过 API，不经过 Excel。
|
||
|
||
## 14. Payment 卡
|
||
|
||
### 14.1 出现与展示
|
||
|
||
- Payment 是否存在由 Agent 识别，信息系统不重新判断“什么算付款”；
|
||
- Payment 只属于 Update Booking；
|
||
- Group 与 Fit 都可能出现；
|
||
- 一封邮件涉及多个订单时按订单拆任务；
|
||
- 同一订单的多份付款凭证在一张 Payment 卡中全部展示，不按附件拆卡；
|
||
- 凭证之间没有业务顺序；
|
||
- Voucher 与 Payment Evidence 都统一为 Payment，不存在独立 Voucher 卡。
|
||
|
||
### 14.2 当前所需业务数据
|
||
|
||
- Payment 事件；
|
||
- 目标订单；
|
||
- 与当前 Payment 对应的一份或多份来源附件。
|
||
|
||
当前不需要金额、付款日期、付款人、交易号、银行账号、QR、备注、付款状态或 Department。凭证存在不等于酒店已确认到账。
|
||
|
||
### 14.3 当前无 PMS API
|
||
|
||
- 用户先查看凭证，再点击“确认”；
|
||
- Group：本地 Group Booking Status 更新为 DEF，Payment 卡完成并锁定；
|
||
- Fit：Payment 卡直接完成并锁定，不新增其他订单字段；
|
||
- 不显示 Payment Confirmed，不代表到账确认或 PMS 成功；
|
||
- 当前不设计 PMS 失败、重试或回执，也没有独立“重试”按钮。
|
||
|
||
## 15. 邮件展示卡
|
||
|
||
邮件展示卡只展开触发当前任务的这一封来源邮件，不在卡内展开整条历史线程。
|
||
|
||
固定显示：
|
||
|
||
- 邮件主题；
|
||
- 发件人；
|
||
- 发送时间；
|
||
- 邮件原文；
|
||
- 当前邮件原始附件。
|
||
|
||
同时提供“查看完整邮件”入口，用于打开对应邮件会话。
|
||
|
||
权限规则：
|
||
|
||
- 主题、发件人、时间和正文只读；
|
||
- 附件允许预览或下载，不允许新增、删除或替换；
|
||
- 业务卡内的修改不能反向改写来源邮件；
|
||
- 普通预订中邮件卡只是证据；纯通知中邮件卡是唯一可确认任务卡。
|
||
|
||
附件业务要求：
|
||
|
||
- 每个附件至少具备稳定标识、文件名、内容类型和可访问地址；文件大小可选；
|
||
- 访问地址由邮件监听或文件存储提供，Agent 只能原样传递；
|
||
- Payment 只引用邮件附件，不复制第二份完整附件对象。
|
||
|
||
## 16. 人工终止、异常订单与后续阻断
|
||
|
||
### 16.1 人工终止
|
||
|
||
- 每张尚未完成、未被异常阻断的预订业务卡都可触发“终止任务”；
|
||
- 操作作用于整笔订单任务，不是只终止当前卡；
|
||
- 所有未完成卡变为已终止并锁定；
|
||
- 已完成卡继续保持已完成，保留其真实参数、确认时间和业务结果；
|
||
- 订单任务整体变为已终止；
|
||
- 终止不调用 PMS，也不回滚已完成卡；
|
||
- 纯通知任务没有“终止任务”。
|
||
|
||
### 16.2 异常订单
|
||
|
||
人工终止后，关联订单标记为异常订单：
|
||
|
||
- 异常标识说明 Agent 结果或订单上下文不可信；
|
||
- 酒店用户不负责维护或解除异常标识；
|
||
- 后续新任务仍可查看邮件和卡片内容，但状态为“异常阻断”；
|
||
- 不显示可用确认入口，不允许调用 PMS；
|
||
- 异常问题交由开发或 Agent 维护人员调查。
|
||
|
||
### 16.3 终止记录
|
||
|
||
- 固定原因：人工终止；
|
||
- 记录终止时间；
|
||
- 不要求自由文本原因；
|
||
- 当前没有账户架构，不记录或伪造终止人；
|
||
- 原邮件和 Agent 结果复用任务已有引用，不重复保存副本。
|
||
|
||
## 17. 纯通知与特殊结果
|
||
|
||
以下情况统一采用纯通知页面：
|
||
|
||
- 内容可理解但不属于预订部自动处理；
|
||
- 无法可靠判断具体任务类型；
|
||
- 材料不足或附件不可用，无法形成具体业务事件；
|
||
- 极少数 AMEND GROUP CODE 业务，由用户在 PMS 外部人工处理。
|
||
|
||
页面只显示邮件展示卡。用户完成必要的外部处理后点击“确认”，任务完成并锁定；不显示业务字段、人工复核卡或人工终止。
|
||
|
||
不再存在 S99、独立 Need Manual Review、Fallback、未处理意图卡或独立 Voucher 卡。
|
||
|
||
信息系统收到无法解析的 Agent 技术输出属于技术异常：不创建酒店用户可见任务或卡片，由开发处理。该技术异常不能伪装成纯通知或人工复核。
|
||
|
||
## 18. 记录与审计要求
|
||
|
||
每张可执行卡独立保存：
|
||
|
||
- Agent 原始业务值；
|
||
- 用户最终确认值；
|
||
- 卡片状态；
|
||
- 确认时间；
|
||
- 当前阶段适用的业务结果；
|
||
- 锁定状态。
|
||
|
||
当前不记录确认人。终止记录只保存固定原因和终止时间。不得保存未确认草稿或逐次中间编辑历史。
|
||
|
||
## 19. 当前无 PMS API 的统一原则
|
||
|
||
- “已完成”表示该任务卡已经在信息系统内完成确认和当前阶段要求的本地处理；
|
||
- “已完成”不等于 PMS 已成功执行；
|
||
- 不伪造 Block ID、Confirmation Number、PMS 成功回执、部门已同步、付款已确认或加床已生效；
|
||
- New、Update、Cancel、Trace 的结果明确显示“信息系统已确认，未调用 PMS”；
|
||
- Update 更新本地订单最新数据，Cancel 标记本地已取消，Group Payment / Rooming List 可按业务规则更新本地 Group Booking Status；
|
||
- 上述本地变化只服务当前演示和后续本地查单，不宣称 PMS 已同步；
|
||
- PMS 的请求、失败、重试、回执和再次提交规则等取得真实 API 后再确认。
|
||
|
||
## 20. 业务验收与后续事项
|
||
|
||
开发应使用 `03-业务验收场景清单.md` 完成需求评审和业务验收，并使用 `02-业务字段与卡片规则矩阵.md` 检查字段权限与确认结果。
|
||
|
||
以下事项明确后置，不阻塞当前开发：
|
||
|
||
- 真实 PMS API 参数和执行结果；
|
||
- Rooming List 的真实住客解析、同住分组和 PMS API 数据结构；
|
||
- 账户体系建立后的确认人、终止人；
|
||
- 无附件与附件监听/读取失败的精确技术表达；
|
||
- Agent 最终 JSON Schema、训练案例和 Skill 调试；
|
||
- 根级 Invoice 与根级 Rooming List 的独立业务说明。
|
||
|
||
开发不得使用后置事项自行扩展当前业务范围，也不得从旧代码、旧 M002 文档或历史讨论恢复已经废止的规则。
|