商品对象预售信息处理方法及装置与流程

本申请涉及商品对象信息处理技术领域，特别是涉及商品对象预售信息处理方法及装置。

背景技术：

电商销售平台的销售模式大致可以分为普通销售和预售两种，其中，普通销售要求仓库中必须有库存才可售卖，预售则并不强制仓库有库存。预售一般包含定金和尾款两个阶段，定金阶段用户可以付定金，锁定商品购买需求；尾款阶段，用户可以付尾款，付完尾款的订单，销售平台需要按订单合约要求发货。预售模式是一种比较有吸引力的销售模式，具体体现在：预售模式允许商家货品延迟入仓，并且入仓的数量和消费需求非常接近，从而可以降低库存周转周期，提升库存周转率，降低仓储成本，因此对商家来说非常有吸引力。从消费者角度而言，可以满足用户个性化的需求，并且通常情况下相同商品的预售价格是相对有竞争力的，因此，对于消费者也有很大的吸引力。

虽然商品预售对商家、消费者都是一种不错的销售模式，但该模式在实际的运作中也存在一定的问题，具体描述如下：预售时货品无需入仓即可售卖，但如果预售的商品需求量超过商家的供货能力，则会导致无法按要求履行订单合约，即发生业务超卖的风险，这在活动场景下(尤其是双11活动等)尤为突出。

例如，在电商平台中为了支持灵活的营销模式，商品被划分成前端和后端商品，前端商品(宝贝)是直接面对消费者的；后端商品是仓库中商品的直接映射。前后端商品之间是N:1的映射关系，即一个后端商品会被发布成若干个前端商品，每个前端商品可以采用不同的营销模式，这在分销场景中是非常常见的。在这种前后端商品模型下，即使商家可以较为准确地设置预售库存数量，在实际运作中也会出现消费者付了定金但无货可发的情况，即发生业务超卖。如：同一供应商的后端商品由三个分销商进行分销，每个分销商可以发布各自 的前端商品SKU(Stock Keeping Unit，库存量单位)，如SKU1、SKU2、SKU3。不同的分销商可以对各自的SKU设置不同的营销模式，如SKU1采用期货预售方式，SKU2采用普通销售方式，等等。假设供货商准确的预估了期货预售的规模并设置了预售商品数量，即SKU1在期货预售期间的销量，但由于SKU2采用普通销售模式，它可以将本来用于期货预售的库存份额直接发货，导致SKU1在消费者付完尾款后无货可发。

技术实现要素：

本申请提供了商品对象预售信息处理方法及装置，能够降低预售订单合约无法履行等情况发生的概率。

本申请提供了如下方案：

一种商品对象预售信息处理方法，包括：

预先确定与同一后端商品对象对应的至少一个前端商品对象；

在某前端商品对象被指定为预售对象时，为该前端商品对象及其对应的后端商品对象添加预置标识；

接收到浏览指定前端商品对象详情信息的浏览请求时，判断该指定前端商品对象对应的目标后端商品对象是否带有所述预置标识；

如果所述目标后端商品对象带有所述预置标识，则判断该指定前端商品对象是否带有所述预置标识；

如果该指定前端商品对象带有所述预置标识，则根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息，否则，将可售库存数量置为预置数目。

一种商品对象预售信息处理装置，包括：

对应关系确定单元，用于预先确定与同一后端商品对象对应的至少一个前端商品对象；

标识添加单元，用于在某前端商品对象被指定为预售对象时，为该前端商品对象及其对应的后端商品对象添加预置标识；

第一标识判断单元，用于接收到浏览指定前端商品对象详情信息的浏览请求时，判断该指定前端商品对象对应的目标后端商品对象是否带有所述预置标识；

第二标识判断单元，用于如果所述目标后端商品对象带有所述预置标识，则判断该指定前端商品对象是否带有所述预置标识；

可售库存信息提供单元，用于如果该指定前端商品对象带有所述预置标识，则根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息，否则，将可售库存数量置为预置数目。

根据本申请提供的具体实施例，本申请公开了以下技术效果：

通过本申请实施例，通过为参加预售活动的前端商品对象以及对应的后端商品对象添加预置标识，可以使得在接收到关于某前端商品对象的浏览请求时，可以判断出当前被浏览的前端商品对象是否参加了预售活动，如果参加预售活动，则可以根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息，否则，如果当前被浏览的前端商品对象未参加预售活动，但是与其对应了同一后端商品对象的其他前端商品对象参加了预售活动，则可以将该当前被浏览的前端商品对象置为不可售，也即，将其可售商品对象数量置为预置数目，使得对应的前端商品对象处于限制销售或者不可售状态，因此，可以降低由于其他的销售活动对实际库存的占用或者消耗，导致预售订单无法履行等情况发生的概率。

此外，还可以对预售库存的设置、预约入库、实际入库、货品调拨、货品出库等环节进行一系列的改进，使得订单合约的履行得到进一步的保障。

当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施 例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的方法的流程图；

图2是本申请实施例提供的装置的示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。

在本申请实施例中，为了更好地支持预售场景，降低预售订单合约无法履行的概率，可以从预售链条上的多个环节进行改进，例如，包括商家设置商品对象的预售库存环节，为前端消费者用户提供可售库存环节，预约入库环节，实际入库环节，发货环节，等等。下面进行详细介绍。

参见图1，本申请实施例首先提供了一种商品对象预售信息处理方法，该方法可以包括以下步骤：

S101：预先确定与同一后端商品对象对应的至少一个前端商品对象；

后端商品对象为供货商发布的商品对象，平台中的商家在需要加入分销时，可以选择供货商发布的后端商品对象，并在自己的店铺中发布前端商品对象。由于同一后端商品对象是可以由多个分销商进行选择的，因此，被不同分销商选择并发布的前端商品对象就会有多个，不同的分销商可以为其发布的前端商品对象制定各自的销售策略、价格等等。也就是说，对于消费者而言，其可能会在不同商家的店铺中看到多个前端商品对象，其价格等可能会有所不同，但实际上对应的是同一供货商的同一后端商品对象。

在具体实现时，电商系统通常会提供专用的分销平台，供货商发布后端商 品对象，以及分销商选择后端商品对象，发布成前端商品对象等操作，都可以是基于该分销平台来进行的。因此，分销平台就可以从商品对象的维度，建立其供货商与分销商之间的关联，进而，后端商品对象与前端商品对象之间的对应关系也可以建立起来。通常，后端商品对象与前端商品对象之间是一对多的关系，当然，在实际应用中，也存在一个后端商品对象仅对应一个前端商品对象的情况。

例如，某供货商发布了某款后端商品对象为A，其中，分销商甲选在选择分销商品时择了A，并发布为前端商品对象SKU1，分销商乙、丙也各自选择了A，并分别发布为前端商品对象SKU2和SKU3，则，在该步骤中，就可以在后端商品对象A与SKU1、SKU2、SKU3之间建立起对应关系。

S102：在某前端商品对象被指定为预售对象时，为该前端商品对象及其对应的后端商品对象添加预置标识；

如果某分销商将其前端商品对象指定为预售对象，则在本申请实施例中，可以为该前端商品对象以及对应的后端商品对象分别添加预置标识，该预置标识用于表明对应的商品对象需要进行防超卖处理。

例如，在前述例子中，后端商品对象A与SKU1、SKU2、SKU3之间具有对应关系，当其中的SKU1被指定为预售对象时，则可以为该SKU1以及其对应的后端商品对象A都添加预置的标识。

其中，无论是后端商品对象还是前端商品对象，在系统中保存时都分别对应着一条记录，因此，添加标识时，就可以向对应的记录条目中预置的字段填写该预置的标识信息即可。

S103：接收到浏览指定前端商品对象详情信息的浏览请求时，判断该指定前端商品对象对应的目标后端商品对象是否带有所述预置标识；

由于对参加预售活动的前端商品对象以及对应的后端商品对象添加了预置标识，因此，在预售活动开始后，就可以根据这种标识，来确定如何为买家用户提供可售库存信息。

具体的，在接收到浏览指定前端商品对象详情信息的浏览请求时，可以首先判断该指定前端商品对象对应的目标后端商品对象是否带有所述预置标识。如果该目标后端商品对象不带有预置标识，则证明其对应的所有前端商品对象都未参加预售活动，因此，按照仓库中实际库存数量向买家用户提供可售库存信息即可。也就是说，如果某供货商的某后端商品对象，在某仓库中有实际库存100件，在接收到买家用户浏览其对应的某前端商品对象的请求时，确定出该后端商品对象对应的各个前端商品对象均未参加预售，则按照普通销售模式处理即可，也即，可以将该前端商品对象的可售库存数量展示为100件。

S104：如果所述目标后端商品对象带有所述预置标识，则判断该指定前端商品对象是否带有所述预置标识；

如果目标后端商品对象带有所述预置标识，则代表其对应的至少一个前端商品对象参加了预售活动，此时，可以进一步判断该指定前端商品对象是否带有所述预置标识，也即，判断当前被浏览的商品对象是否参加了预售活动。

S105：如果该指定前端商品对象带有所述预置标识，则根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息，否则，则将可售库存数量置为预置数目。

如果该指定前端商品对象带有所述预置标识，则代表该前端商品对象参加了预售活动，此时，在向买家用户提供可售库存信息时，就可以将商家预先为该前端商品对象设置的预售库存来确定，而不是仓库中的实际库存。例如，假设当前指定的前端商品对象为SKU1，经判断该SKU1带有预置标识，则此时可以确定出分销商为该SKU1设置的预售库存，例如，假设为500件，则，在向买家用户显示可售库存数量时，就可以根据该预售库存进行确定。此时，可能仓库中的实际库存只有100件，但是由于是参加了预售活动，因此，可以不受实际库存的影响，向买家用户显示的可售库存数量，一般大于仓库中关于该商品对象的实际库存数量。例如，对于预售活动开始后尚未有预售订单生成时，向买家用户显示的可售库存数量就是预置的预售库存的总数，也即500件，之后，随着预售订单的生成，就可以将预售库存减去订单中已经被锁定的库存，得到当前的可售库存数量。

当然，如果当前指定前端商品对象不带有预置标识，则证明该前端商品对象未参加预售活动，但是，因为其对应的后端商品对象带有预置标识，可以证明该后端商品对象对应的其他前端商品对象已经参加了预售活动，因此，就可以将当前指定前端商品对象的可售库存置为预置数目。该预置数目一般可以比较小，例如，在极端的情况下可以置为0。也就是说，在本申请实施例中，为了保障参加预售订单的正常履行，在预售活动过程中，对于同一后端商品对象对应的其他未参加预售活动的前端商品对象，可以置为限制销售或者不可售状态，这样，可以降低由于其他的销售活动对实际库存的占用或者消耗，导致预售订单无法履行等情况发生的概率。

以上实施例一中，对为前端消费者用户提供可售库存环节进行了改进，通过为参加预售活动的前端商品对象以及对应的后端商品对象添加预置标识，可以使得在接收到关于某前端商品对象的浏览请求时，可以判断出当前被浏览的前端商品对象是否参加了预售活动，如果参加预售活动，则可以根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息，否则，如果当前被浏览的前端商品对象未参加预售活动，但是与其对应了同一后端商品对象的其他前端商品对象参加了预售活动，则可以将该当前被浏览的前端商品对象置为不可售，也即，将其可售商品对象数量置为预置数目，使得对应的前端商品对象处于限制销售或者不可售状态，因此，可以降低由于其他的销售活动对实际库存的占用或者消耗，导致预售订单无法履行等情况发生的概率。

在实际应用中，还可以从其他环节进行改进，以进一步保障预售订单的正常履行。

首先，可以从预售库存的设置方面进行改进。如前述实施例中步骤S105所述，如果当前被浏览的前端商品对象带有预置标识，则可以根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息。其中，在现有技术中，预先为前端商品对象设置预售库存时，通常是设置一个全局的预售库存。例如，某前端商品对象SKU1，设置500件预售库存，此时，在预售活动开始后，全国各地的买家用户在对该SKU1进行预订时，显示出的可售库存都只能根据该全局的预售库存数量来确定。

但是，在实际应用中，物流服务提供的方的仓储体系通常是一种层次化模型。例如，全国设置若干中心仓库，每个中心仓库下设若干子仓库，一个中心仓库下的子仓库的覆盖范围的并集是该中心仓库覆盖范围的子集。商家通常会预先订购多个仓库，这种仓库一般分布在不同的区域，对应着不同的服务区域。在为买家用户发货时，通常是由具体的某个实体仓库(例如，距离收货地址最近的仓库等)进行发货，并执行配送等相关物流服务。但是，由于买家用户下定金时，商家的货品并未入库，预售后期商家集中入仓可能会由于仓库的库容等不足导致无法入库。若在消费者付尾款前不能将足额的货品入库，则会影响订单合约的正常履行。也就是说，在预先设置预售库存的情况下，即便在消费者付尾款前，供货商的货源充足，也可能由于未能及时运送到发货仓库，或者运送到发货仓库后，发货仓库库容不足导致无法入库，进而导致预售订单合约无法正常履行。

为此，在本申请实施例中，在商家进行预售库存设置时，可以提供分别为各个仓库设置不同的预售库存的操作选项，这样，每个仓库对应着不同的预售库存，后续在向各个仓库进行补货时，就可以以各个仓库对应的预售库存为依据，进行更合理的补货，防止向其中某个仓库补货过多或者过少。在这种情况下，在向当前买家用户提供可售库存信息时，就可以首先确定出该买家用户所在的区域信息，然后可以将该所在区域与当前商品对象对应的各个仓库的服务区域进行匹配，进而就可以根据匹配成功的仓库中该指定前端商品对象的预售库存信息，提供可售库存数量信息。

例如，当前浏览的前端商品对象为参加预售活动的SKU1，商家为该SKU1设置的预售库存信息如以下表1所示：

表1

根据当前买家用户所在终端设备的定位信息、IP地址信息、已登录用户的历史常用收货地址信息等，可以确定出当前买家用户所在的区域，例如，确定为北京的用户，则可以根据该SKU1在北京仓的预售库存提供当前可售库存。例如，北京仓已经被锁定的库存为10件，则向当前买家用户提供的可售库存为200-10＝190件，等等。

其中，关于同一前端商品对象分别在各个仓库中的预售库存，可以是由商家根据经验等确定。当然，即使已经精确到具体的仓库进行预售库存的设置，仍然不应该任意设置预售库存数量，因为预售库存设置过大，会导致供大于求，反之则供不应求，这两种情况对商家来说均不是最优的方案。为此，在本申请实施例中，还可以通过大数据分析、该商品对象在历史销售记录中在各个区域的销售情况等，对各个仓库的预售数量进行预测，然后，可以根据预测的结果，向商家提供关于各个仓库的预售库存数量的推荐信息。这样，商家可以根据该推荐信息，并结合自身的经验等，更精确地设置各个仓库中的预售库存。

以上所述为在预售活动开始前，进行预售库存设置时提供的改进方案，而在预售活动开始后，供货商可以开始向仓库进行补货，在补货的过程中，本申请实施例也提供了相应的改进方案。

具体的，对于预售业务场景，补货过程通常包括两个步骤，首先是预约入库，之后再进行实际入库，通常情况下，不允许在没有预约的情况下直接进行货品入库。在现有技术中，供货方在提交预约入库请求时，一般是直接接受其请求，生成预约入库单，将单号提供给供货方以及物流服务提供方，供实际入库时使用。有些平台中，在预约入库过程中会考虑仓库的收货能力，但主要考虑仓库的人力资源等因素，也即确定在收到货品后，是否有足够的人手完成入库的操作。

但是，本申请发明人在实现本申请的过程中发现，即使在收到货品时，仓库有足够的人手处理这批货品，也还可能出现另一种情况，即仓库的库容不足， 也即无法容纳下这批货品，此时，仍然会影响货品的入库。因此，在本申请实施例中，还可以对预约入库环节进行改进。

具体的，可以在接收指定前端商品对象进行货品预约入库的请求时，从该请求中提取出其携带的拟入仓库标识、拟入库日期、拟入库货品体积及数量，之后可以确定出该拟入仓库在该拟入日期的库存容量信息，并判断该库存容量是否满足该拟入库商品体积及数量的需求，如果满足，则将拟入库商品体积及数量对应的库存容量进行锁定，并生成预约入库订单，将该预约入库订单的标识信息提供给供货方以及物流服务提供方。也就是说，假设收到预约入库请求的日期是8月1日，请求中携带的拟入日期是8月11日，也就是说，供货方预计在10天后向指定的仓库(例如北京仓)进行补货。此时，在本申请实施例中，可以首先确定出北京仓在8月11日的库存容量是否满足这批拟入货品的需求，如果满足，则可以接受该请求，否则，如果8月11日的库存容量已不足，则可以通知供货方请求失败，该供货方可以修改其拟入日期、货品数量等，重新发起预约入库请求。这样，可以避免在供货方将货品运送到仓库后，由于仓库库存容量不足导致的无法入库等问题。

当然，在具体实现时，在判断出拟入仓库在拟入日期的库存容量满足要求的情况下，还可以增加人工核对的环节，对可能出现的异常情况进行排查，例如，某仓库中的预售数量为200件，但是预约入库请求中需要向该仓库中入库1000件，远大于其预售库存数量，因此，可以对其进行进一步的核查。

其中，对于拟入仓库在拟入日期的库存容量信息，可以通过多种方式确定，例如，其中一种方式下，可以首先确定拟入仓库在当前日期的第一库存容量(该信息可以是由物流服务提供方向平台同步过来的)，然后，可以确定已经被已生成的其他预约入库订单锁定为在当前日期到拟入日期之间入库的第二库存容量。例如，仍然假设收到当前预约入库请求的当前日期为8月1日，该请求的拟入日期为8月11日，而在7月25日生成的预约入库订单中，其拟入日期是8月2日，也即，在8月2日可能会有一批货品被运送到该仓库，使得该仓库的库存容量被占用，这批货品所需的库存容量已经提前被锁定，其他类似的预约入库订单可能还存在，因此，可以将从8月1日到8月11日之间被锁定 的库存容量从当前的库存容量中扣除，优先保证之前已经接受的预约入库请求能够正常入库。另外，拟入仓库中通常还保存有其他货品，每天还会由于部分货品售出而释放出一部分可用库存，因此，还可以对所述拟入仓库每天的销售出库量进行预测，并预测从当前日期到所述拟入日期之间的销售出库总量，这样，在计算拟入仓库在拟入日期的库存容量时，可以用前述第一库存容量减去所述第二库存容量，再加上预测出的销售出库总量，就可以得到拟入仓库在拟入日期的剩余库存容量，如果剩余的库存容量仍然能够满足当前预约入库请求的需求，则可以接受该请求。

对于被接受的预约入库请求，平台可以生成预约入库订单，并将该订单的标识，如订单编码等，发送给供货方以及物流服务提供方，之后，供货方就可以按照预约请求中的拟入日期进行实际入库操作，在将货品运送到仓库时，可以提交货品对应的预约入库订单标识，这样，物流服务提供方可以在入库完成后，将已入库的预约入库订单标识同步到平台，平台对订单状态进行更新，并且可以更新仓库的库存容量等信息。

在现有技术中，供货方需要严格按照拟入日期以及货品体积、数量进行实际入库，否则，仓库方将拒绝入库，避免造成信息同步过程中出错。而在实际应用中，有些供货方可能出于节省成本等目的，通过“捎带”的方式对货品进行实际入库。例如，某预约入库订单中记录的拟入日期是8月11日，但恰好在8月10日有另一批货品也会被运送到同样的拟入仓库，而且运输车辆有额外的运力，于是，可能会需要将原定于8月11日的货品也“捎带”上。此时，如果按照现有技术的方式，供货方即使捎带上了货品，也无法完成实际入库，因为实际入库日期与拟入日期不一致。显然，这种方式不够友好，并且也不利于供货商及时向仓库中补货。

为了给供货方提供更大的便利，更好的履行预约订单合约，在本申请实施例中，在实际入库的过程中也可以进行改进。具体的，在供货方向物流服务提供方进行实际入库操作时，可以接收物流服务提供方提交的实际入库通知消息，该通知消息中可以携带有预约入库订单的标识信息，以及实际入库的货品体积以及数量信息，之后，可以判断接收到该通知消息的当前日期与该预约入库订 单中记录的拟入日期是否相同。如果不相同，则还可以确定出该预约入库订单中的拟入仓库在该当前日期的库存容量信息(该库存容量信息一般是由物流服务提供方同步过来的，另外，还可以减去该当前日期被锁定的库存容量)，之后，就可以判断该库存容量是否满足当前的实际入库商品体积及数量的需求，也即判断拟入仓库在当前日期是否仍然有额外的库存容量，能够供这部分货品使用，如果有，则可以生成允许入库的通知消息，并返回给物流服务提供方，这样，物流服务提供方就可以执行具体的入库操作。在入库完成后，可以接收物流服务提供方提交的实际入库成功的通知消息，然后，可以根据该通知消息更新对应仓库的库存容量，并将对应的预约入库订单的状态进行更新，例如，将该预约入库单锁定的库存容量进行释放。

以上所述是在预约入库以及实际入库环节上进行的改进，通过平台与物流服务提供方的信息互通共享以及系统联动，提高了入库操作效率和操作灵活性。而在买家用户选定了某预售的前端商品对象，就可以生成对应的交易订单，在买家用户完成定金支付后，之后需要考虑的问题即为物流时效问题，因为是影响消费者物流体验的一个重要因素。而期货预售包含定金期和尾款期两个阶段，定金期无需发货，只要在付完尾款后才需发货，因此可以结合预售业务特点来提升物流时效。货品距离消费者越近则物流时效无疑会越好，因此，在本申请实施例中，还可以在货品调拨环节上也可以进行改进，通过精确的数据分析来指导将货品调拨到距离消费者最近的仓库。

具体的，如前文所述，物流服务提供方的仓储体系通常是一种层次化模型，例如，全国设置若干中心仓库，每个中心仓库下设若干子仓库，一个中心仓库下的子仓库的覆盖范围的并集是该中心仓库覆盖范围的子集，等等。供货方在向仓库补货时，通常只会到一级或者二级仓库中，例如，省级或者市级的仓库，市级以下可能还包括多个子仓库，而对这些子仓库的补货，通常要由物流服务提供方通过调拨的方式来进行。另外，对于同一级别的仓库，也可能会根据实际销售情况，由物流服务提供方进行仓库间的调拨，等等。预先完成货品的调拨，有利于更好的履行预约订单合约。

为此，在本申请实施例中，在接收到针对指定前端商品对象完成支付定金 操作的消息时，可以从对应的交易订单中提取需购买的商品对象数量以及收货地址信息，然后，可以将该收货地址与各个仓库的服务区域进行匹配，确定出最佳发货仓库。需要说明的是，由于预售活动的定金期一般比较长，供货方是在定金期内向具体的仓库进行补货，因此，在买家用户付定金时，各个仓库中还不一定有实际的库存，因此，此时在确定最佳发货仓库时，可以不必考虑实际库存信息，而是仅仅从距离等角度出发，确定出最佳的发货仓库。例如，对于北京的用户，最佳的发货仓库为北京仓，但此时北京仓中可能还不存在该商品对象的实体库存，等等。

在确定出最佳发货仓库后，可以将该交易订单关联的商品对象标识、数量关联到该最佳发货仓库，之后，可以将预置周期内的各个交易订单对应的商品对象数量以及最佳发货仓库进行汇总，生成调拨建议信息。例如，一天为一个周期，则可以将一天以内生成的交易订单关联的商品对象标识、数量，以及确定出的最佳发货仓库进行汇总。例如，某第一交易订单关联的前端商品对象为SKU1，数量为3件，最佳发货仓库为北京仓，第二交易订单关联的前端商品对象也为SKU1，数量为5件，最佳发货仓库也为北京仓，则可以建议向北京仓调入8件该SKU1对应的货品。也就是说，调拨建议信息中可以包括调入仓库、调拨商品对象标识以及调拨数量。其中，调入仓库即为确定出的最佳发货仓库。

另外，该建议信息中还可以包括调出仓库信息，具体的，如前文所述，物流服务提供方的仓储体系可能是一种层级化的结构，因此，调出仓库可以是服务区域涵盖调入仓库服务区域的上级仓库。例如，假设最佳发货仓库为北京东城仓库，该仓库的上级仓库为北京仓，则可以将北京仓确定为调出仓库，北京东城仓库确定为调入仓库，等等。

该调拨建议信息可以是定期生成的，例如，每天18点针对当天的订单情况生成调拨建议信息，并且可以向物流服务提供方发送。需要说明的是，该调拨建议信息在发送到物流服务提供方后，物流服务提供方可能并不是马上执行调拨操作，这是因为，由于供货方的补货行为是在预售活动开始后才进行的，因此，在收到调拨建议信息时，供货方可能尚未补货，也即调出仓库中可能也 还没有相应的实际库存，无法进行调拨，或者，也可能是因为物流服务提供方的运力无剩余，等等。这种情况是允许存在的，这是因为定金期一般会比较长，只要在定金期完成调拨即可。也就是说，物流服务提供方在收到调拨建议信息后，可以将其作为参考，在具体进行调拨时，可以将已经收到的多条调拨建议信息进行汇总，执行具体的调拨操作。

在定金期即将结束，也即即将进入尾款期，可以针对订单确定出实际的发货仓库。在本申请实施例中，针对该过程也进行了相应的改进。具体的，在预售的定金期即将结束时，可以根据定金期内生成的交易订单，从中提取需购买的商品对象数量以及收货地址信息，然后，将该收货地址与各个仓库的服务区域进行匹配，确定区域匹配成功的至少一个仓库，然后，可以确定匹配成功的至少一个仓库的实际库存信息，判断与收货地址匹配度最高的第一仓库的实际库存是否充足，如果充足，则将该第一仓库确定为实际发货仓库，并将该第一仓库标识提供给物流服务提供方。匹配度最好的第一仓库，也即前文所述最佳发货仓库，也就是说，如果在实际需要发货时，最佳发货仓库中的库存充足，则可以直接从该仓库发货。而如果该第一仓库库存不足，则在本申请实施例中，还可以从区域匹配成功的仓库中确定出服务区域涵盖该第一仓库服务区域的第二仓库，并判断该第二仓库的实际库存是否充足，如果充足，则将该第二仓库确定为实际发货仓库，并将该第二仓库标识提供给物流服务提供方。例如，假设根据某订单的收货地址，确定出第一仓库为北京东城仓库，但是，该仓库的实际库存可能并不充足，此时，为了能够正常履行该订单合约，可以从该仓库的上级仓库，例如北京仓发货，以此保证买家用户能够及时收到货品。

也就是说，在本申请实施例中，虽然从货品入库、调拨等环节都可以进行优化，但在实际应用中，可能仍然会存在某些仓库中补货不足的情况，针对这种情况，为了确保订单合约的履行，可以采用由上级仓库直接发货的方式。

需要说明的是，是否从上级仓发货可以是由开关控制的，比如在预售快要结束时，则允许上级仓发货；在预售前期则不允许，这时系统会重试直到货物调拨到最佳发货仓库。

总之，在本申请实施例中，针对预售业务场景，可以从预售库存的设置、 预约入库、实际入库、详情浏览、货品调拨、发货等多个环节进行优化，最终降低预售订单合约无法履行的概率。当然，在实际应用中，以上各个环节的优化是可以独立存在的，或者，也可以对部分环节进行优化，都可以从一定程度上达到上述目的。

与前述实施例中提供的商品对象预售信息处理方法相对应，本申请实施例还提供了一种商品对象预售信息处理装置，参见图2，该装置可以包括：

对应关系确定单元201，用于预先确定与同一后端商品对象对应的至少一个前端商品对象；

标识添加单元202，用于在某前端商品对象被指定为为预售对象时，为该前端商品对象及其对应的后端商品对象添加预置标识；

第一标识判断单元203，用于接收到浏览指定前端商品对象详情信息的浏览请求时，判断该指定前端商品对象对应的目标后端商品对象是否带有所述预置标识；

第二标识判断单元204，用于如果所述目标后端商品对象带有所述预置标识，则判断该指定前端商品对象是否带有所述预置标识；

可售库存信息提供单元205，用于如果该指定前端商品对象带有所述预置标识，则根据预先为该指定前端商品对象设置的预售库存信息提供可售库存数量信息，否则，将可售库存数量置为预置数目。

其中，所述预先为该指定前端商品对象设置的预售库存信息包括，预先为该指定前端商品对象关联的至少一个仓库分别设置的预售库存信息；其中，各个仓库对应不同的服务区域；

此时，所述可售库存信息提供单元包括：

区域确定子单元，用于确定所述浏览请求的发出方所在的区域信息；

提供子单元，用于将该所在区域与各个仓库的服务区域进行匹配，根据匹 配成功的仓库中该指定前端商品对象的预售库存信息，提供可售库存数量信息。

具体实现时，该装置还可以包括：

预测单元，用于对所述指定前端商品对象在各个服务区域的销售数量进行预测；

预售库存推荐单元，用于根据预测结果提供关于各个仓库的预售库存数量的推荐信息。

另外，还可以在预约入库以及实际入库阶段进行改进，具体的，该装置还可以包括：

预约入库请求接收单元，用于接收对所述指定前端商品对象进行货品预约入库的请求，该请求中携带有拟入仓库标识、拟入库日期、拟入库货品体积及数量；

库存容量确定单元，用于确定所述拟入仓库在所述拟入日期的库存容量信息；

库存需求判断单元，用于判断所述库存容量是否满足所述拟入库商品体积及数量的需求；

锁定单元，用于如果满足，则将所述拟入库商品体积及数量对应的库存容量进行锁定，并生成预约入库订单，将该预约入库订单的标识信息提供给供货方以及物流服务提供方。

其中，所述库存容量确定单元包括：

第一库存容量确定子单元，用于确定所述拟入仓库在当前日期的第一库存容量；

第二库存容量确定子单元，用于确定已经被已生成的其他预约入库订单锁定为在当前日期到所述拟入日期之间入库的第二库存容量；

计算子单元，用于将所述第一库存容量减去所述第二库存容量，确定为所述拟入仓库在所述拟入日期的库存容量信息。

另外，还可以包括：

实际入库通知接收单元，用于在供货方向所述物流服务提供方进行实际入库操作时，接收所述物流服务提供方提交的实际入库通知消息，所述通知消息中携带有所述预约入库订单的标识信息，以及实际入库的货品体积以及数量信息；

日期判断单元，用于判断接收到该通知消息的当前日期与所述预约入库订单中记录的拟入日期是否相同；

当前库存容量确定单元，用于如果不相同，则确定所述拟入仓库在该当前日期的库存容量信息；

库存需求判断单元，用于判断该库存容量是否满足所述实际入库商品体积及数量的需求；

允许入库通知单元，用于如果满足，则生成允许入库的通知消息，并返回给所述物流服务提供方。

在入库成功后，物流服务提供方可以返回通知消息，此时，该装置还可以包括：

入库成功通知接收单元，用于接收所述物流服务提供方提交的实际入库成功的通知消息；

状态更新单元，用于根据该通知消息更新对应仓库的库存容量，并将对应的预约入库订单的状态进行更新。

在货品调拨环节，该装置还可以包括：

第一信息提取单元，用于接收到针对所述指定前端商品对象完成支付定金操作的消息时，从对应的交易订单中提取需购买的商品对象数量以及收货地址信息；

最佳发货仓库确定单元，用于将所述收货地址与各个仓库的服务区域进行匹配，确定出最佳发货仓库；

调拨建议信息生成单元，用于将预置周期内的各个交易订单对应的商品对象数量以及最佳发货仓库进行汇总，生成调拨建议信息，所述调拨建议信息包括调出仓库、调入仓库、调拨商品对象标识以及调拨数量；其中，所述调入仓库为所述最佳发货仓库，所述调出仓库包括与服务区域涵盖所述最佳发货仓库服务区域的上级仓库；

调拨建议信息提供单元，用于将所述调拨建议信息提供给物流服务提供方。

在实际发货环节，该装置还可以包括：

第二信息提取单元，用于在预售的定金期结束后，根据定金期内生成的交易订单，从中提取需购买的商品对象数量以及收货地址信息；

区域匹配单元，用于将所述收货地址与各个仓库的服务区域进行匹配，确定区域匹配成功的至少一个仓库；

实际库存信息确定单元，用于确定所述匹配成功的至少一个仓库的实际库存信息；

实际库存判断单元，用于判断与所述收货地址匹配度最高的第一仓库的实际库存是否充足；

第一实际发货仓库确定单元，用于如果充足，则将该第一仓库确定为实际发货仓库，并将该第一仓库标识提供给物流服务提供方。

仓库区域确定单元，用于如果第一仓库的实际库存不充足，则从所述区域匹配成功的仓库中确定服务区域涵盖所述第一仓库服务区域的第二仓库；

第二实际发货仓库确定单元，用于判断该第二仓库的实际库存是否充足，如果充足，则将该第二仓库确定为实际发货仓库，并将该第二仓库标识提供给物流服务提供方。

总之，通过本申请实施例，通过为参加预售活动的前端商品对象以及对应的后端商品对象添加预置标识，可以使得在接收到关于某前端商品对象的浏览请求时，可以判断出当前被浏览的前端商品对象是否参加了预售活动，如果参加预售活动，则可以根据预先为该指定前端商品对象设置的预售库存信息提供 可售库存数量信息，否则，如果当前被浏览的前端商品对象未参加预售活动，但是与其对应了同一后端商品对象的其他前端商品对象参加了预售活动，则可以将该当前被浏览的前端商品对象置为不可售，也即，将其可售商品对象数量置为预置数目，使得对应的前端商品对象处于限制销售或者不可售状态，因此，可以降低由于其他的销售活动对实际库存的占用或者消耗，导致预售订单无法履行等情况发生的概率。

此外，还可以对预售库存的设置、预约入库、实际入库、货品调拨、货品出库等环节进行一系列的改进，使得订单合约的履行得到进一步的保障。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

以上对本申请所提供的商品对象预售信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。