解構(gòu)電商、O2O:電商系統(tǒng)的CPU – 交易系統(tǒng)
編輯導(dǎo)語:交易系統(tǒng)就是用戶在確定購買內(nèi)容后和電商平臺(tái)簽約并生成訂單的過程,主要功能是負(fù)責(zé)處理用戶提交的信息。本篇文章系統(tǒng)地分析了電商平臺(tái)的交易系統(tǒng)主要流程和功能,一起來看看。
交易系統(tǒng),顧名思義負(fù)責(zé)完成用戶交易過程的系統(tǒng)。交易的過程主要指通過各種交易的先決條件來判斷應(yīng)該如何確定最終交易的內(nèi)容、事項(xiàng)、金額等信息,整合后提交訂單系統(tǒng)完成訂單生成的工作。
通俗地來說就是用戶在確定購買內(nèi)容后和電商平臺(tái)簽約并形成書面合同(也就是訂單)的過程。
所以合約簽訂的計(jì)算、判斷、處理工作都需要交易系統(tǒng)來完成,所以把交易系統(tǒng)可以稱得上是電商平臺(tái)的運(yùn)行“CPU”了。
交易系統(tǒng)的主要功能就是負(fù)責(zé)處理用戶提交的信息以及針對(duì)這些信息進(jìn)行預(yù)處理計(jì)算,最后完成訂單提交。從流程上來看交易系統(tǒng)負(fù)責(zé)的是生成訂單以前的所有環(huán)節(jié),而訂單系統(tǒng)則負(fù)責(zé)訂單生成后直到履約完成的過程。
在一些平臺(tái)也會(huì)將訂單系統(tǒng)包裹在交易系統(tǒng)之內(nèi),訂單管理作為大交易系統(tǒng)的一個(gè)子模塊。我們這里把兩個(gè)系統(tǒng)作為平行的關(guān)系進(jìn)行了拆分,拆分以后的系統(tǒng)對(duì)于職能邊界上來說更為清晰些。我們可以用戶下單的整個(gè)過程以訂單提交為節(jié)點(diǎn)前面部分屬于交易系統(tǒng),而后面的部分屬于訂單系統(tǒng)。
這里特別要單獨(dú)說一下購物車,購物車原則上屬于前臺(tái)系統(tǒng),但由于他的特殊性,也會(huì)涉及到大量的促銷計(jì)算和運(yùn)費(fèi)計(jì)算的邏輯。購物車的后臺(tái)可以通過調(diào)用交易系統(tǒng)的服務(wù)來實(shí)現(xiàn)上述計(jì)算。如圖:
就像買房買車一樣在簽訂合同之前銷售人員會(huì)針對(duì)你的情況和購買的商品做很多預(yù)先的準(zhǔn)備工作,比如資質(zhì)的評(píng)估、費(fèi)用的評(píng)估、是否有優(yōu)惠的力度等等。這些信息都會(huì)通過核對(duì)溝通最終達(dá)成一致后錄入到合同當(dāng)中。
在電商平臺(tái)也是一樣,我們?cè)诖_定下單之前交易系統(tǒng)也會(huì)充當(dāng)銷售人員的角色根據(jù)用戶填寫信息進(jìn)行核準(zhǔn)判斷、交易金額的明確、促銷情況的明確等,確認(rèn)通過后完成訂單的下單提交。所以在用戶端負(fù)責(zé)對(duì)接交易系統(tǒng)進(jìn)行訂單確認(rèn)的頁面一般也叫訂單確認(rèn)頁或者結(jié)算頁。
接下來我們來看看訂單合同一般都需要對(duì)那些事情進(jìn)行處理和預(yù)先確認(rèn)。
- 合同雙方分別是電商平臺(tái)和用戶,用戶的身份信息就需要記錄下來。這里面有用戶的賬戶信息和收貨人信息。
- 合同中需要交易的商品信息也是合同的主要內(nèi)容之一,包括商品的名稱、編碼(一般系統(tǒng)中以商品ID為準(zhǔn))、商品價(jià)格、商品購買數(shù)量等。
- 合同中需要記錄乙方(電商平臺(tái))對(duì)于甲方(用戶)提供的服務(wù)條款和服務(wù)收費(fèi)明細(xì)準(zhǔn)則,按照電商的術(shù)語說就是運(yùn)費(fèi)規(guī)則、促銷規(guī)則、配貨規(guī)則等。
根據(jù)上述對(duì)于訂單合同的描述我們可以將事項(xiàng)分為幾個(gè)部分:信息的錄入核準(zhǔn)、費(fèi)用的計(jì)算核準(zhǔn)、履約形式的確認(rèn)。交易系統(tǒng)的主要功能包括幾項(xiàng):
- 用戶信息記錄
- 商品金額計(jì)算
- 促銷優(yōu)惠計(jì)算
- 運(yùn)費(fèi)計(jì)算
- 配送邏輯
- 支付方式判斷邏輯
一、用戶信息記錄
記錄用戶信息如名稱、收貨人地址(姓名、聯(lián)系方式、地址)、可收貨時(shí)間、收貨方式、支付方式、發(fā)票等。信息記錄看起來是比較簡單的功能,但這些信息與后面一些計(jì)算邏輯是有密切相關(guān)的。舉個(gè)例子,收貨人地址電商平臺(tái)目前業(yè)內(nèi)通用的都是五級(jí)地址,即國家、省、市、縣(區(qū))、鎮(zhèn)(街道)、詳細(xì)地址。
通過這五級(jí)地址可以計(jì)算出倉庫配貨的情況,是否有移倉等信息。而用戶賬號(hào)的信息可以判斷是否享受VIP價(jià)格等優(yōu)惠。
二、促銷優(yōu)惠計(jì)算
在計(jì)算商品金額之前,我們需要優(yōu)先把促銷優(yōu)惠的金額計(jì)算出來。促銷優(yōu)惠根據(jù)促銷載體來看會(huì)分為商品促銷和集合促銷兩種情況。
商品促銷指的是將優(yōu)惠的金額直接在商品的價(jià)格上做減免或打折,那么當(dāng)前商品的銷售價(jià)格應(yīng)該為促銷的價(jià)格或者折后的促銷價(jià)格。
而集合促銷指的是多個(gè)商品捆綁進(jìn)行優(yōu)惠,比如滿減、滿折等。在計(jì)算這種促銷時(shí)候需要根據(jù)促銷的優(yōu)惠規(guī)則將優(yōu)惠的金額按照商品價(jià)格占比攤到每個(gè)商品上。
假定本次購買有N件商品參與優(yōu)惠,分?jǐn)偟倪壿嫗?
- 前N-1件商品優(yōu)惠分?jǐn)傔壿嫞浩綌傇谏唐飞系挠唵蝺?yōu)惠補(bǔ)貼=單品優(yōu)惠價(jià)*(訂單優(yōu)惠總金額 /(參與訂單優(yōu)惠的商品對(duì)應(yīng)的單品優(yōu)惠價(jià)之和))。
- 剩余1件商品優(yōu)惠分?jǐn)傔壿嫞河唵蝺?yōu)惠金額 – 平攤在(N-1)件商品上的優(yōu)惠金額。
優(yōu)惠券作為一種特殊的促銷形式也需要按照上述促銷的思路進(jìn)行計(jì)算。最終所有的優(yōu)惠金額都會(huì)在商品和訂單兩個(gè)維度體現(xiàn)出來。
促銷、優(yōu)惠券在計(jì)算時(shí)還需要考慮兩者之間的關(guān)系,即是互斥還是共享。在促銷上我們將促銷分為限時(shí)搶促銷和其他促銷,因?yàn)樵瓌t上限時(shí)搶屬于單品范疇的最低價(jià)格。
而券種上除了一般意義上的紅包優(yōu)惠券外,我們將線下單獨(dú)售賣的儲(chǔ)值卡單獨(dú)分開判斷。加上單品的VIP價(jià)格我們共有五種優(yōu)惠方式需要參與計(jì)算。
在判斷是否是共享還是互斥的大體思路是盡量避免在同一個(gè)細(xì)分維度比如品類、單品上做兩次以上促銷減扣,同時(shí)核銷方式不同的促銷形式可以進(jìn)行一定程度的疊加。
這樣來看我們互斥和共享的情況如下:
當(dāng)然在O2O的場景下單品如果已經(jīng)執(zhí)行了特價(jià)則訂單不能再進(jìn)行優(yōu)惠券的使用,這也是為了避免有同一方承擔(dān)雙重補(bǔ)貼的問題。
三、商品金額計(jì)算
商品金額計(jì)算是指計(jì)算當(dāng)前訂單需要消費(fèi)的金額情況,這部分的明細(xì)內(nèi)容同訂單系統(tǒng)是一樣的。訂單的最終消費(fèi)金額 =Sum(商品售賣價(jià)格) – 促銷優(yōu)惠金額 – 優(yōu)惠券優(yōu)惠金額– 儲(chǔ)值卡優(yōu)惠金額 – 其他抵扣 + 運(yùn)費(fèi) + 保險(xiǎn)費(fèi)用。
其中運(yùn)費(fèi)的判斷來自于是否滿足運(yùn)費(fèi)減免條件,一般平臺(tái)的減免掉件都是金額門檻滿足即可減免運(yùn)費(fèi)。其他抵扣指的是可能出現(xiàn)的虛擬貨幣的抵扣,比如積分抵扣等。
商品金額計(jì)算時(shí)候要做最小容錯(cuò)校驗(yàn),訂單的最終金額不能出現(xiàn)負(fù)數(shù)。當(dāng)訂單金額小于等于0時(shí)考慮核銷的原因訂單金額一般記錄為0.01。有可能出現(xiàn)的場景為多個(gè)優(yōu)惠減免導(dǎo)致,則落訂單時(shí)由于已經(jīng)減免到最小值所有將所有優(yōu)惠減免項(xiàng)按照優(yōu)先級(jí)判斷使用哪個(gè)。
四、運(yùn)費(fèi)計(jì)算
運(yùn)費(fèi)是指使用配送服務(wù)后需要用戶成單的運(yùn)輸費(fèi)用。現(xiàn)在大多數(shù)的電商平臺(tái)或者店鋪都會(huì)通過滿足一定訂單金額減免運(yùn)費(fèi),但運(yùn)費(fèi)依然是訂單金額的一個(gè)有效組成部分。
運(yùn)費(fèi)金額主要是根據(jù)配送區(qū)域和配送方式來計(jì)算的,所以運(yùn)費(fèi)的計(jì)算依賴于收貨地址的確定。同時(shí)運(yùn)費(fèi)的計(jì)算維度一般是按包裹單進(jìn)行計(jì)算的(關(guān)于包裹單的概念后面配送邏輯會(huì)講解)。這幾個(gè)維度都會(huì)決定運(yùn)費(fèi)金額的差異。
運(yùn)費(fèi)金額一般是通過運(yùn)費(fèi)模板來進(jìn)行設(shè)置的,設(shè)置的時(shí)候就會(huì)從這些維度來進(jìn)行細(xì)分,包括但不限于按照收貨地、發(fā)送方式、商品件數(shù)、金額、是否分合包裹、發(fā)出倉、顧客身份等。此外配送方式的多種多樣決定了運(yùn)費(fèi)也會(huì)不同,平臺(tái)一般會(huì)配置多套運(yùn)費(fèi)模板來設(shè)定對(duì)應(yīng)運(yùn)送方式下的運(yùn)費(fèi)規(guī)則用以計(jì)算使用。配送方式包括:
- 普通快遞送貨上門
- 平郵
- 特快專遞(EMS)
- 自提
- 3小時(shí)遞(8-17點(diǎn)之間下單且完成支付的訂單)
- 慢遞優(yōu)惠
- 順豐快遞
- 轉(zhuǎn)送(如京東配送等)
- ……
五、支付方式判斷邏輯
在支付方式的選取上也需要進(jìn)行一系列的校驗(yàn)和判斷處理,一般來說電商平臺(tái)的支付方式包括以下幾種:第三方在線支付、銀行卡、余額、白條、儲(chǔ)值卡、優(yōu)惠券、積分抵扣、COD。
如果選擇COD需要根據(jù)收貨地址判斷是否支持,而儲(chǔ)值卡或者優(yōu)惠券在單個(gè)訂單上只能使用一張。多種支付方式則需要在生成訂單時(shí)將金額對(duì)應(yīng)到品上以便訂單可以進(jìn)行后續(xù)的操作。
六、配送邏輯
配送邏輯包括配貨邏輯和預(yù)計(jì)送達(dá)時(shí)間計(jì)算,這兩塊邏輯是緊密關(guān)聯(lián)的。根據(jù)配貨時(shí)遠(yuǎn)近、商品在庫庫存是否充足、是否需要移倉調(diào)撥來滿足訂單等信息,最終預(yù)估出預(yù)計(jì)送達(dá)時(shí)間。所以送達(dá)時(shí)間計(jì)算的前提是配貨邏輯。
在講解配送邏輯前我們先理解下配送的維度是基于什么維度進(jìn)行作業(yè)的。一般來說我們通常講配送訂單都理解為按照訂單維度進(jìn)行作業(yè),但實(shí)際上訂單也有幾層關(guān)系:交易單、訂單、包裹單。
交易單是指顧客一次提交訂單中的所有商品集合,由于電商平臺(tái)下單形式是加入購物車后二次選擇進(jìn)行提交,所以單次提交的商品中可能包括不同商家或者店鋪的商品。有一些平臺(tái)級(jí)別的集合促銷行為也是基于這個(gè)維度進(jìn)行計(jì)算金額的。
交易單不作為配送的標(biāo)準(zhǔn)訂單,系統(tǒng)會(huì)按照商家加配送方的維度將交易單拆分成若干的訂單,訂單的判斷依賴于幾個(gè)維度:收貨人信息、配送方式、支付方式、發(fā)票。這個(gè)維度的訂單是屬于用戶的,但實(shí)際配送的時(shí)候還會(huì)根據(jù)實(shí)際情況進(jìn)行合拆單。
合拆單是按照配貨邏輯的不同來判斷是否可以一次進(jìn)行配送即打包成一個(gè)包裹,所以這個(gè)維度的訂單也叫包裹單。這個(gè)訂單是真正意義上可以追蹤的用戶訂單,在這個(gè)維度用戶可以進(jìn)行售后、評(píng)價(jià)等行為的處理。
理論上商家的配送方式和發(fā)貨倉都是統(tǒng)一的,所以訂單和包裹單一般情況數(shù)量會(huì)是相等,但如果出現(xiàn)同一筆訂單有不同的發(fā)貨方式或發(fā)貨倉則就會(huì)出現(xiàn)一筆訂單多個(gè)包裹單的情況。我們講的配貨邏輯是針對(duì)于最終的包裹單來說的。
配貨邏輯定義是根據(jù)顧客購買地、購買商品品種和庫存計(jì)算包裹發(fā)出倉和發(fā)送方式的邏輯。不同的結(jié)果會(huì)影響到預(yù)計(jì)送達(dá)時(shí)間的變化。配貨邏輯的計(jì)算基準(zhǔn)是基于收貨人信息五級(jí)地址中的第四級(jí)也就是我們通常說的行政區(qū)。
如果平臺(tái)在同一個(gè)城市有多個(gè)倉則會(huì)按區(qū)域劃分不同的配送方,但如果同一個(gè)城市只有一個(gè)倉則可以按照三級(jí)城市來進(jìn)行判斷。一個(gè)倉庫可以對(duì)應(yīng)多個(gè)區(qū)域或者城市進(jìn)行配送的設(shè)置。倉庫我們按照收貨地址的遠(yuǎn)近分為本地倉(或者本區(qū)域倉)或者外地倉。
如果本地倉無法完成全單配送,則需要通過移倉邏輯完成調(diào)動(dòng)或者判斷是否通過外地倉進(jìn)行配送。在倉配模式上有幾種情況:
- 區(qū)域子母倉配貨
- 網(wǎng)狀倉配貨
- 中央倉直發(fā)
子母倉指在全國范圍內(nèi)指定部分母倉來覆蓋幾個(gè)區(qū)域,每個(gè)區(qū)域有子倉。配貨時(shí)優(yōu)先查看子倉是否全單滿足,如果不滿足則從母倉調(diào)撥。如果母倉全單滿足,則直接從母倉發(fā)貨不做調(diào)撥。
子母倉的結(jié)構(gòu)要確保母倉商品品類豐富充足,母倉即可以當(dāng)做子倉的供應(yīng)方又可以作為子倉的補(bǔ)足快速發(fā)貨減少移倉時(shí)間和成本。子母倉的結(jié)構(gòu)在時(shí)下比較流行的新零售領(lǐng)域被稱為大倉和前置倉的概念,邏輯上也是類似。
網(wǎng)狀倉指每個(gè)母倉都覆蓋多個(gè)區(qū)域,可以為不同區(qū)域的子倉進(jìn)行調(diào)撥,滿足子倉的訂單出庫。網(wǎng)狀母倉之間覆蓋會(huì)有一定的區(qū)域重合,配送時(shí)選擇哪個(gè)母倉調(diào)撥優(yōu)先考慮物流成本和時(shí)效。中央倉直發(fā),指[h1]在建立一個(gè)全品類的中央倉,中央倉建立在物流較為便利的城市中。
通過中央倉直發(fā)商品來解決兜底無法配送的問題。在配置倉庫時(shí)無論是母倉還是子倉原則上還是遵從就近原則,盡可能減少運(yùn)輸成本和移倉次數(shù)。
確定配貨邏輯后就可以根據(jù)配送情況估算配送時(shí)效即預(yù)計(jì)送達(dá)時(shí)間了。預(yù)計(jì)送達(dá)時(shí)間的處理是根據(jù)顧客的收貨地址、下單時(shí)間、發(fā)送方式、送貨時(shí)間、發(fā)貨倉庫、支付方式、截單時(shí)間計(jì)算預(yù)計(jì)送達(dá)時(shí)間。按照上述發(fā)貨的方式分為直發(fā)訂單時(shí)間預(yù)估和移倉轉(zhuǎn)發(fā)訂單時(shí)間預(yù)估。
- 直發(fā)訂單:預(yù)計(jì)送達(dá)時(shí)間 = 生產(chǎn)時(shí)間 + 最長送貨時(shí)間
- 移倉訂單:預(yù)計(jì)送達(dá)時(shí)間 = 移倉時(shí)間 + 直發(fā)訂單發(fā)送時(shí)間
交易系統(tǒng)作為購買流程的中樞系統(tǒng)之一,承擔(dān)著所有訂單的計(jì)算判斷。很多相關(guān)業(yè)務(wù)系統(tǒng)都可以通過調(diào)用交易系統(tǒng)的服務(wù)來實(shí)現(xiàn)交易環(huán)節(jié)的功能。上述描述的都是交易系統(tǒng)的核心功能,也是交易系統(tǒng)對(duì)外提供的服務(wù)能力。
七、總結(jié)
交易系統(tǒng)和訂單系統(tǒng)作為電商平臺(tái)的運(yùn)行樞紐,負(fù)責(zé)搭建承前啟后的工作。用戶端大量的處理計(jì)算邏輯需要通過交易系統(tǒng)進(jìn)行處理操作。搭建好交易體系是一個(gè)電商平臺(tái)穩(wěn)定運(yùn)行的開端。
#專欄作家#
高暉,微信號(hào)公眾號(hào):產(chǎn)品老高,人人都是產(chǎn)品經(jīng)理專欄作家。10余年IT經(jīng)驗(yàn),互聯(lián)網(wǎng)老兵。多年電商公司經(jīng)歷,曾參與過B2B/B2C/O2O等多個(gè)方向的電商項(xiàng)目,熟悉電商全流程產(chǎn)品線情況。
本文原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 Unsplash,基于CC0協(xié)議
這個(gè)優(yōu)惠分?jǐn)偟倪壿嫑]懂,不是商品售價(jià)占比去分?jǐn)偅?/p>