電商平臺主要會涉及商家系統、商品系統、訂單系統、售后系統、會員系統、營銷系統、財務系統、數據系統等，這是系列文章的第三篇，處理訂單。

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

首先，用戶選好商品之后會提交訂單，經過一系列判斷之后，用戶成功提交了訂單，此時訂單狀態為待付款，并且會寫入數據庫（多商家的訂單就按商家拆單后寫入）；然后用戶就開始支付訂單，經過一系列判斷成功支付后，這時就需要商家處理訂單，進行發貨等操作，同時用戶也可以進行一些操作。

一、完整訂單字段

1. 訂單信息

1）訂單編號

該訂單的唯一ID，對于管理/商家后臺來說方便查找；生成規則是用的雪花算法，這里不做展開。

2）訂單類型

可以分為“自己購買/好友代付/任務活動”等。

標記訂單類型有兩個目的：一是不同的訂單類型在客戶端和后臺可能有不同的頁面展示和操作流程，二是可以進行數據統計并分析；所以訂單類型可以分得越細越好。

這個字段可以就不放給商家后臺了，僅限管理后臺篩選。

3）訂單備注

這個字段在后臺訂單詳情里可以放在較顯眼的位置，以防工作人員漏掉。

2.?商品信息

1）商品編號

添加商品時的編號，方便查找商品（但在數據庫里不是商品的唯一ID，因為商家數量夠大時會產生重復的情況，但又不能做防止重復的限制）。

2）商品名稱

商品名稱是較大概率會產生重復的情況；從商家的角度來說，名稱怎么取，與搜索引擎和推薦商品的匹配程度具有相當大的關聯。

3）sku（商品的屬性規格）

4）購買數量

4）商品來源

分為普通商品/活動區域一/活動區域；活動區域是一個替代名詞，在我們平臺會有幾個不同的活動區域，在后臺的營銷系統里，可以直接往不同的活動區域里添加不同的商品，并設置相應的如活動價格/單人限購數量等信息；區分的作用主要是用于數據統計并分析。

需要注意的是為什么是商品來源而不是訂單來源，比如用戶在A活動專區找到某商品，又在購物車加入了該商家另外的處于B活動專區的商品，一并購買，這樣就會分不清；所以來源跟著商品走，可以更好地分析某個專區的流量情況，以及后續的運營和迭代。

3.?金額信息

1. 商品結算價
2. 金幣抵扣
3. 郵費
4. 實際支付金額
5. 支付方式

4.?用戶信息

1）賬戶信息（昵稱/賬號）

2）收貨人信息（收貨人姓名/電話/地區/詳細地址）

（注：賬戶信息可不放給商家后臺）

5.?時間信息

1. 下單時間
2. 支付時間
3. 發貨時間
4. 確認收貨時間

6.?操作信息

1. 操作賬號
2. 操作時間
3. 操作內容

如果出現問題，方便后續對相關工作人員追責，

接下來是客戶端的各訂單狀態對應操作，與后臺的各商品狀態對應操作。需要注意的是為什么客戶端是訂單狀態，而后臺是商品狀態？

我們可以先來討論一下：

為什么客戶端的訂單狀態是訂單狀態而不是商品狀態？

商家發貨肯定有個先后順序，一個多商品的訂單中肯定會存在其中一部分發貨了，而另外一部分沒發貨的情況，那此時該訂單到底是待發貨還是待收貨？那么，是不是訂單的狀態跟著商品走會更好一點？

如果設計成客戶端的狀態跟著商品走，當一個訂單中存在多個商品狀態，用戶取消可以對商品取消而不是整個訂單（優惠券、抵扣等也可以避免），確認收貨可以對商品而不是訂單（比如訂單中有3個商品，商家只有其中1個商品一直沒貨，而其他商品用戶早就收貨了，此時訂單就一直不能確認收貨，商家可能就會因為這一個商品，而遲遲不能結算其余的商品金額）等等一系列操作可能都會簡便一點。

我個人認為功能為什么這樣做：要么就是邏輯流程必須要這樣做，要么就是這樣做用戶體驗更好。

在客戶端訂單狀態這個問題上，我暫時沒找到必須這樣做的理由，只能認為這樣做用戶體驗會更好，畢竟前人總結的經驗。所以，主流電商平臺的客戶端，用戶看到的是訂單狀態而不是商品狀態；希望有大佬能指出，一起探討。

剛才說的是客戶端是訂單狀態，根據主流電商平臺這樣設計作為前提（當然用戶也養成習慣了，我不可能去更改），然后來說后臺的為什么是商品狀態。

首先，發貨肯定是對商品發貨（比如一個訂單中有A、B、C三個商品，A、B可能合并發成一個包裹，C拆分成兩個包裹發出去），剛才也說了對于多商品的訂單來說商家發貨，填寫物流單號肯定有個先后順序。

為了方便商家查看哪些商品已發貨，用戶也可以知道哪些商品是哪個包裹，哪些商品已經發貨了，所以在后臺一般狀態是跟著商品走，而不是訂單走。

但是這就涉及到客戶端訂單狀態與后臺商品狀態的對應關系了，下面會進行介紹。

二、客戶端訂單狀態對應管理/商家后臺商品狀態

紅色虛線為對應關系，我來解釋一下為什么存在一對多的情況（待付款，待發貨，已關閉都是一對一的情況就不解釋了），從客戶端的狀態來說：

1.?待收貨

對應后臺可能是部分發貨和已發貨；為什么有部分發貨這個狀態？

因為后臺的狀態是跟著商品走的，所以部分發貨不是訂單中一個商品發了一個沒發的情況，而是商家發了其中一部分購買數量的情況；比如用戶買的某商品購買數量為2，商家只發了其中1個，第二個得等到明天再發，如果不標記出來，商家可能就會不知道。

雖然用戶在購買的時候會鎖庫存，購買數量為2就代表著你此時庫存系統中至少有2件，但是要考慮到很多小商家操作可能并不是那么正規，庫存很有可能是亂填的并不聯動，也有可能商家暫時倉庫里只有1件，但是庫存還是有的，我們沒法去規避這樣的人為情況。

為了對應，我認為可以加上部分發貨這個狀態。

為什么客戶端的訂單中沒部分發貨這個狀態？

一個是這種情況也是少數，加上去反而復雜了用戶的認知，可能會造成用戶覺得怎么一些發了一些沒發，降低用戶體驗；一個是后端的邏輯會更復雜一些。

當訂單中任意一件商品發貨后，客戶端訂單狀態就會變為待收貨，為什么這樣設計？

一個是上面說的，發貨有個先后順序，訂單中一部分發了，一部分沒發，客戶端展示為待收貨肯定比待發貨更能減輕用戶的焦慮心理（訂單中有商品發了貨，這個也沒毛?。?；一個是待發貨的訂單，用戶是可以無成本的直接取消訂單的，有商品發出了，但用戶確直接取消了，這肯定不合理。

綜上所述，比如用戶在同一商家購買A商品2件，B商品2件，當用戶看到訂單處于待收貨貨狀態時，實際有可能A商品只發了一件（A處于部分發貨），A已發貨B待發貨，A,B都已發貨。

2.?待評價、已完成

為什么客戶端的訂單狀態的待評價和已完成，都對應后臺的已發貨，而不是后臺中的待評價和已完成？

是因為我們在需求評審的時候砍掉了后臺的這兩個狀態，分析一下為什么商家需要看到待評價和已完成的訂單，是因為他可能需要去找到這筆訂單后再去看用戶評價了嗎？

原因是，我們現在平臺用戶量并不是很大，評論的用戶較少，所以商家與用戶互動的功能可能用得比較少暫時就沒做，把精力放到更有意義的功能上，所以可能商家就不需要查看待評價和已評價的訂單，這個功能優先級和互動功能一起放低了。

然后說一下，淘寶的后臺有退款中這個訂單狀態，我沒這樣設計的原因是，我把訂單狀態和售后單狀態是完全分開的；比如購買數量為2，用戶收到貨后發現其中一個商品有問題，申請退貨數量為1，那這個訂單是待收貨還是退款中呢？

如果要加這個狀態，又要加一些判斷，比如申請數量為1的時候，訂單狀態為待收貨，申請數量為2的時候，狀態為退款中，就是說需要判斷訂單中是否全部申請退款；又比如訂單中兩個商品都申請退款，這時訂單狀態為退款中，但是其中一個退款單被打回，退款單狀態變為已關閉，這時又從退款中變為待收貨，不光對后端邏輯，對用戶來說也很亂。

所以訂單和售后單狀態完全獨立，比如待評價的訂單中只有一個商品，用戶對該商品申請退款并成功后，訂單狀態依然為待評價，如果變為已關閉，我覺得不合理，就算用戶退貨退款，也不能剝奪用戶評價的權利。

三、客戶端訂單狀態對應操作

1. 待付款

1）去支付

支付時的判斷流程與在支付頁面的判斷流程是一樣的（商品狀態/sku信息是否更改），點擊支付按鈕后如果支付失敗，則可以觸發自動取消訂單。

2）取消訂單

取消后狀態變為已關閉，金幣等抵扣原路返回，釋放庫存。

3）朋友代付

流程較為復雜，這里不做展開，我會在另外的文章中寫出來。

待付款的時間長短需視業務場景而定，比如平臺上商品的庫存是否充足，是否愿意留足夠時間給商家與用戶協商等；淘寶是24小時，京東嚴選是30分鐘。

2. 待發貨

1）取消訂單

待發貨的訂單用戶可以無成本的直接取消，但需要考慮一種情景是，此時商家已經將包裹發出，只是還未來得及填寫物流信息（人為因素無法規避），訂單狀態仍為待發貨，此時用戶是可以取消訂單的；中間這段時間差是無法避免的，只能盡量縮短（由于我們平臺暫未涉及到滿減之類的活動，暫不考慮這類場景下的取消訂單）。

如果大家有好的方案，我們可以一起來討論一下。

2）提醒發貨

在后臺以站內信的方式通知商家，但需設置間隔時間或每個賬號的次數；這個功能實質上對用戶來說只是一個安慰劑功能。

3. 待收貨

1）查看物流

當訂單內有多條物流信息時，有以下幾種情況：

• 單商品多物流：一個商品在發貨時分為多個包裹發出，即填寫了多個物流單號；
• 多商品單物流：多個商品在發貨時合為一個包裹，即填寫了一個物流單號；
• 多商品多物流：比如A、B商品合為一個包裹，C商品分為多個包裹。

以上幾種情況都需要有單獨的頁面來告知用戶，哪些商品在哪個物流單號里。

2）確認收貨

確認收貨分為兩種：用戶主動確認與系統自動確認。

自動確認收貨的時間為訂單內最后一個商品填寫物流單號起10日（具體時間長短可根據具體業務場景而定）。

前面說了，多商品的訂單其中一個商品發貨后，訂單狀態立即變為待收貨；但這樣同樣會帶來一個問題，當訂單中存在未發貨的商品時，當用戶點擊確認訂單時，應不應該讓用戶確認收貨呢？

我的做法是不讓，同時給一條提示語告知用戶，雖然感覺不大合理，但暫時沒想到更好的方案了。

3）申請售后

在此狀態的申請售后需要做3個判斷

• 點擊時同樣需要判斷當前商品是否已發貨（后臺商品狀態處于待發貨和部分發貨則不能點擊）；
• 如果該商品有售后申請記錄且處于進行中狀態，則按鈕置灰；比如購買數量為5，申請數量為1，如果不做限制，則最多還可以申請4次售后，商家可能就會一次性處理5次售后單，所以在非完全申請的情況下，只有當第一條售后單狀態處于已完成或已關閉狀態時才可繼續申請；
• 該商品是否已完全申請過售后，比如購買數量為5，已全部申請過售后且通過并完全，則按鈕置灰，不能再申請售后。

4. 待評價

1）查看物流

與待收貨時的判斷條件一致。

2）去評價

評價分為兩種：用戶主動確認與系統自動確認；自動評價時間為訂單確認收貨起15日（具體時間長短可根據具體業務場景而定）；自動確認收貨后，在商品詳情頁里的評價中心里會顯示該條自動評價的固定文案。

3）申請售后

此狀態的申請售后除了需要判斷該商品是否有售后單處于進行中和是否已完全申請過，還需要判斷該訂單是否已過可售后時間；可售后時間為訂單確認收貨起15日（具體時間長短可根據具體業務場景而定）。

5. 已完成

1）查看物流

2）申請售后

這兩項操作的判斷與待評價狀態下一致。

3）再次購買

這項操作的目的是為了多一個入口來暗示用戶再買一次；如果該訂單內有1個商品，點擊后跳轉至商品詳情頁，如果有多個商品，則跳轉并加入至購物車；為什么不是直接跳轉至提交訂單頁面？

因為所有對商品狀態，sku信息是否更改過的判斷在詳情頁或購物車完成對用戶體驗肯定更好一些。

6. 已關閉：分為3種類型

1. 用戶主動取消（待發貨狀態時用戶在客戶端取消）
2. 商家主動取消（待發貨狀態時商家在后臺取消）
3. 超時未支付系統取消（待付款狀態時超過時間系統取消）

這幾種不同類型的已關閉訂單，需要在頁面體現出取消的原因，以起到告知用戶的作用。

四、后臺商品狀態對應操作

我們平臺綜合考慮后，待付款的訂單暫時不進入后臺

1. 待發貨

1）發貨

需要進行的操作有：選擇發貨數量/選擇物流公司/填寫物流單號；當發貨數量小于購買數量時，商品運輸狀態會變為部分發貨；發貨可能進行的操作是添加物流，比如用戶購買的一個套裝，購買數量雖然為1，但需要2個包裹發出，所以需要有添加多個物流的操作；發貨后就需要扣除庫存。

2）取消訂單

3）修改收貨信息如果用戶聯系商家，希望修改收貨信息，只要涉及到地區的修改，就有可能會影響到郵費的計算，比如用戶提交訂單的收貨地區為重慶，郵費為10元，但希望商家改為西藏，郵費為20元，多出來的10元就需要商家和用戶線下解決。

2. 部分發貨

1）發貨

前面說了，此狀態下的發貨操作不會影響客戶端訂單的狀態。

2）查看物流

查看物流彈窗需要加上修改物流單號的操作，以防填錯。

3. 已發貨/已關閉

操作都為查看物流。

以上就是訂單系統的全部內容了，做一個總結：

1. 首先用戶需要提交訂單，在提交訂單頁面可以看到并選擇哪些字段，同時后端需要經過一系列判斷之后才能成功提交訂單；
2. 用戶在成功提交訂單后，該拆單就拆單，該寫入數據庫就寫入，然后用戶需要支付該筆訂單，后端又經過一系列判斷之后才能支付成功；
3. 最后就需要商家來處理訂單了，正常流程就是商家發貨，用戶確認收貨，異常流程就是用戶或商家取消訂單，申請售后之類的操作。

如果有認為我在流程或者邏輯上設計有問題，或者不清楚的地方，歡迎各位大佬指出，一起來討論一下

下一篇：售后系統

#相關閱讀#

從0到1構建電商平臺之訂單系統（2）：支付訂單

從0到1構建電商平臺之訂單系統（1）：提交訂單

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

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