conti-docs/prd/modules/06-PUR-采购.md

# 4.6 采购

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

| 项 | 值 |
| --- | --- |
| 模块码 | PUR |
| V1.0 章节 | 4.6 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + ROOS 截图 + 设计稿 |
| 现状承载系统 | ROOS（马牌）+ F6（非马牌） |
| 需求条数 | 18（待确认 12，完成度 33%） |
| 本次新增待确认 | 5（REQ-PUR-014 ~ 018） |
| 配图 | 9 张（设计稿 2 / 现状-ROOS 7） |

模块概要

---

**采购覆盖门店要买的全部商品**，包括马牌商品与耗材、辅料、其它品牌轮胎，一套浏览、加购、结算、收货、售后流程走到底，门店不需要按品牌切换页面。

数据来源上，马牌商品走 ROOS、其余商品走 F6。ROOS 本身就是马牌在 F6 后台之上自建的采购小程序 —— 品牌方要单独管理并统计各门店对自有品牌的采购情况，才有了这一层；对门店而言仍是同一个采购功能。

## 4.6.1 需求描述

**业务目标** —— 门店在 App 内完成**全部品类**的订货全流程（搜索 → 加购 → 结算 → 收货 → 售后），覆盖马牌与非马牌商品，并保留 ROOS 的额度、返利、优惠券结算能力，解决[痛点 2.3](../Continental-Retail-APP-PRD.md#23-进销存--erp-数据)

**目标角色** —— 店长：全部；技工：**需被授权**后功能同店长

**入口** —— 底部导航「采购」tab；首页快捷入口「采购」。全部商品同在此 tab 内，按分类 / 品牌逐级筛选

**前置条件** —— 已登录、已确定门店；采购马牌商品还需门店在 ROOS 有有效的经销商 / 信用账户

**页面内容** —— 商品搜索与筛选 → 商品列表 → 购物车 → 订单确认（费用构成与扣账方式）→ 我的订单（六状态）→ 订单详情 → 售后/退款；扫码收货

**主流程** —— 搜索商品 → 加入购物车 → 调整数量并勾选 → 结算 → 确认费用与扣账方式 → 提交订单 → 扫码收货。马牌与非马牌商品的流程完全一致，门店感知不到品牌差异

**异常流程**：

- 信用额度不足 → 提示并阻断提交（校验时机见 [REQ-PUR-017](#467-业务规则)）
- 商品无库存 → 加购按钮替换为「缺货登记」入口（[REQ-PUR-014](#467-业务规则)）
- 商品下架 → 列表不再返回该商品
- 扫码收货条码不匹配 → 提示并拒收

**业务规则** —— 见 [4.6.7](#467-业务规则)

**权限规则** —— 技工默认无采购权限，需店长/后台授权（[REQ-PUR-001](#467-业务规则)）

**访问链路** —— App → App Backend → ROOS（马牌商品）/ F6（非马牌商品）

**逻辑数据来源** —— **马牌商品：ROOS**；**非马牌商品：F6**。两者的底层服务同为 F6，ROOS 是马牌品牌侧的管理与统计层

**回写目标** —— 购物车、采购订单、扣账方式选择、收货确认、售后申请 → 对应来源系统

**状态变化** —— 采购订单：待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消（六状态，见 [REQ-PUR-006](#467-业务规则)）

**验收标准** —— 见 [4.6.9](#469-验收标准)

## 4.6.2 产品搜索与商品列表

用户通过顶部搜索框与筛选条件收窄范围，查询出搜索结果列表。**马牌商品的搜索接口来源于 ROOS，非马牌商品来源于 F6**，两类结果在同一列表内呈现，门店按品牌 / 分类筛选即可，不需要切换页面。

![设计稿-订单管理-商品列表](../app-design-images/订单管理-商品列表.png)

**页面内容** —— App 采购商品列表的目标形态：搜索框 + 购物车图标、一行规格筛选、「显示有货 / 显示促销」开关与品牌下拉，主体为单列商品卡（**4 张卡为同一份占位数据**，仅库存状态不同）。

**关键交互** —— ①点规格筛选任一项 → 展开该维度取值多选；②切换「显示有货 / 显示促销」→ 列表按开关过滤；③点「马牌 ▾」→ 切换品牌；④有货 / 库存紧张的卡点右下加购图标 → 加入购物车，购物车角标 +1；⑤**缺货卡的加购图标被替换为「去登记」按钮** → 进入缺货登记（[REQ-PUR-014](#467-业务规则)）；⑥点购物车图标 → 进入购物车页。

**可用角色** —— 店长 ✅ 全量；技工 ⚙️ 需店长或后台在[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)中授予采购权限后方可进入（[REQ-PUR-001](#467-业务规则)）。

**需求关联** —— [REQ-PUR-007](#467-业务规则) 数据来源、[REQ-PUR-010](#467-业务规则) 商品域范围、[REQ-PUR-014](#467-业务规则) 缺货登记、[REQ-PUR-015](#467-业务规则) 商品卡字段

![现状-ROOS 商品选择](../mini-program-images/ROOS/商品选择.png)

**页面内容** —— ROOS 小程序的商品选择页，结构与上方设计稿高度一致，差别在于商品卡多出「可延保」与时效标、缺货商品直接在图上压「缺货」并给出「缺货登记」按钮，底部是 ROOS 自身的四 tab。

**关键交互** —— ①同上方设计稿的搜索与筛选；②点「缺货登记」→ 提交该商品的缺货登记；③点加购 → 加入 ROOS 购物车；④点底部 tabbar「购物车」→ 进入购物车页。**整合到 App 后 ROOS 自身的 tabbar 不再出现**，购物车入口收敛到列表页右上角（见上方设计稿）。

**可用角色** —— 同上方设计稿：店长 ✅、技工 ⚙️。

**需求关联** —— [REQ-PUR-007](#467-业务规则) 数据来源、[REQ-PUR-014](#467-业务规则) 缺货登记、[REQ-PUR-015](#467-业务规则) 商品卡字段

> **本节正文原描述与两张图不符，已按图修订**（不新增需求编号）：
>
> V1.0 原文写「左侧树形分类（按品牌 / 花纹 / 规格逐级收窄）+ 右侧商品卡」。**两张图都不是这个结构** —— 均为「顶部平铺筛选行 + 单列商品卡」，没有左侧分类树。[4.6.8](#468-业务数据列表) 中 `productCategory` 的备注「树形分类」也应据此复核：该字段可能只是后台的分类层级，并不对应一个前端树形控件。上方正文已改为「顶部搜索框与筛选条件」。

## 4.6.3 购物车与结算

**加入购物车**：用户点击商品卡的加购图标，将商品加入购物车。用户可以调整采购数量，选择商品条目前面的选择图标，点击「结算」按钮进入结算页。

![设计稿-订单管理-购物车](../app-design-images/订单管理-购物车.png)

**页面内容** —— App 购物车的目标形态，商品**按品牌分组**（「德国马牌」组已勾选、「维京轮胎」组未勾选），底部为「合计 / 已减 / 结算」结算条。

**关键交互** —— ①勾选 / 取消单行或整个品牌组 → 合计与已减金额实时重算；②数量步进器 `−` / `+` → 改变该行数量；③点「优惠明细 ^」→ 展开本单优惠构成；④点「结算」→ 进入订单确认页。

**可用角色** —— 店长 ✅；技工 ⚙️ 被授权后可加购与调整数量，**能否点「结算」并最终提交订单未定** `TODO(REQ-PUR-002)`，关闭前按不可提交实现。

**需求关联** —— [REQ-PUR-011](#467-业务规则) 购物车与订单是否合并、[REQ-PUR-002](#467-业务规则) 技工下单权限

> **本图不能作为 [REQ-PUR-011](#467-业务规则) 已解决的证据**：图中分组的「德国马牌」与「维京轮胎」**同属 ROOS 的品牌**，两者本来就在一个系统内。真正的分歧点是 ROOS 商品与 F6 非马牌商品能否共用一个购物车，本图未涉及。

![现状-ROOS 购物车](../mini-program-images/ROOS/购物车.png)

**页面内容** —— ROOS 现状购物车，**本图为单商品的轻量态**（无优惠行），商品归在「德国马牌」组下，行内比设计稿多出商品编码与时效标。

**关键交互** —— ①点「编辑」→ 进入批量管理态（可删除 / 移出）；②勾选与数量调整同设计稿；③点「结算」→ 进入订单确认页。

**可用角色** —— 同上方设计稿：店长 ✅、技工 ⚙️ + `TODO(REQ-PUR-002)`。

**需求关联** —— [REQ-PUR-015](#467-业务规则) 商品卡字段（商品编码、时效标）

> 时效标在三张图里出现了**三种写法** —— 设计稿购物车「最快45分钟」、ROOS 商品选择「⏱45分钟」、ROOS 购物车「⏱1小时」。该标是随商品与仓库动态计算的，App 侧需统一文案模板，一并归入 [REQ-PUR-015](#467-业务规则)。

**结算与提交订单**：用户在订单确认页核对费用构成后，点击「提交订单」，完成采购流程。

![现状-ROOS 订单确认](../mini-program-images/ROOS/订单确认.png)

**页面内容** —— ROOS 现状订单确认页，自上而下为收货地址、订单商品区、费用构成（立减 / 优惠券 / **运费待双方商定** / **返利请选择** / 备注）与底部支付条（**信用额度不可用**），**本图为测试数据**（收货人「测试」、地址为重复拼接的脏数据）。

**关键交互** —— ①点收货地址 → 切换 / 编辑地址；②点「优惠券」→ 选择可用券；③点「返利 请选择」→ 选择本单抵扣的返利额度（见[返利中心](./11-RBT-返利中心.md#411-返利中心)）；④填写备注；⑤点「提交订单」→ 提交（额度校验结果见下图）。

**可用角色** —— 店长 ✅；技工 ❓ `TODO(REQ-PUR-002)`。返利抵扣涉及门店资金账户，即便技工被授权采购，是否可动用返利额度需一并确认。

**需求关联** —— [REQ-PUR-004](#467-业务规则) 支付方式、[REQ-PUR-016](#467-业务规则) 订单确认页费用构成、[REQ-PUR-011](#467-业务规则) 购物车与订单是否合并

> **本图给出两条与 V1.0 正文冲突的事实**：
>
> 1. **页面上没有任何支付方式选择器。** V1.0 的 4.6.3 原文写「用户选择支付方式后，点击提交订单」，现状实际是「信用额度 + 返利 + 优惠券」三者构成扣账，没有微信/支付宝式的支付方式单选。整合后的形态归入 [REQ-PUR-016](#467-业务规则) 与 `TODO(REQ-PUR-004)`。
> 2. **订单标题为「订单1–德国马牌」并标「普通订单」** —— 说明 ROOS 现状**已经按品牌把一次结算拆成多张订单**。这对 [REQ-PUR-011](#467-业务规则) 是重要输入：连同属 ROOS 的两个品牌都要拆单，跨 ROOS / F6 合并成一张订单的可行性更低，更现实的形态是「一个购物车 → 按来源拆多张子订单 → 列表侧聚合展示」。

**信用额度校验**：额度不足时给出明确提示并阻断下单。

![现状-ROOS 订单确认-额度不足提示](../mini-program-images/ROOS/订单确认-额度不足提示.png)

**页面内容** —— 订单确认页上弹出的失败弹窗，标题「订单提交失败」，正文「账户额度不足，请联系经销商处理」，单按钮「我知道了」。

**关键交互** —— ①点「我知道了」→ 关闭弹窗回到订单确认页，订单未生成。**无重试、无跳转充值 / 联系经销商的入口**，门店只能自行线下联系。

**可用角色** —— 店长 ✅、技工 ❓ `TODO(REQ-PUR-002)`（能提交才会遇到本弹窗）。

**需求关联** —— [REQ-PUR-003](#467-业务规则) 额度校验、[REQ-PUR-017](#467-业务规则) 额度校验时机

> **本图与 [REQ-PUR-003](#467-业务规则)、[验收标准第 2 条](#469-验收标准)直接冲突**：现状是**点击提交之后**才由服务端返回「订单提交失败」，而 REQ-PUR-003 要求「提交订单前校验」、验收标准要求「『提交订单』不可点击，且提示包含可用额度与本单金额」。现状弹窗既不置灰按钮，也不告知可用额度与本单金额差额。已新增 [REQ-PUR-017](#467-业务规则) 明确校验时机与提示内容。

> 支付方式的可选集合、优先级与扣账逻辑由「[支付优先级设置](./08-MIN-我的.md#48-我的--个人中心)」决定。整合后支付方式与 CDMS 支付的关系 —— `TODO(REQ-PUR-004)`。

## 4.6.4 收货

用户扫描商品，完成收货流程。扫码为 **App 原生实现**（见 [REQ-INT-003](../Continental-Retail-APP-PRD.md#73-f6-集成边界)），非嵌入 H5。

> 收货扫码与[扫码入库](./07-INV-库存.md#47-库存)是否为同一动作、是否一次扫码同时完成收货与入库 —— `TODO(REQ-PUR-005)`。
>
> [附录 A.5](../Continental-Retail-APP-PRD.md#a5-采购) 第 5 条已经把这两件事写成同一个数据集「收货（扫码入库）」，倾向于合并；但正文与 REQ-PUR-005 仍按未定处理，需业务正式确认后统一两处口径。

本节无配图 —— **收货页面既无设计稿也无现状截图**，扫码后的收货确认页（是否逐条核对、是否支持部分收货、拒收如何记录）目前没有任何页面材料。

## 4.6.5 订单管理与售后

**采购订单列表**：tag 分为**全部、待支付、待发货、待收货、已收货、已取消**六个状态。

![现状-ROOS 我的订单-全部](../mini-program-images/ROOS/我的订单-全部.png)

**页面内容** —— ROOS「我的订单」列表，顶部为搜索框与「筛选」、其下六个状态 tab（全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消，当前选中「全部」），**本截图为空态**（「您还没有相关的订单」），故订单行的字段与操作按钮无法从本图确认。

**关键交互** —— ①在搜索框输入订单号 / 商品名称 / 商品编码 → 检索订单；②点「筛选」→ 打开 tab 之外的附加筛选条件（**本图未展开，筛选维度无法确认**）；③点任一状态 tab → 切换列表；④点订单行 → 进入订单详情。

**可用角色** —— 店长 ✅ 全量；技工 ⚙️ 被授权后可查看订单（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「搜索 / 加购 / 查看订单」为 ⚙️）。

**需求关联** —— [REQ-PUR-006](#467-业务规则) 订单状态机

> **状态集合按本图修订。** V1.0 原写五状态「全部 / 待支付 / 待发货 / **已发货** / 已取消」，现状实为六个 tab：把「已发货」叫作「**待收货**」，并且多出「**已收货**」这一独立状态 —— 后者正对应 REQ-PUR-006 原文里那个没有 tab 的「（收货）完成」。[REQ-PUR-006](#467-业务规则) 与[验收标准第 4 条](#469-验收标准)已同步改为六状态。
>
> 另：**现状 tab 上不带条数角标**，而验收标准第 4 条要求「tab 计数与列表条数一致」—— 该计数是 App 侧的新增要求，接口需支持按状态返回计数。

![现状-ROOS 我的订单-待支付](../mini-program-images/ROOS/我的订单-待支付.png)

**页面内容** —— 同一页面切到「待支付」tab，搜索、筛选与六个 tab 均不变，**同样是空态**。

**关键交互** —— 与上一张图一致；本图仅用于佐证 tab 切换后页面骨架不变、六状态集合稳定。

**可用角色** —— 同上：店长 ✅、技工 ⚙️。

**需求关联** —— [REQ-PUR-006](#467-业务规则) 订单状态机

**采购订单详情**：查看订单流转状态。**本节无订单详情配图**，详情页的字段、可执行操作（取消 / 再次购买 / 申请售后的入口位置）缺少页面材料。

**售后 / 退款**：进入订单详情页面，点击「售后/退款」，进入「售后/退款」流程。

![现状-ROOS 售后退款](../mini-program-images/ROOS/售后退款.png)

**页面内容** —— ROOS「售后/退款」列表页，顶部依次为橙色提示条「退货订单将不会退回抵扣券」、售后单号搜索框与日期区间，**本截图为空态**，故售后单行的字段与状态无法从本图确认。

**关键交互** —— ①输入售后单号或销售订单号 → 检索售后单；②点「开始时间」/「结束时间」→ 选择日期区间过滤；③点售后单行 → 进入售后详情。**本页只做查询，发起售后的入口在订单详情页内**。

**可用角色** —— 店长 ✅；技工 ⚙️（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「售后 / 退款」为 ⚙️，需授权）。售后涉及退款去向，技工被授权后能否发起而非仅查看，随 `TODO(REQ-PUR-002)` 一并确认。

**需求关联** —— [REQ-PUR-018](#467-业务规则) 售后退款规则

> **本图暴露一条涉及资金、却完全未成文的规则**：「退货订单将不会退回抵扣券」—— 门店用抵扣券下单后退货，券不退回，实际损失由门店承担。V1.0 的 4.6.5 对售后只有一句「进入订单详情，点击售后/退款」，售后类型、可申请时限、退款去向（退回信用额度 / 返利 / 抵扣券）一概未定义。已新增 [REQ-PUR-018](#467-业务规则)。
>
> 另注意搜索框写的是「**销售订单号**」—— 这是 ROOS 站在**平台售货方**视角的措辞，而门店视角同一张单叫「采购订单」。整合进 App 后必须统一为门店视角，否则会与[销售模块](./03-SAL-销售.md#43-销售)的销售订单混淆。

> 采购订单的六状态（待支付 / 待发货 / 待收货 / 已收货 / 已取消 / 全部）与 O2O 销售订单的五状态（[4.3.5](./03-SAL-销售.md#435-线上订单管理)）**是两套完全不同的状态机**，UI 上必须明确区分，不可复用同一组件文案。

## 4.6.6 角色差异

| 角色 | 权限 |
| --- | --- |
| 店长 | 搜索、加购、结算、提交订单、收货、查看订单、发起售后 |
| 技工 | 默认不可见；被授权后功能同店长。是否允许技工提交订单（涉及资金）—— `TODO(REQ-PUR-002)` |

采购模块角色差异。资金相关动作（提交订单、选择返利抵扣、发起售后）在 `TODO(REQ-PUR-002)` 关闭前一律按技工不可执行实现。

## 4.6.7 业务规则

**REQ-PUR-001 采购授权** —— 技工需被显式授权才能进入采购模块；授权维度参见[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)

**REQ-PUR-002 技工下单权限** —— 技工被授权后是否可提交订单待定 `TODO(REQ-PUR-002)`。该条同时覆盖「选择返利抵扣」与「发起售后」两个资金相关动作

**REQ-PUR-003 额度校验** —— 提交订单前校验信用额度；不足时阻断并提示。**校验时机与提示内容见 [REQ-PUR-017](#467-业务规则)**

**REQ-PUR-004 支付方式** —— 由支付优先级设置决定默认扣账方式；与 CDMS 支付的关系待定 `TODO(REQ-PUR-004)`

**REQ-PUR-005 收货与入库** —— 扫码收货与扫码入库是否合并为一次动作待定 `TODO(REQ-PUR-005)`

**REQ-PUR-006 订单状态机** —— 待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消。列表 tag 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」六个，与销售订单状态机隔离

> 本条状态集合于 V1.1 按 [ROOS 我的订单截图](#465-订单管理与售后)修订：原写五状态、把「待收货」写作「已发货」且缺「已收货」。

**REQ-PUR-007 数据来源** —— 商品、价格、库存、订单、售后：马牌商品以 **ROOS** 为准，非马牌商品以 **F6** 为准；App 不落地二次计算的价格

**REQ-PUR-008 扫码实现** —— 收货扫码使用 App 原生扫码能力，不嵌入第三方 H5 扫码页

**REQ-PUR-009 车型字段来源** —— 商品的车型（`carModel`）是否取自 RMS 待确认 `TODO(REQ-PUR-009)`，见 [4.6.8](#468-业务数据列表)

**REQ-PUR-010 商品域范围** —— 采购覆盖门店需要的**全部商品**，含马牌商品与耗材、辅料、其它品牌轮胎。**只有一个采购入口**，门店在同一 tab 内按分类 / 品牌筛选，不因商品来源不同而切换页面。这是[痛点 2.1](../Continental-Retail-APP-PRD.md#21-多小程序分散)「多系统来回切换」在采购域的最后一块拼图

**REQ-PUR-011 购物车与订单是否合并** —— 马牌商品与非马牌商品能否放进同一个购物车、生成同一张订单待确认 `TODO(REQ-PUR-011)`。合并则需要跨来源的订单拆分与状态聚合；不合并则购物车与订单列表需按来源分列。**这是本模块最大的架构分歧点**

> V1.1 的实证输入：ROOS 订单确认页把一次结算按品牌拆成「订单1–德国马牌」等多张订单（见 [4.6.3](#463-购物车与结算)）。**连同属 ROOS 的两个品牌都要拆单**，因此「一个购物车 + 提交后按来源拆多张子订单 + 订单列表聚合展示」是比「真正合并成一张订单」更现实的落点，建议以此为决策起点。

**REQ-PUR-012 非马牌结算与账期** —— 非马牌采购的支付方式、信用额度与账期是否与马牌采购一致待确认 `TODO(REQ-PUR-012)`。马牌侧的信用额度与支付提醒来自 ROOS / CDMS，非马牌侧是否共用同一套额度未知

**REQ-PUR-013 接入路径** —— ROOS 建于 F6 后台之上，F6 侧本身具备采购服务能力。App Backend 是走「马牌经 ROOS、非马牌直连 F6」两条链路，还是统一经 ROOS 代理，待确认 `TODO(REQ-PUR-013)`。无论哪种，**马牌商品的采购记录必须仍然进入 ROOS** —— 品牌方按门店统计自有品牌采购情况正是 ROOS 存在的原因。这一条需优先于 [REQ-PUR-011](#467-业务规则) 确认

**REQ-PUR-014 缺货登记与到货通知** —— 商品列表中缺货商品**不置灰**，而是把加购按钮替换为「缺货登记 / 去登记」入口，门店可登记采购意向。登记后的到货通知形式（是否推送、是否自动加购、登记记录在哪里查看）未定 `TODO(REQ-PUR-014)`；缺货登记对非马牌商品是否同样可用，随 [REQ-PUR-013](#467-业务规则) 一并确认

> 本条修正了 [4.6.1](#461-需求描述) 原异常流程「商品下架/无库存 → 列表置灰」的写法：**无库存不是置灰，而是换成一个可点的登记入口**；下架商品则根本不在列表中返回。

**REQ-PUR-015 商品卡与购物车字段** —— 商品卡除[业务数据列表](#468-业务数据列表)已有字段外，还需承载：**发货仓**（截图为「浦东新仓」）、**销量**（「已售 3426」）、**库存状态标**（有货 / 库存紧张 / 库存不足 / 缺货）、**可延保标**、**配送时效标**、**商品编码**（购物车内展示）。这些字段当前均不在 4.6.8 的 10 个字段内，来源与取值集合待补 `TODO(REQ-PUR-015)`。配送时效标现状有「最快45分钟」「⏱45分钟」「⏱1小时」三种写法，App 侧须统一为一个文案模板

**REQ-PUR-016 订单确认页费用构成** —— 订单确认页按「立减 → 优惠券 → 返利抵扣 → 运费 → 信用额度」的顺序展示费用构成，并给出「优惠后订单金额」与「剩余应付合计」。其中：**运费现状为「待双方商定」**（线下协商，无金额），**返利为「请选择」**（门店主动选择本单抵扣额度）。整合后 App 内运费如何呈现与确认、返利抵扣的可选额度来源、以及是否存在独立的支付方式单选（现状**没有**）待确认 `TODO(REQ-PUR-016)`，与 [REQ-PUR-004](#467-业务规则) 一并决策

**REQ-PUR-017 额度校验时机** —— 信用额度校验必须**在提交前**完成：额度不足时「提交订单」置为不可点击，并在按钮上方直接给出**可用额度与本单金额的差额**。服务端在提交时仍需二次校验兜底，但该兜底不得成为门店感知到的唯一提示。现状为提交后弹「订单提交失败 / 账户额度不足，请联系经销商处理」，无差额、无置灰、无后续入口 —— 是否需要在提示中提供「联系经销商」的跳转或经销商联系方式待确认 `TODO(REQ-PUR-017)`

**REQ-PUR-018 售后退款规则** —— 售后单支持按售后单号 / 采购订单号检索与日期区间过滤。**已确认的资金规则：退货订单不退回抵扣券**，该规则须在门店发起售后前显式告知并留痕。售后类型（退货 / 退款 / 换货）、可申请时限、退款去向（原路退回信用额度 / 返利 / 抵扣券）、审核流程均未定义 `TODO(REQ-PUR-018)`。**页面文案须统一为门店视角**：现状 ROOS 用的是平台视角的「销售订单号」，App 内应称「采购订单号」，避免与[销售模块](./03-SAL-销售.md#43-销售)的销售订单混淆

## 4.6.8 业务数据列表

| # | 字段 | 字段名 | 数据来源 | 说明 |
| --- | --- | --- | --- | --- |
| 1 | 商品名称 | productName | ROOS | |
| 2 | 商品编码 | productCode | ROOS | 现状购物车行内直接展示 |
| 3 | 品牌标识 | brandTag | ROOS | |
| 4 | 品牌 | brand | ROOS | 马牌 / 维京 等 |
| 5 | 单价 | price | ROOS | 不在 App 侧二次计算 |
| 6 | 计价单位 | priceUnit | ROOS | |
| 7 | 尺寸 | tireSize | ROOS | |
| 8 | 车型 | carModel | RMS | 车型匹配 `TODO(REQ-PUR-009)` |
| 9 | 安装位置 | installPositon | ROOS | 现有字段名拼写为 `installPositon`，接口对齐时需确认是否应为 `installPosition` |
| 10 | 产品分类 | productCategory | ROOS | 分类层级；是否对应前端树形控件需复核，见 [4.6.2](#462-产品搜索与商品列表) |

采购业务数据表。上表按马牌商品（ROOS）列出；非马牌商品的同名字段以 F6 为准，字段能否一一对齐随 [REQ-PUR-013](#467-业务规则) 的接入路径一并确认。

**上表尚未覆盖**截图中实际出现的以下字段，随 `TODO(REQ-PUR-015)` 补齐：发货仓、销量、库存状态、可延保标、配送时效、以及订单确认页的立减 / 优惠券 / 运费 / 返利抵扣 / 信用额度五项金额字段。

## 4.6.9 验收标准

1. 技工未被授权时，采购 tab 不下发、深链跳转也被拦截；
2. 信用额度不足时「提交订单」不可点击，且提示包含可用额度与本单金额；提交接口在服务端仍做二次校验（[REQ-PUR-017](#467-业务规则)）；
3. 购物车勾选、数量修改在弱网下不丢失，恢复网络后与后端一致；
4. 采购订单**六**状态的 tab 计数与列表条数一致；
5. 扫码收货使用原生扫码，无 WebView 加载过程；
6. 采购 tab 内可同时检索到马牌与非马牌商品，两类商品的下单、支付、收货、售后在交互上完全一致，商品来源对门店可见但不改变操作路径；
7. 门店未接入 F6 时，非马牌商品不出现在采购 tab 内且不报错，见[门店能力开关](../Continental-Retail-APP-PRD.md#74-门店能力开关)；
8. 缺货商品的卡片给出「缺货登记」入口而非置灰，登记成功后有明确反馈（[REQ-PUR-014](#467-业务规则)）；
9. 发起退货前，「退货订单不退回抵扣券」的提示对门店可见（[REQ-PUR-018](#467-业务规则)）。

> 第 2、4 条按本次逐图核看结果修订，第 8、9 条为本次新增。

---

## 附：本模块归拢信息

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

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

| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 商品信息（名称/规格/型号/价格/库存/详情/参数） | Mini Program Backend | HTTPS | ROOS |
| 2 | 当前用户购物车信息数据集 | Mini Program Backend | HTTPS | 保存至 ROOS |
| 3 | 促销日历数据集 | Mini Program Backend | HTTPS | 活动数据接口待确定 |
| 4 | 结算信息结果集 | App Backend | **证书令牌** | 需调用三方接口，银行接口可能需令牌或证书 |
| 5 | 收货（扫码入库） | **原生 `native_scan`** | — | ⚠️ 前期材料写「嵌入 F6 扫码入库页面」，已按 [REQ-INT-003](../Continental-Retail-APP-PRD.md#71-访问链路原则) 校正 |
| 6 | 采购订单列表 / 采购订单详情 | Mini Program Backend | HTTPS | |

采购模块数据集（摘自主文件[附录 A.5](../Continental-Retail-APP-PRD.md#a5-采购)）。字段级清单见上方 [4.6.8](#468-业务数据列表)。

两处需要注意的对不齐：

1. **第 3 条「促销日历数据集」在正文 4.6 中没有任何对应功能。** 商品列表有「显示促销」开关、购物车有「已减 / 优惠明细」、订单确认页有「优惠券」，但都不是「促销日历」。该数据集究竟服务于采购页的哪个位置，还是应归到[营销与会员](./13-MKT-营销与会员.md#413-营销与会员)，需在 `TODO(REQ-PUR-016)` 一并厘清。
2. **第 5 条已把「收货」与「扫码入库」并为同一数据集**，实际上给 `TODO(REQ-PUR-005)`（两者是否合并）预设了答案。正文仍按未定处理，两处口径需在该 TODO 关闭时统一。

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

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

| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 搜索 / 加购 / 查看订单 | ✅ | ⚙️ | 技工需被授权 |
| **提交订单**（涉及资金） | ✅ | ❓ | `TODO(REQ-PUR-002)` |
| 收货 | ✅ | ⚙️ | |
| 售后 / 退款 | ✅ | ⚙️ | 能否**发起**（而非仅查看）随 `TODO(REQ-PUR-002)` 一并确认 |

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

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

> 本次拆分发现矩阵**漏了一行**：订单确认页的「**选择返利抵扣**」同样是动用门店资金的动作，且与「提交订单」可分离（可以允许技工提交但不允许选返利）。回灌主文件附录 B 时建议单列一行，取值随 `TODO(REQ-PUR-002)`。

### 附-3 待确认项（主文件 10.2.6 + 本次新增）

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-PUR-002 | 技工被授权后是否可提交订单（涉及资金） | 业务 |
| REQ-PUR-004 | 支付方式与 CDMS 支付的关系 | 财务 / 架构 |
| REQ-PUR-005 | 扫码收货与扫码入库是否合并为一次动作 | 业务 |
| REQ-PUR-009 | 车型字段（carModel）是否取自 RMS | 架构 |
| REQ-PUR-011 | **马牌与非马牌商品是否共用购物车与订单**（合并需跨来源拆单与状态聚合） | 架构 / 产品 |
| REQ-PUR-012 | 非马牌采购的支付方式、信用额度与账期是否与马牌一致 | 业务 / 财务 |
| REQ-PUR-013 | **非马牌商品是直连 F6 还是经 ROOS 代理**（需保证马牌采购记录仍进 ROOS） | 架构 / F6 |
| **REQ-PUR-014** | 缺货登记后的到货通知形式、登记记录的查看入口；非马牌商品是否同样支持 | 产品 / 业务 |
| **REQ-PUR-015** | 发货仓 / 销量 / 库存状态 / 可延保标 / 配送时效 / 商品编码的来源与取值集合；时效文案统一模板 | 业务 / 架构 |
| **REQ-PUR-016** | 运费「待双方商定」在 App 内如何呈现与确认；返利抵扣的可选额度来源；**是否存在独立的支付方式单选**（现状没有） | 财务 / 产品 |
| **REQ-PUR-017** | 额度不足的提示中是否提供「联系经销商」跳转或联系方式 | 业务 |
| **REQ-PUR-018** | 售后类型、可申请时限、退款去向（信用额度 / 返利 / 抵扣券）与审核流程 | 业务 / 财务 |

采购模块待确认项，共 12 条（主文件 [10.2.6](../Continental-Retail-APP-PRD.md#1026-采购pur) 原 7 条 + 本次新增 5 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.6，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 PUR 行（13 / 7 / 46% → 18 / 12 / 33%）与第 10.2 节总数。

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

| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-订单管理商品列表（规格 + 黑科技筛选、有货/促销开关、品牌下拉、4 张同款占位卡、缺货卡「去登记」） | `../app-design-images/订单管理-商品列表.png` |
| 2 | 现状-ROOS 商品选择（同构筛选、可延保 / 时效标、库存紧张 / 不足、缺货登记、ROOS 自身 tabbar） | `../mini-program-images/ROOS/商品选择.png` |
| 3 | 设计稿-订单管理购物车（按品牌分组、合计 / 已减 / 优惠明细 / 结算） | `../app-design-images/订单管理-购物车.png` |
| 4 | 现状-ROOS 购物车（共 1 件、编辑态入口、行内展示商品编码、⏱1小时） | `../mini-program-images/ROOS/购物车.png` |
| 5 | 现状-ROOS 订单确认（**测试地址数据**；订单按品牌拆为「订单1–德国马牌」；立减 / 优惠券 / 运费待双方商定 / 返利请选择 / 信用额度不可用；**无支付方式选择器**） | `../mini-program-images/ROOS/订单确认.png` |
| 6 | 现状-ROOS 订单确认额度不足（**提交后**弹「订单提交失败 / 账户额度不足，请联系经销商处理」，单按钮「我知道了」） | `../mini-program-images/ROOS/订单确认-额度不足提示.png` |
| 7 | 现状-ROOS 我的订单全部（**空态**；搜索 + 筛选；**六状态 tab**：全部/待支付/待发货/待收货/已收货/已取消） | `../mini-program-images/ROOS/我的订单-全部.png` |
| 8 | 现状-ROOS 我的订单待支付（**空态**；佐证 tab 切换后骨架不变） | `../mini-program-images/ROOS/我的订单-待支付.png` |
| 9 | 现状-ROOS 售后退款（**空态**；橙色提示条「退货订单将不会退回抵扣券」；按售后单号 / 销售订单号 + 日期区间检索） | `../mini-program-images/ROOS/售后退款.png` |

采购模块配图清单，9 张（设计稿 2 / 现状-ROOS 7）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充，主文件附录 C 回灌时应一并更新。

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

- **9 张图里有 3 张是空态**（第 7、8、9 张），1 张是重复占位数据（第 1 张），1 张是脏测试数据（第 5 张）。订单行、售后单行的实际字段与操作按钮**全部无法从现有材料确认**，建议向有真实订单的门店账号补采截图。
- **收货流程与订单详情页完全没有配图**（既无设计稿也无现状截图）。收货确认页是否逐条核对、能否部分收货、拒收如何记录，以及订单详情页的可执行操作，目前没有任何页面材料支撑 —— 这两处直接影响 `TODO(REQ-PUR-005)` 的决策，建议优先补稿。

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

逐张核看 9 张配图后，新增 **5 条编号需求**（REQ-PUR-014 ~ 018）、**修订 3 处既有内容**、另记 **3 条无编号观察**。

**新增需求**：

| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-PUR-014 | 缺货登记与到货通知 | 设计稿与 ROOS 商品列表的缺货卡都给「去登记 / 缺货登记」按钮，而非正文写的「置灰」 |
| REQ-PUR-015 | 商品卡与购物车字段 | 发货仓「浦东新仓」、销量「已售 3426」、可延保标、时效标、商品编码均不在 4.6.8 的 10 个字段内 |
| REQ-PUR-016 | 订单确认页费用构成 | 现状为「立减 / 优惠券 / 运费待双方商定 / 返利请选择 / 信用额度」，**没有支付方式选择器** |
| REQ-PUR-017 | 额度校验时机 | 现状是提交后弹失败框，与 REQ-PUR-003「提交前校验」及验收标准第 2 条冲突 |
| REQ-PUR-018 | 售后退款规则 | 「退货订单将不会退回抵扣券」是一条涉及资金、却完全未成文的规则 |

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

1. **[REQ-PUR-006](#467-业务规则) 订单状态机由五状态改为六状态** —— 现状 tab 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」；原文把「待收货」写作「已发货」，且漏掉了「已收货」。同步改了 [4.6.1](#461-需求描述) 的状态变化、[4.6.5](#465-订单管理与售后) 正文与[验收标准第 4 条](#469-验收标准)。
2. **[4.6.2](#462-产品搜索与商品列表) 的「左侧树形分类」描述被两张图否定** —— 实际是顶部平铺筛选 + 单列商品卡，无分类树。正文已改，`productCategory` 的「树形分类」备注也需复核。
3. **[4.6.1](#461-需求描述) 异常流程「商品下架/无库存 → 列表置灰」拆成两条** —— 无库存换成「缺货登记」入口，下架商品不在列表返回。

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

1. **配送时效标有三种写法** —— 「最快45分钟」「⏱45分钟」「⏱1小时」，App 侧需统一文案模板，已并入 REQ-PUR-015。
2. **购物车设计稿的「德国马牌 / 维京轮胎」分组不能证明 [REQ-PUR-011](#467-业务规则) 已解决** —— 两者同属 ROOS，真正的分歧是 ROOS 与 F6 商品能否共用购物车，图中未涉及。但订单确认页「订单1–德国马牌」说明 ROOS 内部**已按品牌拆单**，这是决策的重要实证输入。
3. **售后页搜索框用的是平台视角的「销售订单号」** —— 门店视角同一张单叫「采购订单」，整合进 App 后须统一措辞，否则与[销售模块](./03-SAL-销售.md#43-销售)的销售订单混淆。已写入 REQ-PUR-018。

另有一条给主文件附录 B 的建议：**补一行「选择返利抵扣」** —— 该动作动用门店资金且可与「提交订单」分离授权，现有矩阵未覆盖，见[附-2](#附-2-权限矩阵主文件附录-b-本模块分行)。