新零售 SaaS 架構：訂單履約系統的概念模型設計

大家好，我是湯師爺。

訂單履約系統的概念模型

• 訂單：客戶提交購物請求後，生成的買賣合同，通常包含客戶信息、下單日期、所購買的商品或服務明細、價格、數量、收貨地址以及支付方式等詳細信息。

• 子訂單：爲了更高效地進行履約，大訂單可能會被拆分成多個子訂單，子訂單會根據商品類型、配送地址、倉庫位置或供應商等因素進行拆分。

• 發貨單：根據子訂單生成，指導完成訂單的具體履約任務，如商品的揀選、包裝、出庫、配送等。 

在整個訂單履約過程中，訂單是起始，子訂單是訂單拆分的結果，用於處理更細粒度的履約邏輯，發貨單則是具體的執行單據，指導商品從倉庫到客戶手中的具體操作任務。這三個模型層層遞進，確保整個履約鏈條的高效管理。

訂單拆分場景

單門店履約場景

在連鎖模式下，系統會自動根據用戶的收貨地址匹配最近的門店。如果匹配到某個門店，且門店庫存充足，能完成履約服務。在這種情況下，不會對訂單進行拆分，直接分配給門店進行備貨。

多倉庫履約場景

有些商家有多個倉庫，不同的商品存放在不同的門店或倉庫裏。

當用戶下單時，如果訂單內的商品在不同的倉庫，就需要拆分訂單，把拆分後的子訂單匹配到對應的倉庫中，然後根據商品的數量進行備貨和出庫。

按訂單類型、商品類型拆分

由於訂單和商品類型的差異，我們需要將其拆分成不同類型的子訂單。

商品中包括跨境商品、分銷商品等，我們會根據不同的商品類型自動拆分。

對於生鮮水果、冷鏈食品以及其他易碎物品，由於它們對快遞的保護性和及時性有較高的要求，我們需要單獨包裝併發貨。

如果訂單中包含這類商品，會對訂單進行拆分處理。

按物流場景拆分

物流公司通常對包裹的重量和體積有限制。如果訂單中的商品超過這些限制，就需要將訂單拆分爲多個發貨單來發貨。

從成本的角度考慮，在某些情況下，將大量商品分成多個發貨單可能會比一個大包裹發貨更省錢。

客戶可能會有特殊的物流要求，如分批送達或特定時間送達，需要將訂單拆分爲多個發貨單。例如預售商品與其他商品一起下單，需要等到預售商品到貨後再發貨。

寫在最後

本文主要介紹了訂單履約系統的概念模型設計。

文章首先定義了 "訂單"、"子訂單" 和 "發貨單" 這三個核心概念，並澄清了它們在整個訂單履約過程中的關係。

接着，文章詳細描述了四種常見的訂單拆分場景，分別是單門店履約場景、多倉庫履約場景、按訂單類型、商品類型拆分以及按物流場景拆分。各種場景下的訂單拆分，能確保整個履約鏈條的高效管理。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/zLR64E6B4qWeKY4uiORsPA