久久精品国产69国产精品亚洲_日韩欧美亚洲一区_免费观看污网站_欧美在线一

隨著“互聯(lián)網(wǎng)+”時(shí)代的電子商務(wù)發(fā)展, 促使著現(xiàn)代倉儲、物流不斷的變革和創(chuàng)新, 倉儲配送的格局正在發(fā)生著巨大變化.倉儲行業(yè)正集中精力創(chuàng)新傳統(tǒng)倉庫, 發(fā)展電商倉;信息處理方面, 大數(shù)據(jù)和智能化驅(qū)動(dòng)著整體行業(yè)的發(fā)展[1].線上線下 (Online To Offline, o2o) 的發(fā)展是商業(yè)變化的大勢所趨, 云倉儲模式逐漸成為未來的剛性需求.

傳統(tǒng)倉儲各倉庫庫存、訂單、物流信息不能實(shí)時(shí)傳遞, 形成信息孤島, 需要用云計(jì)算技術(shù)解決信息不能共享的問題;在傳統(tǒng)倉庫中一般是沒有訂單管理系統(tǒng)的, 在電子商務(wù), 質(zhì)押貸款等新型模式發(fā)展下, 需要訂單管理系統(tǒng)作為客戶與倉庫交流的信息載體, 同時(shí)作為倉庫信息入口.設(shè)計(jì)了云倉儲系統(tǒng)總體架構(gòu), 以訂單管理系統(tǒng)為重點(diǎn), 描述了訂單管理系統(tǒng)與其他模塊之間協(xié)作關(guān)系、結(jié)構(gòu)設(shè)計(jì)及統(tǒng)一的第三方數(shù)據(jù)接口平臺.

云倉儲需要在重要區(qū)域中心建立分倉, 再由公司總部建立基于云計(jì)算的一體化倉儲信息系統(tǒng), 用倉儲信息系統(tǒng)將各分倉聯(lián)網(wǎng), 進(jìn)而實(shí)現(xiàn)商品、倉庫、庫位的合理調(diào)度, 配送網(wǎng)絡(luò)的快速響應(yīng).在這種模式下, 商品可直接從分倉的分揀中心實(shí)現(xiàn)就近配送, 大大地縮短配送時(shí)間, 有效地提升客戶體驗(yàn)[2].

云倉儲系統(tǒng)設(shè)計(jì)思想可概括為:通過云計(jì)算、大數(shù)據(jù)、物聯(lián)網(wǎng)等技術(shù)的緊密結(jié)合, 由系統(tǒng)對數(shù)據(jù)進(jìn)行儲存、分析、計(jì)算, 并對服務(wù)進(jìn)行模塊化、封裝式的處理, 管理人員被賦予不同的權(quán)限, 在任意終端通過門戶網(wǎng)站接入中心服務(wù)器, 獲取權(quán)限范圍內(nèi)的、所需求的服務(wù)[3].

產(chǎn)業(yè)鏈扁平化是未來發(fā)展的趨勢.云倉儲管理系統(tǒng)在電子商務(wù)產(chǎn)業(yè)鏈中提供基礎(chǔ)性服務(wù), 將物流、商流、信息流、資金流“四流”有機(jī)結(jié)合, 利用云計(jì)算共享分倉資源, 完善電商倉儲物流生態(tài)圈, 通過整合信息網(wǎng)、倉儲網(wǎng)、干線網(wǎng), 用大數(shù)據(jù)提升效率.消費(fèi)者和工廠設(shè)計(jì)方、品牌商、農(nóng)業(yè)產(chǎn)區(qū)將實(shí)現(xiàn)可視化的供需鏈接, 不論是電商平臺還是傳統(tǒng)零售, 渠道商如果還是靠買賣賺取差價(jià)獲利, 這樣的生存空間必定是越來越小.真正能夠帶來一體化的供應(yīng)鏈增值服務(wù)的, 才是未來商業(yè)的核心.

圖1 云倉儲系統(tǒng)總體框架圖Fig.1 Architecture diagram of cloud storge system   

云倉儲管理系統(tǒng)利用“云”的概念將分散于不同區(qū)域的、與實(shí)體倉庫相關(guān)的資源整合起來, 交由企業(yè)中心建立的倉儲信息管理系統(tǒng)統(tǒng)一調(diào)度管理, 形成一個(gè)以分布式倉儲為云, 核心信息管理系統(tǒng)為服務(wù)器的企業(yè)內(nèi)部倉儲管理平臺[4].云倉儲管理系統(tǒng)由訂單管理系統(tǒng)、倉庫管理子系統(tǒng)、綜合管理子系統(tǒng)、物流管理子系統(tǒng)、大數(shù)據(jù)驅(qū)動(dòng)子系統(tǒng)構(gòu)成, 并在移動(dòng)客戶端上建立必要的應(yīng)用支持.從接訂單、倉庫內(nèi)部管理、采購、以及組織發(fā)貨, 到進(jìn)行數(shù)據(jù)綜合分析以及業(yè)務(wù)綜合管理, 提供一個(gè)有效的信息化管理平臺, 為網(wǎng)絡(luò)倉庫的各個(gè)部門的業(yè)務(wù)開展與協(xié)同高效工作提供支持[5].

傳統(tǒng)的倉儲管理系統(tǒng)中是沒有訂單管理模塊的, 在云倉儲管理系統(tǒng)中需要處理普通消費(fèi)者、商超、電商平臺等訂單數(shù)據(jù).訂單管理系統(tǒng)是倉儲配送的初始環(huán)節(jié), 客戶需求及內(nèi)部物流、資源狀況、庫存、數(shù)據(jù)分析、任務(wù)完成情況等都是通過訂單來描述的, 云倉儲系統(tǒng)的配送行為表現(xiàn)為圍繞訂單而進(jìn)行的一個(gè)協(xié)調(diào)配置過程[6].

在訂單管理系統(tǒng)中, 訂單是管理的對象.云倉儲管理系統(tǒng)中的協(xié)同訂單處理從地域上橫跨整個(gè)企業(yè)和供應(yīng)鏈, 從時(shí)間上覆蓋訂單的產(chǎn)生一直到貨物交付給用戶的全部生命周期, 主要包括生成訂單、訂單協(xié)同處理、倉庫調(diào)配備貨、制單發(fā)貨、物流跟蹤這五個(gè)階段[6].在生成訂單階段, 訂單管理系統(tǒng)應(yīng)該按照提供的統(tǒng)一接口接收訂單信息, 然后進(jìn)行錄入和保存處理, 生成配貨單, 同時(shí)生成物流服務(wù)需求訂單, 并按照資源優(yōu)化配置策略進(jìn)行訂單在物流企業(yè)的分配.配貨單形成后, 協(xié)同倉庫管理子系統(tǒng)中開始按照最優(yōu)路徑策略打包貨物, 形成發(fā)貨單, 在供應(yīng)鏈子系統(tǒng)中對訂單進(jìn)行確認(rèn), 若分配的物流企業(yè)接受發(fā)貨單, 則執(zhí)行訂單;若物流企業(yè)拒絕訂單, 則供應(yīng)鏈子系統(tǒng)根據(jù)資源最優(yōu)調(diào)度策略對訂單進(jìn)行智能處理.物流發(fā)送貨物后, 由物流平臺提供的物流信息反饋到訂單系統(tǒng)中, 再反饋到客戶.云倉儲系統(tǒng)各個(gè)環(huán)節(jié)進(jìn)行協(xié)同運(yùn)作, 并同客戶、訂單平臺、物流企業(yè)進(jìn)行雙向信息交互, 提高倉儲環(huán)節(jié)的柔性和反應(yīng)能力.

訂單處理狀態(tài)遷移如圖1所示.

在訂單協(xié)同處理階段, 主要包括以下四個(gè)基本環(huán)節(jié):訂單錄入、訂單審批、訂單跟蹤、結(jié)單管理, 還包含兩個(gè)異常訂單處理環(huán)節(jié):撤單管理和急單管理以及一個(gè)歷史訂單綜合查詢環(huán)節(jié)[7].在訂單協(xié)同管理四個(gè)基本環(huán)節(jié)中, 對錄入的合格訂單進(jìn)行訂單分批, 資源分配及制單執(zhí)行計(jì)劃, 對不合格的訂單進(jìn)行調(diào)整, 給與客戶反饋.用戶、企業(yè)、創(chuàng)客可以對處于未審核狀態(tài)下的訂單做撤單處理, 在撤銷訂單后, 完成退款、取消配貨單、物流服務(wù)單等操作.在急單管理中, 首先獲取訂單并進(jìn)行優(yōu)先審核, 如果審核通過, 訂單被直接提交給倉庫管理子系統(tǒng), 如果審核未通過, 向用戶提供急單作廢通知, 急單的整個(gè)業(yè)務(wù)處理過程都是通過開辟專用通道 (即提高訂單響應(yīng)級別) 來實(shí)現(xiàn), 同時(shí)也要求倉庫管理子系統(tǒng)對急單開辟專用通道并進(jìn)行緊急處理[7?8].用戶、倉庫操作員可以根據(jù)業(yè)務(wù)需求利用各種查詢條件對作廢訂單和成功訂單進(jìn)行實(shí)時(shí)查詢, 查看訂單目前的狀態(tài), 進(jìn)行跟蹤[8].系統(tǒng)對各種性質(zhì)的訂單進(jìn)行相應(yīng)的統(tǒng)計(jì), 交給大數(shù)據(jù)驅(qū)動(dòng)子系統(tǒng), 并依據(jù)成功、撤銷、加急訂單詳細(xì)信息做出業(yè)務(wù)分析和預(yù)測.

云倉儲管理系統(tǒng)中的訂單管理模塊涉及到一整套的訂單處理過程, 從提出需求到接受訂單, 訂單審核, 訂單狀況跟蹤、運(yùn)輸?shù)?span style="font-size:12px;line-height:0;vertical-align:baseline;">[9].具體管理內(nèi)容包括:訂單的定制及傳送;訂單的確認(rèn)接收;訂單合同管理;訂單計(jì)劃定制;訂單相關(guān)資源管理;訂單相關(guān)關(guān)系管理;訂單執(zhí)行情況的跟蹤監(jiān)控;訂單出錯(cuò)及變動(dòng)處理;訂單狀態(tài)查詢;訂單后勤管理;訂單財(cái)務(wù)管理;訂單協(xié)調(diào)管理[9,10].

由于訂單狀態(tài)是最直接的信號, 因此不合理的訂單管理所導(dǎo)致的信息波動(dòng)、延遲甚至錯(cuò)誤, 會(huì)導(dǎo)致訂單處理的運(yùn)作效率低下, 嚴(yán)重時(shí)甚至使其陷于癱瘓.為了減小訂單信息波動(dòng)性, 提高運(yùn)作效率, 各子系統(tǒng)必須達(dá)到高度信息共享.為了保證訂單一致性, 云倉儲管理系統(tǒng)中的各個(gè)組成模塊間必須協(xié)調(diào)良好, 保證各方合作的順利進(jìn)行.訂單管理系統(tǒng)結(jié)構(gòu)圖如圖2所示.

圖2 訂單管理系統(tǒng)體系結(jié)構(gòu)Fig.2 Architecture diagram of the order management system   

訂單管理系統(tǒng)會(huì)接受多種平臺的訂單, 需要統(tǒng)一的訂單接口, 規(guī)范訂單數(shù)據(jù), 對不同來源的訂單進(jìn)行數(shù)據(jù)管理.如淘寶、京東、當(dāng)當(dāng)?shù)壬虅?wù)平臺, 通過與電商數(shù)據(jù)交換服務(wù)程序, 獲得指定電商訂單數(shù)據(jù), 為其準(zhǔn)備相應(yīng)的貼牌、配送服務(wù);同時(shí)對庫存、物流等信息, 提供給電商平臺及創(chuàng)客, 以使其獲知商品存量;對于自有商城或者APP的商戶, 按照指定接口與訂單管理系統(tǒng)進(jìn)行數(shù)據(jù)交互, 提供給訂單系統(tǒng)請求數(shù)據(jù), 以便倉儲系統(tǒng)根據(jù)這些數(shù)據(jù)進(jìn)一步處理[11].

以安卓平臺為例, 用java代碼實(shí)現(xiàn), 圖3為第三方平臺與訂單管理系統(tǒng)的交互流程.實(shí)線表示消費(fèi)者或電商平臺對訂單管理系統(tǒng)的請求, 虛線表示訂單系統(tǒng)與商戶系統(tǒng)之間的信息反饋.

第4步:調(diào)用訂單接口:這一步就是將商戶簽名后的訂單信息傳遞給接口中的OrderTask對象, 調(diào)用order方法, 此方法后續(xù)會(huì)喚起訂單檢查、庫存檢查操作, 訂單信息格式具體見表2訂單參數(shù)說明.

第5步:提交訂單請求:saveOrder對象將會(huì)按照商戶客戶端提供的請求參數(shù)發(fā)送提交訂單、保存訂單的請求, 喚起訂單分批、商品裝配等后續(xù)工作.

第8步:接口返回支付結(jié)果:商戶客戶端在第4步中調(diào)用的訂單接口, 會(huì)返回最終的訂單保存結(jié)果 (即同步數(shù)據(jù)庫完畢的通知) .

第12步:異步發(fā)送保存訂單信息通知:云倉儲管理系統(tǒng)會(huì)發(fā)送異步通知消息給商戶服務(wù)器端.因?yàn)槭钱惒桨l(fā)送, 第12步可能在7~11步之前完成, 但是一定是在第6步訂單保存成功后發(fā)起.

訂單管理系統(tǒng)中提供order接口方法供外部調(diào)用, 此接口接收兩個(gè)參數(shù)String類型的orderInfo, 表示商戶的訂單信息, key=“value”格式, 以&連接;另一個(gè)參數(shù)是Boolean類型參數(shù)isShowLoading, 表示商戶提交訂單后, 是否喚起一個(gè)loading.order方法可以觸發(fā)訂單管理系統(tǒng)里的其他流程, 如庫存檢測、貨物調(diào)撥等.重要實(shí)體類及關(guān)鍵代碼示例見表1.

一個(gè)完整的安卓平臺調(diào)用過程與代碼是 (1) 將安卓應(yīng)用的Activity實(shí)例傳遞給OrderTask構(gòu)造方法, 實(shí)例化OrderTask對象:OrderTask orderTask=new OrderTask (Activity) ; (2) 將訂單數(shù)據(jù)封裝到OrderInfo實(shí)體內(nèi):OrderInfo orderInfo=orderTask.order (String, Boolean) ; (3) 檢查訂單數(shù)據(jù)規(guī)范:orderInfo.check () ; (4) 訂單管理系統(tǒng)保存訂單:orderTask.save (OrderInfo) .Order接口接收的String訂單信息格式見表2.

圖3 第三方平臺與訂單管理系統(tǒng)交互流程Fig.3 Interaction between the third party platform and the order management system  

表1 訂單相關(guān)實(shí)體類Tab.1 Class associated with orders     

表2 訂單參數(shù)說明Tab.2 Specification of order parameters     

為簡化訂單接收以后在倉庫中的流轉(zhuǎn)過程, 需要對訂單做分批處理, 在系統(tǒng)中引入基于知識庫的訂單分批策略, 這種策略是去檢索歷史訂單明細(xì)數(shù)據(jù), 按照式 (1) 的約定, 依據(jù)案例推理 (Case-Based Reasoning, CBR) [12]引擎產(chǎn)生最優(yōu)分批策略.訂單在系統(tǒng)中的分批, 流轉(zhuǎn)的方案, 是依據(jù)歷史訂單知識庫決策的.基于知識庫的案例分批策略分為兩部分, 一部分是被處理過的訂單收集模塊, 另一部分是訂單分組生成模塊.第一部分由云計(jì)算子系統(tǒng)提供存儲、更新、檢索的功能, 第二部分集成到訂單管理系統(tǒng)中, 如圖4所示展示了此策略的循環(huán)圖.

CBR是以過去解決的類似問題的案例來尋求解決當(dāng)前新問題的推論方法.CBR引擎是把每一次做出決策的一批訂單作為一個(gè)案例, 也就是所謂的“case”, 典型的CBR引擎運(yùn)行過程分為四步, 依次為檢索、修正、重用、保留.具體是從訂單收集模塊檢索相似的訂單, 進(jìn)一步修正, 以滿足當(dāng)前訂單分批的需求, 訂單分批問題與檢索數(shù)據(jù)相似性滿足以下公式:

式中的sim (f) 是本次案例與歷史案例的相似函數(shù), wi是本次案例與歷史每次相似屬性的權(quán)重.在訂單分批過程中, 把相似值S最高的歷史訂單分批方案作為本次的分批方案, 選中的解決方案還需要修正、核對以適應(yīng)當(dāng)前的需求, 最終把最新的分批方案再作為歷史方案存儲到收集模塊.

圖4 基于知識庫的訂單分批策略循環(huán)圖Fig.4 Knowledge-based order batching decision cycle  

假設(shè)揀貨員都是60名, 訂單量依次增加的情況下.在前人實(shí)驗(yàn)基礎(chǔ)上[13], 對比先到先服務(wù)、節(jié)約算法、粒子群算法, 結(jié)果如圖5所示.可以看到基于知識庫的訂單分批策略只是在訂單量較少時(shí)處理時(shí)間大于粒子群算法, 當(dāng)訂單量繼續(xù)增加, 則優(yōu)于其他三種訂單分批算法.

圖5 訂單分批算法對比圖Fig.5 Comparison between order batching algorithms

1) 通過分析云倉儲管理系統(tǒng)的特點(diǎn), 設(shè)計(jì)了云倉儲管理系統(tǒng)架構(gòu).傳統(tǒng)倉庫可依靠此系統(tǒng)改造成服務(wù)于電子商務(wù)的云倉庫, 形成倉儲配送一體化的新物流模式, 解決了多倉庫信息無法共享和協(xié)同工作的問題.

2) 訂單管理系統(tǒng)工作在云倉儲管理系統(tǒng)之上, 提供統(tǒng)一的訂單接口, 接收來自不同平臺的消費(fèi)者訂單, 統(tǒng)一了云倉儲內(nèi)部訂單數(shù)據(jù)結(jié)構(gòu)便于大數(shù)據(jù)分析.面對不斷變化的消費(fèi)者需求和海量的訂單數(shù)量, 基于知識庫的訂單分批策略在訂單管理系統(tǒng)中的應(yīng)用, 加快了訂單處理速度, 提高了收益率和倉庫的吞吐率.