賬戶系統(tǒng)設計從入門到精通

13 評論 25944 瀏覽 181 收藏 43 分鐘
🔗 B端产品经理需要更多地关注客户的商业需求、痛点、预算、决策流程等,而C端产品经理需要更多地关注用户的个人需求

導語:賬戶是支付交易的最基礎設施,由此可見其重要性。賬戶系統(tǒng)設計的核心不是設計本身,而是其的理念、規(guī)范以及基本原則。本文作者歸納總結(jié)了以往分散的賬戶類文章,并且附帶了后臺設計的幾頁關鍵頁面原型,希望可以幫助你從0到1全面掌握賬戶系統(tǒng)的設計方法。

一、第一部分:賬戶系統(tǒng)概述

賬戶體系是支付交易的基礎,就像電池對于手機,油罐對于加油站,心臟對于人體?那么這么核心的系統(tǒng)是不是很難設計呢,其實恰恰不難;這也印證了那樣一句話“大道至簡”。

1. 什么是賬戶

我們先看看標準定義:賬戶是根據(jù)會計科目設置的,具有一定格式和結(jié)構(gòu),用于反映會計要素的增減變動情況及其結(jié)果的載體。

增減變動的會計分錄的書寫規(guī)范:

  • 借:科目A 金額1
  • 貸:科目B 金額1

賬戶結(jié)構(gòu)規(guī)范:

賬戶的基本結(jié)構(gòu)應同時具備以下內(nèi)容:

  1. 賬戶的名稱,即會計科目;
  2. 日期和摘要,即記載經(jīng)濟業(yè)務的日期和概括說明經(jīng)濟業(yè)務的內(nèi)容;
  3. 增加方和減少方的金額及余額;
  4. 憑證號數(shù),即說明記載賬戶記錄的依據(jù)。

賬戶系統(tǒng)設計從入門到精通

財務知識不是很充足的同學可能對以上的賬戶定義很難理解和繞口;我們從業(yè)務的角度來看賬戶,后面的電子賬戶我們都會從業(yè)務角度去看,拋棄財務視角。從業(yè)務視角來看賬戶,其實就是用于記錄某個主體的某類型資金的余額以及余額變動明細的數(shù)據(jù)載體。

所以賬戶有3個關鍵的點:

  1. 賬戶余額:這個賬戶有多少錢;
  2. 賬戶流水:這個賬戶資金進進出出的明細記錄;
  3. 賬戶交易:怎么把錢放進去,怎么把錢取出來。

賬戶系統(tǒng)設計從入門到精通

抓住了上面3個點我們基本就抓住了賬戶設計的核心了,是不是很簡單?

基于這3個點去構(gòu)建賬戶的輔助設施,比如賬戶主體,賬戶種類,賬戶余額結(jié)構(gòu),賬戶流水的記錄字段,賬戶的功能權(quán)限,賬戶的出入賬,賬戶服務(賬戶開通注銷,凍結(jié)解凍,余額流水查詢等)等。

2. 賬戶的種類

從財務科目分類來看內(nèi)部賬戶,賬戶可以分資產(chǎn)類賬戶,負債類賬戶,損益類賬戶,共同類賬戶,然后就是不同的科目。

賬戶系統(tǒng)設計從入門到精通

但是站在業(yè)務的視角,我們更多是基于業(yè)務場景來對賬戶進行命名,比如商戶的結(jié)算款會結(jié)算到商戶結(jié)算賬戶,支付公司在銀行開的賬戶叫備付金賬戶,備付金賬戶又分存管戶、收付戶、匯繳戶;個人賬戶、企業(yè)賬戶;會員子賬戶、商戶子賬戶、中間擔保戶。

賬戶系統(tǒng)設計從入門到精通

所以從賬戶命名上我們基本就知道了這個賬戶是干嘛用的;就像你有10張卡,一張是放工資的你叫他工資卡,一張是公積金的你叫公積金卡等等,所以這時候我們基于業(yè)務命名,目的是為了區(qū)分賬戶用途。

但是收回來我們發(fā)現(xiàn),無論賬戶叫什么名字,都是有賬戶余額、賬戶流水、賬戶交易。無論卡叫什么名字都是銀行卡,所以賬戶的本質(zhì)屬性不變,設計辦法基本相通,唯一會有不同的是附屬內(nèi)容,比如支出戶只能打款不能收款,中間擔保戶不能為負等等,權(quán)限不同,主體不同,交易特點不同…..

小樣,你以為穿個馬甲我就不認識你啦,你裝錢的,能進能出,記得明明白白;別管你叫啥我都知道怎么設計,不管我叫你啥我都這么設計。

3. 賬戶的結(jié)構(gòu)

賬戶結(jié)構(gòu):

賬戶系統(tǒng)設計從入門到精通

  • 賬戶主體:這個賬戶是誰的,個人的?企業(yè)的?內(nèi)部業(yè)務線的?
  • 賬戶結(jié)構(gòu)樹:就像會計科目,就像商品類目,由于賬戶可能種類繁多所以有時也需要一個結(jié)構(gòu)樹,比如:

賬戶系統(tǒng)設計從入門到精通

  • 賬戶類型:賬戶的分類,比如個人賬戶/對公賬戶、結(jié)算賬戶/付款賬戶、收款賬戶/打款賬戶;
  • 賬戶名稱:錢多少不重要,名字一定要有氣質(zhì):陳老師全球通國際清算私房錢賬戶;
  • 賬戶余額:賬戶余額一般為了業(yè)務需要,會設計多個金額屬性,比如凍結(jié)金額,可用金額,可提金額;

賬戶系統(tǒng)設計從入門到精通

  • 賬戶流水:賬戶的資金變動記錄,記錄對手賬戶,收支方向,金額,費用類型等基本信息;

  • 賬戶服務:開通/關閉、權(quán)限設置、入賬、扣賬、調(diào)賬、凍結(jié)/解凍、余額查詢、流水查詢;
  • 賬戶底線原則:支付成功才入賬,扣賬成功才出款,一分不少真安全。

4. 如何設計類型

賬戶名稱:結(jié)算戶,付款戶,支出戶

原則:名稱是便于區(qū)分業(yè)務,賬戶本質(zhì)相同。就像有的公司叫產(chǎn)品經(jīng)理,有的公司就產(chǎn)品策劃,有的公司叫需求分析師,但本質(zhì)大家干的都是產(chǎn)品設計工作:

  • 基于主體類型命名賬戶:個人賬戶、企業(yè)賬戶;
  • 基于業(yè)務類型命名賬戶:電商商家結(jié)算戶、快遞商家結(jié)算戶;
  • 基于資金屬性命名賬戶:工資賬戶、公積金賬戶、手續(xù)費賬戶;
  • 基于賬戶職能命名賬戶:待清算賬戶、中間擔保賬戶。

現(xiàn)在應該清楚設計賬戶時如何給賬戶命名了吧,簡單易記,容易區(qū)分。

5. 賬戶的附屬設施

有了電池是不是還需要充電線,有了油罐是不是還得有加油設備、安全設備,同樣有了賬戶是不是還得有附屬模塊才能實現(xiàn)賬戶的資金管理職能。

費用類型:每筆交易都有業(yè)務場景,比如下單付款、投訴罰款、用戶充值、余額提現(xiàn)、賬戶年費等等,一個是為了讓用戶知道這是筆什么交易,另一個就是財務能夠知道編寫什么科目的會計憑證。

入賬規(guī)則:上游有業(yè)務系統(tǒng)比如賬務系統(tǒng)請求一筆費用的入賬,那么如那個賬戶呢,收支方向如何呢?所以入賬規(guī)則就是來確定這筆入賬怎么入的問題,規(guī)則主要有2部分組成。

凍結(jié)規(guī)則:有些費用入賬后是需要暫時凍結(jié)的,比如用戶領的活動獎金,必須在凍結(jié)7個工作日之后才能解凍;某業(yè)務線的商家結(jié)算收入,統(tǒng)一在次月15號可提走;所以一條入賬規(guī)則需要關聯(lián)一個凍結(jié)規(guī)則。

費用/入賬規(guī)則/凍結(jié)規(guī)則關系:一個費用入賬時,可能記一筆賬,也可能記多筆;比如商戶傭金費用,則會入兩筆賬:成本賬戶入一筆扣款,商家傭金賬戶入一筆收入;而扣款不用凍結(jié),收入需要凍結(jié)7天。

賬戶系統(tǒng)設計從入門到精通

對外服務:任何系統(tǒng)都不是孤島,賬戶系統(tǒng)同樣,要將能力賦能給上游實現(xiàn)自己的價值;賬戶向外提供的服務基礎的應該包含:開戶、注銷、查詢(余額、流水、狀態(tài))、交易(支付、退款、充值、提現(xiàn)、凍結(jié))等。

賬戶系統(tǒng)設計從入門到精通

賬戶管理后臺:賬戶系統(tǒng)需要提供一個業(yè)務后臺給到相關的運營人員,財務等角色;后臺可以查看所有的賬戶以及賬戶的狀態(tài),所屬主體以及余額情況;還可以操作賬戶進行注銷,還需要能夠查看所有的出入賬流水,配置相關費用,配置入賬規(guī)則和凍結(jié)規(guī)則。

賬戶系統(tǒng)設計從入門到精通

6. 賬戶系統(tǒng)架構(gòu)圖

功能架構(gòu):

賬戶系統(tǒng)設計從入門到精通

業(yè)務架構(gòu):

賬戶系統(tǒng)設計從入門到精通

7. 賬戶入賬流程圖

賬戶系統(tǒng)設計從入門到精通

8. 賬戶系統(tǒng)后臺

上面基本已經(jīng)很清楚了,賬戶系統(tǒng)后臺頁面文章不再詳述,原型可以到星球進行下載。

9. 賬戶的應用

賬戶除了管錢之外還可以在此之上構(gòu)建一些應用產(chǎn)品比如下面這兩個:

  • 錢包:像微信錢包,就是用戶的一個虛擬賬戶,在錢包里可以看到余額,可以充值余額,也可以將余額里的錢提現(xiàn)到銀行卡;
  • 余額支付:賬戶可以作為一種支付方式,包裝出一個支付通道,利用平臺自己的賬戶進行平臺商品的購買支付,當然這個要考慮合規(guī)性。

10. 合規(guī)淺談

果然最后說的都是重頭戲,賬戶作為一種資金池形態(tài),要嚴格做好其合規(guī)性,如果平臺沒有資質(zhì)牌照,那么自建可以但是用戶賬戶的真實資金一定要放到監(jiān)管賬戶當中進行監(jiān)管,避免違規(guī)沉淀資金池,其他合規(guī)風險讀者朋友們自己思考一下吧。

二、第二部分:賬戶主體

賬戶本身記錄的是資產(chǎn)或者負債或者費用,那么必然就需要一個主體承載,誰的錢,誰的債,誰的費用,誰的愛!世界上沒有一片樹葉沒有歸屬,就算秋風落了葉,那它要不屬于天空或是歸屬大地,所以賬戶歸于誰,而這個誰是誰就是今天我們要聊的主體。

1. 什么是主體

主體可以是人,可以是公司,可以是一個組織,我們暫且認為主體就是一個具有基本特征和屬性的一個可定義的對象。

2. 主體的廣義定義

基于對象出發(fā),那么主體可以認為是自然界存在的實體物質(zhì)和虛無的對象;比如一個人是一個主體,一個公司是一個主體,一個組織是一個主體;公司的一條業(yè)務線是一個主體,公司的一個部門也是一個主體,一個城市也是一個主體,一座房子也是一個主體等等。

那么這么多主體有什么意義呢,其實就是說明賬戶的主體可以非常廣義,比如一個城市的GDP,可以通過一個統(tǒng)計報表得到,同樣也可以為每個城市設置一個GDP賬戶,那么這個賬戶的主體就是一座城市;北京GDP賬戶2020年年末余額4萬億!

所以主要是一個可以被定義的對象,我們就可以將它作為賬戶的主體來管理,就可以為之開通某種意義上的賬戶,賬戶也可以是廣義的,不只是金錢余額,也可以是水量余額,點量余額,好感度余額等等,從而賬戶的廣義我們是不是就可以認為:賬戶可以記錄一個可被量化的數(shù)量以及變化過程的記錄工具;那么我們就可以用賬戶的設計理念去設計更多的事物的數(shù)量以及變化過程。

3. 狹義賬戶主體

我們回歸賬戶主體本身,就是賬戶的歸屬對象。最常見的主體就是個人和企業(yè),銀行卡的主體有個人主體和法人主體。

對于一個公司內(nèi)部來說為了經(jīng)營分析或者管理的需要又會虛擬出更多的主體類型,比如營銷賬戶的這類費用賬戶的主體可以是業(yè)務線或者部門或者小組,來記錄部門和小組的預算以及預算的消耗:

  • 站在人民銀行的角度看賬戶主體我們知道就是:網(wǎng)聯(lián)、銀聯(lián)、各商業(yè)銀行、各城市處理中心、各特批處理機構(gòu)等;
  • 站在銀行角度看銀行賬戶主體就是:個人、企業(yè)、支付機構(gòu)等;
  • 站在一個普通企業(yè)看賬戶主體就是:個人用戶、企業(yè)用戶、內(nèi)部業(yè)務線、子公司等。

4. 主體的唯一ID

就像個人我們的唯一ID可以是身份證,我們在開銀行卡的時候就是用的身份證ID作為這個主體的唯一ID,在辦理社保的時候也是用身份證ID作為身份的唯一ID;唯一ID的條件就是能夠唯一識別這個主體。

比如個人的唯一ID可以是身份證,手機號,社保號,一個平臺的userID及時在這個平臺的唯一ID;企業(yè)的唯一ID可以是統(tǒng)一社會信用編號,也可以是對公戶的卡號等;如果企業(yè)入駐了一個平臺那么這個平臺為這個企業(yè)生成的企業(yè)編碼也可以唯一識別這個企業(yè)。

唯一ID的用途就是唯一識別這個主體,但是有時候可能這個主體的唯一身份ID不夠用,比如這個人在淘寶即是個人用戶又是商家用戶,那么他在開戶時可能就不能只用身份證了,而是用userID 去開付款戶 和bussid 去開結(jié)算戶。

5. 主體的身份認證

安全起見,我們需要核查主體的身份,像銀行開戶需要本人到場+身份證核驗;二類戶的開通需要多要素鑒權(quán)識別主體身份的合法性,對于企業(yè)來說企業(yè)的營業(yè)執(zhí)照,法人簽字,蓋章或者對公戶小額打款來驗證企業(yè)的真實身份。

6. 主體的創(chuàng)建

對于一個平臺而言,其賬戶系統(tǒng)的主體無非以下幾種:

  • 個人用戶:具有身份證或者手機號唯一識別的一個自然人個體;
  • 企業(yè)用戶:具有企業(yè)信用編號唯一識別的一個法人主體;
  • 內(nèi)部主體用戶:為了管理需要內(nèi)部的子公司主體或者業(yè)務線主體或者部門;
  • 主體下業(yè)務線子用戶:一個子公司下面的一個業(yè)務線或者部門。

所以我們在創(chuàng)建主體的同時就需要定義每一類主體的唯一識別ID,在開戶的時候,就需要使用這個唯一識別ID作為賬戶主體的唯一識別ID。

7. 主體的信息管理

一個平臺的各類主體信息一般是放在用戶中心或者crm系統(tǒng),這些系統(tǒng)去調(diào)用賬戶中心進行開戶,在這些系統(tǒng)內(nèi)對于一個主體我們需要管理他的基本信息。

比如ID信息、屬性信息、權(quán)限信息、關系信息,有什么信息就增加字段管理即可,也可以將信息分類,每一類記錄的不同的表中,比如身份信息、認證信息、賬戶開通信息等。

賬戶系統(tǒng)設計從入門到精通

8. 為主體開戶

有了主體以后,賬戶的開通可以是人工也可以是上游系統(tǒng)調(diào)用開戶接口開通相關賬戶和賬戶權(quán)限。

賬戶系統(tǒng)設計從入門到精通

比如接口要傳入下面的信息:

  • 入?yún)?/li>
  • 主體ID:123
  • ID類型:userid
  • 用戶類型:個人
  • 用戶姓名:張三
  • 開通賬戶類型:傭金賬戶
  • 賬戶特殊要求:可付款

請求成功后賬戶系統(tǒng)就會先在賬戶主體表中插入基本主體信息,如果需要其他信息,在后面加字段即可。

賬戶系統(tǒng)設計從入門到精通

根據(jù)主體ID可以去賬戶表查詢開通的所有賬戶,然后基于開戶請求我們在賬戶中心表中創(chuàng)建對應的賬戶,賬戶中心表中要有主體的用于開戶唯一ID。

同時在賬戶余額表中創(chuàng)建賬戶余額:

同時在賬戶的權(quán)限表中設置賬戶權(quán)限:

賬戶中心經(jīng)過一些列的處理后賬戶就開通了,然后返回給開戶方:

  • 出參
  • 開戶結(jié)果:開通成功

我們從上面的開戶過程可以看出來,賬戶內(nèi)部和主體之間是一個復雜的對應關系。

9. 主體與賬戶的關系

通過8我們知道,主體和賬戶以及賬戶內(nèi)部有復雜的對應關系:主體vs賬戶是一對多的關系,一個主體可以開通多個賬戶,每一個賬戶又會關聯(lián)余額表、權(quán)限表、流水表。

賬戶系統(tǒng)設計從入門到精通

主體的開戶ID去關聯(lián)賬戶的賬戶ID,賬戶ID去關聯(lián)賬戶的余額表中的余額,權(quán)限表中的權(quán)限。

三、第三部分:賬戶結(jié)構(gòu)

1.? 簡單賬戶結(jié)構(gòu)

賬戶結(jié)構(gòu)一個是本身的結(jié)構(gòu)有什么組成,另一個就是賬戶體系內(nèi)賬戶與賬戶之間的構(gòu)成模型,我們主要說后者,我們看幾個最簡單的賬戶結(jié)構(gòu):

只有一類賬戶,比如整個賬戶系統(tǒng)只有一類賬戶:張三-工資賬戶

賬戶系統(tǒng)設計從入門到精通

有多個類型的賬戶,比如下圖,但本質(zhì)上依然很簡單,很容易管理

賬戶系統(tǒng)設計從入門到精通

2. 簡單余額結(jié)構(gòu)

余額結(jié)構(gòu)就是針對賬戶內(nèi)部來說,賬戶的余額如何劃分,就像火鍋,有一個鍋、鴛鴦鍋、九宮格一樣,賬戶作為一個容器,其內(nèi)部依然可以劃分成多個存儲空間。

只有一個余額的余額結(jié)構(gòu),你會發(fā)現(xiàn)微信錢包的余額就只有一個,有多少就是多少,簡單粗暴。

這樣的余額結(jié)構(gòu)必然支持的交易種類就很簡單、收入、支出,無法支撐其他的針對余額的處理。

3. 復雜賬戶結(jié)構(gòu)

隨著業(yè)務的復雜度增加,各類功能性以及運營需求增加,簡單的賬戶結(jié)構(gòu)開始變得復雜,以支撐更復雜的業(yè)務模型,比如紅包可能每個業(yè)務線都要推出一種紅包營銷形態(tài),比如保險業(yè)務線,游戲業(yè)務線。

而紅包又被拆分成了現(xiàn)金紅包,虛擬幣紅包等這樣的話紅包賬戶結(jié)構(gòu)就成了多層級的賬戶結(jié)構(gòu),如下:

賬戶系統(tǒng)設計從入門到精通

看著是不是很像會計科目的結(jié)構(gòu),最下一層是不是很像葉子科目,當然第二層和第三層換一下位置也可以;這種情況下賬戶結(jié)構(gòu)就很復雜了,而且自然存在了總賬戶和明細賬戶之分。

還有一種是賬戶結(jié)構(gòu)分總分機構(gòu),但二級賬戶的種類繁多,功能劃分較細,這類賬戶結(jié)構(gòu)具有支撐復雜的記賬能力,以及業(yè)務處理能力,這類賬戶結(jié)構(gòu)常見在二清監(jiān)管戶體系,比如下面具有眾多子賬戶的賬戶體系,協(xié)同完成資金的監(jiān)管和分賬職能。

賬戶系統(tǒng)設計從入門到精通

一朋友咨詢我人力資源代理平臺的賬戶該如何設計,業(yè)務模型就是平臺幫助很多企業(yè)代收代發(fā)工資,并且支付公積金和社保等多種資金款項,我設計了四個方案,你覺得那個方案好呢?

賬戶系統(tǒng)設計從入門到精通

賬戶系統(tǒng)設計從入門到精通

賬戶系統(tǒng)設計從入門到精通

賬戶系統(tǒng)設計從入門到精通

4. 復雜余額結(jié)構(gòu)

因為資金清算周期或者業(yè)務流轉(zhuǎn)節(jié)點多,或者其他風控要求,需要對賬戶余額進行復雜的處理操作,比如有的能提,有的不能提,最常見的結(jié)構(gòu)就是三個余額屬性:

核算恒等式:總余額=凍結(jié)余額+可用余額,這樣的話,就可以對賬戶余額進行一些處理,比如發(fā)的紅包7天后才能提現(xiàn),那么紅包入賬戶時就會先入凍結(jié)余額,7日后解凍之可用余額。

5.賬戶結(jié)構(gòu)和余額結(jié)構(gòu)的關系

從上面我們可以看到,賬戶可以分多級,余額可以分多塊,那么有什么關系呢?

  • 多級之間:x級總賬戶總余額=sum( x-1 級子賬戶所有賬戶總余額之和 )
  • 某個賬戶:總賬戶余額=凍結(jié)余額+可用余額

上面另個恒等式可以用于校驗賬戶系統(tǒng)記錄的合法性,是不是覺得跟會計系統(tǒng)科目之間的試算平衡很類似。

6.賬戶管理表的設計

通過前面的賬戶主體,賬戶結(jié)構(gòu),賬戶余額結(jié)構(gòu),我們基本可以設計出賬戶表的基本字段了,只要包含這幾部分信息:賬戶主體信息、賬戶結(jié)構(gòu)信息、余額信息、賬戶狀態(tài)信息,我們設計如下,除了核心字段以外,其他想展示的字段可以去相關表中查詢,比如主體姓名,可以用主體ID去主體表中查詢。

賬戶系統(tǒng)設計從入門到精通

7. 余額的變化

我們簡單說一下,后面在將流水和余額更新時會細講;賬務請求賬戶入賬時,基于凍結(jié)規(guī)則我們可以知道該筆入賬是否需要凍結(jié),如果需要凍結(jié)的話就更新凍結(jié)余額,后面再解凍,如果不需要凍結(jié)的話就直接更新可用余額。

賬戶系統(tǒng)設計從入門到精通

作業(yè):思考一下,如果你是螞蟻財富的賬戶產(chǎn)品經(jīng)理,你會如何設計賬戶結(jié)構(gòu)和余額結(jié)構(gòu),來滿足業(yè)務模型呢?歡迎在產(chǎn)品群或者星球提交作業(yè)?。▊渥⑿⌒挠锌优叮?/p>

賬戶系統(tǒng)設計從入門到精通

四、第四部分:費用管理和入賬配置

有了賬戶那么賬戶里就需要存入和存出,充值和提現(xiàn),轉(zhuǎn)賬和消費;這樣賬戶才會流動起來,才有了生命力;那么在交易場景里費用就顯得十分重要了,多少錢,什么費……我們以滴滴司機的結(jié)算賬戶為例來討論本節(jié)內(nèi)容。

1. 交易場景

任何一筆收支都依賴于一個場景,而且這個場景基本涵蓋所有后續(xù)清結(jié)算的信息,比如用戶叫了一輛快車,張師傅接了單子,從立水橋南到奧森公園;這就是一個交易場景,我們可以稱為”快車打車場景“,在這個場景下我們可以知道用戶是誰,在哪打的車,什么車型,起步價多少,每公里多少,司機是誰等。

如果車到了,超過了4分鐘用戶不用車取消了,那么這時候就需要支付一個取消費用,這又是一個場景,我們可以稱為“超時取消場景”,我們將平臺的所有交易場景進行枚舉,如果要新增場景,那么要預先在場景中心申請場景編號,才能開展上線業(yè)務。

2. 費用

在上面的場景中,就會產(chǎn)生交易,因此產(chǎn)生一些列的費用,比如打車單訂單費用,完單后要給司機做結(jié)算就有了訂單結(jié)算費用,平臺要抽取一定服務費就有了“平臺服務費用”,如果高峰期給司機發(fā)一定補貼的話就有了“高峰補貼費”等等。

費用就是站在業(yè)務角度定義資金的業(yè)務屬性,基于業(yè)務側(cè)的費用我們可以關聯(lián)到后續(xù)的財務科目,這樣的話費用是從業(yè)務發(fā)生那一刻就產(chǎn)生并且定義了,而且最后關聯(lián)到會計科目,這樣業(yè)務和財務實現(xiàn)信息一體,對于業(yè)務記賬以及轉(zhuǎn)財務賬提供巨大的遍歷。

賬戶系統(tǒng)設計從入門到精通

3. 計算

這需要一個強大的計算系統(tǒng),我們在支付系列清結(jié)算模塊會做重點介紹,這里點到為止。下單前的預計算,為用戶選擇起點和重點后預先計算可能需要的訂單費用。

賬戶系統(tǒng)設計從入門到精通

進行中的實時計算,這個大家都打過車就不再說了,結(jié)束后的計算,計算出本單實際產(chǎn)生的費用。

賬戶系統(tǒng)設計從入門到精通

我們可以看出訂單總費用包含三部分:起步價+里程費+時長費;你可能會問,一個訂單為什么要拆成這么多費用呢?

我們簡單想一下,這三個費用的特點,而且這三個費用在不同的城市,不同的時段,不同的用戶,不同的車型都會發(fā)生變化,所以我們可以理解為,費用的細化是精細化運營的必然結(jié)果,另外用戶也需要知道為什么收這么多錢。

訂單的清結(jié)算,訂單完結(jié)后就需要給司機做結(jié)算,那么還需要進行一次計算,那就是這一單應該給司機多少錢,平臺抽多少錢,要不要實時扣稅,有沒有其他費用,比如保險費,我們得出如下的清算結(jié)果。

賬戶系統(tǒng)設計從入門到精通

4. 賬戶結(jié)構(gòu)和余額結(jié)構(gòu)

簡單點,每個司機只有一個結(jié)算賬戶,在某支付平臺開通的二類支付賬戶,沒有其他類型的賬戶,接單的收入,補貼獎金全部結(jié)算到該賬戶,司機可以進行提現(xiàn)。

賬戶系統(tǒng)設計從入門到精通

因為為了風控客訴問題,我們?yōu)樗緳C設置一個7天的訂單結(jié)算凍結(jié)期,這樣的話我們的賬戶余額分成了凍結(jié)余額和可用余額,可用余額可以用于提現(xiàn)。

5. 費用管理設計

上面我們講了交易場景和費用的定義,現(xiàn)在我們就來設計費用費用管理,設計費用有三個關鍵點:費用編碼、費用名稱、費用結(jié)構(gòu)。

這里的設計辦法有2種:

一級枚舉型:就是費用之間沒有關系,對所有費用進行枚舉,有規(guī)律設置編碼。

賬戶系統(tǒng)設計從入門到精通

多級結(jié)構(gòu):就是像會計科目一樣,有總科目,明細科目,明細科目可以設置多級。

賬戶系統(tǒng)設計從入門到精通

以上兩種方式可能第二種更好一些,特別是在核算和統(tǒng)計時,可以進行總分分別進行統(tǒng)計分析和核算。

6. 入賬規(guī)則管理

我們設置好了費用,那么在每個節(jié)點都會產(chǎn)生費用,或者計算出相關的費用,比如司機收入,那么清分之后就需要計入相關的賬戶,比如司機收入要計入司機的結(jié)算賬戶。

那么還可能一個費用要計入多個賬戶,比如復試記賬時,又比如司機獎金可能要同時計入平臺的運營賬戶和司機的結(jié)算賬戶。

賬戶系統(tǒng)設計從入門到精通

入賬規(guī)則設計有兩個關鍵點:

一個是匹配條件:要基于入賬請求傳參的條件來匹配到相關的入賬規(guī)則條目,比如我們需要定義每類記賬請求需要什么條件,比如司機收入入賬,一個條件就夠了。

另一個是入賬規(guī)則就是這個條目指定入什么賬戶,比如司機收入匹配到的規(guī)則應該是要入司機結(jié)算賬戶,則入賬規(guī)則是:

  • 賬戶主體:司機
  • 主體ID:司機ID
  • 賬戶類型:結(jié)算賬戶

這樣我們就得到了一條入賬配置規(guī)則:

賬戶系統(tǒng)設計從入門到精通

基于上面的規(guī)則,上游系統(tǒng)在申請入賬時必須傳幾個參數(shù):費用類型,主體類型,主體id;基于司機收入這個費用,我們就匹配出一條規(guī)則,應該入司機的結(jié)算賬戶,利用司機ID找到相關的結(jié)算賬戶ID然后計入賬戶。

賬戶系統(tǒng)設計從入門到精通

五、第五部分:凍結(jié)配置與賬戶流水

當業(yè)務系統(tǒng)請求入賬以后基于費用類型以及入賬規(guī)則我們就可以知道應該入哪個賬戶;這時候問題就來了,因為賬戶余額也是分結(jié)構(gòu)的,有凍結(jié)和可用,那么要是想先凍結(jié)起來怎么辦呢?

我們先回顧一下上一篇的最后一個圖,在凍結(jié)處理里我畫了一個虛線圈,本篇文章我們就把他做實了。

賬戶系統(tǒng)設計從入門到精通

1. 凍結(jié)規(guī)則

我們在賬戶系統(tǒng)設計詳解里講過凍結(jié)模塊,這里我們再細講一下;凍結(jié)就是一個費用請求入賬時要基于業(yè)務要求決定需不需要暫時凍結(jié)起來,還是直接就可以使用;那么如何設計凍結(jié)規(guī)則呢?

凍結(jié)規(guī)則是基于入賬規(guī)則設置的,也就是這筆入賬需不需要凍結(jié),如何凍結(jié),是全部凍結(jié)還是部分凍結(jié),這里我們以全部凍結(jié)為例。

所以一個入賬規(guī)則要關聯(lián)一個凍結(jié)規(guī)則,入賬的時候就需要同時獲取凍結(jié)規(guī)則;入賬規(guī)則和凍結(jié)規(guī)則是一對一的關系,費用類型和入賬規(guī)則是一對多的關系。

賬戶系統(tǒng)設計從入門到精通

凍結(jié)規(guī)則有2部分組成,一個是關聯(lián)的入賬規(guī)則;另一個是凍結(jié)規(guī)則,也就是說在配置入賬規(guī)則的同時就需要關聯(lián)性的去配置一條凍結(jié)規(guī)則。

賬戶系統(tǒng)設計從入門到精通

凍結(jié)規(guī)則的配置有幾個關鍵點:

  • 凍結(jié)模式:就是按照固定時長凍結(jié)還是凍結(jié)到固定時間點;
  • 凍結(jié)時間:如果選擇固定時長的話就填一個時間值,如果是固定時間的話就選擇一個可循環(huán)的時間點函數(shù),比如次月10號,就配置成M+1月10號。

2. 賬戶流水

賬戶有2個核心部分組成,一個是賬戶余額我們已經(jīng)講過了,另一個就是賬戶流水,賬戶流水就是記錄了賬戶的變動歷史明細,我們收窄為“資金的變動明細”。為了記錄資金的變動明細,我們就需要記錄最基本的明細信息,一般必須包含以下信息:

  • 賬務流水號:作為該筆明細的唯一標識
  • 請求ID:請求入賬方的ID,便于后續(xù)的核算
  • 賬戶ID:這筆流水屬于哪個賬戶(會計記賬就是科目編號)
  • 費用類型:這筆流水是什么費用
  • 金額:發(fā)生額
  • 剩余余額:這筆流水發(fā)生后的賬戶余額
  • 收支:支出,收入,這筆流水是增加余額還是減少余額(同會計分錄的借貸)
  • 賬務發(fā)生時間:記賬時間
  • 會計時間:作為業(yè)務口徑和財務口徑轉(zhuǎn)換的時間(非必須)
  • 備注:業(yè)務備注信息
  • 凍結(jié)狀態(tài):凍結(jié)的管理
  • 操作:凍結(jié)/解凍

這樣我們就將業(yè)務的記賬請求通過入賬規(guī)則處理,凍結(jié)規(guī)則處理,進入到賬戶系統(tǒng)并且生成賬戶流水了

賬戶系統(tǒng)設計從入門到精通

3.更新賬戶余額

這里有一個賬務處理任務流,每筆入賬都需要從頭執(zhí)行到尾,不能遺漏,任何一個處理失敗了這筆入賬就宣布失敗進行入賬的失敗處理,我們先設定一個最簡單的任務流:

  • 檢查賬戶流水合法性通過
  • 賬戶流水表插入賬戶流水 完成
  • 基于賬戶流水信息更新余額表對應賬戶的凍結(jié)余額或者可用余額完成
  • 賬戶ID:
  • 總余額=總余額+本次發(fā)生額 凍結(jié)余額=凍結(jié)余額+本次發(fā)生額(凍結(jié)時)
  • 可用余額=可用余額+本次發(fā)生額(不凍結(jié)時)
  • 自洽校驗:總余額=凍結(jié)余額+可用余額 通過
  • 入賬成功

經(jīng)過一些列的處理,入賬成功了,通知請求方,本次入賬結(jié)束。

4. 余額解凍

因為入賬的時候有的流水處于凍結(jié)狀態(tài),那么我們就需要按照凍結(jié)的規(guī)則進行解凍,這時候就需要一個凍結(jié)解凍處理的任務進行掃描執(zhí)行。

至于掃描的模式要基于凍結(jié)模式去設計,我們以凍結(jié)固定時長最小單位為天為例,那么任務就需要每日凌晨去掃描遍歷所有處于凍結(jié)狀態(tài)的賬戶流水,滿足解凍條件的變更凍結(jié)狀態(tài)為未凍結(jié),然后對余額進行處理;這又是一個處理的任務流。

賬戶系統(tǒng)設計從入門到精通

  • 任務掃描遍歷凍結(jié)狀態(tài)的賬戶流水
  • 滿足條件的賬戶流水變更凍結(jié)狀態(tài)為未凍結(jié)狀態(tài)
  • 扣減賬戶的凍結(jié)余額并同時增加賬戶的可用余額
  • 解凍完成

六、第六部分:后臺設計

1. 賬戶列表

賬戶系統(tǒng)設計從入門到精通

2. 賬戶信息管理

賬戶系統(tǒng)設計從入門到精通

3. 賬戶流水管理

賬戶系統(tǒng)設計從入門到精通

 

作者:陳曉光,一個會彈吉他會算命的產(chǎn)品經(jīng)理老司機,微信公眾號:陳天宇宙

本文由 @陳天宇宙 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. tql

    來自上海 回復
  2. 太棒了,看完了

    來自上海 回復
  3. 怎么加入知識星球呀,求求求

    來自福建 回復
  4. 講的很透徹

    來自浙江 回復
  5. 一個字,絕!

    來自廣東 回復
  6. 大佬,求原型

    來自北京 回復
  7. 雖然是技術(shù)的,但是 面對如此優(yōu)秀的大神,也要虛心學習產(chǎn)品。

    來自浙江 回復
  8. 好文先收藏

    來自上海 回復
  9. 學習了

    回復
  10. 非常全面的文章,感謝分享

    回復
  11. 很全很詳細 ,也很容易理解。三大主體:賬戶、流水、交易;兩大配置:入賬規(guī)則和凍結(jié)規(guī)則;兩大業(yè)務:入賬、解凍。

    來自廣西 回復
  12. 來自山東 回復
  13. 這么厲害的文章,居然每人評論,占個沙發(fā),大佬厲害的

    來自上海 回復
专题
12415人已学习14篇文章
大多数产品经理都会经历职场晋升和转正述职的时刻,这个时候,你该怎么做准备?本专题的文章分享了述职报告撰写指南。
专题
72193人已学习13篇文章
产品经理天天跟“需求”打交道,产品经理的核心价值就是处理“需求”的能力。
专题
38804人已学习11篇文章
世间万物皆有套路,面试更是如此,多拿几个靠谱offer。
专题
13231人已学习13篇文章
本专题的文章分享了搜索策略产品经理必读系列。
专题
17604人已学习12篇文章
本专题的文章分享了竞品分析的案例。