專(zhuān)利名稱(chēng)：國(guó)際標(biāo)準(zhǔn)化組織文件發(fā)行管理系統(tǒng)及方法
技術(shù)領(lǐng)域：
本發(fā)明有關(guān)于一種ISO文件管理方法，特別有關(guān)于一種利用數(shù)據(jù)庫(kù)和網(wǎng)頁(yè)來(lái)實(shí)現(xiàn)基于瀏覽器的ISO文件發(fā)行管理系統(tǒng)及方法。
背景技術(shù)：
國(guó)際標(biāo)準(zhǔn)化組織(international organization for standardization，ISO)是世界上最大的非政府性標(biāo)準(zhǔn)化專(zhuān)門(mén)機(jī)構(gòu)，它在國(guó)際標(biāo)準(zhǔn)化中具有主導(dǎo)地位的角色。ISO的主要活動(dòng)是制定國(guó)際標(biāo)準(zhǔn)、協(xié)調(diào)世界范圍內(nèi)的標(biāo)準(zhǔn)化工作、進(jìn)行組織各成員國(guó)和技術(shù)委員會(huì)之間的情報(bào)交流及進(jìn)行與其他國(guó)際性組織之間的合作，以共同研究有關(guān)標(biāo)準(zhǔn)化的問(wèn)題。
隨著國(guó)際貿(mào)易的發(fā)展，對(duì)國(guó)際標(biāo)準(zhǔn)的要求日益提高，ISO的作用也日趨擴(kuò)大，世界上許多國(guó)家對(duì)ISO也越加重視。ISO的目的和宗旨是在世界范圍內(nèi)促進(jìn)標(biāo)準(zhǔn)化工作的發(fā)展，以利于國(guó)際物資交流和互助，并擴(kuò)大知識(shí)、科學(xué)、技術(shù)和經(jīng)濟(jì)方面的合作。
在目前許多中小型企業(yè)追求ISO的趨勢(shì)下，大多數(shù)公司尚采用人工方式來(lái)管理企業(yè)內(nèi)部大量的ISO文件。然而，公司負(fù)責(zé)人員為了一份很普通的ISO文件的審批而跑東跑西，加上事后相關(guān)的ISO文件的檢索亦非常不方便，這樣作法相當(dāng)浪費(fèi)公司很多的人力、物力及財(cái)力。
雖然，有些大型企業(yè)已經(jīng)采用ISO文件管理系統(tǒng)，然而一般的ISO文件管理系統(tǒng)的價(jià)格相當(dāng)昂貴，加上ISO文件系統(tǒng)的架構(gòu)及事后維護(hù)工作相當(dāng)復(fù)雜的因素，使得公司必須花費(fèi)時(shí)間及成本來(lái)進(jìn)行一般員工對(duì)于ISO管理系統(tǒng)的認(rèn)知及維護(hù)的培訓(xùn)工作。所以，對(duì)于一般中小型企業(yè)而言，他們則無(wú)法承受這樣昂貴的消費(fèi)開(kāi)銷(xiāo)，使得他們只好利用一般的人工方式來(lái)管理ISO文件，相當(dāng)不便。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的目的就是在提供一種利用數(shù)據(jù)庫(kù)和網(wǎng)頁(yè)來(lái)實(shí)現(xiàn)基于瀏覽器的ISO文件發(fā)行管理系統(tǒng)及方法。一方面可以實(shí)現(xiàn)ISO文件電子化管理，使得ISO文件被分類(lèi)組織及存放，并利于日后方便被檢索；另一方面，ISO文件審批自動(dòng)流轉(zhuǎn)，系統(tǒng)會(huì)自動(dòng)地將ISO文件傳遞至下一個(gè)文件處理人員。
根據(jù)本發(fā)明的目的，提出一種ISO文件發(fā)行管理方法。首先，設(shè)定流程模板表中的流程依序?yàn)樯暾?qǐng)者及簽核者。接著，申請(qǐng)者提交一文件需求單，且文件需求單被分配有類(lèi)型號(hào)及記錄號(hào)。然后，寫(xiě)入申請(qǐng)者的提交動(dòng)作信息于相對(duì)于文件需求單的流程記錄表及事件記錄表的動(dòng)作值欄位中。接著，依照流程模板表取出簽核者，并將簽核者的相關(guān)信息寫(xiě)入流程記錄表中。然后，產(chǎn)生相對(duì)于文件需求單的文件需求單狀態(tài)表中的記錄，而寫(xiě)入簽核者于文件需求單狀態(tài)表中的當(dāng)前處理者欄位中，且文件需求單狀態(tài)表中的狀態(tài)值為待處理中。接著，用戶瀏覽文件需求單狀態(tài)表中的記錄并同意文件需求單。然后，判斷用戶是否為當(dāng)前處理者，若是，寫(xiě)入用戶的同意動(dòng)作信息于流程記錄表及事件記錄表的動(dòng)作值欄位中。接著，依照流程模板表更新?tīng)顟B(tài)值為結(jié)案，并執(zhí)行歸檔處理。
為讓本發(fā)明的上述目的、特征、和優(yōu)點(diǎn)能更明顯易懂，下文特舉一較佳實(shí)施例，并配合附圖，作詳細(xì)說(shuō)明如下。


圖1示出了依照本發(fā)明的較佳實(shí)施例的ISO文件發(fā)行管理方法的流程圖。
圖2示出了依照本發(fā)明的較佳實(shí)施例的ISO文件審核同意方法的流程圖。
圖3示出了依照本發(fā)明的較佳實(shí)施例的ISO文件歸檔方法的流程圖。
圖4示出了依照本發(fā)明的較佳實(shí)施例的ISO文件會(huì)簽方法的流程圖。
具體實(shí)施例方式
一總體架構(gòu)本發(fā)明的利用數(shù)據(jù)庫(kù)(database)及網(wǎng)頁(yè)來(lái)實(shí)現(xiàn)基于瀏覽器(browser)的ISO文件發(fā)行管理系統(tǒng)采用瀏覽器/應(yīng)用服務(wù)(application service)/數(shù)據(jù)庫(kù)的三層架構(gòu)，用以讓公司內(nèi)部人員進(jìn)行ISO文件的申請(qǐng)及審核動(dòng)作，擺脫以前人工化的ISO文件管理方法。系統(tǒng)平臺(tái)為Windows NT/2000服務(wù)器(server)、互聯(lián)網(wǎng)信息(Internet information)服務(wù)器及結(jié)構(gòu)化查詢語(yǔ)言(structured query language，SQL)服務(wù)器，客戶(client)端為Internet Explorer 4.0以上，且自己架構(gòu)的服務(wù)(service)為文件發(fā)行系統(tǒng)服務(wù)。其他相關(guān)子系統(tǒng)是為了結(jié)合公司內(nèi)部的資源而彈性設(shè)立，例如人事管理系統(tǒng)是為了取得當(dāng)前用戶的行政組織關(guān)系和姓名等人事資料；PDPM管理系統(tǒng)是為了項(xiàng)目文件需要取得項(xiàng)目的項(xiàng)目主管及項(xiàng)目人員信息。
另外，ISO文件發(fā)行管理系統(tǒng)系統(tǒng)包括文件管理、工作流程、群組管理、代理人制度等核心模塊，分述如下二、文件管理企業(yè)內(nèi)部在經(jīng)營(yíng)管理、項(xiàng)目開(kāi)發(fā)中會(huì)產(chǎn)生許多ISO文件，諸如品質(zhì)手冊(cè)、作業(yè)程序等，這些文件都需要得到有效管制，即在文件發(fā)行前需經(jīng)過(guò)適當(dāng)?shù)膶彶榧昂藴?zhǔn)。文件管理目的在于(a)實(shí)現(xiàn)ISO文件申請(qǐng)表格和附屬文件電子化。
(b)使新文件發(fā)行、文件變更、文件作廢、文件追加申請(qǐng)等電子化的申請(qǐng)過(guò)程與實(shí)際的文件發(fā)行作業(yè)流程相一致。
(c)將文件分類(lèi)便于以發(fā)行文件的分類(lèi)檢索。
(d)對(duì)已發(fā)行文件做到權(quán)限管制。
(e)實(shí)現(xiàn)已發(fā)行文件的備份功能。
所以，文件管理包括文件申請(qǐng)及處理、文件發(fā)行后的檢索、文件備份。
以文件申請(qǐng)及處理而言，文件在發(fā)行前是以文件需求單電子表格的形式在企業(yè)網(wǎng)絡(luò)內(nèi)部傳遞。為了妥善管理此些電子表格，本發(fā)明需要在數(shù)據(jù)庫(kù)中設(shè)計(jì)如下表格(a)表單類(lèi)型信息表(P_FormInfoTab)記錄文件需求單電子表格信息。

(b)文件需求單信息表(F_DCT_MainTab)儲(chǔ)存用戶申請(qǐng)的每一筆文件需求單記錄信息。

(c)附件表(F_DCT_AttachTab)具體的文件內(nèi)容是保存在附件中，此表記錄了申請(qǐng)者上載的文件信息。


以文件發(fā)行后的檢索而言，文件一旦發(fā)行成功，便需產(chǎn)生一文件信息記錄保存在文件信息表中，以利于文件檢索。另外，由于不同用戶對(duì)于某一各文件具有不同的瀏覽權(quán)，這時(shí)需要設(shè)計(jì)權(quán)限表來(lái)設(shè)置用戶的瀏覽權(quán)。
(a)文件信息表(F_DCT_DocInfoTab)記錄已發(fā)行成功的文件信息，供用戶檢索。


(b)文件歸屬表(F_DCT_DocOwnerTab)設(shè)置文件歸屬的瀏覽權(quán)限類(lèi)型、專(zhuān)案和特殊人員。

以文件備份而言，文件備份包括數(shù)據(jù)庫(kù)備份和按照文件信息表、附件表將所有服務(wù)器上的文件復(fù)制至指定備份路徑中。
三、工作流程[工作流程設(shè)計(jì)目的]流程設(shè)計(jì)須符合實(shí)際工作流程步驟的要求，實(shí)現(xiàn)文件發(fā)行的申請(qǐng)、簽核、辦理、結(jié)案歸檔、電子信件(email)通知等一系列過(guò)程全部自動(dòng)完成。
工作流程的設(shè)計(jì)是采用數(shù)據(jù)庫(kù)的方式來(lái)表示文件需求單的簽核過(guò)程、目前處于何種狀態(tài)以及下一步將流傳至誰(shuí)。每份文件需求單都需經(jīng)過(guò)若干步驟的簽核，這個(gè)簽核過(guò)程由文件需求單流程表來(lái)反映。為了能快速取得文件需求單目前處于何種狀態(tài)、當(dāng)前處理者，則需要設(shè)計(jì)一文件需求單狀態(tài)表來(lái)表示。每一份電子表格在被申請(qǐng)之后，會(huì)得到文件需求單類(lèi)型號(hào)(FormID)和文件需求單記錄號(hào)(RecordID)，以唯一標(biāo)示此文件需求單。
系統(tǒng)在文件需求單流傳的每一步記錄下相關(guān)信息來(lái)反映文件需求單流程過(guò)程。其具體數(shù)據(jù)結(jié)構(gòu)定義如下(a)文件需求單狀態(tài)表(P_FormStatusTab)保存文件需求單在當(dāng)前流程中的重要信息。


通過(guò)查詢文件需求單狀態(tài)表(條件是用戶ID＝DealUserID和StatusID＝101)，即可取得目前需要用戶處理的文件需求單記錄號(hào)和相應(yīng)的文件需求單狀態(tài)。通過(guò)查詢文件需求單狀態(tài)表(條件是用戶ID＝UserID)，即可取得目前用戶自己申請(qǐng)的文件需求單記錄號(hào)和相應(yīng)的文件需求單狀態(tài)。
(b)流程模板表(P_FlowTemplateTab)規(guī)定文件需求單簽核時(shí)的流程步驟，確定流程每一步的處理群組。

(c)流程記錄表(P_ActFlowTab)記錄下各關(guān)處理人員的處理意見(jiàn)，指導(dǎo)流程將文件需求單傳至下一關(guān)某一特定人員。


流程模板表與流程記錄表區(qū)別在于流程模板表指規(guī)定文件需求單基本的通用的流程過(guò)程，而流程記錄表反映某一份文件需求單的實(shí)際的流程記錄。
流程記錄表起兩個(gè)作用第一、記載了文件需求單各關(guān)處理者的處理信息，這在用戶調(diào)閱此文件需求單的流程信息時(shí)可以很清楚的知道文件需求單曾傳至誰(shuí)處理及相應(yīng)的處理意見(jiàn)；第二、指導(dǎo)文件需求單的傳送路徑，在文件需求單流傳中，當(dāng)前一個(gè)處理者執(zhí)行了[同意]動(dòng)作后，系統(tǒng)將此動(dòng)作信息(ActionType＝102，ActionDateTime＝當(dāng)前時(shí)間，IP＝當(dāng)前IP地址及Instruct＝處理意見(jiàn))寫(xiě)入流程記錄表，此外按照NextStage所指向的流程模板表的下一關(guān)的指針，取出下一關(guān)的處理群組，再以此群組得到下一關(guān)的處理者，然后將此處理關(guān)信息(CheckName，GroupID，IsLogicGroup，extralDeal及ActionID)寫(xiě)入流程記錄表，此時(shí)ActionType，ActionDateTime，IP及Instruct均為空，這樣系統(tǒng)很容易地獲知此文件需求單已從上一關(guān)傳至下一關(guān)以及下一關(guān)處理者是誰(shuí)。當(dāng)下一關(guān)處理這查閱此文件需求單時(shí)，系統(tǒng)依照上述條件判斷用戶為此文件需求單的當(dāng)前處理者員而顯示出可以處理的文件需求單介面。
(d)事件記錄表(P_EventLogTab)文件需求單處理過(guò)程中的每一個(gè)動(dòng)作均將處理人、處理動(dòng)作、處理說(shuō)明、處理用的電腦IP地址記錄下來(lái)，用于事后反追蹤文件需求單處理過(guò)程。

流程記錄歸檔表(P_ActFlowPackTab)、文件需求單狀態(tài)歸檔表(P_DeActiveFormStatusTab)等兩張表格數(shù)據(jù)結(jié)構(gòu)同流程記錄表(P_ActFlowTab)、文件需求單狀態(tài)表(P_FormStatusTab)。當(dāng)文件需求單結(jié)案、未予批準(zhǔn)、退回、收回時(shí)，便將流程記錄表、文件需求單狀態(tài)表歸檔至流程記錄歸檔表、文件需求單狀態(tài)歸檔表。設(shè)計(jì)這兩個(gè)表格目的是當(dāng)表格數(shù)量不斷增加，文件需求單狀態(tài)表和流程記錄表的記錄數(shù)越來(lái)越多，這樣在文件需求單關(guān)聯(lián)查詢時(shí)系統(tǒng)運(yùn)行效率會(huì)降低，因此有必要將非流傳中的文件需求單進(jìn)行歸檔，提高流傳中的文件需求單調(diào)閱速度。
舉例而言，假設(shè)申請(qǐng)者A申請(qǐng)一份文件需求單Form1，填寫(xiě)后遞交至簽核者B處審核；B簽核后傳至簽核者C辦理，C處理完后，就代表整個(gè)流程結(jié)束，其整個(gè)處理流程如圖1所示。
在圖1中，首先，在步驟102中，設(shè)定一流程于一流程模板表中，假設(shè)此流程為A→B→C→End，至于其他數(shù)據(jù)的設(shè)定如下所述

接著，在步驟104中，A在網(wǎng)頁(yè)(form1.asp？WCI＝FillTable)填寫(xiě)一文件需求單form1并提交此文件需求單form1，同時(shí)上載一附件。然后，進(jìn)入步驟106中，系統(tǒng)將分配此文件需求單中之類(lèi)型號(hào)為11(FormID＝11)及記錄號(hào)為23(RecordID＝23)。其中，系統(tǒng)將文件需求單Form1中的各欄位及附件分別儲(chǔ)存至數(shù)據(jù)庫(kù)中及服務(wù)器的相對(duì)目錄中。
接著，進(jìn)入步驟108中，將A的動(dòng)作信息依序?qū)懭胍涣鞒逃涗洷?P_ActFlowTab)及一事件記錄表(P_EventLogTab)中，而動(dòng)作值為提交(ActionType＝101)。然后，進(jìn)入步驟110中，系統(tǒng)從流程模板表取出A的下一關(guān)指針(NextStage＝101)而得到B，并且將B的相關(guān)信息(UserID＝B)寫(xiě)入流程記錄表中，此時(shí)B的動(dòng)作值(ActionType)為空。接著，進(jìn)入步驟112中，將文件需求單的相關(guān)信息寫(xiě)入一文件需求單狀態(tài)表中，使得文件需求單狀態(tài)表產(chǎn)生一文件需求單記錄(FormID＝11，RecordID＝23，UserID＝A，DealUserID＝B，StatusID＝101)。其中，此文件需求單的當(dāng)前處理者為B，且此文件需求單Form1將由A傳遞至B處。
然后，進(jìn)入步驟114中，當(dāng)B登入系統(tǒng)時(shí)，系統(tǒng)將從文件需求單狀態(tài)表中查到有一文件需求單(FormID＝11，RecordID＝23)需要B來(lái)處理(StatusID＝101，DealUserID＝B)。此時(shí)，系統(tǒng)在B的客戶端的瀏覽器介面上生成一網(wǎng)頁(yè)連結(jié)(form1.asp？WCI＝ShowRecord&FormID＝11&RecordID＝23)。當(dāng)用戶B藉由瀏覽器點(diǎn)擊此網(wǎng)頁(yè)連結(jié)時(shí)，系統(tǒng)將生成此文件需求單記錄的詳細(xì)信息的網(wǎng)頁(yè)。
需要注意的是，一份具體的文件需求單有四個(gè)分頁(yè)面表格分頁(yè)、附件分頁(yè)、流程記錄分頁(yè)及分享人員分頁(yè)。各分頁(yè)面可隨時(shí)進(jìn)行切換，不過(guò)，網(wǎng)頁(yè)與網(wǎng)頁(yè)之間不能像Windows程序一樣保留變量值。因此在各網(wǎng)頁(yè)上需要保存一些hidden數(shù)據(jù)，以便在網(wǎng)頁(yè)提交時(shí)取出這些數(shù)據(jù)傳遞給下一個(gè)網(wǎng)頁(yè)，而下一個(gè)網(wǎng)頁(yè)采用Request方法取出這些數(shù)據(jù)。
例如，由表格分頁(yè)切換到附件分頁(yè)前，表格分頁(yè)上需設(shè)置hidden欄位hFormID及hRecordID，便于用戶在提交文件需求單時(shí)可讓系統(tǒng)確定文件需求單記錄號(hào)等信息；設(shè)置hTab欄位，以確定當(dāng)前網(wǎng)頁(yè)所處分頁(yè)；設(shè)置hShowMode欄位，以確定當(dāng)前網(wǎng)頁(yè)是簽核處理的顯示方式。當(dāng)表格分頁(yè)切換到附件分頁(yè)時(shí)，表格頁(yè)面提交各個(gè)hidden數(shù)據(jù)，然后由附件分頁(yè)采用request方法取出hFormID、hRecordID、hTab及hShowMode數(shù)據(jù)并以hidden欄位方式保存到當(dāng)前網(wǎng)頁(yè)上。
接著，進(jìn)入步驟116中，B瀏覽此記錄并執(zhí)行同意動(dòng)作。然后，進(jìn)入步驟118中，系統(tǒng)藉由文件需求單狀態(tài)表中的此文件需求單當(dāng)前處理者及文件需求單狀態(tài)，以驗(yàn)證用戶B的身份是否為此文件需求單真正的處理者及B所處理的動(dòng)作是否為真正所需的處理動(dòng)作。若是，則進(jìn)入下一步驟，否則的話，本流程終告結(jié)束。
然后，進(jìn)入步驟120中，系統(tǒng)將B的同意動(dòng)作信息寫(xiě)入流程記錄表及事件記錄表中，而動(dòng)作為同意(ActionType＝102)。接著，進(jìn)入步驟122中，系統(tǒng)從流程模板表取出B的下一關(guān)指針(NextStage＝102)而得到C，并且將C的相關(guān)信息(UserID＝C)寫(xiě)入流程記錄表中，此時(shí)C的動(dòng)作值(ActionType)為空。然后，進(jìn)入步驟124中，更新文件需求單狀態(tài)表中的文件需求單記錄(FormID＝11，RecordID＝23，UserID＝A，DealUserID＝C，StatusID＝101)，使得文件需求單的當(dāng)前處理者為C，且Form1將由B傳遞至C處。
然后，進(jìn)入步驟126中，當(dāng)C登入系統(tǒng)時(shí)，系統(tǒng)將從文件需求單狀態(tài)表中查到有一文件需求單記(FormID＝11，RecordID＝23)需要C來(lái)處理(StatusID＝101，DealUserID＝C)。此時(shí)，系統(tǒng)在C的客戶端的瀏覽器介面上生成一網(wǎng)頁(yè)連結(jié)(form1.asp？WCI＝ShowRecord&FormID＝11&RecordID＝23)。當(dāng)用戶C藉由瀏覽器點(diǎn)擊此網(wǎng)頁(yè)連結(jié)時(shí)，系統(tǒng)將生成此文件需求單記錄的詳細(xì)信息的網(wǎng)頁(yè)。
接著，進(jìn)入步驟128中，C瀏覽此記錄并執(zhí)行同意動(dòng)作。然后，進(jìn)入步驟130中，系統(tǒng)藉由文件需求單狀態(tài)表中的此文件需求單當(dāng)前處理者及文件需求單狀態(tài)，以驗(yàn)證用戶C的身份是否為此文件需求單真正的處理者及C所處理的動(dòng)作是否為真正所需的處理動(dòng)作。若是，則進(jìn)入下一步驟，否則的話，本流程終告結(jié)束。
接著，進(jìn)入步驟132中，系統(tǒng)將C的同意動(dòng)作信息寫(xiě)入流程記錄表及事件記錄表中，而動(dòng)作值為同意(ActionType＝102)。然后，進(jìn)入步驟134中，系統(tǒng)從流程模板表取出C的下一關(guān)指針(NextStage＝-1)，表示C的下一關(guān)將結(jié)束流程。接著，進(jìn)入步驟136中，更新文件需求單狀態(tài)表中的文件需求單狀態(tài)值為結(jié)案(FormId＝11，RecordID＝23，UserID＝A，StatusID＝107)。然后，進(jìn)入步驟138中，系統(tǒng)執(zhí)行歸檔處理，將此文件需求單于電子記錄表格單、文件需求單狀態(tài)表及流程記錄表上的各筆記錄分別移至電子表格歸檔表、文件需求單狀態(tài)歸檔表、流程記錄歸檔表。接著，進(jìn)入步驟140中，系統(tǒng)發(fā)電子信件通知申請(qǐng)者文件需求單已辦理完成。
至于本發(fā)明的文件簽核同意的方法流程，在此將以圖2說(shuō)明如下。在圖2中，首先，在步驟202中，取得當(dāng)前用戶信息。接著，進(jìn)入步驟204中，取得文件需求單的類(lèi)型號(hào)(FormID)及記錄號(hào)(RecordID)。然后，進(jìn)入步驟206中，查詢文件需求單狀態(tài)表中的當(dāng)前處理者為誰(shuí)。接著，進(jìn)入步驟208中，判斷用戶是否為當(dāng)前處理者，若是，進(jìn)入下一步驟，否則的話，結(jié)束本方法。
然后，進(jìn)入步驟210中，更新流程記錄表中的當(dāng)前處理者的處理動(dòng)作為同意(ActionType＝102)，并且記下處理時(shí)間(ActionDateTime)、處理意見(jiàn)(Instruct)及處理所在IP地址。接著，進(jìn)入步驟211中，如果處理意見(jiàn)微為不同意，則此文件需求單返回給申請(qǐng)者。然后，進(jìn)入在步驟212中，將此動(dòng)作信息寫(xiě)入事件記錄表中。然后，進(jìn)入步驟214中，依照流程模板表取得當(dāng)前關(guān)的相關(guān)信息。接著，進(jìn)入步驟216中，判斷當(dāng)前關(guān)是否為最后一關(guān)，若是，進(jìn)入步驟218，否則的話，進(jìn)入步驟222。
在步驟218中，更新文件需求單狀態(tài)表的狀態(tài)值為結(jié)案(StatusID＝107)。接著，進(jìn)入步驟220中，進(jìn)行歸檔處理，并結(jié)束本方法。
另外，在步驟222中，取出下一關(guān)處理者。接著，進(jìn)入步驟224中，判斷此處理者是否已經(jīng)處理過(guò)文件需求單。若是，則進(jìn)入步驟226中，更新流程記錄表并回到步驟216中。否則的話，進(jìn)入步驟228中，更新文件需求單狀態(tài)表下一關(guān)處理者及當(dāng)前狀態(tài)值。接著，進(jìn)入步驟230中，判斷當(dāng)前狀態(tài)值是否為結(jié)案。若是，進(jìn)入步驟220中，執(zhí)行歸檔處理并結(jié)束本方法。否則的話，回到步驟202中，重新取得用戶信息。
至于本發(fā)明的文件歸檔之方法流程，在此將以圖3說(shuō)明如下。在圖3中，首先，在步驟302中，取得當(dāng)前用戶信息。接著，在步驟304中，取得文件需求單的類(lèi)型號(hào)(FormID)及記錄號(hào)(RecordID)。然后，進(jìn)入步驟306中，判斷表單是否在處理中，表單例如是電子記錄表格單、流程記錄表及文件需求單狀態(tài)表。接著，進(jìn)入步驟308中，將電子記錄表格單中的記錄復(fù)制至電子表格歸檔表。然后，進(jìn)入步驟310中，刪除電子記錄表格單。
接著，進(jìn)入步驟312中，將流程記錄表中的記錄復(fù)制至流程記錄歸檔表。然后，進(jìn)入步驟314中，刪除流程記錄表。接著，進(jìn)入步驟316中，將文件需求單狀態(tài)表中的記錄復(fù)制至文件需求單狀態(tài)歸檔表。然后，進(jìn)入步驟318中，刪除文件需求狀態(tài)表。接著，進(jìn)入步驟320中，根據(jù)實(shí)際要求發(fā)送電子信件通知相關(guān)人員，本方法終告結(jié)束。
在實(shí)際情況中，有些文件需求單需要會(huì)簽的模式，即文件需求單同時(shí)傳遞給相關(guān)簽核者進(jìn)行簽核，如簽核者A→簽核者B及簽核者C→簽核者D，此種情況的實(shí)現(xiàn)方法必須采用指針來(lái)設(shè)計(jì)流程模板表。在流程模板表和流程記錄表中設(shè)計(jì)三個(gè)欄位FlowID代表流程記錄號(hào)的唯一標(biāo)示、CurrStage代表當(dāng)前關(guān)及NextStage代表下一關(guān)，如圖4所示。
首先，在步驟402中，F(xiàn)lowID＝101，而CurrStage＝0，表示當(dāng)前關(guān)為用戶申請(qǐng)者開(kāi)始申請(qǐng)一文件需求單。其中，下一關(guān)NextStage＝102，則從流程模板表中查找出此文件需求單條件為CurrStage＝102的所有記錄信息(簽核群組)，在利用群組表查找出所有需要簽核者，如簽核者A。再將簽核者A的信息添加至流程記錄表、文件需求單狀態(tài)表中，此時(shí)文件需求單便從申請(qǐng)者傳至A處。
接著，進(jìn)入步驟404中，F(xiàn)lowID＝102，而CurrStage＝102，且簽核者A同意此文件需求單。其中，下一關(guān)NextStage＝103，則從流程模板表中查找出此文件需求單條件為CurrStage＝103的所有記錄信息(簽核群組)，在利用群組表查找出所有需要簽核者，如簽核者B及C。再將簽核者B及C的信息添加至流程記錄表、文件需求單狀態(tài)表中，此時(shí)文件需求單便從A傳至B及C處。
然后，進(jìn)入步驟406中，F(xiàn)lowID＝103，而CurrStage＝103，且簽核者B同意此文件需求單。其中，下一關(guān)NextStage＝104，則從流程模板表中查找出此文件需求單條件為CurrStage＝104的所有記錄信息(簽核群組)，在利用群組表查找出所有需要簽核者，如簽核者D。再將簽核者D的信息添加至流程記錄表、文件需求單狀態(tài)表中，此時(shí)文件需求單便從B傳至D處。
同時(shí)，在步驟408中，F(xiàn)lowID＝104，而CurrStage＝103，且簽核者C同意此文件需求單。其中，下一關(guān)NextStage＝104，則從流程模板表中查找出此文件需求單條件為CurrStage＝104的所有記錄信息(簽核群組)，在利用群組表查找出所有需要簽核者，如簽核者D。再將簽核者D的信息添加至流程記錄表、文件需求單狀態(tài)表中，此時(shí)文件需求單便從C傳至D處。
接著，進(jìn)入步驟410中，F(xiàn)lowID＝105，而CurrStage＝104，且簽核者D同意此文件需求單。其中，下一關(guān)NextStage＝-1，表示下一關(guān)為最后一關(guān)。然后，進(jìn)入步驟412中，F(xiàn)lowID＝105，而CurrStage＝-1，表示當(dāng)前關(guān)為最后一關(guān)并終告結(jié)束。
某些情況，文件需求單在退件后不希望立即被退出處理過(guò)程，而是可以循環(huán)往復(fù)的被處理，這就是退簽。如一份文件需求單簽核過(guò)程應(yīng)為A→B→C，而B(niǎo)在預(yù)覽(Review)時(shí)覺(jué)得申請(qǐng)內(nèi)容不全便做退簽處理。則此時(shí)流程可能為A→B→A→B→C。退簽實(shí)現(xiàn)若采用類(lèi)似上述指針?lè)椒ㄒ埠苋菀?，只要在流程模板表和流程記錄表中增加可退簽的關(guān)指針(BackStage)欄位即可。它代表當(dāng)前關(guān)可退簽至哪些關(guān)，這些關(guān)之間用″，″分隔開(kāi)。例如A的CurrStage＝101，NextStage＝102；B的CurStage＝102，NextStage＝103，BackStage＝101。則當(dāng)B退簽時(shí)，系統(tǒng)根據(jù)BackStage值應(yīng)從流程模板表中取出CurrStage＝101的處理群組。得到處理人員A后，便將A添加至流程記錄表、文件需求單狀態(tài)表中，此時(shí)文件需求單便從B退回至A處。
四、群組管理[群組設(shè)計(jì)的目的]群組的設(shè)計(jì)是為以后的流程設(shè)計(jì)做準(zhǔn)備的。結(jié)合實(shí)際情況來(lái)看，公司的組織是架構(gòu)在一棵縱向的樹(shù)結(jié)構(gòu)上。各種各樣的橫向關(guān)系無(wú)法準(zhǔn)確地及適時(shí)地表達(dá)出來(lái)，而流程在很多情況下是要流經(jīng)這些橫向關(guān)系的節(jié)點(diǎn)。舉例而言，假設(shè)員工A作為部門(mén)Dept1的主管，同時(shí)也是項(xiàng)目Proj1的負(fù)責(zé)人，亦同時(shí)負(fù)責(zé)監(jiān)督本部門(mén)ISO工作，那他就有多重身份(職務(wù))。因?yàn)楦魑募枨髥瘟鞒淌墙y(tǒng)一設(shè)計(jì)的，在不同的流程中分辨這些身份就成為難題。所以為簡(jiǎn)化流程設(shè)計(jì)考慮，本發(fā)明決定流程所流過(guò)的每一節(jié)點(diǎn)將用群組來(lái)表示，但是非常特殊情況的還是要除外來(lái)處理，且群組由設(shè)定程序統(tǒng)一維護(hù)。
在許多情況下，流程中的某一步是只會(huì)牽涉到固定的一批人員的，這批固定人員的集合就是一個(gè)″固定群組″。用戶在提交文件需求單時(shí)會(huì)被要求將流程中每一步的簽核者從群組中挑選出來(lái)，群組在此限定了有權(quán)限充當(dāng)此職務(wù)的人員的范圍。程序一般也會(huì)通過(guò)代理人制度給予每個(gè)群組一位缺省人員，固定群組由兩張數(shù)據(jù)庫(kù)表構(gòu)成，其主要字段如下(1)群組信息表(P_GroupInfoTab)登記了各個(gè)群組的信息。


(2)群組子表(P_GroupMembersTab)用以容納群組的成員。

從群組子表的設(shè)計(jì)可以看出，固定群組的實(shí)現(xiàn)是嵌套式的，且一個(gè)群組是由若干人員和(或)若干子群組所構(gòu)成。
固定群組定義為一個(gè)若干人員的集合，是有缺陷的。缺陷就是通用性差，因?yàn)樗鼰o(wú)法表達(dá)任何邏輯關(guān)系。舉例而言，因?yàn)楣居泻芏嗖块T(mén)，所以″部門(mén)主管″對(duì)每一位員工來(lái)說(shuō)不可能都相同，唯有定義″邏輯群組″才能解決這種需求。群組是共享的，所以邏輯群組的被定義為通過(guò)傳入特定的參數(shù)，返回特定結(jié)構(gòu)的人員數(shù)據(jù)。而且不同于固定群組的是，邏輯群組是動(dòng)態(tài)的，只有需要它時(shí)，它才能產(chǎn)生出人員來(lái)。結(jié)合代理人制度，它甚至可以無(wú)須通過(guò)用戶指定而自動(dòng)產(chǎn)生唯一的處理人來(lái)。
邏輯群組沒(méi)有嵌套的子群組，其實(shí)現(xiàn)方式說(shuō)明如下(1)邏輯群組信息表(P_LogicGroupInfoTab)


需要注意的是，上述邏輯關(guān)系用帶n個(gè)<WC@USERID></WC@USERID>標(biāo)識(shí)(n≥0)的SQL語(yǔ)句存放于字段SQLCmd中。使用時(shí)傳入相應(yīng)員工UserID，并替換掉每個(gè)<WC@USERID><WC@USERID>，再執(zhí)行此語(yǔ)句就可以得到簽核者的信息。
例如″部門(mén)主管″群組的寫(xiě)法如下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>
))))五、代理人制度某些情況文件需求單處理人員不在公司，此時(shí)為了讓文件需求單仍能順利地流傳，需要設(shè)計(jì)代理人數(shù)據(jù)庫(kù)，將積壓在原處理者的文件需求單轉(zhuǎn)至其相應(yīng)的代理人去處理。
(1)適用對(duì)象簽核者、辦理者和行政助理。
(2)代理規(guī)則(a)原則上代理人只能指定本人行政級(jí)別的上下一級(jí)人員。
(b)可以指定兩級(jí)代理，這種指定在群組中做定義。
(c)代理形式有兩種，立即代理和指定日期的代理。
(3)控制條件(a)群組的行政級(jí)別(P_GroupInfoTab.AdministrantLevel)

(b)群組的代理級(jí)別(P_GroupInfoTab.AgentLevel)

(4)表格結(jié)構(gòu)如下P_AgentMainTab為主表，主要記錄其人有無(wú)代理，如下表所示。
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------UserID Int(4) Not Null被代理人工號(hào)ID，Primary KeyDateFrom Datetime(8)代理開(kāi)始時(shí)間DateTo Datetime(8)代理結(jié)束時(shí)間AgentMode Tinyint(1)Not Null代理方式1-無(wú)日期0--有日期----------------------------------------------------------------------------------------------------------------------------------------------------------------------P_AgentListTab記錄代理人，如下表所示。
-------------------------------------------------------------------------------------------------------------------------------------------------------------UserID Int(4)Not Null被代理人工號(hào)IDDepartmenInt(4)被代理的部門(mén)AgentLeve Int(4)Not Null代理級(jí)別(1一級(jí)、2二級(jí))AgentUserID Int(4)Not Null代理人UserID-------------------------------------------------------------------------------------------------------------------------------------------------------------AgentLevel代理范圍

(5)文件需求單流傳至處理人的代理者的處理流程，如下所述(a)取得文件需求單下一關(guān)的處理者A。
(b)取得A用戶的職務(wù)和所在部門(mén)。
(c)判斷A用戶是否有權(quán)指定代理。
(d)若A指定了代理，將A的代理人B找出來(lái)。
(e)將B的信息寫(xiě)入流程記錄表的實(shí)際處理者(ActionID)欄位中，說(shuō)明B成為文件需求單的實(shí)際處理者。
(f)將A的信息寫(xiě)入流程記錄表的原先處理者(OriginUserID)欄位中，說(shuō)明A為原先的處理者。
(g)將B的信息更新至文件需求單狀態(tài)表的當(dāng)前處理者(DealUserID)欄位中，這樣文件需求單順利得從A流傳至其代理者B處。
為使文件需求單順暢的執(zhí)行，系統(tǒng)還需如下功能
(a)在SERVER端運(yùn)行的郵件發(fā)送程序，它的功能是定期掃描郵件緩沖表，將各文件需求單產(chǎn)出的各種報(bào)表、通知等發(fā)送至相關(guān)人員。
(b)在有簽核或辦理權(quán)限的客戶端設(shè)計(jì)一文件需求單檢查程序，它的功能是定期掃描文件需求單狀態(tài)表，若有文件需求單需用戶處理，則彈出視窗提示用戶有文件需求單待處理。
(c)設(shè)計(jì)系統(tǒng)設(shè)定程序，它的功能是對(duì)系統(tǒng)參數(shù)設(shè)定、群組設(shè)定、各類(lèi)文件需求單流程模板設(shè)定此系統(tǒng)與NT用戶驗(yàn)證整合，可實(shí)現(xiàn)自動(dòng)登入。
本發(fā)明上述實(shí)施例所揭示利用數(shù)據(jù)庫(kù)和網(wǎng)頁(yè)來(lái)實(shí)現(xiàn)基于瀏覽器的ISO文件發(fā)行系統(tǒng)及方法，具有下列優(yōu)點(diǎn)1.ISO文件實(shí)現(xiàn)電子化管理并且被分類(lèi)組織、存放，這使得文件可以被方便地檢索。
2.ISO文件審批自動(dòng)流轉(zhuǎn)，系統(tǒng)會(huì)自動(dòng)地將ISO文件傳遞至下一個(gè)文件處理人員。
3.只需數(shù)據(jù)庫(kù)技術(shù)即可實(shí)現(xiàn)電子化，系統(tǒng)維護(hù)方便，客戶端只需要一瀏覽器既可使用該系統(tǒng)。
4.采用標(biāo)準(zhǔn)的三層架構(gòu)在服務(wù)器端對(duì)事件處理并將有用的數(shù)據(jù)傳回客戶端。
綜上所述，雖然本發(fā)明已以一較佳實(shí)施例揭示如上，然其并非用以限定本發(fā)明，任何熟悉本技術(shù)領(lǐng)域者，在不脫離本發(fā)明的精神和范圍內(nèi)，當(dāng)可作各種的更動(dòng)與潤(rùn)飾，因此本發(fā)明的保護(hù)范圍當(dāng)視后附的權(quán)利要求書(shū)所界定者為準(zhǔn)。
權(quán)利要求
1.一種ISO文件發(fā)行管理方法，用于一ISO文件發(fā)行系統(tǒng)中，該方法包括設(shè)定一流程模板表中的流程依序?yàn)橐簧暾?qǐng)者及至少一簽核者；該申請(qǐng)者提交一文件需求單，且該文件需求單被分配有一類(lèi)型號(hào)(FormID)及一記錄號(hào)(RecordID)；寫(xiě)入該申請(qǐng)者的提交動(dòng)作信息于相對(duì)于該文件需求單的一流程記錄表及一事件記錄表的一動(dòng)作值(ActionType)欄位中；依照該流程模板表取出該簽核者，并將該簽核者的相關(guān)信息寫(xiě)入該流程記錄表中；產(chǎn)生相對(duì)于該文件需求單的一文件需求單狀態(tài)表中的記錄，而寫(xiě)入該簽核者于該文件需求單狀態(tài)表中的一當(dāng)前處理者(DealUserID)欄位中，且該文件需求單狀態(tài)表中的一狀態(tài)值(StatusID)為待處理中；一用戶瀏覽該文件需求單狀態(tài)表中的記錄并同意該文件需求單；判斷該用戶是否為該當(dāng)前處理者，若是，寫(xiě)入該用戶的同意動(dòng)作信息于該流程記錄表及該事件記錄表的該動(dòng)作值欄位中；以及依照該流程模板表更新該狀態(tài)值為結(jié)案，并執(zhí)行歸檔處理。
2.如權(quán)利要求1所述的方法，其特征在于，還包括一ISO文件簽核同意方法，如下所述(a)取得該用戶的信息；取得該文件需求單的該類(lèi)型號(hào)及該記錄號(hào)；查詢?cè)撐募枨髥螤顟B(tài)表中的該當(dāng)前處理者；判斷該用戶是否為該當(dāng)前處理者，若是，更新該流程記錄表中的該當(dāng)前處理者的同意動(dòng)作信息，并記下一處理時(shí)間、一處理意見(jiàn)、一處理所在IP地址；于該處理意見(jiàn)為不同意時(shí)返回該文件需求單給申請(qǐng)者；寫(xiě)入該當(dāng)前處理者的同意動(dòng)作信息于該事件記錄表中；依照該流程模板表取得一當(dāng)前關(guān)的相關(guān)信息；(b)判斷該當(dāng)前關(guān)是否為最后一關(guān)，若是，更新該文件需求單狀態(tài)表的該狀態(tài)值為結(jié)案并進(jìn)行歸檔處理，否則，進(jìn)入步驟(c)；(c)取出一下一關(guān)處理者并判斷該下一關(guān)處理者是否已經(jīng)處理過(guò)該文件需求單，若是，更新該流程記錄表并回到步驟(b)，否則，進(jìn)入步驟(d)；以及(d)更新該文件需求單狀態(tài)表的該下一關(guān)處理者及該狀態(tài)值，并判斷該狀態(tài)值是否為結(jié)案，若是，進(jìn)行歸檔處理，否則，回到步驟(a)。
3.如權(quán)利要求1所述的方法，其特征在于，還包括一ISO文件歸檔方法，如下所述取得該用戶的信息；取得該文件需求單的該類(lèi)型號(hào)及該記錄號(hào)；判斷相對(duì)于該文件需求單的至少一電子記錄表格單、該流程記錄表及該文件需求單狀態(tài)表是否正在被處理中，若否，復(fù)制該電子記錄表格單中的記錄至一電子表格歸檔并刪除該電子記錄表格單；復(fù)制該流程記錄表中的記錄至一流程記錄歸檔表并刪除該流程記錄表；復(fù)制該文件需求單狀態(tài)表中的記錄至一文件需求單狀態(tài)歸檔表并刪除文件需求狀態(tài)表；以及發(fā)送至少一電子信件以通知該申請(qǐng)者及相關(guān)人員。
4.如權(quán)利要求1所述的方法，其特征在于，還包括一代理人審核同意方法，如下所述取得該文件需求單的下一關(guān)處理者；取得該下一關(guān)處理者的職務(wù)及所在部門(mén)；判斷該下一關(guān)處理者是否有權(quán)指定一代理人，若有，將該代理人的信息寫(xiě)入該流程記錄表的一實(shí)際處理者(ActionID)欄位中，用以說(shuō)明該代理人成為該文件需求單的實(shí)際處理者；將該下一關(guān)處理者的信息寫(xiě)入該流程記錄表的一原先處理者(OriginUserID)欄位中，用以說(shuō)明該下一關(guān)處理者為原先的處理者；以及將該代理人的信息更新至該文件需求單狀態(tài)表的一當(dāng)前處理者(DealUserID)欄位中，使得該文件需求單可以由該下一關(guān)處理者流傳至該代理人處。
5.如權(quán)利要求1所述的方法，其特征在于，還包括一ISO文件會(huì)簽方法，如下所述該申請(qǐng)者申請(qǐng)?jiān)撐募枨髥?，且該流程記錄表具有第一?dāng)前關(guān)指針(CurrStage)及下一關(guān)指針(NextStage)；從該流程模板表中找出第二當(dāng)前關(guān)指針為該下一關(guān)指針的至少一簽核群組；利用一群組表查找出該簽核群組中的至少一簽核者；以及將該簽核者的信息添加至該流程記錄表、該文件需求單狀態(tài)表中，使得該文件需求單由該申請(qǐng)者傳至該簽核者處。
6.如權(quán)利要求5所述的方法，其特征在于，其中該第一當(dāng)前關(guān)指針的值為0。
7.如權(quán)利要求5所述的方法，其特征在于，其中該下一關(guān)指針的值為-1。
8.如權(quán)利要求5所述的方法，其特征在于，其中該第二當(dāng)前關(guān)指針的值為-1。
9.如權(quán)利要求1所述的方法，其特征在于，還包括一ISO文件退簽方法，如下所述該簽核者不同意該文件需求單，且該流程記錄表具有一第一當(dāng)前關(guān)指針(CurrStage)及一退簽關(guān)指針(BackStage)；從該流程模板表中找出第二當(dāng)前關(guān)指針為該退簽關(guān)指針的該申請(qǐng)者；以及將該申請(qǐng)者的信息添加至該流程記錄表、該文件需求單狀態(tài)表中，使得該文件需求單由該簽核者退回傳至該申請(qǐng)者處。
10.如權(quán)利要求1所述的方法，其特征在于，其中該ISO文件發(fā)行系統(tǒng)至少包含一瀏覽器、一服務(wù)器及一數(shù)據(jù)庫(kù)。
11.如權(quán)利要求7所述的方法，其特征在于，其中于該用戶瀏覽該文件需求單狀態(tài)表中之記錄并同意該文件需求單之前，又包括以下步驟；該用戶登入該ISO文件發(fā)行管理系統(tǒng)；該系統(tǒng)將從該文件需求單狀態(tài)表中查到該文件需求單需要該用戶來(lái)處理；該系統(tǒng)在該用戶的一客戶端之該瀏覽器上生成一網(wǎng)頁(yè)連結(jié)；以及該用戶藉由該瀏覽器點(diǎn)擊該網(wǎng)頁(yè)連結(jié)，使得該系統(tǒng)生成該文件需求單的詳細(xì)信息的網(wǎng)頁(yè)。
12.如權(quán)利要求7所述的方法，其特征在于，其中于該文件需求單被申請(qǐng)發(fā)行前，又包括設(shè)計(jì)一表單類(lèi)型信息表、一文件需求單信息表及一附件表于該數(shù)據(jù)庫(kù)中。
13.如權(quán)利要求7所述的方法，其特征在于，其中于該文件需求單被申請(qǐng)發(fā)行成功后，又包括設(shè)計(jì)相對(duì)于該文件需求單的一文件信息表、一文件歸屬表該數(shù)據(jù)庫(kù)中。
14.如權(quán)利要求7所述的方法，其特征在于，又包括備份該數(shù)據(jù)庫(kù)中的資料并復(fù)制該服務(wù)器中的資料至一指定路徑中。
15.如權(quán)利要求1所述的方法，其特征在于，其中于該文件需求單狀態(tài)表的記錄包含該申請(qǐng)者、該類(lèi)型號(hào)、該記錄號(hào)、該當(dāng)前處理者及該狀態(tài)值。
16.如權(quán)利要求1所述的方法，其特征在于，其中該文件需求單具有一表格分頁(yè)、一附件分頁(yè)、一流程記錄分頁(yè)及一分享人員分頁(yè)。
全文摘要
本發(fā)明涉及一種ISO文件發(fā)行管理系統(tǒng)及方法。設(shè)定流程模板表，并提交文件需求單。寫(xiě)入提交動(dòng)作信息于流程記錄表及事件記錄表的動(dòng)作值欄位中。依照流程模板表寫(xiě)入簽核者的信息于流程記錄表中。產(chǎn)生文件需求單狀態(tài)表中的記錄，而寫(xiě)入簽核者于文件需求單狀態(tài)表中的當(dāng)前處理者欄位中。用戶瀏覽記錄并同意文件需求單。判斷用戶是否為當(dāng)前處理者，若是，寫(xiě)入同意動(dòng)作信息于動(dòng)作值欄位中。更新文件需求單狀態(tài)表的狀態(tài)值為結(jié)案，并執(zhí)行歸檔。
文檔編號(hào)G06F17/30GK1485768SQ0213712
公開(kāi)日2004年3月31日 申請(qǐng)日期2002年9月25日 優(yōu)先權(quán)日2002年9月25日
發(fā)明者賴(lài)振興, 徐小南, 葉波 申請(qǐng)人:英業(yè)達(dá)集團(tuán)(南京)電子技術(shù)有限公司