# 预订任务信息系统业务验收场景清单

版本：V1.0
日期：2026-07-18
适用阶段：无 PMS API

本清单用于需求评审、开发自测和业务验收。页面视觉可参考 `04-前端视觉参考/`，业务判断以主说明书为准。

## 一、任务拆分与卡片组合

### AC-001 只有 New Booking

- 前提：Agent 只识别出一笔 New Booking，没有 Trace、Rooming List 或 Payment。
- 期望：页面依次显示 Basic Information、房间信息、邮件展示；不显示任何空可选卡。

### AC-002 同订单多业务事件

- 前提：同一来源邮件、同一目标订单同时包含 Update、Trace 和 Payment。
- 期望：聚合为一个订单任务；显示 Basic Information、房间信息、Trace、Payment、邮件展示；各业务卡独立确认。

### AC-003 同邮件多个订单

- 前提：一封邮件分别涉及两个目标订单。
- 期望：拆成两笔订单任务；每笔只显示自己的业务事件与附件关联，不根据事件顺序猜测归属。

### AC-004 纯通知

- 前提：没有形成具体预订业务任务。
- 期望：只显示邮件展示卡；不显示 Basic Information、房间信息、人工复核卡或终止入口。

## 二、Basic Information

### AC-005 Account 正常匹配

- 前提：Account 可匹配信息系统目录。
- 期望：Market、Source 自动带出；三项均为受控选择，用户可改选已有值；没有 Manual 和自由输入。

### AC-006 Account 无法确定

- 前提：Agent 已识别具体预订业务，但无法可靠确定 Account。
- 期望：Basic Information 显示“待确认 + 需人工复核”；用户只能从已有目录补选，不能输入新目录值。

## 三、New Booking

### AC-007 Group 普通新建

- 前提：Group New Booking，普通预订。
- 期望：Block Name 显示 Group Code；Group Booking Status 初始为 TEN；房型行按 RoomType、房量、Adult（每间）显示。

### AC-008 Group Proposal

- 前提：Group New Booking，邮件为 Proposal。
- 期望：Group Booking Status 初始为 INQ。

### AC-009 Fit 已有真实姓名

- 前提：Fit 首封邮件同时提供 Booking Code 和真实住客姓名。
- 期望：Name 直接显示真实姓名；已有订单后续操作不使用 Name 定位。

### AC-010 Fit 暂无真实姓名

- 前提：Fit 首封邮件只有 Booking Code，没有真实住客姓名。
- 期望：Name 临时使用 Booking Code；该情况信息完整，不触发人工复核。

### AC-011 New 无 PMS API确认

- 操作：用户确认房间信息卡。
- 期望：保存完整目标参数，卡片已完成并锁定；显示“信息系统已确认，未调用 PMS”；Block ID / Confirmation Number 显示“未接入 PMS API”，不得伪造成功。

## 四、Update Booking

### AC-012 修改日期

- 前提：邮件要求修改入住和/或离店日期。
- 期望：页面突出原日期到修改后日期；Nights 按新日期自动计算；完整最新订单仍可查看。

### AC-013 修改房型或房量

- 前提：原订单为 `TWN × 5 + DBL × 5`，目标改为 `TWN × 3 + DBL × 5`。
- 期望：页面显示修改前和修改后的完整房型清单；不得把仅 `TWN × 3` 当成完整目标而丢失 DBL。

### AC-014 Rate Code 不可在 Update 修改

- 前提：订单已经建立。
- 期望：Rate Code 可作为当前订单信息显示，但不提供原值到新值的修改入口。

### AC-015 Fit Name 更新

- 前提：Fit 原 Name 为 Booking Code，后续邮件提供真实姓名和 Confirmation Number。
- 期望：通过 Confirmation Number 定位原订单，并以 Update 更新 Name；不创建第二笔订单。

### AC-016 Update 无 PMS API确认

- 操作：用户确认 Update 房间信息卡。
- 期望：卡片完成并锁定；最终变化写入信息系统本地订单最新数据；后续本地查单读取新数据；页面明确未调用 PMS。

## 五、Cancel Booking

### AC-017 整单取消

- 前提：Agent 识别为 Cancel Booking并唯一找到订单。
- 期望：完整订单只读展示，只出现“将取消整笔订单”，没有修改后参数。

### AC-018 部分调整不是取消

- 前提：邮件只减少房量、删除房型或修改日期。
- 期望：业务类型为 Update Booking，不是 Cancel Booking。

### AC-019 Cancel 无 PMS API确认

- 操作：用户确认 Cancel 房间信息卡。
- 期望：保留订单和历史，本地标记已取消，页面明确未调用 PMS；后续 Update、Trace、Rooming List、Payment 仍可查看结构但全部禁止确认。

## 六、Trace

### AC-020 普通 Trace

- 前提：邮件要求蜜月布置并指定相关部门。
- 期望：一条普通事项显示事项内容和受控 Department；不显示 RoomType、加床数量或 Adult；内容和 Department 可在确认前修改。

### AC-021 单数加床

- 前提：邮件只写“请给 TWN 加床”，没有其他数量。
- 期望：加床数量默认为 1；显示 `TWN × 1｜Adult 3`（以基础 Adult 2 为例）及 Department；事项默认文本为 `SET EXTRA BED`。

### AC-022 加床与普通事项并存

- 前提：同一订单同时要求加床和蜜月布置。
- 期望：只显示一张 Trace 卡，卡内分别显示一条加床事项和一条普通事项，不丢失任一事项。

### AC-023 Trace 目标房型错误

- 前提：加床目标 RoomType 不存在于当前目标预订或已调出的订单。
- 期望：整笔订单任务进入人工核对；系统不能只改成一条普通文本备注继续确认。

### AC-024 Trace 无 PMS API确认

- 操作：用户确认 Trace 卡。
- 期望：保存全部最终事项，卡片完成并锁定；不改写房间汇总，不宣称部门已同步或加床已生效。

## 七、Rooming List

### AC-025 Group Rooming List

- 前提：Agent 识别出 Group Rooming List 并唯一找到 Group Code。
- 期望：显示 Rooming List 卡和 12 个规定表头；原附件只在邮件展示卡查看；Fit 不生成该卡。

### AC-026 新版 Rooming List

- 前提：同一 Group 后续收到新版 Rooming List 邮件。
- 期望：创建新任务并关联原订单；旧任务、旧邮件和旧确认结果保留。

### AC-027 当前简化范围

- 期望：系统无需证明已经把附件真实转换为 PMS 数据，不要求 Excel 下载、复杂住客编辑或手工 PMS 导入；确认后卡片锁定并把本地 Group Booking Status 处理为 DEF。

## 八、Payment

### AC-028 一笔订单多份凭证

- 前提：同一 Payment 关联多份来源附件。
- 期望：在一张 Payment 卡中展示全部凭证，不按图片拆卡；附件顺序不改变业务含义。

### AC-029 Group Payment

- 操作：用户查看凭证后点击“确认”。
- 期望：Payment 卡完成并锁定，本地 Group Booking Status 更新为 DEF；不显示 Payment Confirmed，不代表 PMS 或到账确认。

### AC-030 Fit Payment

- 操作：用户查看凭证后点击“确认”。
- 期望：Payment 卡完成并锁定，不增加 Group Booking Status 或其他付款字段。

## 九、邮件展示

### AC-031 普通预订邮件证据卡

- 期望：显示当前邮件的主题、发件人、时间、原文和附件；全部只读，附件只可预览或下载；不显示“确认”。

### AC-032 完整邮件线程

- 操作：用户点击“查看完整邮件”。
- 期望：进入该邮件会话；任务邮件卡本身仍只展开当前来源邮件。

### AC-033 纯通知确认

- 操作：用户仅打开页面。
- 期望：任务不自动完成。用户点击“确认”后才完成并锁定，不调用 PMS。

## 十、人工复核与查单校验

### AC-034 单卡人工复核

- 前提：Trace 需要人工复核，Basic Information 与房间信息合法。
- 期望：只有 Trace 显示“待确认 + 需人工复核”并被阻止确认；其他卡可独立确认；订单顶部不增加人工复核状态。

### AC-035 人工复核一步确认

- 前提：用户已按既定权限补正卡片数据。
- 期望：直接点击同一个“确认”完成；不存在“解除复核”或二次确认。

### AC-036 查到 0 笔或多笔订单

- 前提：Agent 没有要求人工复核，但系统未唯一找到已有订单。
- 期望：卡片保持“待确认”；仅定位字段可编辑，其余可见但禁用；显示统一查单提示，不追加“需人工复核”。

## 十一、确认、锁定与终止

### AC-037 多卡独立确认

- 前提：同一订单任务有 Basic、房间信息和 Trace。
- 操作：先确认 Basic。
- 期望：只有 Basic 完成并锁定；房间信息和 Trace 仍保持原状态；订单任务显示“处理中”。

### AC-038 无草稿

- 操作：用户修改未确认字段后离开页面再返回。
- 期望：未确认修改不保留，仍从 Agent 原始值开始；页面没有“保存草稿”。

### AC-039 确认后不可修改

- 前提：某卡已完成。
- 期望：不能再次编辑、确认或重新执行，也不能从该卡创建新任务。

### AC-040 部分卡完成后终止

- 前提：Basic 已完成，房间信息与 Trace 未完成。
- 操作：用户从 Trace 点击“终止任务”。
- 期望：Basic 保持已完成；房间信息和 Trace 变为已终止；订单任务已终止并标记异常；终止不回滚已完成卡。

### AC-041 纯通知没有终止

- 前提：任务只显示邮件展示卡。
- 期望：只有“确认”，没有“终止任务”。

## 十二、异常阻断与技术异常

### AC-042 异常订单后续 Update

- 前提：订单曾因人工终止被标记异常，后续 Agent 生成新的 Update。
- 期望：页面可查看邮件和卡片，但任务状态为“异常阻断”；没有可用确认或终止入口，不调用 PMS。

### AC-043 AMEND GROUP CODE

- 前提：邮件要求修改已创建 Group 的 Group Code。
- 期望：作为纯通知，只显示邮件卡；用户在 PMS 外部处理后回系统点击“确认”；不创建旧/新 Group Code 业务卡。

### AC-044 Agent 技术契约错误

- 前提：信息系统收到无法安全解析的 Agent 技术输出。
- 期望：不创建酒店用户可见任务、列表行或卡片；交由开发处理，不转换成纯通知或人工复核。

## 十三、订单任务汇总状态

### AC-045 全部未完成

- 期望：订单任务显示“待处理”。

### AC-046 部分完成

- 期望：订单任务显示“处理中”，不显示完成数量。

### AC-047 全部完成

- 期望：订单任务显示“已完成”。

### AC-048 任一卡终止

- 期望：订单任务显示“已终止”，未完成卡已终止，已完成卡保持已完成。

### AC-049 异常订单的新任务

- 期望：订单任务显示“异常阻断”，不是待处理、人工复核或已终止。