(57)【要約】【課題】伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、ユーザが無秩序に承認経路を変更してしまうことを防止すること。【解決手段】ワークフローサーバ１０１は、ワークフロークライアント１０２からの承認要求に応じて、伝票データＤＢ１０１５に登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記ワークフロークライアント１０２に通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる構成を特徴とする。【選択図】図１
2008269654.tif 000002
【特許請求の範囲】
【請求項１】
所定の通信媒体を介して複数のクライアントと通信可能なワークフローサーバにおいて、
組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、
承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段と、
前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段と、
前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段と、
を有することを特徴とするワークフローサーバ。
【請求項２】
前記第１の特定手段は、申請日における組織情報より特定される次承認者と前記承認要求時における組織情報より特定される次承認者とが異なる場合には、それぞれを承認時の次承認予定者として特定することを特徴とする請求項１記載のワークフローサーバ。
【請求項３】
前記第１の選択手段は、前記第１の特定手段により複数の次承認予定者が特定されている場合には、クライアントに送信する承認画面上で前記複数の次承認予定者からいずれかを選択させることを特徴とする請求項１又は２記載のワークフローサーバ。
【請求項４】
前記第１の選択手段により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知手段を設けたことを特徴とする請求項１〜３のいずれかに記載のワークフローサーバ。
【請求項５】
前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの否認時の戻り先予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第２の特定手段と、
前記第２の特定手段により特定される複数の否認時の戻り先予定者を前記クライアントに通知し、否認時に前記複数の否認時の戻り先予定者からいずれかを否認時の戻り先として選択させる第２の選択手段と、
を有することを特徴とする請求項１〜３のいずれかに記載のワークフローサーバ。
【請求項６】
前記第２の特定手段は、申請日における組織情報より特定される否認時の戻り先と前記承認要求時における組織情報より特定される否認時の戻り先とが異なる場合には、それぞれを否認時の戻り先予定者として特定することを特徴とする請求項５記載のワークフローサーバ。
【請求項７】
前記第２の選択手段は、前記第２の特定手段により複数の否認時の戻り先予定者が特定されている場合には、クライアントに送信する承認画面上で前記複数の否認時の戻り先予定者からいずれかを選択させることを特徴とする請求項５又は６記載のワークフローサーバ。
【請求項８】
前記第２の選択手段により選択された否認時の戻り先に対して否認された伝票データが存在する旨を通知する第２の通知手段を設けたことを特徴とする請求項５〜７のいずれかに記載のワークフローサーバ。
【請求項９】
役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に複数記憶可能な第３の記憶手段と、
前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成手段と、
を有することを特徴とする請求項１〜６のいずれかに記載のワークフローサーバ。
【請求項１０】
前記生成手段により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第３の特定手段と、
前記第３の特定手段により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第３の通知手段と、
を設けたことを特徴とする請求項９記載のワークフローサーバ。
【請求項１１】
組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段とを有するワークフローサーバと、複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御方法において、
前記いずれかのクライアントからの承認要求に応じて、前記ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定工程と、
該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる選択工程と、
を有することを特徴とするワークフローシステムの制御方法。
【請求項１２】
前記選択工程により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知工程を設けたことを特徴とする請求項１１記載のワークフローシステムの制御方法。
【請求項１３】
前記ワークフローサーバに役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に記憶する第３の記憶手段を設け、
前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成工程を設けたことを特徴とする請求項１１又は１２記載のワークフローシステムの制御方法。
【請求項１４】
前記生成工程により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第２の特定工程と、
前記第２の特定工程により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第２の通知工程と、
を設けたことを特徴とする請求項１３記載のワークフローシステムの制御方法。
【請求項１５】
請求項１１〜１４のいずれかに記載されたワークフローシステムの制御方法を実行するためのプログラム。
【請求項１６】
請求項１１〜１４のいずれかに記載されたワークフローシステムの制御方法を実行するためのプログラムをコンピュータが読み取り可能に記憶した記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ワークフローサーバと複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御に関するものである。
【背景技術】
【０００２】
従来の一般的なワークフローシステムでは、承認が必要な伝票の種類や伝票の申請者の情報及び組織情報等に基づいて承認すべきユーザが決定される構成となっていた。
【０００３】
また、このような従来のワークフローシステムでは、ワークフロー完了前に組織変更が発生してフローする承認者が異動となってしまった場合、組織変更前の組織情報に基づいて承認者を決定したり、組織変更後の組織情報に基づいて承認者を決定したりといったように、いずれもフローする承認者が一意に決定され、組織変更に対処していた。
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかしながら、「旅費・立替金清算」や「報告書」といった過去の事象を清算する伝票においては、変更後の組織情報から決定された承認者では信憑性の確認が難しく組織変更前の組織情報から決定された承認者に決裁されるのが望ましいと考えられるが、逆に、「購入要求」や「開催通知」といった今後の事象を届け出る伝票については、組織変更後の組織情報から決定された承認者に決裁されるのが望ましいと考えられる。しかしながら、上記従来のワークフローシステムでは、システムによりいずれか一意に決定される承認者にフローされるため、伝票の種類やフロー完了前に発生する各種事情に対応して、伝票を手渡しする場合のよういに、柔軟に承認者を変更（決定）することができないという問題点があった。
【０００５】
また、組織変更がある度に、組織変更に応じて、管理者等がフローする承認者を書き換えることにより、組織変更に対応するワークフローチャートシステムもあるが、管理者の管理負担が増大してしまうといった問題点があった。
【０００６】
さらに、各承認者が次の承認者を自由に決定するように構成されたワークフローシステムもあるが、フローする承認者に制約がかけられないという問題点があった。
【０００７】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、クライアントからの承認要求に応じて、ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させることにより、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる仕組みを提供することである。
【課題を解決するための手段】
【０００８】
本発明に係る第１の発明は、所定の通信媒体を介して複数のクライアント（図１に示すワークフロークライアント１０２ａ，１０２ｂ，１０２ｃ，……）と通信可能なワークフローサーバ（図１に示すワークフローサーバ１０１）において、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段（図１に示す組織情報ＤＢ１０１２）と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段（図１に示す伝票データＤＢ１０１５）と、前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段（図２に示すＣＰＵ２０１が図１０に示す承認画面内の次承認予定者１００２ａを特定）と、前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段（図２に示すＣＰＵ２０１が図１０に示す承認画面を生成しクライアント１０２に送信する）とを有することを特徴とする。
【０００９】
本発明に係る第２の発明は、前記第１の特定手段は、申請日における組織情報より特定される次承認者と前記承認要求時における組織情報より特定される次承認者とが異なる場合には、それぞれを承認時の次承認予定者として特定することを特徴とする。
【００１０】
本発明に係る第３の発明は、前記第１の選択手段は、前記第１の特定手段により複数の次承認予定者が特定されている場合には、クライアントに送信する承認画面（図１０に示す承認画面）上で前記複数の次承認予定者からいずれかを選択させることを特徴とする。
【００１１】
本発明に係る第４の発明は、前記第１の選択手段により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知手段（図２に示すＣＰＵ２０１）を設けたことを特徴とする。
【００１２】
本発明に係る第５の発明は、前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの否認時の戻り先予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第２の特定手段（図２に示すＣＰＵ２０１が図１０に示す承認画面内の否認時の戻り先１００２ｂを特定）と、前記第２の特定手段により特定される複数の否認時の戻り先予定者を前記クライアントに通知し、否認時に前記複数の否認時の戻り先予定者からいずれかを否認時の戻り先として選択させる第２の選択手段（図２に示すＣＰＵ２０１が図１０に示す承認画面を生成しクライアント１０２に送信する）とを有することを特徴とする。
【００１３】
本発明に係る第６の発明は、前記第２の特定手段は、申請日における組織情報より特定される否認時の戻り先と前記承認要求時における組織情報より特定される否認時の戻り先とが異なる場合には、それぞれを否認時の戻り先予定者として特定することを特徴とする。
【００１４】
本発明に係る第７の発明は、前記第２の選択手段は、前記第２の特定手段により複数の否認時の戻り先予定者が特定されている場合には、クライアントに送信する承認画面（図１０に示す承認画面）上で前記複数の否認時の戻り先予定者からいずれかを選択させることを特徴とする。
【００１５】
本発明に係る第８の発明は、前記第２の選択手段により選択された否認時の戻り先に対して否認された伝票データが存在する旨を通知する第２の通知手段（図２に示すＣＰＵ２０１）を設けたことを特徴とする。
【００１６】
本発明に係る第９の発明は、役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に複数記憶可能な第３の記憶手段（図１に示す承認経路情報ＤＢ１０１４）と、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成手段（図２に示すＣＰＵ２０１）とを有することを特徴とする。
【００１７】
本発明に係る第１０の発明は、前記生成手段により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第３の特定手段（図２に示すＣＰＵ２０１）と、前記第３の特定手段により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第３の通知手段（図２に示すＣＰＵ２０１）とを設けたことを特徴とする。
【００１８】
本発明に係る第１１の発明は、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段とを有するワークフローサーバと、複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御方法において、前記いずれかのクライアントからの承認要求に応じて、前記ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定工程（図８のステップＳ２１３〜Ｓ２１６）と、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる選択工程（図８のステップＳ２２０，図８のステップＳ２０２〜Ｓ２０４）とを有することを特徴とする。
【００１９】
本発明に係る第１２の発明は、前記選択工程により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知工程（図９のステップＳ２２３）を設けたことを特徴とする。
【００２０】
本発明に係る第１３の発明は、前記ワークフローサーバに役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に記憶する第３の記憶手段を設け、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成工程（図７のステップＳ１１４〜Ｓ１１５）を設けたことを特徴とする。
【００２１】
本発明に係る第１４の発明は、前記生成工程により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第２の特定工程（図７のステップＳ１１６〜Ｓ１１７）と、前記第２の特定工程により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第２の通知工程（図７のステップＳ１１８）とを設けたことを特徴とする。
【００２２】
本発明に係る第１５の発明は、請求項１１〜１４に記載されたワークフローシステムの制御方法を実行するためのプログラムであることを特徴とする。
【００２３】
本発明に係る第１６の発明は、請求項１１〜１４に記載されたワークフローシステムの制御方法を実行するためのプログラムを記録媒体にコンピュータが読み取り可能に記憶させたことを特徴とする。
【発明の効果】
【００２４】
本発明によれば、クライアントからの承認要求に応じて、ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させるので、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる等の効果を奏する。
【発明を実施するための最良の形態】
【００２５】
以下、図面を参照して、ワークフローシステムにおける組織変更前後の承認者決定方法について説明する。
【００２６】
〔第１実施形態〕
図１は、本発明の第１実施形態を示すワークフローサーバ及びクライアントを適用可能なワークフローシステム（電子決裁システム）の構成の一例を示すブロック図である。
【００２７】
図において、１０１はワークフローサーバ（電子決裁サーバ（以下、サーバ））で、イーサネット（登録商標）等のネットワーク１０３を介して複数のワークフロークライアント（情報処理装置（以下、クライアント））１０２ａ，１０２ｂ，１０２ｃ，……（以下単に、クライアント１０２）と通信可能である。
【００２８】
サーバ１０１は、人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５を有する。
【００２９】
なお、クライアント１０２は、ユーザが入出力するためのパーソナルコンピュータ（ＰＣ）又はワークステーション等にワークフローを利用するためのアプリケーションまたはＷｅｂ環境を用意したものである。
【００３０】
また、サーバ１０１は、クライアント１０２からのリクエストを受け付け、ワークフローシステムが持つＤＢ１０１０の内容を更新する。
【００３１】
サーバ１０１は、ユーザから伝票を受け付けたこと（申請処理）に応じて、人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４等を用いて、伝票データを生成し、伝票データＤＢ１０１５に格納する。
【００３２】
図２は、図１に示したサーバ１０１の構成を示すブロック図である。
【００３３】
図において、２０１はＣＰＵで、ＲＯＭ２０３のプログラム用ＲＯＭに記憶されたプログラムに基づいてシステムバス２０４に接続された各デバイスを制御し、サーバ１０１全体を統括制御する。
【００３４】
また、このＲＯＭ２０３のフォント用ＲＯＭにはフォントデータ等を記憶し、ＲＯＭ２０３のデータ用ＲＯＭには各種データを記憶する。２０２はＲＡＭで、ＣＰＵ２０１の主メモリ，ワークエリア等として機能する。
【００３５】
２０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）２０９や図示しないポインティングデバイス、例えばマウスからの入力を制御する。２０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。なお、ここでは、表示装置としてＣＲＴを設けているがＬＣＤ等のその他の形式の表示装置であってもよい。
【００３６】
２０７はメモリコントローラ（ＭＣ）で、図１に示した人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５を構成するハードディスク（ＨＤ）２１１とのアクセスを制御する。２０８はネットワークインタフェース（ＮＷＩ／Ｆ）で、ネットワーク１０３との通信を制御する。
【００３７】
以上のような構成により、サーバ１０１はネットワークを介してクライアント１０２と通信して、クライアントの指示に基づいて、上述したＤＢ内の各種データ等の送受信を行う。
【００３８】
また、ＣＰＵ２０１は、ユーザからの指示（ＫＢ２０９又は図示しないマウス等からの指示や図１に示したクライアント１０２からの指示等）に基づいて種々の機能（後述するフローチャートに示す）に対応する処理を実行する。
【００３９】
なお、図に示した、ＫＢ２０９，ＣＲＴ２１０等は必ずしも備えていなくてもよい。
【００４０】
図３は、図１に示したクライアント１０２の構成を示すブロック図である。
【００４１】
図において、３０１はＣＰＵで、ＲＯＭ３０３のプログラム用ＲＯＭに記憶されたプログラムに基づいてシステムバス３０４に接続された各デバイスを制御し、クライアント１０２全体を統括制御する。
【００４２】
また、このＲＯＭ３０３のフォント用ＲＯＭにはフォントデータ等を記憶し、ＲＯＭ３０３のデータ用ＲＯＭには各種データを記憶する。３０２はＲＡＭで、ＣＰＵ３０１の主メモリ，ワークエリア等として機能する。
【００４３】
３０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）３０９や例えばマウス等のポインティングデバイス（ＰＤ）３１２からの入力を制御する。３０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）３１０の表示を制御する。なお、ここでは、表示装置としてＣＲＴを設けているがＬＣＤ等のその他の形式の表示装置であってもよい。
【００４４】
３０７はメモリコントローラ（ＭＣ）で、ハードディスク（ＨＤ）３１１とのアクセスを制御する。３０８はネットワークインタフェース（ＮＷＩ／Ｆ）で、ネットワーク１０３との通信を制御する。
【００４５】
以上のような構成により、クライアント１０２はネットワーク１０３を介してサーバ１０１と通信して、サーバ１０１が管理する人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５等内のデータの取得、閲覧および申請，承認等を行うことができる。
【００４６】
また、ＣＰＵ３０１は、ユーザからの指示（ＫＢ３０９又はＰＤ３１２等からの指示）に基づいてサーバ１０１に対して種々の機能に対応する処理の実行を指示することができる。
【００４７】
さらに、サーバ１０１，クライアント１０２は、図示しないフレキシブルディスクデバイスやＣＤ−ＲＯＭデバイス等を備えるものとする。
【００４８】
図４は、図１に示した人事情報ＤＢ１０１１内のデータ構成の一例を示す図である。
【００４９】
図において、４００は人事情報で、社員番号４０１，氏名４０２，ユーザＩＤ４０３等により構成される。なお、氏名４０２は、ユーザの実氏名に対応する。
【００５０】
また、人事情報ＤＢ１０１１は、人事情報４００をユーザの数だけ含むものである。
【００５１】
図５は、図１に示した伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４内のデータ構成及び関係を示す図である。
【００５２】
図において、６００は伝票情報で、伝票種別６０１，経路情報インデックス６０２，伝票の入力項目定義６０３等から構成される。
【００５３】
ここで、伝票種別６０１は、伝票の種別を示す。経路情報インデックス６０２は、承認経路情報７００内に保持される承認経路ＩＤ７０１に対応するものであり、この経路情報インデックス６０２により、承認経路情報７００のデータを特定する。伝票の入力項目定義６０３は、伝票の内容を示す各種入力項目が定義されている。
【００５４】
ここで、伝票情報ＤＢ１０１３は、伝票情報６００を伝票種別の数だけ含むものである。
【００５５】
７００は承認経路情報で、承認経路ＩＤ７０１，承認経路７０２等から構成される。ここで、承認経路ＩＤ７０１は、各承認経路情報７００固有の値となっている。また、承認経路７０２は、役割（役職）を羅列（順序構造を有する１次元配列（「１」から始まる））した１組のデータであり、例えば、「１：課長，２：部長，３：経理担当，４：経理課長，５：経理部長」等である。
【００５６】
なお、承認経路情報ＤＢ１０１４は、承認経路情報７００を承認経路の数だけ含むものである。
【００５７】
図６は、図１に示した伝票データＤＢ１０１５，組織情報ＤＢ１０１２内のデータ構成及び関係を示す図である。
【００５８】
図において、８００は伝票データで、伝票番号８０１，申請日８０２，申請者８０３，所属部署８０４，伝票名称８０５，承認経路８０６，伝票の入力データ８０７，コメント８０８等から構成される。
【００５９】
ここで、伝票番号８０１は、伝票の申請毎にサーバ１０１により付与されるシリアルナンバである。申請日８０２は、後述する伝票の申請処理を行った日付である。申請者８０３は、伝票の申請処理を行ったユーザの氏名である。伝票名称８０５は、伝票の申請処理時にユーザにより任意に入力可能なものである。
【００６０】
承認経路８０６は、サーバ１０１により、伝票の申請処理時に伝票の種類に応じて特定される承認経路であり、図５に示した承認経路７０２に基づいて生成される。この承認経路８０６は、役割８０６ａ，承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃから構成される。承認ユーザ名（ＩＤ）８０６ｂは、承認又は否認を行うユーザ名又はＩＤが格納される。承認結果８０６ｃは、デフォルトとして「０」が格納され、承認時には「１」，否認時には「−１」が格納される。この図に示す例では、課長により承認され、部長により否認された状態を示している。
【００６１】
８０７は伝票入力データで、伝票の申請処理時に申請者により入力される伝票の内容に対応する。８０８はコメントで、後述する承認処理時（承認時又は否認時）に、承認者により任意に入力可能である。
【００６２】
ここで、伝票データＤＢ１０１５は、伝票データ８００を申請された伝票データの数だけ含むものである。
【００６３】
５００は組織情報で、適用日５０１，組織データ５０２等から構成される。ここで、適用日５０１は、組織データ５０２を適用する日付けデータに対応する。また、組織データ５０２は、組織名（部，課の名称等），組織構成（部課のメンバの氏名等），役割（役職）の名称（社長，営業部長，経理課長等），役割に対応するユーザの氏名等で構成される。
【００６４】
このように、組織情報５００に、適用日５０１を保持し、適用日の異なる複数の組織情報を組織情報ＤＢ１０１２に保持することができる。これにより、組織変更が行われても、過去の組織情報をいつでも参照することができる。また、伝票データ８００を作成した日付（申請日８０２）での組織データと、承認する時点での組織データをそれぞれ参照することにより、次に承認する予定の候補者を複数抽出することができる。例えば、申請日での営業課長と承認時での営業課長が異なる場合には、２人を次に承認する予定の候補者として抽出し、選択可能である。
【００６５】
以下、図７〜図９のフローチャートを参照して、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける伝票の申請処理及び伝票の承認処理について説明する。
【００６６】
図７は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。なお、図７（ａ）はクライアント側の申請処理手順に対応し、図３に示したＣＰＵ３０１によりＨＤ３１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ１０１〜Ｓ１０５は各ステップを示す。
【００６７】
さらに、図７（ｂ）はサーバ側の申請処理手順に対応し、図２に示したＣＰＵ２０１によりＨＤ２１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ１１１〜Ｓ１１８は各ステップを示す。
【００６８】
まず、図７（ａ）を用いて、クライアント側の申請処理について説明する。
【００６９】
伝票の申請（起票）を行なうユーザ（申請者）が、クライアント１０２から自己を特定するためのログイン処理を行ない、申請（起票）する伝票種類の指定を行なうと、ステップＳ１０１において、伝票の種類と申請処理要求をサーバ１０１に対して送信する。
【００７０】
次に、サーバ１０１から指定した伝票の申請画面を受信すると、ステップＳ１０２において、受信した申請画面をＣＲＴ３１０に表示する。
【００７１】
次に、申請者より、図示しない申請画面上において、伝票毎に定められた事項が入力され、必要な情報の入力完了後、申請実行が指示されると（Ｓ１０３）、ステップＳ１０４において、入力内容をサーバ１０１に送信し、ステップＳ１０５において、申請画面を閉じ、処理を終了する。なお、図示していないが、ステップＳ１０３で、図示しないキャンセルキー等が押下されキャンセル指示を検知した場合、サーバ１０１にキャンセル通知を送信し、そのまま処理を終了するものとする。また、サーバ１０１からの正常終了通知の有無を判定し、正常終了通知を受信した場合にはそのまま処理を終了し、所定時間内に申請終了通知を受信しない場合又はエラー通知を受信した場合には、エラー処理を行うように構成してもよい。
【００７２】
次に、図７（ｂ）を用いて、サーバ側の申請処理について説明する。
【００７３】
まず、クライアント１０２より、申請者がログインすると、申請者のユーザＩＤに基づいて人事情報を読み出し、さらに、クライアント１０２より、伝票の種類と申請処理要求を受信すると、ステップＳ１１１において、該受信した伝票の種類に対応する伝票情報を読み出し、ステップＳ１１２において、申請画面を作成し、ステップＳ１１３において、作成した申請画面を申請画面の要求を行ったクライアント１０２に送信する。
【００７４】
次に、クライアント１０２から申請画面における入力内容（申請者が入力した情報）を受信すると、ステップＳ１１４において、ステップＳ１１１で読み出した伝票情報内の経路情報インデックスに基づいて伝票毎に定められた承認経路情報を読み出し、該読み出した承認経路情報，受信した入力内容，申請日（現在日），申請者の氏名等に基づいて伝票データを作成する（Ｓ１１５）。
【００７５】
次に、ステップＳ１１６において、申請日における組織情報を読み出し、ステップＳ１１７において、申請者が所属する部署に基づいて伝票データを次に承認処理する役割（役職）に相当する実ユーザを特定し、ステップＳ１１８において、そのユーザ（次承認者）に承認処理が必要な伝票データが到来した旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。なお、図示していないが、（クライアント１０２側のユーザによりキャンセルキー等が押下され）クライアント１０２から送信されるキャンセル通知を受信した場合には、そのまま処理を終了するものとする。また、ステップＳ１１１〜１１８の処理が正常終了した場合には、クライアント１０２に対して伝票の申請終了通知を送信した後、正常に終了しなかった場合には、クライアント１０２に対してエラー通知を送信するように構成してもよい。
【００７６】
なお、図７のフローチャートでは、サーバ１０１側で申請画面を作成してクライアント１０２に送信し、クライアント１０２側で表示させる構成について説明したが、サーバ１０１側から申請画面の表示に必要な情報をクライアント１０２に送信し、クライアント１０２側のアプリケーション等でサーバ１０１より受信した情報に基づく申請画面を作成表示させるように構成してもよい。
【００７７】
図８，図９は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。なお、図８（ａ）はクライアント側の承認処理手順に対応し、図３に示したＣＰＵ３０１によりＨＤ３１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ２０１〜Ｓ２０５は各ステップを示す。
【００７８】
さらに、図８（ｂ），図９はサーバ側の承認処理手順に対応し、図２に示したＣＰＵ２０１によりＨＤ２１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ２１１〜Ｓ２２５は各ステップを示す。
【００７９】
まず、図８（ａ）を用いて、クライアント側の承認処理について説明する。
【００８０】
承認を行なうユーザ（図７のステップＳ１１８でサーバ１０１より送信された通知を受け取った次承認者）が、クライアント１０２から自己を特定するためのログイン処理を行ない、承認する伝票データの指定を行なうと、ステップＳ２０１において、伝票データ指定（伝票番号８０１等）と承認処理要求をサーバ１０１に対して送信する。
【００８１】
次に、サーバ１０１から指定した伝票データの承認画面を受信すると、ステップＳ２０２において、受信した承認画面（後述する図１０）をＣＲＴ３１０に表示する。
【００８２】
次に、承認者より、図１０に示す承認画面上において、次承認予定者，否認時の戻り先等の指示及びコメントの入力がなされ（必要な場合のみ）、承認（図１０に示す承認ボタン１００５）又は否認（図１０に示す否認ボタン１００４）が指示されると（Ｓ２０３）、ステップＳ２０４において、承認又は否認の指示，次承認者，否認時の戻り先のデータ，コメント等をサーバ１０１に送信し、ステップＳ２０５において、承認画面を閉じ、処理を終了する。なお、図示していないが、ステップＳ２０３で、図１０に示すキャンセルキー１００６が押下されキャンセル指示を検知した場合、サーバ１０１にキャンセル通知を送信し、そのまま処理を終了するものとする。また、サーバ１０１からの正常終了通知の有無を判定し、正常終了通知を受信した場合にはそのまま処理を終了し、所定時間内に申請終了通知を受信しない場合又はエラー通知を受信した場合には、エラー処理を行うように構成してもよい。また、このフローチャートには、図示しないが、図１０に示すキャンセルボタン１００６が指示された場合には、キャンセルされた旨をサーバ１０１に送信し、そのまま処理を終了するものとする。
【００８３】
次に、図８（ｂ）及び図９を用いて、サーバ側の承認処理について説明する。
【００８４】
まず、クライアント１０２より、承認者がログインすると、承認者のユーザＩＤに基づいて人事情報を読み出し、さらに、クライアント１０２より、伝票データの指定（伝票番号８０１等）と承認処理要求を受信すると、ステップＳ２１１において、該受信した伝票データの指定に対応する伝票データ８００を読み出し、ステップＳ２１２において、承認画面を作成する（後述する図１０に示す１００２ａ，１００２ｂ以外を作成）。
【００８５】
次に、ステップＳ２１３において、申請日８０２における組織情報（Ａ）を読み出し、申請者が所属する部署（所属部署８０４）に基づいて、承認経路８０６において、伝票データを次に承認処理する役割（役職）に相当する実ユーザと、否認した場合の戻り先となる役割（役職）に相当する実ユーザを特定する。次に、現在日における組織情報（Ｂ）を読み出し、申請者が所属する部署（所属部署８０４）に基づいて、承認経路８０６において、伝票データを次に承認処理する役割（役職）に相当する実ユーザ（所属／氏名等表示）と、否認した場合の戻り先となる役割（役職）に相当する実ユーザ（所属／氏名等表示）を特定する。
【００８６】
次に、ステップＳ２１４において、次の承認者が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであるか否かを判定し、同じでない（異なる）と判断した場合には、ステップＳ２１６において、該組織情報（Ａ）における次の承認者の候補と組織情報（Ｂ）における次の承認者の候補を承認画面上の次の承認予定者表示欄１００２ａに選択可能に付加し、ステップＳ２１７に進む。
【００８７】
一方、ステップＳ２１４で、次の承認者が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであると判断した場合には、該次の承認者を承認画面上の次の承認予定者表示欄１００２ａに付加し（１人のみのため選択不可能に付加）、ステップＳ２１７に進む。なお、ここでは図示していないが、承認経路８０６において次の承認者がいない場合には、そのままステップＳ２１７に進む。
【００８８】
次に、ステップＳ２１７において、否認時の戻り先が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであるか否かを判定し、同じでない（異なる）と判断した場合には、ステップＳ２１９において、該組織情報（Ａ）における否認時の戻り先の候補と組織情報（Ｂ）における否認時の戻り先の候補とを承認画面上の否認時の戻り先表示欄１００２ｂに選択可能に付加し、ステップＳ２２０に進む。
【００８９】
一方、ステップＳ２１７で、否認時の戻り先が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであると判断した場合には、ステップＳ２１８において、該否認時の戻り先を承認画面上の否認時の戻り先表示欄１００２ｂに付加し（１人のみのため選択不可能に付加）、ステップＳ２２０に進む。なお、ここでは図示していないが、承認経路８０６において、否認時の戻り先がない場合は、申請者を否認時の戻り先表示欄１００２ｂに付加し、ステップＳ２２０に進む。
【００９０】
次に、ステップＳ２２０において、作成した承認画面を承認画面の要求を行ったクライアント１０２に送信する。
【００９１】
次に、クライアント１０２から承認画面における承認又は否認の指示，次承認者，否認時の戻り先のデータ，コメント等を受信すると、ステップＳ２２１において、受信した指示が承認であるか否かを判定し、承認であると判断した場合には、ステップＳ２２２において、現承認者の情報と承認結果（承認「１」）を伝票データ内の承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃにそれぞれ格納して伝票データを伝票データＤＢ１０１５に保存（更新）し、ステップＳ２２３において、受信した次承認者に承認待ちデータがある旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。なお、ここでは図示していないが、次承認者がいない場合には、申請者に申請した伝票データが承認された旨（伝票番号，伝票名称も含む）の通知を行い、該伝票データを図示しない承認済みＤＢに移動させるものとする。
【００９２】
一方、ステップＳ２２１で、受信した指示が承認であると判断した場合には、ステップＳ２２４において、現承認者の情報と承認結果（否認「−１」）を伝票データ内の承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃにそれぞれ格納して伝票データを伝票データＤＢ１０１５に保存（更新）し、ステップＳ２２５において、否認時の戻り先に否認された戻りデータがある旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。
【００９３】
なお、図示していないが、（クライアント１０２側のユーザにより図１０に示すキャンセルキー１００６が押下され）クライアント１０２から送信されるキャンセル通知を受信した場合には、そのまま処理を終了するものとする。また、ステップＳ２１１〜２２５の処理が正常終了した場合には、クライアント１０２に対して伝票の申請終了通知を送信し、正常に終了しなかった場合には、クライアント１０２に対してエラー通知を送信するように構成してもよい。
【００９４】
また、このフローチャートでは図示しないが、クライアント１０２からキャンセルされた旨の通知が送信された場合には、伝票データＤＢ１０１５を更新することなく、そのまま処理を終了するものとする。
【００９５】
なお、図８，図９のフローチャートでは、サーバ１０１側で、該認証画面にサーバ１０１側で特定した複数の「次承認予定者」と複数の「否認時の戻り先」と選択可能に付加した認証画面を生成してクライアント１０２に送信し、クライアント１０２側で表示させる構成について説明したが、サーバ１０１側で特定した複数の「次承認予定者」と複数の「否認時の戻り先」の情報をクライアント１０２に送信し、クライアント１０２側のアプリケーション等でサーバ１０１より受信した情報に基づいて複数の「次承認予定者」と複数の「否認時の戻り先」とを選択可能に付加した認証画面を作成表示させるように構成してもよい。
【００９６】
図１０は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける承認面の一例を示す模式図であり、承認処理時にクライアント１０２のＣＲＴ３１０に表示される。
【００９７】
図において、１００１は申請者データ表示エリアで、伝票データ８００内の申請日８０２，申請者８０３，所属部署８０４等が表示される。
【００９８】
１００２は次承認者及び否認時の戻り先選択エリアで、次の承認予定者の所属／氏名等を表示する次の承認予定者表示欄１００２ａ，否認時の戻り先の所属／氏名等を表示する否認時の戻り先表示欄１００２ｂから構成される。
【００９９】
申請日での組織情報から、申請者が所属する部署を基に、伝票データを自分の次に承認処理する役割（役職）に相当する実ユーザ（Ｎｅｘｔ−１）と、否認した場合の戻り先となる実ユーザ（Ｂａｃｋ−１）を特定し、さらに、承認処理を行なっている現在日での組織情報から、申請者が所属する部署を基に、伝票データを自分の次に承認処理する役割（役職）に相当する実ユーザ（Ｎｅｘｔ−２）と、否認した場合の戻り先となる実ユーザ（Ｂａｃｋ−２）を特定し、次の承認予定者表示欄１００２ａには、次の承認候補者であるＮｅｘｔ−１とＮｅｘｔ−２をＰＤ３１２等により選択できるユーザＩ／Ｆにて表示する。なお、Ｎｅｘｔ−１とＮｅｘｔ−２が同一人物である場合には選択の必要がないため、単に次の承認予定実ユーザを表示するのみとなる。また、否認時の戻り先表示欄１００２ｂには、戻り先候補者であるＢａｃｋ−１とＢａｃｋ−２をＰＤ３１２等により選択できるユーザＩ／Ｆにて表示する。なお、Ｂａｃｋ−１とＢａｃｋ−２が同一人物である場合には選択の必要がないため、単に戻り先実ユーザを表示するのみとなる。
【０１００】
１００３は伝票内容表示欄で、伝票内容としての伝票名称８０５，伝票の入力データ８０７が表示されるとともに、前の承認者又は否認者等により入力されたコメント８０８が入力者の部署／氏名とともに表示される。１００７はコメント入力欄で、新規に任意のコメントをＫＢ３０９等で入力することができる。
【０１０１】
１００４は否認ボタンで、伝票内容を否認する場合にＰＤ３１２により指示する。１００５は承認ボタンで、伝票内容を承認する場合にＰＤ３１２により指示する。１００６はキャンセルボタンで、承認処理を中止する場合にＰＤ３１２により指示する。また、キャンセル通知がサーバ１０１に送信される。
【０１０２】
以上説明したように、現承認者は、クライアント１０２の画面（ＣＲＴ３１０）に表示された承認画面により、伝票の内容を確認し、承認する場合であれば、その伝票の決裁に相応しい次の承認実ユーザを次の承認予定者表示欄１００２ａで選択し、承認ボタン１００５を指示する。また、否認する場合であれば、その伝票の戻り先に相応しい実ユーザを否認時の戻り先表示欄１００２ｂにより選択し、否認ボタン１００４を指示する。
【０１０３】
これらの現承認者からの指示に従い、サーバ１０１は、承認または否認の結果を伝票データに書き出し、次の処理担当となる承認実ユーザまたは戻り先実ユーザに承認処理または否認処理が必要な伝票データの到来を通知する。
【０１０４】
図１１は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける承認者候補の遷移の一例を示す図である。
【０１０５】
図に示すように、伝票データの申請後に組織変更があった場合でも、各承認者は、伝票の性質等を考慮して、組織変更前の承認予定者又は組織変更後の承認予定者のいずれかを選択して伝票を渡すことができる。
【０１０６】
以上に示すように、本実施形態のワークフローシステムの組織情報は、構成要素に「適用日」を含むことにより、適用日の異なる複数の組織情報を持つことができ、組織変更前の組織情報をワークフローシステムに残すことができる。
【０１０７】
また、本実施形態のワークフローシステムの伝票情報は、構成要素に「承認経路情報を特定するインデックス」を持ち、伝票種に応じた承認経路情報（役割（役職）の羅列によって順路を定義される）を関連付けておくものである。
【０１０８】
さらに、本実施形態のワークフローシステムの伝票データは、構成要素に「申請日」を持つことにより、申請した時点の日付を保持しておくことができる。また、この「申請日」と上記「適用日付組織情報」により、申請時点での組織情報を特定することができ、申請者の所属に応じた「次承認者」を実ユーザ名で特定することができる。
【０１０９】
また、本実施形態のワークフローシステムでは、承認画面に、承認する場合の「次承認実ユーザ名」と、否認する場合の「戻り先実ユーザ名」を表示し、その時点（承認画面表示時点）の組織情報による「次承認実ユーザ」（「戻り先実ユーザ」）と、申請日付での組織情報による「次承認実ユーザ」（「戻り先実ユーザ」）が異なる場合には、それらの候補者の中から「次承認実ユーザ」（「戻り先実ユーザ名」）を選択できるようにする。
【０１１０】
そして、承認画面の操作者は、「次承認実ユーザ名」または「戻り先実ユーザ名」を必要に応じて変更し、承認／否認を行い、承認又は否認された伝票データは、選択された次承認者／戻り先の承認待ちデータとなるものとする。
【０１１１】
以上の構成により、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と現時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、組織変更時の伝票データの取り扱いに自由度が増し、現実に即した対応が可能となる。
【０１１２】
また、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができる。
【０１１３】
さらに、組織情報内に適用日を含むことにより、システムの管理者は、組織変更に先立って新しい情報を事前登録しておくことが可能となる。
【０１１４】
〔第２実施形態〕
上記第１実施形態では、申請時点での組織情報と現時点（承認画面表示時点）での組織情報のいずれかで適切な承認者を伝票データ毎に選択する構成について説明したが、申請時点から現時点（承認画面表示時点）までに適用された全ての組織情報のいずれかで適切な承認者を伝票データ毎に選択可能に構成してもよい。
【０１１５】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組み合わせを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【０１１６】
以下、図１２，図１３に示すメモリマップを参照して本発明に係るワークフローサーバ及びクライアントを適用可能なワークフローシステムで読み出し可能なデータ処理プログラムの構成について説明する。
【０１１７】
図１２は、本発明に係るクライアント（クライアント１０２）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１１８】
図１３は、本発明に係るワークフローサーバ（サーバ１０１）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１１９】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１２０】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１２１】
本実施形態における図７，図８，図９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１２２】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１２３】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１２４】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１２５】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２６】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２７】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１２８】
さらに、本発明を達成するためのソフトウエアによって表されるプログラムをネットワーク上のデータベースから通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【図面の簡単な説明】
【０１２９】
【図１】本発明の第１実施形態を示す電子決裁サーバ及び情報処理装置を適用可能なワークフローシステム（電子決裁システム）の構成の一例を示すブロック図である。
【図２】図１に示したサーバの構成を示すブロック図である。
【図３】図１に示したクライアントの構成を示すブロック図である。
【図４】図１に示した人事情報ＤＢ内のデータ構成の一例を示す図である。
【図５】図１に示した伝票情報ＤＢ，承認経路情報ＤＢ内のデータ構成及び関係を示す図である。
【図６】図１に示した伝票データＤＢ，組織情報ＤＢ内のデータ構成及び関係を示す図である。
【図７】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図８】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図９】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１０】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける承認面の一例を示す模式図である。
【図１１】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける承認者候補の遷移の一例を示す図である。
【図１２】本発明に係る情報処理装置（クライアント）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【図１３】本発明に係る情報処理装置（サーバ）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【符号の説明】
【０１３０】
１０１    ワークフローサーバ
１０２ａ〜１０２ｃ    ワークフロークライアント
１０３    ネットワーク
１０１１    人事情報ＤＢ
１０１２    組織情報ＤＢ
１０１３    伝票情報ＤＢ
１０１４    承認経路情報ＤＢ
１０１５    伝票データＤＢ
【図１】
2008269654.tif 000003
【図２】
2008269654.tif 000004
【図３】
2008269654.tif 000005
【図４】
2008269654.tif 000006
【図５】
2008269654.tif 000007
【図６】
2008269654.tif 000008
【図７】
2008269654.tif 000009
【図８】
2008269654.tif 000010
【図９】
2008269654.tif 000011
【図１０】
2008269654.tif 000012
【図１１】
2008269654.tif 000013
【図１２】
2008269654.tif 000014
【図１３】
2008269654.tif 000015
【手続補正書】
【提出日】平成20年9月3日(2008.9.3)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
所定の通信媒体を介して情報処理装置と通信可能なワークフローサーバにおいて、
組織における役割名と該役割名に対応するユーザ名を定義する組織データを適用日と対応付けて複数記憶可能な第１の記憶手段と、
承認内容，役割名により定義される承認経路情報，申請日に結びつく伝票データを複数記憶可能な第２の記憶手段と、
前記情報処理装置から受信される伝票データの指定要求に応じて、前記第２の記憶手段に記憶された伝票データのうち、該指定された伝票データを読み出す読出し手段と、
前記伝票データの申請日における組織データと現在日における組織データとを読み出し、前記伝票データの申請者が属する部署に基づいて、承認経路情報において当該伝票データを次に承認処理する役割に相当するユーザ名を特定可能な特定手段と、
前記読出し手段で読み出された伝票データの承認先を適用する組織データを変更する承認先変更画面を表示するための情報を、前記情報処理装置に送信する情報送信手段と、
前記情報送信手段により送信された情報により表示される承認先変更画面を介して前記情報処理装置から、当該伝票データに適用する組織データを、前記申請日における組織データから前記現在日における組織データへの変更を受け付ける変更受付手段と、
前記情報処理装置からの入力により、前記変更受付手段に前記現在日における組織情報へ変更指示がある場合、前記読み出された伝票データの承認先を、前記特定手段により特定される現在日における前記役割に相当するユーザ名に変更する変更手段と、
を有することを特徴とするワークフローサーバ。
【請求項２】
前記特定手段は、申請時点から現時点までに適用された全ての組織情報に基づいて複数特定可能であることを特徴とする請求項１記載のワークフローサーバ。
【請求項３】
前記第１の記憶手段は、将来の組織情報を登録可能であることを特徴とする請求項１又は２記載のワークフローサーバ。
【請求項４】
前記変更手段は、前記情報処理装置からの入力により、前記変更受付手段に前記現在日における組織情報へ変更指示がある場合、前記読み出された伝票データの否認先を、前記特定手段により特定される現在日における前記役割に相当するユーザ名に変更することを特徴とする請求項１乃至３のいずれか１項に記載のワークフローサーバ。
【請求項５】
組織における役割名と該役割名に対応するユーザ名を定義する組織データを適用日と対応付けて複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日に結びつく伝票データを複数記憶可能な第２の記憶手段とを有し、所定の通信媒体を介して情報処理装置と通信可能なワークフローサーバの制御方法において、
読み出す読出し手段が、前記情報処理装置から受信される伝票データの指定要求に応じて、前記第２の記憶手段に記憶された伝票データのうち、該指定された伝票データを読み出す読出しステップと、
特定手段が、前記伝票データの申請日における組織データと現在日における組織データとを読み出し、前記伝票データの申請者が属する部署に基づいて、承認経路情報において当該伝票データを次に承認処理する役割に相当するユーザ名を特定可能な特定ステップと、
情報送信手段が、前記読出しステップで読み出された伝票データの承認先を適用する組織データを変更する承認先変更画面を表示するための情報を、前記情報処理装置に送信する情報送信ステップと、
変更受付手段が、前記情報送信ステップにより送信された情報により表示される承認先変更画面を介して前記情報処理装置から、当該伝票データに適用する組織データを、前記申請日における組織データから前記現在日における組織データへの変更を受け付ける変更受付ステップと、
変更手段が、前記情報処理装置からの入力により、前記変更受付手段に前記現在日における組織情報へ変更指示がある場合、前記読み出された伝票データの承認先を、前記特定手段により特定される現在日における前記役割に相当するユーザ名に変更する変更ステップと、
を有することを特徴とするワークフローサーバの制御方法。
【請求項６】
所定の通信媒体を介して情報処理装置と通信可能なワークフローサーバを、
組織における役割名と該役割名に対応するユーザ名を定義する組織データを適用日と対応付けて複数記憶可能な第１の記憶手段と、
承認内容，役割名により定義される承認経路情報，申請日に結びつく伝票データを複数記憶可能な第２の記憶手段と、
前記情報処理装置から受信される伝票データの指定要求に応じて、前記第２の記憶手段に記憶された伝票データのうち、該指定された伝票データを読み出す読出し手段と、
前記伝票データの申請日における組織データと現在日における組織データとを読み出し、前記伝票データの申請者が属する部署に基づいて、承認経路情報において当該伝票データを次に承認処理する役割に相当するユーザ名を特定可能な特定手段と、
前記読出し手段で読み出された伝票データの承認先を適用する組織データを変更する承認先変更画面を表示するための情報を、前記情報処理装置に送信する情報送信手段と、
前記情報送信手段により送信された情報により表示される承認先変更画面を介して前記情報処理装置から、当該伝票データに適用する組織データを、前記申請日における組織データから前記現在日における組織データへの変更を受け付ける変更受付手段と、
前記情報処理装置からの入力により、前記変更受付手段に前記現在日における組織情報へ変更指示がある場合、前記読み出された伝票データの承認先を、前記特定手段により特定される現在日における前記役割に相当するユーザ名に変更する変更手段と、
として機能させるためのプログラム。
【請求項７】
所定の通信媒体を介して情報処理装置と通信可能なワークフローサーバを、
組織における役割名と該役割名に対応するユーザ名を定義する組織データを適用日と対応付けて複数記憶可能な第１の記憶手段と、
承認内容，役割名により定義される承認経路情報，申請日に結びつく伝票データを複数記憶可能な第２の記憶手段と、
前記情報処理装置から受信される伝票データの指定要求に応じて、前記第２の記憶手段に記憶された伝票データのうち、該指定された伝票データを読み出す読出し手段と、
前記伝票データの申請日における組織データと現在日における組織データとを読み出し、前記伝票データの申請者が属する部署に基づいて、承認経路情報において当該伝票データを次に承認処理する役割に相当するユーザ名を特定可能な特定手段と、
前記読出し手段で読み出された伝票データの承認先を適用する組織データを変更する承認先変更画面を表示するための情報を、前記情報処理装置に送信する情報送信手段と、
前記情報送信手段により送信された情報により表示される承認先変更画面を介して前記情報処理装置から、当該伝票データに適用する組織データを、前記申請日における組織データから前記現在日における組織データへの変更を受け付ける変更受付手段と、
前記情報処理装置からの入力により、前記変更受付手段に前記現在日における組織情報へ変更指示がある場合、前記読み出された伝票データの承認先を、前記特定手段により特定される現在日における前記役割に相当するユーザ名に変更する変更手段と、
として機能させるためのプログラムを記録したコンピュータ読取り可能な記録媒体。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と現時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる仕組みを提供することである。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
本発明は、所定の通信媒体を介して情報処理装置と通信可能なワークフローサーバにおいて、組織における役割名と該役割名に対応するユーザ名を定義する組織データを適用日と対応付けて複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日に結びつく伝票データを複数記憶可能な第２の記憶手段と、前記情報処理装置から受信される伝票データの指定要求に応じて、前記第２の記憶手段に記憶された伝票データのうち、該指定された伝票データを読み出す読出し手段と、前記伝票データの申請日における組織データと現在日における組織データとを読み出し、前記伝票データの申請者が属する部署に基づいて、承認経路情報において当該伝票データを次に承認処理する役割に相当するユーザ名を特定可能な特定手段と、前記読出し手段で読み出された伝票データの承認先を適用する組織データを変更する承認先変更画面を表示するための情報を、前記情報処理装置に送信する情報送信手段と、前記情報送信手段により送信された情報により表示される承認先変更画面を介して前記情報処理装置から、当該伝票データに適用する組織データを、前記申請日における組織データから前記現在日における組織データへの変更を受け付ける変更受付手段と、前記情報処理装置からの入力により、前記変更受付手段に前記現在日における組織情報へ変更指示がある場合、前記読み出された伝票データの承認先を、前記特定手段により特定される現在日における前記役割に相当するユーザ名に変更する変更手段とを有することを特徴とする。
【手続補正５】
【補正対象書類名】明細書
【補正対象項目名】０００９
【補正方法】削除
【補正の内容】
【手続補正６】
【補正対象書類名】明細書
【補正対象項目名】００１０
【補正方法】削除
【補正の内容】
【手続補正７】
【補正対象書類名】明細書
【補正対象項目名】００１１
【補正方法】削除
【補正の内容】
【手続補正８】
【補正対象書類名】明細書
【補正対象項目名】００１２
【補正方法】削除
【補正の内容】
【手続補正９】
【補正対象書類名】明細書
【補正対象項目名】００１３
【補正方法】削除
【補正の内容】
【手続補正１０】
【補正対象書類名】明細書
【補正対象項目名】００１４
【補正方法】削除
【補正の内容】
【手続補正１１】
【補正対象書類名】明細書
【補正対象項目名】００１５
【補正方法】削除
【補正の内容】
【手続補正１２】
【補正対象書類名】明細書
【補正対象項目名】００１６
【補正方法】削除
【補正の内容】
【手続補正１３】
【補正対象書類名】明細書
【補正対象項目名】００１７
【補正方法】削除
【補正の内容】
【手続補正１４】
【補正対象書類名】明細書
【補正対象項目名】００１８
【補正方法】削除
【補正の内容】
【手続補正１５】
【補正対象書類名】明細書
【補正対象項目名】００１９
【補正方法】削除
【補正の内容】
【手続補正１６】
【補正対象書類名】明細書
【補正対象項目名】００２０
【補正方法】削除
【補正の内容】
【手続補正１７】
【補正対象書類名】明細書
【補正対象項目名】００２１
【補正方法】削除
【補正の内容】
【手続補正１８】
【補正対象書類名】明細書
【補正対象項目名】００２２
【補正方法】削除
【補正の内容】
【手続補正１９】
【補正対象書類名】明細書
【補正対象項目名】００２３
【補正方法】削除
【補正の内容】
【手続補正２０】
【補正対象書類名】明細書
【補正対象項目名】００２４
【補正方法】変更
【補正の内容】
【００２４】
本発明によれば、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と現時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる等の効果を奏する。