背景
近期负责关于集团的计费结算相关的系统，相对于2C系统的大流量，高并发的场景，计费和结算的信息对稳定性要求更高。对时效性要求并没有过于严苛的要求。那么接下来就和大家分享一下计费结算系统的架构设计。
模块划分
我们暂且将平台细分为规则平台、计费平台和结算平台，我们简单介绍一下各个系统的作用
规则平台
业务、运营人员可以设置一些前置规则，符合规则的数据，会通过大数据/实时接口调用，参与数据的计算
计费平台
满足规则的数据，进行数据的存储，这些数据，作为要结算的基础数据，并不一定要结算，可能只是某些中间状态的数据
结算平台
基于计费的数据，整合结算数据，此结算数据，一般有账期的概念，比如按照日/月/季/年进行汇总结算
全景图
系统内部业务流转图
我们能比较清晰的看到整个系统关联关系。
业务架构图
核心部分讲解
B端系统很难讲解的地方在于，大家的带入感是不够的，比如我们聊 订单、优惠券、促销，大家都很容易理解，并不是因为业务简单，而是因为，我们每天都在接触，比如购物，使用优惠券，叠加促销，我们本身就了解其大概流程。
B端的流程，一般来说，更复杂些，或者说，业务属性更强，比如我之前做ERP相关的系统，需要了解整个公司的全部业务流程，个性化也很多，如果从来没了解过的人，上来就会很懵。
本文会详细讲解下结算相关的模块，希望能够尽可能讲解清楚。
数据来源：
结算的数据全部来自于计费的数据，可以理解为，计费的数据范围要大于结算数据，我们按照天维度或者月维度，进行数据的汇总，维度为商家ID+账期。
也就是说，一个商家，在一个账期下只有一个结算单，明细体现在结算单的明细上。
计算单的明细，也要进行二次汇总，比如按照规则类型，不同的规则，进行汇总，能够使用户，能够更清晰的了解数据。
第三层为非聚合的明细，能够让商家自己查询具体的明细，可以进行数据验证和对账。
发放途径：豆+现金
当前，能够支持豆和现金的发放，豆的方法依赖于豆系统的能力，我们需要通过商家id，去拿到豆账户，去豆账户发放
现金，我们于支付系统交互，进行现金的支付或者扣除。
基础数据配置：
分成比例：商家和门店，可以设置分摊的比例，由商家自行设置。
钱包绑定: 一般情况下，需要商家进行钱包绑定，钱优先发放到商家的钱包里
异常场景：
比如，我们要给商家或者门店进行扣除佣金，那么如果商家钱包里没有余额，且没有豆可以扣除。
如果商家和门店还与我们合作，则可以进行金额的结转，结转到下个月，与下个月的佣金进行合并结算。
如果商家与门店不再与我们合作，则需要通过罚款/抵扣质保金的方式，进行结算单金额的追回，避免造成损失。
![[SWPUCTF 2021 新生赛]gif好像有点大](https://i-blog.csdnimg.cn/img_convert/5bfa873ba11c4fdd4393141b6c44d484.png)
