國際標準化組織文件發行管理系統及方法
2023-05-27 05:29:21 1
專利名稱：國際標準化組織文件發行管理系統及方法
技術領域：
本發明有關於一種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＝ShowRecordFormID＝11RecordID＝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＝ShowRecordFormID＝11RecordID＝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@USERIDWC@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日
發明者賴振興, 徐小南, 葉波 申請人:英業達集團(南京)電子技術有限公司