43 KiB
4.10 财务与对账
本文件是【财务与对账 FIN】模块需求的编辑入口。 主文件
../Continental-Retail-APP-PRD.md第 4.10 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。 两者不一致时以本文件为准。 目录约定见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与痛点 2.5
入口 —— 「我的」菜单 → 对账提现 / 对账单；宫格版导航中为一级 tab「账务对账」
页面内容 —— 对账提现（可提现金额 + 收入 + 提现历史）、收入明细、服务结算单、结算单明细、采购对账单、银行账号绑定
主流程：
- 查看可提现金额 → 进入收入 / 提现历史核对 → 系统按工作日自动提现 → 到账（门店不主动发起提现，见 REQ-FIN-008）
- 结算侧：按周期查看服务结算单 → 核对明细 → 在本月 7 号前确认结算单（逾期自动确认，见 REQ-FIN-012）
- 采购侧：按月查看对账单 → 核对汇总与明细
权限规则 —— 建议限店长（涉及资金）TODO(REQ-FIN-001)
数据来源 —— O2O（O2O 收入、提现、服务结算单、银行账号）、ROOS（采购对账单）
4.10.1 对账提现
页面内容 —— O2O 对账提现首页，橙色头部为「¥0.00 / 可提现金额（元）」与一段说明更新时点的注解，下方是「收入 >」「提现历史 >」两个入口行与蓝色文字链「交易手续费说明」，本截图为 ¥0.00 空态。
关键交互 —— ①点「收入」→ 进入收入明细；②点「提现历史」→ 进入提现流水；③点「交易手续费说明」→ 弹出费率说明（见下图）。
可用角色 —— 店长 ✅；技工 ✗（附录 B 为 ✗，且 TODO(REQ-FIN-001) 关闭前一律按技工完全不可见实现，含深链拦截）。
需求关联 —— REQ-FIN-002 可提现金额口径、REQ-FIN-006 手续费透明、REQ-FIN-008 提现由系统自动发起
本页没有「提现」按钮。 V1.0 的 4.10 主流程写「查看可提现金额 → 进入收入/提现历史核对 → 发起提现 → 到账」，但页面上只有两个查看入口与一个说明链接，没有任何可以发起提现的控件。结合下一张手续费说明中「每个工作日 15:30 左右系统将自动发起提现，将账户余额全部提出」，可以确认：提现是系统自动执行的，门店不主动发起。上方主流程已据此改写，并新增 REQ-FIN-008。
顶部注解揭示两条关键约束：① 提现金额 T+1 且按工作日更新；② 计入基数的是已核销订单货款 —— 这把核销从一个操作动作提升为资金链路的关键节点。核销 → 可提现的具体计算口径 ——
TODO(REQ-FIN-002)。
页面内容 —— 从底部弹出的「交易手续费说明」面板，按「小程序订单」「天猫/京东/拼多多订单」「抖音小店订单」「抖音团购」四段列出结算与费率规则，最后一段被底部按钮遮挡，本图无法确认其内容。
关键交互 —— ①滚动查看各渠道规则；②点右上 ✕ 或底部「确认」→ 关闭。纯内容展示，无其它交互。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-FIN-006 手续费透明、REQ-FIN-008 自动提现、REQ-FIN-009 分渠道结算机制与费率
本图可辨认的规则全文如下，是 REQ-FIN-009 的直接依据：
- 小程序订单：①每个工作日 15:30 左右系统自动发起提现，将账户余额全部提出；②提现在发起 30 分钟内到账；③平台收取营业收入的 0.6% 作为扣点。
- 天猫 / 京东 / 拼多多订单：①每月结算两次，货款打入门店的支付宝账号（在「店铺管理–收款信息」维护）；②手续费——天猫 3.1%、京东 3.2%、拼多多百亿补贴 2%、拼多多普通订单 1%（均按货款收入计）。
- 抖音小店订单：①每月结算两次，货款打入门店的银行卡账号；②手续费——普通订单 2%、达人带货订单 4%。
- 抖音团购：内容被按钮遮挡，无法确认，需补采截图。
由此得出一条 V1.0 完全未提及的结构性事实：收款账户因渠道而异 —— 小程序走平台账户余额，天猫/京东/拼多多打支付宝，抖音小店打银行卡。也就是说 4.10.5 银行账号那一页只服务抖音小店，而支付宝收款信息根本不在本模块，在「店铺管理」里。整合进 App 后这两处收款配置是否都要收进来，见
TODO(REQ-FIN-009)。
页面内容 —— 提现流水列表，顶部为一条说明到账异常处理的黄色提示条，每行是「提现申请成功」+ 时间戳 + 金额 + 到账状态，本图为测试数据（金额 0.01~0.04 元，状态只有「到账异常」与「到账中」，没有一条成功到账）。
关键交互 —— ①上下滚动查看历史；②点「联系客服」路径由提示条文案引导，本图未见可点的客服入口。行本身不可点击下钻（无 > 或展开标识）。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-FIN-010 提现状态机与到账异常
本图给出三条信息：
- 状态是两个维度：左列「提现申请成功」是申请状态，右列「到账中 / 到账异常」是到账状态。App 内需要明确两者的组合关系与完整状态机。
- 时间戳几乎全是
15:00:2x，而手续费说明写的是「每个工作日 15:30 左右」。说明文案与实际执行时点不一致，需确认以哪个为准 —— 门店会拿这句话对时间。- 2021 年的三条记录至今仍是「到账中」，挂了四年多。「到账中」是否有超时兜底、是否应自动转为异常并退回资金，现状看不出来。已记入 REQ-FIN-010。
4.10.2 收入明细
页面内容 —— 收入列表页，顶部为可横滑的渠道 tab、筛选行为月份 + 打款状态 + 橙色「下载明细」，其下是灰色汇总条与两行明细（各带渠道标、打款状态标与核销时间），汇总与明细自洽（24.50 × 2 = 49.00）。
关键交互 —— ①横滑或点展开箭头 → 切换渠道 tab；②点月份 → 选择月份；③点「全部打款状态 ▾」→ 按打款状态过滤；④点「下载明细」→ 导出对账文件；⑤点明细行 → 进入收入详情（见下图）。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-FIN-005 金额一致性、REQ-FIN-009 分渠道结算、REQ-FIN-011 收入金额构成
两个需要处理的点：
- 「下载明细」在 App 内如何落地 —— 小程序里导出一个文件，App 里则涉及下载目录、文件打开方式、iOS 的文件应用权限。这是一处必须给出交互定义的功能，已并入 REQ-FIN-011。
- 「零跑」标签不在任何一份已知的渠道清单里 —— 既不在返利中心的 8 个渠道里，也不在经营业绩的 7 个渠道里。且本页把「天猫/京东/拼多多」合并成一个 tab，而返利中心是三个独立取值。渠道口径的全面冲突见 REQ-FIN-009。
页面内容 —— 单笔收入的详情页，自上而下为订单信息（商品说明、订单号、流水号、支付渠道、打款状态）、金额构成（订单金额 +¥9.90 / 通道费 −¥0.79 / 货款收入 +¥9.11 / 总收入 +¥9.11）与 6 条备注，底部为橙色「查看订单详情」。
关键交互 —— ①点打款状态旁的「查看」→ 下钻打款详情；②点「查看订单详情」→ 跳转对应销售订单；③滚动阅读备注。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-FIN-005 金额一致性、REQ-FIN-011 收入金额构成
金额构成可从本图直接读出：订单金额 − 通道费 = 货款收入（9.90 − 0.79 = 9.11 ✓），总收入 = 货款收入 + 消费者补贴（本例补贴为 0）。
但通道费与手续费对不上：0.79 ÷ 9.90 ≈ 7.98%，而手续费说明里最高的费率也只有 4%。可见「通道费」是与平台手续费并列的另一项扣减（可能是支付通道费），两者的关系与是否会同时扣，需财务澄清 —— 已记入 REQ-FIN-011。
6 条备注是资金规则的正文，必须在 App 内完整保留（同 REQ-FIN-006 的精神）。其中三条尤其重要：
- 「凡是使用抖音 / 美团抵用券的订单，券的面额扣除通道费后，将以货款形式打到银行卡」
- 「京东秒送的货款收入会通过平台直接打款到门店进行结算」
- 「车点点的货款收入会直接由车点点打款与门店进行结算，本页面仅做展示」
也就是说，有的渠道的钱根本不经过这套结算链路，本页只是展示。哪些渠道属于「仅展示」、在列表里如何标识，需要明确，否则门店会误以为这些钱也会自动到账。另注意备注里又出现了「美团」「车点点」两个此前未列入任何渠道清单的名字。
4.10.3 服务结算单
页面内容 —— 服务结算单页，顶部为结算渠道下拉与跨月日期区间「2024年9月–2024年11月」，中部是「¥0.00 / 结算金额」与「查看详细明细 >」，下方为结算单状态 / 开票方式 / 开票状态 / 打款状态四行加两条说明，本图金额为 ¥0.00 且已是终态。
关键交互 —— ①点「全部结算渠道 ▾」→ 选择结算渠道（见下图）；②点日期区间 → 选择结算周期；③点「查看详细明细 >」→ 进入结算单明细；④未确认时该按钮为可点的「确认结算单」，确认后变为禁用的「结算单已确认」；⑤有异议时可点「重审结算单」（本图为已确认态，该入口未出现，位置与形态无法确认）。
可用角色 —— 店长 ✅；技工 ✗。确认结算单是有财务效力的动作，即便 TODO(REQ-FIN-001) 最终对技工开放财务查看，确认动作也应限店长。
需求关联 —— REQ-FIN-012 结算单确认与重审
本图暴露一整套 V1.0 完全没写的业务流程，两条说明原文如下：
- 「此份结算单包含天猫 / 京东pop / 小程序渠道汇总金额，请您务必在本月 7 号之前完成确认，否则系统将自动确认。如您对结算单有异议，可点击重审结算单。」
- 「在您确认结算单之前，请务必确认您已知晓自己的结算方式，如您需要修改结算方式，请登录接单宝小程序进行修改。」
由此得到三条必须成文的规则：结算单需门店主动确认、7 号截止且逾期自动确认、有异议可重审。已记为 REQ-FIN-012。
另外第 2 条里的「请登录接单宝小程序进行修改」在 App 内会自相矛盾 —— 整合的目的正是让门店不必再进小程序。该文案必须改写为 App 内路径，否则门店按提示跳出 App，整合价值受损。
页面内容 —— 「全部结算渠道」下拉展开态，单选（✓ 在「全部结算渠道」），取值 4 项：全部结算渠道 / 小程序服务单结算 / 天猫服务单结算 / 京东服务单结算。
关键交互 —— ①点任一项 → 立即生效并收起（无「确定」按钮）；②点遮罩 → 收起。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-FIN-009 渠道枚举
本图的渠道口径与同一页的说明文字都对不上：下拉是「小程序 / 天猫 / 京东」三个服务单结算，而页面底部说明写的是「天猫 / 京东pop / 小程序」。同一个页面里「京东」与「京东pop」两种写法并存，且两处都没有拼多多，而收入页的 tab 却把拼多多与天猫、京东并列。见 REQ-FIN-009。
页面内容 —— 结算单明细页，沿用上一页的渠道下拉与日期区间，下方是「上周期更正结算(0)」与「本周期订单结算(0)」两个带计数的 tab，本截图为空态故明细行的字段无法从本图确认。
关键交互 —— ①点两个 tab → 切换明细类型，计数随筛选变化；②点「返回查看服务结算单」→ 回到上一页。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-FIN-013 上周期更正结算
「上周期更正结算」是一个 PRD 从未提及的概念 —— 上一结算周期的金额发生更正后，差额落在本期结算单里。这直接影响 REQ-FIN-005「同一笔金额在不同页面必须一致」：同一笔业务在原周期与更正周期会出现两次，若不加以区分，门店会认为对账出错。已记为 REQ-FIN-013。
另注意两个 tab 都带
(N)计数，与采购订单 tab 计数是同一类要求，接口需支持按类型返回计数。
4.10.4 采购对账单
对账单：在「我的」菜单下点击「对账单」，进入「对账单详情」，对账单按月份查看账单详情，汇总支出 / 收入金额，明细列表。
页面内容 —— ROOS「对账单详情」页，顶部为「采购对账单 ∨」下拉与账单单号搜索框，下方筛选行为月份与「支出 / 收入」两个汇总数，本截图为空态故明细行的字段无法从本图确认。
关键交互 —— ①点「采购对账单 ∨」→ 切换对账单类型；②输入账单单号 → 检索；③点月份 → 切换月份，两个汇总数随之变化；④点明细行 → 进入单据详情（本图为空态，无法确认是否可下钻）。
可用角色 —— 店长 ✅；技工 ✗（附录 B「采购对账单」为 ✗）。
需求关联 —— REQ-FIN-003 收支合并
「采购对账单 ∨」是可切换的下拉，说明 ROOS 的对账单不止采购一种，还有其它类型 —— 但本图未展开，其它类型无法确认。附录 A.8 第 1 条写的是「采购及返利对账单（马牌），来自 ROOS 与 F6」，返利对账单很可能就是下拉里的另一项。需补采下拉展开态的截图，并在
TODO(REQ-FIN-003)一并厘清。
采购对账单（ROOS，付给厂商）与 O2O 对账提现（收厂商的钱）方向相反，整合后是并列两个入口还是合成一张「资金总览」——
TODO(REQ-FIN-003)。本图显示采购对账单自身同时含支出与收入两栏，并非纯支出，合并方案设计时需注意。
4.10.5 银行账号
页面内容 —— 银行账号页的企业账户形态，右上角状态为「已激活」，字段区为企业全称、统一社会信用代码、银行卡预留手机号、绑定银行（平安银行）与脱敏后的账号，底部并排「修改手机号」「解绑银行卡」，本图为测试数据（企业全称「张二零」、预留手机号 11111111111）。
关键交互 —— ①点「修改手机号」→ 需重新验证后修改；②点「解绑银行卡」→ 二次确认弹窗（见下图）。注销账户无 App 内入口，提示要求联系马牌客服。
可用角色 —— 店长 🔸 受限（附录 B 标为高风险，需二次验证 TODO(REQ-FIN-004)）；技工 ✗。
需求关联 —— REQ-FIN-004 账户绑定安全、REQ-FIN-014 账户类型与状态
「温馨提示」两条原文：①「银行账户修改手机号、解绑银行卡需要重新验证，请勿频繁修改」；②「如需注销银行账户，请联系马牌客服」。
第 1 条回答了
TODO(REQ-FIN-004)的一半 —— 现状已经要求重新验证，所以「是否需要二次验证」不再是问题，剩下的只是验证方式（短信验证码 / 后台审核 / 其它）。该 TODO 可据此收窄。
页面内容 —— 同一页面的个人账户形态（字段改为姓名与身份证号码，状态同为「已激活」，唯独银行卡预留手机号未脱敏），其上叠加解绑二次确认弹窗，正文说明解绑后账户将降为待激活、需重新绑卡激活。
关键交互 —— ①点「取消」→ 放弃；②点「确认」→ 解绑，账户转为「待激活」。本弹窗未包含任何验证码或密码输入 —— 与「解绑需要重新验证」的提示是否在确认之后才触发，本图无法确认。
可用角色 —— 店长 🔸；技工 ✗。
需求关联 —— REQ-FIN-004 账户绑定安全、REQ-FIN-014 账户类型与状态
两张图合起来给出账户模型：两种账户类型（企业 = 企业全称 + 统一社会信用代码；个人 = 姓名 + 身份证号码）、两种状态（已激活 / 待激活），解绑即降为待激活，需重新绑卡才能恢复。已记为 REQ-FIN-014。
脱敏口径不统一：身份证号与银行账号都做了脱敏，而银行卡预留手机号
13419691597完整显示。App 内须统一脱敏规则，见TODO(REQ-FIN-014)。另：验收标准第 4 条要求「解绑后提现入口给出明确阻断提示」，而现状弹窗只说账户变为待激活，没有提到会影响提现。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 提到「采购及返利对账单」）
REQ-FIN-004 账户绑定安全 —— 银行账号绑定 / 解绑 / 修改预留手机号必须重新验证（现状已如此要求）；具体验证方式（短信验证码 / 后台审核）待定 TODO(REQ-FIN-004)
REQ-FIN-005 金额一致性 —— App 不做金额二次计算，全部以源系统返回值展示；不同页面同一笔金额必须一致。跨周期更正的金额需可区分，见 REQ-FIN-013
REQ-FIN-006 手续费透明 —— 交易手续费说明须在提现入口可达，且分渠道的费率原文须完整保留，不得摘要或省略
REQ-FIN-007 与 CDMS 支付关系 —— 首页待办中的「CDMS 支付提醒」与本模块的关系待定 TODO(REQ-FIN-007)
REQ-FIN-008 提现由系统自动发起 —— 小程序渠道的提现由系统在每个工作日固定时点自动发起，将账户余额全部提出，发起后 30 分钟内到账；门店没有手动提现入口。App 内不得出现「立即提现」类按钮，避免门店误以为需要手动操作。
待确认
TODO(REQ-FIN-008)：①说明文案写「15:30 左右」，而提现历史的记录时间戳几乎全为15:00:2x，实际时点以哪个为准；②天猫 / 京东 / 拼多多 / 抖音等非小程序渠道没有自动提现（按月结算两次直接打款），页面上的「可提现金额」是否只统计小程序渠道，需明确。
REQ-FIN-009 分渠道结算机制与费率 —— 各渠道的结算周期、到账账户与费率互不相同，须按渠道分别落地：
| 渠道组 | 结算周期 | 到账账户 | 费率 |
|---|---|---|---|
| 小程序 | 每工作日自动提现，30 分钟内到账 | 平台账户余额 | 营业收入的 0.6% |
| 天猫 / 京东 / 拼多多 | 每月两次 | 支付宝账号（店铺管理–收款信息） | 天猫 3.1%、京东 3.2%、拼多多百亿补贴 2%、拼多多普通订单 1% |
| 抖音小店 | 每月两次 | 银行卡账号 | 普通订单 2%、达人带货订单 4% |
| 抖音团购 | 截图被遮挡，未知 | 未知 | 未知 |
上表按货款收入计费。本模块的银行账号页只服务抖音小店渠道；支付宝收款信息现状不在本模块，在「店铺管理」内维护。
待确认
TODO(REQ-FIN-009)：①「抖音团购」段落需补采截图后补全；②支付宝收款信息是否随本模块一并收进 App；③渠道枚举必须统一 —— 现状在财务侧就有四套口径：收入页 tab（天猫/京东/拼多多合并 + 小程序 + 抖音小店 + 高德…，另有「零跑」标签）、手续费说明（四段分组）、结算渠道下拉（小程序 / 天猫 / 京东服务单结算，无拼多多）、收入详情备注（抖音 / 美团 / 京东秒送 / 车点点 / 零跑）；再加上返利中心的 8 项与经营业绩的 7 项，全仓库至少六套。须收敛为一份主数据枚举。
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 号是否需要提醒推送，与提醒模块的关系）。
REQ-FIN-013 上周期更正结算 —— 结算单明细分为「上周期更正结算」与「本周期订单结算」两类，各自带条数计数。跨周期更正的金额会落在本期结算单内，展示上必须与本期订单结算区分，避免门店重复计数。
待确认
TODO(REQ-FIN-013)：更正的产生原因（退款 / 核销撤销 / 平台调账）、对已确认结算单的追溯影响、以及更正金额是否计入本期的「结算金额」汇总。
REQ-FIN-014 银行账号的账户类型、状态与脱敏 —— 银行账号支持两种类型：企业账户（企业全称 + 统一社会信用代码）与个人账户（姓名 + 身份证号码），共用「银行卡预留手机号 / 绑定银行 / 绑定银行账号」三个字段。账户状态为已激活 / 待激活；解绑后账户降为待激活，需重新绑卡才能恢复。注销账户无 App 内入口，需联系马牌客服。
待确认
TODO(REQ-FIN-014)：脱敏口径需统一 —— 现状身份证号与银行账号已脱敏，而银行卡预留手机号完整显示。App 内三个字段的脱敏规则须一致并成文。
4.10.7 验收标准
- 可提现金额页面明确标注更新时间与统计口径，不出现「金额已变但说明未变」的错位；
- 收入明细合计与可提现金额可对上，差额部分（未到 T+1、手续费、通道费）有明确说明；
- 技工无法通过任何路径进入财务模块（含深链）；
- 银行账号解绑必须二次确认，且解绑后提现入口给出明确阻断提示；
- 页面不出现任何手动提现按钮，自动提现的时点与规则在提现入口可达（REQ-FIN-008）；
- 手续费说明中各渠道的费率数值与源系统一致，抖音团购段落完整可见、不被按钮遮挡（REQ-FIN-009）；
- 结算单在未确认时可点「确认」，已确认后按钮置灰；临近 7 号自动确认前门店已被告知（REQ-FIN-012）；
- 结算单明细中「上周期更正结算」与「本周期订单结算」两类金额分列且各自计数正确（REQ-FIN-013）；
- App 内所有财务页面不出现「请登录接单宝小程序」类引导，全部改为 App 内路径（REQ-FIN-012）。
第 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 经营分析与财务）。
这张表严重不足以支撑本模块，三点问题：
- A.8 名为「经营分析与财务」，却一条经营分析的数据集都没有（三条全属财务 / 返利），经营业绩与报表模块因此在附录 A 中没有任何字段依据。
- 第 3 条「返利结果集」属于返利中心，不是本模块的数据集；且该条把「提现」写进了返利，而现状提现在 O2O 财务侧，两者是不同链路。
- 本模块 11 张截图涉及的提现流水、收入明细、收入详情、服务结算单、结算单明细、银行账号六类数据，A.8 一条都没有覆盖。
依据本次逐图核看，可确认的数据集如下，供业务确认后写入附录 A，不作为已定稿依据：
| # | 数据集 | 来源 | 安全 | 备注 |
|---|---|---|---|---|
| 1 | 可提现金额（金额 + 更新时点 + 口径说明） | O2O | HTTPS | T+1 工作日 12:30 更新，基数为已核销订单货款 |
| 2 | 交易手续费规则（分渠道结算周期 / 到账账户 / 费率） | O2O | HTTPS | 见 REQ-FIN-009；抖音团购段落待补 |
| 3 | 提现流水（申请状态 / 到账状态 / 金额 / 时间） | O2O | HTTPS | 含「到账异常资金退回」规则 |
| 4 | 收入列表（渠道 / 月份 / 打款状态 / 单号 / 核销时间 / 金额 / 收入类型） | O2O | HTTPS | 支持导出明细文件 |
| 5 | 收入详情（订单金额 / 运费 / 通道费 / 货款收入 / 总收入 + 6 条资金备注） | O2O | HTTPS | 金额构成见 REQ-FIN-011 |
| 6 | 服务结算单（结算周期 / 结算金额 / 四个状态 / 确认与重审） | O2O | HTTPS | 7 号截止自动确认 |
| 7 | 结算单明细（上周期更正结算 / 本周期订单结算，各带计数） | O2O | HTTPS | 见 REQ-FIN-013 |
| 8 | 银行账号（账户类型 / 激活状态 / 主体信息 / 预留手机号 / 绑定银行与账号） | O2O | 敏感，需脱敏 | 含身份证号、统一社会信用代码、银行账号 |
| 9 | 采购对账单（月份 / 支出 / 收入 / 账单单号 / 明细） | ROOS | HTTPS | 对账单类型可切换，其它类型待确认 |
第 8 条含身份证号与银行账号，属个人敏感信息，须遵循安全与合规的处理要求，脱敏口径见 TODO(REQ-FIN-014)。
附-2 权限矩阵（主文件附录 B 本模块分行）
图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
|---|---|---|---|
| 对账提现 / 收入 / 结算单 | ✅ | ✗ | TODO(REQ-FIN-001) |
| 银行账号绑定 / 解绑 | 🔸 | ✗ | 高风险，需二次验证 TODO(REQ-FIN-004) |
| 采购对账单 | ✅ | ✗ |
财务模块权限矩阵（摘自主文件附录 B）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经人员管理「可用系统」授予（REQ-ACC-005）；🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。
本次拆分建议为矩阵补一行「确认 / 重审结算单」（店长 🔸、技工 ✗）。确认结算单是一次性、不可逆、且逾期系统自动代确认的财务动作，与「查看结算单」的风险等级完全不同，不宜共用同一行，见 REQ-FIN-012。
附-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） | 架构 |
| 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 的 FIN 分片原 5 条 + 本次新增 7 条）。加粗编号为本次拆分新增，回灌时需一并写入主文件 10.2.10，并同步附录 D.2 的 FIN 行（7 / 5 / 29% → 14 / 12 / 14%）与第 10.2 节总数。
主文件 10.2.10 是 FIN 与 RBT 合并的一节，本表只取 FIN 前缀的行；RBT 的 7 条见 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已按实际截图内容补充，主文件附录 C 回灌时应一并更新。
本模块配图的三处硬缺口：
- 完全没有设计稿。 14 个模块中本模块是资金链路最长、状态最多的之一，却是采购之外唯一一个关键页面全无 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 | 银行账号类型、状态与脱敏 | 企业 / 个人两套字段 + 已激活 / 待激活 + 三字段脱敏口径不一致 |
修订的既有内容：
- 主流程「发起提现」改为「系统按工作日自动提现」 —— 门店没有手动提现入口，见 REQ-FIN-008。主流程同时补入结算侧的「7 号前确认结算单」一条。
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)，待确认条数不变。这与营销与会员模块发现的 TODO(REQ-MKT-004) 错位是同一类问题，建议回灌时对全文的 TODO 标记与 10.2 编号做一次统一校验。
无编号观察（属现状材料问题，不新增需求）：
- 说明文案与实际执行不一致 —— 手续费说明写「15:30 左右」，提现流水记录全是
15:00:2x。门店会拿这句话对时间，须校准。 - 同一页内「京东」与「京东pop」两种写法并存（服务结算单的下拉 vs 页面说明），且两处都没有拼多多，而收入页 tab 有。
- 「请登录接单宝小程序进行修改」的引导在 App 内自相矛盾 —— 整合的目的正是消除跳出。该文案必须改写，已写入 REQ-FIN-012 与验收标准第 9 条。
另有一条跨模块的结构性问题需要在设计阶段统一解决：渠道枚举在全仓库至少有六套口径（本模块四套 + 返利中心 8 项 + 经营业绩 7 项），且各自还引入了对方没有的名字（零跑、车点点、美团、抖音团购轮胎）。渠道是贯穿销售、财务、返利、业绩四个模块的主数据，不统一将导致同一笔业务在四个模块归到不同渠道下，对账无从谈起。建议在主数据章节固化一份渠道枚举，四个模块共同引用。