酒店管理系统设计预案.docx
《酒店管理系统设计预案.docx》由会员分享，可在线阅读，更多相关《酒店管理系统设计预案.docx（15页珍藏版）》请在冰豆网上搜索。
酒店管理系统设计预案
⏹更多资料请访问.（.....）
c:
\iknow\docshare\data\cur_work\.....\
更多企业学院：
...../Shop/
《中小企业治理全能版》
183套讲座+89700份资料
...../Shop/40.shtml
《总经理、高层治理》
49套讲座+16388份资料
...../Shop/38.shtml
《中层治理学院》
46套讲座+6020份资料
...../Shop/39.shtml
《国学智慧、易经》
46套讲座
...../Shop/41.shtml
《人力资源学院》
56套讲座+27123份资料
...../Shop/44.shtml
《各时期职员培训学院》
77套讲座+324份资料
...../Shop/49.shtml
《职员治理企业学院》
67套讲座+8720份资料
...../Shop/42.shtml
《工厂生产治理学院》
52套讲座+13920份资料
...../Shop/43.shtml
《财务治理学院》
53套讲座+17945份资料
...../Shop/45.shtml
《销售经理学院》
56套讲座+14350份资料
...../Shop/46.shtml
《销售人员培训学院》
72套讲座+4879份资料
...../Shop/47.shtml
⏹更多资料请访问.（.....）
更多企业学院：
...../Shop/
《中小企业治理全能版》
183套讲座+89700份资料
...../Shop/40.shtml
《总经理、高层治理》
49套讲座+16388份资料
...../Shop/38.shtml
《中层治理学院》
46套讲座+6020份资料
...../Shop/39.shtml
《国学智慧、易经》
46套讲座
...../Shop/41.shtml
《人力资源学院》
56套讲座+27123份资料
...../Shop/44.shtml
《各时期职员培训学院》
77套讲座+324份资料
...../Shop/49.shtml
《职员治理企业学院》
67套讲座+8720份资料
...../Shop/42.shtml
《工厂生产治理学院》
52套讲座+13920份资料
...../Shop/43.shtml
《财务治理学院》
53套讲座+17945份资料
...../Shop/45.shtml
《销售经理学院》
56套讲座+14350份资料
...../Shop/46.shtml
《销售人员培训学院》
72套讲座+4879份资料
...../Shop/47.shtml
新天红东酒店治理系统
现
状
调
查
和
建
议
湖南省健坤科技信息技术有限公司
2010-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、运行环境
Ø数据库：
Oracle10g
Ø运行平台：
.NetFramework2.0
Ø开发工具：
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
VARCHAR2（40）
公司名
SALEDATE
DATE
销售日期
PRODUCTID
VARCHAR2（40）
产品编号
SALEQUANTITY
NUMBER（10）
销售数量
SALEROOM
NUMBER（10,4）
STAFFNO
VARCHAR2（40）
职员编号
SOURCETYPE
NUMBER
（1）
来源类型
NOTE
VARCHAR2（2000）
备注
CREATETIME
DATE
建立时刻
PRICE
NUMBER（10,4）
价格
ORGID
VARCHAR2（40）
部门编号
SYNC_STATUS
为0
SALEFTYPE
销售类型
需要关联的表数据：
依照MARKET_SHIPPER_INFO表的FEMP和MF_SALE表的STAFFNO关联出导购员的姓名，MARKET_SHIPPER_INFO的表结构如下：
字段名
类型
备注
ID
NUMBER（9,0）
唯一编号
FEMP
NUMBER（9,0）
MF_SALE的STAFFNO
FMARKET
NUMBER（9,0）
门店编号
FNAME
NVARCHAR2（50）
门店名称
XED
NUMBER（9,0）
状态
STIME
DATE
开始时刻
ETIME
DATE
结束时刻
FTIME
DATE
建立时刻
依照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-未确认
保存
0-未确认
0-未确认
确认
0-未确认
5-已确认
删除
0-未确认
3-删除
审核
5-已确认
1-有效
退回
5-已确认
0-未确认
编辑模块为了方便查看差不多修改过的明细记录，需要依照修改时生成的单号及所属客户进行查询。
客户的选择为单选方式，参见客户选择功能模块的讲明。
门店的选择为多选方式，参见门店选择功能模块的讲明。
界面布局可参考如下界面示例：
3.1.3.2零售数据修改审核
该功能提供给相关人员对零售数据的修改进行审核，假如审核通过，则执行审核操作，否则退回该单。
需要审核的单包括状态为5-审核中的记录。
在审核后，各状态转换如下：
操作方法
操作前的状态
操作后的状态
审核
5-已确认
1-有效
退回
5-已确认
0-未确认
审核模块为了方便查看差不多修改过的明细记录，需要依照修改时生成的单号及客户进行查询。
查询出来后显示符合条件的列表，在点击某条记录后能够单独查看该条记录的详细信息。
详细信息中包含主信息：
单号、客户、零售开始时刻、零售截止时刻、制单时刻、制单人、备注，明细列表信息为：
门店、导购员、产品、销售价格、销售日期、销售数量、销售类型、备注。
界面效果可参考如下界面：
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门店档案编辑
该功能完成门店档案的新增、保存、确认、删除、作废、封存、启用功能。
其中，只有新增和保存操作不需要提交到审核流，其它操作都需要提交到审核流，并由相关岗位的人员进行审核。
操作方法
操作前的状态
操作后的状态
新建
----
0-未确认
保存
0-未确认
0-未确认
确认
0-未确认
5-已确认
删除
0-未确认
3-删除
作废
1-有效，2-封存
16-有效转作废或26-封存转作废
封存
1-有效
12-有效转封存
启用
2-封存
21-封存转有效
为了能跟踪每次对记录的修改，因此一个门店编号可能有几个版本号，不同版本的记录信息不尽相同。
以最高版本的那条为有效记录，其它记录状态为已修改（状态编码为4）。
删除、作废、封存、启用则不需要生成新版本。
编辑模块为了方便定位到某个门店，需要依照所属客户和门店名称进行查询。
该界面的效果可参考如下界面：
3.2.3.2门店档案审核
该功能提供给相关人员对门店档案的修改进行审核，假如审核通过，则执行审核操作，否则退回该单。
需要审核的单包括状态为5-审核中、12-有效转封存、16-有效转作废、21-封存转有效26-封存转作废的记录。
在终审后，各状态转换如下：
终审前
终审后
5-审核中
1-有效
12-有效转封存
2-封存
16-有效转作废
6-作废
21-封存转有效
1-有效
26-封存转作废
6-作废
审核模块为了方便定位到某个门店，需要依照所属客户和门店名称进行查询。
查询出来后显示符合条件的列表，在点击某条记录后能够单独查看该条记录的详细信息。
界面效果可参考如下界面：
3.2.3.3门店档案查询
门店档案查询模块要紧是对门店档案资料进行全面的查询，提供的查询条件应包含：
所属客户、门店名称、开始时刻、截止时刻、状态进行查询。
其中开始时刻和截止时刻是针对基础信息中的“开始时刻”来讲的，即“开始时刻”界于查询的开始时刻和截止时刻。
查询的条件假如为空，则查询出所有门店。
查询出来后显示符合条件的列表，在点击某条记录后能够单独查看该条记录的详细信息。
能够查询的同时，提供依照条件EXCEL导出的功能。
界面效果可参考如下界面：
该模块由于查询条件比较多，因此查询条件是在点击查询按钮后才弹出来。
3.2.3.4所属客户的选择
在门店档案的编辑和查询模块多处需要用到所属客户，所属客户的选择需要做得比较人性化和实现快速搜索的功能，目前客户的数据量在3万左右。
客户的差不多信息如下：
Ø客户编号：
标识一个客户的编号。
Ø客户名称：
客户的名称。
Ø客户编码：
客户编码比较重要，同时是像客户编号一样唯一，由字母和数字组成，一般的用户都记住的是客户编码，名称倒不一定记得清晰。
Ø所属组织：
客户所属的组织，在客户查询时需要依照当前用户的可控业务组织权限取得可控的客户信息。
以上差不多信息中客户名称和客户编码需要在选择时给予显示，同时能够依照这两个字段的值进行模糊搜索。
显示上建议在文本控件输入能够像XX首页一样给出提示，并可选择，同时也能够依照文本框输入的内容进行过滤，弹出窗口供选择。
升级会员 