訂單拆單的流程中,系統(tǒng)需要做哪些工作?

30 評論 17603 瀏覽 136 收藏 19 分鐘

關(guān)于訂單管理中的拆單一直以來都想寫一下,但每次計劃寫的時候卻感覺拆單更多的是在其程序處理邏輯上,想描述清楚或者說其具體的實現(xiàn)還是挺難的,要不就是畫個程序處理流程圖,與我想表述的又不太一樣。

但總是止步不前,永遠(yuǎn)也弄不出來,利用兩天時間整出來這一篇,希望您看過能夠清楚拆單是什么,在拆單的流程中系統(tǒng)都做了哪些工作,它的一些規(guī)則有哪些等等!

什么是拆單?

在網(wǎng)上購買商品下單成功后,過一段時間再次瀏覽時,有時會發(fā)現(xiàn)你的訂單會變成兩個或多個,這就是系統(tǒng)做了拆單而導(dǎo)致的。

拆單,就是將一個大的訂單依據(jù)某些規(guī)則的集合,將其分解成兩個或多個子訂單的過程,原來的訂單稱之為父訂單。

拆單的重要性

通常我們所說的拆單一般情況下是指用戶的銷售訂單,但在實際業(yè)務(wù)中,拆單情況隨處可見,如采購訂單的拆分、調(diào)撥單的拆分等等。本篇后續(xù)都是以銷售訂單的拆單講述的,請知悉!

在互聯(lián)網(wǎng)電商系統(tǒng)中銷售訂單是與C端用戶關(guān)聯(lián)最緊密的,單據(jù)量是最大的,是影響用戶體驗的,且拆單的規(guī)則相對來說是比較復(fù)雜的。

折單要求數(shù)據(jù)準(zhǔn)確、及時,因為拆單后的子訂單是需要流入到倉儲進行生產(chǎn)作業(yè)的,它會進行揀貨、出庫、配送等一系統(tǒng)的流程,它也是后續(xù)財務(wù)系統(tǒng)對賬或結(jié)算、數(shù)據(jù)分析的重要數(shù)據(jù)來源。

拆單的場景

用戶在APP等平臺下單后,由于商品的庫存數(shù)量不滿足,可能在前端進行拆單,即用戶自己選擇是否需要拆單,可以按最快送達最小拆單的規(guī)則進行。

看到這里您可能會有點疑惑,庫存不足時還能下單嗎?現(xiàn)在很多網(wǎng)站上當(dāng)商品不足時用戶需要自行修改數(shù)量,然后才能下單。

確實如此,現(xiàn)在這種場景少了,但是有的商家為了提升客戶體驗,對于商品可以多倉發(fā)貨時。因為單倉缺貨而需要拆單時,由用戶來選擇決定是否購買,這應(yīng)該也是為了提高轉(zhuǎn)化率的一種方式。

還有一種場景,訂單涉及多商家,需要單獨付款的情況下,前端會直接進行拆單,但現(xiàn)在基本上都是合單支付了,這種拆單會使用戶體驗降低。

此外,有的商家既賣國內(nèi)商品,也賣海淘商品,如果都混在一塊,那么在支付前是需要進行拆單的,因為海淘商品要求用戶的身份認(rèn)證等信息的檢驗。

在多數(shù)情況下,都是用戶下單完成后,由系統(tǒng)進行在后臺進行拆單,拆單是要結(jié)合公司業(yè)務(wù)場景去考慮的。

用戶購買涉及幾種拆單

拆單除了以上幾種場景,對于用戶下單時系統(tǒng)上還會有什么操作嗎?

有一種情況即用戶下單時系統(tǒng)要根據(jù)用戶選擇的收貨地址、商品等信息,判斷是否有庫存,訂單應(yīng)該歸屬哪個倉庫,是否可以購買等,這個服務(wù)嚴(yán)格來講應(yīng)該歸屬于商品庫存服務(wù),但是也可以將其稱為預(yù)拆單。

預(yù)拆單一般是調(diào)用倉儲服務(wù)進行庫存的判斷,同時還要根據(jù)促銷活動進行一些優(yōu)惠計算,所有的這些都需要前端系統(tǒng)在處理時對訂單商品進行一些標(biāo)識,以便當(dāng)用戶支付成功后,訂單流轉(zhuǎn)到OMS系統(tǒng)進行物理拆單。

前端用戶下單成功后,訂單經(jīng)過OMS的拉單服務(wù)快速流轉(zhuǎn)到訂單中心,便開始訂單的再生成過程,訂單拆分后的子訂單會展示給用戶,原訂單一般不需要再展示,便于用戶跟蹤和查看。

所以在從用戶角度來看,一種是可以直接看到結(jié)果的拆單和一種無感知的預(yù)拆單過程。

拆單的時點與地點

預(yù)拆單是伴隨著購物流程進行的,這里不多討論,因為這個究竟是否屬于拆單也是要看我們?nèi)绾味x。正常情況下用戶選購商品完成后,系統(tǒng)不會拆單,因為用戶有可能取消訂單或未支付成功。

拆單的時點是要在 “訂單支付成功” 后進行,且需要前端訂單已經(jīng)流轉(zhuǎn)到后端生產(chǎn)庫,在訂單中心進行處理。

在前面有一種場景,如果購物中心不能合并支付時,在購物車中便拆分為幾個訂單,這時的拆單可以定義為一次拆單,也可以歸屬于購物流程,因為用戶不提交就不會生成訂單號,不會保存各個訂單的數(shù)據(jù)。

在用戶支付成功后,各個訂單同樣是要向后臺流轉(zhuǎn),經(jīng)過拆單服務(wù)的處理才可以繼續(xù)進行下面的生產(chǎn)。

在前面討論拆單場景時提到一種缺貨拆單,這種場景的拆單是在用戶下單支付成功后,訂單有可能已經(jīng)拆分為不同的子訂單,但因某種原因倉庫無貨而導(dǎo)致的拆單。

這時拆單的時點是靈活的,一般是在客服系統(tǒng)中,根據(jù)用戶的反饋確定是否拆單的。

缺貨是影響用戶體驗的,但是缺貨是始終客觀存在的。

拆單分幾級

OMS | 訂單拆單

從上圖看,拆單應(yīng)該為三級,即用戶創(chuàng)建的訂單為父訂單,然后經(jīng)過拆單服務(wù)正常的分為多個子訂單為第二級,后續(xù)因為缺貨等原因子訂單再次拆分為子(孫)訂單。

在數(shù)據(jù)設(shè)計上,一般情況子訂單與父訂單的關(guān)聯(lián)都通過ParentID來進行關(guān)聯(lián),但三級以上時,涉及原始訂單的查詢較麻煩。

具體看數(shù)據(jù)結(jié)構(gòu)如何設(shè)計了,可以再增加一個原始訂單號來記錄最初的訂單號,方便統(tǒng)計查詢等,負(fù)責(zé)拆單服務(wù)的同學(xué)可以詳細(xì)討論下。

為了避免訂單的復(fù)雜度及系統(tǒng)的查詢、統(tǒng)計、分析等數(shù)據(jù)處理的難度,訂單最好最多到三級,不宜過多

拆單狀態(tài)

以前專門梳理過訂單狀態(tài)的文章,詳見《訂單信息與狀態(tài)流轉(zhuǎn)看這個應(yīng)該足夠了!》,在拆單過程中也涉及訂單狀態(tài)的變換。

  1. 當(dāng)父訂單拆分為子訂單后,子訂單生效,父訂單應(yīng)該置為無效。
  2. 子訂單或父訂單經(jīng)過缺貨拆單后,原訂單狀態(tài)是無效還是其它?
  3. 訂單拆單后狀態(tài)應(yīng)該置為“待下發(fā)”即需要通過下發(fā)服務(wù),將訂單推送給倉庫發(fā)貨。
  4. 如果訂單已經(jīng)下發(fā)到倉庫后需要缺貨拆單,單據(jù)狀態(tài)應(yīng)保留原狀態(tài)。

這些都屬于細(xì)節(jié),但不得不考慮,因為訂單的狀態(tài)涉及到其他業(yè)務(wù)系統(tǒng)的計算和統(tǒng)計。

如:財務(wù)系統(tǒng)在應(yīng)付報表時是根據(jù)支付訂單進行統(tǒng)計和對賬的,如果訂單狀態(tài)是無效的,那么系統(tǒng)如何獲取此部分?jǐn)?shù)據(jù)。

BI有些統(tǒng)計分析是按狀態(tài)和訂單數(shù)量等進行統(tǒng)計的,如客單價、有效訂單數(shù)等等。

所以針對拆單而導(dǎo)致的訂單狀態(tài)是否應(yīng)該區(qū)分原有的訂單狀態(tài)分別標(biāo)識,是需要綜合考慮的。

拆單原則

拆單的原因我們已經(jīng)清楚,拆單的目的是為了保證履單,拆單的原則是什么?

  1. 首先是最小拆單原則,即能拆兩單,不能拆成三單,因為多拆一單不僅是單據(jù)數(shù)量的增加,它會增加系統(tǒng)的復(fù)雜度,降低用戶體驗,加大倉庫作業(yè)量,增加運費費用等。
  2. 最快送達原則,拆出的子訂單要快速生產(chǎn),快速送達,這個是增加用戶體驗的最好辦法。但是快速送達,依賴于倉儲物流的布局,這個在多倉可以發(fā)送到一個城市時尤為重要。

OMS | 訂單拆單

一般情況下,拆單要遵循這兩條原則,同時我們也看到拆單服務(wù),是依賴于基礎(chǔ)信息配置的,電商系統(tǒng)最復(fù)雜的是很多地方都有關(guān)聯(lián)。

拆單規(guī)則

拆單的規(guī)則因每個公司的業(yè)務(wù)不同而不同,這里羅列一些常見的規(guī)則供參考。

(1)不同商家的訂單需要進行拆分

這個主要應(yīng)用于平臺型的電商,一般情況用戶購買商品都進入不同的店鋪,創(chuàng)建的訂單也是歸屬這個商家的。但有的平臺采用合單支付,即用戶選購不同商家的商品,但支付是一次的。

這個和淘寶有些不同,淘寶上每個商家的收款賬號是不同的,所以不能一次支付,但平臺商家是平臺代收款的,所以可以一次支付后再拆單分?jǐn)偨痤~。

(2)不同倉或不同供應(yīng)商的商品需要進行拆單

倉庫不同訂單需要分開,對于不同的供應(yīng)商訂單主要是指由供應(yīng)商直接發(fā)貨的訂單即商品不存儲在倉庫,由供應(yīng)商直送到用戶,這個和平臺商家類似。但是區(qū)別是簽署的合同不同,一個是購銷合同,一個是傭金扣點合同,細(xì)節(jié)不展開了,有興趣可以留言交流。

(3)商品類型不同需要拆單

一般區(qū)分奢侈品或有特殊要求的商品,這個需要業(yè)務(wù)根據(jù)商品要求進行設(shè)置。因為商品要求不同,后續(xù)在物流環(huán)節(jié)采用的物流產(chǎn)品類型也不同,物流費用也不同。這部分也可以根據(jù)商品信息,在倉儲進行處理,但最后在上位能夠提前區(qū)分。

(4)商品溫控屬性不同要進行拆單

此部分一般是指生鮮電商而言,同一個倉庫有常溫倉、冷藏倉、冷凍倉,存儲著不同的商品,商品的揀貨、包裝等都有不同的要求,所以需要進行拆單。

(5)大件商品拆單

大件商品與普通商品不同,它在倉庫的存儲位置、揀貨方式、包裝、運輸都有所區(qū)別,所以大件商品需要每一件都拆單,大件商品一般遵循最快送達,不需要最少拆單原因的限制。

(6)根據(jù)庫存拆單

這個是針對缺貨商品進行的拆單,即有庫存的一單,無庫存的一單,如果是二級訂單,則父訂單相同,子訂單衍生出子訂單,子訂單1的過程。

(7)線下門店商品不拆單

如果是線下門店購買商品,則不需要拆單。

(8)組合商品不能拆單

在促銷活動中,有時會有一些大禮包等商品的組合銷售,即A,B,C等商品經(jīng)過倉庫的組合包裝后出庫,所以針對此類商品不能拆單。

在拆單服務(wù)中需要調(diào)用物料單信息,進行判斷,具體的要看系統(tǒng)如何設(shè)計了。

拆單的規(guī)則很多,在系統(tǒng)處理時,要依賴于規(guī)則設(shè)置的優(yōu)先級來進行。

拆單算法

(1)稀缺商品算法

找所有商品在所有庫房最稀缺的商品,獲取該商品的階數(shù)。

(2)降階

找稀缺商品的都需要倉庫組合,這些倉庫是必須發(fā)貨的,把這些倉庫計入發(fā)貨列表,這樣就降階了,剩余倉庫再計算組合,減少運算數(shù)量。

(3)抽屜原理算法

找第一階的倉庫列表(發(fā)貨量最大的倉庫),這個庫房的庫存是必須要發(fā)的,然后再找次發(fā)貨量最大的倉庫,以此類推,用于后面的組合計算。

(4)找組合

按照倉庫順序逐漸增加倉庫個數(shù)找組合。

算法也只是拆單過程中的一個路徑參考,且算法依賴于拆單的規(guī)則而制定,無論如何要保證拆單的結(jié)果準(zhǔn)確,拆單的速度要快。

拆單服務(wù)兩步重要工作

以上一直在討論拆單是由1變2,由2變4的一些內(nèi)容,在具體的拆單服務(wù)系統(tǒng)中要考慮哪些內(nèi)容,又有哪些工作?

  1. 前面所說的都應(yīng)該在設(shè)計時考慮,而且最重要的是要依賴規(guī)則進行設(shè)計,數(shù)據(jù)的流轉(zhuǎn),時序等等。
  2. 金額分?jǐn)偸遣饐沃凶钪匾囊徊糠止ぷ?,也是最?fù)雜的。

父訂單的拆分,商品的重新組合,生成新的訂單是第一步,第二步就是要將父訂單的金額合理的,正確的分?jǐn)偟礁鱾€子訂單上。

訂單一般分為訂單主表和訂單商品表、訂單支付明細(xì)表和訂單活動表。

訂單金額有幾個主要的部分:訂單商品金額、折扣金額、禮品卡支付金額、積分支付金額、優(yōu)惠券支付金額、訂單支付金額等幾個部分。

運費是訂單表中一個特殊字段,運費如何分?jǐn)偸且厥饪紤]的,一般情況是按金額占比進行。所以生成的子訂單中各部分金額,也要保證與父訂單金額一致。

訂單商品表、支付明細(xì)表、活動表屬于明細(xì)信息,要根據(jù)原始訂單明細(xì)表的數(shù)據(jù)和標(biāo)識進行計算分?jǐn)偂?/p>

子訂單的金額要保證橫向、縱向都正確才行,橫向是指子單的合與父單金額一致,縱向是指子單訂單主表與明細(xì)表金額一致。

此外,在金額分?jǐn)傆嬎氵^程有一項重要規(guī)則不可避免,即開票金額的考慮。

這部分金額的分?jǐn)偱c公司繳稅息息相關(guān),單據(jù)與發(fā)票要一致,要考慮商品信息、活動規(guī)則等等,非常復(fù)雜。

有的拆單服務(wù)將金額分?jǐn)偑毩⒊鰜?,以降低對拆單的影響,提高訂單流轉(zhuǎn)速度。

拆單的速度要求

由于拆單后訂單才會下發(fā)到倉儲或商家進行生產(chǎn),所以對于速度要求就是。

在系統(tǒng)設(shè)計時可以依據(jù)規(guī)則等綜合考慮,多線程是最常用的方法,但多線程需要考慮資源競爭和安全性。一般情況,如果下單后已經(jīng)確定了倉庫,那么可以按倉庫啟動多個服務(wù),這樣可以避免程序的難度。

對于拆單和下發(fā)在系統(tǒng)上也要有數(shù)據(jù)監(jiān)控,不能出現(xiàn)積壓的情況。如果拆單有異常時,在定時任務(wù)中,很多情況都是依賴一個信息字段的狀態(tài)來進行循環(huán)處理,在服務(wù)中要有容錯處理,不能一直停滯不前。

拆單的影響

什么是拆單?為什么拆單?如何拆單?前面說了很多,但對于拆單有什么影響呢?

先說一個場景,公司搞促銷活動,買A贈B,但A與B商品的溫控屬性不同,所以用戶下單后一定會拆單。

拆單后倉儲揀貨、發(fā)貨是根據(jù)子訂單進行的,很有可能贈品B先發(fā)貨了,A后發(fā)貨。用戶先收到B簽收了,然后A進行拒收或取消。此時,如果在拒收或取消A時不判斷關(guān)聯(lián)子訂單,那么公司就會損失B。

如果判斷關(guān)聯(lián)子訂單的狀態(tài),那么系統(tǒng)的復(fù)雜度將會非常之大,因為實際場景中一個父單拆為多單時是很常見的。

拆單后,子訂單數(shù)量增加,對于客單價、統(tǒng)計分析等報表需要考慮其影響,維度和統(tǒng)計口徑不同,數(shù)據(jù)結(jié)果必然不同,從而會影響到經(jīng)營分析及決策。

影響,對于不同的業(yè)務(wù)有不同的理解,作為產(chǎn)品研發(fā)應(yīng)該在拆單設(shè)計時還是需要要將利害與業(yè)務(wù)說清楚,尤其是運營人員(活動方面重點考慮),雖然這屬于一個后臺服務(wù)。

總結(jié)

拆單是復(fù)雜的,合理的拆單會加快訂單的流轉(zhuǎn),友好的用戶體驗,過度拆單則會產(chǎn)生冗余的數(shù)據(jù),增加訂單的復(fù)雜關(guān)系,統(tǒng)計、計算、售后等各個環(huán)節(jié)。

以上是我對拆單的一次梳理與總結(jié),感謝您的閱讀!

 

作者:倔強的大蘿卜;公眾號:倔強的大蘿卜

本文由 @倔強的大蘿卜 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理,未經(jīng)作者許可,禁止轉(zhuǎn)載。

題圖來自Unsplash,基于CC0協(xié)議

更多精彩內(nèi)容,請關(guān)注人人都是產(chǎn)品經(jīng)理微信公眾號或下載App
評論
評論請登錄
  1. 缺貨拆單,這個我不太能理解,訂單已經(jīng)下發(fā)到倉庫了,這已經(jīng)是被拆解好的訂單了,倉庫缺貨的情況下,就會變?yōu)榭蹘齑媸〉那闆r,然后交由運營介入,對這個訂單進行退單。我不太理解您說的缺貨拆單的含義,請您不吝賜教。

    來自廣東 回復(fù)
    1. 我也有類似的疑惑,因為是否缺貨這個判斷是前置的,會在成單時做判斷,不會到用戶支付后再判斷

      來自廣東 回復(fù)
  2. 《訂單拆單的流程中,系統(tǒng)需要做哪些工作?》《訂單信息與狀態(tài)流轉(zhuǎn)看這個應(yīng)該足夠了!》《電商后臺之訂單生成》,深度好文,三篇文章看完能get很多知識點。

    來自山東 回復(fù)
    1. 感謝認(rèn)可,歡迎一起交流學(xué)習(xí):)

      來自北京 回復(fù)
  3. 深度好文!想問哥們,考慮換工作嗎,跨境電商是否考慮~

    來自浙江 回復(fù)
    1. 工作地點在哪,如果在深圳可以介紹朋友??

      回復(fù)
  4. 想了解,經(jīng)過拆/合單之后的訂單,若此時用戶取消了訂單。訂單攔截時,是否允許取消此類訂單?

    來自廣東 回復(fù)
    1. 以拆單為例,當(dāng)用戶下單后是a,由于商品屬性(如溫控)不同需要拆成b和c,那么a訂單的金額會轉(zhuǎn)移到b和c,a的訂單狀態(tài)為無效,用戶此時看到的是b和c兩張訂單,如果發(fā)貨前要取消是針對b和c的取消,按照取消流程返還用戶金額。

      來自北京 回復(fù)
    2. 這個無效的訂單A,和訂單B,C,同屬于一個級別的訂單,只不過是有一層關(guān)聯(lián)關(guān)系是嗎?還是說A是更上一層的單結(jié)結(jié)構(gòu)?

      來自北京 回復(fù)
    3. A 是B、C的父訂單,在數(shù)據(jù)存儲結(jié)構(gòu)上訂單表中會有一個父訂單號用以父子訂單的關(guān)聯(lián),同時為了方便統(tǒng)計可以增加一個冗余字段 是否為父訂單的字段(0 子訂單,1父訂單)。

      在履單過程(訂單的處理)時,父子訂單沒有區(qū)別,都是統(tǒng)一的流程,系統(tǒng)根據(jù)訂單狀態(tài)來判斷。

      感謝您的關(guān)注!

      來自北京 回復(fù)
    4. 那一個父訂單豈不是可能對應(yīng)多個賣方信息?如果一個父訂單對應(yīng)多個店鋪的商品。

      來自北京 回復(fù)
    5. 對于多店鋪的商品,在前端下單時一般就會按店鋪進行拆單即提交訂單時就創(chuàng)建針對每個店鋪的父訂單,因為這涉及貨款結(jié)算等諸多問題。

      來自北京 回復(fù)
  5. 我提供一下跨境的拆單場景吧,跨境直郵的時候會有運費問題,還有包裹限制問題,需要通過拆單來限制包裹內(nèi)件數(shù)和包裹運費,在訂單結(jié)算后再拆單就不適合這個場景了

    來自新西蘭 回復(fù)
    1. 感謝!

      來自北京 回復(fù)
  6. 寫的不錯,思路清晰,看來作者是自身電商產(chǎn)品啊

    來自廣東 回復(fù)
    1. 感謝您的認(rèn)可,我一直想成為一名產(chǎn)品,目前還在努力中:)

      來自北京 回復(fù)
  7. 拆單算法不是很懂,誰給解釋下 ??

    來自浙江 回復(fù)
    1. 對于這幾個算法其實主要就是考慮是先以稀缺品為主進行,還是按倉優(yōu)先級逐級遞近,只要滿足最小拆單原則或最快出庫就可以,列出的幾個算法也就是計算的步驟邏輯可能都會用到。

      來自北京 回復(fù)
  8. 寫的很深入,看了您的文字對拆單的邏輯了解了很多,贊

    來自四川 回復(fù)
    1. 謝謝關(guān)注:)

      來自北京 回復(fù)
  9. 文章寫的真的很好,邏輯條理清晰,語言簡練。想問一下,關(guān)于“商品溫控屬性不同要進行拆單”這一原則,如果是 30 分鐘到家類的新零售生鮮電商,統(tǒng)一配送統(tǒng)一包裝,有必要拆單嗎?謝謝!

    來自廣東 回復(fù)
    1. 報歉剛回復(fù),如果30分鐘到家的,商品揀貨打包與正常訂單都會簡化,可以不用拆單

      回復(fù)
    2. 謝謝回復(fù)!最近在學(xué)習(xí)電商的后臺系統(tǒng),看您的文章很有收獲。

      來自廣東 回復(fù)
  10. 想問下,如果一筆訂單發(fā)生部分退款,這種情況需要拆單么?

    來自浙江 回復(fù)
    1. 我也遇到這個問題。子訂單里部分退款,這時候沒法再拆單了,那就整個子訂單狀態(tài)為部分退款狀態(tài)。好友:xiangjian1943聊聊吧

      來自浙江 回復(fù)
    2. 加你了,備注寫的杭州同行。

      來自浙江 回復(fù)
    3. 報歉,回復(fù)晚了,退款是原訂單的售后,會生成退貨入庫單,根據(jù)退貨入庫單和原單計算退款金額,生成退款單,不影響原訂單的

      回復(fù)
    4. 對,退款應(yīng)該和原訂單解耦,退款是需要單獨生成一個退款單,退款單的退款金額等同步給子訂單

      來自北京 回復(fù)
  11. 深度好文!學(xué)習(xí)了! ??

    來自浙江 回復(fù)
    1. 謝謝您的認(rèn)可,文章有的內(nèi)容也是基于原來經(jīng)歷的項目進行的學(xué)習(xí)與總結(jié),這里呈現(xiàn)出來與大家分享。

      來自北京 回復(fù)