本申请涉及地址信息处理技术领域，特别是涉及地址修改信息处理方法及装置。
背景技术：
为了提高消费者对大家电等商品对象的购物体验，一些电子商务销售平台向商家提供了同一的仓储以及配送管理系统。例如，淘系的电器城商家首先必须要入驻到菜鸟实仓(大家电仓库，每个仓库都有自己的配送覆盖范围，给消费者提供确定性的物流服务体验)，消费者在淘宝详情或者购买页面中查看宝贝时，根据消费者所在的地址匹配菜鸟实仓的覆盖区域范围，如果匹配上后则会将菜鸟实仓中的库存展示给消费者，消费者付款下单后，会生成一个物流订单流入到菜鸟系统，菜鸟系统对其进行发货，而后“卖家的货物”经过一系列的配送环节派送到消费者手上。
消费者下单后由于各种原因可能会有修改收货地址的需求，比如：下单时选错了收货地址，填错了地址等等。目前现有的操作流程是：消费者在前台完成收货地址的修改，商家再根据新的收货地址生成仓储作业订单(仓库出库指令)。但是，生成仓储作业订单的条件是仓库能够覆盖该收货地址，并且仓库内有库存。由于之前交易订单已经占用在一个仓库上了，消费者修改地址极有可能造成该仓库无法覆盖新地址，即使覆盖新地址也有可能库存不足无法生成仓储作业订单。当“双11”等节日巨大单量来临时，这种问题的出现将给商家的正常运营带来极大的困难，也使得消费者由于长时间无法收到货品，而影响到购物体验。
因此，如何在不影响消费者的购物体验前提下，降低商家由于改地址造成的运营困扰，是一个迫切需要解决的问题。
技术实现要素：
本申请提供了地址修改信息处理方法及装置，能够解决由于改地址带来的发货延迟等问题。
本申请提供了如下方案：
一种地址修改信息处理方法，其特征在于，包括：
第一服务器接收到针对目标交易订单执行修改收货地址的请求时，确定新收货地址；
根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，所述符合预置条件的目标仓库为：配送覆盖范围可涵盖所述新收货地址且库存充足的仓库；
如果存在，则对关联的订单中的信息进行修改，以便按照修改后的信息向所述新收货地址进行发货处理。
一种地址修改信息处理方法，其特征在于，包括：
第三用户客户端接收针对目标交易订单的收货地址修改请求；
将所述请求转发给第一服务器，以便第一服务器确定新收货地址，并根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，如果存在，则对关联的订单中的信息进行修改，并向所述客户端返回所述目标仓库的标识以及库存信息；所述符合预置条件的目标仓库为：配送覆盖范围可涵盖新收货地址且库存充足的仓库；
提供所述目标仓库的标识以及库存信息。
一种地址修改信息处理装置，其特征在于，应用于第一服务器，包括：
请求接收单元，用于接收到针对目标交易订单执行修改收货地址的请求时，确定新收货地址；
目标仓库确定单元，用于根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，所述符合预置条件的目标仓库为：配送覆盖范围可涵盖所述新收货地址且库存充足的仓库；
订单信息修改单元，用于如果存在所述目标仓库，则对关联的订单中的信息进行修改，以便按照修改后的信息向所述新收货地址进行发货处理。
一种地址修改信息处理装置，其特征在于，应用于第三用户客户端，包括：
请求接收单元，用于接收针对目标交易订单的收货地址修改请求；
请求转发单元，用于将所述请求转发给第一服务器，以便第一服务器确定新收货地址，并根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，如果存在，则对关联的订单中的信息进行修改，并向所述客户端返回所述目标仓库的标识以及库存信息；所述符合预置条件的目标仓库为：配送覆盖范围可涵盖新收货地址且库存充足的仓库；
信息提供单元，用于提供所述目标仓库的标识以及库存信息。
根据本申请提供的具体实施例，本申请公开了以下技术效果：
通过本申请实施例，第三用户在修改收货地址时，不再是无条件地修改，而当有地址修改请求时，系统首先判断当前是否存在符合条件的仓库，也即，仓库配送范围覆盖新收货地址，并且仓库库存充足，如果有，则允许第三用户修改。这样，由于已经提前进行了覆盖范围、库存等信息的判断，因此，对于修改地址的订单，第二用户不再需要做补货等操作才能发货，而是直接选用系统选择的仓库来发货即可。这样，就可以有效地解决由于改地址带来的发货延迟等问题。
当然，实施本申请的任一产品并不一定需要同时达到以上所述的所有优点。
附图说明
为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的方法的流程图；
图2是本申请实施例提供的另一方法的流程图；
图3是本申请实施例中非分销场景下的信息交互流程图；
图4是本申请实施例中分销场景下的信息交互流程图；
图5是本申请实施例提供的装置的示意图；
图6是本申请实施例提供的另一装置的示意图。
具体实施方式
下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员所获得的所有其他实施例，都属于本申请保护的范围。
在本申请实施例中，消费者用户(也称“买家用户”等，在本申请实施例中可以称为第三用户)修改收货地址时，不再是无条件地修改，而当有地址修改请求时，系统会判断当前是否存在符合以下条件的仓库：1)仓库配送范围覆盖新地址；2)仓库库存充足；如果有，则允许第三用户修改成功；否则第三用户修改地址失败。对于修改地址的订单，商家用户(或者称为“卖家用户”，在本申请实施例中称为第二用户)不再需要做补货等操作才能发货，而是直接选用系统选择的仓库来发货即可。这样，就可以有效地解决由于改地址带来的发货延迟等问题。当然，在具体实现过程中，还会涉及到前后端的高效协同等处理，包括对各类订单状态的一致性处理等等。下面对具体的实现方式进行详细介绍。
实施例一
该实施例一首先从第一服务器的角度，提供了一种地址修改信息处理方法，其中，所谓的第一服务器是指电子商务交易平台中部署的一服务器，例如，在实际应用中，可以是库存管理子系统的服务器，称为“ipm”，等等。当然，在具体实现时，该服务器的具体名称，以及与其他服务器之间的相互逻辑关系等，都可以根据实际应用中的需要来进行设定。参见图1，该方法可以包括以下步骤：
s101：第一服务器接收到针对目标交易订单执行修改收货地址的请求时，确定新收货地址；
具体实现时，在第三用户通过交易平台系统购买了商品对象后，系统会生成相应的交易订单，并且，还可以向第三用户提供多种操作选项，以便第三用户对交易订单进行操作，例如，可以查询交易订单状态，对交易订单执行确认收货操作，等等。因此，在本申请实施例中，也可以提供用于对交易订单执行修改收货地址的操作选项，第三用户在需要修改某交易订单的收货地址时，就可以通过该操作选项，向系统发出修改请求，相应的，第一服务器就可以接收到该请求。
在收到该请求后，还可以确定出新的收货地址，该收货地址通常可以是由第三用户输入的。具体实现时，可以在操作选项被触发后，直接由客户端提供用于输入新收货地址的输入控件(例如，输入框等)，这样，在客户端将修改请求提交到服务器时，就可以直接将新收货地址携带在修改请求中，服务器可以直接从修改请求中提取相应的新收货地址信息。或者，考虑到有些情况下，交易订单的收货地址可能是不允许修改的，例如，某交易订单关联的物流订单处于关闭状态，或者已经生成仓储作业订单(也即仓库已经发货，或者已经完成打包等准备工作)状态，等等。因此，在另一种实现方式下，还可以是在操作选项被触发后，客户端就直接通知给第一服务器，由第一服务器对关联的物流订单状态进行判断后，确定出是否允许修改收货地址，如果允许，再通知给客户端，客户端再提供相应的输入控件，由第三用户输入具体的新收货地址后，再将新收货地址提交到第一服务器。关于第一服务器对是否允许修改收货地址 的具体判断，在后文中会有详细介绍。
s102：根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，所述符合预置条件的目标仓库为：配送覆盖范围可涵盖所述新收货地址且库存充足的仓库；
在确定出新收货地址后，第一服务器可以首先确定出目标交易订单中关联的商品对象，进而可以确定出该商品对象的仓库列表，以及各个仓库的配送范围信息。其中，关于商品对象关联的仓库列表，可以是由第二用户其发布的各个商品选择物流解决方案时选定的仓库，并记录在销售平台的具体数据库中，这些仓库就可以是本申请实施例背景技术部分所述的“菜鸟仓”等由销售平台统一提供的仓库，由于仓库是由销售平台统一提供的，因此，每个仓库对应的配送范围信息对于销售平台而言是已知的。另外，对于商品对象在各个仓库中的库存信息，是由库存中心服务器进行统一保存以及更新。因此，在确定出新收货地址后，第一服务器就可以判断目标商品对象关联的仓库列表中是否存在符合条件的目标仓库，所谓的符合预置条件也即配送范围能够覆盖新收货地址，并且库存充足。其中，关于配送覆盖范围是否能够覆盖新收货地址以及库存是否充足的具体判断方式，并不是本申请实施例关注的重点，因此，这里不再详述。总之，在本申请实施例中，在收到第三用户的修改地址请求后，就可以首先进行目标仓库的确定，只有在确定出存在符合条件的目标仓库的情况下，才可以进行收货地址的修改。当然，为了保证及时发货，避免出现需要重新进行货品的调拨等操作，还可以对库存中心的库存占用情况进行修改，具体可以是释放之前的仓库中占用的库存，并增加对新目标仓库的库存占用。
s103：如果存在，则对关联的订单中的信息进行修改，以便按照修改后的信息向所述新收货地址进行发货处理。
在确定出存在符合条件的目标仓库的情况下，还可以对关联的一些订单中的信息进行修改，使得后续的发货操作可以是依据修改后的新收货地址进行。具体实现时，考虑到具体的销售场景通常包括分销场景以及普通的非分销场景，而在不同的场景下，具体的处理流程、产生的订单数量、类型等有所不同，因此，在本申请实施例中，可以首先进行交易订单类型的判断，也即，判断所述 目标交易订单是否为分销场景中生成的交易订单，以便根据判断结果确定所述对关联的订单中的信息的修改方式。其中，具体实现时，如果是分销场景中生成的交易订单，则可以在交易订单中添加相应的标识等，因此，可以通过这种标识，进行交易订单类型的判断。
场景一
如果目标交易订单不是分销场景中生成的交易订单，也即，是普通销售场景下产生的交易订单，则第二用户既是商品对象的销售方，也是控货方，在这种场景下，系统会针对生成的交易订单生成物流订单，在物流订单中记录具体的配送方信息等等，后续在执行具体的发货出库等操作时，可以根据物流订单执行具体的发货操作。
也就是说，在非分销场景下，具体的订单通常包括交易订单以及物流订单。在这种情况下，第一服务器在接收到针对目标交易订单的收货地址修改请求时，可以首先判断是否存在与该目标交易订单关联的物流订单，如果存在，则根据所述物流订单的状态，判断是否可修改收货地址，如果可修改，则可以触发所述确定修改后的新收货地址及后续步骤。也就是说，如果物流订单已创建，则可以进一步判断当前的发货进展，例如，判断物流订单是否处于已关闭(例如已申请退款等)，或者已创建仓储作业订单(例如仓库已经做好出库准备或者已出库等)的状态，如果是，则不允许修改收货地址，否则，就处于可修改状态。在根据新收货地址确定出符合条件的目标仓库后，所谓的对关联的订单中的信息进行修改，就可以是对该物流订单中的信息进行修改，具体的，可以将所述物流订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库。
如果不存在与当前的目标交易订单关联的物流订单，则由于具体的发货操作需要基于物流订单进行，因此，可以证明该交易订单一定尚未进入发货状态，因此，可以直接判定该交易订单处于可修改收货地址的状态。在根据新收货地址确定出目标仓库后，所谓的对关联的订单中的信息进行修改，就可以对该目标交易订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库，这样，后续在创建物流订单是，就可以直接根据修改后的目标交易订单中 的信息创建对应的物流订单，进而，后续的发货操作也都会基于物流订单中的新收货地址进行。
场景二
所谓的分销场景也即第二用户作为分销方用户，本身并不控货，货品由第一用户(也即供货方用户)统一提供并管理，第二用户只是将第一用户提供的后端商品对象发布为前端商品对象(也称“前端宝贝”)，第三用户从第二用户的店铺中购买具体的前端商品对象时，系统中可以产生对应的交易订单，并且，还可以生成用于建立第二用户与第三用户关系的第二物流订单；同时，系统中往往还存在专用于处理供销关系的供销平台服务器(本申请实施例中称为第四服务器)，在生成交易订单后，该第四服务器还可以在第二用户的触发操作下生成采购单，或者自动生成采购单(该采购单用于记录第一用户与第二用户之间的关系)。另外，系统中还可以存在个性化方案处理平台服务器(本申请实施例中可以称为第二服务器)，该第二服务器可以根据采购单生成用于创建第一用户、第二用户以及第三用户之间关系的第一物流订单。后续的发货操作会基于该第一物流订单执行，并将具体的发货状态更新到关联的第二物流订单中，使得前端的第三用户可以通过查询第二物流订单的状态，获取到具体的物流状态信息。
也就是说，在分销场景下，通常存在以下订单：交易订单、采购单、第一物流订单以及第二物流订单，其中，各个订单之间可以通过交易订单编码等信息关联起来，并且，每个订单中都可以记录有收货地址信息，因此，在修改地址的情况下，涉及到对各个订单中相关的信息进行一致性修改的问题，以避免系统出错。
具体实现时，在本申请实施例中，在产生了采购单的情况下，可以将采购单标识(例如，编号等)以及第一用户标识(例如，第一用户id等)同步更新到交易订单中，这样，第一用户可以通过交易订单中的这些信息，确定出是否为分销场景下的交易订单，并且，还可以根据交易订单中记录的采购单标识以及第一用户标识，判断是否存在与所述目标交易订单关联的第一物流订单(具体实现时，可以向物流订单中心服务器进行查询，或者也可以是其他实现 方式)，如果存在，则可以根据该第一物流订单的状态，判断是否允许进行收货地址修改操作，如果可修改，则触发所述确定修改后的新收货地址及后续步骤。并且，在此情况下，在根据新收货地址确定出目标仓库后，所谓的对关联的订单中的信息进行修改，具体可以是对第一物流订单中的信息进行修改，也即，将所述第一物流订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库，另外，还可以对所述目标交易订单关联的第二物流订单以及采购单中的信息修改为与所述第一物流订单中修改后的信息一致。
具体实现时，如果系统中部署了多台服务器，不同的服务器用于实现不同的功能，例如，可以存在专用于处理供销关系的服务器，专用于处理个性化解决方案的服务器，等等。此时，为了进行上述一致性操作，可以通过以下方式进行：
通过调用第二服务器(例如，个性化解决方案中心服务器等)的信息修改接口，对所述第一物流订单中的信息进行修改，并由所述第二服务器发布关于所述第一物流订单的第一信息修改消息，以便第三服务器(例如，物流订单管理中心服务器)通过监听该第一信息修改消息，对关联的第二物流订单进行信息修改，所述第三服务器在修改完成后发布关于所述第二物流订单的第二信息修改消息，以便第四服务器(例如，供销平台服务器)通过监听该第二信息修改消息，对关联的采购单进行信息修改。
如果不存在与目标交易订单关联的第一物流订单，也即，第一物流订单可能尚未创建，此时，可以判断是否存在与该目标交易订单关联的第二物流订单，如果存在，则可以根据该第二物流订单的状态判断是否允许进行收货地址修改操作，如果可修改，则触发所述确定修改后的新收货地址及后续步骤。此时，所谓的对关联的订单中的信息进行修改，具体可以是将所述第二物流订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库。当然，由于第二物流订单与采购单往往是在不同的系统中创建的，并且，相互之间并无依赖关系，因此，在存在第二物流订单状态下，虽然之前已经判断出不存在第一物流订单，但是，还是可能已经生成采购单的，因此，在这种情况下，还可以判断是否存在关联的采购单，如果存在，则将采购单中的信息修改为与所述第 二物流订单中修改后的信息一致，以便根据所述采购单中修改后的信息生成第一物流订单。也就是说，后续在创建第一物流订单时，由于是根据采购单中的信息创建的，因此，在采购单中的信息已修改的情况下，后续创建的第一物流订单中的信息自然会与第二物流订单中的信息一致。当然，如果不存在关联的采购单，则证明采购单以及第一物流订单均尚未创建，此时，在修改了第二物流订单中信息的情况下，还可以对目标交易订单中的收货地址信息进行修改，这样，由于采购单是基于目标交易订单中的信息创建的，而第一物流订单又是基于采购单中的信息创建的，因此，后续在创建采购单以及第一物流订单时，可以保证与修改后的第二物流订单中的信息一致。
总之，通过本申请实施例，第三用户在修改收货地址时，不再是无条件地修改，而当有地址修改请求时，系统首先判断当前是否存在符合条件的仓库，也即，仓库配送范围覆盖新收货地址，并且仓库库存充足，如果有，则允许第三用户修改。这样，由于已经提前进行了覆盖范围、库存等信息的判断，因此，对于修改地址的订单，第二用户不再需要做补货等操作才能发货，而是直接选用系统选择的仓库来发货即可。这样，就可以有效地解决由于改地址带来的发货延迟等问题。
实施例二
该实施例二是与实施例一相对应的，从第三用户客户端的角度进行的介绍。参见图2，该实施例二提供了一种地址修改信息处理方法，该方法可以包括以下步骤：
s201：第三用户客户端接收针对目标交易订单的收货地址修改请求；
s202：将所述请求转发给第一服务器，以便第一服务器确定新收货地址，并根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，如果存在，则对关联的订单中的信息进行修改，并向所述客户端返回所述目标仓库的标识以及库存信息；所述符合预置条件的目标仓库为：配送覆盖范围可涵盖新收货地址且库存充足的仓库；
s203：提供所述目标仓库的标识以及库存信息。
其中，具体实现时，第一服务器在确定出目标仓库之后，还可以根据新收货地址以及所述目标仓库确定出配送时效信息(也即，预计的送达的时间信息)，并返回给第三用户客户端，因此，第三用户客户端还可以提供所述配送时效信息。这样，使得第三用户在修改收货地址时，可以获知修改后的发货仓库以及送达时间，进行还可以据此确定该配送时效是否符合自己的心理预期，并确定是否要继续进行地址修改，等等。
由于该实施例二是与实施例一相对应的，因此，相关的具体实现可以参见实施例一中的介绍，这里不再赘述。
为了更好的理解本申请实施例，下面通过非分销场景以及分销场景下的具体例子中的信息交互流程图，进行详细介绍。
参见图3，在非分销场景下，涉及到的交互实体包括交易中心服务器(tc)、库存中心服务器(ipm)、物流订单中心服务器lc以及负责商品对象相关物流业务的核心系统服务器(delivery)，其中，delivery处在前台交易系统tc和与后端物流系统lc之间。在本申请实施例中，在修改地址过程中的交互流程可以包括：
1：tc接收消费者改地址的请求；
1.1：tc调用ipm的修改地址接口；
1.1.1：ipm收到请求后，从lc查询物流订单的状态；
1.1.2：ipm根据物流订单的状态判断是否允许修改地址；
1.1.3：如果允许修改，则首先可以利用三级地址id，向delivery进行仓库路由；
1.1.4：路由出新仓库后，占用新仓库存；
1.1.5：根据四级地址，修改物流订单中的收货地址和仓库编码；
1.1.6：释放老库存；
1.2：ipm通知tc仓库编码已修改；
1.3：如果没有物流订单，则可以直接修改交易订单上的收货地址，否则，可以不修改交易订单中的收货地址。
参见图4，在分销场景下，除了图3中各实体，还涉及到供销平台服务器(gx)、用于提供个性化物流解决方案的服务器(vsp)，在该分销场景下，修改地址过程中的信息交互方式可以包括：
1：tc接收消费者付定金的请求时；
2：gx监听付定金款消息；
2.1：生成采购单；
2.2：给交易订单添加供货商userid以及采购单标识；
3：tc接收消费者修改地址的请求；
3.1：rc调用ipm的改地址接口；
3.1.1：ipm判断是否为分销订单；
3.1.2：如果是，解析出供货商userid以及采购单标识；
3.1.3：ipm向lc查询是否存在b2b物流订单；
3.1.4：如果没有查询到b2b物流订单，则向lc查询是否存在b2c物流订单；
3.1.5：利用三级地址id，向delivery进行仓库路由；
3.1.6：路由出新仓库后，占用新仓库存；
3.1.7：根据四级地址，修改查询到的物流订单(b2b或b2c)中的收货地址和仓库编码；
3.1.8：释放老库存；
3.2：tc在接收到修改完成的消息后，可以修改交易订单上的仓库编码；
3.3：如果没有查询到物流订单，则可以修改交易订单上的收货地址，否则，可以不必修改交易订单上的收货地址；
4：如果存在b2b物流订单，则vsp从lc监听b2b物流订单的修改消息；
5：根据监听到的b2b物流订单的修改消息，修改对应的b2c物流订单的收货地址；
6：gx监听b2c物流订单的地址修改消息；
7：根据监听到的b2c物流订单的修改消息，修改对应的采购单的收货地址。
与实施例一提供的地址修改信息处理方法相对应，本申请实施例还提供了一种地址修改信息处理装置，该装置应用于第一服务器，参见图5，该装置具体可以包括：
请求接收单元501，用于接收到针对目标交易订单执行修改收货地址的请求时，确定新收货地址；
目标仓库确定单元502，用于根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，所述符合预置条件的目标仓库为：配送覆盖范围可涵盖所述新收货地址且库存充足的仓库；
订单信息修改单元503，用于如果存在所述目标仓库，则对关联的订单中的信息进行修改，以便按照修改后的信息向所述新收货地址进行发货处理。
具体实现时，所述装置还可以包括：
订单类型判断单元，用于判断所述目标交易订单是否为分销场景中生成的交易订单，以便根据判断结果确定所述对关联的订单中的信息的修改方式。
其中，如果所述目标交易订单不是分销场景中生成的交易订单，则所述装置还包括：
第一判断单元，用于判断是否存在与所述目标交易订单关联的物流订单；
第二判断单元，用于如果存在所述物流订单，则根据所述物流订单的状态，判断是否可修改收货地址，如果可修改，则触发所述确定修改后的新收货地址及后续步骤。
所述订单信息修改单元具体用于：
将所述物流订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库。
另外，所述装置还包括：
触发单元，用于如果不存在所述物流订单，则判定为可修改收货地址，并触发所述确定修改后的新收货地址及后续步骤；
所述订单信息修改单元具体用于：
将所述目标交易订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库，以便根据修改后的目标交易订单中的信息创建对应的物流订单。
如果所述目标交易订单是分销场景中生成的交易订单，则所述装置还可以包括：
第三判断单元，用于判断是否存在与所述目标交易订单关联的第一物流订单，所述第一物流订单为用于记录第一用户、第二用户以及第三用户之间关系的物流订单，所述第一用户为供货方用户，所述第二用户为分销方用户；
第四判断单元，用于如果存在所述第一物流订单，则根据所述第一物流订单的状态，判断是否可修改收货地址，如果可修改，则触发所述确定修改后的新收货地址及后续步骤。
其中，如果存在所述第一物流订单，则所述订单信息修改单元包括：
第一修改子单元，用于将所述第一物流订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库；
第二修改子单元，用于对所述目标交易订单关联的第二物流订单以及采购单中的信息修改为与所述第一物流订单中修改后的信息一致；其中，所述第二物流订单为用于记录第二用户与第三用户之间关系的物流订单，所述第三用户为消费方用户。
具体实现时，所述订单信息修改单元具体可以用于：
通过调用第二服务器的信息修改接口，对所述第一物流订单中的信息进行修改，并由所述第二服务器发布关于所述第一物流订单的第一信息修改消息，以便第三服务器通过监听该第一信息修改消息，对关联的第二物流订单进行信息修改，所述第三服务器在修改完成后发布关于所述第二物流订单的第二信息修改消息，以便第四服务器通过监听该第二信息修改消息，对关联的采购单进行信息修改。
其中，如果不存在所述第一物流订单，则所述装置还包括：
第五判断单元，用于判断是否存在关联的第二物流订单，所述第二物流订单为用于记录第二用户与第三用户之间关系的物流订单，所述第三用户为消费方用户；
第六判断单元，用于如果存在所述第二物流订单，则根据所述第二物流订单的状态，判断是否可修改收货地址，如果可修改，则触发所述确定修改后的新收货地址及后续步骤。
如果存在所述第二物流订单，则所述订单信息修改单元具体用于：
将所述第二物流订单中的收货地址修改为所述新收货地址，发货仓库修改为所述目标仓库；
所述装置还包括：
一致性修改单元，用于判断是否存在关联的采购单，如果存在，则将采购单中的信息修改为与所述第二物流订单中修改后的信息一致，以便根据所述采购单中修改后的信息生成第一物流订单。
具体实现时，所述一致性修改单元还可以用于：
如果不存在关联的采购单，则将所述目标交易订单中的信息修改为与所述第二物流订单中修改后的信息一致，以便根据所述目标交易订单修改后的信息生成采购单以及第一物流订单。
另外，所述装置还可以包括：
库存占用信息修改单元，用于修改对应仓库中的库存占用信息。
与实施例一提供的地址修改信息处理方法相对应，本申请实施例还提供了一种地址修改信息处理装置，该装置应用于第三用户客户端，参见图6，该装置具体可以包括：
请求接收单元601，用于接收针对目标交易订单的收货地址修改请求；
请求转发单元602，用于将所述请求转发给第一服务器，以便第一服务器确定新收货地址，并根据所述目标交易订单关联的商品对象的仓库列表及各个仓库的配送覆盖范围信息，判断是否存在符合预置条件的目标仓库，如果存在，则对关联的订单中的信息进行修改，并向所述客户端返回所述目标仓库的标识以及库存信息；所述符合预置条件的目标仓库为：配送覆盖范围可涵盖新收货地址且库存充足的仓库；
信息提供单元603，用于提供所述目标仓库的标识以及库存信息。
其中，所述第一服务器返回的信息还包括根据所述新收货地址以及所述目标仓库确定出的配送时效信息，所述装置还包括：
时效信息提供单元，用于提供所述配送时效信息。
通过本申请实施例，第三用户在修改收货地址时，不再是无条件地修改，而当有地址修改请求时，系统首先判断当前是否存在符合条件的仓库，也即，仓库配送范围覆盖新收货地址，并且仓库库存充足，如果有，则允许第三用户修改。这样，由于已经提前进行了覆盖范围、库存等信息的判断，因此，对于修改地址的订单，第二用户不再需要做补货等操作才能发货，而是直接选用系统选择的仓库来发货即可。这样，就可以有效地解决由于改地址带来的发货延迟等问题。
通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。
本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统或系统实施例而言，由于其基本相似于方法实施例，所以描述得比较简单，相关之处参见方法实施例的部分说明即可。以上所描述的系统及系统实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。
以上对本申请所提供的地址修改信息处理方法及装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处。综上所述，本说明书内容不应理解为对本申请的限制。