編輯導(dǎo)語：OMS（訂單管理系統(tǒng)）一般指訂單管理系統(tǒng)：接受客戶訂單信息，以及倉儲管理系統(tǒng)發(fā)來的庫存信息，然后按客戶和緊要程度給訂單歸類，對不同倉儲地點(diǎn)的庫存進(jìn)行配置，并確定交付日期，這樣的一個系統(tǒng)稱為訂單管理系統(tǒng)。接下來，本文作者從三個方面對訂單管理進(jìn)行了簡單的分享。

訂單的流入是電商供應(yīng)鏈履約的起始，訂單的完結(jié)是用戶單次服務(wù)的終結(jié)，本文從以下三個方面對訂單管理進(jìn)行了簡單的分享：

1. 單據(jù)概念簡述
2. 單據(jù)流轉(zhuǎn)詳述
3. 單據(jù)狀態(tài)流

一、單據(jù)概念簡述

在今天的分享中，主要會涉及到三種類型的單據(jù)：銷售訂單、包裹單、出庫申請單，在流程的展開前，我想先簡單的介紹下這三種單據(jù)：

1. 銷售訂單

前臺用戶下單后，創(chuàng)建的單據(jù)稱之為銷售訂單，銷售訂單創(chuàng)建時通常包含以下要素：

• 用戶相關(guān)信息：用戶ID、用戶等級、姓名、收貨地址等；
• 商品相關(guān)信息：商品ID（前臺商品）、數(shù)量；
• 價(jià)格相關(guān)信息：單價(jià)、總價(jià)、優(yōu)惠金額；
• 其他：關(guān)聯(lián)活動ID、下單時間、用戶備注等。

2. 包裹單

OMS中可直接下傳給WMS的單據(jù)，包裹單是銷售訂單經(jīng)過特殊業(yè)務(wù)邏輯處理后生成的，它和銷售訂單的關(guān)系是m:n（下文流程中會有詳細(xì)展開），主要包括以下字段：

• 用戶相關(guān)信息：用戶ID、收貨人姓名、收貨地址等；
• 商品相關(guān)信息：商品ID（后臺商品）、數(shù)量；
• 發(fā)貨相關(guān)信息：發(fā)貨倉、發(fā)貨物流（物流公司、物流單號）、包材、包裹重量、體積等。

3. 出庫申請單/出庫單

WMS中實(shí)際用于出庫和出庫后生成的單據(jù)。

出庫申請單是包裹單通過審核后創(chuàng)建的單據(jù)，單據(jù)中所帶信息更多是用于倉庫和發(fā)貨實(shí)操的，如：庫位、商品批次等。

本文中不再展開，有興趣的小伙伴可以查看：《供應(yīng)鏈：WMS出庫管理》、《供應(yīng)鏈：WMS庫內(nèi)管理設(shè)計(jì)》。

二、單據(jù)流轉(zhuǎn)詳述

下圖為簡化的單據(jù)流轉(zhuǎn)流程圖：

從流程圖中可以看出，在OMS的訂單處理中2塊比較重要的邏輯分別是：攔截器、拆合單和審單。

1. 攔截器

攔截器是基于業(yè)務(wù)的特殊場景和特殊邏輯對訂單進(jìn)行攔截，阻止訂單的下發(fā)。

最常見的是根據(jù)收貨地+貨品屬性/商品ID攔截，主要針對國家大會期間，某些地區(qū)是禁止寄送粉末、液體類的物品這類場景，則可通過攔截器進(jìn)行設(shè)置。到了截止時間時，訂單可以自動再次下發(fā)。

也可用于對指定用戶、指定活動的訂單的攔截，用戶可根據(jù)需求自行配置。

2. 合單

根據(jù)既定規(guī)則對銷售訂單進(jìn)行合并。

合單的本質(zhì)目的在于訂單的整合帶來的包裹數(shù)減少有利于履約成本（倉庫操作成本、物流成本、包材成本等）的降低，同時也有利于用戶體驗(yàn)的提升。

最常見的規(guī)則：同一用戶、同一店鋪、同一收貨信息的訂單可進(jìn)行合并。

最近社群團(tuán)購也比較火，不知道大家有沒有發(fā)現(xiàn)，社群團(tuán)購的模式中其實(shí)也隱含了一個合單的訴求。

對于同一個團(tuán)長下不同團(tuán)員的訂單，是需要進(jìn)行合單的，因?yàn)檫@類訂單對于后續(xù)的發(fā)貨來說其實(shí)是一個單筆訂單（團(tuán)長單是統(tǒng)一發(fā)給團(tuán)長的，并不是單獨(dú)發(fā)給個人）。

3. 拆單

上面既然已經(jīng)提到了合單有利于成本降低，那么為什么我們還要有拆單呢？

訂單一般是在“不得不拆”的情況下才會進(jìn)行拆分：

1. 用戶購買的商品在不同的倉庫；
2. 商品可以原箱發(fā)貨（此類商品一般本身體積就比較大，比如紙尿片4提是一箱，即使用戶購買了8提2箱一開始走了合單邏輯）；
3. 禮盒類/指定商品：為了提升用戶體驗(yàn)，禮盒類商品通常也會和普通商品拆單發(fā)貨（且，通常禮盒類商品是有指定包材的）；
4. 用戶購買的商品過多，超出了倉內(nèi)最大包材容積，只能拆單。

此外還有其他的拆單場景此處就不一一列舉了，建議OMS中的拆單規(guī)則按照不同的場景設(shè)計(jì)為可配置的，可較靈活得適配不同平臺、場景推送的訂單。

拆單過程還會伴隨倉庫的分配（從上面判斷就可以看出，拆單中會參考倉庫庫存的要素）、物流公司和單號的獲取。

4. 審單

審單主要指人為的對生產(chǎn)的包裹單進(jìn)行確認(rèn)，也可在這個環(huán)節(jié)添加人工的備注信息。審單通過后，包裹單會推送至WMS創(chuàng)建出庫申請單，進(jìn)入出庫環(huán)節(jié)，目前很多OMS都是可以進(jìn)行自動審單的。

5. 異常說明

從流程中我們可以看到，訂單處理中是存在異常場景的，異常主要包括：

1. 倉庫庫存不足；
2. 針對收貨地，無物流公司覆蓋（一般是業(yè)務(wù)沒有及時維護(hù)）；
3. 快遞單號獲取異常；
4. 商品異常（前臺商品轉(zhuǎn)后臺商品時出現(xiàn)異常）。

此時需要人為介入進(jìn)行處理。

三、單據(jù)狀態(tài)流

基于以上的流程，我們也可以歸納出，在訂單正向流程中單據(jù)會經(jīng)過以下的各狀態(tài)流，并且單據(jù)之間的狀態(tài)是有相關(guān)性的（注意：以下流程僅涉及正向的，不包含用戶發(fā)起訂單取消或發(fā)起售后的狀態(tài)機(jī)）：

1. 銷售訂單

• 代付款：用戶提交訂單但未付款；
• 待發(fā)貨：用戶付款后訂單狀態(tài)為待發(fā)貨；
• 已發(fā)貨：倉庫發(fā)貨后狀態(tài)變更（考慮到可能拆單發(fā)貨一般還會有發(fā)貨中或部分發(fā)貨狀態(tài)）；

此外在逆向鏈路中，訂單還會涉及到已取消、售后中等狀態(tài)，此處不展開贅述了。

2. 包裹單

• 待審核：銷售訂單經(jīng)過攔截器過濾后創(chuàng)建包裹單的初始狀態(tài)（如果是自動審單則系統(tǒng)會自動跑過這個狀態(tài)）；
• 待處理：人工審核通過后，系統(tǒng)執(zhí)行拆合單、下發(fā)倉庫出現(xiàn)異常時出現(xiàn)的狀態(tài)；
• 未發(fā)貨：包裹單正常下發(fā)倉庫后，倉庫未發(fā)貨前；
• 已發(fā)貨：倉庫執(zhí)行發(fā)貨。

3. 出庫通知單

• 待出庫：出庫通知單創(chuàng)建時的初始狀態(tài)；
• 出庫中：出庫申請單在庫內(nèi)分配庫存/創(chuàng)建波次后，出庫前，處在出庫中的狀態(tài)；
• 已完成：單據(jù)出庫完成。

四、總結(jié)

以上就是今天想和大家分享的全部內(nèi)容，希望可以對你有所幫助，感謝閱讀。

#專欄作家#

麋鹿產(chǎn)品，公眾號：麋鹿產(chǎn)品手冊，人人都是產(chǎn)品經(jīng)理專欄作家。專注供應(yīng)鏈挖掘提升，熱愛生活，熱愛產(chǎn)品。

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

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