Files
conti-docs/prd/modules/14-MSP-福利兑换.md

125 lines
10 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.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 所指)。