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

各位小伙伴好，本文是電商產(chǎn)品設(shè)計(jì)系列文章的第八篇，訂單產(chǎn)品。在電商系統(tǒng)中，訂單是連接用戶和商家之間最重要的交易信息系統(tǒng)，本文就來討論一下訂單相關(guān)的內(nèi)容。

一、訂單的生成與狀態(tài)

1.?下單過程

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

可以看到，下單過程中重點(diǎn)有3個(gè)，分別是訂單金額計(jì)算、庫存校驗(yàn)、過程信息清晰展示。

商品金額計(jì)算包括商品價(jià)格、運(yùn)費(fèi)、優(yōu)惠活動的計(jì)算。

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

過程信息清晰展示包括優(yōu)惠明細(xì)、子訂單明細(xì)、商品主圖/名稱/規(guī)格/數(shù)量的展示、運(yùn)費(fèi)/優(yōu)惠券/促銷的展示。

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

總結(jié)來看訂單的下單過程如下：

2. 訂單計(jì)算

在下單過程中，金額的計(jì)算是流程中最重要也是用戶最關(guān)心的部分，訂單應(yīng)付金額=商品金額（SKU金額合計(jì)）+運(yùn)費(fèi)-總優(yōu)惠金額。

我們分別來看這幾個(gè)值。商品金額即商品原價(jià)，不扣除任何優(yōu)惠金額，但是注意和劃線價(jià)進(jìn)行區(qū)分。我們在購物時(shí)，可以在商品詳情頁查看商品的運(yùn)費(fèi)金額，商品詳情頁的運(yùn)費(fèi)是根據(jù)商品的運(yùn)費(fèi)模板來計(jì)算。

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

以下圖的運(yùn)費(fèi)模板為例，我們可以配置的關(guān)鍵信息有計(jì)費(fèi)方式、配送區(qū)域、指定區(qū)域的首費(fèi)與續(xù)費(fèi)，若想設(shè)置包郵將對應(yīng)條件下的郵費(fèi)設(shè)置為0即可。

實(shí)際生活中我們經(jīng)常會發(fā)現(xiàn)有些商品特價(jià)促銷，9.9包郵，而我們?nèi)粘＜目爝f都需要6元及以上，他們是怎么做到這么低的價(jià)格包郵的呢？

實(shí)際當(dāng)寄件具有規(guī)模效應(yīng)后，實(shí)際運(yùn)費(fèi)能壓到非常低的價(jià)格，一般作為物流公司大客戶來進(jìn)行議價(jià)。

影響議價(jià)的因素主要有單量、所在地區(qū)（如義務(wù)優(yōu)勢）、包裝重量與大小等。我們從某商家論壇找到的數(shù)據(jù)顯示日均單量的200單以上時(shí)，價(jià)格可以談至1.5元左右一單，實(shí)際運(yùn)費(fèi)較低。

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

訂單的優(yōu)惠來源包括促銷活動、優(yōu)惠券、積分抵扣、會員折扣等。當(dāng)涉及多種優(yōu)惠活動同時(shí)進(jìn)行、不同商品參與不同促銷互動時(shí)，優(yōu)惠金額的計(jì)算詳見后續(xù)章節(jié)。

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

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

3. 訂單狀態(tài)

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

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

我們知道，訂單狀態(tài)決定相應(yīng)服務(wù)體系，如“待收貨”狀態(tài)下是否可以確認(rèn)收貨、申請退款。同時(shí)，訂單狀態(tài)與售后狀態(tài)相互獨(dú)立，他們不是一個(gè)狀態(tài)字段但是可以做關(guān)聯(lián)。我們上述說的是訂單的外部狀態(tài)，即展示給用戶查看的狀態(tài)，而訂單內(nèi)部的狀態(tài)指訂單在倉庫層相關(guān)的操作，這部分的操作對應(yīng)的是“待發(fā)貨”狀態(tài)。

二、父子訂單拆分

1. 父子訂單

當(dāng)我們在在線商城購物時(shí)，經(jīng)常會遇到商品屬于不同賣家或因商品數(shù)量、重量等問題需要拆單的現(xiàn)象。這個(gè)時(shí)候我們通常會生成兩種訂單號，一種是拆單前訂單的訂單號，另一種是拆單后的訂單后。

其中父訂單用于記錄用戶這一次下多單的行為，還有合并支付。如果有跨商家優(yōu)惠，父訂單可以對應(yīng)到相應(yīng)的優(yōu)惠，然后對各個(gè)商家進(jìn)行分?jǐn)?、子訂單用于追蹤發(fā)貨物流、售后以及財(cái)務(wù)結(jié)算的依據(jù)，用于記錄優(yōu)惠信息。用戶關(guān)心的是訂單的訂單狀態(tài)、物流狀態(tài)、售后狀態(tài)、售后金額，這些都會以子訂單為單位進(jìn)行跟蹤。

注意，在訂單產(chǎn)品架構(gòu)的設(shè)計(jì)中，如果使用了父子訂單的設(shè)計(jì)，系統(tǒng)中并不是需要拆單的訂單才有父子訂單，而是所有的訂單都需要生成父子訂單。

2. 訂單拆單

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

根據(jù)拆單時(shí)間的不同，我們可以分為支付前與支付后的拆單，支付前主要是拆訂單——拆成父子訂單。支付后主要拆發(fā)貨單——拆成子訂單和多個(gè)包裹。

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

3. 優(yōu)惠分?jǐn)?/h3>

訂單支付時(shí)非常重要的一個(gè)環(huán)節(jié)就是計(jì)算優(yōu)惠的分?jǐn)?，即訂單?nèi)所有商品參與一個(gè)活動后，活動優(yōu)惠的金額分?jǐn)偢鱾€(gè)商品后的金額。

為什么要計(jì)算優(yōu)惠分?jǐn)偰?，主要作用有?/p>

1. 使用優(yōu)惠后計(jì)算每個(gè)商品實(shí)付金額，用于后續(xù)核算商品利潤。
2. 作財(cái)務(wù)上的結(jié)算用。
3. 商品售后時(shí)計(jì)算應(yīng)退商品金額。我們以一個(gè)實(shí)例來分析訂單金額的計(jì)算：

子訂單1中各商品分?jǐn)偟膬?yōu)惠：

如果退回了子訂單1中的商品1，此商品實(shí)付205.12元，若退全款則退款205.12元。除了退現(xiàn)金外，虛擬資產(chǎn)也要退回，例如積分、充值費(fèi)用等。比如該商品若全額退款可退回1.03元——103個(gè)淘金幣。若全額退款則部分情況下優(yōu)惠券退回，部分退款則一般不退優(yōu)惠券。

三、從下單到發(fā)貨

1. 訂單發(fā)貨流程

用戶下單后，接下來就是安排發(fā)貨。

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

訂單發(fā)貨時(shí)首先涉及的是拆單，因?yàn)閭}庫都是根據(jù)訂單為單位去進(jìn)行發(fā)貨，我們來梳理一下訂單全流程中，拆單的過程：

第一次拆單拆的是訂單，指用戶同時(shí)從購物車提交訂單，拆分生成多個(gè)子訂單。第二次拆單是拆發(fā)貨單，如果一個(gè)訂單需要拆分成多個(gè)包裹發(fā)出，我們需要在調(diào)度層進(jìn)行拆單，下發(fā)給倉庫多個(gè)訂單。

注意，這里一般不建議在倉庫層拆單，因?yàn)樵趥}庫層拆單不好監(jiān)控。

上圖展示的是訂單的前臺顯示狀態(tài)，但是對應(yīng)后臺訂單層訂單發(fā)貨的狀態(tài)非常復(fù)雜，一個(gè)前臺訂單狀態(tài)對應(yīng)非常多后臺發(fā)貨相關(guān)步驟的流轉(zhuǎn)，具體見下：

上面講的是普通實(shí)物商品的常規(guī)發(fā)貨流程，實(shí)際我們還會碰到其他的訂單類型，不同業(yè)務(wù)有不同的訂單，不同的訂單有不同的訂單流程。

實(shí)物商品中，最常見的是普通實(shí)物商品，走的是上述的常規(guī)訂單流程。第二種是實(shí)物+服務(wù)的商品，比如售賣家電并提供上門安裝調(diào)試服務(wù)。在這種情況下，實(shí)物子訂單和安裝服務(wù)子訂單相互獨(dú)立，在一個(gè)父訂單下綁定，等后續(xù)安裝服務(wù)完成后，訂單狀態(tài)才算完結(jié)。若客戶不要求安裝服務(wù)，則涉及到服務(wù)費(fèi)用退款。

虛擬商品中，一種是純線上的服務(wù)如話費(fèi)充值、游戲充值，這種生成訂單后，會調(diào)用第三方服務(wù)，完成發(fā)貨。注意這種訂單需要設(shè)置多久內(nèi)允許取消。另一種是線上下單線下服務(wù)的，如OTA、O2O等，這種訂單要確保用戶享受到服務(wù)、進(jìn)行財(cái)務(wù)結(jié)算，注意這種類型訂單的退款流程。

2.?訂單數(shù)據(jù)分析

訂單在交易的過程中，系統(tǒng)會記錄訂單的數(shù)據(jù)，便于數(shù)據(jù)分析指導(dǎo)之后的經(jīng)營生產(chǎn)。我們需要從訂單的流量、品類、交易三個(gè)維度進(jìn)行分析。

首先是流量維度，即分析店鋪、商品的訪問與轉(zhuǎn)化等數(shù)據(jù)。流量分析核心指標(biāo)有：

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

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

其次是訂單商品品類分析，分析核心指標(biāo)有：

• 商品訪客數(shù)、商品瀏覽量、商品收藏人數(shù)、商品加購人數(shù)；
• 加購轉(zhuǎn)化率、收藏轉(zhuǎn)化率；
• 下單用戶數(shù)、下單件數(shù)、下單金額、下單轉(zhuǎn)化率；
• 支付用戶數(shù)、支付件數(shù)、支付金額、支付轉(zhuǎn)化率；
• 客單價(jià)、訪客平均價(jià)值。

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

最后是訂單交易數(shù)據(jù)分析，其交易核心指標(biāo)有：

• 訪客數(shù)、下單用戶數(shù)、下單金額；
• 支付買家數(shù)、支付金額、客單價(jià)；
• 下單轉(zhuǎn)化率、下單支付轉(zhuǎn)化率、支付轉(zhuǎn)化率；
• 商品成本、運(yùn)費(fèi)成本、確認(rèn)收貨金額。

交易分析維度有整體、明細(xì)。

四、總結(jié)

總結(jié)一下本文內(nèi)容，主要有三部分的內(nèi)容：訂單的生成、父子訂單、訂單的發(fā)貨三部分。

1. 掌握訂單生成：從用戶提交訂單，到支付、發(fā)貨、收貨的訂單狀態(tài)變化，訂單信息結(jié)構(gòu)，對于訂單可以進(jìn)行的操作等。
2. 父子訂單：父子訂單的作用，優(yōu)惠分?jǐn)傄?guī)則與作用，如何計(jì)算訂單金額。
3. 訂單發(fā)貨：了解訂單發(fā)貨的過程，內(nèi)部狀態(tài)和外部狀態(tài)的區(qū)別，多種訂單類型（不同的業(yè)務(wù)場景，訂單處理流程有區(qū)別），訂單數(shù)據(jù)分析（交易、商品）。

下圖是整個(gè)訂單的產(chǎn)品架構(gòu)：

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

關(guān)于倉庫層的一些變化本文并未作詳細(xì)講解，后續(xù)我會單獨(dú)寫一篇文章探討一下WMS系統(tǒng)相關(guān)的內(nèi)容。

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

作者：書豐，公眾號：書豐產(chǎn)品記

本文由@書豐 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自 Unsplash，基于CC0協(xié)議