某酒店管理系统设计方案doc 24页正式版Word下载.docx

某酒店管理系统设计方案doc 24页正式版Word下载.docx

《某酒店管理系统设计方案doc 24页正式版Word下载.docx》由会员分享，可在线阅读，更多相关《某酒店管理系统设计方案doc 24页正式版Word下载.docx（20页珍藏版）》请在冰豆网上搜索。

开发工具：

VisualStudio2008

服务器操作系统：

Windows2003Server

Web信息服务管理器：

IIS6.0

客户端浏览器：

IE6.0、IE7.0、IE8.0，显示器的分辨率在1024*768及以上的都能填满整个窗口。

2.2.2、系统集成要求

◆系统能在上面运行环境中正常运行。

并可以与现有环境集成。

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

岗位编号：

审核时需要用到，不同岗位可以看到不同的待审核单。

可控业务组织：

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

现有系统提供审核模块的接口，不需要重新开发，目前提供的格式为”（2,434,3443,232,23343,32423,4322）”，括号里的数字表示可控的组织编号。

需要注意的是，分公司可控的业务组织可能就几十个，但是总部的员工可控所有业务组织（也可称部门），所以在加载基础资料时总部加载量比较大，比如可以加载出所有的客户，客户量目前在3万左右。

比如一个用户可控东莞办，则他的可控业务组织是：

（464）

可控的客户则可以用如下方式查询：

SELECT*FROMCUSTOMER_ACTIVEWHEREFORGIN（464）

◆目前系统的导航采用的是树形菜单导航，所以系统框架中有30%的宽度放的是导航菜单，右侧放具体页面，在排版时要注意内容的摆放。

主界面效果如下图所示：

2.3、系统设计原则

技术先进性和易升级性

技术上系统采用Windows2003Server操作系统，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:

字段名

类型

备注

SALEID

VARCHAR2（40）

编号

COMPANYID

公司名

SALEDATE

DATE

销售日期

PRODUCTID

产品编号

SALEQUANTITY

NUMBER（10）

销售数量

SALEROOM

NUMBER（10,4）

STAFFNO

员工编号

SOURCETYPE

NUMBER

（1）

来源类型

NOTE

VARCHAR2（2000）

CREATETIME

建立时间

PRICE

价格

ORGID

部门编号

SYNC_STATUS

为0

SALEFTYPE

销售类型

需要关联的表数据：

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

ID

NUMBER（9,0）

唯一编号

FEMP

MF_SALE的STAFFNO

FMARKET

门店编号

FNAME

NVARCHAR2（50）

门店名称

XED

状态

STIME

开始时间

ETIME

结束时间

FTIME

根据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表中取。

都用单选的方式实现，实现方式类似“所属客户”的选择。

请参看“所属客户选择”部分。

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

编辑模块提供新增、保存、确认、删除功能。

其中，只有新增和保存操作不需要提交到审核流，确认操作都需要提交到审核流，并由相关岗位的人员进行审核。

操作方法

操作前的状态

操作后的状态

新建

----

0-未确认

保存

确认

5-已确认

删除

3-删除

审核

5-已确认

1-有效

退回

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

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

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

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

3.1.3.2零售数据修改审核

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

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

在审核后，各状态转换如下：

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

查询出来后显示符合条件的列表，在点击某条记录后可以单独查看该条记录的详细信息。

详细信息中包含主信息：

单号、客户、零售开始时间、零售截止时间、制单时间、制单人、备注，明细列表信息为：

界面效果可参考如下界面：

3.1.3.3零售数据修改的查询

零售数据修改的查询模块主要是对修改过的零售数据进行全面的查询，提供的查询条件应包含：

单号、客户、制单开始时间、制单截止时间、状态进行查询。

查询的条件如果为空，则查询出所有记录。

可以查询的同时，提供根据条件提供EXCEL导出的功能。

3.1.3.4所属客户的选择

在零售数据修改的编辑和查询模块多处需要用到所属客户，所属客户的选择需要做得比较人性化和实现快速搜索的功能，目前客户的数据量在3万左右。

客户的基本信息如下：

客户编号：

标识一个客户的编号。

客户名称：

客户的名称。

客户编码：

客户编码比较重要，并且是像客户编号一样唯一，由字母和数字组成，一般的用户都记住的是客户编码，名称倒不一定记得清楚。

所属组织：

客户所属的组织，在客户查询时需要根据当前用户的可控业务组织权限取得可控的客户信息。

以上基本信息中客户名称和客户编码需要在选择时给予显示，并且可以根据这两个字段的值进行模糊搜索。

显示上建议在文本控件输入可以像XX首页一样给出提示，并可选择，同时也可以根据文本框输入的内容进行过滤，弹出窗口供选择。

所属客户为单选控件。

客户具体的数据结构以及样例请参看附件：

“零售数据修改表结构及样例数据.xls”。

3.1.3.5门店的选择

在零售数据修改的编辑模块需要用到门店选择，门店的选择需要做得比较人性化和实现快速搜索的功能，目前门店的数据量在6万左右。

门店的基本信息如下：

门店编号：

标识一个门店的编号。

门店名称：

门店的名称。

门店编码：

门店编码，由字母和数字组成。

所属客户：

门店所属的客户，在门店查询时需要根据当前用户的可控业务组织权限取得可控的客户信息，再查找相应客户下面的门店信息。

以上基本信息中门店名称和门店编码需要在选择时给予显示，并且可以根据这两个字段的值进行模糊搜索，查询出来的结果显示门店名称和门店编码两项，例如：

“VWAXB100401/巫山县声达电器有限公司”。

门店的选择支持多选功能。

门店具体的数据结构以及样例请参看附件：

“零售数据修改表结构及样例数据.xls”

3.2、门市管理模块

3.2.1、系统结构图

门店管理模块：

|门店档案管理|

||——门店档案编辑

||——门店档案审核

||——门店档案查询

3.2.2、门市档案数据设计

门店基础信息如下：

唯一标识一个门店的编号

门店名称，不可为空

门店的助记码，不可为空

门店所属的客户编号，不可为空

门店地址：

门店所在的地址，不可为空

门店电话：

门店的电话，不可为空

备注：

备注信息

状态：

0-未确认，1-有效，2-已封存，3-已删除，4-已修改，5-审核中，6-已作废，12-有效转封存，16-有效转作废，21-封存转有效，26-封存转作废。

不可为空

版本号：

已经生效的门店的信息再修改则需要将版本号加1，并且可以查询到之前版本的门店记录。

管理组织（审核用）：

将当前门店资料提交到审核流操作员所在的部门。

开始时间：

门店资料的建立时间，如果有新版本的记录，则以产生新版本的时间为建立时间。

该时间也为制单时间。

结束时间：

初始时该时间为3004-01-01，如果封存、作废操作则为当前时间。

启用则为3004-01-01。

预留字段1：

预留字段，将来可能用得着，数字类型。

预留字段2:

预留字段，将来可能用得着，文本类型。

预留字段3:

门店数据量目前大约在6万条左右。

为了数据的读取更高效，并且记录基础档案的修改轨迹，所以门店档案主要由以下三个表组成：

表名

可能存在的状态编号

market_edit

0，3，5，16,26,21,26

门店编辑表，用于编辑记录

market_hty

1，2，4，6

门店历史表，记录门店档案的修改轨迹,同一条记录的上一个版本XED置4，并且新加入一条与market_active中一样的记录。

market_active

1，2，6

门店有效记录表，

数据流向图：

数据操作具体业务：

具体表结构和示例数据请看附件“门店相关表及样例数据.xls”。

3.2.3、门市档案功能模块

3.2.3.1门店档案编辑

该功能完成门店档案的新增、保存、确认、删除、作废、封存、启用功能。

其中，只有新增和保存操作不需要提交到审核流，其它操作都需要提交到审核流，并由相关岗位的人员进行审核。

作废

1-有效，2-封存

16-有效转作废或26-封存转作废

封存

12-有效转封存

启用

2-封存

21-封存转有效

为了能跟踪每次对记录的修改，所以一个门店编号可能有几个版本号，不同版本的记录信息不尽相同。

以最高版本的那条为有效记录，其它记录状态为已修改（状态编码为4）。

删除、作废、封存、启用则不需要生成新版本。

编辑模块为了方便定位到某个门店，需要根据所属客户和门店名称进行查询。

该界面的效果可参考如下界面：

3.2.3.2门店档案审核

该功能提供给相关人员对门店档案的修改进行审核，如果审核通过，则执行审核操作，否则退回该单。

需要审核的单包括状态为5-审核中、12-有效转封存、16-有效转作废、21-封存转有效26-封存转作废的记录。

在终审后，各状态转换如下：

终审前

终审后

5-审核中

16-有效转作废

6-作废

26-封存转作废

审核模块为了方便定位到某个门店，需要根据所属客户和门店名称进行查询。

3.2.3.3门店档案查询

门店档案查询模块主要是对门店档案资料进行全面的查询，提供的查询条件应包含：

所属客户、门店名称、开始时间、截止时间、状态进行查询。

其中开始时间和截止时间是针对基础信息中的“开始时间”来说的，即“开始时间”界于查询的开始时间和截止时间。

查询的条件如果为空，则查询出所有门店。

可以查询的同时，提供根据条件EXCEL导出的功能。

该模块由于查询条件比较多，所以查询条件是在点击查询按钮后才弹出来。

3.2.3.4所属客户的选择

在门店档案的编辑和查询模块多处需要用到所属客户，所属客户的选择需要做得比较人性化和实现快速搜索的功能，目前客户的数据量在3万左右。

客户表结构参看附件“门店相关表及样例数据.xls”

4、开发进度计划

门店档案管理和零售数据修改两个模块，预计编码的工作量需要20个工作日（每周除去周六，周日）.

门店档案管理模块的开发工作计划：

零售数据修改模块的开发工作计划