訂單系統(tǒng)的完整性離不開幾個部分，上次講訂單字段，各種字段信息組成了一個訂單詳情頁。如果將字段信息比喻成訂單系統(tǒng)的血液，那訂單狀態(tài)的切換就好比訂單系統(tǒng)靈活的神經(jīng)，沒有訂單狀態(tài)之間的切換，就構成不了龐大的訂單系統(tǒng)，也滿足不了很多網(wǎng)購時各種情況。
訂單流程
訂單流程是指從訂單產(chǎn)生到完成整個流轉的過程，其中包括正想流程和逆向流程。開發(fā)電商企業(yè)采購訂單管理系統(tǒng)正向流程就是一個正常的網(wǎng)購步驟：訂單生成-->支付訂單-->賣家發(fā)貨-->確認收貨-->交易成功。而逆向流程則是各種退款流程。
正向流程
-1.png)
整個電商訂單管理系統(tǒng)設計的流程其實是非常多的，接下來我們將從比較具體的描述一下各個環(huán)節(jié)下的實際情況：
訂單生成：
用戶下單后，系統(tǒng)需要生成訂單，此時需要先獲取下單中涉及的商品信息，然后獲取該商品所涉及到的優(yōu)惠信息，如果商品不參與優(yōu)惠信息，則無此環(huán)節(jié)，接著獲取該賬戶的會員權益（這里其實需要注意的是，優(yōu)惠信息與會員權益是有區(qū)別的，就好比商品滿減是優(yōu)惠信息，新人立減是會員權益。一個是針對商品，另一個是針對賬戶）。
庫存扣減是指可銷售庫存數(shù)量-1，嚴格來講庫存扣減目前分為兩種，一種是下單減庫存，另一種是付款減庫存；個人覺得中小創(chuàng)業(yè)者也許競爭者不比淘寶中的賣家，在電商這個存量市場，需要精細化的運營才能存活下來，如此說保證用戶體驗才是根本，所以我這里的觀點是生成訂單扣減庫存，這種做法會避免用戶支付成功商家卻沒貨的情況。然后計算運費，訂單生成成功。
支付訂單：
用戶支付完訂單后，需要獲取訂單的支付信息，包括支付流水號，支付時間等。支付完訂單接著就是等商家發(fā)貨，但在發(fā)貨過程中，往往還有一種情況存在，很正常卻也比較復雜，就是訂單拆單。訂單拆單分兩種，一種是用戶挑選的商品來自于不同渠道（自營與商家，商家與商家），此時就需要拆分訂單，并分開結算，這里還涉及父子訂單的說法，這里不再贅述。另一種是在SKU層面上拆分訂單。不同倉庫，不同運輸要求的SKU，包裹重量體積限制等因素都需要將訂單拆分。
比如商品A只在甲倉庫有，商品B又只在乙倉庫有，此時會將商品A與商品B拆分成兩個訂單?；蛘哂行┢髽I(yè)的做法是將商品A/B調(diào)撥到另外一個倉庫統(tǒng)一發(fā)貨，也方便了用戶。訂單拆單看起來簡單，其實里面涉及到底層的系統(tǒng)支持，如你需要對每一個倉庫的貨品進行相對準確的盤點，且做到實時同步（涉及到倉庫精細化管理）；對商品進行準確分類與擺放；對商品信息記錄準確無誤等；這其中哪一模塊都是一個浩大的工程，PM一般進入一家公司都會在原有（半成品）的基礎上進行優(yōu)化，大家不妨多思考一下底層業(yè)務，只有在底層做好精細化管理，才能支持線上豐富的用戶需求。
商家發(fā)貨：
商家發(fā)貨過程也有一個標準化的流程。上面也有講到，訂單拆分時會涉及到倉庫間調(diào)撥，然后倉庫會對商品進行打單，揀貨，包裝，交接快遞配送。這套標準化流程如果優(yōu)化好，也是一個大工程，這里不再贅述，建議大家看看庫存與倉庫管理方面的書籍，詳細了解。
確認收貨：
商家發(fā)貨后，就是等快遞配送了，訂單系統(tǒng)需要接入一些常用快遞企業(yè)的接口，方便用戶與商家在站內(nèi)查詢快遞信息。
交易成功：
收到貨后，不是一個服務的結束，相反是一個服務的開始。訂單電商系統(tǒng)需要在快遞被簽收后提醒用戶對商品做評價，這里要注意，確認收到貨不代表交易成功，交易成功是指在收到貨X天的狀態(tài)，此時訂單不在售后的支持時間范圍內(nèi)。到此，一個訂單的正向流程就算走完了。
目前我也沒有研究過，不過我的經(jīng)驗告訴我訂單系統(tǒng)對售后訂單的處理并不比正產(chǎn)訂單少，身為電商PM，我們的工作就是去優(yōu)化這些流程，提高用戶粘性。本身售后訂單的出現(xiàn)，在某種程度上已經(jīng)傷害到了用戶，如果流程還一團糟的話，我們根本沒有機會等到用戶的復購。
逆向流程
-2.png)
訂單逆向流程
一個電商的基本逆向流程如上圖所示，訂單的逆向流程復雜就在于它幾乎允許在正向流程的任何環(huán)節(jié)出現(xiàn)，有人會問，用戶未收到貨為什么還能退款，其實我們換為思考，也很容易理解，假想你是用戶，買了一雙鞋子，付了款發(fā)了貨，正在美滋滋的等待收快遞，然后剛好路過一家鞋店看到剛買的同款鞋子大促銷，于是你就拿起手機點擊退款，買下了這雙促銷的鞋子。這種場景其實是很普通也很正常的用戶日常，所以我們的訂單系統(tǒng)就必須得支持用戶各種豐富的場景需求，也十分考驗PM的業(yè)務滲透能力，好在電商的先行者淘寶已經(jīng)做了很多基礎建設和用戶教育，我們直接可以拿來套用，不過還是要根據(jù)各個公司的業(yè)務情況進行修改。
取消訂單：
用戶提交訂單時，在跳轉至支付前直接退出，此時用戶原則上屬于取消訂單，因為還未付款，則比較簡單，只需要將原本提交訂單時扣減的庫存補回即可。
支付失?。?/b>
用戶進行支付時退出，或者取消支付，我們將其列為支付失敗狀態(tài)，此時處理同上，將扣減的庫存補回可銷售庫存即可。
付款后退款：
用戶支付成功后，商家還未發(fā)貨，支持用戶申請退款，此時如果倉庫與客服是分離的，則需要先檢查倉庫是否已經(jīng)發(fā)貨，若已發(fā)貨則應與客戶溝通是否可以收到貨后再進行退款，如果倉庫還未發(fā)貨，則可直接同意用戶退款。或者企業(yè)接入菜鳥物流，實行截件功能，不過這種操作還不成熟，成本會比較大，不適合中小創(chuàng)業(yè)型公司。
缺貨退款：
用戶支付成功后，商家發(fā)貨時發(fā)現(xiàn)倉庫缺貨（如果提交訂單扣減庫存，則會減少缺貨情況，為什么是減少而不是避免？因為倉庫管理商品時沒辦法做到100%精準，所以信息有時候會不準確，導致線上的可銷售庫存顯示有庫存而倉庫已經(jīng)售空的狀態(tài)），則需要與用戶協(xié)商是否退款，這個流程訂單系統(tǒng)可以做到流程化，自動化，連接消息中心和倉庫管理系統(tǒng)去實現(xiàn)，難點在于消息的實時性。我就遇到過在淘寶買過一件上衣，一天過去了，商家跟我說沒貨了，我當時殺人的心都有了。
待收貨退款：
這個問題目前還沒有特別完美的解決方法，商家發(fā)了貨之后，用戶還未收到貨，此時貨在路上。我曾經(jīng)在一些交流群里提出過這個問題，大家的看法都不一樣，大體上分為兩種做法。一種是用戶收到貨后重新寄回；另一種是用戶直接拒收包裹，包裹直接退回原地址；我個人傾向于第一種，第一種比較靈活，因為用戶未收到貨就退款的原因一般與商品質(zhì)量關系不大，所以如果允許用戶直接拒收退回，相當于商家需要承擔回退運費，而本身可能與商家并無太大關系。另外一個原因就是，有些商家發(fā)貨地址與退貨地址不在同個地方，不支持直接退回。盡管如此，在到處強調(diào)用戶體驗的今天，增加用戶的售后成本也是在消耗用戶對平臺的耐心，大家不妨去思考一下，有沒有更好的解決方法。
用戶拒收：
同上
退貨退款：
用戶收到貨后，想要申請售后，則此時需要提供讓用戶輸入售后原因，包括上傳憑證的功能，如果與商家協(xié)商無果，還需要增加平臺客服的入口，方便用戶進行申訴。而協(xié)商結果/申訴成功后直接觸發(fā)自動退款機制，退款后觸發(fā)消息通知，同時觸發(fā)交易關閉狀態(tài)，整個售后過程才算結束。
我上面有好幾處都提到與消息中心的對接，消息的觸發(fā)等，其實這也算是訂單系統(tǒng)設計的一部分內(nèi)容，稱之為訂單推送，當訂單狀態(tài)機發(fā)生變化時，需要將對應的變化情況告知給相關人員以便了解當前訂單的情況，這也是訂單推送的作用。
訂單推送
訂單推送的觸發(fā)依賴于狀態(tài)機的改變，涉及到的信息包括：
· 推送對象（用戶，商家，倉庫）
· 推送方式（站內(nèi)消息，push，短信，微信）
· 推送節(jié)點（狀態(tài)機）
本文主講訂單系統(tǒng)的核心模塊設計邏輯，訂單推送的具體設計就不再此處贅述。
結言：
一個訂單系統(tǒng)的設計絕非這么簡單，它需要一批又一批的人去維護，去優(yōu)化，根據(jù)公司的業(yè)務情況做出改變和兼容。大家平時在做產(chǎn)品設計的時候可以多深入了解一下公司的具體業(yè)務場景，這樣才能做出適用自己企業(yè)的訂單系統(tǒng)。
作者：林嘉杰 ，來源：CSDN
<數(shù)商云（www.zhimaihui.cn）是國內(nèi)知名企業(yè)級電商平臺提供商，為企業(yè)級商家提供最佳的系統(tǒng)開發(fā)（多種模式電商平臺搭建：B2B/B2B2C/B2C/O2O/新零售等）、供應商系統(tǒng)搭建及電商解決方案服務>
評論