结算和计费

一个订单的创建，创建好之后用户所支付的钱都是中间账户。

如果退款，那么从中间账户转移到用户的账户

如果发生核销，那么就需要把钱从中间账户转给商家。

结算就是根据订单中的信息，先打款在抽佣 还是 直接打款 走分账。

结算可以记录每一个商家的结算方式，如果一个商家有多个结算方式，可以按照时间和业务进行匹配决策出使用哪个结算方式进行结算。

计费就是算钱：一个商家有一个计费合同，但是可以有多个计费规则。

只要计费规则不一样，在计费的时候，就可以匹配出规则进行计费。

因此我认为 结算和计费 的结构大同小异，支持职责不同。

打款方式：及时打款 还是 担保打款 不同的方式可以在不同的节点走结算就可以。

一个商户可以有多个计费的场景code，也就是合同

合同的开始使劲，合同的结束时间，合同类型，合同状态，合同的创建者

具体的费率 是实例表。也可以叫规则表。

费率实例id，code，规则表达试，费率开始时间，费率的结束时间。

举个例子：一个商品可以按照商品纬度收费，也可以按照商户维度收费。

假设按照商品维度结算 或者 抽佣。

那就先创建一个合同，合同id

然后在针对每一个商品生成一个唯一的一个实例id，费率的开始时间，费率的结束时间，唯一的因子。

比如创建一个费率的时候，如果当前时间 《 费率的开始时间，那么则使用费率的开始时间。

如果当前时间》费率的开始时间，那么是用当前时间作为费率的开始时间。

如果要失效费率。只需要更新费率的结束时间就可以，如果当前时间》 费率的结束时间，那么就不用更新，直接使用费率的结束时间就可以。

如果当前时间《费率的结束时间，那么则 使用当前时间做费率的结束时间。

在真正结算的时候，根据下单的时间以及其他的订单信息，则去匹配出对应的计费规则，进行业务处理。

针对结算：业务上可以决策  即使打款/担保打款，结算类型，结算根据标识做相应的打款处理。但是整个订单的状态生命周期是不变的。