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

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

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

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

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

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

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

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

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

03 訂單屬性

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

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

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

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

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

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

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

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

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

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

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

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

    “訂單履約系統(tǒng)應該是所有訂單的集散地，統(tǒng)一管理訂單履約的全流程，按照訂單的履約過程，我們梳理了履約系統(tǒng)的全部狀態(tài)，以及對應到用戶側(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)設計的時候應該考慮到通用性，將訂單取消做成一個公共服務，可供多個系統(tǒng)和場景按需調(diào)用。這也是符合SOA設計理念?！?/p>

▲  訂單取消服務

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

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

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

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

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

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

06 訂單拆分

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

▲ 訂單拆分服務

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

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

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

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

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

07 訂單合并

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

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

▲ 訂單ABC合并為D

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

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

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

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

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

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

08 訂單反審核

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

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

    ①將原訂單做取消處理；

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

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

09 訂單暫停與加急

    “在某些業(yè)務場景下，需要臨時將正在履約過程中的訂單暫停處理，一般由客服發(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分鐘路程，好像走了半個世紀，看著形形色色的上班一族在寒潮和霧霾中穿梭，每個人都包裹的嚴嚴實實，棉衣棉帽棉口罩是標配，只留一副凝重的眼神與寒風對峙，像懷揣著救世使命一般神秘。不遠處一位很時尚的女孩兒因為趕路太匆忙被路旁的共享單車絆倒，剛買的熱包子和紅豆粥灑落一地，白色的羽絨服被污染了一大片，女孩趴在地上30秒后，紅著雙眼慢慢爬起來，掏出包里的紙巾將自己臉上和身上收拾干凈，又禮貌的將掉在地上的包子拾起來丟進了旁邊的垃圾桶，然后滿臉淚痕又故作堅強的前行。小Q望著女孩不停抬手擦拭眼淚的背影，陷入了沉思….

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

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