食堂门禁一卡通业务需求.docxVIP

一卡通业务需求 需求部门：XXXX人事行政部 编写日期：2012年8月28日 编写部门：信息部 编写人：XXX XXX XXX 需求版本：(内部)1.1 版本修订 序号 日期 修订人 版本 内容 1 2012-8-27~2012-8-31 XXX 1.1 基础功能初稿 2 2012-9-3~2012-9-4 XXX 1.2 加入查询报表功能，校稿 3 4 5 6 7 8 9 第一部分一卡通食堂管理系统总体概要 1 前言 一卡通系统系指XXXX内部使用的综合系统，包括两部分，第一部分是食堂系统，第二部分是商管办公区门禁系统，通过统一发放管理ID卡，来实现餐饮和门禁的一张卡片管理，本需求只针对XXX内食堂卡管理业务需求上的描述分析，不涉及门禁系统业务需求。 2 目的 从行政部、财务部食堂管理实际需求出发，列出实际业务需求和管理上要求，以便厂商实际开发中以此需求为准，良好完成开发，制定出符合XXX食堂要求的应用系统软件。 3 开发要求 采用高级主流开发语言，要求采用微软.NET2005或更高版本开发程序，数据采用关系型数据库，要求采用的是SQLSERVER2008。系统开发需采取C S、B S混合开发模式，分食堂售饭客户端CS和食堂管理端BS两个独立程序。厂方在需提供源代码和数据库字典。 4 配置搭建 食堂处放置一台性能稳定PC机，厂家配置、培训运行环境搭建，安装食堂售饭客户端软件CS、SQLSERVER2008、读卡器；办公区多个部门安装食堂管理端BS程序。 5 报表要求 BS程序端事实数据产生的报表，在系统中需要按固定格式能导出EXCEL； 6 数据要求 所有界面涉及到系统已在使用中的数据不可删除，但可以做标识代表数据“删除”；数据在保存失败时能够按事务处理自动数据回滚。 第二部分一卡通食堂系统需求 食堂售饭客户端CS需求 101 主窗体背景图片 可自定义更换背景图片，能够自适应满窗体全屏应用。 102 主窗体光标 食堂售饭主窗体，只能有一处光标，该处为刷卡时显示卡号，只要是刷卡，就必须先清除编辑框内数据，显示新刷卡卡号。编辑框可以编辑，以便刷卡器或卡存在故障时，可手动输入卡号，窗体内任何编辑框都需要隐藏； 103 主窗体显示内容及要求 显示内容有：卡号、姓名、卡充值金额、本次消费额、卡余额、消费日期时间、刷卡提示（见105解释）、收银员（登陆人员）、系统日期时间（与系统时钟同步）。需要主窗体全屏显示，无窗体标题，隐藏任务栏（可借鉴视频播放全屏效果）。 104 刷卡消费 主窗体光标处，在刷卡后显示卡号，同时自动提取计算相关数据，刷卡记录需要保存数据明细（同时可考虑在“209月初卡单独、批量充值管理”中将卡余额计算出来，当然也可以不考虑此方式。）；刷卡器不可用时，可考虑手工输入，如果光标处手动输入卡号，则回车后自动提取计算相关数据，并保存系统数据。 105 刷卡提示 卡余额不足、冻结、注销、挂失等问题卡进行操作时需提示，拦截消费。卡消费成功、不成功进行提示；数据连接异常提示；数据保存失败提示；等等； 106 系统登录 有食堂CS端权限人员，使用账号密码登录系统。 107 开机自动启动、F4关闭程序 PC开机后，自动启动客户端程序。按键盘上F4键关闭食堂客户端CS系统； 食堂管理端BS需求 201 组织机构 可按业态部门进行组织机构基础数据搭建，采用二级目录划分即可。如：01 XX百货 01001信息部，02XX商管 01001信息部等等。要求第二级能够控制是否“使用”和“停用”。数据内容：编号、组织名称、备注、是否启用。调用时停用的组织机构将不显示。 202人员基础信息 对人员信息基本资料进行管理，数据内容：人员编号、人员姓名、所属部门、组织机构、性别、联系电话、职务、在岗状态（离职、在岗，信息维护录入时默认在岗）、备注。维护离岗人员在保存数据时，应对210功能中的状态进行“未绑”处理。 203 系统权限定义与人员管理账号权限管理 可定义不同岗位具有不同功能权限，系统可自定义。目前可分出纳、行政经理、食堂主管、财务主管等。数据内容：权限编号、权限名称、备注及拥有对应系统功能明细表、操作人、操作时间； 人员权限管理是为了登陆系统，提取岗位对应功能表单，通过选择人员信息，选择对应定义权限（可选择多个定义权限项），设定系统登陆密码、权限应用（前台、后台）、操作人、操作时间等基础项来搭建系统人员权限；可修改人员密码、人员定义权限项。人员权限前台CS不需要指定系统权限定义，后台BS需要指定系统权限定义。 204卡类定义 对所有卡进行分类，可自定义卡类。数据内容：卡类编号、卡类名称、此卡类对应金额、是否启用（分启用和停用）、备注。停用的卡类在维护卡信息时不可使用。 205卡信息维护 对卡信息进行维护，分单张卡处理、批量卡处理两个功能。 单张