解構(gòu)電商、O2O:電商系統(tǒng)的CPU – 交易系統(tǒng)_第1頁
解構(gòu)電商、O2O:電商系統(tǒng)的CPU – 交易系統(tǒng)_第2頁
解構(gòu)電商、O2O:電商系統(tǒng)的CPU – 交易系統(tǒng)_第3頁
解構(gòu)電商、O2O:電商系統(tǒng)的CPU – 交易系統(tǒng)_第4頁
解構(gòu)電商、O2O:電商系統(tǒng)的CPU – 交易系統(tǒng)_第5頁
已閱讀5頁,還剩7頁未讀, 繼續(xù)免費閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進行舉報或認領(lǐng)

文檔簡介

1、解構(gòu)電商、O2O:電商系統(tǒng)的CPU 交易系統(tǒng)交易系統(tǒng),顧名思義負責完成用戶交易過程的系統(tǒng)。交易的過程主要指通過各種交易的先決條件來判斷應(yīng)該如何確定最終交易的內(nèi)容、事項、金額等信息,整合后提交訂單系統(tǒng)完成訂單生成的工作。通俗地來說就是用戶在確定購買內(nèi)容后和電商平臺簽約并形成書面合同(也就是訂單)的過程。所以合約簽訂的計算、判斷、處理工作都需要交易系統(tǒng)來完成,所以把交易系統(tǒng)可以稱得上是電商平臺的運行“CPU”了。交易系統(tǒng)的主要功能就是負責處理用戶提交的信息以及針對這些信息進行預(yù)處理計算,最后完成訂單提交。從流程上來看交易系統(tǒng)負責的是生成訂單以前的所有環(huán)節(jié),而訂單系統(tǒng)則負責訂單生成后直到履約完成的過

2、程。在一些平臺也會將訂單系統(tǒng)包裹在交易系統(tǒng)之內(nèi),訂單管理作為大交易系統(tǒng)的一個子模塊。我們這里把兩個系統(tǒng)作為平行的關(guān)系進行了拆分,拆分以后的系統(tǒng)對于職能邊界上來說更為清晰些。我們可以用戶下單的整個過程以訂單提交為節(jié)點前面部分屬于交易系統(tǒng),而后面的部分屬于訂單系統(tǒng)。這里特別要單獨說一下購物車,購物車原則上屬于前臺系統(tǒng),但由于他的特殊性,也會涉及到大量的促銷計算和運費計算的邏輯。購物車的后臺可以通過調(diào)用交易系統(tǒng)的服務(wù)來實現(xiàn)上述計算。如圖:就像買房買車一樣在簽訂合同之前銷售人員會針對你的情況和購買的商品做很多預(yù)先的準備工作,比如資質(zhì)的評估、費用的評估、是否有優(yōu)惠的力度等等。這些信息都會通過核對溝通最終

3、達成一致后錄入到合同當中。在電商平臺也是一樣,我們在確定下單之前交易系統(tǒng)也會充當銷售人員的角色根據(jù)用戶填寫信息進行核準判斷、交易金額的明確、促銷情況的明確等,確認通過后完成訂單的下單提交。所以在用戶端負責對接交易系統(tǒng)進行訂單確認的頁面一般也叫訂單確認頁或者結(jié)算頁。接下來我們來看看訂單合同一般都需要對那些事情進行處理和預(yù)先確認。合同雙方分別是電商平臺和用戶,用戶的身份信息就需要記錄下來。這里面有用戶的賬戶信息和收貨人信息。合同中需要交易的商品信息也是合同的主要內(nèi)容之一,包括商品的名稱、編碼(一般系統(tǒng)中以商品ID為準)、商品價格、商品購買數(shù)量等。合同中需要記錄乙方(電商平臺)對于甲方(用戶)提供的

4、服務(wù)條款和服務(wù)收費明細準則,按照電商的術(shù)語說就是運費規(guī)則、促銷規(guī)則、配貨規(guī)則等。根據(jù)上述對于訂單合同的描述我們可以將事項分為幾個部分:信息的錄入核準、費用的計算核準、履約形式的確認。交易系統(tǒng)的主要功能包括幾項:用戶信息記錄商品金額計算促銷優(yōu)惠計算運費計算配送邏輯支付方式判斷邏輯一、用戶信息記錄記錄用戶信息如名稱、收貨人地址(姓名、聯(lián)系方式、地址)、可收貨時間、收貨方式、支付方式、發(fā)票等。信息記錄看起來是比較簡單的功能,但這些信息與后面一些計算邏輯是有密切相關(guān)的。舉個例子,收貨人地址電商平臺目前業(yè)內(nèi)通用的都是五級地址,即國家、省、市、縣(區(qū))、鎮(zhèn)(街道)、詳細地址。通過這五級地址可以計算出倉庫配

5、貨的情況,是否有移倉等信息。而用戶賬號的信息可以判斷是否享受VIP價格等優(yōu)惠。二、促銷優(yōu)惠計算在計算商品金額之前,我們需要優(yōu)先把促銷優(yōu)惠的金額計算出來。促銷優(yōu)惠根據(jù)促銷載體來看會分為商品促銷和集合促銷兩種情況。商品促銷指的是將優(yōu)惠的金額直接在商品的價格上做減免或打折,那么當前商品的銷售價格應(yīng)該為促銷的價格或者折后的促銷價格。而集合促銷指的是多個商品捆綁進行優(yōu)惠,比如滿減、滿折等。在計算這種促銷時候需要根據(jù)促銷的優(yōu)惠規(guī)則將優(yōu)惠的金額按照商品價格占比攤到每個商品上。假定本次購買有N件商品參與優(yōu)惠,分攤的邏輯為:前N-1件商品優(yōu)惠分攤邏輯:平攤在商品上的訂單優(yōu)惠補貼=單品優(yōu)惠價*(訂單優(yōu)惠總金額 /

6、(參與訂單優(yōu)惠的商品對應(yīng)的單品優(yōu)惠價之和)。剩余1件商品優(yōu)惠分攤邏輯:訂單優(yōu)惠金額 平攤在(N-1)件商品上的優(yōu)惠金額。優(yōu)惠券作為一種特殊的促銷形式也需要按照上述促銷的思路進行計算。最終所有的優(yōu)惠金額都會在商品和訂單兩個維度體現(xiàn)出來。促銷、優(yōu)惠券在計算時還需要考慮兩者之間的關(guān)系,即是互斥還是共享。在促銷上我們將促銷分為限時搶促銷和其他促銷,因為原則上限時搶屬于單品范疇的最低價格。而券種上除了一般意義上的紅包優(yōu)惠券外,我們將線下單獨售賣的儲值卡單獨分開判斷。加上單品的VIP價格我們共有五種優(yōu)惠方式需要參與計算。在判斷是否是共享還是互斥的大體思路是盡量避免在同一個細分維度比如品類、單品上做兩次以上

7、促銷減扣,同時核銷方式不同的促銷形式可以進行一定程度的疊加。這樣來看我們互斥和共享的情況如下:當然在O2O的場景下單品如果已經(jīng)執(zhí)行了特價則訂單不能再進行優(yōu)惠券的使用,這也是為了避免有同一方承擔雙重補貼的問題。三、商品金額計算商品金額計算是指計算當前訂單需要消費的金額情況,這部分的明細內(nèi)容同訂單系統(tǒng)是一樣的。訂單的最終消費金額 =Sum(商品售賣價格) 促銷優(yōu)惠金額 優(yōu)惠券優(yōu)惠金額 儲值卡優(yōu)惠金額 其他抵扣 + 運費 + 保險費用。其中運費的判斷來自于是否滿足運費減免條件,一般平臺的減免掉件都是金額門檻滿足即可減免運費。其他抵扣指的是可能出現(xiàn)的虛擬貨幣的抵扣,比如積分抵扣等。商品金額計算時候要做

8、最小容錯校驗,訂單的最終金額不能出現(xiàn)負數(shù)。當訂單金額小于等于0時考慮核銷的原因訂單金額一般記錄為0.01。有可能出現(xiàn)的場景為多個優(yōu)惠減免導(dǎo)致,則落訂單時由于已經(jīng)減免到最小值所有將所有優(yōu)惠減免項按照優(yōu)先級判斷使用哪個。四、運費計算運費是指使用配送服務(wù)后需要用戶成單的運輸費用?,F(xiàn)在大多數(shù)的電商平臺或者店鋪都會通過滿足一定訂單金額減免運費,但運費依然是訂單金額的一個有效組成部分。運費金額主要是根據(jù)配送區(qū)域和配送方式來計算的,所以運費的計算依賴于收貨地址的確定。同時運費的計算維度一般是按包裹單進行計算的(關(guān)于包裹單的概念后面配送邏輯會講解)。這幾個維度都會決定運費金額的差異。運費金額一般是通過運費模板

9、來進行設(shè)置的,設(shè)置的時候就會從這些維度來進行細分,包括但不限于按照收貨地、發(fā)送方式、商品件數(shù)、金額、是否分合包裹、發(fā)出倉、顧客身份等。此外配送方式的多種多樣決定了運費也會不同,平臺一般會配置多套運費模板來設(shè)定對應(yīng)運送方式下的運費規(guī)則用以計算使用。配送方式包括:普通快遞送貨上門平郵特快專遞(EMS)自提3小時遞(8-17點之間下單且完成支付的訂單)慢遞優(yōu)惠順豐快遞轉(zhuǎn)送(如京東配送等)五、支付方式判斷邏輯在支付方式的選取上也需要進行一系列的校驗和判斷處理,一般來說電商平臺的支付方式包括以下幾種:第三方在線支付、銀行卡、余額、白條、儲值卡、優(yōu)惠券、積分抵扣、COD。如果選擇COD需要根據(jù)收貨地址判斷

10、是否支持,而儲值卡或者優(yōu)惠券在單個訂單上只能使用一張。多種支付方式則需要在生成訂單時將金額對應(yīng)到品上以便訂單可以進行后續(xù)的操作。六、配送邏輯配送邏輯包括配貨邏輯和預(yù)計送達時間計算,這兩塊邏輯是緊密關(guān)聯(lián)的。根據(jù)配貨時遠近、商品在庫庫存是否充足、是否需要移倉調(diào)撥來滿足訂單等信息,最終預(yù)估出預(yù)計送達時間。所以送達時間計算的前提是配貨邏輯。在講解配送邏輯前我們先理解下配送的維度是基于什么維度進行作業(yè)的。一般來說我們通常講配送訂單都理解為按照訂單維度進行作業(yè),但實際上訂單也有幾層關(guān)系:交易單、訂單、包裹單。交易單是指顧客一次提交訂單中的所有商品集合,由于電商平臺下單形式是加入購物車后二次選擇進行提交,所

11、以單次提交的商品中可能包括不同商家或者店鋪的商品。有一些平臺級別的集合促銷行為也是基于這個維度進行計算金額的。交易單不作為配送的標準訂單,系統(tǒng)會按照商家加配送方的維度將交易單拆分成若干的訂單,訂單的判斷依賴于幾個維度:收貨人信息、配送方式、支付方式、發(fā)票。這個維度的訂單是屬于用戶的,但實際配送的時候還會根據(jù)實際情況進行合拆單。合拆單是按照配貨邏輯的不同來判斷是否可以一次進行配送即打包成一個包裹,所以這個維度的訂單也叫包裹單。這個訂單是真正意義上可以追蹤的用戶訂單,在這個維度用戶可以進行售后、評價等行為的處理。理論上商家的配送方式和發(fā)貨倉都是統(tǒng)一的,所以訂單和包裹單一般情況數(shù)量會是相等,但如果出

12、現(xiàn)同一筆訂單有不同的發(fā)貨方式或發(fā)貨倉則就會出現(xiàn)一筆訂單多個包裹單的情況。我們講的配貨邏輯是針對于最終的包裹單來說的。配貨邏輯定義是根據(jù)顧客購買地、購買商品品種和庫存計算包裹發(fā)出倉和發(fā)送方式的邏輯。不同的結(jié)果會影響到預(yù)計送達時間的變化。配貨邏輯的計算基準是基于收貨人信息五級地址中的第四級也就是我們通常說的行政區(qū)。如果平臺在同一個城市有多個倉則會按區(qū)域劃分不同的配送方,但如果同一個城市只有一個倉則可以按照三級城市來進行判斷。一個倉庫可以對應(yīng)多個區(qū)域或者城市進行配送的設(shè)置。倉庫我們按照收貨地址的遠近分為本地倉(或者本區(qū)域倉)或者外地倉。如果本地倉無法完成全單配送,則需要通過移倉邏輯完成調(diào)動或者判斷是

13、否通過外地倉進行配送。在倉配模式上有幾種情況:區(qū)域子母倉配貨網(wǎng)狀倉配貨中央倉直發(fā)子母倉指在全國范圍內(nèi)指定部分母倉來覆蓋幾個區(qū)域,每個區(qū)域有子倉。配貨時優(yōu)先查看子倉是否全單滿足,如果不滿足則從母倉調(diào)撥。如果母倉全單滿足,則直接從母倉發(fā)貨不做調(diào)撥。子母倉的結(jié)構(gòu)要確保母倉商品品類豐富充足,母倉即可以當做子倉的供應(yīng)方又可以作為子倉的補足快速發(fā)貨減少移倉時間和成本。子母倉的結(jié)構(gòu)在時下比較流行的新零售領(lǐng)域被稱為大倉和前置倉的概念,邏輯上也是類似。網(wǎng)狀倉指每個母倉都覆蓋多個區(qū)域,可以為不同區(qū)域的子倉進行調(diào)撥,滿足子倉的訂單出庫。網(wǎng)狀母倉之間覆蓋會有一定的區(qū)域重合,配送時選擇哪個母倉調(diào)撥優(yōu)先考慮物流成本和時效。中央倉直發(fā),指h1在建立一個全品類的中央倉,中央倉建立在物流較為便利的城市中。通過中央倉直發(fā)商品來解決兜底無法配送的問題。在配置倉庫時無論是母倉還是子倉原則上還是遵從就近原則,盡可能減少運輸成本和移倉次數(shù)。確定配貨邏輯后就可以根據(jù)配送情況估算配送時效即預(yù)計送達時間了。預(yù)計送達時間的處理是根據(jù)顧客的收貨地址、下單時間、發(fā)送方式、送貨時間、發(fā)貨倉庫、支付方式、截單時間計算預(yù)計送達時間。按照上述發(fā)貨的方式分為直發(fā)訂單時間預(yù)估和移倉轉(zhuǎn)發(fā)訂單時間預(yù)估。直發(fā)訂單:預(yù)計送達時間 = 生產(chǎn)時間 +

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權(quán)或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論