商店商场等进销存管理系统Word格式.docx
- 文档编号:5593899
- 上传时间:2023-05-05
- 格式:DOCX
- 页数:21
- 大小:216.58KB
商店商场等进销存管理系统Word格式.docx
《商店商场等进销存管理系统Word格式.docx》由会员分享,可在线阅读,更多相关《商店商场等进销存管理系统Word格式.docx(21页珍藏版)》请在冰点文库上搜索。
财务管理部门根据销售部门提供的销售单计算付款金额,根据采购部门提供的进货单计算支付金额,并根据需要定期进行各种类型的帐目统计,为企业销售计划的制定提供决策依据。
(3)各子系统的功能分析及数据流图
根据各部门的不同功能,将该系统划分为四个子系统,分别是:
采购管理子系统、库存管理子系统、销售管理子系统和财务管理子系统,该系统的一层数据流图如图7.1所示:
图7.1系统一层数据流图
1采购管理子系统
采购管理子系统数据流图细化如图7.2。
图7.2二层DFD——采购管理细化
A.对采购员提供的采购计划生成采购订单
B.对采购订单进行管理(删除、修改、查找)
C.将采购订单发送给指定的供货商,通知其订货
D.供货商交付货物时,系统根据采购订单进行验货处理,若符合订单内容,则填写进货单发送给仓库管理系统;
若不符合订单内容,则生成退货单发送给供应商
②库存管理子系统
库存管理子系统数据流图细化如图7.3。
A.仓库管理员根据销售管理部门提供的进货单,对货物进行验收,若合格则入库,生成入库单记录入库商品的详细信息,仓库管理员同时修改库存商品信息;
若验收不合格则进行退货处理,系统生成退货单
B.从仓库提取货物时,系统根据销售部门提供的缺货单,进行出库管理,生成出库单,并修改库存商品信息
C.超市的高级管理人员如经理,可以随时对库存信息进行查询
图7.3二层DFD——库存管理细化
③销售管理子系统
A.根据顾客销售的商品和商品信息,进行收银处理,生成商品销售记录
B.对销售记录打印,生成销售单据给顾客
C.在收银处理过程中,可以对销售信息进行修改、添加和删除操作;
收银处理结束后,若销售信息出现了错误,只能将该次销售记录取消,重新进行录入
D.根据超市的销售情况,实时检测货物数量,在货物短缺前生成缺货单,并将缺货信息传给库存管理子系统。
图7.4二层DFD——销售管理细化
④财务管理子系统
A.根据库存管理部门的进货单,计算每笔业务的应付款和应付款明细
B.根据销售管理部门的销售单,计算每笔业务的应收款和应收款明细
C.财务人员根据各种查询需要对帐目进行查询和统计
D.超市的高级管理人员如经理,可以随时对财务信息进行查询
图7.5二层DFD——财务管理细化
(4)数据字典举例
名字:
退货单
别名:
退货报表
描述:
退货的依据
定义:
退货单=退货单编号+订单编号+负责人编号+商品条码+商品类别+商品数量+金额+供应商名称+退货原因
位置:
采购退货管理
入库单
商品入库时必须开具入库单,表明商品已经入库
入库单=入库单编号+进货单编号+仓库管理员编号+入库时间
库存管理系统中使用
采购订单
根据采购计划生成的采购商品列表
采购订单=采购订单编号+采购开始日期+负责人编号+商品名称+商品数量+供应商名称
采购管理模块
商品信息
商品档案
所有商品的信息保存在商品档案表中
商品档案表=条形码+商品名称+类别编号+库存上限+库存下限+现有库存量+现价+原价+备注
库存管理,销售管理
销售单
销售信息,销售发票
销售的记录,并打印给客户作为收据
销售单=流水号+销售日期+收银员编号+机号+应收款+实收款+找回+销售明细
前台销售管理
销售明细
销售记录
详细的商品销售信息
销售明细=流水号+条形码+数量+单价
销售发票
编号
所有的编号
编号=1{字母|数字}10
系统
权限
用户使用本系统的权限级别,防止非授权的用户更改系统的数据资料
编号=1——经理等领导
2——采购员
3——会计
4——仓库管理员
8——销售员
整个系统
7.1.2概念结构设计
(1)绘制分E-R图
概念设计过程采用自底向上的设计方法,即首先定义各局部应用的概念结构,然后将它们集成起来,得到全局概念结构。
根据需求分析给出的数据流图,参照数据字典中的详细描述,下面给出各个子系统的分E-R图的设计及对其进行的各项调整。
采购管理子系统
图7.6采购管理子系统E_R图
①实体属性定义:
●职员(职员编号、姓名、权限、口令)
●商品(条形码、商品名称、类别编号、库存上限、库存下限、现有库存量、现价、原价、备注)
●供货商(供货商编号、供货商名称、公司地址、联系电话、Email)
●订单(订单编号、商品条码、商品名称、采购数量、采购开始日期、负责人编号、供应商名称)
●进货单(进货单编号、订单编号、商品条码、商品名称、商品类别、进货数量、进货日期、负责人编号)
●退货单(退货单编号、订单编号、商品条码、商品名称、退货数量、退货原因、仓库管理员编号、退货时间)
②实体间联系:
●一个采购员可以填写多份采购订单,但是一份订单只能由一个采购员负责;
●一份采购订单中可以包含多种商品,一种商品也可以被多个订单采购;
●一个供货商可以供应多份采购订单的采购要求,但是每份采购订单只能交给一个供货商处理;
●一张采购定单中的货物可以分多次到货,因此可以生成多张进货单和退货单。
③说明:
●采购订单也可以表示为“采购员——供货商——商品”三个实体集之间的多对多联系;
●由于采购员是职员的一种,为了操作简便,将采购员抽象为职员实体集,用“权限”属性来表示职员不同的身份。
库存管理子系统
图7.7库存管理子系统E_R图
●采购进货单(采购进货单编号、订单编号、负责人编号)
●缺货单(缺货单编号、缺货日期、负责人编号)
●入库单(入库单编号、进货单编号、仓库管理员编号、入库时间)
●出库单(出库单编号、缺货单编号、仓库管理员编号、出库时间)
●退货单(退货单编号、进货单编号、仓库管理员编号、退货时间)
●一张进货单中的商品可以由多个仓库管理员在不同的时间分多次进行入库处理,每次入库时检查合格的商品要生成入库单入库;
检查不合格的商品要生成退货单退回给供货商;
●一张缺货单中的商品可以由多个仓库管理员在不同的时间分多次进行出库处理;
●由于在入库单、出库单中只涉及到仓库管理员的编号,所以把仓库管理员作为属性而不是实体集处理;
销售管理子系统
图7.8销售管理子系统E_R图
●销售单(流水号、销售日期、收银员编号、机号、应收款、实收款、找回)
●一张销售单中可以包含多种商品,而一种商品也可以被包含在多个销售单中,某个销售单销售的具体商品信息用销售明细表示。
●一张缺货单中可以包含多种商品,而一种商品也可以被包含在多个销售单中,某个缺货单销售的具体商品信息用缺货单明细表示。
●由于在销售单中只涉及到收银员的编号,所以把收银员作为属性而不是实体集处理。
财务管理子系统
图7.9财务管理子系统E_R图
●进货单(进货单编号、订单编号、负责人编号、商品条码、商品类别、商品数量、供应商名称)
●应付款(进货单编号、付款日期、应付金额、会计)
●应收款(销售单编号、收款日期、应收金额、会计)
●应付款记录和进货单一一对应;
应收款记录和销售单一一对应
●每笔应付款记录中可以包含多个商品,而每个商品可以包含在多个应付款记录中,每笔应付款记录中的具体付款信息由应付款明细表示
●每笔应收款记录中可以包含多个商品,而每个商品可以包含在多个应收款记录中,每笔应收款记录中的具体付款信息由应收款明细表示
(2)视图集成
以上是四个子系统的分E-R图设计及其调整的整个过程,接着要做的就是将所有的分E-R图进行综合,合成一个系统的总E-R图。
分两步进行:
第一步:
合并。
解决各分E-R图之间的冲突,将各分E-R图合并起来生成初步E-R图。
各分E-R图之间的冲突主要有三类:
①属性冲突:
●属性域冲突,即属性值的类型、取值范围或取值集合不同。
由于本系统较简单,所以并不存在这种冲突;
●属性取值单位冲突。
由于本系统较简单,不存在这类冲突;
②命名冲突:
●同名异义:
由于本系统较简单,所以不存在这类冲突;
●异名同义:
采购管理子系统中的进货单和库存管理子系统中的采购进货单命名不同但结构相同,因此统一名称为进货单;
③结构冲突:
●同一对象在不同应用中具有不同的抽象:
如职员实体,在各子系统中职员有不同的只能,本系统利用“权限”属性将其统一成一个实体集。
●同一实体在不同分E-R图中所包含的属性个数和属性排列次序不完全相同:
第二步:
修改和重构。
消除不必要的冗余,生成总E-R图,由于本系统在子系统设计阶段就去掉了冗余,因此不存在这类问题,只需要将各分E-R图直接进行合并即可。
下面给出总E-R图,如图7.10。
图7.10系统总E_R图
7.1.3逻辑结构设计
(1)与总E-R图对应的关系模式
①实体所对应的关系模式:
职员(职员编号、姓名、权限、口令)
商品(条形码、商品名称、类别编号、库存上限、库存下限、现有库存量、现价、原价、备注)
供货商(供货商编号、供货商名称、公司地址、联系电话、Email)
订单(订单编号、商品条码、商品名称、采购数量、采购开始日期、负责人编号、供应商名称)
进货单(进货单编号、订单编号、商品条码、商品名称、商品类别、进货数量、进货日期、负责人编号)
退货单(退货单编号、订单编号、商品条码、商品名称、退货数量、退货原因、仓库管理员编号、退货时间)
缺货单(缺货单编号、缺货日期、负责人编号)
入库单(入库单编号、进货单编号、仓库管理员编号、入库时间)
出库单(出库单编号、缺货单编号、仓库管理员编号、出库时间)
销售单(流水号、销售日期、收银员编号、机号、应收款、实收款、找回)
应付款(编号、进货单编号、付款日期、应付金额、会计)
应收款(编号、销售单编号、收款日期、应收金额、会计)
②联系所对应的关系模式:
●m:
n联系的转换
采购单明细(采购订单编号、商品条码、数量、类型、单价、金额)
进货单明细(进货单编号、商品条码、数量、类型)
缺货单明细(缺货单编号、商品条码、缺货数量)
退货单明细(退货单编号、商品条码、退货数量、原因)
入库明细(入库单编号、商品条码、数量)
出库明细(出库单编号、商品条码、数量)
销售明细(流水号、商品条码、数量、单价、金额)
应付款明细(进货单编号、商品编号、商品单价、商品数量、单价、应付金额)
应收款明细(销售单编号、商品编号、商品单价、商品数量、单价、应收金额)
●1:
供货商和采购订单之间的1:
n联系并入采购订单关系;
职员和采购订单之间的1:
采购订单和进货单之间的1:
n联系并入进货单关系;
采购订单和退货单之间的1:
n联系并入退货单关系;
进货单和入库单之间的1:
n联系并入入库单关系;
缺货单和出库单之间的1:
n联系并入出库单关系;
③关系模式的优化:
●采购订单(采购订单编号、商品条码、商品名称、采购数量、采购开始日期、负责人编号、供应商名称)
该关系模式的主码为K=(采购订单编号、商品条码),存在的函数依赖集F包括:
(采购订单编号、商品条码)→采购数量
采购订单编号→采购开始日期,负责人编号,供应商名称
商品条码→商品名称
所以,该关系模式属于2NF。
将原关系模式分解得到满足3NF的关系模式集为:
R1=采购订单(采购订单编号、采购开始日期、负责人编号、供应商编号)
R2=商品信息(商品条码、商品名称)
R3=采购订单详细信息(采购订单编号、商品条码、采购数量)
将R2和R3与关系模式商品和采购单明细合并。
关系模式“进货单”和“采购退货单”与“采购订单”的优化过程相同。
该关系模式中的“找回”属性值可以由“实收款”和“应收款”的差计算得到,因此不必存储在数据库中;
●采购单明细(采购订单编号、商品条码、数量、类型、单价、金额)
优化说明:
“金额”没有删除,因为在这一项上查询比较频繁,如果每次查询都计算,必然使系统计算增加,性能降低。
保留下来虽然造成了一定的冗余,但提高了查询的效率,利大于弊。
应付款明细和应收款明细也作同样的优化。
(2)用户子模式设计
①采购管理系统用户子模式
商品(条形码、商品名称、类别编号、现有库存量、备注)
采购单(采购订单编号、采购开始日期、负责人编号、商品条码、数量、类型、单价、金额、供货商名称、职员编号)
因为采购部门对于超市的其他情况不会也不必关注,经常使用的只有以上各项,所以在采购管理子系统上设立以上关系。
②库存管理系统用户子模式
进货单(进货单编号、订单编号、商品条码、数量、类型、负责人编号)
采购退货单(退货单编号、订单编号、仓库管理员编号、商品条码、数量、类型、退货时间)
入库单(入库单编号、进货单编号、仓库管理员编号、入库时间、商品条码、数量、类型)
出库单(出库单编号、缺货单编号、仓库管理员编号、出库时间、商品条码、数量、类型)
因为库存管理部门对于超市的其他情况不会也不必关注,经常使用的只有以上各项,所以在库存管理子系统上设立以上关系。
③销售管理系统用户子模式
缺货单(缺货单编号、缺货日期、负责人编号、商品条码、缺货数量)
销售单(流水号、销售日期、收银员编号、机号、应收款、实收款、找回、商品条码、数量、单价)
因为销售管理部门对于超市的其他情况不会也不必关注,经常使用的只有以上各项,所以在销售管理子系统上设立以上关系。
④财务管理系统用户子模式
应付款明细(进货单编号、商品编号、商品单价、商品数量、单价、付款日期、应付金额、会计)
应收款明细(销售单编号、商品编号、商品单价、商品数量、单价、付款日期、应收金额、会计)
7.1.4物理结构设计
(1)存储结构设计
经过分析可知,该超市进销存管理系统中信息处理有以下特点:
●销售部门的数据不仅经常需要查询,而且更新速度快。
●各个部门信息要求共享的信息较多。
例如员工信息,商品信息等。
但财务信息一般不共享。
●经理部门有一定的特殊职能:
汇总财务信息;
制定采购计划;
安排货物的入库和出库工作。
针对这些特点,设计如下:
①确定数据库的存放位置
为了提高系统性能,现根据应用情况将数据按照易变部分和稳定部分、经常存取部分和存取频率较低的部分分别在两个磁盘上存放。
同时,考虑到本系统是多用户的,为了提高效率,数据库的备份的数据和日志文件将保存在磁带中。
●经常存取部分:
●存取频率较低的部分:
采购订单(采购订单编号、采购开始日期、负责人编号、供货商名称、职员编号)
进货单(进货单编号、订单编号、负责人编号)
采购退货单(退货单编号、订单编号、仓库管理员编号、退货时间)
②确定系统配置
本系统针对于一个中等规模的超市进行管理系统的设计,因此选择的微机数量和规模都不必太大,但在系统设计时应考虑到超市的发展需求,在选择硬件设备、服务器操作系统、数据库时都考虑到能够逐步的增加和扩展。
本管理系统前台选用市场上销售的收银机作为终端处理设备,选用了Windows2000系统作为其他部门微机的操作系统,它能够有较好的使用界面并能够充分发挥出微机硬件的作用,比较适合酒店这样的机构;
另外,选用了目前应用最多的ORACLE数据库。
由于涉及到超市的财务管理,数据的完整性和安全性显得尤其重要。
系统中的数据一旦丢失,将需要很长时间进行恢复,有时甚至使信息系统不得不从系统初始化阶段重新开始运行。
每天进行数据备份是保障系统安全的重要手段。
数据备份需要严格按照事先制定的备份与故障恢复策略进行,并落实备份登记和检查措施。
(2)存取路径设计
①对以下经常在查询中出现的关系的码建立索引<
说明:
下加横线部分表示关系的码>
②以下经常进行连接操作的关系的码建立索引:
职工编号、商品条码、订单编号等
③由于下面几个关系模式的更新频率很高,所以没有定义索引:
账单(账单编号、总帐编号、发票号、摘要、收入数、支出数、日期、经手人号、备注);
本实例的特点是:
将数据库设计理论应用在本实例设计的全过程,结合实例详细说明了“需求分析——概念设计——逻辑设计——物理设计”等阶段应完成的任务和设计的主要内容。
通过本实例的学习可以使读者对数据库分析与设计过程有一个全面地、细致的了解。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 商店 商场 进销存 管理 系统