編輯導讀：當你在網上購物時，付完款之後就會生成訂單，通過訂單可以看見商品的物流信息或騎手信息。而這套交易系統是怎樣運轉的呢？本文作者圍繞底層的交易訂單展開三方面的分析，希望對你有幫助。

一、無處不在的訂單

今年過年因為疫情原因沒回家，留在北京過。過年期間在北京我幾乎沒出門買過菜，都是直接在APP裡選好想買的蔬菜、然後支付，最後就等着小哥送到家了。不光如此，生活中打車、網購、訂外賣等各種場景，再也不用巴巴的忙前忙後，自己在家在幾分鐘即可一氣呵成。别小瞧在頁面上用手指手指簡單的點點點，對于背後的系統來說可是一大步。

其實當我們将喜歡的商品加入購物車，點擊界面上的“提交訂單”後，其實你的訂單就已經生成了，而且此時在頁面上你也可以看到訂單号，等到支付成功後，系統就會安排為你準備商品啦。

淘寶下單頁：

京東下單頁，點擊“自己付”或者“幫我付”，即生成了訂單。

二、底層的交易訂單

1. 什麼是交易訂單

今天我主要聊下用戶看不到的、但是一直默默在發力的處于最底層的“交易訂單”，在我理解交易和訂單其實是兩個不同的東西。

交易是什麼？是買賣雙方對有價物品及服務進行互通有無的行為。而訂單則是訂單是賣家與賣家交易的線上合同，是交易的憑證。所以我理解對于系統來說，交易是系統提供的能力，而訂單是存儲表，後文我用訂單中心來代替交易和訂單，進行整體說明。

2. 交易訂單的底層系統交互

其實訂單系統是電商非常重要的模塊之一，訂單系統在整個售賣的鍊路中，對接了商品、庫存、履約等上下遊不同的系統，同時對保證數據的準确性、合規性、完整性有着不可言喻的作用。

下面先看一張我畫的各個系統時序圖，我對各個系統的交互進行簡要說明。

• 端：端其實很好理解，就是用戶看到的那個下單的入口，PC、APP、h5都是，用戶觸發了提交訂單後，端上就調用訂單中心的下單服務進行下單。這個時候你就發現了訂單中心的重要性，其實端上更多的是數據和信息的展示，核心的能力都是底層提供的。
• 風控中心：訂單下單的時候首先會和風控中心進行交互，這一步主要是為了篩選黑名單用戶、或者說監控是否惡意下單。若發現用戶下單行為異常，則無法下單成功。
• 商品系統：下單時訂單中心會查詢商品系統，對用戶所購買的sku進行校驗，比如是否存在、是否上架、是否可售、可售數量等，若其中任意一項校驗不通過，則終止下單，屬于下單前的基礎校驗。下單前的所有基礎校驗通過後，訂單中心會扣除商品系統裡該sku的可售數量。
• 庫存系統：下單時訂單中心會查詢庫存系統，對用戶所購買的sku的庫存進行校驗，比如當前庫存是否大于等于用戶購買的庫存，若庫存不足，則無法下單成功，屬于下單前的基礎校驗。下單前的所有基礎校驗通過後，訂單中心會預占庫存系統裡該sku的庫存，這裡要說明的是，後續用戶支付成功後，即對預占的庫存進行扣減。ps：為什麼下單後而非支付後紀要進行庫存預占和商品扣減呢，這裡主要考慮的是多用戶同時下單的并發問題，要保證用戶下單後和支付後的信息是一緻的。
• 營銷中心：下單時訂單中心會查詢營銷中心，這裡營銷中心包含一些優惠券、促銷券、限購策略等，訂單中心會對限購數量、券的值、促銷信息等進行數據一緻性校驗，校驗無誤後即可下單成功，屬于下單前的基礎校驗。
• 支付系統：下單後，用戶在端上支付成功後，訂單中心會調用支付系統創建支付單。
• 履約系統：支付單創建成功後，訂單會調用履約系統創建履約單，創建成功後履約會下發wms進行生産。

這裡隻說明的是一些基礎的電商模塊和訂單中心的交互，履約系統和wms的交互等不算是交易訂單模塊的核心鍊路，這裡暫且不表。除此以外不同的商家平台還會涉及訂單中心和台賬系統、用戶權益中心的系統交互等等，這裡不多贅述。

3. 訂單快照和存儲

快照：下單前的所有基礎校驗通過後，訂單中心會存儲快照，快照上會記錄當時用戶下單時所購買商品信息、如商品名稱、商品金額、商品數量、商品主圖以及促銷信息如優惠券、滿折滿減等主要的信息，因為商品、促銷信息促銷信息随時都在變，快照主要是用戶後續發生争議時的一個憑證。

訂單存儲：當訂單中心扣除了商品數量、預占了庫存之後就可以将訂單信息落庫了

訂單主要會存儲有這些信息：

• 用戶信息：用戶賬号信息
• 訂單基礎信息：父單與子單、訂單号、訂單狀态、下單平台、打點信息等
• 收貨信息：收件人姓名、收件人手機号、收件地址、郵編
• 商品信息：sku信息、規格、商品數量、價格、商品圖片等
• 優惠信息：優惠券、促銷活動等
• 支付信息：支付方式、支付單号、應付金額、實付金額、運費等
• 物流信息：物流公司、物流單号、物流狀态
• ……

4. 訂單拆單

訂單拆單從字面上理解就是由一個訂單拆成多筆訂單，原單即父單、拆後的訂單及子單。下面我以拆單的時間、拆單的目的、以及拆單的維度進行說明。

• 拆單的時間點：訂單拆單一般是在支付成功後就會進行拆單。
• 拆單的目的：通過對貨權和财權進行區分，為了發貨和結算方便，同時也為了更好的進行履約。
• 拆單的維度：店鋪商家。這個主要是考慮到商品的貨權、财權不一緻，涉及結算和發貨的問題。

倉：不同的發貨倉，為了保證履約時效進行拆單。

品類：商品的屬性和價值，如虛拟商品和實物、超大物、易碎品單獨需要包裝等。

發貨時間：根據不同的商品特定的發貨時間進行拆單。

5. 訂單拆價

訂單拆價其實核心就是将訂單金額分攤至每個sku上，以便為其他系統提供sku維度金額的數據支持。

• 拆價時間點：訂單一般會在落庫後進行拆價
• 拆價的維度：拆分在每個sku上
• 拆價的要求：總帳要平，分拆後的金額一分不多，一分不少

6. 訂單狀态機

訂單狀态機是指不同流程下訂單的狀态主要分為幾種：

• 待付款：用戶提交訂單，尚未付款
• 待發貨：用戶付款完成，待商家發貨
• 待收貨：商家已完成發貨，待用戶收貨
• 已完成：用戶或系統确認收貨後，訂單已完成交易
• 已取消 ：未支付訂單被取消

7. 取消訂單

取消訂單分為支付前取消和支付後取消，支付前取消又稱作關單，觸發關單時要釋放庫存，更新訂單狀态。

支付後取消又分為兩種，一種是售前取消，一種是售後取消。區别在于取消訂單時是否可以取消履約單，若履約單已下發生産，則無法通過售前取消，需要通過售後服務單走售後取消，售後取消這裡暫且不表。

三、交易訂單與售後

其實上述交易訂單的核心流程已經大緻介紹完了，如果訂單發起售後，如退換貨等，這些都屬于售後的範疇，售後系統都是通過售後服務單進行系統交互的，與正向的交易訂單都應該是獨立的服務和存儲。

四、最後

交易訂單大緻流程每個電商平台都大緻相同，但是具體能夠為上遊提供的服務與能力卻不盡相同，交易訂單内部包涵的細節和邏輯十分複雜，不是簡短的幾句話可以囊括全的，這篇文章隻是介紹了一些基礎的核心流程，希望你能有所幫助！

作者：闫秀兒；公衆号：闫秀兒

本文由 @闫秀兒 原創發布于人人都是産品經理。未經許可，禁止轉載

題圖來自 Unsplash，基于 CC0 協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部