diff --git a/10-产品线/连锁业务对账系统/01-产品定位与业务闭环.md b/10-产品线/连锁业务对账系统/01-产品定位与业务闭环.md
index a31da52..2bb2501 100644
--- a/10-产品线/连锁业务对账系统/01-产品定位与业务闭环.md
+++ b/10-产品线/连锁业务对账系统/01-产品定位与业务闭环.md
@@ -94,6 +94,10 @@
 
 从收银系统、POS 系统、门店系统、电商系统、外卖平台、团购平台、小程序商城、私域商城、会员系统等同步业务订单，形成订单应收数据。
 
+收银系统订单原则上支持按营业日进行 D+1 批量同步。大部分门店业务不要求实时同步到对账系统；实时接口可以作为可选补充，但不能替代 D+1 完整批次校验。
+
+对账系统需要区分订单业务发生时间、营业日期、来源系统更新时间和实际同步时间。订单归属和报表统计使用业务发生时间及营业日期，不使用 D+1 的同步日期替代。
+
 订单数据至少需要支撑识别：
 
 - 订单发生时间
@@ -106,6 +110,9 @@
 - 业务类型
 - 订单来源平台
 - 优惠、退款、取消等业务状态
+- 营业日期
+- 来源系统更新时间
+- 数据同步时间
 
 ### 5.2 支付渠道识别
 
@@ -217,7 +224,7 @@
 - 不可分账：订单未完成核销或存在未处理差异
 - 可分账：订单已完成核销且金额确认
 - 暂缓分账：订单存在业务争议、退款待确认或人工冻结
-- 已输出分账：对账结果已经同步给分账系统
+- 已输出分账：分账系统已经返回有效接收回执
 
 ### 5.7 分账系统对接
 
diff --git a/10-产品线/连锁业务对账系统/03-标准可扩展数据模型规划.md b/10-产品线/连锁业务对账系统/03-标准可扩展数据模型规划.md
index 5ec5e9c..0b846dd 100644
--- a/10-产品线/连锁业务对账系统/03-标准可扩展数据模型规划.md
+++ b/10-产品线/连锁业务对账系统/03-标准可扩展数据模型规划.md
@@ -7,7 +7,7 @@
 原因在于：
 
 - 连锁企业业态会变化，餐饮、鞋服、零售、药店的订单结构不同。
-- 业务类型会变化，堂食、外卖、团购、电商、私域商城、储值、医保等场景不断增加。
+- 业务类型、下单方式、订单来源和履约方式会变化，不同业态和客户需要扩展自己的分类。
 - 结算渠道会变化，支付渠道、平台渠道、聚合支付、银行入账、医保结算等渠道的账单格式和结算规则不同。
 - 渠道字段会变化，同一个渠道在不同时期也可能调整字段、账单类型、费用项和结算周期。
 
@@ -33,9 +33,9 @@
 | 层级 | 作用 | 典型数据 |
 | --- | --- | --- |
 | 原始数据层 | 保留外部系统原始数据，便于追溯和重放 | 原始订单报文、原始账单文件、原始接口返回 |
-| 标准明细层 | 将不同来源数据转换为系统统一模型 | 标准订单、标准支付明细、标准渠道账单、标准退款、标准费用 |
+| 标准明细层 | 将不同来源数据转换为系统统一模型 | 标准订单、标准支付明细、标准退款、支付明细结算主体关系、门店经营主体关系、门店映射关系、渠道结算周期规则、渠道账单明细、渠道结算单、渠道结算归集明细、标准费用 |
 | 对账核销层 | 承载订单与账单的匹配、核销、差异和状态 | 核销记录、匹配关系、差异记录、处理记录 |
-| 输出服务层 | 面向分账、报表、审计等下游系统输出稳定结果 | 可分账订单、对账结果、差异结果、报表指标 |
+| 输出服务层 | 向分账系统输出稳定结果，并接收分账后的入账反馈 | 可分账结果、对账结果、分账入账反馈、报表指标 |
 
 这种分层可以保证：外部渠道变化时，优先调整原始数据解析和标准化映射，不直接冲击核销规则、差异处理和分账输出。
 
@@ -50,8 +50,9 @@
 | 字段类别 | 字段示例 | 说明 |
 | --- | --- | --- |
 | 业务标识 | 订单号、外部订单号、平台订单号 | 用于识别订单及与外部系统追溯 |
-| 组织归属 | 品牌、区域、加盟商、门店、经营主体 | 用于数据权限、门店对账和分账归属 |
-| 业务分类 | 行业、业务类型、订单来源平台 | 区分堂食、外卖、团购、电商、私域商城等场景 |
+| 组织归属 | 客户企业、品牌、区域、加盟商、门店、经营主体 | 用于租户隔离、数据权限、门店对账和分账归属 |
+| 门店经营属性 | 经营类型、门店形态、收银模式、结算模式、收益规则、管理归属 | 用于解释收款、结算、收益和责任归属 |
+| 业务分类 | 行业、业务类型、下单方式、订单来源、履约方式 | 分别描述经营场景、下单入口、来源系统和交付方式 |
 | 时间信息 | 订单发生时间、支付时间、退款时间 | 用于日结、月结和到账周期分析 |
 | 金额信息 | 订单应收金额、实收金额、优惠金额、退款金额 | 用于与渠道账单核销 |
 | 支付汇总 | 支付状态、支付总金额、支付方式数量 | 用于描述订单整体支付结果，不承载具体支付明细 |
@@ -66,6 +67,8 @@
 
 具体支付构成应进入标准支付明细模型。
 
+门店经营属性不应只保存当前值。标准订单需要根据订单发生日期保留当时有效的经营主体和关键经营属性快照，避免基础资料变更后改变历史对账结果。经营类型固定为直营、加盟、联营、托管四类；收银模式和结算模式可按渠道及业务类型生效，收益规则和管理归属可按合同范围生效。
+
 ### 4.2 标准支付明细
 
 标准支付明细描述一笔订单的支付构成，是连接订单应收、渠道账单和核销结果的关键中间模型。
@@ -97,13 +100,51 @@
 
 - 订单金额口径在标准订单中表达，支付构成在标准支付明细中表达。
 - 每条支付明细可以独立对账，也可以参与订单整体对账。
-- 外部有结算账单的支付明细，需要与标准渠道账单核销。
+- 外部有渠道账单的支付明细，需要与标准渠道账单明细核销，并通过渠道结算单及结算批次判断是否完成结算。
 - 内部权益类支付明细，如私域现金券、储值余额，需要与内部权益或账户流水核对。
 - 优惠、补贴、券抵扣不能简单等同于渠道实收，应区分用户实付、平台承担和商家承担。
 
-### 4.3 标准渠道账单
+### 4.3 支付明细结算主体关系
 
-标准渠道账单是对账系统的实收基础，描述渠道“实际结算了多少钱”。
+支付明细结算主体关系用于表达一条支付明细可以拆分归属到多个结算主体。
+
+核心字段包括：
+
+| 字段类别 | 字段示例 | 说明 |
+| --- | --- | --- |
+| 关联对象 | 支付明细标识、结算主体标识 | 建立支付明细与结算主体的多对多关系 |
+| 归属信息 | 结算归属类型、归属依据、来源系统 | 说明该结算归属如何产生 |
+| 金额信息 | 结算归属金额、结算归属比例 | 描述支付明细在各结算主体之间的归属 |
+| 状态信息 | 待确认、已确认、已失效 | 控制是否允许进入可分账输出 |
+| 审计信息 | 确认人、确认时间、变更原因 | 支持关系变更追溯 |
+
+同一支付明细下各结算主体的结算归属金额合计必须等于支付明细确认金额。结算归属金额的基准是支付明细确认金额，不是扣除结算调整项后的支付明细可分账金额；结算调整项及最终收益分配由后续对象和分账系统分别处理。
+
+该关系是对账系统确认的结算归属，不是分账系统最终生成的参与方分账结果。
+
+### 4.4 标准退款
+
+标准退款由退款单、退款明细和退款流水组成。
+
+| 对象 | 作用 | 核心关系 |
+| --- | --- | --- |
+| 退款单 | 记录一次业务退款请求 | 必须关联原业务订单 |
+| 退款明细 | 将业务退款金额拆分到原支付构成 | 必须关联退款单和原支付明细 |
+| 退款流水 | 记录渠道、券账户、储值账户或现金账户实际执行结果 | 一条退款明细可对应多条退款流水 |
+
+退款明细需要记录业务退款金额、原支付明细、计划退款方式、是否原路退款和退款状态。退款流水需要记录实际退款方式、渠道流水号、实际退款金额、执行时间和执行状态，以支持部分退款、分次退款、失败重试及线上支付现金退款。
+
+### 4.5 渠道结算周期规则
+
+渠道结算周期规则用于计算三方平台账单的预期结算日期，支持 D+N 和 T+N。
+
+核心字段包括客户企业、品牌、结算渠道、商户号、结算主体、业务类型、支付方式、周期类型、基准事件类型、N 值、日历类型、日切截点、时区、节假日顺延规则、宽限期、生效日期和失效日期。
+
+品牌是规则必选隔离维度，不允许跨品牌复用平台默认规则。规则匹配应在同一品牌和平台内优先使用商户号、结算主体、业务类型和支付方式范围更精确的配置，但同一业务范围和有效期内不得存在两个同优先级有效规则。无法唯一匹配时生成配置差异，不计算唯一预期结算日。
+
+### 4.6 标准渠道账单明细
+
+标准渠道账单明细描述渠道侧交易、退款、费用和补贴事实，是支付明细核销的主要外部依据。
 
 核心字段包括：
 
@@ -111,13 +152,52 @@
 | --- | --- | --- |
 | 渠道标识 | 渠道类型、渠道名称、商户号、渠道门店号 | 用于识别账单来源和门店归属 |
 | 流水标识 | 渠道交易流水号、渠道订单号、平台订单号、结算单号、券核销单号 | 用于匹配订单、支付明细和追溯渠道数据 |
-| 时间信息 | 交易时间、结算时间、入账时间、账单日期 | 用于判断订单何时发生、何时结算、何时到账 |
-| 金额信息 | 交易金额、退款金额、手续费、佣金、补贴、实收金额、入账金额 | 用于核销订单应收金额和识别差异 |
+| 时间信息 | 交易时间、账单时间、账单日期 | 用于判断渠道交易和账单事实发生时间 |
+| 金额信息 | 交易金额、退款金额、手续费、佣金、补贴、账单净额 | 用于核销支付明细和识别差异 |
 | 费用信息 | 平台服务费、配送费、包装费、渠道手续费、营销费用 | 用于解释账单实收与订单应收差异 |
 | 归属信息 | 品牌、门店、加盟商、经营主体 | 用于门店对账和分账前置归属 |
 | 状态信息 | 账单状态、核销状态、差异状态 | 用于对账流程控制 |
 
-### 4.4 标准费用项
+### 4.7 渠道结算单
+
+渠道结算单描述渠道针对结算主体、商户号或结算周期确认的应结算结果。
+
+核心字段包括结算单号、结算渠道、结算主体、商户号、结算周期、交易金额、退款金额、费用金额、补贴金额、调整金额、应结算金额、结算状态和确认时间。
+
+### 4.8 渠道结算归集明细
+
+渠道结算归集明细连接渠道账单明细与渠道结算单，并记录归集金额、归集类型和状态。该关系必须支持多对多，以表达部分结算和分批结算。
+
+任一渠道账单明细的累计有效归集金额不得超过其可结算金额；渠道结算单金额必须能够由归集明细、费用项和结算调整项解释。
+
+### 4.9 渠道结算批次
+
+渠道结算批次描述渠道实际发起的一次结算处理，记录批次号、包含的结算单、计划结算日期、实际结算日期、批次金额和批次状态。
+
+渠道结算完成不等同于银行入账。对账系统在此确认渠道结算事实，分账后的银行入账仍由分账系统反馈。
+
+### 4.10 门店经营主体关系
+
+门店经营主体关系记录门店、经营主体、生效日期、失效日期、状态和变更审计信息。系统必须保证同一客户企业、同一门店、同一自然日只能匹配一条有效关系。
+
+### 4.11 门店映射关系
+
+门店映射关系是连接系统门店、结算渠道、商户号和渠道门店的独立标准对象，用于将外部订单和渠道账单明细准确归属到系统门店。
+
+核心字段包括：
+
+| 字段类别 | 字段示例 | 说明 |
+| --- | --- | --- |
+| 系统对象 | 系统门店标识 | 对账系统中的标准门店 |
+| 渠道对象 | 结算渠道、商户号、渠道门店标识 | 外部渠道用于识别交易和门店的信息 |
+| 映射信息 | 映射类型、数据来源 | 描述使用何种渠道标识匹配门店 |
+| 有效期 | 生效时间、失效时间 | 支持门店和商户关系历史变化 |
+| 状态信息 | 待确认、有效、失效、冲突 | 控制映射是否能够用于自动归属 |
+| 人工处理信息 | 冲突原因、处理状态、确认门店、确认人、确认时间、处理说明 | 支持冲突确认和审计追溯 |
+
+门店归属解析必须按业务或账单发生时间使用当时有效的映射关系。无法匹配、匹配到多个有效关系或出现映射冲突时，系统必须产生门店映射差异并转人工确认，不允许通过匹配优先级自动选择门店。人工确认唯一门店前，相关数据不得继续执行自动核销和可分账处理。
+
+### 4.12 标准费用项
 
 费用项用于承接不同渠道不断变化的扣费、佣金、补贴和优惠承担规则。
 
@@ -132,11 +212,11 @@
 | 金额 | 费用项金额 |
 | 承担方 | 品牌、门店、加盟商、平台、渠道、用户 |
 | 来源渠道 | 微信、支付宝、美团、饿了么、抖音、电商平台等 |
-| 关联对象 | 关联订单、支付明细、渠道账单、结算单或退款单 |
+| 关联对象 | 关联订单、支付明细、渠道账单明细、渠道结算单或退款单 |
 
 这样设计可以避免每新增一种平台费用，就修改核心账单模型。
 
-### 4.5 核销记录
+### 4.13 核销记录
 
 核销记录描述订单、支付明细与渠道实收之间的匹配关系，是对账结果的核心。
 
@@ -147,16 +227,16 @@
 | 核销批次 | 一次对账任务生成的批次 |
 | 订单标识 | 关联标准订单 |
 | 支付明细标识 | 关联标准支付明细，组合支付场景下用于定位具体支付组成 |
-| 账单标识 | 关联标准渠道账单 |
+| 账单标识 | 关联标准渠道账单明细 |
 | 核销金额 | 本次用于核销的金额 |
 | 核销类型 | 正常核销、部分核销、退款核销、券核销、权益核销、人工核销 |
 | 匹配依据 | 订单号、支付明细号、渠道流水号、核销码、商户号、门店、金额、时间等 |
-| 核销状态 | 已核销、部分核销、未核销、已撤销 |
+| 核销状态 | 待核销、核销中、未核销、部分核销、已核销、核销冲突、暂停核销、已撤销 |
 | 生成方式 | 自动生成、人工确认、人工调整 |
 
 核销记录需要支持多对多关系，不能假设订单和账单永远是一对一。组合支付场景下，系统应优先在支付明细维度完成核销，再汇总形成订单维度的对账结果。
 
-### 4.6 差异记录
+### 4.14 差异记录
 
 差异记录描述对账过程中发现的问题及处理结果。
 
@@ -168,13 +248,13 @@
 | 差异对象 | 订单、支付明细、账单、核销记录或费用项 |
 | 差异金额 | 对账差异金额 |
 | 差异原因 | 系统识别原因或人工确认原因 |
-| 处理状态 | 待处理、处理中、已确认、已关闭、暂缓处理 |
+| 处理状态 | 待分派、待处理、处理中、待协同、待复核、已关闭、暂缓处理、已驳回、已失效 |
 | 处理结果 | 补账、调整、确认无误、转人工、暂缓分账 |
 | 处理留痕 | 处理人、处理时间、说明、附件 |
 
 差异记录应独立于订单和账单主模型，避免用订单状态承载过多异常处理语义。
 
-### 4.7 可分账结果
+### 4.15 可分账结果
 
 可分账结果是对账系统输出给分账系统的稳定数据对象。
 
@@ -183,14 +263,40 @@
 | 字段类别 | 字段示例 | 说明 |
 | --- | --- | --- |
 | 订单信息 | 订单号、业务类型、订单来源平台、订单发生时间 | 用于分账系统识别业务来源 |
-| 支付构成 | 支付方式、支付明细金额、支付来源平台、优惠和券承担方 | 用于分账系统识别收入构成和优惠承担 |
-| 归属信息 | 品牌、门店、加盟商、经营主体 | 用于分账规则匹配 |
-| 金额信息 | 订单应收金额、渠道实收金额、手续费、退款金额、可分账金额 | 用于分账计算输入 |
+| 支付构成 | 支付明细号、支付方式、支付明细金额、支付来源平台、优惠和券承担方 | 用于按支付明细确定和输出可分账金额 |
+| 归属信息 | 品牌、门店、加盟商、经营主体、支付明细结算主体关系 | 用于分账规则匹配 |
+| 金额信息 | 订单应收金额、支付明细确认金额、手续费、退款金额、支付明细可分账金额、订单可分账金额 | 用于分账计算输入 |
 | 渠道信息 | 支付渠道、商户号、渠道流水号、券核销单号、结算时间 | 用于资金、券核销和渠道追溯 |
 | 对账信息 | 对账状态、核销批次、差异处理结果、确认时间 | 用于判断是否允许分账 |
-| 输出状态 | 未输出、已输出、输出失败、已接收 | 用于接口跟踪 |
+| 分账准备状态 | 待判断、不可分账、暂缓分账、可分账、已失效、待重新计算 | 用于判断当前结果是否允许输出 |
+| 输出状态 | 未输出、输出中、输出失败、已发送、已接收、已拒绝、已撤销、已替换 | 用于接口跟踪和版本管理 |
 
-分账系统应依赖可分账结果对象，而不是直接读取订单表、支付明细表或渠道账单表。
+分账系统应依赖可分账结果对象，而不是直接读取订单表、支付明细表、渠道账单明细表或渠道结算单表。
+
+可分账结果应以支付明细为最小输出粒度。同一订单下不同支付明细可以具有不同的分账准备状态和可分账金额，订单级结果仅作为支付明细结果的汇总。
+
+### 4.16 分账入账反馈
+
+分账入账反馈是分账系统完成分账后返回给对账系统的汇总资金结果。
+
+核心字段包括：
+
+| 字段类别 | 字段示例 | 说明 |
+| --- | --- | --- |
+| 批次信息 | 分账批次号、入账批次号 | 关联分账执行和银行汇总入账 |
+| 收款信息 | 收款主体、银行账户 | 识别实际入账对象 |
+| 金额信息 | 应入账金额、实际入账金额、入账差异金额 | 验证分账结果和银行入账 |
+| 时间信息 | 分账完成时间、银行入账时间、反馈时间 | 计算分账入账周期 |
+| 状态信息 | 待入账、部分入账、已入账、入账异常、入账失败、已退回 | 跟踪入账结果 |
+| 关联信息 | 分账结果、可分账结果、订单范围 | 支持从汇总入账追溯到原始业务 |
+
+银行原则上汇总入账，因此该对象需要支持一笔入账关联多笔分账结果，不要求与单笔订单一对一匹配。
+
+### 4.17 分账结果入账关联明细
+
+分账结果入账关联明细连接分账结果与分账入账反馈，并记录本次关联金额、状态和确认时间。
+
+该关系必须支持多对多：一笔分账结果可以分多次入账，一笔汇总入账可以关联多笔分账结果。分账结果的累计有效关联金额不得超过其应入账金额。
 
 ## 5. 渠道扩展机制
 
@@ -207,7 +313,7 @@
   ↓
 字段映射规则
   ↓
-标准渠道账单
+标准渠道账单明细
   ↓
 标准费用项
   ↓
@@ -249,16 +355,35 @@
 
 - 标准订单
 - 标准支付明细
-- 标准渠道账单
+- 标准退款
+- 支付明细结算主体关系
+- 门店经营主体关系
+- 门店映射关系
+- 渠道结算周期规则
+- 标准渠道账单明细
+- 渠道结算单
+- 渠道结算归集明细
+- 渠道结算批次
 - 标准费用项
 - 核销记录
 - 差异记录
 - 可分账结果
+- 分账入账反馈
+- 分账结果入账关联明细
 
 ### 6.2 可扩展部分允许变化
 
 以下部分应允许按渠道和业务类型扩展：
 
+- 业务类型字典
+- 下单方式字典
+- 订单来源字典
+- 履约方式字典
+- 门店形态字典
+- 收银模式配置
+- 结算模式配置
+- 收益规则配置
+- 管理归属配置
 - 原始报文字段
 - 渠道字段映射
 - 费用项类型
@@ -268,6 +393,10 @@
 - 差异识别规则
 - 报表展示字段
 
+业务类型、下单方式、订单来源和履约方式采用平台标准字典与客户扩展字典并存的模式。客户扩展值需要使用客户企业范围内唯一编码，并映射到平台标准分类。字典项需要支持生效、停用和历史追溯；已被业务数据引用的编码不得删除或修改。
+
+门店经营属性需要区分稳定分类和时态配置：经营类型使用四类标准值；门店形态允许在标准分类基础上扩展；收银模式、结算模式、收益规则和管理归属按适用范围及有效期配置；经营主体继续使用独立的门店经营主体关系维护。
+
 ### 6.3 不应把渠道差异写死在主流程
 
 不建议采用以下设计：
@@ -286,11 +415,21 @@
 
 - 标准订单模型
 - 标准支付明细模型
-- 标准渠道账单模型
+- 标准退款模型
+- 支付明细结算主体关系模型
+- 门店经营主体关系模型
+- 门店映射关系模型
+- 渠道结算周期规则模型
+- 标准渠道账单明细模型
+- 渠道结算单模型
+- 渠道结算归集明细模型
+- 渠道结算批次模型
 - 标准费用项模型
 - 核销记录模型
 - 差异记录模型
 - 可分账结果模型
+- 分账入账反馈模型
+- 分账结果入账关联明细模型
 - 渠道字段映射能力
 - 基础匹配规则配置能力
 
diff --git a/10-产品线/连锁业务对账系统/04-产品规划与执行计划.md b/10-产品线/连锁业务对账系统/04-产品规划与执行计划.md
new file mode 100644
index 0000000..06b30f0
--- /dev/null
+++ b/10-产品线/连锁业务对账系统/04-产品规划与执行计划.md
@@ -0,0 +1,681 @@
+# 连锁业务对账系统产品规划与执行计划
+
+## 1. 规划目的
+
+本文档基于当前已经完成的产品定位、岗位需求分析和标准数据模型规划，提出连锁业务对账系统下一阶段的产品规划文档清单和工作顺序。
+
+本阶段只围绕连锁业务线展开，重点服务连锁餐饮，并兼顾后续向连锁鞋服、连锁零售等业态扩展的能力基础。
+
+本文档同时作为持续更新的执行台账，用于记录任务依赖、推进状态、评审结论和下一步工作。
+
+执行原则：
+
+- 严格按业务定义、业务场景、产品方案、核心规则、数据集成、产品落地的依赖顺序推进。
+- 每项任务形成独立文档，不以口头讨论代替正式产出。
+- 上游业务口径未确认前，不提前固化下游页面、字段和规则。
+- 每份文档完成初稿后先进行评估，再进入下一项。
+- 已确认结论作为后续文档输入，发现冲突时回溯修订源文档。
+
+## 2. 当前基础
+
+目前已经完成：
+
+- 产品定位与业务闭环。
+- 财务部门需求分析。
+- 统计部门需求分析。
+- 加盟商需求分析。
+- 门店人员需求分析。
+- 业务运营部门需求分析。
+- IT 部门初步需求分析。
+- 连锁餐饮品牌财务部门岗位梳理。
+- 业务运营部门岗位职责与分工。
+- 标准可扩展数据模型初步规划。
+
+当前已经明确：
+
+- 对账以订单应收和渠道实收核销为核心。
+- 支付信息需要独立建模，支持组合支付。
+- 财务核对和结算结果落到门店。
+- 加盟商是其旗下门店的汇总视角。
+- 业务运营部门负责解释业务规则和协同处理业务类异常。
+- 完成对账的订单输出给分账系统。
+
+## 3. 下一阶段核心目标
+
+下一阶段需要把分散的岗位需求收敛成统一的产品方案，重点回答：
+
+- 系统统一使用哪些业务术语和金额口径？
+- 连锁餐饮有哪些必须支持的对账场景？
+- 订单、支付、账单、退款、费用和入账如何形成完整链路？
+- 系统由哪些产品模块组成？
+- 自动核销和差异处理遵循什么规则？
+- 第一阶段产品具体建设哪些能力？
+
+## 4. 建议文档体系
+
+### 4.1 业务定义类
+
+#### 04-01 核心业务术语与指标口径
+
+需要定义：
+
+- 订单金额
+- 订单应收金额
+- 用户实付金额
+- 券核销金额
+- 优惠金额
+- 补贴金额
+- 渠道交易金额
+- 渠道结算金额
+- 渠道实收金额
+- 银行入账金额
+- 已支付
+- 已结算
+- 已入账
+- 已核销
+- 未结算金额
+- 差异金额
+- 可分账金额
+
+产出目标：形成产品、业务、财务、研发共同使用的统一语言。
+
+#### 04-02 业务对象与业务关系
+
+需要定义：
+
+- 品牌
+- 客户企业
+- 区域
+- 加盟商
+- 门店
+- 经营主体
+- 门店经营主体关系
+- 结算主体
+- 业务类型
+- 下单方式
+- 订单来源
+- 履约方式
+- 支付方式
+- 结算渠道
+- 商户号
+- 渠道门店
+- 银行账户
+
+产出目标：明确组织、门店、渠道、订单和结算主体之间的关系。
+
+### 4.2 业务场景类
+
+#### 05-01 连锁餐饮对账场景清单
+
+第一阶段建议覆盖：
+
+- 门店堂食在线支付。
+- 扫码点餐在线支付。
+- 现金及其他无需渠道结算的支付。
+- 三方团购券核销。
+- 团购券加在线支付。
+- 团购券加在线支付加私域现金券。
+- 储值余额加在线支付。
+- 外卖平台订单。
+- 外卖退款和部分退款。
+- 团购券退款、过期和异常核销。
+- 私域现金券、优惠券和会员权益。
+- 平台补贴、品牌补贴、门店承担优惠。
+- 平台佣金、手续费、配送费、包装费。
+- 跨日结算。
+- 分批结算。
+- 分账后银行入账反馈与验证。
+
+每个场景需要明确：
+
+- 业务发生过程。
+- 订单来源。
+- 支付构成。
+- 应收金额口径。
+- 渠道账单来源。
+- 结算金额口径。
+- 匹配依据。
+- 可能产生的差异。
+- 对账完成条件。
+- 分账输出条件。
+
+#### 05-02 端到端业务流程
+
+需要设计：
+
+- 订单同步流程。
+- 支付明细同步流程。
+- 渠道账单同步流程。
+- 退款同步流程。
+- 自动核销流程。
+- 差异协同处理流程。
+- 分账后银行入账反馈与验证流程。
+- 对账结果确认流程。
+- 可分账结果输出流程。
+
+产出目标：形成从业务订单发生到分账输出的统一主流程。
+
+#### 05-03 状态流转设计
+
+需要定义：
+
+- 订单对账状态。
+- 支付明细对账状态。
+- 渠道账单核销状态。
+- 退款核销状态。
+- 差异处理状态。
+- 分账准备状态。
+- 分账输出状态。
+
+产出目标：避免不同页面和模块各自定义状态。
+
+### 4.3 产品设计类
+
+#### 06-01 产品能力地图
+
+建议一级能力：
+
+1. 基础资料与映射。
+2. 数据接入管理。
+3. 订单中心。
+4. 支付明细中心。
+5. 渠道账单中心。
+6. 退款中心。
+7. 费用项管理。
+8. 对账核销中心。
+9. 差异处理中心。
+10. 分账后银行入账反馈与验证。
+11. 对账结果确认。
+12. 分账结果输出。
+13. 对账报表与分析。
+14. 任务监控。
+15. 权限与审计。
+
+产出目标：把岗位需求收敛为统一产品能力，避免按部门重复建设页面和功能。
+
+#### 06-02 功能架构与功能清单
+
+每项功能需要明确：
+
+- 所属能力模块。
+- 主要使用角色。
+- 使用场景。
+- 解决问题。
+- 输入数据。
+- 输出结果。
+- 操作权限。
+- 是否纳入 MVP。
+
+#### 06-03 信息架构与页面清单
+
+需要形成：
+
+- 系统菜单结构。
+- 页面名称。
+- 页面用途。
+- 主要用户。
+- 核心字段。
+- 页面操作。
+- 页面跳转关系。
+
+产出目标：作为 UI 原型的直接输入。
+
+### 4.4 核心规则类
+
+#### 07-01 对账匹配与核销规则
+
+需要设计：
+
+- 订单与支付明细关系。
+- 支付明细与渠道账单关系。
+- 一对一匹配。
+- 一对多匹配。
+- 多对一匹配。
+- 组合支付核销。
+- 金额容差。
+- 时间窗口。
+- 匹配优先级。
+- 自动核销条件。
+- 人工核销条件。
+- 核销撤销和重新核销。
+
+#### 07-02 退款对账规则
+
+需要设计：
+
+- 全额退款。
+- 部分退款。
+- 原路退款。
+- 跨渠道退款。
+- 券退回。
+- 储值退回。
+- 退款发生后已分账订单的处理边界。
+
+#### 07-03 费用项、结算调整项与优惠承担规则
+
+需要设计：
+
+- 支付手续费。
+- 平台佣金。
+- 服务费。
+- 配送费。
+- 包装费。
+- 达人佣金。
+- 平台补贴。
+- 品牌补贴。
+- 门店承担优惠。
+- 加盟商承担优惠。
+- 平台处罚。
+- 平台赔付。
+- 批量奖励和补扣款。
+- 非订单级调整项归属层级。
+- 多门店调整项分摊规则。
+- 待归属调整项处理。
+
+#### 07-04 差异分类与处理规则
+
+需要定义：
+
+- 差异类型。
+- 差异识别条件。
+- 责任部门。
+- 处理方式。
+- 是否阻断分账。
+- 是否允许人工确认。
+- 关闭条件。
+- 审计要求。
+
+### 4.5 数据与集成类
+
+#### 08-01 标准数据模型详细设计
+
+在现有模型规划基础上细化：
+
+- 标准订单。
+- 标准支付明细。
+- 退款单、退款明细和退款流水。
+- 标准渠道账单明细。
+- 渠道结算单、渠道结算归集明细和渠道结算批次。
+- 标准费用项。
+- 分账入账反馈。
+- 分账结果入账关联明细。
+- 门店经营主体关系。
+- 核销记录。
+- 差异记录。
+- 可分账结果。
+
+需要补充：
+
+- 对象关系。
+- 业务唯一键。
+- 核心字段。
+- 金额字段口径。
+- 时间字段口径。
+- 状态字段。
+- 扩展字段机制。
+
+#### 08-02 系统边界与集成清单
+
+需要明确与以下系统的关系：
+
+- 收银系统。
+- 外卖平台。
+- 团购平台。
+- 私域和会员系统。
+- 支付渠道。
+- 聚合支付系统。
+- 银行流水系统。
+- 分账系统。
+- 财务系统。
+- 统一组织和权限平台。
+
+#### 08-03 渠道接入规范
+
+需要定义：
+
+- 原始数据保留。
+- 渠道字段映射。
+- 账单类型。
+- 金额口径。
+- 时间口径。
+- 数据校验。
+- 幂等规则。
+- 补数和重跑机制。
+- 渠道版本变更处理。
+
+### 4.6 权限与报表类
+
+#### 09-01 角色权限与数据权限
+
+需要按以下角色设计：
+
+- 财务部门。
+- 统计部门。
+- 加盟商。
+- 门店人员。
+- 业务运营部门。
+- IT 部门。
+
+权限内容包括：
+
+- 菜单权限。
+- 页面权限。
+- 操作权限。
+- 数据范围。
+- 明细查看权限。
+- 导出权限。
+- 敏感字段权限。
+- 审计权限。
+
+#### 09-02 报表与指标体系
+
+建议标准报表：
+
+- 财务对账总览。
+- 门店对账报表。
+- 加盟商多店汇总。
+- 渠道对账报表。
+- 业务类型对账报表。
+- 差异分析报表。
+- 到账周期报表。
+- 费用和优惠承担报表。
+- 可分账结果报表。
+- 任务运行报表。
+
+### 4.7 产品落地类
+
+#### 10-01 MVP 范围
+
+第一阶段建议优先支持：
+
+- 连锁餐饮。
+- 堂食和扫码点餐订单。
+- 外卖业务。
+- 团购业务。
+- 私域券和储值组合支付。
+- 微信、支付宝、外卖平台、团购平台账单。
+- 订单、支付明细、账单自动核销。
+- 退款核对。
+- 差异处理。
+- 门店和加盟商查询。
+- 对账结果输出分账系统。
+- 接收分账系统返回的银行汇总入账反馈。
+- 分账批次应入账金额与银行实际入账金额验证。
+
+第一阶段暂不支持：
+
+- 所有连锁行业一次性覆盖。
+- 所有渠道配置化接入。
+- 完整低代码规则平台。
+- 完整财务总账。
+- 完整经营 BI。
+- 资金出款。
+
+#### 10-02 版本路线图
+
+建议划分：
+
+- V1.0：连锁餐饮核心订单对账闭环、分账结果输出、分账后银行入账反馈与验证。
+- V1.1：组合支付、退款和复杂费用项完善。
+- V1.2：对账分析、异常治理和渠道扩展能力完善。
+- V2.0：连锁鞋服、零售等行业扩展。
+
+#### 10-03 UI 原型
+
+优先页面：
+
+1. 财务对账总览。
+2. 订单与支付明细。
+3. 渠道账单明细。
+4. 核销结果详情。
+5. 差异处理工作台。
+6. 门店对账详情。
+7. 加盟商多店汇总。
+8. 运营差异协同。
+9. 对账结果与分账输出。
+10. 任务监控。
+
+#### 10-04 版本 PRD 与验收标准
+
+每个版本需要包含：
+
+- 版本目标。
+- 用户和场景。
+- 业务规则。
+- 功能需求。
+- 页面交互。
+- 数据字段。
+- 权限要求。
+- 异常处理。
+- 验收场景。
+- 非功能要求。
+
+## 5. 推荐工作顺序
+
+### 第一批：先统一业务
+
+1. 核心业务术语与指标口径。
+2. 业务对象与业务关系。
+3. 连锁餐饮对账场景清单。
+4. 端到端业务流程。
+5. 状态流转设计。
+
+完成标准：产品、业务、财务、研发对核心概念和业务过程没有明显歧义。
+
+### 第二批：收敛产品方案
+
+6. 产品能力地图。
+7. 功能架构与功能清单。
+8. 对账匹配与核销规则。
+9. 退款对账规则。
+10. 费用项、结算调整项与优惠承担规则。
+11. 差异分类与处理规则。
+
+完成标准：可以明确系统做什么、不做什么，以及核心规则如何运行。
+
+### 第三批：落实数据与系统协作
+
+12. 标准数据模型详细设计。
+13. 系统边界与集成清单。
+14. 渠道接入规范。
+15. 角色权限与数据权限。
+16. 报表与指标体系。
+
+完成标准：研发可以评估系统架构、接口、数据量和实施成本。
+
+### 第四批：形成可实施版本
+
+17. MVP 范围。
+18. 版本路线图。
+19. 信息架构与页面清单。
+20. 核心页面 UI 原型。
+21. V1.0 PRD 与验收标准。
+
+完成标准：可以进入研发评审、工作量评估和版本排期。
+
+## 6. 当前建议立即启动
+
+当前建议先完成以下三份文档：
+
+1. `06-核心业务术语与指标口径.md`
+2. `07-业务对象与业务关系.md`
+3. `08-连锁餐饮对账场景清单.md`
+
+上述文档完成并评审后，再依次开展端到端业务流程、状态流转、产品能力地图和功能架构，避免直接根据岗位需求堆叠功能。
+
+## 7. 阶段与里程碑
+
+| 阶段 | 阶段目标 | 完成标志 |
+| --- | --- | --- |
+| P1 业务定义 | 统一业务语言、业务对象、业务场景和状态 | 产品、财务、运营和研发对核心口径无明显歧义 |
+| P2 产品方案 | 收敛产品能力、功能范围和核心业务规则 | 明确系统做什么、如何运行、哪些异常需要处理 |
+| P3 数据与集成 | 落实数据模型、系统边界、渠道接入、权限和报表 | 研发可以开展架构和工作量评估 |
+| P4 产品落地 | 明确 MVP、版本路线、页面原型和 PRD | 可以进入研发评审、排期和实施 |
+
+## 8. 任务执行台账
+
+| 编号 | 任务 | 核心产出 | 前置依赖 | 状态 |
+| --- | --- | --- | --- | --- |
+| P1-01 | 核心业务术语与指标口径 | 术语定义、金额口径、状态定义、指标公式 | 已有产品定位与岗位需求 | 已确认 |
+| P1-02 | 业务对象与业务关系 | 业务对象定义、归属关系、对象关系图 | P1-01 | 已确认 |
+| P1-03 | 连锁餐饮对账场景清单 | 场景分类、业务过程、数据来源、对账条件 | P1-01、P1-02 | 待评审 |
+| P1-04 | 端到端业务流程 | 订单到分账输出的主流程和分支流程 | P1-03 | 待评审 |
+| P1-05 | 状态流转设计 | 订单、支付、账单、退款、差异、分账状态机 | P1-03、P1-04 | 待评审 |
+| P2-01 | 产品能力地图 | 一级能力、二级能力、能力边界 | P1 全部 | 未启动 |
+| P2-02 | 功能架构与功能清单 | 功能、角色、场景、输入输出、MVP 建议 | P2-01 | 未启动 |
+| P2-03 | 对账匹配与核销规则 | 匹配层级、优先级、多对多、组合支付规则 | P1-03、P1-05 | 未启动 |
+| P2-04 | 退款对账规则 | 全额、部分、跨日、券退回、储值退回规则 | P1-03、P2-03 | 未启动 |
+| P2-05 | 费用项、结算调整项与优惠承担规则 | 费用分类、调整项归属分摊、承担方和金额关系 | P1-01、P1-03 | 未启动 |
+| P2-06 | 差异分类与处理规则 | 差异分类、责任部门、阻断条件、关闭条件 | P2-03、P2-04、P2-05 | 未启动 |
+| P3-01 | 标准数据模型详细设计 | 对象关系、字段、唯一键、状态和扩展机制 | P2 核心规则 | 未启动 |
+| P3-02 | 系统边界与集成清单 | 上下游系统、数据流向、职责边界 | P1-04、P3-01 | 未启动 |
+| P3-03 | 渠道接入规范 | 原始数据、映射、校验、幂等、补数和变更规范 | P3-01、P3-02 | 未启动 |
+| P3-04 | 角色权限与数据权限 | 菜单、操作、数据范围、敏感字段和审计权限 | P2-02、岗位需求 | 未启动 |
+| P3-05 | 报表与指标体系 | 标准报表、指标公式、维度和数据来源 | P1-01、P3-01 | 未启动 |
+| P4-01 | MVP 范围 | 首期行业、渠道、场景、能力和排除项 | P2、P3 | 未启动 |
+| P4-02 | 版本路线图 | V1.0、V1.1、V1.2、V2.0 建设范围 | P4-01 | 未启动 |
+| P4-03 | 信息架构与页面清单 | 菜单、页面、角色、字段、操作和跳转关系 | P2-02、P3-04、P4-01 | 未启动 |
+| P4-04 | 核心页面 UI 原型 | 财务、门店、加盟商、运营、任务监控原型 | P4-03 | 未启动 |
+| P4-05 | V1.0 PRD 与验收标准 | 业务规则、交互、数据、权限、异常和验收场景 | P4-01 至 P4-04 | 未启动 |
+
+状态说明：
+
+- 未启动：尚未进入正式编写。
+- 进行中：已经开始编写，尚未完成评估。
+- 待评审：初稿完成，等待业务或产品评估。
+- 已确认：评审结论已合入，可作为后续任务输入。
+- 暂缓：存在明确前置条件或范围调整。
+
+## 9. 第一阶段执行计划
+
+### 9.1 P1-01 核心业务术语与指标口径
+
+产出文件：
+
+- [核心业务术语与指标口径](06-核心业务术语与指标口径.md)
+
+评审重点：
+
+- 订单应收金额和订单成交金额。
+- 组合支付及各支付明细口径。
+- 团购券五类金额。
+- 储值消费与资金入账追溯。
+- 门店现金账户和现金汇缴。
+- 支付明细级可分账金额。
+- 分账后银行入账反馈。
+- 费用、补贴和结算调整项。
+
+当前状态：已确认。
+
+### 9.2 P1-02 业务对象与业务关系
+
+产出文件：
+
+- [业务对象与业务关系](07-业务对象与业务关系.md)
+
+评审重点：
+
+- 品牌、区域、加盟商、门店关系。
+- 客户企业、品牌和客户级数据隔离关系。
+- 经营主体与结算主体关系。
+- 门店经营主体关系及同一自然日唯一约束。
+- 商户号、渠道门店和系统门店映射。
+- 支付明细作为核销和可分账最小对象。
+- 业务类型、下单方式、订单来源、履约方式和支付方式边界。
+- 渠道账单明细、渠道结算归集明细、渠道结算单和渠道结算批次关系。
+- 退款单、退款明细和退款流水关系。
+- 结算调整项的归属和分摊对象。
+- 分账结果和银行入账反馈的多对多金额关系。
+
+当前状态：已确认。
+
+### 9.3 P1-03 连锁餐饮对账场景清单
+
+产出文件：
+
+- [连锁餐饮对账场景清单](08-连锁餐饮对账场景清单.md)
+
+启动条件：
+
+- P1-02 评审完成。
+
+当前状态：待评审。
+
+### 9.4 P1-04 端到端业务流程
+
+产出文件：
+
+- [端到端业务流程](09-端到端业务流程.md)
+
+启动条件：
+
+- P1-03 评审完成。
+
+当前状态：待评审。本文档基于 P1-03 初稿先行编写，P1-03 与 P1-04 需要联合评审并同步修订。
+
+### 9.5 P1-05 状态流转设计
+
+产出文件：
+
+- [状态流转设计](10-状态流转设计.md)
+
+启动条件：
+
+- P1-03、P1-04 评审完成。
+
+当前状态：待评审。本文档基于 P1-03、P1-04 初稿先行编写，三份文档需要联合评审。
+
+## 10. 评审机制
+
+每项任务按照以下过程推进：
+
+1. 汇总已有文档结论。
+2. 编写初稿并标识假设和待确认项。
+3. 检查与产品定位、岗位需求和数据模型是否冲突。
+4. 提交评估。
+5. 根据评估意见修订。
+6. 状态更新为已确认。
+7. 启动下一项依赖任务。
+
+评审维度：
+
+- 业务真实性：是否符合连锁餐饮实际业务。
+- 口径一致性：是否与其他文档定义一致。
+- 产品边界：是否属于对账系统职责。
+- 可实现性：是否能被数据和系统流程支撑。
+- 可扩展性：是否能适配新增业务类型和结算渠道。
+
+## 11. 执行记录
+
+| 日期 | 任务 | 动作 | 状态 |
+| --- | --- | --- | --- |
+| 2026-06-20 | P1-01 | 完成核心业务术语与指标口径初稿 | 待评审 |
+| 2026-06-20 | P1-01 | 确认订单原价、成交金额和应收金额口径 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认团购券五类金额及报表使用口径 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认储值账户流水核对及分账系统资金入账追溯 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认平台优惠券作为独立支付明细 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认现金支付、门店现金账户、线上汇缴和跨方式退款 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认银行按分账结果汇总入账并由分账系统反馈 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认分账后银行入账反馈与验证纳入 V1.0 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认可分账金额按支付明细分别确定 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 确认正常费用、费用容差和平台补贴处理 | 已确认部分口径 |
+| 2026-06-20 | P1-01 | 完成全部术语与指标口径确认 | 已确认 |
+| 2026-06-20 | P1-02 | 完成业务对象与业务关系初稿 | 待评审 |
+| 2026-06-20 | P1-02 | 确认同一门店同一自然日唯一经营主体 | 已确认部分关系 |
+| 2026-06-20 | P1-02 | 确认同一支付明细允许拆分到多个结算主体 | 已确认部分关系 |
+| 2026-06-20 | P1-02 | 确认门店映射冲突全部转人工确认，禁止按优先级自动归属 | 已确认部分关系 |
+| 2026-06-20 | P1-02 | 确认业务类型和订单来源采用平台标准字典并允许客户扩展 | 已确认部分关系 |
+| 2026-06-20 | P1-02 | 确认四类门店经营类型及门店形态、收银、结算、收益、管理归属和经营主体模型 | 已确认部分关系 |
+| 2026-06-20 | P1-02 | 根据评审补齐客户企业、业务分类、渠道结算、退款及分账入账关联对象 | 已修订 |
+| 2026-06-20 | P1-02 | 完成业务对象与业务关系复评 | 已确认 |
+| 2026-06-21 | P1-03 | 完成连锁餐饮对账场景清单初稿 | 待评审 |
+| 2026-06-21 | P1-04 | 完成端到端业务流程初稿 | 待评审 |
+| 2026-06-21 | P1-04 | 确认收银订单以营业日 D+1 批量同步为主，实时同步为可选补充 | 已确认部分流程 |
+| 2026-06-21 | P1-04 | 确认三方平台结算支持按品牌和平台配置 D+N、T+N 周期 | 已确认部分流程 |
+| 2026-06-21 | P1-05 | 完成状态流转设计初稿 | 待评审 |
+
+## 12. 下一步
+
+1. 联合评审 P1-03《连锁餐饮对账场景清单》、P1-04《端到端业务流程》和 P1-05《状态流转设计》。
+2. 根据评审结果修订并确认 P1-03、P1-04、P1-05。
+3. 启动 P2-01《产品能力地图》。
diff --git a/10-产品线/连锁业务对账系统/06-核心业务术语与指标口径.md b/10-产品线/连锁业务对账系统/06-核心业务术语与指标口径.md
new file mode 100644
index 0000000..ac5fbe7
--- /dev/null
+++ b/10-产品线/连锁业务对账系统/06-核心业务术语与指标口径.md
@@ -0,0 +1,956 @@
+# 连锁业务对账系统核心业务术语与指标口径
+
+## 1. 文档目的
+
+本文档用于统一连锁业务对账系统中的核心业务术语、金额口径、状态语义和统计指标，作为业务场景、流程、数据模型、核销规则、报表和 UI 设计的共同基础。
+
+本文档已完成核心业务口径确认。涉及企业具体收入确认政策、优惠会计处理和分账规则的内容，仍需在客户实施阶段结合实际业务配置。
+
+## 2. 口径设计原则
+
+- 区分业务发生、用户支付、渠道结算、对账核销、分账执行和银行入账。
+- 区分订单汇总金额和支付明细金额。
+- 组合支付必须在支付明细层表达，不在订单主对象中压缩为单一支付方式。
+- 优惠、补贴和券必须明确金额性质及承担方。
+- 渠道结算不等于银行入账。银行原则上按分账结果汇总入账，并由分账系统在分账完成后反馈入账记录。
+- 可分账金额是对账系统确认后的输入金额，不包含分账规则计算结果。
+- 所有汇总指标必须能够追溯到门店、订单、支付明细、账单和核销记录。
+
+## 3. 业务层级
+
+| 层级 | 核心问题 | 核心对象 |
+| --- | --- | --- |
+| 业务发生层 | 发生了什么交易，应该收多少钱 | 订单、退款单、退款明细 |
+| 支付构成层 | 用户通过什么方式完成支付或权益抵扣 | 支付明细、券核销、储值扣减、现金收款 |
+| 渠道结算层 | 外部渠道按什么口径、什么批次结算了多少钱 | 渠道账单明细、渠道结算单、渠道结算批次、费用项 |
+| 对账核销层 | 订单应收和渠道结算是否匹配 | 核销记录、现金账户流水、差异记录 |
+| 分账准备层 | 哪些已确认金额可以输出给分账系统 | 可分账结果 |
+| 分账执行层 | 已确认金额如何完成分账和资金归集 | 分账结果、分账批次 |
+| 资金入账层 | 分账后的汇总资金是否进入银行账户 | 分账入账反馈、银行入账批次 |
+
+## 4. 订单相关术语
+
+### 4.1 业务订单
+
+业务订单是收银系统、扫码点餐系统、外卖平台、团购平台、小程序商城等业务系统记录的一次交易事实。
+
+一笔业务订单可以包含多条支付明细，也可以发生一次或多次退款。
+
+收银系统订单通常在门店营业结束后按 D+1 批量同步到对账系统，不以实时同步作为统一前提。订单统计和对账归属使用业务发生时间及营业日期，数据同步时间只用于监控数据到达和处理时效。
+
+相关时间需要区分：
+
+| 时间 | 定义 |
+| --- | --- |
+| 业务发生时间 | 订单在业务系统实际发生的时间 |
+| 营业日期 | 门店经营归属日期，可受跨午夜营业规则影响 |
+| 来源系统更新时间 | 收银系统最后修改订单的时间 |
+| 数据同步时间 | 对账系统实际接收订单的时间 |
+| 数据完整截止时间 | D+1 批次按约定应完成同步的时间 |
+
+D+1 数据完整截止时间前，不因订单或支付明细尚未到达生成正式缺失差异；超过截止时间仍缺失时再进入差异处理。
+
+#### 4.1.1 订单分类维度
+
+业务订单需要分别记录以下维度：
+
+| 维度 | 定义 | 示例 |
+| --- | --- | --- |
+| 业务类型 | 订单所属经营场景 | 堂食、外卖、团购、电商、线下零售 |
+| 下单方式 | 创建订单的交互入口 | 收银台开单、扫码点餐、小程序下单、平台下单 |
+| 订单来源 | 生成订单的系统或平台 | POS、美团、抖音、自有商城、私域商城 |
+| 履约方式 | 商品或服务的交付方式 | 到店消费、门店自提、门店配送、平台配送 |
+| 支付方式 | 覆盖订单成交金额的资金或权益方式 | 在线支付、现金、储值、团购券、优惠券 |
+
+上述维度不得相互替代。例如扫码点餐属于下单方式，私域商城属于订单来源，储值消费属于支付方式。
+
+### 4.2 订单商品原价金额
+
+订单中商品或服务按照标准销售价格计算的金额合计，不扣除任何商品优惠、折扣和券，也不包含包装费、配送费等订单附加费用。
+
+建议公式：
+
+```text
+订单商品原价金额 = 订单内各商品标准售价 × 商品数量的合计
+```
+
+### 4.3 订单附加费用金额
+
+除商品或服务价格以外，因订单履约、包装、配送或其他业务规则向用户收取的费用合计。
+
+常见订单附加费用包括：
+
+- 包装费。
+- 配送费。
+- 餐盒费。
+- 服务费。
+- 其他订单侧附加收费。
+
+订单附加费用需要按费用项独立记录，不能只保留附加费用合计。
+
+### 4.4 订单原价金额
+
+订单商品原价金额与订单附加费用金额的合计，不扣除任何优惠、折扣和券。
+
+建议公式：
+
+```text
+订单原价金额 = 订单商品原价金额 + 订单附加费用金额
+```
+
+### 4.5 订单优惠金额
+
+订单原价金额与订单成交金额之间的优惠差额。
+
+优惠金额必须进一步区分承担方：
+
+- 平台承担优惠。
+- 品牌承担优惠。
+- 门店承担优惠。
+- 加盟商承担优惠。
+- 其他合作方承担优惠。
+
+### 4.6 订单成交金额
+
+用户完成本次交易需要通过资金支付、券核销、储值扣减或其他权益抵扣覆盖的金额。
+
+建议公式：
+
+```text
+订单成交金额 = 订单原价金额 - 订单优惠金额
+```
+
+### 4.7 订单应收金额
+
+对账系统基于业务订单确认的应核对金额。
+
+订单应收金额统一使用订单成交金额作为业务口径。订单应收金额不是单一在线支付金额，而是需要通过各类支付明细、权益流水或渠道账单核对的订单成交金额。
+
+统一公式：
+
+```text
+订单应收金额 = 订单成交金额
+```
+
+同时应满足支付平衡关系：
+
+```text
+订单应收金额 = 订单成交金额
+             = 各有效支付明细应核对金额合计
+```
+
+如果存在不参与对账的抹零、免单或特殊内部承担项，需要单独记录，不能隐含在差异金额中。
+
+### 4.8 有效订单
+
+满足统计和对账条件的订单。通常包括已支付、已完成或已发生有效支付的订单，不包括未支付取消单、测试单和已完全冲销且不产生结算影响的订单。
+
+有效订单的最终判定规则需要在业务场景文档中按订单来源定义。
+
+## 5. 支付相关术语
+
+### 5.1 支付明细
+
+支付明细是订单支付构成的最小业务记录。一笔订单可以对应多条支付明细。
+
+支付明细示例：
+
+- 微信支付。
+- 支付宝支付。
+- 三方团购券核销。
+- 私域现金券抵扣。
+- 储值余额扣减。
+- 平台优惠券。
+- 现金支付。
+
+### 5.2 支付方式
+
+完成订单金额覆盖的具体方式。支付方式不等同于结算渠道。
+
+例如：
+
+- 团购券是一种支付或权益核销方式。
+- 团购平台是该支付明细的结算渠道。
+- 私域现金券可能是支付方式，但不一定存在外部资金结算渠道。
+- 平台优惠券作为独立支付明细记录，不只作为订单优惠汇总字段。
+- 现金是用户支付方式，同时需要通过门店现金账户和后续线上汇缴进入渠道结算核销。
+
+### 5.3 平台优惠券支付明细
+
+平台优惠券是由外卖、团购、电商、新媒体等平台发放，并在订单中用于抵扣应付金额的支付明细。
+
+平台优惠券支付明细至少需要记录：
+
+- 优惠券类型。
+- 优惠券标识或券码。
+- 券面金额。
+- 实际核销金额。
+- 平台承担金额。
+- 品牌、门店或加盟商承担金额。
+- 关联活动。
+- 关联订单。
+- 来源平台。
+- 核销时间。
+
+平台优惠券作为支付明细参与订单支付平衡：
+
+```text
+订单应收金额 = 用户实付金额 + 平台优惠券核销金额
+             + 其他券核销金额 + 储值扣减金额
+             + 其他有效支付或权益抵扣金额
+```
+
+平台优惠券的承担金额需要同时保留在优惠承担信息中，用于解释平台应结算金额和订单应收金额之间的关系。
+
+### 5.4 用户实付金额
+
+用户以现金、银行卡、微信、支付宝等资金方式实际支付的金额。
+
+用户实付金额不包括：
+
+- 平台补贴。
+- 品牌补贴。
+- 门店承担优惠。
+- 无需用户支付的权益抵扣。
+
+### 5.5 团购券金额
+
+团购券需要同时保留以下五类金额，并根据报表用途使用不同口径：
+
+| 金额 | 定义 | 主要使用报表 |
+| --- | --- | --- |
+| 团购券券面金额 | 团购券标明可抵扣的商品或服务价值 | 商品价值、活动力度和用户权益分析 |
+| 团购券购买金额 | 用户购买团购券实际支付的金额 | 用户支付、团购销售和营销分析 |
+| 团购券核销金额 | 团购券在门店订单中实际抵扣或支付的金额 | 订单支付构成、门店核销和订单应收分析 |
+| 平台应结算金额 | 平台根据券核销和结算规则应结给经营主体的金额 | 渠道结算、对账核销和可分账判断 |
+| 平台手续费 | 平台针对团购券销售或核销收取的手续费、佣金或服务费 | 渠道费用、成本和结算差额分析 |
+
+上述金额可能不相等，不能使用单一“券金额”字段代替。
+
+团购券相关报表必须明确使用哪一种金额口径：
+
+- 订单与支付构成报表使用团购券核销金额。
+- 用户购买和营销分析使用团购券购买金额。
+- 商品价值和活动分析使用团购券券面金额。
+- 平台结算和对账报表使用平台应结算金额。
+- 渠道费用报表使用平台手续费。
+
+私域现金券、优惠券等其他券类也应根据业务性质区分券面、核销、承担和结算金额，但不直接套用团购券购买金额和平台应结算金额口径。
+
+### 5.6 储值扣减金额
+
+用户使用会员储值余额支付订单时，从储值账户扣减的金额。
+
+储值扣减属于内部账户权益变化，不应直接等同于当期外部渠道资金入账。对账系统需要同时完成两类核对：
+
+1. 储值消费核对：将订单支付明细中的储值扣减金额与会员储值账户流水进行核对。
+2. 储值资金入账追溯：追溯储值金额对应的资金入账记录，验证储值资金来源和入账情况。
+
+储值资金入账数据由分账系统提供。对账系统不负责生成储值资金入账结果，只负责接收、关联和追溯。
+
+储值相关对象至少包括：
+
+- 储值账户。
+- 储值充值流水。
+- 储值资金入账记录。
+- 储值消费扣减流水。
+- 储值退款或退回流水。
+- 关联业务订单和支付明细。
+
+建议核对关系：
+
+```text
+订单储值支付明细金额 = 储值账户消费扣减流水金额
+```
+
+```text
+储值充值或资金归集金额 = 分账系统提供的储值资金入账金额
+```
+
+### 5.7 现金支付与门店现金账户
+
+#### 5.7.1 现金支付
+
+现金支付是用户将现金交付给门店，由营业员或店长收取并确认订单支付完成的支付方式。
+
+现金支付需要作为独立支付明细纳入订单支付平衡：
+
+```text
+订单现金支付明细金额 = 门店现金账户收款流水金额
+```
+
+现金支付不能在订单收款后直接视为完成最终渠道结算。系统需要继续追踪门店现金的汇缴过程。
+
+#### 5.7.2 门店现金账户
+
+每个门店需要建立独立的门店现金账户，用于记录门店应持有和应汇缴的现金余额。
+
+门店现金账户至少包括以下流水类型：
+
+- 用户现金支付收款。
+- 现金退款支出。
+- 现金汇缴支出。
+- 现金盘盈。
+- 现金盘亏。
+- 经授权的其他现金调整。
+
+建议余额公式：
+
+```text
+期末现金余额
+= 期初现金余额
++ 用户现金支付收款
++ 现金盘盈及其他现金增加
+- 现金退款支出
+- 现金汇缴支出
+- 现金盘亏及其他现金减少
+```
+
+门店现金余额表示门店尚未完成汇缴、理论上应持有的现金金额。
+
+#### 5.7.3 现金汇缴
+
+营业员或店长每日通过微信、支付宝、银行卡或其他线上支付方式，合并汇缴当日或指定期间收取的现金。
+
+现金汇缴需要形成独立的现金汇缴批次，不得作为新的业务订单或用户支付重复计入订单收入。
+
+现金汇缴批次至少需要记录：
+
+- 门店。
+- 汇缴日期和时间。
+- 汇缴人员。
+- 汇缴覆盖的现金收款流水。
+- 汇缴覆盖的现金退款和现金调整。
+- 应汇缴金额。
+- 实际汇缴金额。
+- 汇缴支付渠道。
+- 汇缴渠道流水号。
+- 汇缴状态。
+- 汇缴差异金额。
+
+建议核对关系：
+
+```text
+现金汇缴批次应汇缴金额
+= 批次覆盖的现金收款金额
+- 批次覆盖的现金退款金额
++/- 批次覆盖的现金调整金额
+```
+
+```text
+现金汇缴批次实际汇缴金额 = 汇缴线上支付交易金额
+```
+
+现金支付的渠道结算采用两阶段核销：
+
+1. 订单现金支付明细与门店现金账户收款流水核销。
+2. 现金汇缴批次与营业员或店长的线上汇缴支付交易及渠道账单核销。
+
+完成第二阶段核销后，对应现金金额才视为完成渠道结算并可按规则进入分账。分账完成后的银行汇总入账结果，由分账系统统一反馈给对账系统进行后置验证。
+
+#### 5.7.4 线上付款现金退款
+
+订单原支付方式为微信、支付宝等线上支付时，允许门店使用现金向用户退款。
+
+该场景属于跨支付方式退款，需要同时记录：
+
+- 原订单和原线上支付明细。
+- 业务退款金额。
+- 实际现金退款金额。
+- 门店现金账户退款支出流水。
+- 退款操作人和退款时间。
+- 原线上渠道是否同步退款。
+
+如果原线上渠道未执行退款：
+
+- 不生成原渠道退款成功记录。
+- 现金退款金额从门店现金余额中扣减。
+- 原线上支付结算保持原有状态。
+- 对账系统通过退款明细和退款流水解释订单退款与原渠道账单之间的差异。
+
+如果原线上渠道后续又发生退款，需要识别重复退款风险并产生差异。
+
+#### 5.7.5 现金差异
+
+现金相关差异至少包括：
+
+- 现金订单未生成现金账户收款流水。
+- 现金账户收款流水无对应订单。
+- 应汇缴金额与实际汇缴金额不一致。
+- 现金汇缴支付交易不存在或失败。
+- 现金退款流水无对应业务退款明细。
+- 线上渠道退款与现金退款重复发生。
+- 门店现金余额为负数。
+- 现金盘盈或盘亏未说明。
+
+### 5.8 支付总金额
+
+一笔订单所有有效支付明细金额的合计。
+
+建议公式：
+
+```text
+支付总金额 = 用户线上实付金额 + 现金支付金额
+             + 平台优惠券核销金额
+             + 团购券核销金额 + 其他券核销金额
+             + 储值扣减金额 + 其他有效支付或权益抵扣金额
+```
+
+支付总金额应与订单应收金额保持平衡；不平衡时产生订单支付构成差异。
+
+## 6. 优惠与补贴术语
+
+### 6.1 优惠
+
+使用户应付金额减少的业务让利。
+
+优惠需要记录：
+
+- 优惠类型。
+- 优惠金额。
+- 承担方。
+- 关联活动。
+- 关联订单或支付明细。
+
+### 6.2 补贴
+
+平台、品牌或其他主体为了支持交易，向门店、经营主体或用户承担的金额。
+
+补贴需要区分：
+
+- 用户侧补贴：直接减少用户支付金额。
+- 商家侧补贴：渠道结算时补给商家。
+- 营销费用补贴：用于冲抵平台或品牌营销费用。
+
+### 6.3 优惠承担金额
+
+由特定主体承担的优惠金额。
+
+优惠承担方至少包括：
+
+- 平台。
+- 品牌总部。
+- 门店。
+- 加盟商。
+- 其他合作方。
+
+优惠承担金额用于解释订单成交金额、渠道结算金额和可分账金额之间的关系。
+
+## 7. 渠道账单相关术语
+
+### 7.1 渠道交易金额
+
+渠道账单记录的交易金额。该金额用于描述渠道侧确认的交易规模，不一定等于最终结算金额。
+
+### 7.2 渠道退款金额
+
+渠道账单记录的退款金额，包括全额退款和部分退款。
+
+### 7.3 渠道费用金额
+
+渠道在结算过程中收取或扣减的费用合计。
+
+常见费用：
+
+- 支付手续费。
+- 平台佣金。
+- 服务费。
+- 配送费。
+- 包装费。
+- 达人佣金。
+- 营销费用。
+- 平台处罚。
+
+费用项需要独立记录，不能只保留扣费后的净额。
+
+正常费用按照渠道账单实际值认可。对账系统不以合同费率或内部测算金额替代渠道账单实际费用，但可以配置费用预期值和费用容差，用于识别费用异常。
+
+费用判断规则：
+
+```text
+费用偏差金额 = 渠道账单实际费用金额 - 预期费用金额
+```
+
+```text
+当 |费用偏差金额| <= 配置的费用容差值时，费用状态为正常
+```
+
+```text
+当 |费用偏差金额| > 配置的费用容差值时，生成费用异常
+```
+
+费用容差应支持按品牌、渠道、业务类型、费用项和生效时间配置。容差仅用于异常识别，不修改渠道账单实际费用金额。
+
+### 7.4 渠道补贴金额
+
+渠道或平台在结算中向商家增加的补贴金额。
+
+对账系统只记录和使用渠道账单中列示的补贴金额，作为渠道结算金额的组成项，不独立判断平台补贴资金是否已经到账。
+
+平台补贴是否实际到账属于分账及资金入账环节，由分账系统判断并在分账完成后将银行汇总入账结果反馈给对账系统。对账系统根据分账入账反馈进行后置展示和验证。
+
+### 7.5 渠道结算单
+
+渠道针对一个结算主体、商户号或结算周期确认的应结算结果。渠道结算单汇总渠道账单明细、退款、费用、补贴和调整项，是判断“结算了多少”的直接依据。
+
+渠道账单明细与渠道结算单通过渠道结算归集明细建立多对多金额关系，以支持部分结算和分批结算。
+
+### 7.6 渠道结算批次
+
+渠道实际发起的一次结算处理，可以包含一张或多张渠道结算单。渠道结算批次用于记录“什么时候结算”，包括计划结算日期、实际结算日期、批次金额和批次状态。
+
+### 7.7 渠道结算周期规则
+
+三方平台结算周期支持 D+N 和 T+N 两类表达：
+
+| 周期类型 | 基准日期 | 适用说明 |
+| --- | --- | --- |
+| D+N | 订单所属营业日期 D | 从门店业务营业日开始计算第 N 个结算日 |
+| T+N | 平台定义的结算触发日期 T | T 可以是支付成功日、券核销日、订单完成日或平台确认日，必须由平台规则明确 |
+
+D 和 T 的定义不能由系统写死。每条结算周期规则至少需要配置：
+
+- 客户企业和品牌。
+- 三方平台或结算渠道。
+- 商户号或结算主体，可选。
+- 业务类型和支付方式，可选。
+- 周期类型：D+N 或 T+N。
+- T 的触发事件类型。
+- N 值。
+- 按自然日或工作日计算。
+- 日切截点和时区。
+- 节假日日历及顺延规则。
+- 结算宽限期。
+- 生效日期、失效日期和状态。
+
+同一平台在不同品牌、商户号、业务类型或生效期间可以使用不同结算周期。系统应根据业务发生时有效且范围最精确的规则计算预期结算日。
+
+品牌是结算周期规则的必选隔离维度，不允许使用同一平台下其他品牌的规则作为兜底。同一品牌和平台内，按商户号、结算主体、业务类型和支付方式匹配更精确的规则；同一优先级存在多条有效规则时必须转配置异常。
+
+```text
+预期结算日
+= 结算基准日期 D 或 T
++ N 个自然日或工作日
++ 节假日顺延
+```
+
+宽限期结束前仍属于正常待结算；超过预期结算日及宽限期仍无有效结算记录时，才生成结算超期差异。
+
+### 7.8 渠道结算金额
+
+渠道按照结算规则计算出的本次应结金额。
+
+建议公式：
+
+```text
+渠道结算金额
+= 渠道交易金额
+- 渠道退款金额
+- 渠道费用金额
++ 渠道补贴金额
++/- 其他渠道调整金额
+```
+
+不同渠道的字段和公式可能不同，但标准化后必须能够映射到上述组成。
+
+### 7.9 渠道实收金额
+
+对账系统从渠道结算账单确认的实际应收结算金额。
+
+在大多数场景下：
+
+```text
+渠道实收金额 = 渠道结算金额
+```
+
+“实收”在这里表示渠道账单已确认的净结算金额，不代表资金已经进入银行账户。
+
+为避免歧义，产品页面应优先展示“渠道结算金额”；只有在口径说明明确时使用“渠道实收金额”。
+
+### 7.10 非订单级结算调整项
+
+非订单级结算调整项是渠道或平台在结算过程中产生，但无法直接归属于单笔订单或支付明细的增加或扣减金额。
+
+常见类型包括：
+
+- 平台处罚。
+- 平台赔付。
+- 批量奖励。
+- 批量补扣款。
+- 账期调整。
+- 其他非订单级结算调整。
+
+非订单级结算调整项需要作为独立对象记录，不得伪造业务订单，也不得为了平账强制平均分摊到支付明细。
+
+调整项至少需要记录：
+
+- 调整项类型。
+- 调整方向：增加结算或减少结算。
+- 原始金额。
+- 来源平台。
+- 结算批次。
+- 调整原因。
+- 可识别的责任主体。
+- 可识别的归属门店。
+- 关联订单或支付明细。
+- 分摊规则。
+- 分摊结果。
+- 确认状态。
+- 是否阻断分账。
+
+归属层级优先级：
+
+```text
+支付明细 → 订单 → 门店 → 加盟商或经营主体 → 品牌总部 → 待确认
+```
+
+处理原则：
+
+- 能准确关联支付明细时，作为支付明细级调整项，影响对应支付明细可分账金额。
+- 能关联订单但不能关联具体支付明细时，先保留为订单级调整项，后续按明确规则分摊。
+- 能关联门店但不能关联订单时，保留为门店级调整项，不强制回写每条支付明细。
+- 涉及多个门店时，优先使用平台提供的门店金额，其次使用明确业务责任比例、相关业务收入占比、相关订单量占比或人工确认比例。
+- 只能关联加盟商或经营主体时，先保留在对应主体层级，不自动向下分摊。
+- 无法判断归属时，进入待归属状态，未确认前不得随意进入门店或支付明细分账。
+
+支付明细级调整关系：
+
+```text
+支付明细可分账金额
+= 支付明细确认金额
+- 支付明细级扣减调整金额
++ 支付明细级增加调整金额
+```
+
+门店级调整关系：
+
+```text
+门店最终可结算金额
+= 门店下支付明细可分账金额合计
+- 门店级扣减调整金额
++ 门店级增加调整金额
+```
+
+对账系统向分账系统输出时，需要同时输出：
+
+- 支付明细可分账结果。
+- 非订单级结算调整项及其归属、分摊和确认状态。
+
+分账系统根据支付明细结果和已确认调整项执行最终分账。
+
+## 8. 分账后银行入账相关术语
+
+### 8.1 分账入账反馈
+
+分账系统完成分账后，将银行汇总入账结果及其与分账结果的关联关系反馈给对账系统。
+
+对账系统不负责执行分账或生成银行入账记录，只负责接收、关联、展示和验证分账后的入账结果。
+
+分账入账反馈至少需要包括：
+
+- 分账批次号。
+- 入账批次号。
+- 收款主体。
+- 收款银行账户。
+- 银行入账时间。
+- 银行入账金额。
+- 入账状态。
+- 关联分账结果。
+- 关联可分账结果或原始订单范围。
+- 失败或退回原因。
+
+### 8.2 银行汇总入账
+
+银行原则上按分账批次、收款主体或资金归集规则汇总入账。一笔银行入账可以对应多笔分账结果、多笔订单和多个支付明细。
+
+因此，银行入账不要求与单笔订单或单笔渠道结算记录一对一匹配。
+
+分账结果与银行入账反馈之间通过“分账结果入账关联明细”记录关联金额。一笔分账结果可以分多次入账，一笔银行入账也可以覆盖多笔分账结果。
+
+### 8.3 银行入账金额
+
+银行入账流水记录的实际到账金额。
+
+银行入账金额用于验证分账系统完成的资金处理是否真实进入指定账户。
+
+### 8.4 待入账金额
+
+分账已经完成，但尚未收到成功银行入账反馈的金额。
+
+建议公式：
+
+```text
+待入账金额 = 已完成分账金额 - 已反馈成功入账金额
+```
+
+### 8.5 入账验证关系
+
+对账系统按分账批次或入账批次进行汇总验证：
+
+```text
+分账批次应入账金额
+= 关联分账结果应入账金额合计
+```
+
+```text
+入账差异金额
+= 银行实际入账金额
+- 分账批次应入账金额
+```
+
+如果一个分账批次分多次入账，需要累计全部有效入账反馈后再判断批次是否完成入账。
+
+任一分账结果的累计有效入账关联金额不得超过该分账结果的应入账金额。
+
+## 9. 退款相关术语
+
+### 9.1 退款单
+
+退款单记录业务系统发起的一次退款请求，必须关联原业务订单。一笔订单可以存在多张退款单。
+
+### 9.2 退款明细
+
+退款明细将退款单金额拆分到原支付明细，是退款对账的最小业务对象。组合支付订单发生退款时，必须按原支付构成拆分，不得只保留订单级退款总额。
+
+退款明细需要区分业务退款金额、原支付明细、计划退款方式、是否原路退款和退款状态。
+
+### 9.3 退款流水
+
+退款流水记录支付渠道、券账户、储值账户或现金账户实际执行的退款或权益退回结果。一条退款明细可以对应多条退款流水，以支持部分退款、分次退款、失败重试和跨支付方式退款。
+
+### 9.4 业务退款金额
+
+退款明细中业务侧确认应退给用户的金额。
+
+### 9.5 支付退款金额
+
+有效退款流水中实际完成的资金退款或权益退回金额。
+
+### 9.6 退款完成
+
+退款明细的有效退款流水金额合计等于业务退款金额，且不存在待确认的重复退款风险。
+
+## 10. 核销与差异术语
+
+### 10.1 核销
+
+将订单或支付明细的应核对金额与渠道账单明细、权益流水或现金账户流水建立匹配关系，或将退款明细与退款流水建立匹配关系，并记录本次匹配金额的过程。
+
+银行入账属于分账后的后置验证，不与订单核销混为同一层级。
+
+### 10.2 核销金额
+
+一条核销记录实际用于冲减应核对金额或待核销金额的金额。
+
+### 10.3 已核销金额
+
+订单、支付明细或账单已经通过有效核销记录匹配完成的金额合计。
+
+### 10.4 未核销金额
+
+尚未完成匹配的应核对金额。
+
+建议公式：
+
+```text
+未核销金额 = 应核对金额 - 已核销金额
+```
+
+### 10.5 差异
+
+订单、支付明细、渠道账单明细、渠道结算单、退款明细、退款流水、分账结果或银行入账反馈之间存在无法自动解释的不一致。
+
+差异必须有明确的差异对象、差异类型、差异金额、责任部门和处理状态。
+
+### 10.6 差异金额
+
+无法通过正常业务规则、费用项、补贴或有效核销记录解释的金额。
+
+差异金额不应简单定义为订单应收金额减渠道结算金额，因为手续费、佣金、补贴和优惠承担可能是正常业务组成。
+
+费用与差异的分类边界：
+
+- 渠道账单已明确列示的费用，按渠道账单实际值计入正常费用。
+- 实际费用与预期费用的偏差在配置容差内，不生成费用异常。
+- 实际费用与预期费用的偏差超过配置容差，生成费用异常。
+- 完成退款、费用、补贴和其他合法调整归因后仍无法解释的金额，生成未解释差异。
+- 平台补贴是否实际到账不在订单对账阶段判断，不作为订单对账差异。
+
+## 11. 状态术语
+
+### 11.1 已支付
+
+订单需要用户或权益承担的支付金额已经由有效支付明细覆盖。
+
+已支付不代表渠道已经结算。
+
+### 11.2 已结算
+
+渠道已经生成有效渠道结算单或渠道结算批次，且通过渠道结算归集明细可以追溯到对应渠道账单明细、支付明细或业务订单。
+
+已结算不代表资金已经银行入账。
+
+### 11.3 已入账
+
+分账结果已经收到分账系统反馈的成功银行入账记录，并完成汇总金额验证。
+
+### 11.4 已核销
+
+订单或支付明细的应核对金额已经通过有效账单或权益流水完成匹配，且未核销金额为零。
+
+已核销不等同于差异已关闭；存在已核销但费用或归属仍需确认的场景。
+
+已核销也不要求已经银行入账。订单可以在完成对账确认后先进入分账，银行入账结果由分账系统在分账完成后反馈。
+
+### 11.5 未结算
+
+订单或支付明细已经发生，但在预期结算时间内尚未匹配到有效渠道结算记录。
+
+未结算需要结合渠道结算周期判断，不能在订单发生后立即认定为异常。
+
+## 12. 分账准备术语
+
+### 12.1 可分账金额
+
+对账系统确认可以输出给分账系统作为分账计算输入的金额。
+
+可分账金额按支付明细分别确定，不直接以订单总金额一次性判断。
+
+每条支付明细需要独立判断：
+
+- 是否完成对应渠道账单、权益流水或现金汇缴核销。
+- 是否已经扣除或处理对应退款。
+- 是否存在阻断型差异。
+- 支付明细的门店、经营主体和各结算主体归属是否明确。
+- 是否被人工冻结或暂缓分账。
+
+支付明细可分账金额建议口径：
+
+```text
+支付明细可分账金额
+= 支付明细已完成对账确认且未被阻断的确认金额
+```
+
+订单可分账金额由订单下各支付明细汇总：
+
+```text
+订单可分账金额 = 订单下各支付明细可分账金额合计
+```
+
+同一订单可以出现：
+
+- 全部支付明细可分账。
+- 部分支付明细可分账。
+- 全部支付明细不可分账。
+- 部分支付明细暂缓分账。
+
+已满足条件的支付明细可以先输出给分账系统；存在未核销、退款待确认或阻断型差异的支付明细单独阻断，原则上不阻断同一订单中其他已确认支付明细。
+
+不同支付类型的可分账金额基数可能不同，例如在线支付、团购券、平台优惠券、储值和现金汇缴需要分别依据对应的核销结果确定，具体计算规则在后续《对账匹配与核销规则》和《费用项、结算调整项与优惠承担规则》中定义。
+
+同一支付明细允许拆分到多个结算主体，但支付明细可分账金额仍只计算一次。支付明细各结算主体归属金额合计必须等于该支付明细确认金额，分账系统基于结算主体关系和分账规则生成最终分账结果。
+
+结算主体归属金额以支付明细确认金额为基准，不因支付明细级结算调整项直接改写；调整项作为独立输入影响可分账金额。
+
+可分账金额不包含品牌方、加盟商、门店等参与方的具体分配结果。
+
+### 12.2 不可分账
+
+支付明细尚未满足分账前置条件，例如：
+
+- 未完成核销。
+- 存在阻断型差异。
+- 退款状态未确认。
+- 归属关系不明确。
+- 被人工冻结。
+
+### 12.3 暂缓分账
+
+支付明细已具备部分对账基础，但因争议、退款、异常调查或人工控制暂时不输出分账。
+
+## 13. 核心指标公式
+
+| 指标 | 建议公式 |
+| --- | --- |
+| 订单应收总额 | 有效订单的订单应收金额合计 |
+| 支付总额 | 有效支付明细金额合计 |
+| 渠道结算总额 | 有效渠道结算金额合计 |
+| 银行入账总额 | 分账系统反馈的成功银行入账金额合计 |
+| 未结算金额 | 超过预期结算时间仍未匹配结算记录的应核对金额 |
+| 未核销金额 | 应核对金额减已核销金额 |
+| 差异金额 | 无法被正常规则、费用、补贴和核销解释的金额 |
+| 支付明细可分账金额 | 单条支付明细已确认且未被阻断的金额 |
+| 订单可分账金额 | 订单下各支付明细可分账金额合计 |
+| 自动核销率 | 自动核销成功记录数 / 应核销记录数 |
+| 差异率 | 差异记录数 / 应核销记录数，或差异金额 / 应核对金额 |
+| 差异关闭率 | 已关闭差异数 / 已产生差异数 |
+| 渠道实际结算周期 | 实际结算日期减对应结算周期规则的基准日期 |
+| 结算超期天数 | 实际结算日期或当前日期减预期结算日及宽限期；未超期时为 0 |
+| 分账入账周期 | 银行入账时间减分账完成时间 |
+| 门店现金余额 | 期初现金余额加现金收款及增加项，减现金退款、汇缴及减少项 |
+| 待汇缴现金金额 | 已进入门店现金账户但尚未纳入有效汇缴批次的现金金额 |
+| 现金汇缴差异金额 | 现金汇缴批次实际汇缴金额减应汇缴金额 |
+
+## 14. 关键平衡关系
+
+### 14.1 订单与支付平衡
+
+```text
+订单应收金额 = 有效支付明细应核对金额合计
+```
+
+### 14.2 渠道结算组成
+
+```text
+渠道结算金额
+= 渠道交易金额
+- 渠道退款金额
+- 渠道费用金额
++ 渠道补贴金额
++/- 其他渠道调整金额
+```
+
+### 14.3 分账结果与银行入账
+
+```text
+已完成分账金额 = 已反馈成功入账金额 + 待入账金额
+```
+
+### 14.4 对账核销平衡
+
+```text
+应核对金额 = 已核销金额 + 未核销金额
+```
+
+### 14.5 门店现金余额平衡
+
+```text
+期末现金余额
+= 期初现金余额
++ 现金收款金额
++ 现金增加调整金额
+- 现金退款金额
+- 已完成现金汇缴金额
+- 现金减少调整金额
+```
+
+### 14.6 现金汇缴平衡
+
+```text
+现金汇缴差异金额 = 实际汇缴金额 - 应汇缴金额
+```
+
+现金汇缴差异金额为零时，表示该批次现金汇缴金额平衡；非零时需要生成现金汇缴差异。
+
+## 15. 待评估事项
+
+当前核心业务术语与指标口径中的待评估事项已完成确认。
+
+## 16. 下一步
+
+本文件评估确认后，启动：
+
+- `07-业务对象与业务关系.md`
+- `08-连锁餐饮对账场景清单.md`
+
+后续文档必须引用本文件中的统一术语，不再重复定义不同口径。
diff --git a/10-产品线/连锁业务对账系统/07-业务对象与业务关系.md b/10-产品线/连锁业务对账系统/07-业务对象与业务关系.md
new file mode 100644
index 0000000..9c1fbc7
--- /dev/null
+++ b/10-产品线/连锁业务对账系统/07-业务对象与业务关系.md
@@ -0,0 +1,528 @@
+# 连锁业务对账系统业务对象与业务关系
+
+## 1. 文档目的
+
+本文档用于定义连锁业务对账系统中的核心业务对象及其关系，作为业务场景、数据模型、权限、对账规则和系统集成设计的基础。
+
+本文件已通过 P1-02 业务对象与业务关系评审。对象字段、业务唯一键和状态机将在标准数据模型详细设计阶段进一步展开。
+
+## 2. 对象分层
+
+| 对象层级 | 核心对象 | 作用 |
+| --- | --- | --- |
+| 组织经营层 | 客户企业、品牌、区域、加盟商、门店、门店经营主体关系、经营主体 | 确定租户隔离、业务归属和数据权限 |
+| 资金结算层 | 结算主体、支付明细结算主体关系、商户号、银行账户、门店现金账户 | 确定资金结算和入账归属 |
+| 业务交易层 | 业务类型、下单方式、订单来源、履约方式、业务订单、退款单、退款明细、退款流水 | 记录业务发生和退款事实 |
+| 支付权益层 | 支付明细、团购券、平台优惠券、储值账户 | 记录订单支付构成 |
+| 渠道账单层 | 结算渠道、渠道结算周期规则、渠道门店、门店映射关系、渠道账单明细、渠道结算单、渠道结算归集明细、渠道结算批次、费用项、结算调整项 | 记录渠道交易、费用和结算事实 |
+| 对账核销层 | 核销记录、差异记录、可分账结果 | 记录对账过程和输出结果 |
+| 分账反馈层 | 分账结果、分账入账反馈、分账结果入账关联明细 | 记录分账系统返回的后置结果 |
+
+## 3. 组织经营对象
+
+### 3.1 客户企业
+
+客户企业是使用对账系统并承担数据隔离责任的租户主体。
+
+一个客户企业可以管理一个或多个品牌。客户扩展字典、渠道接入配置、权限范围和业务数据均需要归属于客户企业；所有客户级编码必须在客户企业范围内唯一。
+
+### 3.2 品牌
+
+品牌是连锁经营业务的管理和产品归属对象。
+
+一个客户企业可以管理一个或多个品牌。品牌下可以包含区域、加盟商和门店。
+
+### 3.3 区域
+
+区域是品牌对门店进行运营管理和数据统计的组织维度，可以按大区、省、市或企业自定义区域划分。
+
+区域不是必然的资金结算主体。
+
+### 3.4 加盟商
+
+加盟商是管理一家或多家加盟门店的经营管理对象。
+
+加盟商在对账系统中原则上是其旗下门店的汇总维度，不替代门店作为订单、支付和对账明细的归属对象。
+
+### 3.5 门店
+
+门店是连锁业务对账的核心经营和数据落地对象。
+
+订单、支付明细、退款、券核销、现金账户、渠道门店映射和差异原则上都需要归属到门店。
+
+门店经营类型固定为四类：
+
+- 直营门店。
+- 加盟门店。
+- 联营门店。
+- 托管门店。
+
+经营类型只描述门店的经营合作关系，不承载门店形态、收银、结算、收益分配和管理责任等其他语义。
+
+### 3.6 门店经营属性
+
+门店需要维护以下相互独立的经营属性：
+
+| 属性 | 标准分类 | 对账用途 |
+| --- | --- | --- |
+| 门店形态 | 标准店、店中店、档口店、快闪店、云店 | 支持门店经营分析及识别无独立经营场所的门店 |
+| 收银模式 | 门店独立收银、品牌统一收银、平台直接收款 | 判断订单和支付数据来源、收款链路及现金账户责任 |
+| 结算模式 | 门店自结、总部代收代结、多主体结算 | 判断渠道账单、结算主体和分账前置归属 |
+| 收益规则 | 自营收益、固定管理费、营业额分成、毛利分成、利润分成 | 作为合同范围内的收益规则，为分账系统提供规则匹配依据 |
+| 管理归属 | 总部管理、区域管理、加盟商管理、第三方托管 | 确定异常处理、业务确认和数据权限责任 |
+
+门店形态原则上是门店级基础分类。收银模式和结算模式可以按门店、渠道及业务类型配置；收益规则和管理归属通过独立配置关系按门店及合同维护。同一门店允许在不同渠道、业务类型或合同范围内采用不同配置。
+
+上述属性需要记录适用范围、生效日期、失效日期、状态和变更原因。历史订单、支付明细、账单、核销及分账输出必须按照业务发生日期使用当时有效的配置，不得使用当前配置覆盖历史结果。
+
+### 3.7 经营主体
+
+经营主体是依法或按合同实际承担门店经营责任的法人、个体工商户或其他主体。
+
+一个经营主体可以经营一家或多家门店。同一家门店在同一自然日只能对应一个经营主体。
+
+经营主体与品牌、加盟商不必一一对应。
+
+### 3.8 门店经营主体关系
+
+门店经营主体关系用于记录门店在指定自然日由哪个经营主体承担经营责任，至少包括门店、经营主体、生效日期、失效日期、状态、变更原因和审计信息。
+
+门店与经营主体的关系需要按自然日维护有效期：
+
+- 关系生效时间精度至少到自然日。
+- 同一门店的经营主体关系在同一自然日内不得重叠。
+- 门店经营主体发生变更时，新关系从下一自然日开始生效。
+- 历史订单、支付明细、账单和差异按照业务发生日期关联当日经营主体。
+- 经营主体变更不得覆盖历史业务归属。
+
+业务约束为：
+
+```text
+客户企业 + 门店 + 自然日，只能匹配一条有效的门店经营主体关系
+```
+
+## 4. 资金结算对象
+
+### 4.1 结算主体
+
+结算主体是与支付渠道、平台或分账系统发生资金结算的主体。
+
+结算主体可能是：
+
+- 品牌总部。
+- 区域公司。
+- 加盟商经营主体。
+- 门店经营主体。
+- 其他经授权主体。
+
+经营主体与结算主体可以相同，也可以不同。
+
+### 4.2 支付明细结算主体关系
+
+同一支付明细允许拆分到多个结算主体。支付明细与结算主体之间为多对多关系，通过“支付明细结算主体关系”实体维护。
+
+该关系描述支付明细在业务和渠道上的结算归属，不等同于分账系统最终计算的分账结果。
+
+关系实体至少需要记录：
+
+- 支付明细。
+- 结算主体。
+- 结算归属类型。
+- 结算归属金额。
+- 结算归属比例。
+- 归属依据。
+- 来源系统。
+- 生效状态。
+- 确认状态。
+- 确认人和确认时间。
+
+结算归属金额需要满足：
+
+```text
+支付明细确认金额
+= 该支付明细对应各结算主体的结算归属金额合计
+```
+
+如果结算主体关系尚未确认，支付明细不能进入可分账状态。
+
+结算归属金额以支付明细确认金额为基准，不以扣除结算调整项后的支付明细可分账金额为基准。结算调整项另行记录，最终参与方收益分配由分账系统计算。
+
+分账系统接收支付明细可分账结果及结算主体关系后，再根据分账规则生成最终分账结果。
+
+### 4.3 商户号
+
+商户号是支付渠道或业务平台识别结算商户的账号。
+
+一个结算主体可以拥有多个商户号；一个商户号可以服务一家或多家门店。商户号与门店之间不直接固化关联，需要通过门店映射关系实体维护。
+
+### 4.4 银行账户
+
+银行账户是分账后汇总资金的实际收款账户。
+
+银行账户归属于收款主体。银行入账结果由分账系统在分账完成后反馈给对账系统。
+
+### 4.5 门店现金账户
+
+门店现金账户是每个门店用于记录现金收款、现金退款、现金汇缴和现金调整的内部账户。
+
+每个门店原则上至少维护一个有效现金账户。门店现金账户不是银行账户，也不是支付渠道商户号。
+
+## 5. 业务交易对象
+
+### 5.1 业务类型
+
+业务类型描述订单所处的经营场景。
+
+平台标准业务类型包括：
+
+- 堂食。
+- 外卖。
+- 团购。
+- 电商。
+- 线下零售。
+
+一笔订单原则上对应一个主要业务类型。
+
+业务类型采用“平台标准字典 + 客户扩展字典”管理。客户可以根据自身业态新增业务类型，但客户扩展编码必须在客户企业范围内唯一，并明确映射到平台标准业务分类，以保证跨品牌和跨客户统计口径一致。
+
+### 5.2 下单方式
+
+下单方式描述用户或营业人员通过什么交互入口创建订单，例如收银台开单、扫码点餐、小程序下单、平台下单和人工录单。
+
+下单方式允许客户扩展，但不得与业务类型、订单来源或支付方式混用。
+
+### 5.3 订单来源
+
+订单来源是生成业务订单的系统或平台，例如：
+
+- 收银系统。
+- 扫码点餐系统。
+- 外卖平台。
+- 团购平台。
+- 小程序商城。
+- 私域商城。
+
+业务类型与订单来源不是同一概念。相同业务类型可以来自不同订单来源。
+
+订单来源采用“平台标准字典 + 客户扩展字典”管理。客户可以新增自有收银系统、私域平台或其他业务系统作为订单来源，并维护来源编码、来源名称、来源类型和生效状态。
+
+### 5.4 履约方式
+
+履约方式描述订单如何交付，例如到店消费、门店自提、门店配送和平台配送。
+
+相同业务类型可以存在不同履约方式，例如外卖订单可以由门店配送或平台配送。
+
+业务类型、下单方式、订单来源和履约方式字典均需要保留创建主体、适用客户、生效时间、失效时间和状态。已被订单使用的字典值不得删除或修改编码，只允许调整展示名称或停用；停用仅限制新订单使用，不影响历史订单查询、对账和报表。
+
+### 5.5 业务订单
+
+业务订单记录一次交易事实，归属到客户企业、品牌、门店、经营主体、业务类型、下单方式、订单来源和履约方式。
+
+一笔订单可以对应多条支付明细和多张退款单。
+
+### 5.6 退款单
+
+退款单描述业务侧发起的一次退款请求，必须关联原业务订单。一笔业务订单可以发生多次退款。
+
+### 5.7 退款明细
+
+退款明细是退款分配和退款对账的最小业务对象，记录本次退款金额应如何对应原支付明细以及计划采用的退款方式。
+
+组合支付退款必须拆分为多条退款明细。每条退款明细至少关联退款单和原支付明细，并记录业务退款金额、计划退款方式及是否原路退款。
+
+### 5.8 退款流水
+
+退款流水记录支付渠道、券账户、储值账户或门店现金账户实际执行的退款或权益退回结果。
+
+一条退款明细可以对应一条或多条退款流水，以支持分次退款、失败重试和跨支付方式退款；一条退款流水只能归属于一条退款明细。退款完成以退款明细金额被有效退款流水全部覆盖为准。
+
+## 6. 支付权益对象
+
+### 6.1 支付明细
+
+支付明细是订单支付构成和可分账判断的最小对象。
+
+一笔订单可以包含在线支付、现金支付、团购券、平台优惠券、私域券、储值等多条支付明细。
+
+可分账结果以支付明细为最小输出粒度。
+
+### 6.2 团购券
+
+团购券由团购平台发行或销售，在门店核销后参与订单支付。
+
+团购券需要记录券面金额、购买金额、核销金额、平台应结算金额和平台手续费。
+
+### 6.3 平台优惠券
+
+平台优惠券作为独立支付明细，关联来源平台、活动、订单、核销金额和承担方。
+
+### 6.4 储值账户
+
+储值账户记录会员储值余额及其充值、消费、退款和调整流水。
+
+储值消费流水与订单支付明细核对；储值资金入账由分账系统提供并反馈给对账系统追溯。
+
+## 7. 渠道账单对象
+
+### 7.1 结算渠道
+
+结算渠道是产生交易账单或结算账单的支付渠道、业务平台或资金处理方。
+
+常见结算渠道包括：
+
+- 微信。
+- 支付宝。
+- 银联。
+- 聚合支付。
+- 美团。
+- 饿了么。
+- 抖音。
+- 私域支付渠道。
+
+### 7.2 渠道门店
+
+渠道门店是外部平台对门店的标识。
+
+渠道门店本身只描述外部平台门店，不直接代表系统门店。渠道门店与系统门店的对应关系由门店映射关系实体维护。
+
+### 7.3 渠道结算周期规则
+
+渠道结算周期规则描述三方平台在特定客户企业和品牌下采用的 D+N 或 T+N 结算规则。
+
+规则至少需要记录客户企业、品牌、结算渠道、可选商户号、可选结算主体、可选业务类型、可选支付方式、周期类型、基准事件、N 值、自然日或工作日、日切截点、时区、节假日顺延方式、宽限期和有效期。
+
+同一平台允许因品牌、商户号、业务类型或合同生效期不同而使用不同规则。系统按业务发生时有效且适用范围最精确的规则计算预期结算日；无法唯一匹配规则时生成结算周期配置差异，不自动选取。
+
+### 7.4 门店映射关系
+
+门店映射关系是连接系统门店、结算渠道、商户号和渠道门店的独立关系实体，用于判断订单、支付明细和渠道账单明细应归属到哪个系统门店。
+
+门店映射关系至少需要记录：
+
+- 系统门店。
+- 结算渠道。
+- 商户号。
+- 渠道门店。
+- 映射类型。
+- 生效时间。
+- 失效时间。
+- 映射状态。
+- 数据来源。
+- 创建方式。
+- 冲突原因和处理状态。
+- 确认人和确认时间。
+
+映射类型可以包括：
+
+- 商户号与系统门店映射。
+- 渠道门店与系统门店映射。
+- 商户号、渠道门店与系统门店组合映射。
+- 其他渠道标识与系统门店映射。
+
+门店映射关系需要支持：
+
+- 一个商户号对应多家系统门店。
+- 一家系统门店对应多个商户号。
+- 一个渠道门店对应一家系统门店。
+- 一家系统门店在不同渠道对应多个渠道门店。
+- 映射关系按有效期变更并保留历史。
+
+账单门店归属应按照账单发生时间匹配当时有效的门店映射关系，不能直接使用当前最新映射覆盖历史数据。
+
+无法匹配、同时匹配多个有效关系或映射关系冲突时，需要生成门店映射差异并全部转人工确认，不得按匹配优先级自动选择门店。
+
+人工确认完成前，相关订单、支付明细和渠道账单明细保持门店归属待确认状态，不得进入自动核销和可分账处理。人工确认时需要指定唯一系统门店，并记录确认人、确认时间、处理说明及所依据的业务凭证；确认结果仅在适用有效期内生效，历史数据仍按其发生时间对应的映射关系处理。
+
+### 7.5 渠道账单明细
+
+渠道账单明细记录渠道侧交易、退款、费用和补贴事实，是支付明细核销的主要外部明细依据。
+
+一条渠道账单明细可以关联一条或多条支付明细。
+
+渠道账单明细归属系统门店时，应通过门店映射关系进行解析。
+
+### 7.6 渠道结算单
+
+渠道结算单记录渠道针对一个结算主体、商户号或结算周期确认的应结算结果，至少包括结算单号、结算主体、商户号、结算周期、应结算金额、费用金额、调整金额和结算状态。
+
+一张渠道结算单可以汇总多条渠道账单明细；同一条渠道账单明细也可能因部分结算、分批结算而进入多张渠道结算单。
+
+### 7.7 渠道结算归集明细
+
+渠道结算归集明细记录渠道账单明细与渠道结算单之间的金额关系，至少包括渠道账单明细、渠道结算单、归集金额、归集类型和状态。
+
+渠道账单明细与渠道结算单之间为多对多关系。任一渠道账单明细的累计有效归集金额不得超过该明细的可结算金额；渠道结算单金额必须能够由有效归集明细、费用项和结算调整项解释。
+
+### 7.8 渠道结算批次
+
+渠道结算批次记录渠道实际发起的一次结算处理，可以包含一张或多张渠道结算单，并记录计划结算日期、实际结算日期、批次金额和批次状态。
+
+“已结算”以有效渠道结算单或结算批次为依据，不以银行入账为依据。
+
+### 7.9 费用项
+
+费用项是渠道账单明细或渠道结算单中可以按照正常业务规则识别的手续费、佣金、服务费、配送费、包装费、达人佣金等金额。
+
+正常费用按渠道账单明细或渠道结算单实际值认可。预期费用和费用容差用于识别费用异常，不修改实际费用。
+
+### 7.10 结算调整项
+
+结算调整项是渠道或平台在结算过程中产生，但不一定能够直接关联到单笔订单或支付明细的增加或扣减金额，例如平台处罚、平台赔付、批量奖励、批量补扣款和账期调整。
+
+结算调整项可以归属到：
+
+- 支付明细。
+- 订单。
+- 门店。
+- 加盟商。
+- 经营主体。
+- 品牌总部。
+- 待确认归属。
+
+结算调整项与品牌、加盟商、门店、经营主体、订单和支付明细之间均为可选关联，不应为了平账强制建立虚假订单级关系。
+
+结算调整项涉及多个门店时，需要生成独立分摊结果。分摊优先使用平台明细或明确业务规则，不默认平均分摊。
+
+## 8. 对账核销对象
+
+### 8.1 核销记录
+
+核销记录连接支付明细与渠道账单明细、权益流水或现金账户流水，也连接退款明细与退款流水。
+
+核销关系支持一对一、一对多和多对一。
+
+### 8.2 差异记录
+
+差异记录描述无法通过正常业务规则、费用、补贴和核销关系解释的问题。
+
+差异需要关联责任部门、处理状态和是否阻断支付明细分账。
+
+### 8.3 可分账结果
+
+可分账结果是对账系统输出给分账系统的标准对象。
+
+可分账结果以支付明细为最小粒度，订单级结果为支付明细结果汇总。
+
+### 8.4 结算调整项分摊结果
+
+结算调整项分摊结果记录一笔结算调整项在品牌、加盟商、门店、经营主体、订单或支付明细之间的分摊关系。
+
+分摊结果需要记录：
+
+- 调整项。
+- 分摊对象类型。
+- 分摊对象。
+- 分摊规则。
+- 分摊比例。
+- 分摊金额。
+- 确认状态。
+- 是否影响分账。
+
+未确认的分摊结果不得直接影响支付明细或门店的可结算金额。
+
+## 9. 分账反馈对象
+
+### 9.1 分账结果
+
+分账结果由分账系统生成，描述支付明细可分账金额及已确认结算调整项在参与方之间的分配结果。
+
+对账系统不计算分账结果，只接收分账状态、分账批次、分账金额、参与方和后续入账关联信息。
+
+### 9.2 分账入账反馈
+
+分账入账反馈由分账系统在分账完成后返回，描述分账批次的银行汇总入账结果。
+
+一笔入账可以关联多笔分账结果和多笔订单。
+
+### 9.3 分账结果入账关联明细
+
+分账结果入账关联明细记录分账结果与银行入账反馈之间的金额对应关系，至少包括分账结果、入账反馈、关联金额、关联状态和确认时间。
+
+分账结果与银行入账反馈之间为多对多关系：一笔分账结果可以分多次入账，一笔银行汇总入账也可以覆盖多笔分账结果。任一分账结果的有效关联金额累计不得超过其应入账金额。
+
+## 10. 核心关系
+
+```mermaid
+erDiagram
+    客户企业 ||--o{ 品牌 : 管理
+    品牌 ||--o{ 区域 : 包含
+    品牌 ||--o{ 门店 : 管理
+    加盟商 ||--o{ 门店 : 管理
+    门店 ||--o{ 门店经营主体关系 : 维护
+    经营主体 ||--o{ 门店经营主体关系 : 承担经营
+    结算主体 ||--o{ 商户号 : 拥有
+    结算主体 ||--o{ 银行账户 : 拥有
+    支付明细 ||--o{ 支付明细结算主体关系 : 拆分结算
+    结算主体 ||--o{ 支付明细结算主体关系 : 接收归属
+    结算渠道 ||--o{ 商户号 : 分配
+    结算渠道 ||--o{ 渠道门店 : 标识
+    结算渠道 ||--o{ 渠道结算周期规则 : 配置
+    品牌 ||--o{ 渠道结算周期规则 : 适用
+    门店 ||--o{ 门店映射关系 : 被映射
+    商户号 o|--o{ 门店映射关系 : 可参与
+    渠道门店 o|--o{ 门店映射关系 : 可参与
+    门店映射关系 ||--o{ 渠道账单明细 : 解析归属
+    门店 ||--o{ 门店现金账户 : 拥有
+    门店 ||--o{ 业务订单 : 产生
+    业务订单 ||--o{ 支付明细 : 包含
+    业务订单 ||--o{ 退款单 : 发生
+    退款单 ||--o{ 退款明细 : 拆分
+    支付明细 ||--o{ 退款明细 : 原支付
+    退款明细 ||--o{ 退款流水 : 执行
+    支付明细 ||--o{ 核销记录 : 参与
+    渠道账单明细 ||--o{ 核销记录 : 参与
+    退款明细 ||--o{ 核销记录 : 参与
+    退款流水 ||--o{ 核销记录 : 参与
+    渠道账单明细 ||--o{ 渠道结算归集明细 : 被归集
+    渠道结算单 ||--o{ 渠道结算归集明细 : 包含
+    渠道结算批次 o|--o{ 渠道结算单 : 执行
+    结算渠道 ||--o{ 渠道结算单 : 出具
+    结算主体 ||--o{ 渠道结算单 : 接收
+    支付明细 ||--o{ 差异记录 : 可能产生
+    支付明细 ||--o{ 可分账结果 : 产生
+    结算调整项 ||--o{ 调整项分摊结果 : 分摊为
+    品牌 ||--o{ 调整项分摊结果 : 可能接收
+    加盟商 ||--o{ 调整项分摊结果 : 可能接收
+    门店 ||--o{ 调整项分摊结果 : 接收
+    经营主体 ||--o{ 调整项分摊结果 : 可能接收
+    业务订单 ||--o{ 调整项分摊结果 : 可能接收
+    支付明细 ||--o{ 调整项分摊结果 : 可能接收
+    可分账结果 ||--o{ 分账结果 : 生成
+    分账结果 ||--o{ 分账结果入账关联明细 : 被关联
+    分账入账反馈 ||--o{ 分账结果入账关联明细 : 汇总关联
+```
+
+## 11. 核心关系规则
+
+1. 门店是订单和对账明细的核心归属对象。
+2. 客户企业是租户隔离、客户配置和客户扩展编码的归属边界；加盟商是旗下门店的汇总维度。
+3. 经营主体承担门店经营责任，结算主体承担渠道结算责任。
+4. 支付明细是核销和可分账判断的最小对象，同一支付明细允许关联多个结算主体。
+5. 系统门店、商户号和渠道门店之间通过独立的门店映射关系实体关联。
+6. 门店映射关系需要支持一对多、多对一、组合映射、有效期和历史追溯。
+7. 门店映射冲突不得自动选择门店，必须转人工确认；确认完成前不得进入自动核销和可分账处理。
+8. 核销记录连接支付明细与渠道账单明细、权益流水或现金账户流水，也连接退款明细与退款流水。
+9. 分账结果由分账系统生成。
+10. 银行按分账结果汇总入账，分账系统将入账反馈返回对账系统。
+11. 支付明细结算主体关系需要在可分账输出前确认，各结算主体归属金额合计必须与支付明细确认金额平衡。
+12. 非订单级结算调整项独立记录，只有在归属和分摊确认后才影响门店或支付明细的可结算结果。
+13. 业务类型、下单方式、订单来源和履约方式允许客户扩展；客户扩展值必须独立编码、保留有效期，并映射到平台标准分类。
+14. 门店经营类型固定为直营、加盟、联营、托管四类；门店形态、收银模式、结算模式、收益规则和管理归属分别建模，不得混入经营类型。
+15. 门店经营属性按适用范围和有效期管理，经营主体通过门店经营主体关系按自然日管理。
+16. 业务类型、下单方式、订单来源、履约方式和支付方式分别建模，不得相互替代。
+17. 渠道账单明细记录交易事实，渠道结算归集明细支持部分和分批结算，渠道结算单及渠道结算批次记录结算事实。
+18. 组合支付退款通过退款单、退款明细和退款流水表达，支持分次退款和跨支付方式退款。
+19. 分账结果与银行入账反馈通过关联明细建立多对多金额关系，支持部分入账和汇总入账。
+20. 所有核心业务对象必须归属于客户企业，跨客户企业不得共享业务数据或客户扩展编码。
+21. 三方平台结算周期按客户企业、品牌和平台分别配置，支持 D+N、T+N、自然日或工作日、节假日顺延、宽限期和有效期。
+
+## 12. 评审结论
+
+P1-02 业务对象与业务关系评审通过，当前不存在阻断后续业务场景设计的对象级问题。
+
+以下内容转入标准数据模型详细设计阶段：
+
+- 各对象业务唯一键和客户企业隔离键。
+- 各关系实体的数据库唯一约束及有效期重叠校验。
+- 渠道结算归集、退款核销和分账入账关联的状态机。
+- 金额累计上限、撤销、冲正和重新确认机制。
diff --git a/10-产品线/连锁业务对账系统/08-连锁餐饮对账场景清单.md b/10-产品线/连锁业务对账系统/08-连锁餐饮对账场景清单.md
new file mode 100644
index 0000000..423be8e
--- /dev/null
+++ b/10-产品线/连锁业务对账系统/08-连锁餐饮对账场景清单.md
@@ -0,0 +1,384 @@
+# 连锁餐饮对账场景清单
+
+## 1. 文档目的
+
+本文档定义连锁餐饮业务在 V1.0 范围内需要覆盖的对账场景，明确每个场景的业务事实、数据来源、核销对象、结算依据、差异类型、对账完成条件和分账输出条件。
+
+本文档是 P1-03 业务场景设计成果，作为后续端到端业务流程、状态流转、核销规则、数据模型详细设计和测试场景的输入。
+
+## 2. 场景设计原则
+
+1. 订单应收金额统一使用订单成交金额。
+2. 业务类型、下单方式、订单来源、履约方式和支付方式分别记录，不相互替代。
+3. 一笔订单可以包含多条支付明细，支付明细是核销和可分账判断的最小对象。
+4. 渠道账单明细记录渠道交易事实，渠道结算单和渠道结算批次记录结算事实。
+5. 退款通过退款单、退款明细和退款流水表达，并追溯到原支付明细。
+6. 渠道结算不等于银行入账。银行入账由分账系统完成分账后反馈。
+7. 已明确的正常费用按渠道账单实际值认可；超出费用容差时生成费用异常，但不改写渠道实际费用。
+8. 门店、经营主体和结算主体归属未确认时，不得输出可分账结果。
+9. 同一订单下已满足条件的支付明细可以先行输出，其他支付明细单独阻断。
+10. 收银订单以营业日 D+1 批量同步为标准流程；数据完整截止时间前不将尚未到达的订单或支付明细判定为正式缺失差异。
+
+## 3. 场景分类
+
+| 分类 | 场景编号 | 场景名称 | V1.0 |
+| --- | --- | --- | --- |
+| 基础交易 | C01 | 堂食订单在线支付 | 是 |
+| 基础交易 | C02 | 扫码点餐在线支付 | 是 |
+| 基础交易 | C03 | 现金支付与门店现金汇缴 | 是 |
+| 组合支付 | C04 | 三方团购券核销 | 是 |
+| 组合支付 | C05 | 团购券加在线支付 | 是 |
+| 组合支付 | C06 | 团购券加在线支付加私域现金券 | 是 |
+| 组合支付 | C07 | 储值余额加在线支付 | 是 |
+| 平台业务 | C08 | 外卖平台订单结算 | 是 |
+| 平台业务 | C09 | 平台优惠券与平台补贴 | 是 |
+| 内部权益 | C10 | 私域现金券、优惠券和会员权益 | 是 |
+| 退款 | C11 | 在线支付原路退款 | 是 |
+| 退款 | C12 | 组合支付退款 | 是 |
+| 退款 | C13 | 在线支付现金退款 | 是 |
+| 退款 | C14 | 团购券退款、退券、过期和异常核销 | 是 |
+| 渠道结算 | C15 | 跨日结算 | 是 |
+| 渠道结算 | C16 | 部分结算和分批结算 | 是 |
+| 渠道结算 | C17 | 同一支付明细对应多个结算主体 | 是 |
+| 费用调整 | C18 | 平台费用与费用容差 | 是 |
+| 费用调整 | C19 | 非订单级结算调整项 | 是 |
+| 归属异常 | C20 | 门店映射缺失或冲突 | 是 |
+| 分账反馈 | C21 | 分账后银行汇总入账反馈 | 是 |
+
+## 4. 基础交易场景
+
+### C01 堂食订单在线支付
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户在门店堂食，由收银员通过 POS 或收银系统开单并完成在线支付 |
+| 分类维度 | 业务类型为堂食；下单方式为收银台开单；履约方式为到店消费 |
+| 订单来源 | POS、收银系统或门店业务系统 |
+| 支付构成 | 微信、支付宝、银行卡或聚合支付等一条或多条在线支付明细 |
+| 应收口径 | 订单应收金额等于订单成交金额，且等于有效支付明细应核对金额合计 |
+| 核销依据 | 支付明细号、渠道流水号、商户号、门店、支付时间和支付金额 |
+| 结算依据 | 渠道账单明细、渠道结算归集明细、渠道结算单和渠道结算批次 |
+| 主要差异 | 支付成功无账单、账单无订单、金额不一致、重复账单、商户号或门店归属错误 |
+| 完成条件 | 支付明细已与有效渠道账单明细完成金额核销，并可追溯至有效渠道结算单 |
+| 分账条件 | 支付明细已核销，退款和阻断型差异已处理，门店、经营主体及结算主体归属明确 |
+
+### C02 扫码点餐在线支付
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户扫码进入点餐页面，自助下单并在线支付 |
+| 分类维度 | 业务类型通常为堂食；下单方式为扫码点餐；履约方式为到店消费 |
+| 订单来源 | 扫码点餐系统、小程序或品牌私域系统 |
+| 支付构成 | 微信、支付宝或聚合支付等在线支付明细 |
+| 应收口径 | 订单成交金额，不因下单入口不同改变 |
+| 核销依据 | 业务订单号、支付明细号、渠道流水号、商户号、门店和金额 |
+| 结算依据 | 实际收款渠道的渠道账单明细和渠道结算单 |
+| 主要差异 | 扫码订单未同步、支付流水未回写、订单门店与商户号门店不一致、重复支付 |
+| 完成条件 | 订单、支付明细和渠道账单明细链路完整，支付金额完成核销 |
+| 分账条件 | 与 C01 相同；扫码点餐仅影响下单方式和数据来源，不改变核销原则 |
+
+### C03 现金支付与门店现金汇缴
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户向门店支付现金，门店形成现金支付明细和门店现金账户收款流水 |
+| 订单来源 | POS 或收银系统 |
+| 支付构成 | 现金支付明细 |
+| 第一阶段核销 | 订单现金支付明细与门店现金账户收款流水核销 |
+| 第二阶段核销 | 门店每日现金汇缴批次与营业员或店长的线上汇缴支付交易及渠道账单明细核销 |
+| 账户要求 | 每个门店至少维护一个有效现金账户，记录现金收款、退款、汇缴和调整 |
+| 主要差异 | 现金订单无账户流水、账户流水无订单、应汇缴与实际汇缴不一致、汇缴支付失败、现金余额为负 |
+| 完成条件 | 订单现金收款已进入门店现金账户；纳入汇缴范围的现金已完成汇缴核销 |
+| 分账条件 | 现金支付明细完成规定阶段的核销，现金退款和调整已确认，无阻断型现金差异 |
+
+## 5. 组合支付与权益场景
+
+### C04 三方团购券核销
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户出示第三方团购券，门店核销后完成订单支付 |
+| 订单来源 | POS、团购核销系统或团购平台 |
+| 支付构成 | 团购券核销支付明细 |
+| 金额口径 | 同时保留券面金额、购买金额、核销金额、平台应结算金额和平台手续费 |
+| 订单平衡 | 订单支付平衡使用团购券核销金额 |
+| 核销依据 | 团购券码、核销单号、平台订单号、门店、核销时间 |
+| 结算依据 | 团购平台账单明细中的平台应结算金额、费用项及渠道结算单 |
+| 主要差异 | 券已核销无结算、重复核销、核销门店错误、平台应结算金额异常、手续费异常 |
+| 完成条件 | 券核销记录与团购支付明细匹配，平台应结算金额和费用完成确认 |
+| 分账条件 | 团购券支付明细完成核销，退款或退券状态明确，结算主体归属已确认 |
+
+### C05 团购券加在线支付
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 团购券不足以覆盖订单成交金额，用户补充在线支付 |
+| 支付构成 | 团购券核销明细加在线支付明细 |
+| 订单平衡 | 订单应收金额等于团购券核销金额加在线支付金额 |
+| 核销方式 | 团购券与团购平台账单核销；在线支付与对应支付渠道账单核销 |
+| 结算依据 | 两类支付明细分别对应各自渠道账单明细和渠道结算单 |
+| 主要差异 | 仅一类支付完成结算、支付拆分金额不平、补差支付重复或缺失 |
+| 完成条件 | 两类支付明细分别完成核销；允许形成订单部分已核销状态 |
+| 分账条件 | 已满足条件的支付明细可先输出，未完成的支付明细单独阻断 |
+
+### C06 团购券加在线支付加私域现金券
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户同时使用第三方团购券、在线支付和品牌私域现金券 |
+| 支付构成 | 团购券核销明细、在线支付明细、私域现金券抵扣明细 |
+| 订单平衡 | 三类有效支付或权益抵扣金额合计等于订单应收金额 |
+| 核销方式 | 团购券核对平台账单；在线支付核对支付渠道账单；私域现金券核对内部券账户或核销流水 |
+| 结算边界 | 私域现金券不必存在外部渠道结算，但必须确认承担方及内部权益核销结果 |
+| 主要差异 | 组合金额不平、券承担方不明、内部券流水缺失、外部支付未结算 |
+| 完成条件 | 三类支付明细均有明确核销结果，或分别形成已核销、待核销状态 |
+| 分账条件 | 支付明细分别判断；私域券承担关系不明时阻断对应支付明细 |
+
+### C07 储值余额加在线支付
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户使用会员储值余额支付部分金额，其余通过在线支付完成 |
+| 支付构成 | 储值扣减明细加在线支付明细 |
+| 核销方式 | 储值扣减与储值账户消费流水核销；在线支付与渠道账单明细核销 |
+| 资金追溯 | 储值资金原始入账记录由分账系统提供，对账系统负责关联和追溯 |
+| 主要差异 | 储值扣减无账户流水、余额不足仍扣减、重复扣减、在线支付未结算、储值资金来源无法追溯 |
+| 完成条件 | 储值消费核对和在线支付核销分别完成 |
+| 分账条件 | 两条支付明细分别判断；储值消费流水已核销即可判断当前支付明细，历史储值资金入账追溯缺失生成独立差异，不反向阻断当前消费对账 |
+
+### C08 外卖平台订单结算
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 用户在外卖平台下单，由门店或平台完成配送 |
+| 分类维度 | 业务类型为外卖；下单方式为平台下单；订单来源为具体外卖平台；履约方式为门店配送或平台配送 |
+| 订单来源 | 美团、饿了么、抖音等外卖平台及门店订单系统 |
+| 支付构成 | 用户实付、平台优惠券、其他权益支付明细 |
+| 订单费用 | 包装费、配送费等作为订单附加费用独立记录 |
+| 结算组成 | 交易金额、退款、佣金、服务费、配送相关费用、补贴和调整项 |
+| 核销依据 | 平台订单号、渠道流水号、平台门店、商户号、金额和时间 |
+| 主要差异 | 平台订单缺失、门店映射错误、平台费用异常、退款不同步、跨日或分批结算 |
+| 完成条件 | 支付明细与平台账单明细完成核销，并可追溯至平台结算单 |
+| 分账条件 | 支付明细、费用、退款和归属均已确认，无阻断型差异 |
+
+### C09 平台优惠券与平台补贴
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 平台优惠券用于抵扣订单金额，平台可能在账单中列示对应补贴 |
+| 支付构成 | 平台优惠券作为独立支付明细，记录核销金额及承担方 |
+| 核销方式 | 优惠券支付明细与平台活动、券核销或平台账单明细核对 |
+| 结算口径 | 仅使用渠道账单中实际列示的补贴金额解释渠道结算金额 |
+| 系统边界 | 对账系统不判断平台补贴是否最终到账；到账由分账系统判断并反馈 |
+| 主要差异 | 优惠券支付明细缺失、承担方不明、账单补贴金额与活动预期不一致 |
+| 完成条件 | 优惠券核销金额、承担方和渠道列示补贴均已确认 |
+| 分账条件 | 对应支付明细完成核销；平台补贴到账状态不阻断订单对账阶段的分账准备 |
+
+### C10 私域现金券、优惠券和会员权益
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 品牌或门店发行的现金券、优惠券、积分或会员权益用于订单抵扣 |
+| 支付构成 | 按权益性质生成独立支付明细，不仅记录为订单优惠汇总 |
+| 核销依据 | 券码、权益账户流水、活动、核销时间、门店和订单 |
+| 结算边界 | 内部承担权益通常无外部渠道结算；如存在合作方结算，则接入对应渠道账单 |
+| 主要差异 | 权益流水缺失、重复核销、过期权益被使用、承担主体不明、门店或活动归属错误 |
+| 完成条件 | 权益支付明细与有效核销流水匹配，承担方和金额确认 |
+| 分账条件 | 权益承担关系明确；需要结算的合作方账单已完成核销 |
+
+## 6. 退款场景
+
+### C11 在线支付原路退款
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 订单发生全额或部分退款，并通过原在线支付渠道退回 |
+| 退款对象 | 退款单、退款明细和退款流水 |
+| 关联关系 | 退款明细必须关联原在线支付明细，退款流水记录渠道实际退款结果 |
+| 核销依据 | 原支付流水号、退款单号、渠道退款流水号、退款金额和时间 |
+| 主要差异 | 业务退款无渠道退款、渠道退款无业务退款、退款金额不一致、重复退款 |
+| 完成条件 | 退款明细业务退款金额被有效退款流水全部覆盖 |
+| 分账条件 | 未分账支付明细扣除已确认退款；已分账后的退款处理转入后续分账冲正规则 |
+
+### C12 组合支付退款
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 包含在线支付、券、储值或现金等多种支付方式的订单发生退款 |
+| 退款拆分 | 退款单必须拆成多条退款明细，每条关联一个原支付明细 |
+| 执行方式 | 可以原路退款，也可以在业务允许时采用其他实际退款方式 |
+| 金额约束 | 各退款明细业务退款金额合计等于退款单金额；单条原支付明细累计退款不得超过其可退金额 |
+| 主要差异 | 退款未拆分、超额退款、部分方式退款成功、券退回失败、重复退款 |
+| 完成条件 | 每条退款明细分别完成退款核销，退款单再汇总判断整体状态 |
+| 分账条件 | 对应支付明细按退款状态分别调整，不使用订单总退款状态一次性阻断全部支付明细 |
+
+### C13 在线支付现金退款
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 原订单通过在线支付，门店实际使用现金向用户退款 |
+| 退款关系 | 退款明细关联原在线支付明细；退款流水类型为门店现金退款 |
+| 现金账户 | 门店现金账户生成退款支出流水并减少现金余额 |
+| 原渠道处理 | 未原路退款时，不生成原渠道退款成功记录，原渠道结算保持原状态 |
+| 主要差异 | 现金退款无业务退款明细、现金账户余额不足、原渠道后续重复退款 |
+| 完成条件 | 现金退款流水与退款明细核销完成，且重复退款风险已排除 |
+| 分账条件 | 退款对原支付明细可分账金额的影响已确认；必要时输出独立调整或冲正信息 |
+
+### C14 团购券退款、退券、过期和异常核销
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 团购券发生退款、退券、撤销核销、过期或异常重复核销 |
+| 核销对象 | 团购券支付明细、退款明细、券退回流水、平台退款账单和结算调整 |
+| 金额口径 | 区分购买金额退款、核销金额冲销、平台应结算金额调整和手续费退回 |
+| 主要差异 | 已退券仍结算、已核销又退款、过期券被核销、撤销核销未同步、手续费未退 |
+| 完成条件 | 券状态、退款状态、平台账单和结算调整之间可以完整解释 |
+| 分账条件 | 未确认的券退款或异常核销阻断对应团购券支付明细 |
+
+## 7. 渠道结算场景
+
+### C15 跨日结算
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 支付发生日与渠道账单日、结算日不同 |
+| 周期规则 | 支持 D+N 和 T+N；D 为订单所属营业日期，T 为平台定义的支付、核销、完成或确认日期 |
+| 配置范围 | 按客户企业、品牌、三方平台配置，并可细化到商户号、结算主体、业务类型和支付方式 |
+| 日期规则 | 支持自然日、工作日、日切截点、时区、节假日顺延和结算宽限期 |
+| 判断依据 | 使用业务发生时有效且范围最精确的规则计算预期结算日，不在规则到期前认定异常 |
+| 时间字段 | 营业日期、平台触发日期、账单时间、预期结算日、宽限期截止日和实际结算日 |
+| 主要差异 | 周期规则缺失或冲突、超过宽限期仍无结算记录、结算日期异常、跨期归属错误 |
+| 完成条件 | 在允许时间窗口内匹配到有效账单明细和结算归集关系 |
+| 分账条件 | 是否必须等待渠道结算单，由支付类型和客户规则配置；未满足规则时保持待结算 |
+
+### C16 部分结算和分批结算
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 一条支付明细或渠道账单明细被部分结算，后续再分批完成 |
+| 关系对象 | 支付明细与核销记录、渠道账单明细与渠道结算归集明细 |
+| 金额约束 | 累计有效核销金额不得超过支付明细应核对金额；累计有效归集金额不得超过账单明细可结算金额 |
+| 状态 | 未结算、部分结算、已结算；每次结算保留批次和归集金额 |
+| 主要差异 | 超额结算、重复归集、批次金额不平、长期部分结算 |
+| 完成条件 | 累计有效结算金额达到应结算金额，或剩余金额经确认形成合法调整 |
+| 分账条件 | 支持按已确认部分生成支付明细可分账金额，但不得重复输出已处理金额 |
+
+### C17 同一支付明细对应多个结算主体
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 同一支付明细按业务或渠道规则归属于多个结算主体 |
+| 关系对象 | 支付明细结算主体关系 |
+| 金额约束 | 各结算主体归属金额合计等于支付明细确认金额 |
+| 金额基准 | 使用支付明细确认金额，不使用扣除结算调整项后的可分账金额 |
+| 主要差异 | 结算主体缺失、归属金额不平、关系未确认、主体与商户号或结算单不一致 |
+| 完成条件 | 所有结算主体关系已确认且金额平衡 |
+| 分账条件 | 支付明细可分账金额只计算一次；分账系统基于主体关系和分账规则生成最终分配结果 |
+
+## 8. 费用与结算调整场景
+
+### C18 平台费用与费用容差
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 渠道或平台在账单、结算单中列示手续费、佣金、服务费、配送费、包装费、达人佣金等 |
+| 费用口径 | 正常费用按渠道账单明细或渠道结算单实际值认可 |
+| 预期比较 | 合同费率或内部测算值只用于计算费用偏差，不替代实际费用 |
+| 容差规则 | 按品牌、渠道、业务类型、费用项和生效时间配置 |
+| 主要差异 | 实际费用超过容差、费用重复、费用方向错误、费用缺失或归属错误 |
+| 完成条件 | 费用实际值已记录并确认，偏差在容差内或异常已确认处理 |
+| 分账条件 | 正常费用直接进入可分账金额计算；阻断型费用异常处理前不输出对应金额 |
+
+### C19 非订单级结算调整项
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 平台处罚、赔付、批量奖励、批量补扣款或账期调整无法直接关联单笔订单 |
+| 对象要求 | 独立建立结算调整项，不伪造业务订单或支付明细 |
+| 归属范围 | 品牌、加盟商、门店、经营主体、订单、支付明细或待确认 |
+| 分摊原则 | 优先使用平台明细和明确业务规则，不默认平均分摊 |
+| 主要差异 | 调整项无归属、分摊金额不平、重复分摊、未经确认即影响分账 |
+| 完成条件 | 归属和分摊结果已确认，分摊金额合计与调整项金额平衡 |
+| 分账条件 | 已确认调整项作为独立输入输出给分账系统；未确认项目不得影响支付明细或门店可结算金额 |
+
+## 9. 归属异常场景
+
+### C20 门店映射缺失或冲突
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 外部订单或渠道账单明细无法唯一映射到系统门店 |
+| 冲突类型 | 无映射、多个有效映射、商户号与渠道门店映射冲突、映射有效期不匹配 |
+| 处理方式 | 全部生成门店映射差异并转人工确认，不按优先级自动选择门店 |
+| 人工要求 | 指定唯一系统门店，记录确认人、确认时间、处理说明和业务凭证 |
+| 历史规则 | 确认结果按适用有效期生效，不使用当前映射覆盖历史业务 |
+| 完成条件 | 订单、支付明细或账单明细已确认唯一门店归属 |
+| 分账条件 | 人工确认完成前不得进入自动核销和可分账处理 |
+
+## 10. 分账后入账场景
+
+### C21 分账后银行汇总入账反馈
+
+| 项目 | 场景定义 |
+| --- | --- |
+| 业务发生 | 对账系统输出可分账结果，分账系统完成分账并将银行汇总入账结果反馈 |
+| 系统边界 | 对账系统不执行分账、不生成银行流水，只接收、关联、展示和验证 |
+| 关系对象 | 分账结果、分账入账反馈、分账结果入账关联明细 |
+| 关系类型 | 一笔分账结果可以分多次入账；一笔银行入账可以覆盖多笔分账结果 |
+| 金额约束 | 分账结果累计有效入账关联金额不得超过其应入账金额 |
+| 状态 | 待入账、部分入账、已入账、入账失败、已退回 |
+| 主要差异 | 应入账与实际入账不一致、重复关联、超额关联、入账失败或退回 |
+| 完成条件 | 分账结果应入账金额被有效入账关联金额完全覆盖，且汇总金额验证一致 |
+| 分账条件 | 不适用；本场景发生在分账完成之后 |
+| 对账影响 | 该场景属于分账后的资金验证，不回写订单核销结果，但形成独立入账差异 |
+
+## 11. 场景共用差异分类
+
+| 差异分类 | 典型问题 | 是否默认阻断分账 |
+| --- | --- | --- |
+| 数据缺失 | 订单、支付明细、账单明细、退款流水或权益流水缺失 | 是 |
+| 金额不平 | 订单支付不平、核销金额不平、结算归集金额不平 | 是 |
+| 重复处理 | 重复支付、重复核销、重复退款、重复结算或重复入账关联 | 是 |
+| 状态不一致 | 业务成功但渠道失败，或业务退款与渠道退款状态不一致 | 是 |
+| 归属异常 | 门店、经营主体或结算主体不明确 | 是 |
+| 费用异常 | 实际费用超出配置容差 | 按配置 |
+| 时效异常 | 超过预期账单、结算或入账周期 | 按配置 |
+| 正常业务差额 | 账单已列示且规则认可的费用、补贴或调整 | 否 |
+| 后置入账差异 | 分账完成后银行实际入账异常 | 不回阻订单核销，单独处理 |
+
+## 12. 场景共用完成条件
+
+单条支付明细达到可分账状态，至少需要满足：
+
+1. 所属订单为有效订单，订单应收金额和支付构成平衡。
+2. 支付明细已与对应渠道账单明细、权益流水或现金账户流水完成核销。
+3. 对应退款明细和退款流水状态明确。
+4. 渠道结算要求已按场景规则满足。
+5. 正常费用和已确认结算调整项已纳入口径。
+6. 不存在未关闭的阻断型差异。
+7. 门店、当日经营主体和结算主体归属明确。
+8. 未被人工冻结或暂缓分账。
+
+订单级对账状态由订单下支付明细状态汇总，不覆盖支付明细自身状态。
+
+## 13. 场景边界
+
+以下内容不在本场景清单中展开：
+
+- 分账系统内部的参与方分配算法和收益计算公式。
+- 企业会计准则下的收入确认、会计凭证和总账处理。
+- 渠道接口字段级映射和技术接入协议。
+- 各对象完整字段、数据库唯一键和状态机。
+- 已分账订单退款后的资金追回和分账冲正规则细节。
+
+上述内容分别进入分账规则、标准数据模型详细设计、系统集成和退款对账规则文档。
+
+## 14. 评审重点
+
+1. V1.0 场景是否覆盖连锁餐饮主要交易、支付、退款、结算和入账链路。
+2. 各场景的订单、支付明细、账单明细和结算对象是否边界清晰。
+3. 组合支付、部分结算、分批结算和多结算主体是否可独立核销。
+4. 现金、储值和内部权益是否具备独立核对依据。
+5. 退款是否能够追溯原支付明细和实际退款流水。
+6. 差异是否明确区分正常业务差额与异常差异。
+7. 对账完成条件和可分账条件是否足以进入后续流程设计。
diff --git a/10-产品线/连锁业务对账系统/09-端到端业务流程.md b/10-产品线/连锁业务对账系统/09-端到端业务流程.md
new file mode 100644
index 0000000..5da4f5e
--- /dev/null
+++ b/10-产品线/连锁业务对账系统/09-端到端业务流程.md
@@ -0,0 +1,561 @@
+# 连锁业务对账系统端到端业务流程
+
+## 1. 文档目的
+
+本文档定义连锁餐饮业务从基础资料准备、业务数据接入、对账核销、差异处理、结果确认、可分账输出，到分账后银行入账反馈的端到端业务流程。
+
+本文档是 P1-04 流程设计成果，作为状态流转、产品能力地图、核销规则、权限设计、页面原型和验收场景的输入。
+
+## 2. 流程范围
+
+### 2.1 流程起点
+
+满足以下任一条件时启动流程：
+
+- 业务系统产生新增或变更的订单、支付明细、退款数据。
+- 支付渠道或业务平台产生渠道账单明细、结算单、费用或调整项。
+- 门店产生现金账户流水或现金汇缴记录。
+- 内部权益系统产生券核销、储值扣减或权益退回流水。
+- 分账系统返回分账执行和银行入账反馈。
+- 财务或运营人员发起补数、重新核销、人工确认或差异复核。
+
+### 2.2 对账主流程终点
+
+对账主流程以以下结果之一作为终点：
+
+- 支付明细生成可分账结果并成功交付分账系统。
+- 支付明细因前置条件未满足保持不可分账。
+- 支付明细因争议、退款待确认或人工控制进入暂缓分账。
+
+### 2.3 后置反馈终点
+
+分账系统完成分账后，向对账系统反馈分账结果及银行汇总入账结果。对账系统完成入账关联和金额验证后，形成已入账、部分入账、待入账、入账失败或退回、入账差异等结果。
+
+银行入账状态不回写订单核销结果。
+
+## 3. 参与系统与职责
+
+| 参与方 | 输入或操作 | 核心职责 |
+| --- | --- | --- |
+| POS、收银及点餐系统 | 订单、支付构成、退款、门店信息 | 提供门店业务发生事实 |
+| 外卖、团购及其他业务平台 | 平台订单、券核销、退款、账单、结算单、费用、补贴 | 提供平台业务和结算事实 |
+| 支付渠道及聚合支付系统 | 支付流水、退款流水、交易账单、结算数据 | 提供外部资金交易事实 |
+| 会员及权益系统 | 储值、券、积分和权益流水 | 提供内部权益变化事实 |
+| 门店现金账户 | 现金收款、退款、调整和汇缴流水 | 提供现金资金变化事实 |
+| 对账系统 | 标准化、归属、核销、差异、确认和输出 | 生成可信可分账结果 |
+| 财务人员 | 差异处理、人工核销、结果确认和冻结 | 对金额及财务结果负责 |
+| 业务运营人员 | 门店映射、平台规则、活动和业务异常确认 | 对业务归属和渠道规则负责 |
+| 门店人员 | 现金、订单、退款和业务凭证确认 | 对门店业务事实负责 |
+| IT 部门 | 接口、任务、补数、映射和数据质量处理 | 保证数据链路稳定 |
+| 分账系统 | 接收可分账结果、执行分账、反馈入账 | 负责最终分配和资金入账 |
+
+## 4. 流程前置条件
+
+正式执行自动对账前，至少需要完成：
+
+1. 客户企业、品牌、加盟商、门店和区域资料已建立。
+2. 门店在业务发生自然日存在唯一有效经营主体。
+3. 结算渠道、结算主体、商户号和银行账户已建立。
+4. 系统门店、商户号和渠道门店映射已生效。
+5. 业务类型、下单方式、订单来源、履约方式和支付方式字典已配置。
+6. 渠道数据接入、字段映射、金额口径和时间口径已配置。
+7. 匹配规则、D+N/T+N 结算周期、费用容差和差异阻断规则已生效。
+8. 分账系统接口及可分账结果接收确认机制已启用。
+
+前置资料缺失不应阻止原始数据接收，但相关标准数据必须进入待归属、待配置或待人工确认状态。
+
+## 5. 端到端主流程
+
+```mermaid
+flowchart TD
+    A["业务、渠道或内部账户产生数据"] --> B["接收原始数据并保留原文"]
+    B --> C{"基础校验是否通过"}
+    C -- 否 --> C1["记录接入失败或数据质量差异"]
+    C1 --> C2["补数、修正配置或重新处理"]
+    C2 --> B
+    C -- 是 --> D["转换为标准业务对象"]
+    D --> E["解析客户、门店、经营主体和结算主体归属"]
+    E --> F{"归属是否唯一且有效"}
+    F -- 否 --> F1["生成归属差异并转人工确认"]
+    F1 --> F2{"人工确认完成"}
+    F2 -- 否 --> Z1["保持不可核销、不可分账"]
+    F2 -- 是 --> G
+    F -- 是 --> G["校验订单与支付构成平衡"]
+    G --> H{"支付构成是否平衡"}
+    H -- 否 --> H1["生成订单支付不平差异"]
+    H1 --> Z1
+    H -- 是 --> I["按支付明细选择核销路径"]
+    I --> J["执行支付、权益、现金或退款核销"]
+    J --> K["关联渠道结算、费用和调整项"]
+    K --> L["识别未核销、金额、费用、时效和重复差异"]
+    L --> M{"是否存在阻断型差异"}
+    M -- 是 --> M1["进入差异协同处理"]
+    M1 --> M2{"差异是否关闭或解除阻断"}
+    M2 -- 否 --> Z2["不可分账或暂缓分账"]
+    M2 -- 是 --> N
+    M -- 否 --> N["确认支付明细对账结果"]
+    N --> O{"是否满足可分账条件"}
+    O -- 否 --> Z2
+    O -- 是 --> P["生成支付明细级可分账结果"]
+    P --> Q["输出分账系统并等待接收确认"]
+    Q --> R{"分账系统是否成功接收"}
+    R -- 否 --> R1["记录输出失败并重试"]
+    R1 --> Q
+    R -- 是 --> S["标记分账系统已接收"]
+    S --> T["接收分账结果和银行入账反馈"]
+    T --> U["建立分账结果与入账反馈关联"]
+    U --> V["验证应入账与实际入账金额"]
+    V --> W{"入账是否一致"}
+    W -- 否 --> W1["生成后置入账差异"]
+    W -- 是 --> X["形成已入账或部分入账结果"]
+```
+
+## 6. 主流程阶段
+
+| 阶段 | 主要输入 | 核心处理 | 主要输出 |
+| --- | --- | --- | --- |
+| P01 原始数据接收 | 订单、支付、退款、账单、结算、权益、现金、分账反馈 | 保存原始报文、校验文件或接口任务 | 原始数据、接入任务结果 |
+| P02 标准化 | 已通过基础校验的原始数据 | 字段映射、金额转换、时间转换、业务去重 | 标准业务对象 |
+| P03 业务归属 | 标准业务对象、主数据和映射关系 | 确认客户、门店、经营主体、结算主体 | 已归属数据或归属差异 |
+| P04 完整性校验 | 订单、支付明细、退款和账户流水 | 校验订单有效性、支付平衡和对象关联 | 可核销数据或完整性差异 |
+| P05 对账核销 | 支付明细、账单明细、权益流水、现金流水、退款流水 | 自动匹配并生成核销记录 | 已核销、部分核销或未核销结果 |
+| P06 渠道结算确认 | 账单明细、结算归集明细、结算单和结算批次 | 判断未结算、部分结算、已结算 | 渠道结算状态 |
+| P07 费用与调整 | 费用项、容差规则、结算调整项 | 识别正常费用、费用异常和调整归属 | 费用结果、调整项及分摊结果 |
+| P08 差异协同 | 各阶段生成的差异 | 分派、处理、复核、关闭或暂缓 | 差异处理结果 |
+| P09 对账确认 | 核销、退款、结算、费用和差异结果 | 确认支付明细最终对账结果 | 支付明细确认金额 |
+| P10 分账准备 | 对账结果和结算主体关系 | 判断可分账、不可分账或暂缓分账 | 可分账结果 |
+| P11 分账输出 | 可分账结果、调整项 | 输出、重试和接收确认 | 分账系统已接收结果 |
+| P12 后置入账验证 | 分账结果、银行入账反馈 | 建立金额关联并验证 | 入账状态和入账差异 |
+
+## 7. 数据接入与标准化流程
+
+### 7.1 接入依赖
+
+不同数据可以异步到达，不要求严格按顺序接收。业务处理逻辑按以下依赖推进：
+
+```text
+基础资料和映射
+  ↓
+订单及支付明细
+  ↓
+渠道账单明细、权益流水或现金账户流水
+  ↓
+渠道结算单及结算归集明细
+  ↓
+退款、费用和结算调整
+  ↓
+可分账结果
+  ↓
+分账和银行入账反馈
+```
+
+后到数据需要触发关联对象重新评估，但不得重复生成有效核销金额或可分账金额。
+
+### 7.2 订单 D+1 同步
+
+连锁餐饮门店的业务订单原则上支持按营业日从收银系统进行 D+1 批量同步。大部分客户和门店不以实时同步作为对账前提。
+
+系统需要分别记录：
+
+- 业务发生时间：订单在门店实际发生的时间。
+- 营业日期：订单归属的门店营业日，可能与自然日不同。
+- 来源系统更新时间：收银系统最后修改订单的时间。
+- 数据同步时间：对账系统实际接收订单的时间。
+- 数据完整截止时间：客户约定的 D+1 批次应完成时间。
+
+D 日订单的标准处理节奏为：
+
+```text
+D 日门店营业并产生订单
+  ↓
+D 日门店日结或收银系统关账
+  ↓
+D+1 收银系统生成订单和支付明细批次
+  ↓
+D+1 对账系统接收、校验并标准化
+  ↓
+D+1 数据完整截止时间后执行完整性检查和自动核销
+```
+
+处理规则：
+
+1. 订单按业务发生时间和营业日期归属，不按数据同步日期归属。
+2. D+1 数据完整截止时间前，缺少订单或支付明细只标记为“等待同步”，不生成正式缺失差异。
+3. 截止时间后仍未到达的数据，才生成订单同步缺失、支付明细缺失或批次不完整差异。
+4. 收银系统支持实时推送时，可以提前接收和预处理，但实时数据仍需与 D+1 完整批次校验。
+5. D+1 后到数据、补传数据或历史修正数据需要触发重新标准化、重新核销和差异重评。
+6. 已被分账系统接收的数据发生补传或修正时，不直接覆盖历史结果，进入撤销、冲正或重新确认流程。
+
+### 7.3 基础校验
+
+接入时至少校验：
+
+- 客户企业和来源系统可识别。
+- 来源业务唯一键存在。
+- 必填时间和金额字段格式有效。
+- 金额方向和币种有效。
+- 文件、批次或接口请求未重复处理。
+- 数据版本不低于系统已接收版本。
+- 原始记录可追溯到接入任务。
+- D+1 批次对应的营业日期、门店范围、记录数量和金额汇总可校验。
+
+### 7.4 幂等与变更
+
+- 相同来源系统、业务对象类型和来源业务唯一键只能形成一条当前有效标准对象。
+- 重复报文不重复生成订单、支付明细、账单、退款或核销金额。
+- 上游数据变更需要保留版本和变更时间。
+- 已参与核销或分账输出的数据发生变更时，不直接覆盖结果，应进入撤销、冲正或重新确认流程。
+
+## 8. 订单与支付处理流程
+
+```mermaid
+flowchart TD
+    A["接收订单"] --> B["识别业务分类和门店"]
+    B --> C["按发生日期关联经营主体"]
+    C --> D["接收或拆分支付明细"]
+    D --> E["计算有效支付明细应核对金额"]
+    E --> F{"合计是否等于订单应收金额"}
+    F -- 否 --> G["生成订单支付不平差异"]
+    F -- 是 --> H["逐条支付明细进入对应核销路径"]
+    H --> I["订单状态汇总支付明细结果"]
+```
+
+处理规则：
+
+1. 订单应收金额等于订单成交金额。
+2. 每条支付明细必须明确支付方式、应核对金额和核销依据。
+3. 订单支付平衡后才能进入正常自动核销。
+4. 订单状态只汇总支付明细结果，不覆盖支付明细状态。
+5. 组合支付中一条支付明细异常，原则上不阻断其他已确认支付明细。
+
+## 9. 支付明细核销分支
+
+### 9.1 外部渠道支付
+
+适用于在线支付、外卖平台支付、团购券及其他存在外部账单的支付明细。
+
+```text
+支付明细
+  → 匹配渠道账单明细
+  → 生成核销记录
+  → 关联渠道结算归集明细
+  → 确认渠道结算单和结算批次
+```
+
+匹配结果包括已核销、部分核销、未核销和匹配冲突。
+
+### 9.2 内部权益支付
+
+适用于储值、私域券、积分和会员权益。
+
+```text
+支付明细
+  → 匹配权益账户或核销流水
+  → 确认核销金额及承担方
+  → 判断是否存在外部合作方结算
+```
+
+内部权益无外部结算时，以有效权益流水作为核销依据。储值历史资金入账追溯缺失形成独立差异，不反向阻断当前储值消费核销。
+
+### 9.3 现金支付
+
+现金采用两阶段流程：
+
+```mermaid
+flowchart LR
+    A["订单现金支付明细"] --> B["门店现金账户收款流水"]
+    B --> C["形成待汇缴现金余额"]
+    C --> D["门店创建现金汇缴批次"]
+    D --> E["营业员或店长完成线上汇缴支付"]
+    E --> F["汇缴支付渠道账单明细"]
+    F --> G["完成现金汇缴核销"]
+```
+
+第一阶段确认现金已由门店收取，第二阶段确认现金已通过线上方式汇缴。现金支付是否必须完成第二阶段后才能分账，由客户现金管理规则配置。
+
+## 10. 渠道结算确认流程
+
+### 10.1 结算周期规则匹配
+
+三方平台结算周期按客户企业、品牌和平台配置，支持：
+
+- D+N：以订单所属营业日期 D 为基准。
+- T+N：以平台定义的交易触发日期 T 为基准，T 可以是支付成功日、券核销日、订单完成日或平台确认日。
+
+同一平台在不同品牌、商户号、结算主体、业务类型或支付方式下可以采用不同周期。规则需要配置自然日或工作日、日切截点、时区、节假日顺延、宽限期和有效期。
+
+系统按业务发生时有效且范围最精确的规则计算：
+
+```text
+预期结算日
+= 基准日期 D 或 T
++ N 个自然日或工作日
++ 节假日顺延
+```
+
+规则无法匹配或同优先级规则冲突时，生成结算周期配置差异并暂停超期判断，不自动选取规则。
+
+### 10.2 结算确认
+
+```mermaid
+flowchart TD
+    A["渠道账单明细"] --> A1["匹配品牌和平台结算周期规则"]
+    A1 --> A2["计算预期结算日和宽限期截止日"]
+    A2 --> B["等待渠道结算单"]
+    B --> C["建立渠道结算归集明细"]
+    C --> D{"是否全部归集"}
+    D -- 否 --> E["部分结算"]
+    E --> F["等待后续结算单或合法调整"]
+    F --> C
+    D -- 是 --> G["已结算"]
+    G --> H["关联渠道结算批次"]
+```
+
+处理规则：
+
+1. 跨日结算按 D+N 或 T+N 规则判断，不在预期结算日及宽限期前生成超期异常。
+2. 同一账单明细允许通过多条归集明细进入多张结算单。
+3. 累计有效归集金额不得超过账单明细可结算金额。
+4. 结算单金额必须由归集明细、费用项和结算调整项解释。
+5. 已核销和已结算是独立状态，是否必须结算后才能分账由支付类型和客户规则决定。
+6. 渠道结算不代表银行已经入账。
+
+## 11. 退款处理流程
+
+```mermaid
+flowchart TD
+    A["接收退款单"] --> B["关联原业务订单"]
+    B --> C["按原支付构成生成退款明细"]
+    C --> D["每条退款明细关联原支付明细"]
+    D --> E["接收渠道、权益或现金退款流水"]
+    E --> F["退款明细与退款流水核销"]
+    F --> G{"退款金额是否完全覆盖"}
+    G -- 否 --> H["部分退款或退款失败"]
+    H --> I["生成差异并等待重试或人工处理"]
+    G -- 是 --> J["退款明细完成"]
+    J --> K["重新计算原支付明细可分账金额"]
+    K --> L{"原支付明细是否已分账"}
+    L -- 否 --> M["更新分账准备结果"]
+    L -- 是 --> N["输出后续冲正或资金追回处理信息"]
+```
+
+处理规则：
+
+- 退款单金额等于退款明细业务退款金额合计。
+- 退款明细必须关联原支付明细。
+- 一条退款明细可以对应多条退款流水。
+- 原支付明细累计退款不得超过可退金额。
+- 在线支付现金退款需要同时记录现金账户退款支出。
+- 原渠道后续再次退款时生成重复退款风险差异。
+- 已分账后的退款不直接改写历史分账结果。
+
+## 12. 费用与结算调整流程
+
+### 12.1 正常费用
+
+1. 从渠道账单明细或结算单识别费用项。
+2. 按渠道实际费用金额记录。
+3. 根据合同或预期规则计算费用偏差。
+4. 偏差在容差内时标记正常。
+5. 偏差超过容差时生成费用异常。
+6. 费用异常是否阻断分账按规则配置。
+
+### 12.2 非订单级结算调整
+
+```mermaid
+flowchart TD
+    A["接收结算调整项"] --> B{"能否直接识别归属"}
+    B -- 支付明细或订单 --> C["直接关联并确认"]
+    B -- 门店、加盟商、经营主体或品牌 --> D["保留主体级归属"]
+    B -- 涉及多个对象 --> E["按明确规则生成分摊结果"]
+    B -- 无法识别 --> F["进入待归属差异"]
+    E --> G{"分摊金额是否平衡"}
+    G -- 否 --> H["禁止确认并生成差异"]
+    G -- 是 --> I["人工或规则确认"]
+    C --> J["输出已确认调整项"]
+    D --> J
+    I --> J
+```
+
+未确认调整项不得为了平账强制分摊，也不得影响支付明细或门店可结算金额。
+
+## 13. 差异协同处理流程
+
+```mermaid
+flowchart TD
+    A["系统生成差异"] --> B["确定差异对象、类型、金额和阻断级别"]
+    B --> C["按责任规则分派部门和处理人"]
+    C --> D["财务、运营、门店或 IT 调查处理"]
+    D --> E{"是否需要修改基础资料或业务数据"}
+    E -- 是 --> F["修正映射、配置或补充上游数据"]
+    F --> G["重新标准化和核销"]
+    E -- 否 --> H["提交处理结论和凭证"]
+    G --> I{"差异是否消除"}
+    H --> I
+    I -- 否 --> J["继续处理、暂缓或升级"]
+    I -- 是 --> K["复核并关闭差异"]
+    K --> L["重新评估分账准备状态"]
+```
+
+### 13.1 差异责任原则
+
+| 差异类型 | 主要责任角色 |
+| --- | --- |
+| 订单、支付或退款业务事实问题 | 门店人员、业务运营 |
+| 门店映射、平台配置和活动归属问题 | 业务运营、IT |
+| 接口失败、数据缺失、重复和延迟 | IT |
+| 金额核销、费用和结算差异 | 财务 |
+| 现金收款、退款和汇缴问题 | 门店人员、财务 |
+| 结算调整项归属和分摊 | 财务、业务运营 |
+
+### 13.2 门店映射冲突
+
+门店映射缺失、多个有效映射或组合映射冲突时：
+
+1. 生成门店映射差异。
+2. 暂停相关订单、支付明细和账单明细自动核销。
+3. 全部转人工确认，不自动选择优先级最高的门店。
+4. 人工指定唯一门店并上传依据。
+5. 按适用有效期保存确认结果。
+6. 重新执行归属和核销。
+
+## 14. 对账结果确认流程
+
+支付明细进入结果确认时，系统依次检查：
+
+1. 所属订单有效且支付平衡。
+2. 支付明细已完成规定核销。
+3. 退款状态明确且已扣除有效退款。
+4. 渠道结算要求已满足。
+5. 正常费用已纳入口径。
+6. 结算调整项归属和分摊状态明确。
+7. 门店、当日经营主体和全部结算主体已确认。
+8. 不存在未关闭的阻断型差异。
+9. 未被人工冻结。
+
+系统检查通过后形成支付明细确认金额。人工确认不能绕过金额平衡、归属唯一和累计金额上限等强制约束。
+
+## 15. 可分账结果生成与输出流程
+
+```mermaid
+flowchart TD
+    A["支付明细对账确认"] --> B{"分账前置条件是否满足"}
+    B -- 否，数据或差异未完成 --> C["不可分账"]
+    B -- 否，人工冻结或争议 --> D["暂缓分账"]
+    B -- 是 --> E["计算支付明细可分账金额"]
+    E --> F["校验结算主体关系金额平衡"]
+    F --> G["生成可分账结果版本"]
+    G --> H["输出分账系统"]
+    H --> I{"接收是否成功"}
+    I -- 否 --> J["记录失败、重试并告警"]
+    J --> H
+    I -- 是 --> K["记录接收回执并标记已接收"]
+```
+
+输出规则：
+
+- 可分账结果以支付明细为最小粒度。
+- 支付明细可分账金额只计算一次。
+- 同一支付明细可以关联多个结算主体。
+- 结算主体归属金额合计等于支付明细确认金额。
+- 已确认结算调整项作为独立输入输出。
+- 订单级可分账金额仅汇总支付明细结果。
+- 每次输出需要版本号、业务唯一键和幂等标识。
+- 输出失败不得标记为已接收。
+- 已接收结果发生变更时，需要使用撤销、冲正或新版本处理，不直接覆盖。
+- 页面使用“已输出分账”时，其标准含义是输出状态为已接收，不是仅完成网络发送。
+
+## 16. 分账后银行入账反馈流程
+
+```mermaid
+flowchart TD
+    A["分账系统返回分账结果"] --> B["关联原可分账结果"]
+    B --> C["接收银行汇总入账反馈"]
+    C --> D["生成分账结果入账关联明细"]
+    D --> E["累计每笔分账结果有效入账金额"]
+    E --> F{"是否等于应入账金额"}
+    F -- 小于 --> G["部分入账或待入账"]
+    F -- 等于 --> H["已入账"]
+    F -- 大于 --> I["生成超额入账关联差异"]
+    C --> J{"入账是否失败或退回"}
+    J -- 是 --> K["记录失败原因并生成入账差异"]
+```
+
+后置反馈规则：
+
+- 一笔分账结果可以分多次入账。
+- 一笔银行入账可以关联多笔分账结果。
+- 累计有效关联金额不得超过分账结果应入账金额。
+- 入账差异独立处理，不回退订单已核销状态。
+- 对账系统不判断分账算法是否正确，只验证反馈数据的关联和金额一致性。
+
+## 17. 人工操作控制
+
+| 人工操作 | 允许条件 | 强制留痕 |
+| --- | --- | --- |
+| 人工确认门店 | 自动归属失败或冲突 | 确认人、时间、依据、有效期 |
+| 人工核销 | 自动匹配失败但业务证据充分 | 核销对象、金额、依据、附件 |
+| 核销撤销 | 原核销错误或上游数据变更 | 撤销原因、影响范围、重新核销批次 |
+| 差异关闭 | 差异已解决或确认不影响结果 | 处理结论、责任人、复核人 |
+| 暂缓分账 | 争议、退款调查或风险控制 | 原因、开始时间、解除条件 |
+| 解除暂缓 | 解除条件已经满足 | 操作人、复核人、依据 |
+| 重新输出分账 | 上次失败或经批准生成新版本 | 原输出版本、新版本、变更原因 |
+
+人工操作不得删除原始数据、覆盖历史核销记录或修改已接收分账结果。
+
+## 18. 任务与时点
+
+| 任务 | 建议触发方式 | 时点要求 |
+| --- | --- | --- |
+| 收银订单和支付同步 | D+1 营业日批次为主，实时接口为可选补充 | 在客户约定的 D+1 数据完整截止时间前完成 |
+| 外部渠道账单同步 | 渠道接口或账单文件任务 | 按渠道账单可用时间 |
+| 权益和现金流水同步 | 实时或日内批次 | 在当日对账前完成 |
+| 订单完整性检查 | D+1 批次完成或截止时间触发 | 截止时间前不生成正式订单缺失差异 |
+| 自动核销 | D+1 订单批次到达后触发，并按后到数据周期重跑 | 支持跨日、补传和修正数据 |
+| 渠道结算超期检查 | 按预期结算日和宽限期截止日调度 | 按品牌和平台对应的 D+N 或 T+N 规则 |
+| 渠道结算确认 | 结算单到达触发 | 使用业务发生时有效的品牌和平台结算周期规则 |
+| 差异任务生成 | 每次处理后实时生成 | 不重复生成同一有效差异 |
+| 现金汇缴 | 门店日结后 | 按客户规定的营业日 |
+| 可分账结果输出 | 对账确认后触发 | 支持批量和增量输出 |
+| 银行入账反馈验证 | 分账反馈到达触发 | 支持多次部分入账 |
+
+具体 D+1 截止时间、营业日切换时间、D+N/T+N 周期、工作日日历和其他时效阈值在客户实施配置中确定，不在本流程文档固化。
+
+## 19. 流程输出
+
+端到端流程产生以下主要结果：
+
+- 标准订单、支付明细和退款数据。
+- 标准渠道账单明细、结算单和结算归集关系。
+- 权益、现金和退款核销记录。
+- 支付明细及账单的核销和结算状态。
+- 正常费用、费用异常和结算调整项。
+- 差异任务、处理记录和审计轨迹。
+- 支付明细级可分账结果。
+- 分账系统接收回执。
+- 分账结果和银行入账验证结果。
+- 订单、门店、渠道和结算主体维度的汇总数据。
+
+## 20. 流程边界
+
+对账系统不负责：
+
+- 生成业务订单或执行用户支付。
+- 代替渠道出具交易账单或结算单。
+- 计算品牌、加盟商、门店等参与方的最终分账比例和金额。
+- 执行分账和银行转账。
+- 生成企业会计凭证或总账分录。
+- 无业务依据地修改渠道费用、补贴或结算金额。
+
+对账系统负责提供可追溯、金额平衡、归属明确且状态可信的分账输入，并对分账后的银行入账反馈进行后置验证。
+
+## 21. 评审重点
+
+1. 主流程是否覆盖订单发生到可分账输出的完整链路。
+2. 订单核销、渠道结算和银行入账是否保持独立状态。
+3. 组合支付是否按支付明细分别核销和输出。
+4. 现金、储值、权益和退款是否具有独立核销路径。
+5. 跨日、部分和分批结算是否支持后到数据重新评估。
+6. 差异处理是否能够回到归属、标准化或核销环节形成闭环。
+7. 人工操作是否具备权限、复核和审计约束。
+8. 分账输出和后置入账反馈是否具备幂等、版本和金额上限控制。
diff --git a/10-产品线/连锁业务对账系统/10-状态流转设计.md b/10-产品线/连锁业务对账系统/10-状态流转设计.md
new file mode 100644
index 0000000..835f0df
--- /dev/null
+++ b/10-产品线/连锁业务对账系统/10-状态流转设计.md
@@ -0,0 +1,607 @@
+# 连锁业务对账系统状态流转设计
+
+## 1. 文档目的
+
+本文档定义连锁业务对账系统中各核心对象的标准状态、状态流转条件、聚合规则、分账阻断关系和人工操作边界。
+
+本文档是 P1-05 状态设计成果，作为数据模型详细设计、产品能力地图、功能架构、页面展示、接口协议、权限控制和验收测试的统一依据。
+
+## 2. 状态设计原则
+
+1. 不使用单一总状态承载同步、归属、核销、结算、退款、差异、分账和入账等不同语义。
+2. 状态必须归属于明确业务对象，不能只存在于页面展示层。
+3. 支付明细是核销和分账准备状态的最小对象，订单状态由支付明细聚合。
+4. 已支付、已核销、已结算、可分账、已输出和已入账是相互独立的状态。
+5. 状态变更必须由业务事件、有效数据或授权操作触发，并保留时间和操作来源。
+6. 已确认或已输出结果发生变化时，不直接覆盖历史状态，使用撤销、冲正、失效或新版本处理。
+7. 人工操作不能绕过金额平衡、归属唯一、累计金额上限和客户隔离等强制约束。
+8. 状态名称在接口、数据库、页面和报表中保持一致，不允许各模块自行创造同义状态。
+
+## 3. 状态维度总览
+
+| 状态维度 | 核心对象 | 回答的问题 |
+| --- | --- | --- |
+| 数据同步状态 | 接入批次、订单、支付明细、账单等 | 数据是否已按时、完整进入系统 |
+| 标准化状态 | 原始记录、标准对象 | 原始数据是否成功转换为标准模型 |
+| 归属状态 | 订单、支付明细、账单明细 | 客户、门店、经营主体和结算主体是否明确 |
+| 支付平衡状态 | 业务订单 | 订单应收是否被支付明细完整覆盖 |
+| 核销状态 | 支付明细、账单明细、退款明细 | 应核对金额是否完成匹配 |
+| 渠道结算状态 | 账单明细、结算单 | 是否达到平台应结算时间并完成结算 |
+| 退款状态 | 退款单、退款明细、退款流水 | 退款业务和实际执行是否完成 |
+| 差异状态 | 差异记录 | 异常由谁处理、是否解决、是否阻断 |
+| 对账确认状态 | 支付明细 | 核销、退款、费用和归属结果是否已确认 |
+| 分账准备状态 | 支付明细 | 当前金额是否允许输出给分账系统 |
+| 分账输出状态 | 可分账结果 | 结果是否已成功交付分账系统 |
+| 分账执行状态 | 分账结果 | 分账系统是否完成分账 |
+| 银行入账状态 | 分账结果、入账反馈 | 分账资金是否实际进入银行账户 |
+
+## 4. 状态之间的关系
+
+```mermaid
+flowchart LR
+    A["数据同步状态"] --> B["标准化状态"]
+    B --> C["归属状态"]
+    C --> D["支付平衡状态"]
+    D --> E["核销状态"]
+    E --> F["对账确认状态"]
+    G["渠道结算状态"] --> F
+    H["退款状态"] --> F
+    I["差异状态"] --> F
+    F --> J["分账准备状态"]
+    J --> K["分账输出状态"]
+    K --> L["分账执行状态"]
+    L --> M["银行入账状态"]
+```
+
+该图只表达依赖关系，不表示所有状态必须串行。渠道结算、退款、差异处理可能与核销并行推进。
+
+## 5. 数据同步状态
+
+### 5.1 状态定义
+
+| 状态 | 定义 | 是否异常 |
+| --- | --- | --- |
+| 等待同步 | 尚未到客户约定的数据完整截止时间 | 否 |
+| 同步中 | 接口、文件或批次正在接收和处理 | 否 |
+| 已同步 | 数据已接收，但尚未完成完整性校验 | 否 |
+| 已完整 | 批次范围、数量和金额等完整性校验通过 | 否 |
+| 不完整 | 超过完整截止时间后数据仍有缺失 | 是 |
+| 同步失败 | 接口、文件解析或任务执行失败 | 是 |
+| 已补齐 | 原缺失或失败数据已通过补传补齐 | 否 |
+| 已失效 | 批次被撤销、替换或确认不再使用 | 否 |
+
+### 5.2 收银订单 D+1 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 等待同步
+    等待同步 --> 同步中: D+1批次开始
+    同步中 --> 已同步: 数据接收完成
+    同步中 --> 同步失败: 接口或文件失败
+    已同步 --> 已完整: 完整性校验通过
+    已同步 --> 不完整: 截止时间后校验不通过
+    同步失败 --> 同步中: 重试或补传
+    不完整 --> 已补齐: 补传并校验通过
+    已补齐 --> 已完整: 重新确认批次
+    已完整 --> 已失效: 批次被有效新版本替换
+```
+
+### 5.3 D+1 约束
+
+- 数据完整截止时间前，订单或支付明细尚未到达时保持等待同步，不生成正式缺失差异。
+- 截止时间后仍有缺失时进入不完整，并生成同步缺失差异。
+- 实时数据可以提前进入已同步，但仍需通过 D+1 完整批次校验后进入已完整。
+- 后到或补传数据需要触发标准化、核销和差异状态重新评估。
+
+## 6. 标准化状态
+
+| 状态 | 定义 | 后续处理 |
+| --- | --- | --- |
+| 待标准化 | 原始数据已接收，尚未转换 | 等待标准化任务 |
+| 标准化中 | 正在执行字段、金额和时间转换 | 禁止重复处理 |
+| 标准化成功 | 已生成或更新标准对象 | 进入归属解析 |
+| 标准化失败 | 必填字段、格式或映射失败 | 生成数据质量差异 |
+| 待配置 | 缺少字典、字段映射或规则配置 | 配置完成后重试 |
+| 已失效 | 原始版本被新版本替代 | 保留历史，不参与当前处理 |
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待标准化
+    待标准化 --> 标准化中
+    标准化中 --> 标准化成功
+    标准化中 --> 标准化失败
+    标准化中 --> 待配置
+    标准化失败 --> 待标准化: 数据补传或修正
+    待配置 --> 待标准化: 配置完成
+    标准化成功 --> 已失效: 新版本替换
+```
+
+## 7. 归属状态
+
+### 7.1 状态定义
+
+| 状态 | 定义 | 分账影响 |
+| --- | --- | --- |
+| 待归属 | 尚未执行归属解析 | 阻断 |
+| 归属成功 | 门店及必需主体唯一明确 | 不阻断 |
+| 归属缺失 | 未找到有效映射或主体关系 | 阻断 |
+| 归属冲突 | 找到多个有效关系或关系相互冲突 | 阻断 |
+| 待人工确认 | 已生成归属差异并等待处理 | 阻断 |
+| 人工已确认 | 人工指定唯一归属并留痕 | 不阻断 |
+| 已失效 | 归属结果被撤销或新版本替代 | 不参与当前处理 |
+
+### 7.2 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待归属
+    待归属 --> 归属成功: 唯一匹配
+    待归属 --> 归属缺失: 无有效关系
+    待归属 --> 归属冲突: 多个或冲突关系
+    归属缺失 --> 待人工确认
+    归属冲突 --> 待人工确认
+    待人工确认 --> 人工已确认: 指定唯一归属
+    人工已确认 --> 已失效: 撤销确认
+    已失效 --> 待归属: 重新解析
+```
+
+门店映射冲突必须进入待人工确认，不允许通过优先级自动选择门店。经营主体按照业务发生营业日期匹配当日唯一有效关系。
+
+## 8. 订单支付平衡状态
+
+| 状态 | 判定条件 |
+| --- | --- |
+| 待校验 | 订单或支付明细尚未完整 |
+| 平衡 | 有效支付明细应核对金额合计等于订单应收金额 |
+| 不平衡 | 两者金额不一致 |
+| 待补充支付明细 | 订单已到达但支付构成尚未完整 |
+| 已冲销 | 订单被有效取消或完全冲销，不再参与正常对账 |
+
+```text
+订单应收金额
+= 有效支付明细应核对金额合计
+```
+
+订单支付不平衡时不得进入正常自动核销，但已明确为无须参与对账的抹零、免单或内部承担项可以按标准支付或调整对象补齐后重新校验。
+
+## 9. 支付明细核销状态
+
+### 9.1 状态定义
+
+| 状态 | 判定条件 |
+| --- | --- |
+| 待核销 | 已具备核销对象，但尚未执行匹配 |
+| 核销中 | 自动或人工核销任务正在执行 |
+| 未核销 | 有效核销金额为 0 |
+| 部分核销 | 有效核销金额大于 0 且小于应核对金额 |
+| 已核销 | 有效核销金额等于应核对金额 |
+| 核销冲突 | 存在多个候选匹配且无法唯一确定 |
+| 暂停核销 | 因归属、数据质量或人工冻结暂停 |
+| 已撤销 | 原有效核销记录已撤销 |
+
+### 9.2 金额判定
+
+```text
+未核销金额
+= 支付明细应核对金额
+- 有效核销金额合计
+```
+
+| 金额结果 | 核销状态 |
+| --- | --- |
+| 有效核销金额 = 0 | 未核销 |
+| 0 < 有效核销金额 < 应核对金额 | 部分核销 |
+| 有效核销金额 = 应核对金额 | 已核销 |
+| 有效核销金额 > 应核对金额 | 金额异常，不允许进入已核销 |
+
+### 9.3 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待核销
+    待核销 --> 核销中
+    核销中 --> 未核销
+    核销中 --> 部分核销
+    核销中 --> 已核销
+    核销中 --> 核销冲突
+    待核销 --> 暂停核销
+    核销冲突 --> 核销中: 人工选择或规则修正
+    未核销 --> 核销中: 新账单或流水到达
+    部分核销 --> 核销中: 后续账单到达
+    已核销 --> 已撤销: 撤销有效核销
+    已撤销 --> 待核销: 重新核销
+    暂停核销 --> 待核销: 解除暂停
+```
+
+## 10. 渠道账单核销状态
+
+渠道账单明细可以关联一条或多条支付明细，其状态按照账单可核销金额计算：
+
+| 状态 | 定义 |
+| --- | --- |
+| 待核销 | 尚未执行支付明细匹配 |
+| 未核销 | 无有效支付明细核销 |
+| 部分核销 | 部分账单金额已关联支付明细 |
+| 已核销 | 账单可核销金额已全部匹配 |
+| 核销冲突 | 候选支付明细无法唯一确定 |
+| 超额核销 | 有效核销金额超过账单可核销金额 |
+| 已撤销 | 账单核销关系已撤销 |
+
+账单核销状态与渠道结算状态独立。一条账单明细可以已核销但尚未结算，也可以已进入结算单但订单侧仍未完成核销。
+
+## 11. 渠道结算状态
+
+### 11.1 状态定义
+
+| 状态 | 定义 | 是否异常 |
+| --- | --- | --- |
+| 待计算周期 | 尚未匹配 D+N/T+N 规则 | 否 |
+| 周期规则异常 | 规则缺失或同优先级冲突 | 是 |
+| 待结算 | 已计算预期结算日，尚在正常周期或宽限期内 | 否 |
+| 结算超期 | 超过预期结算日及宽限期仍无有效结算 | 是 |
+| 部分结算 | 累计有效归集金额小于可结算金额 | 视规则 |
+| 已结算 | 累计有效归集金额等于可结算金额 | 否 |
+| 结算异常 | 超额归集、重复归集或批次金额不平 | 是 |
+| 已撤销 | 原结算归集或结算单已撤销 | 否 |
+
+### 11.2 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待计算周期
+    待计算周期 --> 待结算: 唯一匹配周期规则
+    待计算周期 --> 周期规则异常: 规则缺失或冲突
+    周期规则异常 --> 待计算周期: 配置修正
+    待结算 --> 部分结算: 收到部分结算归集
+    待结算 --> 已结算: 一次完成结算
+    待结算 --> 结算超期: 超过宽限期
+    结算超期 --> 部分结算: 后到结算
+    结算超期 --> 已结算: 后到完整结算
+    部分结算 --> 已结算: 后续归集完成
+    部分结算 --> 结算异常: 超额或重复归集
+    已结算 --> 已撤销: 结算撤销
+    已撤销 --> 待结算: 重新归集
+```
+
+周期规则按客户企业、品牌和平台隔离，不跨品牌兜底。D+N/T+N 规则到期前不生成结算超期差异。
+
+## 12. 退款状态
+
+### 12.1 退款单状态
+
+| 状态 | 聚合条件 |
+| --- | --- |
+| 待拆分 | 尚未生成完整退款明细 |
+| 退款处理中 | 至少一条退款明细正在执行 |
+| 部分退款 | 部分退款明细完成，仍有未完成明细 |
+| 退款完成 | 全部退款明细完成 |
+| 退款失败 | 全部有效退款路径失败且未继续处理 |
+| 退款异常 | 存在超额、重复或原支付关联异常 |
+| 已撤销 | 退款单被有效撤销且未产生不可逆退款 |
+
+### 12.2 退款明细状态
+
+| 状态 | 定义 |
+| --- | --- |
+| 待退款 | 已关联原支付明细，尚无有效退款流水 |
+| 退款中 | 已发起退款，等待执行结果 |
+| 部分退款 | 有效退款流水金额小于业务退款金额 |
+| 退款完成 | 有效退款流水金额等于业务退款金额 |
+| 退款失败 | 实际退款执行失败 |
+| 退款冲突 | 多条流水、跨方式退款或重复退款风险待确认 |
+| 已撤销 | 退款明细已撤销 |
+
+### 12.3 退款明细流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待退款
+    待退款 --> 退款中: 发起退款
+    退款中 --> 部分退款
+    退款中 --> 退款完成
+    退款中 --> 退款失败
+    部分退款 --> 退款中: 继续退款
+    退款失败 --> 退款中: 重试或更换方式
+    退款完成 --> 退款冲突: 发现重复退款风险
+    退款冲突 --> 退款完成: 确认无重复
+    待退款 --> 已撤销: 撤销退款
+```
+
+退款状态按退款明细分别影响原支付明细，不使用退款单总状态一次性阻断订单下全部支付明细。
+
+## 13. 差异处理状态
+
+### 13.1 状态定义
+
+| 状态 | 定义 |
+| --- | --- |
+| 待分派 | 差异已生成，尚未确定责任人 |
+| 待处理 | 已分派，等待处理 |
+| 处理中 | 责任人正在调查或补充材料 |
+| 待协同 | 等待其他部门、门店、平台或上游系统处理 |
+| 待复核 | 处理人已提交结论，等待复核 |
+| 已关闭 | 差异已解决或确认不再构成异常 |
+| 暂缓处理 | 因外部条件或争议暂停 |
+| 已驳回 | 复核不通过，退回处理 |
+| 已失效 | 来源对象撤销或重新计算后差异不再有效 |
+
+### 13.2 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待分派
+    待分派 --> 待处理: 分派责任人
+    待处理 --> 处理中
+    处理中 --> 待协同: 需要外部协作
+    待协同 --> 处理中: 协作结果返回
+    处理中 --> 待复核: 提交处理结论
+    待复核 --> 已关闭: 复核通过
+    待复核 --> 已驳回: 复核不通过
+    已驳回 --> 处理中
+    处理中 --> 暂缓处理
+    暂缓处理 --> 处理中: 恢复处理
+    待分派 --> 已失效: 来源重算
+    待处理 --> 已失效: 来源重算
+```
+
+### 13.3 阻断状态
+
+差异处理状态和分账阻断属性分开保存：
+
+- 阻断：差异未关闭前对应支付明细不可分账。
+- 不阻断：可以继续分账，但差异仍需跟踪。
+- 人工暂缓：不改变差异性质，但人工控制对应支付明细暂缓分账。
+
+关闭差异不等于自动可分账，系统仍需重新执行全部分账前置条件。
+
+## 14. 对账确认状态
+
+| 状态 | 定义 |
+| --- | --- |
+| 待确认 | 核销结果已产生，但尚未完成综合检查 |
+| 确认中 | 系统或人工正在检查退款、费用、归属和差异 |
+| 已确认 | 支付明细确认金额及相关条件已确认 |
+| 确认失败 | 金额、归属或规则校验不通过 |
+| 已撤销 | 原确认结果失效 |
+| 待重新确认 | 后到数据、退款或配置变化要求重新确认 |
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待确认
+    待确认 --> 确认中
+    确认中 --> 已确认
+    确认中 --> 确认失败
+    确认失败 --> 待确认: 问题修复
+    已确认 --> 待重新确认: 后到数据或业务变化
+    已确认 --> 已撤销: 授权撤销
+    待重新确认 --> 确认中
+    已撤销 --> 待确认
+```
+
+人工确认不能将未平衡金额、冲突归属或超额核销强制改为已确认。
+
+## 15. 分账准备状态
+
+### 15.1 状态定义
+
+| 状态 | 定义 |
+| --- | --- |
+| 待判断 | 尚未执行分账前置条件检查 |
+| 不可分账 | 存在尚未满足的数据、核销、退款、归属或差异条件 |
+| 暂缓分账 | 条件基本满足，但因争议、调查、风险控制或人工冻结暂不输出 |
+| 可分账 | 所有前置条件满足，已形成可分账金额 |
+| 已失效 | 原可分账结果因退款、撤销或数据变化失效 |
+| 待重新计算 | 后到数据或规则变化要求重新计算 |
+
+### 15.2 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待判断
+    待判断 --> 不可分账: 前置条件不满足
+    待判断 --> 暂缓分账: 人工冻结或争议
+    待判断 --> 可分账: 前置条件全部满足
+    不可分账 --> 待判断: 数据或差异更新
+    暂缓分账 --> 待判断: 解除暂缓
+    可分账 --> 待重新计算: 退款或后到数据
+    可分账 --> 已失效: 撤销确认
+    待重新计算 --> 待判断
+    已失效 --> 待判断: 重新处理
+```
+
+### 15.3 可分账强制条件
+
+支付明细进入可分账至少需要：
+
+- 订单有效且支付平衡。
+- 归属状态为归属成功或人工已确认。
+- 对账确认状态为已确认。
+- 退款状态明确。
+- 不存在有效阻断型差异。
+- 支付明细结算主体关系已确认且金额平衡。
+- 未被人工冻结。
+- 场景要求等待渠道结算时，渠道结算条件已满足。
+
+## 16. 分账输出状态
+
+| 状态 | 定义 |
+| --- | --- |
+| 未输出 | 可分账结果已生成，尚未发送 |
+| 输出中 | 正在调用分账系统 |
+| 输出失败 | 调用失败或未收到有效回执 |
+| 已发送 | 请求已发送，等待接收确认 |
+| 已接收 | 分账系统确认接收成功 |
+| 已拒绝 | 分账系统拒绝接收 |
+| 已撤销 | 原输出版本被撤销 |
+| 已替换 | 已由新版本结果替换 |
+
+```mermaid
+stateDiagram-v2
+    [*] --> 未输出
+    未输出 --> 输出中
+    输出中 --> 已发送
+    输出中 --> 输出失败
+    已发送 --> 已接收
+    已发送 --> 输出失败: 回执超时
+    已发送 --> 已拒绝
+    输出失败 --> 输出中: 幂等重试
+    已拒绝 --> 未输出: 修正数据并生成新版本
+    已接收 --> 已撤销: 分账前撤销成功
+    已接收 --> 已替换: 新版本接收成功
+```
+
+只有收到分账系统有效接收回执后才能进入已接收。网络调用成功但无业务回执时仍不能视为已接收。
+
+页面如需使用“已输出分账”作为业务标签，应将其定义为输出状态已接收，不新增独立的“已输出”原子状态。
+
+## 17. 分账执行状态
+
+分账执行状态由分账系统生成并反馈，对账系统只记录：
+
+| 状态 | 定义 |
+| --- | --- |
+| 待分账 | 已接收但尚未执行 |
+| 分账中 | 正在执行分账 |
+| 部分成功 | 部分参与方分账成功 |
+| 分账成功 | 本次分账全部成功 |
+| 分账失败 | 本次分账失败 |
+| 已退回 | 分账资金被退回 |
+| 已冲正 | 原分账结果已执行冲正 |
+
+分账失败或退回不反向改变支付明细已核销状态，但会形成分账执行异常。
+
+## 18. 银行入账状态
+
+### 18.1 分账结果入账状态
+
+| 状态 | 金额判定 |
+| --- | --- |
+| 待入账 | 有效入账关联金额为 0 |
+| 部分入账 | 有效入账关联金额大于 0 且小于应入账金额 |
+| 已入账 | 有效入账关联金额等于应入账金额 |
+| 入账异常 | 有效关联金额超过应入账金额或关联冲突 |
+| 入账失败 | 银行或资金处理失败 |
+| 已退回 | 已入账资金发生退回 |
+
+### 18.2 流转
+
+```mermaid
+stateDiagram-v2
+    [*] --> 待入账
+    待入账 --> 部分入账: 收到部分有效入账
+    待入账 --> 已入账: 一次完整入账
+    待入账 --> 入账失败
+    部分入账 --> 已入账: 后续入账完成
+    部分入账 --> 入账异常: 超额或冲突关联
+    已入账 --> 已退回: 银行退回
+    入账失败 --> 待入账: 重新处理
+    已退回 --> 待入账: 重新发起入账
+```
+
+银行入账属于分账后状态，不回退订单、支付明细或账单的核销与结算状态。
+
+## 19. 订单聚合状态
+
+订单状态只用于汇总展示，不作为支付明细处理的替代状态。
+
+### 19.1 订单核销状态
+
+| 聚合状态 | 判定规则 |
+| --- | --- |
+| 待核销 | 全部有效支付明细均未进入核销 |
+| 未核销 | 全部有效支付明细均为未核销 |
+| 部分核销 | 支付明细状态不完全一致，或至少一条为部分核销 |
+| 已核销 | 全部有效支付明细均为已核销 |
+| 核销异常 | 至少一条支付明细存在核销冲突、超额或暂停 |
+
+### 19.2 订单结算状态
+
+| 聚合状态 | 判定规则 |
+| --- | --- |
+| 待结算 | 需要渠道结算的支付明细均未完成结算 |
+| 部分结算 | 仅部分需结算支付明细已结算，或存在部分结算 |
+| 已结算 | 全部需要渠道结算的支付明细均满足结算条件 |
+| 结算异常 | 存在周期规则异常、超期或结算异常 |
+| 不适用 | 订单全部由无外部结算的内部权益构成 |
+
+### 19.3 订单分账准备状态
+
+| 聚合状态 | 判定规则 |
+| --- | --- |
+| 全部不可分账 | 所有有效支付明细均不可分账 |
+| 部分可分账 | 至少一条可分账，且并非全部可分账 |
+| 全部可分账 | 所有有效支付明细均可分账 |
+| 部分暂缓 | 至少一条支付明细暂缓分账 |
+| 已全部输出 | 所有可分账支付明细均已被分账系统接收 |
+
+订单聚合状态不得阻止已满足条件的支付明细先行输出。
+
+## 20. 状态重算触发事件
+
+以下事件需要触发相关对象状态重算：
+
+- D+1 订单或支付批次到达、补传或修正。
+- 新渠道账单、结算单或结算归集明细到达。
+- D+N/T+N 预期结算日或宽限期到期。
+- 新退款单、退款明细或退款流水到达。
+- 权益流水、现金流水或现金汇缴批次到达。
+- 门店映射、经营主体关系或结算主体关系完成确认。
+- 费用项、容差规则或结算调整项发生变化。
+- 差异关闭、驳回、失效或阻断属性变化。
+- 人工冻结或解除冻结。
+- 可分账结果输出回执返回。
+- 分账结果或银行入账反馈返回。
+
+状态重算必须保证幂等，不得重复累计核销、结算、退款、可分账或入账金额。
+
+## 21. 状态变更审计
+
+每次状态变更至少记录：
+
+- 客户企业。
+- 对象类型和对象标识。
+- 状态维度。
+- 原状态和新状态。
+- 触发事件类型。
+- 触发数据或任务标识。
+- 系统规则版本。
+- 操作人或来源系统。
+- 状态变更时间。
+- 变更原因。
+- 是否人工操作。
+- 关联差异、核销、退款或输出版本。
+
+禁止直接修改状态字段而不产生状态变更记录。
+
+## 22. 页面展示规则
+
+1. 页面应分别展示核销、结算、退款、差异、分账准备、输出和入账状态。
+2. 不使用“已完成”作为跨流程通用状态。
+3. 订单列表展示聚合状态，支付明细列表展示原子状态。
+4. 状态标签必须可以追溯到金额和状态变更记录。
+5. 异常状态需要同时展示责任人、阻断属性和下一处理动作。
+6. D+1 截止前显示等待同步，不显示订单缺失。
+7. D+N/T+N 宽限期前显示待结算，不显示结算超期。
+
+## 23. 状态边界
+
+- 已支付不等于已核销。
+- 已核销不等于已结算。
+- 已结算不等于可分账。
+- 可分账不等于已输出。
+- 已输出不等于分账成功。
+- 分账成功不等于已入账。
+- 差异已关闭不等于自动可分账。
+- 订单已核销不代表订单下全部退款均已完成。
+- 银行入账异常不回退订单核销状态。
+
+## 24. 评审重点
+
+1. 状态是否全部归属于明确业务对象。
+2. 核销、结算、退款、差异、分账和入账是否相互独立。
+3. 支付明细状态能否准确聚合为订单展示状态。
+4. D+1 同步和 D+N/T+N 结算是否具有等待、超期和补传状态。
+5. 部分核销、部分结算、部分退款和部分入账是否均可表达。
+6. 撤销、冲正、重算和新版本是否不会覆盖历史结果。
+7. 人工状态变更是否具备权限、复核和审计要求。
+8. 状态是否能够直接支持后续页面、接口和测试设计。
diff --git a/10-产品线/连锁业务对账系统/README.md b/10-产品线/连锁业务对账系统/README.md
index 690e90a..1c8e692 100644
--- a/10-产品线/连锁业务对账系统/README.md
+++ b/10-产品线/连锁业务对账系统/README.md
@@ -9,3 +9,9 @@
 - [产品定位与业务闭环](01-产品定位与业务闭环.md)
 - [岗位业务需求总览](岗位业务需求/00-总览.md)
 - [标准可扩展数据模型规划](03-标准可扩展数据模型规划.md)
+- [产品规划与执行计划](04-产品规划与执行计划.md)
+- [核心业务术语与指标口径](06-核心业务术语与指标口径.md)
+- [业务对象与业务关系](07-业务对象与业务关系.md)
+- [连锁餐饮对账场景清单](08-连锁餐饮对账场景清单.md)
+- [端到端业务流程](09-端到端业务流程.md)
+- [状态流转设计](10-状态流转设计.md)