倉庫資源信息處理、提供庫存信息的方法及裝置與流程
2023-04-29 11:01:06 2
本申請涉及倉庫資源信息處理
技術領域：
，特別是涉及倉庫資源信息處理、提供庫存信息的方法及裝置。
背景技術：
：隨著電子商務交易平臺的不斷完善，以及傳統通信、移動通信等技術的快速發展，越來越多的人們通過網上購物的方式來獲取自己所需的商品，商品的種類可以涉及到人們日常生活的方方面面，其中包括家用電器、家具等類目的商品。對於這類商品而言，由於具有體積大、重量大、易損壞等特點，如何進行商品的倉儲以及配送是一個關鍵性的問題。為此，一些電子商務交易平臺為這類商品提供了統一的倉儲服務，例如，在天貓、淘寶交易平臺中，平臺為淘系商家提供了可以訂購的「菜鳥倉」，這種菜鳥倉一般為多個，分布在全國各地，甚至還可能會有海外倉，等等，並且每個菜鳥倉具有自己的配送覆蓋範圍。商家可以根據自己的銷售策略，將商品入駐到菜鳥倉。買家用戶訂購的商家的商品可以統一從菜鳥倉發貨，並由平臺提供統一的配送服務。以上銷售模式一般被稱為「4PL」模式，這種模式可以節約商家的成本，並且從倉庫資源及配送資源角度講，還可以起到節省資源，降低資源浪費的目的，此外，還可以從整體上提高交易平臺的服務質量。但是，在上述4PL模式下，商家需要把商品庫存運輸到菜鳥倉才可以銷售，在商家沒有精準的銷售預測的情況下，錄入的庫存會存在或多或少的不準確。在庫存錄入不足時，會引起的流量損失，在庫存錄入太多時，又會引起的商品滯銷，帶來不必要的資金損失。當然，在現有技術中還可以採用傳統的3PL模式，也即，商家的貨品不入駐菜鳥倉，而是在自己部署的商家倉中進行存儲，買家用戶下單後，從商家倉發貨，由第三方配送公司提供配送服務。這種方式不存在向菜鳥倉鋪貨時鋪貨 量的問題，但是，商家倉的物流發貨能力是有限的，不能覆蓋全國，導致有些區域不能銷售，引起自己交易訂單量的無謂損失。另外，平臺無法對各個商家的發貨進行統一管理，無法從整體上提高平臺服務質量。技術實現要素：本申請提供了倉庫資源信息處理、提供庫存信息的方法及裝置，能夠為第一用戶提供更優化的庫存分布網絡。本申請提供了如下方案：一種倉庫資源信息處理方法，包括：物流中心伺服器確定第一用戶關聯的至少一個第一類型實體倉庫資源的信息以及至少一個第二類型實體倉庫資源的信息；其中，所述第一類型實體倉庫資源為平臺提供的倉庫資源，所述第二類型實體倉庫資源為第一用戶自有的倉庫資源；創建針對所述第一用戶的虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係；將所述第一用戶的虛擬倉庫資源信息同步到庫存中心伺服器，以便利用所述虛擬倉庫資源信息提供可售信息服務；其中，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述虛擬庫存資源的庫存根據所述目標第一類型實體倉庫資源以及所述具有共享關聯關係的目標第二類型實體倉庫資源中的庫存確定；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行 補貨。一種提供庫存信息的方法，包括：庫存中心伺服器接收穫取指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源對應的所述目標第一類型實體倉庫資源以及所述目標第二類型實體倉庫資源；分別確定所述指定業務對象SKU在所述目標第一類型實體倉庫中的第一庫存，以及在所述目標第二類型實體倉庫中的第二庫存；根據所述第一庫存以及所述第二庫存，確定所述虛擬倉庫資源中的庫存並返回。一種提供庫存信息的方法，包括：前端伺服器接收瀏覽指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；所述前端伺服器為用於提供查看詳情或者購買服務的伺服器；將所述請求轉發至庫存中心伺服器，以便所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信 息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；利用所述庫存中心伺服器返回的信息提供所述指定業務對象SKU庫存信息。一種提供庫存信息的方法，包括：第二用戶客戶端接收瀏覽指定業務對象SKU信息的指令；確定所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；向前端伺服器發送獲取所述指定業務對象SKU庫存信息的請求，並在所述請求中攜帶所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；以便所述前端伺服器將所述請求轉發至庫存中心伺服器，由所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；根據所述前端伺服器返回的信息，提供所述指定業務對象SKU庫存信息。一種倉庫資源信息處理裝置，應用於物流中心伺服器，包括：倉庫基礎信息確定單元，用於確定第一用戶關聯的至少一個第一類型實體倉庫資源的信息以及至少一個第二類型實體倉庫資源的信息；其中，所述第一類型實體倉庫資源為平臺提供的倉庫資源，所述第二類型實體倉庫資源為第一用戶自有的倉庫資源；虛擬倉庫資源創建單元，用於創建針對所述第一用戶的虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係；同步單元，用於將所述第一用戶的虛擬倉庫資源信息同步到庫存中心伺服器，以便利用所述虛擬倉庫資源信息提供可售信息服務；其中，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述虛擬庫存資源的庫存根據所述目標第一類型實體倉庫資源以及所述具有共享關聯關係的目標第二類型實體倉庫資源中的庫存確定；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨。一種提供庫存信息的裝置，應用於庫存中心伺服器，包括：請求接收單元，用於接收穫取指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；倉庫資源確定單元，用於確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體 倉庫資源進行補貨；匹配運算單元，用於利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；實體倉庫資源確定單元，用於如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源對應的所述目標第一類型實體倉庫資源以及所述目標第二類型實體倉庫資源；實體庫存確定單元，用於分別確定所述指定業務對象SKU在所述目標第一類型實體倉庫中的第一庫存，以及在所述目標第二類型實體倉庫中的第二庫存；虛擬庫存確定單元，用於根據所述第一庫存以及所述第二庫存，確定所述虛擬倉庫資源中的庫存並返回。一種提供庫存信息的裝置，應用於前端伺服器，所述前端伺服器為用於提供查看詳情或者購買服務的伺服器；所述裝置包括：請求接收單元，用於接收瀏覽指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；請求轉發單元，用於將所述請求轉發至庫存中心伺服器，以便所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；庫存信息提供單元，用於利用所述庫存中心伺服器返回的信息提供所述指定業務對象SKU庫存信息。一種提供庫存信息的裝置，應用於第二用戶客戶端，包括：指令接收單元，用於接收瀏覽指定業務對象SKU信息的指令；信息確定單元，用於確定所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；請求發送單元，用於向前端伺服器發送獲取所述指定業務對象SKU庫存信息的請求，並在所述請求中攜帶所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；以便所述前端伺服器將所述請求轉發至庫存中心伺服器，由所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；庫存信息提供單元，用於根據所述前端伺服器返回的信息，提供所述指定業務對象SKU庫存信息。根據本申請提供的具體實施例，本申請公開了以下技術效果：通過本申請實施例，可以重構商家倉(第二類型實體倉庫資源)和菜鳥倉網絡(第一類型實體倉庫資源)，以菜鳥倉為核心，商家倉附屬於附近的菜鳥倉，商家倉的庫存共享給菜鳥倉，同時可以快速補貨到菜鳥倉，同時共享庫存可以在電商領域銷售，在一定程度上提升了菜鳥倉庫存存放的合理度，同時減少由於菜鳥倉鋪貨不準引起的消費者流失。另一方面，能夠平衡商家倉的庫存和菜鳥倉的庫存，給商家最優的庫存分布網絡。同時，繼續走4PL的物流配 送體系，也即，即使商家倉可售，也需要將貨品發送到菜鳥倉之後，才能進行統一的發貨，給商家最優的供應鏈鋪貨解決方案，也使得買家用戶繼續獲得高質量的服務。當然，實施本申請的任一產品並不一定需要同時達到以上所述的所有優點。附圖說明為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據這些附圖獲得其他的附圖。圖1是本申請實施例提供的第一方法的流程圖；圖2是本申請實施例提供的第二方法的流程圖；圖3是本申請實施例提供的第三方法的流程圖圖4是本申請實施例提供的第四方法的流程圖圖5是本申請實施例提供的第一裝置的示意圖；圖6是本申請實施例提供的第二裝置的示意圖；圖7是本申請實施例提供的第三裝置的示意圖；圖8是本申請實施例提供的第四裝置的示意圖。具體實施方式下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基於本申請中的實施例，本領域普通技術人員所獲得的所有其他實施例，都屬於本申請保護的範圍。在本申請實施例中，可以重構商家倉和菜鳥倉網絡，以菜鳥倉為核心，商家倉附屬於附近的商家倉，商家倉的庫存共享給菜鳥倉，同時可以快速補貨到 菜鳥倉，並且共享庫存可以在電商領域銷售，以此構建成商家的虛擬倉庫網絡。這樣可以在一定程度上提升菜鳥倉庫存存放的合理度，同時減少由於菜鳥倉鋪貨不準引起的消費者流失。另一方面，能夠平衡商家倉的庫存和菜鳥倉的庫存，給商家最優的庫存分布網絡，同時繼續走4PL的物流配送體系，給商家最優的供應鏈鋪貨解決方案。首先需要說明的是，在本申請實施例中，涉及到的實體主要有以下幾種：物流中心伺服器(例如，淘系菜鳥物流寶系統的伺服器等等)、庫存中心伺服器(主要用於保存庫存信息)、前端伺服器(一般是指用於提供查看詳情或者購買服務的伺服器，例如，detail/buy頁面對應的伺服器)、客戶端。其中，客戶端一般還可以分為買家用戶側的客戶端以及商家/賣家用戶側的客戶端。在本申請實施例中，各實體之間相互配合，例如：物流中心伺服器可以根據商家/賣家用戶側客戶端的請求，創建前述虛擬倉庫資源，當然也可以自動進行虛擬倉庫資源的創建；創建完成之後，將相關信息同步到庫存中心伺服器，使得該虛擬倉庫資源成為可售狀態；此時，前端伺服器在通過買家用戶側客戶端接收到瀏覽具體業務對象SKU(StockKeepingUnit，庫存量單位，例如，對於某型號手機，不同顏色、容量等可以搭配出多個SKU)的請求時，就可以向庫存中心伺服器請求相關的庫存信息，該庫存信息就可能是某虛擬倉庫中的庫存信息。下面首先從物流中心伺服器的角度，對創建虛擬倉庫資源、構建虛擬倉庫網絡的具體實現進行介紹。實施例一參見圖1，該實施例一首先提供了一種倉庫資源信息處理方法，該方法可以包括以下步驟：S101：物流中心伺服器確定第一用戶關聯的至少一個第一類型實體倉庫資源的信息以及至少一個第二類型實體倉庫資源的信息；在本申請實施例中，將平臺提供的倉庫資源稱為第一類型實體倉庫資源， 例如前述例子中的菜鳥倉；將商家自由的倉庫資源稱為第二類型實體倉庫資源，例如前述例子中的商家倉。另外，第一用戶可以是指銷售平臺中的商家或者賣家用戶，第二用戶可以是指買家用戶。當然，為了便於描述，在以下行文中必要的地方，仍然以菜鳥倉或者商家倉為例進行介紹，可以理解，並不能將其看作是對本申請保護範圍的限制。在具體實現時，平臺一般會將其能夠提供的各個菜鳥倉的信息發布給商家，商家可以根據自己的需求訂購其中的部分菜鳥倉。因此，第一用戶關聯的至少一個第一類型實體倉庫資源，也就是商家預先訂購的各個菜鳥倉。其中，商家在訂購菜鳥倉時，可以為其所有的業務對象SKU訂購相同的物流解決方案，也就是說，假設某商家有10款SKU需要通過銷售平臺進行銷售，則該商家可以為這10款SKU訂購相同的物流解決方案，例如，選擇了5個菜鳥倉，則該商家將會將這10款SKU分別向這5個菜鳥倉進行鋪貨。或者，商家在訂購菜鳥倉時，還可以分別為不同的SKU訂購不同的菜鳥倉，例如，針對SKU001訂購的菜鳥倉有A、B、C，針對SKU002訂購的菜鳥倉有A、B、C、D，等等。當然，對於上述第二種情況，在確定商家關聯的菜鳥倉時，可以針對各個不同的SKU分別進行確定，後續的具體實現方式在本質上還是相同的，因此，在本申請實施例中，主要以商家為所有SKU訂購相同的菜鳥倉的方式為例進行介紹。另外，關於菜鳥倉的位置、配送範圍，以及商家的各個SKU在各個菜鳥倉中的庫存情況，菜鳥物流寶系統中有相關的記錄，因此，這部分信息對於菜鳥物流寶系統而言是已知的。而關於第一用戶關聯的第二類型實體倉庫資源，也即商家的商家倉，這部分信息可以是由商家提交的，例如，對於淘系商家，可以由商家倉系統通過菜鳥物流寶系統接口，錄入商家倉基本信息，包括具體有哪些商家倉，每個商家倉所在的地址，配送範圍等等。另外，商家倉系統還可以將業務對象SKU在商家倉中的庫存信息同步到菜鳥物流寶系統。總之，在商家關聯的商家倉基礎信息，與菜鳥倉基礎信息中，可以收集屬於倉的一些核心信息，包括倉的編碼、地址、名稱等等。例如，對於菜鳥倉的核心信息可以如表1所示：表1對於商家倉的核心信息可以如表2所示：表2S102：創建針對所述第一用戶的虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係。在收集到前述倉的基礎信息之後，就可以構建虛擬倉網絡模型，在這個模型中菜鳥倉被賦予了COMPANY_ID(第一用戶ID，例如商家ID等)屬性，每個商家都能對菜鳥倉進行定製，定製後這個菜鳥倉將與商家倉進行關聯。具體創建虛擬倉庫資源(為便於描述，將其稱為「虛倉」)時，一個虛倉只能綁定一個菜鳥倉，但可以綁定同一個商家的多個商家實倉，對於一個商家而言，具體將其訂購的哪個菜鳥倉與哪個或哪些商家倉進行綁定，可以有多種 方式來確定。例如，其中一種方式下，可以是由商家根據需要而確定，具體的，商家可以將需要綁定的菜鳥倉以及商家倉的標識提交到菜鳥物流寶系統，系統由此可以確定出該商家具有以此信息建立虛倉的意願，進而就可以為其創建虛倉網絡。當然，系統在收到商家的創建虛倉的請求後，還可以將商家提交的菜鳥倉以及商家倉是否能夠進行共享關聯進行判斷。其中，一個商家倉能否與某個菜鳥倉進行關聯，核心的決定因素可以為：從商家倉到菜鳥倉的補貨時效。舉例來說明，某個一線城市，買家對送貨的時效有很強烈的期望，那麼商家倉對菜鳥倉的補貨時效原則上應該控制在1-2天內才能進行關聯。如果在某個偏遠地區，買家對購物時效能夠接受在比較寬鬆的範圍，那麼該區域的商家倉與菜鳥倉的補貨關聯可以控制3-4天。當然，還可以通過其他的因素來判斷商家倉與菜鳥倉能否關聯，因此具體的能否關聯，沒有絕對的量化指標，可以根據實際情況進行設置。或者，在另一種實現方式下，還可以由物流寶系統根據各個菜鳥倉與商家倉的位置、配送範圍等，自動地將商家倉與菜鳥倉建立共享關聯，並以此建立虛倉網絡。例如，某菜鳥倉位於北京，某商家倉A位於北京，商家倉B位於天津，由於商家倉A、B與北京的距離都很近，補貨時效能夠滿足在1～2天的要求，因此，可以自動將商家倉A、B與該菜鳥倉進行關聯，等等。在將某菜鳥倉與某個或某幾個商家倉建立共享關聯之後，就可以創建出對應的虛倉。當然，在實際應用中，針對不同商家創建出的虛倉可能是多個，可以通過資料庫的方式來保存虛倉的信息，例如，在一種實現方式下，虛倉資料庫的結構可以如以下表3所示：表3虛倉編碼菜鳥倉編碼商家倉編碼商家編碼XC_001CNC_001SJC_001SJ_001XC_001CNC_001SJC_002SJ_001……………………在上述表格中，虛倉XC_001綁定的菜鳥倉為CNC_001，商家倉為兩個，分別為SJC_001、SJC_002，因此，針對虛倉XC_001，在上述表格中有兩個信息條目。如果一個菜鳥倉關聯了多個商家倉，不同的商家倉在可售的優先級上還可以在進行控制。例如，表4為多倉可售示意圖，第一行為菜鳥倉可售，第二行以及第三行為與菜鳥倉關聯的兩個商家倉可售。表4ID倉庫編碼SKU庫存商家ID優先級1CNC_001SKU_001300SJ_00102SJC_001SKU_00180SJ_00113SJC_002SKU_00190SJ_0012也就是說，對於一個虛倉而言，只要其綁定的菜鳥倉CNC_001有庫存，則優先為菜鳥倉可售。當菜鳥倉無庫存時，可以觸發SJC_001可售；當商家倉SJC_001的共享庫存也售完時，再觸發商家倉SJC_002可售。當然，所謂的商家倉可售並不是直接從商家倉發貨，而是先從商家倉為菜鳥倉補貨，然後再由菜鳥倉進行統一的發貨，對此，後文中會有更為詳細的介紹。S103：將所述第一用戶的虛擬倉庫資源信息同步到庫存中心伺服器，以便利用所述虛擬倉庫資源信息提供可售信息服務。在創建了虛擬倉庫資源之後，就可以該虛擬倉庫資源信息同步到庫存中心伺服器，這樣，就可以利用該虛擬倉庫資源為前端伺服器提供業務對象的可售信息。需要說明的是，虛倉在創建起來之後，由於本質上也是一種倉庫資源(雖然並不實際存儲實體的貨品)，因此，也會存在配送範圍、庫存等屬性。其中，關於虛倉的配送範圍，可以繼承其綁定的菜鳥倉的配送範圍。也就是說，如果某虛倉綁定的菜鳥倉是菜鳥倉A，則該虛倉的配送範圍就是該菜鳥倉的配送範圍。關於菜鳥倉的配送範圍信息，可以在單獨的資料庫表中維護。例如，可以如以下表5所示：表5菜鳥倉編碼覆蓋範圍CNC_001範圍1CNC_002範圍2CNC_003範圍3…………因此，通過查詢該資料庫表，即可確定虛倉的覆蓋範圍。並且，對於具體的商家而言，如果其訂購的某虛倉綁定了某菜鳥倉，也即利用商家倉對該菜鳥倉的庫存進行了擴展，則庫存中心伺服器在表達該商家所具有的倉庫資源信息時，該菜鳥倉將不再被表達出來，只表達該虛倉以及沒有被擴展的菜鳥倉。例如，某商家SJ_001訂購的菜鳥倉有CNC_001、CNC_002、CNC_003這樣三個菜鳥倉，其中，CNC_001被擴展，生成了虛倉XC_001，則在庫存中心伺服器表達出的該商家SJ_001的倉庫資源有以下幾個：XC_001、CNC_002、CNC_003也就是說，當庫存中心伺服器接收到查詢指定第一用戶關聯的各個倉庫的配送範圍請求時，對於被擴展了的菜鳥倉，將會返回對應的虛倉的編碼以及對應的配送範圍信息等。當然，對於未被擴展的菜鳥倉，正常返回該菜鳥倉編碼以及配送範圍等信息即可。而關於虛倉的庫存，則可以由其綁定的菜鳥倉以及商家倉中的庫存來決定。當然，庫存是指具體到某個SKU的庫存數量，因此，在商家向菜鳥倉鋪貨後形成菜鳥倉庫存，並錄入該SKU在其綁定的商家倉中的庫存，這樣就可以確 定出虛倉的可售庫存。當然，在具體實現時，商家倉的庫存雖然可以用於與菜鳥倉進行共享，但是，一個商家倉也可能需要向多個菜鳥倉補貨，並且，商家倉也可能會需要留一部分庫存用於通過其他銷售渠道進行銷售，不能全部共享給菜鳥倉，因此，商家倉可能會是按照一定的共享比例與某菜鳥倉形成共享關聯關係。例如，某菜鳥倉CNC_001，與商家倉SJC_001具有共享關聯關係，該商家倉SJC_001能夠提供給該菜鳥倉CNC_001的共享比例是20％，則針對某SKU，在確定出其在菜鳥倉CNC_001中的第一庫存(C1)，以及在商家倉SJC_001中的第二庫存(C2)之後，可以按照該共享比例，確定出虛倉的可售庫存：C1+C2×20％。需要說明的是，無論是菜鳥倉的庫存還是商家倉的庫存，都是隨著買家用戶執行的購買操作而不斷變化的，該庫存信息會在庫存中心伺服器的庫存資料庫中進行保存，因此，上述確定虛倉庫存的具體實現一般是依請求而執行的。例如，在前端伺服器接收到查詢某SKU庫存信息的請求時，如果確定出匹配的倉庫資源是虛倉，則此時就可以根據前述方式確定出虛倉的庫存，再返回給前端伺服器。可見，由於虛倉的庫存由兩部分組成，一部分來自於菜鳥倉，一部分來自於商家倉，因此一種可能出現的情況是：虛倉中有庫存，但實際上菜鳥倉中已經沒有庫存。例如，當買家用戶在詳情detail或者購買buy頁面瀏覽某SKU時，假設恰好某虛倉XC_001與該買家用戶的收貨地址相匹配，庫存中心伺服器在確定該虛倉XC_001時發現，對應的菜鳥倉中庫存為零，此時，可以根據其綁定的商家倉的庫存以及共享比例，確定出該虛倉的庫存，並提供給前端伺服器，在detail/buy頁面中展示給買家用戶，使得買家用戶可以執行購買操作。也就是說，通過這種方式，即使尚未入駐到菜鳥倉的貨品，仍然可以作為可售貨品進行銷售，也即使得商家的更多商品可以獲得銷售機會。當然，實際的發貨仍然是從菜鳥倉發貨的，也即需要等到商家倉向該菜鳥倉補貨之後，發貨系統才能執行發貨操作。此時，雖然買家用戶從下單到收到貨品的時間可能會延長，但是，相對於無貨狀態下的不能購買，一般的買家用戶更能夠接受這種時間上的延長，因此，對應買家用戶也有好處。其中，在具體實現時，庫存中心伺服器可以是在接收到前端伺服器的查詢請求時，提供具體的庫存信息(關於該部分內容，後續在實施例二中會有詳細 介紹)。另外，庫存中心伺服器在向買家用戶表達虛倉的庫存信息時，還可以提供對應的配送時效信息。由於實際的發貨都是從菜鳥倉發的，因此，關於虛倉的配送時效信息，可以根據其綁定的菜鳥倉中是否有庫存來確定。例如，如果菜鳥倉中有庫存，則可以直接根據該菜鳥倉對應的配送時效，來向買家用戶提供第一配送時效信息。而如果菜鳥倉中沒有庫存，則需要先由關聯的商家倉為其補貨，此時可以向買家用戶提供第二配送時效信息。其中，第一配送時效以及第二配送時效的具體數據都可以是預先設置的，並且，第二配送時效大於第一配送時效。或者，對於第二配送時效，還可以根據商家倉對菜鳥倉補貨時的補貨時效，以及菜鳥倉的配送時效計算得到。在上述第二種情況下，還可以建立倉間補貨能力信息表，表中包含的欄位及其含義如表6所示：表6上述數據表中的補貨時效、補貨能力等信息可以是由商家用戶確定並提交的。通過上述數據表，就可以查詢出某虛倉綁定的商家倉為對應的菜鳥倉補貨時的補貨時效。另外，在前端伺服器接收到用戶針對指定業務對象SKU的購買請求後，可以生成交易訂單，並在該交易訂單中的前置路由信息中記錄用於發貨的倉庫資源的標識信息，該標識信息就可能是某虛擬倉庫資源的標識信息。此時，物流中心伺服器在根據該交易訂單進行發貨處理時，可以通過以下方式進行：首先，根據前置路由信息中的虛擬倉庫資源標識，確定該虛倉綁定的目標菜鳥倉編碼，以及至少一個目標商家倉的編碼，然後就可以從庫存中心伺服器獲取該 指定SKU在該目標菜鳥倉中的第一庫存，如果該第一庫存不為零，也即在菜鳥倉中有庫存，則可以直接觸發從該目標菜鳥倉進行發貨。而如果該第一庫存為零，也即在菜鳥倉中沒有庫存，則可以等到目標商家倉向該目標菜鳥倉補貨完畢之後，再觸發從該目標菜鳥倉進行發貨。總之，在構建商家個性化的虛倉網絡之後，就可以在菜鳥倉出現庫存不足時，利用其關聯的商家倉為其補貨。也就是說，在保障對菜鳥倉補貨時效的前提下，可以將原來必須入菜鳥倉後才能銷售的規則，修改為與菜鳥倉關聯的商家倉庫存也可以銷售。當然，商家倉中這部分可銷售的庫存最終仍然是從菜鳥倉進行發貨，也就是說，先由商家倉將庫存調撥到關聯的菜鳥倉，再從菜鳥倉進行發貨。這樣仍然可以通過菜鳥倉來實現統倉統配，商家倉庫存可售只是用來作為銷售預測不準，線上銷售「井噴」，無法及時補貨等情況發生時的兜底方案。需要說明的是，在實際應用中，雖然觸發商家倉可售後再進行補貨也在可接受範圍內，但是原則上還是最好能在菜鳥倉庫存低於安全庫存時提前進行補貨。具體實現時，可以針對第一用戶的業務對象SKU，對銷售情況以及菜鳥倉中的庫存量進行監控，當滿足預置的補貨條件時，就可以生成補貨通知，並提供給第一用戶客戶端。其中，銷售情況可以包括平均日銷售量信息，也就是說，通過數據分析，將最近一段時間內的平均銷量作為日銷量預計值，例如近一個月或者近一周，當目標菜鳥倉中的庫存小於該平均日銷售量與補貨時效之間的乘積時，就可以生成補貨通知。其中，補貨通知中還可以包括建議補貨數量信息，該建議補貨數量略大於所述平均日銷售量與所述補貨時效之間的乘積即可。由於商家倉到菜鳥倉補貨提前期已知，因此可以儘可能的保證發貨時效，並且也不會造成貨品在菜鳥倉中的大量積壓。為了便於體現本申請實施例體現出的優勢，下面通過幾個具體的例子進行介紹，並與傳統中的方案進行對比。例一假定某個區域某個SKU的銷售預測為月銷售600件，日均銷量為20件， 商家倉到菜鳥倉的補貨時效為3天，由於實際上「井噴」式購買並不常見，因此，可以採用「悲觀」備貨的策略，在每次從商家倉向菜鳥倉補貨時，補貨的數量只要略大於20*3＝60，假定為100件即可，後續的補貨可以通過監控實際的銷售情況來進行。而如果使用傳統的方案，由於沒有商家倉可售兜底，擔心失去銷售機會，往往不得不採用「樂觀」的策略，也就是儘可能的多向菜鳥倉補貨，這往往為菜鳥倉的庫存積壓埋下了隱患。例二在傳統的方案中，新品的鋪貨有很大難度，因為沒有歷史數據支撐，很難預測實際的市場接受情況。針對這種場景，在本申請實施例中，仍然可以採用菜鳥倉少量備貨，商家倉大佔比可售模式。通過一段時間的運行，如果銷售情況良好，可根據每日菜鳥倉庫存情況進行監控，及時進行補貨，即使出現了「井噴」式購買現象，由於有商家倉庫存可售兜底，也不會出現銷售計劃浪費的問題。如果市場預期不樂觀，銷量很少，那麼由於前期備貨到菜鳥倉的商品量較少，也不會出現大量庫存積壓的問題。對於滯銷品，可以採用同新品相同的策略，在菜鳥倉中備少量庫存，商家倉中輔助少量庫存，監控銷售情況，如果銷售情況好轉，在調整庫存分布的比例。例三在傳統的方案中，平臺或者商家舉辦的大型促銷活動是造成菜鳥倉庫存積壓的一個重要因素，原因很簡單，也是因為無法預估銷量，過於樂觀的銷售預期，造成了過度的備貨。而在本申請實施例中，對於有商家倉的商家，完全可以將庫存分布到商家倉中，即使出現了菜鳥倉無貨的情況，也可以通過延遲買家可接受的收貨時間為代價，換取商品的精確補貨，因為一旦形成銷售訂單再補貨，已經是精確補貨，在大促期間，買家對發貨的時效期望值會比平時小很多，在可控的情況下通過時間換取精確補貨完全可行。通過以上分析可以看出，菜鳥倉結合商家倉形成共享可售庫存，能有效的改進因為銷售預測不準確造成的補貨兩難問題，該方案充分體現了商家的差異 性與個性化：每個商家根據自身的線下倉庫資源，能夠構建個性化的庫存方案，商家能夠根據區域不同，進行細粒度的，到SKU級別的庫存分布設置，能夠根據商品的銷售情況，合理調整分布到菜鳥倉的庫存。另外由於商家倉庫存可售，實際上在菜鳥倉的庫存被售完前，該部分商家倉庫存還是可以供其它銷售渠道銷售，這在一定程度上減少因為需要鋪貨到菜鳥倉，造成商家原來可以支持多個銷售渠道，現在因為庫存的分布無法實現庫存共享的庫存分布問題。總之，通過本申請實施例，可以在商家倉存在的物質基礎上，對現行的4PL統倉統配方案實現改進。以上實施例一對虛擬倉庫資源的創建過程，以及該虛擬倉庫資源在商家鋪貨方面的作用進行了介紹。而在以下實施例二中，將主要介紹在倉儲物流系統(例如菜鳥物流寶系統)與前端伺服器以及庫存中心系統伺服器交互的過程中，如何利用虛擬倉庫資源實現整體上的支持。其中，所謂的前端伺服器主要是指提供具體瀏覽或者購買等服務的前端伺服器。實施例二參見圖2，本申請實施例二從庫存中心伺服器的角度，提供了一種提供庫存信息的方法，該方法可以包括以下步驟：S201：庫存中心伺服器接收穫取指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；在具體實現時，一般是買家用戶在通過客戶端的detail/buy頁面瀏覽具體某件業務對象信息時，在選中了具體的SKU後，客戶端就可以將獲取庫存信息的請求發送給前端伺服器。該請求中就可以攜帶指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息。其中，關於第二用戶的收貨地址信息，可以是通過多種方式確定。例如，在第二用戶已經登錄的情況下，可以根據該第二用戶在歷史購買過程中設定的常用收貨地址等信息來確定。如果第二用戶未登錄，還可以通過定位等方式確定出 該第二用戶終端設備所在的地理位置信息，由該地理位置信息作為其收貨地址信息。前端伺服器在接收到該請求後，就可以將該請求轉發到庫存中心伺服器，相應的，庫存中心伺服器就可以接收到該請求。S202：確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；庫存中心伺服器在接收到請求之後，首先可以確定出商家的該指定業務對象SKU對應的倉庫資源信息，這種倉庫資源中就可能包括前述實施例一中創建的虛倉資源。例如，在前述例子中，假設該商家預先訂購的菜鳥倉有CNC_001、CNC_002、CNC_003這樣三個菜鳥倉，其中，CNC_001被擴展，生成了虛倉XC_001，則在表達菜鳥物流寶系統表達出的該商家SJ_001的倉庫資源有以下幾個：XC_001、CNC_002、CNC_003S203：利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；庫存中心伺服器在確定出商家對應的倉庫資源之後，還可以同時確定出各個倉庫資源的配送範圍，進而，就可以利用買家用戶的收貨地址相關信息與各個倉庫資源的配送範圍信息進行匹配運算。其中，對於虛倉XC_001的配送範圍，根據對應的菜鳥倉CNC_001的配送範圍而確定。S204：如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源對應的所述目標第一類型實體倉庫資源以及所述目標第二類型實體倉庫資源；如果虛倉XC_001匹配成功，則可以首先確定出該虛倉綁定的菜鳥倉以及商家倉編號。S205：分別確定所述指定業務對象SKU在所述目標第一類型實體倉庫中的第一庫存，以及在所述目標第二類型實體倉庫中的第二庫存；具體確定上述第一庫存以及第二庫存時，可以是向庫存中心系統發送請求而獲得的。S206：根據所述第一庫存以及所述第二庫存，確定所述虛擬倉庫資源中的庫存並返回。在確定出第一庫存以及第二庫存的具體取值後，就可以確定出該虛倉的庫存，然後就可以返回給前端伺服器，前端伺服器再提供給客戶端，由客戶端在相應的detail/buy頁面中展示出具體的庫存信息。具體實現時，在提供庫存信息時，還可以根據第一庫存是否為零，提供配送時效信息。其中，如果第一庫存為非零狀態，則根據對應的菜鳥倉的配送時效，確定第一配送時效信息，如果第一庫存為零，則根據對應的菜鳥倉的配送時效以及商家倉對該菜鳥倉的補貨時效，確定第二配送時效信息。例如，菜鳥倉的配送時效為2天，補貨時效為3天，則第二配送時效信息可以是5天，或者還可以更長，等等。這樣，買家用戶可以根據該配送時效信息，確定是否選購該SKU。在用戶購買該SKU後，前端伺服器可以為其生成交易訂單，並將前置路由的倉庫資源編碼記錄在該交易訂單中，其中，如果是前述匹配成功的是虛倉，則記錄的是該虛倉的編碼。需要說明的是，前端伺服器並不區分實倉或者虛倉的概念，只要將物流寶系統返回的倉庫資源的編碼記錄在交易訂單中即可。在生成交易訂單之後，物流寶系統可以根據該交易訂單中包含的前置路由信息，確定出對應的倉庫編碼，其中，如果是虛倉，則可以首先判斷該虛倉對應的菜鳥倉中是否存在該SKU的庫存，如果存在，則觸發對該菜鳥倉中該SKU的庫存進行扣減，並且還可以觸髮菜鳥物流寶系統執行發貨流程。如果菜鳥倉中不存在該SKU的庫存，則觸發對關聯的商家倉中可共享的庫存數量進行扣減。其中，如果與菜鳥倉具有共享關聯關係的商家倉為至少兩個，則各個商家倉之間可以具有不同的優先級，此時，在對商家倉的可共享庫存進行扣減時， 可以是對當前處於最高優先級且可共享的庫存數量不為零的商家倉的可共享庫存數量進行扣減。需要說明的是，在觸發對商家倉的庫存進行扣減後，並不直接觸發發貨，而是等到商家倉對菜鳥倉完成補貨後，觸發發貨，貨品仍然由菜鳥物流寶系統進行統一的發貨及配送。實施例三該實施例三是與實施例二相對應的，從前端伺服器的角度，提供了一種提供庫存信息的方法，參見圖3，該方法可以包括以下步驟：S301：前端伺服器接收瀏覽指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；所述前端伺服器為用於提供查看詳情或者購買服務的伺服器；S302：將所述請求轉發至庫存中心伺服器，以便所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；S303：利用所述庫存中心伺服器返回的信息提供所述指定業務對象SKU庫存信息。具體實現時，前端伺服器還可以接收庫存中心伺服器返回的配送時效信息並提供，所述配送時效信息根據所述第一庫存是否為零而確定。接收到客戶端對指定業務對象SKU的購買請求時，可以向庫存中心伺服器請求獲取倉庫資源標識信息；其中，所述倉庫資源標識信息包括虛擬倉庫資源標識信息，生成交易訂單，並將倉庫資源標識信息記錄在交易訂單的前置路由信息中，以便物流中心伺服器利用交易訂單中記錄的倉庫資源標識信息進行發貨。實施例四該實施例四也是與實施例二、三相對應的，從第二用戶客戶端的角度，提供了一種提供庫存信息的方法，參見圖4，該方法可以包括以下步驟：S401：第二用戶客戶端接收瀏覽指定業務對象SKU信息的指令；S402：確定所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；S403：向前端伺服器發送獲取所述指定業務對象SKU庫存信息的請求，並在所述請求中攜帶所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；以便所述前端伺服器將所述請求轉發至庫存中心伺服器，由所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；S404：根據所述前端伺服器返回的信息，提供所述指定業務對象SKU庫存信息。其中，客戶端在接收到購買所述指定業務對象SKU的指令時，還可以向所述前端伺服器發送生成交易訂單的請求，以便所述前端伺服器向庫存中心伺服器獲取倉庫資源標識信息，並在生成交易訂單時，將所述倉庫資源標識信息記錄在所述交易訂單的前置路由信息中；其中，該記錄的倉庫資源標識信息包括虛擬倉庫資源的標識信息。總之，通過本申請實施例，可以重構商家倉和菜鳥倉網絡，以菜鳥倉為核心，商家倉附屬於附近的菜鳥倉，商家倉的庫存共享給菜鳥倉，同時可以快速補貨到菜鳥倉，同時共享庫存可以在電商領域銷售，在一定程度上提升了菜鳥倉庫存存放的合理度，同時減少由於菜鳥倉鋪貨不準引起的消費者流失。另一方面，能夠平衡商家倉的庫存和菜鳥倉的庫存，給商家最優的庫存分布網絡。同時，繼續走4PL的物流配送體系，也即，即使商家倉可售，也需要將貨品發送到菜鳥倉之後，才能進行統一的發貨，給商家最優的供應鏈鋪貨解決方案，也使得買家用戶繼續獲得高質量的服務。與實施例一相對應，本申請實施例還提供了一種倉庫資源信息處理裝置，該裝置應用於物流中心伺服器，參見圖5，該裝置可以包括：倉庫基礎信息確定單元501，用於確定第一用戶關聯的至少一個第一類型實體倉庫資源的信息以及至少一個第二類型實體倉庫資源的信息；其中，所述第一類型實體倉庫資源為平臺提供的倉庫資源，所述第二類型實體倉庫資源為第一用戶自有的倉庫資源；虛擬倉庫資源創建單元502，用於創建針對所述第一用戶的虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係；同步單元503，用於將所述第一用戶的虛擬倉庫資源信息同步到庫存中心伺服器，以便利用所述虛擬倉庫資源信息提供可售信息服務；其中，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述虛擬庫存資源的庫存根據所述目標第一類型實體倉庫資源以及所述具有共享關聯關係的目標第二類型實體倉庫資源中的庫存確定；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨。其中，所述虛擬倉庫資源創建單元具體用於：根據所述第一用戶客戶端提交的創建請求，創建針對所述第一用戶的虛擬倉庫資源信息。具體實現時，該裝置還可以包括：交易訂單信息處理單元，用於當前端伺服器生成針對指定業務對象SKU的交易訂單，並且所述交易訂單的前置路由信息中記錄的倉庫資源標識為所述虛擬倉庫資源的標識時，則根據所述虛擬倉庫資源標識，確定對應的所述目標第一類型實體倉庫資源以及至少一個目標第二類型實體倉庫資源；其中，所述前端伺服器為用於提供查看詳情或者購買服務的伺服器；庫存信息獲取單元，用於向庫存中心伺服器請求獲取所述目標第一類型實體倉庫資源中該SKU的第一庫存；第一發貨觸發單元，用於如果所述第一庫存不為零，則觸發從所述目標第一類型實體倉庫資源進行發貨。第二發貨觸發單元，用於如果所述第一庫存為零，則待所述目標第二類型實體倉庫資源向所述目標第一類型實體倉庫資源補貨完成後，觸發從所述目標第一類型實體倉庫資源進行發貨。另外，該裝置還可以包括：監控單元，用於針對所述第一用戶的業務對象SKU，對銷售情況以及所 述目標第一類型實體倉庫中的庫存量進行監控；第一補貨通知單元，用於當滿足預置的補貨條件時，生成補貨通知，並提供給第一用戶客戶端。其中，所述銷售情況包括平均日銷售量信息，所述虛擬倉庫資源信息中還保存有所述目標第二類型實體倉庫資源的補貨時效信息；所述第一補貨通知單元具體用於：當所述目標第一類型實體倉庫中的庫存小於所述平均日銷售量與所述補貨時效之間的乘積時，生成補貨通知。所述補貨通知中還包括建議補貨數量信息；所述建議補貨數量略大於所述平均日銷售量與所述補貨時效之間的乘積。另外，該裝置還可以包括：第二補貨通知單元，用於在生成交易訂單並且所述目標第一類型實體倉庫中的庫存為零時，生成補貨通知，並提供給第一用戶客戶端。與實施例二相對應，本申請實施例還提供了一種提供庫存信息的裝置，應用於庫存中心伺服器，參見圖6，該裝置可以包括：請求接收單元601，用於接收穫取指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；倉庫資源確定單元602，用於確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；匹配運算單元603，用於利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；實體倉庫資源確定單元604，用於如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源對應的所述目標第一類型實體倉庫資源以及所述目標第二類型實體倉庫資源；實體庫存確定單元605，用於分別確定所述指定業務對象SKU在所述目標第一類型實體倉庫中的第一庫存，以及在所述目標第二類型實體倉庫中的第二庫存；虛擬庫存確定單元606，用於根據所述第一庫存以及所述第二庫存，確定所述虛擬倉庫資源中的庫存並返回。具體實現時，該裝置還包括：配送時效信息提供單元，用於根據所述第一庫存，提供配送時效信息。其中，所述配送時效信息提供單元包括：第一配送時效信息提供子單元，用於如果所述第一庫存為非零狀態，則根據對應的目標第一類型實體倉庫資源的配送時效，確定第一配送時效信息。或者，所述虛擬倉庫資源信息中還保存有所述目標第二類型實體倉庫資源的補貨時效信息；所述配送時效信息提供單元包括：第二配送時效信息提供子單元，用於如果所述第一庫存為零，則根據對應的目標第一類型實體倉庫資源的配送時效以及所述補貨時效，確定第二配送時效信息。另外，該裝置還可以包括：實體庫存判斷單元，用於在針對所述SKU的交易訂單生成後，如果所述交易訂單中記錄的倉庫資源標識為虛擬倉庫資源，則判斷該虛擬倉庫資源對應的目標第一類型實體倉庫資源中是否存在該SKU的庫存；第一庫存扣減單元，用於如果存在，則觸發對該目標第一類型實體倉庫資源中該SKU的庫存進行扣減，並觸發發貨流程。第二庫存扣減單元，用於如果所述目標第一類型實體倉庫資源中不存在該SKU的庫存，則觸發對所述目標第二類型實體倉庫資源中可共享的庫存數量進行扣減。其中，當與所述目標第一類型實體倉庫資源具有共享關聯關係的目標第二類型實體倉庫資源為至少兩個時，則各個目標第二類型實體倉庫資源之間具有不同的優先級；所述第二庫存扣減單元具體用於：觸發對當前處於最高優先級且可共享的庫存數量不為零的目標第二類型實體倉庫資源中的可共享庫存數量進行扣減。與實施例三相對應，本申請實施例還提供了一種提供庫存信息的裝置，應用於前端伺服器，所述前端伺服器為用於提供查看詳情或者購買服務的伺服器；參見圖7，所述裝置包括：請求接收單元701，用於接收瀏覽指定業務對象SKU庫存信息的請求，所述請求中攜帶有所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；請求轉發單元702，用於將所述請求轉發至庫存中心伺服器，以便所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；庫存信息提供單元703，用於利用所述庫存中心伺服器返回的信息提供所述指定業務對象SKU庫存信息。具體實現時，該裝置還可以包括：配送時效信息提供單元，用於接收所述庫存中心伺服器返回的配送時效信息並提供，所述配送時效信息根據所述第一庫存是否為零而確定。倉庫資源標識信息獲取單元，用於接收到對所述指定業務對象SKU的購買請求時，向所述庫存中心伺服器請求獲取倉庫資源標識信息；其中，所述倉庫資源標識信息包括虛擬倉庫資源標識信息；前置路由信息記錄單元，用於生成交易訂單，並將所述倉庫資源標識信息記錄在所述交易訂單的前置路由信息中，以便物流中心伺服器利用所述交易訂單中記錄的所述倉庫資源標識信息進行發貨。與實施例四相對應，本申請實施例還可提供了一種提供庫存信息的裝置，應用於第二用戶客戶端，參見圖8，該裝置具體可以包括：指令接收單元801，用於接收瀏覽指定業務對象SKU信息的指令；信息確定單元802，用於確定所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；請求發送單元803，用於向前端伺服器發送獲取所述指定業務對象SKU庫存信息的請求，並在所述請求中攜帶所述指定業務對象所屬的第一用戶標識，所述指定業務對象SKU標識，以及第二用戶的收貨地址相關信息；以便所述前端伺服器將所述請求轉發至庫存中心伺服器，由所述庫存中心伺服器確定所述第一用戶的所述指定業務對象SKU對應的倉庫資源信息，該對應的倉庫資源信息包括虛擬倉庫資源信息，所述虛擬倉庫資源信息中，目標第一類型實體倉庫資源與至少一個目標第二類型實體倉庫資源建立共享關聯關係，所述虛擬倉庫資源繼承所述目標第一類型實體倉庫資源的配送範圍；所述共享關聯關係為：當所述目標第一類型實體倉庫資源中的庫存不足時，利用所述目標第二類型實體倉庫資源為所述目標第一類型實體倉庫資源進行補貨；利用所述第二用 戶的收貨地址相關信息與所述對應的倉庫資源的配送範圍信息進行匹配運算；如果所述虛擬倉庫資源信息匹配成功，則確定所述虛擬倉庫資源中的庫存並返回；庫存信息提供單元804，用於根據所述前端伺服器返回的信息，提供所述指定業務對象SKU庫存信息。具體實現時，該裝置還可以包括：購買指令接收單元，用於接收到購買所述指定業務對象SKU的指令時，向所述前端伺服器發送生成交易訂單的請求，以便所述前端伺服器向庫存中心伺服器獲取倉庫資源標識信息，並在生成交易訂單時，將所述倉庫資源標識信息記錄在所述交易訂單的前置路由信息中；其中，該記錄的倉庫資源標識信息包括虛擬倉庫資源的標識信息。通過本申請實施例，可以重構商家倉(第二類型實體倉庫資源)和菜鳥倉網絡(第一類型實體倉庫資源)，以菜鳥倉為核心，商家倉附屬於附近的菜鳥倉，商家倉的庫存共享給菜鳥倉，同時可以快速補貨到菜鳥倉，同時共享庫存可以在電商領域銷售，在一定程度上提升了菜鳥倉庫存存放的合理度，同時減少由於菜鳥倉鋪貨不準引起的消費者流失。另一方面，能夠平衡商家倉的庫存和菜鳥倉的庫存，給商家最優的庫存分布網絡。同時，繼續走4PL的物流配送體系，也即，即使商家倉可售，也需要將貨品發送到菜鳥倉之後，才能進行統一的發貨，給商家最優的供應鏈鋪貨解決方案，也使得買家用戶繼續獲得高質量的服務。通過以上的實施方式的描述可知，本領域的技術人員可以清楚地了解到本申請可藉助軟體加必需的通用硬體平臺的方式來實現。基於這樣的理解，本申請的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟體產品的形式體現出來，該計算機軟體產品可以存儲在存儲介質中，如ROM/RAM、磁碟、光碟等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，伺服器，或者網絡設備等)執行本申請各個實施例或者實施例的某些部分所述的方法。本說明書中的各個實施例均採用遞進的方式描述，各個實施例之間相同相 似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對於系統或系統實施例而言，由於其基本相似於方法實施例，所以描述得比較簡單，相關之處參見方法實施例的部分說明即可。以上所描述的系統及系統實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位於一個地方，或者也可以分布到多個網絡單元上。可以根據實際的需要選擇其中的部分或者全部模塊來實現本實施例方案的目的。本領域普通技術人員在不付出創造性勞動的情況下，即可以理解並實施。以上對本申請所提供的倉庫資源信息處理、提供庫存信息的方法及裝置，進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用於幫助理解本申請的方法及其核心思想；同時，對於本領域的一般技術人員，依據本申請的思想，在具體實施方式及應用範圍上均會有改變之處。綜上所述，本說明書內容不應理解為對本申請的限制。當前第1頁1 2 3