本期LOG引言
很多產品汪肯定經歷過財務板塊的設計，常見的財務板塊應該有哪些功能，內容，並讓公司財神爺對連連稱讚？本期LOG將從基本概念，業務邏輯與關係兩方面帶你掌握財務板塊的業務內容與產品設計。。
1、基本概念
- 財務管理板塊的存在是讓整條業務線的資產投入與產出更明確，讓CFO一線掌握某業務線的運轉情況以做未來的業務線財務規劃；
- 幾乎市面所有產品都會存在資金流一說，除非這款產品是純工具且不具有資金流板塊，功能或線下實現資金流的；
- 出色的財務管理功能應具備源頭可查，去向可查，稅務可查，業務可查；
- 如產品或歸屬公司不具備金融資質或相關拍照的，原則上同一用戶賬號（體系）不能進行即充值又提現業務；
- 產品如涉及與用戶簽訂相關協議（比如，勞務，共享，偶然），則用戶在進行相關提現操作時應遵循相關法律法規，並進行稅務代扣代繳；
- 基於第“5”條，如公司財務對這塊明確了不用代扣代繳的，請務必問清楚原因，否則將會把公司往違法的路子帶，且產品設計者本身也難脫干係。
2、業務邏輯與關係
按目前我們常見的產品種類來劃分，並對這些種類中涉及與財務板塊相關的內容做下解析。
1、直營電商類
這裡就不拿B2B2C的電商業務來講了，我用圖來表述直營的商品，訂單及資金關係。這裡拿相對通用的來講，涉及到運營板塊（比如，優惠券抵扣邏輯，虛擬活動比抵扣獲利，團購邏輯，拼單邏輯等及註冊的功能就先不講了。
用戶創建訂單並未支付時，這類訂單可單獨劃入一張數據表中存儲與其他訂單狀態的數據表分開，這麼做可以避免惡意下單導致的數據庫崩潰。用戶完成支付後，行程訂單流與資金流，這裡的資金嚴格意義上其實還不歸平臺所有（跟財務確認下），屬於待入賬的資金流，在財務管理系統中需要做下區分。
平臺發貨後對應的資金流毅然是未入賬，當且僅當用戶確認收貨後的n天后，資金歸平臺所有（已入賬）。
那，這裡的規則是基於電商規則來的，在發貨途中用戶有可能發起退款，所以這裡的資金不建議做成已入賬。
像這類直營電商類的產品，相對在資金流及財務板塊的延展性是比較簡單的，只涉及到了交易流，並未涉及到用戶的提現流（充值流是會存在的，用戶支付訂單可以看做是一種充值流）
在訂單信息中，明確用戶信息（id，手機號等），支付信息（接第三方的拿第三方返回的訂單信息就好），商品信息及物流信息，如有活動的單獨歸類並與支付信息關聯。
如平臺做推薦功能的，可基於用戶所有訂單的關鍵字，結合平臺營銷策略去做商品推薦，以促成更多的訂單轉化。
2、社交類（含提現，稅費）
社交類產品多含虛擬貨幣，用戶購買貨幣並用於平臺用戶之間的相互流轉（注意，購買虛擬貨幣在ios上與安卓是有明顯區分的，且虛擬貨幣在提現時不得1：1提，做產品設計時建議諮詢公司法務），涉及到了衝轉提三個流
- 用戶充值：視為用戶購買平臺的商品，原則上平臺需向用戶開具對應金額的發票；
- 用戶流轉：即將已購買的商品贈送給別的用戶（比如主播），一般這種贈送類的業務模型，屬於偶然所得，被贈送的用戶在進行提現時需按提現金額的20%繳納稅費或平臺代扣代繳；
- 用戶提現：從合規的角度來講，用戶在提現時需與平臺簽訂相關協議，協議類型的不同，用戶提現時所需扣除的費用也不同。
上述3點都是站在合規的角度來分享的，如業務涉及到相對敏感的內容，務必與業務部門做好溝通，並在設計時去規避這些問題。
在財務管理-用戶提現板塊，常見的信息需包含，用戶的認證信息，銀行卡/支付寶信息，相關時間信息。 注意 ，按一般公司的財務要求，用戶提現的賬號需與用戶信息一致，如允許用戶提現到不同賬的，注意規避相關資金安全風險並明確告知用戶。
3、額外BiBi
財稅模塊比較敏感，線上環境的使用權限盡量僅向財稅部門開放，如涉及用戶諮詢的，不想打擾到財務的，可通過用戶管理與財稅管理數據對接的方式來實現查詢，比如用戶信息用可將用戶錢包的詳細變更數據加入，在訂單管理中將資金信息加入等等方法。
公司財務相對薄弱的（一般不太可能），或對互聯網接受程度很低的，以磨合為先，切記不要強壓財務去符合你的要求。
最後一句.. 財稅是一家公司的命脈，及其敏感，並且與多個業務流並存，所以只要涉及到資金流相關的業務，在需求收集與分析階段，務必將財務與需求部門拉到一起..
閱讀更多 大大鋼 的文章
