訂單信息與狀態(tài)流轉(zhuǎn),看這一篇就夠了
前言訂單產(chǎn)生后,接下來會繼續(xù)進(jìn)行一系列流轉(zhuǎn),最后送到用戶手里。在每個環(huán)節(jié)都有對應(yīng)的操作,數(shù)據(jù)信息也要求其完成性,可以根據(jù)訂單的每個狀態(tài)變化,來計算分析,進(jìn)而進(jìn)行優(yōu)化供應(yīng)鏈路徑,以提升訂單處理效率,提高用戶體驗。本篇就依據(jù)經(jīng)驗從訂單信息及訂單狀態(tài)兩方面拆解來說下本人對訂單涉及的系統(tǒng)或業(yè)務(wù)流程。
訂單信息
1. 關(guān)鍵字段
訂單的流轉(zhuǎn)效率取決于信息系統(tǒng)的數(shù)據(jù)流轉(zhuǎn)同時結(jié)合倉庫、快遞的商品流轉(zhuǎn),所以有幾個關(guān)鍵字段要提前關(guān)注并了解。
- 訂單是從哪流入到OMS(訂單管理系統(tǒng))的,這就是訂單來源。不同來源的訂單銷賣渠道不同,而且有的流轉(zhuǎn)也是不同的,如由第三方負(fù)責(zé)發(fā)貨的訂單,系統(tǒng)是需要根據(jù)開放平臺來傳遞信息,對于發(fā)貨、物流等控制與自營訂單不同。
- 訂單是什么類型的,因為訂單類型不同,在OMS系統(tǒng)中處理有所不同,有的可以有跨節(jié)點,有的可能是逆向流程,如退貨訂單在是從用戶到商家的一個過程,它與正向訂單的處理要復(fù)雜,因為它是要根據(jù)正向訂單流轉(zhuǎn)過程中產(chǎn)生的信息進(jìn)行獲取再根據(jù)規(guī)則進(jìn)行計算處理。
- 倉庫,即訂單來了要送到哪里去作業(yè)處理,在倉庫中的流轉(zhuǎn)需要有哪些標(biāo)準(zhǔn)流程,不同的倉可能歸屬不同的分公司,那么在成本核算上又會有哪些不同,雖然在OMS前期不關(guān)注,但要保證這些信息的準(zhǔn)確性。而且對于有的商家在A倉缺貨后,可能安排B倉發(fā)貨即訂單轉(zhuǎn)倉,不通過倉間調(diào)撥的方式,所以訂單中要記錄最終的發(fā)貨倉。
- 支付狀態(tài),此字段與支付相關(guān),不同的支付方式需要對接不同的接口,狀態(tài)的回傳是否及時等等。支付狀態(tài)與訂單狀態(tài)可以合并成一個字段。
- ?訂單狀態(tài),即在不同的操作節(jié)點上訂單所處的狀態(tài),有些信息是展示給用戶的,有的是內(nèi)部查看的。后續(xù)有詳細(xì)的介紹。
2. 訂單信息
訂單生成時簡單說了下訂單信息包括訂單基本信息與訂單商品信息,還包括很多附屬信息,如支付明細(xì)、關(guān)聯(lián)用戶、使用的禮品卡明細(xì)等等,具體如下圖。
(1)訂單基本信息
訂單信息即訂單主表信息,我這里將分為訂單號、下單用戶信息、訂單基礎(chǔ)信息、支付信息、收貨信息和物流信息幾個小部分。
1)訂單號:單獨列出來了,大家可能有疑問,這里解釋一下。
- 訂單號雖然只是一個單據(jù)號,但是這個號碼格式是什么樣的需要經(jīng)過設(shè)計,因為有的公司訂單號是年月日+序列號或隨機(jī)號方式,這樣設(shè)計沒有什么問題,因為只要保證唯一性就可以了。但是,對于一些公司為了避免數(shù)據(jù)泄露(如友商通過訂單號分析日訂單量)在單據(jù)號格式進(jìn)行了一些處理。
- 此外,在履單過程中,單號是流轉(zhuǎn)過程中非常重要的字段,所以如果好的OMS系統(tǒng)可以根據(jù)訂單號進(jìn)行分發(fā)流轉(zhuǎn),操作人員也可以根據(jù)單號來人為判斷其訂單類型或倉庫等信息。附:Amazon中國的訂單號格式:C01-2442712-9062228 ;京東訂單號:106697775485;淘寶訂單號:786699393282068525
- 訂單號的生成是需要有一個組件支撐的,首先要能夠滿足訂單量的增長、用戶并發(fā)等要求,其次隨著數(shù)據(jù)量的增長訂單表是要進(jìn)行橫向或縱向拆分進(jìn)行分庫分表,數(shù)據(jù)進(jìn)行分布式存儲(有興趣的可以看下《大眾點評訂單系統(tǒng)分庫分表實踐》)。我們曾開啟過分庫分表項目實踐,但因種種原因推進(jìn)不順利,最終僅上線了單號生成器及一些服務(wù)組件,挺遺憾的。
2)基礎(chǔ)信息:
包括除單號的主要信息如來源、分類、狀態(tài)、歸屬、所屬倉庫等,由于訂單表未來是數(shù)據(jù)量最大的,所以每個字段設(shè)計時需要考慮其真正的意義及是否能夠滿足未來的擴(kuò)展。
隨著時間的推移及業(yè)務(wù)的快速變化與增長,未來有很多種可能會迫使你去加字段或?qū)⒃侄芜M(jìn)行二次定義,使得此表在開發(fā)過程中要進(jìn)行不斷轉(zhuǎn)義才可以,大大增加了代碼的復(fù)雜度。個人是比較傾向于預(yù)定義幾個預(yù)留字段,優(yōu)劣大家在設(shè)計時去衡量吧。
3)支付信息:
支付主要是對在訂單級使用的優(yōu)惠券、禮品卡、積分及折扣等,在前端訂單進(jìn)入到結(jié)算頁時會根據(jù)相關(guān)信息進(jìn)行計算并記錄,同時在單據(jù)查時一般遵循:訂單金額 -優(yōu)惠券-禮品卡-積分=應(yīng)付金額;訂單金額=訂單商品金額+運(yùn)費(fèi)金額;訂單商品金額=商品實際售價*商品售賣數(shù)量。
4)收貨信息:
訂單的下單用戶與收貨人可能是不同的,為了更好的提高用戶體驗,有的訂單可以預(yù)約送貨時間等,所以此部分信息可以單獨列出來或以附屬信息進(jìn)行護(hù)展。
5)物流信息:
這里需要記錄快遞公司及物流單號,與物流明細(xì)信息進(jìn)行關(guān)聯(lián)調(diào)用。
(2)訂單商品信息
這個表是交易的明細(xì)商品信息,自然包括商品的基本信息,同時包括交易時的商品價格、優(yōu)惠信息,同時還應(yīng)包括交易過程中商品參與的活動等信息。
商品信息表是訂單從表,數(shù)據(jù)量是訂單表的幾倍或十幾倍,同時對于訂單級別的一些優(yōu)惠金額需要根據(jù)商品進(jìn)行分?jǐn)偂S捎诎l(fā)票是根據(jù)商品信息進(jìn)行的,所以在分?jǐn)偨痤~時要注意尾差;同時在訂單發(fā)生退換貨時是要根據(jù)商品進(jìn)行金額的重攤重算。
對于退換貨時的重攤重算,這里啰嗦一下,是針對于用戶下單時已經(jīng)享受了訂單級或商品的促銷活動,當(dāng)發(fā)生退貨或換貨后由于商品發(fā)生變化,使得訂單級或換的商品不能再享受其促銷優(yōu)惠了,需要重新計算優(yōu)惠金額的過程。
(3)開票信息
對于開票信息,從京東上截了一張圖片,參考下即可。
(4)支付明細(xì)
對于支付,在訂單生成時簡單聊過,這里強(qiáng)調(diào)一下是針對于各種支付方式的支付明細(xì)數(shù)據(jù)。以前說過,涉及到錢的信息不能馬虎,一定要記錄清楚,要有交易流水號(我司或第三方機(jī)構(gòu)的),有狀態(tài)變化的過程即支付日志。
此部分后續(xù)會進(jìn)入到財務(wù)系統(tǒng)進(jìn)行應(yīng)收對賬,同時發(fā)生退款時需要檢驗。對于支付系統(tǒng)如何設(shè)計與研發(fā)就不啰嗦了,官方的話就是要保證數(shù)據(jù)的準(zhǔn)確、及時以及發(fā)生異常后的補(bǔ)償措施;在結(jié)算時要盡可能提升響應(yīng)時間,哪怕1ms也可能大大提升用戶體驗。
對于支付,一般都是按父訂單進(jìn)行的,后續(xù)如果發(fā)生拆單,則相關(guān)的支付信息還需要通過父單號進(jìn)行關(guān)聯(lián)。
(5)物流明細(xì)
下面根據(jù)狀態(tài)分解時,仍會提到,這里也只展示一張圖片供參考。
(6)訂單附屬表
此部分是根據(jù)實際業(yè)務(wù)情況進(jìn)行設(shè)計,譬如訂單支付過程使用了禮品卡,那么就需要記錄禮品卡與訂單號的關(guān)系,同時記錄使用了多少錢,余額是多少,什么時間扣款的,這些需要與禮品卡系統(tǒng)進(jìn)行關(guān)聯(lián),以保證此用戶名下的禮品的金額變化是有跡可循的。
同理,積分支付需要記錄使用積分支付時多少積分抵多少錢,此訂單用了多少積分,用戶還有多少積分余額等這些時點性的信息。
還是那句話,與錢相關(guān)的信息馬虎不得;對于其它需要記錄的信息,如果不方便或不能記錄在訂單請表或商品表中,都可以通過附加表方式。但要清楚附屬表越多,代碼可能會復(fù)雜,但對于遷庫遷表可能會容易些。
至此,對于訂單信息的分解就算完成了,訂單一般都會經(jīng)過拆單即一個訂單會拆分成不同的子訂單,后續(xù)的履單都是根據(jù)子訂單進(jìn)行的,下面從狀態(tài)的角度再來梳理下。
訂單狀態(tài)
訂單的狀態(tài),我將其分為三部分:
- 用戶相關(guān)的狀態(tài),即用戶在我的訂單中可以查看跟蹤的訂單狀態(tài)變化;
- 倉庫/商家的狀態(tài),是指訂單分配到倉庫或商家后,在其作業(yè)過程中產(chǎn)生的狀態(tài);
- 物流狀態(tài),即倉庫/商家發(fā)貨后,包裹發(fā)貨到用戶簽收過程中的相關(guān)狀態(tài)。
下面,按照新建到用戶簽收這一個完整過程來分別說下我的理解。
新建:即用戶選擇商品后,提交后產(chǎn)生的新訂單。訂單產(chǎn)生前是根據(jù)用戶選擇的收貨地址進(jìn)行商品的庫存判斷、商品的優(yōu)惠活動、訂單的優(yōu)惠活動以及用戶選擇的支付方式、開票信息等生成的,詳細(xì)過程大家可以參照《電商后臺-訂單生成》。
支付:用戶支付已提交的訂單,這時就需要記錄支付的詳細(xì)信息,支付完成后,訂單狀態(tài)就變?yōu)橐阎Ц叮藭r訂單距離發(fā)貨還需要經(jīng)歷幾個過程。
- 拉單服務(wù):是將前端服務(wù)器產(chǎn)生的訂單拉取到后端生產(chǎn)庫(一般也叫內(nèi)部ERP庫),這個就是要求快,不能有訂單的積壓。
- 拆單服務(wù):折單分為兩部分,在前端下單時會進(jìn)行預(yù)拆單,即將不同的商品根據(jù)規(guī)則進(jìn)行分堆打標(biāo),供后續(xù)的拆單服務(wù)使用。拆單是在支付完成后進(jìn)行的,這時會根據(jù)商品的屬性、配送條件要求或是否缺貨等原因進(jìn)行拆分,這時是將商品進(jìn)行分堆,然后生成子訂單,一般訂單主表的相關(guān)金額信息會根據(jù)子訂單的商品重新計算。拆單規(guī)則有很多,此篇不深入梳理了。
- 訂單下發(fā)服務(wù):WMS系統(tǒng)是與OMS系統(tǒng)或ERP分離的,如果使用第三方的倉儲系統(tǒng),數(shù)據(jù)的傳輸是必不可少的。對于單據(jù)的下發(fā)與狀態(tài)回傳系統(tǒng)是如何設(shè)計的,目前都是定時任務(wù)+消息隊列的方式進(jìn)行。訂單可以根據(jù)倉庫下發(fā)的WMS系統(tǒng),也可以通過開放平臺傳遞給合作商家由其進(jìn)行發(fā)貨。在京東上下單完成后,你會清楚的看到類似如下系統(tǒng)消息“您的訂單已經(jīng)分配到XXX倉庫……”給用戶。
- 訂單攔截服務(wù),在用戶創(chuàng)建訂單或支付后,在沒有拆單前,還應(yīng)該有一個訂單攔截服務(wù)。此服務(wù)的目的是進(jìn)行惡意訂單的判斷,對于特殊訂單的審核,這都依賴于相關(guān)規(guī)則設(shè)置。當(dāng)訂單攔截后,訂單可能會被強(qiáng)制取消,目的是為了釋放庫存或避免用戶刷單,這個過程有的被稱之為訂單的回滾期,我理解就類似于回收站一樣。
待發(fā)貨:在此狀態(tài)的訂單有可能沒有下發(fā)到倉庫,也可能已經(jīng)下發(fā)了。但在此時,訂單都是可以取消的。
看上面的圖中,訂單在發(fā)貨前每個狀態(tài)理論上都可以取消(用戶主動或被動)。
訂單取消后,狀態(tài)就變?yōu)槿∠麪顟B(tài),這個狀態(tài)我理解為是訂單的終結(jié)狀態(tài)中一個(取消、無效、關(guān)閉或簽收)。
在此取消訂單如果沒有發(fā)生拆單,則可以根據(jù)支付或未支付進(jìn)行,即涉不涉及用戶退款;如果發(fā)生拆單,則訂單是要根據(jù)子訂單進(jìn)行取消了,而且在取消過程中是否要判斷是否可以取消,這就涉及促銷或贈品或訂單分類等信息,細(xì)節(jié)不說了。
這里補(bǔ)充一個訂單狀態(tài),即如果訂單發(fā)生拆單后其父訂單的狀態(tài)是什么?一般設(shè)置為無效訂單,這個也是訂單的一個終結(jié)狀態(tài)。
接收訂單:這個狀態(tài)在WMS系統(tǒng)中可能定義為待分揀或其它名稱,在上位系統(tǒng)就是已下發(fā)或待發(fā)貨。此時訂單就開始在WMS系統(tǒng)中進(jìn)行流轉(zhuǎn)了,但用戶一般不會關(guān)注你具體的履單節(jié)點,他最關(guān)心的是你發(fā)貨還是沒發(fā)。
分揀/打包/發(fā)貨:這幾個狀態(tài)都是倉儲或商家的作業(yè)過程,其發(fā)貨速度是用戶關(guān)注的,一般上位系統(tǒng)只關(guān)注于何時發(fā)貨,如果沒有及時操作會進(jìn)行提醒。對于這些狀態(tài)的變化,雖然是倉儲中的,但是我認(rèn)為需要同步到OMS系統(tǒng)中,這樣可以分析訂單的時效,而且對于售后也是有幫助的。
一般情況下,在訂單還沒有開始分揀時,用戶或系統(tǒng)仍然可以取消的,具體看訂單取消的環(huán)節(jié)是如何設(shè)計的。
已發(fā)貨:當(dāng)倉庫或商家操作發(fā)貨后,訂單便進(jìn)入到下一個狀態(tài)過程,即物流狀態(tài)。此時的訂單已經(jīng)打包完成了,此時訂單是不允許取消了,如果用戶不要,那么只能進(jìn)行攔截進(jìn)行拒收處理。
物流狀態(tài)信息:主要是四個節(jié)點,“已攬收->運(yùn)輸中->已派件->已簽收”,這些都是對接第三方物流信息獲取的。這些狀態(tài)信息一般與訂單主狀態(tài)是分離的,記錄在訂單信息中的物流明細(xì)表中。在與物流公司對接時,它們會有很多狀態(tài)碼,哪些展示給用戶,哪些不展示給用戶可以根據(jù)情況進(jìn)行篩選。但最好與物流的官方保持一致,因為有的用戶會去快遞的官網(wǎng)查詢,如果有異常會進(jìn)行投訴。
由于對接的是快遞公司的開放接口,有些信息是要進(jìn)行脫敏的,有些信息是要保存的,物流狀態(tài)的更新需要及時,以便讓用戶看到最新信息。
簽收:用戶收到貨后簽字確認(rèn),此單完成。如果后續(xù)涉及質(zhì)量等問題,就需要走售后流程。
拒收:淘寶訂單一般很少有拒收,因為商家一般都要求先簽收拍照后走售后(有的商品可以)。在大的垂直電商網(wǎng)站下單一般自營商品可以拒收?,F(xiàn)在基本上沒有貨到付款了,在幾年前購買商品可以選擇貨到付款,對于商品用問題或不滿意的用戶可以非常坦然的拒收,因為你沒有付錢。雖然現(xiàn)在有支付寶等第三方支付了,但是拒收時涉及到與快遞、商家三方的溝通,也是比較麻煩的。
商品拒收后,對于第三方物流是屬于一個新的單子,快遞費(fèi)誰支付(用戶還是商家)是個問題,所以一般都是先簽收后退。
寫到這里應(yīng)該可以簡單的了解了訂單生成后,根據(jù)相關(guān)的狀態(tài)再一次了解了單據(jù)流轉(zhuǎn)過程。
總結(jié)
了解了訂單信息的組成以及相關(guān)的狀態(tài),相信對于后續(xù)業(yè)務(wù)的理解與方案設(shè)計會有一點點幫助,但這些都是非常泛的理解,對于退貨的逆向流程也沒有總結(jié),在設(shè)計產(chǎn)品時一般對于正向的標(biāo)準(zhǔn)流程處理基本都是比較容易的,復(fù)雜的都是逆向或異常情況的考慮。
為什么要考慮這么多的異常情況呢?其實最主要的還是責(zé)任及信任。后續(xù)針對訂單的售后退換貨流程結(jié)合客服系統(tǒng)再進(jìn)行總結(jié)。
感謝您的閱讀!
作者:倔強(qiáng)的大蘿卜;公眾號:倔強(qiáng)的大蘿卜
本文由 @倔強(qiáng)的大蘿卜 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。
題圖來自Unsplash,基于CC0協(xié)議
退款呢?
退款是針對于退貨訂單或拒收訂單的支付狀態(tài)。
您好,最近在設(shè)計多層級的訂單系統(tǒng),大致的業(yè)務(wù)流,三級代理>二級代理>一級代理>廠商,廠商只和一級代理做結(jié)算,那訂單的主狀態(tài)就會在各層級平臺看到,在想是否要區(qū)分訂單的子狀態(tài),還是說訂單就直接進(jìn)行拆分,三級到二級一個訂單號,二級到一級一個訂單號,但是這邊訂單對于廠商來說是同一筆訂單,想請教一下,這種業(yè)務(wù)場景的訂單狀態(tài)如何設(shè)計
您好,對于三級->二級->一級->廠商這個過程,訂單的商品信息都是同樣的嗎?中間有沒有缺貨等場景導(dǎo)致訂單拆分,或一個訂單多次發(fā)貨到下一級的場景。如果有拆單那就應(yīng)該有父子訂單號,否則沿用上級訂單號是沒有問題的,保證數(shù)據(jù)一致方便查詢跟蹤及統(tǒng)計。關(guān)于狀態(tài)建議是分段,就像前端狀態(tài),倉儲狀態(tài)和物流狀態(tài)一樣,每個小段都有其自己的,從上到下有個接收或下發(fā)的中間狀態(tài)。詳細(xì)可以提供WX號,詳細(xì)交流!
VX:Dongfzly,麻煩賜教~
1
1.1
1.1.1
1.1.1.1
?