對于每天都需要對賬的生意來講，如果遇上大的額數(shù)，就會出現(xiàn)困難，為了提升核對效率以及準(zhǔn)確性，對賬系統(tǒng)有一定的改變是避免不了的，下面是筆者整理的關(guān)于“對賬系統(tǒng)”的內(nèi)容分享，想要了解相關(guān)內(nèi)容的可以接著繼續(xù)往下了解了解哦！

賬目核算是財務(wù)工作的必要部分，隨著線上交易體量越來越大或者說對財務(wù)自動化線上化的效率提升需求越來越高，為了提升核對效率以及準(zhǔn)確性，要將核對業(yè)務(wù)系統(tǒng)化、線上化、自動化。如何構(gòu)建設(shè)計一套不同業(yè)務(wù)場景下的對賬系統(tǒng)是本文的重點。

一、對賬概述

日常生活中每天都在對賬，比如去餐館吃飯付款，會對老板說一聲“老板，錢付過去了”，老板檢查收款情況或者聽到語音播報后回復(fù)一聲“好嘞，下次再來”，這就是一次最簡單的對賬。

再比如在淘寶開了一個店鋪，每個月幾千單的交易、發(fā)貨；次月末都拿著所有的訂單明細(xì)和支付寶收款記錄逐筆做一次核對，保證發(fā)過貨的訂單都收到款了，這是一次更復(fù)雜的核對。

1. 對賬的定義

對賬就是“賬證實”的核對，“賬”是賬目，“證”是憑證，“實”是實際資金或者商品。常見的核對模式有三種：賬證核對、賬賬核對、賬實核對，確保賬證實兩兩的一致性。如在飯館吃了一碗面，其中點菜單就是原始憑“證”，付了10元錢是“賬”，老板電腦記錄10元是“賬”，老板看到賬戶中余額增加了10元是“實”。

從財務(wù)范疇來看，證就是會計憑證，比如發(fā)票、小票、出貨單、收據(jù)、交易系統(tǒng)的支付記錄等都是原始憑證；而賬呢就是財務(wù)的賬目，賬務(wù)系統(tǒng)的賬務(wù)記賬，金蝶的科目余額等都是不同的賬目；而一筆交易會記錄在很多的環(huán)節(jié)，比如賬務(wù)系統(tǒng)，金蝶等。

從廣義的時間看核對一致性，核對的就是數(shù)據(jù)，其中包括商品數(shù)據(jù)、用戶數(shù)據(jù)、卡券數(shù)據(jù)等。財務(wù)范疇的賬證實需要核對，而非財務(wù)范疇數(shù)據(jù)也需要核對，比如今天應(yīng)到10人實到8人，軍訓(xùn)時的報數(shù)等其實也可以稱為對賬，我們暫且稱為“廣義的對賬”。

對賬的廣義定義：為了確保同一個事務(wù)的數(shù)據(jù)描述在不同場所下的記錄一致而進行的相互之間的一致性比對。

為什么要對賬呢？首先在財務(wù)范疇，這是一個必要做的工作；其次，從業(yè)務(wù)視角看，如今的交易鏈條越來越長，數(shù)據(jù)在眾多系統(tǒng)之間難免會出現(xiàn)丟失或者差錯的情況，所以為了業(yè)務(wù)的正常運轉(zhuǎn)并及時發(fā)現(xiàn)問題，需要確保系統(tǒng)間數(shù)據(jù)的一致性。

最后，從公司的角度看，需要確保“不少收一分錢，不多付一分錢”，保證資金的安全，不然賣了多少貨，收了多少錢相互之間無法自洽，最后全是糊涂賬。

綜上所述，對賬是必不可少的；對于交易體量巨大的互聯(lián)網(wǎng)公司更是必不可少，而且系統(tǒng)化也是必須的，單靠人工難以滿足需要。

2. 對賬場景和模型

常見的對賬場景包括三方支付公司內(nèi)的對賬、電商平臺內(nèi)部的對賬、金融及清算機構(gòu)等機構(gòu)內(nèi)部的核對等，其中：

• 三方支付公司的對賬：主要是核對自家的交易記錄和銀行清算數(shù)據(jù)之間的一致性；銀行清算數(shù)據(jù)（應(yīng)收應(yīng)付）和銀行結(jié)算數(shù)據(jù)（實收實付）的一致性；同樣也要核對與賬務(wù)系統(tǒng)數(shù)據(jù)的一致性。
• 電商等服務(wù)平臺的對賬：主要是核對自家的交易數(shù)據(jù)和三方支付公司的清算數(shù)據(jù)的一致性；三方清算和結(jié)算的一致性；三方機構(gòu)結(jié)算到企業(yè)對公戶的資金的一致性。

1）對賬模型

對賬模型根據(jù)核對的數(shù)據(jù)種類以及核對模式的不同可以分為交易對賬、資金對賬、余額調(diào)節(jié)對賬、其他對賬等，其中：

• 交易對賬模型：交易數(shù)據(jù)之間通過唯一標(biāo)識進行一對一、一對多、多對多核對業(yè)務(wù)；
• 資金對賬模型：將交易數(shù)據(jù)按照款項類型進行匯總之后進行核對，比如收款，手續(xù)費；
• 余額調(diào)節(jié)核對：將系統(tǒng)記賬余額和實際資金賬戶余額經(jīng)過在途調(diào)整后進行一致性核對的業(yè)務(wù)。

2）搭建對賬系統(tǒng)

對賬系統(tǒng)是通過系統(tǒng)解決方案，對需要核對的數(shù)據(jù)按著設(shè)定好的規(guī)則進行核對校驗，產(chǎn)出核對結(jié)果，并對核對結(jié)果進行對應(yīng)的差錯處理的自動化信息系統(tǒng)。通俗來說就是將人工核對數(shù)據(jù)一致性的事情交給系統(tǒng)去做，只需要預(yù)先配置好各項規(guī)則即可。對賬系統(tǒng)應(yīng)具備以下基礎(chǔ)能力：

• 可以便捷的獲取需要核對的原始數(shù)據(jù)，如平臺數(shù)據(jù)、渠道數(shù)據(jù)；
• 可以對文件數(shù)據(jù)進行解析或者二次加工；
• 可以靈活配置核對規(guī)則；
• 可以查看核對的結(jié)果；
• 可以對差異進行追蹤管理和處理；
• 可以對外提供核對結(jié)果；
• 可以對外輸出數(shù)據(jù)。

如果要實現(xiàn)一款對賬系統(tǒng)，首先應(yīng)該明確相關(guān)的業(yè)務(wù)模型，其次需要抽象出業(yè)務(wù)的核對模型，然后針對核對模型選擇合適的核對方案，最后針對核對方案設(shè)計系統(tǒng)方案、研發(fā)、上線、投入使用。

3. 對賬架構(gòu)圖

本部分將提供一個通用的核對架構(gòu)，可以滿足大部分的核對訴求，如圖1所示。

圖1 對賬系統(tǒng)業(yè)務(wù)架構(gòu)圖

整個架構(gòu)圖包括左中右三大部分。

1. 左部分位業(yè)務(wù)系統(tǒng)層，為平臺的內(nèi)部數(shù)據(jù)，例如訂單數(shù)據(jù)、交易數(shù)據(jù)、卡券數(shù)據(jù)、支付數(shù)據(jù)等；
2. 右部分為外部渠道層，為外部支付數(shù)據(jù)，例如三方支付渠道的清算數(shù)據(jù)和結(jié)算數(shù)據(jù)；
3. 中間部分為對賬系統(tǒng)層，核心職能就是完成左右兩部分?jǐn)?shù)據(jù)在何種模型下的核對業(yè)務(wù)，包括數(shù)據(jù)管理、數(shù)據(jù)解析、交易核對、資金核對、核對結(jié)果管理等一系列的能力。

整個核對業(yè)務(wù)主流程如下：

1. 按核對頻率獲取業(yè)務(wù)支付數(shù)據(jù)；
2. T+1或其他頻率獲取三方清算文件和結(jié)算文件；
3. 將清算和結(jié)算文件進行解析存儲；
4. 根據(jù)對賬項目配置完成交易數(shù)據(jù)和清算的核對；
5. 完成清算數(shù)據(jù)和結(jié)算數(shù)據(jù)的核對；
6. 對交易的單邊數(shù)據(jù)和資金核對差異進行管理和處理。

二、對賬數(shù)據(jù)管理

對賬離不開原始數(shù)據(jù)的獲取和管理，對賬數(shù)據(jù)主要包括渠道的數(shù)據(jù)、平臺的自有數(shù)據(jù)，當(dāng)然也應(yīng)該包括核對之后的結(jié)果數(shù)據(jù)。如何獲取個管理渠道數(shù)據(jù)，以及平臺數(shù)據(jù)通過什么模式和規(guī)則獲得，對賬結(jié)果數(shù)據(jù)如何存儲和查看，是本小節(jié)的重點。

1. 渠道數(shù)據(jù)獲取與解析

支付交易的通道提供方，例如微信、支付寶、網(wǎng)聯(lián)、銀聯(lián)等，都是按照約定頻率和時間提供交易文件，一般是2份，清算文件和結(jié)算文件，其中清算文件記錄支付明細(xì)，結(jié)算文件記錄賬戶的實際資金變動明細(xì)。

一般可以通過通道方提供的專屬接口下載對賬文件，如果沒有接入下載接口或者通道側(cè)本身就不提供下載接口，可以暫時采用人工下載的方式獲得文件，獲得文件以后傳到對賬系統(tǒng)解析出對賬數(shù)據(jù)并存儲，以待核對。

1）對賬文件類型

主流文件類型以Excel和txt為主，其中Excel是常見的文件類型，這種類型的文件閱讀性強，如圖2所示，為從支付寶后臺下載的結(jié)算文件。

圖2 Excel類型的對賬文件

某些通會提供Txt格式的對賬文件，這種類型的對賬文件閱讀性比較差，數(shù)據(jù)列的分割符種類也比較多，在文件解析時存在一定難度，如圖3所示。

圖3 txt格式的對賬文件

還存在一些其他格式的文件，例如xml報文格式、csv格式、pdf格式等。無論什么格式的對賬文件，核心用途都是為了獲得交易數(shù)據(jù)進行核對。

2）對賬文件獲取方式

常見的獲取渠道對賬文件的方式是通過接口，通過機構(gòu)提供的文件查詢和下載接口獲取對賬文件，如圖4、5所示，是從支付寶開放平臺截取的對賬文件下載接口示例。

圖4 對賬文件獲取接口的請求參數(shù)

圖5 對賬文件獲取接口的返回參數(shù)

同樣可以通過人工下載的方式獲得對賬文件，如果技術(shù)能力資源不足，或者暫時沒有接入接口，可以采用人工下載的方式，然后將文件上傳至對賬中心，通過解析文件生成系統(tǒng)需要的數(shù)據(jù)。

3）對賬文件管理

從渠道獲取到的文件一般存放在對賬系統(tǒng)指定的ftp內(nèi)，并對文件或者文件夾按照命名規(guī)范進行命名，通過文件路徑查詢和下載該文件，如圖6所示。

圖6 對賬文件管理

4）對賬文件解析器配置

對賬文件解析是指將文件里的數(shù)據(jù)進行處理，轉(zhuǎn)換成數(shù)據(jù)庫數(shù)據(jù)，以某種形式存儲在數(shù)據(jù)庫內(nèi)，因為文件數(shù)據(jù)不能直接被系統(tǒng)讀取，文件解析模式有原樣解析和通用模板解析。

原樣解析是不改變文件的數(shù)據(jù)列數(shù)和內(nèi)容，在不減少文件數(shù)據(jù)列數(shù)的情況下原汁原味的把數(shù)據(jù)解析出來，可以根據(jù)需要增加列內(nèi)容，比如賬號、對賬時間等。該種解析方法有以下的優(yōu)缺點和適用性。

• 優(yōu)點：不需要配置解析器，每一個文件研發(fā)好固定的解析器進行復(fù)用；
• 缺點：每個文件類型需要建一套數(shù)據(jù)表，維護成本高；
• 適用：通道少的平臺，一般的商戶都僅有微信、支付寶，可以采用原樣解析。

通用板式解析是將所有對賬文件數(shù)據(jù)按照映射關(guān)系解析到固定的數(shù)據(jù)表中，例如表1的表結(jié)構(gòu)所示，所有的文件解析以后都要存儲在這張表里，表字段是固定的，文件中的數(shù)據(jù)怎么對應(yīng)的存儲到指定字段上，是該種解析模式最關(guān)鍵的地方。

表1 存儲對賬數(shù)據(jù)表

例如圖7中所示的是某對賬文件中的部分?jǐn)?shù)據(jù)，如何配置一個規(guī)則將這些數(shù)據(jù)解析到表1中？

圖7 示例對賬文件數(shù)據(jù)

可以設(shè)定如表2中所示的解析規(guī)則，根據(jù)該規(guī)則可以將圖8中的數(shù)據(jù)解析到表1中，表中第一行的規(guī)則的含義是將圖7中的A列數(shù)據(jù)解析到表1中的“支付時間”字段上，第二行的含義是將圖7中F列值為“收入”的數(shù)據(jù)行解析到表1的“金額”字段上，單位是元。

表2 預(yù)先設(shè)定好的解析規(guī)則

5）對賬數(shù)據(jù)查看

數(shù)據(jù)解析到數(shù)據(jù)庫里以后，為了便于排查問題直接查看數(shù)據(jù)或者其他用途，還需要提供查看數(shù)據(jù)的后臺工具，分別按照數(shù)據(jù)類型展示相應(yīng)的數(shù)據(jù)，例如平臺的支付數(shù)據(jù)、微信的清算數(shù)據(jù)、微信的結(jié)算數(shù)據(jù)、支付寶的清算數(shù)據(jù)、支付寶的結(jié)算數(shù)據(jù)、易寶支付的付款數(shù)據(jù)等，如圖8所示是平臺業(yè)務(wù)數(shù)據(jù)的后臺頁面。

圖8 業(yè)務(wù)平臺對賬數(shù)據(jù)查詢

2. 自有數(shù)據(jù)獲取與管理

獲得渠道文件賬單數(shù)據(jù)以后需要將其與平臺自己的相關(guān)數(shù)據(jù)做核對，如平臺的交易數(shù)據(jù)與清算數(shù)據(jù)做核對，平臺賬務(wù)數(shù)據(jù)與銀行賬單數(shù)據(jù)做核對。

1）平臺對賬數(shù)據(jù)獲取方式

平臺自有數(shù)據(jù)的獲取方式常采用如下形式：

• 文件獲?。簶I(yè)務(wù)系統(tǒng)定期（如每日凌晨2:00）生成文件，按照約定規(guī)范進行命名，將文件推送至對賬系統(tǒng)指定位置（ftp）；這種方式需要各業(yè)務(wù)系統(tǒng)有一定開發(fā)量，業(yè)務(wù)調(diào)整時也需要調(diào)整文件的生成策略，維護成本略高。
• 接口接收：對賬系統(tǒng)提供對賬數(shù)據(jù)接收接口，類似賬務(wù)記賬接口，業(yè)務(wù)系統(tǒng)按照約定在相應(yīng)業(yè)務(wù)節(jié)點發(fā)送業(yè)務(wù)數(shù)據(jù)到對賬中心。
• MQ：業(yè)務(wù)方按照要求在交易成功時發(fā)送約定格式的MQ消息，對賬系統(tǒng)訂閱該MQ，對MQ進行解析后獲得業(yè)務(wù)數(shù)據(jù)。
• SQL：通過SQL定期撈取業(yè)務(wù)數(shù)據(jù)，并將數(shù)據(jù)存儲到對賬系統(tǒng)數(shù)據(jù)庫中；該方式調(diào)整靈活，可以選擇在業(yè)務(wù)并發(fā)較小的凌晨進行。
• 人工上傳：對于一些采購的外部應(yīng)用，比如金蝶系統(tǒng)，數(shù)據(jù)無法通過以上方式獲取的情況下，就需要對賬人員定期下載應(yīng)用內(nèi)數(shù)據(jù)，然后上傳到對賬系統(tǒng)。

2）數(shù)據(jù)分類管理

隨著業(yè)務(wù)的發(fā)展，對賬系統(tǒng)數(shù)據(jù)會越來越多，類型也越來越多，包括支付數(shù)據(jù)、卡券數(shù)據(jù)、訂單數(shù)據(jù)、三方清算數(shù)據(jù)、三方結(jié)算數(shù)據(jù)等；每類數(shù)據(jù)的數(shù)據(jù)字段有各有不同，如何對眾多類型的數(shù)據(jù)進行管理呢？可以對數(shù)據(jù)進行分類管理，每類數(shù)據(jù)單獨設(shè)置表結(jié)構(gòu)。

首先是設(shè)置數(shù)據(jù)的大類，或者說是一級分類；就像商品類目一樣管理數(shù)據(jù)，如圖9所示。

圖9 數(shù)據(jù)分類設(shè)置

然后設(shè)置數(shù)據(jù)子類，在數(shù)據(jù)分類下面設(shè)置數(shù)據(jù)的子類，并將數(shù)據(jù)子類關(guān)聯(lián)到數(shù)據(jù)庫表，便于存儲數(shù)據(jù)，查詢數(shù)據(jù)，對賬取數(shù)，如圖10所示。

圖10 數(shù)據(jù)子分類設(shè)置

3）取數(shù)規(guī)則配置

配置好了數(shù)據(jù)分類和類型并關(guān)聯(lián)好了數(shù)據(jù)表之后，接下來就是配置獲取數(shù)據(jù)的規(guī)則了，以通過文件或者SQL兩種獲取數(shù)據(jù)的形式為例，如圖11所示。

圖11 取數(shù)規(guī)則設(shè)置

為每個數(shù)據(jù)分類配置取數(shù)方式，如果獲取的是文件就配置文件路徑，如果通過SQL獲取就配置取數(shù)sql。對賬系統(tǒng)會按照任務(wù)配置基于取數(shù)規(guī)則定期獲取對賬所需要的數(shù)據(jù)，并且插入到數(shù)據(jù)類型關(guān)聯(lián)的數(shù)據(jù)表當(dāng)中。

3. 對賬數(shù)據(jù)管理

支付數(shù)據(jù)與三方清算的核對，或者其他數(shù)據(jù)的兩兩核對，會得到核對結(jié)果，且每一組核對都會有一個組別的名字，這一部分會在下一節(jié)詳細(xì)介紹。

首先是交易對賬的核對結(jié)果，主要是展示平臺支付數(shù)據(jù)與渠道的清算數(shù)據(jù)之間的差異，或是可以理解為信息流的差異，如表3所示的案例數(shù)據(jù)。

表3 交易對賬結(jié)果示例

上表中“1、5、6”這三條記錄是有問題的，第1、5條數(shù)據(jù)是一方有一方?jīng)]有，第6條是雙方都有數(shù)據(jù)但金額不一致，這就是交易對賬結(jié)果，一般有“對平、單邊、錯賬”三種核對結(jié)果，對于核對存在問題的數(shù)據(jù)需要進行排查找出差異的原因，并進行差錯處理。

交易對賬結(jié)果是源數(shù)據(jù)本身在某個對賬項目里的核對結(jié)果；而資金對賬結(jié)果是某資金賬號某交易日的資金收付的一致性核對結(jié)果；比較平臺的資金賬收付結(jié)果與銀行的收付結(jié)果是否一致，或者說是銀行自己本身的清算與結(jié)算的款項否一致，如表4所示的案例數(shù)據(jù)。

表4 資金對賬結(jié)果示例

從上表可以看出，在退款和退款手續(xù)費款項上存在差異，且二者正好正負(fù)相抵，原因是退款和手續(xù)費是軋差出現(xiàn)在賬單里的，所以實際上并沒有差異，但是既然已經(jīng)對出差異，并且排查出原因，就需要對差異進行處理，資金對賬的差異是“長款、短款、應(yīng)收未收、應(yīng)付未付”。

確認(rèn)對賬結(jié)果后，會生成差異表，在差異表中對差異進行核銷處理。

上面介紹了交易對賬和資金對賬的核對結(jié)果，如何存儲核對結(jié)果呢？核對結(jié)果可以存儲在源對賬數(shù)據(jù)的表中，也可以單獨存儲。

存儲在源對賬表這種方式適合數(shù)據(jù)簡單的對賬體系，且同一份數(shù)據(jù)不會在多個對賬項目中進行核對，比如支付數(shù)據(jù)只與清算核對，這時候數(shù)據(jù)的核對結(jié)果就是默認(rèn)與另一方的核對情況。

存儲在單獨的對賬表這種方式適合復(fù)雜的核對場景，同一份數(shù)據(jù)會在多個對賬項目中與多組數(shù)據(jù)完成核對，產(chǎn)生多個對賬結(jié)果，比如支付數(shù)據(jù)與上游的訂單進行核對得出一個對賬結(jié)果，支付數(shù)據(jù)又會與下游的清算數(shù)據(jù)核對得出另一個對賬結(jié)果。

此時支付數(shù)據(jù)的對賬結(jié)果有2個，一個是與訂單的核對的結(jié)果，另一個是與清算的核對的結(jié)果，這種情況，對賬結(jié)果就需要單獨存儲“某數(shù)據(jù)在每一個對賬項目組中的核對結(jié)果表”。

三、對賬項目設(shè)計

業(yè)務(wù)總是在不斷變化，新的業(yè)務(wù)也在不斷出現(xiàn)，對賬數(shù)據(jù)也會因為業(yè)務(wù)的變化發(fā)生變化，當(dāng)接入了新的支付渠道對賬設(shè)置也需要新增，如果每次都通過研發(fā)實現(xiàn)，那么產(chǎn)研成本會很高，本部分將介紹如何實現(xiàn)交易對賬及資金對賬的對賬項目的配置化設(shè)計，會極大提升對賬項目的管理效率。

1. 交易對賬項目

對賬并不是簡單的一方與另一方比對，實際情況是會基于業(yè)務(wù)情況進行很多組之間的核對，比如與微信的核對，與支付寶的核對等。每一組又可以分成更細(xì)的組，比如與微信核對，可以分成微信收款核對，微信退款核對，如果微信收款有很多賬號，又可以按照微信賬戶進行分組進行核對，例如微信收款一共有兩個微信賬號：微信1，微信2，就可以設(shè)置4個對賬的組。如下：

• 對賬項目1：微信1-收款
• 對賬項目2：微信1-退款
• 對賬項目3：微信2-收款
• 對賬項目4：微信2-退款

對賬項目是按照一定維度設(shè)定的核對組，如果上述的4個核對項目組僅按照收付方向分組還可以簡化成2個核對項目組，如下所示：

• 對賬項目1：微信-收款
• 對賬項目2：微信-退款

具體如何設(shè)置核對組，這個因公司而已，因喜好而已，核心目的只要能完成全量的核對即可，對賬項目越少越容易管理，對賬項目越多越清晰，各有利弊。

1）對賬項目命名

為了便于管理還需要為每個對賬項目命個名字，如何起名也看自己喜好。比如，如果對賬組的同學(xué)都是女生，都是吃貨，因此所有對賬項目的名稱都可以跟吃相關(guān)，如工商9876-鹵煮火燒，命名的一個關(guān)鍵原則是要能從名字中看出具體核對的是什么業(yè)務(wù)。基于這個原則為開頭的幾個項目起一個如下的名字：

• 對賬項目1：會員購買微信支付-收款
• 對賬項目2：會員購買微信支付-退款

通過對賬項目的名稱便可以清晰的知道對賬項目1是會員購買的收款核對項目，對賬項目2是會員購買退款的核對項目。

2）對賬項目管理

一個企業(yè)可能會存在很多個對賬項目，有的甚至高達(dá)幾百個核對項目。為了便于管理，就需要一個菜單專門管理對賬項目，該頁面可以查看所有的對賬項目；點擊設(shè)置可以進行該對賬項目的配置；右上角的新增可以新增項目，如圖12所示。

圖12 交易對賬項目管理

3）對賬項目新增

在對賬項目列表點擊新增會有一個彈窗可以添加一個對賬項目，需要先填寫基本信息，比如對賬項目的名稱、對賬啟用時間、對賬的頻次、對賬的類型等，如圖13所示。

圖13 對賬項目新增

4）對賬項目設(shè)置

設(shè)置對賬項目主要設(shè)置對賬項目的執(zhí)行時間、核對雙方的對應(yīng)數(shù)據(jù)、核對的唯一標(biāo)識等一些處理規(guī)則。如圖14所示是一個基礎(chǔ)的設(shè)置頁面，實際工作中需要基于業(yè)務(wù)場景以及數(shù)據(jù)特點，對設(shè)置器進行一些調(diào)整，但是在這個配置基礎(chǔ)之上一般難度不大。

從頁面可以看出來，該配置是設(shè)置卡系統(tǒng)的消耗數(shù)據(jù)與訂單中的消耗記錄進行核對，為數(shù)據(jù)兩方配置了如下的數(shù)據(jù)選擇條件：

• A方數(shù)據(jù)為卡數(shù)據(jù)，數(shù)據(jù)篩選條件是”交易類型=消耗購買”；
• B方數(shù)據(jù)是訂單數(shù)據(jù)，設(shè)置以訂單號為唯一標(biāo)識進行核對；
• 訂單數(shù)據(jù)的金額如果存在多條則進行匯總；
• 對賬差異的報警接受人，可以填郵件，辦公賬號等。

完成配置后，一個對賬項目就配置完成了；對賬系統(tǒng)會照著配置的任務(wù)時間每天完成訂單數(shù)據(jù)和卡數(shù)據(jù)關(guān)于消耗明細(xì)的核對。

圖14 交易對賬項目設(shè)置

2. 資金對賬項目

線上支付完成以后，雖然通道方已經(jīng)返回支付成功，但是錢最終是不是能正確結(jié)算，還需要打一個問號，資金對賬就是應(yīng)收應(yīng)付和實收實付之間的核對，其中應(yīng)收應(yīng)付就是交易記錄所記錄的成功交易，而實收實付就是收款賬戶實際的資金入賬。

1）資金對賬項目

明白了對賬項目的概念以后，接下來要介紹的資金對賬項目就容易理解了：一個實體的銀行或者收付款賬戶就是一個資金對賬項目，所以說資金對賬是按照收付款賬戶的維度進行核對的。

將一個資金賬戶設(shè)置為一個資金對賬項目，比如平臺有2個微信收款賬戶1和2，有兩個支付寶收款賬戶3和4，一個招商對公戶5，共5個資金賬戶，那么就可以設(shè)置5個資金對賬項目，如下設(shè)置：

• 資金對賬項目1：微信賬戶1；
• 資金對賬項目2：微信賬戶2；
• 資金對賬項目3：支付寶賬戶3；
• 資金對賬項目4：支付寶賬戶4；
• 資金對賬項目5：招商對公戶5。

2）對賬項目命名

為了便于管理，還需要為每個對賬項目進行命名，如何起名看業(yè)務(wù)需求或者個人喜好，同交易對賬項目命名類似，命名的一個關(guān)鍵原則是要能從名字中看出具體核對的那個賬戶。

基于這個原則為（1)中的幾個項目按照“通道方+通道類型+賬戶號”的命名規(guī)則規(guī)則進行命名，具體命名如下：

• 資金對賬項目1：微信-收款-賬戶1；
• 資金對賬項目2：微信-收款-賬戶2；
• 資金對賬項目3：支付寶-收款-賬戶3；
• 資金對賬項目4：支付寶-收款-賬戶4；
• 資金對賬項目5：招商對公-收款-公戶5 。

對賬文件管理在前文已經(jīng)介紹過了，賬戶方一般會在次日提供相應(yīng)的清算文件和結(jié)算文件，那么文件要跟資金對賬項目對應(yīng)上，通過對賬文件命名可以知道對應(yīng)的所屬賬戶，比如制定這樣命名規(guī)則：通道方+賬號+文件類型+交易日期，按照該規(guī)則可以得到資金對賬項目1的文件命名：wx-1-pay-20210204。

3）對賬項目管理

一個企業(yè)可能存在多個資金賬戶，為了便于管理，就需要一個菜單專門管理資金對賬項目，該頁面可以進行對賬項目的新增、配置、修改等一系列的操作，如圖15所示。

圖15 資金對賬項目管理

點擊右上角的新增可以新增資金對賬項目，要填寫的信息如圖16所示，包括賬戶名稱、關(guān)聯(lián)的交易對賬編號、對賬起始時間、對賬類型、對賬頻率等基本信息，配置好基本信息以后確定新增即可增加一個對賬項目，然后通過設(shè)置進行資金對賬項目規(guī)則的配置。

圖16 資金對賬項目新增彈窗

4）資金對賬模式選擇

資金對賬是核對應(yīng)收應(yīng)付和實收實付，實收實付就是銀行實際資金的變動，使用銀行結(jié)算賬單即可，而應(yīng)收應(yīng)付的選擇其實有2種方法，一個是使用通道的清算文件作為應(yīng)收應(yīng)付，另一個是使用平臺的資金賬務(wù)作為應(yīng)收應(yīng)付。

使用銀行清算文件做為應(yīng)收應(yīng)付的數(shù)據(jù)源有個缺陷，就是平臺的支付記錄需要跟銀行的清算文件進行核對確保沒有差異，然后確保清算文件和結(jié)算文件之間的核對沒有差異，核對模型的實現(xiàn)如圖17所示。

圖17 資金對賬業(yè)務(wù)模式

在新增對賬項目時需要關(guān)聯(lián)交易對賬，目的就是看一下平臺的支付記錄和清算文件之間的核對有沒有差異，如果沒有且資金對賬沒差異，那么整個對賬就沒有問題了。

交易對賬是按照交易明細(xì)進行逐筆核對的，而資金對賬并不按照資金明細(xì)進行逐筆核對，因為存在軋差以及線下匯入等情況，資金對賬需要按照費用維度進行核對，也就是將應(yīng)收應(yīng)付和實收實付數(shù)據(jù)解析成費用項的匯總，對相同款項進行核對，其中的費用項如收款、收款手續(xù)費、退款、退款手續(xù)費、打款等。

5）對賬項目設(shè)置

以核對清算數(shù)據(jù)和結(jié)算數(shù)據(jù)為例，資金對賬項目設(shè)置就是設(shè)置如何將文件里的數(shù)據(jù)解析匯總到對應(yīng)的款項上去的解析規(guī)則，將一個資金賬戶在某一個交易日的資金變動明細(xì)進行匯總，得到每一個款項的變動金額，該配置設(shè)置如圖18所示。

圖18 資金對賬項目規(guī)則設(shè)置

從頁面可以看的出來，該配置中的每一個費用項的配置規(guī)則就是將文件里的數(shù)據(jù)先通過該費用項的“條件組”進行篩選獲得屬于該費用項的數(shù)據(jù)，然后取目標(biāo)數(shù)據(jù)的金額，并且對金額進行運算匯總。比如例子中的第一條就是：取交易狀態(tài)=success的數(shù)據(jù)，取訂單金額作為結(jié)算金額，如表10-5所示為一部分案例數(shù)據(jù)。

通過原型中的配置條件組“交易狀態(tài)=success”，金額配置“正直匯總訂單金額”，可以得到收款=100+90=190。

表5 對賬文件部分?jǐn)?shù)據(jù)

其他費用的配置邏輯類似，一定要枚舉一個資金賬戶里的每一類費用，不能遺漏，不然會出現(xiàn)資金差異。如此全部配置完成以后，一個資金對賬項目就配置完成了，對賬系統(tǒng)會按照配置的時間進行賬單的解析，得到資金對賬所需要的核對源數(shù)據(jù)。

四、對賬引擎

在執(zhí)行對賬前還有幾個重要的問題沒有解決，即對賬的核心處理邏輯，例如對賬的連續(xù)性控制、時間控制、狀態(tài)控制、對賬核心邏輯、對賬結(jié)果查看等。

1. 對賬控制

首先是對賬的連續(xù)性控制，對賬不能跨日，如2號對完才能對3號，如果今天是10號，2號還沒對賬，那么3至9號的賬都不會核對，因為前一天的核對結(jié)果會循影響下一天的核對結(jié)果，這種控制如圖19所示。

圖19 對賬連續(xù)性的控制

其次是對賬的時間控制，如圖10-19所示，系統(tǒng)內(nèi)需要維護對賬的相關(guān)時間，主要是對賬日期、對賬啟用日期、最后對賬日期，他們的含義如下：

• 對賬日期：交易成功時間或者資金變動日；
• 對賬啟用日期：對賬項目設(shè)定的第一個對賬日；
• 最后對賬日期：對賬項目的最后一次執(zhí)行對賬的日期。

然后是對賬的狀態(tài)控制，對賬狀態(tài)即每個對賬項目在每一個日期是否執(zhí)行了對賬，已經(jīng)完成對賬的項目不需要重復(fù)執(zhí)行對賬，除非需要重對，如圖20所示是對賬狀態(tài)的管理頁面。

圖20 對賬狀態(tài)管理

最后是對賬任務(wù)流的控制，控制對賬項目的任務(wù)執(zhí)行，并在流程中更新其他環(huán)節(jié)的相應(yīng)參數(shù)。如果主流程的某一個處理關(guān)節(jié)失敗了，那么應(yīng)該進行任務(wù)報警，人工干預(yù)重啟核對流程，控制流程如圖21所示。

圖21 對賬流程控制

2. 核心處理引擎

對賬最核心的流程就是對賬執(zhí)行流程，實現(xiàn)數(shù)據(jù)間的逐筆核對的過程，如圖22所示。本邏輯流程主要包含三大核心邏輯：實現(xiàn)每一天都完成核對，實現(xiàn)每天的每一個對賬項目都完成核對，實現(xiàn)每一個對賬項目的每一條數(shù)據(jù)都進行了核對。并且產(chǎn)出每條數(shù)據(jù)的核對結(jié)果，是對平、單邊、還是錯賬。

圖22 交易對賬邏輯

舉個例子，經(jīng)過上面的邏輯處理，對賬項目1在x日的對賬結(jié)果如表6所示，其中單號2是對平，單號1和4是單邊，單號3是錯賬。

表6對賬結(jié)果示例

3. 對賬結(jié)果

通過上面的對賬執(zhí)行，就得到了每一個對賬項目的對賬結(jié)果，包括每個對賬項目的對賬總筆數(shù)、總差異。對賬結(jié)果包括交易對賬結(jié)果和資金對賬結(jié)果2類。

交易對賬結(jié)果是交易對賬項目執(zhí)行對賬之后得到的結(jié)果，每個對賬項目按筆數(shù)核對，如圖23所示。從頁面中可以看到每個交易對賬項目的核對日期、總筆數(shù)、單邊數(shù)、錯賬數(shù)、待處理數(shù)等，并且可以查看該對賬項目在該核對日期的平臺明細(xì)數(shù)據(jù)和清算明細(xì)數(shù)據(jù)。

圖23 交易對賬結(jié)果查看

資金對賬結(jié)果是資金對賬項目執(zhí)行對賬之后得到的結(jié)果，每個對賬項目按照費用項核對，如圖24所示。從頁面中可以看到每個核對賬戶在該核對日期的每一個款項是否存在差異，并且可以直接查看到該賬戶關(guān)聯(lián)的交易對賬是否存在差異。

圖24 資金對賬結(jié)果查看

五、差錯處理

對賬有兩個核心目的，一個是發(fā)現(xiàn)錯誤，另一個是改正錯誤，即對賬差異的處理。對賬結(jié)果如果有差異，就需要有排查差異的原因，差異原因千奇百怪，但存在必是有原因的，如果暫時查不到具體原因就先掛著，至少我們知道了有一個差異待處理。

差錯處理就是消除差異的過程，主要包括發(fā)現(xiàn)差異、排查原因、處理方案制定、消除差異等環(huán)節(jié)：

• 發(fā)現(xiàn)差異：對賬對出了差異；
• 排查原因：排查差異原因，是掉單了、bug、時間差還是其他原因；
• 處理方案：制定差異處理方案，如時間差造成的不用處理，等待第二天對平；
• 消除差異：這一步是在對賬系統(tǒng)對差異進行標(biāo)記處理，說明差異已經(jīng)處理完成了。

1. 交易差錯處理

交易對賬是交易數(shù)據(jù)的逐筆核對，會出現(xiàn)對平、單邊、錯賬等三類結(jié)果。對賬的差異會單獨出現(xiàn)在差異列表等待處理，如圖25所示。

圖25 交易對賬差錯處理列表

點擊處理，在彈窗中選擇處理類型，提交之后可以走一個設(shè)定好的流程，也可以直接處理完成，如圖26所示。

圖26 差錯處理操作彈窗

其中差錯處理類型就是我們要用什么樣的方式消除了差異，比如如果是銀行成功，我方掉單了，那么就進行補單，補完后就對平了，這樣也是保證用戶的權(quán)益。因為是我方掉單了，所以對賬結(jié)果是銀行單邊；等我方補完單后，銀行的這筆單邊就處理成“平臺補單”。

系統(tǒng)可以預(yù)設(shè)一些差錯處理類型，設(shè)定每個類型的處理流程，便于在處理的時候直接選擇使用，如圖27所示。

有些差錯處理可以實現(xiàn)自動化，讓相關(guān)系統(tǒng)包裝接口直接進行調(diào)用處理，比如平臺補單可以讓訂單系統(tǒng)包裝一個補單接口，對賬系統(tǒng)直接調(diào)用進行補單。

圖27 差錯類型管理

2. 資金差錯處理

資金對賬的差異是費用的差異，即收款、退款、手續(xù)費等于平臺記錄的不一致。資金核對完成得出結(jié)果后，如果不是解析等技術(shù)層面的差異，可以對結(jié)果進行一個確認(rèn)，確認(rèn)之后差異會生成長短款數(shù)據(jù)，后面對長短款進行排查原因、進行核銷。資金對賬結(jié)果詳情頁面如圖28所示。

圖28 資金對賬結(jié)果詳情

什么是長短款呢？比如微信的一個資金賬戶，資金同事直接在微信商戶后臺操作了一筆轉(zhuǎn)賬，或者用戶直接用微信轉(zhuǎn)賬100元給了這個賬戶，這時候就會出現(xiàn)微信收款比平臺記錄收款多的情況，即微信賬單的收款總額比平臺的記賬總額多100元，資金對賬就會發(fā)現(xiàn)這100元的長款，就是渠道多收了。

但經(jīng)過排查是可以找到這個具體原因的，本質(zhì)上是平臺沒有獲得這筆轉(zhuǎn)賬數(shù)據(jù)，也就無法記錄，通過排查可以操作核銷差異。

確認(rèn)結(jié)果以后，長短款模塊就會生成一筆該賬戶的 100元長款記錄；長款記錄要有賬戶信息、對賬日期信息、費用信息等，如圖29所示。

圖29 長短款核銷管理

點擊核銷可以對該筆差異進行核銷處理，在彈窗里選擇相應(yīng)的核銷類型，本次要核銷的金額，同時也可以選擇與前期其他差異進行雙邊核銷，如圖30所示。

圖30 長短款核銷處理彈窗

長短款差異生成的同時也會生成對應(yīng)的賬務(wù)憑證，算是一個掛賬憑證，為了讓賬務(wù)是平衡的，后續(xù)針對每筆資金差異進行排查核銷，比如如果確認(rèn)是人工微信做了轉(zhuǎn)賬，那么可以直接核銷“資金人工轉(zhuǎn)入確認(rèn)”，直到長短款沒有待核銷為止，資金就是準(zhǔn)確的了，每筆核銷都需要生成核銷記錄，如圖31所示。

圖31 核銷記錄

六、坑位解析器

獲取文件并解析文件是對賬系統(tǒng)非常重要的環(huán)節(jié)，也是后續(xù)進行對賬的基礎(chǔ)。因此，解析文件是對賬系統(tǒng)設(shè)計中非常核心的一部分，上文中所采用的是原樣解析文件數(shù)據(jù)，本小節(jié)將提供另一種解析模式做為補充。

為什么叫坑位解析器呢，因為本模型的數(shù)據(jù)庫表是固定的，而是將文件數(shù)據(jù)按照對應(yīng)關(guān)系解析到固定的字段上去。

對賬所需要解析的文件主要有三類：平臺的支付數(shù)據(jù)、渠道的清算數(shù)據(jù)、渠道的結(jié)算數(shù)據(jù)，其中，平臺數(shù)據(jù)可以通過SQL、MQ、接口、文件等形式獲取，而渠道文件一般會通過接口獲取，或者人工下載文件以后導(dǎo)入到對賬系統(tǒng)內(nèi)，如圖32所示。

圖32 坑位解析器模型

交易對賬主要核對平臺的支付數(shù)據(jù)記錄與渠道下發(fā)的清算文件中的記錄的一致性，而平臺數(shù)據(jù)可以通過SQL獲得，而清算數(shù)據(jù)可以通過接口獲得，獲得文件以后進行解析，對賬項目、文件、解析器之間的關(guān)系如圖33所示。

圖33 解析器關(guān)聯(lián)關(guān)系

一個對賬項目的解析器和清算文件是綁定關(guān)系，這樣就意味著該對賬項目的清算文件是由該對賬項目綁定的解析器所設(shè)置的規(guī)則進行解析。如何設(shè)計配置工具呢？如圖34所示是某支付渠道的清算文件示例。

圖34 清算文件示例

文件中的商戶訂單號是平臺的請求唯一單號，也是渠道數(shù)據(jù)與平臺數(shù)據(jù)進行核對的唯一標(biāo)識，所以要解析出來，另外的交易狀態(tài)代表了退款和支付類型，后面還有金額等對賬需要的字段都需要解析出來。

如何設(shè)置將這些字段解析到數(shù)據(jù)庫表中的規(guī)則，就需要用到如下的配置工具，如圖35所示。

圖35 解析器配置頁面

其中基礎(chǔ)配置是配置該解析規(guī)則的基礎(chǔ)信息，主要配置實現(xiàn)“我們需要哪些數(shù)據(jù)”，比如解析器的編號，所屬對賬項目，文件的格式、編碼等內(nèi)容。

過濾字段設(shè)置的是“哪些數(shù)據(jù)不要”，比如示例中的含義就是通過文件中的第9列和第10列進行過濾，第9列是“未知、失敗”或者第10列是“01”的數(shù)據(jù)不需要進行解析。

數(shù)據(jù)開始行的用途是指定從哪一行開始解析，因為有些渠道的文件開頭有表頭或者有些統(tǒng)計類信息不需要解析，應(yīng)該刨除掉，如圖36所示的文件就應(yīng)該填“6”，從第6行數(shù)據(jù)開始解析，前5行數(shù)據(jù)不需要。

數(shù)據(jù)列數(shù)的配置用途其實也是用于設(shè)定解析哪些數(shù)據(jù)，可以跟“數(shù)據(jù)開始行”的配置同時使用，屬于加強條件，比如填寫了“12”，就代表只解析哪些有12個字段的數(shù)據(jù)行。

圖36 結(jié)算數(shù)據(jù)示例

然后是解析規(guī)則的配置，這部分是規(guī)則部分，主要是配置文件中的“數(shù)據(jù)如何放到數(shù)據(jù)表里”的問題。

配置一共有3列：第一列是數(shù)據(jù)庫表的固定字段，例如銀行訂單號、交易類型、卡類型等；第二列是字段位置，也就是這個字段取文件中那一列的數(shù)據(jù)，比如原型中銀行訂單號填寫的是1，就是將文件中的第一列解析到銀行訂單號；第三列是說明文件中的數(shù)據(jù)格式、單位或者數(shù)值。

需要強調(diào)的是，整個規(guī)則配置主要可以分3大類：

• 第一類是取數(shù)型配置，如銀行訂單號等，只需要填寫數(shù)據(jù)列“數(shù)”即可，不需要配置格式、單位、數(shù)值，直接將文件中的數(shù)據(jù)取過來即可。
• 第二類是映射型配置，如交易類型、卡類型，二者在數(shù)據(jù)庫里是固定的枚舉值，分別是“支付、退款”、“借記卡、貸記卡”，原型示例的配置含義是卡類型根據(jù)第“13”列判斷，如果是01則代表借記卡、02代表貸記卡，解析到數(shù)據(jù)庫里時，卡類型字段會設(shè)置成“借記卡”或者“貸記卡”，而不是文件中的數(shù)值；同樣原型中的交易類型字段，由第“10”列決定，當(dāng)是“S13、S22、S23、S36、S37、S46、S54、S56、S64”時代表支付，當(dāng)是“REFUND”時代表退款。
• 第三類是單位和格式型配置，比如原型中的金額需要配置文件中是什么單位，時間要配置說明文件中的時間格式是什么。