中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

很多公司，除了自營商城以外，還有其它渠道（如天貓、京東等），多個渠道的訂單該如何集中履約？訂單履約全流程是怎樣的？接著小Q的故事，為您揭曉多平臺訂單履約系統(tǒng)的系統(tǒng)設計思路。

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

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

三九酷寒，一夜北風吹，朋友圈里全國各地網(wǎng)友都在喜迎2019年的首場瑞雪，期待來年有個好盼頭，唯獨帝都上空一片寂寥。

寒風肆虐外加霧霾橫行，空氣充斥著流感的囂張氣焰，氣溫比昨日越發(fā)陰冷，能見度也低了不少。北風嗚嗚的壓面掃過，從發(fā)絲到脖子，凡是暴露在外的肢體部分都如同冰刀刮體，凍的生疼。嘴里哈出的白氣像一把反擊的利劍，在空中凝固，隨之慢慢消散淪為霧霾的奴役。鼻腔里充斥著塵霾的焦味，隨便嚼一口都能感覺到牙縫里的沙子滋滋作響。

雖然穿著羽絨服，仍然能感受到寒氣由外向內(nèi)節(jié)節(jié)滲透，要不是有棉帽和鴨絨護身，?作為南方人的小Q與這般惡劣的天氣根本斗不過10分鐘。

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

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

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

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

“咱們有兩大類業(yè)務：三方電商平臺和自營平臺；三方平臺是咱們在天貓、京東等平臺上開的電商店鋪，自有平臺是咱們自行搭建的商城，和一些對外的sdk、API等渠道；咱們下游有多個倉庫，遍布全國各地，各地配送區(qū)域不同；自營平臺上，咱們還有一些新零售業(yè)務，支持用戶到店自提，以及急速送達的配送業(yè)務?！?/p>

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

▲? 訂單履約系統(tǒng)架構設計圖

以下為小Q分享內(nèi)容：

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

訂單履約系統(tǒng)的上游是訂單轉換中心，用以對接各個銷售平臺。因為各平臺的訂單結構不盡相同，為了能統(tǒng)一在履約系統(tǒng)中對訂單進行管理，保證訂單內(nèi)部流轉的標準化，不至于因為某個平臺的調(diào)整而動了主體結構，所以在訂單轉換中心中針對各個平臺配置不同的適配器，將訂單標準化以后再與履約系統(tǒng)進行通訊。

需要適配的信息包括商品、地址、訂單狀態(tài)、物流公司等。

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

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

02 訂單履約全流程詳解

從系統(tǒng)層面看，一張實物類的訂單從銷售平臺下單，到最終用戶簽收，會經(jīng)歷10余個履約節(jié)點，涉及銷售平臺、訂單轉換中心、履約系統(tǒng)、中央庫存、配送系統(tǒng)、倉儲路由中心、倉庫/新零售系統(tǒng)等多個系統(tǒng)。

所以，履約流程最核心的訴求是協(xié)同和順暢，只有各系統(tǒng)相互協(xié)作，訂單自始至終很流暢的執(zhí)行完各個節(jié)點，才能保證在約定時效內(nèi)完成履約。其中任何一個節(jié)點出現(xiàn)卡殼，都會導致履約時效拉長，影響的是客戶對平臺的信任。

▲? 實物訂單履約全流程

1. 新訂單

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

2. 訂單拆分

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

3. 訂單預分倉

為防止超賣，已經(jīng)下單的訂單需盡快進行庫存預占，以免庫存被其它訂單占用，分倉過程由中央庫存提供服務。

訂單預分倉可以提前鎖定訂單發(fā)貨倉庫，若訂單核心信息發(fā)生變化，再重新分倉。若業(yè)務上允許一個訂單被拆分為多個庫房發(fā)貨，訂單需再次拆分。

需要注意的是：只有實物庫存滿足的訂單才能預分倉成功，預售類的訂單，可在訂單拆分后進行截停等待，待真實庫存采購入庫以后再進行分倉流轉。

4. 訂單攔截處理

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

（訂單攔截規(guī)則因為行業(yè)、公司、業(yè)務不同，要根據(jù)實際業(yè)務情況進行梳理，不在這里詳述。另外，到底是先分倉預占，還是先攔截訂單？木筆認為應該先進行分倉，雖然惡意訂單可能會占用部分庫存，但處理完以后，訂單會被取消釋放庫存。此種處理方式好過一些疑似但不是惡意的訂單因為被攔截了而沒有分倉，導致后續(xù)庫存被其它訂單占用而引起超賣的情況。）

5. 合并訂單處理

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

6. 訂單審核

某些業(yè)務規(guī)則下，會要求訂單在人工審核處理后方能繼續(xù)流轉，例如：被攔截的訂單、客戶有特殊需求的訂單等。

為提升履約效率，其它訂單可自動審核而無需人工一一處理。當然此審核功能可以直接放在履約系統(tǒng)中供客服使用，也可以提供服務供客服系統(tǒng)調(diào)用。

7. 訂單重新分倉

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

8. 訂單分物流

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

9. 下發(fā)庫房

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

10. 波次下發(fā)

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

11. 生成批揀單

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

12. 訂單打印

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

13. 揀貨

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

14. 復核打包

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

15. 訂單發(fā)貨

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

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

16. 物流攬件

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

17. 物流運輸

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

18. 物流派件

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

19. 物流簽收

包裹送達客戶手中，完成簽收。

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

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

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

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

04 訂單取消

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

1. 顧客發(fā)起的取消：客戶在用戶端發(fā)起的取消；
2. 客服代為取消：客服代替顧客取消訂單，此操作一般在后臺客服系統(tǒng)或者在訂單履約系統(tǒng)中直接操作；
3. 系統(tǒng)取消：若客戶下單后超時未支付，或系統(tǒng)判定為惡意訂單，會自動取消訂單。

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

▲? 訂單取消服務

根據(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)簽收的訂單，不支持取消，若想將貨退回，只能走售后退貨流程。

05 訂單拆分

訂單拆分是將一張訂單拆分為多張子單獨立發(fā)貨的過程。訂單履約過程中非常核心的一個環(huán)節(jié)，和訂單取消一樣，訂單拆分會出現(xiàn)在訂單履約的多個環(huán)節(jié)中，可以是系統(tǒng)自動拆單，也可以是人工拆單。

所以，訂單拆分也應該設計為一個公共服務。

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

▲?訂單拆分服務

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

拆分過程中，對訂單的處理邏輯如下：

• 基本信息（下單人、收貨人、渠道等公共信息）：將父單信息復制到子單 。
• 財務信息：?訂單應付總金額/已支付金額/發(fā)票金額/物流運費=按照各子訂單的商品總價比例進行分攤，最后一個訂單金額為剩余未分配金額。建議保留2位小數(shù)。
• 商品信息：按照需要拆分的sku或者數(shù)量進行拆分，保證所有子單的sku及數(shù)量之和與父單一致。
• 促銷信息：針對整單的促銷（例如整單優(yōu)惠、滿減、平臺優(yōu)惠券、積分抵扣等），拆分時按照訂單中sku金額比例分攤；若是針對單sku的促銷，拆分時僅考慮參與促銷的單sku維度，其它sku 不參與促銷分攤。”

06 訂單合并

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

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

▲?訂單ABC合并為D

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

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

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

• 基本信息（下單人、收貨人、渠道等信息）：取任意一張子單（因為信息都一樣）。
• 財務及發(fā)票信息：訂單應付總金額/已支付金額/發(fā)票金額/物流運費=各子單金額相加。
• 商品信息：所有需要合并的子單SKU及數(shù)量進行匯總。
• 促銷信息：將所有子單促銷明細集中至父單中?。

07 訂單反審核

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

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

1. 將原訂單做取消處理；
2. 根據(jù)要求修改后生成一張新訂單重新下發(fā)完成履約流程。

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

此次來北京出差，小Q從酒店出發(fā)步行到辦公室，區(qū)區(qū)10分鐘路程，好像走了半個世紀?？粗涡紊纳习嘁蛔逶诤焙挽F霾中穿梭，每個人都包裹的嚴嚴實實，棉衣棉帽棉口罩是標配，只留一副凝重的眼神與寒風對峙，像懷揣著救世使命一般神秘。

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

小Q望著女孩不停抬手擦拭眼淚的背影，陷入了沉思….

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

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

由于篇幅關系，內(nèi)容略有精簡，若需了解全部內(nèi)容，可前往公眾號查看原文。若對供應鏈全流程或者小Q的故事感興趣，可參考前序文章：

1. 《產(chǎn)品經(jīng)理眼中的供應鏈流程及產(chǎn)品設計》
2. 《電商新零售核心系統(tǒng)從0到1規(guī)劃之路》
3. 《電商新零售系統(tǒng)劃分及供應鏈系統(tǒng)流程詳解》

作者：木筆，產(chǎn)品一俗生，深耕于供應鏈領域，公眾號：供應鏈產(chǎn)品筆記

本文由 @木筆 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉載

題圖來自Unsplash，基于CC0協(xié)議。