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

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

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

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

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

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

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

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

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

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

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

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

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

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