企業物流管理信息系統(1)(編輯修改稿)

　

【文章內容簡介】 。 鑒于這兩種情況我們的建議是一旦不能部分或全部簽收 ， 系統即生成貨運事故處理單 3PL在送貨清單上標明是貨損還是貨差 。 物流運作部的貨運事故處理員根據系統自動生成的貨運事故處理單和 3PL提交的貨運事故報案表來進行貨損貨差的處理 。 對于貨損的情況完成了賠付和補發物料的操作后點擊處理后 ，流程終止 。 而對于貨差的情況點擊沖紅按鈕系統生成貨險沖紅請求等待計劃員處理 。 注：沖紅單的主要內容包括 (貨運事故報案表編號 、 原發貨計劃號 、 發貨沖紅內容 ) ?對貨險沖紅掛帳單進行處理 事業部計劃員作出發貨計劃沖紅審核后 ， 即生成貨險沖紅掛帳單 。 出現貨損的貨物的所有權即轉為物流運作部 ， 貨險處理員有義務對該掛帳單進行處理 ， 直到發生貨險的貨物被完全完畢 。 輸入：貨險沖紅掛帳單 輸出：處理過的貨險沖紅掛帳單 ? 事業部計劃員 ? 審核貨險沖紅申請單 事業部計劃員根據物流部上傳的貨險沖紅單進行審批 ， 系統隨即會對要沖紅的發貨計劃進行沖紅同時會詢問是否要對收貨方繼續發貨 ， 如果要繼續發貨則自動生成新的發貨計劃 （ 進入新的發貨計劃處理流程 ） ， 如果無需繼續發貨則不做處理 。 輸入：貨險沖紅單 輸出：審核后的貨險沖紅單 、 新的發貨計劃 （ 可選 ） ? 生成貨險沖紅掛帳單 一旦計劃員審核了由物流運作部提交的貨險沖紅單 ， 無論是否繼續發貨系統都會生成貨險沖紅掛帳單并將收貨方改為物流運作部 。 輸入：審核后的貨險沖紅單 輸出：貨險沖紅掛帳單 RDC調撥處理 填寫調撥計劃 銷售預測 數據 生成調撥計劃 調撥計 劃 [初稿 ] Start 初稿 草稿 正式稿 最終審批 End 調撥計 劃 [正式稿 ] 庫存信 息 準備出庫 庫存信 息 準備入庫 調整計劃 調撥計 劃 [草稿 ] 物流運作部 RDC2(調入 ) RDC(調出 ) 事業部計劃協調員 事業部計劃員 RDC調撥處理流程描述 ? 事業部計劃員 ? 生成調撥計劃初稿 調撥計劃的產生是由兩個前因來驅動的 （ 分公司的調撥申請 、 總部銷售預測 ） ， 事業部計劃員填寫調撥計劃提交給物流中心 。 注：調撥計劃的主要內容包括 (調出 RDC名稱 、 調入 RDC名稱 、 計劃內容 ) 輸入：調撥申請 （ 手工 ） 、 各 RDC庫存 、銷售預測 輸出：調撥計劃 生成調撥計劃初稿（補充） （ 1） 制作調撥計劃參考的因素主要有以下六點 ? 調撥申請 ? 調出 RDC庫存 ? 調入 RDC庫存 ? 銷售數據 ? 電話溝通 ? 銷售預測 （ 2） 事業部計劃員完成計劃后發到物流運作部 ， 物流運作部根據運力情況并與事業部計劃員協商后調整計劃 ，后交由事業部計劃協調員做最終審核后下達物流運作部執行 。 在傳遞過程中會產生 3次數值，一次是初始值，第二次是物流部修改的值，第三次是事業部最終確定的數值。 ?生成正式調撥計劃 事業部計劃員收到經過物流運作部調整的后的調撥計劃 ， 經過事業部計劃協調員的最終審核后交由物流運作部進行運作 。 當物流運作部開始運輸流程時計劃員可以對調撥計劃的執行情況進行跟蹤 。 輸入：經過物流運作部根據運力調整后的調撥計劃 輸出：正式調撥計劃 RDC調撥處理流程描述 ? 物流中心干線計劃員 ? 調整調撥計劃 物流中心干線計劃員對各事業部計劃員提交的調撥計劃進行調整后 ， 交還給事業部計劃協調員員進行最終確認 。 輸入：事業部計劃員交來的調撥計劃 輸出：經過運力調整的調撥計劃 RDC調撥處理流程描述 ? 事業部計劃協調員 ?最終審核調撥計劃 事業部計劃協調員員對調撥計劃進行最終確認 。 輸入：運力調整后的調撥計劃 輸出：最終的調撥計劃 物流管理系統軟件架構 TULIP系統的軟件架構 ?業務模型 ?設計思路 ?設計模式 ?實現架構 工廠 CDC RDC DC 客戶 。工廠 到 CDC 。工廠 到 RDC 。工廠 到 DC 。工廠 到 客戶 。 CDC 到 RDC 。 CDC 到 DC 。 CDC 到 客戶 。 RDC 到 DC 。 RDC 到 RDC 。 RDC 到 客戶 。 DC 到 客戶 物流網絡模型 軟件架構 設計原則 ?系統之間的低耦合 降低系統的耦合度，盡量使每個業務單位的子系統都可以獨立運行。 減少各系統間的依賴關系。 ?系統的擴展與可配置 注重對接口的設計，增強與其它系統的數據交換能力。 ?面向對象的分析與設計 應用面向對象的分析與設計技術，采用原型法來進行系統開發。 軟件架構 設計原則 小結： TULIP系統的重點并非提供一個在每個業務環節都非常完整及完美的軟件系統，而是為了實現對訂單的實時跟蹤，統一管理以及對整個銷售網絡中庫存的實時監控，及時準確地反映業務數據，以整合規范業務流程為主要目的的 IT系統。因此，要求 TULIP系統中的每個子系統均以低耦合度相連，將來被其它系統所代替時，不會影響業務流程的完整性。 軟件架構 設計模式 ?代理關系機制 應用代理技術來實現系統中某些業務對象之間的業務關系。使重組或更改業務關系變得更容易。 ?設計模式 應用 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。 } } 軟件架構 訂單 倉儲 運輸 報表 系統管理 (產品 ,客戶 ,機構 ,用戶等 ) 系 統 接 口 Java Platform 其它系統 CRM JXC DB Report 軟件架構 Manager BO BC Handler DB JSP BO=BusinessObject BC=BusinessObjectController 從 JSP客戶端發出的每次請求，經過 SessionManager的處理后，根據不同的 Command分發給不同 Handler來處理， Handler然后調用相應的 Manager來處理業務邏輯，最后由Controller來完成對數據庫的操作。 Session Manager TULIP系統的數據庫設計 ?主要數據模型 ?訂單處理 ?入庫出庫 ?運輸與貨險 ?機構管理 ?用戶及權限 ?代理關系 ?產品管理 數據庫設計 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 p k f k1 f k2 f k2 ?主要數據模型 TULIP系統中的主要數據模型為訂單，出庫單，入庫單，沖紅單，送貨清單，掛帳單，庫存，產品，機構等之間的關系模型，而且也主要以處理以上幾種業務對象的關系為主。 D i sp a tch D o cu m e n tIDT yp eD i sp a tch D a teW a re h o u seP i ck e rP i ck i n g T i ck e tC re a te rO p e ra to rC o m m e n tS ta tu 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 (6 )V A R C H A R 2 (2 0 )V A R C H A R