上一节我们讲了账户结构和余额结构，有了账户那么账户里就需要存入和存出，充值和提现，转账和消费；这样账户才会流动起来，才有了生命力；那么在交易场景里费用就显得十分重要了，多少钱，什么费……我们以滴滴司机的结算账户为例来讨论本节内容。
1、交易场景
任何一笔收支都依赖于一个场景，而且这个场景基本涵盖所有后续清结算的信息。
比如用户叫了一辆快车，张师傅接了单子，从立水桥南到奥森公园；这就是一个交易场景，我们可以称为”快车打车场景“，在这个场景下我们可以知道用户是谁，在哪打的车，什么车型，起步价多少，每公里多少，司机是谁等。
如果车到了，超过了4分钟用户不用车取消了，那么这时候就需要支付一个取消费用，这又是一个场景，我们可以称为“超时取消场景”。
我们将平台的所有交易场景进行枚举，如果要新增场景，那么要预先在场景中心申请场景编号，才能开展上线业务。
2、费用
在上面的场景中，就会产生交易，因此产生一些列的费用。
比如打车单订单费用，完单后要给司机做结算就有了订单结算费用，平台要抽取一定服务费就有了“平台服务费用”，如果高峰期给司机发一定补贴的话就有了“高峰补贴费”等等；
费用就是站在业务角度定义资金的业务属性，基于业务侧的费用我们可以关联到后续的财务科目，这样的话费用是从业务发生那一刻就产生并且定义了，而且最后关联到会计科目，这样业务和财务实现信息一体，对于业务记账以及转财务账提供巨大的遍历
3、计算
这需要一个强大的计算系统，我们在支付系列清结算模块会做重点介绍；这里点到为止。
下单前的预计算，为用户选择起点和重点后预先计算可能需要的订单费用。
进行中的实时计算，这个大家都打过车就不再说了。
结束后的计算，计算出本单实际产生的费用。
我们可以看出订单总费用包含三部分：起步价+里程费+时长费；你可能会问，一个订单为什么要拆成这么多费用呢？我们简单想一下，这三个费用的特点，而且这三个费用在不同的城市，不同的时段，不同的用户，不同的车型都会发生变化，所以我们可以理解为，费用的细化是精细化运营的必然结果，另外用户也需要知道为什么收这么多钱。
订单的清结算，订单完结后就需要给司机做结算，那么还需要进行一次计算，那就是这一单应该给司机多少钱，平台抽多少钱，要不要实时扣税，有没有其他费用，比如保险费，我们得出如下的清算结果。
4、账户结构和余额结构
简单点，每个司机只有一个结算账户，在某支付平台开通的二类支付账户，没有其他类型的账户，接单的收入，补贴奖金全部结算到该账户，司机可以进行提现。
因为为了风控客诉问题，我们为司机设置一个7天的订单结算冻结期，这样的话我们的账户余额分成了冻结余额和可用余额，可用余额可以用于提现。
5、费用管理设计
上面我们讲了交易场景和费用的定义，现在我们就来设计费用费用管理，设计费用有三个关键点。
费用编码 费用名称 费用结构。
这里的设计办法有2种。
一级枚举型，就是费用之间没有关系，对所有费用进行枚举，有规律设置编码。
多级结构，就是像会计科目一样，有总科目，明细科目，明细科目可以设置多级。
以上两种方式可能第二种更好一些，特别是在核算和统计时，可以进行总分分别进行统计分析和核算。
6、入账规则管理
我们设置好了费用，那么在每个节点都会产生费用，或者计算出相关的费用，比如司机收入，那么清分之后就需要计入相关的账户，比如司机收入要计入司机的结算账户；那么还可能一个费用要计入多个账户，比如复试记账时，又比如司机奖金可能要同时计入平台的运营账户和司机的结算账户。
入账规则设计有两个关键点。
一个是匹配条件：要基于入账请求传参的条件来匹配到相关的入账规则条目，比如我们需要定义每类记账请求需要什么条件，比如司机收入入账，一个条件就够了。
费用类型 司机收入
另一个是入账规则：就是这个条目指定入什么账户，比如司机收入匹配到的规则应该是要入司机结算账户，则入账规则是。
账户主体：司机
主体ID：司机ID
账户类型：结算账户
这样我们就得到了一条入账配置规则。
基于上面的规则，上游系统在申请入账时必须传几个参数：费用类型，主体类型，主体id;基于司机收入这个费用，我们就匹配出一条规则，应该入司机的结算账户，利用司机ID找到相关的结算账户ID然后计入账户。
我们下一篇介绍冻结规则和账户流水和余额更新。
