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

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

背景技术：

预售是电子商务平台中的一种销售模式，其具体的销售环节分为定金和尾款两个阶段。消费者在定金期支付较少的金额即可锁定对某商品的购买权利；在尾款期消费者可以支付尾款确认购买。广义的预售包含期货预售和现货预售，现货预售指预售开始前仓库中已经有商品，期货预售则不做此限制，因此对商家来说更具灵活性。

但是，在传统的预售模式下，需要在消费者支付了尾款之后才能够进入到发货出库流程，这样，在一些大型促销活动等场景下，定金期产生的交易订单数量非常多，在支付尾款后，会导致同一时间物流系统需要处理海量的货物，供应链压力超过任何一个物流服务商的能力，进而导致爆仓、积压等一系列问题，严重影响消费者的消费体验。

为了充分利用物流服务商的能力，协调整个供应链的能力，现有技术中提供了“期货预售下沉”的模式，将供应链的发货压力分摊到期货预售的定金期，也即，在定金期通过系统协同，提前将货物下沉到离消费者最近的仓库网点，使得消费者在支付尾款后能够在很短的时间内即可收到货品，从而解决活动期间的供应链问题。

虽然期货预售下沉对商家、消费者都是一种不错的销售模式，但是现有技术中只能实现在“直营”场景下的预售下沉，一直没有实现分销场景下的预售下沉。这里所谓的“直营”场景是指，商家本身就是货主，消费者在前端下单后，商家直接为其发货。而在分销模式下，商品的所有者货主并不直接面向最终消费者销售，而是由供货商进行货品的管理，然后通过中间的分销商，把商品卖给消费者。“天猫”等系统中的供销平台支持这种交易形式，具体的，供 货商发布后端商品，分销商发布前端商品并关联供货商的后端商品，消费者在前端购买指定前端商品后，分销商利用该订单去供销平台向供货商发起采购，然后由供货商发货给消费者。也就是说，在分销模式下，涉及到消费者用户与分销商之间的B2C交易订单，以及分销商与供货商之间的B2B采购单，单据模型复杂。

在很多类目销售中，分销是一种主要的销售模式。例如，在大家电等类目，分销占了总销售额的40％以上，也就是说，假设期货预售要卖出100w单的大家电，40％的分销销售，那么有将近40w单无法下沉，即有接近一半的交易无法使用预售下沉来优化物流方案。可见，如果不解决分销场景的下沉处理，预售下沉方案是严重不完整的，不能达到为更多商家缓解活动期物流压力和成本的目的。

因此，如何实现在分销场景下的预售下沉，成为需要本领域技术人员解决的技术问题。

技术实现要素：

本申请提供了商品对象物流信息处理方法及装置，能够实现在分销场景下的预售下沉，使得更多的交易订单能够进行预售下沉。

本申请提供了如下方案：

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

前端交易中心服务器在目标交易订单的定金期内，确定所述目标交易订单关联的前端商品对象、第一用户以及第二用户，并判断所述第二用户是否为分销商用户，其中，所述第一用户为消费者用户；

如果确定出所述第二用户是分销商用户，则通知供销平台服务器创建对应的采购单，以便通过所述采购单建立第二用户与第三用户在此次交易中的关联关系，并将所述采购单已创建的消息通知给物流中心服务器，所述物流中心服务器在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单， 并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作。

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

供销平台服务器接收前端交易中心服务器发送的针对目标交易订单创建采购单的请求；

确定所述目标交易订单的状态；

如果所述目标交易订单处于定金期，则创建采购单，并通知物流中心服务器创建物流订单，以便所述物流中心服务器在在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作。

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

物流中心服务器接收供销平台服务器发送的采购单已创建的通知消息；

确定所述采购单对应的目标交易订单所处的状态；

如果所述目标交易订单处于定金期，则判断所述目标交易订单关联的目标商品对象是否需要下沉；

如果需要下沉，则根据所述采购单关联的目标商品对象信息、第一用户的地址信息、以及第三用户订购的物流资源信息，创建对应的物流订单，并通过调用发货中心服务器的接口创建预发货单，以便在定金期进行对应货品的下沉发货操作。

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

仓储中心服务器检测到针对目标物流订单完成发货操作的事件后，判断所述目标物流订单是否带有预置标识，所述预置标识用于表明对应的货品在定金期执行下沉操作；

如果带有所述预置标识，则向订单中心服务器回传确认出库的消息，并将所述目标物流订单的状态更新为预售出库中状态。

一种商品对象物流信息处理装置，应用于前端交易中心服务器，包括：

交易订单信息确定单元，用于在目标交易订单的定金期内，确定所述目标交易订单关联的前端商品对象、第一用户以及第二用户，并判断所述第二用户是否为分销商用户，其中，所述第一用户为消费者用户；

通知单元，用于如果确定出所述第二用户是分销商用户，则通知供销平台服务器创建对应的采购单，以便通过所述采购单建立第二用户与第三用户在此次交易中的关联关系，并将所述采购单已创建的消息通知给物流中心服务器，所述物流中心服务器在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作。

一种商品对象物流信息处理装置，应用于供销平台服务器，包括：

采购单创建请求接收单元，用于接收前端交易中心服务器发送的针对目标交易订单创建采购单的请求；

订单状态确定单元，用于确定所述目标交易订单的状态；

采购单创建单元，用于如果所述目标交易订单处于定金期，则创建采购单，并通知物流中心服务器创建物流订单，以便所述物流中心服务器在在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作。

一种商品对象物流信息处理装置，应用于物流中心服务器，包括：

通知消息接收单元，用于接收供销平台服务器发送的采购单已创建的通知消息；

交易订单状态确定单元，用于确定所述采购单对应的目标交易订单所处的状态；

判断单元，用于如果所述目标交易订单处于定金期，则判断所述目标交易订单关联的目标商品对象是否需要下沉；

物流订单创建单元，用于如果需要下沉，则根据所述采购单关联的目标商品对象信息、第一用户的地址信息、以及第三用户订购的物流资源信息，创建对应的物流订单，并通过调用发货中心服务器的接口创建预发货单，以便在定金期进行对应货品的下沉发货操作。

一种商品对象物流信息处理装置，用于仓储中心服务器，包括：

检测单元，用于检测到针对目标物流订单完成发货操作的事件后，判断所述目标物流订单是否带有预置标识，所述预置标识用于表明对应的货品在定金期执行下沉操作；

消息回传单元，用于如果带有所述预置标识，则向订单中心服务器回传确认出库的消息，并将所述目标物流订单的状态更新为预售出库中状态。

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

通过本申请实施例，对于分销场景下的预售下沉，可以在定金期就创建采购单，从而提前建立起第二用户与第三用户在此次交易过程中的关联关系，进而就可以根据第三用户对物流资源的订购情况等信息进行路由，创建起物流订单，另外还可以创建预发货单，从而实现在分销场景下的预售下沉，使得更多的交易订单能够进行预售下沉。

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

附图说明

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

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

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

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

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

图5是本申请实施例提供的第一装置的示意图；

图6是本申请实施例提供的第二装置的示意图；

图7是本申请实施例提供的第三装置的示意图；

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

具体实施方式

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

首先需要说明的是，对于“直营”场景，如果不考虑定金期下沉，则处理链路大致为：在定金期，第一用户(例如，买家用户、消费者用户等)点击购买并支付定金后，可以生成交易订单；在此期间，第二用户(商家用户、卖家用户等)可以进行补货入库等。在尾款期，第一用户支付尾款后，物流中心服务器就可以创建对应的物流订单，并由仓储中心进入后续的发货流程。

如果需要进行定金期下沉，则可以在定金期生成交易订单后，物流中心服务器就可以提前创建物流订单(而不用等到第二用户支付尾款之后)，并创建预发货单，仓储中心根据该预发货单执行发货操作，这样，在第二用户支付尾款之后，相应的货品可能已经到达距离第二用户收货地最近的网点，因此，可以在很短的时间内将货品配送到第二用户指定的收货地址。

但是，在“分销”场景下，如果不考虑定金期下沉，则处理链路大致为：在定金期，第一用户点击购买并支付定金后，可以生成B2C(也即商家与消费者之间)交易订单，在定金期结束，进入到尾款期后，如果第一用户支付了尾款，则首先需要生成B2B采购单，建立起第二用户与第三用户(例如，供货商，货主等)在此次交易中的关联关系，之后，物流中心服务器才会创建对应的物流订单，并由仓储中心进入到后续的发货流程。

也就是说，第二用户与第三用户在一次交易中的关联关系，需要通过B2B采购单来建立，并且，具体的货品是第三用户统一管理的，包括仓库、配送等物流资源的选择，都是由第三用户确定的，因此，物流订单的生成也需要基于B2B采购单进行。可见，在分销模式下，不能简单的在生成B2C交易订单之后直接创建物流订单，事实上，在第二用户与第三用户之间尚未建立起在此次交易中的关联关系之前，也无法建立起对应的物流订单。

为此，本申请实施例对于各种订单的生成时机方面首先进行了改进。具体的，前端交易中心服务器在交易订单的定金期内(第一用户已经支付定金，并且定金期尚未结束)，就可以通知供销平台服务器异步创建B2B采购单，从而提前建立起第二用户与第三用户在此次交易中的关联关系，而不用等到第一用户支付尾款之后。另外，在创建了B2B采购单后，物流中心服务器还可以在定金期提前创建好物流订单，之后就可以基于该物流订单创建预发货单，进行发货处理，也就是在定金期进行货品的下沉。

其中，提前创建的B2B采购单实际上只是为了支持预售下沉操作，因此，在创建该B2B采购单之后，可以将B2B采购单置为锁定状态，使得第二用户以及第三用户均不得对该B2B采购单执行手动操作，例如，第二用户不得在定金期执行手动发货等等，以避免对预售下沉操作造成影响。

物流中心服务器创建的物流订单可以是两个，其中第一物流订单对应于B2C交易订单，第二物流订单对应于B2B采购单，第二物流订单用于支持具体的发货操作，第一物流订单的状态可以与第二物流订单的状态同步变化，用于将具体的物流详情信息提供给前端第一用户，也就是说，可以使得第一用户能够了解到货品下沉过程中的具体状态。例如，在第一用户获知其预定的商品对象已经到达距离其收货地址最近的网点时，可以尽快支付尾款，以便尽快收到具体的货品，等等。

第一物流订单和第二物流订单都可以带有“下沉”标识，这样，仓储中心服务器可以将这种需要执行下沉操作的物流订单与普通的物流订单相区分。之所以要进行这种区分是因为，在本申请实施例中，还可以对下沉操作中的物流订单模型进行改进，使得其支持“预售出库中”的状态。具体的，在仓储中心 服务器针对某带有下沉标识的物流订单完成发货后，向订单中心服务器回传确认出库的时候，回传的B2B物流订单的状态是“预售出库中”，而不是“已出库”，后续在进入尾款期后再更新为“已发货”状态。

在具体进行下沉发货时，物流中心服务器可以首先确定出第三用户为当前的商品对象预订的物流资源(例如，包括仓库资源、配送资源等)，并且可以确定出各个物流资源对应的覆盖范围等属性信息，另外，B2B物流订单中还可以记录第一用户的收货地址信息，库存中心服务器中还记录有各个商品对象在仓库中的库存信息，因此，可以确定出与收货地址相匹配的优先级最高的发货仓库。进而就可以调用发货中心服务器的接口，生成预发货单，然后，发货中心服务器可以将预发货单下发给仓储中心服务器，仓储中心服务器可以再转发给合作的物流服务提供方(例如，“日日顺”等)，这样，物流服务提供方就可以执行具体的发货操作。其中，物流中心服务器在调用发货中心服务器接口生成预发货单时，还可以携带上尾款期的开始时间，这样，就可以将该信息记录在预发货单中，物流服务提供方可以尽量赶在尾款期开始之前进行发货，否则将失去预售下沉的意义。另外，如果预先承诺了发货时间，则还可以携带上该承诺的发货时间，以便物流服务提供方根据该承诺的发货时间进行发货。

预发货单用于支持物流服务提供方执行发货操作，在生成该预发货单的初始状态，该预发货单可以处于“出库中”状态，此时，对应的物流订单处于“待发货状态”。在物流服务提供方执行了发货之后，可以回传确认出库信息，例如，首先回传到仓储中心服务器，发货中心服务器可以监听仓储中心服务器的确认出库消息，将预发货单修改为“已出库”状态，然后可以调用订单中心服务器的接口，将第二物流订单的状态更新为“预售出库中”状态，另外，订单中心服务器还可以确定出该第二物流订单对应的第一物流订单，并将其同步更新为“预售出库中”状态，此时，第一用户就可以通过查询该第一物流订单，获知具体的物流详情信息。

定金期结束后，会进入到尾款期，而对于具体的某个交易订单而言，是否进入尾款期，还需要结合用户的具体操作来判断。在本申请实施例中，一个B2C交易订单是否进入尾款期，也可以不再由第一用户支付尾款这一个条件来 推动，而是要再增加一个条件，也即，第二用户向第三用户付款。也就是说，交易中心服务器在接收到第一用户为指定B2C交易订单支付尾款的操作后，可以通知给供销平台服务器，供销平台服务器在确定出第二用户已经针对对应的B2B采购单完成了向第三用户的付款操作之后，再向物流中心服务器发送B2B采购单已经支付尾款的通知消息，物流中心服务器在接收到该通知消息后，可以调用订单中心服务器的接口，为对应的第二物流订单添加尾款标识，订单中心服务器在为第二物流订单添加尾款标识时，还可以确定出对应的第一物流订单，并且为第一物流订单也添加上尾款标识。

该尾款标识是很重要的，这是因为：在一般的交易过程中，如果仓储发货单对应的货物在仓库完成出库操作，仓储会回传确认出库消息给发货中心服务器，发货中心服务器会将物流订单的状态置为已出库，同时同步通知交易中心服务器已发货。但是对于预售下沉订单，在没有打尾款标前，意味者第一用户没有付尾款，这个时候即使仓储已经完成出库操作，也仅仅是将货物运送到网点，并不会给消费者配送，因此，不能通知交易已发货(如果通知交易已发货可能会让第一用户以为自己不需要付尾款了)。所以，尾款标识是物流端确认第一用户是否已经付尾款的标准，同时，可以针对是否有这个尾款标识，进行不同的状态机流转和物流操作逻辑。

物流中心服务器在确定出交易订单进入尾款期后，可以再进行后续的处理。具体的，在一个交易订单进入尾款期后，对应的采购单以及物流订单的状态却可能有多种。例如，有些第一用户可能在生成交易订单之后又取消了交易，例如，一直未付定金，直到付款超时，或者，支付了定金后又申请了退款等；另外，对于正常状态的采购单，由于第一用户的下单时间较晚等因素，也可能导致未能在定金期内完成货品的下沉，等等。这就使得采购单可能处于超时关闭/退款状态，或者待发货状态，或者已产生预出库单状态等，相应的，物流订单的状态也可能会不同。对于不同的状态，物流中心还可以分别设置不同的处理方式。

具体的，物流中心服务器在确定出交易订单进入尾款期后，则可以通过以下各步骤来进行：

向订单中心服务器查询对应的B2B采购单的状态，之后可能分为以下各种情况：

1.如果确定出该B2B采购单处于超时关闭/退款状态，则可以查询仓储中心服务器，确定是否已经针对该B2B采购单生成了预发货单；

1.1如果尚未产生预发货单，则停止发货，结束流程；

1.2如果已经产生预发货单，则向发货中心服务器查询预发货单的状态；

1.2.1如果预发货单处于“出库中”状态，也即物流订单处于“待出库”状态，则可以调用发货中心服务器的接口，取消该预发货单；

1.2.2如果预发货单处于“已出库”状态，也即物流订单处于“预售出库中”状态，则可以通知第二用户执行手动截单，已发出的货品可以再退回到原发货仓库。

2.如果确定出该B2B采购单处于待发货状态，则可以查询仓储中心服务器，确定是否已经针对该B2B采购单生成了预发货单；

2.1如果尚未产生预发货单，则查询交易中心服务器，是否发生申请退款；

2.1.1如果申请退款，则停止发货，结束流程；

2.1.2如果未申请退款，则进行二次路由，生成普通发货单，也即与常规的发货流程可以相同。

2.2如果已经产生预发货单，则向发货中心服务器查询预发货单的状态；

2.2.1如果预发货单处于“出库中”状态，则生成尾款消息给对应的物流服务提供方，由物流服务提供方进行发货重试；

2.2.2如果预发货单处于“已出库”状态，也即物流订单处 于“预售出库中”状态，则可以调用发货中心服务器的接口，通知发货中心服务器第二物流订单已发货，这样，发货中心服务器可以调用订单中心服务器接口，将对应的第二物流订单的状态修改为“已发货”状态，相应的，订单中心服务器还可以将对应的第一物流订单的状态同步修改为“已发货”状态，第一用户在通过交易中心服务器查询B2C交易订单的物流详情时，订单中心服务器就可以向交易中心服务器提供该信息，第一用户可以查看到该状态。

2.2.3如果预发货单处于取消、停止等状态，则可以通知第二用户进行手动处理。

总之，为了给第二用户统一的物流使用体验，对于同一笔交易可以仅进行一次自动发货，不再自动进行逆向的再发货流程，在自动发货不成功的情况下，可以给第二用户提供操作入口，使得第二用户可以手动处理。另外，在成功进行了自动发货的情况下，在通知订单中心修改物流订单状态时，可以仅通知其修改第二物流订单的状态为已发货，不直接通知对第一物流订单的状态进行修改，但是，可以由订单中心完成物流订单状态的同步。

以上对本申请实施例中从定金期到尾款期，再到后续的发货信息处理期进行了介绍，通过该方式，可以实现分销模式下，在定金期进行货品的下沉。

另外，在实际应用中，有些第一用户在生成交易订单后，可能会有需要修改收货地址的需求。如果不进行特殊处理，则通常只能将之前的交易订单取消，再重新生成新的订单。当时，在本申请实施例中，由于在一个交易订单生成之后，可能就已经进入自动发货流程，执行了定金期的货品下沉，此时，如果将交易订单取消，则意味着已经耗费的资源都成为了一种浪费，甚至可能还需要执行逆向流程，将已经发出的货品退回到发货仓库，等等。因此，在具体实现时，可以尽量降低交易订单取消情况的产生。例如，针对前述第一用户只是想修改收货地址，而其他的信息不需要修改的情况下，可以提供一种更智能的处理方式。

具体的，可以在交易订单等页面中为第一用户提供执行修改收货地址的操作选项，如果第一用户需要修改地址，则可以通过该操作选项发起请求，而不需要将交易订单取消。交易中心服务器在收到该修改地址的请求后，可以发送到物流中心服务器，物流中心服务器可以查询订单中心服务器，是否已经针对该交易订单生成了物流订单。如果已经生成了物流订单，还可以判断是否已经针对该物流订单生成了预发货单，如果预发货单已生成，则可以不再接受该请求，也即可以返回失败。如果尚未生成预发货单，则可以根据新输入的收货地址，重新根据仓库列表中各个仓库的配送覆盖范围，选择出优先权最高的发货仓库，并调用发货中心服务器的接口，将物流订单中的收货地址修改为新的收货地址，将发货仓库修改为新的发货仓库。并且，还可以将占用的原来发货仓库的库存释放。

可见，通过这种方式，在定金期，预发货单未创建的时候，第一用户可以直接改交易订单中的收货地址，而不需要将原交易订单取消，再重新生成新的交易订单，优化了第一用户的物流体验，也节省了系统的资源。当然，如果预发货单已经创建，则第一用户只能将原来的交易订单取消，此时，可以通知第二用户进行截单等操作。

通过以上所述，对本申请实施例中提供的方案进行了详细介绍，下面分别从前端交易中心服务器(用于向第二用户提供前端交互界面等信息的服务器)、供销平台服务器(用于管理供货商与分销商关系等信息的服务器)、物流中心服务器(用于管理物流信息的服务器，例如菜鸟平台的服务器等)、仓库中心服务器(用于管理入库、发货等处理的服务器)等角度出发，对本申请实施例进行详细介绍。

实施例一

参见图1，本申请实施例一首先从前端交易中心服务器的角度提供了一种商品对象物流信息处理方法，该方法可以包括以下步骤：

S101：前端交易中心服务器在目标交易订单的定金期内，确定所述目标交 易订单关联的前端商品对象、第一用户以及第二用户，并判断所述第二用户是否为分销商用户，其中，所述第一用户为消费者用户；

S102：如果确定出所述第二用户是分销商用户，则通知供销平台服务器创建对应的采购单，以便通过所述采购单建立第二用户与第三用户在此次交易中的关联关系，并将所述采购单已创建的消息通知给物流中心服务器，所述物流中心服务器在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作；其中，所述第三用户为供货商用户。

其中，所述物流中心服务器创建的物流订单包括：针对所述目标交易订单创建的第一物流订单，以及针对所述采购单创建的第二物流订单，其中，由订单中心服务器根据所述第二物流订单的状态，同步更新所述第一物流订单的状态。在这种情况下，前端交易中心服务器还可以在接收到查看所述目标交易订单物流详情信息的请求时，将所述请求发送到所述订单中心服务器，以便所述订单中心服务器返回所述第一物流订单的当前状态信息。

另外，在本申请实施例中，前端交易中心服务器还可以接收修改目标交易订单关联的收货地址的请求，在判断出所述目标交易订单处于定金期时，可以将所述修改后的收货地址发送到物流中心服务器，以便所述物流中心服务器通过查询订单中心服务器确定对应的物流订单状态，并根据物流订单的状态进行处理。

实施例二

该实施例二主要从供销平台服务器的角度进行介绍，参见图2，该实施例二提供了一种商品对象物流信息处理方法，该方法可以包括以下步骤：

S201：供销平台服务器接收前端交易中心服务器发送的针对目标交易订单创建采购单的请求；

S202：确定所述目标交易订单的状态；

S203：如果所述目标交易订单处于定金期，则创建采购单，并通知物流中心服务器创建物流订单，以便所述物流中心服务器在在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作。

具体实现时，可以将所述采购单置为锁定状态，以便拒绝在定金期对所述采购单执行的手动操作请求。

在接收到所述前端交易中心服务器发送的所述目标交易订单更新到已支付尾款状态的通知消息后，可以对所述采购单的状态进行监控，如果第二用户针对所述采购单完成向第三用户的付款操作，则通知所述物流中心服务器所述目标交易订单进入尾款期，以便所述物流中心服务器在接收到该通知消息后，通知订单中心服务器为对应的物流订单添加尾款标识。

实施例三

该实施例三主要从物流中心服务器的角度进行介绍，参见图3，该实施例三提供了一种商品对象物流信息处理方法，参见图3，该方法可以包括以下步骤：

S301：物流中心服务器接收供销平台服务器发送的采购单已创建的通知消息；

S302：确定所述采购单对应的目标交易订单所处的状态；

S303：如果所述目标交易订单处于定金期，则判断所述目标交易订单关联的目标商品对象是否需要下沉；

S304：如果需要下沉，则根据所述采购单关联的目标商品对象信息、第一用户的地址信息、以及第三用户订购的物流资源信息，创建对应的物流订单，并通过调用发货中心服务器的接口创建预发货单，以便在定金期进行对应货品的下沉发货操作。

具体实现时，可以为所述目标交易订单创建第一物流订单，为所述采购单 创建第二物流订单，并为所述第一物流订单以及第二物流订单添加预置标识，所述预置标识用于表明对应的货品需要下沉。

在通过调用发货中心服务器的接口创建预发货单时，还可以在调用请求中携带尾款期开始时间，以及预先向第二用户承诺的发货时间，以便物流服务提供方在尾款期开始之前，按照所述承诺的发货时间进行下沉。

另外，物流中心服务器还可以接收交易中心服务器发送的修改收货地址的请求，此时，可以查询订单中心服务器，判断是否已经为所述目标交易订单创建了物流订单，如果已创建，则判断是否已创建对应的预发货单，如果预发货单已创建，则返回失败响应；如果预发货单未创建，则根据修改后的收货地址重新路由，确定新的发货仓库，并调用发货中心服务器的接口，修改物流订单中的收货地址以及发货仓库，将占用的原发货仓库的库存进行释放。

在确定出第一用户为所述目标交易订单支付了尾款，并且第二用户通过所述采购单完成向第三用户的付款操作后，可以确定所述目标交易订单进入尾款期，并通过调用订单中心服务器的接口，为物流订单添加尾款标识。

在确定所述目标交易订单进入尾款期之后，还可以调用订单中心服务器接口查询所述目标交易订单对应的采购单的状态；如果采购单处于超时关闭或者退款状态，则查询仓储中心服务器，判断是否为所述采购单创建了预发货单，如果未产生则停止发货，如果已产生，则判断所述预发货单的状态，如果预发货单处于出库中状态，则通过调用发货中心服务器的接口取消该预发货单，如果预发货单处于已出库状态，则通知第二用户执行截单操作。

如果采购单处于待发货状态，则查询仓储中心服务器，判断是否为所述采购单创建了预发货单，如果未产生，则查询交易中心服务器，判断是否发生申请退款，如果申请退款，则停止发货，如果未申请退款，则生成普通发货单；如果已产生预发货单，则向发货中心服务器查询预发货单的状态，如果预发货单处于出库中状态，则生成尾款消息给对应的物流服务提供方，由物流服务提供方进行发货重试，如果预发货单处于已出库状态，则调用发货中心服务器的接口，通知发货中心服务器物流订单已发货，以便发货中心服务器调用订单中 心服务器的接口，将物流订单的状态更新为已发货状态。

实施例四

该实施例四主要从仓储中心服务器的角度进行介绍，参见图4，该实施例四提供了一种商品对象物流信息处理方法，该方法可以包括以下步骤：

S401：仓储中心服务器检测到针对目标物流订单完成发货操作的事件后，判断所述目标物流订单是否带有预置标识，所述预置标识用于表明对应的货品在定金期执行下沉操作；

S402：如果带有所述预置标识，则向订单中心服务器回传确认出库的消息，并将所述目标物流订单的状态更新为预售出库中状态。

需要说明的是，以上实施例一至实施例四中各步骤的具体实现，可以参见前文中对本申请实施例的详细描述，这里不再赘述。

总之，通过本申请实施例，对于分销场景下的预售下沉，可以在定金期就创建采购单，从而提前建立起第二用户与第三用户在此次交易过程中的关联关系，进而就可以根据第三用户对物流资源的订购情况等信息进行路由，创建起物流订单，另外还可以创建预发货单，从而实现在分销场景下的预售下沉，使得更多的交易订单能够进行预售下沉。

与实施例一提供的商品对象物流信息处理方法相对应，本申请实施例还提供了一种商品对象物流信息处理装置，应用于前端交易中心服务器，参见图5，该装置可以包括：

交易订单信息确定单元501，用于在目标交易订单的定金期内，确定所述目标交易订单关联的前端商品对象、第一用户以及第二用户，并判断所述第二用户是否为分销商用户，其中，所述第一用户为消费者用户；

通知单元502，用于如果确定出所述第二用户是分销商用户，则通知供销 平台服务器创建对应的采购单，以便通过所述采购单建立第二用户与第三用户在此次交易中的关联关系，并将所述采购单已创建的消息通知给物流中心服务器，所述物流中心服务器在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作；其中，所述第三用户为供货商用户。

其中，所述物流中心服务器创建的物流订单包括：针对所述目标交易订单创建的第一物流订单，以及针对所述采购单创建的第二物流订单，其中，由订单中心服务器根据所述第二物流订单的状态，同步更新所述第一物流订单的状态；

所述装置还包括：

查看请求接收单元，用于接收到查看所述目标交易订单物流详情信息的请求时，将所述请求发送到所述订单中心服务器，以便所述订单中心服务器返回所述第一物流订单的当前状态信息。

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

收货地址修改请求接收单元，用于接收修改目标交易订单关联的收货地址的请求；

判断单元，用于判断所述目标交易订单是否处于定金期；

收货地址发送单元，用于如果处于定金期，则将所述修改后的收货地址发送到物流中心服务器，以便所述物流中心服务器通过查询订单中心服务器确定对应的物流订单状态，并根据物流订单的状态进行处理。

与实施例二提供的商品对象物流信息处理方法相对应，本申请实施例还提供了一种商品对象物流信息处理装置，应用于供销平台服务器，参见图6，该装置可以包括：

采购单创建请求接收单元601，用于接收前端交易中心服务器发送的针对目标交易订单创建采购单的请求；

订单状态确定单元602，用于确定所述目标交易订单的状态；

采购单创建单元603，用于如果所述目标交易订单处于定金期，则创建采购单，并通知物流中心服务器创建物流订单，以便所述物流中心服务器在在判断出所述前端商品对象为需下沉的商品对象后，创建对应的物流订单，并针对所述物流订单创建预发货单，在定金期进行对应货品的下沉发货操作。

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

锁定单元，用于将所述采购单置为锁定状态，以便拒绝在定金期对所述采购单执行的手动操作请求。

监控单元，用于在接收到所述前端交易中心服务器发送的所述目标交易订单更新到已支付尾款状态的通知消息后，对所述采购单的状态进行监控；

尾款期确定单元，用于如果第二用户针对所述采购单完成向第三用户的付款操作，则通知所述物流中心服务器所述目标交易订单进入尾款期，以便所述物流中心服务器在接收到该通知消息后，通知订单中心服务器为对应的物流订单添加尾款标识。

与实施例三提供的商品对象物流信息处理方法相对应，本申请实施例还提供了一种商品对象物流信息处理装置，应用于物流中心服务器，参见图7，该装置可以包括：

通知消息接收单元701，用于接收供销平台服务器发送的采购单已创建的通知消息；

交易订单状态确定单元702，用于确定所述采购单对应的目标交易订单所处的状态；

判断单元703，用于如果所述目标交易订单处于定金期，则判断所述目标交易订单关联的目标商品对象是否需要下沉；

物流订单创建单元704，用于如果需要下沉，则根据所述采购单关联的目 标商品对象信息、第一用户的地址信息、以及第三用户订购的物流资源信息，创建对应的物流订单，并通过调用发货中心服务器的接口创建预发货单，以便在定金期进行对应货品的下沉发货操作。

其中，所述物流订单创建单元具体用于：

为所述目标交易订单创建第一物流订单，为所述采购单创建第二物流订单，并为所述第一物流订单以及第二物流订单添加预置标识，所述预置标识用于表明对应的货品需要下沉。

所述通过调用发货中心服务器的接口创建预发货单时，在调用请求中携带尾款期开始时间，以及预先向第二用户承诺的发货时间，以便物流服务提供方在尾款期开始之前，按照所述承诺的发货时间进行下沉。

另外，该装置还可以包括：

修改地址请求接收单元，用于接收交易中心服务器发送的修改收货地址的请求；

第一处理单元，用于查询订单中心服务器，判断是否已经为所述目标交易订单创建了物流订单，如果已创建，则判断是否已创建对应的预发货单，如果预发货单已创建，则返回失败响应；如果预发货单未创建，则根据修改后的收货地址重新路由，确定新的发货仓库，并调用发货中心服务器的接口，修改物流订单中的收货地址以及发货仓库，将占用的原发货仓库的库存进行释放。

尾款期确定单元，用于在确定出第一用户为所述目标交易订单支付了尾款，并且第二用户通过所述采购单完成向第三用户的付款操作后，确定所述目标交易订单进入尾款期，并通过调用订单中心服务器的接口，为物流订单添加尾款标识。

采购单状态查询单元，用于在确定所述目标交易订单进入尾款期之后，调用订单中心服务器接口查询所述目标交易订单对应的采购单的状态；

第二处理单元，用于如果采购单处于超时关闭或者退款状态，则查询仓储中心服务器，判断是否为所述采购单创建了预发货单，如果未产生则停止发货， 如果已产生，则判断所述预发货单的状态，如果预发货单处于出库中状态，则通过调用发货中心服务器的接口取消该预发货单，如果预发货单处于已出库状态，则通知第二用户执行截单操作；

第三处理单元，用于如果采购单处于待发货状态，则查询仓储中心服务器，判断是否为所述采购单创建了预发货单，如果未产生，则查询交易中心服务器，判断是否发生申请退款，如果申请退款，则停止发货，如果未申请退款，则生成普通发货单；如果已产生预发货单，则向发货中心服务器查询预发货单的状态，如果预发货单处于出库中状态，则生成尾款消息给对应的物流服务提供方，由物流服务提供方进行发货重试，如果预发货单处于已出库状态，则调用发货中心服务器的接口，通知发货中心服务器物流订单已发货，以便发货中心服务器调用订单中心服务器的接口，将物流订单的状态更新为已发货状态。

与实施例四提供的商品对象物流信息处理方法相对应，本申请实施例还提供了一种商品对象物流信息处理装置，应用于仓储中心服务器，参见图8，该装置可以包括：

检测单元801，用于检测到针对目标物流订单完成发货操作的事件后，判断所述目标物流订单是否带有预置标识，所述预置标识用于表明对应的货品在定金期执行下沉操作；

消息回传单元802，用于如果带有所述预置标识，则向订单中心服务器回传确认出库的消息，并将所述目标物流订单的状态更新为预售出库中状态。

通过本申请实施例，对于分销场景下的预售下沉，可以在定金期就创建采购单，从而提前建立起第二用户与第三用户在此次交易过程中的关联关系，进而就可以根据第三用户对物流资源的订购情况等信息进行路由，创建起物流订单，另外还可以创建预发货单，从而实现在分销场景下的预售下沉，使得更多的交易订单能够进行预售下沉。

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

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

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