訂單管理流程

訂單概述電商所有模塊中，訂單模塊是核心中的核心，電商所有模塊都是直接或者間接為訂單模塊服務(wù)的。電商系統(tǒng)涉及到3流，分別時信息流，資金流，物流，而訂單系統(tǒng)作為中樞將三者有機的集合起來，訂單系統(tǒng)就從這三流開始吧。訂單場景訂單場景的說明不言而喻，不同場景下訂單表現(xiàn)形式和數(shù)據(jù)傳遞方式也不相同，目前主流的訂單場景包括線上電商訂單、O2O電商訂單。（1）線上電商訂單這種電商就像淘寶、京東等，通過線上下單、支付后由自建物流或者第三方物流進行配送。這種電商系統(tǒng)通過，展示電商系統(tǒng)的商品模塊引導(dǎo)用戶對商品進行訂單模塊的處理，訂單模塊處理完成后將信息傳遞給WMS系統(tǒng)進行處理，當(dāng)用戶收到貨品后在訂單系統(tǒng)進行確認(rèn)。通過以上系統(tǒng)的協(xié)同處理來完成整個訂單信息的處理。如果是虛擬物品的話需要調(diào)用其他系統(tǒng)進行對接，通過接口返回參數(shù)方式完成信息的處理，比如充話費、買點卡等。（2）O2O電商訂單這種電商包括兩種外賣訂單和團購訂單。外賣訂單和線上電商訂單有些類似，線上訂單處理完成后只是沒有經(jīng)過倉庫環(huán)節(jié)進行處理，而是需要生產(chǎn)環(huán)節(jié)對數(shù)據(jù)進行處理，生產(chǎn)完成后將信息傳遞給物流環(huán)節(jié)，用戶確認(rèn)收貨后再對訂單信息進行處理。而團購訂單則是線上獲取商品信息后，通過訂單系統(tǒng)處理完成，將信息傳遞給wms系統(tǒng)進行庫存處理，只是對庫存進行信息處理而沒有物流配送環(huán)節(jié)，用戶線下到店后對訂單系統(tǒng)進行核銷處理，從而完成整個訂單信息的閉環(huán)訂單構(gòu)成我們先從訂單整個架構(gòu)進行了解，以下是整個訂單系統(tǒng)的構(gòu)成：用戶信息用戶信息包括用戶賬號、用戶等級、用戶的收貨地址、收貨人、收貨人電話等組成，用戶賬戶需要綁定手機號碼，但是用戶綁定的手機號碼不一定是收貨信息上的電話。用戶可以添加多個收貨信息，用戶等級信息可以用來和促銷系統(tǒng)進行匹配，獲取商品折扣，同時用戶等級還可以獲取積分的獎勵等。訂單基礎(chǔ)信息訂單基礎(chǔ)信息是訂單流轉(zhuǎn)的核心，其包括訂單類型、父/子訂單、訂單編號、訂單狀態(tài)、訂單流轉(zhuǎn)的時間等。（1）訂單類型包括實體商品訂單和虛擬訂單商品等，這個根據(jù)商城商品和服務(wù)類型進行區(qū)分。（2）同時訂單都需要做父子訂單處理，之前在初創(chuàng)公司一直只有一個訂單，沒有做父子訂單處理后期需要進行拆單的時候就比較麻煩，尤其是多商戶商場，和不同倉庫商品的時候，父子訂單就是為后期做拆單準(zhǔn)備的。（3）訂單編號不多說了，需要強調(diào)的一點是父子訂單都需要有訂單編號，需要完善的時候可以對訂單編號的每個字段進行統(tǒng)一定義和詮釋。（4）訂單狀態(tài)記錄訂單每次流轉(zhuǎn)過程，后面會對訂單狀態(tài)進行單獨的說明。（5）訂單流轉(zhuǎn)時間需要記錄下單時間，支付時間，發(fā)貨時間，結(jié)束時間/關(guān)閉時間等等。商品信息商品信息從商品庫中獲取商品的SKU信息、圖片、名稱、屬性規(guī)格、商品單價、商戶信息等，從用戶下單行為記錄的用戶下單數(shù)量，商品合計價格等。優(yōu)惠信息優(yōu)惠信息記錄用戶參與的優(yōu)惠活動，包括優(yōu)惠促銷活動，比如滿減、滿贈、秒殺等，用戶使用的優(yōu)惠券信息，優(yōu)惠券滿足條件的優(yōu)惠券需要默認(rèn)展示出來，具體方式已在之前的優(yōu)惠券篇章做過詳細(xì)介紹，另外還虛擬幣抵扣信息等進行記錄。為什么把優(yōu)惠信息單獨拿出來而不放在支付信息里面呢？因為優(yōu)惠信息只是記錄用戶使用的條目，而支付信息需要加入數(shù)據(jù)進行計算，所以做為區(qū)分。支付信息（1）支付流水單號，這個流水單號是在喚起網(wǎng)關(guān)支付后支付通道返回給電商業(yè)務(wù)平臺的支付流水號，財務(wù)通過訂單號和流水單號與支付通道進行對賬使用。（2）支付方式用戶使用的支付方式，比如微信支付、支付寶支付、錢包支付、快捷支付等。支付方式有時候可能有兩個——余額支付+第三方支付。（3）商品總金額，每個商品加總后的金額；運費，物流產(chǎn)生的費用；優(yōu)惠總金額，包括促銷活動的優(yōu)惠金額，優(yōu)惠券優(yōu)惠金額，虛擬積分或者虛擬幣抵扣的金額，會員折扣的金額等之和；實付金額，用戶實際需要付款的金額。用戶實付金額=商品總金額+運費-優(yōu)惠總金額物流信息物流信息包括配送方式，物流公司，物流單號，物流狀態(tài)，物流狀態(tài)可以通過第三方接口來獲取和向用戶展示物流每個狀態(tài)節(jié)點。三、訂單狀態(tài)待付款用戶提交訂單后，訂單進行預(yù)下單，目前主流電商網(wǎng)站都會喚起支付，便于用戶快速完成支付，需要注意的是待付款狀態(tài)下可以對庫存進行鎖定，鎖定庫存需要配置支付超時時間，超時后將自動取消訂單，訂單變更關(guān)閉狀態(tài)。已付款/待發(fā)貨用戶完成訂單支付，訂單系統(tǒng)需要記錄支付時間，支付流水單號便于對賬，訂單下放到WMS系統(tǒng),倉庫進行調(diào)撥，配貨，分揀,出庫等操作。待收貨/已發(fā)貨倉儲將商品出庫后，訂單進入物流環(huán)節(jié)，訂單系統(tǒng)需要同步物流信息，便于用戶實時知悉物品物流狀態(tài)已完成用戶確認(rèn)收貨后，訂單交易完成。后續(xù)支付側(cè)進行結(jié)算，如果訂單存在問題進入售后狀態(tài)已取消付款之前取消訂單。包括超時未付款或用戶商戶取消訂單都會產(chǎn)生這種訂單狀態(tài)。售后中用戶在付款后申請退款，或商家發(fā)貨后用戶申請退換貨。售后也同樣存在各種狀態(tài)，當(dāng)發(fā)起售后申請后生成售后訂單，售后訂單狀態(tài)為待審核，等待商家審核，商家審核通過后訂單狀態(tài)變更為待退貨，等待用戶將商品寄回，商家收貨后訂單狀態(tài)更新為待退款狀態(tài)，退款到用戶原賬戶后訂單狀態(tài)更新為售后成功。訂單流程訂單流程是指從訂單產(chǎn)生到完成整個流轉(zhuǎn)的過程，從而行程了一套標(biāo)準(zhǔn)流程規(guī)則。而不同的產(chǎn)品類型或業(yè)務(wù)類型在系統(tǒng)中的流程會千差萬別，比如上面提到的線上實物訂單和虛擬訂單的流程，線上實物訂單與O2O訂單等，所以需要根據(jù)不同的類型進行構(gòu)建訂單流程。不管類型如何訂單都包括正向流程和逆向流程，對應(yīng)的場景就是購買商品和退換貨流程，正向流程就是一個正常的網(wǎng)購步驟:訂單生成-＞支付訂單-＞賣家發(fā)貨-＞確認(rèn)收貨-＞交易成功。而每個步驟的背后，訂單是如何在多系統(tǒng)之間交互流轉(zhuǎn)的，可概括如下圖：訂單創(chuàng)建訂單創(chuàng)建是從用戶下單開始的，當(dāng)用戶對商品進行下單后，系統(tǒng)會引導(dǎo)用戶來到確認(rèn)訂單頁面，此時系統(tǒng)會獲取用戶預(yù)下單的商品信息，同時判斷商品是否涉及到優(yōu)惠促銷的信息，這些優(yōu)惠券包括促銷活動，優(yōu)惠券，積分抵扣等。除了獲取優(yōu)惠信息外，還需要判斷用戶等級權(quán)益，比如VIP用戶8折優(yōu)惠，新用戶立減優(yōu)惠等，其中的券別在于一個是針對商品，一個針對的用戶等級權(quán)益，電商系統(tǒng)在開發(fā)初期如果不涉及用戶等級折扣而又有新用戶促活優(yōu)惠的話，建議使用優(yōu)惠券來做。而在優(yōu)惠活動需要遵循配置的疊加規(guī)則和優(yōu)先級規(guī)則，在預(yù)下單操作是需要做判斷。在預(yù)下單操作時，需要對庫存進行查詢，而庫存從什么時候進行增減，目前主流有兩種方式：下單減庫存，用戶預(yù)下單成功時減少庫存數(shù)量，優(yōu)點是系統(tǒng)邏輯比較簡單，庫存實時展示用戶體驗好，同時也帶來了惡意下單的風(fēng)險。付款減庫存，用戶支付完成后再減少庫存，優(yōu)點減少惡意下單的風(fēng)險，缺點是第三方支付回調(diào)采取的是異步回調(diào)方式，回調(diào)結(jié)果返回系統(tǒng)需要時間，并發(fā)下單情況下可能導(dǎo)致庫存不足引發(fā)退款和投訴。個人比較傾向于下單減庫存的方式，在電商這個競爭激烈的環(huán)境下，保障用戶體驗才是第一位的，同時需要做好相對的措施，預(yù)下單后馬上對庫存進行鎖定，鎖定時間同步訂單支付的限定時間。比如淘寶的15分鐘，限定時間內(nèi)沒有付款，將鎖定庫存進行回滾釋放。這種下單減庫存的方式，可以減少用戶因為下單后倉庫沒有貨的情況，減少用戶的挫敗感。訂單支付訂單支付在支付層面涉及的方面比較多，比如默認(rèn)支付渠道，支付渠道的路由，組合支付等，在這里就不多加敘述，訂單支付過程做需要選擇支付方式，支付完成后通過支付渠道會返回支付流水號，支付完成時間。系統(tǒng)需要記錄訂單同時生成支付流水，方便與支付渠道進行對賬。支付完成后下一步是等待賣家發(fā)貨或者是訂單下放到倉庫，在此過程中，會涉及到拆單過程，一般拆單分為兩次拆單：一次拆單：訂單層面的拆單，這個拆單主要是因為組合商品時，各個商品屬于不同商家，此時訂單需要使用父子訂單進行區(qū)分二次拆單：商品層面的拆單，這個拆單由于商品分屬不同的倉庫，重量/體積限制，商品品類要求比如易燃或者貴重物品需要單獨打包，商品庫存原因，比如需要有些商品當(dāng)天發(fā)生，有些商品48小時后發(fā)送，另外對于海淘來說還存在關(guān)稅問題需要拆單的。對于拆單后面還會繼續(xù)進行說明。賣家發(fā)貨/倉儲處理這個過程從線下走向線下，商家發(fā)貨過程已經(jīng)形成一個標(biāo)準(zhǔn)化的流程，訂單內(nèi)容會下放到倉庫，倉庫對商品進行打單、揀貨、包裝、交接快遞進行配送。目前很多WMS系統(tǒng)都與主流電商系統(tǒng)進行了對接，訂單下單成功后直接進入到WMS系統(tǒng)，在此過程中會涉及到合并訂單，比如同一買家同一收貨信息分多筆下單的訂單，訂單審核，訂單重新分倉，下放庫房，生成批檢單，訂單打印等等。關(guān)于物流倉儲方面后面物流篇講進行詳述。確認(rèn)收貨訂單通過倉儲環(huán)節(jié)，已經(jīng)發(fā)貨了，在訂單系統(tǒng)中會涉及到對物流信息的獲取，包括配送方式/物流公司/物流單號/物流狀態(tài)的實時顯示。記得淘寶沒有打通物流查詢環(huán)節(jié)時，那時候想知道包裹到哪里，需要根據(jù)商家提供的物流公司和物流單號，在物流公司官網(wǎng)進行查詢，而現(xiàn)在很多物流公司開放了物流接口，可以根據(jù)物流接口獲取物流狀態(tài)信息。當(dāng)用戶收到貨后，可以根據(jù)物流公司反饋的簽收結(jié)果，設(shè)置提醒用戶確認(rèn)收貨。訂單完成用戶確認(rèn)收貨后，這個訂單總算完了，NO,NO,NO,演出才剛剛開始。訂單完成后會涉及到需要提醒用戶進行訂單的點評，同時可能會涉及到訂單的售后問題。交易成功是指在收貨后N天后，此時除去售后問題外,渠道側(cè)會涉及到平臺和支付渠道結(jié)算的問題，貨款需要從支付渠道流入平臺賬戶；商戶側(cè)會涉及到平臺需要生成待結(jié)算清單問題，明細(xì)該筆訂單商戶結(jié)算款是多少。如果涉及到三級分銷的話，還需要考慮到各級代理分潤問題。逆向訂單訂單逆向過程是個非常頭痛的問題，每次涉及訂單的時候，每次都傻傻地問boss可以不做退款退貨流程嗎？老板很鄙夷地回答：沒有買賣就沒有傷害。有人的地方就有江湖，有訂單的地方就有退款退貨一個道理，所以安心設(shè)計好逆向流程才是王道。關(guān)于訂單逆向流程，想想線下一些購買場景理解起來就方便很多了，接下來就舉例說明逆向訂單：大傻去電腦城去買個筆記本電腦在千挑萬選后終于在奸商小K的說服下，準(zhǔn)備下單購買一臺聯(lián)想小新air，故事就這么發(fā)生了……CASE1修改訂單這個時候在小K的說服下大傻選購小新air，突然大傻對小新air配置還有一些優(yōu)惠提出了新的疑問，好吧……正準(zhǔn)備開單的小K為了促成這個交易在單子上面給大傻填寫贈送鼠標(biāo)，背包…修改訂單發(fā)生在預(yù)下單過程中，用戶沒有提交訂單，可以對訂單一些信息進行修改，比如配送信息，優(yōu)惠信息，及其他一些訂單可修改范圍的內(nèi)容，此時只需對數(shù)據(jù)進行變更即可。訂單取消待支付情況下，各種單據(jù)都填好了，小K說：哥，你該付款了。大傻一摸口袋，錢包不見了。小長心里想，哥，你逗我玩呢？這個時候有3種情況：第一，大傻回去拿錢后給了小K錢。第二，大傻說這個電腦不要了，單據(jù)作廢吧。第三，大傻說我回去拿錢，返回后結(jié)果門店下班了，單據(jù)也作廢了。這個狀態(tài)下對應(yīng)電商場景下的用戶主動取消訂單和用戶超時未支付，兩種情況下訂單都會取消訂單，而超時情況是系統(tǒng)自動關(guān)閉訂單，所以在訂單支付的響應(yīng)機制上面要做支付的限時處理，尤其是在前面說的下單減庫存的情形下面，可以保證快速的釋放庫存。另外需要需要處理的是促銷優(yōu)惠中使用的優(yōu)惠券，權(quán)益等視平臺規(guī)則，進行相應(yīng)補回給用戶。退款待發(fā)貨情況下，大傻及時付完款了，小K心里樂開了花，在去倉庫的路上一蹦一跳的，心里琢磨著這筆單下來晚上可以好好喝一杯了，結(jié)果跑到倉庫拿貨，倉庫告訴小K沒有貨了，小K心里一萬匹草泥馬在奔馳著。沒有辦法，小K只好回去告訴大傻，完了大傻對小K一頓咆哮，最終小K還是把錢退給了大傻。故事還有另外一個版本：大傻及時付完款了，小K心里樂開了花，在去倉庫的路上一蹦一跳的，心里琢磨著這筆單下來晚上可以好好喝一杯了。還沒有到倉庫，前臺小姐姐給他打電話，大傻說隔壁王阿姨的姑姑的表姐的女兒出了車禍要借錢，所以大傻不要筆記本了，小K心里一萬匹草泥馬在奔馳著。沒有辦法，小K只好給大傻退款。在待發(fā)貨訂單狀態(tài)下取消訂單時，分為商戶缺貨退款和用戶申請退款。商戶缺貨退款由于訂單系統(tǒng)和WMS系統(tǒng)商品沒有進行及時同步導(dǎo)致，或者是倉管和客服分開產(chǎn)生的，這個情況下需要與用戶協(xié)商處理退款。用戶申請退款，用戶下單后，商家還未發(fā)貨，系統(tǒng)應(yīng)該支持用戶申請退款，如果發(fā)貨單已經(jīng)下發(fā)到wms系統(tǒng)，但是尚未推送至倉庫，則應(yīng)該挺推送至倉庫，推送至倉庫則需要WMS中進行攔截，攔截成功則暫定出庫，同步訂單系統(tǒng)同意取消訂單，同時進入退款流程。如果是全部退款則訂單更新為關(guān)閉狀態(tài)，若只是做部分退款則訂單仍需進行進行，同時生成一條退款的售后訂單，走退款流程。退款金額需原路返回用戶的賬戶。發(fā)貨后的退款我們繼續(xù)那個故事：當(dāng)小K從倉庫將筆記本電腦領(lǐng)出來后，將電腦拿給大傻，大傻一看包裝破破爛爛的啥玩意啊，老子不要了，不管小K好說歹說，大傻堅決不要了，拗不過他，小K最終還是給大傻退了錢。發(fā)貨后的退款，發(fā)生在倉儲已經(jīng)貨物的配送，在配送過程中商品遺失，用戶拒收，用戶收貨后對商品不滿意，這樣情況下用戶發(fā)起退款的售后訴求后，需要商戶進行退款的審核，雙方達成一致后，系統(tǒng)更新退款狀態(tài)，對訂單進行退款操作，金額原路返回用戶的賬戶，同時關(guān)閉原訂單數(shù)據(jù)。僅退款情況下暫不考慮倉庫系統(tǒng)變化。如果發(fā)生雙方協(xié)調(diào)不一致情況下，可以申請平臺客服介入。在退款訂單商戶不處理的情況下，系統(tǒng)需要做限期判斷，比如5天商戶不處理，退款單自動變更同意退款。CASE5退款退貨故事還沒有完，大傻沒有在小長家買成筆記本，又去了阿貍家買成了筆記本電腦，誰知道阿貍家筆記本更黑