筆者目前就職于一家中型的互聯網金服企業 ， 公司提供全鏈路的風控信貸服務，主要通過售賣數據產品和提供本地化系統部署服務獲得盈利 。公司內部自研的系統超過100多個，包括支持性業務系統及職能系統等等，本文將以筆者負責了2年多的賬務系統來分享一些工作經驗心得，希望可以幫助大家對業財領域的產品設計提供些思路和借鑒 。
一、項目背景介紹
1. 業務背景
筆者公司的業務模式具有一定的獨特性，不同于我們常見的市面上供應鏈類公司的進銷存模式 。公司主要為各大銀行和金融機構提供信貸領域的風控服務，客戶主要通過請求公司的數據產品接口產生費用，可以簡單地理解為請求一次接口收費0.5元 ， 一個月若是有1w人請求同一個接口則公司需要收費5000元 。2. 業務核心痛點
- 如何將請求的不同的產品的計費量與單價進行匹配出具賬單？
- 出具賬單后如何與客戶進行對賬？并且能夠有留存？
- 與客戶對賬無誤后，如何通過系統為客戶開具服務發票？
- 客戶收到發票后進行了打款，如何將賬單、發票、回款進行一一關聯和匹配呢？
- 有了賬單、發票、回款信息后，如何通過這三類基礎要素統計各種維度的財務分析匯總報表呢？
3. 系統定位
根據上面提到的業務背景和業務痛點，我們基本就能夠明確系統的基本定位，以及需要支持的業務功能和流程，概括來講的話 ， 系統定位為：集合了賬單、開票、回款、財務報表的全流程一體化管理系統 。
二、系統業務流程說明
上圖為筆者繪制的一份簡版的賬務系統的核心業務流程圖 ， 通過這張圖我們來拆解每個業務模塊 。
1. 創建計費單
計費單顧名思義為用來計費的單子，在這個單子里將包含的需要計費的信息，從流程圖中我們可以看出計費單的上游業務是CRM的合同，也就是說其實計費單的計費信息最初來源于客戶與我司簽署的合同，則計費單是將合同中有關計費的信息進行了提煉和轉換 ， 通過計費單去作為后續出具賬單的依據和憑證 。在計費單中包含產品信息、單價信息、計費方式、賬號信息等等 。
2. 生成賬單
賬單的上游業務是計費單，通過計費單我們就能知道賬單中需要包含的每個產品的計費方式和單價等基礎信息，則只要再有了每個產品數量（調用量），就可以為客戶出具完整的賬單 ， 那么調用量則是來源于BI系統的調用日志，在觸發重跑賬單時，將計費信息和調用量進行匹配和組合，最終生成賬單 。通過上述兩個步驟 ， 來解決我們剛才提到的業務核心痛點1 。
3. 賬單確認核賬
當有了賬單之后，就需要考慮如何與客戶進行對賬，那就到了解決業務痛點2的時候了 。在之前線下業務模式中 ， 我們調研到銷售同事是跟客戶通過公司郵箱發送賬單的方式來展開對賬工作，這樣的方式放在系統上來進行也是非常方便的，同時也符合他們之前的工作習慣，于是我們決定在賬務系統上支持每個客戶的賬單通過系統來發送到客戶郵箱中 。系統在發送時會附帶好賬單，通過在系統中維護好收件人即可，郵件發送后若客戶回復郵件 ， 系統可以抓取到回復郵件自動帶回到賬單中，便于銷售同事進行確認核賬 。
4. 申請開票
當賬單確認核賬后，一般客戶就會要求我司為其開具相關服務發票，客戶見票回款 。開具發票是賬務系統中使用最為頻繁的功能模塊之一，也有著比較復雜的邏輯處理 。目前我們賬務系統在開票時包含多種類型，將會在下面展開來講 。5. 拆分回款
為客戶開具發票后，客戶一般會在約定的幾個工作日后進行回款，賬務系統與主流的各大銀行做到了銀企直連，客戶進行銀行打款后當日也會回傳到賬務系統，則銷售同事通過操作賬務系統將回款進行拆分，同樣在拆分回款時也包含多種類型，將會在下面展開來講 。6. 賬戶
每個客戶在我們的賬務系統都擁有自己的賬戶 ， 在賬戶中管理著每個客戶的余額及對應的每筆收入和支出的流水，當然有的賬戶中可能還會產生壞賬或人工調整金額等，總之所有會影響的客戶余額的操作都會在賬戶中體現出來 。在確立賬戶時，需要明確賬戶的維度，是客戶維度還是客戶+業務線維度，亦或是客戶+業務線+產品維度等等 。
這里的主要提下賬單產生的負向支出和回款的正向收入 。當賬單核賬后，系統會生成對應的支出扣減的流水 ， 客戶的賬戶余額減少；當客戶回款后拆分完成，系統會生成對應的一筆收入的流水，賬戶余額增加 。
7. 賬單開票回款關聯表
這部分在流程圖中即是筆者用淺藍色的長框框住的部分，是將賬單、開票、回款三個表進行了關聯匯總，此表在后續的財務數據的統計中經常會作為中間表用到，比如計算哪些賬單是已開票已回款或者已開票未回款，哪些預付回款已開票，哪些預付開票是否回款等等，通過這張表可以得知各類的信息，為財務報表統計提供基礎數據 。8. 財務報表統計
財務報表的統計是根據實際業務場景產生的，就筆者公司而言，目前在賬務系統中已上線的財務報表包含：封賬統計報表、包年權責報表、客戶賬齡表、客戶逾期表、逾期匯總表、財務賬齡表、財務收入大表、項目類收入表等等 。每個報表的處理邏輯和方法都是不一樣的，在接到財務報表相關需求時，需要捋清楚報表內的每個字段的計算邏輯，更重要的是財務報表是依據財務維度出具的，在理解每個字段背后的含義時 ， 需要結合一定的“財務原則”，不然很容易出現“我以為你說的這個意思啊”這樣的場景 。
三、系統核心元素關系
簡單來說，賬務系統核心元素主要就是三個：賬單、開票、回款，在這三個元素中最核心基礎的當然是賬單 ， 其他的功能或者報表都是基于這些基礎元素進行的延伸和拓展，所以我們需要先搞清楚這三者之間的會產生的哪些復雜的關聯關系 。1. 賬單
賬單是開票和回款中間的橋梁 ， 橋梁的作用體現在，開票時需要關聯賬單，回款時也需要賬單 。2. 開票
我們根據業務需要，支持針對產生的賬單進行開具發票，在開具發票時必須選擇賬單，可開票的金額需要小于等于當前的賬單的金額；另外一種開票的業務場景為，客戶還未在我司產生賬單，也沒有預付款，但是需要我司提前進行開票，則如果只支持客戶對賬單進行開票，顯然無法適配當前的業務場景 ， 那么系統需要支持無賬單下開票，確定好需要開票的業務線即可；
但同時也會有客戶預付款的業務，同樣還未產生賬單 ， 則此時需要支持按照預付款進行開票，在開票時必須要選擇客戶的某筆回款進行開票 。
3. 回款
當客戶進行回款后，需要將回款拆分到對應的賬單或者開票，如此來讓賬單、開票、回款三三者之間關聯起來 ， 最理想的數據情況則為，此賬單已開票已回款 。1）回款拆分到賬單
將回款關聯拆分到對應的賬單，給每個賬單分配回款金額 ， 直到該筆款的回款金額分配完 。
2）回款拆分到開票
如果先對賬單進行了開票，客戶的回款對應某張開票，則此時通過將回款關聯拆分到開票是最方便的 ， 直接為開票分配回款金額即可；但是這里需要注意到回款雖然是表面上拆分給了開票 ， 如果該張票當時是開到了賬單上時，則在回款拆分到開票時，系統需要同時將回款金額分配該張票底層的賬單上 ， 這樣才能保證賬、票、款一致 。
3）回款拆分到預付
針對客戶先打款后產生賬單的業務類型，系統支持提前將回款的拆分到預付回款下，在拆分時不需要關聯賬單和開票，只需要確認好每條業務線需要分配的回款金額 。
四、賬務系統架構
上圖為筆者繪制的一份簡單的功能架構圖，基本包含了目前賬務系統核心的業務功能，可以將該圖與流程圖結合起來理解 。
五、一些踩過的“坑”吧
1）賬務系統中的必然會出現大量的數字，是實打實跟數字打交道的系統，在最初設計時一定要考慮清楚數值的類型，是采用double類型、float類型還是別的類型 ， 最終的目的是保證系統在數值的精確度上是始終保持一致的，在這件事上我和我的團隊是吃過虧的 。2）賬務系統的各個模塊的數據和功能的串聯型與關聯度是非常高的，舉個例子來說 ， 當你發現某個財務報表的某個字段統計計算有誤，很可能是因為最初在賬單已經出錯，進而導致開票有誤、回款有誤、關聯表有誤，最終導致報表有誤 ， 因此需要考慮在設計各個模塊時耦合度的問題 。
3）一般新系統的在上線時，都會需要處理歷史數據 ， 賬務系統也不例外，尤其是針對各種期初數據的導入和處理是比較多的 ， 而且相關人員在給到我們數據時，往往是無法一次到位的，少不了在后續多次的修改和調整，然后再由我們的研發人員執行sql 。
因此針對這類問題，可以考慮增加一些修改期初數據的功能，雖然我之前一直認為這樣地低頻的導入期初數據的操作不需要做成系統功能，但從實際來看并非完全如此 。
【如何搭建企業級賬務系統？看這篇給你思路】
