6個(gè)部分,詳解電商訂單管理流程
本文詳解了電商系統(tǒng)訂單模塊中的各項(xiàng)流程,包括了訂單的概念、構(gòu)成、狀態(tài)、流程、逆向訂單、訂單拆單等內(nèi)容。
一、訂單概述
電商所有模塊中,訂單模塊是核心中的核心,電商所有模塊都是直接或者間接為訂單模塊服務(wù)的。
訂單模塊看似簡單,很多新人產(chǎn)品經(jīng)理包括我自己,都覺得訂單模塊不就是瀏覽商品、加購、支付、訂單列表不就完了嗎?
后來隨著接觸的增多,發(fā)現(xiàn)訂單模塊并不是想象中的簡單,覺得簡單的只是看到了冰山的海面部分,其龐雜的體系都隱匿在海面一下。今天根據(jù)我的經(jīng)驗(yàn),來和大家訂單做詳細(xì)的說明。
電商系統(tǒng)涉及到3流,分別時(shí)信息流,資金流,物流,而訂單系統(tǒng)作為中樞將三者有機(jī)的集合起來,訂單系統(tǒng)就從這三流開始吧。
訂單模塊是電商系統(tǒng)的樞紐,在訂單這個(gè)環(huán)節(jié)上需求獲取多個(gè)模塊的數(shù)據(jù)和信息,同時(shí)對這些信息進(jìn)行加工處理后流向下個(gè)環(huán)節(jié),這一系列就構(gòu)成了訂單的信息流通。我們從以下幾個(gè)環(huán)節(jié)對訂單信息流動進(jìn)行詳細(xì)的說明
1. 訂單場景
訂單場景的說明不言而喻,不同場景下訂單表現(xiàn)形式和數(shù)據(jù)傳遞方式也不相同,目前主流的訂單場景包括線上電商訂單、O2O電商訂單。
(1)線上電商訂單
這種電商就像淘寶、京東等,通過線上下單、支付后由自建物流或者第三方物流進(jìn)行配送。這種電商系統(tǒng)通過,展示電商系統(tǒng)的商品模塊引導(dǎo)用戶對商品進(jìn)行訂單模塊的處理,訂單模塊處理完成后將信息傳遞給WMS系統(tǒng)進(jìn)行處理,當(dāng)用戶收到貨品后在訂單系統(tǒng)進(jìn)行確認(rèn)。通過以上系統(tǒng)的協(xié)同處理來完成整個(gè)訂單信息的處理。如果是虛擬物品的話需要調(diào)用其他系統(tǒng)進(jìn)行對接,通過接口返回參數(shù)方式完成信息的處理,比如充話費(fèi)、買點(diǎn)卡等。
(2)O2O電商訂單
這種電商包括兩種外賣訂單和團(tuán)購訂單。
外賣訂單和線上電商訂單有些類似,線上訂單處理完成后只是沒有經(jīng)過倉庫環(huán)節(jié)進(jìn)行處理,而是需要生產(chǎn)環(huán)節(jié)對數(shù)據(jù)進(jìn)行處理,生產(chǎn)完成后將信息傳遞給物流環(huán)節(jié),用戶確認(rèn)收貨后再對訂單信息進(jìn)行處理。
而團(tuán)購訂單則是線上獲取商品信息后,通過訂單系統(tǒng)處理完成,將信息傳遞給wms系統(tǒng)進(jìn)行庫存處理,只是對庫存進(jìn)行信息處理而沒有物流配送環(huán)節(jié),用戶線下到店后對訂單系統(tǒng)進(jìn)行核銷處理,從而完成整個(gè)訂單信息的閉環(huán)。
二、訂單構(gòu)成
我們先從訂單整個(gè)架構(gòu)進(jìn)行了解,以下是整個(gè)訂單系統(tǒng)的構(gòu)成:
1. 用戶信息
用戶信息包括用戶賬號、用戶等級、用戶的收貨地址、收貨人、收貨人電話等組成,用戶賬戶需要綁定手機(jī)號碼,但是用戶綁定的手機(jī)號碼不一定是收貨信息上的電話。用戶可以添加多個(gè)收貨信息,用戶等級信息可以用來和促銷系統(tǒng)進(jìn)行匹配,獲取商品折扣,同時(shí)用戶等級還可以獲取積分的獎勵等。
2. 訂單基礎(chǔ)信息
訂單基礎(chǔ)信息是訂單流轉(zhuǎn)的核心,其包括訂單類型、父/子訂單、訂單編號、訂單狀態(tài)、訂單流轉(zhuǎn)的時(shí)間等。
(1)訂單類型包括實(shí)體商品訂單和虛擬訂單商品等,這個(gè)根據(jù)商城商品和服務(wù)類型進(jìn)行區(qū)分。
(2)同時(shí)訂單都需要做父子訂單處理,之前在初創(chuàng)公司一直只有一個(gè)訂單,沒有做父子訂單處理后期需要進(jìn)行拆單的時(shí)候就比較麻煩,尤其是多商戶商場,和不同倉庫商品的時(shí)候,父子訂單就是為后期做拆單準(zhǔn)備的。
(3)訂單編號不多說了,需要強(qiáng)調(diào)的一點(diǎn)是父子訂單都需要有訂單編號,需要完善的時(shí)候可以對訂單編號的每個(gè)字段進(jìn)行統(tǒng)一定義和詮釋。
(4)訂單狀態(tài)記錄訂單每次流轉(zhuǎn)過程,后面會對訂單狀態(tài)進(jìn)行單獨(dú)的說明。
(5)訂單流轉(zhuǎn)時(shí)間需要記錄下單時(shí)間,支付時(shí)間,發(fā)貨時(shí)間,結(jié)束時(shí)間/關(guān)閉時(shí)間等等。
3. 商品信息
商品信息從商品庫中獲取商品的SKU信息、圖片、名稱、屬性規(guī)格、商品單價(jià)、商戶信息等,從用戶下單行為記錄的用戶下單數(shù)量,商品合計(jì)價(jià)格等。
4. 優(yōu)惠信息
優(yōu)惠信息記錄用戶參與的優(yōu)惠活動,包括優(yōu)惠促銷活動,比如滿減、滿贈、秒殺等,用戶使用的優(yōu)惠券信息,優(yōu)惠券滿足條件的優(yōu)惠券需要默認(rèn)展示出來,具體方式已在之前的優(yōu)惠券篇章做過詳細(xì)介紹,另外還虛擬幣抵扣信息等進(jìn)行記錄。
為什么把優(yōu)惠信息單獨(dú)拿出來而不放在支付信息里面呢?
因?yàn)閮?yōu)惠信息只是記錄用戶使用的條目,而支付信息需要加入數(shù)據(jù)進(jìn)行計(jì)算,所以做為區(qū)分。
5. 支付信息
(1)支付流水單號,這個(gè)流水單號是在喚起網(wǎng)關(guān)支付后支付通道返回給電商業(yè)務(wù)平臺的支付流水號,財(cái)務(wù)通過訂單號和流水單號與支付通道進(jìn)行對賬使用。
(2)支付方式用戶使用的支付方式,比如微信支付、支付寶支付、錢包支付、快捷支付等。支付方式有時(shí)候可能有兩個(gè)——余額支付+第三方支付。
(3)商品總金額,每個(gè)商品加總后的金額;運(yùn)費(fèi),物流產(chǎn)生的費(fèi)用;優(yōu)惠總金額,包括促銷活動的優(yōu)惠金額,優(yōu)惠券優(yōu)惠金額,虛擬積分或者虛擬幣抵扣的金額,會員折扣的金額等之和;實(shí)付金額,用戶實(shí)際需要付款的金額。
6. 物流信息
物流信息包括配送方式,物流公司,物流單號,物流狀態(tài),物流狀態(tài)可以通過第三方接口來獲取和向用戶展示物流每個(gè)狀態(tài)節(jié)點(diǎn)。
三、訂單狀態(tài)
1. 待付款
用戶提交訂單后,訂單進(jìn)行預(yù)下單,目前主流電商網(wǎng)站都會喚起支付,便于用戶快速完成支付,需要注意的是待付款狀態(tài)下可以對庫存進(jìn)行鎖定,鎖定庫存需要配置支付超時(shí)時(shí)間,超時(shí)后將自動取消訂單,訂單變更關(guān)閉狀態(tài)。
2. 已付款/待發(fā)貨
用戶完成訂單支付,訂單系統(tǒng)需要記錄支付時(shí)間,支付流水單號便于對賬,訂單下放到WMS系統(tǒng),倉庫進(jìn)行調(diào)撥,配貨,分揀,出庫等操作。
3. 待收貨/已發(fā)貨
倉儲將商品出庫后,訂單進(jìn)入物流環(huán)節(jié),訂單系統(tǒng)需要同步物流信息,便于用戶實(shí)時(shí)知悉物品物流狀態(tài)
4. 已完成
用戶確認(rèn)收貨后,訂單交易完成。后續(xù)支付側(cè)進(jìn)行結(jié)算,如果訂單存在問題進(jìn)入售后狀態(tài)
5. 已取消
付款之前取消訂單。包括超時(shí)未付款或用戶商戶取消訂單都會產(chǎn)生這種訂單狀態(tài)。
6. 售后中
用戶在付款后申請退款,或商家發(fā)貨后用戶申請退換貨。
售后也同樣存在各種狀態(tài),當(dāng)發(fā)起售后申請后生成售后訂單,售后訂單狀態(tài)為待審核,等待商家審核,商家審核通過后訂單狀態(tài)變更為待退貨,等待用戶將商品寄回,商家收貨后訂單狀態(tài)更新為待退款狀態(tài),退款到用戶原賬戶后訂單狀態(tài)更新為售后成功。
四、訂單流程
訂單流程是指從訂單產(chǎn)生到完成整個(gè)流轉(zhuǎn)的過程,從而行程了一套標(biāo)準(zhǔn)流程規(guī)則。而不同的產(chǎn)品類型或業(yè)務(wù)類型在系統(tǒng)中的流程會千差萬別,比如上面提到的線上實(shí)物訂單和虛擬訂單的流程,線上實(shí)物訂單與O2O訂單等,所以需要根據(jù)不同的類型進(jìn)行構(gòu)建訂單流程。
不管類型如何訂單都包括正向流程和逆向流程,對應(yīng)的場景就是購買商品和退換貨流程,正向流程就是一個(gè)正常的網(wǎng)購步驟:訂單生成–>支付訂單–>賣家發(fā)貨–>確認(rèn)收貨–>交易成功。而每個(gè)步驟的背后,訂單是如何在多系統(tǒng)之間交互流轉(zhuǎn)的,可概括如下圖:
1. 訂單創(chuàng)建
訂單創(chuàng)建是從用戶下單開始的,當(dāng)用戶對商品進(jìn)行下單后,系統(tǒng)會引導(dǎo)用戶來到確認(rèn)訂單頁面,此時(shí)系統(tǒng)會獲取用戶預(yù)下單的商品信息,同時(shí)判斷商品是否涉及到優(yōu)惠促銷的信息,這些優(yōu)惠券包括促銷活動,優(yōu)惠券,積分抵扣等。
除了獲取優(yōu)惠信息外,還需要判斷用戶等級權(quán)益,比如VIP用戶8折優(yōu)惠,新用戶立減優(yōu)惠等,其中的券別在于一個(gè)是針對商品,一個(gè)針對的用戶等級權(quán)益,電商系統(tǒng)在開發(fā)初期如果不涉及用戶等級折扣而又有新用戶促活優(yōu)惠的話,建議使用優(yōu)惠券來做。而在優(yōu)惠活動需要遵循配置的疊加規(guī)則和優(yōu)先級規(guī)則,在預(yù)下單操作是需要做判斷。
在預(yù)下單操作時(shí),需要對庫存進(jìn)行查詢,而庫存從什么時(shí)候進(jìn)行增減,目前主流有兩種方式:
- 下單減庫存,用戶預(yù)下單成功時(shí)減少庫存數(shù)量,優(yōu)點(diǎn)是系統(tǒng)邏輯比較簡單,庫存實(shí)時(shí)展示用戶體驗(yàn)好,同時(shí)也帶來了惡意下單的風(fēng)險(xiǎn)。
- 付款減庫存,用戶支付完成后再減少庫存,優(yōu)點(diǎn)減少惡意下單的風(fēng)險(xiǎn),缺點(diǎn)是第三方支付回調(diào)采取的是異步回調(diào)方式,回調(diào)結(jié)果返回系統(tǒng)需要時(shí)間,并發(fā)下單情況下可能導(dǎo)致庫存不足引發(fā)退款和投訴。
個(gè)人比較傾向于下單減庫存的方式,在電商這個(gè)競爭激烈的環(huán)境下,保障用戶體驗(yàn)才是第一位的,同時(shí)需要做好相對的措施,預(yù)下單后馬上對庫存進(jìn)行鎖定,鎖定時(shí)間同步訂單支付的限定時(shí)間。
比如淘寶的15分鐘,限定時(shí)間內(nèi)沒有付款,將鎖定庫存進(jìn)行回滾釋放。這種下單減庫存的方式,可以減少用戶因?yàn)橄聠魏髠}庫沒有貨的情況,減少用戶的挫敗感。
2. 訂單支付
訂單支付在支付層面涉及的方面比較多,比如默認(rèn)支付渠道,支付渠道的路由,組合支付等,在這里就不多加敘述,訂單支付過程做需要選擇支付方式,支付完成后通過支付渠道會返回支付流水號,支付完成時(shí)間。系統(tǒng)需要記錄訂單同時(shí)生成支付流水,方便與支付渠道進(jìn)行對賬。
支付完成后下一步是等待賣家發(fā)貨或者是訂單下放到倉庫,在此過程中,會涉及到拆單過程,一般拆單分為兩次拆單:
- 一次拆單:訂單層面的拆單,這個(gè)拆單主要是因?yàn)榻M合商品時(shí),各個(gè)商品屬于不同商家,此時(shí)訂單需要使用父子訂單進(jìn)行區(qū)分
- 二次拆單:商品層面的拆單,這個(gè)拆單由于商品分屬不同的倉庫,重量/體積限制,商品品類要求比如易燃或者貴重物品需要單獨(dú)打包,商品庫存原因,比如需要有些商品當(dāng)天發(fā)生,有些商品48小時(shí)后發(fā)送,另外對于海淘來說還存在關(guān)稅問題需要拆單的。
對于拆單后面還會繼續(xù)進(jìn)行說明。
3. 賣家發(fā)貨/倉儲處理
這個(gè)過程從線下走向線下,商家發(fā)貨過程已經(jīng)形成一個(gè)標(biāo)準(zhǔn)化的流程,訂單內(nèi)容會下放到倉庫,倉庫對商品進(jìn)行打單、揀貨、包裝、交接快遞進(jìn)行配送。
目前很多WMS系統(tǒng)都與主流電商系統(tǒng)進(jìn)行了對接,訂單下單成功后直接進(jìn)入到WMS系統(tǒng),在此過程中會涉及到合并訂單,比如同一買家同一收貨信息分多筆下單的訂單,訂單審核,訂單重新分倉,下放庫房,生成批檢單,訂單打印等等。關(guān)于物流倉儲方面后面物流篇講進(jìn)行詳述。
4. 確認(rèn)收貨
訂單通過倉儲環(huán)節(jié),已經(jīng)發(fā)貨了,在訂單系統(tǒng)中會涉及到對物流信息的獲取,包括配送方式/物流公司/物流單號/物流狀態(tài)的實(shí)時(shí)顯示。
記得淘寶沒有打通物流查詢環(huán)節(jié)時(shí),那時(shí)候想知道包裹到哪里,需要根據(jù)商家提供的物流公司和物流單號,在物流公司官網(wǎng)進(jìn)行查詢,而現(xiàn)在很多物流公司開放了物流接口,可以根據(jù)物流接口獲取物流狀態(tài)信息。當(dāng)用戶收到貨后,可以根據(jù)物流公司反饋的簽收結(jié)果,設(shè)置提醒用戶確認(rèn)收貨。
5. 訂單完成
用戶確認(rèn)收貨后,這個(gè)訂單總算完了,NO,NO,NO,演出才剛剛開始。
訂單完成后會涉及到需要提醒用戶進(jìn)行訂單的點(diǎn)評,同時(shí)可能會涉及到訂單的售后問題。
交易成功是指在收貨后N天后,此時(shí)除去售后問題外,渠道側(cè)會涉及到平臺和支付渠道結(jié)算的問題,貨款需要從支付渠道流入平臺賬戶;商戶側(cè)會涉及到平臺需要生成待結(jié)算清單問題,明細(xì)該筆訂單商戶結(jié)算款是多少。如果涉及到三級分銷的話,還需要考慮到各級代理分潤問題。
五、逆向訂單
訂單逆向過程是個(gè)非常頭痛的問題,每次涉及訂單的時(shí)候,每次都傻傻地問boss可以不做退款退貨流程嗎?
老板很鄙夷地回答:沒有買賣就沒有傷害。有人的地方就有江湖,有訂單的地方就有退款退貨一個(gè)道理,所以安心設(shè)計(jì)好逆向流程才是王道。
關(guān)于訂單逆向流程,想想線下一些購買場景理解起來就方便很多了,接下來就舉例說明逆向訂單:
大傻去電腦城去買個(gè)筆記本電腦,在千挑萬選后終于在奸商小K的說服下,準(zhǔn)備下單購買一臺聯(lián)想小新air,故事就這么發(fā)生了……
CASE1 修改訂單
這個(gè)時(shí)候在小K的說服下大傻選購小新air,突然大傻對小新air配置還有一些優(yōu)惠提出了新的疑問,好吧……正準(zhǔn)備開單的小K為了促成這個(gè)交易在單子上面給大傻填寫贈送鼠標(biāo),背包…
修改訂單發(fā)生在預(yù)下單過程中,用戶沒有提交訂單,可以對訂單一些信息進(jìn)行修改,比如配送信息,優(yōu)惠信息,及其他一些訂單可修改范圍的內(nèi)容,此時(shí)只需對數(shù)據(jù)進(jìn)行變更即可。
CASE2 訂單取消
待支付情況下,各種單據(jù)都填好了,小K說:哥,你該付款了。大傻一摸口袋,錢包不見了。小K心里想,哥,你逗我玩呢?
這個(gè)時(shí)候有3種情況:
第一,大傻回去拿錢后給了小K錢。
第二,大傻說這個(gè)電腦不要了,單據(jù)作廢吧。
第三,大傻說我回去拿錢,返回后結(jié)果門店下班了,單據(jù)也作廢了。
這個(gè)狀態(tài)下對應(yīng)電商場景下的 用戶主動取消訂單和用戶超時(shí)未支付,兩種情況下訂單都會取消訂單,而超時(shí)情況是系統(tǒng)自動關(guān)閉訂單,所以在訂單支付的響應(yīng)機(jī)制上面要做支付的限時(shí)處理,尤其是在前面說的下單減庫存的情形下面,可以保證快速的釋放庫存。
另外需要需要處理的是促銷優(yōu)惠中使用的優(yōu)惠券,權(quán)益等視平臺規(guī)則,進(jìn)行相應(yīng)補(bǔ)回給用戶。
CASE3 退款
待發(fā)貨情況下,大傻及時(shí)付完款了,小K心里樂開了花,在去倉庫的路上一蹦一跳的,心里琢磨著這筆單下來晚上可以好好喝一杯了,結(jié)果跑到倉庫拿貨,倉庫告訴小K沒有貨了,小K心里一萬匹草泥馬在奔馳著。沒有辦法,小K只好回去告訴大傻,完了大傻對小K一頓咆哮,最終小K還是把錢退給了大傻。
故事還有另外一個(gè)版本:大傻及時(shí)付完款了,小K心里樂開了花,在去倉庫的路上一蹦一跳的,心里琢磨著這筆單下來晚上可以好好喝一杯了。還沒有到倉庫,前臺小姐姐給他打電話,大傻說隔壁王阿姨的姑姑的表姐的女兒出了車禍要借錢,所以大傻不要筆記本了,小K心里一萬匹草泥馬在奔馳著。沒有辦法,小K只好給大傻退款。
在待發(fā)貨訂單狀態(tài)下取消訂單時(shí),分為商戶缺貨退款和用戶申請退款。
- 商戶缺貨退款由于訂單系統(tǒng)和WMS系統(tǒng)商品沒有進(jìn)行及時(shí)同步導(dǎo)致,或者是倉管和客服分開產(chǎn)生的,這個(gè)情況下需要與用戶協(xié)商處理退款。
- 用戶申請退款,用戶下單后,商家還未發(fā)貨,系統(tǒng)應(yīng)該支持用戶申請退款,如果發(fā)貨單已經(jīng)下發(fā)到wms系統(tǒng),但是尚未推送至倉庫,則應(yīng)該挺推送至倉庫,推送至倉庫則需要WMS中進(jìn)行攔截,攔截成功則暫定出庫,同步訂單系統(tǒng) 同意取消訂單,同時(shí)進(jìn)入退款流程。
如果是全部退款則訂單更新為關(guān)閉狀態(tài),若只是做部分退款則訂單仍需進(jìn)行進(jìn)行,同時(shí)生成一條退款的售后訂單,走退款流程。退款金額需原路返回用戶的賬戶。
CASE4 發(fā)貨后的退款
我們繼續(xù)那個(gè)故事:當(dāng)小K從倉庫將筆記本電腦領(lǐng)出來后,將電腦拿給大傻,大傻一看包裝破破爛爛的啥玩意啊,老子不要了,不管小K好說歹說,大傻堅(jiān)決不要了,拗不過他,小K最終還是給大傻退了錢。
發(fā)貨后的退款,發(fā)生在倉儲已經(jīng)貨物的配送,在配送過程中商品遺失,用戶拒收,用戶收貨后對商品不滿意,這樣情況下用戶發(fā)起退款的售后訴求后,需要商戶進(jìn)行退款的審核,雙方達(dá)成一致后,系統(tǒng)更新退款狀態(tài),對訂單進(jìn)行退款操作,金額原路返回用戶的賬戶,同時(shí)關(guān)閉原訂單數(shù)據(jù)。
僅退款情況下暫不考慮倉庫系統(tǒng)變化。如果發(fā)生雙方協(xié)調(diào)不一致情況下,可以申請平臺客服介入。在退款訂單商戶不處理的情況下,系統(tǒng)需要做限期判斷,比如5天商戶不處理,退款單自動變更同意退款。
CASE5 退款退貨
故事還沒有完,大傻沒有在小K家買成筆記本,又去了阿貍家買成了筆記本電腦,誰知道阿貍家筆記本更黑,翻新機(jī)做新機(jī)賣給大傻,大傻回去后筆記本沒用到1晚上就直接掛了。
火大的大傻第二天就找到阿貍要退貨,阿貍各種忽悠還是沒有忽悠到大傻這顆要退款退貨執(zhí)著的心,萬般不情愿下阿貍終于將筆記本重新入庫后,給大傻退了錢。
用戶退款退貨的流程和用戶僅退款的流程差不多,需要與商戶進(jìn)行協(xié)商,如果協(xié)商過程存在爭議平臺客服介入進(jìn)行協(xié)調(diào)。如無爭議,商戶審核通過后告知用戶退貨流程及退回的收件信息,進(jìn)入退貨流程后,商家收到用戶退貨商品后,庫存系統(tǒng)進(jìn)行補(bǔ)回,退貨入庫,訂單系統(tǒng)確認(rèn)后進(jìn)行退款,同時(shí)關(guān)閉訂單。
當(dāng)訂單中發(fā)生部分退貨時(shí),原訂單的狀態(tài)不變,維持待收貨或交易成功狀態(tài),同時(shí)退貨的部分生成交易售后訂單。剩余未退貨部分仍然允許申請售后。如果退貨商品在驗(yàn)收環(huán)節(jié)存在用戶導(dǎo)致的問題,可以通過線下協(xié)商后,將商品重新發(fā)回給用戶,或者進(jìn)行退部分款項(xiàng)。
之前在聊促銷活動時(shí),說到過優(yōu)惠金額的處理方式,之前只是針對平臺類和單店鋪模式進(jìn)行說明,本節(jié)對優(yōu)惠券和促銷進(jìn)行訂單逆向的退款退貨進(jìn)行說明,主要進(jìn)行部分退款進(jìn)行說明。
講解前先列公式,便于計(jì)算:
好了公式列完了開始講故事了:
618大促時(shí)夏天正好快到了,王小胖在某商城進(jìn)行血拼,在618之前王小胖已經(jīng)領(lǐng)取幾張優(yōu)惠券分別時(shí)平臺服飾類優(yōu)惠券滿500減50,小貓門店滿800減200優(yōu)惠券,小花花門店滿400減100優(yōu)惠券。
以下就是羅列每件商品的優(yōu)惠券金額和實(shí)付金額:
如果王小胖對小貓門店休閑長褲不滿意,退款只需要退款149.31元即可。
到這里關(guān)于訂單正向和逆向流程已經(jīng)說明完畢,拋出一個(gè)問題,如果同一個(gè)SKU里面有多件商品,需要對某件商品進(jìn)行退款怎么操作?
六、訂單拆單
為什么要拆單呢?
因?yàn)殡娚唐脚_存在購物車進(jìn)行合并付款,如果不拆單會遇到無法跟蹤物流或者會存在多個(gè)物流,另外做結(jié)算時(shí)不方便進(jìn)行核賬等,哪怕時(shí)同一家店鋪也會存在發(fā)貨時(shí)間、分不同物流發(fā)貨問。這個(gè)時(shí)候我們需要進(jìn)行拆單。
從訂單表層面,我們需要將訂單建立父子訂單,加購后提交訂單時(shí)需要創(chuàng)建父子訂單和編號,這個(gè)從用戶體驗(yàn)角度來說方便用戶進(jìn)合并付款,減少用戶操作提高轉(zhuǎn)化率。
拆單的原因包括:
- 店鋪:在多商戶商場下,商品歸屬不同商戶,所以涉及到商戶后臺的財(cái)務(wù)結(jié)算和物流發(fā)貨問題。
- 倉庫:商品不在同一個(gè)倉庫時(shí)需要按照倉庫歸屬進(jìn)行拆單
- 屬性:有些商品需要單獨(dú)運(yùn)配送,購買沙發(fā)和衣柜都需要獨(dú)立包裝,商品不在一起需要進(jìn)行拆單
- 價(jià)值:這個(gè)涉及跨進(jìn)電商,政策對跨境電商有單次限額,超過金額翻,也需要對訂單進(jìn)行拆單。
第一次拆單 訂單層面拆單
訂單層面拆單主要加購下單后存在上面說的對應(yīng)不同的商戶和不同倉庫,用戶完成支付后可以訂單中有多個(gè)不同的子訂單。
父訂單是記錄一次下單和合并支付的依據(jù),同樣在促銷層面來說可以通過父訂單享受購物的優(yōu)惠,然后通過子訂單進(jìn)行分?jǐn)偅佑唵问歉櫸锪?,售后、結(jié)算的依據(jù)。所以在設(shè)計(jì)訂單設(shè)計(jì)需要所有訂單都設(shè)計(jì)父子訂單。
從物流層面來說訂單生成后,訂單會進(jìn)行下放。對于平臺會將訂單推送到調(diào)度系統(tǒng)進(jìn)行處理,多商戶商城可以將訂單導(dǎo)出安排發(fā)貨,在更新發(fā)貨信息;自接系統(tǒng)會將訂單同步WMS系統(tǒng)或者ERP里,安排發(fā)貨。
第二次拆單 物流層面拆單
訂單推送至調(diào)度層后,調(diào)度中心需要進(jìn)行審核處理,審核通過后訂單開始進(jìn)行調(diào)撥和配貨,這個(gè)時(shí)候需要倉儲需要根據(jù)發(fā)貨單進(jìn)行拆單,這次拆單會包括商品屬性/價(jià)值/體積/重量/庫存進(jìn)行拆單,子訂單包括多個(gè)包裝,也存在多個(gè)物流信息。
以上就是整個(gè)訂單信息流的說明,關(guān)于訂單還包括訂單結(jié)算,訂單支付等流程,這塊屬于支付和結(jié)算體系需要考慮的范疇,有機(jī)會再后面會進(jìn)行支付和結(jié)算體系的說明。
作者:產(chǎn)品_空,微信號king_mario
本文由 @產(chǎn)品_空 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理 ,未經(jīng)許可,禁止轉(zhuǎn)載。
題圖來自 unsplash,基于 CC0 協(xié)議
簽收以后,同步信息:商品中心要同步啥信息呀?
還有個(gè)問題就是客戶下的一個(gè)訂單需要才倉儲拆單,多出來的訂單的運(yùn)費(fèi)是怎么計(jì)算的?是按照一件貨品計(jì)算運(yùn)費(fèi)還是按照兩件來計(jì)算?
請教下電商平臺上購買客廳那種歐式的那吊燈,前臺下單后,這樣的是一個(gè)怎樣的拆單合單的過程,因?yàn)檎麄€(gè)吊燈是非常大、組合裝的有很多零部件、有些零部件又是易碎品,這種的話再下單完成支付時(shí)是一個(gè)訂單,但是在訂單信息傳到倉庫,是倉庫再進(jìn)行拆單嗎?根據(jù)不同品類拆成易碎品和非易碎品兩種訂單嗎?還是該怎么理解
強(qiáng)烈推薦lz開公號~必關(guān)注!
寫得很好呀,如果有配合具體的實(shí)現(xiàn)界面就好了,這樣輕松不少,也能說明這個(gè)是可以走通的
兄弟你的這種分?jǐn)偹惴ǎ瑢?shí)付款最后少退了1分,總賬平不了啊,最后一件商品用實(shí)付款-所有已退款商品和,最后一件商品要單獨(dú)處理的,贈品的退還邏輯相對復(fù)雜一對一、一對多、多對一,ROUNDUP和ROUNDDOWN函數(shù)
就是說不要用平均分?jǐn)偟姆绞?,因?yàn)樗闫骄鶗姓`差,應(yīng)該前面幾件產(chǎn)品用平均的方式,最后一件用總的去減,這樣就沒誤差了~
這個(gè)處理方式很好啊
寫的很細(xì)致,收益匪淺,也讓人有很多思考點(diǎn)和火花點(diǎn),謝謝大神~
7年領(lǐng)域?qū)m?xiàng),全網(wǎng)資源整合營銷
【擁有資源】:微博、微信、快手、抖音、小紅書、網(wǎng)媒、網(wǎng)紅等等
【主營業(yè)務(wù)】:門戶發(fā)稿、品牌推廣、SEO優(yōu)化、關(guān)鍵詞排名、網(wǎng)紅帶貨等
【尋求資源】:廣告商、公關(guān)公司、店鋪商家、品牌方
【合作模式】:合同制
【聯(lián)系方式】:vx:qwe580
您好,有幾個(gè)問題想和您聊一聊:
1.請問平臺是依據(jù)什么規(guī)則進(jìn)行拆單呢?是優(yōu)先判斷是否存在多個(gè)商家、多個(gè)商家時(shí)是否存在多個(gè)倉庫、每個(gè)倉庫是否存在多個(gè)商品的多個(gè)物流配送等規(guī)則進(jìn)行多次拆單嗎?
2.拆單成功后是直接生成發(fā)貨單嗎?還是拆單完成后直接推送至賣家,由賣家自己依據(jù)情況生成發(fā)貨單呢?
3.關(guān)于物流的二次拆單,如果物流拆單后多于平臺的拆單數(shù)量,系統(tǒng)是否只顯示一種物流信息呢?比如平臺拆成子訂單推送至商鋪,貨品是20個(gè)椅子,但是此次物流需要分兩箱配送,同時(shí)就是兩個(gè)物流單號,此時(shí)是否存在物流拆單多于平臺的拆單呢?此場景可以在一個(gè)子訂單里顯示兩個(gè)物流信息嗎?
我是電商的初學(xué)者,不知道提出的問題是否對?希望我們多交流謝謝。
根據(jù)平臺是多商戶商城還是自營商城進(jìn)行設(shè)計(jì),如果并存的情況下,先區(qū)分商戶對訂單進(jìn)行拆單,訂單拆單完成后再對物流進(jìn)行拆單,物流層拆單成為多個(gè)物流單來對應(yīng)子訂單。
請問,拆單之前,是否需要商戶上架每個(gè)商品時(shí),對每個(gè)商品的倉庫、物流方式都先配置好,才可以降低拆單后的出錯率呢?
針對您的問題,個(gè)人淺見,歡迎拍磚!
1. 訂單提交后,訂單的所有商品,在庫存里,狀態(tài)應(yīng)該都從 可購買 -> 預(yù)鎖定 狀態(tài)。(30分鐘內(nèi)未付款,釋放商品,狀態(tài) 更新為 可購買。 )
2. 客戶付款后, 訂單的所有商品,在庫存里, 都 改為 鎖定 狀態(tài)。
3. 所以,庫存里面的這些SKU,都被這個(gè)訂單占有了, 無論是否拆單。
4. 回到你說的物流問題,我的理解是要分2個(gè)步驟:
-4.1. 商品的出庫管理,出庫管理,每個(gè)倉庫會有自己的出庫單;
-4.2. 出庫商品的物流管理 ,不同倉庫肯定是不同物流單; 相同倉庫,可以是1個(gè) 或 多個(gè)物流單。
上述的 各類訂單,我們可以把他們理解為 各個(gè) 交易數(shù)據(jù)。 每個(gè)交易數(shù)據(jù)之間 都是 關(guān)聯(lián)的。。
如:
-原始訂單 : 拆分訂單 = 1:N
-拆分訂單 : 出庫單 = 1:N
-出庫單: 物流單 = 1:N
上述各工單最核心的是元素是:產(chǎn)品的唯一編號, 對應(yīng)唯一的SKU。
寫的好棒。確認(rèn)一下,當(dāng)有滿減情況下的退款也是退實(shí)付的價(jià)格嗎?
寫的太贊了,但是逆向訂單還有更多的一些場景,例如:涉及到促銷活動、優(yōu)惠券等優(yōu)惠政策的部分商品退款
逆向訂單中有一些賠償、換貨、收發(fā)貨差異的場景
個(gè)人提點(diǎn)意見,寫的面太廣,不如聚焦幾個(gè)方面展開說明的好。
謝謝你的建議
贊