企业批文审批系统设计与开发.docx
《企业批文审批系统设计与开发.docx》由会员分享，可在线阅读，更多相关《企业批文审批系统设计与开发.docx（35页珍藏版）》请在冰点文库上搜索。
企业批文审批系统设计与开发
企业批文审批系统设计与开发
摘要
一家大型企业的分公司对总公司的各种政策资源和各种费用预算的使用是通过申请批文流程来实现的。
批文是分公司向总公司的费用申请单，包括了物流费用，广告费用，政策资源费用等。
以前的情况是固定的审批流程，申请人先填写申请单据，然后在各个部门进行审批，结束审批了之后，然后财务部门拨出相应的款项。
缺点是审批所用时间较长，容易出错，审批的流程相对固定，不能灵活的改动。
本文描述了一个应用了三层C/S体系模式，使用C++语言和PL/SQL语言开发，使用了Oracle数据库，运用了关系数据库结构、面向对象技术、图形用户界面、网络通讯等信息产业成果，以现代管理思想为中心的软件系统。
数据完全按逻辑集成、实现客户化配置功能，并且在技术和应用上达到了很好的结合。
实现了批文从流程配置，批文的录入到批文的审批的整个流程，满足了客户的对批文审批业务的需求。
关键词：
C/S模式，Oracle数据库，MIDAS
DesignandDevelopmentofApprovalDocumentSystem
Author:
LiuXing
Tutor:
DaiMu-Hong
Abstract
Thevariouspoliciesofresourcesandthecostestimatesshouldbeusedinasubcompanyaftertheprocessofdocumentapprovetoitsparentcompany.Theapproveddocumentistheexpenseapplysheettotheparentcompany,includinglogisticscost,advertisementcost,policiesofresourcescostandsoon.There’sastaticapproveflowinthepast,afterfilledbytheapplier,thebillwillbeconfirmedinthedifferentdepartments.Thenthesubcompanywillgetthemoneyfromthefinancialdepartmentafterexamineandapprove.Thedefectisthatitwilltakealongtime,what’sworse,it’snotflexiblebecauseofthestaticworkflow.
Thepaperdescribeasystembasedonthemodernmanagement.It’sbuiltonthethree-layerC/Sarchitecture,usingC++andPL/SQLlanguagesandOracle10gdatabase.Italsouseobject-orientedtechnology,graphicaluserinterface,networkcommunications,andotherinformationindustryresults.Thesystemgetaexcellentunionbetweenthetechnologyandtheapplication,whichimplementstheworkflowfromthedocumentconfigurationtotheexamineandapproveandsatisfythecustomersintherequirementofthedocumentapproveoperation.
KeyWords：
C/S,Oracledatabase,MIDAS
1.绪论
1.1背景
一家大型企业的分公司向总公司申请各种政策资源和各种费用预算的使用是通过申请批文流程来实现的。
批文是分公司的部门向总公司的费用申请单，包括了物流费用，广告费用，政策资源费用等。
以前的情况是固定的审批流程，申请人先填写申请单据，然后在各个部门进行审批，结束审批了之后，然后财务部门拨出相应的款项。
缺点是审批所用时间较长，容易出错，出现错误后不易改正，审批的流程相对固定，不能灵活的改动。
随着企业规模的扩大，这种方式已经无法适应企业的需要，所以需要使用一套软件系统[1-5]来实现这个流程。
要求对整个流程有严密的监控和权限的控制它能够规范和监控各种政策资源和各种费用预算的使用情况，有着严密的权限控制。
并且能够灵活定义配置审批的方式和流程，能在在申请过程中控制批文金额来源和可以使用情况。
系统每天都需要处理相当多的数据，所以处理的速度和性能也有一定的要求。
1.2本文的结构
本文的其他章节如下：
第2章介绍系统的主要特点，用户需求以及开发环境。
第3章介绍系统的结构框架。
第4章介绍系统的主要流程，数据结构设计，以及界面设计。
第5章介绍系统实现所用到的主要技术。
2.批文审批系统简介
2.1系统特点
1安全性高，具有权限管理和数据管理机制与安全措施，禁止和预防非法用户访问程序和读取数据，每个模块的每个操作都有严格的权限控制。
2具有较高的实用性．坚持以用户实际需求为指导，在设计、开发、测试、应用过程中积极与用户沟通。
3操作简单、灵活，提供EXCEL文档导入和导出功能，充分利用原有EXCEL数据，以便加快录入速度，减少工作量。
4配置灵活，可扩展性好，可移植性好，基于组件的开发模式，可方便的添加、取消系统模块，基于权限改变用户菜单。
2.2系统的要求
1、数据来源控制：
在登陆批文信息时，金额的控制来源是预算和政策资源，但在批文设置时必须能设置批文审批流程是否金额控制。
2、批文审批过程控制：
批文审批流程分为固定审批流程（即审批人员和审批顺序是在设置批文审批流程时就配置好了）、半手动审批流程（即在配置批文审批流程时设置一个初始流程，审批过程中审批人可以修改后面审批人和审批顺序）和全手动审批流程（即在配置批文审批流程时配置好第一个审批人，由审批指定后面审批人审批顺序）；
审批操作包括提交和驳回：
提交时录入同意意见或不同意意见，如果是同意，则进入下一个审批环节，如果不同意，则停止审批流程（如果已经产生批文头单据，则同时关闭批文头单据）；驳回是可以驳回到已经审批的任何一个层次；提交和驳回都必须录入意见。
在审批过程中，必须设置审批人是否有权限修改批文内容。
在登陆批文时，必须把附件传到服务器上，在审批过程中审批人可以打开阅读；
批文紧急程度分：
“普通”、“一般”和“紧急”，审批过程能相应提示审批人。
3、审批结果：
在配置批文审批流程时就设置好到那个审批人就产生批文头单据，这个单据还不能使用，必须在整个批文审批完毕后才能使用。
当申请批文金额不够时，必须重新申请批文，在登陆时指定是附加到那个批文里面，在生成批文头单据时，和原批文批文头单据合并成一张批文头单据，系统记录单据明细。
可以使用批文单据根据不同批文类型进行处理：
市场费用批文单据录入批文行单据后，使用的是批文行单据，政策资源批文也是录入批文行单据，兑现时自动产生一张返利单据。
当批文金额使用剩余时，通过关闭批文单据来释放金额。
4、报表信息：
政策资源、预算批文使用明细：
政策资源、预算、批文申请金额、使用金额、未使用金额。
2.3开发实施环境及开发工具
硬件：
PC机
操作系统：
WindowsXP
数据库：
Oracle10g
服务器操作系统：
Windows2003Server
设计工具：
PowerDesign12
开发工具：
C++Builder6，PL/SQLDeveloper6
3.系统结构以及相关技术
3.1C/S系统模式
本系统主要运用于企业内部，而且数据量比较大，所以采用了CS的构架，数据库为Oracle10g[6-9]。
客户端使用C++Builder[10-11]开发，使用了DLL工程的形式实现各个模块，系统每次运行会自动检查相关模块版本，自动更新版本，所以克服了一般C/S模式更新麻烦的缺点。
客户端发出数据资源访问请求，服务器端将结果返回客户端，主要优点是能充分发挥客户端PC的处理能力，很多工作可以在客户端处理后再提交给服务器，这样做的优点就是服务器端负担轻，响应速度快，相对使用BS模式处理的效率更高，对权限的控制更加严密。
3.2三层的系统结构
三层体系结构[12-14]，是在客户端与数据库之间加入了一个“中间层”，也叫组件层。
这里所说的三层体系，不是指物理上的三层，不是简单地放置三台机器就是三层体系结构，也不仅仅有B/S应用才是三层体系结构，三层是指逻辑上的三层，即使这三个层放置到一台机器上。
三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层进行处理。
通常情况下，客户端不直接与数据库进行交互，而是通过COM/DCOM通讯与中间层建立连接，再经由中间层与数据库进行交互。
随着分布式对象技术的逐渐成熟，多层分布式应用体系结构得到了越来越多的应用。
在多层架构下，应用可以分布在不同的系统平台上，通过分布式技术实现异构平台间对象的相互通信。
将应用系统集成于分布式系统之上，能极大地提高系统的可扩展性。
在多层分布式应用中，在客户端和服务器之间加入了一层或多层应用服务程序，这种程序称为“应用服务器”。
将应用的商业逻辑放在中间层应用服务器上，把应用的业务逻辑与用户界面分开。
在保证客户端功能的前提下，为用户提供一个简洁的界面。
这意味着如果需要修改应用程序代码，只需要对中间层应用服务器进行修改，而不用修改成千上万的客户端应用程序。
从而使开发人员可以专注于应用系统核心业务逻辑的分析、设计和开发，简化了应用系统的开发、更新和升级工作
应用程序服务器
Application
Server（AS）
数据库服务器
DataBase
Managemet
Server（DBMS）
ADO/OLEDB
BDE/IDAPI
ODBC
客户端
Client
DCOM/COM+
MIDAS
图2-1三层的系统结构
如图2-1所示本系统包括了客户端，应用服务器，以及后台数据库三个层次。
客户端：
对数据的操作主要是在客户端进行，增加，删除，修改数据。
还有对用户的数据以及操作进行基本的验证和控制。
权限的判断也是在客户端进行，但是主要的业务逻辑是集中在数据库服务器中的相关存储过程过程中，客户端的相关事件触发调用数据库中的存储过程处理事物。
应用服务器：
接受客户端的请求，然后向数据库进行访问，再返回给客户端的请求，可以对数据进行筛选和过滤，拒绝一些不合法的数据和操作。
数据库服务器：
保存着业务的所有数据，以及相关业务逻辑的存储过程。
本系统三层结构的详细情况：
DBMS
AS
Client
ADO
MIDAS
图2-2系统三层结构的详细情况
3.3MIDAS技术介绍
早在1980年第一个数据库管理系统出现时，数据库的世纪就已悄然开始。
那时的观念是由应用程序控制关系型数据库，这种数据处理的模式一般称为单层结构（1－Tier）。
由于这种结构的数据库程序占用计算机资源较多，于是在80年代中期，数据库应用开始转向C/S结构，也就是所谓的两层结构（2－Tier）。
这种结构在近十年内不但得到了广泛的运用，而且相当成功。
然而，在两层C/S结构成功的背后却逐渐暴露出其构架上的缺陷。
其中最明显的问题表现在应用程序的伸缩性和维护方面。
例如，一个跨国企业如何把数据库管理系统及其应用程序分散到十分缓慢的网络上，如何控制数据的统一性和完整性；一旦应用程序有任何改动，维护人员就必须修改每一个客户端上的应用。
新一代数据库管理系统在传统的C/S结构中，增加了应用程序服务器――这种新的结构就是所谓的n－Tier或Multi－Tier。
应用程序服务器包括了统一的界面、业务规则的制定和数据处理逻辑的规定等等。
多层应用服务技术允许分割应用程序，本地计算机上无须安装一整套数据库工具，就可以在另一台机器上存取数据。
同时它允许对业务规则和进程进行集中管理，并在整个网络上分发、实现进程负载的动态调节。
众所周知，开发服务器级的应用程序要比开发单纯应用级的程序困难得多，有很多系统服务需要考虑。
如果没有一种好的工具，对于大多数程序员来说，开发一个复杂的多层结构应用只能是一种理想。
为了使这种理想方便地实现，Borland公司推出了开发多层结构所需的技术和工具集――MIDAS[15-18]。
MIDAS――多层分布式应用程序服务器，对MIDAS这个名字一般有两种理解。
MIDAS是Multi－tierDistributedApplicationServicesSuite（多层分布式应用程序服务包）的缩写，这也诠释了MIDAS技术的实质。
也许因为这个本义太长，很多人更愿意把它理解成Multi－tierMadeEasy，这也是MIDAS的作用。
多层计算（Multi－tieredcomputing）是业界对此类技术通用的术语，而Multi－tier是Borland公司采用的技术术语。
Borland典型的三层结构如下：
第一层是数据库服务器，第二层是应用服务器，第三层是瘦客户机。
数据库服务器是诸如InterBase、Oracle、Sybase、MSSQLServer等数据库，应用服务器和瘦客户机由Delphi建立。
大多数情况下，数据库访问软件（例如BDE,SQL＊NET等等）与应用服务器运行在同一台机器上。
应用服务器主要基于Borland的分布式数据技术，至少包括两方面的内容：
1.内置在Delphi组件中;
2.OLEnterprise产品对分布式计算和负载平衡提供超强的支持。
内置在Delphi组件中使你能很容易地使用DCOM、Socket或OLEnterprise连接两台机器，并在两者之间来回传输数据集。
OLEnterprise工具提供DCOM的选择方法简化了连接两台机器的任务，尤其是对两台运行Windows95的机器更是如此。
OLEnterprise使用户能访问ObjectBroker，它允许在几个服务器中随机分配任务负载。
此外，还可以在几台机器上装载服务器工具，每次实行连接时，Broker会选择其中一台机器。
例如，如果你有100个客户端和3台服务器，ObjectBroker会随机分配负载给3台服务器，每台服务器大约有33个客户端。
Broker会在服务器异常关闭时提供支持。
编写几行代码可以提供服务器错误处理，把客户端从出现问题的服务器切换到另一台正常运行的服务器。
另外Broker不会试图把一个新的客户端连接到已经关闭的服务器上，相反它会自动连接到其中一台正在运行的服务器上。
分布式数据集可以基于DCOM，在客户端没有任何数据库工具的情况下读取远程数据。
有些用户可能会有这样的疑问：
通过浏览器和Web服务器也能在客户端没有任何数据库工具的情况下观察远程机器上的数据集，为什么还要采用分布式数据集呢？
这是因为浏览器的功能远不如Borland分布式数据集的功能。
如果没有一种强大的第三方工具（如IntraBuilder），要增强浏览器的约束条件，或者在浏览器中加入或建立一个一到多的关系表是非常困难的。
但这些功能都可以在Delphi的多层应用程序中简单地实现，Delphi的编译应用程序比基于HTML的应用更快速、更易于应答。
分布式数据集允许在客户端的应用中使用所有标准的Delphi组件，包括数据库工具，但是客户端无须装载BDE、ODBC或者任何数据库类库（例如OracleSQL＊NET、SybaseCT－Lib等等）。
当然网络上的某些地方需要BDE或类似的引擎，但是客户端无须装载。
简言之，现在只需要一套服务器端的数据库工具，每一个客户端就可以使用它。
分布式数据集是缩减网络通信量的一种方法。
从服务器端下载数据后，在客户端操作数据而无须初始化任何网络交易，除非需要更改服务器端。
这意味着在不启动网络交易的情况下，可以编辑、插入、删除多个记录。
更改服务器数据时，可以在预先选定的时间段内把多个数据包送到网络上。
另外，当客户端从网络上断开时，仍然可以利用“briefcasemodel"访问数据。
其操作步骤如下：
先把一个远程数据库复制到磁盘上，然后关闭计算机，再重新引导它、断开网络连接、编辑数据，接着重新联网并修改数据库。
所有这些都可以在没有大型数据库工具的客户端完成。
这说明为了操作数据，客户端不必每时每刻都与服务器连接。
这对于膝上型计算机用户和想要保持数据库通信量最小的站点是非常理想的。
MIDAS技术的另一方面是提供访问数据库约束条件。
当从服务器上卸载数据时，可以同时卸载一套自动执行的约束条件。
约束条件可以帮助程序员确保用户输入合法的数据。
当重新连到网络上时，数据可以被正确地修改。
如果你在更改数据库时偶然发生了一个错误，那么内建的机制会帮助程序员报告和处理错误。
例如，如果另一个用户已经更改了你正试图更改的那条记录，那么你将看到一个提示你如何处理的选项表。
在DelphiObjectRepository中的一个预建表单可以使你的应用程序简单地实现错误处理。
Borland多层计算的另一个重要功能是将数据库的负载分散到多个服务器上。
这样，一旦发生错误也能恢复。
概括起来讲，这些技术存在于三种Broker中：
第一种叫做RemoteDataBroker，RemoteDataBroker结构的精髓是让每一个客户端不再需要BDE，取而代之的是一个中央化的BDE，以集中管理的方式降低每一个客户在BDE上所需的开销和复杂度。
第二种叫做ConstraintBroker，它所扮演的角色是保证所有客户数据的一致性及数据的完整性。
第三种是BusinessObjectBroker，它的目的是给一些关键性的商业应用程序提供一个快速且可信赖的使用环境。
为了满足这种高层次的要求，BusinessObjectBroker会自动地将应用程序做适当的划分，并复制重要的业务规则到每一个区间，以达到速度的要求。
Borland提供了四种Delphi工具帮助用户实现分布式数据集。
前两个在服务器端：
1.远程数据模块像标准数据模块一样，它不但可以将数据传播到当前的应用中，而且会传到网络上的特定区域中。
特别是它们把简单的数据模块转化成COM对象，允许你通过DCOM访问远程服务器上的数据库。
2.TProvider组件就像可以驻留在标准数据模块中的TTable组件一样，驻留在远程数据模块中，不同的是TProvider在网络上发布数据表。
TTable和TQuery组件都含有Provider属性。
但是如果把它作为一个独立的组件访问，会有更大的灵活性和力量。
特别是把TProvider组件与TTable或TQuery组件建立连接，网络上的其它程序就可通过DCOM从TTable或TQuery访问数据。
远程数据模块的任务就是使客户端访问服务器上特定的Provider。
在客户端可以利用两个组件访问服务器提供的数据：
1.TRemoteServer组件把客户端连到服务器上，特别是连到服务器的远程数据模块上。
更明确地说是连到远程数据模块支持的COM接口上。
TRemoteServer能浏览可用的服务器，一旦找到服务器，TRemoteServer就可与之连接。
2.TClientDataSet与TRemoteServer组件连接在一起，在服务器上就得到一个特定的Provider。
简言之，TClientDataSet组件扮演了与TQuery或TTable同样的角色，只不过它是为远程站点提供数据服务。
如同在许多标准的Delphi应用程序中传统TDatabase、TTable、TDataSource、TDBGrid组件的配置结构一样，在远程数据集中使用TRemoteServer、TClientDataSet、TDataSource和TDBGrid组件，它们的配置只是稍有不同。
在这个新的方案中，TRemoteServer的作用类似于TDatabase的作用，而TClientDataSet组件与TTable或TQuery组件所起的作用又极其相似。
结论
MIDAS为多层结构的应用开发提供了强大的功能，这使得开发者再也无需为越来越庞大的数据及应用发愁了。
在Delphi3.0Client/Server版中打包了MIDAS的开发版，它可以用于多层结构应用的开发及调试，其它开发工具如：
C＋＋Builder、JBuilder中也打包了MIDAS，以帮助用户用C＋＋、Java语言进行多层结构应用程序的开发。
4.系统流程及基本设计
4.1系统功能结构
批文审批系统
批文类型流程配置模块
批文类型配置
批文录入模块
批文审批模块
批文流程配置
部门于审批人关系配置
批文职责关系配置
批文录入
附件上传
批文审批
选择批文类型
图4-1系统功能结构
批文类型审批流程配置模块：
对批文的类型的基本信息进行管理，并且对批文类型对应的审批流程进行配置，还有对部门对审批人关系进行维护，以及批文职责关系的配置。
批文录入模块：
选择批文的类型，录入批文信息，上传附件。
批文审批模块：
对已经提交审批的批文进行审批。
4.2系统主要流程
如图4-2所示，批文审批系统的系统流程主要分为三大步骤，对应三个模块。
4.2.1批文类型审批流程的定义：
此步骤由系统的管理员来进行的，首先对批文类型和审批流程进行配置，配置内容包括批文类型的基本信息预算来源等信息，然后配置批文类型对应的审批流程，每个类型对应一个审批流程。
审批流程具有三种模式：
固定审批流程：
审批人员和审批顺序是在设置批文审批流程时就配置好了。
半手动审批流程：
在配置批文审批流程时设置一个初始流程，审批过程中审批人可以修改后面审批人和审批顺序。
全手动审批流程：
在配置批文审批流程时配置好第一个审批人，由审批指定后面审批人审批顺序。
批文登陆信息金额的控制统一来源于预算，配置批文类型时，选择预算来源后，根据预算类型方式确定那些字段是需要录入，登陆批文信息时，根据必须录入的字段信息从预算平台取得预算金额进行判断，配置批文时，可以设置是否进行金额控制标志，对于一些资源（如政策资源）统一在预算模块录入初始预算或预算追加。
系统其他相关的部门与审批人关系也是在此模块进行配置。
4.2.2批文的录入
这个步骤主要是各个分公司相关录入工作人员来进行。
首先选择批文的类型，录入批文的基本信息，然后录入批文的行信息。
保存之后系统自动根据批文类型所对应的流程初始化次批文的审批流程，并且状态变为送审
在登陆批文信息时，只是登陆主要的信息，其他都时已附件的形式上传到文件服务器上，在审批过程中，审批人可以打开附件进行阅读。
对于不同类型的批文提供附件模板供下载填写后上传到文件服务器上
4.2.3批文的审批
按照审批流程由各部门审批人员审批，同意则进入下一步骤。
不同意则停止批文的审批，将此批文作废，作废的批文可以由第二步的录入人员再次送审。
如果其中一步出现问题，可以使用驳回，驳回到指定的步骤，从该步骤开始重新进行审批。
通过最后一个审批步骤的批文，完成审批。
批文审批完毕后，系统自动产一张批文明细单据，由批文明细单据自动产生批文单据，批文明细单据可以合并成批文单据；
对于不同批文类型的批文单据去向根据需求建立不同模块处理，如政策资源模块产
升级会员 