账单、付款与发票
在平台向商家结算的业务中，最终会有三个非常重要的产出物——账单、付款、发票
商家需要知道一个结算周期内，自己的账单、付款、发票，三者有着紧密的联系，商家对账也是要核对清楚“账、款、票”的一致性
账单就是提供给商家的本结算周期的交易记录，买了多少货、收了多少钱、退了多少款，以及平台抽了多少佣金，代扣代缴了多少税，本期应结多少钱等等
付款就是根据账单结算的最终资金，把钱打到商家签约的结算银行账户中，商家就会拿着自己的账单来核对自己的收款，账单里告知商家要结算20万，那就应该收到20万的付款
然后就是发票，这里的发票可以是广义的票据，比如消费的小票、增值税发票等，所以不同的款项可能要开不同的发票，不同的对象可能要开的发票也不同，而不同的国家需要的发票种类也不同，这要看这个国家此类活动需要什么税种
税种也不是一成不变的，如下图就是在某国根据其法律要求进行的按期税改，从图中可以看出开票跟账是分不开的，同时开票跟付款也分不开
开票就需要接外部的开票渠道，这个在不同国家也有不同的服务商，按其标准去接入即可，如智利、墨西哥等可以接入gosoket、vender等发票服务商
其中有一个特别的税，就是增值税，平台收了商家的佣金，佣金是平台的收入，所以这部分是需要平台缴纳增值税vat，但是这部分平台可以转嫁给商家，这时候就需要帮助商家代扣代缴，并且帮助其开vat增值税发票
上面介绍的是一条结算产出物的主线“账单、付款、发票”
那么拆开看，账单、付款、发票还有更精细的属性，比如一个独立的小店铺和一个全国数千家连锁的麦当劳对“账单、付款、发票”的模式诉求大为不同
也就是普通商家和连锁商家有不同的需求，所以我们将商家分成三个等级“KA、CKA、普通商家”
KA就是大型连锁商家，无论是连锁酒店、连锁超市、还是连锁餐饮，普通商家就是一个独立的小商家，就一个门店；而cka就是介于二者之间，例如有十几个门店，但并非大型连锁
还有品牌一说，一个KA下可能有多个品牌，一个品牌也可可能有多个连锁业务等等，有很复杂的关系
同样，还有法人主体一说，有的多门店共用一个法人主体，有的每个门店是一个单独的法人主体，那么这样的话，就有了更复杂的组织关系，也会造成结算关系的复杂，对平台来说，账单生成、付款处理、发票开具的模式就复杂了
比如，对于大型连锁来说，就存在总部和门店的关系，比如有的KA要合并付款到总部，总部统一收款，那么账单、发票要进行合并，但是每个门店又要统计自己的经营，所以每个门店又要单独的账单信息；而有的KA可能需要单独付款给每个实际经营的门店，但是要给总部合并账单
上述的账单生成，结算付款，发票开具都有独立完整的主模块
而如何生成账单、如何进行付款、如何开具发票，就需要考虑是不是需要合并，合并那一块业务
此时就需要一套规则的配置，来促成这一“是合是分”的实现
其实在合并上有很多合并逻辑，主要是要抽象出“合并维度”，我能实现以谁为合并维度，或者按照法律法规我必须以谁为维度，或者按照法律法规我不能突破什么维度而合并，例如我能不能突破法人主体而合并付款给总集团？这些都需要财税法团队的支持以满足当地的法律法规和商户的诉求
假如，我们合并的上限是法人主体，只能针对同一法人主体下的门店合并其付款和发票，也就是多个门店的营收可以一笔付款，和开一张票；但是账单我可以任意合并出具；当然其他按照品牌合并或者更多维度也可以实现，方式类似
这样的假设之下就需要构建一个门店合并关系
我们通过配置化实现这层合并关系，在账单生成、付款单生成、发票数据处理时，调用这个关系，去判断该门店是否在一个合并关系中，该业务是否需要与其他门店进行合并
这里的合并关系，是建立一个主体下的多个门店之间在“账单、付款、发票”三个业务之间“是否合并”的关系，如下图中的合并关系，仅仅是合并了3家门店的付款，而发票和账单并没有合并关系所以还是按单门店执行
那么为什么会存在一个法人主体下仅部分门店合并了付款呢？这里的合并诉求要看商家具体经营情况，可能是这3家门店是同一个运营团队在运作，而该企业是以运营团队为单位进行核算的
如下图的配置关系规则，明确了哪些门店进行了合并，在什么场景上合并了，这里的场景主要是3个，就是“账单场景、付款场景、开票场景”
在新增合并关系时，必须选择一个法人主体，该法人主体下的门店可以自由组合
这时，一个法人主体下就可以配置多条合并规则，一条合并规则可以约定了这些门店是合并了什么场景
账单、付款、发票都是独立的业务，他们未来都会有独立的文章单独介绍，各自的详细业务介绍本文就不过多说明了
本文主要说明的就是他们合并的原因，合并方法，以及合并关系的逻辑实现