住宅专项维修资金管理系统方案.docx

住宅专项维修资金管理系统方案.docx

《住宅专项维修资金管理系统方案.docx》由会员分享，可在线阅读，更多相关《住宅专项维修资金管理系统方案.docx（41页珍藏版）》请在冰豆网上搜索。

住宅专项维修资金管理系统方案

一、相关背景

2003年6月8日，国务院颁布了第37９号中华人民共和国国务院令，《物业管理条例》自2０03年９月1日起正式施行,明确提出‘按照国家有关规定交纳专项维修资金’。

2007年12月4日,建设部、财政部联合发布第165号令,正式颁布了《住房专项维修资金管理办法》，并于２０08年2月正式施行。

《住房专项维修资金管理办法》对维修资的征缴、使用等均做了详细说明,将物业维修资金的管理提高到更高的法规层面。

在此之前，全国各地部分城市就本地区的发展现状,相继出台了各自的物业管理条例法规,其中关于专项维修资金的归集管理，各地也各不相同。

目前主要存在两种管理模式:

一是开发商代收代管，而后由成立的业主大会或业主委员会管理,二是政府主管部门集中监管,业主所有。

随着房地产业的发展及资金规模的不断扩大，传统的人工会计账册管理模式已难以应付,相关软件系统也应运而生。

二、产品简介

《毅成达住宅专项维修资金管理信息系统》（以下简称“本系统”）遵循‘统一归集、专户存储、专款专用、所有人决策、政府监督’的原则，融合了涉及商品房、房改房、二手房等多种性质房屋维修资金的管理,系统几乎涵盖了所有目前所能预见的各项业务，并提供方便的开发方法,以适应不同地区不同政策的需求。

本系统1.0版本于２00２年10月立项，03年底研发成功并在南京物业管理办公室试运行,0４年6月正式上线运行。

经过六年多不断完善,先后在江苏南京（包括浦口、江宁、六合、高淳、潥水十一区两县）、淮安（包括涟水、楚州、盱眙等三区四县）、安徽安庆、安徽天长、山东枣庄（包括腾州市、薛城区、台儿庄区、开发区三区一市）等近20家客户实施,目前系统运行稳定,管理的业主户数近２４0万,管理的资金规模达到100多亿。

目前已升级至３.0版本，包含B/S和C/Ｓ结构两种模式,为客户提供更多的选择空间。

三、技术方案

３.1系统建设原则

目前管理信息系统（MＩS）主要架构模式有B/Ｓ/S和C/S/S两种:

B/S／S（浏览器/应用服务器/数据库服务器）架构是目前运行于广域网内的管理系统普遍采用的系统架构，它的优点是无需安装系统客户端，只要安装了网页浏览器,如IE、FiｒeＦox、Maｘthｏn等即可,维护方便。

C/S/S（客户端/应用服务器／数据库服务器）架构主要用于局域网，它及传统的C/S两层结构不同，C/Ｓ／S是瘦客户端,只需简单的安装即可，无需复杂的环境配置，并可实现自动升级。

其最大的优点在于操作简便性及符合Wｉｎdｏｗs用户操作习惯。

对于需要大量输入、调用计算机外设的功能，C／Ｓ/S结构有着强大的优势。

我公司所开发的C／Ｓ/S结构平台,所有功能均是一个独立的插件，方便升级和维护。

并且所有查询结果均可进行标题排序、导出Exｃel、用Ｅxcｅl打开,并可实现快速记录定位,方便局域网内用户操作。

因此,在项目架构设计上，采用Ｃ／S／S及B/Ｓ/Ｓ模式共存的体系架构:

局域网内部用户可以使用C/Ｓ／Ｓ版本的功能，均可实现相同业务；对于广域网用户，则采用B/S／Ｓ版本的功能,实现远程登录系统进行业务处理，主要面对物业公司、业委会等分散在全市各地的用户。

在系统建设方面,我们坚持以下原则,确保系统安全、稳健:

☐冗余数据检验,保证数据安全准确。

从以下几个方面确保数据的安全:

1、业务处理各环节进行冗余数据检验及事务处理,在后台对数据进行逻辑校验，确保数据平衡；同时进行自动对帐及手工对帐，及时发现可能的问题并进行及时调整。

2、局域网用户只能通过软件客户端经中间件登录系统，用户无法直接连接数据库;用户登录密码采用加密方式存储,避免泄露;同时可对用户登录地址（IＰ地址或MＡC地址）进行绑定,防止恶意登录。

3、广域网用户通过浏览器登录时，采用认证机制访问,拒绝非法用户登录,保证系统不受恶意攻击。

4、数据库用户名及密码不定期变更，防止非法用户擅改数据。

☐通过角色分工及功能模块划分,实现多种管理模式。

针对不同的管理模式，设置多个角色，为每个角色定制不同的业务权限;并可针对不同管理模式下的相关业务单独设计开发功能模块。

这样，为相关操作用户授予不同的角色,该用户登录系统后将实现指定模式下的业务处理。

同一个用户可以设置多个角色，以实现在不同角色间的切换，完成不同模式下的业务处理。

☐界面人性化定制,使用高效简洁方便。

经过多年的MＩS系统实施经验总结，并结合用户反馈意见,系统从设计到研发,综合考虑了不同用户的操作习惯,业务界面简洁、方便、高效，并留有个性定制功能，方便用户定制符合自己操作习惯的系统设置，提高工作效率。

同时,将各种使用频率较高的功能集成所有界面中，方便用户导出、排序、查询、打印等。

☐预留系统接口,实现无缝对接。

本系统是一个开放的平台，可以扩展任何业务功能。

并可根据实际情况及其它软件，如财务软件进行数据交互（需该软件供应商支持）；也可扩展接口,实现及房产局信息平台的数据共享。

３．２系统实现思想

维修资金管理的需求以及运行的业务流程处于不断的变化之中,在系统的使用过程中,随着管理人员和业务人员信息化素质的提高以及管理和业务上的调整需要,不可避免地需要对现有系统的各种信息和业务规则进行调整和整合。

根据目前专项维修资金政府监管及业主大会自管相结合的管理模式要求，本系统的整体设计在一开始就充分考虑到系统在近期和将来的变化，应是逐渐由政府监管向业主大会自管进行过渡,系统能够在发生变化时从容地实现变化的要求。

系统除了需要考虑业务需求的变化,而且还要考虑由用户层面及数据的增加，所带来的硬件环境和网络环境的变化。

随着业务量和数据量的增加，系统对硬件环境的要求也会增加。

当前系统的开发需要考虑目前硬件环境、和将来硬件环境和网络环境升级时，系统能够无缝地移植到新的环境中,即系统是建筑在跨平台的运行环境之上的。

鉴于上述分析，本系统的实现思想遵循以下几项原则：

☐安全性

安全是系统稳定运行的首要保证。

本系统采用三层体系结构，及数据库的连接受到严格控制;用户登录密码加密传输,加密存储;支技ＩP绑定登录;外网用户数字认证登录等严格安全措施,确保数据安全。

☐统一性

对维修资金管理中涉及的不同管理对象、管理模式、管理层级进行整体方案的统一规划、统一标准、统一设计,使得用户在同一个操作平台之下即可完成不同的业务功能。

☐先进性

充分利用当前流行的操作系统、数据库、网络通讯、服务器、客户机、中间件的最新、成熟的技术成果,转化到系统的具体实现中去，发挥软硬件的最大效能。

☐实用性

在保证业务功能的准确性前提下，提高业务操作的实用性，增加了排序、导出、查询、打印、过滤、定制样式等等实用功能,为日常操作提高了效率。

☐灵活性

维修资金管理工作具有很强的政策性，并且及相关环节联系密切。

一旦政策发生变化或上下游环节发生调整,势必影响系统的动行。

因此，系统应具备很强的灵活性。

本系统的灵活性体现在MVＣ的结构设计及插件化、模块化的功能设计,这样局部的调整或后台业务的调整对整个系统几乎没有影响,功能的扩展上则更加便捷。

3.3系统网络拓扑图

本系统设计的使用对象涵盖包括局信息中心或上级主管领导、市级资金管理部门、区级资金管理部门、业主委员会、售房单位、建设单位、物管单位、专户银行、购房人或业主等使用对象，分布范围广，因此要求系统不能完全运行于局域网内，而要形成一个基于公网的开放式平台。

鉴于上述情况，系统的网络拓扑图如下所示:

当然，根据各地的管理规模和实际情况,仅需要‘中心子系统’即可实现当前的工作需要,其它部分可根据实际发展情况进行增加扩展，而不会有任何影响。

３．４系统关键技术

●J2EE技术

J２ＥE是SUN公司提出的在分布式环境中的一种体系结构,它提供了一种基于组件的设计、开发、集成、部署企业应用系统的方法,Ｊ2EE平台提供了多层分布式的应用系统模型、重用组件的能力、统一的安全模型和灵活的事务控制。

基于组件的Ｊ2EE企业应用系统具有平台独立性,所以不受任何软件产品和任何软件厂家AＰI的约束。

Ｊ２EＥ定义了下面的组件：

ﻫ·Apｐlicａtionｃｌienｔ和portｌｅtｓ　是客户层组件

·JavａＳｅrvlet和JSＰ组件是ＷEB层组件ﻫ·EnterpriseJａvａBeａｎ（ＥJＢ）组件是业务处理层组件

●MＶＣ设计模式

MVＣ设计模式将项目分解为模型（Modｅl）、视图（Vｉeｗ）和控制（Contｒｏｌ）三部分。

其中“模型”是完成任务的代码;“视图”既是表达界面;“控制器”则控制着模型和视图之间的交互过程。

三者之间的关系如下图所示。

MＶＣ设计模式

客户端浏览器提交请求给服务器的“控制器”;“控制器”根据系统的配置选择相应的“模型”；“模型”完成处理数据的任务和生成“视图”的任务；“视图”则返回客户端更新浏览器的内容。

由此完成一个操作。

MVC设计模式实现了应用的业务逻辑封装，规范了基于JSP/Servｌet的Ｗeb应用开发。

维修资金管理系统将采用跨平台的J2EE技术架构。

随着业务的发展或企业ＩT环境的整合，维修资金管理系统能够随时根据业务需要移植到其他的操作系统，譬如Windows、Liｎux、ＳUNSｏlaｒis、HP　ＵＸ等。

建筑在J２ＥE技术架构上的应用系统提供了这种可能性。

维修资金管理系统的系统整体框架如下图所示。

系统架构

对系统的操作则通过台式机或笔记本的浏览器，以ＨTTP/ＨＴTPS协议连接到服务器上。

服务器上的用户操作界面使用目前流行的JSP格式。

但维修资金管理系统的JSP有两个特殊的要求：

1）严格使用MVＣ模式;2）直接集成到企业信息门户（ＥIP）中。

为将来整个企业应用系统的深度集成作好准备。

维修资金管理系统B/Ｓ部分将使用Java开发，并遵从J2EE技术架构。

应用服务器可以考虑使用WebLｏgic、WebSpheｒe、Tomcat、JBoss等。

维修资金管理系统运行在应用服务器上,并通过应用服务器及数据库连接。

维修资金管理系统是一个基于业务流程管理思想的软件应用系统。

在确定的组织模型下，以业务流程引擎为驱动实现具体的业务流程。

维修资金管理系统将其他应用系统、应用子系统、应用模块作为同等对待。

也就是说系统本身是一个小范围的“系统集成”，如下图所示。

功能架构

应用模块之间或应用子系统之间可能会发生相互调用。

3.5业务功能

经过近七年的不断完善和经验总结，《毅成达维修资金管理信息系统》从功能上逐渐形成如上图所示的标准配置功能列表，基本涵盖了大多数维修资金管理的涉及的业务功能,并可根据实际工作情况适当调整，形成客户化、本地化的一整套完整解决方案。

具体的业务功能设计，在秉承老版本系统的业务功能划分的基础上,新版本在简化操作流程、增加实用功能、提高运行效率等方面做了很大改进。

新版本C／S结构部分功能模块如下所述：

３.５．１前台业务

1、房屋登记

房屋登记,包括数据导入和分户录入两种方式。

数据导入:

通过及共享平台的接口，将测绘楼盘表直接加载到本系统，作为缴存维修资金的依据；或使用标准格式的Excel录入后再导入系统；单机版的开发商代缴子系统,由开发商代收代缴,然后导入系统等多种导入模式和方法。

分户录入：

是指在本系统建立的楼盘表中，根据业主提供的测绘图,手工录入新的分户信息，作为缴存维修资金的依据。

对于已存在的房屋信息,可以进行修改、删除、导出、查询等操作。

支持纸质资料的扫描存档、拍照存档及回调查询功能;

支持直接将房屋信息拖放到指定结点，实现关联关系的建立,如将下图列表已经选中的１00条记录，直接拖放到左边树状菜单的某个小区、或某个建设单位,该100条房屋信息将自动建立及该小区或建设单位的关联关系,高效方便。

2、业主缴存

房屋登记时可选择录入的同时进行缴存。

对于已录入或从接口中已加载的房屋，可以进行单个缴存、批量缴存、多样付款、续筹缴存等缴存业务。

缴存时根据缴存时间,自动取得缴费比例及计算方式,计算出业主和单位应缴金额，录入实缴金额、缴费方式（现金、支票、银联）、凭证号码等,生成缴存流水记录。

对于未到帐的缴存流水可以取消、重新缴存、补打印等。

缴存比例（缴交标准）可由系统参数设置，并可按时间段分别计算。

3、单位缴存

对于需要单位（建设单位或售房单位）缴存的房屋信息，系统显示所有应缴未缴的记录，由单位选择指定范围进行缴存,生成缴存流水记录。

可实现单独缴存、批量缴存、全部缴存等多种缴存模式。

对于未到帐的缴存流水可以取消、重新缴存、补打印等。

4、缴存复核

复核柜员对未复核的缴存流水记录进行复核，并打印票据。

只有复核过的缴存流水才可进行日终批处理。

5、支票确认

对于使用支票或银联卡进行缴费的流水,需要对使用的支票号或银行卡号进行使用确认，否则使用该支票的所有缴存流水将无法进行日终批量处理。

经确认后的支票号，会产生一条发送银行的确认信息，由银行确认支票的实际到帐日期。

6、退多补差

当发生缴存面积或实收房款及缴存时的面积或房款有差额时,相应的维修资金应缴金额也将发生变化,此时,业主可凭相关证明进行退款或补缴。

此业务应先由后台发起‘补差申请’,生成退款或补缴流水记录后方可进行退款或补缴操作。

前台柜员选择退款或补缴的流水记录进行复核并打印票据,并将差额退还给业主或向业主补收差额。

7、销户退款

当房屋发生灭失或拆迁等情况时，可将已缴维修资金帐户余额提取，将该业主户销户处理。

此业务应先由后台发起‘销户申请’及‘销户审核’，生成退款流水记录后方可进行退款操作。

前台柜员选择销户退款的流水记录进行复核并打印票据,并将退款金额退还业主。

8、日结单查询

查询并汇总前台缴存柜员当天的收款情况，打印后交由财务，作为物业处及银行进行对帐的依据。

３．5.２后台业务

1、补差申请

由于实测面积及缴存面积不符或其它原因造成的缴存金额不符,可以对已缴存金额进行修改，退缴或补缴差额,生成退款或补缴流水记录,作为前台退多补差操作的依据，前台用户通过‘退多补差’功能，对流水进行实际给付操作。

2、销户申请

对于因拆迁、退房、房屋灭失等情况，将已缴存的维修资金余额进行退还，并对该房屋进行注销处理。

可以精确指定某个业主销户,也可针对指定范围（如某幢楼所有业主）进行销户申请。

销户退款可选择只退本金及本息退款，如果选择只退本金，则将业主利息金额从本4金户转至结算户。

申请用户可撤消销户申请。

销户申请成功后产生一条销户退款业务流水,需经‘销户审核’，可能包括财务审核及领导审核二级审核流程,然后才可以在前台通过‘销户退款’进行退款操作。

3、销户审核

对销户退款申请流水进行审核,包括财务审核及领导审核。

财务审核用以确认退款银行、退款方式；领导审核为最终审核,只有经过领导审核的销户流水，才可从前台进行退款操作。

4、资金使用

使用单位,如业委会或售房单位,提出使用申请,资金管理部门对使用要件进行人工审核，审核通过后，进行案件登记,生成案件编号；为使用单位编制楼幢关系,并记录票权信息;对登记案件进行业务审核，主要是对票权及要件是否符合使用要求，对于符合要求的,并提交入库,进行金额分摊,打印使用单、分摊明细等；业务科室对案件进行初审,审核通过，进入领导审核环节;领导对初审通过的案件进行审核，审核通过的案件可以进入下一环节,审核驳回的案件则返回上一环节；财务部门对审核通过的案件,进行划账操作；已划转确认的数据发送到银行端进行确认；银行将指定金额划拨到使用单位开设的指定账户后对划拨数据进行确认，并将数据返回到中心数据库;中心数据库经日终批处理后,扣减相关业主账户。

使用申请时可选择一次性划拨，也可选择分两次划拨;分两次划拨情况下,首款划拨为审批金额的70％（由系统参数设置确定），尾款为审批金额的30％。

当尾款划拨申请时,工程决算金额及首款申请金额不符时,应以决算金额重新计算分摊金额，此时尾款金额将不再是审批金额的30％。

各业主所分摊金额也将发生相应变化。

要件录入时，应提供两种方式:

直接扫描档案文件入库方式和加载图像文件入库方式，并可方便回调查看。

分摊计算时，以业主实测面积作为分摊依据。

分摊方式也有两种：

留存比分摊和余额分摊。

留存比分摊：

是指以该业主当前余额扣除应留存的金额为限参及分摊,如果分摊金额大于可用金额，则超出部分需用现金参及分摊;

余额分摊:

是指以该业主当前余额为限参及分摊，如果分摊金额大于当前余额,是超出部分需用现金参及分摊。

首款申请流程

尾款申请流程

5、委托增值

根据最新的《住宅专项维修资金管理办法》，“业主大会成立后，应当按照下列规定划转业主交存的住宅专项维修资金：

（一）业主大会应当委托所在地一家商业银行作为本物业管理区域内住宅专项维修资金的专户管理银行，并在专户管理银行开立住宅专项维修资金专户。

”对于此种情况，业主大会可对其账户中的维修资金进行相应增值操作，由专户管理银行为其增值金额进行计息及划转。

本系统对增值收益按指定范围进行分摊到相关业主。

对于未成立业主大会的物业小区，可以向资金管理部门（市物业办或区局管理部门）申请委托增值。

管理部门对申请单位提供的要件进行人工审核,审核通过后，进行案件登记,生成案件编号;为申请单位编制楼幢关系，并记录票权信息；对登记案件进行业务审核，主要是对票权及要件是否符合使用要求，对于符合要求的,并提交入库，进行金额分摊,打印申请使用单、分摊明细等;业务科室对案件进行初审，审核通过，进入领导审核环节;区局领导对初审通过的案件进行审核,审核通过的案件可以进入下一环节，审核驳回的案件则返回上一环节；市级管理部门对审核通过的案件，进行划账操作;经日终批处理后，为申请单位生成增值记录,并扣减相关业主账户余额。

委托增值到期后,系统根据申请时所选择的到期处理类型（到期自动转存、到期转活期），在日终批处理时自动执行相应操作。

对于到期自动转存,自动生成一笔新的增值记录，将到期利息生成一笔息入本划转申请;对于到期转为活期,自动将本金回存到相关业主,计算积数,同时将到期利息生成一笔息入本划转申请；对息入本划转申请进行财务审核及领导审核后,经日终批处理后发送至相关银行,由银行进行实际划转操作，并回填划转日期等信息。

再经日终批处理后，将利息金额增加到相关业主账户中，并计算利息积数。

增值申请处理流程

增值到期处理流程

6、缴存补录

对于因特殊原因未能及时缴存并打印票据而手工开据票据的情况,可通过补登功能，将缴存单据补录到系统中,记录票据号、到帐日期等,经日终处理后，修改对应业主账户余额并计算利息积数。

7、年终结息

业主明细账户中的可用余额，应于每年年末（１2月20日）进行活期计息。

活期计息的计息金额为业主账户实际余额中扣减委托增值部分的金额,按照积数计息法计算活期利息。

计息计算成功后,系统按各业主的开户银行,自动生成多笔息入本划转申请记录;对息入本划转申请进行财务审核及领导审核后,经日终批处理后发送至相关银行,由银行进行实际划转操作，并回填划转日期等信息。

再经日终批处理后，将利息金额增加到相关业主账户中，并计算利息积数。

8、利息分摊

根据《物权法》及《住宅专项维修资金管理办法》相关规定,资金专户增值部分也属全体业主所有。

因此，对于因一级账户增值而产生的利息扣除委托增值和年终活期计息以及其它可扣除费用后的利息余额，应向全体业主进行分摊。

该功能可选择提取部分金额、对选定范围业主进行分摊。

9、房屋分户、并户、过户

分户:

是指在信息录入时无法确定明细信息而作为一个整体录入，后发现可提供明细信息,因此可将该整体拆分成N个明细房屋记录。

拆分时，对当前账户余额根据面积所占比例进行相应拆分,并计算利息积数。

并户：

是指对于特殊原因分别录入的房屋信息进行合并成一条房屋信息。

并户时先对合并的各房屋分别计算积数，合并时,将当前余额、利息积数汇总后转入合并目标房屋账户。

过户：

是指产权人发生变更时的修改,无需重新计算积数。

10、单位开户、合并、分立

开户：

业委会或售房单位申请资金使用，或业委会自管时,均要在指定银行开设二级结算户。

系统生成开户申请并打印开户申请单，将开户申请发送至银行,由银行进行开户确认，并将开户日期、银行账号等信息回传至中心,完成开户处理。

合并：

将当前单位所属房屋合并到目标单位;对于开设二级账户的业委会或售房单位的合并,还将涉及账户划转，系统生成二级账户划转申请，划转申请经财务审核后发送到银行,由银行进行划转操作,并将划转日期等信息回传到中心，完成合并处理。

分立：

将当前单位所属房屋中选择的范围分立到目标单位;对于开设二级账户的业委会或售房单位的分立，还将涉及账户划转,系统生成二级账户划转申请，划转申请经财务审核后发送到银行，由银行进行划转操作，并将划转日期等信息回传到中心,完成合并处理。

11、领导审核

根据管理模式要求,对需要进行领导审核的业务环节进行审核处理，以便进入下一业务流程。

如资金使用审核、资金专户取款审核等。

具体审核的业务可由系统定制。

３.5.3财务管理

1、资金专户管理

资金专户是指资金管理部门在各银行开设的一级专户,包括本金户和结算户（利息户）。

本金户用以管理所有房屋明细户的账户余额。

本金必须保证及房屋明细户余额完全相等。

结算户用以管理本金户产生的利息以及结算户产生的利息，并负责划转为业主计算的活期利息及委托增值到期利息。

专户管理内容包括：

活期转定期、活期购买国债、各专户间的划转、存取款、流水明细查询等

2、增值卡片管理

用于管理各专户银行本金户和结算户的资金存定、购买国债情况。

反映各增值卡片的存款银行、金额、存期、到期日期、到期利息等，并可根据系统设置在到期前N天给出提示；对未到期增值卡片可提前转活;可对各类账户分类查询（银行、本金户、结算户）

3、支票信息管理

对缴存时使用的支票信息进行查询及维护,如换票处理。

4、专户财务审核

根据管理模式要求,对需要进行财务领导审核的业务环节进行审核处理，以便进入下一业务流程。

如资金专户存取款审核、资金划转审核等。

具体审核的业务可由系统定制。

5、资金使用划拨

对审核通过的资金使用申请进行划拨，指定划拨银行,生成划拨指令,发送给相关银行，由银行进行实际划拨。

6、二级账户划拨

　对开设二级账户的业委会或售房单位进行资金划拨，将该业委会或售房单位虚拟账户上的余额划转到指定银行的指定账户中，生成划拨指令，发送给相关银行,由银行进行实际划拨。

7、银行专户对帐

管理部门及各专户银行账户进行余额对帐及流水对帐,及时发现问题并解决。

8、银行账户管理

对各专户银行账户进行管理,如新开专户账号设置、账号变更修改等。

9、柜员票号管理

对前台收款柜员领用收据票号进行设置，防止随便输入票据号码，并可实现票据的跟踪管理。

10、会计凭证生成

　　根据设定的会计科目，自动生成会计凭证,并按标准记账凭证格式打印会计凭证，减少财会人员填制记账凭证工作量。

3.5.4系统管理

1、系统部件发布

系统部件是指构成整个系统的各个子程序、功能模块文件、报表文件、控件包、动态库等。

当业务功能发生变化,相应的功能部件也要进行升级，经过测试的功能部件使用系统部件发布功能注册到数据库，用户登录时将会自动升级,无需系统管理员进行手工升级客户端软件。

2、角色权限定义

角色是指系统用户的职责分类。

可对系统用户按职责或业务部门分类，如‘缴存柜员’角色。

可对角色进行权限定义及菜单定制，这样当某个系统用户属于该角色时,将自动获得该角色所有权限,无需对各个用户单独授权。

3、用户权限设置

增加系统用户、为系统用户授权。

用户权限可精确到菜单、按钮或任何界面对象，方更灵活。

4、用户日志查询

对系统用户所有操作日志进行查询、导出、备份、清除。

5、日终批量处理