实现M002 V3 P0.1 Parent Group路由修订

docs/import/20260712/Agent 0711 1743/skills/booking-desk-event/references/13-voucher-payment.md

@@ -0,0 +1,111 @@
+# 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`。