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/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 能力清单不新增通讯录读取。