編輯導語：訂單系統連接了用戶和商家，用戶可以通過訂單看到商品購買詳情，商家則可以通過訂單看到購買用戶信息等。而整個訂單系統囊括了許多模塊，如訂單生成、訂單計算等。本篇文章里，作者就電商訂單系統設計做了梳理和總結，一起來看一下。

各位小伙伴好，本文是電商產品設計系列文章的第八篇，訂單產品。在電商系統中，訂單是連接用戶和商家之間最重要的交易信息系統，本文就來討論一下訂單相關的內容。

一、訂單的生成與狀態

1.?下單過程

電商下單的過程相信大家都不陌生，我們以從購物車下單為例，可以看到一次下單過程涉及的主要前端頁面有購物車選擇商品頁、訂單確認頁、收銀臺支付頁、訂單詳情頁、訂單列表頁。

可以看到，下單過程中重點有3個，分別是訂單金額計算、庫存校驗、過程信息清晰展示。

商品金額計算包括商品價格、運費、優惠活動的計算。

庫存校驗主要判斷庫存是否足夠、用戶是否有購買限制、庫存的鎖定與扣減。

過程信息清晰展示包括優惠明細、子訂單明細、商品主圖/名稱/規格/數量的展示、運費/優惠券/促銷的展示。

其中訂單詳情包含了最多的信息，主要包括用戶信息、基礎信息、收貨信息、商品信息、優惠信息、支付信息、物流信息、其他信息，包括的詳細信息見下圖：

總結來看訂單的下單過程如下：

2. 訂單計算

在下單過程中，金額的計算是流程中最重要也是用戶最關心的部分，訂單應付金額=商品金額（SKU金額合計）+運費-總優惠金額。

我們分別來看這幾個值。商品金額即商品原價，不扣除任何優惠金額，但是注意和劃線價進行區分。我們在購物時，可以在商品詳情頁查看商品的運費金額，商品詳情頁的運費是根據商品的運費模板來計算。

以下圖為例，我們可以看到商品是滿一件包郵，其他常見的包郵規則還有滿XX元包郵，某一區域包郵等。

以下圖的運費模板為例，我們可以配置的關鍵信息有計費方式、配送區域、指定區域的首費與續費，若想設置包郵將對應條件下的郵費設置為0即可。

實際生活中我們經常會發現有些商品特價促銷，9.9包郵，而我們日常寄快遞都需要6元及以上，他們是怎么做到這么低的價格包郵的呢？

實際當寄件具有規模效應后，實際運費能壓到非常低的價格，一般作為物流公司大客戶來進行議價。

影響議價的因素主要有單量、所在地區（如義務優勢）、包裝重量與大小等。我們從某商家論壇找到的數據顯示日均單量的200單以上時，價格可以談至1.5元左右一單，實際運費較低。

但是隨著電商發展至今，我們我們發現越來越多的商品都有包郵的服務，現在很多小伙伴如果發現商品不包郵相信都會猶豫之后再下單，所以在包郵盛行的今日，越來越多的商家會將運費計入商品成本，從而提供包郵服務，降低用戶下單決策成本。

訂單的優惠來源包括促銷活動、優惠券、積分抵扣、會員折扣等。當涉及多種優惠活動同時進行、不同商品參與不同促銷互動時，優惠金額的計算詳見后續章節。

訂單計算完成后最后一步是訂單支付，這一部分主要包括支付方式，目前主流的是使用第三方支付，如微信支付和支付寶支付，這部分的對接詳見第三方支付API文檔，這部分后續我也會單獨寫一篇文章介紹一下。

訂單的支付主要包括直接支付父訂單，或者選擇部分子訂單進行支付。

3. 訂單狀態

在一次完整的訂單過程中，訂單有非常多的狀態，主要的訂單狀態包括待付款、待發貨、待收貨、已完成。

• 待付款：用戶提交訂單，尚未支付的狀態。由于待支付狀態會鎖定庫存，所以一般會設置超時自動取消。
• 待發貨：用戶付款之后，等待商家發貨。
• 待收貨：商家已發貨，等待用戶收貨。
• 交易成功：用戶確認收貨后，訂單已完成交易。
• 交易關閉：付款之前取消訂單，或售后完成后訂單全額退款。
• 售后中：非訂單狀態，指訂單有對應的進行中的售后單，如用戶退換貨、退款。

我們知道，訂單狀態決定相應服務體系，如“待收貨”狀態下是否可以確認收貨、申請退款。同時，訂單狀態與售后狀態相互獨立，他們不是一個狀態字段但是可以做關聯。我們上述說的是訂單的外部狀態，即展示給用戶查看的狀態，而訂單內部的狀態指訂單在倉庫層相關的操作，這部分的操作對應的是“待發貨”狀態。

二、父子訂單拆分

1. 父子訂單

當我們在在線商城購物時，經常會遇到商品屬于不同賣家或因商品數量、重量等問題需要拆單的現象。這個時候我們通常會生成兩種訂單號，一種是拆單前訂單的訂單號，另一種是拆單后的訂單后。

其中父訂單用于記錄用戶這一次下多單的行為，還有合并支付。如果有跨商家優惠，父訂單可以對應到相應的優惠，然后對各個商家進行分攤、子訂單用于追蹤發貨物流、售后以及財務結算的依據，用于記錄優惠信息。用戶關心的是訂單的訂單狀態、物流狀態、售后狀態、售后金額，這些都會以子訂單為單位進行跟蹤。

注意，在訂單產品架構的設計中，如果使用了父子訂單的設計，系統中并不是需要拆單的訂單才有父子訂單，而是所有的訂單都需要生成父子訂單。

2. 訂單拆單

影響父子訂單拆單的規則有多個，主要有平臺的不同店鋪商家、不同的發貨倉庫、品類特殊包裝要求、物流因素、商品價值等。

根據拆單時間的不同，我們可以分為支付前與支付后的拆單，支付前主要是拆訂單——拆成父子訂單。支付后主要拆發貨單——拆成子訂單和多個包裹。

最好在下單過程中能拆好就拆好，避免后續判斷。但是比如第三方商城訂單、倉庫發貨限制等因素會導致生成訂單后仍有需求拆單。

3. 優惠分攤

訂單支付時非常重要的一個環節就是計算優惠的分攤，即訂單內所有商品參與一個活動后，活動優惠的金額分攤各個商品后的金額。

為什么要計算優惠分攤呢，主要作用有：

1. 使用優惠后計算每個商品實付金額，用于后續核算商品利潤。
2. 作財務上的結算用。
3. 商品售后時計算應退商品金額。我們以一個實例來分析訂單金額的計算：

子訂單1中各商品分攤的優惠：

如果退回了子訂單1中的商品1，此商品實付205.12元，若退全款則退款205.12元。除了退現金外，虛擬資產也要退回，例如積分、充值費用等。比如該商品若全額退款可退回1.03元——103個淘金幣。若全額退款則部分情況下優惠券退回，部分退款則一般不退優惠券。

三、從下單到發貨

1. 訂單發貨流程

用戶下單后，接下來就是安排發貨。

根據商家體量的不同，發貨方式也會有差異。小商家一般采用手動打包、線下跟蹤。發貨后，在商家后臺填寫物流信息；中小商家利用第三方ERP管理訂單，統一發貨，并自動回傳物流信息；大商家或自營平臺則有自己獨立的ERP或獨立的WMS，并且會有適合業務的定制化流程。

訂單發貨時首先涉及的是拆單，因為倉庫都是根據訂單為單位去進行發貨，我們來梳理一下訂單全流程中，拆單的過程：

第一次拆單拆的是訂單，指用戶同時從購物車提交訂單，拆分生成多個子訂單。第二次拆單是拆發貨單，如果一個訂單需要拆分成多個包裹發出，我們需要在調度層進行拆單，下發給倉庫多個訂單。

注意，這里一般不建議在倉庫層拆單，因為在倉庫層拆單不好監控。

上圖展示的是訂單的前臺顯示狀態，但是對應后臺訂單層訂單發貨的狀態非常復雜，一個前臺訂單狀態對應非常多后臺發貨相關步驟的流轉，具體見下：

上面講的是普通實物商品的常規發貨流程，實際我們還會碰到其他的訂單類型，不同業務有不同的訂單，不同的訂單有不同的訂單流程。

實物商品中，最常見的是普通實物商品，走的是上述的常規訂單流程。第二種是實物+服務的商品，比如售賣家電并提供上門安裝調試服務。在這種情況下，實物子訂單和安裝服務子訂單相互獨立，在一個父訂單下綁定，等后續安裝服務完成后，訂單狀態才算完結。若客戶不要求安裝服務，則涉及到服務費用退款。

虛擬商品中，一種是純線上的服務如話費充值、游戲充值，這種生成訂單后，會調用第三方服務，完成發貨。注意這種訂單需要設置多久內允許取消。另一種是線上下單線下服務的，如OTA、O2O等，這種訂單要確保用戶享受到服務、進行財務結算，注意這種類型訂單的退款流程。

2.?訂單數據分析

訂單在交易的過程中，系統會記錄訂單的數據，便于數據分析指導之后的經營生產。我們需要從訂單的流量、品類、交易三個維度進行分析。

首先是流量維度，即分析店鋪、商品的訪問與轉化等數據。流量分析核心指標有：

• 瀏覽量PV、訪客數UV、跳失率、人均瀏覽量、老用戶占比；
• 商品訪客數、商品瀏覽量、加購人數·下單轉化率、下單金額、下單數；
• 支付金額、支付用戶數、支付轉化率·客單價、整體轉化率。

流量的分析維度有整體、流量來源、核心頁面。

其次是訂單商品品類分析，分析核心指標有：

• 商品訪客數、商品瀏覽量、商品收藏人數、商品加購人數；
• 加購轉化率、收藏轉化率；
• 下單用戶數、下單件數、下單金額、下單轉化率；
• 支付用戶數、支付件數、支付金額、支付轉化率；
• 客單價、訪客平均價值。

品類分析維度有品類、商品、新品。

最后是訂單交易數據分析，其交易核心指標有：

• 訪客數、下單用戶數、下單金額；
• 支付買家數、支付金額、客單價；
• 下單轉化率、下單支付轉化率、支付轉化率；
• 商品成本、運費成本、確認收貨金額。

交易分析維度有整體、明細。

四、總結

總結一下本文內容，主要有三部分的內容：訂單的生成、父子訂單、訂單的發貨三部分。

1. 掌握訂單生成：從用戶提交訂單，到支付、發貨、收貨的訂單狀態變化，訂單信息結構，對于訂單可以進行的操作等。
2. 父子訂單：父子訂單的作用，優惠分攤規則與作用，如何計算訂單金額。
3. 訂單發貨：了解訂單發貨的過程，內部狀態和外部狀態的區別，多種訂單類型（不同的業務場景，訂單處理流程有區別），訂單數據分析（交易、商品）。

下圖是整個訂單的產品架構：

在電商系統中，訂單是非常重要的模塊，訂單記錄了關于本次交易的所有信息，包括商品信息、價格信息、支付信息、物流信息、收貨信息等等，并且隨著訂單的變化其狀態也在發生變化，我們需要將這些狀態清晰的展示在前臺，展示給用戶。

關于倉庫層的一些變化本文并未作詳細講解，后續我會單獨寫一篇文章探討一下WMS系統相關的內容。

以上就是訂單模塊所有的內容了，下一期，我將分享在線支付模塊相關的內容，盡請期待。

作者：書豐，公眾號：書豐產品記

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

題圖來自 Unsplash，基于CC0協議