1. 程式人生 > >全面解構支付系統設計——你不可不知的會計核心

全面解構支付系統設計——你不可不知的會計核心

一、複式記賬

第一個問題:如何理解賬務系統單邊記賬,會計系統複式記賬?

有些公司內部賬戶之間轉賬都採用複式記賬法,如充值、提現交易,他們在賬務系統都記單邊流水,等和銀行對賬後,在會計系統複式記賬。

1. 以充值為例

使用者充值:秋秋支付寶充值100 元,那麼在賬務系統裡面單邊記賬,主要就是如下的流水資訊:

若有N 多條充值的流水,在賬務系統中會記錄客戶分戶N 多條賬務流水,並實時更新外部分戶的流水和分戶餘額。

同時傳送該充值業務資料到會計核心,會計核心根據賬務系統提供的會計科目做一條客戶帳分戶的貸方分錄,日終彙總分別借記一條工商銀行待清算款充值賬戶的分錄,同時更新相應科目下的內部分戶餘額,在會計系統中會對應的生成會計分錄流水:

銀行對賬後 ,對賬結果觸發會計系統會計分錄:

二、會計基礎入門

第二個問題:如何理解會計中的“借”和“貸”?

首先明確一個公式:資產= 負債+ 所有者權益

規律:

  • 當秋秋收到現金時,都是借:我的現金 貸:其他科目;說明我的現金時借方表示增加。

  • 當秋秋借別人錢時,負債增加了,借:其他科目 貸:我的負債(屬於別人的錢),說明我的負債是貸方表示增加。

  • 當秋秋辛苦攢下的積蓄,所有者權益增加了,借:其他科目 貸:屬於我的財產,說明屬於我的財產是貸方表示增加。

三、會計科目和賬戶

1. 會計科目

  • 會計科目按其反映經濟內容的不同一般分為資產類、負債類、所有者權益類、收入類、費用類、利潤類六大類科目。由於支付機構主要核算客戶資金和備付金資金賬戶,沒有直接採用所有者權益類、收入類、費用類和利潤類科目,僅僅設定資產類、負債類、共同類(待清算),嚴格遵循會計恆等式。

  • 資產類科目餘額方向一般在借方,負債類科目的餘額一般在貸方,共同類既具有資產也具有負責屬性,屬於雙重科目。

2. 科目層級

為了既能夠提供總額核算,又能提供明細核算,會計科目一般更具具體需求設定層級。

按照提供指標的詳細程度不同,可以分為總分類科目、明細類科目。總分類科目就是我們說的總賬科目或者叫一級科目,是總體反映會計要素具體內容的科目。

明細分類科目,也就是明細科目,是對總分科目所含內容做詳細分類形成的會計科目。

明細科目根據會計核算和經營管理需要還可設定二級、三級科目。沒有下級科目的會計科目為葉子科目,即底層科目,底層科目下按照實際賬務處理設定會計賬戶,會計賬戶與資金賬戶一一對應。只有葉子科目下才能開立賬戶,非葉子科目下不可以開立賬戶。

3. 科目和賬戶的關係

  • 資產類科目記在借方表示增加,記在貸方表示減少;

  • 負債類科目記在借方表示減少,記在借方表示增加;

  • 所有者權益記在借方表示減少,記在貸方表示減少;

  • 費用類科目記在借方表示增加,記在貸方表示減少;

  • 利潤類科目記在借方表示增加,記在貸方表示增加。

4. 交易流程與資金平衡

5. 內部戶和科目的關係

6. 會計科目平衡關係

  • 在一級科目110銀行存款下,針對不同銀行可以設定多個二級科目:11001 A銀行存款科目,11002  B銀行存款科目;

  • 在每一個銀行存款二級科目下,根據收付業務目的的不同,又可以設定多個三級科目:1100101 A銀行存款_收款專用科目,1100102 A銀行存款_付款專用科目,1100103 A銀行存款_歸集專用科目。

7. 每個類目的科目平衡關係

  • 葉子科目餘額= 該科目下所有賬戶餘額綜合;如:1100201 科目餘額= 1100201科目下所有賬戶的餘額總和。

  • 科目彙總餘額= 該科目下所有葉子科目餘額總和;如:110 一級科目餘額= 110 一級科目下所有葉子科目的餘額總和。

  • 總賬餘額= 該科目下所有同級科目彙總餘額總和;如:資產類總賬= 資產類所有科目的餘額總和。

201 和 202 科目屬於客戶賬科目,其餘科目均屬於內部賬科目,即 201 和 202 科目下的賬戶屬於客戶賬,其餘科目下的賬戶屬於內部賬。

四、會計資金平衡關係

採用複式記賬法,保證會計核算資金的平衡關係,複式記賬法是指對發生的每一項經濟業務,都以相等的金額,在相互聯絡的兩個或者兩個以上賬戶中間同時進行登記的方法。

公式①:資產 (借方餘額)= 負債(貸方餘額)+ 待清算(借方餘額)

公式②:原始平衡關係:資產 (0)= 負債(0)+ 待清算(0)

支付機構的資金管理體系是在銀行資金管理體系基礎上建立了,為了能清晰的理清資金的流入與流出關係,保證收支兩條線;支付機構一般會在每家合作銀行分別開設收款專使用者和付款專使用者。

其中收款專戶是專門用來歸集充值流入的資金,付款專戶專門用來歸集提現流出的資金。

1. 充值業務資金流動機制

當充值業務發生時,銀行直接從客戶的銀行賬戶進行扣款,但是並不會立即向支付機構的銀行賬戶入賬,而是先掛入銀行內部過渡賬戶,在日終處理時統一講當日累計充值資金一次性向支付機構收款專業銀行賬戶入賬。

2. 提現業務資金流動機制

當提現業務發生時,支付機構並不是立即通知銀行扣款,而是在每日定時將一段時間內同一家銀行申請提現的請求彙總提交給銀行,由銀行負責從支付機構付款專用銀行賬戶進行扣款,向客戶的銀行賬戶入賬。

3. 資金排程機制

為了保證每家銀行的收款專戶資金得到統一的排程支配,同時滿足每家銀行付款專戶的資金需求,支付機構會指定唯一的一家合作銀行開設統一歸集賬戶,每日將各家銀行收款專戶內充值業務資金彙總歸集到這個唯一的歸集賬戶內,並根據各家銀行付款專戶提現業務需要支付的資金,從歸集賬戶向各家銀行付款專戶劃轉調撥資金,確保提現支付成功。

支付機構在銀行的資金管理體系的基礎上,從自身的資金管理需求出發,搭建了自己的資金排程體系,其資金流基本和銀行類似,典型的資金體系如下:

由於支付機構內部待清算充值款項是當晚核心系統日終後才能結轉到銀存收款賬戶後,才能進行調撥,而每日下午在產生給銀行的提現資料時,就需要保證銀存付款專戶上的資金到位,這樣資金調撥就會存在時間差,為了解決這個時間差問題,於是內部設定了一個調撥戶進行資金中轉。

調撥專戶是一個虛擬的賬戶,不是與真實資金賬戶對應的賬戶,餘額方向可以是借方或貸方。每日在向銀行提交提現資料前,先內部從銀行收款賬戶進行調撥,如果由於時間差原因收款賬戶資金餘額不足,則直接從調撥專戶上調撥資金到收款賬戶,再從收款賬戶向付款賬戶調撥。

資金調撥專戶上的缺口部分需要在日終結轉時予以軋差抹平,即現將待清算充值資金結轉到調撥戶,再從調撥戶結轉到銀行存款收款賬戶。

五、會計驅動的入賬機制

賬務系統作為會計系統的前置,一般的業務請求都是由賬務系統先完成記賬再向會計系統傳送請求進行會計記賬。

但是有兩項特殊業務是會計系統獨立處理,並是由會計系統向賬務系統發起請求進行最終賬務記賬處理的,這就是涉及銀行資金結算的充值、提現業務的待清算賬戶單邊歸總記賬和日終的會計結轉記賬。

1. 充值業務在會計系統中單邊彙總的流程

2. 提現業務在會計系統中單邊彙總的流程

六、會計日終處理

1. 日終前的賬務準備階段

向對賬中心通知會計日終處理開始。

針對充值業務和提現業務員的日間單邊記賬進行彙總,完成待清算款項的彙總單邊記賬。

通知對賬中心日終對賬,並獲取對賬中心返回的銀行對賬結果資料。

根據各家銀行充值業務的對賬結果資料,彙總結轉各銀行待清算充值資金到各銀行存款賬戶(若有資金調撥,則結轉到資金調撥賬戶)。

對於有資金調撥的銀行,根據充值業務的對賬結果資料,彙總結轉各家銀行資金調撥資金到各銀行存款賬戶。

根據提現業務的對賬結果資料,彙總結轉各銀行待清算提現資金到各銀行存款賬戶。

因為資金調撥專戶需要在日終時歸零,所以對於差額部分需要軋差記賬,即結轉各家銀行資金調撥餘額到各家銀行存款賬戶。

2. 日終的軋差與彙總處理階段

檢查所有賬戶當日會計發生額是是否借貸相等,即借方發生額=貸方發生額,若不相等,則自動登記軋差金額的會計分錄,保證借貸發生額平衡,對於導致借貸發生額不平的原因事後查詢解決。

對賬戶的會計分錄按借貸進行彙總,同時根據各賬戶上日餘額和當日的發生額計算得到每個賬戶當日餘額。

按照科目對科目賬戶的會計分錄進行彙總得到科目當日發生額,同時根據各科目上日餘額和當日的發生額計算得到當日科目餘額。

3. 日終的平衡檢查和日切階段

  1. 平衡檢查主要保證借方科目餘額等於貸方科目餘額;

  2. 科目總分檢查保證下級科目餘額總和等於對應的上級科目餘額;

  3. 會計日餘額表日切主要保證每日的賬戶餘額資料得到儲存;

  4. 更新會計日,保證下次日終處理的是下一個會計日。

七、會計結算業務引數的配置與管理

會計系統作為核心重點負責清算、結算會計平衡的系統,在每增加一家銀行時,都需要配置相關的會計結算關係。

會計系統的日間記帳處理包含兩種模式:即時模式和緩衝模式,具體採用何種模式由賬務系統觸發時決定。

即時模式需要會計系統嚴格按照賬務系統傳送的指令進行會計記帳處理;

緩衝模式需要會計系統根據相關的引數配置進行會計記帳處理,一般日間都是單邊的會計記賬處理,如充值與提現業務。

日間會計系統根據引數配置僅記錄客戶帳的變化部分,不記錄內部賬的變化部分,內部賬的變化部分在日終時根據相關引數和日間的單邊賬務記錄,進行分類彙總後再分別記帳處理。

1. 會計業務相關引數包括以下部分內容

針對日間所有的充值類交易程式碼(含充值 4003、充值補賬 4023 )、提現類交易程式碼(含提現 5004 、提現補賬 4022 、充退 4104 )操作,其下每一個子交易碼 sub_trans_code 對應的每一個涉及該業務的 title_code 科目程式碼都需要配置一條對應的引數記錄,來確定日間該科目下的該交易程式碼進行怎樣的單邊會計記帳處理。

引數重點說明該科目該交易記帳的方向、是否需要彙總記帳、是否需要傳送對帳中心處理、是否需要 cache ;如 400301 交易程式碼,業務涉及 20100 1個人賬戶科目和 2002001 公司賬戶科目,則需要對應的兩條引數記錄;具體配置如下:

日終批量處理時,有一步是專門針對緩衝記賬的處理,會計系統會根據引數表中充值、提現相關的每一個子交易碼 sub_trans_code 對應的銀行程式碼 bank_type 不同,分類統計日間的單邊會計記賬資料,按照彙總後的資料會計系統單邊記賬處理;完成緩衝記賬的剩餘部分。

如 400301 交易程式碼,日終時按照引數表中的銀行程式碼分別統計日間 400301 交易的單邊會計記錄,產生另一邊的待清算戶的會計記帳記錄。

日終批量處理時,有一步是專門針對銀行存款結轉的,即將經過對帳的資金從待清算賬戶結轉到銀行存款賬戶,以保持與銀行真實資金變化的一致。

會計系統會根據與銀行的對賬結果資料進行結轉記賬處理,引數表中記錄了每家銀行從待清算戶到銀行存款戶進行結轉的具體記賬引數中充值;因為存在兩種結算方式,所以存在兩套記賬引數:

  1. 從待結算資金戶結轉到銀行存款戶的會計記帳引數;

  2. 從待結算資金戶結轉到資金調撥戶的會計記帳引數;

  3. 從資金調撥戶結轉到銀行存款戶的會計記帳引數。

當前的業務規則表包括欄位如下:

會計業務規則在整個會計核心中起著非常重要的作用。會計核心的幾個重要功能(記錄分錄,傳送對賬中心資料,彙總記賬,日切結轉)中,都有他的用處。目前來講,會計規則主要有三個地方應用:

  1. 日間生成分錄:這部分規則叫做會計分錄規則。

  2. 日切彙總記賬:這部分規則叫做會計彙總規則。

  3. 日切資金結轉:這部分規則叫做會計結轉規則。

會計彙總規則和會計結轉規則同屬於會計流轉規則。

2. 日間生成分錄

在日間過程中,會計核心主要負責把賬務請求轉化成分錄要素並記錄下來,同時根據需要傳送給對賬中心。在這過程中, 會計分錄規則起如下作用(左邊是賬務請求已知資訊,右邊是通過會計分錄規則得到的資訊):

通過會計分錄規則的轉化,就可以知道是否要進行彙總記賬,從而決定是記單邊分錄還是也要記錄待清算方科目的分錄。可以知道會計要素中的銀行是從賬務請求的哪個欄位取。

也可以知道是否要傳送給對賬中心,有了規則得到的這些資訊,再加上能從賬務請求直接拿來的會計要素(如:賬戶,科目,金額,會計日,借貸方向),就可以生成分錄,併發送給對賬中心。

從能夠目前的會計業務規則表中的資料來看,這部分規則的使用如下:其中藍色部分作為請求部分,×××部分作為會計業務規則的產出部分。

3. 日切彙總記賬

在日切過程中,需要把充值、提現等業務的多方分錄進行彙總,得到一方分錄,並記錄下來。會計彙總規則在由多方分錄轉化成一方分錄時,起如下用途:

通過會計彙總規則的轉化,得到一方分錄的賬戶,科目和借貸方向要素,再加上其他一些會計要素(SubTransCode,會計日等),就可以生成一方分錄了。

從目前的會計業務規則表中的資料來看,這部分規則的使用如下:

其中藍色部分作為請求部分,×××部分作為會計業務規則的產出部分。

4. 日切資金結轉

在日切結轉過程中,需要把已清算款或調撥戶結轉成銀行存款。這些結轉所使用規則叫做會計結轉規則。日切資金結轉有兩種情況:

(1)待清算結轉

對賬中心對賬完畢之後,在日切過程中,需要把待清算資料結轉成銀存或調撥戶,所以需要建立一套會計結轉業務規則,來約束如何從待清算結轉到銀行或調撥戶。

在結轉過程中,他是依賴會計結轉規則的如下引數來查詢規則:

根據已清算彙總資料( pac_gather_daily )得到的SubTransCode,TitleCode,Remark(=SubTransCode ),從會計結轉規則中得到兩條規則,一條是存放待清算方分錄規則,一條是存銀存方(或調撥方)分錄規則。我們根據這兩條規則,然後在根據其他分錄要素( SubTransCode , 會計日等),就可以生成兩條分錄。

同時要說明得是:這種情況的結轉規則,都是成套的。

成套的含義是指用相同的 SubTransCode,BankType,Remark 取查詢會計規則,如果能找得到,就是兩條,這兩條是成套的。

就目前的會計業務規則表中的資料來看,他的用途如下:(其中藍色部分作為請求部分,×××部分作為會計業務規則的產出部分。綠色部分是給調撥結轉用的)

(2)調撥結轉

相關推薦

全面支付系統設計——不可不知會計核心

一、複式記賬 第一個問題:如何理解賬務系統單邊記賬,會計系統複式記賬? 有些公司內部賬戶之間轉賬都採用複式記賬法,如充值、提現交易,他們在賬務系統都記單邊流水,等和銀行對賬後,在會計系統複式記賬。 1. 以充值為例 使用者充值:秋秋支付寶充值100 元,那麼在賬務系統裡面單邊記賬,主要就是如下的流

賦值,不能不懂!

es6語法解構賦值 很多人可能和我一樣,第一次看到這個詞的時候摸不著頭腦。但是冷靜再看一遍好像明白了,“把數據結構分解開分別進行賦值”。 我們先看幾個小例子 let [a,b,c] = [1,2,3];console.log(a,b,c);//1 2 3 let {name,age} = {name:&qu

聚合支付系統設計(二)

支付閘道器與非同步通知設計 支付閘道器 使用者下單成功後,要經過收銀臺發起支付流程,支付閘道器就是使用者發起支付流程的入口地址。支付閘道器需要接收訂單的部分資料(訂單號、待支付金額、商品描述資訊等)和交易資料(支付方式、交易起止時間、回撥地址等)以及簽名,支付閘道器接收到收銀臺的支付請求後,驗證

聚合支付系統設計(一)

商戶聚合支付系統設計(一) 產品概述與整體設計 背景 如今,網購已經滲透到人們日常生活中的方方面面,做為網購的載體,網際網路電商平臺發展如火如荼,支付功能做為其不可或缺的一部分,實現起來,也有各種各樣的方案。根據自己有限的認知,我主觀上把目前行業內的支付實現方案做以下歸

一個簡單的支付系統設計

1.設計思路 每個公司都有自己的支付系統,有很複雜的像支付寶這種,也有超級簡單的就是一個接入第三方支付。這裡我想設計一個簡易的完整的支付系統,我應為應當包括,支付閘道器,支付渠道,基本支付,以及風險監控。 1.1支付閘道器 支付閘道器是對外提供服務的介面,所有需要渠道支

支付系統設計:銀行卡支付(三)

這一期,回到支付系統的核心業務,即支付。每個電商公司的支付系統都已經或多或少的實現了交易核心功能,可也都是一直在改進,總是不斷的有新的需求冒出來。所以這一期開始,我們梳理一下:到底有哪些支付方式?每種支付方式都是怎麼運作的? 支付和交易 說到支付就不得不提交易。這

不可不知的Java引用型別之ReferenceQueue原始碼詳

定義 引用佇列是用於儲存要回收的引用物件的引用佇列。 說明 對於軟引用、弱引用和虛擬引用,如果希望在垃圾收集器回收物件以進行其他處理時得到通知,則需要使用引用佇列。 當垃圾收集器掃描要回收的物件時,將對應的引用包裝器類(引用物件)放入其註冊的引用佇列佇列中。可以從佇列中獲得相應的物件

不可不知的Java引用型別之——SoftReference原始碼詳

  定義      SoftReference是軟引用,其引用的物件在記憶體不足的時候會被回收。只有軟引用指向的物件稱為軟可達(softly-reachable)物件。      說明      垃圾回收器會在記憶體不足,經過一次垃圾回收後,記憶體仍舊不足的時候回收掉軟可達物件。在虛擬機器丟擲OOM

現代支付系統設計 ——基於微服務的實踐

一、支付概述 1.1 支付與交易 1.2 中國支付體系 二、支付系統設計 2.3.1 銀行卡支付 2.3.2 快捷支付 2.3.3 網銀支付 2.3.4 應用內支付 2.3.5 賬戶支付 三、賬戶與賬務 3.1 賬戶模型 3.2 基本

電商支付系統設計(一)——可行性分析

1    背景 隨著網際網路的發展,主流OTA不再單純賣自己的機票和酒店,都走向多供應商的開放平臺。商旅系統在XX信用卡中心的戰略指導下,也拓展了火車票、簽證、保險等多項業務,旨在為XX銀行持卡人的出行提供全方位產品供應。 商差旅系統早期的設計是支援多供應商和開放平臺,架構

不可不知的Java引用型別之——WeakReference原始碼詳

定義 WeakReference是弱引用,該引用不會影響垃圾回收器對物件的回收,不會影響物件的生命週期。 說明 當虛擬機器在某個時間點決定要回收一個弱可達(weakly-reachable)物件時,會自動清除該物件的所有弱引用。並且會將物件變為finalizable狀態,然後把這些剛清除的弱引用放到其註

不可不知的Java引用型別之——PhantomReference原始碼詳

定義 PhantomReference是虛引用,該引用不會影響不會影響物件的生命週期,也無法從虛引用中獲取物件例項。 說明 原始碼介紹部分其實也沒多大內容,主要內容都在前面介紹中說完了。PhantomReference類的原始碼和WeakReference類一樣簡單: public class Pha

領域驅動設計(一):為什麼領域驅動設計能夠解決軟體複雜性

1 為什麼我要研究領域驅動設計 1.1 設計方法各樣且程式碼無法反映設計 我大概從2017年10月份開始研究DDD,當時在一家物流資訊化的公司任職架構師,研究DDD的初衷在於為團隊尋找一種軟體設計的方法論。作為架構師,經常參與設計評審,包括:需求評審、設計評審、程式碼評審。在評審過程中,有一點感受非常深,

領域驅動設計(一):為什麽領域驅動設計能夠解決軟件復雜性

unp 問題 困難 技術 工作 質量管理 exce urn 如果 1 為什麽我要研究領域驅動設計 1.1 設計方法各樣且代碼無法反映設計 我大概從2017年10月份開始研究DDD,當時在一家物流信息化的公司任職架構師,研究DDD的初衷在於為團隊尋找一種軟件設計的方法論。

領域驅動設計(二):領域驅動設計核心之分層架構

() shc created win cif nec upd 方法 bool 反映業務規則的代碼是整個軟件的核心,但是它一般只占很小的一部分,在傳統的基於貧血模型的分層軟件架構中,業務規則可能分散到各個層、各個代碼段,從而使得通過代碼來還原業務規則或者保證代碼與業務規則一致

支付系統設計支付系統的賬戶模型(一)

賬戶體系是支付系統的基礎,它的設計直接影響整個系統的特性。這裡探討如何針對電子商務系統的支付賬戶體系設計。我們從一些基本概念開始入手,瞭解怎麼建模。 支付賬戶和登入賬號 賬戶體系設計首先要區分兩個概念,支付賬戶和登入賬號。 這是兩個不同業務領域的概念:支付賬戶指使

關於設計規範,不可不知的三件事

過去幾個月裡,優秀原型工具提供者摹客(Mockplus)團隊於在端午節前,釋出了國內獨家設計系統,致力於定製設計規範。這對於國內的產品設計行業而言,無疑是一種設計和開發領域激動人心的轉變,而摹客,也無疑是走在了前面。 但其實設計規範早已經不是一個全新的概念了。如果你正好有參

領域驅動設計(三):領域驅動設計

ddd 引擎 .get states 成員變量 float 類的屬性 table custom 在上一部分,分層架構的目的是為了將業務規則剝離出來在單獨的領域層中進行實現。再回顧一下領域驅動設計的分層中應用層代碼的實現。 @Override public void

強烈推薦|不可不知的性能優化內幕

idl 奇怪 負數 反向 art 頁面加載 加載 全部 src 一. 基本概念 軟件系統質量特性 安全性:同時兼顧向合法用戶提供服務,以及阻止非授權使用軟件及資源的能力。 健壯、可靠:軟件系統在一定的時間內無故障運行的能力、容錯能力、恢復能力 可擴展、可維護、可移植:

書摘—不可不知的心理策略

作者:陳國榮 前 言 正如法國文學家羅曼·羅蘭所說:“人類的一切生活,其實都是心理生活。” 偉大的心理學家榮格曾說過:“心靈的探討必將成為一門十分重要的學問,因為人類最大的敵人不是災荒、飢餓、貧苦和戰爭,而是我們的心靈自身。” 著名行為心理學派大師阿爾伯特·班圖拉曾說:“心理學不能告訴人們應當怎樣