具体实施方式
一总体架构
本发明的利用数据库(database)及网页来实现基于浏览器(browser)的ISO文件发行管理系统采用浏览器/应用服务(application service)/数据库的三层架构,用以让公司内部人员进行ISO文件的申请及审核动作,摆脱以前人工化的ISO文件管理方法。系统平台为Windows NT/2000服务器(server)、互联网信息(Internet information)服务器及结构化查询语言(structured query language,SQL)服务器,客户(client)端为Internet Explorer 4.0以上,且自己架构的服务(service)为文件发行系统服务。其他相关子系统是为了结合公司内部的资源而弹性设立,例如人事管理系统是为了取得当前用户的行政组织关系和姓名等人事资料;PDPM管理系统是为了项目文件需要取得项目的项目主管及项目人员信息。
另外,ISO文件发行管理系统系统包括文件管理、工作流程、群组管理、代理人制度等核心模块,分述如下:
二、文件管理
企业内部在经营管理、项目开发中会产生许多ISO文件,诸如品质手册、作业程序等,这些文件都需要得到有效管制,即在文件发行前需经过适当的审查及核准。文件管理目的在于:
(a)实现ISO文件申请表格和附属文件电子化。
(b)使新文件发行、文件变更、文件作废、文件追加申请等电子化的申请过程与实际的文件发行作业流程相一致。
(c)将文件分类便于以发行文件的分类检索。
(d)对已发行文件做到权限管制。
(e)实现已发行文件的备份功能。
所以,文件管理包括文件申请及处理、文件发行后的检索、文件备份。
以文件申请及处理而言,文件在发行前是以文件需求单电子表格的形式在企业网络内部传递。为了妥善管理此些电子表格,本发明需要在数据库中设计如下表格:
(a)表单类型信息表(P_FormInfoTab):记录文件需求单电子表格信息。
栏位 |
描述 |
FormID |
表格类型的唯一标识int型 |
FormNo |
表格编号char()型 |
FormName |
表格中文名称char()型 |
FormVersion |
版本号char()型 |
(b)文件需求单信息表(F_DCT_MainTab):储存用户申请的每一笔文件需求单记录信息。
栏位 |
描述 |
RecordID |
表格记录的唯一标识int型 |
FormID |
对应的表格类型IDint型 |
Title |
文件标题Char()型 |
DocType |
文件类型,对应文件类型表DocTypeID。int型 |
DocNo |
文件编号Char()型 |
ApplyType |
文件申请类型取值为1、2、3、4。1:新文件申请。2:文件变更申请。3:文件作废申请。4:文件追加申请。 |
Departname |
申请部门char型 |
FillUserID |
填写人Int型 |
ApplyDate |
填写日期datetime型 |
AttachNum |
附件数目int型 |
Reason |
申请理由varchar()型 |
DocVer |
文件版本char()型 |
(c)附件表(F_DCT_AttachTab):具体的文件内容是保存在附件中,此表记录了申请者上载的文件信息。
AttachID |
上载文件记录的唯一标识int型 |
FormID |
对应的表格类型IDint型 |
RecordID |
对应的表格记录IDint型 |
FileName |
文件档名称char()型 |
FileSize |
文件档大小int型 |
FileType |
文件档类型char()型 |
Description |
上载说明char()型 |
UploadTime |
上载时间datetime型 |
UserID |
申请人int型 |
IP |
申请人上载文件时的IP地址Char()型 |
以文件发行后的检索而言,文件一旦发行成功,便需产生一文件信息记录保存在文件信息表中,以利于文件检索。另外,由于不同用户对于某一各文件具有不同的浏览权,这时需要设计权限表来设置用户的浏览权。
(a)文件信息表(F_DCT_DocInfoTab):记录已发行成功的文件信息,供用户检索。
栏位 |
描述 |
RecordID |
文件记录的唯一标识,与文件需求单RecordID相同。int型 |
StoreType |
文件的储存类型,取值为1、2、3、4。1:新版。2:旧版。3:作废。4:销毁。 |
Title |
文件标题char()型 |
DocType |
文件类型int型 |
DocNo |
文件编号char()型 |
Description |
一些描述和说明varchar(型) |
AttachNum |
附件数目int型 |
IssueDate |
发行日期datetime型 |
DocVer |
发行文件的版本char()型 |
(b)文件归属表(F_DCT_DocOwnerTab):设置文件归属的浏览权限类型、专案和特殊人员。
栏位 |
描述 |
RecordID |
对应文件记录IDint型 |
LtypeID |
对应的文件浏览权限类型表的LtypeIDint型 |
ProjectID |
若为项目文件,此为对应的专案ID。int型 |
SpecialPerson |
特殊人员,此栏位可单独为某些人员设定浏览权限char()型(格式:″UserID1,UserID2,UserID3…″) |
以文件备份而言,文件备份包括数据库备份和按照文件信息表、附件表将所有服务器上的文件复制至指定备份路径中。
三、工作流程
[工作流程设计目的]
流程设计须符合实际工作流程步骤的要求,实现文件发行的申请、签核、办理、结案归档、电子信件(email)通知等一系列过程全部自动完成。
[工作流程的定义和实现]
工作流程的设计是采用数据库的方式来表示文件需求单的签核过程、目前处于何种状态以及下一步将流传至谁。每份文件需求单都需经过若干步骤的签核,这个签核过程由文件需求单流程表来反映。为了能快速取得文件需求单目前处于何种状态、当前处理者,则需要设计一文件需求单状态表来表示。每一份电子表格在被申请之后,会得到文件需求单类型号(FormID)和文件需求单记录号(RecordID),以唯一标示此文件需求单。
系统在文件需求单流传的每一步记录下相关信息来反映文件需求单流程过程。其具体数据结构定义如下:
(a)文件需求单状态表(P_FormStatusTab):保存文件需求单在当前流程中的重要信息。
栏位 |
描述 |
FormID |
对应文件需求单类型表的文件需求单类型IDint型 |
RecordID |
对应具体文件需求单的文件需求单记录IDint型 |
UserID |
文件需求单申请者IDint型 |
DealUserID |
文件需求单当前处理者IDint型 |
StatusID |
文件需求单当前状态值。101:待处理。104:驳回结束。105:收回结束。106:退回结束。107:结案完毕。int型 |
Subject |
文件需求单主题 |
ApplyDate |
申请时间 |
通过查询文件需求单状态表(条件是用户ID=DealUserID和StatusID=101),即可取得目前需要用户处理的文件需求单记录号和相应的文件需求单状态。通过查询文件需求单状态表(条件是用户ID=UserID),即可取得目前用户自己申请的文件需求单记录号和相应的文件需求单状态。
(b)流程模板表(P_FlowTemplateTab):规定文件需求单签核时的流程步骤,确定流程每一步的处理群组。
栏位 |
描述 |
TemplateID |
模板号的唯一标识int型 |
CurrStage |
当前关指针,CurrStage=0时代表此关是第一步申请者填写表格。int型 |
NextStage |
下一关指针,指向下一关的CurrStage。NextStage=-1时代表此关之下一关将结束流程。int型 |
BackStage |
可退签的关指针,数据格式:(stage1,ststage2,...,stagen)。varchar型 |
CheckerName |
签核者/群组名称char型 |
GroupID |
若处理人员为群组,此处保存对应群组表的群组。int型 |
IslogicFroup |
布尔型,取0表示上述GroupID存放的是固定群组。 |
extraDeal |
具体反映此关将做何处理,如申请、签核、办理这些处理对于流程来说,都是将文件需求单流传至下一个处理人,只是在某些场合需要做特制化的处理。char型 |
(c)流程记录表(P_ActFlowTab):记录下各关处理人员的处理意见,指导流程将文件需求单传至下一关某一特定人员。
栏位 |
描述 |
FlowID |
流程记录的唯一标识int型 |
FormID |
对应文件需求单类型表的文件需求单类型IDint型 |
RecordID |
对应具体文件需求单的文件需求单记录IDint型 |
TempleateID |
对应流程模板表的模板IDint型 |
CurrStage |
当前关指针char型 |
NextSage |
下一端指针,指向下一关的CurrStage。int型 |
BackStage |
可退签的关指针,数据格式:(stage1,ststage2,...,stagen)。varchar()型 |
CheckerName |
签核者/群组名称char型 |
GroupID |
若处理人员为群组,此处保存对应群组表的群组。int型 |
IsLogicGroup |
布尔型,取0表示上述GroupID存放的是固定群组,取1表示上述GroupID存放的是逻辑群组GroupID。 |
extraDeal |
具体反映此关将做何处理,如申请、签核、办理这些处理对于流程来说,都是将文件需求单流传至下一个处理人,只是在某些场合需要做特制化的处理。char()型 |
ActionType |
处理人的处理动作。101:提交。102:同意。103:不同意。104:收回。105:退件。109:删除。int型 |
ActionID |
处理人的人事IDint型 |
ActionDateTime |
处理人执行处理动作时的时间datetime型 |
IP |
处理动作时的IP地址,便于事后追查处理人的真实性。char型 |
OriginUserID |
原先处理者int型 |
Instruct |
处理意见varchar()型 |
流程模板表与流程记录表区别在于:流程模板表指规定文件需求单基本的通用的流程过程,而流程记录表反映某一份文件需求单的实际的流程记录。
流程记录表起两个作用:第一、记载了文件需求单各关处理者的处理信息,这在用户调阅此文件需求单的流程信息时可以很清楚的知道文件需求单曾传至谁处理及相应的处理意见;第二、指导文件需求单的传送路径,在文件需求单流传中,当前一个处理者执行了[同意]动作后,系统将此动作信息(ActionType=102,ActionDateTime=当前时间,IP=当前IP地址及Instruct=处理意见)写入流程记录表,此外按照NextStage所指向的流程模板表的下一关的指针,取出下一关的处理群组,再以此群组得到下一关的处理者,然后将此处理关信息(CheckName,GroupID,IsLogicGroup,extralDeal及ActionID)写入流程记录表,此时ActionType,ActionDateTime,IP及Instruct均为空,这样系统很容易地获知此文件需求单已从上一关传至下一关以及下一关处理者是谁。当下一关处理这查阅此文件需求单时,系统依照上述条件判断用户为此文件需求单的当前处理者员而显示出可以处理的文件需求单介面。
(d)事件记录表(P_EventLogTab):文件需求单处理过程中的每一个动作均将处理人、处理动作、处理说明、处理用的电脑IP地址记录下来,用于事后反追踪文件需求单处理过程。
栏位 |
描述 |
FormID |
对应文件需求单类型表的文件需求单类型IDint型 |
RecordID |
对应具体文件需求单的文件需求单记录IDint型 |
UserID |
文件需求单申请者IDint型 |
ActionID |
文件需求单处理者IDint型 |
ActionType |
处理人的处理动作,其动作值说明如下。101:提交。102:同意。103:不同意。104:收回。105:退件。109:删除。Int型 |
IP |
处理动作时的IP地址char型 |
ActionMemo |
动作备注varchar()型 |
流程记录归档表(P_ActFlowPackTab)、文件需求单状态归档表(P_DeActiveFormStatusTab)等两张表格数据结构同流程记录表(P_ActFlowTab)、文件需求单状态表(P_FormStatusTab)。当文件需求单结案、未予批准、退回、收回时,便将流程记录表、文件需求单状态表归档至流程记录归档表、文件需求单状态归档表。设计这两个表格目的是当表格数量不断增加,文件需求单状态表和流程记录表的记录数越来越多,这样在文件需求单关联查询时系统运行效率会降低,因此有必要将非流传中的文件需求单进行归档,提高流传中的文件需求单调阅速度。
举例而言,假设申请者A申请一份文件需求单Form1,填写后递交至签核者B处审核;B签核后传至签核者C办理,C处理完后,就代表整个流程结束,其整个处理流程如图1所示。
在图1中,首先,在步骤102中,设定一流程于一流程模板表中,假设此流程为A→B→C→End,至于其他数据的设定如下所述:
User |
CurrStage |
NextStage |
ExtraDeal |
A |
0 |
101 |
申请 |
B |
101 |
102 |
签核 |
C |
102 |
-1 |
办理 |
接着,在步骤104中,A在网页(form1.asp?WCI=FillTable)填写一文件需求单form1并提交此文件需求单form1,同时上载一附件。然后,进入步骤106中,系统将分配此文件需求单中之类型号为11(FormID=11)及记录号为23(RecordID=23)。其中,系统将文件需求单Form1中的各栏位及附件分别储存至数据库中及服务器的相对目录中。
接着,进入步骤108中,将A的动作信息依序写入一流程记录表(P_ActFlowTab)及一事件记录表(P_EventLogTab)中,而动作值为提交(ActionType=101)。然后,进入步骤110中,系统从流程模板表取出A的下一关指针(NextStage=101)而得到B,并且将B的相关信息(UserID=B)写入流程记录表中,此时B的动作值(ActionType)为空。接着,进入步骤112中,将文件需求单的相关信息写入一文件需求单状态表中,使得文件需求单状态表产生一文件需求单记录(FormID=11,RecordID=23,UserID=A,DealUserID=B,StatusID=101)。其中,此文件需求单的当前处理者为B,且此文件需求单Form1将由A传递至B处。
然后,进入步骤114中,当B登入系统时,系统将从文件需求单状态表中查到有一文件需求单(FormID=11,RecordID=23)需要B来处理(StatusID=101,DealUserID=B)。此时,系统在B的客户端的浏览器介面上生成一网页连结(form1.asp?WCI=ShowRecord&FormID=11&RecordID=23)。当用户B藉由浏览器点击此网页连结时,系统将生成此文件需求单记录的详细信息的网页。
需要注意的是,一份具体的文件需求单有四个分页面:表格分页、附件分页、流程记录分页及分享人员分页。各分页面可随时进行切换,不过,网页与网页之间不能像Windows程序一样保留变量值。因此在各网页上需要保存一些hidden数据,以便在网页提交时取出这些数据传递给下一个网页,而下一个网页采用Request方法取出这些数据。
例如,由表格分页切换到附件分页前,表格分页上需设置hidden栏位hFormID及hRecordID,便于用户在提交文件需求单时可让系统确定文件需求单记录号等信息;设置hTab栏位,以确定当前网页所处分页;设置hShowMode栏位,以确定当前网页是签核处理的显示方式。当表格分页切换到附件分页时,表格页面提交各个hidden数据,然后由附件分页采用request方法取出hFormID、hRecordID、hTab及hShowMode数据并以hidden栏位方式保存到当前网页上。
接着,进入步骤116中,B浏览此记录并执行同意动作。然后,进入步骤118中,系统藉由文件需求单状态表中的此文件需求单当前处理者及文件需求单状态,以验证用户B的身份是否为此文件需求单真正的处理者及B所处理的动作是否为真正所需的处理动作。若是,则进入下一步骤,否则的话,本流程终告结束。
然后,进入步骤120中,系统将B的同意动作信息写入流程记录表及事件记录表中,而动作为同意(ActionType=102)。接着,进入步骤122中,系统从流程模板表取出B的下一关指针(NextStage=102)而得到C,并且将C的相关信息(UserID=C)写入流程记录表中,此时C的动作值(ActionType)为空。然后,进入步骤124中,更新文件需求单状态表中的文件需求单记录(FormID=11,RecordID=23,UserID=A,DealUserID=C,StatusID=101),使得文件需求单的当前处理者为C,且Form1将由B传递至C处。
然后,进入步骤126中,当C登入系统时,系统将从文件需求单状态表中查到有一文件需求单记(FormID=11,RecordID=23)需要C来处理(StatusID=101,DealUserID=C)。此时,系统在C的客户端的浏览器介面上生成一网页连结(form1.asp?WCI=ShowRecord&FormID=11&RecordID=23)。当用户C藉由浏览器点击此网页连结时,系统将生成此文件需求单记录的详细信息的网页。
接着,进入步骤128中,C浏览此记录并执行同意动作。然后,进入步骤130中,系统藉由文件需求单状态表中的此文件需求单当前处理者及文件需求单状态,以验证用户C的身份是否为此文件需求单真正的处理者及C所处理的动作是否为真正所需的处理动作。若是,则进入下一步骤,否则的话,本流程终告结束。
接着,进入步骤132中,系统将C的同意动作信息写入流程记录表及事件记录表中,而动作值为同意(ActionType=102)。然后,进入步骤134中,系统从流程模板表取出C的下一关指针(NextStage=-1),表示C的下一关将结束流程。接着,进入步骤136中,更新文件需求单状态表中的文件需求单状态值为结案(FormId=11,RecordID=23,UserID=A,StatusID=107)。然后,进入步骤138中,系统执行归档处理,将此文件需求单于电子记录表格单、文件需求单状态表及流程记录表上的各笔记录分别移至电子表格归档表、文件需求单状态归档表、流程记录归档表。接着,进入步骤140中,系统发电子信件通知申请者文件需求单已办理完成。
至于本发明的文件签核同意的方法流程,在此将以图2说明如下。在图2中,首先,在步骤202中,取得当前用户信息。接着,进入步骤204中,取得文件需求单的类型号(FormID)及记录号(RecordID)。然后,进入步骤206中,查询文件需求单状态表中的当前处理者为谁。接着,进入步骤208中,判断用户是否为当前处理者,若是,进入下一步骤,否则的话,结束本方法。
然后,进入步骤210中,更新流程记录表中的当前处理者的处理动作为同意(ActionType=102),并且记下处理时间(ActionDateTime)、处理意见(Instruct)及处理所在IP地址。接着,进入步骤211中,如果处理意见微为不同意,则此文件需求单返回给申请者。然后,进入在步骤212中,将此动作信息写入事件记录表中。然后,进入步骤214中,依照流程模板表取得当前关的相关信息。接着,进入步骤216中,判断当前关是否为最后一关,若是,进入步骤218,否则的话,进入步骤222。
在步骤218中,更新文件需求单状态表的状态值为结案(StatusID=107)。接着,进入步骤220中,进行归档处理,并结束本方法。
另外,在步骤222中,取出下一关处理者。接着,进入步骤224中,判断此处理者是否已经处理过文件需求单。若是,则进入步骤226中,更新流程记录表并回到步骤216中。否则的话,进入步骤228中,更新文件需求单状态表下一关处理者及当前状态值。接着,进入步骤230中,判断当前状态值是否为结案。若是,进入步骤220中,执行归档处理并结束本方法。否则的话,回到步骤202中,重新取得用户信息。
至于本发明的文件归档之方法流程,在此将以图3说明如下。在图3中,首先,在步骤302中,取得当前用户信息。接着,在步骤304中,取得文件需求单的类型号(FormID)及记录号(RecordID)。然后,进入步骤306中,判断表单是否在处理中,表单例如是电子记录表格单、流程记录表及文件需求单状态表。接着,进入步骤308中,将电子记录表格单中的记录复制至电子表格归档表。然后,进入步骤310中,删除电子记录表格单。
接着,进入步骤312中,将流程记录表中的记录复制至流程记录归档表。然后,进入步骤314中,删除流程记录表。接着,进入步骤316中,将文件需求单状态表中的记录复制至文件需求单状态归档表。然后,进入步骤318中,删除文件需求状态表。接着,进入步骤320中,根据实际要求发送电子信件通知相关人员,本方法终告结束。
在实际情况中,有些文件需求单需要会签的模式,即文件需求单同时传递给相关签核者进行签核,如签核者A→签核者B及签核者C→签核者D,此种情况的实现方法必须采用指针来设计流程模板表。在流程模板表和流程记录表中设计三个栏位:FlowID代表流程记录号的唯一标示、CurrStage代表当前关及NextStage代表下一关,如图4所示。
首先,在步骤402中,FlowID=101,而CurrStage=0,表示当前关为用户申请者开始申请一文件需求单。其中,下一关NextStage=102,则从流程模板表中查找出此文件需求单条件为CurrStage=102的所有记录信息(签核群组),在利用群组表查找出所有需要签核者,如签核者A。再将签核者A的信息添加至流程记录表、文件需求单状态表中,此时文件需求单便从申请者传至A处。
接着,进入步骤404中,FlowID=102,而CurrStage=102,且签核者A同意此文件需求单。其中,下一关NextStage=103,则从流程模板表中查找出此文件需求单条件为CurrStage=103的所有记录信息(签核群组),在利用群组表查找出所有需要签核者,如签核者B及C。再将签核者B及C的信息添加至流程记录表、文件需求单状态表中,此时文件需求单便从A传至B及C处。
然后,进入步骤406中,FlowID=103,而CurrStage=103,且签核者B同意此文件需求单。其中,下一关NextStage=104,则从流程模板表中查找出此文件需求单条件为CurrStage=104的所有记录信息(签核群组),在利用群组表查找出所有需要签核者,如签核者D。再将签核者D的信息添加至流程记录表、文件需求单状态表中,此时文件需求单便从B传至D处。
同时,在步骤408中,FlowID=104,而CurrStage=103,且签核者C同意此文件需求单。其中,下一关NextStage=104,则从流程模板表中查找出此文件需求单条件为CurrStage=104的所有记录信息(签核群组),在利用群组表查找出所有需要签核者,如签核者D。再将签核者D的信息添加至流程记录表、文件需求单状态表中,此时文件需求单便从C传至D处。
接着,进入步骤410中,FlowID=105,而CurrStage=104,且签核者D同意此文件需求单。其中,下一关NextStage=-1,表示下一关为最后一关。然后,进入步骤412中,FlowID=105,而CurrStage=-1,表示当前关为最后一关并终告结束。
某些情况,文件需求单在退件后不希望立即被退出处理过程,而是可以循环往复的被处理,这就是退签。如一份文件需求单签核过程应为A→B→C,而B在预览(Review)时觉得申请内容不全便做退签处理。则此时流程可能为A→B→A→B→C。退签实现若采用类似上述指针方法也很容易,只要在流程模板表和流程记录表中增加可退签的关指针(BackStage)栏位即可。它代表当前关可退签至哪些关,这些关之间用″,″分隔开。例如A的CurrStage=101,NextStage=102;B的CurStage=102,NextStage=103,BackStage=101。则当B退签时,系统根据BackStage值应从流程模板表中取出CurrStage=101的处理群组。得到处理人员A后,便将A添加至流程记录表、文件需求单状态表中,此时文件需求单便从B退回至A处。
四、群组管理
[群组设计的目的]
群组的设计是为以后的流程设计做准备的。结合实际情况来看,公司的组织是架构在一棵纵向的树结构上。各种各样的横向关系无法准确地及适时地表达出来,而流程在很多情况下是要流经这些横向关系的节点。举例而言,假设员工A作为部门Dept1的主管,同时也是项目Proj1的负责人,亦同时负责监督本部门ISO工作,那他就有多重身份(职务)。因为各文件需求单流程是统一设计的,在不同的流程中分辨这些身份就成为难题。所以为简化流程设计考虑,本发明决定流程所流过的每一节点将用群组来表示,但是非常特殊情况的还是要除外来处理,且群组由设定程序统一维护。
[固定群组的定义和实现]
在许多情况下,流程中的某一步是只会牵涉到固定的一批人员的,这批固定人员的集合就是一个″固定群组″。用户在提交文件需求单时会被要求将流程中每一步的签核者从群组中挑选出来,群组在此限定了有权限充当此职务的人员的范围。程序一般也会通过代理人制度给予每个群组一位缺省人员,固定群组由两张数据库表构成,其主要字段如下:
(1)群组信息表(P_GroupInfoTab):登记了各个群组的信息。
栏位 |
描述 |
GroupID |
群组的唯一标识int型 |
GroupName |
群组中文名称char()型 |
(2)群组子表(P_GroupMembersTab):用以容纳群组的成员。
栏位 |
描述 |
GroupID |
对应于群组信息表(P_GroupInfoTab),表明这是哪个群组的成员。int型 |
GID |
存放一个int值char()型 |
bGroup |
布尔型,取0表示上述GID存放的是员工UserID。取1表示上述GID存放的是子群组GroupID。char()型 |
从群组子表的设计可以看出,固定群组的实现是嵌套式的,且一个群组是由若干人员和(或)若干子群组所构成。
[逻辑群组的定义和实现]
固定群组定义为一个若干人员的集合,是有缺陷的。缺陷就是通用性差,因为它无法表达任何逻辑关系。举例而言,因为公司有很多部门,所以″部门主管″对每一位员工来说不可能都相同,唯有定义″逻辑群组″才能解决这种需求。群组是共享的,所以逻辑群组的被定义为通过传入特定的参数,返回特定结构的人员数据。而且不同于固定群组的是,逻辑群组是动态的,只有需要它时,它才能产生出人员来。结合代理人制度,它甚至可以无须通过用户指定而自动产生唯一的处理人来。
逻辑群组没有嵌套的子群组,其实现方式说明如下:
(1)逻辑群组信息表(P_LogicGroupInfoTab)
栏位 |
描述 |
GroupID |
群组的唯一标识int型 |
GroupName |
群组中文名称char()型 |
GroupCode |
群组英文名称char()型 |
SQLCmd |
存放一条逻辑关系text型 |
需要注意的是,上述逻辑关系用带n个<WC@USERID></WC@USERID>标识(n≥0)的SQL语句存放于字段SQLCmd中。使用时传入相应员工UserID,并替换掉每个<WC@USERID><WC@USERID>,再执行此语句就可以得到签核者的信息。
例如″部门主管″群组的写法如下:
select UserID,CardNum,Chinesename,Department fromincMisDB..r_employeeInfoTab
where
(UserID=
(select DepartManagerid
from incmisdb..r_departmanagertab
where
(DepartNum=
(select Department
from incMisDB..r_employeeInfoTab
where UserID=<WC@USERID></WC@USERID>
)
)
)
)
五、代理人制度
某些情况文件需求单处理人员不在公司,此时为了让文件需求单仍能顺利地流传,需要设计代理人数据库,将积压在原处理者的文件需求单转至其相应的代理人去处理。
(1)适用对象:签核者、办理者和行政助理。
(2)代理规则:
(a)原则上代理人只能指定本人行政级别的上下一级人员。
(b)可以指定两级代理,这种指定在群组中做定义。
(c)代理形式有两种,立即代理和指定日期的代理。
(3)控制条件:
(a)群组的行政级别(P_GroupInfoTab.AdministrantLevel):
value |
描述 |
0 |
无指定代理人或授权的权力 |
正数 |
有指定代理人或授权的权力,并且其值代表了行政级别的上下层关系。 |
(b)群组的代理级别(P_GroupInfoTab.AgentLevel):
value |
描述 |
0 |
平级代理 |
1 |
上下级代理+平级代理 |
2 |
上级代理+平级代理 |
3 |
下级代理+平级代理 |
(4)表格结构如下:P_AgentMainTab为主表,主要记录其人有无代理,如下表所示。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
UserID Int(4) Not Null被代理人工号ID,Primary Key
DateFrom Datetime(8)代理开始时间
DateTo Datetime(8)代理结束时间
AgentMode Tinyint(1)Not Null代理方式1-无日期0--有日期
----------------------------------------------------------------------------------------------------------------------------------------------------------------------
P_AgentListTab:记录代理人,如下表所示。
-------------------------------------------------------------------------------------------------------------------------------------------------------------UserID Int(4)Not Null被代理人工号ID
DepartmenInt(4)被代理的部门
AgentLeve Int(4)Not Null代理级别(1:一级、2:二级)
AgentUserID Int(4)Not Null代理人UserID
-------------------------------------------------------------------------------------------------------------------------------------------------------------
AgentLevel代理范围:
AgentLevel |
描述 |
0 |
平级代理,如总经理室、行政助理。 |
1 |
上下级代理+平级代理 |
2 |
上级代理+平级代理,如部门主管的第一级代理人。 |
3 |
下级代理+平级代理,如部门主管的第二级代理人。 |
(5)文件需求单流传至处理人的代理者的处理流程,如下所述:
(a)取得文件需求单下一关的处理者A。
(b)取得A用户的职务和所在部门。
(c)判断A用户是否有权指定代理。
(d)若A指定了代理,将A的代理人B找出来。
(e)将B的信息写入流程记录表的实际处理者(ActionID)栏位中,说明B成为文件需求单的实际处理者。
(f)将A的信息写入流程记录表的原先处理者(OriginUserID)栏位中,说明A为原先的处理者。
(g)将B的信息更新至文件需求单状态表的当前处理者(DealUserID)栏位中,这样文件需求单顺利得从A流传至其代理者B处。
[辅助功能介绍]
为使文件需求单顺畅的执行,系统还需如下功能:
(a)在SERVER端运行的邮件发送程序,它的功能是定期扫描邮件缓冲表,将各文件需求单产出的各种报表、通知等发送至相关人员。
(b)在有签核或办理权限的客户端设计一文件需求单检查程序,它的功能是定期扫描文件需求单状态表,若有文件需求单需用户处理,则弹出视窗提示用户有文件需求单待处理。
(c)设计系统设定程序,它的功能是对系统参数设定、群组设定、各类文件需求单流程模板设定此系统与NT用户验证整合,可实现自动登入。
本发明上述实施例所揭示利用数据库和网页来实现基于浏览器的ISO文件发行系统及方法,具有下列优点:
1.ISO文件实现电子化管理并且被分类组织、存放,这使得文件可以被方便地检索。
2.ISO文件审批自动流转,系统会自动地将ISO文件传递至下一个文件处理人员。
3.只需数据库技术即可实现电子化,系统维护方便,客户端只需要一浏览器既可使用该系统。
4.采用标准的三层架构:在服务器端对事件处理并将有用的数据传回客户端。
综上所述,虽然本发明已以一较佳实施例揭示如上,然其并非用以限定本发明,任何熟悉本技术领域者,在不脱离本发明的精神和范围内,当可作各种的更动与润饰,因此本发明的保护范围当视后附的权利要求书所界定者为准。