企業物流管理信息系統1、企業基本資料2、系統目標3、需求分析4、重要流程5、重要功能企業物流管理信息系統1、企業基本資料11、企業基本資料生產——銷售型的集團企業生產分布在全國的多個地區在全國建立有比較完善的銷售體系，銷售人員占整個企業的比例較大銷售體系中可以代銷其他企業的同類商品產品包括：家電類、計算機等信息產品1、企業基本資料生產——銷售型的集團企業21、企業基本資料家電生產企業網絡產品生產企業通信類產品生產企業銷售公司計算機生產企業集團公司產品生產隸屬關系產品銷售隸屬關系1、企業基本資料家電生產企業網絡產品生產企業通信類產品生產企3家電網絡產品通信產品銷售公司計算機區域銷售分公司直屬銷售分公司………省級銷售公司省級銷售公司……經營部倉庫倉庫經營部經營部倉庫倉庫經營部…………區域銷售分公司：華北、東北、華中、 華東、西北、西南、 華南直屬銷售分公司：廣東、山東、新疆、 四川、海南、江西、 廣西家電網絡產品通信產品銷售公司計算機區域銷售分公司直屬銷售分公41、企業基本資料存在問題：一種典型的“垂直型”的銷售架構各個分公司、直屬公司之間的銷售貨物不能互相補充倉庫的產品調配只能由上級公司負責各個倉庫之間不存在聯系商品的供應、沖紅、退貨由上級公司負責1、企業基本資料存在問題：5經營部事業部銷售中心客戶分公司銷售公司總部分公司產品部集團機構模式下單機構審單機構總部客戶分公司事業部經營部分公司產品部大客戶分公司TULIP機構模式機構模式經營部事業部銷售中心客戶分公司銷售公司總部分公司產品部集團機6需求分析 TULIP由執行和計劃兩大系統組成。

TULIP執行系統實現了分銷物流流程中的流程閉環處理以及運作數據的采集，統計，和可視化； TULIP計劃系統將管理和支持網絡整體庫存的優化工作。需求分析 TULIP由執行和計劃兩大系統組成。7需求分析第一階段經營部在網上按照發貨要求（自提或配送）填寫要貨訂單經營部在網上填寫沖紅申請單事業部計劃員根據業務情況審核經營部提交的訂單事業部計劃員審核經營部提交的沖紅訂單RDC管理員根據收發貨指令進行倉庫作業運輸管理員根據訂單指令進行運輸作業。需求分析第一階段8需求分析第二階段CDC庫存管理補貨計劃管理RDC調撥計劃管理干線運輸管理 在第一階段基礎上提出一個流程優化，支持多產品，計劃信息平臺解決方案需求分析第二階段9第一階段流程第一階段流程10訂單處理流程 訂單管理模塊實現客戶訂單的輸入，提交；訂單接收方的審核，訂單執行；訂單運作信息的實時查詢；訂單沖紅的輸入，審核和實現；以及訂單狀態的實時查詢。訂單管理模塊完成訂單從產生到簽收完畢之間的完整閉環的信息處理。主要使用者為經營部和事業部（分公司）的計劃員。訂單處理流程 訂單管理模塊實現客戶訂單的輸入，提交；訂單接11訂單處理模塊功能新建訂單修改訂單取消訂單訂單沖紅訂單鎖定計劃員審批訂單訂單查詢訂單打印訂單處理模塊功能新建訂單12打印財務簽字審核審核打印聯單客戶RDC分公司物流部（事業部）經營部客戶出庫操作接收到貨信息驗貨簽收作廢要貨申請傳真YNYN承運商財務開單簽字確認RDC聯運輸操作配送聯錄入Tulip打印財務簽字審核審核打印聯單客戶RDC分公司物流部（事業部）13經營部計劃員庫存查詢庫存的查詢是經營部計劃員作為填寫訂單的一個重要條件，系統可以提供經營部計劃員隨時在網上查詢庫存情況，其中庫存分為兩大類型（１）正常品和（２）殘次品。正常品是指能夠下達訂單要貨的物品。殘次品是指未經過修復不能直接下達訂單要貨的物品。經營部計劃員庫存查詢14經營部計劃員填寫訂單經營部計劃員直接從客戶或通過業務員收集和匯總客戶訂貨信息,經財務審核后，如果庫存滿足訂單需求,就開始填寫訂單。由于所填寫的訂單中的要貨信息是經過經營部財務審核后的，所以被視為有效，合法的訂單，在訂單提交并審核后后不得隨意提出沖紅請求，此項可以視為經營部的考核標準之一。為了配合物流改革的模式，經營部填寫完訂單提交之后，系統會檢查該張訂單是客戶訂單還是經營部自己的訂單，如果是客戶訂單，系統可用庫存隨之減少。如果是經營部自己的訂單，系統本著客戶訂單優先要貨、盡量減少經營部要貨的原則，不會根據訂單的數量來刪減可用庫存，直到事業部計劃員審核該張訂單后庫存才會減少。在系統未完全取代手工操作之前，經營部計劃員要將訂單打印出來交經營部財務簽字確認后將該訂單傳真至分公司等待審核（待到運行穩定后將取消傳真的操作，訂單轉為完全電子化）以保持訂單的嚴謹性.這時經營部計劃員要及時登錄到系統查看訂單的狀態，當發現提交的訂單分公司已審核，經營部財務要依此訂單在財務系統上開單。輸入：要貨信息輸出：訂單經營部計劃員填寫訂單15經營部計劃員查詢訂單 經營部計劃員或業務員可以隨時在網上查詢訂單的狀態（未審核、已審核、安排運輸、在途、簽收）。取消訂單 當經營部計劃員需要取消所下的訂單時首先在網上查詢訂單的狀態，如果該訂單未被審核系統允許取消訂單，可用庫存量隨之增加。如果該訂單已經被審核則無法進行取消操作，而要進行沖紅處理。訂單沖紅 當訂單被事業部計劃員審核之后，經營部如果有訂單變更或取消的業務需求時要進行沖紅操作。事業部計劃員會酌情進行部分沖紅或全部沖紅的審核工作，具體要求參考事業部計劃員沖紅審核（分公司）。打印訂單經營部計劃員查詢訂單16經營部計劃員客戶管理 經營部可以自主管理屬下的客戶，在新建訂單時需要的客戶信息全部在該功能中提前輸入，為了保證歷史數據的一致性，所有錄入的客戶資料系統不提供刪除功能，對于需要刪除該客戶的要求系統提供停用該用戶的功能，一旦該用戶被停用在新建訂單時，客戶列表不會出現該客戶名稱，如果情況發生變化該客戶又開始參與業務活動，經營部計劃員只需要將該用戶重新啟用即可。經營部計劃員客戶管理17事業部計劃員（分公司）庫存查詢 庫存的查詢是事業部計劃員（分公司）作為審核經營部訂單（客戶和經營部自己的訂單）的一個重要條件，計劃員看到的庫存結構與經營部看到的庫存略有不同，不但提供的可用庫存的信息還提供了實際庫存和待出庫數量的信息。

庫存結構公式：實際庫存＝可用庫存＋待出庫實際庫存：倉庫里真實存在的物品數量可用庫存：能夠滿足訂單需求的物品數量待出庫：已下達訂單未進行發貨操作的余留數量事業部計劃員（分公司）庫存查詢18事業部計劃員（分公司）訂單鎖定 考慮到在分公司層面可能會出現多個計劃員審核訂單的情況，在審核訂單之前計劃員必須要對其準備審核的訂單進行鎖定，這樣就防止了多個計劃員操作同一張訂單的情況發生。 操作指引：分公司計劃員進入待處理訂單列表后選擇要處理的訂單后面的選定框進行鎖定，鎖定后進入訂單審核功能。事業部計劃員（分公司）訂單鎖定19事業部計劃員（分公司）訂單審核 分公司計劃員在做訂單審核時原則上采取見單處理的原則，即要看到經過財務簽字的傳真件，但考慮到實際情況，如果經營部需要立即審批的貨物需打電話向分公司申請后立即審核。在未到訂單處理時間點之前經營部可以取消訂單，可用庫存隨之增加。因此當查詢到的庫存數量不能滿足訂單需求時每個經營部可以在隔段時間再次查詢可用庫存是否滿足訂單需求。 分公司計劃員在系統過渡期必須見到有經營部財務簽章的打印訂單傳真件作為審核訂單的依據。對于經營部提交的訂單原則上全部通過，分公司計劃員也可根據實際情況對訂單的數量進行調整或拒絕該張訂單。為了保障經營部能夠及時準確的查詢到訂單的執行狀態，要求分公司計劃員在第一時間內進行審核操作。為保證傳真件和實際的審核數一致，當審核人員對經營部提交的訂單數要進行調整時，建議先取消整個訂單（拒絕），通知填單人員根據調整數重新填寫新的訂單，再將新訂單傳真到分公司。事業部計劃員（分公司）訂單審核20事業部計劃員（分公司）訂單沖紅審核當訂單沖紅申請被經營部提交上來后，分公司計劃員要根據實際情況進行沖紅的審核操作，沖紅的對象只限于下達訂單未做實際發貨處理的部分（只可以沖減余留數量）。訂單查詢分公司計劃員可以隨時在網上查詢訂單的狀態（已審核、安排運輸、在途、簽收），以便安排自己的工作內容。具體操作方法見用戶手冊。注：對于未審核的訂單因為會存在取消的可能性所有不作為正式訂單在訂單查詢里出現。涉及單證：訂單、訂單沖紅申請單事業部計劃員（分公司）訂單沖紅審核21沖紅申請審核簽字/蓋章3PL分公司物流部經營部接受指令執行指令訂單沖紅流程作廢NY傳真計劃員執行結果反饋沖紅結果接收傳真計劃員執行結果查詢沖紅申請審核簽字/蓋章3PL分公司物流部經營部接受指令執行指22RDC管理模塊 RDC管理模塊實現RDC的庫存數量可視化管理。它提供倉庫出入庫指令查詢，出入庫結果記錄，庫存實時查詢，以及庫存和發貨的統計和分析。 主要使用者為RDC管理員，物流經理，物流運作管理部門，管理RDC的3PL。RDC管理模塊 RDC管理模塊實現RDC的庫存數量可視化23RDC管理模塊功能計劃入庫計劃出庫非計劃入庫非計劃出庫庫存查詢出庫記錄查詢入庫記錄查詢出庫單、入庫單打印匯總報表RDC管理模塊功能計劃入庫24RDC售后貨到驗貨確定好壞機Tulip系統非計劃入庫運輸承運商RDC——入庫RDC售后貨到驗貨確定好壞機Tulip系統運輸承運商RDC—25RDC——出庫承運商RDC

裝貨開出庫單備車分公司RDC聯開送貨清單分公司承運聯RDC——出庫承運商RDC裝貨開出庫單備車分公司RDC聯開26RDC倉管員計劃入庫 與補貨計劃的接口功能非計劃入庫 非計劃入庫是為了解決在Tulip2.0系統未實施前代替流程中的部分環節所作的臨時功能。目前的倉庫入庫操作必須全部使用非計劃入庫來完成。根據不同的入庫指令倉庫管理員需要先選擇入庫類型然后才能填寫入庫單內容。RDC倉管員計劃入庫27入庫類型（補充）補貨入庫調撥入庫退換貨入庫修還入庫沖紅入庫入庫類型（補充）補貨入庫28入庫類型說明（補充）補貨入庫：對應補貨計劃進行的入庫操作，倉管員必須并填寫相應的補貨計劃號和發貨的CDC名稱后才可以進行入庫單內容的輸入。調撥入庫：跟補貨計劃相同也是為了彌補Tulip2.0為上線前的流程空缺，倉管員選擇了入庫類型為調撥入庫后，必須選擇相應的發貨倉庫的名稱和對應的調撥計劃的計劃好后才可以進行入庫單內同的輸入。退換貨入庫：當發生客戶退換貨需要進入RDC的時候，倉管員先要檢查收到的退換貨計劃的傳真件和實物是否一一對應，同時要經過售后部門對物品進行鑒定后按照好壞機區分入庫的原則進行入庫單的填寫，在原單單號欄必須填寫退換貨計劃的計劃號，以便日后查對之用。修還入庫：當需要將維修好的機器重新入庫時將使用到該類型。倉管員在做修還入庫時必須將原有的維修出庫單的單號錄入原單單號的文字欄中以便核對維修出庫領用的型號、數量是否可以和入庫的型號、數量相對應。做完入庫處理，系統會增加好機數量。沖紅入庫：該出庫類型是為了修正非計劃入庫時產生的填寫錯誤而導致庫存不準確的情況而設立的，在填寫沖紅入庫時一定要填入出錯的入庫單號作為以后核對庫存的依據。入庫類型說明（補充）補貨入庫：對應補貨計劃進行的入庫操作，倉29RDC倉管員計劃出庫 所有的訂單出庫都必須為計劃出庫，在頁面上可以看到計劃出庫的待處理數量，點擊進入后就可以看到每一條計劃出庫指令就是一張訂單，考慮到在實際發貨的時候會出現余留的現象，計劃出庫提供了分次執行出庫指令的功能，如果根據訂單所作的每一次出庫沒有完全將訂單執行完畢，系統會自動將已執行完畢的數量減去并提示需要繼續處理的信息。 操作指引：倉管員進入計劃出庫后查看相應的出庫指令，點擊進入后可以看到出庫指令的詳細內容，這時需要將出庫指令打印出來作為倉庫檢貨的信息指導，待裝完貨后，填入實際出庫的物品數量后提交生成正式的出庫單，這個功能是為了防止在實際操作中先生成出庫單后由于各種特殊情況無法完成出庫單上全部物品的出庫操作而產生的出庫單沖紅現象的發生。RDC倉管員計劃出庫30RDC倉管員非計劃出庫 非計劃出庫是為了解決在Tulip2.0系統未實施前代替流程中的部分環節所作的臨時功能。目前的倉庫出庫操作除了正常的客戶訂單使用計劃出庫外其它類型的出庫倉庫管理員均需要選擇出庫類型然后才能填寫出庫單內容。RDC倉管員非計劃出庫31非計劃出庫類型（補充）維修出庫返廠出庫調撥出庫沖紅出庫非計劃出庫類型（補充）維修出庫32非計劃出庫類型說明（補充）維修出庫：當售后服務中心需要將倉庫中的壞機進行維修領用時將使用到該類型。倉管員在做維修出庫時必須將售后服務中心開具的維修領用單的單號錄入原單單號的文字欄中以便日后同維修領用單上標注的型號、數量進行核對。做完維修出庫庫處理后，系統會減少壞機的數量。返廠出庫：該出庫類型較少使用，當倉管員接到事業部下達的返廠計劃后將使用該類型進行返廠出庫。倉管員在做返廠出庫時必須將事業部下達的返廠計劃的計劃號錄入原單單號的文字欄中以便日后進行核對。調撥出庫：同調撥入庫一樣只是功能相反，倉管員選擇了出庫類型為調撥出庫后，必須選擇相應的收貨倉庫的名稱和對應的調撥計劃的計劃好后才可以進行出庫單內容的輸入。沖紅出庫：該出庫類型是為了修正非計劃出庫時產生的填寫錯誤而導致庫存不準確的情況而設立的，在填寫沖紅出庫時一定要填入出錯的出庫單號作為以后核對庫存的依據。非計劃出庫類型說明（補充）維修出庫：當售后服務中心需要將倉庫33RDC倉管員查詢庫存庫存的查詢是倉庫管理員在進行盤點時核對倉庫實物數量和系統反映數量的一個重要依據，不但提供的可用庫存的信息還提供了實際庫存和待出庫數量的信息。庫存結構公式：實際庫存＝可用庫存＋待出庫實際庫存：倉庫里真實存在的物品數量可用庫存：能夠滿足訂單需求的物品數量待出庫：已下達訂單未進行發貨操作的余留數量。注：顯示待出庫的數量時是為了提醒倉管員還有部分物品是處于余留狀態的以便指導其工作。RDC倉管員查詢庫存34RDC倉管員查詢入庫記錄 對倉庫在任何時段進行的入庫進行查詢，此功能是為了對日常的入庫業務進行數據跟蹤而提供的，點擊進入后填好查詢條件后即可查到業務發生的原始記錄，具體操作見用戶手冊。查詢出庫記錄 功能和操作方法同查詢入庫記錄。RDC倉管員查詢入庫記錄35運輸管理模塊 運輸管理模塊實現支線的配送指令查詢和運輸結果信息的輸入和查詢，以及運輸結果的統計分析。 主要使用者：運輸承運商，物流經理，物流運作管理部門。運輸管理模塊 運輸管理模塊實現支線的配送指令查詢和運輸結36運輸管理模塊功能生成送貨清單送貨清單打印送貨清單維護生成沖紅通知單

運輸管理模塊功能生成送貨清單37運輸管理模塊功能說明生成送貨清單 根據訂單生成送貨清單：系統設計的原則是一張訂單可以對應多張送貨清單運。因此輸管理員可以根據運力情況來決定是一次還是多次執行該訂單，如果分次執行該訂單則系統會在下一次生成送貨清單時將以發運的數量減去直到完全執行完訂單的數量為止。運輸管理模塊功能說明生成送貨清單38運輸管理模塊功能說明維護送貨清單 發運工作開始后，維護送貨清單便成為訂單執行情況跟蹤的數據源車輛離開中轉倉后，中轉倉倉管員通知物流經理貨已出庫的信息。物流經理便可以在網上隨時監控訂單的執行情況。當貨物在途中時運輸管理員可以不斷的對到達時間和途中發生的情況進行修正，這些改動會立即在網上體現出來，以便物流經理可以隨時的掌握貨物的動向。貨物到達目的地后，收貨方在隨運輸人員到達的送貨清單上填寫實際收貨數量。運輸人員可以實時也可以事后將這些信息反饋給運輸管理員。運輸管理員將這些信息錄入系統后，簽收的信息隨即體現出來。運輸管理模塊功能說明維護送貨清單39運輸管理模塊功能說明生成沖紅通知單 如客戶簽收的貨物數量與送貨清單上的貨物數量不相等，系統自動顯示該頁面，讓運輸公司填寫沖紅通知單，主要用于記錄貨物運輸過程中發生貨損、貨差的狀況。 該功能是由系統自動完成的，如果客戶的簽收數量與實發數量不符，則系統認為產生了貨險，自動打開貨險沖紅功能，由運輸管理員填寫貨損原因后提交，系統自動會生成貨險沖紅掛帳單。物流經理可以通過貨險沖紅掛帳單的內容進行相應的處理。運輸管理模塊功能說明生成沖紅通知單40第二階段業務流程第二階段業務流程41第二階段業務流程補貨計劃處理流程CDC管理流程干線運輸管理流程干線運輸貨險沖紅流程RDC調撥處理流程 通用業務處理流程實現的目標是建立一套支持多元化產品及多渠道銷售的信息平臺。第二階段業務流程補貨計劃處理流程42第二階段流程設計第二階段流程設計43第二階段用戶角色定義事業部計劃員：主要負責補貨計劃、調撥計劃的編制，審核，確認物流中心計劃員：主要負責發貨指令的執行，運輸商的選擇CDC倉管員：主要負責貨物在CDC出入庫操作第三方物流(干線)：主要負責貨物的干線運輸，簽收貨險處理員：主要負責干線運輸出現貨險后的處理第二階段用戶角色定義事業部計劃員：主要負責補貨計劃、調撥計劃44補貨計劃處理流程補貨計劃處理流程45提交補貨訂單補貨訂單初稿草稿正式稿Start接收補貨訂單填寫補貨計劃銷售預測數據生成補貨計劃補貨計劃[初稿]再次調整補貨計劃[正式稿]最終審批EndCDC/RDC庫存數據調整計劃補貨計劃[草稿]物流運作部CDC/RDC事業部計劃協調員事業部計劃員分公司提交補貨訂單補貨訂單初稿草稿正式稿Start接收補貨訂單填寫46補貨計劃處理——流程描述事業部計劃員（TV、AV事業部計劃員）生成補貨計劃初稿補貨計劃的產生是由三個前因來驅動的（分公司的要貨申請、RDC庫存、總部銷售預測），事業部計劃員填寫補貨計劃提交給物流中心。（系統里要標識該補貨計劃是由分公司的要貨訂單驅動的，還是由總部自主進行補貨）補貨計劃的主要內容包括(發貨CDC名稱、收貨RDC名稱OR收貨單位的名稱、計劃內容)輸入：要貨申請、RDC庫存、銷售預測輸出：補貨計劃補貨計劃處理——流程描述事業部計劃員（TV、AV事業部計劃員47生成補貨計劃初稿（補充）制作補貨計劃參考的因素主要有以下六點： 要貨計劃、CDC庫存、RDC庫存、銷售數據、電話溝通、銷售預測補貨計劃有兩種方式：直接對分公司提交的補貨訂單進行審核后直接生成補貨計劃；由主動補貨引發的手工填寫的補貨計劃。事業部計劃員完成計劃后發到物流運作部，物流運作部根據運力情況并與事業部計劃員協商后調整發貨計劃的數量，后交由事業部計劃協調員做最終審核后下達物流運作部執行。在傳遞過程中會產生3次數值，一次是初始值，第二次是物流部修改的值，第三次是事業部最終確定的數值。總部計劃在參考CDC庫存的時候只參考這個CDC的合計庫存而不管其內部是如何分布的，因為倉庫產品類型和存貨量分布非常的不均勻。生成補貨計劃初稿（補充）制作補貨計劃參考的因素主要有以下六點48補貨計劃處理——流程描述生成正式補貨計劃 事業部計劃員收到經過物流運作部調整的后的補貨計劃，經過事業部計劃協調員的最終審核后交由物流運作部進行運作。當物流運作部開始運輸流程時計劃員可以對發貨計劃的情況進行跟蹤。輸入：經過物流運作部根據運力調整后的補貨計劃輸出：正式補貨計劃補貨計劃處理——流程描述生成正式補貨計劃49補貨計劃處理——流程描述物流中心干線計劃員調整補貨計劃 物流中心干線計劃員對各事業部計劃員提交的發貨計劃進行數量上調整后，交還給事業部計劃協調員員進行最終確認。輸入：事業部計劃員交來的補貨計劃 輸出：經過運力調整的補貨計劃補貨計劃處理——流程描述物流中心干線計劃員50補貨計劃處理——流程描述事業部計劃協調員最終審核發貨計劃 事業部計劃協調員員對發貨計劃進行最終確認。輸入：運力調整后的發貨計劃輸出：最終的發貨計劃補貨計劃處理——流程描述事業部計劃協調員51CDC管理流程CDC管理流程52開始結束是否合格取消入庫(NO)辦理入庫(Yes)辦理入庫單準備入庫入庫檢驗倉管員入庫流程開始結束是否合格取消入庫(NO)辦理入庫(Yes)辦53CDC管理流程描述——CDC管理員填寫入庫單 CDC管理員接到由工廠送來的貨物后通過隨貨物到達的批次計劃檢驗貨物，滿足入庫條件后允許入庫。同時填寫入庫單修正庫存 輸入：工廠發來的批次入庫計劃 輸出：入庫單CDC管理流程描述——CDC管理員填寫入庫單54出庫流程提貨單自提出庫結束客戶簽收送貨清單送貨清單(簽)開始接單核單按單找貨核對記帳揀貨裝車盤點余數復核放行報表處理結束庫存總帳<<報表>>配送/自提(自提)貨物出庫處理配送處理(配送)出庫單<<單據>>是否符合(Yes)等待處理(No)End發貨計劃<<單據>>CDC日庫存報表<<報表>>CDC日發貨統計<<報表>>CDC余留報表<<報表>>分公司物流部CDC倉管員3PL(配送處理)客戶方(自提處理)出庫流程提貨單自提出庫結束客戶簽收送貨清單送貨清單(簽)開始55CDC管理流程描述——CDC管理員填寫出庫單 根據計劃部門下達的補貨計劃生成出庫單，在這里要說明的是由于目前Tulip系統無法對CDC內部的物理倉庫進行管理因此制作出庫單的依據是各物理倉庫上報的內部出庫單。由于目前倉庫已經在使用K3系統，因此可以考慮Tulip系統與K3系統進行對接。 輸入：審核后的發貨計劃 輸出：出庫單CDC管理流程描述——CDC管理員填寫出庫單56干線運輸管理干線運輸管理57正式下達正式補貨訂單補貨訂單[正式]下達發貨指令選擇運輸商補貨訂單[正式]出庫準備出庫準備運輸準備運輸簽收返回簽收結果簽收情況客戶/RDC3PLCDC物流運作部事業部正式下達正式補貨訂單補貨訂單[正式]下達發貨指令選擇運輸商補58干線運輸管理流程描述物流中心干線計劃員對事業部下達的發貨指令進行承運商的分配工作根據事業部下達的發貨指令選擇運輸商，提交系統后會將各承運商所需要操作的訂單分發。由于CDC部門無法實現對具體物理庫的管理因此需要手工標注裝貨地點。輸入：發貨指令（補貨計劃、調撥計劃、返廠計劃等）輸出：標注了承運商信息的發貨指令干線運輸管理流程描述物流中心干線計劃員59干線運輸管理流程描述3PL運輸管理員根據物流運作部下達的運輸計劃生成送貨清單 根據物流部下達的運輸計劃結合自身的運輸能力一次或分次執行運輸計劃，生成一張或多張送貨清單供簽收用。 輸入：發貨指令（補貨計劃、調撥計劃、返廠計劃等） 輸出：送貨清單干線運輸管理流程描述3PL運輸管理員60對送貨清單進行跟蹤維護 送貨清單生成后交由具體運輸人員攜帶，在運輸過程中運輸管理員可以隨時通過各種方式同運輸人員進行聯系，及時了解運輸的情況并維護入送貨清單。這樣所有的人員（計劃員、物流運作人員等）可以隨時在網上關注發貨計劃的執行情況。 輸入：送貨清單 輸出：維護了過程信息的送貨清單送貨清單的簽收信息錄入 貨物到達后，收貨方進行簽收。運輸管理員可以將簽收信息維護錄入系統，以便相關人員了解貨物的簽收情況。 輸入：送貨清單 輸出：送貨清單（簽收）對送貨清單進行跟蹤維護61干線運輸貨險處理干線運輸貨險處理62貨運事故報案表運輸中出現事故Start沖紅通知單審核沖紅賬目修復貨損重新調賬貨險沖紅處理物流管理中心帳目掛帳沖紅通知單掛帳單沖紅沖紅處理根據沖紅請求生成沖紅掛帳計劃沖紅（紅單）（負數）詢問經營部或中轉倉是否需要補貨生成對應要貨計劃的補發貨計劃(Yes)結束(No)計劃沖紅（藍單）（正數）計劃員物流運作部3PL貨運事故報案表運輸中出現事故Start沖紅通知單審核沖紅賬目63干線運輸貨險處理流程描述干線運輸貨險處理員生成貨運事故處理單 由于干線運輸情況比較復雜，目前干線運輸發生事故有兩種情況和處理辦法。 輸入：貨運事故報案表（手工） 輸出：貨險沖紅單（1）貨損處理 貨損是指貨物在運輸過程中沒有太大的損壞，通過業務模式和補發物料可以解決的。 對于這部分貨物不會做沖紅處理而是通過賠付和補發物料的情況來解決。干線運輸貨險處理流程描述干線運輸貨險處理員64 （2）貨差處理 貨差是指在運輸過程中發生了比較大的事故導致貨物無法完成既定功能的。這部分的處理一定要進行沖紅處理。鑒于這兩種情況我們的建議是一旦不能部分或全部簽收，系統即生成貨運事故處理單3PL在送貨清單上標明是貨損還是貨差。 物流運作部的貨運事故處理員根據系統自動生成的貨運事故處理單和3PL提交的貨運事故報案表來進行貨損貨差的處理。 對于貨損的情況完成了賠付和補發物料的操作后點擊處理后，流程終止。而對于貨差的情況點擊沖紅按鈕系統生成貨險沖紅請求等待計劃員處理。

注：沖紅單的主要內容包括(貨運事故報案表編號、原發貨計劃號、發貨沖紅內容) （2）貨差處理65對貨險沖紅掛帳單進行處理 事業部計劃員作出發貨計劃沖紅審核后，即生成貨險沖紅掛帳單。出現貨損的貨物的所有權即轉為物流運作部，貨險處理員有義務對該掛帳單進行處理，直到發生貨險的貨物被完全完畢。 輸入：貨險沖紅掛帳單 輸出：處理過的貨險沖紅掛帳單對貨險沖紅掛帳單進行處理66事業部計劃員審核貨險沖紅申請單 事業部計劃員根據物流部上傳的貨險沖紅單進行審批，系統隨即會對要沖紅的發貨計劃進行沖紅同時會詢問是否要對收貨方繼續發貨，如果要繼續發貨則自動生成新的發貨計劃（進入新的發貨計劃處理流程），如果無需繼續發貨則不做處理。 輸入：貨險沖紅單 輸出：審核后的貨險沖紅單、新的發貨計劃（可選）生成貨險沖紅掛帳單 一旦計劃員審核了由物流運作部提交的貨險沖紅單，無論是否繼續發貨系統都會生成貨險沖紅掛帳單并將收貨方改為物流運作部。輸入：審核后的貨險沖紅單輸出：貨險沖紅掛帳單事業部計劃員67RDC調撥處理RDC調撥處理68填寫調撥計劃銷售預測數據生成調撥計劃調撥計劃[初稿]Start初稿草稿正式稿最終審批End調撥計劃[正式稿]庫存信息準備出庫庫存信息準備入庫調整計劃調撥計劃[草稿]物流運作部RDC2(調入)RDC(調出)事業部計劃協調員事業部計劃員填寫調撥計劃銷售預測數據生成調撥計劃調撥計劃[初稿]Star69RDC調撥處理流程描述事業部計劃員生成調撥計劃初稿 調撥計劃的產生是由兩個前因來驅動的（分公司的調撥申請、總部銷售預測），事業部計劃員填寫調撥計劃提交給物流中心。 注：調撥計劃的主要內容包括(調出RDC名稱、調入RDC名稱、計劃內容) 輸入：調撥申請（手工）、各RDC庫存、銷售預測 輸出：調撥計劃RDC調撥處理流程描述事業部計劃員70生成調撥計劃初稿（補充）（1）制作調撥計劃參考的因素主要有以下六點調撥申請調出RDC庫存調入RDC庫存銷售數據電話溝通銷售預測（2）事業部計劃員完成計劃后發到物流運作部，物流運作部根據運力情況并與事業部計劃員協商后調整計劃，后交由事業部計劃協調員做最終審核后下達物流運作部執行。 在傳遞過程中會產生3次數值，一次是初始值，第二次是物流部修改的值，第三次是事業部最終確定的數值。生成調撥計劃初稿（補充）（1）制作調撥計劃參考的因素主要有以71生成正式調撥計劃 事業部計劃員收到經過物流運作部調整的后的調撥計劃，經過事業部計劃協調員的最終審核后交由物流運作部進行運作。當物流運作部開始運輸流程時計劃員可以對調撥計劃的執行情況進行跟蹤。 輸入：經過物流運作部根據運力調整后的調撥計劃 輸出：正式調撥計劃生成正式調撥計劃72RDC調撥處理流程描述物流中心干線計劃員調整調撥計劃 物流中心干線計劃員對各事業部計劃員提交的調撥計劃進行調整后，交還給事業部計劃協調員員進行最終確認。 輸入：事業部計劃員交來的調撥計劃 輸出：經過運力調整的調撥計劃RDC調撥處理流程描述物流中心干線計劃員73RDC調撥處理流程描述事業部計劃協調員最終審核調撥計劃 事業部計劃協調員員對調撥計劃進行最終確認。 輸入：運力調整后的調撥計劃 輸出：最終的調撥計劃RDC調撥處理流程描述事業部計劃協調員74物流管理系統軟件架構物流管理系統軟件架構75TULIP系統的軟件架構業務模型設計思路設計模式實現架構TULIP系統的軟件架構業務模型76軟件架構-業務模型RDC1CDC2RDC2DC1分公司1事業部1訂單補貨調拔經營部2經營部3補貨補貨調拔經營部1DC2管理客戶客戶客戶客戶客戶CDC1調拔調拔補貨下訂單。每個客戶有且只有一個為之服務的xDC.。經營部通過客戶來決定可以查看的xDC庫存.。分公司可以管理多個xDC補貨訂單軟件架構-業務模型RDC1CDC2RDC2DC1分公司1事業77工廠CDCRDCDC客戶。工廠到CDC。工廠到RDC。工廠到DC。工廠到客戶。CDC到RDC。CDC到DC。CDC到客戶。RDC到DC。RDC到RDC。RDC到客戶。DC到客戶物流網絡模型工廠CDCRDCDC客戶。工廠到CDC物流網絡模型78下單機構審單機構總部分公司事業部經營部分公司產品部大客戶分公司CDCRDCDC工廠CDCRDC客戶CDC。客戶在一個DC的服務范圍內。客戶屬于某個下單機構。下單機構通過客戶來決定可以查看哪個DC的庫存。下單機構隸屬于某個審單機構。審單機構可以管理多個DC。該審單機構下所有下單機構的所有客戶的隸屬DC都在該審單機構的管理之下。客戶客戶物流與商流下單機構審單機構總部分公司經營部CDCRDCDC工廠CDCR79軟件架構-設計原則系統之間的低耦合降低系統的耦合度，盡量使每個業務單位的子系統都可以獨立運行。減少各系統間的依賴關系。系統的擴展與可配置注重對接口的設計，增強與其它系統的數據交換能力。面向對象的分析與設計應用面向對象的分析與設計技術，采用原型法來進行系統開發。軟件架構-設計原則系統之間的低耦合80軟件架構-設計原則小結：TULIP系統的重點并非提供一個在每個業務環節都非常完整及完美的軟件系統，而是為了實現對訂單的實時跟蹤，統一管理以及對整個銷售網絡中庫存的實時監控，及時準確地反映業務數據，以整合規范業務流程為主要目的的IT系統。因此，要求TULIP系統中的每個子系統均以低耦合度相連，將來被其它系統所代替時，不會影響業務流程的完整性。軟件架構-設計原則小結：TULIP系統的重點并非提供一個在每81軟件架構-設計模式代理關系機制應用代理技術來實現系統中某些業務對象之間的業務關系。使重組或更改業務關系變得更容易。設計模式應用Factory,Agent,Singleton,Handler,Controller等設計模式，保持代碼的清析與易懂。例如：publicclassOrderManagerFactory{privatestaticOrderManagerivOrderManager;publicOrderManagerFactory(){}publicOrderManagergetManagerBy(Stringmanager){return(newOrderDefaultManager());}publicstaticOrderManagergetDefaultFactory(){if(ivOrderManager==null)ivOrderManager=newOrderDefaultManager();returnivOrderManager;}}軟件架構-設計模式代理關系機制82軟件架構訂單倉儲運輸報表系統管理(產品,客戶,機構,用戶等)系統接口JavaPlatform其它系統CRMJXCDBReport軟件架構訂單倉儲運輸報表系統管理(產品,客戶,機構,用戶等)83軟件架構ManagerBOBCHandlerDBJSPBO=BusinessObjectBC=BusinessObjectController從JSP客戶端發出的每次請求，經過SessionManager的處理后，根據不同的Command分發給不同Handler來處理，Handler然后調用相應的Manager來處理業務邏輯，最后由Controller來完成對數據庫的操作。SessionManager軟件架構ManagerBOBCHandlerDBJSPBO=84TULIP系統的數據庫設計主要數據模型訂單處理入庫出庫運輸與貨險機構管理用戶及權限代理關系產品管理TULIP系統的數據庫設計主要數據模型85數據庫設計主要數據模型TULIP系統中的主要數據模型為訂單，出庫單，入庫單，沖紅單，送貨清單，掛帳單，庫存，產品，機構等之間的關系模型，而且也主要以處理以上幾種業務對象的關系為主。數據庫設計主要數據模型86數據庫設計－訂單數據庫設計－訂單87數據庫設計－庫存數據庫設計－庫存88數據庫設計－運輸數據庫設計－運輸89數據庫設計－機構數據庫設計－機構90用戶機構權限用戶產品線機構客戶1.用戶的產品線權限:同一機構下不同的操作用戶具有不同的產品權限.2.用戶的機構權限:對于審核訂單角色來說,同一機構下的不同審單角色可以審核不同機構的訂單.而且只能是該用戶有產品權限的訂單.3.客戶權限:對于下訂單角色來說,同一機構下的不同下單角色可以為不同的客戶下單,機構產品線機構的產品權限:指該機構所具有的產品權限,如果有該產品的權限,則意味著可以查詢與該產品相關的在該機構的職責范圍內的數據用戶機構權限用戶產品線機構客戶1.用戶的產品線權限:機構產品91OrganizationCustomerCustomerGroupUserRoleUserRoleUserPrivilegeProductUserPrivileges:PRIV_TYPEPRIV_VALUE-----------------------------------------------------ProductProductGroupID(defaultvalueis'ALL')CustomerCustomerGroupID(defaultvalueis'ALL')OrganizationOrganizationID(defaultvalueisnull用戶機構權限OrganizationCustomerCustomerGr92數據庫設計－用戶及權限數據庫設計－用戶及權限93數據庫設計－代理關系OrganizationTypeProductAgentJNJN005TVJN0000JN00005TVHZTV00JN00005AVHZAV00JN00005BDHZBD00JN00003TVJNRDCJN00003BDJNRDC。。。。。。。。。。BusinessAgent數據庫設計－代理關系OrganizationTypeProd94物理倉庫邏輯倉庫經營部客戶分公司事業部3PLTULIP的倉庫模型物理倉庫邏輯倉庫經營部分公司事業部3PLTULIP的倉庫模型95大客戶經營部大客戶物理庫庫存帳本/邏輯庫物理庫采用劃分邏輯庫的方法來實現庫存隔離。即在該庫內專門為某個機構設立庫存帳本用來記錄專屬于該機構的庫存。當需要為某個客戶建立隱含庫存時，先通過系統管理員在機構管理中為該倉庫創建一個屬于該客戶的“帳本”即可。理論上系統可以為每一個客戶建立一套自已的帳本。庫存帳本/邏輯庫庫存帳本/邏輯庫某客戶能看的庫存：＝倉庫的公有庫存＋屬于該客戶的私有庫存PublicPrivate1Private2xDCStockReserve大客戶經營部大客戶物理庫庫存帳本/邏輯庫物理庫采用劃分邏輯庫96數據庫設計－產品管理數據庫設計－產品管理97TULIP系統的安全性考慮系統的安全是綜合性的，它包含了訪問控制，數據加密，傳輸控制，運行安全等多種因素。TULIP系統做為一個業務系統，其安全問題當然是至關重要的，但就安全性來說TULIP系統重點在于對非授權訪問的控制，也就是說要保證用戶訪問的安全性，對于其它的安全性因素應由不同的軟硬件系統來完成。例如：數據傳輸的安全性，可由SSL來實現，WebLogic完全支持該技術。運行的安全性，可由提供備份服務器，備份數據等方式完成。TULIP系統的安全性考慮系統的安全是綜合性的，它包含了訪問98報表系統報表系統99報表系統的設計TULIP報表工具管理層數據報表報表工具完成的功能:后端:1.報表定義2.報表數據定義2.報表格式定義前端:3.顯示報表4.打印報表5.導出報表數據抽取數據抽取其它系統報表系統的設計TULIP報表工具管理層數據報表報表工具完成的100報表系統業務需求時間(年，月，日)貨物數量(計劃數，在途數，實際數，簽收數，余留數)區域(經營部，分公司，倉庫，事業部)(發站，到站)報表系統業務需求時間(年，月，日)貨物數量(計劃數，在途數101五個關鍵數據：計劃數，實際數，余留數，在途數，簽收數。七個統計要素：時間段（年月日），發貨、到貨地點，產品類別，運輸方式（公路，鐵路等），承運單位運作方式（干線，配送，自提等），訂單號。

所有倉庫的進、出、存都圍繞"計劃、實際、余留、在途、簽收"五個要素進行統計，生成各種相關報表。五個關鍵數據：計劃數，實際數，余留數，在途數，簽收數。102重點名詞解釋和約束干線運輸：干線運輸包括CDC－RDC的配送和CDC－客戶/經營部的配送二次配送：二次配送包括RDC－RDC的配送和RDC－客戶/經營部的配送RDC：地域配送中心，目前由分公司管轄，下屬可以設立多個DCCDC：全國配送中心，負責向所有的RDC供貨，目前由總部統一管轄標準車體積：作為基準車型的體積，目前以7.2m為標準車體積，要求在系統管理中可以自定義何種車型為標準車型。重點名詞解釋和約束干線運輸：干線運輸包括CDC－RDC的配103報表統計要素時間段（以天為分割的時間點要求在系統管理中可以設置）事業部（TV事業部、AV事業部、白家電事業部、空調事業部、彩顯事業部、PHILIPS銷售中心等）產品類別（彩電、TV附件、視盤機、功放、音箱、冰箱、洗衣機、空調整機、空調樣機、空調附件等）發站（CDC、RDC、DC名稱）到站（按區域、省份、分公司、經營部（銷售部）、客戶等）3PL（安得、寶供、南方、中外運等，可自行維護）運輸方式（汽車、火車、飛機、輪船等，可自行維護） 先選擇運輸工具——再選整車或零擔方式——最后選整車的規格（例如選輪船——整集裝箱或零擔——集裝箱規格）承運方式（自提、配送）發運方式（CDC至RDC、CDC至客戶等，可自行維護）區分訂單（計劃）的緊急程度。按響應時間（如4小時、8小時、12小時等）分A類、B類、C類等訂單，具體分類標準可按實際需要進行維護調整。

該處需要描述清楚運輸方式的選擇在什么地方來操作報表統計要素時間段（以天為分割的時間點要求在系統管理中可以104費用核算干線、配送運輸費用統計數據來源——倉庫實際發運數量統計口徑——按報表查詢口徑查詢（十種）費用報表匯總（1）按物流供應商分發站匯總 匯總表的兩個匯總條件：條件1－按物流供應商的名稱進行費用匯總，此時不考慮發貨站和到貨站的匯總條件，條件2－按發貨站和到貨站進行匯總此時不考慮物流供應商名稱的匯總條件（2）按事業部分發站匯總 匯總表的兩個匯總條件：條件1－按事業部的名稱進行費用匯總，此時不考慮發貨站和到貨站的匯總條件，條件2－按發貨站和到貨站進行匯總此時不考慮事業部名稱的匯總條件費用核算干線、配送運輸費用統計105計費方法（1）按臺價計費 單臺價=點到點標準車型運價/標準車型滿載量×（標準車型與實際車型差值比率）（或按不同產品類別段確定費用，如21、25、29、34、38等分別對應一個價格） 運費=單臺價×發運數量標準車型是指以何種車型來作為滿載量的計算標準（目前以7.2米車為基準）計費方法106（2）按標準車計費（可同時確定幾種基準車型，如7.2m車、14m車） 運費=標準車車價×發運車數（3）按體積計費 運費=單位體積運價×發運體積（4）按貨值計費 運費=貨值費率×發運貨值（貨值費率隨產品類別、發站、到站區域等的不同而不同）（5）按重量計費 運費=元/Kg（按不同距離給予定義）×發運重量提供重量費率(維護界面) 要求上述計費方式可按不同起運量進行費用標準的維護和統計。

（需要提供貨值費率表、需要提供重量費率表）（2）按標準車計費（可同時確定幾種基準車型，如7.2m車、1107費用核算倉租費 倉租費可以按流通量計費，也可以按租用面積計費。 ——倉租費=元/㎡×租用面積×租用天數（月租是按自然天結算） ——倉租費=元/臺×平均庫存數量（或流通量）×存放天數(平均庫存量=上月庫存總和/自然月天數,流通量=（上月出+入庫數量）/2)裝卸費 裝卸費=元/臺×（入庫數量+出庫數量）費用核算倉租費108物流系統考核指標計劃執行率 計劃執行率=已執行計劃量/計劃總量（按臺） 已執行計劃量是指計劃已經審核并且已經產生出庫單并且已經產生送貨清單的數量，余留數量不記入已執行計劃量。①已出庫、已送貨——視為計劃執行；②已出庫、未送貨——視為計劃余留，不計入計劃執行；③未出庫、已送貨——視為計劃未執行，不計入計劃執行。完好交貨率 完好交貨率=（已簽收數量）/實際送貨清單總量準點交貨率 準點交貨率=實際簽收數量（包括完好和貨損，不包括丟失）/送貨清單物品總數量物流系統考核指標計劃執行率109物流成本分析干線運輸數據分析RDC數據分析CDC數據分析二次配送數據分析物流成本分析干線運輸數據分析110干線運輸數據分析主要統計指標 有實際發運臺數、實際發運體積、發運總運距（發運體積×里程）、發運總貨值、實際發運總費用、發運車數（可折合成7.2米車，可自定義）。 (發運數量全部按送貨清單的生成數量作為基準)干線運輸數據分析主要統計指標111主要分析指標各發站發運量（按臺、按體積）比率；各發站對應各到站發運量比率（基數為總數量或各發站數量）；各發RDC與直發客戶的比率；發運體積比率（與發運數量比率雷同）；平均單臺體積（總體積/總發運量，分發站、分產品類別）；平均單臺貨值；平均體積貨值；臺費率；體積費率；貨值費率；臺公里費率；體積公里費率；車公里費率。主要分析指標112RDC數據分析主要統計指標 計劃出入庫數、實際出入庫數、流通量、計劃月初月末庫存數、實際月初月末庫存數、平均庫存量、租用面積、庫存周轉天數、倉租費、裝卸費、二次配送費等RDC數據分析主要統計指標113主要分析指標倉庫利用率單位面積倉租費率單次臺裝卸費率臺費率（庫存臺倉租費率<流通臺倉租費率、流通臺裝卸費率>）體積費率（庫存體積倉租費率<流通體積倉租費率、流通體積裝卸費率>）貨值費率（庫存貨值倉租費率<流通貨值倉租費率、流通貨值裝卸費率>）主要分析指標114CDC數據分析主要統計指標 計劃出入庫數、實際出入庫數、流通量、計劃月初月末庫存數、實際月初月末庫存數、平均庫存量、租用面積、庫存周轉天數、倉租費、裝卸費、二次配送費等CDC數據分析主要統計指標115主要分析指標倉庫利用率單位面積倉租費率單次臺裝卸費率臺費率（庫存臺倉租費率<流通臺倉租費率、流通臺裝卸費率>）體積費率（庫存體積倉租費率<流通體積倉租費率、流通體積裝卸費率>）貨值費率（庫存貨值倉租費率<流通貨值倉租費率、流通貨值裝卸費率>）主要分析指標116二次配送數據分析主要統計指標 配送（發運）臺數（分自提、配送）、體積數（分自提、配送）、配送距離、配送費用等。二次配送數據分析主要統計指標117主要分析指標配送、自提比率（分臺、體積）配送量運費率（配送臺運費率、配送體積運費率、配送貨值運費率、配送車運費率）出庫量運費率（出庫臺運費率、出庫體積運費率、出庫車運費率、出庫貨值運費率）單位距離費率

主要分析指標11811企業物流管理信息系統課件119企業物流管理信息系統1、企業基本資料2、系統目標3、需求分析4、重要流程5、重要功能企業物流管理信息系統1、企業基本資料1201、企業基本資料生產——銷售型的集團企業生產分布在全國的多個地區在全國建立有比較完善的銷售體系，銷售人員占整個企業的比例較大銷售體系中可以代銷其他企業的同類商品產品包括：家電類、計算機等信息產品1、企業基本資料生產——銷售型的集團企業1211、企業基本資料家電生產企業網絡產品生產企業通信類產品生產企業銷售公司計算機生產企業集團公司產品生產隸屬關系產品銷售隸屬關系1、企業基本資料家電生產企業網絡產品生產企業通信類產品生產企122家電網絡產品通信產品銷售公司計算機區域銷售分公司直屬銷售分公司………省級銷售公司省級銷售公司……經營部倉庫倉庫經營部經營部倉庫倉庫經營部…………區域銷售分公司：華北、東北、華中、 華東、西北、西南、 華南直屬銷售分公司：廣東、山東、新疆、 四川、海南、江西、 廣西家電網絡產品通信產品銷售公司計算機區域銷售分公司直屬銷售分公1231、企業基本資料存在問題：一種典型的“垂直型”的銷售架構各個分公司、直屬公司之間的銷售貨物不能互相補充倉庫的產品調配只能由上級公司負責各個倉庫之間不存在聯系商品的供應、沖紅、退貨由上級公司負責1、企業基本資料存在問題：124經營部事業部銷售中心客戶分公司銷售公司總部分公司產品部集團機構模式下單機構審單機構總部客戶分公司事業部經營部分公司產品部大客戶分公司TULIP機構模式機構模式經營部事業部銷售中心客戶分公司銷售公司總部分公司產品部集團機125需求分析 TULIP由執行和計劃兩大系統組成。

TULIP執行系統實現了分銷物流流程中的流程閉環處理以及運作數據的采集，統計，和可視化； TULIP計劃系統將管理和支持網絡整體庫存的優化工作。需求分析 TULIP由執行和計劃兩大系統組成。126需求分析第一階段經營部在網上按照發貨要求（自提或配送）填寫要貨訂單經營部在網上填寫沖紅申請單事業部計劃員根據業務情況審核經營部提交的訂單事業部計劃員審核經營部提交的沖紅訂單RDC管理員根據收發貨指令進行倉庫作業運輸管理員根據訂單指令進行運輸作業。需求分析第一階段127需求分析第二階段CDC庫存管理補貨計劃管理RDC調撥計劃管理干線運輸管理 在第一階段基礎上提出一個流程優化，支持多產品，計劃信息平臺解決方案需求分析第二階段128第一階段流程第一階段流程129訂單處理流程 訂單管理模塊實現客戶訂單的輸入，提交；訂單接收方的審核，訂單執行；訂單運作信息的實時查詢；訂單沖紅的輸入，審核和實現；以及訂單狀態的實時查詢。訂單管理模塊完成訂單從產生到簽收完畢之間的完整閉環的信息處理。主要使用者為經營部和事業部（分公司）的計劃員。訂單處理流程 訂單管理模塊實現客戶訂單的輸入，提交；訂單接130訂單處理模塊功能新建訂單修改訂單取消訂單訂單沖紅訂單鎖定計劃員審批訂單訂單查詢訂單打印訂單處理模塊功能新建訂單131打印財務簽字審核審核打印聯單客戶RDC分公司物流部（事業部）經營部客戶出庫操作接收到貨信息驗貨簽收作廢要貨申請傳真YNYN承運商財務開單簽字確認RDC聯運輸操作配送聯錄入Tulip打印財務簽字審核審核打印聯單客戶RDC分公司物流部（事業部）132經營部計劃員庫存查詢庫存的查詢是經營部計劃員作為填寫訂單的一個重要條件，系統可以提供經營部計劃員隨時在網上查詢庫存情況，其中庫存分為兩大類型（１）正常品和（２）殘次品。正常品是指能夠下達訂單要貨的物品。殘次品是指未經過修復不能直接下達訂單要貨的物品。經營部計劃員庫存查詢133經營部計劃員填寫訂單經營部計劃員直接從客戶或通過業務員收集和匯總客戶訂貨信息,經財務審核后，如果庫存滿足訂單需求,就開始填寫訂單。由于所填寫的訂單中的要貨信息是經過經營部財務審核后的，所以被視為有效，合法的訂單，在訂單提交并審核后后不得隨意提出沖紅請求，此項可以視為經營部的考核標準之一。為了配合物流改革的模式，經營部填寫完訂單提交之后，系統會檢查該張訂單是客戶訂單還是經營部自己的訂單，如果是客戶訂單，系統可用庫存隨之減少。如果是經營部自己的訂單，系統本著客戶訂單優先要貨、盡量減少經營部要貨的原則，不會根據訂單的數量來刪減可用庫存，直到事業部計劃員審核該張訂單后庫存才會減少。在系統未完全取代手工操作之前，經營部計劃員要將訂單打印出來交經營部財務簽字確認后將該訂單傳真至分公司等待審核（待到運行穩定后將取消傳真的操作，訂單轉為完全電子化）以保持訂單的嚴謹性.這時經營部計劃員要及時登錄到系統查看訂單的狀態，當發現提交的訂單分公司已審核，經營部財務要依此訂單在財務系統上開單。輸入：要貨信息輸出：訂單經營部計劃員填寫訂單134經營部計劃員查詢訂單 經營部計劃員或業務員可以隨時在網上查詢訂單的狀態（未審核、已審核、安排運輸、在途、簽收）。取消訂單 當經營部計劃員需要取消所下的訂單時首先在網上查詢訂單的狀態，如果該訂單未被審核系統允許取消訂單，可用庫存量隨之增加。如果該訂單已經被審核則無法進行取消操作，而要進行沖紅處理。訂單沖紅 當訂單被事業部計劃員審核之后，經營部如果有訂單變更或取消的業務需求時要進行沖紅操作。事業部計劃員會酌情進行部分沖紅或全部沖紅的審核工作，具體要求參考事業部計劃員沖紅審核（分公司）。打印訂單經營部計劃員查詢訂單135經營部計劃員客戶管理 經營部可以自主管理屬下的客戶，在新建訂單時需要的客戶信息全部在該功能中提前輸入，為了保證歷史數據的一致性，所有錄入的客戶資料系統不提供刪除功能，對于需要刪除該客戶的要求系統提供停用該用戶的功能，一旦該用戶被停用在新建訂單時，客戶列表不會出現該客戶名稱，如果情況發生變化該客戶又開始參與業務活動，經營部計劃員只需要將該用戶重新啟用即可。經營部計劃員客戶管理136事業部計劃員（分公司）庫存查詢 庫存的查詢是事業部計劃員（分公司）作為審核經營部訂單（客戶和經營部自己的訂單）的一個重要條件，計劃員看到的庫存結構與經營部看到的庫存略有不同，不但提供的可用庫存的信息還提供了實際庫存和待出庫數量的信息。

庫存結構公式：實際庫存＝可用庫存＋待出庫實際庫存：倉庫里真實存在的物品數量可用庫存：能夠滿足訂單需求的物品數量待出庫：已下達訂單未進行發貨操作的余留數量事業部計劃員（分公司）庫存查詢137事業部計劃員（分公司）訂單鎖定 考慮到在分公司層面可能會出現多個計劃員審核訂單的情況，在審核訂單之前計劃員必須要對其準備審核的訂單進行鎖定，這樣就防止了多個計劃員操作同一張訂單的情況發生。 操作指引：分公司計劃員進入待處理訂單列表后選擇要處理的訂單后面的選定框進行鎖定，鎖定后進入訂單審核功能。事業部計劃員（分公司）訂單鎖定138事業部計劃員（分公司）訂單審核 分公司計劃員在做訂單審核時原則上采取見單處理的原則，即要看到經過財務簽字的傳真件，但考慮到實際情況，如果經營部需要立即審批的貨物需打電話向分公司申請后立即審核。在未到訂單處理時間點之前經營部可以取消訂單，可用庫存隨之增加。因此當查詢到的庫存數量不能滿足訂單需求時每個經營部可以在隔段時間再次查詢可用庫存是否滿足訂單需求。 分公司計劃員在系統過渡期必須見到有經營部財務簽章的打印訂單傳真件作為審核訂單的依據。對于經營部提交的訂單原則上全部通過，分公司計劃員也可根據實際情況對訂單的數量進行調整或拒絕該張訂單。為了保障經營部能夠及時準確的查詢到訂單的執行狀態，要求分公司計劃員在第一時間內進行審核操作。為保證傳真件和實際的審核數一致，當審核人員對經營部提交的訂單數要進行調整時，建議先取消整個訂單（拒絕），通知填單人員根據調整數重新填寫新的訂單，再將新訂單傳真到分公司。事業部計劃員（分公司）訂單審核139事業部計劃員（分公司）訂單沖紅審核當訂單沖紅申請被經營部提交上來后，分公司計劃員要根據實際情況進行沖紅的審核操作，沖紅的對象只限于下達訂單未做實際發貨處理的部分（只可以沖減余留數量）。訂單查詢分公司計劃員可以隨時在網上查詢訂單的狀態（已審核、安排運輸、在途、簽收），以便安排自己的工作內容。具體操作方法見用戶手冊。注：對于未審核的訂單因為會存在取消的可能性所有不作為正式訂單在訂單查詢里出現。涉及單證：訂單、訂單沖紅申請單事業部計劃員（分公司）訂單沖紅審核140沖紅申請審核簽字/蓋章3PL分公司物流部經營部接受指令執行指令訂單沖紅流程作廢NY傳真計劃員執行結果反饋沖紅結果接收傳真計劃員執行結果查詢沖紅申請審核簽字/蓋章3PL分公司物流部經營部接受指令執行指141RDC管理模塊 RDC管理模塊實現RDC的庫存數量可視化管理。它提供倉庫出入庫指令查詢，出入庫結果記錄，庫存實時查詢，以及庫存和發貨的統計和分析。 主要使用者為RDC管理員，物流經理，物流運作管理部門，管理RDC的3PL。RDC管理模塊 RDC管理模塊實現RDC的庫存數量可視化142RDC管理模塊功能計劃入庫計劃出庫非計劃入庫非計劃出庫庫存查詢出庫記錄查詢入庫記錄查詢出庫單、入庫單打印匯總報表RDC管理模塊功能計劃入庫143RDC售后貨到驗貨確定好壞機Tulip系統非計劃入庫運輸承運商RDC——入庫RDC售后貨到驗貨確定好壞機Tulip系統運輸承運商RDC—144RDC——出庫承運商RDC

裝貨開出庫單備車分公司RDC聯開送貨清單分公司承運聯RDC——出庫承運商RDC裝貨開出庫單備車分公司RDC聯開145RDC倉管員計劃入庫 與補貨計劃的接口功能非計劃入庫 非計劃入庫是為了解決在Tulip2.0系統未實施前代替流程中的部分環節所作的臨時功能。目前的倉庫入庫操作必須全部使用非計劃入庫來完成。根據不同的入庫指令倉庫管理員需要先選擇入庫類型然后才能填寫入庫單內容。RDC倉管員計劃入庫146入庫類型（補充）補貨入庫調撥入庫退換貨入庫修還入庫沖紅入庫入庫類型（補充）補貨入庫147入庫類型說明（補充）補貨入庫：對應補貨計劃進行的入庫操作，倉管員必須并填寫相應的補貨計劃號和發貨的CDC名稱后才可以進行入庫單內容的輸入。調撥入庫：跟補貨計劃相同也是為了彌補Tulip2.0為上線前的流程空缺，倉管員選擇了入庫類型為調撥入庫后，必須選擇相應的發貨倉庫的名稱和對應的調撥計劃的計劃好后才可以進行入庫單內同的輸入。退換貨入庫：當發生客戶退換貨需要進入RDC的時候，倉管員先要檢查收到的退換貨計劃的傳真件和實物是否一一對應，同時要經過售后部門對物品進行鑒定后按照好壞機區分入庫的原則進行入庫單的填寫，在原單單號欄必須填寫退換貨計劃的計劃號，以便日后查對之用。修還入庫：當需要將維修好的機器重新入庫時將使用到該類型。倉管員在做修還入庫時必須將原有的維修出庫單的單號錄入原單單號的文字欄中以便核對維修出庫領用的型號、數量是否可以和入庫的型號、數量相對應。做完入庫處理，系統會增加好機數量。沖紅入庫：該出庫類型是為了修正非計劃入庫時產生的填寫錯誤而導致庫存不準確的情況而設立的，在填寫沖紅入庫時一定要填入出錯的入庫單號作為以后核對庫存的依據。入庫類型說明（補充）補貨入庫：對應補貨計劃進行的入庫操作，倉148RDC倉管員計劃出庫 所有的訂單出庫都必須為計劃出庫，在頁面上可以看到計劃出庫的待處理數量，點擊進入后就可以看到每一條計劃出庫指令就是一張訂單，考慮到在實際發貨的時候會出現余留的現象，計劃出庫提供了分次執行出庫指令的功能，如果根據訂單所作的每一次出庫沒有完全將訂單執行完畢，系統會自動將已執行完畢的數量減去并提示需要繼續處理的信息。 操作指引：倉管員進入計劃出庫后查看相應的出庫指令，點擊進入后可以看到出庫指令的詳細內容，這時需要將出庫指令打印出來作為倉庫檢貨的信息指導，待裝完貨后，填入實際出庫的物品數量后提交生成正式的出庫單，這個功能是為了防止在實際操作中先生成出庫單后由于各種特殊情況無法完成出庫單上全部物品的出庫操作而產生的出庫單沖紅現象的發生。RDC倉管員計劃出庫149RDC倉管員非計劃出庫 非計劃出庫是為了解決在Tulip2.0系統未實施前代替流程中的部分環節所作的臨時功能。目前的倉庫出庫操作除了正常的客戶訂單使用計劃出庫外其它類型的出庫倉庫管理員均需要選擇出庫類型然后才能填寫出庫單內容。RDC倉管員非計劃出庫150非計劃出庫類型（補充）維修出庫返廠出庫調撥出庫沖紅出庫非計劃出庫類型（補充）維修出庫151非計劃出庫類型說明（補充）維修出庫：當售后服務中心需要將倉庫中的壞機進行維修領用時將使用到該類型。倉管員在做維修出庫時必須將售后服務中心開具的維修領用單的單號錄入原單單號的文字欄中以便日后同維修領用單上標注的型號、數量進行核對。做完維修出庫庫處理后，系統會減少壞機的數量。返廠出庫：該出庫類型較少使用，當倉管員接到事業部下達的返廠計劃后將使用該類型進行返廠出庫。倉管員在做返廠出庫時必須將事業部下達的返廠計劃的計劃號錄入原單單號的文字欄中以便日后進行核對。調撥出庫：同調撥入庫一樣只是功能相反，倉管員選擇了出庫類型為調撥出庫后，必須選擇相應的收貨倉庫的名稱和對應的調撥計劃的計劃好后才可以進行出庫單內容的輸入。沖紅出庫：該出庫類型是為了修正非計劃出庫時產生的填寫錯誤而導致庫存不準確的情況而設立的，在填寫沖紅出庫時一定要填入出錯的出庫單號作為以后核對庫存的依據。非計劃出庫類型說明（補充）維修出庫：當售后服務中心需要將倉庫152RDC倉管員查詢庫存庫存的查詢是倉庫管理員在進行盤點時核對倉庫實物數量和系統反映數量的一個重要依據，不但提供的可用庫存的信息還提供了實際庫存和待出庫數量的信息。庫存結構公式：實際庫存＝可用庫存＋待出庫實際庫存：倉庫里真實存在的物品數量可用庫存：能夠滿足訂單需求的物品數量待出庫：已下達訂單未進行發貨操作的余留數量。注：顯示待出庫的數量時是為了提醒倉管員還有部分物品是處于余留狀態的以便指導其工作。RDC倉管員查詢庫存153RDC倉管員查詢入庫記錄 對倉庫在任何時段進行的入庫進行查詢，此功能是為了對日常的入庫業務進行數據跟蹤而提供的，點擊進入后填好查詢條件后即可查到業務發生的原始記錄，具體操作見用戶手冊。查詢出庫記錄 功能和操作方法同查詢入庫記錄。RDC倉管員查詢入庫記錄154運輸管理模塊 運輸管理模塊實現支線的配送指令查詢和運輸結果信息的輸入和查詢，以及運輸結果的統計分析。 主要使用者：運輸承運商，物流經理，物流運作管理部門。運輸管理模塊 運輸管理模塊實現支線的配送指令查詢和運輸結155運輸管理模塊功能生成送貨清單送貨清單打印送貨清單維護生成沖紅通知單

運輸管理模塊功能生成送貨清單156運輸管理模塊功能說明生成送貨清單 根據訂單生成送貨清單：系統設計的原則是一張訂單可以對應多張送貨清單運。因此輸管理員可以根據運力情況來決定是一次還是多次執行該訂單，如果分次執行該訂單則系統會在下一次生成送貨清單時將以發運的數量減去直到完全執行完訂單的數量為止。運輸管理模塊功能說明生成送貨清單157運輸管理模塊功能說明維護送貨清單 發運工作開始后，維護送貨清單便成為訂單執行情況跟蹤的數據源車輛離開中轉倉后，中轉倉倉管員通知物流經理貨已出庫的信息。物流經理便可以在網上隨時監控訂單的執行情況。當貨物在途中時運輸管理員可以不斷的對到達時間和途中發生的情況進行修正，這些改動會立即在網上體現出來，以便物流經理可以隨時的掌握貨物的動向。貨物到達目的地后，收貨方在隨運輸人員到達的送貨清單上填寫實際收貨數量。運輸人員可以實時也可以事后將這些信息反饋給運輸管理員。運輸管理員將這些信息錄入系統后，簽收的信息隨即體現出來。運輸管理模塊功能說明維護送貨清單158運輸管理模塊功能說明生成沖紅通知單 如客戶簽收的貨物數量與送貨清單上的貨物數量不相等，系統自動顯示該頁面，讓運輸公司填寫沖紅通知單，主要用于記錄貨物運輸過程中發生貨損、貨差的狀況。 該功能是由系統自