一種訂單拆分方法和裝置的制造方法
【技術領域】
[0001]本發(fā)明涉及計算機技術領域,特別地涉及一種訂單拆分方法和裝置。
【背景技術】
[0002]隨著電子商務的發(fā)展不斷的復雜和擴大,訂單拆分成為大型電子商務公司訂單生產過程中不可缺少的一個環(huán)節(jié),對于開放式B2C電子商務來說用戶下了不同商家的訂單是需要拆分來開的,對于自營式B2C電子商務來說更是如此。
[0003]比如,用戶下了一個混合訂單,訂單中有書,有手機,有衣服等不同品類(圖書、3C、百貨)的商品,而事實上這些商品根據庫房劃分的不同會存放在不同地理位置和區(qū)域中,比如書,可能會是在圖書倉庫,手機在3C倉庫,衣服又在百貨倉庫,而這些倉庫在實際情況中不一定是在同一個區(qū)域,那么這樣就需要系統在訂單到達庫房進行生產之前按照庫房分布不同進行拆分,以便保證來自不同庫房商品的訂單能夠正確流轉到下游的對應的庫房或者第三方商家中進行生產打包和配送。
[0004]上面說的其實只是用戶下單后需要根據訂單中商品的商家不同庫房分布不同進行訂單拆分的情況,就是按照商家維度、庫房的維度進行訂單拆分,就是說商家標識、庫房號是訂單進行拆分的不同維度,而在實際的訂單生產流程中會有很多的自身條件需要對訂單進行拆分,比如機構號,商品是否是現貨等物理條件進行限制,而系統就是通過這些條件將訂單拆分開來。
[0005]對于訂單拆分,現有的技術方案通常采用基于固定拆分維度技術方案進行拆分:
[0006]通過相關業(yè)務要求去構建一個拆分模型,這個模型中包含了基本拆分固有維度,這個拆分固有維度是指本身對于拆分而言是有實際意義,比如商品的庫房號,商品的庫存狀態(tài)這都是有意義的;通過對訂單中的每個商品進行遍歷,進行填充該拆分模型所包含的拆分維度,這樣每個商品都有了自己的拆分模型的實例,最后系統進行模型實例的比對,如果模型實例相同則是一單,反之會有多單。其工作流程如圖1所示:
[0007]訂單原始信息模塊:主要進行訂單拆分之前的數據整理,這里系統會從用戶下的原始訂單中得到一些訂單數據詳情,比如商品及數量,使用的優(yōu)惠以及金額等等,這些數據中會包含拆分所關注的一些直接維度,比如庫房號,商家編號等信息,為訂單拆分做準備;
[0008]商品的拆分模型構造模塊:主要是進行構建每個商品的拆分模型實例,根據相關人員定義好的拆分模型和系統得到的每個商品的信息進行填充拆分模型,為下一步準備;
[0009]商品的模型對比模塊:主要是對上一步形成的一個每個商品的拆分模型實例進行比較,如果一樣的話就是一堆,否則會有很多堆;
[0010]拆分結果的確定模塊:根據上一步的分堆的結果,進行拆分結果的構造和確定。
[0011]隨著訂單業(yè)務的不斷發(fā)展,系統除了需要按照商品本身具備的屬性進行拆分后,同時也需要按照很多業(yè)務上的規(guī)則對訂單進行拆分,比如要求某種商品只能是一個商品是一單的,還有同一個訂單不同商品的配送方式不一樣,甚至是商家特殊的促銷也是需要進行拆分的等等情況。
[0012]如按照現有技術方案對訂單進行拆分會存在這樣的問題,就是固有的拆分維度無法適應滿足新的業(yè)務擴展:因為固有的拆分模型不會考慮到新的業(yè)務將會帶來的拆分維度,而且每個業(yè)務所定義的維度也不可能是相同意義的。而隨著業(yè)務不斷增加和擴展,對于拆分的邏輯也在趨于復雜和拆分粒度會更大,就是可能會存在這樣的問題:對于原來拆分完的一個訂單,新的業(yè)務會導致該訂單的進一步拆分,比如一個訂單有兩本書,一個手機這三個商品,按照現有的方式進行拆分的話,根據庫房不同會拆分成兩單,兩本書在同一個庫房是一單,手機是一單,但可能存在一個業(yè)務或者特殊要求其中的一本圖書必須是一單一貨,也就是說系統還需要將這兩本書拆分開,最后是三單。那么對于上面這種情況按照已有維度是無法拆分處理的,不能拆分到底的,顯然已有的拆分方案無法很好的解決這樣的問題,這樣就需要系統在拆分結果的基礎上對訂單再次進行特殊的處理,比如上面的情況如果發(fā)現訂單中有特殊的商品需要單拆分出來,進行特殊的邏輯處理,需要在已有的業(yè)務邏輯上增加新拆分要求,就會存在不斷修改已有業(yè)務邏輯的缺點,會增加已有業(yè)務邏輯出現崩潰的風險,會降低系統的穩(wěn)定性,不利于系統和業(yè)務的擴展。
【發(fā)明內容】
[0013]有鑒于此,本發(fā)明提供一種訂單拆分方法和裝置,能夠在有特殊的商品需要單拆分出來的時候,無需進行特殊的邏輯處理,只要在已有的業(yè)務邏輯上增加新拆分要求即可,克服了需要不斷修改已有業(yè)務邏輯的缺點,減少了已有業(yè)務邏輯出現崩潰的風險,提高了系統的穩(wěn)定性,有利于系統和業(yè)務的擴展。
[0014]為實現上述目的,根據本發(fā)明的一個方面,提供了一種訂單拆分方法。
[0015]本發(fā)明的訂單拆分方法包括:在已有的拆分維度節(jié)點中,保存根據業(yè)務需求增加的拆分維度節(jié)點;在已有的拆分模型基礎上,加入包括所述增加的拆分維度節(jié)點的拆分模型,以構造得到動態(tài)業(yè)務拆分模型;根據訂單中的商品信息以及所述動態(tài)業(yè)務拆分模型,對訂單進行拆分。
[0016]可選地,所述拆分維度節(jié)點包括如下一種或多種:庫房號、商家標識、機構號、商品類型、以及庫存狀態(tài)。
[0017]可選地,所述根據業(yè)務需求增加的拆分維度節(jié)點包括商品通用維度標識。
[0018]可選地,所述商品通用維度標識為多位的字符串,每一位用于標識不同的業(yè)務需求。
[0019]可選地,所述增加的拆分維度節(jié)點的拆分模型為:一個單獨包括已增加拆分維度節(jié)點的拆分模型;
[0020]或者,所述增加的拆分維度節(jié)點的拆分模型為:既包括已增加的拆分維度節(jié)點,又包括訂單中的商品信息所含有的維度節(jié)點的拆分模型。
[0021]根據本發(fā)明的另一方面,提供了一種訂單拆分裝置。
[0022]本發(fā)明的訂單拆分裝置包括:保存模塊,用于在已有的拆分維度節(jié)點中,保存根據業(yè)務需求增加的拆分維度節(jié)點;構造模塊,用于在已有的拆分模型基礎上,加入包括所述增加的拆分維度節(jié)點的拆分模型,以構造得到動態(tài)業(yè)務拆分模型;拆分模塊,用于根據訂單中的商品信息以及所述動態(tài)業(yè)務拆分模型,對訂單進行拆分。
[0023]可選地,所述拆分維度節(jié)點包括如下一種或多種:庫房號、商家標識、機構號、商品類型、以及庫存狀態(tài)。
[0024]可選地,所述根據業(yè)務需求增加的拆分維度節(jié)點包括商品通用維度標識。
[0025]可選地,所述商品通用維度標識為多位的字符串,每一位用于標識不同的業(yè)務需求。
[0026]可選地,所述增加的拆分維度節(jié)點的拆分模型為:一個單獨包括已增加拆分維度節(jié)點的拆分模型;
[0027]或者,所述增加的拆分維度節(jié)點的拆分模型為:既包括已增加的拆分維度節(jié)點,又包括訂單中的商品信息所含有的維度節(jié)點的拆分模型。
[0028]根據本發(fā)明的技術方案,能夠在有特殊的商品需要單拆分出來的時候,無需進行特殊的邏輯處理,只要在已有的業(yè)務邏輯上增加新拆分要求即可,克服了需要不斷修改已有業(yè)務邏輯的缺點,減少了已有業(yè)務邏輯出現崩潰的風險,提高了系統的穩(wěn)定性,有利于系統和業(yè)務的擴展。
【附圖說明】
[0029]附圖用于更好地理解本發(fā)明,不構成對本發(fā)明的不當限定。其中:
[0030]圖1是根據現有技術的拆分模型流程圖;
[0031]圖2是根據本發(fā)明實施例的訂單拆分方法示意圖;
[0032]圖3是根據本發(fā)明實施例的訂單拆分裝置示意圖。
【具體實施方式】
[0033]以下結合附圖對本發(fā)明的示范性實施例做出說明,其中包括本發(fā)明實施例的各種細節(jié)以助于理解,應當將它們認為僅僅是示范性的。因此,本領域普通技術人員應當認識到,可以對這里描述的實施例做出各種改變和修改,而不會背離本發(fā)明的范圍和精神。同樣,為了清楚和簡明,以下的描述中省略了對公知功能和結構的描述。
[0034]圖2是根據本發(fā)明實施例的訂單拆分方法示意圖。如圖2所示,該方法主要包括如下的步驟S20至S22。
[0035]步驟S20