网站建设全程揭秘,西安网站建设招标,网站建设的设计方案,网页网站建设的ppt导读
京东科技业务在快速发展的同时#xff0c;产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点#xff0c;且无法满足“风法财审”对于资金流程的管控要求#xff0c;在此背景下金道结算平台…导读
京东科技业务在快速发展的同时产生了众多线上化资金结算的需求。传统的线下资金结算模式有着人力成本高、耗时长、多方沟通协调成本高、结算准确率低等固有缺点且无法满足“风法财审”对于资金流程的管控要求在此背景下金道结算平台孕育而生。本文从系统建设的背景、设计细节、已支撑案例及适用业务场景多个层面进行详细阐述。读者可以关注文中所讲的系统实践过程进而对结算领域系统设计能力提升具有一定的参考价值。
一、概述
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种模式覆盖目前所有场景随着接入业务场景的扩展模式可再增加。 作者京东科技 张学君 来源京东云开发者社区 转载请注明来源
