在跨境電商業務場景下，訂單的產生是常見的環節之一，那么在這一場景下，訂單模塊該如何搭建相應的設計策略？過程中又有哪些細節事項需要注意？一起來看看作者的分析和解答。

一旦發生交易，就會產生訂單。在所有涉及到訂單的系統中，訂單模塊往往是最核心的部分。本文以跨境電商為業務背景，講解一下訂單模塊的產品設計。

一、訂單下載

對于跨境賣家而言，對于訂單下載肯定不陌生，也就是常說的“抓單”，將第三方平臺的訂單同步到自己系統。抓單需要考慮2個問題。

(資料圖)

訂單有未付款、已付款、已發貨、簽收、退款等等狀態。以海運為例，如果是直發，走海運從國內發貨到美國簽收，可能需要40-50天。這樣就意味著訂單狀態從發貨到簽收，也需要40-50天。假設公司每天到美國有5W單，那么到了50天后就會有250萬單，為了同步狀態，難道每天去遍歷幾百萬條數據？

所以有一種處理方式就是只會同步幾個狀態，最常見就是同步未付款、已付款、已發貨3個狀態。只要發貨，在賣家端的操作就已經完結了。后續客戶的售后操作，就會形成新的售后訂單，按照依舊按照上述邏輯去同步狀態。

二、訂單預占

成功抓單后，訂單就預占中央庫存的庫存。

中央庫存不是一個系統，甚至頁面都沒有。理解理解中央庫存是一個調度模塊。抓單后，訂單通過調度系統指派那個倉庫發貨出庫。

最簡單的中央庫存模型就是公司有N個倉庫，這N各倉庫的庫存統一起來就是一個中央庫存。此時對中央庫存的預占只是增加了中央庫存的鎖定層，倉庫的實物層并沒有受影響。

三、拆合單策略

合單的本質就是為了減少履約成本，最直觀的就是體現在運費上。用戶下了3個訂單，公司一次性給用戶發了，就節省了2次的運費。

最常見的合單規則就是同一個客戶，在同一個店鋪，收貨地址相同的訂單合并。

按理來說不同的店鋪的訂單應該也可以合并。因為第三方平臺有防關聯政策，如果一個賣家注冊多個賬號在平臺賣貨。系統檢測到的話就會封號，所以合單一般都不回跨店鋪。

訂單的合并條件還有更多，如下圖所示：

合單功能比較簡單，重點是合單后的處理。

如果2個訂單合單了，且2個訂單已經匹配了倉庫，合并后根據“就近就全”原則，是否需要重新匹配倉庫？

如果2個訂單手動合單了，且2個訂單已經匹配了物流，合單后是否需要根據“匹配物流”策略，重新匹配物流？

上面說了合并是為了減少履約成本，拆單就是增加了履約成本，那么為什么還需要拆單呢？因為在實際的工作場景中有很多不得不拆單的情況。常見的拆單策略有：

拆分的訂單也需要考慮是否需要重新尋倉和匹配物流。

一些人搞不懂ERP拆單和倉庫拆包之間的關系，拆單可以理解為將銷售單拆分成N個，拆包理解為將銷售單拆分為多個包裹（包括也可以理解為運單）。

小結：

訂單的拆單和合單需要考慮訂單的成本、銷售額、優惠等金額的計算，還需要考慮贈品。這一塊的計算規則稍微復雜一點，我放在營銷模塊去講。

需要注意的是自動拆單合單策略需要放在尋倉、分配物流這些策略前面，因為拆單和合單需要重新尋倉和分配物流。

四、尋倉

尋倉就是系統找到最合適的倉庫，所以尋倉的核心邏輯就一句話：“就近就全”原則。

找到距離用戶最近的倉庫，且倉庫當前的可用庫存可以滿足訂單。這里就引申了一個問題，尋倉，尋哪些倉庫？比如用戶的收貨地址是美國，尋歐洲的倉顯然就不合理，所以尋哪些倉庫也就需要根據用戶的收貨地址做配置。

如果公司有成品倉庫和半成品倉庫，用戶下單購買了半成品，那么尋成品倉顯然不合理，所以尋倉也需要根據用戶中商品的屬性進行配置。

結合以上的描述，那么我們可以把尋倉功能做成策略，進行配置，如下圖所示（僅供參考）：

看到一個友商的產品設計，非常類似，就截圖過來了。從上圖可以看出，首先配置一些“滿足條件”，這些條件有收獲地址，貨品分類等等，滿足條件后去執行指定的倉庫，倉庫可以配置多個。

“就全”怎么理解呢？就是一個訂單盡量由一個倉庫發貨，避免多個倉庫發貨吧訂單拆分成多個包裹。試想一下用戶下單，結果一個訂單收到了5-8個包裹，體驗非常不好，而且公司要付出的運費也高。

但是這里有一種特殊情況，舉個栗子說明。如：用戶下單，收貨地址為深圳，系統檢索了整個華南地區的倉庫，沒有一個倉庫可以完全滿足。但是在西藏的一個倉庫可以滿足訂單，那么此時應該是華南地區的多個倉庫

那么是在華南地區拆分成多個包裹發貨，還是在西藏發貨，這個就要看公司策略了。

五、倉庫預占

當尋倉完成之后，就預占倉庫的庫存，將中央庫存預占的庫存下推給倉庫，邏輯如下圖所示：

六、分配物流

分配物流就是給訂單匹配一個發貨方式用于發貨，分配物流的核心邏輯與尋倉一致，也是一個句話：“選擇滿足發貨方式中最便宜的物流”。

作為跨境賣家，通常會對接很多物流公司。作為賣家出于節省成本的考慮，肯定會選擇滿足訂單履約，且最便宜的物流。

具體的物流模塊的產品設計我就不贅述了，內容太多。感興趣可以去看我之前寫的文章《ERP-物流模塊設計》。

七、訂單審核

訂單審核的頁面如下（僅供參考）：

審單就是人工在對訂單進行確認，因為在實際的工作情況中有非常多的特殊情況，如：用戶修改地址，用戶的一些特殊備注等等。

在審核頁面也可以手動對訂單進行拆分、合單、改物流、改備注等操作。

在審核通過之后，訂單就會下推到WMS系統，倉庫進行揀貨出庫。但是在根據不同的業務發貨方式也不同，常見的有3種發貨方式，如下：

竟然有審核操作，那么也有審單策略。如果每天5W單，審單就2個人，那么每天的工作怎么做都做不完。所以就需要做一個自動審單的策略，將一些常規的訂單自動審核通過，一些不常規的訂單攔截由人工審核。

自動審單策略的界面如下（僅供參考）：

八、自動攔截策略

設置一些規則，將滿足規則的訂單標記為異常訂單，這里先說一下WMS的異常單，因為WMS的異常單與ERP的異常單會有關聯。

在WMS常見的異常原因有：缺貨、收貨地址變更、退款、部分退款、物流方式變更、取消發貨、備注變更、發貨超時、打包時錯貨/少貨/次品等等

不同的異常原因后續的處理流程不同。

訂單退款和取消發貨，訂單就已經結束了發貨流程。

部分取消發貨，通常是將訂單打回上游系統，上游系統拆單后重新下推到倉庫。

其它的異常原因，本質就是訂單進行掛起，訂單不會進入下一個環節。

那么在ERP的異常訂單也是同理，設置一些策略，訂單滿足策略就標記異常。異常策略如下（僅供參考）：

這里只需要主要一個點，如果ERP的訂單下推到了WMS，在ERP標記異常的訂單，相應WMS的訂單是否也需要標記異常？在WMS標記異常，相應ERP的訂單是否需要標記異常？

如果在WMS標記的異常訂單，相應ERP的訂單也標記異常，那么在ERP是否可以手動解除異常？

以上就是整篇文章的內容，希望能夠對你有所幫助。

本文由@koi 原創發布于人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash, 基于 CC0 協議

該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。

標簽：