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