什么是對賬？

 

傳統(tǒng)的對賬又稱為核對賬目，是指在會計核算中，為保證賬簿記錄正確可靠，對賬簿中的有關(guān)數(shù)據(jù)進行檢查和核對的工作。在銀行或者第三方支付中，對賬指對前一個清算周期內(nèi)的交易信息進行核對，以確保交易信息的一致性和正確性，一般都是第二天在銀行或者第三方支付公司對前一日交易進行清分，生成對賬單供商戶方進行下載，并將應(yīng)結(jié)算款結(jié)算給對應(yīng)商戶系統(tǒng)。
 

對賬系統(tǒng)

對賬系統(tǒng)，是支付體系中最重要的一環(huán)，也是保證交易、資金安全的最后一道防線。通過系統(tǒng)的使用，不僅可以提升對賬效率和解放人工對賬工作量，而且還可以快速擴展其他支付類渠道，它的職責(zé)就是替代傳統(tǒng)的人工對賬，解放人工對賬的工作量，提升對賬效率，實現(xiàn)系統(tǒng)自動化。

以筆者多年前參與的項目為例，對接了多個銀行渠道系統(tǒng)進行代收代付業(yè)務(wù)，在實際應(yīng)用場景中，生產(chǎn)交易系統(tǒng)總會存在因掉單或者系統(tǒng)突發(fā)異常導(dǎo)致的同一筆交易在支付系統(tǒng)與銀行系統(tǒng)的信息不對稱，使得支付系統(tǒng)在銀行的賬戶資金實際發(fā)生額與應(yīng)該發(fā)生額不一致，比如長款（銀行多結(jié)算給支付系統(tǒng)）和短款（銀行少結(jié)算給支付系統(tǒng)）。
 

而隨著業(yè)務(wù)的體量不斷增加、定制化與個性化的業(yè)務(wù)場景不斷細化，接入更多的支付渠道已成為未來可預(yù)見的必然趨勢。在這樣的前提下，人工進行賬目核對已經(jīng)很難達到財務(wù)部門所提出的要求，如何依據(jù)軟件工程設(shè)計理論和結(jié)合系統(tǒng)架構(gòu)現(xiàn)狀，設(shè)計一款滿足對賬功能、安全可靠和易于維護的高質(zhì)量的對賬系統(tǒng)，顯得尤為重要。
 

如何高效對賬

通過對既有系統(tǒng)以及其他渠道系統(tǒng)進行研究發(fā)現(xiàn)，對賬的通用流程大致分為如下步驟：  渠道對賬單下載、對賬單文件解析、對賬(軋賬/平賬)。  對賬系統(tǒng)是一個以定時任務(wù)為主的系統(tǒng)，我們在系統(tǒng)架構(gòu)方面基于分布式任務(wù)框架elastic-job與自定義任務(wù)邏輯相結(jié)合的方式進行設(shè)計，其中elastic-job作為無中心化的分布式定時調(diào)度框架，其優(yōu)勢就是保證后續(xù)任務(wù)可以在任意節(jié)點中執(zhí)行。業(yè)務(wù)邏輯架構(gòu)如圖1所示:
 

   

圖1:對賬系統(tǒng)架構(gòu)
 

各個功能模塊功能：
 

1、對賬單下載

 

對賬單下載組件根據(jù)各個支付渠道不同的對賬周期定時觸發(fā)，通過支付渠道提供的方法獲取相應(yīng)的對賬文件。目前主流的獲取方式大致分為  HTTP(S)  和 FTP  兩種下載方式。

 從技術(shù)實現(xiàn)的角度來說，我們可以將其設(shè)計為工廠模式，針對不同的支付渠道對應(yīng)不同的下載類，如果是http接口可以將獲取到的文件寫入到對賬單中，用于后續(xù)解析操作，如果是對方提供的是ftp服務(wù)器，則需要將服務(wù)器中的對賬單下載至本機。  在這個環(huán)節(jié)中，為了防止單一應(yīng)用宕機導(dǎo)致系統(tǒng)產(chǎn)生異常，對賬單下載至本地后會同步將其上傳至DFS服務(wù)器中，方便后續(xù)步驟中的定時任務(wù)可以從DFS服務(wù)器中獲取到對應(yīng)的對賬單文件。  這個環(huán)節(jié)的主要編碼工作包括通用ftp工具類、http(s)工具類的編寫，并會涉及到IO讀寫相關(guān)的實現(xiàn)。

 在下載對賬單的步驟中，很多同仁都踩過不少坑,也針對共性問題進行了總結(jié)，那就是“HTTP(S)用apache httpclient即可實現(xiàn)鏈接池和斷點續(xù)傳功能,亦可使用Apache Commons Net API實現(xiàn)FTP的上傳與下載。但不管是哪一種方式，都需要謹慎的設(shè)置重試次數(shù)、重試間隔以及鏈接超時時間,其原因是重試太頻繁容易導(dǎo)致服務(wù)器夯死；時間間隔太大又會阻塞后續(xù)處理步驟，評估下來5～10分鐘是一個較為合理的重試間隔區(qū)間。”
 

當然，在實際應(yīng)用種如何選擇這個重試的區(qū)間，可能需要我們在開發(fā)時結(jié)合自身系統(tǒng)的特點制訂出符合自身要求時間范圍。
 

2、對賬單轉(zhuǎn)換

對于不同的支付渠道，其對賬單的文件格式也略有不同，包含XML、Excel、Text、csv等不同形式。

如果完全按照下游渠道系統(tǒng)提供的原始賬單格式進行對賬單存儲，那么對于后續(xù)的賬單數(shù)據(jù)處理邏輯就會隨著下游渠道的增加而不斷的擴展，并且每增加一個新的支付渠道，賬單存儲表都需要根據(jù)渠道賬單結(jié)構(gòu)新建，使得開發(fā)工作量大幅增加。因此，從對賬模塊來看，為了讓后續(xù)的對賬操作變得統(tǒng)一，需要格式化不同形式的對賬文件，并對其進行標準化處理顯得尤為重要。

 由于支付渠道系統(tǒng)在設(shè)計上存在差異性，我們需要為每個渠道開發(fā)一套對應(yīng)的解析規(guī)則，可能包含計量單位的轉(zhuǎn)換、交易日期的格式化、交易結(jié)果的映射轉(zhuǎn)換等操作，對賬單轉(zhuǎn)換模塊的職責(zé)就是將各式各樣的數(shù)據(jù)源解析為標準格式后插入交易記錄表中，用于后續(xù)對賬工作。
 

在導(dǎo)入數(shù)據(jù)的過程中，我們選擇使用批量導(dǎo)入操作，  一方面可以避免重復(fù)記錄導(dǎo)致的臟數(shù)據(jù)，另一方面也可避免逐行入庫操作過程中因每次重新建立網(wǎng)絡(luò)連接、關(guān)閉連接造成的效率低下。  

 

3、對賬模塊

在對賬模塊中，通常以系統(tǒng)調(diào)用方產(chǎn)生的交易訂單號作為關(guān)聯(lián)條件，使用事先定義好的比對規(guī)則核對對賬文件中的記錄與本地流水信息，得到一個交集與兩個并集。這兩個并集中的數(shù)據(jù)即為對賬過程中產(chǎn)生直接的差異數(shù)據(jù)，而交集部分的數(shù)據(jù)集說明根據(jù)訂單號是可以獲取到對應(yīng)記錄，當然，我們還需要對其金額以及支付結(jié)果等信息進行比對。
 
 在對賬的過程中可能出現(xiàn)某些系統(tǒng)無法匹配的異常數(shù)據(jù)，為了便于分析，我們需要將三個集合中出現(xiàn)的長款、短款、金額不一致等問題記錄在差異表中，并同時登記產(chǎn)生差錯的類型。  對于某些類型的差異數(shù)據(jù)，對賬系統(tǒng)在后續(xù)的跑批中能夠自動化處理，一致化交易數(shù)據(jù)。  而對于那些系統(tǒng)無法處理的異常，則需要人工干預(yù)排查問題原因，并尋找合理的解決方式。  此外，由于各個支付系統(tǒng)的日切時間會存在細微的差異，對于可能在當日的賬單數(shù)據(jù)中沒有匹配到待對賬的數(shù)據(jù)需要我們進行滾動對賬。
 

圖2:交易流水表與對賬單表邏輯關(guān)系
   

4、差錯處理

 

差錯處理的目的就是分類記錄對賬過程中出現(xiàn)的異常數(shù)據(jù)，并通過系統(tǒng)自動處理或者人工干預(yù)的方式將賬務(wù)對平，常見的賬務(wù)處理方式有  掛賬、登賬、調(diào)賬  。
 

補單：  通過人為干預(yù)方式，將原有業(yè)務(wù)進行下去，如通過接口人工干預(yù)訂單狀態(tài)  

 

掛賬：  對于不平賬單，先掛起，等查明后再進行相應(yīng)處理  

 

登賬：  會計記賬，伴隨虛擬資金從一個賬戶向另一個賬戶轉(zhuǎn)移的過程(原始憑證)
 

 

針對可能出現(xiàn)的情況分類，處理方式分為如下幾類：
 

(1) 本地交易流水中支付狀態(tài)為未支付，但是支付渠道對賬單中顯示記錄為已支付。  這可能是由于本地未正確接收到支付渠道異步通知的消息所導(dǎo)致。 針對這種情況，我們通過補償機制同步交易未決的流水信息來盡量避免這種情況的出現(xiàn)，但是特殊情況下，亦可通過數(shù)據(jù)維護的方式將本地支付狀態(tài)修改與渠道側(cè)一致，并響應(yīng)后續(xù)的流程處理等。
 

 

(2) 本地交易流水與支付渠道支付狀態(tài)一致均為已支付，但是金額不同。這個情況一般以支付渠道的金額為準，需要人工核查自有系統(tǒng)的代碼是否存在缺陷，導(dǎo)致交易過程中金額計算出現(xiàn)了誤差，出現(xiàn)記錄失真的情況。   
 

 

(3) 本地流水中已支付，但是支付渠道中無記錄。  在排查這類問題的時候首先要判斷是否因為交易跨天所導(dǎo)致的，因為交易系統(tǒng)與第三方支付渠道的過程中恰好跨天，這樣就會導(dǎo)致前一天的數(shù)據(jù)出現(xiàn)一筆短款記錄，而后一天又會出現(xiàn)一筆長款記錄,這個時候就需要進行補對賬操作，來補償那些由于某些原因未對賬的數(shù)據(jù)，具體流程如圖3所示。  

 

 

圖  3:  滾動補對賬流程
 

總體來說，我們發(fā)現(xiàn)不同渠道的對賬工作會存在細微的差異，但是具體的步驟卻又具有共性。細節(jié)往往決定事情的成敗，簡單的業(yè)務(wù)反而需要更加細心去處理可能存在的異常情況。比如，下載過程中斷線后如何操作，重試次數(shù)如何設(shè)置以及超時時間的設(shè)定都需要結(jié)合實際業(yè)務(wù)，并深入熟悉其背景后選擇最優(yōu)解決方案。

另外，從技術(shù)角度發(fā)現(xiàn)對賬過程中逐行比對算法效率較低，但目前仍未找到更為合理的算法進行替代，如采用數(shù)據(jù)庫INTERSECT、MINUS的方式進行比對則將壓力轉(zhuǎn)嫁到了對數(shù)據(jù)庫側(cè)。當業(yè)務(wù)呈井噴式增長時，大量的交易數(shù)據(jù)需要進行對賬操作，也會導(dǎo)致數(shù)據(jù)庫負荷較高，通過讀寫分離以及避開交易高峰等空間換時間的操作雖然可降低生產(chǎn)系統(tǒng)的風(fēng)險，但仍沒有從根本上徹底解決問題。后續(xù)優(yōu)化重構(gòu)的過程中也會嘗試使用Redis等NOSQL數(shù)據(jù)庫進行對賬操作，如使用Redis的set集合的sdiff功能，返回兩個集合之間的差異集合，比對解析后的對賬單記錄和本地自有記錄的差異，降低對生產(chǎn)交易中的mysql數(shù)據(jù)庫的壓力，并且Redis數(shù)據(jù)庫在擴展上也相對容易。

當然，這個方案是否是最優(yōu)解仍需要驗證后才可知，如何在特定的情況制定出一套最佳方案仍需要我們在漫漫長路上不斷探索與研究。

本文作者：興業(yè)數(shù)金供應(yīng)鏈金融事業(yè)部技術(shù)團隊 張佳鵬
 

特別聲明：

文章來源：興業(yè)數(shù)金公眾號（ID：gh_b700b775ae81）

原文鏈接：https://mp.weixin.qq.com/s/2tiHlWT_6iXmIRpxnlwCww

如有侵權(quán)，請聯(lián)系刪除

 

 

繼續(xù)閱讀：對賬   對賬系統(tǒng)   流程自動化   RPA

未經(jīng)允許不得轉(zhuǎn)載：RPA中國 | RPA全球生態(tài) | 數(shù)字化勞動力 | RPA新聞 | 推動中國RPA生態(tài)發(fā)展 | 流 > 對賬那些事兒