在平台与商户的结算业务中，有三个重要的产出。 本文主要阐述他们合并的原因、合并方式、合并关系的逻辑实现。 我希望它能给你带来启发。
平台与商户的结算业务中，最终会产生三个非常重要的输出——账单、付款、发票。
商户需要知道，在一个结算周期内，他们的账单、付款和发票是密切相关的。 商户在对账时还必须检查“账款、发票”的一致性。
1. 账单、付款、发票
账单是本次结算周期提供给商户的交易记录，包括购买了多少商品、收取了多少、退款了多少、平台抽取了多少佣金、代扣代缴了多少税、应收多少等。当期支付，等等。
支付是将账单结算的最终资金划入商户签署的结算银行账户。 商家会用自己的账单来查询其收款情况。 账单告诉商家需要结算20万，那么就应该收到20万的付款。
然后是发票。 这里的发票可以是广义的票据，比如消费收据、增值税发票等，因此不同的付款可能开具不同的发票，不同的对象、不同的国家也可能开具不同的发票类型所需的费用有所不同，具体取决于该国此类活动所需的税收。
税收类型不是静态的。 下图为某国根据其法律要求进行的阶段性税制改革。 从图中可以看出，开票和会计是密不可分的，同时，开票和付款也是密不可分的。
要开具发票，您需要连接到外部开票渠道。 不同国家有不同的服务提供商。 您可以按照他们的标准进行连接。 例如智利、墨西哥等可以连接等待开票服务商。
其中有一种特殊税种，就是增值税。 平台向商家收取佣金。 佣金是平台的收入，所以这部分需要平台缴纳增值税，但这部分平台可以转嫁给商户。 这时就需要帮助商户代扣代缴增值税，并帮助他们开具增值税增值税发票。
2、有拆分、有组合，需求多样化。
上面介绍的是结算输出的主线“票据、付款、发票”。
如果细分一下，你会发现账单、付款、发票都有更详细的属性。 例如，一家独立的小店对于“账单、付款、发票”模式的要求与遍布全国数千家门店的麦当劳连锁店有很大不同。
也就是说，普通商户和连锁商户的需求是不同的，所以我们将商户分为“KA、CKA、普通商户”三个级别。
KA是大型连锁商家，无论是连锁酒店、连锁超市、还是连锁餐饮。 普通商户是独立的小商户，只有一个店铺； 而cka则介于两者之间，比如有十几家店，但不是大型连锁店。
对于品牌来说，一个KA下可能有多个品牌，一个品牌可能有多个连锁业务等等，关系非常复杂。
同样，还有法人实体。 有些商店共享一个法人实体，有些商店则是单独的法人实体。 在这种情况下，就会出现更加复杂的组织关系，这也会使结算关系变得复杂。 对于平台来说，账单生成、支付处理、发票开具的模式比较复杂。
例如，对于大型连锁店来说，总部和门店之间存在关系。 例如，有些KA需要将款项集中到总部，由总部统一收款。 然后账单和发票需要合并，但是每个商店都要计算自己的运营。 因此，每个商店都需要单独的账单信息； 而有些KA可能需要分别向每个实际经营的门店付款，但将账单合并到总部。
3、恢复关系，灵活合并
上述账单生成、结算支付、发票开具都有独立完整的主要模块。
至于如何生成账单、如何付款、如何开具发票，需要考虑是否需要合并以及需要合并哪些业务。
这时就需要一套规则配置来方便实现这种“组合或划分”。
其实合并中有很多合并逻辑。 主要是抽象出“融合维度”。 我可以使用谁作为合并维度？ 或者说按照法律法规我必须以谁为维度？ 或者说按照法规，我无法突破哪个维度去融合。 比如，我可以突破法人实体，将款项合并到主集团吗？ 这些都需要财税法律团队的支持，以满足当地的法律法规和商家的诉求。
如果我们合并的上限是法人实体，我们只能合并同一法人实体下的商店的付款和发票。 即多个门店的收入可以一次性支付，开具一张发票； 但我可以随意合并账单。 发布; 当然，其他基于品牌或者更多维度的组合也可以类似的方式实现。
在此假设下，需要构建门店合并关系。
我们通过配置来实现这种级别的合并关系。 在生成账单、付款单、发票数据处理时，我们调用这个关系来判断该店铺是否处于合并关系，以及该业务是否需要与其他店铺进行合并。
这里的合并关系是指一个实体下的多个门店之间的“计费、支付、发票”三项业务之间建立“是否合并”的关系。 下图的合并关系只合并了3家店铺。 付款，但发票和帐单没有合并，因此仍然按商店执行。
那么，为什么只有一些同一法人实体下的商店才会合并付款呢？ 这里的合并请求取决于商家的具体经营情况。 可能这三个店是同一个运营团队运营的，公司是由运营团队占的。
如下图所示，配置关系规则明确了合并哪些商店以及在什么场景下合并。 这里主要有三个场景，即“计费场景、支付场景、开票场景”。
新增合并关系时，必须选择法人实体，该法人实体下的店铺可以自由组合。
此时，一个法人下可以配置多条合并规则，一条合并规则可以指定这些店铺合并的场景。
计费、付款和开票都是独立的业务。 以后会在单独的文章中分别介绍。 对于各个详细的业务介绍，本文不会过多解释。
本文主要阐述他们合并的原因、合并方式、合并关系的逻辑实现。
专栏作家
陈天宇，微信公众号：陈天宇，人人都是产品经理专栏作家。 多平台支付领域专栏作家，拥有十年产品经验； 专注于为10万支付产品经理、支付机构和企业提供深度支付内容和服务！