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

4.14 福利兑换（MSIP）

本文件是【福利兑换 MSP】模块需求的编辑入口。 主文件 ../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 章。

---

积分主体已定：积分挂在门店账下，不归属店员个人。 App 面向经销商，店长与技工都是门店的员工；积分是品牌方发给经销商的福利，因此切换门店时积分随门店上下文一起切换，同门店的店员看到同一份额度。这一条决定了本模块的权限模型与切店行为。

页面内容、积分产生规则与 MSIP 的集成方式仍待补，见 4.14.1。

业务目标 —— 品牌方以积分形式向经销商发放福利，门店用积分兑换商品或权益，作为对门店的激励手段

入口 —— 现状：ROOS / O2O 首页的「积分兑换」（见 2.7.2、2.7.3）；目标：宫格版「福利兑换」（见 4.2.5）或个人中心的积分资产卡

页面内容 —— 待确认 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）；同门店所有角色看到同一份额度

REQ-MSP-004 集成方式 —— MSIP 是否提供 API，还是只能以 Embedded H5 嵌入待确认 TODO(REQ-MSP-004)。若只能嵌 H5，则与提醒同为容器方案，集成矩阵需相应调整

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的现状截图）。整合后三处全部取消，收敛为 App 内的单一「福利兑换」入口；积分余额在个人中心的资产卡与福利兑换页两处展示时，必须同源同刷新时机，不得出现两个数

REQ-MSP-008 积分余额的口径与失效 —— ①积分余额随门店上下文切换而整体失效重取，不做跨门店缓存合并（依赖 REQ-MSP-003）；②余额展示须带数据口径时间，若 MSIP 为 H5 嵌入则口径时间由 MSIP 页面自行承载；③兑换成功后余额须立即回刷，不得依赖用户手动下拉

---

附：本模块归拢信息（来自主文件其它章节）

附-1 业务数据字典（主文件附录 A）

主文件附录 A 未收录本模块的字段清单 —— 附录 A 只有 A.1–A.9 九节，无福利兑换节。与本模块相关的只有第 5 章主数据表的一行：

#	类型	来源	同步方式	说明
6	积分主数据	MSIP	TODO(REQ-MSP-004)	见 4.14

以及集成矩阵的一行：

#	系统	涉及模块	集成方式	数据
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 明确「同门店所有角色看到同一份余额」——看得到是已定的，能不能兑才是待定的，两者必须拆成两行才不冲突。

附-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 经营业绩与 4.13 营销与会员。三个模块的分片合计须等于主文件 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、REQ-MSP-008）都只涉及入口与口径，不涉及页面形态。
2. 发现了一个正文没记的现状入口 —— 除 ROOS 与 O2O 两处首页宫格外，延保小程序的「其他小程序入口」四宫格里也有「积分兑换」一格（见 4.5.7）。即现状共有三个入口，正文只写了两个。见 REQ-MSP-007。
3. 附录 B 的单行写法会导致实现歧义 —— 「积分兑换」一行技工为 ❓，但 REQ-MSP-003 已明确同店所有角色看到同一份余额。「查看」与「兑换」必须拆成两行，否则容易实现成技工连余额都看不到，与已定规则冲突。见「附-2」。
4. TODO(REQ-MSP-004) 的影响面比 10.2.11 记录的更大 —— 它同时挂在三处：本模块的集成方式、第 5 章主数据表第 6 行的同步方式、集成矩阵第 7 行。三处须一并更新，不能只改 4.14。
5. 积分兑换很可能涉及实物发放与物流 —— 「兑换商品」若是实物，则兑换记录须有收货地址、发货状态与物流单号，这会显著扩大本模块范围；若只兑权益（券、服务），范围小得多。这一点在 TODO(REQ-MSP-002) 澄清页面形态时须一并问清，否则排期估算会严重失真（正是风险 R1 所指）。