br>[0065] 其中，_规格参数可以是商品的型号、尺寸等信息。在生成了表2中各条记录对应的 交易订单时，相应的，表1中针对该商品对象的虚拟库存数量也将会发生更新，也即在原来 的基础上扣减2。例如，针对表2中的交易订单，更新后的商品对象虚拟物流仓库信息如表 3所示：
[0066] 表 3
[0067]
[0068] 在具体实现时，为了与普通的交易订单进行区分，还可以在交易订单中增加期货 预售标识（例如，以True、False分别表示是与否），这样后续在根据该交易订单生成物流 订单时，就可以知晓该订单中的商品对象是作为期货进行预售的商品对象，进而就可以按 照期货预售的发货策略进行后续的发货处理。此时，交易订单对应的数据库格式可以如以 下表4所示：
[0069] 表 4
[0070]
[0071] 当然，如果在生成了交易订单之后，第二用户发生了取消订单等行为，则该订单中 对应的预购数量也可以回滚到虚拟库存数量中。例如，第二用户1取消了编号1对应的交 易订单，并且在取消该订单之前，对应的商品对象10010的虚拟物流仓库信息如表3中的第 一条所示，则取消该交易订单之后，表3中第一条记录中的"虚拟库存数量"将会重新变为 100。
[0072] 如果第二用户在生成交易订单之后，又在规定的时间内执行支付尾款的操作，则 可以生成物流订单，并根据交易订单中的期货预售标识，识别出当前生成的是期货预售的 物流订单。需要说明的是，在实际应用中，生成交易订单和物流订单的触发操作，也不一定 分别是支付定金以及支付尾款的操作，例如，还可以在支付尾款时生成交易订单，在执行其 他操作时生成物流订单等等。因此，在本申请实施例中，将用于生成交易订单的操作称为第 一操作，用于生成物流订单的操作称为第二操作。
[0073] 在生成物流订单之后，实体物流仓库中不一定有对应的实际库存，因此，如何为第 二用户进行发货也是需要解决的问题。为此，本申请实施例可以提供对应的期货预售发货 策略，也即可以根据预置的期货预售发货策略通知仓储系统进行发货。
[0074] 具体在根据预置的期货预售发货策略通知仓储系统进行发货时，可以首先查询第 一用户订购的实体物流仓库中是否有当前商品对象的库存，如果有，则将物流订单发送给 仓储系统，这样，仓储系统就可以根据物流订单中的信息进行发货。如果生成物流订单时， 第一用户关联的实体物流仓库中还没有商品对象的实际库存，则可以等到满足条件时，再 将物流订单发送给仓储系统，由仓储系统进行发货。例如，在一种具体的实现方式下，可以 在接收到第一用户的入库完成通知时，将物流订单发送给仓储系统，以便仓储系统进行发 货。也就是说，等到第一用户将对应的商品对象运输到实体物流仓库之后，再将物流订单发 送到仓储系统，由仓储系统进行发货。或者，在另一种实现方式下，也可以从生成物流订单 时刻起开始计时，每隔预置的时间间隔，将物流订单发送给仓储系统，仓储系统在每次接收 到物流订单时，都可以判断对应的商品对象在实体物流仓库中是否有库存，如果没有，则不 作出响应，或者返回发货失败的消息，直到某次接收到物流订单时，如果发现实体物流仓库 中产生了关于该商品对象的实际库存，则返回表示成功的响应消息，并安排进行发货。或 者，也可以每隔一定的时间间隔，询问仓储系统，实体物流仓库中是否已经产生库存，只有 在有库存的情况下，才将物流订单发给仓储系统，否则继续等待。
[0075] 当然，具体在为第二用户进行发货时，都是从具体的实体物流仓库发出的，因此， 在第一用户关联了多个实体物流仓库的情况下，同样需要从中选择物流配送范围能够覆盖 到该第二用户的收货地址的实体物流仓库。具体实现时，可以是由仓储系统在收到物流订 单之后，再根据当前第二用户的收货地址，以及当前第一用户订购的各个实体物流仓库的 配送覆盖范围，确定出实际为该第二用户发货的实体物流仓库，再从该实体物流仓库为该 第二用户进行发货。在实际应用中，可能存在不同实体物流仓库覆盖同一区域的情况，此 时，可以设定实体物流仓库发货优先级，根据优先级确定是从哪个实体物流仓库进行发货。
[0076] 但是，这样可能存在的问题是：第一用户只知道针对此次期货预售一共需要准备 多少库存，如果该第一用户关联了多个实体物流仓库，则在商品入库的过程中，到底需要向 每个实体物流仓库存入多少件库存，第一用户并不知晓，此时，仍然只能凭经验或者平均分 配，这使得实体物流仓库中的库存数量仍然可能会出现不够或者过多的情况。为此，在本 申请优选实施例中，由于第二用户的收货地址是不变的，因此，在第一用户订购的实体物流 仓库也确定的情况下，实际上是可以提前确定出通过哪个实体物流仓库为该第二用户发货 的。因此，在本申请实施例中，在用户支付定金生产交易订单时，就可根据第二用户的收货 地址以及当前第一用户关联的各个实体物流仓库的配送覆盖范围，确定出实际为该第二用 户发货的实体物流仓库。之后就可以随着交易订单的生成，对各个实体物流仓库需要入库 的商品对象数量进行同步更新，并实时通知给第一用户。这样，第一用户在进行实体商品到 实体物流仓库的入库时，就可以根据各个实体物流仓库需要入库的商品对象数量进行更精 准的入库，避免出现某实体物流仓库中的库存数量过多或者不够的情况。
[0077] 当然，还可以将确定出的实体物流仓库的信息添加到交易订单中，在后续生成物 流订单时，也可以将该信息添加到物流订单中。这样，后续仓储系统在根据物流订单进行发 货时，就可以直接根据已经确定出的实体物流仓库信息进行发货，而不需要再重新根据第 二用户的收货地址等信息进行确定。例如，在一种具体的实现方式下，如果添加了实体物流 仓库信息，则对应的交易订单的
[0078] IP140126
[0079] 数据库格式可以如以下表5所示：
[0080] 表 5
[0081]
[0082] 为了更好的理解本申请实施例提供的技术方案，下面通过一个实际的例子对具体 的实现方式进行更为详细地介绍。在该例子中，假设某第一用户关联了多个实体物流仓 库，其中，每个实体物流仓库都有自己的配送覆盖范围（省、市、区），同时，系统针对参加期 货预售的第一用户构建一虚拟物流仓库，该虚拟物流仓库包括两个方面的信息，一个是虚 拟库存数量，另一个是虚拟配送覆盖范围，关于前者依商品对象的不同而不同，具体可以根 据系统预测出的数量或者第一用户录入的预售数量而定；而关于后者，依各个不同的第一 用户可能会是不同的，一般小于等于第一用户订购的各个实体物流仓库的配送覆盖范围之 和。接下来，参见图2,涉及到浏览器、交易平台系统、库存系统数据库、仓储系统这样几个实 体，具体的过程可以包括以下步骤：
[0083] S201 :接收到第二用户浏览或者购买商品对象的请求；该步骤涉及到的主体一般 是通过用户终端设备中安装的浏览器，访问到的交易平台系统的前端界面，第二用户的请 求，相当于是第二用户在访问该前端界面的过程中，打开某商品对象的详情页界面等操作 时发出的。
[0084] S202:判断该商品对象是否为预售期货，如果是，则向库存系统数据库获取该商品 对象的虚拟物流仓库信息；也就是说，关于步骤S103中生成的虚拟物流仓库信息，可以是 保存在库存系统数据库中，浏览器端可以从该库存系统数据库中获取各个商品对象的虚拟 物流仓库信息。
[0085] S203:根据第二用户的收货地址，判断当前第二用户的收货地址是否位于该商品 对象的虚拟配送覆盖范围，如果是，则将该商品对象的虚拟物流仓库信息展示给该第二用 户；
[0086] S204:在第二用户为该商品对象支付了定金并生成交易订单时，对库存系统数据 库中保存的该商品对象的虚拟物流仓库信息中的虚拟库存进行更新；
[0087] S205 :根据第二用户的收货地址，以及第一用户订购的各个实体物流仓库的配送 覆盖范围，确定出用于为该第二用户进行发货的实体物流仓库，将该实体物流仓库需要入 库的商品对象数量进行更新，并反馈给第一用户；
[0088] S206:在第二用户为该商品对象支付尾款并生成物流订单时，通知仓储系统进行 发货，仓储系统可以路由出真实用户发货的实体物流仓库，并为第二用户进行发货。
[0089] 总之，在本申请实施例中，通过虚拟物流仓库信息，可以在第二用户在浏览或者购 买作为期货进行预售的商品对象时，能够知晓该商品对象的虚拟库存数量，避免期货预售 过程中发生超卖现象；另外，在为第二用户显示虚拟物流仓库信息之前，还需要判断第二用 户的收货地址是否位于该商品对象对应的虚拟配送覆盖范围内，如果是才会进行显示，并 允许第二用户进行购买操作，这样，也可以避免配送范围之外的第二用户产生无效的交易 订单，避免了用户的时间和精力的耗费，提高了网络计算资源的利用率。
[0090] 实施例二
[0091] 前述实施例一中，主要从生成虚拟物流仓库信息的角度对本申请实施例进行了介 绍，本申请实施例二中，主要从前端处理的角度对本申请实施例进行介绍。参见图3,本申请 实施例二提供了一种商品对象信息处理方法，该方法可以包括以下步骤：
[0092] S301 :在向第二用户展示指定商品对象的物流仓库信息时，通过查询库存系统数 据库判断该商品对象是否为作为期货进行预售的商品对象；所述库存系统数据库中保存有 各个作为期货进行预售的商品对象的标识以及虚拟物流仓库信息，所述虚拟物流仓库信息 包括虚拟库存数量；
[0093] S302 :如果是，则向该第二用户提供该商品对象的虚拟物流仓库信息；
[0094] 当然，虚拟物流仓库信息还可以包括虚拟物流仓库的配送覆盖范围信息，
[0095] IP1401