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

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

1. 核心判断

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

原因在于：

• 连锁企业业态会变化，餐饮、鞋服、零售、药店的订单结构不同。
• 业务类型会变化，堂食、外卖、团购、电商、私域商城、储值、医保等场景不断增加。
• 结算渠道会变化，支付渠道、平台渠道、聚合支付、银行入账、医保结算等渠道的账单格式和结算规则不同。
• 渠道字段会变化，同一个渠道在不同时期也可能调整字段、账单类型、费用项和结算周期。

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

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

2. 数据模型设计目标

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

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

3. 分层模型

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

层级	作用	典型数据
原始数据层	保留外部系统原始数据，便于追溯和重放	原始订单报文、原始账单文件、原始接口返回
标准明细层	将不同来源数据转换为系统统一模型	标准订单、标准支付明细、标准渠道账单、标准退款、标准费用
对账核销层	承载订单与账单的匹配、核销、差异和状态	核销记录、匹配关系、差异记录、处理记录
输出服务层	面向分账、报表、审计等下游系统输出稳定结果	可分账订单、对账结果、差异结果、报表指标

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

4. 核心对象模型

4.1 标准订单

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

核心字段包括：

字段类别	字段示例	说明
业务标识	订单号、外部订单号、平台订单号	用于识别订单及与外部系统追溯
组织归属	品牌、区域、加盟商、门店、经营主体	用于数据权限、门店对账和分账归属
业务分类	行业、业务类型、订单来源平台	区分堂食、外卖、团购、电商、私域商城等场景
时间信息	订单发生时间、支付时间、退款时间	用于日结、月结和到账周期分析
金额信息	订单应收金额、实收金额、优惠金额、退款金额	用于与渠道账单核销
支付汇总	支付状态、支付总金额、支付方式数量	用于描述订单整体支付结果，不承载具体支付明细
状态信息	订单状态、支付状态、退款状态、对账状态	用于跟踪订单生命周期

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

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

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

4.2 标准支付明细

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

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

核心字段包括：

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

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

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

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

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

4.3 标准渠道账单

标准渠道账单是对账系统的实收基础，描述渠道“实际结算了多少钱”。

核心字段包括：

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

4.4 标准费用项

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

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

核心字段包括：

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

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

4.5 核销记录

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

核心字段包括：

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

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

4.6 差异记录

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

核心字段包括：

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

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

4.7 可分账结果

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

核心字段包括：

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

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

5. 渠道扩展机制

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

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

标准接入路径应为：

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

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

每个渠道至少需要配置：

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

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

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

处理方式：

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

6. 模型边界

6.1 标准模型必须稳定

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

• 标准订单
• 标准支付明细
• 标准渠道账单
• 标准费用项
• 核销记录
• 差异记录
• 可分账结果

6.2 可扩展部分允许变化

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

• 原始报文字段
• 渠道字段映射
• 费用项类型
• 金额计算口径
• 时间取值口径
• 匹配规则优先级
• 差异识别规则
• 报表展示字段

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

不建议采用以下设计：

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

7. 对功能规划的影响

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

第一阶段应优先建设：

• 标准订单模型
• 标准支付明细模型
• 标准渠道账单模型
• 标准费用项模型
• 核销记录模型
• 差异记录模型
• 可分账结果模型
• 渠道字段映射能力
• 基础匹配规则配置能力

暂不应优先建设：

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

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