本文作者所在的公司提供全鍊路的風控信貸服務，主要通過售賣資料産品和提供本地化系統部署服務獲得盈利，這篇文章總結了他負責賬務系統的工作經驗和心得，希望能幫你對業财領域的産品設計提供些思路和借鑒。
筆者目前就職于一家中型的網際網路金服企業，公司提供全鍊路的風控信貸服務，主要通過售賣資料産品和提供本地化系統部署服務獲得盈利。公司内部自研的系統超過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。
是以針對這類問題，可以考慮增加一些修改期初資料的功能，雖然我之前一直認為這樣地低頻的導入期初資料的操作不需要做成系統功能，但從實際來看并非完全如此。
本文由@Joysaver🏁 原創釋出于人人都是産品經理，未經許可，禁止轉載
題圖來自 Unsplash, 基于 CC0 協定
該文觀點僅代表作者本人，人人都是産品經理平台僅提供資訊存儲空間服務。