一、訂單狀態
從用戶側角度來講，前臺展示的訂單，可以界定為待支付、待發貨、待收貨、已完成和已取消五個狀態。各家電商系統的訂單狀態的名稱或類型會略有不同，這似乎并不重要。重要的是訂單狀態的界定應從便捷用戶理解與查看，須要清晰的定義各訂單狀態，各狀態之間應有清晰的界限，不能存在同一個訂單同一時間存在多種狀態。上文所說的五種訂單狀態的定義說明如下：
待支付：用戶下單后，未完成支付。一般每位商城系統就會對訂單設置支付時間，頁面應顯示支付倒計時。
待發貨：用戶已完成訂單支付，店家未安排發貨。
待收貨：店家已發貨，用戶未收到貨物或用戶收到貨物未確認收貨。
已完成：用戶收到貨物，已確認收貨。確認收貨包含用戶主動確認和系統手動確認。主動確認，須要用戶點擊“確認收貨”按鈕；手動確認通常為發貨后xx天內系統手動確認收貨。
已取消：訂單被取消，包含用戶自動取消和支付超時取消兩種情況。
二、訂單操作
用戶可以對訂單進行支付、取消、確認收貨、評價、查看貨運、申請售后、刪除訂單、再來一單、分享等操作。各操作說明如下：
支付：未完成支付的訂單，用戶可以在訂單列表或訂單詳情頁中對訂單進行支付。完成支付后我的訂單詳情查詢，訂單狀態從待支付狀態轉變為待發貨狀態。
取消：取消訂單則是為用戶提供一個毀約的機會。取消后，訂單從待支付狀態轉變為已取消狀態。
查看貨運：店家發貨后，用戶可以查看倉儲作業流程及貨運信息。倉儲作業流程包含生成訂單、揀貨、清點、打包發貨。貨運信息包含快件形式、物流單號和貨運軌跡信息。貨運軌跡信息可通過與快件100、菜鳥系統等第三方貨運服務提供商進行插口對接，抓取貨運信息。
確認收貨：店家發貨，用戶收到包裹后，在商城中點擊“確認收貨”，系統則將訂單狀態從待收貨轉變為已完成。
評價：已完成交易的訂單，用戶可以對本次訂單服務進行評價。評價的內容包含打分和評論。部份平臺型商城，支持分別對商品、店鋪、物流分別進行星級評分，大型商城則可以只對商品進行評分即可。評論內容支持用戶編輯文字、上傳圖片和短視頻。
申請售后：包含申請退票、申請退款退貨和申請退貨。訂單完成支付，且店家未發貨，則可以申請退票；店家發貨后，可申請退款退貨；用戶收到貨物后，可申請退款退貨或申請退貨。（關于售后的詳情內容，后續另起一篇單獨分享）
刪掉訂單：用戶從前臺頁面中刪掉訂單。通常針對已完成、已取消的訂單可以進行刪掉操作。這兒的刪掉僅是對后端顯示層面的“隱藏”，實際上前端系統和數據庫并未進行刪掉。
再來一單：用戶對于已訂購的商品常常都會有重復訂購的需求。再來一單功能解決了復購重新選購商品的問題。通過再來一單用戶將訂單中的商品再度添加至購物車。通常針對已完成、已取消的訂單可以進行再來一單的操作。
分享：用戶可以將訂單訂購的商品通過微信、QQ等社交渠道分享給好友，用戶可自主選擇訂單中須要分享的商品。好友點擊分享鏈接，步入商品詳情頁。
用戶可以在訂單列表、訂單詳情頁對訂單進行操作。不同狀態的訂單支持不同的操作，這兒將各狀態訂單支持的操作整理成下邊這張表。
三、訂單展示
訂單的內容展示分為訂單列表展示和訂單詳情展示。
3.1列表展示
訂單列表展示所有的訂單，后端頁面通常按照訂單的狀態將訂單進行分類，分別顯示在不同Tab標簽頁下方。從左至右各Tab標簽次序依次為：全部、待支付、待發貨、待收貨、已完成和已取消。全部Tab標簽下顯示所有狀態的訂單，通常根據下單時間升序排列顯示。旁邊的待支付、待發貨、待收貨、已完成和已取消則分別對應各狀態的訂單內容。
部份規模較大的綜合型電商平臺，都會在列表頁提供一些篩選條件，如支持按下單時間篩選、支持按商品分類篩選。另外，也可以通過訂單編號或商品名稱進行訂單搜索。
訂單列表展示的信息通常包含：店面名稱、訂單狀態、下單時間、訂單編號、商品圖片、商品名稱、商品尺寸、商品數目（單品SKU數目）、合計數目（各SKU累計數目）、訂單應付金額等信息。訂單列表應展示用戶最關注的信息，不建議將讓利、運費、參數、服務信息展示下來。這樣也就能規范列表信息的數據，致使列表信息展示更簡練。
為了用戶對訂單的操作便捷，一般在訂單列表和訂單詳情頁都可以對訂單進行操作。
3.2詳情展示
詳情頁用于展示訂單的所有信息，展示的信息類型主要包含：訂單狀態、物流信息、收貨信息、商品信息、訂單信息。
貨運信息包含倉儲作業環節及貨運信息兩部份內容。倉儲作業流程包含生成訂單、揀貨、清點、打包發貨。貨運信息包含快件形式、快遞單號以及貨運軌跡。貨運軌跡可通過與快件100、菜鳥系統等第三方貨運服務提供商進行插口對接，抓取貨運信息。收貨信息內容為收件人姓名、聯系電話和收貨地址。若果是代發訂單，則同時也應顯示代發信息。
商品信息包含：商品圖片、商品名稱、規格機型、單價、數量、單品數目小計、單品價金額小計。訂單信息包含：訂單編號、下單時間、商品金額（合計金額）、優惠免除金額、積分抵扣金額、運費、訂單應付金額、支付時間、支付方法、支付金額、獎勵積分等。
為了盡可能的拓展銷售場景，提供更多的銷售機會，在詳情頁的頂部也可以降低商品推薦模塊，基于商品之間的關聯度協同算法為用戶推薦可能感興趣的商品。如推薦相同類目中的其它商品，相同品牌的其它商品，與用戶訂購了相同商品的其它用戶訂購的商品等。
四、拆單與合單4.1拆單
當商城存在多個庫房時，用戶下單后，系統就會按照貨物所屬的庫房進行拆單，將貨物分拆到對應的庫房，并生成子單。父單中的所有商品均分拆到各子單，包括各種讓利金額、獎勵金額、運費也應平攤到各子單中。讓利金額、獎勵金額，依照各子單商品金額占整個父單商品金額的比列進行權重估算。郵費金額則根據各自庫房的郵費規則進行分別估算。須要注意的是，在下單時，前端系統按照商品完成了拆倉邏輯、并早已估算好各倉的郵費，將各倉的郵費累加并返回到下單頁面。
遞交訂單后，列表頁可以看見拆單后的結果，為了用戶的支付便捷以及平臺早日收款，用戶只能對父單進行支付。父單完成后，父單的使命任務就完成了。后續用戶所有的操作都是針對子單。每位子單有自己獨立的狀態和操作命令。
為了提高訂單支付率，大部份商城都容許不同庫房、不同店面的商品合并在一起下單支付我的訂單詳情查詢，待遞交訂單后再依照店面、倉庫進行拆倉。
4.2合單
當同一個收件人有多筆訂單，且這種訂單的貨物都在同一庫房，下單間隔時間也較短時，系統或營運人員會在后臺對這種訂單進行合并領料，將這種貨物打包通過一個包裹發貨給顧客，這些情況稱之為庫房合單。用戶在列表頁將見到這幾個訂單合并成了一個父單，合并前的訂單變為了子單。這兒與拆單的情況有些區別，合單后只有父單有狀態（待發貨/待收貨/已完成），用戶只能對父單進行確認收貨操作。用戶依然可以對每位子單進行申請售后、評價、刪除訂單、再來一單等操作。
結語：前臺的訂單設計主要梳理清楚訂單的各類狀態，以及各狀態訂單支持的操作，并理清訂單的拆單與合單的邏輯原理，訂單模塊的設計自然水到渠成。訂單信息的展示在頁面設計時，須要將信息進行合理的歸類，注意數據信息的結構化展示，關注用戶的交互操作體驗。下一篇，將從商城后端的角度聊一聊有關訂單售后的相關流程與功能設計。
免責聲明：部分文章信息來源于網絡以及網友投稿，本站只負責對文章進行整理、排版、編輯，出于傳遞更多信息之目的，并不意味著贊同其觀點或證實其內容的真實性，如本站文章和轉稿涉及版權等問題，請作者在及時聯系本站，我們會盡快為您處理。
