交易系統，顧名思義負責完成用戶交易過程的系統。交易的過程主要指通過各種交易的先決條件來判斷應該如何確定最終交易的內容、事項、金額等信息，整合后提交訂單系統完成訂單生成的工作。

通俗地來說就是用戶在確定購買內容后和電商平臺簽約并形成書面合同（也就是訂單）的過程。

所以合約簽訂的計算、判斷、處理工作都需要交易系統來完成，所以把交易系統可以稱得上是電商平臺的運行“CPU”了。

在一些平臺也會將訂單系統包裹在交易系統之內，訂單管理作為大交易系統的一個子模塊。我們這里把兩個系統作為平行的關系進行了拆分，拆分以后的系統對于職能邊界上來說更為清晰些。我們可以用戶下單的整個過程以訂單提交為節點前面部分屬于交易系統，而后面的部分屬于訂單系統。

就像買房買車一樣在簽訂合同之前銷售人員會針對你的情況和購買的商品做很多預先的準備工作，比如資質的評估、費用的評估、是否有優惠的力度等等。這些信息都會通過核對溝通最終達成一致后錄入到合同當中。

在電商平臺也是一樣，我們在確定下單之前交易系統也會充當銷售人員的角色根據用戶填寫信息進行核準判斷、交易金額的明確、促銷情況的明確等，確認通過后完成訂單的下單提交。所以在用戶端負責對接交易系統進行訂單確認的頁面一般也叫訂單確認頁或者結算頁。

接下來我們來看看訂單合同一般都需要對那些事情進行處理和預先確認。

根據上述對于訂單合同的描述我們可以將事項分為幾個部分：信息的錄入核準、費用的計算核準、履約形式的確認。交易系統的主要功能包括幾項：

記錄用戶信息如名稱、收貨人地址（姓名、聯系方式、地址）、可收貨時間、收貨方式、支付方式、發票等。信息記錄看起來是比較簡單的功能，但這些信息與后面一些計算邏輯是有密切相關的。舉個例子，收貨人地址電商平臺目前業內通用的都是五級地址，即國家、省、市、縣（區）、鎮（街道）、詳細地址。

通過這五級地址可以計算出倉庫配貨的情況，是否有移倉等信息。而用戶賬號的信息可以判斷是否享受VIP價格等優惠。

在計算商品金額之前，我們需要優先把促銷優惠的金額計算出來。促銷優惠根據促銷載體來看會分為商品促銷和集合促銷兩種情況。

商品促銷指的是將優惠的金額直接在商品的價格上做減免或打折，那么當前商品的銷售價格應該為促銷的價格或者折后的促銷價格。

而集合促銷指的是多個商品捆綁進行優惠，比如滿減、滿折等。在計算這種促銷時候需要根據促銷的優惠規則將優惠的金額按照商品價格占比攤到每個商品上。

假定本次購買有N件商品參與優惠，分攤的邏輯為:

優惠券作為一種特殊的促銷形式也需要按照上述促銷的思路進行計算。最終所有的優惠金額都會在商品和訂單兩個維度體現出來。

促銷、優惠券在計算時還需要考慮兩者之間的關系，即是互斥還是共享。在促銷上我們將促銷分為限時搶促銷和其他促銷，因為原則上限時搶屬于單品范疇的最低價格。

而券種上除了一般意義上的紅包優惠券外，我們將線下單獨售賣的儲值卡單獨分開判斷。加上單品的VIP價格我們共有五種優惠方式需要參與計算。

在判斷是否是共享還是互斥的大體思路是盡量避免在同一個細分維度比如品類、單品上做兩次以上促銷減扣，同時核銷方式不同的促銷形式可以進行一定程度的疊加。

這樣來看我們互斥和共享的情況如下：

當然在O2O的場景下單品如果已經執行了特價則訂單不能再進行優惠券的使用，這也是為了避免有同一方承擔雙重補貼的問題。

商品金額計算是指計算當前訂單需要消費的金額情況，這部分的明細內容同訂單系統是一樣的。訂單的最終消費金額 =Sum(商品售賣價格） – 促銷優惠金額 – 優惠券優惠金額– 儲值卡優惠金額 – 其他抵扣 + 運費 + 保險費用。

其中運費的判斷來自于是否滿足運費減免條件，一般平臺的減免掉件都是金額門檻滿足即可減免運費。其他抵扣指的是可能出現的虛擬貨幣的抵扣，比如積分抵扣等。

商品金額計算時候要做最小容錯校驗，訂單的最終金額不能出現負數。當訂單金額小于等于0時考慮核銷的原因訂單金額一般記錄為0.01。有可能出現的場景為多個優惠減免導致，則落訂單時由于已經減免到最小值所有將所有優惠減免項按照優先級判斷使用哪個。

運費是指使用配送服務后需要用戶成單的運輸費用。現在大多數的電商平臺或者店鋪都會通過滿足一定訂單金額減免運費，但運費依然是訂單金額的一個有效組成部分。

運費金額主要是根據配送區域和配送方式來計算的，所以運費的計算依賴于收貨地址的確定。同時運費的計算維度一般是按包裹單進行計算的（關于包裹單的概念后面配送邏輯會講解）。這幾個維度都會決定運費金額的差異。

運費金額一般是通過運費模板來進行設置的，設置的時候就會從這些維度來進行細分，包括但不限于按照收貨地、發送方式、商品件數、金額、是否分合包裹、發出倉、顧客身份等。此外配送方式的多種多樣決定了運費也會不同，平臺一般會配置多套運費模板來設定對應運送方式下的運費規則用以計算使用。配送方式包括：

在支付方式的選取上也需要進行一系列的校驗和判斷處理，一般來說電商平臺的支付方式包括以下幾種：第三方在線支付、銀行卡、余額、白條、儲值卡、優惠券、積分抵扣、COD。

如果選擇COD需要根據收貨地址判斷是否支持，而儲值卡或者優惠券在單個訂單上只能使用一張。多種支付方式則需要在生成訂單時將金額對應到品上以便訂單可以進行后續的操作。

配送邏輯包括配貨邏輯和預計送達時間計算，這兩塊邏輯是緊密關聯的。根據配貨時遠近、商品在庫庫存是否充足、是否需要移倉調撥來滿足訂單等信息，最終預估出預計送達時間。所以送達時間計算的前提是配貨邏輯。

在講解配送邏輯前我們先理解下配送的維度是基于什么維度進行作業的。一般來說我們通常講配送訂單都理解為按照訂單維度進行作業，但實際上訂單也有幾層關系：交易單、訂單、包裹單。

交易單是指顧客一次提交訂單中的所有商品集合，由于電商平臺下單形式是加入購物車后二次選擇進行提交，所以單次提交的商品中可能包括不同商家或者店鋪的商品。有一些平臺級別的集合促銷行為也是基于這個維度進行計算金額的。

交易單不作為配送的標準訂單，系統會按照商家加配送方的維度將交易單拆分成若干的訂單，訂單的判斷依賴于幾個維度：收貨人信息、配送方式、支付方式、發票。這個維度的訂單是屬于用戶的，但實際配送的時候還會根據實際情況進行合拆單。

合拆單是按照配貨邏輯的不同來判斷是否可以一次進行配送即打包成一個包裹，所以這個維度的訂單也叫包裹單。這個訂單是真正意義上可以追蹤的用戶訂單，在這個維度用戶可以進行售后、評價等行為的處理。

理論上商家的配送方式和發貨倉都是統一的，所以訂單和包裹單一般情況數量會是相等，但如果出現同一筆訂單有不同的發貨方式或發貨倉則就會出現一筆訂單多個包裹單的情況。我們講的配貨邏輯是針對于最終的包裹單來說的。

配貨邏輯定義是根據顧客購買地、購買商品品種和庫存計算包裹發出倉和發送方式的邏輯。不同的結果會影響到預計送達時間的變化。配貨邏輯的計算基準是基于收貨人信息五級地址中的第四級也就是我們通常說的行政區。

如果平臺在同一個城市有多個倉則會按區域劃分不同的配送方，但如果同一個城市只有一個倉則可以按照三級城市來進行判斷。一個倉庫可以對應多個區域或者城市進行配送的設置。倉庫我們按照收貨地址的遠近分為本地倉（或者本區域倉）或者外地倉。

如果本地倉無法完成全單配送，則需要通過移倉邏輯完成調動或者判斷是否通過外地倉進行配送。在倉配模式上有幾種情況：

子母倉指在全國范圍內指定部分母倉來覆蓋幾個區域，每個區域有子倉。配貨時優先查看子倉是否全單滿足，如果不滿足則從母倉調撥。如果母倉全單滿足，則直接從母倉發貨不做調撥。

子母倉的結構要確保母倉商品品類豐富充足，母倉即可以當做子倉的供應方又可以作為子倉的補足快速發貨減少移倉時間和成本。子母倉的結構在時下比較流行的新零售領域被稱為大倉和前置倉的概念，邏輯上也是類似。

網狀倉指每個母倉都覆蓋多個區域，可以為不同區域的子倉進行調撥，滿足子倉的訂單出庫。網狀母倉之間覆蓋會有一定的區域重合，配送時選擇哪個母倉調撥優先考慮物流成本和時效。中央倉直發，指[h1]在建立一個全品類的中央倉，中央倉建立在物流較為便利的城市中。

通過中央倉直發商品來解決兜底無法配送的問題。在配置倉庫時無論是母倉還是子倉原則上還是遵從就近原則，盡可能減少運輸成本和移倉次數。

確定配貨邏輯后就可以根據配送情況估算配送時效即預計送達時間了。預計送達時間的處理是根據顧客的收貨地址、下單時間、發送方式、送貨時間、發貨倉庫、支付方式、截單時間計算預計送達時間。按照上述發貨的方式分為直發訂單時間預估和移倉轉發訂單時間預估。

交易系統作為購買流程的中樞系統之一，承擔著所有訂單的計算判斷。很多相關業務系統都可以通過調用交易系統的服務來實現交易環節的功能。上述描述的都是交易系統的核心功能，也是交易系統對外提供的服務能力。

交易系統和訂單系統作為電商平臺的運行樞紐，負責搭建承前啟后的工作。用戶端大量的處理計算邏輯需要通過交易系統進行處理操作。搭建好交易體系是一個電商平臺穩定運行的開端。

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

題圖來自 Unsplash，基于CC0協議