conti-docs/prd/modules/09-STM-门店管理.md

# 4.9 门店管理

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

| 项 | 值 |
| --- | --- |
| 模块码 | STM |
| V1.0 章节 | 4.9 |
| 描述粒度 | 6 维精简模板 |
| 需求依据 | 业务需求 + O2O 店铺管理截图 + 设计稿 |
| 现状承载系统 | O2O（店铺管理、经营范围、协议中心）+ 马上下单（门店主数据）+ App Backend（人员与授权） |
| 需求条数 | 14（待确认 13，完成度 7%） |
| 本次新增待确认 | 7（REQ-STM-008 ~ 014） |
| 配图 | 14 张（设计稿 2 / 现状-O2O 12） |

模块概要

---

**业务目标** —— 门店管理的入口在「我的」菜单，门店管理包括门店的基础信息，人员管理，门店项目信息，营业执照信息等

**入口** —— 「我的」菜单 → 门店管理；宫格版导航中为一级 tab（见[三版底部导航方案](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置)）

**页面内容** —— 四个 Tab：基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息；另有人员管理、收款信息、经营范围与开票方式、协议中心

**主流程** —— 进入门店管理 → 切换 Tab 查看 → 点击「修改」提交变更 →（如需）等待审核

> **现状有三种互不相同的「修改」交互模型**，见各图说明与 [REQ-STM-007](#496-业务规则)：基础信息 tab **整页只读、无任何修改入口**；2.0 店铺信息 tab 是**逐字段「修改」链接**；营业执照 tab 是**整页「修改执照信息」按钮 + 独立编辑页**。设计稿统一为底部一个「修改」按钮，与现状三种模型都不一致。字段级可编辑性必须逐字段定义。

**权限规则** —— 店长可以修改门店基础信息，添加和修改人员，修改门店项目信息，营业执照信息；**技工基本没有门店管理权限**

**数据来源** —— O2O（店铺管理、经营范围、协议）、马上下单（门店主数据）、App Backend（人员与授权）

## 4.9.1 目标形态

![设计稿-门店管理](../app-design-images/门店管理.png)

**页面内容** —— App 门店管理的设计稿：四个 Tab（**基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息**，当前选中「基础信息」）之下依次是门头照通栏、门店卡、负责人与联系方式、「收款信息 >」入口和一组渠道到期状态（高德、美团均标 **已过期**），底部为描边「修改」按钮。

**关键交互** —— ①点四个 Tab → 切换内容；②点「收款信息 >」→ 进入二级页（现状对应[银行账号](./10-FIN-财务与对账.md#4105-银行账号)）；③点底部「修改」→ 进入编辑态提交变更；④渠道行**本图未见 `>` 或可点标识**，是否可下钻无法确认。

**可用角色** —— 店长 ✅；技工 🔸 只读（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「查看门店信息」为 🔸，「修改基础信息」为 ✗，故技工看到本页时**底部「修改」按钮不可见**，见[验收标准第 1 条](#497-验收标准)）。

**需求关联** —— [REQ-STM-002](#496-业务规则) Tab 口径、[REQ-STM-006](#496-业务规则) 渠道到期提醒、[REQ-STM-007](#496-业务规则) 主数据边界、[REQ-STM-009](#496-业务规则) 渠道口径

> 三处与现状对不上，都需要在开发前定：
>
> 1. **渠道到期状态被放在「基础信息」Tab，而页面上另有一个独立的「渠道信息」Tab。** 同一类信息出现在两个 Tab 里，职责边界不清。现状中这组数据其实在「2.0 店铺信息」Tab 下，而「渠道信息」Tab 装的是完全不同的东西（见 [4.9.2](#492-门店基础信息与渠道信息)）。
> 2. **设计稿只画了 4 个渠道**（高德 / 美团 / 抖音团购 / 百度），现状有 6 个（多出**车点点**与**零跑**）。且设计稿把抖音团购标为「未上线」，现状是「已上线」——**设计稿的渠道数据已过时**。
> 3. **联系方式 13496913568 完整显示未脱敏**，与[银行账号页](./10-FIN-财务与对账.md#4105-银行账号)的脱敏口径问题同源，须统一，见 `TODO(REQ-FIN-014)`。

![设计稿-人员管理](../app-design-images/人员管理.png)

**页面内容** —— App 人员管理的设计稿：顶部是当前操作人卡（带橙色「**店铺管理员**」标签），下方两张店员卡各含姓名、「**店长权限**」标签、「账户设置 >」入口与一行「**可用系统**」图标，底部为通栏「添加店员」，**三张卡姓名相同、图标重复排列，属占位数据**。

**关键交互** —— ①点「账户设置 >」→ 进入该店员的账户与权限设置；②点底部「添加店员」→ 新增店员流程；③「可用系统」图标行**本图未见可点标识**，是在账户设置里配置还是就地可点，无法确认。

**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「人员管理与授权」标为**高风险、需审计**，技工完全不可见，含深链拦截）。

**需求关联** —— [REQ-STM-001](#496-业务规则) 人员授权模型、[REQ-STM-005](#496-业务规则) 技工权限

> **「可用系统」是一个独立于角色的授权维度** —— 它意味着人员授权不是单一角色开关，而是「角色 + 可访问子系统集合」的二维模型（如某店员有店长权限但只开通 O2O 与采购）。这与 [REQ-PUR-001](./06-PUR-采购.md#467-业务规则)（技工采购授权）是同一套机制。可用系统的取值集合、与角色的关系 —— `TODO(REQ-STM-001)`。

> 设计稿另有三处缺口：
>
> 1. **图标没有文字标签**，「可用系统」到底有哪几个系统、每个图标代表谁，从设计稿完全读不出来。这正是 `TODO(REQ-STM-001)` 要解决的取值集合问题 —— 在它关闭前，本页无法进入开发。
> 2. **角色词汇有三套**：本页的「店铺管理员」（当前操作人）与「店长权限」（店员卡），加上[第 3 章](../Continental-Retail-APP-PRD.md#3-利益相关者分析)定义的「店长 / 技工」。三者是同义、包含还是并列，须收敛为一套，否则权限矩阵无法落地。
> 3. **没有一张技工卡片**，也**没有删除或停用店员的入口**。店员离职是门店高频场景，缺了这条链路，人员管理无法闭环。已并入 [REQ-STM-001](#496-业务规则)。

## 4.9.2 门店基础信息与渠道信息

![现状-O2O 店铺管理-基础信息](../mini-program-images/O2O/店铺管理-基础信息.png)

**页面内容** —— O2O 店铺管理的「基础信息」Tab（四个 Tab 为**基础信息 / 2.0店铺信息 / 营业执照信息 / 渠道信息**），内容是门店名称、门店主编码、收款信息、负责人姓名、联系方式、门店地区、详细地址、门店评分、门头照片九行只读字段，**本图为测试数据**（门店名称「豌豆的小店」、负责人「豌豆」）。

**关键交互** —— ①点 Tab → 切换；②点「收款信息 查看详情 >」→ 进入收款信息二级页。**本页没有任何修改入口** —— 整页只读。

**可用角色** —— 店长 ✅；技工 🔸 只读。

**需求关联** —— [REQ-STM-002](#496-业务规则) Tab 口径、[REQ-STM-007](#496-业务规则) 主数据边界

> 与设计稿的字段差异：现状把地址拆成「门店地区 + 详细地址」两个字段，设计稿合并为一个「门店地址」；现状叫「门店主编码」，设计稿叫「门店编码」（编码值 3449155 一致）。这两处属字段口径，以现状为准，并在设计稿评审时提出。
>
> **「收款信息」的模块归属存在冲突**：[附录 A.7](../Continental-Retail-APP-PRD.md#a7-门店管理) 第 6 条把「收款信息结果集（O2O **平安账号模块** —— 企业银行账号、改绑手机、解绑银行卡）」列在**门店管理**名下，而正文把银行账号写在[财务与对账 4.10.5](./10-FIN-财务与对账.md#4105-银行账号) 里；[附录 C 的来源表](../Continental-Retail-APP-PRD.md#附录-c-图表清单)也把两张银行账号截图归到门店管理。**同一份数据在三处被分到两个模块**，须择一。建议按用户心智留在财务模块，[附录 A.7](../Continental-Retail-APP-PRD.md#a7-门店管理) 与[附录 C 来源表](../Continental-Retail-APP-PRD.md#附录-c-图表清单)据此改归 FIN。

![现状-O2O 店铺管理-2.0店铺信息](../mini-program-images/O2O/店铺管理-2.0店铺信息.png)

**页面内容** —— 「2.0 店铺信息」Tab，由**门店联系信息**（每行右侧各有一个橙色「修改」链接）、**渠道上线与到期状态六行**（高德与美团均 **已过期**，零跑按服务项分别记状态）、**门店本地化服务项目价目表**三块组成。

**关键交互** —— ①点任一行的「修改」→ 单独编辑该字段；②点「门店本地化服务项目」的「修改」→ 编辑价目表；③渠道行**无修改入口**，为只读展示。

**可用角色** —— 店长 ✅；技工 ✗（涉及对外报价与渠道状态）。

**需求关联** —— [REQ-STM-002](#496-业务规则) Tab 口径、[REQ-STM-006](#496-业务规则) 渠道到期提醒、[REQ-STM-008](#496-业务规则) 本地化服务项目与自主定价、[REQ-STM-009](#496-业务规则) 渠道口径

> **本图是 STM 模块信息量最大的一张，暴露三件 PRD 完全没写的事：**
>
> 1. **门店可以自主维护一张服务项目价目表**（两列「名称 / 价格」，本图可见泰克贴片补胎 50、泰克蘑菇钉补胎 100、四轮换位 70、普通四轮定位 99、全车手工打蜡-轿车 148、全车手工打蜡-SUV/MPV 198、标准洗车-轿车 30，末行被截断，即**七项以上、价格 30~198 元不等**）。这是门店对外报价的依据，直接影响[销售](./03-SAL-销售.md#43-销售)与[财务收入](./10-FIN-财务与对账.md#4102-收入明细)，PRD 全文一字未提。已记为 [REQ-STM-008](#496-业务规则)。
> 2. **现状渠道有 6 个，且零跑的状态是按服务项分别记的**（「洗车服务已上线，补胎服务已上线」），而其它 5 个是整体「已上线 / 未上线 / 已过期」。**渠道状态模型不统一**，见 [REQ-STM-009](#496-业务规则)。
> 3. **修改是逐字段的**，与设计稿「底部一个修改按钮提交整页」的模型冲突，也与营业执照 Tab 的整页编辑模型冲突。三种模型必须收敛，见 [REQ-STM-007](#496-业务规则)。
>
> 另一处数据疑点：本 Tab 的「联系人」为**宛玉**，而[基础信息 Tab](#492-门店基础信息与渠道信息)的「负责人姓名」为**豌豆**，同一门店两个名字。二者是两个不同角色字段（负责人 ≠ 联系人）还是数据不同步，**本图无法确认**，须在字段口径中明确。

![现状-O2O 店铺管理-渠道信息](../mini-program-images/O2O/店铺管理-渠道信息.png)

**页面内容** —— 「渠道信息」Tab，**页面几乎为空**，只有一个分组标题「渠道资料　（如需申请渠道上下线请联系 **SR**）」与其下「小程序」小节里唯一一行灰色的「维京　关闭」。

**关键交互** —— **本页无任何可交互控件** —— 纯只读展示，渠道上下线需线下联系 SR（马牌销售代表）办理。

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

**需求关联** —— [REQ-STM-009](#496-业务规则) 渠道口径与上下线申请

> **「渠道」在同一个页面里有两种完全不同的含义**：
>
> - 「2.0 店铺信息」Tab 里的渠道 = **外部平台**（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑），管的是门店在各引流平台的上线与到期；
> - 「渠道信息」Tab 里的渠道 = **小程序内的品牌线**（小程序 → 维京 关闭），管的是门店能卖哪些品牌。
>
> 两者共用一个词，放在相邻的两个 Tab 里，门店必然混淆。整合进 App 时必须拆成两个术语（如「平台渠道」与「品牌授权」），见 [REQ-STM-009](#496-业务规则)。这也是[全仓库渠道口径不统一](./10-FIN-财务与对账.md#4106-业务规则)问题的一部分。
>
> 另一条可直接成文的规则：**渠道上下线不能自助，须联系 SR**。App 内是保留这条线下指引，还是做成可提交的申请单，需决策。

> 现状 Tab 名为「2.0 店铺信息」，设计稿对应位置为「门店项目信息」。二者是否同一内容 —— `TODO(REQ-STM-002)`。**从截图看两者内容差异很大**：现状的「2.0 店铺信息」含联系信息、渠道状态与服务价目表三块，设计稿的「门店项目信息」未出稿，无从比对。这条待确认必须在设计稿补齐后才能关闭。

## 4.9.3 营业执照信息

![现状-O2O 店铺管理-营业执照信息](../mini-program-images/O2O/店铺管理-营业执照信息.png)

**页面内容** —— 「营业执照信息」Tab，仅营业执照照片、企业名称、统一社会信用代码三行加底部通栏橙色「修改执照信息」按钮，**本图为测试数据**（企业名称与轮胎门店业务无关）。

**关键交互** —— ①点「修改执照信息」→ 进入编辑页（见下图）；②点照片缩略图**是否可放大，本图无法确认**。

**可用角色** —— 店长 ✅；技工 ✗（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「修改基础信息 / 项目信息 / 营业执照」为 ✗）。

**需求关联** —— [REQ-STM-003](#496-业务规则) 资质变更审核、[REQ-STM-012](#496-业务规则) 协议中心清单

> **营业执照有两个入口**：本 Tab 与[协议中心](#495-协议中心)（在那里显示为「营业执照　已上传」）。同一份资质在两处维护，状态是否同源、从哪个入口改，须择一为主入口。

![现状-O2O 修改营业执照信息](../mini-program-images/O2O/修改营业执照信息.png)

**页面内容** —— 营业执照编辑页，上半部为「上传营业执照」及三条填写须知与压着「更换图片」的执照缩略图，下半部为「请确认营业信息」的两个可编辑输入框（企业名称、统一社会信用代码，均已带值），底部为通栏橙色「保存」。

**关键交互** —— ①点「更换图片」→ 弹出上传方式选择（见下图）；②点两个输入框 → 直接编辑文本；③点「保存」→ 提交变更。

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

**需求关联** —— [REQ-STM-003](#496-业务规则) 资质变更审核

> 三条须知原文，均为可校验的规则，须原样保留：①「请确保证件内容文字清晰可见，证件本身无残缺」；②「仅支持中国大陆工商局或市场监督管理局登记的个体工商户或企业，请提供有效期内的营业执照」；③「无企业名称的个体工商户，营业执照–企业名称栏，请填写营业执照–『法人姓名』，示例数据：张三」。
>
> **页面结构是「先传图 → 再确认营业信息」，强烈暗示存在证照 OCR 识别后回填**，但本图两个输入框均为可编辑状态、也没有「识别中」之类的提示，**是否真有 OCR 无法从本图确认**。若确有，需与[车牌 OCR](./03-SAL-销售.md#43-销售)一样明确由后端代理调用、客户端不直连。
>
> **变更后是否需要审核，本页看不出来** —— 点「保存」是直接生效还是转入待审，无任何提示。`TODO(REQ-STM-003)`。

![现状-O2O 修改营业执照信息-上传方式选择](../mini-program-images/O2O/修改营业执照信息-上传方式选择.png)

**页面内容** —— 上一页点「更换图片」后从底部弹出的选择面板，三项：**拍照 / 从手机相册选择 / 取消**。

**关键交互** —— ①点「拍照」→ 唤起相机；②点「从手机相册选择」→ 打开相册；③点「取消」或遮罩 → 关闭。

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

**需求关联** —— [REQ-STM-003](#496-业务规则) 资质变更审核（[验收标准第 3 条](#497-验收标准)要求两种上传方式并支持弱网重试）

> 本图直接印证[验收标准第 3 条](#497-验收标准)的前半句「支持拍照与相册两种方式」。后半句「弱网下失败可重试且不丢失已填字段」在现状截图中无从验证，属 App 侧新增要求。

> 营业执照变更是否需要审核、审核在哪个系统完成 —— `TODO(REQ-STM-003)`。

## 4.9.4 经营范围与开票方式

![现状-O2O 经营范围与开票方式](../mini-program-images/O2O/经营范围与开票方式.png)

**页面内容** —— 标题为「经营范围」的入口页，全页只有「经营范围 >」与「开票方式　非自行开票 >」两行。

**关键交互** —— ①点「经营范围 >」→ 进入经营范围详情（见下图）；②点「开票方式 >」→ 进入开票方式选择页。

**可用角色** —— 店长 ✅；技工 ✗（涉及资质与资金）。

**需求关联** —— [REQ-STM-010](#496-业务规则) 经营范围三类资质、[REQ-STM-011](#496-业务规则) 开票方式

> 页面标题是「经营范围」，但内容包含并列的「开票方式」，**标题与内容不匹配**。整合到 App 时应重命名为「经营范围与开票」或把开票方式移到财务模块下。

![现状-O2O 经营范围详情](../mini-program-images/O2O/经营范围详情.png)

**页面内容** —— 经营范围详情，由**会员体系门店（待申请）/ 认证轮胎技术检测中心（查看）/ 单独服务项（管理）三个互相独立的资质分组**构成，**其中的服务标签混有大量回归测试数据**。

**关键交互** —— ①点「待申请 >」→ 发起会员体系门店申请（**本图为待申请态，申请表单与流程无法确认**）；②点「查看 >」→ 查看 CATI 认证详情；③点「管理 >」→ 进入[单独服务项开通页](#494-经营范围与开票方式)。

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

**需求关联** —— [REQ-STM-010](#496-业务规则) 经营范围三类资质

> **三个分组对应三个不同的动词**（待申请 / 查看 / 管理），说明它们是三套独立的资质流程，而不是一张清单的三段：
>
> - **会员体系门店** —— 需申请，有准入门槛（必须具备清单内的全部服务）；
> - **CATI 认证轮胎技术检测中心** —— 由马牌授权，门店只能查看，不能自助申请；
> - **单独服务项** —— 门店可自助逐项开通。
>
> PRD 现有正文只把「经营范围」当作一个归属待定的页面（`TODO(REQ-MIN-006)`），完全没有涉及这三套流程。已记为 [REQ-STM-010](#496-业务规则)。
>
> CATI 定义原文（需在 App 内保留）：「CATI（Continental Approved Tire Inspector）是大陆马牌轮胎（中国）有限公司认证的轮胎技术检测中心。该授权中心能够及时处理客户轮胎投诉以及轮胎售后技术咨询服务。」

![现状-O2O 选择开票方式](../mini-program-images/O2O/选择开票方式.png)

**页面内容** —— 开票方式选择页，「自行开票」与「非自行开票」两张卡片各带一个勾选框、**单选**（当前选中「非自行开票」），卡片下各列若干条说明，底部为通栏橙色「确认」按钮。

**关键交互** —— ①点任一卡片的勾选框 → 切换开票方式（互斥）；②点「确认」→ 提交。**切换是否有二次确认、是否有生效时点限制，本图无法确认**。

**可用角色** —— 店长 ✅；技工 ✗（直接影响资金结算）。

**需求关联** —— [REQ-STM-011](#496-业务规则) 开票方式与 13% 扣除、[REQ-STM-013](#496-业务规则) 百望云初始密码

> **本图是全模块财务影响最大的一张。**「非自行开票」的说明第 1 条写明：「您的服务费货款将**自动扣除 13%**，并将定期打款到您小程序绑定的银行卡。」
>
> 13% 远高于[财务模块列出的全部平台费率](./10-FIN-财务与对账.md#4106-业务规则)（0.6%~4%），却在财务模块的[收入构成](./10-FIN-财务与对账.md#4102-收入明细)里完全看不到 —— 收入详情页只有「通道费」一项扣减。这两笔扣减的关系必须查清，否则门店对不上账。已记为 [REQ-STM-011](#496-业务规则)，并需与 `TODO(REQ-FIN-011)` 一并解决。
>
> 「自行开票」路径引入了一个 PRD 系统清单里没有的第三方系统 —— **百望云**（电子发票平台）：需自备电子发票资质、登录百望云完善开票信息、另填并上传对公银行信息。星号补充「登陆接单宝小程序，点击『协议中心』查看百望云初始账户密码」既是[又一处「请回小程序」的引导](./10-FIN-财务与对账.md#4103-服务结算单)，也是一处**安全问题**，见 [REQ-STM-013](#496-业务规则)。
>
> 另注：「非自行开票」说明第 2 条「请确认您已将收款方式转成银行卡收款，如需修改收款。」**句子未写完**，属现状文案缺陷，App 内须补全。

![现状-O2O 单独服务项开通情况](../mini-program-images/O2O/单独服务项开通情况.png)

**页面内容** —— 单独服务项开通页，主体是 7 行服务项开关（部分名称右侧带橙色「**会员**」小标，**其中 3 项是回归测试数据**），底部为一行协议勾选加通栏橙色「保存」。

**关键交互** —— ①逐项点开关 → 开通 / 关闭该服务；②点协议名称 → 打开协议全文；③勾选协议后点「保存」→ 提交。**未勾选协议时「保存」是否禁用，本图无法确认**。

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

**需求关联** —— [REQ-STM-010](#496-业务规则) 经营范围三类资质、[REQ-STM-004](#496-业务规则) 协议体系

> 两条可直接成文的规则：①**开通服务项须先同意《德国马牌门店非轮胎项目服务协议》**，协议同意与服务开通是同一次提交；②**带「会员」标记的服务项归属会员体系**，与上一页「会员体系门店必须包含以下服务」的清单存在交集 —— 单独开通这些项与申请会员体系门店是什么关系（前置条件？自动满足？），须明确。
>
> 这条协议同时说明[协议中心](#495-协议中心)不是唯一的协议入口 —— 协议也会内嵌在业务动作里，[REQ-STM-004](#496-业务规则) 的「协议体系是否合并」需要把这类内嵌协议一并纳入考虑。

> 经营范围在设计稿中被放进了[个人中心](./08-MIN-我的.md#481-目标形态)，在现状中属于店铺管理。归属待定 —— `TODO(REQ-MIN-006)`。

## 4.9.5 协议中心

![现状-O2O 协议中心](../mini-program-images/O2O/协议中心.png)

**页面内容** —— 协议中心，营业执照（已上传）与三份协议（均已签署）共四张卡片纵向排列、下方接 4 条说明，**本图四项均为完成态**，未签署 / 未上传的形态无法确认。

**关键交互** —— ①点任一卡片 → 打开对应协议全文或执照详情（见下图）；②**已签署项是否可重新签署、未签署项如何发起签署，本图无法确认**。

**可用角色** —— 店长 ✅；技工 🔸 只读（[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)「协议中心」为 🔸）。

**需求关联** —— [REQ-STM-004](#496-业务规则) 协议体系、[REQ-STM-012](#496-业务规则) 协议中心清单与状态、[REQ-STM-013](#496-业务规则) 百望云初始密码

> 四条说明原文：①「如您的门店已参与德国马牌的非轮胎活动，请确认您已签署相关服务协议」；②「如果您参与非轮胎项目，且选择了自行开票，请注意及时上传对公银行账户信息」；③「如果您未参与非轮胎项目或您参与了非轮胎项目后，选择的是『非自行开票』，则无需维护对公银行账户信息」；④「**百望云账号密码仅为初始密码，登录后请及时修改**」。
>
> 说明 ②③ 把**协议中心 ↔ [开票方式](#494-经营范围与开票方式) ↔ [对公银行账户](./10-FIN-财务与对账.md#4105-银行账号)**三者锁在一起：是否需要维护对公账户，取决于「是否参与非轮胎项目」与「开票方式选哪种」的组合。这套判定逻辑必须在 App 内成文，否则门店不知道自己该不该填银行信息。
>
> 说明 ④ 与[开票方式页](#494-经营范围与开票方式)的星号补充合起来意味着：**协议中心是一个第三方系统初始密码的分发渠道**。密码明文常驻在一个门店随时可进的页面里，风险明显。已记为 [REQ-STM-013](#496-业务规则)。
>
> 另注**状态词有两套**：营业执照用「已上传」，三份协议用「已签署」。它们的完成条件与法律效力不同，混在一张列表里易误解，App 内建议分组或补充状态说明。

![现状-O2O 小程序线下门店合作协议](../mini-program-images/O2O/小程序线下门店合作协议.png)

**页面内容** —— 《德国马牌轮胎小程序线下门店合作协议》全文页，开头为甲方（大陆马牌轮胎（中国）有限公司，简称"德国马牌"）与**空白的乙方**，其后本屏可见「乙方需履行以下几项义务」的第 1~9 条（第 9 条被截断）。

**关键交互** —— **无交互，仅作内容佐证**；页面为可滚动长文，本图未见「同意」「签署」按钮（该协议已处于已签署态）。

**可用角色** —— 店长 ✅ 只读；技工 🔸 只读。

**需求关联** —— [REQ-STM-004](#496-业务规则) 协议体系、[REQ-STM-014](#496-业务规则) 合作协议义务的系统承接

> **协议正文里有三条可被系统承接的门店义务**，目前 PRD 里一条都没有对应功能：
>
> - 第 1 条：「由德国马牌轮胎小程序引流产生的轮胎销售必须在**下月 15 号前**从当地认证经销商处完成补货。」—— 一条带明确截止日的周期性义务，天然适合做成[提醒](./04-RMD-提醒.md#44-提醒)或[首页待办](./02-HOM-APP首页与导航.md#423-店长首页)。
> - 第 5 条：「乙方需要在轮胎安装前向终端消费者索取**安装码**，并核销。」—— 与[销售模块的核销](./03-SAL-销售.md#434-核销)是同一动作，且核销又是[可提现金额](./10-FIN-财务与对账.md#4101-对账提现)的计算基数，三者须口径一致。
> - 第 7 条：「如终端消费者需要开具发票，乙方必须按终端消费者实际支付金额开具……不得以任何理由拒绝开具发票。」—— 与[开票方式](#494-经营范围与开票方式)的选择相互作用。
>
> 已记为 [REQ-STM-014](#496-业务规则)。
>
> **「乙方」栏空白但状态显示「已签署」** —— 本页展示的可能是协议模板而非门店签署后的实例。App 内应展示带乙方主体与签署时间的实例，否则「已签署」无从取证。**本图无法确认**该页是否另有签署信息区被折叠。

> 协议中心与[延保零售商使用条款](./05-WTY-延保.md#451-保障产品与责任边界)是两套独立的协议体系，整合后是否合并为统一的「协议与条款」入口 —— `TODO(REQ-STM-004)`。**V1.1 逐图核对发现协议实际有三类**：协议中心的 4 项、内嵌在业务动作里的《德国马牌门店非轮胎项目服务协议》、以及延保条款。合并方案需覆盖全部三类。

## 4.9.6 业务规则

**REQ-STM-001 人员授权模型** —— 角色 + 可用系统的二维授权，取值集合待定 `TODO(REQ-STM-001)`。**同时需补齐**：可用系统的图标与文案对照、店员的删除 / 停用链路、以及「店铺管理员 / 店长权限 / 店长·技工」三套角色词汇的收敛

**REQ-STM-002 Tab 口径** —— 「2.0 店铺信息」与「门店项目信息」的对应关系待定 `TODO(REQ-STM-002)`

**REQ-STM-003 资质变更审核** —— 营业执照等资质变更的审核流程待定 `TODO(REQ-STM-003)`。上传须知三条须原样保留；上传支持拍照与相册

**REQ-STM-004 协议体系** —— 协议中心与延保条款是否合并待定 `TODO(REQ-STM-004)`。合并方案须覆盖三类协议：协议中心 4 项、业务动作内嵌协议、延保条款

**REQ-STM-005 技工权限** —— 技工基本无门店管理权限，仅可只读查看门店基础信息

**REQ-STM-006 渠道到期提醒** —— 高德 / 美团 / 抖音 / 百度等渠道到期应产生[首页待办或预警](./02-HOM-APP首页与导航.md#423-店长首页) `TODO(REQ-STM-006)`

**REQ-STM-007 主数据边界** —— 门店主数据来源为马上下单（[第 5 章](../Continental-Retail-APP-PRD.md#5-主数据)），App 内可改的字段范围待定 `TODO(REQ-STM-007)`。**须同时定义修改交互模型** —— 现状三种模型并存（基础信息只读 / 2.0 店铺信息逐字段改 / 营业执照整页改），App 内须统一，并逐字段标注可编辑性

**REQ-STM-008 门店本地化服务项目与自主定价** —— 门店可在「2.0 店铺信息」下维护一张本地化服务项目价目表（名称 + 价格，现状可见泰克贴片补胎 50、四轮换位 70、全车手工打蜡-SUV/MPV 198 等七项以上），带独立编辑入口。该价目表是门店对外报价依据，须在 App 内可查可改。

> **待确认** `TODO(REQ-STM-008)`：①价格是否有上下限管控或需审核；②与[经营范围「单独服务项」](#494-经营范围与开票方式)的关系（同一批服务项还是两套清单）；③与[销售](./03-SAL-销售.md#43-销售)开单时的取价关系 —— 开单是否直接引用这张价目表。

**REQ-STM-009 渠道口径与上下线申请** —— 「渠道」须拆分为两个互不相同的概念并分别命名：**平台渠道**（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑，管上线与到期）与**品牌授权**（小程序下的品牌线，如维京，管可售品牌）。渠道上下线**不支持自助，须联系 SR**，该指引须在 App 内保留。

> **待确认** `TODO(REQ-STM-009)`：①两个概念的最终命名与页面归属（现状分散在「2.0 店铺信息」与「渠道信息」两个 Tab，设计稿又把平台渠道画在「基础信息」Tab）；②**渠道状态模型不统一** —— 零跑按服务项分别记状态（洗车已上线 / 补胎已上线），其余按渠道整体记；③平台渠道枚举须与[财务](./10-FIN-财务与对账.md#4106-业务规则)、[返利](./11-RBT-返利中心.md#4113-多维筛选)、[业绩](./12-PRF-经营业绩与报表.md#412-经营业绩与报表)统一，收敛进[主数据](../Continental-Retail-APP-PRD.md#5-主数据)；④渠道上下线申请是否做成 App 内可提交的申请单。

**REQ-STM-010 经营范围的三类资质** —— 经营范围由三套独立流程构成，须分别落地：**会员体系门店**（需申请，准入条件为具备指定服务清单，现状为「待申请」）、**CATI 认证轮胎技术检测中心**（马牌授权，门店只可查看）、**单独服务项**（门店自助逐项开关）。单独服务项的开通须同时勾选同意《德国马牌门店非轮胎项目服务协议》，协议同意与开通为同一次提交；带「会员」标记的服务项归属会员体系。

> **待确认** `TODO(REQ-STM-010)`：①会员体系门店的申请表单、审核方与时效；②CATI 认证是否有 App 内可发起的路径，还是纯线下授权；③单独开通带「会员」标记的服务项与申请会员体系门店之间是前置、等价还是无关。

**REQ-STM-011 开票方式与 13% 扣除** —— 开票方式为二选一：**自行开票**（需自备服务费电子发票资质、登录**百望云**完善开票信息、填写并上传对公银行信息）与**非自行开票**（**服务费货款自动扣除 13%**，定期打款到小程序绑定的银行卡）。两种方式的说明条文须原样展示；「非自行开票」路径下无需维护对公银行账户。

> **待确认** `TODO(REQ-STM-011)`：①**13% 与[财务模块的通道费 / 平台手续费是什么关系](./10-FIN-财务与对账.md#4106-业务规则)** —— 现状收入详情只显示通道费，13% 无处体现，门店无法对账，须与 `TODO(REQ-FIN-011)` 一并解决；②百望云是否需要在 App 内打通，还是保留外跳；③切换开票方式的生效时点、是否可反复切换、对已生成结算单的影响。

**REQ-STM-012 协议中心的清单与状态** —— 协议中心承载 4 项：营业执照（状态「已上传」）与三份协议（小程序轮胎合作协议 / 非轮胎项目服务协议 / 认证轮胎技术检测中心合作协议，状态「已签署」）。营业执照同时存在于[营业执照信息 Tab](#493-营业执照信息)，两处须同源并指定唯一编辑主入口。协议正文须可完整查看。

> **待确认** `TODO(REQ-STM-012)`：①**未签署 / 未上传态的形态与签署交互**（现状截图四项均为完成态，无从确认）；②签署是否需要电子签名与留痕，是否计入[审计日志](../Continental-Retail-APP-PRD.md#6-后台管理)；③协议全文页应展示签署实例（含乙方主体与签署时间），现状展示的疑似模板，「乙方」栏为空。

**REQ-STM-013 第三方系统初始密码不得明文承载** —— 现状把「百望云账号初始密码」放在协议中心供门店自行查看。**App 内不得以明文常驻方式展示任何第三方系统的账号密码。**

> **待确认** `TODO(REQ-STM-013)`：替代方案待定 —— 一次性查看后失效、改由后台按需重置下发、或 App 完全不承载（仅保留百望云官方找回路径）。决策方：安全 / 产品。

**REQ-STM-014 合作协议义务的系统承接** —— 《德国马牌轮胎小程序线下门店合作协议》中的可执行义务须由系统承接而非仅靠门店自觉：①小程序引流产生的轮胎销售须在**下月 15 号前**从当地认证经销商完成补货；②安装前须向消费者索取**安装码**并核销；③消费者要求开票时不得拒绝。

> **待确认** `TODO(REQ-STM-014)`：①「下月 15 号前补货」是否做成周期性[提醒](./04-RMD-提醒.md#44-提醒)或[首页待办](./02-HOM-APP首页与导航.md#423-店长首页)，未完成是否需要预警；②协议中的「安装码」与[销售模块的核销码](./03-SAL-销售.md#434-核销)是否同一物，术语须统一；③三条义务是否需要在管理后台侧有对应的监控或考核。

## 4.9.7 验收标准

1. 技工进入门店管理时，所有「修改」「添加店员」入口不可见；
2. 门店编码、门店名称等主数据字段为只读，与马上下单一致；
3. 营业执照上传支持拍照与相册两种方式，弱网下失败可重试且不丢失已填字段；
4. 渠道到期状态与实际签约状态一致，已过期渠道有明显视觉标记；
5. 每个可编辑字段都有明确的可编辑标识，修改交互模型全 App 统一，不出现「同一页面部分字段逐个改、部分字段整页改」（[REQ-STM-007](#496-业务规则)）；
6. 「平台渠道」与「品牌授权」在文案上明确区分，不出现两处都叫「渠道」的情况（[REQ-STM-009](#496-业务规则)）；
7. 单独服务项未勾选协议时「保存」不可提交，协议全文可从勾选行直接打开（[REQ-STM-010](#496-业务规则)）；
8. 开票方式页完整展示两种方式的全部说明条文，含 13% 扣除比例，且文案完整无断句（[REQ-STM-011](#496-业务规则)）；
9. App 内任何页面不出现第三方系统的明文账号密码（[REQ-STM-013](#496-业务规则)）；
10. App 内所有门店管理页面**不出现「请登录接单宝小程序」类引导**，全部改为 App 内路径（[REQ-STM-011](#496-业务规则)）。

> 第 5~10 条为本次逐图核看后新增。

---

## 附：本模块归拢信息

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

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

| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 门店基础数据结果集 | Mini Program Backend | HTTPS | 调用**马上下单**后台接口 |
| 2 | 门店服务信息数据结果集 | Mini Program Backend | HTTPS | 马上下单 |
| 3 | 营业执照信息结果集 | Mini Program Backend | HTTPS | 马上下单 |
| 4 | 渠道信息结果集 | Mini Program Backend | HTTPS | 马上下单 |
| 5 | 经营范围信息结果集 | Mini Program Backend | HTTPS | **O2O** —— 会员体系开通、CATI 开通、单独服务项、开票方式 |
| 6 | 收款信息结果集 | Mini Program Backend | HTTPS | **O2O 平安账号模块** —— 企业银行账号、改绑手机、解绑银行卡 |
| 7 | 门店员工列表结果集 / 员工详细信息 | Mini Program Backend | HTTPS | 马上下单 |

门店管理模块数据集（摘自主文件[附录 A.7](../Continental-Retail-APP-PRD.md#a7-门店管理)）。这是各模块中附录 A 覆盖最完整的一节，7 条基本覆盖了本模块的页面。

三处需要在回灌时处理：

1. **第 6 条「收款信息结果集」应归入[财务与对账](./10-FIN-财务与对账.md#4105-银行账号)** —— 正文把银行账号写在 4.10.5，附录 A.7 与[附录 C 的来源表](../Continental-Retail-APP-PRD.md#附录-c-图表清单)却把它归到门店管理。同一份数据在三处被分到两个模块，须择一。另注意本条揭示了银行账号模块的现状名称是「**平安账号**」，这正是 [10.3 的 C11](../Continental-Retail-APP-PRD.md#103-跨文档阻塞项) 里列为「无归属」的那个功能 —— 它其实已经有归属了。
2. **第 4 条「渠道信息结果集」写的是马上下单**，但现状「渠道信息」Tab 展示的是小程序品牌授权（维京），而平台渠道状态在「2.0 店铺信息」Tab 下。[REQ-STM-009](#496-业务规则) 拆分两个概念后，这一条也须拆成两个数据集并分别标注来源。
3. **缺两个数据集**：本次拆分发现的**门店本地化服务项目价目表**（[REQ-STM-008](#496-业务规则)）与**协议签署状态**（[REQ-STM-012](#496-业务规则)）在 A.7 中无对应条目，须补。前者来源为 O2O，后者为 O2O 协议中心。

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

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

| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 查看门店信息 | ✅ | 🔸 | 技工只读，基本无门店管理权限 |
| 修改基础信息 / 项目信息 / 营业执照 | ✅ | ✗ | |
| **人员管理与授权** | ✅ | ✗ | 高风险，需审计 |
| 协议中心 | ✅ | 🔸 | 技工只读 |

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

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

> 本次拆分建议为矩阵**补三行**：
>
> - **经营范围与资质申请**（店长 ✅ / 技工 ✗）—— 会员体系门店申请、单独服务项开关，涉及门店对外承诺；
> - **开票方式**（店长 ✅ / 技工 ✗）—— 直接影响 13% 扣除与打款账户，风险等级等同财务操作，不宜并入「查看门店信息」；
> - **本地化服务项目定价**（店长 ✅ / 技工 ✗）—— 对外报价依据。
>
> 另需注意：本模块的 🔸 有两种含义 ——「查看门店信息」的 🔸 指技工可看基础信息但看不到修改入口，「协议中心」的 🔸 指技工可读协议全文。两者实现方式不同，回灌时建议在备注中写清。

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

| 编号 | 待确认内容 | 建议决策方 |
| --- | --- | --- |
| REQ-STM-001 | **「可用系统」授权模型**（取值集合、与角色的关系）；另需补店员删除 / 停用链路与三套角色词汇的收敛 | 架构 / 产品 |
| REQ-STM-002 | 「2.0 店铺信息」与「门店项目信息」的对应关系（设计稿未出稿，须补稿后才能比对） | 业务 |
| REQ-STM-003 | 营业执照等资质变更的审核流程；是否存在证照 OCR 识别回填 | 运营 |
| REQ-STM-004 | 协议中心与延保条款是否合并（须覆盖三类协议） | 法务 / 产品 |
| REQ-STM-006 | 渠道到期是否产生首页待办或预警（主文件误标为 REQ-STM-007） | 产品 |
| REQ-STM-007 | 门店主数据中 App 内可编辑的字段范围；修改交互模型的统一（主文件误标为 REQ-STM-008） | 架构 |
| **REQ-STM-008** | 本地化服务项目定价是否需管控 / 审核；与「单独服务项」和销售取价的关系 | 业务 / 产品 |
| **REQ-STM-009** | 「平台渠道」与「品牌授权」的拆分命名与归属；零跑的分服务项状态模型；**平台渠道枚举统一**；SR 申请是否进 App | 产品 / 主数据 |
| **REQ-STM-010** | 会员体系门店的申请流程与审核方；CATI 是否可 App 内发起；「会员」标记服务项与会员体系门店的关系 | 运营 / 业务 |
| **REQ-STM-011** | **13% 扣除与财务通道费 / 平台手续费的关系**；百望云是否打通；开票方式切换的生效时点与限制 | 财务 |
| **REQ-STM-012** | 协议未签署态的签署交互；是否需电子签名与审计留痕；协议实例（乙方 + 签署时间）的展示 | 法务 / 架构 |
| **REQ-STM-013** | 百望云初始密码的替代承载方案（一次性查看 / 后台重置 / 不承载） | 安全 / 产品 |
| **REQ-STM-014** | 「下月 15 号前补货」是否做成提醒或待办；「安装码」与核销码是否同一物；三条协议义务是否需后台监控 | 业务 / 产品 |

门店管理模块待确认项，共 13 条（主文件 [10.2.9](../Continental-Retail-APP-PRD.md#1029-门店管理stm) 原 6 条 + 本次新增 7 条）。**加粗编号为本次拆分新增**，回灌时需一并写入主文件 10.2.9，并同步[附录 D.2](../Continental-Retail-APP-PRD.md#d2-模块级追溯汇总) 的 STM 行（8 / 6 / 25% → **14 / 13 / 7%**）与第 10.2 节总数。

> 回灌 10.2.9 时须同时把原表中「REQ-STM-007 渠道到期」「REQ-STM-008 主数据边界」两行改号为 006 / 007，详见 [4.9.6 的编号错位说明](#496-业务规则)。
>
> 完成度 7% 是本模块的真实状态：7 条既有需求里只有 REQ-STM-005（技工权限）没有待确认，新增的 7 条全部带 TODO。这不代表本模块难做，而是**它的需求此前几乎只有截图没有正文** —— 91 行正文承载 14 张图，其中 12 张此前没有任何文字说明。新增的 7 条里 REQ-STM-008、010、011、012、014 的**事实部分已由截图确认**，待确认的是流程归属与跨模块口径。

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

| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 设计稿-门店管理（四 Tab + 门头照 + 门店卡 + 收款信息入口 + **渠道到期状态放在基础信息 Tab**；渠道只有 4 个且数据已过时） | `../app-design-images/门店管理.png` |
| 2 | 设计稿-人员管理（**占位数据**：三卡同名、可用系统 4 图标为两组重复；**无技工卡、无删除店员入口**；角色词汇「店铺管理员」与「店长权限」并存） | `../app-design-images/人员管理.png` |
| 3 | 现状-O2O 店铺管理基础信息（九字段；**整页只读、无修改入口**；测试数据「豌豆的小店」） | `../mini-program-images/O2O/店铺管理-基础信息.png` |
| 4 | 现状-O2O 店铺管理 2.0 店铺信息（**逐字段修改**；6 个平台渠道含车点点与零跑；**门店本地化服务项目价目表**） | `../mini-program-images/O2O/店铺管理-2.0店铺信息.png` |
| 5 | 现状-O2O 店铺管理渠道信息（**几乎空页**；实为小程序品牌授权「维京 关闭」，与平台渠道同名异义；「渠道上下线请联系 SR」） | `../mini-program-images/O2O/店铺管理-渠道信息.png` |
| 6 | 现状-O2O 店铺管理营业执照信息（仅照片 + 企业名称 + 统一社会信用代码；**测试数据**为一家 IT 公司） | `../mini-program-images/O2O/店铺管理-营业执照信息.png` |
| 7 | 现状-O2O 修改营业执照信息（三条填写须知；「更换图片」+ 两个可编辑输入框；**是否有 OCR 回填无法确认**） | `../mini-program-images/O2O/修改营业执照信息.png` |
| 8 | 现状-O2O 修改营业执照信息上传方式选择（拍照 / 从手机相册选择 / 取消） | `../mini-program-images/O2O/修改营业执照信息-上传方式选择.png` |
| 9 | 现状-O2O 经营范围与开票方式（两行入口页；**标题「经营范围」与内容含开票方式不匹配**） | `../mini-program-images/O2O/经营范围与开票方式.png` |
| 10 | 现状-O2O 经营范围详情（**三类资质**：会员体系门店「待申请」/ CATI「查看」/ 单独服务项「管理」；含 CATI 定义原文；**大量回归测试数据**） | `../mini-program-images/O2O/经营范围详情.png` |
| 11 | 现状-O2O 选择开票方式（单选；**非自行开票自动扣除 13%**；自行开票需登录**百望云**；含一句未写完的文案） | `../mini-program-images/O2O/选择开票方式.png` |
| 12 | 现状-O2O 单独服务项开通情况（7 个开关，3 个为回归测试数据；带「会员」标记；**保存前须勾选同意非轮胎项目服务协议**） | `../mini-program-images/O2O/单独服务项开通情况.png` |
| 13 | 现状-O2O 协议中心（4 项：营业执照「已上传」+ 三份协议「已签署」；**四条说明含百望云初始密码提示**；**未签署态无截图**） | `../mini-program-images/O2O/协议中心.png` |
| 14 | 现状-O2O 小程序线下门店合作协议（甲乙方 + 九条门店义务，含**下月 15 号前补货**、**索取安装码并核销**、不得拒开发票；**乙方栏空白**） | `../mini-program-images/O2O/小程序线下门店合作协议.png` |

门店管理模块配图清单，14 张（设计稿 2 / 现状-O2O 12）。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容大幅补充 —— 原清单中第 4~14 行基本是文件名的复述，主文件附录 C 回灌时应一并更新。

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

- **设计稿只覆盖 2 个页面**（门店管理首页、人员管理），且两张都是占位数据。四个 Tab 里只出了「基础信息」一个，「门店项目信息 / 营业执照信息 / 渠道信息」三个 Tab 全部未出稿 —— 这直接导致 `TODO(REQ-STM-002)` 无法比对、无法关闭。
- **人员管理的关键信息全是占位**：三张卡同名、可用系统只有重复图标无文字、全部是「店长权限」没有技工样例。这一页在设计稿补齐前无法开发。
- **回归测试数据污染严重**：经营范围与单独服务项两页共 13 个服务标签中，「测试无需领取的 / 回归531会员 / 全回归1028 / 回归测试 / 回归521 / 回归531单项」6 个是 QA 数据，占了近一半，真实服务项清单无法从截图确认。
- **缺三类关键截图**：①协议**未签署 / 未上传态**与签署交互（卡 `TODO(REQ-STM-012)`）；②会员体系门店的**申请表单**（现状为「待申请」，点进去是什么完全未知，卡 `TODO(REQ-STM-010)`）；③营业执照保存后的**审核状态提示**（卡 `TODO(REQ-STM-003)`）。这三处补采成本不高，建议优先。

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

逐张核看 14 张配图后，新增 **7 条编号需求**（REQ-STM-008 ~ 014）、**修订 3 处既有内容**、发现 **1 处编号错位 + 1 处 D.2 计数错误**，另记 **6 条无编号观察**。

**新增需求**：

| 编号 | 名称 | 触发证据 |
| --- | --- | --- |
| REQ-STM-008 | 本地化服务项目与自主定价 | 2.0 店铺信息 Tab 下的「门店本地化服务项目」价目表（七项以上，带独立修改入口） |
| REQ-STM-009 | 渠道口径与上下线申请 | 「渠道」二义（平台渠道 6 个 vs 小程序品牌授权）+ 零跑分服务项状态 + 「上下线请联系 SR」 |
| REQ-STM-010 | 经营范围的三类资质 | 经营范围详情的三个分组与三个动词（待申请 / 查看 / 管理）+ 单独服务项的协议勾选 |
| REQ-STM-011 | 开票方式与 13% 扣除 | 选择开票方式页两张卡片的全部说明条文 |
| REQ-STM-012 | 协议中心的清单与状态 | 协议中心 4 项 + 两套状态词 + 营业执照双入口 + 合作协议「乙方」空白 |
| REQ-STM-013 | 第三方系统初始密码不得明文承载 | 协议中心说明第 4 条 + 开票方式页星号补充（百望云初始密码） |
| REQ-STM-014 | 合作协议义务的系统承接 | 合作协议第 1 / 5 / 7 条（下月 15 号前补货、索取安装码并核销、不得拒开发票） |

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

1. **主流程补入「三种修改交互模型」的说明** —— 现状基础信息只读、2.0 店铺信息逐字段改、营业执照整页改，设计稿又是底部单按钮提交整页，四者互不相同。已并入 [REQ-STM-007](#496-业务规则) 并新增[验收标准第 5 条](#497-验收标准)。
2. **REQ-STM-001 扩容** —— 除原有的「可用系统取值集合」外，补入店员删除 / 停用链路缺失、以及「店铺管理员 / 店长权限 / 店长·技工」三套角色词汇需收敛两项。
3. **REQ-STM-004 的范围扩大** —— 协议实际有三类（协议中心 4 项、业务动作内嵌协议、延保条款），原表述只提了前两者中的一个与延保条款。

**发现的编号问题**：

- **编号错位** —— REQ-STM-006 / 007 分别挂着 `TODO(REQ-STM-007)` / `TODO(REQ-STM-008)`，10.2.9 也沿用了错号。按「正文规则编号为准」修正为 006 / 007。
- **D.2 计数错误** —— STM 行写「需求条数 8」，但正文只有 REQ-STM-001~007 共 7 条且无空号。「8」应是被上述错位带偏的结果，回灌时改为 7（叠加本次新增后为 14）。

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

1. **同一门店两个名字** —— 基础信息 Tab 的「负责人姓名 豌豆」与 2.0 店铺信息 Tab 的「联系人 宛玉」。是两个不同角色字段还是数据不同步，**本图无法确认**，须在字段口径中明确。
2. **设计稿渠道数据已过时** —— 抖音团购在设计稿标「未上线」，现状为「已上线」；设计稿还漏了车点点与零跑两个渠道。
3. **手机号未脱敏** —— 设计稿 13496913568、现状 13419691597 均完整显示，与[银行账号页](./10-FIN-财务与对账.md#4105-银行账号)的脱敏口径问题同源，须统一处理。
4. **页面标题与内容不匹配** —— 「经营范围」页实际含并列的「开票方式」。
5. **现状文案有断句** —— 开票方式页「请确认您已将收款方式转成银行卡收款，如需修改收款。」句子未写完。
6. **服务项名称混有回归测试数据** —— [经营范围详情](#494-经营范围与开票方式)与[单独服务项开通页](#494-经营范围与开票方式)的服务标签里实测混有 `测试无需领取的` / `回归531会员` / `全回归1028` / `回归测试` / `回归521` / `回归531单项` 六个非真实服务项，单独服务项开通页 7 行开关中有 3 行属此类。这批数据由 O2O 侧维护，清理属 O2O 责任，本 PRD 不为此提需求，仅提示**勿据这两张图统计服务项数量**。与[营销与会员](./13-MKT-营销与会员.md#4132-会员权益)的会员体系开通引导页是同一份服务清单、同一批脏数据。

另有一条跨模块的归属问题需要在回灌时裁决：**「收款信息 / 银行账号（O2O 平安账号模块）」在正文中属[财务 4.10.5](./10-FIN-财务与对账.md#4105-银行账号)，在[附录 A.7](#附-1-业务数据字典主文件附录-a7) 与附录 C 来源表中却属门店管理**，且设计稿的门店管理首页确实有「收款信息 >」入口。建议：**数据与页面归 FIN，门店管理保留一个跳转入口**，附录 A.7 第 6 条与来源表相应改归 FIN。同时这也解决了 [10.3 的 C11](../Continental-Retail-APP-PRD.md#103-跨文档阻塞项) 中「平安账号无归属」一项 —— 它已经有归属了，只是记在了两个地方。