版權聲明：本文版權歸文章作者所有，僅代表作者觀點，本文不用於商業用途，僅為學習交流之用，如文中的內容、圖片、音頻、視頻等如有侵權，請及時聯系本站站長刪除。
本文來源於微信公眾號【電子合同網】
合同是與供貨商或商家或用戶簽訂的，它是公司業務經營的重要組成部分，涉及到的相關條款、協議都是需要經過法務進行審核的，以避免後續的不必要紛爭；同時采購、銷售等都要按照合同執行的。
在電商財務介紹中已經寫了一篇關於合同的文章，但很多內容都是針對於財務結算考慮的。這裡再把相關內容複盤一下，以供應鏈的角度來說下合同管理。
下圖是在電商財務系列之合同管理中總結的合同分類：采購類合同、銷售類合同、其他合同.
采購合同和銷售合同分別與采購訂單和銷售訂單建立對應關系，通過采購訂單和銷售訂單的管理可以有效的監督采購合同及銷售合同的執行情況。采購合同是合同管理中的核心部分，也是采購部與財務特別重視的，因為這部分與應付管理關聯密切。對於銷售合同一般對應大客戶模塊，是應收管理中的一部分，在分銷企業中銷售合同是核心，如代理IBM服務器，需要先與相關的公司與政府簽訂合同，然後根據合同生成PO單與SO單，然後再進行合同執行。一個銷售合同需要執行很長時間才能完成。如果以商品流轉的維度，其他合同是指線下門店涉及的合同、渠道合作合同等采購合同又可以分為經銷合同、代銷合同、聯營合同；這幾種屬於自營的範疇。【經銷】：是指零售商從供應商處購買貨品，根據采購貨品的價格與供應商進行結算，商品售價權由公司確定。采購還分為現金采購、按賬期結算、預付款等相關合同條款。【代銷】：是指零售商接受供應商的委托，代理銷售商品並按照實際商品的銷售數量來進行結算，關於結算價可以采用供售雙方約定的結算價進行結算或按按進貨單上的進貨價成本與供應商進行結算，但商品售價格是公司確定與供應商無關。【聯營】：是指零售商接受供應商的委托，代理銷售商品並按照所代銷商品的銷售數量和銷售金額向供應商進行結算，同時收取傭金收入，商品定價權是供應商確定或雙方協定。與采購類的聯營合同有些相似，目前的京東、天貓等電商平臺中大部分都是這種商家類合同。但是對於商家合同涉及的商品，零售商只是提供平臺服務並進行相關的審核機制（保證商品附合國家售賣標準，不侵犯購買用戶的利益），商家需要遵循國家和平臺相關規定，平臺負責代收款及傭金提成等。在電商中對於采購類與平臺商家合同是主要的，在分銷企業中則銷售合同是主要的，這裡涉及到建立銷售合同，然後根據合同的行項目生成銷售訂單，合同收款等等。在電商公司中銷售的產品有面向C端用戶的也有面向公司的即ToB,所以為了更好的促進銷售，一般都有大客戶部門，所以在合同管理中應該包括大客戶相關的銷售合同。對於第三方銷售渠道（如我們的商品放在第三方平臺上銷售）需要有相關的合同信息，以便我們進行財務對賬與結算，這部分合同信息主要應該是代收款與傭金提成的核算（我們要收回貨款並給渠道結算傭金）；目前社區團購和線下委托性質的門店都應該屬於這類合同。最近幾年都在搞線上線下融合，大的平臺都在布局線下門店（京東便利店、盒馬、蘇寧小店等等），所以對於門店的管理也是電商公司的重中之重，門店相關合同包括上面提到的委托合同也包括與店長或工作人員的業績提成合同，同時還有門店與物業相關合同（物業費、水運、電費、租金等）。有了相關的合同條款與框架協議，對於采購、銷售我們可以通過合同進行跟蹤並不斷優化供應鏈流程；對於其他合作可以及時進行回款與付款，保證公司的利益並掌握公司的經營狀況。
前面雜七雜八的說了很多合同，對於系統方面如何設計？雖然合同有不同的種類，但是合同信息我認為可以分為兩大塊(注：我們系統中只關注合同與業務單據有關聯的，與財務結算有關聯的，紙質版合同可以以附件形式上傳到系統中供查看)：基礎信息包括合同號、開始時間、結束時間、合作模式、賬期、合同類型、出單日期等。
由於合同種類不同，合同對應的模板也不相同，對於系統中我們需要保存不同的合同模板，供應商或商家簽訂合同時可以選擇不同的合同模板；這裡可以根據合同信息，將基礎信息設置為不可調整的，對於與結算相關的條款可以進行配置選擇，最終生成合同模板。如果一個大客戶在合作過程中，主體的信息已經確定，但是在銷售過程中每個階段可能會根據實際的情況有些條款是要進行調整的。這時如果采用合同變更的方式可以滿足，也可以采用框架合同與合同的方式。系統中每個階段在框架合同基礎下創建合同，類似於主合同與子合同的概念；主合同負責圈定主體信息，執行中的主體框架與主要條款，子合同負責執行細節，以減少在合同執行過程中業務同事的重複性錄入及審核工作。此部分目前在電商系統中有的沒有采用，基本上是采用一個合同方式來進行執行管理。
- 合同模板管理，是創建維護不同的合同模板，對於可配置的信息可以進行選擇調整。
- 合同錄入與編輯與合同審批是創建合同的過程，這裡要選擇供應商，一般情況下同一個供應商同一時間內只能有一個有效的合同。在上一篇“供應商管理”中介紹過，供應商可以分為父供應商與子供應商，所以合同是建立在子供應商賬號上的，為什麼這麼做？是因為一個供應商可能有不同的合作模式（既可以是商家、也可以是經銷供應商）。
- 合同變更、合同預警與合同跟蹤都屬於合同執行過程中的幾大部分。
此部分是合同執行過程中比較重要的一個環節；尤其隨著業務變化有時需要變更合同。提到變更，對於我們產品研發來說是最最厭煩的，業務需求變更我們要重新梳理流程，重新出方案，要重新寫PRD；產品需求變更，我們要重新設計，重新編碼；研發接口變更，對應的研發對接人也要變更相關接口參數或調用方法，同時還要重新聯調。但對於合同變更，我們可以通過補充協議方式框定其允許變更的幾個部分，確定相關規則。１.變更協議必須依賴於合同主體，不能脫離合同主體的框架如補充協議的生效時間必須在合同主體的有效時間內。變更的內容需要與業務確認，盡量不要增加系統的難度，變更內容如：商家平臺合同傭金提成比例調整、結算賬期的調整、出單日期的調整、罰款金額的調整等。２.變更補充協議的審核機制應該與合同主體的審核流程相同或者更嚴格。３.變更預警機制：在設置變更時需要進行規則驗證與正在執行合同的影響。如平臺商家合同執行過程中在店慶或雙節期間商家要做一些促銷活動，需要調整傭金收入的傭金率等，這裡錄入補充協議後需要及時審核生效，到期後要及時變更為正常的傭金率。此部分需要合同能夠發些站內消息、郵件、短信等給商家與公司的相關業務人員。１.當合同將到期時或終止時要有提醒機制，以便給業務部門或財務部門提供相關的處理時間（如采購的風險控制、銷售的控制以及應收應付的結算等）２.當合同信息變更申請時，要進行預警提示，發送給相關的人員（尤其要通知財務）以便對於進行相關的判斷。３.當合同中相關的要繳納的金額不足時，要進行預警提示（如質保金餘額不足）１.郵件、短信：對於相關信息要及時發送郵件（設置好郵件接收組）與短信，對於涉及到金額或關鍵信息要發短信。２.站內信，系統內通知消息，主頁面要有即將到期合同、合同變更等消息提示。２.預警消息可以設置模板（可以建立對應的短信與郵件模板）
合同從建立到終止有不同的狀態，它也有自己的生命周期，由於合同是根據供應商創建的，所以合同在執行過程中往往要與供應商發生的業務單據共同來設計，但是有些又要單獨進行，因為每個合同的執行期是不同的。對於合同執行過程中應該關注哪些內容，這裡簡單羅列一下：１.合同的狀態統計，即目前有效的合同有多少，即將到期的合同有多少，已經結束的有多少。２.對於采購類合同需要統計每個合同的應付賬款有多少；可以按供應商維度進行設計，具體看業務需求。３.對於銷售類合同要統計合同的應收款有多少，逾期未回款金額有多少，此部分主要是針對大客戶的。４.對於我司入駐第三方的要統計貨款即對方代收貨款金額。
- 商家或代銷聯營類合同，需要及時下架商家的商品停止售賣，避免產生新的交易。這部分是靠系統任務來觸發的，但是難免有問題，所以在系統任務執行過程也要有預警等消息提醒。
- 合同結算的清算，即應收與應付，這部分可以與供應商清戶結算綜合考慮，前面在介紹供應商時有供應商終止時的相關操作，具體可以查看“電商財務之供應商管理”。
總結：合同管理如果在電商供應鏈中不考慮特別複雜，可以設計的非常簡單，這就是簡單粗暴的管理，在初期可以這麼幹，但當業務發展到一定規模後，精細化的管理是必然的。我們在設計合同管理模塊需要結合各種業務模塊綜合考慮，最主要的還是財務系統。對於合同系統與財務系統的對接，我個人的原則仍然是合同不要影響到正常的銷售（即在訂單產生過程中加入過多的合同相關的信息）；合同的數據要考慮其它系統或財務系統的調用，提供必要的接口，但不要過度的耦合；對於相關的風險通過預警機制來提前通知。
發表評論 取消回複