"ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とするワークフローシステム。前記伝票毎に承認画面を表示することなく一括して承認処理を行うための一括承認ルールを登録する登録手段とを備え、前記判定手段は、前記登録手段により登録された前記一括承認ルールを用いることにより、前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定することを特徴とする請求項1に記載のワークフローシステム。ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、前記表示手段により表示された前記未処理の伝票のうち、承認処理を行う伝票をユーザに選択させる第二の選択手段と、前記第二の選択手段により選択された前記伝票の承認処理を行った後、前記未処理の伝票を承認するための承認画面を連続して自動的に表示することで承認処理を行う連続承認手段とを備えることを特徴とするワークフローシステム。前記登録手段により前記一括承認をするためのルールが登録されていない場合、前記選択手段でユーザにより選択された前記複数の伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行うことを特徴とする請求項1または2に記載のワークフローシステム。前記登録手段により一括承認を行わない旨のルールが設定された場合、前記選択手段でユーザにより選択された前記複数の伝票に対して、前記伝票毎に承認画面を表示することでユーザに個別承認をさせることを特徴とする請求項1、2または4のいずれか1項に記載のワークフローシステム。前記登録手段は、前記伝票毎に一括承認をする複数のルールを登録可能であることを特徴とする請求項1、2、4または5のいずれか1項に記載のワークフローシステム。前記登録手段は、前記伝票毎に一括承認をしないルールを設定することが可能であることを特徴とする請求項1、2、4、5または6のいずれか1項に記載のワークフローシステム。前記ユーザにより起票された伝票のうち合議投票の処理を要する伝票に対して、前記選択手段により前記一括承認の対象として選択させないことを特徴とする1、2、4、5、6または7のいずれか1項に記載のワークフローシステム。ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールと、前記伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報とを記憶するサーバとがネットワークを介して接続しているワークフローシステムの制御方法であって、前記ワークフローシステムの抽出手段が、前記伝票のうち、未処理の伝票を抽出する抽出ステップと、前記ワークフローシステムの表示手段が、前記抽出ステップにより抽出された前記未処理の伝票を表示する表示ステップと、前記ワークフローシステムの選択手段が、前記表示ステップにより表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択ステップと、前記ワークフローシステムの判定手段が、前記選択ステップにより一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定ステップと、前記ワークフローシステムの一括承認手段が、前記判定ステップにより一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認ステップと、前記ワークフローシステムの個別承認手段が、前記判定ステップにより一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認ステップとを特徴とする制御方法。ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムとして機能させるプログラムであって、前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とするプログラム。上述した従来のワークフローシステムにおける一括承認機能であるが、現行の機能では、一括承認対象として選択された処理待ち案件の場合でも、案件内の業務項目の状態によっては一括承認対象外とし、個別承認対象に切り替えるといった業務要件があった場合に柔軟に対応することができない。例えば、ある部署の複数のユーザが各々購入申請書を起案申請した案件に対して、上長である承認者が、一括承認対象として同時に選択して承認処理を行った場合、購入金額の総額が100,000円未満の案件の場合には承認者の指示通りに一括承認として処理するが、100,000円以上の案件の場合には一括承認対象外として個別承認対象とする、といった業務要件には現行の機能では対応できない。上記特許文献1の特開2002-132759号公報では、一括承認対象の処理待ち案件を一括閲覧表示して、承認者が内容を確認の上で承認処理を行うことを対象としている。このため、本来の一括承認処理の目的である、わざわざ個別に内容を表示確認する必要のないような複数の処理待ち案件に対して一括で承認処理を行えるということが不可能である。本発明の目的は、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする仕組みを提供することである。ユーザの申請により起票される伝票の処理を行うクライアント装置と前記伝票を承認するための承認ルールを記憶するサーバとがネットワークを介して接続しているワークフローシステムであって、前記ユーザの申請により起票された伝票が、処理済みの伝票であることまたは未処理の伝票であることを識別する情報を記憶する記憶手段と、前記記憶手段により記憶された前記伝票のうち、未処理の伝票を抽出する抽出手段と、前記抽出手段により抽出された前記未処理の伝票を表示する表示手段と、前記表示手段により表示された前記未処理の伝票のうち、一括承認する対象の伝票として複数の伝票をユーザに選択させる選択手段と、前記選択手段により一括承認の対象として選択された前記複数の伝票を、前記選択された伝票毎に一括承認が可能であるか否かを判定する判定手段と、前記判定手段により一括承認が可能であると判定された伝票に対して、前記伝票毎に承認画面を表示することなく一括承認処理を行う一括承認手段と、前記判定手段により一括承認が可能ではないと判定された伝票に対して、前記伝票毎に承認画面を表示することで個別承認処理を行う個別承認手段とを備えることを特徴とする。本発明によれば、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする。第一の実施例以下、図面を参照して、本発明の実施形態を詳細に説明する。図1は、本発明の実施形態におけるワークフローシステムの構成を示す図である。図1において、ワークフローシステムは少なくとも1つのワークフローサーバ以下、WFサーバー101とワークフロークライアント102がネットワークを介して接続されている。本実施例においては、ワークフロークライアント102は複数台で構成されている。ユーザは、たとえばウェブブラウザやクライアントソフトウェアなどを利用して、ワークフロークライアント102から、ワークフローサーバ101に対して、ワークフロー進行の要求などを行う。ワークフローサーバ101は、ワークフロークライアント102からの要求に応じた処理、案件の管理をおこない、必要があればワークフロークライアント102に対して結果などを送信する。ワークフローサーバ101とワークフロークライアント102の間の通信は、通常のHTTPのリクエストでもよいし、SOAPなどを利用したウェブサービスのリクエストでもよい。図2は、本発明の実施形態における各種端末のハードウエア構成を示す図である。図2において、CPU201は、システムバス204に接続される各デバイスを統括的に制御する。また、ROM203あるいは外部メモリ211には、CPU201の制御プログラムであるオペレーティングシステムOSや、各サーバあるいは各クライアントの後述する各種機能を実現するためのプログラムが記憶されている。RAM202は、CPU201の主メモリ、ワークエリア、一時待避領域等として機能する。入力コントローラ205は、入力部209からの入力を制御する。この入力部209としては、特に、サーバやクライアント等の端末では、キーボード、マウス等のポインティングデバイスが挙げられる。外部メモリコントローラ207は、ブートプログラム、各種のアプリケーション、フォントデータ、ユーザファイル、編集ファイル、プリンタドライバ等を記憶する外部メモリ211へのアクセスを制御する。加えて、各サーバあるいは各クライアントの各種機能を実現するための各種テーブル、パラメータが記憶されている。この外部メモリ211としては、ハードディスクHDやフロッピー登録商標ディスクFD、PCMCIAカードスロットにアダプタを介して接続されるコンパクトフラッシュ登録商標、スマートメディア等が挙げられる。通信I/Fコントローラ208は、ネットワーク213を介して外部機器との通信制御処理を実行する。本発明を実現するためのプログラム212は外部メモリ211に記録されており、必要に応じてRAM202にロードされることによりCPU201によって実行されるものである。図3は、本発明の実施形態におけるワークフローシステムにおいて、一括承認時の各種ルールを登録更新する為の編集画面の一例である。図3において、一括承認ルールは、比較演算子301~定数305までを用いて作成される。一括承認ルールは、左辺、条件式、右辺の3つの構成要素から成る。以下、前記一括承認ルールの編集画面図3を説明する。比較演算子301は、~~前記一括承認ルールの構成要素である条件式を表わし、左辺および右辺を表すの比較を行う為に使用する。比較演算子301は、左辺と右辺の一致を意味する=、左辺と右辺の不一致を意味する=、左辺が右辺に比べ小を意味する<、左辺が右辺に比べ大を意味する>、左辺が右辺以下を意味する<=、左辺が右辺以上を意味する>=の5つの選択肢から成る。判定演算子302は、前記一括承認ルールの構成要素である条件式を表わし、左辺がNULLか否かを判定する為に使用する~~を表す。判定演算子302は、左辺がNULLであることを意味するISNULL、左辺がNULLでないことを意味するISNOTNULLの2つの選択肢から成る。本明細書では、値自体が存在しない状態をNULLと呼ぶこととする論理演算子303は、~~前記一括承認ルールを複数登録する場合に、登録した各ルールを論理積または論理和で組み合わせる為に使用するを表す。論理演算子303は、論理積を意味する、論理和を意味する||の2つの選択肢から成る。業務項目304は、~~前記一括承認ルールの構成要素である左辺を表わし、当該業務内に存在するいづれかの項目を選択する為に使用するを表す。業務項目304は、当該業務内の項目選択を意味する業務項目の1つの選択肢から成る。定数305は、~~前記一括承認ルールの構成要素である右辺を表わし、左辺と比較した具体的な値を設定する為に使用するを表す。定数305は、文字列型定数を意味する文字列、数値型定数を意味する数値、日時型定数を意味する日時、真偽値型定数を意味する真偽値の4つの選択肢から成る。テキストエリア306は、設定した前記一括承認ルールの表示エリアである。OKボタン307は、設定した前記一括承認ルールを保存する為に使用する。キャンセルボタン308は、設定した前記一括承認ルールを取り消す為に使用する。業務項目一覧画面309は、業務項目304を選択した場合に表示される。業務項目一覧画面309は、当該業務項目の一覧情報が表示され、任意の1項目が選択可能である。チェックボックス310は、当該業務に対して一括承認許可を制御する為に使用する。チェックボックス310にチェックが設定された場合、当該業務に対しては一括承認自体が不可扱いとなる。業務名311は、当該業務の名称を表す。一括承認ルールの作成手順の一例を図3Bのフローチャートと併せて示す。まず、一括承認ルールの構成要素:左辺が未設定の場合、左辺の設定を行う図3BのS301。業務項目304より項目ボタンを選択後、テキストエリア306を選択すると、業務項目一覧画面309が表示される。業務項目は、文字、数値、日付、真偽値、文書、添付など、いずれかの属性から成る。業務項目一覧画面309より項目を選択すると、一括承認ルールの構成要素の一つである左辺として設定され、テキストエリア306に表示される。図3の306における、項目名:購入金額がそれに当たる。次に、一括承認ルールの構成要素:条件式が未設定の場合、条件式の設定を行う図3BのS302。比較演算子301或いは判定演算子302より任意の演算子ボタンを選択後、テキストエリア306を選択すると、一括承認ルールの構成要素の一つである条件式として設定され、テキストエリア306に表示される。図3の306における、>=がそれに当たる。最後に、一括承認ルールの構成要素:右辺が未設定の場合、右辺の設定を行う図3BのS303。定数305より任意の属性ボタンを選択後、テキストエリア306を選択すると入力欄が表示されるので、任意の文字、数値、日時、真偽値を入力すると、一括承認ルールの構成要素の一つである右辺として設定され、テキストエリア306に表示される。図3の306における30000がそれに当たる。なお、一括承認ルールを複数設定したい場合は、一つ目のルールを設定後、論理演算子303より=AND或いは||=ORを選択後図3BのS304、テキストエリア306を選択すると二つ目のルールが設定可能な状態となる図3の306には不図示。最後に、一括承認ルールの編集が終わったら、確定処理を行う図3BのS305、S306。OKボタン307を選択することで、一括承認ルールの編集が完了となり、キャンセルボタン308を選択することで、一括承認ルールの編集を取り消す。一括承認ルールがデータベースにどのようなデータ形式で登録されるかは、後述する図13で示す。図13は、本発明の実施形態におけるワークフローシステムにおいて、一括承認ルールの登録データ形式の一例である。図13において、一括承認ルールはXML形式でデータベースに登録される。その際、一括承認ルールは業務毎に設定されるものなので、業務設計データに紐づく形で一括承認ルールは登録されている。業務設計データと一括承認ルールの関係性を示すデータ構造については、後述する図14で示す。図14は、本発明の実施形態におけるワークフローシステムにおいて、業務設計データと案件データのデータ構造を示す図である。図14において、業務設計データ1420は、業務定義1421と経路定義1422とフォーム定義1423と項目定義1424を含む。業務定義1421は、業務設計データ1420を特定するための定義情報を保持する。また、業務定義1421は、業務設計の1つを特定するための情報として、業務IDおよび、業務バージョン番号を保持する。また、業務定義1421は、業務名と、一括承認ルールを保持する。一括承認ルールは、図13で先述した通り、XML形式で登録される。経路定義1422は、ワークフローの流れの定義情報を保持する。フォーム定義1423は、ワークフローを操作するユーザーが直接操作する画面の定義情報を保持する。項目定義1424は、案件データ1410が、保持するべきデータの型や長さなどのデータ定義情報を保持する。案件データ1410は、案件親データ1411と案件子データ1412を含む。案件親データ1411は、案件データ1410を特定するためのデータ情報を保持する。案件子データ1412は、案件データ1410の実データを保持する。次に、図4および図5を用いて本発明の実施形態における一般的なワークフローの例について説明する。図4は、従来のワークフローの第一例である。図4においては、備品購入申請書の例として、購入希望申請者が各々起票申請を行う。工程1本発明の実施例において、ワークフローの処理者はワークフロークライアント102より起票申請や承認の処理を行うが、ワークフロークライアント102では起票申請や承認の指示処理を行っているのみであり、実際には、ワークフローサーバー101において各処理が行われる。申請者が起票申請を行うと、申請者の、上長である課長工程2、部長の承認を経て工程3主管部門の処理者が処理を行い工程4、主管部門長が最終承認を行う工程5流れを示している。この場合、工程2~工程5については、各案件に対して一つづつ承認作業を行う個別承認或いは一括承認が可能である一括承認の場合は、別途一括承認ルールが適用され、承認或いは未承認が判定される。図5は、従来のワークフローの第二例である。図5においては、起案書の例として、購入希望者が各々起票申請を行い工程1、上長である課長工程2、複数の合議者が同時並行に合議投票を行い工程3、役員の承認後工程4に主管部門長が最終承認を行う工程5流れを示している。ここで言う、合議投票とは~~申請者より起案申請された案件に対して、複数の関係者が同意するか否かの意思表明を意味している。この場合図5に示すワークフローの工程2、工程4、工程5については、個別承認或いは一括承認が可能であるが一括承認の場合は、別途一括承認ルールが適用され、承認或いは未承認が判定される、工程3については個別承認及び一括承認は不可能であり、合議投票賛成、反対のみが可能である。図6は、本発明の実施形態におけるワークフローシステムにおいて、ワークフローにおける一括承認時の処理イメージである。先述したように一括承認とは、承認者に処理待ち案件の承認依頼が複数存在する場合、承認者の手間を軽減する為に個別に処理待ち案件を開くことなく纏めて一括で承認する処理方法を言う。図6においては、一括承認ルール601を購入金額<30,000円に設定したと仮定する。一括承認の例602の中で、申請者1~5が備品購入申請書を各々起票申請した場合、次の承認者1課長へ申請書1~5に対する承認依頼が通知される。図6の実施例において夫々、申請者120000円、申請者230000円、申請者325000円、申請者410000円、申請者540000円の案件を起票している。承認者1課長は、申請書1~5の内容に目を通し、それぞれ個別に承認を行う。次の承認者2部長は、承認依頼が通知された申請書1~5に対して、内容に目を通すことなく一括での承認を行おうとする。その際、申請書1~5それぞれに対して、一括承認ルール601が適用され一括承認対象とするか否かを判定される。一括承認ルール601の設定内容の場合、申請書1については承認処理が行われ、申請書2については案件画面が開き個別承認が促される。個別承認後、申請書3、4については承認処理が行われ、申請書5については再び案件画面が開き個別承認が促される、といった流れになる。図7は、本発明の実施形態におけるワークフローシステムにおいて、後述する処理待ち案件一覧画面図8の起動元となるWEB画面の一例である。図7においては、ログインユーザ情報701で、当該ワークフローシステムにログインしたユーザ情報が表示される。業務一覧702では、当該ワークフローシステムにログイン中のユーザが起案申請可能な業務の一覧が表示される。起案ボタン703を選択することで、後述する起案画面図9が起動する。メニューの処理待ち案件一覧リンクボタン704はリンク形式であり、このリンクを選択することで、後述する処理待ち案件一覧画面図8を起動することが可能である。図8は、本発明の実施形態におけるワークフローシステムにおいて、先述した図7の704にある、処理待ち案件一覧ボタンを押下された時に起動するWEB画面図7より起動された処理待ち案件一覧画面の一例である。図8においては、処理待ち案件一覧画面は、マイクロソフト社の推進するリッチクライアント方式スマートクライアント技術から構成され、サーバとの通信はXMLWEBサービスを用いて行われる。対象ユーザ選択ボタン801は、当該ワークフローシステムにログイン中のユーザと、委任関係となる委任元ユーザの情報がドロップダウン形式で表示される図8の処理待ち案件一覧画面の初期表示時は、ログインユーザが選択されている状態。対象ユーザ選択ボタン801で別の委任元ユーザを選択後、一覧表示ボタン802が選択されると、選択した委任元ユーザに紐づく処理待ち案件一覧データが明細部に表示される。絞込条件ボタン803は、明細部に表示されている処理待ち案件一覧データをある条件に基づいて絞り込む為の条件指定部である。絞込条件ボタン803に条件指定後、絞込ボタン804を選択すると絞込された結果が明細部に表示される。この絞込機能については、サーバとのXMLWEBサービス通信は行われない。あくまで、クライアント内部で保持している処理待ち案件一覧データを、クライアント内部で絞り込む形となる。元に戻すボタン805は、絞込条件ボタン803で絞り込んだ結果を取り消すためのボタンである。リセットボタン806は、条件部をクリアする。明細部807は、処理待ち案件一覧データを表示エリアする領域である図8の処理待ち案件一覧画面の初期表示時は、ログインユーザに紐づく処理待ち案件一覧が表示されている状態。明細部807の左端に位置するチェックボックスは一括承認対象とする為の入力部である図8の処理待ち案件一覧画面の初期表示時は、すべてのチェックボックスが未選択状態。一括承認対象としたい処理待ち案件のチェックボックスにチェックを入れ、一括承認ボタン809を選択することで、個別に処理待ち案件画面を起動することなく一括での承認が行われる。非チェックボックス808にチェックボックスが表示されていない処理待ち案件は、合議投票を要する処理待ち案件の為、チェックボックスが非表示の状態となっている。また、明細部807より任意の処理待ち案件を選択後、案件を開くボタン810を選択すると、後述の選択した処理待ち案件画面図10が起動される。承認操作を行うと、次の処理待ち案件画面図10が起動されるといった具合に、承認操作が行われる度に順次、連続的に案件画面が起動することで、承認者の作業負担を軽減する。図9は、本発明の実施形態におけるワークフローシステムにおいて、図7の起案ボタン703が押下されたことにより先述したWEB画面図7より起動された起案画面の一例である。図9の起案画面は購入申請書が起動された場合の一例である。図9においては、起案画面は、マイクロソフト社の推進するリッチクライアント方式スマートクライアント技術から構成され、サーバとの通信はXMLWEBサービスを用いて行われる。申請者は、各業務の申請書を起動し、必要事項を入力後、申請ボタン901を選択することで、申請操作が完了する。図10は、本発明の実施形態におけるワークフローシステムにおいて、図8の案件を開くボタン810が押下されたことにより先述した処理待ち案件一覧画面図8より起動された処理待ち案件画面の一例である。図10においては、処理待ち案件画面は、マイクロソフト社の推進するリッチクライアント方式スマートクライアント技術から構成され、サーバとの通信はXMLWEBサービスを用いて行われる。承認者は、画面上の当該処理待ち案件に対して内容を確認の上、差戻ボタン1001、否決ボタン1002、承認ボタン1003のいずれかを押下することにより、該当する処理を実施する。また、連続承認メニュー1004は、処理待ち案件画面が自動的に順次起動する連続承認モードを切り替える為に使用する。連続承認メニュー1004は、当該案件の処理が完了すると次の処理待ち案件画面が自動的に起動する連続モード、当該案件の処理が完了すると次の処理待ち案件画面が自動的に起動しない単一モードの2つの選択肢から成る。当該案件を処理した後、次の処理待ち案件画面を自動的に起動したくない場合、つまり処理待ち案件に対する処理を終えたい場合には、連続承認メニューより単一モードを選択することで実現可能となる。図11は、本発明の実施形態におけるワークフローシステムにおいて、処理待ち案件一覧画面表示時のフローチャートである。図11においては、まず、S1102において、S1101のWEB画面図7より処理待ち案件一覧リンクボタン704を押下することで、S1103へ処理を進める。S1103において、スマートクライアントアプリをWFサーバ101よりダウンロードし、S1104でスマートクライアントアプリが起動される。S1105~S1112までは処理待ち案件一覧画面図8を表示する為に必要なデータ取得及び画面編集の処理となる。S1105で、図8の対象ユーザ選択ボタン801が押下されると、をドロップダウン形式で表示する為のデータをWFサーバ101より取得する。WFサーバー101はデータベース中に不図示の案件一覧データベースを保持しており、そのうち、未処理処理待ちのステータスとなっている案件を抽出して、ワークフロークライアント102に送信する。S1106で、図8の明細部807で表示する為の処理待ち案件一覧データをWFサーバ101より取得する。S1107で、S1106で取得した処理待ち案件一覧画面図8を表示する。S1109で、処理待ち案件が合議投票を要する案件の場合、明細部807の一括承認対象とする為の入力部であるチェックボックス図8の808は非表示とするS1110。逆に、処理待ち案件が合議投票を要さない案件の場合、明細部807の一括承認対象とする為の入力部であるチェックボックス図8の808は表示とするS1111。この処理によれば、合議投票を要する処理待ち案件に対して、誤って一括承認の対象としてしまうことを予め防ぐことが可能になる。S1112では、次の処理待ち案件の編集に移り、処理待ち案件表示画面が表示される。S1113図12は、本発明の実施形態におけるワークフローシステムにおいて、一括承認時のフローチャートである。図12においては、まず、S1202において、S1201の処理待ち案件一覧画面図8で一括承認対象となる案件が選択されているか否かを判定する。S1201で、一括承認対象となる案件が選択されていない場合は、S1216でエラーメッセージを表示する。選択有りの場合は、S1203~S1208まで、選択された一括承認対象の処理待ち案件の処理が行われる。S1204で、選択された処理待ち案件を1件分の案件IDがWFサーバ101へ送信される。S1209でWFサーバ101は受け取った案件IDを元にその案件の詳細データをDBより取得する。その後、S1210で、一括承認ルール編集画面図3で登録された一括承認ルールをDBより取得し、S1211で、一括承認ルールの登録があったか否かの判定を行う。登録が無い場合は、無条件で一括承認対象外とみなし、S1214で、対象の処理待ち案件を未承認とする処理を行う。登録が有る場合は、S1213で、対象の処理待ち案件が一括承認ルールに合致するか否かの判定を行う。一括承認ルールに合致する場合は、S1213の承認処理に入り、一括承認ルールに合致しない場合は、S1214の未承認扱いとする。S1215において、承認結果承認、未承認をクライアント側へ返却する。クライアント側では、S1205で、対象の処理待ち案件が一括承認として承認されたか否かを判定し、一括承認として承認されなかった場合は、S1206で、対象の処理待ち案件画面図10を起動して承認者へ個別承認を促す。S1207で、承認者が処理待ち案件の内容を確認の上で個別承認を行うと、S1208で、全ての処理待ち案件の処理が終了したかどうかを判定し、未処理の案件が残っている場合にはS1206に戻り、次の処理待ち案件画面が自動的に表示されて、個別承認処理を繰り返し行う、という流れになる。なお、図12のフローチャートには不図示であるが、次の処理待ち案件の処理の承認画面が自動的に開かれずに、一つ一つ個別で開くような処理にする場合には、S1204に戻って、1つずつ案件IDをサーバに送るような処理にしてもよい。本処理によれば、一括承認対象として選択した業務について、一括承認が可能かどうかの判断を一度に行い、予め登録されていたルールにより一括承認対象であると判断された業務については、一括承認を行い、一括承認の対象ではない業務については個別承認画面を開き、処理が終わると連続して次の個別承認対象業務の承認画面が開くような処理になるため、簡単に承認者は各以上、本発明の第一の実施例によれば、各業務を承認する際に、一括承認が可能であるか、個別承認が必要であるかを適切に判断して、一括承認と個別承認とを各業務により適切に実行させることで、処理者が各業務の承認を簡単に行うことを可能にする。例えば、承認者が複数の処理待ち案件を選択して一括承認処理を行った場合に、上記登録ルールに合致する処理待ち案件については承認者の指示通りに一括承認対象として処理し、上記の登録ルールに合致しない処理待ち案件については一括承認処理の対象とはせず、個別に画面表示を行い承認者へ個別での承認処理を促すといった処理を行う。また、上記登録ルールが未登録の業務については、承認者が複数の処理待ち案件を選択して一括承認処理を行った場合には、従来通り、選択されたすべての処理待ち案件が一括承認対象として処理され、さらに、当該業務に対する一括承認自体を不可とする設定が為されていた場合には、たとえ承認者が一括承認処理を行ったとしても、選択された処理待ち案件すべてが個別承認の対象として処理されるようにする。第二の実施例前記第一の実施例では、図8の処理待ち案件一覧表示画面にて、一括承認したい処理待ち案件を明細部807のチェックボックスよりチェックを入れ、一括承認ボタン809を選択することで一括承認が行われる処理について説明した。実際には、前記一括承認ルールを参照して、一括承認対象とするか個別承認対象とするかの判断処理が別途発生する。一方で、図8の処理待ち案件一覧表示画面にて、明細部807より任意の処理待ち案件の対象データをダブルクリックするか、対象データを選択状態にして案件を開くボタン810を選択することで、選択された処理待ち案件が個別承認対象として画面起動される。当該案件を処理する=承認、否認、合議投票、差戻しなどと、当該案件が自動的に閉じられ、次の処理待ち案件が個別承認対象として自動的に画面起動される。このように、処理待ち案件が存在する間、案件を処理する毎に自動的に次の処理待ち案件が起動する処理を、本明細書において、連続承認と呼ぶこととする。図8の処理待ち案件一覧表示画面が起動するまでのフローチャートは、先述した図11の通りである。図15は、本発明の実施形態におけるワークフローシステムにおいて、連続承認時のフローチャートである。図15においては、まず、S1501の処理待ち案件一覧画面図8にて、任意の処理待ち案件の対象データを選択するダブルクリック、案件を開くボタンなどことで、選択した処理待ち案件の案件IDがWFサーバ101へ送信されるS1502。S1513で、WFサーバ101側では、クライアントより受け取った案件IDを元に案件データをデータベースから取得し、クライアント側へ返却するS1514。クライアント側では、S1514でサーバーより送信された案件データを元に、S1503で処理待ち案件画面図10をオープンする。承認者は、S1503の処理待ち案件画面図10に対して、S1504のワークフロー操作図10の処理待ち案件画面中の承認、否認、差戻しボタン1001~1003による処理や合議投票などを行うことで、当該処理待ち案件に対する処理を実行する。処理が完了すると当該処理待ち案件画面がクローズされる。S1506では、処理待ち案件が存在するかどうかを判定し、次の処理待ち案件画面が存在している間はS1502のID送信処理に戻り、連続承認モードとなる。この際、S1503の処理待ち案件画面図10にて、連続承認モードの中断が選択されている場合図10の1004の連続承認モード選択で、単一承認が選択されている場合、当該処理待ち案件に対するワークフロー操作後、次の処理待ち案件画面がオープンすることはなく、連続承認が終了する。本発明の第二の実施例によれば、処理待ち案件の内容を個別に確認して処理を行いたいといった場合に、承認者が処理待ち案件を一つ一つ開く手間を省き、自動的に順次、処理待ちの案件を開き個別承認を促すことを可能にするワークフローシステムを提供する。以上、一実施形態について示したが、本発明は、例えば、システム、装置、方法、プログラムもしくは記録媒体等としての実施態様をとることが可能であり、具体的には、複数の機器から構成されるシステムに適用しても良いし、また、一つの機器からなる装置に適用しても良い。また、前述した実施形態の機能を実現するプログラムを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータまたはCPUやMPUが記録媒体に格納されたプログラムを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。この場合、記録媒体から読み出されたプログラム自体が本発明の新規な機能を実現することになり、そのプログラムを記憶した記録媒体は本発明を構成することになる。プログラムを供給するための記録媒体としては、例えば、フレキシブルディスク,ハードディスク,光ディスク,光磁気ディスク,CD-ROM,CD-R,DVD-ROM,磁気テープ,不揮発性のメモリカード,ROM,EEPROM,シリコンディスク等を用いることができる。また、コンピュータが読み出したプログラムを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムの指示に基づき、コンピュータ上で稼働しているOSオペレーティングシステム等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。さらに、記録媒体から読み出されたプログラムが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるCPU等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。また、本発明は、複数の機器から構成されるシステムに適用しても、1つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。さらに、本発明を達成するためのプログラムをネットワーク上のサーバ,データベース等から通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。なお、上述した各実施形態およびその変形例を組み合わせた構成も全て本発明に含まれるものである。"