Continental-AG/conti-docs
3
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Add initial reference document in Word format with structured headings and content

Browse Source
This commit is contained in:
Guangfei.Zhao
2026-08-24 18:46:37 +08:00
parent 70c5cef4e1
commit d43d33c3cd
197 changed files with 9230 additions and 3754 deletions
Download Patch File Download Diff File Expand all files Collapse all files
prd/modules/14-MSP-福利兑换.md
+124
View File
@@ -0,0 +1,124 @@
# 4.14 福利兑换（MSIP）
> **本文件是【福利兑换 MSP】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.14 节已于 2026-08 从本文件回灌（V1.1），
> 此后的需求变更仍改本文件、再回灌。**两者不一致时以本文件为准。**
| 项 | 值 |
| --- | --- |
| 模块码 | MSP |
| V1.0 章节 | 4.14 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状入口 + 设计稿 + 业务确认（页面待补） |
| 现状承载系统 | MSIP |
| 需求条数 | 8（待确认 4，完成度 50%） |
| 配图 | **0 张** —— 附录 C 无 4.14 节 |
**本模块是全 PRD 材料最少的一个**：至今没有任何 MSIP 的页面截图或设计稿，业务需求文档中也只在背景部分提过一次。已定的是业务目标与积分主体两条，其余四条全部待确认。这一状况已作为风险 R1 登记在[第 10 章](../Continental-Retail-APP-PRD.md#10-风险与待确认项)。
---
> **积分主体已定**：**积分挂在门店账下，不归属店员个人。** App 面向经销商，店长与技工都是门店的员工；积分是**品牌方发给经销商的福利**，因此切换门店时积分随门店上下文一起切换，同门店的店员看到同一份额度。这一条决定了本模块的权限模型与切店行为。
>
> 页面内容、积分产生规则与 MSIP 的集成方式**仍待补**，见 [4.14.1](#4141-业务规则)。
**业务目标** —— 品牌方以积分形式向经销商发放福利，门店用积分兑换商品或权益，作为对门店的激励手段
**入口** —— 现状：ROOS / O2O 首页的「积分兑换」（见 [2.7.2](../Continental-Retail-APP-PRD.md#272-roos-采购小程序)、[2.7.3](../Continental-Retail-APP-PRD.md#273-o2o-接单宝小程序)）；目标：宫格版「福利兑换」（见 [4.2.5](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）或[个人中心](./08-MIN-我的.md#481-目标形态)的积分资产卡
**页面内容** —— 待确认 `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](./01-LGN-账号登录.md#412-业务规则)）；同门店所有角色看到同一份额度
**REQ-MSP-004 集成方式** —— MSIP 是否提供 API，还是只能以 Embedded H5 嵌入待确认 `TODO(REQ-MSP-004)`。若只能嵌 H5，则与[提醒](./04-RMD-提醒.md#44-提醒)同为容器方案，[集成矩阵](../Continental-Retail-APP-PRD.md#72-集成矩阵)需相应调整
**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](./05-WTY-延保.md#457-培训操作指引与服务支持)的现状截图）。整合后三处**全部取消**，收敛为 App 内的单一「福利兑换」入口；积分余额在个人中心的资产卡与福利兑换页两处展示时，**必须同源同刷新时机**，不得出现两个数
**REQ-MSP-008 积分余额的口径与失效** —— ①积分余额随门店上下文切换而整体失效重取，不做跨门店缓存合并（依赖 [REQ-MSP-003](#4141-业务规则)）；②余额展示须带数据口径时间，若 MSIP 为 H5 嵌入则口径时间由 MSIP 页面自行承载；③兑换成功后余额须立即回刷，不得依赖用户手动下拉
---
## 附：本模块归拢信息（来自主文件其它章节）
### 附-1 业务数据字典（主文件附录 A）
**主文件附录 A 未收录本模块的字段清单** —— 附录 A 只有 A.1–A.9 九节，无福利兑换节。与本模块相关的只有第 5 章主数据表的一行：
| # | 类型 | 来源 | 同步方式 | 说明 |
| --- | --- | --- | --- | --- |
| 6 | 积分主数据 | MSIP | `TODO(REQ-MSP-004)` | 见 [4.14](#414-福利兑换msip) |
以及集成矩阵的一行：
| # | 系统 | 涉及模块 | 集成方式 | 数据 |
| --- | --- | --- | --- | --- |
| 7 | **MSIP** | 4.14 福利兑换 | `TODO(REQ-MSP-004)` | 积分、兑换 |
**回灌主文件时的处理建议**：在 `TODO(REQ-MSP-002)` 和 `TODO(REQ-MSP-004)` 各自澄清之前，**不为本模块编造字段清单**。待 MSIP 侧给出页面与接口后，附录 A 至少需补三组数据集：积分账户（门店维度余额、冻结、口径时间）、兑换商品目录、兑换记录（含状态机与物流/发放信息）。
### 附-2 权限矩阵（主文件附录 B 本模块分行）
**图例**：✅ 完整权限 · 🔸 受限（详见备注）· ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **福利兑换** | 积分兑换 | ✅ | ❓ | 积分属**门店**，同店两角色看到同一份余额；能否发起兑换待定 `TODO(REQ-MSP-005)` |
**本次拆分建议新增的一行**（回灌主文件时一并处理）：
| 模块 | 功能点 | 店长 | 技工 | 备注 |
| --- | --- | --- | --- | --- |
| **福利兑换** | 积分余额查看 | ✅ | ✅ | 余额是门店级资产，**查看与兑换应分开授权**：查看全角色开放，兑换权限按 `TODO(REQ-MSP-005)` 裁决 |
拆分理由：现状矩阵只有「积分兑换」一行且技工为 ❓，容易被实现成「技工连余额都看不到」。而 [REQ-MSP-003](#4141-业务规则) 明确「同门店所有角色看到同一份余额」——**看得到**是已定的，**能不能兑**才是待定的，两者必须拆成两行才不冲突。
### 附-3 待确认项（主文件 10.2.11 中的 MSP 分片）
| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-MSP-002 | 福利兑换的页面内容与主流程（兑换商品列表 / 详情 / 记录） | 产品 |
| REQ-MSP-004 | MSIP 是否提供 API，还是只能嵌入 H5 | 架构 |
| REQ-MSP-005 | 门店内是否限店长发起兑换 | 产品 |
| REQ-MSP-006 | 积分如何产生（订货 / 入库 / 延保建单 / 核销，或后台直接发放） | 业务 |
合计 4 条待确认，本次拆分**未新增、未关闭**。
> 主文件 10.2.11 是 PRF / MKT / MSP 三个模块合并的一节，上表只取 MSP 前缀的 4 行；另外 8 行分别归入 [4.12 经营业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)与 [4.13 营销与会员](./13-MKT-营销与会员.md#413-营销与会员)。三个模块的分片合计须等于主文件 10.2.11 的 12 行。
### 附-4 配图清单（主文件附录 C）
**本模块无配图** —— 主文件附录 C 无 4.14 节，磁盘上也没有任何 MSIP 相关截图。
**建议补充的材料**（按优先级）：
1. **MSIP 现状页面截图** —— 至少需要 兑换商品列表 / 兑换详情 / 兑换记录 / 积分余额与明细 四张，这是关闭 `TODO(REQ-MSP-002)` 的前提；
2. **积分获取路径的说明材料** —— 用于关闭 `TODO(REQ-MSP-006)`，决定本模块与采购 / 库存 / 延保 / 销售四个模块是否有联动；
3. **MSIP 的接口文档或 H5 地址** —— 用于关闭 `TODO(REQ-MSP-004)`。
补图后须同步更新三处：文档头部规模声明、附录 C 的来源分布表与本节清单、本文件头部信息表。
### 附-5 本次拆分新增发现
1. **本模块是 14 个模块里唯一没有任何页面材料的** —— 其余 13 个模块都有截图或设计稿可核对，本模块的 6 条需求全部来自业务口头确认。因此本次拆分**没有逐图核对环节**，新增的两条需求（[REQ-MSP-007](#4141-业务规则)、[REQ-MSP-008](#4141-业务规则)）都只涉及入口与口径，不涉及页面形态。
2. **发现了一个正文没记的现状入口** —— 除 ROOS 与 O2O 两处首页宫格外，**延保小程序的「其他小程序入口」四宫格里也有「积分兑换」一格**（见 [4.5.7](./05-WTY-延保.md#457-培训操作指引与服务支持)）。即现状共有**三个**入口，正文只写了两个。见 [REQ-MSP-007](#4141-业务规则)。
3. **附录 B 的单行写法会导致实现歧义** —— 「积分兑换」一行技工为 ❓，但 [REQ-MSP-003](#4141-业务规则) 已明确同店所有角色看到同一份余额。「查看」与「兑换」必须拆成两行，否则容易实现成技工连余额都看不到，与已定规则冲突。见「附-2」。
4. **`TODO(REQ-MSP-004)` 的影响面比 10.2.11 记录的更大** —— 它同时挂在三处：本模块的集成方式、[第 5 章主数据表](../Continental-Retail-APP-PRD.md#51-主数据来源)第 6 行的同步方式、[集成矩阵](../Continental-Retail-APP-PRD.md#72-集成矩阵)第 7 行。三处须一并更新，不能只改 4.14。
5. **积分兑换很可能涉及实物发放与物流** —— 「兑换商品」若是实物，则兑换记录须有收货地址、发货状态与物流单号，这会显著扩大本模块范围；若只兑权益（券、服务），范围小得多。这一点在 `TODO(REQ-MSP-002)` 澄清页面形态时须一并问清，否则排期估算会严重失真（正是风险 R1 所指）。