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

　　小Q：某醫藥互聯網公司后臺產品經理，著手規劃重構公司的供應鏈及電商后臺相關系統。

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

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

　　01

　　訂單履約系統架構及核心功能

　　此番來北京出差的任務是給技術GG們講解訂單履約系統需求。

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

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

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

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

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

　　“結合這些現狀，我給大家講解一下訂單履約系統的設計架構”，小Q打開了先行寫好的prd。

　　▲ 訂單履約系統架構設計圖

　　“從訂單數據上下傳通道來看，整個訂單履約從上往下涉及3層系統：訂單轉換中心、訂單履約中心、倉儲路由中心。

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

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

　　訂單履約系統負責處理訂單履約的全過程，對上通過訂單轉換中心與銷售平臺進行信息同步，對下通過倉儲路由中心將訂單信息上下傳，內部通過調度中央庫存、配送系統等多個外圍系統對訂單信息進行層層拆解和組裝，將訂單加工為滿足履約條件的可執行指令。

　　根據以上架構，梳理出訂單履約系統的核心功能如下：

　　▲ 訂單履約系統核心功能”

　　02

　　訂單履約全流程詳解

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

　　▲ 實物訂單履約全流程

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

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

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

　　4.訂單攔截處理：某些不符合業務規則的訂單，如疑似惡意訂單，在訂單系統中打上攔截標記，待人工審核通過后才能繼續放行。若明確為惡意訂單，則將訂單取消。

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

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

　　5.合并訂單處理：為降低運費成本和庫房作業成本，在一定時段內，滿足合并條件的訂單，在訂單系統中合并為一單下發庫房/門店發貨。

　　6.訂單審核：某些業務規則下，會要求訂單在人工審核處理后方能繼續流轉，例如被攔截的訂單、客戶有特殊需求的訂單等。為提升履約效率，其它訂單可自動審核而無需人工一一處理。當然此審核功能可以直接放在履約系統中供客服使用，也可以提供服務供客服系統調用。

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

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

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

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

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

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

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

　　14.復核打包：復核員按照訂單的下單明細對商品進行復核確認，無誤后交由打包員打包并粘貼物流運單。

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

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

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

　　17.物流運輸：包裹從物流公司的分揀中心分撥發出。

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

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

　　以上便是一個實物訂單的履約全流向，虛擬訂單因為不涉及到庫房發貨和物流配送等環節，需走另外的系統流程。”

　　03

　　訂單屬性

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

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

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

　　3.收貨信息：收貨人、收貨人手機電話、收貨人省份、收貨人市、收貨人區縣、收貨人鄉鎮、收貨人詳細地址。

　　4.發票信息：開發票的訂單，應包含發票抬頭和發票明細信息：

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

　　發票明細信息：明細類目明細、包裝規格、包裝單位、數量、含稅單價、含稅金額、稅率。

　　5.促銷信息：促銷類型(優惠券、積分、滿減等)、促銷ID、金額。

　　6.物流信息：發貨庫房、系統指派物流公司、系統指派電子面單號、實際發貨物流公司、實際發貨物流單號、物流公司月結賬號、大頭筆信息。

　　7.商品明細信息：sku編碼、sku名稱、商品規格、銷售單價、實付單價(各種優惠折扣計算完以后的單價)、數量、實付金額(實付單價*數量)。

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

　　04

　　訂單履約系統狀態

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

　　▲ 訂單履約狀態說明

　　05

　　訂單取消

　　“在電商系統中，取消場景主要有3類：

　　①、顧客發起的取消：客戶在用戶端發起的取消。

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

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

　　由于訂單取消會由多個環節觸發，在系統設計的時候應該考慮到通用性，將訂單取消做成一個公共服務，可供多個系統和場景按需調用。這也是符合SOA設計理念。”

　　▲ 訂單取消服務

　　“根據訂單在取消時可能存在于訂單系統工作流、倉庫作業、配送等多個環節，取消訂單時需根據訂單所處不同的狀態執行不同的系統處理邏輯：

　　1.訂單處于預分倉之前的狀態：直接取消，更新訂單狀態為“已取消”，并判斷是否需要退款觸發退款流程。

　　2.訂單已分倉，但尚未下發庫房：取消訂單，并通知中央庫存清除訂單預占。

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

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

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

　　06

　　訂單拆分

　　“訂單拆分是將一張訂單拆分為多張子單獨立發貨的過程。訂單履約過程中非常核心的一個環節，和訂單取消一樣，訂單拆分會出現在訂單履約的多個環節中，可以是系統自動拆單，也可以是人工拆單。所以訂單拆分也應該設計為一個公共服務。常見的拆分業務如下：

　　▲ 訂單拆分服務

　　拆分以后，父單作廢，子單繼續完成履約過程。但在前臺和履約系統中需要有很明晰的父單和子單的對應關系。拆分過程中，對訂單的處理邏輯如下：

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

　　2.財務信息：訂單應付總金額/已支付金額/發票金額/物流運費=按照各子訂單的商品總價比例進行分攤，最后一個訂單金額為剩余未分配金額。建議保留2位小數。

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

　　4.促銷信息：針對整單的促銷(例如整單優惠、滿減、平臺優惠券、積分抵扣等)，拆分時按照訂單中sku金額比例分攤;若是針對單sku的促銷，拆分時僅考慮參與促銷的單sku維度，其它sku 不參與促銷分攤。”

　　07

　　訂單合并

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

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

　　▲ 訂單ABC合并為D

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

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

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

　　2.財務及發票信息：訂單應付總金額/已支付金額/發票金額/物流運費=各子單金額相加。

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

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

　　08

　　訂單反審核

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

　　反審核的系統處理邏輯為：

　　①將原訂單做取消處理。

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

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

　　09

　　訂單暫停與加急

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

　　▲ 訂單暫停邏輯

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

　　▲ 訂單加急邏輯

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

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

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

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

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