開發FMS財務管理系統，每天都會與數據打交道，數據的核對與處理是日常工作的一部分，相信接觸過財務系統的同學都深有感觸，為了一個差異查來查去，最終發現是前端業務系統的問題，白忙一場，本篇就說一下關于財務數據核對的過程與方法，希望讀后有所幫助！

一、系統數據生成過程

對于財務管理系統的數據是通過前端業務系統的數據進行抽取、計算、匯總生成的，其中又包括財務結算、付款、收款等核銷過程，數據的準確性是第一位的。

之前曾整理過數據核對的內容，這里回顧下幾個原則：

1. 三個原則

（1）財務數據的生成原則

從業務單據明細->財務明細->財務匯總，即從細到粗的順序生成。

為什么這么做?

因為在抽取財務相關數據時，有時候為了方便可以從業務相關的統計查詢報表中獲取數據，這樣能減少很多工作（不需要了解具體的邏輯）。

但是如果這樣設計就使得財務的數據過度依賴于前端業務系統，當業務系統的報表邏輯口徑有變化時或不需要是就會影響到財務數據，所以我們應該盡可能的抽取相關明細的數據以防止過度耦合。

您可能說即便單據也會有變化，沒錯，但我們的原則是盡可能減小這種差異的產生。

（2）財務核對數據的原則

從財務匯總->財務明細->業務單據明細　即從粗到細的順序核對。

為什么這么做？

因為如果您核對數據時先從最細粒度的去核對，那么數據量是非常大，計算量可能是成指數級遞增。

所以我們一定要先核對總數，總數有差異再核對明細，一層層的向下鉆取直致查詢到具體的問題數據。

我一直堅持在財務系統中的數據要分層，每層都要保留明細，當本層數據無誤后再進行下一層數據生成。

（3）數據勾稽關系如何設計

了解報表的生成邏輯，先從各報表中相同的數據項進行比對，然后再根據報表間計算規則進行比對。

舉個例子：銷售收入成本報表中收入－成本＝毛利；存貨平衡表中有商品的成本，這里銷售出庫、銷售退貨、銷售補發等成本的合計應該與收入成本報表中的成本數能夠勾對上；如果不相對，那我們系統肯定有問題了。

在開發報表中要了解報表中各字段的統計時間口徑及相關其他條件，這是設計勾稽關系的前提。

2. 理解數據依賴關系

這里最重要的是數據勾稽如何確定，需要產品研發同學非常清晰的理解相關數據的依賴關系。

首先，從系統的角度來考慮，先要保證數據的產生是正常，每天有很多定時任務在運行，要先確定各服務的依賴關系。

這和分布式服務（通過spring clound等來實現，但要防止循環依賴）中服務依賴還有點區別，這里更多的是指數據上的依賴。

1. 通過消息來實現服務間的解耦，一個服務執行完發條消息到MQ,訂閱者開始執行即可；
2. 如果不通過MQ，可以采用最建立一個服務調度狀態表來實現，設計好服務間的依賴關系，每個服務執行前循環掃描此表狀態，如果依賴的服務都執行完畢，則執行（參照下表）。

其次，從數據的完整性和準確性上考慮。

這里涉及一個設計原則，既當服務在執行過程中出現了異常，是終止還是繼續執行？

• 終止：后續依賴的任務都不會執行，系統產生不了數據，影響業務使用系統。
• 執行：有了異常數據，繼續執行后依賴的數據也會有錯誤，業務雖然能夠使用，但是會錯上加錯。

當這種問題出現后，相信多數人都會采用終止執行，由研發同學盡快解決后再繼續。

其實這個問題有點類似于大促活動時服務降級策略；在系統設計過程中是務必要考慮的。

FMS財務管理系統的數據不像前端業務生產系統實時性要求那么高，所以一般情況下可以根據數據的使用用途來劃分，原則上以數據的準確性為第一原則。

• 報表統計分析來數據，可以繼續執行；有數據參考比沒有數據要好，雖然有部分是錯的。舉個例子：公司老板每天必看的報表（一般都是匯總類數據），提供比不提供要好。
• 財務業務單據類數據，終止，等待處理后再執行。舉個例子：應付結算單，如果產生了錯誤數據應會影響到付款，此時不執行比執行要好。

最后，數據重算機制

數據有問題或異常了，要考慮重算或補償機制，保證數據準確性和完整性。

重要的服務，盡量不要借助人工處理，要寫程序來完成。

舉個例子：財務成本核算服務每天要根據出入庫流水進行成本計算（移動加權或先進先出等），出現異常了，一定要寫重算的過程，否則后續處理問題時相當麻煩。

其他的每層數據的生成時都應該考慮，人工和系統結合的方式來解決問題。

二、數據核對過程

對于數據的核對需要借助于核對平臺，按數據“匯總－〉明細”的過程進行。

我個人的處理原則還是先在數據庫層面利用SQL來進行核對，然后借助于系統出具核對結果。

1. 為什么這么做？

因為財務庫的數據是獨立的，而且不會影響到前端業務生產庫，可以充分利用腳本來進行。

這里我們可以開發一些定時任務服務來進行對財務數據進行匯總核對。

2. 核對的內容和方式

這個核對對于業務生產與財務抽取間既要核對數據條數，也要核對數量與金額等關鍵數據，防止數據的丟失和異常。

其它層級間主要是核對數量與金額，最復雜的是財務報表間的核對，要明確勾稽關系（這部分在設計報表時就需要確定）。

• 核對系統：以上的核對至少要做一個核對界面，每天來查看服務的執行狀態（在數據庫中查詢也可以），查看核對的數據間差異，需要設置閥值，對于超過閥值的要高亮顯示。
• 手工核對：對每日的核對結果提前寫好腳本，每天進行查看。

對于相關的預警，譬如服務假死，我們可以通過監控此服務產生的數據行數來判定。

出現異常后，產品研發還是應該及時處理，終止未執行的服務，解決后再啟動，降低整體數據生成的時間，保證業務每天早上都能快快樂樂的使用系統，提升產品研發的高大形象。

3. 財務數據核對誤區

作為研發、產品我們在設計核對平臺時，都希望開發一個牛逼的系統，引入了規則引擎、大數據計算等技術，利用一個當前很流行的框架。但這樣做好嗎？

個人不贊成這樣去做，我個人覺得可以在數據庫層面利用腳本或存儲過程核對的，就不要寫程序（財務庫不像各個業務生產庫對讀寫要求非常高可以用存儲過程等技術） ，可以用簡單的技術實現的，不要引入過多復雜的技術（可以適當使用），降低開發成本。

最后介紹幾個，本人在日常工作中的幾個數據處理的小方法，供大家參考。

三、數據核對的幾個小方法

1. 利用Excel的公式來核對

主要是使用VLOOKUP公式進行，這個公式比較強大。

場景：從兩個不同的數據庫中來對比差異（兩個庫不能聯合查詢，也沒有建立DBLINK）。

樣例數據D1：

目標數據D2：

根據城市、月份從D1中查詢出對應的銷售額，并得出差異。

方法：在源數據列中輸入公式：

=VLOOKUP(F2&G2,IF({1,0},Sheet3!$A$2:$A$6&Sheet3!$B$2:$B$6,$C$2:$C$6),2,0)

然后按CTRL+SHIT+ENTER組合鍵，再下拉即可。

2. 利用Excel與數據庫腳本結合

場景：業務提供一個EXCEL，需要技術從數據庫后臺根據訂單號獲取其支付時間與發貨倉庫。

數據文件：EXCEL,樣例數據如下

處理方法：通過拼接SQL方式去獲取數據，這里的方法是和一位同事學習的，百試百靈。

1）先要插入一個關鍵字段，作為Excel文件中的一個主鍵，自增數字即可，然后拼寫SQL。

2）將數據粘到文本中，去空格操作。

結果如下：

3）在數據庫中拼寫SQL，執行，注意這里就用到 order bykey_id進行排序了，保證輸出的結果與Excel中的順序一樣，方便粘貼

4）將結果粘貼到Excel中進行處理（單元格設置為文本格式），注意key_id要與源數據增加的相同。

3. 利用數據庫進行大批量數據核對、檢驗及處理

場景：業務提供一份幾十萬行的Excel文件數據（一般為CSV），需要技術在后臺進行核對處理，并反饋出差異結果。

方法：由于數據量太大，此時不能利用方法一與方法二了，一般研發同學習慣于根據需求邏輯寫個程序來進行處理，這里我習慣于利用數據庫的SQL來核對處理，具體如下。

1）前提，本地機器上需要安裝一個數據庫，Mysql、SQLSERVER等都可以，如果有公共的測試數據庫且有創建刪除表權限的也可以，以MySql為例。

2）將數據文件導入到本地庫中，Navicat中的導入工具可以用，這里用腳本。

3）首先創建一個表（根據數據文件進行創建），例如腳本如下：

4）數據文件保存成txt格式的文本。

5）導入數據到本地庫。

腳本如下（語法可以百度一下load file）：

6）將所有需要的數據導入到本地庫，你就折騰吧。

這里可能需要生產庫的數據，如果不涉及敏感信息，你這可以從生產中導出，再導入到本地庫中進行與其它數據進行關聯查詢等。

其他數據庫也是同樣的過程，SQLServer的客戶端功能強大，導入導出的工具很方便，Oracle可以利用SQLLoader工具來導入，導入百萬級數據大約十幾秒的時間，非?？?。

如果需要的生產數據復雜，可以借助其它工具，例如Kettle，但這個需要安裝，還要申請一些聯接生產庫的權限才可以使用。

注：對于數據和創建表都要注意編碼格式，正常都采用UTF8

4. 寫代碼，利用程序來實現

這種方法我是極力不推薦的，不到萬不得已，盡量不要寫程序來完成大批量數據的處理與核對。

原因如下：

1. 這種需求一般都是臨時性的，對于源文件數據是否可以導入到生產，這個一般不允許；
2. 程序需要連接生產庫，需要創建項目，部署；通常開發環境與生產環境都是隔離的；
3. 即便都可以在本地進行，但程序的邏輯要進行設計，如果調整不如腳本方便快捷。

總結

敏捷項目管理中提到，借助于有效的工具來提升研發效率是一個非常不錯的選擇。

在財務數據日常的核對處理時，可以借助各種工具來完成工作，但是過度的依賴最新的技術來完成簡單的工作又會有種殺雞用牛刀的感覺。

簡單有效直接是行之有效的方法，通過總結，開發有效的工具是目標。

最后感謝您的閱讀！

作者：倔強的大蘿卜；公眾號：倔強的大蘿卜

本文由 @倔強的大蘿卜 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議