筆者前面介紹了FMS財務管理系統相關邏輯結構，本篇文章繼續對應收管理進行了系統的介紹，希望通過此文能夠加深你對FMS財務管理系統的認識。

上一篇主要介紹了財務進銷存系統的數據流與模塊組成，知道了FMS系統中數據的來源并從系統結構上說明了打造一個財務系統不僅包括用戶直接使用的系統，它更多的是財務數據層層流轉以及數據的核對、計算及業務操作流程。

從開篇就一直說FMS是一個業務系統，現在開始逐一介紹下每個模塊，與大家共同探討學習，本篇主要介紹一下應收管理。

一、應收

先回顧下什么是應收？

應收是指企業在正常的經營過程中因銷售商品、產品、提供勞務等業務，應向購買單位收取的款項，包括應由購買單位或接受勞務單位負擔的稅金、代購買方墊付的各種運雜費等。

在電商系統中主要是指賣給第三方用戶（C端和B端）商品或服務取得的賬款；對于預付貨款在財務中屬于“應收”，待結算后會進行結轉，具體看財務業務要求。

需要說明一下后續我們所說的應收都是指主營業務部分的。

在我接觸的電商系統中的應收主要包括兩部分

（1）ToC端用戶訂單的應收管理（無銷售類合同）

主要包括C端用戶的銷售訂單、銷售退貨訂單；雖然目前都采用在線支付了很少有COD的支付方式了，但是用戶都是通過第三方支付付款的，所以此部分涉及第三方支付平臺的應收款與對賬。

（2）ToB端用戶訂單的應收管理（有銷售類合同）

大客戶訂單作為一種特殊銷售單據，一般都是市場部與大客戶簽訂了銷售合同采用賒銷的方式，根據規定賬期財務進行收款并計算銷售提成。

下面我們分別介紹下這兩種場景。

二、ToC端訂單流程

我們仍然先看一張圖（如下）：

1. 訂單（或其他業務單據）

這里是指關于主營業務收入的單據，一般是銷售訂單、補發訂單、換貨訂單、銷售退貨訂單等。

面對的用戶如果是B2C則是指C端用戶，如果是B2B則是指B端用戶，本人沒有參與過太多的B2B業務，所以只以B2C的為例說明。

在這里如果有賒銷業務（如大客戶業務），那么還應該考慮到賒銷的收款方式，這也是應收賬款中很重要的一部分。對于補貨及換貨一般應收金額是零，銷售退貨則會退款給用戶（通過原路退回或非原路退回）

2. 支付方式

訂單的支付方式是非常重要的一部分，購物流程中的支付環節是非常重要的，如用戶下單后是立即支付呢，還是延遲支付（可能有事或要再確認）；如果沒有立即支付，我們的訂單給用戶保留多久合適呢？這又涉及訂單取消的環節，一般像外賣是保留15分鐘，一般的B2C訂單是保留30分鐘。超過時間訂單會自動取消，這些都應該以業務情況及用戶體驗而定。

隨著技術和支付的便利性，現在采用貨到付款（COD）的不多了，但在有些電商網站中仍然保留了貨到付款的方式，主要是為了獲得更好的用戶體驗。

采用不同的支付方式可能就會涉及多個交易公司，如支付寶、微信、銀行、京東支付等等。

3. 第三方支付公司

前面說了支付方式，如果是采用在線支付則需要調用第三方支付公司的接口，這在支付流程中需要由前端系統對接（一般支付接口都會統一對接）。

對于支付的數據分為兩種即收用戶的款與退客戶錢，此時我們的業務系統都需要詳細記得交易流水號，業務單據號，支付金額、支付時間，交易公司代碼等等，我們稱之為支付交易流水；同時支付交易流水要與訂單（業務單據）關聯綁定，尤其是支付狀態的回傳是否及時，系統中還需要進行冪等性較驗。

4. 代收款公司

對于貨到付款的訂單就會涉及到代收貨款，一般由快遞公司來協助完成。雖然是貨到付款，但是采用現金支付的情況已經非常少了，快遞公司都有手持，當客戶簽收時則利用手持POS進行收款（通過刷卡、微信或支付寶）。

雖然采用刷卡或微信、支付寶，但與第3步中的不同，此部分款項收到快遞公司的賬戶中，我們一般會與快遞公司進行月結（包括代收貨款及快遞費用）。

應收賬款＝代收貨款－快遞費用

5. 開票與對賬

開票是指給C端用戶開具的普通發票，現在都采用電子發票了，這部分后續在稅票管理中單獨介紹。

應收報表是FMS進銷存系統中根據單據每日生成的，應收對賬是根據我們生成的數據與第三方平臺進行核對的過程（上面標綠的子流程）。

三、財務應收報表及對賬管理

根據上面的流程，這里涉及兩部分對賬即：

1. 第三方支付公司的應收對賬：與支付寶、微信等第三方的對賬；
2. 代收貨款的應收對賬：與快遞公司的代收款對賬（如果款沒有收到我司賬戶）。

實質上兩部分是相同的，只是如果有COD的現金收款略有不同，對于第三方支付平臺的手續費與快遞公司的快遞費是不同的科目，在應收報表中不需要體現。

對賬流程如下：

1. 應收報表

應收報表主要的字段如下：

單號、支付方式、支付金額、支付時間、交易流水號、訂單類型、訂單來源、下單時間。

取數邏輯：按收款或退款的支付時間來獲取，也就是財務上所說的“收付實現制”或“現收現付制”。

數據來源：訂單或銷售退貨單等、支付流水（每筆訂單按支付方式記錄的詳細信息）。

因為每個訂單可能有多種支付方式（禮品卡、現金券、積分、微信或支付寶及銀行付款等），所以在應收報表生成時，與前端系統的數據緊密關聯，如果相關字段數據缺失需要與負責訂單、購物流程等開發組進行協調溝通。

原則：在不影響生產流程時，涉及金額的信息要盡可能記錄的詳細。

生成頻率：這部分一般不需要實時每天零點以后系統自動生成即可。

2. 對賬單

數據來源有兩種：

1. 通過與第三方支付平臺對接，通過接口每天定時拉取數據：需要一定的開發量，數據準確；
2. 由財務人員根據定義好的模板整理好數據，手動導入：人工處理麻煩，費時。

取數邏輯：根據接口信息按第三方的交易時間獲取，具體內容要與財務業務共同確定。

生成頻率：每日拉取數據，有的平臺對于查詢有限制，如果數據量過大要與第三方的技術支持人員進行溝通。

3. 對賬

數據源有了，下面就是核對應收差異。對賬結果有四種：

1. 雙方數據一致，無差異；
2. 第三方公司有數據，我司無數據：一般是時間性差異；
3. 我司有數據，第三方公司無數據：一般時時間性差異；
4. 第三方公司與我司均有數據，但是金額有差異：需要查明原因進行核對。

在處理應收差異時，采用什么樣的策略？

在實現的生產環境中，時間性差異是我司與第三方平臺最常見的場景，所以我們不能每天的對賬不能僅僅以“應收財務報表”與“對賬單”相同日期的數據進行對賬。

1. 確定對賬的數據源，即出差差異時以哪方數據為基準進行處理；
2. 對賬期間，一般每日對于有差異的數據要追溯7天前的數據進行核對，消除時間差的影響；
3. 對于是雙方系統原因產生的差異，如果無法調整，則不能手動修改數據；
4. 在已經明確差異原因后，要進行手動處理，差異金額的調賬由財務在賬務上處理。

下圖是總結的相關術語供參考：

四、ToB訂單應收管理流程

這里僅以大客戶訂單的為例說明，但實際的業務場景是非常復雜的：

1. 銷售合同管理模塊

此部分是根據大客戶（如果是分銷企業應該是普通用戶）約定，簽訂銷售類合同，包括付款方式、付款周期、發貨時間及商品的售價、折扣等信息。如果合同執行完畢則不能再創建銷售訂單。

此部分可以參照電商后臺財務管理部分。

2. 銷售發貨

根據銷售合同，生成銷售訂單，按照合同執行計劃給用戶發貨。

對于ToB的訂單可以手動創建、批量導入；每一個大客戶訂單創建后需要進行轉單即生成大客戶的銷售訂單，然后按ToC的訂單發貨流程進行。

可以通過線上企業專區入口由用戶自己下單，此部分又與購物流程等相關聯。一般此種場景是有特殊的商品活動或折扣的，對于FMS財務進銷存系統來說只是一種數據來源。

3. 應收對賬及報表

如果是采用線上企業專區等入口用戶自行下單且在線支付的（微信、支付寶等），這部分的對賬單不僅要體現在前面的對賬報表中，也要在此處有體現。

我的理解這種訂單的來源不同而已，其余的應該都相同。

在上圖中，只簡單標識了是否賒銷，實際的業務情況中也會有預付款等付款方式。每個銷售訂單都會對應具體的銷售用戶，此時可以根據銷售數據生成應收銷售報表明細，提供給市場及財務部門進行應收對賬。

4. 應收回款

當客戶回款后，需要在系統中根據銷售合同進行收款操作；對于ToB的訂單可以以大客戶訂單的方式創建，也可以以散單的方式，所以收款便有根據大客戶訂單進行收款，也可以按散單逐筆收款。

收款可以是多次，待款項全部完成此期的結算完成，收款方式一般是銀行匯款，當財務收到款后需要同步操作，以保證單據的收款狀態一致。

總結

以上只是簡單介紹了應收管理，總結一下就是一個應收報表，一個對賬單，外加系統對賬。對賬的目的是發現問題（解決因系統BUG產生的異常），保證應收數據的準確；對于ToB訂單的部分如何下單、如何收款等如果詳細設計后續在供應鏈系統列文章單獨寫一下，最后感謝您的閱讀！

聲明：本人水平有限，書寫電商財務系統系列的目的是個人的總結，文章可能結構或描述比較亂，希望看到此文章的人能夠給出建議，在此感謝！

#相關閱讀#

《電商后臺：FMS財務管理系統》

《FMS財務管理系統：數據流轉&模塊組成》

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

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

題圖來自Unsplash，基于CC0協議