Files
zd_product_document/10-产品线/连锁业务对账系统/07-业务对象与业务关系.md
2026-06-22 11:56:17 +08:00

24 KiB

连锁业务对账系统业务对象与业务关系

1. 文档目的

本文档用于定义连锁业务对账系统中的核心业务对象及其关系,作为业务场景、数据模型、权限、对账规则和系统集成设计的基础。

本文件已通过 P1-02 业务对象与业务关系评审。对象字段、业务唯一键和状态机将在标准数据模型详细设计阶段进一步展开。

2. 对象分层

对象层级 核心对象 作用
组织经营层 客户企业、品牌、区域、加盟商、门店、门店经营主体关系、经营主体 确定租户隔离、业务归属和数据权限
资金结算层 结算主体、支付明细结算主体关系、商户号、银行账户、门店现金账户 确定资金结算和入账归属
业务交易层 业务类型、下单方式、订单来源、履约方式、业务订单、退款单、退款明细、退款流水 记录业务发生和退款事实
支付权益层 支付明细、团购券、平台优惠券、储值账户 记录订单支付构成
渠道账单层 结算渠道、渠道结算周期规则、渠道门店、门店映射关系、渠道账单明细、渠道结算单、渠道结算归集明细、渠道结算批次、费用项、结算调整项 记录渠道交易、费用和结算事实
对账核销层 核销记录、差异记录、可分账结果 记录对账过程和输出结果
分账反馈层 分账结果、分账入账反馈、分账结果入账关联明细 记录分账系统返回的后置结果

3. 组织经营对象

3.1 客户企业

客户企业是使用对账系统并承担数据隔离责任的租户主体。

一个客户企业可以管理一个或多个品牌。客户扩展字典、渠道接入配置、权限范围和业务数据均需要归属于客户企业;所有客户级编码必须在客户企业范围内唯一。

3.2 品牌

品牌是连锁经营业务的管理和产品归属对象。

一个客户企业可以管理一个或多个品牌。品牌下可以包含区域、加盟商和门店。

3.3 区域

区域是品牌对门店进行运营管理和数据统计的组织维度,可以按大区、省、市或企业自定义区域划分。

区域不是必然的资金结算主体。

3.4 加盟商

加盟商是管理一家或多家加盟门店的经营管理对象。

加盟商在对账系统中原则上是其旗下门店的汇总维度,不替代门店作为订单、支付和对账明细的归属对象。

3.5 门店

门店是连锁业务对账的核心经营和数据落地对象。

订单、支付明细、退款、券核销、现金账户、渠道门店映射和差异原则上都需要归属到门店。

门店经营类型固定为四类:

  • 直营门店。
  • 加盟门店。
  • 联营门店。
  • 托管门店。

经营类型只描述门店的经营合作关系,不承载门店形态、收银、结算、收益分配和管理责任等其他语义。

3.6 门店经营属性

门店需要维护以下相互独立的经营属性:

属性 标准分类 对账用途
门店形态 标准店、店中店、档口店、快闪店、云店 支持门店经营分析及识别无独立经营场所的门店
收银模式 门店独立收银、品牌统一收银、平台直接收款 判断订单和支付数据来源、收款链路及现金账户责任
结算模式 门店自结、总部代收代结、多主体结算 判断渠道账单、结算主体和分账前置归属
收益规则 自营收益、固定管理费、营业额分成、毛利分成、利润分成 作为合同范围内的收益规则,为分账系统提供规则匹配依据
管理归属 总部管理、区域管理、加盟商管理、第三方托管 确定异常处理、业务确认和数据权限责任

门店形态原则上是门店级基础分类。收银模式和结算模式可以按门店、渠道及业务类型配置;收益规则和管理归属通过独立配置关系按门店及合同维护。同一门店允许在不同渠道、业务类型或合同范围内采用不同配置。

上述属性需要记录适用范围、生效日期、失效日期、状态和变更原因。历史订单、支付明细、账单、核销及分账输出必须按照业务发生日期使用当时有效的配置,不得使用当前配置覆盖历史结果。

3.7 经营主体

经营主体是依法或按合同实际承担门店经营责任的法人、个体工商户或其他主体。

一个经营主体可以经营一家或多家门店。同一家门店在同一自然日只能对应一个经营主体。

经营主体与品牌、加盟商不必一一对应。

3.8 门店经营主体关系

门店经营主体关系用于记录门店在指定自然日由哪个经营主体承担经营责任,至少包括门店、经营主体、生效日期、失效日期、状态、变更原因和审计信息。

门店与经营主体的关系需要按自然日维护有效期:

  • 关系生效时间精度至少到自然日。
  • 同一门店的经营主体关系在同一自然日内不得重叠。
  • 门店经营主体发生变更时,新关系从下一自然日开始生效。
  • 历史订单、支付明细、账单和差异按照业务发生日期关联当日经营主体。
  • 经营主体变更不得覆盖历史业务归属。

业务约束为:

客户企业 + 门店 + 自然日,只能匹配一条有效的门店经营主体关系

4. 资金结算对象

4.1 结算主体

结算主体是与支付渠道、平台或分账系统发生资金结算的主体。

结算主体可能是:

  • 品牌总部。
  • 区域公司。
  • 加盟商经营主体。
  • 门店经营主体。
  • 其他经授权主体。

经营主体与结算主体可以相同,也可以不同。

4.2 支付明细结算主体关系

同一支付明细允许拆分到多个结算主体。支付明细与结算主体之间为多对多关系,通过“支付明细结算主体关系”实体维护。

该关系描述支付明细在业务和渠道上的结算归属,不等同于分账系统最终计算的分账结果。

关系实体至少需要记录:

  • 支付明细。
  • 结算主体。
  • 结算归属类型。
  • 结算归属金额。
  • 结算归属比例。
  • 归属依据。
  • 来源系统。
  • 生效状态。
  • 确认状态。
  • 确认人和确认时间。

结算归属金额需要满足:

支付明细确认金额
= 该支付明细对应各结算主体的结算归属金额合计

如果结算主体关系尚未确认,支付明细不能进入可分账状态。

结算归属金额以支付明细确认金额为基准,不以扣除结算调整项后的支付明细可分账金额为基准。结算调整项另行记录,最终参与方收益分配由分账系统计算。

分账系统接收支付明细可分账结果及结算主体关系后,再根据分账规则生成最终分账结果。

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. 核心关系

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 业务对象与业务关系评审通过,当前不存在阻断后续业务场景设计的对象级问题。

以下内容转入标准数据模型详细设计阶段:

  • 各对象业务唯一键和客户企业隔离键。
  • 各关系实体的数据库唯一约束及有效期重叠校验。
  • 渠道结算归集、退款核销和分账入账关联的状态机。
  • 金额累计上限、撤销、冲正和重新确认机制。