Files
conti-docs/prd/modules/02-HOM-APP首页与导航.md
T

445 lines
36 KiB
Markdown
Raw Normal View History

# 4.2 APP 首页
> **本文件是【APP 首页与导航 HOM】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.2 节已于 2026-08 从本文件回灌(V1.1),此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | HOM |
| V1.0 章节 | 4.2 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 设计稿 3 版 |
| 现状承载系统 | ROOS / O2O / 延保(三套 tabbar 待废弃) |
| 需求条数 | 14(待确认 11,完成度 21% |
| 本次新增待确认 | 1REQ-HOM-016 见[附-5](#附-5-本次拆分新增发现待业务确认) |
| 配图 | 5 张(设计稿 3 / 现状-ROOS 1 / 现状-O2O 1 |
模块概要
---
APP 首页是用户登录成功后展示的第一个页面。不同角色因权限不同,展示的信息和菜单不一样。
![设计稿-首页-店长](../app-design-images/首页-店长.png)
**页面内容** —— 店长首页目标形态,自上而下为门店名 + 问候语 + 铃铛(角标 9)的头部、橙色「今日预计营收」卡、快速核销与车牌扫码两张卡、待办事项五项计数、动态预警与促销横幅,底部五 tab 为 **首页 / 入库 / 采购 / 延保 / 我的**
**关键交互** —— ①点门店名 → 切换门店(**本稿未画下拉箭头**,见下方说明);②点眼睛图标 → 隐藏 / 显示金额类指标([REQ-HOM-011](#426-业务规则));③点铃铛 → 进入消息列表,角标清零;④「快速核销-扫码 / 输码」→ 核销流程;⑤「车牌扫码-扫码 / 车牌」→ 接车进销售流程;⑥点待办任一项 → 进对应订单列表;⑦「查看全部」→ 全量预警列表;⑧点促销横幅 → 活动详情;⑨底部 tab 切换模块。
**可用角色** —— 店长 ✅ 全量。本稿的金额类分区(预计营收 / 毛利 / 客单价)对技工 ✗,见 [4.2.4](#424-技工首页)。
**需求关联** —— [REQ-HOM-001](#426-业务规则) 门店切换、[REQ-HOM-002](#426-业务规则) 问候语、[REQ-HOM-003](#426-业务规则) 消息公告、[REQ-HOM-005](#426-业务规则)/[006](#426-业务规则) 扫码与输码接车、[REQ-HOM-007](#426-业务规则) 快速核销、[REQ-HOM-008](#426-业务规则) 待办、[REQ-HOM-009](#426-业务规则) 动态预警、[REQ-HOM-011](#426-业务规则) 今日经营卡片
> **本稿的三处状态缺失**(属设计稿补稿,不新增需求):①门店名旁**未画下拉箭头**,而功能宫格版画了 `▾` —— 切店器的表现形式两版不一致,随 [REQ-HOM-001](#426-业务规则) 统一;②动态预警角标写「2 项待处理」,但列表区**只画了 1 条**(低库存),第 2 条未画;③金额隐藏后的形态(打码还是留空)未画。
![设计稿-首页-技工](../app-design-images/首页-技工.png)
**页面内容** —— 技工首页目标形态,头部**无门店名与铃铛**、橙色卡改为「今日已完工 8 单」且**不含任何金额**,快速核销与车牌扫码两张卡同店长版,其下是技工独有的「当前施工队列(共 2 单)」工单卡,底部五 tab 与店长版一致。
**关键交互** —— ①「查看绩效明细」→ 技工个人绩效页(该页无设计稿);②「开始施工」→ 工单转「安装中」;③「完工并结算」→ 结算(去 F6 结算页还是 App 内页未定 `TODO(REQ-HOM-012)`);④快速核销与车牌扫码同店长版。**本稿未画**消息铃铛、待办事项、动态预警、促销位。
**可用角色** —— 技工 ✅。「当前施工队列」为技工独有,店长 ✗。技工是否应有消息 / 待办 / 预警三个分区,业务需求说有、本稿未画 —— `TODO(REQ-HOM-003)` / `TODO(REQ-HOM-008)` / `TODO(REQ-HOM-009)`
**需求关联** —— [REQ-HOM-011](#426-业务规则)(技工只看完工单数,本稿是该规则的直接落地)、[REQ-HOM-012](#426-业务规则) 当前施工队列
> 卡片一的施工内容写作「**更**正品查验 + 动平衡 + 轮胎号延保绑定」,疑为「更换 / 正品查验」的文案笔误,补稿时一并核对。
![设计稿-首页-功能宫格版](../app-design-images/首页-功能宫格版.png)
**页面内容** —— 首页备选方案(对应[三版底部导航](#425-导航收敛与角色化配置)的方案 C),自上而下为内嵌核销码输入框的橙色头部、限时活动三张商品卡、待办事项五项计数、八宫格功能入口与经营业绩区(四个时间 tab + 三项指标,数值为占位),底部五 tab 为 **首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心**
**关键交互** —— ①输核销码 → 点「核销」直接核销(比店长版少一步进卡片);②「限时活动-更多」→ 活动列表;③点商品卡 → 目标未定,见 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom);④点八宫格(扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换)任一 → 进对应模块;⑤切换当日/当周/当月/当季 → 刷新经营指标;⑥「经营业绩-更多」→ 经营报表。
**可用角色** —— 本稿**未区分角色**,仅作导航方案备选。若采用,需补技工版 —— 稿中「经营业绩」含 O2O 成交金额,属金额类,对技工应不可见(`TODO(REQ-PRF-001)`)。
**需求关联** —— [REQ-HOM-010](#426-业务规则) 角色化导航(本稿即方案 C 的实体)、[REQ-HOM-007](#426-业务规则) 快速核销、[REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 促销位形态与来源
> **本稿与店长版的两处口径不一致**,需在 [REQ-HOM-008](#426-业务规则) / [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 一并裁决:①待办首项,店长版写「待**接**单」、本稿写「待**订**单」;②促销位,店长版是底部活动横幅、本稿是顶部三商品卡、技工版没有 —— **三版稿画了三种形态**;且本稿三张商品卡**直接用了京东站内推广创意**(可见「京东JOY」「JD.COM」「爱奇艺」等第三方水印),正式稿须换成马牌自有素材。
## 4.2.1 需求描述
**业务目标** —— 把分散在三套小程序的入口、待办、经营数据聚合到一屏,让门店开工第一眼就知道「今天有什么要做、有什么要盯」,解决[痛点 2.1](../Continental-Retail-APP-PRD.md#21-多小程序分散) 与 [2.5](../Continental-Retail-APP-PRD.md#25-数据经营分析)
**目标角色** —— 店长、技工(内容差异见 [4.2.3](#423-店长首页)、[4.2.4](#424-技工首页)
**入口** —— 登录成功后默认落地;任意页面点击底部「首页」tab
**前置条件** —— 已登录且已确定当前门店上下文
**页面内容** —— 见 [4.2.3](#423-店长首页)、[4.2.4](#424-技工首页)
**主流程**
1. 进入首页
2. 并行拉取门店信息、待办、预警、促销、经营卡片
3. 分区渲染,任一分区失败不阻塞其它分区
4. 用户点击分区进入对应模块
**异常流程**
- 单个数据源超时/失败 → 该卡片显示占位与「重试」,其余正常展示(局部降级,见《后端跨域协作与聚合文档》)
- 门店未接 F6 → 隐藏依赖 F6 的分区与 tab
- 无待办 → 显示空态而非隐藏分区
**业务规则** —— 见 [4.2.6](#426-业务规则)
**权限规则** —— 底部 tab 集合、卡片可见性均由 App Backend 按「角色 + 门店能力」下发,客户端不硬编码,见 [4.2.5](#425-导航收敛与角色化配置)
**访问链路** —— App → App Backend(聚合)→ 并行 fan-out 至 O2O / ROOS / 延保 / CDMS / F6
**逻辑数据来源** —— 见 [4.2.7](#427-业务数据列表)
**回写目标** —— 消息已读状态回写 App Backend;其余为只读聚合
**状态变化** —— 消息:未读 → 已读;待办项计数随源系统单据状态变化
**验收标准** —— 见 [4.2.8](#428-验收标准)
## 4.2.2 现状导航与目标导航的差异
整合前,三套小程序各带一套底部导航,且互相之间用「首页放友链」的方式跳转(见 [2.7.1](../Continental-Retail-APP-PRD.md#271-现状导航结构))。整合后**全部小程序 tabbar 一律废弃**,App 只保留一套底部导航。
| 现状入口 | 现状位置 | App 归属 |
| --- | --- | --- |
| ROOS 首页 / 商品 / 购物车 | ROOS tabbar | 合并进「采购」tab[4.6](./06-PUR-采购.md) |
| ROOS 我的 | ROOS tabbar | 拆分:账务类进「我的」([4.8](./08-MIN-我的.md)),对账单进[财务](./10-FIN-财务与对账.md),业绩进[经营业绩](./12-PRF-经营业绩与报表.md) |
| ROOS 扫码出库 / 扫码入库 | ROOS 首页 | 「入库」tab[4.7](./07-INV-库存.md) |
| O2O 核销码输入 + 核销 | O2O 首页顶部 | 首页「快速核销」卡片 |
| O2O 订单管理五状态 | O2O 首页 | 首页「待办事项」+ [4.3 销售](./03-SAL-销售.md)的订单列表 |
| O2O 两组功能宫格(13 项) | O2O 首页 | 分派至 [4.9](./09-STM-门店管理.md) / [4.10](./10-FIN-财务与对账.md) / [4.11](./11-RBT-返利中心.md) / [4.12](./12-PRF-经营业绩与报表.md) / [4.13](./13-MKT-营销与会员.md) |
| 延保 首页 / 工作台 / 待办事项 / 我的 | 延保 tabbar | 合并进「延保」tab[4.5](./05-WTY-延保.md) |
| 「订货平台 / O2O / 延保门店端 / 积分兑换 / 零售管理」互跳宫格 | ROOS + O2O 首页 | **取消**——整合后无需互跳;其中「积分兑换」保留为 [4.14 福利兑换](./14-MSP-福利兑换.md)入口 |
现状入口 → App 导航映射
## 4.2.3 店长首页
自上而下分区(见本节店长首页设计稿):
**一、门店切换**
当前用户旗下如果有多家店,可以通过顶部的下拉选择项切换至不同的门店。切换后所有业务数据按新门店重新加载。
**二、问候语**
用户成功登录首页后,在左上方展示用户信息以及问候。系统读取当前用户的姓氏、角色以及当前时间段,整合成合适的问候语,如「张店长,上午好」。
**三、消息公告**
右上角铃铛图标的角标展示当前未读消息条数;点击图标以列表形式展示系统站内信;点击后角标数字消失。促销信息展示往期马牌的所有促销活动;通知消息由管理员在后台管理平台发布。
![现状-ROOS 公告列表-空态](../mini-program-images/ROOS/公告列表-空态.png)
**页面内容** —— ROOS 小程序「公告列表」页,**本图为空态**(「暂无公告」占位),故公告条目的字段构成无法从本图确认。
**关键交互** —— ①左上返回;②有数据时点条目进详情(本图无法确认)。本页除返回外**无任何筛选、搜索或标记已读的控件**。
**可用角色** —— 店长 ✅;技工 ❓ `TODO(REQ-HOM-003)`。ROOS 侧现状不区分角色。
**需求关联** —— [REQ-HOM-003](#426-业务规则) 消息公告、[REQ-HOM-004](#426-业务规则) 促销信息(往期促销即在本列表中承载)
![现状-O2O 消息-门店违规提醒](../mini-program-images/O2O/消息-门店违规提醒.png)
**页面内容** —— O2O 接单宝「消息」页,按日期分组的卡片流,**本图可见的消息全部是同一类**(`【门店违规】提醒`),且**最新一条已是 2023-04-13**。
**关键交互** —— ①上下滑动按日期倒序浏览。**未见**已读标记、删除、分类筛选或点击进详情的控件 —— 本页是纯只读消息流。
**可用角色** —— 店长 ✅(违规会导致「禁止接单」,属店长必须知悉的治理类消息);技工 ❓ `TODO(REQ-HOM-003)`
**需求关联** —— [REQ-HOM-003](#426-业务规则)。本图是「消息分类体系」这条待确认的核心证据:O2O 侧是**会阻断经营的治理类消息**,ROOS 侧是**促销与通知类公告**,两者的紧急程度、是否需强提醒、能否删除完全不同,合并进一个消息中心时必须分类承载。本图的违规原因样例为「车牌号已超出年度最大下单量」「同一手机号下多笔订单超过限制数量」「门店单日销量超过限制数量」,均由风控规则触发,正文写「门店触发违规条件,已被禁止接单」并附「如有异议,请联系门店相应的销售代表」。
> 现状消息分散在 ROOS「公告」与 O2O「消息」两处,且类型不同(ROOS 为促销/通知公告,O2O 含门店违规提醒等治理类消息)。整合后需在一个消息中心内分类承载 —— 消息分类体系 `TODO(REQ-HOM-003)`。
>
> **补充**:附录 A.2 已定义消息列表「支持查看、标记已读、删除」,但上面两张现状图**都没有这三个控件** —— 这三项是 App 的新增能力,不是现状迁移,开发时需明确它们作用于哪一侧数据(App 自有消息表还是回写 ROOS / O2O)。
**四、促销信息**
提醒用户当前马牌轮胎有促销活动,系统展示马牌最近一次举行的促销活动;点击促销区域展示具体活动内容。促销活动内容来自 **ROOS** 提供的接口;APP 后台定时调用促销活动接口,拉取促销信息并推至用户首页;往期促销信息在右上角铃铛对应的列表页中展示。
设计稿中该区域为首页底部的横幅广告位(「马牌高端系列 买三送一」)。
> ⚠️ 三版设计稿对促销位画了三种形态 —— 形态与来源需一并裁决,见 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)。
**五、扫码接车**
当客户车开进马牌门店时,用户可以直接点击「扫码」按钮,对准客户车头识别车辆号牌,进入销售流程。
> 扫码由 **App 原生能力**实现(`native_scan`),非 F6 提供的扫码页,见 [C5](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。**车牌识别走云端 OCR 服务**:拍一张照上传识别,不是取景框里的实时识别,因而**依赖网络**——「输码」不是失败后的降级,而是与「扫码」并列的常驻入口。见[第 10 章风险 R9](../Continental-Retail-APP-PRD.md#104-风险登记)。
**六、输码**
在做客户接车时,因特殊原因无法正确通过「扫码」识别客户车牌时,可以通过「车牌」按钮手工输入客户的车辆号牌,进入销售流程。
**七、快速核销**
设计稿在「车牌扫码」之外并列了一组「快速核销」(扫码 / 输码),对应 O2O 接单宝首页顶部的核销码输入框 —— 消费者到店出示线上订单核销码,门店扫码或手工输码完成核销。
> 扫码核销的详细流程待确认 —— `TODO(REQ-SAL-010)`,详见 [4.3.4](./03-SAL-销售.md#434-核销)。
**八、待办事项**
待办事项在首页中扮演用户助手的角色,方便用户随时查看自己的工作列表。每项提醒的上方显示该项对应的待办事项总数。
现有两套并存的待办口径,**两者不冲突,是两个层次**:
| 层次 | 项目 | 来源 | 说明 |
| --- | --- | --- | --- |
| **跨系统提醒**(业务层) | O2O 订单接单提醒、CDMS 采购单支付提醒、延保视频上传提醒、问卷提醒、过期门店信息更新提醒 | O2O / CDMS / 延保 / 待定 | 按来源系统聚合的业务提醒 |
| **订单流转状态**(单据层) | 待接单、待调货、待安装、待配送、待服务 | O2O 订单管理 | 设计稿口径;对应 O2O 现状的「待接订单 / 调货中 / 待安装 / 待配送 / 配送中」 |
待办事项两层口径
> 设计稿的五项与 O2O 现状五状态一一对应但措辞不同(「待调货」vs「调货中」、「待服务」vs「配送中」)。首页最终展示哪一层、或两层如何合并展示 —— `TODO(REQ-HOM-008)`,见 [C2](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
>
> **补充**:措辞不一致不止存在于「设计稿 vs O2O 现状」,**两版设计稿之间也不一致** —— 店长版首项写「待**接**单」,功能宫格版写「待**订**单」。取哪一套措辞随本条一并定稿。
**九、动态预警**
动态预警在首页中扮演用户管家的角色,随时帮用户检查目标任务达成情况、库存数量预警、时效订单预警等。系统按紧急程度在动态预警右边展示需要及时处理的事件数量,并提供「查看全部」入口浏览所有需要及时处理的事件。
预警项全集:
| 预警项 | 数据来源 | 备注 |
| --- | --- | --- |
| 总预警数 | APP 后台计算 | 各项之和 |
| 月度签约达成预警 | `TODO(REQ-HOM-009)` | 达成口径与阈值待定 |
| 库存预警(低库存) | F6 | ⚠️ 未接 F6 不显示此项;设计稿示例为「低库存 马牌 205/55R16 剩余 5 条」 |
| 时效订单预警 | O2O | 临近履约时限的订单 |
动态预警项
> 各项预警的触发阈值(如低库存的条数门槛、时效订单的提前量)均未定义 —— `TODO(REQ-HOM-009)`,见 [C3](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
**十、今日经营卡片**
设计稿在问候语下方设有营收卡片:今日预计营收(¥34,500)、毛利率(88%)、成交单数(24 单)、客单价(¥1,437),并带「眼睛」图标支持一键隐藏金额。
> 该卡片仅见于设计稿。**「预计营收」的口径**(是否含未结算订单、是否含延保与返利、毛利率的成本口径)未定义 —— `TODO(REQ-HOM-011)`,见 [C8](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。金额隐藏功能对应[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控) 中「技工可查看门店财务数据」的风险控制诉求。
**十一、底部导航**
见 [4.2.5](#425-导航收敛与角色化配置)。
## 4.2.4 技工首页
技工首页与店长首页的分区差异(见本节技工首页设计稿):
| 分区 | 店长 | 技工 | 说明 |
| --- | --- | --- | --- |
| 门店切换 | ✅ 下拉切换 | ⚠️ 仅显示门店名 | 拥有多门店权限的用户可切换门店;设计稿技工版无门店名与切换器 —— `TODO(REQ-HOM-001)` 需确认技工是否允许多门店 |
| 问候语 | 「张店长,上午好」 | 「韩师傅 · 技师」 | 设计稿技工版为「姓氏 + 师傅 · 角色」格式,无时段问候 |
| 消息公告 | ✅ 铃铛 + 角标 | ⚠️ 设计稿未出现 | 业务需求中技工应有消息公告 —— `TODO(REQ-HOM-003)` 需确认 |
| 促销信息 | ✅ | ✅ | 技工可见 |
| 今日经营卡片 | 今日预计营收 / 毛利 / 成交单数 / 客单价 | **今日已完工 N 单** + 「查看绩效明细」 | 技工不可见金额类数据,与[痛点 2.2](../Continental-Retail-APP-PRD.md#22-账号权限管控) 一致 |
| 快速核销 / 车牌扫码 | ✅ | ✅ | 完全一致 |
| 待办事项 | ✅ | ⚠️ 设计稿未出现 | 业务需求中技工应有待办事项 —— `TODO(REQ-HOM-008)` |
| 动态预警 | ✅ | ⚠️ 设计稿未出现 | 业务需求中技工应有动态预警 —— `TODO(REQ-HOM-009)` |
| **当前施工队列** | ❌ | ✅ | **技工独有分区,仅见于设计稿** |
店长 / 技工首页分区差异
> **上表「促销信息 技工 ✅」与技工版设计稿不符** —— 技工版稿中**没有促销位**(店长版有底部横幅、宫格版有顶部商品卡)。该行按业务需求填写,实际形态随 [REQ-HOM-016](../Continental-Retail-APP-PRD.md#1022-首页与导航hom) 一并确认。
**当前施工队列**(技工独有)
展示分配给当前技工的施工任务,卡片含:车牌号、订单来源渠道标(天猫订单 / 京东订单)、状态标(安装中 / 待安装)、施工内容(如「更正品查验 + 动平衡 + 轮胎号延保绑定」「更换 马牌 UC6 225/55R17 * 4 条」)、预约时间、主操作按钮(「完工并结算」/「开始施工」);顶部显示「共 N 单」。
> 该分区仅见于设计稿。涉及的问题:施工任务如何分派给具体技工?状态机与 F6 工单、O2O 服务单的关系?「完工并结算」跳转到 F6 结算页还是 App 内页?—— `TODO(REQ-HOM-012)`,见 [C13](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
## 4.2.5 导航收敛与角色化配置
**收敛原则**
1. 整合后 App 只有**一套**底部导航,所有小程序 tabbar 全部废弃;
2. tab 集合**不在客户端硬编码**,由 App Backend 在登录/切店后下发;
3. 下发依据为 **角色(店长 / 技工)× 门店能力(是否接 F6、是否开通延保等)**
4. 客户端对未知 tab code 做忽略处理,保证后端可灰度增删 tab 而不强制发版。
**三版 tab 方案**
| 方案 | tab 集合 | 来源 |
| --- | --- | --- |
| A(业务菜单版) | 首页 / 库存 / 采购 / 我的 | 业务需求「用户主菜单」 |
| B(主设计稿) | 首页 / 入库 / 采购 / 延保 / 我的 | 设计稿 首页-店长、首页-技工、个人中心 |
| C(宫格版) | 首页 / 门店管理 / 经营分析 / 账务对账 / 个人中心 | 设计稿 首页-功能宫格版 |
三版底部导航方案
三者的差别不只是段数:方案 A/B 是「业务动作导向」(去入库、去采购),方案 C 是「管理职能导向」(看门店、看经营、看账务),且方案 C 把业务动作全部收进首页的 8 宫格(扫码入库 / 扫码出库 / 马牌商品 / 订单管理 / 条码库存 / 延保服务 / 核销记录 / 福利兑换)。
**推荐方案**:以 **B** 为基线(业务动作导向更贴合门店高频操作),把 C 的管理职能入口收进「我的」与首页宫格。
> ⚠️ **各角色的具体 tab 清单尚未确认** —— `TODO(REQ-HOM-010)`,见 [C1](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。下表为待确认的建议值:
| tab | 店长 | 技工 | 门店能力依赖 | 对应章节 |
| --- | --- | --- | --- | --- |
| 首页 | ✅ | ✅ | — | 4.2 |
| 入库 | ✅ | ✅ | — | [4.7](./07-INV-库存.md) |
| 采购 | ✅ | ⚠️ 授权可见 | — | [4.6](./06-PUR-采购.md) |
| 延保 | ✅ | ✅ | 门店已开通延保 | [4.5](./05-WTY-延保.md) |
| 我的 | ✅ | ✅ | — | [4.8](./08-MIN-我的.md) |
角色化 tab 配置(建议值,待确认)
> 店长版与技工版两张设计稿的底部导航**完全一致**(首页 / 入库 / 采购 / 延保 / 我的),即稿中并未体现角色化差异 —— 差异全在页面内容而非 tab 集合。上表把「采购」对技工标为「授权可见」,属建议值,设计稿并未画出技工少一个 tab 的形态。
**门店能力开关对导航的影响**
已明确一条硬规则:
> ⚠️ 如果当前用户所在门店未接 F6,「库存」菜单不显示;对技工还需叠加「技工无此权限则不显示」。
推广为通用规则:任一 tab 或首页分区若依赖某外围系统,而当前门店未接入该系统,则该 tab / 分区整体隐藏(而非置灰或点击后报错)。能力开关清单见 [7.4](../Continental-Retail-APP-PRD.md#74-门店能力开关)。
## 4.2.6 业务规则
**REQ-HOM-001 门店切换** —— 多门店账号可在首页顶部切换门店;切换后级联刷新全部数据,见《App 门店上下文与会话管理文档》
**REQ-HOM-002 问候语** —— 由「姓氏 + 角色称谓 + 时段问候」拼接;时段划分口径 `TODO(REQ-HOM-002)`
**REQ-HOM-003 消息公告** —— 角标为未读数;点击进入列表后清零。消息分类体系待定 `TODO(REQ-HOM-003)`
**REQ-HOM-004 促销信息** —— 来源 ROOS 接口,APP 后台定时拉取;首页展示最近一次活动,往期在消息列表
**REQ-HOM-005 扫码接车** —— App 原生扫码识别车牌 → 进入销售流程
**REQ-HOM-006 输码接车** —— 扫码失败时手工输入车牌 → 进入销售流程
**REQ-HOM-007 快速核销** —— 扫核销码或手工输入核销码 → 进入核销流程([4.3.4](./03-SAL-销售.md#434-核销)
**REQ-HOM-008 待办事项** —— 两层口径并存,最终展示形态待定 `TODO(REQ-HOM-008)`
**REQ-HOM-009 动态预警** —— 四项预警,阈值待定 `TODO(REQ-HOM-009)`;库存预警依赖 F6
**REQ-HOM-010 角色化导航** —— tab 集合由后端按角色 + 门店能力下发,清单待定 `TODO(REQ-HOM-010)`
**REQ-HOM-011 今日经营卡片** —— 店长看金额类指标(可隐藏),技工看完工单数;口径待定 `TODO(REQ-HOM-011)`
**REQ-HOM-012 当前施工队列** —— 技工独有;分派规则与状态机待定 `TODO(REQ-HOM-012)`
**REQ-HOM-013 分区降级** —— 任一数据源失败仅该卡片降级,不影响其它分区渲染
**REQ-HOM-016 促销位形态与来源** —— 三版设计稿画了三种互不相同的促销位形态(店长版底部通栏横幅、宫格版顶部三商品卡、技工版无),[附录 A.2](../Continental-Retail-APP-PRD.md#a2-首页) 又写作顶部滚动提示,共四种说法;宫格版素材直接用了第三方电商推广创意,正式稿须换成马牌自有素材。最终形态、数据来源、点击目标与技工可见性均待定 `TODO(REQ-HOM-016)`
## 4.2.7 业务数据列表
| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 门店名称列表 | StoreNameList | 马上下单 | 来自马上下单的门店列表 |
| 2 | 用户问候 | GreetingStr | APP Backend | 首页问候语,来自登录后获取的姓名和当前时间 |
| 3 | 消息公告 | Msg2PromotionList | APP 后台 + ROOS | 消息公告来自 APP 后台,促销信息来自 ROOS |
| 4 | 促销信息 | PromotionMsg | ROOS | 来自最新的 ROOS 促销信息 |
| 5 | 待办事项 | TodoList | 多源 | O2O 订单接单提醒:O2O 接口<br>CDMS 采购单支付提醒:CDMS 接口<br>延保视频上传提醒:延保接口<br>问卷提醒:`TODO(REQ-HOM-014)`<br>过期门店信息更新提醒:`TODO(REQ-HOM-015)` |
| 6 | 动态预警 | PrecautionIndexList | 多源 | 总预警数:APP 后台计算<br>月度签约达成预警:`TODO(REQ-HOM-009)`<br>库存预警:F6(⚠️ 未接 F6 不显示此项)<br>时效订单预警:O2O |
| 7 | 动态预警查看详情 | PrecautionAllList | 同上 | 全量预警列表 |
| 8 | 今日经营卡片 | TodayBusinessCard | `TODO(REQ-HOM-011)` | 预计营收 / 毛利率 / 成交单数 / 客单价(店长);已完工单数(技工) |
| 9 | 当前施工队列 | WorkQueueList | `TODO(REQ-HOM-012)` | 技工独有;车牌、渠道、状态、施工内容、预约时间 |
| 10 | 底部 tab 配置 | TabConfigList | APP Backend | 按角色 + 门店能力下发 |
APP 首页信息字段
## 4.2.8 验收标准
1. 未接 F6 的门店,登录后底部导航不出现依赖 F6 的 tab,首页不出现库存预警项;
2. 多门店店长切换门店后,首页全部分区(待办、预警、经营卡片、促销)均刷新为新门店数据;
3. 任意单个上游系统(O2O / CDMS / 延保 / F6)不可用时,首页仍可打开,失败分区显示占位与重试,其余分区正常;
4. 技工登录后首页不出现任何金额类经营指标;
5. 消息角标数字与消息列表未读条数一致;进入列表后角标归零。
---
## 附:本模块归拢信息
> 以下内容从主文件的其它章节归拢而来,便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典(主文件附录 A.2)
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 切换后的店铺信息集 | App Backend | HTTPS | |
| 2 | 店铺列表结果集(用于切店) | App Backend | HTTPS | |
| 3 | 当前用户的菜单数据集 | App Backend | HTTPS | **即角色化 tab 下发**[REQ-HOM-010](#426-业务规则) |
| 4 | 动态预警 | Mini Program Backend | HTTPS | 来自 ROOS 与 O2O |
| 5 | 促销信息 | Mini Program Backend | HTTPS | 首页顶部滚动提示 |
| 6 | 公告/通知列表(按发布时间倒序) | Mini Program Backend | HTTPS | 支持查看、标记已读、删除 |
| 7 | 待办事项(按优先级/截止时间排序) | Mini Program Backend | HTTPS | 来自 O2O 与延保后台 |
首页模块数据集(摘自主文件[附录 A.2](../Continental-Retail-APP-PRD.md#a2-首页))。字段级清单见上方 [4.2.7](#427-业务数据列表)。
> **第 5 条与设计稿不符**:附录 A 写促销信息是「首页**顶部滚动提示**」,而店长版稿把它画成**底部通栏横幅**、宫格版画成**顶部三商品卡**。三处形态互不相同 —— 随 [REQ-HOM-016](#附-5-本次拆分新增发现待业务确认) 统一。
>
> **第 6 条的三个动作在现状中都不存在**:ROOS 公告列表与 O2O 消息页均无「标记已读 / 删除」控件(见 [4.2.3](#423-店长首页) 两张现状图)。这三项属 App 新增能力,需明确作用于 App 自有消息表还是回写源系统。
### 附-2 权限矩阵(主文件附录 B 本模块分行)
**图例**:✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 门店切换 | ✅ | ❓ | 技工是否允许多门店 `TODO(REQ-HOM-001)` |
| 消息公告 | ✅ | ❓ | 业务需求说有、设计稿未画 `TODO(REQ-HOM-003)` |
| 待办事项 | ✅ | ❓ | 同上 `TODO(REQ-HOM-008)` |
| 动态预警 | ✅ | ❓ | 同上 `TODO(REQ-HOM-009)` |
| 今日经营卡片(金额类) | 🔸 | ✗ | 店长可隐藏金额;技工仅见完工单数 `TODO(REQ-HOM-011)` |
| 当前施工队列 | ✗ | ✅ | 技工独有 `TODO(REQ-HOM-012)` |
首页模块权限矩阵(摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)
适用的全局权限实施规则:接口层强制(REQ-ACC-004);⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予(REQ-ACC-005);**🔸 与 ❓ 项在待确认关闭前,一律按更严格的一侧实现**(REQ-ACC-006);权限变更后用户下次进入 App 即生效(REQ-ACC-007)。
> 本模块权限的特殊之处:**四个 ❓ 全部指向「技工能不能看」**,且四项都是设计稿未画所致,而非业务上已判定不可见。按 REQ-ACC-006,这四项在关闭前一律实现为技工不可见 —— 也就是说,**技工首页首版会是设计稿画的那个精简版**。若业务实际期望技工也有待办与预警,需尽早关闭这四条,否则会返工。
### 附-3 待确认项(主文件 10.2.2)
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-HOM-001 | 技工是否允许多门店(设计稿技工版无切店器) | 产品 |
| REQ-HOM-002 | 问候语时段划分口径 | 产品 |
| REQ-HOM-003 | 消息分类体系;技工是否有消息公告 | 产品 |
| REQ-HOM-008 | 待办两层口径的最终展示形态(**C2**);技工是否有待办 | 产品 |
| REQ-HOM-009 | 四项动态预警的触发阈值(**C3**);技工是否有预警 | 业务 |
| REQ-HOM-010 | **各角色的具体 tab 清单(C1,最高优先级)** | 产品 |
| REQ-HOM-011 | 「今日预计营收 / 毛利率 / 客单价」口径(**C8**) | 财务 / 业务 |
| REQ-HOM-012 | 技工「当前施工队列」的分派规则与状态机(**C13**) | 产品 / 业务 |
| REQ-HOM-014 | 待办中「问卷提醒」的数据来源 | 业务 |
| REQ-HOM-015 | 待办中「过期门店信息更新提醒」的数据来源 | 业务 |
首页模块待确认项(摘自主文件 [10.2.2](../Continental-Retail-APP-PRD.md#1022-首页与导航hom)10 条)
**本次拆分新增 1 条**(回灌主文件时并入 10.2.2):
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| **REQ-HOM-016** | **首页促销位的形态与来源** —— 三版设计稿画了三种形态、附录 A.2 又是第四种;素材含第三方电商水印;点击目标、数据来源与技工可见性均未定,详见[附-5](#附-5-本次拆分新增发现待业务确认) | 产品 / 业务 |
合计 11 条待确认(原 10 条 + 新增 1 条)。回灌时需同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 HOM 行(15 / 10 / 33% → 16 / 11 / 31%)与第 10.2 节总数。
> `TODO(REQ-HOM-010)` 是全文最高优先级的待确认项(**C1**),其落地前提是后台的「APP 配置」粒度 `TODO(REQ-ADM-002)`。两者构成一条链:**后台配得出来 → tab 才下发得下去 → 首页才知道画谁的版本**。
### 附-4 配图清单(主文件附录 C 4.2 节)
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-首页(店长):营收卡 + 双扫码卡 + 待办五项 + 动态预警 + 促销横幅 + 五 tab | `../app-design-images/首页-店长.png` |
| 2 | 设计稿-首页(技工):完工单数卡 + 双扫码卡 + **当前施工队列**,无消息/待办/预警 | `../app-design-images/首页-技工.png` |
| 3 | 设计稿-首页(功能宫格版,备选方案 C):核销码输入 + 限时活动三商品卡 + 八宫格 + 经营业绩 | `../app-design-images/首页-功能宫格版.png` |
| 4 | 现状-ROOS 公告列表(空态,无已读/删除控件) | `../mini-program-images/ROOS/公告列表-空态.png` |
| 5 | 现状-O2O 消息(全部为【门店违规】治理类消息,最新一条 2023-04) | `../mini-program-images/O2O/消息-门店违规提醒.png` |
首页模块配图清单,5 张(设计稿 3 / 现状-ROOS 1 / 现状-O2O 1)。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充,主文件附录 C 回灌时应一并更新。
### 附-5 本次拆分新增发现(待业务确认)
以下 1 条**不在主文件现有 15 条 HOM 需求内**,是本次逐张核看 5 张配图时发现的、现有需求未覆盖的事项。编号接 REQ-HOM-015 顺延,**尚未登记进主文件 10.2.2**,回灌时需一并并入并更新主文件的规模声明与附录 D.2 计数。
| 编号 | 待确认内容 | 证据 | 建议决策方 |
| --- | --- | --- | --- |
| REQ-HOM-016 | **首页促销位的形态与来源**:三版设计稿画了三种互不相同的形态 —— 店长版是底部通栏活动横幅(「马牌高端系列 买三送一」),宫格版是顶部「限时活动」三张商品卡(带划线价、「已售 N」、立减券,**素材含京东JOY / JD.COM / 爱奇艺水印,属第三方电商推广创意**),技工版**没有促销位**;而主文件附录 A.2 又写作「首页**顶部滚动提示**」,共四种说法。需裁决:①最终形态;②数据来源是 ROOS 活动接口([REQ-HOM-004](#426-业务规则) 现有口径)还是第三方电商商品位;③若含商品位,点击后去哪(App 内商详 / 跳京东小程序 / 跳 [ROOS 采购](./06-PUR-采购.md));④技工是否可见([4.2.4](#424-技工首页) 差异表写 ✅,但技工版稿没画)。 | 本节图 1 / 2 / 3 + 附录 A.2 | 产品 / 业务 |
本次拆分新增待确认项,1 条
> 另有三项**不需新增编号**的观察,已就地记在各图下方:①店长版门店名旁未画切店下拉箭头而宫格版画了(随 [REQ-HOM-001](#426-业务规则) 补稿);②动态预警角标写「2 项待处理」但只画了 1 条(补稿);③店长版「待接单」与宫格版「待订单」措辞不一致(随 [REQ-HOM-008](#426-业务规则) 定稿)。
>
> 另有一项数据观察:O2O 消息页**最新一条消息的日期是 2023-04-13**,距今已超三年,且全部为同一类型。可能是该测试账号无近期消息,也可能是 O2O 消息通道现状本就低频 —— 若属后者,「消息中心」在 App 内的实际价值需重新评估。本图不足以判定,建议向业务核实真实门店的消息量级。