【文章內(nèi)容簡介】 鑒于這兩種情況我們的建議是一旦不能部分或全部簽收 ， 系統(tǒng)即生成貨運事故處理單 3PL在送貨清單上標明是貨損還是貨差 。 物流運作部的貨運事故處理員根據(jù)系統(tǒng)自動生成的貨運事故處理單和 3PL提交的貨運事故報案表來進行貨損貨差的處理 。 對于貨損的情況完成了賠付和補發(fā)物料的操作后點擊處理后 ，流程終止 。 而對于貨差的情況點擊沖紅按鈕系統(tǒng)生成貨險沖紅請求等待計劃員處理 。 注：沖紅單的主要內(nèi)容包括 (貨運事故報案表編號 、 原發(fā)貨計劃號 、 發(fā)貨沖紅內(nèi)容 ) ?對貨險沖紅掛帳單進行處理 事業(yè)部計劃員作出發(fā)貨計劃沖紅審核后 ， 即生成貨險沖紅掛帳單 。 出現(xiàn)貨損的貨物的所有權即轉(zhuǎn)為物流運作部 ， 貨險處理員有義務對該掛帳單進行處理 ， 直到發(fā)生貨險的貨物被完全完畢 。 輸入：貨險沖紅掛帳單 輸出：處理過的貨險沖紅掛帳單 ? 事業(yè)部計劃員 ? 審核貨險沖紅申請單 事業(yè)部計劃員根據(jù)物流部上傳的貨險沖紅單進行審批 ， 系統(tǒng)隨即會對要沖紅的發(fā)貨計劃進行沖紅同時會詢問是否要對收貨方繼續(xù)發(fā)貨 ， 如果要繼續(xù)發(fā)貨則自動生成新的發(fā)貨計劃 （ 進入新的發(fā)貨計劃處理流程 ） ， 如果無需繼續(xù)發(fā)貨則不做處理 。 輸入：貨險沖紅單 輸出：審核后的貨險沖紅單 、 新的發(fā)貨計劃 （ 可選 ） ? 生成貨險沖紅掛帳單 一旦計劃員審核了由物流運作部提交的貨險沖紅單 ， 無論是否繼續(xù)發(fā)貨系統(tǒng)都會生成貨險沖紅掛帳單并將收貨方改為物流運作部 。 輸入：審核后的貨險沖紅單 輸出：貨險沖紅掛帳單 RDC調(diào)撥處理 填寫調(diào)撥計劃 銷售預測 數(shù)據(jù) 生成調(diào)撥計劃 調(diào)撥計 劃 [初稿 ] Start 初稿 草稿 正式稿 最終審批 End 調(diào)撥計 劃 [正式稿 ] 庫存信 息 準備出庫 庫存信 息 準備入庫 調(diào)整計劃 調(diào)撥計 劃 [草稿 ] 物流運作部 RDC2(調(diào)入 ) RDC(調(diào)出 ) 事業(yè)部計劃協(xié)調(diào)員 事業(yè)部計劃員 RDC調(diào)撥處理流程描述 ? 事業(yè)部計劃員 ? 生成調(diào)撥計劃初稿 調(diào)撥計劃的產(chǎn)生是由兩個前因來驅(qū)動的 （ 分公司的調(diào)撥申請 、 總部銷售預測 ） ， 事業(yè)部計劃員填寫調(diào)撥計劃提交給物流中心 。 注：調(diào)撥計劃的主要內(nèi)容包括 (調(diào)出 RDC名稱 、 調(diào)入 RDC名稱 、 計劃內(nèi)容 ) 輸入：調(diào)撥申請 （ 手工 ） 、 各 RDC庫存 、銷售預測 輸出：調(diào)撥計劃 生成調(diào)撥計劃初稿（補充） （ 1） 制作調(diào)撥計劃參考的因素主要有以下六點 ? 調(diào)撥申請 ? 調(diào)出 RDC庫存 ? 調(diào)入 RDC庫存 ? 銷售數(shù)據(jù) ? 電話溝通 ? 銷售預測 （ 2） 事業(yè)部計劃員完成計劃后發(fā)到物流運作部 ， 物流運作部根據(jù)運力情況并與事業(yè)部計劃員協(xié)商后調(diào)整計劃 ，后交由事業(yè)部計劃協(xié)調(diào)員做最終審核后下達物流運作部執(zhí)行 。 在傳遞過程中會產(chǎn)生 3次數(shù)值，一次是初始值，第二次是物流部修改的值，第三次是事業(yè)部最終確定的數(shù)值。 ?生成正式調(diào)撥計劃 事業(yè)部計劃員收到經(jīng)過物流運作部調(diào)整的后的調(diào)撥計劃 ， 經(jīng)過事業(yè)部計劃協(xié)調(diào)員的最終審核后交由物流運作部進行運作 。 當物流運作部開始運輸流程時計劃員可以對調(diào)撥計劃的執(zhí)行情況進行跟蹤 。 輸入：經(jīng)過物流運作部根據(jù)運力調(diào)整后的調(diào)撥計劃 輸出：正式調(diào)撥計劃 RDC調(diào)撥處理流程描述 ? 物流中心干線計劃員 ? 調(diào)整調(diào)撥計劃 物流中心干線計劃員對各事業(yè)部計劃員提交的調(diào)撥計劃進行調(diào)整后 ， 交還給事業(yè)部計劃協(xié)調(diào)員員進行最終確認 。 輸入：事業(yè)部計劃員交來的調(diào)撥計劃 輸出：經(jīng)過運力調(diào)整的調(diào)撥計劃 RDC調(diào)撥處理流程描述 ? 事業(yè)部計劃協(xié)調(diào)員 ?最終審核調(diào)撥計劃 事業(yè)部計劃協(xié)調(diào)員員對調(diào)撥計劃進行最終確認 。 輸入：運力調(diào)整后的調(diào)撥計劃 輸出：最終的調(diào)撥計劃 物流管理系統(tǒng)軟件架構 TULIP系統(tǒng)的軟件架構 ?業(yè)務模型 ?設計思路 ?設計模式 ?實現(xiàn)架構 軟件架構 業(yè)務模型 分公司 1 事業(yè)部 1 訂單 補貨 調(diào)拔 經(jīng)營部 2 經(jīng)營部 3 補貨 補貨 調(diào)拔 經(jīng)營部 1 管理 客戶 客戶 客戶 客戶 客戶 調(diào)拔 調(diào)拔 補貨 下訂單 。每個客戶有且只有一個為之服務的 xDC. 。經(jīng)營部通過客戶來決定可以查看的 xDC庫存 . 。分公司可以管理多個 xDC 補貨訂單 工廠 CDC RDC DC 客戶 。工廠 到 CDC 。工廠 到 RDC 。工廠 到 DC 。工廠 到 客戶 。 CDC 到 RDC 。 CDC 到 DC 。 CDC 到 客戶 。 RDC 到 DC 。 RDC 到 RDC 。 RDC 到 客戶 。 DC 到 客戶 物流網(wǎng)絡模型 下單機構 審單機構 總部 分公司 事業(yè)部 經(jīng)營部 分公司產(chǎn)品部 大客戶 分公司 CDC RDC DC 工廠 CDC RDC 客戶 CDC ?？蛻粼谝粋€ DC的服務范圍內(nèi) 。客戶屬于某個下單機構 。下單機構通過客戶來決定可以 查看哪個 DC的庫存 。下單機構隸屬于某個審單機構 。審單機構可以管理多個 DC 。該審單機構下所有下單機構的 所有客戶的隸屬 DC都在該審單 機構的管理之下。 客戶 客戶 物流與商流 軟件架構 設計原則 ?系統(tǒng)之間的低耦合 降低系統(tǒng)的耦合度，盡量使每個業(yè)務單位的子系統(tǒng)都可以獨立運行。 減少各系統(tǒng)間的依賴關系。 ?系統(tǒng)的擴展與可配置 注重對接口的設計，增強與其它系統(tǒng)的數(shù)據(jù)交換能力。 ?面向?qū)ο蟮姆治雠c設計 應用面向?qū)ο蟮姆治雠c設計技術，采用原型法來進行系統(tǒng)開發(fā)。 軟件架構 設計原則 小結： TULIP系統(tǒng)的重點并非提供一個在每個業(yè)務環(huán)節(jié)都非常完整及完美的軟件系統(tǒng)，而是為了實現(xiàn)對訂單的實時跟蹤，統(tǒng)一管理以及對整個銷售網(wǎng)絡中庫存的實時監(jiān)控，及時準確地反映業(yè)務數(shù)據(jù)，以整合規(guī)范業(yè)務流程為主要目的的 IT系統(tǒng)。因此，要求 TULIP系統(tǒng)中的每個子系統(tǒng)均以低耦合度相連，將來被其它系統(tǒng)所代替時，不會影響業(yè)務流程的完整性。 軟件架構 設計模式 ?代理關系機制 應用代理技術來實現(xiàn)系統(tǒng)中某些業(yè)務對象之間的業(yè)務關系。使重組或更改業(yè)務關系變得更容易。 ?設計模式 應用 Factory,Agent,Singleton,Handler,Controller等設計模式，保持代碼的清析與易懂。 例如： public class OrderManagerFactory { private static OrderManager ivOrderManager。 public OrderManagerFactory() { } public OrderManager getManagerBy(String manager) { return (new OrderDefaultManager())。 } public static OrderManager getDefaultFactory() { if ( ivOrderManager == null ) ivOrderManager = new OrderDefaultManager()。 return ivOrderManager。 } } 軟件架構 訂單 倉儲 運輸 報表 系統(tǒng)管理 (產(chǎn)品 ,客戶 ,機構 ,用戶等 ) 系 統(tǒng) 接 口 Java Platform 其它系統(tǒng) CRM JXC DB Report 軟件架構 Manager BO BC Handler DB JSP BO=BusinessObject BC=BusinessObjectController 從 JSP客戶端發(fā)出的每次請求，經(jīng)過 SessionManager的處理后，根據(jù)不同的 Command分發(fā)給不同 Handler來處理， Handler然后調(diào)用相應的 Manager來處理業(yè)務邏輯，最后由Controller來完成對數(shù)據(jù)庫的操作。 Session Manager TULIP系統(tǒng)的數(shù)據(jù)庫設計 ?主要數(shù)據(jù)模型 ?訂單處理 ?入庫出庫 ?運輸與貨險 ?機構管理 ?用戶及權限 ?代理關系 ?產(chǎn)品管理 數(shù)據(jù)庫設計 O rd e rIDT yp eS e n d e rS h i p p i n g M e th o dP i ck i n g A d d re ssR e q u i re d D a teR e q u i re d T i m eR e ce i ve rR e ce i vi n g A d d re ssR e ce i ve rC o n ta ctP h o n eC re a te rC re a ti o n D a teS u b m i tte rC o n fi rm D a teC o m m e n tB i zS ta tu sS ta tu sR D C IDO ri g i n a l IDV A R C H A R 2 (1 8 )V A R C H A R 2 (2 )V A R C H A R 2 (6 )V A R C H A R 2 (2 )V A R C H A R 2 (1 0 0 )V A R C H A R 2 (1 6 )V A R C H A R 2 (1 6 )V A R C H A R 2 (6 )V A R C H A R 2 (1 0 0 )V A R C H A R 2 (2 0 )V A R C H A R 2 (2 0 )V A R C H A R 2 (6 )V A R C H A R 2 (1 6 )V A R C H A R 2 (2 0 )V A R C H A R 2 (1 6 )V A R C H A R 2 (2 0 0 )N U M B E RN U M B E RV A R C H A R 2 (6 )V A R C H A R 2 (2 0 ) p k fk1 fk4 fk3 fk2 fk5 O rd e rA d j u st m e n tIDT yp eC re a t i o n D a t eS e n d e rS u b m i t t e rO rd e rA d j u st e d O rd e rS t a t u sC o n f i rm D a t eC o m m e n tO ri g i n a l I DV A R C H A R 2 (1 6 )N U M B E RV A R C H A R 2 (1 6 )V A R C H A R 2 (6 )V A R C H A R 2 (2 0 )V A R C H A R 2 (1 8 )V A R C H A R 2 (1 8 )N U M B E RV A R C H A R 2 (1 6 )V A R C H A R 2 (1 0 0 )V A R C H A R 2 (2 0 ) p k f k3 f k1 f k2 R e ce i vi n g D o cu m e n tIDT yp eR e ce i p t D a t eW a re h o u seS e n d e rC o n si g n m e n t N o t eO p e ra t o rC re a t e rC o m m e n tS t a t u sV A R C H A R 2 (1 6 )V A R C H A R 2 (2 )V A R C H A R 2 (1 6 )V A R C H A R 2 (6 )V A R C H A R 2 (2 0 )V A R C H A R 2 (1 8 )V A R C H A R 2 (2 0 )V A R C H A R 2 (6 )V A R C H A R 2 (1 0 0 )N U M B E R