Files

T

Guangfei.Zhao d43d33c3cd Add initial reference document in Word format with structured headings and content

2026-08-24 18:46:37 +08:00

503 KiB

Raw Permalink Blame History

Continental Retail APP 产品需求文档（PRD）

项目	内容
文档名称	Continental Retail APP 产品需求文档
文档版本	V1.1
编制时间	2026 年 08 月（V1.1 修订于 2026-08）
文档状态	评审中
编制依据	零售 APP 方案 PPT、Workshop、研讨会议记录；现状小程序实测截图；APP 视觉设计稿
适用产品	移动端 Retail APP（Android / iOS）、Web 端后台管理控制台
主技术路线	Flutter（详见《App 工程结构与分包架构文档》）
后端技术栈	Kotlin 2.4 + Spring Boot 4.1 + Java 21 + MySQL 8.4 + Azure

修订历史

版本	日期	修订人	修订说明
V0.9	2026-07	业务侧	初版需求分析文档
V1.0	2026-08	—	完整版产品需求文档
V1.1	2026-08	—	逐张核看第 4 章 167 张配图，为每张图补写「页面内容 / 关键交互 / 可用角色 / 需求关联」四段式说明；据此补录 V1.0 未记的机制与口径冲突，第 4 章需求由 121 条增至 222 条、待确认由 74 条增至 121 条；同步更新 10.2、附录 B / C / D 与本表上方的规模声明

本文档规模：19 个模块、296 条编号需求（其中 144 条待业务确认）、173 张图、44 张正文表格。需求描述与编号需求均以文本书写，表格只用于字段清单、矩阵与统计。第 4 章的 167 张图每张均配有四段式说明。全部图片引用与章节内链已校验通过。

1 引言

1.1 文档目的

本文档为马牌统一零售 Retail APP 完整需求分析文档，用于明确业务现状、全部用户诉求、功能 / 非功能、集成、接口类需求；作为产品设计、开发、测试、验收、项目交付的唯一基准文件，供业务、IT、开发、测试、门店经销商评审使用。

凡本文档中标注「现状实测」的内容，来源为小程序真机截图；标注「设计稿」的内容，来源为 APP 视觉设计稿；两者均为需求佐证，不等同于已确认的需求结论——需要业务确认的部分统一以 TODO(REQ-xxx-nnn) 标记，并汇总于第 10 章。

1.2 项目背景

当前全国马牌线下门店运营依赖 6 套以上独立微信小程序：ROOS 采购、O2O 接单宝、延保小程序、马上下单门店管理、RMS 车型匹配、MSIP 福利兑换，另有第三方 F6 汽修系统。各系统账号独立、数据孤岛、流程割裂，门店店长 / 技工需要反复切换登录、手工同步库存 / 订单 / 财务数据，经营数据无法统一查看，门店数字化管理效率极低。

现计划建设一套统一移动端 Retail APP，整合全部小程序能力，打通集团 ERP 与 F6 汽修系统，实现门店全业务一站式数字化管理。

1.3 项目目标

统一账号体系，一套账号通行全部业务系统，分级管控门店人员权限；
打通集团 ERP，采购、销售、库存、财务数据自动双向同步，消除手工录入；
整合采购、销售、施工、延保、财务、数据分析全业务流程；
扩充多支付渠道，优化对账、返利、员工业绩核算流程；
首页聚合营销活动、待办、风险预警，提升门店转化与风险管控能力；
采用 Azure 云原生架构，支撑全国数千门店大规模并发，支持业务长期扩展。

1.4 终端用户

本 APP 的终端用户为马牌轮胎门店店长、技工两类角色。

本文档的角色模型仅包含这两类。更细粒度的角色（如财务专员、区域经理、总部运营）为后续扩展方向，不在首版范围内，见 C6。

1.5 文档适用范围

适用产品：移动端 Retail APP、Web 端后台管理控制台；
适用角色：产品、架构、前后端开发、测试、运维、门店经销商、大陆业务管理人员；
适用阶段：需求评审、概要设计、详细设计、开发、UAT 验收、上线运维。

1.6 术语与缩写定义

缩写	全称	说明
Retail APP	Continental 零售门店统一 APP	本次新建移动端主应用
ROOS	马牌采购进销存小程序	轮胎线上采购、出入库、返利数据源；底部导航「首页 / 商品 / 购物车 / 我的」。建于 F6 后台之上，由马牌自建以管理并统计各门店对自有品牌的采购
O2O 接单宝	线上订单核销、门店收款小程序	线上到店订单、对账提现数据源；单页结构，无底部导航
延保门店端	延保业务门店侧小程序	保单建单、理赔、售后鉴定、延保返利数据源；底部导航「首页 / 工作台 / 待办事项 / 我的」
马上下单	门店主数据与订单后台	零售主数据（门店列表）来源
F6	第三方汽修管理系统	车辆 VIN 识别、轮胎检测、工单施工、会员营销（提醒规则）
RMS	车型匹配系统	车型与轮胎规格匹配能力；首版范围待确认，见 C10
MSIP	福利兑换 / 积分兑换平台	ROOS 与 O2O 首页的「积分兑换」入口指向该平台
CDMS	经销商管理系统	采购单支付提醒来源；与 ROOS 的职责边界待确认，见 C7
SAP	集团 ERP 系统	产品主数据（Tire price catalog）来源
零售管理	零售业务管理端	ROOS / O2O 首页的互跳入口之一；范围待确认，见 C10
ERP	企业资源计划系统	集团库存、订单、财务主数据系统
CATI	认证轮胎技术检测中心（Certified Tire Technical Inspection）	延保理赔中与「延保理赔」「售后鉴定」并列的独立理赔通道
DOT	轮胎生产批次代码（Department of Transportation code）	售后鉴定必采字段，含生产周次信息
SFTP	安全文件传输协议	SAP price catalog 的文件传输通道
CSO	客户服务订单系统（Customer Service Order）	其数据同步至马上下单
SKU	最小库存单位	商品/库存的唯一标识
核销码	线上订单到店核销凭证	消费者出示，门店扫码或输码核销
UAT	用户验收测试	门店真实人员参与业务验收
VNet	Azure 虚拟网络	生产 / 测试环境网络隔离
WAF	Web 应用防火墙	外网流量安全防护
IAM	身份访问管理	统一账号权限体系
JSBridge	H5 与原生的通信桥	Embedded H5 调用原生能力的通道，共 13 行 / 15 个 `method`，见 7.3 与《App Embedded H5 容器与 JSBridge 文档》

术语与缩写定义

1.7 需求编号规则

本文档所有需求条目采用 REQ-<模块码>-<3位序号> 编号，编号一经分配不再复用；需求删除时保留编号并标注「已废弃」。

模块码	模块	章节
LGN	账号登录	4.1
HOM	APP 首页与导航	4.2
SAL	销售	4.3
RMD	提醒	4.4
WTY	延保	4.5
PUR	采购	4.6
INV	库存	4.7
MIN	我的 / 个人中心	4.8
STM	门店管理	4.9
FIN	财务与对账	4.10
RBT	返利中心	4.11
PRF	经营业绩与报表	4.12
MKT	营销与会员	4.13
MSP	福利兑换（MSIP）	4.14
MDM	主数据	5
ADM	后台管理	6
INT	系统集成	7
NFR	非功能需求	8
ACC	验收与追溯	9、附录 D

需求模块码

1.8 文档编写约定

1.8.1 需求描述模板

本文档按模块重要度分两级描述。

完整模板（14 维） —— 适用于核心模块（4.1 账号登录、4.2 APP 首页、4.3 销售、4.4 提醒、4.5 延保、4.6 采购）：

维度	说明
业务目标	该模块要解决的业务问题
目标角色	店长 / 技工
入口	用户从哪里进入该功能
前置条件	进入前必须满足的状态
页面内容	页面上呈现的信息与控件
主流程	正常路径的步骤序列
异常流程	失败、超时、无权限、无数据等分支
业务规则	计算口径、约束、校验规则
权限规则	角色可见性与可操作性差异
访问链路	App → 后端 → 外围系统的调用路径
逻辑数据来源	数据取自哪个系统
回写目标	数据写回哪个系统
状态变化	单据/对象的状态流转
验收标准	可测试的判定条件

精简模板（6 维） —— 适用于其余模块（4.7–4.14）：业务目标 / 入口 / 页面内容 / 主流程 / 权限规则 / 数据来源。

书写形式：需求一律用文本描述，不用表格。 上表只是维度的定义清单，正文里每个维度写成一个自然段，维度名加粗置于段首，后接破折号与内容：

**业务目标** —— 用一套账号替代 6 套小程序各自的登录，消除重复登录……

**目标角色** —— 店长、技工

三个维度例外，写成列表而非段落，因为它们天然是多条并列项：页面内容（逐条列控件与信息）、主流程（有序列表，一步一行）、异常流程（每行一个「触发条件 → 处理方式」）。状态变化、访问链路涉及多个对象或多条链路时同样用列表，每行一条。

编号需求同理，写成 **REQ-xxx-nnn 需求名** —— 规则内容 的段落；需求下挂的提示或待确认说明另起一段，用 > 引用块承接，以免与下一条需求混淆。

之所以不用表格：需求正文长短差异大，塞进单元格后要靠 <br> 硬断行，Word 导出时列宽被迫压缩、长条目难以阅读；改成文本后段落可自由折行，编号仍在行首便于检索。表格只保留给字段清单、矩阵、对照与统计这类真正的二维数据。

1.8.2 图表约定

本文档为独立交付件，不引用其他文档的编号，全部结论就地写明；
插图直接嵌在所属小节内，正文以「本节设计稿」「现状截图」等方式称呼，不使用图号；
需求描述与编号需求用文本，不用表格，写法见 1.8.1；表格只用于字段清单、矩阵、对照与统计；
表格下方以一行文字说明其内容，不使用表号；
全部 173 张插图的清单见附录 C 图表清单，可用于核对导出后的配图完整性；同附录的表格清单收录正文中的实质性表格，附录内部的清单表不重复登记。

1.8.3 图片来源标注

标注	来源目录	含义
设计稿	`app-design-images/`	APP 目标形态视觉稿，15 张
现状-ROOS / 现状-O2O / 现状-延保	`mini-program-images/`	现状小程序真机截图，142 张
原型	`./images/`	业务流程原型图，16 张（F6 页面、提醒、后台管理，其余目录未覆盖）

1.8.4 待确认标记

正文中一切未经业务确认的内容以 TODO(REQ-xxx-nnn) 标记，并在第 10 章登记。本文档不使用 tbd，一切未定事项均有编号。

2 现状痛点分析

2.1 多小程序分散

门店人员切换采购、接单、延保等小程序需重复输入账号密码，登录繁琐；
各系统入口分散，店长需要多平台切换查看订单、库存、延保保单；
各小程序消息、待办独立，无统一提醒看板，容易遗漏订单、保单待办。

现状实证：ROOS 与 O2O 接单宝的首页各自挂着「订货平台 / O2O、延保门店端、积分兑换、零售管理」四个互跳入口——即小程序之间已经在用「首页放友链」的方式互相打补丁，恰好反证了入口分散的问题（见 2.7.2、2.7.3）。

2.2 账号权限管控

门店员工账号无统一后台审核机制，随意注册，人员离职无法快速回收权限；
无精细化角色区分，技工可查看门店财务数据，存在经营数据泄露风险；
多门店店长无法一键切换店铺，跨门店管理操作复杂。

现状实证：三套小程序各自实现了自己的「切换店铺」（ROOS 我的、O2O 选择店铺、延保工作台-选择店铺），店长在一天内可能要切三次同一家店。

2.3 进销存 & ERP 数据

小程序与集团 ERP 无自动同步，采购订单、销售工单、出入库数据需要手工二次录入；
库存数据分散，无法实时统一查看全门店轮胎、配件库存；
缺货、滞销无统一预警，门店补货全凭人工经验，库存周转效率低。

2.4 支付与营销

原有系统仅支持微信支付，缺少支付宝、对公转账、账期支付渠道；
促销活动入口隐蔽，无首页专属营销专区，曝光量不足；
客户分层营销能力缺失，无法根据车龄、生命周期精准推送活动优惠券。

2.5 数据经营分析

采购、营收、毛利、延保、返利数据分散在多系统，无统一可视化看板；
返利核算、员工业绩提成需要线下手工计算，效率低易出错。

现状实证：经营业绩至少有三个互不相通的口径——ROOS「业绩详情」（签约量/订货量/扫码入库量/O2O售出量）、O2O「经营业绩」（1.0/2.0/引流转化三套指标）、延保「工作台」（延保数量与返利简报）。返利同理，O2O 返利中心与延保返利中心是两套独立数据。

2.6 售后延保

延保登记需要在单独小程序操作，无法和门店施工工单联动；
F6 汽修开单后无法一键跳转延保办理，需要重复录入车辆、轮胎信息；
保单、理赔数据在不同平台，查询、跟进流程复杂。

2.7 现状小程序功能全景

本节把「多小程序分散」从定性描述展开为可核对的功能清单，同时作为第 4 章各模块「迁移来源」的索引。内容全部来自现状小程序真机截图。

2.7.1 现状导航结构

小程序	底部导航	结构特征
ROOS 采购	首页 / 商品 / 购物车 / 我的	标准电商四段式
O2O 接单宝	无底部导航	单页长滚动 + 顶部工具条，全部功能以宫格铺开
延保门店端	首页 / 工作台 / [中键] / 待办事项 / 我的	深色主题，五段式带中央凸起键

现状小程序底部导航（截图实测）

三套导航互不兼容：段数不同（4 / 0 / 5）、主题不同（浅色 / 橙色 / 深色）、同名 tab 含义也不同（ROOS「我的」是采购账务中心，延保「我的」是账号设置页）。这是整合后必须收敛为一套 App 导航的直接原因，收敛方案见 4.2.5。

2.7.2 ROOS 采购小程序

首页构成：品牌 banner → 公告栏（暂无公告 >）→ 扫码出库 / 扫码入库 → 互跳宫格「O2O / 延保门店端 / 积分兑换 / 零售管理」。

功能域	页面	迁移目标章节
首页	首页、公告列表-空态、首页-扫码出库操作选择弹窗	4.2、4.7
商品与下单	商品选择、购物车、订单确认、订单确认-额度不足提示	4.6
订单	我的订单-全部、我的订单-待支付、售后退款	4.6
我的	我的、我的账户、我的优惠券-待使用、收货地址、支付优先级设置、商品收藏列表、我的-跳转账户管理小程序弹窗	4.8
库存	条码库存-入库记录	4.7
财务	对账单详情-采购对账单	4.10
业绩	业绩详情	4.12

ROOS 小程序功能清单（20 张截图）

2.7.3 O2O 接单宝小程序

首页构成（自上而下）：核销码输入框 + 核销按钮 → 工具条「核销历史 / 添加员工 / 消息 / 设置」→ 互跳宫格「订货平台 / 延保门店端 / 积分兑换 / 零售管理」→ 经营业绩卡（当月/当日/当周/当季，扫码入库总数、O2O 售出、马牌与维京性能指标含补货率）→ 订单管理（待接订单 74 / 调货中 2 / 待安装 26 / 待配送 1 / 配送中）→ 服务单（待安装 4 单）→ 宫格「平安账号 / 店铺管理 / 服务项报名 / 对账提现 / 经营业绩 / 返利中心 / 门店海报」→ 宫格「会员权益 / 经营范围 / 库存查询 / 协议中心 / 服务结算单 / 优惠券」→ 悬浮「联系客服」。

功能域	页面	迁移目标章节
核销与订单	订单列表-待接单/调货中/已完成/筛选、订单列表-接单货品状态选择、订单详情-待接单/待安装、订单备注、核销历史	4.3
服务单	服务单列表-全部/待安装/已安装/筛选、服务单列表-核销订单弹窗、服务单详情-待安装/已安装	4.3
库存	库存查询、库存查询-搜索类型选择、库存查询-筛选胎面宽/扁平比/直径/花纹、扫码入库、扫码入库-筛选品牌、扫码入库-自定义日期筛选	4.7
财务对账	对账提现、对账提现-交易手续费说明、提现历史、收入、收入详情、结算单明细、服务结算单、服务结算单-筛选结算渠道	4.10
返利	返利中心-返利详情/返利核算/安装费用调整情况/消费者补贴调整情况/抽奖红包返利说明/筛选品牌/筛选月份/筛选标签/筛选渠道	4.11
经营业绩	经营业绩-1.0经营业绩/2.0经营业绩/2.0引流转化/筛选品牌/筛选日期/筛选渠道	4.12
门店管理	店铺管理-基础信息/渠道信息/营业执照信息/2.0店铺信息、修改营业执照信息、修改营业执照信息-上传方式选择、经营范围与开票方式、经营范围详情、选择开票方式、银行账号-企业账户、银行账号-个人账户-解绑确认弹窗、单独服务项开通情况	4.9
营销与会员	优惠券-消费券、优惠券-门店营销券、选择营销券-空态、会员权益弹窗、会员权益弹窗-已选权益、会员体系门店-未开通、门店海报	4.13
协议	协议中心、小程序线下门店合作协议	4.9
个人与设置	设置、设置-确认登出弹窗、修改手机号、选择店铺、小程序在线客服、消息-门店违规提醒	4.8
延保关联	查看延保、认证轮胎技术检测中心CATI	4.5

O2O 接单宝小程序功能清单（78 张截图）

2.7.4 延保门店端小程序

功能域	页面	迁移目标章节
首页与建单	首页、首页切换店铺、扫描车牌、特殊车牌输入、待绑定车辆、待补充装车视频、待办事项	4.5.2
保单	所有保单、保单筛选、保单筛选日期、保单筛选品牌、保单子代码详情、保单详情-保单与活动信息、保单详情-延保信息、保单协议、德国马牌零售商延保使用条款须知	4.5.1、4.5.3
预约与理赔	全部预约-预约信息1/2、全部预约-预约信息详情、全部预约-提交的理赔信息、手动输入预约码、理赔处理、理赔-延保理赔、理赔-CATI理赔、理赔-售后鉴定	4.5.4
售后鉴定	售后鉴定、无用户信息鉴定通道1/2	4.5.5
工作台与数据	工作台、工作台-年、工作台-筛选品牌、工作台-选择店铺、数据分析1、数据分析2	4.5.6
返利	返利中心、返利中心-筛选品牌、返利详情、返利详细筛选日期	4.5.6、4.11
教程与账号	教程、教程视频、我的、我的-修改姓名、我的-切换店铺、其他小程序入口	4.5.7、4.8

延保门店端小程序功能清单（44 张截图）

2.8 痛点 → 需求映射

本节闭合「痛点提出」与「需求覆盖」。

痛点	对应需求章节	关键需求编号
2.1 多小程序分散	4.1 账号登录、4.2 APP 首页与导航	REQ-LGN-001、REQ-HOM-010
2.2 账号权限管控	4.1 账号登录、4.9 门店管理、6.3–6.4 后台账号与 RBAC	REQ-LGN-002、REQ-STM-004、REQ-ADM-003
2.3 进销存 & ERP 数据	4.6 采购、4.7 库存、5 主数据	REQ-PUR-001、REQ-INV-001
2.4 支付与营销	4.6 采购、4.13 营销与会员、4.2 首页促销位	REQ-PUR-006、REQ-MKT-001、REQ-HOM-004
2.5 数据经营分析	4.12 经营业绩与报表、4.11 返利中心	REQ-PRF-001、REQ-RBT-001
2.6 售后延保	4.5 延保、4.3 销售（结算后跳延保）	REQ-WTY-001、REQ-SAL-011

痛点与需求映射

3 利益相关者分析

3.1 终端用户（门店角色）

3.1.1 门店店长（核心管理用户）

诉求：一键登录，统一管理门店人员、采购库存、线上线下订单、财务对账、返利核算、销售机会、查看多维度经营数据、办理延保理赔、精准营销获客。

3.1.2 门店技工（一线操作用户）

诉求：快速扫码接车、轮胎检测、工单核销、简易延保登记、出入库扫码；无财务、人员管理权限，简化操作流程。

3.2 企业内部干系人

干系人	关注点
大陆零售业务部	统一管控全国门店运营、查看门店经营汇总数据
IT 架构团队	系统云架构设计、多系统集成、安全管控、运维落地
财务部门	门店对账、返利结算、营收数据统一校验
项目 PM / 产品	需求落地、项目进度管控、需求变更管理

企业内部干系人

3.3 外部对接系统厂商

厂商	提供能力
F6 汽修服务商	车辆检测、工单施工、结算页面（Embedded H5）与 API 接口；提醒规则配置（现状在 F6 PC 端）
云服务商 Azure	数据库、网络、监控、安全组件支撑
支付服务商	微信、支付宝、对公转账渠道对接
短信服务商	登录验证码、客户营销短信通道

外部对接系统厂商

注：扫码能力由 App 原生实现（native_scan），不依赖 F6 提供扫码页；F6 侧 H5 页面通过 JSBridge 调用原生扫码。见 C5 与《App 原生能力集成文档》、《App Embedded H5 容器与 JSBridge 文档》。

4 用户需求

本章按模块组织。4.1–4.6 为核心模块，采用完整 14 维模板；4.7–4.14 采用精简 6 维模板。

模块与来源对照见模块总览。

4.0 模块总览

章节	模块	模块码	粒度	需求依据	现状承载系统
4.1	账号登录	LGN	14 维	业务需求 + 设计稿	O2O（用户主数据）
4.2	APP 首页与导航	HOM	14 维	业务需求 + 设计稿 3 版	ROOS / O2O / 延保
4.3	销售	SAL	14 维	业务需求 + 原型图 + O2O 订单截图	F6 + O2O
4.4	提醒	RMD	14 维	业务需求 + 原型图	F6（PC 端，App 内嵌 H5 展示）
4.5	延保	WTY	14 维	业务需求 + 延保小程序 44 张截图	延保门店端
4.6	采购	PUR	14 维	业务需求 + ROOS 截图 + 设计稿	ROOS（马牌）+ F6（非马牌）
4.7	库存	INV	6 维	现状截图反推	O2O + ROOS
4.8	我的 / 个人中心	MIN	6 维	业务需求 + 现状截图 + 设计稿	ROOS + O2O + 延保
4.9	门店管理	STM	6 维	业务需求 + O2O 店铺管理截图 + 设计稿	O2O
4.10	财务与对账	FIN	6 维	现状截图反推	O2O + ROOS
4.11	返利中心	RBT	6 维	现状截图反推	O2O + 延保
4.12	经营业绩与报表	PRF	6 维	现状截图反推 + 设计稿	O2O + ROOS + 延保
4.13	营销与会员	MKT	6 维	现状截图反推	O2O
4.14	福利兑换（MSIP）	MSP	6 维	现状入口 + 设计稿 + 业务确认（页面待补）	MSIP

模块总览

4.1 账号登录

一套账号切换多家门店，账号统一管理、员工权限配置。

页面内容 —— App 登录页目标形态：深色轮胎背景 + 橙色徽标，中部为手机号 / 验证码登录区与「密码登录」「我要注册」两个次级入口，下方是第三方登录（微信、支付宝）与协议勾选行。

关键交互 —— ①输入手机号 → 点「获取验证码」，60 秒内不可重复获取（REQ-LGN-001）；②点「密码登录」→ 切换为用户名 + 密码模式；③点「我要注册」→ 进入注册流程（表单与审核流程未定 TODO(REQ-LGN-004)）；④点微信 / 支付宝 → 第三方授权，首次需绑定已有手机号账号（TODO(REQ-LGN-003) 是否纳入本期）；⑤点《用户协议》/《隐私政策》→ 查看全文；⑥勾选协议后「登录」方可提交。

可用角色 —— 店长 ✅、技工 ✅，登录环节两个角色完全一致；差异从登录成功后的角色化导航开始（见导航收敛与角色化配置）。第三方登录与注册两项对两个角色均为 ❓ TODO(REQ-LGN-003) / TODO(REQ-LGN-004)。

需求关联 —— REQ-LGN-001 验证码登录、REQ-LGN-002 密码登录、REQ-LGN-003 第三方登录、REQ-LGN-004 注册与审核、REQ-LGN-005 协议展示与留痕

本图与验收标准的两处对不上，需设计补稿（不新增需求，属设计稿状态缺失）：

稿中协议勾选框为未勾选态，而「登录」按钮画的是完整橙色实心（非置灰）。验收标准第 1 条要求未勾选时按钮为禁用态 —— 设计稿未画禁用态。

稿中未见「忘记密码」入口，而 REQ-LGN-006 规定忘记密码经手机号验证码重置。该入口可能在「密码登录」模式下才出现，但密码登录态的稿未提供，本图无法确认。

4.1.1 需求描述

业务目标 —— 用一套账号替代 6 套小程序各自的登录，消除重复登录；同时建立可审核、可回收的账号管控机制，解决痛点 2.2

目标角色 —— 店长、技工

入口 —— APP 冷启动且无有效会话；会话失效后的任意页面被动跳转

前置条件 —— 账号已在 O2O 接单宝后台存在并通过审核；设备可访问网络

页面内容：

品牌背景 + Continental Logo
手机号输入框
验证码输入框 + 「获取验证码」
「登录」主按钮
「密码登录」次按钮（切换到用户名 + 密码模式）
「我要注册」文字入口
第三方登录区（微信、支付宝）
底部协议勾选「已阅读并同意《用户协议》与《隐私政策》」

主流程：

输入手机号
获取验证码
输入验证码
勾选协议
点击登录
后端校验通过下发 access / refresh token
拉取该账号的门店列表与角色
单门店直接进入首页；多门店弹出门店选择
进入 APP 首页

异常流程：

手机号未注册 → 提示并引导「我要注册」
验证码错误 → 提示剩余可试次数
验证码超时 → 提示重新获取
未勾选协议 → 登录按钮不可用
账号被停用 → 提示联系门店管理员
账号无任何门店归属 → 阻断登录并提示
网络异常 → 保留已输入内容并允许重试

业务规则 —— 见 4.1.2

权限规则 —— 登录本身不区分角色；登录成功后由后端下发角色（店长 / 技工）与该角色的可见 tab 集合、功能权限，见导航收敛与角色化配置与附录 B

访问链路 —— App → App Backend → O2O 后台（用户主数据校验）；App Backend → 短信网关（验证码下发）；App Backend → 马上下单（门店列表）

逻辑数据来源 —— 用户主数据：O2O 接单宝后台（手机号、用户名、密码、角色）；门店列表：马上下单；协议内容：APP 后台管理 Web

回写目标 —— 登录日志、设备信息写入 App Backend；协议同意记录（版本号 + 时间戳）写入 App Backend

状态变化 —— 无会话 → 已登录（持有 access/refresh token）→ 已选定门店上下文

验收标准 —— 见 4.1.6

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 的「随意注册」问题。

⚠️ 注册表单字段、审核人、审核时效均未定义 —— 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 店长

店长通过自己注册的手机号登录页面；
店长通过注册的用户名、密码登录页面；
店长点击「用户协议」，可以查看用户协议的具体内容；
店长点击「隐私协议」，可以查看隐私协议的具体内容。

4.1.4 技工

技工通过自己注册的手机号登录页面；
技工通过自己的用户名、密码登录页面；
技工点击「用户协议」，可以查看用户协议的具体内容；
技工点击「隐私协议」，可以查看隐私协议的具体内容。

登录环节店长与技工无差异；差异从登录成功后的角色化导航开始，见导航收敛与角色化配置。

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 验收标准

未勾选协议时登录按钮为禁用态，无法提交；
单门店账号登录后直接进入首页，不出现门店选择步骤；
多门店账号登录后必须完成门店选择才能进入首页；
主动登出后，重新启动 APP 不会恢复到已登录状态，且 WebView 中原会话不可复用；
refresh token 失效后，任意业务页面的接口调用都会被统一拦截并跳转登录页，不出现半登录态；
切换门店后，首页及各业务页展示的数据全部属于新门店，无旧门店数据残留。

4.2 APP 首页

APP 首页是用户登录成功后展示的第一个页面。不同角色因权限不同，展示的信息和菜单不一样。

页面内容 —— 店长首页目标形态，自上而下为门店名 + 问候语 + 铃铛（角标 9）的头部、橙色「今日预计营收」卡、快速核销与车牌扫码两张卡、待办事项五项计数、动态预警与促销横幅，底部五 tab 为 首页 / 入库 / 采购 / 延保 / 我的。

关键交互 —— ①点门店名 → 切换门店（本稿未画下拉箭头，见下方说明）；②点眼睛图标 → 隐藏 / 显示金额类指标（REQ-HOM-011）；③点铃铛 → 进入消息列表，角标清零；④「快速核销-扫码 / 输码」→ 核销流程；⑤「车牌扫码-扫码 / 车牌」→ 接车进销售流程；⑥点待办任一项 → 进对应订单列表；⑦「查看全部」→ 全量预警列表；⑧点促销横幅 → 活动详情；⑨底部 tab 切换模块。

可用角色 —— 店长 ✅ 全量。本稿的金额类分区（预计营收 / 毛利 / 客单价）对技工 ✗，见 4.2.4。

需求关联 —— REQ-HOM-001 门店切换、REQ-HOM-002 问候语、REQ-HOM-003 消息公告、REQ-HOM-005/006 扫码与输码接车、REQ-HOM-007 快速核销、REQ-HOM-008 待办、REQ-HOM-009 动态预警、REQ-HOM-011 今日经营卡片

本稿的三处状态缺失（属设计稿补稿，不新增需求）：①门店名旁未画下拉箭头，而功能宫格版画了 ▾ —— 切店器的表现形式两版不一致，随 REQ-HOM-001 统一；②动态预警角标写「2 项待处理」，但列表区只画了 1 条（低库存），第 2 条未画；③金额隐藏后的形态（打码还是留空）未画。

页面内容 —— 技工首页目标形态，头部无门店名与铃铛、橙色卡改为「今日已完工 8 单」且不含任何金额，快速核销与车牌扫码两张卡同店长版，其下是技工独有的「当前施工队列（共 2 单）」工单卡，底部五 tab 与店长版一致。

关键交互 —— ①「查看绩效明细」→ 技工个人绩效页（该页无设计稿）；②「开始施工」→ 工单转「安装中」；③「完工并结算」→ 结算（去 F6 结算页还是 App 内页未定 TODO(REQ-HOM-012)）；④快速核销与车牌扫码同店长版。本稿未画消息铃铛、待办事项、动态预警、促销位。

可用角色 —— 技工 ✅。「当前施工队列」为技工独有，店长 ✗。技工是否应有消息 / 待办 / 预警三个分区，业务需求说有、本稿未画 —— TODO(REQ-HOM-003) / TODO(REQ-HOM-008) / TODO(REQ-HOM-009)。

需求关联 —— REQ-HOM-011（技工只看完工单数，本稿是该规则的直接落地）、REQ-HOM-012 当前施工队列

卡片一的施工内容写作「更正品查验 + 动平衡 + 轮胎号延保绑定」，疑为「更换 / 正品查验」的文案笔误，补稿时一并核对。

页面内容 —— 首页备选方案（对应三版底部导航的方案 C），自上而下为内嵌核销码输入框的橙色头部、限时活动三张商品卡、待办事项五项计数、八宫格功能入口与经营业绩区（四个时间 tab + 三项指标，数值为占位），底部五 tab 为 首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心。

关键交互 —— ①输核销码 → 点「核销」直接核销（比店长版少一步进卡片）；②「限时活动-更多」→ 活动列表；③点商品卡 → 目标未定，见 REQ-HOM-016；④点八宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）任一 → 进对应模块；⑤切换当日/当周/当月/当季 → 刷新经营指标；⑥「经营业绩-更多」→ 经营报表。

可用角色 —— 本稿未区分角色，仅作导航方案备选。若采用，需补技工版 —— 稿中「经营业绩」含 O2O 成交金额，属金额类，对技工应不可见（TODO(REQ-PRF-001)）。

需求关联 —— REQ-HOM-010 角色化导航（本稿即方案 C 的实体）、REQ-HOM-007 快速核销、REQ-HOM-016 促销位形态与来源

本稿与店长版的两处口径不一致，需在 REQ-HOM-008 / REQ-HOM-016 一并裁决：①待办首项，店长版写「待接单」、本稿写「待订单」；②促销位，店长版是底部活动横幅、本稿是顶部三商品卡、技工版没有 —— 三版稿画了三种形态；且本稿三张商品卡直接用了京东站内推广创意（可见「京东JOY」「JD.COM」「爱奇艺」等第三方水印），正式稿须换成马牌自有素材。

4.2.1 需求描述

业务目标 —— 把分散在三套小程序的入口、待办、经营数据聚合到一屏，让门店开工第一眼就知道「今天有什么要做、有什么要盯」，解决痛点 2.1 与 2.5

目标角色 —— 店长、技工（内容差异见 4.2.3、4.2.4）

入口 —— 登录成功后默认落地；任意页面点击底部「首页」tab

前置条件 —— 已登录且已确定当前门店上下文

页面内容 —— 见 4.2.3、4.2.4

主流程：

进入首页
并行拉取门店信息、待办、预警、促销、经营卡片
分区渲染，任一分区失败不阻塞其它分区
用户点击分区进入对应模块

异常流程：

单个数据源超时/失败 → 该卡片显示占位与「重试」，其余正常展示（局部降级，见《后端跨域协作与聚合文档》）
门店未接 F6 → 隐藏依赖 F6 的分区与 tab
无待办 → 显示空态而非隐藏分区

业务规则 —— 见 4.2.6

权限规则 —— 底部 tab 集合、卡片可见性均由 App Backend 按「角色 + 门店能力」下发，客户端不硬编码，见 4.2.5

访问链路 —— App → App Backend（聚合）→ 并行 fan-out 至 O2O / ROOS / 延保 / CDMS / F6

逻辑数据来源 —— 见 4.2.7

回写目标 —— 消息已读状态回写 App Backend；其余为只读聚合

状态变化 —— 消息：未读 → 已读；待办项计数随源系统单据状态变化

验收标准 —— 见 4.2.8

4.2.2 现状导航与目标导航的差异

整合前，三套小程序各带一套底部导航，且互相之间用「首页放友链」的方式跳转（见 2.7.1）。整合后全部小程序 tabbar 一律废弃，App 只保留一套底部导航。

现状入口	现状位置	App 归属
ROOS 首页 / 商品 / 购物车	ROOS tabbar	合并进「采购」tab（4.6）
ROOS 我的	ROOS tabbar	拆分：账务类进「我的」（4.8），对账单进财务，业绩进经营业绩
ROOS 扫码出库 / 扫码入库	ROOS 首页	「入库」tab（4.7）
O2O 核销码输入 + 核销	O2O 首页顶部	首页「快速核销」卡片
O2O 订单管理五状态	O2O 首页	首页「待办事项」+ 4.3 销售的订单列表
O2O 两组功能宫格（13 项）	O2O 首页	分派至 4.9 / 4.10 / 4.11 / 4.12 / 4.13
延保首页 / 工作台 / 待办事项 / 我的	延保 tabbar	合并进「延保」tab（4.5）
「订货平台 / O2O / 延保门店端 / 积分兑换 / 零售管理」互跳宫格	ROOS + O2O 首页	取消——整合后无需互跳；其中「积分兑换」保留为 4.14 福利兑换入口

现状入口 → App 导航映射

4.2.3 店长首页

自上而下分区（见本节店长首页设计稿）：

一、门店切换

当前用户旗下如果有多家店，可以通过顶部的下拉选择项切换至不同的门店。切换后所有业务数据按新门店重新加载。

二、问候语

用户成功登录首页后，在左上方展示用户信息以及问候。系统读取当前用户的姓氏、角色以及当前时间段，整合成合适的问候语，如「张店长，上午好」。

三、消息公告

右上角铃铛图标的角标展示当前未读消息条数；点击图标以列表形式展示系统站内信；点击后角标数字消失。促销信息展示往期马牌的所有促销活动；通知消息由管理员在后台管理平台发布。

页面内容 —— ROOS 小程序「公告列表」页，本图为空态（「暂无公告」占位），故公告条目的字段构成无法从本图确认。

关键交互 —— ①左上返回；②有数据时点条目进详情（本图无法确认）。本页除返回外无任何筛选、搜索或标记已读的控件。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-HOM-003)。ROOS 侧现状不区分角色。

需求关联 —— REQ-HOM-003 消息公告、REQ-HOM-004 促销信息（往期促销即在本列表中承载）

页面内容 —— O2O 接单宝「消息」页，按日期分组的卡片流，本图可见的消息全部是同一类（【门店违规】提醒），且最新一条已是 2023-04-13。

关键交互 —— ①上下滑动按日期倒序浏览。未见已读标记、删除、分类筛选或点击进详情的控件 —— 本页是纯只读消息流。

可用角色 —— 店长 ✅（违规会导致「禁止接单」，属店长必须知悉的治理类消息）；技工 ❓ TODO(REQ-HOM-003)。

需求关联 —— REQ-HOM-003。本图是「消息分类体系」这条待确认的核心证据：O2O 侧是会阻断经营的治理类消息，ROOS 侧是促销与通知类公告，两者的紧急程度、是否需强提醒、能否删除完全不同，合并进一个消息中心时必须分类承载。本图的违规原因样例为「车牌号已超出年度最大下单量」「同一手机号下多笔订单超过限制数量」「门店单日销量超过限制数量」，均由风控规则触发，正文写「门店触发违规条件，已被禁止接单」并附「如有异议，请联系门店相应的销售代表」。

现状消息分散在 ROOS「公告」与 O2O「消息」两处，且类型不同（ROOS 为促销/通知公告，O2O 含门店违规提醒等治理类消息）。整合后需在一个消息中心内分类承载 —— 消息分类体系 TODO(REQ-HOM-003)。

补充：附录 A.2 已定义消息列表「支持查看、标记已读、删除」，但上面两张现状图都没有这三个控件 —— 这三项是 App 的新增能力，不是现状迁移，开发时需明确它们作用于哪一侧数据（App 自有消息表还是回写 ROOS / O2O）。

四、促销信息

提醒用户当前马牌轮胎有促销活动，系统展示马牌最近一次举行的促销活动；点击促销区域展示具体活动内容。促销活动内容来自 ROOS 提供的接口；APP 后台定时调用促销活动接口，拉取促销信息并推至用户首页；往期促销信息在右上角铃铛对应的列表页中展示。

设计稿中该区域为首页底部的横幅广告位（「马牌高端系列买三送一」）。

⚠️ 三版设计稿对促销位画了三种形态 —— 形态与来源需一并裁决，见 REQ-HOM-016。

五、扫码接车

当客户车开进马牌门店时，用户可以直接点击「扫码」按钮，对准客户车头识别车辆号牌，进入销售流程。

扫码由 App 原生能力实现（native_scan），非 F6 提供的扫码页，见 C5。车牌识别走云端 OCR 服务：拍一张照上传识别，不是取景框里的实时识别，因而依赖网络——「输码」不是失败后的降级，而是与「扫码」并列的常驻入口。见第 10 章风险 R9。

六、输码

在做客户接车时，因特殊原因无法正确通过「扫码」识别客户车牌时，可以通过「车牌」按钮手工输入客户的车辆号牌，进入销售流程。

七、快速核销

设计稿在「车牌扫码」之外并列了一组「快速核销」（扫码 / 输码），对应 O2O 接单宝首页顶部的核销码输入框 —— 消费者到店出示线上订单核销码，门店扫码或手工输码完成核销。

扫码核销的详细流程待确认 —— TODO(REQ-SAL-010)，详见 4.3.4。

八、待办事项

待办事项在首页中扮演用户助手的角色，方便用户随时查看自己的工作列表。每项提醒的上方显示该项对应的待办事项总数。

现有两套并存的待办口径，两者不冲突，是两个层次：

层次	项目	来源	说明
跨系统提醒（业务层）	O2O 订单接单提醒、CDMS 采购单支付提醒、延保视频上传提醒、问卷提醒、过期门店信息更新提醒	O2O / CDMS / 延保 / 待定	按来源系统聚合的业务提醒
订单流转状态（单据层）	待接单、待调货、待安装、待配送、待服务	O2O 订单管理	设计稿口径；对应 O2O 现状的「待接订单 / 调货中 / 待安装 / 待配送 / 配送中」

待办事项两层口径

设计稿的五项与 O2O 现状五状态一一对应但措辞不同（「待调货」vs「调货中」、「待服务」vs「配送中」）。首页最终展示哪一层、或两层如何合并展示 —— TODO(REQ-HOM-008)，见 C2。

补充：措辞不一致不止存在于「设计稿 vs O2O 现状」，两版设计稿之间也不一致 —— 店长版首项写「待接单」，功能宫格版写「待订单」。取哪一套措辞随本条一并定稿。

九、动态预警

动态预警在首页中扮演用户管家的角色，随时帮用户检查目标任务达成情况、库存数量预警、时效订单预警等。系统按紧急程度在动态预警右边展示需要及时处理的事件数量，并提供「查看全部」入口浏览所有需要及时处理的事件。

预警项全集：

预警项	数据来源	备注
总预警数	APP 后台计算	各项之和
月度签约达成预警	`TODO(REQ-HOM-009)`	达成口径与阈值待定
库存预警（低库存）	F6	⚠️ 未接 F6 不显示此项；设计稿示例为「低库存马牌 205/55R16 剩余 5 条」
时效订单预警	O2O	临近履约时限的订单

动态预警项

各项预警的触发阈值（如低库存的条数门槛、时效订单的提前量）均未定义 —— TODO(REQ-HOM-009)，见 C3。

十、今日经营卡片

设计稿在问候语下方设有营收卡片：今日预计营收（¥34,500）、毛利率（88%）、成交单数（24 单）、客单价（¥1,437），并带「眼睛」图标支持一键隐藏金额。

该卡片仅见于设计稿。「预计营收」的口径（是否含未结算订单、是否含延保与返利、毛利率的成本口径）未定义 —— TODO(REQ-HOM-011)，见 C8。金额隐藏功能对应痛点 2.2 中「技工可查看门店财务数据」的风险控制诉求。

十一、底部导航

见 4.2.5。

4.2.4 技工首页

技工首页与店长首页的分区差异（见本节技工首页设计稿）：

分区	店长	技工	说明
门店切换	✅ 下拉切换	⚠️ 仅显示门店名	拥有多门店权限的用户可切换门店；设计稿技工版无门店名与切换器 —— `TODO(REQ-HOM-001)` 需确认技工是否允许多门店
问候语	「张店长，上午好」	「韩师傅 · 技师」	设计稿技工版为「姓氏 + 师傅 · 角色」格式，无时段问候
消息公告	✅ 铃铛 + 角标	⚠️ 设计稿未出现	业务需求中技工应有消息公告 —— `TODO(REQ-HOM-003)` 需确认
促销信息	✅	✅	技工可见
今日经营卡片	今日预计营收 / 毛利 / 成交单数 / 客单价	今日已完工 N 单 + 「查看绩效明细」	技工不可见金额类数据，与痛点 2.2 一致
快速核销 / 车牌扫码	✅	✅	完全一致
待办事项	✅	⚠️ 设计稿未出现	业务需求中技工应有待办事项 —— `TODO(REQ-HOM-008)`
动态预警	✅	⚠️ 设计稿未出现	业务需求中技工应有动态预警 —— `TODO(REQ-HOM-009)`
当前施工队列	❌	✅	技工独有分区，仅见于设计稿

店长 / 技工首页分区差异

上表「促销信息技工 ✅」与技工版设计稿不符 —— 技工版稿中没有促销位（店长版有底部横幅、宫格版有顶部商品卡）。该行按业务需求填写，实际形态随 REQ-HOM-016 一并确认。

当前施工队列（技工独有）

展示分配给当前技工的施工任务，卡片含：车牌号、订单来源渠道标（天猫订单 / 京东订单）、状态标（安装中 / 待安装）、施工内容（如「更正品查验 + 动平衡 + 轮胎号延保绑定」「更换马牌 UC6 225/55R17 * 4 条」）、预约时间、主操作按钮（「完工并结算」/「开始施工」）；顶部显示「共 N 单」。

该分区仅见于设计稿。涉及的问题：施工任务如何分派给具体技工？状态机与 F6 工单、O2O 服务单的关系？「完工并结算」跳转到 F6 结算页还是 App 内页？—— TODO(REQ-HOM-012)，见 C13。

4.2.5 导航收敛与角色化配置

收敛原则

整合后 App 只有一套底部导航，所有小程序 tabbar 全部废弃；
tab 集合不在客户端硬编码，由 App Backend 在登录/切店后下发；
下发依据为 角色（店长 / 技工）× 门店能力（是否接 F6、是否开通延保等）；
客户端对未知 tab code 做忽略处理，保证后端可灰度增删 tab 而不强制发版。

三版 tab 方案

方案	tab 集合	来源
A（业务菜单版）	首页 / 库存 / 采购 / 我的	业务需求「用户主菜单」
B（主设计稿）	首页 / 入库 / 采购 / 延保 / 我的	设计稿首页-店长、首页-技工、个人中心
C（宫格版）	首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心	设计稿首页-功能宫格版

三版底部导航方案

三者的差别不只是段数：方案 A/B 是「业务动作导向」（去入库、去采购），方案 C 是「管理职能导向」（看门店、看经营、看账务），且方案 C 把业务动作全部收进首页的 8 宫格（扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换）。

推荐方案：以 B 为基线（业务动作导向更贴合门店高频操作），把 C 的管理职能入口收进「我的」与首页宫格。

⚠️ 各角色的具体 tab 清单尚未确认 —— TODO(REQ-HOM-010)，见 C1。下表为待确认的建议值：

tab	店长	技工	门店能力依赖	对应章节
首页	✅	✅	—	4.2
入库	✅	✅	—	4.7
采购	✅	⚠️ 授权可见	—	4.6
延保	✅	✅	门店已开通延保	4.5
我的	✅	✅	—	4.8

角色化 tab 配置（建议值，待确认）

店长版与技工版两张设计稿的底部导航完全一致（首页 / 入库 / 采购 / 延保 / 我的），即稿中并未体现角色化差异 —— 差异全在页面内容而非 tab 集合。上表把「采购」对技工标为「授权可见」，属建议值，设计稿并未画出技工少一个 tab 的形态。

门店能力开关对导航的影响

已明确一条硬规则：

⚠️ 如果当前用户所在门店未接 F6，「库存」菜单不显示；对技工还需叠加「技工无此权限则不显示」。

推广为通用规则：任一 tab 或首页分区若依赖某外围系统，而当前门店未接入该系统，则该 tab / 分区整体隐藏（而非置灰或点击后报错）。能力开关清单见 7.4。

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）

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 又写作顶部滚动提示，共四种说法；宫格版素材直接用了第三方电商推广创意，正式稿须换成马牌自有素材。最终形态、数据来源、点击目标与技工可见性均待定 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 接口 CDMS 采购单支付提醒：CDMS 接口延保视频上传提醒：延保接口问卷提醒：`TODO(REQ-HOM-014)` 过期门店信息更新提醒：`TODO(REQ-HOM-015)`
6	动态预警	PrecautionIndexList	多源	总预警数：APP 后台计算月度签约达成预警：`TODO(REQ-HOM-009)` 库存预警：F6（⚠️ 未接 F6 不显示此项）时效订单预警：O2O
7	动态预警查看详情	PrecautionAllList	同上	全量预警列表
8	今日经营卡片	TodayBusinessCard	`TODO(REQ-HOM-011)`	预计营收 / 毛利率 / 成交单数 / 客单价（店长）；已完工单数（技工）
9	当前施工队列	WorkQueueList	`TODO(REQ-HOM-012)`	技工独有；车牌、渠道、状态、施工内容、预约时间
10	底部 tab 配置	TabConfigList	APP Backend	按角色 + 门店能力下发

APP 首页信息字段

4.2.8 验收标准

未接 F6 的门店，登录后底部导航不出现依赖 F6 的 tab，首页不出现库存预警项；
多门店店长切换门店后，首页全部分区（待办、预警、经营卡片、促销）均刷新为新门店数据；
任意单个上游系统（O2O / CDMS / 延保 / F6）不可用时，首页仍可打开，失败分区显示占位与重试，其余分区正常；
技工登录后首页不出现任何金额类经营指标；
消息角标数字与消息列表未读条数一致；进入列表后角标归零。

4.3 销售

关于「原型」图源的说明：本节 11 张标注为「原型」的图，实为 F6 系统的真机截图拼版（多联屏，图下带中文标注），不是线框稿。其中 原型-销售-历史记录页、原型-销售-车主车辆卡片、原型-销售-历史工单、原型-销售-延保历史记录 四张是 App 目标形态的设计稿（iPhone 边框、马牌橙配色），其余 7 张是 F6 现状截图（蓝色主色）。两类图混在同一前缀下容易误读，引用时须按实际图源理解，不以前缀为准。

用户登录成功后，通过「扫码」按钮扫描客户车牌，即可进入销售流程。

4.3.1 需求描述

业务目标 —— 把「车开进门店」到「结算完成并办理延保」的全链路装进一个 APP，消除 F6、O2O、延保三系统间的重复录入，解决痛点 2.6

目标角色 —— 店长；技工（授权后功能一致，见 4.3.8）

入口 —— 首页「扫码 / 车牌」（接车）；首页「快速核销」（线上订单核销）；底部导航进入订单列表

前置条件 —— 已登录并确定门店上下文；接车与施工链路要求门店已接入 F6；核销链路要求门店已开通 O2O

页面内容 —— 见 4.3.2–4.3.7

主流程：

扫码/输码识别车牌
后端凭车牌向 F6 取车主车辆信息
展示历史工单与延保历史
新建工单 / 检测开单
施工查车
生成检测报告并发送车主
检测单转工单
完工
结算收银
结算后跳转延保

异常流程：

车牌识别失败 → 转手工输码
F6 无该车档案 → 进入新建车辆建档流程
门店未接 F6 → 隐藏历史工单、销售商机、施工查车、结算等 F6 分区
F6 接口超时 → 提示重试且不生成半截单据
核销码无效/已核销/过期 → 分别给出可区分的错误提示

业务规则 —— 见 4.3.9

权限规则 —— 技工被分配销售权限后功能与店长一致；未授权技工不可见销售入口。金额类信息（商品总价、实收金额）对技工的可见性 —— 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

4.3.2 接车与车辆识别

页面内容 —— 接车成功后的「历史记录」页（App 目标形态）：顶部为交易流水号与橙色「已在店」状态，中部是橙色车主车辆卡，下方「历史工单 / 延保历史记录」两个 tab，底部固定三个橙色描边按钮。

关键交互 —— ①切换「历史工单 / 延保历史记录」两个 tab；②点击车架号旁的复制图标 → 复制 VIN；③点击车辆卡右上「销售商机」→ 销售商机页；④展开/收起工单卡的「查看项目材料」→ 显示项目 / 工时费 / 折后价明细；⑤底部三按钮 —— 「新建工单」进 F6 开单、「扫码核销」进核销流程、「延保」直接进延保建单。

可用角色 —— 店长 ✅ 全量；技工 ⚙️ 需被分配销售权限（见附录 B）。金额字段（商品总价 ¥5.00 / 实收金额 ¥5.00）对技工是否可见未定 TODO(REQ-SAL-012)。

需求关联 —— REQ-SAL-001 交易流水号、REQ-SAL-015 与 F6 单号并存、REQ-SAL-016 接车页三个并列入口

本图揭示了正文未记的一条重要路径：接车页底部同时给出「新建工单 / 扫码核销 / 延保」三个入口，即延保可以直接从接车页发起，不必先走 F6 结算。而 4.3.7 只描述了「结算后跳延保」一条路径。两条路径都要支持，见 REQ-SAL-016。

另有两处设计稿的示例数据自相矛盾，设计评审时应修正：车辆卡的当前里程是 23456 km，而下方历史工单的行驶里程是 30000km —— 上次到店的里程大于当前里程，逻辑上不成立。

一、交易记录号

APP 自动按预定规则生成门店交易流水号，在业务保存时提交此唯一交易号。

流水号生成规则（前缀、门店码位数、日期段、序列位数、跨天重置策略）未定义 —— TODO(REQ-SAL-001)。该号需保证幂等提交，见《后端并发、事务与定时任务文档》。

二、已在店

车牌扫码成功或用户输码成功后，系统显示该车状态为「已在店」。

三、当前时间

APP 获取手机系统当前时间；格式：YYYY-MM-DD HH:mm。

四、车主车辆信息

页面内容 —— 车主车辆卡的放大视图：橙色圆角卡内自上而下为车牌号、车主姓名、行驶证车架号（带复制按钮）与「里程 | 最近到店」一行，右上角是「销售商机」胶囊。

关键交互 —— ①点击车架号右侧复制图标 → 一键复制 VIN；②点击「销售商机」→ 销售商机页（仅接入 F6 的门店可见）；③车牌与其余字段为只读展示。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。车主姓名属消费者个人信息，展示口径见 REQ-SAL-026。

需求关联 —— REQ-SAL-002 车牌识别、REQ-SAL-003 车辆信息获取、REQ-SAL-006 销售商机、REQ-SAL-017 「待确认」态的展示位

REQ-SAL-002 要求「置信度偏低时以『待确认』展示」，但本卡片的设计上没有承载该状态的位置 —— 车牌是纯展示文本，既无角标也无可点编辑入口。须补设计，见 REQ-SAL-017。另外只有车架号有复制按钮，车牌没有。

用户扫码获取车辆车牌后，后台通过车牌从 F6 获取车主信息、行驶证车架号、车辆里程，以及最近一次到店时间；如果是第一次到店，显示当天时间。

#	字段	字段名	数据来源	说明
1	车牌	CarPlate	拍照识别或手工输入	识别经云端 OCR，需联网；置信度低时以「待确认」展示
2	车主姓名	OwnerName	F6 接口获取
3	车架号	VIN	F6 接口获取	支持一键复制
4	里程	Milage	F6 接口获取
5	最近到店时间	LatestArrDate	F6 接口获取	首次到店显示当天

根据车牌获取车主车辆信息

五、历史工单

页面内容 —— 「历史工单」tab 的放大视图：一条工单卡，含门店与服务时间的卡头、车牌与「已结算」标、行驶里程 / 服务顾问 / 业务分类、商品总价与实收金额，底部是可展开的「查看项目材料」明细表。

关键交互 —— ①点击「查看项目材料 ^」→ 展开/收起明细表；②卡片本身是否可点入工单详情本图无法确认。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权，且商品总价与实收金额两个字段是否屏蔽未定 TODO(REQ-SAL-012)。门店未接 F6 时整个分区不显示。

需求关联 —— REQ-SAL-004 历史工单来自 F6，未接 F6 则整区不显示

展示该车以前的维修记录。历史记录从 F6 取；如果门店未接 F6，则「历史工单」不显示。

字段：门店名、服务时间、车牌号、行驶里程、服务顾问、业务分类、商品总价、实收金额、结算状态、可展开的「查看项目材料」（项目 / 工时费 / 折后价）。

六、延保历史记录

页面内容 —— 「延保历史记录」tab：三张保单卡纵向排列，每张含编号、车牌、保障类型标签、时间与「详情 >」入口，右上角是状态胶囊（正常 / 待确认 / 待补充）。

关键交互 —— ①点击「详情 >」→ 保单详情（进入 4.5 延保）；②保障标签（数包保障 / 爆胎保障 / 延保服务）为只读标识，一张保单可带多个标签。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。数据来自延保后台，不受门店是否接入 F6 影响。

需求关联 —— REQ-SAL-005 延保历史来自延保后台，与历史工单并列为两个 tab

本图有两处必须在设计评审时修正的设计问题：

状态色与语义错配 —— 「正常」用橙色（警示色）、「待确认」用绿色（成功色）、「待补充」用红色。按通行约定应为：正常=绿、待确认=橙、待补充=红。

三条记录的 POLICY NO. 完全相同（8507302611），车牌也相同（豫AQ27Z3），但状态各不相同 —— 若保单号唯一，则不应出现三条；若一张保单可对应多条保障记录，则列表的主键与去重规则需说明。同时该车牌与本节其它图的 鄂AH0889 不是同一台车，属拼版示例数据不一致。

延保历史记录通过「延保」小程序后台获取信息。字段：POLICY NO.、车牌、保障标签（数包保障 / 爆胎保障 / 延保服务）、保单状态（正常 / 待确认 / 待补充）、时间、详情入口。

七、销售商机

开通 F6 的门店才有此功能。点击「销售商机」展示销售商机页，「服务提醒」和「意向池」的内容来自于 F6 接口。

4.3.3 检测、开单与施工

八、新建工单

点击「新建工单」，弹出新建工单页，由 F6 开发页面。

页面内容 —— F6 三联屏：左屏「到店记录」（F6 单号 + 「已在店」、含「完善信息 / 完善VIN码」入口的蓝色车辆卡、保险信息分区、里程与油量、四个开单入口图标、「小程序订单」关联行、底部「离店」），中屏是新车辆建档表单，右屏是「车辆详情」。

关键交互 —— ①左屏四个开单入口（预检开单 / 检测开单 / 报价开单 / 工单开单）→ 各自的开单流程；②保险信息每行右侧「查询」→ 触发机器人（RPA）代查保险到期日，「去完善 >」→ 手工补录；③点击「小程序订单无待服务订单 >」→ 查看该车关联的 O2O 订单；④点击「离店」→ 车辆状态由「已在店」转「离店」；⑤中屏车牌号与 VIN 均可勾选「无」，也可点扫描图标调用相机；⑥中屏客户姓名右侧的通讯录图标 → 从手机通讯录选联系人；⑦右屏「复制VIN」「客户信息 >」「配置详情 >」「开单」。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。页面由 F6 提供并在 Embedded H5 内运行，页内权限由 F6 控制，App 只控入口可见性。

需求关联 —— REQ-SAL-007 页面由 F6 提供、REQ-SAL-015 两套单号并存、REQ-SAL-018 无车牌/无 VIN 建档、REQ-SAL-019 通讯录能力、REQ-SAL-026 车主信息脱敏、REQ-SAL-037 到店时提示待服务订单

本图有四处关键发现：

两套单号并存 —— F6 到店记录用的是 F6 自己的单号（DD 前缀），而 App 接车页顶部用的是 App 生成的交易流水号（D 前缀，格式与位数都不同）。同一次接车挂着两个号，须定义映射与对外展示口径，见 REQ-SAL-015。

F6 侧已有「小程序订单」关联入口 —— 说明 F6 与 O2O 之间已存在关联通道。这对 TODO(REQ-SAL-014)（服务单与工单关系）是重要证据，也意味着 App 整合后不应再出现两套互不相通的订单视图，见 REQ-SAL-037。

建档时车牌与 VIN 都可勾「无」 —— 允许无车牌车辆建档，但这类车既无法扫码接车，也无法按车牌与延保保单绑定，见 REQ-SAL-018。

客户姓名支持从手机通讯录选取 —— 这是需要通讯录读取权限的原生能力。H5 在 App 容器内运行时该能力不可用，且通讯录属高敏感权限，见 REQ-SAL-019。

另：右屏车辆详情完整展示车主手机号并提供「复制」按钮，车主是消费者而非门店员工，属个人信息保护范畴，见 REQ-SAL-026。F6 页面主色为蓝色，与 App 橙色主题不一致。

到店记录页含：车牌、完善信息入口、保险信息（交强险 / 商业险 / 保险公司到期日与查询状态）、当前里程与油量、四个开单入口（预检开单 / 检测开单 / 报价开单 / 工单开单）、小程序订单关联区、「离店」按钮。

新车辆建档页含：车牌号（支持扫描）、车辆用途（乘用车 / 商用车）、VIN（17 位，支持扫描，保存后自动解析车型）、车型、客户信息（姓名、手机号码）、更多联系人、行驶证信息。

车辆详情页含：品牌车型、VIN、编辑车辆 / 编辑车辆标签、建档人、车辆分类、燃油类型、年检日期、一级类型、轮胎规格与发动机型号等出厂配置详情、客户信息、消费历史、保险保养信息、「给当前车辆发票」/「开单」。

九、施工查车

页面中的「预检开单」等操作按钮弹出相关工单页，由 F6 开发页面。

页面内容 —— F6 两联屏：左屏是「到店记录」下滑后的上半部分（橙色商机提醒条、历史记账 / 上次服务 / 定金 / 卡 / 优惠券五项汇总、专属顾问、客户标签、轮胎出厂规格），右屏是点「检测开单」后从底部弹出的检测项目选择面板。

关键交互 —— ①点「检测开单」→ 弹出面板，五选一：底盘检测 / 保养速检 / 轮胎专检 / 3万公里保养检测 / 新能源检测；②点「商机」条的「已过1条共1条 >」→ 商机明细；③点客户标签「共3个 >」→ 标签全量；④「收起 ^」折叠车辆信息区。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。金额类字段（历史记账、定金）对技工的可见性同 TODO(REQ-SAL-012)。

需求关联 —— REQ-SAL-007 页面由 F6 提供、REQ-SAL-020 检测项目类型

正文只写了「预检开单等操作按钮弹出相关工单页」，未列检测项目类型。实际有 5 类，轮胎门店最相关的是「轮胎专检」，见 REQ-SAL-020。另：F6 已存有该车的「轮胎出厂规格前后轮 235/60 R18」，这条数据对采购推荐与延保建单都有用，App 整合后应加以利用。「商机」的具体形态之一就是车险到期提醒，可与 4.4 提醒的提醒规则打通。

页面内容 —— F6 两联屏「轮胎专检」：左屏是初始态（全部(24) / 已检(0) / 未检(24) 三个 tab、按轮位分组的检测项与结论按钮、底部「放弃检测 / 批量通过 / 保存」），右屏是已检 2 项并弹出「确定将未检测项目批量通过吗？」二次确认的状态。

关键交互 —— ①点结论按钮选定检测结果（花纹深度：正常 / 尽快更换 / 立即更换；偏磨：正常 / 偏磨中间 / 偏磨胎肩 / 失圆；外伤：正常 / 鼓包 / 划伤 / 漏气）；②「+ 添加备注/图片」→ 拍照或选图上传（右上「0/200」疑为上传配额，本图无法确认其含义）；③点轮位分组右侧「检测视频」→ 录制或查看该轮位视频；④「批量通过」→ 二次确认后把所有未检项一次性标记为正常；⑤「放弃检测」退出，「保存」提交。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权 —— 施工查车是技工的核心作业，实际使用者以技工为主。

需求关联 —— REQ-SAL-007 页面由 F6 提供、REQ-SAL-021 批量通过的留痕

「批量通过」是一处质量风险：一次点击即可把 22 项未实检的项目标记为「正常」，而这些结论会直接进入发给车主的检测报告。App 侧须保留该效率功能，但必须留痕并在报告上标注哪些项是批量通过的，见 REQ-SAL-021。另：全量检测项共 24 项，正文只描述了花纹深度 / 偏磨 / 外伤三类，未说明 24 项如何分布（四轮 × 三项 = 12，其余 12 项的构成本图无法确认）。

轮胎专检页：tab「全部(N) / 已检(N) / 未检(N)」；按轮位分组（如「左前轮检测」）含检测视频入口；每个检测项（花纹深度检测 / 偏磨检测 / 外伤检测）提供结论按钮（正常 / 尽快更换 / 立即更换、正常 / 偏磨中间 / 偏磨胎肩 / 失圆、正常 / 鼓包 / 划伤 / 漏气）与「添加备注/图片」；底部「共 N 项异常」+「放弃检测 / 批量通过 / 保存」；批量通过时弹确认。

页面内容 —— F6 两联屏「检测报告」：左屏为报告正文（红色环形健康度图「有隐患」、检测门店与服务人员、四类严重度计数卡、按严重度分组的检测明细含图片与视频、底部「客户签名 / 发给车主 / 去处理」），右屏是点「发给车主」后弹出的分享面板。

关键交互 —— ①点「发给车主」→ 弹出五渠道面板，每个渠道各有前置条件：车主微信（带「隐私安全」角标，仅主订单可发）、公众号推送（车主未关注则置灰）、企业微信、短信（未购买时显示「立即购买 > / 通知老板买 >」）、他人微信（带「隐私使用」角标，提示"其他人都可看"）；②点「客户签名」→ 车主在屏上签名；③点「去处理」→ 检测问题处理页（见下一张图）；④点检测项的图片/视频 → 放大查看。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。发送渠道涉及车主个人信息外发，见 REQ-SAL-026。

需求关联 —— REQ-SAL-008 检测报告发送、REQ-SAL-022 客户签名与渠道前置条件

正文写的「支持车主微信 / 公众号 / 企业微信 / 短信等渠道；短信渠道需购买」漏了两件事：一是第五个渠道「他人微信」及其隐私提示，二是**「客户签名」这个动作** —— 车主在检测报告上签名具有法律意义（是后续争议时门店已履行告知义务的凭据），必须留存签名图与时间戳。见 REQ-SAL-022。另：四类计数卡下方各带「已解决(N)」，说明检测项可被标记为已解决，正文未提及该状态。

检测报告页：健康度环形图（有隐患）、检测门店 / 服务顾问 / 服务技师、四类计数（急需处理 / 择期处理 / 建议处理 / 正常，各带「已解决(N)」）、按类分组的检测明细（检测图片、项目说明、视频）、底部「客户签名 / 发给车主 / 去处理」。发送渠道弹层含：车主微信（仅主订单）、公众号推送（车主已关注）、企业微信、短信（需购买）、他人微信。

页面内容 —— F6 三联屏：左屏是检测报告页，中屏是点「去处理」后弹出的转单类型面板，右屏「检测问题处理」逐条列出异常项并对每条给出「转维修单 / 转商机」二选一，底部为「待处理: 2 本次处理: 2」+「提交」。

关键交互 —— ①点「去处理」→ 弹出转单类型面板，五选一：转维保单或转商机 / 转维修单或转商机 / 转贴膜单或转商机 / 转洗车单或转商机 / 转理赔单或转商机；②每个异常项在「转维修单」与「转商机」间二选一（选中态为橙色实心）；③点「+ 项目」→ 添加服务项目并带出工时与金额；④点项目行右侧删除图标 → 移除；⑤底部计数随勾选实时变化，点「提交」生成单据。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。项目金额（¥40.00 / 工时 1.00）的可见性同 TODO(REQ-SAL-012)。

需求关联 —— REQ-SAL-009 检测单转单、REQ-SAL-023 转单类型共五种

正文写的转单类型是四种，实际是五种 —— 多一个「转维保单或转商机」（面板第一项）。已在 REQ-SAL-023 就地更正。

检测问题处理页：只支持处理「急需」「择期」「建议」类项目（不包含车辆检测视频和聊天记录）；每个异常项提供「转维修单 / 转商机」二选一；选择维修单后可添加项目（含工时与金额）；底部「待处理: N 本次处理: N」+「提交」。转单类型弹层：转维保单 / 转维修单 / 转贴膜单 / 转洗车单 / 转理赔单，各与「转商机」二选一。

页面内容 —— F6 两联屏：左屏「新建维修单」（四个批量操作按钮、项目行与材料行、自带材料 / 附加费 / 车主描述三个可添加区、底部金额与「提交」），右屏「查看维修单」，其客户信息区之下是绿色的本次到店状态条（接车 → 开单 → 施工 → 完工）。

关键交互 —— ①批量指派技师 / 批量业务分类 / 批量销售人员 / 更多 → 对多行一次性赋值；②点项目行的「技师: 请选择 >」→ 指派技师；③点「添加关联材料」→ 为该项目挂材料；④材料行的「质保信息」→ 查看/录入质保（图中标签为「未质保」）；⑤右屏点「完工」→ 工单状态推进到完工，按钮随之变为「收款」；⑥「价参」查看价格参考。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。「商品总价 ¥410.00 / 待收金额 ¥410.00」正是 TODO(REQ-SAL-012) 争议的字段。

需求关联 —— REQ-SAL-007 页面由 F6 提供、REQ-SAL-024 F6 库存与价格、TODO(REQ-SAL-012) 技工金额可见性

状态条「接车 → 开单 → 施工 → 完工」与 4.3.1 声明的工单状态机一致 ✓。材料行的「未质保」标签与「质保信息」入口，与 4.5 延保的质保/延保是两个不同概念，App 整合后须避免用户混淆。

新建维修单页：批量操作（指派技师 / 业务分类 / 销售人员 / 更多）；项目行（如「更换轮胎（普通胎 17 寸以上）」含工时、技师选择、添加关联材料）；材料行（如「乘用车轮胎」含数量、技师、仓库/货位、质保信息）；自带材料 / 附加费 / 车主描述；底部「商品总价 / 待收金额」+「价参 / 提交」。

查看维修单页：车辆头卡（车牌、车型、VIN、复制VIN、配置详情、标签）、商机与车险到期提醒、历史记账 / 上次服务 / 定金 / 卡 / 优惠券、专属顾问、客户标签、变速箱号 / 发动机号 / 发动机型号 / 轮胎出厂规格、服务顾问、本次到店状态条（接车 → 开单 → 施工 → 完工）、商品总价 / 待收金额、底部「发给车主 / 修改 / 完工」。

4.3.4 核销

十、扫码核销

消费者到店出示线上订单核销码，门店通过首页「快速核销」扫码或手工输码完成核销。

现状实证（O2O）：

页面内容 —— 「核销历史」列表：顶部「今天 / 本周 / 本月 / 全部」四个时间 tab（当前选中「全部」），下方是汇总「总共核销 4974 单」与核销记录列表。

关键交互 —— ①切换四个时间 tab → 列表与汇总数随之变化；②本页无搜索框、无渠道筛选，只能按时间段浏览；③记录行是否可点入详情本图无法确认。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权（见附录 B）。金额字段（订单金额 / 货款收入）的可见性同 TODO(REQ-SAL-012)。

需求关联 —— TODO(REQ-SAL-010) 核销流程、REQ-SAL-029 核销码按渠道路由校验、REQ-SAL-031 收入口径与 4.10 同源

本图给出了两条硬事实：

订单号格式至少有 4 种 —— LP20260305135911100463032（LP 前缀 25 位）、202602050001000269816（纯数字 21 位）、202602041518（纯数字 12 位）、AMAP202602041121（AMAP 前缀 = 高德）。核销码校验规则不能写死长度与字符集，见 REQ-SAL-029。

金额口径随订单来源而变 —— 一部分记录显示「订单金额」，另一部分显示「货款收入 + 消费者补贴（待审核）」。后者与 4.11 返利中心的消费者补贴是同一件事，即核销动作会触发补贴申报。正文完全未记这条链路。

该门店累计核销 4974 单，核销是高频操作，App 侧的核销入口须做到首页一步可达。

页面内容 —— 在「服务单列表」上弹出的「核销订单」白色弹窗：核销码输入框 + 右侧扫码图标 + 橙色「核销」按钮，遮罩下可见服务单卡片与「核销安装」按钮。

关键交互 —— ①在输入框手工键入核销码；②点右侧扫码图标 → 唤起相机扫码；③点「核销」提交；④点弹窗外的 ✕ → 关闭。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权 —— 核销直接影响履约与结算，权限须显式授予。

需求关联 —— REQ-SAL-028 「核销安装」为合一动作、REQ-SAL-029 核销码校验、REQ-SAL-027 核销入口在服务单

本图回答了 TODO(REQ-SAL-010) 的一个关键子问题：遮罩下的按钮名为「核销安装」，即现状把核销与安装合并为一个动作，核销成功后服务单直接由「待安装」变「已安装」，不是「核销后仍需单独标记安装」。见 REQ-SAL-028。卡头的「未核销 / 未打款」进一步说明：服务单上同时承载核销状态与打款状态，履约与结算是耦合的，与 4.10 财务与对账直接相关。

核销的详细流程仍有未尽项 —— TODO(REQ-SAL-010)：重复核销与撤销核销的处理尚无任何现状佐证。核销码格式见 REQ-SAL-029、核销与订单状态的关系见 REQ-SAL-028、错误分类见 REQ-SAL-029。见 C12。

4.3.5 线上订单管理

线上订单来自 O2O，是首页待办「单据层」五状态的详情载体。

页面内容 —— App 订单列表的目标形态：订单号搜索框 + 渠道与状态两级 tab，主体为订单卡列表，每卡含渠道与状态标、可复制的订单编号、带商品图的商品行、**独立的客户卡（含拨号按钮）**与底部两个操作按钮。

关键交互 —— ①在搜索框输入订单号检索；②切换渠道 tab（全部渠道 / 抖音 / 天猫 / 京东 / …）；③切换状态 tab 胶囊（待接单(9) / 待配送(3) / 调货中(6) / 待安装(4)），数字为该状态单量；④点订单编号右侧复制图标 → 复制单号；⑤点客户卡右侧拨号按钮 → 拨打车主电话；⑥「添加备注」→ 备注页；「确定接单」→ 接单。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。订单金额对技工的可见性同 TODO(REQ-SAL-012)。

需求关联 —— TODO(REQ-SAL-013) 渠道清单（已由 REQ-SAL-036 关闭）、REQ-SAL-030 订单金额下发时机、REQ-SAL-036 两套渠道枚举

设计稿有两处缺陷，须在设计评审时修正：

渠道 tab 中「天猫」出现了两次（全部渠道 / 抖音 / 天猫 / 京东 / 天猫）—— 重复项。

状态 tab 只有 4 个（待接单 / 待配送 / 调货中 / 待安装），而 4.3.1 声明的订单状态机是六态（待接单 → 调货中 → 待安装 → 待配送 → 配送中 → 已完成），缺「配送中」与「已完成」。现状 O2O 的状态 tab 是完整六态 + 「全部」。

另：设计稿的客户卡带「普通客户」客户等级，与 4.13 营销与会员的会员体系关联；现状 O2O 无此字段。设计稿订单金额示例为 ¥0，与现状一致，原因见 REQ-SAL-030。

设计稿订单列表：订单号搜索；渠道 tab（全部渠道 / 抖音 / 天猫 / 京东 / …）；状态 tab（待接单(9) / 待配送(3) / 调货中(6) / 待安装(4)）；订单卡含渠道标、状态、下单时间、订单编号（可复制）、商品行（名称 / 规格 / 数量）、客户卡（姓名 / 客户等级 / 拨号按钮）、共 N 件、订单金额、操作「添加备注 / 确定接单」。

现状实证（O2O）：

页面内容 —— O2O「订单列表」的「待接单」页签：搜索框 + 渠道 tab（全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖…）+ 状态 tab（待接单(10) / 待配送(0) / 调货中(3) / 待安装(19) / 配…），其下是「待接单 10 单」与「筛选」，主体为订单卡列表。

关键交互 —— ①点渠道 tab 右侧的 ^ → 展开全部渠道；②切换状态 tab；③点「筛选」→ 弹出筛选面板（见后）；④点车主行的红色电话图标 → 拨号；⑤点订单号右侧复制图标 → 复制；⑥「添加备注」→ 备注页；⑦「确定接单」→ 弹出货品状态选择（见后）。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-030 订单金额、REQ-SAL-032 订单标识、REQ-SAL-036 渠道枚举、REQ-SAL-026 车主信息脱敏

现状卡片结构与设计稿的三处差异：现状把「车主 + 红色电话图标」放在卡片最上方且无客户等级、无商品图；设计稿则是独立的客户卡 + 橙色拨号钮 + 商品图 + 客户等级。以设计稿为目标形态，现状缺失的商品图与客户等级须由接口补齐。第一条记录的车主姓名是「123456789」，属测试数据。订单金额为 ¥0，原因见 REQ-SAL-030。

页面内容 —— 同一页面切到「调货中(3)」页签，卡片结构与待接单一致，差别在于状态标签为「调货中」、操作按钮变为「确定到货」。

关键交互 —— ①点「确定到货」→ 订单由「调货中」推进到「待安装」；②其余交互同待接单页。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-030 订单金额、REQ-SAL-034 商品图兜底

操作按钮随状态变化：待接单 → 「确定接单」，调货中 → 「确定到货」。App 须按状态映射按钮文案与动作，不能做成一个通用的「下一步」。

页面内容 —— 切到「已完成(105)」页签（状态 tab 已横向滚动，可见待安装(26) / 配送中(0) / 已完成(105) / 全部(208)），卡片结构不变但车主姓名显示为 ***、操作按钮变成「查看延保」，第二张卡的卡头多出「已核销/未打款」与「抖音小店 | 发货」两段信息。

关键交互 —— ①点「查看延保」→ 查看该订单关联的延保保单；②其余同上。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-033 第二条延保入口、REQ-SAL-030 订单金额、REQ-SAL-026 脱敏规则、REQ-SAL-034 商品图兜底

本图有三处关键发现：

已完成订单带「查看延保」按钮 —— 说明线上订单履约完成后也会办延保，订单与保单之间已有关联。这是 4.3.7「F6 结算后跳延保」之外的第二条延保入口，正文完全未记，见 REQ-SAL-033。

订单金额在已完成状态下才有真实值（¥908），而待接单 / 调货中 / 待安装一律是 ¥0 —— 金额并非「免费」，而是接单阶段平台不下发，见 REQ-SAL-030。

车主姓名在已完成状态下脱敏为 ***，而待接单 / 调货中显示真实姓名。同一字段在不同状态下脱敏规则不同（推测与平台的号码保护期有关），App 须统一口径，见 REQ-SAL-026。

另：本卡的商品图是一张樱花与日式塔的风景照，不是轮胎 —— 属商品主数据配错图（不是缺图），见 REQ-SAL-034。

页面内容 —— 从底部升起的订单「筛选」面板，三组条件（订单标识：百亿补贴 / 达人带货 / 门店配送；下单时间：近 1/3/6 个月或自定义；是否打款：是 / 否），背景是「待配送 0 单」的空态页。

关键交互 —— ①点胶囊选中/取消筛选条件；②「起始时间 — 终止时间」→ 打开日期选择；③「重置」清空全部条件；④「确认」应用筛选并关闭面板。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。「是否打款」属结算信息，对技工的可见性同 TODO(REQ-SAL-012)。

需求关联 —— REQ-SAL-032 订单标识须下发并展示

「百亿补贴」「达人带货」正是 4.10 财务与对账里费率不同的订单类型（拼多多百亿补贴 2% vs 普通 1%、抖音达人带货 4% vs 普通 2%）。订单标识 → 结算费率的映射链路在此得到印证：门店在接单阶段就能据此预判到手金额，因此该标识必须作为订单字段下发并在卡片上直接展示，而不只是一个筛选条件，见 REQ-SAL-032。「是否打款」作为筛选项，再次说明履约与结算在 O2O 侧是耦合的。

页面内容 —— 点「确定接单」后从底部升起的「选择当前货品状态」面板，两个大方块选项「有货」（已选）与「可调货」，背景的渠道 tab 已横向滚动、露出后半段（抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎）。

关键交互 —— ①二选一「有货 / 可调货」；②点「确定接单」提交 —— 选「有货」订单进入「待安装」，选「可调货」订单进入「调货中」；③点 ✕ 取消接单。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权 —— 该选择直接决定履约路径，属经营判断。

需求关联 —— REQ-SAL-036 渠道枚举

这是订单状态机的分叉点，4.3.1 的状态变化「待接单 → 调货中 → 待安装」没有说明分叉条件，实际由接单时声明的货品状态决定。附录 C 第 18 行已正确记录这一点，正文须补齐。本图还补全了订单渠道的后半段。合并前一张图可得订单渠道完整枚举为 8 个：小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎，见 REQ-SAL-036。

页面内容 —— 「订单详情」页：顶部橙色状态条「待接单」，其下是车主与订单号、「商品列表」分区与订单金额，最下是订单来源 / 下单时间 / 支付方式 / 支付时间四行属性与两个操作按钮。

关键交互 —— ①点车主行的红色电话图标 → 拨号；②「添加备注」→ 备注页；③「确定接单」→ 弹出货品状态选择；④订单号在详情页没有复制按钮（列表页有）。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-030 订单金额、REQ-SAL-027 订单与服务单的职责划分

详情页比列表页多出订单来源、支付方式、支付时间三个字段。值得注意的是：订单金额显示 ¥0，却有「微信支付」与明确的支付时间 —— 消费者确实付了钱，只是金额未下发到门店侧，进一步印证 REQ-SAL-030。本页没有安装地址、预约到店时间、核销码等履约信息，服务类订单所需的预约时间本图无法确认是否存在。

页面内容 —— 同一详情页在「待安装」状态，结构与待接单页完全一致（状态条插画换成沙漏），差别在于底部只剩「添加备注」一个按钮。

关键交互 —— ①「添加备注」→ 备注页；②本页没有任何核销或安装操作入口。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-027 订单与服务单的职责划分

这是回答 TODO(REQ-SAL-014) 的直接证据：待安装的订单详情页没有核销按钮，核销动作只发生在服务单列表上（按钮「核销安装」）。即 订单 = 商流载体（接单 / 调货 / 发货），服务单 = 履约载体（核销 / 安装 / 服务收入），两者分工明确。见 REQ-SAL-027。同时这也是一处交互缺陷：用户在详情页确认完信息后无法直接核销，必须退回列表页。App 侧应在详情页补上核销入口。

页面内容 —— 极简的「订单备注」页：一个多行输入框 + 右下角字数计数「0/50」+ 橙色「保存」按钮。

关键交互 —— ①输入备注文本，上限 50 字；②点「保存」提交并返回。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-035 备注改为追加式并留痕

本页为空态，页面上看不到已有备注，因此备注是覆盖式还是追加式、是否展示历史备注与操作人，均无法从本图确认。门店多人协作时这一点很关键，见 REQ-SAL-035。

4.3.6 服务单

服务单是订单履约的施工侧载体，与订单一对一或一对多关联。

页面内容 —— 「服务单列表」的「全部(49)」页签：渠道 tab（全部渠道 / 美团 / 高德 / 抖音团购 / 百度 / 车点…）+ 状态 tab（待安装(4) / 已安装(45) / 全部(49)），主体是服务单卡列表，卡头为三段式「履约状态 | 核销/打款状态 | 查看」+ 右侧渠道名。

关键交互 —— ①切换渠道 tab 与状态 tab；②点卡头的「查看」→ 本图无法确认跳转目标（推测为核销凭证或明细）；③点订单号右侧复制图标 → 复制；④点卡片 → 服务单详情。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-027 服务单为履约载体、REQ-SAL-036 服务单渠道枚举、REQ-SAL-034 长商品名

服务单的渠道枚举与订单不同 —— 服务单是美团 / 高德 / 抖音团购 / 百度 / 车点点（+零跑，见 4.9 门店管理）共 6 个平台服务渠道；订单是 8 个商品渠道。二者是两个不同的枚举，不是同一份数据的不一致，见 REQ-SAL-036。商品名「【库存紧张】狂欢钜惠｜安全出行全车检测【德国马牌】」是带促销修饰的营销文案，不是规范商品名，两行才显示得下，见 REQ-SAL-034。订单号 DY20260416160239205533 7（DY 前缀 = 抖音）又是一种新格式，佐证 REQ-SAL-029。

页面内容 —— 切到「待安装(4)」页签，卡头为「待安装 | 未核销/未打款」+ 渠道「高德」，卡体首行是**「联系车主 + 完整手机号 + 红色电话图标」**，其后是订单号、创建时间与商品行，底部为「添加备注 / 核销安装」两个按钮。

关键交互 —— ①点红色电话图标 → 拨打车主电话；②点「核销安装」→ 弹出核销订单弹窗（见 4.3.4）；③「添加备注」→ 备注页。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权 —— 核销安装是技工的现场作业动作。

需求关联 —— REQ-SAL-028 核销安装合一、REQ-SAL-029 核销码格式、REQ-SAL-026 车主手机号脱敏

服务单显示的是「联系车主 + 完整手机号」，订单列表显示的是「车主 + 姓名」 —— 同一实体两种字段口径，且服务单侧手机号完全未脱敏，见 REQ-SAL-026。本图两条记录来自同一车主、同一时间，订单号却一个是纯数字 22 位、一个带 AMAP 前缀 —— 同一渠道下也存在两种单号格式（推测为平台单号与内部单号），核销码校验必须容忍这种并存，见 REQ-SAL-029。商品名「自动化测试」为测试数据；订单金额 ¥1888 与「高德洗车 ¥100」并存，说明 O2O 服务单承载的不只是轮胎安装，还有洗车等服务项。

页面内容 —— 切到「已安装(45)」页签，首屏内容与「全部」页签完全一致（同为两条抖音团购的 ¥9.90 全车检测记录），因为列表按时间倒序、最新两条恰好都已安装。

关键交互 —— 同「全部」页签，无新增交互。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-027 服务单为履约载体

本图与「全部」页签除计数与选中态外无差异，附录 C 保留两张的意义仅在于佐证页签切换。若后续补拍，建议改拍已安装状态下有多种渠道混排的样本。

页面内容 —— 服务单的「筛选」面板，只有「下单时间」（近 1/3/6 个月 + 自定义）与「是否打款」两组条件，比订单筛选少一组「订单标识」。

关键交互 —— ①选择时间范围；②选择是否打款；③「重置 / 确认」。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-032 订单标识、REQ-SAL-027 订单与服务单的职责划分

服务单筛选比订单筛选少一整组「订单标识」（百亿补贴 / 达人带货 / 门店配送）。这不是遗漏，而是因为服务类订单本就没有这些商品促销标识 —— 又一条支撑「订单与服务单是两条不同业务线」的证据，见 REQ-SAL-027。

页面内容 —— 「服务单详情」页（待安装）：顶部橙色状态条与沙漏插画，其下是联系车主与订单号、展示服务项的「商品列表」分区，再下是共计项数与订单金额 / 服务单来源 / 下单时间三行属性，底部只有「添加备注」。

关键交互 —— ①点电话图标 → 拨号；②「添加备注」→ 备注页；③本页同样没有核销入口。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。

需求关联 —— REQ-SAL-027 详情页须补核销入口

与订单详情页对比：服务单详情少了支付方式与支付时间，多了「服务单来源」（订单详情叫「订单来源」），量词也不同（「共计 1 项服务」vs「共计 1 件商品」）。App 统一后须固定一套字段名与量词。核销入口在详情页缺失的问题，与订单详情页相同，见 REQ-SAL-027。

页面内容 —— 同一详情页在「已安装」状态，页面最顶部多出一行白底条「服务收入 ¥9.11」+「查看明细 >」，属性区的三行变为「订单金额 ¥9.90 / 服务单来源抖音团购 / 核销时间」。

关键交互 —— ①点「查看明细 >」→ 服务收入的费用构成明细；②其余为只读展示。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。「服务收入」属结算金额，对技工的可见性同 TODO(REQ-SAL-012)。

需求关联 —— REQ-SAL-031 服务收入口径与 4.10 同源、REQ-SAL-028 核销即安装

本图是全 PRD 中一处关键的跨模块交叉点：订单金额 ¥9.90、服务收入 ¥9.11，差额 ¥0.79，费率 0.79 / 9.90 ≈ 7.98%。 4.10 财务与对账记录了同一笔样本，并指出该费率与任何一档已公布的渠道费率都对不上。本图给出了它的上游来源：这是一笔抖音团购的全车检测服务单，核销后由 O2O 直接计算出服务收入。也就是说，FIN 的收入明细与 SAL 的服务单详情读的是同一个数，两处必须同源，见 REQ-SAL-031。另：已安装状态多出「核销时间」字段，且核销时间与「全部」列表中该单的创建时间（2026-04-15 11:13:49）完全一致 —— 说明这类团购服务单是核销时才创建服务单，而非下单时创建。

服务单与 F6 工单的关系仍未完全定义：同一次施工在 O2O 有服务单、在 F6 有工单，两者是否需要关联、以哪一侧为准 —— TODO(REQ-SAL-014)。V1.1 已明确 O2O 内部「订单 vs 服务单」的分工（见 REQ-SAL-027），但 O2O 服务单 ↔ F6 工单的主从关系仍待架构裁决。这直接影响技工首页「当前施工队列」的数据源。

4.3.7 结算与延保跳转

十一、结算

结算页由 F6 开发。结算完成后，F6 需要添加一个按钮，跳转到「延保」。

页面内容 —— F6 三联屏：左屏「添加项目/材料」（搜索 + 扫码、多个品类页签，「换轮胎」页签下按规格列出适配轮胎推荐，每条含品牌型号、单价、门店库存与数量步进器），中屏「查看维修单」底部为「收款」，右屏「结算收银」为收款成功页且页面最底挂着一条第三方广告横幅。

关键交互 —— ①左屏按规格筛选适配轮胎，用步进器选数量 → 「加入维保单」；②「纠错」标签 → 反馈商品主数据错误；③中屏点「收款」→ 进入结算收银；④右屏「完成收款」结束流程，「查看历史收款 >」「查看未结清单据 >」进入对应列表。

可用角色 —— 店长 ✅；技工 ⚙️ 需授权。结算收银涉及全部金额字段，是 TODO(REQ-SAL-012) 最敏感的场景。

需求关联 —— REQ-SAL-007 页面由 F6 提供、REQ-SAL-011 结算后跳延保、REQ-SAL-024 F6 库存与价格、REQ-SAL-025 H5 容器模式

本图有三处关键发现：

F6 内置马牌轮胎商品库并能按规格推荐适配轮胎，但四条商品的价格全是 ¥0.00、门店库存全是 0 —— F6 的库存与价格没有和 ROOS / O2O 打通，这是痛点 2.3 进销存 / ERP 数据的直接实证。App 整合后开单页的轮胎材料应以 App 侧库存为准，见 REQ-SAL-024。

结算页底部有第三方金融产品广告横幅（网商银行「开通网商账户」），页面右上还有 F6 自己的首页与客服图标。这些内容会原封不动出现在马牌 App 里，属品牌与合规问题，须要求 F6 提供无广告、无自有导航的容器模式，见 REQ-SAL-025。

结算成功页上没有「延保」按钮 —— 印证正文所说「F6 需要添加一个按钮跳转到延保」确实是尚未开发的待办项，而不是已有能力。

另：按钮文案是「加入维保单」，而单据本身叫「维修单」，F6 内部命名不统一；App 侧透传时以实际单据名为准。

结算收银页：收款成功状态、收款信息（订单金额 / 应收金额 / 已收金额 / 未收金额）、备注、「完成收款」、「查看历史收款 >」「查看未结清单据 >」。

十二、延保

由结算页跳转至延保流程，见 4.5。跳转时应携带车牌、VIN、轮胎条码/DOT 等已录入信息，避免重复录入（这正是痛点 2.6 的核心诉求）。

跳转参数契约（F6 → App → 延保后台）未定义 —— TODO(REQ-SAL-011)。该契约须同时覆盖 V1.1 逐图核对发现的另外两条延保入口：接车页底部的「延保」按钮（见 REQ-SAL-016）与 O2O 已完成订单的「查看延保」（见 REQ-SAL-033）。

4.3.8 角色差异

店长：完整销售流程权限。

技工：如果技工被分配此项权限，其功能与店长一致。

金额类字段（商品总价、实收金额、待收金额）是否对技工屏蔽，与痛点 2.2「技工可查看门店财务数据」的诉求存在张力 —— 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

REQ-SAL-010 扫码核销 —— 核销码格式见 REQ-SAL-029、与订单状态的关系见 REQ-SAL-028、错误分类见 REQ-SAL-029；仅「重复核销与撤销核销的处理」仍待定 TODO(REQ-SAL-010)

REQ-SAL-011 结算后跳延保 —— F6 结算页增加跳转按钮；参数契约待定 TODO(REQ-SAL-011)，且须同时覆盖 REQ-SAL-016 与 REQ-SAL-033 的另外两条入口

REQ-SAL-012 技工金额可见性 —— 待定 TODO(REQ-SAL-012)；可行结论只有「完全不可见」与「完全可见」两种，理由见 4.3.8

REQ-SAL-013 订单渠道维度 —— ~~渠道清单是否可配置待定~~ V1.1 关闭：现状证明渠道会随平台合作变化且订单侧与服务单侧是两套不同枚举，必须后台可配置，见 REQ-SAL-036

REQ-SAL-014 服务单与工单关系 —— O2O 内部「订单 vs 服务单」的分工已明确（见 REQ-SAL-027）；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 延保）

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 中「四种」的表述）

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 财务与对账的收入明细必须来自同一个接口与同一套计算口径，两处数字不得出现差异。通道费 = 订单金额 − 服务收入，费率的取值依据见 4.10

REQ-SAL-032 订单标识须下发并展示 —— 「百亿补贴 / 达人带货 / 门店配送」三个订单标识决定结算费率（见 4.10 财务与对账），须作为订单字段下发，并在订单卡上直接展示，而不只作为筛选条件 —— 门店需要在接单时即可预判到手金额

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 验收标准

门店未接 F6 时，销售模块不展示历史工单、销售商机、检测开单、施工查车、结算等 F6 分区，且不产生报错弹窗；
扫码识别失败后可无损转入手工输码，已识别的部分信息不丢失；
F6 页面在 Embedded H5 中打开时，登录态与门店上下文自动透传，用户无需二次登录；
从 F6 结算页跳转延保时，车牌与 VIN 自动带入，无需重新录入；
同一交易流水号重复提交时，后端幂等处理，不产生重复单据；
切换门店后，订单列表与服务单列表只显示新门店的数据；
车牌 OCR 置信度低于阈值时，车牌以「待确认」态展示，且此时点击「新建工单」被拦截并提示先核对车牌（REQ-SAL-017）；
从接车页底部的「延保」按钮进入延保建单，带入的车牌与 VIN 与从 F6 结算页进入时完全一致（REQ-SAL-016）；
检测报告中经「批量通过」标记为正常的项，在报告上有明确区分标识，且后台可查到操作人与批量项数（REQ-SAL-021）；
在 App 内打开 F6 结算页时，页面不出现第三方广告横幅，也不出现 F6 自有的首页 / 客服图标（REQ-SAL-025）；
订单列表与服务单列表中车主手机号均以脱敏形式展示，点击拨号可正常接通且剪贴板中不出现完整号码（REQ-SAL-026）；
分别输入 LP / AMAP / DY / 纯数字四种格式的核销码均能正确路由校验；输入已核销的码时提示「该订单已核销」而非通用失败（REQ-SAL-029）；
核销成功后，服务单状态由「待安装」变为「已安装」并写入核销时间，无需再执行任何标记动作（REQ-SAL-028）；
待接单订单的金额显示为「—」，订单完成后显示真实金额（REQ-SAL-030）；
服务单详情的「服务收入」与财务模块收入明细中同一笔单的金额完全一致（REQ-SAL-031）；
后台新增一个订单渠道后，App 的渠道 tab 无需发版即可展示（REQ-SAL-036）；
接车时若该车有待服务的 O2O 订单，接车页出现高亮提示并可一键跳转到该订单（REQ-SAL-037）。

4.4 提醒

承接方式已定：提醒能力由 F6 承载，App 不做原生实现，以 Embedded H5 容器嵌入 F6 现有提醒页，能正常展示与操作即可。提醒规则、提醒单生成与跟进逻辑全部留在 F6 侧，App 只负责入口、换票鉴权与容器能力。方案取舍见 4.4.5。

本模块现状分三步：设置提醒规则 → 生成提醒单 → 跟进提醒单，分别对应 4.4.2–4.4.4。三步均由 F6 实现，以下小节记录其现状形态 —— 这既是 App 嵌入后用户实际看到的内容，也是后续若要原生化时的需求底稿。

4.4.1 需求描述

业务目标 —— 基于车辆保养周期、保险到期、检测异常等规则自动生成提醒单，由服务顾问跟进转化，提升复购与到店率，支撑痛点 2.4 的「客户分层营销」诉求

目标角色 —— 店长；技工是否开放入口待定 TODO(REQ-RMD-005)

入口 —— App 内提醒入口，具体位置随导航方案确定（见导航收敛与角色化配置）；点击后进入 Embedded H5 容器加载 F6 提醒页

前置条件 —— 门店已接入 F6；已有车辆与消费历史数据

页面内容 —— 由 F6 页面提供，App 侧不另行定义；现状形态见 4.4.2–4.4.4

主流程：

设置提醒规则
车主到店消费
车主完工离店
生成提醒单并跟进
临近服务日提醒车主（可自动发短信/微信）
车主再次到店

异常流程：

门店未接入 F6 → 提醒入口不显示，见门店能力开关
F6 提醒页白屏 / 加载超时 / 票据过期 → 由 Embedded H5 容器统一处理，见 7.3
车主手机号缺失 → 无法发送短信/微信，仅支持电话提醒（F6 页面行为）
短信额度不足 → 提示「未购短信，无法分享」并提供购买入口（F6 页面行为）

业务规则 —— 见 4.4.6

权限规则 —— 页面内的规则配置与跟进权限由 F6 自行控制；App 侧只决定入口对哪些角色可见 TODO(REQ-RMD-005)

访问链路 —— App → Embedded H5 容器 → App Backend 换票下发 URL → F6 提醒页（不传裸 URL，见 7.3）

逻辑数据来源 —— F6（规则、提醒单、车辆与消费历史）

回写目标 —— 无。跟进动作（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交）在 F6 页面内完成并由 F6 自行落库，App 不做回写

状态变化 —— 提醒单：未处理 → 我未完成 / 我已完成 → 所有已完成（状态机由 F6 维护）

验收标准 —— 见 4.4.7

4.4.2 设置提醒规则

页面内容 —— F6 PC 端「客情维护 > 商机设置 > 服务提醒」页（顶部叠加的流程条在第 ① 步），左侧为 F6 主导航，右侧「商机规则设置」区含八个规则类别 tab、保养 / 洗美子 tab 与一张规则表格，表格右侧「操作」列被截断并出现横向滚动条 —— PC 版式在窄容器内的实际表现。

关键交互 —— ①切换八个规则类别 tab；②切换保养 / 洗美子 tab；③行末「修改」→ 编辑该条规则；④「状态」列开关 → 启用 / 停用该规则（图中橙色为启用、灰色为停用）；⑤「+ 添加保养提醒规则」→ 新增，上限 20 条（REQ-RMD-002）；⑥横向滚动查看被截断的列。

可用角色 —— 店长 ✅（设置提醒规则属门店管理职能）；技工 ✗。页面内权限由 F6 自行控制，App 只控入口可见性 TODO(REQ-RMD-005)。

需求关联 —— REQ-RMD-002 规则数量上限、REQ-RMD-003 自动提醒开关、REQ-RMD-007（本图的横向滚动即「PC 版式展示降级」的直接证据）

规则分八类（tab）：服务提醒 / 车险到期提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保提醒。最多可自定义 20 个提醒规则。

服务提醒下分「保养提醒」与「洗美提醒」，按项目设置服务周期。保养提醒规则表字段：

字段	说明	示例
提醒类别	规则名称，可标「推荐」	小保养、空气滤清器、火花塞、变速箱油、刹车油、发动机清洗、油底壳螺丝、防冻冷却液、轮胎
包含项目	触发该提醒的业务项目	工单业务分类：保养；更换空气滤清器·保养工时费
是否根据保养手册	是 / 否
提醒单生成日	相对下次服务日的提前量	下次服务日前 30 天 / 15 天 / 7 天 / 60 天 / 10 天 / 23 天
提醒单处理人	责任人角色	工单服务顾问 / 公司统一处理人 / 无处理人
是否自动提醒	是 / 否
状态	启用 / 停用开关
操作	修改

保养提醒规则字段

系统预置规则基于常见保养提醒周期，建议开启后不删除；开启时若提醒包含项目有云项目，会自动下载云项目至本地。

4.4.3 生成提醒单

页面内容 —— F6 PC 端「服务提醒 > 我未完成」页（流程条在第 ② 步），顶部是两个按八类规则分列的计数看板（待我处理 0 / 所有未处理 8100），其下依次为八类 tab、四个状态 tab、搜索筛选行与提醒单表格（共 1939 条），本图为测试门店数据（客户姓名含「测试111」、手机号含 12123456789 等非法号码）。

关键交互 —— ①切换八类 tab / 四个状态 tab → 过滤列表；②行首勾选框多选 → 对选中项批量执行；③「电话提醒」→ 外呼（App 内经容器 dial 桥接，见验收标准）；④「发送短信」/「发送微信」→ 手动触达；⑤「完成」→ 关单；⑥「转交」→ 移交他人；⑦「列设置」→ 自定义显示列；⑧「更多筛选」/「设为常用」→ 条件筛选与常用条件保存。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RMD-005)。⚠️ 与 REQ-ACC-006 一致，该项关闭前按更严格一侧实现（技工不可见）。

需求关联 —— REQ-RMD-001 承接方式、REQ-RMD-003 自动提醒、REQ-RMD-006 短信额度

页面构成：

顶部双看板：「待我处理的提醒单」与「所有未处理的提醒单」，各按八类规则分列计数；
八类 tab（服务提醒 / 保险提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保）；
流程条：①设置提醒规则 → ②车主到店消费 → ③车主完工离店 → ④生成提醒单并跟进 → ⑤临近服务日，提醒车主（可自动发送短信微信）→ ⑥车主再次到店；
状态 tab：我未完成 / 我已完成 / 所有未完成 / 所有已完成；
提醒单列表字段：提醒单号、客户姓名、手机号、车牌号、上次服务门店、上次服务日期、提醒类别、提醒来源、关联单号；
操作区：操作 / 电话提醒 / 发送短信 / 发送微信 / 完成 / 转交 / 列设置。

4.4.4 跟进提醒单

页面内容 —— 与上一张是同一个 F6 页面（同一份表格、同一批数据），区别只是流程条高亮在第 ③ 步并另加了两个 PPT 标注框，图左下角还残留德文占位文字 Individueller Informationsbereich，说明本图取自 PPT 模板。

关键交互 —— 无新增交互。跟进动作就是上一张图中列表上方的那排按钮（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交），「跟进提醒单」不是一个独立页面。

可用角色 —— 同 4.4.3：店长 ✅；技工 ❓ TODO(REQ-RMD-005)。

需求关联 —— REQ-RMD-003 自动提醒、REQ-RMD-006 短信额度。本图主要作跟进手段的分类佐证，不引入新页面需求。

本图澄清了一处结构误解：V1.0 把 4.4.3「生成提醒单」与 4.4.4「跟进提醒单」写成两节，容易读成两个页面。实际上 F6 侧只有一个列表页，「生成」是系统按规则自动产出提醒单，「跟进」是人在同一个列表上执行操作。App 以 Embedded H5 嵌入时，这两节对应同一个 URL。

跟进手段四类：

SA 发券 —— 服务顾问向车主发放优惠券；
SA 电话跟进 —— 通过列表「电话提醒」直接外呼；
SA 主动发短信提醒 —— 手动触发短信/微信；
临近服务期系统自动发送短信提醒 —— 由规则的「是否自动提醒」开关驱动。

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 的待办、消息或首页看板，也不参与弱网与离线策略；页面内的一切行为都是 F6 的行为。

4.4.6 业务规则

REQ-RMD-001 承接方式 —— 已定：以 Embedded H5 嵌入 F6 现有提醒页，App 不做原生实现，见 4.4.5

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

4.4.7 验收标准

门店未接入 F6 时，提醒入口不显示；
从提醒入口进入后，F6 提醒页正常加载，登录态与门店上下文自动带入，不出现二次登录；
票据过期时容器自动换票并重载，用户无感知；
页面内「电话提醒」可调起系统拨号盘（经容器的 dial 桥接能力，见 7.3）；
切换门店或退出登录后，已打开的提醒页立即失效并关闭。

4.5 延保

4.5.1 保障产品与责任边界

业务目标：明确延保产品的保障范围与责任边界，避免门店与消费者对「什么该走原厂质保、什么该走延保」产生争议。

双保障并行生效：原厂质量质保与「1 年撞击延保」互不替代、并行存在。制造缺陷应进入原厂基础质保；外力撞击导致的胎侧鼓包、爆胎等应进入撞击延保换新。

延保协议与零售商使用条款：支持查看保单协议，以及零售商延保使用条款、违规处理等规则，并留存同意条款时间。

页面内容 —— 「文件预览」容器里打开的《延保服务政策》PDF 长文，内容为保障范围与不予保障的 15 种情形。

关键交互 —— ①上下滚动翻阅，跨页连续；②无任何可点控件，纯阅读页。

可用角色 —— 店长 ✅、技工 ✅（只读）。

需求关联 —— REQ-WTY-001 双保障并行、REQ-WTY-036 PDF 预览与密级标识

三处细节值得注意：①这是以 PDF 文件预览器打开的，不是原生页面，App 侧需要原生 PDF 容器能力；②文档页脚带 Continental 的密级标识「Public」，属公司文档规范，展示时不得裁剪；③政策正文写明了两个品牌的生效起点 —— 美国将军轮胎 UC7/CC7/SC7 自 2022 年 9 月 1 日起、维京轮胎自 2020 年 11 月 1 日起，这是 REQ-WTY-031 品牌枚举的业务依据。

页面内容 —— 深色主题的两页式条款页，当前是第一页「使用条款」，顶部带本账户的同意时间戳。

关键交互 —— ①顶部两段式进度条显示「使用条款 → 违规处理」两页，点底部橙色「下一页」翻到第二页；②灰底提示行「本账户于 2026.03.18 14:57 同意本条款」为只读留痕，不可点。

可用角色 —— 店长 ✅、技工 ✅（只读查看）；同意动作记录操作人。

需求关联 —— REQ-WTY-010 条款同意留痕、REQ-WTY-035 两页式与留痕字段

REQ-WTY-010 在现状已实现 —— 同意时间戳精确到分钟并展示在页面顶部。但两点须补：①条款是两页（使用条款 + 违规处理），须两页读完才可同意；②留痕只有时间，没有条款版本号，也没有操作人（现状延保侧拿不到真实员工身份，见 REQ-WTY-015）。见 REQ-WTY-035。

目标角色 —— 店长、技工（只读查看）

入口 —— 延保 tab 首页顶部「零售商延保使用条款须知」；保单详情页「保单协议」

权限规则 —— 全角色可见；同意动作记录操作人

数据来源 —— 延保后台

回写目标 —— 条款同意时间戳回写延保后台

4.5.2 消费者激活与门店建单

业务目标：把延保建单从「独立小程序里重新录一遍」变成销售流程的自然延续，解决痛点 2.6。

页面内容 —— App 目标形态的延保服务首页：门店选择器 + 两个待办计数卡 + 「立刻延保」车牌录入区 + 保单管理 / 理赔处理双入口。

关键交互 —— ①点门店名右侧 ▼ → 切换操作门店；②点右上橙色耳机 → 延保客服；③点「零售商延保使用条款须知 >」→ 条款页；④点两个计数卡 → 各自的待办列表；⑤点橙色「扫描车牌」→ 拍照识别；⑥或在车牌格子逐位输入，点绿色「+新能源」在 7 位/8 位车牌间切换；⑦车牌未填满时「下一步」为禁用态；⑧点「切换特殊车牌录入」→ 换成自由文本输入模式；⑨底部「保单管理」「理赔处理」两个入口。

可用角色 —— 店长 ✅ 全量；技工 ❓ 建单权限待定 TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-037 车牌录入的两种模式、REQ-WTY-028 待办归并

设计稿有两处与现状不符，须在设计评审时修正：①「切换特殊车牌录入」带外链图标 ↗，暗示跳出到别的页面，但现状是同页切换输入控件（车牌格子 ⇄ 自由输入框），见 REQ-WTY-037；②门店选择器与客服入口都放在延保页内，而按 REQ-HOM-001 门店上下文应收敛到 App 全局，延保内不再单设切店入口。

设计稿延保服务页构成：门店选择器（门店名 + 门店编码）+ 客服入口 → 「零售商延保使用条款须知」→ 待绑定车辆 / 待补充装车视频双计数卡 → 立刻延保（扫描车牌主按钮 / 或手动录入车牌，车牌格子含「新能源」标记，「下一步」，「切换特殊车牌录入」）→ 保单管理 / 理赔处理双入口。

消费者延保激活链路：消费者需通过「大陆马牌轮胎服务」公众号进入「延保换新 | 消费者端」，以手机号注册，上传驾驶证认证，添加车辆并上传行驶证，录入轮胎条码 / DOT 和购买凭证，确认激活。

该链路在消费者侧完成，不在本 APP 范围内，但门店端的「待绑定车辆」「待补充装车视频」待办正是由该链路的未完成状态产生。

门店端立即延保建单：首页提供「立即延保」入口，门店扫描或录入车牌后进入下一步，为消费者建立 / 承接延保业务。

车牌识别与特殊车牌兼容：支持拍摄车牌进行识别；识别失败或特殊车牌场景下可切换普通车牌手动输入。

页面内容 —— 「拍摄车牌」相机页，橙色取景框 + 底部快门按钮，框内是拍摄时误对准键盘的测试画面。

关键交互 —— ①对准车牌点底部橙色快门 → 拍照并上传识别；②点中部横条「使用手动输入车牌 >」→ 转手工录入。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-037 车牌录入的模式与文案配色

确认了识别方式：有快门按钮，说明是拍照上传识别而非实时视频流识别，与销售模块 REQ-SAL-002 的口径一致，两处应复用同一套 OCR 能力。两处 UI 问题：①提示文案写「请将黄色取景框对准车牌」，而实际取景框是橙色；②「使用手动输入车牌」用了红色按钮，红色在本 App 中是危险操作色（如「作废保单」），此处语义不符。均见 REQ-WTY-037。

页面内容 —— 延保小程序首页处于「特殊车牌录入」模式时的样子，车牌格子已换成一个自由文本输入框。

关键交互 —— ①点橙色「扫描车牌」→ 拍照识别；②在「输入车牌号码」框内自由输入，不受 7/8 位格子约束；③点橙色文字「切换普通车牌录入」→ 切回车牌格子模式；④点顶部两个计数「0 >」→ 各自的待办列表；⑤点右下绿色悬浮胶囊「延保客服」→ 客服会话；⑥底部 tab 五项：首页 / 工作台 / 中间橙色圆形图标 / 待办事项 / 我的。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-037 两种录入模式为同页切换、REQ-WTY-028 待办归并

本图证明普通 / 特殊车牌是同页切换控件，不是两个页面 —— 普通模式用车牌格子（逐位约束），特殊模式用自由输入框（不做位数校验），两者用一个橙色文字链互切。设计稿把它画成外链跳转是错的，见 REQ-WTY-037。另有三点：①底部 tab 中间那个橙色圆形指南针图标没有文字标签，其功能本图无法确认；②「延保客服」用了绿色悬浮胶囊，在这套深色 + 橙色主题里是唯一的绿色元素，疑为跳转微信客服；③顶部条款提示条压在系统状态栏上，属遮挡。

待办驱动的激活完善：将未完成业务拆为「待绑定车辆」和「待补充装车视频」，并可在待办页按待处理 / 已完成状态查询。

页面内容 —— 「待绑定车辆 / 待补充装车视频」两 tab 的待办列表页，当前是待绑定车辆的空态。

关键交互 —— ①切换顶部两个 tab；②切换「待绑定 / 已完成」两个状态胶囊；③在「搜索车牌号」框内检索。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-028 延保内两套待办的归并

页面内容 —— 与上一张完全相同（同一时刻、同一 tab、同一空态），未拍到「待补充装车视频」tab 的实际内容。

关键交互 —— 同上一张，无新增。

可用角色 —— 同上一张。

需求关联 —— REQ-WTY-028 延保内两套待办的归并

这两张图是同一张截图 —— 附录 C 第 6、7 行分别指向两个文件，但两个文件的内容逐像素一致（均为 16:47、5G 88%、选中「待绑定车辆」tab、空态）。「待补充装车视频」tab 的实际内容至今没有任何佐证，而它恰恰是首页待办里唯一被列入 App 跨系统待办的延保事项。建议优先补拍。

页面内容 —— 延保小程序底部 tab「待办事项」页的空态，页面仅有标题与「暂无待办事项」占位。

关键交互 —— 无交互，空态页。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-028 延保内两套待办的归并

延保小程序内部就已经有两套待办 —— 首页的「待绑定车辆 / 待补充装车视频」两个计数卡有自己的列表页（上两张图），而底部 tab 的「待办事项」是另一个独立页面。两者是否同源、为何并存，本图无法确认。这使 TODO(REQ-WTY-002) 的归并问题比原文描述的更复杂 —— 要归并的不是「延保待办 vs 首页待办」两套，而是三套。见 REQ-WTY-028。

延保的「待办事项」是独立 tab，与 App 首页待办存在归并关系：延保视频上传提醒已列入首页跨系统待办。归并后延保 tab 内是否保留独立待办页 —— TODO(REQ-WTY-002)。

门店切换：用户可在首页和工作台选择当前操作门店，保证建单、查询、返利等数据归属于正确门店。

页面内容 —— 从首页调起的「选择操作店铺」弹层，列表中只有一个门店。

关键交互 —— ①点门店行选中并关闭弹层；②点右上「✕ 关闭」取消。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-HOM-001 全局门店上下文（整合后本入口取消）

该测试账号只绑一个门店，因此弹层没有搜索框，也看不出多门店时的排序与置顶规则。4.8 我的的切换门店页有搜索且当前门店置顶，两处口径须统一到全局门店上下文。

页面内容 —— 从工作台调起的同一个「选择操作店铺」弹层，遮罩下可见工作台的六宫格与延保数据卡。

关键交互 —— 与上一张完全一致，是同一个组件。

可用角色 —— 同上一张。

需求关联 —— REQ-HOM-001 全局门店上下文（整合后本入口取消）

两张图佐证的是同一个弹层组件挂在两个入口下（首页 + 工作台）。正文原写「用户可在首页和工作台选择当前操作门店」，本次确认二者共用同一组件，整合后两个入口一并取消。

整合后门店切换收敛到 App 全局门店上下文（REQ-HOM-001），延保内不再单独提供切店入口。

4.5.3 保单与延保生命周期管理

业务目标：提供保单的全量查询、状态跟踪与生命周期操作，替代跨平台查保单的现状。

页面内容 —— App 目标形态的保单管理页：搜索框 + 四个分组胶囊 + 保单卡列表。

关键交互 —— ①搜索框检索；②切换「全部 / 正常保单 / 待补充保单 / 待确认保单」四个胶囊；③点卡片右下「详情 >」→ 保单详情；④卡右上角状态胶囊为只读标识。

可用角色 —— 店长 ✅；技工 ❓ 保单查询权限待定 TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-012 字段命名、REQ-WTY-013 一车四胎、REQ-WTY-014 保障类型枚举、REQ-WTY-011 状态机

本设计稿有四处必须修正的问题：

POLICY NO. 标错了字段 —— 卡片主号 8507302611 在现状里是轮胎条码，真正的保单号是 15 位的「保单子代码」（如 173147928125200）。见 REQ-WTY-012。

「数包保障」是「鼓包保障」的错别字 —— 现状小程序写的是「鼓包保障」。见 REQ-WTY-014。

三条示例数据的保单号与车牌完全相同、状态却不同 —— 现状是「一车四胎、一胎一保单」，同一车牌下应是四个不同的轮胎条码。见 REQ-WTY-013。

状态色与语义错配 —— 正常=橙、待确认=绿、待补充=红；按通行约定应为正常=绿、待确认=橙、待补充=红。

另：设计稿的状态胶囊（正常/待确认/待补充）是对现状的增强 —— 现状列表卡没有状态标识，只能靠切 tab 区分，这个改进值得保留。

保单全量查询与搜索：按车牌或轮胎条码搜索全部保单，并按全部、正常保单、待补充保单、待确认保单分组查看。

页面内容 —— 深色的「所有保单」列表，5 条记录均带「鼓包保障 / 爆胎保障」双标签，底部固定筛选条。

关键交互 —— ①搜索框支持车牌号或条码两种检索；②切换「全部 / 正常保单 / 待补充保单 / 待确认保单」四个平铺 tab；③点任意行 > → 保单详情；④点底部「筛选 | 已筛选 >」→ 筛选弹层。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-012 字段命名、REQ-WTY-013 一车四胎、REQ-WTY-009 保单筛选

本图给出了保单数据结构的关键事实：豫AQ27Z3 一个车牌下有 4 条不同编号的记录（8507302611 / 8506983288 / 8507302660 / 8505665909），时间都是 2024.11.13 14:16 —— 这是一车四胎、每条胎一条记录，而列表主号是轮胎条码不是保单号。见 REQ-WTY-013、REQ-WTY-012。另：底部「已筛选」是橙色，说明当前列表带着生效中的筛选条件，不是全量；现状卡片没有状态标识，设计稿的状态胶囊是新增能力。

保单状态、标签和安装留痕：显示保单子代码、保单类型、轮胎条码、轮胎规格、保障状态、安装门店、安装时间、安装城市及安装店员。

页面内容 —— 单个保单子代码的详情页，分「保单基础信息 / 保单状态信息 / 安装信息」三段。

关键交互 —— 无交互，纯信息展示页。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-012 字段命名、REQ-WTY-015 安装店员须为真实身份

这张图澄清了保单的字段结构：保单子代码 173147928125203（15 位）才是保单主键，8507302611 的字段名明确写作「轮胎条码」，「轮胎描述」是规格串 215/55R17 94W FR UC7 #。列表页与设计稿把轮胎条码当保单号展示，须更正，见 REQ-WTY-012。 「安装店员」显示「微信用户」，不是真实姓名 —— 正文把安装店员列为留痕字段，但现状拿不到员工身份。这直接架空了 REQ-WTY-005 保单作废的审计要求（不知道是谁操作的），见 REQ-WTY-015。

延保详细信息管理：集中展示轮胎规格、保单号、投保车辆、VIN、投保人、保单有效期及保单状态；关联系统流水，如「新胎激活」「用户核保」等。

保单作废：门店具备作废保单的操作入口，应配合权限、状态校验和审计记录控制使用。

页面内容 —— 保单详情页下半部分：三条系统流水 + 空的活动信息区，底部是常驻的红色「作废保单」。

关键交互 —— ①点分区右侧「^ 收起」折叠「保单信息 / 活动信息」；②点任一条流水的 > → 该笔流水详情；③点底部红色「作废保单」→ 作废流程。

可用角色 —— 店长 🔸 受限（高风险）；技工 ✗ 无权限 TODO(REQ-WTY-005)。

需求关联 —— REQ-WTY-016 作废的状态校验与二次确认、REQ-WTY-017 流水排序与事件枚举

两处必须修正的问题：

该保单状态已是「延保已过有效期」，「作废保单」按钮仍然可点 —— 现状没有任何状态校验，也没看到二次确认。正文 REQ-WTY-005 要求「权限 + 状态校验 + 审计记录」，现状三样都缺。见 REQ-WTY-016。

三条流水的排序无规律 —— 依次是 14:16 爆胎保障 / 14:21 用户核保 / 14:16 新胎激活，既非正序也非倒序。按业务发生顺序应为新胎激活 → 爆胎保障 → 用户核保。见 REQ-WTY-017。

另：「用户核保」那条没有门店信息（因为是消费者侧动作），说明流水混合了门店端与消费者端两类事件。

页面内容 —— 保单详情页上半部分：橙色轮胎卡 + 「延保信息」字段区，底部同样常驻红色「作废保单」。

关键交互 —— ①三处「复制」按钮（轮胎条码 / 保单号 / 投保车辆车牌）；②点「保单协议 >」→ PDF 预览；③点「^ 收起」折叠分区。

可用角色 —— 店长 ✅ 查看 / 🔸 作废；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-011 状态机补「已过有效期」、REQ-WTY-012 字段命名、REQ-WTY-015 投保人身份

本图暴露了保单状态机的缺口：保单有效期 2025.11.14、保单状态「延保已过有效期」—— 而正文 4.5.8 声明的状态机是「待补充 → 待确认 → 正常 → 已作废」，根本没有这一态。见 REQ-WTY-011。另两点：①保单号 173147928125200 与上一张图的保单子代码 173147928125203 只差末位 —— 同一条轮胎下有多个子代码，分别对应「鼓包保障」与「爆胎保障」两种保障，印证 REQ-WTY-013 的三层结构；②投保人显示「微信用户」，与安装店员同样是兜底值，见 REQ-WTY-015。

保单作废是不可逆的高风险操作。作废权限归属（是否限店长）、是否需要二次确认与作废原因、是否需要后台审批 —— TODO(REQ-WTY-005)。V1.1 已明确其中的状态校验与原因留痕要求，见 REQ-WTY-016。

保单筛选：支持按激活起止日期、轮胎品牌筛选保单；品牌可选全部、马牌轮胎、维京轮胎。

页面内容 —— 保单筛选弹层，上方压着一整块黄色的「消费者未认证」提醒卡。

关键交互 —— ①点激活开始 / 结束日期 > → 日期滚轮；②点「选择品牌 >」→ 品牌滚轮；③「清除条件」（红色描边）重置，「确认筛选条件」（橙色）应用；④「✕ 关闭」取消。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-009 保单筛选、REQ-WTY-008 消费者未认证兼容

黄色提醒卡是正文「消费者认证状态兼容」的原文出处，并补充了两个正文没写的细节：新老系统切换点是 2020 年 8 月 24 日 7 点，且消费者找回保单的方式是「在新系统扫描两证」（驾驶证 + 行驶证）。注意 筛选的激活开始日期默认就是 2020-08-24 —— 即默认筛选已排除老系统保单，这与提醒卡的说明是同一件事的两面。一处 UI 问题：「清除条件」用了红色描边，与「作废保单」同色，但两者风险等级完全不同。

页面内容 —— 同一筛选弹层下方升起的微信原生日期滚轮（年 / 月 / 日三列）。

关键交互 —— ①三列滚轮各自滑动选值；②「取消」放弃，绿色「确定」回填到筛选项。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-038 统一选择器

白底 + 绿色确定按钮的微信原生 picker，压在深色页面上，视觉断裂明显。 这是小程序无法改写原生组件主题的典型代价，本模块共 4 张截图出现同一问题（日期 ×2、品牌 ×2）。App 自研后可统一，见 REQ-WTY-038。

页面内容 —— 同一筛选弹层的品牌滚轮，三项：全部 / 马牌轮胎（选中）/ 维京轮胎。

关键交互 —— ①滚动选择品牌；②「取消 / 确定」。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-009 保单筛选、REQ-WTY-031 品牌枚举统一

品牌三项与 REQ-WTY-009 一致 ✓。但本模块内品牌枚举出现了三种不同写法：此处 3 项（全部/马牌轮胎/维京轮胎）、工作台指标用「马 / 维」单字缩写、返利中心筛选只有 2 项且没有「全部」。见 REQ-WTY-031。

消费者认证状态兼容：历史保单可能显示「消费者未认证」，页面提示该状态不影响延保返利及管理端查询；消费者后续在新系统扫码可找回保单。

销售流程内查看延保：O2O 侧亦提供「查看延保」入口，与销售流程中的延保历史记录同源。

页面内容 —— O2O 侧的「查看延保」页（浅色），顶部是订单与延保的比对汇总，下方按轮胎逐条列出延保状态。

关键交互 —— ①无操作按钮，纯查询页；②粉色顶条为风险提示，橙色行为数据审核状态提示。

可用角色 —— 店长 ✅；技工 ⚙️ 需被授权（沿用销售模块的订单权限）。

需求关联 —— REQ-WTY-018 两段式生效、REQ-WTY-019 状态收敛、REQ-SAL-033 O2O 侧延保入口

本图是全模块信息量最大的一张，暴露了三处状态自相矛盾：

每张卡的标题写「暂无延保信息」，但卡内又同时显示「✅ 激活成功」和「🔄 用户未确认」——三个状态互相打架。

顶部汇总写「订单轮胎数：4，延保成功轮胎数：0」，而下方 4 条全部显示「激活成功」——计数与明细对不上。

还叠加了一条「订单数据审核中，请稍后查询」。

但矛盾之下藏着一条正文完全没记录的核心业务规则：「激活成功」与「用户未确认」并存，说明延保生效是两段式的 —— 门店激活之后还需消费者确认，只有两者都完成才计入「延保成功」。这解释了为什么 4 条激活成功却统计为 0。见 REQ-WTY-018、REQ-WTY-019。

另：第 3 条轮胎规格 255/45R19 与前两条 235/55R20 不同，属前后轮不同规格的正常情况；门店名「智慧园杀虫轮胎店」是脏数据。

4.5.4 预约与理赔运营

业务目标：把预约车检与理赔受理的跟进从多平台查询收敛到门店端一处。

预约车检管理：按车牌搜索预约，按「预约车检、已受理、已上报」跟踪预约处理状态。

页面内容 —— 「预约信息」列表的「预约车检」页签，三条预约记录。

关键交互 —— ①切换顶部「预约信息 / 提交的理赔信息」两个 tab；②切换「预约车检 / 已受理 / 已上报」三个状态胶囊；③搜索框按车牌号检索；④点任一行 > → 预约详情。

可用角色 —— 店长 ✅；技工 ❓ 理赔受理权限待定 TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-020 入口收敛、REQ-WTY-022 三类案件状态机、REQ-WTY-023 CATI 归属

每条预约都带一个「CATI预约：<日期>」字段 —— 这是回答 TODO(REQ-WTY-006) 的关键证据：预约车检本质就是预约 CATI 检测，预约、理赔、CATI 是同一条业务链上的三个环节，不是三套独立业务。见 REQ-WTY-023。另：预约序列号统一为 TI 前缀 + 7 位数字（TI0000657）；申请时间与 CATI 预约日期可以是同一天，也可相隔数日。

页面内容 —— 同一列表切到「已受理」页签，为空。

关键交互 —— 同上一张，无新增。

可用角色 —— 同上一张。

需求关联 —— REQ-WTY-022 三类案件状态机、REQ-WTY-030 空态统一

「已受理」为空，因此已受理状态下的卡片长什么样、比预约车检多哪些字段，本图无法确认。另：本模块的空态至少有三种写法 —— 待办列表用插画 +「暂无数据」、本页用纯文字「没有更多了」、理赔管理页用虚线框 +「暂无预约记录」。见 REQ-WTY-030。

预约详情与订单凭证：记录车辆同步问题、申请时间、申请人、脱敏手机号、预约序列号、预约检测时间、订单编号及订单 / 确认图片。

页面内容 —— 预约详情页，分「基础信息 / 预约时间 / 订单信息」三段。

关键交互 —— 无交互，纯信息展示页。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-025 脱敏格式统一

三处发现：

手机号脱敏为 *******3963（7 星 + 后四位），而 4.8 我的用的是 138****7616（前三 + 四星 + 后四）。全 App 脱敏格式不统一，且此处的申请人姓名「王磊」是消费者姓名、完全未脱敏。见 REQ-WTY-025。

字段名「车主同步问题」，值是「抖动」 —— 从值可判断这是消费者反馈的故障现象，字段名疑为「反馈问题」之误。

「订单图片」「订单确认图片」两栏都是空的 —— 正文把它们列为记录项，但无图可看，其展示形式（缩略图 / 点击放大 / 几张）本图无法确认。

延保理赔受理：支持扫描消费者延保理赔码进入处理，并支持按车牌号或条码搜索，分别查看进行中和已完成案件。

页面内容 —— 「理赔管理」页的「延保理赔」tab，顶部是「临近预约」提醒卡，下方是案件列表（空）。

关键交互 —— ①点提醒卡底部橙色「全部预约」→ 预约列表页；②切换「延保理赔 / 售后鉴定 / CATI理赔」三个 tab；③搜索框支持车牌号或条码；④切换「正在进行 / 已完成」两个状态胶囊。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-021 临近预约并入待办、REQ-WTY-020 入口收敛、REQ-WTY-022 状态机

顶部的「临近预约（未来3天内的预约）」是一个正文完全没提的主动提醒机制。 它与 4.4 提醒、App 首页待办是同一类东西 —— 门店需要在预约日前被提醒备料备人。整合后应并入首页跨系统待办，见 REQ-WTY-021。另：「全部预约」的入口挂在这张卡的底部，即预约列表是理赔管理的下级页面，而不是平级功能。

页面内容 —— 极简的「理赔处理」页，只有「延保理赔」扫码卡与「售后鉴定 >」两个入口。

关键交互 —— ①点橙色「扫描消费者的延保理赔码」→ 相机扫码；②点「售后鉴定 >」→ 售后鉴定页。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-020 入口收敛

理赔码由消费者出示、门店扫 —— 与销售模块的核销码是同一种交互模型。「理赔处理」页与「理赔管理」页是两个不同的页面（前者是发起入口，后者是案件跟踪），但命名极为接近，门店容易混淆。页面下方还有一块几乎不可见的深色文字，本图无法确认其内容（疑为扫码失败时的手动输入提示）。

预约码手动录入：当扫码不可用时，可人工输入预约码进行匹配和受理。

页面内容 —— 「输入预约码」弹层，单输入框 + 橙色「确认」。

关键交互 —— ①键入预约码；②点「确认」提交匹配；③「✕ 关闭」取消。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-020 入口收敛

两点：①该弹层是从「售后鉴定」页调起的（遮罩下可见售后鉴定页），不是从理赔处理页；②输入框没有格式提示，而预约序列号现状为 TI + 7 位数字，应在占位文案里给出样例，并做前缀校验。

提交理赔信息跟踪：理赔信息按正在进行、已完成分组展示，便于门店持续跟进处理结果。

页面内容 —— 「预约信息 / 提交的理赔信息」两 tab 中的第二个，为空。

关键交互 —— ①切换两个顶部 tab；②切换「正在进行 / 已完成」；③搜索框按车牌号检索。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-020 入口收敛

本页与「理赔管理 > 延保理赔」tab 的结构完全相同（都是搜索 + 正在进行/已完成 + 列表），两处是否为同一份数据本图无法确认。这是入口冗余最直接的证据 —— 同一批理赔案件至少有两个查看路径，见 REQ-WTY-020。

CATI 理赔分流：理赔管理中独立提供 CATI 理赔入口，与延保理赔和售后鉴定并列管理。

页面内容 —— 「理赔管理」页切到「CATI理赔」tab，结构与「延保理赔」tab 完全一致。

关键交互 —— 同「延保理赔」tab，无新增。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-022 状态机、REQ-WTY-023 CATI 归属

三个 tab 共用同一套页面结构，只是数据源不同。但状态机不同：延保理赔与 CATI理赔是两态（正在进行 / 已完成），售后鉴定是三态（多一个「待上传」），见 REQ-WTY-022。

页面内容 —— O2O 侧的 CATI 页，是一个门店资质的开通状态页，底部按钮为「关闭服务」。

关键交互 —— ①滚动阅读 CATI 说明文字；②点底部橙色「关闭服务」→ 关闭本门店的 CATI 资质。

可用角色 —— 店长 ✅（属门店资质管理）；技工 ✗。

需求关联 —— REQ-WTY-023 CATI 的两个面（关闭 TODO(REQ-WTY-006)）、REQ-WTY-024 文案脏数据

本图回答了 TODO(REQ-WTY-006)。 底部按钮是「关闭服务」，说明 O2O 侧的 CATI 是门店资质的开通 / 关闭开关，而延保侧的 CATI 是理赔案件的跟踪列表 —— 两者不是重复功能，而是同一项资质的两个面：资质开关归 4.9 门店管理，案件跟踪归本模块。见 REQ-WTY-023。另两处必须处理：①说明文案是脏数据 —— 同一段介绍重复了 4 遍，每遍后面还跟着一行测试串「xxx特热爱1111…」，上线前须由业务重新提供；②「关闭服务」会使门店失去 CATI 资质，属高风险操作，现状没有二次确认。见 REQ-WTY-024。

CATI 入口同时存在于延保小程序与 O2O 接单宝 —— ~~两处是否为同一业务、整合后归属哪个模块~~ V1.1 关闭：两处不是同一业务，结论见 REQ-WTY-023。

4.5.5 售后鉴定与证据采集

业务目标：为轮胎故障提供标准化的鉴定资料采集流程，保证证据链完整可追溯。

售后鉴定受理入口：支持扫描消费者理赔码 / 预约码、手动输入预约码，以及进入无用户信息鉴定通道。

页面内容 —— 「售后鉴定」入口页：一个扫码主按钮 + 两个次级入口，下方是两条说明文字。

关键交互 —— ①点橙色「扫描消费者的理赔码/预约码」→ 相机扫码（一个入口同时接受两种码）；②点「手动输入预约码 >」→ 输入弹层；③点「无用户信息鉴定 >」→ 无用户通道表单。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-007 无用户信息鉴定、REQ-WTY-020 入口收敛

页内说明文字是 REQ-WTY-007 的原文出处 ✓：「该模式未关联消费者的延保保单，因此，无法进行延保鉴定理赔」。但说明第 1 条讲的是「CATI理赔」，而页面标题是「售后鉴定」—— CATI 理赔与售后鉴定在这个入口下是混在一起的，与「理赔管理」页把二者拆成两个 tab 的做法不一致。这是 REQ-WTY-020 要收敛的又一处。另：主按钮同时接受「理赔码 / 预约码」两种码，App 侧须能自动判别码型并路由。

售后鉴定状态跟踪：可按「待上传、正在进行、已完成」管理鉴定单，且支持按车牌或条码查询。

页面内容 —— 「理赔管理」页的「售后鉴定」tab，状态胶囊比另两个 tab 多一个「待上传」。

关键交互 —— ①切换「待上传 / 正在进行 / 已完成」三个状态胶囊；②其余同「延保理赔」tab。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-022 三类案件状态机各不相同

正文 4.5.5 写的「待上传、正在进行、已完成」只适用于售后鉴定，延保理赔与 CATI理赔都是两态。App 侧不应强行统一，见 REQ-WTY-022。「待上传」这一态的存在也说明鉴定单可以先建单、后补证据，与 8.6 弱网与离线的本地暂存策略直接相关。

无用户信息鉴定：适用于未关联消费者延保保单的轮胎故障鉴定，仅做故障鉴定，不可走延保理赔。

标准化鉴定资料收集：采集车辆品牌 / 型号、轮胎故障、生产日期、完整 DOT、轮位、轮胎品牌，以及 DOT 照片、胎面照片、故障部位内外部照片；补充视频为可选项。

页面内容 —— 「无用户通道」表单上半部分，分车辆信息 / 轮胎故障信息 / 轮胎基础信息 / 轮胎照片信息四段，字段均为必填。

关键交互 —— ①带 > 的字段点开下拉选择（车辆品牌 / 轮胎故障信息 / 轮位 / 轮胎品牌）；②车辆型号、生产日期、DOT 编码为文本输入；③点「ⓘ 示例：」旁的缩略图 → 查看拍照示范；④点上传区 → 拍照或选图；⑤底部「确认保存」提交。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003) —— 鉴定资料采集是现场作业，实际使用者以技工为主。

需求关联 —— REQ-WTY-007 无用户信息鉴定、REQ-WTY-026 必填与张数、REQ-WTY-027 必填标识规范

两点：①**「生产日期（4 位）」与「DOT 编码（完整）」是两个独立字段**，前者是 DOT 尾部的周 + 年，正文写「生产日期、完整 DOT」是对的但未说明二者关系；②必填标识的表达方式有问题 —— 所有字段都带 *，但下拉选择类的占位文字是红色、文本输入类是灰色，用颜色区分的是控件类型而非必填性，门店容易误读为「红的才必填」。见 REQ-WTY-027。页面标题是「无用户通道」，比入口处的「无用户信息鉴定」短，两处命名应统一。

页面内容 —— 同一表单下半部分的四个上传区，每区各带一张拍照示范缩略图。

关键交互 —— ①点 + 方格 → 拍照或从相册选择；②每类照片有各自的张数上限；③「补充视频」为唯一选填项；④底部「确认保存」提交。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-003)。

需求关联 —— REQ-WTY-026 必填项与张数上限

四类照片的张数上限各不相同：DOT 照片 ≤1 张、胎面照片 ≤1 张、故障部位内外部照片 ≤3 张，胎侧整体照片的上限被顶部返回胶囊遮挡，本图无法确认。每类都配了拍照示范缩略图，这个设计降低了门店拍错率，App 侧应保留。见 REQ-WTY-026。顶部的小程序返回胶囊常驻并遮挡页面内容，是小程序容器的固有问题，App 自研后可消除。

照片与视频为必填证据，涉及弱网环境下的大文件上传。断点续传、失败重试、本地暂存策略见 8.6。

4.5.6 工作台、返利与经营数据

业务目标：为门店提供延保业务的聚合视图与返利可见性。

工作台快捷入口：聚合保单、理赔、返利、教程、店员、数据等核心业务模块，并展示当前门店延保数据和返利简报（见 2.7.4）。

经营数据时间粒度切换：工作台支持按月、年查看延保数据，并可切换品牌口径。

页面内容 —— 工作台页 + 品牌选择滚轮，页内可见六宫格入口与「延保数据」卡的月粒度视图。

关键交互 —— ①六宫格入口分别进入保单 / 理赔 / 返利 / 教程 / 店员 / 数据；②「月 | 年」切换时间粒度；③滚轮选品牌后点绿色「确定」应用。

可用角色 —— 店长 ✅；技工 ❓ 返利与数据可见性待定 TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-004 返利可见性、REQ-WTY-031 品牌枚举

六宫格确认为 保单 / 理赔 / 返利 / 教程 / 店员 / 数据，与正文完全一致 ✓。「延保数据」卡已经按品牌拆成「马牌延保数量 / 维京延保数量」两列，上面又有一个品牌筛选滚轮 —— 筛选与拆列功能重复。另，两个指标下方各有一行「筛选结果」标签但没有对应数值，本图无法确认该行是被滚轮遮住还是本就为空。

页面内容 —— 工作台切到「年」粒度的完整视图，含「延保数据」与「店铺返利简报」两张卡。

关键交互 —— ①「月 | 年」切换 → 日期区间随之变化；②点「查看返利明细」类入口进入下级页；③点底部「筛选品牌 | 全部 >」→ 返利简报的独立品牌筛选。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-004 返利可见性、REQ-WTY-029 数据口径、REQ-WTY-031 品牌枚举

三点口径须写进 PRD：①**「月 / 年」切的都是「至今」区间** —— 月 = 当月 1 日至今（2026-04-01 ~ 04-21），年 = 1 月 1 日至今（2026-01-01 ~ 04-21），不是完整自然周期；②返利简报的「本月 / 本年」两个指标不随上面的月/年切换变化，是两套独立时间口径；③返利简报有自己独立的品牌筛选（底部橙色行），与延保数据卡的品牌筛选互不影响 —— 同一页面两个品牌筛选器，见 REQ-WTY-031。免责声明「*享受延保奖励轮胎条数以最终实际发放为准」须保留，这是返利数字与实际到账可能不符的法律兜底。

数据分析：提供近 7 天、近 30 天的延保生效保单和理赔数量趋势；同时展示用户性别与年龄分布，用于门店经营分析。

页面内容 —— 「数据分析」页上半部分：时间范围胶囊 + 延保生效保单与理赔数量两张折线图（数据全为 0）。

关键交互 —— ①切换「近7天 / 近30天」两个胶囊；②点折线上的数据点 → 弹出 tooltip 显示当日数值。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-029 数据口径「截止到今日0点」

每张图表卡底部都标注「截止到今日0点」，即数据是 T+1、不含当天。 这是一条必须写进 PRD 的口径声明 —— 门店当天做的单子当天看不到，容易被当作 bug 反复提。与 4.12 经营业绩的实时性口径须一并裁决，见 REQ-WTY-029。本图数据全为 0（折线呈水平直线），是空数据门店的样本。

页面内容 —— 「数据分析」页下半部分：用户性别信息与年龄分布信息两张图。

关键交互 —— ①滚动查看；②图表本身在有数据时应支持点选查看数值。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-029 数据口径、REQ-WTY-030 空数据兜底渲染

两处图表渲染缺陷：①「用户性别信息」只剩三条图例（男性 / 女性 / 未知），图形本体完全没渲染；②「年龄分布信息」在数据全为 0 的情况下，六根柱子仍然等高显示且无数值标注 —— 会被误读为「各年龄段均匀分布」。见 REQ-WTY-030。另：年龄分六档（17岁以下 / 18-24 / 25-29 / 30-39 / 40-49 / 50岁以上），须与 4.13 营销与会员的会员画像口径对齐；用户画像属消费者人口统计数据的聚合展示，其合规口径应在安全章节统一规定。

返利中心：展示品牌编码、经销商编码、本年返利总额、本月及本年延保轮胎奖励胎数，支持按品牌筛选。

页面内容 —— 「返利中心」页，一张指标卡 + 一行品牌筛选，卡内所有指标位均为空白。

关键交互 —— ①点橙色「查看返利明细 >」→ 返利详情页；②点「筛选返利品牌 | 马牌轮胎 >」→ 品牌滚轮。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-004 返利可见性、REQ-WTY-030 空数据兜底渲染

整张卡「有标签没有值」 —— 品牌编码、经销商编码、本年返利总额、本月 / 本年延保轮胎奖励数五个指标位全是空白，不是显示 0，而是彻底没有渲染。而工作台的返利简报在同样无数据时显示的是 0。同一份数据在两个页面上的空态表现不一致，见 REQ-WTY-030。

页面内容 —— 返利中心的品牌滚轮，只有马牌轮胎与维京轮胎两项，没有「全部」。

关键交互 —— ①滚动选择品牌；②「取消 / 确定」。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-031 品牌枚举统一

本模块第三处品牌枚举，且与前两处都不同 —— 保单筛选 3 项（含「全部」）、工作台筛选 3 项（含「全部」）、返利中心只有 2 项且缺「全部」，即返利数据无法一次看全品牌合计。加上 4.8 我的的返利品牌里还出现过「卡迪睿德」，品牌枚举须作为主数据统一，见 REQ-WTY-031。

返利明细与时间筛选：可查看延保返利金额，并按起止日期筛选明细数据。

页面内容 —— 「返利详情」页，顶部是延保返利额汇总（0 元），下方明细列表为空。

关键交互 —— ①点橙色「设置时间段 - 默认」→ 时间筛选弹层；②明细列表下拉加载。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-032 返利明细的时间筛选改造

「设置时间段 - 默认」这个文案含义不明 —— 「默认」是当前生效的时间段名称，还是按钮的一部分？结合下一张图（起止日期均为空）可判断默认其实是「不限时间」，但页面上完全看不出来。见 REQ-WTY-032。另：顶部只有「延保返利额」一个汇总数，与返利中心的「本年返利总额」是否同一口径，本图无法确认。

页面内容 —— 「返利详情设置条件」弹层，仅开始 / 结束日期两项，均未填。

关键交互 —— ①点「选择日期 >」→ 日期滚轮；②点橙色「确认筛选条件」应用；③「✕ 关闭」取消。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-WTY-004)。

需求关联 —— REQ-WTY-032 返利明细的时间筛选改造

三处体验问题：①没有「清除条件」按钮（保单筛选有）；②没有快捷选项（近 7 天 / 近 30 天），必须手动选两个日期，而同一个 App 内的数据分析页就是胶囊快捷选择；③起止日期默认为空即不限时间，与页面上的「默认」字样对不上。见 REQ-WTY-032。

延保返利与 O2O 返利是两套独立数据（口径、维度、周期均不同）。整合后是否合并进统一的返利中心 —— TODO(REQ-RBT-004)。

延保经营数据与 4.12 经营业绩同理，存在口径合并问题 —— TODO(REQ-PRF-004)。

4.5.7 培训、操作指引与服务支持

业务目标：降低门店上手成本，减少因流程不熟导致的建单/理赔错误。

内置教程中心：提供零售店注册延保新流程、装车视频拍摄、延保理赔、售后鉴定、无用户信息鉴定、保单作废和延保客服等教程。

页面内容 —— 「使用教程」列表，7 条教程各占一张卡。

关键交互 —— 点任一卡 > → 该教程的视频播放页。

可用角色 —— 店长 ✅、技工 ✅（教程应全角色开放）。

需求关联 —— REQ-WTY-033 教程与功能入口一一对应

7 条教程与正文所列完全一致 ✓：零售店注册延保新流程 / 拍摄装车视频 / 理赔操作(延保) / 理赔操作(售后鉴定) / 理赔操作(无用户信息鉴定) / 作废保单操作 / 延保客服操作。但教程口径与理赔功能的 tab 对不上：教程有「理赔操作教程(无用户信息鉴定)」而理赔管理里没有该 tab；理赔管理有「CATI理赔」tab 却没有对应教程。见 REQ-WTY-033。另：「作废保单操作教程」的存在说明作废是门店会常态使用的功能，更凸显 REQ-WTY-016 状态校验与审计的必要性。

视频化教程承载：教程详情以视频播放器形式呈现，支持播放进度与全屏查看。

页面内容 —— 教程视频播放页，播放区为全黑、进度条显示 00:00 / 00:00。

关键交互 —— ①点播放区播放 / 暂停；②拖动进度条；③点右下图标全屏。

可用角色 —— 店长 ✅、技工 ✅。

需求关联 —— REQ-WTY-034 教程视频播放器能力

视频未加载（总时长也是 00:00），无法确认是加载失败还是截图时机过早。播放器本身只有进度条与全屏两个控件 —— 没有独立的播放/暂停按钮、没有倍速、没有字幕、没有章节目录，作为培训材料的承载偏弱，见 REQ-WTY-034。

延保客服入口：首页提供悬浮式延保客服入口，支持门店在建单、激活和理赔过程中寻求帮助（见 2.7.4）。

其他小程序入口：延保小程序内亦挂有跳转其它小程序的入口，整合后取消（见现状入口 → App 导航映射）。

页面内容 —— 延保首页底部升起的四宫格面板，用于跳转到其它四个小程序。

关键交互 —— 点任一格 → 跳转对应小程序（订单平台 / O2O接单宝 / 积分兑换 / 零售管理）。

可用角色 —— 店长 ✅；技工 ⚙️ 取决于各目标小程序自身的权限。

需求关联 —— 整合后取消（见现状入口 → App 导航映射）

这张图是整合价值最直接的实证：四个入口分别对应本 PRD 要收编的四个现状系统 —— 订单平台（4.6 采购）、O2O接单宝（4.3 销售）、积分兑换（4.14 福利兑换）、零售管理（4.9 门店管理）。门店现状要在五个小程序之间靠这个面板来回跳，正是痛点 2.1 多小程序分散的写照。注意面板里没有 F6 —— F6 不是小程序，走的是 H5，这也解释了为什么 F6 只能以 Embedded H5 方式整合。

4.5.8 需求描述汇总

业务目标 —— 见各子节

目标角色 —— 店长：全部功能；技工：建单、待办处理、保单查询、理赔受理（TODO(REQ-WTY-003) 需确认）

入口 —— 底部导航「延保」tab；销售结算页跳转（4.3.7）；首页待办「延保视频上传提醒」

V1.1 补充：延保实际有三条入口，除上述两条外，销售模块的接车页底部还有一个「延保」按钮，且 O2O 已完成订单卡上有「查看延保」。参数契约须统一覆盖，见 REQ-SAL-011。

前置条件 —— 已登录、已确定门店；门店已开通延保业务

主流程：

建单：扫描/录入车牌 → 绑定车辆 → 上传装车视频 → 门店激活 → 消费者确认 → 保单生效
理赔：扫描理赔码/预约码 → 受理 → 采集证据 → 上报 → 跟踪结果

异常流程：

车牌识别失败 → 手动输入 / 特殊车牌录入
扫码不可用 → 手动输入预约码
无关联保单 → 走无用户信息鉴定通道（仅鉴定不理赔）
上传失败 → 本地暂存并重试

权限规则 —— 保单作废、返利查看建议限店长 —— TODO(REQ-WTY-005)、TODO(REQ-WTY-004)

访问链路 —— App → App Backend → 延保后台

逻辑数据来源 —— 延保后台（保单、预约、理赔、鉴定、返利、教程）

回写目标 —— 建单、装车视频、理赔申请、鉴定资料、条款同意记录 → 延保后台

状态变化：

保单：待补充 → 待确认 → 正常（生效中）→ 已过有效期 → 已作废（REQ-WTY-011 补入「已过有效期」）
延保生效：门店激活成功 → 用户未确认 → 用户已确认（计入「延保成功」）（REQ-WTY-018）
预约：预约车检 → 已受理 → 已上报
延保理赔 / CATI 理赔：正在进行 → 已完成
鉴定单：待上传 → 正在进行 → 已完成

4.5.9 业务规则

REQ-WTY-001 双保障并行 —— 原厂质保与撞击延保互不替代；制造缺陷走原厂质保，外力撞击走延保换新

REQ-WTY-002 待办归并 —— ~~延保待办与首页待办的归并方式待定~~ V1.1 收窄：延保内部本就有两套待办，处置方式见 REQ-WTY-028；仅「归并后的计数口径与刷新时机」仍待定 TODO(REQ-WTY-002)

REQ-WTY-003 技工权限范围 —— 技工可执行的延保操作范围待定 TODO(REQ-WTY-003)

REQ-WTY-004 返利可见性 —— 延保返利对技工是否可见待定 TODO(REQ-WTY-004)

REQ-WTY-005 保单作废 —— 高风险操作，需权限 + 状态校验 + 审计记录；状态校验与原因留痕的具体要求见 REQ-WTY-016，权限归属与是否需后台审批仍待定 TODO(REQ-WTY-005)

REQ-WTY-006 CATI 归属 —— ~~延保与 O2O 两处 CATI 入口的关系待定~~ V1.1 关闭：两处不是同一业务，结论见 REQ-WTY-023

REQ-WTY-007 无用户信息鉴定 —— 仅做故障鉴定，不可走延保理赔；必采字段见 4.5.5

REQ-WTY-008 消费者未认证兼容 —— 该状态不影响延保返利及管理端查询；消费者后续扫码可找回保单。新老系统切换点为 2020-08-24 07:00，找回方式为在新系统扫描驾驶证 + 行驶证两证

REQ-WTY-009 保单筛选 —— 支持激活起止日期 + 品牌（全部 / 马牌 / 维京）

REQ-WTY-010 条款同意留痕 —— 记录条款版本与同意时间；完整字段要求见 REQ-WTY-035

以下 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 的作废审计要求；②投保人为消费者，未实名时显示「未实名消费者」而非「微信用户」；③条款同意留痕同样须带操作人

REQ-WTY-016 保单作废的状态校验与留痕 —— ①已过有效期、已作废的保单，「作废保单」按钮置灰不可点；②作废须二次确认，并必填作废原因（枚举 + 「其它」自由填写）；③作废记录操作人（依赖 REQ-WTY-015）、时间、原因；④作废不可撤销，二次确认文案须明示

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 门店管理；延保侧的 CATI 是理赔案件的跟踪列表，归本模块。 二者不是重复功能，而是同一项资质的两个面。未开通 CATI 资质的门店，延保侧的「CATI理赔」tab 隐藏。（关闭原 TODO(REQ-WTY-006)）

REQ-WTY-024 CATI 说明文案与高危开关 —— ①O2O 侧 CATI 页的说明文案现状为脏数据（同段重复 4 遍 + 测试串），须由业务重新提供一版；②「关闭服务」会使门店失去 CATI 资质并影响理赔受理能力，须二次确认并说明影响范围

REQ-WTY-025 脱敏格式统一 —— 手机号统一按 138****7616（前三 + 四星 + 后四）脱敏，现状预约详情用的 *******3963 须改；消费者姓名（申请人 / 投保人 / 车主）同样须脱敏。本条与 4.3 销售、4.8 我的是同一问题，建议在安全章节统一规定

REQ-WTY-026 鉴定资料的必填项与张数上限 —— 必填照片四类，张数上限各不相同：DOT 照片 ≤1 张 / 胎侧整体照片（上限待向延保后台确认）/ 胎面照片 ≤1 张 / 故障部位内外部照片 ≤3 张；补充视频为唯一选填项。每类上传区须配拍照示范缩略图（现状已有，须保留）

REQ-WTY-027 必填标识与提交校验规范 —— 必填一律以 * 标识，占位文字统一为同一灰色，不得用红 / 灰区分控件类型（现状用红色表示下拉选择、灰色表示文本输入，易被误读为「红的才必填」）；提交时若有未填项，统一高亮并自动滚动定位到第一个未填项

REQ-WTY-028 延保内两套待办的归并 —— 延保小程序内部现有两套待办：首页的「待绑定车辆 / 待补充装车视频」计数卡（含独立列表页）与底部 tab「待办事项」。整合后：延保内不再保留独立待办 tab，全部并入 App 首页待办；首页的两个计数卡保留为延保页内的快捷筛选入口

REQ-WTY-029 数据口径「截止到今日 0 点」 —— 延保经营数据为 T+1、不含当天，图表上须保留该口径声明。与 4.12 经营业绩的实时性口径一并裁决（TODO(REQ-PRF-004)）

REQ-WTY-030 空数据的兜底渲染 —— ①指标位无数据时显示 0 或 —，不得出现「有标签无数值」（现状返利中心整卡空白）；②图表无数据时显示统一空态插画，不得只剩图例（现状用户性别图）或全 0 却等高（现状年龄分布图）；③全模块空态文案统一（现状有「暂无数据」「没有更多了」「暂无预约记录」三种写法）

REQ-WTY-031 品牌枚举统一 —— 品牌为主数据，全 App 使用同一套枚举与展示名，筛选器一律包含「全部」。现状本模块内有三种写法（保单筛选 3 项 / 工作台缩写「马维」/ 返利中心 2 项缺「全部」）。延保品牌是否包含卡迪睿德（4.8 我的的返利品牌中出现过）未定 —— 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）

REQ-WTY-036 保单协议的 PDF 预览 —— 保单协议以 PDF 文件形式提供，App 须具备原生 PDF 预览能力（缩放、分页、保存），并保留文档页脚的 Continental 密级标识，不得裁剪

REQ-WTY-037 车牌录入的两种模式 —— ①普通模式用车牌格子（逐位输入、支持「新能源」切换 7/8 位），特殊模式用自由文本输入框（不做位数校验），两者为同页切换控件，不是页面跳转（设计稿画成外链跳转须修正）；②车牌识别为拍照上传识别，与 REQ-SAL-002 复用同一套 OCR 能力；③取景提示文案须与实际框色一致（现状文案写「黄色」、框是橙色）；④「手动输入车牌」改用中性 / 次要按钮样式，红色仅保留给危险操作

REQ-WTY-038 统一选择器 —— 日期与品牌等选择控件由 App 自研并随主题配色，替代现状的微信原生 picker（白底 + 绿色按钮压在深色页面上，本模块 4 处出现）

4.5.10 验收标准

门店未开通延保业务时，延保 tab 不显示；
车牌识别失败可切换手动输入与特殊车牌录入，已录入内容不丢失；
「待绑定车辆」「待补充装车视频」计数与待办列表条数一致，且与首页对应待办项一致；
无关联保单的轮胎进入无用户信息鉴定通道后，界面不提供任何理赔提交入口；
弱网下上传鉴定照片/视频中断后，重新进入可从本地暂存恢复，不需要重新拍摄；
保单作废后，该保单在所有列表与筛选结果中状态一致，且留有操作人与时间的审计记录；
保单列表卡的主标题字段名为「轮胎条码」，详情页的「保单号」为 15 位保单子代码，两处不混用（REQ-WTY-012）；
同一车牌下的 4 条轮胎在列表中展示为 4 条不同条码的记录，不出现「相同保单号」的重复卡片（REQ-WTY-013）；
已过有效期的保单，其「作废保单」按钮为置灰不可点状态（REQ-WTY-016）；
作废保单时必须选择作废原因并二次确认，作废记录中可查到操作人的真实工号与姓名（REQ-WTY-015、REQ-WTY-016）；
门店激活成功但消费者未确认的轮胎，在门店端显示为「待消费者确认」，且不计入「延保成功轮胎数」（REQ-WTY-018）；
「查看延保」页中每条轮胎只显示一个状态，汇总数与明细条数一致（REQ-WTY-019）；
未开通 CATI 资质的门店，延保侧不显示「CATI理赔」tab（REQ-WTY-023）；
预约详情中的消费者手机号按 138****7616 格式脱敏，姓名同样脱敏（REQ-WTY-025）；
无用户信息鉴定表单在有未填必填项时点击「确认保存」，页面自动滚动到第一个未填项并高亮（REQ-WTY-027）；
无数据门店进入返利中心与数据分析页时，所有指标位显示 0 或 —，图表显示统一空态插画，不出现空白标签或等高柱（REQ-WTY-030）；
保单筛选、工作台、返利中心三处的品牌下拉，选项完全一致且均含「全部」（REQ-WTY-031）；
教程视频支持倍速播放，加载失败时给出重试入口（REQ-WTY-034）。

4.6 采购

采购覆盖门店要买的全部商品，包括马牌商品与耗材、辅料、其它品牌轮胎，一套浏览、加购、结算、收货、售后流程走到底，门店不需要按品牌切换页面。

数据来源上，马牌商品走 ROOS、其余商品走 F6。ROOS 本身就是马牌在 F6 后台之上自建的采购小程序 —— 品牌方要单独管理并统计各门店对自有品牌的采购情况，才有了这一层；对门店而言仍是同一个采购功能。

4.6.1 需求描述

业务目标 —— 门店在 App 内完成全部品类的订货全流程（搜索 → 加购 → 结算 → 收货 → 售后），覆盖马牌与非马牌商品，并保留 ROOS 的额度、返利、优惠券结算能力，解决痛点 2.3

目标角色 —— 店长：全部；技工：需被授权后功能同店长

入口 —— 底部导航「采购」tab；首页快捷入口「采购」。全部商品同在此 tab 内，按分类 / 品牌逐级筛选

前置条件 —— 已登录、已确定门店；采购马牌商品还需门店在 ROOS 有有效的经销商 / 信用账户

页面内容 —— 商品搜索与筛选 → 商品列表 → 购物车 → 订单确认（费用构成与扣账方式）→ 我的订单（六状态）→ 订单详情 → 售后/退款；扫码收货

主流程 —— 搜索商品 → 加入购物车 → 调整数量并勾选 → 结算 → 确认费用与扣账方式 → 提交订单 → 扫码收货。马牌与非马牌商品的流程完全一致，门店感知不到品牌差异

异常流程：

信用额度不足 → 提示并阻断提交（校验时机见 REQ-PUR-017）
商品无库存 → 加购按钮替换为「缺货登记」入口（REQ-PUR-014）
商品下架 → 列表不再返回该商品
扫码收货条码不匹配 → 提示并拒收

业务规则 —— 见 4.6.7

权限规则 —— 技工默认无采购权限，需店长/后台授权（REQ-PUR-001）

访问链路 —— App → App Backend → ROOS（马牌商品）/ F6（非马牌商品）

逻辑数据来源 —— 马牌商品：ROOS；非马牌商品：F6。两者的底层服务同为 F6，ROOS 是马牌品牌侧的管理与统计层

回写目标 —— 购物车、采购订单、扣账方式选择、收货确认、售后申请 → 对应来源系统

状态变化 —— 采购订单：待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消（六状态，见 REQ-PUR-006）

验收标准 —— 见 4.6.9

4.6.2 产品搜索与商品列表

用户通过顶部搜索框与筛选条件收窄范围，查询出搜索结果列表。马牌商品的搜索接口来源于 ROOS，非马牌商品来源于 F6，两类结果在同一列表内呈现，门店按品牌 / 分类筛选即可，不需要切换页面。

页面内容 —— App 采购商品列表的目标形态：搜索框 + 购物车图标、一行规格筛选、「显示有货 / 显示促销」开关与品牌下拉，主体为单列商品卡（4 张卡为同一份占位数据，仅库存状态不同）。

关键交互 —— ①点规格筛选任一项 → 展开该维度取值多选；②切换「显示有货 / 显示促销」→ 列表按开关过滤；③点「马牌 ▾」→ 切换品牌；④有货 / 库存紧张的卡点右下加购图标 → 加入购物车，购物车角标 +1；⑤缺货卡的加购图标被替换为「去登记」按钮 → 进入缺货登记（REQ-PUR-014）；⑥点购物车图标 → 进入购物车页。

可用角色 —— 店长 ✅ 全量；技工 ⚙️ 需店长或后台在人员管理「可用系统」中授予采购权限后方可进入（REQ-PUR-001）。

需求关联 —— REQ-PUR-007 数据来源、REQ-PUR-010 商品域范围、REQ-PUR-014 缺货登记、REQ-PUR-015 商品卡字段

页面内容 —— ROOS 小程序的商品选择页，结构与上方设计稿高度一致，差别在于商品卡多出「可延保」与时效标、缺货商品直接在图上压「缺货」并给出「缺货登记」按钮，底部是 ROOS 自身的四 tab。

关键交互 —— ①同上方设计稿的搜索与筛选；②点「缺货登记」→ 提交该商品的缺货登记；③点加购 → 加入 ROOS 购物车；④点底部 tabbar「购物车」→ 进入购物车页。整合到 App 后 ROOS 自身的 tabbar 不再出现，购物车入口收敛到列表页右上角（见上方设计稿）。

可用角色 —— 同上方设计稿：店长 ✅、技工 ⚙️。

需求关联 —— REQ-PUR-007 数据来源、REQ-PUR-014 缺货登记、REQ-PUR-015 商品卡字段

本节正文原描述与两张图不符，已按图修订（不新增需求编号）：

V1.0 原文写「左侧树形分类（按品牌 / 花纹 / 规格逐级收窄）+ 右侧商品卡」。两张图都不是这个结构 —— 均为「顶部平铺筛选行 + 单列商品卡」，没有左侧分类树。4.6.8 中 productCategory 的备注「树形分类」也应据此复核：该字段可能只是后台的分类层级，并不对应一个前端树形控件。上方正文已改为「顶部搜索框与筛选条件」。

4.6.3 购物车与结算

加入购物车：用户点击商品卡的加购图标，将商品加入购物车。用户可以调整采购数量，选择商品条目前面的选择图标，点击「结算」按钮进入结算页。

页面内容 —— App 购物车的目标形态，商品按品牌分组（「德国马牌」组已勾选、「维京轮胎」组未勾选），底部为「合计 / 已减 / 结算」结算条。

关键交互 —— ①勾选 / 取消单行或整个品牌组 → 合计与已减金额实时重算；②数量步进器 − / + → 改变该行数量；③点「优惠明细 ^」→ 展开本单优惠构成；④点「结算」→ 进入订单确认页。

可用角色 —— 店长 ✅；技工 ⚙️ 被授权后可加购与调整数量，能否点「结算」并最终提交订单未定 TODO(REQ-PUR-002)，关闭前按不可提交实现。

需求关联 —— REQ-PUR-011 购物车与订单是否合并、REQ-PUR-002 技工下单权限

本图不能作为 REQ-PUR-011 已解决的证据：图中分组的「德国马牌」与「维京轮胎」同属 ROOS 的品牌，两者本来就在一个系统内。真正的分歧点是 ROOS 商品与 F6 非马牌商品能否共用一个购物车，本图未涉及。

页面内容 —— ROOS 现状购物车，本图为单商品的轻量态（无优惠行），商品归在「德国马牌」组下，行内比设计稿多出商品编码与时效标。

关键交互 —— ①点「编辑」→ 进入批量管理态（可删除 / 移出）；②勾选与数量调整同设计稿；③点「结算」→ 进入订单确认页。

可用角色 —— 同上方设计稿：店长 ✅、技工 ⚙️ + TODO(REQ-PUR-002)。

需求关联 —— REQ-PUR-015 商品卡字段（商品编码、时效标）

时效标在三张图里出现了三种写法 —— 设计稿购物车「最快45分钟」、ROOS 商品选择「⏱45分钟」、ROOS 购物车「⏱1小时」。该标是随商品与仓库动态计算的，App 侧需统一文案模板，一并归入 REQ-PUR-015。

结算与提交订单：用户在订单确认页核对费用构成后，点击「提交订单」，完成采购流程。

页面内容 —— ROOS 现状订单确认页，自上而下为收货地址、订单商品区、费用构成（立减 / 优惠券 / 运费待双方商定 / 返利请选择 / 备注）与底部支付条（信用额度不可用），本图为测试数据（收货人「测试」、地址为重复拼接的脏数据）。

关键交互 —— ①点收货地址 → 切换 / 编辑地址；②点「优惠券」→ 选择可用券；③点「返利请选择」→ 选择本单抵扣的返利额度（见返利中心）；④填写备注；⑤点「提交订单」→ 提交（额度校验结果见下图）。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-PUR-002)。返利抵扣涉及门店资金账户，即便技工被授权采购，是否可动用返利额度需一并确认。

需求关联 —— REQ-PUR-004 支付方式、REQ-PUR-016 订单确认页费用构成、REQ-PUR-011 购物车与订单是否合并

本图给出两条与 V1.0 正文冲突的事实：

页面上没有任何支付方式选择器。 V1.0 的 4.6.3 原文写「用户选择支付方式后，点击提交订单」，现状实际是「信用额度 + 返利 + 优惠券」三者构成扣账，没有微信/支付宝式的支付方式单选。整合后的形态归入 REQ-PUR-016 与 TODO(REQ-PUR-004)。

订单标题为「订单1–德国马牌」并标「普通订单」 —— 说明 ROOS 现状已经按品牌把一次结算拆成多张订单。这对 REQ-PUR-011 是重要输入：连同属 ROOS 的两个品牌都要拆单，跨 ROOS / F6 合并成一张订单的可行性更低，更现实的形态是「一个购物车 → 按来源拆多张子订单 → 列表侧聚合展示」。

信用额度校验：额度不足时给出明确提示并阻断下单。

页面内容 —— 订单确认页上弹出的失败弹窗，标题「订单提交失败」，正文「账户额度不足，请联系经销商处理」，单按钮「我知道了」。

关键交互 —— ①点「我知道了」→ 关闭弹窗回到订单确认页，订单未生成。无重试、无跳转充值 / 联系经销商的入口，门店只能自行线下联系。

可用角色 —— 店长 ✅、技工 ❓ TODO(REQ-PUR-002)（能提交才会遇到本弹窗）。

需求关联 —— REQ-PUR-003 额度校验、REQ-PUR-017 额度校验时机

本图与 REQ-PUR-003、验收标准第 2 条直接冲突：现状是点击提交之后才由服务端返回「订单提交失败」，而 REQ-PUR-003 要求「提交订单前校验」、验收标准要求「『提交订单』不可点击，且提示包含可用额度与本单金额」。现状弹窗既不置灰按钮，也不告知可用额度与本单金额差额。已新增 REQ-PUR-017 明确校验时机与提示内容。

支付方式的可选集合、优先级与扣账逻辑由「支付优先级设置」决定。整合后支付方式与 CDMS 支付的关系 —— TODO(REQ-PUR-004)。

4.6.4 收货

用户扫描商品，完成收货流程。扫码为 App 原生实现（见 REQ-INT-003），非嵌入 H5。

收货扫码与扫码入库是否为同一动作、是否一次扫码同时完成收货与入库 —— TODO(REQ-PUR-005)。

附录 A.5 第 5 条已经把这两件事写成同一个数据集「收货（扫码入库）」，倾向于合并；但正文与 REQ-PUR-005 仍按未定处理，需业务正式确认后统一两处口径。

本节无配图 —— 收货页面既无设计稿也无现状截图，扫码后的收货确认页（是否逐条核对、是否支持部分收货、拒收如何记录）目前没有任何页面材料。

4.6.5 订单管理与售后

采购订单列表：tag 分为全部、待支付、待发货、待收货、已收货、已取消六个状态。

页面内容 —— ROOS「我的订单」列表，顶部为搜索框与「筛选」、其下六个状态 tab（全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消，当前选中「全部」），本截图为空态（「您还没有相关的订单」），故订单行的字段与操作按钮无法从本图确认。

关键交互 —— ①在搜索框输入订单号 / 商品名称 / 商品编码 → 检索订单；②点「筛选」→ 打开 tab 之外的附加筛选条件（本图未展开，筛选维度无法确认）；③点任一状态 tab → 切换列表；④点订单行 → 进入订单详情。

可用角色 —— 店长 ✅ 全量；技工 ⚙️ 被授权后可查看订单（附录 B「搜索 / 加购 / 查看订单」为 ⚙️）。

需求关联 —— REQ-PUR-006 订单状态机

状态集合按本图修订。 V1.0 原写五状态「全部 / 待支付 / 待发货 / 已发货 / 已取消」，现状实为六个 tab：把「已发货」叫作「待收货」，并且多出「已收货」这一独立状态 —— 后者正对应 REQ-PUR-006 原文里那个没有 tab 的「（收货）完成」。REQ-PUR-006 与验收标准第 4 条已同步改为六状态。

另：现状 tab 上不带条数角标，而验收标准第 4 条要求「tab 计数与列表条数一致」—— 该计数是 App 侧的新增要求，接口需支持按状态返回计数。

页面内容 —— 同一页面切到「待支付」tab，搜索、筛选与六个 tab 均不变，同样是空态。

关键交互 —— 与上一张图一致；本图仅用于佐证 tab 切换后页面骨架不变、六状态集合稳定。

可用角色 —— 同上：店长 ✅、技工 ⚙️。

需求关联 —— REQ-PUR-006 订单状态机

采购订单详情：查看订单流转状态。本节无订单详情配图，详情页的字段、可执行操作（取消 / 再次购买 / 申请售后的入口位置）缺少页面材料。

售后 / 退款：进入订单详情页面，点击「售后/退款」，进入「售后/退款」流程。

页面内容 —— ROOS「售后/退款」列表页，顶部依次为橙色提示条「退货订单将不会退回抵扣券」、售后单号搜索框与日期区间，本截图为空态，故售后单行的字段与状态无法从本图确认。

关键交互 —— ①输入售后单号或销售订单号 → 检索售后单；②点「开始时间」/「结束时间」→ 选择日期区间过滤；③点售后单行 → 进入售后详情。本页只做查询，发起售后的入口在订单详情页内。

可用角色 —— 店长 ✅；技工 ⚙️（附录 B「售后 / 退款」为 ⚙️，需授权）。售后涉及退款去向，技工被授权后能否发起而非仅查看，随 TODO(REQ-PUR-002) 一并确认。

需求关联 —— REQ-PUR-018 售后退款规则

本图暴露一条涉及资金、却完全未成文的规则：「退货订单将不会退回抵扣券」—— 门店用抵扣券下单后退货，券不退回，实际损失由门店承担。V1.0 的 4.6.5 对售后只有一句「进入订单详情，点击售后/退款」，售后类型、可申请时限、退款去向（退回信用额度 / 返利 / 抵扣券）一概未定义。已新增 REQ-PUR-018。

另注意搜索框写的是「销售订单号」—— 这是 ROOS 站在平台售货方视角的措辞，而门店视角同一张单叫「采购订单」。整合进 App 后必须统一为门店视角，否则会与销售模块的销售订单混淆。

采购订单的六状态（待支付 / 待发货 / 待收货 / 已收货 / 已取消 / 全部）与 O2O 销售订单的五状态（4.3.5）是两套完全不同的状态机，UI 上必须明确区分，不可复用同一组件文案。

4.6.6 角色差异

角色	权限
店长	搜索、加购、结算、提交订单、收货、查看订单、发起售后
技工	默认不可见；被授权后功能同店长。是否允许技工提交订单（涉及资金）—— `TODO(REQ-PUR-002)`

采购模块角色差异。资金相关动作（提交订单、选择返利抵扣、发起售后）在 TODO(REQ-PUR-002) 关闭前一律按技工不可执行实现。

4.6.7 业务规则

REQ-PUR-001 采购授权 —— 技工需被显式授权才能进入采购模块；授权维度参见人员管理「可用系统」

REQ-PUR-002 技工下单权限 —— 技工被授权后是否可提交订单待定 TODO(REQ-PUR-002)。该条同时覆盖「选择返利抵扣」与「发起售后」两个资金相关动作

REQ-PUR-003 额度校验 —— 提交订单前校验信用额度；不足时阻断并提示。校验时机与提示内容见 REQ-PUR-017

REQ-PUR-004 支付方式 —— 由支付优先级设置决定默认扣账方式；与 CDMS 支付的关系待定 TODO(REQ-PUR-004)

REQ-PUR-005 收货与入库 —— 扫码收货与扫码入库是否合并为一次动作待定 TODO(REQ-PUR-005)

REQ-PUR-006 订单状态机 —— 待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消。列表 tag 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」六个，与销售订单状态机隔离

本条状态集合于 V1.1 按 ROOS 我的订单截图修订：原写五状态、把「待收货」写作「已发货」且缺「已收货」。

REQ-PUR-007 数据来源 —— 商品、价格、库存、订单、售后：马牌商品以 ROOS 为准，非马牌商品以 F6 为准；App 不落地二次计算的价格

REQ-PUR-008 扫码实现 —— 收货扫码使用 App 原生扫码能力，不嵌入第三方 H5 扫码页

REQ-PUR-009 车型字段来源 —— 商品的车型（carModel）是否取自 RMS 待确认 TODO(REQ-PUR-009)，见 4.6.8

REQ-PUR-010 商品域范围 —— 采购覆盖门店需要的全部商品，含马牌商品与耗材、辅料、其它品牌轮胎。只有一个采购入口，门店在同一 tab 内按分类 / 品牌筛选，不因商品来源不同而切换页面。这是痛点 2.1「多系统来回切换」在采购域的最后一块拼图

REQ-PUR-011 购物车与订单是否合并 —— 马牌商品与非马牌商品能否放进同一个购物车、生成同一张订单待确认 TODO(REQ-PUR-011)。合并则需要跨来源的订单拆分与状态聚合；不合并则购物车与订单列表需按来源分列。这是本模块最大的架构分歧点

V1.1 的实证输入：ROOS 订单确认页把一次结算按品牌拆成「订单1–德国马牌」等多张订单（见 4.6.3）。连同属 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 确认

REQ-PUR-014 缺货登记与到货通知 —— 商品列表中缺货商品不置灰，而是把加购按钮替换为「缺货登记 / 去登记」入口，门店可登记采购意向。登记后的到货通知形式（是否推送、是否自动加购、登记记录在哪里查看）未定 TODO(REQ-PUR-014)；缺货登记对非马牌商品是否同样可用，随 REQ-PUR-013 一并确认

本条修正了 4.6.1 原异常流程「商品下架/无库存 → 列表置灰」的写法：无库存不是置灰，而是换成一个可点的登记入口；下架商品则根本不在列表中返回。

REQ-PUR-015 商品卡与购物车字段 —— 商品卡除业务数据列表已有字段外，还需承载：发货仓（截图为「浦东新仓」）、销量（「已售 3426」）、库存状态标（有货 / 库存紧张 / 库存不足 / 缺货）、可延保标、配送时效标、商品编码（购物车内展示）。这些字段当前均不在 4.6.8 的 10 个字段内，来源与取值集合待补 TODO(REQ-PUR-015)。配送时效标现状有「最快45分钟」「⏱45分钟」「⏱1小时」三种写法，App 侧须统一为一个文案模板

REQ-PUR-016 订单确认页费用构成 —— 订单确认页按「立减 → 优惠券 → 返利抵扣 → 运费 → 信用额度」的顺序展示费用构成，并给出「优惠后订单金额」与「剩余应付合计」。其中：运费现状为「待双方商定」（线下协商，无金额），返利为「请选择」（门店主动选择本单抵扣额度）。整合后 App 内运费如何呈现与确认、返利抵扣的可选额度来源、以及是否存在独立的支付方式单选（现状没有）待确认 TODO(REQ-PUR-016)，与 REQ-PUR-004 一并决策

REQ-PUR-017 额度校验时机 —— 信用额度校验必须在提交前完成：额度不足时「提交订单」置为不可点击，并在按钮上方直接给出可用额度与本单金额的差额。服务端在提交时仍需二次校验兜底，但该兜底不得成为门店感知到的唯一提示。现状为提交后弹「订单提交失败 / 账户额度不足，请联系经销商处理」，无差额、无置灰、无后续入口 —— 是否需要在提示中提供「联系经销商」的跳转或经销商联系方式待确认 TODO(REQ-PUR-017)

REQ-PUR-018 售后退款规则 —— 售后单支持按售后单号 / 采购订单号检索与日期区间过滤。已确认的资金规则：退货订单不退回抵扣券，该规则须在门店发起售后前显式告知并留痕。售后类型（退货 / 退款 / 换货）、可申请时限、退款去向（原路退回信用额度 / 返利 / 抵扣券）、审核流程均未定义 TODO(REQ-PUR-018)。页面文案须统一为门店视角：现状 ROOS 用的是平台视角的「销售订单号」，App 内应称「采购订单号」，避免与销售模块的销售订单混淆

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

采购业务数据表。上表按马牌商品（ROOS）列出；非马牌商品的同名字段以 F6 为准，字段能否一一对齐随 REQ-PUR-013 的接入路径一并确认。

上表尚未覆盖截图中实际出现的以下字段，随 TODO(REQ-PUR-015) 补齐：发货仓、销量、库存状态、可延保标、配送时效、以及订单确认页的立减 / 优惠券 / 运费 / 返利抵扣 / 信用额度五项金额字段。

4.6.9 验收标准

技工未被授权时，采购 tab 不下发、深链跳转也被拦截；
信用额度不足时「提交订单」不可点击，且提示包含可用额度与本单金额；提交接口在服务端仍做二次校验（REQ-PUR-017）；
购物车勾选、数量修改在弱网下不丢失，恢复网络后与后端一致；
采购订单六状态的 tab 计数与列表条数一致；
扫码收货使用原生扫码，无 WebView 加载过程；
采购 tab 内可同时检索到马牌与非马牌商品，两类商品的下单、支付、收货、售后在交互上完全一致，商品来源对门店可见但不改变操作路径；
门店未接入 F6 时，非马牌商品不出现在采购 tab 内且不报错，见门店能力开关；
缺货商品的卡片给出「缺货登记」入口而非置灰，登记成功后有明确反馈（REQ-PUR-014）；
发起退货前，「退货订单不退回抵扣券」的提示对门店可见（REQ-PUR-018）。

第 2、4 条按本次逐图核看结果修订，第 8、9 条为本次新增。

4.7 库存

底部导航的三版方案中，业务菜单版有「库存」tab、设计稿 5 tab 方案有「入库」tab（见三版底部导航方案）。本节内容由现状截图反推。

业务目标 —— 把「查得到货、扫得进库、对得上账」收敛到 App 内，解决痛点 2.3中「门店无法实时判断可售库存」的问题

入口 —— 底部导航「库存 / 入库」tab；首页快捷入口「扫码入库」「扫码出库」；采购收货流程

页面内容 —— 库存查询（SKU 列表 + 四级轮胎参数筛选）、扫码入库记录、扫码出库、条码库存（入库记录 / 出库记录 / 在库条码）

主流程：

查询：选择搜索类型 → 输入关键字或逐级筛选 → 查看 SKU 库存状态与结算价
入库：扫描轮胎条码 → 校验 → 写入在库条码 → 生成入库记录

权限规则 —— 店长全量；技工可查询与扫码入/出库，TODO(REQ-INV-001) 确认技工是否可见结算价

数据来源 —— O2O（库存查询、扫码入库）、ROOS（条码库存、扫码出库）

4.7.1 库存查询

页面内容 —— App 目标形态：搜索框 + 一行五个下拉筛选（胎面宽 / 扁平比 / 直径 / 花纹 / 黑科技），主体为 SKU 卡片列表，卡上含库存状态标签与小程序结算价（稿中含普利司通 / 米其林 / 倍耐力，规格与级别为占位数据）。

关键交互 —— ①点搜索框输入关键字 → 检索；②点五个下拉任一 → 展开取值面板，逐级收窄；③上下滑动卡片列表。稿中未画搜索类型切换、未画筛选重置入口、未画分页或上拉加载。

可用角色 —— 店长 ✅ 全量；技工 ✅ 可查询。卡片右下「小程序结算价」对技工是否可见未定 TODO(REQ-INV-001)——若判定不可见，本卡片布局需出一版无价格的技工态。

需求关联 —— REQ-INV-002 SKU 与产品编码、REQ-INV-003 库存状态覆盖、REQ-INV-004 筛选维度

页面内容 —— O2O 小程序现状：搜索行为「搜索类型下拉 + 输入框 + 搜索按钮」三段式，筛选行只有四个（无黑科技），列表为通栏分隔行含产品编码、库存状态、商品名与小程序结算价，本图为测试环境数据（编码多值且被截断、库存状态列大多为空）。

关键交互 —— ①点「产品信息 ▾」→ 切换搜索类型（见下一张图）；②输入关键字点「搜索」→ 检索；③点四个筛选任一 → 展开取值面板；④上下滑动列表。

可用角色 —— 店长 ✅；技工 ✅ 可查询，结算价可见性待定 TODO(REQ-INV-001)。

需求关联 —— REQ-INV-002（一行多编码正是本图实证）、REQ-INV-003（库存状态大面积为空正是本图实证）、REQ-INV-004（促销标签的去留）

页面内容 —— 「产品信息」下拉的展开态，浮层给出产品信息（当前选中）与产品code 两个搜索类型，其余区域被遮罩。

关键交互 —— ①点搜索行「产品信息 ▾」→ 展开 / 收起本浮层；②选「产品信息」→ 按商品名称检索；③选「产品code」→ 按产品编码检索；④点遮罩区 → 收起浮层。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-INV-002——现状把「产品信息」与「产品code」做成两种并列的搜索类型，正是「主键到底是 SKU 还是产品编码」这一口径问题在交互层的外显；App 若统一为 SKU，这个下拉是保留还是取消需一并裁决。

四级轮胎参数筛选：胎面宽、扁平比、直径、花纹逐级收窄。以下四张图为四级筛选各自展开后的取值面板。

页面内容 —— 「胎面宽」的展开态，面板为 4 列 chip 网格、实测 20 项取值（0、13、175…325），底部并排「重置」「确认」。

关键交互 —— ①点 chip 选取值（单选还是多选本图无法确认，图中无任何 chip 处于选中态）；②「重置」清空本级已选；③「确认」应用筛选并收起面板；④点遮罩收起。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-INV-004；取值中的 0 与 13 不是合法胎面宽 → REQ-INV-008

页面内容 —— 「扁平比」的展开态，结构同上但取值远多于胎面宽（首屏可数 60 余项且可继续滚动，第 2、3 项即为 ssss 和 测试），本图底部被截断未拍到按钮。

关键交互 —— ①上下滚动取值网格；②点 chip 选取值；③滚到底部使用重置 / 确认（本图未拍到该区域）。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-INV-004；取值含 ssss、测试 两个非数值项，且 107 / 120 / 255 等远超乘用车胎扁平比常见区间（约 25–80）→ REQ-INV-008

页面内容 —— 「直径」的展开态，结构同前两级，取值同样 60 余项且可滚动（首项即 测试），底部截断。

关键交互 —— 同扁平比：滚动网格 → 点 chip 选取值 → 底部重置 / 确认。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-INV-004；列表首项即为 测试，且含 348 等远超乘用车轮辋直径区间（13–24 英寸）的取值 → REQ-INV-008

页面内容 —— 「花纹」的展开态，4 列 chip 网格完整拍到全部 42 项取值，超长名称在 chip 内以 … 截断。

关键交互 —— ①点 chip 选取值；②「重置」/「确认」；③点遮罩收起。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-INV-004；本图是四级筛选数据质量问题最集中的一张 → REQ-INV-008：测试残留（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 扫码入库

页面内容 —— 入库记录查询页（非扫码页），筛选行为日期区间 2026.04.01–2026.04.27 + 品牌下拉（图中已选中「马牌」），其下是橙色汇总条「总入：0 条」，本图为空态故记录行的字段构成无法确认。

关键交互 —— ①点日期区间 → 打开日期筛选浮层（见下方第二张图）；②点品牌下拉 → 展开品牌筛选（见下方第一张图）；③汇总条「总入：N 条」随筛选条件变化；④页面本身未见扫码按钮——本页是入库记录查询页，扫码动作的入口在 O2O 首页而非此处。

可用角色 —— 店长 ✅ 全量；技工 ✅ 可扫可查（一线高频操作）。

需求关联 —— REQ-INV-005 入库写入目标、REQ-INV-006 扫码由 App 原生实现、REQ-INV-007 重复条码拒绝

页面内容 —— 品牌下拉的展开态，三个选项：全部品牌 / 马牌（✓ 当前选中）/ 维京。

关键交互 —— ①点品牌下拉 → 展开 / 收起；②点选项 → 单选切换，选中项右端显示 ✓；③点遮罩 → 收起。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— 品牌可选值只有马牌与维京两个 Continental 集团品牌，而 4.7.1 的库存查询里出现普利司通 / 米其林 / 倍耐力——两者覆盖范围不同，佐证「入库」与「库存查询」在现状下是两套口径不一致的数据，是 REQ-INV-005 需要一并裁决的部分。

页面内容 —— 日期区间的展开态，浮层有「月份选择」「自定义」两个 tab（当前停在自定义），其下为两个日期输入框构成区间，底部并排「全部日期」「确认」。

关键交互 —— ①切换「月份选择」/「自定义」两种取期模式；②点任一日期框 → 唤起日期选择器；③「全部日期」→ 取消区间限制，查全部；④「确认」→ 应用区间并收起。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— —（仅作现状佐证）。App 整合后是否保留「月份选择 / 自定义」双模式，随 REQ-INV-005 的入库页形态一并确定。

4.7.3 扫码出库与条码库存

页面内容 —— ROOS 首页扫码后弹出的模态弹窗「请选择需要执行的操作」，底部两个并排按钮 「去延保」 与 「直接出库」，背景可见 ROOS 首页与四宫格互跳入口，标题栏写明「MF ROOS UAT 测试环境」。

关键交互 —— ①在 ROOS 首页点扫码入口扫描轮胎条码 → 弹出本弹窗；②点「去延保」→ 携该条码进入延保建单流程；③点「直接出库」→ 仅登记出库、不建延保单；④弹窗未提供取消或关闭按钮，能否点遮罩关闭本图无法确认。

可用角色 —— 店长 ✅；技工 ✅（扫码出库属一线高频操作）。但「去延保」分支会创建延保单，而延保建单对技工是否开放尚未定 TODO(REQ-WTY-003)——两处口径必须对齐，否则会出现「技工能出库却在弹窗第二步被拦」的断流。

需求关联 —— REQ-INV-005、REQ-INV-006；出库时的「去延保 / 直接出库」二选一分支是本模块与延保的关键衔接点，现有 7 条需求中没有任何一条描述它 → REQ-INV-009

条码库存：在「我的」菜单中点击「条码库存」，进入「条码库存」，tab 为入库记录、出库记录、在库条码。

页面内容 —— 条码库存页：橙色头部含搜索框与一个独立的扫码图标，其下三个 tab（入库记录选中 / 出库记录 / 在库条码）与筛选行品牌 / 选择日期 / 是否有效，本图为空态故记录行的字段构成无法确认。

关键交互 —— ①切换入库记录 / 出库记录 / 在库条码三个 tab；②搜索框按商品编号或名称检索；③点右侧扫码图标 → 扫码直接定位条码；④三个下拉分别按品牌、日期、有效性筛选；⑤「清除筛选」一键复位全部筛选条件。

可用角色 —— 店长 ✅ 全量；技工 ✅ 可查。本页在 ROOS 中的入口位于「我的」菜单下，App 整合后入口位置需随导航收敛重新安排。

需求关联 —— REQ-INV-005 入库写入目标、REQ-INV-007 重复条码；「是否有效」这个筛选维度说明条码存在**有效 / 失效（作废）**两种状态，而现有需求未定义该状态、也未定义谁能作废条码 → REQ-INV-010

入库来源双写问题：扫码入库在 O2O 和 ROOS 两侧都有记录（O2O 的「扫码入库」与 ROOS 的「条码库存-入库记录」），经营业绩同时统计「扫码入库总数」与「扫码入库门店数」。整合后是一次扫码双写、还是以其中一侧为准 —— 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）

REQ-INV-007 重复条码 —— 同一条码重复扫描应拒绝并提示已入库时间与门店

REQ-INV-008 筛选取值清洗 —— 品牌 / 花纹 / 规格 / 级别四级筛选的取值直接取自库存主数据，现状含测试残留、越界值、疑似重复与字段串位。App 是照搬现状取值还是由后端出清洗后的枚举，待定 TODO(REQ-INV-008)

REQ-INV-009 扫码出库的延保分支 —— 现状扫码出库后弹窗强制在「去延保 / 直接出库」二选一，是库存与延保的衔接点。App 是否保留该弹窗、传递哪些参数、技工能否走「去延保」，待定 TODO(REQ-INV-009)

REQ-INV-010 条码有效性状态 —— 条码存在有效 / 失效两态，其流转规则、作废权限、作废后能否重新入库，以及与 REQ-INV-007 重复校验的关系待定 TODO(REQ-INV-010)

REQ-INV-011 字段清单缺失 —— 附录 A 未收录本模块的字段清单，需业务补齐后再定接口契约 TODO(REQ-INV-011)

4.7.5 验收标准

四级参数筛选任意组合下，列表结果与筛选条件一致，清空筛选可一键还原；
同一条码重复扫描时给出明确提示，不产生重复入库记录；
扫码入库在断网时可暂存，恢复网络后批量提交且不重复；
库存状态标签与结算价来自同一次查询，不出现价格已更新而状态未更新的错位。

4.8 我的 / 个人中心

本节的来历：V1.0 的 4.8 没有「业务规则」小节。 六个 REQ-MIN-001 ~ REQ-MIN-006 编号全部只以 TODO(...) 标记的形式散落在正文与合并规则表中， 没有任何一条成文规则，这正是附录 D.2 中 MIN 完成度为 0% 的直接原因（14 个模块里唯一的 0%）。 V1.1 补入 4.8.6 业务规则，V1.0 的「4.8.6 验收标准」顺延为 4.8.7。

三套现状小程序各有一个「我的」，本节将其合并为 App 的统一个人中心。

业务目标 —— 提供统一的账号、门店、资产（额度/返利/优惠券/积分）与设置入口，取代三套小程序各自的「我的」

入口 —— 底部导航「我的」tab

页面内容 —— 用户信息卡（头像/姓名/门店/角色标签）+ 资产卡（积分、优惠券）+ 功能列表 + 退出登录

主流程 —— 进入个人中心 → 查看资产 / 进入子功能 → 返回

权限规则 —— 全角色可见；资产类（额度、返利、对账单）建议限店长 TODO(REQ-MIN-002)

数据来源 —— App Backend（账号、门店）、ROOS（账户、优惠券、地址、收藏、支付优先级）、O2O（设置、手机号）、延保后台（姓名、门店）

4.8.1 目标形态

页面内容 —— App 个人中心的目标形态：顶部橙色用户卡（头像、账号名、门店名、金黑配色的「⭐ 店长」角色标签），下方并排两张资产卡（积分 460 / 优惠券 56），再下是 6 项功能列表，底部为描边样式的「退出登录」。

关键交互 —— ①点击右上角设置图标 → 进入设置页（设计稿未定义该页内容）；②点击「积分 460」「优惠券 56」→ 资产二级页（卡片上未见 > 或箭头，是否可下钻本图无法确认）；③点击功能列表任一项（服务热线 / 经销商客服 / 地址管理 / 我的收藏 / 经营范围 / 换绑手机）→ 进入对应二级页；④点击「退出登录」→ 二次确认弹窗。

可用角色 —— 店长 ✅ 全量；技工 ✅ 可见页面，但资产卡与部分功能项受限（附-2）。角色标签由后台下发，技工不显示店长专属资产项。

需求关联 —— TODO(REQ-MIN-001) 个人中心保留哪 6 项、REQ-MIN-016 关于 / 版本号入口、REQ-MIN-020 头像首版只读

设计稿的功能列表只有 6 项，而三套现状小程序的「我的」合计有 20 余项。哪些进个人中心、哪些下沉到各业务模块 —— TODO(REQ-MIN-001)。本节先按域完整记录现状，作为取舍的输入。

设计稿与其它章节的三处冲突，须一并解决：

资产卡只有积分与优惠券两项，额度与返利没有位置，而 4.8.5 合并规则表写的是「我的账户（额度/返利/券/积分）→ 个人中心资产卡 + 二级页」，附录 B 的权限行也是四项一起管控 —— 四项资产如何在两张卡里落位未定，见 REQ-MIN-009。

优惠券在设计稿上是 56（像张数），而 ROOS 现状展示的是优惠券总金额 ¥0.00（金额）—— 口径不同，见 REQ-MIN-009。

设计稿把「退出登录」放在个人中心主页面，O2O 现状放在二级「设置」页内 —— 本 PRD 以设计稿为准（见 4.8.5 合并规则表）。另：设计稿底部导航为 首页 / 入库 / 采购 / 延保 / 我的，与 4.2 APP 首页与导航的导航收敛方案须保持一致。

4.8.2 ROOS「我的」（采购域资产）

页面内容 —— ROOS 采购小程序的「我的」：橙色头部为头像、门店主编码、门店名与账号，其下依次是「本月进度」考核卡、「我的订单」四状态卡、四宫格快捷入口（账户 / 优惠券 / 对账单 / 条码库存）与收货地址 / 员工管理 / 我的收藏三行列表。

关键交互 —— ①点击「本月进度 ⓘ」的问号 → 指标口径说明；②点击「查看更多 >」→ 门店考核明细（现状指标为签约量(单马牌) 100 / 马牌订货量 0 / 扫码入库 0 / O2O售出 –）；③点击「全部订单 >」或待支付 / 待发货 / 待收货 / 售后退款任一图标 → 采购订单列表并定位到对应状态页签；④点击账户 / 优惠券 / 对账单 / 条码库存 → 四个二级页；⑤点击收货地址 / 员工管理 / 我的收藏 → 对应二级页。

可用角色 —— 店长 ✅ 全量；技工 🔸 资产类（账户 / 对账单）与员工管理不可见 TODO(REQ-MIN-002)。本页底部导航为 4 tab（首页 / 商品 / 购物车 / 我的），是采购域独立小程序的形态，与 App 5 tab 不同。

需求关联 —— REQ-MIN-009 我的账户资产结构、REQ-MIN-017 本月进度与员工管理的归属

本页有两项能力不在 4.8.5 合并规则表的 16 行里，也不在设计稿里 —— 属漏归：

「本月进度」考核卡 —— 与 4.12 经营业绩与报表、4.11 返利中心是同一套门店考核体系（签约量 / 订货量 / 扫码入库 / O2O 售出）；

「员工管理」 —— 与 4.9 门店管理的「人员管理与授权」是同一件事。

处理办法见 REQ-MIN-017，两行已补入 4.8.5 合并规则表。

页面内容 —— 点 ROOS「我的」资产入口后弹出的微信系统级弹窗「即将打开"账户管理｜德国马牌轮胎"小程序」，遮罩下露出的功能列表补齐了上一张未拍到的项（支付优先级设置、服务热线、经销商客服、关于 V2.66.96、退出登录）。

关键交互 —— ①点击「允许」→ 跳出 ROOS，打开独立的「账户管理」小程序；②点击「取消」→ 留在当前页。这是微信原生弹窗，样式与文案由平台控制，小程序无法定制。

可用角色 —— 店长 ✅；技工 ❓ 取决于资产类权限结论 TODO(REQ-MIN-002)。

需求关联 —— REQ-MIN-018 「账户管理」小程序的接入范围、REQ-MIN-016 关于 / 版本号入口

两处关键发现：

「账户管理｜德国马牌轮胎」是本 PRD 系统清单之外的第 8 个小程序 —— 第 5 章列出的现状系统为 ROOS / O2O / 延保 / 马上下单 / RMS / MSIP / F6，不含它。4.8.5 合并规则表写「跳转其它小程序 → 取消」，意味着 App 必须自行承接账户管理的全部能力，或接入该小程序的后端接口 —— 这是一处尚未评估的接入范围，见 REQ-MIN-018。

「关于 V2.66.96」入口在设计稿中完全缺失 —— App 作为独立安装包，版本号、用户协议、隐私政策、检查更新是发版合规的必备项，见 REQ-MIN-016。

我的账户：点击「账户」按钮进入「我的账户」。我的账户分为信用额度、未使用返利、优惠券总金额、积分余额。信用额度含可用余额、待还金额、信用额度；未使用返利按品牌明细展示，含返利总额。

页面内容 —— 资产总览页：顶部橙色卡为门店名、所属经销商与可用余额 / 信用额度 / 待还金额，下方白卡按未使用返利、优惠券总金额、积分余额三段罗列并各自拆分明细，本页为全零数据故金额格式与明细行样式无法从本图确认。

关键交互 —— ①点击「未使用返利 ¥0.00 >」→ 返利明细；②点击「优惠券总金额 ¥0.00 >」→ 优惠券列表（即下一张图）；③点击「积分余额 0 >」→ 积分明细与兑换；④四类返利与两类积分本身未见 >，是否可逐类下钻本图无法确认。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-MIN-002)（资产与资金相关，倾向不开放）。

需求关联 —— REQ-MIN-009 资产四层结构与两套返利体系

本页揭示的三点，是 4.8 与 4.11 之间最容易做错的地方：

信用额度未设置时显示「——」而非 ¥0.00 —— 空值与零值在授信语境下含义完全不同（未授信 vs 授信额度为零），App 必须沿用这一区分。

未使用返利按「品牌–区域」组织，出现了 Continental–上海 / Viking–上海 / 卡迪睿德 / 其他业务 四类。其中**「卡迪睿德」是 4.11 返利中心从未出现过的第三个品牌**（4.11 只涉及马牌与 Viking）。

返利有两套互不相通的体系 —— 本页是 ROOS 采购返利（按品牌×区域累计，用于抵扣货款，4.6 采购结算页的「返利抵扣请选择」取的就是它）；而 4.11 返利中心描述的是 O2O 营销返利（消费者补贴、安装费用、抽奖红包）。4.11 只覆盖后者。 个人中心若只展示一个「返利」数字，必然把两套账混在一起。

优惠券：状态 Tab 为待激活、待生效、待使用、已使用、已失效；券的种类分为马牌券、经销商券。

页面内容 —— 优惠券列表页：顶部五个状态页签（待激活 / 待生效 / 待使用（当前选中）/ 已使用 / 已失效）与「马牌券 | 经销商券」二级分段控件，本截图为空态故券卡的面额、门槛、有效期、适用范围无法从本图确认。

关键交互 —— ①切换五个状态页签 → 列表按券状态过滤；②切换「马牌券 / 经销商券」→ 在当前状态下再按券种过滤（两级筛选叠加）；③点击券卡 → 券详情或去使用（空态下无法确认）；④「待激活」状态隐含一个激活动作，但激活入口与规则本图无法确认。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-MIN-002)。

需求关联 —— REQ-MIN-010 优惠券五状态与两种券种

「待激活」与「待生效」是两个不同状态：前者需用户主动激活，后者是已激活但未到生效时间。PRD 现状未定义激活动作的触发方式与规则，见 REQ-MIN-010。

支付优先级设置：~~设置是否优先使用扣账支付方式~~ —— V1.1 更正：现状实际为单一开关「是否优先使用微信支付」，取值「是 / 否」，与「扣账支付方式」无关。

页面内容 —— 极简单行设置页「是否优先使用微信支付」（当前值「是」），点击后从底部升起微信原生单列滚轮，选项为「否 / 是」。

关键交互 —— ①点击设置行 → 升起滚轮选择器；②滚动选择「是 / 否」→ 点「确认」保存并回填该行，点「取消」不变更；③本页只有这一项设置，无其它支付方式排序能力。

可用角色 —— 店长 ✅；技工 ✗（影响资金，见附录 B）。

需求关联 —— TODO(REQ-MIN-005) 放在个人中心还是采购结算、REQ-MIN-011 设置语义与生效范围

V1.0 的 4.8.2 原文「设置是否优先使用扣账支付方式」与截图不符，已就地更正。 该表述会误导设计与开发把它做成「扣账 / 微信 / 余额」的多方式排序，实际只是一个二值开关。

收货地址：地址列表含联系人、手机号、详细地址、默认标记。页面提示「扫码入库时，店铺位置以地图定位为准」。

页面内容 —— 收货地址列表，本图只有一条（联系人「测试」、详细地址为重复拼接的脏数据、带 ✅「默认地址」标记），列表下方有一行提示「扫码入库时，店铺位置以地图定位为准」与橙色「查看定位 >」。

关键交互 —— ①点击「查看定位 >」→ 打开门店地图定位（V1.0 只引用了提示文案，未提及这个可点入口）；②点击地址条目 → 编辑（本图无法确认是否可点）；③本页未见「新增地址」按钮，新增入口位置无法从本图确认；④只有一条地址，A.9 所称「按使用时间 / 默认状态排序」无法验证。

可用角色 —— 店长 ✅；技工 🔸 只读（见附录 B）。

需求关联 —— REQ-MIN-014 地址管理能力与权威数据源

地址文本「上海市上海市浦东新区上海市浦东新区南桥路1200号」是典型的省市区与详细地址重复拼接的脏数据 —— 结构化字段（省/市/区）与自由文本（详细地址）在录入时没有做互斥校验。App 侧须做规范化，见 REQ-MIN-014。

我的收藏：进入「商品收藏列表」。

页面内容 —— 商品收藏列表（顶部标注「共 1 件商品」），商品卡含左侧占位图（无实际商品图）、规格名与红色单价，右侧竖排橙色实心 ❤ 与「加入购物车」两个图标。

关键交互 —— ①点击橙色实心 ❤ → 取消收藏，商品从列表移除；②点击「加入购物车」→ 直接加购，与 4.6 采购的购物车联动；③点击商品卡 → 商品详情（本图无法确认）。

可用角色 —— 店长 ✅；技工 🔸 只读（见附录 B）—— 「只读」意味着技工不可取消收藏、不可加购，需在实现时明确。

需求关联 —— REQ-MIN-015 收藏列表的价格可见性与操作权限

收藏卡直接展示采购价 ¥1688.00/条，与附录 B 存在冲突：附录 B 给技工的「收货地址 / 我的收藏」是 🔸 只读（即可见），而「查看小程序结算价」对技工是 ❓ TODO(REQ-INV-001)。若技工能打开收藏列表，就等于绕过价格管控看到了采购价。见 REQ-MIN-015。另：商品图为占位图，是 ROOS 商品主数据的图片缺失，属现状数据质量问题，不新增需求编号。

4.8.3 O2O「设置」（账号与门店）

页面内容 —— O2O（接单宝）的「设置」页，内容极简：头像 + 昵称 + 手机号一行（右侧一枚橙色小标签文字过小、本图无法辨认）、门店名 + 灰色「切换店铺」一行，中部大片留白，底部是灰色的「退出登录」。

关键交互 —— ①点击「切换店铺」→ 门店选择列表（见本节后面的图）；②点击「退出登录」→ 确认弹窗（见下一张图）；③本页无「修改手机号」入口，而 O2O 确实存在修改手机号页 —— 其入口位置本图无法确认。

可用角色 —— 店长 ✅；技工 ✅（个人信息 / 登出对全角色开放，见附录 B）。

需求关联 —— REQ-MIN-007 门店绑定关系与切换门店、REQ-MIN-013 姓名的可编辑性与回写

门店名「智慧园杀虫轮胎店」与 4.9 门店管理截图中的「豌豆的小店」不同，但手机号 13419691597 相同 —— 同一账号绑定多家门店，这一点在下面的「选择店铺」图中得到印证。另：三套现状系统对同一个人的称呼各不相同 —— O2O 显示昵称「宛玉」，ROOS 显示手机号，延保显示操作人姓名「史涵」。这正是 TODO(REQ-MIN-003) 要解决的问题。

页面内容 —— 居中确认弹窗，标题「确认登出」+「取消 / 确定」两个按钮，无任何正文说明。

关键交互 —— ①点击「确定」→ 清除登录态并返回登录页；②点击「取消」→ 关闭弹窗留在设置页。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-LGN-008 退出登录需二次确认、REQ-MIN-019 登出的清除范围与多设备会话

现状弹窗只有「确认登出」四个字，不说明后果。App 的登出会同时清除本地 Token、门店上下文与缓存业务数据（见 4.8.7 验收标准第 2 条），弹窗文案须把这一点告知用户，见 REQ-MIN-019。

页面内容 —— 换绑手机号表单，三行为「当前手机号」（134 1969 1597，分组展示、未脱敏）、新手机号与短信验证码，下方提示「验证码将发送至原手机号」，底部「确认修改」为灰色禁用态。

关键交互 —— ①点击「获取验证码」→ 向原手机号发送短信验证码并开始倒计时；②三项填写完整后「确认修改」由灰转亮 → 提交换绑；③新手机号不做任何验证即可绑定。

可用角色 —— 店长 ✅；技工 ✅（换绑手机对全角色开放，见附录 B）。

需求关联 —— REQ-MIN-012 换绑手机的双向验证与脱敏

这是现状里最需要在 App 上改掉的一处：验证码发往原号只能证明「你是当前账号的持有人」，无法证明「新号归你所有」。填错一位数字就会把账号绑到陌生号码上，且原号已失去登录能力 —— 属不可自助恢复的故障。App 须改为双向验证，见 REQ-MIN-012。

页面内容 —— 「选择店铺」列表页，每行为门店名 + 橙色「进入」按钮（当前门店改显橙色 ✅ 标记），本图可见 13 家门店且列表可继续下滑，即同一账号绑定了 13 家以上门店。

关键交互 —— ①点击任一行的「进入」→ 切换到该门店并返回，全站数据随之切换；②当前门店不可重复进入；③列表无搜索框、无分组、无字母索引，门店多时只能逐屏翻找。

可用角色 —— 店长 ✅；技工 ✅（能进哪些门店由后台绑定关系决定，不由角色决定）。

需求关联 —— REQ-MIN-007 门店绑定关系与切换门店、REQ-HOM-001 全局门店上下文

这张图确立了个人中心最关键的一条结构性事实：门店与账号是多对多关系，且规模不小（本例 13+ 家）。 4.8.5 合并规则表把「切换门店」收敛为 App 全局门店上下文，但全局门店列表取自哪套系统的绑定关系、切店时清不清购物车、已打开的页面如何处理均未定义，见 REQ-MIN-007。列表中「曲奇测试门店2号店」「马牌品牌商导入MS（预发1）」「上海市尚浦中心马牌培训店1(测试勿拍)」「野蜂蜜很甜」「吃瓜专门店」「小脑斧汽车修理门店」等大量条目为测试数据，正式环境的门店名规范与数量分布无法从本图推断。

页面内容 —— 从 O2O 首页唤起的底部动作面板「小程序在线客服」，列出 6 条按渠道区分的电话（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），底部为「取消」。

关键交互 —— ①点击任一行 → 唤起系统拨号盘拨打该号码；②点击「取消」→ 关闭面板；③无在线聊天能力 —— 名为「在线客服」，实为电话清单。

可用角色 —— 店长 ✅；技工 ✅（客服入口不设权限）。

需求关联 —— TODO(REQ-MIN-004) 三个客服入口是否合并、REQ-MIN-008 服务热线按渠道分列的数据模型

两点须处理：

客服不是一个号码，而是按渠道分的 6 条线。V1.0 的 4.8 只列了「服务热线 / 经销商客服 / O2O·延保企微客服」三个入口，附录 A.9 的「服务热线列表」也只有「号码 / 服务时间 / 范围 / 类型」四个字段 —— 缺「渠道」维度，见 REQ-MIN-008。

高德（159****1674）与美团（185****1756）用的是个人手机号，零跑是座机分机（023-62905394）。个人号码作为对外官方热线，人员变动即失联，属治理风险。

本图的渠道口径（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑）与 4.9 门店管理的平台渠道（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑）又不相同 —— 这是全仓库第七套渠道枚举，见附-5。

4.8.4 延保「我的」

页面内容 —— 延保小程序的「我的」，深色主题（与 ROOS / O2O 的浅色主题完全不同）：上部是带编辑铅笔的大号橙色头像，下方三行为操作人姓名、切换店铺与手机号（右侧灰字「已绑定」），底部是 5 tab 导航。

关键交互 —— ①点击头像右下的铅笔钮 → 更换头像（本图无法确认是否真的可上传）；②点击「操作人姓名」→ 姓名编辑弹窗（见下一张图）；③点击「切换店铺」→ 门店选择器（见本节最后一张图）；④「手机号码」行无 >，不可点 —— 延保侧不提供换绑手机；⑤底部中央的橙色指南针钮功能本图无法确认。

可用角色 —— 店长 ✅；技工 ✅（个人信息类，见附录 B）。

需求关联 —— REQ-MIN-013 姓名的可编辑性与回写、REQ-MIN-020 头像首版只读、TODO(REQ-MIN-003) 姓名的权威来源与回写范围

姓名在延保侧是可自由编辑的文本（「史涵」），而 ROOS 显示的是手机号、O2O 显示的是昵称「宛玉」。三套各存一份、互不同步 —— 这就是 TODO(REQ-MIN-003) 的由来。本页账号 13871477616 / 上海东兴店与 ROOS 截图一致（同一测试账号跨两系统），与 O2O 截图的 13419691597 / 智慧园杀虫轮胎店不是同一个账号。

页面内容 —— 居中深色弹窗「登录账户输入您的姓名」（右上角「✕ 关闭」胶囊），表单只有一个「姓名」下划线输入框与底部橙色「确认」。

关键交互 —— ①在输入框键入姓名 → 点「确认」保存并回填到「操作人姓名」行；②点右上「✕ 关闭」→ 放弃修改；③输入框为空，未预填当前姓名「史涵」；④无必填标记、无长度或字符校验提示。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-MIN-013 姓名的可编辑性与回写

两处须在 App 上改掉：编辑弹窗不预填当前值（用户改一个字也得整个重打），以及标题文案「登录账户输入您的姓名」语义不通。

页面内容 —— 深色「我的」页底部升起的微信原生单列滚轮选择器（浅色，与页面深色主题割裂），滚轮中只有一个选项「上海东兴店」，底部为灰底「取消」与绿色实心「确定」。

关键交互 —— ①滚动滚轮选择门店 → 点「确定」切换；②点「取消」不变更；③本账号在延保侧只绑定 1 家门店，故滚轮无实际可选项。

可用角色 —— 店长 ✅；技工 ✅。

需求关联 —— REQ-MIN-007 门店绑定关系与切换门店

同一件事，三套系统三种交互：O2O 是整页列表 + 「进入」按钮，延保是底部滚轮选择器，ROOS 的「我的」页则没有切换店铺入口。App 统一为一种交互即可，但更要紧的是背后的数据 —— 门店绑定关系分别维护在各系统里（本例延保侧 1 家，O2O 侧另一账号 13+ 家），统一后取哪套为权威须定，见 REQ-MIN-007。另：确定按钮为绿色（微信原生 picker 默认色），与延保小程序的橙色主色不一致 —— App 用原生组件时须统一主题色。

4.8.5 合并规则

现状能力	来源	App 归属
头像 / 姓名 / 角色	三套各有	个人中心用户卡（姓名以 App Backend 为准，回写各系统）`TODO(REQ-MIN-003)`；头像首版只读（REQ-MIN-020）
切换门店	三套各有	收敛为 App 全局门店上下文（REQ-HOM-001），个人中心不再单独提供；绑定关系权威来源见 REQ-MIN-007
修改手机号 / 换绑手机	O2O + 设计稿	个人中心，须双向验证（REQ-MIN-012）
退出登录	O2O + 设计稿	个人中心，需二次确认（REQ-LGN-008）
在线客服 / 服务热线 / 经销商客服	O2O + 设计稿	个人中心（三个客服入口是否合并 —— `TODO(REQ-MIN-004)`）；须支持按渠道分列（REQ-MIN-008）
我的账户（额度/返利/券/积分）	ROOS	个人中心资产卡 + 二级页；采购返利与营销返利须分列（REQ-MIN-009）；营销返利明细见 4.11
优惠券	ROOS + O2O	个人中心，保留五状态 + 两种券种（REQ-MIN-010）；营销侧发放见 4.13
收货地址 / 地址管理	ROOS + 设计稿	个人中心（REQ-MIN-014）
我的收藏	ROOS + 设计稿	个人中心（REQ-MIN-015）
支付优先级设置	ROOS	个人中心（或下沉到采购结算）`TODO(REQ-MIN-005)`；实为「是否优先使用微信支付」（REQ-MIN-011）
经营范围	O2O + 设计稿	设计稿放在个人中心，现状在店铺管理下 —— 归属待定 `TODO(REQ-MIN-006)`，现状见 4.9
条码库存	ROOS	下沉到 4.7 库存
对账单	ROOS	下沉到 4.10 财务与对账
经营业绩	ROOS	下沉到 4.12 经营业绩与报表
跳转其它小程序	ROOS	取消；「账户管理」小程序的能力承接范围见 REQ-MIN-018
本月进度（门店考核卡）	ROOS	V1.1 补入 —— 下沉到 4.12 经营业绩与报表（REQ-MIN-017）
员工管理	ROOS	V1.1 补入 —— 下沉到 4.9 门店管理的人员管理与授权（REQ-MIN-017）
我的订单（四状态入口）	ROOS	V1.1 补入 —— 下沉到 4.6 采购的订单列表（REQ-MIN-017）
关于 / 版本号	ROOS	V1.1 补入 —— 个人中心新增，含版本号、用户协议、隐私政策、检查更新（REQ-MIN-016）

三套「我的」的合并归属（原 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 逐图核对现状后补写。

REQ-MIN-007 门店绑定关系与切换门店 —— App 可切换的门店列表以 App Backend 的「人员–门店」绑定关系为唯一权威，由后台聚合三套现状系统的绑定并按门店主编码去重；列表须支持按门店名 / 编码搜索，当前门店置顶并以选中态标识（现状 O2O 单账号已绑定 13 家以上门店，无搜索）。切换门店后须刷新全局门店上下文并重载所有业务数据。切店时购物车、未提交表单、已打开的 H5 页面如何处理未定 —— TODO(REQ-MIN-007)。
REQ-MIN-008 服务热线按渠道分列 —— 服务热线数据集须支持「渠道 → 号码」多条记录（现状 6 条：小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），由后台维护、App 动态渲染，不得在客户端硬编码，号码变更无需发版。点击行为统一为唤起系统拨号盘。现状高德、美团用的是个人手机号，是否替换为总机分机 —— TODO(REQ-MIN-008)。
REQ-MIN-009 资产结构与两套返利体系 —— 「我的账户」保留四层结构：授信（可用余额 / 信用额度 / 待还金额）、未使用返利、优惠券、积分。其中：信用额度未授信时显示「——」，不得显示 ¥0.00（空值与零值语义不同）；采购返利（按「品牌–区域」累计，用于抵扣货款，见 4.6 采购）与营销返利（消费者补贴 / 安装费用 / 抽奖红包，见 4.11 返利中心）必须分列展示，不得合并为一个「返利」数字；积分区分「通用兑换 / 运营物料」两类。四项资产在设计稿两张资产卡里如何落位、优惠券展示张数还是总金额、采购返利品牌枚举（现状含 Continental / Viking / 卡迪睿德 / 其他业务）是否完整 —— TODO(REQ-MIN-009)。
REQ-MIN-010 优惠券状态与券种 —— App 优惠券列表保留五状态页签（待激活 / 待生效 / 待使用 / 已使用 / 已失效）与「马牌券 / 经销商券」二级券种筛选，两级筛选可叠加。「待激活」状态的激活入口、激活条件与激活后是否立即可用未定 —— TODO(REQ-MIN-010)。
REQ-MIN-011 支付优先级设置的语义 —— 该设置的现状语义是单一二值开关「是否优先使用微信支付」，不是V1.0 原文所写的「是否优先使用扣账支付方式」，不得实现为多支付方式排序。该设置是账号级还是门店级、变更后对已在购物车中的商品是否即时生效未定 —— TODO(REQ-MIN-011)。
REQ-MIN-012 换绑手机的双向验证与脱敏 —— App 换绑手机须同时验证原号与新号（原号验证码证明账号归属，新号验证码证明新号可用），不得沿用现状「验证码只发原号」的单向流程；页面展示的当前手机号须脱敏为 138****7616；提交按钮在必填项补齐前保持禁用态。
REQ-MIN-013 姓名的可编辑性与校验 —— 姓名编辑弹窗必须预填当前姓名；须做长度（2–20 字符）与字符集校验，禁止纯空白；保存成功后立即回填用户卡。权威来源与回写到哪几套系统 —— 见 TODO(REQ-MIN-003)。
REQ-MIN-014 地址管理能力与数据规范 —— 地址管理须提供新增 / 编辑 / 删除 / 设为默认四项能力（现状页面未见新增入口）；省 / 市 / 区为结构化字段，详细地址不得重复拼接省市区（现状存在「上海市上海市浦东新区上海市浦东新区南桥路1200号」这类脏数据），提交时须校验并在展示时规范化；保留「查看定位」入口，与 4.7 库存扫码入库的门店定位校验同源。收货地址的权威数据源（是否来自马上下单接口） —— TODO(REQ-MIN-014)。
REQ-MIN-015 收藏列表的价格与操作权限 —— 收藏列表的价格显示须遵从与商品列表一致的价格可见性策略（见 4.7 库存的 TODO(REQ-INV-001)），不得成为绕过价格管控的旁路；附录 B 中技工对「我的收藏」的 🔸 只读，明确为可查看、不可取消收藏、不可加入购物车。
REQ-MIN-016 关于 / 版本号入口 —— 个人中心须提供「关于」入口，至少包含：App 版本号与构建号、用户协议、隐私政策、检查更新（对接 OTA 分发）、备案信息。该入口在现状 ROOS 中存在（「关于 V2.66.96」），但设计稿完全缺失，属发版合规必备项。
REQ-MIN-017 下沉能力不在个人中心重复提供 —— 「本月进度」考核卡下沉到 4.12 经营业绩与报表、「员工管理」下沉到 4.9 门店管理、「我的订单」下沉到 4.6 采购；个人中心不再重复提供入口，避免同一能力两处维护。
REQ-MIN-018 「账户管理」小程序的能力承接 —— 现状 ROOS 通过微信系统弹窗跳转「账户管理｜德国马牌轮胎」小程序，该小程序不在本 PRD 的现状系统清单内。按 4.8.5「跳转其它小程序 → 取消」的原则，App 须自行承接其能力。承接范围（是否只需授信 / 返利 / 券 / 积分的查询，还是包含还款、开票等写操作）与接入方式（直连其后端 / 由 App Backend 代理 / 内嵌 H5）未定 —— TODO(REQ-MIN-018)。
REQ-MIN-019 登出的清除范围与多设备会话 —— 登出二次确认弹窗须说明后果（将清除本地登录态、门店上下文与缓存业务数据），不得像现状那样只有「确认登出」四字；登出后本地 Token、门店上下文、缓存业务数据全部清除。多设备可同时登录、单设备登出不影响其它设备（附录 A.9 第 5 条），与账号共用治理诉求的张力见 TODO(REQ-LGN-009)。
REQ-MIN-020 头像首版只读 —— 首版头像不提供上传，统一使用系统默认头像 + 角色底色（避免引入图片审核、存储与合规成本）；现状三套小程序中虽有编辑入口（延保），但全部截图均为默认头像，无实际使用。如业务需要自定义头像，另行提需求。

4.8.7 验收标准

个人中心显示的门店与全局门店上下文一致，切店后资产数据同步刷新；
退出登录后本地 Token、门店上下文、缓存业务数据全部清除（见《App 门店上下文与会话管理文档》）；
角色标签与后台下发的角色一致，技工不显示店长专属资产项；
门店切换列表支持按门店名 / 编码搜索，当前门店置顶并高亮；绑定 20 家门店的账号可在 3 秒内定位到目标门店（REQ-MIN-007）；
「我的账户」中采购返利与营销返利分列展示，两个数字来源不同接口且互不相加；信用额度未授信时显示「——」（REQ-MIN-009）；
换绑手机须原号与新号各验证一次，任一验证失败即不落库；页面展示的手机号已脱敏（REQ-MIN-012）；
姓名编辑弹窗打开时输入框已预填当前姓名；提交空白或超长姓名被拦截并给出提示（REQ-MIN-013）；
新增地址时详细地址中重复填写省市区会被校验拦截；地址列表按默认状态与使用时间排序（REQ-MIN-014）；
服务热线列表从后台接口动态获取，后台新增一条渠道热线后 App 无需发版即可展示（REQ-MIN-008）；
「关于」页展示的版本号与安装包版本一致，用户协议与隐私政策可正常打开（REQ-MIN-016）；
技工登录后个人中心不出现「本月进度」「员工管理」「我的订单」等已下沉入口，且资产卡按 TODO(REQ-MIN-002) 的结论展示或隐藏。

4.9 门店管理

业务目标 —— 门店管理的入口在「我的」菜单，门店管理包括门店的基础信息，人员管理，门店项目信息，营业执照信息等

入口 —— 「我的」菜单 → 门店管理；宫格版导航中为一级 tab（见三版底部导航方案）

页面内容 —— 四个 Tab：基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息；另有人员管理、收款信息、经营范围与开票方式、协议中心

主流程 —— 进入门店管理 → 切换 Tab 查看 → 点击「修改」提交变更 →（如需）等待审核

现状有三种互不相同的「修改」交互模型，见各图说明与 REQ-STM-007：基础信息 tab 整页只读、无任何修改入口；2.0 店铺信息 tab 是逐字段「修改」链接；营业执照 tab 是整页「修改执照信息」按钮 + 独立编辑页。设计稿统一为底部一个「修改」按钮，与现状三种模型都不一致。字段级可编辑性必须逐字段定义。

权限规则 —— 店长可以修改门店基础信息，添加和修改人员，修改门店项目信息，营业执照信息；技工基本没有门店管理权限

数据来源 —— O2O（店铺管理、经营范围、协议）、马上下单（门店主数据）、App Backend（人员与授权）

4.9.1 目标形态

页面内容 —— App 门店管理的设计稿：四个 Tab（基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息，当前选中「基础信息」）之下依次是门头照通栏、门店卡、负责人与联系方式、「收款信息 >」入口和一组渠道到期状态（高德、美团均标 已过期），底部为描边「修改」按钮。

关键交互 —— ①点四个 Tab → 切换内容；②点「收款信息 >」→ 进入二级页（现状对应银行账号）；③点底部「修改」→ 进入编辑态提交变更；④渠道行本图未见 > 或可点标识，是否可下钻无法确认。

可用角色 —— 店长 ✅；技工 🔸 只读（附录 B「查看门店信息」为 🔸，「修改基础信息」为 ✗，故技工看到本页时底部「修改」按钮不可见，见验收标准第 1 条）。

需求关联 —— REQ-STM-002 Tab 口径、REQ-STM-006 渠道到期提醒、REQ-STM-007 主数据边界、REQ-STM-009 渠道口径

三处与现状对不上，都需要在开发前定：

渠道到期状态被放在「基础信息」Tab，而页面上另有一个独立的「渠道信息」Tab。 同一类信息出现在两个 Tab 里，职责边界不清。现状中这组数据其实在「2.0 店铺信息」Tab 下，而「渠道信息」Tab 装的是完全不同的东西（见 4.9.2）。

设计稿只画了 4 个渠道（高德 / 美团 / 抖音团购 / 百度），现状有 6 个（多出车点点与零跑）。且设计稿把抖音团购标为「未上线」，现状是「已上线」——设计稿的渠道数据已过时。

联系方式 13496913568 完整显示未脱敏，与银行账号页的脱敏口径问题同源，须统一，见 TODO(REQ-FIN-014)。

页面内容 —— App 人员管理的设计稿：顶部是当前操作人卡（带橙色「店铺管理员」标签），下方两张店员卡各含姓名、「店长权限」标签、「账户设置 >」入口与一行「可用系统」图标，底部为通栏「添加店员」，三张卡姓名相同、图标重复排列，属占位数据。

关键交互 —— ①点「账户设置 >」→ 进入该店员的账户与权限设置；②点底部「添加店员」→ 新增店员流程；③「可用系统」图标行本图未见可点标识，是在账户设置里配置还是就地可点，无法确认。

可用角色 —— 店长 ✅；技工 ✗（附录 B「人员管理与授权」标为高风险、需审计，技工完全不可见，含深链拦截）。

需求关联 —— REQ-STM-001 人员授权模型、REQ-STM-005 技工权限

「可用系统」是一个独立于角色的授权维度 —— 它意味着人员授权不是单一角色开关，而是「角色 + 可访问子系统集合」的二维模型（如某店员有店长权限但只开通 O2O 与采购）。这与 REQ-PUR-001（技工采购授权）是同一套机制。可用系统的取值集合、与角色的关系 —— TODO(REQ-STM-001)。

设计稿另有三处缺口：

图标没有文字标签，「可用系统」到底有哪几个系统、每个图标代表谁，从设计稿完全读不出来。这正是 TODO(REQ-STM-001) 要解决的取值集合问题 —— 在它关闭前，本页无法进入开发。

角色词汇有三套：本页的「店铺管理员」（当前操作人）与「店长权限」（店员卡），加上第 3 章定义的「店长 / 技工」。三者是同义、包含还是并列，须收敛为一套，否则权限矩阵无法落地。

没有一张技工卡片，也没有删除或停用店员的入口。店员离职是门店高频场景，缺了这条链路，人员管理无法闭环。已并入 REQ-STM-001。

4.9.2 门店基础信息与渠道信息

页面内容 —— O2O 店铺管理的「基础信息」Tab（四个 Tab 为基础信息 / 2.0店铺信息 / 营业执照信息 / 渠道信息），内容是门店名称、门店主编码、收款信息、负责人姓名、联系方式、门店地区、详细地址、门店评分、门头照片九行只读字段，本图为测试数据（门店名称「豌豆的小店」、负责人「豌豆」）。

关键交互 —— ①点 Tab → 切换；②点「收款信息查看详情 >」→ 进入收款信息二级页。本页没有任何修改入口 —— 整页只读。

可用角色 —— 店长 ✅；技工 🔸 只读。

需求关联 —— REQ-STM-002 Tab 口径、REQ-STM-007 主数据边界

与设计稿的字段差异：现状把地址拆成「门店地区 + 详细地址」两个字段，设计稿合并为一个「门店地址」；现状叫「门店主编码」，设计稿叫「门店编码」（编码值 3449155 一致）。这两处属字段口径，以现状为准，并在设计稿评审时提出。

「收款信息」的模块归属存在冲突：附录 A.7 第 6 条把「收款信息结果集（O2O 平安账号模块 —— 企业银行账号、改绑手机、解绑银行卡）」列在门店管理名下，而正文把银行账号写在财务与对账 4.10.5 里；附录 C 的来源表也把两张银行账号截图归到门店管理。同一份数据在三处被分到两个模块，须择一。建议按用户心智留在财务模块，附录 A.7 与附录 C 来源表据此改归 FIN。

页面内容 —— 「2.0 店铺信息」Tab，由门店联系信息（每行右侧各有一个橙色「修改」链接）、渠道上线与到期状态六行（高德与美团均 已过期，零跑按服务项分别记状态）、门店本地化服务项目价目表三块组成。

关键交互 —— ①点任一行的「修改」→ 单独编辑该字段；②点「门店本地化服务项目」的「修改」→ 编辑价目表；③渠道行无修改入口，为只读展示。

可用角色 —— 店长 ✅；技工 ✗（涉及对外报价与渠道状态）。

需求关联 —— REQ-STM-002 Tab 口径、REQ-STM-006 渠道到期提醒、REQ-STM-008 本地化服务项目与自主定价、REQ-STM-009 渠道口径

本图是 STM 模块信息量最大的一张，暴露三件 PRD 完全没写的事：

门店可以自主维护一张服务项目价目表（两列「名称 / 价格」，本图可见泰克贴片补胎 50、泰克蘑菇钉补胎 100、四轮换位 70、普通四轮定位 99、全车手工打蜡-轿车 148、全车手工打蜡-SUV/MPV 198、标准洗车-轿车 30，末行被截断，即七项以上、价格 30~198 元不等）。这是门店对外报价的依据，直接影响销售与财务收入，PRD 全文一字未提。已记为 REQ-STM-008。

现状渠道有 6 个，且零跑的状态是按服务项分别记的（「洗车服务已上线，补胎服务已上线」），而其它 5 个是整体「已上线 / 未上线 / 已过期」。渠道状态模型不统一，见 REQ-STM-009。

修改是逐字段的，与设计稿「底部一个修改按钮提交整页」的模型冲突，也与营业执照 Tab 的整页编辑模型冲突。三种模型必须收敛，见 REQ-STM-007。

另一处数据疑点：本 Tab 的「联系人」为宛玉，而基础信息 Tab的「负责人姓名」为豌豆，同一门店两个名字。二者是两个不同角色字段（负责人 ≠ 联系人）还是数据不同步，本图无法确认，须在字段口径中明确。

页面内容 —— 「渠道信息」Tab，页面几乎为空，只有一个分组标题「渠道资料　（如需申请渠道上下线请联系 SR）」与其下「小程序」小节里唯一一行灰色的「维京　关闭」。

关键交互 —— 本页无任何可交互控件 —— 纯只读展示，渠道上下线需线下联系 SR（马牌销售代表）办理。

可用角色 —— 店长 ✅ 只读；技工 ✗。

需求关联 —— REQ-STM-009 渠道口径与上下线申请

「渠道」在同一个页面里有两种完全不同的含义：

「2.0 店铺信息」Tab 里的渠道 = 外部平台（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑），管的是门店在各引流平台的上线与到期；

「渠道信息」Tab 里的渠道 = 小程序内的品牌线（小程序 → 维京关闭），管的是门店能卖哪些品牌。

两者共用一个词，放在相邻的两个 Tab 里，门店必然混淆。整合进 App 时必须拆成两个术语（如「平台渠道」与「品牌授权」），见 REQ-STM-009。这也是全仓库渠道口径不统一问题的一部分。

另一条可直接成文的规则：渠道上下线不能自助，须联系 SR。App 内是保留这条线下指引，还是做成可提交的申请单，需决策。

现状 Tab 名为「2.0 店铺信息」，设计稿对应位置为「门店项目信息」。二者是否同一内容 —— TODO(REQ-STM-002)。从截图看两者内容差异很大：现状的「2.0 店铺信息」含联系信息、渠道状态与服务价目表三块，设计稿的「门店项目信息」未出稿，无从比对。这条待确认必须在设计稿补齐后才能关闭。

4.9.3 营业执照信息

页面内容 —— 「营业执照信息」Tab，仅营业执照照片、企业名称、统一社会信用代码三行加底部通栏橙色「修改执照信息」按钮，本图为测试数据（企业名称与轮胎门店业务无关）。

关键交互 —— ①点「修改执照信息」→ 进入编辑页（见下图）；②点照片缩略图是否可放大，本图无法确认。

可用角色 —— 店长 ✅；技工 ✗（附录 B「修改基础信息 / 项目信息 / 营业执照」为 ✗）。

需求关联 —— REQ-STM-003 资质变更审核、REQ-STM-012 协议中心清单

营业执照有两个入口：本 Tab 与协议中心（在那里显示为「营业执照　已上传」）。同一份资质在两处维护，状态是否同源、从哪个入口改，须择一为主入口。

页面内容 —— 营业执照编辑页，上半部为「上传营业执照」及三条填写须知与压着「更换图片」的执照缩略图，下半部为「请确认营业信息」的两个可编辑输入框（企业名称、统一社会信用代码，均已带值），底部为通栏橙色「保存」。

关键交互 —— ①点「更换图片」→ 弹出上传方式选择（见下图）；②点两个输入框 → 直接编辑文本；③点「保存」→ 提交变更。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-STM-003 资质变更审核

三条须知原文，均为可校验的规则，须原样保留：①「请确保证件内容文字清晰可见，证件本身无残缺」；②「仅支持中国大陆工商局或市场监督管理局登记的个体工商户或企业，请提供有效期内的营业执照」；③「无企业名称的个体工商户，营业执照–企业名称栏，请填写营业执照–『法人姓名』，示例数据：张三」。

页面结构是「先传图 → 再确认营业信息」，强烈暗示存在证照 OCR 识别后回填，但本图两个输入框均为可编辑状态、也没有「识别中」之类的提示，是否真有 OCR 无法从本图确认。若确有，需与车牌 OCR一样明确由后端代理调用、客户端不直连。

变更后是否需要审核，本页看不出来 —— 点「保存」是直接生效还是转入待审，无任何提示。TODO(REQ-STM-003)。

页面内容 —— 上一页点「更换图片」后从底部弹出的选择面板，三项：拍照 / 从手机相册选择 / 取消。

关键交互 —— ①点「拍照」→ 唤起相机；②点「从手机相册选择」→ 打开相册；③点「取消」或遮罩 → 关闭。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-STM-003 资质变更审核（验收标准第 3 条要求两种上传方式并支持弱网重试）

本图直接印证验收标准第 3 条的前半句「支持拍照与相册两种方式」。后半句「弱网下失败可重试且不丢失已填字段」在现状截图中无从验证，属 App 侧新增要求。

营业执照变更是否需要审核、审核在哪个系统完成 —— TODO(REQ-STM-003)。

4.9.4 经营范围与开票方式

页面内容 —— 标题为「经营范围」的入口页，全页只有「经营范围 >」与「开票方式　非自行开票 >」两行。

关键交互 —— ①点「经营范围 >」→ 进入经营范围详情（见下图）；②点「开票方式 >」→ 进入开票方式选择页。

可用角色 —— 店长 ✅；技工 ✗（涉及资质与资金）。

需求关联 —— REQ-STM-010 经营范围三类资质、REQ-STM-011 开票方式

页面标题是「经营范围」，但内容包含并列的「开票方式」，标题与内容不匹配。整合到 App 时应重命名为「经营范围与开票」或把开票方式移到财务模块下。

页面内容 —— 经营范围详情，由会员体系门店（待申请）/ 认证轮胎技术检测中心（查看）/ 单独服务项（管理）三个互相独立的资质分组构成，其中的服务标签混有大量回归测试数据。

关键交互 —— ①点「待申请 >」→ 发起会员体系门店申请（本图为待申请态，申请表单与流程无法确认）；②点「查看 >」→ 查看 CATI 认证详情；③点「管理 >」→ 进入单独服务项开通页。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-STM-010 经营范围三类资质

三个分组对应三个不同的动词（待申请 / 查看 / 管理），说明它们是三套独立的资质流程，而不是一张清单的三段：

会员体系门店 —— 需申请，有准入门槛（必须具备清单内的全部服务）；

CATI 认证轮胎技术检测中心 —— 由马牌授权，门店只能查看，不能自助申请；

单独服务项 —— 门店可自助逐项开通。

PRD 现有正文只把「经营范围」当作一个归属待定的页面（TODO(REQ-MIN-006)），完全没有涉及这三套流程。已记为 REQ-STM-010。

CATI 定义原文（需在 App 内保留）：「CATI（Continental Approved Tire Inspector）是大陆马牌轮胎（中国）有限公司认证的轮胎技术检测中心。该授权中心能够及时处理客户轮胎投诉以及轮胎售后技术咨询服务。」

页面内容 —— 开票方式选择页，「自行开票」与「非自行开票」两张卡片各带一个勾选框、单选（当前选中「非自行开票」），卡片下各列若干条说明，底部为通栏橙色「确认」按钮。

关键交互 —— ①点任一卡片的勾选框 → 切换开票方式（互斥）；②点「确认」→ 提交。切换是否有二次确认、是否有生效时点限制，本图无法确认。

可用角色 —— 店长 ✅；技工 ✗（直接影响资金结算）。

需求关联 —— REQ-STM-011 开票方式与 13% 扣除、REQ-STM-013 百望云初始密码

本图是全模块财务影响最大的一张。「非自行开票」的说明第 1 条写明：「您的服务费货款将自动扣除 13%，并将定期打款到您小程序绑定的银行卡。」

13% 远高于财务模块列出的全部平台费率（0.6%~4%），却在财务模块的收入构成里完全看不到 —— 收入详情页只有「通道费」一项扣减。这两笔扣减的关系必须查清，否则门店对不上账。已记为 REQ-STM-011，并需与 TODO(REQ-FIN-011) 一并解决。

「自行开票」路径引入了一个 PRD 系统清单里没有的第三方系统 —— 百望云（电子发票平台）：需自备电子发票资质、登录百望云完善开票信息、另填并上传对公银行信息。星号补充「登陆接单宝小程序，点击『协议中心』查看百望云初始账户密码」既是又一处「请回小程序」的引导，也是一处安全问题，见 REQ-STM-013。

另注：「非自行开票」说明第 2 条「请确认您已将收款方式转成银行卡收款，如需修改收款。」句子未写完，属现状文案缺陷，App 内须补全。

页面内容 —— 单独服务项开通页，主体是 7 行服务项开关（部分名称右侧带橙色「会员」小标，其中 3 项是回归测试数据），底部为一行协议勾选加通栏橙色「保存」。

关键交互 —— ①逐项点开关 → 开通 / 关闭该服务；②点协议名称 → 打开协议全文；③勾选协议后点「保存」→ 提交。未勾选协议时「保存」是否禁用，本图无法确认。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-STM-010 经营范围三类资质、REQ-STM-004 协议体系

两条可直接成文的规则：①开通服务项须先同意《德国马牌门店非轮胎项目服务协议》，协议同意与服务开通是同一次提交；②带「会员」标记的服务项归属会员体系，与上一页「会员体系门店必须包含以下服务」的清单存在交集 —— 单独开通这些项与申请会员体系门店是什么关系（前置条件？自动满足？），须明确。

这条协议同时说明协议中心不是唯一的协议入口 —— 协议也会内嵌在业务动作里，REQ-STM-004 的「协议体系是否合并」需要把这类内嵌协议一并纳入考虑。

经营范围在设计稿中被放进了个人中心，在现状中属于店铺管理。归属待定 —— TODO(REQ-MIN-006)。

4.9.5 协议中心

页面内容 —— 协议中心，营业执照（已上传）与三份协议（均已签署）共四张卡片纵向排列、下方接 4 条说明，本图四项均为完成态，未签署 / 未上传的形态无法确认。

关键交互 —— ①点任一卡片 → 打开对应协议全文或执照详情（见下图）；②已签署项是否可重新签署、未签署项如何发起签署，本图无法确认。

可用角色 —— 店长 ✅；技工 🔸 只读（附录 B「协议中心」为 🔸）。

需求关联 —— REQ-STM-004 协议体系、REQ-STM-012 协议中心清单与状态、REQ-STM-013 百望云初始密码

四条说明原文：①「如您的门店已参与德国马牌的非轮胎活动，请确认您已签署相关服务协议」；②「如果您参与非轮胎项目，且选择了自行开票，请注意及时上传对公银行账户信息」；③「如果您未参与非轮胎项目或您参与了非轮胎项目后，选择的是『非自行开票』，则无需维护对公银行账户信息」；④「百望云账号密码仅为初始密码，登录后请及时修改」。

说明 ②③ 把**协议中心 ↔ 开票方式 ↔ 对公银行账户**三者锁在一起：是否需要维护对公账户，取决于「是否参与非轮胎项目」与「开票方式选哪种」的组合。这套判定逻辑必须在 App 内成文，否则门店不知道自己该不该填银行信息。

说明 ④ 与开票方式页的星号补充合起来意味着：协议中心是一个第三方系统初始密码的分发渠道。密码明文常驻在一个门店随时可进的页面里，风险明显。已记为 REQ-STM-013。

另注状态词有两套：营业执照用「已上传」，三份协议用「已签署」。它们的完成条件与法律效力不同，混在一张列表里易误解，App 内建议分组或补充状态说明。

页面内容 —— 《德国马牌轮胎小程序线下门店合作协议》全文页，开头为甲方（大陆马牌轮胎（中国）有限公司，简称"德国马牌"）与空白的乙方，其后本屏可见「乙方需履行以下几项义务」的第 1~9 条（第 9 条被截断）。

关键交互 —— 无交互，仅作内容佐证；页面为可滚动长文，本图未见「同意」「签署」按钮（该协议已处于已签署态）。

可用角色 —— 店长 ✅ 只读；技工 🔸 只读。

需求关联 —— REQ-STM-004 协议体系、REQ-STM-014 合作协议义务的系统承接

协议正文里有三条可被系统承接的门店义务，目前 PRD 里一条都没有对应功能：

第 1 条：「由德国马牌轮胎小程序引流产生的轮胎销售必须在下月 15 号前从当地认证经销商处完成补货。」—— 一条带明确截止日的周期性义务，天然适合做成提醒或首页待办。

第 5 条：「乙方需要在轮胎安装前向终端消费者索取安装码，并核销。」—— 与销售模块的核销是同一动作，且核销又是可提现金额的计算基数，三者须口径一致。

第 7 条：「如终端消费者需要开具发票，乙方必须按终端消费者实际支付金额开具……不得以任何理由拒绝开具发票。」—— 与开票方式的选择相互作用。

已记为 REQ-STM-014。

「乙方」栏空白但状态显示「已签署」 —— 本页展示的可能是协议模板而非门店签署后的实例。App 内应展示带乙方主体与签署时间的实例，否则「已签署」无从取证。本图无法确认该页是否另有签署信息区被折叠。

协议中心与延保零售商使用条款是两套独立的协议体系，整合后是否合并为统一的「协议与条款」入口 —— 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 渠道到期提醒 —— 高德 / 美团 / 抖音 / 百度等渠道到期应产生首页待办或预警 TODO(REQ-STM-006)

REQ-STM-007 主数据边界 —— 门店主数据来源为马上下单（第 5 章），App 内可改的字段范围待定 TODO(REQ-STM-007)。须同时定义修改交互模型 —— 现状三种模型并存（基础信息只读 / 2.0 店铺信息逐字段改 / 营业执照整页改），App 内须统一，并逐字段标注可编辑性

REQ-STM-008 门店本地化服务项目与自主定价 —— 门店可在「2.0 店铺信息」下维护一张本地化服务项目价目表（名称 + 价格，现状可见泰克贴片补胎 50、四轮换位 70、全车手工打蜡-SUV/MPV 198 等七项以上），带独立编辑入口。该价目表是门店对外报价依据，须在 App 内可查可改。

待确认 TODO(REQ-STM-008)：①价格是否有上下限管控或需审核；②与经营范围「单独服务项」的关系（同一批服务项还是两套清单）；③与销售开单时的取价关系 —— 开单是否直接引用这张价目表。

REQ-STM-009 渠道口径与上下线申请 —— 「渠道」须拆分为两个互不相同的概念并分别命名：平台渠道（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑，管上线与到期）与品牌授权（小程序下的品牌线，如维京，管可售品牌）。渠道上下线不支持自助，须联系 SR，该指引须在 App 内保留。

待确认 TODO(REQ-STM-009)：①两个概念的最终命名与页面归属（现状分散在「2.0 店铺信息」与「渠道信息」两个 Tab，设计稿又把平台渠道画在「基础信息」Tab）；②渠道状态模型不统一 —— 零跑按服务项分别记状态（洗车已上线 / 补胎已上线），其余按渠道整体记；③平台渠道枚举须与财务、返利、业绩统一，收敛进主数据；④渠道上下线申请是否做成 App 内可提交的申请单。

REQ-STM-010 经营范围的三类资质 —— 经营范围由三套独立流程构成，须分别落地：会员体系门店（需申请，准入条件为具备指定服务清单，现状为「待申请」）、CATI 认证轮胎技术检测中心（马牌授权，门店只可查看）、单独服务项（门店自助逐项开关）。单独服务项的开通须同时勾选同意《德国马牌门店非轮胎项目服务协议》，协议同意与开通为同一次提交；带「会员」标记的服务项归属会员体系。

待确认 TODO(REQ-STM-010)：①会员体系门店的申请表单、审核方与时效；②CATI 认证是否有 App 内可发起的路径，还是纯线下授权；③单独开通带「会员」标记的服务项与申请会员体系门店之间是前置、等价还是无关。

REQ-STM-011 开票方式与 13% 扣除 —— 开票方式为二选一：自行开票（需自备服务费电子发票资质、登录百望云完善开票信息、填写并上传对公银行信息）与非自行开票（服务费货款自动扣除 13%，定期打款到小程序绑定的银行卡）。两种方式的说明条文须原样展示；「非自行开票」路径下无需维护对公银行账户。

待确认 TODO(REQ-STM-011)：①13% 与财务模块的通道费 / 平台手续费是什么关系 —— 现状收入详情只显示通道费，13% 无处体现，门店无法对账，须与 TODO(REQ-FIN-011) 一并解决；②百望云是否需要在 App 内打通，还是保留外跳；③切换开票方式的生效时点、是否可反复切换、对已生成结算单的影响。

REQ-STM-012 协议中心的清单与状态 —— 协议中心承载 4 项：营业执照（状态「已上传」）与三份协议（小程序轮胎合作协议 / 非轮胎项目服务协议 / 认证轮胎技术检测中心合作协议，状态「已签署」）。营业执照同时存在于营业执照信息 Tab，两处须同源并指定唯一编辑主入口。协议正文须可完整查看。

待确认 TODO(REQ-STM-012)：①未签署 / 未上传态的形态与签署交互（现状截图四项均为完成态，无从确认）；②签署是否需要电子签名与留痕，是否计入审计日志；③协议全文页应展示签署实例（含乙方主体与签署时间），现状展示的疑似模板，「乙方」栏为空。

REQ-STM-013 第三方系统初始密码不得明文承载 —— 现状把「百望云账号初始密码」放在协议中心供门店自行查看。App 内不得以明文常驻方式展示任何第三方系统的账号密码。

待确认 TODO(REQ-STM-013)：替代方案待定 —— 一次性查看后失效、改由后台按需重置下发、或 App 完全不承载（仅保留百望云官方找回路径）。决策方：安全 / 产品。

REQ-STM-014 合作协议义务的系统承接 —— 《德国马牌轮胎小程序线下门店合作协议》中的可执行义务须由系统承接而非仅靠门店自觉：①小程序引流产生的轮胎销售须在下月 15 号前从当地认证经销商完成补货；②安装前须向消费者索取安装码并核销；③消费者要求开票时不得拒绝。

待确认 TODO(REQ-STM-014)：①「下月 15 号前补货」是否做成周期性提醒或首页待办，未完成是否需要预警；②协议中的「安装码」与销售模块的核销码是否同一物，术语须统一；③三条义务是否需要在管理后台侧有对应的监控或考核。

4.9.7 验收标准

技工进入门店管理时，所有「修改」「添加店员」入口不可见；
门店编码、门店名称等主数据字段为只读，与马上下单一致；
营业执照上传支持拍照与相册两种方式，弱网下失败可重试且不丢失已填字段；
渠道到期状态与实际签约状态一致，已过期渠道有明显视觉标记；
每个可编辑字段都有明确的可编辑标识，修改交互模型全 App 统一，不出现「同一页面部分字段逐个改、部分字段整页改」（REQ-STM-007）；
「平台渠道」与「品牌授权」在文案上明确区分，不出现两处都叫「渠道」的情况（REQ-STM-009）；
单独服务项未勾选协议时「保存」不可提交，协议全文可从勾选行直接打开（REQ-STM-010）；
开票方式页完整展示两种方式的全部说明条文，含 13% 扣除比例，且文案完整无断句（REQ-STM-011）；
App 内任何页面不出现第三方系统的明文账号密码（REQ-STM-013）；
App 内所有门店管理页面不出现「请登录接单宝小程序」类引导，全部改为 App 内路径（REQ-STM-011）。

第 5~10 条为本次逐图核看后新增。

4.10 财务与对账

本节内容由 O2O 与 ROOS 的对账 / 提现 / 结算截图反推。本模块没有任何设计稿 —— 11 张图全部是现状小程序，App 目标形态尚未出稿。

业务目标 —— 让门店在 App 内看清「挣了多少、能提多少、什么时候到账、和厂商怎么对账」，解决痛点 2.4与痛点 2.5

入口 —— 「我的」菜单 → 对账提现 / 对账单；宫格版导航中为一级 tab「账务对账」

页面内容 —— 对账提现（可提现金额 + 收入 + 提现历史）、收入明细、服务结算单、结算单明细、采购对账单、银行账号绑定

主流程：

查看可提现金额 → 进入收入 / 提现历史核对 → 系统按工作日自动提现 → 到账（门店不主动发起提现，见 REQ-FIN-008）
结算侧：按周期查看服务结算单 → 核对明细 → 在本月 7 号前确认结算单（逾期自动确认，见 REQ-FIN-012）
采购侧：按月查看对账单 → 核对汇总与明细

权限规则 —— 建议限店长（涉及资金）TODO(REQ-FIN-001)

数据来源 —— O2O（O2O 收入、提现、服务结算单、银行账号）、ROOS（采购对账单）

4.10.1 对账提现

页面内容 —— O2O 对账提现首页，橙色头部为「¥0.00 / 可提现金额（元）」与一段说明更新时点的注解，下方是「收入 >」「提现历史 >」两个入口行与蓝色文字链「交易手续费说明」，本截图为 ¥0.00 空态。

关键交互 —— ①点「收入」→ 进入收入明细；②点「提现历史」→ 进入提现流水；③点「交易手续费说明」→ 弹出费率说明（见下图）。

可用角色 —— 店长 ✅；技工 ✗（附录 B 为 ✗，且 TODO(REQ-FIN-001) 关闭前一律按技工完全不可见实现，含深链拦截）。

需求关联 —— REQ-FIN-002 可提现金额口径、REQ-FIN-006 手续费透明、REQ-FIN-008 提现由系统自动发起

本页没有「提现」按钮。 V1.0 的 4.10 主流程写「查看可提现金额 → 进入收入/提现历史核对 → 发起提现 → 到账」，但页面上只有两个查看入口与一个说明链接，没有任何可以发起提现的控件。结合下一张手续费说明中「每个工作日 15:30 左右系统将自动发起提现，将账户余额全部提出」，可以确认：提现是系统自动执行的，门店不主动发起。上方主流程已据此改写，并新增 REQ-FIN-008。

顶部注解揭示两条关键约束：① 提现金额 T+1 且按工作日更新；② 计入基数的是已核销订单货款 —— 这把核销从一个操作动作提升为资金链路的关键节点。核销 → 可提现的具体计算口径 —— TODO(REQ-FIN-002)。

页面内容 —— 从底部弹出的「交易手续费说明」面板，按「小程序订单」「天猫/京东/拼多多订单」「抖音小店订单」「抖音团购」四段列出结算与费率规则，最后一段被底部按钮遮挡，本图无法确认其内容。

关键交互 —— ①滚动查看各渠道规则；②点右上 ✕ 或底部「确认」→ 关闭。纯内容展示，无其它交互。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-FIN-006 手续费透明、REQ-FIN-008 自动提现、REQ-FIN-009 分渠道结算机制与费率

本图可辨认的规则全文如下，是 REQ-FIN-009 的直接依据：

小程序订单：①每个工作日 15:30 左右系统自动发起提现，将账户余额全部提出；②提现在发起 30 分钟内到账；③平台收取营业收入的 0.6% 作为扣点。

天猫 / 京东 / 拼多多订单：①每月结算两次，货款打入门店的支付宝账号（在「店铺管理–收款信息」维护）；②手续费——天猫 3.1%、京东 3.2%、拼多多百亿补贴 2%、拼多多普通订单 1%（均按货款收入计）。

抖音小店订单：①每月结算两次，货款打入门店的银行卡账号；②手续费——普通订单 2%、达人带货订单 4%。

抖音团购：内容被按钮遮挡，无法确认，需补采截图。

由此得出一条 V1.0 完全未提及的结构性事实：收款账户因渠道而异 —— 小程序走平台账户余额，天猫/京东/拼多多打支付宝，抖音小店打银行卡。也就是说 4.10.5 银行账号那一页只服务抖音小店，而支付宝收款信息根本不在本模块，在「店铺管理」里。整合进 App 后这两处收款配置是否都要收进来，见 TODO(REQ-FIN-009)。

页面内容 —— 提现流水列表，顶部为一条说明到账异常处理的黄色提示条，每行是「提现申请成功」+ 时间戳 + 金额 + 到账状态，本图为测试数据（金额 0.01~0.04 元，状态只有「到账异常」与「到账中」，没有一条成功到账）。

关键交互 —— ①上下滚动查看历史；②点「联系客服」路径由提示条文案引导，本图未见可点的客服入口。行本身不可点击下钻（无 > 或展开标识）。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-FIN-010 提现状态机与到账异常

本图给出三条信息：

状态是两个维度：左列「提现申请成功」是申请状态，右列「到账中 / 到账异常」是到账状态。App 内需要明确两者的组合关系与完整状态机。

时间戳几乎全是 15:00:2x，而手续费说明写的是「每个工作日 15:30 左右」。说明文案与实际执行时点不一致，需确认以哪个为准 —— 门店会拿这句话对时间。

2021 年的三条记录至今仍是「到账中」，挂了四年多。「到账中」是否有超时兜底、是否应自动转为异常并退回资金，现状看不出来。已记入 REQ-FIN-010。

4.10.2 收入明细

页面内容 —— 收入列表页，顶部为可横滑的渠道 tab、筛选行为月份 + 打款状态 + 橙色「下载明细」，其下是灰色汇总条与两行明细（各带渠道标、打款状态标与核销时间），汇总与明细自洽（24.50 × 2 = 49.00）。

关键交互 —— ①横滑或点展开箭头 → 切换渠道 tab；②点月份 → 选择月份；③点「全部打款状态 ▾」→ 按打款状态过滤；④点「下载明细」→ 导出对账文件；⑤点明细行 → 进入收入详情（见下图）。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-FIN-005 金额一致性、REQ-FIN-009 分渠道结算、REQ-FIN-011 收入金额构成

两个需要处理的点：

「下载明细」在 App 内如何落地 —— 小程序里导出一个文件，App 里则涉及下载目录、文件打开方式、iOS 的文件应用权限。这是一处必须给出交互定义的功能，已并入 REQ-FIN-011。

「零跑」标签不在任何一份已知的渠道清单里 —— 既不在返利中心的 8 个渠道里，也不在经营业绩的 7 个渠道里。且本页把「天猫/京东/拼多多」合并成一个 tab，而返利中心是三个独立取值。渠道口径的全面冲突见 REQ-FIN-009。

页面内容 —— 单笔收入的详情页，自上而下为订单信息（商品说明、订单号、流水号、支付渠道、打款状态）、金额构成（订单金额 +¥9.90 / 通道费 −¥0.79 / 货款收入 +¥9.11 / 总收入 +¥9.11）与 6 条备注，底部为橙色「查看订单详情」。

关键交互 —— ①点打款状态旁的「查看」→ 下钻打款详情；②点「查看订单详情」→ 跳转对应销售订单；③滚动阅读备注。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-FIN-005 金额一致性、REQ-FIN-011 收入金额构成

金额构成可从本图直接读出：订单金额 − 通道费 = 货款收入（9.90 − 0.79 = 9.11 ✓），总收入 = 货款收入 + 消费者补贴（本例补贴为 0）。

但通道费与手续费对不上：0.79 ÷ 9.90 ≈ 7.98%，而手续费说明里最高的费率也只有 4%。可见「通道费」是与平台手续费并列的另一项扣减（可能是支付通道费），两者的关系与是否会同时扣，需财务澄清 —— 已记入 REQ-FIN-011。

6 条备注是资金规则的正文，必须在 App 内完整保留（同 REQ-FIN-006 的精神）。其中三条尤其重要：

「凡是使用抖音 / 美团抵用券的订单，券的面额扣除通道费后，将以货款形式打到银行卡」

「京东秒送的货款收入会通过平台直接打款到门店进行结算」

「车点点的货款收入会直接由车点点打款与门店进行结算，本页面仅做展示」

也就是说，有的渠道的钱根本不经过这套结算链路，本页只是展示。哪些渠道属于「仅展示」、在列表里如何标识，需要明确，否则门店会误以为这些钱也会自动到账。另注意备注里又出现了「美团」「车点点」两个此前未列入任何渠道清单的名字。

4.10.3 服务结算单

页面内容 —— 服务结算单页，顶部为结算渠道下拉与跨月日期区间「2024年9月–2024年11月」，中部是「¥0.00 / 结算金额」与「查看详细明细 >」，下方为结算单状态 / 开票方式 / 开票状态 / 打款状态四行加两条说明，本图金额为 ¥0.00 且已是终态。

关键交互 —— ①点「全部结算渠道 ▾」→ 选择结算渠道（见下图）；②点日期区间 → 选择结算周期；③点「查看详细明细 >」→ 进入结算单明细；④未确认时该按钮为可点的「确认结算单」，确认后变为禁用的「结算单已确认」；⑤有异议时可点「重审结算单」（本图为已确认态，该入口未出现，位置与形态无法确认）。

可用角色 —— 店长 ✅；技工 ✗。确认结算单是有财务效力的动作，即便 TODO(REQ-FIN-001) 最终对技工开放财务查看，确认动作也应限店长。

需求关联 —— REQ-FIN-012 结算单确认与重审

本图暴露一整套 V1.0 完全没写的业务流程，两条说明原文如下：

「此份结算单包含天猫 / 京东pop / 小程序渠道汇总金额，请您务必在本月 7 号之前完成确认，否则系统将自动确认。如您对结算单有异议，可点击重审结算单。」

「在您确认结算单之前，请务必确认您已知晓自己的结算方式，如您需要修改结算方式，请登录接单宝小程序进行修改。」

由此得到三条必须成文的规则：结算单需门店主动确认、7 号截止且逾期自动确认、有异议可重审。已记为 REQ-FIN-012。

另外第 2 条里的「请登录接单宝小程序进行修改」在 App 内会自相矛盾 —— 整合的目的正是让门店不必再进小程序。该文案必须改写为 App 内路径，否则门店按提示跳出 App，整合价值受损。

页面内容 —— 「全部结算渠道」下拉展开态，单选（✓ 在「全部结算渠道」），取值 4 项：全部结算渠道 / 小程序服务单结算 / 天猫服务单结算 / 京东服务单结算。

关键交互 —— ①点任一项 → 立即生效并收起（无「确定」按钮）；②点遮罩 → 收起。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-FIN-009 渠道枚举

本图的渠道口径与同一页的说明文字都对不上：下拉是「小程序 / 天猫 / 京东」三个服务单结算，而页面底部说明写的是「天猫 / 京东pop / 小程序」。同一个页面里「京东」与「京东pop」两种写法并存，且两处都没有拼多多，而收入页的 tab 却把拼多多与天猫、京东并列。见 REQ-FIN-009。

页面内容 —— 结算单明细页，沿用上一页的渠道下拉与日期区间，下方是「上周期更正结算(0)」与「本周期订单结算(0)」两个带计数的 tab，本截图为空态故明细行的字段无法从本图确认。

关键交互 —— ①点两个 tab → 切换明细类型，计数随筛选变化；②点「返回查看服务结算单」→ 回到上一页。

可用角色 —— 店长 ✅；技工 ✗。

需求关联 —— REQ-FIN-013 上周期更正结算

「上周期更正结算」是一个 PRD 从未提及的概念 —— 上一结算周期的金额发生更正后，差额落在本期结算单里。这直接影响 REQ-FIN-005「同一笔金额在不同页面必须一致」：同一笔业务在原周期与更正周期会出现两次，若不加以区分，门店会认为对账出错。已记为 REQ-FIN-013。

另注意两个 tab 都带 (N) 计数，与采购订单 tab 计数是同一类要求，接口需支持按类型返回计数。

4.10.4 采购对账单

对账单：在「我的」菜单下点击「对账单」，进入「对账单详情」，对账单按月份查看账单详情，汇总支出 / 收入金额，明细列表。

页面内容 —— ROOS「对账单详情」页，顶部为「采购对账单 ∨」下拉与账单单号搜索框，下方筛选行为月份与「支出 / 收入」两个汇总数，本截图为空态故明细行的字段无法从本图确认。

关键交互 —— ①点「采购对账单 ∨」→ 切换对账单类型；②输入账单单号 → 检索；③点月份 → 切换月份，两个汇总数随之变化；④点明细行 → 进入单据详情（本图为空态，无法确认是否可下钻）。

可用角色 —— 店长 ✅；技工 ✗（附录 B「采购对账单」为 ✗）。

需求关联 —— REQ-FIN-003 收支合并

「采购对账单 ∨」是可切换的下拉，说明 ROOS 的对账单不止采购一种，还有其它类型 —— 但本图未展开，其它类型无法确认。附录 A.8 第 1 条写的是「采购及返利对账单（马牌），来自 ROOS 与 F6」，返利对账单很可能就是下拉里的另一项。需补采下拉展开态的截图，并在 TODO(REQ-FIN-003) 一并厘清。

采购对账单（ROOS，付给厂商）与 O2O 对账提现（收厂商的钱）方向相反，整合后是并列两个入口还是合成一张「资金总览」—— TODO(REQ-FIN-003)。本图显示采购对账单自身同时含支出与收入两栏，并非纯支出，合并方案设计时需注意。

4.10.5 银行账号

页面内容 —— 银行账号页的企业账户形态，右上角状态为「已激活」，字段区为企业全称、统一社会信用代码、银行卡预留手机号、绑定银行（平安银行）与脱敏后的账号，底部并排「修改手机号」「解绑银行卡」，本图为测试数据（企业全称「张二零」、预留手机号 11111111111）。

关键交互 —— ①点「修改手机号」→ 需重新验证后修改；②点「解绑银行卡」→ 二次确认弹窗（见下图）。注销账户无 App 内入口，提示要求联系马牌客服。

可用角色 —— 店长 🔸 受限（附录 B 标为高风险，需二次验证 TODO(REQ-FIN-004)）；技工 ✗。

需求关联 —— REQ-FIN-004 账户绑定安全、REQ-FIN-014 账户类型与状态

「温馨提示」两条原文：①「银行账户修改手机号、解绑银行卡需要重新验证，请勿频繁修改」；②「如需注销银行账户，请联系马牌客服」。

第 1 条回答了 TODO(REQ-FIN-004) 的一半 —— 现状已经要求重新验证，所以「是否需要二次验证」不再是问题，剩下的只是验证方式（短信验证码 / 后台审核 / 其它）。该 TODO 可据此收窄。

页面内容 —— 同一页面的个人账户形态（字段改为姓名与身份证号码，状态同为「已激活」，唯独银行卡预留手机号未脱敏），其上叠加解绑二次确认弹窗，正文说明解绑后账户将降为待激活、需重新绑卡激活。

关键交互 —— ①点「取消」→ 放弃；②点「确认」→ 解绑，账户转为「待激活」。本弹窗未包含任何验证码或密码输入 —— 与「解绑需要重新验证」的提示是否在确认之后才触发，本图无法确认。

可用角色 —— 店长 🔸；技工 ✗。

需求关联 —— REQ-FIN-004 账户绑定安全、REQ-FIN-014 账户类型与状态

两张图合起来给出账户模型：两种账户类型（企业 = 企业全称 + 统一社会信用代码；个人 = 姓名 + 身份证号码）、两种状态（已激活 / 待激活），解绑即降为待激活，需重新绑卡才能恢复。已记为 REQ-FIN-014。

脱敏口径不统一：身份证号与银行账号都做了脱敏，而银行卡预留手机号 13419691597 完整显示。App 内须统一脱敏规则，见 TODO(REQ-FIN-014)。

另：验收标准第 4 条要求「解绑后提现入口给出明确阻断提示」，而现状弹窗只说账户变为待激活，没有提到会影响提现。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 提到「采购及返利对账单」）

REQ-FIN-004 账户绑定安全 —— 银行账号绑定 / 解绑 / 修改预留手机号必须重新验证（现状已如此要求）；具体验证方式（短信验证码 / 后台审核）待定 TODO(REQ-FIN-004)

REQ-FIN-005 金额一致性 —— App 不做金额二次计算，全部以源系统返回值展示；不同页面同一笔金额必须一致。跨周期更正的金额需可区分，见 REQ-FIN-013

REQ-FIN-006 手续费透明 —— 交易手续费说明须在提现入口可达，且分渠道的费率原文须完整保留，不得摘要或省略

REQ-FIN-007 与 CDMS 支付关系 —— 首页待办中的「CDMS 支付提醒」与本模块的关系待定 TODO(REQ-FIN-007)

REQ-FIN-008 提现由系统自动发起 —— 小程序渠道的提现由系统在每个工作日固定时点自动发起，将账户余额全部提出，发起后 30 分钟内到账；门店没有手动提现入口。App 内不得出现「立即提现」类按钮，避免门店误以为需要手动操作。

待确认 TODO(REQ-FIN-008)：①说明文案写「15:30 左右」，而提现历史的记录时间戳几乎全为 15:00:2x，实际时点以哪个为准；②天猫 / 京东 / 拼多多 / 抖音等非小程序渠道没有自动提现（按月结算两次直接打款），页面上的「可提现金额」是否只统计小程序渠道，需明确。

REQ-FIN-009 分渠道结算机制与费率 —— 各渠道的结算周期、到账账户与费率互不相同，须按渠道分别落地：

渠道组	结算周期	到账账户	费率
小程序	每工作日自动提现，30 分钟内到账	平台账户余额	营业收入的 0.6%
天猫 / 京东 / 拼多多	每月两次	支付宝账号（店铺管理–收款信息）	天猫 3.1%、京东 3.2%、拼多多百亿补贴 2%、拼多多普通订单 1%
抖音小店	每月两次	银行卡账号	普通订单 2%、达人带货订单 4%
抖音团购	截图被遮挡，未知	未知	未知

上表按货款收入计费。本模块的银行账号页只服务抖音小店渠道；支付宝收款信息现状不在本模块，在「店铺管理」内维护。

待确认 TODO(REQ-FIN-009)：①「抖音团购」段落需补采截图后补全；②支付宝收款信息是否随本模块一并收进 App；③渠道枚举必须统一 —— 现状在财务侧就有四套口径：收入页 tab（天猫/京东/拼多多合并 + 小程序 + 抖音小店 + 高德…，另有「零跑」标签）、手续费说明（四段分组）、结算渠道下拉（小程序 / 天猫 / 京东服务单结算，无拼多多）、收入详情备注（抖音 / 美团 / 京东秒送 / 车点点 / 零跑）；再加上返利中心的 8 项与经营业绩的 7 项，全仓库至少六套。须收敛为一份主数据枚举。

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 号是否需要提醒推送，与提醒模块的关系）。

REQ-FIN-013 上周期更正结算 —— 结算单明细分为「上周期更正结算」与「本周期订单结算」两类，各自带条数计数。跨周期更正的金额会落在本期结算单内，展示上必须与本期订单结算区分，避免门店重复计数。

待确认 TODO(REQ-FIN-013)：更正的产生原因（退款 / 核销撤销 / 平台调账）、对已确认结算单的追溯影响、以及更正金额是否计入本期的「结算金额」汇总。

REQ-FIN-014 银行账号的账户类型、状态与脱敏 —— 银行账号支持两种类型：企业账户（企业全称 + 统一社会信用代码）与个人账户（姓名 + 身份证号码），共用「银行卡预留手机号 / 绑定银行 / 绑定银行账号」三个字段。账户状态为已激活 / 待激活；解绑后账户降为待激活，需重新绑卡才能恢复。注销账户无 App 内入口，需联系马牌客服。

待确认 TODO(REQ-FIN-014)：脱敏口径需统一 —— 现状身份证号与银行账号已脱敏，而银行卡预留手机号完整显示。App 内三个字段的脱敏规则须一致并成文。

4.10.7 验收标准

可提现金额页面明确标注更新时间与统计口径，不出现「金额已变但说明未变」的错位；
收入明细合计与可提现金额可对上，差额部分（未到 T+1、手续费、通道费）有明确说明；
技工无法通过任何路径进入财务模块（含深链）；
银行账号解绑必须二次确认，且解绑后提现入口给出明确阻断提示；
页面不出现任何手动提现按钮，自动提现的时点与规则在提现入口可达（REQ-FIN-008）；
手续费说明中各渠道的费率数值与源系统一致，抖音团购段落完整可见、不被按钮遮挡（REQ-FIN-009）；
结算单在未确认时可点「确认」，已确认后按钮置灰；临近 7 号自动确认前门店已被告知（REQ-FIN-012）；
结算单明细中「上周期更正结算」与「本周期订单结算」两类金额分列且各自计数正确（REQ-FIN-013）；
App 内所有财务页面不出现「请登录接单宝小程序」类引导，全部改为 App 内路径（REQ-FIN-012）。

第 2 条补入「通道费」，第 5~9 条为本次逐图核看后新增。

4.11 返利中心

返利分布在两侧：延保侧有延保返利，O2O 侧另有一套完全独立、维度更丰富的返利体系（9 张截图），设计稿为其单独出了页面。

业务目标 —— 让门店随时看清「这单能拿多少返利、为什么是这个数、核算到哪一步了」，解决痛点 2.4中返利不透明的问题

入口 —— O2O 工具条「返利中心」；宫格版导航一级入口

页面内容：

双 Tab：返利详情 / 返利核算
顶部订单号搜索 + 四个筛选（渠道 / 品牌 / 标签 / 月份）—— 仅返利详情 Tab 有，切到返利核算后整个筛选区消失（REQ-RBT-010）
概览卡（补贴返利、核算后返利）+ 三项构成（消费者补贴、安装费用、抽奖红包返利），每项可点开调整情况
明细列表，按三项构成分组切换

主流程 —— 选择月份与筛选 → 查看概览 → 按构成切换明细 → 展开单条查看构成与状态；另可切到「返利核算」查看季度核算的调整流水

权限规则 —— 建议限店长 TODO(REQ-RBT-001)

数据来源 —— O2O（返利核算）、延保后台（延保返利，见 4.5.6）

4.11.1 目标形态

页面内容 —— App 返利中心的目标形态，自上而下为订单号搜索框、「返利详情 / 返利核算」双 Tab、四个筛选、橙色汇总卡（返利补贴与核算后返利 + 三项构成，每项带 ⓘ）与「明细」区，两张明细卡是同一份占位数据，仅状态标签不同。

关键交互 —— ①输入订单号 → 检索该单返利；②切换双 Tab；③点四个筛选任一项 → 展开取值（取值集合见 4.11.3）；④点三项构成上的 ⓘ → 弹出该项的调整情况（见 4.11.4）；⑤点「消费者补贴 / 安装费用 / 抽奖红包返利」三个标签 → 切换下方明细分组；⑥点明细卡右侧 ∨ → 展开该条的返利构成。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)，关闭前按技工不可见实现。

需求关联 —— REQ-RBT-002 计算口径、REQ-RBT-003 规则说明可达

本图的三个数值互不自洽，不可作为计算口径的依据：返利补贴 ¥30.00、核算后返利 ¥38.00，而三项构成之和为 40 + 12.08 + 1.08 = ¥53.16 —— 与前两者都对不上。相比之下现状返利详情的一组数据恰好自洽（20 = 20 + 0 + 0）。设计稿此处是随手填的占位数值，TODO(REQ-RBT-002) 的公式应以现状数据反推，见 REQ-RBT-002。

4.11.2 返利详情与返利核算

页面内容 —— O2O 返利中心的「返利详情」Tab，结构与设计稿一致但筛选分成两行（渠道 / 品牌 / 标签一行，月份单独一行），「概览」区为补贴返利与核算后返利两张白卡加三项构成，「明细」区当前按「消费者补贴」分组、两条记录合计 +¥20.00。

关键交互 —— ①输入订单号后需点「搜索」按钮才触发查询（非输入即搜）；②点三项构成旁的 ? → 弹出调整情况；③点明细分组切换列表；④点明细行右侧 ∨ → 展开该条构成；⑤列表触底显示「已经到底啦！」。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-002 计算口径、REQ-RBT-006 数据来源、REQ-RBT-007 筛选取值

本图是推导计算口径的关键证据，三层数值恰好闭合：明细合计（−40 + 60）= 消费者补贴（+20）= 三项构成之和（20 + 0 + 0）= 补贴返利（+20）= 核算后返利（+20，本月无核算调整）。据此可给出待业务确认的公式草案，见 REQ-RBT-002。

明细行的字段与设计稿不一致：现状每行含数量「x1」、条码后跟灰色**「撤回」标签、「最近记录时间」**前缀；设计稿则是状态标签「已完成」/「退款扣减」，无数量、无「最近记录时间」。两套字段需在设计定稿时合并，一并归入 REQ-RBT-007。

页面内容 —— 切到「返利核算」Tab 后的列表，搜索框与四个筛选整行消失，只剩双 Tab 与核算调整流水卡（每张含事由标题、「品牌｜渠道｜返利类型」三个维度标签、带正负的金额与时间戳）。

关键交互 —— ①切换回「返利详情」→ 搜索与筛选区重新出现；②列表本身无筛选、无搜索、无分页控件，只能上下滚动。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。核算流水含考核扣款，敏感度高于返利详情，即便技工可见返利详情，本 Tab 是否一并开放需单独判断。

需求关联 —— REQ-RBT-010 核算 Tab 的筛选缺失、REQ-RBT-011 返利类型集合

本图给出三条实质信息：

返利核算是「季度」粒度的（结合抽奖红包返利说明中的「不参与季度核算」），而返利详情按月筛选。两个 Tab 的时间粒度不同，图中三条记录横跨 2023–2025，也确实不受月份筛选约束 —— 已记为 REQ-RBT-010。

「好评返利」不属于三项构成的任何一项（消费者补贴 / 安装费用 / 抽奖红包返利），说明返利类型的完整集合比概览区展示的三项更大 —— 已记为 REQ-RBT-011。

「Q1补货率未达标 −¥1,000.00」证明返利核算包含考核扣款，且考核指标是「补货率」—— 与营销与会员中「消费券额度随扫码入库与补货率累积」是同一套门店考核体系。App 内两处应引用同一份考核规则说明，避免门店在两个模块看到互相矛盾的解释。

事由标题「11」「导入增加11」明显是后台录入的测试文案。整合后该字段直接对门店展示，需明确其录入规范与字数上限，一并归入 REQ-RBT-010。

4.11.3 多维筛选

页面内容 —— 「全部渠道」下拉展开态，单选（当前 ✓ 在「全部渠道」），取值共 9 项：全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎。

关键交互 —— ①点任一渠道 → 立即收起下拉并按该渠道过滤（无「确定」按钮）；②再次点标题或点遮罩 → 收起。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-007 筛选取值

渠道主数据与经营业绩模块对不上：本图为 8 个业务渠道，而经营业绩与报表记录的渠道清单为 7 个（小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎），少了「抖音团购轮胎」。渠道是跨模块共用的主数据，两处必须取自同一份枚举，见主数据。已记入 REQ-RBT-007。

页面内容 —— 「全部品牌」下拉展开态，单选（✓ 在「全部品牌」），取值 3 项：全部品牌 / 德国马牌 / 维京。

关键交互 —— 同渠道下拉：点选即生效并收起。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-007 筛选取值

品牌名称在三处有三种写法：本图下拉为「德国马牌 / 维京」，返利核算的标签为「马牌 / 维京」，采购购物车分组为「德国马牌 / 维京轮胎」。App 内须统一，同样归入主数据口径。

页面内容 —— 「标签」下拉展开态，与前两个筛选形态不同：提示「请选择标签（可多选）」，三个可点 chip「撤回 / 异常 / 调整」，下方另有独立的「确定」按钮。

关键交互 —— ①点 chip → 切换选中态，可多选；②点「确定」→ 应用筛选并收起（与渠道 / 品牌的「点选即生效」不同）。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-007 筛选取值

V1.0 原文把「标签」列为四个筛选之一，但从未说明它的取值。本图给出确定答案：标签 = 撤回 / 异常 / 调整，且是多选。这三个值正是消费者补贴调整情况弹窗里的三个调整分项 —— 标签筛选的本质是「按调整原因过滤明细」，而非商品或订单的标签。

页面内容 —— 点月份后从底部弹出的年月滚轮选择器（左列年份、右列月份，底部「取消」与绿色「确定」），为微信小程序原生 picker 样式。

关键交互 —— ①滚动年 / 月 → 预选；②点「确定」→ 应用；③点「取消」或遮罩 → 放弃。只能选单个月，不支持区间。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-007 筛选取值

两点须在 App 内改造：①绿色「确定」是微信原生控件样式，App 内应换成本项目设计系统的按钮；②年份可选范围（图中可滚到 2027 年，即未来月份）需要约束，选到无数据的未来月份只会得到空态。

4.11.4 返利构成说明

三项返利构成各自带独立的规则说明页，这些说明必须在 App 内完整保留 —— 它们是门店理解返利数额的唯一依据。

页面内容 —— 点「消费者补贴 ?」后的居中弹窗「消费者补贴调整情况」，一行汇总之下的框内是发放 / 撤回 / 异常 / 调整四个分项（本图各为 ¥0.00）。

关键交互 —— ①点 ✕ 或遮罩 → 关闭。弹窗内各分项不可再下钻，是终点页。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-003 规则说明可达、REQ-RBT-008 调整情况分项

页面内容 —— 结构与上一张相同的「安装费用调整情况」弹窗，差别是分项只有三个：发放 / 异常 / 调整 —— 没有「撤回」。

关键交互 —— 同上，仅 ✕ 关闭。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-008 调整情况分项

两项的分项数不同：消费者补贴有「撤回」而安装费用没有。若这是有意的业务设计（安装费用一旦发放不可撤回），需成文；若是现状遗漏，App 内应补齐。同时标签筛选包含「撤回」，按安装费用分组时该标签将始终无结果 —— 交互上需要处理。已记为 REQ-RBT-008。

页面内容 —— 点「抽奖红包返利 ?」后弹出的纯文字提示框（非前两张的数据弹窗），全文一句：「抽奖红包返利，不参与季度核算，不会进行扣除」。

关键交互 —— 仅 ✕ 关闭，无交互。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RBT-001)。

需求关联 —— REQ-RBT-003 规则说明可达、REQ-RBT-009 抽奖红包返利的核算例外

本图有两个值得注意的点：

三项构成的说明形态不一致 —— 前两项是带金额分项的「调整情况」数据弹窗，第三项是无数据的纯文字规则说明。App 内是否统一为同一种形态，见 REQ-RBT-008。

这句话本身是一条实质业务规则，且是全部 10 张图里唯一明确写出核算规则的地方：抽奖红包返利不参与季度核算、不会被扣除。它直接约束 REQ-RBT-002 的公式 —— 「核算后返利」的调整只作用于消费者补贴与安装费用两项。已单独成文为 REQ-RBT-009。

4.11.5 业务规则

REQ-RBT-001 权限 —— 返利对技工是否可见待定 TODO(REQ-RBT-001)。「返利核算」Tab 含考核扣款流水，敏感度高于「返利详情」，两者是否同一档权限需一并判断

REQ-RBT-002 计算口径 —— 返利补贴、核算后返利、三项构成的关系需给出公式说明 TODO(REQ-RBT-002)

V1.1 依据现状返利详情与三项说明弹窗反推出以下公式草案，待财务确认后转为正式口径：

消费者补贴 = 发放 + 撤回 + 异常 + 调整

安装费用 = 发放 + 异常 + 调整（无撤回项，见 REQ-RBT-008）

补贴返利 = 消费者补贴 + 安装费用 + 抽奖红包返利

核算后返利 = 补贴返利 + 季度核算调整合计，其中抽奖红包返利不参与核算调整（REQ-RBT-009）

每项构成的明细列表合计 = 该项金额

现状截图的一组数据完全满足上述关系（明细 −40 + 60 = 消费者补贴 20 = 补贴返利 20 = 核算后返利 20）；设计稿的 30 / 38 / 53.16 三者不自洽，不作为口径依据。另需财务明确：正负号约定（撤回 / 异常为负值还是绝对值）、以及季度核算调整落在哪个月份的「核算后返利」上。

REQ-RBT-003 规则说明可达 —— 三项构成的 ⓘ 说明必须在 App 内保留，不得外链小程序

REQ-RBT-004 与延保返利合并 —— O2O 返利与延保返利是否合并入口待定 TODO(REQ-RBT-004)

REQ-RBT-005 退款扣减 —— 明细中的「退款扣减」状态需与财务收入对齐，同一笔不得两侧不一致

REQ-RBT-006 数据来源 —— 返利金额全部由 O2O 返回，App 不做二次计算（同 REQ-FIN-005）

REQ-RBT-007 筛选取值与明细字段 —— 四个筛选的取值与交互按现状固化：

渠道：单选，点选即生效。取值为「全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎」
品牌：单选，点选即生效。取值为「全部品牌 / 德国马牌 / 维京」
标签：多选，需点「确定」生效。取值为「撤回 / 异常 / 调整」，语义是按调整原因过滤明细
月份：单月，年月滚轮 + 确定，不支持区间；可选年份范围需约束，避免选中无数据的未来月份

明细行字段需在现状（数量 x1 / 条码 + 撤回标签 / 最近记录时间）与设计稿（已完成 / 退款扣减状态标签）两套之间合并定稿。

待确认 TODO(REQ-RBT-007)：渠道枚举与经营业绩与报表记录的 7 项不一致（本模块多出「抖音团购轮胎」）；品牌名称在返利核算标签、品牌下拉、采购购物车三处分别写作「马牌」「德国马牌」「德国马牌 / 维京轮胎」。两者均为跨模块主数据，须统一到同一份枚举后再定稿。

REQ-RBT-008 三项构成的调整情况 —— 消费者补贴与安装费用各自可点开「调整情况」弹窗，展示该项的分项金额；抽奖红包返利仅有一句文字说明。分项现状为：消费者补贴 = 发放 / 撤回 / 异常 / 调整（4 项），安装费用 = 发放 / 异常 / 调整（3 项，无撤回）。

待确认 TODO(REQ-RBT-008)：①安装费用无「撤回」是业务设计还是现状遗漏；②按安装费用分组时「撤回」标签必然无结果，交互上如何处理（置灰 / 隐藏 / 允许空结果）；③App 内三项的说明是否统一为同一种形态（现状两种：数据弹窗 + 纯文字提示）。

REQ-RBT-009 抽奖红包返利的核算例外 —— 抽奖红包返利不参与季度核算，不会被扣除。该规则须在 App 内对门店显式展示（沿用现状的说明入口），并作为 REQ-RBT-002 公式的约束条件：季度核算的调整只作用于消费者补贴与安装费用两项

REQ-RBT-010 返利核算 Tab 的独立性 —— 「返利核算」Tab 与「返利详情」Tab 的数据粒度不同：详情按月筛选，核算按季度产生，现状切到核算 Tab 后搜索框与四个筛选整行消失，列表不受月份约束。核算记录的结构为「事由标题 + 品牌｜渠道｜返利类型 + 金额 + 时间戳」。

待确认 TODO(REQ-RBT-010)：①核算 Tab 是否需要自己的筛选（按季度 / 品牌 / 渠道）与搜索；②事由标题由后台自由录入（现状可见「11」「导入增加11」等测试文案），直接对门店展示前需明确录入规范与字数上限；③核算调整最终如何回写到某个月份的「核算后返利」。

REQ-RBT-011 返利类型集合 —— 概览区展示的三项构成（消费者补贴 / 安装费用 / 抽奖红包返利）不是返利类型的全集：返利核算记录中出现了「好评返利」，不属于其中任何一项。返利类型的完整枚举、每种类型是否计入补贴返利、是否参与季度核算，均待补 TODO(REQ-RBT-011)

4.11.6 验收标准

四个筛选任意组合下，概览卡数值与明细列表合计一致；
每一项返利构成都能点开对应的规则说明，且说明内容与现状小程序一致；
「退款扣减」明细在返利中心与财务收入两处金额与符号一致；
「补贴返利 = 三项构成之和」「各项明细合计 = 该项金额」两条恒等式在任意筛选组合下成立（REQ-RBT-002）；
切到「返利核算」Tab 时，页面不残留「返利详情」的筛选条件，返回时原筛选条件仍在（REQ-RBT-010）；
标签筛选支持多选并需点「确定」生效，渠道 / 品牌为单选点选即生效（REQ-RBT-007）。

第 4、5、6 条为本次逐图核看后新增。

4.12 经营业绩与报表

本节内容由 O2O 经营业绩、ROOS 业绩详情与设计稿构建。

业务目标 —— 门店在一处看到订货、入库、售出、延保、收入的全链路经营数据，解决痛点 2.5

入口 —— 「我的」菜单 → 经营业绩；宫格版导航「经营分析」；店长首页业绩卡片

页面内容：

三 Tab：1.0 经营业绩 / 2.0 经营业绩 / 2.0 引流转化
三个筛选（品牌 / 渠道 / 日期）+ 一行时间粒度 chip（当月 / 当日 / 当周 / 当季）
扫码入库双计数、分品牌性能指标、销售统计、收入统计
引流转化 Tab 另有线索三分类、环比、排名与市/全国对标折线图（REQ-PRF-007）

V1.0 此处原写作「三个筛选（时间粒度 / 渠道 / 日期）」，据现状图核实第一个筛选是「品牌」而非「时间粒度」，时间粒度是另一行独立的 chip，已按实际改写。见 4.12.2 的筛选品牌图。

主流程 —— 选择时间粒度与渠道 → 查看指标卡 → 下钻明细

权限规则 —— 建议限店长；技工可见与其相关的施工量指标 TODO(REQ-PRF-001)

数据来源 —— O2O（O2O 售出、收入、引流转化）、ROOS（签约量、订货量、扫码入库量）

4.12.1 目标形态

页面内容 —— App 经营业绩页的目标形态，顶部三 Tab + 三个筛选下拉，其下依次是两张并排计数卡、马牌与维京两张性能指标卡（各含入库数 / O2O 售出 / 补货率）、「销售统计」三项与「收入统计」三行。

关键交互 —— ①切换三 Tab → 换一套指标体系（注意不只是换数据，见 REQ-PRF-009）；②点三个筛选下拉 → 展开选项并刷新全部指标；③点指标卡 → 下钻明细（本稿未画下钻标识，也未提供明细页的稿）。

可用角色 —— 店长 ✅ 全量；技工 ❓，可见范围待定 TODO(REQ-PRF-001)。按 REQ-ACC-006，在该项关闭前技工一律不可见收入统计。

需求关联 —— REQ-PRF-002 命名、REQ-PRF-008 指标与筛选的最终集合

本稿与现状有四处对不上，需连同「以哪一版为准」一并裁决（见 REQ-PRF-008）：

两张计数卡的文案完全相同，都写「扫码入库总数」，仅图标不同（二维码 / 店铺）——用户无从分辨。V1.0 正文称其为「扫码入库总数 / 扫码入库总数（门店）」，但稿上并没有「（门店）」这个后缀。而现状的第二张卡是「O2O 售出」，根本不是入库数。

稿中丢失了「品牌」筛选：三个下拉画成「当月 / 全部渠道 / 日期选择」，而现状是「品牌 / 渠道 / 日期」+ 独立的时间粒度 chip 行。分品牌性能指标卡（马牌 / 维京）恰恰依赖品牌筛选。

收入统计少一项：现状有四项（含「总收入」），稿中只有三项。

现状在可下钻的指标上带 👆 标识、页面底部带一行返利实时变动的备注，稿中均无。

另：稿中马牌与维京的「O2O 售出」同为 5、补货率同为 0.00%，属占位数据。

「1.0 / 2.0」是现状 O2O 沿用的版本代号，对门店无业务含义。App 应改用可读的业务命名 —— TODO(REQ-PRF-002)。

补充：核看现状图后发现这句话说轻了 —— 1.0 与 2.0 不是同一套指标的两个版本，而是两套完全不同的指标体系，改名解决不了问题。见 REQ-PRF-009。

4.12.2 现状经营业绩

页面内容 —— O2O「经营业绩」的 1.0 经营业绩 分页，三个 Tab 与三个筛选下拉之下另有一行时间粒度 chip（当月 / 当日 / 当周 / 当季），内容区依次为扫码入库统计、六格分品牌指标、销售统计与含「总收入」的收入统计四项，本图全部指标为 0 或 --%，属空态。

关键交互 —— ①切换三 Tab → 换指标体系；②三个下拉分别筛品牌 / 渠道 / 日期；③点时间 chip → 切换统计周期（与「日期选择」区间是互斥还是叠加，本图无法确认）；④点带 👆 标识的指标（扫码入库总数、马牌入库数、维京入库数）→ 下钻明细；⑤其余指标无下钻标识。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-PRF-001)。

需求关联 —— REQ-PRF-002、REQ-PRF-003 报表合并、REQ-PRF-008、REQ-PRF-009

底部备注原文：「上述消费者补贴及好评展示的发放/扣回金额，根据订单核销及延保状态实时变动」。这说明收入统计不是终值而是可回冲的动态值 —— 与财务对账、返利的口径衔接需注意，该备注在 App 内必须保留。

页面内容 —— 2.0 经营业绩 分页，筛选只剩两个下拉（无渠道筛选），内容只有销售统计三项与收入统计两项，没有扫码入库统计，也没有分品牌指标。

关键交互 —— ①同上，但少一个渠道筛选；②本页指标均无 👆 下钻标识。

可用角色 —— 同上图。

需求关联 —— REQ-PRF-009

本图是「1.0/2.0 不是版本号」的直接证据：两个分页的指标名称无一相同（1.0 是订单数量 / 轮胎条数 / 延保条数，2.0 是下单数量 / 下单人数 / 商品数），筛选项数量也不同。「下单人数」是 1.0 完全没有的消费者维度指标。

页面内容 —— 2.0 引流转化 分页，结构与前两个分页完全不同：筛选为「全部」+ 月份区间与一行排名灰字，主体是三项转化指标（各带环比）与其下三项线索来源细分，再下方是年度折线图与「我的数据 / 市平均值 / 全国平均值」三个图例开关，本图指标全为 —、折线图全为 0，属空态。

关键交互 —— ①点指标旁的 ⓘ → 指标口径说明；②点年份下拉 → 切换折线图年度；③开关三条对比曲线的显隐；④折线图横向滚动查看 12 个月（本图仅能看到 1–5 月，下方有滚动条）。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-PRF-001)。本页含「市/全国平均值」与门店排名，属对标数据，技工可见性尤需明确。

需求关联 —— REQ-PRF-007 引流转化指标体系

V1.0 的 4.12「页面内容」完全没有描述本分页 —— 只列了「扫码入库双计数、分品牌性能指标、销售统计、收入统计」，那些全属 1.0 分页。本页的线索三分类、环比、门店排名、市/全国对标折线图在需求中一条都没有，见 REQ-PRF-007。

折线图的横向滚动与提醒模块中发现的横向滚动是同类问题：为宽屏设计的图表直接搬到手机上。App 化时需重做图表适配。

页面内容 —— 1.0 分页上「全部渠道」下拉的展开态，白色浮层完整拍到 8 项取值：全部渠道（已选中）/ 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎。

关键交互 —— ①点任一渠道 → 收起浮层并按该渠道刷新全部指标；②点浮层外区域 → 收起。浮层是否可继续下滑露出更多渠道，本图无法确认。

可用角色 —— 同 1.0 分页。

需求关联 —— REQ-PRF-008

这是全文唯一一处完整列出 O2O 渠道全集的证据（7 个实际渠道）。注意「京东」与「京东秒送」是两个独立渠道。该取值集与销售模块的订单来源渠道标（设计稿中出现过「天猫订单」「京东订单」）应为同一份主数据，需在第 5 章主数据中统一。

页面内容 —— 1.0 分页上第一个下拉的展开态，取值为「全部」（已选中）/ 马牌 / 维京 —— 证明该下拉是品牌筛选而非时间粒度。

关键交互 —— ①点品牌 → 收起并按品牌刷新指标。

可用角色 —— 同 1.0 分页。

需求关联 —— REQ-PRF-008

本图是纠正 V1.0「三个筛选（时间粒度 / 渠道 / 日期）」这句话的依据，也是判定设计稿丢失品牌筛选的依据。品牌取值只有马牌与维京两个，与库存模块的品牌筛选取值范围是否一致，需在主数据侧核对。

页面内容 —— 「日期选择」下拉的展开态，只有一个含「起」「止」两个输入框与一个「查询」按钮的「选择查询时间」区，本图两框均为空、按钮置灰，故日期控件的具体形态（日历弹层还是滚轮）无法从本图确认。

关键交互 —— ①点「起」/「止」→ 唤起日期选择控件；②两端都选定后「查询」转为可点；③点「查询」→ 按区间刷新指标。

可用角色 —— 同 1.0 分页。

需求关联 —— REQ-PRF-008

页面同时存在「当月/当日/当周/当季」四个时间 chip 与这个自定义区间，两者是互斥还是叠加，现状图无法判定，App 化时须明确（否则会出现「当月 + 跨月区间」这类自相矛盾的组合）。

4.12.3 采购侧业绩详情

业绩详情：在「我的」菜单下，点击「经营业绩」进入「业绩详情」，业绩详情包含签约量、订货量、扫码入库量、O2O 售出量；签约量分为月度签约量、季度签约量；订货量、扫码入库量、O2O 售出量均支持年份 + 月度/季度维度筛选查看。

页面内容 —— ROOS「业绩详情」页，顶部是一个橙色的统计主体下拉「Continental–上海」，其下为签约量 / 订货量 / 扫码入库量 / O2O 售出量四个指标区块（后三个各自带年份下拉、区块内两张卡再各带月份与季度下拉），只有签约量有非零数据（月度 100 / 季度 300）。

关键交互 —— ①点顶部下拉 → 切换统计主体；②每个区块的年份下拉 → 切换年度；③每张卡的月份 / 季度下拉 → 切换周期。全页共有 10 个独立筛选控件，无统一筛选栏。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-PRF-001)。签约量属商务承诺数据，技工可见性需明确。

需求关联 —— REQ-PRF-003 报表合并、REQ-PRF-005 月度签约达成预警

本图给 REQ-PRF-003 补了三条具体障碍，合并方案必须逐条回答：

统计主体不同。顶部下拉写的是「Continental–上海」，从命名看是签约主体或区域，而非某家具体门店；O2O 经营业绩则是门店维度。同名指标挂在不同主体上，直接相加会错。本图无法确认该下拉的确切层级，需向业务核实。

时间粒度不同。ROOS 只有「年 + 月 / 年 + 季」，O2O 有「当日 / 当周 / 当月 / 当季 + 自定义区间」。合并后取哪一套。

筛选模型不同。ROOS 是每个区块各自带筛选（共 10 个控件），O2O 是页面顶部统一筛选栏。这不只是样式差异 —— ROOS 允许「订货量看 4 月、扫码入库量看 3 月」这种跨周期并列，统一筛选栏做不到。

另注意本页对空值有两种写法：订货量与扫码入库量写 0，O2O 售出量写 —。前者是「统计结果为零」，后者通常是「无数据」，同一页面不应混用。

两套经营业绩的指标高度重叠但口径不同：ROOS 业绩详情与 O2O 经营业绩都统计「扫码入库量」和「O2O 售出量」。合并为一套报表还是并列两个 Tab —— TODO(REQ-PRF-003)，与 REQ-INV-005（入库写入目标）是同一个根因。

延保侧还有第三套经营数据（4.5.6）—— 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。

REQ-PRF-003 报表合并 —— ROOS 与 O2O 两套业绩的合并方式待定 TODO(REQ-PRF-003)

REQ-PRF-004 延保数据并入 —— 延保经营数据是否并入统一报表待定 TODO(REQ-PRF-004)

REQ-PRF-005 月度签约达成预警 —— 首页动态预警中的「月度签约达成」阈值取自签约量指标，规则待定 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 条需补充「品牌」这一维（现状是四个筛选维度：品牌 / 渠道 / 日期 / 时间粒度），并明确时间 chip 与自定义区间的互斥关系。

4.13 营销与会员

本节对应痛点 2.4「支付与营销」，内容由 O2O 优惠券、会员权益、门店海报截图构建。

业务目标 —— 让门店在开单现场就能用上券和会员权益，并具备自主获客的物料，解决痛点 2.4

入口 —— O2O 工具条「优惠券」「会员权益」「门店海报」；开单结算流程中的选券环节

页面内容 —— 消费券 / 门店营销券、选择营销券、会员权益选择弹窗、会员体系开通状态、门店海报

主流程：

开单选券：结算 → 选择营销券 → 应用 → 计入金额
会员权益：开单 → 选择会员权益 → 应用

⚠️ 上面「会员权益」这条主流程与现状不符 —— 现状是首页宫格的独立入口，输会员手机号后勾选权益并提交，与开单流程无关。见 REQ-MKT-007。

权限规则 —— 店长可管理；技工在开单时可使用 TODO(REQ-MKT-001)

数据来源 —— O2O（券、会员权益、海报）、ROOS（采购优惠券）

4.13.1 优惠券

页面内容 —— O2O「优惠券」页的消费券分页（另一分页为「门店营销券」），上半部是门店的消费券额度看板（三项额度均为 0，配补货率环形图与一条「未满足规则，消费券额度不会增加」的橙色提示），下半部是一张可发放的满减券条目与底部置灰的「去发放（0）」。

关键交互 —— ①点「额度变更记录」→ 额度流水；②点橙色提示条的「详情」→ 额度累积规则说明；③券条目的 − / + 步进器 → 调整发放数量，同步更新底部「使用额度」与「去发放（N）」计数；④点「详细说明 ∨」→ 展开该券的使用说明；⑤点「去发放」→ 发券（本图为置灰态，发放后的流程无法从本图确认）。

可用角色 —— 店长 ✅（属「管理券」，附录 B 已定技工 ✗）；技工 ✗ TODO(REQ-MKT-001)。

需求关联 —— REQ-MKT-001 权限、REQ-MKT-002 券体系归并、REQ-MKT-006 消费券额度机制

本图揭示了一条 PRD 完全未描述的机制：消费券不是门店自建的，而是按「扫码入库」与「补货率」自动累积额度，未达规则则不增额度，门店只能在额度内发放 —— 即消费券是与进货挂钩的厂商激励，不是普通营销券。详见 REQ-MKT-006。

图中券名为 shasha_test，「优惠范围 1~~5」「使用门槛 1~~5」「仅剩 1」均为测试数据，不代表真实券配置。

页面内容 —— 同一页面的门店营销券分页，顶部为虚线框的「+ 创建门店营销券」入口与「发放统计」卡片，本图为空态（「当前没有门店可用营销券」），故营销券条目的字段构成无法从本图确认。

关键交互 —— ①点「+ 创建门店营销券」→ 建券表单（表单字段无设计稿也无现状图，未知）；②点月份下拉 → 切换统计周期，刷新三项计数。

可用角色 —— 店长 ✅；技工 ✗ TODO(REQ-MKT-001)。

需求关联 —— REQ-MKT-001、REQ-MKT-002

两个分页是两种截然不同的券：消费券由上游按进货表现下发额度、门店只能发放；门店营销券由门店自己创建、自负成本。这一区别直接决定 REQ-MKT-002「三套券叠加规则」的裁决方式 —— 资金来源不同的券能否叠加，是财务问题而非产品问题。

页面内容 —— 开单结算环节的「选择营销券」页，本图为完全空态（占位插图 +「当前没有营销券」），除标题栏外无任何控件，故券列表的行内字段、可用/不可用的区分方式与是否支持多选均无法从本图确认。

关键交互 —— ①左上返回 → 回结算页。有券时的选择交互本图无法确认。

可用角色 —— 店长 ✅、技工 ✅（属「使用券（开单时）」，附录 B 已定两角色均 ✅）。

需求关联 —— REQ-MKT-002

验收标准第 2 条要求「不可用券给出不可用原因而非简单置灰」，但本图是空态，现状是否已展示不可用券、以何种方式展示，本图无法确认 —— 该条属新增要求，需在设计稿中明确。

4.13.2 会员权益

页面内容 —— 从 O2O 接单宝首页宫格「会员权益」唤起的弹窗，含会员手机号输入框、两项各带圆形勾选标的「权益」列表与底部橙色「确认提交」按钮，弹窗背后是 O2O 首页。

关键交互 —— ①输入会员手机号 → 标识会员身份；②点权益行 → 选中/取消；③点「确认提交」→ 核销该会员的权益；④点 × → 关闭弹窗。

可用角色 —— 店长 ✅、技工 ✅（附录 B「使用券与会员权益（开单时）」两角色均 ✅）。

需求关联 —— REQ-MKT-004 会员能力开关、REQ-MKT-007 会员权益的触发位置

本图与本节主流程描述不符：主流程写「开单 → 选择会员权益 → 应用」，而现状是首页独立入口 + 输手机号核销，整个过程与订单无关，弹窗内也没有任何订单信息。两种形态的差别很大（一个是订单折扣项，一个是到店服务核销），需裁决 —— 见 REQ-MKT-007。

页面内容 —— 同一弹窗的已选中态：「免费查车」变为浅橙底 + 实心黑色对勾，「免费加玻璃水」仍为未选中，手机号输入框仍为空。

关键交互 —— ①再点已选行 → 取消选中（推测，本图无法确认）。本图只选中了一项，无法确认权益是单选还是多选。

可用角色 —— 同上图。

需求关联 —— REQ-MKT-007

手机号未填时「确认提交」按钮仍为完整橙色可点态，未见禁用态。App 化时该按钮应在手机号校验通过前禁用。

页面内容 —— 门店未开通会员体系时的引导页，灰色锁形图标与「会员体系门店未开通」之下列出开通所需的 8 个服务标签（其中混有回归测试数据）及一句服务同步开通说明，底部是未勾选的协议行加橙色「开通会员体系门店」按钮。

关键交互 —— ①点《德国马牌门店非轮胎项目服务协议》→ 查看协议全文；②勾选「本店具备以上服务……愿意加入上述选择的服务体系」；③点「开通会员体系门店」→ 提交开通（是否即时生效、是否需上游审核，本图无法确认）。8 个服务标签样式一致、无选中态，本图无法确认它们是静态展示还是可逐项勾选。

可用角色 —— 店长 ✅（开通属门店级承诺，且涉及协议签署）；技工 ✗（建议值，附录 B 未单列此功能）。

需求关联 —— REQ-MKT-004、REQ-MKT-008 会员体系开通流程

本图暴露了 REQ-MKT-004 的一处逻辑冲突：该规则要求「未开通会员体系的门店隐藏相关入口」，但本页本身就是未开通门店才能看到的开通入口 —— 若一并隐藏，门店将永远无法自助开通。需求需细化为「隐藏的是权益核销入口，保留的是开通申请入口」，见 REQ-MKT-008。

服务标签中的「测试无需领取的」「回归531会员」「全回归1028」三项是 O2O 侧的测试数据，非真实服务项；真实项应为前 5 项。该数据由 O2O 维护，清理属 O2O 侧责任，本 PRD 不为此提需求，仅提示读者勿据此图统计服务项数量。

本页的《德国马牌门店非轮胎项目服务协议》是继用户协议与隐私政策之外的第三份需签署留痕的协议（O2O 首页另有「协议中心」入口），App 化后协议签署的版本号与时间戳如何留痕，随 REQ-MKT-008 一并确认。

会员体系是门店级能力开关：未开通的门店应隐藏相关入口，而非展示空页面。这是门店能力开关的典型场景。

4.13.3 门店海报

页面内容 —— 「门店海报」页，只有橙色区块的「门店小程序码」与白色区块的「门店海报」列表两块，列表为空态（「没有数据了！」），故海报条目的字段构成、尺寸与模板类型均无法从本图确认。

关键交互 —— ①点/长按小程序码 → 保存或分享（本图未画出任何按钮，交互方式无法确认）；②有海报时点条目 → 预览/保存（同样无法确认）。本图中未见「保存到相册」或「分享」控件。

可用角色 —— 店长 ✅；技工 ✗（附录 B「管理券 / 门店海报」已定技工 ✗）TODO(REQ-MKT-001)。

需求关联 —— REQ-MKT-001、REQ-MKT-003 海报分享

V1.0 的 4.13.3 称「海报涉及保存到相册与分享」，但本图并未出现这两个控件 —— 它们可能在海报详情页或长按菜单中，也可能是 App 端的新增能力。TODO(REQ-MKT-003) 需一并明确控件位置，不只是分享目标。

另需注意：页面顶部的「门店小程序码」与海报是两件不同的物料，V1.0 只提到海报。小程序码扫码后进入的是消费者侧小程序（消费者侧本就不做 App 化），因此码本身无需改造，但 App 内是否保留该展示位需确认。

海报涉及保存到相册与分享。App 内需要相册写入权限与分享能力 —— 见 8.4 安全与合规、《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。

REQ-MKT-005 券与返利关系 —— 消费者补贴（返利构成）与消费券是否为同一资金来源待定 TODO(REQ-MKT-005)

REQ-MKT-006 消费券额度机制 —— 消费券非门店自建，额度按「扫码入库」与「补货率」自动累积，门店只能在可用额度内发放，实质是与进货表现挂钩的厂商激励。累积规则与考核周期、额度变更记录与详情两页是否进 App、发放对象与领取方式、额度是否随切换门店隔离，均待定 TODO(REQ-MKT-006)

REQ-MKT-007 会员权益的触发位置 —— 本节主流程写作「开单 → 选择会员权益 → 应用」，现状却是首页宫格独立入口 → 输入会员手机号 → 勾选权益 → 提交，与开单流程完全解耦，二者是不同的业务动作。App 采用哪一种、权益单选还是多选、核销是否生成单据并计入经营业绩、会员手机号与销售侧客户手机号是否同一份数据，均待定 TODO(REQ-MKT-007)

REQ-MKT-008 会员体系开通流程与协议留痕 —— 开通是门店自助动作，前置条件是承诺具备一组非轮胎服务能力并签署《德国马牌门店非轮胎项目服务协议》，开通后联动服务项管理。App 是否承载该流程、服务标签是承诺清单还是可逐项勾选、是否需上游审核、协议签署留痕（版本号 + 时间戳）如何处理，均待定 TODO(REQ-MKT-008)。这是继用户协议与隐私政策之外的第三份协议

4.13.5 验收标准

未开通会员体系的门店，会员权益入口不下发；
开单选券时，不可用券给出不可用原因而非简单置灰；
海报保存失败（无相册权限）时给出可操作的引导，而非静默失败。

4.14 福利兑换（MSIP）

本模块是全 PRD 材料最少的一个：至今没有任何 MSIP 的页面截图或设计稿，业务需求文档中也只在背景部分提过一次。已定的是业务目标与积分主体两条，其余四条全部待确认。这一状况已作为风险 R1 登记在第 10 章。

积分主体已定：积分挂在门店账下，不归属店员个人。 App 面向经销商，店长与技工都是门店的员工；积分是品牌方发给经销商的福利，因此切换门店时积分随门店上下文一起切换，同门店的店员看到同一份额度。这一条决定了本模块的权限模型与切店行为。

页面内容、积分产生规则与 MSIP 的集成方式仍待补，见 4.14.1。

业务目标 —— 品牌方以积分形式向经销商发放福利，门店用积分兑换商品或权益，作为对门店的激励手段

入口 —— 现状：ROOS / O2O 首页的「积分兑换」（见 2.7.2、2.7.3）；目标：宫格版「福利兑换」（见 4.2.5）或个人中心的积分资产卡

页面内容 —— 待确认 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）；同门店所有角色看到同一份额度

REQ-MSP-004 集成方式 —— MSIP 是否提供 API，还是只能以 Embedded H5 嵌入待确认 TODO(REQ-MSP-004)。若只能嵌 H5，则与提醒同为容器方案，集成矩阵需相应调整

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的现状截图）。整合后三处全部取消，收敛为 App 内的单一「福利兑换」入口；积分余额在个人中心的资产卡与福利兑换页两处展示时，必须同源同刷新时机，不得出现两个数

REQ-MSP-008 积分余额的口径与失效 —— ①积分余额随门店上下文切换而整体失效重取，不做跨门店缓存合并（依赖 REQ-MSP-003）；②余额展示须带数据口径时间，若 MSIP 为 H5 嵌入则口径时间由 MSIP 页面自行承载；③兑换成功后余额须立即回刷，不得依赖用户手动下拉

5 主数据

主数据是全 App 各模块共同依赖的基础数据，其来源与同步方式决定了整合后的数据一致性。

5.1 主数据来源

#	类型	来源	同步方式	说明
1	产品主数据	SAP、CDMS	Tire：通过 SFTP 文件获取 SAP price catalog Non-tire：先确认 CDMS 非轮数据的来源 `TODO(REQ-MDM-001)`	非轮数据来源是本项的前置阻塞点
2	零售主数据	马上下单	通过 API 获取增量、全量；CSO 的数据也会同步马上下单	含门店、经销商等零售侧基础数据
3	门店主数据	马上下单	API	门店基础信息、服务信息、营业执照、渠道信息、人员，见 4.9
4	车型主数据	RMS	`TODO(REQ-MDM-002)`	车型匹配，见 4.3.2、4.6.8 业务数据列表
5	用户与权限主数据	App Backend	内部	账号、角色、可用系统授权，见 4.1、6.3、6.4
6	积分主数据	MSIP	`TODO(REQ-MSP-004)`	见 4.14

主数据来源

5.2 主数据使用原则

REQ-MDM-003 —— App 不是主数据的权威源。所有主数据字段在 App 内默认只读；可编辑字段必须显式列出并回写到权威源

REQ-MDM-004 —— 价格以源系统返回值为准，App 侧不做二次计算（同 REQ-PUR-007、REQ-FIN-005）

REQ-MDM-005 —— 产品主数据经 SFTP 文件同步，存在时延；App 需展示数据口径时间，避免门店以为是实时价 TODO(REQ-MDM-005)

REQ-MDM-006 —— 门店主数据变更后，需级联刷新所有已缓存的门店上下文（见《App 门店上下文与会话管理文档》）

CDMS 非轮数据来源未定（REQ-MDM-001），它直接卡住采购中的非轮产品分类与商品域，见 10.2。

6 后台管理

后台管理是运营方（非门店）使用的 Web 端，与 App 共用一套 App Backend。

6.1 后台用户登录

后台管理员，通过用户名或验证码方式安全登录平台。

目标角色 —— 运营管理员（非门店角色，与店长/技工体系隔离）

权限规则 —— 后台账号与 App 账号不互通 TODO(REQ-ADM-001)

数据来源 —— App Backend

6.2 后台管理首页

首页看板构成：

区域	内容
左侧菜单	主页 / 用户账号管理 / RBAC 权限体系 / APP 配置 / 接口监控中心 / 基础数据配置 / 系统管理信息 / 日志查询
实时业务异常告警	置顶告警条
统计卡（4 张）	总营业门店 / 累计注册用户 / 7 日活跃用户 / 90 天僵尸用户
门店客户转化漏斗	转化率分析
APP 各功能当日访问趋势	折线图，数据源为埋点
三类接口性能监控	后台接口 / 小程序接口 / F6 接口，SLA 200ms

后台管理首页看板构成

左侧菜单中的 APP 配置与基础数据配置两项需特别说明：

APP 配置正是角色化 tab 下发的配置端 —— 这一项是 App 导航模型能落地的前提。其配置粒度（按角色 / 按门店能力 / 按单店覆盖）—— TODO(REQ-ADM-002)。

基础数据配置与 5 主数据的关系 —— TODO(REQ-ADM-003)。

6.3 用户账号管理

门店与后台用户账号的全生命周期管理。

页面内容 —— 账号列表、账号详情、创建/停用/删除、重置密码、绑定门店

关联 —— 对应 App 侧的注册审核（REQ-LGN-002）与人员管理

待确认 —— 账号审核流是在后台还是由店长在 App 内完成 TODO(REQ-ADM-004)

6.4 RBAC 权限管理

用户权限管理。

页面内容 —— 角色定义、权限点维护、角色-权限绑定、用户-角色绑定

关联 —— 首版角色仅店长/技工；「可用系统」维度（REQ-STM-001）需在此建模

待确认 —— 角色是全局定义还是可按门店自定义 TODO(REQ-ADM-005)

6.5 接口监控

监控 APP 后台调用其它外围系统的健康状态。

监控对象 —— 后台接口 / 小程序接口（ROOS、O2O、延保、马上下单）/ F6 接口

指标 —— 响应时间（SLA 200ms）、成功率、错误码分布

关联 —— 与集成矩阵一一对应；告警联动见《后端可观测性文档》

待确认 —— 200ms 是 P50 还是 P95、是否分接口分级 TODO(REQ-ADM-006)

6.6 系统管理

一、消息公告管理 —— 对应 App 的公告/通知与首页顶部滚动促销提示。

二、系统数据字典管理 —— 与 5 主数据、6.2 的「基础数据配置」的边界 TODO(REQ-ADM-003)。

6.7 日志查询

查询后台用户的操作日志。

门店侧的高风险操作（保单作废、银行账号解绑、人员授权变更）是否也需进入同一套审计日志 —— TODO(REQ-ADM-007)。日志脱敏要求见《后端可观测性文档》。

6.8 埋点

埋点方案见仓库文档《App 可观测性与埋点文档》。

该文档记录：客户端埋点选型为神策，但本项目没有现成账号，开通属采购流程，属跨文档阻塞项，见 10.3。崩溃上报不引入独立崩溃平台，由现有的腾讯 Bugly（原生崩溃 / ANR）加神策自定义事件（Dart 异常明细）共同承担，错误看板在神策上二次开发。

因此神策的可用性同时决定埋点与错误看板两件事，权重比原先更高。

后台首页看板的「APP 各功能当日访问趋势」「门店客户转化漏斗」「7 日活跃 / 90 天僵尸用户」全部依赖埋点数据 —— 埋点方案不落地，后台首页看板就是空的。

7 系统集成与架构边界

本章说明 App 与各外部系统的连接方式。技术结论来自既有架构文档（《App 工程结构与分包架构文档》–《App 工程规范与 CI 门禁文档》、《后端工程结构文档》–《后端并发、事务与定时任务文档》），这些结论优先于任何前期材料。

7.1 访问链路原则

REQ-INT-001 —— Mobile App → App Backend 是唯一主链路。App 不直连任何外围系统（ROOS / O2O / 延保后台 / 马上下单 / RMS / MSIP / F6）

REQ-INT-002 —— 外围系统由 App Backend 的集成层统一代理，采用同步 RestClient + Resilience4j，不引入响应式栈（见《后端集成层设计文档》）

REQ-INT-003 —— 扫码是 App 原生实现（native_scan），同时服务原生页面与 H5 的 JSBridge。不嵌入第三方扫码页

REQ-INT-004 —— 门店上下文（storeId/storeCode/orgId/roleCode）由 App Backend 统一签发，切店时级联失效所有缓存（见《App 门店上下文与会话管理文档》）

REQ-INT-005 —— 单个外围系统不可用时局部降级，不阻断整个页面（见《后端跨域协作与聚合文档》）

REQ-INT-003 是对前期材料的明确纠正。 《Conti Retail APP 功能模块与数据来源整理》在第 2.4 节「扫一扫」、第 3.2.1 节「首页扫码」、第 4.5 节「收货」三处均写「Involve F6 Page / 嵌入 F6 扫码页面」。这与《App 原生能力集成文档》和《App Embedded H5 容器与 JSBridge 文档》的结论冲突，以架构文档为准。原因：通用扫码库解条码/二维码，VIN 与车牌需要 OCR，二者都要作为原生能力提供给 H5，嵌一个 H5 扫码页反而多一层。参见《文档仓库说明》。

7.2 集成矩阵

#	外围系统	承载模块	集成方式	关键数据
1	ROOS	4.6 采购（马牌商品）、4.7 库存、4.8 我的、4.10 财务、4.12 业绩	API	商品、价格、购物车、采购订单、售后、信用额度、优惠券、条码库存、对账单、业绩
2	O2O 接单宝	4.3 销售、4.7 库存、4.9 门店管理、4.10 财务、4.11 返利、4.12 业绩、4.13 营销会员	API	线上订单、服务单、核销、库存查询、扫码入库、店铺管理、对账提现、返利、经营业绩、券与会员
3	延保后台	4.5 延保	API	保单、预约、理赔、售后鉴定、返利、教程
4	马上下单	4.9 门店管理、5 主数据	API（增量 + 全量）	门店主数据、零售主数据、人员
5	F6	4.3 销售（到店记录/开单/施工查车/结算）、4.4 提醒、4.6 采购（非马牌商品）	Embedded H5 + Adapter；非马牌采购的接入路径 `TODO(REQ-PUR-013)`	到店记录、工单、检测报告、商机、结算收银、提醒规则、非马牌商品与订货
6	RMS	4.3 销售车型匹配	`TODO(REQ-INT-006)`	车型主数据
7	MSIP	4.14 福利兑换	`TODO(REQ-MSP-004)`	积分、兑换
8	SAP	5 主数据	SFTP 文件	Tire price catalog
9	CDMS	5 主数据、首页待办	`TODO(REQ-MDM-001)`	非轮产品数据、支付提醒
10	短信网关	4.1 登录、检测报告发送	第三方	验证码、报告短信
11	企业微信	客服入口	`TODO(REQ-MIN-004)`	O2O / 延保客服

系统集成矩阵

ROOS 与 CDMS 的命名存在混用：采购走 ROOS、首页待办写 CDMS 支付、主数据写 SAP + CDMS。二者是同一系统的不同叫法，还是两套系统 —— TODO(REQ-INT-007)。这直接影响集成矩阵第 1 与第 9 行是否应合并。

7.3 F6 集成边界

F6 是唯一以 Embedded H5 方式集成的外围系统，其余系统一律走 API。以 H5 承接的是销售的到店记录 / 开单 / 施工查车 / 结算与提醒全部功能；采购中的非马牌商品则需要 F6 开放商品与订货 API，是 F6 集成中唯一的 API 面 —— 即 F6 一家同时占用两种集成方式。需注意马牌采购所走的 ROOS 本身也建于 F6 后台之上，因此 F6 的实际影响面比矩阵中列出的更大。

维度	约定
容器	`core_webview`，基于 `webview_flutter`（Flutter 官方维护）
URL 来源	只接受 App Backend 换票后下发的 URL，路由里不传裸 URL
桥接通道	单一 JavaScript Channel `ContiBridge`，协议 `{id, method, params}`
适配层	App Backend 侧的 F6 Integration Adapter
导航栏	同时提供「返回」与「关闭」；Android 物理返回键必须拦截，与「返回」同语义
缓存	走 WebView HTTP 缓存，首版不做离线包

F6 集成边界

JSBridge 能力清单（详见《App Embedded H5 容器与 JSBridge 文档》）：

method	说明	底层
`scan`	打开扫码（`barcode`/`vin`/`plate`）	`native_scan`
`camera`	打开相机拍照	`native_media`
`pickImage`	打开相册（支持多选）	`native_media`
`uploadFile`	上传图片/文件（带进度事件）	`core_network`
`dial`	调起拨号（不直接拨出）	`native_device`
`closePage`	关闭当前 H5 页	`core_router`
`goBack`	H5 内返回上一页（无历史降级为 `closePage`）	WebView
`refresh`	刷新页面	WebView
`getAuthState`	获取登录态 / 触发换票（不返回 token 明文）	`core_auth`
`getStoreContext`	获取门店上下文	`core_auth`
`toast` / `dialog` / `loading`	原生提示控件	`core_ui`
`navigate`	跳转 App 原生页（路由白名单）	`core_router`
`setTitle`	设置导航栏标题	`core_ui`

JSBridge 能力清单

能力条目数在不同文档中记法不一（计划稿记 13 项、前期 PRD 记 12 项）。按《App Embedded H5 容器与 JSBridge 文档》的分行方式，本表为 13 行，但因 toast / dialog / loading 合并为一行，实际 method 名共 15 个。以《App Embedded H5 容器与 JSBridge 文档》为准，本表仅为需求侧引用。

F6 集成的四个关键异常场景（《App Embedded H5 容器与 JSBridge 文档》已定方案）：票据过期、白屏/超时、上传中断、门店切换/登出。

F6 覆盖率问题：并非所有门店都接入 F6。未接 F6 的门店，销售的到店记录、开单、施工查车、结算全链路如何提供 —— TODO(REQ-INT-008)。随着提醒整体落在 F6 上、采购的非马牌商品也由 F6 供货，未接 F6 的门店会一次性失去提醒模块与半个采购模块，这使 F6 成为门店能力开关中影响面最大的一个开关。该问题也是《Conti Retail APP 功能模块与数据来源整理》第 3.2.1 节自己提出的（「要考虑未接 F6 的车辆如何处理？」）。

7.4 门店能力开关

不同门店开通的业务不同，App 必须按门店能力下发功能，而非全量展示后再报错。

开关	影响	现状实证
是否接入 F6	销售全链路	`TODO(REQ-INT-008)`
是否开通延保	延保 tab	延保为独立小程序，非全部门店安装
是否开通会员体系	会员权益	4.13.2 会员体系门店-未开通
是否开通 CATI	CATI 理赔	4.5.4 认证轮胎技术检测中心
单独服务项开通情况	服务单可选项目	4.9.4
渠道开通状态	订单渠道（高德/美团/抖音/百度）	4.9.1 设计稿渠道信息
可用系统授权	各 tab 可见性	4.9.1 人员管理「可用系统」

门店能力开关

REQ-INT-009 —— 能力开关由 App Backend 在登录/切店时随门店上下文一次性下发，客户端不自行推断

REQ-INT-010 —— 未开通的能力不下发入口，而非展示后提示「未开通」

REQ-INT-011 —— 能力开关 + 角色共同决定 tab 集合（见 4.2.5）

REQ-INT-012 —— 深链/推送跳转到未开通模块时，需有统一的兜底页

8 非功能需求

各项指标多数尚未由业务方给出，本章先建立条目与责任归属，逐条标注 TODO。

8.1 性能

REQ-NFR-001 冷启动 —— TODO(REQ-NFR-001)

REQ-NFR-002 首页首屏 —— 首页聚合多个外围系统（待办来自 O2O + 延保，预警来自 ROOS + O2O），需并行 fan-out 且局部降级（《后端跨域协作与聚合文档》）。目标值 TODO(REQ-NFR-002)

REQ-NFR-003 接口 SLA —— 后台/小程序/F6 三类接口监控口径为 200ms（6.5），P50/P95 归属待定 TODO(REQ-ADM-006)

REQ-NFR-004 扫码识别 —— 条码/二维码、VIN、车牌三种模式的识别时延与成功率 TODO(REQ-NFR-004)

REQ-NFR-005 H5 首屏 —— F6 页面白屏超时阈值与重试策略见《App Embedded H5 容器与 JSBridge 文档》

REQ-NFR-006 并发 —— 门店总数与日活峰值 TODO(REQ-NFR-006)

8.2 统一交互规则

整合六套小程序，最大的隐性风险是同一业务概念在不同来源页面上叫法与交互不一致。

REQ-NFR-007 —— 统一设计系统：core_ui 的 Material 3 主题与设计 token（对应仓库待编的《UI 设计系统文档》）

REQ-NFR-008 —— 同名不同义必须消歧：如采购订单五状态与销售订单五状态、两套返利、三套经营业绩、三套券

REQ-NFR-009 —— 版本代号（「1.0/2.0 经营业绩」「2.0 店铺信息」）不得出现在 App 界面 TODO(REQ-PRF-002)

REQ-NFR-010 —— H5 页面的 toast/dialog/loading 使用原生控件，保证与原生页视觉一致

REQ-NFR-011 —— 首版单语言，但需预留 flutter_localizations + intl 结构

8.3 可用性与容错

REQ-NFR-012 —— 单一外围系统故障时局部降级，首页其余卡片正常展示并标注「暂不可用」

REQ-NFR-013 —— 统一错误处理与 ApiResult 契约（见《App 错误处理与 API 契约文档》）

REQ-NFR-014 —— 错误码为 5 位数字、前 2 位为域段（10xxx 平台通用、11xxx 认证与门店、20xxx/21xxx 采购/库存、3xxxx 外部系统集成）。基础码已定，各域业务码在开发对应模块时随接口增补；客户端对未识别的码统一展示后端返回的提示文案

REQ-NFR-015 —— 崩溃上报：腾讯 Bugly（原生崩溃 / ANR）；Dart 异常明细与错误看板：神策自定义事件；客户端埋点：神策。神策账号可用性为阻塞项，见 10.3

8.4 安全与合规

REQ-NFR-016 —— 全链路 HTTPS

REQ-NFR-017 —— JWT + refresh 轮换，门店上下文参与越权隔离（见《后端安全与认证文档》）

REQ-NFR-018 —— H5 不传递 token 明文，getAuthState 只返回状态并触发换票

REQ-NFR-019 —— 日志脱敏：手机号、车牌、身份证、银行账号（见《后端可观测性文档》、《App 可观测性与埋点文档》）

REQ-NFR-020 —— 用户协议与隐私政策须在注册/登录前可查看并确认

REQ-NFR-021 —— 权限申请：相机（扫码/拍照）、相册读写（海报保存、证据上传）、定位（扫码入库以地图定位为准）、拨号

REQ-NFR-022 —— 高风险操作二次确认 + 审计：保单作废、银行账号解绑、人员授权变更、登出

REQ-NFR-023 —— 数据出境：首版不涉及（崩溃、埋点、车牌识别均落在境内服务）。但车辆照片会上传至第三方 OCR 服务进行识别，属须告知的处理行为，必须写入隐私政策；照片在服务端为临时对象、识别完成后按生命周期规则自动清除。引入任何境外 SaaS 前须重新评估

8.5 兼容性

REQ-NFR-024 平台 —— 首版 Android / iOS；鸿蒙 OHOS 不在首版内（SDK 基线锁 3.44.9 为后续 OHOS 适配留窗口）

REQ-NFR-025 最低系统版本 —— TODO(REQ-NFR-025)

REQ-NFR-026 设备形态 —— 门店常用机型与屏幕尺寸清单 TODO(REQ-NFR-026)

REQ-NFR-027 暗色模式 —— 是否首版支持 TODO(REQ-NFR-027)

8.6 弱网与离线

门店场地（地下车库、仓库、施工区）网络条件差，而恰恰是这些场景要上传大文件。

REQ-NFR-028 —— 装车视频、鉴定照片/视频、营业执照、检测报告上传须支持失败重试与本地暂存

REQ-NFR-029 —— 扫码入库在断网时可本地暂存，恢复后批量提交且幂等不重复

REQ-NFR-030 —— 购物车勾选与数量修改在弱网下不丢失

REQ-NFR-031 —— H5 上传中断的恢复策略见《App Embedded H5 容器与 JSBridge 文档》

REQ-NFR-032 —— 离线可读的数据范围（如今日待办、当前施工队列）TODO(REQ-NFR-032)

REQ-NFR-038 —— 车牌识别依赖网络（云端 OCR），断网或弱网下不可用：「手工输码」须为常驻并列入口；识别失败不自动重试，直接引导至手工输码

8.7 包体积与发布

REQ-NFR-033 包体积上限 —— TODO(REQ-NFR-033)

REQ-NFR-034 多环境 —— dev / uat / prod flavor（见《App 多环境构建文档》）

REQ-NFR-035 iOS 构建 —— 由远程 Mac 出包；首版手工执行仓库内构建脚本，后续接入流水线

REQ-NFR-036 内测分发 —— Android 走托管的 OTA 分发页，iOS 走 TestFlight；不使用 Firebase App Distribution

REQ-NFR-037 强制升级 —— 是否需要版本强制升级机制 TODO(REQ-NFR-037)；若需要，倾向与内测分发一并收进后台的「APP 发布管理」功能

9 验收标准

各模块的验收标准已随模块给出（4.1.6、4.2.8、4.3.10、4.4.7、4.5.10、4.6.9、4.7.5、4.8.7、4.9.7、4.10.7、4.11.6、4.12.5、4.13.5）。本章只列跨模块的整合类验收，即「六套小程序合成一个 App」这件事本身是否做成了。

9.1 验收原则

REQ-ACC-001 —— 每条验收标准必须可由一名不了解实现的测试人员在真机上独立执行并判定通过/失败

REQ-ACC-002 —— 带 TODO 的需求在其待确认项关闭前不进入验收范围；关闭后须补写对应验收标准

REQ-ACC-003 —— 验收环境须覆盖已接入 F6 与未接入 F6 两类门店（见 REQ-INT-008）

9.2 整合类验收

这九条直接对应第 2 章的六类痛点，是本项目「做没做成」的判据：

#	验收标准	对应痛点
1	店长与技工完成各自一天的完整业务旅程，全程不跳出 App、不打开任何微信小程序	2.1
2	App 内不存在任何跳转其它小程序的入口（ROOS 四个互跳入口、延保「其他小程序入口」全部移除）	2.1
3	一次登录后，访问采购、销售、延保、库存、财务各模块均无需二次登录或再次选店	2.1、2.2
4	全局只有一套底部导航；切换角色（店长↔技工）后 tab 集合随之变化，且变化仅由后端下发驱动	2.1
5	技工账号在任何路径下（含深链、推送、H5 内 `navigate`）都无法访问未授权模块	2.2
6	同一业务数据（如扫码入库量、某笔订单金额）在首页、模块页、报表页三处显示一致	2.3、2.5
7	返利、优惠券、可提现金额三类金额均可点开查看构成与规则说明，不出现无解释的数字	2.4
8	延保建单可从销售结算页直接跳转带参进入，不需要重新输入车牌	2.6
9	门店未开通的能力（延保、会员体系、CATI、F6）入口不出现，而非出现后报错	7.4

整合类验收标准

9.3 角色与权限验收

#	验收标准
1	以技工账号登录，附录 B 权限矩阵中标记为「✗」的操作在 UI 上不可见，且接口层直接拒绝
2	店长授予/收回技工的模块授权后，技工端下次进入 App 即生效，无需重装
3	切换门店后，上一门店的业务数据缓存全部失效，不出现串店数据
4	登出后重新打开 App 不自动登录；本地 Token、门店上下文、业务缓存全部清除

角色与权限验收标准

9.4 集成验收

#	验收标准
1	App 抓包确认只与 App Backend 通信，无对 ROOS/O2O/延保/F6 的直连请求
2	F6 页面在 App 内以 Embedded H5 打开，导航栏同时具备「返回」与「关闭」，Android 物理返回键与「返回」同语义
3	在 F6 H5 页内调用扫码，弹出的是 App 原生扫码界面，不是网页扫码
4	H5 内票据过期时可自动换票续期，用户已填写的表单内容不丢失
5	任一外围系统返回超时/错误时，首页其余卡片仍正常展示并对故障区域标注「暂不可用」
6	门店切换或登出时，已打开的 H5 容器被正确关闭或刷新，不残留上一门店上下文

集成验收标准

9.5 非功能验收

#	验收标准
1	弱网（限速/断网）下，装车视频、鉴定照片、营业执照上传中断后可恢复，已拍摄内容不丢失
2	断网下扫码入库可暂存；恢复网络批量提交后，条码数量与实际扫描数一致且无重复
3	同一条码重复扫描被拒绝，并提示已入库时间与门店
4	日志与崩溃上报中不出现手机号、车牌、身份证、银行账号明文
5	所有高风险操作（保单作废、银行账号解绑、人员授权变更、登出）均有二次确认与审计记录

非功能验收标准

10 风险与待确认项

本章汇总全部未决事项。共 13 项需求冲突、144 项编号待确认项、1 项跨文档阻塞项（原 6 项中的 5 项已于 2026-08 裁决，结论见 10.3）。

10.1 需求冲突清单

以下冲突源于「业务需求 / 设计稿 / 现状小程序 / 架构文档」四方材料之间的不一致，需业务方裁决。

#	冲突	各方说法	本文档处理	关联
C1	底部导航三版	业务需求 4 tab（首页/库存/采购/我的）· 设计稿 5 tab（首页/入库/采购/延保/我的）· 宫格版（首页/门店管理/经营分析/账务对账/个人中心 + 8 宫格）	已定原则：App 导航为主、按角色 + 门店能力下发；各角色具体 tab 清单待确认	4.2.5 `TODO(REQ-HOM-010)`
C2	待办口径两层	业务需求：跨系统提醒（O2O 接单/CDMS 支付/延保视频/问卷/门店信息）· 设计稿：O2O 订单五状态	两层并存写入，标注各自来源；最终展示形态待定	待办事项两层口径 `TODO(REQ-HOM-008)`
C3	动态预警口径	业务需求四项（总数/月度签约/库存/时效订单）· 设计稿仅低库存	列全集，阈值待定	动态预警项 `TODO(REQ-HOM-009)`
C4	技术路线	前期 PRD 表头写「React Native / 备选 Flutter」	全文按 Flutter（01–14 全部基于 Flutter）	《文档仓库说明》
C5	扫码归属	《Conti Retail APP 功能模块与数据来源整理》第 2.4 / 3.2.1 / 4.5 节写「嵌入 F6 扫码页」	按 App 原生实现（`native_scan` + JSBridge）	REQ-INT-003
C6	角色模型	业务需求店长/技工 · 前期 PRD 八角色	正文用店长/技工，八角色列为后续扩展	3.1
C7	ROOS / CDMS 关系	命名混用：采购走 ROOS、待办写 CDMS 支付、主数据写 SAP + CDMS	术语表标注，二者关系待确认	系统集成矩阵 `TODO(REQ-INT-007)`
C8	首页营收卡片	设计稿有「今日预计营收/毛利/客单价」· 业务需求无此项	写入 4.2 并标待确认口径	4.2.3 `TODO(REQ-HOM-011)`
C9	MSIP 福利兑换	ROOS/O2O 首页均有「积分兑换」入口 · 宫格稿有「福利兑换」· 业务需求仅在背景中提过一次	立 4.14 章；业务目标与积分主体已确认，页面内容与集成方式待补	`TODO(REQ-MSP-002)`、`TODO(REQ-MSP-004..006)`
C10	RMS / 零售管理	背景列为整合目标或截图出现入口，均无需求描述	范围待确认	系统集成矩阵 `TODO(REQ-INT-006)`
C11	O2O 独有功能无归属	平安账号、服务项报名、门店海报、服务结算单、会员权益、经营范围、协议中心	分别归入 4.9/4.10/4.13，需求细节待补	`TODO(REQ-STM-)`、`TODO(REQ-MKT-)`
C12	遗留未定事项	扫码核销流程、问卷提醒、月度签约达成预警、后台首页 index、CDMS 非轮数据来源	逐条转为编号待确认项；后台首页 index 已由原型图解决并关闭	`TODO(REQ-SAL-010)`、`TODO(REQ-HOM-014)`、`TODO(REQ-HOM-009)`、6.2、`TODO(REQ-MDM-001)`
C13	技工「当前施工队列」	设计稿技工首页有独立施工队列分区 · 业务需求完全无此项	写入 4.2.4，分派规则与状态机待定	`TODO(REQ-HOM-012)`、`TODO(REQ-SAL-014)`

需求冲突清单

C1 是所有冲突里优先级最高的一条 —— 导航 tab 清单不定，6.2 后台「APP 配置」就无法建模，各模块的入口也无法定稿。

10.2 待确认项清单

144 项，按模块分组。建议决策方一列为本文档的建议，非最终分工。

编号加粗的条目是 V1.1 逐图核对第 4 章 167 张配图时新增的，共 49 条；其余 95 条沿用 V1.0，其中 4 条（REQ-FIN-007 / REQ-MKT-005 / REQ-STM-006 / REQ-STM-007）是内容不变、只在本次修正编号错位后换了号，不算新增，故不加粗。编号加删除线的是 V1.1 已裁决关闭的，保留行以便追溯，不计入 144。即 144 = V1.0 沿用 95 + 新增 49；V1.0 原有 97 条，减去关闭的 2 条即 95。

10.2.1 登录（LGN）

编号	待确认内容	建议决策方
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.2 首页与导航（HOM）

编号	待确认内容	建议决策方
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	待办中「过期门店信息更新提醒」的数据来源	业务
REQ-HOM-016	首页促销位的形态与来源 —— 三版设计稿画了三种形态、附录 A.2 又是第四种；素材含第三方电商水印；点击目标、数据来源与技工可见性均未定	产品 / 业务

10.2.3 销售（SAL）

编号	待确认内容	建议决策方
REQ-SAL-001	交易流水号生成规则（前缀/门店码/日期/序列/跨天重置）	架构
REQ-SAL-010	~~扫码核销详细流程~~ 收窄为：重复核销与撤销核销的处理（格式、状态关系、错误分类已由 REQ-SAL-028/REQ-SAL-029 关闭）	业务
REQ-SAL-011	结算后跳延保的参数契约（F6 → App → 延保后台），须覆盖三条入口	架构
REQ-SAL-012	金额类字段对技工的可见性	产品 / 业务
REQ-SAL-014	~~O2O 服务单与 F6 工单的关系与主从~~ 收窄为：O2O 服务单与 F6 工单的主从（O2O 内部订单/服务单分工已由 REQ-SAL-027 明确）	架构 / 业务
REQ-SAL-015	App 交易流水号与 F6 到店单号的映射存储与对外展示口径	架构
REQ-SAL-020	检测项目类型是否按门店经营范围过滤	产品 / 业务
REQ-SAL-024	F6 开单页的轮胎价格与库存由谁提供、如何回填（现状 F6 侧全为空）	架构 / 业务
REQ-SAL-025	F6 是否支持无广告、无自有导航的容器模式	架构 / 对外协调
REQ-SAL-026	车主个人信息的统一脱敏口径；F6 侧能否配置；平台号码保护期对拨号的影响	法务 / 架构
REQ-SAL-030	订单金额由哪个接口、在哪个时点下发	架构 / 对外协调
~~REQ-SAL-013~~	~~订单渠道清单是否可配置~~ —— V1.1 关闭，结论见 REQ-SAL-036	—

10.2.4 提醒（RMD）

编号	待确认内容	建议决策方
REQ-RMD-005	提醒入口对技工是否可见	产品
REQ-RMD-007	F6 能否提供移动端版式的提醒页 URL	架构 / F6

10.2.5 延保（WTY）

编号	待确认内容	建议决策方
REQ-WTY-002	~~延保待办与首页待办的归并方式~~ 收窄为：归并后的计数口径与刷新时机（归并方式已由 REQ-WTY-028 明确）	产品
REQ-WTY-003	技工可执行的延保操作范围	产品
REQ-WTY-004	延保返利对技工是否可见	产品
REQ-WTY-005	~~保单作废的权限、二次确认、作废原因、是否需后台审批~~ 收窄为：权限归属与是否需后台审批（状态校验、二次确认、作废原因已由 REQ-WTY-016 明确）	业务 / 安全
REQ-WTY-018	消费者未确认延保时的催办方式（是否推送消费者、门店能否主动催办）	业务
REQ-WTY-031	延保品牌枚举是否包含卡迪睿德	业务 / 主数据
~~REQ-WTY-006~~	~~延保与 O2O 两处 CATI 入口的关系与归属~~ —— V1.1 关闭，结论见 REQ-WTY-023	—

10.2.6 采购（PUR）

编号	待确认内容	建议决策方
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	售后类型、可申请时限、退款去向（信用额度 / 返利 / 抵扣券）与审核流程	业务 / 财务

10.2.7 库存（INV）

编号	待确认内容	建议决策方
REQ-INV-001	技工是否可见小程序结算价	业务
REQ-INV-002	SKU 与产品编码的口径统一（一行多编码如何呈现）	业务 / 架构
REQ-INV-003	库存状态标签的数据覆盖率与刷新频率	业务
REQ-INV-004	「黑科技」与「促销」两个筛选维度的取舍	产品
REQ-INV-005	扫码入库的权威写入目标（O2O / ROOS / 双写）	架构
REQ-INV-008	四级筛选取值需数据清洗 —— 现状取值含测试残留、越界值、疑似重复与字段串位	业务 / 架构
REQ-INV-009	扫码出库的「去延保 / 直接出库」分支 —— 本模块与延保模块的衔接点，现有需求完全未描述	产品 / 业务
REQ-INV-010	条码有效性状态 —— 有效 / 失效（作废）两态的流转规则、作废权限与重新入库规则均未定义	业务 / 架构
REQ-INV-011	本模块字段清单缺失 —— 附录 A 无库存节，字段与权威数据来源需业务与架构补齐，详见附录 A	业务 / 架构

10.2.8 我的（MIN）

编号	待确认内容	建议决策方
REQ-MIN-001	个人中心保留哪 6 项、其余下沉到哪些模块	产品
REQ-MIN-002	资产类（额度/返利/对账单）是否限店长	业务
REQ-MIN-003	姓名的权威来源与回写范围	架构
REQ-MIN-004	服务热线 / 经销商客服 / 企微客服三个入口是否合并	产品
REQ-MIN-005	支付优先级设置放在个人中心还是采购结算	产品
REQ-MIN-006	「经营范围」归属个人中心还是门店管理	产品
REQ-MIN-007	切换门店时购物车、未提交表单、已打开 H5 页面如何处理；全局门店列表的权威绑定关系取自哪套系统	架构 / 产品
REQ-MIN-008	高德、美团客服现用个人手机号，是否替换为总机分机	运营
REQ-MIN-009	四项资产在两张资产卡里的落位；优惠券展示张数还是总金额；采购返利的品牌枚举是否完整（现含卡迪睿德）	产品 / 业务
REQ-MIN-010	优惠券「待激活」状态的激活入口与激活规则	业务
REQ-MIN-011	支付优先级设置是账号级还是门店级；变更对购物车内商品是否即时生效	架构
REQ-MIN-014	收货地址的权威数据源（是否来自马上下单接口）	架构
REQ-MIN-018	「账户管理」小程序的能力承接范围与接入方式	架构 / 业务

10.2.9 门店管理（STM）

编号	待确认内容	建议决策方
REQ-STM-001	「可用系统」授权模型（取值集合、与角色的关系）；另需补店员删除 / 停用链路与三套角色词汇的收敛	架构 / 产品
REQ-STM-002	「2.0 店铺信息」与「门店项目信息」的对应关系（设计稿未出稿，须补稿后才能比对）	业务
REQ-STM-003	营业执照等资质变更的审核流程；是否存在证照 OCR 识别回填	运营
REQ-STM-004	协议中心与延保条款是否合并（须覆盖三类协议）	法务 / 产品
REQ-STM-006	渠道到期是否产生首页待办或预警（V1.0 误标为 REQ-STM-007，见 4.9.6）	产品
REQ-STM-007	门店主数据中 App 内可编辑的字段范围；修改交互模型的统一（V1.0 误标为 REQ-STM-008，见 4.9.6）	架构
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 号前补货」是否做成提醒或待办；「安装码」与核销码是否同一物；三条协议义务是否需后台监控	业务 / 产品

10.2.10 财务与返利（FIN / RBT）

编号	待确认内容	建议决策方
REQ-FIN-001	财务模块是否限店长	业务
REQ-FIN-002	可提现金额的精确计算口径（核销 → 可提现）	财务
REQ-FIN-003	采购对账单与 O2O 提现是否合成「资金总览」；ROOS 对账单类型下拉还有哪些类型	产品 / 财务
REQ-FIN-004	银行账号绑定 / 解绑的二次验证方式（现状已确认必须验证，只缺方式）	安全 / 财务
REQ-FIN-007	首页「CDMS 支付提醒」与财务模块的关系（V1.0 误标为 REQ-FIN-005，见 4.10.6）	架构
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	银行账号三个敏感字段的脱敏口径统一	安全 / 财务
REQ-RBT-001	返利对技工是否可见（详情与核算是否同一档）	业务
REQ-RBT-002	返利补贴、核算后返利、三项构成的计算公式（4.11.4 已给出待验证草案）	财务
REQ-RBT-004	O2O 返利与延保返利是否合并入口	产品
REQ-RBT-007	渠道枚举与经营业绩模块不一致（多出「抖音团购轮胎」）；品牌名称三处三种写法；明细行字段两套合并	主数据 / 产品
REQ-RBT-008	安装费用无「撤回」分项是设计还是遗漏；「撤回」标签在安装费用分组下的空结果处理；三项说明形态是否统一	财务 / 产品
REQ-RBT-010	返利核算 Tab 是否需要独立筛选；事由标题的录入规范；核算调整回写到哪个月份	财务 / 产品
REQ-RBT-011	返利类型的完整枚举（现状可见「好评返利」不属三项构成任一项）	业务 / 财务

10.2.11 业绩、营销、福利兑换（PRF / MKT / MSP）

编号	待确认内容	建议决策方
REQ-PRF-001	技工可见的业绩指标范围	业务
REQ-PRF-002	「1.0 / 2.0」版本代号的业务命名替换	产品
REQ-PRF-003	ROOS 与 O2O 两套业绩的合并方式	业务
REQ-PRF-004	延保经营数据是否并入统一报表	业务
REQ-PRF-007	引流转化 Tab 的指标体系未定义 —— 线索三分类、环比、门店排名、市/全国对标折线图在需求中一片空白	产品 / 业务
REQ-PRF-008	指标与筛选的最终集合以哪一版为准 —— 设计稿与现状有四处实质不一致（计数卡文案、品牌筛选、收入项数、下钻标识）	产品
REQ-PRF-009	1.0 与 2.0 是两套不同的指标体系，不是同一套的两个版本 —— 指标名无一相同，仅改名不足以解决	业务 / 产品
REQ-MKT-001	技工可用券与权益但不可管理，边界确认	产品
REQ-MKT-002	三套券（O2O 消费券 / 门店营销券 / ROOS 马牌券·经销商券）的适用场景与叠加规则	业务
REQ-MKT-003	门店海报的分享目标与相册权限方案	产品
REQ-MKT-005	消费者补贴与消费券是否为同一资金来源（V1.0 误标为 REQ-MKT-004，见 4.13.4）	财务
REQ-MKT-006	消费券额度机制 —— 消费券非门店自建，而是按扫码入库与补货率自动累积额度，实为与进货挂钩的厂商激励，只字未提	业务 / 财务
REQ-MKT-007	会员权益的触发位置 —— 写「开单 → 选权益」，现状是首页独立入口且与开单完全解耦，两者是不同的业务动作	产品 / 业务
REQ-MKT-008	会员体系开通流程与协议留痕 —— 门店自助开通、承诺服务能力、签署第三份协议并联动服务项管理；且 REQ-MKT-004「未开通则隐藏入口」必须细化	产品
REQ-MSP-002	福利兑换的页面内容与主流程（兑换商品列表 / 详情 / 记录）	产品
REQ-MSP-004	MSIP 是否提供 API，还是只能嵌入 H5	架构
REQ-MSP-005	门店内是否限店长发起兑换	产品
REQ-MSP-006	积分如何产生（订货 / 入库 / 延保建单 / 核销，或后台直接发放）	业务

10.2.12 主数据、后台、集成（MDM / ADM / INT）

编号	待确认内容	建议决策方
REQ-MDM-001	CDMS 非轮数据的来源	架构
REQ-MDM-002	RMS 车型主数据的同步方式	架构
REQ-MDM-005	产品主数据（SFTP 同步）的口径时间是否需在 App 展示	产品
REQ-ADM-001	后台账号与 App 账号是否互通	架构
REQ-ADM-002	后台「APP 配置」的配置粒度（按角色 / 门店能力 / 单店覆盖）—— C1 的落地前提	架构 / 产品
REQ-ADM-003	「基础数据配置」与主数据、系统数据字典的边界	架构
REQ-ADM-004	账号审核在后台完成还是由店长在 App 内完成	产品
REQ-ADM-005	角色是全局定义还是可按门店自定义	架构
REQ-ADM-006	接口 SLA 200ms 是 P50 还是 P95、是否分接口分级	架构
REQ-ADM-007	门店侧高风险操作是否进入后台审计日志	安全
REQ-INT-006	RMS 的集成方式（C10）	架构
REQ-INT-007	ROOS 与 CDMS 是否为同一系统（C7）	架构
REQ-INT-008	未接入 F6 的门店，销售全链路如何提供	架构 / 产品

10.2.13 非功能（NFR）

编号	待确认内容	建议决策方
REQ-NFR-001	冷启动时长指标	架构
REQ-NFR-002	首页首屏时长指标	架构
REQ-NFR-004	扫码识别时延与成功率指标（条码 / VIN 在端上离线完成；车牌为云端 OCR，时延含网络往返与图片上传，需分开定指标）	架构
REQ-NFR-006	门店总数与日活峰值（并发基线）	业务
REQ-NFR-025	最低系统版本	架构
REQ-NFR-026	门店常用机型与屏幕尺寸清单	业务
REQ-NFR-027	是否首版支持暗色模式	产品
REQ-NFR-032	离线可读的数据范围	产品 / 架构
REQ-NFR-033	包体积上限	架构
REQ-NFR-037	是否需要版本强制升级机制	产品

10.3 跨文档阻塞项

以下来自仓库《文档仓库说明》，不解决会直接卡住工程落地。本文档不重复论证，只登记其对需求的影响。当前仅剩 1 项未决，另 5 项已于 2026-08 裁决，结论一并登记在下方。

阻塞项	出处	对本文档的影响
神策服务是否可用未确认	《App 可观测性与埋点文档》	后台首页看板的访问趋势、转化漏斗、活跃/僵尸用户全部依赖埋点 —— 埋点不落地，看板即为空。且 Dart 异常的明细看板也建在神策上（见下表崩溃上报一行），该项权重高于最初评估

未决的跨文档阻塞项

已裁决的 5 项：

原阻塞项	结论	对本文档的影响
iOS 构建链路不成立	由远程 Mac 出包，首版手工执行仓库内构建脚本，后续注册成流水线 Runner	REQ-NFR-035 已改写为确定要求
后端错误码表未定	分段方案与基础码已定死，业务码在开发对应模块时随接口增补；客户端对未识别的码统一展示后端提示文案	REQ-NFR-014 已改写；各模块「异常流程」可按默认文案验收
崩溃上报平台未定	不引入独立崩溃平台。原生崩溃 / ANR 走腾讯 Bugly，Dart 异常明细与错误看板走神策自定义事件（在神策上二次开发）	REQ-NFR-015 已改写；REQ-NFR-023 数据出境风险随之消除
内测分发渠道未定	Android 走托管的 OTA 分发页，iOS 走 TestFlight，不使用 Firebase；后续可能并入后台的「APP 发布管理」	REQ-NFR-036 已改写；与 REQ-NFR-037 强制升级的实现方式相关
车牌识别技术路径未验证	采用付费的云端 OCR 服务（拍照上传换识别结果），客户端不直连、由 App 后端代理	REQ-SAL-002 已改写。交互由「取景框自动识别」改为「拍一张照」，涉及该处设计稿的调整；弱网不可用与计费风险登记为 R9；照片上传第三方需写入隐私政策（REQ-NFR-023）

已裁决的跨文档阻塞项

10.4 风险登记

#	风险	影响	缓解建议
R1	需求密度不均 —— 销售与延保有完整现状与原型，而福利兑换至今无任何页面材料，采购中非马牌商品的部分也只有文字约定	排期估算失真	两处的范围与数据源均已确认；剩余风险集中在 `TODO(REQ-PUR-011)`（是否共用购物车）与 `TODO(REQ-MSP-002)`（兑换页面形态），需在设计阶段补出稿再估排期
R2	F6 覆盖率未知	未接 F6 门店的销售链路无方案，可能需要 App 内自建开单	优先关闭 `TODO(REQ-INT-008)`
R3	同名不同义大量存在（两套五状态订单、三套业绩、三套券、两套返利）	用户误操作、验收争议	术语与状态机在开发前统一定稿（REQ-NFR-008）
R4	数据双写风险 —— 扫码入库同时存在于 O2O 与 ROOS	数据不一致，报表对不上	优先关闭 `TODO(REQ-INV-005)`
R5	金额口径未定 —— 返利公式、可提现口径、预计营收口径均未定义	门店与厂商产生对账争议	财务口径需在开发前书面确认（`TODO(REQ-RBT-002)`、`TODO(REQ-FIN-002)`、`TODO(REQ-HOM-011)`）
R6	弱网 + 大文件上传是刚需场景	装车视频、鉴定证据上传失败会直接阻断理赔业务	断点续传与本地暂存作为首版必做项（8.6）
R7	导航配置端与 App 强耦合	后台「APP 配置」未建模则 tab 无法下发	`TODO(REQ-ADM-002)` 与 `TODO(REQ-HOM-010)` 需一并裁决
R8	能力陈述式需求不可直接验收	开发理解偏差	全部需求须沿用 1.8 的模板书写，新增与修订同样适用
R9	车牌识别依赖网络 —— 技术路径已定为付费的云端 OCR 服务，识别准确率由供应商保证，但门店地下车库、施工区弱网时该功能不可用，且按调用次数计费	接车与延保建单两条主流程在弱网下退化为纯手工录入	① 手工输码作为常驻并列入口，不是失败后的降级；② 上传前压缩图片，超时与重试上限设死，失败即转手工输码不自动重试；③ 置信度低于阈值时以「待确认」展示而非直接回填；④ 调用量需监控告警，防止误做成连续帧调用

风险登记

附录 A 业务数据字典

本附录汇总各模块的数据集及其来源。「来源」列取自《Conti Retail APP 功能模块与数据来源整理》（该文档为可信的字段级数据来源整理），并按第 7 章的架构结论校正。

来源标识说明：App Backend = App 自有；Mini Program Backend = 经 App Backend 代理的小程序后台（ROOS / O2O / 延保 / 马上下单）；F6 Backend = 经 F6 Adapter；Embedded H5 = F6 页面内自取；User Input = 用户录入。

A.1 登录

#	数据集	来源	安全	备注
1	第三方验证码	App Backend	HTTPS	短信调用第三方短信网关
2	登录成功结果集	App Backend	HTTPS	账号密码登录与验证码登录共用
3	用户协议与隐私政策完整内容	App Backend	HTTPS	注册/登录前须确认（REQ-NFR-020）

A.2 首页

#	数据集	来源	安全	备注
1	切换后的店铺信息集	App Backend	HTTPS
2	店铺列表结果集（用于切店）	App Backend	HTTPS
3	当前用户的菜单数据集	App Backend	HTTPS	即角色化 tab 下发（REQ-HOM-010）
4	动态预警	Mini Program Backend	HTTPS	来自 ROOS 与 O2O
5	促销信息	Mini Program Backend	HTTPS	首页顶部滚动提示
6	公告/通知列表（按发布时间倒序）	Mini Program Backend	HTTPS	支持查看、标记已读、删除
7	待办事项（按优先级/截止时间排序）	Mini Program Backend	HTTPS	来自 O2O 与延保后台

A.3 销售

#	数据集	来源	安全	备注
1	扫码结果（VIN / 车牌 / 条码二维码）	原生 `native_scan`	—	⚠️ 前期材料写「Involve F6 Page」，已按 REQ-INT-003 校正
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.4 提醒

#	数据集	来源	安全	备注
1	提醒规则、提醒单、提醒作业	F6 Backend	HTTPS	F6 后台自动按规则生成提醒单；App 以 Embedded H5 嵌入展示，不落地也不回写，见 4.4.5

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 校正
6	采购订单列表 / 采购订单详情	Mini Program Backend	HTTPS

采购商品字段（见 4.6.8 业务数据列表）：productName、productCode、brandTag、brand、price、priceUnit、tireSize、carModel、installPositon、productCategory。

A.6 延保

#	数据集	来源	安全	备注
1	延保服务信息集	Mini Program Backend	HTTPS	保存到延保后台
2	延保出库	Mini Program Backend	HTTPS
3	延保注册数据集	User Input	HTTPS	保存到延保后台
4	保单 / 预约 / 理赔 / 鉴定 / 返利 / 教程	Mini Program Backend	HTTPS	延保后台

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.8 经营分析与财务

#	数据集	来源	安全	备注
1	对账单	Mini Program Backend	HTTPS	采购及返利对账单（马牌），来自 ROOS 与 F6
2	核销结果集	Mini Program Backend	HTTPS	门店核销收入（马牌）
3	返利结果集	Mini Program Backend	HTTPS	返利余额、明细、规则、提现

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 条隐含一条尚未成文的规则：多设备可同时登录，单设备登出不影响其它设备。这与账号权限管控痛点中「账号共用」的治理诉求存在张力 —— 是否需要单设备登录限制，建议在 TODO(REQ-LGN-009) 一并确认。

附录 B 权限矩阵

角色定义见 3.1。首版仅店长与技工两个角色。

图例：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认

模块	功能	店长	技工	备注 / 待确认
登录	手机验证码 / 账号密码登录	✅	✅
	第三方登录（微信/支付宝）	❓	❓	仅见于设计稿 `TODO(REQ-LGN-003)`
	注册	❓	❓	需审核 `TODO(REQ-LGN-004)`
首页	门店切换	✅	❓	技工是否允许多门店 `TODO(REQ-HOM-001)`
	消息公告	✅	❓	业务需求说有、设计稿未画 `TODO(REQ-HOM-003)`
	待办事项	✅	❓	同上 `TODO(REQ-HOM-008)`
	动态预警	✅	❓	同上 `TODO(REQ-HOM-009)`
	今日经营卡片（金额类）	🔸	✗	店长可隐藏金额；技工仅见完工单数 `TODO(REQ-HOM-011)`
	当前施工队列	✗	✅	技工独有 `TODO(REQ-HOM-012)`
销售	接车 / 扫码识别	✅	⚙️
	检测、开单、施工	✅	⚙️
	扫码核销	✅	⚙️	流程待定 `TODO(REQ-SAL-010)`
	查看金额（商品总价/实收/待收）	✅	❓	`TODO(REQ-SAL-012)`
	结算收银	✅	⚙️
	线上订单接单 / 确定到货	✅	⚙️	接单时须选货品状态，影响履约路径（REQ-SAL-027）
	服务单核销安装	✅	⚙️	核销即安装，不可撤销（REQ-SAL-028）
提醒	设置提醒规则	✅	✗	属门店管理职能
	生成 / 跟进提醒单	✅	❓	页内权限由 F6 控制，App 只控入口可见性 `TODO(REQ-RMD-005)`
延保	建单（扫车牌/绑定车辆/装车视频）	✅	❓	`TODO(REQ-WTY-003)`
	保单查询	✅	❓	同上
	保单作废	🔸	✗	高风险，需二次确认 + 审计 `TODO(REQ-WTY-005)`
	理赔受理 / 售后鉴定	✅	❓	`TODO(REQ-WTY-003)`
	延保返利	✅	❓	`TODO(REQ-WTY-004)`
	鉴定资料采集（拍照 / 录像 / 提交）	✅	⚙️	现场作业，实际以技工为主，建议默认授予（REQ-WTY-026）
	经营数据 / 用户画像查看	✅	❓	含消费者性别年龄聚合，口径同 `TODO(REQ-WTY-004)`
	使用教程	✅	✅	培训材料，全角色开放（REQ-WTY-033）
采购	搜索 / 加购 / 查看订单	✅	⚙️	技工需被授权
	提交订单（涉及资金）	✅	❓	`TODO(REQ-PUR-002)`
	收货	✅	⚙️
	售后 / 退款	✅	⚙️	能否发起（而非仅查看）随 `TODO(REQ-PUR-002)` 一并确认
库存	库存查询	✅	✅
	查看小程序结算价	✅	❓	`TODO(REQ-INV-001)`
	扫码入库 / 出库	✅	✅	一线高频操作
我的	个人信息 / 换绑手机 / 登出	✅	✅
	我的账户（额度/返利/券/积分）	✅	❓	`TODO(REQ-MIN-002)`
	收货地址 / 我的收藏	✅	🔸	技工只读
	支付优先级设置	✅	✗	影响资金
	切换门店	✅	✅	可切换范围由后台绑定关系决定，不由角色决定（REQ-MIN-007）
	收藏列表中的商品价格	✅	❓	须与「查看小程序结算价」同口径，见 `TODO(REQ-INV-001)`（REQ-MIN-015）
	服务热线 / 客服入口	✅	✅	不设权限（REQ-MIN-008）
门店管理	查看门店信息	✅	🔸	技工只读，基本无门店管理权限
	修改基础信息 / 项目信息 / 营业执照	✅	✗
	人员管理与授权	✅	✗	高风险，需审计
	协议中心	✅	🔸	技工只读
财务	对账提现 / 收入 / 结算单	✅	✗	`TODO(REQ-FIN-001)`
	银行账号绑定 / 解绑	🔸	✗	高风险，需二次验证 `TODO(REQ-FIN-004)`
	采购对账单	✅	✗
返利	返利详情 / 核算	✅	❓	`TODO(REQ-RBT-001)`。核算 Tab 含考核扣款流水，敏感度高于按订单看返利，建议拆成「返利详情」「返利核算」两个权限开关
经营业绩	全量指标	✅	❓	技工可见范围 `TODO(REQ-PRF-001)`
营销会员	使用券与会员权益（开单时）	✅	✅
	管理券 / 门店海报	✅	✗	`TODO(REQ-MKT-001)`
福利兑换	积分余额查看	✅	✅	余额是门店级资产，查看与兑换分开授权：查看全角色开放
	积分兑换	✅	❓	积分属门店，同店两角色看到同一份余额；能否发起兑换待定 `TODO(REQ-MSP-005)`

权限矩阵（功能 × 角色）

编号	权限实施规则
REQ-ACC-004	权限在接口层强制，前端隐藏只是配套，不得作为唯一手段
REQ-ACC-005	⚙️ 类权限由店长或后台通过人员管理「可用系统」授予（`TODO(REQ-STM-001)`）
REQ-ACC-006	🔸 与 ❓ 项在待确认项关闭前，默认取更严格的一侧实现
REQ-ACC-007	权限变更后，用户下次进入 App 即生效（9.3）

权限实施规则

附录 C 图表清单

本文档共 173 张图与 44 张正文表格。图片按章节顺序排列，本清单给出每张图的说明与源文件，可用于核对导出后的 Word 文档配图是否完整、以及追溯每张截图的出处。C.3 只收正文表格；附录 A/B/C/D 与 10.2 自身的清单表不重复计入。

C.1 图片来源分布

来源目录	张数	用途
`mini-program-images/O2O/`	78	O2O 接单宝小程序现状截图
`mini-program-images/Warranty/`	44	延保门店端小程序现状截图
`mini-program-images/ROOS/`	20	ROOS 采购小程序现状截图
`app-design-images/`	15	新 App 目标形态设计稿
`images/`	16	业务流程原型图（F6 销售页面、提醒、后台管理）
合计	173

图片来源分布

C.2 各章节配图清单

2.7 现状小程序功能全景（4 张）

序	说明	文件
1	现状-ROOS 首页（公告 / 扫码出入库 / 四个互跳入口）	`mini-program-images/ROOS/首页.png`
2	现状-O2O 接单宝首页（单页承载全部功能）	`mini-program-images/O2O/接单宝首页.png`
3	现状-延保门店端首页（深色主题，立刻延保为主操作）	`mini-program-images/Warranty/首页.png`
4	现状-延保门店端工作台（六宫格 + 延保数据 + 返利简报）	`mini-program-images/Warranty/工作台.png`

4.1 账号登录（1 张）

序	说明	文件
1	设计稿-登录页（验证码 / 密码 / 第三方三种登录方式 + 注册入口 + 协议勾选）	`app-design-images/登录.png`

4.2 APP 首页（5 张）

序	说明	文件
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`

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`

4.4 提醒（3 张）

序	说明	文件
1	原型-设置提醒规则（F6「客情维护 > 商机设置」，八类 tab + 规则表 + 启停开关）	`images/原型-提醒-设置提醒规则.png`
2	原型-生成提醒单（F6 服务提醒列表，双看板 + 四状态 tab + 跟进按钮行，测试数据）	`images/原型-提醒-生成提醒单.png`
3	原型-跟进提醒单（与上图同一页面，PPT 标注四类跟进手段）	`images/原型-提醒-跟进提醒单.png`

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`

4.6 采购（9 张）

序	说明	文件
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`

4.7 库存（12 张）

序	说明	文件
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`

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.9 门店管理（14 张）

序	说明	文件
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`

4.10 财务与对账（11 张）

序	说明	文件
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`

4.11 返利中心（10 张）

序	说明	文件
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`

4.12 经营业绩与报表（8 张）

序	说明	文件
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`

4.13 营销与会员（7 张）

序	说明	文件
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`

6.1 后台用户登录（1 张）

序	说明	文件
1	原型-后台管理登录页	`images/原型-后台-登录.png`

6.2 后台管理首页（1 张）

序	说明	文件
1	原型-后台管理首页看板	`images/原型-后台-首页看板.png`

C.3 表格清单

序	说明	所属章节
1	术语与缩写定义	1.6 术语与缩写定义
2	需求模块码	1.7 需求编号规则
3	现状小程序底部导航（截图实测）	2.7 现状小程序功能全景
4	ROOS 小程序功能清单（20 张截图）	2.7 现状小程序功能全景
5	O2O 接单宝小程序功能清单（78 张截图）	2.7 现状小程序功能全景
6	延保门店端小程序功能清单（44 张截图）	2.7 现状小程序功能全景
7	痛点与需求映射	2.8 痛点 → 需求映射
8	企业内部干系人	3.2 企业内部干系人
9	外部对接系统厂商	3.3 外部对接系统厂商
10	模块总览	4.0 模块总览
11	账号登录业务数据	4.1 账号登录
12	现状入口 → App 导航映射	4.2 APP 首页
13	待办事项两层口径	4.2 APP 首页
14	动态预警项	4.2 APP 首页
15	店长 / 技工首页分区差异	4.2 APP 首页
16	三版底部导航方案	4.2 APP 首页
17	角色化 tab 配置（建议值，待确认）	4.2 APP 首页
18	APP 首页信息字段	4.2 APP 首页
19	根据车牌获取车主车辆信息	4.3 销售
20	保养提醒规则字段	4.4 提醒
21	提醒模块承接方案候选	4.4 提醒
22	采购模块角色差异	4.6 采购
23	采购业务数据表	4.6 采购
24	库存查询现状与目标差异	4.7 库存
25	三套「我的」的合并归属	4.8 我的 / 个人中心
26	结算周期与手续费口径	4.10 财务与对账
27	主数据来源	5.1 主数据来源
28	后台管理首页看板构成	6.2 后台管理首页
29	系统集成矩阵	7.2 集成矩阵
30	F6 集成边界	7.3 F6 集成边界
31	JSBridge 能力清单	7.3 F6 集成边界
32	门店能力开关	7.4 门店能力开关
33	整合类验收标准	9.2 整合类验收
34	角色与权限验收标准	9.3 角色与权限验收
35	集成验收标准	9.4 集成验收
36	非功能验收标准	9.5 非功能验收
37	需求冲突清单	10.1 需求冲突清单
38	未决的跨文档阻塞项	10.3 跨文档阻塞项
39	已裁决的跨文档阻塞项	10.3 跨文档阻塞项
40	风险登记	10.4 风险登记
41	权限矩阵（功能 × 角色）	附录 B 权限矩阵
42	权限实施规则	附录 B 权限矩阵
43	图片来源分布	C.1 图片来源分布
44	需求追溯矩阵（RTM）骨架	D.2 模块级追溯汇总

附录 D 需求追溯矩阵（RTM）

D.1 用途与填写规则

RTM 用于保证「痛点 → 需求 → 设计 → 开发 → 测试」四段链路不断裂。本附录给出骨架与填写规则；逐条明细在需求评审关闭 10.2 的 144 项待确认后，由 PO 与 QA 共同维护于独立表格（建议 Jira/禅道，不建议长期维护在本文档中）。

列定义

列	含义	取值来源
需求编号	`REQ-<模块码>-<3位序号>`	本文档第 4–8 章
需求描述	一句话陈述	各节「需求描述汇总」表
来源痛点	P1–P6	2.8 痛点→需求映射
来源材料	业务需求 / 设计稿 / 现状截图 / 原型图 / 架构文档	1.8 的来源标注
优先级	P0 必须 / P1 应该 / P2 可选	需求评审裁定
状态	已确认 / 待确认 / 已废弃	带 `TODO(...)` 标记的一律为「待确认」
设计稿	所在小节的设计稿 / 现状截图，或 Figma 链接	附录 C 图表清单
接口	API 路径	接口文档（待建，见《文档仓库说明》）
验收标准	AC 编号	第 9 章
测试用例	TC 编号	QA 维护

填写规则

REQ-ACC-008 —— 每条需求必须有至少一条验收标准；无验收标准的需求不得进入开发排期

REQ-ACC-009 —— 状态为「待确认」的需求不得进入开发排期；其在 10.2 中必须有对应条目与责任人

REQ-ACC-010 —— 需求变更时同步更新 RTM 与本文档修订历史，变更未同步的视为未变更

REQ-ACC-011 —— 10.1 中 C1–C13 任一冲突未裁决前，受其影响的需求一律标「待确认」

D.2 模块级追溯汇总

模块码	模块	章节	需求条数	其中待确认	完成度
LGN	账号登录	4.1	11	7	36%
HOM	APP 首页	4.2	16	11	31%
SAL	销售	4.3	37	11	70%
RMD	提醒	4.4	7	2	71%
WTY	延保	4.5	38	6	84%
PUR	采购	4.6	18	12	33%
INV	库存	4.7	11	9	18%
MIN	我的 / 个人中心	4.8	20	13	35%
STM	门店管理	4.9	14	13	7%
FIN	财务与对账	4.10	14	12	14%
RBT	返利中心	4.11	11	7	36%
PRF	经营业绩与报表	4.12	9	7	22%
MKT	营销与会员	4.13	8	7	13%
MSP	福利兑换 MSIP	4.14	8	4	50%
MDM	主数据	第 5 章	6	3	50%
ADM	后台管理	第 6 章	7	7	0%
INT	系统集成	第 7 章	12	3	75%
NFR	非功能需求	第 8 章	38	10	74%
ACC	验收与追溯	第 9 章、本附录	11	0	100%
	合计		296	144	51%

需求追溯矩阵（RTM）骨架

完成度 = (需求条数 − 待确认条数) / 需求条数，衡量的是「需求是否说清楚了」，不是开发进度。

V1.1 逐张核看第 4 章 167 张配图后，需求条数由 195 增至 296、待确认由 97 增至 144，合计完成度由 50% 变为 51%。完成度普遍不升反降是预期结果 —— 核图暴露出的多是现状里真实存在、而 V1.0 正文未记的机制与口径冲突，把隐性的未知转成了显式的待确认项。降幅最大的是门店管理（25% → 7%）、财务与对账（29% → 14%）与库存（29% → 18%）；销售（57% → 70%）与延保（50% → 84%）反向上升，因为这两个模块的截图最密（28 张 / 43 张），补出的多是可直接定稿的规则。

仍需单独关注的是：

ADM 后台管理 0% —— 只有菜单结构、无功能级需求，且 REQ-ADM-002（角色化 tab 配置端）是 C1 的前置条件，是优先级最高的空白

STM 门店管理 7% —— 14 条需求里 13 条待确认。V1.1 从现状截图中补出了本地化服务项目价目表、平台渠道与品牌授权的拆分、百望云开票通道等一整套 V1.0 未覆盖的机制，但每一条的归属与管控方式都需业务裁决

MSP 福利兑换 —— 完成度 50%，但它仍是全文唯一没有任何页面材料的模块，完成度反映的是需求是否说清楚，不代表已有设计稿可供开发

D.3 逐条 RTM 样例

以下为 4.1 账号登录的填写样例，其余模块照此格式展开：

需求编号	需求描述	来源痛点	来源材料	优先级	状态	设计稿	验收标准
REQ-LGN-001	支持手机号 + 短信验证码登录	P2	业务需求	P0	已确认	登录页设计稿	9.2 AC-1
REQ-LGN-002	支持账号 + 密码登录	P2	业务需求	P0	已确认	登录页设计稿	9.2 AC-1
REQ-LGN-003	支持微信 / 支付宝第三方登录	P2	设计稿	P2	待确认	登录页设计稿	—
REQ-LGN-004	新用户注册需经审核后开通	P2	设计稿	P1	待确认	登录页设计稿	—
REQ-LGN-009	access token 短期有效、refresh token 轮换续期，失效后跳登录页	—	《后端安全与认证文档》	P0	已确认	—	9.5
REQ-LGN-011	角色（RoleCode）的权威来源是 O2O 后台还是 APP 后台	P2	本文档附录 A.1 的「登录成功结果集」反推	P1	待确认	—	9.3

样例中 REQ-LGN-011 演示了一条由数据来源反推出、业务侧尚未提出的需求如何入表：来源材料写「本文档反推」，并在 10.2 中登记责任人。

结束语

本文档覆盖账号登录、首页与导航、销售、提醒、延保、采购、库存、个人中心、门店管理、财务对账、返利中心、经营业绩、营销与会员、福利兑换等 19 个模块，并把 173 张设计稿与现状截图全部编入对应章节作为需求实证。

本文档不是终稿。 296 条需求中有 144 条处于「待确认」，集中在第 10 章。这些是业务侧尚未给出结论的事项 —— 显式列出来，比用看似完整的文字掩盖过去更有价值。建议下一步：

先关闭 C1 底部导航三版与 REQ-ADM-002 后台 APP 配置 —— 这两条卡住整个信息架构
再补 MSP / MIN / ADM 三个 0% 模块的需求
确认埋点服务的可用性 —— 这是仅剩的跨文档阻塞项，同时决定后台首页看板与线上错误看板能否落地，属采购流程，与需求评审可并行

503 KiB Raw Permalink Blame History Unescape Escape

Continental Retail APP 产品需求文档（PRD）

修订历史

1 引言

1.1 文档目的

1.2 项目背景

1.3 项目目标

1.4 终端用户

1.5 文档适用范围

1.6 术语与缩写定义

1.7 需求编号规则

1.8 文档编写约定

1.8.1 需求描述模板

1.8.2 图表约定

1.8.3 图片来源标注

1.8.4 待确认标记

2 现状痛点分析

2.1 多小程序分散

2.2 账号权限管控

2.3 进销存 & ERP 数据

2.4 支付与营销

2.5 数据经营分析

2.6 售后延保

2.7 现状小程序功能全景

2.7.1 现状导航结构

2.7.2 ROOS 采购小程序

2.7.3 O2O 接单宝小程序

2.7.4 延保门店端小程序

2.8 痛点 → 需求映射

3 利益相关者分析

3.1 终端用户（门店角色）

3.1.1 门店店长（核心管理用户）

3.1.2 门店技工（一线操作用户）

3.2 企业内部干系人

3.3 外部对接系统厂商

4 用户需求

4.0 模块总览

4.1 账号登录

4.1.1 需求描述

4.1.2 业务规则

4.1.3 店长

4.1.4 技工

4.1.5 业务数据列表

4.1.6 验收标准

4.2 APP 首页

4.2.1 需求描述

4.2.2 现状导航与目标导航的差异

4.2.3 店长首页

4.2.4 技工首页

4.2.5 导航收敛与角色化配置

4.2.6 业务规则

4.2.7 业务数据列表

4.2.8 验收标准

4.3 销售

4.3.1 需求描述

4.3.2 接车与车辆识别

4.3.3 检测、开单与施工

4.3.4 核销

4.3.5 线上订单管理

4.3.6 服务单

4.3.7 结算与延保跳转

4.3.8 角色差异

4.3.9 业务规则

4.3.10 验收标准

4.4 提醒

4.4.1 需求描述

4.4.2 设置提醒规则

4.4.3 生成提醒单

4.4.4 跟进提醒单

4.4.5 承接方式

4.4.6 业务规则

4.4.7 验收标准

4.5 延保

4.5.1 保障产品与责任边界

4.5.2 消费者激活与门店建单

4.5.3 保单与延保生命周期管理

4.5.4 预约与理赔运营

4.5.5 售后鉴定与证据采集

4.5.6 工作台、返利与经营数据

4.5.7 培训、操作指引与服务支持

503 KiB

Raw Permalink Blame History