38 KiB
4.6 采购
本文件是【采购 PUR】模块需求的编辑入口。 主文件
../Continental-Retail-APP-PRD.md第 4.6 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。 两者不一致时以本文件为准。 目录约定见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
目标角色 —— 店长：全部；技工：需被授权后功能同店长
入口 —— 底部导航「采购」tab；首页快捷入口「采购」。全部商品同在此 tab 内，按分类 / 品牌逐级筛选
前置条件 —— 已登录、已确定门店；采购马牌商品还需门店在 ROOS 有有效的经销商 / 信用账户
页面内容 —— 商品搜索与筛选 → 商品列表 → 购物车 → 订单确认（费用构成与扣账方式）→ 我的订单（六状态）→ 订单详情 → 售后/退款；扫码收货
主流程 —— 搜索商品 → 加入购物车 → 调整数量并勾选 → 结算 → 确认费用与扣账方式 → 提交订单 → 扫码收货。马牌与非马牌商品的流程完全一致，门店感知不到品牌差异
异常流程：
- 信用额度不足 → 提示并阻断提交（校验时机见 REQ-PUR-017）
- 商品无库存 → 加购按钮替换为「缺货登记」入口（REQ-PUR-014）
- 商品下架 → 列表不再返回该商品
- 扫码收货条码不匹配 → 提示并拒收
业务规则 —— 见 4.6.7
权限规则 —— 技工默认无采购权限，需店长/后台授权（REQ-PUR-001）
访问链路 —— App → App Backend → ROOS（马牌商品）/ F6（非马牌商品）
逻辑数据来源 —— 马牌商品：ROOS；非马牌商品：F6。两者的底层服务同为 F6，ROOS 是马牌品牌侧的管理与统计层
回写目标 —— 购物车、采购订单、扣账方式选择、收货确认、售后申请 → 对应来源系统
状态变化 —— 采购订单：待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消（六状态，见 REQ-PUR-006）
验收标准 —— 见 4.6.9
4.6.2 产品搜索与商品列表
用户通过顶部搜索框与筛选条件收窄范围，查询出搜索结果列表。马牌商品的搜索接口来源于 ROOS，非马牌商品来源于 F6，两类结果在同一列表内呈现，门店按品牌 / 分类筛选即可，不需要切换页面。
页面内容 —— App 采购商品列表的目标形态：搜索框 + 购物车图标、一行规格筛选、「显示有货 / 显示促销」开关与品牌下拉，主体为单列商品卡（4 张卡为同一份占位数据，仅库存状态不同）。
关键交互 —— ①点规格筛选任一项 → 展开该维度取值多选；②切换「显示有货 / 显示促销」→ 列表按开关过滤；③点「马牌 ▾」→ 切换品牌；④有货 / 库存紧张的卡点右下加购图标 → 加入购物车，购物车角标 +1；⑤缺货卡的加购图标被替换为「去登记」按钮 → 进入缺货登记（REQ-PUR-014）；⑥点购物车图标 → 进入购物车页。
可用角色 —— 店长 ✅ 全量；技工 ⚙️ 需店长或后台在人员管理「可用系统」中授予采购权限后方可进入（REQ-PUR-001）。
需求关联 —— REQ-PUR-007 数据来源、REQ-PUR-010 商品域范围、REQ-PUR-014 缺货登记、REQ-PUR-015 商品卡字段
页面内容 —— ROOS 小程序的商品选择页，结构与上方设计稿高度一致，差别在于商品卡多出「可延保」与时效标、缺货商品直接在图上压「缺货」并给出「缺货登记」按钮，底部是 ROOS 自身的四 tab。
关键交互 —— ①同上方设计稿的搜索与筛选；②点「缺货登记」→ 提交该商品的缺货登记；③点加购 → 加入 ROOS 购物车；④点底部 tabbar「购物车」→ 进入购物车页。整合到 App 后 ROOS 自身的 tabbar 不再出现，购物车入口收敛到列表页右上角（见上方设计稿）。
可用角色 —— 同上方设计稿：店长 ✅、技工 ⚙️。
需求关联 —— REQ-PUR-007 数据来源、REQ-PUR-014 缺货登记、REQ-PUR-015 商品卡字段
本节正文原描述与两张图不符，已按图修订（不新增需求编号）：
V1.0 原文写「左侧树形分类（按品牌 / 花纹 / 规格逐级收窄）+ 右侧商品卡」。两张图都不是这个结构 —— 均为「顶部平铺筛选行 + 单列商品卡」，没有左侧分类树。4.6.8 中
productCategory的备注「树形分类」也应据此复核：该字段可能只是后台的分类层级，并不对应一个前端树形控件。上方正文已改为「顶部搜索框与筛选条件」。
4.6.3 购物车与结算
加入购物车：用户点击商品卡的加购图标，将商品加入购物车。用户可以调整采购数量，选择商品条目前面的选择图标，点击「结算」按钮进入结算页。
页面内容 —— App 购物车的目标形态，商品按品牌分组（「德国马牌」组已勾选、「维京轮胎」组未勾选），底部为「合计 / 已减 / 结算」结算条。
关键交互 —— ①勾选 / 取消单行或整个品牌组 → 合计与已减金额实时重算；②数量步进器 − / + → 改变该行数量；③点「优惠明细 ^」→ 展开本单优惠构成；④点「结算」→ 进入订单确认页。
可用角色 —— 店长 ✅；技工 ⚙️ 被授权后可加购与调整数量，能否点「结算」并最终提交订单未定 TODO(REQ-PUR-002)，关闭前按不可提交实现。
需求关联 —— REQ-PUR-011 购物车与订单是否合并、REQ-PUR-002 技工下单权限
本图不能作为 REQ-PUR-011 已解决的证据：图中分组的「德国马牌」与「维京轮胎」同属 ROOS 的品牌，两者本来就在一个系统内。真正的分歧点是 ROOS 商品与 F6 非马牌商品能否共用一个购物车，本图未涉及。
页面内容 —— ROOS 现状购物车，本图为单商品的轻量态（无优惠行），商品归在「德国马牌」组下，行内比设计稿多出商品编码与时效标。
关键交互 —— ①点「编辑」→ 进入批量管理态（可删除 / 移出）；②勾选与数量调整同设计稿；③点「结算」→ 进入订单确认页。
可用角色 —— 同上方设计稿：店长 ✅、技工 ⚙️ + TODO(REQ-PUR-002)。
需求关联 —— REQ-PUR-015 商品卡字段（商品编码、时效标）
时效标在三张图里出现了三种写法 —— 设计稿购物车「最快45分钟」、ROOS 商品选择「⏱45分钟」、ROOS 购物车「⏱1小时」。该标是随商品与仓库动态计算的，App 侧需统一文案模板，一并归入 REQ-PUR-015。
结算与提交订单：用户在订单确认页核对费用构成后，点击「提交订单」，完成采购流程。
页面内容 —— ROOS 现状订单确认页，自上而下为收货地址、订单商品区、费用构成（立减 / 优惠券 / 运费待双方商定 / 返利请选择 / 备注）与底部支付条（信用额度不可用），本图为测试数据（收货人「测试」、地址为重复拼接的脏数据）。
关键交互 —— ①点收货地址 → 切换 / 编辑地址；②点「优惠券」→ 选择可用券；③点「返利 请选择」→ 选择本单抵扣的返利额度（见返利中心）；④填写备注；⑤点「提交订单」→ 提交（额度校验结果见下图）。
可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-PUR-002)。返利抵扣涉及门店资金账户，即便技工被授权采购，是否可动用返利额度需一并确认。
需求关联 —— REQ-PUR-004 支付方式、REQ-PUR-016 订单确认页费用构成、REQ-PUR-011 购物车与订单是否合并
本图给出两条与 V1.0 正文冲突的事实：
- 页面上没有任何支付方式选择器。 V1.0 的 4.6.3 原文写「用户选择支付方式后，点击提交订单」，现状实际是「信用额度 + 返利 + 优惠券」三者构成扣账，没有微信/支付宝式的支付方式单选。整合后的形态归入 REQ-PUR-016 与
TODO(REQ-PUR-004)。- 订单标题为「订单1–德国马牌」并标「普通订单」 —— 说明 ROOS 现状已经按品牌把一次结算拆成多张订单。这对 REQ-PUR-011 是重要输入：连同属 ROOS 的两个品牌都要拆单，跨 ROOS / F6 合并成一张订单的可行性更低，更现实的形态是「一个购物车 → 按来源拆多张子订单 → 列表侧聚合展示」。
信用额度校验：额度不足时给出明确提示并阻断下单。
页面内容 —— 订单确认页上弹出的失败弹窗，标题「订单提交失败」，正文「账户额度不足，请联系经销商处理」，单按钮「我知道了」。
关键交互 —— ①点「我知道了」→ 关闭弹窗回到订单确认页，订单未生成。无重试、无跳转充值 / 联系经销商的入口，门店只能自行线下联系。
可用角色 —— 店长 ✅、技工 ❓ TODO(REQ-PUR-002)（能提交才会遇到本弹窗）。
需求关联 —— REQ-PUR-003 额度校验、REQ-PUR-017 额度校验时机
本图与 REQ-PUR-003、验收标准第 2 条直接冲突：现状是点击提交之后才由服务端返回「订单提交失败」，而 REQ-PUR-003 要求「提交订单前校验」、验收标准要求「『提交订单』不可点击，且提示包含可用额度与本单金额」。现状弹窗既不置灰按钮，也不告知可用额度与本单金额差额。已新增 REQ-PUR-017 明确校验时机与提示内容。
支付方式的可选集合、优先级与扣账逻辑由「支付优先级设置」决定。整合后支付方式与 CDMS 支付的关系 ——
TODO(REQ-PUR-004)。
4.6.4 收货
用户扫描商品，完成收货流程。扫码为 App 原生实现（见 REQ-INT-003），非嵌入 H5。
收货扫码与扫码入库是否为同一动作、是否一次扫码同时完成收货与入库 ——
TODO(REQ-PUR-005)。附录 A.5 第 5 条已经把这两件事写成同一个数据集「收货（扫码入库）」，倾向于合并；但正文与 REQ-PUR-005 仍按未定处理，需业务正式确认后统一两处口径。
本节无配图 —— 收货页面既无设计稿也无现状截图，扫码后的收货确认页（是否逐条核对、是否支持部分收货、拒收如何记录）目前没有任何页面材料。
4.6.5 订单管理与售后
采购订单列表：tag 分为全部、待支付、待发货、待收货、已收货、已取消六个状态。
页面内容 —— ROOS「我的订单」列表，顶部为搜索框与「筛选」、其下六个状态 tab（全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消，当前选中「全部」），本截图为空态（「您还没有相关的订单」），故订单行的字段与操作按钮无法从本图确认。
关键交互 —— ①在搜索框输入订单号 / 商品名称 / 商品编码 → 检索订单；②点「筛选」→ 打开 tab 之外的附加筛选条件（本图未展开，筛选维度无法确认）；③点任一状态 tab → 切换列表；④点订单行 → 进入订单详情。
可用角色 —— 店长 ✅ 全量；技工 ⚙️ 被授权后可查看订单（附录 B「搜索 / 加购 / 查看订单」为 ⚙️）。
需求关联 —— REQ-PUR-006 订单状态机
状态集合按本图修订。 V1.0 原写五状态「全部 / 待支付 / 待发货 / 已发货 / 已取消」，现状实为六个 tab：把「已发货」叫作「待收货」，并且多出「已收货」这一独立状态 —— 后者正对应 REQ-PUR-006 原文里那个没有 tab 的「（收货）完成」。REQ-PUR-006 与验收标准第 4 条已同步改为六状态。
另：现状 tab 上不带条数角标，而验收标准第 4 条要求「tab 计数与列表条数一致」—— 该计数是 App 侧的新增要求，接口需支持按状态返回计数。
页面内容 —— 同一页面切到「待支付」tab，搜索、筛选与六个 tab 均不变，同样是空态。
关键交互 —— 与上一张图一致；本图仅用于佐证 tab 切换后页面骨架不变、六状态集合稳定。
可用角色 —— 同上：店长 ✅、技工 ⚙️。
需求关联 —— REQ-PUR-006 订单状态机
采购订单详情：查看订单流转状态。本节无订单详情配图，详情页的字段、可执行操作（取消 / 再次购买 / 申请售后的入口位置）缺少页面材料。
售后 / 退款：进入订单详情页面，点击「售后/退款」，进入「售后/退款」流程。
页面内容 —— ROOS「售后/退款」列表页，顶部依次为橙色提示条「退货订单将不会退回抵扣券」、售后单号搜索框与日期区间，本截图为空态，故售后单行的字段与状态无法从本图确认。
关键交互 —— ①输入售后单号或销售订单号 → 检索售后单；②点「开始时间」/「结束时间」→ 选择日期区间过滤；③点售后单行 → 进入售后详情。本页只做查询，发起售后的入口在订单详情页内。
可用角色 —— 店长 ✅；技工 ⚙️（附录 B「售后 / 退款」为 ⚙️，需授权）。售后涉及退款去向，技工被授权后能否发起而非仅查看，随 TODO(REQ-PUR-002) 一并确认。
需求关联 —— REQ-PUR-018 售后退款规则
本图暴露一条涉及资金、却完全未成文的规则：「退货订单将不会退回抵扣券」—— 门店用抵扣券下单后退货，券不退回，实际损失由门店承担。V1.0 的 4.6.5 对售后只有一句「进入订单详情，点击售后/退款」，售后类型、可申请时限、退款去向（退回信用额度 / 返利 / 抵扣券）一概未定义。已新增 REQ-PUR-018。
另注意搜索框写的是「销售订单号」—— 这是 ROOS 站在平台售货方视角的措辞，而门店视角同一张单叫「采购订单」。整合进 App 后必须统一为门店视角，否则会与销售模块的销售订单混淆。
采购订单的六状态（待支付 / 待发货 / 待收货 / 已收货 / 已取消 / 全部）与 O2O 销售订单的五状态（4.3.5）是两套完全不同的状态机，UI 上必须明确区分，不可复用同一组件文案。
4.6.6 角色差异
| 角色 | 权限 |
|---|---|
| 店长 | 搜索、加购、结算、提交订单、收货、查看订单、发起售后 |
| 技工 | 默认不可见；被授权后功能同店长。是否允许技工提交订单（涉及资金）—— TODO(REQ-PUR-002) |
采购模块角色差异。资金相关动作（提交订单、选择返利抵扣、发起售后）在 TODO(REQ-PUR-002) 关闭前一律按技工不可执行实现。
4.6.7 业务规则
REQ-PUR-001 采购授权 —— 技工需被显式授权才能进入采购模块；授权维度参见人员管理「可用系统」
REQ-PUR-002 技工下单权限 —— 技工被授权后是否可提交订单待定 TODO(REQ-PUR-002)。该条同时覆盖「选择返利抵扣」与「发起售后」两个资金相关动作
REQ-PUR-003 额度校验 —— 提交订单前校验信用额度；不足时阻断并提示。校验时机与提示内容见 REQ-PUR-017
REQ-PUR-004 支付方式 —— 由支付优先级设置决定默认扣账方式；与 CDMS 支付的关系待定 TODO(REQ-PUR-004)
REQ-PUR-005 收货与入库 —— 扫码收货与扫码入库是否合并为一次动作待定 TODO(REQ-PUR-005)
REQ-PUR-006 订单状态机 —— 待支付 → 待发货 → 待收货 → 已收货；可取消 → 已取消。列表 tag 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」六个，与销售订单状态机隔离
本条状态集合于 V1.1 按 ROOS 我的订单截图修订：原写五状态、把「待收货」写作「已发货」且缺「已收货」。
REQ-PUR-007 数据来源 —— 商品、价格、库存、订单、售后：马牌商品以 ROOS 为准，非马牌商品以 F6 为准；App 不落地二次计算的价格
REQ-PUR-008 扫码实现 —— 收货扫码使用 App 原生扫码能力，不嵌入第三方 H5 扫码页
REQ-PUR-009 车型字段来源 —— 商品的车型（carModel）是否取自 RMS 待确认 TODO(REQ-PUR-009)，见 4.6.8
REQ-PUR-010 商品域范围 —— 采购覆盖门店需要的全部商品，含马牌商品与耗材、辅料、其它品牌轮胎。只有一个采购入口，门店在同一 tab 内按分类 / 品牌筛选，不因商品来源不同而切换页面。这是痛点 2.1「多系统来回切换」在采购域的最后一块拼图
REQ-PUR-011 购物车与订单是否合并 —— 马牌商品与非马牌商品能否放进同一个购物车、生成同一张订单待确认 TODO(REQ-PUR-011)。合并则需要跨来源的订单拆分与状态聚合；不合并则购物车与订单列表需按来源分列。这是本模块最大的架构分歧点
V1.1 的实证输入：ROOS 订单确认页把一次结算按品牌拆成「订单1–德国马牌」等多张订单（见 4.6.3）。连同属 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 确认
REQ-PUR-014 缺货登记与到货通知 —— 商品列表中缺货商品不置灰，而是把加购按钮替换为「缺货登记 / 去登记」入口，门店可登记采购意向。登记后的到货通知形式（是否推送、是否自动加购、登记记录在哪里查看）未定 TODO(REQ-PUR-014)；缺货登记对非马牌商品是否同样可用，随 REQ-PUR-013 一并确认
本条修正了 4.6.1 原异常流程「商品下架/无库存 → 列表置灰」的写法：无库存不是置灰，而是换成一个可点的登记入口；下架商品则根本不在列表中返回。
REQ-PUR-015 商品卡与购物车字段 —— 商品卡除业务数据列表已有字段外，还需承载：发货仓（截图为「浦东新仓」）、销量（「已售 3426」）、库存状态标（有货 / 库存紧张 / 库存不足 / 缺货）、可延保标、配送时效标、商品编码（购物车内展示）。这些字段当前均不在 4.6.8 的 10 个字段内，来源与取值集合待补 TODO(REQ-PUR-015)。配送时效标现状有「最快45分钟」「⏱45分钟」「⏱1小时」三种写法，App 侧须统一为一个文案模板
REQ-PUR-016 订单确认页费用构成 —— 订单确认页按「立减 → 优惠券 → 返利抵扣 → 运费 → 信用额度」的顺序展示费用构成，并给出「优惠后订单金额」与「剩余应付合计」。其中：运费现状为「待双方商定」（线下协商，无金额），返利为「请选择」（门店主动选择本单抵扣额度）。整合后 App 内运费如何呈现与确认、返利抵扣的可选额度来源、以及是否存在独立的支付方式单选（现状没有）待确认 TODO(REQ-PUR-016)，与 REQ-PUR-004 一并决策
REQ-PUR-017 额度校验时机 —— 信用额度校验必须在提交前完成：额度不足时「提交订单」置为不可点击，并在按钮上方直接给出可用额度与本单金额的差额。服务端在提交时仍需二次校验兜底，但该兜底不得成为门店感知到的唯一提示。现状为提交后弹「订单提交失败 / 账户额度不足，请联系经销商处理」，无差额、无置灰、无后续入口 —— 是否需要在提示中提供「联系经销商」的跳转或经销商联系方式待确认 TODO(REQ-PUR-017)
REQ-PUR-018 售后退款规则 —— 售后单支持按售后单号 / 采购订单号检索与日期区间过滤。已确认的资金规则：退货订单不退回抵扣券，该规则须在门店发起售后前显式告知并留痕。售后类型（退货 / 退款 / 换货）、可申请时限、退款去向（原路退回信用额度 / 返利 / 抵扣券）、审核流程均未定义 TODO(REQ-PUR-018)。页面文案须统一为门店视角：现状 ROOS 用的是平台视角的「销售订单号」，App 内应称「采购订单号」，避免与销售模块的销售订单混淆
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 |
采购业务数据表。上表按马牌商品（ROOS）列出；非马牌商品的同名字段以 F6 为准，字段能否一一对齐随 REQ-PUR-013 的接入路径一并确认。
上表尚未覆盖截图中实际出现的以下字段，随 TODO(REQ-PUR-015) 补齐：发货仓、销量、库存状态、可延保标、配送时效、以及订单确认页的立减 / 优惠券 / 运费 / 返利抵扣 / 信用额度五项金额字段。
4.6.9 验收标准
- 技工未被授权时，采购 tab 不下发、深链跳转也被拦截；
- 信用额度不足时「提交订单」不可点击，且提示包含可用额度与本单金额；提交接口在服务端仍做二次校验（REQ-PUR-017）；
- 购物车勾选、数量修改在弱网下不丢失，恢复网络后与后端一致；
- 采购订单六状态的 tab 计数与列表条数一致；
- 扫码收货使用原生扫码，无 WebView 加载过程；
- 采购 tab 内可同时检索到马牌与非马牌商品，两类商品的下单、支付、收货、售后在交互上完全一致，商品来源对门店可见但不改变操作路径；
- 门店未接入 F6 时，非马牌商品不出现在采购 tab 内且不报错，见门店能力开关；
- 缺货商品的卡片给出「缺货登记」入口而非置灰，登记成功后有明确反馈（REQ-PUR-014）；
- 发起退货前，「退货订单不退回抵扣券」的提示对门店可见（REQ-PUR-018）。
第 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 校正 |
| 6 | 采购订单列表 / 采购订单详情 | Mini Program Backend | HTTPS |
采购模块数据集（摘自主文件附录 A.5）。字段级清单见上方 4.6.8。
两处需要注意的对不齐：
- 第 3 条「促销日历数据集」在正文 4.6 中没有任何对应功能。 商品列表有「显示促销」开关、购物车有「已减 / 优惠明细」、订单确认页有「优惠券」，但都不是「促销日历」。该数据集究竟服务于采购页的哪个位置，还是应归到营销与会员，需在
TODO(REQ-PUR-016)一并厘清。 - 第 5 条已把「收货」与「扫码入库」并为同一数据集，实际上给
TODO(REQ-PUR-005)（两者是否合并）预设了答案。正文仍按未定处理，两处口径需在该 TODO 关闭时统一。
附-2 权限矩阵（主文件附录 B 本模块分行）
图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
|---|---|---|---|
| 搜索 / 加购 / 查看订单 | ✅ | ⚙️ | 技工需被授权 |
| 提交订单（涉及资金） | ✅ | ❓ | TODO(REQ-PUR-002) |
| 收货 | ✅ | ⚙️ | |
| 售后 / 退款 | ✅ | ⚙️ | 能否发起（而非仅查看）随 TODO(REQ-PUR-002) 一并确认 |
采购模块权限矩阵（摘自主文件附录 B）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经人员管理「可用系统」授予（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 原 7 条 + 本次新增 5 条）。加粗编号为本次拆分新增，回灌时需一并写入主文件 10.2.6，并同步附录 D.2 的 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已按实际截图内容补充，主文件附录 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 | 售后退款规则 | 「退货订单将不会退回抵扣券」是一条涉及资金、却完全未成文的规则 |
修订的既有内容：
- REQ-PUR-006 订单状态机由五状态改为六状态 —— 现状 tab 为「全部 / 待支付 / 待发货 / 待收货 / 已收货 / 已取消」；原文把「待收货」写作「已发货」，且漏掉了「已收货」。同步改了 4.6.1 的状态变化、4.6.5 正文与验收标准第 4 条。
- 4.6.2 的「左侧树形分类」描述被两张图否定 —— 实际是顶部平铺筛选 + 单列商品卡，无分类树。正文已改，
productCategory的「树形分类」备注也需复核。 - 4.6.1 异常流程「商品下架/无库存 → 列表置灰」拆成两条 —— 无库存换成「缺货登记」入口，下架商品不在列表返回。
无编号观察（属现状材料或设计稿状态问题，不新增需求）：
- 配送时效标有三种写法 —— 「最快45分钟」「⏱45分钟」「⏱1小时」，App 侧需统一文案模板，已并入 REQ-PUR-015。
- 购物车设计稿的「德国马牌 / 维京轮胎」分组不能证明 REQ-PUR-011 已解决 —— 两者同属 ROOS，真正的分歧是 ROOS 与 F6 商品能否共用购物车，图中未涉及。但订单确认页「订单1–德国马牌」说明 ROOS 内部已按品牌拆单，这是决策的重要实证输入。
- 售后页搜索框用的是平台视角的「销售订单号」 —— 门店视角同一张单叫「采购订单」，整合进 App 后须统一措辞，否则与销售模块的销售订单混淆。已写入 REQ-PUR-018。
另有一条给主文件附录 B 的建议：补一行「选择返利抵扣」 —— 该动作动用门店资金且可与「提交订单」分离授权，现有矩阵未覆盖，见附-2。