筆者復盤了電商平臺從0到1的搭建過程，梳理并分析了具體的流程設計，涉及商家系統、商品系統、訂單系統、售后系統、會員系統、營銷系統、財務系統、數據系統等，與大家分享。

最近我經歷了一次電商平臺從0到1的搭建，準備把項目以文章的方式寫出來（除去可能會涉及到公司內部業務流程的地方）。

寫文章的目的，一是為了復盤，重新梳理思路，二是為了寫出來與大家共同學習和討論，設計得不合理的地方（技術的角度或者流程功能的角度）還請大家指出。

電商平臺主要會涉及商家系統、商品系統、訂單系統、售后系統、會員系統、營銷系統、財務系統、數據系統等。我會把訂單系統的文章拆分成三篇，本篇是第一篇。

雖然每個公司的具體需求與業務場景不一樣，我們平臺的功能需求可能其他平臺不盡相同，但整個訂單的產生到結束的，主要有以下3個流程：

本篇文章主要是提交訂單這一步，當用戶停留在客戶端的提交訂單這一步時，會涉及到哪些字段，各字段會有哪些影響，后端的一系列判斷流程

一、字段信息

在該頁面需要提交的字段信息如下圖所示：

二、用戶操作

用戶一系列操作對各項數據的影響：

1. 選擇收貨地址

用戶選擇的收貨地址中的地區會涉及到運費的計算（每個商家有自己的n套運費計算模板，添加商品時會選擇對應的運費模板，不同地區的運費計算會根據商品重量或件數進行計算，相應的介紹在商家系統一文中闡述）

2. 選擇是否抵扣

我們平臺業務上暫未涉及優惠券，但會通過一些渠道獲得相應的金幣，而這些金幣是可以用來抵扣訂單金額的，但是抵扣有多種方式。

比如有多個商品時，從上往下依次抵扣，平均抵扣，但相對最合理的是按商品價值比例進行抵扣，比如有3款商品，分別為20元，30元，50元，而你的金幣正好抵扣10元，按2元，3元，5元抵扣。

需要注意的是，當你的商品總價100元，運費為10元，而金幣可抵扣105元，此時是先抵扣運費再抵扣商品，還是當先把商品金額抵扣完后是否抵扣運費，這就要看平臺的規則或不同的業務場景相應的規則了；

畢竟要涉及到退貨退款，如果用戶是選擇7天無理由退貨，是不會退用戶運費的，此時如果先抵扣運費再抵扣商品，用戶只會損失金幣，而先抵扣商品不抵扣運費，用戶損失的是現金，對用戶的體驗是不一樣的。

3. 選擇是否朋友代付

代付是一套比較復雜的業務場景，會涉及到微信的分享，獲取微信的openid之類的流程，具體在另外的文章中我會寫出來。

4. 選擇是否匿名購買

當用戶選擇是后，用戶對該商品的評價可以根據一定的顯示規則來隱藏昵稱

5. 填寫訂單備注

需要注意的一點是，訂單備注是跟著商家走的，也就是跟著訂單走的（因為會涉及到以商家為維度拆單），所以需要每個商家有一個輸入框。

三、判斷流程

點擊提交訂單按鈕后，此時后臺會進行一系列的判斷。

1. 風控驗證

判斷此次下單是否惡意可以通過一些維度，比如該賬號或ip是否一段時間內重復下單多次，是否有過惡意下單記錄等，這里不做展開。

2. 驗證商品狀態

如果當用戶停留在提交訂單頁面期間，商家下架了該商品，處于已下架狀態，或者用戶選擇的該sku已售罄；所以需要在提交訂單頁面驗證一次。

3. 驗證sku庫存

比如用戶在選擇sku時，購買數量為2件，庫存也剩2件，但此時有另外的用戶搶先購買了1件；所以需要在提交訂單頁面判斷一次庫存是否大于該用戶的購買數量（因為在提交訂單后就會鎖定庫存，所以并不會出現在支付頁面顯示商品庫存不足的情況）。

4. 驗證sku信息是否更改

當用戶停留在提交訂單頁面期間，商家更改了商品的sku信息（比如直接刪掉或修改了金額）并成功上架，此時應提示用戶“商品信息已更改，請重新下單”，并原路返回頁面。

下一篇：“支付訂單”

本文由 @張璨 原創發布于人人都是產品經理，未經作者許可，禁止轉載。

題圖來自Unsplash，基于CC0協議。