本申請涉及商品對象信息處理技術領域，特別是涉及商品對象預售信息處理方法及裝置。

背景技術：

電商銷售平臺的銷售模式大致可以分為普通銷售和預售兩種，其中，普通銷售要求倉庫中必須有庫存才可售賣，預售則并不強制倉庫有庫存。預售一般包含定金和尾款兩個階段，定金階段用戶可以付定金，鎖定商品購買需求；尾款階段，用戶可以付尾款，付完尾款的訂單，銷售平臺需要按訂單合約要求發(fā)貨。預售模式是一種比較有吸引力的銷售模式，具體體現(xiàn)在：預售模式允許商家貨品延遲入倉，并且入倉的數(shù)量和消費需求非常接近，從而可以降低庫存周轉(zhuǎn)周期，提升庫存周轉(zhuǎn)率，降低倉儲成本，因此對商家來說非常有吸引力。從消費者角度而言，可以滿足用戶個性化的需求，并且通常情況下相同商品的預售價格是相對有競爭力的，因此，對于消費者也有很大的吸引力。

雖然商品預售對商家、消費者都是一種不錯的銷售模式，但該模式在實際的運作中也存在一定的問題，具體描述如下：預售時貨品無需入倉即可售賣，但如果預售的商品需求量超過商家的供貨能力，則會導致無法按要求履行訂單合約，即發(fā)生業(yè)務超賣的風險，這在活動場景下(尤其是雙11活動等)尤為突出。

例如，在電商平臺中為了支持靈活的營銷模式，商品被劃分成前端和后端商品，前端商品(寶貝)是直接面對消費者的；后端商品是倉庫中商品的直接映射。前后端商品之間是N:1的映射關系，即一個后端商品會被發(fā)布成若干個前端商品，每個前端商品可以采用不同的營銷模式，這在分銷場景中是非常常見的。在這種前后端商品模型下，即使商家可以較為準確地設置預售庫存數(shù)量，在實際運作中也會出現(xiàn)消費者付了定金但無貨可發(fā)的情況，即發(fā)生業(yè)務超賣。如：同一供應商的后端商品由三個分銷商進行分銷，每個分銷商可以發(fā)布各自 的前端商品SKU(Stock Keeping Unit，庫存量單位)，如SKU1、SKU2、SKU3。不同的分銷商可以對各自的SKU設置不同的營銷模式，如SKU1采用期貨預售方式，SKU2采用普通銷售方式，等等。假設供貨商準確的預估了期貨預售的規(guī)模并設置了預售商品數(shù)量，即SKU1在期貨預售期間的銷量，但由于SKU2采用普通銷售模式，它可以將本來用于期貨預售的庫存份額直接發(fā)貨，導致SKU1在消費者付完尾款后無貨可發(fā)。

技術實現(xiàn)要素：

本申請?zhí)峁┝松唐穼ο箢A售信息處理方法及裝置，能夠降低預售訂單合約無法履行等情況發(fā)生的概率。

本申請?zhí)峁┝巳缦路桨福?/p>

一種商品對象預售信息處理方法，包括：

預先確定與同一后端商品對象對應的至少一個前端商品對象；

在某前端商品對象被指定為預售對象時，為該前端商品對象及其對應的后端商品對象添加預置標識；

接收到瀏覽指定前端商品對象詳情信息的瀏覽請求時，判斷該指定前端商品對象對應的目標后端商品對象是否帶有所述預置標識；

如果所述目標后端商品對象帶有所述預置標識，則判斷該指定前端商品對象是否帶有所述預置標識；

如果該指定前端商品對象帶有所述預置標識，則根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息，否則，將可售庫存數(shù)量置為預置數(shù)目。

一種商品對象預售信息處理裝置，包括：

對應關系確定單元，用于預先確定與同一后端商品對象對應的至少一個前端商品對象；

標識添加單元，用于在某前端商品對象被指定為預售對象時，為該前端商品對象及其對應的后端商品對象添加預置標識；

第一標識判斷單元，用于接收到瀏覽指定前端商品對象詳情信息的瀏覽請求時，判斷該指定前端商品對象對應的目標后端商品對象是否帶有所述預置標識；

第二標識判斷單元，用于如果所述目標后端商品對象帶有所述預置標識，則判斷該指定前端商品對象是否帶有所述預置標識；

可售庫存信息提供單元，用于如果該指定前端商品對象帶有所述預置標識，則根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息，否則，將可售庫存數(shù)量置為預置數(shù)目。

根據(jù)本申請?zhí)峁┑木唧w實施例，本申請公開了以下技術效果：

通過本申請實施例，通過為參加預售活動的前端商品對象以及對應的后端商品對象添加預置標識，可以使得在接收到關于某前端商品對象的瀏覽請求時，可以判斷出當前被瀏覽的前端商品對象是否參加了預售活動，如果參加預售活動，則可以根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息，否則，如果當前被瀏覽的前端商品對象未參加預售活動，但是與其對應了同一后端商品對象的其他前端商品對象參加了預售活動，則可以將該當前被瀏覽的前端商品對象置為不可售，也即，將其可售商品對象數(shù)量置為預置數(shù)目，使得對應的前端商品對象處于限制銷售或者不可售狀態(tài)，因此，可以降低由于其他的銷售活動對實際庫存的占用或者消耗，導致預售訂單無法履行等情況發(fā)生的概率。

此外，還可以對預售庫存的設置、預約入庫、實際入庫、貨品調(diào)撥、貨品出庫等環(huán)節(jié)進行一系列的改進，使得訂單合約的履行得到進一步的保障。

當然，實施本申請的任一產(chǎn)品并不一定需要同時達到以上所述的所有優(yōu)點。

附圖說明

為了更清楚地說明本申請實施例或現(xiàn)有技術中的技術方案，下面將對實施 例中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的一些實施例，對于本領域普通技術人員來講，在不付出創(chuàng)造性勞動的前提下，還可以根據(jù)這些附圖獲得其他的附圖。

圖1是本申請實施例提供的方法的流程圖；

圖2是本申請實施例提供的裝置的示意圖。

具體實施方式

下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例?；诒旧暾堉械膶嵤├?，本領域普通技術人員所獲得的所有其他實施例，都屬于本申請保護的范圍。

在本申請實施例中，為了更好地支持預售場景，降低預售訂單合約無法履行的概率，可以從預售鏈條上的多個環(huán)節(jié)進行改進，例如，包括商家設置商品對象的預售庫存環(huán)節(jié)，為前端消費者用戶提供可售庫存環(huán)節(jié)，預約入庫環(huán)節(jié)，實際入庫環(huán)節(jié)，發(fā)貨環(huán)節(jié)，等等。下面進行詳細介紹。

參見圖1，本申請實施例首先提供了一種商品對象預售信息處理方法，該方法可以包括以下步驟：

S101：預先確定與同一后端商品對象對應的至少一個前端商品對象；

后端商品對象為供貨商發(fā)布的商品對象，平臺中的商家在需要加入分銷時，可以選擇供貨商發(fā)布的后端商品對象，并在自己的店鋪中發(fā)布前端商品對象。由于同一后端商品對象是可以由多個分銷商進行選擇的，因此，被不同分銷商選擇并發(fā)布的前端商品對象就會有多個，不同的分銷商可以為其發(fā)布的前端商品對象制定各自的銷售策略、價格等等。也就是說，對于消費者而言，其可能會在不同商家的店鋪中看到多個前端商品對象，其價格等可能會有所不同，但實際上對應的是同一供貨商的同一后端商品對象。

在具體實現(xiàn)時，電商系統(tǒng)通常會提供專用的分銷平臺，供貨商發(fā)布后端商 品對象，以及分銷商選擇后端商品對象，發(fā)布成前端商品對象等操作，都可以是基于該分銷平臺來進行的。因此，分銷平臺就可以從商品對象的維度，建立其供貨商與分銷商之間的關聯(lián)，進而，后端商品對象與前端商品對象之間的對應關系也可以建立起來。通常，后端商品對象與前端商品對象之間是一對多的關系，當然，在實際應用中，也存在一個后端商品對象僅對應一個前端商品對象的情況。

例如，某供貨商發(fā)布了某款后端商品對象為A，其中，分銷商甲選在選擇分銷商品時擇了A，并發(fā)布為前端商品對象SKU1，分銷商乙、丙也各自選擇了A，并分別發(fā)布為前端商品對象SKU2和SKU3，則，在該步驟中，就可以在后端商品對象A與SKU1、SKU2、SKU3之間建立起對應關系。

S102：在某前端商品對象被指定為預售對象時，為該前端商品對象及其對應的后端商品對象添加預置標識；

如果某分銷商將其前端商品對象指定為預售對象，則在本申請實施例中，可以為該前端商品對象以及對應的后端商品對象分別添加預置標識，該預置標識用于表明對應的商品對象需要進行防超賣處理。

例如，在前述例子中，后端商品對象A與SKU1、SKU2、SKU3之間具有對應關系，當其中的SKU1被指定為預售對象時，則可以為該SKU1以及其對應的后端商品對象A都添加預置的標識。

其中，無論是后端商品對象還是前端商品對象，在系統(tǒng)中保存時都分別對應著一條記錄，因此，添加標識時，就可以向?qū)挠涗洍l目中預置的字段填寫該預置的標識信息即可。

S103：接收到瀏覽指定前端商品對象詳情信息的瀏覽請求時，判斷該指定前端商品對象對應的目標后端商品對象是否帶有所述預置標識；

由于對參加預售活動的前端商品對象以及對應的后端商品對象添加了預置標識，因此，在預售活動開始后，就可以根據(jù)這種標識，來確定如何為買家用戶提供可售庫存信息。

具體的，在接收到瀏覽指定前端商品對象詳情信息的瀏覽請求時，可以首先判斷該指定前端商品對象對應的目標后端商品對象是否帶有所述預置標識。如果該目標后端商品對象不帶有預置標識，則證明其對應的所有前端商品對象都未參加預售活動，因此，按照倉庫中實際庫存數(shù)量向買家用戶提供可售庫存信息即可。也就是說，如果某供貨商的某后端商品對象，在某倉庫中有實際庫存100件，在接收到買家用戶瀏覽其對應的某前端商品對象的請求時，確定出該后端商品對象對應的各個前端商品對象均未參加預售，則按照普通銷售模式處理即可，也即，可以將該前端商品對象的可售庫存數(shù)量展示為100件。

S104：如果所述目標后端商品對象帶有所述預置標識，則判斷該指定前端商品對象是否帶有所述預置標識；

如果目標后端商品對象帶有所述預置標識，則代表其對應的至少一個前端商品對象參加了預售活動，此時，可以進一步判斷該指定前端商品對象是否帶有所述預置標識，也即，判斷當前被瀏覽的商品對象是否參加了預售活動。

S105：如果該指定前端商品對象帶有所述預置標識，則根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息，否則，則將可售庫存數(shù)量置為預置數(shù)目。

如果該指定前端商品對象帶有所述預置標識，則代表該前端商品對象參加了預售活動，此時，在向買家用戶提供可售庫存信息時，就可以將商家預先為該前端商品對象設置的預售庫存來確定，而不是倉庫中的實際庫存。例如，假設當前指定的前端商品對象為SKU1，經(jīng)判斷該SKU1帶有預置標識，則此時可以確定出分銷商為該SKU1設置的預售庫存，例如，假設為500件，則，在向買家用戶顯示可售庫存數(shù)量時，就可以根據(jù)該預售庫存進行確定。此時，可能倉庫中的實際庫存只有100件，但是由于是參加了預售活動，因此，可以不受實際庫存的影響，向買家用戶顯示的可售庫存數(shù)量，一般大于倉庫中關于該商品對象的實際庫存數(shù)量。例如，對于預售活動開始后尚未有預售訂單生成時，向買家用戶顯示的可售庫存數(shù)量就是預置的預售庫存的總數(shù)，也即500件，之后，隨著預售訂單的生成，就可以將預售庫存減去訂單中已經(jīng)被鎖定的庫存，得到當前的可售庫存數(shù)量。

當然，如果當前指定前端商品對象不帶有預置標識，則證明該前端商品對象未參加預售活動，但是，因為其對應的后端商品對象帶有預置標識，可以證明該后端商品對象對應的其他前端商品對象已經(jīng)參加了預售活動，因此，就可以將當前指定前端商品對象的可售庫存置為預置數(shù)目。該預置數(shù)目一般可以比較小，例如，在極端的情況下可以置為0。也就是說，在本申請實施例中，為了保障參加預售訂單的正常履行，在預售活動過程中，對于同一后端商品對象對應的其他未參加預售活動的前端商品對象，可以置為限制銷售或者不可售狀態(tài)，這樣，可以降低由于其他的銷售活動對實際庫存的占用或者消耗，導致預售訂單無法履行等情況發(fā)生的概率。

以上實施例一中，對為前端消費者用戶提供可售庫存環(huán)節(jié)進行了改進，通過為參加預售活動的前端商品對象以及對應的后端商品對象添加預置標識，可以使得在接收到關于某前端商品對象的瀏覽請求時，可以判斷出當前被瀏覽的前端商品對象是否參加了預售活動，如果參加預售活動，則可以根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息，否則，如果當前被瀏覽的前端商品對象未參加預售活動，但是與其對應了同一后端商品對象的其他前端商品對象參加了預售活動，則可以將該當前被瀏覽的前端商品對象置為不可售，也即，將其可售商品對象數(shù)量置為預置數(shù)目，使得對應的前端商品對象處于限制銷售或者不可售狀態(tài)，因此，可以降低由于其他的銷售活動對實際庫存的占用或者消耗，導致預售訂單無法履行等情況發(fā)生的概率。

在實際應用中，還可以從其他環(huán)節(jié)進行改進，以進一步保障預售訂單的正常履行。

首先，可以從預售庫存的設置方面進行改進。如前述實施例中步驟S105所述，如果當前被瀏覽的前端商品對象帶有預置標識，則可以根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息。其中，在現(xiàn)有技術中，預先為前端商品對象設置預售庫存時，通常是設置一個全局的預售庫存。例如，某前端商品對象SKU1，設置500件預售庫存，此時，在預售活動開始后，全國各地的買家用戶在對該SKU1進行預訂時，顯示出的可售庫存都只能根據(jù)該全局的預售庫存數(shù)量來確定。

但是，在實際應用中，物流服務提供的方的倉儲體系通常是一種層次化模型。例如，全國設置若干中心倉庫，每個中心倉庫下設若干子倉庫，一個中心倉庫下的子倉庫的覆蓋范圍的并集是該中心倉庫覆蓋范圍的子集。商家通常會預先訂購多個倉庫，這種倉庫一般分布在不同的區(qū)域，對應著不同的服務區(qū)域。在為買家用戶發(fā)貨時，通常是由具體的某個實體倉庫(例如，距離收貨地址最近的倉庫等)進行發(fā)貨，并執(zhí)行配送等相關物流服務。但是，由于買家用戶下定金時，商家的貨品并未入庫，預售后期商家集中入倉可能會由于倉庫的庫容等不足導致無法入庫。若在消費者付尾款前不能將足額的貨品入庫，則會影響訂單合約的正常履行。也就是說，在預先設置預售庫存的情況下，即便在消費者付尾款前，供貨商的貨源充足，也可能由于未能及時運送到發(fā)貨倉庫，或者運送到發(fā)貨倉庫后，發(fā)貨倉庫庫容不足導致無法入庫，進而導致預售訂單合約無法正常履行。

為此，在本申請實施例中，在商家進行預售庫存設置時，可以提供分別為各個倉庫設置不同的預售庫存的操作選項，這樣，每個倉庫對應著不同的預售庫存，后續(xù)在向各個倉庫進行補貨時，就可以以各個倉庫對應的預售庫存為依據(jù)，進行更合理的補貨，防止向其中某個倉庫補貨過多或者過少。在這種情況下，在向當前買家用戶提供可售庫存信息時，就可以首先確定出該買家用戶所在的區(qū)域信息，然后可以將該所在區(qū)域與當前商品對象對應的各個倉庫的服務區(qū)域進行匹配，進而就可以根據(jù)匹配成功的倉庫中該指定前端商品對象的預售庫存信息，提供可售庫存數(shù)量信息。

例如，當前瀏覽的前端商品對象為參加預售活動的SKU1，商家為該SKU1設置的預售庫存信息如以下表1所示：

表1

根據(jù)當前買家用戶所在終端設備的定位信息、IP地址信息、已登錄用戶的歷史常用收貨地址信息等，可以確定出當前買家用戶所在的區(qū)域，例如，確定為北京的用戶，則可以根據(jù)該SKU1在北京倉的預售庫存提供當前可售庫存。例如，北京倉已經(jīng)被鎖定的庫存為10件，則向當前買家用戶提供的可售庫存為200-10＝190件，等等。

其中，關于同一前端商品對象分別在各個倉庫中的預售庫存，可以是由商家根據(jù)經(jīng)驗等確定。當然，即使已經(jīng)精確到具體的倉庫進行預售庫存的設置，仍然不應該任意設置預售庫存數(shù)量，因為預售庫存設置過大，會導致供大于求，反之則供不應求，這兩種情況對商家來說均不是最優(yōu)的方案。為此，在本申請實施例中，還可以通過大數(shù)據(jù)分析、該商品對象在歷史銷售記錄中在各個區(qū)域的銷售情況等，對各個倉庫的預售數(shù)量進行預測，然后，可以根據(jù)預測的結果，向商家提供關于各個倉庫的預售庫存數(shù)量的推薦信息。這樣，商家可以根據(jù)該推薦信息，并結合自身的經(jīng)驗等，更精確地設置各個倉庫中的預售庫存。

以上所述為在預售活動開始前，進行預售庫存設置時提供的改進方案，而在預售活動開始后，供貨商可以開始向倉庫進行補貨，在補貨的過程中，本申請實施例也提供了相應的改進方案。

具體的，對于預售業(yè)務場景，補貨過程通常包括兩個步驟，首先是預約入庫，之后再進行實際入庫，通常情況下，不允許在沒有預約的情況下直接進行貨品入庫。在現(xiàn)有技術中，供貨方在提交預約入庫請求時，一般是直接接受其請求，生成預約入庫單，將單號提供給供貨方以及物流服務提供方，供實際入庫時使用。有些平臺中，在預約入庫過程中會考慮倉庫的收貨能力，但主要考慮倉庫的人力資源等因素，也即確定在收到貨品后，是否有足夠的人手完成入庫的操作。

但是，本申請發(fā)明人在實現(xiàn)本申請的過程中發(fā)現(xiàn)，即使在收到貨品時，倉庫有足夠的人手處理這批貨品，也還可能出現(xiàn)另一種情況，即倉庫的庫容不足， 也即無法容納下這批貨品，此時，仍然會影響貨品的入庫。因此，在本申請實施例中，還可以對預約入庫環(huán)節(jié)進行改進。

具體的，可以在接收指定前端商品對象進行貨品預約入庫的請求時，從該請求中提取出其攜帶的擬入倉庫標識、擬入庫日期、擬入庫貨品體積及數(shù)量，之后可以確定出該擬入倉庫在該擬入日期的庫存容量信息，并判斷該庫存容量是否滿足該擬入庫商品體積及數(shù)量的需求，如果滿足，則將擬入庫商品體積及數(shù)量對應的庫存容量進行鎖定，并生成預約入庫訂單，將該預約入庫訂單的標識信息提供給供貨方以及物流服務提供方。也就是說，假設收到預約入庫請求的日期是8月1日，請求中攜帶的擬入日期是8月11日，也就是說，供貨方預計在10天后向指定的倉庫(例如北京倉)進行補貨。此時，在本申請實施例中，可以首先確定出北京倉在8月11日的庫存容量是否滿足這批擬入貨品的需求，如果滿足，則可以接受該請求，否則，如果8月11日的庫存容量已不足，則可以通知供貨方請求失敗，該供貨方可以修改其擬入日期、貨品數(shù)量等，重新發(fā)起預約入庫請求。這樣，可以避免在供貨方將貨品運送到倉庫后，由于倉庫庫存容量不足導致的無法入庫等問題。

當然，在具體實現(xiàn)時，在判斷出擬入倉庫在擬入日期的庫存容量滿足要求的情況下，還可以增加人工核對的環(huán)節(jié)，對可能出現(xiàn)的異常情況進行排查，例如，某倉庫中的預售數(shù)量為200件，但是預約入庫請求中需要向該倉庫中入庫1000件，遠大于其預售庫存數(shù)量，因此，可以對其進行進一步的核查。

其中，對于擬入倉庫在擬入日期的庫存容量信息，可以通過多種方式確定，例如，其中一種方式下，可以首先確定擬入倉庫在當前日期的第一庫存容量(該信息可以是由物流服務提供方向平臺同步過來的)，然后，可以確定已經(jīng)被已生成的其他預約入庫訂單鎖定為在當前日期到擬入日期之間入庫的第二庫存容量。例如，仍然假設收到當前預約入庫請求的當前日期為8月1日，該請求的擬入日期為8月11日，而在7月25日生成的預約入庫訂單中，其擬入日期是8月2日，也即，在8月2日可能會有一批貨品被運送到該倉庫，使得該倉庫的庫存容量被占用，這批貨品所需的庫存容量已經(jīng)提前被鎖定，其他類似的預約入庫訂單可能還存在，因此，可以將從8月1日到8月11日之間被鎖定 的庫存容量從當前的庫存容量中扣除，優(yōu)先保證之前已經(jīng)接受的預約入庫請求能夠正常入庫。另外，擬入倉庫中通常還保存有其他貨品，每天還會由于部分貨品售出而釋放出一部分可用庫存，因此，還可以對所述擬入倉庫每天的銷售出庫量進行預測，并預測從當前日期到所述擬入日期之間的銷售出庫總量，這樣，在計算擬入倉庫在擬入日期的庫存容量時，可以用前述第一庫存容量減去所述第二庫存容量，再加上預測出的銷售出庫總量，就可以得到擬入倉庫在擬入日期的剩余庫存容量，如果剩余的庫存容量仍然能夠滿足當前預約入庫請求的需求，則可以接受該請求。

對于被接受的預約入庫請求，平臺可以生成預約入庫訂單，并將該訂單的標識，如訂單編碼等，發(fā)送給供貨方以及物流服務提供方，之后，供貨方就可以按照預約請求中的擬入日期進行實際入庫操作，在將貨品運送到倉庫時，可以提交貨品對應的預約入庫訂單標識，這樣，物流服務提供方可以在入庫完成后，將已入庫的預約入庫訂單標識同步到平臺，平臺對訂單狀態(tài)進行更新，并且可以更新倉庫的庫存容量等信息。

在現(xiàn)有技術中，供貨方需要嚴格按照擬入日期以及貨品體積、數(shù)量進行實際入庫，否則，倉庫方將拒絕入庫，避免造成信息同步過程中出錯。而在實際應用中，有些供貨方可能出于節(jié)省成本等目的，通過“捎帶”的方式對貨品進行實際入庫。例如，某預約入庫訂單中記錄的擬入日期是8月11日，但恰好在8月10日有另一批貨品也會被運送到同樣的擬入倉庫，而且運輸車輛有額外的運力，于是，可能會需要將原定于8月11日的貨品也“捎帶”上。此時，如果按照現(xiàn)有技術的方式，供貨方即使捎帶上了貨品，也無法完成實際入庫，因為實際入庫日期與擬入日期不一致。顯然，這種方式不夠友好，并且也不利于供貨商及時向倉庫中補貨。

為了給供貨方提供更大的便利，更好的履行預約訂單合約，在本申請實施例中，在實際入庫的過程中也可以進行改進。具體的，在供貨方向物流服務提供方進行實際入庫操作時，可以接收物流服務提供方提交的實際入庫通知消息，該通知消息中可以攜帶有預約入庫訂單的標識信息，以及實際入庫的貨品體積以及數(shù)量信息，之后，可以判斷接收到該通知消息的當前日期與該預約入庫訂 單中記錄的擬入日期是否相同。如果不相同，則還可以確定出該預約入庫訂單中的擬入倉庫在該當前日期的庫存容量信息(該庫存容量信息一般是由物流服務提供方同步過來的，另外，還可以減去該當前日期被鎖定的庫存容量)，之后，就可以判斷該庫存容量是否滿足當前的實際入庫商品體積及數(shù)量的需求，也即判斷擬入倉庫在當前日期是否仍然有額外的庫存容量，能夠供這部分貨品使用，如果有，則可以生成允許入庫的通知消息，并返回給物流服務提供方，這樣，物流服務提供方就可以執(zhí)行具體的入庫操作。在入庫完成后，可以接收物流服務提供方提交的實際入庫成功的通知消息，然后，可以根據(jù)該通知消息更新對應倉庫的庫存容量，并將對應的預約入庫訂單的狀態(tài)進行更新，例如，將該預約入庫單鎖定的庫存容量進行釋放。

以上所述是在預約入庫以及實際入庫環(huán)節(jié)上進行的改進，通過平臺與物流服務提供方的信息互通共享以及系統(tǒng)聯(lián)動，提高了入庫操作效率和操作靈活性。而在買家用戶選定了某預售的前端商品對象，就可以生成對應的交易訂單，在買家用戶完成定金支付后，之后需要考慮的問題即為物流時效問題，因為是影響消費者物流體驗的一個重要因素。而期貨預售包含定金期和尾款期兩個階段，定金期無需發(fā)貨，只要在付完尾款后才需發(fā)貨，因此可以結合預售業(yè)務特點來提升物流時效。貨品距離消費者越近則物流時效無疑會越好，因此，在本申請實施例中，還可以在貨品調(diào)撥環(huán)節(jié)上也可以進行改進，通過精確的數(shù)據(jù)分析來指導將貨品調(diào)撥到距離消費者最近的倉庫。

具體的，如前文所述，物流服務提供方的倉儲體系通常是一種層次化模型，例如，全國設置若干中心倉庫，每個中心倉庫下設若干子倉庫，一個中心倉庫下的子倉庫的覆蓋范圍的并集是該中心倉庫覆蓋范圍的子集，等等。供貨方在向倉庫補貨時，通常只會到一級或者二級倉庫中，例如，省級或者市級的倉庫，市級以下可能還包括多個子倉庫，而對這些子倉庫的補貨，通常要由物流服務提供方通過調(diào)撥的方式來進行。另外，對于同一級別的倉庫，也可能會根據(jù)實際銷售情況，由物流服務提供方進行倉庫間的調(diào)撥，等等。預先完成貨品的調(diào)撥，有利于更好的履行預約訂單合約。

為此，在本申請實施例中，在接收到針對指定前端商品對象完成支付定金 操作的消息時，可以從對應的交易訂單中提取需購買的商品對象數(shù)量以及收貨地址信息，然后，可以將該收貨地址與各個倉庫的服務區(qū)域進行匹配，確定出最佳發(fā)貨倉庫。需要說明的是，由于預售活動的定金期一般比較長，供貨方是在定金期內(nèi)向具體的倉庫進行補貨，因此，在買家用戶付定金時，各個倉庫中還不一定有實際的庫存，因此，此時在確定最佳發(fā)貨倉庫時，可以不必考慮實際庫存信息，而是僅僅從距離等角度出發(fā)，確定出最佳的發(fā)貨倉庫。例如，對于北京的用戶，最佳的發(fā)貨倉庫為北京倉，但此時北京倉中可能還不存在該商品對象的實體庫存，等等。

在確定出最佳發(fā)貨倉庫后，可以將該交易訂單關聯(lián)的商品對象標識、數(shù)量關聯(lián)到該最佳發(fā)貨倉庫，之后，可以將預置周期內(nèi)的各個交易訂單對應的商品對象數(shù)量以及最佳發(fā)貨倉庫進行匯總，生成調(diào)撥建議信息。例如，一天為一個周期，則可以將一天以內(nèi)生成的交易訂單關聯(lián)的商品對象標識、數(shù)量，以及確定出的最佳發(fā)貨倉庫進行匯總。例如，某第一交易訂單關聯(lián)的前端商品對象為SKU1，數(shù)量為3件，最佳發(fā)貨倉庫為北京倉，第二交易訂單關聯(lián)的前端商品對象也為SKU1，數(shù)量為5件，最佳發(fā)貨倉庫也為北京倉，則可以建議向北京倉調(diào)入8件該SKU1對應的貨品。也就是說，調(diào)撥建議信息中可以包括調(diào)入倉庫、調(diào)撥商品對象標識以及調(diào)撥數(shù)量。其中，調(diào)入倉庫即為確定出的最佳發(fā)貨倉庫。

另外，該建議信息中還可以包括調(diào)出倉庫信息，具體的，如前文所述，物流服務提供方的倉儲體系可能是一種層級化的結構，因此，調(diào)出倉庫可以是服務區(qū)域涵蓋調(diào)入倉庫服務區(qū)域的上級倉庫。例如，假設最佳發(fā)貨倉庫為北京東城倉庫，該倉庫的上級倉庫為北京倉，則可以將北京倉確定為調(diào)出倉庫，北京東城倉庫確定為調(diào)入倉庫，等等。

該調(diào)撥建議信息可以是定期生成的，例如，每天18點針對當天的訂單情況生成調(diào)撥建議信息，并且可以向物流服務提供方發(fā)送。需要說明的是，該調(diào)撥建議信息在發(fā)送到物流服務提供方后，物流服務提供方可能并不是馬上執(zhí)行調(diào)撥操作，這是因為，由于供貨方的補貨行為是在預售活動開始后才進行的，因此，在收到調(diào)撥建議信息時，供貨方可能尚未補貨，也即調(diào)出倉庫中可能也 還沒有相應的實際庫存，無法進行調(diào)撥，或者，也可能是因為物流服務提供方的運力無剩余，等等。這種情況是允許存在的，這是因為定金期一般會比較長，只要在定金期完成調(diào)撥即可。也就是說，物流服務提供方在收到調(diào)撥建議信息后，可以將其作為參考，在具體進行調(diào)撥時，可以將已經(jīng)收到的多條調(diào)撥建議信息進行匯總，執(zhí)行具體的調(diào)撥操作。

在定金期即將結束，也即即將進入尾款期，可以針對訂單確定出實際的發(fā)貨倉庫。在本申請實施例中，針對該過程也進行了相應的改進。具體的，在預售的定金期即將結束時，可以根據(jù)定金期內(nèi)生成的交易訂單，從中提取需購買的商品對象數(shù)量以及收貨地址信息，然后，將該收貨地址與各個倉庫的服務區(qū)域進行匹配，確定區(qū)域匹配成功的至少一個倉庫，然后，可以確定匹配成功的至少一個倉庫的實際庫存信息，判斷與收貨地址匹配度最高的第一倉庫的實際庫存是否充足，如果充足，則將該第一倉庫確定為實際發(fā)貨倉庫，并將該第一倉庫標識提供給物流服務提供方。匹配度最好的第一倉庫，也即前文所述最佳發(fā)貨倉庫，也就是說，如果在實際需要發(fā)貨時，最佳發(fā)貨倉庫中的庫存充足，則可以直接從該倉庫發(fā)貨。而如果該第一倉庫庫存不足，則在本申請實施例中，還可以從區(qū)域匹配成功的倉庫中確定出服務區(qū)域涵蓋該第一倉庫服務區(qū)域的第二倉庫，并判斷該第二倉庫的實際庫存是否充足，如果充足，則將該第二倉庫確定為實際發(fā)貨倉庫，并將該第二倉庫標識提供給物流服務提供方。例如，假設根據(jù)某訂單的收貨地址，確定出第一倉庫為北京東城倉庫，但是，該倉庫的實際庫存可能并不充足，此時，為了能夠正常履行該訂單合約，可以從該倉庫的上級倉庫，例如北京倉發(fā)貨，以此保證買家用戶能夠及時收到貨品。

也就是說，在本申請實施例中，雖然從貨品入庫、調(diào)撥等環(huán)節(jié)都可以進行優(yōu)化，但在實際應用中，可能仍然會存在某些倉庫中補貨不足的情況，針對這種情況，為了確保訂單合約的履行，可以采用由上級倉庫直接發(fā)貨的方式。

需要說明的是，是否從上級倉發(fā)貨可以是由開關控制的，比如在預售快要結束時，則允許上級倉發(fā)貨；在預售前期則不允許，這時系統(tǒng)會重試直到貨物調(diào)撥到最佳發(fā)貨倉庫。

總之，在本申請實施例中，針對預售業(yè)務場景，可以從預售庫存的設置、 預約入庫、實際入庫、詳情瀏覽、貨品調(diào)撥、發(fā)貨等多個環(huán)節(jié)進行優(yōu)化，最終降低預售訂單合約無法履行的概率。當然，在實際應用中，以上各個環(huán)節(jié)的優(yōu)化是可以獨立存在的，或者，也可以對部分環(huán)節(jié)進行優(yōu)化，都可以從一定程度上達到上述目的。

與前述實施例中提供的商品對象預售信息處理方法相對應，本申請實施例還提供了一種商品對象預售信息處理裝置，參見圖2，該裝置可以包括：

對應關系確定單元201，用于預先確定與同一后端商品對象對應的至少一個前端商品對象；

標識添加單元202，用于在某前端商品對象被指定為為預售對象時，為該前端商品對象及其對應的后端商品對象添加預置標識；

第一標識判斷單元203，用于接收到瀏覽指定前端商品對象詳情信息的瀏覽請求時，判斷該指定前端商品對象對應的目標后端商品對象是否帶有所述預置標識；

第二標識判斷單元204，用于如果所述目標后端商品對象帶有所述預置標識，則判斷該指定前端商品對象是否帶有所述預置標識；

可售庫存信息提供單元205，用于如果該指定前端商品對象帶有所述預置標識，則根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供可售庫存數(shù)量信息，否則，將可售庫存數(shù)量置為預置數(shù)目。

其中，所述預先為該指定前端商品對象設置的預售庫存信息包括，預先為該指定前端商品對象關聯(lián)的至少一個倉庫分別設置的預售庫存信息；其中，各個倉庫對應不同的服務區(qū)域；

此時，所述可售庫存信息提供單元包括：

區(qū)域確定子單元，用于確定所述瀏覽請求的發(fā)出方所在的區(qū)域信息；

提供子單元，用于將該所在區(qū)域與各個倉庫的服務區(qū)域進行匹配，根據(jù)匹 配成功的倉庫中該指定前端商品對象的預售庫存信息，提供可售庫存數(shù)量信息。

具體實現(xiàn)時，該裝置還可以包括：

預測單元，用于對所述指定前端商品對象在各個服務區(qū)域的銷售數(shù)量進行預測；

預售庫存推薦單元，用于根據(jù)預測結果提供關于各個倉庫的預售庫存數(shù)量的推薦信息。

另外，還可以在預約入庫以及實際入庫階段進行改進，具體的，該裝置還可以包括：

預約入庫請求接收單元，用于接收對所述指定前端商品對象進行貨品預約入庫的請求，該請求中攜帶有擬入倉庫標識、擬入庫日期、擬入庫貨品體積及數(shù)量；

庫存容量確定單元，用于確定所述擬入倉庫在所述擬入日期的庫存容量信息；

庫存需求判斷單元，用于判斷所述庫存容量是否滿足所述擬入庫商品體積及數(shù)量的需求；

鎖定單元，用于如果滿足，則將所述擬入庫商品體積及數(shù)量對應的庫存容量進行鎖定，并生成預約入庫訂單，將該預約入庫訂單的標識信息提供給供貨方以及物流服務提供方。

其中，所述庫存容量確定單元包括：

第一庫存容量確定子單元，用于確定所述擬入倉庫在當前日期的第一庫存容量；

第二庫存容量確定子單元，用于確定已經(jīng)被已生成的其他預約入庫訂單鎖定為在當前日期到所述擬入日期之間入庫的第二庫存容量；

計算子單元，用于將所述第一庫存容量減去所述第二庫存容量，確定為所述擬入倉庫在所述擬入日期的庫存容量信息。

另外，還可以包括：

實際入庫通知接收單元，用于在供貨方向所述物流服務提供方進行實際入庫操作時，接收所述物流服務提供方提交的實際入庫通知消息，所述通知消息中攜帶有所述預約入庫訂單的標識信息，以及實際入庫的貨品體積以及數(shù)量信息；

日期判斷單元，用于判斷接收到該通知消息的當前日期與所述預約入庫訂單中記錄的擬入日期是否相同；

當前庫存容量確定單元，用于如果不相同，則確定所述擬入倉庫在該當前日期的庫存容量信息；

庫存需求判斷單元，用于判斷該庫存容量是否滿足所述實際入庫商品體積及數(shù)量的需求；

允許入庫通知單元，用于如果滿足，則生成允許入庫的通知消息，并返回給所述物流服務提供方。

在入庫成功后，物流服務提供方可以返回通知消息，此時，該裝置還可以包括：

入庫成功通知接收單元，用于接收所述物流服務提供方提交的實際入庫成功的通知消息；

狀態(tài)更新單元，用于根據(jù)該通知消息更新對應倉庫的庫存容量，并將對應的預約入庫訂單的狀態(tài)進行更新。

在貨品調(diào)撥環(huán)節(jié)，該裝置還可以包括：

第一信息提取單元，用于接收到針對所述指定前端商品對象完成支付定金操作的消息時，從對應的交易訂單中提取需購買的商品對象數(shù)量以及收貨地址信息；

最佳發(fā)貨倉庫確定單元，用于將所述收貨地址與各個倉庫的服務區(qū)域進行匹配，確定出最佳發(fā)貨倉庫；

調(diào)撥建議信息生成單元，用于將預置周期內(nèi)的各個交易訂單對應的商品對象數(shù)量以及最佳發(fā)貨倉庫進行匯總，生成調(diào)撥建議信息，所述調(diào)撥建議信息包括調(diào)出倉庫、調(diào)入倉庫、調(diào)撥商品對象標識以及調(diào)撥數(shù)量；其中，所述調(diào)入倉庫為所述最佳發(fā)貨倉庫，所述調(diào)出倉庫包括與服務區(qū)域涵蓋所述最佳發(fā)貨倉庫服務區(qū)域的上級倉庫；

調(diào)撥建議信息提供單元，用于將所述調(diào)撥建議信息提供給物流服務提供方。

在實際發(fā)貨環(huán)節(jié)，該裝置還可以包括：

第二信息提取單元，用于在預售的定金期結束后，根據(jù)定金期內(nèi)生成的交易訂單，從中提取需購買的商品對象數(shù)量以及收貨地址信息；

區(qū)域匹配單元，用于將所述收貨地址與各個倉庫的服務區(qū)域進行匹配，確定區(qū)域匹配成功的至少一個倉庫；

實際庫存信息確定單元，用于確定所述匹配成功的至少一個倉庫的實際庫存信息；

實際庫存判斷單元，用于判斷與所述收貨地址匹配度最高的第一倉庫的實際庫存是否充足；

第一實際發(fā)貨倉庫確定單元，用于如果充足，則將該第一倉庫確定為實際發(fā)貨倉庫，并將該第一倉庫標識提供給物流服務提供方。

倉庫區(qū)域確定單元，用于如果第一倉庫的實際庫存不充足，則從所述區(qū)域匹配成功的倉庫中確定服務區(qū)域涵蓋所述第一倉庫服務區(qū)域的第二倉庫；

第二實際發(fā)貨倉庫確定單元，用于判斷該第二倉庫的實際庫存是否充足，如果充足，則將該第二倉庫確定為實際發(fā)貨倉庫，并將該第二倉庫標識提供給物流服務提供方。

總之，通過本申請實施例，通過為參加預售活動的前端商品對象以及對應的后端商品對象添加預置標識，可以使得在接收到關于某前端商品對象的瀏覽請求時，可以判斷出當前被瀏覽的前端商品對象是否參加了預售活動，如果參加預售活動，則可以根據(jù)預先為該指定前端商品對象設置的預售庫存信息提供 可售庫存數(shù)量信息，否則，如果當前被瀏覽的前端商品對象未參加預售活動，但是與其對應了同一后端商品對象的其他前端商品對象參加了預售活動，則可以將該當前被瀏覽的前端商品對象置為不可售，也即，將其可售商品對象數(shù)量置為預置數(shù)目，使得對應的前端商品對象處于限制銷售或者不可售狀態(tài)，因此，可以降低由于其他的銷售活動對實際庫存的占用或者消耗，導致預售訂單無法履行等情況發(fā)生的概率。

此外，還可以對預售庫存的設置、預約入庫、實際入庫、貨品調(diào)撥、貨品出庫等環(huán)節(jié)進行一系列的改進，使得訂單合約的履行得到進一步的保障。

通過以上的實施方式的描述可知，本領域的技術人員可以清楚地了解到本申請可借助軟件加必需的通用硬件平臺的方式來實現(xiàn)。基于這樣的理解，本申請的技術方案本質(zhì)上或者說對現(xiàn)有技術做出貢獻的部分可以以軟件產(chǎn)品的形式體現(xiàn)出來，該計算機軟件產(chǎn)品可以存儲在存儲介質(zhì)中，如ROM/RAM、磁碟、光盤等，包括若干指令用以使得一臺計算機設備(可以是個人計算機，服務器，或者網(wǎng)絡設備等)執(zhí)行本申請各個實施例或者實施例的某些部分所述的方法。

本說明書中的各個實施例均采用遞進的方式描述，各個實施例之間相同相似的部分互相參見即可，每個實施例重點說明的都是與其他實施例的不同之處。尤其，對于系統(tǒng)或系統(tǒng)實施例而言，由于其基本相似于方法實施例，所以描述得比較簡單，相關之處參見方法實施例的部分說明即可。以上所描述的系統(tǒng)及系統(tǒng)實施例僅僅是示意性的，其中所述作為分離部件說明的單元可以是或者也可以不是物理上分開的，作為單元顯示的部件可以是或者也可以不是物理單元，即可以位于一個地方，或者也可以分布到多個網(wǎng)絡單元上?？梢愿鶕?jù)實際的需要選擇其中的部分或者全部模塊來實現(xiàn)本實施例方案的目的。本領域普通技術人員在不付出創(chuàng)造性勞動的情況下，即可以理解并實施。

以上對本申請所提供的商品對象預售信息處理方法及裝置，進行了詳細介紹，本文中應用了具體個例對本申請的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本申請的方法及其核心思想；同時，對于本領域的一般技術人員，依據(jù)本申請的思想，在具體實施方式及應用范圍上均會有改變之處。綜上所述，本說明書內(nèi)容不應理解為對本申請的限制。