訂單管理是一個常見的管理問題，包含在企業(yè)的訂單處理流程中。由于客戶/用戶下訂單的方式多種多樣、訂單執(zhí)行路徑千變?nèi)f化、產(chǎn)品和服務(wù)不斷變化、發(fā)票開具難以協(xié)調(diào)，這些情況使得訂單管理變得十分復(fù)雜。 

訂單管理的本質(zhì)就是處理訂單的過程。

在前文的庫存管理與系統(tǒng)設(shè)計中，我們系統(tǒng)的梳理了三層庫存模型，本文則著重探討如何根據(jù)訂單流向設(shè)計從下單到發(fā)貨的全流程訂單管理系統(tǒng)。

事實上，在早期excel表格是最常用的訂單數(shù)據(jù)處理方式之一，主要用于輸入、輸出、顯示、處理和打印數(shù)據(jù)，可以制作各種復(fù)雜的表格文檔，甚至能幫助用戶進(jìn)行復(fù)雜的統(tǒng)計運(yùn)算和圖表化展示等。今天的訂單管理系統(tǒng)也依然基于這一基本邏輯。

01訂單屬性

所謂訂單履約，就是從訂單交易產(chǎn)生以后，到用戶最終收到商品，包括售后的整個過程。所以我們的訂單履約系統(tǒng)的主要實現(xiàn)目標(biāo)是能高效且透明的完成訂單履約全過程，保證用戶體驗。

一張訂單在訂單履約全流向中，需要調(diào)度各個系統(tǒng)獲取履約的各種信息，所以訂單信息應(yīng)該越全面越好，這里展示一些訂單的核心屬性（盡管訂單在客戶/用戶的眼中好簡單得多）：

1.基本信息：訂單編號、來源編號、銷售平臺與銷售店鋪、下單時間、訂單狀態(tài)、支付方式（在線支付/貨到付款）、買家留言、配送方式（物流配送/自提）、下單賬號、訂單類型（實物訂單/虛擬訂單）；

2.財務(wù)信息：付款方式（微信、支付寶、銀行卡、現(xiàn)金…）、支付平臺、支付賬戶（微信賬號、支付寶賬號）、商戶訂單號、支付流水號、訂單應(yīng)付總金額、已支付金額、貨到付款金額、商品總金額、運(yùn)費(fèi)、客服增加/減免金額；

3.收貨信息：收貨人、收貨人手機(jī)\電話、收貨人省份、收貨人市、收貨人區(qū)\縣、收貨人鄉(xiāng)鎮(zhèn)、收貨人詳細(xì)地址；

4.發(fā)票信息：開發(fā)票的訂單，應(yīng)包含發(fā)票抬頭和發(fā)票明細(xì)信息：

• 發(fā)票抬頭信息：發(fā)票類型（紙質(zhì)/電子）、發(fā)票號、抬頭、發(fā)票稅號、公司地址、電話號碼、開戶行、銀行賬號、發(fā)票金額、開票人

• 發(fā)票明細(xì)信息：明細(xì)類目明細(xì)、包裝規(guī)格、包裝單位、數(shù)量、含稅單價、含稅金額、稅率；

5.促銷信息：促銷類型（優(yōu)惠券、積分、滿減等）、促銷ID、金額；

6.物流信息：發(fā)貨庫房、系統(tǒng)指派物流公司、系統(tǒng)指派電子面單號、實際發(fā)貨物流公司、實際發(fā)貨物流單號、物流公司月結(jié)賬號、大頭筆信息；

7.商品明細(xì)信息：sku編碼、sku名稱、商品規(guī)格、銷售單價、實付單價（各種優(yōu)惠折扣計算完以后的單價）、數(shù)量、實付金額（實付單價*數(shù)量）；

8.訂單全程跟蹤信息：記錄訂單履約的每一步的操作人、操作時間及操作內(nèi)容。

訂單系統(tǒng)架構(gòu)

一般來說，電商平臺有兩大類業(yè)務(wù)：三方電商平臺和自營平臺。三方平臺指的是在天貓、京東等平臺上開的電商店鋪，自有平臺是企業(yè)自行搭建的商城，和一些對外的sdk、API等渠道。

同時一定規(guī)模的企業(yè)，都可能會開設(shè)多個門店，多個倉庫，遍布全國各地，各地配送區(qū)域不同，甚至有些門店的還能夠支持用戶到店自提，以及急速送達(dá)等多種配送業(yè)務(wù)。

所以，通常來說訂單履約系統(tǒng)的架構(gòu)可以這樣設(shè)計：

▲  訂單履約系統(tǒng)架構(gòu)設(shè)計圖

訂單履約系統(tǒng)負(fù)責(zé)處理訂單履約的全過程，對上通過訂單轉(zhuǎn)換中心與銷售平臺進(jìn)行信息同步，對下通過倉儲路由中心將訂單信息上下傳，內(nèi)部通過調(diào)度中央庫存、配送系統(tǒng)等多個外圍系統(tǒng)對訂單信息進(jìn)行層層拆解和組裝，將訂單加工為滿足履約條件的可執(zhí)行指令。 

從訂單數(shù)據(jù)上下傳通道來看，整個訂單履約從上往下涉及3層系統(tǒng)：訂單轉(zhuǎn)換中心、訂單履約中心、倉儲路由中心。  

1、訂單履約系統(tǒng)的上游是訂單轉(zhuǎn)換中心，用以對接各個銷售平臺，因為各平臺的訂單結(jié)構(gòu)不盡相同，為了能統(tǒng)一在履約系統(tǒng)中對訂單進(jìn)行管理，保證訂單內(nèi)部流轉(zhuǎn)的標(biāo)準(zhǔn)化，不至于因為某個平臺的調(diào)整而動了主體結(jié)構(gòu)，所以在訂單轉(zhuǎn)換中心中針對各個平臺配置不同的適配器，將訂單標(biāo)準(zhǔn)化以后再與履約系統(tǒng)進(jìn)行通訊。需要適配的信息包括商品、地址、訂單狀態(tài)、物流公司等。

2、訂單履約系統(tǒng)的下游是倉儲路由中心，用以與各個倉庫系統(tǒng)和門店新零售系統(tǒng)進(jìn)行交互，將訂單路由分發(fā)至目標(biāo)庫房進(jìn)行生產(chǎn)，同時將目標(biāo)庫房的發(fā)貨信息收集并回傳至訂單履約中心。

02訂單系統(tǒng)流程

從系統(tǒng)層面看，一張實物類的訂單從銷售平臺下單，到最終用戶簽收，會經(jīng)歷10余個履約節(jié)點，涉及銷售平臺、訂單轉(zhuǎn)換中心、履約系統(tǒng)、中央庫存、配送系統(tǒng)、倉儲路由中心、倉庫/新零售系統(tǒng)等多個系統(tǒng)，所以履約流程最核心的訴求是協(xié)同和順暢，只有各系統(tǒng)相互協(xié)作，訂單自始至終很流暢的執(zhí)行完各個節(jié)點，才能保證在約定時效內(nèi)完成履約，其中任何一個節(jié)點出現(xiàn)卡殼，都會導(dǎo)致履約時效拉長，影響的是客戶對平臺的信任。

▲  實物訂單履約全流程

1.新訂單：訂單系統(tǒng)接到新單的狀態(tài)。此處根據(jù)業(yè)務(wù)分為兩塊邏輯處理：三方平臺（如天貓、京東）的訂單，客戶在銷售平臺上完成了交易，由訂單系統(tǒng)接到銷售平臺同步的訂單后的狀態(tài)；自營平臺的訂單，客戶提交訂單后，訂單系統(tǒng)便生成一張新訂單，不過此訂單需判斷若為在線支付訂單，需付款以后才能繼續(xù)往下流轉(zhuǎn)。

2.訂單拆分：為了更好的購物體驗，大部分電商平臺支持合并提交支付，在訂單生成以后，需按照商家、倉庫、商品、金額、物流等規(guī)則進(jìn)行訂單拆分，分為多個子訂單發(fā)貨。

3.訂單預(yù)分倉：為防止超賣，已經(jīng)下單的訂單需盡快進(jìn)行庫存預(yù)占，以免庫存被其它訂單占用。分倉過程由中央庫存提供服務(wù)。訂單預(yù)分倉可以提前鎖定訂單發(fā)貨倉庫，若訂單核心信息發(fā)生變化，再重新分倉。若業(yè)務(wù)上允許一個訂單被拆分為多個庫房發(fā)貨，訂單需再次拆分。需要注意的是，只有實物庫存滿足的訂單才能預(yù)分倉成功，預(yù)售類的訂單，可在訂單拆分后進(jìn)行截停等待，待真實庫存采購入庫以后再進(jìn)行分倉流轉(zhuǎn)。

 4.訂單攔截處理：某些不符合業(yè)務(wù)規(guī)則的訂單，如疑似惡意訂單，在訂單系統(tǒng)中打上攔截標(biāo)記，待人工審核通過后才能繼續(xù)放行。若明確為惡意訂單，則將訂單取消。

訂單攔截規(guī)則因為行業(yè)、公司、業(yè)務(wù)不同，要根據(jù)實際業(yè)務(wù)情況進(jìn)行梳理。另外，到底是先分倉預(yù)占，還是先攔截訂單這個問題經(jīng)常會出現(xiàn)分歧。

雖然惡意訂單可能會占用部分庫存，但處理完以后，訂單會被取消釋放庫存，此種處理方式好過一些疑似但不是惡意的訂單因為被攔截了而沒有分倉，導(dǎo)致后續(xù)庫存被其它訂單占用而引起超賣的情況。

5.合并訂單處理：為降低運(yùn)費(fèi)成本和庫房作業(yè)成本，在一定時段內(nèi)，滿足合并條件的訂單，在訂單系統(tǒng)中合并為一單下發(fā)庫房/門店發(fā)貨。

6.訂單審核：某些業(yè)務(wù)規(guī)則下，會要求訂單在人工審核處理后方能繼續(xù)流轉(zhuǎn)，例如被攔截的訂單、客戶有特殊需求的訂單等。為提升履約效率，其它訂單可自動審核而無需人工一一處理。當(dāng)然此審核功能可以直接放在履約系統(tǒng)中供客服使用，也可以提供服務(wù)供客服系統(tǒng)調(diào)用。

7.訂單重新分倉：若在人工審核處理環(huán)節(jié)，客服修改了訂單收貨地址、商品及數(shù)量等分倉相關(guān)信息，從而影響了預(yù)分倉的結(jié)果，需要重新進(jìn)行分倉預(yù)占，并清除原預(yù)分倉結(jié)果。

8.訂單分物流：由于全國各倉的物流是單獨(dú)簽約，根據(jù)倉庫所處的位置不同，簽約的物流可能不盡相同，所以在明確了發(fā)貨庫房以后，履約系統(tǒng)調(diào)用物流配送系統(tǒng)提供的物流服務(wù)進(jìn)行物流商的匹配，以及調(diào)用物流公司接口獲取電子面單相關(guān)信息。

9.下發(fā)庫房：物流公司分配完成以后，訂單履約需要的信息已組裝完全，訂單履約系統(tǒng)根據(jù)訂單距離和物流信息試算履約時效（履約時效主要用于服務(wù)承諾，為庫房波次提供參考），并將訂單下傳倉儲路由中心，經(jīng)此系統(tǒng)路由至目標(biāo)庫房或門店生產(chǎn)發(fā)貨。

10.波次下發(fā)：倉庫/門店系統(tǒng)接到訂單后，根據(jù)配送方向、時效承諾、訂單類型等因素將訂單生成波次，并按照出庫策略對波次進(jìn)行定位，生成庫房揀貨任務(wù)。在此過程中，若倉庫零散貨位庫存不足而整件貨位庫存充裕，會產(chǎn)生波次補(bǔ)貨。

11.生成批揀單：系統(tǒng)或庫房操作員將定位成功后可以一起揀貨的訂單（如相同物流公司、相同揀貨區(qū)域等）打包生成一張批揀單，在非自動化作業(yè)模式下，一張批揀單中含多少訂單合適？一般按照揀貨員推著揀貨容器一次性能放下的揀貨箱上限即可。例如一個揀貨小車上能放下12個揀貨箱，則可以設(shè)定1張批揀單含12張訂單。

12.訂單打?。捍騿螁T按照批揀單將每張訂單的面單、紙質(zhì)發(fā)票、發(fā)貨清單打印出來并按訂單順序整理存放。

13.揀貨：揀貨員按批揀單領(lǐng)取揀貨任務(wù)（紙單或PDA），并按揀貨路徑完成揀貨任務(wù)（若揀貨區(qū)域過大，可將批揀單再拆分為多個揀貨任務(wù)，按區(qū)域完成揀貨）。若是邊揀邊分模式，揀貨員一邊揀貨一邊將批揀的商品分揀到每個揀貨箱,揀貨完成也分揀完成；若是先揀后分模式，待揀貨員揀貨完成后再集中進(jìn)行集貨分揀。

14.復(fù)核打包：復(fù)核員按照訂單的下單明細(xì)對商品進(jìn)行復(fù)核確認(rèn)，無誤后交由打包員打包并粘貼物流運(yùn)單。

15.訂單發(fā)貨：發(fā)貨員將包裹交由快遞員攬收，并在系統(tǒng)中操作發(fā)貨，代表訂單從庫房發(fā)出。發(fā)貨以后，若實際發(fā)貨物流有變化，回傳實際的物流公司及物流單號至履約系統(tǒng)，履約系統(tǒng)再通過訂單轉(zhuǎn)換中心將物流信息回傳銷售平臺。

若是新零售下的自提業(yè)務(wù)，則由門店店員打包以后，等待客戶上門自提。

16.物流攬件：物流公司快遞員收到包裹后，在系統(tǒng)中操作攬件，攬件操作信息可由配送系統(tǒng)調(diào)用物流公司提供的接口獲取，解析完后回傳訂單系統(tǒng)。

17.物流運(yùn)輸：包裹從物流公司的分揀中心分撥發(fā)出。

18.物流派件：包裹到達(dá)配送站點，派件員按照路線進(jìn)行派件上門。

19.物流簽收：包裹送達(dá)客戶手中，完成簽收。

以上便是一個實物訂單的履約全流向，虛擬訂單因為不涉及到庫房發(fā)貨和物流配送等環(huán)節(jié)，需走另外的系統(tǒng)流程。

03訂單履約過程

訂單履約系統(tǒng)是所有訂單的集散地，統(tǒng)一管理訂單履約的全流程，按照訂單的履約過程，我們可以梳理出整個履約系統(tǒng)的全部狀態(tài)，以及對應(yīng)到用戶側(cè)的顯示狀態(tài)，如圖所示：

▲  訂單履約狀態(tài)說明

在訂單的整個履約過程（全生命周期）中，至少都應(yīng)該包含訂單的接收、審核、攔截、拆分、合并、修改、取消和執(zhí)行8個狀態(tài)節(jié)點。

本文著重討論訂單的取消（退款退貨）、分拆、合并四個環(huán)節(jié)。

01 訂單取消

在電商系統(tǒng)中，取消場景主要有3類：

①、顧客發(fā)起的取消：客戶在用戶端發(fā)起的取消；

②、客服代為取消：客服代替顧客取消訂單，此操作一般在后臺客服系統(tǒng)或者在訂單履約系統(tǒng)中直接操作；

③、系統(tǒng)取消：若客戶下單后超時未支付，或系統(tǒng)判定為惡意訂單，會自動取消訂單。

由于訂單取消會由多個環(huán)節(jié)觸發(fā)，在系統(tǒng)設(shè)計的時候應(yīng)該考慮到通用性，將訂單取消做成一個公共服務(wù)，可供多個系統(tǒng)和場景按需調(diào)用。這也是符合SOA設(shè)計理念。

▲  訂單取消服務(wù)

根據(jù)訂單在取消時可能存在于訂單系統(tǒng)工作流、倉庫作業(yè)、配送等多個環(huán)節(jié)，取消訂單時需根據(jù)訂單所處不同的狀態(tài)執(zhí)行不同的系統(tǒng)處理邏輯：

1.訂單處于預(yù)分倉之前的狀態(tài)：直接取消，更新訂單狀態(tài)為“已取消”，并判斷是否需要退款觸發(fā)退款流程；

2.訂單已分倉，但尚未下發(fā)庫房：取消訂單，并通知中央庫存清除訂單預(yù)占；

3.訂單已下發(fā)庫房，但尚未發(fā)貨：由履約系統(tǒng)對倉儲系統(tǒng)發(fā)起詢問，若倉儲系統(tǒng)未發(fā)貨且攔截訂單成功，履約系統(tǒng)再取消訂單，并通知中央庫存清除訂單預(yù)占；

4.訂單已發(fā)貨但尚未簽收：若是自營配送，或者配送系統(tǒng)已與物流公司接口打通，則發(fā)貨以后仍可以取消訂單，履約系統(tǒng)詢問配送系統(tǒng)，若配送系統(tǒng)攔截包裹成功，則履約系統(tǒng)更新訂單狀態(tài)為“已取消”，此階段無需處理庫存；

5.訂單已簽收：已經(jīng)簽收的訂單，不支持取消，若想將貨退回，只能走售后退貨流程。

02 退貨與退款

訂單的取消，必然帶來后續(xù)的退款退貨作業(yè)，不管該取消的觸發(fā)動作是用戶/客戶直接在線上發(fā)起，還是通過客服從后臺發(fā)起的訂單取消申請。

如果企業(yè)的業(yè)務(wù)還同時存在自營平臺和三方POP商家兩種業(yè)務(wù)模式，以及在線支付和貨到付款兩種支付方式的訂單，其退款退貨的操作會更加復(fù)雜。

整體的業(yè)務(wù)場景藍(lán)圖可以梳理如下：

▲  退貨退款場景羅列

如上圖所示，我們可以根據(jù)退貨退款觸發(fā)的不同時機(jī)，將退貨退款流程分拆為訂單發(fā)貨前、訂單發(fā)貨后、訂單簽收后3大節(jié)點，單獨(dú)設(shè)計系統(tǒng)流程。

1.訂單發(fā)貨前的退貨退款

用戶下單以后，在實物訂單未出庫之前，用戶尚未拿到實物商品，訂單也還處于正向履約流程中，還不涉及到逆向物流場景。在此場景下發(fā)起的退貨退款，在系統(tǒng)層面的操作動作為兩個：取消訂單；退款。

▲  訂單發(fā)貨前的取消及退款流程

根據(jù)訂單所處的履約節(jié)點，系統(tǒng)處理邏輯再細(xì)分為3個子節(jié)點：

（1）訂單未支付：特指貨到付款訂單已提交，和在線支付訂單已提交未付款的場景。此時由于尚未支付，所以只需要取消訂單即可，不涉及退款；

（2）訂單已付款，但尚未下發(fā)庫房/商家：此時訂單還在中臺訂單履約系統(tǒng)中，實物尚在庫房未動。在操作層面需處理兩個動作：

      ①取消訂單；

      ②在線支付的訂單，由系統(tǒng)或者人工生成退款單，審核通過后將訂單實付金額原路退回用戶支付賬戶（貨到付款的訂單未付款，無需退款）。

（3）訂單已下發(fā)庫房：此時訂單已產(chǎn)生波次進(jìn)行發(fā)貨生產(chǎn)了，所以退款之前需確保實物商品尚未真實發(fā)出，將商品還貨上架。

為防止系統(tǒng)信息流轉(zhuǎn)過程中存在滯后性，故在取消訂單前，最好核實一下庫房/商家實物的真實情況。所以，在業(yè)務(wù)操作上需要至少完成三個步驟：

      ①嘗試取消訂單，若商品未發(fā)貨，則可取消成功。否則取消失敗，退款失?。?/p>

      ②庫房將已取消訂單攔截并還貨上架；

      ③在線支付訂單，生成退款單，審核通過后原路退款至用戶支付賬戶。

2.訂單發(fā)貨后的退貨退款

訂單發(fā)貨以后，實物已經(jīng)在運(yùn)輸途中，但用戶尚未簽收，此時，若用戶拒絕簽收，則產(chǎn)生了拒收。貨到付款的訂單，拒收時并未收費(fèi)，也無需退款。

所以，更為準(zhǔn)確的描述是：用戶拒收后的退貨退款

▲  訂單拒收退貨及退款流程

用戶拒收后，業(yè)務(wù)上有兩種做法：

（1）客服核實拒收原因，若用戶還想繼續(xù)要，則聯(lián)系物流公司對包裹進(jìn)行再投，正常簽收訂單。此過程仍為訂單正向流程，未涉及售后流程。

（2）若協(xié)商同意退貨，則由客服發(fā)起一個退貨申請下發(fā)至庫房（自營業(yè)務(wù)）或者商家端（三方POP商家業(yè)務(wù)），等待包裹被物流送回以后，核實確認(rèn)無誤后，將在線支付訂單原路退款，貨到付款訂單因尚未收款，無需退款。

此處需要說明的是，自營平臺訂單，一般在庫房操作WMS系統(tǒng)，退貨入庫狀態(tài)可與上游系統(tǒng)實時互通，故在庫房退貨入庫以后可自動觸發(fā)退款；而商家系統(tǒng)最好由商家明確確認(rèn)收到實物以后（多了一步商家確認(rèn)的動作），再觸發(fā)退款。

平臺退款以后，與商家進(jìn)行結(jié)算訂單應(yīng)收時需排除已退款訂單。

3.訂單簽收后的退貨退款

訂單簽收以后發(fā)起的退款，與簽收前主要有兩點不同：

（1）貨到付款訂單此時已收款，所以涉及到訂單退款； 

（2）簽收前的退貨都是整單維度，簽收后可支持部分退貨。

▲  訂單簽收后的退貨退款流程

訂單一旦被簽收，必須經(jīng)由用戶/客戶或者客服發(fā)起退貨申請，平臺或商家審核退貨申請以后，該流程才正式生效。系統(tǒng)應(yīng)該能夠提醒用戶及時將原貨物原路退回。

而且只有當(dāng)庫房/商家收到用戶/客戶寄回包裹后，系統(tǒng)才能生成退款單，按照約定路徑將貨款退回用戶賬戶。原則上要求按原路返回，但部分為現(xiàn)金支付的貨到付款訂單，或者其它情況，可以協(xié)商其它線上退回路徑。

訂單的取消以及有此引起的退貨退款處理是非常復(fù)雜的業(yè)務(wù)，一般而言，一張訂單可能會產(chǎn)生多次退貨，每次退貨會生成一張退貨單。同時，一張訂單也有可能觸發(fā)多次退款。所以，在退貨單、退款單的設(shè)計上務(wù)必保持清醒，將退貨單、退款單與訂單庫彼此獨(dú)立又相輔相成是一種更為合理的設(shè)計。

▲  訂單、退貨單與退款單

實際業(yè)務(wù)中，并不是每一張退貨單都會生成退款單，更不是每一張退款單都會有退貨單。

例如貨到付款的訂單退貨，就只會有退貨單，不需要退款單；有些情況下，客服會針對某些訂單只為客戶退款，而無需退貨，例如承諾超時賠付等。

所以，退貨單和退款單只有在常規(guī)退貨退款場景下才是一對一的關(guān)系，在特定的場景下并不具備強(qiáng)關(guān)聯(lián)關(guān)系。

在系統(tǒng)上，退貨單的操作也必定具備待審核、待入庫、入庫完成、駁回 4個狀態(tài)：

①待審核：在訂單逆向過程中，客戶或客服新發(fā)起退貨申請，系統(tǒng)生成退貨單的初始狀態(tài)；

②待入庫：退貨單審核通過，同意退貨的狀態(tài)。此時，等待客戶包裹寄回；

③入庫完成：包裹寄回倉庫，庫房已完成入庫；

④駁回：退貨申請被駁回的狀態(tài)。

▲  退貨單狀態(tài)圖

同樣的邏輯，按照退款節(jié)點，退款單的狀態(tài)設(shè)計也有待審核、待退款、退款完成、駁回 4個操作狀態(tài)：

①待審核：退款申請剛提交的初始狀態(tài)；

②待退款：退款單由財務(wù)審核通過，同意退款；

③退款完成：由財務(wù)手工或系統(tǒng)自動觸發(fā)退款，退款成功后的狀態(tài)；

④駁回：退款申請被駁回的狀態(tài)。

▲  退款單狀態(tài)圖

與退貨相比，更復(fù)雜的業(yè)務(wù)是退款，它涉及一系列的負(fù)責(zé)計算規(guī)則，至少需要考慮三種業(yè)務(wù)場景：

1、訂單簽收前的取消和拒收引起的退款，都是整單退貨（全退）；

2、簽收以后的退貨，經(jīng)常由于部分商品問題，所以會存在部分退貨（半退）；

3、如果在訂單下單時使用了優(yōu)惠券、抵扣金、積分等，也需要考慮退回用戶賬戶。

全退情況的退款處理比較簡單，①可按訂單實付總金額退款；②未過期的優(yōu)惠券、積分等優(yōu)惠信息原路返回。

而半退情況下的退款處理相對復(fù)雜：

     ①若無組合優(yōu)惠信息，按商品實付金額退款；

     ②若使用了組合優(yōu)惠信息（如整單滿減券），有兩種主流處理方式：

        a.優(yōu)惠按照商品金額比例分?jǐn)?，按照分?jǐn)偤蟮膶嵏督痤~退款；

        b.退款時需考慮剩余商品是否滿足優(yōu)惠，重算優(yōu)惠后退款。

為加強(qiáng)理解，舉例說明：

a.優(yōu)惠按照商品金額比例分?jǐn)?，按照分?jǐn)偤蟮膶嵏督痤~退款。(參考：淘寶)

假設(shè)某用戶購買商品A\B\C各1個，使用了滿150減20的優(yōu)惠券，按比例分?jǐn)偤蟮膶嵏督痤~如下:

如上，若退A，則退款90元；退B，則退款54元；退C，則退款46元。

此規(guī)則簡單易實現(xiàn)，但存在湊單刷優(yōu)惠券的風(fēng)險。存在用戶為了湊單使用優(yōu)惠券，簽收后又將其它不需要的SKU退貨的情況。一般規(guī)避方案為：①用戶責(zé)任導(dǎo)致的退貨運(yùn)費(fèi)由用戶承擔(dān)；②惡意刷優(yōu)惠券退貨的行為，將用戶做降級處理、或加入黑名單。

b.退款時重新計算優(yōu)惠，若剩余SKU繼續(xù)滿足優(yōu)惠，則按原價退款；否則扣除優(yōu)惠后再退款，若扣退款金額尚不夠優(yōu)惠，則不能單獨(dú)退此商品。參考：京東

假設(shè)某用戶購買商品A\B\C各1個，使用了滿150減20的優(yōu)惠券，實付金額如下：

①若退C，則剩余A和B，原金額合計160，仍然滿足優(yōu)惠條件，故退款40元；

②若退B，則剩余A和C，原金額合計140，不再滿足優(yōu)惠條件，需扣除優(yōu)惠，故退款金額=60–20=40元。

如某用戶購買商品A\B各1個，使用了滿100減50的優(yōu)惠券，實付金額如下：

①若退A，剩余B（原金額為40），不再滿足優(yōu)惠條件，需扣除優(yōu)惠，可退款金額=60-50=10元

②若退B，則剩余A（原金額為60），不再滿足優(yōu)惠條件，需扣除優(yōu)惠，但因B的原金額（40）小于已優(yōu)惠金額（50），故不允許單獨(dú)退B。

此規(guī)則可預(yù)防刷優(yōu)惠券的情況，但規(guī)則較復(fù)雜，解釋成本和系統(tǒng)實現(xiàn)成本較大。

03 訂單拆分

訂單拆分是將一張訂單拆分為多張子單獨(dú)立發(fā)貨的過程。訂單履約過程中非常核心的一個環(huán)節(jié)，和訂單取消一樣，訂單拆分會出現(xiàn)在訂單履約的多個環(huán)節(jié)中，可以是系統(tǒng)自動拆單，也可以是人工拆單。所以訂單拆分也應(yīng)該設(shè)計為一個公共服務(wù)。

常見的拆分業(yè)務(wù)如下：

▲ 訂單拆分服務(wù)

拆分以后，父單作廢，子單繼續(xù)完成履約過程。但在前臺和履約系統(tǒng)中需要有很明晰的父單和子單的對應(yīng)關(guān)系。拆分過程中，對訂單的處理邏輯如下：

1.基本信息（下單人、收貨人、渠道等公共信息）：將父單信息復(fù)制到子單 。

2.財務(wù)信息： 訂單應(yīng)付總金額/已支付金額/發(fā)票金額/物流運(yùn)費(fèi)=按照各子訂單的商品總價比例進(jìn)行分?jǐn)?，最后一個訂單金額為剩余未分配金額。建議保留2位小數(shù)。

3.商品信息：按照需要拆分的sku或者數(shù)量進(jìn)行拆分，保證所有子單的sku及數(shù)量之和與父單一致。

4.促銷信息：針對整單的促銷（例如整單優(yōu)惠、滿減、平臺優(yōu)惠券、積分抵扣等），拆分時按照訂單中sku金額比例分?jǐn)?；若是針對單sku的促銷，拆分時僅考慮參與促銷的單sku維度，其它sku 不參與促銷分?jǐn)偂?/p>

04 訂單合并

將相同客戶的多張訂單合并一起發(fā)貨，有諸多好處，于客戶而言，多張訂單一起送貨，只需要簽收一次包裹；于公司而言，可以節(jié)省庫房的作業(yè)成本和配送的物流成本。所以訂單履約系統(tǒng)中增加訂單合并功能是很有必要的。

履約系統(tǒng)設(shè)計時可以設(shè)置訂單集中等待10到15min，在此等待時間內(nèi)進(jìn)入履約系統(tǒng)的訂單，若符合合并條件，可自動進(jìn)行合并；超過等待時期進(jìn)入系統(tǒng)的訂單，可由客服手工合并。

訂單合并條件：同銷售平臺、同下單會員賬號、同收貨地址、同收貨人、同手機(jī)號、同支付方式（在線支付/貨到付款/到店支付）、同出庫倉庫、同訂單類型（如普通訂單、預(yù)售訂單）、同客戶備注（客戶備注一樣or無備注）、同開發(fā)票方式（都開發(fā)票，且抬頭信息一樣；或者都不開發(fā)票）、同配送方式（自提/配送）

合并以后，各原單作廢，合并后生成一張新單繼續(xù)完成后續(xù)履約過程，但要求在銷售平臺上客戶仍看到的是多張訂單，僅發(fā)貨時的物流公司和物流單號都是一樣的。

合并訂單的處理邏輯如下：

    1.基本信息（下單人、收貨人、渠道等信息）：取任意一張子單（因為信息都一樣）

    2.財務(wù)及發(fā)票信息：訂單應(yīng)付總金額/已支付金額/發(fā)票金額/物流運(yùn)費(fèi)=各子單金額相加

    3.商品信息：所有需要合并的子單SKU及數(shù)量進(jìn)行匯總

    4.促銷信息：將所有子單促銷明細(xì)集中至父單中