為了使本領域技術人員更好地理解本說明書實施例中的技術方案，下面將結合本說明書實施例中的附圖，對本說明書實施例中的技術方案進行詳細地描述，顯然，所描述的實施例僅僅是本說明書的一部分實施例，而不是全部的實施例。基於本說明書中的實施例，本領域普通技術人員所獲得的所有其他實施例，都應當屬於保護的範圍。
現有技術中，針對一些簡單且固定的結算關係，已經可以實現支付金額的自動結算，以網路預約車平台為例，乘客支付的乘車費用實際會被分為兩部分：一部分是司機的實際收入，另一部分是平台的抽成。假設1個平台有n個司機，且平台以及每名司機都各自對應一個帳戶，那麼就形成了一個“1對n”的兩級結算體系。在網路預約車平台中，兩級的結算體系結構是固定的，並且“平台”對“司機”的抽成額度也是固定的（例如平台抽取乘車費用的20%），那麼就可以針對“平台帳戶”和“司機帳戶”這兩種帳戶身份，設計一個具有固定結構和分配規則的體系，從而實現乘車費用的自動結算。
然而在實際應用中，不同的應用場景可能存在截然不同的結算需求，舉例說明如下：
不同的商戶，具有不同的結算層級架構。例如最簡單的結算體系是“總商戶-門店”的兩級1對n關係，更多層級的結算體系例如：有些商戶在“門店”下還會有“櫃員機”、有些商戶在“總商戶”和“門店”之間還有“區域”的概念，而“區域”又可能進一步存在多級，例如國家、省、市等等。
屬於同一身份類型的不同帳戶，在結算體系中處於不同位置。例如在“總商戶-門店-櫃員機”這樣的3級結算體系中，有些櫃員機是設置在門店中，則其上級結算對象是“門店”，有些櫃員機是獨立設置（不屬於任一家門店），則其上級結算對象是“總商戶”；
屬於同一級別（或同一身份類型）的不同帳戶，在結算體系中使用不同的結算規則，例如不同銷售人員的銷售金額提成比例不同，不同地區的返利點數不同，等等。
可見，現有技術中的自動結算，僅是針對某個特定應用場景，設置固定的結算體系，無法滿足多變的結算需求。
技術人員透過分析發現，在複雜的金額結算應用場景中，各個帳戶的結算關係具有以下特點：
下級帳戶向上級帳戶結算，並且可以存在多個層次的“上下級”關係。例如櫃員機向門店結算、門店向總商戶結算；
上級帳戶和下級帳戶是“一對多”的關係，即多個下級帳戶可以向同一個上級帳戶結算。例如一個門店下面有多個櫃員機；
結算金額按照由下至上的方向，逐級結算，最終彙集至一個總帳戶；
針對上述具體應用場景，本說明書實施例提供一種可靈活配置的金額結算系統，具體實現方案如下：
● 系統具有若干數量的節點，其中節點數量是可配置的，即系統管理用戶可以對系統的節點進行增加/刪除操作。每個節點對應一個電子帳戶，該帳戶可依託於客戶端實現金額轉入/轉出等基本功能，因此可視為系統中存在的一個功能模組。
● 每個節點具有若干屬性，這些屬性中的一種或多種也是可配置的。
● 節點間以樹形結構關聯，每組父子關係對應一組存在結算關係的帳戶：父節點對應結算金額轉入帳戶、子節點對應結算金額轉出帳戶；
樹形結構一般指代多個節點之間存在“一對多”關係的資料結構，在樹形結構中，根節點沒有父節點，其餘每個節點有且只有一個父節點；葉子節點沒有子節點，其餘每個節點可以有一個或多個子節點。對應於本說明書中的金額結算場景如下：除總帳戶（根節點）外，每個下級帳戶（子節點）均向其上級帳戶（父節點）結算，支援多級結算（多層樹形結構）、以及支援多個下級帳戶向同一個上級帳戶結算（一個父節點對應多個子節點），結算金額最終彙集至總帳戶（僅有一個根節點）。
每個節點具有若干屬性，從性質上可以分為“獨立屬性”和“關係屬性”兩類，下面分別進行介紹：
“關係屬性”用於表徵該節點與系統中其他節點的關係，為了滿足結算應用場景的需求，關係屬性至少應包括結算關係屬性。
對於系統中每個節點（除根節點之外），收到一筆轉入金額後，需要瞭解該向誰進行結算，因此在任一節點的結算關係屬性中，至少應包括該節點的父節點標識。
如圖1所示的三層結算體系，a為根節點，全域的結算關係包括：c1、c2向b1結算，c3向b2結算，b1和b2向a結算。
那麼，除根節點的外的各節點結算關係配置如下：
c1：（父節點：b1）
c2：（父節點：b1）
c3：（父節點：b2）
b1：（父節點：a）
b2：（父節點：a）
預設情況下， 各節點可以採用統一的規則向上一級節點進行結算，例如將轉入金額的100%結算至上一級節點、將轉入金額的80%結算至上一級節點，等等。為了滿足更靈活的結算需求，還可以在結算關係屬性中添加“結算規則”，表示節點的入帳金額與結算轉出金額的映射關係。
仍以圖1所示的三層結算體系為例，添加結算規則後的配置結果示意如下：
c1：（父節點：b1），（結算比例：1）
c2：（父節點：b1），（結算比例：1）
c3：（父節點：b2），（結算比例：1）
b1：（父節點：a），（結算比例：0.9）
b2：（父節點：a），（結算比例：0.8）
根據上述的結算規則配置，c1、c2、c3均為全額向上級節點結算，b1和b2向上級節點結算的比例分別為0.9和0.8。可見，不僅不同級別的節點之間可以支持不同的向上結算比例，相同級別的節點也可以支援不同的向上結算比例。
可以理解的是，結算比例只是結算規則的一種具體表現形式，根據實際需求，可以將結算規則配置為其他形式的“入帳金額→轉出金額”映射關係。例如，除了固定結算比例（相當於映射關係為線性函數）外，還可以利用分段函數、指數函數等形式，實現配置結算比例根據每次入帳金額動態變化、或者結算比例根據統計週期（例如1個月）的入帳總金額動態變化；當然，結算關係也不僅限於結算比例一種表現形式，本領域技術人員可以根據實際需求靈活進行配置。
此外，在任一節點中，還可以針對不同入帳來源配置不同的結算規則，舉例如下：
“不同來源”可以是不同的下級計算節點，例如針對圖1的b1節點：
b1：（父節點：a），（結算比例：[if來源c1:0.95]，[if來源c2:0.85]）
“不同來源”可以是不同的入帳類型，例如針對圖1的b2節點：
b2：（父節點：a），（結算比例：[if來源下級節點:0.85]，[if來源直接入帳:0.75]）
除“父節點標識”和“結算規則”之外，任一節點的關係屬性中還可以包括其他內容，例如：
子節點標識，可用於校驗，需與子節點中的父節點標識同步更新；
業務關係資訊，可用於記錄該節點對應帳戶的業務上級/下級，注意這裡的業務關係與結算關係可以是一致的，也可以相互獨立，即：業務關係中的上級/下級，並不一定是結算關係中的上級/下級。
相對於“關係屬性”而言，“獨立屬性”用於表徵任一節點的獨立特徵，這些屬性與其他節點不存在關聯。對於每個帳戶而言，“帳戶名”、“綁定用戶資訊”、“負責人”、“地址”、“電話”等等，均屬於獨立屬性的範疇。而根據本申請方案，位於結算系統中的節點還可以具有以下一種或多種可配置的獨立屬性：
節點的配置類型：
可以理解為一種“標籤”，其作用是方便系統管理用戶對多個具有相同標籤節點進行批量資訊配置，即：透過修改一個標籤的值，實現所有具有該標籤的節點的統一配置。
標籤可以是節點對應帳戶的業務類型，例如“門店”、“業務員”、“終端機”、“一級商戶”、“二級商戶”等等，也可以是節點對應帳戶的結算關係類型，例如“收費終端型”、“中間結算型”、“一級子節點”、“二級子節點”等等，
需要說明的是，節點的配置類型，既可以複用該節點對應帳戶的其他類型，也可以獨立於該節點對應帳戶的其他類型。
例如，在節點的業務類型和結算需求完全一致的情況下，可以將節點的業務類型複用為配置類型；而針對業務類型和結算需求分離的情況。例如前面的舉例，“總商戶-門店-櫃員機”這樣的3級結算體系中，有些櫃員機是設置在門店中，有些櫃員機是獨立設置，儘管其業務類型都是“櫃員機”，但是卻具有不同的結算配置需求。應用本說明書實施例所提供的方案，將節點業務類型和結算需求解耦，從而可以脫離節點業務類型的限制，實現更為靈活的配置。
另外，任一節點可以同時具有多個不同維度下的配置類型，從而方便從多個維度篩選節點。例如，某個節點可以具有“業務員”標籤，還可以同時具有“高比例提成”標籤，則該節點可以分別匹配“業務員”、“高比例提成”以及“高比例提成&業務員”的篩選規則。
節點的入帳來源類型：
節點的入帳來源類型，本身可以作為節點的一種特徵，例如可以複用為節點的配置類型；也可以用於限定哪些類型的入帳來源將參與向上級節點結算；該屬性還可以配合前面實施例中“針對不同入帳來源配置不同的結算規則”來實現功能。
一般而言，任一節點的入帳來源可以包括2個類型：當前節點的子節點帳戶、結算系統之外的帳戶。例如，直接面對客戶收款的節點帳戶（樹形結構中的葉子節點），其入帳來源為“結算系統外帳戶”，而結算體系中的中間階層帳戶（樹形結構中的非葉子節點），其入帳來源為“當前節點的子節點帳戶”。
值得注意的是，對於結算體系中的中間階層帳戶，可以同時允許其入帳來源為“結算系統外帳戶”以及“當前節點的子節點帳戶”。例如，對於“區域總店”這樣一個業務節點而言，其既會接收“區域分店”的結算金額，同時也可以直接收款產生銷售額。
當然，根據實際的應用需求，還可以對入帳來源類型做進一步劃分，或者增加其他的入帳來源類型。
節點的配置權限：
理論上，系統中的任一節點都可以對系統的整體或局部進行配置，實際應用中，配置權限應僅限於少數具有管理性質的節點。根據本說明書所提供的實現方式，可以用“配置權限”這一屬性來表示節點是否具有對系統整體或局部的配置權限。
配置權限可以按照可配置對象進行劃分，例如：
系統的根節點具有對系統整體的配置權限；
任一節點具有對其子孫節點的配置權限；
任一節點具有對其一級子節點的配置權限（但不具有對其更下級子節點的配置權限）；
……
配置權限還可以按照內容劃分，例如：
是否允許在系統中新增/刪除節點；
是否允許修改節點的結算關係；
是否允許對節點的結算規則進行配置；
……
當然，上述配置權限僅用於示意性說明，本領域技術人員可以根據需求靈活設計。此外，配置權限也可以脫離結算體系樹形結構本身的限制，或設置結算系統之外的專用的配置節點，等等。
基於前述提供的系統，本說明書還提供一種金額結算方法，該方法運行於系統中任一節點上，參見圖2所示，該方法可以包括以下步驟：
S101，系統中任一節點在收到入帳金額後，根據預先配置的該節點的父節點標識確定結算目標；
S102，根據所收到的入帳金額，向結算目標進行金額結算。
根據前面實施例的描述，對於系統中任一節點，收到一筆轉入金額後，根據預先配置的父節點標識，就可以確定需要向誰進行結算。
樹形結構中的每一節點都按照S101~S102的步驟執行功能，就形成了一個完整的由下至上逐級結算的系統。需要特別說明的是，根節點對應的總帳戶僅會收到入帳金額，不會進一步向上級發起結算，這裡可以理解為根節點配置的“父節點標識”為空。
如果系統支援結算規則屬性，則在節點發起結算之前，可以根據預先配置的該節點的結算規則，計算所收到入帳金額對應的結算轉出金額，然後進一步將計算得到的結算轉出金額，轉出至結算目標。
此外，在節點收到入帳金額之後，還可以進一步獲取轉入方的資訊，判斷該轉入方是否與預先配置的當前節點的“入帳來源類型”相匹配，或者根據轉入方的資訊確定不同的結算規則，等等。具體功能實現可以參見前面實施例的描述，這裡不再重複說明。
基於前述提供的系統，本說明書還提供相應的系統組態方法，用戶可以透過客戶端實現對系統的配置。按照基本功能可以將客戶端劃分為系統管理客戶端和節點客戶端：
在系統管理客戶端，提供全域配置操作介面，該介面是面對管理用戶的，可以是命令列或GUI形式提供，具體的對話模式可以是按鍵、觸摸、聲控等，本說明書對此並不進行限定。
全域配置操作介面至少可以用於實現系統節點數量增減配置，系統任一節點的父節點標識配置；進一步地，全域配置操作介面還可以用於實現系統任一節點的獨立屬性配置，等等。
用戶在系統管理客戶端進行配置操作時，可以創建或刪除一個新系統、在已有系統中新增或刪除節點、對已有系統的一個或多個節點的配置進行修改。這裡可以利用“節點的配置類型”屬性，對具有相同配置類型的節點進行批量配置。
用戶完成配置操作並確認提交後，系統管理客戶端根據從全域配置操作介面接收到的資訊，對系統進行配置。
在任一節點對應的客戶端，提供局部配置操作介面；該介面是面對節點帳戶使用者的，同樣可以是命令列或GUI形式提供，具體的對話模式可以是按鍵、觸摸、聲控等，本說明書對此並不進行限定。
由於不同節點具有不同的配置權限，因此呈現給不同節點帳戶使用者的可配置項目應是與節點的配置權限內容相匹配的。這裡可以理解為：如果節點不具有任何配置權限，則用戶就看不到（或無法使用）任何可配置項目。
局部配置操作介面可以用於實現：系統局部節點數量增減配置，和/或系統局部節點的父節點標識配置。進一步地，局部配置操作介面還可以用於實現權限範圍內的任一節點的結算規則配置，任一節點的獨立屬性配置，等等。這裡的“系統局部”應理解為對應於配置權限所規定的範圍。例如，如果規定任一節點的配置權限範圍為其子孫節點，則該節點可以實現對其子孫節點的父節點標識、結算規則等屬性進行配置。
用戶在節點客戶端進行配置操作時，可以在配置權限所規定的範圍內新增或刪除節點、對已有的一個或多個節點的配置進行修改。這裡同樣可以利用“節點的配置類型”屬性，對具有相同配置類型的節點進行批量配置。
用戶完成配置操作並確認提交後，節點客戶端根據從全域配置操作介面接收到的資訊，對相應的節點進行配置。
以上介紹了兩種不同類型的客戶端，其本質區別在於，“節點客戶端”對應於結算系統中的某個節點，而“系統管理客戶端”則可以位於結算系統之外，並且不必須具備“帳戶”相互功能。實際應用時，可以分別開發兩種版本的客戶端，也可以在一個版本中，為不同身份的登錄用戶提供不同功能。
可見，應用本說明書所提供的方案，實現複雜結算場景時，可以將總帳戶視為一個根節點，用戶可以在下面建立任意多的子孫節點，形成一棵樹，每一個節點可以配置的內容可以包括：結算上級對象、結算公式、業務類型（例如門店、區域、直營門店等）、其他資訊（例如負責人、地址、電話、為該節點申請的二維碼等）。
每個節點可以設置不同的權限，支援客制化標籤，標籤可以打到不同的節點上，方便做一次性配置並運用到所有相關聯的節點上，減少重複性的勞動。並且標籤可以與節點的業務類型分離，不會出現店鋪一定掛在商戶下面的固定兩級結構。對於系統，不需要知道“店鋪”或者“商戶”或者“終端機”等等的業務類型，樹形結構的每一層或者每一個節點都沒有強制業務類型，業務類型作為一個節點的屬性弱關聯，實現可隨意配置。樹形結構的同一結算層級可以出現不同業務類型的節點，配置不同的結算關係屬性。
下面結合一個實際應用場景，對本說明書提供的方案進行說明。如圖3所示，以某品牌的連鎖店為例，每一個銷售代表都有自己的客戶，客戶得到銷售代表的服務、並到收銀台付款時，銷售代表會把他的帳戶代碼提供給收銀台，把相應的消費記到他的帳上，以便後面計算獎金分紅。
根據現有技術的實現方案，店鋪具有一個二維碼，所有在那個店鋪的消費都在扣除店鋪提成後給向上匯總給總帳戶，店鋪要自行二次把相應的提成部分分配給相應的銷售代表。
而在本說明書所提供的系統中，除了店鋪之外，每個銷售代表都可以列印自己的二維碼，每個銷售代表對應一個結算帳戶，該帳戶屬於結算系統中的葉子節點，具有上級結算對象（店鋪）、結算規則（提成百分比）等屬性。對於系統中的其他業務類型節點，結算方式類似。這樣，對於消費者而言仍是相同的付款流程，但是在結算系統一側，系統可以很清晰地瞭解到是從哪個節點收到的轉入金額、並且應該如何分配這筆金額。
本說明書所提供的結算系統，可以適應各種規模、各種結構的結算需求，特別是對於中小型商戶，可能連自己的銷售管理系統都沒有，那麼應用本申請的方案，可以有效提升這些商戶的金額分配的效率及準確性。
相應於上述方法實施例，本說明書還提供一種金額結算裝置，該裝置位於系統任一節點，參見圖4所示，該裝置可以包括：
結算目標確定單元110，用於在節點在收到入帳金額後，根據預先配置的該節點的父節點標識確定結算目標；
結算處理單元120，用於根據所收到的入帳金額，向結算目標進行金額結算。
相應於上述方法實施例，本說明書還提供一種針對結算系統的配置裝置，該裝置位於系統管理客戶端，參見圖5所示，該裝置可以包括：
全域配置介面提供單元210，用於提供全域配置操作介面，所述全域配置操作介面至少用於實現：系統節點數量增減配置、以及系統任一節點的結算關係屬性配置；
配置執行單元220，用於根據所述全域配置操作介面接收到的資訊，對系統進行配置。
相應於上述方法實施例，本說明書還提供一種針對結算系統的配置裝置，該裝置位於系統任一節點對應的客戶端，參見圖6所示，該裝置可以包括：
局部配置介面提供單元310，用於根據該節點的配置權限，提供與配置權限相匹配的局部配置操作介面；所述局部配置操作介面至少用於實現：系統局部節點數量增減配置，和/或系統局部節點的結算關係屬性配置；
配置執行單元320，用於根據所述局部配置操作介面接收到的資訊，對與配置權限相匹配的系統局部進行配置。
本說明書實施例還提供一種電腦設備，其至少包括記憶體、處理器及儲存在記憶體上並可在處理器上運行的電腦程式，其中，處理器執行所述程式時實現前述的金額結算方法和/或系統組態方法。
圖7示出了本說明書實施例所提供的一種更為具體的計算設備硬體結構示意圖，該設備可以包括：處理器1010、記憶體1020、輸入/輸出介面1030、通信介面1040和匯流排1050。其中處理器1010、記憶體1020、輸入/輸出介面1030和通信介面1040透過匯流排1050實現彼此之間在設備內部的通信連接。
處理器1010可以採用通用的CPU（Central Processing Unit，中央處理器）、微處理器、應用專用積體電路（Application Specific Integrated Circuit，ASIC）、或者一個或多個積體電路等方式實現，用於執行相關程式，以實現本說明書實施例所提供的技術方案。
記憶體1020可以採用ROM（Read Only Memory，唯讀記憶體）、RAM（Random Access Memory，隨機存取記憶體）、靜態存放裝置，動態儲存裝置設備等形式實現。記憶體1020可以儲存作業系統和其他應用程式，在透過軟體或者韌體來實現本說明書實施例所提供的技術方案時，相關的程式碼保存在記憶體1020中，並由處理器1010來調用執行。
輸入/輸出介面1030用於連接輸入/輸出模組，以實現資訊輸入及輸出。輸入輸出/模組可以作為元件配置在設備中（圖中未示出），也可以外接於設備以提供相應功能。其中輸入裝置可以包括鍵盤、滑鼠、觸控式螢幕、麥克風、各類感測器等，輸出設備可以包括顯示器、揚聲器、振動器、指示燈等。
通信介面1040用於連接通信模組（圖中未示出），以實現本設備與其他設備的通信交互。其中通信模組可以透過有線方式（例如USB、網線等）實現通信，也可以透過無線方式（例如移動網路、WIFI、藍牙等）實現通信。
匯流排1050包括一通路，在設備的各個元件（例如處理器1010、記憶體1020、輸入/輸出介面1030和通信介面1040）之間傳輸資訊。
需要說明的是，儘管上述設備僅示出了處理器1010、記憶體1020、輸入/輸出介面1030、通信介面1040以及匯流排1050，但是在具體實施過程中，該設備還可以包括實現正常運行所必需的其他元件。此外，本領域的技術人員可以理解的是，上述設備中也可以僅包含實現本說明書實施例方案所必需的組件，而不必包含圖中所示的全部元件。
本說明書實施例還提供一種電腦可讀儲存媒體，其上儲存有電腦程式，該程式被處理器執行時實現前述的金額結算方法和/或系統組態方法。
電腦可讀媒體包括永久性和非永久性、可移動和非可移動媒體可以由任何方法或技術來實現資訊儲存。資訊可以是電腦可讀指令、資料結構、程式的模組或其他資料。電腦的儲存媒體的例子包括，但不限於相變記憶體（PRAM）、靜態隨機存取記憶體（SRAM）、動態隨機存取記憶體（DRAM）、其他類型的隨機存取記憶體（RAM）、唯讀記憶體（ROM）、電可擦除可編程唯讀記憶體（EEPROM）、快閃記憶體或其他記憶體技術、唯讀光碟唯讀記憶體（CD-ROM）、數位多功能光碟（DVD）或其他光學儲存、磁盒式磁帶，磁帶磁磁片儲存或其他磁性存放裝置或任何其他非傳輸媒體，可用於儲存可以被計算設備存取的資訊。按照本文中的界定，電腦可讀媒體不包括暫存電腦可讀媒體（transitory media），如調製的資料信號和載波。
透過以上的實施方式的描述可知，本領域的技術人員可以清楚地瞭解到本說明書實施例可借助軟體加必需的通用硬體平台的方式來實現。基於這樣的理解，本說明書實施例的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該電腦軟體產品可以儲存在儲存媒體中，如ROM/RAM、磁碟、光碟等，包括若干指令用以使得一台電腦設備（可以是個人電腦，伺服器，或者網路設備等）執行本說明書實施例各個實施例或者實施例的某些部分所述的方法。
上述實施例闡明的系統、裝置、模組或單元，具體可以由電腦晶片或實體實現，或者由具有某種功能的產品來實現。一種典型的實現設備為電腦，電腦的具體形式可以是個人電腦、膝上型電腦、行動電話、相機電話、智慧型電話、個人數位助理、媒體播放機、導航設備、電子郵件收發設備、遊戲控制台、平板電腦、可穿戴設備或者這些設備中的任意幾種設備的組合。
本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於裝置實施例而言，由於其基本相似於方法實施例，所以描述得比較簡單，相關之處參見方法實施例的部分說明即可。以上所描述的裝置實施例僅僅是示意性的，其中所述作為分離部件說明的模組可以是或者也可以不是物理上分開的，在實施本說明書實施例方案時可以把各模組的功能在同一個或多個軟體和/或硬體中實現。也可以根據實際的需要選擇其中的部分或者全部模組來實現本實施例方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解並實施。
以上所述僅是本說明書實施例的具體實施方式，應當指出，對於本技術領域的普通技術人員來說，在不脫離本說明書實施例原理的前提下，還可以做出若干改進和潤飾，這些改進和潤飾也應視為本說明書實施例的保護範圍。In order to enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the technical solutions in the embodiments of this specification will be described in detail below in conjunction with the drawings in the embodiments of this specification. Obviously, the described implementation The examples are only a part of the embodiments in this specification, not all the embodiments. Based on the embodiments in this specification, all other embodiments obtained by a person of ordinary skill in the art should fall within the scope of protection.
In the prior art, for some simple and fixed settlement relationships, automatic settlement of the payment amount can already be achieved. Taking the online booking platform as an example, the ride fare paid by passengers will actually be divided into two parts: one is the actual driver’s The other part of revenue is the platform's commission. Assuming that there are n drivers on a platform, and the platform and each driver correspond to an account, then a two-level settlement system of "1 to n" is formed. In the online car booking platform, the two-level settlement system structure is fixed, and the “platform”’s quota for “drivers” is also fixed (for example, the platform collects 20% of the ride fee), then it can be targeted at For the two account identities of "platform account" and "driver account", a system with a fixed structure and distribution rules is designed to realize automatic settlement of ride expenses.
However, in practical applications, different application scenarios may have completely different settlement requirements. Examples are as follows:
Different merchants have different settlement levels. For example, the simplest settlement system is a two-level one-to-n relationship of "main merchant-store", and more-level settlement systems such as: some merchants will also have "teller machines" under "stores", and some merchants will be "main merchants" There is also the concept of "area" between "stores", and "area" may have multiple levels, such as countries, provinces, cities, and so on.
Different accounts belonging to the same identity type are in different positions in the settlement system. For example, in a three-level settlement system such as "main merchant-store-teller machine", if some teller machines are set up in stores, their superior settlement object is the "store", and some teller machines are independently set up (not belonging to any store), then Its superior settlement object is the "general merchant";
Different accounts belonging to the same level (or the same identity type) use different settlement rules in the settlement system. For example, different sales staff have different sales amount commission ratios, and different regions have different rebate points.
It can be seen that the automatic settlement in the prior art only sets a fixed settlement system for a specific application scenario, and cannot meet the changing settlement requirements.
Through analysis, technical staff found that in the complex amount settlement application scenario, the settlement relationship of each account has the following characteristics:
Subordinate accounts are billed to superior accounts, and there can be multiple levels of "subordinate and subordinate" relationships. For example, the teller machine settles with the store, and the store settles with the general merchant;
The upper-level account and the lower-level account are in a "one-to-many" relationship, that is, multiple lower-level accounts can be billed to the same upper-level account. For example, there are multiple teller machines under a store;
The settlement amount is settled step by step in a bottom-up direction, and finally collected into a master account;
For the above specific application scenarios, the embodiments of this specification provide a flexibly configurable amount settlement system, and the specific implementation scheme is as follows:
● The system has a number of nodes, among which the number of nodes is configurable, that is, system management users can add/delete nodes in the system. Each node corresponds to an electronic account, which can rely on the client to realize basic functions such as money transfer in/out, so it can be regarded as a functional module in the system.
● Each node has several attributes, one or more of these attributes are also configurable.
● The nodes are related in a tree structure, and each parent-child relationship corresponds to a set of accounts that have a settlement relationship: the parent node corresponds to the settlement amount transfer account, and the child node corresponds to the settlement amount transfer account;
A tree structure generally refers to a data structure with a "one-to-many" relationship between multiple nodes. In the tree structure, the root node has no parent node, and each of the remaining nodes has one and only one parent node; the leaf nodes have no child nodes , Each other node can have one or more child nodes. The scenario corresponding to the amount settlement in this manual is as follows: Except for the general account (root node), each lower-level account (child node) settles to its upper-level account (parent node), and supports multi-level settlement (multi-level tree structure), And it supports multiple lower-level accounts to settle to the same upper-level account (a parent node corresponds to multiple child nodes), and the settlement amount is finally aggregated into the total account (only one root node).
Each node has several attributes, which can be divided into "independent attributes" and "relational attributes" in nature, which are introduced separately below:
"Relationship attributes" are used to characterize the relationship between the node and other nodes in the system. To meet the needs of settlement application scenarios, the relationship attributes should at least include settlement relationship attributes.
For each node in the system (except the root node), after receiving a transfer amount, it needs to know whom to settle to. Therefore, the settlement relationship attribute of any node should include at least the parent node identifier of the node.
In the three-tier settlement system shown in Figure 1, a is the root node, and the settlement relationship in the whole domain includes: settlement of c1, c2 to b1, settlement of c3 to b2, and settlement of b1 and b2 to a.
Then, the settlement relationship configuration of each node except the root node is as follows:
c1: (parent node: b1)
c2: (parent node: b1)
c3: (parent node: b2)
b1: (parent node: a)
b2: (parent node: a)
By default, each node can use uniform rules to settle to the upper-level node, for example, settle 100% of the transferred amount to the upper-level node, settle 80% of the transferred amount to the upper-level node, and so on. In order to meet more flexible settlement requirements, you can also add a "settlement rule" to the settlement relationship attribute to indicate the mapping relationship between the node's entry amount and the settlement transfer amount.
Still taking the three-tier settlement system shown in Figure 1 as an example, the configuration results after adding settlement rules are as follows:
c1: (parent node: b1), (settlement ratio: 1)
c2: (parent node: b1), (settlement ratio: 1)
c3: (parent node: b2), (settlement ratio: 1)
b1: (parent node: a), (settlement ratio: 0.9)
b2: (parent node: a), (settlement ratio: 0.8)
According to the above settlement rule configuration, c1, c2, and c3 are all settled to the superior node in full, and the proportions of b1 and b2 to settle to the superior node are 0.9 and 0.8, respectively. It can be seen that not only nodes of different levels can support different upward settlement ratios, but nodes of the same level can also support different upward settlement ratios.
It is understandable that the settlement ratio is only a specific manifestation of the settlement rules. According to actual needs, the settlement rules can be configured as other forms of "accounting amount→transferred amount" mapping relationship. For example, in addition to a fixed settlement ratio (equivalent to a linear function of the mapping relationship), you can also use piecewise functions, exponential functions, etc., to configure the settlement ratio to dynamically change according to the amount of each entry, or the settlement ratio according to the statistical cycle (for example, 1 month) The total amount in the account changes dynamically; of course, the settlement relationship is not limited to the expression of the settlement ratio, and those skilled in the art can flexibly configure it according to actual needs.
In addition, in any node, you can also configure different settlement rules for different sources of accounting, for example:
"Different sources" can be different lower-level computing nodes, for example, for node b1 in Figure 1:
b1: (parent node: a), (settlement ratio: [if source c1:0.95], [if source c2:0.85])
"Different sources" can be different types of accounts, for example, for the b2 node in Figure 1:
b2: (parent node: a), (settlement ratio: [if source subordinate node: 0.85], [if source direct entry: 0.75])
In addition to "parent node identification" and "settlement rules", the relationship attributes of any node can also include other content, such as:
The child node ID can be used for verification and needs to be updated synchronously with the parent node ID in the child node;
Business relationship information can be used to record the business superior/subordinate of the account corresponding to the node. Note that the business relationship and settlement relationship here can be the same or independent of each other, that is: the superior/subordinate in the business relationship is not necessarily the settlement The superior/subordinate in the relationship.
Compared with "relational attributes", "independent attributes" are used to characterize the independent characteristics of any node, and these attributes are not related to other nodes. For each account, "account name", "bind user information", "person in charge", "address", "telephone", etc., belong to the category of independent attributes. According to the solution of this application, the nodes located in the settlement system may also have one or more of the following configurable independent attributes:
Node configuration type:
It can be understood as a kind of "label", whose function is to facilitate system management users to configure batch information for multiple nodes with the same label, that is, by modifying the value of a label, the unified configuration of all nodes with the label is realized.
The label can be the business type of the account corresponding to the node, such as "store", "salesman", "terminal", "first-level merchant", "second-level merchant", etc., or the settlement relationship type of the node's corresponding account, for example "Charging terminal type", "intermediate settlement type", "first-level sub-node", "second-level sub-node", etc.,
It should be noted that the configuration type of the node can either reuse other types of accounts corresponding to the node, or be independent of other types of accounts corresponding to the node.
For example, when the service type of the node and the settlement requirement are completely consistent, the service type of the node can be reused as the configuration type; and for the case where the service type and settlement requirement are separated. For example, in the previous example, in a three-level settlement system such as "General Merchant-Store-Teller Machine", some teller machines are set up in stores, and some are set up independently. Although their business types are all "teller machines", they have different Settlement configuration requirements. The solution provided by the embodiment of this specification is used to decouple the node service type and the settlement requirement, so that the restriction of the node service type can be separated and more flexible configuration can be realized.
In addition, any node can have multiple configuration types in different dimensions at the same time, so that it is convenient to filter nodes from multiple dimensions. For example, a node can have a "salesman" label, and it can also have a "high percentage commission" label, then the node can match the "salesman", "high percentage commission" and "high percentage commission & salesman" label. Filtering rules.
The type of the node's accounting source:
The source type of the node can be used as a feature of the node, for example, it can be reused as the configuration type of the node; it can also be used to limit which types of account sources will participate in the settlement of the superior node; this attribute can also be used in conjunction with the previous implementation In the example, "configure different settlement rules for different sources of account" to achieve the function.
Generally speaking, the accounting source of any node can include two types: sub-node accounts of the current node and accounts outside the settlement system. For example, the node account that directly faces the customer receiving payment (the leaf node in the tree structure), the source of which is the "account outside the settlement system", and the middle-level account in the settlement system (the non-leaf node in the tree structure) ), the source of its credit is "the current node's child node account".
It is worth noting that, for the middle-level accounts in the settlement system, the sources of their accounts can be allowed to be “accounts outside the settlement system” and “sub-node accounts of the current node” at the same time. For example, for a business node such as the "regional head office", it will not only receive the settlement amount of the "regional branch", but also directly collect payments to generate sales.
Of course, according to actual application requirements, you can further divide the types of accounting sources, or add other types of accounting sources.
Configuration authority of the node:
In theory, any node in the system can configure the whole or part of the system. In actual applications, the configuration authority should be limited to a few nodes with management properties. According to the implementation provided in this specification, the attribute "configuration authority" can be used to indicate whether a node has the overall or partial configuration authority of the system.
Configuration permissions can be divided according to configurable objects, for example:
The root node of the system has the authority to configure the entire system;
Any node has the configuration authority for its descendants;
Any node has the configuration authority to its first-level child nodes (but does not have the configuration authority to its lower-level child nodes);
...
Configuration permissions can also be divided according to content, for example:
Whether to allow adding/deleting nodes in the system;
Whether it is allowed to modify the settlement relationship of the node;
Whether it is allowed to configure the settlement rules of the node;
...
Of course, the above configuration permissions are only used for schematic illustration, and those skilled in the art can flexibly design according to requirements. In addition, the configuration authority can also break away from the limitation of the settlement system's tree structure itself, or set up dedicated configuration nodes outside the settlement system, and so on.
Based on the aforementioned system, this specification also provides an amount settlement method that runs on any node in the system. As shown in Figure 2, the method may include the following steps:
S101: After receiving the credited amount, any node in the system determines the settlement target according to the pre-configured parent node identifier of the node;
S102: Perform an amount settlement to the settlement target according to the received credited amount.
According to the description of the previous embodiment, for any node in the system, after receiving a transfer amount, according to the pre-configured parent node identifier, it is possible to determine to whom the settlement needs to be made.
Each node in the tree structure executes its function according to the steps of S101~S102, forming a complete system of settlement from bottom to top. It should be noted that the total account corresponding to the root node will only receive the credited amount and will not further initiate settlement to the higher level. It can be understood that the "parent node identifier" configured by the root node is empty.
If the system supports settlement rule attributes, before the node initiates settlement, it can calculate the settlement transfer-out amount corresponding to the received deposit amount according to the pre-configured settlement rule of the node, and then further transfer the calculated settlement transfer-out amount. Transfer out to the settlement goal.
In addition, after the node receives the credited amount, it can further obtain the transferor's information to determine whether the transferor matches the pre-configured current node's "account source type", or according to the transferor's information Determine different settlement rules, etc. For specific function implementation, refer to the description of the previous embodiment, and the description will not be repeated here.
Based on the aforementioned system, this manual also provides a corresponding system configuration method, and users can configure the system through the client. According to the basic functions, the client can be divided into system management client and node client:
On the system management client, a global configuration operation interface is provided. This interface is for the management user. It can be provided in the form of command line or GUI. The specific dialogue mode can be buttons, touch, voice control, etc. This manual does not deal with this limited.
The global configuration operation interface can at least be used to realize the configuration of the increase or decrease of the number of system nodes, the configuration of the parent node identification of any node in the system; further, the global configuration operation interface can also be used to realize the independent attribute configuration of any node of the system, and so on.
When performing configuration operations on the system management client, users can create or delete a new system, add or delete nodes in an existing system, and modify the configuration of one or more nodes in the existing system. Here, you can use the "node configuration type" attribute to configure batches of nodes with the same configuration type.
After the user completes the configuration operation and confirms the submission, the system management client configures the system according to the information received from the global configuration operation interface.
On the client corresponding to any node, a local configuration operation interface is provided; this interface is for the user of the node account, and can also be provided in the form of command line or GUI. The specific dialogue mode can be buttons, touch, voice control, etc. This manual This is not limited.
Since different nodes have different configuration rights, the configurable items presented to users of different node accounts should match the configuration rights of the node. This can be understood as: if the node does not have any configuration permissions, the user will not see (or cannot use) any configurable items.
The local configuration operation interface can be used to implement: increase or decrease the number of system local nodes, and/or the parent node identification configuration of the system local nodes. Further, the local configuration operation interface can also be used to implement the settlement rule configuration of any node within the scope of authority, the independent attribute configuration of any node, and so on. The "system part" here should be understood as corresponding to the scope specified by the configuration authority. For example, if the configuration authority scope of any node is specified as its descendant nodes, the node can realize the configuration of attributes such as the parent node identification and settlement rules of its descendant nodes.
When the user performs configuration operations on the node client, he can add or delete nodes within the scope specified by the configuration authority, and modify the configuration of one or more existing nodes. Here you can also use the "node configuration type" attribute to configure nodes with the same configuration type in batches.
After the user completes the configuration operation and confirms the submission, the node client configures the corresponding node according to the information received from the global configuration operation interface.
The two different types of clients are introduced above. The essential difference is that the "node client" corresponds to a node in the settlement system, while the "system management client" can be located outside the settlement system and does not have to be "Account" mutual function. In actual application, two versions of the client can be developed separately, or in one version, different functions can be provided for login users with different identities.
It can be seen that when applying the solution provided in this manual to realize complex settlement scenarios, the total account can be regarded as a root node, and the user can create as many descendant nodes as needed to form a tree. The content that can be configured for each node can be Including: settlement superior object, settlement formula, business type (such as store, area, direct-sale store, etc.), other information (such as person in charge, address, phone number, QR code applied for the node, etc.).
Each node can be set with different permissions, support customized tags, and tags can be placed on different nodes, which facilitates one-time configuration and applies to all associated nodes, reducing repetitive labor. And the label can be separated from the business type of the node, and there will be no fixed two-level structure where the store must be hung under the merchant. For the system, there is no need to know the business types such as "shops" or "merchants" or "terminals". Each layer or node of the tree structure has no mandatory business types. The business types are weakly related as the attributes of a node. The realization can be configured at will. Nodes of different business types can appear at the same settlement level in the tree structure, and different settlement relationship attributes can be configured.
The following describes the solution provided in this manual in conjunction with a practical application scenario. As shown in Figure 3, taking a certain brand of chain stores as an example, each sales representative has his own customer. When the customer receives the service of the sales representative and pays at the cashier, the sales representative will provide his account code to the cashier. , The corresponding consumption will be credited to his account to calculate bonus dividends later.
According to the implementation scheme of the prior art, the store has a QR code, and all the consumption in that store is summed up to the general account after deducting the store commission. The store must allocate the corresponding commission to the corresponding sales representative twice.
In the system provided in this manual, except for shops, each sales representative can print his own QR code. Each sales representative corresponds to a settlement account, which belongs to the leaf node of the settlement system and has a superior Attributes such as settlement object (shop), settlement rule (commission percentage). For other business type nodes in the system, the settlement method is similar. In this way, the payment process is still the same for consumers, but on the side of the settlement system, the system can clearly understand from which node the transfer amount was received and how the amount should be distributed.
The settlement system provided in this manual can meet the settlement needs of various scales and structures, especially for small and medium-sized merchants, who may not even have their own sales management system. Then the application of this application can effectively increase the amount of these merchants. The efficiency and accuracy of allocation.
Corresponding to the above method embodiment, this specification also provides an amount settlement device, which is located at any node of the system. As shown in Figure 4, the device may include:
The settlement target determining unit 110 is configured to determine the settlement target according to the pre-configured parent node identifier of the node after the node receives the credited amount;
The settlement processing unit 120 is configured to settle the amount to the settlement target according to the received amount in the account.
Corresponding to the above method embodiment, this specification also provides a configuration device for the settlement system, the device is located in the system management client, as shown in Figure 5, the device may include:
The global configuration interface providing unit 210 is configured to provide a global configuration operation interface, the global configuration operation interface is used to at least realize: the configuration of increase or decrease of the number of system nodes, and the configuration of settlement relationship attributes of any node of the system;
The configuration execution unit 220 is configured to configure the system according to the information received by the global configuration operation interface.
Corresponding to the foregoing method embodiment, this specification also provides a configuration device for the settlement system, which is located at the client corresponding to any node in the system. As shown in Figure 6, the device may include:
The local configuration interface providing unit 310 is configured to provide a local configuration operation interface that matches the configuration authority according to the configuration authority of the node; the local configuration operation interface is used to at least realize: increase or decrease the number of local nodes in the system, and/or Settlement relationship attribute configuration of local nodes of the system;
The configuration execution unit 320 is configured to configure the part of the system that matches the configuration authority according to the information received by the partial configuration operation interface.
The embodiment of this specification also provides a computer device, which at least includes a memory, a processor, and a computer program stored on the memory and capable of running on the processor, wherein the processor executes the program to implement the aforementioned amount settlement method And/or system configuration method.
FIG. 7 shows a more specific hardware structure diagram of a computing device provided by an embodiment of this specification. The device may include a processor 1010, a memory 1020, an input/output interface 1030, a communication interface 1040, and a bus 1050. . The processor 1010, the memory 1020, the input/output interface 1030 and the communication interface 1040 realize the communication connection between each other in the device through the bus 1050.
The processor 1010 may be implemented by a general CPU (Central Processing Unit, central processing unit), a microprocessor, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), or one or more integrated circuits, etc., for Execute related programs to realize the technical solutions provided in the embodiments of this specification.
The memory 1020 can be implemented in the form of ROM (Read Only Memory), RAM (Random Access Memory), static storage device, dynamic storage device, etc. The memory 1020 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the related program codes are stored in the memory 1020 and called and executed by the processor 1010. .
The input/output interface 1030 is used for connecting input/output modules to realize information input and output. The input/output/module can be configured as a component in the device (not shown in the figure), or it can be connected to the device to provide corresponding functions. The input device may include a keyboard, a mouse, a touch screen, a microphone, various sensors, etc., and an output device may include a display, a speaker, a vibrator, an indicator light, and so on.
The communication interface 1040 is used to connect a communication module (not shown in the figure) to realize the communication interaction between the device and other devices. The communication module can realize communication through wired means (such as USB, network cable, etc.), or through wireless means (such as mobile network, WIFI, Bluetooth, etc.).
The bus 1050 includes a path for transmitting information between various components of the device (such as the processor 1010, the memory 1020, the input/output interface 1030, and the communication interface 1040).
It should be noted that although the above device only shows the processor 1010, the memory 1020, the input/output interface 1030, the communication interface 1040, and the bus 1050, in the specific implementation process, the device may also include a device for normal operation. Other necessary components. In addition, those skilled in the art can understand that the above-mentioned equipment may also include only the components necessary to implement the solutions of the embodiments of the present specification, and not necessarily include all the elements shown in the figures.
The embodiment of the present specification also provides a computer-readable storage medium on which a computer program is stored, and when the program is executed by a processor, the aforementioned amount settlement method and/or system configuration method are realized.
Computer-readable media includes permanent and non-permanent, removable and non-removable media, and information storage can be realized by any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), and other types of random access memory (RAM) , Read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital multi-function optical disc (DVD) or other optical storage, magnetic cassettes, magnetic tape storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by computing devices. According to the definition in this article, computer-readable media does not include transitory media, such as modulated data signals and carrier waves.
From the description of the above embodiments, those skilled in the art can clearly understand that the embodiments of this specification can be implemented by means of software plus a necessary general hardware platform. Based on this understanding, the technical solutions of the embodiments of this specification can be embodied in the form of software products, which can be stored in storage media, such as ROM/RAM, magnetic A disc, an optical disc, etc., include a number of instructions to make a computer device (which may be a personal computer, a server, or a network device, etc.) execute the methods described in the various embodiments or some parts of the embodiments of this specification.
The systems, devices, modules, or units explained in the above embodiments may be implemented by computer chips or entities, or implemented by products with certain functions. A typical implementation device is a computer. The specific form of the computer can be a personal computer, a laptop, a mobile phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email receiving and sending device, and a game control Desktop, tablet, wearable device, or any combination of these devices.
The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the various embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, as for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and for related parts, please refer to the part of the description of the method embodiment. The device embodiments described above are merely illustrative. The modules described as separate components may or may not be physically separated. When implementing the embodiments of this specification, the functions of the modules may be Implemented in the same one or more software and/or hardware. It is also possible to select some or all of the modules according to actual needs to achieve the objectives of the solutions of the embodiments. Those of ordinary skill in the art can understand and implement it without creative work.
The above are only specific implementations of the embodiments of this specification. It should be pointed out that for those of ordinary skill in the art, without departing from the principle of the embodiments of this specification, several improvements and modifications can be made. These Improvement and retouching should also be regarded as the protection scope of the embodiments of this specification.
