在平臺向商家結(jié)算的業(yè)務中，有三個重要的產(chǎn)出物，本文主要說明的就是他們合并的原因、合并方法，以及合并關(guān)系的邏輯實現(xiàn)，希望對你有所啟發(fā)。

在平臺向商家結(jié)算的業(yè)務中，最終會有三個非常重要的產(chǎn)出物——賬單、付款、發(fā)票。

商家需要知道一個結(jié)算周期內(nèi)，自己的賬單、付款、發(fā)票，三者有著緊密的聯(lián)系，商家對賬也是要核對清楚“賬、款、票”的一致性。

一、賬單、付款、發(fā)票

賬單就是提供給商家的本結(jié)算周期的交易記錄，買了多少貨、收了多少錢、退了多少款，以及平臺抽了多少傭金，代扣代繳了多少稅，本期應結(jié)多少錢等等。

付款就是根據(jù)賬單結(jié)算的最終資金，把錢打到商家簽約的結(jié)算銀行賬戶中，商家就會拿著自己的賬單來核對自己的收款，賬單里告知商家要結(jié)算20萬，那就應該收到20萬的付款。

然后就是發(fā)票，這里的發(fā)票可以是廣義的票據(jù)，比如消費的小票、增值稅發(fā)票等，所以不同的款項可能要開不同的發(fā)票，不同的對象可能要開的發(fā)票也不同，而不同的國家需要的發(fā)票種類也不同，這要看這個國家此類活動需要什么稅種。

稅種也不是一成不變的，如下圖就是在某國根據(jù)其法律要求進行的按期稅改，從圖中可以看出開票跟賬是分不開的，同時開票跟付款也分不開。

開票就需要接外部的開票渠道，這個在不同國家也有不同的服務商，按其標準去接入即可，如智利、墨西哥等可以接入gosoket、vender等發(fā)票服務商。

其中有一個特別的稅，就是增值稅，平臺收了商家的傭金，傭金是平臺的收入，所以這部分是需要平臺繳納增值稅vat，但是這部分平臺可以轉(zhuǎn)嫁給商家，這時候就需要幫助商家代扣代繳，并且?guī)椭溟_vat增值稅發(fā)票。

二、有拆有合，需求多樣化

上面介紹的是一條結(jié)算產(chǎn)出物的主線“賬單、付款、發(fā)票。

那么拆開看，賬單、付款、發(fā)票還有更精細的屬性，比如一個獨立的小店鋪和一個全國數(shù)千家連鎖的麥當勞對“賬單、付款、發(fā)票”的模式訴求大為不同。

也就是普通商家和連鎖商家有不同的需求，所以我們將商家分成三個等級“KA、CKA、普通商家”。

KA就是大型連鎖商家，無論是連鎖酒店、連鎖超市、還是連鎖餐飲，普通商家就是一個獨立的小商家，就一個門店；而cka就是介于二者之間，例如有十幾個門店，但并非大型連鎖。

還有品牌一說，一個KA下可能有多個品牌，一個品牌也可可能有多個連鎖業(yè)務等等，有很復雜的關(guān)系。

同樣，還有法人主體一說，有的多門店共用一個法人主體，有的每個門店是一個單獨的法人主體，那么這樣的話，就有了更復雜的組織關(guān)系，也會造成結(jié)算關(guān)系的復雜，對平臺來說，賬單生成、付款處理、發(fā)票開具的模式就復雜了。

比如，對于大型連鎖來說，就存在總部和門店的關(guān)系，比如有的KA要合并付款到總部，總部統(tǒng)一收款，那么賬單、發(fā)票要進行合并，但是每個門店又要統(tǒng)計自己的經(jīng)營，所以每個門店又要單獨的賬單信息；而有的KA可能需要單獨付款給每個實際經(jīng)營的門店，但是要給總部合并賬單。

三、簡歷關(guān)系，靈活合并

上述的賬單生成，結(jié)算付款，發(fā)票開具都有獨立完整的主模塊。

而如何生成賬單、如何進行付款、如何開具發(fā)票，就需要考慮是不是需要合并，合并那一塊業(yè)務。

此時就需要一套規(guī)則的配置，來促成這一“是合是分”的實現(xiàn)。

其實在合并上有很多合并邏輯，主要是要抽象出“合并維度”，我能實現(xiàn)以誰為合并維度，或者按照法律法規(guī)我必須以誰為維度，或者按照法律法規(guī)我不能突破什么維度而合并，例如我能不能突破法人主體而合并付款給總集團？這些都需要財稅法團隊的支持以滿足當?shù)氐姆煞ㄒ?guī)和商戶的訴求。

假如，我們合并的上限是法人主體，只能針對同一法人主體下的門店合并其付款和發(fā)票，也就是多個門店的營收可以一筆付款，和開一張票；但是賬單我可以任意合并出具；當然其他按照品牌合并或者更多維度也可以實現(xiàn)，方式類似。

這樣的假設之下就需要構(gòu)建一個門店合并關(guān)系。

我們通過配置化實現(xiàn)這層合并關(guān)系，在賬單生成、付款單生成、發(fā)票數(shù)據(jù)處理時，調(diào)用這個關(guān)系，去判斷該門店是否在一個合并關(guān)系中，該業(yè)務是否需要與其他門店進行合并。

這里的合并關(guān)系，是建立一個主體下的多個門店之間在“賬單、付款、發(fā)票”三個業(yè)務之間“是否合并”的關(guān)系，如下圖中的合并關(guān)系，僅僅是合并了3家門店的付款，而發(fā)票和賬單并沒有合并關(guān)系所以還是按單門店執(zhí)行。

那么為什么會存在一個法人主體下僅部分門店合并了付款呢？這里的合并訴求要看商家具體經(jīng)營情況，可能是這3家門店是同一個運營團隊在運作，而該企業(yè)是以運營團隊為單位進行核算的。

如下圖的配置關(guān)系規(guī)則，明確了哪些門店進行了合并，在什么場景上合并了，這里的場景主要是3個，就是“賬單場景、付款場景、開票場景”。

在新增合并關(guān)系時，必須選擇一個法人主體，該法人主體下的門店可以自由組合。

這時，一個法人主體下就可以配置多條合并規(guī)則，一條合并規(guī)則可以約定了這些門店是合并了什么場景。

賬單、付款、發(fā)票都是獨立的業(yè)務，他們未來都會有獨立的文章單獨介紹，各自的詳細業(yè)務介紹本文就不過多說明了。

本文主要說明的就是他們合并的原因，合并方法，以及合并關(guān)系的邏輯實現(xiàn)。