442 lines
50 KiB
Markdown
442 lines
50 KiB
Markdown
# 4.8 我的 / 个人中心
|
||
|
||
> **本文件是【我的 MIN】模块需求的编辑入口。**
|
||
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.8 节已于 2026-08 从本文件回灌（V1.1），
|
||
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**
|
||
|
||
| 项 | 值 |
|
||
| --- | --- |
|
||
| 模块码 | MIN |
|
||
| V1.0 章节 | 4.8 |
|
||
| 描述粒度 | 6 维精简模板 |
|
||
| 需求依据 | 设计稿 1 张 + 三套现状小程序截图反推 |
|
||
| 现状承载系统 | ROOS + O2O + 延保 |
|
||
| 需求条数 | 14（待确认 13，完成度 7%） |
|
||
| 配图 | 16 张（设计稿 1 / 现状-ROOS 7 / 现状-O2O 5 / 现状-延保 3） |
|
||
|
||
> **本节的来历：V1.0 的 4.8 没有「业务规则」小节。**
|
||
> 六个 `REQ-MIN-001` ~ `REQ-MIN-006` 编号全部只以 `TODO(...)` 标记的形式散落在正文与合并规则表中，
|
||
> **没有任何一条成文规则**，这正是附录 D.2 中 MIN 完成度为 0% 的直接原因（14 个模块里唯一的 0%）。
|
||
> V1.1 补入 [4.8.6 业务规则](#486-业务规则)，V1.0 的「4.8.6 验收标准」顺延为 [4.8.7](#487-验收标准)。
|
||
|
||
三套现状小程序各有一个「我的」，本节将其合并为 App 的统一个人中心。
|
||
|
||
**业务目标** —— 提供统一的账号、门店、资产（额度/返利/优惠券/积分）与设置入口，取代三套小程序各自的「我的」
|
||
|
||
**入口** —— 底部导航「我的」tab
|
||
|
||
**页面内容** —— 用户信息卡（头像/姓名/门店/角色标签）+ 资产卡（积分、优惠券）+ 功能列表 + 退出登录
|
||
|
||
**主流程** —— 进入个人中心 → 查看资产 / 进入子功能 → 返回
|
||
|
||
**权限规则** —— 全角色可见；资产类（额度、返利、对账单）建议限店长 `TODO(REQ-MIN-002)`
|
||
|
||
**数据来源** —— App Backend（账号、门店）、ROOS（账户、优惠券、地址、收藏、支付优先级）、O2O（设置、手机号）、延保后台（姓名、门店）
|
||
|
||
---
|
||
|
||
## 4.8.1 目标形态
|
||
|
||
|
||
|
||
**页面内容** —— App 个人中心的目标形态：顶部橙色用户卡（头像、账号名、门店名、金黑配色的「⭐ 店长」角色标签），下方并排两张资产卡（积分 460 / 优惠券 56），再下是 6 项功能列表，底部为描边样式的「退出登录」。
|
||
|
||
**关键交互** —— ①点击右上角设置图标 → 进入设置页（**设计稿未定义该页内容**）；②点击「积分 460」「优惠券 56」→ 资产二级页（**卡片上未见 `>` 或箭头，是否可下钻本图无法确认**）；③点击功能列表任一项（服务热线 / 经销商客服 / 地址管理 / 我的收藏 / 经营范围 / 换绑手机）→ 进入对应二级页；④点击「退出登录」→ 二次确认弹窗。
|
||
|
||
**可用角色** —— 店长 ✅ 全量；技工 ✅ 可见页面，但资产卡与部分功能项受限（[附-2](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）。角色标签由后台下发，技工不显示店长专属资产项。
|
||
|
||
**需求关联** —— `TODO(REQ-MIN-001)` 个人中心保留哪 6 项、[REQ-MIN-016](#486-业务规则) 关于 / 版本号入口、[REQ-MIN-020](#486-业务规则) 头像首版只读
|
||
|
||
> 设计稿的功能列表**只有 6 项**，而三套现状小程序的「我的」合计有 20 余项。哪些进个人中心、哪些下沉到各业务模块 —— `TODO(REQ-MIN-001)`。本节先按域完整记录现状，作为取舍的输入。
|
||
|
||
> **设计稿与其它章节的三处冲突，须一并解决：**
|
||
> 1. 资产卡只有**积分**与**优惠券**两项，**额度与返利没有位置**，而 4.8.5 合并规则表写的是「我的账户（额度/返利/券/积分）→ 个人中心资产卡 + 二级页」，附录 B 的权限行也是四项一起管控 —— 四项资产如何在两张卡里落位未定，见 [REQ-MIN-009](#486-业务规则)。
|
||
> 2. 优惠券在设计稿上是 **56**（像张数），而 ROOS 现状展示的是**优惠券总金额 ¥0.00**（金额）—— 口径不同，见 [REQ-MIN-009](#486-业务规则)。
|
||
> 3. 设计稿把「退出登录」放在个人中心主页面，O2O 现状放在二级「设置」页内 —— 本 PRD 以设计稿为准（见 4.8.5 合并规则表）。
|
||
> 另：设计稿底部导航为 **首页 / 入库 / 采购 / 延保 / 我的**，与 [4.2 APP 首页与导航](./02-HOM-APP首页与导航.md#42-app-首页)的导航收敛方案须保持一致。
|
||
|
||
## 4.8.2 ROOS「我的」（采购域资产）
|
||
|
||
|
||
|
||
**页面内容** —— ROOS 采购小程序的「我的」：橙色头部为头像、门店主编码、门店名与账号，其下依次是「本月进度」考核卡、「我的订单」四状态卡、四宫格快捷入口（账户 / 优惠券 / 对账单 / 条码库存）与 收货地址 / 员工管理 / 我的收藏 三行列表。
|
||
|
||
**关键交互** —— ①点击「本月进度 ⓘ」的问号 → 指标口径说明；②点击「查看更多 >」→ 门店考核明细（现状指标为 签约量(单马牌) 100 / 马牌订货量 0 / 扫码入库 0 / O2O售出 –）；③点击「全部订单 >」或待支付 / 待发货 / 待收货 / 售后退款任一图标 → 采购订单列表并定位到对应状态页签；④点击账户 / 优惠券 / 对账单 / 条码库存 → 四个二级页；⑤点击收货地址 / 员工管理 / 我的收藏 → 对应二级页。
|
||
|
||
**可用角色** —— 店长 ✅ 全量；技工 🔸 资产类（账户 / 对账单）与员工管理不可见 `TODO(REQ-MIN-002)`。本页底部导航为 4 tab（首页 / 商品 / 购物车 / 我的），是采购域独立小程序的形态，与 App 5 tab 不同。
|
||
|
||
**需求关联** —— [REQ-MIN-009](#486-业务规则) 我的账户资产结构、[REQ-MIN-017](#486-业务规则) 本月进度与员工管理的归属
|
||
|
||
> **本页有两项能力不在 4.8.5 合并规则表的 16 行里，也不在设计稿里 —— 属漏归**：
|
||
> - **「本月进度」考核卡** —— 与 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)、[4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)是同一套门店考核体系（签约量 / 订货量 / 扫码入库 / O2O 售出）；
|
||
> - **「员工管理」** —— 与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)的「人员管理与授权」是同一件事。
|
||
>
|
||
> 处理办法见 [REQ-MIN-017](#486-业务规则)，两行已补入 4.8.5 合并规则表。
|
||
|
||
|
||
|
||
**页面内容** —— 点 ROOS「我的」资产入口后弹出的**微信系统级弹窗**「即将打开"账户管理｜德国马牌轮胎"小程序」，遮罩下露出的功能列表补齐了上一张未拍到的项（支付优先级设置、服务热线、经销商客服、**关于 V2.66.96**、退出登录）。
|
||
|
||
**关键交互** —— ①点击「允许」→ 跳出 ROOS，打开独立的「账户管理」小程序；②点击「取消」→ 留在当前页。这是微信原生弹窗，样式与文案由平台控制，小程序无法定制。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ 取决于资产类权限结论 `TODO(REQ-MIN-002)`。
|
||
|
||
**需求关联** —— [REQ-MIN-018](#486-业务规则) 「账户管理」小程序的接入范围、[REQ-MIN-016](#486-业务规则) 关于 / 版本号入口
|
||
|
||
> **两处关键发现：**
|
||
> 1. **「账户管理｜德国马牌轮胎」是本 PRD 系统清单之外的第 8 个小程序** —— 第 5 章列出的现状系统为 ROOS / O2O / 延保 / 马上下单 / RMS / MSIP / F6，不含它。4.8.5 合并规则表写「跳转其它小程序 → **取消**」，意味着 App 必须自行承接账户管理的全部能力，或接入该小程序的后端接口 —— 这是一处**尚未评估的接入范围**，见 [REQ-MIN-018](#486-业务规则)。
|
||
> 2. **「关于 V2.66.96」入口在设计稿中完全缺失** —— App 作为独立安装包，版本号、用户协议、隐私政策、检查更新是发版合规的必备项，见 [REQ-MIN-016](#486-业务规则)。
|
||
|
||
**我的账户**：点击「账户」按钮进入「我的账户」。我的账户分为**信用额度、未使用返利、优惠券总金额、积分余额**。信用额度含可用余额、待还金额、信用额度；未使用返利按品牌明细展示，含返利总额。
|
||
|
||
|
||
|
||
**页面内容** —— 资产总览页：顶部橙色卡为门店名、所属经销商与可用余额 / 信用额度 / 待还金额，下方白卡按未使用返利、优惠券总金额、积分余额三段罗列并各自拆分明细，**本页为全零数据**故金额格式与明细行样式无法从本图确认。
|
||
|
||
**关键交互** —— ①点击「未使用返利 ¥0.00 >」→ 返利明细；②点击「优惠券总金额 ¥0.00 >」→ 优惠券列表（即下一张图）；③点击「积分余额 0 >」→ 积分明细与兑换；④四类返利与两类积分本身**未见 `>`，是否可逐类下钻本图无法确认**。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-MIN-002)`（资产与资金相关，倾向不开放）。
|
||
|
||
**需求关联** —— [REQ-MIN-009](#486-业务规则) 资产四层结构与两套返利体系
|
||
|
||
> **本页揭示的三点，是 4.8 与 4.11 之间最容易做错的地方：**
|
||
> 1. **信用额度未设置时显示「——」而非 ¥0.00** —— 空值与零值在授信语境下含义完全不同（未授信 vs 授信额度为零），App 必须沿用这一区分。
|
||
> 2. **未使用返利按「品牌–区域」组织**，出现了 **Continental–上海 / Viking–上海 / 卡迪睿德 / 其他业务** 四类。其中**「卡迪睿德」是 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)从未出现过的第三个品牌**（4.11 只涉及马牌与 Viking）。
|
||
> 3. **返利有两套互不相通的体系** —— 本页是 **ROOS 采购返利**（按品牌×区域累计，用于抵扣货款，[4.6 采购](./06-PUR-采购.md#46-采购)结算页的「返利抵扣 请选择」取的就是它）；而 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)描述的是 **O2O 营销返利**（消费者补贴、安装费用、抽奖红包）。**4.11 只覆盖后者。** 个人中心若只展示一个「返利」数字，必然把两套账混在一起。
|
||
|
||
**优惠券**：状态 Tab 为**待激活、待生效、待使用、已使用、已失效**；券的种类分为**马牌券、经销商券**。
|
||
|
||
|
||
|
||
**页面内容** —— 优惠券列表页：顶部五个状态页签（待激活 / 待生效 / **待使用**（当前选中）/ 已使用 / 已失效）与「马牌券 | 经销商券」二级分段控件，**本截图为空态**故券卡的面额、门槛、有效期、适用范围无法从本图确认。
|
||
|
||
**关键交互** —— ①切换五个状态页签 → 列表按券状态过滤；②切换「马牌券 / 经销商券」→ 在当前状态下再按券种过滤（两级筛选叠加）；③点击券卡 → 券详情或去使用（**空态下无法确认**）；④「待激活」状态**隐含一个激活动作**，但激活入口与规则本图无法确认。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-MIN-002)`。
|
||
|
||
**需求关联** —— [REQ-MIN-010](#486-业务规则) 优惠券五状态与两种券种
|
||
|
||
> 「待激活」与「待生效」是两个不同状态：前者需用户**主动激活**，后者是**已激活但未到生效时间**。PRD 现状未定义激活动作的触发方式与规则，见 [REQ-MIN-010](#486-业务规则)。
|
||
|
||
**支付优先级设置**：~~设置是否优先使用扣账支付方式~~ —— **V1.1 更正**：现状实际为单一开关「**是否优先使用微信支付**」，取值「是 / 否」，与「扣账支付方式」无关。
|
||
|
||
|
||
|
||
**页面内容** —— 极简单行设置页「是否优先使用微信支付」（当前值「是」），点击后从底部升起微信原生单列滚轮，选项为「否 / 是」。
|
||
|
||
**关键交互** —— ①点击设置行 → 升起滚轮选择器；②滚动选择「是 / 否」→ 点「确认」保存并回填该行，点「取消」不变更；③本页**只有这一项设置**，无其它支付方式排序能力。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✗（影响资金，见附录 B）。
|
||
|
||
**需求关联** —— `TODO(REQ-MIN-005)` 放在个人中心还是采购结算、[REQ-MIN-011](#486-业务规则) 设置语义与生效范围
|
||
|
||
> **V1.0 的 4.8.2 原文「设置是否优先使用扣账支付方式」与截图不符，已就地更正。** 该表述会误导设计与开发把它做成「扣账 / 微信 / 余额」的多方式排序，实际只是一个二值开关。
|
||
|
||
**收货地址**：地址列表含联系人、手机号、详细地址、默认标记。页面提示「扫码入库时，店铺位置以地图定位为准」。
|
||
|
||
|
||
|
||
**页面内容** —— 收货地址列表，本图只有一条（联系人「测试」、详细地址为重复拼接的脏数据、带 ✅「默认地址」标记），列表下方有一行提示「扫码入库时，店铺位置以地图定位为准」与橙色「查看定位 >」。
|
||
|
||
**关键交互** —— ①点击「查看定位 >」→ 打开门店地图定位（V1.0 只引用了提示文案，**未提及这个可点入口**）；②点击地址条目 → 编辑（**本图无法确认是否可点**）；③**本页未见「新增地址」按钮**，新增入口位置无法从本图确认；④只有一条地址，A.9 所称「按使用时间 / 默认状态排序」无法验证。
|
||
|
||
**可用角色** —— 店长 ✅；技工 🔸 只读（见附录 B）。
|
||
|
||
**需求关联** —— [REQ-MIN-014](#486-业务规则) 地址管理能力与权威数据源
|
||
|
||
> 地址文本「**上海市上海市浦东新区上海市浦东新区**南桥路1200号」是典型的**省市区与详细地址重复拼接**的脏数据 —— 结构化字段（省/市/区）与自由文本（详细地址）在录入时没有做互斥校验。App 侧须做规范化，见 [REQ-MIN-014](#486-业务规则)。
|
||
|
||
**我的收藏**：进入「商品收藏列表」。
|
||
|
||
|
||
|
||
**页面内容** —— 商品收藏列表（顶部标注「共 1 件商品」），商品卡含左侧**占位图（无实际商品图）**、规格名与红色单价，右侧竖排橙色实心 ❤ 与「加入购物车」两个图标。
|
||
|
||
**关键交互** —— ①点击橙色实心 ❤ → 取消收藏，商品从列表移除；②点击「加入购物车」→ 直接加购，与 [4.6 采购](./06-PUR-采购.md#46-采购)的购物车联动；③点击商品卡 → 商品详情（**本图无法确认**）。
|
||
|
||
**可用角色** —— 店长 ✅；技工 🔸 只读（见附录 B）—— 「只读」意味着技工**不可取消收藏、不可加购**，需在实现时明确。
|
||
|
||
**需求关联** —— [REQ-MIN-015](#486-业务规则) 收藏列表的价格可见性与操作权限
|
||
|
||
> **收藏卡直接展示采购价 ¥1688.00/条，与附录 B 存在冲突**：附录 B 给技工的「收货地址 / 我的收藏」是 🔸 只读（即**可见**），而「查看小程序结算价」对技工是 ❓ `TODO(REQ-INV-001)`。若技工能打开收藏列表，就等于绕过价格管控看到了采购价。见 [REQ-MIN-015](#486-业务规则)。
|
||
> 另：商品图为占位图，是 ROOS 商品主数据的图片缺失，属现状数据质量问题，不新增需求编号。
|
||
|
||
## 4.8.3 O2O「设置」（账号与门店）
|
||
|
||
|
||
|
||
**页面内容** —— O2O（接单宝）的「设置」页，内容极简：头像 + 昵称 + 手机号一行（右侧一枚橙色小标签**文字过小、本图无法辨认**）、门店名 + 灰色「切换店铺」一行，中部大片留白，底部是灰色的「退出登录」。
|
||
|
||
**关键交互** —— ①点击「切换店铺」→ 门店选择列表（见本节后面的图）；②点击「退出登录」→ 确认弹窗（见下一张图）；③**本页无「修改手机号」入口**，而 O2O 确实存在修改手机号页 —— 其入口位置本图无法确认。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅（个人信息 / 登出对全角色开放，见附录 B）。
|
||
|
||
**需求关联** —— [REQ-MIN-007](#486-业务规则) 门店绑定关系与切换门店、[REQ-MIN-013](#486-业务规则) 姓名的可编辑性与回写
|
||
|
||
> 门店名「智慧园杀虫轮胎店」与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)截图中的「豌豆的小店」不同，但**手机号 13419691597 相同** —— 同一账号绑定多家门店，这一点在下面的「选择店铺」图中得到印证。
|
||
> 另：三套现状系统对同一个人的称呼各不相同 —— O2O 显示昵称「宛玉」，ROOS 显示手机号，延保显示操作人姓名「史涵」。这正是 `TODO(REQ-MIN-003)` 要解决的问题。
|
||
|
||
|
||
|
||
**页面内容** —— 居中确认弹窗，标题「确认登出」+「取消 / 确定」两个按钮，**无任何正文说明**。
|
||
|
||
**关键交互** —— ①点击「确定」→ 清除登录态并返回登录页；②点击「取消」→ 关闭弹窗留在设置页。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅。
|
||
|
||
**需求关联** —— [REQ-LGN-008](./01-LGN-账号登录.md#412-业务规则) 退出登录需二次确认、[REQ-MIN-019](#486-业务规则) 登出的清除范围与多设备会话
|
||
|
||
> 现状弹窗只有「确认登出」四个字，不说明后果。App 的登出会同时清除本地 Token、门店上下文与缓存业务数据（见 [4.8.7 验收标准](#487-验收标准)第 2 条），弹窗文案须把这一点告知用户，见 [REQ-MIN-019](#486-业务规则)。
|
||
|
||
|
||
|
||
**页面内容** —— 换绑手机号表单，三行为「当前手机号」（`134 1969 1597`，**分组展示、未脱敏**）、新手机号与短信验证码，下方提示「验证码将发送至**原手机号**」，底部「确认修改」为灰色禁用态。
|
||
|
||
**关键交互** —— ①点击「获取验证码」→ 向**原**手机号发送短信验证码并开始倒计时；②三项填写完整后「确认修改」由灰转亮 → 提交换绑；③新手机号**不做任何验证**即可绑定。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅（换绑手机对全角色开放，见附录 B）。
|
||
|
||
**需求关联** —— [REQ-MIN-012](#486-业务规则) 换绑手机的双向验证与脱敏
|
||
|
||
> **这是现状里最需要在 App 上改掉的一处**：验证码发往**原**号只能证明「你是当前账号的持有人」，无法证明「新号归你所有」。填错一位数字就会把账号绑到陌生号码上，且原号已失去登录能力 —— 属不可自助恢复的故障。App 须改为**双向验证**，见 [REQ-MIN-012](#486-业务规则)。
|
||
|
||
|
||
|
||
**页面内容** —— 「选择店铺」列表页，每行为门店名 + 橙色「进入」按钮（当前门店改显橙色 ✅ 标记），本图可见 13 家门店且列表可继续下滑，即**同一账号绑定了 13 家以上门店**。
|
||
|
||
**关键交互** —— ①点击任一行的「进入」→ 切换到该门店并返回，全站数据随之切换；②当前门店不可重复进入；③列表**无搜索框、无分组、无字母索引**，门店多时只能逐屏翻找。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅（能进哪些门店由后台绑定关系决定，不由角色决定）。
|
||
|
||
**需求关联** —— [REQ-MIN-007](#486-业务规则) 门店绑定关系与切换门店、[REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文
|
||
|
||
> **这张图确立了个人中心最关键的一条结构性事实：门店与账号是多对多关系，且规模不小（本例 13+ 家）。** 4.8.5 合并规则表把「切换门店」收敛为 App 全局门店上下文，但**全局门店列表取自哪套系统的绑定关系、切店时清不清购物车、已打开的页面如何处理**均未定义，见 [REQ-MIN-007](#486-业务规则)。
|
||
> 列表中「曲奇测试门店2号店」「马牌品牌商导入MS（预发1）」「上海市尚浦中心马牌培训店1(测试勿拍)」「野蜂蜜很甜」「吃瓜专门店」「小脑斧汽车修理门店」等大量条目为**测试数据**，正式环境的门店名规范与数量分布无法从本图推断。
|
||
|
||
|
||
|
||
**页面内容** —— 从 O2O 首页唤起的底部动作面板「小程序在线客服」，列出 **6 条按渠道区分的电话**（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），底部为「取消」。
|
||
|
||
**关键交互** —— ①点击任一行 → 唤起系统拨号盘拨打该号码；②点击「取消」→ 关闭面板；③**无在线聊天能力** —— 名为「在线客服」，实为电话清单。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅（客服入口不设权限）。
|
||
|
||
**需求关联** —— `TODO(REQ-MIN-004)` 三个客服入口是否合并、[REQ-MIN-008](#486-业务规则) 服务热线按渠道分列的数据模型
|
||
|
||
> **两点须处理：**
|
||
> 1. **客服不是一个号码，而是按渠道分的 6 条线**。V1.0 的 4.8 只列了「服务热线 / 经销商客服 / O2O·延保企微客服」三个入口，附录 A.9 的「服务热线列表」也只有「号码 / 服务时间 / 范围 / 类型」四个字段 —— **缺「渠道」维度**，见 [REQ-MIN-008](#486-业务规则)。
|
||
> 2. **高德（159\*\*\*\*1674）与美团（185\*\*\*\*1756）用的是个人手机号**，零跑是座机分机（023-62905394）。个人号码作为对外官方热线，人员变动即失联，属治理风险。
|
||
>
|
||
> 本图的渠道口径（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑）与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)的平台渠道（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑）**又不相同** —— 这是全仓库第七套渠道枚举，见 [附-5](../Continental-Retail-APP-PRD.md#1028-我的min)。
|
||
|
||
## 4.8.4 延保「我的」
|
||
|
||
|
||
|
||
**页面内容** —— 延保小程序的「我的」，**深色主题**（与 ROOS / O2O 的浅色主题完全不同）：上部是带编辑铅笔的大号橙色头像，下方三行为操作人姓名、切换店铺与手机号（右侧灰字「已绑定」），底部是 5 tab 导航。
|
||
|
||
**关键交互** —— ①点击头像右下的铅笔钮 → 更换头像（**本图无法确认是否真的可上传**）；②点击「操作人姓名」→ 姓名编辑弹窗（见下一张图）；③点击「切换店铺」→ 门店选择器（见本节最后一张图）；④「手机号码」行**无 `>`，不可点** —— 延保侧不提供换绑手机；⑤底部中央的橙色指南针钮功能**本图无法确认**。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅（个人信息类，见附录 B）。
|
||
|
||
**需求关联** —— [REQ-MIN-013](#486-业务规则) 姓名的可编辑性与回写、[REQ-MIN-020](#486-业务规则) 头像首版只读、`TODO(REQ-MIN-003)` 姓名的权威来源与回写范围
|
||
|
||
> **姓名在延保侧是可自由编辑的文本**（「史涵」），而 ROOS 显示的是手机号、O2O 显示的是昵称「宛玉」。三套各存一份、互不同步 —— 这就是 `TODO(REQ-MIN-003)` 的由来。
|
||
> 本页账号 13871477616 / 上海东兴店与 ROOS 截图一致（同一测试账号跨两系统），与 O2O 截图的 13419691597 / 智慧园杀虫轮胎店不是同一个账号。
|
||
|
||
|
||
|
||
**页面内容** —— 居中深色弹窗「**登录账户**输入您的姓名」（右上角「✕ 关闭」胶囊），表单只有一个「姓名」下划线输入框与底部橙色「确认」。
|
||
|
||
**关键交互** —— ①在输入框键入姓名 → 点「确认」保存并回填到「操作人姓名」行；②点右上「✕ 关闭」→ 放弃修改；③**输入框为空，未预填当前姓名「史涵」**；④无必填标记、无长度或字符校验提示。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅。
|
||
|
||
**需求关联** —— [REQ-MIN-013](#486-业务规则) 姓名的可编辑性与回写
|
||
|
||
> 两处须在 App 上改掉：**编辑弹窗不预填当前值**（用户改一个字也得整个重打），以及**标题文案「登录账户输入您的姓名」语义不通**。
|
||
|
||
|
||
|
||
**页面内容** —— 深色「我的」页底部升起的**微信原生单列滚轮选择器**（浅色，与页面深色主题割裂），滚轮中只有一个选项「上海东兴店」，底部为灰底「取消」与**绿色**实心「确定」。
|
||
|
||
**关键交互** —— ①滚动滚轮选择门店 → 点「确定」切换；②点「取消」不变更；③本账号在延保侧**只绑定 1 家门店**，故滚轮无实际可选项。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ✅。
|
||
|
||
**需求关联** —— [REQ-MIN-007](#486-业务规则) 门店绑定关系与切换门店
|
||
|
||
> **同一件事，三套系统三种交互**：O2O 是整页列表 + 「进入」按钮，延保是底部滚轮选择器，ROOS 的「我的」页则**没有切换店铺入口**。App 统一为一种交互即可，但更要紧的是背后的数据 —— **门店绑定关系分别维护在各系统里**（本例延保侧 1 家，O2O 侧另一账号 13+ 家），统一后取哪套为权威须定，见 [REQ-MIN-007](#486-业务规则)。
|
||
> 另：确定按钮为**绿色**（微信原生 picker 默认色），与延保小程序的橙色主色不一致 —— App 用原生组件时须统一主题色。
|
||
|
||
## 4.8.5 合并规则
|
||
|
||
| 现状能力 | 来源 | App 归属 |
|
||
| --- | --- | --- |
|
||
| 头像 / 姓名 / 角色 | 三套各有 | 个人中心用户卡（姓名以 App Backend 为准，回写各系统）`TODO(REQ-MIN-003)`；头像首版只读（[REQ-MIN-020](#486-业务规则)） |
|
||
| 切换门店 | 三套各有 | **收敛为 App 全局门店上下文**（[REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则)），个人中心不再单独提供；绑定关系权威来源见 [REQ-MIN-007](#486-业务规则) |
|
||
| 修改手机号 / 换绑手机 | O2O + 设计稿 | 个人中心，须双向验证（[REQ-MIN-012](#486-业务规则)） |
|
||
| 退出登录 | O2O + 设计稿 | 个人中心，需二次确认（[REQ-LGN-008](./01-LGN-账号登录.md#412-业务规则)） |
|
||
| 在线客服 / 服务热线 / 经销商客服 | O2O + 设计稿 | 个人中心（三个客服入口是否合并 —— `TODO(REQ-MIN-004)`）；须支持按渠道分列（[REQ-MIN-008](#486-业务规则)） |
|
||
| 我的账户（额度/返利/券/积分） | ROOS | 个人中心资产卡 + 二级页；**采购返利与营销返利须分列**（[REQ-MIN-009](#486-业务规则)）；营销返利明细见 [4.11](./11-RBT-返利中心.md#411-返利中心) |
|
||
| 优惠券 | ROOS + O2O | 个人中心，保留五状态 + 两种券种（[REQ-MIN-010](#486-业务规则)）；营销侧发放见 [4.13](./13-MKT-营销与会员.md#413-营销与会员) |
|
||
| 收货地址 / 地址管理 | ROOS + 设计稿 | 个人中心（[REQ-MIN-014](#486-业务规则)） |
|
||
| 我的收藏 | ROOS + 设计稿 | 个人中心（[REQ-MIN-015](#486-业务规则)） |
|
||
| 支付优先级设置 | ROOS | 个人中心（或下沉到[采购结算](./06-PUR-采购.md#463-购物车与结算)）`TODO(REQ-MIN-005)`；实为「是否优先使用微信支付」（[REQ-MIN-011](#486-业务规则)） |
|
||
| 经营范围 | O2O + 设计稿 | 设计稿放在个人中心，现状在店铺管理下 —— 归属待定 `TODO(REQ-MIN-006)`，现状见 [4.9](./09-STM-门店管理.md#49-门店管理) |
|
||
| 条码库存 | ROOS | 下沉到 [4.7 库存](./07-INV-库存.md#47-库存) |
|
||
| 对账单 | ROOS | 下沉到 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账) |
|
||
| 经营业绩 | ROOS | 下沉到 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表) |
|
||
| 跳转其它小程序 | ROOS | **取消**；「账户管理」小程序的能力承接范围见 [REQ-MIN-018](#486-业务规则) |
|
||
| **本月进度（门店考核卡）** | ROOS | **V1.1 补入** —— 下沉到 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)（[REQ-MIN-017](#486-业务规则)） |
|
||
| **员工管理** | ROOS | **V1.1 补入** —— 下沉到 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)的人员管理与授权（[REQ-MIN-017](#486-业务规则)） |
|
||
| **我的订单（四状态入口）** | ROOS | **V1.1 补入** —— 下沉到 [4.6 采购](./06-PUR-采购.md#46-采购)的订单列表（[REQ-MIN-017](#486-业务规则)） |
|
||
| **关于 / 版本号** | ROOS | **V1.1 补入** —— 个人中心新增，含版本号、用户协议、隐私政策、检查更新（[REQ-MIN-016](#486-业务规则)） |
|
||
|
||
三套「我的」的合并归属（原 16 行，V1.1 补入 4 行，共 19 行）
|
||
|
||
## 4.8.6 业务规则
|
||
|
||
> **本节为 V1.1 新增。** V1.0 的 4.8 原本没有业务规则小节，`REQ-MIN-001` ~ `REQ-MIN-006` 六个编号只以 `TODO(...)` 形式散落在正文中；下列 `REQ-MIN-007` ~ `REQ-MIN-020` 为 V1.1 逐图核对现状后补写。
|
||
|
||
1. **REQ-MIN-007 门店绑定关系与切换门店** —— App 可切换的门店列表**以 App Backend 的「人员–门店」绑定关系为唯一权威**，由后台聚合三套现状系统的绑定并按门店主编码去重；列表须支持按门店名 / 编码搜索，当前门店置顶并以选中态标识（现状 O2O 单账号已绑定 13 家以上门店，无搜索）。切换门店后须刷新全局门店上下文并重载所有业务数据。**切店时购物车、未提交表单、已打开的 H5 页面如何处理未定** —— `TODO(REQ-MIN-007)`。
|
||
2. **REQ-MIN-008 服务热线按渠道分列** —— 服务热线数据集须支持「渠道 → 号码」多条记录（现状 6 条：小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），由后台维护、App 动态渲染，**不得在客户端硬编码**，号码变更无需发版。点击行为统一为唤起系统拨号盘。**现状高德、美团用的是个人手机号，是否替换为总机分机** —— `TODO(REQ-MIN-008)`。
|
||
3. **REQ-MIN-009 资产结构与两套返利体系** —— 「我的账户」保留四层结构：授信（可用余额 / 信用额度 / 待还金额）、未使用返利、优惠券、积分。其中：**信用额度未授信时显示「——」，不得显示 ¥0.00**（空值与零值语义不同）；**采购返利（按「品牌–区域」累计，用于抵扣货款，见 [4.6 采购](./06-PUR-采购.md#46-采购)）与营销返利（消费者补贴 / 安装费用 / 抽奖红包，见 [4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)）必须分列展示，不得合并为一个「返利」数字**；积分区分「通用兑换 / 运营物料」两类。**四项资产在设计稿两张资产卡里如何落位、优惠券展示张数还是总金额、采购返利品牌枚举（现状含 Continental / Viking / 卡迪睿德 / 其他业务）是否完整** —— `TODO(REQ-MIN-009)`。
|
||
4. **REQ-MIN-010 优惠券状态与券种** —— App 优惠券列表保留五状态页签（待激活 / 待生效 / 待使用 / 已使用 / 已失效）与「马牌券 / 经销商券」二级券种筛选，两级筛选可叠加。**「待激活」状态的激活入口、激活条件与激活后是否立即可用未定** —— `TODO(REQ-MIN-010)`。
|
||
5. **REQ-MIN-011 支付优先级设置的语义** —— 该设置的现状语义是单一二值开关「**是否优先使用微信支付**」，**不是**V1.0 原文所写的「是否优先使用扣账支付方式」，不得实现为多支付方式排序。**该设置是账号级还是门店级、变更后对已在购物车中的商品是否即时生效未定** —— `TODO(REQ-MIN-011)`。
|
||
6. **REQ-MIN-012 换绑手机的双向验证与脱敏** —— App 换绑手机须**同时验证原号与新号**（原号验证码证明账号归属，新号验证码证明新号可用），不得沿用现状「验证码只发原号」的单向流程；页面展示的当前手机号须脱敏为 `138****7616`；提交按钮在必填项补齐前保持禁用态。
|
||
7. **REQ-MIN-013 姓名的可编辑性与校验** —— 姓名编辑弹窗**必须预填当前姓名**；须做长度（2–20 字符）与字符集校验，禁止纯空白；保存成功后立即回填用户卡。**权威来源与回写到哪几套系统** —— 见 `TODO(REQ-MIN-003)`。
|
||
8. **REQ-MIN-014 地址管理能力与数据规范** —— 地址管理须提供新增 / 编辑 / 删除 / 设为默认四项能力（现状页面未见新增入口）；省 / 市 / 区为结构化字段，详细地址不得重复拼接省市区（现状存在「上海市上海市浦东新区上海市浦东新区南桥路1200号」这类脏数据），提交时须校验并在展示时规范化；保留「查看定位」入口，与 [4.7 库存](./07-INV-库存.md#47-库存)扫码入库的门店定位校验同源。**收货地址的权威数据源（是否来自马上下单接口）** —— `TODO(REQ-MIN-014)`。
|
||
9. **REQ-MIN-015 收藏列表的价格与操作权限** —— 收藏列表的价格显示**须遵从与商品列表一致的价格可见性策略**（见 [4.7 库存](./07-INV-库存.md#47-库存)的 `TODO(REQ-INV-001)`），不得成为绕过价格管控的旁路；附录 B 中技工对「我的收藏」的 🔸 只读，明确为**可查看、不可取消收藏、不可加入购物车**。
|
||
10. **REQ-MIN-016 关于 / 版本号入口** —— 个人中心须提供「关于」入口，至少包含：App 版本号与构建号、用户协议、隐私政策、检查更新（对接 OTA 分发）、备案信息。该入口在现状 ROOS 中存在（「关于 V2.66.96」），但**设计稿完全缺失**，属发版合规必备项。
|
||
11. **REQ-MIN-017 下沉能力不在个人中心重复提供** —— 「本月进度」考核卡下沉到 [4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)、「员工管理」下沉到 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)、「我的订单」下沉到 [4.6 采购](./06-PUR-采购.md#46-采购)；个人中心不再重复提供入口，避免同一能力两处维护。
|
||
12. **REQ-MIN-018 「账户管理」小程序的能力承接** —— 现状 ROOS 通过微信系统弹窗跳转「账户管理｜德国马牌轮胎」小程序，该小程序**不在本 PRD 的现状系统清单内**。按 4.8.5「跳转其它小程序 → 取消」的原则，App 须自行承接其能力。**承接范围（是否只需授信 / 返利 / 券 / 积分的查询，还是包含还款、开票等写操作）与接入方式（直连其后端 / 由 App Backend 代理 / 内嵌 H5）未定** —— `TODO(REQ-MIN-018)`。
|
||
13. **REQ-MIN-019 登出的清除范围与多设备会话** —— 登出二次确认弹窗须说明后果（将清除本地登录态、门店上下文与缓存业务数据），不得像现状那样只有「确认登出」四字；登出后本地 Token、门店上下文、缓存业务数据全部清除。**多设备可同时登录、单设备登出不影响其它设备**（附录 A.9 第 5 条），与账号共用治理诉求的张力见 `TODO(REQ-LGN-009)`。
|
||
14. **REQ-MIN-020 头像首版只读** —— 首版头像**不提供上传**，统一使用系统默认头像 + 角色底色（避免引入图片审核、存储与合规成本）；现状三套小程序中虽有编辑入口（延保），但全部截图均为默认头像，无实际使用。如业务需要自定义头像，另行提需求。
|
||
|
||
## 4.8.7 验收标准
|
||
|
||
1. 个人中心显示的门店与全局门店上下文一致，切店后资产数据同步刷新；
|
||
2. 退出登录后本地 Token、门店上下文、缓存业务数据全部清除（见《App 门店上下文与会话管理文档》）；
|
||
3. 角色标签与后台下发的角色一致，技工不显示店长专属资产项；
|
||
4. 门店切换列表支持按门店名 / 编码搜索，当前门店置顶并高亮；绑定 20 家门店的账号可在 3 秒内定位到目标门店（[REQ-MIN-007](#486-业务规则)）；
|
||
5. 「我的账户」中采购返利与营销返利分列展示，两个数字来源不同接口且互不相加；信用额度未授信时显示「——」（[REQ-MIN-009](#486-业务规则)）；
|
||
6. 换绑手机须原号与新号各验证一次，任一验证失败即不落库；页面展示的手机号已脱敏（[REQ-MIN-012](#486-业务规则)）；
|
||
7. 姓名编辑弹窗打开时输入框已预填当前姓名；提交空白或超长姓名被拦截并给出提示（[REQ-MIN-013](#486-业务规则)）；
|
||
8. 新增地址时详细地址中重复填写省市区会被校验拦截；地址列表按默认状态与使用时间排序（[REQ-MIN-014](#486-业务规则)）；
|
||
9. 服务热线列表从后台接口动态获取，后台新增一条渠道热线后 App 无需发版即可展示（[REQ-MIN-008](#486-业务规则)）；
|
||
10. 「关于」页展示的版本号与安装包版本一致，用户协议与隐私政策可正常打开（[REQ-MIN-016](#486-业务规则)）；
|
||
11. 技工登录后个人中心不出现「本月进度」「员工管理」「我的订单」等已下沉入口，且资产卡按 `TODO(REQ-MIN-002)` 的结论展示或隐藏。
|
||
|
||
---
|
||
|
||
## 附：本模块归拢信息（来自主文件其它章节）
|
||
|
||
### 附-1 业务数据字典（主文件附录 A.9）
|
||
|
||
| # | 数据集 | 来源 | 安全 | 备注 |
|
||
| --- | --- | --- | --- | --- |
|
||
| 1 | 收货地址列表（按使用时间/默认状态排序） | App Backend | HTTPS | 数据来源于马上下单接口（待确认，见 `TODO(REQ-MIN-003)`） |
|
||
| 2 | 服务热线列表（号码/服务时间/范围/类型） | App Backend | HTTPS | 支持一键拨号 |
|
||
| 3 | 经销商客服信息 | App Backend | HTTPS | 在线咨询、留言反馈 |
|
||
| 4 | O2O / 延保企微客服信息 | App Backend | HTTPS | 数据来源于企业微信接口（待确认，见 `TODO(REQ-MIN-004)`） |
|
||
| 5 | 退出登录 | App Backend | HTTPS | 清除登录态；多设备登录时单设备退出不影响其它设备 |
|
||
|
||
> **A.9 第 5 条隐含一条尚未成文的规则**：多设备可同时登录，单设备登出不影响其它设备。这与[账号权限管控痛点](../Continental-Retail-APP-PRD.md#22-账号权限管控)中「账号共用」的治理诉求存在张力 —— 是否需要单设备登录限制，建议在 `TODO(REQ-LGN-009)` 一并确认。
|
||
|
||
**本次拆分对 A.9 的三点修订建议**（回灌主文件时一并处理）：
|
||
|
||
1. **第 1 条的 TODO 编号指错** —— 备注引用的 `TODO(REQ-MIN-003)` 是「姓名的权威来源与回写范围」，与收货地址无关。应改为指向本次新增的 `TODO(REQ-MIN-014)`（收货地址的权威数据源）。
|
||
2. **第 2 条缺「渠道」字段** —— 现状热线按渠道分为 6 条（小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑），字段清单须补「渠道」，见 [REQ-MIN-008](#486-业务规则)。
|
||
3. **A.9 缺三个数据集** —— 现状页面用到但附录 A 未收录：**门店绑定关系列表**（账号可切换的门店，含门店主编码 / 门店名 / 是否当前，来源 App Backend）、**账户资产聚合**（可用余额 / 信用额度 / 待还 / 未使用返利按品牌×区域 / 优惠券总额 / 积分双类型，来源 ROOS 或「账户管理」小程序后端）、**优惠券列表**（五状态 × 两券种，来源 ROOS + O2O）。三者分别对应 [REQ-MIN-007](#486-业务规则) / [REQ-MIN-009](#486-业务规则) / [REQ-MIN-010](#486-业务规则)。
|
||
|
||
### 附-2 权限矩阵（主文件附录 B 本模块分行）
|
||
|
||
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
|
||
|
||
| 模块 | 功能点 | 店长 | 技工 | 备注 |
|
||
| --- | --- | --- | --- | --- |
|
||
| **我的** | 个人信息 / 换绑手机 / 登出 | ✅ | ✅ | |
|
||
| | 我的账户（额度/返利/券/积分） | ✅ | ❓ | `TODO(REQ-MIN-002)` |
|
||
| | 收货地址 / 我的收藏 | ✅ | 🔸 | 技工只读 |
|
||
| | 支付优先级设置 | ✅ | ✗ | 影响资金 |
|
||
|
||
**本次拆分建议新增的三行**（回灌主文件时一并处理）：
|
||
|
||
| 模块 | 功能点 | 店长 | 技工 | 备注 |
|
||
| --- | --- | --- | --- | --- |
|
||
| **我的** | 切换门店 | ✅ | ✅ | 可切换范围由后台绑定关系决定，不由角色决定（[REQ-MIN-007](#486-业务规则)） |
|
||
| | 收藏列表中的商品价格 | ✅ | ❓ | 须与「查看小程序结算价」同口径，见 `TODO(REQ-INV-001)`（[REQ-MIN-015](#486-业务规则)） |
|
||
| | 服务热线 / 客服入口 | ✅ | ✅ | 不设权限（[REQ-MIN-008](#486-业务规则)） |
|
||
|
||
另需明确：现有「收货地址 / 我的收藏」行的「技工只读」，具体指**可查看但不可新增/编辑/删除地址、不可取消收藏、不可加入购物车**，见 [REQ-MIN-014](#486-业务规则) 与 [REQ-MIN-015](#486-业务规则)。
|
||
|
||
### 附-3 待确认项（主文件 10.2.8）
|
||
|
||
| 编号 | 待确认内容 | 建议决策方 |
|
||
| --- | --- | --- |
|
||
| REQ-MIN-001 | 个人中心保留哪 6 项、其余下沉到哪些模块 | 产品 |
|
||
| REQ-MIN-002 | 资产类（额度/返利/对账单）是否限店长 | 业务 |
|
||
| REQ-MIN-003 | 姓名的权威来源与回写范围 | 架构 |
|
||
| REQ-MIN-004 | 服务热线 / 经销商客服 / 企微客服三个入口是否合并 | 产品 |
|
||
| REQ-MIN-005 | 支付优先级设置放在个人中心还是采购结算 | 产品 |
|
||
| REQ-MIN-006 | 「经营范围」归属个人中心还是门店管理 | 产品 |
|
||
|
||
**本次拆分新增 7 条**（回灌主文件时并入 10.2.8）：
|
||
|
||
| 编号 | 待确认内容 | 建议决策方 |
|
||
| --- | --- | --- |
|
||
| REQ-MIN-007 | **切换门店时购物车、未提交表单、已打开 H5 页面如何处理**；全局门店列表的权威绑定关系取自哪套系统 | 架构 / 产品 |
|
||
| REQ-MIN-008 | 高德、美团客服现用个人手机号，是否替换为总机分机 | 运营 |
|
||
| REQ-MIN-009 | 四项资产在两张资产卡里的落位；优惠券展示张数还是总金额；**采购返利的品牌枚举是否完整（现含卡迪睿德）** | 产品 / 业务 |
|
||
| REQ-MIN-010 | 优惠券「待激活」状态的激活入口与激活规则 | 业务 |
|
||
| REQ-MIN-011 | 支付优先级设置是账号级还是门店级；变更对购物车内商品是否即时生效 | 架构 |
|
||
| REQ-MIN-014 | 收货地址的权威数据源（是否来自马上下单接口） | 架构 |
|
||
| REQ-MIN-018 | **「账户管理」小程序的能力承接范围与接入方式** | 架构 / 业务 |
|
||
|
||
合计 13 条待确认（原 6 + 新增 7）。
|
||
|
||
### 附-4 配图清单（主文件附录 C 4.8 节，16 张）
|
||
|
||
| 序 | 说明 | 文件 |
|
||
| --- | --- | --- |
|
||
| 1 | 设计稿-个人中心（App 目标形态） | `app-design-images/个人中心.png` |
|
||
| 2 | 现状-ROOS 我的 | `mini-program-images/ROOS/我的.png` |
|
||
| 3 | 现状-ROOS 我的（跳转账户管理小程序弹窗，整合后取消） | `mini-program-images/ROOS/我的-跳转账户管理小程序弹窗.png` |
|
||
| 4 | 现状-ROOS 我的账户 | `mini-program-images/ROOS/我的账户.png` |
|
||
| 5 | 现状-ROOS 我的优惠券（待使用） | `mini-program-images/ROOS/我的优惠券-待使用.png` |
|
||
| 6 | 现状-ROOS 支付优先级设置 | `mini-program-images/ROOS/支付优先级设置.png` |
|
||
| 7 | 现状-ROOS 收货地址 | `mini-program-images/ROOS/收货地址.png` |
|
||
| 8 | 现状-ROOS 商品收藏列表 | `mini-program-images/ROOS/商品收藏列表.png` |
|
||
| 9 | 现状-O2O 设置 | `mini-program-images/O2O/设置.png` |
|
||
| 10 | 现状-O2O 设置（确认登出弹窗） | `mini-program-images/O2O/设置-确认登出弹窗.png` |
|
||
| 11 | 现状-O2O 修改手机号 | `mini-program-images/O2O/修改手机号.png` |
|
||
| 12 | 现状-O2O 选择店铺 | `mini-program-images/O2O/选择店铺.png` |
|
||
| 13 | 现状-O2O 小程序在线客服 | `mini-program-images/O2O/小程序在线客服.png` |
|
||
| 14 | 现状-延保 我的 | `mini-program-images/Warranty/我的.png` |
|
||
| 15 | 现状-延保 我的（修改姓名） | `mini-program-images/Warranty/我的-修改姓名.png` |
|
||
| 16 | 现状-延保 我的（切换店铺） | `mini-program-images/Warranty/我的-切换店铺.png` |
|
||
|
||
**看图后对本清单的补充说明**：
|
||
|
||
- 第 4、5 张为**全零 / 空态**截图 —— 我的账户全部金额为 ¥0.00、优惠券列表「暂无可用优惠券~」，故资产明细行与券卡的字段无法从截图确认，须补拍有数据的样本。
|
||
- 第 7、12 张含**测试脏数据** —— 收货地址的省市区重复拼接、选择店铺列表中大量「测试」「勿拍」「野蜂蜜很甜」「吃瓜专门店」类门店名。
|
||
- 第 8 张商品图为**占位图**（ROOS 商品主数据图片缺失）。
|
||
- 第 9 张用户行右侧的橙色小标签**文字过小无法辨认**，第 14 张底部中央的橙色指南针钮**功能无法确认**，两处均须补拍或向业务确认。
|
||
- 建议**补拍 4 张**：有数据的「我的账户」、有券的优惠券列表、O2O 修改手机号的入口路径、延保底部中央按钮展开态。补拍后附录 C 的 4.8 节计数由 16 → 20，须同步更新文档头部规模声明与本文件头部信息表。
|
||
|
||
### 附-5 本次拆分新增发现
|
||
|
||
1. **4.8 完全没有业务规则小节** —— 六个 REQ-MIN 编号全部只以 `TODO(...)` 形式存在，无一条成文规则，这是附录 D.2 中 MIN 完成度 0%（14 个模块唯一）的直接原因。本次补入 [4.8.6 业务规则](#486-业务规则) 共 14 条，原验收标准顺延为 4.8.7。**回灌主文件时须同步这处节号变更，并把 D.2 的 MIN 行由 6 / 6 / 0% 改为 20 / 13 / 35%。**
|
||
2. **合并规则表漏了 4 项能力** —— 「本月进度」考核卡、「员工管理」、「我的订单」四状态入口、「关于 / 版本号」，四者既不在原 16 行表里，也不在设计稿里。已补入 4.8.5（16 行 → 19 行，其中「我的订单」与前三项一并计入）。其中**「关于 / 版本号」是发版合规必备项**，缺失风险最高。
|
||
3. **「账户管理｜德国马牌轮胎」是系统清单外的第 8 个小程序** —— 第 5 章的现状系统清单（ROOS / O2O / 延保 / 马上下单 / RMS / MSIP / F6）不含它，但 ROOS 的资产入口实际跳转到它。合并规则表写「取消跳转」，等于要求 App 承接一个尚未评估的系统，见 [REQ-MIN-018](#486-业务规则)。**建议在第 5 章的系统清单中补录该小程序。**
|
||
4. **返利有两套互不相通的体系** —— ROOS **采购返利**（按「品牌–区域」累计，抵扣货款，[4.6 采购](./06-PUR-采购.md#46-采购)结算页在用）与 O2O **营销返利**（消费者补贴 / 安装费用 / 抽奖红包，[4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)在写）。**主文件 4.11 只覆盖后者**，而 4.8.5 合并规则表把「我的账户（额度/返利/券/积分）」的返利明细指向 4.11 —— 指错了。已在本文件的合并规则表中更正。另外，采购返利出现了 4.11 从未提及的第三个品牌「**卡迪睿德**」。
|
||
5. **换绑手机的验证码发往原号** —— 现状只验证原号、不验证新号，填错一位即把账号绑到陌生号码且原号失去登录能力，属不可自助恢复的故障。已定为 [REQ-MIN-012](#486-业务规则)（必须双向验证），无需再走待确认。
|
||
6. **支付优先级设置的描述与现状不符** —— 主文件原文「设置是否优先使用扣账支付方式」，现状实为二值开关「是否优先使用微信支付」。已在 4.8.2 就地更正，回灌时须带上。
|
||
7. **账号与门店是多对多，规模不小** —— O2O 单账号绑定 13 家以上门店，且列表无搜索。这条事实决定了 [REQ-HOM-001](./02-HOM-APP首页与导航.md#426-业务规则) 全局门店上下文的实现复杂度，也决定了切店时的数据清理策略，见 [REQ-MIN-007](#486-业务规则)。**三套系统的门店绑定关系各自维护**（本例延保侧 1 家、O2O 侧另一账号 13+ 家），统一后的权威来源须定。
|
||
8. **第七套渠道枚举** —— O2O 客服热线的渠道口径为「小程序 / 天猫京东拼多多 / 抖音 / 高德 / 美团 / 零跑」，与 [4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)（内部四种变体）、[4.11 返利中心](./11-RBT-返利中心.md#411-返利中心)（8 项，含抖音团购轮胎）、[4.12 经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)（7 项）、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)（6 个平台渠道 + 同名的品牌授权概念）**均不相同**。至此全仓库已出现**七套渠道枚举**。**强烈建议在第 5 章主数据中定义唯一的渠道枚举，各章节一律引用，不再各写各的。**
|
||
9. **A.9 第 1 条的 TODO 编号指错** —— 引用的 `TODO(REQ-MIN-003)`（姓名的权威来源）与收货地址无关，应改为 `TODO(REQ-MIN-014)`。这与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)、[4.10 财务与对账](./10-FIN-财务与对账.md#410-财务与对账)、[4.9 门店管理](./09-STM-门店管理.md#49-门店管理)中已发现的 TODO 编号漂移是同一类问题 —— **建议在全文回灌后统一做一次 REQ 编号与 TODO 引用的交叉校验。**
|
||
10. **同一件事三套交互** —— 切换门店在 O2O 是整页列表 + 「进入」按钮、在延保是底部滚轮选择器、在 ROOS 的「我的」页则没有入口；深色（延保）与浅色（ROOS / O2O）两套主题；延保用微信原生 picker 导致确定按钮是绿色。App 统一后须固定一种交互与一套主题色。
|
||
11. **三套系统对同一个人的称呼各不相同** —— O2O 显示昵称「宛玉」、ROOS 显示手机号 13871477616、延保显示可自由编辑的操作人姓名「史涵」。姓名字段在延保侧是自由文本且编辑弹窗不预填当前值。这是 `TODO(REQ-MIN-003)` 的具体表现，已在 [REQ-MIN-013](#486-业务规则) 中补上校验与预填要求。
|
||
12. **手机号在两处未脱敏** —— ROOS「我的」头部直接展示 13871477616，O2O 修改手机号页展示 `134 1969 1597`。这与 [4.9 门店管理](./09-STM-门店管理.md#49-门店管理)中发现的手机号未脱敏是同一类问题，**建议在第 5 章或安全章节统一规定客户端手机号展示的脱敏规则**。
|