Continental-AG/conti-docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add initial reference document in Word format with structured headings and content

Browse Source
This commit is contained in:
Guangfei.Zhao
2026-08-24 18:46:37 +08:00
parent 70c5cef4e1
commit d43d33c3cd
197 changed files with 9230 additions and 3754 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prd/modules/01-LGN-账号登录.md
+220
View File
@@ -0,0 +1,220 @@
# 4.1 账号登录
> **本文件是【账号登录 LGN】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.1 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | LGN |
| V1.0 章节 | 4.1 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 设计稿 |
| 现状承载系统 | O2O 接单宝后台（用户主数据） |
| 需求条数 | 10（待确认 7，完成度 30%） |
| 配图 | 1 张（设计稿 1） |
模块概要
---
一套账号切换多家门店，账号统一管理、员工权限配置。
![设计稿-登录页](../app-design-images/登录.png)
**页面内容** —— App 登录页目标形态：深色轮胎背景 + 橙色徽标，中部为手机号 / 验证码登录区与「密码登录」「我要注册」两个次级入口，下方是第三方登录（微信、支付宝）与协议勾选行。
**关键交互** —— ①输入手机号 → 点「获取验证码」，60 秒内不可重复获取（[REQ-LGN-001](#412-业务规则)）；②点「密码登录」→ 切换为用户名 + 密码模式；③点「我要注册」→ 进入注册流程（表单与审核流程未定 `TODO(REQ-LGN-004)`）；④点微信 / 支付宝 → 第三方授权，首次需绑定已有手机号账号（`TODO(REQ-LGN-003)` 是否纳入本期）；⑤点《用户协议》/《隐私政策》→ 查看全文；⑥勾选协议后「登录」方可提交。
**可用角色** —— 店长 ✅、技工 ✅，登录环节两个角色完全一致；差异从登录成功后的角色化导航开始（见[导航收敛与角色化配置](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）。第三方登录与注册两项对两个角色均为 ❓ `TODO(REQ-LGN-003)` / `TODO(REQ-LGN-004)`。
**需求关联** —— [REQ-LGN-001](#412-业务规则) 验证码登录、[REQ-LGN-002](#412-业务规则) 密码登录、[REQ-LGN-003](#412-业务规则) 第三方登录、[REQ-LGN-004](#412-业务规则) 注册与审核、[REQ-LGN-005](#412-业务规则) 协议展示与留痕
> **本图与验收标准的两处对不上，需设计补稿**（不新增需求，属设计稿状态缺失）：
>
> 1. 稿中协议勾选框为**未勾选**态，而「登录」按钮画的是完整橙色实心（非置灰）。[验收标准第 1 条](#416-验收标准)要求未勾选时按钮为禁用态 —— **设计稿未画禁用态**。
> 2. 稿中**未见「忘记密码」入口**，而 [REQ-LGN-006](#412-业务规则) 规定忘记密码经手机号验证码重置。该入口可能在「密码登录」模式下才出现，但**密码登录态的稿未提供**，本图无法确认。
## 4.1.1 需求描述
**业务目标** —— 用一套账号替代 6 套小程序各自的登录，消除重复登录；同时建立可审核、可回收的账号管控机制，解决[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控)
**目标角色** —— 店长、技工
**入口** —— APP 冷启动且无有效会话；会话失效后的任意页面被动跳转
**前置条件** —— 账号已在 O2O 接单宝后台存在并通过审核；设备可访问网络
**页面内容**：
- 品牌背景 + Continental Logo
- 手机号输入框
- 验证码输入框 + 「获取验证码」
- 「登录」主按钮
- 「密码登录」次按钮（切换到用户名 + 密码模式）
- 「我要注册」文字入口
- 第三方登录区（微信、支付宝）
- 底部协议勾选「已阅读并同意《用户协议》与《隐私政策》」
**主流程**：
1. 输入手机号
2. 获取验证码
3. 输入验证码
4. 勾选协议
5. 点击登录
6. 后端校验通过下发 access / refresh token
7. 拉取该账号的门店列表与角色
8. 单门店直接进入首页；多门店弹出门店选择
9. 进入 APP 首页
**异常流程**：
- 手机号未注册 → 提示并引导「我要注册」
- 验证码错误 → 提示剩余可试次数
- 验证码超时 → 提示重新获取
- 未勾选协议 → 登录按钮不可用
- 账号被停用 → 提示联系门店管理员
- 账号无任何门店归属 → 阻断登录并提示
- 网络异常 → 保留已输入内容并允许重试
**业务规则** —— 见 [4.1.2](#412-业务规则)
**权限规则** —— 登录本身不区分角色；登录成功后由后端下发角色（店长 / 技工）与该角色的可见 tab 集合、功能权限，见[导航收敛与角色化配置](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)与[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)
**访问链路** —— App → App Backend → O2O 后台（用户主数据校验）；App Backend → 短信网关（验证码下发）；App Backend → 马上下单（门店列表）
**逻辑数据来源** —— 用户主数据：**O2O 接单宝后台**（手机号、用户名、密码、角色）；门店列表：马上下单；协议内容：APP 后台管理 Web
**回写目标** —— 登录日志、设备信息写入 App Backend；协议同意记录（版本号 + 时间戳）写入 App Backend
**状态变化** —— 无会话 → 已登录（持有 access/refresh token）→ 已选定门店上下文
**验收标准** —— 见 [4.1.6](#416-验收标准)
## 4.1.2 业务规则
**REQ-LGN-001 手机号验证码登录** —— 手机号为 11 位中国大陆号码；验证码 6 位数字，有效期 5 分钟；同一手机号 60 秒内只能获取一次；单日获取上限 `TODO(REQ-LGN-001)`
**REQ-LGN-002 用户名密码登录** —— 用户名与密码沿用 O2O 注册时设置的凭据；密码在传输与存储全程不可逆
**REQ-LGN-003 第三方登录** —— 支持微信、支付宝授权登录。首次授权需绑定已有手机号账号后方可进入；未绑定账号不允许直接创建新账号。
> ⚠️ 该需求仅见于设计稿 —— `TODO(REQ-LGN-003)` 需确认是否纳入本期
**REQ-LGN-004 注册与审核** —— 设计稿含「我要注册」入口。注册后账号处于「待审核」状态，需门店店长或后台管理员审核通过方可登录，以解决[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控) 的「随意注册」问题。
> ⚠️ 注册表单字段、审核人、审核时效均未定义 —— `TODO(REQ-LGN-004)`
**REQ-LGN-005 协议展示与留痕** —— 用户协议、隐私政策内容由后台管理 Web 维护，经法务审核；用户点击可查看全文；同意时记录协议版本号与同意时间；协议版本更新后需重新征得同意
**REQ-LGN-006 密码策略** —— 密码长度、复杂度、有效期、历史密码不可复用条数 —— `TODO(REQ-LGN-006)`。忘记密码通过手机号验证码重置
**REQ-LGN-007 登录失败锁定** —— 连续登录失败达到阈值后锁定账号一段时间。阈值与锁定时长 —— `TODO(REQ-LGN-007)`
**REQ-LGN-008 登出** —— 用户主动登出时清理本地会话、门店上下文、缓存的业务数据与 WebView Cookie，见《App 门店上下文与会话管理文档》
**REQ-LGN-009 会话与 Token** —— access token 短期有效，refresh token 轮换续期；refresh 失效后跳转登录页。轮换策略见《后端安全与认证文档》。具体有效期 —— `TODO(REQ-LGN-009)`
**REQ-LGN-010 门店上下文** —— 登录后必须确定唯一「当前门店」；切换门店时级联失效所有门店相关缓存与在途请求，见《App 门店上下文与会话管理文档》
## 4.1.3 店长
1. 店长通过自己注册的手机号登录页面；
2. 店长通过注册的用户名、密码登录页面；
3. 店长点击「用户协议」，可以查看用户协议的具体内容；
4. 店长点击「隐私协议」，可以查看隐私协议的具体内容。
## 4.1.4 技工
1. 技工通过自己注册的手机号登录页面；
2. 技工通过自己的用户名、密码登录页面；
3. 技工点击「用户协议」，可以查看用户协议的具体内容；
4. 技工点击「隐私协议」，可以查看隐私协议的具体内容。
> 登录环节店长与技工无差异；差异从登录成功后的角色化导航开始，见[导航收敛与角色化配置](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)。
## 4.1.5 业务数据列表
用户信息当前存放在 O2O 接单宝后台，用户的登录验证数据一致性以 O2O 接单宝后台的数据为用户主数据。
| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 手机号 | PhoneNum | O2O 后台 | 用户注册手机号 |
| 2 | 用户名 | Username | O2O 后台 | 用户在 O2O 注册时的用户名 |
| 3 | 密码 | Password | O2O 后台 | 用户名设置的密码 |
| 4 | 用户协议 | UserProtocol | APP 后台管理 Web | 由法务审核后的协议条例 |
| 5 | 隐私政策 | PrivateProtocol | APP 后台管理 Web | 由法务审核后的隐私政策 |
| 6 | 验证码 | ValidateCode | 第三方短信网关 | 后台调用短信网关发送至用户手机 |
| 7 | 角色 | RoleCode | O2O 后台 / APP 后台 | 店长 / 技工，决定导航与权限 —— 权威来源待确认 `TODO(REQ-LGN-011)` |
| 8 | 门店列表 | StoreList | 马上下单 | 该账号可访问的门店集合 |
| 9 | 协议同意记录 | ProtocolConsent | APP Backend | 协议版本号 + 同意时间戳 |
账号登录业务数据
## 4.1.6 验收标准
1. 未勾选协议时登录按钮为禁用态，无法提交；
2. 单门店账号登录后直接进入首页，不出现门店选择步骤；
3. 多门店账号登录后必须完成门店选择才能进入首页；
4. 主动登出后，重新启动 APP 不会恢复到已登录状态，且 WebView 中原会话不可复用；
5. refresh token 失效后，任意业务页面的接口调用都会被统一拦截并跳转登录页，不出现半登录态；
6. 切换门店后，首页及各业务页展示的数据全部属于新门店，无旧门店数据残留。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.1）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 第三方验证码 | App Backend | HTTPS | 短信调用第三方短信网关 |
| 2 | 登录成功结果集 | App Backend | HTTPS | 账号密码登录与验证码登录共用 |
| 3 | 用户协议与隐私政策完整内容 | App Backend | HTTPS | 注册/登录前须确认（[REQ-NFR-020](../Continental-Retail-APP-PRD.md#84-安全与合规)） |
登录模块数据集（摘自主文件[附录 A.1](../Continental-Retail-APP-PRD.md#a1-登录)）。字段级清单见上方 [4.1.5](#415-业务数据列表)。
> 主文件[附录 A.9 个人中心](../Continental-Retail-APP-PRD.md#a9-个人中心)第 5 条隐含一条与本模块相关、尚未成文的规则：**多设备可同时登录，单设备登出不影响其它设备**。这与[账号权限管控痛点](../Continental-Retail-APP-PRD.md#22-账号权限管控)中「账号共用」的治理诉求存在张力 —— 是否需要单设备登录限制，在 `TODO(REQ-LGN-009)` 一并确认。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 手机验证码 / 账号密码登录 | ✅ | ✅ | |
| 第三方登录（微信/支付宝） | ❓ | ❓ | 仅见于设计稿 `TODO(REQ-LGN-003)` |
| 注册 | ❓ | ❓ | 需审核 `TODO(REQ-LGN-004)` |
登录模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
### 附-3 待确认项（主文件 10.2.1）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-LGN-001 | 验证码单日获取上限 | 安全 / 后端 |
| REQ-LGN-003 | 微信/支付宝第三方登录是否纳入本期（仅见于设计稿） | 产品 |
| REQ-LGN-004 | 注册表单字段、审核人、审核时效（设计稿有「我要注册」） | 产品 / 运营 |
| REQ-LGN-006 | 密码长度、复杂度、有效期、历史密码不可复用条数 | 安全 |
| REQ-LGN-007 | 登录失败锁定阈值与锁定时长 | 安全 |
| REQ-LGN-009 | access / refresh token 有效期 | 安全 / 后端 |
| REQ-LGN-011 | 角色（RoleCode）的权威来源是 O2O 后台还是 APP 后台 | 架构 |
登录模块待确认项（摘自主文件 [10.2.1](../Continental-Retail-APP-PRD.md#1021-登录lgn)，7 条）
### 附-4 配图清单（主文件附录 C 4.1 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-登录页（验证码 / 密码 / 第三方三种登录方式 + 注册入口 + 协议勾选） | `../app-design-images/登录.png` |
登录模块配图清单，1 张（设计稿 1）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
### 附-5 本次拆分新增发现
本模块**未新增编号需求**。逐图核看发现的两处缺口均为**设计稿状态缺失**，已就地记在图下：登录按钮的禁用态未画、密码登录模式与「忘记密码」入口无设计稿。两者都已被现有的[验收标准第 1 条](#416-验收标准)与 [REQ-LGN-006](#412-业务规则) 覆盖，补稿即可，无需新增需求编号。
prd/modules/02-HOM-APP首页与导航.md
+444
View File
@@ -0,0 +1,444 @@
# 4.2 APP 首页
> **本文件是【APP 首页与导航 HOM】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.2 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | HOM |
| V1.0 章节 | 4.2 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 设计稿 3 版 |
| 现状承载系统 | ROOS / O2O / 延保（三套 tabbar 待废弃） |
| 需求条数 | 14（待确认 11，完成度 21%） |
| 本次新增待确认 | 1（REQ-HOM-016 见[附-5](#附-5-本次拆分新增发现待业务确认)） |
| 配图 | 5 张（设计稿 3 / 现状-ROOS 1 / 现状-O2O 1） |
模块概要
---
APP 首页是用户登录成功后展示的第一个页面。不同角色因权限不同，展示的信息和菜单不一样。
![设计稿-首页-店长](../app-design-images/首页-店长.png)
**页面内容** —— 店长首页目标形态，自上而下为门店名 + 问候语 + 铃铛（角标 9）的头部、橙色「今日预计营收」卡、快速核销与车牌扫码两张卡、待办事项五项计数、动态预警与促销横幅，底部五 tab 为 **首页 / 入库 / 采购 / 延保 / 我的**。
**关键交互** —— ①点门店名 → 切换门店（**本稿未画下拉箭头**，见下方说明）；②点眼睛图标 → 隐藏 / 显示金额类指标（[REQ-HOM-011](#426-业务规则)）；③点铃铛 → 进入消息列表，角标清零；④「快速核销-扫码 / 输码」→ 核销流程；⑤「车牌扫码-扫码 / 车牌」→ 接车进销售流程；⑥点待办任一项 → 进对应订单列表；⑦「查看全部」→ 全量预警列表；⑧点促销横幅 → 活动详情；⑨底部 tab 切换模块。
**可用角色** —— 店长 ✅ 全量。本稿的金额类分区（预计营收 / 毛利 / 客单价）对技工 ✗，见 [4.2.4](#424-技工首页)。
**需求关联** —— [REQ-HOM-001](#426-业务规则) 门店切换、[REQ-HOM-002](#426-业务规则) 问候语、[REQ-HOM-003](#426-业务规则) 消息公告、[REQ-HOM-005](#426-业务规则)/[006](#426-业务规则) 扫码与输码接车、[REQ-HOM-007](#426-业务规则) 快速核销、[REQ-HOM-008](#426-业务规则) 待办、[REQ-HOM-009](#426-业务规则) 动态预警、[REQ-HOM-011](#426-业务规则) 今日经营卡片
> **本稿的三处状态缺失**（属设计稿补稿，不新增需求）：①门店名旁**未画下拉箭头**，而功能宫格版画了 `▾` —— 切店器的表现形式两版不一致，随 [REQ-HOM-001](#426-业务规则) 统一；②动态预警角标写「2 项待处理」，但列表区**只画了 1 条**（低库存），第 2 条未画；③金额隐藏后的形态（打码还是留空）未画。
![设计稿-首页-技工](../app-design-images/首页-技工.png)
**页面内容** —— 技工首页目标形态，头部**无门店名与铃铛**、橙色卡改为「今日已完工 8 单」且**不含任何金额**，快速核销与车牌扫码两张卡同店长版，其下是技工独有的「当前施工队列（共 2 单）」工单卡，底部五 tab 与店长版一致。
**关键交互** —— ①「查看绩效明细」→ 技工个人绩效页（该页无设计稿）；②「开始施工」→ 工单转「安装中」；③「完工并结算」→ 结算（去 F6 结算页还是 App 内页未定 `TODO(REQ-HOM-012)`）；④快速核销与车牌扫码同店长版。**本稿未画**消息铃铛、待办事项、动态预警、促销位。
**可用角色** —— 技工 ✅。「当前施工队列」为技工独有，店长 ✗。技工是否应有消息 / 待办 / 预警三个分区，业务需求说有、本稿未画 —— `TODO(REQ-HOM-003)` / `TODO(REQ-HOM-008)` / `TODO(REQ-HOM-009)`。
**需求关联** —— [REQ-HOM-011](#426-业务规则)（技工只看完工单数，本稿是该规则的直接落地）、[REQ-HOM-012](#426-业务规则) 当前施工队列
> 卡片一的施工内容写作「**更**正品查验 + 动平衡 + 轮胎号延保绑定」，疑为「更换 / 正品查验」的文案笔误，补稿时一并核对。
![设计稿-首页-功能宫格版](../app-design-images/首页-功能宫格版.png)
**页面内容** —— 首页备选方案（对应[三版底部导航](#425-导航收敛与角色化配置)的方案 C），自上而下为内嵌核销码输入框的橙色头部、限时活动三张商品卡、待办事项五项计数、八宫格功能入口与经营业绩区（四个时间 tab + 三项指标，数值为占位），底部五 tab 为 **首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心**。
**关键交互** —— ①输核销码 → 点「核销」直接核销（比店长版少一步进卡片）；②「限时活动-更多」→ 活动列表；③点商品卡 → 目标未定，见 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)；④点八宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）任一 → 进对应模块；⑤切换当日/当周/当月/当季 → 刷新经营指标；⑥「经营业绩-更多」→ 经营报表。
**可用角色** —— 本稿**未区分角色**，仅作导航方案备选。若采用，需补技工版 —— 稿中「经营业绩」含 O2O 成交金额，属金额类，对技工应不可见（`TODO(REQ-PRF-001)`）。
**需求关联** —— [REQ-HOM-010](#426-业务规则) 角色化导航（本稿即方案 C 的实体）、[REQ-HOM-007](#426-业务规则) 快速核销、[REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 促销位形态与来源
> **本稿与店长版的两处口径不一致**，需在 [REQ-HOM-008](#426-业务规则) / [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 一并裁决：①待办首项，店长版写「待**接**单」、本稿写「待**订**单」；②促销位，店长版是底部活动横幅、本稿是顶部三商品卡、技工版没有 —— **三版稿画了三种形态**；且本稿三张商品卡**直接用了京东站内推广创意**（可见「京东JOY」「JD.COM」「爱奇艺」等第三方水印），正式稿须换成马牌自有素材。
## 4.2.1 需求描述
**业务目标** —— 把分散在三套小程序的入口、待办、经营数据聚合到一屏，让门店开工第一眼就知道「今天有什么要做、有什么要盯」，解决[痛点 2.1](../Continental-Retail-APP-PRD.md#21-多小程序分散) 与 [2.5](../Continental-Retail-APP-PRD.md#25-数据经营分析)
**目标角色** —— 店长、技工（内容差异见 [4.2.3](#423-店长首页)、[4.2.4](#424-技工首页)）
**入口** —— 登录成功后默认落地；任意页面点击底部「首页」tab
**前置条件** —— 已登录且已确定当前门店上下文
**页面内容** —— 见 [4.2.3](#423-店长首页)、[4.2.4](#424-技工首页)
**主流程**：
1. 进入首页
2. 并行拉取门店信息、待办、预警、促销、经营卡片
3. 分区渲染，任一分区失败不阻塞其它分区
4. 用户点击分区进入对应模块
**异常流程**：
- 单个数据源超时/失败 → 该卡片显示占位与「重试」，其余正常展示（局部降级，见《后端跨域协作与聚合文档》）
- 门店未接 F6 → 隐藏依赖 F6 的分区与 tab
- 无待办 → 显示空态而非隐藏分区
**业务规则** —— 见 [4.2.6](#426-业务规则)
**权限规则** —— 底部 tab 集合、卡片可见性均由 App Backend 按「角色 + 门店能力」下发，客户端不硬编码，见 [4.2.5](#425-导航收敛与角色化配置)
**访问链路** —— App → App Backend（聚合）→ 并行 fan-out 至 O2O / ROOS / 延保 / CDMS / F6
**逻辑数据来源** —— 见 [4.2.7](#427-业务数据列表)
**回写目标** —— 消息已读状态回写 App Backend；其余为只读聚合
**状态变化** —— 消息：未读 → 已读；待办项计数随源系统单据状态变化
**验收标准** —— 见 [4.2.8](#428-验收标准)
## 4.2.2 现状导航与目标导航的差异
整合前，三套小程序各带一套底部导航，且互相之间用「首页放友链」的方式跳转（见 [2.7.1](../Continental-Retail-APP-PRD.md#271-现状导航结构)）。整合后**全部小程序 tabbar 一律废弃**，App 只保留一套底部导航。
| 现状入口 | 现状位置 | App 归属 |
| --- | --- | --- |
| ROOS 首页 / 商品 / 购物车 | ROOS tabbar | 合并进「采购」tab（[4.6](./06-PUR-采购.md)） |
| ROOS 我的 | ROOS tabbar | 拆分：账务类进「我的」（[4.8](./08-MIN-我的.md)），对账单进[财务](./10-FIN-财务与对账.md)，业绩进[经营业绩](./12-PRF-经营业绩与报表.md) |
| ROOS 扫码出库 / 扫码入库 | ROOS 首页 | 「入库」tab（[4.7](./07-INV-库存.md)） |
| O2O 核销码输入 + 核销 | O2O 首页顶部 | 首页「快速核销」卡片 |
| O2O 订单管理五状态 | O2O 首页 | 首页「待办事项」+ [4.3 销售](./03-SAL-销售.md)的订单列表 |
| O2O 两组功能宫格（13 项） | O2O 首页 | 分派至 [4.9](./09-STM-门店管理.md) / [4.10](./10-FIN-财务与对账.md) / [4.11](./11-RBT-返利中心.md) / [4.12](./12-PRF-经营业绩与报表.md) / [4.13](./13-MKT-营销与会员.md) |
| 延保 首页 / 工作台 / 待办事项 / 我的 | 延保 tabbar | 合并进「延保」tab（[4.5](./05-WTY-延保.md)） |
| 「订货平台 / O2O / 延保门店端 / 积分兑换 / 零售管理」互跳宫格 | ROOS + O2O 首页 | **取消**——整合后无需互跳；其中「积分兑换」保留为 [4.14 福利兑换](./14-MSP-福利兑换.md)入口 |
现状入口 → App 导航映射
## 4.2.3 店长首页
自上而下分区（见本节店长首页设计稿）：
**一、门店切换**
当前用户旗下如果有多家店，可以通过顶部的下拉选择项切换至不同的门店。切换后所有业务数据按新门店重新加载。
**二、问候语**
用户成功登录首页后，在左上方展示用户信息以及问候。系统读取当前用户的姓氏、角色以及当前时间段，整合成合适的问候语，如「张店长，上午好」。
**三、消息公告**
右上角铃铛图标的角标展示当前未读消息条数；点击图标以列表形式展示系统站内信；点击后角标数字消失。促销信息展示往期马牌的所有促销活动；通知消息由管理员在后台管理平台发布。
![现状-ROOS 公告列表-空态](../mini-program-images/ROOS/公告列表-空态.png)
**页面内容** —— ROOS 小程序「公告列表」页，**本图为空态**（「暂无公告」占位），故公告条目的字段构成无法从本图确认。
**关键交互** —— ①左上返回；②有数据时点条目进详情（本图无法确认）。本页除返回外**无任何筛选、搜索或标记已读的控件**。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-HOM-003)`。ROOS 侧现状不区分角色。
**需求关联** —— [REQ-HOM-003](#426-业务规则) 消息公告、[REQ-HOM-004](#426-业务规则) 促销信息（往期促销即在本列表中承载）
![现状-O2O 消息-门店违规提醒](../mini-program-images/O2O/消息-门店违规提醒.png)
**页面内容** —— O2O 接单宝「消息」页，按日期分组的卡片流，**本图可见的消息全部是同一类**（`【门店违规】提醒`），且**最新一条已是 2023-04-13**。
**关键交互** —— ①上下滑动按日期倒序浏览。**未见**已读标记、删除、分类筛选或点击进详情的控件 —— 本页是纯只读消息流。
**可用角色** —— 店长 ✅（违规会导致「禁止接单」，属店长必须知悉的治理类消息）；技工 ❓ `TODO(REQ-HOM-003)`。
**需求关联** —— [REQ-HOM-003](#426-业务规则)。本图是「消息分类体系」这条待确认的核心证据：O2O 侧是**会阻断经营的治理类消息**，ROOS 侧是**促销与通知类公告**，两者的紧急程度、是否需强提醒、能否删除完全不同，合并进一个消息中心时必须分类承载。本图的违规原因样例为「车牌号已超出年度最大下单量」「同一手机号下多笔订单超过限制数量」「门店单日销量超过限制数量」，均由风控规则触发，正文写「门店触发违规条件，已被禁止接单」并附「如有异议，请联系门店相应的销售代表」。
> 现状消息分散在 ROOS「公告」与 O2O「消息」两处，且类型不同（ROOS 为促销/通知公告，O2O 含门店违规提醒等治理类消息）。整合后需在一个消息中心内分类承载 —— 消息分类体系 `TODO(REQ-HOM-003)`。
>
> **补充**：附录 A.2 已定义消息列表「支持查看、标记已读、删除」，但上面两张现状图**都没有这三个控件** —— 这三项是 App 的新增能力，不是现状迁移，开发时需明确它们作用于哪一侧数据（App 自有消息表还是回写 ROOS / O2O）。
**四、促销信息**
提醒用户当前马牌轮胎有促销活动，系统展示马牌最近一次举行的促销活动；点击促销区域展示具体活动内容。促销活动内容来自 **ROOS** 提供的接口；APP 后台定时调用促销活动接口，拉取促销信息并推至用户首页；往期促销信息在右上角铃铛对应的列表页中展示。
设计稿中该区域为首页底部的横幅广告位（「马牌高端系列 买三送一」）。
> ⚠️ 三版设计稿对促销位画了三种形态 —— 形态与来源需一并裁决，见 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)。
**五、扫码接车**
当客户车开进马牌门店时，用户可以直接点击「扫码」按钮，对准客户车头识别车辆号牌，进入销售流程。
> 扫码由 **App 原生能力**实现（`native_scan`），非 F6 提供的扫码页，见 [C5](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。**车牌识别走云端 OCR 服务**：拍一张照上传识别，不是取景框里的实时识别，因而**依赖网络**——「输码」不是失败后的降级，而是与「扫码」并列的常驻入口。见[第 10 章风险 R9](../Continental-Retail-APP-PRD.md#104-风险登记)。
**六、输码**
在做客户接车时，因特殊原因无法正确通过「扫码」识别客户车牌时，可以通过「车牌」按钮手工输入客户的车辆号牌，进入销售流程。
**七、快速核销**
设计稿在「车牌扫码」之外并列了一组「快速核销」（扫码 / 输码），对应 O2O 接单宝首页顶部的核销码输入框 —— 消费者到店出示线上订单核销码，门店扫码或手工输码完成核销。
> 扫码核销的详细流程待确认 —— `TODO(REQ-SAL-010)`，详见 [4.3.4](./03-SAL-销售.md#434-核销)。
**八、待办事项**
待办事项在首页中扮演用户助手的角色，方便用户随时查看自己的工作列表。每项提醒的上方显示该项对应的待办事项总数。
现有两套并存的待办口径，**两者不冲突，是两个层次**：
| 层次 | 项目 | 来源 | 说明 |
| --- | --- | --- | --- |
| **跨系统提醒**（业务层） | O2O 订单接单提醒、CDMS 采购单支付提醒、延保视频上传提醒、问卷提醒、过期门店信息更新提醒 | O2O / CDMS / 延保 / 待定 | 按来源系统聚合的业务提醒 |
| **订单流转状态**（单据层） | 待接单、待调货、待安装、待配送、待服务 | O2O 订单管理 | 设计稿口径；对应 O2O 现状的「待接订单 / 调货中 / 待安装 / 待配送 / 配送中」 |
待办事项两层口径
> 设计稿的五项与 O2O 现状五状态一一对应但措辞不同（「待调货」vs「调货中」、「待服务」vs「配送中」）。首页最终展示哪一层、或两层如何合并展示 —— `TODO(REQ-HOM-008)`，见 [C2](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
>
> **补充**：措辞不一致不止存在于「设计稿 vs O2O 现状」，**两版设计稿之间也不一致** —— 店长版首项写「待**接**单」，功能宫格版写「待**订**单」。取哪一套措辞随本条一并定稿。
**九、动态预警**
动态预警在首页中扮演用户管家的角色，随时帮用户检查目标任务达成情况、库存数量预警、时效订单预警等。系统按紧急程度在动态预警右边展示需要及时处理的事件数量，并提供「查看全部」入口浏览所有需要及时处理的事件。
预警项全集：
| 预警项 | 数据来源 | 备注 |
| --- | --- | --- |
| 总预警数 | APP 后台计算 | 各项之和 |
| 月度签约达成预警 | `TODO(REQ-HOM-009)` | 达成口径与阈值待定 |
| 库存预警（低库存） | F6 | ⚠️ 未接 F6 不显示此项；设计稿示例为「低库存 马牌 205/55R16 剩余 5 条」 |
| 时效订单预警 | O2O | 临近履约时限的订单 |
动态预警项
> 各项预警的触发阈值（如低库存的条数门槛、时效订单的提前量）均未定义 —— `TODO(REQ-HOM-009)`，见 [C3](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
**十、今日经营卡片**
设计稿在问候语下方设有营收卡片：今日预计营收（¥34,500）、毛利率（88%）、成交单数（24 单）、客单价（¥1,437），并带「眼睛」图标支持一键隐藏金额。
> 该卡片仅见于设计稿。**「预计营收」的口径**（是否含未结算订单、是否含延保与返利、毛利率的成本口径）未定义 —— `TODO(REQ-HOM-011)`，见 [C8](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。金额隐藏功能对应[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控) 中「技工可查看门店财务数据」的风险控制诉求。
**十一、底部导航**
见 [4.2.5](#425-导航收敛与角色化配置)。
## 4.2.4 技工首页
技工首页与店长首页的分区差异（见本节技工首页设计稿）：
| 分区 | 店长 | 技工 | 说明 |
| --- | --- | --- | --- |
| 门店切换 | ✅ 下拉切换 | ⚠️ 仅显示门店名 | 拥有多门店权限的用户可切换门店；设计稿技工版无门店名与切换器 —— `TODO(REQ-HOM-001)` 需确认技工是否允许多门店 |
| 问候语 | 「张店长，上午好」 | 「韩师傅 · 技师」 | 设计稿技工版为「姓氏 + 师傅 · 角色」格式，无时段问候 |
| 消息公告 | ✅ 铃铛 + 角标 | ⚠️ 设计稿未出现 | 业务需求中技工应有消息公告 —— `TODO(REQ-HOM-003)` 需确认 |
| 促销信息 | ✅ | ✅ | 技工可见 |
| 今日经营卡片 | 今日预计营收 / 毛利 / 成交单数 / 客单价 | **今日已完工 N 单** + 「查看绩效明细」 | 技工不可见金额类数据，与[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控) 一致 |
| 快速核销 / 车牌扫码 | ✅ | ✅ | 完全一致 |
| 待办事项 | ✅ | ⚠️ 设计稿未出现 | 业务需求中技工应有待办事项 —— `TODO(REQ-HOM-008)` |
| 动态预警 | ✅ | ⚠️ 设计稿未出现 | 业务需求中技工应有动态预警 —— `TODO(REQ-HOM-009)` |
| **当前施工队列** | ❌ | ✅ | **技工独有分区，仅见于设计稿** |
店长 / 技工首页分区差异
> **上表「促销信息 技工 ✅」与技工版设计稿不符** —— 技工版稿中**没有促销位**（店长版有底部横幅、宫格版有顶部商品卡）。该行按业务需求填写，实际形态随 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 一并确认。
**当前施工队列**（技工独有）
展示分配给当前技工的施工任务，卡片含：车牌号、订单来源渠道标（天猫订单 / 京东订单）、状态标（安装中 / 待安装）、施工内容（如「更正品查验 + 动平衡 + 轮胎号延保绑定」「更换 马牌 UC6 225/55R17 * 4 条」）、预约时间、主操作按钮（「完工并结算」/「开始施工」）；顶部显示「共 N 单」。
> 该分区仅见于设计稿。涉及的问题：施工任务如何分派给具体技工？状态机与 F6 工单、O2O 服务单的关系？「完工并结算」跳转到 F6 结算页还是 App 内页？—— `TODO(REQ-HOM-012)`，见 [C13](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
## 4.2.5 导航收敛与角色化配置
**收敛原则**
1. 整合后 App 只有**一套**底部导航，所有小程序 tabbar 全部废弃；
2. tab 集合**不在客户端硬编码**，由 App Backend 在登录/切店后下发；
3. 下发依据为 **角色（店长 / 技工）× 门店能力（是否接 F6、是否开通延保等）**；
4. 客户端对未知 tab code 做忽略处理，保证后端可灰度增删 tab 而不强制发版。
**三版 tab 方案**
| 方案 | tab 集合 | 来源 |
| --- | --- | --- |
| A（业务菜单版） | 首页 / 库存 / 采购 / 我的 | 业务需求「用户主菜单」 |
| B（主设计稿） | 首页 / 入库 / 采购 / 延保 / 我的 | 设计稿 首页-店长、首页-技工、个人中心 |
| C（宫格版） | 首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心 | 设计稿 首页-功能宫格版 |
三版底部导航方案
三者的差别不只是段数：方案 A/B 是「业务动作导向」（去入库、去采购），方案 C 是「管理职能导向」（看门店、看经营、看账务），且方案 C 把业务动作全部收进首页的 8 宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）。
**推荐方案**：以 **B** 为基线（业务动作导向更贴合门店高频操作），把 C 的管理职能入口收进「我的」与首页宫格。
> ⚠️ **各角色的具体 tab 清单尚未确认** —— `TODO(REQ-HOM-010)`，见 [C1](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。下表为待确认的建议值：
| tab | 店长 | 技工 | 门店能力依赖 | 对应章节 |
| --- | --- | --- | --- | --- |
| 首页 | ✅ | ✅ | — | 4.2 |
| 入库 | ✅ | ✅ | — | [4.7](./07-INV-库存.md) |
| 采购 | ✅ | ⚠️ 授权可见 | — | [4.6](./06-PUR-采购.md) |
| 延保 | ✅ | ✅ | 门店已开通延保 | [4.5](./05-WTY-延保.md) |
| 我的 | ✅ | ✅ | — | [4.8](./08-MIN-我的.md) |
角色化 tab 配置（建议值，待确认）
> 店长版与技工版两张设计稿的底部导航**完全一致**（首页 / 入库 / 采购 / 延保 / 我的），即稿中并未体现角色化差异 —— 差异全在页面内容而非 tab 集合。上表把「采购」对技工标为「授权可见」，属建议值，设计稿并未画出技工少一个 tab 的形态。
**门店能力开关对导航的影响**
已明确一条硬规则：
> ⚠️ 如果当前用户所在门店未接 F6，「库存」菜单不显示；对技工还需叠加「技工无此权限则不显示」。
推广为通用规则：任一 tab 或首页分区若依赖某外围系统，而当前门店未接入该系统，则该 tab / 分区整体隐藏（而非置灰或点击后报错）。能力开关清单见 [7.4](../Continental-Retail-APP-PRD.md#74-门店能力开关)。
## 4.2.6 业务规则
**REQ-HOM-001 门店切换** —— 多门店账号可在首页顶部切换门店；切换后级联刷新全部数据，见《App 门店上下文与会话管理文档》
**REQ-HOM-002 问候语** —— 由「姓氏 + 角色称谓 + 时段问候」拼接；时段划分口径 `TODO(REQ-HOM-002)`
**REQ-HOM-003 消息公告** —— 角标为未读数；点击进入列表后清零。消息分类体系待定 `TODO(REQ-HOM-003)`
**REQ-HOM-004 促销信息** —— 来源 ROOS 接口，APP 后台定时拉取；首页展示最近一次活动，往期在消息列表
**REQ-HOM-005 扫码接车** —— App 原生扫码识别车牌 → 进入销售流程
**REQ-HOM-006 输码接车** —— 扫码失败时手工输入车牌 → 进入销售流程
**REQ-HOM-007 快速核销** —— 扫核销码或手工输入核销码 → 进入核销流程（[4.3.4](./03-SAL-销售.md#434-核销)）
**REQ-HOM-008 待办事项** —— 两层口径并存，最终展示形态待定 `TODO(REQ-HOM-008)`
**REQ-HOM-009 动态预警** —— 四项预警，阈值待定 `TODO(REQ-HOM-009)`；库存预警依赖 F6
**REQ-HOM-010 角色化导航** —— tab 集合由后端按角色 + 门店能力下发，清单待定 `TODO(REQ-HOM-010)`
**REQ-HOM-011 今日经营卡片** —— 店长看金额类指标（可隐藏），技工看完工单数；口径待定 `TODO(REQ-HOM-011)`
**REQ-HOM-012 当前施工队列** —— 技工独有；分派规则与状态机待定 `TODO(REQ-HOM-012)`
**REQ-HOM-013 分区降级** —— 任一数据源失败仅该卡片降级，不影响其它分区渲染
**REQ-HOM-016 促销位形态与来源** —— 三版设计稿画了三种互不相同的促销位形态（店长版底部通栏横幅、宫格版顶部三商品卡、技工版无），[附录 A.2](../Continental-Retail-APP-PRD.md#a2-首页) 又写作顶部滚动提示，共四种说法；宫格版素材直接用了第三方电商推广创意，正式稿须换成马牌自有素材。最终形态、数据来源、点击目标与技工可见性均待定 `TODO(REQ-HOM-016)`
## 4.2.7 业务数据列表
| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 门店名称列表 | StoreNameList | 马上下单 | 来自马上下单的门店列表 |
| 2 | 用户问候 | GreetingStr | APP Backend | 首页问候语，来自登录后获取的姓名和当前时间 |
| 3 | 消息公告 | Msg2PromotionList | APP 后台 + ROOS | 消息公告来自 APP 后台，促销信息来自 ROOS |
| 4 | 促销信息 | PromotionMsg | ROOS | 来自最新的 ROOS 促销信息 |
| 5 | 待办事项 | TodoList | 多源 | O2O 订单接单提醒：O2O 接口<br>CDMS 采购单支付提醒：CDMS 接口<br>延保视频上传提醒：延保接口<br>问卷提醒：`TODO(REQ-HOM-014)`<br>过期门店信息更新提醒：`TODO(REQ-HOM-015)` |
| 6 | 动态预警 | PrecautionIndexList | 多源 | 总预警数：APP 后台计算<br>月度签约达成预警：`TODO(REQ-HOM-009)`<br>库存预警：F6（⚠️ 未接 F6 不显示此项）<br>时效订单预警：O2O |
| 7 | 动态预警查看详情 | PrecautionAllList | 同上 | 全量预警列表 |
| 8 | 今日经营卡片 | TodayBusinessCard | `TODO(REQ-HOM-011)` | 预计营收 / 毛利率 / 成交单数 / 客单价（店长）；已完工单数（技工） |
| 9 | 当前施工队列 | WorkQueueList | `TODO(REQ-HOM-012)` | 技工独有；车牌、渠道、状态、施工内容、预约时间 |
| 10 | 底部 tab 配置 | TabConfigList | APP Backend | 按角色 + 门店能力下发 |
APP 首页信息字段
## 4.2.8 验收标准
1. 未接 F6 的门店，登录后底部导航不出现依赖 F6 的 tab，首页不出现库存预警项；
2. 多门店店长切换门店后，首页全部分区（待办、预警、经营卡片、促销）均刷新为新门店数据；
3. 任意单个上游系统（O2O / CDMS / 延保 / F6）不可用时，首页仍可打开，失败分区显示占位与重试，其余分区正常；
4. 技工登录后首页不出现任何金额类经营指标；
5. 消息角标数字与消息列表未读条数一致；进入列表后角标归零。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.2）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 切换后的店铺信息集 | App Backend | HTTPS | |
| 2 | 店铺列表结果集（用于切店） | App Backend | HTTPS | |
| 3 | 当前用户的菜单数据集 | App Backend | HTTPS | **即角色化 tab 下发**（[REQ-HOM-010](#426-业务规则)） |
| 4 | 动态预警 | Mini Program Backend | HTTPS | 来自 ROOS 与 O2O |
| 5 | 促销信息 | Mini Program Backend | HTTPS | 首页顶部滚动提示 |
| 6 | 公告/通知列表（按发布时间倒序） | Mini Program Backend | HTTPS | 支持查看、标记已读、删除 |
| 7 | 待办事项（按优先级/截止时间排序） | Mini Program Backend | HTTPS | 来自 O2O 与延保后台 |
首页模块数据集（摘自主文件[附录 A.2](../Continental-Retail-APP-PRD.md#a2-首页)）。字段级清单见上方 [4.2.7](#427-业务数据列表)。
> **第 5 条与设计稿不符**：附录 A 写促销信息是「首页**顶部滚动提示**」，而店长版稿把它画成**底部通栏横幅**、宫格版画成**顶部三商品卡**。三处形态互不相同 —— 随 [REQ-HOM-016](#附-5-本次拆分新增发现待业务确认) 统一。
>
> **第 6 条的三个动作在现状中都不存在**：ROOS 公告列表与 O2O 消息页均无「标记已读 / 删除」控件（见 [4.2.3](#423-店长首页) 两张现状图）。这三项属 App 新增能力，需明确作用于 App 自有消息表还是回写源系统。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 门店切换 | ✅ | ❓ | 技工是否允许多门店 `TODO(REQ-HOM-001)` |
| 消息公告 | ✅ | ❓ | 业务需求说有、设计稿未画 `TODO(REQ-HOM-003)` |
| 待办事项 | ✅ | ❓ | 同上 `TODO(REQ-HOM-008)` |
| 动态预警 | ✅ | ❓ | 同上 `TODO(REQ-HOM-009)` |
| 今日经营卡片（金额类） | 🔸 | ✗ | 店长可隐藏金额；技工仅见完工单数 `TODO(REQ-HOM-011)` |
| 当前施工队列 | ✗ | ✅ | 技工独有 `TODO(REQ-HOM-012)` |
首页模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本模块权限的特殊之处：**四个 ❓ 全部指向「技工能不能看」**，且四项都是设计稿未画所致，而非业务上已判定不可见。按 REQ-ACC-006，这四项在关闭前一律实现为技工不可见 —— 也就是说，**技工首页首版会是设计稿画的那个精简版**。若业务实际期望技工也有待办与预警，需尽早关闭这四条，否则会返工。
### 附-3 待确认项（主文件 10.2.2）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-HOM-001 | 技工是否允许多门店（设计稿技工版无切店器） | 产品 |
| REQ-HOM-002 | 问候语时段划分口径 | 产品 |
| REQ-HOM-003 | 消息分类体系；技工是否有消息公告 | 产品 |
| REQ-HOM-008 | 待办两层口径的最终展示形态（**C2**）；技工是否有待办 | 产品 |
| REQ-HOM-009 | 四项动态预警的触发阈值（**C3**）；技工是否有预警 | 业务 |
| REQ-HOM-010 | **各角色的具体 tab 清单（C1，最高优先级）** | 产品 |
| REQ-HOM-011 | 「今日预计营收 / 毛利率 / 客单价」口径（**C8**） | 财务 / 业务 |
| REQ-HOM-012 | 技工「当前施工队列」的分派规则与状态机（**C13**） | 产品 / 业务 |
| REQ-HOM-014 | 待办中「问卷提醒」的数据来源 | 业务 |
| REQ-HOM-015 | 待办中「过期门店信息更新提醒」的数据来源 | 业务 |
首页模块待确认项（摘自主文件 [10.2.2](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)，10 条）
**本次拆分新增 1 条**（回灌主文件时并入 10.2.2）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| **REQ-HOM-016** | **首页促销位的形态与来源** —— 三版设计稿画了三种形态、附录 A.2 又是第四种；素材含第三方电商水印；点击目标、数据来源与技工可见性均未定，详见[附-5](#附-5-本次拆分新增发现待业务确认) | 产品 / 业务 |
合计 11 条待确认（原 10 条 + 新增 1 条）。回灌时需同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 HOM 行（15 / 10 / 33% → 16 / 11 / 31%）与第 10.2 节总数。
> `TODO(REQ-HOM-010)` 是全文最高优先级的待确认项（**C1**），其落地前提是后台的「APP 配置」粒度 `TODO(REQ-ADM-002)`。两者构成一条链：**后台配得出来 → tab 才下发得下去 → 首页才知道画谁的版本**。
### 附-4 配图清单（主文件附录 C 4.2 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-首页（店长）：营收卡 + 双扫码卡 + 待办五项 + 动态预警 + 促销横幅 + 五 tab | `../app-design-images/首页-店长.png` |
| 2 | 设计稿-首页（技工）：完工单数卡 + 双扫码卡 + **当前施工队列**，无消息/待办/预警 | `../app-design-images/首页-技工.png` |
| 3 | 设计稿-首页（功能宫格版，备选方案 C）：核销码输入 + 限时活动三商品卡 + 八宫格 + 经营业绩 | `../app-design-images/首页-功能宫格版.png` |
| 4 | 现状-ROOS 公告列表（空态，无已读/删除控件） | `../mini-program-images/ROOS/公告列表-空态.png` |
| 5 | 现状-O2O 消息（全部为【门店违规】治理类消息，最新一条 2023-04） | `../mini-program-images/O2O/消息-门店违规提醒.png` |
首页模块配图清单，5 张（设计稿 3 / 现状-ROOS 1 / 现状-O2O 1）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
### 附-5 本次拆分新增发现（待业务确认）
以下 1 条**不在主文件现有 15 条 HOM 需求内**，是本次逐张核看 5 张配图时发现的、现有需求未覆盖的事项。编号接 REQ-HOM-015 顺延，**尚未登记进主文件 10.2.2**，回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。
| 编号 | 待确认内容 | 证据 | 建议决策方 |
| --- | --- | --- | --- |
| REQ-HOM-016 | **首页促销位的形态与来源**：三版设计稿画了三种互不相同的形态 —— 店长版是底部通栏活动横幅（「马牌高端系列 买三送一」），宫格版是顶部「限时活动」三张商品卡（带划线价、「已售 N」、立减券，**素材含京东JOY / JD.COM / 爱奇艺水印，属第三方电商推广创意**），技工版**没有促销位**；而主文件附录 A.2 又写作「首页**顶部滚动提示**」，共四种说法。需裁决：①最终形态；②数据来源是 ROOS 活动接口（[REQ-HOM-004](#426-业务规则) 现有口径）还是第三方电商商品位；③若含商品位，点击后去哪（App 内商详 / 跳京东小程序 / 跳 [ROOS 采购](./06-PUR-采购.md)）；④技工是否可见（[4.2.4](#424-技工首页) 差异表写 ✅，但技工版稿没画）。 | 本节图 1 / 2 / 3 + 附录 A.2 | 产品 / 业务 |
本次拆分新增待确认项，1 条
> 另有三项**不需新增编号**的观察，已就地记在各图下方：①店长版门店名旁未画切店下拉箭头而宫格版画了（随 [REQ-HOM-001](#426-业务规则) 补稿）；②动态预警角标写「2 项待处理」但只画了 1 条（补稿）；③店长版「待接单」与宫格版「待订单」措辞不一致（随 [REQ-HOM-008](#426-业务规则) 定稿）。
>
> 另有一项数据观察：O2O 消息页**最新一条消息的日期是 2023-04-13**，距今已超三年，且全部为同一类型。可能是该测试账号无近期消息，也可能是 O2O 消息通道现状本就低频 —— 若属后者，「消息中心」在 App 内的实际价值需重新评估。本图不足以判定，建议向业务核实真实门店的消息量级。
prd/modules/03-SAL-销售.md
+801
View File
@@ -0,0 +1,801 @@
# 4.3 销售
> **本文件是【销售 SAL】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.3 节已于 2026-08 从本文件回灌（V1.1），
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**
| 项 | 值 |
| --- | --- |
| 模块码 | SAL |
| V1.0 章节 | 4.3 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 原型图 + O2O 订单截图 |
| 现状承载系统 | F6 + O2O |
| 需求条数 | 37（待确认 12，完成度 68%） |
| 配图 | 28 张（原型-F6 11 / 设计稿 1 / 现状-O2O 16） |
> **关于「原型」图源的说明**：本节 11 张标注为「原型」的图，实为 **F6 系统的真机截图拼版**（多联屏，图下带中文标注），不是线框稿。其中 `原型-销售-历史记录页`、`原型-销售-车主车辆卡片`、`原型-销售-历史工单`、`原型-销售-延保历史记录` 四张是 **App 目标形态的设计稿**（iPhone 边框、马牌橙配色），其余 7 张是 F6 现状截图（蓝色主色）。两类图混在同一前缀下容易误读，引用时须按实际图源理解，不以前缀为准。
用户登录成功后，通过「扫码」按钮扫描客户车牌，即可进入销售流程。
## 4.3.1 需求描述
**业务目标** —— 把「车开进门店」到「结算完成并办理延保」的全链路装进一个 APP，消除 F6、O2O、延保三系统间的重复录入，解决[痛点 2.6](../Continental-Retail-APP-PRD.md#26-售后延保)
**目标角色** —— 店长；技工（授权后功能一致，见 [4.3.8](#438-角色差异)）
**入口** —— 首页「扫码 / 车牌」（接车）；首页「快速核销」（线上订单核销）；底部导航进入订单列表
**前置条件** —— 已登录并确定门店上下文；接车与施工链路要求**门店已接入 F6**；核销链路要求门店已开通 O2O
**页面内容** —— 见 [4.3.2](#432-接车与车辆识别)–[4.3.7](#437-结算与延保跳转)
**主流程**：
1. 扫码/输码识别车牌
2. 后端凭车牌向 F6 取车主车辆信息
3. 展示历史工单与延保历史
4. 新建工单 / 检测开单
5. 施工查车
6. 生成检测报告并发送车主
7. 检测单转工单
8. 完工
9. 结算收银
10. 结算后跳转延保
**异常流程**：
- 车牌识别失败 → 转手工输码
- F6 无该车档案 → 进入新建车辆建档流程
- 门店未接 F6 → 隐藏历史工单、销售商机、施工查车、结算等 F6 分区
- F6 接口超时 → 提示重试且不生成半截单据
- 核销码无效/已核销/过期 → 分别给出可区分的错误提示
**业务规则** —— 见 [4.3.9](#439-业务规则)
**权限规则** —— 技工被分配销售权限后功能与店长一致；未授权技工不可见销售入口。金额类信息（商品总价、实收金额）对技工的可见性 —— `TODO(REQ-SAL-012)`
**访问链路**：
- 车辆信息/工单/检测/结算：App → App Backend → **F6 Integration Adapter** → F6；F6 页面以 **Embedded H5** 形式嵌入，原生能力经 JSBridge 提供（见《App Embedded H5 容器与 JSBridge 文档》）
- 线上订单/核销/服务单：App → App Backend → O2O
- 延保历史：App → App Backend → 延保后台
**逻辑数据来源** —— 车主车辆、历史工单、检测、工单、结算：**F6**；销售商机（服务提醒 + 意向池）：**F6**；延保历史：**延保后台**；线上订单、服务单、核销：**O2O**
**回写目标** —— 工单、检测单、结算单回写 F6；核销结果回写 O2O；延保建单回写延保后台
**状态变化**：
- 车辆：未到店 → **已在店** → 离店
- 工单：接车 → 开单 → 施工 → 完工 → 已结算
- 检测单：待检 → 已检（正常/异常）→ 转工单 / 转商机
- 线上订单：待接单 → 调货中 → 待安装 → 待配送 → 配送中 → 已完成
**验收标准** —— 见 [4.3.10](#4310-验收标准)
---
## 4.3.2 接车与车辆识别
![设计稿-销售-历史记录页](../images/原型-销售-历史记录页.png)
**页面内容** —— 接车成功后的「历史记录」页（App 目标形态）：顶部为交易流水号与橙色「已在店」状态，中部是橙色车主车辆卡，下方「历史工单 / 延保历史记录」两个 tab，底部固定三个橙色描边按钮。
**关键交互** —— ①切换「历史工单 / 延保历史记录」两个 tab；②点击车架号旁的复制图标 → 复制 VIN；③点击车辆卡右上「销售商机」→ 销售商机页；④展开/收起工单卡的「查看项目材料」→ 显示项目 / 工时费 / 折后价明细；⑤底部三按钮 —— 「新建工单」进 F6 开单、「扫码核销」进核销流程、「延保」直接进延保建单。
**可用角色** —— 店长 ✅ 全量；技工 ⚙️ 需被分配销售权限（见附录 B）。金额字段（商品总价 ¥5.00 / 实收金额 ¥5.00）对技工是否可见未定 `TODO(REQ-SAL-012)`。
**需求关联** —— [REQ-SAL-001](#439-业务规则) 交易流水号、[REQ-SAL-015](#439-业务规则) 与 F6 单号并存、[REQ-SAL-016](#439-业务规则) 接车页三个并列入口
> **本图揭示了正文未记的一条重要路径**：接车页底部同时给出「新建工单 / 扫码核销 / **延保**」三个入口，即**延保可以直接从接车页发起，不必先走 F6 结算**。而 4.3.7 只描述了「结算后跳延保」一条路径。两条路径都要支持，见 [REQ-SAL-016](#439-业务规则)。
>
> 另有两处设计稿的示例数据自相矛盾，设计评审时应修正：车辆卡的当前里程是 **23456 km**，而下方历史工单的行驶里程是 **30000km** —— 上次到店的里程大于当前里程，逻辑上不成立。
**一、交易记录号**
APP 自动按预定规则生成门店交易流水号，在业务保存时提交此唯一交易号。
> 流水号生成规则（前缀、门店码位数、日期段、序列位数、跨天重置策略）未定义 —— `TODO(REQ-SAL-001)`。该号需保证幂等提交，见《后端并发、事务与定时任务文档》。
**二、已在店**
车牌扫码成功或用户输码成功后，系统显示该车状态为「已在店」。
**三、当前时间**
APP 获取手机系统当前时间；格式：`YYYY-MM-DD HH:mm`。
**四、车主车辆信息**
![设计稿-销售-车主车辆卡片](../images/原型-销售-车主车辆卡片.png)
**页面内容** —— 车主车辆卡的放大视图：橙色圆角卡内自上而下为车牌号、车主姓名、行驶证车架号（带复制按钮）与「里程 | 最近到店」一行，右上角是「销售商机」胶囊。
**关键交互** —— ①点击车架号右侧复制图标 → 一键复制 VIN；②点击「销售商机」→ 销售商机页（仅接入 F6 的门店可见）；③车牌与其余字段为只读展示。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。车主姓名属消费者个人信息，展示口径见 [REQ-SAL-026](#439-业务规则)。
**需求关联** —— [REQ-SAL-002](#439-业务规则) 车牌识别、[REQ-SAL-003](#439-业务规则) 车辆信息获取、[REQ-SAL-006](#439-业务规则) 销售商机、[REQ-SAL-017](#439-业务规则) 「待确认」态的展示位
> [REQ-SAL-002](#439-业务规则) 要求「置信度偏低时以『待确认』展示」，但**本卡片的设计上没有承载该状态的位置** —— 车牌是纯展示文本，既无角标也无可点编辑入口。须补设计，见 [REQ-SAL-017](#439-业务规则)。另外只有车架号有复制按钮，车牌没有。
用户扫码获取车辆车牌后，后台通过车牌从 F6 获取车主信息、行驶证车架号、车辆里程，以及最近一次到店时间；如果是第一次到店，显示当天时间。
| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 车牌 | CarPlate | 拍照识别或手工输入 | 识别经云端 OCR，需联网；置信度低时以「待确认」展示 |
| 2 | 车主姓名 | OwnerName | F6 接口获取 | |
| 3 | 车架号 | VIN | F6 接口获取 | 支持一键复制 |
| 4 | 里程 | Milage | F6 接口获取 | |
| 5 | 最近到店时间 | LatestArrDate | F6 接口获取 | 首次到店显示当天 |
根据车牌获取车主车辆信息
**五、历史工单**
![设计稿-销售-历史工单](../images/原型-销售-历史工单.png)
**页面内容** —— 「历史工单」tab 的放大视图：一条工单卡，含门店与服务时间的卡头、车牌与「已结算」标、行驶里程 / 服务顾问 / 业务分类、商品总价与实收金额，底部是可展开的「查看项目材料」明细表。
**关键交互** —— ①点击「查看项目材料 ^」→ 展开/收起明细表；②卡片本身是否可点入工单详情本图无法确认。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权，且**商品总价与实收金额两个字段是否屏蔽未定** `TODO(REQ-SAL-012)`。**门店未接 F6 时整个分区不显示。**
**需求关联** —— [REQ-SAL-004](#439-业务规则) 历史工单来自 F6，未接 F6 则整区不显示
展示该车以前的维修记录。历史记录从 F6 取；**如果门店未接 F6，则「历史工单」不显示**。
字段：门店名、服务时间、车牌号、行驶里程、服务顾问、业务分类、商品总价、实收金额、结算状态、可展开的「查看项目材料」（项目 / 工时费 / 折后价）。
**六、延保历史记录**
![设计稿-销售-延保历史记录](../images/原型-销售-延保历史记录.png)
**页面内容** —— 「延保历史记录」tab：三张保单卡纵向排列，每张含编号、车牌、保障类型标签、时间与「详情 >」入口，右上角是状态胶囊（正常 / 待确认 / 待补充）。
**关键交互** —— ①点击「详情 >」→ 保单详情（进入 [4.5 延保](./05-WTY-延保.md#45-延保)）；②保障标签（数包保障 / 爆胎保障 / 延保服务）为只读标识，一张保单可带多个标签。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。数据来自延保后台，不受门店是否接入 F6 影响。
**需求关联** —— [REQ-SAL-005](#439-业务规则) 延保历史来自延保后台，与历史工单并列为两个 tab
> **本图有两处必须在设计评审时修正的设计问题：**
> 1. **状态色与语义错配** —— 「正常」用橙色（警示色）、「待确认」用绿色（成功色）、「待补充」用红色。按通行约定应为：正常=绿、待确认=橙、待补充=红。
> 2. **三条记录的 POLICY NO. 完全相同（8507302611），车牌也相同（豫AQ27Z3），但状态各不相同** —— 若保单号唯一，则不应出现三条；若一张保单可对应多条保障记录，则列表的主键与去重规则需说明。同时该车牌与本节其它图的 `鄂AH0889` 不是同一台车，属拼版示例数据不一致。
延保历史记录通过「延保」小程序后台获取信息。字段：POLICY NO.、车牌、保障标签（数包保障 / 爆胎保障 / 延保服务）、保单状态（正常 / 待确认 / 待补充）、时间、详情入口。
**七、销售商机**
开通 F6 的门店才有此功能。点击「销售商机」展示销售商机页，「服务提醒」和「意向池」的内容来自于 F6 接口。
## 4.3.3 检测、开单与施工
**八、新建工单**
点击「新建工单」，弹出新建工单页，**由 F6 开发页面**。
![现状-F6 到店记录与建档](../images/原型-销售-到店记录与建档.png)
**页面内容** —— F6 三联屏：左屏「到店记录」（F6 单号 + 「已在店」、含「完善信息 / 完善VIN码」入口的蓝色车辆卡、保险信息分区、里程与油量、四个开单入口图标、「小程序订单」关联行、底部「离店」），中屏是新车辆建档表单，右屏是「车辆详情」。
**关键交互** —— ①左屏四个开单入口（预检开单 / 检测开单 / 报价开单 / 工单开单）→ 各自的开单流程；②保险信息每行右侧「查询」→ 触发**机器人（RPA）代查**保险到期日，「去完善 >」→ 手工补录；③点击「小程序订单 无待服务订单 >」→ 查看该车关联的 O2O 订单；④点击「离店」→ 车辆状态由「已在店」转「离店」；⑤中屏车牌号与 VIN 均可勾选「无」，也可点扫描图标调用相机；⑥中屏客户姓名右侧的通讯录图标 → 从手机通讯录选联系人；⑦右屏「复制VIN」「客户信息 >」「配置详情 >」「开单」。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。**页面由 F6 提供并在 Embedded H5 内运行，页内权限由 F6 控制，App 只控入口可见性。**
**需求关联** —— [REQ-SAL-007](#439-业务规则) 页面由 F6 提供、[REQ-SAL-015](#439-业务规则) 两套单号并存、[REQ-SAL-018](#439-业务规则) 无车牌/无 VIN 建档、[REQ-SAL-019](#439-业务规则) 通讯录能力、[REQ-SAL-026](#439-业务规则) 车主信息脱敏、[REQ-SAL-037](#439-业务规则) 到店时提示待服务订单
> **本图有四处关键发现：**
> 1. **两套单号并存** —— F6 到店记录用的是 F6 自己的单号（`DD` 前缀），而 App 接车页顶部用的是 App 生成的交易流水号（`D` 前缀，格式与位数都不同）。同一次接车挂着两个号，须定义映射与对外展示口径，见 [REQ-SAL-015](#439-业务规则)。
> 2. **F6 侧已有「小程序订单」关联入口** —— 说明 F6 与 O2O 之间已存在关联通道。这对 `TODO(REQ-SAL-014)`（服务单与工单关系）是重要证据，也意味着 App 整合后不应再出现两套互不相通的订单视图，见 [REQ-SAL-037](#439-业务规则)。
> 3. **建档时车牌与 VIN 都可勾「无」** —— 允许无车牌车辆建档，但这类车既无法扫码接车，也无法按车牌与延保保单绑定，见 [REQ-SAL-018](#439-业务规则)。
> 4. **客户姓名支持从手机通讯录选取** —— 这是需要通讯录读取权限的原生能力。H5 在 App 容器内运行时该能力不可用，且通讯录属高敏感权限，见 [REQ-SAL-019](#439-业务规则)。
>
> 另：右屏车辆详情**完整展示车主手机号并提供「复制」按钮**，车主是消费者而非门店员工，属个人信息保护范畴，见 [REQ-SAL-026](#439-业务规则)。F6 页面主色为蓝色，与 App 橙色主题不一致。
到店记录页含：车牌、完善信息入口、保险信息（交强险 / 商业险 / 保险公司到期日与查询状态）、当前里程与油量、四个开单入口（预检开单 / 检测开单 / 报价开单 / 工单开单）、小程序订单关联区、「离店」按钮。
新车辆建档页含：车牌号（支持扫描）、车辆用途（乘用车 / 商用车）、VIN（17 位，支持扫描，保存后自动解析车型）、车型、客户信息（姓名、手机号码）、更多联系人、行驶证信息。
车辆详情页含：品牌车型、VIN、编辑车辆 / 编辑车辆标签、建档人、车辆分类、燃油类型、年检日期、一级类型、轮胎规格与发动机型号等出厂配置详情、客户信息、消费历史、保险保养信息、「给当前车辆发票」/「开单」。
**九、施工查车**
页面中的「预检开单」等操作按钮弹出相关工单页，**由 F6 开发页面**。
![现状-F6 检测开单](../images/原型-销售-检测开单.png)
**页面内容** —— F6 两联屏：左屏是「到店记录」下滑后的上半部分（橙色商机提醒条、历史记账 / 上次服务 / 定金 / 卡 / 优惠券五项汇总、专属顾问、客户标签、轮胎出厂规格），右屏是点「检测开单」后从底部弹出的检测项目选择面板。
**关键交互** —— ①点「检测开单」→ 弹出面板，五选一：**底盘检测 / 保养速检 / 轮胎专检 / 3万公里保养检测 / 新能源检测**；②点「商机」条的「已过1条 共1条 >」→ 商机明细；③点客户标签「共3个 >」→ 标签全量；④「收起 ^」折叠车辆信息区。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。金额类字段（历史记账、定金）对技工的可见性同 `TODO(REQ-SAL-012)`。
**需求关联** —— [REQ-SAL-007](#439-业务规则) 页面由 F6 提供、[REQ-SAL-020](#439-业务规则) 检测项目类型
> 正文只写了「预检开单等操作按钮弹出相关工单页」，未列检测项目类型。**实际有 5 类**，轮胎门店最相关的是「轮胎专检」，见 [REQ-SAL-020](#439-业务规则)。
> 另：F6 已存有该车的「轮胎出厂规格 前后轮 235/60 R18」，这条数据对采购推荐与延保建单都有用，App 整合后应加以利用。「商机」的具体形态之一就是**车险到期提醒**，可与 [4.4 提醒](./04-RMD-提醒.md#44-提醒)的提醒规则打通。
![现状-F6 轮胎专检](../images/原型-销售-轮胎专检.png)
**页面内容** —— F6 两联屏「轮胎专检」：左屏是初始态（全部(24) / 已检(0) / 未检(24) 三个 tab、按轮位分组的检测项与结论按钮、底部「放弃检测 / 批量通过 / 保存」），右屏是已检 2 项并弹出「确定将未检测项目批量通过吗？」二次确认的状态。
**关键交互** —— ①点结论按钮选定检测结果（花纹深度：正常 / 尽快更换 / 立即更换；偏磨：正常 / 偏磨中间 / 偏磨胎肩 / 失圆；外伤：正常 / 鼓包 / 划伤 / 漏气）；②「+ 添加备注/图片」→ 拍照或选图上传（右上「0/200」疑为上传配额，**本图无法确认其含义**）；③点轮位分组右侧「检测视频」→ 录制或查看该轮位视频；④「批量通过」→ 二次确认后把所有未检项一次性标记为正常；⑤「放弃检测」退出，「保存」提交。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权 —— 施工查车是技工的核心作业，实际使用者以技工为主。
**需求关联** —— [REQ-SAL-007](#439-业务规则) 页面由 F6 提供、[REQ-SAL-021](#439-业务规则) 批量通过的留痕
> **「批量通过」是一处质量风险**：一次点击即可把 22 项未实检的项目标记为「正常」，而这些结论会直接进入发给车主的检测报告。App 侧须保留该效率功能，但必须留痕并在报告上标注哪些项是批量通过的，见 [REQ-SAL-021](#439-业务规则)。
> 另：全量检测项共 **24 项**，正文只描述了花纹深度 / 偏磨 / 外伤三类，未说明 24 项如何分布（四轮 × 三项 = 12，其余 12 项的构成本图无法确认）。
轮胎专检页：tab「全部(N) / 已检(N) / 未检(N)」；按轮位分组（如「左前轮检测」）含检测视频入口；每个检测项（花纹深度检测 / 偏磨检测 / 外伤检测）提供结论按钮（正常 / 尽快更换 / 立即更换、正常 / 偏磨中间 / 偏磨胎肩 / 失圆、正常 / 鼓包 / 划伤 / 漏气）与「添加备注/图片」；底部「共 N 项异常」+「放弃检测 / 批量通过 / 保存」；批量通过时弹确认。
![现状-F6 检测报告发送](../images/原型-销售-检测报告发送.png)
**页面内容** —— F6 两联屏「检测报告」：左屏为报告正文（红色环形健康度图「有隐患」、检测门店与服务人员、四类严重度计数卡、按严重度分组的检测明细含图片与视频、底部「客户签名 / 发给车主 / 去处理」），右屏是点「发给车主」后弹出的分享面板。
**关键交互** —— ①点「发给车主」→ 弹出五渠道面板，**每个渠道各有前置条件**：车主微信（带「隐私安全」角标，仅主订单可发）、公众号推送（车主未关注则置灰）、企业微信、短信（未购买时显示「立即购买 > / 通知老板买 >」）、他人微信（带「隐私使用」角标，提示"其他人都可看"）；②点「客户签名」→ 车主在屏上签名；③点「去处理」→ 检测问题处理页（见下一张图）；④点检测项的图片/视频 → 放大查看。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。发送渠道涉及车主个人信息外发，见 [REQ-SAL-026](#439-业务规则)。
**需求关联** —— [REQ-SAL-008](#439-业务规则) 检测报告发送、[REQ-SAL-022](#439-业务规则) 客户签名与渠道前置条件
> 正文写的「支持车主微信 / 公众号 / 企业微信 / 短信等渠道；短信渠道需购买」**漏了两件事**：一是第五个渠道「他人微信」及其隐私提示，二是**「客户签名」这个动作** —— 车主在检测报告上签名具有法律意义（是后续争议时门店已履行告知义务的凭据），必须留存签名图与时间戳。见 [REQ-SAL-022](#439-业务规则)。
> 另：四类计数卡下方各带「已解决(N)」，说明检测项可被标记为已解决，正文未提及该状态。
检测报告页：健康度环形图（有隐患）、检测门店 / 服务顾问 / 服务技师、四类计数（急需处理 / 择期处理 / 建议处理 / 正常，各带「已解决(N)」）、按类分组的检测明细（检测图片、项目说明、视频）、底部「客户签名 / 发给车主 / 去处理」。发送渠道弹层含：车主微信（仅主订单）、公众号推送（车主已关注）、企业微信、短信（需购买）、他人微信。
![现状-F6 检测单转工单](../images/原型-销售-检测单转工单.png)
**页面内容** —— F6 三联屏：左屏是检测报告页，中屏是点「去处理」后弹出的转单类型面板，右屏「检测问题处理」逐条列出异常项并对每条给出「转维修单 / 转商机」二选一，底部为「待处理: 2 本次处理: 2」+「提交」。
**关键交互** —— ①点「去处理」→ 弹出转单类型面板，**五选一**：转维保单或转商机 / 转维修单或转商机 / 转贴膜单或转商机 / 转洗车单或转商机 / 转理赔单或转商机；②每个异常项在「转维修单」与「转商机」间二选一（选中态为橙色实心）；③点「+ 项目」→ 添加服务项目并带出工时与金额；④点项目行右侧删除图标 → 移除；⑤底部计数随勾选实时变化，点「提交」生成单据。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。项目金额（¥40.00 / 工时 1.00）的可见性同 `TODO(REQ-SAL-012)`。
**需求关联** —— [REQ-SAL-009](#439-业务规则) 检测单转单、[REQ-SAL-023](#439-业务规则) 转单类型共五种
> **正文写的转单类型是四种，实际是五种** —— 多一个「转维保单或转商机」（面板第一项）。已在 [REQ-SAL-023](#439-业务规则) 就地更正。
检测问题处理页：只支持处理「急需」「择期」「建议」类项目（不包含车辆检测视频和聊天记录）；每个异常项提供「转维修单 / 转商机」二选一；选择维修单后可添加项目（含工时与金额）；底部「待处理: N 本次处理: N」+「提交」。转单类型弹层：转维保单 / 转维修单 / 转贴膜单 / 转洗车单 / 转理赔单，各与「转商机」二选一。
![现状-F6 维修单与完工](../images/原型-销售-维修单与完工.png)
**页面内容** —— F6 两联屏：左屏「新建维修单」（四个批量操作按钮、项目行与材料行、自带材料 / 附加费 / 车主描述三个可添加区、底部金额与「提交」），右屏「查看维修单」，其客户信息区之下是绿色的**本次到店状态条**（接车 → 开单 → 施工 → 完工）。
**关键交互** —— ①批量指派技师 / 批量业务分类 / 批量销售人员 / 更多 → 对多行一次性赋值；②点项目行的「技师: 请选择 >」→ 指派技师；③点「添加关联材料」→ 为该项目挂材料；④材料行的「质保信息」→ 查看/录入质保（图中标签为「未质保」）；⑤右屏点「完工」→ 工单状态推进到完工，按钮随之变为「收款」；⑥「价参」查看价格参考。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。**「商品总价 ¥410.00 / 待收金额 ¥410.00」正是 `TODO(REQ-SAL-012)` 争议的字段。**
**需求关联** —— [REQ-SAL-007](#439-业务规则) 页面由 F6 提供、[REQ-SAL-024](#439-业务规则) F6 库存与价格、`TODO(REQ-SAL-012)` 技工金额可见性
> 状态条「接车 → 开单 → 施工 → 完工」与 4.3.1 声明的工单状态机一致 ✓。材料行的「未质保」标签与「质保信息」入口，与 [4.5 延保](./05-WTY-延保.md#45-延保)的质保/延保是两个不同概念，App 整合后须避免用户混淆。
新建维修单页：批量操作（指派技师 / 业务分类 / 销售人员 / 更多）；项目行（如「更换轮胎（普通胎 17 寸以上）」含工时、技师选择、添加关联材料）；材料行（如「乘用车轮胎」含数量、技师、仓库/货位、质保信息）；自带材料 / 附加费 / 车主描述；底部「商品总价 / 待收金额」+「价参 / 提交」。
查看维修单页：车辆头卡（车牌、车型、VIN、复制VIN、配置详情、标签）、商机与车险到期提醒、历史记账 / 上次服务 / 定金 / 卡 / 优惠券、专属顾问、客户标签、变速箱号 / 发动机号 / 发动机型号 / 轮胎出厂规格、服务顾问、**本次到店状态条（接车 → 开单 → 施工 → 完工）**、商品总价 / 待收金额、底部「发给车主 / 修改 / 完工」。
## 4.3.4 核销
**十、扫码核销**
消费者到店出示线上订单核销码，门店通过首页「快速核销」扫码或手工输码完成核销。
现状实证（O2O）：
![现状-O2O 核销历史](../mini-program-images/O2O/核销历史.png)
**页面内容** —— 「核销历史」列表：顶部「今天 / 本周 / 本月 / 全部」四个时间 tab（当前选中「全部」），下方是汇总「总共核销 4974 单」与核销记录列表。
**关键交互** —— ①切换四个时间 tab → 列表与汇总数随之变化；②**本页无搜索框、无渠道筛选**，只能按时间段浏览；③记录行是否可点入详情本图无法确认。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权（见附录 B）。金额字段（订单金额 / 货款收入）的可见性同 `TODO(REQ-SAL-012)`。
**需求关联** —— `TODO(REQ-SAL-010)` 核销流程、[REQ-SAL-029](#439-业务规则) 核销码按渠道路由校验、[REQ-SAL-031](#439-业务规则) 收入口径与 4.10 同源
> **本图给出了两条硬事实：**
> 1. **订单号格式至少有 4 种** —— `LP20260305135911100463032`（LP 前缀 25 位）、`202602050001000269816`（纯数字 21 位）、`202602041518`（纯数字 12 位）、`AMAP202602041121`（AMAP 前缀 = 高德）。核销码校验规则**不能写死长度与字符集**，见 [REQ-SAL-029](#439-业务规则)。
> 2. **金额口径随订单来源而变** —— 一部分记录显示「订单金额」，另一部分显示「货款收入 + 消费者补贴（待审核）」。后者与 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)的消费者补贴是同一件事，即**核销动作会触发补贴申报**。正文完全未记这条链路。
>
> 该门店累计核销 4974 单，核销是高频操作，App 侧的核销入口须做到首页一步可达。
![现状-O2O 服务单列表-核销订单弹窗](../mini-program-images/O2O/服务单列表-核销订单弹窗.png)
**页面内容** —— 在「服务单列表」上弹出的「核销订单」白色弹窗：核销码输入框 + 右侧扫码图标 + 橙色「核销」按钮，遮罩下可见服务单卡片与「核销安装」按钮。
**关键交互** —— ①在输入框手工键入核销码；②点右侧扫码图标 → 唤起相机扫码；③点「核销」提交；④点弹窗外的 ✕ → 关闭。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权 —— 核销直接影响履约与结算，权限须显式授予。
**需求关联** —— [REQ-SAL-028](#439-业务规则) 「核销安装」为合一动作、[REQ-SAL-029](#439-业务规则) 核销码校验、[REQ-SAL-027](#439-业务规则) 核销入口在服务单
> **本图回答了 `TODO(REQ-SAL-010)` 的一个关键子问题**：遮罩下的按钮名为「**核销安装**」，即现状把核销与安装合并为一个动作，核销成功后服务单直接由「待安装」变「已安装」，**不是「核销后仍需单独标记安装」**。见 [REQ-SAL-028](#439-业务规则)。
> 卡头的「未核销 / 未打款」进一步说明：服务单上同时承载核销状态与打款状态，履约与结算是耦合的，与 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)直接相关。
> 核销的详细流程仍有未尽项 —— `TODO(REQ-SAL-010)`：**重复核销与撤销核销的处理**尚无任何现状佐证。核销码格式见 [REQ-SAL-029](#439-业务规则)、核销与订单状态的关系见 [REQ-SAL-028](#439-业务规则)、错误分类见 [REQ-SAL-029](#439-业务规则)。见 [C12](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
## 4.3.5 线上订单管理
线上订单来自 O2O，是[首页待办](./02-HOM-APP首页与导航.md#423-店长首页)「单据层」五状态的详情载体。
![设计稿-订单列表](../app-design-images/订单列表.png)
**页面内容** —— App 订单列表的目标形态：订单号搜索框 + 渠道与状态两级 tab，主体为订单卡列表，每卡含渠道与状态标、可复制的订单编号、带商品图的商品行、**独立的客户卡（含拨号按钮）**与底部两个操作按钮。
**关键交互** —— ①在搜索框输入订单号检索；②切换渠道 tab（全部渠道 / 抖音 / 天猫 / 京东 / …）；③切换状态 tab 胶囊（待接单(9) / 待配送(3) / 调货中(6) / 待安装(4)），数字为该状态单量；④点订单编号右侧复制图标 → 复制单号；⑤点客户卡右侧拨号按钮 → 拨打车主电话；⑥「添加备注」→ 备注页；「确定接单」→ 接单。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。订单金额对技工的可见性同 `TODO(REQ-SAL-012)`。
**需求关联** —— `TODO(REQ-SAL-013)` 渠道清单（已由 [REQ-SAL-036](#439-业务规则) 关闭）、[REQ-SAL-030](#439-业务规则) 订单金额下发时机、[REQ-SAL-036](#439-业务规则) 两套渠道枚举
> **设计稿有两处缺陷，须在设计评审时修正：**
> 1. **渠道 tab 中「天猫」出现了两次**（全部渠道 / 抖音 / 天猫 / 京东 / **天猫**）—— 重复项。
> 2. **状态 tab 只有 4 个**（待接单 / 待配送 / 调货中 / 待安装），而 4.3.1 声明的订单状态机是六态（待接单 → 调货中 → 待安装 → 待配送 → 配送中 → 已完成），**缺「配送中」与「已完成」**。现状 O2O 的状态 tab 是完整六态 + 「全部」。
>
> 另：设计稿的客户卡带「普通客户」客户等级，与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)的会员体系关联；现状 O2O 无此字段。设计稿订单金额示例为 ¥0，与现状一致，原因见 [REQ-SAL-030](#439-业务规则)。
设计稿订单列表：订单号搜索；**渠道 tab（全部渠道 / 抖音 / 天猫 / 京东 / …）**；状态 tab（待接单(9) / 待配送(3) / 调货中(6) / 待安装(4)）；订单卡含渠道标、状态、下单时间、订单编号（可复制）、商品行（名称 / 规格 / 数量）、客户卡（姓名 / 客户等级 / 拨号按钮）、共 N 件、订单金额、操作「添加备注 / 确定接单」。
现状实证（O2O）：
![现状-O2O 订单列表-待接单](../mini-program-images/O2O/订单列表-待接单.png)
**页面内容** —— O2O「订单列表」的「待接单」页签：搜索框 + 渠道 tab（全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖…）+ 状态 tab（待接单(10) / 待配送(0) / 调货中(3) / 待安装(19) / 配…），其下是「待接单 10 单」与「筛选」，主体为订单卡列表。
**关键交互** —— ①点渠道 tab 右侧的 `^` → 展开全部渠道；②切换状态 tab；③点「筛选」→ 弹出筛选面板（见后）；④点车主行的红色电话图标 → 拨号；⑤点订单号右侧复制图标 → 复制；⑥「添加备注」→ 备注页；⑦「确定接单」→ 弹出货品状态选择（见后）。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-030](#439-业务规则) 订单金额、[REQ-SAL-032](#439-业务规则) 订单标识、[REQ-SAL-036](#439-业务规则) 渠道枚举、[REQ-SAL-026](#439-业务规则) 车主信息脱敏
> **现状卡片结构与设计稿的三处差异**：现状把「车主 + 红色电话图标」放在卡片最上方且**无客户等级**、**无商品图**；设计稿则是独立的客户卡 + 橙色拨号钮 + 商品图 + 客户等级。以设计稿为目标形态，现状缺失的商品图与客户等级须由接口补齐。
> 第一条记录的车主姓名是「123456789」，属测试数据。**订单金额为 ¥0**，原因见 [REQ-SAL-030](#439-业务规则)。
![现状-O2O 订单列表-调货中](../mini-program-images/O2O/订单列表-调货中.png)
**页面内容** —— 同一页面切到「调货中(3)」页签，卡片结构与待接单一致，差别在于状态标签为「调货中」、操作按钮变为「确定到货」。
**关键交互** —— ①点「确定到货」→ 订单由「调货中」推进到「待安装」；②其余交互同待接单页。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-030](#439-业务规则) 订单金额、[REQ-SAL-034](#439-业务规则) 商品图兜底
> **操作按钮随状态变化**：待接单 → 「确定接单」，调货中 → 「确定到货」。App 须按状态映射按钮文案与动作，不能做成一个通用的「下一步」。
![现状-O2O 订单列表-已完成](../mini-program-images/O2O/订单列表-已完成.png)
**页面内容** —— 切到「已完成(105)」页签（状态 tab 已横向滚动，可见 待安装(26) / 配送中(0) / 已完成(105) / 全部(208)），卡片结构不变但**车主姓名显示为 `***`**、操作按钮变成「查看延保」，第二张卡的卡头多出「已核销/未打款」与「抖音小店 | 发货」两段信息。
**关键交互** —— ①点「查看延保」→ 查看该订单关联的延保保单；②其余同上。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-033](#439-业务规则) 第二条延保入口、[REQ-SAL-030](#439-业务规则) 订单金额、[REQ-SAL-026](#439-业务规则) 脱敏规则、[REQ-SAL-034](#439-业务规则) 商品图兜底
> **本图有三处关键发现：**
> 1. **已完成订单带「查看延保」按钮** —— 说明**线上订单履约完成后也会办延保**，订单与保单之间已有关联。这是 4.3.7「F6 结算后跳延保」之外的**第二条延保入口**，正文完全未记，见 [REQ-SAL-033](#439-业务规则)。
> 2. **订单金额在已完成状态下才有真实值（¥908）**，而待接单 / 调货中 / 待安装一律是 ¥0 —— 金额并非「免费」，而是接单阶段平台不下发，见 [REQ-SAL-030](#439-业务规则)。
> 3. **车主姓名在已完成状态下脱敏为 `***`**，而待接单 / 调货中显示真实姓名。同一字段在不同状态下脱敏规则不同（推测与平台的号码保护期有关），App 须统一口径，见 [REQ-SAL-026](#439-业务规则)。
>
> 另：本卡的**商品图是一张樱花与日式塔的风景照**，不是轮胎 —— 属商品主数据配错图（不是缺图），见 [REQ-SAL-034](#439-业务规则)。
![现状-O2O 订单列表-筛选](../mini-program-images/O2O/订单列表-筛选.png)
**页面内容** —— 从底部升起的订单「筛选」面板，三组条件（订单标识：百亿补贴 / 达人带货 / 门店配送；下单时间：近 1/3/6 个月或自定义；是否打款：是 / 否），背景是「待配送 0 单」的空态页。
**关键交互** —— ①点胶囊选中/取消筛选条件；②「起始时间 — 终止时间」→ 打开日期选择；③「重置」清空全部条件；④「确认」应用筛选并关闭面板。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。「是否打款」属结算信息，对技工的可见性同 `TODO(REQ-SAL-012)`。
**需求关联** —— [REQ-SAL-032](#439-业务规则) 订单标识须下发并展示
> **「百亿补贴」「达人带货」正是 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)里费率不同的订单类型**（拼多多百亿补贴 2% vs 普通 1%、抖音达人带货 4% vs 普通 2%）。订单标识 → 结算费率的映射链路在此得到印证：门店在接单阶段就能据此预判到手金额，因此该标识必须作为订单字段下发并在卡片上直接展示，而不只是一个筛选条件，见 [REQ-SAL-032](#439-业务规则)。
> 「是否打款」作为筛选项，再次说明履约与结算在 O2O 侧是耦合的。
![现状-O2O 接单货品状态选择](../mini-program-images/O2O/订单列表-接单货品状态选择.png)
**页面内容** —— 点「确定接单」后从底部升起的「选择当前货品状态」面板，两个大方块选项「有货」（已选）与「可调货」，背景的渠道 tab 已横向滚动、露出后半段（抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎）。
**关键交互** —— ①二选一「有货 / 可调货」；②点「确定接单」提交 —— **选「有货」订单进入「待安装」，选「可调货」订单进入「调货中」**；③点 ✕ 取消接单。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权 —— 该选择直接决定履约路径，属经营判断。
**需求关联** —— [REQ-SAL-036](#439-业务规则) 渠道枚举
> **这是订单状态机的分叉点**，4.3.1 的状态变化「待接单 → 调货中 → 待安装」没有说明分叉条件，实际由接单时声明的货品状态决定。附录 C 第 18 行已正确记录这一点，正文须补齐。
> 本图还补全了订单渠道的后半段。合并前一张图可得订单渠道完整枚举为 **8 个**：小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎，见 [REQ-SAL-036](#439-业务规则)。
![现状-O2O 订单详情-待接单](../mini-program-images/O2O/订单详情-待接单.png)
**页面内容** —— 「订单详情」页：顶部橙色状态条「待接单」，其下是车主与订单号、「商品列表」分区与订单金额，最下是订单来源 / 下单时间 / 支付方式 / 支付时间四行属性与两个操作按钮。
**关键交互** —— ①点车主行的红色电话图标 → 拨号；②「添加备注」→ 备注页；③「确定接单」→ 弹出货品状态选择；④**订单号在详情页没有复制按钮**（列表页有）。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-030](#439-业务规则) 订单金额、[REQ-SAL-027](#439-业务规则) 订单与服务单的职责划分
> 详情页比列表页多出**订单来源、支付方式、支付时间**三个字段。值得注意的是：**订单金额显示 ¥0，却有「微信支付」与明确的支付时间** —— 消费者确实付了钱，只是金额未下发到门店侧，进一步印证 [REQ-SAL-030](#439-业务规则)。
> 本页**没有安装地址、预约到店时间、核销码**等履约信息，服务类订单所需的预约时间**本图无法确认是否存在**。
![现状-O2O 订单详情-待安装](../mini-program-images/O2O/订单详情-待安装.png)
**页面内容** —— 同一详情页在「待安装」状态，结构与待接单页完全一致（状态条插画换成沙漏），差别在于底部**只剩「添加备注」一个按钮**。
**关键交互** —— ①「添加备注」→ 备注页；②**本页没有任何核销或安装操作入口**。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-027](#439-业务规则) 订单与服务单的职责划分
> **这是回答 `TODO(REQ-SAL-014)` 的直接证据**：待安装的订单详情页没有核销按钮，核销动作只发生在**服务单列表**上（按钮「核销安装」）。即 **订单 = 商流载体**（接单 / 调货 / 发货），**服务单 = 履约载体**（核销 / 安装 / 服务收入），两者分工明确。见 [REQ-SAL-027](#439-业务规则)。
> 同时这也是一处交互缺陷：用户在详情页确认完信息后无法直接核销，必须退回列表页。App 侧应在详情页补上核销入口。
![现状-O2O 订单备注](../mini-program-images/O2O/订单备注.png)
**页面内容** —— 极简的「订单备注」页：一个多行输入框 + 右下角字数计数「0/50」+ 橙色「保存」按钮。
**关键交互** —— ①输入备注文本，上限 **50 字**；②点「保存」提交并返回。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-035](#439-业务规则) 备注改为追加式并留痕
> **本页为空态**，页面上看不到已有备注，因此**备注是覆盖式还是追加式、是否展示历史备注与操作人，均无法从本图确认**。门店多人协作时这一点很关键，见 [REQ-SAL-035](#439-业务规则)。
## 4.3.6 服务单
服务单是订单履约的施工侧载体，与订单一对一或一对多关联。
![现状-O2O 服务单列表-全部](../mini-program-images/O2O/服务单列表-全部.png)
**页面内容** —— 「服务单列表」的「全部(49)」页签：渠道 tab（全部渠道 / 美团 / 高德 / 抖音团购 / 百度 / 车点…）+ 状态 tab（待安装(4) / 已安装(45) / 全部(49)），主体是服务单卡列表，卡头为三段式「履约状态 | 核销/打款状态 | 查看」+ 右侧渠道名。
**关键交互** —— ①切换渠道 tab 与状态 tab；②点卡头的「查看」→ **本图无法确认跳转目标**（推测为核销凭证或明细）；③点订单号右侧复制图标 → 复制；④点卡片 → 服务单详情。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-027](#439-业务规则) 服务单为履约载体、[REQ-SAL-036](#439-业务规则) 服务单渠道枚举、[REQ-SAL-034](#439-业务规则) 长商品名
> **服务单的渠道枚举与订单不同** —— 服务单是 美团 / 高德 / 抖音团购 / 百度 / 车点点（+零跑，见 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)）共 **6 个平台服务渠道**；订单是 8 个商品渠道。二者是**两个不同的枚举**，不是同一份数据的不一致，见 [REQ-SAL-036](#439-业务规则)。
> 商品名「【库存紧张】狂欢钜惠｜安全出行 全车检测【德国马牌】」是带促销修饰的营销文案，不是规范商品名，两行才显示得下，见 [REQ-SAL-034](#439-业务规则)。
> 订单号 `DY20260416160239205533 7`（DY 前缀 = 抖音）又是一种新格式，佐证 [REQ-SAL-029](#439-业务规则)。
![现状-O2O 服务单列表-待安装](../mini-program-images/O2O/服务单列表-待安装.png)
**页面内容** —— 切到「待安装(4)」页签，卡头为「待安装 | 未核销/未打款」+ 渠道「高德」，卡体首行是**「联系车主 + 完整手机号 + 红色电话图标」**，其后是订单号、创建时间与商品行，底部为「添加备注 / 核销安装」两个按钮。
**关键交互** —— ①点红色电话图标 → 拨打车主电话；②点「核销安装」→ 弹出核销订单弹窗（见 4.3.4）；③「添加备注」→ 备注页。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权 —— 核销安装是技工的现场作业动作。
**需求关联** —— [REQ-SAL-028](#439-业务规则) 核销安装合一、[REQ-SAL-029](#439-业务规则) 核销码格式、[REQ-SAL-026](#439-业务规则) 车主手机号脱敏
> **服务单显示的是「联系车主 + 完整手机号」，订单列表显示的是「车主 + 姓名」** —— 同一实体两种字段口径，且服务单侧手机号完全未脱敏，见 [REQ-SAL-026](#439-业务规则)。
> 本图两条记录来自同一车主、同一时间，订单号却一个是纯数字 22 位、一个带 `AMAP` 前缀 —— 同一渠道下也存在两种单号格式（推测为平台单号与内部单号），核销码校验必须容忍这种并存，见 [REQ-SAL-029](#439-业务规则)。
> 商品名「自动化测试」为测试数据；订单金额 ¥1888 与「高德洗车 ¥100」并存，说明 O2O 服务单承载的不只是轮胎安装，还有洗车等服务项。
![现状-O2O 服务单列表-已安装](../mini-program-images/O2O/服务单列表-已安装.png)
**页面内容** —— 切到「已安装(45)」页签，**首屏内容与「全部」页签完全一致**（同为两条抖音团购的 ¥9.90 全车检测记录），因为列表按时间倒序、最新两条恰好都已安装。
**关键交互** —— 同「全部」页签，无新增交互。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-027](#439-业务规则) 服务单为履约载体
> 本图与「全部」页签除计数与选中态外无差异，**附录 C 保留两张的意义仅在于佐证页签切换**。若后续补拍，建议改拍已安装状态下有多种渠道混排的样本。
![现状-O2O 服务单列表-筛选](../mini-program-images/O2O/服务单列表-筛选.png)
**页面内容** —— 服务单的「筛选」面板，只有「下单时间」（近 1/3/6 个月 + 自定义）与「是否打款」两组条件，比订单筛选少一组「订单标识」。
**关键交互** —— ①选择时间范围；②选择是否打款；③「重置 / 确认」。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-032](#439-业务规则) 订单标识、[REQ-SAL-027](#439-业务规则) 订单与服务单的职责划分
> **服务单筛选比订单筛选少一整组「订单标识」**（百亿补贴 / 达人带货 / 门店配送）。这不是遗漏，而是因为服务类订单本就没有这些商品促销标识 —— 又一条支撑「订单与服务单是两条不同业务线」的证据，见 [REQ-SAL-027](#439-业务规则)。
![现状-O2O 服务单详情-待安装](../mini-program-images/O2O/服务单详情-待安装.png)
**页面内容** —— 「服务单详情」页（待安装）：顶部橙色状态条与沙漏插画，其下是联系车主与订单号、展示服务项的「商品列表」分区，再下是共计项数与订单金额 / 服务单来源 / 下单时间三行属性，底部只有「添加备注」。
**关键交互** —— ①点电话图标 → 拨号；②「添加备注」→ 备注页；③**本页同样没有核销入口**。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。
**需求关联** —— [REQ-SAL-027](#439-业务规则) 详情页须补核销入口
> 与订单详情页对比：服务单详情**少**了支付方式与支付时间，**多**了「服务单来源」（订单详情叫「订单来源」），量词也不同（「共计 1 项服务」vs「共计 1 件商品」）。App 统一后须固定一套字段名与量词。
> 核销入口在详情页缺失的问题，与订单详情页相同，见 [REQ-SAL-027](#439-业务规则)。
![现状-O2O 服务单详情-已安装](../mini-program-images/O2O/服务单详情-已安装.png)
**页面内容** —— 同一详情页在「已安装」状态，**页面最顶部多出一行白底条「服务收入 ¥9.11」+「查看明细 >」**，属性区的三行变为「订单金额 ¥9.90 / 服务单来源 抖音团购 / **核销时间**」。
**关键交互** —— ①点「查看明细 >」→ 服务收入的费用构成明细；②其余为只读展示。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。**「服务收入」属结算金额，对技工的可见性同 `TODO(REQ-SAL-012)`。**
**需求关联** —— [REQ-SAL-031](#439-业务规则) 服务收入口径与 4.10 同源、[REQ-SAL-028](#439-业务规则) 核销即安装
> **本图是全 PRD 中一处关键的跨模块交叉点**：订单金额 **¥9.90**、服务收入 **¥9.11**，差额 **¥0.79**，费率 **0.79 / 9.90 ≈ 7.98%**。
> [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)记录了同一笔样本，并指出该费率与任何一档已公布的渠道费率都对不上。**本图给出了它的上游来源**：这是一笔抖音团购的全车检测服务单，核销后由 O2O 直接计算出服务收入。也就是说，FIN 的收入明细与 SAL 的服务单详情**读的是同一个数**，两处必须同源，见 [REQ-SAL-031](#439-业务规则)。
> 另：已安装状态多出「核销时间」字段，且核销时间与「全部」列表中该单的创建时间（2026-04-15 11:13:49）完全一致 —— 说明这类团购服务单是**核销时才创建服务单**，而非下单时创建。
> 服务单与 F6 工单的关系仍未完全定义：同一次施工在 O2O 有服务单、在 F6 有工单，两者是否需要关联、以哪一侧为准 —— `TODO(REQ-SAL-014)`。V1.1 已明确 O2O 内部「订单 vs 服务单」的分工（见 [REQ-SAL-027](#439-业务规则)），但 **O2O 服务单 ↔ F6 工单**的主从关系仍待架构裁决。这直接影响[技工首页「当前施工队列」](./02-HOM-APP首页与导航.md#424-技工首页)的数据源。
## 4.3.7 结算与延保跳转
**十一、结算**
结算页由 F6 开发。**结算完成后，F6 需要添加一个按钮，跳转到「延保」**。
![现状-F6 添加项目材料与结算收银](../images/原型-销售-结算收银.png)
**页面内容** —— F6 三联屏：左屏「添加项目/材料」（搜索 + 扫码、多个品类页签，**「换轮胎」页签下按规格列出适配轮胎推荐**，每条含品牌型号、单价、门店库存与数量步进器），中屏「查看维修单」底部为「收款」，右屏「结算收银」为收款成功页且**页面最底挂着一条第三方广告横幅**。
**关键交互** —— ①左屏按规格筛选适配轮胎，用步进器选数量 → 「加入维保单」；②「纠错」标签 → 反馈商品主数据错误；③中屏点「收款」→ 进入结算收银；④右屏「完成收款」结束流程，「查看历史收款 >」「查看未结清单据 >」进入对应列表。
**可用角色** —— 店长 ✅；技工 ⚙️ 需授权。**结算收银涉及全部金额字段，是 `TODO(REQ-SAL-012)` 最敏感的场景。**
**需求关联** —— [REQ-SAL-007](#439-业务规则) 页面由 F6 提供、[REQ-SAL-011](#439-业务规则) 结算后跳延保、[REQ-SAL-024](#439-业务规则) F6 库存与价格、[REQ-SAL-025](#439-业务规则) H5 容器模式
> **本图有三处关键发现：**
> 1. **F6 内置马牌轮胎商品库并能按规格推荐适配轮胎，但四条商品的价格全是 ¥0.00、门店库存全是 0** —— F6 的库存与价格没有和 ROOS / O2O 打通，这是[痛点 2.3 进销存 / ERP 数据](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)的直接实证。App 整合后开单页的轮胎材料应以 App 侧库存为准，见 [REQ-SAL-024](#439-业务规则)。
> 2. **结算页底部有第三方金融产品广告横幅（网商银行「开通网商账户」）**，页面右上还有 F6 自己的首页与客服图标。这些内容会原封不动出现在马牌 App 里，属品牌与合规问题，须要求 F6 提供无广告、无自有导航的容器模式，见 [REQ-SAL-025](#439-业务规则)。
> 3. **结算成功页上没有「延保」按钮** —— 印证正文所说「F6 需要添加一个按钮跳转到延保」确实是**尚未开发**的待办项，而不是已有能力。
>
> 另：按钮文案是「加入**维保**单」，而单据本身叫「维修单」，F6 内部命名不统一；App 侧透传时以实际单据名为准。
结算收银页：收款成功状态、收款信息（订单金额 / 应收金额 / 已收金额 / 未收金额）、备注、「完成收款」、「查看历史收款 >」「查看未结清单据 >」。
**十二、延保**
由结算页跳转至延保流程，见 [4.5](./05-WTY-延保.md#45-延保)。跳转时应携带车牌、VIN、轮胎条码/DOT 等已录入信息，避免重复录入（这正是[痛点 2.6](../Continental-Retail-APP-PRD.md#26-售后延保) 的核心诉求）。
> 跳转参数契约（F6 → App → 延保后台）未定义 —— `TODO(REQ-SAL-011)`。**该契约须同时覆盖 V1.1 逐图核对发现的另外两条延保入口**：接车页底部的「延保」按钮（见 [REQ-SAL-016](#439-业务规则)）与 O2O 已完成订单的「查看延保」（见 [REQ-SAL-033](#439-业务规则)）。
## 4.3.8 角色差异
**店长**：完整销售流程权限。
**技工**：如果技工被分配此项权限，其功能与店长一致。
> 金额类字段（商品总价、实收金额、待收金额）是否对技工屏蔽，与[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控)「技工可查看门店财务数据」的诉求存在张力 —— `TODO(REQ-SAL-012)`。
>
> **V1.1 补充**：该问题的影响面比原文描述的更大。逐图核对后，金额字段出现在**至少 8 个页面**上 —— 历史工单（商品总价 / 实收金额）、维修单（商品总价 / 待收金额）、检测转单（项目工时费）、结算收银（四行金额）、订单列表与详情（订单金额）、核销历史（订单金额 / 货款收入）、服务单列表与详情（订单金额 / **服务收入**）。其中 F6 侧的页面在 Embedded H5 内运行，**App 无法逐字段裁剪**，只能整页控制入口可见性。因此 `TODO(REQ-SAL-012)` 的可行结论只有两种：要么技工完全不可进入这些 F6 页面，要么接受技工可见全部金额 —— **中间态在技术上不成立**，须在裁决时一并说明。
## 4.3.9 业务规则
**REQ-SAL-001 交易流水号** —— APP 按规则生成、业务保存时提交，保证唯一与幂等；规则待定 `TODO(REQ-SAL-001)`
**REQ-SAL-002 车牌识别** —— **拍照上传至云端 OCR 识别**（经 App 后端代理），返回车牌号与置信度；置信度偏低时以「待确认」展示、由用户核对后再提交。**需联网**；**手工输码为常驻并列入口**，不是识别失败后的降级
**REQ-SAL-003 车辆信息获取** —— 凭车牌向 F6 取车主、VIN、里程、最近到店时间；F6 无档案时进入建档
**REQ-SAL-004 历史工单** —— 来自 F6；**门店未接 F6 则整个分区不显示**
**REQ-SAL-005 延保历史** —— 来自延保后台；与历史工单并列为两个 tab
**REQ-SAL-006 销售商机** —— 仅开通 F6 的门店可见；「服务提醒」与「意向池」来自 F6
**REQ-SAL-007 检测与工单** —— 页面由 F6 提供（Embedded H5）；App 负责容器、导航栏、原生能力桥接与登录态透传
**REQ-SAL-008 检测报告发送** —— 支持车主微信 / 公众号 / 企业微信 / 短信 / 他人微信五个渠道；短信渠道需购买
**REQ-SAL-009 检测单转单** —— 异常项可转单据或转商机，二选一；单据类型五种，见 [REQ-SAL-023](#439-业务规则)
**REQ-SAL-010 扫码核销** —— 核销码格式见 [REQ-SAL-029](#439-业务规则)、与订单状态的关系见 [REQ-SAL-028](#439-业务规则)、错误分类见 [REQ-SAL-029](#439-业务规则)；**仅「重复核销与撤销核销的处理」仍待定** `TODO(REQ-SAL-010)`
**REQ-SAL-011 结算后跳延保** —— F6 结算页增加跳转按钮；参数契约待定 `TODO(REQ-SAL-011)`，且须同时覆盖 [REQ-SAL-016](#439-业务规则) 与 [REQ-SAL-033](#439-业务规则) 的另外两条入口
**REQ-SAL-012 技工金额可见性** —— 待定 `TODO(REQ-SAL-012)`；可行结论只有「完全不可见」与「完全可见」两种，理由见 [4.3.8](#438-角色差异)
**REQ-SAL-013 订单渠道维度** —— ~~渠道清单是否可配置待定~~ **V1.1 关闭**：现状证明渠道会随平台合作变化且订单侧与服务单侧是两套不同枚举，**必须后台可配置**，见 [REQ-SAL-036](#439-业务规则)
**REQ-SAL-014 服务单与工单关系** —— O2O 内部「订单 vs 服务单」的分工已明确（见 [REQ-SAL-027](#439-业务规则)）；**O2O 服务单与 F6 工单的主从关系仍待定** `TODO(REQ-SAL-014)`
> 以下 `REQ-SAL-015` ~ `REQ-SAL-037` 为 V1.1 逐图核对现状后补写。
**REQ-SAL-015 两套单号并存** —— 同一次接车同时存在 App 交易流水号（`D` 前缀）与 F6 到店单号（`DD` 前缀），二者格式与位数均不同。App 须保存映射关系；对门店展示时**以 App 交易流水号为主**，F6 单号在需要与 F6 客服对账时可查。**两者的映射存储位置与对外口径未定** —— `TODO(REQ-SAL-015)`
**REQ-SAL-016 接车页的三个并列入口** —— 接车成功后的历史记录页底部固定提供「新建工单 / 扫码核销 / 延保」三个并列入口，即**核销与延保均可从接车页直接发起**，不以 F6 结算为前置。三条路径带入的车辆信息须一致
**REQ-SAL-017 车牌「待确认」态** —— 车主车辆卡的车牌字段须承载 OCR 低置信度的「待确认」状态（角标 + 可点编辑）；**车牌处于待确认状态时不允许提交建单或开工单**，必须先由用户核对
**REQ-SAL-018 无车牌 / 无 VIN 建档** —— 沿用 F6 的允许无车牌、无 VIN 建档；但建档时须提示：无车牌车辆不能通过扫码接车，且**无法按车牌与延保保单绑定**（延保以车牌 + VIN 为键，见 [4.5 延保](./05-WTY-延保.md#45-延保)）
**REQ-SAL-019 通讯录能力不提供** —— F6 建档页的「从通讯录选联系人」在 App 容器内**不提供**（通讯录属高敏感权限，需额外合规申报，收益不足以匹配成本），该入口在 App 内隐藏，改为手工输入。JSBridge 能力清单不新增通讯录读取
**REQ-SAL-020 检测项目类型** —— F6 提供五类检测：底盘检测 / 保养速检 / 轮胎专检 / 3 万公里保养检测 / 新能源检测。App 不裁剪、全部透传，轮胎门店默认把「轮胎专检」置顶。**是否按门店经营范围过滤检测类型（如未开通新能源业务的门店隐藏新能源检测）未定** —— `TODO(REQ-SAL-020)`
**REQ-SAL-021 批量通过须留痕** —— 「批量通过」可一次把未检项标记为正常，App 侧保留该功能但必须：①记录操作人、时间与被批量通过的项数；②在生成的检测报告上区分标注「实检」与「批量通过」的项。避免未实检结论以实检名义发给车主
**REQ-SAL-022 检测报告的签名与发送前置条件** —— ①「客户签名」须留存签名图与时间戳，作为门店已履行告知义务的凭据；②五个发送渠道各自的前置条件与隐私标识（车主微信仅主订单可发 / 公众号需车主已关注 / 短信需购买 / 他人微信"其他人都可看"）须完整透传，**不得简化为一个通用「分享」按钮**
**REQ-SAL-023 转单类型五种** —— 检测异常项的转单类型为**五种**：转维保单 / 转维修单 / 转贴膜单 / 转洗车单 / 转理赔单，各与「转商机」二选一。（更正原 [REQ-SAL-009](#439-业务规则) 中「四种」的表述）
**REQ-SAL-024 F6 开单页的库存与价格** —— F6 商品库中马牌轮胎的门店库存与价格现状均为空值。App 整合后，开单页的轮胎材料**须以 App 侧库存（条码库存 / ROOS）与价格为准**；在 F6 侧取不到数时，不得显示「¥0.00 / 库存 0」误导门店，应显示「—」并提示改用 App 库存查询。**由谁提供价格与库存、以何种方式回填 F6 未定** —— `TODO(REQ-SAL-024)`
**REQ-SAL-025 Embedded H5 的容器模式** —— F6 页面在 App 容器内运行时须屏蔽两类内容：①**第三方广告**（现状结算页有网商银行推广横幅）；②**F6 自有的导航元素**（首页 / 客服图标），避免与 App 容器导航重复。实现方式为 App 侧传递容器标识（UA 或参数），F6 据此渲染精简版。**F6 是否支持该模式未定** —— `TODO(REQ-SAL-025)`
**REQ-SAL-026 车主个人信息的统一脱敏** —— 车主姓名与手机号的展示口径须全 App 统一，现状存在三种做法：F6 车辆详情完整展示手机号并可复制、O2O 服务单完整展示手机号、O2O 已完成订单把姓名脱敏为 `***`。目标口径为**列表与详情一律脱敏展示 + 提供一键拨号**，拨号不落地明文号码，禁用复制。**F6 侧能否配置、以及平台号码保护期对拨号的影响未定** —— `TODO(REQ-SAL-026)`
**REQ-SAL-027 订单与服务单的职责划分** —— **订单是商流载体**（接单 / 调货 / 发货 / 订单标识 / 支付信息），**服务单是履约载体**（核销 / 安装 / 服务收入 / 核销时间）。App 保留两个列表与两套详情，不合并。核销入口在服务单侧，且**列表页与详情页都须提供**（现状详情页缺失，用户须退回列表才能核销）
**REQ-SAL-028 核销即安装** —— 核销与安装是**同一个动作**（现状按钮名为「核销安装」），核销成功后服务单由「待安装」直接变为「已安装」并写入核销时间，不需要单独的「标记已安装」步骤。若业务需要拆分为两步，须另行提出
**REQ-SAL-029 核销码校验与错误分类** —— 核销码格式**因渠道而异**（现状已见 `LP` + 25 位、`AMAP` + 数字、`DY` + 20 位、纯数字 12/21/22 位共六种），校验**不得写死长度与字符集**，须按渠道前缀路由到对应规则。核销失败须给出可区分的错误提示，至少分五类：**格式不符 / 订单不存在 / 已核销 / 已过期 / 非本店订单**
**REQ-SAL-030 订单金额的下发时机** —— 订单金额在待接单 / 调货中 / 待安装阶段平台不下发，现状一律显示 ¥0，仅已完成订单有真实金额。App 侧在金额未下发时**须显示「—」而非「¥0」**（¥0 会被门店误读为免费单）。**金额由哪个接口、在哪个时点下发未定** —— `TODO(REQ-SAL-030)`
**REQ-SAL-031 服务收入口径同源** —— 服务单详情的「服务收入」及其「查看明细」，与 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)的收入明细**必须来自同一个接口与同一套计算口径**，两处数字不得出现差异。通道费 = 订单金额 − 服务收入，费率的取值依据见 4.10
**REQ-SAL-032 订单标识须下发并展示** —— 「百亿补贴 / 达人带货 / 门店配送」三个订单标识决定结算费率（见 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)），须作为订单字段下发，并**在订单卡上直接展示**，而不只作为筛选条件 —— 门店需要在接单时即可预判到手金额
**REQ-SAL-033 O2O 订单的延保入口** —— O2O 已完成订单卡上的「查看延保」是**第二条延保入口**：线上订单履约完成后同样会办理延保，订单与保单之间已建立关联。App 须同时支持两条入口（F6 结算后跳转、O2O 订单完成后跳转），并统一记录保单与来源单据的关联关系；参数契约并入 `TODO(REQ-SAL-011)`
**REQ-SAL-034 商品图兜底与长商品名** —— ①商品图缺失或明显错误时（现状已见轮胎商品配樱花风景照）须有品牌兜底图；②团购类商品名含促销修饰词（如「【库存紧张】狂欢钜惠｜安全出行 全车检测【德国马牌】」），列表页最多展示两行并截断，详情页展示全称
**REQ-SAL-035 订单备注改为追加式** —— 备注改为**追加式**，每条记录操作人与时间并按时间倒序展示；单条上限沿用 50 字。现状为单框覆盖式且不展示历史，门店多人协作时无法追溯是谁改的
**REQ-SAL-036 渠道枚举分两套且后台可配置** —— 渠道分为两个互不相同的枚举：**商品订单渠道 8 个**（小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎）与**服务单渠道 6 个**（美团 / 高德 / 抖音团购 / 百度 / 车点点 / 零跑）。两套均须**后台可配置**，新增渠道无需发版。设计稿中「天猫」重复出现的缺陷须修正（关闭原 `TODO(REQ-SAL-013)`）
**REQ-SAL-037 到店时提示待服务的线上订单** —— F6 到店记录页已有「小程序订单」关联区。App 整合后，接车成功时若该车存在待服务的 O2O 订单，须在接车页**直接高亮提示并可一键跳转**，不得让门店在两个列表间自行比对
## 4.3.10 验收标准
1. 门店未接 F6 时，销售模块不展示历史工单、销售商机、检测开单、施工查车、结算等 F6 分区，且不产生报错弹窗；
2. 扫码识别失败后可无损转入手工输码，已识别的部分信息不丢失；
3. F6 页面在 Embedded H5 中打开时，登录态与门店上下文自动透传，用户无需二次登录；
4. 从 F6 结算页跳转延保时，车牌与 VIN 自动带入，无需重新录入；
5. 同一交易流水号重复提交时，后端幂等处理，不产生重复单据；
6. 切换门店后，订单列表与服务单列表只显示新门店的数据；
7. 车牌 OCR 置信度低于阈值时，车牌以「待确认」态展示，且此时点击「新建工单」被拦截并提示先核对车牌（[REQ-SAL-017](#439-业务规则)）；
8. 从接车页底部的「延保」按钮进入延保建单，带入的车牌与 VIN 与从 F6 结算页进入时完全一致（[REQ-SAL-016](#439-业务规则)）；
9. 检测报告中经「批量通过」标记为正常的项，在报告上有明确区分标识，且后台可查到操作人与批量项数（[REQ-SAL-021](#439-业务规则)）；
10. 在 App 内打开 F6 结算页时，页面不出现第三方广告横幅，也不出现 F6 自有的首页 / 客服图标（[REQ-SAL-025](#439-业务规则)）；
11. 订单列表与服务单列表中车主手机号均以脱敏形式展示，点击拨号可正常接通且剪贴板中不出现完整号码（[REQ-SAL-026](#439-业务规则)）；
12. 分别输入 `LP` / `AMAP` / `DY` / 纯数字四种格式的核销码均能正确路由校验；输入已核销的码时提示「该订单已核销」而非通用失败（[REQ-SAL-029](#439-业务规则)）；
13. 核销成功后，服务单状态由「待安装」变为「已安装」并写入核销时间，无需再执行任何标记动作（[REQ-SAL-028](#439-业务规则)）；
14. 待接单订单的金额显示为「—」，订单完成后显示真实金额（[REQ-SAL-030](#439-业务规则)）；
15. 服务单详情的「服务收入」与[财务模块](./10-FIN-财务与对账.md#410-财务与对账)收入明细中同一笔单的金额完全一致（[REQ-SAL-031](#439-业务规则)）；
16. 后台新增一个订单渠道后，App 的渠道 tab 无需发版即可展示（[REQ-SAL-036](#439-业务规则)）；
17. 接车时若该车有待服务的 O2O 订单，接车页出现高亮提示并可一键跳转到该订单（[REQ-SAL-037](#439-业务规则)）。
---
## 附：本模块归拢信息（来自主文件其它章节）
### 附-1 业务数据字典（主文件附录 A.3）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 扫码结果（VIN / 车牌 / 条码二维码） | **原生 `native_scan`** | — | ⚠️ 前期材料写「Involve F6 Page」，已按 [REQ-INT-003](../Continental-Retail-APP-PRD.md#71-访问链路原则) 校正 |
| 2 | 历史工单记录结果集 / 单条工单详情 | Mini Program Backend | HTTPS | |
| 3 | 工单数据集 | Mini Program Backend | HTTPS | 保存到 O2O 后台 |
| 4 | 服务提醒记录集 / 意向池 | F6 Backend | HTTPS | 销售商机 |
| 5 | 延保历史记录集 / 单条延保详情集 | Mini Program Backend | HTTPS | |
| 6 | 到店记录页 / 新车辆完善信息 / 车辆详情 / 开单 | Embedded H5（F6） | HTTPS | |
| 7 | 施工查车（检测模板、异常结果、批量正常、报告发送）/ 查车转工单、转商机 | Embedded H5（F6） | HTTPS | 报告经 SMS 或微信发送 |
| 8 | 添加其它项目 / 结算收款 | Embedded H5（F6） | HTTPS | |
| 9 | 延保数据集 / 延保出库（总数量减 1） | Mini Program Backend | HTTPS | 结算后进入延保流程 |
**本次拆分对 A.3 的三点修订建议**（回灌主文件时一并处理）：
1. **第 2、3 条的来源存疑** —— 「历史工单」与「工单数据集」标注来源为 Mini Program Backend、备注写「保存到 O2O 后台」，但正文 4.3.2 明确写「历史记录从 **F6** 取；如果门店未接 F6 则不显示」，[REQ-SAL-004](#439-业务规则) 同。**两处矛盾**，须以正文为准改为 F6 Backend，或说明 Mini Program Backend 只是代理层。
2. **缺 O2O 订单与服务单两个数据集** —— 4.3.5 与 4.3.6 共占 15 张图，但附录 A.3 完全没有对应条目。须补：**线上订单结果集 / 订单详情**（含订单标识、渠道、支付信息，来源 O2O）、**服务单结果集 / 服务单详情**（含核销状态、打款状态、服务收入、核销时间，来源 O2O）、**核销历史结果集**（来源 O2O）。
3. **第 9 条「延保出库（总数量减 1）」的触发点须补** —— 现状有两条延保入口（F6 结算后、O2O 订单完成后，见 [REQ-SAL-033](#439-业务规则)），出库动作在哪一条上触发、是否会重复扣减，须说明。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **销售** | 接车 / 扫码识别 | ✅ | ⚙️ | |
| | 检测、开单、施工 | ✅ | ⚙️ | |
| | 扫码核销 | ✅ | ⚙️ | 流程待定 `TODO(REQ-SAL-010)` |
| | 查看金额（商品总价/实收/待收） | ✅ | ❓ | `TODO(REQ-SAL-012)` |
| | 结算收银 | ✅ | ⚙️ | |
**本次拆分建议新增的两行**（回灌主文件时一并处理）：
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **销售** | 线上订单接单 / 确定到货 | ✅ | ⚙️ | 接单时须选货品状态，影响履约路径（[REQ-SAL-027](#439-业务规则)） |
| | 服务单核销安装 | ✅ | ⚙️ | 核销即安装，不可撤销（[REQ-SAL-028](#439-业务规则)） |
另需明确「查看金额」一行的备注：由于 F6 页面在 Embedded H5 内运行，**App 无法逐字段裁剪金额**，`TODO(REQ-SAL-012)` 的可行结论只有「技工完全不可进入 F6 页面」与「技工可见全部金额」两种，详见 [4.3.8](#438-角色差异)。
### 附-3 待确认项（主文件 10.2.3）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-SAL-001 | 交易流水号生成规则（前缀/门店码/日期/序列/跨天重置） | 架构 |
| REQ-SAL-010 | ~~扫码核销详细流程~~ **收窄为：重复核销与撤销核销的处理**（格式、状态关系、错误分类已由 [REQ-SAL-028](#439-业务规则)/[REQ-SAL-029](#439-业务规则) 关闭） | 业务 |
| REQ-SAL-011 | 结算后跳延保的参数契约（F6 → App → 延保后台），**须覆盖三条入口** | 架构 |
| REQ-SAL-012 | 金额类字段对技工的可见性 | 产品 / 业务 |
| ~~REQ-SAL-013~~ | ~~订单渠道清单是否可配置~~ —— **本次拆分关闭**，结论见 [REQ-SAL-036](#439-业务规则) | — |
| REQ-SAL-014 | ~~O2O 服务单与 F6 工单的关系与主从~~ **收窄为：O2O 服务单与 F6 工单的主从**（O2O 内部订单/服务单分工已由 [REQ-SAL-027](#439-业务规则) 明确） | 架构 / 业务 |
**本次拆分新增 6 条**（回灌主文件时并入 10.2.3）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-SAL-015 | App 交易流水号与 F6 到店单号的映射存储与对外展示口径 | 架构 |
| REQ-SAL-020 | 检测项目类型是否按门店经营范围过滤 | 产品 / 业务 |
| REQ-SAL-024 | **F6 开单页的轮胎价格与库存由谁提供、如何回填**（现状 F6 侧全为空） | 架构 / 业务 |
| REQ-SAL-025 | **F6 是否支持无广告、无自有导航的容器模式** | 架构 / 对外协调 |
| REQ-SAL-026 | 车主个人信息的统一脱敏口径；F6 侧能否配置；平台号码保护期对拨号的影响 | 法务 / 架构 |
| REQ-SAL-030 | 订单金额由哪个接口、在哪个时点下发 | 架构 / 对外协调 |
合计 11 条待确认（原 6 条中关闭 1 条、收窄 2 条，新增 6 条）。
### 附-4 配图清单（主文件附录 C 4.3 节，28 张）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 原型-销售历史记录页（车主车辆卡片 + 历史工单 / 延保历史记录 + 底部三操作） | `images/原型-销售-历史记录页.png` |
| 2 | 原型-车主车辆信息卡片（带「销售商机」入口） | `images/原型-销售-车主车辆卡片.png` |
| 3 | 原型-历史工单 | `images/原型-销售-历史工单.png` |
| 4 | 原型-延保历史记录 | `images/原型-销售-延保历史记录.png` |
| 5 | 原型-到店记录 / 新车辆建档 / 车辆详情 | `images/原型-销售-到店记录与建档.png` |
| 6 | 原型-检测开单与检测项目选择（底盘检测 / 保养速检 / 轮胎专检 / 3 万公里保养检测 / 新能源检测） | `images/原型-销售-检测开单.png` |
| 7 | 原型-轮胎专检（检测项目 / 异常项拍照，正常项批量通过） | `images/原型-销售-轮胎专检.png` |
| 8 | 原型-生成检测报告并发送车主（微信 / 企业微信 / 公众号 / 短信 / 他人微信） | `images/原型-销售-检测报告发送.png` |
| 9 | 原型-检测单转工单 / 转商机 | `images/原型-销售-检测单转工单.png` |
| 10 | 原型-新建维修单与查看维修单（完工） | `images/原型-销售-维修单与完工.png` |
| 11 | 现状-O2O 核销历史 | `mini-program-images/O2O/核销历史.png` |
| 12 | 现状-O2O 核销订单弹窗 | `mini-program-images/O2O/服务单列表-核销订单弹窗.png` |
| 13 | 设计稿-订单列表（渠道 tab + 状态 tab + 接单操作） | `app-design-images/订单列表.png` |
| 14 | 现状-O2O 订单列表（待接单） | `mini-program-images/O2O/订单列表-待接单.png` |
| 15 | 现状-O2O 订单列表（调货中） | `mini-program-images/O2O/订单列表-调货中.png` |
| 16 | 现状-O2O 订单列表（已完成） | `mini-program-images/O2O/订单列表-已完成.png` |
| 17 | 现状-O2O 订单列表（筛选） | `mini-program-images/O2O/订单列表-筛选.png` |
| 18 | 现状-O2O 接单货品状态选择（接单时须声明货品状态，决定后续走调货还是直接安装） | `mini-program-images/O2O/订单列表-接单货品状态选择.png` |
| 19 | 现状-O2O 订单详情（待接单） | `mini-program-images/O2O/订单详情-待接单.png` |
| 20 | 现状-O2O 订单详情（待安装） | `mini-program-images/O2O/订单详情-待安装.png` |
| 21 | 现状-O2O 订单备注 | `mini-program-images/O2O/订单备注.png` |
| 22 | 现状-O2O 服务单列表（全部） | `mini-program-images/O2O/服务单列表-全部.png` |
| 23 | 现状-O2O 服务单列表（待安装） | `mini-program-images/O2O/服务单列表-待安装.png` |
| 24 | 现状-O2O 服务单列表（已安装） | `mini-program-images/O2O/服务单列表-已安装.png` |
| 25 | 现状-O2O 服务单列表（筛选） | `mini-program-images/O2O/服务单列表-筛选.png` |
| 26 | 现状-O2O 服务单详情（待安装） | `mini-program-images/O2O/服务单详情-待安装.png` |
| 27 | 现状-O2O 服务单详情（已安装） | `mini-program-images/O2O/服务单详情-已安装.png` |
| 28 | 原型-添加项目材料 / 查看维修单 / 结算收银 | `images/原型-销售-结算收银.png` |
**看图后对本清单的补充说明**：
- **前缀「原型-」名不副实** —— 第 1–4 张是 **App 目标形态的设计稿**（iPhone 边框、马牌橙），第 5–10、28 张是 **F6 系统的真机截图拼版**（蓝色主色、图下带中文标注）。两类图性质完全不同，建议把第 1–4 张改为「设计稿-」、第 5–10 与 28 张改为「现状-F6」。本文件正文中已按此新前缀书写。
- 第 24 张（服务单列表 已安装）**首屏内容与第 22 张（全部）完全一致**，除页签选中态与计数外无差异，信息价值重复。
- **测试与脏数据分布**：第 14 张车主姓名为「123456789」；第 23、26 张商品名为「自动化测试」；第 5、6 张门店为「测试D门店1」、建档人「F6赵炳成」。
- **商品图问题**：第 16 张的轮胎商品配的是**樱花与日式塔的风景照**（配错图，非缺图）；第 14、19、20 张无商品图。
- **两处无法确认**：第 7 张右上角的「0/200」含义不明（疑为图片上传配额）；第 22 张卡头的「查看」链接跳转目标不明。
- 建议**补拍 3 张**：撤销核销的操作路径（现状完全无佐证，卡着 `TODO(REQ-SAL-010)`）、有历史备注的订单备注页（现状为空态）、服务单详情「查看明细」展开后的费用构成（卡着 [REQ-SAL-031](#439-业务规则) 与 4.10 的口径对齐）。补拍后附录 C 的 4.3 节计数由 28 → 31，须同步更新文档头部规模声明与本文件头部信息表。
### 附-5 本次拆分新增发现
1. **延保有三条入口，正文只写了一条** —— ①接车页底部的「延保」按钮（第 1 张图）、②F6 结算后跳转（4.3.7，**尚未开发**）、③O2O 已完成订单的「查看延保」（第 16 张图）。`TODO(REQ-SAL-011)` 的参数契约必须同时覆盖三条，否则从不同入口进入延保会带入不一致的信息。见 [REQ-SAL-016](#439-业务规则)、[REQ-SAL-033](#439-业务规则)。
2. **`TODO(REQ-SAL-010)` 的四个子问题已答其三** —— 核销码格式（六种，按渠道路由）、核销与订单状态的关系（**核销即安装，现状按钮就叫「核销安装」**）、错误分类（五类）均已由截图确定；**只剩「重复核销与撤销核销」完全没有现状佐证**，须补拍或向 O2O 团队确认。见 [REQ-SAL-028](#439-业务规则)、[REQ-SAL-029](#439-业务规则)。
3. **`TODO(REQ-SAL-014)` 答了一半** —— O2O 内部「订单 = 商流 / 服务单 = 履约」的分工由三条证据确立：订单详情页无核销按钮、核销按钮只在服务单列表、服务单筛选没有「订单标识」组。**剩下的 O2O 服务单 ↔ F6 工单主从关系仍需架构裁决。** 见 [REQ-SAL-027](#439-业务规则)。
4. **`TODO(REQ-SAL-013)` 可以关闭** —— 渠道不是一套而是两套：商品订单 8 个、服务单 6 个，且设计稿只画了 3 个（还重复了「天猫」）。结论只能是**后台可配置 + 区分两个枚举**。见 [REQ-SAL-036](#439-业务规则)。
5. **`TODO(REQ-SAL-012)` 的可行解只有两个极端** —— 金额字段散布在至少 8 个页面上，其中 F6 侧页面在 Embedded H5 内运行，**App 无法逐字段裁剪**。因此「技工可见部分金额」在技术上不成立，裁决时须知悉这一约束。见 [4.3.8](#438-角色差异)。
6. **本模块与 4.10 财务的一处硬交叉** —— 服务单详情（已安装）显示 订单金额 ¥9.90 / 服务收入 ¥9.11 / 差额 ¥0.79（7.98%）。[4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)记录了同一笔样本并指出该费率与任何已公布档位都对不上。**两个模块读的是同一个数**，须同源，见 [REQ-SAL-031](#439-业务规则)。同时，服务单详情的「查看明细 >」很可能就是解开该费率之谜的入口，建议优先补拍。
7. **订单标识 → 结算费率的链路被打通** —— 订单筛选的「百亿补贴 / 达人带货 / 门店配送」，正是 4.10 中费率分档的依据（拼多多百亿补贴 2% vs 普通 1%、抖音达人带货 4% vs 普通 2%）。该标识须下发并直接展示在订单卡上，见 [REQ-SAL-032](#439-业务规则)。
8. **订单金额在接单阶段为 ¥0 是常态，不是 bug** —— 待接单 / 调货中 / 待安装一律 ¥0（且同时有「微信支付」与支付时间），只有已完成订单才有真实金额（¥908）。这一点必须写进 PRD，否则会被当作缺陷反复提。见 [REQ-SAL-030](#439-业务规则)。
9. **F6 的库存与价格是空的** —— F6 开单页内置马牌轮胎商品库并能按规格推荐，但**门店库存全为 0、价格全为 ¥0.00**。这是[痛点 2.3 进销存 / ERP 数据](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)最直接的实证，也意味着 App 整合后必须由 App 侧供数，见 [REQ-SAL-024](#439-业务规则)。
10. **F6 结算页内嵌第三方金融广告** —— 网商银行「开通网商账户」横幅。App 一旦嵌入该页，广告会出现在马牌 App 内。这是**品牌与合规问题，须在集成协议中明确**，见 [REQ-SAL-025](#439-业务规则)。
11. **车主个人信息在三处口径不一** —— F6 车辆详情完整展示手机号且可复制、O2O 服务单完整展示手机号、O2O 已完成订单把姓名脱敏为 `***`。车主是消费者而非门店员工，须统一按个人信息保护的口径处理，见 [REQ-SAL-026](#439-业务规则)。这与 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)中发现的手机号未脱敏是同一类问题，**建议在第 5 章或安全章节统一规定**。
12. **正文的两处事实性错误** —— ①转单类型是**五种**不是四种（多「转维保单」）；②检测报告发送渠道是**五个**不是四个（多「他人微信」），且每个渠道都有前置条件与隐私标识。均已就地更正，回灌时须带上。见 [REQ-SAL-023](#439-业务规则)、[REQ-SAL-022](#439-业务规则)。
13. **设计稿的三处缺陷** —— ①订单列表渠道 tab 中「天猫」出现两次；②订单状态 tab 只有 4 个，缺「配送中」与「已完成」；③延保历史记录的状态色与语义错配（正常=橙、待确认=绿、待补充=红）。回灌前应要求设计修正。
14. **「批量通过」是质量风控点** —— 轮胎专检 24 项，一次点击可把 22 项未实检项标为「正常」，而这些结论会直接发给车主。App 须保留效率但必须留痕并在报告上区分标注，见 [REQ-SAL-021](#439-业务规则)。
15. **两套单号并存** —— App 交易流水号（`D` + 17 位）与 F6 到店单号（`DD` + 14 位）格式完全不同，同一次接车挂两个号。`TODO(REQ-SAL-001)` 的流水号规则须连同二者的映射一并定义，见 [REQ-SAL-015](#439-业务规则)。
16. **F6 建档页需要通讯录权限** —— 客户姓名支持从手机通讯录选取。该能力在 App 容器内不可用且属高敏感权限，本次已决定**不提供、入口隐藏**，见 [REQ-SAL-019](#439-业务规则)。这条应同步给《App Embedded H5 容器与 JSBridge 文档》，确认 JSBridge 能力清单不新增通讯录读取。
prd/modules/04-RMD-提醒.md
+239
View File
@@ -0,0 +1,239 @@
# 4.4 提醒
> **本文件是【提醒 RMD】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.4 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | RMD |
| V1.0 章节 | 4.4 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 原型图 |
| 现状承载系统 | F6（PC 端，App 内嵌 H5） |
| 需求条数 | 7（待确认 2，完成度 71%） |
| 配图 | 3 张（原型 3，均为 F6 PC 端截图） |
模块概要
---
> **承接方式已定**：提醒能力**由 F6 承载**，App **不做原生实现**，以 [Embedded H5](../Continental-Retail-APP-PRD.md#73-f6-集成边界) 容器嵌入 F6 现有提醒页，能正常展示与操作即可。提醒规则、提醒单生成与跟进逻辑全部留在 F6 侧，App 只负责入口、换票鉴权与容器能力。方案取舍见 [4.4.5](#445-承接方式)。
本模块现状分三步：**设置提醒规则 → 生成提醒单 → 跟进提醒单**，分别对应 [4.4.2](#442-设置提醒规则)–[4.4.4](#444-跟进提醒单)。三步均由 F6 实现，以下小节记录其现状形态 —— 这既是 App 嵌入后用户实际看到的内容，也是后续若要原生化时的需求底稿。
## 4.4.1 需求描述
**业务目标** —— 基于车辆保养周期、保险到期、检测异常等规则自动生成提醒单，由服务顾问跟进转化，提升复购与到店率，支撑[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销) 的「客户分层营销」诉求
**目标角色** —— 店长；技工是否开放入口待定 `TODO(REQ-RMD-005)`
**入口** —— App 内提醒入口，具体位置随导航方案确定（见[导航收敛与角色化配置](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）；点击后进入 Embedded H5 容器加载 F6 提醒页
**前置条件** —— 门店已接入 F6；已有车辆与消费历史数据
**页面内容** —— 由 F6 页面提供，App 侧不另行定义；现状形态见 [4.4.2](#442-设置提醒规则)–[4.4.4](#444-跟进提醒单)
**主流程**：
1. 设置提醒规则
2. 车主到店消费
3. 车主完工离店
4. 生成提醒单并跟进
5. 临近服务日提醒车主（可自动发短信/微信）
6. 车主再次到店
**异常流程**：
- 门店未接入 F6 → 提醒入口不显示，见[门店能力开关](../Continental-Retail-APP-PRD.md#74-门店能力开关)
- F6 提醒页白屏 / 加载超时 / 票据过期 → 由 Embedded H5 容器统一处理，见 [7.3](../Continental-Retail-APP-PRD.md#73-f6-集成边界)
- 车主手机号缺失 → 无法发送短信/微信，仅支持电话提醒（F6 页面行为）
- 短信额度不足 → 提示「未购短信，无法分享」并提供购买入口（F6 页面行为）
**业务规则** —— 见 [4.4.6](#446-业务规则)
**权限规则** —— 页面内的规则配置与跟进权限由 F6 自行控制；App 侧只决定入口对哪些角色可见 `TODO(REQ-RMD-005)`
**访问链路** —— App → Embedded H5 容器 → App Backend 换票下发 URL → F6 提醒页（不传裸 URL，见 [7.3](../Continental-Retail-APP-PRD.md#73-f6-集成边界)）
**逻辑数据来源** —— **F6**（规则、提醒单、车辆与消费历史）
**回写目标** —— 无。跟进动作（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交）在 F6 页面内完成并由 F6 自行落库，App 不做回写
**状态变化** —— 提醒单：未处理 → 我未完成 / 我已完成 → 所有已完成（状态机由 F6 维护）
**验收标准** —— 见 [4.4.7](#447-验收标准)
## 4.4.2 设置提醒规则
![原型-提醒-设置提醒规则](../images/原型-提醒-设置提醒规则.png)
**页面内容** —— F6 PC 端「客情维护 > 商机设置 > 服务提醒」页（顶部叠加的流程条在第 ① 步），左侧为 F6 主导航，右侧「商机规则设置」区含八个规则类别 tab、保养 / 洗美子 tab 与一张规则表格，表格右侧「操作」列被截断并出现横向滚动条 —— **PC 版式在窄容器内的实际表现**。
**关键交互** —— ①切换八个规则类别 tab；②切换保养 / 洗美子 tab；③行末「修改」→ 编辑该条规则；④「状态」列开关 → 启用 / 停用该规则（图中橙色为启用、灰色为停用）；⑤「+ 添加保养提醒规则」→ 新增，上限 20 条（[REQ-RMD-002](#446-业务规则)）；⑥横向滚动查看被截断的列。
**可用角色** —— 店长 ✅（设置提醒规则属门店管理职能）；技工 ✗。页面内权限由 F6 自行控制，App 只控入口可见性 `TODO(REQ-RMD-005)`。
**需求关联** —— [REQ-RMD-002](#446-业务规则) 规则数量上限、[REQ-RMD-003](#446-业务规则) 自动提醒开关、[REQ-RMD-007](#446-业务规则)（本图的横向滚动即「PC 版式展示降级」的直接证据）
规则分八类（tab）：**服务提醒 / 车险到期提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保提醒**。最多可自定义 20 个提醒规则。
服务提醒下分「保养提醒」与「洗美提醒」，按项目设置服务周期。保养提醒规则表字段：
| 字段 | 说明 | 示例 |
| --- | --- | --- |
| 提醒类别 | 规则名称，可标「推荐」 | 小保养、空气滤清器、火花塞、变速箱油、刹车油、发动机清洗、油底壳螺丝、防冻冷却液、轮胎 |
| 包含项目 | 触发该提醒的业务项目 | 工单业务分类：保养；更换空气滤清器·保养工时费 |
| 是否根据保养手册 | 是 / 否 | |
| 提醒单生成日 | 相对下次服务日的提前量 | 下次服务日前 30 天 / 15 天 / 7 天 / 60 天 / 10 天 / 23 天 |
| 提醒单处理人 | 责任人角色 | 工单服务顾问 / 公司统一处理人 / 无处理人 |
| 是否自动提醒 | 是 / 否 | |
| 状态 | 启用 / 停用开关 | |
| 操作 | 修改 | |
保养提醒规则字段
系统预置规则基于常见保养提醒周期，建议开启后不删除；开启时若提醒包含项目有云项目，会自动下载云项目至本地。
## 4.4.3 生成提醒单
![原型-提醒-生成提醒单](../images/原型-提醒-生成提醒单.png)
**页面内容** —— F6 PC 端「服务提醒 > 我未完成」页（流程条在第 ② 步），顶部是两个按八类规则分列的计数看板（待我处理 0 / 所有未处理 8100），其下依次为八类 tab、四个状态 tab、搜索筛选行与提醒单表格（共 1939 条），**本图为测试门店数据**（客户姓名含「测试111」、手机号含 `12123456789` 等非法号码）。
**关键交互** —— ①切换八类 tab / 四个状态 tab → 过滤列表；②行首勾选框多选 → 对选中项批量执行；③「电话提醒」→ 外呼（App 内经容器 `dial` 桥接，见[验收标准](#447-验收标准)）；④「发送短信」/「发送微信」→ 手动触达；⑤「完成」→ 关单；⑥「转交」→ 移交他人；⑦「列设置」→ 自定义显示列；⑧「更多筛选」/「设为常用」→ 条件筛选与常用条件保存。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RMD-005)`。**⚠️ 与 REQ-ACC-006 一致，该项关闭前按更严格一侧实现（技工不可见）。**
**需求关联** —— [REQ-RMD-001](#446-业务规则) 承接方式、[REQ-RMD-003](#446-业务规则) 自动提醒、[REQ-RMD-006](#446-业务规则) 短信额度
页面构成：
- 顶部双看板：「待我处理的提醒单」与「所有未处理的提醒单」，各按八类规则分列计数；
- 八类 tab（服务提醒 / 保险提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保）；
- 流程条：①设置提醒规则 → ②车主到店消费 → ③车主完工离店 → ④生成提醒单并跟进 → ⑤临近服务日，提醒车主（可自动发送短信微信）→ ⑥车主再次到店；
- 状态 tab：我未完成 / 我已完成 / 所有未完成 / 所有已完成；
- 提醒单列表字段：提醒单号、客户姓名、手机号、车牌号、上次服务门店、上次服务日期、提醒类别、提醒来源、关联单号；
- 操作区：操作 / 电话提醒 / 发送短信 / 发送微信 / 完成 / 转交 / 列设置。
## 4.4.4 跟进提醒单
![原型-提醒-跟进提醒单](../images/原型-提醒-跟进提醒单.png)
**页面内容** —— **与上一张是同一个 F6 页面**（同一份表格、同一批数据），区别只是流程条高亮在第 ③ 步并另加了两个 PPT 标注框，图左下角还残留德文占位文字 `Individueller Informationsbereich`，说明本图取自 PPT 模板。
**关键交互** —— 无新增交互。跟进动作就是上一张图中列表上方的那排按钮（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交），**「跟进提醒单」不是一个独立页面**。
**可用角色** —— 同 [4.4.3](#443-生成提醒单)：店长 ✅；技工 ❓ `TODO(REQ-RMD-005)`。
**需求关联** —— [REQ-RMD-003](#446-业务规则) 自动提醒、[REQ-RMD-006](#446-业务规则) 短信额度。本图主要作跟进手段的分类佐证，不引入新页面需求。
> **本图澄清了一处结构误解**：V1.0 把 4.4.3「生成提醒单」与 4.4.4「跟进提醒单」写成两节，容易读成两个页面。实际上 F6 侧**只有一个列表页**，「生成」是系统按规则自动产出提醒单，「跟进」是人在同一个列表上执行操作。App 以 Embedded H5 嵌入时，**这两节对应同一个 URL**。
跟进手段四类：
1. **SA 发券** —— 服务顾问向车主发放优惠券；
2. **SA 电话跟进** —— 通过列表「电话提醒」直接外呼；
3. **SA 主动发短信提醒** —— 手动触发短信/微信；
4. **临近服务期系统自动发送短信提醒** —— 由规则的「是否自动提醒」开关驱动。
## 4.4.5 承接方式
现状三步全部在 F6 PC 端完成（会员营销 > 商机规则设置 / 服务提醒）。App 侧的承接范围曾有四个候选：
| 方案 | 范围 | 优点 | 代价 |
| --- | --- | --- | --- |
| A | 全不做，仍在 PC 端 | 零成本 | 门店移动化诉求落空 |
| B | 只做「跟进提醒单」（列表 + 电话/短信/微信/完成） | 覆盖高频动作，移动端体验合理 | 规则配置仍需上 PC；需 F6 开放对应 API |
| C | 三步全部移植 | 完整闭环 | 规则配置表单在手机上体验差，工作量大 |
| **D** | **Embedded H5 直接嵌 F6 现有页** | **开发量最小，不依赖 F6 开放 API** | **F6 现有页为 PC 版，手机上展示效果受限** |
提醒模块承接方案候选
**已选定方案 D。** 判定逻辑是：提醒能力本就属于 F6 的业务范畴，App 的整合目标是**消除来回切换系统**，而不是把 F6 的功能重做一遍；只要能在 App 内看到并处理提醒单，整合价值就已经兑现。方案 B 虽然移动端体验更好，但需要 F6 额外开放提醒单列表与跟进动作的 API，属外部依赖，首版不引入。
**随之接受的两个约束**：
- **展示效果降级** —— F6 现有提醒页是 PC 版式（八类 tab + 九列表格），在手机上很可能需要横向滚动。**本期接受这一降级**，不为其做专门适配。若 F6 能提供移动端页面则直接换 URL，见 `TODO(REQ-RMD-007)`。
- **App 侧无原生能力** —— 提醒单不进入 App 的待办、消息或首页看板，也不参与[弱网与离线](../Continental-Retail-APP-PRD.md#86-弱网与离线)策略；页面内的一切行为都是 F6 的行为。
## 4.4.6 业务规则
**REQ-RMD-001 承接方式** —— 已定：以 Embedded H5 嵌入 F6 现有提醒页，App 不做原生实现，见 [4.4.5](#445-承接方式)
**REQ-RMD-002 规则数量上限** —— 最多自定义 20 个提醒规则（F6 侧约束，App 不另设限制）
**REQ-RMD-003 自动提醒** —— 规则开启「是否自动提醒」后，临近服务日由 F6 自动发送短信/微信，不经 App
**REQ-RMD-004 规则冲突** —— 同一车同一项目命中多条规则时的去重由 F6 规则引擎决定，**不属 App 需求范围**（已随 REQ-RMD-001 关闭）
**REQ-RMD-005 入口可见性** —— 提醒入口对技工是否可见待定 `TODO(REQ-RMD-005)`；页面内的操作权限由 F6 控制，App 不参与
**REQ-RMD-006 短信额度** —— 短信为 F6 侧付费资源，额度不足时由 F6 页面阻断发送并提供购买入口
**REQ-RMD-007 移动端页面** —— F6 是否能提供移动端版式的提醒页 URL 待确认 `TODO(REQ-RMD-007)`；在其提供之前，按 PC 版式嵌入并接受展示降级，见 [4.4.5](#445-承接方式)
## 4.4.7 验收标准
1. 门店未接入 F6 时，提醒入口不显示；
2. 从提醒入口进入后，F6 提醒页正常加载，登录态与门店上下文自动带入，**不出现二次登录**；
3. 票据过期时容器自动换票并重载，用户无感知；
4. 页面内「电话提醒」可调起系统拨号盘（经容器的 `dial` 桥接能力，见 [7.3](../Continental-Retail-APP-PRD.md#73-f6-集成边界)）；
5. 切换门店或退出登录后，已打开的提醒页立即失效并关闭。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.4）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 提醒规则、提醒单、提醒作业 | F6 Backend | HTTPS | **F6 后台自动按规则生成提醒单**；App 以 Embedded H5 嵌入展示，不落地也不回写，见 [4.4.5](#445-承接方式) |
提醒模块数据集（摘自主文件[附录 A.4](../Continental-Retail-APP-PRD.md#a4-提醒)）
> 本模块是全文**唯一一个 App 侧零落地、零回写**的模块 —— 数据全在 F6，App 只提供容器。因此附录 A 只有一行，也不需要字段级清单。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 设置提醒规则 | ✅ | ✗ | 属门店管理职能 |
| 生成 / 跟进提醒单 | ✅ | ❓ | 页内权限由 F6 控制，App 只控入口可见性 `TODO(REQ-RMD-005)` |
提醒模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本模块权限有个特殊之处：**App 只能控制入口可见性，控制不了页面内部**。技工一旦进入 F6 提醒页，页内能做什么由 F6 的账号权限决定。因此 `TODO(REQ-RMD-005)` 的结论必须与 F6 侧的角色配置对齐，否则会出现「App 放行、F6 拦截」或反过来的错配。
### 附-3 待确认项（主文件 10.2.4）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-RMD-005 | 提醒入口对技工是否可见 | 产品 |
| REQ-RMD-007 | F6 能否提供移动端版式的提醒页 URL | 架构 / F6 |
提醒模块待确认项（摘自主文件 [10.2.4](../Continental-Retail-APP-PRD.md#1024-提醒rmd)，2 条）
### 附-4 配图清单（主文件附录 C 4.4 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 原型-设置提醒规则（F6「客情维护 > 商机设置」，八类 tab + 规则表 + 启停开关） | `../images/原型-提醒-设置提醒规则.png` |
| 2 | 原型-生成提醒单（F6 服务提醒列表，双看板 + 四状态 tab + 跟进按钮行，测试数据） | `../images/原型-提醒-生成提醒单.png` |
| 3 | 原型-跟进提醒单（**与上图同一页面**，PPT 标注四类跟进手段） | `../images/原型-提醒-跟进提醒单.png` |
提醒模块配图清单，3 张（原型 3）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
### 附-5 本次拆分新增发现
本模块**未新增编号需求**（提醒能力整体外包给 F6，App 侧不产生新需求）。逐图核看得到三点观察，供评审参考：
1. **4.4.3 与 4.4.4 是同一个 F6 页面**，不是两个。已就地写进 [4.4.4](#444-跟进提醒单) 的说明块 —— 影响的是嵌入时的 URL 数量（1 个而非 2 个），不影响需求条目。
2. **「PC 版式展示降级」已有实证**。[REQ-RMD-007](#446-业务规则) 此前只是推断，本次在设置提醒规则图上看到了表格右侧列被截断 + 横向滚动条，可作为向 F6 提移动端页面需求时的直接依据。
3. **F6 侧数据同样含测试残留**（客户姓名 `无` / `测试等级` / `测试111`，手机号 `12123456789` 等非法号码）。与[库存模块](./07-INV-库存.md#附-5-本次拆分新增发现待业务确认)发现的同类问题一致，但**本模块不为此立需求** —— 数据在 F6 侧、清洗责任也在 F6 侧，App 只作展示。若上线前 F6 未清理，属对方系统的数据质量问题，建议在集成联调时一并提出。
prd/modules/05-WTY-延保.md
+975
View File
@@ -0,0 +1,975 @@
# 4.5 延保
> **本文件是【延保 WTY】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.5 节已于 2026-08 从本文件回灌（V1.1），
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**
| 项 | 值 |
| --- | --- |
| 模块码 | WTY |
| V1.0 章节 | 4.5 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 延保小程序 43 张截图 |
| 现状承载系统 | 延保门店端小程序 + O2O |
| 需求条数 | 38（待确认 7，完成度 82%） |
| 配图 | 43 张（设计稿 2 / 现状-延保 39 / 现状-O2O 2） |
## 4.5.1 保障产品与责任边界
**业务目标**：明确延保产品的保障范围与责任边界，避免门店与消费者对「什么该走原厂质保、什么该走延保」产生争议。
**双保障并行生效**：原厂质量质保与「1 年撞击延保」互不替代、并行存在。制造缺陷应进入原厂基础质保；外力撞击导致的胎侧鼓包、爆胎等应进入撞击延保换新。
**延保协议与零售商使用条款**：支持查看保单协议，以及零售商延保使用条款、违规处理等规则，并留存同意条款时间。
![现状-延保 保单协议](../mini-program-images/Warranty/保单协议.png)
**页面内容** —— 「文件预览」容器里打开的《延保服务政策》PDF 长文，内容为保障范围与不予保障的 15 种情形。
**关键交互** —— ①上下滚动翻阅，跨页连续；②无任何可点控件，纯阅读页。
**可用角色** —— 店长 ✅、技工 ✅（只读）。
**需求关联** —— [REQ-WTY-001](#459-业务规则) 双保障并行、[REQ-WTY-036](#459-业务规则) PDF 预览与密级标识
> 三处细节值得注意：①这是**以 PDF 文件预览器打开的**，不是原生页面，App 侧需要原生 PDF 容器能力；②文档页脚带 Continental 的**密级标识「Public」**，属公司文档规范，展示时不得裁剪；③政策正文写明了两个品牌的生效起点 —— 美国将军轮胎 UC7/CC7/SC7 自 2022 年 9 月 1 日起、维京轮胎自 2020 年 11 月 1 日起，这是 [REQ-WTY-031](#459-业务规则) 品牌枚举的业务依据。
![现状-延保 德国马牌零售商延保使用条款须知](../mini-program-images/Warranty/德国马牌零售商延保使用条款须知.png)
**页面内容** —— 深色主题的两页式条款页，当前是第一页「使用条款」，顶部带本账户的同意时间戳。
**关键交互** —— ①顶部两段式进度条显示「使用条款 → 违规处理」两页，点底部橙色「下一页」翻到第二页；②灰底提示行「本账户于 2026.03.18 14:57 同意本条款」为只读留痕，不可点。
**可用角色** —— 店长 ✅、技工 ✅（只读查看）；同意动作记录操作人。
**需求关联** —— [REQ-WTY-010](#459-业务规则) 条款同意留痕、[REQ-WTY-035](#459-业务规则) 两页式与留痕字段
> **[REQ-WTY-010](#459-业务规则) 在现状已实现** —— 同意时间戳精确到分钟并展示在页面顶部。但两点须补：①条款是**两页**（使用条款 + 违规处理），须两页读完才可同意；②留痕只有时间，**没有条款版本号，也没有操作人**（现状延保侧拿不到真实员工身份，见 [REQ-WTY-015](#459-业务规则)）。见 [REQ-WTY-035](#459-业务规则)。
**目标角色** —— 店长、技工（只读查看）
**入口** —— 延保 tab 首页顶部「零售商延保使用条款须知」；保单详情页「保单协议」
**权限规则** —— 全角色可见；同意动作记录操作人
**数据来源** —— 延保后台
**回写目标** —— 条款同意时间戳回写延保后台
## 4.5.2 消费者激活与门店建单
**业务目标**：把延保建单从「独立小程序里重新录一遍」变成销售流程的自然延续，解决[痛点 2.6](../Continental-Retail-APP-PRD.md#26-售后延保)。
![设计稿-延保服务](../app-design-images/延保服务.png)
**页面内容** —— App 目标形态的延保服务首页：门店选择器 + 两个待办计数卡 + 「立刻延保」车牌录入区 + 保单管理 / 理赔处理双入口。
**关键交互** —— ①点门店名右侧 `▼` → 切换操作门店；②点右上橙色耳机 → 延保客服；③点「零售商延保使用条款须知 >」→ 条款页；④点两个计数卡 → 各自的待办列表；⑤点橙色「扫描车牌」→ 拍照识别；⑥或在车牌格子逐位输入，点绿色「+新能源」在 7 位/8 位车牌间切换；⑦车牌未填满时「下一步」为禁用态；⑧点「切换特殊车牌录入」→ 换成自由文本输入模式；⑨底部「保单管理」「理赔处理」两个入口。
**可用角色** —— 店长 ✅ 全量；技工 ❓ 建单权限待定 `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-037](#459-业务规则) 车牌录入的两种模式、[REQ-WTY-028](#459-业务规则) 待办归并
> 设计稿有两处与现状不符，须在设计评审时修正：①「切换特殊车牌录入」带**外链图标 ↗**，暗示跳出到别的页面，但现状是**同页切换输入控件**（车牌格子 ⇄ 自由输入框），见 [REQ-WTY-037](#459-业务规则)；②门店选择器与客服入口都放在延保页内，而按 [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 门店上下文应收敛到 App 全局，延保内不再单设切店入口。
设计稿延保服务页构成：门店选择器（门店名 + 门店编码）+ 客服入口 → 「零售商延保使用条款须知」→ 待绑定车辆 / 待补充装车视频 双计数卡 → **立刻延保**（扫描车牌主按钮 / 或手动录入车牌，车牌格子含「新能源」标记，「下一步」，「切换特殊车牌录入」）→ 保单管理 / 理赔处理 双入口。
**消费者延保激活链路**：消费者需通过「大陆马牌轮胎服务」公众号进入「延保换新 | 消费者端」，以手机号注册，上传驾驶证认证，添加车辆并上传行驶证，录入轮胎条码 / DOT 和购买凭证，确认激活。
> 该链路在消费者侧完成，不在本 APP 范围内，但门店端的「待绑定车辆」「待补充装车视频」待办正是由该链路的未完成状态产生。
**门店端立即延保建单**：首页提供「立即延保」入口，门店扫描或录入车牌后进入下一步，为消费者建立 / 承接延保业务。
**车牌识别与特殊车牌兼容**：支持拍摄车牌进行识别；识别失败或特殊车牌场景下可切换普通车牌手动输入。
![现状-延保 扫描车牌](../mini-program-images/Warranty/扫描车牌.png)
**页面内容** —— 「拍摄车牌」相机页，橙色取景框 + 底部快门按钮，框内是拍摄时误对准键盘的测试画面。
**关键交互** —— ①对准车牌点底部橙色快门 → 拍照并上传识别；②点中部横条「使用手动输入车牌 >」→ 转手工录入。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-037](#459-业务规则) 车牌录入的模式与文案配色
> **确认了识别方式**：有快门按钮，说明是**拍照上传识别**而非实时视频流识别，与销售模块 [REQ-SAL-002](./03-SAL-销售.md#439-业务规则) 的口径一致，两处应复用同一套 OCR 能力。
> 两处 UI 问题：①提示文案写「请将**黄色**取景框对准车牌」，而实际取景框是**橙色**；②「使用手动输入车牌」用了**红色按钮**，红色在本 App 中是危险操作色（如「作废保单」），此处语义不符。均见 [REQ-WTY-037](#459-业务规则)。
![现状-延保 特殊车牌输入](../mini-program-images/Warranty/特殊车牌输入.png)
**页面内容** —— 延保小程序首页处于「特殊车牌录入」模式时的样子，车牌格子已换成一个自由文本输入框。
**关键交互** —— ①点橙色「扫描车牌」→ 拍照识别；②在「输入车牌号码」框内自由输入，不受 7/8 位格子约束；③点橙色文字「切换普通车牌录入」→ 切回车牌格子模式；④点顶部两个计数「0 >」→ 各自的待办列表；⑤点右下绿色悬浮胶囊「延保客服」→ 客服会话；⑥底部 tab 五项：首页 / 工作台 / 中间橙色圆形图标 / 待办事项 / 我的。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-037](#459-业务规则) 两种录入模式为同页切换、[REQ-WTY-028](#459-业务规则) 待办归并
> **本图证明普通 / 特殊车牌是同页切换控件，不是两个页面** —— 普通模式用车牌格子（逐位约束），特殊模式用自由输入框（不做位数校验），两者用一个橙色文字链互切。设计稿把它画成外链跳转是错的，见 [REQ-WTY-037](#459-业务规则)。
> 另有三点：①底部 tab **中间那个橙色圆形指南针图标没有文字标签**，其功能本图无法确认；②「延保客服」用了**绿色**悬浮胶囊，在这套深色 + 橙色主题里是唯一的绿色元素，疑为跳转微信客服；③顶部条款提示条压在系统状态栏上，属遮挡。
**待办驱动的激活完善**：将未完成业务拆为「待绑定车辆」和「待补充装车视频」，并可在待办页按待处理 / 已完成状态查询。
![现状-延保 待绑定车辆](../mini-program-images/Warranty/待绑定车辆.png)
**页面内容** —— 「待绑定车辆 / 待补充装车视频」两 tab 的待办列表页，当前是待绑定车辆的空态。
**关键交互** —— ①切换顶部两个 tab；②切换「待绑定 / 已完成」两个状态胶囊；③在「搜索车牌号」框内检索。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-028](#459-业务规则) 延保内两套待办的归并
![现状-延保 待补充装车视频](../mini-program-images/Warranty/待补充装车视频.png)
**页面内容** —— 与上一张**完全相同**（同一时刻、同一 tab、同一空态），未拍到「待补充装车视频」tab 的实际内容。
**关键交互** —— 同上一张，无新增。
**可用角色** —— 同上一张。
**需求关联** —— [REQ-WTY-028](#459-业务规则) 延保内两套待办的归并
> **这两张图是同一张截图** —— 附录 C 第 6、7 行分别指向两个文件，但两个文件的内容逐像素一致（均为 16:47、5G 88%、选中「待绑定车辆」tab、空态）。**「待补充装车视频」tab 的实际内容至今没有任何佐证**，而它恰恰是首页待办里唯一被列入 App 跨系统待办的延保事项。**建议优先补拍。**
![现状-延保 待办事项](../mini-program-images/Warranty/待办事项.png)
**页面内容** —— 延保小程序底部 tab「待办事项」页的空态，页面仅有标题与「暂无待办事项」占位。
**关键交互** —— 无交互，空态页。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-028](#459-业务规则) 延保内两套待办的归并
> **延保小程序内部就已经有两套待办** —— 首页的「待绑定车辆 / 待补充装车视频」两个计数卡有自己的列表页（上两张图），而底部 tab 的「待办事项」是**另一个独立页面**。两者是否同源、为何并存，本图无法确认。这使 `TODO(REQ-WTY-002)` 的归并问题比原文描述的更复杂 —— 要归并的不是「延保待办 vs 首页待办」两套，而是三套。见 [REQ-WTY-028](#459-业务规则)。
> 延保的「待办事项」是独立 tab，与 [App 首页待办](./02-HOM-APP首页与导航.md#423-店长首页)存在归并关系：延保视频上传提醒已列入首页跨系统待办。归并后延保 tab 内是否保留独立待办页 —— `TODO(REQ-WTY-002)`。
**门店切换**：用户可在首页和工作台选择当前操作门店，保证建单、查询、返利等数据归属于正确门店。
![现状-延保 首页切换店铺](../mini-program-images/Warranty/首页切换店铺.png)
**页面内容** —— 从首页调起的「选择操作店铺」弹层，列表中只有一个门店。
**关键交互** —— ①点门店行选中并关闭弹层；②点右上「✕ 关闭」取消。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文（整合后本入口取消）
> 该测试账号只绑一个门店，因此**弹层没有搜索框，也看不出多门店时的排序与置顶规则**。[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)的切换门店页有搜索且当前门店置顶，两处口径须统一到全局门店上下文。
![现状-延保 工作台-选择店铺](../mini-program-images/Warranty/工作台-选择店铺.png)
**页面内容** —— 从工作台调起的同一个「选择操作店铺」弹层，遮罩下可见工作台的六宫格与延保数据卡。
**关键交互** —— 与上一张完全一致，是同一个组件。
**可用角色** —— 同上一张。
**需求关联** —— [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文（整合后本入口取消）
> 两张图佐证的是**同一个弹层组件挂在两个入口下**（首页 + 工作台）。正文原写「用户可在首页和工作台选择当前操作门店」，本次确认二者共用同一组件，整合后**两个入口一并取消**。
> 整合后门店切换收敛到 App 全局门店上下文（[REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则)），延保内不再单独提供切店入口。
## 4.5.3 保单与延保生命周期管理
**业务目标**：提供保单的全量查询、状态跟踪与生命周期操作，替代跨平台查保单的现状。
![设计稿-保单管理](../app-design-images/保单管理.png)
**页面内容** —— App 目标形态的保单管理页：搜索框 + 四个分组胶囊 + 保单卡列表。
**关键交互** —— ①搜索框检索；②切换「全部 / 正常保单 / 待补充保单 / 待确认保单」四个胶囊；③点卡片右下「详情 >」→ 保单详情；④卡右上角状态胶囊为只读标识。
**可用角色** —— 店长 ✅；技工 ❓ 保单查询权限待定 `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-013](#459-业务规则) 一车四胎、[REQ-WTY-014](#459-业务规则) 保障类型枚举、[REQ-WTY-011](#459-业务规则) 状态机
> **本设计稿有四处必须修正的问题：**
> 1. **`POLICY NO.` 标错了字段** —— 卡片主号 8507302611 在现状里是**轮胎条码**，真正的保单号是 15 位的「保单子代码」（如 173147928125200）。见 [REQ-WTY-012](#459-业务规则)。
> 2. **「数包保障」是「鼓包保障」的错别字** —— 现状小程序写的是「鼓包保障」。见 [REQ-WTY-014](#459-业务规则)。
> 3. **三条示例数据的保单号与车牌完全相同、状态却不同** —— 现状是「一车四胎、一胎一保单」，同一车牌下应是**四个不同的轮胎条码**。见 [REQ-WTY-013](#459-业务规则)。
> 4. **状态色与语义错配** —— 正常=橙、待确认=绿、待补充=红；按通行约定应为 正常=绿、待确认=橙、待补充=红。
>
> 另：设计稿的状态胶囊（正常/待确认/待补充）是对现状的**增强** —— 现状列表卡没有状态标识，只能靠切 tab 区分，这个改进值得保留。
**保单全量查询与搜索**：按车牌或轮胎条码搜索全部保单，并按全部、正常保单、待补充保单、待确认保单分组查看。
![现状-延保 所有保单](../mini-program-images/Warranty/所有保单.png)
**页面内容** —— 深色的「所有保单」列表，5 条记录均带「鼓包保障 / 爆胎保障」双标签，底部固定筛选条。
**关键交互** —— ①搜索框支持**车牌号或条码**两种检索；②切换「全部 / 正常保单 / 待补充保单 / 待确认保单」四个平铺 tab；③点任意行 `>` → 保单详情；④点底部「筛选 | 已筛选 >」→ 筛选弹层。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-013](#459-业务规则) 一车四胎、[REQ-WTY-009](#459-业务规则) 保单筛选
> **本图给出了保单数据结构的关键事实**：豫AQ27Z3 一个车牌下有 **4 条不同编号**的记录（8507302611 / 8506983288 / 8507302660 / 8505665909），时间都是 2024.11.13 14:16 —— 这是**一车四胎、每条胎一条记录**，而列表主号是**轮胎条码**不是保单号。见 [REQ-WTY-013](#459-业务规则)、[REQ-WTY-012](#459-业务规则)。
> 另：底部「已筛选」是橙色，说明当前列表**带着生效中的筛选条件**，不是全量；现状卡片**没有状态标识**，设计稿的状态胶囊是新增能力。
**保单状态、标签和安装留痕**：显示保单子代码、保单类型、轮胎条码、轮胎规格、保障状态、安装门店、安装时间、安装城市及安装店员。
![现状-延保 保单子代码详情](../mini-program-images/Warranty/保单子代码详情.png)
**页面内容** —— 单个保单子代码的详情页，分「保单基础信息 / 保单状态信息 / 安装信息」三段。
**关键交互** —— 无交互，纯信息展示页。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-015](#459-业务规则) 安装店员须为真实身份
> **这张图澄清了保单的字段结构**：保单子代码 `173147928125203`（15 位）才是保单主键，`8507302611` 的字段名明确写作「**轮胎条码**」，「轮胎描述」是规格串 `215/55R17 94W FR UC7 #`。列表页与设计稿把轮胎条码当保单号展示，须更正，见 [REQ-WTY-012](#459-业务规则)。
> **「安装店员」显示「微信用户」，不是真实姓名** —— 正文把安装店员列为留痕字段，但现状拿不到员工身份。这直接架空了 [REQ-WTY-005](#459-业务规则) 保单作废的审计要求（不知道是谁操作的），见 [REQ-WTY-015](#459-业务规则)。
**延保详细信息管理**：集中展示轮胎规格、保单号、投保车辆、VIN、投保人、保单有效期及保单状态；关联系统流水，如「新胎激活」「用户核保」等。
**保单作废**：门店具备作废保单的操作入口，应配合权限、状态校验和审计记录控制使用。
![现状-延保 保单详情-保单与活动信息](../mini-program-images/Warranty/保单详情-保单与活动信息.png)
**页面内容** —— 保单详情页下半部分：三条系统流水 + 空的活动信息区，底部是常驻的红色「作废保单」。
**关键交互** —— ①点分区右侧「^ 收起」折叠「保单信息 / 活动信息」；②点任一条流水的 `>` → 该笔流水详情；③点底部红色「作废保单」→ 作废流程。
**可用角色** —— 店长 🔸 受限（高风险）；技工 ✗ 无权限 `TODO(REQ-WTY-005)`。
**需求关联** —— [REQ-WTY-016](#459-业务规则) 作废的状态校验与二次确认、[REQ-WTY-017](#459-业务规则) 流水排序与事件枚举
> **两处必须修正的问题：**
> 1. **该保单状态已是「延保已过有效期」，「作废保单」按钮仍然可点** —— 现状没有任何状态校验，也没看到二次确认。正文 [REQ-WTY-005](#459-业务规则) 要求「权限 + 状态校验 + 审计记录」，现状三样都缺。见 [REQ-WTY-016](#459-业务规则)。
> 2. **三条流水的排序无规律** —— 依次是 14:16 爆胎保障 / 14:21 用户核保 / 14:16 新胎激活，既非正序也非倒序。按业务发生顺序应为 新胎激活 → 爆胎保障 → 用户核保。见 [REQ-WTY-017](#459-业务规则)。
>
> 另：「用户核保」那条没有门店信息（因为是消费者侧动作），说明流水混合了门店端与消费者端两类事件。
![现状-延保 保单详情-延保信息](../mini-program-images/Warranty/保单详情-延保信息.png)
**页面内容** —— 保单详情页上半部分：橙色轮胎卡 + 「延保信息」字段区，底部同样常驻红色「作废保单」。
**关键交互** —— ①三处「复制」按钮（轮胎条码 / 保单号 / 投保车辆车牌）；②点「保单协议 >」→ PDF 预览；③点「^ 收起」折叠分区。
**可用角色** —— 店长 ✅ 查看 / 🔸 作废；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-011](#459-业务规则) 状态机补「已过有效期」、[REQ-WTY-012](#459-业务规则) 字段命名、[REQ-WTY-015](#459-业务规则) 投保人身份
> **本图暴露了保单状态机的缺口**：保单有效期 2025.11.14、保单状态「**延保已过有效期**」—— 而正文 4.5.8 声明的状态机是「待补充 → 待确认 → 正常 → 已作废」，**根本没有这一态**。见 [REQ-WTY-011](#459-业务规则)。
> 另两点：①**保单号 `173147928125200` 与上一张图的保单子代码 `173147928125203` 只差末位** —— 同一条轮胎下有多个子代码，分别对应「鼓包保障」与「爆胎保障」两种保障，印证 [REQ-WTY-013](#459-业务规则) 的三层结构；②**投保人显示「微信用户」**，与安装店员同样是兜底值，见 [REQ-WTY-015](#459-业务规则)。
> 保单作废是不可逆的高风险操作。作废权限归属（是否限店长）、是否需要二次确认与作废原因、是否需要后台审批 —— `TODO(REQ-WTY-005)`。V1.1 已明确其中的状态校验与原因留痕要求，见 [REQ-WTY-016](#459-业务规则)。
**保单筛选**：支持按激活起止日期、轮胎品牌筛选保单；品牌可选全部、马牌轮胎、维京轮胎。
![现状-延保 保单筛选](../mini-program-images/Warranty/保单筛选.png)
**页面内容** —— 保单筛选弹层，上方压着一整块黄色的「消费者未认证」提醒卡。
**关键交互** —— ①点激活开始 / 结束日期 `>` → 日期滚轮；②点「选择品牌 >」→ 品牌滚轮；③「清除条件」（红色描边）重置，「确认筛选条件」（橙色）应用；④「✕ 关闭」取消。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-009](#459-业务规则) 保单筛选、[REQ-WTY-008](#459-业务规则) 消费者未认证兼容
> 黄色提醒卡是正文「消费者认证状态兼容」的原文出处，并补充了两个正文没写的细节：**新老系统切换点是 2020 年 8 月 24 日 7 点**，且消费者找回保单的方式是「在新系统扫描**两证**」（驾驶证 + 行驶证）。
> 注意 **筛选的激活开始日期默认就是 2020-08-24** —— 即默认筛选已排除老系统保单，这与提醒卡的说明是同一件事的两面。
> 一处 UI 问题：「清除条件」用了红色描边，与「作废保单」同色，但两者风险等级完全不同。
![现状-延保 保单筛选日期](../mini-program-images/Warranty/保单筛选日期.png)
**页面内容** —— 同一筛选弹层下方升起的微信原生日期滚轮（年 / 月 / 日三列）。
**关键交互** —— ①三列滚轮各自滑动选值；②「取消」放弃，绿色「确定」回填到筛选项。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-038](#459-业务规则) 统一选择器
> **白底 + 绿色确定按钮的微信原生 picker，压在深色页面上，视觉断裂明显。** 这是小程序无法改写原生组件主题的典型代价，本模块共 4 张截图出现同一问题（日期 ×2、品牌 ×2）。App 自研后可统一，见 [REQ-WTY-038](#459-业务规则)。
![现状-延保 保单筛选品牌](../mini-program-images/Warranty/保单筛选品牌.png)
**页面内容** —— 同一筛选弹层的品牌滚轮，三项：全部 / 马牌轮胎（选中）/ 维京轮胎。
**关键交互** —— ①滚动选择品牌；②「取消 / 确定」。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-009](#459-业务规则) 保单筛选、[REQ-WTY-031](#459-业务规则) 品牌枚举统一
> 品牌三项与 [REQ-WTY-009](#459-业务规则) 一致 ✓。但本模块内品牌枚举出现了**三种不同写法**：此处 3 项（全部/马牌轮胎/维京轮胎）、工作台指标用「马 / 维」单字缩写、返利中心筛选**只有 2 项且没有「全部」**。见 [REQ-WTY-031](#459-业务规则)。
**消费者认证状态兼容**：历史保单可能显示「消费者未认证」，页面提示该状态不影响延保返利及管理端查询；消费者后续在新系统扫码可找回保单。
**销售流程内查看延保**：O2O 侧亦提供「查看延保」入口，与销售流程中的[延保历史记录](./03-SAL-销售.md#432-接车与车辆识别)同源。
![现状-O2O 查看延保](../mini-program-images/O2O/查看延保.png)
**页面内容** —— O2O 侧的「查看延保」页（浅色），顶部是订单与延保的比对汇总，下方按轮胎逐条列出延保状态。
**关键交互** —— ①无操作按钮，纯查询页；②粉色顶条为风险提示，橙色行为数据审核状态提示。
**可用角色** —— 店长 ✅；技工 ⚙️ 需被授权（沿用销售模块的订单权限）。
**需求关联** —— [REQ-WTY-018](#459-业务规则) 两段式生效、[REQ-WTY-019](#459-业务规则) 状态收敛、[REQ-SAL-033](./03-SAL-销售.md#439-业务规则) O2O 侧延保入口
> **本图是全模块信息量最大的一张，暴露了三处状态自相矛盾：**
> 1. 每张卡的标题写「**暂无延保信息**」，但卡内又同时显示「**✅ 激活成功**」和「**🔄 用户未确认**」——三个状态互相打架。
> 2. 顶部汇总写「订单轮胎数：4，**延保成功轮胎数：0**」，而下方 4 条全部显示「激活成功」——**计数与明细对不上**。
> 3. 还叠加了一条「订单数据审核中，请稍后查询」。
>
> 但矛盾之下藏着一条**正文完全没记录的核心业务规则**：「激活成功」与「用户未确认」并存，说明**延保生效是两段式的 —— 门店激活之后还需消费者确认**，只有两者都完成才计入「延保成功」。这解释了为什么 4 条激活成功却统计为 0。见 [REQ-WTY-018](#459-业务规则)、[REQ-WTY-019](#459-业务规则)。
>
> 另：第 3 条轮胎规格 255/45R19 与前两条 235/55R20 不同，属前后轮不同规格的正常情况；门店名「智慧园杀虫轮胎店」是脏数据。
## 4.5.4 预约与理赔运营
**业务目标**：把预约车检与理赔受理的跟进从多平台查询收敛到门店端一处。
**预约车检管理**：按车牌搜索预约，按「预约车检、已受理、已上报」跟踪预约处理状态。
![现状-延保 全部预约-预约信息1](../mini-program-images/Warranty/全部预约-预约信息1.png)
**页面内容** —— 「预约信息」列表的「预约车检」页签，三条预约记录。
**关键交互** —— ①切换顶部「预约信息 / 提交的理赔信息」两个 tab；②切换「预约车检 / 已受理 / 已上报」三个状态胶囊；③搜索框按车牌号检索；④点任一行 `>` → 预约详情。
**可用角色** —— 店长 ✅；技工 ❓ 理赔受理权限待定 `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛、[REQ-WTY-022](#459-业务规则) 三类案件状态机、[REQ-WTY-023](#459-业务规则) CATI 归属
> **每条预约都带一个「CATI预约：<日期>」字段** —— 这是回答 `TODO(REQ-WTY-006)` 的关键证据：**预约车检本质就是预约 CATI 检测**，预约、理赔、CATI 是同一条业务链上的三个环节，不是三套独立业务。见 [REQ-WTY-023](#459-业务规则)。
> 另：预约序列号统一为 `TI` 前缀 + 7 位数字（TI0000657）；申请时间与 CATI 预约日期可以是同一天，也可相隔数日。
![现状-延保 全部预约-预约信息2](../mini-program-images/Warranty/全部预约-预约信息2.png)
**页面内容** —— 同一列表切到「已受理」页签，为空。
**关键交互** —— 同上一张，无新增。
**可用角色** —— 同上一张。
**需求关联** —— [REQ-WTY-022](#459-业务规则) 三类案件状态机、[REQ-WTY-030](#459-业务规则) 空态统一
> 「已受理」为空，因此**已受理状态下的卡片长什么样、比预约车检多哪些字段，本图无法确认**。
> 另：本模块的空态至少有三种写法 —— 待办列表用插画 +「暂无数据」、本页用纯文字「没有更多了」、理赔管理页用虚线框 +「暂无预约记录」。见 [REQ-WTY-030](#459-业务规则)。
**预约详情与订单凭证**：记录车辆同步问题、申请时间、申请人、脱敏手机号、预约序列号、预约检测时间、订单编号及订单 / 确认图片。
![现状-延保 全部预约-预约信息详情](../mini-program-images/Warranty/全部预约-预约信息详情.png)
**页面内容** —— 预约详情页，分「基础信息 / 预约时间 / 订单信息」三段。
**关键交互** —— 无交互，纯信息展示页。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-025](#459-业务规则) 脱敏格式统一
> 三处发现：
> 1. **手机号脱敏为 `*******3963`（7 星 + 后四位）**，而 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)用的是 `138****7616`（前三 + 四星 + 后四）。**全 App 脱敏格式不统一**，且此处的申请人姓名「王磊」是消费者姓名、完全未脱敏。见 [REQ-WTY-025](#459-业务规则)。
> 2. **字段名「车主同步问题」，值是「抖动」** —— 从值可判断这是消费者反馈的故障现象，字段名疑为「反馈问题」之误。
> 3. **「订单图片」「订单确认图片」两栏都是空的** —— 正文把它们列为记录项，但无图可看，**其展示形式（缩略图 / 点击放大 / 几张）本图无法确认**。
**延保理赔受理**：支持扫描消费者延保理赔码进入处理，并支持按车牌号或条码搜索，分别查看进行中和已完成案件。
![现状-延保 理赔-延保理赔](../mini-program-images/Warranty/理赔-延保理赔.png)
**页面内容** —— 「理赔管理」页的「延保理赔」tab，顶部是「临近预约」提醒卡，下方是案件列表（空）。
**关键交互** —— ①点提醒卡底部橙色「全部预约」→ 预约列表页；②切换「延保理赔 / 售后鉴定 / CATI理赔」三个 tab；③搜索框支持车牌号或条码；④切换「正在进行 / 已完成」两个状态胶囊。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-021](#459-业务规则) 临近预约并入待办、[REQ-WTY-020](#459-业务规则) 入口收敛、[REQ-WTY-022](#459-业务规则) 状态机
> **顶部的「临近预约（未来3天内的预约）」是一个正文完全没提的主动提醒机制。** 它与 [4.4 提醒](./04-RMD-提醒.md#44-提醒)、[App 首页待办](./02-HOM-APP首页与导航.md#423-店长首页)是同一类东西 —— 门店需要在预约日前被提醒备料备人。整合后应并入首页跨系统待办，见 [REQ-WTY-021](#459-业务规则)。
> 另：「全部预约」的入口挂在这张卡的底部，即**预约列表是理赔管理的下级页面**，而不是平级功能。
![现状-延保 理赔处理](../mini-program-images/Warranty/理赔处理.png)
**页面内容** —— 极简的「理赔处理」页，只有「延保理赔」扫码卡与「售后鉴定 >」两个入口。
**关键交互** —— ①点橙色「扫描消费者的延保理赔码」→ 相机扫码；②点「售后鉴定 >」→ 售后鉴定页。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛
> **理赔码由消费者出示、门店扫** —— 与销售模块的核销码是同一种交互模型。
> 「理赔处理」页与「理赔管理」页是**两个不同的页面**（前者是发起入口，后者是案件跟踪），但命名极为接近，门店容易混淆。页面下方还有一块几乎不可见的深色文字，**本图无法确认其内容**（疑为扫码失败时的手动输入提示）。
**预约码手动录入**：当扫码不可用时，可人工输入预约码进行匹配和受理。
![现状-延保 手动输入预约码](../mini-program-images/Warranty/手动输入预约码.png)
**页面内容** —— 「输入预约码」弹层，单输入框 + 橙色「确认」。
**关键交互** —— ①键入预约码；②点「确认」提交匹配；③「✕ 关闭」取消。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛
> 两点：①**该弹层是从「售后鉴定」页调起的**（遮罩下可见售后鉴定页），不是从理赔处理页；②输入框**没有格式提示**，而预约序列号现状为 `TI` + 7 位数字，应在占位文案里给出样例，并做前缀校验。
**提交理赔信息跟踪**：理赔信息按正在进行、已完成分组展示，便于门店持续跟进处理结果。
![现状-延保 全部预约-提交的理赔信息](../mini-program-images/Warranty/全部预约-提交的理赔信息.png)
**页面内容** —— 「预约信息 / 提交的理赔信息」两 tab 中的第二个，为空。
**关键交互** —— ①切换两个顶部 tab；②切换「正在进行 / 已完成」；③搜索框按车牌号检索。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-020](#459-业务规则) 入口收敛
> **本页与「理赔管理 > 延保理赔」tab 的结构完全相同**（都是 搜索 + 正在进行/已完成 + 列表），两处是否为同一份数据本图无法确认。这是入口冗余最直接的证据 —— 同一批理赔案件至少有两个查看路径，见 [REQ-WTY-020](#459-业务规则)。
**CATI 理赔分流**：理赔管理中独立提供 CATI 理赔入口，与延保理赔和售后鉴定并列管理。
![现状-延保 理赔-CATI理赔](../mini-program-images/Warranty/理赔-CATI理赔.png)
**页面内容** —— 「理赔管理」页切到「CATI理赔」tab，结构与「延保理赔」tab 完全一致。
**关键交互** —— 同「延保理赔」tab，无新增。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-022](#459-业务规则) 状态机、[REQ-WTY-023](#459-业务规则) CATI 归属
> 三个 tab 共用同一套页面结构，只是数据源不同。但状态机不同：延保理赔与 CATI理赔是**两态**（正在进行 / 已完成），售后鉴定是**三态**（多一个「待上传」），见 [REQ-WTY-022](#459-业务规则)。
![现状-O2O 认证轮胎技术检测中心CATI](../mini-program-images/O2O/认证轮胎技术检测中心CATI.png)
**页面内容** —— O2O 侧的 CATI 页，是一个**门店资质的开通状态页**，底部按钮为「关闭服务」。
**关键交互** —— ①滚动阅读 CATI 说明文字；②点底部橙色「关闭服务」→ 关闭本门店的 CATI 资质。
**可用角色** —— 店长 ✅（属门店资质管理）；技工 ✗。
**需求关联** —— [REQ-WTY-023](#459-业务规则) CATI 的两个面（关闭 `TODO(REQ-WTY-006)`）、[REQ-WTY-024](#459-业务规则) 文案脏数据
> **本图回答了 `TODO(REQ-WTY-006)`。** 底部按钮是「**关闭服务**」，说明 O2O 侧的 CATI 是**门店资质的开通 / 关闭开关**，而延保侧的 CATI 是**理赔案件的跟踪列表** —— 两者不是重复功能，而是同一项资质的两个面：**资质开关归 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)，案件跟踪归本模块**。见 [REQ-WTY-023](#459-业务规则)。
> 另两处必须处理：①**说明文案是脏数据** —— 同一段介绍重复了 4 遍，每遍后面还跟着一行测试串「xxx特热爱1111…」，上线前须由业务重新提供；②「关闭服务」会使门店失去 CATI 资质，属高风险操作，现状**没有二次确认**。见 [REQ-WTY-024](#459-业务规则)。
> CATI 入口同时存在于延保小程序与 O2O 接单宝 —— ~~两处是否为同一业务、整合后归属哪个模块~~ **V1.1 关闭**：两处不是同一业务，结论见 [REQ-WTY-023](#459-业务规则)。
## 4.5.5 售后鉴定与证据采集
**业务目标**：为轮胎故障提供标准化的鉴定资料采集流程，保证证据链完整可追溯。
**售后鉴定受理入口**：支持扫描消费者理赔码 / 预约码、手动输入预约码，以及进入无用户信息鉴定通道。
![现状-延保 售后鉴定](../mini-program-images/Warranty/售后鉴定.png)
**页面内容** —— 「售后鉴定」入口页：一个扫码主按钮 + 两个次级入口，下方是两条说明文字。
**关键交互** —— ①点橙色「扫描消费者的理赔码/预约码」→ 相机扫码（**一个入口同时接受两种码**）；②点「手动输入预约码 >」→ 输入弹层；③点「无用户信息鉴定 >」→ 无用户通道表单。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-007](#459-业务规则) 无用户信息鉴定、[REQ-WTY-020](#459-业务规则) 入口收敛
> 页内说明文字是 [REQ-WTY-007](#459-业务规则) 的原文出处 ✓：「该模式未关联消费者的延保保单，因此，无法进行延保鉴定理赔」。
> 但说明第 1 条讲的是「CATI理赔」，而页面标题是「售后鉴定」—— **CATI 理赔与售后鉴定在这个入口下是混在一起的**，与「理赔管理」页把二者拆成两个 tab 的做法不一致。这是 [REQ-WTY-020](#459-业务规则) 要收敛的又一处。
> 另：主按钮同时接受「理赔码 / 预约码」两种码，App 侧须能自动判别码型并路由。
**售后鉴定状态跟踪**：可按「待上传、正在进行、已完成」管理鉴定单，且支持按车牌或条码查询。
![现状-延保 理赔-售后鉴定](../mini-program-images/Warranty/理赔-售后鉴定.png)
**页面内容** —— 「理赔管理」页的「售后鉴定」tab，状态胶囊比另两个 tab 多一个「待上传」。
**关键交互** —— ①切换「待上传 / 正在进行 / 已完成」三个状态胶囊；②其余同「延保理赔」tab。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-022](#459-业务规则) 三类案件状态机各不相同
> 正文 4.5.5 写的「待上传、正在进行、已完成」**只适用于售后鉴定**，延保理赔与 CATI理赔 都是两态。App 侧不应强行统一，见 [REQ-WTY-022](#459-业务规则)。「待上传」这一态的存在也说明鉴定单可以先建单、后补证据，与 [8.6 弱网与离线](../Continental-Retail-APP-PRD.md#86-弱网与离线)的本地暂存策略直接相关。
**无用户信息鉴定**：适用于未关联消费者延保保单的轮胎故障鉴定，**仅做故障鉴定，不可走延保理赔**。
**标准化鉴定资料收集**：采集车辆品牌 / 型号、轮胎故障、生产日期、完整 DOT、轮位、轮胎品牌，以及 DOT 照片、胎面照片、故障部位内外部照片；补充视频为可选项。
![现状-延保 无用户信息鉴定通道1](../mini-program-images/Warranty/无用户信息鉴定通道1.png)
**页面内容** —— 「无用户通道」表单上半部分，分车辆信息 / 轮胎故障信息 / 轮胎基础信息 / 轮胎照片信息四段，字段均为必填。
**关键交互** —— ①带 `>` 的字段点开下拉选择（车辆品牌 / 轮胎故障信息 / 轮位 / 轮胎品牌）；②车辆型号、生产日期、DOT 编码为文本输入；③点「ⓘ 示例：」旁的缩略图 → 查看拍照示范；④点上传区 → 拍照或选图；⑤底部「确认保存」提交。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)` —— 鉴定资料采集是现场作业，实际使用者以技工为主。
**需求关联** —— [REQ-WTY-007](#459-业务规则) 无用户信息鉴定、[REQ-WTY-026](#459-业务规则) 必填与张数、[REQ-WTY-027](#459-业务规则) 必填标识规范
> 两点：①**「生产日期（4 位）」与「DOT 编码（完整）」是两个独立字段**，前者是 DOT 尾部的周 + 年，正文写「生产日期、完整 DOT」是对的但未说明二者关系；②**必填标识的表达方式有问题** —— 所有字段都带 `*`，但下拉选择类的占位文字是**红色**、文本输入类是**灰色**，用颜色区分的是控件类型而非必填性，门店容易误读为「红的才必填」。见 [REQ-WTY-027](#459-业务规则)。
> 页面标题是「无用户通道」，比入口处的「无用户信息鉴定」短，两处命名应统一。
![现状-延保 无用户信息鉴定通道2](../mini-program-images/Warranty/无用户信息鉴定通道2.png)
**页面内容** —— 同一表单下半部分的四个上传区，每区各带一张拍照示范缩略图。
**关键交互** —— ①点 `+` 方格 → 拍照或从相册选择；②每类照片有各自的张数上限；③「补充视频」为唯一选填项；④底部「确认保存」提交。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-003)`。
**需求关联** —— [REQ-WTY-026](#459-业务规则) 必填项与张数上限
> **四类照片的张数上限各不相同**：DOT 照片 ≤1 张、胎面照片 ≤1 张、故障部位内外部照片 ≤3 张，胎侧整体照片的上限**被顶部返回胶囊遮挡，本图无法确认**。每类都配了拍照示范缩略图，这个设计降低了门店拍错率，App 侧应保留。见 [REQ-WTY-026](#459-业务规则)。
> 顶部的小程序返回胶囊常驻并遮挡页面内容，是小程序容器的固有问题，App 自研后可消除。
> 照片与视频为必填证据，涉及弱网环境下的大文件上传。断点续传、失败重试、本地暂存策略见 [8.6](../Continental-Retail-APP-PRD.md#86-弱网与离线)。
## 4.5.6 工作台、返利与经营数据
**业务目标**：为门店提供延保业务的聚合视图与返利可见性。
**工作台快捷入口**：聚合保单、理赔、返利、教程、店员、数据等核心业务模块，并展示当前门店延保数据和返利简报（见 [2.7.4](../Continental-Retail-APP-PRD.md#274-延保门店端小程序)）。
**经营数据时间粒度切换**：工作台支持按月、年查看延保数据，并可切换品牌口径。
![现状-延保 工作台-筛选品牌](../mini-program-images/Warranty/工作台-筛选品牌.png)
**页面内容** —— 工作台页 + 品牌选择滚轮，页内可见六宫格入口与「延保数据」卡的月粒度视图。
**关键交互** —— ①六宫格入口分别进入 保单 / 理赔 / 返利 / 教程 / 店员 / 数据；②「月 | 年」切换时间粒度；③滚轮选品牌后点绿色「确定」应用。
**可用角色** —— 店长 ✅；技工 ❓ 返利与数据可见性待定 `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-004](#459-业务规则) 返利可见性、[REQ-WTY-031](#459-业务规则) 品牌枚举
> 六宫格确认为 **保单 / 理赔 / 返利 / 教程 / 店员 / 数据**，与正文完全一致 ✓。
> 「延保数据」卡已经按品牌拆成「马牌延保数量 / 维京延保数量」两列，上面又有一个品牌筛选滚轮 —— **筛选与拆列功能重复**。另，两个指标下方各有一行「筛选结果」标签但没有对应数值，**本图无法确认**该行是被滚轮遮住还是本就为空。
![现状-延保 工作台-年](../mini-program-images/Warranty/工作台-年.png)
**页面内容** —— 工作台切到「年」粒度的完整视图，含「延保数据」与「店铺返利简报」两张卡。
**关键交互** —— ①「月 | 年」切换 → 日期区间随之变化；②点「查看返利明细」类入口进入下级页；③点底部「筛选品牌 | 全部 >」→ 返利简报的独立品牌筛选。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-004](#459-业务规则) 返利可见性、[REQ-WTY-029](#459-业务规则) 数据口径、[REQ-WTY-031](#459-业务规则) 品牌枚举
> 三点口径须写进 PRD：①**「月 / 年」切的都是「至今」区间** —— 月 = 当月 1 日至今（2026-04-01 ~ 04-21），年 = 1 月 1 日至今（2026-01-01 ~ 04-21），**不是完整自然周期**；②**返利简报的「本月 / 本年」两个指标不随上面的月/年切换变化**，是两套独立时间口径；③返利简报有**自己独立的品牌筛选**（底部橙色行），与延保数据卡的品牌筛选互不影响 —— 同一页面两个品牌筛选器，见 [REQ-WTY-031](#459-业务规则)。
> 免责声明「*享受延保奖励轮胎条数以最终实际发放为准」须保留，这是返利数字与实际到账可能不符的法律兜底。
**数据分析**：提供近 7 天、近 30 天的延保生效保单和理赔数量趋势；同时展示用户性别与年龄分布，用于门店经营分析。
![现状-延保 数据分析1](../mini-program-images/Warranty/数据分析1.png)
**页面内容** —— 「数据分析」页上半部分：时间范围胶囊 + 延保生效保单与理赔数量两张折线图（数据全为 0）。
**关键交互** —— ①切换「近7天 / 近30天」两个胶囊；②点折线上的数据点 → 弹出 tooltip 显示当日数值。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-029](#459-业务规则) 数据口径「截止到今日0点」
> **每张图表卡底部都标注「截止到 今日0点」，即数据是 T+1、不含当天。** 这是一条必须写进 PRD 的口径声明 —— 门店当天做的单子当天看不到，容易被当作 bug 反复提。与 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)的实时性口径须一并裁决，见 [REQ-WTY-029](#459-业务规则)。
> 本图数据全为 0（折线呈水平直线），是空数据门店的样本。
![现状-延保 数据分析2](../mini-program-images/Warranty/数据分析2.png)
**页面内容** —— 「数据分析」页下半部分：用户性别信息与年龄分布信息两张图。
**关键交互** —— ①滚动查看；②图表本身在有数据时应支持点选查看数值。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-029](#459-业务规则) 数据口径、[REQ-WTY-030](#459-业务规则) 空数据兜底渲染
> **两处图表渲染缺陷**：①「用户性别信息」**只剩三条图例（男性 / 女性 / 未知），图形本体完全没渲染**；②「年龄分布信息」在数据全为 0 的情况下，六根柱子**仍然等高显示**且无数值标注 —— 会被误读为「各年龄段均匀分布」。见 [REQ-WTY-030](#459-业务规则)。
> 另：年龄分六档（17岁以下 / 18-24 / 25-29 / 30-39 / 40-49 / 50岁以上），须与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)的会员画像口径对齐；用户画像属消费者人口统计数据的聚合展示，其合规口径应在安全章节统一规定。
**返利中心**：展示品牌编码、经销商编码、本年返利总额、本月及本年延保轮胎奖励胎数，支持按品牌筛选。
![现状-延保 返利中心](../mini-program-images/Warranty/返利中心.png)
**页面内容** —— 「返利中心」页，一张指标卡 + 一行品牌筛选，卡内所有指标位均为空白。
**关键交互** —— ①点橙色「查看返利明细 >」→ 返利详情页；②点「筛选返利品牌 | 马牌轮胎 >」→ 品牌滚轮。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-004](#459-业务规则) 返利可见性、[REQ-WTY-030](#459-业务规则) 空数据兜底渲染
> **整张卡「有标签没有值」** —— 品牌编码、经销商编码、本年返利总额、本月 / 本年延保轮胎奖励数五个指标位全是空白，不是显示 0，而是彻底没有渲染。而工作台的返利简报在同样无数据时显示的是 `0`。**同一份数据在两个页面上的空态表现不一致**，见 [REQ-WTY-030](#459-业务规则)。
![现状-延保 返利中心-筛选品牌](../mini-program-images/Warranty/返利中心-筛选品牌.png)
**页面内容** —— 返利中心的品牌滚轮，**只有马牌轮胎与维京轮胎两项，没有「全部」**。
**关键交互** —— ①滚动选择品牌；②「取消 / 确定」。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-031](#459-业务规则) 品牌枚举统一
> **本模块第三处品牌枚举，且与前两处都不同** —— 保单筛选 3 项（含「全部」）、工作台筛选 3 项（含「全部」）、返利中心**只有 2 项且缺「全部」**，即返利数据无法一次看全品牌合计。加上 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)的返利品牌里还出现过「卡迪睿德」，品牌枚举须作为主数据统一，见 [REQ-WTY-031](#459-业务规则)。
**返利明细与时间筛选**：可查看延保返利金额，并按起止日期筛选明细数据。
![现状-延保 返利详情](../mini-program-images/Warranty/返利详情.png)
**页面内容** —— 「返利详情」页，顶部是延保返利额汇总（0 元），下方明细列表为空。
**关键交互** —— ①点橙色「设置时间段 - 默认」→ 时间筛选弹层；②明细列表下拉加载。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-032](#459-业务规则) 返利明细的时间筛选改造
> 「设置时间段 - **默认**」这个文案含义不明 —— 「默认」是当前生效的时间段名称，还是按钮的一部分？结合下一张图（起止日期均为空）可判断**默认其实是「不限时间」**，但页面上完全看不出来。见 [REQ-WTY-032](#459-业务规则)。
> 另：顶部只有「延保返利额」一个汇总数，与返利中心的「本年返利总额」是否同一口径，本图无法确认。
![现状-延保 返利详细筛选日期](../mini-program-images/Warranty/返利详细筛选日期.png)
**页面内容** —— 「返利详情设置条件」弹层，仅开始 / 结束日期两项，均未填。
**关键交互** —— ①点「选择日期 >」→ 日期滚轮；②点橙色「确认筛选条件」应用；③「✕ 关闭」取消。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-WTY-004)`。
**需求关联** —— [REQ-WTY-032](#459-业务规则) 返利明细的时间筛选改造
> 三处体验问题：①**没有「清除条件」按钮**（保单筛选有）；②**没有快捷选项**（近 7 天 / 近 30 天），必须手动选两个日期，而同一个 App 内的数据分析页就是胶囊快捷选择；③起止日期默认为空即不限时间，与页面上的「默认」字样对不上。见 [REQ-WTY-032](#459-业务规则)。
> **延保返利与 O2O 返利是两套独立数据**（口径、维度、周期均不同）。整合后是否合并进统一的[返利中心](./11-RBT-返利中心.md#411-返利中心) —— `TODO(REQ-RBT-004)`。
> 延保经营数据与 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)同理，存在口径合并问题 —— `TODO(REQ-PRF-004)`。
## 4.5.7 培训、操作指引与服务支持
**业务目标**：降低门店上手成本，减少因流程不熟导致的建单/理赔错误。
**内置教程中心**：提供零售店注册延保新流程、装车视频拍摄、延保理赔、售后鉴定、无用户信息鉴定、保单作废和延保客服等教程。
![现状-延保 教程](../mini-program-images/Warranty/教程.png)
**页面内容** —— 「使用教程」列表，7 条教程各占一张卡。
**关键交互** —— 点任一卡 `>` → 该教程的视频播放页。
**可用角色** —— 店长 ✅、技工 ✅（教程应全角色开放）。
**需求关联** —— [REQ-WTY-033](#459-业务规则) 教程与功能入口一一对应
> **7 条教程与正文所列完全一致** ✓：零售店注册延保新流程 / 拍摄装车视频 / 理赔操作(延保) / 理赔操作(售后鉴定) / 理赔操作(无用户信息鉴定) / 作废保单操作 / 延保客服操作。
> 但**教程口径与理赔功能的 tab 对不上**：教程有「理赔操作教程(无用户信息鉴定)」而理赔管理里没有该 tab；理赔管理有「CATI理赔」tab 却没有对应教程。见 [REQ-WTY-033](#459-业务规则)。
> 另：「作废保单操作教程」的存在说明作废是门店会常态使用的功能，更凸显 [REQ-WTY-016](#459-业务规则) 状态校验与审计的必要性。
**视频化教程承载**：教程详情以视频播放器形式呈现，支持播放进度与全屏查看。
![现状-延保 教程视频](../mini-program-images/Warranty/教程视频.png)
**页面内容** —— 教程视频播放页，播放区为全黑、进度条显示 00:00 / 00:00。
**关键交互** —— ①点播放区播放 / 暂停；②拖动进度条；③点右下图标全屏。
**可用角色** —— 店长 ✅、技工 ✅。
**需求关联** —— [REQ-WTY-034](#459-业务规则) 教程视频播放器能力
> **视频未加载**（总时长也是 00:00），无法确认是加载失败还是截图时机过早。播放器本身只有进度条与全屏两个控件 —— **没有独立的播放/暂停按钮、没有倍速、没有字幕、没有章节目录**，作为培训材料的承载偏弱，见 [REQ-WTY-034](#459-业务规则)。
**延保客服入口**：首页提供悬浮式延保客服入口，支持门店在建单、激活和理赔过程中寻求帮助（见 [2.7.4](../Continental-Retail-APP-PRD.md#274-延保门店端小程序)）。
**其他小程序入口**：延保小程序内亦挂有跳转其它小程序的入口，整合后取消（见 [现状入口 → App 导航映射](./02-HOM-APP首页与导航.md#422-现状导航与目标导航的差异)）。
![现状-延保 其他小程序入口](../mini-program-images/Warranty/其他小程序入口.png)
**页面内容** —— 延保首页底部升起的四宫格面板，用于跳转到其它四个小程序。
**关键交互** —— 点任一格 → 跳转对应小程序（订单平台 / O2O接单宝 / 积分兑换 / 零售管理）。
**可用角色** —— 店长 ✅；技工 ⚙️ 取决于各目标小程序自身的权限。
**需求关联** —— 整合后取消（见 [现状入口 → App 导航映射](./02-HOM-APP首页与导航.md#422-现状导航与目标导航的差异)）
> **这张图是整合价值最直接的实证**：四个入口分别对应本 PRD 要收编的四个现状系统 —— 订单平台（[4.6 采购](./06-PUR-采购.md#46-采购)）、O2O接单宝（[4.3 销售](./03-SAL-销售.md#43-销售)）、积分兑换（[4.14 福利兑换](./14-MSP-福利兑换.md#414-福利兑换msip)）、零售管理（[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)）。门店现状要在五个小程序之间靠这个面板来回跳，正是[痛点 2.1 多小程序分散](../Continental-Retail-APP-PRD.md#21-多小程序分散)的写照。
> 注意面板里**没有 F6** —— F6 不是小程序，走的是 H5，这也解释了为什么 F6 只能以 Embedded H5 方式整合。
## 4.5.8 需求描述汇总
**业务目标** —— 见各子节
**目标角色** —— 店长：全部功能；技工：建单、待办处理、保单查询、理赔受理（`TODO(REQ-WTY-003)` 需确认）
**入口** —— 底部导航「延保」tab；销售结算页跳转（[4.3.7](./03-SAL-销售.md#437-结算与延保跳转)）；首页待办「延保视频上传提醒」
> **V1.1 补充**：延保实际有**三条入口**，除上述两条外，销售模块的接车页底部还有一个「延保」按钮，且 O2O 已完成订单卡上有「查看延保」。参数契约须统一覆盖，见 [REQ-SAL-011](./03-SAL-销售.md#439-业务规则)。
**前置条件** —— 已登录、已确定门店；门店已开通延保业务
**主流程**：
- 建单：扫描/录入车牌 → 绑定车辆 → 上传装车视频 → **门店激活** → **消费者确认** → 保单生效
- 理赔：扫描理赔码/预约码 → 受理 → 采集证据 → 上报 → 跟踪结果
**异常流程**：
- 车牌识别失败 → 手动输入 / 特殊车牌录入
- 扫码不可用 → 手动输入预约码
- 无关联保单 → 走无用户信息鉴定通道（仅鉴定不理赔）
- 上传失败 → 本地暂存并重试
**权限规则** —— 保单作废、返利查看建议限店长 —— `TODO(REQ-WTY-005)`、`TODO(REQ-WTY-004)`
**访问链路** —— App → App Backend → 延保后台
**逻辑数据来源** —— 延保后台（保单、预约、理赔、鉴定、返利、教程）
**回写目标** —— 建单、装车视频、理赔申请、鉴定资料、条款同意记录 → 延保后台
**状态变化**：
- 保单：待补充 → 待确认 → 正常（生效中）→ **已过有效期** → 已作废（[REQ-WTY-011](#459-业务规则) 补入「已过有效期」）
- 延保生效：门店激活成功 → **用户未确认** → 用户已确认（计入「延保成功」）（[REQ-WTY-018](#459-业务规则)）
- 预约：预约车检 → 已受理 → 已上报
- 延保理赔 / CATI 理赔：正在进行 → 已完成
- 鉴定单：待上传 → 正在进行 → 已完成
## 4.5.9 业务规则
**REQ-WTY-001 双保障并行** —— 原厂质保与撞击延保互不替代；制造缺陷走原厂质保，外力撞击走延保换新
**REQ-WTY-002 待办归并** —— ~~延保待办与首页待办的归并方式待定~~ **V1.1 收窄**：延保内部本就有两套待办，处置方式见 [REQ-WTY-028](#459-业务规则)；**仅「归并后的计数口径与刷新时机」仍待定** `TODO(REQ-WTY-002)`
**REQ-WTY-003 技工权限范围** —— 技工可执行的延保操作范围待定 `TODO(REQ-WTY-003)`
**REQ-WTY-004 返利可见性** —— 延保返利对技工是否可见待定 `TODO(REQ-WTY-004)`
**REQ-WTY-005 保单作废** —— 高风险操作，需权限 + 状态校验 + 审计记录；状态校验与原因留痕的具体要求见 [REQ-WTY-016](#459-业务规则)，**权限归属与是否需后台审批仍待定** `TODO(REQ-WTY-005)`
**REQ-WTY-006 CATI 归属** —— ~~延保与 O2O 两处 CATI 入口的关系待定~~ **V1.1 关闭**：两处不是同一业务，结论见 [REQ-WTY-023](#459-业务规则)
**REQ-WTY-007 无用户信息鉴定** —— 仅做故障鉴定，**不可走延保理赔**；必采字段见 [4.5.5](#455-售后鉴定与证据采集)
**REQ-WTY-008 消费者未认证兼容** —— 该状态不影响延保返利及管理端查询；消费者后续扫码可找回保单。新老系统切换点为 **2020-08-24 07:00**，找回方式为在新系统扫描驾驶证 + 行驶证两证
**REQ-WTY-009 保单筛选** —— 支持激活起止日期 + 品牌（全部 / 马牌 / 维京）
**REQ-WTY-010 条款同意留痕** —— 记录条款版本与同意时间；完整字段要求见 [REQ-WTY-035](#459-业务规则)
> 以下 `REQ-WTY-011` ~ `REQ-WTY-038` 为 V1.1 逐图核对现状后补写。
**REQ-WTY-011 保单状态机补全** —— 保单状态为 **待补充 / 待确认 / 正常（生效中）/ 已过有效期 / 已作废** 五态。原文缺「已过有效期」，而现状详情页确实会显示该状态。列表 tab 的分组与详情页的状态取值须使用同一套枚举
**REQ-WTY-012 保单号与轮胎条码的命名统一** —— 三个概念须严格区分：**轮胎条码**（如 8507302611，商品条码）、**保单子代码**（15 位，如 173147928125203，保单主键）、**轮胎描述**（规格串，如 `215/55R17 94W FR UC7 #`）。列表卡的主标题现状展示的是**轮胎条码**，不得标注为「保单号 / POLICY NO.」；需要展示保单号时使用保单子代码
**REQ-WTY-013 一车四胎、一胎多保障** —— 保单数据是三层结构：**车牌 → 轮胎（各一条条码）→ 保障类型（各一个保单子代码）**。同一车牌下通常有 4 条轮胎记录，同一条轮胎下可有「鼓包保障」「爆胎保障」两个子代码。列表须按此三层组织，不得把同一车牌的多条胎并排展示为多张「相同保单号」的卡片
**REQ-WTY-014 保障类型枚举** —— 固定为 **鼓包保障 / 爆胎保障 / 延保服务** 三种。设计稿中的「**数包保障**」是「鼓包保障」的错别字，须修正
**REQ-WTY-015 操作人与投保人身份** —— ①**安装店员必须记录 App 登录员工的真实身份（工号 + 姓名）**，现状显示「微信用户」使审计留痕形同虚设，也架空了 [REQ-WTY-005](#459-业务规则) 的作废审计要求；②投保人为消费者，未实名时显示「未实名消费者」而非「微信用户」；③条款同意留痕同样须带操作人
**REQ-WTY-016 保单作废的状态校验与留痕** —— ①**已过有效期、已作废的保单，「作废保单」按钮置灰不可点**；②作废须二次确认，并**必填作废原因**（枚举 + 「其它」自由填写）；③作废记录操作人（依赖 [REQ-WTY-015](#459-业务规则)）、时间、原因；④作废不可撤销，二次确认文案须明示
**REQ-WTY-017 保单流水的排序与事件枚举** —— 流水按**业务发生时间正序**展示（现状排序无规律）；事件枚举至少含 **新胎激活 / 鼓包保障 / 爆胎保障 / 用户核保**；门店端事件带门店信息，消费者端事件（如用户核保）不带；每条流水可点进详情
**REQ-WTY-018 延保生效为两段式** —— 延保生效需两步：**门店激活成功 → 消费者确认**。只有两步都完成才计入「延保成功轮胎数」。门店端须明确区分「已激活待确认」与「已生效」两种状态，不得只显示「激活成功」使门店误以为已完成。**消费者未确认时的催办方式（是否推送消费者、门店能否主动催办）未定** —— `TODO(REQ-WTY-018)`
**REQ-WTY-019 O2O「查看延保」页的状态收敛** —— 该页现状同时展示三组互相矛盾的状态（卡片标题「暂无延保信息」/ 卡内「激活成功 + 用户未确认」/ 汇总「延保成功轮胎数 0」）。App 侧须收敛为**单一状态源**：每条轮胎只展示一个明确状态，汇总数由明细聚合得出，两者不得不一致
**REQ-WTY-020 理赔与预约的入口收敛** —— 现状同一批案件至少有三个查看路径（理赔管理三 tab / 全部预约两 tab / 理赔处理两入口），且「全部预约 > 提交的理赔信息」与「理赔管理 > 延保理赔」页面结构完全相同。App 侧收敛为**一个理赔工作台**：按案件类型（延保理赔 / 售后鉴定 / CATI理赔）分 tab，预约作为案件的前置阶段并入同一列表，不再单设「全部预约」页
**REQ-WTY-021 临近预约提醒并入待办** —— 现状理赔管理页顶部的「临近预约（未来 3 天内的预约）」是一条门店需要提前备料备人的主动提醒，须并入 App 首页跨系统待办（与延保视频上传提醒并列），提前天数阈值后台可配置
**REQ-WTY-022 三类案件的状态机各不相同** —— **延保理赔 / CATI理赔为两态**（正在进行 / 已完成），**售后鉴定为三态**（待上传 / 正在进行 / 已完成），**预约为三态**（预约车检 / 已受理 / 已上报）。App 不强行统一为一套状态，按案件类型各自保留，但每个 tab 上须显示待处理计数
**REQ-WTY-023 CATI 的两个面** —— **O2O 侧的 CATI 是门店资质的开通 / 关闭开关，归 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)；延保侧的 CATI 是理赔案件的跟踪列表，归本模块。** 二者不是重复功能，而是同一项资质的两个面。**未开通 CATI 资质的门店，延保侧的「CATI理赔」tab 隐藏。**（关闭原 `TODO(REQ-WTY-006)`）
**REQ-WTY-024 CATI 说明文案与高危开关** —— ①O2O 侧 CATI 页的说明文案现状为脏数据（同段重复 4 遍 + 测试串），须由业务重新提供一版；②「关闭服务」会使门店失去 CATI 资质并影响理赔受理能力，须**二次确认并说明影响范围**
**REQ-WTY-025 脱敏格式统一** —— 手机号统一按 `138****7616`（前三 + 四星 + 后四）脱敏，现状预约详情用的 `*******3963` 须改；**消费者姓名（申请人 / 投保人 / 车主）同样须脱敏**。本条与 [4.3 销售](./03-SAL-销售.md#439-业务规则)、[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)是同一问题，建议在安全章节统一规定
**REQ-WTY-026 鉴定资料的必填项与张数上限** —— 必填照片四类，张数上限各不相同：**DOT 照片 ≤1 张 / 胎侧整体照片（上限待向延保后台确认）/ 胎面照片 ≤1 张 / 故障部位内外部照片 ≤3 张**；补充视频为唯一选填项。每类上传区须配拍照示范缩略图（现状已有，须保留）
**REQ-WTY-027 必填标识与提交校验规范** —— 必填一律以 `*` 标识，**占位文字统一为同一灰色**，不得用红 / 灰区分控件类型（现状用红色表示下拉选择、灰色表示文本输入，易被误读为「红的才必填」）；提交时若有未填项，统一高亮并自动滚动定位到第一个未填项
**REQ-WTY-028 延保内两套待办的归并** —— 延保小程序内部现有两套待办：首页的「待绑定车辆 / 待补充装车视频」计数卡（含独立列表页）与底部 tab「待办事项」。整合后：**延保内不再保留独立待办 tab**，全部并入 App 首页待办；首页的两个计数卡保留为延保页内的快捷筛选入口
**REQ-WTY-029 数据口径「截止到今日 0 点」** —— 延保经营数据为 **T+1、不含当天**，图表上须保留该口径声明。与 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)的实时性口径一并裁决（`TODO(REQ-PRF-004)`）
**REQ-WTY-030 空数据的兜底渲染** —— ①指标位无数据时显示 `0` 或 `—`，**不得出现「有标签无数值」**（现状返利中心整卡空白）；②图表无数据时显示统一空态插画，**不得只剩图例**（现状用户性别图）或**全 0 却等高**（现状年龄分布图）；③全模块空态文案统一（现状有「暂无数据」「没有更多了」「暂无预约记录」三种写法）
**REQ-WTY-031 品牌枚举统一** —— 品牌为主数据，全 App 使用同一套枚举与展示名，**筛选器一律包含「全部」**。现状本模块内有三种写法（保单筛选 3 项 / 工作台缩写「马 维」/ 返利中心 2 项缺「全部」）。**延保品牌是否包含卡迪睿德（[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)的返利品牌中出现过）未定** —— `TODO(REQ-WTY-031)`
**REQ-WTY-032 返利明细的时间筛选** —— 改为「近 7 天 / 近 30 天 / 自定义」三档快捷选择，**默认近 30 天**（现状默认为不限，且页面上写作含义不明的「默认」），并提供「重置」按钮
**REQ-WTY-033 教程与功能入口一一对应** —— 教程清单须与实际功能入口对应：现状「无用户信息鉴定」有教程无 tab、「CATI理赔」有 tab 无教程。同时教程支持**从对应功能页直接唤起**（上下文帮助），而不是只能从工作台进教程列表逐个找
**REQ-WTY-034 教程视频播放器能力** —— 须支持 播放/暂停、进度拖拽、**倍速（0.75/1/1.25/1.5/2）**、全屏、加载失败重试；弱网下允许降码率播放。现状播放器只有进度条与全屏
**REQ-WTY-035 条款的两页式与留痕字段** —— 条款分「使用条款」+「违规处理」两页，**须两页均阅读完毕才可同意**；留痕记录 **条款版本号 + 同意时间 + 操作人**（现状只有时间）。（补充 [REQ-WTY-010](#459-业务规则)）
**REQ-WTY-036 保单协议的 PDF 预览** —— 保单协议以 PDF 文件形式提供，App 须具备原生 PDF 预览能力（缩放、分页、保存），并**保留文档页脚的 Continental 密级标识**，不得裁剪
**REQ-WTY-037 车牌录入的两种模式** —— ①**普通模式用车牌格子**（逐位输入、支持「新能源」切换 7/8 位），**特殊模式用自由文本输入框**（不做位数校验），两者为**同页切换控件**，不是页面跳转（设计稿画成外链跳转须修正）；②车牌识别为**拍照上传识别**，与 [REQ-SAL-002](./03-SAL-销售.md#439-业务规则) 复用同一套 OCR 能力；③取景提示文案须与实际框色一致（现状文案写「黄色」、框是橙色）；④「手动输入车牌」改用中性 / 次要按钮样式，**红色仅保留给危险操作**
**REQ-WTY-038 统一选择器** —— 日期与品牌等选择控件由 App 自研并随主题配色，替代现状的微信原生 picker（白底 + 绿色按钮压在深色页面上，本模块 4 处出现）
## 4.5.10 验收标准
1. 门店未开通延保业务时，延保 tab 不显示；
2. 车牌识别失败可切换手动输入与特殊车牌录入，已录入内容不丢失；
3. 「待绑定车辆」「待补充装车视频」计数与待办列表条数一致，且与首页对应待办项一致；
4. 无关联保单的轮胎进入无用户信息鉴定通道后，界面不提供任何理赔提交入口；
5. 弱网下上传鉴定照片/视频中断后，重新进入可从本地暂存恢复，不需要重新拍摄；
6. 保单作废后，该保单在所有列表与筛选结果中状态一致，且留有操作人与时间的审计记录；
7. 保单列表卡的主标题字段名为「轮胎条码」，详情页的「保单号」为 15 位保单子代码，两处不混用（[REQ-WTY-012](#459-业务规则)）；
8. 同一车牌下的 4 条轮胎在列表中展示为 4 条不同条码的记录，不出现「相同保单号」的重复卡片（[REQ-WTY-013](#459-业务规则)）；
9. 已过有效期的保单，其「作废保单」按钮为置灰不可点状态（[REQ-WTY-016](#459-业务规则)）；
10. 作废保单时必须选择作废原因并二次确认，作废记录中可查到操作人的真实工号与姓名（[REQ-WTY-015](#459-业务规则)、[REQ-WTY-016](#459-业务规则)）；
11. 门店激活成功但消费者未确认的轮胎，在门店端显示为「待消费者确认」，且不计入「延保成功轮胎数」（[REQ-WTY-018](#459-业务规则)）；
12. 「查看延保」页中每条轮胎只显示一个状态，汇总数与明细条数一致（[REQ-WTY-019](#459-业务规则)）；
13. 未开通 CATI 资质的门店，延保侧不显示「CATI理赔」tab（[REQ-WTY-023](#459-业务规则)）；
14. 预约详情中的消费者手机号按 `138****7616` 格式脱敏，姓名同样脱敏（[REQ-WTY-025](#459-业务规则)）；
15. 无用户信息鉴定表单在有未填必填项时点击「确认保存」，页面自动滚动到第一个未填项并高亮（[REQ-WTY-027](#459-业务规则)）；
16. 无数据门店进入返利中心与数据分析页时，所有指标位显示 `0` 或 `—`，图表显示统一空态插画，不出现空白标签或等高柱（[REQ-WTY-030](#459-业务规则)）；
17. 保单筛选、工作台、返利中心三处的品牌下拉，选项完全一致且均含「全部」（[REQ-WTY-031](#459-业务规则)）；
18. 教程视频支持倍速播放，加载失败时给出重试入口（[REQ-WTY-034](#459-业务规则)）。
---
## 附：本模块归拢信息（来自主文件其它章节）
### 附-1 业务数据字典（主文件 A.6）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 延保服务信息集 | Mini Program Backend | HTTPS | 保存到延保后台 |
| 2 | 延保出库 | Mini Program Backend | HTTPS | |
| 3 | 延保注册数据集 | User Input | HTTPS | 保存到延保后台 |
| 4 | 保单 / 预约 / 理赔 / 鉴定 / 返利 / 教程 | Mini Program Backend | HTTPS | 延保后台 |
**本次拆分对 A.6 的三点修订建议**（回灌主文件时一并处理）：
1. **第 4 条过于笼统** —— 一行囊括六类业务数据，无法据此设计接口。建议至少拆为：保单结果集 / 保单详情（含保单子代码、轮胎条码、安装信息、系统流水）、预约结果集 / 预约详情、理赔案件结果集（三类案件）、鉴定单与鉴定资料（含照片视频，走对象存储）、返利汇总与明细、教程清单与视频。
2. **缺「延保生效确认」数据** —— [REQ-WTY-018](#459-业务规则) 明确延保生效是两段式（门店激活 + 消费者确认），但附录 A 没有承载「消费者确认状态」的数据集。须补。
3. **鉴定照片与教程视频须区分存储通道** —— 二者都是大文件但性质不同：鉴定照片是门店上传的证据（写入，需断点续传与本地暂存），教程视频是平台下发的素材（读取，需 CDN 与降码率）。A.6 现在都归在「Mini Program Backend」下，须分开说明。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **延保** | 建单（扫车牌/绑定车辆/装车视频） | ✅ | ❓ | `TODO(REQ-WTY-003)` |
| | 保单查询 | ✅ | ❓ | 同上 |
| | **保单作废** | 🔸 | ✗ | 高风险，需二次确认 + 审计 `TODO(REQ-WTY-005)` |
| | 理赔受理 / 售后鉴定 | ✅ | ❓ | `TODO(REQ-WTY-003)` |
| | 延保返利 | ✅ | ❓ | `TODO(REQ-WTY-004)` |
**本次拆分建议新增的三行**（回灌主文件时一并处理）：
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **延保** | 鉴定资料采集（拍照 / 录像 / 提交） | ✅ | ⚙️ | 现场作业，实际以技工为主，建议默认授予（[REQ-WTY-026](#459-业务规则)） |
| | 经营数据 / 用户画像查看 | ✅ | ❓ | 含消费者性别年龄聚合，口径同 `TODO(REQ-WTY-004)` |
| | 使用教程 | ✅ | ✅ | 培训材料，全角色开放（[REQ-WTY-033](#459-业务规则)） |
另需明确：**「保单作废」一行的 🔸 受限需要落到实处** —— 现状既无状态校验也无二次确认，且操作人记录为「微信用户」。在 [REQ-WTY-015](#459-业务规则) 落地前，该行的审计要求无法满足。
### 附-3 待确认项（主文件 10.2.5）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-WTY-002 | ~~延保待办与首页待办的归并方式~~ **收窄为：归并后的计数口径与刷新时机**（归并方式已由 [REQ-WTY-028](#459-业务规则) 明确） | 产品 |
| REQ-WTY-003 | 技工可执行的延保操作范围 | 产品 |
| REQ-WTY-004 | 延保返利对技工是否可见 | 产品 |
| REQ-WTY-005 | ~~保单作废的权限、二次确认、作废原因、是否需后台审批~~ **收窄为：权限归属与是否需后台审批**（状态校验、二次确认、作废原因已由 [REQ-WTY-016](#459-业务规则) 明确） | 业务 / 安全 |
| ~~REQ-WTY-006~~ | ~~延保与 O2O 两处 CATI 入口的关系与归属~~ —— **本次拆分关闭**，结论见 [REQ-WTY-023](#459-业务规则) | — |
**本次拆分新增 2 条**（回灌主文件时并入 10.2.5）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-WTY-018 | 消费者未确认延保时的催办方式（是否推送消费者、门店能否主动催办） | 业务 |
| REQ-WTY-031 | 延保品牌枚举是否包含卡迪睿德 | 业务 / 主数据 |
合计 6 条待确认（原 5 条中关闭 1 条、收窄 2 条，新增 2 条）。
### 附-4 配图清单（主文件附录 C 4.5 节，43 张）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 现状-延保 保单协议 | `mini-program-images/Warranty/保单协议.png` |
| 2 | 现状-延保 德国马牌零售商延保使用条款须知 | `mini-program-images/Warranty/德国马牌零售商延保使用条款须知.png` |
| 3 | 设计稿-延保服务（App 目标形态，与现状延保首页 2.7.4 一一对应） | `app-design-images/延保服务.png` |
| 4 | 现状-延保 扫描车牌 | `mini-program-images/Warranty/扫描车牌.png` |
| 5 | 现状-延保 特殊车牌输入 | `mini-program-images/Warranty/特殊车牌输入.png` |
| 6 | 现状-延保 待绑定车辆 | `mini-program-images/Warranty/待绑定车辆.png` |
| 7 | 现状-延保 待补充装车视频 | `mini-program-images/Warranty/待补充装车视频.png` |
| 8 | 现状-延保 待办事项 | `mini-program-images/Warranty/待办事项.png` |
| 9 | 现状-延保 首页切换店铺 | `mini-program-images/Warranty/首页切换店铺.png` |
| 10 | 现状-延保 工作台选择店铺 | `mini-program-images/Warranty/工作台-选择店铺.png` |
| 11 | 设计稿-保单管理 | `app-design-images/保单管理.png` |
| 12 | 现状-延保 所有保单 | `mini-program-images/Warranty/所有保单.png` |
| 13 | 现状-延保 保单子代码详情 | `mini-program-images/Warranty/保单子代码详情.png` |
| 14 | 现状-延保 保单详情（保单与活动信息） | `mini-program-images/Warranty/保单详情-保单与活动信息.png` |
| 15 | 现状-延保 保单详情（延保信息） | `mini-program-images/Warranty/保单详情-延保信息.png` |
| 16 | 现状-延保 保单筛选 | `mini-program-images/Warranty/保单筛选.png` |
| 17 | 现状-延保 保单筛选（日期） | `mini-program-images/Warranty/保单筛选日期.png` |
| 18 | 现状-延保 保单筛选（品牌） | `mini-program-images/Warranty/保单筛选品牌.png` |
| 19 | 现状-O2O 查看延保 | `mini-program-images/O2O/查看延保.png` |
| 20 | 现状-延保 全部预约（预约信息 1） | `mini-program-images/Warranty/全部预约-预约信息1.png` |
| 21 | 现状-延保 全部预约（预约信息 2） | `mini-program-images/Warranty/全部预约-预约信息2.png` |
| 22 | 现状-延保 全部预约（预约信息详情） | `mini-program-images/Warranty/全部预约-预约信息详情.png` |
| 23 | 现状-延保 理赔（延保理赔） | `mini-program-images/Warranty/理赔-延保理赔.png` |
| 24 | 现状-延保 理赔处理 | `mini-program-images/Warranty/理赔处理.png` |
| 25 | 现状-延保 手动输入预约码 | `mini-program-images/Warranty/手动输入预约码.png` |
| 26 | 现状-延保 全部预约（提交的理赔信息） | `mini-program-images/Warranty/全部预约-提交的理赔信息.png` |
| 27 | 现状-延保 理赔（CATI 理赔） | `mini-program-images/Warranty/理赔-CATI理赔.png` |
| 28 | 现状-O2O 认证轮胎技术检测中心（CATI） | `mini-program-images/O2O/认证轮胎技术检测中心CATI.png` |
| 29 | 现状-延保 售后鉴定 | `mini-program-images/Warranty/售后鉴定.png` |
| 30 | 现状-延保 理赔（售后鉴定） | `mini-program-images/Warranty/理赔-售后鉴定.png` |
| 31 | 现状-延保 无用户信息鉴定通道（1） | `mini-program-images/Warranty/无用户信息鉴定通道1.png` |
| 32 | 现状-延保 无用户信息鉴定通道（2） | `mini-program-images/Warranty/无用户信息鉴定通道2.png` |
| 33 | 现状-延保 工作台（筛选品牌） | `mini-program-images/Warranty/工作台-筛选品牌.png` |
| 34 | 现状-延保 工作台（年） | `mini-program-images/Warranty/工作台-年.png` |
| 35 | 现状-延保 数据分析（1） | `mini-program-images/Warranty/数据分析1.png` |
| 36 | 现状-延保 数据分析（2） | `mini-program-images/Warranty/数据分析2.png` |
| 37 | 现状-延保 返利中心 | `mini-program-images/Warranty/返利中心.png` |
| 38 | 现状-延保 返利中心（筛选品牌） | `mini-program-images/Warranty/返利中心-筛选品牌.png` |
| 39 | 现状-延保 返利详情 | `mini-program-images/Warranty/返利详情.png` |
| 40 | 现状-延保 返利详细（筛选日期） | `mini-program-images/Warranty/返利详细筛选日期.png` |
| 41 | 现状-延保 教程 | `mini-program-images/Warranty/教程.png` |
| 42 | 现状-延保 教程视频 | `mini-program-images/Warranty/教程视频.png` |
| 43 | 现状-延保 其他小程序入口（整合后取消） | `mini-program-images/Warranty/其他小程序入口.png` |
**看图后对本清单的补充说明**：
- **第 6、7 两行指向的两个文件内容完全相同** —— 均为「待绑定车辆」tab 的空态截图（同一时刻、同一电量）。**「待补充装车视频」tab 至今没有任何佐证**，而它恰是首页待办里唯一被列入 App 跨系统待办的延保事项。**建议优先补拍。**
- **第 5 行「特殊车牌输入」实际拍的是延保小程序首页**（处于特殊车牌模式），说明文字应改为「现状-延保 首页（特殊车牌录入模式）」。
- **第 28 行的 O2O CATI 页不是理赔页，而是门店资质开通页**（底部按钮「关闭服务」），说明文字应补上这一点 —— 这正是 [REQ-WTY-023](#459-业务规则) 的依据。
- **测试与脏数据分布**：第 4 张取景框内拍的是笔记本键盘；第 19 张门店名「智慧园杀虫轮胎店」；第 28 张说明文案重复 4 遍并含测试串「xxx特热爱111…」。
- **数据全为 0 的门店样本**：第 6–10、20–27、29–30、33–40 张均为空态或全 0，因此**有数据时的卡片形态、图表形态、列表字段大多无法确认**。
- **无法确认的四处**：第 5 张底部 tab 中间的橙色圆形图标无文字标签，功能不明；第 22 张的「订单图片 / 订单确认图片」两栏为空，展示形式不明；第 32 张「胎侧整体照片」的张数上限被返回胶囊遮挡；第 33 张「筛选结果」标签下无数值。
- 建议**补拍 5 张**：「待补充装车视频」tab 的实际内容、有数据的保单列表（能看到状态标识）、已受理状态的预约卡片、有案件的理赔列表（三类各一）、教程视频加载成功后的播放器。补拍后附录 C 的 4.5 节计数由 43 → 48，须同步更新文档头部规模声明与本文件头部信息表。
### 附-5 本次拆分新增发现
1. **保单的数据结构与正文表述不符，这是本模块最重要的一处更正** —— 列表卡上的 `8507302611` 不是保单号而是**轮胎条码**，真正的保单号是 15 位的「保单子代码」。数据是**车牌 → 轮胎 → 保障类型**三层：一车四胎、一胎可有鼓包与爆胎两个子代码。设计稿把它标成 `POLICY NO.` 并画出三张「同号不同状态」的卡片，是对业务的误解。见 [REQ-WTY-012](#459-业务规则)、[REQ-WTY-013](#459-业务规则)。
2. **延保生效是两段式的，正文完全没写** —— O2O「查看延保」页同时显示「激活成功」与「用户未确认」，且「订单轮胎数 4 / 延保成功轮胎数 0」。**门店激活之后还需要消费者确认才算生效**。这条规则直接决定门店端的状态展示与催办设计，见 [REQ-WTY-018](#459-业务规则)。
3. **保单状态机缺一态** —— 现状会显示「延保已过有效期」，而正文声明的状态机只有「待补充 → 待确认 → 正常 → 已作废」。见 [REQ-WTY-011](#459-业务规则)。
4. **审计留痕现状是空的** —— 「安装店员」和「投保人」都显示「微信用户」，拿不到真实身份。这不是显示问题，而是**使 [REQ-WTY-005](#459-业务规则) 的作废审计要求形同虚设** —— 作废了保单也不知道是谁作废的。见 [REQ-WTY-015](#459-业务规则)。
5. **作废保单现状没有任何防护** —— 已过有效期的保单，红色「作废保单」按钮仍常驻底部且可点，没看到状态校验，也没有二次确认与作废原因。正文要求的「权限 + 状态校验 + 审计记录」三样现状全缺。见 [REQ-WTY-016](#459-业务规则)。
6. **`TODO(REQ-WTY-006)` 可以关闭** —— O2O 侧的 CATI 页底部按钮是「**关闭服务**」，说明那是**门店资质开关**（归门店管理）；延保侧的 CATI 是**理赔案件跟踪**（归延保）。两处不是重复功能，而是同一资质的两个面。见 [REQ-WTY-023](#459-业务规则)。
7. **`TODO(REQ-WTY-002)` 比原文描述的更复杂** —— 要归并的不是「延保待办 vs 首页待办」两套，而是三套：延保首页的两个计数卡（有独立列表页）、延保底部 tab 的「待办事项」（另一个独立页）、App 首页待办。见 [REQ-WTY-028](#459-业务规则)。
8. **发现一条正文完全没记的主动提醒机制** —— 理赔管理页顶部有「临近预约（未来 3 天内的预约）」卡。门店需要在预约日前备料备人，这与 [4.4 提醒](./04-RMD-提醒.md#44-提醒)和首页待办是同一类东西，应并入跨系统待办。见 [REQ-WTY-021](#459-业务规则)。
9. **理赔与预约的入口严重冗余** —— 同一批案件至少有三个查看路径，其中「全部预约 > 提交的理赔信息」与「理赔管理 > 延保理赔」的页面结构完全相同。且「理赔处理」与「理赔管理」是两个不同页面却几乎同名。见 [REQ-WTY-020](#459-业务规则)。
10. **三类案件的状态机不同，不能强行统一** —— 延保理赔 / CATI理赔两态，售后鉴定三态（多「待上传」），预约三态（预约车检 / 已受理 / 已上报）。正文 4.5.5 写的三态**只适用于售后鉴定**。见 [REQ-WTY-022](#459-业务规则)。
11. **品牌枚举在本模块内就有三种写法** —— 保单筛选 3 项（含全部）、工作台缩写「马 / 维」、返利中心 2 项（缺全部）；加上 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心)出现过的「卡迪睿德」，品牌须作为主数据统一。见 [REQ-WTY-031](#459-业务规则)。
12. **空数据的兜底渲染有三类缺陷** —— 返利中心整卡「有标签无数值」、用户性别图只剩图例、年龄分布图全 0 却六柱等高。空态文案也有三种写法（暂无数据 / 没有更多了 / 暂无预约记录）。见 [REQ-WTY-030](#459-业务规则)。
13. **数据口径是 T+1** —— 三张图表都标「截止到 今日0点」。这条必须写进 PRD，否则门店会把「今天的单看不到」当作缺陷反复提。见 [REQ-WTY-029](#459-业务规则)。
14. **脱敏格式与 [4.8 我的](./08-MIN-我的.md#48-我的--个人中心) 不一致** —— 此处是 `*******3963`（7 星 + 后四），我的模块是 `138****7616`（前三 + 四星 + 后四），且消费者姓名完全未脱敏。这是本次拆分在 [4.3 销售](./03-SAL-销售.md#439-业务规则)、[4.8 我的](./08-MIN-我的.md#48-我的--个人中心)、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)之后**第四次**遇到同一类问题，**强烈建议在第 5 章或安全章节统一规定一次**。
15. **教程口径与功能入口对不上** —— 教程有「无用户信息鉴定」但理赔管理无该 tab；理赔管理有「CATI理赔」tab 但无对应教程。见 [REQ-WTY-033](#459-业务规则)。
16. **微信原生 picker 是小程序无法回避的主题断裂** —— 深色页面上弹出白底 + 绿色确定按钮的滚轮，本模块 4 处出现。这条是「为什么要做原生 App」的一个具体论据。见 [REQ-WTY-038](#459-业务规则)。
17. **「其他小程序入口」是整合价值最直接的实证** —— 四宫格面板（订单平台 / O2O接单宝 / 积分兑换 / 零售管理）正好对应本 PRD 要收编的四个现状系统，门店现状要在五个小程序间来回跳。**建议把这张图同时引用到第 2 章痛点部分**（现状仅在 4.5 出现一次）。
18. **[REQ-WTY-010](#459-业务规则) 条款留痕在现状已实现**（页面顶部展示「本账户于 2026.03.18 14:57 同意本条款」），但缺条款版本号与操作人，且条款实为两页。见 [REQ-WTY-035](#459-业务规则)。
prd/modules/06-PUR-采购.md
+401
View File
@@ -0,0 +1,401 @@
# 4.6 采购
> **本文件是【采购 PUR】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.6 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | PUR |
| V1.0 章节 | 4.6 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + ROOS 截图 + 设计稿 |
| 现状承载系统 | ROOS（马牌）+ F6（非马牌） |
| 需求条数 | 18（待确认 12，完成度 33%） |
| 本次新增待确认 | 5（REQ-PUR-014 ~ 018） |
| 配图 | 9 张（设计稿 2 / 现状-ROOS 7） |
模块概要
---
**采购覆盖门店要买的全部商品**，包括马牌商品与耗材、辅料、其它品牌轮胎，一套浏览、加购、结算、收货、售后流程走到底，门店不需要按品牌切换页面。
数据来源上，马牌商品走 ROOS、其余商品走 F6。ROOS 本身就是马牌在 F6 后台之上自建的采购小程序 —— 品牌方要单独管理并统计各门店对自有品牌的采购情况，才有了这一层；对门店而言仍是同一个采购功能。
## 4.6.1 需求描述
**业务目标** —— 门店在 App 内完成**全部品类**的订货全流程（搜索 → 加购 → 结算 → 收货 → 售后），覆盖马牌与非马牌商品，并保留 ROOS 的额度、返利、优惠券结算能力，解决[痛点 2.3](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)
**目标角色** —— 店长：全部；技工：**需被授权**后功能同店长
**入口** —— 底部导航「采购」tab；首页快捷入口「采购」。全部商品同在此 tab 内，按分类 / 品牌逐级筛选
**前置条件** —— 已登录、已确定门店；采购马牌商品还需门店在 ROOS 有有效的经销商 / 信用账户
**页面内容** —— 商品搜索与筛选 → 商品列表 → 购物车 → 订单确认（费用构成与扣账方式）→ 我的订单（六状态）→ 订单详情 → 售后/退款；扫码收货
**主流程** —— 搜索商品 → 加入购物车 → 调整数量并勾选 → 结算 → 确认费用与扣账方式 → 提交订单 → 扫码收货。马牌与非马牌商品的流程完全一致，门店感知不到品牌差异
**异常流程**：
- 信用额度不足 → 提示并阻断提交（校验时机见 [REQ-PUR-017](#467-业务规则)）
- 商品无库存 → 加购按钮替换为「缺货登记」入口（[REQ-PUR-014](#467-业务规则)）
- 商品下架 → 列表不再返回该商品
- 扫码收货条码不匹配 → 提示并拒收
**业务规则** —— 见 [4.6.7](#467-业务规则)
**权限规则** —— 技工默认无采购权限，需店长/后台授权（[REQ-PUR-001](#467-业务规则)）
**访问链路** —— App → App Backend → ROOS（马牌商品）/ F6（非马牌商品）
**逻辑数据来源** —— **马牌商品：ROOS**；**非马牌商品：F6**。两者的底层服务同为 F6，ROOS 是马牌品牌侧的管理与统计层
**回写目标** —— 购物车、采购订单、扣账方式选择、收货确认、售后申请 → 对应来源系统
**状态变化** —— 采购订单：待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消（六状态，见 [REQ-PUR-006](#467-业务规则)）
**验收标准** —— 见 [4.6.9](#469-验收标准)
## 4.6.2 产品搜索与商品列表
用户通过顶部搜索框与筛选条件收窄范围，查询出搜索结果列表。**马牌商品的搜索接口来源于 ROOS，非马牌商品来源于 F6**，两类结果在同一列表内呈现，门店按品牌 / 分类筛选即可，不需要切换页面。
![设计稿-订单管理-商品列表](../app-design-images/订单管理-商品列表.png)
**页面内容** —— App 采购商品列表的目标形态：搜索框 + 购物车图标、一行规格筛选、「显示有货 / 显示促销」开关与品牌下拉，主体为单列商品卡（**4 张卡为同一份占位数据**，仅库存状态不同）。
**关键交互** —— ①点规格筛选任一项 → 展开该维度取值多选；②切换「显示有货 / 显示促销」→ 列表按开关过滤；③点「马牌 ▾」→ 切换品牌；④有货 / 库存紧张的卡点右下加购图标 → 加入购物车，购物车角标 +1；⑤**缺货卡的加购图标被替换为「去登记」按钮** → 进入缺货登记（[REQ-PUR-014](#467-业务规则)）；⑥点购物车图标 → 进入购物车页。
**可用角色** —— 店长 ✅ 全量；技工 ⚙️ 需店长或后台在[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)中授予采购权限后方可进入（[REQ-PUR-001](#467-业务规则)）。
**需求关联** —— [REQ-PUR-007](#467-业务规则) 数据来源、[REQ-PUR-010](#467-业务规则) 商品域范围、[REQ-PUR-014](#467-业务规则) 缺货登记、[REQ-PUR-015](#467-业务规则) 商品卡字段
![现状-ROOS 商品选择](../mini-program-images/ROOS/商品选择.png)
**页面内容** —— ROOS 小程序的商品选择页，结构与上方设计稿高度一致，差别在于商品卡多出「可延保」与时效标、缺货商品直接在图上压「缺货」并给出「缺货登记」按钮，底部是 ROOS 自身的四 tab。
**关键交互** —— ①同上方设计稿的搜索与筛选；②点「缺货登记」→ 提交该商品的缺货登记；③点加购 → 加入 ROOS 购物车；④点底部 tabbar「购物车」→ 进入购物车页。**整合到 App 后 ROOS 自身的 tabbar 不再出现**，购物车入口收敛到列表页右上角（见上方设计稿）。
**可用角色** —— 同上方设计稿：店长 ✅、技工 ⚙️。
**需求关联** —— [REQ-PUR-007](#467-业务规则) 数据来源、[REQ-PUR-014](#467-业务规则) 缺货登记、[REQ-PUR-015](#467-业务规则) 商品卡字段
> **本节正文原描述与两张图不符，已按图修订**（不新增需求编号）：
>
> V1.0 原文写「左侧树形分类（按品牌 / 花纹 / 规格逐级收窄）+ 右侧商品卡」。**两张图都不是这个结构** —— 均为「顶部平铺筛选行 + 单列商品卡」，没有左侧分类树。[4.6.8](#468-业务数据列表) 中 `productCategory` 的备注「树形分类」也应据此复核：该字段可能只是后台的分类层级，并不对应一个前端树形控件。上方正文已改为「顶部搜索框与筛选条件」。
## 4.6.3 购物车与结算
**加入购物车**：用户点击商品卡的加购图标，将商品加入购物车。用户可以调整采购数量，选择商品条目前面的选择图标，点击「结算」按钮进入结算页。
![设计稿-订单管理-购物车](../app-design-images/订单管理-购物车.png)
**页面内容** —— App 购物车的目标形态，商品**按品牌分组**（「德国马牌」组已勾选、「维京轮胎」组未勾选），底部为「合计 / 已减 / 结算」结算条。
**关键交互** —— ①勾选 / 取消单行或整个品牌组 → 合计与已减金额实时重算；②数量步进器 `−` / `+` → 改变该行数量；③点「优惠明细 ^」→ 展开本单优惠构成；④点「结算」→ 进入订单确认页。
**可用角色** —— 店长 ✅；技工 ⚙️ 被授权后可加购与调整数量，**能否点「结算」并最终提交订单未定** `TODO(REQ-PUR-002)`，关闭前按不可提交实现。
**需求关联** —— [REQ-PUR-011](#467-业务规则) 购物车与订单是否合并、[REQ-PUR-002](#467-业务规则) 技工下单权限
> **本图不能作为 [REQ-PUR-011](#467-业务规则) 已解决的证据**：图中分组的「德国马牌」与「维京轮胎」**同属 ROOS 的品牌**，两者本来就在一个系统内。真正的分歧点是 ROOS 商品与 F6 非马牌商品能否共用一个购物车，本图未涉及。
![现状-ROOS 购物车](../mini-program-images/ROOS/购物车.png)
**页面内容** —— ROOS 现状购物车，**本图为单商品的轻量态**（无优惠行），商品归在「德国马牌」组下，行内比设计稿多出商品编码与时效标。
**关键交互** —— ①点「编辑」→ 进入批量管理态（可删除 / 移出）；②勾选与数量调整同设计稿；③点「结算」→ 进入订单确认页。
**可用角色** —— 同上方设计稿：店长 ✅、技工 ⚙️ + `TODO(REQ-PUR-002)`。
**需求关联** —— [REQ-PUR-015](#467-业务规则) 商品卡字段（商品编码、时效标）
> 时效标在三张图里出现了**三种写法** —— 设计稿购物车「最快45分钟」、ROOS 商品选择「⏱45分钟」、ROOS 购物车「⏱1小时」。该标是随商品与仓库动态计算的，App 侧需统一文案模板，一并归入 [REQ-PUR-015](#467-业务规则)。
**结算与提交订单**：用户在订单确认页核对费用构成后，点击「提交订单」，完成采购流程。
![现状-ROOS 订单确认](../mini-program-images/ROOS/订单确认.png)
**页面内容** —— ROOS 现状订单确认页，自上而下为收货地址、订单商品区、费用构成（立减 / 优惠券 / **运费待双方商定** / **返利请选择** / 备注）与底部支付条（**信用额度不可用**），**本图为测试数据**（收货人「测试」、地址为重复拼接的脏数据）。
**关键交互** —— ①点收货地址 → 切换 / 编辑地址；②点「优惠券」→ 选择可用券；③点「返利 请选择」→ 选择本单抵扣的返利额度（见[返利中心](./11-RBT-返利中心.md#411-返利中心)）；④填写备注；⑤点「提交订单」→ 提交（额度校验结果见下图）。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-PUR-002)`。返利抵扣涉及门店资金账户，即便技工被授权采购，是否可动用返利额度需一并确认。
**需求关联** —— [REQ-PUR-004](#467-业务规则) 支付方式、[REQ-PUR-016](#467-业务规则) 订单确认页费用构成、[REQ-PUR-011](#467-业务规则) 购物车与订单是否合并
> **本图给出两条与 V1.0 正文冲突的事实**：
>
> 1. **页面上没有任何支付方式选择器。** V1.0 的 4.6.3 原文写「用户选择支付方式后，点击提交订单」，现状实际是「信用额度 + 返利 + 优惠券」三者构成扣账，没有微信/支付宝式的支付方式单选。整合后的形态归入 [REQ-PUR-016](#467-业务规则) 与 `TODO(REQ-PUR-004)`。
> 2. **订单标题为「订单1–德国马牌」并标「普通订单」** —— 说明 ROOS 现状**已经按品牌把一次结算拆成多张订单**。这对 [REQ-PUR-011](#467-业务规则) 是重要输入：连同属 ROOS 的两个品牌都要拆单，跨 ROOS / F6 合并成一张订单的可行性更低，更现实的形态是「一个购物车 → 按来源拆多张子订单 → 列表侧聚合展示」。
**信用额度校验**：额度不足时给出明确提示并阻断下单。
![现状-ROOS 订单确认-额度不足提示](../mini-program-images/ROOS/订单确认-额度不足提示.png)
**页面内容** —— 订单确认页上弹出的失败弹窗，标题「订单提交失败」，正文「账户额度不足，请联系经销商处理」，单按钮「我知道了」。
**关键交互** —— ①点「我知道了」→ 关闭弹窗回到订单确认页，订单未生成。**无重试、无跳转充值 / 联系经销商的入口**，门店只能自行线下联系。
**可用角色** —— 店长 ✅、技工 ❓ `TODO(REQ-PUR-002)`（能提交才会遇到本弹窗）。
**需求关联** —— [REQ-PUR-003](#467-业务规则) 额度校验、[REQ-PUR-017](#467-业务规则) 额度校验时机
> **本图与 [REQ-PUR-003](#467-业务规则)、[验收标准第 2 条](#469-验收标准)直接冲突**：现状是**点击提交之后**才由服务端返回「订单提交失败」，而 REQ-PUR-003 要求「提交订单前校验」、验收标准要求「『提交订单』不可点击，且提示包含可用额度与本单金额」。现状弹窗既不置灰按钮，也不告知可用额度与本单金额差额。已新增 [REQ-PUR-017](#467-业务规则) 明确校验时机与提示内容。
> 支付方式的可选集合、优先级与扣账逻辑由「[支付优先级设置](./08-MIN-我的.md#48-我的--个人中心)」决定。整合后支付方式与 CDMS 支付的关系 —— `TODO(REQ-PUR-004)`。
## 4.6.4 收货
用户扫描商品，完成收货流程。扫码为 **App 原生实现**（见 [REQ-INT-003](../Continental-Retail-APP-PRD.md#73-f6-集成边界)），非嵌入 H5。
> 收货扫码与[扫码入库](./07-INV-库存.md#47-库存)是否为同一动作、是否一次扫码同时完成收货与入库 —— `TODO(REQ-PUR-005)`。
>
> [附录 A.5](../Continental-Retail-APP-PRD.md#a5-采购) 第 5 条已经把这两件事写成同一个数据集「收货（扫码入库）」，倾向于合并；但正文与 REQ-PUR-005 仍按未定处理，需业务正式确认后统一两处口径。
本节无配图 —— **收货页面既无设计稿也无现状截图**，扫码后的收货确认页（是否逐条核对、是否支持部分收货、拒收如何记录）目前没有任何页面材料。
## 4.6.5 订单管理与售后
**采购订单列表**：tag 分为**全部、待支付、待发货、待收货、已收货、已取消**六个状态。
![现状-ROOS 我的订单-全部](../mini-program-images/ROOS/我的订单-全部.png)
**页面内容** —— ROOS「我的订单」列表，顶部为搜索框与「筛选」、其下六个状态 tab（全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消，当前选中「全部」），**本截图为空态**（「您还没有相关的订单」），故订单行的字段与操作按钮无法从本图确认。
**关键交互** —— ①在搜索框输入订单号 / 商品名称 / 商品编码 → 检索订单；②点「筛选」→ 打开 tab 之外的附加筛选条件（**本图未展开，筛选维度无法确认**）；③点任一状态 tab → 切换列表；④点订单行 → 进入订单详情。
**可用角色** —— 店长 ✅ 全量；技工 ⚙️ 被授权后可查看订单（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「搜索 / 加购 / 查看订单」为 ⚙️）。
**需求关联** —— [REQ-PUR-006](#467-业务规则) 订单状态机
> **状态集合按本图修订。** V1.0 原写五状态「全部 / 待支付 / 待发货 / **已发货** / 已取消」，现状实为六个 tab：把「已发货」叫作「**待收货**」，并且多出「**已收货**」这一独立状态 —— 后者正对应 REQ-PUR-006 原文里那个没有 tab 的「（收货）完成」。[REQ-PUR-006](#467-业务规则) 与[验收标准第 4 条](#469-验收标准)已同步改为六状态。
>
> 另：**现状 tab 上不带条数角标**，而验收标准第 4 条要求「tab 计数与列表条数一致」—— 该计数是 App 侧的新增要求，接口需支持按状态返回计数。
![现状-ROOS 我的订单-待支付](../mini-program-images/ROOS/我的订单-待支付.png)
**页面内容** —— 同一页面切到「待支付」tab，搜索、筛选与六个 tab 均不变，**同样是空态**。
**关键交互** —— 与上一张图一致；本图仅用于佐证 tab 切换后页面骨架不变、六状态集合稳定。
**可用角色** —— 同上：店长 ✅、技工 ⚙️。
**需求关联** —— [REQ-PUR-006](#467-业务规则) 订单状态机
**采购订单详情**：查看订单流转状态。**本节无订单详情配图**，详情页的字段、可执行操作（取消 / 再次购买 / 申请售后的入口位置）缺少页面材料。
**售后 / 退款**：进入订单详情页面，点击「售后/退款」，进入「售后/退款」流程。
![现状-ROOS 售后退款](../mini-program-images/ROOS/售后退款.png)
**页面内容** —— ROOS「售后/退款」列表页，顶部依次为橙色提示条「退货订单将不会退回抵扣券」、售后单号搜索框与日期区间，**本截图为空态**，故售后单行的字段与状态无法从本图确认。
**关键交互** —— ①输入售后单号或销售订单号 → 检索售后单；②点「开始时间」/「结束时间」→ 选择日期区间过滤；③点售后单行 → 进入售后详情。**本页只做查询，发起售后的入口在订单详情页内**。
**可用角色** —— 店长 ✅；技工 ⚙️（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「售后 / 退款」为 ⚙️，需授权）。售后涉及退款去向，技工被授权后能否发起而非仅查看，随 `TODO(REQ-PUR-002)` 一并确认。
**需求关联** —— [REQ-PUR-018](#467-业务规则) 售后退款规则
> **本图暴露一条涉及资金、却完全未成文的规则**：「退货订单将不会退回抵扣券」—— 门店用抵扣券下单后退货，券不退回，实际损失由门店承担。V1.0 的 4.6.5 对售后只有一句「进入订单详情，点击售后/退款」，售后类型、可申请时限、退款去向（退回信用额度 / 返利 / 抵扣券）一概未定义。已新增 [REQ-PUR-018](#467-业务规则)。
>
> 另注意搜索框写的是「**销售订单号**」—— 这是 ROOS 站在**平台售货方**视角的措辞，而门店视角同一张单叫「采购订单」。整合进 App 后必须统一为门店视角，否则会与[销售模块](./03-SAL-销售.md#43-销售)的销售订单混淆。
> 采购订单的六状态（待支付 / 待发货 / 待收货 / 已收货 / 已取消 / 全部）与 O2O 销售订单的五状态（[4.3.5](./03-SAL-销售.md#435-线上订单管理)）**是两套完全不同的状态机**，UI 上必须明确区分，不可复用同一组件文案。
## 4.6.6 角色差异
| 角色 | 权限 |
| --- | --- |
| 店长 | 搜索、加购、结算、提交订单、收货、查看订单、发起售后 |
| 技工 | 默认不可见；被授权后功能同店长。是否允许技工提交订单（涉及资金）—— `TODO(REQ-PUR-002)` |
采购模块角色差异。资金相关动作（提交订单、选择返利抵扣、发起售后）在 `TODO(REQ-PUR-002)` 关闭前一律按技工不可执行实现。
## 4.6.7 业务规则
**REQ-PUR-001 采购授权** —— 技工需被显式授权才能进入采购模块；授权维度参见[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)
**REQ-PUR-002 技工下单权限** —— 技工被授权后是否可提交订单待定 `TODO(REQ-PUR-002)`。该条同时覆盖「选择返利抵扣」与「发起售后」两个资金相关动作
**REQ-PUR-003 额度校验** —— 提交订单前校验信用额度；不足时阻断并提示。**校验时机与提示内容见 [REQ-PUR-017](#467-业务规则)**
**REQ-PUR-004 支付方式** —— 由支付优先级设置决定默认扣账方式；与 CDMS 支付的关系待定 `TODO(REQ-PUR-004)`
**REQ-PUR-005 收货与入库** —— 扫码收货与扫码入库是否合并为一次动作待定 `TODO(REQ-PUR-005)`
**REQ-PUR-006 订单状态机** —— 待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消。列表 tag 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」六个，与销售订单状态机隔离
> 本条状态集合于 V1.1 按 [ROOS 我的订单截图](#465-订单管理与售后)修订：原写五状态、把「待收货」写作「已发货」且缺「已收货」。
**REQ-PUR-007 数据来源** —— 商品、价格、库存、订单、售后：马牌商品以 **ROOS** 为准，非马牌商品以 **F6** 为准；App 不落地二次计算的价格
**REQ-PUR-008 扫码实现** —— 收货扫码使用 App 原生扫码能力，不嵌入第三方 H5 扫码页
**REQ-PUR-009 车型字段来源** —— 商品的车型（`carModel`）是否取自 RMS 待确认 `TODO(REQ-PUR-009)`，见 [4.6.8](#468-业务数据列表)
**REQ-PUR-010 商品域范围** —— 采购覆盖门店需要的**全部商品**，含马牌商品与耗材、辅料、其它品牌轮胎。**只有一个采购入口**，门店在同一 tab 内按分类 / 品牌筛选，不因商品来源不同而切换页面。这是[痛点 2.1](../Continental-Retail-APP-PRD.md#21-多小程序分散)「多系统来回切换」在采购域的最后一块拼图
**REQ-PUR-011 购物车与订单是否合并** —— 马牌商品与非马牌商品能否放进同一个购物车、生成同一张订单待确认 `TODO(REQ-PUR-011)`。合并则需要跨来源的订单拆分与状态聚合；不合并则购物车与订单列表需按来源分列。**这是本模块最大的架构分歧点**
> V1.1 的实证输入：ROOS 订单确认页把一次结算按品牌拆成「订单1–德国马牌」等多张订单（见 [4.6.3](#463-购物车与结算)）。**连同属 ROOS 的两个品牌都要拆单**，因此「一个购物车 + 提交后按来源拆多张子订单 + 订单列表聚合展示」是比「真正合并成一张订单」更现实的落点，建议以此为决策起点。
**REQ-PUR-012 非马牌结算与账期** —— 非马牌采购的支付方式、信用额度与账期是否与马牌采购一致待确认 `TODO(REQ-PUR-012)`。马牌侧的信用额度与支付提醒来自 ROOS / CDMS，非马牌侧是否共用同一套额度未知
**REQ-PUR-013 接入路径** —— ROOS 建于 F6 后台之上，F6 侧本身具备采购服务能力。App Backend 是走「马牌经 ROOS、非马牌直连 F6」两条链路，还是统一经 ROOS 代理，待确认 `TODO(REQ-PUR-013)`。无论哪种，**马牌商品的采购记录必须仍然进入 ROOS** —— 品牌方按门店统计自有品牌采购情况正是 ROOS 存在的原因。这一条需优先于 [REQ-PUR-011](#467-业务规则) 确认
**REQ-PUR-014 缺货登记与到货通知** —— 商品列表中缺货商品**不置灰**，而是把加购按钮替换为「缺货登记 / 去登记」入口，门店可登记采购意向。登记后的到货通知形式（是否推送、是否自动加购、登记记录在哪里查看）未定 `TODO(REQ-PUR-014)`；缺货登记对非马牌商品是否同样可用，随 [REQ-PUR-013](#467-业务规则) 一并确认
> 本条修正了 [4.6.1](#461-需求描述) 原异常流程「商品下架/无库存 → 列表置灰」的写法：**无库存不是置灰，而是换成一个可点的登记入口**；下架商品则根本不在列表中返回。
**REQ-PUR-015 商品卡与购物车字段** —— 商品卡除[业务数据列表](#468-业务数据列表)已有字段外，还需承载：**发货仓**（截图为「浦东新仓」）、**销量**（「已售 3426」）、**库存状态标**（有货 / 库存紧张 / 库存不足 / 缺货）、**可延保标**、**配送时效标**、**商品编码**（购物车内展示）。这些字段当前均不在 4.6.8 的 10 个字段内，来源与取值集合待补 `TODO(REQ-PUR-015)`。配送时效标现状有「最快45分钟」「⏱45分钟」「⏱1小时」三种写法，App 侧须统一为一个文案模板
**REQ-PUR-016 订单确认页费用构成** —— 订单确认页按「立减 → 优惠券 → 返利抵扣 → 运费 → 信用额度」的顺序展示费用构成，并给出「优惠后订单金额」与「剩余应付合计」。其中：**运费现状为「待双方商定」**（线下协商，无金额），**返利为「请选择」**（门店主动选择本单抵扣额度）。整合后 App 内运费如何呈现与确认、返利抵扣的可选额度来源、以及是否存在独立的支付方式单选（现状**没有**）待确认 `TODO(REQ-PUR-016)`，与 [REQ-PUR-004](#467-业务规则) 一并决策
**REQ-PUR-017 额度校验时机** —— 信用额度校验必须**在提交前**完成：额度不足时「提交订单」置为不可点击，并在按钮上方直接给出**可用额度与本单金额的差额**。服务端在提交时仍需二次校验兜底，但该兜底不得成为门店感知到的唯一提示。现状为提交后弹「订单提交失败 / 账户额度不足，请联系经销商处理」，无差额、无置灰、无后续入口 —— 是否需要在提示中提供「联系经销商」的跳转或经销商联系方式待确认 `TODO(REQ-PUR-017)`
**REQ-PUR-018 售后退款规则** —— 售后单支持按售后单号 / 采购订单号检索与日期区间过滤。**已确认的资金规则：退货订单不退回抵扣券**，该规则须在门店发起售后前显式告知并留痕。售后类型（退货 / 退款 / 换货）、可申请时限、退款去向（原路退回信用额度 / 返利 / 抵扣券）、审核流程均未定义 `TODO(REQ-PUR-018)`。**页面文案须统一为门店视角**：现状 ROOS 用的是平台视角的「销售订单号」，App 内应称「采购订单号」，避免与[销售模块](./03-SAL-销售.md#43-销售)的销售订单混淆
## 4.6.8 业务数据列表
| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 商品名称 | productName | ROOS | |
| 2 | 商品编码 | productCode | ROOS | 现状购物车行内直接展示 |
| 3 | 品牌标识 | brandTag | ROOS | |
| 4 | 品牌 | brand | ROOS | 马牌 / 维京 等 |
| 5 | 单价 | price | ROOS | 不在 App 侧二次计算 |
| 6 | 计价单位 | priceUnit | ROOS | |
| 7 | 尺寸 | tireSize | ROOS | |
| 8 | 车型 | carModel | RMS | 车型匹配 `TODO(REQ-PUR-009)` |
| 9 | 安装位置 | installPositon | ROOS | 现有字段名拼写为 `installPositon`，接口对齐时需确认是否应为 `installPosition` |
| 10 | 产品分类 | productCategory | ROOS | 分类层级；是否对应前端树形控件需复核，见 [4.6.2](#462-产品搜索与商品列表) |
采购业务数据表。上表按马牌商品（ROOS）列出；非马牌商品的同名字段以 F6 为准，字段能否一一对齐随 [REQ-PUR-013](#467-业务规则) 的接入路径一并确认。
**上表尚未覆盖**截图中实际出现的以下字段，随 `TODO(REQ-PUR-015)` 补齐：发货仓、销量、库存状态、可延保标、配送时效、以及订单确认页的立减 / 优惠券 / 运费 / 返利抵扣 / 信用额度五项金额字段。
## 4.6.9 验收标准
1. 技工未被授权时，采购 tab 不下发、深链跳转也被拦截；
2. 信用额度不足时「提交订单」不可点击，且提示包含可用额度与本单金额；提交接口在服务端仍做二次校验（[REQ-PUR-017](#467-业务规则)）；
3. 购物车勾选、数量修改在弱网下不丢失，恢复网络后与后端一致；
4. 采购订单**六**状态的 tab 计数与列表条数一致；
5. 扫码收货使用原生扫码，无 WebView 加载过程；
6. 采购 tab 内可同时检索到马牌与非马牌商品，两类商品的下单、支付、收货、售后在交互上完全一致，商品来源对门店可见但不改变操作路径；
7. 门店未接入 F6 时，非马牌商品不出现在采购 tab 内且不报错，见[门店能力开关](../Continental-Retail-APP-PRD.md#74-门店能力开关)；
8. 缺货商品的卡片给出「缺货登记」入口而非置灰，登记成功后有明确反馈（[REQ-PUR-014](#467-业务规则)）；
9. 发起退货前，「退货订单不退回抵扣券」的提示对门店可见（[REQ-PUR-018](#467-业务规则)）。
> 第 2、4 条按本次逐图核看结果修订，第 8、9 条为本次新增。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.5）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 商品信息（名称/规格/型号/价格/库存/详情/参数） | Mini Program Backend | HTTPS | ROOS |
| 2 | 当前用户购物车信息数据集 | Mini Program Backend | HTTPS | 保存至 ROOS |
| 3 | 促销日历数据集 | Mini Program Backend | HTTPS | 活动数据接口待确定 |
| 4 | 结算信息结果集 | App Backend | **证书令牌** | 需调用三方接口，银行接口可能需令牌或证书 |
| 5 | 收货（扫码入库） | **原生 `native_scan`** | — | ⚠️ 前期材料写「嵌入 F6 扫码入库页面」，已按 [REQ-INT-003](../Continental-Retail-APP-PRD.md#71-访问链路原则) 校正 |
| 6 | 采购订单列表 / 采购订单详情 | Mini Program Backend | HTTPS | |
采购模块数据集（摘自主文件[附录 A.5](../Continental-Retail-APP-PRD.md#a5-采购)）。字段级清单见上方 [4.6.8](#468-业务数据列表)。
两处需要注意的对不齐：
1. **第 3 条「促销日历数据集」在正文 4.6 中没有任何对应功能。** 商品列表有「显示促销」开关、购物车有「已减 / 优惠明细」、订单确认页有「优惠券」，但都不是「促销日历」。该数据集究竟服务于采购页的哪个位置，还是应归到[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)，需在 `TODO(REQ-PUR-016)` 一并厘清。
2. **第 5 条已把「收货」与「扫码入库」并为同一数据集**，实际上给 `TODO(REQ-PUR-005)`（两者是否合并）预设了答案。正文仍按未定处理，两处口径需在该 TODO 关闭时统一。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 搜索 / 加购 / 查看订单 | ✅ | ⚙️ | 技工需被授权 |
| **提交订单**（涉及资金） | ✅ | ❓ | `TODO(REQ-PUR-002)` |
| 收货 | ✅ | ⚙️ | |
| 售后 / 退款 | ✅ | ⚙️ | 能否**发起**（而非仅查看）随 `TODO(REQ-PUR-002)` 一并确认 |
采购模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本次拆分发现矩阵**漏了一行**：订单确认页的「**选择返利抵扣**」同样是动用门店资金的动作，且与「提交订单」可分离（可以允许技工提交但不允许选返利）。回灌主文件附录 B 时建议单列一行，取值随 `TODO(REQ-PUR-002)`。
### 附-3 待确认项（主文件 10.2.6 + 本次新增）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-PUR-002 | 技工被授权后是否可提交订单（涉及资金） | 业务 |
| REQ-PUR-004 | 支付方式与 CDMS 支付的关系 | 财务 / 架构 |
| REQ-PUR-005 | 扫码收货与扫码入库是否合并为一次动作 | 业务 |
| REQ-PUR-009 | 车型字段（carModel）是否取自 RMS | 架构 |
| REQ-PUR-011 | **马牌与非马牌商品是否共用购物车与订单**（合并需跨来源拆单与状态聚合） | 架构 / 产品 |
| REQ-PUR-012 | 非马牌采购的支付方式、信用额度与账期是否与马牌一致 | 业务 / 财务 |
| REQ-PUR-013 | **非马牌商品是直连 F6 还是经 ROOS 代理**（需保证马牌采购记录仍进 ROOS） | 架构 / F6 |
| **REQ-PUR-014** | 缺货登记后的到货通知形式、登记记录的查看入口；非马牌商品是否同样支持 | 产品 / 业务 |
| **REQ-PUR-015** | 发货仓 / 销量 / 库存状态 / 可延保标 / 配送时效 / 商品编码的来源与取值集合；时效文案统一模板 | 业务 / 架构 |
| **REQ-PUR-016** | 运费「待双方商定」在 App 内如何呈现与确认；返利抵扣的可选额度来源；**是否存在独立的支付方式单选**（现状没有） | 财务 / 产品 |
| **REQ-PUR-017** | 额度不足的提示中是否提供「联系经销商」跳转或联系方式 | 业务 |
| **REQ-PUR-018** | 售后类型、可申请时限、退款去向（信用额度 / 返利 / 抵扣券）与审核流程 | 业务 / 财务 |
采购模块待确认项，共 12 条（主文件 [10.2.6](../Continental-Retail-APP-PRD.md#1026-采购pur) 原 7 条 + 本次新增 5 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.6，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 PUR 行（13 / 7 / 46% → 18 / 12 / 33%）与第 10.2 节总数。
### 附-4 配图清单（主文件附录 C 4.6 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-订单管理商品列表（规格 + 黑科技筛选、有货/促销开关、品牌下拉、4 张同款占位卡、缺货卡「去登记」） | `../app-design-images/订单管理-商品列表.png` |
| 2 | 现状-ROOS 商品选择（同构筛选、可延保 / 时效标、库存紧张 / 不足、缺货登记、ROOS 自身 tabbar） | `../mini-program-images/ROOS/商品选择.png` |
| 3 | 设计稿-订单管理购物车（按品牌分组、合计 / 已减 / 优惠明细 / 结算） | `../app-design-images/订单管理-购物车.png` |
| 4 | 现状-ROOS 购物车（共 1 件、编辑态入口、行内展示商品编码、⏱1小时） | `../mini-program-images/ROOS/购物车.png` |
| 5 | 现状-ROOS 订单确认（**测试地址数据**；订单按品牌拆为「订单1–德国马牌」；立减 / 优惠券 / 运费待双方商定 / 返利请选择 / 信用额度不可用；**无支付方式选择器**） | `../mini-program-images/ROOS/订单确认.png` |
| 6 | 现状-ROOS 订单确认额度不足（**提交后**弹「订单提交失败 / 账户额度不足，请联系经销商处理」，单按钮「我知道了」） | `../mini-program-images/ROOS/订单确认-额度不足提示.png` |
| 7 | 现状-ROOS 我的订单全部（**空态**；搜索 + 筛选；**六状态 tab**：全部/待支付/待发货/待收货/已收货/已取消） | `../mini-program-images/ROOS/我的订单-全部.png` |
| 8 | 现状-ROOS 我的订单待支付（**空态**；佐证 tab 切换后骨架不变） | `../mini-program-images/ROOS/我的订单-待支付.png` |
| 9 | 现状-ROOS 售后退款（**空态**；橙色提示条「退货订单将不会退回抵扣券」；按售后单号 / 销售订单号 + 日期区间检索） | `../mini-program-images/ROOS/售后退款.png` |
采购模块配图清单，9 张（设计稿 2 / 现状-ROOS 7）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
**本模块配图的两处硬缺口**：
- **9 张图里有 3 张是空态**（第 7、8、9 张），1 张是重复占位数据（第 1 张），1 张是脏测试数据（第 5 张）。订单行、售后单行的实际字段与操作按钮**全部无法从现有材料确认**，建议向有真实订单的门店账号补采截图。
- **收货流程与订单详情页完全没有配图**（既无设计稿也无现状截图）。收货确认页是否逐条核对、能否部分收货、拒收如何记录，以及订单详情页的可执行操作，目前没有任何页面材料支撑 —— 这两处直接影响 `TODO(REQ-PUR-005)` 的决策，建议优先补稿。
### 附-5 本次拆分新增发现
逐张核看 9 张配图后，新增 **5 条编号需求**（REQ-PUR-014 ~ 018）、**修订 3 处既有内容**、另记 **3 条无编号观察**。
**新增需求**：
| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-PUR-014 | 缺货登记与到货通知 | 设计稿与 ROOS 商品列表的缺货卡都给「去登记 / 缺货登记」按钮，而非正文写的「置灰」 |
| REQ-PUR-015 | 商品卡与购物车字段 | 发货仓「浦东新仓」、销量「已售 3426」、可延保标、时效标、商品编码均不在 4.6.8 的 10 个字段内 |
| REQ-PUR-016 | 订单确认页费用构成 | 现状为「立减 / 优惠券 / 运费待双方商定 / 返利请选择 / 信用额度」，**没有支付方式选择器** |
| REQ-PUR-017 | 额度校验时机 | 现状是提交后弹失败框，与 REQ-PUR-003「提交前校验」及验收标准第 2 条冲突 |
| REQ-PUR-018 | 售后退款规则 | 「退货订单将不会退回抵扣券」是一条涉及资金、却完全未成文的规则 |
**修订的既有内容**：
1. **[REQ-PUR-006](#467-业务规则) 订单状态机由五状态改为六状态** —— 现状 tab 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」；原文把「待收货」写作「已发货」，且漏掉了「已收货」。同步改了 [4.6.1](#461-需求描述) 的状态变化、[4.6.5](#465-订单管理与售后) 正文与[验收标准第 4 条](#469-验收标准)。
2. **[4.6.2](#462-产品搜索与商品列表) 的「左侧树形分类」描述被两张图否定** —— 实际是顶部平铺筛选 + 单列商品卡，无分类树。正文已改，`productCategory` 的「树形分类」备注也需复核。
3. **[4.6.1](#461-需求描述) 异常流程「商品下架/无库存 → 列表置灰」拆成两条** —— 无库存换成「缺货登记」入口，下架商品不在列表返回。
**无编号观察**（属现状材料或设计稿状态问题，不新增需求）：
1. **配送时效标有三种写法** —— 「最快45分钟」「⏱45分钟」「⏱1小时」，App 侧需统一文案模板，已并入 REQ-PUR-015。
2. **购物车设计稿的「德国马牌 / 维京轮胎」分组不能证明 [REQ-PUR-011](#467-业务规则) 已解决** —— 两者同属 ROOS，真正的分歧是 ROOS 与 F6 商品能否共用购物车，图中未涉及。但订单确认页「订单1–德国马牌」说明 ROOS 内部**已按品牌拆单**，这是决策的重要实证输入。
3. **售后页搜索框用的是平台视角的「销售订单号」** —— 门店视角同一张单叫「采购订单」，整合进 App 后须统一措辞，否则与[销售模块](./03-SAL-销售.md#43-销售)的销售订单混淆。已写入 REQ-PUR-018。
另有一条给主文件附录 B 的建议：**补一行「选择返利抵扣」** —— 该动作动用门店资金且可与「提交订单」分离授权，现有矩阵未覆盖，见[附-2](#附-2-权限矩阵主文件附录-b-本模块分行)。
prd/modules/07-INV-库存.md
+296
View File
@@ -0,0 +1,296 @@
# 4.7 库存
> **本文件是【库存 INV】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.7 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | INV |
| V1.0 章节 | 4.7 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状截图反推 |
| 现状承载系统 | O2O（库存查询、扫码入库）+ ROOS（条码库存、扫码出库） |
| 需求条数 | 11（待确认 9，完成度 18%） |
| 本次新增待确认 | 4（REQ-INV-008 / 009 / 010 见[附-5](#附-5-本次拆分新增发现待业务确认)；REQ-INV-011 见[附-1](#附-1-业务数据字典主文件附录-a)） |
| 配图 | 12 张（设计稿 1 / 现状-O2O 9 / 现状-ROOS 2） |
模块概要
---
> 底部导航的三版方案中，业务菜单版有「库存」tab、设计稿 5 tab 方案有「入库」tab（见[三版底部导航方案](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）。本节内容由现状截图反推。
**业务目标** —— 把「查得到货、扫得进库、对得上账」收敛到 App 内，解决[痛点 2.3](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)中「门店无法实时判断可售库存」的问题
**入口** —— 底部导航「库存 / 入库」tab；首页快捷入口「扫码入库」「扫码出库」；采购收货流程
**页面内容** —— 库存查询（SKU 列表 + 四级轮胎参数筛选）、扫码入库记录、扫码出库、条码库存（入库记录 / 出库记录 / 在库条码）
**主流程**：
- 查询：选择搜索类型 → 输入关键字或逐级筛选 → 查看 SKU 库存状态与结算价
- 入库：扫描轮胎条码 → 校验 → 写入在库条码 → 生成入库记录
**权限规则** —— 店长全量；技工可查询与扫码入/出库，`TODO(REQ-INV-001)` 确认技工是否可见结算价
**数据来源** —— O2O（库存查询、扫码入库）、ROOS（条码库存、扫码出库）
## 4.7.1 库存查询
![设计稿-库存查询](../app-design-images/库存查询.png)
**页面内容** —— App 目标形态：搜索框 + 一行**五个**下拉筛选（胎面宽 / 扁平比 / 直径 / 花纹 / **黑科技**），主体为 SKU 卡片列表，卡上含库存状态标签与小程序结算价（稿中含普利司通 / 米其林 / 倍耐力，规格与级别为占位数据）。
**关键交互** —— ①点搜索框输入关键字 → 检索；②点五个下拉任一 → 展开取值面板，逐级收窄；③上下滑动卡片列表。稿中**未画**搜索类型切换、未画筛选重置入口、未画分页或上拉加载。
**可用角色** —— 店长 ✅ 全量；技工 ✅ 可查询。卡片右下「小程序结算价」对技工是否可见未定 `TODO(REQ-INV-001)`——若判定不可见，本卡片布局需出一版无价格的技工态。
**需求关联** —— [REQ-INV-002](#474-业务规则) SKU 与产品编码、[REQ-INV-003](#474-业务规则) 库存状态覆盖、[REQ-INV-004](#474-业务规则) 筛选维度
![现状-O2O 库存查询](../mini-program-images/O2O/库存查询.png)
**页面内容** —— O2O 小程序现状：搜索行为「搜索类型下拉 + 输入框 + 搜索按钮」三段式，筛选行只有**四个**（无黑科技），列表为通栏分隔行含产品编码、库存状态、商品名与小程序结算价，**本图为测试环境数据**（编码多值且被截断、库存状态列大多为空）。
**关键交互** —— ①点「产品信息 ▾」→ 切换搜索类型（见下一张图）；②输入关键字点「搜索」→ 检索；③点四个筛选任一 → 展开取值面板；④上下滑动列表。
**可用角色** —— 店长 ✅；技工 ✅ 可查询，结算价可见性待定 `TODO(REQ-INV-001)`。
**需求关联** —— [REQ-INV-002](#474-业务规则)（一行多编码正是本图实证）、[REQ-INV-003](#474-业务规则)（库存状态大面积为空正是本图实证）、[REQ-INV-004](#474-业务规则)（促销标签的去留）
![现状-O2O 库存查询-搜索类型选择](../mini-program-images/O2O/库存查询-搜索类型选择.png)
**页面内容** —— 「产品信息」下拉的展开态，浮层给出**产品信息**（当前选中）与**产品code** 两个搜索类型，其余区域被遮罩。
**关键交互** —— ①点搜索行「产品信息 ▾」→ 展开 / 收起本浮层；②选「产品信息」→ 按商品名称检索；③选「产品code」→ 按产品编码检索；④点遮罩区 → 收起浮层。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-INV-002](#474-业务规则)——现状把「产品信息」与「产品code」做成两种并列的搜索类型，正是「主键到底是 SKU 还是产品编码」这一口径问题在交互层的外显；App 若统一为 SKU，这个下拉是保留还是取消需一并裁决。
**四级轮胎参数筛选**：胎面宽、扁平比、直径、花纹逐级收窄。以下四张图为四级筛选各自展开后的取值面板。
![现状-O2O 库存查询-筛选胎面宽](../mini-program-images/O2O/库存查询-筛选胎面宽.png)
**页面内容** —— 「胎面宽」的展开态，面板为 4 列 chip 网格、实测 20 项取值（`0`、`13`、`175`…`325`），底部并排「重置」「确认」。
**关键交互** —— ①点 chip 选取值（**单选还是多选本图无法确认**，图中无任何 chip 处于选中态）；②「重置」清空本级已选；③「确认」应用筛选并收起面板；④点遮罩收起。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-INV-004](#474-业务规则)；取值中的 `0` 与 `13` 不是合法胎面宽 → [REQ-INV-008](../Continental-Retail-APP-PRD.md#1027-库存inv)
![现状-O2O 库存查询-筛选扁平比](../mini-program-images/O2O/库存查询-筛选扁平比.png)
**页面内容** —— 「扁平比」的展开态，结构同上但取值远多于胎面宽（首屏可数 60 余项且可继续滚动，第 2、3 项即为 `ssss` 和 `测试`），**本图底部被截断**未拍到按钮。
**关键交互** —— ①上下滚动取值网格；②点 chip 选取值；③滚到底部使用重置 / 确认（本图未拍到该区域）。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-INV-004](#474-业务规则)；取值含 `ssss`、`测试` 两个非数值项，且 `107` / `120` / `255` 等远超乘用车胎扁平比常见区间（约 25–80）→ [REQ-INV-008](../Continental-Retail-APP-PRD.md#1027-库存inv)
![现状-O2O 库存查询-筛选直径](../mini-program-images/O2O/库存查询-筛选直径.png)
**页面内容** —— 「直径」的展开态，结构同前两级，取值同样 60 余项且可滚动（**首项即 `测试`**），底部截断。
**关键交互** —— 同扁平比：滚动网格 → 点 chip 选取值 → 底部重置 / 确认。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-INV-004](#474-业务规则)；**列表首项即为 `测试`**，且含 `348` 等远超乘用车轮辋直径区间（13–24 英寸）的取值 → [REQ-INV-008](../Continental-Retail-APP-PRD.md#1027-库存inv)
![现状-O2O 库存查询-筛选花纹](../mini-program-images/O2O/库存查询-筛选花纹.png)
**页面内容** —— 「花纹」的展开态，4 列 chip 网格完整拍到全部 42 项取值，超长名称在 chip 内以 `…` 截断。
**关键交互** —— ①点 chip 选取值；②「重置」/「确认」；③点遮罩收起。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-INV-004](#474-业务规则)；本图是四级筛选数据质量问题最集中的一张 → [REQ-INV-008](../Continental-Retail-APP-PRD.md#1027-库存inv)：测试残留（`bang123`、`cpsx`、`测试`、`自动化测试`、`CPC2自动…`、`CC7item` / `CSC5 item` / `MC6 item`）、疑似重复（`CCC LX2` 与 `CCCLX2`、`UC6 SUV` 出现两次）、字段串位（`123/45R` / `17` / `195/55R` 是规格串误入花纹字段）、以及长名截断导致的不可辨识。
**现状与目标的三处差异**（均需确认）：
| # | 现状（O2O） | 设计稿（App） | 说明 |
| --- | --- | --- | --- |
| 1 | 主键是**产品编码**，且一行可能是逗号分隔的多个编码 | 主键是 **SKU** | 两者是否同一概念、多编码如何在 SKU 视图下展示 —— `TODO(REQ-INV-002)` |
| 2 | 「库存状态」一列大多为空/置灰，仅个别显示「库存充足」 | 每条都有库存充足 / 紧张 / 缺货标签 | 库存状态数据是否已具备全量覆盖能力 —— `TODO(REQ-INV-003)` |
| 3 | 无「黑科技」筛选，有「促销」标签 | 有「黑科技」筛选，无促销标签 | 两个维度是否都保留 —— `TODO(REQ-INV-004)` |
库存查询现状与目标差异
## 4.7.2 扫码入库
![现状-O2O 扫码入库](../mini-program-images/O2O/扫码入库.png)
**页面内容** —— 入库**记录查询页**（非扫码页），筛选行为日期区间 `2026.04.01–2026.04.27` + 品牌下拉（**图中已选中「马牌」**），其下是橙色汇总条「总入：0 条」，**本图为空态**故记录行的字段构成无法确认。
**关键交互** —— ①点日期区间 → 打开日期筛选浮层（见下方第二张图）；②点品牌下拉 → 展开品牌筛选（见下方第一张图）；③汇总条「总入：N 条」随筛选条件变化；④页面本身**未见扫码按钮**——本页是入库**记录查询页**，扫码动作的入口在 O2O 首页而非此处。
**可用角色** —— 店长 ✅ 全量；技工 ✅ 可扫可查（一线高频操作）。
**需求关联** —— [REQ-INV-005](#474-业务规则) 入库写入目标、[REQ-INV-006](#474-业务规则) 扫码由 App 原生实现、[REQ-INV-007](#474-业务规则) 重复条码拒绝
![现状-O2O 扫码入库-筛选品牌](../mini-program-images/O2O/扫码入库-筛选品牌.png)
**页面内容** —— 品牌下拉的展开态，三个选项：`全部品牌` / `马牌`（✓ 当前选中）/ `维京`。
**关键交互** —— ①点品牌下拉 → 展开 / 收起；②点选项 → **单选**切换，选中项右端显示 ✓；③点遮罩 → 收起。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— 品牌可选值只有马牌与维京两个 Continental 集团品牌，而 [4.7.1](#471-库存查询) 的库存查询里出现普利司通 / 米其林 / 倍耐力——两者覆盖范围不同，佐证「入库」与「库存查询」在现状下是两套口径不一致的数据，是 [REQ-INV-005](#474-业务规则) 需要一并裁决的部分。
![现状-O2O 扫码入库-自定义日期筛选](../mini-program-images/O2O/扫码入库-自定义日期筛选.png)
**页面内容** —— 日期区间的展开态，浮层有「月份选择」「自定义」两个 tab（当前停在**自定义**），其下为两个日期输入框构成区间，底部并排「全部日期」「确认」。
**关键交互** —— ①切换「月份选择」/「自定义」两种取期模式；②点任一日期框 → 唤起日期选择器；③「全部日期」→ 取消区间限制，查全部；④「确认」→ 应用区间并收起。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— —（仅作现状佐证）。App 整合后是否保留「月份选择 / 自定义」双模式，随 [REQ-INV-005](#474-业务规则) 的入库页形态一并确定。
## 4.7.3 扫码出库与条码库存
![现状-ROOS 首页-扫码出库操作选择弹窗](../mini-program-images/ROOS/首页-扫码出库操作选择弹窗.png)
**页面内容** —— ROOS 首页扫码后弹出的模态弹窗「请选择需要执行的操作」，底部两个并排按钮 **「去延保」** 与 **「直接出库」**，背景可见 ROOS 首页与四宫格互跳入口，标题栏写明「MF ROOS **UAT 测试环境**」。
**关键交互** —— ①在 ROOS 首页点扫码入口扫描轮胎条码 → 弹出本弹窗；②点「去延保」→ 携该条码进入延保建单流程；③点「直接出库」→ 仅登记出库、不建延保单；④弹窗**未提供取消或关闭按钮**，能否点遮罩关闭本图无法确认。
**可用角色** —— 店长 ✅；技工 ✅（扫码出库属一线高频操作）。但「去延保」分支会创建延保单，而延保建单对技工是否开放尚未定 `TODO(REQ-WTY-003)`——**两处口径必须对齐**，否则会出现「技工能出库却在弹窗第二步被拦」的断流。
**需求关联** —— [REQ-INV-005](#474-业务规则)、[REQ-INV-006](#474-业务规则)；**出库时的「去延保 / 直接出库」二选一分支是本模块与[延保](./05-WTY-延保.md)的关键衔接点，现有 7 条需求中没有任何一条描述它** → [REQ-INV-009](../Continental-Retail-APP-PRD.md#1027-库存inv)
**条码库存**：在「我的」菜单中点击「条码库存」，进入「条码库存」，tab 为**入库记录、出库记录、在库条码**。
![现状-ROOS 条码库存-入库记录](../mini-program-images/ROOS/条码库存-入库记录.png)
**页面内容** —— 条码库存页：橙色头部含搜索框与一个独立的扫码图标，其下三个 tab（**入库记录**选中 / 出库记录 / 在库条码）与筛选行 品牌 / 选择日期 / **是否有效**，**本图为空态**故记录行的字段构成无法确认。
**关键交互** —— ①切换入库记录 / 出库记录 / 在库条码三个 tab；②搜索框按商品编号或名称检索；③点右侧扫码图标 → 扫码直接定位条码；④三个下拉分别按品牌、日期、有效性筛选；⑤「清除筛选」一键复位全部筛选条件。
**可用角色** —— 店长 ✅ 全量；技工 ✅ 可查。本页在 ROOS 中的入口位于「我的」菜单下，App 整合后入口位置需随[导航收敛](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)重新安排。
**需求关联** —— [REQ-INV-005](#474-业务规则) 入库写入目标、[REQ-INV-007](#474-业务规则) 重复条码；「**是否有效**」这个筛选维度说明条码存在**有效 / 失效（作废）**两种状态，而现有需求未定义该状态、也未定义谁能作废条码 → [REQ-INV-010](../Continental-Retail-APP-PRD.md#1027-库存inv)
> **入库来源双写问题**：扫码入库在 O2O 和 ROOS 两侧都有记录（O2O 的「扫码入库」与 ROOS 的「条码库存-入库记录」），[经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)同时统计「扫码入库总数」与「扫码入库门店数」。整合后是一次扫码双写、还是以其中一侧为准 —— `TODO(REQ-INV-005)`，这是本模块的关键前置决策。
## 4.7.4 业务规则
**REQ-INV-001 结算价可见性** —— 技工是否可见小程序结算价待定 `TODO(REQ-INV-001)`
**REQ-INV-002 SKU 与产品编码** —— 主键口径待统一 `TODO(REQ-INV-002)`
**REQ-INV-003 库存状态覆盖** —— 库存状态标签的数据覆盖率与刷新频率待定 `TODO(REQ-INV-003)`
**REQ-INV-004 筛选维度** —— 黑科技 / 促销两个维度的取舍待定 `TODO(REQ-INV-004)`
**REQ-INV-005 入库写入目标** —— 扫码入库的权威写入目标待定 `TODO(REQ-INV-005)`
**REQ-INV-006 扫码实现** —— 入库/出库扫码均为 App 原生实现（[REQ-INT-003](../Continental-Retail-APP-PRD.md#73-f6-集成边界)）
**REQ-INV-007 重复条码** —— 同一条码重复扫描应拒绝并提示已入库时间与门店
**REQ-INV-008 筛选取值清洗** —— 品牌 / 花纹 / 规格 / 级别四级筛选的取值直接取自库存主数据，现状含测试残留、越界值、疑似重复与字段串位。App 是照搬现状取值还是由后端出清洗后的枚举，待定 `TODO(REQ-INV-008)`
**REQ-INV-009 扫码出库的延保分支** —— 现状扫码出库后弹窗强制在「去延保 / 直接出库」二选一，是库存与[延保](./05-WTY-延保.md#45-延保)的衔接点。App 是否保留该弹窗、传递哪些参数、技工能否走「去延保」，待定 `TODO(REQ-INV-009)`
**REQ-INV-010 条码有效性状态** —— 条码存在有效 / 失效两态，其流转规则、作废权限、作废后能否重新入库，以及与 REQ-INV-007 重复校验的关系待定 `TODO(REQ-INV-010)`
**REQ-INV-011 字段清单缺失** —— [附录 A](../Continental-Retail-APP-PRD.md#附录-a-业务数据字典) 未收录本模块的字段清单，需业务补齐后再定接口契约 `TODO(REQ-INV-011)`
## 4.7.5 验收标准
1. 四级参数筛选任意组合下，列表结果与筛选条件一致，清空筛选可一键还原；
2. 同一条码重复扫描时给出明确提示，不产生重复入库记录；
3. 扫码入库在断网时可暂存，恢复网络后批量提交且不重复；
4. 库存状态标签与结算价来自同一次查询，不出现价格已更新而状态未更新的错位。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A）
**主文件[附录 A 业务数据字典](../Continental-Retail-APP-PRD.md#附录-a-业务数据字典)未收录本模块。** 附录 A 现有 A.1 登录、A.2 首页、A.3 销售、A.4 提醒、A.5 采购、A.6 延保、A.7 门店管理、A.8 经营分析与财务、A.9 个人中心共 9 节，库存（INV）无对应节。
本模块涉及的字段（SKU / 产品编码、库存状态、小程序结算价、胎面宽 / 扁平比 / 直径 / 花纹、条码、入库时间、操作人、条码有效性等）目前散落在正文与截图中，**未形成字段清单，也未标注权威数据来源**。此处不自行编造字段表，需业务与架构补充 —— `TODO(REQ-INV-011)`。
同样缺失的还有返利中心（RBT）、营销与会员（MKT）、福利兑换（MSP）三个模块，见 [`README.md` 待办](./README.md#状态与待办)。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 库存查询 | ✅ | ✅ | |
| 查看小程序结算价 | ✅ | ❓ | `TODO(REQ-INV-001)` |
| 扫码入库 / 出库 | ✅ | ✅ | 一线高频操作 |
库存模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本模块新增的三条待确认项也各带权限口径：[REQ-INV-009](#附-5-本次拆分新增发现待业务确认) 的「去延保」分支须与延保建单权限 `TODO(REQ-WTY-003)` 对齐；[REQ-INV-010](#附-5-本次拆分新增发现待业务确认) 的条码作废属高风险操作，建议默认仅店长。
### 附-3 待确认项（主文件 10.2.7）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-INV-001 | 技工是否可见小程序结算价 | 业务 |
| REQ-INV-002 | SKU 与产品编码的口径统一（一行多编码如何呈现） | 业务 / 架构 |
| REQ-INV-003 | 库存状态标签的数据覆盖率与刷新频率 | 业务 |
| REQ-INV-004 | 「黑科技」与「促销」两个筛选维度的取舍 | 产品 |
| REQ-INV-005 | **扫码入库的权威写入目标（O2O / ROOS / 双写）** | 架构 |
库存模块待确认项（摘自主文件 [10.2.7](../Continental-Retail-APP-PRD.md#1027-库存inv)，5 条）
**本次拆分新增 4 条**（回灌主文件时并入 10.2.7）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| **REQ-INV-008** | **四级筛选取值需数据清洗** —— 现状取值含测试残留、越界值、疑似重复与字段串位，详见[附-5](#附-5-本次拆分新增发现待业务确认) | 业务 / 架构 |
| **REQ-INV-009** | **扫码出库的「去延保 / 直接出库」分支** —— 本模块与延保模块的衔接点，现有需求完全未描述 | 产品 / 业务 |
| **REQ-INV-010** | **条码有效性状态** —— 有效 / 失效（作废）两态的流转规则、作废权限与重新入库规则均未定义 | 业务 / 架构 |
| **REQ-INV-011** | **本模块字段清单缺失** —— 主文件附录 A 无库存节，字段与权威数据来源需业务与架构补齐，详见[附-1](#附-1-业务数据字典主文件附录-a) | 业务 / 架构 |
合计 9 条待确认（原 5 条 + 新增 4 条）。回灌时需同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 INV 行（7 / 5 / 29% → 11 / 9 / 18%）与第 10.2 节总数。
### 附-4 配图清单（主文件附录 C 4.7 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-库存查询（App 目标形态，五级筛选 + SKU 卡片） | `../app-design-images/库存查询.png` |
| 2 | 现状-O2O 库存查询（四级筛选 + 通栏行，多编码 / 库存状态空缺） | `../mini-program-images/O2O/库存查询.png` |
| 3 | 现状-O2O 库存查询（搜索类型选择：产品信息 / 产品code） | `../mini-program-images/O2O/库存查询-搜索类型选择.png` |
| 4 | 现状-O2O 库存查询（筛选胎面宽，20 项取值 + 重置/确认） | `../mini-program-images/O2O/库存查询-筛选胎面宽.png` |
| 5 | 现状-O2O 库存查询（筛选扁平比，含 `ssss` / `测试` 脏值） | `../mini-program-images/O2O/库存查询-筛选扁平比.png` |
| 6 | 现状-O2O 库存查询（筛选直径，首项即 `测试`） | `../mini-program-images/O2O/库存查询-筛选直径.png` |
| 7 | 现状-O2O 库存查询（筛选花纹，42 项，脏值 / 重复 / 串位最集中） | `../mini-program-images/O2O/库存查询-筛选花纹.png` |
| 8 | 现状-O2O 扫码入库（空态，日期区间 + 品牌筛选 +「总入：N 条」汇总条） | `../mini-program-images/O2O/扫码入库.png` |
| 9 | 现状-O2O 扫码入库（筛选品牌：全部品牌 / 马牌 ✓ / 维京） | `../mini-program-images/O2O/扫码入库-筛选品牌.png` |
| 10 | 现状-O2O 扫码入库（自定义日期筛选，月份选择 / 自定义双 tab） | `../mini-program-images/O2O/扫码入库-自定义日期筛选.png` |
| 11 | 现状-ROOS 首页扫码出库（「去延保 / 直接出库」操作选择弹窗，UAT 环境） | `../mini-program-images/ROOS/首页-扫码出库操作选择弹窗.png` |
| 12 | 现状-ROOS 条码库存（入库记录 tab，空态，含「是否有效」筛选） | `../mini-program-images/ROOS/条码库存-入库记录.png` |
库存模块配图清单，12 张（设计稿 1 / 现状-O2O 9 / 现状-ROOS 2）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
### 附-5 本次拆分新增发现（待业务确认）
以下三条**不在主文件现有 7 条 INV 需求内**，是本次逐张核看 12 张截图时发现的、现有需求未覆盖的事项。编号接 REQ-INV-007 顺延，**尚未登记进主文件 10.2.7**，回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。
| 编号 | 待确认内容 | 证据 | 建议决策方 |
| --- | --- | --- | --- |
| REQ-INV-008 | **四级筛选取值需数据清洗**：现状取值直接取自库存主数据未做清洗，含测试残留（`ssss`、`测试`、`自动化测试`、`bang123`、`cpsx`、`CPC2自动…`、`*item`）、越界值（扁平比 `107`/`120`/`255`，直径 `348`，胎面宽 `0`/`13`）、疑似重复（`CCC LX2` vs `CCCLX2`、`UC6 SUV` ×2）、字段串位（`123/45R`、`195/55R` 落入花纹）。App 是照搬现状取值，还是由后端出清洗后的枚举？超长花纹名的截断展示如何处理？ | 本节图 4–7 | 业务 / 架构 |
| REQ-INV-009 | **扫码出库的「去延保 / 直接出库」分支**：ROOS 扫码出库后弹窗强制二选一，该分支是本模块与延保模块的衔接点，现有需求完全未描述。App 是否保留该弹窗？「去延保」传递哪些参数？技工能否走「去延保」（需与 `TODO(REQ-WTY-003)` 对齐）？弹窗能否取消？ | 本节图 11 | 产品 / 业务 |
| REQ-INV-010 | **条码有效性状态**：ROOS 条码库存有「是否有效」筛选，说明条码存在有效 / 失效（作废）两态。该状态的流转规则、谁有权作废、作废后是否可重新入库、与 [REQ-INV-007](#474-业务规则) 重复条码校验的关系均未定义。 | 本节图 12 | 业务 / 架构 |
本次拆分新增待确认项，3 条
> 另有一项非需求性观察：本模块 12 张截图中，`库存查询`、`库存查询-搜索类型选择` 的列表、以及 `首页-扫码出库操作选择弹窗`（标题栏写明「MF ROOS UAT 测试环境」）均取自**测试环境且含测试数据**，`扫码入库` 与 `条码库存-入库记录` 为**空态**。这些截图可用于确认页面结构与控件，**不可用于推断线上真实数据形态与字段取值**。
prd/modules/08-MIN-我的.md
+441
View File
@@ -0,0 +1,441 @@
# 4.8 我的 / 个人中心
> **本文件是【我的 MIN】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.8 节已于 2026-08 从本文件回灌（V1.1），
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**
| 项 | 值 |
| --- | --- |
| 模块码 | MIN |
| V1.0 章节 | 4.8 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 设计稿 1 张 + 三套现状小程序截图反推 |
| 现状承载系统 | ROOS + O2O + 延保 |
| 需求条数 | 14（待确认 13，完成度 7%） |
| 配图 | 16 张（设计稿 1 / 现状-ROOS 7 / 现状-O2O 5 / 现状-延保 3） |
> **本节的来历：V1.0 的 4.8 没有「业务规则」小节。**
> 六个 `REQ-MIN-001` ~ `REQ-MIN-006` 编号全部只以 `TODO(...)` 标记的形式散落在正文与合并规则表中，
> **没有任何一条成文规则**，这正是附录 D.2 中 MIN 完成度为 0% 的直接原因（14 个模块里唯一的 0%）。
> V1.1 补入 [4.8.6 业务规则](#486-业务规则)，V1.0 的「4.8.6 验收标准」顺延为 [4.8.7](#487-验收标准)。
三套现状小程序各有一个「我的」，本节将其合并为 App 的统一个人中心。
**业务目标** —— 提供统一的账号、门店、资产（额度/返利/优惠券/积分）与设置入口，取代三套小程序各自的「我的」
**入口** —— 底部导航「我的」tab
**页面内容** —— 用户信息卡（头像/姓名/门店/角色标签）+ 资产卡（积分、优惠券）+ 功能列表 + 退出登录
**主流程** —— 进入个人中心 → 查看资产 / 进入子功能 → 返回
**权限规则** —— 全角色可见；资产类（额度、返利、对账单）建议限店长 `TODO(REQ-MIN-002)`
**数据来源** —— App Backend（账号、门店）、ROOS（账户、优惠券、地址、收藏、支付优先级）、O2O（设置、手机号）、延保后台（姓名、门店）
---
## 4.8.1 目标形态
![设计稿-个人中心](../app-design-images/个人中心.png)
**页面内容** —— App 个人中心的目标形态：顶部橙色用户卡（头像、账号名、门店名、金黑配色的「⭐ 店长」角色标签），下方并排两张资产卡（积分 460 / 优惠券 56），再下是 6 项功能列表，底部为描边样式的「退出登录」。
**关键交互** —— ①点击右上角设置图标 → 进入设置页（**设计稿未定义该页内容**）；②点击「积分 460」「优惠券 56」→ 资产二级页（**卡片上未见 `>` 或箭头，是否可下钻本图无法确认**）；③点击功能列表任一项（服务热线 / 经销商客服 / 地址管理 / 我的收藏 / 经营范围 / 换绑手机）→ 进入对应二级页；④点击「退出登录」→ 二次确认弹窗。
**可用角色** —— 店长 ✅ 全量；技工 ✅ 可见页面，但资产卡与部分功能项受限（[附-2](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）。角色标签由后台下发，技工不显示店长专属资产项。
**需求关联** —— `TODO(REQ-MIN-001)` 个人中心保留哪 6 项、[REQ-MIN-016](#486-业务规则) 关于 / 版本号入口、[REQ-MIN-020](#486-业务规则) 头像首版只读
> 设计稿的功能列表**只有 6 项**，而三套现状小程序的「我的」合计有 20 余项。哪些进个人中心、哪些下沉到各业务模块 —— `TODO(REQ-MIN-001)`。本节先按域完整记录现状，作为取舍的输入。
> **设计稿与其它章节的三处冲突，须一并解决：**
> 1. 资产卡只有**积分**与**优惠券**两项，**额度与返利没有位置**，而 4.8.5 合并规则表写的是「我的账户（额度/返利/券/积分）→ 个人中心资产卡 + 二级页」，附录 B 的权限行也是四项一起管控 —— 四项资产如何在两张卡里落位未定，见 [REQ-MIN-009](#486-业务规则)。
> 2. 优惠券在设计稿上是 **56**（像张数），而 ROOS 现状展示的是**优惠券总金额 ¥0.00**（金额）—— 口径不同，见 [REQ-MIN-009](#486-业务规则)。
> 3. 设计稿把「退出登录」放在个人中心主页面，O2O 现状放在二级「设置」页内 —— 本 PRD 以设计稿为准（见 4.8.5 合并规则表）。
> 另：设计稿底部导航为 **首页 / 入库 / 采购 / 延保 / 我的**，与 [4.2 APP 首页与导航](./02-HOM-APP首页与导航.md#42-app-首页)的导航收敛方案须保持一致。
## 4.8.2 ROOS「我的」（采购域资产）
![现状-ROOS 我的](../mini-program-images/ROOS/我的.png)
**页面内容** —— ROOS 采购小程序的「我的」：橙色头部为头像、门店主编码、门店名与账号，其下依次是「本月进度」考核卡、「我的订单」四状态卡、四宫格快捷入口（账户 / 优惠券 / 对账单 / 条码库存）与 收货地址 / 员工管理 / 我的收藏 三行列表。
**关键交互** —— ①点击「本月进度 ⓘ」的问号 → 指标口径说明；②点击「查看更多 >」→ 门店考核明细（现状指标为 签约量(单马牌) 100 / 马牌订货量 0 / 扫码入库 0 / O2O售出 –）；③点击「全部订单 >」或待支付 / 待发货 / 待收货 / 售后退款任一图标 → 采购订单列表并定位到对应状态页签；④点击账户 / 优惠券 / 对账单 / 条码库存 → 四个二级页；⑤点击收货地址 / 员工管理 / 我的收藏 → 对应二级页。
**可用角色** —— 店长 ✅ 全量；技工 🔸 资产类（账户 / 对账单）与员工管理不可见 `TODO(REQ-MIN-002)`。本页底部导航为 4 tab（首页 / 商品 / 购物车 / 我的），是采购域独立小程序的形态，与 App 5 tab 不同。
**需求关联** —— [REQ-MIN-009](#486-业务规则) 我的账户资产结构、[REQ-MIN-017](#486-业务规则) 本月进度与员工管理的归属
> **本页有两项能力不在 4.8.5 合并规则表的 16 行里，也不在设计稿里 —— 属漏归**：
> - **「本月进度」考核卡** —— 与 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)、[4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)是同一套门店考核体系（签约量 / 订货量 / 扫码入库 / O2O 售出）；
> - **「员工管理」** —— 与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)的「人员管理与授权」是同一件事。
>
> 处理办法见 [REQ-MIN-017](#486-业务规则)，两行已补入 4.8.5 合并规则表。
![现状-ROOS 我的-跳转账户管理小程序弹窗](../mini-program-images/ROOS/我的-跳转账户管理小程序弹窗.png)
**页面内容** —— 点 ROOS「我的」资产入口后弹出的**微信系统级弹窗**「即将打开"账户管理｜德国马牌轮胎"小程序」，遮罩下露出的功能列表补齐了上一张未拍到的项（支付优先级设置、服务热线、经销商客服、**关于 V2.66.96**、退出登录）。
**关键交互** —— ①点击「允许」→ 跳出 ROOS，打开独立的「账户管理」小程序；②点击「取消」→ 留在当前页。这是微信原生弹窗，样式与文案由平台控制，小程序无法定制。
**可用角色** —— 店长 ✅；技工 ❓ 取决于资产类权限结论 `TODO(REQ-MIN-002)`。
**需求关联** —— [REQ-MIN-018](#486-业务规则) 「账户管理」小程序的接入范围、[REQ-MIN-016](#486-业务规则) 关于 / 版本号入口
> **两处关键发现：**
> 1. **「账户管理｜德国马牌轮胎」是本 PRD 系统清单之外的第 8 个小程序** —— 第 5 章列出的现状系统为 ROOS / O2O / 延保 / 马上下单 / RMS / MSIP / F6，不含它。4.8.5 合并规则表写「跳转其它小程序 → **取消**」，意味着 App 必须自行承接账户管理的全部能力，或接入该小程序的后端接口 —— 这是一处**尚未评估的接入范围**，见 [REQ-MIN-018](#486-业务规则)。
> 2. **「关于 V2.66.96」入口在设计稿中完全缺失** —— App 作为独立安装包，版本号、用户协议、隐私政策、检查更新是发版合规的必备项，见 [REQ-MIN-016](#486-业务规则)。
**我的账户**：点击「账户」按钮进入「我的账户」。我的账户分为**信用额度、未使用返利、优惠券总金额、积分余额**。信用额度含可用余额、待还金额、信用额度；未使用返利按品牌明细展示，含返利总额。
![现状-ROOS 我的账户](../mini-program-images/ROOS/我的账户.png)
**页面内容** —— 资产总览页：顶部橙色卡为门店名、所属经销商与可用余额 / 信用额度 / 待还金额，下方白卡按未使用返利、优惠券总金额、积分余额三段罗列并各自拆分明细，**本页为全零数据**故金额格式与明细行样式无法从本图确认。
**关键交互** —— ①点击「未使用返利 ¥0.00 >」→ 返利明细；②点击「优惠券总金额 ¥0.00 >」→ 优惠券列表（即下一张图）；③点击「积分余额 0 >」→ 积分明细与兑换；④四类返利与两类积分本身**未见 `>`，是否可逐类下钻本图无法确认**。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-MIN-002)`（资产与资金相关，倾向不开放）。
**需求关联** —— [REQ-MIN-009](#486-业务规则) 资产四层结构与两套返利体系
> **本页揭示的三点，是 4.8 与 4.11 之间最容易做错的地方：**
> 1. **信用额度未设置时显示「——」而非 ¥0.00** —— 空值与零值在授信语境下含义完全不同（未授信 vs 授信额度为零），App 必须沿用这一区分。
> 2. **未使用返利按「品牌–区域」组织**，出现了 **Continental–上海 / Viking–上海 / 卡迪睿德 / 其他业务** 四类。其中**「卡迪睿德」是 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)从未出现过的第三个品牌**（4.11 只涉及马牌与 Viking）。
> 3. **返利有两套互不相通的体系** —— 本页是 **ROOS 采购返利**（按品牌×区域累计，用于抵扣货款，[4.6 采购](./06-PUR-采购.md#46-采购)结算页的「返利抵扣 请选择」取的就是它）；而 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)描述的是 **O2O 营销返利**（消费者补贴、安装费用、抽奖红包）。**4.11 只覆盖后者。** 个人中心若只展示一个「返利」数字，必然把两套账混在一起。
**优惠券**：状态 Tab 为**待激活、待生效、待使用、已使用、已失效**；券的种类分为**马牌券、经销商券**。
![现状-ROOS 我的优惠券-待使用](../mini-program-images/ROOS/我的优惠券-待使用.png)
**页面内容** —— 优惠券列表页：顶部五个状态页签（待激活 / 待生效 / **待使用**（当前选中）/ 已使用 / 已失效）与「马牌券 | 经销商券」二级分段控件，**本截图为空态**故券卡的面额、门槛、有效期、适用范围无法从本图确认。
**关键交互** —— ①切换五个状态页签 → 列表按券状态过滤；②切换「马牌券 / 经销商券」→ 在当前状态下再按券种过滤（两级筛选叠加）；③点击券卡 → 券详情或去使用（**空态下无法确认**）；④「待激活」状态**隐含一个激活动作**，但激活入口与规则本图无法确认。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-MIN-002)`。
**需求关联** —— [REQ-MIN-010](#486-业务规则) 优惠券五状态与两种券种
> 「待激活」与「待生效」是两个不同状态：前者需用户**主动激活**，后者是**已激活但未到生效时间**。PRD 现状未定义激活动作的触发方式与规则，见 [REQ-MIN-010](#486-业务规则)。
**支付优先级设置**：~~设置是否优先使用扣账支付方式~~ —— **V1.1 更正**：现状实际为单一开关「**是否优先使用微信支付**」，取值「是 / 否」，与「扣账支付方式」无关。
![现状-ROOS 支付优先级设置](../mini-program-images/ROOS/支付优先级设置.png)
**页面内容** —— 极简单行设置页「是否优先使用微信支付」（当前值「是」），点击后从底部升起微信原生单列滚轮，选项为「否 / 是」。
**关键交互** —— ①点击设置行 → 升起滚轮选择器；②滚动选择「是 / 否」→ 点「确认」保存并回填该行，点「取消」不变更；③本页**只有这一项设置**，无其它支付方式排序能力。
**可用角色** —— 店长 ✅；技工 ✗（影响资金，见附录 B）。
**需求关联** —— `TODO(REQ-MIN-005)` 放在个人中心还是采购结算、[REQ-MIN-011](#486-业务规则) 设置语义与生效范围
> **V1.0 的 4.8.2 原文「设置是否优先使用扣账支付方式」与截图不符，已就地更正。** 该表述会误导设计与开发把它做成「扣账 / 微信 / 余额」的多方式排序，实际只是一个二值开关。
**收货地址**：地址列表含联系人、手机号、详细地址、默认标记。页面提示「扫码入库时，店铺位置以地图定位为准」。
![现状-ROOS 收货地址](../mini-program-images/ROOS/收货地址.png)
**页面内容** —— 收货地址列表，本图只有一条（联系人「测试」、详细地址为重复拼接的脏数据、带 ✅「默认地址」标记），列表下方有一行提示「扫码入库时，店铺位置以地图定位为准」与橙色「查看定位 >」。
**关键交互** —— ①点击「查看定位 >」→ 打开门店地图定位（V1.0 只引用了提示文案，**未提及这个可点入口**）；②点击地址条目 → 编辑（**本图无法确认是否可点**）；③**本页未见「新增地址」按钮**，新增入口位置无法从本图确认；④只有一条地址，A.9 所称「按使用时间 / 默认状态排序」无法验证。
**可用角色** —— 店长 ✅；技工 🔸 只读（见附录 B）。
**需求关联** —— [REQ-MIN-014](#486-业务规则) 地址管理能力与权威数据源
> 地址文本「**上海市上海市浦东新区上海市浦东新区**南桥路1200号」是典型的**省市区与详细地址重复拼接**的脏数据 —— 结构化字段（省/市/区）与自由文本（详细地址）在录入时没有做互斥校验。App 侧须做规范化，见 [REQ-MIN-014](#486-业务规则)。
**我的收藏**：进入「商品收藏列表」。
![现状-ROOS 商品收藏列表](../mini-program-images/ROOS/商品收藏列表.png)
**页面内容** —— 商品收藏列表（顶部标注「共 1 件商品」），商品卡含左侧**占位图（无实际商品图）**、规格名与红色单价，右侧竖排橙色实心 ❤ 与「加入购物车」两个图标。
**关键交互** —— ①点击橙色实心 ❤ → 取消收藏，商品从列表移除；②点击「加入购物车」→ 直接加购，与 [4.6 采购](./06-PUR-采购.md#46-采购)的购物车联动；③点击商品卡 → 商品详情（**本图无法确认**）。
**可用角色** —— 店长 ✅；技工 🔸 只读（见附录 B）—— 「只读」意味着技工**不可取消收藏、不可加购**，需在实现时明确。
**需求关联** —— [REQ-MIN-015](#486-业务规则) 收藏列表的价格可见性与操作权限
> **收藏卡直接展示采购价 ¥1688.00/条，与附录 B 存在冲突**：附录 B 给技工的「收货地址 / 我的收藏」是 🔸 只读（即**可见**），而「查看小程序结算价」对技工是 ❓ `TODO(REQ-INV-001)`。若技工能打开收藏列表，就等于绕过价格管控看到了采购价。见 [REQ-MIN-015](#486-业务规则)。
> 另：商品图为占位图，是 ROOS 商品主数据的图片缺失，属现状数据质量问题，不新增需求编号。
## 4.8.3 O2O「设置」（账号与门店）
![现状-O2O 设置](../mini-program-images/O2O/设置.png)
**页面内容** —— O2O（接单宝）的「设置」页，内容极简：头像 + 昵称 + 手机号一行（右侧一枚橙色小标签**文字过小、本图无法辨认**）、门店名 + 灰色「切换店铺」一行，中部大片留白，底部是灰色的「退出登录」。
**关键交互** —— ①点击「切换店铺」→ 门店选择列表（见本节后面的图）；②点击「退出登录」→ 确认弹窗（见下一张图）；③**本页无「修改手机号」入口**，而 O2O 确实存在修改手机号页 —— 其入口位置本图无法确认。
**可用角色** —— 店长 ✅；技工 ✅（个人信息 / 登出对全角色开放，见附录 B）。
**需求关联** —— [REQ-MIN-007](#486-业务规则) 门店绑定关系与切换门店、[REQ-MIN-013](#486-业务规则) 姓名的可编辑性与回写
> 门店名「智慧园杀虫轮胎店」与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)截图中的「豌豆的小店」不同，但**手机号 13419691597 相同** —— 同一账号绑定多家门店，这一点在下面的「选择店铺」图中得到印证。
> 另：三套现状系统对同一个人的称呼各不相同 —— O2O 显示昵称「宛玉」，ROOS 显示手机号，延保显示操作人姓名「史涵」。这正是 `TODO(REQ-MIN-003)` 要解决的问题。
![现状-O2O 设置-确认登出弹窗](../mini-program-images/O2O/设置-确认登出弹窗.png)
**页面内容** —— 居中确认弹窗，标题「确认登出」+「取消 / 确定」两个按钮，**无任何正文说明**。
**关键交互** —— ①点击「确定」→ 清除登录态并返回登录页；②点击「取消」→ 关闭弹窗留在设置页。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-LGN-008](./01-LGN-账号登录.md#412-业务规则) 退出登录需二次确认、[REQ-MIN-019](#486-业务规则) 登出的清除范围与多设备会话
> 现状弹窗只有「确认登出」四个字，不说明后果。App 的登出会同时清除本地 Token、门店上下文与缓存业务数据（见 [4.8.7 验收标准](#487-验收标准)第 2 条），弹窗文案须把这一点告知用户，见 [REQ-MIN-019](#486-业务规则)。
![现状-O2O 修改手机号](../mini-program-images/O2O/修改手机号.png)
**页面内容** —— 换绑手机号表单，三行为「当前手机号」（`134 1969 1597`，**分组展示、未脱敏**）、新手机号与短信验证码，下方提示「验证码将发送至**原手机号**」，底部「确认修改」为灰色禁用态。
**关键交互** —— ①点击「获取验证码」→ 向**原**手机号发送短信验证码并开始倒计时；②三项填写完整后「确认修改」由灰转亮 → 提交换绑；③新手机号**不做任何验证**即可绑定。
**可用角色** —— 店长 ✅；技工 ✅（换绑手机对全角色开放，见附录 B）。
**需求关联** —— [REQ-MIN-012](#486-业务规则) 换绑手机的双向验证与脱敏
> **这是现状里最需要在 App 上改掉的一处**：验证码发往**原**号只能证明「你是当前账号的持有人」，无法证明「新号归你所有」。填错一位数字就会把账号绑到陌生号码上，且原号已失去登录能力 —— 属不可自助恢复的故障。App 须改为**双向验证**，见 [REQ-MIN-012](#486-业务规则)。
![现状-O2O 选择店铺](../mini-program-images/O2O/选择店铺.png)
**页面内容** —— 「选择店铺」列表页，每行为门店名 + 橙色「进入」按钮（当前门店改显橙色 ✅ 标记），本图可见 13 家门店且列表可继续下滑，即**同一账号绑定了 13 家以上门店**。
**关键交互** —— ①点击任一行的「进入」→ 切换到该门店并返回，全站数据随之切换；②当前门店不可重复进入；③列表**无搜索框、无分组、无字母索引**，门店多时只能逐屏翻找。
**可用角色** —— 店长 ✅；技工 ✅（能进哪些门店由后台绑定关系决定，不由角色决定）。
**需求关联** —— [REQ-MIN-007](#486-业务规则) 门店绑定关系与切换门店、[REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文
> **这张图确立了个人中心最关键的一条结构性事实：门店与账号是多对多关系，且规模不小（本例 13+ 家）。** 4.8.5 合并规则表把「切换门店」收敛为 App 全局门店上下文，但**全局门店列表取自哪套系统的绑定关系、切店时清不清购物车、已打开的页面如何处理**均未定义，见 [REQ-MIN-007](#486-业务规则)。
> 列表中「曲奇测试门店2号店」「马牌品牌商导入MS（预发1）」「上海市尚浦中心马牌培训店1(测试勿拍)」「野蜂蜜很甜」「吃瓜专门店」「小脑斧汽车修理门店」等大量条目为**测试数据**，正式环境的门店名规范与数量分布无法从本图推断。
![现状-O2O 小程序在线客服](../mini-program-images/O2O/小程序在线客服.png)
**页面内容** —— 从 O2O 首页唤起的底部动作面板「小程序在线客服」，列出 **6 条按渠道区分的电话**（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），底部为「取消」。
**关键交互** —— ①点击任一行 → 唤起系统拨号盘拨打该号码；②点击「取消」→ 关闭面板；③**无在线聊天能力** —— 名为「在线客服」，实为电话清单。
**可用角色** —— 店长 ✅；技工 ✅（客服入口不设权限）。
**需求关联** —— `TODO(REQ-MIN-004)` 三个客服入口是否合并、[REQ-MIN-008](#486-业务规则) 服务热线按渠道分列的数据模型
> **两点须处理：**
> 1. **客服不是一个号码，而是按渠道分的 6 条线**。V1.0 的 4.8 只列了「服务热线 / 经销商客服 / O2O·延保企微客服」三个入口，附录 A.9 的「服务热线列表」也只有「号码 / 服务时间 / 范围 / 类型」四个字段 —— **缺「渠道」维度**，见 [REQ-MIN-008](#486-业务规则)。
> 2. **高德（159\*\*\*\*1674）与美团（185\*\*\*\*1756）用的是个人手机号**，零跑是座机分机（023-62905394）。个人号码作为对外官方热线，人员变动即失联，属治理风险。
>
> 本图的渠道口径（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑）与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)的平台渠道（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑）**又不相同** —— 这是全仓库第七套渠道枚举，见 [附-5](../Continental-Retail-APP-PRD.md#1028-我的min)。
## 4.8.4 延保「我的」
![现状-延保 我的](../mini-program-images/Warranty/我的.png)
**页面内容** —— 延保小程序的「我的」，**深色主题**（与 ROOS / O2O 的浅色主题完全不同）：上部是带编辑铅笔的大号橙色头像，下方三行为操作人姓名、切换店铺与手机号（右侧灰字「已绑定」），底部是 5 tab 导航。
**关键交互** —— ①点击头像右下的铅笔钮 → 更换头像（**本图无法确认是否真的可上传**）；②点击「操作人姓名」→ 姓名编辑弹窗（见下一张图）；③点击「切换店铺」→ 门店选择器（见本节最后一张图）；④「手机号码」行**无 `>`，不可点** —— 延保侧不提供换绑手机；⑤底部中央的橙色指南针钮功能**本图无法确认**。
**可用角色** —— 店长 ✅；技工 ✅（个人信息类，见附录 B）。
**需求关联** —— [REQ-MIN-013](#486-业务规则) 姓名的可编辑性与回写、[REQ-MIN-020](#486-业务规则) 头像首版只读、`TODO(REQ-MIN-003)` 姓名的权威来源与回写范围
> **姓名在延保侧是可自由编辑的文本**（「史涵」），而 ROOS 显示的是手机号、O2O 显示的是昵称「宛玉」。三套各存一份、互不同步 —— 这就是 `TODO(REQ-MIN-003)` 的由来。
> 本页账号 13871477616 / 上海东兴店与 ROOS 截图一致（同一测试账号跨两系统），与 O2O 截图的 13419691597 / 智慧园杀虫轮胎店不是同一个账号。
![现状-延保 我的-修改姓名](../mini-program-images/Warranty/我的-修改姓名.png)
**页面内容** —— 居中深色弹窗「**登录账户**输入您的姓名」（右上角「✕ 关闭」胶囊），表单只有一个「姓名」下划线输入框与底部橙色「确认」。
**关键交互** —— ①在输入框键入姓名 → 点「确认」保存并回填到「操作人姓名」行；②点右上「✕ 关闭」→ 放弃修改；③**输入框为空，未预填当前姓名「史涵」**；④无必填标记、无长度或字符校验提示。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-MIN-013](#486-业务规则) 姓名的可编辑性与回写
> 两处须在 App 上改掉：**编辑弹窗不预填当前值**（用户改一个字也得整个重打），以及**标题文案「登录账户输入您的姓名」语义不通**。
![现状-延保 我的-切换店铺](../mini-program-images/Warranty/我的-切换店铺.png)
**页面内容** —— 深色「我的」页底部升起的**微信原生单列滚轮选择器**（浅色，与页面深色主题割裂），滚轮中只有一个选项「上海东兴店」，底部为灰底「取消」与**绿色**实心「确定」。
**关键交互** —— ①滚动滚轮选择门店 → 点「确定」切换；②点「取消」不变更；③本账号在延保侧**只绑定 1 家门店**，故滚轮无实际可选项。
**可用角色** —— 店长 ✅；技工 ✅。
**需求关联** —— [REQ-MIN-007](#486-业务规则) 门店绑定关系与切换门店
> **同一件事，三套系统三种交互**：O2O 是整页列表 + 「进入」按钮，延保是底部滚轮选择器，ROOS 的「我的」页则**没有切换店铺入口**。App 统一为一种交互即可，但更要紧的是背后的数据 —— **门店绑定关系分别维护在各系统里**（本例延保侧 1 家，O2O 侧另一账号 13+ 家），统一后取哪套为权威须定，见 [REQ-MIN-007](#486-业务规则)。
> 另：确定按钮为**绿色**（微信原生 picker 默认色），与延保小程序的橙色主色不一致 —— App 用原生组件时须统一主题色。
## 4.8.5 合并规则
| 现状能力 | 来源 | App 归属 |
| --- | --- | --- |
| 头像 / 姓名 / 角色 | 三套各有 | 个人中心用户卡（姓名以 App Backend 为准，回写各系统）`TODO(REQ-MIN-003)`；头像首版只读（[REQ-MIN-020](#486-业务规则)） |
| 切换门店 | 三套各有 | **收敛为 App 全局门店上下文**（[REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则)），个人中心不再单独提供；绑定关系权威来源见 [REQ-MIN-007](#486-业务规则) |
| 修改手机号 / 换绑手机 | O2O + 设计稿 | 个人中心，须双向验证（[REQ-MIN-012](#486-业务规则)） |
| 退出登录 | O2O + 设计稿 | 个人中心，需二次确认（[REQ-LGN-008](./01-LGN-账号登录.md#412-业务规则)） |
| 在线客服 / 服务热线 / 经销商客服 | O2O + 设计稿 | 个人中心（三个客服入口是否合并 —— `TODO(REQ-MIN-004)`）；须支持按渠道分列（[REQ-MIN-008](#486-业务规则)） |
| 我的账户（额度/返利/券/积分） | ROOS | 个人中心资产卡 + 二级页；**采购返利与营销返利须分列**（[REQ-MIN-009](#486-业务规则)）；营销返利明细见 [4.11](./11-RBT-返利中心.md#411-返利中心) |
| 优惠券 | ROOS + O2O | 个人中心，保留五状态 + 两种券种（[REQ-MIN-010](#486-业务规则)）；营销侧发放见 [4.13](./13-MKT-营销与会员.md#413-营销与会员) |
| 收货地址 / 地址管理 | ROOS + 设计稿 | 个人中心（[REQ-MIN-014](#486-业务规则)） |
| 我的收藏 | ROOS + 设计稿 | 个人中心（[REQ-MIN-015](#486-业务规则)） |
| 支付优先级设置 | ROOS | 个人中心（或下沉到[采购结算](./06-PUR-采购.md#463-购物车与结算)）`TODO(REQ-MIN-005)`；实为「是否优先使用微信支付」（[REQ-MIN-011](#486-业务规则)） |
| 经营范围 | O2O + 设计稿 | 设计稿放在个人中心，现状在店铺管理下 —— 归属待定 `TODO(REQ-MIN-006)`，现状见 [4.9](./09-STM-门店管理.md#49-门店管理) |
| 条码库存 | ROOS | 下沉到 [4.7 库存](./07-INV-库存.md#47-库存) |
| 对账单 | ROOS | 下沉到 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账) |
| 经营业绩 | ROOS | 下沉到 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表) |
| 跳转其它小程序 | ROOS | **取消**；「账户管理」小程序的能力承接范围见 [REQ-MIN-018](#486-业务规则) |
| **本月进度（门店考核卡）** | ROOS | **V1.1 补入** —— 下沉到 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)（[REQ-MIN-017](#486-业务规则)） |
| **员工管理** | ROOS | **V1.1 补入** —— 下沉到 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)的人员管理与授权（[REQ-MIN-017](#486-业务规则)） |
| **我的订单（四状态入口）** | ROOS | **V1.1 补入** —— 下沉到 [4.6 采购](./06-PUR-采购.md#46-采购)的订单列表（[REQ-MIN-017](#486-业务规则)） |
| **关于 / 版本号** | ROOS | **V1.1 补入** —— 个人中心新增，含版本号、用户协议、隐私政策、检查更新（[REQ-MIN-016](#486-业务规则)） |
三套「我的」的合并归属（原 16 行，V1.1 补入 4 行，共 19 行）
## 4.8.6 业务规则
> **本节为 V1.1 新增。** V1.0 的 4.8 原本没有业务规则小节，`REQ-MIN-001` ~ `REQ-MIN-006` 六个编号只以 `TODO(...)` 形式散落在正文中；下列 `REQ-MIN-007` ~ `REQ-MIN-020` 为 V1.1 逐图核对现状后补写。
1. **REQ-MIN-007 门店绑定关系与切换门店** —— App 可切换的门店列表**以 App Backend 的「人员–门店」绑定关系为唯一权威**，由后台聚合三套现状系统的绑定并按门店主编码去重；列表须支持按门店名 / 编码搜索，当前门店置顶并以选中态标识（现状 O2O 单账号已绑定 13 家以上门店，无搜索）。切换门店后须刷新全局门店上下文并重载所有业务数据。**切店时购物车、未提交表单、已打开的 H5 页面如何处理未定** —— `TODO(REQ-MIN-007)`。
2. **REQ-MIN-008 服务热线按渠道分列** —— 服务热线数据集须支持「渠道 → 号码」多条记录（现状 6 条：小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），由后台维护、App 动态渲染，**不得在客户端硬编码**，号码变更无需发版。点击行为统一为唤起系统拨号盘。**现状高德、美团用的是个人手机号，是否替换为总机分机** —— `TODO(REQ-MIN-008)`。
3. **REQ-MIN-009 资产结构与两套返利体系** —— 「我的账户」保留四层结构：授信（可用余额 / 信用额度 / 待还金额）、未使用返利、优惠券、积分。其中：**信用额度未授信时显示「——」，不得显示 ¥0.00**（空值与零值语义不同）；**采购返利（按「品牌–区域」累计，用于抵扣货款，见 [4.6 采购](./06-PUR-采购.md#46-采购)）与营销返利（消费者补贴 / 安装费用 / 抽奖红包，见 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)）必须分列展示，不得合并为一个「返利」数字**；积分区分「通用兑换 / 运营物料」两类。**四项资产在设计稿两张资产卡里如何落位、优惠券展示张数还是总金额、采购返利品牌枚举（现状含 Continental / Viking / 卡迪睿德 / 其他业务）是否完整** —— `TODO(REQ-MIN-009)`。
4. **REQ-MIN-010 优惠券状态与券种** —— App 优惠券列表保留五状态页签（待激活 / 待生效 / 待使用 / 已使用 / 已失效）与「马牌券 / 经销商券」二级券种筛选，两级筛选可叠加。**「待激活」状态的激活入口、激活条件与激活后是否立即可用未定** —— `TODO(REQ-MIN-010)`。
5. **REQ-MIN-011 支付优先级设置的语义** —— 该设置的现状语义是单一二值开关「**是否优先使用微信支付**」，**不是**V1.0 原文所写的「是否优先使用扣账支付方式」，不得实现为多支付方式排序。**该设置是账号级还是门店级、变更后对已在购物车中的商品是否即时生效未定** —— `TODO(REQ-MIN-011)`。
6. **REQ-MIN-012 换绑手机的双向验证与脱敏** —— App 换绑手机须**同时验证原号与新号**（原号验证码证明账号归属，新号验证码证明新号可用），不得沿用现状「验证码只发原号」的单向流程；页面展示的当前手机号须脱敏为 `138****7616`；提交按钮在必填项补齐前保持禁用态。
7. **REQ-MIN-013 姓名的可编辑性与校验** —— 姓名编辑弹窗**必须预填当前姓名**；须做长度（2–20 字符）与字符集校验，禁止纯空白；保存成功后立即回填用户卡。**权威来源与回写到哪几套系统** —— 见 `TODO(REQ-MIN-003)`。
8. **REQ-MIN-014 地址管理能力与数据规范** —— 地址管理须提供新增 / 编辑 / 删除 / 设为默认四项能力（现状页面未见新增入口）；省 / 市 / 区为结构化字段，详细地址不得重复拼接省市区（现状存在「上海市上海市浦东新区上海市浦东新区南桥路1200号」这类脏数据），提交时须校验并在展示时规范化；保留「查看定位」入口，与 [4.7 库存](./07-INV-库存.md#47-库存)扫码入库的门店定位校验同源。**收货地址的权威数据源（是否来自马上下单接口）** —— `TODO(REQ-MIN-014)`。
9. **REQ-MIN-015 收藏列表的价格与操作权限** —— 收藏列表的价格显示**须遵从与商品列表一致的价格可见性策略**（见 [4.7 库存](./07-INV-库存.md#47-库存)的 `TODO(REQ-INV-001)`），不得成为绕过价格管控的旁路；附录 B 中技工对「我的收藏」的 🔸 只读，明确为**可查看、不可取消收藏、不可加入购物车**。
10. **REQ-MIN-016 关于 / 版本号入口** —— 个人中心须提供「关于」入口，至少包含：App 版本号与构建号、用户协议、隐私政策、检查更新（对接 OTA 分发）、备案信息。该入口在现状 ROOS 中存在（「关于 V2.66.96」），但**设计稿完全缺失**，属发版合规必备项。
11. **REQ-MIN-017 下沉能力不在个人中心重复提供** —— 「本月进度」考核卡下沉到 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)、「员工管理」下沉到 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)、「我的订单」下沉到 [4.6 采购](./06-PUR-采购.md#46-采购)；个人中心不再重复提供入口，避免同一能力两处维护。
12. **REQ-MIN-018 「账户管理」小程序的能力承接** —— 现状 ROOS 通过微信系统弹窗跳转「账户管理｜德国马牌轮胎」小程序，该小程序**不在本 PRD 的现状系统清单内**。按 4.8.5「跳转其它小程序 → 取消」的原则，App 须自行承接其能力。**承接范围（是否只需授信 / 返利 / 券 / 积分的查询，还是包含还款、开票等写操作）与接入方式（直连其后端 / 由 App Backend 代理 / 内嵌 H5）未定** —— `TODO(REQ-MIN-018)`。
13. **REQ-MIN-019 登出的清除范围与多设备会话** —— 登出二次确认弹窗须说明后果（将清除本地登录态、门店上下文与缓存业务数据），不得像现状那样只有「确认登出」四字；登出后本地 Token、门店上下文、缓存业务数据全部清除。**多设备可同时登录、单设备登出不影响其它设备**（附录 A.9 第 5 条），与账号共用治理诉求的张力见 `TODO(REQ-LGN-009)`。
14. **REQ-MIN-020 头像首版只读** —— 首版头像**不提供上传**，统一使用系统默认头像 + 角色底色（避免引入图片审核、存储与合规成本）；现状三套小程序中虽有编辑入口（延保），但全部截图均为默认头像，无实际使用。如业务需要自定义头像，另行提需求。
## 4.8.7 验收标准
1. 个人中心显示的门店与全局门店上下文一致，切店后资产数据同步刷新；
2. 退出登录后本地 Token、门店上下文、缓存业务数据全部清除（见《App 门店上下文与会话管理文档》）；
3. 角色标签与后台下发的角色一致，技工不显示店长专属资产项；
4. 门店切换列表支持按门店名 / 编码搜索，当前门店置顶并高亮；绑定 20 家门店的账号可在 3 秒内定位到目标门店（[REQ-MIN-007](#486-业务规则)）；
5. 「我的账户」中采购返利与营销返利分列展示，两个数字来源不同接口且互不相加；信用额度未授信时显示「——」（[REQ-MIN-009](#486-业务规则)）；
6. 换绑手机须原号与新号各验证一次，任一验证失败即不落库；页面展示的手机号已脱敏（[REQ-MIN-012](#486-业务规则)）；
7. 姓名编辑弹窗打开时输入框已预填当前姓名；提交空白或超长姓名被拦截并给出提示（[REQ-MIN-013](#486-业务规则)）；
8. 新增地址时详细地址中重复填写省市区会被校验拦截；地址列表按默认状态与使用时间排序（[REQ-MIN-014](#486-业务规则)）；
9. 服务热线列表从后台接口动态获取，后台新增一条渠道热线后 App 无需发版即可展示（[REQ-MIN-008](#486-业务规则)）；
10. 「关于」页展示的版本号与安装包版本一致，用户协议与隐私政策可正常打开（[REQ-MIN-016](#486-业务规则)）；
11. 技工登录后个人中心不出现「本月进度」「员工管理」「我的订单」等已下沉入口，且资产卡按 `TODO(REQ-MIN-002)` 的结论展示或隐藏。
---
## 附：本模块归拢信息（来自主文件其它章节）
### 附-1 业务数据字典（主文件附录 A.9）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 收货地址列表（按使用时间/默认状态排序） | App Backend | HTTPS | 数据来源于马上下单接口（待确认，见 `TODO(REQ-MIN-003)`） |
| 2 | 服务热线列表（号码/服务时间/范围/类型） | App Backend | HTTPS | 支持一键拨号 |
| 3 | 经销商客服信息 | App Backend | HTTPS | 在线咨询、留言反馈 |
| 4 | O2O / 延保企微客服信息 | App Backend | HTTPS | 数据来源于企业微信接口（待确认，见 `TODO(REQ-MIN-004)`） |
| 5 | 退出登录 | App Backend | HTTPS | 清除登录态；多设备登录时单设备退出不影响其它设备 |
> **A.9 第 5 条隐含一条尚未成文的规则**：多设备可同时登录，单设备登出不影响其它设备。这与[账号权限管控痛点](../Continental-Retail-APP-PRD.md#22-账号权限管控)中「账号共用」的治理诉求存在张力 —— 是否需要单设备登录限制，建议在 `TODO(REQ-LGN-009)` 一并确认。
**本次拆分对 A.9 的三点修订建议**（回灌主文件时一并处理）：
1. **第 1 条的 TODO 编号指错** —— 备注引用的 `TODO(REQ-MIN-003)` 是「姓名的权威来源与回写范围」，与收货地址无关。应改为指向本次新增的 `TODO(REQ-MIN-014)`（收货地址的权威数据源）。
2. **第 2 条缺「渠道」字段** —— 现状热线按渠道分为 6 条（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），字段清单须补「渠道」，见 [REQ-MIN-008](#486-业务规则)。
3. **A.9 缺三个数据集** —— 现状页面用到但附录 A 未收录：**门店绑定关系列表**（账号可切换的门店，含门店主编码 / 门店名 / 是否当前，来源 App Backend）、**账户资产聚合**（可用余额 / 信用额度 / 待还 / 未使用返利按品牌×区域 / 优惠券总额 / 积分双类型，来源 ROOS 或「账户管理」小程序后端）、**优惠券列表**（五状态 × 两券种，来源 ROOS + O2O）。三者分别对应 [REQ-MIN-007](#486-业务规则) / [REQ-MIN-009](#486-业务规则) / [REQ-MIN-010](#486-业务规则)。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **我的** | 个人信息 / 换绑手机 / 登出 | ✅ | ✅ | |
| | 我的账户（额度/返利/券/积分） | ✅ | ❓ | `TODO(REQ-MIN-002)` |
| | 收货地址 / 我的收藏 | ✅ | 🔸 | 技工只读 |
| | 支付优先级设置 | ✅ | ✗ | 影响资金 |
**本次拆分建议新增的三行**（回灌主文件时一并处理）：
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **我的** | 切换门店 | ✅ | ✅ | 可切换范围由后台绑定关系决定，不由角色决定（[REQ-MIN-007](#486-业务规则)） |
| | 收藏列表中的商品价格 | ✅ | ❓ | 须与「查看小程序结算价」同口径，见 `TODO(REQ-INV-001)`（[REQ-MIN-015](#486-业务规则)） |
| | 服务热线 / 客服入口 | ✅ | ✅ | 不设权限（[REQ-MIN-008](#486-业务规则)） |
另需明确：现有「收货地址 / 我的收藏」行的「技工只读」，具体指**可查看但不可新增/编辑/删除地址、不可取消收藏、不可加入购物车**，见 [REQ-MIN-014](#486-业务规则) 与 [REQ-MIN-015](#486-业务规则)。
### 附-3 待确认项（主文件 10.2.8）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-MIN-001 | 个人中心保留哪 6 项、其余下沉到哪些模块 | 产品 |
| REQ-MIN-002 | 资产类（额度/返利/对账单）是否限店长 | 业务 |
| REQ-MIN-003 | 姓名的权威来源与回写范围 | 架构 |
| REQ-MIN-004 | 服务热线 / 经销商客服 / 企微客服三个入口是否合并 | 产品 |
| REQ-MIN-005 | 支付优先级设置放在个人中心还是采购结算 | 产品 |
| REQ-MIN-006 | 「经营范围」归属个人中心还是门店管理 | 产品 |
**本次拆分新增 7 条**（回灌主文件时并入 10.2.8）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-MIN-007 | **切换门店时购物车、未提交表单、已打开 H5 页面如何处理**；全局门店列表的权威绑定关系取自哪套系统 | 架构 / 产品 |
| REQ-MIN-008 | 高德、美团客服现用个人手机号，是否替换为总机分机 | 运营 |
| REQ-MIN-009 | 四项资产在两张资产卡里的落位；优惠券展示张数还是总金额；**采购返利的品牌枚举是否完整（现含卡迪睿德）** | 产品 / 业务 |
| REQ-MIN-010 | 优惠券「待激活」状态的激活入口与激活规则 | 业务 |
| REQ-MIN-011 | 支付优先级设置是账号级还是门店级；变更对购物车内商品是否即时生效 | 架构 |
| REQ-MIN-014 | 收货地址的权威数据源（是否来自马上下单接口） | 架构 |
| REQ-MIN-018 | **「账户管理」小程序的能力承接范围与接入方式** | 架构 / 业务 |
合计 13 条待确认（原 6 + 新增 7）。
### 附-4 配图清单（主文件附录 C 4.8 节，16 张）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-个人中心（App 目标形态） | `app-design-images/个人中心.png` |
| 2 | 现状-ROOS 我的 | `mini-program-images/ROOS/我的.png` |
| 3 | 现状-ROOS 我的（跳转账户管理小程序弹窗，整合后取消） | `mini-program-images/ROOS/我的-跳转账户管理小程序弹窗.png` |
| 4 | 现状-ROOS 我的账户 | `mini-program-images/ROOS/我的账户.png` |
| 5 | 现状-ROOS 我的优惠券（待使用） | `mini-program-images/ROOS/我的优惠券-待使用.png` |
| 6 | 现状-ROOS 支付优先级设置 | `mini-program-images/ROOS/支付优先级设置.png` |
| 7 | 现状-ROOS 收货地址 | `mini-program-images/ROOS/收货地址.png` |
| 8 | 现状-ROOS 商品收藏列表 | `mini-program-images/ROOS/商品收藏列表.png` |
| 9 | 现状-O2O 设置 | `mini-program-images/O2O/设置.png` |
| 10 | 现状-O2O 设置（确认登出弹窗） | `mini-program-images/O2O/设置-确认登出弹窗.png` |
| 11 | 现状-O2O 修改手机号 | `mini-program-images/O2O/修改手机号.png` |
| 12 | 现状-O2O 选择店铺 | `mini-program-images/O2O/选择店铺.png` |
| 13 | 现状-O2O 小程序在线客服 | `mini-program-images/O2O/小程序在线客服.png` |
| 14 | 现状-延保 我的 | `mini-program-images/Warranty/我的.png` |
| 15 | 现状-延保 我的（修改姓名） | `mini-program-images/Warranty/我的-修改姓名.png` |
| 16 | 现状-延保 我的（切换店铺） | `mini-program-images/Warranty/我的-切换店铺.png` |
**看图后对本清单的补充说明**：
- 第 4、5 张为**全零 / 空态**截图 —— 我的账户全部金额为 ¥0.00、优惠券列表「暂无可用优惠券~」，故资产明细行与券卡的字段无法从截图确认，须补拍有数据的样本。
- 第 7、12 张含**测试脏数据** —— 收货地址的省市区重复拼接、选择店铺列表中大量「测试」「勿拍」「野蜂蜜很甜」「吃瓜专门店」类门店名。
- 第 8 张商品图为**占位图**（ROOS 商品主数据图片缺失）。
- 第 9 张用户行右侧的橙色小标签**文字过小无法辨认**，第 14 张底部中央的橙色指南针钮**功能无法确认**，两处均须补拍或向业务确认。
- 建议**补拍 4 张**：有数据的「我的账户」、有券的优惠券列表、O2O 修改手机号的入口路径、延保底部中央按钮展开态。补拍后附录 C 的 4.8 节计数由 16 → 20，须同步更新文档头部规模声明与本文件头部信息表。
### 附-5 本次拆分新增发现
1. **4.8 完全没有业务规则小节** —— 六个 REQ-MIN 编号全部只以 `TODO(...)` 形式存在，无一条成文规则，这是附录 D.2 中 MIN 完成度 0%（14 个模块唯一）的直接原因。本次补入 [4.8.6 业务规则](#486-业务规则) 共 14 条，原验收标准顺延为 4.8.7。**回灌主文件时须同步这处节号变更，并把 D.2 的 MIN 行由 6 / 6 / 0% 改为 20 / 13 / 35%。**
2. **合并规则表漏了 4 项能力** —— 「本月进度」考核卡、「员工管理」、「我的订单」四状态入口、「关于 / 版本号」，四者既不在原 16 行表里，也不在设计稿里。已补入 4.8.5（16 行 → 19 行，其中「我的订单」与前三项一并计入）。其中**「关于 / 版本号」是发版合规必备项**，缺失风险最高。
3. **「账户管理｜德国马牌轮胎」是系统清单外的第 8 个小程序** —— 第 5 章的现状系统清单（ROOS / O2O / 延保 / 马上下单 / RMS / MSIP / F6）不含它，但 ROOS 的资产入口实际跳转到它。合并规则表写「取消跳转」，等于要求 App 承接一个尚未评估的系统，见 [REQ-MIN-018](#486-业务规则)。**建议在第 5 章的系统清单中补录该小程序。**
4. **返利有两套互不相通的体系** —— ROOS **采购返利**（按「品牌–区域」累计，抵扣货款，[4.6 采购](./06-PUR-采购.md#46-采购)结算页在用）与 O2O **营销返利**（消费者补贴 / 安装费用 / 抽奖红包，[4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)在写）。**主文件 4.11 只覆盖后者**，而 4.8.5 合并规则表把「我的账户（额度/返利/券/积分）」的返利明细指向 4.11 —— 指错了。已在本文件的合并规则表中更正。另外，采购返利出现了 4.11 从未提及的第三个品牌「**卡迪睿德**」。
5. **换绑手机的验证码发往原号** —— 现状只验证原号、不验证新号，填错一位即把账号绑到陌生号码且原号失去登录能力，属不可自助恢复的故障。已定为 [REQ-MIN-012](#486-业务规则)（必须双向验证），无需再走待确认。
6. **支付优先级设置的描述与现状不符** —— 主文件原文「设置是否优先使用扣账支付方式」，现状实为二值开关「是否优先使用微信支付」。已在 4.8.2 就地更正，回灌时须带上。
7. **账号与门店是多对多，规模不小** —— O2O 单账号绑定 13 家以上门店，且列表无搜索。这条事实决定了 [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文的实现复杂度，也决定了切店时的数据清理策略，见 [REQ-MIN-007](#486-业务规则)。**三套系统的门店绑定关系各自维护**（本例延保侧 1 家、O2O 侧另一账号 13+ 家），统一后的权威来源须定。
8. **第七套渠道枚举** —— O2O 客服热线的渠道口径为「小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑」，与 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)（内部四种变体）、[4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)（8 项，含抖音团购轮胎）、[4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)（7 项）、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)（6 个平台渠道 + 同名的品牌授权概念）**均不相同**。至此全仓库已出现**七套渠道枚举**。**强烈建议在第 5 章主数据中定义唯一的渠道枚举，各章节一律引用，不再各写各的。**
9. **A.9 第 1 条的 TODO 编号指错** —— 引用的 `TODO(REQ-MIN-003)`（姓名的权威来源）与收货地址无关，应改为 `TODO(REQ-MIN-014)`。这与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)、[4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)中已发现的 TODO 编号漂移是同一类问题 —— **建议在全文回灌后统一做一次 REQ 编号与 TODO 引用的交叉校验。**
10. **同一件事三套交互** —— 切换门店在 O2O 是整页列表 + 「进入」按钮、在延保是底部滚轮选择器、在 ROOS 的「我的」页则没有入口；深色（延保）与浅色（ROOS / O2O）两套主题；延保用微信原生 picker 导致确定按钮是绿色。App 统一后须固定一种交互与一套主题色。
11. **三套系统对同一个人的称呼各不相同** —— O2O 显示昵称「宛玉」、ROOS 显示手机号 13871477616、延保显示可自由编辑的操作人姓名「史涵」。姓名字段在延保侧是自由文本且编辑弹窗不预填当前值。这是 `TODO(REQ-MIN-003)` 的具体表现，已在 [REQ-MIN-013](#486-业务规则) 中补上校验与预填要求。
12. **手机号在两处未脱敏** —— ROOS「我的」头部直接展示 13871477616，O2O 修改手机号页展示 `134 1969 1597`。这与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)中发现的手机号未脱敏是同一类问题，**建议在第 5 章或安全章节统一规定客户端手机号展示的脱敏规则**。
prd/modules/09-STM-门店管理.md
+477
View File
@@ -0,0 +1,477 @@
# 4.9 门店管理
> **本文件是【门店管理 STM】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.9 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | STM |
| V1.0 章节 | 4.9 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 业务需求 + O2O 店铺管理截图 + 设计稿 |
| 现状承载系统 | O2O（店铺管理、经营范围、协议中心）+ 马上下单（门店主数据）+ App Backend（人员与授权） |
| 需求条数 | 14（待确认 13，完成度 7%） |
| 本次新增待确认 | 7（REQ-STM-008 ~ 014） |
| 配图 | 14 张（设计稿 2 / 现状-O2O 12） |
模块概要
---
**业务目标** —— 门店管理的入口在「我的」菜单，门店管理包括门店的基础信息，人员管理，门店项目信息，营业执照信息等
**入口** —— 「我的」菜单 → 门店管理；宫格版导航中为一级 tab（见[三版底部导航方案](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）
**页面内容** —— 四个 Tab：基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息；另有人员管理、收款信息、经营范围与开票方式、协议中心
**主流程** —— 进入门店管理 → 切换 Tab 查看 → 点击「修改」提交变更 →（如需）等待审核
> **现状有三种互不相同的「修改」交互模型**，见各图说明与 [REQ-STM-007](#496-业务规则)：基础信息 tab **整页只读、无任何修改入口**；2.0 店铺信息 tab 是**逐字段「修改」链接**；营业执照 tab 是**整页「修改执照信息」按钮 + 独立编辑页**。设计稿统一为底部一个「修改」按钮，与现状三种模型都不一致。字段级可编辑性必须逐字段定义。
**权限规则** —— 店长可以修改门店基础信息，添加和修改人员，修改门店项目信息，营业执照信息；**技工基本没有门店管理权限**
**数据来源** —— O2O（店铺管理、经营范围、协议）、马上下单（门店主数据）、App Backend（人员与授权）
## 4.9.1 目标形态
![设计稿-门店管理](../app-design-images/门店管理.png)
**页面内容** —— App 门店管理的设计稿：四个 Tab（**基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息**，当前选中「基础信息」）之下依次是门头照通栏、门店卡、负责人与联系方式、「收款信息 >」入口和一组渠道到期状态（高德、美团均标 **已过期**），底部为描边「修改」按钮。
**关键交互** —— ①点四个 Tab → 切换内容；②点「收款信息 >」→ 进入二级页（现状对应[银行账号](./10-FIN-财务与对账.md#4105-银行账号)）；③点底部「修改」→ 进入编辑态提交变更；④渠道行**本图未见 `>` 或可点标识**，是否可下钻无法确认。
**可用角色** —— 店长 ✅；技工 🔸 只读（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「查看门店信息」为 🔸，「修改基础信息」为 ✗，故技工看到本页时**底部「修改」按钮不可见**，见[验收标准第 1 条](#497-验收标准)）。
**需求关联** —— [REQ-STM-002](#496-业务规则) Tab 口径、[REQ-STM-006](#496-业务规则) 渠道到期提醒、[REQ-STM-007](#496-业务规则) 主数据边界、[REQ-STM-009](#496-业务规则) 渠道口径
> 三处与现状对不上，都需要在开发前定：
>
> 1. **渠道到期状态被放在「基础信息」Tab，而页面上另有一个独立的「渠道信息」Tab。** 同一类信息出现在两个 Tab 里，职责边界不清。现状中这组数据其实在「2.0 店铺信息」Tab 下，而「渠道信息」Tab 装的是完全不同的东西（见 [4.9.2](#492-门店基础信息与渠道信息)）。
> 2. **设计稿只画了 4 个渠道**（高德 / 美团 / 抖音团购 / 百度），现状有 6 个（多出**车点点**与**零跑**）。且设计稿把抖音团购标为「未上线」，现状是「已上线」——**设计稿的渠道数据已过时**。
> 3. **联系方式 13496913568 完整显示未脱敏**，与[银行账号页](./10-FIN-财务与对账.md#4105-银行账号)的脱敏口径问题同源，须统一，见 `TODO(REQ-FIN-014)`。
![设计稿-人员管理](../app-design-images/人员管理.png)
**页面内容** —— App 人员管理的设计稿：顶部是当前操作人卡（带橙色「**店铺管理员**」标签），下方两张店员卡各含姓名、「**店长权限**」标签、「账户设置 >」入口与一行「**可用系统**」图标，底部为通栏「添加店员」，**三张卡姓名相同、图标重复排列，属占位数据**。
**关键交互** —— ①点「账户设置 >」→ 进入该店员的账户与权限设置；②点底部「添加店员」→ 新增店员流程；③「可用系统」图标行**本图未见可点标识**，是在账户设置里配置还是就地可点，无法确认。
**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「人员管理与授权」标为**高风险、需审计**，技工完全不可见，含深链拦截）。
**需求关联** —— [REQ-STM-001](#496-业务规则) 人员授权模型、[REQ-STM-005](#496-业务规则) 技工权限
> **「可用系统」是一个独立于角色的授权维度** —— 它意味着人员授权不是单一角色开关，而是「角色 + 可访问子系统集合」的二维模型（如某店员有店长权限但只开通 O2O 与采购）。这与 [REQ-PUR-001](./06-PUR-采购.md#467-业务规则)（技工采购授权）是同一套机制。可用系统的取值集合、与角色的关系 —— `TODO(REQ-STM-001)`。
> 设计稿另有三处缺口：
>
> 1. **图标没有文字标签**，「可用系统」到底有哪几个系统、每个图标代表谁，从设计稿完全读不出来。这正是 `TODO(REQ-STM-001)` 要解决的取值集合问题 —— 在它关闭前，本页无法进入开发。
> 2. **角色词汇有三套**：本页的「店铺管理员」（当前操作人）与「店长权限」（店员卡），加上[第 3 章](../Continental-Retail-APP-PRD.md#3-利益相关者分析)定义的「店长 / 技工」。三者是同义、包含还是并列，须收敛为一套，否则权限矩阵无法落地。
> 3. **没有一张技工卡片**，也**没有删除或停用店员的入口**。店员离职是门店高频场景，缺了这条链路，人员管理无法闭环。已并入 [REQ-STM-001](#496-业务规则)。
## 4.9.2 门店基础信息与渠道信息
![现状-O2O 店铺管理-基础信息](../mini-program-images/O2O/店铺管理-基础信息.png)
**页面内容** —— O2O 店铺管理的「基础信息」Tab（四个 Tab 为**基础信息 / 2.0店铺信息 / 营业执照信息 / 渠道信息**），内容是门店名称、门店主编码、收款信息、负责人姓名、联系方式、门店地区、详细地址、门店评分、门头照片九行只读字段，**本图为测试数据**（门店名称「豌豆的小店」、负责人「豌豆」）。
**关键交互** —— ①点 Tab → 切换；②点「收款信息 查看详情 >」→ 进入收款信息二级页。**本页没有任何修改入口** —— 整页只读。
**可用角色** —— 店长 ✅；技工 🔸 只读。
**需求关联** —— [REQ-STM-002](#496-业务规则) Tab 口径、[REQ-STM-007](#496-业务规则) 主数据边界
> 与设计稿的字段差异：现状把地址拆成「门店地区 + 详细地址」两个字段，设计稿合并为一个「门店地址」；现状叫「门店主编码」，设计稿叫「门店编码」（编码值 3449155 一致）。这两处属字段口径，以现状为准，并在设计稿评审时提出。
>
> **「收款信息」的模块归属存在冲突**：[附录 A.7](../Continental-Retail-APP-PRD.md#a7-门店管理) 第 6 条把「收款信息结果集（O2O **平安账号模块** —— 企业银行账号、改绑手机、解绑银行卡）」列在**门店管理**名下，而正文把银行账号写在[财务与对账 4.10.5](./10-FIN-财务与对账.md#4105-银行账号) 里；[附录 C 的来源表](../Continental-Retail-APP-PRD.md#附录-c-图表清单)也把两张银行账号截图归到门店管理。**同一份数据在三处被分到两个模块**，须择一。建议按用户心智留在财务模块，[附录 A.7](../Continental-Retail-APP-PRD.md#a7-门店管理) 与[附录 C 来源表](../Continental-Retail-APP-PRD.md#附录-c-图表清单)据此改归 FIN。
![现状-O2O 店铺管理-2.0店铺信息](../mini-program-images/O2O/店铺管理-2.0店铺信息.png)
**页面内容** —— 「2.0 店铺信息」Tab，由**门店联系信息**（每行右侧各有一个橙色「修改」链接）、**渠道上线与到期状态六行**（高德与美团均 **已过期**，零跑按服务项分别记状态）、**门店本地化服务项目价目表**三块组成。
**关键交互** —— ①点任一行的「修改」→ 单独编辑该字段；②点「门店本地化服务项目」的「修改」→ 编辑价目表；③渠道行**无修改入口**，为只读展示。
**可用角色** —— 店长 ✅；技工 ✗（涉及对外报价与渠道状态）。
**需求关联** —— [REQ-STM-002](#496-业务规则) Tab 口径、[REQ-STM-006](#496-业务规则) 渠道到期提醒、[REQ-STM-008](#496-业务规则) 本地化服务项目与自主定价、[REQ-STM-009](#496-业务规则) 渠道口径
> **本图是 STM 模块信息量最大的一张，暴露三件 PRD 完全没写的事：**
>
> 1. **门店可以自主维护一张服务项目价目表**（两列「名称 / 价格」，本图可见泰克贴片补胎 50、泰克蘑菇钉补胎 100、四轮换位 70、普通四轮定位 99、全车手工打蜡-轿车 148、全车手工打蜡-SUV/MPV 198、标准洗车-轿车 30，末行被截断，即**七项以上、价格 30~198 元不等**）。这是门店对外报价的依据，直接影响[销售](./03-SAL-销售.md#43-销售)与[财务收入](./10-FIN-财务与对账.md#4102-收入明细)，PRD 全文一字未提。已记为 [REQ-STM-008](#496-业务规则)。
> 2. **现状渠道有 6 个，且零跑的状态是按服务项分别记的**（「洗车服务已上线，补胎服务已上线」），而其它 5 个是整体「已上线 / 未上线 / 已过期」。**渠道状态模型不统一**，见 [REQ-STM-009](#496-业务规则)。
> 3. **修改是逐字段的**，与设计稿「底部一个修改按钮提交整页」的模型冲突，也与营业执照 Tab 的整页编辑模型冲突。三种模型必须收敛，见 [REQ-STM-007](#496-业务规则)。
>
> 另一处数据疑点：本 Tab 的「联系人」为**宛玉**，而[基础信息 Tab](#492-门店基础信息与渠道信息)的「负责人姓名」为**豌豆**，同一门店两个名字。二者是两个不同角色字段（负责人 ≠ 联系人）还是数据不同步，**本图无法确认**，须在字段口径中明确。
![现状-O2O 店铺管理-渠道信息](../mini-program-images/O2O/店铺管理-渠道信息.png)
**页面内容** —— 「渠道信息」Tab，**页面几乎为空**，只有一个分组标题「渠道资料　（如需申请渠道上下线请联系 **SR**）」与其下「小程序」小节里唯一一行灰色的「维京　关闭」。
**关键交互** —— **本页无任何可交互控件** —— 纯只读展示，渠道上下线需线下联系 SR（马牌销售代表）办理。
**可用角色** —— 店长 ✅ 只读；技工 ✗。
**需求关联** —— [REQ-STM-009](#496-业务规则) 渠道口径与上下线申请
> **「渠道」在同一个页面里有两种完全不同的含义**：
>
> - 「2.0 店铺信息」Tab 里的渠道 = **外部平台**（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑），管的是门店在各引流平台的上线与到期；
> - 「渠道信息」Tab 里的渠道 = **小程序内的品牌线**（小程序 → 维京 关闭），管的是门店能卖哪些品牌。
>
> 两者共用一个词，放在相邻的两个 Tab 里，门店必然混淆。整合进 App 时必须拆成两个术语（如「平台渠道」与「品牌授权」），见 [REQ-STM-009](#496-业务规则)。这也是[全仓库渠道口径不统一](./10-FIN-财务与对账.md#4106-业务规则)问题的一部分。
>
> 另一条可直接成文的规则：**渠道上下线不能自助，须联系 SR**。App 内是保留这条线下指引，还是做成可提交的申请单，需决策。
> 现状 Tab 名为「2.0 店铺信息」，设计稿对应位置为「门店项目信息」。二者是否同一内容 —— `TODO(REQ-STM-002)`。**从截图看两者内容差异很大**：现状的「2.0 店铺信息」含联系信息、渠道状态与服务价目表三块，设计稿的「门店项目信息」未出稿，无从比对。这条待确认必须在设计稿补齐后才能关闭。
## 4.9.3 营业执照信息
![现状-O2O 店铺管理-营业执照信息](../mini-program-images/O2O/店铺管理-营业执照信息.png)
**页面内容** —— 「营业执照信息」Tab，仅营业执照照片、企业名称、统一社会信用代码三行加底部通栏橙色「修改执照信息」按钮，**本图为测试数据**（企业名称与轮胎门店业务无关）。
**关键交互** —— ①点「修改执照信息」→ 进入编辑页（见下图）；②点照片缩略图**是否可放大，本图无法确认**。
**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「修改基础信息 / 项目信息 / 营业执照」为 ✗）。
**需求关联** —— [REQ-STM-003](#496-业务规则) 资质变更审核、[REQ-STM-012](#496-业务规则) 协议中心清单
> **营业执照有两个入口**：本 Tab 与[协议中心](#495-协议中心)（在那里显示为「营业执照　已上传」）。同一份资质在两处维护，状态是否同源、从哪个入口改，须择一为主入口。
![现状-O2O 修改营业执照信息](../mini-program-images/O2O/修改营业执照信息.png)
**页面内容** —— 营业执照编辑页，上半部为「上传营业执照」及三条填写须知与压着「更换图片」的执照缩略图，下半部为「请确认营业信息」的两个可编辑输入框（企业名称、统一社会信用代码，均已带值），底部为通栏橙色「保存」。
**关键交互** —— ①点「更换图片」→ 弹出上传方式选择（见下图）；②点两个输入框 → 直接编辑文本；③点「保存」→ 提交变更。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-STM-003](#496-业务规则) 资质变更审核
> 三条须知原文，均为可校验的规则，须原样保留：①「请确保证件内容文字清晰可见，证件本身无残缺」；②「仅支持中国大陆工商局或市场监督管理局登记的个体工商户或企业，请提供有效期内的营业执照」；③「无企业名称的个体工商户，营业执照–企业名称栏，请填写营业执照–『法人姓名』，示例数据：张三」。
>
> **页面结构是「先传图 → 再确认营业信息」，强烈暗示存在证照 OCR 识别后回填**，但本图两个输入框均为可编辑状态、也没有「识别中」之类的提示，**是否真有 OCR 无法从本图确认**。若确有，需与[车牌 OCR](./03-SAL-销售.md#43-销售)一样明确由后端代理调用、客户端不直连。
>
> **变更后是否需要审核，本页看不出来** —— 点「保存」是直接生效还是转入待审，无任何提示。`TODO(REQ-STM-003)`。
![现状-O2O 修改营业执照信息-上传方式选择](../mini-program-images/O2O/修改营业执照信息-上传方式选择.png)
**页面内容** —— 上一页点「更换图片」后从底部弹出的选择面板，三项：**拍照 / 从手机相册选择 / 取消**。
**关键交互** —— ①点「拍照」→ 唤起相机；②点「从手机相册选择」→ 打开相册；③点「取消」或遮罩 → 关闭。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-STM-003](#496-业务规则) 资质变更审核（[验收标准第 3 条](#497-验收标准)要求两种上传方式并支持弱网重试）
> 本图直接印证[验收标准第 3 条](#497-验收标准)的前半句「支持拍照与相册两种方式」。后半句「弱网下失败可重试且不丢失已填字段」在现状截图中无从验证，属 App 侧新增要求。
> 营业执照变更是否需要审核、审核在哪个系统完成 —— `TODO(REQ-STM-003)`。
## 4.9.4 经营范围与开票方式
![现状-O2O 经营范围与开票方式](../mini-program-images/O2O/经营范围与开票方式.png)
**页面内容** —— 标题为「经营范围」的入口页，全页只有「经营范围 >」与「开票方式　非自行开票 >」两行。
**关键交互** —— ①点「经营范围 >」→ 进入经营范围详情（见下图）；②点「开票方式 >」→ 进入开票方式选择页。
**可用角色** —— 店长 ✅；技工 ✗（涉及资质与资金）。
**需求关联** —— [REQ-STM-010](#496-业务规则) 经营范围三类资质、[REQ-STM-011](#496-业务规则) 开票方式
> 页面标题是「经营范围」，但内容包含并列的「开票方式」，**标题与内容不匹配**。整合到 App 时应重命名为「经营范围与开票」或把开票方式移到财务模块下。
![现状-O2O 经营范围详情](../mini-program-images/O2O/经营范围详情.png)
**页面内容** —— 经营范围详情，由**会员体系门店（待申请）/ 认证轮胎技术检测中心（查看）/ 单独服务项（管理）三个互相独立的资质分组**构成，**其中的服务标签混有大量回归测试数据**。
**关键交互** —— ①点「待申请 >」→ 发起会员体系门店申请（**本图为待申请态，申请表单与流程无法确认**）；②点「查看 >」→ 查看 CATI 认证详情；③点「管理 >」→ 进入[单独服务项开通页](#494-经营范围与开票方式)。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-STM-010](#496-业务规则) 经营范围三类资质
> **三个分组对应三个不同的动词**（待申请 / 查看 / 管理），说明它们是三套独立的资质流程，而不是一张清单的三段：
>
> - **会员体系门店** —— 需申请，有准入门槛（必须具备清单内的全部服务）；
> - **CATI 认证轮胎技术检测中心** —— 由马牌授权，门店只能查看，不能自助申请；
> - **单独服务项** —— 门店可自助逐项开通。
>
> PRD 现有正文只把「经营范围」当作一个归属待定的页面（`TODO(REQ-MIN-006)`），完全没有涉及这三套流程。已记为 [REQ-STM-010](#496-业务规则)。
>
> CATI 定义原文（需在 App 内保留）：「CATI（Continental Approved Tire Inspector）是大陆马牌轮胎（中国）有限公司认证的轮胎技术检测中心。该授权中心能够及时处理客户轮胎投诉以及轮胎售后技术咨询服务。」
![现状-O2O 选择开票方式](../mini-program-images/O2O/选择开票方式.png)
**页面内容** —— 开票方式选择页，「自行开票」与「非自行开票」两张卡片各带一个勾选框、**单选**（当前选中「非自行开票」），卡片下各列若干条说明，底部为通栏橙色「确认」按钮。
**关键交互** —— ①点任一卡片的勾选框 → 切换开票方式（互斥）；②点「确认」→ 提交。**切换是否有二次确认、是否有生效时点限制，本图无法确认**。
**可用角色** —— 店长 ✅；技工 ✗（直接影响资金结算）。
**需求关联** —— [REQ-STM-011](#496-业务规则) 开票方式与 13% 扣除、[REQ-STM-013](#496-业务规则) 百望云初始密码
> **本图是全模块财务影响最大的一张。**「非自行开票」的说明第 1 条写明：「您的服务费货款将**自动扣除 13%**，并将定期打款到您小程序绑定的银行卡。」
>
> 13% 远高于[财务模块列出的全部平台费率](./10-FIN-财务与对账.md#4106-业务规则)（0.6%~4%），却在财务模块的[收入构成](./10-FIN-财务与对账.md#4102-收入明细)里完全看不到 —— 收入详情页只有「通道费」一项扣减。这两笔扣减的关系必须查清，否则门店对不上账。已记为 [REQ-STM-011](#496-业务规则)，并需与 `TODO(REQ-FIN-011)` 一并解决。
>
> 「自行开票」路径引入了一个 PRD 系统清单里没有的第三方系统 —— **百望云**（电子发票平台）：需自备电子发票资质、登录百望云完善开票信息、另填并上传对公银行信息。星号补充「登陆接单宝小程序，点击『协议中心』查看百望云初始账户密码」既是[又一处「请回小程序」的引导](./10-FIN-财务与对账.md#4103-服务结算单)，也是一处**安全问题**，见 [REQ-STM-013](#496-业务规则)。
>
> 另注：「非自行开票」说明第 2 条「请确认您已将收款方式转成银行卡收款，如需修改收款。」**句子未写完**，属现状文案缺陷，App 内须补全。
![现状-O2O 单独服务项开通情况](../mini-program-images/O2O/单独服务项开通情况.png)
**页面内容** —— 单独服务项开通页，主体是 7 行服务项开关（部分名称右侧带橙色「**会员**」小标，**其中 3 项是回归测试数据**），底部为一行协议勾选加通栏橙色「保存」。
**关键交互** —— ①逐项点开关 → 开通 / 关闭该服务；②点协议名称 → 打开协议全文；③勾选协议后点「保存」→ 提交。**未勾选协议时「保存」是否禁用，本图无法确认**。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-STM-010](#496-业务规则) 经营范围三类资质、[REQ-STM-004](#496-业务规则) 协议体系
> 两条可直接成文的规则：①**开通服务项须先同意《德国马牌门店非轮胎项目服务协议》**，协议同意与服务开通是同一次提交；②**带「会员」标记的服务项归属会员体系**，与上一页「会员体系门店必须包含以下服务」的清单存在交集 —— 单独开通这些项与申请会员体系门店是什么关系（前置条件？自动满足？），须明确。
>
> 这条协议同时说明[协议中心](#495-协议中心)不是唯一的协议入口 —— 协议也会内嵌在业务动作里，[REQ-STM-004](#496-业务规则) 的「协议体系是否合并」需要把这类内嵌协议一并纳入考虑。
> 经营范围在设计稿中被放进了[个人中心](./08-MIN-我的.md#481-目标形态)，在现状中属于店铺管理。归属待定 —— `TODO(REQ-MIN-006)`。
## 4.9.5 协议中心
![现状-O2O 协议中心](../mini-program-images/O2O/协议中心.png)
**页面内容** —— 协议中心，营业执照（已上传）与三份协议（均已签署）共四张卡片纵向排列、下方接 4 条说明，**本图四项均为完成态**，未签署 / 未上传的形态无法确认。
**关键交互** —— ①点任一卡片 → 打开对应协议全文或执照详情（见下图）；②**已签署项是否可重新签署、未签署项如何发起签署，本图无法确认**。
**可用角色** —— 店长 ✅；技工 🔸 只读（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「协议中心」为 🔸）。
**需求关联** —— [REQ-STM-004](#496-业务规则) 协议体系、[REQ-STM-012](#496-业务规则) 协议中心清单与状态、[REQ-STM-013](#496-业务规则) 百望云初始密码
> 四条说明原文：①「如您的门店已参与德国马牌的非轮胎活动，请确认您已签署相关服务协议」；②「如果您参与非轮胎项目，且选择了自行开票，请注意及时上传对公银行账户信息」；③「如果您未参与非轮胎项目或您参与了非轮胎项目后，选择的是『非自行开票』，则无需维护对公银行账户信息」；④「**百望云账号密码仅为初始密码，登录后请及时修改**」。
>
> 说明 ②③ 把**协议中心 ↔ [开票方式](#494-经营范围与开票方式) ↔ [对公银行账户](./10-FIN-财务与对账.md#4105-银行账号)**三者锁在一起：是否需要维护对公账户，取决于「是否参与非轮胎项目」与「开票方式选哪种」的组合。这套判定逻辑必须在 App 内成文，否则门店不知道自己该不该填银行信息。
>
> 说明 ④ 与[开票方式页](#494-经营范围与开票方式)的星号补充合起来意味着：**协议中心是一个第三方系统初始密码的分发渠道**。密码明文常驻在一个门店随时可进的页面里，风险明显。已记为 [REQ-STM-013](#496-业务规则)。
>
> 另注**状态词有两套**：营业执照用「已上传」，三份协议用「已签署」。它们的完成条件与法律效力不同，混在一张列表里易误解，App 内建议分组或补充状态说明。
![现状-O2O 小程序线下门店合作协议](../mini-program-images/O2O/小程序线下门店合作协议.png)
**页面内容** —— 《德国马牌轮胎小程序线下门店合作协议》全文页，开头为甲方（大陆马牌轮胎（中国）有限公司，简称"德国马牌"）与**空白的乙方**，其后本屏可见「乙方需履行以下几项义务」的第 1~9 条（第 9 条被截断）。
**关键交互** —— **无交互，仅作内容佐证**；页面为可滚动长文，本图未见「同意」「签署」按钮（该协议已处于已签署态）。
**可用角色** —— 店长 ✅ 只读；技工 🔸 只读。
**需求关联** —— [REQ-STM-004](#496-业务规则) 协议体系、[REQ-STM-014](#496-业务规则) 合作协议义务的系统承接
> **协议正文里有三条可被系统承接的门店义务**，目前 PRD 里一条都没有对应功能：
>
> - 第 1 条：「由德国马牌轮胎小程序引流产生的轮胎销售必须在**下月 15 号前**从当地认证经销商处完成补货。」—— 一条带明确截止日的周期性义务，天然适合做成[提醒](./04-RMD-提醒.md#44-提醒)或[首页待办](./02-HOM-APP首页与导航.md#423-店长首页)。
> - 第 5 条：「乙方需要在轮胎安装前向终端消费者索取**安装码**，并核销。」—— 与[销售模块的核销](./03-SAL-销售.md#434-核销)是同一动作，且核销又是[可提现金额](./10-FIN-财务与对账.md#4101-对账提现)的计算基数，三者须口径一致。
> - 第 7 条：「如终端消费者需要开具发票，乙方必须按终端消费者实际支付金额开具……不得以任何理由拒绝开具发票。」—— 与[开票方式](#494-经营范围与开票方式)的选择相互作用。
>
> 已记为 [REQ-STM-014](#496-业务规则)。
>
> **「乙方」栏空白但状态显示「已签署」** —— 本页展示的可能是协议模板而非门店签署后的实例。App 内应展示带乙方主体与签署时间的实例，否则「已签署」无从取证。**本图无法确认**该页是否另有签署信息区被折叠。
> 协议中心与[延保零售商使用条款](./05-WTY-延保.md#451-保障产品与责任边界)是两套独立的协议体系，整合后是否合并为统一的「协议与条款」入口 —— `TODO(REQ-STM-004)`。**V1.1 逐图核对发现协议实际有三类**：协议中心的 4 项、内嵌在业务动作里的《德国马牌门店非轮胎项目服务协议》、以及延保条款。合并方案需覆盖全部三类。
## 4.9.6 业务规则
**REQ-STM-001 人员授权模型** —— 角色 + 可用系统的二维授权，取值集合待定 `TODO(REQ-STM-001)`。**同时需补齐**：可用系统的图标与文案对照、店员的删除 / 停用链路、以及「店铺管理员 / 店长权限 / 店长·技工」三套角色词汇的收敛
**REQ-STM-002 Tab 口径** —— 「2.0 店铺信息」与「门店项目信息」的对应关系待定 `TODO(REQ-STM-002)`
**REQ-STM-003 资质变更审核** —— 营业执照等资质变更的审核流程待定 `TODO(REQ-STM-003)`。上传须知三条须原样保留；上传支持拍照与相册
**REQ-STM-004 协议体系** —— 协议中心与延保条款是否合并待定 `TODO(REQ-STM-004)`。合并方案须覆盖三类协议：协议中心 4 项、业务动作内嵌协议、延保条款
**REQ-STM-005 技工权限** —— 技工基本无门店管理权限，仅可只读查看门店基础信息
**REQ-STM-006 渠道到期提醒** —— 高德 / 美团 / 抖音 / 百度等渠道到期应产生[首页待办或预警](./02-HOM-APP首页与导航.md#423-店长首页) `TODO(REQ-STM-006)`
**REQ-STM-007 主数据边界** —— 门店主数据来源为马上下单（[第 5 章](../Continental-Retail-APP-PRD.md#5-主数据)），App 内可改的字段范围待定 `TODO(REQ-STM-007)`。**须同时定义修改交互模型** —— 现状三种模型并存（基础信息只读 / 2.0 店铺信息逐字段改 / 营业执照整页改），App 内须统一，并逐字段标注可编辑性
**REQ-STM-008 门店本地化服务项目与自主定价** —— 门店可在「2.0 店铺信息」下维护一张本地化服务项目价目表（名称 + 价格，现状可见泰克贴片补胎 50、四轮换位 70、全车手工打蜡-SUV/MPV 198 等七项以上），带独立编辑入口。该价目表是门店对外报价依据，须在 App 内可查可改。
> **待确认** `TODO(REQ-STM-008)`：①价格是否有上下限管控或需审核；②与[经营范围「单独服务项」](#494-经营范围与开票方式)的关系（同一批服务项还是两套清单）；③与[销售](./03-SAL-销售.md#43-销售)开单时的取价关系 —— 开单是否直接引用这张价目表。
**REQ-STM-009 渠道口径与上下线申请** —— 「渠道」须拆分为两个互不相同的概念并分别命名：**平台渠道**（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑，管上线与到期）与**品牌授权**（小程序下的品牌线，如维京，管可售品牌）。渠道上下线**不支持自助，须联系 SR**，该指引须在 App 内保留。
> **待确认** `TODO(REQ-STM-009)`：①两个概念的最终命名与页面归属（现状分散在「2.0 店铺信息」与「渠道信息」两个 Tab，设计稿又把平台渠道画在「基础信息」Tab）；②**渠道状态模型不统一** —— 零跑按服务项分别记状态（洗车已上线 / 补胎已上线），其余按渠道整体记；③平台渠道枚举须与[财务](./10-FIN-财务与对账.md#4106-业务规则)、[返利](./11-RBT-返利中心.md#4113-多维筛选)、[业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)统一，收敛进[主数据](../Continental-Retail-APP-PRD.md#5-主数据)；④渠道上下线申请是否做成 App 内可提交的申请单。
**REQ-STM-010 经营范围的三类资质** —— 经营范围由三套独立流程构成，须分别落地：**会员体系门店**（需申请，准入条件为具备指定服务清单，现状为「待申请」）、**CATI 认证轮胎技术检测中心**（马牌授权，门店只可查看）、**单独服务项**（门店自助逐项开关）。单独服务项的开通须同时勾选同意《德国马牌门店非轮胎项目服务协议》，协议同意与开通为同一次提交；带「会员」标记的服务项归属会员体系。
> **待确认** `TODO(REQ-STM-010)`：①会员体系门店的申请表单、审核方与时效；②CATI 认证是否有 App 内可发起的路径，还是纯线下授权；③单独开通带「会员」标记的服务项与申请会员体系门店之间是前置、等价还是无关。
**REQ-STM-011 开票方式与 13% 扣除** —— 开票方式为二选一：**自行开票**（需自备服务费电子发票资质、登录**百望云**完善开票信息、填写并上传对公银行信息）与**非自行开票**（**服务费货款自动扣除 13%**，定期打款到小程序绑定的银行卡）。两种方式的说明条文须原样展示；「非自行开票」路径下无需维护对公银行账户。
> **待确认** `TODO(REQ-STM-011)`：①**13% 与[财务模块的通道费 / 平台手续费是什么关系](./10-FIN-财务与对账.md#4106-业务规则)** —— 现状收入详情只显示通道费，13% 无处体现，门店无法对账，须与 `TODO(REQ-FIN-011)` 一并解决；②百望云是否需要在 App 内打通，还是保留外跳；③切换开票方式的生效时点、是否可反复切换、对已生成结算单的影响。
**REQ-STM-012 协议中心的清单与状态** —— 协议中心承载 4 项：营业执照（状态「已上传」）与三份协议（小程序轮胎合作协议 / 非轮胎项目服务协议 / 认证轮胎技术检测中心合作协议，状态「已签署」）。营业执照同时存在于[营业执照信息 Tab](#493-营业执照信息)，两处须同源并指定唯一编辑主入口。协议正文须可完整查看。
> **待确认** `TODO(REQ-STM-012)`：①**未签署 / 未上传态的形态与签署交互**（现状截图四项均为完成态，无从确认）；②签署是否需要电子签名与留痕，是否计入[审计日志](../Continental-Retail-APP-PRD.md#6-后台管理)；③协议全文页应展示签署实例（含乙方主体与签署时间），现状展示的疑似模板，「乙方」栏为空。
**REQ-STM-013 第三方系统初始密码不得明文承载** —— 现状把「百望云账号初始密码」放在协议中心供门店自行查看。**App 内不得以明文常驻方式展示任何第三方系统的账号密码。**
> **待确认** `TODO(REQ-STM-013)`：替代方案待定 —— 一次性查看后失效、改由后台按需重置下发、或 App 完全不承载（仅保留百望云官方找回路径）。决策方：安全 / 产品。
**REQ-STM-014 合作协议义务的系统承接** —— 《德国马牌轮胎小程序线下门店合作协议》中的可执行义务须由系统承接而非仅靠门店自觉：①小程序引流产生的轮胎销售须在**下月 15 号前**从当地认证经销商完成补货；②安装前须向消费者索取**安装码**并核销；③消费者要求开票时不得拒绝。
> **待确认** `TODO(REQ-STM-014)`：①「下月 15 号前补货」是否做成周期性[提醒](./04-RMD-提醒.md#44-提醒)或[首页待办](./02-HOM-APP首页与导航.md#423-店长首页)，未完成是否需要预警；②协议中的「安装码」与[销售模块的核销码](./03-SAL-销售.md#434-核销)是否同一物，术语须统一；③三条义务是否需要在管理后台侧有对应的监控或考核。
## 4.9.7 验收标准
1. 技工进入门店管理时，所有「修改」「添加店员」入口不可见；
2. 门店编码、门店名称等主数据字段为只读，与马上下单一致；
3. 营业执照上传支持拍照与相册两种方式，弱网下失败可重试且不丢失已填字段；
4. 渠道到期状态与实际签约状态一致，已过期渠道有明显视觉标记；
5. 每个可编辑字段都有明确的可编辑标识，修改交互模型全 App 统一，不出现「同一页面部分字段逐个改、部分字段整页改」（[REQ-STM-007](#496-业务规则)）；
6. 「平台渠道」与「品牌授权」在文案上明确区分，不出现两处都叫「渠道」的情况（[REQ-STM-009](#496-业务规则)）；
7. 单独服务项未勾选协议时「保存」不可提交，协议全文可从勾选行直接打开（[REQ-STM-010](#496-业务规则)）；
8. 开票方式页完整展示两种方式的全部说明条文，含 13% 扣除比例，且文案完整无断句（[REQ-STM-011](#496-业务规则)）；
9. App 内任何页面不出现第三方系统的明文账号密码（[REQ-STM-013](#496-业务规则)）；
10. App 内所有门店管理页面**不出现「请登录接单宝小程序」类引导**，全部改为 App 内路径（[REQ-STM-011](#496-业务规则)）。
> 第 5~10 条为本次逐图核看后新增。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.7）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 门店基础数据结果集 | Mini Program Backend | HTTPS | 调用**马上下单**后台接口 |
| 2 | 门店服务信息数据结果集 | Mini Program Backend | HTTPS | 马上下单 |
| 3 | 营业执照信息结果集 | Mini Program Backend | HTTPS | 马上下单 |
| 4 | 渠道信息结果集 | Mini Program Backend | HTTPS | 马上下单 |
| 5 | 经营范围信息结果集 | Mini Program Backend | HTTPS | **O2O** —— 会员体系开通、CATI 开通、单独服务项、开票方式 |
| 6 | 收款信息结果集 | Mini Program Backend | HTTPS | **O2O 平安账号模块** —— 企业银行账号、改绑手机、解绑银行卡 |
| 7 | 门店员工列表结果集 / 员工详细信息 | Mini Program Backend | HTTPS | 马上下单 |
门店管理模块数据集（摘自主文件[附录 A.7](../Continental-Retail-APP-PRD.md#a7-门店管理)）。这是各模块中附录 A 覆盖最完整的一节，7 条基本覆盖了本模块的页面。
三处需要在回灌时处理：
1. **第 6 条「收款信息结果集」应归入[财务与对账](./10-FIN-财务与对账.md#4105-银行账号)** —— 正文把银行账号写在 4.10.5，附录 A.7 与[附录 C 的来源表](../Continental-Retail-APP-PRD.md#附录-c-图表清单)却把它归到门店管理。同一份数据在三处被分到两个模块，须择一。另注意本条揭示了银行账号模块的现状名称是「**平安账号**」，这正是 [10.3 的 C11](../Continental-Retail-APP-PRD.md#103-跨文档阻塞项) 里列为「无归属」的那个功能 —— 它其实已经有归属了。
2. **第 4 条「渠道信息结果集」写的是马上下单**，但现状「渠道信息」Tab 展示的是小程序品牌授权（维京），而平台渠道状态在「2.0 店铺信息」Tab 下。[REQ-STM-009](#496-业务规则) 拆分两个概念后，这一条也须拆成两个数据集并分别标注来源。
3. **缺两个数据集**：本次拆分发现的**门店本地化服务项目价目表**（[REQ-STM-008](#496-业务规则)）与**协议签署状态**（[REQ-STM-012](#496-业务规则)）在 A.7 中无对应条目，须补。前者来源为 O2O，后者为 O2O 协议中心。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 查看门店信息 | ✅ | 🔸 | 技工只读，基本无门店管理权限 |
| 修改基础信息 / 项目信息 / 营业执照 | ✅ | ✗ | |
| **人员管理与授权** | ✅ | ✗ | 高风险，需审计 |
| 协议中心 | ✅ | 🔸 | 技工只读 |
门店管理模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](#491-目标形态)授予（REQ-ACC-005，其取值集合正是 `TODO(REQ-STM-001)`）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本次拆分建议为矩阵**补三行**：
>
> - **经营范围与资质申请**（店长 ✅ / 技工 ✗）—— 会员体系门店申请、单独服务项开关，涉及门店对外承诺；
> - **开票方式**（店长 ✅ / 技工 ✗）—— 直接影响 13% 扣除与打款账户，风险等级等同财务操作，不宜并入「查看门店信息」；
> - **本地化服务项目定价**（店长 ✅ / 技工 ✗）—— 对外报价依据。
>
> 另需注意：本模块的 🔸 有两种含义 ——「查看门店信息」的 🔸 指技工可看基础信息但看不到修改入口，「协议中心」的 🔸 指技工可读协议全文。两者实现方式不同，回灌时建议在备注中写清。
### 附-3 待确认项（主文件 10.2.9 + 本次新增）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-STM-001 | **「可用系统」授权模型**（取值集合、与角色的关系）；另需补店员删除 / 停用链路与三套角色词汇的收敛 | 架构 / 产品 |
| REQ-STM-002 | 「2.0 店铺信息」与「门店项目信息」的对应关系（设计稿未出稿，须补稿后才能比对） | 业务 |
| REQ-STM-003 | 营业执照等资质变更的审核流程；是否存在证照 OCR 识别回填 | 运营 |
| REQ-STM-004 | 协议中心与延保条款是否合并（须覆盖三类协议） | 法务 / 产品 |
| REQ-STM-006 | 渠道到期是否产生首页待办或预警（主文件误标为 REQ-STM-007） | 产品 |
| REQ-STM-007 | 门店主数据中 App 内可编辑的字段范围；修改交互模型的统一（主文件误标为 REQ-STM-008） | 架构 |
| **REQ-STM-008** | 本地化服务项目定价是否需管控 / 审核；与「单独服务项」和销售取价的关系 | 业务 / 产品 |
| **REQ-STM-009** | 「平台渠道」与「品牌授权」的拆分命名与归属；零跑的分服务项状态模型；**平台渠道枚举统一**；SR 申请是否进 App | 产品 / 主数据 |
| **REQ-STM-010** | 会员体系门店的申请流程与审核方；CATI 是否可 App 内发起；「会员」标记服务项与会员体系门店的关系 | 运营 / 业务 |
| **REQ-STM-011** | **13% 扣除与财务通道费 / 平台手续费的关系**；百望云是否打通；开票方式切换的生效时点与限制 | 财务 |
| **REQ-STM-012** | 协议未签署态的签署交互；是否需电子签名与审计留痕；协议实例（乙方 + 签署时间）的展示 | 法务 / 架构 |
| **REQ-STM-013** | 百望云初始密码的替代承载方案（一次性查看 / 后台重置 / 不承载） | 安全 / 产品 |
| **REQ-STM-014** | 「下月 15 号前补货」是否做成提醒或待办；「安装码」与核销码是否同一物；三条协议义务是否需后台监控 | 业务 / 产品 |
门店管理模块待确认项，共 13 条（主文件 [10.2.9](../Continental-Retail-APP-PRD.md#1029-门店管理stm) 原 6 条 + 本次新增 7 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.9，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 STM 行（8 / 6 / 25% → **14 / 13 / 7%**）与第 10.2 节总数。
> 回灌 10.2.9 时须同时把原表中「REQ-STM-007 渠道到期」「REQ-STM-008 主数据边界」两行改号为 006 / 007，详见 [4.9.6 的编号错位说明](#496-业务规则)。
>
> 完成度 7% 是本模块的真实状态：7 条既有需求里只有 REQ-STM-005（技工权限）没有待确认，新增的 7 条全部带 TODO。这不代表本模块难做，而是**它的需求此前几乎只有截图没有正文** —— 91 行正文承载 14 张图，其中 12 张此前没有任何文字说明。新增的 7 条里 REQ-STM-008、010、011、012、014 的**事实部分已由截图确认**，待确认的是流程归属与跨模块口径。
### 附-4 配图清单（主文件附录 C 4.9 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-门店管理（四 Tab + 门头照 + 门店卡 + 收款信息入口 + **渠道到期状态放在基础信息 Tab**；渠道只有 4 个且数据已过时） | `../app-design-images/门店管理.png` |
| 2 | 设计稿-人员管理（**占位数据**：三卡同名、可用系统 4 图标为两组重复；**无技工卡、无删除店员入口**；角色词汇「店铺管理员」与「店长权限」并存） | `../app-design-images/人员管理.png` |
| 3 | 现状-O2O 店铺管理基础信息（九字段；**整页只读、无修改入口**；测试数据「豌豆的小店」） | `../mini-program-images/O2O/店铺管理-基础信息.png` |
| 4 | 现状-O2O 店铺管理 2.0 店铺信息（**逐字段修改**；6 个平台渠道含车点点与零跑；**门店本地化服务项目价目表**） | `../mini-program-images/O2O/店铺管理-2.0店铺信息.png` |
| 5 | 现状-O2O 店铺管理渠道信息（**几乎空页**；实为小程序品牌授权「维京 关闭」，与平台渠道同名异义；「渠道上下线请联系 SR」） | `../mini-program-images/O2O/店铺管理-渠道信息.png` |
| 6 | 现状-O2O 店铺管理营业执照信息（仅照片 + 企业名称 + 统一社会信用代码；**测试数据**为一家 IT 公司） | `../mini-program-images/O2O/店铺管理-营业执照信息.png` |
| 7 | 现状-O2O 修改营业执照信息（三条填写须知；「更换图片」+ 两个可编辑输入框；**是否有 OCR 回填无法确认**） | `../mini-program-images/O2O/修改营业执照信息.png` |
| 8 | 现状-O2O 修改营业执照信息上传方式选择（拍照 / 从手机相册选择 / 取消） | `../mini-program-images/O2O/修改营业执照信息-上传方式选择.png` |
| 9 | 现状-O2O 经营范围与开票方式（两行入口页；**标题「经营范围」与内容含开票方式不匹配**） | `../mini-program-images/O2O/经营范围与开票方式.png` |
| 10 | 现状-O2O 经营范围详情（**三类资质**：会员体系门店「待申请」/ CATI「查看」/ 单独服务项「管理」；含 CATI 定义原文；**大量回归测试数据**） | `../mini-program-images/O2O/经营范围详情.png` |
| 11 | 现状-O2O 选择开票方式（单选；**非自行开票自动扣除 13%**；自行开票需登录**百望云**；含一句未写完的文案） | `../mini-program-images/O2O/选择开票方式.png` |
| 12 | 现状-O2O 单独服务项开通情况（7 个开关，3 个为回归测试数据；带「会员」标记；**保存前须勾选同意非轮胎项目服务协议**） | `../mini-program-images/O2O/单独服务项开通情况.png` |
| 13 | 现状-O2O 协议中心（4 项：营业执照「已上传」+ 三份协议「已签署」；**四条说明含百望云初始密码提示**；**未签署态无截图**） | `../mini-program-images/O2O/协议中心.png` |
| 14 | 现状-O2O 小程序线下门店合作协议（甲乙方 + 九条门店义务，含**下月 15 号前补货**、**索取安装码并核销**、不得拒开发票；**乙方栏空白**） | `../mini-program-images/O2O/小程序线下门店合作协议.png` |
门店管理模块配图清单，14 张（设计稿 2 / 现状-O2O 12）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容大幅补充 —— 原清单中第 4~14 行基本是文件名的复述，主文件附录 C 回灌时应一并更新。
**本模块配图的四处硬缺口**：
- **设计稿只覆盖 2 个页面**（门店管理首页、人员管理），且两张都是占位数据。四个 Tab 里只出了「基础信息」一个，「门店项目信息 / 营业执照信息 / 渠道信息」三个 Tab 全部未出稿 —— 这直接导致 `TODO(REQ-STM-002)` 无法比对、无法关闭。
- **人员管理的关键信息全是占位**：三张卡同名、可用系统只有重复图标无文字、全部是「店长权限」没有技工样例。这一页在设计稿补齐前无法开发。
- **回归测试数据污染严重**：经营范围与单独服务项两页共 13 个服务标签中，「测试无需领取的 / 回归531会员 / 全回归1028 / 回归测试 / 回归521 / 回归531单项」6 个是 QA 数据，占了近一半，真实服务项清单无法从截图确认。
- **缺三类关键截图**：①协议**未签署 / 未上传态**与签署交互（卡 `TODO(REQ-STM-012)`）；②会员体系门店的**申请表单**（现状为「待申请」，点进去是什么完全未知，卡 `TODO(REQ-STM-010)`）；③营业执照保存后的**审核状态提示**（卡 `TODO(REQ-STM-003)`）。这三处补采成本不高，建议优先。
### 附-5 本次拆分新增发现
逐张核看 14 张配图后，新增 **7 条编号需求**（REQ-STM-008 ~ 014）、**修订 3 处既有内容**、发现 **1 处编号错位 + 1 处 D.2 计数错误**，另记 **6 条无编号观察**。
**新增需求**：
| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-STM-008 | 本地化服务项目与自主定价 | 2.0 店铺信息 Tab 下的「门店本地化服务项目」价目表（七项以上，带独立修改入口） |
| REQ-STM-009 | 渠道口径与上下线申请 | 「渠道」二义（平台渠道 6 个 vs 小程序品牌授权）+ 零跑分服务项状态 + 「上下线请联系 SR」 |
| REQ-STM-010 | 经营范围的三类资质 | 经营范围详情的三个分组与三个动词（待申请 / 查看 / 管理）+ 单独服务项的协议勾选 |
| REQ-STM-011 | 开票方式与 13% 扣除 | 选择开票方式页两张卡片的全部说明条文 |
| REQ-STM-012 | 协议中心的清单与状态 | 协议中心 4 项 + 两套状态词 + 营业执照双入口 + 合作协议「乙方」空白 |
| REQ-STM-013 | 第三方系统初始密码不得明文承载 | 协议中心说明第 4 条 + 开票方式页星号补充（百望云初始密码） |
| REQ-STM-014 | 合作协议义务的系统承接 | 合作协议第 1 / 5 / 7 条（下月 15 号前补货、索取安装码并核销、不得拒开发票） |
**修订的既有内容**：
1. **主流程补入「三种修改交互模型」的说明** —— 现状基础信息只读、2.0 店铺信息逐字段改、营业执照整页改，设计稿又是底部单按钮提交整页，四者互不相同。已并入 [REQ-STM-007](#496-业务规则) 并新增[验收标准第 5 条](#497-验收标准)。
2. **REQ-STM-001 扩容** —— 除原有的「可用系统取值集合」外，补入店员删除 / 停用链路缺失、以及「店铺管理员 / 店长权限 / 店长·技工」三套角色词汇需收敛两项。
3. **REQ-STM-004 的范围扩大** —— 协议实际有三类（协议中心 4 项、业务动作内嵌协议、延保条款），原表述只提了前两者中的一个与延保条款。
**发现的编号问题**：
- **编号错位** —— REQ-STM-006 / 007 分别挂着 `TODO(REQ-STM-007)` / `TODO(REQ-STM-008)`，10.2.9 也沿用了错号。按「正文规则编号为准」修正为 006 / 007。
- **D.2 计数错误** —— STM 行写「需求条数 8」，但正文只有 REQ-STM-001~007 共 7 条且无空号。「8」应是被上述错位带偏的结果，回灌时改为 7（叠加本次新增后为 14）。
**无编号观察**（属现状材料问题，不新增需求）：
1. **同一门店两个名字** —— 基础信息 Tab 的「负责人姓名 豌豆」与 2.0 店铺信息 Tab 的「联系人 宛玉」。是两个不同角色字段还是数据不同步，**本图无法确认**，须在字段口径中明确。
2. **设计稿渠道数据已过时** —— 抖音团购在设计稿标「未上线」，现状为「已上线」；设计稿还漏了车点点与零跑两个渠道。
3. **手机号未脱敏** —— 设计稿 13496913568、现状 13419691597 均完整显示，与[银行账号页](./10-FIN-财务与对账.md#4105-银行账号)的脱敏口径问题同源，须统一处理。
4. **页面标题与内容不匹配** —— 「经营范围」页实际含并列的「开票方式」。
5. **现状文案有断句** —— 开票方式页「请确认您已将收款方式转成银行卡收款，如需修改收款。」句子未写完。
6. **服务项名称混有回归测试数据** —— [经营范围详情](#494-经营范围与开票方式)与[单独服务项开通页](#494-经营范围与开票方式)的服务标签里实测混有 `测试无需领取的` / `回归531会员` / `全回归1028` / `回归测试` / `回归521` / `回归531单项` 六个非真实服务项，单独服务项开通页 7 行开关中有 3 行属此类。这批数据由 O2O 侧维护，清理属 O2O 责任，本 PRD 不为此提需求，仅提示**勿据这两张图统计服务项数量**。与[营销与会员](./13-MKT-营销与会员.md#4132-会员权益)的会员体系开通引导页是同一份服务清单、同一批脏数据。
另有一条跨模块的归属问题需要在回灌时裁决：**「收款信息 / 银行账号（O2O 平安账号模块）」在正文中属[财务 4.10.5](./10-FIN-财务与对账.md#4105-银行账号)，在[附录 A.7](#附-1-业务数据字典主文件附录-a7) 与附录 C 来源表中却属门店管理**，且设计稿的门店管理首页确实有「收款信息 >」入口。建议：**数据与页面归 FIN，门店管理保留一个跳转入口**，附录 A.7 第 6 条与来源表相应改归 FIN。同时这也解决了 [10.3 的 C11](../Continental-Retail-APP-PRD.md#103-跨文档阻塞项) 中「平安账号无归属」一项 —— 它已经有归属了，只是记在了两个地方。
prd/modules/10-FIN-财务与对账.md
+424
View File
@@ -0,0 +1,424 @@
# 4.10 财务与对账
> **本文件是【财务与对账 FIN】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.10 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | FIN |
| V1.0 章节 | 4.10 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状截图反推 |
| 现状承载系统 | O2O（收入 / 提现 / 结算单 / 银行账号）+ ROOS（采购对账单） |
| 需求条数 | 14（待确认 12，完成度 14%） |
| 本次新增待确认 | 7（REQ-FIN-008 ~ 014） |
| 配图 | 11 张（现状-O2O 10 / 现状-ROOS 1，**无设计稿**） |
模块概要
---
本节内容由 O2O 与 ROOS 的对账 / 提现 / 结算截图反推。**本模块没有任何设计稿** —— 11 张图全部是现状小程序，App 目标形态尚未出稿。
**业务目标** —— 让门店在 App 内看清「挣了多少、能提多少、什么时候到账、和厂商怎么对账」，解决[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销)与[痛点 2.5](../Continental-Retail-APP-PRD.md#25-数据经营分析)
**入口** —— 「我的」菜单 → 对账提现 / 对账单；宫格版导航中为一级 tab「账务对账」
**页面内容** —— 对账提现（可提现金额 + 收入 + 提现历史）、收入明细、服务结算单、结算单明细、采购对账单、银行账号绑定
**主流程**：
- 查看可提现金额 → 进入收入 / 提现历史核对 → **系统按工作日自动提现** → 到账（**门店不主动发起提现**，见 [REQ-FIN-008](#4106-业务规则)）
- 结算侧：按周期查看服务结算单 → 核对明细 → **在本月 7 号前确认结算单**（逾期自动确认，见 [REQ-FIN-012](#4106-业务规则)）
- 采购侧：按月查看对账单 → 核对汇总与明细
**权限规则** —— **建议限店长**（涉及资金）`TODO(REQ-FIN-001)`
**数据来源** —— O2O（O2O 收入、提现、服务结算单、银行账号）、ROOS（采购对账单）
## 4.10.1 对账提现
![现状-O2O 对账提现](../mini-program-images/O2O/对账提现.png)
**页面内容** —— O2O 对账提现首页，橙色头部为「¥0.00 / 可提现金额（元）」与一段说明更新时点的注解，下方是「收入 >」「提现历史 >」两个入口行与蓝色文字链「交易手续费说明」，**本截图为 ¥0.00 空态**。
**关键交互** —— ①点「收入」→ 进入[收入明细](#4102-收入明细)；②点「提现历史」→ 进入提现流水；③点「交易手续费说明」→ 弹出费率说明（见下图）。
**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵) 为 ✗，且 `TODO(REQ-FIN-001)` 关闭前一律按技工完全不可见实现，含深链拦截）。
**需求关联** —— [REQ-FIN-002](#4106-业务规则) 可提现金额口径、[REQ-FIN-006](#4106-业务规则) 手续费透明、[REQ-FIN-008](#4106-业务规则) 提现由系统自动发起
> **本页没有「提现」按钮。** V1.0 的 4.10 主流程写「查看可提现金额 → 进入收入/提现历史核对 → **发起提现** → 到账」，但页面上只有两个查看入口与一个说明链接，没有任何可以发起提现的控件。结合下一张手续费说明中「每个工作日 15:30 左右系统将自动发起提现，将账户余额全部提出」，可以确认：**提现是系统自动执行的，门店不主动发起**。上方主流程已据此改写，并新增 [REQ-FIN-008](#4106-业务规则)。
> 顶部注解揭示两条关键约束：① 提现金额 **T+1 且按工作日**更新；② 计入基数的是**已核销**订单货款 —— 这把[核销](./03-SAL-销售.md#434-核销)从一个操作动作提升为资金链路的关键节点。核销 → 可提现的具体计算口径 —— `TODO(REQ-FIN-002)`。
![现状-O2O 对账提现-交易手续费说明](../mini-program-images/O2O/对账提现-交易手续费说明.png)
**页面内容** —— 从底部弹出的「交易手续费说明」面板，按「小程序订单」「天猫/京东/拼多多订单」「抖音小店订单」「抖音团购」四段列出结算与费率规则，**最后一段被底部按钮遮挡，本图无法确认其内容**。
**关键交互** —— ①滚动查看各渠道规则；②点右上 ✕ 或底部「确认」→ 关闭。纯内容展示，无其它交互。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-FIN-006](#4106-业务规则) 手续费透明、[REQ-FIN-008](#4106-业务规则) 自动提现、[REQ-FIN-009](#4106-业务规则) 分渠道结算机制与费率
> 本图可辨认的规则全文如下，是 [REQ-FIN-009](#4106-业务规则) 的直接依据：
>
> - **小程序订单**：①每个工作日 15:30 左右系统自动发起提现，将账户余额**全部**提出；②提现在发起 30 分钟内到账；③平台收取营业收入的 **0.6%** 作为扣点。
> - **天猫 / 京东 / 拼多多订单**：①每月结算**两次**，货款打入门店的**支付宝账号**（在「店铺管理–收款信息」维护）；②手续费——天猫 **3.1%**、京东 **3.2%**、拼多多百亿补贴 **2%**、拼多多普通订单 **1%**（均按货款收入计）。
> - **抖音小店订单**：①每月结算**两次**，货款打入门店的**银行卡账号**；②手续费——普通订单 **2%**、达人带货订单 **4%**。
> - **抖音团购**：**内容被按钮遮挡，无法确认**，需补采截图。
>
> 由此得出一条 V1.0 完全未提及的结构性事实：**收款账户因渠道而异** —— 小程序走平台账户余额，天猫/京东/拼多多打**支付宝**，抖音小店打**银行卡**。也就是说 [4.10.5 银行账号](#4105-银行账号)那一页**只服务抖音小店**，而支付宝收款信息根本不在本模块，在「店铺管理」里。整合进 App 后这两处收款配置是否都要收进来，见 `TODO(REQ-FIN-009)`。
![现状-O2O 提现历史](../mini-program-images/O2O/提现历史.png)
**页面内容** —— 提现流水列表，顶部为一条说明到账异常处理的黄色提示条，每行是「提现申请成功」+ 时间戳 + 金额 + 到账状态，**本图为测试数据**（金额 0.01~0.04 元，状态只有「到账异常」与「到账中」，**没有一条成功到账**）。
**关键交互** —— ①上下滚动查看历史；②点「联系客服」路径由提示条文案引导，**本图未见可点的客服入口**。行本身**不可点击下钻**（无 `>` 或展开标识）。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-FIN-010](#4106-业务规则) 提现状态机与到账异常
> 本图给出三条信息：
>
> 1. **状态是两个维度**：左列「提现申请成功」是申请状态，右列「到账中 / 到账异常」是到账状态。App 内需要明确两者的组合关系与完整状态机。
> 2. **时间戳几乎全是 `15:00:2x`**，而[手续费说明](#4101-对账提现)写的是「每个工作日 **15:30** 左右」。**说明文案与实际执行时点不一致**，需确认以哪个为准 —— 门店会拿这句话对时间。
> 3. **2021 年的三条记录至今仍是「到账中」**，挂了四年多。「到账中」是否有超时兜底、是否应自动转为异常并退回资金，现状看不出来。已记入 [REQ-FIN-010](#4106-业务规则)。
## 4.10.2 收入明细
![现状-O2O 收入](../mini-program-images/O2O/收入.png)
**页面内容** —— 收入列表页，顶部为可横滑的渠道 tab、筛选行为月份 + 打款状态 + 橙色「**下载明细**」，其下是灰色汇总条与两行明细（各带渠道标、打款状态标与核销时间），**汇总与明细自洽**（24.50 × 2 = 49.00）。
**关键交互** —— ①横滑或点展开箭头 → 切换渠道 tab；②点月份 → 选择月份；③点「全部打款状态 ▾」→ 按打款状态过滤；④点「**下载明细**」→ 导出对账文件；⑤点明细行 → 进入收入详情（见下图）。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-FIN-005](#4106-业务规则) 金额一致性、[REQ-FIN-009](#4106-业务规则) 分渠道结算、[REQ-FIN-011](#4106-业务规则) 收入金额构成
> 两个需要处理的点：
>
> 1. **「下载明细」在 App 内如何落地** —— 小程序里导出一个文件，App 里则涉及下载目录、文件打开方式、iOS 的文件应用权限。这是一处必须给出交互定义的功能，已并入 [REQ-FIN-011](#4106-业务规则)。
> 2. **「零跑」标签不在任何一份已知的渠道清单里** —— 既不在[返利中心的 8 个渠道](./11-RBT-返利中心.md#4113-多维筛选)里，也不在[经营业绩的 7 个渠道](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)里。且本页把「天猫/京东/拼多多」合并成一个 tab，而返利中心是三个独立取值。渠道口径的全面冲突见 [REQ-FIN-009](#4106-业务规则)。
![现状-O2O 收入详情](../mini-program-images/O2O/收入详情.png)
**页面内容** —— 单笔收入的详情页，自上而下为订单信息（商品说明、订单号、流水号、支付渠道、打款状态）、金额构成（订单金额 +¥9.90 / **通道费 −¥0.79** / 货款收入 +¥9.11 / 总收入 +¥9.11）与 6 条备注，底部为橙色「查看订单详情」。
**关键交互** —— ①点打款状态旁的「查看」→ 下钻打款详情；②点「查看订单详情」→ 跳转对应[销售订单](./03-SAL-销售.md#435-线上订单管理)；③滚动阅读备注。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-FIN-005](#4106-业务规则) 金额一致性、[REQ-FIN-011](#4106-业务规则) 收入金额构成
> **金额构成可从本图直接读出**：订单金额 − 通道费 = 货款收入（9.90 − 0.79 = 9.11 ✓），总收入 = 货款收入 + 消费者补贴（本例补贴为 0）。
>
> 但**通道费与手续费对不上**：0.79 ÷ 9.90 ≈ **7.98%**，而[手续费说明](#4101-对账提现)里最高的费率也只有 4%。可见「通道费」是与平台手续费并列的另一项扣减（可能是支付通道费），两者的关系与是否会同时扣，需财务澄清 —— 已记入 [REQ-FIN-011](#4106-业务规则)。
> 6 条备注是**资金规则的正文**，必须在 App 内完整保留（同 [REQ-FIN-006](#4106-业务规则) 的精神）。其中三条尤其重要：
>
> - 「凡是使用**抖音 / 美团**抵用券的订单，券的面额扣除通道费后，将以货款形式打到银行卡」
> - 「**京东秒送**的货款收入会通过平台直接打款到门店进行结算」
> - 「**车点点**的货款收入会直接由车点点打款与门店进行结算，**本页面仅做展示**」
>
> 也就是说，有的渠道的钱根本不经过这套结算链路，本页只是展示。哪些渠道属于「仅展示」、在列表里如何标识，需要明确，否则门店会误以为这些钱也会自动到账。另注意备注里又出现了「美团」「车点点」两个此前未列入任何渠道清单的名字。
## 4.10.3 服务结算单
![现状-O2O 服务结算单](../mini-program-images/O2O/服务结算单.png)
**页面内容** —— 服务结算单页，顶部为结算渠道下拉与**跨月**日期区间「2024年9月–2024年11月」，中部是「¥0.00 / 结算金额」与「查看详细明细 >」，下方为结算单状态 / 开票方式 / 开票状态 / 打款状态四行加两条说明，**本图金额为 ¥0.00 且已是终态**。
**关键交互** —— ①点「全部结算渠道 ▾」→ 选择结算渠道（见下图）；②点日期区间 → 选择结算周期；③点「查看详细明细 >」→ 进入[结算单明细](#4103-服务结算单)；④**未确认时**该按钮为可点的「确认结算单」，确认后变为禁用的「结算单已确认」；⑤有异议时可点「重审结算单」（**本图为已确认态，该入口未出现，位置与形态无法确认**）。
**可用角色** —— 店长 ✅；技工 ✗。确认结算单是有财务效力的动作，即便 `TODO(REQ-FIN-001)` 最终对技工开放财务查看，确认动作也应限店长。
**需求关联** —— [REQ-FIN-012](#4106-业务规则) 结算单确认与重审
> **本图暴露一整套 V1.0 完全没写的业务流程**，两条说明原文如下：
>
> 1. 「此份结算单包含**天猫 / 京东pop / 小程序**渠道汇总金额，请您务必在**本月 7 号之前完成确认，否则系统将自动确认**。如您对结算单有异议，可点击**重审结算单**。」
> 2. 「在您确认结算单之前，请务必确认您已知晓自己的结算方式，如您需要修改结算方式，**请登录接单宝小程序进行修改**。」
>
> 由此得到三条必须成文的规则：**结算单需门店主动确认**、**7 号截止且逾期自动确认**、**有异议可重审**。已记为 [REQ-FIN-012](#4106-业务规则)。
>
> 另外第 2 条里的「请登录接单宝小程序进行修改」**在 App 内会自相矛盾** —— 整合的目的正是让门店不必再进小程序。该文案必须改写为 App 内路径，否则门店按提示跳出 App，整合价值受损。
![现状-O2O 服务结算单-筛选结算渠道](../mini-program-images/O2O/服务结算单-筛选结算渠道.png)
**页面内容** —— 「全部结算渠道」下拉展开态，**单选**（✓ 在「全部结算渠道」），取值 4 项：全部结算渠道 / **小程序服务单结算** / **天猫服务单结算** / **京东服务单结算**。
**关键交互** —— ①点任一项 → 立即生效并收起（无「确定」按钮）；②点遮罩 → 收起。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-FIN-009](#4106-业务规则) 渠道枚举
> **本图的渠道口径与同一页的说明文字都对不上**：下拉是「小程序 / 天猫 / 京东」三个服务单结算，而页面底部说明写的是「天猫 / **京东pop** / 小程序」。同一个页面里「京东」与「京东pop」两种写法并存，且两处都**没有拼多多**，而[收入页](#4102-收入明细)的 tab 却把拼多多与天猫、京东并列。见 [REQ-FIN-009](#4106-业务规则)。
![现状-O2O 结算单明细](../mini-program-images/O2O/结算单明细.png)
**页面内容** —— 结算单明细页，沿用上一页的渠道下拉与日期区间，下方是「**上周期更正结算(0)**」与「**本周期订单结算(0)**」两个**带计数的 tab**，**本截图为空态**故明细行的字段无法从本图确认。
**关键交互** —— ①点两个 tab → 切换明细类型，计数随筛选变化；②点「返回查看服务结算单」→ 回到上一页。
**可用角色** —— 店长 ✅；技工 ✗。
**需求关联** —— [REQ-FIN-013](#4106-业务规则) 上周期更正结算
> **「上周期更正结算」是一个 PRD 从未提及的概念** —— 上一结算周期的金额发生更正后，差额落在本期结算单里。这直接影响 [REQ-FIN-005](#4106-业务规则)「同一笔金额在不同页面必须一致」：同一笔业务在原周期与更正周期会出现两次，若不加以区分，门店会认为对账出错。已记为 [REQ-FIN-013](#4106-业务规则)。
>
> 另注意两个 tab 都带 `(N)` 计数，与[采购订单 tab 计数](./06-PUR-采购.md#469-验收标准)是同一类要求，接口需支持按类型返回计数。
## 4.10.4 采购对账单
**对账单**：在「我的」菜单下点击「对账单」，进入「对账单详情」，对账单**按月份**查看账单详情，汇总支出 / 收入金额，明细列表。
![现状-ROOS 对账单详情-采购对账单](../mini-program-images/ROOS/对账单详情-采购对账单.png)
**页面内容** —— ROOS「对账单详情」页，顶部为「**采购对账单 ∨**」下拉与账单单号搜索框，下方筛选行为月份与「支出 / 收入」两个汇总数，**本截图为空态**故明细行的字段无法从本图确认。
**关键交互** —— ①点「采购对账单 ∨」→ **切换对账单类型**；②输入账单单号 → 检索；③点月份 → 切换月份，两个汇总数随之变化；④点明细行 → 进入单据详情（本图为空态，无法确认是否可下钻）。
**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「采购对账单」为 ✗）。
**需求关联** —— [REQ-FIN-003](#4106-业务规则) 收支合并
> **「采购对账单 ∨」是可切换的下拉**，说明 ROOS 的对账单**不止采购一种**，还有其它类型 —— 但本图未展开，**其它类型无法确认**。[附录 A.8](../Continental-Retail-APP-PRD.md#a8-经营分析与财务) 第 1 条写的是「采购及**返利**对账单（马牌），来自 ROOS 与 F6」，返利对账单很可能就是下拉里的另一项。需补采下拉展开态的截图，并在 `TODO(REQ-FIN-003)` 一并厘清。
> **采购对账单（ROOS，付给厂商）与 O2O 对账提现（收厂商的钱）方向相反**，整合后是并列两个入口还是合成一张「资金总览」—— `TODO(REQ-FIN-003)`。本图显示采购对账单**自身同时含支出与收入两栏**，并非纯支出，合并方案设计时需注意。
## 4.10.5 银行账号
![现状-O2O 银行账号-企业账户](../mini-program-images/O2O/银行账号-企业账户.png)
**页面内容** —— 银行账号页的**企业账户**形态，右上角状态为「**已激活**」，字段区为企业全称、统一社会信用代码、银行卡预留手机号、绑定银行（**平安银行**）与脱敏后的账号，底部并排「修改手机号」「解绑银行卡」，**本图为测试数据**（企业全称「张二零」、预留手机号 `11111111111`）。
**关键交互** —— ①点「修改手机号」→ 需重新验证后修改；②点「解绑银行卡」→ 二次确认弹窗（见下图）。注销账户**无 App 内入口**，提示要求联系马牌客服。
**可用角色** —— 店长 🔸 受限（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵) 标为高风险，需二次验证 `TODO(REQ-FIN-004)`）；技工 ✗。
**需求关联** —— [REQ-FIN-004](#4106-业务规则) 账户绑定安全、[REQ-FIN-014](#4106-业务规则) 账户类型与状态
> 「温馨提示」两条原文：①「银行账户修改手机号、解绑银行卡**需要重新验证**，请勿频繁修改」；②「如需注销银行账户，请**联系马牌客服**」。
>
> 第 1 条**回答了 `TODO(REQ-FIN-004)` 的一半** —— 现状已经要求重新验证，所以「是否需要二次验证」不再是问题，剩下的只是**验证方式**（短信验证码 / 后台审核 / 其它）。该 TODO 可据此收窄。
![现状-O2O 银行账号-个人账户-解绑确认弹窗](../mini-program-images/O2O/银行账号-个人账户-解绑确认弹窗.png)
**页面内容** —— 同一页面的**个人账户**形态（字段改为姓名与身份证号码，状态同为「已激活」，**唯独银行卡预留手机号未脱敏**），其上叠加解绑二次确认弹窗，正文说明解绑后账户将降为**待激活**、需重新绑卡激活。
**关键交互** —— ①点「取消」→ 放弃；②点「确认」→ 解绑，账户转为「待激活」。**本弹窗未包含任何验证码或密码输入** —— 与「解绑需要重新验证」的提示是否在确认之后才触发，本图无法确认。
**可用角色** —— 店长 🔸；技工 ✗。
**需求关联** —— [REQ-FIN-004](#4106-业务规则) 账户绑定安全、[REQ-FIN-014](#4106-业务规则) 账户类型与状态
> 两张图合起来给出账户模型：**两种账户类型**（企业 = 企业全称 + 统一社会信用代码；个人 = 姓名 + 身份证号码）、**两种状态**（已激活 / 待激活），解绑即降为待激活，需重新绑卡才能恢复。已记为 [REQ-FIN-014](#4106-业务规则)。
>
> **脱敏口径不统一**：身份证号与银行账号都做了脱敏，而**银行卡预留手机号 `13419691597` 完整显示**。App 内须统一脱敏规则，见 `TODO(REQ-FIN-014)`。
>
> 另：[验收标准第 4 条](#4107-验收标准)要求「解绑后提现入口给出明确阻断提示」，而现状弹窗只说账户变为待激活，**没有提到会影响提现**。App 内需补上这层因果说明。
## 4.10.6 业务规则
**REQ-FIN-001 权限** —— 财务模块建议限店长可见 `TODO(REQ-FIN-001)`。确认结算单、绑定 / 解绑银行账号等有财务效力的动作，即便财务查看对技工开放也应单独限店长
**REQ-FIN-002 可提现金额口径** —— T+1 工作日 12:30 更新；基数为已核销订单货款；具体计算口径待定 `TODO(REQ-FIN-002)`
**REQ-FIN-003 收支合并** —— 采购对账单与 O2O 提现是否合成资金总览待定 `TODO(REQ-FIN-003)`。同时需确认 ROOS「对账单类型」下拉里除采购对账单外还有哪些类型（[附录 A.8](../Continental-Retail-APP-PRD.md#a8-经营分析与财务) 提到「采购及返利对账单」）
**REQ-FIN-004 账户绑定安全** —— 银行账号绑定 / 解绑 / 修改预留手机号**必须重新验证**（现状已如此要求）；具体验证方式（短信验证码 / 后台审核）待定 `TODO(REQ-FIN-004)`
**REQ-FIN-005 金额一致性** —— App 不做金额二次计算，全部以源系统返回值展示；不同页面同一笔金额必须一致。**跨周期更正的金额需可区分**，见 [REQ-FIN-013](#4106-业务规则)
**REQ-FIN-006 手续费透明** —— 交易手续费说明须在提现入口可达，且**分渠道的费率原文须完整保留**，不得摘要或省略
**REQ-FIN-007 与 CDMS 支付关系** —— 首页待办中的「CDMS 支付提醒」与本模块的关系待定 `TODO(REQ-FIN-007)`
**REQ-FIN-008 提现由系统自动发起** —— 小程序渠道的提现**由系统在每个工作日固定时点自动发起，将账户余额全部提出**，发起后 30 分钟内到账；**门店没有手动提现入口**。App 内不得出现「立即提现」类按钮，避免门店误以为需要手动操作。
> **待确认** `TODO(REQ-FIN-008)`：①说明文案写「15:30 左右」，而[提现历史](#4101-对账提现)的记录时间戳几乎全为 `15:00:2x`，实际时点以哪个为准；②天猫 / 京东 / 拼多多 / 抖音等非小程序渠道**没有自动提现**（按月结算两次直接打款），页面上的「可提现金额」是否只统计小程序渠道，需明确。
**REQ-FIN-009 分渠道结算机制与费率** —— 各渠道的结算周期、到账账户与费率互不相同，须按渠道分别落地：
| 渠道组 | 结算周期 | 到账账户 | 费率 |
| --- | --- | --- | --- |
| 小程序 | 每工作日自动提现，30 分钟内到账 | 平台账户余额 | 营业收入的 0.6% |
| 天猫 / 京东 / 拼多多 | 每月两次 | **支付宝账号**（店铺管理–收款信息） | 天猫 3.1%、京东 3.2%、拼多多百亿补贴 2%、拼多多普通订单 1% |
| 抖音小店 | 每月两次 | **银行卡账号** | 普通订单 2%、达人带货订单 4% |
| 抖音团购 | **截图被遮挡，未知** | 未知 | 未知 |
上表按货款收入计费。本模块的[银行账号页](#4105-银行账号)只服务抖音小店渠道；支付宝收款信息现状不在本模块，在「店铺管理」内维护。
> **待确认** `TODO(REQ-FIN-009)`：①「抖音团购」段落需补采截图后补全；②支付宝收款信息是否随本模块一并收进 App；③**渠道枚举必须统一** —— 现状在财务侧就有四套口径：收入页 tab（天猫/京东/拼多多合并 + 小程序 + 抖音小店 + 高德…，另有「零跑」标签）、手续费说明（四段分组）、结算渠道下拉（小程序 / 天猫 / 京东服务单结算，**无拼多多**）、收入详情备注（抖音 / 美团 / 京东秒送 / **车点点** / 零跑）；再加上[返利中心的 8 项](./11-RBT-返利中心.md#4113-多维筛选)与[经营业绩的 7 项](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)，全仓库至少六套。须收敛为一份[主数据](../Continental-Retail-APP-PRD.md#5-主数据)枚举。
**REQ-FIN-010 提现状态机与到账异常** —— 提现流水含两个状态维度：申请状态（提现申请成功）与到账状态（到账中 / 到账异常）。**到账异常后资金自动退回账户，可在下次提现时重新提走**，该提示须在提现历史页顶部常驻。
> **待确认** `TODO(REQ-FIN-010)`：①完整状态机与到账成功态的文案（现状截图中未出现成功态）；②「到账中」是否有超时兜底 —— 截图里 2021 年的记录至今仍停留在「到账中」，若无终态收敛，门店无法判断这笔钱的去向；③提示条中的「联系客服」是否需要做成可点入口。
**REQ-FIN-011 收入明细的金额构成与导出** —— 单笔收入的金额构成为「订单金额 − 通道费 = 货款收入」，「总收入 = 货款收入 + 消费者补贴」；收入类型现状可见「服务收入」与「货款收入」两类。收入详情页的备注是资金规则正文，须完整保留。列表页的「下载明细」需给出 App 内的落地方式（下载位置、文件格式、打开与分享路径）。
> **待确认** `TODO(REQ-FIN-011)`：①**通道费与平台手续费的关系** —— 截图中通道费 0.79 / 订单金额 9.90 ≈ 7.98%，与手续费说明里任何一档费率都对不上，两者是否会同时扣减需财务澄清；②备注中「车点点的货款收入……**本页面仅做展示**」意味着部分渠道的资金不走本链路，哪些渠道属于「仅展示」、列表中如何标识，需明确，否则门店会误判到账预期。
**REQ-FIN-012 结算单确认与重审** —— 服务结算单需门店主动确认：**每月 7 号前完成确认，逾期系统自动确认**；对结算单有异议可发起「重审结算单」。结算单含四个独立状态：结算单状态（待确认 / 已确认）、开票方式（自行开票 / 非自行开票）、开票状态（已开票 / …）、打款状态（已打款 / …）。
> **待确认** `TODO(REQ-FIN-012)`：①重审的发起条件、处理时效与结果回执；②开票方式的完整取值与切换路径 —— 现状提示「修改结算方式请登录接单宝小程序」，**该引导在 App 内必须改写为 App 内路径**，否则与整合目标冲突；③自动确认对门店的告知方式（临近 7 号是否需要提醒推送，与[提醒模块](./04-RMD-提醒.md#44-提醒)的关系）。
**REQ-FIN-013 上周期更正结算** —— 结算单明细分为「上周期更正结算」与「本周期订单结算」两类，各自带条数计数。跨周期更正的金额会落在本期结算单内，展示上必须与本期订单结算区分，避免门店重复计数。
> **待确认** `TODO(REQ-FIN-013)`：更正的产生原因（退款 / 核销撤销 / 平台调账）、对已确认结算单的追溯影响、以及更正金额是否计入本期的「结算金额」汇总。
**REQ-FIN-014 银行账号的账户类型、状态与脱敏** —— 银行账号支持两种类型：**企业账户**（企业全称 + 统一社会信用代码）与**个人账户**（姓名 + 身份证号码），共用「银行卡预留手机号 / 绑定银行 / 绑定银行账号」三个字段。账户状态为**已激活 / 待激活**；**解绑后账户降为待激活，需重新绑卡才能恢复**。注销账户无 App 内入口，需联系马牌客服。
> **待确认** `TODO(REQ-FIN-014)`：**脱敏口径需统一** —— 现状身份证号与银行账号已脱敏，而银行卡预留手机号完整显示。App 内三个字段的脱敏规则须一致并成文。
## 4.10.7 验收标准
1. 可提现金额页面明确标注更新时间与统计口径，不出现「金额已变但说明未变」的错位；
2. 收入明细合计与可提现金额可对上，差额部分（未到 T+1、手续费、通道费）有明确说明；
3. 技工无法通过任何路径进入财务模块（含深链）；
4. 银行账号解绑必须二次确认，且解绑后提现入口给出明确阻断提示；
5. 页面**不出现任何手动提现按钮**，自动提现的时点与规则在提现入口可达（[REQ-FIN-008](#4106-业务规则)）；
6. 手续费说明中各渠道的费率数值与源系统一致，抖音团购段落完整可见、不被按钮遮挡（[REQ-FIN-009](#4106-业务规则)）；
7. 结算单在未确认时可点「确认」，已确认后按钮置灰；临近 7 号自动确认前门店已被告知（[REQ-FIN-012](#4106-业务规则)）；
8. 结算单明细中「上周期更正结算」与「本周期订单结算」两类金额分列且各自计数正确（[REQ-FIN-013](#4106-业务规则)）；
9. App 内所有财务页面**不出现「请登录接单宝小程序」类引导**，全部改为 App 内路径（[REQ-FIN-012](#4106-业务规则)）。
> 第 2 条补入「通道费」，第 5~9 条为本次逐图核看后新增。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.8）
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 对账单 | Mini Program Backend | HTTPS | 采购及返利对账单（马牌），来自 ROOS 与 F6 |
| 2 | 核销结果集 | Mini Program Backend | HTTPS | 门店核销收入（马牌） |
| 3 | 返利结果集 | Mini Program Backend | HTTPS | 返利余额、明细、规则、提现 |
财务模块数据集（摘自主文件[附录 A.8 经营分析与财务](../Continental-Retail-APP-PRD.md#a8-经营分析与财务)）。
**这张表严重不足以支撑本模块**，三点问题：
1. **A.8 名为「经营分析与财务」，却一条经营分析的数据集都没有**（三条全属财务 / 返利），[经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)模块因此在附录 A 中没有任何字段依据。
2. **第 3 条「返利结果集」属于[返利中心](./11-RBT-返利中心.md#411-返利中心)**，不是本模块的数据集；且该条把「提现」写进了返利，而现状提现在 O2O 财务侧，两者是不同链路。
3. 本模块 11 张截图涉及的**提现流水、收入明细、收入详情、服务结算单、结算单明细、银行账号**六类数据，A.8 一条都没有覆盖。
依据本次逐图核看，可确认的数据集如下，**供业务确认后写入附录 A，不作为已定稿依据**：
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 可提现金额（金额 + 更新时点 + 口径说明） | O2O | HTTPS | T+1 工作日 12:30 更新，基数为已核销订单货款 |
| 2 | 交易手续费规则（分渠道结算周期 / 到账账户 / 费率） | O2O | HTTPS | 见 [REQ-FIN-009](#4106-业务规则)；抖音团购段落待补 |
| 3 | 提现流水（申请状态 / 到账状态 / 金额 / 时间） | O2O | HTTPS | 含「到账异常资金退回」规则 |
| 4 | 收入列表（渠道 / 月份 / 打款状态 / 单号 / 核销时间 / 金额 / 收入类型） | O2O | HTTPS | 支持导出明细文件 |
| 5 | 收入详情（订单金额 / 运费 / 通道费 / 货款收入 / 总收入 + 6 条资金备注） | O2O | HTTPS | 金额构成见 [REQ-FIN-011](#4106-业务规则) |
| 6 | 服务结算单（结算周期 / 结算金额 / 四个状态 / 确认与重审） | O2O | HTTPS | 7 号截止自动确认 |
| 7 | 结算单明细（上周期更正结算 / 本周期订单结算，各带计数） | O2O | HTTPS | 见 [REQ-FIN-013](#4106-业务规则) |
| 8 | 银行账号（账户类型 / 激活状态 / 主体信息 / 预留手机号 / 绑定银行与账号） | O2O | **敏感，需脱敏** | 含身份证号、统一社会信用代码、银行账号 |
| 9 | 采购对账单（月份 / 支出 / 收入 / 账单单号 / 明细） | ROOS | HTTPS | 对账单类型可切换，其它类型待确认 |
第 8 条含身份证号与银行账号，属个人敏感信息，须遵循[安全与合规](../Continental-Retail-APP-PRD.md#84-安全与合规)的处理要求，脱敏口径见 `TODO(REQ-FIN-014)`。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 对账提现 / 收入 / 结算单 | ✅ | ✗ | `TODO(REQ-FIN-001)` |
| **银行账号绑定 / 解绑** | 🔸 | ✗ | 高风险，需二次验证 `TODO(REQ-FIN-004)` |
| 采购对账单 | ✅ | ✗ | |
财务模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本次拆分建议为矩阵**补一行「确认 / 重审结算单」**（店长 🔸、技工 ✗）。确认结算单是一次性、不可逆、且逾期系统自动代确认的财务动作，与「查看结算单」的风险等级完全不同，不宜共用同一行，见 [REQ-FIN-012](#4106-业务规则)。
### 附-3 待确认项（主文件 10.2.10 的 FIN 分片 + 本次新增）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-FIN-001 | 财务模块是否限店长 | 业务 |
| REQ-FIN-002 | 可提现金额的精确计算口径（核销 → 可提现） | 财务 |
| REQ-FIN-003 | 采购对账单与 O2O 提现是否合成「资金总览」；ROOS 对账单类型下拉还有哪些类型 | 产品 / 财务 |
| REQ-FIN-004 | 银行账号绑定 / 解绑的**二次验证方式**（现状已确认必须验证，只缺方式） | 安全 / 财务 |
| REQ-FIN-007 | 首页「CDMS 支付提醒」与财务模块的关系（主文件误标为 REQ-FIN-005，见 [4.10.6](#4106-业务规则)） | 架构 |
| **REQ-FIN-008** | 自动提现的实际时点（说明写 15:30、流水记录为 15:00）；非小程序渠道是否计入「可提现金额」 | 财务 |
| **REQ-FIN-009** | 抖音团购的结算规则（截图被遮挡）；支付宝收款信息是否收进 App；**渠道枚举统一** | 财务 / 主数据 |
| **REQ-FIN-010** | 提现完整状态机与成功态文案；「到账中」的超时兜底；客服入口是否可点 | 财务 |
| **REQ-FIN-011** | 通道费与平台手续费的关系（7.98% 与费率表对不上）；「仅展示」渠道的标识方式；「下载明细」在 App 内的落地 | 财务 / 产品 |
| **REQ-FIN-012** | 重审结算单的条件与时效；开票方式取值与 App 内修改路径；自动确认前的提醒方式 | 财务 / 产品 |
| **REQ-FIN-013** | 上周期更正结算的产生原因、追溯影响、是否计入本期汇总 | 财务 |
| **REQ-FIN-014** | 银行账号三个敏感字段的脱敏口径统一 | 安全 / 财务 |
财务模块待确认项，共 12 条（主文件 [10.2.10](../Continental-Retail-APP-PRD.md#10210-财务与返利fin--rbt) 的 FIN 分片原 5 条 + 本次新增 7 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.10，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 FIN 行（7 / 5 / 29% → 14 / 12 / 14%）与第 10.2 节总数。
> 主文件 10.2.10 是 FIN 与 RBT 合并的一节，本表只取 FIN 前缀的行；RBT 的 7 条见 [11-RBT-返利中心.md](./11-RBT-返利中心.md)。两边条目相加须与主文件该节总数一致。
>
> 新增的 7 条里，REQ-FIN-008、009、012、013、014 的**主体规则已由截图确认**，待确认的只是其中一两个细节（时点、遮挡段落、脱敏口径等）。它们计入待确认数是因为带有 TODO 标记，但实现风险显著低于 REQ-FIN-002、003 这类完全未定的条目。
### 附-4 配图清单（主文件附录 C 4.10 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 现状-O2O 对账提现（**¥0.00 空态**；T+1 工作日 12:30 更新口径；**页面无提现按钮**） | `../mini-program-images/O2O/对账提现.png` |
| 2 | 现状-O2O 交易手续费说明（**分渠道结算周期 / 到账账户 / 费率全文**；「抖音团购」段落**被底部按钮遮挡**） | `../mini-program-images/O2O/对账提现-交易手续费说明.png` |
| 3 | 现状-O2O 提现历史（**测试数据 0.01~0.04 元**；状态仅「到账异常 / 到账中」，**无成功态**；时间戳均为 15:00:2x） | `../mini-program-images/O2O/提现历史.png` |
| 4 | 现状-O2O 收入（渠道 tab + 月份 + 打款状态 + **下载明细**；汇总 +¥49.00 与两条 ¥24.50 自洽；含**「零跑」渠道标签**） | `../mini-program-images/O2O/收入.png` |
| 5 | 现状-O2O 收入详情（金额构成 9.90 − 0.79 = 9.11；**6 条资金规则备注**，含抖音/美团券、京东秒送、车点点「仅做展示」） | `../mini-program-images/O2O/收入详情.png` |
| 6 | 现状-O2O 服务结算单（**¥0.00 已确认终态**；四个独立状态；说明含**7 号前确认 / 逾期自动确认 / 可重审**） | `../mini-program-images/O2O/服务结算单.png` |
| 7 | 现状-O2O 服务结算单筛选结算渠道（单选 4 项：全部 / 小程序 / 天猫 / 京东服务单结算，**无拼多多**） | `../mini-program-images/O2O/服务结算单-筛选结算渠道.png` |
| 8 | 现状-O2O 结算单明细（**空态**；两个带计数 tab：**上周期更正结算(0) / 本周期订单结算(0)**） | `../mini-program-images/O2O/结算单明细.png` |
| 9 | 现状-ROOS 对账单详情采购对账单（**空态**；**「采购对账单 ∨」可切换类型**；支出 / 收入双汇总） | `../mini-program-images/ROOS/对账单详情-采购对账单.png` |
| 10 | 现状-O2O 银行账号企业账户（**测试数据**；已激活；企业全称 + 统一社会信用代码；提示「修改需重新验证」「注销联系客服」） | `../mini-program-images/O2O/银行账号-企业账户.png` |
| 11 | 现状-O2O 银行账号个人账户解绑弹窗（姓名 + 身份证号；**解绑后降为待激活**；**弹窗内无验证码输入**） | `../mini-program-images/O2O/银行账号-个人账户-解绑确认弹窗.png` |
财务模块配图清单，11 张（现状-O2O 10 / 现状-ROOS 1）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
**本模块配图的三处硬缺口**：
- **完全没有设计稿。** 14 个模块中本模块是资金链路最长、状态最多的之一，却是[采购](./06-PUR-采购.md#46-采购)之外唯一一个关键页面全无 App 目标形态的模块。整合后的信息架构（收入 / 提现 / 结算单 / 对账单四条线如何组织）目前只能靠现状小程序推断。
- **金额全是 0 或测试值。** 11 张里 6 张是 ¥0.00 或空态，提现历史是 0.01~0.04 元的测试流水，银行账号是测试主体。**结算单明细行、对账单明细行、提现成功态的字段全部无法确认**。
- **两处被遮挡 / 未展开的内容直接卡着需求**：手续费说明的「抖音团购」段落被按钮压住（卡 `TODO(REQ-FIN-009)`），ROOS「采购对账单 ∨」下拉未展开（卡 `TODO(REQ-FIN-003)`）。这两张补采成本极低，建议优先。
### 附-5 本次拆分新增发现
逐张核看 11 张配图后，新增 **7 条编号需求**（REQ-FIN-008 ~ 014）、**修订 2 处既有内容**、发现 **1 处编号错位**，另记 **3 条无编号观察**。这是目前拆分的各模块中新增最多的一个 —— 原因是主文件 4.10 几乎只有图、没有正文：11 张图里有 8 张此前没有任何文字说明。
**新增需求**：
| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-FIN-008 | 提现由系统自动发起 | 对账提现页无提现按钮 + 手续费说明「每工作日 15:30 自动发起提现，全部提出」 |
| REQ-FIN-009 | 分渠道结算机制与费率 | 手续费说明全文：三套结算周期、三种到账账户、七个费率数值 |
| REQ-FIN-010 | 提现状态机与到账异常 | 提现历史的两维状态 + 「到账异常资金退回」提示条 + 2021 年记录仍「到账中」 |
| REQ-FIN-011 | 收入金额构成与导出 | 收入详情的五项金额构成 + 6 条资金备注 + 收入页「下载明细」按钮 |
| REQ-FIN-012 | 结算单确认与重审 | 服务结算单说明「7 号前确认，逾期自动确认，可重审」+ 四个独立状态 |
| REQ-FIN-013 | 上周期更正结算 | 结算单明细的两个带计数 tab |
| REQ-FIN-014 | 银行账号类型、状态与脱敏 | 企业 / 个人两套字段 + 已激活 / 待激活 + 三字段脱敏口径不一致 |
**修订的既有内容**：
1. **主流程「发起提现」改为「系统按工作日自动提现」** —— 门店没有手动提现入口，见 [REQ-FIN-008](#4106-业务规则)。主流程同时补入结算侧的「7 号前确认结算单」一条。
2. **`TODO(REQ-FIN-004)` 收窄** —— 现状已明确要求「修改手机号、解绑银行卡需要重新验证」，所以「是否需要二次验证」不再是待确认项，只剩**验证方式**待定。
**发现的编号错位**：REQ-FIN-007（与 CDMS 支付关系）挂着 `TODO(REQ-FIN-005)` 标记，主文件 10.2.10 对应行也用了 REQ-FIN-005 编号，但 REQ-FIN-005 是「金额一致性」且无待确认。回灌时两处一并改为 `TODO(REQ-FIN-007)`，**待确认条数不变**。这与[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)模块发现的 `TODO(REQ-MKT-004)` 错位是同一类问题，建议回灌时对全文的 TODO 标记与 10.2 编号做一次统一校验。
**无编号观察**（属现状材料问题，不新增需求）：
1. **说明文案与实际执行不一致** —— 手续费说明写「15:30 左右」，提现流水记录全是 `15:00:2x`。门店会拿这句话对时间，须校准。
2. **同一页内「京东」与「京东pop」两种写法并存**（服务结算单的下拉 vs 页面说明），且两处都没有拼多多，而收入页 tab 有。
3. **「请登录接单宝小程序进行修改」的引导在 App 内自相矛盾** —— 整合的目的正是消除跳出。该文案必须改写，已写入 [REQ-FIN-012](#4106-业务规则) 与[验收标准第 9 条](#4107-验收标准)。
另有一条跨模块的结构性问题需要在设计阶段统一解决：**渠道枚举在全仓库至少有六套口径**（本模块四套 + [返利中心 8 项](./11-RBT-返利中心.md#4113-多维筛选) + [经营业绩 7 项](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)），且各自还引入了对方没有的名字（零跑、车点点、美团、抖音团购轮胎）。渠道是贯穿销售、财务、返利、业绩四个模块的主数据，不统一将导致同一笔业务在四个模块归到不同渠道下，对账无从谈起。建议在[主数据](../Continental-Retail-APP-PRD.md#5-主数据)章节固化一份渠道枚举，四个模块共同引用。
prd/modules/11-RBT-返利中心.md
+338
View File
@@ -0,0 +1,338 @@
# 4.11 返利中心
> **本文件是【返利中心 RBT】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.11 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | RBT |
| V1.0 章节 | 4.11 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状截图反推 |
| 现状承载系统 | O2O（返利核算）+ 延保后台（延保返利） |
| 需求条数 | 11（待确认 7，完成度 36%） |
| 本次新增待确认 | 4（REQ-RBT-007、008、010、011） |
| 配图 | 10 张（设计稿 1 / 现状-O2O 9） |
模块概要
---
返利分布在两侧：延保侧有延保返利，O2O 侧另有一套完全独立、维度更丰富的返利体系（9 张截图），设计稿为其单独出了页面。
**业务目标** —— 让门店随时看清「这单能拿多少返利、为什么是这个数、核算到哪一步了」，解决[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销)中返利不透明的问题
**入口** —— O2O 工具条「返利中心」；宫格版导航一级入口
**页面内容**：
- 双 Tab：**返利详情 / 返利核算**
- 顶部订单号搜索 + 四个筛选（渠道 / 品牌 / 标签 / 月份）—— **仅返利详情 Tab 有，切到返利核算后整个筛选区消失**（[REQ-RBT-010](#4115-业务规则)）
- 概览卡（补贴返利、核算后返利）+ 三项构成（消费者补贴、安装费用、抽奖红包返利），每项可点开调整情况
- 明细列表，按三项构成分组切换
**主流程** —— 选择月份与筛选 → 查看概览 → 按构成切换明细 → 展开单条查看构成与状态；另可切到「返利核算」查看季度核算的调整流水
**权限规则** —— 建议限店长 `TODO(REQ-RBT-001)`
**数据来源** —— O2O（返利核算）、延保后台（延保返利，见 [4.5.6](./05-WTY-延保.md#456-工作台返利与经营数据)）
## 4.11.1 目标形态
![设计稿-返利中心](../app-design-images/返利中心.png)
**页面内容** —— App 返利中心的目标形态，自上而下为订单号搜索框、「返利详情 / 返利核算」双 Tab、四个筛选、橙色汇总卡（返利补贴与核算后返利 + 三项构成，每项带 `ⓘ`）与「明细」区，**两张明细卡是同一份占位数据**，仅状态标签不同。
**关键交互** —— ①输入订单号 → 检索该单返利；②切换双 Tab；③点四个筛选任一项 → 展开取值（取值集合见 [4.11.3](#4113-多维筛选)）；④点三项构成上的 `ⓘ` → 弹出该项的调整情况（见 [4.11.4](#4114-返利构成说明)）；⑤点「消费者补贴 / 安装费用 / 抽奖红包返利」三个标签 → 切换下方明细分组；⑥点明细卡右侧 `∨` → 展开该条的返利构成。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`，关闭前按技工不可见实现。
**需求关联** —— [REQ-RBT-002](#4115-业务规则) 计算口径、[REQ-RBT-003](#4115-业务规则) 规则说明可达
> **本图的三个数值互不自洽，不可作为计算口径的依据**：返利补贴 ¥30.00、核算后返利 ¥38.00，而三项构成之和为 40 + 12.08 + 1.08 = **¥53.16** —— 与前两者都对不上。相比之下[现状返利详情](#4112-返利详情与返利核算)的一组数据恰好自洽（20 = 20 + 0 + 0）。设计稿此处是随手填的占位数值，`TODO(REQ-RBT-002)` 的公式应以现状数据反推，见 [REQ-RBT-002](#4115-业务规则)。
## 4.11.2 返利详情与返利核算
![现状-O2O 返利中心-返利详情](../mini-program-images/O2O/返利中心-返利详情.png)
**页面内容** —— O2O 返利中心的「返利详情」Tab，结构与设计稿一致但筛选分成两行（渠道 / 品牌 / 标签一行，月份单独一行），「概览」区为补贴返利与核算后返利两张白卡加三项构成，「明细」区当前按「消费者补贴」分组、两条记录合计 **+¥20.00**。
**关键交互** —— ①输入订单号后需**点「搜索」按钮**才触发查询（非输入即搜）；②点三项构成旁的 `?` → 弹出调整情况；③点明细分组切换列表；④点明细行右侧 `∨` → 展开该条构成；⑤列表触底显示「已经到底啦！」。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-002](#4115-业务规则) 计算口径、[REQ-RBT-006](#4115-业务规则) 数据来源、[REQ-RBT-007](#4115-业务规则) 筛选取值
> **本图是推导计算口径的关键证据**，三层数值恰好闭合：明细合计（−40 + 60）= 消费者补贴（+20）= 三项构成之和（20 + 0 + 0）= 补贴返利（+20）= 核算后返利（+20，本月无核算调整）。据此可给出待业务确认的公式草案，见 [REQ-RBT-002](#4115-业务规则)。
> **明细行的字段与设计稿不一致**：现状每行含**数量「x1」**、条码后跟灰色**「撤回」**标签、**「最近记录时间」**前缀；设计稿则是状态标签「已完成」/「退款扣减」，无数量、无「最近记录时间」。两套字段需在设计定稿时合并，一并归入 [REQ-RBT-007](#4115-业务规则)。
![现状-O2O 返利中心-返利核算](../mini-program-images/O2O/返利中心-返利核算.png)
**页面内容** —— 切到「返利核算」Tab 后的列表，**搜索框与四个筛选整行消失**，只剩双 Tab 与核算调整流水卡（每张含事由标题、「品牌｜渠道｜返利类型」三个维度标签、带正负的金额与时间戳）。
**关键交互** —— ①切换回「返利详情」→ 搜索与筛选区重新出现；②列表本身**无筛选、无搜索、无分页控件**，只能上下滚动。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。核算流水含考核扣款，敏感度高于返利详情，即便技工可见返利详情，本 Tab 是否一并开放需单独判断。
**需求关联** —— [REQ-RBT-010](#4115-业务规则) 核算 Tab 的筛选缺失、[REQ-RBT-011](#4115-业务规则) 返利类型集合
> 本图给出三条实质信息：
>
> 1. **返利核算是「季度」粒度的**（结合[抽奖红包返利说明](#4114-返利构成说明)中的「不参与季度核算」），而返利详情按**月**筛选。两个 Tab 的时间粒度不同，图中三条记录横跨 2023–2025，也确实不受月份筛选约束 —— 已记为 [REQ-RBT-010](#4115-业务规则)。
> 2. **「好评返利」不属于三项构成的任何一项**（消费者补贴 / 安装费用 / 抽奖红包返利），说明返利类型的完整集合比概览区展示的三项更大 —— 已记为 [REQ-RBT-011](#4115-业务规则)。
> 3. **「Q1补货率未达标 −¥1,000.00」证明返利核算包含考核扣款**，且考核指标是「补货率」—— 与[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)中「消费券额度随扫码入库与补货率累积」是**同一套门店考核体系**。App 内两处应引用同一份考核规则说明，避免门店在两个模块看到互相矛盾的解释。
> 事由标题「11」「导入增加11」明显是后台录入的测试文案。整合后该字段直接对门店展示，需明确其录入规范与字数上限，一并归入 [REQ-RBT-010](#4115-业务规则)。
## 4.11.3 多维筛选
![现状-O2O 返利中心-筛选渠道](../mini-program-images/O2O/返利中心-筛选渠道.png)
**页面内容** —— 「全部渠道」下拉展开态，**单选**（当前 ✓ 在「全部渠道」），取值共 9 项：全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / **抖音团购轮胎**。
**关键交互** —— ①点任一渠道 → 立即收起下拉并按该渠道过滤（无「确定」按钮）；②再次点标题或点遮罩 → 收起。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
> **渠道主数据与经营业绩模块对不上**：本图为 8 个业务渠道，而[经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)记录的渠道清单为 7 个（小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎），**少了「抖音团购轮胎」**。渠道是跨模块共用的主数据，两处必须取自同一份枚举，见[主数据](../Continental-Retail-APP-PRD.md#5-主数据)。已记入 [REQ-RBT-007](#4115-业务规则)。
![现状-O2O 返利中心-筛选品牌](../mini-program-images/O2O/返利中心-筛选品牌.png)
**页面内容** —— 「全部品牌」下拉展开态，**单选**（✓ 在「全部品牌」），取值 3 项：全部品牌 / **德国马牌** / 维京。
**关键交互** —— 同渠道下拉：点选即生效并收起。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
> **品牌名称在三处有三种写法**：本图下拉为「德国马牌 / 维京」，[返利核算](#4112-返利详情与返利核算)的标签为「马牌 / 维京」，[采购购物车](./06-PUR-采购.md#463-购物车与结算)分组为「德国马牌 / 维京轮胎」。App 内须统一，同样归入主数据口径。
![现状-O2O 返利中心-筛选标签](../mini-program-images/O2O/返利中心-筛选标签.png)
**页面内容** —— 「标签」下拉展开态，与前两个筛选形态不同：提示「请选择标签（**可多选**）」，三个可点 chip「**撤回 / 异常 / 调整**」，下方另有独立的「确定」按钮。
**关键交互** —— ①点 chip → 切换选中态，可多选；②点「确定」→ 应用筛选并收起（与渠道 / 品牌的「点选即生效」不同）。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
> V1.0 原文把「标签」列为四个筛选之一，但**从未说明它的取值**。本图给出确定答案：标签 = **撤回 / 异常 / 调整**，且是多选。这三个值正是[消费者补贴调整情况](#4114-返利构成说明)弹窗里的三个调整分项 —— 标签筛选的本质是「按调整原因过滤明细」，而非商品或订单的标签。
![现状-O2O 返利中心-筛选月份](../mini-program-images/O2O/返利中心-筛选月份.png)
**页面内容** —— 点月份后从底部弹出的年月滚轮选择器（左列年份、右列月份，底部「取消」与绿色「确定」），**为微信小程序原生 picker 样式**。
**关键交互** —— ①滚动年 / 月 → 预选；②点「确定」→ 应用；③点「取消」或遮罩 → 放弃。**只能选单个月，不支持区间**。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
> 两点须在 App 内改造：①绿色「确定」是微信原生控件样式，App 内应换成本项目设计系统的按钮；②年份可选范围（图中可滚到 2027 年，即**未来月份**）需要约束，选到无数据的未来月份只会得到空态。
## 4.11.4 返利构成说明
三项返利构成各自带独立的规则说明页，这些说明必须在 App 内完整保留 —— 它们是门店理解返利数额的唯一依据。
![现状-O2O 返利中心-消费者补贴调整情况](../mini-program-images/O2O/返利中心-消费者补贴调整情况.png)
**页面内容** —— 点「消费者补贴 `?`」后的居中弹窗「消费者补贴调整情况」，一行汇总之下的框内是**发放 / 撤回 / 异常 / 调整**四个分项（本图各为 ¥0.00）。
**关键交互** —— ①点 ✕ 或遮罩 → 关闭。**弹窗内各分项不可再下钻**，是终点页。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-003](#4115-业务规则) 规则说明可达、[REQ-RBT-008](#4115-业务规则) 调整情况分项
![现状-O2O 返利中心-安装费用调整情况](../mini-program-images/O2O/返利中心-安装费用调整情况.png)
**页面内容** —— 结构与上一张相同的「安装费用调整情况」弹窗，差别是分项**只有三个：发放 / 异常 / 调整 —— 没有「撤回」**。
**关键交互** —— 同上，仅 ✕ 关闭。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-008](#4115-业务规则) 调整情况分项
> **两项的分项数不同**：消费者补贴有「撤回」而安装费用没有。若这是有意的业务设计（安装费用一旦发放不可撤回），需成文；若是现状遗漏，App 内应补齐。同时[标签筛选](#4113-多维筛选)包含「撤回」，按安装费用分组时该标签将始终无结果 —— 交互上需要处理。已记为 [REQ-RBT-008](#4115-业务规则)。
![现状-O2O 返利中心-抽奖红包返利说明](../mini-program-images/O2O/返利中心-抽奖红包返利说明.png)
**页面内容** —— 点「抽奖红包返利 `?`」后弹出的**纯文字提示框**（非前两张的数据弹窗），全文一句：「**抽奖红包返利，不参与季度核算，不会进行扣除**」。
**关键交互** —— 仅 ✕ 关闭，无交互。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
**需求关联** —— [REQ-RBT-003](#4115-业务规则) 规则说明可达、[REQ-RBT-009](#4115-业务规则) 抽奖红包返利的核算例外
> 本图有两个值得注意的点：
>
> 1. **三项构成的说明形态不一致** —— 前两项是带金额分项的「调整情况」数据弹窗，第三项是无数据的纯文字规则说明。App 内是否统一为同一种形态，见 [REQ-RBT-008](#4115-业务规则)。
> 2. **这句话本身是一条实质业务规则**，且是全部 10 张图里唯一明确写出核算规则的地方：抽奖红包返利**不参与季度核算、不会被扣除**。它直接约束 [REQ-RBT-002](#4115-业务规则) 的公式 —— 「核算后返利」的调整只作用于消费者补贴与安装费用两项。已单独成文为 [REQ-RBT-009](#4115-业务规则)。
## 4.11.5 业务规则
**REQ-RBT-001 权限** —— 返利对技工是否可见待定 `TODO(REQ-RBT-001)`。「返利核算」Tab 含考核扣款流水，敏感度高于「返利详情」，两者是否同一档权限需一并判断
**REQ-RBT-002 计算口径** —— 返利补贴、核算后返利、三项构成的关系需给出公式说明 `TODO(REQ-RBT-002)`
> V1.1 依据[现状返利详情](#4112-返利详情与返利核算)与[三项说明弹窗](#4114-返利构成说明)反推出以下**公式草案，待财务确认后转为正式口径**：
>
> - 消费者补贴 = 发放 + 撤回 + 异常 + 调整
> - 安装费用 = 发放 + 异常 + 调整（**无撤回项**，见 [REQ-RBT-008](#4115-业务规则)）
> - 补贴返利 = 消费者补贴 + 安装费用 + 抽奖红包返利
> - 核算后返利 = 补贴返利 + 季度核算调整合计，其中**抽奖红包返利不参与核算调整**（[REQ-RBT-009](#4115-业务规则)）
> - 每项构成的明细列表合计 = 该项金额
>
> 现状截图的一组数据完全满足上述关系（明细 −40 + 60 = 消费者补贴 20 = 补贴返利 20 = 核算后返利 20）；[设计稿](#4111-目标形态)的 30 / 38 / 53.16 三者不自洽，**不作为口径依据**。另需财务明确：正负号约定（撤回 / 异常 为负值还是绝对值）、以及季度核算调整落在哪个月份的「核算后返利」上。
**REQ-RBT-003 规则说明可达** —— 三项构成的 `ⓘ` 说明必须在 App 内保留，不得外链小程序
**REQ-RBT-004 与延保返利合并** —— O2O 返利与[延保返利](./05-WTY-延保.md#456-工作台返利与经营数据)是否合并入口待定 `TODO(REQ-RBT-004)`
**REQ-RBT-005 退款扣减** —— 明细中的「退款扣减」状态需与[财务收入](./10-FIN-财务与对账.md#4102-收入明细)对齐，同一笔不得两侧不一致
**REQ-RBT-006 数据来源** —— 返利金额全部由 O2O 返回，App 不做二次计算（同 [REQ-FIN-005](./10-FIN-财务与对账.md#4106-业务规则)）
**REQ-RBT-007 筛选取值与明细字段** —— 四个筛选的取值与交互按现状固化：
- **渠道**：单选，点选即生效。取值为「全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎」
- **品牌**：单选，点选即生效。取值为「全部品牌 / 德国马牌 / 维京」
- **标签**：**多选**，需点「确定」生效。取值为「撤回 / 异常 / 调整」，语义是按调整原因过滤明细
- **月份**：单月，年月滚轮 + 确定，不支持区间；可选年份范围需约束，避免选中无数据的未来月份
明细行字段需在现状（数量 x1 / 条码 + 撤回标签 / 最近记录时间）与设计稿（已完成 / 退款扣减状态标签）两套之间合并定稿。
> **待确认** `TODO(REQ-RBT-007)`：渠道枚举与[经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)记录的 7 项不一致（本模块多出「抖音团购轮胎」）；品牌名称在返利核算标签、品牌下拉、采购购物车三处分别写作「马牌」「德国马牌」「德国马牌 / 维京轮胎」。两者均为跨模块主数据，须统一到同一份枚举后再定稿。
**REQ-RBT-008 三项构成的调整情况** —— 消费者补贴与安装费用各自可点开「调整情况」弹窗，展示该项的分项金额；抽奖红包返利仅有一句文字说明。分项现状为：消费者补贴 = 发放 / 撤回 / 异常 / 调整（4 项），安装费用 = 发放 / 异常 / 调整（3 项，无撤回）。
> **待确认** `TODO(REQ-RBT-008)`：①安装费用无「撤回」是业务设计还是现状遗漏；②按安装费用分组时「撤回」标签必然无结果，交互上如何处理（置灰 / 隐藏 / 允许空结果）；③App 内三项的说明是否统一为同一种形态（现状两种：数据弹窗 + 纯文字提示）。
**REQ-RBT-009 抽奖红包返利的核算例外** —— **抽奖红包返利不参与季度核算，不会被扣除**。该规则须在 App 内对门店显式展示（沿用现状的说明入口），并作为 [REQ-RBT-002](#4115-业务规则) 公式的约束条件：季度核算的调整只作用于消费者补贴与安装费用两项
**REQ-RBT-010 返利核算 Tab 的独立性** —— 「返利核算」Tab 与「返利详情」Tab 的数据粒度不同：详情按**月**筛选，核算按**季度**产生，现状切到核算 Tab 后搜索框与四个筛选整行消失，列表不受月份约束。核算记录的结构为「事由标题 + 品牌｜渠道｜返利类型 + 金额 + 时间戳」。
> **待确认** `TODO(REQ-RBT-010)`：①核算 Tab 是否需要自己的筛选（按季度 / 品牌 / 渠道）与搜索；②事由标题由后台自由录入（现状可见「11」「导入增加11」等测试文案），直接对门店展示前需明确录入规范与字数上限；③核算调整最终如何回写到某个月份的「核算后返利」。
**REQ-RBT-011 返利类型集合** —— 概览区展示的三项构成（消费者补贴 / 安装费用 / 抽奖红包返利）**不是返利类型的全集**：返利核算记录中出现了「好评返利」，不属于其中任何一项。返利类型的完整枚举、每种类型是否计入补贴返利、是否参与季度核算，均待补 `TODO(REQ-RBT-011)`
## 4.11.6 验收标准
1. 四个筛选任意组合下，概览卡数值与明细列表合计一致；
2. 每一项返利构成都能点开对应的规则说明，且说明内容与现状小程序一致；
3. 「退款扣减」明细在返利中心与财务收入两处金额与符号一致；
4. 「补贴返利 = 三项构成之和」「各项明细合计 = 该项金额」两条恒等式在任意筛选组合下成立（[REQ-RBT-002](#4115-业务规则)）；
5. 切到「返利核算」Tab 时，页面不残留「返利详情」的筛选条件，返回时原筛选条件仍在（[REQ-RBT-010](#4115-业务规则)）；
6. 标签筛选支持多选并需点「确定」生效，渠道 / 品牌为单选点选即生效（[REQ-RBT-007](#4115-业务规则)）。
> 第 4、5、6 条为本次逐图核看后新增。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A 无对应节）
**主文件[附录 A](../Continental-Retail-APP-PRD.md#附录-a-业务数据字典) 未收录返利中心的数据集清单** —— A.1~A.9 覆盖登录、首页、销售、提醒、采购、延保、门店管理、经营分析与财务、个人中心，**没有返利中心一节**。返利金额涉及门店实收，字段缺失会直接影响接口对齐，需业务补齐。
依据本次逐图核看，可确认的数据集如下，**供业务确认后写入附录 A，不作为已定稿依据**：
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 返利概览（补贴返利 / 核算后返利 / 三项构成） | O2O | HTTPS | 按渠道 + 品牌 + 标签 + 月份筛选 |
| 2 | 返利明细列表（商品名 + 规格 / 数量 / 条码 / 最近记录时间 / 金额 / 状态标签） | O2O | HTTPS | 按三项构成分组 |
| 3 | 调整情况（发放 / 撤回 / 异常 / 调整） | O2O | HTTPS | 消费者补贴 4 项、安装费用 3 项 |
| 4 | 返利核算流水（事由 / 品牌 / 渠道 / 返利类型 / 金额 / 时间） | O2O | HTTPS | 季度粒度，不受月份筛选约束 |
| 5 | 筛选主数据（渠道 8 项 / 品牌 2 项 / 标签 3 项） | O2O | HTTPS | **须与[主数据](../Continental-Retail-APP-PRD.md#5-主数据)统一**，见 `TODO(REQ-RBT-007)` |
| 6 | 延保返利 | 延保后台 | HTTPS | 是否并入本模块见 `TODO(REQ-RBT-004)` |
上表字段全部来自截图可见内容；返利类型的完整枚举尚未确认（`TODO(REQ-RBT-011)`）。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 返利详情 / 核算 | ✅ | ❓ | `TODO(REQ-RBT-001)` |
返利模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 本次拆分建议**把该行拆成两行**：「返利详情」与「返利核算」。核算 Tab 含「Q1补货率未达标 −¥1,000.00」这类考核扣款流水，与门店经营考核直接相关，敏感度明显高于按订单看返利，两者不宜共用一个权限开关。
### 附-3 待确认项（主文件 10.2.10 的 RBT 分片 + 本次新增）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-RBT-001 | 返利对技工是否可见（详情与核算是否同一档） | 业务 |
| REQ-RBT-002 | **返利补贴、核算后返利、三项构成的计算公式**（本文件已给出待验证草案） | 财务 |
| REQ-RBT-004 | O2O 返利与延保返利是否合并入口 | 产品 |
| **REQ-RBT-007** | 渠道枚举与经营业绩模块不一致（多出「抖音团购轮胎」）；品牌名称三处三种写法；明细行字段两套合并 | 主数据 / 产品 |
| **REQ-RBT-008** | 安装费用无「撤回」分项是设计还是遗漏；「撤回」标签在安装费用分组下的空结果处理；三项说明形态是否统一 | 财务 / 产品 |
| **REQ-RBT-010** | 返利核算 Tab 是否需要独立筛选；事由标题的录入规范；核算调整回写到哪个月份 | 财务 / 产品 |
| **REQ-RBT-011** | 返利类型的完整枚举（现状可见「好评返利」不属三项构成任一项） | 业务 / 财务 |
返利模块待确认项，共 7 条（主文件 [10.2.10](../Continental-Retail-APP-PRD.md#10210-财务与返利fin--rbt) 的 RBT 分片原 3 条 + 本次新增 4 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.10，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 RBT 行（6 / 3 / 50% → 11 / 7 / 36%）与第 10.2 节总数。
> 主文件 10.2.10 是 FIN 与 RBT 合并的一节，本表只取 RBT 前缀的行；FIN 的 5 条见 [10-FIN-财务与对账.md](./10-FIN-财务与对账.md)。两边条目相加须与主文件该节总数一致。
### 附-4 配图清单（主文件附录 C 4.11 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-返利中心（双 Tab + 四筛选 + 橙色汇总卡 + 三项构成 + 明细；**三个数值互不自洽，为占位数据**） | `../app-design-images/返利中心.png` |
| 2 | 现状-O2O 返利详情（概览 20 / 20 + 消费者补贴 20；明细 −40 与 +60 各一条，**数据自洽，是推导公式的关键证据**） | `../mini-program-images/O2O/返利中心-返利详情.png` |
| 3 | 现状-O2O 返利核算（**切换后筛选区整体消失**；三条核算流水含「Q1补货率未达标 −¥1,000.00」与「好评返利」） | `../mini-program-images/O2O/返利中心-返利核算.png` |
| 4 | 现状-O2O 筛选渠道（单选，8 个业务渠道 + 全部；**含经营业绩模块没有的「抖音团购轮胎」**） | `../mini-program-images/O2O/返利中心-筛选渠道.png` |
| 5 | 现状-O2O 筛选品牌（单选：全部 / 德国马牌 / 维京；背景为**空态**） | `../mini-program-images/O2O/返利中心-筛选品牌.png` |
| 6 | 现状-O2O 筛选标签（**多选 + 确定**；取值为撤回 / 异常 / 调整 —— 主文件原未定义该筛选取值） | `../mini-program-images/O2O/返利中心-筛选标签.png` |
| 7 | 现状-O2O 筛选月份（微信原生年月滚轮，单月不支持区间，可滚到未来年份；背景为**空态**） | `../mini-program-images/O2O/返利中心-筛选月份.png` |
| 8 | 现状-O2O 消费者补贴调整情况（弹窗，分项 **发放 / 撤回 / 异常 / 调整**；本图**全为 ¥0.00**） | `../mini-program-images/O2O/返利中心-消费者补贴调整情况.png` |
| 9 | 现状-O2O 安装费用调整情况（弹窗，分项 **发放 / 异常 / 调整，无撤回**；本图**全为 ¥0.00**） | `../mini-program-images/O2O/返利中心-安装费用调整情况.png` |
| 10 | 现状-O2O 抽奖红包返利说明（**纯文字提示**，非数据弹窗：「不参与季度核算，不会进行扣除」） | `../mini-program-images/O2O/返利中心-抽奖红包返利说明.png` |
返利模块配图清单，10 张（设计稿 1 / 现状-O2O 9）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
**配图材料的两处限制**：
- **第 4~10 张共 7 张的背景数据均为 ¥0.00 或「暂无数据」空态**。三项调整情况弹窗（第 8、9 张）虽然结构清晰，但全为零值，**分项之间的正负号约定无法从图中确认** —— 这正是 `TODO(REQ-RBT-002)` 公式草案里最需要财务澄清的一点。建议向有真实返利数据的门店账号补采这两张弹窗的截图。
- **明细行展开态（`∨`）没有截图**。展开后显示的单条返利构成是门店核对争议时的最终依据，目前没有任何页面材料。
### 附-5 本次拆分新增发现
逐张核看 10 张配图后，新增 **5 条编号需求**（REQ-RBT-007 ~ 011，其中 4 条带待确认）、另记 **4 条无编号观察**，并为悬置已久的 `TODO(REQ-RBT-002)` 给出了**可验证的公式草案**。
**新增需求**：
| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-RBT-007 | 筛选取值与明细字段 | 主文件列了四个筛选却从未写取值；本次逐图取全（渠道 8 / 品牌 2 / 标签 3），并发现渠道与品牌的跨模块主数据冲突 |
| REQ-RBT-008 | 三项构成的调整情况 | 消费者补贴 4 分项 vs 安装费用 3 分项（无撤回）；两项是数据弹窗、第三项是纯文字，形态不统一 |
| REQ-RBT-009 | 抽奖红包返利的核算例外 | 说明弹窗原文「不参与季度核算，不会进行扣除」—— 10 张图中唯一明写的核算规则 |
| REQ-RBT-010 | 返利核算 Tab 的独立性 | 切到核算 Tab 后筛选区整体消失；记录横跨 2023–2025，是季度粒度而非月度 |
| REQ-RBT-011 | 返利类型集合 | 核算记录出现「好评返利」，不属于概览区三项构成任何一项 |
**对 [REQ-RBT-002](#4115-业务规则) 的实质推进** —— 该条是主文件标注「门店最容易产生争议」的一项，此前只有一句「需要明确的计算公式说明」。本次由现状截图反推出五条恒等式草案（见 REQ-RBT-002 下方引用块），并证明**设计稿的数值不可用**（30 / 38 与三项之和 53.16 三者互不相等），把这条 TODO 从「无从下手」推进到「有草案待财务确认」。
**无编号观察**（属现状材料或设计稿状态问题，不新增需求）：
1. **「返利补贴」与「补贴返利」词序不同** —— 设计稿写「返利补贴」，现状写「补贴返利」，指同一个数。定稿时取其一。
2. **搜索提示语用词冲突** —— 现状写「请输入订单号搜索查看**收入详情**」，把返利叫作「收入详情」，与[财务与对账](./10-FIN-财务与对账.md#4102-收入明细)的「收入明细」撞名，容易让门店误以为是同一个东西。
3. **月份 picker 是微信原生控件**（绿色确定按钮），App 内需换成本项目设计系统；且年份可滚到未来（2027），需约束范围。
4. **返利核算的事由文案含测试数据**（「11」「导入增加11」），该字段直接对门店展示，需明确后台录入规范。
另有一条跨模块关联值得业务注意：**「Q1补货率未达标」的考核扣款与[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)中「消费券额度随补货率累积」出自同一套门店考核体系**。补货率既加消费券额度、又扣返利，门店在两个模块看到的规则说明必须同源，否则会产生解释冲突。建议在设计阶段确认是否需要一个统一的「门店考核规则」说明页，供两处共同引用。
另建议主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵) 把「返利详情 / 核算」**拆成两行** —— 核算 Tab 含考核扣款流水，不宜与按订单看返利共用同一个权限开关，见[附-2](#附-2-权限矩阵主文件附录-b-本模块分行)。
prd/modules/12-PRF-经营业绩与报表.md
+314
View File
@@ -0,0 +1,314 @@
# 4.12 经营业绩与报表
> **本文件是【经营业绩与报表 PRF】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.12 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | PRF |
| V1.0 章节 | 4.12 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状截图反推 + 设计稿 |
| 现状承载系统 | O2O + ROOS（+ 延保为第三套） |
| 需求条数 | 9（待确认 7，完成度 22%） |
| 本次新增待确认 | 3（REQ-PRF-007 / 008 / 009 见[附-5](#附-5-本次拆分新增发现待业务确认)） |
| 配图 | 8 张（设计稿 1 / 现状-O2O 6 / 现状-ROOS 1） |
模块概要
---
> 本节内容由 O2O 经营业绩、ROOS 业绩详情与设计稿构建。
**业务目标** —— 门店在一处看到订货、入库、售出、延保、收入的全链路经营数据，解决[痛点 2.5](../Continental-Retail-APP-PRD.md#25-数据经营分析)
**入口** —— 「我的」菜单 → 经营业绩；宫格版导航「经营分析」；[店长首页](./02-HOM-APP首页与导航.md#423-店长首页)业绩卡片
**页面内容**：
- 三 Tab：**1.0 经营业绩 / 2.0 经营业绩 / 2.0 引流转化**
- 三个筛选（**品牌** / 渠道 / 日期）+ 一行时间粒度 chip（当月 / 当日 / 当周 / 当季）
- 扫码入库双计数、分品牌性能指标、销售统计、收入统计
- 引流转化 Tab 另有线索三分类、环比、排名与市/全国对标折线图（[REQ-PRF-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)）
> V1.0 此处原写作「三个筛选（时间粒度 / 渠道 / 日期）」，据现状图核实**第一个筛选是「品牌」而非「时间粒度」**，时间粒度是另一行独立的 chip，已按实际改写。见 [4.12.2](#4122-现状经营业绩) 的筛选品牌图。
**主流程** —— 选择时间粒度与渠道 → 查看指标卡 → 下钻明细
**权限规则** —— 建议限店长；技工可见与其相关的施工量指标 `TODO(REQ-PRF-001)`
**数据来源** —— O2O（O2O 售出、收入、引流转化）、ROOS（签约量、订货量、扫码入库量）
## 4.12.1 目标形态
![设计稿-经营业绩](../app-design-images/经营业绩.png)
**页面内容** —— App 经营业绩页的目标形态，顶部三 Tab + 三个筛选下拉，其下依次是两张并排计数卡、马牌与维京两张性能指标卡（各含入库数 / O2O 售出 / 补货率）、「销售统计」三项与「收入统计」三行。
**关键交互** —— ①切换三 Tab → 换一套指标体系（**注意不只是换数据**，见 [REQ-PRF-009](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)）；②点三个筛选下拉 → 展开选项并刷新全部指标；③点指标卡 → 下钻明细（**本稿未画下钻标识，也未提供明细页的稿**）。
**可用角色** —— 店长 ✅ 全量；技工 ❓，可见范围待定 `TODO(REQ-PRF-001)`。按 REQ-ACC-006，在该项关闭前技工一律不可见收入统计。
**需求关联** —— [REQ-PRF-002](#4124-业务规则) 命名、[REQ-PRF-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp) 指标与筛选的最终集合
> **本稿与现状有四处对不上**，需连同「以哪一版为准」一并裁决（见 [REQ-PRF-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)）：
>
> 1. **两张计数卡的文案完全相同**，都写「扫码入库总数」，仅图标不同（二维码 / 店铺）——用户无从分辨。V1.0 正文称其为「扫码入库总数 / 扫码入库总数（门店）」，但**稿上并没有「（门店）」这个后缀**。而现状的第二张卡是「**O2O 售出**」，根本不是入库数。
> 2. **稿中丢失了「品牌」筛选**：三个下拉画成「当月 / 全部渠道 / 日期选择」，而现状是「品牌 / 渠道 / 日期」+ 独立的时间粒度 chip 行。分品牌性能指标卡（马牌 / 维京）恰恰依赖品牌筛选。
> 3. **收入统计少一项**：现状有四项（含「**总收入**」），稿中只有三项。
> 4. 现状在可下钻的指标上带 👆 标识、页面底部带一行返利实时变动的备注，稿中均无。
>
> 另：稿中马牌与维京的「O2O 售出」同为 5、补货率同为 0.00%，属占位数据。
> 「1.0 / 2.0」是现状 O2O 沿用的版本代号，对门店无业务含义。App 应改用可读的业务命名 —— `TODO(REQ-PRF-002)`。
>
> **补充**：核看现状图后发现这句话说轻了 —— 1.0 与 2.0 **不是同一套指标的两个版本，而是两套完全不同的指标体系**，改名解决不了问题。见 [REQ-PRF-009](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
## 4.12.2 现状经营业绩
![现状-O2O 经营业绩-1.0经营业绩](../mini-program-images/O2O/经营业绩-1.0经营业绩.png)
**页面内容** —— O2O「经营业绩」的 **1.0 经营业绩** 分页，三个 Tab 与三个筛选下拉之下另有一行时间粒度 chip（当月 / 当日 / 当周 / 当季），内容区依次为扫码入库统计、六格分品牌指标、销售统计与含「**总收入**」的收入统计四项，**本图全部指标为 0 或 `--%`，属空态**。
**关键交互** —— ①切换三 Tab → 换指标体系；②三个下拉分别筛品牌 / 渠道 / 日期；③点时间 chip → 切换统计周期（**与「日期选择」区间是互斥还是叠加，本图无法确认**）；④点带 👆 标识的指标（扫码入库总数、马牌入库数、维京入库数）→ 下钻明细；⑤其余指标无下钻标识。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-PRF-001)`。
**需求关联** —— [REQ-PRF-002](#4124-业务规则)、[REQ-PRF-003](#4124-业务规则) 报表合并、[REQ-PRF-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)、[REQ-PRF-009](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)
> 底部备注原文：「上述消费者补贴及好评展示的发放/扣回金额，根据订单核销及延保状态实时变动」。这说明**收入统计不是终值而是可回冲的动态值** —— 与[财务对账](./10-FIN-财务与对账.md)、[返利](./11-RBT-返利中心.md)的口径衔接需注意，该备注在 App 内必须保留。
![现状-O2O 经营业绩-2.0经营业绩](../mini-program-images/O2O/经营业绩-2.0经营业绩.png)
**页面内容** —— **2.0 经营业绩** 分页，筛选只剩两个下拉（**无渠道筛选**），内容只有销售统计三项与收入统计两项，**没有扫码入库统计，也没有分品牌指标**。
**关键交互** —— ①同上，但少一个渠道筛选；②本页指标**均无 👆 下钻标识**。
**可用角色** —— 同上图。
**需求关联** —— [REQ-PRF-009](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)
> **本图是「1.0/2.0 不是版本号」的直接证据**：两个分页的指标名称无一相同（1.0 是订单数量 / 轮胎条数 / 延保条数，2.0 是下单数量 / 下单人数 / 商品数），筛选项数量也不同。**「下单人数」是 1.0 完全没有的消费者维度指标**。
![现状-O2O 经营业绩-2.0引流转化](../mini-program-images/O2O/经营业绩-2.0引流转化.png)
**页面内容** —— **2.0 引流转化** 分页，**结构与前两个分页完全不同**：筛选为「全部」+ 月份区间与一行排名灰字，主体是三项转化指标（各带环比）与其下三项线索来源细分，再下方是年度折线图与「我的数据 / 市平均值 / 全国平均值」三个图例开关，**本图指标全为 `—`、折线图全为 0，属空态**。
**关键交互** —— ①点指标旁的 ⓘ → 指标口径说明；②点年份下拉 → 切换折线图年度；③开关三条对比曲线的显隐；④折线图**横向滚动**查看 12 个月（本图仅能看到 1–5 月，下方有滚动条）。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-PRF-001)`。本页含「市/全国平均值」与门店排名，属对标数据，技工可见性尤需明确。
**需求关联** —— [REQ-PRF-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp) 引流转化指标体系
> **V1.0 的 4.12「页面内容」完全没有描述本分页** —— 只列了「扫码入库双计数、分品牌性能指标、销售统计、收入统计」，那些全属 1.0 分页。本页的线索三分类、环比、门店排名、市/全国对标折线图**在需求中一条都没有**，见 [REQ-PRF-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
>
> 折线图的横向滚动与[提醒模块](./04-RMD-提醒.md)中发现的横向滚动是同类问题：**为宽屏设计的图表直接搬到手机上**。App 化时需重做图表适配。
![现状-O2O 经营业绩-筛选渠道](../mini-program-images/O2O/经营业绩-筛选渠道.png)
**页面内容** —— 1.0 分页上「全部渠道」下拉的展开态，白色浮层完整拍到 8 项取值：**全部渠道**（已选中）/ 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎。
**关键交互** —— ①点任一渠道 → 收起浮层并按该渠道刷新全部指标；②点浮层外区域 → 收起。**浮层是否可继续下滑露出更多渠道，本图无法确认。**
**可用角色** —— 同 1.0 分页。
**需求关联** —— [REQ-PRF-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)
> 这是全文唯一一处**完整列出 O2O 渠道全集**的证据（7 个实际渠道）。注意「京东」与「京东秒送」是**两个独立渠道**。该取值集与[销售模块](./03-SAL-销售.md)的订单来源渠道标（设计稿中出现过「天猫订单」「京东订单」）应为同一份主数据，需在[第 5 章主数据](../Continental-Retail-APP-PRD.md#5-主数据)中统一。
![现状-O2O 经营业绩-筛选品牌](../mini-program-images/O2O/经营业绩-筛选品牌.png)
**页面内容** —— 1.0 分页上**第一个**下拉的展开态，取值为「全部」（已选中）/ 马牌 / 维京 —— 证明该下拉是**品牌筛选**而非时间粒度。
**关键交互** —— ①点品牌 → 收起并按品牌刷新指标。
**可用角色** —— 同 1.0 分页。
**需求关联** —— [REQ-PRF-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)
> **本图是纠正 V1.0「三个筛选（时间粒度 / 渠道 / 日期）」这句话的依据**，也是判定设计稿丢失品牌筛选的依据。品牌取值只有马牌与维京两个，与[库存模块](./07-INV-库存.md)的品牌筛选取值范围是否一致，需在主数据侧核对。
![现状-O2O 经营业绩-筛选日期](../mini-program-images/O2O/经营业绩-筛选日期.png)
**页面内容** —— 「日期选择」下拉的展开态，只有一个含「起」「止」两个输入框与一个「查询」按钮的「选择查询时间」区，**本图两框均为空、按钮置灰**，故日期控件的具体形态（日历弹层还是滚轮）无法从本图确认。
**关键交互** —— ①点「起」/「止」→ 唤起日期选择控件；②两端都选定后「查询」转为可点；③点「查询」→ 按区间刷新指标。
**可用角色** —— 同 1.0 分页。
**需求关联** —— [REQ-PRF-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)
> 页面同时存在「当月/当日/当周/当季」四个时间 chip 与这个自定义区间，**两者是互斥还是叠加，现状图无法判定**，App 化时须明确（否则会出现「当月 + 跨月区间」这类自相矛盾的组合）。
## 4.12.3 采购侧业绩详情
**业绩详情**：在「我的」菜单下，点击「经营业绩」进入「业绩详情」，业绩详情包含**签约量、订货量、扫码入库量、O2O 售出量**；签约量分为**月度签约量、季度签约量**；订货量、扫码入库量、O2O 售出量均支持**年份 + 月度/季度**维度筛选查看。
![现状-ROOS 业绩详情](../mini-program-images/ROOS/业绩详情.png)
**页面内容** —— ROOS「业绩详情」页，顶部是一个橙色的统计主体下拉「**Continental–上海**」，其下为签约量 / 订货量 / 扫码入库量 / O2O 售出量四个指标区块（后三个各自带年份下拉、区块内两张卡再各带月份与季度下拉），**只有签约量有非零数据**（月度 100 / 季度 300）。
**关键交互** —— ①点顶部下拉 → 切换统计主体；②每个区块的年份下拉 → 切换年度；③每张卡的月份 / 季度下拉 → 切换周期。**全页共有 10 个独立筛选控件**，无统一筛选栏。
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-PRF-001)`。签约量属商务承诺数据，技工可见性需明确。
**需求关联** —— [REQ-PRF-003](#4124-业务规则) 报表合并、[REQ-PRF-005](#4124-业务规则) 月度签约达成预警
> **本图给 [REQ-PRF-003](#4124-业务规则) 补了三条具体障碍**，合并方案必须逐条回答：
>
> 1. **统计主体不同**。顶部下拉写的是「Continental–上海」，从命名看是**签约主体或区域**，而非某家具体门店；O2O 经营业绩则是门店维度。同名指标挂在不同主体上，直接相加会错。**本图无法确认该下拉的确切层级**，需向业务核实。
> 2. **时间粒度不同**。ROOS 只有「年 + 月 / 年 + 季」，O2O 有「当日 / 当周 / 当月 / 当季 + 自定义区间」。合并后取哪一套。
> 3. **筛选模型不同**。ROOS 是每个区块各自带筛选（共 10 个控件），O2O 是页面顶部统一筛选栏。这不只是样式差异 —— ROOS 允许「订货量看 4 月、扫码入库量看 3 月」这种**跨周期并列**，统一筛选栏做不到。
>
> 另注意本页对空值有**两种写法**：订货量与扫码入库量写 `0`，O2O 售出量写 `—`。前者是「统计结果为零」，后者通常是「无数据」，同一页面不应混用。
> **两套经营业绩的指标高度重叠但口径不同**：ROOS 业绩详情与 O2O 经营业绩都统计「扫码入库量」和「O2O 售出量」。合并为一套报表还是并列两个 Tab —— `TODO(REQ-PRF-003)`，与 [REQ-INV-005](./07-INV-库存.md#474-业务规则)（入库写入目标）是同一个根因。
>
> 延保侧还有第三套经营数据（[4.5.6](./05-WTY-延保.md#456-工作台返利与经营数据)）—— `TODO(REQ-PRF-004)`。
## 4.12.4 业务规则
**REQ-PRF-001 权限** —— 技工可见的指标范围待定 `TODO(REQ-PRF-001)`
**REQ-PRF-002 命名** —— 「1.0 / 2.0」版本代号需替换为业务可读名称 `TODO(REQ-PRF-002)`
> ⚠️ 改名之前须先厘清两者的业务口径差异，见 [REQ-PRF-009](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
**REQ-PRF-003 报表合并** —— ROOS 与 O2O 两套业绩的合并方式待定 `TODO(REQ-PRF-003)`
**REQ-PRF-004 延保数据并入** —— 延保经营数据是否并入统一报表待定 `TODO(REQ-PRF-004)`
**REQ-PRF-005 月度签约达成预警** —— [首页动态预警](./02-HOM-APP首页与导航.md#423-店长首页)中的「月度签约达成」阈值取自签约量指标，规则待定 `TODO(REQ-HOM-009)`
**REQ-PRF-006 首页营收卡片** —— 设计稿的「今日预计营收 / 毛利 / 客单价」在本模块无对应指标，口径待定 `TODO(REQ-HOM-011)`
> 逐图核看确认了这一条：8 张图中**没有任何一处出现「毛利」「客单价」「预计营收」**。现状最接近的只有「货款收入-结算总额」与「总收入」，二者都是已发生的收入，不是「预计」，也不含成本项。首页那张卡片的三个指标**在现有数据源里全部无对应**，需新建口径。
**REQ-PRF-007 引流转化指标体系** —— 「2.0 引流转化」分页含线索数量 / 轮胎转化 / 好评数量三项主指标（均带环比）、线索按电话 / 导航 / 订单三类细分、上月门店排名，以及可叠加市平均与全国平均对标曲线的年度折线图。是否纳入首版、对标数据谁算谁可见、线索分类口径、折线图的移动端适配，均待定 `TODO(REQ-PRF-007)`
**REQ-PRF-008 指标与筛选的最终集合** —— 设计稿与现状有四处实质不一致（第二张计数卡的指标、品牌筛选的存废、收入统计三项还是四项、下钻标识），且时间 chip 与自定义日期区间是互斥还是叠加未定。以哪一版为准待定 `TODO(REQ-PRF-008)`
**REQ-PRF-009 1.0 与 2.0 的业务口径** —— 两者指标名无一相同，是两套不同的指标体系而非同一套的两个版本。各自对应什么业务范围、能否合并或废弃其一、在此之前 App 是否照搬两个 Tab，待定 `TODO(REQ-PRF-009)`
## 4.12.5 验收标准
1. 时间粒度、渠道、日期三个筛选任意组合下，各指标卡与下钻明细口径一致；
2. 同一指标（如扫码入库量）在首页、经营业绩、库存三处显示的数值一致；
3. 技工不可见的指标在接口层即不返回，而非仅前端隐藏。
> 第 1 条需补充「品牌」这一维（现状是四个筛选维度：品牌 / 渠道 / 日期 / 时间粒度），并明确时间 chip 与自定义区间的互斥关系。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A.8，与 FIN 共用一节）
主文件[附录 A.8「经营分析与财务」](../Continental-Retail-APP-PRD.md#a8-经营分析与财务)一节跨 PRF 与 FIN 两个模块，共 3 条：
| # | 数据集 | 来源 | 安全 | 归属 |
| --- | --- | --- | --- | --- |
| 1 | 对账单（采购及返利对账单，来自 ROOS 与 F6） | Mini Program Backend | HTTPS | [FIN](./10-FIN-财务与对账.md) |
| 2 | 核销结果集（门店核销收入） | Mini Program Backend | HTTPS | [FIN](./10-FIN-财务与对账.md) |
| 3 | 返利结果集（余额、明细、规则、提现） | Mini Program Backend | HTTPS | [RBT](./11-RBT-返利中心.md) |
附录 A.8 三条数据集的模块归属
> **A.8 名为「经营分析与财务」，但三条数据集全部属于财务与返利，经营分析的指标一条都没有。** 本模块涉及的以下数据集在附录 A 中**完全缺失**，需业务补齐字段级定义：
| 数据集 | 来源 | 备注 |
| --- | --- | --- |
| 扫码入库统计（总数 + 分品牌入库数） | O2O + ROOS | 两系统同名指标，口径待合并 [REQ-PRF-003](#4124-业务规则) |
| O2O 售出量与补货率（分品牌） | O2O | 补货率 = 入库 / 售出，口径需确认 |
| 销售统计（1.0：订单数量 / 轮胎条数 / 延保条数；2.0：下单数量 / 下单人数 / 商品数） | O2O | 两套指标名互不相同 [REQ-PRF-009](#附-5-本次拆分新增发现待业务确认) |
| 收入统计（货款收入 / 消费者补贴 / 抽奖红包返利 / 总收入） | O2O | **可回冲的动态值**，随订单核销与延保状态变动 |
| 引流转化（线索数量 / 轮胎转化 / 好评数量；电话·导航·订单线索；市与全国平均值；门店排名） | O2O | 需求中完全未定义 [REQ-PRF-007](#附-5-本次拆分新增发现待业务确认) |
| 签约量（月度 / 季度） | ROOS | 首页「月度签约达成预警」的阈值来源 [REQ-PRF-005](#4124-业务规则) |
| 订货量 | ROOS | |
| 渠道主数据（小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎） | O2O | 应与[销售](./03-SAL-销售.md)的订单来源渠道同源，见[第 5 章](../Continental-Retail-APP-PRD.md#5-主数据) |
经营业绩模块数据集（**本表为本次拆分据现状截图补写，非主文件原文**，需业务确认后并入附录 A）
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 全量指标 | ✅ | ❓ | 技工可见范围 `TODO(REQ-PRF-001)` |
经营业绩模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 矩阵只有「全量指标」一行，粒度过粗。逐图核看后，本模块至少有**四类敏感度不同的指标**需分别定级，建议在关闭 `TODO(REQ-PRF-001)` 时按下表细化：
>
> | 指标类 | 举例 | 建议 |
> | --- | --- | --- |
> | 金额类 | 货款收入、总收入、消费者补贴 | 店长 ✅ / 技工 ✗（与[首页金额隐藏](./02-HOM-APP首页与导航.md#426-业务规则)口径一致） |
> | 商务承诺类 | 月度 / 季度签约量 | 店长 ✅ / 技工 ✗ |
> | 对标排名类 | 市平均值、全国平均值、上月排名 | 店长 ✅ / 技工 ❓ |
> | 作业量类 | 扫码入库数、轮胎条数、延保条数 | 店长 ✅ / 技工 ✅（即主文件所说「与其相关的施工量指标」） |
>
> 上表为建议值，非已决结论。按 REQ-ACC-006，关闭前技工一律按最严格实现（仅作业量类可见）。
### 附-3 待确认项（主文件 10.2.11）
主文件 10.2.11 是「业绩、营销、福利兑换（PRF / MKT / MSP）」三模块合并的一节，以下为按 REQ 前缀拆出的 PRF 分片：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-PRF-001 | 技工可见的业绩指标范围 | 业务 |
| REQ-PRF-002 | 「1.0 / 2.0」版本代号的业务命名替换 | 产品 |
| REQ-PRF-003 | ROOS 与 O2O 两套业绩的合并方式 | 业务 |
| REQ-PRF-004 | 延保经营数据是否并入统一报表 | 业务 |
经营业绩模块待确认项（摘自主文件 [10.2.11](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)，4 条）
**本次拆分新增 3 条**（回灌主文件时并入 10.2.11）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| **REQ-PRF-007** | **引流转化 Tab 的指标体系未定义** —— 线索三分类、环比、门店排名、市/全国对标折线图在需求中一片空白，详见[附-5](#附-5-本次拆分新增发现待业务确认) | 产品 / 业务 |
| **REQ-PRF-008** | **指标与筛选的最终集合以哪一版为准** —— 设计稿与现状有四处实质不一致（计数卡文案、品牌筛选、收入项数、下钻标识） | 产品 |
| **REQ-PRF-009** | **1.0 与 2.0 是两套不同的指标体系，不是同一套的两个版本** —— 指标名无一相同，仅改名不足以解决 | 业务 / 产品 |
合计 7 条待确认（原 4 条 + 新增 3 条）。回灌时需同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 PRF 行（6 / 4 / 33% → 9 / 7 / 22%）与第 10.2 节总数。
> 另有两条**记在本模块名下但归属其它模块**的规则：[REQ-PRF-005](#4124-业务规则) 挂 `TODO(REQ-HOM-009)`、[REQ-PRF-006](#4124-业务规则) 挂 `TODO(REQ-HOM-011)`，两条 TODO 均登记在 [10.2.2 首页](./02-HOM-APP首页与导航.md#附-3-待确认项主文件-1022)下，不重复计入本模块的 4 条。
### 附-4 配图清单（主文件附录 C 4.12 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-经营业绩（App 目标形态）：**两张计数卡文案相同、缺品牌筛选、缺「总收入」** | `../app-design-images/经营业绩.png` |
| 2 | 现状-O2O 经营业绩（1.0）：入库统计 + 分品牌指标 + 销售统计 + 收入四项；**全空态** | `../mini-program-images/O2O/经营业绩-1.0经营业绩.png` |
| 3 | 现状-O2O 经营业绩（2.0）：**另一套指标**（下单数量/下单人数/商品数），无渠道筛选 | `../mini-program-images/O2O/经营业绩-2.0经营业绩.png` |
| 4 | 现状-O2O 经营业绩（2.0 引流转化）：线索三分类 + 环比 + 排名 + 市/全国对标折线图；**全空态** | `../mini-program-images/O2O/经营业绩-2.0引流转化.png` |
| 5 | 现状-O2O 经营业绩（筛选渠道）：**完整 7 个渠道取值** | `../mini-program-images/O2O/经营业绩-筛选渠道.png` |
| 6 | 现状-O2O 经营业绩（筛选品牌）：取值全部 / 马牌 / 维京，**证明首个筛选是品牌不是时间** | `../mini-program-images/O2O/经营业绩-筛选品牌.png` |
| 7 | 现状-O2O 经营业绩（筛选日期）：起止区间 + 查询按钮，**两框为空、按钮置灰** | `../mini-program-images/O2O/经营业绩-筛选日期.png` |
| 8 | 现状-ROOS 业绩详情：签约量（唯一有数据）+ 订货量 / 扫码入库量 / O2O 售出量，**10 个独立筛选控件** | `../mini-program-images/ROOS/业绩详情.png` |
经营业绩模块配图清单，8 张（设计稿 1 / 现状-O2O 6 / 现状-ROOS 1）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
> 8 张中 **6 张为空态或零值**，唯一有真实数据的是 ROOS 业绩详情的签约量（月度 100 / 季度 300）与设计稿的占位数据。与 [MKT 模块](./13-MKT-营销与会员.md#附-4-配图清单主文件附录-c-413-节)同样的问题：**现状证据不足以验证指标的真实取值范围与量级**，评审前建议索取一份有真实数据的门店账号截图。
### 附-5 本次拆分新增发现（待业务确认）
以下 3 条**不在主文件现有 6 条 PRF 需求内**，是本次逐张核看 8 张配图时发现的、现有需求未覆盖的事项。编号接 REQ-PRF-006 顺延，**尚未登记进主文件 10.2.11**，回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。
| 编号 | 待确认内容 | 证据 | 建议决策方 |
| --- | --- | --- | --- |
| REQ-PRF-007 | **引流转化 Tab 的指标体系未定义**：主文件「页面内容」只描述了 1.0 分页的指标，「2.0 引流转化」整个分页在需求中一片空白。该分页实际含：①线索数量 / 轮胎转化 / 好评数量三项主指标，均带**环比上月**；②线索按**电话 / 导航 / 订单**三类细分；③**上月门店排名**；④按年度的折线图，可叠加**市平均值与全国平均值**对标曲线。需确认：①是否纳入 App 首版；②排名与市/全国平均值由谁计算、能否对门店开放；③线索三分类的采集口径（导航线索指高德/百度导航到店？）；④折线图现状**横向滚动**，移动端需重做适配；⑤对标数据对技工是否可见。 | [4.12.2](#4122-现状经营业绩) 图 4 | 产品 / 业务 |
| REQ-PRF-008 | **指标与筛选的最终集合以哪一版为准**：设计稿与现状有四处实质不一致 —— ①现状第二张计数卡是「O2O 售出」，设计稿画成第二个「**扫码入库总数**」且与第一张**文案完全相同**、仅图标不同；②设计稿**丢失品牌筛选**（现状是品牌 / 渠道 / 日期三个下拉 + 当月·当日·当周·当季 chip 行；设计稿是当月 / 全部渠道 / 日期选择），而分品牌指标卡依赖它；③现状收入统计四项含「**总收入**」，设计稿只有三项；④现状带 👆 下钻标识与底部「返利实时变动」备注，设计稿均无。另需一并明确：时间 chip 与自定义日期区间是**互斥还是叠加**。 | [4.12.1](#4121-目标形态) 图 1 + [4.12.2](#4122-现状经营业绩) 图 2、5、6、7 | 产品 |
| REQ-PRF-009 | **1.0 与 2.0 是两套不同的指标体系，不是同一套的两个版本**：1.0 有扫码入库统计、分品牌性能指标、渠道筛选、四项收入（订单数量 / 轮胎条数 / 延保条数）；2.0 只有三项销售指标（下单数量 / **下单人数** / 商品数）与两项收入，无入库、无分品牌、无渠道筛选。两者指标名**无一相同**，「下单人数」更是 1.0 没有的消费者维度。因此 [REQ-PRF-002](#4124-业务规则)「换个可读名字」并不足够，需先回答：①两者各自对应什么业务范围（是否两代 O2O 履约模式）；②是否可合并为一套，或废弃其一；③在此之前 App 是否照搬两个 Tab。 | [4.12.2](#4122-现状经营业绩) 图 2、图 3 | 业务 / 产品 |
本次拆分新增待确认项，3 条
> 另有两项**不需新增编号**的观察，已就地记在图下：①[REQ-PRF-003](#4124-业务规则) 的合并障碍已具体化为三条（统计主体不同 —— ROOS 顶部下拉「Continental–上海」疑为区域/签约主体而非门店、时间粒度不同、筛选模型不同），合并方案须逐条回答；②[REQ-PRF-006](#4124-业务规则) 经核实成立 —— 8 张图中**没有任何一处出现「毛利」「客单价」「预计营收」**，首页营收卡片的三个指标在现有数据源里全部无对应，必须新建口径而非映射现有字段。
>
> 另有一项数据质量观察：ROOS 业绩详情对空值混用 `0` 与 `—` 两种写法，同一页面内含义不一致。该数据由 ROOS 维护，本 PRD 不为此提需求，但 App 聚合时须统一空值语义，避免把「无数据」渲染成「零」。
prd/modules/13-MKT-营销与会员.md
+264
View File
@@ -0,0 +1,264 @@
# 4.13 营销与会员
> **本文件是【营销与会员 MKT】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.13 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | MKT |
| V1.0 章节 | 4.13 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状截图反推 |
| 现状承载系统 | O2O 接单宝 |
| 需求条数 | 8（待确认 7，完成度 13%） |
| 本次新增待确认 | 3（REQ-MKT-006 / 007 / 008 见[附-5](#附-5-本次拆分新增发现待业务确认)） |
| 配图 | 7 张（全部为现状-O2O） |
模块概要
---
> 本节对应[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销)「支付与营销」，内容由 O2O 优惠券、会员权益、门店海报截图构建。
**业务目标** —— 让门店在开单现场就能用上券和会员权益，并具备自主获客的物料，解决[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销)
**入口** —— O2O 工具条「优惠券」「会员权益」「门店海报」；[开单结算](./03-SAL-销售.md#437-结算与延保跳转)流程中的选券环节
**页面内容** —— 消费券 / 门店营销券、选择营销券、会员权益选择弹窗、会员体系开通状态、门店海报
**主流程**：
- 开单选券：结算 → 选择营销券 → 应用 → 计入金额
- 会员权益：开单 → 选择会员权益 → 应用
> ⚠️ **上面「会员权益」这条主流程与现状不符** —— 现状是首页宫格的独立入口，输会员手机号后勾选权益并提交，与开单流程无关。见 [REQ-MKT-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
**权限规则** —— 店长可管理；技工在开单时可使用 `TODO(REQ-MKT-001)`
**数据来源** —— O2O（券、会员权益、海报）、ROOS（[采购优惠券](./08-MIN-我的.md#482-roos我的采购域资产)）
## 4.13.1 优惠券
![现状-O2O 优惠券-消费券](../mini-program-images/O2O/优惠券-消费券.png)
**页面内容** —— O2O「优惠券」页的**消费券**分页（另一分页为「门店营销券」），上半部是门店的**消费券额度**看板（三项额度均为 0，配补货率环形图与一条「未满足规则，消费券额度不会增加」的橙色提示），下半部是一张可发放的满减券条目与底部**置灰**的「去发放（0）」。
**关键交互** —— ①点「额度变更记录」→ 额度流水；②点橙色提示条的「详情」→ 额度累积规则说明；③券条目的 `−` / `+` 步进器 → 调整发放数量，同步更新底部「使用额度」与「去发放（N）」计数；④点「详细说明 ∨」→ 展开该券的使用说明；⑤点「去发放」→ 发券（**本图为置灰态，发放后的流程无法从本图确认**）。
**可用角色** —— 店长 ✅（属「管理券」，附录 B 已定技工 ✗）；技工 ✗ `TODO(REQ-MKT-001)`。
**需求关联** —— [REQ-MKT-001](#4134-业务规则) 权限、[REQ-MKT-002](#4134-业务规则) 券体系归并、[REQ-MKT-006](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp) 消费券额度机制
> **本图揭示了一条 PRD 完全未描述的机制**：消费券**不是门店自建**的，而是按「扫码入库」与「补货率」自动累积额度，未达规则则不增额度，门店只能在额度内发放 —— 即消费券是**与进货挂钩的厂商激励**，不是普通营销券。详见 [REQ-MKT-006](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
>
> 图中券名为 `shasha_test`，「优惠范围 1~5」「使用门槛 1~5」「仅剩 1」均为**测试数据**，不代表真实券配置。
![现状-O2O 优惠券-门店营销券](../mini-program-images/O2O/优惠券-门店营销券.png)
**页面内容** —— 同一页面的**门店营销券**分页，顶部为虚线框的「+ 创建门店营销券」入口与「发放统计」卡片，**本图为空态**（「当前没有门店可用营销券」），故营销券条目的字段构成无法从本图确认。
**关键交互** —— ①点「+ 创建门店营销券」→ 建券表单（**表单字段无设计稿也无现状图，未知**）；②点月份下拉 → 切换统计周期，刷新三项计数。
**可用角色** —— 店长 ✅；技工 ✗ `TODO(REQ-MKT-001)`。
**需求关联** —— [REQ-MKT-001](#4134-业务规则)、[REQ-MKT-002](#4134-业务规则)
> **两个分页是两种截然不同的券**：消费券由上游按进货表现下发额度、门店只能发放；门店营销券由**门店自己创建**、自负成本。这一区别直接决定 [REQ-MKT-002](#4134-业务规则)「三套券叠加规则」的裁决方式 —— 资金来源不同的券能否叠加，是财务问题而非产品问题。
![现状-O2O 选择营销券-空态](../mini-program-images/O2O/选择营销券-空态.png)
**页面内容** —— 开单结算环节的「选择营销券」页，**本图为完全空态**（占位插图 +「当前没有营销券」），除标题栏外无任何控件，故券列表的行内字段、可用/不可用的区分方式与是否支持多选均无法从本图确认。
**关键交互** —— ①左上返回 → 回结算页。有券时的选择交互本图无法确认。
**可用角色** —— 店长 ✅、技工 ✅（属「使用券（开单时）」，附录 B 已定两角色均 ✅）。
**需求关联** —— [REQ-MKT-002](#4134-业务规则)
> [验收标准第 2 条](#4135-验收标准)要求「不可用券给出不可用原因而非简单置灰」，但本图是空态，**现状是否已展示不可用券、以何种方式展示，本图无法确认** —— 该条属新增要求，需在设计稿中明确。
## 4.13.2 会员权益
![现状-O2O 会员权益弹窗](../mini-program-images/O2O/会员权益弹窗.png)
**页面内容** —— 从 O2O 接单宝首页宫格「会员权益」唤起的弹窗，含会员手机号输入框、两项各带圆形勾选标的「权益」列表与底部橙色「确认提交」按钮，**弹窗背后是 O2O 首页**。
**关键交互** —— ①输入会员手机号 → 标识会员身份；②点权益行 → 选中/取消；③点「确认提交」→ 核销该会员的权益；④点 × → 关闭弹窗。
**可用角色** —— 店长 ✅、技工 ✅（附录 B「使用券与会员权益（开单时）」两角色均 ✅）。
**需求关联** —— [REQ-MKT-004](#4134-业务规则) 会员能力开关、[REQ-MKT-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp) 会员权益的触发位置
> **本图与本节主流程描述不符**：主流程写「开单 → 选择会员权益 → 应用」，而现状是**首页独立入口 + 输手机号核销**，整个过程与订单无关，弹窗内也没有任何订单信息。两种形态的差别很大（一个是订单折扣项，一个是到店服务核销），需裁决 —— 见 [REQ-MKT-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
![现状-O2O 会员权益弹窗-已选权益](../mini-program-images/O2O/会员权益弹窗-已选权益.png)
**页面内容** —— 同一弹窗的**已选中态**：「免费查车」变为浅橙底 + 实心黑色对勾，「免费加玻璃水」仍为未选中，手机号输入框仍为空。
**关键交互** —— ①再点已选行 → 取消选中（推测，本图无法确认）。**本图只选中了一项，无法确认权益是单选还是多选**。
**可用角色** —— 同上图。
**需求关联** —— [REQ-MKT-007](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)
> 手机号未填时「确认提交」按钮仍为**完整橙色可点态**，未见禁用态。App 化时该按钮应在手机号校验通过前禁用。
![现状-O2O 会员体系门店-未开通](../mini-program-images/O2O/会员体系门店-未开通.png)
**页面内容** —— 门店**未开通会员体系**时的引导页，灰色锁形图标与「会员体系门店未开通」之下列出开通所需的 8 个服务标签（**其中混有回归测试数据**）及一句服务同步开通说明，底部是未勾选的协议行加橙色「开通会员体系门店」按钮。
**关键交互** —— ①点《德国马牌门店非轮胎项目服务协议》→ 查看协议全文；②勾选「本店具备以上服务……愿意加入上述选择的服务体系」；③点「开通会员体系门店」→ 提交开通（**是否即时生效、是否需上游审核，本图无法确认**）。8 个服务标签样式一致、无选中态，**本图无法确认它们是静态展示还是可逐项勾选**。
**可用角色** —— 店长 ✅（开通属门店级承诺，且涉及协议签署）；技工 ✗（建议值，附录 B 未单列此功能）。
**需求关联** —— [REQ-MKT-004](#4134-业务规则)、[REQ-MKT-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp) 会员体系开通流程
> **本图暴露了 [REQ-MKT-004](#4134-业务规则) 的一处逻辑冲突**：该规则要求「未开通会员体系的门店隐藏相关入口」，但**本页本身就是未开通门店才能看到的开通入口** —— 若一并隐藏，门店将永远无法自助开通。需求需细化为「隐藏的是权益核销入口，保留的是开通申请入口」，见 [REQ-MKT-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
>
> 服务标签中的「**测试无需领取的**」「**回归531会员**」「**全回归1028**」三项是 O2O 侧的**测试数据**，非真实服务项；真实项应为前 5 项。该数据由 O2O 维护，清理属 O2O 侧责任，本 PRD 不为此提需求，仅提示读者勿据此图统计服务项数量。
>
> 本页的《德国马牌门店非轮胎项目服务协议》是继[用户协议与隐私政策](./01-LGN-账号登录.md#412-业务规则)之外的**第三份需签署留痕的协议**（O2O 首页另有「协议中心」入口），App 化后协议签署的版本号与时间戳如何留痕，随 [REQ-MKT-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp) 一并确认。
> 会员体系是**门店级能力开关**：未开通的门店应隐藏相关入口，而非展示空页面。这是[门店能力开关](../Continental-Retail-APP-PRD.md#74-门店能力开关)的典型场景。
## 4.13.3 门店海报
![现状-O2O 门店海报](../mini-program-images/O2O/门店海报.png)
**页面内容** —— 「门店海报」页，只有橙色区块的「门店小程序码」与白色区块的「门店海报」列表两块，**列表为空态**（「没有数据了！」），故海报条目的字段构成、尺寸与模板类型均无法从本图确认。
**关键交互** —— ①点/长按小程序码 → 保存或分享（**本图未画出任何按钮，交互方式无法确认**）；②有海报时点条目 → 预览/保存（同样无法确认）。**本图中未见「保存到相册」或「分享」控件**。
**可用角色** —— 店长 ✅；技工 ✗（附录 B「管理券 / 门店海报」已定技工 ✗）`TODO(REQ-MKT-001)`。
**需求关联** —— [REQ-MKT-001](#4134-业务规则)、[REQ-MKT-003](#4134-业务规则) 海报分享
> V1.0 的 4.13.3 称「海报涉及保存到相册与分享」，但**本图并未出现这两个控件** —— 它们可能在海报详情页或长按菜单中，也可能是 App 端的新增能力。`TODO(REQ-MKT-003)` 需一并明确控件位置，不只是分享目标。
>
> 另需注意：页面顶部的「门店小程序码」与海报是**两件不同的物料**，V1.0 只提到海报。小程序码扫码后进入的是消费者侧小程序（消费者侧本就不做 App 化），因此码本身无需改造，但 App 内是否保留该展示位需确认。
> 海报涉及保存到相册与分享。App 内需要相册写入权限与分享能力 —— 见 [8.4 安全与合规](../Continental-Retail-APP-PRD.md#84-安全与合规)、《App 原生能力集成文档》。分享目标（微信 / 系统分享）—— `TODO(REQ-MKT-003)`。
## 4.13.4 业务规则
**REQ-MKT-001 权限** —— 技工在开单时可用券与权益，但不可管理 `TODO(REQ-MKT-001)`
**REQ-MKT-002 券体系归并** —— 三套券的适用场景与叠加规则待定 `TODO(REQ-MKT-002)`
**REQ-MKT-003 海报分享** —— 分享目标与相册权限方案待定 `TODO(REQ-MKT-003)`
**REQ-MKT-004 会员能力开关** —— 未开通会员体系的门店隐藏相关入口
> ⚠️ 该规则需细化：隐藏的是**权益核销**入口，**开通申请入口必须保留**，否则门店无法自助开通。见 [REQ-MKT-008](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)。
**REQ-MKT-005 券与返利关系** —— 消费者补贴（[返利构成](./11-RBT-返利中心.md#4114-返利构成说明)）与消费券是否为同一资金来源待定 `TODO(REQ-MKT-005)`
**REQ-MKT-006 消费券额度机制** —— 消费券非门店自建，额度按「扫码入库」与「补货率」自动累积，门店只能在可用额度内发放，实质是与进货表现挂钩的厂商激励。累积规则与考核周期、额度变更记录与详情两页是否进 App、发放对象与领取方式、额度是否随[切换门店](./02-HOM-APP首页与导航.md#426-业务规则)隔离，均待定 `TODO(REQ-MKT-006)`
**REQ-MKT-007 会员权益的触发位置** —— 本节主流程写作「开单 → 选择会员权益 → 应用」，现状却是首页宫格独立入口 → 输入会员手机号 → 勾选权益 → 提交，与开单流程完全解耦，二者是不同的业务动作。App 采用哪一种、权益单选还是多选、核销是否生成单据并计入[经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)、会员手机号与[销售](./03-SAL-销售.md#43-销售)侧客户手机号是否同一份数据，均待定 `TODO(REQ-MKT-007)`
**REQ-MKT-008 会员体系开通流程与协议留痕** —— 开通是门店自助动作，前置条件是承诺具备一组非轮胎服务能力并签署《德国马牌门店非轮胎项目服务协议》，开通后联动服务项管理。App 是否承载该流程、服务标签是承诺清单还是可逐项勾选、是否需上游审核、协议签署留痕（版本号 + 时间戳）如何处理，均待定 `TODO(REQ-MKT-008)`。这是继[用户协议与隐私政策](./01-LGN-账号登录.md#412-业务规则)之外的第三份协议
## 4.13.5 验收标准
1. 未开通会员体系的门店，会员权益入口不下发；
2. 开单选券时，不可用券给出不可用原因而非简单置灰；
3. 海报保存失败（无相册权限）时给出可操作的引导，而非静默失败。
---
## 附：本模块归拢信息
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典（主文件附录 A）
**主文件附录 A 未收录本模块的字段清单。** 附录 A 现有 A.1–A.9 九节（登录 / 首页 / 销售 / 提醒 / 采购 / 延保 / 门店管理 / 财务业绩 / 个人中心），**INV、RBT、MKT、MSP 四个模块没有对应节**。
本模块至少涉及以下数据集，需业务补齐字段级定义：
| 数据集 | 来源 | 备注 |
| --- | --- | --- |
| 消费券额度（总额度 / 可用额度 / 扫码入库新增额度） | O2O | 含额度变更流水，见 [REQ-MKT-006](#附-5-本次拆分新增发现待业务确认) |
| 消费券列表（券类型 / 优惠范围 / 门槛 / 有效期 / 剩余数量） | O2O | |
| 门店营销券（门店自建）与发放统计 | O2O | 创建总数 / 已领取 / 已使用，按月 |
| 会员权益项与核销记录 | O2O | 以会员手机号为主键 |
| 会员体系开通状态与服务项清单 | O2O | 门店级能力开关，见[门店能力开关](../Continental-Retail-APP-PRD.md#74-门店能力开关) |
| 门店海报与门店小程序码 | O2O | |
营销与会员模块数据集（**本表为本次拆分据现状截图补写，非主文件原文**，需业务确认后并入附录 A）
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 使用券与会员权益（开单时） | ✅ | ✅ | |
| 管理券 / 门店海报 | ✅ | ✗ | `TODO(REQ-MKT-001)` |
营销与会员模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
> 附录 B 只有两行，覆盖不全。逐图核看后发现**至少两项功能未在矩阵中列明**：①「会员体系开通」（涉及协议签署与门店级服务承诺，建议店长 ✅ / 技工 ✗）；②「消费券发放（去发放）」（涉及厂商额度消耗，建议店长 ✅ / 技工 ✗）。两项均随 [REQ-MKT-006](#附-5-本次拆分新增发现待业务确认) / [REQ-MKT-008](#附-5-本次拆分新增发现待业务确认) 补入附录 B。
>
> 另注意「使用券与会员权益（开单时）」这一行的括号 —— 若 [REQ-MKT-007](#附-5-本次拆分新增发现待业务确认) 裁定会员权益是**独立核销入口**而非开单环节，该行的措辞与权限边界都要改写。
### 附-3 待确认项（主文件 10.2.11）
主文件 10.2.11 是「业绩、营销、福利兑换（PRF / MKT / MSP）」三模块合并的一节，以下为按 REQ 前缀拆出的 MKT 分片：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-MKT-001 | 技工可用券与权益但不可管理，边界确认 | 产品 |
| REQ-MKT-002 | **三套券（O2O 消费券 / 门店营销券 / ROOS 马牌券·经销商券）的适用场景与叠加规则** | 业务 |
| REQ-MKT-003 | 门店海报的分享目标与相册权限方案 | 产品 |
| REQ-MKT-004 | 消费者补贴与消费券是否为同一资金来源 | 财务 |
营销与会员模块待确认项（摘自主文件 [10.2.11](../Continental-Retail-APP-PRD.md#10211-业绩营销福利兑换prf--mkt--msp)，4 条）
**本次拆分新增 3 条**（回灌主文件时并入 10.2.11）：
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| **REQ-MKT-006** | **消费券额度机制** —— 消费券非门店自建，而是按扫码入库与补货率自动累积额度，实为与进货挂钩的厂商激励，主文件只字未提，详见[附-5](#附-5-本次拆分新增发现待业务确认) | 业务 / 财务 |
| **REQ-MKT-007** | **会员权益的触发位置** —— 主文件写「开单 → 选权益」，现状是首页独立入口且与开单完全解耦，两者是不同的业务动作 | 产品 / 业务 |
| **REQ-MKT-008** | **会员体系开通流程与协议留痕** —— 门店自助开通、承诺服务能力、签署第三份协议并联动服务项管理；且 REQ-MKT-004「未开通则隐藏入口」必须细化 | 产品 |
合计 7 条待确认（原 4 条 + 新增 3 条）。回灌时需同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 MKT 行（5 / 4 / 20% → 8 / 7 / 13%）与第 10.2 节总数。
> 末行的编号错位见 [4.13.4](#4134-业务规则) 的说明：该问题实际属 REQ-MKT-005。
>
> 另有一条跨模块待确认与本模块相关：主文件第 10 章 **C11「O2O 独有功能无归属」**（平安账号 / 服务项报名 / 门店海报 / 服务结算单 / 会员权益 / 经营范围 / 协议中心）标了 `TODO(REQ-MKT-*)`，其中**门店海报**与**会员权益**已在本模块成文，**协议中心**归 [4.9 门店管理](./09-STM-门店管理.md)，**服务项报名**与本模块的会员体系开通存在联动（开通会员体系会同步开通服务项），需一并梳理。
### 附-4 配图清单（主文件附录 C 4.13 节）
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 现状-O2O 优惠券（消费券）：**额度看板 + 补货率 + 可发放券条目**，额度按扫码入库累积；券名为测试数据 | `../mini-program-images/O2O/优惠券-消费券.png` |
| 2 | 现状-O2O 优惠券（门店营销券）：门店自建入口 + 按月发放统计；**列表空态** | `../mini-program-images/O2O/优惠券-门店营销券.png` |
| 3 | 现状-O2O 选择营销券：**完全空态**，无任何控件 | `../mini-program-images/O2O/选择营销券-空态.png` |
| 4 | 现状-O2O 会员权益弹窗：**手机号 + 权益勾选 + 确认提交**，从首页宫格唤起，与开单无关 | `../mini-program-images/O2O/会员权益弹窗.png` |
| 5 | 现状-O2O 会员权益弹窗（已选权益）：「免费查车」选中态 | `../mini-program-images/O2O/会员权益弹窗-已选权益.png` |
| 6 | 现状-O2O 会员体系门店（未开通）：8 项服务承诺 + 协议勾选 + 自助开通按钮；**含 3 条测试服务项** | `../mini-program-images/O2O/会员体系门店-未开通.png` |
| 7 | 现状-O2O 门店海报：门店小程序码 + 海报列表**空态**，**未见保存/分享控件** | `../mini-program-images/O2O/门店海报.png` |
营销与会员模块配图清单，7 张（全部为现状-O2O）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
> 7 张中有 **4 张是空态或含测试数据**（第 2、3、6、7 张），本模块的现状证据强度明显弱于其它模块。评审时不宜据此图集推断券与权益的真实字段结构，建议向业务索取一份**有真实数据**的门店账号截图。
### 附-5 本次拆分新增发现（待业务确认）
以下 3 条**不在主文件现有 5 条 MKT 需求内**，是本次逐张核看 7 张配图时发现的、现有需求未覆盖的事项。编号接 REQ-MKT-005 顺延，**尚未登记进主文件 10.2.11**，回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。
| 编号 | 待确认内容 | 证据 | 建议决策方 |
| --- | --- | --- | --- |
| REQ-MKT-006 | **消费券额度机制**：消费券并非门店自建，而是按「扫码入库」与「补货率」自动累积额度（页面明示「未满足规则，消费券额度不会增加，如有疑问请联系 SR」），门店只能在可用额度内「去发放」。这实质是**与进货表现挂钩的厂商激励**，主文件对此机制只字未提。需确认：①额度累积规则与考核周期（是否按月重置）；②「额度变更记录」与「详情」两个页面是否在 App 内承载；③「去发放」的目标对象是谁、发放后消费者如何领取；④额度是否随[门店切换](./02-HOM-APP首页与导航.md#426-业务规则)隔离。 | [4.13.1](#4131-优惠券) 图 1 | 业务 / 财务 |
| REQ-MKT-007 | **会员权益的触发位置**：主文件主流程写作「开单 → 选择会员权益 → 应用」，但现状是**首页宫格独立入口 → 输入会员微信绑定手机号 → 勾选权益 → 确认提交**，弹窗内无任何订单信息，与开单流程完全解耦。两者是不同的业务动作（订单折扣项 vs 到店服务核销）。需确认：①App 采用哪一种，还是两者都要；②权益是单选还是多选（本图只选中一项，无法确认）；③核销后是否生成单据、是否计入[经营业绩](./12-PRF-经营业绩与报表.md)；④会员手机号与[销售](./03-SAL-销售.md)侧的客户手机号是否同一份数据。 | [4.13.2](#4132-会员权益) 图 4、图 5 + 本节主流程 | 产品 / 业务 |
| REQ-MKT-008 | **会员体系开通流程与协议留痕**：开通是**门店自助**动作，前置条件是门店承诺具备一组非轮胎服务能力（标准洗车 / 蘑菇钉补胎 / 免费加玻璃水 / 免费查车 / 延保服务），并勾选签署《德国马牌门店非轮胎项目服务协议》，开通后联动「服务项管理」同步开通。需确认：①App 是否承载该开通流程，还是仅展示状态、开通引导至他处；②服务标签是静态承诺清单还是可逐项勾选；③提交后是否需上游审核；④该协议的签署留痕（版本号 + 时间戳）如何处理 —— 这是继[用户协议与隐私政策](./01-LGN-账号登录.md#412-业务规则)之外的第三份协议，且 O2O 另有「协议中心」入口；⑤**[REQ-MKT-004](#4134-业务规则)「未开通则隐藏相关入口」必须细化** —— 隐藏权益核销入口、保留开通申请入口，否则门店无法自助开通。 | [4.13.2](#4132-会员权益) 图 6 | 产品 / 业务 / 法务 |
本次拆分新增待确认项，3 条
> 另有三项**不需新增编号**的观察，已就地记在各图下方：①消费券与门店营销券的**资金来源不同**（厂商额度 vs 门店自负），直接影响 [REQ-MKT-002](#4134-业务规则) 的叠加规则裁决；②「选择营销券」页为空态，[验收标准第 2 条](#4135-验收标准)要求的「不可用原因」在现状中无从验证，属 App 新增要求；③「门店海报」页未见保存/分享控件，[REQ-MKT-003](#4134-业务规则) 需一并明确控件位置而非只定分享目标。
prd/modules/14-MSP-福利兑换.md
+124
View File
@@ -0,0 +1,124 @@
# 4.14 福利兑换（MSIP）
> **本文件是【福利兑换 MSP】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.14 节已于 2026-08 从本文件回灌（V1.1），
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**
| 项 | 值 |
| --- | --- |
| 模块码 | MSP |
| V1.0 章节 | 4.14 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状入口 + 设计稿 + 业务确认（页面待补） |
| 现状承载系统 | MSIP |
| 需求条数 | 8（待确认 4，完成度 50%） |
| 配图 | **0 张** —— 附录 C 无 4.14 节 |
**本模块是全 PRD 材料最少的一个**：至今没有任何 MSIP 的页面截图或设计稿，业务需求文档中也只在背景部分提过一次。已定的是业务目标与积分主体两条，其余四条全部待确认。这一状况已作为风险 R1 登记在[第 10 章](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
---
> **积分主体已定**：**积分挂在门店账下，不归属店员个人。** App 面向经销商，店长与技工都是门店的员工；积分是**品牌方发给经销商的福利**，因此切换门店时积分随门店上下文一起切换，同门店的店员看到同一份额度。这一条决定了本模块的权限模型与切店行为。
>
> 页面内容、积分产生规则与 MSIP 的集成方式**仍待补**，见 [4.14.1](#4141-业务规则)。
**业务目标** —— 品牌方以积分形式向经销商发放福利，门店用积分兑换商品或权益，作为对门店的激励手段
**入口** —— 现状：ROOS / O2O 首页的「积分兑换」（见 [2.7.2](../Continental-Retail-APP-PRD.md#272-roos-采购小程序)、[2.7.3](../Continental-Retail-APP-PRD.md#273-o2o-接单宝小程序)）；目标：宫格版「福利兑换」（见 [4.2.5](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）或[个人中心](./08-MIN-我的.md#481-目标形态)的积分资产卡
**页面内容** —— 待确认 `TODO(REQ-MSP-002)`
**主流程** —— 待确认 `TODO(REQ-MSP-002)`
**权限规则** —— 积分为**门店级**资产，同门店所有角色看到同一份余额；门店内谁可以发起兑换（是否限店长）待确认 `TODO(REQ-MSP-005)`
**数据来源** —— MSIP
### 4.14.1 业务规则
**REQ-MSP-001 业务目标** —— 已定：品牌方给经销商的福利激励，门店以积分兑换商品或权益
**REQ-MSP-002 页面内容与主流程** —— 兑换商品列表、兑换详情、兑换记录的具体形态待补 `TODO(REQ-MSP-002)`
**REQ-MSP-003 积分主体** —— 已定：**积分归属门店**，不归属店员个人。切换门店时积分随门店上下文切换（与门店切换的级联失效规则一致，见 [REQ-LGN-010](./01-LGN-账号登录.md#412-业务规则)）；同门店所有角色看到同一份额度
**REQ-MSP-004 集成方式** —— MSIP 是否提供 API，还是只能以 Embedded H5 嵌入待确认 `TODO(REQ-MSP-004)`。若只能嵌 H5，则与[提醒](./04-RMD-提醒.md#44-提醒)同为容器方案，[集成矩阵](../Continental-Retail-APP-PRD.md#72-集成矩阵)需相应调整
**REQ-MSP-005 兑换权限** —— 积分虽属门店，但门店内是否限店长发起兑换待确认 `TODO(REQ-MSP-005)`
**REQ-MSP-006 积分产生规则** —— 积分如何产生（订货 / 扫码入库 / 延保建单 / O2O 核销，或由品牌方后台直接发放）待确认 `TODO(REQ-MSP-006)`。这决定本模块与哪些业务模块联动，以及 App 内是否需要展示积分获取明细
> 以下 `REQ-MSP-007` ~ `REQ-MSP-008` 为 V1.1 补写。本模块无配图，两条均来自其它模块截图中的旁证与跨模块口径对齐，不涉及页面形态。
**REQ-MSP-007 现状入口清单与整合后的收敛** —— 「积分兑换」在现状**至少有三个入口**：ROOS 首页宫格、O2O 接单宝首页宫格、以及**延保小程序「其他小程序入口」四宫格中的「积分兑换」一格**（见 [4.5.7](./05-WTY-延保.md#457-培训操作指引与服务支持)的现状截图）。整合后三处**全部取消**，收敛为 App 内的单一「福利兑换」入口；积分余额在个人中心的资产卡与福利兑换页两处展示时，**必须同源同刷新时机**，不得出现两个数
**REQ-MSP-008 积分余额的口径与失效** —— ①积分余额随门店上下文切换而整体失效重取，不做跨门店缓存合并（依赖 [REQ-MSP-003](#4141-业务规则)）；②余额展示须带数据口径时间，若 MSIP 为 H5 嵌入则口径时间由 MSIP 页面自行承载；③兑换成功后余额须立即回刷，不得依赖用户手动下拉
---
## 附：本模块归拢信息（来自主文件其它章节）
### 附-1 业务数据字典（主文件附录 A）
**主文件附录 A 未收录本模块的字段清单** —— 附录 A 只有 A.1–A.9 九节，无福利兑换节。与本模块相关的只有第 5 章主数据表的一行：
| # | 类型 | 来源 | 同步方式 | 说明 |
| --- | --- | --- | --- | --- |
| 6 | 积分主数据 | MSIP | `TODO(REQ-MSP-004)` | 见 [4.14](#414-福利兑换msip) |
以及集成矩阵的一行：
| # | 系统 | 涉及模块 | 集成方式 | 数据 |
| --- | --- | --- | --- | --- |
| 7 | **MSIP** | 4.14 福利兑换 | `TODO(REQ-MSP-004)` | 积分、兑换 |
**回灌主文件时的处理建议**：在 `TODO(REQ-MSP-002)` 和 `TODO(REQ-MSP-004)` 各自澄清之前，**不为本模块编造字段清单**。待 MSIP 侧给出页面与接口后，附录 A 至少需补三组数据集：积分账户（门店维度余额、冻结、口径时间）、兑换商品目录、兑换记录（含状态机与物流/发放信息）。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **福利兑换** | 积分兑换 | ✅ | ❓ | 积分属**门店**，同店两角色看到同一份余额；能否发起兑换待定 `TODO(REQ-MSP-005)` |
**本次拆分建议新增的一行**（回灌主文件时一并处理）：
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **福利兑换** | 积分余额查看 | ✅ | ✅ | 余额是门店级资产，**查看与兑换应分开授权**：查看全角色开放，兑换权限按 `TODO(REQ-MSP-005)` 裁决 |
拆分理由：现状矩阵只有「积分兑换」一行且技工为 ❓，容易被实现成「技工连余额都看不到」。而 [REQ-MSP-003](#4141-业务规则) 明确「同门店所有角色看到同一份余额」——**看得到**是已定的，**能不能兑**才是待定的，两者必须拆成两行才不冲突。
### 附-3 待确认项（主文件 10.2.11 中的 MSP 分片）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-MSP-002 | 福利兑换的页面内容与主流程（兑换商品列表 / 详情 / 记录） | 产品 |
| REQ-MSP-004 | MSIP 是否提供 API，还是只能嵌入 H5 | 架构 |
| REQ-MSP-005 | 门店内是否限店长发起兑换 | 产品 |
| REQ-MSP-006 | 积分如何产生（订货 / 入库 / 延保建单 / 核销，或后台直接发放） | 业务 |
合计 4 条待确认，本次拆分**未新增、未关闭**。
> 主文件 10.2.11 是 PRF / MKT / MSP 三个模块合并的一节，上表只取 MSP 前缀的 4 行；另外 8 行分别归入 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)。三个模块的分片合计须等于主文件 10.2.11 的 12 行。
### 附-4 配图清单（主文件附录 C）
**本模块无配图** —— 主文件附录 C 无 4.14 节，磁盘上也没有任何 MSIP 相关截图。
**建议补充的材料**（按优先级）：
1. **MSIP 现状页面截图** —— 至少需要 兑换商品列表 / 兑换详情 / 兑换记录 / 积分余额与明细 四张，这是关闭 `TODO(REQ-MSP-002)` 的前提；
2. **积分获取路径的说明材料** —— 用于关闭 `TODO(REQ-MSP-006)`，决定本模块与采购 / 库存 / 延保 / 销售四个模块是否有联动；
3. **MSIP 的接口文档或 H5 地址** —— 用于关闭 `TODO(REQ-MSP-004)`。
补图后须同步更新三处：文档头部规模声明、附录 C 的来源分布表与本节清单、本文件头部信息表。
### 附-5 本次拆分新增发现
1. **本模块是 14 个模块里唯一没有任何页面材料的** —— 其余 13 个模块都有截图或设计稿可核对，本模块的 6 条需求全部来自业务口头确认。因此本次拆分**没有逐图核对环节**，新增的两条需求（[REQ-MSP-007](#4141-业务规则)、[REQ-MSP-008](#4141-业务规则)）都只涉及入口与口径，不涉及页面形态。
2. **发现了一个正文没记的现状入口** —— 除 ROOS 与 O2O 两处首页宫格外，**延保小程序的「其他小程序入口」四宫格里也有「积分兑换」一格**（见 [4.5.7](./05-WTY-延保.md#457-培训操作指引与服务支持)）。即现状共有**三个**入口，正文只写了两个。见 [REQ-MSP-007](#4141-业务规则)。
3. **附录 B 的单行写法会导致实现歧义** —— 「积分兑换」一行技工为 ❓，但 [REQ-MSP-003](#4141-业务规则) 已明确同店所有角色看到同一份余额。「查看」与「兑换」必须拆成两行，否则容易实现成技工连余额都看不到，与已定规则冲突。见「附-2」。
4. **`TODO(REQ-MSP-004)` 的影响面比 10.2.11 记录的更大** —— 它同时挂在三处：本模块的集成方式、[第 5 章主数据表](../Continental-Retail-APP-PRD.md#51-主数据来源)第 6 行的同步方式、[集成矩阵](../Continental-Retail-APP-PRD.md#72-集成矩阵)第 7 行。三处须一并更新，不能只改 4.14。
5. **积分兑换很可能涉及实物发放与物流** —— 「兑换商品」若是实物，则兑换记录须有收货地址、发货状态与物流单号，这会显著扩大本模块范围；若只兑权益（券、服务），范围小得多。这一点在 `TODO(REQ-MSP-002)` 澄清页面形态时须一并问清，否则排期估算会严重失真（正是风险 R1 所指）。
prd/modules/README.md
+151
View File
@@ -0,0 +1,151 @@
# PRD 模块需求文件
本目录把 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4 章的 14 个业务模块拆成独立文件，便于分模块维护、分模块评审、分模块指派负责人。
## ⚠️ 同步契约（必读）
| 项 | 约定 |
| --- | --- |
| **谁为准** | **本目录为准。** 需求变更一律改本目录的模块文件 |
| 主文件第 4 章 | **不要直接编辑，改动会在下次回灌时被覆盖。** 已于 2026-08 完成首次回灌，主文件升至 V1.1，与本目录一致 |
| 主文件其余章节 | 第 1–3、5–10 章与附录 A/B/C/D 仍以主文件为准，本目录只做**只读引用** |
| 回灌方式 | 跑 `scripts/build_prd.py backfill`（先 `--dry-run` 看差异）。范围仅限各模块文件 `## 附：本模块归拢信息` 分界线**以上**的部分，分界线以下不回灌 |
| 回灌时机 | 需要出 Word / PDF 交付件时，或模块文件改完想让主文件跟上时。脚本是幂等的，多跑无害 |
| 派生数据 | 附录 D.2、头部规模声明、附录 C.3 首句、10.2 图例计数、各模块头部信息表的「需求条数」行——**这五处由脚本重算，不要手改** |
| 仍需手工维护 | **附录 A / B / C.2 与 10.2 的条目正文**。脚本只校验数目对不对（对不上会在 `verify` 里报出来），不替你写条目 |
| 编号规则 | 沿用主文件 1.7：`REQ-<模块码>-<3位序号>`，**一经分配不再复用**，删除时保留编号并标注「已废弃」 |
| 待确认标记 | 沿用 `TODO(REQ-xxx-nnn)`，**禁止使用 `tbd`** |
三条命令，都用仓库根目录的 `.venv`（自带 pandoc 与 Pillow，系统 Python 跑不了）：
```bash
.venv/Scripts/python.exe scripts/build_prd.py verify # 只校验，不改文件
.venv/Scripts/python.exe scripts/build_prd.py backfill --dry-run # 看回灌会改什么
.venv/Scripts/python.exe scripts/build_prd.py backfill # 回灌，末尾自动跑 verify
.venv/Scripts/python.exe scripts/build_prd.py export # 压缩配图 + 出 docx
```
`export` 做两件事：把 `prd/` 下三个图源目录的 PNG **就地**调色板量化（首次跑：**23.4 MB → 9.7 MB**；已量化的跳过，日后新加的截图会自动压掉，免得仓库又长胖），再用 pandoc 生成 `prd/Continental-Retail-APP-PRD.docx`（约 9.8 MB，含全部 173 张图与三级目录）。**PDF 不由脚本生成**——pandoc 转 PDF 要 LaTeX，本机没装，用 Word 打开 docx 另存。
> 量化是有损的（256 色）。这批截图是扁平 UI 图，实测中位 RMS 误差 0.82/255、最差一张 3.10（延保「扫描车牌」，取景框里有实拍照片），文字与控件肉眼无差别。**原图都在 git 历史里**，要取回某张跑 `git checkout <commit> -- prd/xxx.png`。
版式模板是 `scripts/reference.docx`，首次 `export` 时自动生成（pandoc 默认模板 + 把东亚字体钉成标题「微软雅黑」/ 正文「等线」，否则换台机器 Word 会自挑中文字体）。**已存在就原样使用**，在 Word 里改过的版式不会被脚本覆盖；想重置就删掉它再跑一次。
> 主文件与本目录并存，漂移风险真实存在。降低漂移的唯一手段是：**只在本目录改需求**，主文件第 4 章当只读产物看待。
## 模块索引
「需求 / 待确认」两列是**本目录各模块文件的现值**；括号内是逐图核对前的 2026-08 基线，两者的差额就是核图时新增的条目。**主文件[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 与[第 10.2 节](../Continental-Retail-APP-PRD.md#102-待确认项清单)已按括号外的现值同步**，下次改需求后须再同步一次。
| 序 | 文件 | 章节 | 模块码 | 粒度 | 需求 | 待确认 | 完成度 | 图 | 现状承载系统 |
| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- |
| 01 | [账号登录](./01-LGN-账号登录.md) | 4.1 | LGN | 14 维 | 11 | 7 | 36% | 1 | O2O（用户主数据） |
| 02 | [APP 首页与导航](./02-HOM-APP首页与导航.md) | 4.2 | HOM | 14 维 | 16（15） | 11（10） | 31% | 5 | ROOS / O2O / 延保 |
| 03 | [销售](./03-SAL-销售.md) | 4.3 | SAL | 14 维 | 37（14） | 11（6） | 70% | 28 | F6 + O2O |
| 04 | [提醒](./04-RMD-提醒.md) | 4.4 | RMD | 14 维 | 7 | 2 | 71% | 3 | F6（PC 端，App 内嵌 H5） |
| 05 | [延保](./05-WTY-延保.md) | 4.5 | WTY | 14 维 | 38（10） | 6（5） | 84% | 43 | 延保门店端 |
| 06 | [采购](./06-PUR-采购.md) | 4.6 | PUR | 14 维 | 18（13） | 12（7） | 33% | 9 | ROOS（马牌）+ F6（非马牌） |
| 07 | [库存](./07-INV-库存.md) | 4.7 | INV | 6 维 | 11（7） | 9（5） | 18% | 12 | O2O + ROOS |
| 08 | [我的 / 个人中心](./08-MIN-我的.md) | 4.8 | MIN | 6 维 | 20（6） | 13（6） | 35% | 16 | ROOS + O2O + 延保 |
| 09 | [门店管理](./09-STM-门店管理.md) | 4.9 | STM | 6 维 | 14（7） | 13（6） | 7% | 14 | O2O |
| 10 | [财务与对账](./10-FIN-财务与对账.md) | 4.10 | FIN | 6 维 | 14（7） | 12（5） | 14% | 11 | O2O + ROOS |
| 11 | [返利中心](./11-RBT-返利中心.md) | 4.11 | RBT | 6 维 | 11（6） | 7（3） | 36% | 10 | O2O + 延保 |
| 12 | [经营业绩与报表](./12-PRF-经营业绩与报表.md) | 4.12 | PRF | 6 维 | 9（6） | 7（4） | 22% | 8 | O2O + ROOS + 延保 |
| 13 | [营销与会员](./13-MKT-营销与会员.md) | 4.13 | MKT | 6 维 | 8（5） | 7（4） | 13% | 7 | O2O |
| 14 | [福利兑换（MSIP）](./14-MSP-福利兑换.md) | 4.14 | MSP | 6 维 | 8（6） | 4 | 50% | 0 | MSIP |
| | **合计** | | | | **222**（121） | **121**（74） | **46%** | **167** | |
模块索引。完成度 =（需求条数 − 待确认）÷ 需求条数。
> **括号内的 D.2 基线曾有一处错**：STM 行原记「需求条数 8」，但当时 4.9 正文只有 REQ-STM-001~007 共 7 条且无空号，上表括号内按实际的 7 记（故基线合计 121 实为 120）。根因是 V1.0 的 STM-006/007 挂错了 TODO 编号，已在回灌时连同 FIN、MKT 的同类错位一并修正，主文件 10.2 各行标注了原编号以便追溯。详见 [09-STM 的附-5](./09-STM-门店管理.md#附-5-本次拆分新增发现)。
>
> 逐图核对把需求条数从 121 提到 222（+101）、待确认从 74 提到 121（+47 净增：新增 49 条、裁决关闭 2 条）。**增量全部来自逐张核看 167 张配图**：现状截图里实际存在、而 2026-08 版正文一字未提的机制（如门店本地化服务项目价目表、消费券额度按补货率累积、延保生效的两段式确认、扫码出库的「去延保」分支），以及设计稿与现状互相冲突、必须裁决的口径。各模块文件的 `附-5` 逐条列明了触发证据。
**需求依据**（主文件 4.0 模块总览）：LGN 业务需求 + 设计稿；HOM 业务需求 + 设计稿 3 版；SAL 业务需求 + 原型图 + O2O 订单截图；RMD 业务需求 + 原型图；WTY 业务需求 + 延保小程序 44 张截图；PUR 业务需求 + ROOS 截图 + 设计稿；INV / FIN / RBT / PRF / MKT 现状截图反推；MIN / STM 业务需求 + 现状截图 + 设计稿；MSP 现状入口 + 设计稿 + 业务确认（页面待补）。
> 第 4 章共 173 张图中的 167 张归属这 14 个模块；其余 6 张分布在主文件 2.7 现状小程序功能全景（4 张）与 6.1 / 6.2 后台管理（2 张），不在本目录范围内。
## 模块文件结构
每个文件以 `## 附：本模块归拢信息` 为分界线：
- **分界线以上** —— 1:1 对应主文件 4.x 正文，保留原有小节编号（如 `4.7.1`）。回灌主文件时只处理这部分。
- **分界线以下** —— 从主文件其它章节归拢来的本模块分片：业务数据字典（附录 A）、权限矩阵（附录 B）、待确认项（10.2）、配图清单（附录 C）。这部分**不回灌**，主文件的附录仍是全局视图。
> **文件标题必须与主文件 4.x 标题逐字一致**（如 `# 4.9 门店管理`，**不要**加模块码写成 `# 4.9 门店管理（STM）`）。两个原因：一是回灌时只需把 `#` 降为 `##`，不改标题文字；二是主文件附录 C 用 `[4.9 门店管理](#49-门店管理)` 这类锚点自引，各模块之间的互链也复用同一套 slug —— 标题一改，**上百条链接同时静默失效**。模块码写在下方信息表的「模块码」行和文件名里，标题里不重复。
## 配图说明规范（四段式）
每张图正下方接四段，段名加粗 + 破折号，与主文件 1.8.1 的写法一致：
```markdown
![现状-O2O 扫码入库](../mini-program-images/O2O/扫码入库.png)
**页面内容** —— 一句话：这是什么页、有哪些主要区块
**关键交互** —— ①控件 → 结果 ②控件 → 结果
**可用角色** —— 店长 …；技工 …
**需求关联** —— REQ-xxx-nnn、REQ-xxx-nnn
```
硬性规则：
1. **页面内容只写一句话**，说清「这是什么页 + 有哪些主要区块」即可，**不逐个控件描述文案、颜色、位置**。一句写不下的，说明细节该放到别处：交互过程写进「关键交互」，结论与推断写进图下的 `>` 引用块，冗长的取值清单与脏数据明细写进 `附-5` 的证据列 —— **不在图下重复**。
2. **写之前必须实际打开该 PNG**，不得据文件名臆造。空态、测试数据、已选中的筛选值属于会误导读者的关键信息，须用一句点明（如「**本图为空态**，记录行字段无法确认」）。看不清或无法判断的写「本图无法确认 xxx」，**不猜**。
3. **关键交互**用 ①②③ 编号，每条写成「控件 → 结果」。纯静态展示图写「无交互，仅作内容佐证」。
4. **可用角色**沿用主文件附录 B 图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认。有待确认的就地带 `TODO(REQ-xxx-nnn)`。
5. **需求关联**列 REQ 编号并锚到本文件的业务规则小节；不支撑任何编号需求的写「—（仅作现状佐证）」。
6. 图片一律用**相对路径**引用，从本目录出发要多一层 `../`：`../app-design-images/`、`../mini-program-images/{O2O,ROOS,Warranty}/`、`../images/`。
## 链接写法
| 目标 | 写法 |
| --- | --- |
| 本模块内小节 | `[4.7.4](#474-业务规则)` |
| 其它模块整节 | `[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)` |
| 其它模块内小节 | `[4.2.5](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)` |
| 主文件其它章节 / 附录 | `[痛点 2.3](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)` |
锚点按 GitHub 规则从标题生成：转小写、去掉标点（含中文全角 `（）、，`）、空格换 `-`。所以 `## 4.14 福利兑换（MSIP）` 的锚点是 `#414-福利兑换msip`，`## 2.3 进销存 / ERP 数据` 的是 `#23-进销存--erp-数据`（`/` 被删除后留下两个空格，成为双连字符）。**写完链接要点开验证**——锚点错了不会报错，只是不跳转。
主文件本身仍须满足 CLAUDE.md 的「自包含、只用锚点、不引用其它 md」约束；本目录是仓库内部工作副本，不受该约束限制。
## 状态与待办
**14 个模块文件已全部建成**，167 张配图逐张核看后写了四段式说明，主文件 10.2 与附录 A/B/C 的本模块分片已归拢到各文件的 `附-1` ~ `附-4`，逐图核对中新增的需求与待确认项记在各文件的 `附-5`。**2026-08 已完成首次回灌**，主文件升至 V1.1。
拆分完成后跑过的一致性核对（结果均为通过）：
| 核对项 | 结果 |
| --- | --- |
| 图片路径可解析 | 167 处引用，磁盘缺失 **0** |
| 图不丢 | 主文件第 4 章 167 张 ∩ 本目录 167 张，双向差集**均为空** |
| 每张图都有说明 | 缺四段式说明的图 **0**（拆分前的基线是 173 张里 94 张裸图） |
| REQ 不丢不重 | 主文件第 4 章 121 个编号，每个**恰好**归属一个模块文件；本目录现有 222 个 |
| 待确认项 | 主文件 10.2 共 97 条 = 第 4 章 74 条 + 章外 23 条；74 条**全部**落到对应模块的 `附-3`，本目录现为 121 条 |
| 链接可达 | 全仓 md 共 1784 条带锚点/跨文件链接，失效 **0** |
> 最后一项曾一次性失效 139 条：模块文件的一级标题当初写成了 `# 4.9 门店管理（STM）`，多出的模块码改变了 slug，而上百条互链是按主文件的 `## 4.9 门店管理` 生成的。已把 14 个 H1 全部对齐主文件标题，另修正 `#d2-模块覆盖度`→`#d2-模块级追溯汇总`（主文件实为「D.2 模块级追溯汇总」）等 10 处失效目标。规则见上文[模块文件结构](#模块文件结构)与[链接写法](#链接写法)。
回灌后在**主文件一侧**另跑过一轮（结果均为通过）：
| 核对项 | 结果 |
| --- | --- |
| 图片路径可解析 | 173 处引用，磁盘缺失 **0** |
| 站内锚点 | 1289 条，失效 **0**；正文无跨文件链接（满足 CLAUDE.md 的自包含约束，`modules/` 的指引只写在 HTML 注释里） |
| REQ 编号 | 全文 296 个不同编号，正文重复定义 **0** |
| TODO ↔ 10.2 | 正文 146 个 `TODO(...)` 与 10.2 的 144 条 + 2 条已关闭**双向对齐**，无孤儿 |
| 计数三处联动 | 头部规模声明 / 附录 C / 附录 D.2 / 10.2 均为 296 需求、144 待确认、173 图、44 表；D.2 逐行累加与合计行一致，各行完成度按公式复算无误 |
| `tbd` | 全文 **0**（唯一一处出现在 1.8 的「本文档不使用 `tbd`」这句禁令本身） |
待办：
- [x] **回灌主文件**（2026-08 完成）—— 需求条数 121 → 222、待确认 74 → 121（全文 97 → 144、296 条需求），主文件的规模声明、附录 B / C / D.2 与第 10.2 节已同步，第 4 章开头加了指向本目录的 HTML 横幅
- [x] **构建脚本 [`scripts/build_prd.py`](../../scripts/build_prd.py)**（2026-08 完成）—— `backfill` / `verify` / `export` 三个子命令，见上文[同步契约](#-同步契约必读)。首次机器回灌顺带修好了主文件里 10 处被早前一次编辑误删字符的句子（模块文件留着完好原文）
- [x] **`prd-export/` 已删除**（2026-08）—— 那是一整套与 `prd/` 一模一样的图片副本，仓库白背 31 MB。改成配图就地量化，docx 直接出到 `prd/Continental-Retail-APP-PRD.docx`
- [ ] **PDF 待重出**：原 `prd-export/Continental-Retail-APP-PRD.pdf` 是 2026-08-21 的 V1.0 版，内容已过时，已随目录删除。脚本不生成 PDF，须用 Word 打开新 docx 另存到 `prd/Continental-Retail-APP-PRD.pdf`
- [ ] 主文件附录 A 缺 INV / RBT / MKT / MSP 四个模块的字段清单，需业务补（已记为 `TODO(REQ-INV-011)` 等，见各文件 `附-1`）
- [ ] 补采两张截图：延保「待补充装车视频」tab（附录 C 第 6、7 行指向的两个文件截图像素一致，该 tab 实际未拍到）、O2O「交易手续费说明」的抖音团购段（被底部按钮遮挡）
- [ ] 人工抽查：用 VS Code 的 Markdown 预览打开任一模块文件，确认图片经 `../` 正常渲染、四段式说明与图上所见一致（路径已机器校验，渲染效果需肉眼确认）