很多公司，除了自營(yíng)商城以外，還有其它渠道（如天貓、京東等），多個(gè)渠道的訂單該如何集中履約？訂單履約全流程是怎樣的？接著小Q的故事，為您揭曉多平臺(tái)訂單履約系統(tǒng)的系統(tǒng)設(shè)計(jì)思路。 由于篇幅關(guān)系，本文僅介紹正向履約流程，逆向流程放置后續(xù)文章中更新~

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

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

    三九酷寒，一夜北風(fēng)吹，朋友圈里全國(guó)各地網(wǎng)友都在喜迎2019年的首場(chǎng)瑞雪，期待來(lái)年有個(gè)好盼頭，唯獨(dú)帝都上空一片寂寥，寒風(fēng)肆虐外加霧霾橫行，空氣充斥著流感的囂張氣焰，氣溫比昨日越發(fā)陰冷，能見(jiàn)度也低了不少。北風(fēng)嗚嗚的壓面掃過(guò)，從發(fā)絲到脖子，凡是暴露在外的肢體部分都如同冰刀刮體，凍的生疼；嘴里哈出的白氣像一把反擊的利劍，在空中凝固，隨之慢慢消散淪為霧霾的奴役；鼻腔里充斥著塵霾的焦味，隨便嚼一口都能感覺(jué)到牙縫里的沙子滋滋作響。雖然穿著羽絨服，仍然能感受到寒氣由外向內(nèi)節(jié)節(jié)滲透，要不是有棉帽和鴨絨護(hù)身， 作為南方人的小Q與這般惡劣的天氣根本斗不過(guò)10分鐘。

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

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

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

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

    “①咱們有兩大類業(yè)務(wù)：三方電商平臺(tái)和自營(yíng)平臺(tái)；三方平臺(tái)是咱們?cè)谔熵?、京東等平臺(tái)上開(kāi)的電商店鋪，自有平臺(tái)是咱們自行搭建的商城，和一些對(duì)外的sdk、API等渠道；

      ②咱們下游有多個(gè)倉(cāng)庫(kù)，遍布全國(guó)各地，各地配送區(qū)域不同；

      ③自營(yíng)平臺(tái)上，咱們還有一些新零售業(yè)務(wù)，支持用戶到店自提，以及急速送達(dá)的配送業(yè)務(wù)?！?/span>

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

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

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

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

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

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

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

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

02 訂單履約全流程詳解

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

▲  實(shí)物訂單履約全流程

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

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

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

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

 （訂單攔截規(guī)則因?yàn)樾袠I(yè)、公司、業(yè)務(wù)不同，要根據(jù)實(shí)際業(yè)務(wù)情況進(jìn)行梳理，不在這里詳述。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   以上便是一個(gè)實(shí)物訂單的履約全流向，虛擬訂單因?yàn)椴簧婕暗綆?kù)房發(fā)貨和物流配送等環(huán)節(jié)，需走另外的系統(tǒng)流程?！?/span>

03 訂單屬性

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

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

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

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

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

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

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

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

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

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

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

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

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

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

05 訂單取消

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

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

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

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

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

▲  訂單取消服務(wù)

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

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

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

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

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

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

06 訂單拆分

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

▲ 訂單拆分服務(wù)

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

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

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

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

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

07 訂單合并

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

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

▲ 訂單ABC合并為D

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

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

    1.基本信息（下單人、收貨人、渠道等信息）：取任意一張子單（因?yàn)樾畔⒍家粯樱?/span>

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

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

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

08 訂單反審核

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

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

    ①將原訂單做取消處理；

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

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

09 訂單暫停與加急

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

▲ 訂單暫停邏輯

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

▲ 訂單加急邏輯

    以上暫停和加急功能主要供客服內(nèi)部使用，無(wú)需對(duì)客戶開(kāi)放?！?/span>

   此次來(lái)北京出差，小Q從酒店出發(fā)步行到辦公室，區(qū)區(qū)10分鐘路程，好像走了半個(gè)世紀(jì)，看著形形色色的上班一族在寒潮和霧霾中穿梭，每個(gè)人都包裹的嚴(yán)嚴(yán)實(shí)實(shí)，棉衣棉帽棉口罩是標(biāo)配，只留一副凝重的眼神與寒風(fēng)對(duì)峙，像懷揣著救世使命一般神秘。不遠(yuǎn)處一位很時(shí)尚的女孩兒因?yàn)橼s路太匆忙被路旁的共享單車絆倒，剛買的熱包子和紅豆粥灑落一地，白色的羽絨服被污染了一大片，女孩趴在地上30秒后，紅著雙眼慢慢爬起來(lái)，掏出包里的紙巾將自己臉上和身上收拾干凈，又禮貌的將掉在地上的包子拾起來(lái)丟進(jìn)了旁邊的垃圾桶，然后滿臉淚痕又故作堅(jiān)強(qiáng)的前行。小Q望著女孩不停抬手擦拭眼淚的背影，陷入了沉思….

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

    尼采說(shuō)：凡不能毀滅我的，必使我強(qiáng)大！