# Voucher 与付款凭证

## 适用业务

仅当当前邮件包含真实当前 voucher 或 payment evidence 时使用：

- 当前附件图片
- 当前 inline image
- 当前 PDF
- 当前 downloaded file reference

事件类型：

- `Voucher Received`
- `Payment Evidence`

两者共享当前附件、目标绑定和安全规则，但不是同一个事件：实际 `CREDIT VOUCHER` 文档输出 `Voucher Received`；银行转账、现金存款或交易回执输出 `Payment Evidence`。Voucher 不证明资金到账，Payment Evidence 也不表示酒店已经确认付款。

## Credit Voucher

典型信号：

- LT / LianTai logo。
- 泰國聯泰旅運集團有限公司 / `LIAN TAI TRAVEL GROUP (THAILAND) CO., LTD.`
- `CREDIT VOUCHER`
- `DATE`、`CODE / 團號`、`IN`、`OUT`
- `SGL`、`TWN`、`TRP`
- `B`、`L`、`D`
- 手写、盖章或签名

`CODE / 團號` 是优先目标来源。已经确定事件为 `Voucher Received`、但该字段模糊、空白或冲突时，保留 `Voucher Received` 并附非空 `manual_review`。

## Bank Transfer Slip

付款证据可包括：

- 银行转账成功截图
- 现金存款收据
- 交易收据
- payment slip
- payment confirmation 图片/PDF

## 不得仅凭文本触发

以下信号不能单独触发：

- 关键词 `voucher` / `payment slip`
- subject `FULL PAYMENT`
- 文字说 voucher 已发送
- 只有附件文件名
- 酒店回复 thanking voucher
- 只有历史中的 voucher
- 没有当前 image/PDF/file evidence 的表格状态

只有被动文本或文件名提到 voucher、但没有当前 image/PDF/file 对象，也没有明确 current 收件/处理信号时，不足以形成支持业务事件；整封邮件没有其他 active 信号则由 Main Agent 输出 `S10`。如果 current 正文明确信号已经足以确定 `Voucher Received` 或 `Payment Evidence`，只是必要附件缺失、无法取得或不可读，则仍形成对应粗候选；Skill 保留该已知业务事件并附非空 `manual_review`，不得降级为 S10/S99/Fallback。

当前文件对象存在，且当前证据已经能唯一确定 `Voucher Received` 或 `Payment Evidence` 时，即使文件部分不可读或目标不安全，也保留该业务 `event_type` 并附非空 `manual_review`。当前证据已确认属于 voucher/payment evidence 业务方向、但无法在两个事件类型之间确定时，输出 `event_type=Need Manual Review` 的 Fallback 复核；如果连是否属于受支持业务方向都无法判断，则按入口规则使用 S99。

## 同邮件其他付款内容

- 当前付款凭证与需要酒店决定的付款安排询问同现时，付款文件输出 `Payment Evidence`，询问原文按 `03-current-content-completeness.md` 输出到 `unhandled_current_intents`。
- 例如“余款能否入住时支付”是付款政策审批询问，不是 `Payment Notice`，也不得改名为 Trace。
- “余款将在入住时支付”是已经确定、需要随预订保留的补充付款安排，可以按 `16-trace-notes.md` 输出 `Trace.payment_information`。
- 当前凭证与未覆盖意图必须分别保留；不得因为付款图片已成功路由就丢弃正文中的审批询问。

## 目标绑定

一个 voucher/payment event 绑定一个目标 group code 或 reservation key。多个 group code 必须拆分。

一张 bank slip 覆盖多个 group code 时，每个 group code 输出一个事件，并在 `extracted_fields.related_group_codes` 保留完整集合。多个事件可以共享同一个 `voucher_attachment.file_reference`。

不要把 amount、date、bank account、payer、payee、reference number、QR 或 memo 抽成业务字段。用户应查看原始图片或 PDF。

## 下游意图

事件可以保留下游意图：付款确认后将 Reservation Type 更新为 `PD`。本 skill 不确认 payment，也不执行更新。

```json
{
  "voucher_attachment": {
    "display_original": true,
    "file_reference": ""
  },
  "requires_department_routing": true,
  "department_routing": [
    {
      "department": "Finance",
      "purpose": "confirm_payment_received",
      "required": true,
      "status": "pending"
    }
  ],
  "post_confirmation_intent": {
    "reservation_type": "PD",
    "status": "pending_payment_confirmation"
  }
}
```

## 业务复核

当前证据已经能确定 `Voucher Received` 或 `Payment Evidence` 时，以下问题保留该业务事件，并使用非空、完整的 `manual_review`：

- 当前 image/PDF/file 部分不可读，但事件类型已经由可靠当前证据确定。
- 多个 group code 无法安全拆分。
- target key 缺失或无法唯一绑定。
- `Voucher Received` 的 CODE / 團號模糊或冲突。

保留当前文件引用和所有可读字段；缺失字段使用 RFC 6901 JSON Pointer 写入 `manual_review.missing_fields[]`。

只有当前证据已确认 voucher/payment evidence 业务方向、但无法在 `Voucher Received` 与 `Payment Evidence` 之间确定事件类型时，才输出 `event_type=Need Manual Review` 的 Fallback 复核；连受支持业务方向都无法判断时使用 S99。只有历史提及或被动文件名、没有当前 image/PDF/file 对象且没有明确 current 收件/处理信号时，不生成上述业务事件；按入口支持范围使用 S10 或同邮件其他结果。若 current 信号已确定业务卡型而附件缺失/不可读，必须保留该业务 event 并使用非空 `manual_review`。