专利名称：国际标准化组织文件发行管理系统及方法
技术领域：
本发明有关于一种ISO文件管理方法，特别有关于一种利用数据库和网页来实现基于浏览器的ISO文件发行管理系统及方法。
背景技术：
国际标准化组织(international organization for standardization，ISO)是世界上最大的非政府性标准化专门机构，它在国际标准化中具有主导地位的角色。ISO的主要活动是制定国际标准、协调世界范围内的标准化工作、进行组织各成员国和技术委员会之间的情报交流及进行与其他国际性组织之间的合作，以共同研究有关标准化的问题。
随着国际贸易的发展，对国际标准的要求日益提高，ISO的作用也日趋扩大，世界上许多国家对ISO也越加重视。ISO的目的和宗旨是在世界范围内促进标准化工作的发展，以利于国际物资交流和互助，并扩大知识、科学、技术和经济方面的合作。
在目前许多中小型企业追求ISO的趋势下，大多数公司尚采用人工方式来管理企业内部大量的ISO文件。然而，公司负责人员为了一份很普通的ISO文件的审批而跑东跑西，加上事后相关的ISO文件的检索亦非常不方便，这样作法相当浪费公司很多的人力、物力及财力。
虽然，有些大型企业已经采用ISO文件管理系统，然而一般的ISO文件管理系统的价格相当昂贵，加上ISO文件系统的架构及事后维护工作相当复杂的因素，使得公司必须花费时间及成本来进行一般员工对于ISO管理系统的认知及维护的培训工作。所以，对于一般中小型企业而言，他们则无法承受这样昂贵的消费开销，使得他们只好利用一般的人工方式来管理ISO文件，相当不便。
发明内容
有鉴于此，本发明的目的就是在提供一种利用数据库和网页来实现基于浏览器的ISO文件发行管理系统及方法。一方面可以实现ISO文件电子化管理，使得ISO文件被分类组织及存放，并利于日后方便被检索；另一方面，ISO文件审批自动流转，系统会自动地将ISO文件传递至下一个文件处理人员。
根据本发明的目的，提出一种ISO文件发行管理方法。首先，设定流程模板表中的流程依序为申请者及签核者。接着，申请者提交一文件需求单，且文件需求单被分配有类型号及记录号。然后，写入申请者的提交动作信息于相对于文件需求单的流程记录表及事件记录表的动作值栏位中。接着，依照流程模板表取出签核者，并将签核者的相关信息写入流程记录表中。然后，产生相对于文件需求单的文件需求单状态表中的记录，而写入签核者于文件需求单状态表中的当前处理者栏位中，且文件需求单状态表中的状态值为待处理中。接着，用户浏览文件需求单状态表中的记录并同意文件需求单。然后，判断用户是否为当前处理者，若是，写入用户的同意动作信息于流程记录表及事件记录表的动作值栏位中。接着，依照流程模板表更新状态值为结案，并执行归档处理。
为让本发明的上述目的、特征、和优点能更明显易懂，下文特举一较佳实施例，并配合附图，作详细说明如下。
图1示出了依照本发明的较佳实施例的ISO文件发行管理方法的流程图。
图2示出了依照本发明的较佳实施例的ISO文件审核同意方法的流程图。
图3示出了依照本发明的较佳实施例的ISO文件归档方法的流程图。
图4示出了依照本发明的较佳实施例的ISO文件会签方法的流程图。
具体实施例方式
一总体架构本发明的利用数据库(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)记录文件需求单电子表格信息。
(b)文件需求单信息表(F_DCT_MainTab)储存用户申请的每一笔文件需求单记录信息。
(c)附件表(F_DCT_AttachTab)具体的文件内容是保存在附件中，此表记录了申请者上载的文件信息。
以文件发行后的检索而言，文件一旦发行成功，便需产生一文件信息记录保存在文件信息表中，以利于文件检索。另外，由于不同用户对于某一各文件具有不同的浏览权，这时需要设计权限表来设置用户的浏览权。
(a)文件信息表(F_DCT_DocInfoTab)记录已发行成功的文件信息，供用户检索。
(b)文件归属表(F_DCT_DocOwnerTab)设置文件归属的浏览权限类型、专案和特殊人员。
以文件备份而言，文件备份包括数据库备份和按照文件信息表、附件表将所有服务器上的文件复制至指定备份路径中。
三、工作流程[工作流程设计目的]流程设计须符合实际工作流程步骤的要求，实现文件发行的申请、签核、办理、结案归档、电子信件(email)通知等一系列过程全部自动完成。
工作流程的设计是采用数据库的方式来表示文件需求单的签核过程、目前处于何种状态以及下一步将流传至谁。每份文件需求单都需经过若干步骤的签核，这个签核过程由文件需求单流程表来反映。为了能快速取得文件需求单目前处于何种状态、当前处理者，则需要设计一文件需求单状态表来表示。每一份电子表格在被申请之后，会得到文件需求单类型号(FormID)和文件需求单记录号(RecordID)，以唯一标示此文件需求单。
系统在文件需求单流传的每一步记录下相关信息来反映文件需求单流程过程。其具体数据结构定义如下(a)文件需求单状态表(P_FormStatusTab)保存文件需求单在当前流程中的重要信息。
通过查询文件需求单状态表(条件是用户ID＝DealUserID和StatusID＝101)，即可取得目前需要用户处理的文件需求单记录号和相应的文件需求单状态。通过查询文件需求单状态表(条件是用户ID＝UserID)，即可取得目前用户自己申请的文件需求单记录号和相应的文件需求单状态。
(b)流程模板表(P_FlowTemplateTab)规定文件需求单签核时的流程步骤，确定流程每一步的处理群组。
(c)流程记录表(P_ActFlowTab)记录下各关处理人员的处理意见，指导流程将文件需求单传至下一关某一特定人员。
流程模板表与流程记录表区别在于流程模板表指规定文件需求单基本的通用的流程过程，而流程记录表反映某一份文件需求单的实际的流程记录。
流程记录表起两个作用第一、记载了文件需求单各关处理者的处理信息，这在用户调阅此文件需求单的流程信息时可以很清楚的知道文件需求单曾传至谁处理及相应的处理意见；第二、指导文件需求单的传送路径，在文件需求单流传中，当前一个处理者执行了[同意]动作后，系统将此动作信息(ActionType＝102，ActionDateTime＝当前时间，IP＝当前IP地址及Instruct＝处理意见)写入流程记录表，此外按照NextStage所指向的流程模板表的下一关的指针，取出下一关的处理群组，再以此群组得到下一关的处理者，然后将此处理关信息(CheckName，GroupID，IsLogicGroup，extralDeal及ActionID)写入流程记录表，此时ActionType，ActionDateTime，IP及Instruct均为空，这样系统很容易地获知此文件需求单已从上一关传至下一关以及下一关处理者是谁。当下一关处理这查阅此文件需求单时，系统依照上述条件判断用户为此文件需求单的当前处理者员而显示出可以处理的文件需求单介面。
(d)事件记录表(P_EventLogTab)文件需求单处理过程中的每一个动作均将处理人、处理动作、处理说明、处理用的电脑IP地址记录下来，用于事后反追踪文件需求单处理过程。
流程记录归档表(P_ActFlowPackTab)、文件需求单状态归档表(P_DeActiveFormStatusTab)等两张表格数据结构同流程记录表(P_ActFlowTab)、文件需求单状态表(P_FormStatusTab)。当文件需求单结案、未予批准、退回、收回时，便将流程记录表、文件需求单状态表归档至流程记录归档表、文件需求单状态归档表。设计这两个表格目的是当表格数量不断增加，文件需求单状态表和流程记录表的记录数越来越多，这样在文件需求单关联查询时系统运行效率会降低，因此有必要将非流传中的文件需求单进行归档，提高流传中的文件需求单调阅速度。
举例而言，假设申请者A申请一份文件需求单Form1，填写后递交至签核者B处审核；B签核后传至签核者C办理，C处理完后，就代表整个流程结束，其整个处理流程如图1所示。
在图1中，首先，在步骤102中，设定一流程于一流程模板表中，假设此流程为A→B→C→End，至于其他数据的设定如下所述
接着，在步骤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)登记了各个群组的信息。
(2)群组子表(P_GroupMembersTab)用以容纳群组的成员。
从群组子表的设计可以看出，固定群组的实现是嵌套式的，且一个群组是由若干人员和(或)若干子群组所构成。
固定群组定义为一个若干人员的集合，是有缺陷的。缺陷就是通用性差，因为它无法表达任何逻辑关系。举例而言，因为公司有很多部门，所以″部门主管″对每一位员工来说不可能都相同，唯有定义″逻辑群组″才能解决这种需求。群组是共享的，所以逻辑群组的被定义为通过传入特定的参数，返回特定结构的人员数据。而且不同于固定群组的是，逻辑群组是动态的，只有需要它时，它才能产生出人员来。结合代理人制度，它甚至可以无须通过用户指定而自动产生唯一的处理人来。
逻辑群组没有嵌套的子群组，其实现方式说明如下(1)逻辑群组信息表(P_LogicGroupInfoTab)
需要注意的是，上述逻辑关系用带n个<WC@USERID></WC@USERID>标识(n≥0)的SQL语句存放于字段SQLCmd中。使用时传入相应员工UserID，并替换掉每个<WC@USERID><WC@USERID>，再执行此语句就可以得到签核者的信息。
例如″部门主管″群组的写法如下select UserID，CardNum，Chinesename，Department fromincMisDB..r_employeeInfoTabwhere(UserID＝(select DepartManageridfrom incmisdb..r_departmanagertabwhere(DepartNum＝(select Departmentfrom incMisDB..r_employeeInfoTabwhere UserID＝<WC@USERID></WC@USERID>
))))五、代理人制度某些情况文件需求单处理人员不在公司，此时为了让文件需求单仍能顺利地流传，需要设计代理人数据库，将积压在原处理者的文件需求单转至其相应的代理人去处理。
(1)适用对象签核者、办理者和行政助理。
(2)代理规则(a)原则上代理人只能指定本人行政级别的上下一级人员。
(b)可以指定两级代理，这种指定在群组中做定义。
(c)代理形式有两种，立即代理和指定日期的代理。
(3)控制条件(a)群组的行政级别(P_GroupInfoTab.AdministrantLevel)
(b)群组的代理级别(P_GroupInfoTab.AgentLevel)
(4)表格结构如下P_AgentMainTab为主表，主要记录其人有无代理，如下表所示。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------UserID Int(4) Not Null被代理人工号ID，Primary KeyDateFrom Datetime(8)代理开始时间DateTo Datetime(8)代理结束时间AgentMode Tinyint(1)Not Null代理方式1-无日期0--有日期----------------------------------------------------------------------------------------------------------------------------------------------------------------------P_AgentListTab记录代理人，如下表所示。
-------------------------------------------------------------------------------------------------------------------------------------------------------------UserID Int(4)Not Null被代理人工号IDDepartmenInt(4)被代理的部门AgentLeve Int(4)Not Null代理级别(1一级、2二级)AgentUserID Int(4)Not Null代理人UserID-------------------------------------------------------------------------------------------------------------------------------------------------------------AgentLevel代理范围
(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.采用标准的三层架构在服务器端对事件处理并将有用的数据传回客户端。
综上所述，虽然本发明已以一较佳实施例揭示如上，然其并非用以限定本发明，任何熟悉本技术领域者，在不脱离本发明的精神和范围内，当可作各种的更动与润饰，因此本发明的保护范围当视后附的权利要求书所界定者为准。
权利要求
1.一种ISO文件发行管理方法，用于一ISO文件发行系统中，该方法包括设定一流程模板表中的流程依序为一申请者及至少一签核者；该申请者提交一文件需求单，且该文件需求单被分配有一类型号(FormID)及一记录号(RecordID)；写入该申请者的提交动作信息于相对于该文件需求单的一流程记录表及一事件记录表的一动作值(ActionType)栏位中；依照该流程模板表取出该签核者，并将该签核者的相关信息写入该流程记录表中；产生相对于该文件需求单的一文件需求单状态表中的记录，而写入该签核者于该文件需求单状态表中的一当前处理者(DealUserID)栏位中，且该文件需求单状态表中的一状态值(StatusID)为待处理中；一用户浏览该文件需求单状态表中的记录并同意该文件需求单；判断该用户是否为该当前处理者，若是，写入该用户的同意动作信息于该流程记录表及该事件记录表的该动作值栏位中；以及依照该流程模板表更新该状态值为结案，并执行归档处理。
2.如权利要求1所述的方法，其特征在于，还包括一ISO文件签核同意方法，如下所述(a)取得该用户的信息；取得该文件需求单的该类型号及该记录号；查询该文件需求单状态表中的该当前处理者；判断该用户是否为该当前处理者，若是，更新该流程记录表中的该当前处理者的同意动作信息，并记下一处理时间、一处理意见、一处理所在IP地址；于该处理意见为不同意时返回该文件需求单给申请者；写入该当前处理者的同意动作信息于该事件记录表中；依照该流程模板表取得一当前关的相关信息；(b)判断该当前关是否为最后一关，若是，更新该文件需求单状态表的该状态值为结案并进行归档处理，否则，进入步骤(c)；(c)取出一下一关处理者并判断该下一关处理者是否已经处理过该文件需求单，若是，更新该流程记录表并回到步骤(b)，否则，进入步骤(d)；以及(d)更新该文件需求单状态表的该下一关处理者及该状态值，并判断该状态值是否为结案，若是，进行归档处理，否则，回到步骤(a)。
3.如权利要求1所述的方法，其特征在于，还包括一ISO文件归档方法，如下所述取得该用户的信息；取得该文件需求单的该类型号及该记录号；判断相对于该文件需求单的至少一电子记录表格单、该流程记录表及该文件需求单状态表是否正在被处理中，若否，复制该电子记录表格单中的记录至一电子表格归档并删除该电子记录表格单；复制该流程记录表中的记录至一流程记录归档表并删除该流程记录表；复制该文件需求单状态表中的记录至一文件需求单状态归档表并删除文件需求状态表；以及发送至少一电子信件以通知该申请者及相关人员。
4.如权利要求1所述的方法，其特征在于，还包括一代理人审核同意方法，如下所述取得该文件需求单的下一关处理者；取得该下一关处理者的职务及所在部门；判断该下一关处理者是否有权指定一代理人，若有，将该代理人的信息写入该流程记录表的一实际处理者(ActionID)栏位中，用以说明该代理人成为该文件需求单的实际处理者；将该下一关处理者的信息写入该流程记录表的一原先处理者(OriginUserID)栏位中，用以说明该下一关处理者为原先的处理者；以及将该代理人的信息更新至该文件需求单状态表的一当前处理者(DealUserID)栏位中，使得该文件需求单可以由该下一关处理者流传至该代理人处。
5.如权利要求1所述的方法，其特征在于，还包括一ISO文件会签方法，如下所述该申请者申请该文件需求单，且该流程记录表具有第一当前关指针(CurrStage)及下一关指针(NextStage)；从该流程模板表中找出第二当前关指针为该下一关指针的至少一签核群组；利用一群组表查找出该签核群组中的至少一签核者；以及将该签核者的信息添加至该流程记录表、该文件需求单状态表中，使得该文件需求单由该申请者传至该签核者处。
6.如权利要求5所述的方法，其特征在于，其中该第一当前关指针的值为0。
7.如权利要求5所述的方法，其特征在于，其中该下一关指针的值为-1。
8.如权利要求5所述的方法，其特征在于，其中该第二当前关指针的值为-1。
9.如权利要求1所述的方法，其特征在于，还包括一ISO文件退签方法，如下所述该签核者不同意该文件需求单，且该流程记录表具有一第一当前关指针(CurrStage)及一退签关指针(BackStage)；从该流程模板表中找出第二当前关指针为该退签关指针的该申请者；以及将该申请者的信息添加至该流程记录表、该文件需求单状态表中，使得该文件需求单由该签核者退回传至该申请者处。
10.如权利要求1所述的方法，其特征在于，其中该ISO文件发行系统至少包含一浏览器、一服务器及一数据库。
11.如权利要求7所述的方法，其特征在于，其中于该用户浏览该文件需求单状态表中之记录并同意该文件需求单之前，又包括以下步骤；该用户登入该ISO文件发行管理系统；该系统将从该文件需求单状态表中查到该文件需求单需要该用户来处理；该系统在该用户的一客户端之该浏览器上生成一网页连结；以及该用户藉由该浏览器点击该网页连结，使得该系统生成该文件需求单的详细信息的网页。
12.如权利要求7所述的方法，其特征在于，其中于该文件需求单被申请发行前，又包括设计一表单类型信息表、一文件需求单信息表及一附件表于该数据库中。
13.如权利要求7所述的方法，其特征在于，其中于该文件需求单被申请发行成功后，又包括设计相对于该文件需求单的一文件信息表、一文件归属表该数据库中。
14.如权利要求7所述的方法，其特征在于，又包括备份该数据库中的资料并复制该服务器中的资料至一指定路径中。
15.如权利要求1所述的方法，其特征在于，其中于该文件需求单状态表的记录包含该申请者、该类型号、该记录号、该当前处理者及该状态值。
16.如权利要求1所述的方法，其特征在于，其中该文件需求单具有一表格分页、一附件分页、一流程记录分页及一分享人员分页。
全文摘要
本发明涉及一种ISO文件发行管理系统及方法。设定流程模板表，并提交文件需求单。写入提交动作信息于流程记录表及事件记录表的动作值栏位中。依照流程模板表写入签核者的信息于流程记录表中。产生文件需求单状态表中的记录，而写入签核者于文件需求单状态表中的当前处理者栏位中。用户浏览记录并同意文件需求单。判断用户是否为当前处理者，若是，写入同意动作信息于动作值栏位中。更新文件需求单状态表的状态值为结案，并执行归档。
文档编号G06F17/30GK1485768SQ0213712
公开日2004年3月31日 申请日期2002年9月25日 优先权日2002年9月25日
发明者赖振兴, 徐小南, 叶波 申请人:英业达集团(南京)电子技术有限公司