【正文】 訂單接收方的審核，訂單執(zhí)行；訂單運(yùn)作信息的實(shí)時(shí)查詢；訂單沖紅的輸入，審核和實(shí)現(xiàn)；以及訂單狀態(tài)的實(shí)時(shí)查詢。 訂單管理模塊完成訂單從產(chǎn)生到簽收完畢之間的完整閉環(huán)的信息處理。 如果是經(jīng)營(yíng)部自己的訂單 ， 系統(tǒng)本著客戶訂單優(yōu)先要貨 、 盡量減少經(jīng)營(yíng)部要貨的原則 ， 不會(huì)根據(jù)訂單的數(shù)量來刪減可用庫(kù)存 ，直到事業(yè)部計(jì)劃員審核該張訂單后庫(kù)存才會(huì)減少 。 事業(yè)部計(jì)劃員（分公司） ? 庫(kù)存查詢 庫(kù)存的查詢是事業(yè)部計(jì)劃員 （ 分公司 ） 作為審核經(jīng)營(yíng)部訂單 （ 客戶和經(jīng)營(yíng)部自己的訂單 ） 的一個(gè)重要條件 ， 計(jì)劃員看到的庫(kù)存結(jié)構(gòu)與經(jīng)營(yíng)部看到的庫(kù)存略有不同 ， 不但提供的可用庫(kù)存的信息還提供了實(shí)際庫(kù)存和待出庫(kù)數(shù)量的信息 。為了保障經(jīng)營(yíng)部能夠及時(shí)準(zhǔn)確的查詢到訂單的執(zhí)行狀態(tài)，要求分公司計(jì)劃員在第一時(shí)間內(nèi)進(jìn)行審核操作。 主要使用者為 RDC管理員，物流經(jīng)理，物流運(yùn)作管理部門，管理 RDC的 3PL。 倉(cāng)管員在做修還入庫(kù)時(shí)必須將原有的維修出庫(kù)單的單號(hào)錄入原單單號(hào)的文字欄中以便核對(duì)維修出庫(kù)領(lǐng)用的型號(hào) 、 數(shù)量是否可以和入庫(kù)的型號(hào) 、 數(shù)量相對(duì)應(yīng) 。 倉(cāng)管員在做維修出庫(kù)時(shí)必須將售后服務(wù)中心開具的維修領(lǐng)用單的單號(hào)錄入原單單號(hào)的文字欄中以便日后同維修領(lǐng)用單上標(biāo)注的型號(hào) 、 數(shù)量進(jìn)行核對(duì) 。 注： 顯示待出庫(kù)的數(shù)量時(shí)是為了提醒倉(cāng)管員還有部分物品是處于余留狀態(tài)的以便指導(dǎo)其工作。物流經(jīng)理便可以在網(wǎng)上隨時(shí)監(jiān)控訂單的執(zhí)行情況。 第二階段業(yè)務(wù)流程 第二階段業(yè)務(wù)流程 ? 補(bǔ)貨計(jì)劃處理流程 ? CDC管理流程 ? 干線運(yùn)輸管理流程 ? 干線運(yùn)輸貨險(xiǎn)沖紅流程 ? RDC調(diào)撥處理流程 通用業(yè)務(wù)處理流程實(shí)現(xiàn)的目標(biāo)是建立一套支持多元化產(chǎn)品及多渠道銷售的信息平臺(tái)。 輸入：經(jīng)過物流運(yùn)作部根據(jù)運(yùn)力調(diào)整后的補(bǔ)貨計(jì)劃 輸出：正式補(bǔ)貨計(jì)劃 補(bǔ)貨計(jì)劃處理 —— 流程描述 ?物流中心干線計(jì)劃員 ?調(diào)整補(bǔ)貨計(jì)劃 物流中心干線計(jì)劃員對(duì)各事業(yè)部計(jì)劃員提交的發(fā)貨計(jì)劃進(jìn)行數(shù)量上調(diào)整后 ， 交還給事業(yè)部計(jì)劃協(xié)調(diào)員員進(jìn)行最終確認(rèn) 。 輸入：發(fā)貨指令 （ 補(bǔ)貨計(jì)劃 、 調(diào)撥計(jì)劃 、 返廠計(jì)劃等 ） 輸出：送貨清單 ?對(duì)送貨清單進(jìn)行跟蹤維護(hù) 送貨清單生成后交由具體運(yùn)輸人員攜帶 ， 在運(yùn)輸過程中運(yùn)輸管理員可以隨時(shí)通過各種方式同運(yùn)輸人員進(jìn)行聯(lián)系 ， 及時(shí)了解運(yùn)輸?shù)那闆r并維護(hù)入送貨清單 。 這部分的處理一定要進(jìn)行沖紅處理 。 輸入：貨險(xiǎn)沖紅單 輸出：審核后的貨險(xiǎn)沖紅單 、 新的發(fā)貨計(jì)劃 （ 可選 ） ? 生成貨險(xiǎn)沖紅掛帳單 一旦計(jì)劃員審核了由物流運(yùn)作部提交的貨險(xiǎn)沖紅單 ， 無論是否繼續(xù)發(fā)貨系統(tǒng)都會(huì)生成貨險(xiǎn)沖紅掛帳單并將收貨方改為物流運(yùn)作部 。 輸入：運(yùn)力調(diào)整后的調(diào)撥計(jì)劃 輸出：最終的調(diào)撥計(jì)劃 物流管理系統(tǒng)軟件架構(gòu) TULIP系統(tǒng)的軟件架構(gòu) ?業(yè)務(wù)模型 ?設(shè)計(jì)思路 ?設(shè)計(jì)模式 ?實(shí)現(xiàn)架構(gòu) 軟件架構(gòu) 業(yè)務(wù)模型 分公司 1 事業(yè)部 1 訂單 補(bǔ)貨 調(diào)拔 經(jīng)營(yíng)部 2 經(jīng)營(yíng)部 3 補(bǔ)貨 補(bǔ)貨 調(diào)拔 經(jīng)營(yíng)部 1 管理 客戶 客戶 客戶 客戶 客戶 調(diào)拔 調(diào)拔 補(bǔ)貨 下訂單 。 CDC 到 RDC ?？蛻魧儆谀硞€(gè)下單機(jī)構(gòu) 。 ?面向?qū)ο蟮姆治雠c設(shè)計(jì) 應(yīng)用面向?qū)ο蟮姆治雠c設(shè)計(jì)技術(shù)，采用原型法來進(jìn)行系統(tǒng)開發(fā)。 } public static OrderManager getDefaultFactory() { if ( ivOrderManager == null ) ivOrderManager = new OrderDefaultManager()。 } } 軟件架構(gòu) 訂單 倉(cāng)儲(chǔ) 運(yùn)輸 報(bào)表 系統(tǒng)管理 (產(chǎn)品 ,客戶 ,機(jī)構(gòu) ,用戶等 ) 系 統(tǒng) 接 口 Java Platform 其它系統(tǒng) CRM JXC DB Report 軟件架構(gòu) Manager BO BC Handler DB JSP BO=BusinessObject BC=BusinessObjectController 從 JSP客戶端發(fā)出的每次請(qǐng)求，經(jīng)過 SessionManager的處理后，根據(jù)不同的 Command分發(fā)給不同 Handler來處理， Handler然后調(diào)用相應(yīng)的 Manager來處理業(yè)務(wù)邏輯，最后由Controller來完成對(duì)數(shù)據(jù)庫(kù)的操作。因此，要求 TULIP系統(tǒng)中的每個(gè)子系統(tǒng)均以低耦合度相連，將來被其它系統(tǒng)所代替時(shí)，不會(huì)影響業(yè)務(wù)流程的完整性。下單機(jī)構(gòu)隸屬于某個(gè)審單機(jī)構(gòu) 。 CDC 到 客戶 。經(jīng)營(yíng)部通過客戶來決定可以查看的 xDC庫(kù)存 . 。 注：調(diào)撥計(jì)劃的主要內(nèi)容包括 (調(diào)出 RDC名稱 、 調(diào)入 RDC名稱 、 計(jì)劃內(nèi)容 ) 輸入：調(diào)撥申請(qǐng) （ 手工 ） 、 各 RDC庫(kù)存 、銷售預(yù)測(cè) 輸出：調(diào)撥計(jì)劃 生成調(diào)撥計(jì)劃初稿（補(bǔ)充） （ 1） 制作調(diào)撥計(jì)劃參考的因素主要有以下六點(diǎn) ? 調(diào)撥申請(qǐng) ? 調(diào)出 RDC庫(kù)存 ? 調(diào)入 RDC庫(kù)存 ? 銷售數(shù)據(jù) ? 電話溝通 ? 銷售預(yù)測(cè) （ 2） 事業(yè)部計(jì)劃員完成計(jì)劃后發(fā)到物流運(yùn)作部 ， 物流運(yùn)作部根據(jù)運(yùn)力情況并與事業(yè)部計(jì)劃員協(xié)商后調(diào)整計(jì)劃 ，后交由事業(yè)部計(jì)劃協(xié)調(diào)員做最終審核后下達(dá)物流運(yùn)作部執(zhí)行 。 物流運(yùn)作部的貨運(yùn)事故處理員根據(jù)系統(tǒng)自動(dòng)生成的貨運(yùn)事故處理單和 3PL提交的貨運(yùn)事故報(bào)案表來進(jìn)行貨損貨差的處理 。 輸入：送貨清單 輸出：維護(hù)了過程信息的送貨清單 ? 送貨清單的簽收信息錄入 貨物到達(dá)后 ， 收貨方進(jìn)行簽收 。 輸入：運(yùn)力調(diào)整后的發(fā)貨計(jì)劃 輸出：最終的發(fā)貨計(jì)劃 CDC管理流程 開始 結(jié)束 是否合格 取消入庫(kù) ( NO ) 辦理入庫(kù) ( Yes ) 辦理入庫(kù)單 準(zhǔn)備入庫(kù) 入庫(kù)檢驗(yàn) 倉(cāng)管員 入庫(kù)流程 CDC管理流程 描述 —— CDC管理員 ?填寫入庫(kù)單 CDC管理員接到由工廠送來的貨物后通過隨貨物到達(dá)的批次計(jì)劃?rùn)z驗(yàn)貨物 ，滿足入庫(kù)條件后允許入庫(kù) 。（系統(tǒng)里要標(biāo)識(shí)該補(bǔ)貨計(jì)劃是由分公司的要貨訂單驅(qū)動(dòng)的，還是由總部自主進(jìn)行補(bǔ)貨） 補(bǔ)貨計(jì)劃的主要內(nèi)容包括 (發(fā)貨 CDC名稱、收貨 RDC名稱 OR收貨單位的名稱、計(jì)劃內(nèi)容 ) 輸入：要貨申請(qǐng) 、 RDC庫(kù)存 、 銷售預(yù)測(cè) 輸出：補(bǔ)貨計(jì)劃 生成補(bǔ)貨計(jì)劃初稿（補(bǔ)充） ? 制作補(bǔ)貨計(jì)劃參考的因素主要有以下六點(diǎn) ： 要貨計(jì)劃、 CDC庫(kù)存、 RDC庫(kù)存、銷售數(shù)據(jù)、電話溝通、銷售預(yù)測(cè) ? 補(bǔ)貨計(jì)劃有兩種方式： 直接對(duì)分公司提交的補(bǔ)貨訂單進(jìn)行審核后直接生成補(bǔ)貨計(jì)劃；由主動(dòng)補(bǔ)貨引發(fā)的手工填寫的補(bǔ)貨計(jì)劃。貨物到達(dá)目的地后，收貨方在隨運(yùn)輸人員到達(dá)的送貨清單上填寫實(shí)際收貨數(shù)量。 ? 查詢出庫(kù)記錄 功能和操作方法同查詢?nèi)霂?kù)記錄。 ?返廠出庫(kù) ： 該出庫(kù)類型較少使用 ， 當(dāng)倉(cāng)管員接到事業(yè)部下達(dá)的返廠計(jì)劃后將使用該類型進(jìn)行返廠出庫(kù) 。 ?沖紅入庫(kù) ：該出庫(kù)類型是為了修正非計(jì)劃入庫(kù)時(shí)產(chǎn)生的填寫錯(cuò)誤而導(dǎo)致庫(kù)存不準(zhǔn)確的情況而設(shè)立的 ， 在填寫沖紅入庫(kù)時(shí)一定要填入出錯(cuò)的入庫(kù)單號(hào)作為以后核對(duì)庫(kù)存的依據(jù) 。目前的倉(cāng)庫(kù)入庫(kù)操作必須全部使用非計(jì)劃入庫(kù)來完成。 事業(yè)部計(jì)劃員（分公司） ? 訂單沖紅審核 當(dāng)訂單沖紅申請(qǐng)被經(jīng)營(yíng)部提交上來后，分公司計(jì)劃員要根據(jù)實(shí)際情況進(jìn)行沖紅的審核操作，沖紅的對(duì)象只限于下達(dá)訂單未做實(shí)際發(fā)貨處理的部分（只可以沖減余留數(shù)量）。 操作指引：分公司計(jì)劃員進(jìn)入待處理訂單列表后選擇要處理的訂單后面的選定框進(jìn)行鎖定，鎖定后進(jìn)入訂單審核功能。 輸入：要貨信息 輸出：訂單 經(jīng)營(yíng)部計(jì)劃員 ? 查詢訂單 經(jīng)營(yíng)部計(jì)劃員或業(yè)務(wù)員可以隨時(shí)在網(wǎng)上查詢訂單的狀態(tài)（未審核、已審核、安排運(yùn)輸、在途、簽收）。 訂單處理模塊功能 ?新建訂單 ?修改訂單 ?取消訂單 ?訂單沖紅 ?訂單鎖定 ?計(jì)劃員審批訂單 ?訂單查詢 ?訂單打印 打印財(cái)務(wù)簽字 審核 審核 打印聯(lián)單 客戶 RDC 分公司物流部 （ 事業(yè)部 ） 經(jīng)營(yíng)部 客戶 出庫(kù)操作 接收到 貨信息 驗(yàn)貨簽收 作廢 要貨申請(qǐng) 傳真 Y N Y N 承運(yùn)商 財(cái)務(wù)開單 簽字確認(rèn) R D C聯(lián) 運(yùn)輸操作 配送聯(lián) 錄入 Tulip 經(jīng)營(yíng)部計(jì)劃員 ? 庫(kù)存查詢 庫(kù)存的查詢是經(jīng)營(yíng)部計(jì)劃員作為填寫訂單的一個(gè)重要條件，系統(tǒng)可以提供經(jīng)營(yíng)部計(jì)劃員隨時(shí)在網(wǎng)上查詢庫(kù)存情況，其中庫(kù)存分為兩大類型（１）正常品 和（２）殘次品。 TULIP執(zhí)行系統(tǒng)實(shí)現(xiàn)了分銷物流流程中的流程閉環(huán)處理以及運(yùn)作數(shù)據(jù)的采集，統(tǒng)計(jì)，和可視化； TULIP計(jì)劃系統(tǒng)將管理和支持網(wǎng)絡(luò)整體庫(kù)存的優(yōu)化工作。 經(jīng)營(yíng)部計(jì)劃員 ? 填寫訂單 經(jīng)營(yíng)部計(jì)劃員直接從客戶或通過業(yè)務(wù)員收集和匯總客戶訂貨信息 , 經(jīng)財(cái)務(wù)審核后 ， 如果庫(kù)存滿足訂單需求 ,就開始填寫訂單 。 ? 訂單沖紅 當(dāng)訂單被事業(yè)部計(jì)劃員審核之后，經(jīng)營(yíng)部如果有訂單變更或取消的業(yè)務(wù)需求時(shí)要進(jìn)行沖紅操作。因此當(dāng)查詢到的庫(kù)存數(shù)量不能滿足訂單需求時(shí)每個(gè)經(jīng)營(yíng)部可以在隔段時(shí)間再次查詢可用庫(kù)存是否滿足訂單需求。 注：對(duì)于未審核的訂單因?yàn)闀?huì)存在取消的可能性所有不作為正式訂單在訂單查詢里出現(xiàn) 。 ?調(diào)撥入庫(kù) ：跟補(bǔ)貨計(jì)劃相同也是為了彌補(bǔ) 缺 ， 倉(cāng)管員選擇了入庫(kù)類型為調(diào)撥入庫(kù)后 ， 必須選擇相應(yīng)的發(fā)貨倉(cāng)庫(kù)的名稱和對(duì)應(yīng)的調(diào)撥計(jì)劃的計(jì)劃好后才可以進(jìn)行入庫(kù)單內(nèi)同的輸入 。 RDC倉(cāng)管員 ? 非計(jì)劃出庫(kù) 非計(jì)劃出庫(kù)是為了解決在 未實(shí)施前代替流程中的部分環(huán)節(jié)所作的臨時(shí)功能。 ?沖紅出庫(kù) ： 該出庫(kù)類型是為了修正非計(jì)劃出庫(kù)時(shí)產(chǎn)生的填寫錯(cuò)誤而導(dǎo)致庫(kù)存不準(zhǔn)確的情況而設(shè)立的 ， 在填寫沖紅出庫(kù)時(shí)一定要填入出錯(cuò)的出庫(kù)單號(hào)作為以后核對(duì)庫(kù)存的依據(jù) 。 運(yùn)輸管理模塊功能 ? 生成送貨清單 ? 送貨清單打印 ? 送貨清單維護(hù) ? 生成沖紅通知單 運(yùn)輸管理模塊功能說明 ? 生成送貨清單 根據(jù)訂單生成送貨清單：系統(tǒng)設(shè)計(jì)的原則是一張訂單可以對(duì)應(yīng)多張送貨清單運(yùn)。 運(yùn)輸管理模塊功能說明 ? 生成沖紅通知單 如客戶簽收的貨物數(shù)量與送貨清單上的貨物數(shù)量不相等，系統(tǒng)自動(dòng)顯示該頁面，讓運(yùn)輸公司填寫沖紅通知單，主要用于記錄貨物運(yùn)輸過程中發(fā)生貨損、貨差的狀況。 ? 總部計(jì)劃在參考 CDC庫(kù)存的時(shí)候只參考這個(gè) CDC的合計(jì)庫(kù)存而不管其內(nèi)部是如何分布的，因?yàn)閭}(cāng)庫(kù)產(chǎn)品類型和存貨量分布非常的不均勻。 輸入：審核后的發(fā)貨計(jì)劃 輸出：出庫(kù)單 干線運(yùn)輸管理 正式 下達(dá)正式補(bǔ)貨 訂單 補(bǔ)貨訂 單 [正式 ] 下達(dá)發(fā)貨指令 選擇運(yùn)輸商 補(bǔ)貨訂 單 [正式 ] 出庫(kù)準(zhǔn)備 出庫(kù)準(zhǔn)備 運(yùn)輸準(zhǔn)備 運(yùn)輸 簽收 返回簽收結(jié)果 簽收情 況 客戶 /RDC 3PL CDC 物流運(yùn)作部 事業(yè)部 干線運(yùn)輸管理流程描述 ? 物流中心干線計(jì)劃員 ? 對(duì)事業(yè)部下達(dá)的發(fā)貨指令進(jìn)行承運(yùn)商的分配工作 根據(jù)事業(yè)部下達(dá)的發(fā)貨指令選擇運(yùn)輸商 ，提交系統(tǒng)后會(huì)將各承運(yùn)商所需要操作的訂單分發(fā) 。 輸入：貨運(yùn)事故報(bào)案表 （ 手工 ） 輸出：貨險(xiǎn)沖紅單 （ 1）貨損處理 貨損是指貨物在運(yùn)輸過程中沒有太大的損壞 ， 通過業(yè)務(wù)模式和補(bǔ)發(fā)物料可以解決的 。 注：沖紅單的主要內(nèi)容包括 (貨運(yùn)事故報(bào)案表編號(hào) 、 原發(fā)貨計(jì)劃號(hào) 、 發(fā)貨沖紅內(nèi)容 ) ?對(duì)貨險(xiǎn)沖紅掛帳單進(jìn)行處理 事業(yè)部計(jì)劃員作出發(fā)貨計(jì)劃沖紅審核后 ， 即生成貨險(xiǎn)沖紅掛帳單 。 當(dāng)物流運(yùn)作部開始運(yùn)輸流程時(shí)計(jì)劃員可以對(duì)調(diào)撥計(jì)劃的執(zhí)行情況進(jìn)行跟蹤 。工廠 到 RDC 。 RDC 到 客戶 。 客戶 客戶 物流與商流 軟件架構(gòu) 設(shè)計(jì)原則 ?系統(tǒng)之間的低耦合 降低系統(tǒng)的耦合度，盡量使每個(gè)業(yè)務(wù)單位的子系統(tǒng)都可以獨(dú)立運(yùn)行。 ?設(shè)計(jì)模式 應(yīng)用 Factory,Agent,Singleton,Handler,Controller等設(shè)計(jì)模式，保持代碼的清析與