# 精选票需求业务确认稿（待评审）

> 文档状态：待评审，评审通过并补录确认人后改为“已确认”
>
> 适用对象：业务、产品、运营、客服、后台、Android/iOS 原生客户端、H5、测试与研发负责人
>
> 评审稿日期：2026-08-29
>
> 说明：本文用于本轮页面结构评审，不表示当前系统已经实现；评审完成、确认人补录后，文档状态再改为“已确认”。

## 一、产品定义

精选票是一种**无需兑换、可直接核销使用的票券权益**。它可以用于线下业务现场，也可以复用于其他直接核销场景，系统不把它限定为某一种具体用途。

精选票与服务券的边界固定：

| 对象 | 业务含义 | 使用方式 | 核销对象 |
| --- | --- | --- | --- |
| 精选票 | 可直接使用的票券权益 | 用户提交核销申请，或展示动态二维码由核销人员扫码 | 用户持有的精选票 |
| 服务券 | 用于兑换具体服务的兑换券 | 先兑换服务，再按服务订单流程处理 | 兑换后生成的服务订单 |

本次不建立活动、场馆、选座、预约或场次关联，不进行实名核验，也不生成服务订单。

### 申请单与核销记录的关系

精选票的申请单和核销记录是两个不同的业务对象，但在后台和用户端可以放在同一个核销管理入口下查看：

```text
用户提交申请 → 核销申请（待审核）
                         ├─ 驳回 → 仅保留申请历史，不产生核销记录
                         └─ 通过 → 保留申请历史，并新增一条核销记录

用户二维码核销 ─────────────────────→ 新增一条核销记录（无申请编号）
```

- **核销申请**表示用户提出的处理请求，保存申请编号、用户、票种、申请数量、实际扣减批次、申请状态、申请时间、审核人、审核时间和驳回原因。
- **核销记录**只表示已经实际扣减成功的核销事实，保存独立的核销记录编号、申请关联、用户、票种、实际扣减批次、核销方式、数量、处理人和核销时间。
- 申请通过后，核销记录通过内部申请 ID 关联申请单；申请编号仅作为业务人员可读的关联编号，不作为内部关联键。
- 一份申请只对应一个精选票票种，可申请 N 张；按最早到期批次优先扣减，申请和核销记录均保留实际扣减批次；通过后生成一条数量为 N 的汇总核销记录，不按单张电子卡拆行。
- 申请记录和核销记录分别参与各自页面展示；统计只按核销记录的实际数量计算，不能因申请历史再次累计。

## 二、核心业务确认

| 编号 | 确认结论 |
| --- | --- |
| A-01 | **核销成功只表示对应数量的精选票已经使用；具体用途由线下或实际业务场景处理，线上不再区分。** |
| A-02 | **新增独立的“精选票”卡片类型，使用规则、核销数据和统计口径与服务券分开；配置入口仍复用现有卡片菜单。** |
| A-03 | **精选票固定为直接核销，服务券固定为兑换服务，二者不能互相切换。** |
| A-04 | **精选票核销不生成服务订单，直接扣减精选票并生成独立核销记录。** |
| A-05 | **用户提交申请和现场展示二维码是精选票固定支持的两种并列核销方式，不需要在后台配置开关；申请审核通过或现场扫码成功后，票立即完成核销，另一条路径不能重复使用。申请单和核销记录分开保存，申请通过后两边都保留历史，但实际数量只扣减一次。** |
| A-06 | **每一张精选票只能成功核销一次；同一票种持有多张时，可以按数量分次核销。** |

## 三、有效期规则

1. 精选票与推广卡使用相同的有效期方式：后台按“有效天数”配置，不增加固定开始时间、固定结束时间或其他有效期类型；有效天数留空或填写 `0` 均表示卡片本身不设置有效期。
2. 用户获得精选票时，按照现有卡片发放渠道生成每张电子票的具体到期时间；卡片本身未设置有效期时，发放渠道已有的到期时间继承规则仍沿用，最终没有到期时间的批次显示为“不设置有效期”。
3. Android、iOS 和 H5 沿用现有卡片的有效期字段和过期过滤方式，不在用户侧新增“已过期”提示。
4. 用户提交核销申请或展示二维码时，所选票必须仍在有效期内。
5. 核销申请不设置审核时限。申请待审核期间票到期，申请仍保持“待审核”且不会自动关闭；客户端不展示到期标记或“票已过期”等过期提示。
6. 后台处理已经过期的待审核申请时，先明确提示“票已过期”，审核人员二次确认后才能通过或驳回。
7. 过期申请通过后，锁定的票照常完成核销并记录实际处理时间，但不会改变票的原到期时间。
8. 过期申请被后台驳回后解除锁定；已过期批次不恢复为可使用数量，仍有效批次按原批次恢复，申请记录整体保留为“已驳回”。
9. 本次不增加到期提醒、固定生效时间、转赠后重新计算、自动延期、批量调整或人工修改有效期功能。
10. 扣减排序时，有明确到期时间的批次按到期时间从早到晚处理；不设置有效期的批次排在所有有明确到期时间的批次之后。

## 四、用户提交核销申请

### 4.1 申请内容

| 编号 | 确认结论 |
| --- | --- |
| C-01 | **核销申请是不使用现场扫码时的另一种最终核销方式。用户从当前精选票进入申请页，只选择申请数量，不填写申请说明，也不上传材料。** |
| C-02 | **一份申请只包含一种精选票，可以申请多张；按“用户 + 票种”限制同时只能有一份待审核申请，不同用户可以同时提交同一票种，申请数量不得超过该用户当前可用数量。** |
| C-03 | **提交申请前必须进行二次确认；提交后按最早到期批次优先扣减并锁定申请数量，用户不能自行取消、撤回或修改。锁定数量不能转赠、扫码或重复申请；后台驳回时解除锁定，后台通过时直接完成核销。申请不设置审核时限，票到期也不自动关闭申请。** |
| C-04 | **一份申请只能整份通过或整份驳回，不允许部分通过或修改申请数量。驳回必须填写用户可见的原因。** |

### 4.2 锁定后的客户端展示

卡包列表继续只代表当前可用的卡券，不承担审核状态展示。

- 部分数量被申请锁定时，卡片仍显示，右上角 `xN` 只计算剩余可用数量。例如持有 3 张、申请 1 张后，卡片只显示 `x2`。
- 全部数量被申请锁定时，该精选票卡片从列表隐藏；分类下显示“暂无可用精选票”，不提供进入核销码页的入口。
- “精选票”分类下方、卡片列表上方固定显示“核销记录”入口，右侧统一显示“查看全部 ›”，入口不附带申请数量标记。
- 用户从该入口进入核销记录页，默认打开“核销记录”Tab；页面另设“申请记录”Tab。待审核期间票到期时，申请记录仍显示“待审核”，用户侧不增加“票已过期”等提示；到期状态由后台审核列表和二次确认承载。
- 后台驳回后，仍在有效期内的数量恢复可用，对应卡片重新出现在列表；已经过期的数量只解除锁定且不恢复可用，申请记录保留为“已驳回”。
- 后台通过后，对应数量转为已核销；申请记录保留“已通过”历史，核销记录新增一条“申请核销／已核销”事实；没有剩余可用数量时，卡片保持隐藏。

### 4.3 申请状态变化

```text
可使用
  └─ 用户提交申请 → 待审核（锁定对应数量）
                         ├─ 后台驳回 → 解除锁定 → 可使用或已失效
                         └─ 后台通过 → 已核销
```

待审核期间到期时，申请状态仍为“待审核”，不会自动关闭，也不能由用户取消；后台处理时判断对应批次是否已过期并二次确认，客户端不增加到期标记。

### 4.4 申请记录与核销记录展示口径

| 页面 | 展示内容 | 是否计入实际核销量 |
| --- | --- | --- |
| C 端“申请记录”Tab | 全部申请历史：待审核、已通过、已驳回；显示申请编号、票种、数量、实际扣减批次、申请时间、状态和驳回原因 | 否 |
| C 端“核销记录”Tab | 已成功扣减的二维码核销和申请核销；显示票种、数量、实际扣减批次、核销方式和核销时间；申请核销在有值时显示申请编号 | 是 |
| 后台“核销申请”Tab | 全部申请及审核字段，包含实际扣减批次；已处理申请只读 | 否 |
| 后台“核销记录”Tab | 成功核销事实；显示核销记录编号、申请编号、用户、票种、数量、实际扣减批次、核销方式、处理人、处理时间和状态 | 是 |

- 申请通过后会在两个 Tab 各出现一条对应信息，这是“申请过程”和“实际核销事实”的两种视角，不是两次扣减。
- 二维码核销没有申请编号：后台固定列显示“—”，C 端不显示空的申请编号字段。
- 每次实际核销动作只生成一条汇总记录；一次动作核销 N 张时，记录数量为 N。
- 核销记录编号独立于申请编号；申请核销通过时两者均有值，二维码核销只生成核销记录编号。

## 五、现场动态二维码核销

| 编号 | 确认结论 |
| --- | --- |
| C-05 | **每一种精选票生成一个约 60 秒有效的动态二维码，页面自动刷新；旧码失效后不能继续使用。** |
| C-06 | **核销人员扫码后先查看票种、有效期和可用数量，再选择本次核销数量；点击“确认核销”后先弹出二次确认，只有再次确认才扣减票券。** |
| C-07 | **核销人员按精选票票种分别配置；同一人员可以关联多个票种，但只能核销已授权的票种。** |

现场核销遵守以下规则：

1. 二维码只代表当前用户的指定精选票票种，不代表账号内的全部票种。
2. 动态码对应的可核销数量不包含处于待审核锁定中的数量；二维码核销按最早到期批次优先扣减，并保存实际扣减批次。
3. 扫码后再次校验票是否有效、是否可用以及核销人员是否拥有该票种权限。
4. 核销人员选择的数量不能超过扫码时重新取得的可用数量；二次确认弹窗需再次展示票种、持票用户和本次数量。
5. 核销成功后立即按最早到期批次优先扣减对应数量，并生成独立核销记录编号，记录用户、票种、数量、实际扣减批次、时间、核销方式和核销人员；二次确认前不产生核销结果。
6. 已无可用数量时，再次扫码仅提示“已核销”和当前没有可用数量，不展示额外的最近处理信息。
7. 二维码过期、无权限、数量不足或重复扫码只提示当前操作结果，不写入用户端或后台的成功核销记录。
8. 首期只支持在线正常核销，不提供离线记录、网络异常补录、误核销撤销或恢复能力。

## 六、获得、持有和流转

精选票作为一种卡片，获得、持有和流转全部使用当前卡片已有能力：

1. 复用现有卡片的创建、发放审批、电子卡到账、持有数量、启用、停用和流水记录。
2. 奖励发放、服务包、实体卡或兑换码、积分兑换等现有渠道，按各渠道当前支持卡片的方式接入精选票。
3. 转赠沿用现有卡片开关、限制和流水；处于核销申请锁定中的数量不能转赠。
4. 发放数量、单人持有数量、冻结、失效、补发和票种停用等管理能力沿用现有卡片功能。
5. 卡片价值、用户价值和运营统计继续使用现有卡片口径，不增加精选票专属计算规则。

本次不新增精选票专属购买、发放、库存、转赠或人工补票流程。

## 七、业务后台

### 7.1 卡片表单中的精选票配置

- 配置路径沿用现有后台：**卡片菜单 → 卡片列表 → 点击“新增” → 在卡片表单选择“精选票”类型**；编辑精选票时复用同一张表单，卡片类型只读。
- 卡片列表保留全部卡片类型，并沿用现有的卡片名称、卡片类型、用户端显示等筛选和编辑、启停、查看持卡用户操作；通过卡片类型筛选查看精选票。
- 精选票卡片表单沿用现有字段：卡片类型、卡片名称、价值积分、专属图片、有效天数、转赠设置、启用状态和备注；转赠设置沿用现有卡片能力，弹窗和卡片列表均使用现有风格入口。
- 选择精选票类型后隐藏比赛项目、兑换库存等不适用字段，显示“有效天数”；有效期方式沿用推广卡的有效天数配置，留空或填写 `0` 表示不设置有效期。
- 每个精选票固定同时支持“用户提交核销申请”和“现场动态二维码”，后台不提供核销方式开关，卡片表单也不额外展示能力说明文案。
- 在精选票卡片表单中配置现场核销人员，可多选，也允许暂不配置并在创建后补充；同一人员可以关联多个精选票票种。后台审核权限仍按后台用户权限逻辑执行。
- 精选票配置不出现活动、场馆、场次、预约、选座、实名或服务兑换字段；发放记录和持卡用户查看沿用卡片列表现有操作，不在表单内增加伪 Tab。
- 本轮只评审页面结构；交互原型中的新增、编辑和保存仅用于演示表单入口，保存结果只更新示例卡片，不代表真实接口或数据已经落地。

### 7.2 通用核销管理

“核销管理”作为卡片菜单下的通用入口，当前首期只展示精选票数据，后续可复用到其他无需兑换、可直接核销的卡片类型；服务订单继续使用线下服务模块下原有的核销管理。

| 编号 | 确认结论 |
| --- | --- |
| E-01 | **卡片菜单下增加通用“核销管理”菜单，内部提供“核销申请”“核销记录”两个 Tab；当前展示精选票数据，服务订单仍沿用线下服务核销管理。** |
| E-02 | **“核销申请”Tab 的列表和审核详情展示申请编号、用户信息（账号、昵称、手机号）、卡片类型、数量、实际扣减批次、申请状态、申请时间、审核人、审核时间、驳回原因和操作；驳回原因仅在已驳回申请中展示，精选票不生成服务订单，因此不展示服务订单编号、服务内容。** |
| E-03 | **支持逐笔审核，并允许对筛选出的同类申请批量通过或驳回；单笔和批量驳回必须填写处理原因，通过不填写处理原因；已处理申请只读。** |
| E-04 | **现有卡片列表的统计字段直接包含精选票；“核销管理”的“核销记录”Tab 只展示已经成功扣减的申请核销和二维码核销事实，包含独立核销记录编号、申请编号、核销方式、数量、实际扣减批次、用户、卡片类型、处理人、处理时间和状态，并提供查询、导出入口；不新增独立统计页面。申请记录不重复计入核销量。** |

审核权限使用后台现有用户权限逻辑。现场核销人员配置属于用户侧核销权限，不与后台审核权限互相继承。

核销记录的编号和人员口径：

- 每次实际核销动作生成一个独立的核销记录编号；一次申请通过 N 张或一次二维码核销 N 张，均只生成一条数量为 N 的汇总记录，并保留本次实际扣减批次。
- 申请核销记录同时保存申请编号；二维码核销没有申请编号，后台固定显示“—”。两类记录均保存实际扣减批次；有效天数为 0 或未填写时批次标记为“不设置有效期”。
- 核销记录统一使用“处理人”列：申请核销显示审核人，二维码核销显示现场核销人员。
- 待审核和已驳回申请不进入核销记录 Tab；申请通过后才进入核销记录，并按实际核销数量统计。

后台审核规则：

- 待审核申请只能整份通过或整份驳回。
- 单笔驳回必须填写原因；原因展示给申请用户。
- 申请包含任一已过期批次时，通过和驳回都必须先进行二次确认；一份申请仍整份通过或整份驳回，不按批次拆分审核结果。
- 批量审核中只要包含过期申请，也必须明确提示并二次确认。
- 同一申请被其他审核人员先处理后，后续操作不能重复执行。

## 八、Android、iOS 与 H5

| 编号 | 确认结论 |
| --- | --- |
| F-01 | **Android 原生客户端、iOS 原生客户端和 H5 同步支持；三个客户端均发布可用版本后再开始发放精选票。** |
| F-02 | **在“我的卡片/权益”中新增独立“精选票”分类。分类标签由 Android、iOS 和 H5 客户端固定配置，不由服务端动态下发；用户进入该分类时，客户端固定传入 `species=featured`，服务端按 `species` 筛选并返回精选票列表。** |
| F-03 | **卡包列表只展示当前可用的精选票，卡片保留票名、图片、有效期，右上角 `xN` 只表示可用数量；全部数量锁定后卡片隐藏。“精选票”分类下方、列表上方固定显示核销记录入口，右侧统一显示“查看全部 ›”。点击可用精选票直接进入核销码页，不增加详情页；二维码页任何状态都不放核销记录入口，申请入口仅以“不方便现场出示二维码？”场景引导呈现。** |
| F-04 | **用户端核销记录页分为“核销记录”和“申请记录”两个 Tab，默认打开“核销记录”。核销记录只展示成功扣减事实；申请记录保留待审核、已通过、已驳回的申请历史，申请编号仅在有值时展示，不增加额外到期状态、过期提示或锁定量汇总。申请结果页的“查看申请记录”直接打开“申请记录”Tab；用户端不记录失败扫码。** |
| F-05 | **Android/iOS 原生客户端在“我的”页面增加独立“精选票核销”入口；H5 只提供用户持票、提交申请和展示核销码。** |
| F-06 | **精选票流程不单独设计旧版本升级提示页。客户端分类标签固定写明 `species=featured`，未内置该分类标签的旧版客户端不会展示精选票；三个客户端可用前不发放精选票。** |
| F-07 | **本次只补充精选票功能，不补齐服务券“用户提交核销申请”的客户端入口。** |
| F-08 | **申请提交后立即更新申请记录；申请通过后同时在申请记录保留“已通过”历史，并在核销记录新增一条“申请核销／已核销”事实；驳回原因在申请记录中查看，二维码成功核销只进入核销记录。** |

三个客户端使用同一套业务规则：

- 卡片分类沿用现有“客户端固定分类标签（`species=featured`）→ 传入 `species` → 服务端按 `species` 筛选 → 返回对应卡片列表”的加载方式。
- 每个精选票固定支持二维码核销和申请核销，两种方式共用同一份可用数量。核销码页默认用于现场扫码，展示二维码后用户无需继续操作。
- 不方便现场出示二维码时，用户通过低强调的场景引导进入申请流程；有待审核申请时，二维码页不增加记录入口或锁定量，申请状态只在“申请记录”Tab查看。
- 卡包只展示可用数量，卡片 `xN` 不叠加申请中的数量；部分数量锁定时显示剩余可用数量，没有可用数量或已不在有效期时卡片隐藏。
- 精选票分类下固定显示核销记录入口；用户进入后默认查看“核销记录”，申请数量和状态切换到“申请记录”查看。没有可用数量时不进入核销码页，也不为这种情况单独设计核销页状态。
- 已进入待审核申请的数量不能用于扫码、转赠或再次申请；客户端其他页面不汇总申请锁定量，申请历史和成功核销记录从核销记录页的两个 Tab 查看。
- 待审核期间票到期后，C 端仍只显示“待审核”，不显示到期标记或“票已过期”等过期提示；后台按对应批次判断并处理。
- 核销记录页从卡包固定入口进入时返回卡包；申请结果页“查看申请记录”进入时打开“申请记录”Tab，返回申请结果页。

## 九、历史数据、统计和上线

| 编号 | 确认结论 |
| --- | --- |
| G-01 | **历史服务券保持不变，新发业务才使用精选票。** |
| G-02 | **历史服务券、服务订单和核销记录保持原业务类型和原展示，不回写为精选票。** |
| G-03 | **现有卡片列表统计按新类型识别精选票；实际核销量和使用人数按核销记录统计，申请记录不重复计入；精选票与服务券分开统计。** |
| G-04 | **精选票和核销记录沿用现有业务审计及数据保留要求，不因票过期或核销完成而立即删除。** |
| G-05 | **首期选择一个或少量票种，并限制首批使用人员；确认发放、申请、扫码、过期和报表后再逐步放开。** |
| G-06 | **首期验收覆盖客户端精选票分类与 `species=featured` 筛选、所有获得方式、两种核销方式、有效与过期、待审核期间过期及后台二次确认、申请与扫码冲突、多张核销、驳回和转赠限制。** |
| G-07 | **指定一名业务负责人统一汇总运营、客服、财务和数据口径；具体负责人姓名待业务补录。** |

## 十、首期评审口径

1. 新增独立“精选票”卡片类型，代表无需兑换、可直接核销使用的票券权益。
2. 精选票与服务券严格分开，不生成服务订单。
3. 每张票只能成功核销一次；同一票种持有多张时按数量核销。
4. 有效期完全沿用推广卡和现有卡片逻辑；有效天数留空或填 `0` 表示不设置有效期，正数按最早到期批次优先扣减。
5. 用户申请和现场动态二维码是每个精选票固定支持的两种并列核销方式，不配置方式开关。
6. 申请仅选择数量并经过二次确认；提交后锁定对应数量且用户不能自行取消。卡包只显示剩余可用数量，全部数量锁定后卡片隐藏；审核状态通过列表上方固定的核销记录入口进入“申请记录”查看，成功扣减事实进入“核销记录”查看。
7. 申请不设置审核时限，待审核期间到期不自动关闭；后台处理时提示过期并二次确认。
8. 后台用户按后台权限审核；用户侧核销人员按票种获得现场扫码权限。
9. Android、iOS 和 H5 同步内置精选票分类，并固定传入 `species=featured` 获取列表；现场扫码入口首期只在 Android/iOS 开放，不单独设计旧版本升级提示页。
10. 获得、持有和流转沿用现有卡片能力，历史服务券不迁移，精选票单独统计；统计只按成功核销记录累计，不按申请历史重复累计。

## 十一、原型页面映射

| 业务角色 | 原型页面 | 覆盖规则 |
| --- | --- | --- |
| 用户 | 精选票列表、动态二维码、核销申请、申请结果、核销记录（核销记录／申请记录两个 Tab） | 可用卡片列表、独立核销记录入口、默认打开成功核销事实、申请历史、列表直达核销码、现场扫码无需后续操作、申请场景引导、二次确认、申请锁定、到期申请仍可查询 |
| 核销人员 | 精选票核销入口、扫码、数量确认、二次确认、核销结果 | 按票种授权、有效期和数量校验、二次确认、重复核销提示 |
| 后台用户 | 卡片列表、新增/编辑卡片、核销管理（核销申请/核销记录两个 Tab） | 仅评审页面结构；卡片类型联动、有效天数（空或 0 表示不设置）、人员配置、过期二次确认、双用户批量审核、批次展示、记录查询与导出 |

配套交互原型：`精选票交互原型.html`（与本文同目录）。

## 十二、验收清单

1. Android、iOS 和 H5 均内置“精选票”分类；进入该分类时固定传入 `species=featured`，服务端只返回该分类的精选票列表。新建精选票并按有效天数发放后，三个客户端均能查看。
2. 点击精选票直接进入核销码页；现场展示二维码无需用户继续操作。页面以“不方便现场出示二维码？”和低强调“去申请”引导申请流程；申请页仅选择数量，提交必须二次确认，提交后不能由用户取消、撤回或修改。
3. 精选票分类下方、卡片列表上方始终显示“核销记录”入口，右侧统一显示“查看全部 ›”。从该入口进入后默认打开 C 端“核销记录”Tab；申请结果页点击“查看申请记录”直接打开“申请记录”Tab；二维码页任何状态均不放记录入口，核销码页、申请页和核销人员确认页只展示完成当前操作所需的可用数量。
4. 部分数量锁定时，卡片只显示剩余可用数量；全部数量锁定后卡片隐藏，并显示“暂无可用精选票”和记录查看提示，不再进入核销码页。
5. 提交申请后按最早到期批次优先扣减并锁定申请数量；后台在有效期内驳回后按原批次恢复，审核通过或过期后驳回且无剩余可用数量时卡片保持隐藏，申请记录保留“已驳回”并展示原因，不新增第三个 Tab。
6. 后台审核通过后对应数量直接完成核销，不生成服务订单。
7. 待审核期间过期的申请继续保留，卡包不展示已无可用数量或已不在有效期的卡片，C 端“申请记录”仍显示“待审核”且不显示过期提示，后台通过或驳回前执行二次确认。
8. 动态二维码约 60 秒刷新，过期码不能使用，扫码时重新校验票和核销人员权限；点击确认核销后必须二次确认。
9. 核销人员只能处理已授权票种，并能选择不超过可用数量的本次核销数量；确认前可返回重新检查。
10. 核销成功后，用户、票种、数量、实际扣减批次、时间、方式、处理人和独立核销记录编号记录完整；申请核销同时保留申请编号。
11. 用户端从卡包固定入口进入记录页时默认打开“核销记录”Tab，仅展示申请通过后的实际核销和二维码成功核销；申请结果页点击“查看申请记录”时直接打开“申请记录”Tab。申请记录保留全部申请历史，待审核过期仍显示“待审核”但不增加到期标记或过期提示，且不提供取消入口；二维码页任何状态均不提供记录入口。
12. 历史服务券、服务订单和原有核销记录保持不变；精选票统计和服务券统计分开，申请历史不重复计入核销量。
13. 后台从“卡片”菜单进入卡片列表，点击“新增”打开现有风格卡片表单；选择“精选票”后隐藏比赛项目、兑换库存，显示有效天数和现场核销人员选择区，有效天数留空或填 `0` 表示不设置有效期，核销人员允许暂不配置；编辑时卡片类型只读。
14. 后台“卡片”菜单下只有一个通用“核销管理”入口，内部仅有“核销申请”“核销记录”两个 Tab，默认打开核销申请；服务订单继续使用线下服务下原有核销管理，不与精选票数据混合。
15. 核销申请 Tab 支持按申请编号、状态、卡片类型、用户和申请/审核时间筛选，逐笔审核、批量通过、批量驳回、驳回原因和过期二次确认；列表展示申请编号、用户信息、卡片类型、数量、实际扣减批次、申请状态、申请时间、审核人、审核时间、驳回原因和操作，已处理申请只读。核销记录 Tab 只展示成功核销事实，包含核销记录编号、申请编号、用户、卡片类型、数量、实际扣减批次、核销方式、处理人、处理时间和状态，并提供查询、导出入口；二维码记录的申请编号显示“—”。
16. 卡片列表直接沿用现有统计字段展示精选票的发放、兑换、颁奖、福利赠送、实物卡和用户已使用数据；不新增独立统计页面，核销明细从“核销管理”的“核销记录”查询和导出。
17. 本轮原型只评审页面结构：卡片新增/编辑弹窗仅演示表单入口，保存结果只更新示例卡片，不据此确认真实接口、数据表、权限或保存结果。
18. 在“部分锁定”或“待审核期间过期”演示场景中，后台同时展示两个用户的待审核申请，可全选后批量通过或批量驳回；同一用户同一票种不能重复产生第二份待审核申请。

## 十三、业务确认记录

| 问题编号 | 拟采用选项 | 确认人 | 确认日期 |
| --- | --- | --- | --- |
| A-01 至 A-06 | **A** | 待业务签字 | 待业务签字 |
| C-01 至 C-07 | **A** | 待业务签字 | 待业务签字 |
| E-01 至 E-04 | **A** | 待业务签字 | 待业务签字 |
| F-01 至 F-08 | **A** | 待业务签字 | 待业务签字 |
| G-01 至 G-07 | **A** | 待业务签字 | 待业务签字 |

## 十四、现状核对依据

本文在确定目标规则前，已核对当前系统的以下实现。它们用于说明可复用能力和现状差距，不表示精选票已经上线。

- （以下路径均以 `poker` 项目集合根目录为基准。）卡片列表入口及 `species` 筛选：`poker-web/modules/poker/src/http/routes/api_v1_web.php`、`poker-web/modules/poker/src/http/request/api_v1/web/CardController.php`、`poker-web/modules/poker/src/action/ActCard.php`、`poker-web/modules/poker/src/models/PokerCard.php`
- 卡片后台菜单、列表和表单：`poker-web/modules/poker/configurations/menus.yaml`、`poker-web/modules/poker/resources/views/backend/card/index.blade.php`、`poker-web/modules/poker/resources/views/backend/card/establish.blade.php`
- 有效天数允许 `0` 及不设置到期时间的现有处理：`poker-web/modules/poker/src/action/ActBakCard.php`、`poker-web/modules/user/src/action/invite/Invitee.php`、`poker-web/modules/user/src/action/ActParticipationAward.php`
- 可用卡片按到期时间排序及空到期时间排后的现有处理：`poker-web/modules/poker/src/action/ActCard.php`、`poker-web/modules/poker/src/action/ActPackageCard.php`
- 服务券兑换和服务订单核销申请：`poker-web/modules/offline/src/action/service/ActServiceOrder.php`、`poker-web/modules/offline/src/action/service/ActServiceOrderVerificationApplication.php`
- 服务订单后台核销申请列表字段及审核方式：`poker-web/modules/offline/resources/views/backend/service/order/applications.blade.php`
- 服务订单核销管理的双 Tab 模式：`poker-web/modules/offline/configurations/menus.yaml`、`poker-web/modules/offline/resources/views/backend/service/order/_verification_tabs.blade.php`
- 服务订单申请与实际核销分开保存及审核流转：`poker-web/modules/offline/src/models/OfflineServiceOrderVerificationApplication.php`、`poker-web/modules/offline/src/action/service/ActServiceOrderVerificationApplication.php`、`poker-web/modules/offline/resources/views/backend/service/order/applications.blade.php`
- 卡片二维码直接核销流水：`poker-web/modules/poker/src/action/ActCard.php`、`poker-web/modules/poker/src/models/PokerCardLog.php`、`poker-web/modules/user/src/models/UserConsumeLog.php`
- Android 固定分类标签、`species` 传参与旧直接核卡页面：`android-ipg/app/src/main/java/com/silkroad/sport/ui/my/card/CardActivity.java`、`android-ipg/app/src/main/java/com/silkroad/sport/ui/my/card/FragmentCard.java`
- iOS 固定分类标签、`species` 传参与旧直接核卡页面：`ios-ipg/IPG/Offline/卡包/ReceiveViewController.m`、`ios-ipg/IPG/Offline/卡包/CardTypeController.m`、`ios-ipg/IPG/Mine/核销/`
- H5 卡包和扫码组件：`league-h5/src/views/app/card/`、`league-h5/src/components/app/XCard.vue`

当前卡包接口只返回可用卡片数量，三个主要客户端也没有承载申请锁定量的字段，这与“卡包列表只代表可用卡券”的确认口径一致。现有服务订单已经将申请过程与实际核销结果分开处理；精选票二维码链路目前写入直接使用流水，并没有申请关系。当前 `PokerCard::getFromSpecies()` 尚未包含 `featured` 分支，真实开发时需要按本确认稿补充 `species=featured` 映射。本次确认稿和原型采用“申请单 + 核销记录”两个业务实体：后续实现需要提供可关联的核销记录视图，但不改变现有卡包列表的可用卡券筛选逻辑。