"接二連三地寫了十幾篇關於電商財務的內容，都是些粗淺的介紹與總結，這部分只是財務系統的一部分，相對於電子商務公司的系統和業務來說更是很小的一部分。
羅馬帝國不是一天建成的，正是因為有了這些微小系統的組成才形成了一個龐大的系統架構。這裡想根據商品的生命週期來介紹一下我所瞭解的電商公司的系統模塊組成。
接二連三地寫了十幾篇關於電商財務的內容，都是些粗淺的介紹與總結，這部分只是財務系統的一部分，相對於電子商務公司的系統和業務來說更是很小的一部分。
羅馬帝國不是一天建成的，正是因為有了這些微小系統的組成才形成了一個龐大的系統架構。這裡想根據商品的生命週期來介紹一下我所瞭解的電商公司的系統模塊組成。
每個公司所處的階段不同，所以它的系統也是不斷演化升級的，我個人的理解系統的技術一直在不斷的推陳出新，系統是一直在合併與分拆過程中優化、重構、迭代。但無論如何演變，無論商業模式如何改變，始終圍繞著供應鏈來進行。
商品流程介紹
物流、信息流、現金流是流通行業中的三個部分，個人簡單把物流理解為關於商品（實物商品、虛擬商品）的流轉，信息流是針對於我們的信息化系統的，現金流則是針對於貨款的跟蹤與管理的。
信息流和現金流都是以商品流為載體進行的，也是為了商品流更好的流轉而服務的。無論你是開淘寶店賣服裝還是在商場裡開了個實體店，或者開發了一款APP或小程序創業，首先我們都需要選擇商品，這裡商品不僅指實物，也包括提供的服務等虛擬商品。
供應商管理
首先，我們要選擇合適供貨商或批發商，這時涉及的第一個系統模塊就產生了即“供應商管理”。 供應商管理主要做什麼？
它是供應鏈管理的基礎模塊，主要是包括供應商基礎信息的管理、供應商資質的審核以及供應商考核等。
對於像我們以售賣商品為主的電商行業，主要有兩種供貨商即：直接供貨給我們，由我們負責銷售商品，一般叫自營供應商；還有一種是我們提供服務平臺由供應商進行自行管理銷售和發貨，也叫商家，這種供應商在服務平臺中一般都以店鋪的形式存在。對於供應商的考核，要注重優質供應商的培養，撇棄劣質供應商。
合同管理
有了供應商，下一步就是簽訂合同，合同是供貨商與我們的法律依據，商品的採購進貨、退貨、售賣與最終的財務結算都要以合同條款為基礎進行。
合同可以按商品的採購與銷售分為採購合同、銷售合同，又可以按照與供應商或商家的合作模式分為自營合同、商家合同等。
具體的可以看一下《電商系統之合同管理》。對於合同管理我認為最重要的是相關條款的確定以及合同的變更（業務變化太快）。對於初創公司可以搭建簡單的合同信息管理，對於規模大的公司對於合同管理要求就比較高，需要跟蹤合同的執行過程中的各個環節。
商品管理
有了供應商和合同，這時我們才能採購或審核商品。針對於自營的商品我們需要錄入商品信息、製作商品圖片、生成商品詳情頁等基礎性工作，對商家商品則更多的是商品的信息審核，確保商品信息的準確性。
商品管理系統是電商系統中核心繫統。商品管理又可以分為商品品類管理模塊、SPU與SKU管理、商品資質管理、商品屬性管理、商品品牌管理、商品庫存的管理等等。每一個模塊擴展開又可以分為多個小模塊。
商品價稅管理可以從商品管理中獨立出來，這裡涉及商品的基準價、商品進價、商品退貨價、商品市場價、商品售價等管理。
同時商品的定價策略是什麼？
這裡可能又需要比價系統，根據各友商的價格與自己的成本由系統進行價格的制定；對於稅率有進項稅和銷項稅兩種。隨著增值稅改革，目前稅率也會不定期的調整，每次的調整都會涉及商品採購與財務結算、賬務報表等，所以在設計系統時需要考慮擴展性。
採購管理
有了商品，沒有庫存依然無法銷售，對於自營商品需要先採購商品，對於商家商品則需要商家去維護商品庫存。
如何採購即根據什麼採購？
供應鏈中涉及到採購計劃，初期在沒有數據積累時，一般是根據銷售部或運營部的預測進行商品採購。採購單是以供應商合同為基礎進行的。採購管理是供應商關聯的，所以這部分又涉及供應商管理平臺，用於與供應商進行數據交互與審核及對賬。
對於採購單數據的產生可以通過銷售計劃和採購計劃單生成，也可以通過補貨建議單生成，補貨計劃是供應鏈管理中的一個重要組成部分，它是根據需求計劃、銷售預測、到貨週期等根據預測模型進行計算的。
在劉寶紅的採購與計劃管理中，針對預測有三個原則：
- 有預測比沒有預測好;
- 預測是各部門協同完成的，不是供應鏈部門的功能;
- 預測數據的準確性是需要不斷的循環修復與調整的。
有采就有退，商品能不能退貨、退貨數量是多少是由倉儲部與採購部共同完成的，同時是要根據合同條款進行的。
到貨預約管理
採購單創建並經過供應商的審核後，由供應商進行發貨，對於發貨也有兩種(1)由供應商負責發貨運輸(2)公司自取，但是都面臨一個共同的問題，發的貨物何時到倉庫，倉庫應安排多少人去收貨呢？
這就需要在供應商管理平臺與倉庫系統間構建到貨預約系統模塊，此部分需要根據倉庫的存儲空間及作業能力來進行預約模型的搭建。當供應商預約完成後，結合運輸的在途時間便可以安排商品發貨了。
入庫管理
供應商發貨後，經過幹線運輸最後就會送到倉庫由我司負責入庫、上架等操作，進行商品的保管。
入庫有哪些操作，首先在倉庫有專門的收貨臺，用於接收商品貨物，由倉儲的收貨組負責。入庫前需要進行商品的質檢操作，這就涉及質檢管理系統，質檢有抽檢和全檢，有的按包裝箱進行稱重檢查來判斷商品是否少貨或缺貨。
在入庫前不還涉及到裝卸、標籤打印等工作，這時就會產生裝卸費、標籤打印費等財務費用。
當這一些都完成後，收貨組開始進行商品的入庫操作，入庫又分為整箱收貨、散件收貨等。而收貨的商品是存放在整庫，還是存放在零庫，具體又涉及到倉庫的庫區、庫位的管理，這些都是根據商品的相關屬性來設置好的。
像生鮮類的商品又要根據商品溫控屬性確定是常溫的、冷藏的、冷凍的，不同溫控的商品要存放在對應的庫區以便更好的保存，減少損耗。
對於比較大型的倉庫，一般分為整庫與零庫，整庫一般是整箱整箱的保存，商品的入庫都是先入到整庫，待銷售時會從整庫調撥到零庫，進行商品的庫內上架銷售。倉庫的管理涉及的知識特別多，我個人一直都對這部分非常感興趣，只是沒有太多的機會參與大型電商公司的庫內管理與實踐。
商品入庫後，系統中就有可售庫存了，前端售賣系統如APP、小程序、網站、合作渠道。
商品上架銷售前工作
自營商品採購入庫後，已經產生庫存了；對於商家發貨的商品，通過我們的服務平臺可以進行庫存設置。
商品可以售賣了嗎？
這裡回到商品管理部分，需要確認商品的圖片是否已經上傳完整，圖片等都需要保存在CDN，這樣才能保證前端的瀏覽和加載速度。
商品圖片的管理是商品管理的重要組成部分。
商品的詳情頁是否生成、商品的價格是否設置好了嗎？這部分需要結合網站或APP的CMS管理來進行配置。
商品是否有相關活動，這就涉及促銷活動管理模塊。對於我們熟悉的促銷活動有商品秒殺（秒殺系統需要單獨部署，每次的秒殺瞬間的流量都可能沖垮我們的APP或主站）、單品直降、滿減、滿贈等等。
如果公司提前發送了優惠券，這裡又涉及到優惠券的發放、生效、使用等管理。
優惠券又分為滿減券、現金券、品類券等等各種形式，光促銷的玩法，就會把產品、研發稿的焦頭爛額。
尤其當我們遇上比較糊塗的運營人員，活動設置的亂七八遭，出問題就找技術，從來不進行個人工作的檢查，遇到這樣的人員要極力剋制，剋制，再剋制。
在促銷活動管理系統中，對於各活動間的互斥規則需要明確，不要你以為也不要我以為，最好在系統配置活動過程中加上必要的引導說明工作，以減少後期產品技術同事的擦屁股工作。
以上設置好了，商品可以銷售了嗎？
我們還缺少了一個環節，商品銷售模板也叫配送模板的設置，即商品能送達的城市地區設置。所有的商品都需要設置包括自營與商家商品，所以關於區域編碼需要採用與當前各大電商網站相同的編碼，方便後續與第三方商家系統的對接。
運費模板也是上架銷售前的重要部分，一般的商品都是按重量來確定收費規則，每個商品都需要進行運費模板的配置。
其它的準備工作還包括商品是否有會員價、是否支持貨到付款（一般在商家上進行設置）、支付方式等。 至此，商品上架銷售前的準備工作基本完成了。
分銷渠道平臺
在商品銷售時，一般都有很多的銷售渠道，線上有APP，小程序，第三方合作平臺，線下有門店，大客戶批發等，此外還可能有內部購銷平臺等。
商品如何確定在哪個平臺銷售，銷售的價格是多少？
這就需要我們搭建一個分銷渠道平臺。它要能夠分發商品，確定商品價格，同時最重要的是渠道庫存是共享的還是獨立的。
對於財務結算也要考慮到渠道的佣金計算邏輯等。此部分內容也應屬於銷售前的準備工作，在微信公眾號上發佈時沒有獨立出來，同事建議此部分應該做成一個類似於中臺的系統來作來運營的操作。後續具體模塊系統介紹時再做詳細說明。
銷售訂單產生
商品銷售的渠道有很多種，如APP上售賣、小程序上、網站售賣、第三方合作渠道、線下門店售賣。
從2011年開始的O2O到新零售的線上線下融合，從網上商城到移動APP再到這兩年的社區團購小程序等，電商零售的發展是非常之快的（還有無人貨架、無人超市等），銷售方式也是非常之多。
如果有線下門店，則商品需要從自營倉或供應商供貨到門店，產生門店庫存，經過門店銷售POS進行售賣。這從供應鏈的角度屬於倉到店到戶或供貨商直送到店到戶。這裡涉及的系統有，門店銷售系統、門店空間管理、門店進銷存管理等幾部分。
對於門店銷售POS的理解等同於APP或小程序等線上銷售，這裡涉及的商品促銷活動設置可以通過促銷系統區分門店促銷和線上促銷兩種方式。
商品的購物車管理、購物流程、支付流程等服務基本相同，但門店由於是可見即所得，所以商品瀏覽等可以不需要，超市的POS以及現在各超市推出的自助結賬，基本上就是掃碼、商品購物清單確認、支付、打印小票等幾部分。
在網上商城的銷售，需要網上運營部同事與產品、體驗官來共同協作設計，一個簡潔、清晰的商城+簡潔的購物流程可以帶來更多的瀏覽和轉化率。
說到如何計算轉化率，這又涉及相關的埋點進行數據的收集利用weblog來對用戶的行為來進行分析。
在銷售過程中有兩個服務是比較重要的，即商品服務與庫存服務；對於庫存服務是非常關鍵的，商品是否超賣都與庫存服務有著重要的關係，同時這部分也直接影響著下單流程的響應速度，關鍵的服務需要進行性能壓力測試的。 商品銷售的流程大家都熟悉，瀏覽、選定商品、加入購物車、支付、等待收貨。
訂單流轉到後端
這裡就會產生銷售訂單和支付流水，在電商系統組成中，前端下單系統與後端訂單的業務處理是分開的，這裡涉及很多的服務和任務。首先前端的數據庫與後端的數據庫就是隔離的，前端數據庫可以擴展，後端的數據庫是要進行分庫分表的（每日訂單量達到十萬或百萬級）。
1. 拉單服務：前端下完訂單後，需要經過拉單服務將訂單取到後端生產庫，這個過程一般不做過多的邏輯處理。
2. 拆單服務：在後端庫，訂單是需要進行拆單的，拆單規則根據業務規則進行設置，商家商品要根據發貨商家進行拆分、自發貨商品要根據商品倉庫、溫控屬性、活動類型（預售商品）等進行拆單。在拆單過程中要進行商品相關金額的分攤。
對於現在智能倉儲系統的建設，對於前面介紹的拆單，一方面依賴於上游系統的商品屬性，另一方面依賴於倉儲系統的拆單邏輯。
3. 訂單下發服務：訂單經過拆單後，需要與倉儲系統WMS進行對接，由倉庫安排發貨。
一般的WMS系統都採用第三方的，相對比較成熟穩定，沒有必要自己搭建了。這裡就涉及上位與下位系統的數據傳遞。
訂單的下發與回傳僅是數據交互平臺的一般分，還有如商品數據、供應商數據、採購單據等傳輸。因為電商網站的訂單量是非常大的，所以此服務要獨立出來。
訂單下發時要考慮哪些訂單需要下發，哪些訂單需要定時下發，哪些訂單需要經過合單後再下發，規則還是蠻多的。不同的組合對於後續訂單的作業與售後都可能不一樣。
訂單發貨
發貨是意味著我們的流程已經走過了一半，訂單發貨了一般情況下用戶就不能再取消了。
倉儲發貨前需要進行訂單波次生成、揀貨、打包、發貨等流程，由於有了第三方成熟的WMS系統，我們不需要了解太多的細節，只需要將系統間的對接接口參數、報文處理好就可以了。但是隻要涉及兩個系統的對接，如果雙方規則定義模糊，那邊後續問題就會相對較多。
商品運輸：
對於訂單發貨，可能涉及多個包裹單，每個包裹單又對應不同的物流單號，此部分是與TMS系統對接的。不同的物流公司對於包裹單的處理跟蹤也會有所不同。
用戶在商城中看到的是訂單（主要看拆單後的子訂單），每個子訂單由於商品屬性不同，選擇的物流產品也不同，比如普通商品與冷凍商品的運輸方式肯定不同，那麼就會對應不同的物流產品。
目前對於多數的電商公司都不會自建物流了，成本太高了，對於冷鏈物流一直是近年來不斷優化，爭議也是比較多的，沒有實力根本無法滿足商品、用戶、商家的需求。
對於上面提到的包裹單一般是一個或多個包裹單對應一個子訂單，在子訂單的簽收和取消時不僅要考慮到父訂單，同時也要考慮到包裹單。
- 考慮父訂單是因為在用戶下單時，用戶可能享受了促銷活動（如滿減、贈品），當子訂單發生取消和退貨時要考慮到優惠的重攤重算（非常複雜）；
- 考慮包裹單時，防止一個包裹到了進行簽收（另一個包括還沒有到），給用戶造成誤解。
訂單運輸的物流信息，需要與第三方物流或與像快遞100等這樣的服務平臺進行對接，及時準確的獲取運單信息。
快遞將商品運送到用戶手裡前，還涉及到一個最後一公里的問題，即從配送站到用戶的配送；這也是各大快遞公司證明自己服務優劣的關鍵部分。
商品收貨
收貨又分為兩部分即簽收與拒收。
簽收就是用戶確認商品沒有問題，簽收確認（現在淘寶訂單有的是先簽收，如果有問題與快遞員確定後再聯繫商家進行售後；貴重商品需要當面驗收）。
拒收就是家裡無人或商品質量或包裝問題，用戶不收貨；拒收後商品會退還給供應商或倉庫。這裡又涉及到有實物拒收入庫與無實物拒收入庫（如保質期很短的鮮奶、雞蛋、水果等用戶拒收後如果再返還到倉庫已經過期或腐爛，這時就不退倉了，降低物流成本）。
如果用戶簽收後，用戶享用了此商品，那麼此商品流程就完成了。
商品補發與換貨
當商品在運輸過程中損壞等原因沒有滿足用戶需求，用戶會通過售後系統進行申請商品補發或換貨。
- 商品補發就是一個新的商品重新生成補發訂單、訂單下發、發貨、運輸最終到用戶手中。這裡仍然走一遍訂單流程。
- 換貨：如果是有實物的換貨則原商品需要寄回到倉庫或供應商，然後再生成一張換貨訂單，重新走一遍訂單流程。
注意，這兩種都不涉及用戶的退款和收款（一般認為是等價相同商品），如果不同的商品，可以走退貨流程，然後再重新代客下單。
商品退貨
一直以來，商品的正向流程是比較簡單的（相對於逆向流程）。但退貨等售後工作必不可少，客服的售後系統是每個電商系統中非常重要的組成部分。
它包括工單的處理流程、理賠流程；工單和理賠都是圍繞著商品的訂單展開進行的，主要考慮以下幾個方面即：
- 商品是否可退、退貨或理賠的原因，責任方是誰
- 商品發生退貨後是否涉及優惠，是否需要重新計算優惠，涉及的優惠券、紅包等是否失效。
- 涉及的支付方式（如積分、禮品卡）是否要重新分攤與返還。
- 涉及的商品發票是否已開，是否需要紅字發票。
如果退貨商品需要退回倉庫，需要創建退回入庫單，快遞方式如何，運費承擔方等內容。
這裡只是把主要的，想到的內容羅列一下而已，如果涉及到線下門店與供貨商或倉儲的內部商品管理，流程將會更加複雜。前面也提到了商品倉到家、倉到店到家、供應商到店到家、供應商到家等模式不同，售後的流程也會有所區別，這需要產品和業務以及研發人共同商討解決方案。
總結：商品的整個流轉流程簡單說完了，每個流程中都涉及到不同的系統模塊，每個系統模塊數據有些都是要流轉到財務進銷存和數據分析系統中的。這裡只是大框框的介紹，每個子系統的設計需要進行需求重新收集與瞭解，然後進行詳細流程的設計才可以，後續計劃逐步總結下各個系統模塊和功能，希望對你我都有幫助，感謝大家閱讀！
作者：倔強的大蘿蔔；公眾號：倔強的大蘿蔔
本文由 @倔強的大蘿蔔 原創發佈於人人都是產品經理，未經作者許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
"