【文章內容簡介】 內容：商 品號，名稱，規(guī)格，需求時間等。接受庫存部門的請購信息，供主管審批時參照使用。審批結束后對請購單按是否批準作分類記錄。 2. 采購訂單管理：根據(jù)審批通過的請購單，生成采購訂單，除了請購的基本內容外還包括供應商，運輸方式，付款方式，付款條件，交貨日期等詳細情況。按不同的狀態(tài)實現(xiàn)訂購單的新建、修改、撤銷功能。具體地說，未執(zhí)行狀態(tài)下才能夠新建，撤消訂購單，執(zhí)行中狀態(tài)下才能修改和撤銷，訂購單一旦完成，就不允許修改和撤銷。另外也對訂購單按狀態(tài)分類列表記錄。 3. 采購合同管理： （ 1） 一份采購定單生成后對應生成采購合同（采用合同號和訂購單號對應） ； （ 2） 對撤銷，執(zhí)行中，已執(zhí)行的合同分類列表記錄，并且合同狀態(tài)和采購訂單狀態(tài)有效關聯(lián)：一份合同生成后，合同和對應的采購訂單自動進入執(zhí)行狀態(tài)；一份合同完成后， 對應的采購訂單也自動進入完成狀態(tài)； （ 3） 按供應商名稱和商品名稱提供供應商供貨記錄查詢列表；按商品名稱、供應商名稱和合同執(zhí)行時間提供進貨數(shù)量統(tǒng)計 ； （ 4） 按照合同的付款信息，及時向財務部門反饋用款信息，經批準后更新部門可用資金數(shù)目。合同完成后，為庫存提供到貨信息（名稱，數(shù)量等）。 系統(tǒng)只是超市管理信息系統(tǒng)的一個子系統(tǒng)。所以還需 考慮 與其他子系統(tǒng)之間的 聯(lián)系，從庫存獲取商品數(shù)據(jù)，從供應商管理獲取供應商信息，采購任務完成后需生成入庫單傳給庫存管理系統(tǒng)等。還有財務款項的進出與財會子系統(tǒng)有關。所以系統(tǒng)設計需有倉庫和財務的界面（接口） 。 系統(tǒng)業(yè)務流程圖 若商品缺貨或對某商品有需求，就由庫存部門生成請購單，主管部門結合銷售計劃和財務狀況及前期合同 系統(tǒng)分析 執(zhí)行情況來進行審核，并將未批準的請購單退給庫存部門；采購部門根據(jù)審批通過的請購單生成采購訂單發(fā)往供應商，供應商得到采購訂單后提交采購合同，采購部通過合同管理審核合同，簽訂合同后返回供應商要求供貨，同時將生效合同存儲 備查并提交采購部以便采購部向庫存部門。發(fā)送入庫單。 如圖 21 所示 ： 圖 21 超市采購管理信息系統(tǒng)業(yè)務流程圖 需求分析 需求分析的任務 需求分析是軟件定義時期的最后一個階段，也是設計數(shù)據(jù)庫的一個起點，它確定了系統(tǒng)必須完成哪些工作，提出完整、準確、清晰和具體的要求，直接影響到后面各個階段的設計，及設計結果是否合理和實用。 需求分析的任務是通過詳細調查現(xiàn)實世界要處理的對象（組織、部門、企業(yè)等），充分了解原系統(tǒng)（手工系統(tǒng) /計算機系統(tǒng)）工作概況，明確用戶的各種需求，然后在此基礎上確定 新系統(tǒng)的功能。新系統(tǒng)必須充分考慮今后可能的擴充和改變，不能僅僅按當前應用需求來設計系統(tǒng)。 其主要解決的問題： ? 信息要求：用戶希望從數(shù)據(jù)庫中獲 取什么數(shù)據(jù)，并由此決定在數(shù)據(jù)庫中 存儲哪些數(shù)據(jù) ； ? 處理要求：明確用戶對數(shù)據(jù)有什么樣的處理要求，從而確定數(shù)據(jù)之間的 相互關系 ； ? 安全性與完整性要求：確定用戶的最終需求是一件很困難的事情，用戶缺少計算機知識，不能準確表達自己的需求，所提出的需求往往經常變化。設計人員缺少用戶的專業(yè)知識，不易理解用戶的真正需求。因此在需求分析階段要求客戶的廣泛參與，設計人員也要去 熟悉客戶的業(yè)務工作，才能逐步確定用戶的實際需求。 超市采購管理信息系統(tǒng)的需求分析 超市采購 信息管理系統(tǒng)是一個基于全國連鎖制管理的 超市 統(tǒng)一集團內部商品 采購 的管理工具，以實現(xiàn)信息的全面采集和處理 、規(guī)范管理 、提高效率 。 通過實際調查，要求本系統(tǒng)具有以下功能： 請購單 合格請購單 采購部門 采購訂單 供應商 財務部門 部門資金信息 不合格請購單 銷售計劃 庫存部門 采購合同 生成采購訂單 合同臺帳 審批請購單 入庫單 采 購部門 合同管理 生效合同 批準記錄 未批準記錄 ? 要求系統(tǒng)具有良好的人機界面 ，使客戶不用了解過多的操作方法就可以熟練運用系統(tǒng)； ? 如果系統(tǒng)的使用對象較多，則要求有較好的權限管理 ，保證系統(tǒng)的穩(wěn)定和安全； ? 方便的數(shù)據(jù)查詢 ，通過簡單操作快速得到所需數(shù)據(jù)； ? 采用結構化的分析方法進行面向數(shù)據(jù)流的分析，主要有分層數(shù)據(jù)流圖和數(shù)據(jù)字典組成 ； 幫助更好的理解系統(tǒng)的流程； ? 在相應的權限下，可方便的刪除數(shù)據(jù)，同時也要保證安全性操作。 ? 商品基本檔案維護（新建、查詢、統(tǒng)計） ? 商品基本檔案的數(shù)據(jù)檢索（按不同要求分類模糊查詢，組合查詢） ? 報表處理（以不同選擇方式，輸出基本檔案信息） 數(shù)據(jù)流程圖（ DFD） 頂層 數(shù)據(jù)流程圖說明了系統(tǒng)總的處理功能，輸入和輸出。采購系統(tǒng)就是采購部門根據(jù)庫存送來的請購單進行系統(tǒng)處理，貨到后向庫存發(fā)出入庫單。 如圖 22所示： 圖 22 第一層 DFD 圖 中層 數(shù)據(jù)流圖是對頂層數(shù)據(jù)流圖的數(shù)據(jù) 流和加工進行分解，分解為更多的處理。 首先是主管 根據(jù)銷售列表和資金狀況 對倉庫發(fā)來的請購單進行審批處理，然后對通過審批的請購單進行訂單、合同處理。再把請購單、訂購單、合同歸檔，除了采購訂單外，還 需向 財務部門提供用款信息 。 如圖 23所示： 圖 23 第二層 DFD 圖 第三層考慮財務部門與銷售計劃將審批分解，如圖 24所示： 庫存部門 P1 庫存處理 D1 商品庫存信息 P2 審批 D1 銷售計劃 D2 資金信息 請購單 采購系統(tǒng)處理 倉庫 請購單 入庫單 財務部門 提供資金信息 系統(tǒng)分析 第三層 DFD 圖 圖 24 第三層 DFD圖 第四層數(shù)據(jù)流圖在第二層的基礎上進一步分析，把訂單、合同處理分開，再把合 同處理分為合同生成處理和合同管理。得到四個處理，審核、采購訂單管理、采購合同生成和采購合同管理。 如圖 25 所示： 圖 25 第四層 DFD圖 采購訂單管理 D5 供應商信息 D6 商品運輸方式 D7 采購付款方 式 D8 已通過審批請 購單 采購合同生成 談判價格等信息 采購訂單 采購合同管理 采購合同 用款信 息 D9 更新的合同狀態(tài)記錄 D10 更新的訂購單狀態(tài)記錄 D11 供應商共獲的查詢記錄 合同執(zhí)行狀態(tài) 操作員 財務部門 供應商 操作 員 系統(tǒng)分析 數(shù)據(jù)字典 (DD) 表 21 數(shù)據(jù)流名：請購單 簡述：庫存部門發(fā)出的請購信息 組成：請購單編號 +商品編號 +商品名稱 +規(guī)格 +單價 +請購數(shù)量 +需 要日期 +請購單狀態(tài) +賬號 +生成日期 +審批意見 備注： 表 22 數(shù)據(jù)流名：商品庫存信息 簡述：規(guī)定庫存下限， 當前倉庫里商品庫存量隨進貨完畢而改變 組成：商品編號 +庫存量 +庫存下限 備注： 表 23 數(shù)據(jù)流名：商品信息 簡述：由其他部門提供，審批時使用 組成：商品編號 +商品名稱 +規(guī)格 +單價 +供應商編號 +生產商編號 +備注 備注： 表 24 數(shù)據(jù)流名：財務部門信息表 簡述：由財務部門提供，審批時使用 組成：部門代碼 +可用資金 +最近使用時間 +最近使用理由 備注： 表 25 數(shù)據(jù)流名：采購訂單 簡述：采購訂單管理模塊生成，流向合同生成模塊 組成：訂購單編號 +訂購單狀態(tài) +下單日期 +賬號 +商品編 號 +商品名稱 +規(guī)格 +數(shù)量 +單價 +金額 備注： 表 26 數(shù)據(jù)流名：采購合同 簡述：采購合同生成模塊生成，流向合同管理模塊 組成：合同編號 +訂購單編號 +合同狀態(tài) +總金額 +交貨日期 +付款方式編號 +付款方式名稱 +預付款 +供應商編號 +供應商名稱 +運輸方式編號 備注： 表 27 數(shù)據(jù)流名：用款信息 簡述：又名待批準資金，合同管理模塊生成，流向財務部門 組成：請求編號 +部門代碼 +部門名稱 +請求資金 +請求理由 +請求時間 +付款方式名稱 +是否批準 備注： 表 28 數(shù)據(jù)流名：入庫單 簡述：采購部門 生成，流向倉庫部門 組成：商品種類 +商品名稱 +數(shù)量 備注： 表 29 數(shù)據(jù)文件名：采購合同記錄 簡述：采購合同生成模塊生成，流向合同管理模塊 組成：合同編號 +訂購單編號 +合同狀態(tài) +總金額 +交貨日期 +付款方式編號 +付款方式名稱 +預付款 +供應商編號 +供應商名稱 +運輸方式編號 備注 表 210 數(shù)據(jù)元素名：訂購單編號 簡述：訂購單的代碼 取值：“年、月、日、編號”如： 090501***** 備注：字段類型為數(shù)字 表 211 數(shù)據(jù)元素名：商品編號 簡述：訂購商品的代碼 簡稱 sp 系統(tǒng)分析 取 值：“ 1” __“ 500” 備注：字段類型為數(shù)字 表 212 數(shù)據(jù)元素名：供應商編號 簡述：供應商的代碼 簡稱 gy 取值：“ 1” — “ 500” 備注：字段類型為數(shù)字 表 213 數(shù)據(jù)元素名：合同編號 簡述：生成合同的代碼 取值：“年、月、日、編號” — 如 090502**** 備注：字段類型為數(shù)字 表 214 數(shù)據(jù)元素名：請求編號 簡述：請求部門代碼 取值：“ 1” — “ 50” 備注：字段類型為數(shù)字 表 215 數(shù)據(jù)項名：賬號 簡述：請求資金時的銀行賬號 取值：如 810112345678902020 備注： 表 216 數(shù)據(jù)項名：登錄名 簡述：登錄進入系統(tǒng)的用戶名 取值： qq， dd， hh， zj 備注： qq 為倉庫管理者帳號， dd為主管賬號，hh 為采購管理者帳號， zj 為財務管理者帳號 3 系統(tǒng)設計 在整個系統(tǒng)的開發(fā)時期中，設計階段是最主要的階段。設計任務通常分為兩個階段來完成，第一個階段是概要設計，它的任務是建立軟件的總體結構， 即軟件的組成，以及各組成成分之間的相互聯(lián)系。第二個階段是詳細設計，其任務是確定模 塊的內部算法和數(shù)據(jù)結構，產生描述各個模塊程序過程的詳細設計文檔，本系統(tǒng)采用了原型法，即先跟據(jù)需求分析設計出原型，然后在原型的基礎上進行測試和改進。本系統(tǒng)在設計過程中采取了模塊化的設計方法，化繁為簡 。 設計思想 本系統(tǒng)分為四種操作員進行，每種操作員有自己的賬號和密碼。按照采購流程來認識每種操作員的任務 。首先是倉庫部門的操作員，他在請購單管理模塊里主要是根據(jù)商品庫存是否有缺貨可能來進行請購單添加、修改操作。 然后是主管人員登入界面，對生成的請購單進行審批。審批前要查看商品信息表、執(zhí)行中合同情況 以及 財務部門的報表 等 ， 然后提交審批意見 ，分為合格請購單和不合格請購單。不合格請購單要退回庫存部門處理。 接著采購部 門的人員登入訂購單管理界面，根據(jù)已經批準的請購單列表生成請購單 ，同時可打印報表 。在合同還沒有生成之前都可以修改、撤銷操作。剛生成的訂購單還為未 執(zhí)行狀態(tài)，然后進入合同管理界面，該界面提供合同添加、撤銷、查詢 功能。選擇訂購單號就可以跳出訂單信息 ，再填入最終價格等就生成相對的合同，訂單編號和合同編號一致。 合同一旦生成就進入執(zhí)行狀態(tài)， 不允許再修改。 推出后返回到訂購單管理界面就可以發(fā)現(xiàn)訂購單也自動變?yōu)閳?zhí)行狀態(tài) 了。此時不能對訂購單和合同內容做任何修改。到貨后，更改合同狀態(tài)為已完成，則訂購單也變?yōu)橐淹瓿伞? 在以財務部門人員的身份登入資金審批界面，提供了部門資 金信息和待審批資金項目。只要點擊審批按鈕就可以跳出請求詳細信息。 最后倉庫人員再次登入，則跳出入庫單， 生成報表。提供商品名稱和數(shù)量，并且可以發(fā)現(xiàn)該商品的庫存量已經更新。 系統(tǒng)設計 系統(tǒng)模塊設計 圖 31 系統(tǒng)模塊分析 1， 請購單管理模塊 模塊名：請購單管理 簡述： 庫存管理員估計未來一段時期的庫存量添加請購單，包括商品名稱，數(shù)量 ，需要日期