conti-docs/prd/modules/10-FIN-财务与对账.md

# 4.10 财务与对账

> **本文件是【财务与对账 FIN】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.10 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。

| 项 | 值 |
| --- | --- |
| 模块码 | FIN |
| V1.0 章节 | 4.10 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 现状截图反推 |
| 现状承载系统 | O2O（收入 / 提现 / 结算单 / 银行账号）+ ROOS（采购对账单） |
| 需求条数 | 14（待确认 12，完成度 14%） |
| 本次新增待确认 | 7（REQ-FIN-008 ~ 014） |
| 配图 | 11 张（现状-O2O 10 / 现状-ROOS 1，**无设计稿**） |

模块概要

---

本节内容由 O2O 与 ROOS 的对账 / 提现 / 结算截图反推。**本模块没有任何设计稿** —— 11 张图全部是现状小程序，App 目标形态尚未出稿。

**业务目标** —— 让门店在 App 内看清「挣了多少、能提多少、什么时候到账、和厂商怎么对账」，解决[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销)与[痛点 2.5](../Continental-Retail-APP-PRD.md#25-数据经营分析)

**入口** —— 「我的」菜单 → 对账提现 / 对账单；宫格版导航中为一级 tab「账务对账」

**页面内容** —— 对账提现（可提现金额 + 收入 + 提现历史）、收入明细、服务结算单、结算单明细、采购对账单、银行账号绑定

**主流程**：

- 查看可提现金额 → 进入收入 / 提现历史核对 → **系统按工作日自动提现** → 到账（**门店不主动发起提现**，见 [REQ-FIN-008](#4106-业务规则)）
- 结算侧：按周期查看服务结算单 → 核对明细 → **在本月 7 号前确认结算单**（逾期自动确认，见 [REQ-FIN-012](#4106-业务规则)）
- 采购侧：按月查看对账单 → 核对汇总与明细

**权限规则** —— **建议限店长**（涉及资金）`TODO(REQ-FIN-001)`

**数据来源** —— O2O（O2O 收入、提现、服务结算单、银行账号）、ROOS（采购对账单）

## 4.10.1 对账提现

![现状-O2O 对账提现](../mini-program-images/O2O/对账提现.png)

**页面内容** —— O2O 对账提现首页，橙色头部为「¥0.00 / 可提现金额（元）」与一段说明更新时点的注解，下方是「收入 >」「提现历史 >」两个入口行与蓝色文字链「交易手续费说明」，**本截图为 ¥0.00 空态**。

**关键交互** —— ①点「收入」→ 进入[收入明细](#4102-收入明细)；②点「提现历史」→ 进入提现流水；③点「交易手续费说明」→ 弹出费率说明（见下图）。

**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵) 为 ✗，且 `TODO(REQ-FIN-001)` 关闭前一律按技工完全不可见实现，含深链拦截）。

**需求关联** —— [REQ-FIN-002](#4106-业务规则) 可提现金额口径、[REQ-FIN-006](#4106-业务规则) 手续费透明、[REQ-FIN-008](#4106-业务规则) 提现由系统自动发起

> **本页没有「提现」按钮。** V1.0 的 4.10 主流程写「查看可提现金额 → 进入收入/提现历史核对 → **发起提现** → 到账」，但页面上只有两个查看入口与一个说明链接，没有任何可以发起提现的控件。结合下一张手续费说明中「每个工作日 15:30 左右系统将自动发起提现，将账户余额全部提出」，可以确认：**提现是系统自动执行的，门店不主动发起**。上方主流程已据此改写，并新增 [REQ-FIN-008](#4106-业务规则)。

> 顶部注解揭示两条关键约束：① 提现金额 **T+1 且按工作日**更新；② 计入基数的是**已核销**订单货款 —— 这把[核销](./03-SAL-销售.md#434-核销)从一个操作动作提升为资金链路的关键节点。核销 → 可提现的具体计算口径 —— `TODO(REQ-FIN-002)`。

![现状-O2O 对账提现-交易手续费说明](../mini-program-images/O2O/对账提现-交易手续费说明.png)

**页面内容** —— 从底部弹出的「交易手续费说明」面板，按「小程序订单」「天猫/京东/拼多多订单」「抖音小店订单」「抖音团购」四段列出结算与费率规则，**最后一段被底部按钮遮挡，本图无法确认其内容**。

**关键交互** —— ①滚动查看各渠道规则；②点右上 ✕ 或底部「确认」→ 关闭。纯内容展示，无其它交互。

**可用角色** —— 店长 ✅；技工 ✗。

**需求关联** —— [REQ-FIN-006](#4106-业务规则) 手续费透明、[REQ-FIN-008](#4106-业务规则) 自动提现、[REQ-FIN-009](#4106-业务规则) 分渠道结算机制与费率

> 本图可辨认的规则全文如下，是 [REQ-FIN-009](#4106-业务规则) 的直接依据：
>
> - **小程序订单**：①每个工作日 15:30 左右系统自动发起提现，将账户余额**全部**提出；②提现在发起 30 分钟内到账；③平台收取营业收入的 **0.6%** 作为扣点。
> - **天猫 / 京东 / 拼多多订单**：①每月结算**两次**，货款打入门店的**支付宝账号**（在「店铺管理–收款信息」维护）；②手续费——天猫 **3.1%**、京东 **3.2%**、拼多多百亿补贴 **2%**、拼多多普通订单 **1%**（均按货款收入计）。
> - **抖音小店订单**：①每月结算**两次**，货款打入门店的**银行卡账号**；②手续费——普通订单 **2%**、达人带货订单 **4%**。
> - **抖音团购**：**内容被按钮遮挡，无法确认**，需补采截图。
>
> 由此得出一条 V1.0 完全未提及的结构性事实：**收款账户因渠道而异** —— 小程序走平台账户余额，天猫/京东/拼多多打**支付宝**，抖音小店打**银行卡**。也就是说 [4.10.5 银行账号](#4105-银行账号)那一页**只服务抖音小店**，而支付宝收款信息根本不在本模块，在「店铺管理」里。整合进 App 后这两处收款配置是否都要收进来，见 `TODO(REQ-FIN-009)`。

![现状-O2O 提现历史](../mini-program-images/O2O/提现历史.png)

**页面内容** —— 提现流水列表，顶部为一条说明到账异常处理的黄色提示条，每行是「提现申请成功」+ 时间戳 + 金额 + 到账状态，**本图为测试数据**（金额 0.01~0.04 元，状态只有「到账异常」与「到账中」，**没有一条成功到账**）。

**关键交互** —— ①上下滚动查看历史；②点「联系客服」路径由提示条文案引导，**本图未见可点的客服入口**。行本身**不可点击下钻**（无 `>` 或展开标识）。

**可用角色** —— 店长 ✅；技工 ✗。

**需求关联** —— [REQ-FIN-010](#4106-业务规则) 提现状态机与到账异常

> 本图给出三条信息：
>
> 1. **状态是两个维度**：左列「提现申请成功」是申请状态，右列「到账中 / 到账异常」是到账状态。App 内需要明确两者的组合关系与完整状态机。
> 2. **时间戳几乎全是 `15:00:2x`**，而[手续费说明](#4101-对账提现)写的是「每个工作日 **15:30** 左右」。**说明文案与实际执行时点不一致**，需确认以哪个为准 —— 门店会拿这句话对时间。
> 3. **2021 年的三条记录至今仍是「到账中」**，挂了四年多。「到账中」是否有超时兜底、是否应自动转为异常并退回资金，现状看不出来。已记入 [REQ-FIN-010](#4106-业务规则)。

## 4.10.2 收入明细

![现状-O2O 收入](../mini-program-images/O2O/收入.png)

**页面内容** —— 收入列表页，顶部为可横滑的渠道 tab、筛选行为月份 + 打款状态 + 橙色「**下载明细**」，其下是灰色汇总条与两行明细（各带渠道标、打款状态标与核销时间），**汇总与明细自洽**（24.50 × 2 = 49.00）。

**关键交互** —— ①横滑或点展开箭头 → 切换渠道 tab；②点月份 → 选择月份；③点「全部打款状态 ▾」→ 按打款状态过滤；④点「**下载明细**」→ 导出对账文件；⑤点明细行 → 进入收入详情（见下图）。

**可用角色** —— 店长 ✅；技工 ✗。

**需求关联** —— [REQ-FIN-005](#4106-业务规则) 金额一致性、[REQ-FIN-009](#4106-业务规则) 分渠道结算、[REQ-FIN-011](#4106-业务规则) 收入金额构成

> 两个需要处理的点：
>
> 1. **「下载明细」在 App 内如何落地** —— 小程序里导出一个文件，App 里则涉及下载目录、文件打开方式、iOS 的文件应用权限。这是一处必须给出交互定义的功能，已并入 [REQ-FIN-011](#4106-业务规则)。
> 2. **「零跑」标签不在任何一份已知的渠道清单里** —— 既不在[返利中心的 8 个渠道](./11-RBT-返利中心.md#4113-多维筛选)里，也不在[经营业绩的 7 个渠道](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)里。且本页把「天猫/京东/拼多多」合并成一个 tab，而返利中心是三个独立取值。渠道口径的全面冲突见 [REQ-FIN-009](#4106-业务规则)。

![现状-O2O 收入详情](../mini-program-images/O2O/收入详情.png)

**页面内容** —— 单笔收入的详情页，自上而下为订单信息（商品说明、订单号、流水号、支付渠道、打款状态）、金额构成（订单金额 +¥9.90 / **通道费 −¥0.79** / 货款收入 +¥9.11 / 总收入 +¥9.11）与 6 条备注，底部为橙色「查看订单详情」。

**关键交互** —— ①点打款状态旁的「查看」→ 下钻打款详情；②点「查看订单详情」→ 跳转对应[销售订单](./03-SAL-销售.md#435-线上订单管理)；③滚动阅读备注。

**可用角色** —— 店长 ✅；技工 ✗。

**需求关联** —— [REQ-FIN-005](#4106-业务规则) 金额一致性、[REQ-FIN-011](#4106-业务规则) 收入金额构成

> **金额构成可从本图直接读出**：订单金额 − 通道费 = 货款收入（9.90 − 0.79 = 9.11 ✓），总收入 = 货款收入 + 消费者补贴（本例补贴为 0）。
>
> 但**通道费与手续费对不上**：0.79 ÷ 9.90 ≈ **7.98%**，而[手续费说明](#4101-对账提现)里最高的费率也只有 4%。可见「通道费」是与平台手续费并列的另一项扣减（可能是支付通道费），两者的关系与是否会同时扣，需财务澄清 —— 已记入 [REQ-FIN-011](#4106-业务规则)。

> 6 条备注是**资金规则的正文**，必须在 App 内完整保留（同 [REQ-FIN-006](#4106-业务规则) 的精神）。其中三条尤其重要：
>
> - 「凡是使用**抖音 / 美团**抵用券的订单，券的面额扣除通道费后，将以货款形式打到银行卡」
> - 「**京东秒送**的货款收入会通过平台直接打款到门店进行结算」
> - 「**车点点**的货款收入会直接由车点点打款与门店进行结算，**本页面仅做展示**」
>
> 也就是说，有的渠道的钱根本不经过这套结算链路，本页只是展示。哪些渠道属于「仅展示」、在列表里如何标识，需要明确，否则门店会误以为这些钱也会自动到账。另注意备注里又出现了「美团」「车点点」两个此前未列入任何渠道清单的名字。

## 4.10.3 服务结算单

![现状-O2O 服务结算单](../mini-program-images/O2O/服务结算单.png)

**页面内容** —— 服务结算单页，顶部为结算渠道下拉与**跨月**日期区间「2024年9月–2024年11月」，中部是「¥0.00 / 结算金额」与「查看详细明细 >」，下方为结算单状态 / 开票方式 / 开票状态 / 打款状态四行加两条说明，**本图金额为 ¥0.00 且已是终态**。

**关键交互** —— ①点「全部结算渠道 ▾」→ 选择结算渠道（见下图）；②点日期区间 → 选择结算周期；③点「查看详细明细 >」→ 进入[结算单明细](#4103-服务结算单)；④**未确认时**该按钮为可点的「确认结算单」，确认后变为禁用的「结算单已确认」；⑤有异议时可点「重审结算单」（**本图为已确认态，该入口未出现，位置与形态无法确认**）。

**可用角色** —— 店长 ✅；技工 ✗。确认结算单是有财务效力的动作，即便 `TODO(REQ-FIN-001)` 最终对技工开放财务查看，确认动作也应限店长。

**需求关联** —— [REQ-FIN-012](#4106-业务规则) 结算单确认与重审

> **本图暴露一整套 V1.0 完全没写的业务流程**，两条说明原文如下：
>
> 1. 「此份结算单包含**天猫 / 京东pop / 小程序**渠道汇总金额，请您务必在**本月 7 号之前完成确认，否则系统将自动确认**。如您对结算单有异议，可点击**重审结算单**。」
> 2. 「在您确认结算单之前，请务必确认您已知晓自己的结算方式，如您需要修改结算方式，**请登录接单宝小程序进行修改**。」
>
> 由此得到三条必须成文的规则：**结算单需门店主动确认**、**7 号截止且逾期自动确认**、**有异议可重审**。已记为 [REQ-FIN-012](#4106-业务规则)。
>
> 另外第 2 条里的「请登录接单宝小程序进行修改」**在 App 内会自相矛盾** —— 整合的目的正是让门店不必再进小程序。该文案必须改写为 App 内路径，否则门店按提示跳出 App，整合价值受损。

![现状-O2O 服务结算单-筛选结算渠道](../mini-program-images/O2O/服务结算单-筛选结算渠道.png)

**页面内容** —— 「全部结算渠道」下拉展开态，**单选**（✓ 在「全部结算渠道」），取值 4 项：全部结算渠道 / **小程序服务单结算** / **天猫服务单结算** / **京东服务单结算**。

**关键交互** —— ①点任一项 → 立即生效并收起（无「确定」按钮）；②点遮罩 → 收起。

**可用角色** —— 店长 ✅；技工 ✗。

**需求关联** —— [REQ-FIN-009](#4106-业务规则) 渠道枚举

> **本图的渠道口径与同一页的说明文字都对不上**：下拉是「小程序 / 天猫 / 京东」三个服务单结算，而页面底部说明写的是「天猫 / **京东pop** / 小程序」。同一个页面里「京东」与「京东pop」两种写法并存，且两处都**没有拼多多**，而[收入页](#4102-收入明细)的 tab 却把拼多多与天猫、京东并列。见 [REQ-FIN-009](#4106-业务规则)。

![现状-O2O 结算单明细](../mini-program-images/O2O/结算单明细.png)

**页面内容** —— 结算单明细页，沿用上一页的渠道下拉与日期区间，下方是「**上周期更正结算(0)**」与「**本周期订单结算(0)**」两个**带计数的 tab**，**本截图为空态**故明细行的字段无法从本图确认。

**关键交互** —— ①点两个 tab → 切换明细类型，计数随筛选变化；②点「返回查看服务结算单」→ 回到上一页。

**可用角色** —— 店长 ✅；技工 ✗。

**需求关联** —— [REQ-FIN-013](#4106-业务规则) 上周期更正结算

> **「上周期更正结算」是一个 PRD 从未提及的概念** —— 上一结算周期的金额发生更正后，差额落在本期结算单里。这直接影响 [REQ-FIN-005](#4106-业务规则)「同一笔金额在不同页面必须一致」：同一笔业务在原周期与更正周期会出现两次，若不加以区分，门店会认为对账出错。已记为 [REQ-FIN-013](#4106-业务规则)。
>
> 另注意两个 tab 都带 `(N)` 计数，与[采购订单 tab 计数](./06-PUR-采购.md#469-验收标准)是同一类要求，接口需支持按类型返回计数。

## 4.10.4 采购对账单

**对账单**：在「我的」菜单下点击「对账单」，进入「对账单详情」，对账单**按月份**查看账单详情，汇总支出 / 收入金额，明细列表。

![现状-ROOS 对账单详情-采购对账单](../mini-program-images/ROOS/对账单详情-采购对账单.png)

**页面内容** —— ROOS「对账单详情」页，顶部为「**采购对账单 ∨**」下拉与账单单号搜索框，下方筛选行为月份与「支出 / 收入」两个汇总数，**本截图为空态**故明细行的字段无法从本图确认。

**关键交互** —— ①点「采购对账单 ∨」→ **切换对账单类型**；②输入账单单号 → 检索；③点月份 → 切换月份，两个汇总数随之变化；④点明细行 → 进入单据详情（本图为空态，无法确认是否可下钻）。

**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「采购对账单」为 ✗）。

**需求关联** —— [REQ-FIN-003](#4106-业务规则) 收支合并

> **「采购对账单 ∨」是可切换的下拉**，说明 ROOS 的对账单**不止采购一种**，还有其它类型 —— 但本图未展开，**其它类型无法确认**。[附录 A.8](../Continental-Retail-APP-PRD.md#a8-经营分析与财务) 第 1 条写的是「采购及**返利**对账单（马牌），来自 ROOS 与 F6」，返利对账单很可能就是下拉里的另一项。需补采下拉展开态的截图，并在 `TODO(REQ-FIN-003)` 一并厘清。

> **采购对账单（ROOS，付给厂商）与 O2O 对账提现（收厂商的钱）方向相反**，整合后是并列两个入口还是合成一张「资金总览」—— `TODO(REQ-FIN-003)`。本图显示采购对账单**自身同时含支出与收入两栏**，并非纯支出，合并方案设计时需注意。

## 4.10.5 银行账号

![现状-O2O 银行账号-企业账户](../mini-program-images/O2O/银行账号-企业账户.png)

**页面内容** —— 银行账号页的**企业账户**形态，右上角状态为「**已激活**」，字段区为企业全称、统一社会信用代码、银行卡预留手机号、绑定银行（**平安银行**）与脱敏后的账号，底部并排「修改手机号」「解绑银行卡」，**本图为测试数据**（企业全称「张二零」、预留手机号 `11111111111`）。

**关键交互** —— ①点「修改手机号」→ 需重新验证后修改；②点「解绑银行卡」→ 二次确认弹窗（见下图）。注销账户**无 App 内入口**，提示要求联系马牌客服。

**可用角色** —— 店长 🔸 受限（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵) 标为高风险，需二次验证 `TODO(REQ-FIN-004)`）；技工 ✗。

**需求关联** —— [REQ-FIN-004](#4106-业务规则) 账户绑定安全、[REQ-FIN-014](#4106-业务规则) 账户类型与状态

> 「温馨提示」两条原文：①「银行账户修改手机号、解绑银行卡**需要重新验证**，请勿频繁修改」；②「如需注销银行账户，请**联系马牌客服**」。
>
> 第 1 条**回答了 `TODO(REQ-FIN-004)` 的一半** —— 现状已经要求重新验证，所以「是否需要二次验证」不再是问题，剩下的只是**验证方式**（短信验证码 / 后台审核 / 其它）。该 TODO 可据此收窄。

![现状-O2O 银行账号-个人账户-解绑确认弹窗](../mini-program-images/O2O/银行账号-个人账户-解绑确认弹窗.png)

**页面内容** —— 同一页面的**个人账户**形态（字段改为姓名与身份证号码，状态同为「已激活」，**唯独银行卡预留手机号未脱敏**），其上叠加解绑二次确认弹窗，正文说明解绑后账户将降为**待激活**、需重新绑卡激活。

**关键交互** —— ①点「取消」→ 放弃；②点「确认」→ 解绑，账户转为「待激活」。**本弹窗未包含任何验证码或密码输入** —— 与「解绑需要重新验证」的提示是否在确认之后才触发，本图无法确认。

**可用角色** —— 店长 🔸；技工 ✗。

**需求关联** —— [REQ-FIN-004](#4106-业务规则) 账户绑定安全、[REQ-FIN-014](#4106-业务规则) 账户类型与状态

> 两张图合起来给出账户模型：**两种账户类型**（企业 = 企业全称 + 统一社会信用代码；个人 = 姓名 + 身份证号码）、**两种状态**（已激活 / 待激活），解绑即降为待激活，需重新绑卡才能恢复。已记为 [REQ-FIN-014](#4106-业务规则)。
>
> **脱敏口径不统一**：身份证号与银行账号都做了脱敏，而**银行卡预留手机号 `13419691597` 完整显示**。App 内须统一脱敏规则，见 `TODO(REQ-FIN-014)`。
>
> 另：[验收标准第 4 条](#4107-验收标准)要求「解绑后提现入口给出明确阻断提示」，而现状弹窗只说账户变为待激活，**没有提到会影响提现**。App 内需补上这层因果说明。

## 4.10.6 业务规则

**REQ-FIN-001 权限** —— 财务模块建议限店长可见 `TODO(REQ-FIN-001)`。确认结算单、绑定 / 解绑银行账号等有财务效力的动作，即便财务查看对技工开放也应单独限店长

**REQ-FIN-002 可提现金额口径** —— T+1 工作日 12:30 更新；基数为已核销订单货款；具体计算口径待定 `TODO(REQ-FIN-002)`

**REQ-FIN-003 收支合并** —— 采购对账单与 O2O 提现是否合成资金总览待定 `TODO(REQ-FIN-003)`。同时需确认 ROOS「对账单类型」下拉里除采购对账单外还有哪些类型（[附录 A.8](../Continental-Retail-APP-PRD.md#a8-经营分析与财务) 提到「采购及返利对账单」）

**REQ-FIN-004 账户绑定安全** —— 银行账号绑定 / 解绑 / 修改预留手机号**必须重新验证**（现状已如此要求）；具体验证方式（短信验证码 / 后台审核）待定 `TODO(REQ-FIN-004)`

**REQ-FIN-005 金额一致性** —— App 不做金额二次计算，全部以源系统返回值展示；不同页面同一笔金额必须一致。**跨周期更正的金额需可区分**，见 [REQ-FIN-013](#4106-业务规则)

**REQ-FIN-006 手续费透明** —— 交易手续费说明须在提现入口可达，且**分渠道的费率原文须完整保留**，不得摘要或省略

**REQ-FIN-007 与 CDMS 支付关系** —— 首页待办中的「CDMS 支付提醒」与本模块的关系待定 `TODO(REQ-FIN-007)`

**REQ-FIN-008 提现由系统自动发起** —— 小程序渠道的提现**由系统在每个工作日固定时点自动发起，将账户余额全部提出**，发起后 30 分钟内到账；**门店没有手动提现入口**。App 内不得出现「立即提现」类按钮，避免门店误以为需要手动操作。

> **待确认** `TODO(REQ-FIN-008)`：①说明文案写「15:30 左右」，而[提现历史](#4101-对账提现)的记录时间戳几乎全为 `15:00:2x`，实际时点以哪个为准；②天猫 / 京东 / 拼多多 / 抖音等非小程序渠道**没有自动提现**（按月结算两次直接打款），页面上的「可提现金额」是否只统计小程序渠道，需明确。

**REQ-FIN-009 分渠道结算机制与费率** —— 各渠道的结算周期、到账账户与费率互不相同，须按渠道分别落地：

| 渠道组 | 结算周期 | 到账账户 | 费率 |
| --- | --- | --- | --- |
| 小程序 | 每工作日自动提现，30 分钟内到账 | 平台账户余额 | 营业收入的 0.6% |
| 天猫 / 京东 / 拼多多 | 每月两次 | **支付宝账号**（店铺管理–收款信息） | 天猫 3.1%、京东 3.2%、拼多多百亿补贴 2%、拼多多普通订单 1% |
| 抖音小店 | 每月两次 | **银行卡账号** | 普通订单 2%、达人带货订单 4% |
| 抖音团购 | **截图被遮挡，未知** | 未知 | 未知 |

上表按货款收入计费。本模块的[银行账号页](#4105-银行账号)只服务抖音小店渠道；支付宝收款信息现状不在本模块，在「店铺管理」内维护。

> **待确认** `TODO(REQ-FIN-009)`：①「抖音团购」段落需补采截图后补全；②支付宝收款信息是否随本模块一并收进 App；③**渠道枚举必须统一** —— 现状在财务侧就有四套口径：收入页 tab（天猫/京东/拼多多合并 + 小程序 + 抖音小店 + 高德…，另有「零跑」标签）、手续费说明（四段分组）、结算渠道下拉（小程序 / 天猫 / 京东服务单结算，**无拼多多**）、收入详情备注（抖音 / 美团 / 京东秒送 / **车点点** / 零跑）；再加上[返利中心的 8 项](./11-RBT-返利中心.md#4113-多维筛选)与[经营业绩的 7 项](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)，全仓库至少六套。须收敛为一份[主数据](../Continental-Retail-APP-PRD.md#5-主数据)枚举。

**REQ-FIN-010 提现状态机与到账异常** —— 提现流水含两个状态维度：申请状态（提现申请成功）与到账状态（到账中 / 到账异常）。**到账异常后资金自动退回账户，可在下次提现时重新提走**，该提示须在提现历史页顶部常驻。

> **待确认** `TODO(REQ-FIN-010)`：①完整状态机与到账成功态的文案（现状截图中未出现成功态）；②「到账中」是否有超时兜底 —— 截图里 2021 年的记录至今仍停留在「到账中」，若无终态收敛，门店无法判断这笔钱的去向；③提示条中的「联系客服」是否需要做成可点入口。

**REQ-FIN-011 收入明细的金额构成与导出** —— 单笔收入的金额构成为「订单金额 − 通道费 = 货款收入」，「总收入 = 货款收入 + 消费者补贴」；收入类型现状可见「服务收入」与「货款收入」两类。收入详情页的备注是资金规则正文，须完整保留。列表页的「下载明细」需给出 App 内的落地方式（下载位置、文件格式、打开与分享路径）。

> **待确认** `TODO(REQ-FIN-011)`：①**通道费与平台手续费的关系** —— 截图中通道费 0.79 / 订单金额 9.90 ≈ 7.98%，与手续费说明里任何一档费率都对不上，两者是否会同时扣减需财务澄清；②备注中「车点点的货款收入……**本页面仅做展示**」意味着部分渠道的资金不走本链路，哪些渠道属于「仅展示」、列表中如何标识，需明确，否则门店会误判到账预期。

**REQ-FIN-012 结算单确认与重审** —— 服务结算单需门店主动确认：**每月 7 号前完成确认，逾期系统自动确认**；对结算单有异议可发起「重审结算单」。结算单含四个独立状态：结算单状态（待确认 / 已确认）、开票方式（自行开票 / 非自行开票）、开票状态（已开票 / …）、打款状态（已打款 / …）。

> **待确认** `TODO(REQ-FIN-012)`：①重审的发起条件、处理时效与结果回执；②开票方式的完整取值与切换路径 —— 现状提示「修改结算方式请登录接单宝小程序」，**该引导在 App 内必须改写为 App 内路径**，否则与整合目标冲突；③自动确认对门店的告知方式（临近 7 号是否需要提醒推送，与[提醒模块](./04-RMD-提醒.md#44-提醒)的关系）。

**REQ-FIN-013 上周期更正结算** —— 结算单明细分为「上周期更正结算」与「本周期订单结算」两类，各自带条数计数。跨周期更正的金额会落在本期结算单内，展示上必须与本期订单结算区分，避免门店重复计数。

> **待确认** `TODO(REQ-FIN-013)`：更正的产生原因（退款 / 核销撤销 / 平台调账）、对已确认结算单的追溯影响、以及更正金额是否计入本期的「结算金额」汇总。

**REQ-FIN-014 银行账号的账户类型、状态与脱敏** —— 银行账号支持两种类型：**企业账户**（企业全称 + 统一社会信用代码）与**个人账户**（姓名 + 身份证号码），共用「银行卡预留手机号 / 绑定银行 / 绑定银行账号」三个字段。账户状态为**已激活 / 待激活**；**解绑后账户降为待激活，需重新绑卡才能恢复**。注销账户无 App 内入口，需联系马牌客服。

> **待确认** `TODO(REQ-FIN-014)`：**脱敏口径需统一** —— 现状身份证号与银行账号已脱敏，而银行卡预留手机号完整显示。App 内三个字段的脱敏规则须一致并成文。

## 4.10.7 验收标准

1. 可提现金额页面明确标注更新时间与统计口径，不出现「金额已变但说明未变」的错位；
2. 收入明细合计与可提现金额可对上，差额部分（未到 T+1、手续费、通道费）有明确说明；
3. 技工无法通过任何路径进入财务模块（含深链）；
4. 银行账号解绑必须二次确认，且解绑后提现入口给出明确阻断提示；
5. 页面**不出现任何手动提现按钮**，自动提现的时点与规则在提现入口可达（[REQ-FIN-008](#4106-业务规则)）；
6. 手续费说明中各渠道的费率数值与源系统一致，抖音团购段落完整可见、不被按钮遮挡（[REQ-FIN-009](#4106-业务规则)）；
7. 结算单在未确认时可点「确认」，已确认后按钮置灰；临近 7 号自动确认前门店已被告知（[REQ-FIN-012](#4106-业务规则)）；
8. 结算单明细中「上周期更正结算」与「本周期订单结算」两类金额分列且各自计数正确（[REQ-FIN-013](#4106-业务规则)）；
9. App 内所有财务页面**不出现「请登录接单宝小程序」类引导**，全部改为 App 内路径（[REQ-FIN-012](#4106-业务规则)）。

> 第 2 条补入「通道费」，第 5~9 条为本次逐图核看后新增。

---

## 附：本模块归拢信息

> 以下内容从主文件的其它章节归拢而来，便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。

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

| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 对账单 | Mini Program Backend | HTTPS | 采购及返利对账单（马牌），来自 ROOS 与 F6 |
| 2 | 核销结果集 | Mini Program Backend | HTTPS | 门店核销收入（马牌） |
| 3 | 返利结果集 | Mini Program Backend | HTTPS | 返利余额、明细、规则、提现 |

财务模块数据集（摘自主文件[附录 A.8 经营分析与财务](../Continental-Retail-APP-PRD.md#a8-经营分析与财务)）。

**这张表严重不足以支撑本模块**，三点问题：

1. **A.8 名为「经营分析与财务」，却一条经营分析的数据集都没有**（三条全属财务 / 返利），[经营业绩与报表](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)模块因此在附录 A 中没有任何字段依据。
2. **第 3 条「返利结果集」属于[返利中心](./11-RBT-返利中心.md#411-返利中心)**，不是本模块的数据集；且该条把「提现」写进了返利，而现状提现在 O2O 财务侧，两者是不同链路。
3. 本模块 11 张截图涉及的**提现流水、收入明细、收入详情、服务结算单、结算单明细、银行账号**六类数据，A.8 一条都没有覆盖。

依据本次逐图核看，可确认的数据集如下，**供业务确认后写入附录 A，不作为已定稿依据**：

| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 可提现金额（金额 + 更新时点 + 口径说明） | O2O | HTTPS | T+1 工作日 12:30 更新，基数为已核销订单货款 |
| 2 | 交易手续费规则（分渠道结算周期 / 到账账户 / 费率） | O2O | HTTPS | 见 [REQ-FIN-009](#4106-业务规则)；抖音团购段落待补 |
| 3 | 提现流水（申请状态 / 到账状态 / 金额 / 时间） | O2O | HTTPS | 含「到账异常资金退回」规则 |
| 4 | 收入列表（渠道 / 月份 / 打款状态 / 单号 / 核销时间 / 金额 / 收入类型） | O2O | HTTPS | 支持导出明细文件 |
| 5 | 收入详情（订单金额 / 运费 / 通道费 / 货款收入 / 总收入 + 6 条资金备注） | O2O | HTTPS | 金额构成见 [REQ-FIN-011](#4106-业务规则) |
| 6 | 服务结算单（结算周期 / 结算金额 / 四个状态 / 确认与重审） | O2O | HTTPS | 7 号截止自动确认 |
| 7 | 结算单明细（上周期更正结算 / 本周期订单结算，各带计数） | O2O | HTTPS | 见 [REQ-FIN-013](#4106-业务规则) |
| 8 | 银行账号（账户类型 / 激活状态 / 主体信息 / 预留手机号 / 绑定银行与账号） | O2O | **敏感，需脱敏** | 含身份证号、统一社会信用代码、银行账号 |
| 9 | 采购对账单（月份 / 支出 / 收入 / 账单单号 / 明细） | ROOS | HTTPS | 对账单类型可切换，其它类型待确认 |

第 8 条含身份证号与银行账号，属个人敏感信息，须遵循[安全与合规](../Continental-Retail-APP-PRD.md#84-安全与合规)的处理要求，脱敏口径见 `TODO(REQ-FIN-014)`。

### 附-2 权限矩阵（主文件附录 B 本模块分行）

**图例**：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认

| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 对账提现 / 收入 / 结算单 | ✅ | ✗ | `TODO(REQ-FIN-001)` |
| **银行账号绑定 / 解绑** | 🔸 | ✗ | 高风险，需二次验证 `TODO(REQ-FIN-004)` |
| 采购对账单 | ✅ | ✗ | |

财务模块权限矩阵（摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)）

适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予（REQ-ACC-005）；**🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现**（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。

> 本次拆分建议为矩阵**补一行「确认 / 重审结算单」**（店长 🔸、技工 ✗）。确认结算单是一次性、不可逆、且逾期系统自动代确认的财务动作，与「查看结算单」的风险等级完全不同，不宜共用同一行，见 [REQ-FIN-012](#4106-业务规则)。

### 附-3 待确认项（主文件 10.2.10 的 FIN 分片 + 本次新增）

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-FIN-001 | 财务模块是否限店长 | 业务 |
| REQ-FIN-002 | 可提现金额的精确计算口径（核销 → 可提现） | 财务 |
| REQ-FIN-003 | 采购对账单与 O2O 提现是否合成「资金总览」；ROOS 对账单类型下拉还有哪些类型 | 产品 / 财务 |
| REQ-FIN-004 | 银行账号绑定 / 解绑的**二次验证方式**（现状已确认必须验证，只缺方式） | 安全 / 财务 |
| REQ-FIN-007 | 首页「CDMS 支付提醒」与财务模块的关系（主文件误标为 REQ-FIN-005，见 [4.10.6](#4106-业务规则)） | 架构 |
| **REQ-FIN-008** | 自动提现的实际时点（说明写 15:30、流水记录为 15:00）；非小程序渠道是否计入「可提现金额」 | 财务 |
| **REQ-FIN-009** | 抖音团购的结算规则（截图被遮挡）；支付宝收款信息是否收进 App；**渠道枚举统一** | 财务 / 主数据 |
| **REQ-FIN-010** | 提现完整状态机与成功态文案；「到账中」的超时兜底；客服入口是否可点 | 财务 |
| **REQ-FIN-011** | 通道费与平台手续费的关系（7.98% 与费率表对不上）；「仅展示」渠道的标识方式；「下载明细」在 App 内的落地 | 财务 / 产品 |
| **REQ-FIN-012** | 重审结算单的条件与时效；开票方式取值与 App 内修改路径；自动确认前的提醒方式 | 财务 / 产品 |
| **REQ-FIN-013** | 上周期更正结算的产生原因、追溯影响、是否计入本期汇总 | 财务 |
| **REQ-FIN-014** | 银行账号三个敏感字段的脱敏口径统一 | 安全 / 财务 |

财务模块待确认项，共 12 条（主文件 [10.2.10](../Continental-Retail-APP-PRD.md#10210-财务与返利fin--rbt) 的 FIN 分片原 5 条 + 本次新增 7 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.10，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 FIN 行（7 / 5 / 29% → 14 / 12 / 14%）与第 10.2 节总数。

> 主文件 10.2.10 是 FIN 与 RBT 合并的一节，本表只取 FIN 前缀的行；RBT 的 7 条见 [11-RBT-返利中心.md](./11-RBT-返利中心.md)。两边条目相加须与主文件该节总数一致。
>
> 新增的 7 条里，REQ-FIN-008、009、012、013、014 的**主体规则已由截图确认**，待确认的只是其中一两个细节（时点、遮挡段落、脱敏口径等）。它们计入待确认数是因为带有 TODO 标记，但实现风险显著低于 REQ-FIN-002、003 这类完全未定的条目。

### 附-4 配图清单（主文件附录 C 4.10 节）

| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 现状-O2O 对账提现（**¥0.00 空态**；T+1 工作日 12:30 更新口径；**页面无提现按钮**） | `../mini-program-images/O2O/对账提现.png` |
| 2 | 现状-O2O 交易手续费说明（**分渠道结算周期 / 到账账户 / 费率全文**；「抖音团购」段落**被底部按钮遮挡**） | `../mini-program-images/O2O/对账提现-交易手续费说明.png` |
| 3 | 现状-O2O 提现历史（**测试数据 0.01~0.04 元**；状态仅「到账异常 / 到账中」，**无成功态**；时间戳均为 15:00:2x） | `../mini-program-images/O2O/提现历史.png` |
| 4 | 现状-O2O 收入（渠道 tab + 月份 + 打款状态 + **下载明细**；汇总 +¥49.00 与两条 ¥24.50 自洽；含**「零跑」渠道标签**） | `../mini-program-images/O2O/收入.png` |
| 5 | 现状-O2O 收入详情（金额构成 9.90 − 0.79 = 9.11；**6 条资金规则备注**，含抖音/美团券、京东秒送、车点点「仅做展示」） | `../mini-program-images/O2O/收入详情.png` |
| 6 | 现状-O2O 服务结算单（**¥0.00 已确认终态**；四个独立状态；说明含**7 号前确认 / 逾期自动确认 / 可重审**） | `../mini-program-images/O2O/服务结算单.png` |
| 7 | 现状-O2O 服务结算单筛选结算渠道（单选 4 项：全部 / 小程序 / 天猫 / 京东服务单结算，**无拼多多**） | `../mini-program-images/O2O/服务结算单-筛选结算渠道.png` |
| 8 | 现状-O2O 结算单明细（**空态**；两个带计数 tab：**上周期更正结算(0) / 本周期订单结算(0)**） | `../mini-program-images/O2O/结算单明细.png` |
| 9 | 现状-ROOS 对账单详情采购对账单（**空态**；**「采购对账单 ∨」可切换类型**；支出 / 收入双汇总） | `../mini-program-images/ROOS/对账单详情-采购对账单.png` |
| 10 | 现状-O2O 银行账号企业账户（**测试数据**；已激活；企业全称 + 统一社会信用代码；提示「修改需重新验证」「注销联系客服」） | `../mini-program-images/O2O/银行账号-企业账户.png` |
| 11 | 现状-O2O 银行账号个人账户解绑弹窗（姓名 + 身份证号；**解绑后降为待激活**；**弹窗内无验证码输入**） | `../mini-program-images/O2O/银行账号-个人账户-解绑确认弹窗.png` |

财务模块配图清单，11 张（现状-O2O 10 / 现状-ROOS 1）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。

**本模块配图的三处硬缺口**：

- **完全没有设计稿。** 14 个模块中本模块是资金链路最长、状态最多的之一，却是[采购](./06-PUR-采购.md#46-采购)之外唯一一个关键页面全无 App 目标形态的模块。整合后的信息架构（收入 / 提现 / 结算单 / 对账单四条线如何组织）目前只能靠现状小程序推断。
- **金额全是 0 或测试值。** 11 张里 6 张是 ¥0.00 或空态，提现历史是 0.01~0.04 元的测试流水，银行账号是测试主体。**结算单明细行、对账单明细行、提现成功态的字段全部无法确认**。
- **两处被遮挡 / 未展开的内容直接卡着需求**：手续费说明的「抖音团购」段落被按钮压住（卡 `TODO(REQ-FIN-009)`），ROOS「采购对账单 ∨」下拉未展开（卡 `TODO(REQ-FIN-003)`）。这两张补采成本极低，建议优先。

### 附-5 本次拆分新增发现

逐张核看 11 张配图后，新增 **7 条编号需求**（REQ-FIN-008 ~ 014）、**修订 2 处既有内容**、发现 **1 处编号错位**，另记 **3 条无编号观察**。这是目前拆分的各模块中新增最多的一个 —— 原因是主文件 4.10 几乎只有图、没有正文：11 张图里有 8 张此前没有任何文字说明。

**新增需求**：

| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-FIN-008 | 提现由系统自动发起 | 对账提现页无提现按钮 + 手续费说明「每工作日 15:30 自动发起提现，全部提出」 |
| REQ-FIN-009 | 分渠道结算机制与费率 | 手续费说明全文：三套结算周期、三种到账账户、七个费率数值 |
| REQ-FIN-010 | 提现状态机与到账异常 | 提现历史的两维状态 + 「到账异常资金退回」提示条 + 2021 年记录仍「到账中」 |
| REQ-FIN-011 | 收入金额构成与导出 | 收入详情的五项金额构成 + 6 条资金备注 + 收入页「下载明细」按钮 |
| REQ-FIN-012 | 结算单确认与重审 | 服务结算单说明「7 号前确认，逾期自动确认，可重审」+ 四个独立状态 |
| REQ-FIN-013 | 上周期更正结算 | 结算单明细的两个带计数 tab |
| REQ-FIN-014 | 银行账号类型、状态与脱敏 | 企业 / 个人两套字段 + 已激活 / 待激活 + 三字段脱敏口径不一致 |

**修订的既有内容**：

1. **主流程「发起提现」改为「系统按工作日自动提现」** —— 门店没有手动提现入口，见 [REQ-FIN-008](#4106-业务规则)。主流程同时补入结算侧的「7 号前确认结算单」一条。
2. **`TODO(REQ-FIN-004)` 收窄** —— 现状已明确要求「修改手机号、解绑银行卡需要重新验证」，所以「是否需要二次验证」不再是待确认项，只剩**验证方式**待定。

**发现的编号错位**：REQ-FIN-007（与 CDMS 支付关系）挂着 `TODO(REQ-FIN-005)` 标记，主文件 10.2.10 对应行也用了 REQ-FIN-005 编号，但 REQ-FIN-005 是「金额一致性」且无待确认。回灌时两处一并改为 `TODO(REQ-FIN-007)`，**待确认条数不变**。这与[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)模块发现的 `TODO(REQ-MKT-004)` 错位是同一类问题，建议回灌时对全文的 TODO 标记与 10.2 编号做一次统一校验。

**无编号观察**（属现状材料问题，不新增需求）：

1. **说明文案与实际执行不一致** —— 手续费说明写「15:30 左右」，提现流水记录全是 `15:00:2x`。门店会拿这句话对时间，须校准。
2. **同一页内「京东」与「京东pop」两种写法并存**（服务结算单的下拉 vs 页面说明），且两处都没有拼多多，而收入页 tab 有。
3. **「请登录接单宝小程序进行修改」的引导在 App 内自相矛盾** —— 整合的目的正是消除跳出。该文案必须改写，已写入 [REQ-FIN-012](#4106-业务规则) 与[验收标准第 9 条](#4107-验收标准)。

另有一条跨模块的结构性问题需要在设计阶段统一解决：**渠道枚举在全仓库至少有六套口径**（本模块四套 + [返利中心 8 项](./11-RBT-返利中心.md#4113-多维筛选) + [经营业绩 7 项](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)），且各自还引入了对方没有的名字（零跑、车点点、美团、抖音团购轮胎）。渠道是贯穿销售、财务、返利、业绩四个模块的主数据，不统一将导致同一笔业务在四个模块归到不同渠道下，对账无从谈起。建议在[主数据](../Continental-Retail-APP-PRD.md#5-主数据)章节固化一份渠道枚举，四个模块共同引用。