first commit

.vscode/launch.json

@@ -0,0 +1,24 @@
+{
+    // 使用 IntelliSense 了解相关属性。 
+    // 悬停以查看现有属性的描述。
+    // 欲了解更多信息，请访问: https://go.microsoft.com/fwlink/?linkid=830387
+    "version": "0.2.0",
+    "configurations": [
+        {
+            "name": "IAM",
+            "type": "go",
+            "request": "launch",
+            "mode": "auto",
+            "program": "${workspaceFolder}/zd_iam/server/cmd/main.go",
+            "args": ["config","${workspaceFolder}/zd_iam/server/config/config.yaml"]
+        },
+        {
+            "name": "SYSTEM",
+            "type": "go",
+            "request": "launch",
+            "mode": "auto",
+            "program": "${workspaceFolder}/zd_system/server/cmd/system/main.go",
+            "args": ["config","${workspaceFolder}/zd_system/server/config/config.yaml"]
+        }
+    ]
+}

.vscode/settings.json

@@ -0,0 +1,3 @@
+{
+    "editor.mouseWheelZoom": true
+}

00-公司战略/00-公司产品战略目标.md

@@ -0,0 +1,142 @@
+# 公司产品战略目标
+
+## 1. 战略定位
+
+公司围绕连锁经营企业和互联网平台型业务，提供对账、分账、门店经营和行业数字化解决方案。
+
+当前产品战略分为两条主线：
+
+- 纵向发展：围绕连锁门店对账与分账系统深耕，并向更多连锁业态和平台型交易场景拓展。
+- 横向发展：围绕连锁餐饮行业，逐步建设完整的门店经营数字化产品线。
+
+## 2. 战略主线一：对账与分账系统纵向发展
+
+### 2.1 战略目标
+
+以现有营帐通产品为基础，将营帐通拆分和升级为相对独立的连锁业务对账系统与分账系统，分别形成清晰的产品定位、能力边界和商业化路径。
+
+连锁业务对账系统和分账系统不局限于餐饮行业，应逐步拓展到连锁鞋服、连锁零售、连锁药店等连锁经营业态。
+
+分账系统应进一步升级为 SaaS 平台，适配互联网平台业务和担保交易场景。
+
+### 2.2 连锁业务对账系统发展方向
+
+连锁业务对账系统重点解决多门店、多渠道、多平台、多支付方式、多结算周期下的交易核对和差异处理问题。
+
+目标行业包括：
+
+- 连锁餐饮
+- 连锁鞋服
+- 连锁零售
+- 连锁药店
+- 其他多门店连锁经营企业
+
+核心能力方向包括：
+
+- 销售订单对账
+- 支付流水对账
+- 外部平台账单对账
+- 银行入账对账
+- 退款、手续费、补贴、佣金核对
+- 差异识别、差异处理和差异闭环
+- 门店、区域、品牌、总部多层级对账分析
+
+### 2.3 分账系统发展方向
+
+分账系统重点解决多交易主体、多结算主体、多资金账户、多分润规则下的资金分配和结算管理问题。
+
+目标场景包括：
+
+- 连锁门店销售款分账
+- 加盟商结算
+- 品牌监管账户分账
+- 门店钱包
+- 平台商户结算
+- 服务商、供应商、渠道方、运营方分润
+- 担保交易资金结算
+
+分账系统应向 SaaS 平台演进，支持平台型客户快速接入交易、清结算和分账能力。
+
+### 2.4 平台业务与担保交易场景
+
+分账系统需要适配互联网平台业务，特别是存在撮合交易、履约确认、资金暂存、交易完成后分账的担保交易场景。
+
+典型目标场景包括：
+
+- 物流撮合平台
+- 充电桩运营平台
+- 本地生活服务平台
+- 多商户交易平台
+- 其他需要交易担保、履约确认和多方分润的平台业务
+
+核心能力方向包括：
+
+- 交易订单管理
+- 担保交易状态管理
+- 履约确认
+- 资金冻结、解冻、结算和退款
+- 多方分账规则
+- 商户账户和平台账户管理
+- 结算周期管理
+- 对账、清分、分账、出款闭环
+
+## 3. 战略主线二：连锁餐饮行业横向发展
+
+### 3.1 战略目标
+
+围绕连锁餐饮企业完整经营链路，逐步建设餐饮行业数字化系统平台，形成可组合、可扩展、可产品化的行业解决方案。
+
+横向产品线应优先围绕餐饮连锁企业高频、刚需、强协同的业务场景展开。
+
+### 3.2 重点产品线方向
+
+后续重点建设方向包括：
+
+- 收银系统
+- 客服系统
+- 门店生命周期系统
+- 商品管理系统
+- 加盟商管理系统
+- 营运督导系统
+- 门店订货与库存系统
+- 外卖与三方平台运营系统
+- 品牌会员与营销系统
+- 餐饮经营数据平台
+
+### 3.3 与现有产品关系
+
+横向餐饮产品线应与现有产品形成组合方案：
+
+- 营帐通承接订单之后的对账、清分、分账、结算、利润核算场景。
+- 门店选址规划系统承接开店前的区域规划、选址评估、点位审核和开店复盘场景。
+- 门店大数据平台承接集团、品牌、区域、门店、加盟商等多层级经营分析场景。
+
+新建产品线应优先补齐现有产品前后的业务链路，形成从门店开店、日常经营、订单交易、财务结算到经营分析的闭环。
+
+## 4. 产品规划原则
+
+### 4.1 双主线并行
+
+产品规划需要同时服务两类目标：
+
+- 对账与分账能力的跨行业、平台化、SaaS 化发展。
+- 连锁餐饮行业解决方案的横向产品线扩展。
+
+### 4.2 能力复用
+
+对账、分账、账户、结算、规则、报表、权限、主数据等通用能力，应尽量跨产品线复用。
+
+### 4.3 行业适配
+
+跨行业拓展时，应区分通用交易结算能力和行业专属业务对象。对账与分账底层能力应保持通用，行业差异通过业务模板、接入适配、规则配置和报表口径承载。
+
+### 4.4 产品边界清晰
+
+营帐通拆分为连锁业务对账系统和分账系统后，需要明确两者边界：
+
+- 连锁业务对账系统重点负责交易、账单、流水、入账之间的核对和差异闭环。
+- 分账系统重点负责结算主体、分账规则、资金账户、清分分润、出款和结算闭环。
+
+### 4.5 从项目沉淀产品
+
+客户项目中的能力建设，应持续评估其行业共性和产品化价值，优先沉淀为标准产品能力或行业方案模板。

01-角色与治理/00-产品规划负责人角色与产品线定位.md

@@ -0,0 +1,179 @@
+# 产品规划负责人角色与产品线定位
+
+## 1. 角色定位
+
+当前规划角色定义为：面向连锁经营企业和餐饮连锁企业提供信息化解决方案及软件产品的产品总监和产品规划负责人。
+
+该角色不只面向单一餐饮集团内部信息化建设，也面向连锁经营行业、餐饮连锁行业和平台型交易业务的通用信息化需求，负责将行业业务理解、客户项目实践和软件产品能力结合起来，形成可复制、可升级、可拓展的数字化解决方案。
+
+## 2. 核心职责
+
+### 2.1 提供餐饮连锁行业解决方案
+
+围绕餐饮连锁企业在多品牌、多业态、多门店、多经营模式下的经营管理需求，规划行业信息化解决方案。
+
+重点关注：
+
+- 餐饮连锁企业业务流程规划。
+- 集团、品牌、区域、门店、加盟商之间的业务协同。
+- 门店经营、供应链、会员营销、财务结算、数据分析等业务域的系统规划。
+- 各业务系统的功能边界和协同关系。
+- 行业通用能力沉淀和客户差异化适配。
+
+### 2.2 推进对账与分账系统纵向发展
+
+围绕连锁门店对账与分账系统深耕，将现有营帐通产品拆分为连锁业务对账系统和分账系统，并推动其跨行业、平台化、SaaS 化发展。
+
+重点关注：
+
+- 对账业务拓展到连锁餐饮、连锁鞋服、连锁零售、连锁药店等连锁业态。
+- 分账业务从连锁门店分账拓展到互联网平台分账。
+- 分账系统升级为 SaaS 平台。
+- 支持物流撮合平台、充电桩运营平台等平台型业务。
+- 支持担保交易、履约确认、资金暂存、清分分润、结算出款等场景。
+
+### 2.3 持续完善和升级现有产品
+
+基于客户项目、行业变化和门店经营管理需求，持续完善已有产品能力，提高产品成熟度、适配范围和商业竞争力。
+
+当前重点产品包括：
+
+- 连锁企业门店对账分账系统：营帐通。
+- 门店选址规划系统。
+- 门店大数据平台。
+
+### 2.4 围绕餐饮连锁行业拓展产品线
+
+基于餐饮连锁企业完整经营链路，识别高价值、高复用、可产品化的业务场景，逐步拓展产品线。
+
+产品线拓展方向应重点关注：
+
+- 收银系统。
+- 客服系统。
+- 门店生命周期系统。
+- 商品管理系统。
+- 门店经营与收银订单。
+- 门店对账、结算、分账和利润核算。
+- 加盟商管理与门店生命周期。
+- 选址、开发、工程装修和开业筹备。
+- 供应链订货、库存、履约和门店自采。
+- 品牌会员、营销活动和渠道运营。
+- 外卖与三方平台运营。
+- 门店营运督导、巡检、整改和培训。
+- 经营数据分析和管理驾驶舱。
+
+## 3. 当前已有产品资产
+
+### 3.1 营帐通
+
+营帐通当前定位为连锁企业门店对账分账系统，面向多门店、多渠道、多支付方式、多结算主体的资金结算和经营对账场景。
+
+后续营帐通应拆分为连锁业务对账系统和分账系统：
+
+- 连锁业务对账系统：面向连锁餐饮、连锁鞋服、连锁零售、连锁药店等行业，解决交易、账单、支付流水、银行入账之间的核对和差异处理。
+- 分账系统：面向连锁门店和互联网平台业务，解决多主体、多账户、多规则下的清分、分账、结算、出款和担保交易。
+
+重点业务价值：
+
+- 支撑门店销售款、外卖款、团购款等多渠道款项对账。
+- 支撑品牌监管账户、门店钱包、加盟商结算等资金管理场景。
+- 支撑加盟费、保证金、管理费、物料款、装修款、设备款等费用结算。
+- 支撑门店级、加盟商级、品牌级经营核算和利润分析。
+- 支撑品牌公司、门店、加盟商、供应链公司、物流公司、装修公司之间的结算协同。
+
+后续升级方向：
+
+- 强化多行业、多渠道订单对账能力。
+- 强化监管账户归集和自动分账能力。
+- 强化门店钱包和加盟商资金账户能力。
+- 强化平台商户账户、服务商分润、供应商结算能力。
+- 强化担保交易、履约确认、资金暂存、清分分润能力。
+- 将分账系统升级为 SaaS 平台能力。
+- 强化门店级利润表和加盟商利润表。
+- 强化与 POS、外卖平台、财务系统、供应链系统之间的业务协同。
+
+### 3.2 门店选址规划系统
+
+门店选址规划系统定位为连锁门店拓展和选址决策产品，面向品牌拓展、加盟开发、直营开发、区域规划等场景。
+
+重点业务价值：
+
+- 支撑品牌开店策略和区域布局规划。
+- 支撑商圈、客流、竞品、租金、交通、消费力等选址因素分析。
+- 支撑直营、加盟、联营等不同开店模式下的选址评估。
+- 支撑门店开发、选址评审、合同签约、装修筹备等前置流程衔接。
+
+后续升级方向：
+
+- 强化多品牌、多业态选址模型。
+- 强化门店历史经营数据对选址模型的反哺。
+- 强化加盟商候选点位评估和总部审核能力。
+- 强化区域保护、门店密度、品牌组合布局分析。
+- 强化与门店生命周期管理系统、工程装修管理系统的数据衔接。
+
+### 3.3 门店大数据平台
+
+门店大数据平台定位为餐饮连锁经营分析和决策支持产品，面向集团、品牌、区域、门店、加盟商等不同层级的经营分析场景。
+
+重点业务价值：
+
+- 支撑集团经营分析、品牌经营分析、区域经营分析和门店经营分析。
+- 支撑销售、订单、会员、商品、毛利、库存、供应链、渠道、财务等多维分析。
+- 支撑门店级利润表、加盟商利润表、品牌利润表。
+- 支撑经营异常识别、区域对比、门店分层和经营改善。
+
+后续升级方向：
+
+- 强化统一指标口径和数据治理能力。
+- 强化多品牌、多业态、多经营模式的数据分析模板。
+- 强化门店经营诊断和改进建议能力。
+- 强化营帐通、选址系统、POS、供应链、会员营销等系统数据融合。
+- 强化面向集团高管、品牌负责人、区域经理、督导、加盟商的差异化看板。
+
+## 4. 产品规划原则
+
+### 4.1 行业通用能力优先
+
+优先沉淀连锁经营行业和平台型交易业务的共性能力，避免为单个客户或单一品牌做不可复用的定制化设计。
+
+### 4.2 场景闭环优先
+
+产品规划应围绕完整业务闭环展开，避免只做单点功能。
+
+典型闭环包括：
+
+- 订单、对账、结算、分账、利润核算闭环。
+- 交易、担保、履约、清分、分账、出款闭环。
+- 选址、签约、装修、开业、经营复盘闭环。
+- 经营数据、问题识别、整改动作、结果跟踪闭环。
+
+### 4.3 统一平台与差异配置并重
+
+面向多品牌、多业态、多经营模式的餐饮连锁企业，产品应优先采用统一平台能力，通过品牌配置、业态配置、流程配置、权限配置承载差异。
+
+### 4.4 产品化与方案化结合
+
+产品规划既要形成标准软件产品，也要能够组合成行业解决方案。
+
+对于客户项目中的个性化需求，应判断其是否具备行业共性，再决定是否纳入标准产品能力。
+
+## 5. 后续产品线拓展方向
+
+基于现有产品资产，后续可重点拓展以下产品线：
+
+- 连锁业务对账系统。
+- 分账 SaaS 平台。
+- 门店生命周期管理产品。
+- 加盟商管理产品。
+- 工程装修管理产品。
+- 收银系统。
+- 客服系统。
+- 商品管理系统。
+- 门店订货与库存产品。
+- 品牌会员与营销产品。
+- 外卖与三方平台运营产品。
+- 门店营运督导产品。
+- 餐饮供应链协同产品。
+- 餐饮集团经营管理驾驶舱。
+
+其中，营帐通、门店选址规划系统、门店大数据平台可作为现有核心产品底座，与后续产品线形成组合方案。

02-年度计划/2026年产品工作计划.md

@@ -0,0 +1,473 @@
+# 2026 年产品工作计划
+
+## 1. 年度工作定位
+
+2026 年产品工作的核心定位是：完成基础平台建设和协助研发部门完成技术架构调整，在此基础上重点推进营帐通产品拆分与完善，并围绕明确客户项目完成纵向行业试点和横向产品建设。
+
+今年的工作不做全面铺开，重点放在“底座建设、营帐通升级、聚合支付建设、重点客户验证、横向产品试点”五类事项上。
+
+年度优先级明确为：纵向产品作为第一优先级，横向拓展作为第二优先级。
+
+- 第一优先级：营帐通拆分与完善、连锁业务对账系统、分账系统、聚合支付系统、物流撮合行业分账试点、万店餐饮客户营帐通升级、鞋服连锁客户营帐通升级。
+- 第二优先级：门店选址规划系统集成、连锁门店客服系统开发及试点。
+
+## 2. 年度核心目标
+
+### 2.1 完成基础平台建设
+
+围绕后续多产品线、多客户、多行业复用的需要，完成基础平台产品规划和建设协同。
+
+重点目标包括：
+
+- 明确统一组织、账号、权限、角色、菜单、流程、消息、配置等基础能力范围。
+- 明确多租户、多客户、多品牌、多门店的基础管理模型。
+- 优先为营帐通拆分、分账系统 SaaS 化、聚合支付建设和物流撮合行业试点提供统一底座。
+- 在不影响纵向产品推进的前提下，兼顾餐饮横向产品线建设需要。
+- 协助研发部门完成基础平台建设过程中的产品边界、业务规则和场景校验。
+
+### 2.2 协助研发部门完成技术架构调整
+
+产品侧重点不是技术实现细节，而是协助研发完成架构调整所需的业务边界、产品边界和演进路径。
+
+重点目标包括：
+
+- 明确营帐通、连锁业务对账系统、分账系统、基础平台之间的产品关系。
+- 明确业务模块拆分优先级，避免技术架构调整脱离业务演进目标。
+- 梳理现有客户升级和新行业试点对技术架构的关键要求。
+- 协助研发识别必须优先支撑的业务能力，例如多租户、规则配置、账户体系、分账规则、对账任务、渠道接入等。
+
+### 2.3 启动聚合支付系统建设并完成 1.0 版本
+
+基于基础平台建设和技术架构调整，启动聚合支付系统建设，完成 1.0 版本，为营帐通、分账系统、收银系统和后续平台交易业务提供统一支付接入能力。
+
+重点目标包括：
+
+- 明确聚合支付系统的产品定位和系统边界。
+- 明确聚合支付系统与营帐通、分账系统、收银系统、财务系统之间的关系。
+- 完成聚合支付 1.0 版本产品规划。
+- 支撑研发完成聚合支付 1.0 版本建设。
+- 初步支持多支付渠道接入、支付订单管理、支付状态管理、退款、支付流水、基础对账数据输出等能力。
+
+### 2.4 重点完成营帐通拆分与完善
+
+营帐通仍是 2026 年最核心的产品工作。年度重点是将现有营帐通逐步拆分为连锁业务对账系统和分账系统，并补齐现有客户升级、跨行业拓展和平台业务试点所需能力。
+
+重点目标包括：
+
+- 完成营帐通现有能力盘点。
+- 明确连锁业务对账系统与分账系统边界。
+- 完成连锁业务对账系统核心能力规划。
+- 完成分账系统核心能力规划。
+- 支撑现有万店餐饮连锁客户营帐通升级。
+- 支撑现有鞋服连锁客户营帐通升级。
+- 支撑物流撮合行业分账系统试点。
+
+### 2.5 纵向推进分账系统物流撮合行业试点
+
+在基础平台和技术架构调整基础上，推动分账系统从连锁门店分账向平台型业务分账延伸，优先选择物流撮合行业进行试点。
+
+重点目标包括：
+
+- 梳理物流撮合平台交易、履约、对账、清分、分账、结算流程。
+- 明确平台方、货主、司机、承运商、服务商等参与主体和资金关系。
+- 明确担保交易、履约确认、资金暂存、退款、分润、出款等关键规则。
+- 形成物流撮合行业分账试点方案。
+- 支撑试点客户上线验证。
+
+### 2.6 推进两个存量客户营帐通升级
+
+围绕现有客户完成产品升级验证，沉淀可复用能力。
+
+重点客户包括：
+
+- 1 个万店餐饮连锁企业营帐通升级。
+- 1 个鞋服连锁企业营帐通产品升级。
+
+重点目标包括：
+
+- 通过万店餐饮客户验证营帐通在大规模、多品牌、多门店、多渠道、多结算主体场景下的能力。
+- 通过鞋服连锁客户验证营帐通对非餐饮连锁业态的适配能力。
+- 将客户升级需求沉淀为连锁业务对账系统和分账系统的标准能力。
+
+### 2.7 横向推进门店选址规划系统集成
+
+围绕餐饮连锁横向产品线，推进门店选址规划系统与相关系统的集成和方案完善。该项属于第二优先级，应在不影响纵向产品主线的前提下推进。
+
+重点目标包括：
+
+- 明确门店选址规划系统与门店生命周期、门店主数据、经营数据平台之间的关系。
+- 推进门店选址规划系统与现有客户业务系统集成。
+- 打通选址评估、点位审批、开店筹备、开业后经营复盘之间的数据链路。
+- 强化门店选址规划系统在餐饮连锁解决方案中的位置。
+
+### 2.8 推进连锁门店客服系统开发及试点
+
+客服系统作为餐饮横向产品线的重要补充，2026 年重点完成产品规划、核心功能开发协同和试点验证。该项属于第二优先级，应控制试点范围，避免影响纵向产品资源投入。
+
+重点目标包括：
+
+- 明确连锁门店客服系统的业务定位和产品边界。
+- 梳理客诉、咨询、工单、补偿、回访、责任归属、服务质量分析等核心流程。
+- 明确客服系统与门店、订单、会员、营帐通、数据平台之间的协同关系。
+- 支撑研发完成核心功能开发。
+- 选择试点客户或试点门店进行验证。
+
+## 3. 年度重点项目
+
+年度重点项目按优先级分为两类：
+
+- 第一优先级项目：基础平台建设、技术架构调整协同、聚合支付系统 1.0 建设、营帐通拆分与完善、物流撮合行业分账试点、万店餐饮客户营帐通升级、鞋服连锁客户营帐通升级。
+- 第二优先级项目：门店选址规划系统集成、连锁门店客服系统开发及试点。
+
+### 3.1 基础平台建设项目
+
+工作内容：
+
+- 梳理基础平台产品范围。
+- 明确基础平台与业务产品的边界。
+- 输出统一组织、账号、权限、配置、流程、消息等基础能力需求。
+- 协助研发确认基础平台建设优先级。
+
+关键产出：
+
+- 基础平台产品规划。
+- 基础平台能力清单。
+- 多租户、多组织、多门店管理模型。
+- 基础平台与业务产品边界说明。
+
+### 3.2 技术架构调整协同项目
+
+工作内容：
+
+- 配合研发梳理现有系统模块和业务边界。
+- 明确营帐通拆分后的业务模块关系。
+- 明确对账、分账、账户、规则、任务、报表、接口等能力的归属。
+- 根据客户升级和试点项目，提出架构调整的业务优先级。
+
+关键产出：
+
+- 产品模块拆分建议。
+- 业务能力分层说明。
+- 架构调整业务影响清单。
+- 重点客户升级对架构的要求清单。
+
+### 3.3 聚合支付系统 1.0 建设项目
+
+工作内容：
+
+- 明确聚合支付系统产品定位和能力范围。
+- 梳理支付渠道、支付订单、支付流水、退款、支付状态、支付通知、对账数据输出等核心对象。
+- 明确聚合支付系统与营帐通、分账系统、收银系统、财务系统的协同边界。
+- 明确 1.0 版本最小可用范围。
+- 协助研发完成 1.0 版本需求澄清、版本验收和上线验证。
+
+关键产出：
+
+- 聚合支付系统产品规划。
+- 聚合支付 1.0 版本需求说明。
+- 聚合支付与营帐通、分账系统、收银系统边界说明。
+- 聚合支付 1.0 验收清单。
+
+### 3.4 营帐通拆分与完善项目
+
+工作内容：
+
+- 完成营帐通现有功能、客户场景和能力缺口梳理。
+- 将营帐通拆分为连锁业务对账系统和分账系统两条能力线。
+- 明确连锁业务对账系统核心流程：数据采集、账单导入、对账任务、差异识别、差异处理、对账报表。
+- 明确分账系统核心流程：结算主体、账户体系、分账规则、清分、分账、出款、退款、结算报表。
+- 明确两个产品与基础平台、财务系统、收银系统、外部平台之间的边界。
+
+关键产出：
+
+- 营帐通能力盘点。
+- 连锁业务对账系统规划。
+- 分账系统规划。
+- 营帐通拆分方案。
+- 对账与分账系统边界说明。
+
+### 3.5 物流撮合行业分账试点项目
+
+工作内容：
+
+- 梳理物流撮合平台业务流程。
+- 明确平台交易主体、结算主体、资金流和分润规则。
+- 设计担保交易流程，包括下单、支付、履约、确认、清分、分账、退款、出款。
+- 明确试点版本的最小能力范围。
+- 跟进试点上线和业务反馈。
+
+关键产出：
+
+- 物流撮合行业分账方案。
+- 担保交易流程说明。
+- 物流撮合分账试点需求说明。
+- 试点问题清单和产品优化清单。
+
+### 3.6 万店餐饮连锁客户营帐通升级项目
+
+工作内容：
+
+- 梳理现有万店餐饮客户营帐通使用现状和升级诉求。
+- 明确多品牌、多门店、多渠道、多账户、多结算主体场景下的升级范围。
+- 推进监管账户、门店钱包、外卖款、团购款、门店销售款、加盟商结算等能力完善。
+- 沉淀餐饮连锁行业对账分账标准方案。
+
+关键产出：
+
+- 万店餐饮客户升级方案。
+- 餐饮连锁对账分账业务模板。
+- 餐饮连锁结算规则清单。
+- 产品标准能力沉淀清单。
+
+### 3.7 鞋服连锁客户营帐通升级项目
+
+工作内容：
+
+- 梳理鞋服连锁客户交易渠道、门店收款、平台账单、退款、手续费、促销补贴等对账场景。
+- 识别鞋服行业与餐饮行业在商品、渠道、门店、促销、退换货、结算上的差异。
+- 推进营帐通对鞋服连锁行业的适配升级。
+- 沉淀非餐饮连锁行业对账方案。
+
+关键产出：
+
+- 鞋服连锁客户升级方案。
+- 鞋服连锁对账业务模板。
+- 鞋服行业差异化需求清单。
+- 连锁业务对账系统跨行业能力沉淀清单。
+
+### 3.8 门店选址规划系统集成项目
+
+工作内容：
+
+- 明确门店选址规划系统与客户现有系统的数据集成范围。
+- 梳理点位、商圈、门店、区域、品牌、经营数据等关键数据对象。
+- 推进选址评估与开店后经营复盘的数据闭环。
+- 明确选址系统与门店生命周期系统的未来协同边界。
+
+关键产出：
+
+- 门店选址规划系统集成方案。
+- 选址系统数据对象清单。
+- 选址评估到经营复盘流程说明。
+- 与门店生命周期系统的边界说明。
+
+### 3.9 连锁门店客服系统开发及试点项目
+
+工作内容：
+
+- 完成客服系统产品定位和核心流程设计。
+- 明确客诉、咨询、工单、补偿、回访、责任归属等核心能力。
+- 明确客服系统与订单、会员、门店、营帐通、数据平台的协同关系。
+- 协助研发完成试点版本开发。
+- 推进客户或门店试点验证。
+
+关键产出：
+
+- 连锁门店客服系统产品规划。
+- 客服系统试点版本需求说明。
+- 客诉与工单流程设计。
+- 试点验证报告。
+
+## 4. 季度工作计划
+
+### 4.1 第一季度：底座规划与营帐通拆分启动
+
+工作重点：
+
+- 明确年度工作计划和产品优先级。
+- 完成基础平台产品规划初稿。
+- 协助研发明确技术架构调整方向和业务拆分原则。
+- 明确聚合支付系统产品定位和建设范围。
+- 完成营帐通现有能力盘点。
+- 完成连锁业务对账系统、分账系统边界初稿。
+- 启动万店餐饮客户和鞋服连锁客户升级需求梳理。
+- 明确横向项目的最小推进范围，避免挤占纵向产品资源。
+
+关键产出：
+
+- 2026 年产品工作计划。
+- 基础平台产品规划初稿。
+- 技术架构调整业务协同清单。
+- 聚合支付系统产品定位初稿。
+- 营帐通能力盘点。
+- 对账与分账系统边界初稿。
+
+### 4.2 第二季度：营帐通升级方案与试点方案形成
+
+工作重点：
+
+- 完成聚合支付系统产品规划。
+- 完成聚合支付 1.0 版本需求说明。
+- 完成营帐通拆分方案。
+- 完成连锁业务对账系统规划和分账系统规划。
+- 完成万店餐饮客户营帐通升级方案。
+- 完成鞋服连锁客户营帐通升级方案。
+- 完成物流撮合行业分账试点方案。
+- 在纵向产品方案完成后，推进门店选址规划系统集成方案。
+- 在资源允许前提下，完成客服系统产品规划。
+
+关键产出：
+
+- 聚合支付系统产品规划。
+- 聚合支付 1.0 版本需求说明。
+- 营帐通拆分方案。
+- 连锁业务对账系统规划。
+- 分账系统规划。
+- 万店餐饮客户升级方案。
+- 鞋服连锁客户升级方案。
+- 物流撮合行业分账试点方案。
+- 门店选址规划系统集成方案。
+- 连锁门店客服系统产品规划。
+
+### 4.3 第三季度：重点项目研发协同与试点推进
+
+工作重点：
+
+- 协助研发推进基础平台和技术架构调整落地。
+- 协助研发推进聚合支付 1.0 版本建设。
+- 跟进营帐通拆分相关版本需求和研发实现。
+- 推进万店餐饮客户营帐通升级。
+- 推进鞋服连锁客户营帐通升级。
+- 推进物流撮合行业分账试点。
+- 在纵向产品项目节奏稳定后，推进门店选址规划系统集成。
+- 在研发资源允许前提下，协助客服系统试点版本开发。
+
+关键产出：
+
+- 重点项目需求说明书。
+- 聚合支付 1.0 验收清单。
+- 营帐通升级版本需求清单。
+- 物流撮合行业试点需求清单。
+- 客服系统试点版本需求说明。
+- 项目问题与风险清单。
+
+### 4.4 第四季度：试点验收、产品沉淀与 2027 规划
+
+工作重点：
+
+- 完成聚合支付 1.0 版本验收和复盘。
+- 完成万店餐饮客户营帐通升级复盘。
+- 完成鞋服连锁客户营帐通升级复盘。
+- 完成物流撮合行业分账试点复盘。
+- 完成门店选址规划系统集成复盘。
+- 完成客服系统试点复盘。
+- 沉淀连锁业务对账系统、分账系统、客服系统、选址集成的标准能力。
+- 输出 2027 年产品路线图。
+
+关键产出：
+
+- 聚合支付 1.0 版本复盘报告。
+- 重点客户升级复盘报告。
+- 物流撮合行业分账试点复盘报告。
+- 门店选址规划系统集成复盘报告。
+- 客服系统试点验证报告。
+- 产品标准能力沉淀清单。
+- 2027 年产品路线图。
+
+## 5. 年度关键成果物清单
+
+2026 年至少应完成以下成果物：
+
+- 基础平台产品规划。
+- 技术架构调整业务协同清单。
+- 聚合支付系统产品规划。
+- 聚合支付 1.0 版本需求说明。
+- 聚合支付 1.0 验收清单。
+- 营帐通能力盘点。
+- 营帐通拆分方案。
+- 连锁业务对账系统规划。
+- 分账系统规划。
+- 万店餐饮客户营帐通升级方案。
+- 鞋服连锁客户营帐通升级方案。
+- 物流撮合行业分账试点方案。
+- 门店选址规划系统集成方案。
+- 连锁门店客服系统产品规划。
+- 客服系统试点版本需求说明。
+- 重点项目复盘报告。
+- 产品标准能力沉淀清单。
+- 2027 年产品路线图。
+
+## 6. 年度衡量指标
+
+### 6.1 底座与架构协同指标
+
+- 完成基础平台产品规划并支撑研发建设。
+- 完成技术架构调整所需的产品边界和业务能力拆分说明。
+- 支撑营帐通拆分后的核心能力在新架构下落位。
+
+### 6.2 聚合支付建设指标
+
+- 完成聚合支付系统产品规划。
+- 完成聚合支付 1.0 版本需求说明。
+- 支撑研发完成聚合支付 1.0 版本建设。
+- 明确聚合支付与营帐通、分账系统、收银系统之间的业务边界。
+
+### 6.3 营帐通升级指标
+
+- 完成营帐通拆分方案。
+- 完成连锁业务对账系统和分账系统核心规划。
+- 推进 1 个万店餐饮连锁客户营帐通升级。
+- 推进 1 个鞋服连锁客户营帐通升级。
+- 沉淀餐饮连锁和鞋服连锁两套行业对账分账模板。
+
+### 6.4 分账试点指标
+
+- 完成物流撮合行业分账试点方案。
+- 推进物流撮合行业试点落地。
+- 沉淀平台业务担保交易和分账能力模型。
+
+### 6.5 横向产品指标
+
+- 完成门店选址规划系统集成方案并推进集成落地。
+- 完成连锁门店客服系统产品规划。
+- 在不影响纵向产品主线的前提下，推进客服系统试点版本开发和试点验证。
+
+## 7. 资源与协同要求
+
+### 7.1 与研发部门协同
+
+研发部门是 2026 年最重要的协同方。产品侧需要持续提供业务边界、产品边界、流程规则、客户场景和优先级判断，协助研发完成基础平台建设、技术架构调整和聚合支付 1.0 版本建设。
+
+### 7.2 与客户项目团队协同
+
+万店餐饮客户、鞋服连锁客户、物流撮合试点、门店选址集成、客服系统试点都需要项目团队持续输入现场需求、客户反馈和上线问题。
+
+### 7.3 与销售和售前协同
+
+销售和售前需要参与行业方案沉淀，尤其是物流撮合分账方案、鞋服连锁对账方案、餐饮连锁营帐通升级方案和客服系统试点方案。
+
+### 7.4 与管理层协同
+
+需要管理层明确资源优先级，尤其是在基础平台、技术架构调整、聚合支付建设、营帐通拆分、客服系统开发和物流撮合分账试点之间进行投入取舍。资源冲突时，优先保障纵向产品主线。
+
+## 8. 风险与应对
+
+### 8.1 基础平台和业务产品互相拖累风险
+
+风险：基础平台和技术架构调整周期较长，可能影响聚合支付建设、营帐通升级和试点项目进度。
+
+应对：产品侧明确最小可用底座能力，优先保障聚合支付 1.0、营帐通拆分、客户升级和物流撮合试点需要。
+
+### 8.2 营帐通拆分边界不清风险
+
+风险：连锁业务对账系统和分账系统边界不清，导致研发拆分、客户报价、产品包装和后续 SaaS 化受影响。
+
+应对：优先输出产品边界说明，明确对账负责差异核对闭环，分账负责账户、规则、清分、分账、出款闭环。
+
+### 8.3 聚合支付建设范围发散风险
+
+风险：聚合支付系统容易扩展到完整收银、清结算、分账、财务对账等过大范围，影响 1.0 版本落地。
+
+应对：1.0 版本聚焦支付渠道接入、支付订单、支付状态、退款、支付流水和基础对账数据输出，不承担完整分账和财务结算职责。
+
+### 8.4 物流撮合试点复杂度风险
+
+风险：物流撮合场景涉及担保交易、履约确认、多方分润和退款争议，业务复杂度高。
+
+应对：试点阶段控制范围，先跑通交易、履约、清分、分账、出款主流程，再逐步扩展异常场景。
+
+### 8.5 客服系统建设范围发散风险
+
+风险：客服系统容易从客诉工单扩展到会员、营销、订单、售后、质检等过多范围。
+
+应对：试点版本聚焦客诉、咨询、工单、补偿、回访和责任归属，不在 2026 年追求完整大客服平台。若与纵向产品资源冲突，客服系统开发和试点顺延。

02-年度计划/2026年详细执行计划.md

@@ -0,0 +1,616 @@
+# 2026 年详细执行计划
+
+## 1. 计划定位
+
+本文档基于《2026 年产品工作计划》进一步拆解，作为产品规划负责人日常推进、跨部门协同、月度检查和季度复盘的执行依据。
+
+本计划遵循年度优先级：
+
+- 第一优先级：纵向产品，包括营帐通现状梳理、营帐通拆分、连锁业务对账系统、分账系统、聚合支付系统、物流撮合行业分账试点、万店餐饮客户营帐通升级、鞋服连锁客户营帐通升级。
+- 第二优先级：横向拓展，包括门店选址规划系统集成、连锁门店客服系统开发及试点。
+
+产品侧职责边界：
+
+- 负责业务流程、产品定位、产品边界、能力清单、需求说明、方案沉淀、客户验证和验收标准。
+- 协助研发完成基础平台建设、技术架构调整、版本范围确认和上线验证。
+- 不负责具体技术实现方案、代码架构、数据库设计、接口技术细节和研发排期管理。
+
+## 2. 年度工作包总览
+
+| 编号 | 工作包 | 优先级 | 年度目标 | 核心产出 |
+| --- | --- | --- | --- | --- |
+| WP01 | 基础平台产品协同 | P0 | 支撑多产品、多客户、多行业复用 | 基础平台产品规划、能力清单、边界说明 |
+| WP02 | 技术架构调整业务协同 | P0 | 协助研发完成业务模块拆分和架构调整 | 业务能力分层、模块边界、架构影响清单 |
+| WP03 | 营帐通现状梳理 | P0 | 明确营帐通现有能力、问题和客户使用情况 | 现状说明、功能清单、问题清单、客户使用情况 |
+| WP04 | 营帐通拆分方案 | P0 | 明确营帐通拆分为连锁业务对账系统和分账系统的路径 | 拆分方案、产品边界、能力迁移清单 |
+| WP05 | 连锁业务对账系统规划 | P0 | 形成连锁业务对账系统产品规划 | 产品规划、核心流程、能力清单、行业模板 |
+| WP06 | 分账系统规划 | P0 | 形成分账系统产品规划和平台化方向 | 产品规划、账户体系、分账规则、清分出款流程 |
+| WP07 | 聚合支付系统 1.0 | P0 | 完成 1.0 产品规划、需求说明和验收 | 产品规划、1.0 需求说明、验收清单 |
+| WP08 | 物流撮合分账试点 | P0 | 完成物流撮合行业分账试点方案并推进验证 | 行业方案、试点需求、复盘报告 |
+| WP09 | 万店餐饮客户升级 | P0 | 推进万店餐饮客户营帐通升级 | 升级方案、规则清单、复盘报告 |
+| WP10 | 鞋服连锁客户升级 | P0 | 推进鞋服连锁客户营帐通升级 | 升级方案、行业差异清单、复盘报告 |
+| WP11 | 门店选址规划系统集成 | P1 | 推进选址系统集成和数据闭环 | 集成方案、数据对象清单、复盘报告 |
+| WP12 | 连锁门店客服系统试点 | P1 | 完成客服系统规划、试点版本需求和验证 | 产品规划、试点需求、验证报告 |
+| WP13 | 产品治理与知识库沉淀 | P0 | 建立持续沉淀机制 | 知识库目录、模板、评审机制、月度复盘 |
+
+## 3. 月度推进节奏
+
+### 3.1 1 月：年度计划与现状启动
+
+重点任务：
+
+- 明确 2026 年产品工作计划和优先级。
+- 完成公司核心知识库目录结构搭建。
+- 明确营帐通目录仅沉淀现状，拆分规划进入对应产品线目录。
+- 启动营帐通现状梳理。
+- 启动基础平台产品范围梳理。
+
+关键产出：
+
+- 2026 年产品工作计划。
+- 2026 年详细执行计划。
+- 公司核心知识库目录。
+- 营帐通现状文档目录。
+- 基础平台产品规划框架。
+
+### 3.2 2 月：底座边界与营帐通能力盘点
+
+重点任务：
+
+- 梳理基础平台能力范围：组织、账号、权限、角色、菜单、配置、流程、消息。
+- 梳理营帐通现有功能清单、业务流程、客户使用情况和问题清单。
+- 梳理营帐通现有能力与未来连锁业务对账系统、分账系统之间的关系。
+- 与研发对齐技术架构调整的业务拆分原则。
+- 明确聚合支付系统产品定位初稿。
+
+关键产出：
+
+- 基础平台能力清单。
+- 营帐通现有功能清单。
+- 营帐通现有业务流程。
+- 营帐通现有问题与能力缺口。
+- 技术架构调整业务协同清单初稿。
+- 聚合支付系统产品定位初稿。
+
+### 3.3 3 月：产品边界初稿
+
+重点任务：
+
+- 明确连锁业务对账系统与分账系统产品边界初稿。
+- 明确聚合支付系统与营帐通、分账系统、收银系统、财务系统边界初稿。
+- 梳理万店餐饮客户和鞋服连锁客户升级诉求。
+- 梳理物流撮合行业分账试点业务流程。
+- 明确横向项目最小推进范围。
+
+关键产出：
+
+- 连锁业务对账系统边界初稿。
+- 分账系统边界初稿。
+- 聚合支付系统边界初稿。
+- 万店餐饮客户升级需求清单。
+- 鞋服连锁客户升级需求清单。
+- 物流撮合业务流程初稿。
+
+### 3.4 4 月：纵向产品方案深化
+
+重点任务：
+
+- 完成营帐通拆分方案初稿。
+- 完成连锁业务对账系统产品规划初稿。
+- 完成分账系统产品规划初稿。
+- 完成聚合支付系统产品规划。
+- 完成物流撮合行业分账方案初稿。
+
+关键产出：
+
+- 营帐通拆分方案初稿。
+- 连锁业务对账系统产品规划初稿。
+- 分账系统产品规划初稿。
+- 聚合支付系统产品规划。
+- 物流撮合行业分账方案初稿。
+
+### 3.5 5 月：客户升级方案形成
+
+重点任务：
+
+- 完成万店餐饮客户营帐通升级方案。
+- 完成鞋服连锁客户营帐通升级方案。
+- 完成聚合支付 1.0 版本需求说明。
+- 完成物流撮合行业分账试点需求说明。
+- 完成门店选址规划系统集成方案初稿。
+
+关键产出：
+
+- 万店餐饮客户升级方案。
+- 鞋服连锁客户升级方案。
+- 聚合支付 1.0 版本需求说明。
+- 物流撮合分账试点需求说明。
+- 门店选址规划系统集成方案初稿。
+
+### 3.6 6 月：版本范围与研发协同
+
+重点任务：
+
+- 与研发确认聚合支付 1.0 版本范围。
+- 与研发确认营帐通拆分相关版本范围。
+- 与项目团队确认万店餐饮客户和鞋服连锁客户升级实施范围。
+- 完成客服系统产品规划。
+- 完成 Q2 复盘和下半年重点项目计划。
+
+关键产出：
+
+- 聚合支付 1.0 版本范围确认。
+- 营帐通升级版本需求清单。
+- 客服系统产品规划。
+- Q2 产品工作复盘。
+- 下半年重点项目计划。
+
+### 3.7 7 月：研发协同与版本跟进
+
+重点任务：
+
+- 跟进基础平台和技术架构调整落地情况。
+- 跟进聚合支付 1.0 版本研发过程中的需求澄清。
+- 跟进营帐通拆分和客户升级需求落地。
+- 推进物流撮合行业试点需求澄清。
+- 推进门店选址规划系统集成需求澄清。
+
+关键产出：
+
+- 聚合支付 1.0 需求澄清记录。
+- 营帐通升级需求澄清记录。
+- 物流撮合试点问题清单。
+- 门店选址集成问题清单。
+
+### 3.8 8 月：重点客户升级推进
+
+重点任务：
+
+- 推进万店餐饮客户营帐通升级。
+- 推进鞋服连锁客户营帐通升级。
+- 跟进聚合支付 1.0 测试和验收准备。
+- 推进物流撮合分账试点。
+- 协助客服系统试点版本开发。
+
+关键产出：
+
+- 万店餐饮客户升级问题清单。
+- 鞋服连锁客户升级问题清单。
+- 聚合支付 1.0 验收清单初稿。
+- 客服系统试点版本需求说明。
+
+### 3.9 9 月：试点验证与能力沉淀
+
+重点任务：
+
+- 推进聚合支付 1.0 验收。
+- 推进物流撮合行业分账试点验证。
+- 梳理万店餐饮客户和鞋服连锁客户升级中的标准能力。
+- 推进门店选址规划系统集成。
+- 完成 Q3 复盘。
+
+关键产出：
+
+- 聚合支付 1.0 验收清单。
+- 物流撮合试点验证问题清单。
+- 餐饮连锁对账分账模板初稿。
+- 鞋服连锁对账模板初稿。
+- Q3 产品工作复盘。
+
+### 3.10 10 月：试点收敛与标准化
+
+重点任务：
+
+- 完成聚合支付 1.0 版本复盘。
+- 完成物流撮合行业分账试点阶段复盘。
+- 完成万店餐饮客户升级阶段复盘。
+- 完成鞋服连锁客户升级阶段复盘。
+- 梳理产品标准能力沉淀清单。
+
+关键产出：
+
+- 聚合支付 1.0 版本复盘报告。
+- 物流撮合分账试点复盘报告。
+- 万店餐饮客户升级复盘报告。
+- 鞋服连锁客户升级复盘报告。
+- 产品标准能力沉淀清单。
+
+### 3.11 11 月：横向试点复盘与 2027 路线准备
+
+重点任务：
+
+- 完成门店选址规划系统集成复盘。
+- 完成客服系统试点验证复盘。
+- 梳理 2027 年纵向产品路线。
+- 梳理 2027 年横向拓展建议。
+- 形成产品线资源投入建议。
+
+关键产出：
+
+- 门店选址规划系统集成复盘报告。
+- 客服系统试点验证报告。
+- 2027 年纵向产品路线草案。
+- 2027 年横向产品建议。
+- 产品线资源投入建议。
+
+### 3.12 12 月：年度复盘与下一年度计划
+
+重点任务：
+
+- 完成 2026 年产品工作年度复盘。
+- 完成 2027 年产品路线图。
+- 完成产品知识库归档和目录更新。
+- 完成产品标准能力清单更新。
+- 完成重点产品下一年度规划建议。
+
+关键产出：
+
+- 2026 年产品工作年度复盘。
+- 2027 年产品路线图。
+- 产品知识库年度归档。
+- 产品标准能力清单。
+- 重点产品 2027 年规划建议。
+
+## 4. 工作包详细计划
+
+### 4.1 WP01 基础平台产品协同
+
+目标：
+
+- 明确基础平台产品范围，支撑纵向产品优先落地。
+
+工作任务：
+
+- 梳理统一组织、账号、权限、菜单、角色、流程、消息、配置等基础能力。
+- 明确多租户、多客户、多品牌、多门店模型。
+- 明确基础平台与营帐通、连锁业务对账系统、分账系统、聚合支付、客服系统的关系。
+- 协助研发确认基础平台最小可用范围。
+
+关键产出：
+
+- 基础平台产品规划。
+- 基础平台能力清单。
+- 基础平台与业务产品边界说明。
+
+协同对象：
+
+- 研发负责人
+- 架构负责人
+- 实施 / 交付团队
+
+验收标准：
+
+- 基础平台能力范围被研发和产品共同确认。
+- 纵向产品所需基础能力有明确支撑路径。
+
+### 4.2 WP02 技术架构调整业务协同
+
+目标：
+
+- 从业务和产品角度协助研发完成架构调整。
+
+工作任务：
+
+- 梳理营帐通现有业务模块。
+- 明确营帐通拆分后的模块归属。
+- 明确连锁业务对账系统、分账系统、聚合支付、基础平台之间的关系。
+- 输出客户升级和试点项目对架构调整的业务要求。
+
+关键产出：
+
+- 产品模块拆分建议。
+- 业务能力分层说明。
+- 架构调整业务影响清单。
+
+协同对象：
+
+- 研发负责人
+- 架构负责人
+- 测试负责人
+
+验收标准：
+
+- 架构调整范围能够支撑聚合支付 1.0、营帐通拆分、物流撮合试点和存量客户升级。
+
+### 4.3 WP03 营帐通现状梳理
+
+目标：
+
+- 将营帐通现状完整沉淀，为拆分和升级提供依据。
+
+工作任务：
+
+- 梳理营帐通现有产品定位。
+- 梳理现有功能清单。
+- 梳理现有业务流程。
+- 梳理现有客户使用情况。
+- 梳理现有问题与能力缺口。
+
+关键产出：
+
+- 营帐通-现有产品说明。
+- 营帐通-现有功能清单。
+- 营帐通-现有业务流程。
+- 营帐通-现有客户使用情况。
+- 营帐通-现有问题与能力缺口。
+
+文档归属：
+
+- `10-产品线/营帐通`
+
+验收标准：
+
+- 能够基于现状文档清楚判断哪些能力进入连锁业务对账系统，哪些能力进入分账系统，哪些能力保留为存量兼容。
+
+### 4.4 WP04 营帐通拆分方案
+
+目标：
+
+- 明确营帐通拆分为连锁业务对账系统和分账系统的路径。
+
+工作任务：
+
+- 明确拆分原则。
+- 明确能力迁移关系。
+- 明确存量客户升级策略。
+- 明确新老产品关系。
+- 明确报价、交付、实施、售前口径。
+
+关键产出：
+
+- 营帐通拆分方案。
+- 连锁业务对账系统与分账系统边界说明。
+- 营帐通能力迁移清单。
+
+验收标准：
+
+- 产品、研发、销售、售前、交付对拆分边界达成一致。
+
+### 4.5 WP05 连锁业务对账系统规划
+
+目标：
+
+- 形成连锁业务对账系统产品规划。
+
+工作任务：
+
+- 设计对账业务流程。
+- 梳理订单、账单、流水、入账、差异、调整等核心对象。
+- 明确餐饮、鞋服、零售、药店的行业适配方式。
+- 明确对账任务、差异处理、报表分析等能力。
+
+关键产出：
+
+- 连锁业务对账系统产品规划。
+- 连锁业务对账系统能力清单。
+- 连锁餐饮对账模板。
+- 连锁鞋服对账模板。
+
+验收标准：
+
+- 能支撑万店餐饮客户和鞋服连锁客户升级。
+
+### 4.6 WP06 分账系统规划
+
+目标：
+
+- 形成分账系统产品规划，支撑连锁门店分账和平台业务分账。
+
+工作任务：
+
+- 梳理结算主体、账户体系、分账规则、清分、分账、退款、出款流程。
+- 明确连锁门店分账和物流撮合平台分账的共性能力。
+- 明确担保交易流程。
+- 明确与聚合支付、连锁业务对账系统、财务系统的边界。
+
+关键产出：
+
+- 分账系统产品规划。
+- 分账系统能力清单。
+- 担保交易流程说明。
+- 平台业务分账模型。
+
+验收标准：
+
+- 能支撑物流撮合行业分账试点。
+
+### 4.7 WP07 聚合支付系统 1.0
+
+目标：
+
+- 完成聚合支付系统 1.0 建设所需产品工作。
+
+工作任务：
+
+- 明确产品定位和边界。
+- 梳理支付订单、支付渠道、支付流水、退款、支付通知、支付状态等核心对象。
+- 明确 1.0 版本范围。
+- 输出需求说明和验收标准。
+- 协助研发完成需求澄清、版本验收和复盘。
+
+关键产出：
+
+- 聚合支付系统产品规划。
+- 聚合支付 1.0 版本需求说明。
+- 聚合支付 1.0 验收清单。
+- 聚合支付 1.0 复盘报告。
+
+验收标准：
+
+- 1.0 能支持支付渠道接入、支付订单管理、支付状态管理、退款、支付流水和基础对账数据输出。
+
+### 4.8 WP08 物流撮合分账试点
+
+目标：
+
+- 完成物流撮合行业分账试点，验证分账系统平台化能力。
+
+工作任务：
+
+- 梳理物流撮合平台业务流程。
+- 明确平台方、货主、司机、承运商、服务商等主体关系。
+- 梳理交易、担保、履约、清分、分账、退款、出款流程。
+- 明确试点最小范围。
+- 跟进试点反馈并沉淀能力。
+
+关键产出：
+
+- 物流撮合行业分账方案。
+- 物流撮合分账试点需求说明。
+- 物流撮合分账试点复盘报告。
+
+验收标准：
+
+- 能跑通交易、履约、清分、分账、出款主流程。
+
+### 4.9 WP09 万店餐饮客户升级
+
+目标：
+
+- 通过万店餐饮客户升级验证大规模餐饮连锁场景。
+
+工作任务：
+
+- 梳理客户现有使用情况。
+- 梳理升级诉求和问题。
+- 明确升级范围和优先级。
+- 沉淀餐饮连锁对账分账模板。
+
+关键产出：
+
+- 万店餐饮客户升级方案。
+- 餐饮连锁结算规则清单。
+- 餐饮连锁对账分账模板。
+- 万店餐饮客户升级复盘报告。
+
+验收标准：
+
+- 客户升级范围明确，关键问题闭环，沉淀可复用标准能力。
+
+### 4.10 WP10 鞋服连锁客户升级
+
+目标：
+
+- 通过鞋服连锁客户升级验证非餐饮连锁业态适配能力。
+
+工作任务：
+
+- 梳理鞋服交易渠道和对账场景。
+- 梳理退款、退换货、手续费、促销补贴等差异化场景。
+- 明确营帐通升级范围。
+- 沉淀鞋服连锁对账模板。
+
+关键产出：
+
+- 鞋服连锁客户升级方案。
+- 鞋服行业差异化需求清单。
+- 鞋服连锁对账模板。
+- 鞋服连锁客户升级复盘报告。
+
+验收标准：
+
+- 能支撑鞋服客户升级，并沉淀非餐饮行业适配能力。
+
+### 4.11 WP11 门店选址规划系统集成
+
+目标：
+
+- 推进门店选址规划系统集成，打通选址到经营复盘的数据链路。
+
+工作任务：
+
+- 梳理点位、商圈、门店、区域、品牌、经营数据对象。
+- 明确与客户现有系统的数据集成范围。
+- 明确与门店生命周期系统的未来边界。
+- 跟进集成落地和复盘。
+
+关键产出：
+
+- 门店选址规划系统集成方案。
+- 选址系统数据对象清单。
+- 选址评估到经营复盘流程说明。
+- 门店选址规划系统集成复盘报告。
+
+验收标准：
+
+- 选址系统能与相关业务系统完成关键数据集成。
+
+### 4.12 WP12 连锁门店客服系统试点
+
+目标：
+
+- 完成客服系统试点版本规划、开发协同和试点验证。
+
+工作任务：
+
+- 明确客服系统产品定位。
+- 梳理客诉、咨询、工单、补偿、回访、责任归属流程。
+- 明确与订单、会员、门店、数据平台的关系。
+- 协助研发完成试点版本。
+- 跟进试点验证。
+
+关键产出：
+
+- 连锁门店客服系统产品规划。
+- 客服系统试点版本需求说明。
+- 客诉与工单流程设计。
+- 客服系统试点验证报告。
+
+验收标准：
+
+- 试点版本聚焦客诉、咨询、工单、补偿、回访和责任归属，避免范围发散。
+
+### 4.13 WP13 产品治理与知识库沉淀
+
+目标：
+
+- 建立持续沉淀和复盘机制。
+
+工作任务：
+
+- 维护公司核心知识库。
+- 建立文档命名和归档规则。
+- 建立月度产品复盘机制。
+- 建立重点项目复盘机制。
+- 沉淀产品规划模板、客户访谈模板、复盘模板。
+
+关键产出：
+
+- 知识库目录维护。
+- 产品规划模板。
+- 客户访谈模板。
+- 项目复盘模板。
+- 月度 / 季度复盘记录。
+
+验收标准：
+
+- 重点产品和试点项目均有文档沉淀，可复用能力明确。
+
+## 5. 例行工作机制
+
+### 5.1 周例行
+
+- 跟进 P0 项目进度、风险和待决策事项。
+- 与研发同步需求澄清、版本范围和验收问题。
+- 与项目团队同步客户反馈和现场问题。
+
+### 5.2 月度例行
+
+- 更新月度工作进度。
+- 更新产品问题清单和风险清单。
+- 更新知识库目录和文档状态。
+- 对 P0 项目进行阶段性复盘。
+
+### 5.3 季度例行
+
+- 完成季度复盘。
+- 调整下一季度优先级。
+- 向管理层提交产品线进度、风险和资源建议。
+
+## 6. 决策原则
+
+- 纵向产品优先于横向拓展。
+- 客户升级和试点验证优先于概念规划。
+- 产品边界先于功能细节。
+- 标准能力沉淀优先于一次性项目定制。
+- 聚合支付 1.0、营帐通拆分、物流撮合试点、两个存量客户升级为 2026 年资源保障重点。

10-产品线/README.md

@@ -0,0 +1,14 @@
+# 产品线
+
+本目录用于沉淀各产品线的产品定位、产品规划、能力清单、业务流程、产品边界、版本规划和 PRD。
+
+当前产品线包括营帐通、连锁业务对账系统、分账系统、聚合支付、门店选址规划系统、门店大数据平台、连锁门店客服系统。
+
+## 目录定位
+
+- `营帐通`：仅用于整理营帐通现状，包括现有能力、客户使用情况、现有问题、现有业务流程和现有系统边界。
+- `连锁业务对账系统`：用于沉淀营帐通拆分后的对账方向规划。
+- `分账系统`：用于沉淀营帐通拆分后的分账方向规划，以及平台型分账能力规划。
+- `聚合支付`：用于沉淀聚合支付系统 1.0 及后续版本规划。
+
+营帐通后续拆分、升级和新产品化规划，不放在 `营帐通` 目录下，避免现状文档和未来规划混杂。

10-产品线/分账系统/README.md

@@ -0,0 +1,5 @@
+# 分账系统
+
+本目录用于沉淀营帐通拆分后的分账方向规划。
+
+重点关注结算主体、账户体系、分账规则、清分分润、退款、出款、平台业务分账和担保交易场景。

10-产品线/聚合支付/README.md

@@ -0,0 +1,5 @@
+# 聚合支付
+
+本目录用于沉淀聚合支付系统规划。
+
+2026 年重点目标是基于基础平台和技术架构调整，完成聚合支付系统 1.0 版本建设。

10-产品线/营帐通/README.md

@@ -0,0 +1,38 @@
+# 营帐通
+
+本目录仅用于整理营帐通现状，不承载营帐通拆分后的未来产品规划。
+
+## 文档范围
+
+本目录后续主要沉淀：
+
+- 营帐通现有产品定位
+- 营帐通现有功能清单
+- 营帐通现有业务流程
+- 营帐通现有客户使用情况
+- 营帐通现有系统边界
+- 营帐通现有问题与能力缺口
+- 营帐通现有数据对象与报表
+
+## 不放入本目录的内容
+
+以下内容不放在本目录：
+
+- 连锁业务对账系统规划
+- 分账系统规划
+- 聚合支付系统规划
+- 分账 SaaS 平台规划
+- 物流撮合行业分账试点规划
+- 营帐通拆分后的目标架构和版本路线
+
+上述内容应分别沉淀到对应产品线或项目目录。
+
+## 建议文档
+
+后续建议优先补充：
+
+- `营帐通-现有产品说明.md`
+- `营帐通-现有功能清单.md`
+- `营帐通-现有业务流程.md`
+- `营帐通-现有客户使用情况.md`
+- `营帐通-现有问题与能力缺口.md`

10-产品线/连锁业务对账系统/README.md

@@ -0,0 +1,5 @@
+# 连锁业务对账系统
+
+本目录用于沉淀营帐通拆分后的对账方向规划。
+
+重点关注连锁餐饮、连锁鞋服、连锁零售、连锁药店等多门店连锁业务下的订单对账、支付对账、平台账单对账、银行入账对账、差异识别和差异处理闭环。

20-行业解决方案/README.md

@@ -0,0 +1,5 @@
+# 行业解决方案
+
+本目录用于沉淀面向不同行业的解决方案、行业业务模型、行业差异化需求、行业售前材料和标准方案。
+
+当前重点行业包括餐饮连锁、连锁鞋服、连锁零售、连锁药店、物流撮合。

20-行业解决方案/餐饮连锁/00-典型客户背景与解决方案规划前提.md

@@ -0,0 +1,286 @@
+# 典型客户背景与解决方案规划前提
+
+## 1. 文档目的
+
+本文档用于沉淀餐饮连锁行业典型客户的业务背景、组织背景、关键业务规则和解决方案规划前提，作为后续《餐饮连锁行业数字化解决方案规划》文档的基础输入。
+
+本文档重点描述行业客户场景和产品规划约束，不涉及具体技术实现方案。
+
+当前规划视角不是单一集团内部 IT 负责人视角，而是餐饮连锁行业信息化解决方案和软件产品负责人视角。本文档中的集团背景可作为大型餐饮连锁客户的典型样板，用于指导现有产品升级、解决方案组合和后续产品线拓展。
+
+## 2. 典型客户经营背景
+
+典型目标客户为多品牌、多业态的大型餐饮连锁集团，旗下拥有多个餐饮品牌，覆盖小吃、米线、火锅、卤味、自助餐、茶饮等多种餐饮业态。
+
+其中，小吃品牌和茶饮品牌已形成万店级连锁规模，其他品牌分别拥有几十家至几百家门店不等。
+
+该类客户整体经营具备以下特征：
+
+- 品牌数量多，各品牌在定位、客群、产品结构、价格带、门店模型上存在差异。
+- 业态跨度大，覆盖小吃、茶饮、米线、火锅、卤味、自助餐等不同经营场景。
+- 门店规模差异明显，既有万店级成熟品牌，也有区域型、成长型品牌。
+- 经营模式复杂，涉及直营、加盟、联营等多种门店经营模式。
+- 客户需要在统一管控基础上，支撑各品牌差异化经营和持续扩张。
+
+因此，面向该类客户的信息化解决方案不能按单一品牌、单一业态、单一经营模式规划，而应面向集团型餐饮连锁企业整体，统一支撑多品牌、多业态、多组织、多经营模式的运营管理。
+
+## 3. 典型客户组织背景
+
+典型客户下辖多个品牌管理公司和多个专业业务公司。
+
+### 3.1 品牌管理公司
+
+每个品牌管理公司单独负责一个品牌的运营事宜，主要承担品牌经营、门店拓展、加盟管理、直营管理、联营管理、区域营运、商品策略、营销活动、门店标准执行等职责。
+
+品牌管理公司内部一般按经营模式划分为：
+
+- 加盟部门
+- 直营部门
+- 联营部门
+
+各经营部门下，再按大区、区域等层级进行门店管理，形成从品牌公司、经营部门、大区、区域到门店的分级管理体系。
+
+### 3.2 专业业务公司
+
+除品牌管理公司外，集团还设有多个专业业务公司，包括但不限于：
+
+- 装修公司
+- 物流公司
+- 外卖业务代运营公司
+- 新媒体运营公司
+- 信息技术服务公司
+- 供应链公司
+- 工厂
+
+这些专业业务公司承担集团内部专业化服务能力，为各品牌和门店提供装修工程、仓储物流、外卖运营、新媒体运营、IT 支撑、供应链采购、生产加工等服务。
+
+因此，该类客户业务协同不是简单的总部到门店两级关系，而是集团、品牌公司、业务公司、经营部门、大区、区域、门店、加盟商等多主体协同的复杂组织体系。
+
+## 4. 关键业务背景
+
+本章节沉淀当前已明确的关键业务规则，作为后续业务架构、产品边界、系统边界、流程规划和数据模型规划的输入。对于尚未明确或需要在具体业务系统中进一步设计的内容，本文档仅记录规划口径，不在背景阶段展开。
+
+### 4.1 门店经营模型
+
+集团门店存在直营、加盟、联营等经营模式，但三类模式之间没有绝对清晰、稳定的权责边界。实际经营中，门店可能在直营、加盟、联营之间发生切换，因此系统规划不应将经营模式设计为不可变的门店属性，也不应基于经营模式固化系统边界。
+
+门店经营模型的规划前提包括：
+
+- 直营店、加盟店、联营店之间边界不固定，经营模式允许切换。
+- 门店收入均归属门店，门店作为相对独立的经营主体进行管理。
+- 加盟商允许并鼓励多店、多品牌经营。
+- 门店存在托管、代运营、店中店、档口、外摆等特殊经营模型。
+
+因此，未来产品和系统应支持“门店主体 + 经营关系 + 合同规则 + 结算规则”的组合式管理，而不是仅按直营、加盟、联营三类标签进行简单区分。
+
+### 4.2 供应链与生产模型
+
+集团大部分商品采用统一采购、统一配送模式，少部分商品允许门店自采，例如蔬菜等本地化、时效性较强的品类。
+
+供应链与生产模型的规划前提包括：
+
+- 大部分商品由集团统一采购和配送。
+- 少部分商品允许门店自采，自采需要申请和审批。
+- 各品牌共用供应商、仓库和工厂等供应链资源。
+- 履约模式以集团统配和门店自采为主。
+- 门店订货、补货、收货、退货、报损、盘点等具体流程延后到供应链、门店库存等系统规划中设计。
+
+因此，供应链相关产品规划需要同时支持集团统配和受控自采，并支持多品牌共用供应商、仓库、工厂和物流资源。
+
+### 4.3 商品与菜单管理背景
+
+商品与菜单管理背景将在商品与菜单管理系统、POS 与收银系统、门店订货与库存系统、供应链系统等相关系统规划时补充。
+
+后续规划时需重点关注：
+
+- 商品、原辅料、半成品、成品、套餐、加料、规格等对象关系。
+- 不同品牌、不同业态的菜单结构差异。
+- 堂食、外带、外卖、团购、小程序等渠道菜单差异。
+- 商品价格、会员价、活动价、渠道价的管理边界。
+- 商品与原辅料、配方、库存、成本、毛利之间的关系。
+
+### 4.4 会员与营销背景
+
+集团会员体系按品牌独立运营，不建设跨品牌统一会员。积分、储值、券、权益等会员资产和权益不跨品牌共享。
+
+会员与营销模型的规划前提包括：
+
+- 当前及未来规划均按品牌独立会员体系建设。
+- 不建设集团统一会员，不做跨品牌会员共享。
+- 积分、储值、券、权益不跨品牌共享。
+- 加盟店参与会员权益和营销成本分摊。
+- 营销活动主要由品牌发起。
+- 外卖平台、自有小程序、社群、新媒体之间的协同方式待后续明确。
+
+因此，会员与营销相关产品应采用统一平台能力，但按品牌隔离会员资产、权益规则、营销活动、成本分摊和数据口径。
+
+### 4.5 财务与结算背景
+
+门店作为单独经营主体进行管理，需要支持门店级经营核算、资金归集、对账结算和分账。
+
+财务与结算模型的规划前提包括：
+
+- 直营、加盟、联营的财务核算口径需要在财务与结算系统规划中进一步明确。
+- 加盟费、保证金、管理费、物料款、装修款、设备款等费用统一缴费，并在完成对账结算后进行分账。
+- 所有门店销售款进入品牌开设的银行监管账户，对账结算完成后分账到门店钱包。
+- 外卖平台款项结算到品牌开设的银行监管账户，对账结算完成后分账到门店钱包。
+- 供应链公司、物流公司、装修公司与品牌公司之间存在内部结算。
+- 需要支持门店级利润表、加盟商利润表、品牌利润表。
+
+因此，财务与结算相关产品应重点支撑多主体结算、监管账户归集、门店钱包、费用分账、内部结算和多层级利润表。这一方向与现有产品“营帐通”的核心能力高度匹配，应作为营帐通后续升级的重点场景。
+
+### 4.6 渠道与订单背景
+
+集团门店订单来源包括堂食、外带、自提、外卖、团购、私域、小程序等，当前订单均在收银系统中汇聚。
+
+渠道与订单模型的规划前提包括：
+
+- 堂食、外带、自提、外卖、团购、私域、小程序订单均在收银系统中汇聚。
+- 美团、饿了么、抖音、本地生活等平台可由门店自运营，也可由外卖代运营公司或新媒体公司代运营。
+- 外卖代运营公司仅代理外卖平台或三方团购平台的运营。
+- 不同渠道的商品定价可以不同。
+- 不同渠道的结算时间可以不同。
+- 是否需要独立统一订单中心，以及订单中心是否归属于收银系统，需要在应用系统总体蓝图和 POS / 订单系统边界规划中进一步明确。
+
+因此，订单规划需要重点明确 POS 收银系统、外卖运营系统、营销系统、财务结算系统之间的订单归集、状态流转、价格管理、库存占用、渠道对账和结算边界。其中，多渠道订单对账、渠道结算和分账应纳入营帐通产品能力规划；订单数据沉淀和经营分析应纳入门店大数据平台能力规划。
+
+### 4.7 门店营运管理背景
+
+门店营运管理相关内容将在具体业务系统规划中展开，包括：
+
+- 门店巡检、稽核、督导、整改流程。
+- SOP、培训、考试、认证管理方式。
+- 食安管理、设备管理、证照管理、客诉管理。
+- 区域经理、督导、店长的管理职责。
+- 门店经营指标和考核机制。
+
+上述内容后续应分别在营运督导管理系统、人力与培训系统、门店生命周期管理系统、数据分析与经营看板等章节中展开。
+
+## 5. 解决方案与产品规划原则
+
+面向集团型餐饮连锁客户，信息化解决方案应支持客户统一规划、统一建设、统一运维，对客户旗下所有品牌进行统一支撑。各子品牌不应独立建设割裂的核心 IT 系统。
+
+### 5.1 统一平台
+
+- 核心信息化系统由客户集团统一规划建设。
+- 不以单个品牌为单位重复建设系统。
+- 通过统一平台支撑多品牌、多业态、多经营模式运营。
+
+### 5.2 品牌差异配置
+
+- 品牌公司负责品牌运营管理，不单独建设 IT 系统。
+- 品牌差异、业态差异、经营模式差异，通过系统配置、流程模板、业务参数、权限规则实现。
+- 对确有差异的业务场景，可在统一平台下建设差异化功能模块。
+
+### 5.3 集团管控与品牌运营并重
+
+- 集团层面关注统一标准、统一数据、统一管控、资源协同和经营分析。
+- 品牌公司关注门店拓展、营运管理、加盟商管理、商品营销和经营结果。
+- 大区、区域、门店关注日常业务执行、经营达成、标准落地和问题整改。
+
+### 5.4 系统能力复用
+
+- 组织、账号、权限、门店、商品、供应商、加盟商、合同、流程、数据等基础能力应统一沉淀。
+- 各品牌、各业态、各业务公司共用集团统一能力，避免重复建设和数据割裂。
+
+### 5.5 产品化与方案化结合
+
+- 对行业共性强、复用价值高的能力，应优先沉淀为标准软件产品能力。
+- 对客户差异较大的能力，应通过配置、模板、参数、流程编排、行业方案包等方式适配。
+- 现有产品“营帐通、门店选址规划系统、门店大数据平台”应作为解决方案组合的核心产品资产。
+- 新增业务场景应评估是否可沉淀为产品线，而不是仅作为单个客户项目定制功能。
+
+## 6. 当前规划约束
+
+本轮规划不展开现有系统盘点和痛点清单，不以现有系统功能为主要约束进行规划。
+
+后续规划以餐饮连锁客户未来业务目标、组织管理模型、核心业务流程、统一平台建设原则和产品线拓展价值为主导，采用整体规划、分步建设、逐步替代的方式推进。
+
+需要保留的高层约束包括：
+
+- 当前存在老旧系统和信息孤岛问题，但本文档不逐项展开。
+- 当前系统对多品牌、多业态、多经营模式的适配不足，但不以现状系统作为规划边界。
+- 后续建设需要支持新旧系统分阶段并行和逐步替代，避免影响门店经营连续性。
+
+## 7. 解决方案规划目标
+
+基于餐饮连锁客户业务规模、组织复杂度和现有系统问题，需要规划一套面向大型连锁客户的数字化解决方案，并沉淀可复制的软件产品能力。
+
+### 7.1 支撑集团多品牌、多业态、多经营模式发展
+
+- 统一支撑小吃、茶饮、米线、火锅、卤味、自助餐等不同餐饮业态。
+- 支持直营、加盟、联营等多种经营模式。
+- 满足万店级成熟品牌和成长型品牌的不同管理需求。
+
+### 7.2 形成统一 IT 能力底座
+
+- 建立统一组织、账号、权限、门店、商品、加盟商、供应商、合同、流程、数据等基础能力。
+- 打通核心业务系统，减少重复建设和信息孤岛。
+- 为各品牌、各业务公司提供统一可复用的系统能力。
+
+### 7.3 提升集团管控和品牌运营能力
+
+- 支撑集团统一标准、统一流程、统一数据和统一风险管控。
+- 支撑品牌公司独立经营、差异化配置和快速扩张。
+- 支撑大区、区域、门店的日常运营管理和经营改善。
+
+### 7.4 打通核心业务链路
+
+- 打通加盟招商、签约、培训、装修、开业、营运、续约、退出的加盟商全生命周期。
+- 打通选址、工程装修、证照办理、开业筹备到正式营业的门店生命周期。
+- 打通商品研发、采购、生产、仓储、配送、门店订货、销售、库存、毛利分析的商品与供应链链路。
+- 打通销售、外卖、会员、营销、财务结算、经营分析的门店经营链路。
+
+### 7.5 建立统一数据分析体系
+
+- 统一集团经营数据口径。
+- 建立集团、品牌、经营模式、大区、区域、门店等多维度经营分析能力。
+- 支撑集团战略决策、品牌经营复盘、区域运营改进和门店经营提升。
+
+### 7.6 支撑现有产品升级和产品线拓展
+
+- 将门店对账、分账、门店钱包、监管账户、利润表等场景纳入营帐通升级方向。
+- 将门店开发、选址评估、区域布局、开店复盘等场景纳入门店选址规划系统升级方向。
+- 将集团、品牌、区域、门店、加盟商经营分析纳入门店大数据平台升级方向。
+- 围绕门店生命周期、加盟商管理、营运督导、订货库存、外卖运营、会员营销等方向拓展产品线。
+
+## 8. 建设与产品演进策略
+
+大型餐饮连锁客户的 IT 重规划不适合采用一次性整体替换方式，应采用“整体规划、分步建设、逐步替代”的建设策略。同时，产品负责人应将客户项目中的共性能力沉淀为标准产品能力，形成“项目验证、产品沉淀、方案复制”的演进路径。
+
+### 8.1 统一规划
+
+- 先完成集团级业务架构、应用架构、数据架构和组织权限架构规划。
+- 明确各业务系统边界、核心流程、主数据归属和系统协同关系。
+
+### 8.2 分阶段建设
+
+- 按业务价值、系统依赖、实施风险和组织承接能力分阶段推进。
+- 优先建设集团统一底座和高价值核心业务系统。
+- 再逐步替换老旧系统，完善跨系统业务闭环。
+
+### 8.3 逐步替代
+
+- 对 POS、供应链、财务、会员、订货库存等核心系统，采用试点、并行、灰度、分批迁移方式。
+- 避免一次性切换带来的经营风险。
+- 在新旧系统并行阶段，保证数据同步、业务连续和财务可对账。
+
+### 8.4 持续治理
+
+- 系统建设与数据治理、流程治理、组织权限治理同步推进。
+- 建立集团统一 IT 治理机制，确保系统长期可持续演进。
+
+## 9. 后续规划展开方向
+
+后续《餐饮连锁行业数字化解决方案规划》应在本文档基础上继续展开：
+
+- 餐饮连锁行业数字化解决方案蓝图
+- 业务流程架构设计
+- 应用系统架构规划
+- 各业务系统边界划分
+- 主数据与数据治理规划
+- 组织、角色、权限体系规划
+- 分阶段建设路线图
+- 新旧系统替代策略
+- 现有产品升级规划
+- 新产品线拓展规划

20-行业解决方案/餐饮连锁/01-餐饮连锁行业数字化解决方案规划目录.md

@@ -0,0 +1,321 @@
+# 餐饮连锁行业数字化解决方案规划目录
+
+## 1. 文档定位
+
+本文档用于规划《餐饮连锁行业数字化解决方案规划》的完整目录结构，作为后续逐章编写、评审、补充和落地的文档骨架。
+
+规划文档面向餐饮连锁客户、公司内部产品团队、解决方案团队、销售售前团队、交付实施团队及外部合作伙伴，重点回答以下问题：
+
+- 餐饮连锁企业需要什么样的数字化系统体系。
+- 各业务系统分别解决什么问题，边界如何划分。
+- 多品牌、多业态、多经营模式如何在统一系统中得到支撑。
+- 现有产品“营帐通、门店选址规划系统、门店大数据平台”如何覆盖客户核心场景。
+- 营帐通如何拆分为连锁业务对账系统和分账系统，并支撑跨行业与平台化发展。
+- 哪些场景应作为现有产品升级方向，哪些场景应拓展为新产品线。
+- 新旧系统如何分阶段替换，降低业务风险。
+- 建设优先级、阶段目标和关键里程碑如何安排。
+
+## 2. 建议文档总目录
+
+```text
+餐饮连锁行业数字化解决方案规划
+├── 01. 项目背景与规划目标
+│   ├── 1.1 目标客户经营背景
+│   ├── 1.2 目标客户组织背景
+│   ├── 1.3 门店经营模型背景
+│   ├── 1.4 供应链与生产模型背景
+│   ├── 1.5 会员与营销背景
+│   ├── 1.6 财务与结算背景
+│   ├── 1.7 渠道与订单背景
+│   ├── 1.8 当前解决方案规划约束
+│   ├── 1.9 解决方案规划目标
+│   └── 1.10 规划范围与不包含范围
+│
+├── 02. 产品定位与方案组合
+│   ├── 2.1 餐饮连锁行业目标客群
+│   ├── 2.2 解决方案总体定位
+│   ├── 2.3 现有产品能力盘点
+│   ├── 2.4 营帐通产品定位与适用场景
+│   ├── 2.5 连锁业务对账系统定位与适用场景
+│   ├── 2.6 分账系统定位与适用场景
+│   ├── 2.7 分账 SaaS 平台定位与适用场景
+│   ├── 2.8 门店选址规划系统定位与适用场景
+│   ├── 2.9 门店大数据平台定位与适用场景
+│   ├── 2.10 产品组合方案
+│   ├── 2.11 产品能力缺口
+│   └── 2.12 产品线拓展方向
+│
+├── 03. 业务架构规划
+│   ├── 3.1 集团整体业务架构
+│   ├── 3.2 多品牌运营管理架构
+│   ├── 3.3 多业态经营差异分析
+│   ├── 3.4 门店经营主体模型
+│   ├── 3.5 直营、加盟、联营切换模型
+│   ├── 3.6 加盟商多店多品牌经营模型
+│   ├── 3.7 托管、档口、店中店、外摆等特殊模型
+│   ├── 3.8 专业业务公司协同模型
+│   └── 3.9 集团、品牌、区域、门店权责划分
+│
+├── 04. 核心业务流程规划
+│   ├── 4.1 门店全生命周期流程
+│   ├── 4.2 加盟商全生命周期流程
+│   ├── 4.3 商品全生命周期流程
+│   ├── 4.4 集团统配流程
+│   ├── 4.5 门店自采申请与审批流程
+│   ├── 4.6 门店日常营运流程
+│   ├── 4.7 品牌会员与营销运营流程
+│   ├── 4.8 外卖与三方平台运营协同流程
+│   ├── 4.9 财务结算、对账与分账流程
+│   ├── 4.10 人员培训与督导流程
+│   └── 4.11 跨公司协同流程
+│
+├── 05. 应用系统总体蓝图
+│   ├── 5.1 应用系统规划原则
+│   ├── 5.2 集团统一应用架构
+│   ├── 5.3 系统分层规划
+│   ├── 5.4 集团统一底座系统
+│   ├── 5.5 品牌运营类系统
+│   ├── 5.6 门店经营类系统
+│   ├── 5.7 供应链与工厂类系统
+│   ├── 5.8 财务与结算类系统
+│   ├── 5.9 数据分析与经营决策类系统
+│   └── 5.10 外部平台与生态系统
+│
+├── 06. 集团统一底座规划
+│   ├── 6.1 统一组织管理
+│   ├── 6.2 统一账号与权限
+│   ├── 6.3 统一流程审批
+│   ├── 6.4 统一消息与待办
+│   ├── 6.5 统一主数据管理
+│   ├── 6.6 统一系统门户
+│   └── 6.7 统一系统配置中心
+│
+├── 07. 主数据体系规划
+│   ├── 7.1 主数据规划原则
+│   ├── 7.2 组织主数据
+│   ├── 7.3 品牌主数据
+│   ├── 7.4 门店主数据
+│   ├── 7.5 商品主数据
+│   ├── 7.6 原辅料主数据
+│   ├── 7.7 供应商主数据
+│   ├── 7.8 加盟商主数据
+│   ├── 7.9 客户与会员主数据
+│   ├── 7.10 合同主数据
+│   └── 7.11 主数据治理机制
+│
+├── 08. 核心业务系统规划
+│   ├── 8.1 门店生命周期管理系统
+│   ├── 8.2 加盟商管理系统
+│   ├── 8.3 工程装修管理系统
+│   ├── 8.4 营运督导管理系统
+│   ├── 8.5 门店 POS 与收银系统
+│   ├── 8.6 客服系统
+│   ├── 8.7 门店订货与库存系统
+│   ├── 8.8 商品与菜单管理系统
+│   ├── 8.9 品牌会员管理系统
+│   ├── 8.10 营销活动管理系统
+│   ├── 8.11 外卖与三方平台运营管理系统
+│   ├── 8.12 采购管理系统
+│   ├── 8.13 仓储管理系统
+│   ├── 8.14 物流配送管理系统
+│   ├── 8.15 工厂生产管理系统
+│   ├── 8.16 财务共享与结算系统
+│   ├── 8.17 人力与培训系统
+│   ├── 8.18 IT 服务管理系统
+│   └── 8.19 数据分析与经营看板
+│
+├── 09. 产品与系统边界规划
+│   ├── 9.1 产品边界划分原则
+│   ├── 9.2 系统边界划分原则
+│   ├── 9.3 集团统一能力与品牌差异能力边界
+│   ├── 9.4 品牌公司与专业业务公司系统边界
+│   ├── 9.5 总部、区域、门店系统使用边界
+│   ├── 9.6 POS 收银系统与订单中心边界
+│   ├── 9.7 营帐通与财务结算系统边界
+│   ├── 9.8 门店大数据平台与业务系统边界
+│   ├── 9.9 门店选址规划系统与门店生命周期系统边界
+│   ├── 9.10 会员、营销与渠道运营边界
+│   ├── 9.11 财务结算、门店钱包与监管账户边界
+│   ├── 9.12 业务系统间协同关系
+│   ├── 9.13 核心数据流转关系
+│   └── 9.14 边界争议处理原则
+│
+├── 10. 多品牌多业态适配规划
+│   ├── 10.1 多品牌配置模型
+│   ├── 10.2 多业态差异配置模型
+│   ├── 10.3 小吃业态系统适配
+│   ├── 10.4 茶饮业态系统适配
+│   ├── 10.5 火锅业态系统适配
+│   ├── 10.6 米线业态系统适配
+│   ├── 10.7 卤味业态系统适配
+│   ├── 10.8 自助餐业态系统适配
+│   └── 10.9 成熟品牌与成长品牌差异适配
+│
+├── 11. 组织、角色与权限规划
+│   ├── 11.1 权限规划原则
+│   ├── 11.2 集团层权限模型
+│   ├── 11.3 品牌公司权限模型
+│   ├── 11.4 业务公司权限模型
+│   ├── 11.5 大区与区域权限模型
+│   ├── 11.6 门店权限模型
+│   ├── 11.7 加盟商权限模型
+│   ├── 11.8 数据权限模型
+│   └── 11.9 权限治理机制
+│
+├── 12. 数据分析与经营决策规划
+│   ├── 12.1 数据分析体系定位
+│   ├── 12.2 集团经营分析
+│   ├── 12.3 品牌经营分析
+│   ├── 12.4 大区与区域经营分析
+│   ├── 12.5 门店经营分析
+│   ├── 12.6 加盟商经营分析
+│   ├── 12.7 商品与毛利分析
+│   ├── 12.8 供应链履约分析
+│   ├── 12.9 会员与营销分析
+│   ├── 12.10 渠道与订单分析
+│   ├── 12.11 门店级利润表
+│   ├── 12.12 加盟商利润表
+│   ├── 12.13 品牌利润表
+│   └── 12.14 指标口径治理
+│
+├── 13. 新旧系统替代策略
+│   ├── 13.1 替代策略原则
+│   ├── 13.2 替代范围评估
+│   ├── 13.3 业务影响与风险评估
+│   ├── 13.4 新旧系统并行策略
+│   ├── 13.5 数据迁移与对账策略
+│   ├── 13.6 品牌试点策略
+│   ├── 13.7 区域试点策略
+│   ├── 13.8 门店批量切换策略
+│   └── 13.9 切换风险与回退机制
+│
+├── 14. 分阶段建设路线图
+│   ├── 14.1 建设阶段划分原则
+│   ├── 14.2 第一阶段：统一底座与主数据治理
+│   ├── 14.3 第二阶段：门店与加盟核心链路
+│   ├── 14.4 第三阶段：供应链与财务结算闭环
+│   ├── 14.5 第四阶段：会员营销、外卖运营与数据经营
+│   ├── 14.6 第五阶段：全面替代旧系统与持续优化
+│   ├── 14.7 各阶段关键成果
+│   └── 14.8 各阶段业务价值评估
+│
+├── 15. 项目治理与推进机制
+│   ├── 15.1 项目组织机制
+│   ├── 15.2 集团与品牌协同机制
+│   ├── 15.3 业务需求管理机制
+│   ├── 15.4 系统上线评审机制
+│   ├── 15.5 数据治理机制
+│   ├── 15.6 变更管理机制
+│   ├── 15.7 培训推广机制
+│   └── 15.8 持续运营机制
+│
+├── 16. 产品升级与产品线拓展规划
+│   ├── 16.1 产品升级规划原则
+│   ├── 16.2 营帐通升级路线
+│   ├── 16.3 连锁业务对账系统升级路线
+│   ├── 16.4 分账系统升级路线
+│   ├── 16.5 分账 SaaS 平台规划
+│   ├── 16.6 跨行业拓展规划
+│   ├── 16.7 平台业务与担保交易场景规划
+│   ├── 16.8 门店选址规划系统升级路线
+│   ├── 16.9 门店大数据平台升级路线
+│   ├── 16.10 收银系统产品规划
+│   ├── 16.11 客服系统产品规划
+│   ├── 16.12 门店生命周期管理产品规划
+│   ├── 16.13 商品管理产品规划
+│   ├── 16.14 加盟商管理产品规划
+│   ├── 16.15 营运督导产品规划
+│   ├── 16.16 订货库存产品规划
+│   ├── 16.17 外卖与三方平台运营产品规划
+│   ├── 16.18 会员营销产品规划
+│   └── 16.19 产品线优先级与商业化路径
+│
+└── 17. 附录
+    ├── 17.1 术语表
+    ├── 17.2 业务对象清单
+    ├── 17.3 系统清单
+    ├── 17.4 核心流程清单
+    ├── 17.5 核心报表与指标清单
+    └── 17.6 待确认问题清单
+```
+
+## 3. 各章节编写重点
+
+### 3.1 项目背景与规划目标
+
+说明目标客户经营背景、组织背景、关键业务模型、规划目标和规划边界。该章节可引用 `02-典型客户背景与解决方案规划前提.md` 作为基础。本轮规划不展开现有系统盘点和痛点清单。
+
+### 3.2 产品定位与方案组合
+
+说明现有产品如何覆盖餐饮连锁客户核心场景，明确营帐通、门店选址规划系统、门店大数据平台在整体解决方案中的位置。重点说明营帐通拆分为连锁业务对账系统和分账系统后的产品边界，并识别跨行业、平台化、SaaS 化和餐饮横向产品线拓展方向。
+
+### 3.3 业务架构规划
+
+从集团业务管理视角，梳理多品牌、多业态、多经营模式、多业务公司的整体业务架构，明确各组织主体的权责关系。直营、加盟、联营不作为绝对固定边界，应重点规划门店经营主体、经营关系、合同规则和结算规则。
+
+### 3.4 核心业务流程规划
+
+围绕门店、加盟商、商品、供应链、会员、外卖、财务等核心对象，梳理端到端业务流程，重点识别跨组织、跨系统协同关系。门店订货、补货、收货、退货、报损、盘点等细节在相关系统规划中展开。
+
+### 3.5 应用系统总体蓝图
+
+定义目标客户未来应用系统的总体分层和系统构成，明确哪些系统属于集团统一底座，哪些系统属于业务运营系统，哪些系统属于数据分析和经营决策系统。
+
+### 3.6 集团统一底座规划
+
+规划组织、账号、权限、流程、消息、主数据、门户、配置中心等通用能力，为多品牌、多业态共享系统提供基础支撑。
+
+### 3.7 主数据体系规划
+
+明确组织、品牌、门店、商品、原辅料、供应商、加盟商、会员、合同等主数据的管理归属、维护流程和治理机制。
+
+### 3.8 核心业务系统规划
+
+逐个系统说明业务定位、核心用户、核心功能、系统边界、上下游关系、关键数据和主要流程。
+
+### 3.9 产品与系统边界规划
+
+重点解决产品之间、系统之间“谁负责什么、谁产生数据、谁消费数据、谁作为主责系统”的问题，避免后续产品重叠、系统重复建设和边界不清。
+
+### 3.10 多品牌多业态适配规划
+
+说明统一系统如何支撑不同品牌、不同业态、不同门店模型、不同经营模式。重点区分共性能力、配置能力和差异化能力。
+
+### 3.11 组织、角色与权限规划
+
+梳理集团、品牌公司、业务公司、大区、区域、门店、加盟商等不同主体的角色体系、功能权限和数据权限。
+
+### 3.12 数据分析与经营决策规划
+
+规划集团、品牌、区域、门店等不同层级的经营分析体系，明确核心指标口径和经营看板方向。
+
+### 3.13 新旧系统替代策略
+
+在不展开现有系统盘点的前提下，基于业务影响、上线风险和替代范围，制定试点策略、并行策略、数据迁移策略、对账机制和回退机制。
+
+### 3.14 分阶段建设路线图
+
+按业务价值、依赖关系、实施风险和组织承接能力，规划分阶段建设路径，明确每个阶段的建设目标、系统范围和业务成果。
+
+### 3.15 项目治理与推进机制
+
+规划项目组织、需求管理、业务参与、上线评审、数据治理、培训推广和持续运营机制，保障规划可落地。
+
+### 3.16 产品升级与产品线拓展规划
+
+围绕现有产品升级和新产品线拓展，明确每条产品线的目标客户、核心场景、能力范围、与现有产品关系、优先级和商业化路径。
+
+其中，对账与分账系统属于纵向发展主线，应重点规划跨行业拓展、分账 SaaS 平台和担保交易场景。收银系统、客服系统、门店生命周期系统、商品管理系统等属于餐饮行业横向发展主线，应重点规划与现有产品的组合关系。
+
+## 4. 后续建议优先补充的文档
+
+建议后续按以下顺序继续补充：
+
+1. `03-产品定位与方案组合.md`
+2. `04-业务架构规划.md`
+3. `05-核心业务流程规划.md`
+4. `06-应用系统总体蓝图.md`
+5. `07-产品与系统边界规划.md`
+6. `08-产品升级与产品线拓展规划.md`
+
+上述文档完成后，即可形成一版可用于客户交流、内部产品评审和解决方案评审的数字化解决方案规划初稿。

30-客户与试点项目/README.md

@@ -0,0 +1,5 @@
+# 客户与试点项目
+
+本目录用于沉淀客户升级项目、试点项目、客户访谈、项目复盘、需求差异和产品能力沉淀。
+
+当前重点项目包括万店餐饮连锁客户营帐通升级、鞋服连锁客户营帐通升级、物流撮合行业分账试点。

40-平台与架构/README.md

@@ -0,0 +1,9 @@
+# 平台与架构
+
+本目录用于沉淀基础平台、技术架构调整、产品模块拆分、系统边界、平台能力清单等文档。
+
+产品侧只关注业务边界、产品边界、平台能力和演进路径，不展开具体技术实现细节。
+
+## 当前文档
+
+- [基础平台产品设计](基础平台/基础平台产品设计.md)

40-平台与架构/基础平台/功能模块/01-客户管理.md

@@ -0,0 +1,50 @@
+# 5.1 客户管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.1.1 功能说明
+
+客户管理用于维护使用公司产品的客户主体，是多客户隔离和业务系统开通的基础。
+
+## 5.1.2 功能范围
+
+- 新增客户
+- 编辑客户信息
+- 启用 / 停用客户
+- 查询客户列表
+- 查看客户详情
+- 为客户开通应用
+- 维护客户管理员
+
+## 5.1.3 字段要求
+
+客户基础信息至少包括：
+
+- 客户名称
+- 客户简称
+- 客户编码
+- 客户类型
+- 所属行业
+- 联系人
+- 联系方式
+- 启用状态
+- 开通应用
+- 创建时间
+
+## 5.1.4 业务规则
+
+- 客户编码全局唯一。
+- 停用客户后，该客户下用户不可登录业务系统。
+- 客户停用不删除历史数据。
+- 客户未开通某应用时，该客户下用户不可看到该应用入口。
+- 一个客户至少应有一个客户管理员。
+
+## 5.1.5 验收标准
+
+- 可创建、编辑、停用客户。
+- 可为客户开通和关闭应用。
+- 停用客户后，该客户下账号无法继续访问系统。
+- 客户之间数据不可互相查看。

40-平台与架构/基础平台/功能模块/02-应用管理.md

@@ -0,0 +1,43 @@
+# 5.2 应用管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.2.1 功能说明
+
+应用管理用于维护接入基础平台的业务系统。
+
+## 5.2.2 功能范围
+
+- 新增应用
+- 编辑应用信息
+- 启用 / 停用应用
+- 配置应用入口
+- 配置应用菜单
+- 配置应用权限项
+- 配置应用可授权范围
+
+## 5.2.3 应用清单
+
+1.0 需要支持以下应用接入：
+
+- 连锁业务对账系统
+- 分账系统
+- 聚合支付
+- 门店选址规划系统
+- 连锁门店客服系统
+
+## 5.2.4 业务规则
+
+- 应用编码全局唯一。
+- 应用停用后，所有客户不可访问该应用。
+- 客户未开通应用时，不显示该应用入口。
+- 应用菜单和权限项由产品管理员维护。
+
+## 5.2.5 验收标准
+
+- 可维护应用基础信息。
+- 可控制客户是否开通某应用。
+- 应用停用后入口不可访问。

40-平台与架构/基础平台/功能模块/03-组织管理.md

@@ -0,0 +1,50 @@
+# 5.3 组织管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.3.1 功能说明
+
+组织管理用于维护客户内部组织结构，支撑总部、部门、品牌、区域、门店等组织层级。
+
+## 5.3.2 功能范围
+
+- 新增组织
+- 编辑组织
+- 启用 / 停用组织
+- 查询组织树
+- 调整上级组织
+- 维护组织负责人
+- 维护组织类型
+
+## 5.3.3 组织类型
+
+基础平台 1.0 支持以下组织类型：
+
+- 公司
+- 部门
+- 品牌
+- 大区
+- 区域
+- 门店
+- 项目组织
+- 平台商户
+- 其他
+
+## 5.3.4 业务规则
+
+- 组织必须归属于某个客户。
+- 组织编码在同一客户下唯一。
+- 组织支持多级结构。
+- 停用组织后，该组织不可继续分配给新用户。
+- 停用组织不影响历史数据归属。
+- 门店可以作为一种组织类型，但门店业务属性由业务系统维护。
+
+## 5.3.5 验收标准
+
+- 可维护多级组织树。
+- 可按客户隔离组织数据。
+- 停用组织后不可继续用于新授权。
+- 用户数据权限可按组织范围生效。

40-平台与架构/基础平台/功能模块/04-用户与账号管理.md

@@ -0,0 +1,54 @@
+# 5.4 用户与账号管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.4.1 功能说明
+
+用户与账号管理用于维护系统使用人员及登录账号。
+
+## 5.4.2 功能范围
+
+- 新增用户
+- 编辑用户
+- 启用 / 停用用户
+- 创建账号
+- 重置密码
+- 设置用户所属组织
+- 设置默认组织
+- 分配角色
+- 查询用户列表
+- 查看用户详情
+
+## 5.4.3 字段要求
+
+用户信息至少包括：
+
+- 姓名
+- 手机号
+- 登录账号
+- 所属客户
+- 所属组织
+- 默认组织
+- 角色
+- 状态
+- 创建时间
+
+## 5.4.4 业务规则
+
+- 用户必须归属于一个客户。
+- 登录账号在平台内唯一。
+- 手机号是否唯一按客户维度控制，1.0 默认同一客户下唯一。
+- 一个用户可属于多个组织。
+- 一个用户必须有一个默认组织。
+- 停用用户后不可登录。
+- 用户离职或停用不删除历史操作日志。
+
+## 5.4.5 验收标准
+
+- 可创建用户并分配组织和角色。
+- 用户登录后只能看到授权应用和菜单。
+- 停用用户后不能登录。
+- 用户切换组织时，数据范围应随组织变化。

40-平台与架构/基础平台/功能模块/05-单点登录与统一认证鉴权.md

@@ -0,0 +1,72 @@
+# 5.5 单点登录与统一认证鉴权
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.5.1 功能说明
+
+单点登录与统一认证鉴权用于支撑用户一次登录后访问多个已授权业务应用，并统一完成所有应用的 Token 认证和鉴权。
+
+基础平台作为统一认证中心，所有接入应用不再各自独立维护登录认证逻辑。业务应用需要根据基础平台返回的认证结果和权限结果，控制用户访问。
+
+详细流程、Token 交互规则和验收口径见：[单点登录与统一认证鉴权设计](../单点登录与统一认证鉴权设计.md)。
+
+## 5.5.2 功能范围
+
+- 用户统一登录
+- 用户统一退出
+- 登录状态维护
+- Token 签发
+- Token 校验
+- Token 刷新
+- Token 失效
+- 应用访问鉴权
+- 用户身份信息获取
+- 当前登录用户信息获取
+- 用户授权应用列表获取
+- 用户菜单和权限获取
+
+## 5.5.3 业务规则
+
+- 用户登录由基础平台统一完成。
+- 用户登录成功后，可访问已开通且已授权的业务应用。
+- 用户未登录时，不可访问任何业务应用。
+- 用户访问业务应用时，业务应用必须通过基础平台完成 Token 认证鉴权。
+- Token 无效、过期、被注销或用户已停用时，业务应用必须拒绝访问。
+- 用户退出登录后，已登录应用应同步失效或在下一次认证时失效。
+- 客户停用、用户停用、应用停用、客户未开通应用、用户未授权应用时，认证鉴权均不通过。
+- 用户权限变更后，应能在合理时间内影响用户后续访问。
+- 业务应用不得绕过基础平台独立放行用户访问。
+
+## 5.5.4 鉴权判断维度
+
+基础平台认证鉴权至少需要判断：
+
+- Token 是否有效。
+- 用户是否存在且启用。
+- 用户所属客户是否启用。
+- 应用是否存在且启用。
+- 客户是否已开通该应用。
+- 用户是否拥有该应用访问权限。
+- 用户是否拥有对应菜单、操作或数据范围权限。
+
+## 5.5.5 业务系统接入要求
+
+所有接入基础平台的业务系统均需满足：
+
+- 登录入口统一接入基础平台。
+- 用户身份校验统一通过基础平台。
+- Token 认证鉴权统一通过基础平台。
+- 菜单、权限、数据范围以基础平台授权结果为准。
+- 业务系统可保留自身业务权限补充规则，但不得与基础平台授权结果冲突。
+
+## 5.5.6 验收标准
+
+- 用户一次登录后，可访问多个已授权应用。
+- 未授权应用不可访问。
+- Token 无效或过期时，业务应用拒绝访问。
+- 用户停用、客户停用、应用停用后，业务应用拒绝访问。
+- 用户退出后，再访问业务应用需要重新登录。
+- 各业务应用均通过基础平台完成 Token 认证鉴权。

40-平台与架构/基础平台/功能模块/06-统一门户与应用容器.md

@@ -0,0 +1,36 @@
+# 5.6 统一门户与应用容器
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.6.1 功能说明
+
+统一门户与应用容器用于承载基础平台页面和各业务应用页面。基础平台负责所有业务系统的菜单聚合、业务链接入口、页面框架、Tab 管理、iframe 嵌入和 Token 有效期管理。
+
+业务应用不再独立渲染系统级菜单。业务应用只负责提供自身业务页面，由基础平台通过 iframe 嵌入到右侧内容区。
+
+详细页面结构、容器规则、keepalive 规则和验收口径见：[统一门户与应用容器设计](../统一门户与应用容器设计.md)。
+
+## 5.6.2 页面总体布局
+
+基础平台主页面由三部分组成：
+
+- 头部区域
+- 左侧菜单导航栏
+- 右侧内容区
+
+右侧内容区用于展示基础平台自身页面和各业务应用 iframe 页面。
+
+## 5.6.3 验收标准
+
+- 基础平台可聚合展示用户有权限访问的所有应用菜单。
+- 业务应用不再独立展示系统级菜单。
+- 点击业务应用菜单后，可在右侧内容区通过 iframe 打开应用页面。
+- 打开的页面可生成 Tab。
+- Tab 切换时页面状态可保持。
+- 关闭 Tab 后页面状态释放。
+- iframe 应用可使用基础平台 Token 访问业务接口。
+- Token 刷新后，已打开 iframe 应用可继续访问。
+- 用户注销后，已打开 iframe 应用不可继续访问。

40-平台与架构/基础平台/功能模块/07-角色管理.md

@@ -0,0 +1,45 @@
+# 5.7 角色管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.7.1 功能说明
+
+角色管理用于将权限项组合成可分配给用户的权限集合。
+
+## 5.7.2 功能范围
+
+- 新增角色
+- 编辑角色
+- 复制角色
+- 启用 / 停用角色
+- 为角色配置权限
+- 为角色配置数据范围
+- 查询角色列表
+
+## 5.7.3 角色类型
+
+基础平台 1.0 支持：
+
+- 平台角色
+- 客户角色
+- 应用角色
+
+## 5.7.4 业务规则
+
+- 平台角色由平台超级管理员维护。
+- 客户角色由客户管理员维护。
+- 应用角色可作为系统预置角色。
+- 角色停用后不可再分配给新用户。
+- 停用角色不影响历史操作日志。
+- 用户拥有多个角色时，功能权限取并集。
+- 数据权限按角色配置规则合并，具体合并规则需在角色配置中明确展示。
+
+## 5.7.5 验收标准
+
+- 可创建角色并配置功能权限。
+- 用户分配角色后权限立即生效。
+- 角色停用后不可继续分配。
+- 多角色用户权限计算正确。

40-平台与架构/基础平台/功能模块/08-权限管理.md

@@ -0,0 +1,57 @@
+# 5.8 权限管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.8.1 功能说明
+
+权限管理用于控制用户可访问的应用、菜单、页面和操作。
+
+## 5.8.2 权限分类
+
+基础平台 1.0 支持：
+
+- 应用权限
+- 菜单权限
+- 操作权限
+- 数据范围权限
+
+## 5.8.3 操作权限
+
+基础操作权限包括：
+
+- 查看
+- 新增
+- 编辑
+- 删除
+- 审核
+- 导入
+- 导出
+- 启用 / 停用
+
+## 5.8.4 数据范围
+
+基础数据范围包括：
+
+- 全部数据
+- 本组织及下级组织
+- 本组织
+- 指定组织
+- 本人数据
+
+## 5.8.5 业务规则
+
+- 用户未授权应用时不可看到应用入口。
+- 用户未授权菜单时不可看到菜单。
+- 用户未授权操作时不可执行对应操作。
+- 数据权限必须按客户隔离。
+- 不允许用户通过 URL 或其他入口访问未授权功能。
+
+## 5.8.6 验收标准
+
+- 菜单显示与用户权限一致。
+- 操作按钮显示与用户权限一致。
+- 未授权用户无法访问对应接口或页面。
+- 数据范围控制正确。

40-平台与架构/基础平台/功能模块/09-菜单管理.md

@@ -0,0 +1,32 @@
+# 5.9 菜单管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.9.1 功能说明
+
+菜单管理用于维护应用在系统中的导航结构。
+
+## 5.9.2 功能范围
+
+- 新增菜单
+- 编辑菜单
+- 排序菜单
+- 启用 / 停用菜单
+- 绑定权限项
+- 配置菜单所属应用
+
+## 5.9.3 业务规则
+
+- 菜单必须归属于某个应用。
+- 菜单可多级展示。
+- 停用菜单后用户不可见。
+- 菜单是否可见由应用开通状态、用户角色、菜单权限共同决定。
+
+## 5.9.4 验收标准
+
+- 菜单可按应用维护。
+- 菜单可根据权限显示或隐藏。
+- 菜单排序生效。

40-平台与架构/基础平台/功能模块/10-基础配置管理.md

@@ -0,0 +1,40 @@
+# 5.10 基础配置管理
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.10.1 功能说明
+
+基础配置管理用于维护客户级、应用级基础参数。
+
+## 5.10.2 功能范围
+
+- 配置项管理
+- 配置值维护
+- 启用 / 停用配置
+- 按客户配置
+- 按应用配置
+
+## 5.10.3 配置分类
+
+1.0 支持：
+
+- 平台配置
+- 客户配置
+- 应用配置
+- 业务开关
+
+## 5.10.4 业务规则
+
+- 平台配置仅平台管理员维护。
+- 客户配置仅影响当前客户。
+- 应用配置仅影响对应应用。
+- 配置变更需要记录操作日志。
+
+## 5.10.5 验收标准
+
+- 可维护客户级配置。
+- 可维护应用级配置。
+- 配置变更后业务系统可读取到正确配置。

40-平台与架构/基础平台/功能模块/11-消息与待办.md

@@ -0,0 +1,31 @@
+# 5.11 消息与待办
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.11.1 功能说明
+
+消息与待办用于为业务系统提供基础通知能力。
+
+## 5.11.2 功能范围
+
+- 系统消息
+- 待办消息
+- 消息已读 / 未读
+- 消息查询
+- 消息跳转业务系统
+
+## 5.11.3 业务规则
+
+- 消息必须归属于客户和用户。
+- 用户只能查看自己的消息。
+- 待办可关联业务系统和业务单据。
+- 业务单据处理完成后，待办状态应支持更新。
+
+## 5.11.4 验收标准
+
+- 用户可查看自己的消息和待办。
+- 已读 / 未读状态正确。
+- 待办可跳转到对应业务系统。

40-平台与架构/基础平台/功能模块/12-操作日志.md

@@ -0,0 +1,50 @@
+# 5.12 操作日志
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.12.1 功能说明
+
+操作日志用于记录用户关键操作，支持审计和问题排查。
+
+## 5.12.2 日志范围
+
+1.0 至少记录：
+
+- 登录
+- 新增
+- 编辑
+- 删除
+- 启用 / 停用
+- 授权变更
+- 配置变更
+- 导入
+- 导出
+
+## 5.12.3 日志字段
+
+日志至少包括：
+
+- 操作时间
+- 操作用户
+- 所属客户
+- 所属组织
+- 操作应用
+- 操作模块
+- 操作类型
+- 操作对象
+- 操作结果
+
+## 5.12.4 业务规则
+
+- 操作日志不可由普通用户修改或删除。
+- 日志查询需按权限控制。
+- 不同客户日志隔离。
+
+## 5.12.5 验收标准
+
+- 关键操作可生成日志。
+- 日志内容可查询。
+- 客户之间日志隔离。

40-平台与架构/基础平台/功能模块/13-数据字典.md

@@ -0,0 +1,29 @@
+# 5.13 数据字典
+
+本文档从《基础平台产品设计》第 5 章拆分而来，用于独立描述基础平台功能模块的业务需求、规则和验收标准。
+
+上级文档：[基础平台产品设计](../基础平台产品设计.md)
+
+
+## 5.13.1 功能说明
+
+数据字典用于维护基础枚举类数据，供各业务系统复用。
+
+## 5.13.2 功能范围
+
+- 字典分类
+- 字典项
+- 启用 / 停用字典项
+- 字典项排序
+
+## 5.13.3 业务规则
+
+- 字典编码唯一。
+- 停用字典项后，不影响历史数据展示。
+- 字典变更需记录日志。
+
+## 5.13.4 验收标准
+
+- 可维护字典分类和字典项。
+- 业务系统可使用启用状态的字典项。
+- 停用字典项不影响历史数据。

40-平台与架构/基础平台/功能模块/README.md

@@ -0,0 +1,19 @@
+# 基础平台功能模块
+
+本目录用于承接《基础平台产品设计》第 5 章的功能模块详细设计。每个功能模块独立成文档，便于研发拆分任务、测试编写用例、产品进行范围控制。
+
+| 编号 | 功能模块 | 文档 |
+| --- | --- | --- |
+| 5.1 | 客户管理 | [01-客户管理.md](./01-客户管理.md) |
+| 5.2 | 应用管理 | [02-应用管理.md](./02-应用管理.md) |
+| 5.3 | 组织管理 | [03-组织管理.md](./03-组织管理.md) |
+| 5.4 | 用户与账号管理 | [04-用户与账号管理.md](./04-用户与账号管理.md) |
+| 5.5 | 单点登录与统一认证鉴权 | [05-单点登录与统一认证鉴权.md](./05-单点登录与统一认证鉴权.md) |
+| 5.6 | 统一门户与应用容器 | [06-统一门户与应用容器.md](./06-统一门户与应用容器.md) |
+| 5.7 | 角色管理 | [07-角色管理.md](./07-角色管理.md) |
+| 5.8 | 权限管理 | [08-权限管理.md](./08-权限管理.md) |
+| 5.9 | 菜单管理 | [09-菜单管理.md](./09-菜单管理.md) |
+| 5.10 | 基础配置管理 | [10-基础配置管理.md](./10-基础配置管理.md) |
+| 5.11 | 消息与待办 | [11-消息与待办.md](./11-消息与待办.md) |
+| 5.12 | 操作日志 | [12-操作日志.md](./12-操作日志.md) |
+| 5.13 | 数据字典 | [13-数据字典.md](./13-数据字典.md) |

40-平台与架构/基础平台/单点登录与统一认证鉴权设计.md

@@ -0,0 +1,239 @@
+# 单点登录与统一认证鉴权设计
+
+## 1. 文档说明
+
+本文档是《基础平台产品设计》的专题补充文档，用于定义基础平台单点登录、统一 Token 认证鉴权、Token 刷新、登录注销、当前登录用户信息获取和 Token 状态同步规则。
+
+本文档阅读对象为研发部门、测试部门、产品部门和实施交付团队。
+
+## 2. 产品定位
+
+单点登录与统一认证鉴权用于支撑用户一次登录基础平台后，访问多个已授权业务应用，并统一完成所有应用的 Token 认证和鉴权。
+
+基础平台作为统一认证中心。所有接入应用不再各自独立维护登录认证逻辑，业务应用需要根据基础平台返回的认证结果和权限结果控制用户访问。
+
+## 3. 功能范围
+
+- 用户统一登录
+- 用户统一退出
+- 登录状态维护
+- Token 签发
+- Token 校验
+- Token 刷新
+- Token 失效
+- 应用访问鉴权
+- 用户身份信息获取
+- 当前登录用户信息获取
+- 用户授权应用列表获取
+- 用户菜单和权限获取
+
+## 4. 业务规则
+
+- 用户登录由基础平台统一完成。
+- 用户登录成功后，可访问已开通且已授权的业务应用。
+- 用户未登录时，不可访问任何业务应用。
+- 用户访问业务应用时，业务应用必须通过基础平台完成 Token 认证鉴权。
+- Token 无效、过期、被注销或用户已停用时，业务应用必须拒绝访问。
+- 用户退出登录后，已登录应用应同步失效或在下一次认证时失效。
+- 客户停用、用户停用、应用停用、客户未开通应用、用户未授权应用时，认证鉴权均不通过。
+- 用户权限变更后，应能在合理时间内影响用户后续访问。
+- 业务应用不得绕过基础平台独立放行用户访问。
+
+## 5. 鉴权判断维度
+
+基础平台认证鉴权至少需要判断：
+
+- Token 是否有效。
+- 用户是否存在且启用。
+- 用户所属客户是否启用。
+- 应用是否存在且启用。
+- 客户是否已开通该应用。
+- 用户是否拥有该应用访问权限。
+- 用户是否拥有对应菜单、操作或数据范围权限。
+
+## 6. 业务系统接入要求
+
+所有接入基础平台的业务系统均需满足：
+
+- 登录入口统一接入基础平台。
+- 用户身份校验统一通过基础平台。
+- Token 认证鉴权统一通过基础平台。
+- 菜单、权限、数据范围以基础平台授权结果为准。
+- 业务系统可保留自身业务权限补充规则，但不得与基础平台授权结果冲突。
+
+## 7. 统一登录流程
+
+统一登录流程用于解决用户登录入口、Token 源头、门户登录态统一问题。用户只登录基础平台门户，不直接登录各业务应用。
+
+流程步骤：
+
+1. 用户访问基础平台登录页。
+2. 用户提交登录账号和登录凭证。
+3. 基础平台校验用户账号、密码或其他登录凭证。
+4. 基础平台校验用户状态、客户状态、默认组织状态。
+5. 校验通过后，基础平台生成门户登录会话并签发 Token。
+6. 基础平台加载当前用户基础信息、默认组织、可访问应用列表、菜单和权限。
+7. 用户进入基础平台统一门户主页面。
+8. 基础平台根据用户权限渲染头部、左侧菜单、Tab 导航栏和右侧内容区。
+9. 用户点击业务应用菜单时，基础平台在右侧内容区通过 iframe 打开业务应用页面。
+10. 基础平台将 Token 访问状态同步给 iframe 应用。
+11. iframe 应用使用基础平台 Token 访问自身业务接口。
+
+流程规则：
+
+- 用户登录必须由基础平台统一完成。
+- 业务应用不得独立生成登录 Token。
+- Token 的签发源头只能是基础平台。
+- 登录成功后，业务应用只能在基础平台门户容器中使用基础平台签发的 Token 进行访问。
+- 用户无任何授权应用时，登录成功后应提示暂无可访问应用。
+- 业务应用不再提供独立登录页作为常规访问入口。
+
+## 8. iframe 应用 Token 交互流程
+
+iframe 应用 Token 交互流程用于解决业务应用嵌入基础平台后，如何获取和使用基础平台统一 Token。
+
+流程步骤：
+
+1. 用户在基础平台左侧菜单点击某业务应用菜单。
+2. 基础平台校验用户是否拥有该应用和菜单访问权限。
+3. 校验通过后，基础平台在右侧内容区创建或激活对应 iframe 页面。
+4. 基础平台向 iframe 应用同步当前 Token 或可用于获取 Token 的访问状态。
+5. iframe 应用接收基础平台 Token 后，向基础平台进行 Token 校验或获取当前登录用户信息。
+6. 基础平台返回 Token 有效性、当前用户信息、当前应用权限和数据范围。
+7. iframe 应用根据基础平台返回结果加载业务页面。
+8. iframe 应用访问自身业务接口时，使用基础平台 Token 作为统一认证凭证。
+
+流程规则：
+
+- 业务应用只接受基础平台签发的 Token。
+- 业务应用不得自行伪造、转换或替代基础平台 Token。
+- iframe 应用不得要求用户再次登录。
+- iframe 应用不得独立维护与基础平台冲突的登录态。
+- iframe 应用每次关键访问均应确认 Token 有效性。
+- 多个 iframe 应用之间不直接互相传递用户身份，以基础平台门户容器和 Token 为统一身份依据。
+- 用户未通过基础平台打开业务应用时，业务应用应拒绝访问或引导到基础平台。
+
+## 9. Token 刷新流程
+
+Token 刷新流程用于解决基础平台门户中多个已打开 iframe 应用的登录状态延续和 Token 过期处理问题。
+
+流程步骤：
+
+1. 用户已登录基础平台门户，并打开一个或多个 iframe 应用。
+2. 基础平台监控当前 Token 有效期。
+3. Token 即将过期时，基础平台发起 Token 刷新。
+4. 基础平台校验原登录会话、用户状态、客户状态和应用授权状态。
+5. 校验通过后，基础平台签发新的 Token。
+6. 基础平台更新门户容器中的当前 Token。
+7. 基础平台向已打开 iframe 应用同步 Token 刷新结果。
+8. iframe 应用使用新 Token 继续访问业务接口。
+9. 旧 Token 按规则失效或在有效期结束后失效。
+
+流程规则：
+
+- Token 刷新必须由基础平台完成。
+- 用户停用、客户停用、应用停用、用户无应用权限时，不允许刷新 Token。
+- Token 刷新后，基础平台负责向已打开 iframe 应用同步新 Token 状态。
+- iframe 应用收到 Token 刷新成功结果后，应使用新 Token 访问。
+- Token 刷新失败时，基础平台应统一引导用户重新登录，并使已打开 iframe 应用访问失效。
+- iframe 应用不主动刷新 Token，只响应基础平台刷新结果。
+
+## 10. 登录注销流程
+
+登录注销流程用于解决用户退出基础平台后，所有已打开 iframe 应用访问状态一致失效问题。
+
+流程步骤：
+
+1. 用户在基础平台头部用户信息区域点击退出登录。
+2. 基础平台确认注销操作。
+3. 基础平台失效当前用户门户登录会话和相关 Token。
+4. 基础平台向所有已打开 iframe 应用同步注销或 Token 失效状态。
+5. 基础平台关闭或失效所有已打开业务应用页面访问状态。
+6. iframe 应用清理本地临时登录状态或停止继续访问业务接口。
+7. 用户再次访问基础平台或业务应用时，需要重新登录基础平台。
+
+流程规则：
+
+- 登录注销由基础平台统一处理。
+- 用户注销后，原 Token 不可继续访问业务应用。
+- 基础平台负责向已打开 iframe 应用同步注销状态。
+- iframe 应用发现 Token 已注销或失效时，不得继续放行访问。
+- 业务应用不提供独立注销逻辑作为常规退出入口；如业务页面存在退出入口，应调用基础平台统一注销能力。
+
+## 11. 当前登录用户信息获取流程
+
+当前登录用户信息获取流程用于解决基础平台门户和 iframe 应用如何获取当前用户、组织、角色和权限信息问题。
+
+流程步骤：
+
+1. 用户登录基础平台后，基础平台加载当前登录用户信息。
+2. iframe 应用打开时，通过基础平台 Token 请求当前登录用户信息。
+3. 基础平台校验 Token 有效性。
+4. 基础平台返回当前用户基础信息。
+5. 基础平台返回用户所属客户、默认组织、组织列表、角色列表。
+6. 基础平台返回当前应用下的菜单、操作权限和数据范围。
+7. iframe 应用根据返回结果加载业务页面和控制操作。
+
+当前用户信息至少包括：
+
+- 用户 ID
+- 用户姓名
+- 登录账号
+- 手机号
+- 所属客户
+- 默认组织
+- 可选组织列表
+- 角色列表
+- 可访问应用列表
+- 当前应用菜单
+- 当前应用操作权限
+- 当前应用数据范围
+
+流程规则：
+
+- 当前登录用户信息必须以基础平台为准。
+- 业务应用不得自行维护独立用户主档。
+- 业务应用可缓存用户信息，但缓存失效和刷新规则需服从基础平台授权结果。
+- 用户角色、组织、权限变更后，业务应用应能在合理时间内获取最新结果。
+- iframe 应用仅获取当前应用所需的用户、权限和数据范围信息。
+
+## 12. Token 信息交互同步规则
+
+Token 信息交互同步用于规范基础平台门户容器与各 iframe 应用之间的 Token 使用关系。
+
+同步规则：
+
+- 基础平台是 Token 唯一签发方。
+- 基础平台是 Token 唯一认证鉴权方。
+- 基础平台门户容器是 Token 持有方和同步方。
+- iframe 应用是 Token 使用方。
+- iframe 应用需要识别 Token 有效、无效、过期、刷新、注销、无权限等状态。
+- iframe 应用需要根据基础平台认证结果决定是否允许访问。
+- iframe 应用需要根据基础平台返回的用户、组织、角色、权限结果进行页面和数据控制。
+- 用户在基础平台注销后，所有 iframe 应用再次访问时必须感知 Token 已失效。
+- 用户权限变更后，iframe 应用应在下次鉴权、Token 状态同步或重新获取用户信息时同步变化。
+- 已打开 iframe 应用的 Token 状态由基础平台门户容器统一管理。
+
+异常处理规则：
+
+- Token 不存在：基础平台门户引导用户登录。
+- Token 无效：基础平台门户拒绝访问并引导重新登录。
+- Token 过期且可刷新：基础平台门户统一刷新 Token，并同步给 iframe 应用。
+- Token 过期且不可刷新：基础平台门户引导重新登录，并使已打开 iframe 应用访问失效。
+- 用户无应用权限：提示无权限访问。
+- 用户无菜单权限：不展示对应菜单。
+- 用户无操作权限：不展示或禁用对应操作。
+
+## 13. 验收标准
+
+- 用户一次登录后，可访问多个已授权应用。
+- 未授权应用不可访问。
+- Token 无效或过期时，业务应用拒绝访问。
+- 用户停用、客户停用、应用停用后，业务应用拒绝访问。
+- 用户退出后，再访问业务应用需要重新登录。
+- 各业务应用均通过基础平台完成 Token 认证鉴权。
+- Token 即将过期或已过期但允许刷新时，由基础平台门户统一刷新 Token。
+- Token 刷新成功后，已打开 iframe 应用使用新 Token 继续访问。
+- Token 刷新失败后，基础平台门户引导用户重新登录。
+- 用户注销后，所有已打开 iframe 应用访问状态失效。
+- 当前用户信息获取结果包含用户、客户、默认组织、组织列表、角色、可访问应用、菜单、操作权限和数据范围。

40-平台与架构/基础平台/基础平台产品设计.md

@@ -0,0 +1,464 @@
+# 基础平台产品设计
+
+## 1. 文档说明
+
+### 1.1 文档目的
+
+本文档用于定义基础平台的产品设计和业务需求，作为研发部门进行基础平台研发、测试部门进行测试验收的依据。
+
+本文档重点描述基础平台需要支撑的业务对象、功能范围、业务规则、产品边界和验收标准，不描述具体技术实现方案。
+
+### 1.2 阅读对象
+
+- 研发部门：根据本文档理解基础平台的业务范围、功能模块、数据对象、业务规则和系统边界。
+- 测试部门：根据本文档设计测试用例、验证功能完整性、业务规则正确性和跨模块协同结果。
+- 产品部门：根据本文档进行需求澄清、范围控制、版本验收和后续迭代管理。
+- 实施与交付团队：根据本文档理解基础平台能力边界和客户初始化配置方式。
+
+### 1.3 建设背景
+
+公司当前产品战略要求同时支撑纵向产品和横向产品：
+
+- 纵向产品：营帐通拆分、连锁业务对账系统、分账系统、聚合支付系统、物流撮合行业分账试点。
+- 横向产品：门店选址规划系统、连锁门店客服系统，以及后续餐饮连锁行业产品线。
+
+为避免各业务系统重复建设组织、账号、权限、菜单、配置、消息、流程等通用能力，需要建设统一基础平台，作为后续多产品、多客户、多组织、多门店复用的底座。
+
+### 1.4 版本范围
+
+本文档定义基础平台 1.0 范围。
+
+1.0 重点支撑：
+
+- 多客户管理
+- 组织管理
+- 用户与账号管理
+- 单点登录服务
+- 统一 Token 认证鉴权
+- 统一门户与菜单聚合
+- 应用 iframe 容器
+- 角色与权限管理
+- 菜单与应用入口管理
+- 基础配置管理
+- 操作日志
+- 消息与待办基础能力
+- 基础数据字典
+- 业务系统接入管理
+
+1.0 不展开：
+
+- 复杂工作流引擎
+- 复杂主数据治理平台
+- 数据中台
+- 统一报表平台
+- 复杂低代码配置平台
+- 复杂开放平台能力
+
+## 2. 产品定位
+
+### 2.1 基础平台定位
+
+基础平台是公司各业务产品的统一底座，为连锁业务对账系统、分账系统、聚合支付系统、门店选址规划系统、门店大数据平台、连锁门店客服系统等产品提供通用管理能力。
+
+基础平台不直接承载具体业务交易，不负责对账、分账、支付、客服、选址等具体业务逻辑。基础平台负责统一管理业务系统运行所需的基础对象和通用能力。
+
+### 2.2 核心价值
+
+- 统一客户、组织、用户、角色、权限、菜单等基础能力。
+- 支撑多产品复用，避免每个业务系统重复建设基础模块。
+- 支撑多客户、多品牌、多门店、多业务系统的统一管理。
+- 为后续分账系统 SaaS 化、聚合支付接入、客户项目交付提供基础能力。
+- 为研发技术架构调整提供清晰的业务边界和模块边界。
+
+### 2.3 产品边界
+
+基础平台负责：
+
+- 客户管理
+- 组织管理
+- 用户账号管理
+- 单点登录服务
+- 统一 Token 认证鉴权
+- 统一门户与菜单聚合
+- 应用 iframe 容器
+- 角色权限管理
+- 菜单与应用入口管理
+- 基础配置管理
+- 消息与待办基础能力
+- 操作日志
+- 数据字典
+- 业务系统接入管理
+
+基础平台不负责：
+
+- 对账业务规则
+- 分账业务规则
+- 聚合支付业务规则
+- 客服工单业务规则
+- 选址评分模型
+- 经营分析指标计算
+- 具体客户项目的业务审批细节
+
+## 3. 用户与使用场景
+
+### 3.1 主要用户角色
+
+| 角色 | 使用场景 |
+| --- | --- |
+| 平台超级管理员 | 管理客户、系统应用、全局配置、平台级账号 |
+| 客户管理员 | 管理本客户下组织、用户、角色、权限、菜单 |
+| 产品管理员 | 管理某个业务产品的菜单、权限项、接入配置 |
+| 实施人员 | 初始化客户组织、账号、权限、配置 |
+| 客服 / 运维人员 | 查询账号、权限、日志、消息状态，协助排查问题 |
+| 业务系统用户 | 通过基础平台获得账号、权限、菜单、消息和待办 |
+
+### 3.2 典型使用场景
+
+#### 3.2.1 新客户初始化
+
+实施人员为新客户创建客户档案，配置客户基本信息，初始化组织架构、管理员账号、基础角色和可用应用。
+
+#### 3.2.2 新产品接入
+
+产品管理员将新业务系统注册到基础平台，配置应用入口、菜单、权限项和可授权范围。
+
+#### 3.2.3 客户开通业务产品
+
+平台管理员为客户开通连锁业务对账系统、分账系统、聚合支付等业务产品，客户管理员再给本客户内部用户分配权限。
+
+#### 3.2.4 用户登录与权限控制
+
+用户登录后，根据所属客户、组织、角色和权限，看到对应业务系统入口和菜单，并只能操作授权范围内的数据。
+
+#### 3.2.5 账号和权限问题排查
+
+客服或运维人员可查询用户所属组织、角色、权限、菜单、登录状态和操作日志，用于定位用户无法访问或权限异常问题。
+
+## 4. 核心业务对象
+
+### 4.1 对象清单
+
+| 对象 | 定义 | 说明 |
+| --- | --- | --- |
+| 客户 | 使用公司产品的企业或平台客户 | 例如餐饮连锁客户、鞋服连锁客户、物流撮合平台客户 |
+| 应用 | 接入基础平台的业务系统 | 例如连锁业务对账系统、分账系统、聚合支付 |
+| 组织 | 客户内部管理结构 | 例如总部、品牌、区域、门店、部门 |
+| 用户 | 使用系统的自然人 | 可属于一个或多个组织 |
+| 账号 | 用户登录系统的身份标识 | 与用户关联 |
+| 登录会话 | 用户登录后形成的访问状态 | 用于支撑跨应用访问 |
+| Token | 用户访问应用和接口的认证凭证 | 由基础平台统一签发和校验 |
+| 门户框架 | 基础平台统一页面框架 | 包含头部、左侧菜单、Tab、内容区 |
+| 应用入口 | 业务应用在基础平台中的访问入口 | 可指向基础平台页面或 iframe 应用页面 |
+| 已打开页签 | 用户在门户中打开的页面 Tab | 可关联基础平台页面或业务应用页面 |
+| iframe 容器 | 基础平台承载业务应用页面的容器 | 用于嵌入业务应用界面 |
+| 角色 | 权限集合 | 例如客户管理员、财务主管、门店店长 |
+| 权限项 | 系统可控制的功能或操作 | 例如查看、创建、修改、审核、导出 |
+| 菜单 | 用户可见的系统导航入口 | 与应用和权限关联 |
+| 数据范围 | 用户可查看或操作的数据边界 | 例如全部、指定组织、指定门店 |
+| 配置项 | 可被客户或系统配置的参数 | 例如启用状态、业务开关 |
+| 消息 | 系统向用户发送的通知 | 可包含待办、通知、提醒 |
+| 操作日志 | 用户在系统中的关键操作记录 | 用于审计和排查 |
+
+### 4.2 对象关系
+
+- 一个客户可开通多个应用。
+- 一个客户下可建立多级组织。
+- 一个用户归属于一个客户。
+- 一个用户可关联多个组织，但必须有一个默认组织。
+- 一个用户可拥有多个角色。
+- 一个用户登录基础平台后，可在已授权应用之间进行单点访问。
+- 各业务应用访问时，Token 认证鉴权统一由基础平台完成。
+- 基础平台统一聚合所有应用菜单。
+- 业务应用不再独立渲染系统级菜单。
+- 业务应用页面通过 iframe 方式嵌入基础平台内容区。
+- 一个角色可包含多个权限项。
+- 一个权限项归属于一个应用。
+- 一个菜单归属于一个应用，并可绑定权限项。
+- 一个用户最终可访问的菜单和功能，由客户开通应用、用户角色、权限项和数据范围共同决定。
+
+## 5. 功能模块设计
+
+基础平台功能模块详细设计已拆分至独立文档，便于研发、测试和产品分别按模块评审、开发和验收。
+
+功能模块目录：[功能模块](./功能模块/README.md)
+
+| 编号 | 功能模块 | 独立文档 |
+| --- | --- | --- |
+| 5.1 | 客户管理 | [01-客户管理.md](./功能模块/01-客户管理.md) |
+| 5.2 | 应用管理 | [02-应用管理.md](./功能模块/02-应用管理.md) |
+| 5.3 | 组织管理 | [03-组织管理.md](./功能模块/03-组织管理.md) |
+| 5.4 | 用户与账号管理 | [04-用户与账号管理.md](./功能模块/04-用户与账号管理.md) |
+| 5.5 | 单点登录与统一认证鉴权 | [05-单点登录与统一认证鉴权.md](./功能模块/05-单点登录与统一认证鉴权.md) |
+| 5.6 | 统一门户与应用容器 | [06-统一门户与应用容器.md](./功能模块/06-统一门户与应用容器.md) |
+| 5.7 | 角色管理 | [07-角色管理.md](./功能模块/07-角色管理.md) |
+| 5.8 | 权限管理 | [08-权限管理.md](./功能模块/08-权限管理.md) |
+| 5.9 | 菜单管理 | [09-菜单管理.md](./功能模块/09-菜单管理.md) |
+| 5.10 | 基础配置管理 | [10-基础配置管理.md](./功能模块/10-基础配置管理.md) |
+| 5.11 | 消息与待办 | [11-消息与待办.md](./功能模块/11-消息与待办.md) |
+| 5.12 | 操作日志 | [12-操作日志.md](./功能模块/12-操作日志.md) |
+| 5.13 | 数据字典 | [13-数据字典.md](./功能模块/13-数据字典.md) |
+
+## 6. 跨模块业务规则
+
+### 6.1 多客户隔离
+
+- 所有客户数据必须隔离。
+- 用户只能访问所属客户数据。
+- 平台管理员可管理多个客户。
+- 客户管理员只能管理本客户。
+
+### 6.2 应用开通与访问
+
+- 客户未开通应用时，该客户用户不可访问应用。
+- 应用停用时，所有客户均不可访问。
+- 用户是否能访问应用，由客户开通状态和用户角色共同决定。
+
+### 6.3 权限生效顺序
+
+用户最终权限由以下条件共同决定：
+
+1. 客户是否启用。
+2. 用户是否启用。
+3. 应用是否启用。
+4. 客户是否开通应用。
+5. Token 是否有效。
+6. 用户是否拥有对应角色。
+7. 角色是否包含对应权限。
+8. 数据范围是否覆盖目标数据。
+
+任一条件不满足，用户不可访问对应功能或数据。
+
+### 6.4 历史数据处理
+
+- 客户、组织、用户、角色停用后，不删除历史数据。
+- 历史操作日志保留。
+- 历史业务数据归属不因组织调整自动变化。
+
+## 7. 与业务系统关系
+
+### 7.1 与营帐通现状关系
+
+营帐通作为现有产品和客户项目现状，不作为基础平台 1.0 的新接入应用。
+
+营帐通拆分后的目标产品为连锁业务对账系统和分账系统。基础平台 1.0 面向拆分后的连锁业务对账系统、分账系统提供客户、组织、用户、角色、菜单、权限、日志等能力。
+
+营帐通现有业务能力、现状问题和迁移策略不在基础平台中处理，应在营帐通现状文档、连锁业务对账系统规划文档和分账系统规划文档中分别承接。
+
+### 7.2 与连锁业务对账系统关系
+
+基础平台提供用户、权限、组织、菜单、配置等能力。
+
+连锁业务对账系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
+
+连锁业务对账系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
+
+连锁业务对账系统负责对账任务、账单、流水、差异、报表等业务能力。
+
+### 7.3 与分账系统关系
+
+基础平台提供用户、权限、组织、菜单、配置等能力。
+
+分账系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
+
+分账系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
+
+分账系统负责结算主体、账户体系、分账规则、清分、分账、退款、出款等业务能力。
+
+### 7.4 与聚合支付关系
+
+基础平台提供用户、权限、应用入口、配置等能力。
+
+聚合支付系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
+
+聚合支付系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
+
+聚合支付系统负责支付渠道、支付订单、支付流水、退款、支付状态、支付通知等业务能力。
+
+### 7.5 与客服系统关系
+
+基础平台提供用户、组织、角色、权限、菜单、消息等能力。
+
+客服系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
+
+客服系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
+
+客服系统负责客诉、咨询、工单、补偿、回访、责任归属等业务能力。
+
+## 8. 测试验收要求
+
+### 8.1 测试范围
+
+测试部门需重点覆盖：
+
+- 客户隔离
+- 组织管理
+- 用户账号管理
+- 单点登录
+- Token 认证鉴权
+- 统一门户布局
+- 菜单聚合
+- iframe 应用嵌入
+- Tab 与 keepalive
+- Token 共享与有效期管理
+- 角色权限管理
+- 菜单展示控制
+- 应用开通控制
+- 数据范围控制
+- 配置项维护
+- 消息与待办
+- 操作日志
+- 停用规则
+- 多角色权限合并
+
+### 8.2 核心测试场景
+
+#### 8.2.1 客户隔离测试
+
+- A 客户用户不能看到 B 客户组织、用户、角色、菜单、日志。
+- A 客户停用后，A 客户用户不可登录。
+- B 客户不受 A 客户停用影响。
+
+#### 8.2.2 应用开通测试
+
+- 未开通应用的客户不可见应用入口。
+- 开通应用后，客户管理员可为用户授权。
+- 应用停用后，所有客户均不可访问该应用。
+
+#### 8.2.3 角色权限测试
+
+- 用户分配角色后可访问对应菜单和操作。
+- 移除角色后权限失效。
+- 多角色用户权限为授权能力组合。
+- 无权限用户不可通过直接访问地址绕过权限。
+
+#### 8.2.4 单点登录与 Token 认证鉴权测试
+
+- 用户登录基础平台后，可进入已授权业务应用。
+- 用户未登录时，不可访问基础平台门户和业务应用。
+- 用户访问未授权应用时，被拒绝访问。
+- 用户访问业务应用入口时，统一进入基础平台门户登录和访问流程。
+- Token 无效时，业务应用拒绝访问。
+- Token 过期时，业务应用拒绝访问。
+- Token 即将过期或已过期但允许刷新时，由基础平台门户统一刷新 Token。
+- Token 刷新成功后，已打开 iframe 应用使用新 Token 继续访问。
+- Token 刷新失败后，基础平台门户引导用户重新登录。
+- 用户退出登录后，原访问状态失效。
+- 用户在基础平台注销后，再访问其他应用时需要重新认证。
+- 用户停用后，业务应用认证鉴权不通过。
+- 客户停用后，该客户下用户认证鉴权不通过。
+- 应用停用后，所有用户不可访问该应用。
+- 所有接入应用均通过基础平台完成 Token 认证鉴权。
+
+#### 8.2.5 当前登录用户信息测试
+
+- 业务应用可通过基础平台 Token 获取当前登录用户信息。
+- 当前用户信息包含用户、客户、默认组织、组织列表、角色、可访问应用、菜单、操作权限和数据范围。
+- 用户切换组织后，业务应用获取到的当前组织和数据范围正确。
+- 用户权限变更后，业务应用重新获取用户信息时权限结果正确。
+- Token 无效时，不可获取当前用户信息。
+
+#### 8.2.6 统一门户与 iframe 应用容器测试
+
+- 基础平台主页面包含头部、左侧菜单导航栏和右侧内容区。
+- 头部第一部分展示应用 logo、平台名称、菜单折叠按钮、常用菜单、主题设置、消息按钮、语言切换按钮、用户信息。
+- 头部第二部分展示已打开页面 Tab 导航栏。
+- 左侧菜单展示用户有权限访问的所有应用菜单。
+- 用户无权限应用不展示菜单。
+- 用户无权限菜单不展示。
+- 点击基础平台菜单后，在右侧内容区打开基础平台页面。
+- 点击业务应用菜单后，在右侧内容区通过 iframe 打开业务应用页面。
+- 业务应用页面不展示自身系统级菜单。
+- 打开页面后生成对应 Tab。
+- 切换 Tab 时已打开页面状态保持。
+- 关闭 Tab 后对应页面状态释放。
+- 刷新当前 Tab 时仅刷新当前页面。
+- 多个已打开 iframe 应用共享基础平台登录态。
+- Token 刷新后，已打开 iframe 应用可继续访问。
+- Token 失效或用户注销后，已打开 iframe 应用不可继续访问。
+
+#### 8.2.7 数据范围测试
+
+- 本组织用户只能访问本组织数据。
+- 本组织及下级组织用户可访问本组织和下级组织数据。
+- 指定组织权限按指定范围生效。
+- 不同客户之间数据不可跨越。
+
+#### 8.2.8 停用规则测试
+
+- 停用客户后，客户下用户不可登录。
+- 停用组织后，不可继续分配给新用户。
+- 停用用户后，用户不可登录。
+- 停用角色后，不可继续分配。
+- 停用菜单后，用户不可见。
+
+#### 8.2.9 日志测试
+
+- 新增、修改、删除、启用、停用、授权、配置变更等关键操作生成日志。
+- 日志记录操作人、时间、对象、结果。
+- 日志按客户隔离。
+
+## 9. 验收清单
+
+| 模块 | 验收项 | 是否必须 |
+| --- | --- | --- |
+| 客户管理 | 支持客户新增、编辑、停用、应用开通 | 是 |
+| 应用管理 | 支持应用、入口、菜单、权限项维护 | 是 |
+| 组织管理 | 支持多级组织树和组织停用 | 是 |
+| 用户管理 | 支持用户、账号、组织、角色维护 | 是 |
+| 单点登录 | 支持一次登录访问多个已授权应用 | 是 |
+| Token 认证鉴权 | 所有应用 Token 认证鉴权均通过基础平台完成 | 是 |
+| Token 刷新 | 支持基础平台门户统一刷新 Token 并同步给已打开 iframe 应用 | 是 |
+| 登录注销 | 用户注销后原 Token 不可继续访问应用 | 是 |
+| 当前用户信息 | 支持业务应用通过 Token 获取当前登录用户信息 | 是 |
+| 统一门户 | 支持头部、左侧菜单、Tab、右侧内容区布局 | 是 |
+| 菜单聚合 | 支持聚合展示所有授权应用菜单 | 是 |
+| iframe 应用容器 | 支持业务应用 iframe 嵌入基础平台内容区 | 是 |
+| Tab 与 keepalive | 支持已打开页面 Tab 管理和状态保持 | 是 |
+| Token 共享 | 支持已打开 iframe 应用共享基础平台 Token | 是 |
+| 角色管理 | 支持角色授权和数据范围配置 | 是 |
+| 权限管理 | 支持应用、菜单、操作、数据范围控制 | 是 |
+| 菜单管理 | 支持菜单层级、排序、启停和权限绑定 | 是 |
+| 配置管理 | 支持平台、客户、应用配置 | 是 |
+| 消息待办 | 支持消息查询、已读未读、待办跳转 | 是 |
+| 操作日志 | 支持关键操作记录和查询 | 是 |
+| 多客户隔离 | 客户数据不可互相访问 | 是 |
+| 停用规则 | 客户、组织、用户、角色、菜单停用规则正确 | 是 |
+
+## 10. 后续迭代方向
+
+基础平台 1.0 完成后，后续可按业务需要迭代：
+
+- 更完整的流程审批能力
+- 更完整的主数据管理能力
+- 更细的数据权限模型
+- 外部客户自助开通能力
+- 开放平台和第三方接入能力
+- 统一通知中心
+- 更完整的审计与风控能力
+- 统一首页和工作台
+- 外部协同单点登录接入
+
+上述能力不纳入 1.0 必须范围。
+
+## 11. 2.0 版本规划补充
+
+### 11.1 外部协同单点登录接入
+
+基础平台 2.0 需要支持外部协同场景下的单点登录接入，使外部合作方、客户已有系统或第三方协同平台能够按规则接入基础平台认证体系。
+
+2.0 重点支持：
+
+- 外部系统单点登录接入
+- 外部协同用户身份识别
+- 外部用户与内部客户、组织、角色的映射关系
+- 外部协同应用访问授权
+- 外部协同登录状态管理
+- 外部接入审计与日志
+
+2.0 业务目标：
+
+- 支持客户已有系统与公司业务系统之间的协同登录。
+- 支持外部合作方访问被授权的业务应用。
+- 保证外部协同用户访问仍受基础平台客户、组织、角色、权限、数据范围控制。
+
+2.0 不在基础平台 1.0 范围内，研发和测试在 1.0 阶段只需预留产品边界认知，不作为 1.0 验收项。

40-平台与架构/基础平台/统一门户与应用容器设计.md

@@ -0,0 +1,152 @@
+# 统一门户与应用容器设计
+
+## 1. 文档说明
+
+本文档是《基础平台产品设计》的专题补充文档，用于定义基础平台统一门户、菜单聚合、Tab 导航、右侧内容区、iframe 应用容器、keepalive、Token 共享与业务应用改造要求。
+
+本文档阅读对象为研发部门、测试部门、产品部门和实施交付团队。
+
+## 2. 产品定位
+
+统一门户与应用容器用于承载基础平台页面和各业务应用页面。基础平台负责所有业务系统的菜单聚合、业务链接入口、页面框架、Tab 管理、iframe 嵌入和 Token 有效期管理。
+
+业务应用不再独立渲染系统级菜单。业务应用只负责提供自身业务页面，由基础平台通过 iframe 嵌入到右侧内容区。
+
+## 3. 页面总体布局
+
+基础平台主页面由三部分组成：
+
+- 头部区域
+- 左侧菜单导航栏
+- 右侧内容区
+
+右侧内容区用于展示基础平台自身页面和各业务应用 iframe 页面。
+
+## 4. 头部区域
+
+头部区域分为上下两部分。
+
+第一部分为全局操作区，包含：
+
+- 应用 logo
+- 平台名称
+- 左侧菜单折叠按钮
+- 常用菜单
+- 主题设置
+- 消息按钮
+- 语言切换按钮
+- 用户信息
+
+第二部分为已打开页面的 Tab 导航栏，包含：
+
+- 已打开页面 Tab
+- 当前激活页面状态
+- 关闭单个 Tab
+- 关闭其他 Tab
+- 关闭全部可关闭 Tab
+- 刷新当前 Tab
+
+## 5. 左侧菜单导航栏
+
+左侧菜单导航栏展示当前用户有权限访问的所有菜单。
+
+菜单来源：
+
+- 基础平台菜单
+- 连锁业务对账系统菜单
+- 分账系统菜单
+- 聚合支付菜单
+- 门店选址规划系统菜单
+- 连锁门店客服系统菜单
+- 后续接入应用菜单
+
+菜单展示规则：
+
+- 用户无权限的应用不展示。
+- 用户无权限的菜单不展示。
+- 客户未开通的应用菜单不展示。
+- 应用停用后，该应用菜单不展示。
+- 菜单支持多级展示。
+- 菜单支持折叠和展开。
+- 菜单点击后，在右侧内容区打开对应页面。
+
+## 6. 右侧内容区
+
+右侧内容区用于展示：
+
+- 基础平台自身业务页面
+- 业务应用 iframe 页面
+
+展示规则：
+
+- 点击基础平台菜单时，在内容区打开基础平台页面。
+- 点击业务应用菜单时，在内容区以 iframe 方式打开业务应用页面。
+- 已打开页面在 Tab 导航栏中生成对应 Tab。
+- 切换 Tab 时，内容区切换到对应页面。
+- 关闭 Tab 时，关闭对应页面容器。
+
+## 7. iframe 应用嵌入规则
+
+业务应用采用 iframe 方式嵌入基础平台。
+
+嵌入规则：
+
+- iframe 页面地址由基础平台菜单或应用入口配置提供。
+- iframe 打开前，基础平台需要确认当前用户对该应用和菜单有访问权限。
+- iframe 打开时，需要让业务应用获得基础平台 Token。
+- 业务应用使用基础平台 Token 完成自身业务接口访问鉴权。
+- iframe 页面不展示业务应用自身系统级菜单。
+- iframe 页面应适配基础平台内容区展示。
+
+## 8. Tab 与 keepalive 规则
+
+基础平台需要对已打开应用页面进行 keepalive 管理。
+
+规则包括：
+
+- 已打开 Tab 可保持页面状态。
+- 用户在 Tab 之间切换时，已打开页面不应重复初始化，除非用户主动刷新。
+- 用户关闭 Tab 后，对应页面状态释放。
+- 用户刷新当前 Tab 时，仅刷新当前页面。
+- 基础平台应管理已打开 iframe 应用页面的生命周期。
+- keepalive 范围应可控，避免无限制保留页面导致性能问题。
+
+## 9. Token 共享与有效期管理
+
+基础平台负责对已打开应用系统进行 Token 有效期管理和 Token 共享。
+
+规则包括：
+
+- 基础平台持有并管理当前登录用户的 Token。
+- iframe 应用页面使用基础平台 Token。
+- 已打开的多个 iframe 应用共享同一基础平台登录态。
+- Token 刷新由基础平台统一处理。
+- iframe 应用不主动刷新 Token，只响应基础平台门户容器同步的 Token 状态。
+- Token 刷新成功后，已打开应用应能使用新 Token 继续访问。
+- Token 失效或注销后，已打开应用再次访问时应被拒绝，并引导回基础平台登录。
+- 用户注销后，基础平台关闭或失效所有已打开应用访问状态。
+- 基础平台需要向已打开应用同步 Token 有效、刷新、失效、注销等状态。
+
+## 10. 业务应用改造要求
+
+接入基础平台的业务应用需要满足：
+
+- 不再独立渲染系统级菜单。
+- 支持被基础平台 iframe 嵌入。
+- 支持接收或获取基础平台 Token。
+- 所有业务接口访问均使用基础平台 Token。
+- 支持 Token 刷新后的访问延续。
+- 支持 Token 失效后的访问拒绝。
+- 页面布局适配基础平台内容区。
+
+## 11. 验收标准
+
+- 基础平台可聚合展示用户有权限访问的所有应用菜单。
+- 业务应用不再独立展示系统级菜单。
+- 点击业务应用菜单后，可在右侧内容区通过 iframe 打开应用页面。
+- 打开的页面可生成 Tab。
+- Tab 切换时页面状态可保持。
+- 关闭 Tab 后页面状态释放。
+- iframe 应用可使用基础平台 Token 访问业务接口。
+- Token 刷新后，已打开 iframe 应用可继续访问。
+- 用户注销后，已打开 iframe 应用不可继续访问。

50-方法论与模板/README.md

@@ -0,0 +1,3 @@
+# 方法论与模板
+
+本目录用于沉淀产品规划模板、需求调研模板、客户访谈模板、行业方案模板、PRD 模板、复盘模板等。

90-归档/README.md

@@ -0,0 +1,3 @@
+# 归档
+
+本目录用于存放过期方案、历史版本、已废弃规划和归档材料。

README.md

@@ -0,0 +1,48 @@
+# 连锁经营与餐饮行业产品规划
+
+本项目用于沉淀公司产品战略、连锁经营对账分账系统规划、餐饮连锁行业信息化解决方案和软件产品规划文档，重点覆盖产品战略、业务流程、系统功能、产品边界、系统边界、数据治理、产品线规划和分阶段建设路线。
+
+## 角色定位
+
+当前规划视角为：为连锁经营企业、餐饮连锁企业和平台型交易业务提供信息化解决方案及软件产品的产品总监和产品规划负责人。
+
+核心职责：
+
+- 为连锁经营企业和餐饮连锁企业提供行业信息化解决方案。
+- 不断完善和升级现有产品和方案。
+- 围绕对账分账垂直赛道和餐饮连锁行业横向场景持续拓展产品线。
+
+当前已有业务产品：
+
+- 连锁企业门店对账分账系统：营帐通
+- 门店选址规划系统
+- 门店大数据平台
+
+## 公司产品战略
+
+- 纵向发展：围绕连锁门店对账与分账系统深耕，将营帐通拆分为连锁业务对账系统和分账系统，并拓展到连锁鞋服、连锁零售、连锁药店等业态。
+- 平台化发展：将分账系统升级为 SaaS 平台，适配物流撮合平台、充电桩运营平台等互联网平台业务和担保交易场景。
+- 横向发展：围绕连锁餐饮行业，逐步建设收银系统、客服系统、门店生命周期系统、商品管理等系统平台。
+
+## 年度优先级
+
+- 第一优先级：推进纵向产品，包括营帐通拆分与完善、连锁业务对账系统、分账系统、聚合支付、物流撮合行业分账试点、存量客户营帐通升级。
+- 第二优先级：推进横向拓展，包括门店选址规划系统集成、连锁门店客服系统开发及试点。
+
+## 当前文档
+
+- [知识库目录](知识库目录.md)
+- [公司产品战略目标](00-公司战略/00-公司产品战略目标.md)
+- [产品规划负责人角色与产品线定位](01-角色与治理/00-产品规划负责人角色与产品线定位.md)
+- [2026 年产品工作计划](02-年度计划/2026年产品工作计划.md)
+- [2026 年详细执行计划](02-年度计划/2026年详细执行计划.md)
+- [典型客户背景与解决方案规划前提](20-行业解决方案/餐饮连锁/00-典型客户背景与解决方案规划前提.md)
+- [餐饮连锁行业数字化解决方案规划目录](20-行业解决方案/餐饮连锁/01-餐饮连锁行业数字化解决方案规划目录.md)
+
+## 规划原则
+
+- 纵向产品优先，横向拓展跟进。
+- 产品边界先行，功能建设跟进。
+- 先服务明确客户和试点场景，再沉淀标准产品能力。
+- 统一平台支撑多产品、多客户、多行业复用。
+- 采用整体规划、分步建设、逐步替代的建设策略。

知识库目录.md

@@ -0,0 +1,142 @@
+# 公司核心知识库目录
+
+本文档用于说明公司核心知识库的目录结构。后续产品战略、产品规划、行业方案、客户项目、基础平台、技术架构、方法模板等文档均按本结构沉淀。
+
+## 目录结构
+
+```text
+.
+├── 00-公司战略
+├── 01-角色与治理
+├── 02-年度计划
+├── 10-产品线
+│   ├── 营帐通
+│   ├── 连锁业务对账系统
+│   ├── 分账系统
+│   ├── 聚合支付
+│   ├── 门店选址规划系统
+│   ├── 门店大数据平台
+│   └── 连锁门店客服系统
+├── 20-行业解决方案
+│   ├── 餐饮连锁
+│   ├── 连锁鞋服
+│   ├── 连锁零售
+│   ├── 连锁药店
+│   └── 物流撮合
+├── 30-客户与试点项目
+│   ├── 万店餐饮连锁客户
+│   ├── 鞋服连锁客户
+│   └── 物流撮合试点
+├── 40-平台与架构
+│   ├── 基础平台
+│   └── 技术架构调整
+├── 50-方法论与模板
+└── 90-归档
+```
+
+## 一级目录说明
+
+### 00-公司战略
+
+沉淀公司级产品战略、业务战略、年度优先级、产品组合方向等文档。
+
+当前文档：
+
+- [公司产品战略目标](00-公司战略/00-公司产品战略目标.md)
+
+### 01-角色与治理
+
+沉淀产品负责人职责、产品治理机制、产品评审机制、需求管理机制、产品边界治理规则等文档。
+
+当前文档：
+
+- [产品规划负责人角色与产品线定位](01-角色与治理/00-产品规划负责人角色与产品线定位.md)
+
+### 02-年度计划
+
+沉淀年度产品工作计划、季度计划、年度复盘、下一年度路线图等文档。
+
+当前文档：
+
+- [2026 年产品工作计划](02-年度计划/2026年产品工作计划.md)
+- [2026 年详细执行计划](02-年度计划/2026年详细执行计划.md)
+
+### 10-产品线
+
+沉淀各产品线的产品定位、产品规划、能力清单、业务流程、产品边界、版本规划和 PRD。
+
+其中，`营帐通` 目录仅用于整理营帐通现状；拆分后的规划内容分别放入 `连锁业务对账系统`、`分账系统`、`聚合支付` 等目录。
+
+重点产品线包括：
+
+- 营帐通：现状整理
+- 连锁业务对账系统
+- 分账系统
+- 聚合支付
+- 门店选址规划系统
+- 门店大数据平台
+- 连锁门店客服系统
+
+### 20-行业解决方案
+
+沉淀面向不同行业的解决方案、行业业务模型、行业差异化需求、行业售前材料和标准方案。
+
+当前重点行业包括：
+
+- 餐饮连锁
+- 连锁鞋服
+- 连锁零售
+- 连锁药店
+- 物流撮合
+
+当前文档：
+
+- [典型客户背景与解决方案规划前提](20-行业解决方案/餐饮连锁/00-典型客户背景与解决方案规划前提.md)
+- [餐饮连锁行业数字化解决方案规划目录](20-行业解决方案/餐饮连锁/01-餐饮连锁行业数字化解决方案规划目录.md)
+
+### 30-客户与试点项目
+
+沉淀客户升级项目、试点项目、客户访谈、项目复盘、需求差异和产品能力沉淀。
+
+当前重点项目包括：
+
+- 万店餐饮连锁客户营帐通升级
+- 鞋服连锁客户营帐通升级
+- 物流撮合行业分账试点
+
+### 40-平台与架构
+
+沉淀基础平台、技术架构调整、产品模块拆分、系统边界、平台能力清单等文档。
+
+当前重点方向包括：
+
+- 基础平台建设
+- 技术架构调整协同
+
+当前文档：
+
+- [基础平台产品设计](40-平台与架构/基础平台/基础平台产品设计.md)
+
+### 50-方法论与模板
+
+沉淀产品规划模板、需求调研模板、客户访谈模板、行业方案模板、PRD 模板、复盘模板等。
+
+### 90-归档
+
+存放过期方案、历史版本、已废弃规划和归档材料。
+
+## 文档命名建议
+
+- 公司级文档：`00-文档名称.md`
+- 产品规划文档：`产品名称-产品规划.md`
+- 版本需求文档：`产品名称-版本号-需求说明.md`
+- 行业方案文档：`行业名称-解决方案.md`
+- 客户项目文档：`客户名称-项目名称-方案.md`
+- 复盘文档：`项目名称-复盘报告.md`
+
+## 使用原则
+
+- 先放到正确业务目录，再补充文档内容。
+- 产品线文档优先沉淀产品边界、核心流程、能力清单和版本路线。
+- 行业方案文档优先沉淀行业业务模型、典型场景、差异化需求和标准方案。
+- 客户项目文档必须沉淀可复用能力，避免只记录一次性项目过程。