编辑导语：做一款结算产品，要考虑到支付时的各种场景，因此计费模块的设计尤为重要。本文作者根据自身的工作经历，对如何设计计费模块展开分析，希望对你有帮助。

做结算产品三两年了，基本结算相关的应收应付场景都见过，主要是围绕计费这块写点东西，分享一下，可探讨，可喷，大厂同学请绕路，因为这东西可能你们的团队已经实现了。

公司现在业务相当于平台，业务抽象来说比较简单，有点像电商的POP模式，用仨字儿概括就是算分成，背景如下：

1. 几个商户（角色）入驻你这个平台
2. C端支付个订单
3. 平台把该收谁多少钱，该给谁多少钱算好
4. 信息提交至银行做清分

各位看官淡定，以上几个步骤我们都是合法合规的，跟银行合作的，这块可不要开喷。

以上就是业务背景，可能围绕计费这块，做过电商的或者平台类的朋友会遇到运营或者各部门提的需求，举个例子：

我每年需要收年费，可能A供应商每年收1000，B供应商每年收2000，等等。每个订单我平台要抽成，每个商家，甚至于每个商品类目，收取的都不一样，费用，费率都不一样，收取的方式天花乱坠。某些商户我可能不间断的还会给他阶梯优惠，等等。

每衍生出一个费用需求，接下来就是技术一顿改，一顿出问题，一顿修复。

所以，需要一个可配置的模板，每新增一个费用需求，不需要改代码，可以通过配置，来解决以上的问题。

一、基本要素

个人理解，决定费用项目的几个基本的要素就以下几个：

1. 计费业务线：每个公司都不一样
2. 计费对象（角色）：就是入驻你这个平台的商户是干嘛的，给它规个类
3. 费用类型：比如，年费，每单的抽成，佣金，等等

以上仨要素，或者更多要素，基本能决定入驻平台的这个商户的类型以级费用类型。

二、费用规则

1. 计费的基准值

常见的两种：

1. 按照（订单/商品）售价收
2. 按照差价收，相当于(卖出价-进货价),目前我们平台暂时就做了这两种

这里暂时留个的个问题：万一特殊的业务，出个其它规则呢，所以这里要要解决的问题是在不变更代码的情况下，让业务人员可配置基准值。

2. 计费规则

基本上以基准值*比例或者固定值提现，比如每单固定抽成20块，或者每单抽取销售额的百分之5。

3. 计费区间

时间段内： startTime< D < EndTIme.

时间段外： D>startTime 或者 D>EndTIme.

等于什么时间：D=XXTIme或者D=XXTIme，等等

4. 小结

其实基本的归根究地就是，5W原则，什么时候收誰，收多少，怎么收。这个足以构成模板的横向元素。

首先，实现计费模板实现的前提，就是在结算系统，有一个类似于“订单快照”的模块，简单来说就是包含所有结算用的，订单商品维度的一个大表，包含订单号，售价，实付，结算价，确认收货时间等等。快照作为后续结算甚至财务统计的BASE。

三、具体的配置以级相关联的功能点

计费业务线：

比如，金融业务，物流业务等。

计费对象（角色）：

可以决定商户属性的角色，比如自营，POP商户，视实际业务场景而定。

计费类型：

年费，手续费，技术服务费，等等的费用。

不过多描述了，几个字典表相关联可以搞定。

计费的基准值：

比如售价，结算价，售卖，等等的基准值，均来自于订单快照，且可计算。

基准值的作用有以下两点：

1. 就作为基准值：比如某类业务需要收取 销售额的百分之5，实际支付金额的6%，等等
2. 作为阶梯价的标准，比如售价达到多少时，改变什么金额，结算金额达到XXX时，结算价发生变化，售卖天数达到XX天时，做什么，等等

这里我想表达的需求是，订单快照相关的所有结算数据，都可以配置为基准值，我可以把销售额作为基准值，可以把数量作为基准值，可以把售卖天数作为基准值等等，而且基准值可以算加减乘除。

举个例子：

我某类商品需要按（卖出价-买入价）的3%收取平台服务费，那么配置个基准值：取名叫——利润=卖出价-买入价（不要纠结这个名字）

这里衍生出一个功能点：在不需要改代码的情况下，让基准值进行可配。

所以技术上要实现两点：

1. 公式的解析，举例：利润=卖出价-买入价，卖出价是结算数据的哪列，买入价是哪列
2. 业务人员不懂数据库，不可能让他们直接把列名输出成公式，所以需要一个然他们能看的懂的输入界面来编辑公式。

以上两点就由产品及技术自己发挥了。

基准值一般应该是不复杂的元素，售价，结算价，数量等等的要素或者要素经过简单计算得出的结果，可以作为基准值，比如（卖出价-卖入价），如果基准值包含了数字的比例计算，那就需要注意，是不是错误的把某项费用当做基准值来配置了

接下来是费用比例以及封顶值：

费用比例比较特殊，规则简单的，可以配置到角色维度就可以了，比如平台统一收取角色为服务商的商户每笔订单 10%佣金，这类的配置到角色层级即可。

规则复杂的，以电商平台为例，比如某某商品佣金按6%收取，某某商品佣金按3%收取那这个就是商品的维度，也就是在基础佣金规则存在的前提下，按照供应商商品维度，再次进行编辑，至于要编辑多少次，是不是每条商品都需要编辑规则，那就看产品设计咯。

封顶值有三种：固定金额封顶，非固定金额封顶，无封顶。

1. 固定金额封顶：举例：年费每年收1w
2. 非固定金额封顶：前三个月销售额达到XX的百分之10，免收佣金(例子不太恰当，理解就行了）
3. 无封顶：永久收取的费用

计费区间：

就很简单了，不过多说了，至于把或且非的关系如何配置，那就自由发挥了。

综上，阶梯价场景以外的规则，通过以上这些元素横向组成，任何基本的计费场景以及规则都可以横向配置出来，而且是可以配置到商品维度，节省了绝大多数因为计费规则变化而增加的开发工作量。

最后就是阶梯价：

阶梯在大大小小的公司都是令人头疼的事，一般的我见过的比较“笨”的做法是在结算时点，生成结算单数据后，统一刷一遍，然后再重新计算。

上文提到的计费区间+封顶值构成了阶梯价的数据。

这里就用到了之前提到的基准值，基准值一旦配置，就会在结算系统进行累加，按单，或天维度，所以在商户入驻平台同时，根据业务场景可能衍生的阶梯价规则就需要在基准值进行配置。

举个最简单的阶梯价场景：

A供应商，x商品，结算价为50，售卖之日起三个月内，如果销售额达到50w，后续结算价变为40。

这里以时间，销售额为阶梯，按照模板配置两条：

1. 费用类型：平台应付XX费
2. 基准值：销售额

计费区间，2020-01-01<=D<=2020-03-31，封顶值：50w。

到达封顶值后，清结算系统识别阶梯价改变任务改变结算价去继续执行后续计费即可。

然后在配置一条计费区间>=2020-03-31，无封顶值的就可以了。

以上的场景偏向于按单计提，意思就是以订单商品维度来收取（支付）费用。

最后就是一次性收取的费用，这种最简单，比如年费，服务费，等等，配置好以后，这种本身跟订单弱关联的的，清结算系统生成任务事件推给供应商前置生成B2B订单去缴纳就是了。

举个小栗子：年费，按年收取的，业务人员一年在费用模板做一条，当然了这是比较笨的方式，最好的就是依赖配置自动生成。

小结：

以上描述的“计费”比较狭隘，目前公司所应用的场景是清分，也可以把它称之为“分成”模块，就清结算系统边界内讲，这个模块的前置是支付模块，BASE数据也就是上文提到过的“订单快照”均依赖于支付模块生成。

如果计费平台化，那么…..

计费是一个可逆的场景，不是任何的业务线，场景都存在一个“永不变更”的场景，例如阶梯价的计算，什么时间什么时点，计入销售额，如果计入后发生了退款，什么时点扣除，等等细节还有很多。

更细的不说了，欢迎大家指正与探讨。

本文由@卡欧里 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Pexels，基于CC0协议