339 lines
31 KiB
Markdown
339 lines
31 KiB
Markdown
# 4.11 返利中心
|
||
|
||
> **本文件是【返利中心 RBT】模块需求的编辑入口。**
|
||
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.11 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
|
||
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
|
||
|
||
| 项 | 值 |
|
||
| --- | --- |
|
||
| 模块码 | RBT |
|
||
| V1.0 章节 | 4.11 |
|
||
| 描述粒度 | 6 维精简模板 |
|
||
| 需求依据 | 现状截图反推 |
|
||
| 现状承载系统 | O2O（返利核算）+ 延保后台（延保返利） |
|
||
| 需求条数 | 11（待确认 7，完成度 36%） |
|
||
| 本次新增待确认 | 4（REQ-RBT-007、008、010、011） |
|
||
| 配图 | 10 张（设计稿 1 / 现状-O2O 9） |
|
||
|
||
模块概要
|
||
|
||
---
|
||
|
||
返利分布在两侧：延保侧有延保返利，O2O 侧另有一套完全独立、维度更丰富的返利体系（9 张截图），设计稿为其单独出了页面。
|
||
|
||
**业务目标** —— 让门店随时看清「这单能拿多少返利、为什么是这个数、核算到哪一步了」，解决[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销)中返利不透明的问题
|
||
|
||
**入口** —— O2O 工具条「返利中心」；宫格版导航一级入口
|
||
|
||
**页面内容**：
|
||
|
||
- 双 Tab：**返利详情 / 返利核算**
|
||
- 顶部订单号搜索 + 四个筛选（渠道 / 品牌 / 标签 / 月份）—— **仅返利详情 Tab 有，切到返利核算后整个筛选区消失**（[REQ-RBT-010](#4115-业务规则)）
|
||
- 概览卡（补贴返利、核算后返利）+ 三项构成（消费者补贴、安装费用、抽奖红包返利），每项可点开调整情况
|
||
- 明细列表，按三项构成分组切换
|
||
|
||
**主流程** —— 选择月份与筛选 → 查看概览 → 按构成切换明细 → 展开单条查看构成与状态；另可切到「返利核算」查看季度核算的调整流水
|
||
|
||
**权限规则** —— 建议限店长 `TODO(REQ-RBT-001)`
|
||
|
||
**数据来源** —— O2O（返利核算）、延保后台（延保返利，见 [4.5.6](./05-WTY-延保.md#456-工作台返利与经营数据)）
|
||
|
||
## 4.11.1 目标形态
|
||
|
||
|
||
|
||
**页面内容** —— App 返利中心的目标形态，自上而下为订单号搜索框、「返利详情 / 返利核算」双 Tab、四个筛选、橙色汇总卡（返利补贴与核算后返利 + 三项构成，每项带 `ⓘ`）与「明细」区，**两张明细卡是同一份占位数据**，仅状态标签不同。
|
||
|
||
**关键交互** —— ①输入订单号 → 检索该单返利；②切换双 Tab；③点四个筛选任一项 → 展开取值（取值集合见 [4.11.3](#4113-多维筛选)）；④点三项构成上的 `ⓘ` → 弹出该项的调整情况（见 [4.11.4](#4114-返利构成说明)）；⑤点「消费者补贴 / 安装费用 / 抽奖红包返利」三个标签 → 切换下方明细分组；⑥点明细卡右侧 `∨` → 展开该条的返利构成。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`，关闭前按技工不可见实现。
|
||
|
||
**需求关联** —— [REQ-RBT-002](#4115-业务规则) 计算口径、[REQ-RBT-003](#4115-业务规则) 规则说明可达
|
||
|
||
> **本图的三个数值互不自洽，不可作为计算口径的依据**：返利补贴 ¥30.00、核算后返利 ¥38.00，而三项构成之和为 40 + 12.08 + 1.08 = **¥53.16** —— 与前两者都对不上。相比之下[现状返利详情](#4112-返利详情与返利核算)的一组数据恰好自洽（20 = 20 + 0 + 0）。设计稿此处是随手填的占位数值，`TODO(REQ-RBT-002)` 的公式应以现状数据反推，见 [REQ-RBT-002](#4115-业务规则)。
|
||
|
||
## 4.11.2 返利详情与返利核算
|
||
|
||
|
||
|
||
**页面内容** —— O2O 返利中心的「返利详情」Tab，结构与设计稿一致但筛选分成两行（渠道 / 品牌 / 标签一行，月份单独一行），「概览」区为补贴返利与核算后返利两张白卡加三项构成，「明细」区当前按「消费者补贴」分组、两条记录合计 **+¥20.00**。
|
||
|
||
**关键交互** —— ①输入订单号后需**点「搜索」按钮**才触发查询（非输入即搜）；②点三项构成旁的 `?` → 弹出调整情况；③点明细分组切换列表；④点明细行右侧 `∨` → 展开该条构成；⑤列表触底显示「已经到底啦！」。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-002](#4115-业务规则) 计算口径、[REQ-RBT-006](#4115-业务规则) 数据来源、[REQ-RBT-007](#4115-业务规则) 筛选取值
|
||
|
||
> **本图是推导计算口径的关键证据**，三层数值恰好闭合：明细合计（−40 + 60）= 消费者补贴（+20）= 三项构成之和（20 + 0 + 0）= 补贴返利（+20）= 核算后返利（+20，本月无核算调整）。据此可给出待业务确认的公式草案，见 [REQ-RBT-002](#4115-业务规则)。
|
||
|
||
> **明细行的字段与设计稿不一致**：现状每行含**数量「x1」**、条码后跟灰色**「撤回」**标签、**「最近记录时间」**前缀；设计稿则是状态标签「已完成」/「退款扣减」，无数量、无「最近记录时间」。两套字段需在设计定稿时合并，一并归入 [REQ-RBT-007](#4115-业务规则)。
|
||
|
||
|
||
|
||
**页面内容** —— 切到「返利核算」Tab 后的列表，**搜索框与四个筛选整行消失**，只剩双 Tab 与核算调整流水卡（每张含事由标题、「品牌｜渠道｜返利类型」三个维度标签、带正负的金额与时间戳）。
|
||
|
||
**关键交互** —— ①切换回「返利详情」→ 搜索与筛选区重新出现；②列表本身**无筛选、无搜索、无分页控件**，只能上下滚动。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。核算流水含考核扣款，敏感度高于返利详情，即便技工可见返利详情，本 Tab 是否一并开放需单独判断。
|
||
|
||
**需求关联** —— [REQ-RBT-010](#4115-业务规则) 核算 Tab 的筛选缺失、[REQ-RBT-011](#4115-业务规则) 返利类型集合
|
||
|
||
> 本图给出三条实质信息：
|
||
>
|
||
> 1. **返利核算是「季度」粒度的**（结合[抽奖红包返利说明](#4114-返利构成说明)中的「不参与季度核算」），而返利详情按**月**筛选。两个 Tab 的时间粒度不同，图中三条记录横跨 2023–2025，也确实不受月份筛选约束 —— 已记为 [REQ-RBT-010](#4115-业务规则)。
|
||
> 2. **「好评返利」不属于三项构成的任何一项**（消费者补贴 / 安装费用 / 抽奖红包返利），说明返利类型的完整集合比概览区展示的三项更大 —— 已记为 [REQ-RBT-011](#4115-业务规则)。
|
||
> 3. **「Q1补货率未达标 −¥1,000.00」证明返利核算包含考核扣款**，且考核指标是「补货率」—— 与[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)中「消费券额度随扫码入库与补货率累积」是**同一套门店考核体系**。App 内两处应引用同一份考核规则说明，避免门店在两个模块看到互相矛盾的解释。
|
||
|
||
> 事由标题「11」「导入增加11」明显是后台录入的测试文案。整合后该字段直接对门店展示，需明确其录入规范与字数上限，一并归入 [REQ-RBT-010](#4115-业务规则)。
|
||
|
||
## 4.11.3 多维筛选
|
||
|
||
|
||
|
||
**页面内容** —— 「全部渠道」下拉展开态，**单选**（当前 ✓ 在「全部渠道」），取值共 9 项：全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / **抖音团购轮胎**。
|
||
|
||
**关键交互** —— ①点任一渠道 → 立即收起下拉并按该渠道过滤（无「确定」按钮）；②再次点标题或点遮罩 → 收起。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
|
||
|
||
> **渠道主数据与经营业绩模块对不上**：本图为 8 个业务渠道，而[经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)记录的渠道清单为 7 个（小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎），**少了「抖音团购轮胎」**。渠道是跨模块共用的主数据，两处必须取自同一份枚举，见[主数据](../Continental-Retail-APP-PRD.md#5-主数据)。已记入 [REQ-RBT-007](#4115-业务规则)。
|
||
|
||
|
||
|
||
**页面内容** —— 「全部品牌」下拉展开态，**单选**（✓ 在「全部品牌」），取值 3 项：全部品牌 / **德国马牌** / 维京。
|
||
|
||
**关键交互** —— 同渠道下拉：点选即生效并收起。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
|
||
|
||
> **品牌名称在三处有三种写法**：本图下拉为「德国马牌 / 维京」，[返利核算](#4112-返利详情与返利核算)的标签为「马牌 / 维京」，[采购购物车](./06-PUR-采购.md#463-购物车与结算)分组为「德国马牌 / 维京轮胎」。App 内须统一，同样归入主数据口径。
|
||
|
||
|
||
|
||
**页面内容** —— 「标签」下拉展开态，与前两个筛选形态不同：提示「请选择标签（**可多选**）」，三个可点 chip「**撤回 / 异常 / 调整**」，下方另有独立的「确定」按钮。
|
||
|
||
**关键交互** —— ①点 chip → 切换选中态，可多选；②点「确定」→ 应用筛选并收起（与渠道 / 品牌的「点选即生效」不同）。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
|
||
|
||
> V1.0 原文把「标签」列为四个筛选之一，但**从未说明它的取值**。本图给出确定答案：标签 = **撤回 / 异常 / 调整**，且是多选。这三个值正是[消费者补贴调整情况](#4114-返利构成说明)弹窗里的三个调整分项 —— 标签筛选的本质是「按调整原因过滤明细」，而非商品或订单的标签。
|
||
|
||
|
||
|
||
**页面内容** —— 点月份后从底部弹出的年月滚轮选择器（左列年份、右列月份，底部「取消」与绿色「确定」），**为微信小程序原生 picker 样式**。
|
||
|
||
**关键交互** —— ①滚动年 / 月 → 预选；②点「确定」→ 应用；③点「取消」或遮罩 → 放弃。**只能选单个月，不支持区间**。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-007](#4115-业务规则) 筛选取值
|
||
|
||
> 两点须在 App 内改造：①绿色「确定」是微信原生控件样式，App 内应换成本项目设计系统的按钮；②年份可选范围（图中可滚到 2027 年，即**未来月份**）需要约束，选到无数据的未来月份只会得到空态。
|
||
|
||
## 4.11.4 返利构成说明
|
||
|
||
三项返利构成各自带独立的规则说明页，这些说明必须在 App 内完整保留 —— 它们是门店理解返利数额的唯一依据。
|
||
|
||
|
||
|
||
**页面内容** —— 点「消费者补贴 `?`」后的居中弹窗「消费者补贴调整情况」，一行汇总之下的框内是**发放 / 撤回 / 异常 / 调整**四个分项（本图各为 ¥0.00）。
|
||
|
||
**关键交互** —— ①点 ✕ 或遮罩 → 关闭。**弹窗内各分项不可再下钻**，是终点页。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-003](#4115-业务规则) 规则说明可达、[REQ-RBT-008](#4115-业务规则) 调整情况分项
|
||
|
||
|
||
|
||
**页面内容** —— 结构与上一张相同的「安装费用调整情况」弹窗，差别是分项**只有三个：发放 / 异常 / 调整 —— 没有「撤回」**。
|
||
|
||
**关键交互** —— 同上，仅 ✕ 关闭。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-008](#4115-业务规则) 调整情况分项
|
||
|
||
> **两项的分项数不同**：消费者补贴有「撤回」而安装费用没有。若这是有意的业务设计（安装费用一旦发放不可撤回），需成文；若是现状遗漏，App 内应补齐。同时[标签筛选](#4113-多维筛选)包含「撤回」，按安装费用分组时该标签将始终无结果 —— 交互上需要处理。已记为 [REQ-RBT-008](#4115-业务规则)。
|
||
|
||
|
||
|
||
**页面内容** —— 点「抽奖红包返利 `?`」后弹出的**纯文字提示框**（非前两张的数据弹窗），全文一句：「**抽奖红包返利，不参与季度核算，不会进行扣除**」。
|
||
|
||
**关键交互** —— 仅 ✕ 关闭，无交互。
|
||
|
||
**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-RBT-001)`。
|
||
|
||
**需求关联** —— [REQ-RBT-003](#4115-业务规则) 规则说明可达、[REQ-RBT-009](#4115-业务规则) 抽奖红包返利的核算例外
|
||
|
||
> 本图有两个值得注意的点：
|
||
>
|
||
> 1. **三项构成的说明形态不一致** —— 前两项是带金额分项的「调整情况」数据弹窗，第三项是无数据的纯文字规则说明。App 内是否统一为同一种形态，见 [REQ-RBT-008](#4115-业务规则)。
|
||
> 2. **这句话本身是一条实质业务规则**，且是全部 10 张图里唯一明确写出核算规则的地方：抽奖红包返利**不参与季度核算、不会被扣除**。它直接约束 [REQ-RBT-002](#4115-业务规则) 的公式 —— 「核算后返利」的调整只作用于消费者补贴与安装费用两项。已单独成文为 [REQ-RBT-009](#4115-业务规则)。
|
||
|
||
## 4.11.5 业务规则
|
||
|
||
**REQ-RBT-001 权限** —— 返利对技工是否可见待定 `TODO(REQ-RBT-001)`。「返利核算」Tab 含考核扣款流水，敏感度高于「返利详情」，两者是否同一档权限需一并判断
|
||
|
||
**REQ-RBT-002 计算口径** —— 返利补贴、核算后返利、三项构成的关系需给出公式说明 `TODO(REQ-RBT-002)`
|
||
|
||
> V1.1 依据[现状返利详情](#4112-返利详情与返利核算)与[三项说明弹窗](#4114-返利构成说明)反推出以下**公式草案，待财务确认后转为正式口径**：
|
||
>
|
||
> - 消费者补贴 = 发放 + 撤回 + 异常 + 调整
|
||
> - 安装费用 = 发放 + 异常 + 调整（**无撤回项**，见 [REQ-RBT-008](#4115-业务规则)）
|
||
> - 补贴返利 = 消费者补贴 + 安装费用 + 抽奖红包返利
|
||
> - 核算后返利 = 补贴返利 + 季度核算调整合计，其中**抽奖红包返利不参与核算调整**（[REQ-RBT-009](#4115-业务规则)）
|
||
> - 每项构成的明细列表合计 = 该项金额
|
||
>
|
||
> 现状截图的一组数据完全满足上述关系（明细 −40 + 60 = 消费者补贴 20 = 补贴返利 20 = 核算后返利 20）；[设计稿](#4111-目标形态)的 30 / 38 / 53.16 三者不自洽，**不作为口径依据**。另需财务明确：正负号约定（撤回 / 异常 为负值还是绝对值）、以及季度核算调整落在哪个月份的「核算后返利」上。
|
||
|
||
**REQ-RBT-003 规则说明可达** —— 三项构成的 `ⓘ` 说明必须在 App 内保留，不得外链小程序
|
||
|
||
**REQ-RBT-004 与延保返利合并** —— O2O 返利与[延保返利](./05-WTY-延保.md#456-工作台返利与经营数据)是否合并入口待定 `TODO(REQ-RBT-004)`
|
||
|
||
**REQ-RBT-005 退款扣减** —— 明细中的「退款扣减」状态需与[财务收入](./10-FIN-财务与对账.md#4102-收入明细)对齐，同一笔不得两侧不一致
|
||
|
||
**REQ-RBT-006 数据来源** —— 返利金额全部由 O2O 返回，App 不做二次计算（同 [REQ-FIN-005](./10-FIN-财务与对账.md#4106-业务规则)）
|
||
|
||
**REQ-RBT-007 筛选取值与明细字段** —— 四个筛选的取值与交互按现状固化：
|
||
|
||
- **渠道**：单选，点选即生效。取值为「全部渠道 / 小程序 / 天猫 / 京东秒送 / 京东 / 抖音小店 / 拼多多 / 高德轮胎 / 抖音团购轮胎」
|
||
- **品牌**：单选，点选即生效。取值为「全部品牌 / 德国马牌 / 维京」
|
||
- **标签**：**多选**，需点「确定」生效。取值为「撤回 / 异常 / 调整」，语义是按调整原因过滤明细
|
||
- **月份**：单月，年月滚轮 + 确定，不支持区间；可选年份范围需约束，避免选中无数据的未来月份
|
||
|
||
明细行字段需在现状（数量 x1 / 条码 + 撤回标签 / 最近记录时间）与设计稿（已完成 / 退款扣减状态标签）两套之间合并定稿。
|
||
|
||
> **待确认** `TODO(REQ-RBT-007)`：渠道枚举与[经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)记录的 7 项不一致（本模块多出「抖音团购轮胎」）；品牌名称在返利核算标签、品牌下拉、采购购物车三处分别写作「马牌」「德国马牌」「德国马牌 / 维京轮胎」。两者均为跨模块主数据，须统一到同一份枚举后再定稿。
|
||
|
||
**REQ-RBT-008 三项构成的调整情况** —— 消费者补贴与安装费用各自可点开「调整情况」弹窗，展示该项的分项金额；抽奖红包返利仅有一句文字说明。分项现状为：消费者补贴 = 发放 / 撤回 / 异常 / 调整（4 项），安装费用 = 发放 / 异常 / 调整（3 项，无撤回）。
|
||
|
||
> **待确认** `TODO(REQ-RBT-008)`：①安装费用无「撤回」是业务设计还是现状遗漏；②按安装费用分组时「撤回」标签必然无结果，交互上如何处理（置灰 / 隐藏 / 允许空结果）；③App 内三项的说明是否统一为同一种形态（现状两种：数据弹窗 + 纯文字提示）。
|
||
|
||
**REQ-RBT-009 抽奖红包返利的核算例外** —— **抽奖红包返利不参与季度核算，不会被扣除**。该规则须在 App 内对门店显式展示（沿用现状的说明入口），并作为 [REQ-RBT-002](#4115-业务规则) 公式的约束条件：季度核算的调整只作用于消费者补贴与安装费用两项
|
||
|
||
**REQ-RBT-010 返利核算 Tab 的独立性** —— 「返利核算」Tab 与「返利详情」Tab 的数据粒度不同：详情按**月**筛选，核算按**季度**产生，现状切到核算 Tab 后搜索框与四个筛选整行消失，列表不受月份约束。核算记录的结构为「事由标题 + 品牌｜渠道｜返利类型 + 金额 + 时间戳」。
|
||
|
||
> **待确认** `TODO(REQ-RBT-010)`：①核算 Tab 是否需要自己的筛选（按季度 / 品牌 / 渠道）与搜索；②事由标题由后台自由录入（现状可见「11」「导入增加11」等测试文案），直接对门店展示前需明确录入规范与字数上限；③核算调整最终如何回写到某个月份的「核算后返利」。
|
||
|
||
**REQ-RBT-011 返利类型集合** —— 概览区展示的三项构成（消费者补贴 / 安装费用 / 抽奖红包返利）**不是返利类型的全集**：返利核算记录中出现了「好评返利」，不属于其中任何一项。返利类型的完整枚举、每种类型是否计入补贴返利、是否参与季度核算，均待补 `TODO(REQ-RBT-011)`
|
||
|
||
## 4.11.6 验收标准
|
||
|
||
1. 四个筛选任意组合下，概览卡数值与明细列表合计一致；
|
||
2. 每一项返利构成都能点开对应的规则说明，且说明内容与现状小程序一致；
|
||
3. 「退款扣减」明细在返利中心与财务收入两处金额与符号一致；
|
||
4. 「补贴返利 = 三项构成之和」「各项明细合计 = 该项金额」两条恒等式在任意筛选组合下成立（[REQ-RBT-002](#4115-业务规则)）；
|
||
5. 切到「返利核算」Tab 时，页面不残留「返利详情」的筛选条件，返回时原筛选条件仍在（[REQ-RBT-010](#4115-业务规则)）；
|
||
6. 标签筛选支持多选并需点「确定」生效，渠道 / 品牌为单选点选即生效（[REQ-RBT-007](#4115-业务规则)）。
|
||
|
||
> 第 4、5、6 条为本次逐图核看后新增。
|
||
|
||
---
|
||
|
||
## 附：本模块归拢信息
|
||
|
||
> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
|
||
|
||
### 附-1 业务数据字典（主文件附录 A 无对应节）
|
||
|
||
**主文件[附录 A](../Continental-Retail-APP-PRD.md#附录-a-业务数据字典) 未收录返利中心的数据集清单** —— A.1~A.9 覆盖登录、首页、销售、提醒、采购、延保、门店管理、经营分析与财务、个人中心，**没有返利中心一节**。返利金额涉及门店实收，字段缺失会直接影响接口对齐，需业务补齐。
|
||
|
||
依据本次逐图核看，可确认的数据集如下，**供业务确认后写入附录 A，不作为已定稿依据**：
|
||
|
||
| # | 数据集 | 来源 | 安全 | 备注 |
|
||
| --- | --- | --- | --- | --- |
|
||
| 1 | 返利概览（补贴返利 / 核算后返利 / 三项构成） | O2O | HTTPS | 按渠道 + 品牌 + 标签 + 月份筛选 |
|
||
| 2 | 返利明细列表（商品名 + 规格 / 数量 / 条码 / 最近记录时间 / 金额 / 状态标签） | O2O | HTTPS | 按三项构成分组 |
|
||
| 3 | 调整情况（发放 / 撤回 / 异常 / 调整） | O2O | HTTPS | 消费者补贴 4 项、安装费用 3 项 |
|
||
| 4 | 返利核算流水（事由 / 品牌 / 渠道 / 返利类型 / 金额 / 时间） | O2O | HTTPS | 季度粒度，不受月份筛选约束 |
|
||
| 5 | 筛选主数据（渠道 8 项 / 品牌 2 项 / 标签 3 项） | O2O | HTTPS | **须与[主数据](../Continental-Retail-APP-PRD.md#5-主数据)统一**，见 `TODO(REQ-RBT-007)` |
|
||
| 6 | 延保返利 | 延保后台 | HTTPS | 是否并入本模块见 `TODO(REQ-RBT-004)` |
|
||
|
||
上表字段全部来自截图可见内容；返利类型的完整枚举尚未确认（`TODO(REQ-RBT-011)`）。
|
||
|
||
### 附-2 权限矩阵（主文件附录 B 本模块分行）
|
||
|
||
**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
|
||
|
||
| 功能 | 店长 | 技工 | 备注 / 待确认 |
|
||
| --- | --- | --- | --- |
|
||
| 返利详情 / 核算 | ✅ | ❓ | `TODO(REQ-RBT-001)` |
|
||
|
||
返利模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）
|
||
|
||
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
|
||
|
||
> 本次拆分建议**把该行拆成两行**：「返利详情」与「返利核算」。核算 Tab 含「Q1补货率未达标 −¥1,000.00」这类考核扣款流水，与门店经营考核直接相关，敏感度明显高于按订单看返利，两者不宜共用一个权限开关。
|
||
|
||
### 附-3 待确认项（主文件 10.2.10 的 RBT 分片 + 本次新增）
|
||
|
||
| 编号 | 待确认内容 | 建议决策方 |
|
||
| --- | --- | --- |
|
||
| REQ-RBT-001 | 返利对技工是否可见（详情与核算是否同一档） | 业务 |
|
||
| REQ-RBT-002 | **返利补贴、核算后返利、三项构成的计算公式**（本文件已给出待验证草案） | 财务 |
|
||
| REQ-RBT-004 | O2O 返利与延保返利是否合并入口 | 产品 |
|
||
| **REQ-RBT-007** | 渠道枚举与经营业绩模块不一致（多出「抖音团购轮胎」）；品牌名称三处三种写法；明细行字段两套合并 | 主数据 / 产品 |
|
||
| **REQ-RBT-008** | 安装费用无「撤回」分项是设计还是遗漏；「撤回」标签在安装费用分组下的空结果处理；三项说明形态是否统一 | 财务 / 产品 |
|
||
| **REQ-RBT-010** | 返利核算 Tab 是否需要独立筛选；事由标题的录入规范；核算调整回写到哪个月份 | 财务 / 产品 |
|
||
| **REQ-RBT-011** | 返利类型的完整枚举（现状可见「好评返利」不属三项构成任一项） | 业务 / 财务 |
|
||
|
||
返利模块待确认项，共 7 条（主文件 [10.2.10](../Continental-Retail-APP-PRD.md#10210-财务与返利fin--rbt) 的 RBT 分片原 3 条 + 本次新增 4 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.10，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 RBT 行（6 / 3 / 50% → 11 / 7 / 36%）与第 10.2 节总数。
|
||
|
||
> 主文件 10.2.10 是 FIN 与 RBT 合并的一节，本表只取 RBT 前缀的行；FIN 的 5 条见 [10-FIN-财务与对账.md](./10-FIN-财务与对账.md)。两边条目相加须与主文件该节总数一致。
|
||
|
||
### 附-4 配图清单（主文件附录 C 4.11 节）
|
||
|
||
| 序 | 说明 | 文件 |
|
||
| --- | --- | --- |
|
||
| 1 | 设计稿-返利中心（双 Tab + 四筛选 + 橙色汇总卡 + 三项构成 + 明细；**三个数值互不自洽，为占位数据**） | `../app-design-images/返利中心.png` |
|
||
| 2 | 现状-O2O 返利详情（概览 20 / 20 + 消费者补贴 20；明细 −40 与 +60 各一条，**数据自洽，是推导公式的关键证据**） | `../mini-program-images/O2O/返利中心-返利详情.png` |
|
||
| 3 | 现状-O2O 返利核算（**切换后筛选区整体消失**；三条核算流水含「Q1补货率未达标 −¥1,000.00」与「好评返利」） | `../mini-program-images/O2O/返利中心-返利核算.png` |
|
||
| 4 | 现状-O2O 筛选渠道（单选，8 个业务渠道 + 全部；**含经营业绩模块没有的「抖音团购轮胎」**） | `../mini-program-images/O2O/返利中心-筛选渠道.png` |
|
||
| 5 | 现状-O2O 筛选品牌（单选：全部 / 德国马牌 / 维京；背景为**空态**） | `../mini-program-images/O2O/返利中心-筛选品牌.png` |
|
||
| 6 | 现状-O2O 筛选标签（**多选 + 确定**；取值为撤回 / 异常 / 调整 —— 主文件原未定义该筛选取值） | `../mini-program-images/O2O/返利中心-筛选标签.png` |
|
||
| 7 | 现状-O2O 筛选月份（微信原生年月滚轮，单月不支持区间，可滚到未来年份；背景为**空态**） | `../mini-program-images/O2O/返利中心-筛选月份.png` |
|
||
| 8 | 现状-O2O 消费者补贴调整情况（弹窗，分项 **发放 / 撤回 / 异常 / 调整**；本图**全为 ¥0.00**） | `../mini-program-images/O2O/返利中心-消费者补贴调整情况.png` |
|
||
| 9 | 现状-O2O 安装费用调整情况（弹窗，分项 **发放 / 异常 / 调整，无撤回**；本图**全为 ¥0.00**） | `../mini-program-images/O2O/返利中心-安装费用调整情况.png` |
|
||
| 10 | 现状-O2O 抽奖红包返利说明（**纯文字提示**，非数据弹窗：「不参与季度核算，不会进行扣除」） | `../mini-program-images/O2O/返利中心-抽奖红包返利说明.png` |
|
||
|
||
返利模块配图清单，10 张（设计稿 1 / 现状-O2O 9）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
|
||
|
||
**配图材料的两处限制**：
|
||
|
||
- **第 4~10 张共 7 张的背景数据均为 ¥0.00 或「暂无数据」空态**。三项调整情况弹窗（第 8、9 张）虽然结构清晰，但全为零值，**分项之间的正负号约定无法从图中确认** —— 这正是 `TODO(REQ-RBT-002)` 公式草案里最需要财务澄清的一点。建议向有真实返利数据的门店账号补采这两张弹窗的截图。
|
||
- **明细行展开态（`∨`）没有截图**。展开后显示的单条返利构成是门店核对争议时的最终依据，目前没有任何页面材料。
|
||
|
||
### 附-5 本次拆分新增发现
|
||
|
||
逐张核看 10 张配图后，新增 **5 条编号需求**（REQ-RBT-007 ~ 011，其中 4 条带待确认）、另记 **4 条无编号观察**，并为悬置已久的 `TODO(REQ-RBT-002)` 给出了**可验证的公式草案**。
|
||
|
||
**新增需求**：
|
||
|
||
| 编号 | 名称 | 触发证据 |
|
||
| --- | --- | --- |
|
||
| REQ-RBT-007 | 筛选取值与明细字段 | 主文件列了四个筛选却从未写取值；本次逐图取全（渠道 8 / 品牌 2 / 标签 3），并发现渠道与品牌的跨模块主数据冲突 |
|
||
| REQ-RBT-008 | 三项构成的调整情况 | 消费者补贴 4 分项 vs 安装费用 3 分项（无撤回）；两项是数据弹窗、第三项是纯文字，形态不统一 |
|
||
| REQ-RBT-009 | 抽奖红包返利的核算例外 | 说明弹窗原文「不参与季度核算，不会进行扣除」—— 10 张图中唯一明写的核算规则 |
|
||
| REQ-RBT-010 | 返利核算 Tab 的独立性 | 切到核算 Tab 后筛选区整体消失；记录横跨 2023–2025，是季度粒度而非月度 |
|
||
| REQ-RBT-011 | 返利类型集合 | 核算记录出现「好评返利」，不属于概览区三项构成任何一项 |
|
||
|
||
**对 [REQ-RBT-002](#4115-业务规则) 的实质推进** —— 该条是主文件标注「门店最容易产生争议」的一项，此前只有一句「需要明确的计算公式说明」。本次由现状截图反推出五条恒等式草案（见 REQ-RBT-002 下方引用块），并证明**设计稿的数值不可用**（30 / 38 与三项之和 53.16 三者互不相等），把这条 TODO 从「无从下手」推进到「有草案待财务确认」。
|
||
|
||
**无编号观察**（属现状材料或设计稿状态问题，不新增需求）：
|
||
|
||
1. **「返利补贴」与「补贴返利」词序不同** —— 设计稿写「返利补贴」，现状写「补贴返利」，指同一个数。定稿时取其一。
|
||
2. **搜索提示语用词冲突** —— 现状写「请输入订单号搜索查看**收入详情**」，把返利叫作「收入详情」，与[财务与对账](./10-FIN-财务与对账.md#4102-收入明细)的「收入明细」撞名，容易让门店误以为是同一个东西。
|
||
3. **月份 picker 是微信原生控件**（绿色确定按钮），App 内需换成本项目设计系统；且年份可滚到未来（2027），需约束范围。
|
||
4. **返利核算的事由文案含测试数据**（「11」「导入增加11」），该字段直接对门店展示，需明确后台录入规范。
|
||
|
||
另有一条跨模块关联值得业务注意：**「Q1补货率未达标」的考核扣款与[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)中「消费券额度随补货率累积」出自同一套门店考核体系**。补货率既加消费券额度、又扣返利，门店在两个模块看到的规则说明必须同源，否则会产生解释冲突。建议在设计阶段确认是否需要一个统一的「门店考核规则」说明页，供两处共同引用。
|
||
|
||
另建议主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵) 把「返利详情 / 核算」**拆成两行** —— 核算 Tab 含考核扣款流水，不宜与按订单看返利共用同一个权限开关，见[附-2](#附-2-权限矩阵主文件附录-b-本模块分行)。
|