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

445 lines
36 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 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 内的实际价值需重新评估。本图不足以判定,建议向业务核实真实门店的消息量级。