以下故事情節(jié)及人物均為作者杜撰，若有雷同，純屬巧合：

　　小Q：某醫(yī)藥互聯(lián)網(wǎng)公司后臺產(chǎn)品經(jīng)理，著手規(guī)劃重構(gòu)公司的供應(yīng)鏈及電商后臺相關(guān)系統(tǒng)。

　　三九酷寒，一夜北風(fēng)吹，朋友圈里全國各地網(wǎng)友都在喜迎2019年的首場瑞雪，期待來年有個好盼頭，唯獨帝都上空一片寂寥，寒風(fēng)肆虐外加霧霾橫行，空氣充斥著流感的囂張氣焰，氣溫比昨日越發(fā)陰冷，能見度也低了不少。

　　北風(fēng)嗚嗚的壓面掃過，從發(fā)絲到脖子，凡是暴露在外的肢體部分都如同冰刀刮體，凍的生疼;嘴里哈出的白氣像一把反擊的利劍，在空中凝固，隨之慢慢消散淪為霧霾的奴役;鼻腔里充斥著塵霾的焦味，隨便嚼一口都能感覺到牙縫里的沙子滋滋作響。雖然穿著羽絨服，仍然能感受到寒氣由外向內(nèi)節(jié)節(jié)滲透，要不是有棉帽和鴨絨護身， 作為南方人的小Q與這般惡劣的天氣根本斗不過10分鐘。

　　01

　　訂單履約系統(tǒng)架構(gòu)及核心功能

　　此番來北京出差的任務(wù)是給技術(shù)GG們講解訂單履約系統(tǒng)需求。

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

　　“在正式講解需求之前，咱們先來了解一下公司的業(yè)務(wù)現(xiàn)狀，”，小Q覺得即便是程序員，也非常有必要先了解一下業(yè)務(wù)背景，以需求為出發(fā)點，才能設(shè)計出更貼合業(yè)務(wù)的系統(tǒng)，而且也會更加有參與感。

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

　　②咱們下游有多個倉庫，遍布全國各地，各地配送區(qū)域不同;

　　③自營平臺上，咱們還有一些新零售業(yè)務(wù)，支持用戶到店自提，以及急速送達的配送業(yè)務(wù)。”

　　“結(jié)合這些現(xiàn)狀，我給大家講解一下訂單履約系統(tǒng)的設(shè)計架構(gòu)”，小Q打開了先行寫好的prd。

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

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

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

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

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

　　根據(jù)以上架構(gòu)，梳理出訂單履約系統(tǒng)的核心功能如下：

　　▲ 訂單履約系統(tǒng)核心功能”

　　02

　　訂單履約全流程詳解

　　“從系統(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ī)則進行訂單拆分，分為多個子訂單發(fā)貨。

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

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

　　(訂單攔截規(guī)則因為行業(yè)、公司、業(yè)務(wù)不同，要根據(jù)實際業(yè)務(wù)情況進行梳理，不在這里詳述。

　　另外，到底是先分倉預(yù)占，還是先攔截訂單?木筆認(rèn)為應(yīng)該先進行分倉，雖然惡意訂單可能會占用部分庫存，但處理完以后，訂單會被取消釋放庫存，此種處理方式好過一些疑似但不是惡意的訂單因為被攔截了而沒有分倉，導(dǎo)致后續(xù)庫存被其它訂單占用而引起超賣的情況。)

　　5.合并訂單處理：為降低運費成本和庫房作業(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é)果，需要重新進行分倉預(yù)占，并清除原預(yù)分倉結(jié)果。

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

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

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

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

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

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

　　14.復(fù)核打包：復(fù)核員按照訂單的下單明細(xì)對商品進行復(fù)核確認(rè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.物流運輸：包裹從物流公司的分揀中心分撥發(fā)出。

　　18.物流派件：包裹到達配送站點，派件員按照路線進行派件上門。

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

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

　　03

　　訂單屬性

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

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

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

　　3.收貨信息：收貨人、收貨人手機電話、收貨人省份、收貨人市、收貨人區(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)容 ”

　　04

　　訂單履約系統(tǒng)狀態(tài)

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

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

　　05

　　訂單取消

　　“在電商系統(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)簽收的訂單，不支持取消，若想將貨退回，只能走售后退貨流程。”

　　06

　　訂單拆分

　　“訂單拆分是將一張訂單拆分為多張子單獨立發(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ā)票金額/物流運費=按照各子訂單的商品總價比例進行分?jǐn)偅詈笠粋€訂單金額為剩余未分配金額。建議保留2位小數(shù)。

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

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

　　07

　　訂單合并

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

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

　　▲ 訂單ABC合并為D

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

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

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

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

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

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

　　08

　　訂單反審核

　　“在訂單履約過程中，已經(jīng)審核過的訂單，常常會被要求修改信息(例如客戶要求修改地址、庫房要求拆包裹發(fā)貨等)，客服需要將訂單拉回至審核之前的狀態(tài)，然后修改之后重新審核下發(fā)，此動作即為反審核。

　　反審核的系統(tǒng)處理邏輯為：

　　①將原訂單做取消處理。

　　②根據(jù)要求修改后生成一張新訂單重新下發(fā)完成履約流程。

　　新訂單是否需要生成新的單號? 取決于下游的倉庫/門店系統(tǒng)是否兼容多個相同的訂單號。若兼容，則無需更改單號，若不支持，則生成一個新訂單號。訂單在未下發(fā)倉庫系統(tǒng)之前，原則上無需重新生成單號，系統(tǒng)記錄一條反審日志即可。”

　　09

　　訂單暫停與加急

　　“在某些業(yè)務(wù)場景下，需要臨時將正在履約過程中的訂單暫停處理，一般由客服發(fā)起，若訂單在庫房發(fā)貨之前，可暫停成功，將訂單攔截在倉庫里，等待客服下一步操作(取消暫停/取消訂單/反審核等)，暫停的系統(tǒng)流程如圖所示：

　　▲ 訂單暫停邏輯

　　與暫停功能類似，某些訂單需要臨時提升出庫優(yōu)先級，加急出庫，故訂單履約系統(tǒng)需提供加急功能供客服使用，一旦訂單被加急，庫房在出庫作業(yè)環(huán)節(jié)中均優(yōu)先處理。優(yōu)先級越高，出庫越靠前。加急的系統(tǒng)流程如下：

　　▲ 訂單加急邏輯

　　以上暫停和加急功能主要供客服內(nèi)部使用，無需對客戶開放。”

　　此次來北京出差，小Q從酒店出發(fā)步行到辦公室，區(qū)區(qū)10分鐘路程，好像走了半個世紀(jì)，看著形形色色的上班一族在寒潮和霧霾中穿梭，每個人都包裹的嚴(yán)嚴(yán)實實，棉衣棉帽棉口罩是標(biāo)配，只留一副凝重的眼神與寒風(fēng)對峙，像懷揣著救世使命一般神秘。

　　不遠(yuǎn)處一位很時尚的女孩兒因為趕路太匆忙被路旁的共享單車絆倒，剛買的熱包子和紅豆粥灑落一地，白色的羽絨服被污染了一大片，女孩趴在地上30秒后，紅著雙眼慢慢爬起來，掏出包里的紙巾將自己臉上和身上收拾干凈，又禮貌的將掉在地上的包子拾起來丟進了旁邊的垃圾桶，然后滿臉淚痕又故作堅強的前行。小Q望著女孩不停抬手擦拭眼淚的背影，陷入了沉思….

　　眾生皆苦，萬般無奈。所有的美妙光鮮背后，都有著不為人知的難言苦楚。不過因果交加，如果不是一次次的艱難困苦，人生又當(dāng)如何進階?眼前的坎，掉下去了叫入坑，自己爬起來抹平了，就變成了自己的路。要相信所有讓我們變好的選擇，過程都不會很舒服。

　　尼采說：凡不能毀滅我的，必使我強大!