酒店管理系统设计方案

酒店管理系统设计

方案

?更多资料请访问.(.....)

?更多资料请访问.(.....)

新天红东酒店管理系统

现

状

调

查

和

建

议

湖南省健坤科技信息技术有限公司

-7-8

1、概述 (3)

1.1、项目背景 (3)

1.2、系统设计目标 (3)

1.3、定义 (3)

2、设计方案 (4)

2.1、开发目标 (4)

2.2、应用目标 (4)

2.2.1、运行环境 (4)

2.2.2、系统集成要求 (4)

2.3、系统设计原则 (5)

2.4、系统架构 (6)

2.4.1、三层结构(推荐) (6)

2.4.2、遵循魔方系统系统架构 (8)

3、详细设计 (8)

3.1、零售数据修改模块 (8)

3.1.1、系统结构图 (8)

3.1.2、数据定义 (9)

3.1.3、零售数据修改功能模块设计 (9)

3.1.3.1零售数据编辑

9

3.1.3.2零售数据修改审核

11

3.1.3.3零售数据修改的查询

12

3.1.3.4所属客户的选择

13

3.1.3.5门店的选择

13

3.2、门市管理模块 (14)

3.2.1、系统结构图 (14)

3.2.2、门市档案数据设计 (14)

3.2.3、门市档案功能模块 (18)

3.2.3.1门店档案编辑

18

3.2.3.2门店档案审核

19

3.2.3.3门店档案查询

19

3.2.3.4所属客户的选择

20

4、开发进度计划 (20)

1、概述

1.1、项目背景

创维公司外购了一套终端销售系统(也称魔方系统),用于对零售数据进行统计,可是由于某些原因,上报进来的数据存在差异,因此需要提供一个专门的模块对零售数据进行修改。

创维公司每个客户有一个甚至多个门店,需要对客户的门店进行管理,便于物流和销量统计等工作。

1.2、系统设计目标

根据零售数据修改需求说明书和门店档案管理需求说明书明确系统需求以便指导系统功能的实现。

1.3、定义

本文档中涉及的专门术语、容易引起歧义的概念、关键词缩写及相应的解释内容包括:

零售数据是指对终端销售系统提供的零售数据进行后期修改的模块。

门店档案的管理是指对客户的门店基础资料进行管理的模块,包括新建、修改、删除、封存、启用、作废功能。

2、设计方案

2.1、开发目标

1.系统能够实现地对零售数据进行修改和门店基础资料进行管

理,并完成功能需求。

2.实现数据的安全性和完整性。

3.给用户清新、易用的界面,采用AJAX技术提高界面友好性。

4.系统能够有高效的运行速度。

2.2、应用目标

2.2.1、运行环境

?数据库:Oracle 10g

?运行平台:.Net Framework 2.0

?开发工具:Visual Studio

?服务器操作系统:Windows Server

?Web信息服务管理器:IIS 6.0

?客户端浏览器:IE6.0、IE7.0、IE8.0,显示器的分辨率在1024*768及以上的都能填满整个窗口。

2.2.2、系统集成要求

◆系统能在上面运行环境中正常运行。并能够与现有环境集成。

◆用户登陆后,现有系统提供的SESSION信息如下:

?岗位编号:审核时需要用到,不同岗位能够看到不同的待审核单。

?可控业务组织:查询时需要用到,每个用户只能查到属于自己可控组织的门店档案。

现有系统提供审核模块的接口,不需要重新开发,当前提供的格式为”(2,434,3443,232,23343,32423,4322)”,括号里的数字表示可控的组织编号。需要注意的是,分公司可控的业务组织可能就几十个,可是总部的员工可控所有业务组织(也可称部门),因此在加载基础资料时总部加载量比较大,比如能够加载出所有的客户,客户量当前在3万左右。

比如一个用户可控东莞办,则她的可控业务组织是:(464)

可控的客户则能够用如下方式查询:

SELECT * FROM CUSTOMER_ACTIVE WHERE FORG IN (464)

◆当前系统的导航采用的是树形菜单导航,因此系统框架中有

30%的宽度放的是导航菜单,右侧放具体页面,在排版时要注意内容的摆放。主界面效果如下图所示:

2.3、系统设计原则

技术先进性和易升级性

技术上系统采用Windows Server操作系统,Oracle 数据库, B/S体系结构等主流技术,能够保证平稳升级。业

务上基于健坤科技公司的业务软件应用模式,结合创维的特点,吸收国内外管理软件的先进的管理思想,采用一体化设计的思路,优化和实现最佳的业务流程,达到最大程度的数据共享,确保系统应用模型的先进性。

易用性

提供图形化用户界面,操作简便易学,随时提供在线帮助,尽量降低操作使用、系统升级和维护的难度。

系统的开放性

浏览器/服务器(Browse/Server)体系结构已被数据库产品开发者、硬件制造厂商、系统集成商和广大的用户广为使用,证明是一种较为理想的体系结构。采用这种体系结构,实现分布式操作,可大大减轻服务器和主干网的负担,更有效地使用计算机资源,大大提高通讯和控制的效率。

稳定性和可靠性

系统选用可靠的硬件设备、操作系统和数据库,有严格的安全机制和数据备份机制,可确保数据安全可靠,应用软件则为成熟运行5年的可靠产品,稳定性和可靠性能够得到保证。

可集成性

为了实现两个系统模块和原魔方系统信息共享,降低系统集成难度,对于共享数据库的分布式数据库管理系统采用单一型数据库管理系统,共享数据的基表保持一致的

关系模式。

安全性和保密性

在网络配置上,选用健坤科技公司的网络经过国家公安部信息安全产品信息检测中心严格测试,获得公安部颁发许可证书的NETEYE防火墙,能够防止系统外来的攻击。从企业外只可访问对外信息发布系统,保证内部各业务子系统的数据不被非法用户所获取。

在应用系统设计上,经过对各级人员及不同业务人员的权限分配,以及严格的口令验证机制,作到所有人员只能查看与自己工作相关的数据,并建立完善的日志管理,作到所有操作有据可查。

可扩充性与易维护性

系统采用面向对象程序设计更方便维护和扩充,可动态设置业务流、数据流和控制点参数,适应创维今后由于管理制度、机构设置、业务流程和管理要求发生变化而导致的业务重组,满足将来发展的需要。

技术成熟原则

以已有的开发经验为依托,尽量采用已在其它系统中性能稳定的技术和流程模式,从而使公司内各处用户能够尽快适应新的工作环境。

2.4、系统架构

2.4.1、三层结构(推荐)

各层具体完成的任务:

一:表示层

UI 层为客户端提供对应用程序的访问。从”用户”层接收用户输入,并进行简单的数据数据验证,如非空,非数字以及非法日期等的验

二: 业务逻辑层(BLL)

主要功能如下:

1.实现一些简单的业务逻辑,比如,组合查询等。

2. 处理这一些操作,比如计算:销售价格并根据顾客的级别计算回扣等等,这部分往往有许多不同的功能的类,操作起来也比较复杂,此时则经过调用业务规则层进行业务计算处理,然后调用数据访问层(DataAccess)进行存储。

三:数据访问层(DataAccess)

数据访问层为业务规则层提供数据服务。负责数据库的增、删、改、查工作。

四:Common层,也称为实体层,与数据库表的列一一对应,作为程序

中传递数据的一个载体。

各层严格分工,调用顺序为UI层调用BLL层,BLL层再调用数据访问层(DataAccess),禁止越级调用,也就是说,UI层不允许直接调用数据访问层(DataAccess),但Common层作为各层中传递数据的一个载体,每层都能够调用。

2.4.2、遵循魔方系统系统架构

也能够遵循原魔方系统的系统架构。

3、详细设计

3.1、零售数据修改模块

3.1.1、系统结构图

销售机构结构图:

零售数据修改模块:

|零售数据修改 |

| |——零售数据修改编辑

| |——零售数据修改审核

| |——零售数据修改查询

3.1.2、数据定义

现有魔方销售明细表结构: MF_SALE:

需要关联的表数据:

根据MARKET_SHIPPER_INFO表的FEMP和MF_SALE表的STAFFNO关联出导购员的姓名,MARKET_SHIPPER_INFO的表结构如下:

根据PRODUCT_ACTIVE表的FID和MF_SALE的PRODUCTID关联出产品名称,PRODUCT_ACTIVE的表结构以及样例数据参考”零售数据修改表结构及样例数据.xls”。

3.1.3、零售数据修改功能模块设计

3.1.3.1零售数据编辑

该功能完成零售数据的从魔方系统的加载、修改、导入功能。在修改后,不能直接更新到魔方系统,必须经过审核才能够写入魔方系统。

加载魔方数据需要根据门店、开始时间、结束时间三个参数进

行查询,”cw”+门店编号等于魔方销售明细表的ORGID字段。

能够修改和新增的信息包括:门店、导购员、产品、销售价格、销售日期、销售数量、销售类型、备注。

为了更便于修改销售明细,系统需要提供导入明细的功能,用户在EXCEL中录入信息格式如下:

从魔方拉过来的数据中,只能修改和新增,支持”单行删除”和”全部删除”功能,但不是真正的删除记录,而是将”销售数量”置0。

明细数据的修改为了操作的方便,需要实现在表格中直接修改的功能,而且对录入的数据在提交之前需要做合法性的校验,比如日期类型、数字类型的判断。

明细数据中门店、导购员、产品型号要支持弹出选择的功能,导购员根据选择的门店取该门店下面的导购员,从MARKET_SHIPPER_INFO表中取,产品信息从PRODUCT_ACTIVE表中取。都用单选的方式实现,实现方式类似”所属客户”的选择。请参看”所属客户选择”部分。

保存后需要有制单人、制单人所在组织和制单时间。

编辑模块提供新增、保存、确认、删除功能。其中,只有新增和保存操作不需要提交到审核流,确认操作都需要提交到审核流,并由相关岗位的人员进行审核。

编辑模块为了方便查看已经修改过的明细记录,需要根据修改时生成的单号及所属客户进行查询。

客户的选择为单选方式,参见客户选择功能模块的说明。

门店的选择为多选方式,参见门店选择功能模块的说明。

界面布局可参考如下界面示例:

3.1.3.2零售数据修改审核

该功能提供给相关人员对零售数据的修改进行审核,如果审核经过,则执行审核操作,否则退回该单。

需要审核的单包括状态为5-审核中的记录。

在审核后,各状态转换如下:

审核模块为了方便查看已经修改过的明细记录,需要根据修改时生成的单号及客户进行查询。

查询出来后显示符合条件的列表,在点击某条记录后能够单独查看该条记录的详细信息。详细信息中包含主信息:单号、客户、零售开始时间、零售截止时间、制单时间、制单人、备注,明细列表信息为:门店、导购员、产品、销售价格、销售日期、销售数量、销售类型、备注。