zd_product_document/10-产品线/连锁业务对账系统/03-标准可扩展数据模型规划.md

连锁业务对账系统标准可扩展数据模型规划

1. 核心判断

连锁业务对账系统的长期难点，不只是接入某几个收银系统或结算渠道，而是建立一套标准、稳定、可扩展的数据模型。

原因在于：

• 连锁企业业态会变化，餐饮、鞋服、零售、药店的订单结构不同。
• 业务类型、下单方式、订单来源和履约方式会变化，不同业态和客户需要扩展自己的分类。
• 结算渠道会变化，支付渠道、平台渠道、聚合支付、银行入账、医保结算等渠道的账单格式和结算规则不同。
• 渠道字段会变化，同一个渠道在不同时期也可能调整字段、账单类型、费用项和结算周期。

因此，系统设计不能以某个渠道账单字段作为核心模型，也不能为每个渠道单独建立一套对账逻辑。正确方向是：

以标准订单、标准账单、标准核销、标准差异、标准输出为主模型，以渠道适配层承接不断变化的外部渠道差异。

2. 数据模型设计目标

标准数据模型需要满足以下目标：

• 支持多行业、多业务类型、多结算渠道。
• 支持订单、组合支付、退款、手续费、佣金、补贴、入账等多类金额。
• 支持渠道账单字段差异，但不让渠道差异污染核心核销模型。
• 支持一笔订单包含多种支付方式、一笔订单对应一笔账单、一笔订单对应多笔账单、多笔订单对应一笔账单等匹配关系。
• 支持跨日结算、分批结算、部分退款、补贴后结算、平台扣费后结算等复杂场景。
• 支持对账结果向分账系统稳定输出，不因新增渠道而频繁改变接口。

3. 分层模型

对账系统的数据模型应分为四层：

层级	作用	典型数据
原始数据层	保留外部系统原始数据，便于追溯和重放	原始订单报文、原始账单文件、原始接口返回
标准明细层	将不同来源数据转换为系统统一模型	标准订单、标准支付明细、标准退款、支付明细结算主体关系、门店经营主体关系、门店映射关系、渠道结算周期规则、渠道账单明细、渠道结算单、渠道结算归集明细、标准费用
对账核销层	承载订单与账单的匹配、核销、差异和状态	核销记录、匹配关系、差异记录、处理记录
输出服务层	向分账系统输出稳定结果，并接收分账后的入账反馈	可分账结果、对账结果、分账入账反馈、报表指标

这种分层可以保证：外部渠道变化时，优先调整原始数据解析和标准化映射，不直接冲击核销规则、差异处理和分账输出。

4. 核心对象模型

4.1 标准订单

标准订单是对账系统的应收基础，描述业务订单“应该收多少钱”。

核心字段包括：

字段类别	字段示例	说明
业务标识	订单号、外部订单号、平台订单号	用于识别订单及与外部系统追溯
组织归属	客户企业、品牌、区域、加盟商、门店、经营主体	用于租户隔离、数据权限、门店对账和分账归属
门店经营属性	经营类型、门店形态、收银模式、结算模式、收益规则、管理归属	用于解释收款、结算、收益和责任归属
业务分类	行业、业务类型、下单方式、订单来源、履约方式	分别描述经营场景、下单入口、来源系统和交付方式
时间信息	订单发生时间、支付时间、退款时间	用于日结、月结和到账周期分析
金额信息	订单应收金额、实收金额、优惠金额、退款金额	用于与渠道账单核销
支付汇总	支付状态、支付总金额、支付方式数量	用于描述订单整体支付结果，不承载具体支付明细
状态信息	订单状态、支付状态、退款状态、对账状态	用于跟踪订单生命周期

标准订单不应直接承载具体支付渠道、支付流水和商户号。原因是一个订单可能包含多种支付方式，例如：

• 三方团购券核销 + 在线支付
• 三方团购券 + 在线支付 + 私域现金券
• 会员储值余额 + 微信支付
• 平台优惠券 + 商家优惠券 + 用户实付

具体支付构成应进入标准支付明细模型。

门店经营属性不应只保存当前值。标准订单需要根据订单发生日期保留当时有效的经营主体和关键经营属性快照，避免基础资料变更后改变历史对账结果。经营类型固定为直营、加盟、联营、托管四类；收银模式和结算模式可按渠道及业务类型生效，收益规则和管理归属可按合同范围生效。

4.2 标准支付明细

标准支付明细描述一笔订单的支付构成，是连接订单应收、渠道账单和核销结果的关键中间模型。

一笔标准订单可以对应多条标准支付明细。每条支付明细代表一种支付方式、一种券核销、一种储值扣减或一种平台权益抵扣。

核心字段包括：

字段类别	字段示例	说明
关联标识	订单号、支付明细号、外部支付明细号	用于关联标准订单和外部支付记录
支付分类	支付大类、支付方式、支付来源平台	区分在线支付、团购券、现金券、储值、优惠券、医保等
渠道信息	支付渠道、商户号、渠道流水号、平台券码、核销码	用于匹配渠道账单、平台账单或券核销记录
金额信息	支付金额、核销金额、优惠金额、用户实付金额、退款金额	用于拆分订单应收与各支付组成
承担信息	用户承担、平台承担、商家承担、品牌承担、加盟商承担	用于解释金额差异并支撑后续分账
时间信息	支付时间、核销时间、退款时间	用于对账和到账周期分析
状态信息	支付状态、核销状态、退款状态、对账状态	用于跟踪每条支付明细的生命周期

标准支付明细需要支持以下组合支付场景：

场景	支付明细示例	对账重点
团购券 + 在线支付	团购券核销明细、微信或支付宝支付明细	团购平台是否结算券款，在线支付是否到账
团购券 + 在线支付 + 私域现金券	团购券核销明细、在线支付明细、私域现金券抵扣明细	区分平台结算金额、用户实付金额和品牌自承担优惠
储值 + 在线支付	储值扣减明细、在线支付明细	储值账户内部扣减和外部支付渠道结算不能混为一类
平台优惠 + 用户实付	平台补贴明细、商家优惠明细、用户支付明细	识别优惠承担方，避免把优惠误认为渠道少结

标准支付明细的设计原则：

• 订单金额口径在标准订单中表达，支付构成在标准支付明细中表达。
• 每条支付明细可以独立对账，也可以参与订单整体对账。
• 外部有渠道账单的支付明细，需要与标准渠道账单明细核销，并通过渠道结算单及结算批次判断是否完成结算。
• 内部权益类支付明细，如私域现金券、储值余额，需要与内部权益或账户流水核对。
• 优惠、补贴、券抵扣不能简单等同于渠道实收，应区分用户实付、平台承担和商家承担。

4.3 支付明细结算主体关系

支付明细结算主体关系用于表达一条支付明细可以拆分归属到多个结算主体。

核心字段包括：

字段类别	字段示例	说明
关联对象	支付明细标识、结算主体标识	建立支付明细与结算主体的多对多关系
归属信息	结算归属类型、归属依据、来源系统	说明该结算归属如何产生
金额信息	结算归属金额、结算归属比例	描述支付明细在各结算主体之间的归属
状态信息	待确认、已确认、已失效	控制是否允许进入可分账输出
审计信息	确认人、确认时间、变更原因	支持关系变更追溯

同一支付明细下各结算主体的结算归属金额合计必须等于支付明细确认金额。结算归属金额的基准是支付明细确认金额，不是扣除结算调整项后的支付明细可分账金额；结算调整项及最终收益分配由后续对象和分账系统分别处理。

该关系是对账系统确认的结算归属，不是分账系统最终生成的参与方分账结果。

4.4 标准退款

标准退款由退款单、退款明细和退款流水组成。

对象	作用	核心关系
退款单	记录一次业务退款请求	必须关联原业务订单
退款明细	将业务退款金额拆分到原支付构成	必须关联退款单和原支付明细
退款流水	记录渠道、券账户、储值账户或现金账户实际执行结果	一条退款明细可对应多条退款流水

退款明细需要记录业务退款金额、原支付明细、计划退款方式、是否原路退款和退款状态。退款流水需要记录实际退款方式、渠道流水号、实际退款金额、执行时间和执行状态，以支持部分退款、分次退款、失败重试及线上支付现金退款。

4.5 渠道结算周期规则

渠道结算周期规则用于计算三方平台账单的预期结算日期，支持 D+N 和 T+N。

核心字段包括客户企业、品牌、结算渠道、商户号、结算主体、业务类型、支付方式、周期类型、基准事件类型、N 值、日历类型、日切截点、时区、节假日顺延规则、宽限期、生效日期和失效日期。

品牌是规则必选隔离维度，不允许跨品牌复用平台默认规则。规则匹配应在同一品牌和平台内优先使用商户号、结算主体、业务类型和支付方式范围更精确的配置，但同一业务范围和有效期内不得存在两个同优先级有效规则。无法唯一匹配时生成配置差异，不计算唯一预期结算日。

4.6 标准渠道账单明细

标准渠道账单明细描述渠道侧交易、退款、费用和补贴事实，是支付明细核销的主要外部依据。

核心字段包括：

字段类别	字段示例	说明
渠道标识	渠道类型、渠道名称、商户号、渠道门店号	用于识别账单来源和门店归属
流水标识	渠道交易流水号、渠道订单号、平台订单号、结算单号、券核销单号	用于匹配订单、支付明细和追溯渠道数据
时间信息	交易时间、账单时间、账单日期	用于判断渠道交易和账单事实发生时间
金额信息	交易金额、退款金额、手续费、佣金、补贴、账单净额	用于核销支付明细和识别差异
费用信息	平台服务费、配送费、包装费、渠道手续费、营销费用	用于解释账单实收与订单应收差异
归属信息	品牌、门店、加盟商、经营主体	用于门店对账和分账前置归属
状态信息	账单状态、核销状态、差异状态	用于对账流程控制

4.7 渠道结算单

渠道结算单描述渠道针对结算主体、商户号或结算周期确认的应结算结果。

核心字段包括结算单号、结算渠道、结算主体、商户号、结算周期、交易金额、退款金额、费用金额、补贴金额、调整金额、应结算金额、结算状态和确认时间。

4.8 渠道结算归集明细

渠道结算归集明细连接渠道账单明细与渠道结算单，并记录归集金额、归集类型和状态。该关系必须支持多对多，以表达部分结算和分批结算。

任一渠道账单明细的累计有效归集金额不得超过其可结算金额；渠道结算单金额必须能够由归集明细、费用项和结算调整项解释。

4.9 渠道结算批次

渠道结算批次描述渠道实际发起的一次结算处理，记录批次号、包含的结算单、计划结算日期、实际结算日期、批次金额和批次状态。

渠道结算完成不等同于银行入账。对账系统在此确认渠道结算事实，分账后的银行入账仍由分账系统反馈。

4.10 门店经营主体关系

门店经营主体关系记录门店、经营主体、生效日期、失效日期、状态和变更审计信息。系统必须保证同一客户企业、同一门店、同一自然日只能匹配一条有效关系。

4.11 门店映射关系

门店映射关系是连接系统门店、结算渠道、商户号和渠道门店的独立标准对象，用于将外部订单和渠道账单明细准确归属到系统门店。

核心字段包括：

字段类别	字段示例	说明
系统对象	系统门店标识	对账系统中的标准门店
渠道对象	结算渠道、商户号、渠道门店标识	外部渠道用于识别交易和门店的信息
映射信息	映射类型、数据来源	描述使用何种渠道标识匹配门店
有效期	生效时间、失效时间	支持门店和商户关系历史变化
状态信息	待确认、有效、失效、冲突	控制映射是否能够用于自动归属
人工处理信息	冲突原因、处理状态、确认门店、确认人、确认时间、处理说明	支持冲突确认和审计追溯

门店归属解析必须按业务或账单发生时间使用当时有效的映射关系。无法匹配、匹配到多个有效关系或出现映射冲突时，系统必须产生门店映射差异并转人工确认，不允许通过匹配优先级自动选择门店。人工确认唯一门店前，相关数据不得继续执行自动核销和可分账处理。

4.12 标准费用项

费用项用于承接不同渠道不断变化的扣费、佣金、补贴和优惠承担规则。

费用项不建议全部固化为账单主表字段，应作为可扩展明细处理。

核心字段包括：

字段	说明
费用项类型	手续费、平台佣金、配送费、包装费、服务费、营销费、补贴、优惠券承担
费用项方向	增加实收、减少实收、仅用于说明
金额	费用项金额
承担方	品牌、门店、加盟商、平台、渠道、用户
来源渠道	微信、支付宝、美团、饿了么、抖音、电商平台等
关联对象	关联订单、支付明细、渠道账单明细、渠道结算单或退款单

这样设计可以避免每新增一种平台费用，就修改核心账单模型。

4.13 核销记录

核销记录描述订单、支付明细与渠道实收之间的匹配关系，是对账结果的核心。

核心字段包括：

字段	说明
核销批次	一次对账任务生成的批次
订单标识	关联标准订单
支付明细标识	关联标准支付明细，组合支付场景下用于定位具体支付组成
账单标识	关联标准渠道账单明细
核销金额	本次用于核销的金额
核销类型	正常核销、部分核销、退款核销、券核销、权益核销、人工核销
匹配依据	订单号、支付明细号、渠道流水号、核销码、商户号、门店、金额、时间等
核销状态	待核销、核销中、未核销、部分核销、已核销、核销冲突、暂停核销、已撤销
生成方式	自动生成、人工确认、人工调整

核销记录需要支持多对多关系，不能假设订单和账单永远是一对一。组合支付场景下，系统应优先在支付明细维度完成核销，再汇总形成订单维度的对账结果。

4.14 差异记录

差异记录描述对账过程中发现的问题及处理结果。

核心字段包括：

字段	说明
差异类型	未结算、少结、多结、订单缺失、账单缺失、退款异常、手续费异常、门店归属异常
差异对象	订单、支付明细、账单、核销记录或费用项
差异金额	对账差异金额
差异原因	系统识别原因或人工确认原因
处理状态	待分派、待处理、处理中、待协同、待复核、已关闭、暂缓处理、已驳回、已失效
处理结果	补账、调整、确认无误、转人工、暂缓分账
处理留痕	处理人、处理时间、说明、附件

差异记录应独立于订单和账单主模型，避免用订单状态承载过多异常处理语义。

4.15 可分账结果

可分账结果是对账系统输出给分账系统的稳定数据对象。

核心字段包括：

字段类别	字段示例	说明
订单信息	订单号、业务类型、订单来源平台、订单发生时间	用于分账系统识别业务来源
支付构成	支付明细号、支付方式、支付明细金额、支付来源平台、优惠和券承担方	用于按支付明细确定和输出可分账金额
归属信息	品牌、门店、加盟商、经营主体、支付明细结算主体关系	用于分账规则匹配
金额信息	订单应收金额、支付明细确认金额、手续费、退款金额、支付明细可分账金额、订单可分账金额	用于分账计算输入
渠道信息	支付渠道、商户号、渠道流水号、券核销单号、结算时间	用于资金、券核销和渠道追溯
对账信息	对账状态、核销批次、差异处理结果、确认时间	用于判断是否允许分账
分账准备状态	待判断、不可分账、暂缓分账、可分账、已失效、待重新计算	用于判断当前结果是否允许输出
输出状态	未输出、输出中、输出失败、已发送、已接收、已拒绝、已撤销、已替换	用于接口跟踪和版本管理

分账系统应依赖可分账结果对象，而不是直接读取订单表、支付明细表、渠道账单明细表或渠道结算单表。

可分账结果应以支付明细为最小输出粒度。同一订单下不同支付明细可以具有不同的分账准备状态和可分账金额，订单级结果仅作为支付明细结果的汇总。

4.16 分账入账反馈

分账入账反馈是分账系统完成分账后返回给对账系统的汇总资金结果。

核心字段包括：

字段类别	字段示例	说明
批次信息	分账批次号、入账批次号	关联分账执行和银行汇总入账
收款信息	收款主体、银行账户	识别实际入账对象
金额信息	应入账金额、实际入账金额、入账差异金额	验证分账结果和银行入账
时间信息	分账完成时间、银行入账时间、反馈时间	计算分账入账周期
状态信息	待入账、部分入账、已入账、入账异常、入账失败、已退回	跟踪入账结果
关联信息	分账结果、可分账结果、订单范围	支持从汇总入账追溯到原始业务

银行原则上汇总入账，因此该对象需要支持一笔入账关联多笔分账结果，不要求与单笔订单一对一匹配。

4.17 分账结果入账关联明细

分账结果入账关联明细连接分账结果与分账入账反馈，并记录本次关联金额、状态和确认时间。

该关系必须支持多对多：一笔分账结果可以分多次入账，一笔汇总入账可以关联多笔分账结果。分账结果的累计有效关联金额不得超过其应入账金额。

5. 渠道扩展机制

5.1 渠道接入不直接改变核心模型

新增结算渠道时，不应直接新增一套核心订单、核心账单或核心核销逻辑。

标准接入路径应为：

渠道原始账单
  ↓
渠道解析器
  ↓
字段映射规则
  ↓
标准渠道账单明细
  ↓
标准费用项
  ↓
统一核销规则
  ↓
标准对账结果

5.2 渠道适配需要配置化承接

每个渠道至少需要配置：

配置项	作用
渠道类型	区分支付渠道、外卖平台、团购平台、电商平台、银行、医保等
账单类型	区分交易账单、结算账单、退款账单、手续费账单、入账流水
字段映射	将渠道字段映射到标准账单字段
金额口径	定义交易金额、退款金额、费用金额、实收金额、入账金额的计算方式
时间口径	定义交易时间、结算时间、入账时间、账单日期的取值规则
匹配规则	定义订单和账单的匹配字段和优先级
差异规则	定义金额容差、跨日结算、分批结算、退款处理等规则

5.3 渠道特殊字段进入扩展字段

渠道特殊字段可以保留，但不应强行进入核心字段。

处理方式：

• 核心核销必须使用标准字段。
• 渠道原始字段完整保留在原始数据层。
• 对报表或追溯有价值但不具备通用性的字段，进入扩展字段。
• 扩展字段可以按渠道、业务类型、账单类型分组管理。

6. 模型边界

6.1 标准模型必须稳定

以下对象应保持稳定，不随单个渠道变化频繁调整：

• 标准订单
• 标准支付明细
• 标准退款
• 支付明细结算主体关系
• 门店经营主体关系
• 门店映射关系
• 渠道结算周期规则
• 标准渠道账单明细
• 渠道结算单
• 渠道结算归集明细
• 渠道结算批次
• 标准费用项
• 核销记录
• 差异记录
• 可分账结果
• 分账入账反馈
• 分账结果入账关联明细

6.2 可扩展部分允许变化

以下部分应允许按渠道和业务类型扩展：

• 业务类型字典
• 下单方式字典
• 订单来源字典
• 履约方式字典
• 门店形态字典
• 收银模式配置
• 结算模式配置
• 收益规则配置
• 管理归属配置
• 原始报文字段
• 渠道字段映射
• 费用项类型
• 金额计算口径
• 时间取值口径
• 匹配规则优先级
• 差异识别规则
• 报表展示字段

业务类型、下单方式、订单来源和履约方式采用平台标准字典与客户扩展字典并存的模式。客户扩展值需要使用客户企业范围内唯一编码，并映射到平台标准分类。字典项需要支持生效、停用和历史追溯；已被业务数据引用的编码不得删除或修改。

门店经营属性需要区分稳定分类和时态配置：经营类型使用四类标准值；门店形态允许在标准分类基础上扩展；收银模式、结算模式、收益规则和管理归属按适用范围及有效期配置；经营主体继续使用独立的门店经营主体关系维护。

6.3 不应把渠道差异写死在主流程

不建议采用以下设计：

• 为每个渠道单独开发一套核销流程。
• 在核心账单表中无限增加渠道专属字段。
• 把费用项全部固化为主表字段。
• 让分账系统直接适配各渠道账单格式。
• 用人工导入表结构替代标准账单模型。

7. 对功能规划的影响

数据模型规划会直接影响功能建设顺序。

第一阶段应优先建设：

• 标准订单模型
• 标准支付明细模型
• 标准退款模型
• 支付明细结算主体关系模型
• 门店经营主体关系模型
• 门店映射关系模型
• 渠道结算周期规则模型
• 标准渠道账单明细模型
• 渠道结算单模型
• 渠道结算归集明细模型
• 渠道结算批次模型
• 标准费用项模型
• 核销记录模型
• 差异记录模型
• 可分账结果模型
• 分账入账反馈模型
• 分账结果入账关联明细模型
• 渠道字段映射能力
• 基础匹配规则配置能力

暂不应优先建设：

• 全量字段自定义平台
• 复杂低代码数据建模平台
• 面向所有行业的通用主数据平台
• 跨系统财务总账模型

第一阶段的重点不是做一个无限泛化的平台，而是建立足够稳定的核心模型和必要的渠道扩展机制，让后续新增结算渠道时主要通过映射、规则和费用项扩展完成适配。