53 KiB
4.9 门店管理
本文件是【门店管理 STM】模块需求的编辑入口。 主文件
../Continental-Retail-APP-PRD.md第 4.9 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。 两者不一致时以本文件为准。 目录约定见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（见三版底部导航方案）
页面内容 —— 四个 Tab：基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息；另有人员管理、收款信息、经营范围与开票方式、协议中心
主流程 —— 进入门店管理 → 切换 Tab 查看 → 点击「修改」提交变更 →（如需）等待审核
现状有三种互不相同的「修改」交互模型，见各图说明与 REQ-STM-007：基础信息 tab 整页只读、无任何修改入口；2.0 店铺信息 tab 是逐字段「修改」链接；营业执照 tab 是整页「修改执照信息」按钮 + 独立编辑页。设计稿统一为底部一个「修改」按钮，与现状三种模型都不一致。字段级可编辑性必须逐字段定义。
权限规则 —— 店长可以修改门店基础信息，添加和修改人员，修改门店项目信息，营业执照信息；技工基本没有门店管理权限
数据来源 —— O2O（店铺管理、经营范围、协议）、马上下单（门店主数据）、App Backend（人员与授权）
4.9.1 目标形态
页面内容 —— App 门店管理的设计稿：四个 Tab（基础信息 / 门店项目信息 / 营业执照信息 / 渠道信息，当前选中「基础信息」）之下依次是门头照通栏、门店卡、负责人与联系方式、「收款信息 >」入口和一组渠道到期状态（高德、美团均标 已过期），底部为描边「修改」按钮。
关键交互 —— ①点四个 Tab → 切换内容；②点「收款信息 >」→ 进入二级页（现状对应银行账号）；③点底部「修改」→ 进入编辑态提交变更；④渠道行本图未见 > 或可点标识，是否可下钻无法确认。
可用角色 —— 店长 ✅；技工 🔸 只读（附录 B「查看门店信息」为 🔸，「修改基础信息」为 ✗，故技工看到本页时底部「修改」按钮不可见，见验收标准第 1 条）。
需求关联 —— REQ-STM-002 Tab 口径、REQ-STM-006 渠道到期提醒、REQ-STM-007 主数据边界、REQ-STM-009 渠道口径
三处与现状对不上，都需要在开发前定：
页面内容 —— App 人员管理的设计稿：顶部是当前操作人卡（带橙色「店铺管理员」标签），下方两张店员卡各含姓名、「店长权限」标签、「账户设置 >」入口与一行「可用系统」图标，底部为通栏「添加店员」，三张卡姓名相同、图标重复排列，属占位数据。
关键交互 —— ①点「账户设置 >」→ 进入该店员的账户与权限设置；②点底部「添加店员」→ 新增店员流程；③「可用系统」图标行本图未见可点标识，是在账户设置里配置还是就地可点，无法确认。
可用角色 —— 店长 ✅；技工 ✗（附录 B「人员管理与授权」标为高风险、需审计，技工完全不可见，含深链拦截）。
需求关联 —— REQ-STM-001 人员授权模型、REQ-STM-005 技工权限
「可用系统」是一个独立于角色的授权维度 —— 它意味着人员授权不是单一角色开关，而是「角色 + 可访问子系统集合」的二维模型（如某店员有店长权限但只开通 O2O 与采购）。这与 REQ-PUR-001（技工采购授权）是同一套机制。可用系统的取值集合、与角色的关系 ——
TODO(REQ-STM-001)。
设计稿另有三处缺口：
- 图标没有文字标签，「可用系统」到底有哪几个系统、每个图标代表谁，从设计稿完全读不出来。这正是
TODO(REQ-STM-001)要解决的取值集合问题 —— 在它关闭前，本页无法进入开发。- 角色词汇有三套：本页的「店铺管理员」（当前操作人）与「店长权限」（店员卡），加上第 3 章定义的「店长 / 技工」。三者是同义、包含还是并列，须收敛为一套，否则权限矩阵无法落地。
- 没有一张技工卡片，也没有删除或停用店员的入口。店员离职是门店高频场景，缺了这条链路，人员管理无法闭环。已并入 REQ-STM-001。
4.9.2 门店基础信息与渠道信息
页面内容 —— O2O 店铺管理的「基础信息」Tab（四个 Tab 为基础信息 / 2.0店铺信息 / 营业执照信息 / 渠道信息），内容是门店名称、门店主编码、收款信息、负责人姓名、联系方式、门店地区、详细地址、门店评分、门头照片九行只读字段，本图为测试数据（门店名称「豌豆的小店」、负责人「豌豆」）。
关键交互 —— ①点 Tab → 切换；②点「收款信息 查看详情 >」→ 进入收款信息二级页。本页没有任何修改入口 —— 整页只读。
可用角色 —— 店长 ✅；技工 🔸 只读。
需求关联 —— REQ-STM-002 Tab 口径、REQ-STM-007 主数据边界
与设计稿的字段差异：现状把地址拆成「门店地区 + 详细地址」两个字段，设计稿合并为一个「门店地址」；现状叫「门店主编码」，设计稿叫「门店编码」（编码值 3449155 一致）。这两处属字段口径，以现状为准，并在设计稿评审时提出。
「收款信息」的模块归属存在冲突：附录 A.7 第 6 条把「收款信息结果集（O2O 平安账号模块 —— 企业银行账号、改绑手机、解绑银行卡）」列在门店管理名下，而正文把银行账号写在财务与对账 4.10.5 里；附录 C 的来源表也把两张银行账号截图归到门店管理。同一份数据在三处被分到两个模块，须择一。建议按用户心智留在财务模块，附录 A.7 与附录 C 来源表据此改归 FIN。
页面内容 —— 「2.0 店铺信息」Tab，由门店联系信息（每行右侧各有一个橙色「修改」链接）、渠道上线与到期状态六行（高德与美团均 已过期，零跑按服务项分别记状态）、门店本地化服务项目价目表三块组成。
关键交互 —— ①点任一行的「修改」→ 单独编辑该字段；②点「门店本地化服务项目」的「修改」→ 编辑价目表；③渠道行无修改入口，为只读展示。
可用角色 —— 店长 ✅；技工 ✗（涉及对外报价与渠道状态）。
需求关联 —— REQ-STM-002 Tab 口径、REQ-STM-006 渠道到期提醒、REQ-STM-008 本地化服务项目与自主定价、REQ-STM-009 渠道口径
本图是 STM 模块信息量最大的一张，暴露三件 PRD 完全没写的事：
- 门店可以自主维护一张服务项目价目表（两列「名称 / 价格」，本图可见泰克贴片补胎 50、泰克蘑菇钉补胎 100、四轮换位 70、普通四轮定位 99、全车手工打蜡-轿车 148、全车手工打蜡-SUV/MPV 198、标准洗车-轿车 30，末行被截断，即七项以上、价格 30~198 元不等）。这是门店对外报价的依据，直接影响销售与财务收入，PRD 全文一字未提。已记为 REQ-STM-008。
- 现状渠道有 6 个，且零跑的状态是按服务项分别记的（「洗车服务已上线，补胎服务已上线」），而其它 5 个是整体「已上线 / 未上线 / 已过期」。渠道状态模型不统一，见 REQ-STM-009。
- 修改是逐字段的，与设计稿「底部一个修改按钮提交整页」的模型冲突，也与营业执照 Tab 的整页编辑模型冲突。三种模型必须收敛，见 REQ-STM-007。
另一处数据疑点：本 Tab 的「联系人」为宛玉，而基础信息 Tab的「负责人姓名」为豌豆，同一门店两个名字。二者是两个不同角色字段（负责人 ≠ 联系人）还是数据不同步，本图无法确认，须在字段口径中明确。
页面内容 —— 「渠道信息」Tab，页面几乎为空，只有一个分组标题「渠道资料 （如需申请渠道上下线请联系 SR）」与其下「小程序」小节里唯一一行灰色的「维京 关闭」。
关键交互 —— 本页无任何可交互控件 —— 纯只读展示，渠道上下线需线下联系 SR（马牌销售代表）办理。
可用角色 —— 店长 ✅ 只读；技工 ✗。
需求关联 —— REQ-STM-009 渠道口径与上下线申请
「渠道」在同一个页面里有两种完全不同的含义：
- 「2.0 店铺信息」Tab 里的渠道 = 外部平台（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑），管的是门店在各引流平台的上线与到期；
- 「渠道信息」Tab 里的渠道 = 小程序内的品牌线（小程序 → 维京 关闭），管的是门店能卖哪些品牌。
两者共用一个词，放在相邻的两个 Tab 里，门店必然混淆。整合进 App 时必须拆成两个术语（如「平台渠道」与「品牌授权」），见 REQ-STM-009。这也是全仓库渠道口径不统一问题的一部分。
另一条可直接成文的规则：渠道上下线不能自助，须联系 SR。App 内是保留这条线下指引，还是做成可提交的申请单，需决策。
现状 Tab 名为「2.0 店铺信息」，设计稿对应位置为「门店项目信息」。二者是否同一内容 ——
TODO(REQ-STM-002)。从截图看两者内容差异很大：现状的「2.0 店铺信息」含联系信息、渠道状态与服务价目表三块，设计稿的「门店项目信息」未出稿，无从比对。这条待确认必须在设计稿补齐后才能关闭。
4.9.3 营业执照信息
页面内容 —— 「营业执照信息」Tab，仅营业执照照片、企业名称、统一社会信用代码三行加底部通栏橙色「修改执照信息」按钮，本图为测试数据（企业名称与轮胎门店业务无关）。
关键交互 —— ①点「修改执照信息」→ 进入编辑页（见下图）；②点照片缩略图是否可放大，本图无法确认。
可用角色 —— 店长 ✅；技工 ✗（附录 B「修改基础信息 / 项目信息 / 营业执照」为 ✗）。
需求关联 —— REQ-STM-003 资质变更审核、REQ-STM-012 协议中心清单
营业执照有两个入口：本 Tab 与协议中心（在那里显示为「营业执照 已上传」）。同一份资质在两处维护，状态是否同源、从哪个入口改，须择一为主入口。
页面内容 —— 营业执照编辑页，上半部为「上传营业执照」及三条填写须知与压着「更换图片」的执照缩略图，下半部为「请确认营业信息」的两个可编辑输入框（企业名称、统一社会信用代码，均已带值），底部为通栏橙色「保存」。
关键交互 —— ①点「更换图片」→ 弹出上传方式选择（见下图）；②点两个输入框 → 直接编辑文本；③点「保存」→ 提交变更。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-STM-003 资质变更审核
三条须知原文，均为可校验的规则，须原样保留：①「请确保证件内容文字清晰可见，证件本身无残缺」；②「仅支持中国大陆工商局或市场监督管理局登记的个体工商户或企业，请提供有效期内的营业执照」；③「无企业名称的个体工商户，营业执照–企业名称栏，请填写营业执照–『法人姓名』，示例数据：张三」。
页面结构是「先传图 → 再确认营业信息」，强烈暗示存在证照 OCR 识别后回填，但本图两个输入框均为可编辑状态、也没有「识别中」之类的提示，是否真有 OCR 无法从本图确认。若确有，需与车牌 OCR一样明确由后端代理调用、客户端不直连。
变更后是否需要审核，本页看不出来 —— 点「保存」是直接生效还是转入待审，无任何提示。
TODO(REQ-STM-003)。
页面内容 —— 上一页点「更换图片」后从底部弹出的选择面板，三项：拍照 / 从手机相册选择 / 取消。
关键交互 —— ①点「拍照」→ 唤起相机；②点「从手机相册选择」→ 打开相册；③点「取消」或遮罩 → 关闭。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-STM-003 资质变更审核（验收标准第 3 条要求两种上传方式并支持弱网重试）
本图直接印证验收标准第 3 条的前半句「支持拍照与相册两种方式」。后半句「弱网下失败可重试且不丢失已填字段」在现状截图中无从验证，属 App 侧新增要求。
营业执照变更是否需要审核、审核在哪个系统完成 ——
TODO(REQ-STM-003)。
4.9.4 经营范围与开票方式
页面内容 —— 标题为「经营范围」的入口页，全页只有「经营范围 >」与「开票方式 非自行开票 >」两行。
关键交互 —— ①点「经营范围 >」→ 进入经营范围详情（见下图）；②点「开票方式 >」→ 进入开票方式选择页。
可用角色 —— 店长 ✅；技工 ✗（涉及资质与资金）。
需求关联 —— REQ-STM-010 经营范围三类资质、REQ-STM-011 开票方式
页面标题是「经营范围」，但内容包含并列的「开票方式」，标题与内容不匹配。整合到 App 时应重命名为「经营范围与开票」或把开票方式移到财务模块下。
页面内容 —— 经营范围详情，由会员体系门店（待申请）/ 认证轮胎技术检测中心（查看）/ 单独服务项（管理）三个互相独立的资质分组构成，其中的服务标签混有大量回归测试数据。
关键交互 —— ①点「待申请 >」→ 发起会员体系门店申请（本图为待申请态，申请表单与流程无法确认）；②点「查看 >」→ 查看 CATI 认证详情；③点「管理 >」→ 进入单独服务项开通页。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-STM-010 经营范围三类资质
三个分组对应三个不同的动词（待申请 / 查看 / 管理），说明它们是三套独立的资质流程，而不是一张清单的三段：
- 会员体系门店 —— 需申请，有准入门槛（必须具备清单内的全部服务）；
- CATI 认证轮胎技术检测中心 —— 由马牌授权，门店只能查看，不能自助申请；
- 单独服务项 —— 门店可自助逐项开通。
PRD 现有正文只把「经营范围」当作一个归属待定的页面（
TODO(REQ-MIN-006)），完全没有涉及这三套流程。已记为 REQ-STM-010。CATI 定义原文（需在 App 内保留）：「CATI（Continental Approved Tire Inspector）是大陆马牌轮胎（中国）有限公司认证的轮胎技术检测中心。该授权中心能够及时处理客户轮胎投诉以及轮胎售后技术咨询服务。」
页面内容 —— 开票方式选择页，「自行开票」与「非自行开票」两张卡片各带一个勾选框、单选（当前选中「非自行开票」），卡片下各列若干条说明，底部为通栏橙色「确认」按钮。
关键交互 —— ①点任一卡片的勾选框 → 切换开票方式（互斥）；②点「确认」→ 提交。切换是否有二次确认、是否有生效时点限制，本图无法确认。
可用角色 —— 店长 ✅；技工 ✗（直接影响资金结算）。
需求关联 —— REQ-STM-011 开票方式与 13% 扣除、REQ-STM-013 百望云初始密码
本图是全模块财务影响最大的一张。「非自行开票」的说明第 1 条写明：「您的服务费货款将自动扣除 13%，并将定期打款到您小程序绑定的银行卡。」
13% 远高于财务模块列出的全部平台费率（0.6%~4%），却在财务模块的收入构成里完全看不到 —— 收入详情页只有「通道费」一项扣减。这两笔扣减的关系必须查清，否则门店对不上账。已记为 REQ-STM-011，并需与
TODO(REQ-FIN-011)一并解决。「自行开票」路径引入了一个 PRD 系统清单里没有的第三方系统 —— 百望云（电子发票平台）：需自备电子发票资质、登录百望云完善开票信息、另填并上传对公银行信息。星号补充「登陆接单宝小程序，点击『协议中心』查看百望云初始账户密码」既是又一处「请回小程序」的引导，也是一处安全问题，见 REQ-STM-013。
另注：「非自行开票」说明第 2 条「请确认您已将收款方式转成银行卡收款，如需修改收款。」句子未写完，属现状文案缺陷，App 内须补全。
页面内容 —— 单独服务项开通页，主体是 7 行服务项开关（部分名称右侧带橙色「会员」小标，其中 3 项是回归测试数据），底部为一行协议勾选加通栏橙色「保存」。
关键交互 —— ①逐项点开关 → 开通 / 关闭该服务；②点协议名称 → 打开协议全文；③勾选协议后点「保存」→ 提交。未勾选协议时「保存」是否禁用，本图无法确认。
可用角色 —— 店长 ✅；技工 ✗。
需求关联 —— REQ-STM-010 经营范围三类资质、REQ-STM-004 协议体系
两条可直接成文的规则：①开通服务项须先同意《德国马牌门店非轮胎项目服务协议》，协议同意与服务开通是同一次提交；②带「会员」标记的服务项归属会员体系，与上一页「会员体系门店必须包含以下服务」的清单存在交集 —— 单独开通这些项与申请会员体系门店是什么关系（前置条件？自动满足？），须明确。
这条协议同时说明协议中心不是唯一的协议入口 —— 协议也会内嵌在业务动作里，REQ-STM-004 的「协议体系是否合并」需要把这类内嵌协议一并纳入考虑。
经营范围在设计稿中被放进了个人中心，在现状中属于店铺管理。归属待定 ——
TODO(REQ-MIN-006)。
4.9.5 协议中心
页面内容 —— 协议中心，营业执照（已上传）与三份协议（均已签署）共四张卡片纵向排列、下方接 4 条说明，本图四项均为完成态，未签署 / 未上传的形态无法确认。
关键交互 —— ①点任一卡片 → 打开对应协议全文或执照详情（见下图）；②已签署项是否可重新签署、未签署项如何发起签署，本图无法确认。
可用角色 —— 店长 ✅；技工 🔸 只读（附录 B「协议中心」为 🔸）。
需求关联 —— REQ-STM-004 协议体系、REQ-STM-012 协议中心清单与状态、REQ-STM-013 百望云初始密码
四条说明原文：①「如您的门店已参与德国马牌的非轮胎活动，请确认您已签署相关服务协议」；②「如果您参与非轮胎项目，且选择了自行开票，请注意及时上传对公银行账户信息」；③「如果您未参与非轮胎项目或您参与了非轮胎项目后，选择的是『非自行开票』，则无需维护对公银行账户信息」；④「百望云账号密码仅为初始密码，登录后请及时修改」。
说明 ②③ 把**协议中心 ↔ 开票方式 ↔ 对公银行账户**三者锁在一起：是否需要维护对公账户，取决于「是否参与非轮胎项目」与「开票方式选哪种」的组合。这套判定逻辑必须在 App 内成文，否则门店不知道自己该不该填银行信息。
说明 ④ 与开票方式页的星号补充合起来意味着：协议中心是一个第三方系统初始密码的分发渠道。密码明文常驻在一个门店随时可进的页面里，风险明显。已记为 REQ-STM-013。
另注状态词有两套：营业执照用「已上传」，三份协议用「已签署」。它们的完成条件与法律效力不同，混在一张列表里易误解，App 内建议分组或补充状态说明。
页面内容 —— 《德国马牌轮胎小程序线下门店合作协议》全文页，开头为甲方（大陆马牌轮胎（中国）有限公司，简称"德国马牌"）与空白的乙方，其后本屏可见「乙方需履行以下几项义务」的第 1~9 条（第 9 条被截断）。
关键交互 —— 无交互，仅作内容佐证；页面为可滚动长文，本图未见「同意」「签署」按钮（该协议已处于已签署态）。
可用角色 —— 店长 ✅ 只读；技工 🔸 只读。
需求关联 —— REQ-STM-004 协议体系、REQ-STM-014 合作协议义务的系统承接
协议正文里有三条可被系统承接的门店义务，目前 PRD 里一条都没有对应功能：
- 第 1 条：「由德国马牌轮胎小程序引流产生的轮胎销售必须在下月 15 号前从当地认证经销商处完成补货。」—— 一条带明确截止日的周期性义务，天然适合做成提醒或首页待办。
- 第 5 条：「乙方需要在轮胎安装前向终端消费者索取安装码，并核销。」—— 与销售模块的核销是同一动作，且核销又是可提现金额的计算基数，三者须口径一致。
- 第 7 条：「如终端消费者需要开具发票，乙方必须按终端消费者实际支付金额开具……不得以任何理由拒绝开具发票。」—— 与开票方式的选择相互作用。
已记为 REQ-STM-014。
「乙方」栏空白但状态显示「已签署」 —— 本页展示的可能是协议模板而非门店签署后的实例。App 内应展示带乙方主体与签署时间的实例，否则「已签署」无从取证。本图无法确认该页是否另有签署信息区被折叠。
协议中心与延保零售商使用条款是两套独立的协议体系，整合后是否合并为统一的「协议与条款」入口 ——
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 渠道到期提醒 —— 高德 / 美团 / 抖音 / 百度等渠道到期应产生首页待办或预警 TODO(REQ-STM-006)
REQ-STM-007 主数据边界 —— 门店主数据来源为马上下单（第 5 章），App 内可改的字段范围待定 TODO(REQ-STM-007)。须同时定义修改交互模型 —— 现状三种模型并存（基础信息只读 / 2.0 店铺信息逐字段改 / 营业执照整页改），App 内须统一，并逐字段标注可编辑性
REQ-STM-008 门店本地化服务项目与自主定价 —— 门店可在「2.0 店铺信息」下维护一张本地化服务项目价目表（名称 + 价格，现状可见泰克贴片补胎 50、四轮换位 70、全车手工打蜡-SUV/MPV 198 等七项以上），带独立编辑入口。该价目表是门店对外报价依据，须在 App 内可查可改。
待确认
TODO(REQ-STM-008)：①价格是否有上下限管控或需审核；②与经营范围「单独服务项」的关系（同一批服务项还是两套清单）；③与销售开单时的取价关系 —— 开单是否直接引用这张价目表。
REQ-STM-009 渠道口径与上下线申请 —— 「渠道」须拆分为两个互不相同的概念并分别命名：平台渠道（高德 / 美团 / 抖音团购 / 百度 / 车点点 / 零跑，管上线与到期）与品牌授权（小程序下的品牌线，如维京，管可售品牌）。渠道上下线不支持自助，须联系 SR，该指引须在 App 内保留。
待确认
TODO(REQ-STM-009)：①两个概念的最终命名与页面归属（现状分散在「2.0 店铺信息」与「渠道信息」两个 Tab，设计稿又把平台渠道画在「基础信息」Tab）；②渠道状态模型不统一 —— 零跑按服务项分别记状态（洗车已上线 / 补胎已上线），其余按渠道整体记；③平台渠道枚举须与财务、返利、业绩统一，收敛进主数据；④渠道上下线申请是否做成 App 内可提交的申请单。
REQ-STM-010 经营范围的三类资质 —— 经营范围由三套独立流程构成，须分别落地：会员体系门店（需申请，准入条件为具备指定服务清单，现状为「待申请」）、CATI 认证轮胎技术检测中心（马牌授权，门店只可查看）、单独服务项（门店自助逐项开关）。单独服务项的开通须同时勾选同意《德国马牌门店非轮胎项目服务协议》，协议同意与开通为同一次提交；带「会员」标记的服务项归属会员体系。
待确认
TODO(REQ-STM-010)：①会员体系门店的申请表单、审核方与时效；②CATI 认证是否有 App 内可发起的路径，还是纯线下授权；③单独开通带「会员」标记的服务项与申请会员体系门店之间是前置、等价还是无关。
REQ-STM-011 开票方式与 13% 扣除 —— 开票方式为二选一：自行开票（需自备服务费电子发票资质、登录百望云完善开票信息、填写并上传对公银行信息）与非自行开票（服务费货款自动扣除 13%，定期打款到小程序绑定的银行卡）。两种方式的说明条文须原样展示；「非自行开票」路径下无需维护对公银行账户。
待确认
TODO(REQ-STM-011)：①13% 与财务模块的通道费 / 平台手续费是什么关系 —— 现状收入详情只显示通道费，13% 无处体现，门店无法对账，须与TODO(REQ-FIN-011)一并解决；②百望云是否需要在 App 内打通，还是保留外跳；③切换开票方式的生效时点、是否可反复切换、对已生成结算单的影响。
REQ-STM-012 协议中心的清单与状态 —— 协议中心承载 4 项：营业执照（状态「已上传」）与三份协议（小程序轮胎合作协议 / 非轮胎项目服务协议 / 认证轮胎技术检测中心合作协议，状态「已签署」）。营业执照同时存在于营业执照信息 Tab，两处须同源并指定唯一编辑主入口。协议正文须可完整查看。
待确认
TODO(REQ-STM-012)：①未签署 / 未上传态的形态与签署交互（现状截图四项均为完成态，无从确认）；②签署是否需要电子签名与留痕，是否计入审计日志；③协议全文页应展示签署实例（含乙方主体与签署时间），现状展示的疑似模板，「乙方」栏为空。
REQ-STM-013 第三方系统初始密码不得明文承载 —— 现状把「百望云账号初始密码」放在协议中心供门店自行查看。App 内不得以明文常驻方式展示任何第三方系统的账号密码。
待确认
TODO(REQ-STM-013)：替代方案待定 —— 一次性查看后失效、改由后台按需重置下发、或 App 完全不承载（仅保留百望云官方找回路径）。决策方：安全 / 产品。
REQ-STM-014 合作协议义务的系统承接 —— 《德国马牌轮胎小程序线下门店合作协议》中的可执行义务须由系统承接而非仅靠门店自觉：①小程序引流产生的轮胎销售须在下月 15 号前从当地认证经销商完成补货；②安装前须向消费者索取安装码并核销；③消费者要求开票时不得拒绝。
待确认
TODO(REQ-STM-014)：①「下月 15 号前补货」是否做成周期性提醒或首页待办，未完成是否需要预警；②协议中的「安装码」与销售模块的核销码是否同一物，术语须统一；③三条义务是否需要在管理后台侧有对应的监控或考核。
4.9.7 验收标准
- 技工进入门店管理时，所有「修改」「添加店员」入口不可见；
- 门店编码、门店名称等主数据字段为只读，与马上下单一致；
- 营业执照上传支持拍照与相册两种方式，弱网下失败可重试且不丢失已填字段；
- 渠道到期状态与实际签约状态一致，已过期渠道有明显视觉标记；
- 每个可编辑字段都有明确的可编辑标识，修改交互模型全 App 统一，不出现「同一页面部分字段逐个改、部分字段整页改」（REQ-STM-007）；
- 「平台渠道」与「品牌授权」在文案上明确区分，不出现两处都叫「渠道」的情况（REQ-STM-009）；
- 单独服务项未勾选协议时「保存」不可提交，协议全文可从勾选行直接打开（REQ-STM-010）；
- 开票方式页完整展示两种方式的全部说明条文，含 13% 扣除比例，且文案完整无断句（REQ-STM-011）；
- App 内任何页面不出现第三方系统的明文账号密码（REQ-STM-013）；
- App 内所有门店管理页面不出现「请登录接单宝小程序」类引导，全部改为 App 内路径（REQ-STM-011）。
第 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）。这是各模块中附录 A 覆盖最完整的一节，7 条基本覆盖了本模块的页面。
三处需要在回灌时处理：
- 第 6 条「收款信息结果集」应归入财务与对账 —— 正文把银行账号写在 4.10.5，附录 A.7 与附录 C 的来源表却把它归到门店管理。同一份数据在三处被分到两个模块，须择一。另注意本条揭示了银行账号模块的现状名称是「平安账号」，这正是 10.3 的 C11 里列为「无归属」的那个功能 —— 它其实已经有归属了。
- 第 4 条「渠道信息结果集」写的是马上下单，但现状「渠道信息」Tab 展示的是小程序品牌授权（维京），而平台渠道状态在「2.0 店铺信息」Tab 下。REQ-STM-009 拆分两个概念后，这一条也须拆成两个数据集并分别标注来源。
- 缺两个数据集：本次拆分发现的门店本地化服务项目价目表（REQ-STM-008）与协议签署状态（REQ-STM-012）在 A.7 中无对应条目，须补。前者来源为 O2O，后者为 O2O 协议中心。
附-2 权限矩阵（主文件附录 B 本模块分行）
图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
|---|---|---|---|
| 查看门店信息 | ✅ | 🔸 | 技工只读，基本无门店管理权限 |
| 修改基础信息 / 项目信息 / 营业执照 | ✅ | ✗ | |
| 人员管理与授权 | ✅ | ✗ | 高风险，需审计 |
| 协议中心 | ✅ | 🔸 | 技工只读 |
门店管理模块权限矩阵（摘自主文件附录 B）
适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经人员管理「可用系统」授予（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 原 6 条 + 本次新增 7 条）。加粗编号为本次拆分新增，回灌时需一并写入主文件 10.2.9，并同步附录 D.2 的 STM 行（8 / 6 / 25% → 14 / 13 / 7%）与第 10.2 节总数。
回灌 10.2.9 时须同时把原表中「REQ-STM-007 渠道到期」「REQ-STM-008 主数据边界」两行改号为 006 / 007，详见 4.9.6 的编号错位说明。
完成度 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已按实际截图内容大幅补充 —— 原清单中第 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 号前补货、索取安装码并核销、不得拒开发票） |
修订的既有内容：
- 主流程补入「三种修改交互模型」的说明 —— 现状基础信息只读、2.0 店铺信息逐字段改、营业执照整页改，设计稿又是底部单按钮提交整页，四者互不相同。已并入 REQ-STM-007 并新增验收标准第 5 条。
- REQ-STM-001 扩容 —— 除原有的「可用系统取值集合」外，补入店员删除 / 停用链路缺失、以及「店铺管理员 / 店长权限 / 店长·技工」三套角色词汇需收敛两项。
- 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）。
无编号观察（属现状材料问题，不新增需求）：
- 同一门店两个名字 —— 基础信息 Tab 的「负责人姓名 豌豆」与 2.0 店铺信息 Tab 的「联系人 宛玉」。是两个不同角色字段还是数据不同步，本图无法确认，须在字段口径中明确。
- 设计稿渠道数据已过时 —— 抖音团购在设计稿标「未上线」，现状为「已上线」；设计稿还漏了车点点与零跑两个渠道。
- 手机号未脱敏 —— 设计稿 13496913568、现状 13419691597 均完整显示，与银行账号页的脱敏口径问题同源，须统一处理。
- 页面标题与内容不匹配 —— 「经营范围」页实际含并列的「开票方式」。
- 现状文案有断句 —— 开票方式页「请确认您已将收款方式转成银行卡收款，如需修改收款。」句子未写完。
- 服务项名称混有回归测试数据 —— 经营范围详情与单独服务项开通页的服务标签里实测混有
测试无需领取的/回归531会员/全回归1028/回归测试/回归521/回归531单项六个非真实服务项，单独服务项开通页 7 行开关中有 3 行属此类。这批数据由 O2O 侧维护，清理属 O2O 责任，本 PRD 不为此提需求，仅提示勿据这两张图统计服务项数量。与营销与会员的会员体系开通引导页是同一份服务清单、同一批脏数据。
另有一条跨模块的归属问题需要在回灌时裁决：「收款信息 / 银行账号（O2O 平安账号模块）」在正文中属财务 4.10.5，在附录 A.7 与附录 C 来源表中却属门店管理，且设计稿的门店管理首页确实有「收款信息 >」入口。建议：数据与页面归 FIN，门店管理保留一个跳转入口，附录 A.7 第 6 条与来源表相应改归 FIN。同时这也解决了 10.3 的 C11 中「平安账号无归属」一项 —— 它已经有归属了，只是记在了两个地方。