咱們聊聊對賬系統該如何設計？
網路潮科技2019-11-15 10:55:30在現實中只要涉及到支付，必然就會有對賬的需求，幾乎所有公司的業務中多多少少的都會涉及到支付，大一點的公司甚至都標配有了自己的第三方支付公司，因此對賬具有普遍性。對賬系統是支付體系中最重要的一環，也是保證交易、資金安全的最後一道防線。在大多數的網際網路公司中，一般都會有獨立的對賬系統來處理。
我認為一個好的對賬系統需要科學，完善，閉環，便於操作，安全等幾大方面。
民間交易員2019-11-16 19:14:42對賬是金融領域中的名詞，對應的學科為大家熟知的會計學。在金融領域中，不僅銀行、基金、第三方支付機構需要對賬，其他任何涉及金融交易的公司/機構都需要對賬，比如商戶業務、信貸業務等。
對賬是指對前一個清算週期的交易資訊進行核對，以確認交易資訊的一致性和正確性的過程。這是普遍認可的一個概念，可以用一句話總結：確保單個週期內，資訊流和現金流的一致。
透過對賬可以保證賬證一致、賬賬一致、賬實一致，三者一致的正確、真實、完整為後續的佣金、分潤等計算提供基礎。對賬的準確性也為系統、人工平賬提供了差錯資訊，確保平賬後達到財務一致。
總之，對一個公司來說，透過對賬，可以正確地反映企業的財務狀態，及時發現差錯，確保業務健康發展。
對賬大部分涉及兩方對賬，極少情況下會有三方對賬的情況。三方對賬本身的系統邏輯比較複雜，特別是三方平賬時的差錯處理更加複雜，這裡不作討論。
對於沒有虛擬賬戶，只有交易通道類的對賬，有兩種對賬型別：總分對賬和明細對賬。
總分對賬即根據不同的交易通道，把每個交易通道的進出或者單獨的交易型別進行彙總，按照不同交易通道、不同交易型別進行總對總對賬，確保和每個交易通道的進出是一致的，確保每個通道不會有長款或短款的情況。
對大部分系統來說，總分對賬沒有差錯就不用進行明細對賬了。
如果發現總分對賬有差錯，就需要進行明細對賬，將具體差錯資訊找出來。明細對賬，顧名思義就是將發生的每一筆交易的詳細資訊和交易通道的對賬檔案進行逐筆核對，找出是否有不一致的交易。
重慶小哪吒2019-11-15 15:43:55對電商系統來說，每一筆交易，在所有相關主體側都要能對得上：
交易主體，如果發起人是個人，必須能夠從個人交易歷史記錄中找到這筆交易。但大部分人不會保留電子記錄，所以一般是提供可以下載的賬單或交易記錄，讓使用者自己對去。
交易對手，一般是商戶。商戶側對賬處理同用戶側，也僅僅提供對賬單。
交易渠道側，這是對賬的重點，一是核實交易流水，二是核實交易佣金，畢竟是租用人家通道做結算的。
那有哪些記錄需要對賬？ 目前主要是兩個：一個是交易記錄；一個是退款記錄。
對賬處理流程
一般來說，對賬流程涉及到如下步驟： 渠道對賬單下載、本地交易記錄準備、軋賬、平賬。
渠道對賬單下載
銀行，第三方支付，銀聯等，基本都會提供對賬單下載的功能。不過也有少數工作做不到位或者太到位的銀行，只提供賬單查詢後臺，不提供對賬單下載功能。
對開發人員來說，這裡有幾個坑：
對賬單格式不一。文字，XML，csv的都有。為了後續能夠統一處理，在賬單下載完成後，需要進行標準化處理。
下載方式不一，HTTP，HTTPS，FTP的，都有。下載程式需要按照渠道的協議來處理。
下載時間不一，一般是凌晨1點後，到中午12才能用的也有。如果在預定的時間取不到資料，需要注意重試讀取。
穩定性差。FTP伺服器出問題那是常有的事。渠道側解決方案往往就是重啟。所以重試機制是必要的。
技術選型上，HTTP（S）用apache httpclient即可實現連結池和斷點續傳， FTP也可以使用Apache Commons Net API。 但不管是哪一個，都需要設定重試次數和連結超時間。重試次數和間隔的設定需要小心，重試太頻繁，容易把伺服器打死。；時間間隔太大，又會阻塞後續處理步驟。5～10分鐘是一個合適的重試間隔區間。
連結超時指在伺服器出現問題時，連線在指定時間內獲取不到資料即自動斷開。這個很容易被忽略。我們有一次系統出問題，是渠道側的FTP假死後重啟，導致我們的客戶端掛住，一直在等待重新連結。
渠道對賬單標準化
找個例子大家看看， 比如微信的對賬單，他是csv格式的，包括如下資訊：
交易時間：這是在微信側的支付完成的時間。 這個時間會成為一個陷阱。
公眾賬號ID，商戶號，子商戶號，裝置號： 這些資訊需要做驗證，確保是自己的單子，不要讓微信把老王家的單子也給發過來了；
微信訂單號，商戶訂單號： 這兩個是對單的核心。前者是微信側產生的訂單號，在微信支付介面返回值中有。但是萬一收不到這個返回值，那在本地記錄中可能就空了。 後者是我們傳送給微信的訂單號，一般用這個來做對單依據。兩邊的資料中都會有這個值。
使用者標識，交易型別，交易狀態，付款銀行，貨幣種類，總金額，企業紅包金額： 這幾個就是對單的核心欄位，必須確保雙方是一致的。
商品名稱，商戶資料包，手續費，費率：這些是可選驗證。
微信對賬單
而某寶的對賬單，是文字格式的，用空格隔開。他們家的就簡單很多，只有商戶訂單號，交易流水號，交易時間，支付時間，付款方，交易金額，交易型別，交易狀態這些欄位。
某寶對賬單
由於每個渠道的賬單格式都不盡相同， 在得到賬單後，下一步是對賬單做標準化處理，這樣軋帳以及後續工作就可以統一處理了。 標準化後的賬單資料可以放在檔案系統或者資料庫中。這取決於交易資料量。每天百萬以上的量，還是使用檔案系統，比較合適。資料庫操作相對比較慢，也浪費資源。
基於檔案系統的標準化涉及如下內容：
檔案格式標準化：統一使用csv或者json或者xml格式。如果是使用hadoop或者spark來對賬，使用csv是個不錯的選擇。
檔案儲存統一化：檔案目錄，檔名都需要遵循統一命名規範。
為了加快處理速度，我們使用hdfs作為檔案系統，有利於後續的對賬的處理。
本地交易記錄準備
本地交易記錄的準備，總的來說有如下方法： – 啥都不做，直接用原始資料。鑑於大部分系統使用的是mysql，這也意味著在MySQL上做對賬。對賬時需要大量的資料查詢工作，必然會影響線上業務。在資料規模較大，比如超過100萬時，就不太合適了。
當然，還有一個選擇是使用備庫來執行對賬，這樣既簡單，也不影響線上業務。這是典型的空間換時間的做法。
如果業務大到需要分表分庫才能處理，那對賬資料準備也不一樣。使用分庫也不現實，因為分庫一般是按照主體id，而不是渠道id，來分庫，這樣對賬就需要在多個庫上進行，效率反而降低了。而對分表分庫建立從庫也非常耗費資源。這種情況下，需要同步一份資料到（hdfs）檔案系統中，或者NOSQL資料庫上。
由於交易記錄是支付系統核心資料，有大量的應用，如信用、風控等，都需要交易記錄資料。這些應用對交易記錄的需求還不完全一致，為了提升效能， 交易記錄會使用非同步的方式來將資料投遞給使用方。 交易記錄在入庫時，投遞訊息到訊息系統中。使用方監聽這個訊息，一旦收到新訊息，則從交易記錄庫中查詢資料，獲取資料並更新到庫中。關於此類資料同步的文章不少，這裡就不詳細介紹。
軋帳
軋帳是按照客戶訂單號來比較本地交易記錄和渠道交易記錄是否一致。從演算法角度，是計算兩個陣列的差異。在單機執行時，可以採用的演算法不少，這裡不詳細介紹。 我們推薦採用mapreduce來軋帳，這有個優勢，可以按照訂單號將渠道提供的記錄和本地記錄shuffle到同一個reduce處理上，這樣就可以很容易進行資料比對。 軋帳中最大的坑，莫過於切分點的問題。
比如以整0點為切分點，那存在一個問題，本地23：59發起的交易，到了渠道側，可能會在00：01處理，這一筆交易變成第二天的帳了。實際處理中，一筆交易在渠道側處理，花上幾分鐘都有可能。 對於切分點附近無法確認的帳，做一個時間窗，在時間窗內的資料，留待第二天對賬時繼續處理。
平帳
發現兩邊不一致的資料，那應該如何處理？資料量不大時，記錄起來，人工甄別就行。但如果資料量很大，每天上千條，人工處理就成本太高了。這個沒有統一的處理方法，需要根據有問題的資料，做個分析，然後做自動處理。 針對交易記錄的對賬的處理，主要有如下情況：
本地未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發的非同步通知導致。 一般處理是將本地狀態修改為已支付，並做響應的後續處理，比如通知業務方等。
本地已支付，支付渠道已支付，但是金額不同，這個需要人工核查。
本地已支付，但是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。在排除跨日因素外，這種情況非常少見，需要了解具體原因後做處理。
針對退款的對賬處理，主要有如下情況：
本地未退款，支付渠道已退款，則以支付渠道為準，修改本地為已退款狀態，並觸發後續處理。
本地已退款、支付渠道已退款，但是金額不同，需要人工核查；
本地已退款，但是支付渠道無記錄；或者支付渠道有記錄，但是本地沒有。 在排除跨日因素外， 這種情況非常少見，需要了解具體原因後做處理。
總之，對賬工作，即複雜也不復雜。需要細心，對業務要有深入的瞭解，並選擇合適的架構。
眺望金沙2019-11-15 19:31:59對賬系統設計主要分為以下四個模組：
渠道資料處理模組
資料處理模組
核對模組
差異資料處理模組
天明哥V2019-11-15 15:03:10天明哥從我們開店來說說，如何設計對賬系統。大家都知道，你開的門店一但需要僱傭店長或者透過合夥來進行管理，就需要牽扯到對賬。如果想省去對賬的麻煩，可以在分配機制裡進行設計，比如，按營業額的比例來分。
如果不按比例，按工資加績效等方式來分的話，也是可以的。前提是都要對賬 要保證你門店的貨，資金對的上。
對於小店建議做一個日常日清統計表，把每天的產品流動，經營結果進行統計彙報，包裝物料產品可以有容錯區間限制。
當然，在收銀環節也要沒一塊錢都要經過收銀系統，禁止私自收錢。
方禾圓2019-11-15 18:07:16從我們開店來說說，如何設計對賬系統。大家都知道，你開的門店一但需要僱傭店長或者透過合夥來進行管理，就需要牽扯到對賬。如果想省去對賬的麻煩，可以在分配機制裡進行設計，比如，按營業額的比例來分。
如果不按比例，按工資加績效等方式來分的話，也是可以的。前提是都要對賬 要保證你門店的貨，資金對的上。
對於小店建議做一個日常日清統計表，把每天的產品流動，經營結果進行統計彙報，包裝物料產品可以有容錯區間限制。
當然，在收銀環節也要沒一塊錢都要經過收銀系統，禁止私自收錢。
財商操作實戰專家2019-11-15 16:13:11作為職業工作人員必須做到，保留有效原始憑證，清晰計入每一筆賬單去向
獨DY語2019-11-14 17:02:39你想針對哪一方面設計對賬系統。
娜娜教你玩期權2019-11-15 10:12:02在網際網路行業中只要涉及到支付，必然就會有對賬的需求，幾乎所有網際網路公司的業務中多多少少的都會涉及到支付，大一點的公司甚至都標配有了自己的第三方支付公司，因此對賬具有普遍性。對賬系統是支付體系中最重要的一環，也是保證交易、資金安全的最後一道防線。在大多數的網際網路公司中，一般都會有獨立的對賬系統來處理，比如：電商平臺、網際網路金融、第三方支付公司等。
對賬是支付系統中的一環，因此在對賬前我們先了解一下相關的業務知識
業務知識什麼是對賬
傳統的對賬就是核對賬目，是指在會計核算中，為保證賬簿記錄正確可靠，對賬簿中的有關資料進行檢查和核對的工作。在銀行或者第三方支付中，對賬其實是對一定週期內的交易進行雙方確認的過程，一般都是在第二天銀行或者第三方支付公司對前一日交易進行清分，生成對賬單供平臺商戶下載，並將應結算款結算給平臺商戶。在往下一層，在網際網路金融行業或者電商行業中，對賬其實就是確認在固定週期內和支付提供方（銀行和第三方支付）的交易、資金的正確性，保證雙方的交易、資金一致正確。
廣義的對賬，所有跨應用的資料互動，理論上都應該進行對賬。所以對賬也可以分為資訊流對賬，資金流對賬。資訊流對賬也一般用在自己內部系統的對賬，比如支付系統的支付資料和業務系統的業務資料進行對賬，保證資金交易和業務交易的一致性。資金流對賬也就是支付系統和銀行或者第三方支付系統之間的資金交易對賬。
對賬方式
單向對賬：一般拿第三方支付機構或銀行流水，與自己系統進行對賬，防止出現掉單問題；
雙向對賬：兩個應用間的流水進行雙向核對，如訂單與財務系統，既要保證財務系統支付成功的記錄，訂單系統也是成功的；也要確保訂單系統記錄成功的記錄，財務系統也成功。
我們一般採用雙向對賬的方式進行對賬
對賬相關的問題
不同系統日切點不一致問題：滾動對賬差錯處理：補賬，補償（退款）
相關概念
軋帳和平帳
每一筆交易，都要做到各參與者的記錄能夠吻合，沒有偏差。對賬系統的工作，是發現有差異的記錄，即軋帳；然後透過人工或者自動的方式，解決這些差異，即平帳。
長款和漏單
在以平臺交易為基準的情況下和銀行對賬，發現週期內的交易，平臺有此訂單而第三方支付中沒有訂單，成為平臺長款。平臺長款一般是由於使用者在支付的時候跨天的情況，比如使用者在23：58分建立了訂單，在第二天的凌晨00：03分進行了支付。在以銀行交易為基準的情況下對賬，銀行有此訂單而平臺無此訂單，即為平臺漏單。平臺漏單很少見，一般直接轉人工處理。
賬戶體系
在一般的支付體系中會分為登入賬戶和支付賬戶，支付賬戶指使用者在支付系統中用於交易的資金所有者權益的憑證；登入賬號指使用者在系統中登入的憑證和個人資訊。一個使用者可以有多個登入賬戶，一個登入賬戶可以有多個支付賬戶，比如零錢賬戶、儲值卡賬戶等。一般來說，支付賬戶不會在多個登入賬戶之間共用。對賬的交易一般都是支付賬戶參與交易。
交易與賬戶
賬戶設定，一般是從交易開始的。 交易的實現必須有賬戶的支援，賬戶是交易的基本構成元素。 從支付系統的角度，交易中涉及到的資金流是資金從一個賬戶流向另一個賬戶。 發起交易的一方，被稱之為交易主體，他可以是一個人，也可以是一個機構。
清算和結算
清算主要是指不同銀行間的貨幣收付，可以認為是結算進行之前，發起行和接收行對支付指令的傳送、接收、核對確認，其結果是全面交換結算工具和支付資訊，並建立最終結算頭寸。
結算是指將清算過程產生的待結算頭寸分別在發起行、接收行進行相應的會計處理，完成資金轉移，並通知收付雙方的過程。當前，大多數銀行結算業務的完成主要透過兩類賬戶：一是銀行間互相開立的代理賬戶，二是開立在央行、獨立金融機構如銀聯、或者第三方支付機構的賬戶。
清算：計算各方應收應付錢款的時間與金額。結算：根據清算的結果在指定的時間對各方進行實際的資金轉移操作
資金池
使用者備付資金（如充值）統一放在企業的銀行賬戶中，企業可以隨意支配這些資金，即為資金池。與之對應的是第三方託管，使用者備付資金是放在企業在第三方支付機構為使用者開設的虛擬賬戶中，企業無法隨意取出這些資金。現在網際網路金融全面要求接入銀行存管，就是銀行會為每個使用者建立一個資金賬戶來保護使用者的資金，互聯金融公司不能隨意劃撥這些資金賬戶中的金額。
對賬系統對賬設計
對賬系統的設計階段，將對賬系統分為四個模組，每個模組的負責自己的職能。
檔案獲取模組：下載或者讀取各渠道對賬檔案
檔案解析模組：建立不同的解析模板，根據渠道和檔案型別獲取對應的解析模板進行解析
對賬處理模組：對賬的業務邏輯處理
差錯處理模組：處理差錯池中的訂單
一般會設計一個定時任務，每天固定的時間點觸發，定時驅動排程類分別呼叫四個模組來處理對賬。也有的銀行會主動的推送對賬單，再透過http回撥來觸發對賬流程。
對賬演算法
一、流程：
1、從上游渠道（銀行、銀聯等金融機構）獲取對賬檔案，程式逐行解析入庫；2、在程式處理中，以上游對賬檔案的表為基準，程式逐行讀取並與我們系統的交易記錄對比賬務記錄（有賬務系統情況下，合理方案應該是於賬務記錄）對比，查找出差異記錄；3、以我們系統的交易記錄對比賬務記錄為基準，程式逐行讀取與上游對賬檔案對比，查找出差異記錄。
二、缺陷：
1、對賬過程中查詢相關資料，如果資料量巨大，對資料庫效能影響較大，而且對賬邏輯擴充套件極為麻煩；2、逐行比對演算法效率較低，但演算法上並無好的最佳化餘地。如果採用資料庫INTERSECT、MINUS對資料庫壓力也高；3、在業務量大的情況下（例如有上百家上游渠道需要對，每一家都有幾十萬條交易記錄），對賬伺服器及資料庫伺服器負荷較高。即便採用讀寫分離，對賬時候使用讀庫，壓力一樣很大；4、匯入批次檔案，逐行入庫效率較為低下（每一次都需要建立網路連線、關閉連線）。
三、改進：
1、涉及網路傳輸的，儘量採用批次方式操作，減少網路消耗及時間消耗；2、使用Redis等NOSQL資料庫，降低資料庫伺服器的壓力。同時在擴充套件上也容易，一臺Redis伺服器不夠，可以無限制增加用於對賬用的伺服器；3、使用Redis的set集合的sdiff功能，利用Redis sdiff演算法的高效能，比對上游記錄和我方記錄的差異。
對賬流程
1、下載對賬單
大多數銀行都要求接入方提供ftp服務，銀行定時將對賬單推送到接入方提供的ftp伺服器上面；還有一部分銀行會提供對賬單的下載服務，透過ftp/http的都有，ftp方式居多；另外網銀的對賬單比較特殊，一般都需要結算登入網銀的後臺管理系統中，手動下載，結算下載完對賬單後在匯入到對賬系統。
技術實現上可以做成工廠模式，不同的支付渠道有不同的下載類，如果是http介面將檔案寫入到對賬單，如果是ftp伺服器，將伺服器中的對賬單下載到本地帶解析的目錄中。主要涉及的程式碼ftp工具類、http（s）工具類，相關IO讀寫。
技術選型上，HTTP（S）用apache httpclient即可實現連結池和斷點續傳， FTP也可以使用Apache Commons Net API。 但不管是哪一個，都需要設定重試次數和連結超時間。重試次數和間隔的設定需要小心，重試太頻繁，容易把伺服器打死。；時間間隔太大，又會阻塞後續處理步驟。5～10分鐘是一個合適的重試間隔區間。
2、建立批次
建立批次一方面是為了防止重複對賬，另一方面需要在對賬結束的時候將對賬的結果資訊儲存到批次中。
3、解析檔案
解析檔案主要是將下載的對賬檔案解析成我們可以對賬的資料型別並且入庫。解析的檔案不同渠道有不同的型別，因此也可以設計成不同的解析模板，使用工廠模式將不同格式的檔案解析成可以對賬的統一資料型別。解析的檔案型別一般包括：json、text、cvs、excle等，另外部分銀行會對賬單做加密或者提供zip打包的格式，這裡就需要額外開發zip工具類和加解密工具類進行處理。
對賬檔案中包含的主要資訊有：商戶訂單號、交易流水號、交易時間、支付時間、付款方、交易金額、交易型別、交易狀態這些欄位。
4、對賬處理
對賬處理也是對賬的核心邏輯，具體分為以下的幾個步驟來實現：
查詢平臺所有交易成功的訂單
查詢平臺所有的交易訂單
查詢平臺快取池中的資料
查詢銀行交易成功的訂單
開始以平臺的資料為準對賬，平臺長款記入緩衝池
開始以銀行通道的資料為準對賬
以平臺訂單為基準對賬邏輯：以平臺所有交易成功的訂單為基準，遍歷銀行訂單的所有資料，找出訂單號相同的訂單，對比訂單的金額、手續費是否一致。如果一致跳過；如果不一致，平臺訂單進入差錯池；如果在銀行訂單中沒有找到此筆交易，訂單進入快取池，記錄平臺長款。同時統計對賬相關金額和訂單數。
以銀行訂單為基準對賬邏輯：以銀行的交易資料為基準，遍歷所有平臺的交易（包括未成功的訂單），找出訂單號相同但支付狀態不一致的訂單，在進行對比金額存入差錯池。如果沒有在平臺的交易中找到此訂單，再從快取池中遍歷查詢，找到對應的平臺訂單驗證金額是否一致，不一致進入差錯池。如果在快取池匯中依然沒有找到對應的訂單，直接進入差錯池，記錄平臺漏單。同時統計對賬相關金額和訂單數。
5、對賬統計
根據對賬處理中，統計的相關資訊包括：對賬完成時間、對賬是否成功、平賬的金額和訂單數、差錯的金額和訂單數、快取池金額和訂單數等。
6、差錯處理
在一般系統中，差錯處理分為兩種，一種人工來處理，一種系統自動來處理。
主要有如下情況：
本地未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發的非同步通知導致。 一般處理是將本地狀態修改為已支付，並做響應的後續處理，比如通知業務方等。
本地已支付，支付渠道已支付，但是金額不同，這個需要人工核查。
本地已支付，但是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。在排除跨日因素外，這種情況非常少見，需要了解具體原因後做處理。
求研閔2019-11-14 17:53:41實際財務工作中，對賬工作是一個重要環節。期末財務報告之前，一定要確保帳賬、帳表、帳實及所有的資料及勾稽關係一致。最為重要的是帳實核對，透過盤點實物等查明財產的實存數與賬存數是否相符的方法，比如貨幣資金一定要與現金實盤數及根據各銀行存款對賬單製作的銀行存款餘額調節表，核對無誤，應收賬款要逐一與各個欠款客戶進行對賬。
洪多多多2019-11-16 00:01:06在AI時代，運用資料庫比對
義烏達文西2019-11-15 11:48:43對賬是做什麼呢？說起來很簡單，通俗講就是，你該收到的和你真收到的是否一致，你該給的和你真給的是否一致。夠通俗嗎？如果套用到實際例子中，銀行和支付系統的收單對賬就是，你該收到的和銀行給你是否一致。退款對賬就是，你該給的和銀行真退出去的是否一致。當然，還有一些內部業務系統的對賬，例如賬務系統與業務系統之間的對賬，訂單系統與業務系統的對賬等等，你都按照這種去理解應該沒什麼問題。
鏈信扶持團2019-11-15 10:44:37從整體來看，按照時序維度的先後，系統對賬主要分為三階段的工作。分別是資料準備、資料核對和差錯處理。
資料準備細分一下，又分為檔案獲取、檔案解析、資料清洗。
在對賬專業概念中，資料核對和差錯處理又叫軋賬和平賬。
具體設計腦圖
賈全義jqy2019-11-16 15:37:38實際財務工作中，對賬工作是一個重要環節。
期末財務報告之前，一定要確保帳賬、帳表、帳實及所有的資料及勾稽關係一致。最為重要的是帳實核對，透過盤點實物等查明財產的實存數與賬存數是否相符的方法，比如貨幣資金一定要與現金實盤數及根據各銀行存款對賬單製作的銀行存款餘額調節表，核對無誤，應收賬款要逐一與各個欠款客戶進行對賬。
潮圖潮句呀2019-11-16 02:24:26人工上傳檔案處理方式步驟如下：
下載檔案
從指定SFTP伺服器下載檔案。
解壓檔案
一般為zip壓縮包，節省儲存空間，提高上傳和下載速度。
解析檔案
一般檔案格式為EXCEL（財務人工上傳檔案，一般從銀行或第三方支付後臺下載）、CSV（資料接入方一般從資料庫匯出格式，或第三方支付提供的檔案格式）、TXT。
儲存資料
將第三步得到的資料儲存、持久化到資料庫，一般底稿資料都儲存最全數方便問題追溯。
遠方的小紅2019-11-16 22:27:29從整體來看，按照時序維度的先後，系統對賬主要分為三階段的工作。分別是資料準備、資料核對和差錯處理。
資料準備細分一下，又分為檔案獲取、檔案解析、資料清洗。
在對賬專業概念中，資料核對和差錯處理又叫軋賬和平賬。
對賬各個模組設計
資料準備
資料準備，顧名思義，我們需要把對賬所需的全部資料，接入到我們的對賬系統。
該模組主要實現兩個目標：
為不同的外部系統提供多元化的接入機制。
透過資料適配的手段把外部資料以統一的格式進行轉換和儲存。
在資料接入層，我們會針對不同的資料接入方提供三種不同的資料接入模式。
資料拉取
主動拉取資料，並透過資料適配的方式，將資料儲存到對賬資料池中。
資料推送
指定標準規範和格式，供各個接入方使用，統一格式推送到對賬服務。
人工上傳
提供標準的檔案模板，由業務接入方填充資料，通過後臺文件上傳或SFTP上傳工具的方式將資料上傳到對賬服務。
人工上傳檔案處理方式步驟如下：
下載檔案
從指定SFTP伺服器下載檔案。
解壓檔案
一般為zip壓縮包，節省儲存空間，提高上傳和下載速度。
解析檔案
一般檔案格式為EXCEL（財務人工上傳檔案，一般從銀行或第三方支付後臺下載）、CSV（資料接入方一般從資料庫匯出格式，或第三方支付提供的檔案格式）、TXT。
儲存資料
將第三步得到的資料儲存、持久化到資料庫，一般底稿資料都儲存最全數方便問題追溯。
資料清洗
顧名思義，即對準備的上下游資料進行清洗。
清洗的作用或原因：
從底稿提取對賬核心欄位
一般參與對賬的欄位就幾個，具體欄位：銀行卡號、銀行單號、業務單號、支付金額、支付方式、支付完成時間、核對狀態。
上文提到底稿一般建議儲存所有資料，資料太多影響對賬效能和效率。
合併、排除無用資料
上文提到底稿一般建議儲存所有資料，難免有無用資料需要剔除，或者排除業務或財務指定無需對賬的資料；合併特殊業務或流程產生的N對1資料。
資料核對
對賬的核心
資料核對是對賬的核心，對賬的主邏輯；一般對賬方式有兩種，即對明細賬和對總賬，對總賬一般包括總金額和總條目。一般做法為對明細賬，即上下游每條記錄逐一比對。
核對的結果
核對一般就是兩個結果：對上帳和對不上賬，對不上賬有分三種結果，上游單邊（支付中一般稱為企業單邊，即長款），下游單邊（支付中一般稱為銀行邊，即漏單），金額不等（即兩邊都有資料，金額對不上）。
設計normal和different兩張表，分別儲存不同的核對結果資料，方便後期統計以及為業務提供能力。
具體對賬的方法有多種，比如：
sql核對
exist insert select
最簡單的方式，也是問題比較多方式，對資料庫壓力比較大，資料特別多的時候，對賬效率比較低。
redis核對
set集合分別diff （inter）上游、下游資料
比較好的方式，可以降低資料庫壓力，redis方便根據資料量做水平擴充套件。
sprak核對
採用流式運算進行比對；（具體做法待擴充套件）
差錯處理
在一般系統中，差錯處理分為兩種，一種人工來處理，一種系統自動來處理。
人工處理一般兩個操作：平賬和勾兌，勾兌一般處理的是單邊情況，比如由於系統bug出現的單邊問題，經由人工溯源修復bug之後，相關業務人員即可在對賬後臺將該條資料進行勾兌。
系統自動處理一般為：自動補單和驅動下游流程完成兩種方式。主要有如下情況：
下游單邊（銀行單邊）情況
業務未支付，支付渠道已支付。這主要是本地未正確接收到渠道下發的非同步通知導致。
一般處理是將本地狀態修改為已支付，並做響應的後續處理，比如通知業務方等。
上游單邊（企業單邊）情況
業務已支付，但是支付渠道中無記錄；或者本地無記錄，支付渠道有記錄。
在排除跨日因素外，這種情況非常少見，需要了解具體原因後做處理。
金額不等情況
業務已支付，支付渠道已支付，但是金額不同，這個需要人工核查。
對賬統計
根據對賬處理結果，統計的資料由：彙總總條目、彙總總金額、彙總差異結果、彙總單邊結果、彙總處理結果。
業務和財務關係的統計的相關資訊有：對賬完成時間、對賬是否成功、平賬的金額和訂單數、差錯的金額和訂單數、快取池金額和訂單數等。
對賬系統相關設計
分散式定時系統
一般對賬系統都是N+1離線對賬，所有上述所有模組的設計一般使用定時任務去執行。不可能所有模組、所有銀行卡都用一個任務去執行，也不可能只用一臺機器去執行，這樣一天可能都跑不完所有的資料。
所以考慮到最佳化，一般設定為叢集分散式的去跑任務，所以涉及一個分散式定時系統對對賬系統來說很重要，考慮成本和時間問題，可以簡單實現分散式任務效果。分散式定時系統的設計後續再單獨探討。
即使所有任務都按模組化去進行劃分，按模組化單獨起任務去執行業務邏輯，也會存在時間效率的瓶頸（因為下文提到的依賴關係，導致並不能讓所有的任務都並行起來）。再加上銀行卡號比較多的情況下，最好情況就是各個銀行卡號並行處理，即併發粒度設計到銀行卡號維度，使用多執行緒把所有銀行卡的對賬任務並行起來。
依賴鏈設計
所有模組是存在依賴關係的，比如清洗之前，肯定要資料準備完成；但是上游資料和下游資料的準備、清洗可以併發的執行。
核心對賬最佳化
上文模組設計有提到核心對賬的多種實現思路，這裡推薦的兩種：
redis 實現
sprak 實現
具體實現過程會在後續博文中詳細介紹。
對賬系統資料庫模型
按以上設計模型，具體資料模型如下介紹。
底稿資料表
各個上游資料、下游資料抓取、解析的底稿資料 。
不只兩張表，由具體業務決定；資料量比較大，一般按日期水平分表，按實際業務考慮要不要垂直分表。
清洗表
從各個上游資料、下游資料的底稿資料取部分欄位。
不只兩張表，由具體業務決定；資料量比較大，一般按日期分表。
對賬結果表
正常表
用來存放對上賬的資料（即對賬結果正常的資料，一般資料量比較大，需要按日期分表）
異常表
用來存放對不上賬的資料（上游單邊、下游單邊、金額不等）。
對賬彙總表
即對對賬資料的彙總
專注支付很多年2019-11-15 08:21:41可以套用專業表格
洛克先森來了2019-11-15 07:51:53這個是專業的財務人員回答的問題，我都不幹財務我咋知道
Banma趙紅巖2019-11-14 23:15:44對賬的核心是對錢，錢的資金走向，所有之處錙銖必較，錙銖必究。
智慧財稅安全可靠2019-11-14 19:35:09對賬首先要確定重點，核心問題就是對錢，我們可以打出全月的銀行對賬單與銀行日記賬逐筆的核對，確保期初餘額、期末餘額與銀行對賬單相符。原材料賬，庫存商品賬要與實物進行盤點，確保賬實相符。