本申請涉及地址信息處理技術(shù)領(lǐng)域，特別是涉及地址修改信息處理方法及裝置。

背景技術(shù)：

為了提高消費(fèi)者對大家電等商品對象的購物體驗，一些電子商務(wù)銷售平臺向商家提供了同一的倉儲以及配送管理系統(tǒng)。例如，淘系的電器城商家首先必須要入駐到菜鳥實倉(大家電倉庫，每個倉庫都有自己的配送覆蓋范圍，給消費(fèi)者提供確定性的物流服務(wù)體驗)，消費(fèi)者在淘寶詳情或者購買頁面中查看寶貝時，根據(jù)消費(fèi)者所在的地址匹配菜鳥實倉的覆蓋區(qū)域范圍，如果匹配上后則會將菜鳥實倉中的庫存展示給消費(fèi)者，消費(fèi)者付款下單后，會生成一個物流訂單流入到菜鳥系統(tǒng)，菜鳥系統(tǒng)對其進(jìn)行發(fā)貨，而后“賣家的貨物”經(jīng)過一系列的配送環(huán)節(jié)派送到消費(fèi)者手上。

消費(fèi)者下單后由于各種原因可能會有修改收貨地址的需求，比如：下單時選錯了收貨地址，填錯了地址等等。目前現(xiàn)有的操作流程是：消費(fèi)者在前臺完成收貨地址的修改，商家再根據(jù)新的收貨地址生成倉儲作業(yè)訂單(倉庫出庫指令)。但是，生成倉儲作業(yè)訂單的條件是倉庫能夠覆蓋該收貨地址，并且倉庫內(nèi)有庫存。由于之前交易訂單已經(jīng)占用在一個倉庫上了，消費(fèi)者修改地址極有可能造成該倉庫無法覆蓋新地址，即使覆蓋新地址也有可能庫存不足無法生成倉儲作業(yè)訂單。當(dāng)“雙11”等節(jié)日巨大單量來臨時，這種問題的出現(xiàn)將給商家的正常運(yùn)營帶來極大的困難，也使得消費(fèi)者由于長時間無法收到貨品，而影響到購物體驗。

因此，如何在不影響消費(fèi)者的購物體驗前提下，降低商家由于改地址造成的運(yùn)營困擾，是一個迫切需要解決的問題。

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

本申請?zhí)峁┝说刂沸薷男畔⑻幚矸椒把b置，能夠解決由于改地址帶來的發(fā)貨延遲等問題。

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

一種地址修改信息處理方法，其特征在于，包括：

第一服務(wù)器接收到針對目標(biāo)交易訂單執(zhí)行修改收貨地址的請求時，確定新收貨地址；

根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋所述新收貨地址且?guī)齑娉渥愕膫}庫；

如果存在，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，以便按照修改后的信息向所述新收貨地址進(jìn)行發(fā)貨處理。

一種地址修改信息處理方法，其特征在于，包括：

第三用戶客戶端接收針對目標(biāo)交易訂單的收貨地址修改請求；

將所述請求轉(zhuǎn)發(fā)給第一服務(wù)器，以便第一服務(wù)器確定新收貨地址，并根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，如果存在，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，并向所述客戶端返回所述目標(biāo)倉庫的標(biāo)識以及庫存信息；所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋新收貨地址且?guī)齑娉渥愕膫}庫；

提供所述目標(biāo)倉庫的標(biāo)識以及庫存信息。

一種地址修改信息處理裝置，其特征在于，應(yīng)用于第一服務(wù)器，包括：

請求接收單元，用于接收到針對目標(biāo)交易訂單執(zhí)行修改收貨地址的請求時，確定新收貨地址；

目標(biāo)倉庫確定單元，用于根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋所述新收貨地址且?guī)齑娉渥愕膫}庫；

訂單信息修改單元，用于如果存在所述目標(biāo)倉庫，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，以便按照修改后的信息向所述新收貨地址進(jìn)行發(fā)貨處理。

一種地址修改信息處理裝置，其特征在于，應(yīng)用于第三用戶客戶端，包括：

請求接收單元，用于接收針對目標(biāo)交易訂單的收貨地址修改請求；

請求轉(zhuǎn)發(fā)單元，用于將所述請求轉(zhuǎn)發(fā)給第一服務(wù)器，以便第一服務(wù)器確定新收貨地址，并根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，如果存在，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，并向所述客戶端返回所述目標(biāo)倉庫的標(biāo)識以及庫存信息；所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋新收貨地址且?guī)齑娉渥愕膫}庫；

信息提供單元，用于提供所述目標(biāo)倉庫的標(biāo)識以及庫存信息。

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

通過本申請實施例，第三用戶在修改收貨地址時，不再是無條件地修改，而當(dāng)有地址修改請求時，系統(tǒng)首先判斷當(dāng)前是否存在符合條件的倉庫，也即，倉庫配送范圍覆蓋新收貨地址，并且倉庫庫存充足，如果有，則允許第三用戶修改。這樣，由于已經(jīng)提前進(jìn)行了覆蓋范圍、庫存等信息的判斷，因此，對于修改地址的訂單，第二用戶不再需要做補(bǔ)貨等操作才能發(fā)貨，而是直接選用系統(tǒng)選擇的倉庫來發(fā)貨即可。這樣，就可以有效地解決由于改地址帶來的發(fā)貨延遲等問題。

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

附圖說明

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

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

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

圖3是本申請實施例中非分銷場景下的信息交互流程圖；

圖4是本申請實施例中分銷場景下的信息交互流程圖；

圖5是本申請實施例提供的裝置的示意圖；

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

具體實施方式

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

在本申請實施例中，消費(fèi)者用戶(也稱“買家用戶”等，在本申請實施例中可以稱為第三用戶)修改收貨地址時，不再是無條件地修改，而當(dāng)有地址修改請求時，系統(tǒng)會判斷當(dāng)前是否存在符合以下條件的倉庫：1)倉庫配送范圍覆蓋新地址；2)倉庫庫存充足；如果有，則允許第三用戶修改成功；否則第三用戶修改地址失敗。對于修改地址的訂單，商家用戶(或者稱為“賣家用戶”，在本申請實施例中稱為第二用戶)不再需要做補(bǔ)貨等操作才能發(fā)貨，而是直接選用系統(tǒng)選擇的倉庫來發(fā)貨即可。這樣，就可以有效地解決由于改地址帶來的發(fā)貨延遲等問題。當(dāng)然，在具體實現(xiàn)過程中，還會涉及到前后端的高效協(xié)同等處理，包括對各類訂單狀態(tài)的一致性處理等等。下面對具體的實現(xiàn)方式進(jìn)行詳細(xì)介紹。

實施例一

該實施例一首先從第一服務(wù)器的角度，提供了一種地址修改信息處理方法，其中，所謂的第一服務(wù)器是指電子商務(wù)交易平臺中部署的一服務(wù)器，例如，在實際應(yīng)用中，可以是庫存管理子系統(tǒng)的服務(wù)器，稱為“ipm”，等等。當(dāng)然，在具體實現(xiàn)時，該服務(wù)器的具體名稱，以及與其他服務(wù)器之間的相互邏輯關(guān)系等，都可以根據(jù)實際應(yīng)用中的需要來進(jìn)行設(shè)定。參見圖1，該方法可以包括以下步驟：

s101：第一服務(wù)器接收到針對目標(biāo)交易訂單執(zhí)行修改收貨地址的請求時，確定新收貨地址；

具體實現(xiàn)時，在第三用戶通過交易平臺系統(tǒng)購買了商品對象后，系統(tǒng)會生成相應(yīng)的交易訂單，并且，還可以向第三用戶提供多種操作選項，以便第三用戶對交易訂單進(jìn)行操作，例如，可以查詢交易訂單狀態(tài)，對交易訂單執(zhí)行確認(rèn)收貨操作，等等。因此，在本申請實施例中，也可以提供用于對交易訂單執(zhí)行修改收貨地址的操作選項，第三用戶在需要修改某交易訂單的收貨地址時，就可以通過該操作選項，向系統(tǒng)發(fā)出修改請求，相應(yīng)的，第一服務(wù)器就可以接收到該請求。

在收到該請求后，還可以確定出新的收貨地址，該收貨地址通?？梢允怯傻谌脩糨斎氲摹＞唧w實現(xiàn)時，可以在操作選項被觸發(fā)后，直接由客戶端提供用于輸入新收貨地址的輸入控件(例如，輸入框等)，這樣，在客戶端將修改請求提交到服務(wù)器時，就可以直接將新收貨地址攜帶在修改請求中，服務(wù)器可以直接從修改請求中提取相應(yīng)的新收貨地址信息?；蛘?，考慮到有些情況下，交易訂單的收貨地址可能是不允許修改的，例如，某交易訂單關(guān)聯(lián)的物流訂單處于關(guān)閉狀態(tài)，或者已經(jīng)生成倉儲作業(yè)訂單(也即倉庫已經(jīng)發(fā)貨，或者已經(jīng)完成打包等準(zhǔn)備工作)狀態(tài)，等等。因此，在另一種實現(xiàn)方式下，還可以是在操作選項被觸發(fā)后，客戶端就直接通知給第一服務(wù)器，由第一服務(wù)器對關(guān)聯(lián)的物流訂單狀態(tài)進(jìn)行判斷后，確定出是否允許修改收貨地址，如果允許，再通知給客戶端，客戶端再提供相應(yīng)的輸入控件，由第三用戶輸入具體的新收貨地址后，再將新收貨地址提交到第一服務(wù)器。關(guān)于第一服務(wù)器對是否允許修改收貨地址 的具體判斷，在后文中會有詳細(xì)介紹。

s102：根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋所述新收貨地址且?guī)齑娉渥愕膫}庫；

在確定出新收貨地址后，第一服務(wù)器可以首先確定出目標(biāo)交易訂單中關(guān)聯(lián)的商品對象，進(jìn)而可以確定出該商品對象的倉庫列表，以及各個倉庫的配送范圍信息。其中，關(guān)于商品對象關(guān)聯(lián)的倉庫列表，可以是由第二用戶其發(fā)布的各個商品選擇物流解決方案時選定的倉庫，并記錄在銷售平臺的具體數(shù)據(jù)庫中，這些倉庫就可以是本申請實施例背景技術(shù)部分所述的“菜鳥倉”等由銷售平臺統(tǒng)一提供的倉庫，由于倉庫是由銷售平臺統(tǒng)一提供的，因此，每個倉庫對應(yīng)的配送范圍信息對于銷售平臺而言是已知的。另外，對于商品對象在各個倉庫中的庫存信息，是由庫存中心服務(wù)器進(jìn)行統(tǒng)一保存以及更新。因此，在確定出新收貨地址后，第一服務(wù)器就可以判斷目標(biāo)商品對象關(guān)聯(lián)的倉庫列表中是否存在符合條件的目標(biāo)倉庫，所謂的符合預(yù)置條件也即配送范圍能夠覆蓋新收貨地址，并且?guī)齑娉渥恪Ｆ渲校P(guān)于配送覆蓋范圍是否能夠覆蓋新收貨地址以及庫存是否充足的具體判斷方式，并不是本申請實施例關(guān)注的重點，因此，這里不再詳述。總之，在本申請實施例中，在收到第三用戶的修改地址請求后，就可以首先進(jìn)行目標(biāo)倉庫的確定，只有在確定出存在符合條件的目標(biāo)倉庫的情況下，才可以進(jìn)行收貨地址的修改。當(dāng)然，為了保證及時發(fā)貨，避免出現(xiàn)需要重新進(jìn)行貨品的調(diào)撥等操作，還可以對庫存中心的庫存占用情況進(jìn)行修改，具體可以是釋放之前的倉庫中占用的庫存，并增加對新目標(biāo)倉庫的庫存占用。

s103：如果存在，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，以便按照修改后的信息向所述新收貨地址進(jìn)行發(fā)貨處理。

在確定出存在符合條件的目標(biāo)倉庫的情況下，還可以對關(guān)聯(lián)的一些訂單中的信息進(jìn)行修改，使得后續(xù)的發(fā)貨操作可以是依據(jù)修改后的新收貨地址進(jìn)行。具體實現(xiàn)時，考慮到具體的銷售場景通常包括分銷場景以及普通的非分銷場景，而在不同的場景下，具體的處理流程、產(chǎn)生的訂單數(shù)量、類型等有所不同，因此，在本申請實施例中，可以首先進(jìn)行交易訂單類型的判斷，也即，判斷所述 目標(biāo)交易訂單是否為分銷場景中生成的交易訂單，以便根據(jù)判斷結(jié)果確定所述對關(guān)聯(lián)的訂單中的信息的修改方式。其中，具體實現(xiàn)時，如果是分銷場景中生成的交易訂單，則可以在交易訂單中添加相應(yīng)的標(biāo)識等，因此，可以通過這種標(biāo)識，進(jìn)行交易訂單類型的判斷。

場景一

如果目標(biāo)交易訂單不是分銷場景中生成的交易訂單，也即，是普通銷售場景下產(chǎn)生的交易訂單，則第二用戶既是商品對象的銷售方，也是控貨方，在這種場景下，系統(tǒng)會針對生成的交易訂單生成物流訂單，在物流訂單中記錄具體的配送方信息等等，后續(xù)在執(zhí)行具體的發(fā)貨出庫等操作時，可以根據(jù)物流訂單執(zhí)行具體的發(fā)貨操作。

也就是說，在非分銷場景下，具體的訂單通常包括交易訂單以及物流訂單。在這種情況下，第一服務(wù)器在接收到針對目標(biāo)交易訂單的收貨地址修改請求時，可以首先判斷是否存在與該目標(biāo)交易訂單關(guān)聯(lián)的物流訂單，如果存在，則根據(jù)所述物流訂單的狀態(tài)，判斷是否可修改收貨地址，如果可修改，則可以觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟。也就是說，如果物流訂單已創(chuàng)建，則可以進(jìn)一步判斷當(dāng)前的發(fā)貨進(jìn)展，例如，判斷物流訂單是否處于已關(guān)閉(例如已申請退款等)，或者已創(chuàng)建倉儲作業(yè)訂單(例如倉庫已經(jīng)做好出庫準(zhǔn)備或者已出庫等)的狀態(tài)，如果是，則不允許修改收貨地址，否則，就處于可修改狀態(tài)。在根據(jù)新收貨地址確定出符合條件的目標(biāo)倉庫后，所謂的對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，就可以是對該物流訂單中的信息進(jìn)行修改，具體的，可以將所述物流訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫。

如果不存在與當(dāng)前的目標(biāo)交易訂單關(guān)聯(lián)的物流訂單，則由于具體的發(fā)貨操作需要基于物流訂單進(jìn)行，因此，可以證明該交易訂單一定尚未進(jìn)入發(fā)貨狀態(tài)，因此，可以直接判定該交易訂單處于可修改收貨地址的狀態(tài)。在根據(jù)新收貨地址確定出目標(biāo)倉庫后，所謂的對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，就可以對該目標(biāo)交易訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫，這樣，后續(xù)在創(chuàng)建物流訂單是，就可以直接根據(jù)修改后的目標(biāo)交易訂單中 的信息創(chuàng)建對應(yīng)的物流訂單，進(jìn)而，后續(xù)的發(fā)貨操作也都會基于物流訂單中的新收貨地址進(jìn)行。

場景二

所謂的分銷場景也即第二用戶作為分銷方用戶，本身并不控貨，貨品由第一用戶(也即供貨方用戶)統(tǒng)一提供并管理，第二用戶只是將第一用戶提供的后端商品對象發(fā)布為前端商品對象(也稱“前端寶貝”)，第三用戶從第二用戶的店鋪中購買具體的前端商品對象時，系統(tǒng)中可以產(chǎn)生對應(yīng)的交易訂單，并且，還可以生成用于建立第二用戶與第三用戶關(guān)系的第二物流訂單；同時，系統(tǒng)中往往還存在專用于處理供銷關(guān)系的供銷平臺服務(wù)器(本申請實施例中稱為第四服務(wù)器)，在生成交易訂單后，該第四服務(wù)器還可以在第二用戶的觸發(fā)操作下生成采購單，或者自動生成采購單(該采購單用于記錄第一用戶與第二用戶之間的關(guān)系)。另外，系統(tǒng)中還可以存在個性化方案處理平臺服務(wù)器(本申請實施例中可以稱為第二服務(wù)器)，該第二服務(wù)器可以根據(jù)采購單生成用于創(chuàng)建第一用戶、第二用戶以及第三用戶之間關(guān)系的第一物流訂單。后續(xù)的發(fā)貨操作會基于該第一物流訂單執(zhí)行，并將具體的發(fā)貨狀態(tài)更新到關(guān)聯(lián)的第二物流訂單中，使得前端的第三用戶可以通過查詢第二物流訂單的狀態(tài)，獲取到具體的物流狀態(tài)信息。

也就是說，在分銷場景下，通常存在以下訂單：交易訂單、采購單、第一物流訂單以及第二物流訂單，其中，各個訂單之間可以通過交易訂單編碼等信息關(guān)聯(lián)起來，并且，每個訂單中都可以記錄有收貨地址信息，因此，在修改地址的情況下，涉及到對各個訂單中相關(guān)的信息進(jìn)行一致性修改的問題，以避免系統(tǒng)出錯。

具體實現(xiàn)時，在本申請實施例中，在產(chǎn)生了采購單的情況下，可以將采購單標(biāo)識(例如，編號等)以及第一用戶標(biāo)識(例如，第一用戶id等)同步更新到交易訂單中，這樣，第一用戶可以通過交易訂單中的這些信息，確定出是否為分銷場景下的交易訂單，并且，還可以根據(jù)交易訂單中記錄的采購單標(biāo)識以及第一用戶標(biāo)識，判斷是否存在與所述目標(biāo)交易訂單關(guān)聯(lián)的第一物流訂單(具體實現(xiàn)時，可以向物流訂單中心服務(wù)器進(jìn)行查詢，或者也可以是其他實現(xiàn) 方式)，如果存在，則可以根據(jù)該第一物流訂單的狀態(tài)，判斷是否允許進(jìn)行收貨地址修改操作，如果可修改，則觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟。并且，在此情況下，在根據(jù)新收貨地址確定出目標(biāo)倉庫后，所謂的對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，具體可以是對第一物流訂單中的信息進(jìn)行修改，也即，將所述第一物流訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫，另外，還可以對所述目標(biāo)交易訂單關(guān)聯(lián)的第二物流訂單以及采購單中的信息修改為與所述第一物流訂單中修改后的信息一致。

具體實現(xiàn)時，如果系統(tǒng)中部署了多臺服務(wù)器，不同的服務(wù)器用于實現(xiàn)不同的功能，例如，可以存在專用于處理供銷關(guān)系的服務(wù)器，專用于處理個性化解決方案的服務(wù)器，等等。此時，為了進(jìn)行上述一致性操作，可以通過以下方式進(jìn)行：

通過調(diào)用第二服務(wù)器(例如，個性化解決方案中心服務(wù)器等)的信息修改接口，對所述第一物流訂單中的信息進(jìn)行修改，并由所述第二服務(wù)器發(fā)布關(guān)于所述第一物流訂單的第一信息修改消息，以便第三服務(wù)器(例如，物流訂單管理中心服務(wù)器)通過監(jiān)聽該第一信息修改消息，對關(guān)聯(lián)的第二物流訂單進(jìn)行信息修改，所述第三服務(wù)器在修改完成后發(fā)布關(guān)于所述第二物流訂單的第二信息修改消息，以便第四服務(wù)器(例如，供銷平臺服務(wù)器)通過監(jiān)聽該第二信息修改消息，對關(guān)聯(lián)的采購單進(jìn)行信息修改。

如果不存在與目標(biāo)交易訂單關(guān)聯(lián)的第一物流訂單，也即，第一物流訂單可能尚未創(chuàng)建，此時，可以判斷是否存在與該目標(biāo)交易訂單關(guān)聯(lián)的第二物流訂單，如果存在，則可以根據(jù)該第二物流訂單的狀態(tài)判斷是否允許進(jìn)行收貨地址修改操作，如果可修改，則觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟。此時，所謂的對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，具體可以是將所述第二物流訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫。當(dāng)然，由于第二物流訂單與采購單往往是在不同的系統(tǒng)中創(chuàng)建的，并且，相互之間并無依賴關(guān)系，因此，在存在第二物流訂單狀態(tài)下，雖然之前已經(jīng)判斷出不存在第一物流訂單，但是，還是可能已經(jīng)生成采購單的，因此，在這種情況下，還可以判斷是否存在關(guān)聯(lián)的采購單，如果存在，則將采購單中的信息修改為與所述第 二物流訂單中修改后的信息一致，以便根據(jù)所述采購單中修改后的信息生成第一物流訂單。也就是說，后續(xù)在創(chuàng)建第一物流訂單時，由于是根據(jù)采購單中的信息創(chuàng)建的，因此，在采購單中的信息已修改的情況下，后續(xù)創(chuàng)建的第一物流訂單中的信息自然會與第二物流訂單中的信息一致。當(dāng)然，如果不存在關(guān)聯(lián)的采購單，則證明采購單以及第一物流訂單均尚未創(chuàng)建，此時，在修改了第二物流訂單中信息的情況下，還可以對目標(biāo)交易訂單中的收貨地址信息進(jìn)行修改，這樣，由于采購單是基于目標(biāo)交易訂單中的信息創(chuàng)建的，而第一物流訂單又是基于采購單中的信息創(chuàng)建的，因此，后續(xù)在創(chuàng)建采購單以及第一物流訂單時，可以保證與修改后的第二物流訂單中的信息一致。

總之，通過本申請實施例，第三用戶在修改收貨地址時，不再是無條件地修改，而當(dāng)有地址修改請求時，系統(tǒng)首先判斷當(dāng)前是否存在符合條件的倉庫，也即，倉庫配送范圍覆蓋新收貨地址，并且倉庫庫存充足，如果有，則允許第三用戶修改。這樣，由于已經(jīng)提前進(jìn)行了覆蓋范圍、庫存等信息的判斷，因此，對于修改地址的訂單，第二用戶不再需要做補(bǔ)貨等操作才能發(fā)貨，而是直接選用系統(tǒng)選擇的倉庫來發(fā)貨即可。這樣，就可以有效地解決由于改地址帶來的發(fā)貨延遲等問題。

實施例二

該實施例二是與實施例一相對應(yīng)的，從第三用戶客戶端的角度進(jìn)行的介紹。參見圖2，該實施例二提供了一種地址修改信息處理方法，該方法可以包括以下步驟：

s201：第三用戶客戶端接收針對目標(biāo)交易訂單的收貨地址修改請求；

s202：將所述請求轉(zhuǎn)發(fā)給第一服務(wù)器，以便第一服務(wù)器確定新收貨地址，并根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，如果存在，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，并向所述客戶端返回所述目標(biāo)倉庫的標(biāo)識以及庫存信息；所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋新收貨地址且?guī)齑娉渥愕膫}庫；

s203：提供所述目標(biāo)倉庫的標(biāo)識以及庫存信息。

其中，具體實現(xiàn)時，第一服務(wù)器在確定出目標(biāo)倉庫之后，還可以根據(jù)新收貨地址以及所述目標(biāo)倉庫確定出配送時效信息(也即，預(yù)計的送達(dá)的時間信息)，并返回給第三用戶客戶端，因此，第三用戶客戶端還可以提供所述配送時效信息。這樣，使得第三用戶在修改收貨地址時，可以獲知修改后的發(fā)貨倉庫以及送達(dá)時間，進(jìn)行還可以據(jù)此確定該配送時效是否符合自己的心理預(yù)期，并確定是否要繼續(xù)進(jìn)行地址修改，等等。

由于該實施例二是與實施例一相對應(yīng)的，因此，相關(guān)的具體實現(xiàn)可以參見實施例一中的介紹，這里不再贅述。

為了更好的理解本申請實施例，下面通過非分銷場景以及分銷場景下的具體例子中的信息交互流程圖，進(jìn)行詳細(xì)介紹。

參見圖3，在非分銷場景下，涉及到的交互實體包括交易中心服務(wù)器(tc)、庫存中心服務(wù)器(ipm)、物流訂單中心服務(wù)器lc以及負(fù)責(zé)商品對象相關(guān)物流業(yè)務(wù)的核心系統(tǒng)服務(wù)器(delivery)，其中，delivery處在前臺交易系統(tǒng)tc和與后端物流系統(tǒng)lc之間。在本申請實施例中，在修改地址過程中的交互流程可以包括：

1：tc接收消費(fèi)者改地址的請求；

1.1：tc調(diào)用ipm的修改地址接口；

1.1.1：ipm收到請求后，從lc查詢物流訂單的狀態(tài)；

1.1.2：ipm根據(jù)物流訂單的狀態(tài)判斷是否允許修改地址；

1.1.3：如果允許修改，則首先可以利用三級地址id，向delivery進(jìn)行倉庫路由；

1.1.4：路由出新倉庫后，占用新倉庫存；

1.1.5：根據(jù)四級地址，修改物流訂單中的收貨地址和倉庫編碼；

1.1.6：釋放老庫存；

1.2：ipm通知tc倉庫編碼已修改；

1.3：如果沒有物流訂單，則可以直接修改交易訂單上的收貨地址，否則，可以不修改交易訂單中的收貨地址。

參見圖4，在分銷場景下，除了圖3中各實體，還涉及到供銷平臺服務(wù)器(gx)、用于提供個性化物流解決方案的服務(wù)器(vsp)，在該分銷場景下，修改地址過程中的信息交互方式可以包括：

1：tc接收消費(fèi)者付定金的請求時；

2：gx監(jiān)聽付定金款消息；

2.1：生成采購單；

2.2：給交易訂單添加供貨商userid以及采購單標(biāo)識；

3：tc接收消費(fèi)者修改地址的請求；

3.1：rc調(diào)用ipm的改地址接口；

3.1.1：ipm判斷是否為分銷訂單；

3.1.2：如果是，解析出供貨商userid以及采購單標(biāo)識；

3.1.3：ipm向lc查詢是否存在b2b物流訂單；

3.1.4：如果沒有查詢到b2b物流訂單，則向lc查詢是否存在b2c物流訂單；

3.1.5：利用三級地址id，向delivery進(jìn)行倉庫路由；

3.1.6：路由出新倉庫后，占用新倉庫存；

3.1.7：根據(jù)四級地址，修改查詢到的物流訂單(b2b或b2c)中的收貨地址和倉庫編碼；

3.1.8：釋放老庫存；

3.2：tc在接收到修改完成的消息后，可以修改交易訂單上的倉庫編碼；

3.3：如果沒有查詢到物流訂單，則可以修改交易訂單上的收貨地址，否則，可以不必修改交易訂單上的收貨地址；

4：如果存在b2b物流訂單，則vsp從lc監(jiān)聽b2b物流訂單的修改消息；

5：根據(jù)監(jiān)聽到的b2b物流訂單的修改消息，修改對應(yīng)的b2c物流訂單的收貨地址；

6：gx監(jiān)聽b2c物流訂單的地址修改消息；

7：根據(jù)監(jiān)聽到的b2c物流訂單的修改消息，修改對應(yīng)的采購單的收貨地址。

與實施例一提供的地址修改信息處理方法相對應(yīng)，本申請實施例還提供了一種地址修改信息處理裝置，該裝置應(yīng)用于第一服務(wù)器，參見圖5，該裝置具體可以包括：

請求接收單元501，用于接收到針對目標(biāo)交易訂單執(zhí)行修改收貨地址的請求時，確定新收貨地址；

目標(biāo)倉庫確定單元502，用于根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋所述新收貨地址且?guī)齑娉渥愕膫}庫；

訂單信息修改單元503，用于如果存在所述目標(biāo)倉庫，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，以便按照修改后的信息向所述新收貨地址進(jìn)行發(fā)貨處理。

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

訂單類型判斷單元，用于判斷所述目標(biāo)交易訂單是否為分銷場景中生成的交易訂單，以便根據(jù)判斷結(jié)果確定所述對關(guān)聯(lián)的訂單中的信息的修改方式。

其中，如果所述目標(biāo)交易訂單不是分銷場景中生成的交易訂單，則所述裝置還包括：

第一判斷單元，用于判斷是否存在與所述目標(biāo)交易訂單關(guān)聯(lián)的物流訂單；

第二判斷單元，用于如果存在所述物流訂單，則根據(jù)所述物流訂單的狀態(tài)，判斷是否可修改收貨地址，如果可修改，則觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟。

所述訂單信息修改單元具體用于：

將所述物流訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫。

另外，所述裝置還包括：

觸發(fā)單元，用于如果不存在所述物流訂單，則判定為可修改收貨地址，并觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟；

所述訂單信息修改單元具體用于：

將所述目標(biāo)交易訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫，以便根據(jù)修改后的目標(biāo)交易訂單中的信息創(chuàng)建對應(yīng)的物流訂單。

如果所述目標(biāo)交易訂單是分銷場景中生成的交易訂單，則所述裝置還可以包括：

第三判斷單元，用于判斷是否存在與所述目標(biāo)交易訂單關(guān)聯(lián)的第一物流訂單，所述第一物流訂單為用于記錄第一用戶、第二用戶以及第三用戶之間關(guān)系的物流訂單，所述第一用戶為供貨方用戶，所述第二用戶為分銷方用戶；

第四判斷單元，用于如果存在所述第一物流訂單，則根據(jù)所述第一物流訂單的狀態(tài)，判斷是否可修改收貨地址，如果可修改，則觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟。

其中，如果存在所述第一物流訂單，則所述訂單信息修改單元包括：

第一修改子單元，用于將所述第一物流訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫；

第二修改子單元，用于對所述目標(biāo)交易訂單關(guān)聯(lián)的第二物流訂單以及采購單中的信息修改為與所述第一物流訂單中修改后的信息一致；其中，所述第二物流訂單為用于記錄第二用戶與第三用戶之間關(guān)系的物流訂單，所述第三用戶為消費(fèi)方用戶。

具體實現(xiàn)時，所述訂單信息修改單元具體可以用于：

通過調(diào)用第二服務(wù)器的信息修改接口，對所述第一物流訂單中的信息進(jìn)行修改，并由所述第二服務(wù)器發(fā)布關(guān)于所述第一物流訂單的第一信息修改消息，以便第三服務(wù)器通過監(jiān)聽該第一信息修改消息，對關(guān)聯(lián)的第二物流訂單進(jìn)行信息修改，所述第三服務(wù)器在修改完成后發(fā)布關(guān)于所述第二物流訂單的第二信息修改消息，以便第四服務(wù)器通過監(jiān)聽該第二信息修改消息，對關(guān)聯(lián)的采購單進(jìn)行信息修改。

其中，如果不存在所述第一物流訂單，則所述裝置還包括：

第五判斷單元，用于判斷是否存在關(guān)聯(lián)的第二物流訂單，所述第二物流訂單為用于記錄第二用戶與第三用戶之間關(guān)系的物流訂單，所述第三用戶為消費(fèi)方用戶；

第六判斷單元，用于如果存在所述第二物流訂單，則根據(jù)所述第二物流訂單的狀態(tài)，判斷是否可修改收貨地址，如果可修改，則觸發(fā)所述確定修改后的新收貨地址及后續(xù)步驟。

如果存在所述第二物流訂單，則所述訂單信息修改單元具體用于：

將所述第二物流訂單中的收貨地址修改為所述新收貨地址，發(fā)貨倉庫修改為所述目標(biāo)倉庫；

所述裝置還包括：

一致性修改單元，用于判斷是否存在關(guān)聯(lián)的采購單，如果存在，則將采購單中的信息修改為與所述第二物流訂單中修改后的信息一致，以便根據(jù)所述采購單中修改后的信息生成第一物流訂單。

具體實現(xiàn)時，所述一致性修改單元還可以用于：

如果不存在關(guān)聯(lián)的采購單，則將所述目標(biāo)交易訂單中的信息修改為與所述第二物流訂單中修改后的信息一致，以便根據(jù)所述目標(biāo)交易訂單修改后的信息生成采購單以及第一物流訂單。

另外，所述裝置還可以包括：

庫存占用信息修改單元，用于修改對應(yīng)倉庫中的庫存占用信息。

與實施例一提供的地址修改信息處理方法相對應(yīng)，本申請實施例還提供了一種地址修改信息處理裝置，該裝置應(yīng)用于第三用戶客戶端，參見圖6，該裝置具體可以包括：

請求接收單元601，用于接收針對目標(biāo)交易訂單的收貨地址修改請求；

請求轉(zhuǎn)發(fā)單元602，用于將所述請求轉(zhuǎn)發(fā)給第一服務(wù)器，以便第一服務(wù)器確定新收貨地址，并根據(jù)所述目標(biāo)交易訂單關(guān)聯(lián)的商品對象的倉庫列表及各個倉庫的配送覆蓋范圍信息，判斷是否存在符合預(yù)置條件的目標(biāo)倉庫，如果存在，則對關(guān)聯(lián)的訂單中的信息進(jìn)行修改，并向所述客戶端返回所述目標(biāo)倉庫的標(biāo)識以及庫存信息；所述符合預(yù)置條件的目標(biāo)倉庫為：配送覆蓋范圍可涵蓋新收貨地址且?guī)齑娉渥愕膫}庫；

信息提供單元603，用于提供所述目標(biāo)倉庫的標(biāo)識以及庫存信息。

其中，所述第一服務(wù)器返回的信息還包括根據(jù)所述新收貨地址以及所述目標(biāo)倉庫確定出的配送時效信息，所述裝置還包括：

時效信息提供單元，用于提供所述配送時效信息。

通過本申請實施例，第三用戶在修改收貨地址時，不再是無條件地修改，而當(dāng)有地址修改請求時，系統(tǒng)首先判斷當(dāng)前是否存在符合條件的倉庫，也即，倉庫配送范圍覆蓋新收貨地址，并且倉庫庫存充足，如果有，則允許第三用戶修改。這樣，由于已經(jīng)提前進(jìn)行了覆蓋范圍、庫存等信息的判斷，因此，對于修改地址的訂單，第二用戶不再需要做補(bǔ)貨等操作才能發(fā)貨，而是直接選用系統(tǒng)選擇的倉庫來發(fā)貨即可。這樣，就可以有效地解決由于改地址帶來的發(fā)貨延遲等問題。

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

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

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