您的位置:  首页 > 技术杂谈 > 正文

交易履约之结算平台实践 | 京东云技术团队

2023-10-10 11:03 https://my.oschina.net/u/4090830/blog/10116562 京东云开发者 次阅读 条评论

导读

京东科技业务在快速发展的同时,产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点,且无法满足“风法财审”对于资金流程的管控要求,在此背景下金道结算平台孕育而生。本文从系统建设的背景、设计细节、已支撑案例及适用业务场景多个层面进行详细阐述。读者可以关注文中所讲的系统实践过程,进而对结算领域系统设计能力提升,具有一定的参考价值。

一、概述

1.1 背景

业务在快速发展的同时,产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点,且无法满足“风法财审”对于资金流程的管控要求。金道结算平台应运而生,专注于内部中心化流量场外的、通过外部场或搭建撮合平台进行获客、转化的场景,支撑业务方面向客户、合作伙伴、经销商、供应商等多利益相关方,实现快速、专业、高效、准确的线上化计费结算解决方案提供和能力支持。金道结算平台对接各垂直业务系统,实时同步业务的交易数据,并经过标准的结算流程(数据标准化预处理,清分,计费,分摊,结算单生成、运营确认等),最终通过财务渠道或其他支付渠道完成资金结算,有效降低了各业务系统结算成本的投入,提升业务资金流转的健康度,为业务的快速增长赋能。

1.2 痛点

业务系统在开展业务时,以当前线下处理的方式,普遍存在以下痛点:

计算难:计算规则复杂,数据量大,人工难以处理;

响应慢:现有业务变化快和新增业务速度快,人工效率较低,难以快速响应新资金结算模式;

风险高:人工计费、核对、结算数据风险高且不合规,难以溯源,操作风险高;

运营难:基础数据不完善,线下无法多维度分析,无法精准管理业务成本,及时调整策略;

成本大:人工结算的方式,投入的时间和资源成本高。

1.3 定位

金道结算平台深耕业务场景,打通平台接口,支持跨平台结算,是业财一体化的桥梁,为平台型交易及全域营销赋能。

图1 平台定位

1.4 优势

金道平台的建设,在解决业务痛点基础上,平台优势能够从几个层面体现:

1. 计费准确:支持大数据量计费,准确性达99.99%;

2. 结算快速:灵活支持按日或月等维度结算,缩短结算账期,实现资金快速收付;

3. 运营精细:支持业务精细化运营,助力业务发展;

4. 成本降低:提高运营效率,节省成本。

二、系统架构介绍

2.1 名词解释

名词解释
清分清分是在清算前对数据标准化处理阶段。在本文中,清分指的是对交易明细数据的核对、识别、调整及打标操作。
清算清算是标准化数据的计算及核对过程,本文清算主要完成标准化数据的核对、计费及分摊处理。
结算结算是汇总账单,并完成资金最终转移的过程。本文中的结算指的是对清算明细数据,以不同的维度生成结算单并确认,最终通过财务系统完成收付款的整个过程。
计费本文中指:单据数据按一定计算规则,生成的结果金额及过程金额。
分摊本文中指:费用存在多个承担方,在清算过程中,会把计费的结果金额,再次按分摊的规则划分到各方。
累额本文中指:累额服务于分摊动作,具体过程 为分摊规则中配置了每个承担方最大的承担上限,那么在计费后需要分摊时,需要参考承担方已累加金额是否到了上限,如果到了上限,则此方不进行分摊金额,否则正常累加本次金额。
冲正本文中指:同一单据重新计费、分摊时,需要把此单据在原累加总额值减去,再累加上本次金额。
重置本文中指:顺序清算场景时,业务线需要在历史的某个单据向后重新清算时,累额中需要把总额回退到此单据清算时累加的总额快照,并标识累额流水中哪些是效数据。

表1 名词解释

2.2 服务域设计

图2 服务域划分

平台基于DDD思想,划分清分域、清算域、结算域及报表域四个大域,每个子域又依次划分了自己的子域。

2.3 整体架构图

图3 整体架构图

说明:

1. 金道平台从数据处理流向上,自上而下划为分数据源、清分、清算、结算及下游,从使用群体上分为零售客户及科技客户。

2. 业务数据通过实时或离线两种方式接入平台。在清分中判别数据归属清分类型(通用流程或个性化流程),而进入不同的清分处理流程。清分域主要是按一定的规则对原始数据进行核对、识别、调整及打标动作,为清算做好数据标准化。

3. 当清分标准化数据后,会推送结果数据到清算域,清算按模型配置的清算规则,通过流程控制进入计费、分摊、累额等不同的组合处理(譬如:只计费、先计费后分摊、只分摊、先分摊后计费等),以及会补全结算户、合同及汇率数据,数据落到清算明细表。

4. 结算模型达到结算周期条件时,会产生一个结算任务。结算任务处理时,会从清算表中按条件获取待结算明细,然后按结算维度汇总,各自产生结算单信息。结算单自动按预定审批流程完成确认,最终推送到财务渠道(渠道当前有:科技财务、预存款账户、pop核算等),由财务渠道系统完成收付款。

2.4 典型问题技术设计

2.4.1 分片任务处理组件

平台采用cds实现分库分表存储数据,通过DTS把数据同步到ES,并进行报表明细显示。在整个结算流程中,存在众多需要聚合表数据处理操作(譬如:单据预处理、清算预处理、生成结算单,条件拉取条件数据等),因为本平台是与资金结算相关,金额必须绝对准确,所以未采用ES作为可信的聚合处理源。在前期公司调研相关产品后,未找到基于分库分表有高效的聚合工具,所以特研发以下“分片任务处理组件”:

图4 分片任务处理组件

此组件提供抽象的类shardingTask,预定好3个核心动作:split(如何分片)、do(分片数据如何处理)、merge(最终数据如何聚合)。

核心处理过程为:先统一抽象批量处理逻辑,把批量数据分片发送 MQ 并落库。多节点多线程进行消费,消费完成后,对数据库 MQ 记录的状态进行修改。每个分片处理完后,匀检查该任务下的消息是否全部处理完成,如果完成后,最后执行合并逻辑,那么此时我们想要的最终结果就出来了。

2.4.2 顺序清算

背景

某些业务系统要求以业务发生的流水,按顺序做计算、分摊及累额,为了解决这个场景,特设计以下通用的处理流程。

实现过程

第一步:数据接入在中间表中,按业务时间排序,然后打上唯一流水号(流水号自增特点):

图5 打标流水号

第二步:业务人员或系统自动处理单据,进行清算时,会触发条件 ,进入以下预清算处理流程:

图6 预清算处理流程

原理:

不需要按顺序处理的单据数据,直接发送了待清算MQ主题 中,需要按顺序清算单据,进入主流程。

挑战:

1. 分片存储情况下业务数据明细百万级排序;

2. 顺序处理如何保证处理效率;

3. 顺序清算异常情况,如何断点继续处理。

实现核心点:

原始快照表打标顺序流水号,利用分片任务组件,拉取数据后放在zset中进行排序,全部放入后,触发顺序清算流程。为应对大促销日,可以在业务能容忍的范围中,开放并发清算(并发数据之间不保证顺序),要成功整体成功,要失败整体失败。

2.4.3累额重置

背景

按顺序计费、分摊及累额场景,当业务人员需要回退到历史某个时间的单据重新顺序清算时,就需要从累额明细中重置到将要执行单据的位点(也就是累加的总额回退回去,并在流水中标识出哪些是无效数据)。

实现原理

图7 累额重置实现原理

三、系统功能介绍

3.1 结算流程

图8 结算流程

整个流程主要分为 4 个步骤:

1. 出具结算方案:每当有新业务场景接入,需由产品同学调研业务运营同学以了解业务场景,并出具专业的线上化结算解决方案,辅助业务系统备齐结算所需数据来源,并辅助业务数据同学加工结算数据表。

2. 结算模型配置:依据结算解决方案,在金道结算系统完成结算模型的基本信息配置以及单据处理、清算处理、结算处理、下游处理等环节的规则配置。

3. 结算任务处理:业务交易发生推送到结算平台,然后经过清分流程处理、清算流程处理、结算单生成,如果有对账确认流程配置,则会推送账单由客户进行账单确认,发票暂由运营人员线下开具(后续会支持)。

4. 结算完成:等确认完账单后,账单会推送到财务进行收付款处理,财务的处理结算会通知到结算平台。最终账单信息可以由结算平台提供归档及检索。

3.2 主要配置

3.2.1结算模型

1. 基本信息

图9 基本信息

2. 规则信息

图10 规则信息

结算模型是本平台核心配置,内容涵盖基本信息、结算周期、单据处理、清算处理、结算处理及下游配置,运营人员可以通过引导一站式配置好整个所需功能。

3.2.2 计费模型

1. 计费规则

图11 计费规则

对外提供计费服务,支持不同产品的计费模型和计费规则,形成计费规则引擎,实现计费规则和模型的可配置化,可支持灵活多变的计费场景。

2.分摊规则

图12 分摊规则

本平台支持基于预算的分摊配置能力,适合成本分摊型结算。目前我们支持分摊方式有按比例、按顺序及按固定金额,支持两级分摊,具备了大部分业务应用场景支撑能力。

四、业务支持案例

目前金道结算平台已赋能了 微电佣金、白条息费成本、内容平台创作者佣金、支付营销券计收等 业务的线上化结算场景,日均处理订单量达5000万+,日均有效结算金额达1300万+,有力支撑了业务快速发展。

4.1 微电业务

合作案例:为微电业务解决职场、坐席销售金融产品而产生的资金结算问题,包括佣金、业绩考核、企微加粉费和电话使用费等。

业务场景:微电业务售卖的金条、白条、基金、养老保障、小金保、股票、延保、CPA等。

图13 微电业务

4.2 白条业务

合作案例:为白条与商城解决商城、科技、供应商、POP商家联合营销而产生的白条营销费用收取问题。

业务场景:收取商城、供应商、POP商家的白条营销费用。

图14 白条业务

4.3 支付业务

合作案例:为支付解决外部机构采购优惠券,而产生的支付营销费用收取问题.

业务场景:收取外部机构的支付营销费。

图15 支付业务

五、总结

针对目前业务场景、商业模式进行调研分析,主要有四种结算模式:分佣结算业绩考核结算技术服务结算商品营销结算

4种模式覆盖目前所有场景,随着接入业务场景的扩展,模式可再增加。

作者:京东科技 张学君

来源:京东云开发者社区 转载请注明来源

展开阅读全文
  • 0
    感动
  • 0
    路过
  • 0
    高兴
  • 0
    难过
  • 0
    搞笑
  • 0
    无聊
  • 0
    愤怒
  • 0
    同情
热度排行
友情链接