(57)【要約】【課題】電子決裁システムにおいて、承認案件を回覧対象者全員に本来の順序で回覧しつつ回覧対象者全員が承認するまでのリードタイムを短縮する。【解決手段】この電子決裁システムのサーバ１は、起案票をＬＡＮ３上の承認者へ順次回覧する場合、回覧される起案票の情報をＬＡＮ３上で承認者に対して閲覧可能に公開し、公開した起案票の中で承認者自身に回覧される予定の起案票に対する承認条件が承認者から入力されると、入力された該当起案票の承認条件を承認者毎に予約承認条件テーブル３０に記憶しておき、起案票が当該承認者に回ると、予約承認条件テーブル３０の該当承認者の承認条件をチェックし、承認者が予め登録しておいた承認条件を満たしていた場合、当該起案票の承認処理を行う一方、承認条件を満たしていない起案票については承認者による承認操作待ちとするサーバソフト１０を備える。【選択図】      図２
2004258960.tif 000002
【特許請求の範囲】
【請求項１】
回覧対象の承認者への承認案件を回覧ルートに従いネットワーク上の承認者へ順次回覧する承認案件回覧手段と、
前記承認案件回覧手段により回覧される承認案件の情報を該当承認者に対して前記ネットワーク上で閲覧可能に公開する承認案件情報公開手段と、
前記承認案件情報公開手段により公開された承認案件の中で承認者自身に回覧される予定の承認案件に対する承認条件の入力を促す手段と、
入力された該当承認案件の承認条件を承認者毎に記憶する承認条件記憶手段と、
前記承認案件回覧手段により承認者に承認案件が回覧された場合、前記承認条件記憶手段に記憶されている当該承認者の承認条件をチェックし、前記承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、前記承認条件を満たしていない承認案件については承認者による承認操作待ちとする承認手段とを具備したことを特徴とする承認システム。
【請求項２】
承認案件が承認者に回覧された時点から承認処理を実行するまでの時間情報を承認条件の一つとして用いたことを特徴とする請求項１記載の承認システム。
【請求項３】
承認案件に対して承認予約を行った日時情報を承認条件の一つとして用いたことを特徴とする請求項１記載の承認システム。
【請求項４】
承認案件に指定されている項目毎に承認条件を付与することを特徴とする請求項１記載の承認システム。
【請求項５】
ネットワークに接続された承認システムに処理を実行させる承認プログラムにおいて、
前記承認システムを、
回覧対象の承認者への承認案件を回覧ルートに従いネットワーク上の承認者へ順次回覧する承認案件回覧手段と、
前記承認案件回覧手段により回覧される承認案件の情報を当該承認者に対して前記ネットワーク上で閲覧可能に公開する承認案件情報公開手段と、
前記承認案件情報公開手段により公開された承認案件の中で承認者自身に回覧される予定の承認案件に対する承認条件の入力を促す手段と、
入力された当該承認案件の承認条件を承認者毎に記憶する承認条件記憶手段と、
前記承認案件回覧手段により承認者に承認案件が回覧された場合、前記承認条件記憶手段に記憶されている当該承認者の承認条件をチェックし、前記承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、前記承認条件を満たしていない承認案件については承認者による承認操作待ちとする承認手段
として機能させることを特徴とする承認プログラム。
【請求項６】
回覧対象の承認者への承認案件の情報を承認システムが前記承認者に対してネットワーク上で閲覧可能に公開するステップと、
前記承認システムによりネットワーク上に公開された承認案件の中で承認者自身に回覧される予定の承認案件に対する承認条件の入力を促すステップと、
入力された当該承認案件の承認条件を承認者毎に前記承認システムに記憶するステップと、
前記承認案件が承認者に回覧された場合、前記承認システムが当該承認者の承認条件をチェックし、前記承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、前記承認条件を満たしていない承認案件については承認者による承認操作待ちとするステップと
を有することを特徴とする承認方法。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、例えば電子決裁システムなどにおいて、回覧対象の承認案件を承認者へ順に回覧する承認システム、承認プログラム、承認方法に関する。
【０００２】
【従来の技術】
回覧対象の文書を回覧対象者に順に回付（以下回覧と称す）するワークフロー装置が開示されている。（例えば特許文献１参照）。
【０００３】
このワークフロー装置には、ある書類についての初期設定の回覧ルート（通常モード）の他に、少なくとも一つの回覧ルート（急行モード、特急モードなど）が用意されており、書類の処理の緊急度に応じて、いずれかの回覧ルートを選択すると、選択された回覧ルートになるよう回覧ルートの設定を自動的に変更する自動回覧モード設定機能が備えられている。
このワークフロー装置の場合、緊急時には、初期設定とは別の回覧ルートで書類を回覧することで、回覧リードタイムの短縮化を図ることができる。
【０００４】
【特許文献１】
特開平１０−３０１９９８号公報（図３）
【０００５】
【発明が解決しようとする課題】
しかしながら、特許文献１に記載されているワークフロー装置の場合、緊急時には初期設定の回覧ルート以外の回覧ルートで書類が回覧されてしまうことから、もともと初期設定の回覧ルートに含まれていた回覧対象者に書類が回らなくなることがある。
このように回覧対象者に書類が回らない場合、一般的な確認事項程度の回覧であれば、さほど問題にはならないものの、電子決裁システムのように、承認用の書類を回覧する場合には、本来の「承認」という目的が達成できなくなる恐れがある。
【０００６】
本発明はこのような課題を解決するためになされたもので、承認案件を回覧対象者全員に本来の順序で回覧しつつ回覧対象者全員が承認するまでのリードタイムを短縮することのできる承認システム、承認プログラム、承認方法を提供することを目的としている。
【０００７】
【課題を解決するための手段】
上記した目的を達成するために、本発明の承認システムは、回覧対象の承認者への承認案件を回覧ルートに従いネットワーク上の承認者へ順次回覧する承認案件回覧手段と、前記承認案件回覧手段により回覧される承認案件の情報を当該承認者に対して前記ネットワーク上で閲覧可能に公開する承認案件情報公開手段と、前記承認案件情報公開手段により公開された承認案件の中で自身に回覧される予定の承認案件に対する承認条件の入力を促す手段と、入力された当該承認案件の承認条件を承認者毎に記憶する承認条件記憶手段と、前記承認案件回覧手段により承認者に承認案件が回覧された場合、前記承認条件記憶手段に記憶されている当該承認者の承認条件をチェックし、前記承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、前記承認条件を満たしていない承認案件については承認者による承認操作待ちとする承認手段とを具備したことを特徴としている。
なお、承認案件が承認者に回覧された時点から承認処理を実行するまでの時間情報を承認条件の一つとして用いたり、承認案件に対して承認予約を行った日時情報を承認条件の一つとして用いても良い。また、承認案件に指定されている項目毎に承認条件を付与しても良い。
【０００８】
本発明の承認プログラムは、承認システムに処理を実行させる承認プログラムにおいて、前記承認システムを、回覧対象の承認者への承認案件を回覧ルートに従いネットワーク上の承認者へ順次回覧する承認案件回覧手段と、前記承認案件回覧手段により回覧される承認案件の情報を当該承認者に対して前記ネットワーク上で閲覧可能に公開する承認案件情報公開手段と、前記承認案件情報公開手段により公開された承認案件の中で自身に回覧される予定の承認案件に対する承認条件の入力を促す手段と、入力された当該承認案件の承認条件を承認者毎に記憶する承認条件記憶手段と、前記承認案件回覧手段により承認者に承認案件が回覧された場合、前記承認条件記憶手段に記憶されている当該承認者の承認条件をチェックし、前記承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、前記承認条件を満たしていない承認案件については承認者による承認操作待ちとする承認手段として機能させることを特徴としている。
【０００９】
本発明の承認方法は、回覧対象の承認者への承認案件の情報を承認システムが前記承認者に対してネットワーク上で閲覧可能に公開するステップと、前記承認システムによりネットワーク上に公開された承認案件の中で承認者自身に回覧される予定の承認案件に対する承認条件の入力を促すステップと、入力された承認案件の承認条件を承認者毎に前記承認システムに記憶するステップと、前記承認案件が承認者に回覧された場合、前記承認システムが当該承認者の承認条件をチェックし、前記承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、前記承認条件を満たしていない承認案件については承認者による承認操作待ちとするステップとを有することを特徴としている。
【００１０】
本発明では、承認システムによりネットワーク上に公開された承認案件の中で承認者自身に回覧される予定の承認案件に対する承認条件が承認者によって入力されると、当該承認案件の承認条件を承認者毎に承認システムが記憶する。
そして、承認案件が承認者に回覧された場合、承認システムが当該承認者の承認条件をチェックし、承認者の承認条件を満たした場合、当該承認案件の承認処理を行う一方、承認条件を満たしていない場合は承認者による承認操作待ちとするので、承認案件を回覧対象者全員に本来の順序で回覧しつつ回覧対象者全員が承認するまでのリードタイムを短縮することができる。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態を図面を参照して詳細に説明する。図１は本発明に係る一つの実施形態の電子決裁システムのハードウェア構成を示す図である。
図１に示すように、この電子決裁システムは、サーバコンピュータとしてのワークフローサーバ１（以下サーバ１と称す）と、複数のクライアントコンピュータとしてのクライアント２ａ〜２ｃとをＬＡＮ３などの通信網に接続して構成されている。
サーバ１とクライアント２ａ〜２ｃは、ＣＰＵ、メモリ、ハードディスク装置、ＬＡＮインターフェース装置、キーボード、表示装置等を備えるコンピュータであり、ハードディスク装置にオペレーティングシステム（ＯＳ）の他、各種アプリケーションプログラムを格納している。
サーバ１のハードディスク装置１ａには、ワークフローサーバソフトウェア１０（以下サーバソフト１０と称す）と、ワークフロー情報を記憶したワークフロー情報記憶部１１、回覧対象の承認案件である起案票のデータを記憶した承認案件記憶部１２、予約承認条件テーブル３０などが格納されている。ワークフロー情報記憶部１１に記憶されているワークフロー情報は、回覧対象の起案票をどのように回覧するかといった回覧ルートを取り決めた情報であり、サーバソフト１０は、このワークフロー情報記憶部１１のワークフロー情報に基づいて起案票の回覧処理を実行する。
サーバソフト１０は、ＨＴＴＰサーバ機能、ワークフロー管理機能を有している。ＨＴＴＰサーバ機能は、各クライアント２ａ〜２ｃからの各種要求の受け付けを行う機能と、受け付けた要求に対する応答をクライアント２ａ〜２ｃへ送信する機能である。ワークフロー管理機能は、各クライアント２ａ〜２ｃを利用するユーザによって承認・否認された際には次の回覧対象者へ起案票を回覧する承認回覧制御機能であり、いわゆるワークフローエンジンと呼ばれる機能である。
【００１２】
サーバソフト１０は、自身に登録された起案票をＬＡＮ３上の承認者へ順次回覧する。サーバソフト１０は、回覧対象として承認案件記憶部１２に登録された起案票のデータを回覧対象者である承認者がＬＡＮ３上で閲覧可能に、例えばメニュー画面（図３参照）からのリンクで承認予約可能案件一覧画面（図４参照）を公開し、公開した承認予約可能案件一覧画面の中で所望の案件名が選択操作されたことで、承認者に回覧される予定の起案票のデータ（図５参照）を表示し、起案票のデータ（内容）についての承認予約を行う操作を促し、承認者により承認予約の操作が行われると、承認予約された該当起案票のデータを該当承認者の承認条件のデータとして予約承認条件テーブル３０（図６参照）に記憶（登録）する。なお、起案票のデータ（内容）についての承認予約を行う操作には、起案票の（内容）データを変更した後、承認予約を行う操作も含まれる。
予約承認条件テーブル３０には、承認者の固有の識別情報、つまりユーザＩＤに対応して案件ＩＤ、使用目的、申請金額、承認予約を行った日時などの承認条件が設定される。案件ＩＤとは起案票を一意に特定するための情報である。
【００１３】
サーバソフト１０は、起案票が該当承認者に回ると、承認案件記憶部１２に記憶されている起案票のデータを読み出して、起案票のデータ（使用目的：交通費、申請金額：１２００円）と予約承認条件テーブル３０の該当承認者（ユーザＩＤ）の承認条件（使用目的のデータ（交通費）、申請金額のデータ（１２００円））とを照合し、起案票のデータが承認者の承認条件を満たしているか否かをチェックする。なお、この場合のチェックとは、起案票の使用目的、申請金額等の各項目のデータと承認条件のデータとが一致しているか否かのチェックである。
そして、このチェック結果、起案票の各項目のデータが承認者が予約を入れた承認条件を満たしていた場合、サーバソフト１０は、当該起案票に対する承認処理を行い、承認処理が正しく終了すると、該当起案票を次の承認者へ回覧する一方、予約承認条件テーブル３０の承認条件を満たしていない起案票については承認者による承認操作待ちとする。
【００１４】
クライアント２ａ〜２ｃのハードディスク装置には、ワークフロークライアントソフトウェア（以下クライアントソフトと称す）がインストールされている。クライアントソフトは、サーバ１から受信されたＨＴＭＬデータを表示するＨＴＭＬ表示機能とＨＴＭＬデータ内のボタンクリックを受け付けてサーバ１へ要求を送信する要求送信機能とを有している。
各クライアント２ａ〜２ｃでは、ＯＳの起動に伴いクライアントソフトが起動しサーバ１へのログイン画面を表示し、ユーザがログイン情報を入力することにより、ユーザの権限に応じたサーバ１のサーバソフト１０の機能を利用できるようになる。なお、ユーザの操作でクライアントソフトが起動するようにしても良い。
【００１５】
以下、図２の通信シーケンス図、図３以降の各画面例などを参照してこの電子決裁システムの動作を説明する。図２は図１の電子決裁システムにおけるサーバとクライアント間の通信動作を示すシーケンス図である。
この実施形態の電子決裁システムでは、図２に示すように、ある承認者、例えば承認者Ｃがクライアント２ａを起動すると、ＯＳの起動と共にクライアントソフトが起動して、サーバ１へアクセス要求を行い、この要求に対してサーバ１は、ログイン画面を送信し（Ｓ１０２）、クライアント２ａにログイン画面が表示される（Ｓ１０３）。
表示されたログイン画面から承認者がログイン情報を入力すると、サーバ１へログイン情報が送信される（Ｓ１０４）。
【００１６】
サーバ１では、ログイン情報を受信すると、サーバソフト１０が認証処理を行い、認証結果に応じた画面を返信する（Ｓ１０５）。つまり、認証結果がＯＫであれば、メニュー画面を送信し、認証結果がＮＧであれば、再度ログイン情報の入力を促すためのログイン画面を送信する。
認証が正常に済むと、クライアント２ａには、図３に示すようなメニュー画面が表示される。
クライアント２ａに表示されたメニュー画面には、承認可能案件一覧および承認予定案件一覧のボタンが表示されており、承認者がいずれかのボタンを選択操作することで、各ボタンにリンクされている次の画面が表示される。
【００１７】
ここで、例えば承認予定案件一覧のボタンが選択操作されると、クライアントソフトは、承認予定案件の一覧表示要求を送信し（Ｓ１０６）、この要求を受信したサーバ１では、サーバソフト１０が、該当承認者に回覧される予定の起案票のデータの中のヘッダデータを承認案件記憶部１２から読み出して承認予定案件一覧データとして送信する（Ｓ１０７）。
承認予定案件一覧データがクライアント２ａに受信されると、クライアント２ａには、図４に示すような承認予約可能一覧の画面が表示される。この承認予約可能一覧の画面には、起案票のデータヘッダ、例えば「ＸＸＸＸＸＸの承認依頼」、「ＹＹＹＹＹＹＹの承認依頼」「ＺＺＺＺＺＺの承認依頼」などといった案件名が承認予約可能な承認案件の一覧として表示される。
【００１８】
ここで、承認者が、例えば「ＸＸＸＸＸＸの承認依頼」という案件名を選択操作すると、クライアント２ａのクライアントソフトにより該当案件名に対応する起案票の本文のデータの要求が行われ（Ｓ１０８）、この要求をサーバ１で受信すると、サーバソフト１０が該当する起案票の本文のデータを送信する（Ｓ１０９）。
起案票の本文のデータがクライアント２ａに受信されると、クライアント２ａの画面には、起案票５１（図５参照）として表示される（Ｓ１１０）。
図５に示すように、起案票５１には、例えば使用目的という項目名とその項目のデータ（交通費など）が入力されたデータ入力欄５２、申請金額の項目名とその項目のデータ（１２００円など）が入力されたデータ入力欄５３、および承認予約を確定操作（実行）するための承認予約ボタン５４が設けられている。
ここで、クライアント２ａの承認者が、表示された起案票５１の内容を確認し、このまま回覧されたときに起案票５１の申請内容を許可する場合（承認する場合）、承認予約ボタン５４を選択操作すると、クライアント２ａの画面に表示されている起案票５１のデータが承認条件のデータとしてＬＡＮ３を通じてサーバ１へ送信される（Ｓ１１１）。
なお、起案票５１の使用目的のデータ入力欄５２、あるいは申請金額のデータ入力欄５３に予め入力されているデータについては、承認者がキーボード、あるいはマウスなどを操作して変更することもできる。例えば申請金額のデータ入力欄５３に予め入力されていた「１２００」というデータを、例えば「１２００以下」、「１３００以下」などに変更しても良い。
サーバ１では、クライアント２ａからＬＡＮ３を通じて送信されてきた承認条件のデータが受信されると、受信された承認条件のデータを予約承認条件テーブル３０の該当承認者の欄に該当承認者の予約承認条件として設定（登録）する（Ｓ１１２）。なお、図６において、予約承認条件テーブル３０のユーザＩＤと案件ＩＤは、必然的に決まる情報である。また、使用目的と申請金額のデータは、承認者が入力してもよく、また、予めサーバ１に登録しておくことで、各欄にダウンリストで選択項目として表示させ、承認者が選択するだけ済むようにできる。
図６の予約承認条件テーブル３０のように、例えばある承認者が承認の予約を登録した起案票５１（この例では案件ＩＤ：１０４２）について、使用目的が「交通費」、申請金額が「１２００」円などの場合に、その起案票５１が後に自分に回覧されてきたときには承認処理を自動で実行することを意味する。
【００１９】
以下、この電子決済システムにおける承認処理の第１動作例について説明する。
この電子決済システムの場合、起案票は、ワークフロー情報記憶部１１に記憶されているワークフロー情報に従って承認すべき順に回覧される。
この際、ワークフローの処理順のうち後ろに指定されている承認者は、上述したように、後で自身に回覧される起案票を一覧表示させ、回覧予定の起案票の内容を閲覧して、起案票の内容を確認できる。この際、その起案票の内容が変更されずに自分に回ってきた際には、承認処理が自動的に実行されるように承認予約を行っておくことができる。
つまり、承認者自身に回覧される予定の起案票毎に承認条件を予約承認条件テーブル３０に登録しておき、承認予約を行った中のある起案票が承認者に実際に回覧されたときに、サーバソフト１０が、起案票のデータと予約承認条件テーブル３０の承認条件とを照合し、起案票のデータが承認条件を満たしていた場合にのみ自動承認を行う。
【００２０】
以下、図７のフローチャートを参照して具体的なサーバソフト１０の処理について説明する。
サーバソフト１０は、ワークフロー情報に従って起案票を次の承認者に回覧したときに、その起案票の回覧の順番が承認予約した承認者の順番か否かを判定する（図７のＳ２０１）。
当該起案票の回覧の順番が承認予約した承認者の順番であれば（Ｓ２０１のＹｅｓ）、予約承認条件テーブル３０より該当案件ＩＤ、ユーザＩＤの承認条件を読み出すると共に、承認案件記憶部１２より当該起案票のデータを読み出して、互いの内容をチェック（照合）する（Ｓ２０２）。
このチェック（照合）の結果、当該起案票のデータが、予約した承認条件を満たしていた場合（Ｓ２０３のＹｅｓ）、サーバソフト１０は、その起案票に対して承認を行う行為（自動承認処理）を実行する（Ｓ２０４）。承認を行う行為（自動承認処理）とは、当該起案票のデータに承認フラグを付加する等の処理である。
自動承認処理を実行した結果、処理を正常に終了すると、サーバソフト１０は、その起案票をワークフロー情報に示されている次の承認者へ回覧する（Ｓ２０５）。
なお、多くの起案票が修正なしで回覧されてくるような場合に、承認にかかる時間を大幅に短縮でき、一連の承認回覧にかかるリードタイムの短縮化を図ることができる。
【００２１】
一方、予約を行った承認者自身に回る前、つまり承認途中で、当該起案票に修正などが生じて、予約した承認条件が満たされない場合（Ｓ２０３のＮｏ）、サーバソフト１０は、承認者からの承認操作を待つようになる（Ｓ２０６）。
この場合、承認待ちになっている起案票に対して承認者が閲覧操作を行うことで、クライアント２ａの画面に起案票の内容を表示させ、確認した上で承認操作を行う。サーバソフト１０は、この承認操作が行われた場合に（Ｓ２０７のＹｅｓ）、起案票に対する承認処理を実行する。
【００２２】
例えばクライアント２ａの利用者が作成した起案票がクライアント２ｂ，クライアント２ｃの利用者にその順で回覧されるような場合、クライアント２ｃの利用者が、自身に回覧される予定の承認予約可能案件一覧をクライアント２ｃに示させたときに、クライアント２ａの利用者が作成した起案票がクライアント２ｂの利用者により変更なしにそのまま承認された場合には承認を行う、といった承認条件を入力し、サーバ１の予約承認条件テーブル３０に登録しておくことで、当該起案票がクライアント２ｂの利用者からクライアント２ｃの利用者に修正なしに回ってきたときに、その起案票は、サーバソフト１０によりそのまま自動承認処理されて次の承認者へ回覧されることになる。なお、各クライアント２ａ、２ｂ，２ｃを一人ではなく複数の利用者が利用する場合もあり、起案票の回覧はユーザ単位であり、上記回覧の例はあくまでも一例にしか過ぎない。
【００２３】
以下、この電子決裁システムにおける第２動作例〜第４動作例について説明する。まず、第２動作例について説明する。この第２動作例は上記第１動作例の予約の処理タイミングを変更した応用例である。
すなわち、上記第１動作例では、クライアント２ｂの利用者である承認者の承認が終了した後、クライアント２ｃの利用者である承認者の順番になったときに、直ちに予約承認の処理を開始する仕組みとしたが、この第２動作例では、承認予約を入れたときの時刻情報（日時）とは別に、予約承認条件テーブル３０に、自身に回覧されてから何時間後に承認処理を実行するといった時限情報を記憶しておく。
【００２４】
この場合、クライアント２ｃの利用者が起案票の承認予約を行った後、サーバソフト１０は、その起案票について、クライアント２ｃの利用者が承認を行う順番になったときに、まず、予約承認条件テーブル３０の承認条件に含まれる時限情報を読み出し、時限情報が例えば１時間後などと設定されていた場合、タイマーを動作させ、それから１時間が経過した場合に予約承認条件テーブル３０の承認条件のうち使用目的、請求金額などの各項目のデータと起案票のデータとを照合して承認条件を満たしていた場合に自動承認処理を実行する。なお、タイマーではなくＯＳが有する時計機能を利用して時間を計測しても良い。
【００２５】
このように起案票が承認者に回覧された時点から承認処理を実行するまでの時間情報を承認条件の一つとして用いたことで、クライアント２ｃの利用者としては、できるだけ自身で起案票の内容を確認し承認操作したい場合に、自身が予め設定した時間よりも早く起案票を確認できたときには自身で承認操作を行えるようになる。また、クライアント２ｃの利用者が何らかの理由で承認を行えないような場合に、起案票に対して一定時間後に予約した承認条件にて自動的に承認処理が行われるので、承認回覧が予め設定した時間以上遅くなるなる事態を回避できる。
【００２６】
続いて、第３動作例について説明する。この第３動作例は、起案票に対して承認の予約が行われた時期（タイミング）を一つの判定材料とする動作例である。
上記第１動作例では、承認予約時点での起案票のデータを承認条件として登録しておき、起案票が回覧された時点での起案票のデータと承認条件とを比較して承認条件を満たしているか否かを判定していたが、承認条件に時間的な制約が無く、これでは起案票が回るまでの変更履歴がわからない。
【００２７】
そこで、この第３動作例では、起案票が回覧され、その中の各項目のデータが変更された場合に起案票のデータの更新履歴を残しておく。そして、実際に、起案票が回覧された場合に起案票のデータの最終変更日と承認の予約を行った日時（予約登録日時）とを比較して、例えば予約登録日時以前に起案票のデータが変更されていてもその更新は自動承認の判定対象とはせず、予約登録日時以降の起案票のデータの更新のみを自動承認の判定対象とする。
【００２８】
つまり、予約承認条件テーブル３０に登録されている承認予約を行った日時情報についても承認条件の一つとして用いる。
サーバソフト１０は、承認の予約後に起案票が該当承認者に回覧されると、予約承認条件テーブル３０の承認条件に含まれる日時のデータ（予約日時）を読み出し、例えば２００２０１１３などと設定されていた場合、起案票の更新履歴のデータを参照して最終更新日が予約日時以前か、予約日時以降かを判定する。
この判定結果、起案票のデータの最終更新日が予約日時以降の場合、サーバソフト１０は、自動承認処理を行わず、承認者による承認操作を待つことにする。
【００２９】
一方、起案票のデータの最終更新日が予約日時以前の場合に、サーバソフト１０は、次に、予約承認条件テーブル３０の承認条件のうち使用目的、請求金額などの各項目のデータと起案票のデータとを照合する。そして、起案票のデータが承認条件を満たしていた場合に自動承認処理を実行する。なお、これら２段階の判定処理を一度に行っても良い。
すなわち、承認の予約後に回覧された起案票について自動承認の可否を判定する上で、承認の予約登録を行った日時よりも後に起案票のデータに変更がないことの確認処理を追加する。これにより、いつの時点で自動承認を有効としたかが明確になり、起案票について自動承認する上での間違いをなくすることができる。
【００３０】
次に、第４動作例について説明する。この第４動作例は、予約承認の条件範囲をいくつか設ける応用例である。
上記第１動作例では、起案票の項目すべて、つまり「使用目的」、「請求金額」をアンド条件で自動承認したが、このうち、いずれか一方の条件だけを満たした場合でも承認を行うことにする。
【００３１】
すなわち、この第４動作例の場合、図８に示すように、起案票５１には、図５で示した起案票５１の各項目のデータ入力欄５２，５３の他に、どの項目を承認条件とするかを指定するためのチェックボックス８２，８３を項目毎に追加する。また、図９に示すように、予約承認条件テーブル３１には、承認条件の各項目毎に確認が不要か必要かを設定する確認要否の情報が登録される欄３２，３３を新たに設ける。
承認の予約を行う承認者は、これらの中の少なくとも一つのチェックボックス８２，８３にチェックマークを入れて承認予約の操作を行うようにする。
従って、承認予約の際に、図８の起案票５１のチェックボックス８２，８３のうち少なくとも一つにチェックマークを入れて承認予約の操作を行うと、予約承認条件テーブル３１の該当項目の欄３２に例えば「要」などの情報が登録され、チェックマークが入っていなかった項目の欄３３に例えば「不要」などの情報が登録される。
【００３２】
つまり、起案票に複数の項目が指定されている場合に、各項目毎に承認条件とするか否かの情報を付与することで、承認条件は、申請金額と使用目的の両方のみに限定されることなく、申請金額のみ、あるいは使用目的のみ、というように条件を緩和して設定できる。
図８の起案票５１の例では、申請金額の項目のチェックボックス８３にのみチェックマークが付けられているため、図９の予約承認条件テーブル３１には、申請金額の項目の欄３３に「要」が登録され、チェックマークが入っていなかった使用目的の項目の欄３２に「不要」が登録され、自動承認処理を実行する際には、申請金額だけが承認条件としての判定対象となる。なお、起案票５１が回覧されたときの処理については、図９の予約承認条件テーブル３１に登録されている承認条件の内容、つまり申請金額と使用目的のうちの少なくとも一方になるだけであり、第１動作例で説明した図７のフローチャートと同様である。
【００３３】
このようにこの実施形態の電子決裁システムによれば、ある起案票について多くの承認者が承認予約を設定した場合に、起案票を一人ずつ承認する場合よりも早い時間で対象者全員の承認を得ることができる。また、承認条件の多くが修正されることなく承認されるような場合には、より大きな効果を得ることができる。
予約された承認処理を直ちに実行せずに一定時間経過後に実行することで、承認者の選択肢を広げつつ変更のない起案票の処理にかかる時間を短縮することができる。
承認予約の登録日時と起案票の最終変更日とを比較して自動承認の可否を判定することで、起案票について自動承認する上での間違いをなくすることができる。
起案票に対する承認条件を、起案票のデータがすべて変更されなかった場合だけに限ることなく、起案票のデータが一部変更されたとしても自動承認を許可することで、自動承認の際の条件を緩和することがきる。
【００３４】
【発明の効果】
以上説明したように本発明によれば、承認案件を回覧対象者全員に本来の順序で回覧しつつ回覧対象者全員が承認するまでのリードタイムを短縮することができる。
【図面の簡単な説明】
【図１】本発明の一つの実施形態の電子決裁システムのハードウェア構成を示す図。
【図２】図１の電子決裁システムにおけるサーバとクライアント間の通信動作を示すシーケンス図。
【図３】メニュー画面の一例を示す図。
【図４】承認予約可能案件一覧表示画面を示す図。
【図５】起案票の一例を示す図。
【図６】予約承認条件テーブルを示す図。
【図７】この電子決裁システムの回覧動作を示すフローチャート。
【図８】起案票の一例を示す図。
【図９】予約承認条件テーブルを示す図。
【符号の説明】
１…サーバ、１ａ…ハードディスク装置、２ａ〜２ｃ…クライアント、３…ＬＡＮ、１０…サーバソフト、１１…ワークフロー情報記憶部、１２…承認案件記憶部、３０…予約承認条件テーブル。
【図１】
2004258960.tif 000003
【図２】
2004258960.tif 000004
【図３】
2004258960.tif 000005
【図４】
2004258960.tif 000006
【図５】
2004258960.tif 000007
【図６】
2004258960.tif 000008
【図７】
2004258960.tif 000009
【図８】
2004258960.tif 000010
【図９】
2004258960.tif 000011