JP4183491B2 - ワークフローサーバおよびワークフローシステムの制御方法およびプログラムおよび記録媒体 - Google Patents
ワークフローサーバおよびワークフローシステムの制御方法およびプログラムおよび記録媒体 Download PDFInfo
- Publication number
- JP4183491B2 JP4183491B2 JP2002341906A JP2002341906A JP4183491B2 JP 4183491 B2 JP4183491 B2 JP 4183491B2 JP 2002341906 A JP2002341906 A JP 2002341906A JP 2002341906 A JP2002341906 A JP 2002341906A JP 4183491 B2 JP4183491 B2 JP 4183491B2
- Authority
- JP
- Japan
- Prior art keywords
- approval
- information
- approver
- slip data
- slip
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Management, Administration, Business Operations System, And Electronic Commerce (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は、ワークフローサーバと複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御に関するものである。
【０００２】
【従来の技術】
従来の一般的なワークフローシステムでは、承認が必要な伝票の種類や伝票の申請者の情報及び組織情報等に基づいて承認すべきユーザが決定される構成となっていた。
【０００３】
また、このような従来のワークフローシステムでは、ワークフロー完了前に組織変更が発生してフローする承認者が異動となってしまった場合、組織変更前の組織情報に基づいて承認者を決定したり、組織変更後の組織情報に基づいて承認者を決定したりといったように、いずれもフローする承認者が一意に決定され、組織変更に対処していた。
【０００４】
【発明が解決しようとする課題】
しかしながら、「旅費・立替金清算」や「報告書」といった過去の事象を清算する伝票においては、変更後の組織情報から決定された承認者では信憑性の確認が難しく組織変更前の組織情報から決定された承認者に決裁されるのが望ましいと考えられるが、逆に、「購入要求」や「開催通知」といった今後の事象を届け出る伝票については、組織変更後の組織情報から決定された承認者に決裁されるのが望ましいと考えられる。しかしながら、上記従来のワークフローシステムでは、システムによりいずれか一意に決定される承認者にフローされるため、伝票の種類やフロー完了前に発生する各種事情に対応して、伝票を手渡しする場合のよういに、柔軟に承認者を変更（決定）することができないという問題点があった。
【０００５】
また、組織変更がある度に、組織変更に応じて、管理者等がフローする承認者を書き換えることにより、組織変更に対応するワークフローチャートシステムもあるが、管理者の管理負担が増大してしまうといった問題点があった。
【０００６】
さらに、各承認者が次の承認者を自由に決定するように構成されたワークフローシステムもあるが、フローする承認者に制約がかけられないという問題点があった。
【０００７】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、クライアントからの承認要求に応じて、ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させることにより、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる仕組みを提供することである。
【０００８】
【課題を解決するための手段】
本発明に係る第１の発明は、所定の通信媒体を介して複数のクライアント（図１に示すワークフロークライアント１０２ａ，１０２ｂ，１０２ｃ，……）と通信可能なワークフローサーバ（図１に示すワークフローサーバ１０１）において、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段（図１に示す組織情報ＤＢ１０１２）と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段（図１に示す伝票データＤＢ１０１５）と、前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段（図２に示すＣＰＵ２０１が図１０に示す承認画面内の次承認予定者１００２ａを特定）と、前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段（図２に示すＣＰＵ２０１が図１０に示す承認画面を生成しクライアント１０２に送信する）とを有することを特徴とする。
【０００９】
本発明に係る第２の発明は、前記第１の特定手段は、申請日における組織情報より特定される次承認者と前記承認要求時における組織情報より特定される次承認者とが異なる場合には、それぞれを承認時の次承認予定者として特定することを特徴とする。
【００１０】
本発明に係る第３の発明は、前記第１の選択手段は、前記第１の特定手段により複数の次承認予定者が特定されている場合には、クライアントに送信する承認画面（図１０に示す承認画面）上で前記複数の次承認予定者からいずれかを選択させることを特徴とする。
【００１１】
本発明に係る第４の発明は、前記第１の選択手段により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知手段（図２に示すＣＰＵ２０１）を設けたことを特徴とする。
【００１６】
本発明に係る第５の発明は、役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に複数記憶可能な第３の記憶手段（図１に示す承認経路情報ＤＢ１０１４）と、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成手段（図２に示すＣＰＵ２０１）とを有することを特徴とする。
【００１７】
本発明に係る第６の発明は、前記生成手段により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第３の特定手段（図２に示すＣＰＵ２０１）と、前記第３の特定手段により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第３の通知手段（図２に示すＣＰＵ２０１）とを設けたことを特徴とする。
【００１８】
本発明に係る第７の発明は、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段とを有するワークフローサーバと、複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御方法において、前記ワークフローサーバの第１の特定手段が、前記いずれかのクライアントからの承認要求に応じて、前記ワークフローサーバの前記第２の記憶手段に登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定工程（図８のステップＳ２１３〜Ｓ２１６）と、前記ワークフローサーバの第１の選択手段が、前記第１の特定工程で特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択工程（図８のステップＳ２２０，図８のステップＳ２０２〜Ｓ２０４）とを含むことを特徴とする。
【００１９】
本発明に係る第８の発明は、前記ワークフローサーバの第１の通知手段が、前記第１の選択工程により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知工程（図９のステップＳ２２３）を更に含むことを特徴とする。
【００２０】
本発明に係る第９の発明は、前記ワークフローサーバが役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に記憶する第３の記憶手段を設けており、前記ワークフローサーバの生成手段が、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成工程（図７のステップＳ１１４〜Ｓ１１５）を更に含むことを特徴とする。
【００２１】
本発明に係る第１０の発明は、前記ワークフローサーバの第２の特定手段が、前記生成工程により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第２の特定工程（図７のステップＳ１１６〜Ｓ１１７）と、前記ワークフローサーバの第２の通知手段が、前記第２の特定工程により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第２の通知工程（図７のステップＳ１１８）とを更に含むことを特徴とする。
【００２２】
本発明に係る第１１の発明は、所定の通信媒体を介して複数のクライアントと通信可能なワークフローサーバで実行可能な制御プログラムであって、前記ワークフローサーバを、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段と、前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段と、前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段として機能させるためのプログラムであることを特徴とする。
【００２３】
本発明に係る第１２の発明は、第１１の発明に記載された制御プログラムを記録媒体にコンピュータが読み取り可能に記憶させたことを特徴とする。
【００２４】
【発明の実施の形態】
以下、図面を参照して、ワークフローシステムにおける組織変更前後の承認者決定方法について説明する。
【００２５】
〔第１実施形態〕
図１は、本発明の第１実施形態を示すワークフローサーバ及びクライアントを適用可能なワークフローシステム（電子決裁システム）の構成の一例を示すブロック図である。
【００２６】
図において、１０１はワークフローサーバ（電子決裁サーバ（以下、サーバ））で、イーサネット（登録商標）等のネットワーク１０３を介して複数のワークフロークライアント（情報処理装置（以下、クライアント））１０２ａ，１０２ｂ，１０２ｃ，……（以下単に、クライアント１０２）と通信可能である。
【００２７】
サーバ１０１は、人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５を有する。
【００２８】
なお、クライアント１０２は、ユーザが入出力するためのパーソナルコンピュータ（ＰＣ）又はワークステーション等にワークフローを利用するためのアプリケーションまたはＷｅｂ環境を用意したものである。
【００２９】
また、サーバ１０１は、クライアント１０２からのリクエストを受け付け、ワークフローシステムが持つＤＢ１０１０の内容を更新する。
【００３０】
サーバ１０１は、ユーザから伝票を受け付けたこと（申請処理）に応じて、人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４等を用いて、伝票データを生成し、伝票データＤＢ１０１５に格納する。
【００３１】
図２は、図１に示したサーバ１０１の構成を示すブロック図である。
【００３２】
図において、２０１はＣＰＵで、ＲＯＭ２０３のプログラム用ＲＯＭに記憶されたプログラムに基づいてシステムバス２０４に接続された各デバイスを制御し、サーバ１０１全体を統括制御する。
【００３３】
また、このＲＯＭ２０３のフォント用ＲＯＭにはフォントデータ等を記憶し、ＲＯＭ２０３のデータ用ＲＯＭには各種データを記憶する。２０２はＲＡＭで、ＣＰＵ２０１の主メモリ，ワークエリア等として機能する。
【００３４】
２０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）２０９や図示しないポインティングデバイス、例えばマウスからの入力を制御する。２０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。なお、ここでは、表示装置としてＣＲＴを設けているがＬＣＤ等のその他の形式の表示装置であってもよい。
【００３５】
２０７はメモリコントローラ（ＭＣ）で、図１に示した人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５を構成するハードディスク（ＨＤ）２１１とのアクセスを制御する。２０８はネットワークインタフェース（ＮＷＩ／Ｆ）で、ネットワーク１０３との通信を制御する。
【００３６】
以上のような構成により、サーバ１０１はネットワークを介してクライアント１０２と通信して、クライアントの指示に基づいて、上述したＤＢ内の各種データ等の送受信を行う。
【００３７】
また、ＣＰＵ２０１は、ユーザからの指示（ＫＢ２０９又は図示しないマウス等からの指示や図１に示したクライアント１０２からの指示等）に基づいて種々の機能（後述するフローチャートに示す）に対応する処理を実行する。
【００３８】
なお、図に示した、ＫＢ２０９，ＣＲＴ２１０等は必ずしも備えていなくてもよい。
【００３９】
図３は、図１に示したクライアント１０２の構成を示すブロック図である。
【００４０】
図において、３０１はＣＰＵで、ＲＯＭ３０３のプログラム用ＲＯＭに記憶されたプログラムに基づいてシステムバス３０４に接続された各デバイスを制御し、クライアント１０２全体を統括制御する。
【００４１】
また、このＲＯＭ３０３のフォント用ＲＯＭにはフォントデータ等を記憶し、ＲＯＭ３０３のデータ用ＲＯＭには各種データを記憶する。３０２はＲＡＭで、ＣＰＵ３０１の主メモリ，ワークエリア等として機能する。
【００４２】
３０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）３０９や例えばマウス等のポインティングデバイス（ＰＤ）３１２からの入力を制御する。３０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）３１０の表示を制御する。なお、ここでは、表示装置としてＣＲＴを設けているがＬＣＤ等のその他の形式の表示装置であってもよい。
【００４３】
３０７はメモリコントローラ（ＭＣ）で、ハードディスク（ＨＤ）３１１とのアクセスを制御する。３０８はネットワークインタフェース（ＮＷＩ／Ｆ）で、ネットワーク１０３との通信を制御する。
【００４４】
以上のような構成により、クライアント１０２はネットワーク１０３を介してサーバ１０１と通信して、サーバ１０１が管理する人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５等内のデータの取得、閲覧および申請，承認等を行うことができる。
【００４５】
また、ＣＰＵ３０１は、ユーザからの指示（ＫＢ３０９又はＰＤ３１２等からの指示）に基づいてサーバ１０１に対して種々の機能に対応する処理の実行を指示することができる。
【００４６】
さらに、サーバ１０１，クライアント１０２は、図示しないフレキシブルディスクデバイスやＣＤ−ＲＯＭデバイス等を備えるものとする。
【００４７】
図４は、図１に示した人事情報ＤＢ１０１１内のデータ構成の一例を示す図である。
【００４８】
図において、４００は人事情報で、社員番号４０１，氏名４０２，ユーザＩＤ４０３等により構成される。なお、氏名４０２は、ユーザの実氏名に対応する。
【００４９】
また、人事情報ＤＢ１０１１は、人事情報４００をユーザの数だけ含むものである。
【００５０】
図５は、図１に示した伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４内のデータ構成及び関係を示す図である。
【００５１】
図において、６００は伝票情報で、伝票種別６０１，経路情報インデックス６０２，伝票の入力項目定義６０３等から構成される。
【００５２】
ここで、伝票種別６０１は、伝票の種別を示す。経路情報インデックス６０２は、承認経路情報７００内に保持される承認経路ＩＤ７０１に対応するものであり、この経路情報インデックス６０２により、承認経路情報７００のデータを特定する。伝票の入力項目定義６０３は、伝票の内容を示す各種入力項目が定義されている。
【００５３】
ここで、伝票情報ＤＢ１０１３は、伝票情報６００を伝票種別の数だけ含むものである。
【００５４】
７００は承認経路情報で、承認経路ＩＤ７０１，承認経路７０２等から構成される。ここで、承認経路ＩＤ７０１は、各承認経路情報７００固有の値となっている。また、承認経路７０２は、役割（役職）を羅列（順序構造を有する１次元配列（「１」から始まる））した１組のデータであり、例えば、「１：課長，２：部長，３：経理担当，４：経理課長，５：経理部長」等である。
【００５５】
なお、承認経路情報ＤＢ１０１４は、承認経路情報７００を承認経路の数だけ含むものである。
【００５６】
図６は、図１に示した伝票データＤＢ１０１５，組織情報ＤＢ１０１２内のデータ構成及び関係を示す図である。
【００５７】
図において、８００は伝票データで、伝票番号８０１，申請日８０２，申請者８０３，所属部署８０４，伝票名称８０５，承認経路８０６，伝票の入力データ８０７，コメント８０８等から構成される。
【００５８】
ここで、伝票番号８０１は、伝票の申請毎にサーバ１０１により付与されるシリアルナンバである。申請日８０２は、後述する伝票の申請処理を行った日付である。申請者８０３は、伝票の申請処理を行ったユーザの氏名である。伝票名称８０５は、伝票の申請処理時にユーザにより任意に入力可能なものである。
【００５９】
承認経路８０６は、サーバ１０１により、伝票の申請処理時に伝票の種類に応じて特定される承認経路であり、図５に示した承認経路７０２に基づいて生成される。この承認経路８０６は、役割８０６ａ，承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃから構成される。承認ユーザ名（ＩＤ）８０６ｂは、承認又は否認を行うユーザ名又はＩＤが格納される。承認結果８０６ｃは、デフォルトとして「０」が格納され、承認時には「１」，否認時には「−１」が格納される。この図に示す例では、課長により承認され、部長により否認された状態を示している。
【００６０】
８０７は伝票入力データで、伝票の申請処理時に申請者により入力される伝票の内容に対応する。８０８はコメントで、後述する承認処理時（承認時又は否認時）に、承認者により任意に入力可能である。
【００６１】
ここで、伝票データＤＢ１０１５は、伝票データ８００を申請された伝票データの数だけ含むものである。
【００６２】
５００は組織情報で、適用日５０１，組織データ５０２等から構成される。ここで、適用日５０１は、組織データ５０２を適用する日付けデータに対応する。また、組織データ５０２は、組織名（部，課の名称等），組織構成（部課のメンバの氏名等），役割（役職）の名称（社長，営業部長，経理課長等），役割に対応するユーザの氏名等で構成される。
【００６３】
このように、組織情報５００に、適用日５０１を保持し、適用日の異なる複数の組織情報を組織情報ＤＢ１０１２に保持することができる。これにより、組織変更が行われても、過去の組織情報をいつでも参照することができる。また、伝票データ８００を作成した日付（申請日８０２）での組織データと、承認する時点での組織データをそれぞれ参照することにより、次に承認する予定の候補者を複数抽出することができる。例えば、申請日での営業課長と承認時での営業課長が異なる場合には、２人を次に承認する予定の候補者として抽出し、選択可能である。
【００６４】
以下、図７〜図９のフローチャートを参照して、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける伝票の申請処理及び伝票の承認処理について説明する。
【００６５】
図７は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。なお、図７（ａ）はクライアント側の申請処理手順に対応し、図３に示したＣＰＵ３０１によりＨＤ３１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ１０１〜Ｓ１０５は各ステップを示す。
【００６６】
さらに、図７（ｂ）はサーバ側の申請処理手順に対応し、図２に示したＣＰＵ２０１によりＨＤ２１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ１１１〜Ｓ１１８は各ステップを示す。
【００６７】
まず、図７（ａ）を用いて、クライアント側の申請処理について説明する。
【００６８】
伝票の申請（起票）を行なうユーザ（申請者）が、クライアント１０２から自己を特定するためのログイン処理を行ない、申請（起票）する伝票種類の指定を行なうと、ステップＳ１０１において、伝票の種類と申請処理要求をサーバ１０１に対して送信する。
【００６９】
次に、サーバ１０１から指定した伝票の申請画面を受信すると、ステップＳ１０２において、受信した申請画面をＣＲＴ３１０に表示する。
【００７０】
次に、申請者より、図示しない申請画面上において、伝票毎に定められた事項が入力され、必要な情報の入力完了後、申請実行が指示されると（Ｓ１０３）、ステップＳ１０４において、入力内容をサーバ１０１に送信し、ステップＳ１０５において、申請画面を閉じ、処理を終了する。なお、図示していないが、ステップＳ１０３で、図示しないキャンセルキー等が押下されキャンセル指示を検知した場合、サーバ１０１にキャンセル通知を送信し、そのまま処理を終了するものとする。また、サーバ１０１からの正常終了通知の有無を判定し、正常終了通知を受信した場合にはそのまま処理を終了し、所定時間内に申請終了通知を受信しない場合又はエラー通知を受信した場合には、エラー処理を行うように構成してもよい。
【００７１】
次に、図７（ｂ）を用いて、サーバ側の申請処理について説明する。
【００７２】
まず、クライアント１０２より、申請者がログインすると、申請者のユーザＩＤに基づいて人事情報を読み出し、さらに、クライアント１０２より、伝票の種類と申請処理要求を受信すると、ステップＳ１１１において、該受信した伝票の種類に対応する伝票情報を読み出し、ステップＳ１１２において、申請画面を作成し、ステップＳ１１３において、作成した申請画面を申請画面の要求を行ったクライアント１０２に送信する。
【００７３】
次に、クライアント１０２から申請画面における入力内容（申請者が入力した情報）を受信すると、ステップＳ１１４において、ステップＳ１１１で読み出した伝票情報内の経路情報インデックスに基づいて伝票毎に定められた承認経路情報を読み出し、該読み出した承認経路情報，受信した入力内容，申請日（現在日），申請者の氏名等に基づいて伝票データを作成する（Ｓ１１５）。
【００７４】
次に、ステップＳ１１６において、申請日における組織情報を読み出し、ステップＳ１１７において、申請者が所属する部署に基づいて伝票データを次に承認処理する役割（役職）に相当する実ユーザを特定し、ステップＳ１１８において、そのユーザ（次承認者）に承認処理が必要な伝票データが到来した旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。なお、図示していないが、（クライアント１０２側のユーザによりキャンセルキー等が押下され）クライアント１０２から送信されるキャンセル通知を受信した場合には、そのまま処理を終了するものとする。また、ステップＳ１１１〜１１８の処理が正常終了した場合には、クライアント１０２に対して伝票の申請終了通知を送信した後、正常に終了しなかった場合には、クライアント１０２に対してエラー通知を送信するように構成してもよい。
【００７５】
なお、図７のフローチャートでは、サーバ１０１側で申請画面を作成してクライアント１０２に送信し、クライアント１０２側で表示させる構成について説明したが、サーバ１０１側から申請画面の表示に必要な情報をクライアント１０２に送信し、クライアント１０２側のアプリケーション等でサーバ１０１より受信した情報に基づく申請画面を作成表示させるように構成してもよい。
【００７６】
図８，図９は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。なお、図８（ａ）はクライアント側の承認処理手順に対応し、図３に示したＣＰＵ３０１によりＨＤ３１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ２０１〜Ｓ２０５は各ステップを示す。
【００７７】
さらに、図８（ｂ），図９はサーバ側の承認処理手順に対応し、図２に示したＣＰＵ２０１によりＨＤ２１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ２１１〜Ｓ２２５は各ステップを示す。
【００７８】
まず、図８（ａ）を用いて、クライアント側の承認処理について説明する。
【００７９】
承認を行なうユーザ（図７のステップＳ１１８でサーバ１０１より送信された通知を受け取った次承認者）が、クライアント１０２から自己を特定するためのログイン処理を行ない、承認する伝票データの指定を行なうと、ステップＳ２０１において、伝票データ指定（伝票番号８０１等）と承認処理要求をサーバ１０１に対して送信する。
【００８０】
次に、サーバ１０１から指定した伝票データの承認画面を受信すると、ステップＳ２０２において、受信した承認画面（後述する図１０）をＣＲＴ３１０に表示する。
【００８１】
次に、承認者より、図１０に示す承認画面上において、次承認予定者，否認時の戻り先等の指示及びコメントの入力がなされ（必要な場合のみ）、承認（図１０に示す承認ボタン１００５）又は否認（図１０に示す否認ボタン１００４）が指示されると（Ｓ２０３）、ステップＳ２０４において、承認又は否認の指示，次承認者，否認時の戻り先のデータ，コメント等をサーバ１０１に送信し、ステップＳ２０５において、承認画面を閉じ、処理を終了する。なお、図示していないが、ステップＳ２０３で、図１０に示すキャンセルキー１００６が押下されキャンセル指示を検知した場合、サーバ１０１にキャンセル通知を送信し、そのまま処理を終了するものとする。また、サーバ１０１からの正常終了通知の有無を判定し、正常終了通知を受信した場合にはそのまま処理を終了し、所定時間内に申請終了通知を受信しない場合又はエラー通知を受信した場合には、エラー処理を行うように構成してもよい。また、このフローチャートには、図示しないが、図１０に示すキャンセルボタン１００６が指示された場合には、キャンセルされた旨をサーバ１０１に送信し、そのまま処理を終了するものとする。
【００８２】
次に、図８（ｂ）及び図９を用いて、サーバ側の承認処理について説明する。
【００８３】
まず、クライアント１０２より、承認者がログインすると、承認者のユーザＩＤに基づいて人事情報を読み出し、さらに、クライアント１０２より、伝票データの指定（伝票番号８０１等）と承認処理要求を受信すると、ステップＳ２１１において、該受信した伝票データの指定に対応する伝票データ８００を読み出し、ステップＳ２１２において、承認画面を作成する（後述する図１０に示す１００２ａ，１００２ｂ以外を作成）。
【００８４】
次に、ステップＳ２１３において、申請日８０２における組織情報（Ａ）を読み出し、申請者が所属する部署（所属部署８０４）に基づいて、承認経路８０６において、伝票データを次に承認処理する役割（役職）に相当する実ユーザと、否認した場合の戻り先となる役割（役職）に相当する実ユーザを特定する。次に、現在日における組織情報（Ｂ）を読み出し、申請者が所属する部署（所属部署８０４）に基づいて、承認経路８０６において、伝票データを次に承認処理する役割（役職）に相当する実ユーザ（所属／氏名等表示）と、否認した場合の戻り先となる役割（役職）に相当する実ユーザ（所属／氏名等表示）を特定する。
【００８５】
次に、ステップＳ２１４において、次の承認者が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであるか否かを判定し、同じでない（異なる）と判断した場合には、ステップＳ２１６において、該組織情報（Ａ）における次の承認者の候補と組織情報（Ｂ）における次の承認者の候補を承認画面上の次の承認予定者表示欄１００２ａに選択可能に付加し、ステップＳ２１７に進む。
【００８６】
一方、ステップＳ２１４で、次の承認者が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであると判断した場合には、該次の承認者を承認画面上の次の承認予定者表示欄１００２ａに付加し（１人のみのため選択不可能に付加）、ステップＳ２１７に進む。なお、ここでは図示していないが、承認経路８０６において次の承認者がいない場合には、そのままステップＳ２１７に進む。
【００８７】
次に、ステップＳ２１７において、否認時の戻り先が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであるか否かを判定し、同じでない（異なる）と判断した場合には、ステップＳ２１９において、該組織情報（Ａ）における否認時の戻り先の候補と組織情報（Ｂ）における否認時の戻り先の候補とを承認画面上の否認時の戻り先表示欄１００２ｂに選択可能に付加し、ステップＳ２２０に進む。
【００８８】
一方、ステップＳ２１７で、否認時の戻り先が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであると判断した場合には、ステップＳ２１８において、該否認時の戻り先を承認画面上の否認時の戻り先表示欄１００２ｂに付加し（１人のみのため選択不可能に付加）、ステップＳ２２０に進む。なお、ここでは図示していないが、承認経路８０６において、否認時の戻り先がない場合は、申請者を否認時の戻り先表示欄１００２ｂに付加し、ステップＳ２２０に進む。
【００８９】
次に、ステップＳ２２０において、作成した承認画面を承認画面の要求を行ったクライアント１０２に送信する。
【００９０】
次に、クライアント１０２から承認画面における承認又は否認の指示，次承認者，否認時の戻り先のデータ，コメント等を受信すると、ステップＳ２２１において、受信した指示が承認であるか否かを判定し、承認であると判断した場合には、ステップＳ２２２において、現承認者の情報と承認結果（承認「１」）を伝票データ内の承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃにそれぞれ格納して伝票データを伝票データＤＢ１０１５に保存（更新）し、ステップＳ２２３において、受信した次承認者に承認待ちデータがある旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。なお、ここでは図示していないが、次承認者がいない場合には、申請者に申請した伝票データが承認された旨（伝票番号，伝票名称も含む）の通知を行い、該伝票データを図示しない承認済みＤＢに移動させるものとする。
【００９１】
一方、ステップＳ２２１で、受信した指示が承認であると判断した場合には、ステップＳ２２４において、現承認者の情報と承認結果（否認「−１」）を伝票データ内の承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃにそれぞれ格納して伝票データを伝票データＤＢ１０１５に保存（更新）し、ステップＳ２２５において、否認時の戻り先に否認された戻りデータがある旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。
【００９２】
なお、図示していないが、（クライアント１０２側のユーザにより図１０に示すキャンセルキー１００６が押下され）クライアント１０２から送信されるキャンセル通知を受信した場合には、そのまま処理を終了するものとする。また、ステップＳ２１１〜２２５の処理が正常終了した場合には、クライアント１０２に対して伝票の申請終了通知を送信し、正常に終了しなかった場合には、クライアント１０２に対してエラー通知を送信するように構成してもよい。
【００９３】
また、このフローチャートでは図示しないが、クライアント１０２からキャンセルされた旨の通知が送信された場合には、伝票データＤＢ１０１５を更新することなく、そのまま処理を終了するものとする。
【００９４】
なお、図８，図９のフローチャートでは、サーバ１０１側で、該認証画面にサーバ１０１側で特定した複数の「次承認予定者」と複数の「否認時の戻り先」と選択可能に付加した認証画面を生成してクライアント１０２に送信し、クライアント１０２側で表示させる構成について説明したが、サーバ１０１側で特定した複数の「次承認予定者」と複数の「否認時の戻り先」の情報をクライアント１０２に送信し、クライアント１０２側のアプリケーション等でサーバ１０１より受信した情報に基づいて複数の「次承認予定者」と複数の「否認時の戻り先」とを選択可能に付加した認証画面を作成表示させるように構成してもよい。
【００９５】
図１０は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける承認面の一例を示す模式図であり、承認処理時にクライアント１０２のＣＲＴ３１０に表示される。
【００９６】
図において、１００１は申請者データ表示エリアで、伝票データ８００内の申請日８０２，申請者８０３，所属部署８０４等が表示される。
【００９７】
１００２は次承認者及び否認時の戻り先選択エリアで、次の承認予定者の所属／氏名等を表示する次の承認予定者表示欄１００２ａ，否認時の戻り先の所属／氏名等を表示する否認時の戻り先表示欄１００２ｂから構成される。
【００９８】
申請日での組織情報から、申請者が所属する部署を基に、伝票データを自分の次に承認処理する役割（役職）に相当する実ユーザ（Ｎｅｘｔ−１）と、否認した場合の戻り先となる実ユーザ（Ｂａｃｋ−１）を特定し、さらに、承認処理を行なっている現在日での組織情報から、申請者が所属する部署を基に、伝票データを自分の次に承認処理する役割（役職）に相当する実ユーザ（Ｎｅｘｔ−２）と、否認した場合の戻り先となる実ユーザ（Ｂａｃｋ−２）を特定し、次の承認予定者表示欄１００２ａには、次の承認候補者であるＮｅｘｔ−１とＮｅｘｔ−２をＰＤ３１２等により選択できるユーザＩ／Ｆにて表示する。なお、Ｎｅｘｔ−１とＮｅｘｔ−２が同一人物である場合には選択の必要がないため、単に次の承認予定実ユーザを表示するのみとなる。また、否認時の戻り先表示欄１００２ｂには、戻り先候補者であるＢａｃｋ−１とＢａｃｋ−２をＰＤ３１２等により選択できるユーザＩ／Ｆにて表示する。なお、Ｂａｃｋ−１とＢａｃｋ−２が同一人物である場合には選択の必要がないため、単に戻り先実ユーザを表示するのみとなる。
【００９９】
１００３は伝票内容表示欄で、伝票内容としての伝票名称８０５，伝票の入力データ８０７が表示されるとともに、前の承認者又は否認者等により入力されたコメント８０８が入力者の部署／氏名とともに表示される。１００７はコメント入力欄で、新規に任意のコメントをＫＢ３０９等で入力することができる。
【０１００】
１００４は否認ボタンで、伝票内容を否認する場合にＰＤ３１２により指示する。１００５は承認ボタンで、伝票内容を承認する場合にＰＤ３１２により指示する。１００６はキャンセルボタンで、承認処理を中止する場合にＰＤ３１２により指示する。また、キャンセル通知がサーバ１０１に送信される。
【０１０１】
以上説明したように、現承認者は、クライアント１０２の画面（ＣＲＴ３１０）に表示された承認画面により、伝票の内容を確認し、承認する場合であれば、その伝票の決裁に相応しい次の承認実ユーザを次の承認予定者表示欄１００２ａで選択し、承認ボタン１００５を指示する。また、否認する場合であれば、その伝票の戻り先に相応しい実ユーザを否認時の戻り先表示欄１００２ｂにより選択し、否認ボタン１００４を指示する。
【０１０２】
これらの現承認者からの指示に従い、サーバ１０１は、承認または否認の結果を伝票データに書き出し、次の処理担当となる承認実ユーザまたは戻り先実ユーザに承認処理または否認処理が必要な伝票データの到来を通知する。
【０１０３】
図１１は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける承認者候補の遷移の一例を示す図である。
【０１０４】
図に示すように、伝票データの申請後に組織変更があった場合でも、各承認者は、伝票の性質等を考慮して、組織変更前の承認予定者又は組織変更後の承認予定者のいずれかを選択して伝票を渡すことができる。
【０１０５】
以上に示すように、本実施形態のワークフローシステムの組織情報は、構成要素に「適用日」を含むことにより、適用日の異なる複数の組織情報を持つことができ、組織変更前の組織情報をワークフローシステムに残すことができる。
【０１０６】
また、本実施形態のワークフローシステムの伝票情報は、構成要素に「承認経路情報を特定するインデックス」を持ち、伝票種に応じた承認経路情報（役割（役職）の羅列によって順路を定義される）を関連付けておくものである。
【０１０７】
さらに、本実施形態のワークフローシステムの伝票データは、構成要素に「申請日」を持つことにより、申請した時点の日付を保持しておくことができる。また、この「申請日」と上記「適用日付組織情報」により、申請時点での組織情報を特定することができ、申請者の所属に応じた「次承認者」を実ユーザ名で特定することができる。
【０１０８】
また、本実施形態のワークフローシステムでは、承認画面に、承認する場合の「次承認実ユーザ名」と、否認する場合の「戻り先実ユーザ名」を表示し、その時点（承認画面表示時点）の組織情報による「次承認実ユーザ」（「戻り先実ユーザ」）と、申請日付での組織情報による「次承認実ユーザ」（「戻り先実ユーザ」）が異なる場合には、それらの候補者の中から「次承認実ユーザ」（「戻り先実ユーザ名」）を選択できるようにする。
【０１０９】
そして、承認画面の操作者は、「次承認実ユーザ名」または「戻り先実ユーザ名」を必要に応じて変更し、承認／否認を行い、承認又は否認された伝票データは、選択された次承認者／戻り先の承認待ちデータとなるものとする。
【０１１０】
以上の構成により、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と現時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、組織変更時の伝票データの取り扱いに自由度が増し、現実に即した対応が可能となる。
【０１１１】
また、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができる。
【０１１２】
さらに、組織情報内に適用日を含むことにより、システムの管理者は、組織変更に先立って新しい情報を事前登録しておくことが可能となる。
【０１１３】
〔第２実施形態〕
上記第１実施形態では、申請時点での組織情報と現時点（承認画面表示時点）での組織情報のいずれかで適切な承認者を伝票データ毎に選択する構成について説明したが、申請時点から現時点（承認画面表示時点）までに適用された全ての組織情報のいずれかで適切な承認者を伝票データ毎に選択可能に構成してもよい。
【０１１４】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組み合わせを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【０１１５】
以下、図１２，図１３に示すメモリマップを参照して本発明に係るワークフローサーバ及びクライアントを適用可能なワークフローシステムで読み出し可能なデータ処理プログラムの構成について説明する。
【０１１６】
図１２は、本発明に係るクライアント（クライアント１０２）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１１７】
図１３は、本発明に係るワークフローサーバ（サーバ１０１）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１１８】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１１９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１２０】
本実施形態における図７，図８，図９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１２１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１２２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１２３】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１２４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１２７】
さらに、本発明を達成するためのソフトウエアによって表されるプログラムをネットワーク上のデータベースから通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１２８】
【発明の効果】
以上説明したように、本発明によれば、クライアントからの承認要求に応じて、ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させるので、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる等の効果を奏する。
【図面の簡単な説明】
【図１】本発明の第１実施形態を示す電子決裁サーバ及び情報処理装置を適用可能なワークフローシステム（電子決裁システム）の構成の一例を示すブロック図である。
【図２】図１に示したサーバの構成を示すブロック図である。
【図３】図１に示したクライアントの構成を示すブロック図である。
【図４】図１に示した人事情報ＤＢ内のデータ構成の一例を示す図である。
【図５】図１に示した伝票情報ＤＢ，承認経路情報ＤＢ内のデータ構成及び関係を示す図である。
【図６】図１に示した伝票データＤＢ，組織情報ＤＢ内のデータ構成及び関係を示す図である。
【図７】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図８】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図９】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１０】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける承認面の一例を示す模式図である。
【図１１】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける承認者候補の遷移の一例を示す図である。
【図１２】本発明に係る情報処理装置（クライアント）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【図１３】本発明に係る情報処理装置（サーバ）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【符号の説明】
１０１ ワークフローサーバ
１０２ａ〜１０２ｃ ワークフロークライアント
１０３ ネットワーク
１０１１ 人事情報ＤＢ
１０１２ 組織情報ＤＢ
１０１３ 伝票情報ＤＢ
１０１４ 承認経路情報ＤＢ
１０１５ 伝票データＤＢ
【発明の属する技術分野】
本発明は、ワークフローサーバと複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御に関するものである。
【０００２】
【従来の技術】
従来の一般的なワークフローシステムでは、承認が必要な伝票の種類や伝票の申請者の情報及び組織情報等に基づいて承認すべきユーザが決定される構成となっていた。
【０００３】
また、このような従来のワークフローシステムでは、ワークフロー完了前に組織変更が発生してフローする承認者が異動となってしまった場合、組織変更前の組織情報に基づいて承認者を決定したり、組織変更後の組織情報に基づいて承認者を決定したりといったように、いずれもフローする承認者が一意に決定され、組織変更に対処していた。
【０００４】
【発明が解決しようとする課題】
しかしながら、「旅費・立替金清算」や「報告書」といった過去の事象を清算する伝票においては、変更後の組織情報から決定された承認者では信憑性の確認が難しく組織変更前の組織情報から決定された承認者に決裁されるのが望ましいと考えられるが、逆に、「購入要求」や「開催通知」といった今後の事象を届け出る伝票については、組織変更後の組織情報から決定された承認者に決裁されるのが望ましいと考えられる。しかしながら、上記従来のワークフローシステムでは、システムによりいずれか一意に決定される承認者にフローされるため、伝票の種類やフロー完了前に発生する各種事情に対応して、伝票を手渡しする場合のよういに、柔軟に承認者を変更（決定）することができないという問題点があった。
【０００５】
また、組織変更がある度に、組織変更に応じて、管理者等がフローする承認者を書き換えることにより、組織変更に対応するワークフローチャートシステムもあるが、管理者の管理負担が増大してしまうといった問題点があった。
【０００６】
さらに、各承認者が次の承認者を自由に決定するように構成されたワークフローシステムもあるが、フローする承認者に制約がかけられないという問題点があった。
【０００７】
本発明は、上記の問題点を解決するためになされたもので、本発明の目的は、クライアントからの承認要求に応じて、ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させることにより、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる仕組みを提供することである。
【０００８】
【課題を解決するための手段】
本発明に係る第１の発明は、所定の通信媒体を介して複数のクライアント（図１に示すワークフロークライアント１０２ａ，１０２ｂ，１０２ｃ，……）と通信可能なワークフローサーバ（図１に示すワークフローサーバ１０１）において、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段（図１に示す組織情報ＤＢ１０１２）と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段（図１に示す伝票データＤＢ１０１５）と、前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段（図２に示すＣＰＵ２０１が図１０に示す承認画面内の次承認予定者１００２ａを特定）と、前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段（図２に示すＣＰＵ２０１が図１０に示す承認画面を生成しクライアント１０２に送信する）とを有することを特徴とする。
【０００９】
本発明に係る第２の発明は、前記第１の特定手段は、申請日における組織情報より特定される次承認者と前記承認要求時における組織情報より特定される次承認者とが異なる場合には、それぞれを承認時の次承認予定者として特定することを特徴とする。
【００１０】
本発明に係る第３の発明は、前記第１の選択手段は、前記第１の特定手段により複数の次承認予定者が特定されている場合には、クライアントに送信する承認画面（図１０に示す承認画面）上で前記複数の次承認予定者からいずれかを選択させることを特徴とする。
【００１１】
本発明に係る第４の発明は、前記第１の選択手段により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知手段（図２に示すＣＰＵ２０１）を設けたことを特徴とする。
【００１６】
本発明に係る第５の発明は、役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に複数記憶可能な第３の記憶手段（図１に示す承認経路情報ＤＢ１０１４）と、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成手段（図２に示すＣＰＵ２０１）とを有することを特徴とする。
【００１７】
本発明に係る第６の発明は、前記生成手段により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第３の特定手段（図２に示すＣＰＵ２０１）と、前記第３の特定手段により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第３の通知手段（図２に示すＣＰＵ２０１）とを設けたことを特徴とする。
【００１８】
本発明に係る第７の発明は、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段とを有するワークフローサーバと、複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御方法において、前記ワークフローサーバの第１の特定手段が、前記いずれかのクライアントからの承認要求に応じて、前記ワークフローサーバの前記第２の記憶手段に登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定工程（図８のステップＳ２１３〜Ｓ２１６）と、前記ワークフローサーバの第１の選択手段が、前記第１の特定工程で特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択工程（図８のステップＳ２２０，図８のステップＳ２０２〜Ｓ２０４）とを含むことを特徴とする。
【００１９】
本発明に係る第８の発明は、前記ワークフローサーバの第１の通知手段が、前記第１の選択工程により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知工程（図９のステップＳ２２３）を更に含むことを特徴とする。
【００２０】
本発明に係る第９の発明は、前記ワークフローサーバが役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に記憶する第３の記憶手段を設けており、前記ワークフローサーバの生成手段が、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成工程（図７のステップＳ１１４〜Ｓ１１５）を更に含むことを特徴とする。
【００２１】
本発明に係る第１０の発明は、前記ワークフローサーバの第２の特定手段が、前記生成工程により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第２の特定工程（図７のステップＳ１１６〜Ｓ１１７）と、前記ワークフローサーバの第２の通知手段が、前記第２の特定工程により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第２の通知工程（図７のステップＳ１１８）とを更に含むことを特徴とする。
【００２２】
本発明に係る第１１の発明は、所定の通信媒体を介して複数のクライアントと通信可能なワークフローサーバで実行可能な制御プログラムであって、前記ワークフローサーバを、組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段と、前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段と、前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段として機能させるためのプログラムであることを特徴とする。
【００２３】
本発明に係る第１２の発明は、第１１の発明に記載された制御プログラムを記録媒体にコンピュータが読み取り可能に記憶させたことを特徴とする。
【００２４】
【発明の実施の形態】
以下、図面を参照して、ワークフローシステムにおける組織変更前後の承認者決定方法について説明する。
【００２５】
〔第１実施形態〕
図１は、本発明の第１実施形態を示すワークフローサーバ及びクライアントを適用可能なワークフローシステム（電子決裁システム）の構成の一例を示すブロック図である。
【００２６】
図において、１０１はワークフローサーバ（電子決裁サーバ（以下、サーバ））で、イーサネット（登録商標）等のネットワーク１０３を介して複数のワークフロークライアント（情報処理装置（以下、クライアント））１０２ａ，１０２ｂ，１０２ｃ，……（以下単に、クライアント１０２）と通信可能である。
【００２７】
サーバ１０１は、人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５を有する。
【００２８】
なお、クライアント１０２は、ユーザが入出力するためのパーソナルコンピュータ（ＰＣ）又はワークステーション等にワークフローを利用するためのアプリケーションまたはＷｅｂ環境を用意したものである。
【００２９】
また、サーバ１０１は、クライアント１０２からのリクエストを受け付け、ワークフローシステムが持つＤＢ１０１０の内容を更新する。
【００３０】
サーバ１０１は、ユーザから伝票を受け付けたこと（申請処理）に応じて、人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４等を用いて、伝票データを生成し、伝票データＤＢ１０１５に格納する。
【００３１】
図２は、図１に示したサーバ１０１の構成を示すブロック図である。
【００３２】
図において、２０１はＣＰＵで、ＲＯＭ２０３のプログラム用ＲＯＭに記憶されたプログラムに基づいてシステムバス２０４に接続された各デバイスを制御し、サーバ１０１全体を統括制御する。
【００３３】
また、このＲＯＭ２０３のフォント用ＲＯＭにはフォントデータ等を記憶し、ＲＯＭ２０３のデータ用ＲＯＭには各種データを記憶する。２０２はＲＡＭで、ＣＰＵ２０１の主メモリ，ワークエリア等として機能する。
【００３４】
２０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）２０９や図示しないポインティングデバイス、例えばマウスからの入力を制御する。２０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）２１０の表示を制御する。なお、ここでは、表示装置としてＣＲＴを設けているがＬＣＤ等のその他の形式の表示装置であってもよい。
【００３５】
２０７はメモリコントローラ（ＭＣ）で、図１に示した人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５を構成するハードディスク（ＨＤ）２１１とのアクセスを制御する。２０８はネットワークインタフェース（ＮＷＩ／Ｆ）で、ネットワーク１０３との通信を制御する。
【００３６】
以上のような構成により、サーバ１０１はネットワークを介してクライアント１０２と通信して、クライアントの指示に基づいて、上述したＤＢ内の各種データ等の送受信を行う。
【００３７】
また、ＣＰＵ２０１は、ユーザからの指示（ＫＢ２０９又は図示しないマウス等からの指示や図１に示したクライアント１０２からの指示等）に基づいて種々の機能（後述するフローチャートに示す）に対応する処理を実行する。
【００３８】
なお、図に示した、ＫＢ２０９，ＣＲＴ２１０等は必ずしも備えていなくてもよい。
【００３９】
図３は、図１に示したクライアント１０２の構成を示すブロック図である。
【００４０】
図において、３０１はＣＰＵで、ＲＯＭ３０３のプログラム用ＲＯＭに記憶されたプログラムに基づいてシステムバス３０４に接続された各デバイスを制御し、クライアント１０２全体を統括制御する。
【００４１】
また、このＲＯＭ３０３のフォント用ＲＯＭにはフォントデータ等を記憶し、ＲＯＭ３０３のデータ用ＲＯＭには各種データを記憶する。３０２はＲＡＭで、ＣＰＵ３０１の主メモリ，ワークエリア等として機能する。
【００４２】
３０５はキーボードコントローラ（ＫＢＣ）で、キーボード（ＫＢ）３０９や例えばマウス等のポインティングデバイス（ＰＤ）３１２からの入力を制御する。３０６はＣＲＴコントローラ（ＣＲＴＣ）で、ＣＲＴディスプレイ（ＣＲＴ）３１０の表示を制御する。なお、ここでは、表示装置としてＣＲＴを設けているがＬＣＤ等のその他の形式の表示装置であってもよい。
【００４３】
３０７はメモリコントローラ（ＭＣ）で、ハードディスク（ＨＤ）３１１とのアクセスを制御する。３０８はネットワークインタフェース（ＮＷＩ／Ｆ）で、ネットワーク１０３との通信を制御する。
【００４４】
以上のような構成により、クライアント１０２はネットワーク１０３を介してサーバ１０１と通信して、サーバ１０１が管理する人事情報ＤＢ１０１１，組織情報ＤＢ１０１２，伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４，伝票データＤＢ１０１５等内のデータの取得、閲覧および申請，承認等を行うことができる。
【００４５】
また、ＣＰＵ３０１は、ユーザからの指示（ＫＢ３０９又はＰＤ３１２等からの指示）に基づいてサーバ１０１に対して種々の機能に対応する処理の実行を指示することができる。
【００４６】
さらに、サーバ１０１，クライアント１０２は、図示しないフレキシブルディスクデバイスやＣＤ−ＲＯＭデバイス等を備えるものとする。
【００４７】
図４は、図１に示した人事情報ＤＢ１０１１内のデータ構成の一例を示す図である。
【００４８】
図において、４００は人事情報で、社員番号４０１，氏名４０２，ユーザＩＤ４０３等により構成される。なお、氏名４０２は、ユーザの実氏名に対応する。
【００４９】
また、人事情報ＤＢ１０１１は、人事情報４００をユーザの数だけ含むものである。
【００５０】
図５は、図１に示した伝票情報ＤＢ１０１３，承認経路情報ＤＢ１０１４内のデータ構成及び関係を示す図である。
【００５１】
図において、６００は伝票情報で、伝票種別６０１，経路情報インデックス６０２，伝票の入力項目定義６０３等から構成される。
【００５２】
ここで、伝票種別６０１は、伝票の種別を示す。経路情報インデックス６０２は、承認経路情報７００内に保持される承認経路ＩＤ７０１に対応するものであり、この経路情報インデックス６０２により、承認経路情報７００のデータを特定する。伝票の入力項目定義６０３は、伝票の内容を示す各種入力項目が定義されている。
【００５３】
ここで、伝票情報ＤＢ１０１３は、伝票情報６００を伝票種別の数だけ含むものである。
【００５４】
７００は承認経路情報で、承認経路ＩＤ７０１，承認経路７０２等から構成される。ここで、承認経路ＩＤ７０１は、各承認経路情報７００固有の値となっている。また、承認経路７０２は、役割（役職）を羅列（順序構造を有する１次元配列（「１」から始まる））した１組のデータであり、例えば、「１：課長，２：部長，３：経理担当，４：経理課長，５：経理部長」等である。
【００５５】
なお、承認経路情報ＤＢ１０１４は、承認経路情報７００を承認経路の数だけ含むものである。
【００５６】
図６は、図１に示した伝票データＤＢ１０１５，組織情報ＤＢ１０１２内のデータ構成及び関係を示す図である。
【００５７】
図において、８００は伝票データで、伝票番号８０１，申請日８０２，申請者８０３，所属部署８０４，伝票名称８０５，承認経路８０６，伝票の入力データ８０７，コメント８０８等から構成される。
【００５８】
ここで、伝票番号８０１は、伝票の申請毎にサーバ１０１により付与されるシリアルナンバである。申請日８０２は、後述する伝票の申請処理を行った日付である。申請者８０３は、伝票の申請処理を行ったユーザの氏名である。伝票名称８０５は、伝票の申請処理時にユーザにより任意に入力可能なものである。
【００５９】
承認経路８０６は、サーバ１０１により、伝票の申請処理時に伝票の種類に応じて特定される承認経路であり、図５に示した承認経路７０２に基づいて生成される。この承認経路８０６は、役割８０６ａ，承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃから構成される。承認ユーザ名（ＩＤ）８０６ｂは、承認又は否認を行うユーザ名又はＩＤが格納される。承認結果８０６ｃは、デフォルトとして「０」が格納され、承認時には「１」，否認時には「−１」が格納される。この図に示す例では、課長により承認され、部長により否認された状態を示している。
【００６０】
８０７は伝票入力データで、伝票の申請処理時に申請者により入力される伝票の内容に対応する。８０８はコメントで、後述する承認処理時（承認時又は否認時）に、承認者により任意に入力可能である。
【００６１】
ここで、伝票データＤＢ１０１５は、伝票データ８００を申請された伝票データの数だけ含むものである。
【００６２】
５００は組織情報で、適用日５０１，組織データ５０２等から構成される。ここで、適用日５０１は、組織データ５０２を適用する日付けデータに対応する。また、組織データ５０２は、組織名（部，課の名称等），組織構成（部課のメンバの氏名等），役割（役職）の名称（社長，営業部長，経理課長等），役割に対応するユーザの氏名等で構成される。
【００６３】
このように、組織情報５００に、適用日５０１を保持し、適用日の異なる複数の組織情報を組織情報ＤＢ１０１２に保持することができる。これにより、組織変更が行われても、過去の組織情報をいつでも参照することができる。また、伝票データ８００を作成した日付（申請日８０２）での組織データと、承認する時点での組織データをそれぞれ参照することにより、次に承認する予定の候補者を複数抽出することができる。例えば、申請日での営業課長と承認時での営業課長が異なる場合には、２人を次に承認する予定の候補者として抽出し、選択可能である。
【００６４】
以下、図７〜図９のフローチャートを参照して、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける伝票の申請処理及び伝票の承認処理について説明する。
【００６５】
図７は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。なお、図７（ａ）はクライアント側の申請処理手順に対応し、図３に示したＣＰＵ３０１によりＨＤ３１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ１０１〜Ｓ１０５は各ステップを示す。
【００６６】
さらに、図７（ｂ）はサーバ側の申請処理手順に対応し、図２に示したＣＰＵ２０１によりＨＤ２１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ１１１〜Ｓ１１８は各ステップを示す。
【００６７】
まず、図７（ａ）を用いて、クライアント側の申請処理について説明する。
【００６８】
伝票の申請（起票）を行なうユーザ（申請者）が、クライアント１０２から自己を特定するためのログイン処理を行ない、申請（起票）する伝票種類の指定を行なうと、ステップＳ１０１において、伝票の種類と申請処理要求をサーバ１０１に対して送信する。
【００６９】
次に、サーバ１０１から指定した伝票の申請画面を受信すると、ステップＳ１０２において、受信した申請画面をＣＲＴ３１０に表示する。
【００７０】
次に、申請者より、図示しない申請画面上において、伝票毎に定められた事項が入力され、必要な情報の入力完了後、申請実行が指示されると（Ｓ１０３）、ステップＳ１０４において、入力内容をサーバ１０１に送信し、ステップＳ１０５において、申請画面を閉じ、処理を終了する。なお、図示していないが、ステップＳ１０３で、図示しないキャンセルキー等が押下されキャンセル指示を検知した場合、サーバ１０１にキャンセル通知を送信し、そのまま処理を終了するものとする。また、サーバ１０１からの正常終了通知の有無を判定し、正常終了通知を受信した場合にはそのまま処理を終了し、所定時間内に申請終了通知を受信しない場合又はエラー通知を受信した場合には、エラー処理を行うように構成してもよい。
【００７１】
次に、図７（ｂ）を用いて、サーバ側の申請処理について説明する。
【００７２】
まず、クライアント１０２より、申請者がログインすると、申請者のユーザＩＤに基づいて人事情報を読み出し、さらに、クライアント１０２より、伝票の種類と申請処理要求を受信すると、ステップＳ１１１において、該受信した伝票の種類に対応する伝票情報を読み出し、ステップＳ１１２において、申請画面を作成し、ステップＳ１１３において、作成した申請画面を申請画面の要求を行ったクライアント１０２に送信する。
【００７３】
次に、クライアント１０２から申請画面における入力内容（申請者が入力した情報）を受信すると、ステップＳ１１４において、ステップＳ１１１で読み出した伝票情報内の経路情報インデックスに基づいて伝票毎に定められた承認経路情報を読み出し、該読み出した承認経路情報，受信した入力内容，申請日（現在日），申請者の氏名等に基づいて伝票データを作成する（Ｓ１１５）。
【００７４】
次に、ステップＳ１１６において、申請日における組織情報を読み出し、ステップＳ１１７において、申請者が所属する部署に基づいて伝票データを次に承認処理する役割（役職）に相当する実ユーザを特定し、ステップＳ１１８において、そのユーザ（次承認者）に承認処理が必要な伝票データが到来した旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。なお、図示していないが、（クライアント１０２側のユーザによりキャンセルキー等が押下され）クライアント１０２から送信されるキャンセル通知を受信した場合には、そのまま処理を終了するものとする。また、ステップＳ１１１〜１１８の処理が正常終了した場合には、クライアント１０２に対して伝票の申請終了通知を送信した後、正常に終了しなかった場合には、クライアント１０２に対してエラー通知を送信するように構成してもよい。
【００７５】
なお、図７のフローチャートでは、サーバ１０１側で申請画面を作成してクライアント１０２に送信し、クライアント１０２側で表示させる構成について説明したが、サーバ１０１側から申請画面の表示に必要な情報をクライアント１０２に送信し、クライアント１０２側のアプリケーション等でサーバ１０１より受信した情報に基づく申請画面を作成表示させるように構成してもよい。
【００７６】
図８，図９は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。なお、図８（ａ）はクライアント側の承認処理手順に対応し、図３に示したＣＰＵ３０１によりＨＤ３１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ２０１〜Ｓ２０５は各ステップを示す。
【００７７】
さらに、図８（ｂ），図９はサーバ側の承認処理手順に対応し、図２に示したＣＰＵ２０１によりＨＤ２１１又はその他の記録媒体に格納されたプログラムに基づいて実行制御されるものとする。また、Ｓ２１１〜Ｓ２２５は各ステップを示す。
【００７８】
まず、図８（ａ）を用いて、クライアント側の承認処理について説明する。
【００７９】
承認を行なうユーザ（図７のステップＳ１１８でサーバ１０１より送信された通知を受け取った次承認者）が、クライアント１０２から自己を特定するためのログイン処理を行ない、承認する伝票データの指定を行なうと、ステップＳ２０１において、伝票データ指定（伝票番号８０１等）と承認処理要求をサーバ１０１に対して送信する。
【００８０】
次に、サーバ１０１から指定した伝票データの承認画面を受信すると、ステップＳ２０２において、受信した承認画面（後述する図１０）をＣＲＴ３１０に表示する。
【００８１】
次に、承認者より、図１０に示す承認画面上において、次承認予定者，否認時の戻り先等の指示及びコメントの入力がなされ（必要な場合のみ）、承認（図１０に示す承認ボタン１００５）又は否認（図１０に示す否認ボタン１００４）が指示されると（Ｓ２０３）、ステップＳ２０４において、承認又は否認の指示，次承認者，否認時の戻り先のデータ，コメント等をサーバ１０１に送信し、ステップＳ２０５において、承認画面を閉じ、処理を終了する。なお、図示していないが、ステップＳ２０３で、図１０に示すキャンセルキー１００６が押下されキャンセル指示を検知した場合、サーバ１０１にキャンセル通知を送信し、そのまま処理を終了するものとする。また、サーバ１０１からの正常終了通知の有無を判定し、正常終了通知を受信した場合にはそのまま処理を終了し、所定時間内に申請終了通知を受信しない場合又はエラー通知を受信した場合には、エラー処理を行うように構成してもよい。また、このフローチャートには、図示しないが、図１０に示すキャンセルボタン１００６が指示された場合には、キャンセルされた旨をサーバ１０１に送信し、そのまま処理を終了するものとする。
【００８２】
次に、図８（ｂ）及び図９を用いて、サーバ側の承認処理について説明する。
【００８３】
まず、クライアント１０２より、承認者がログインすると、承認者のユーザＩＤに基づいて人事情報を読み出し、さらに、クライアント１０２より、伝票データの指定（伝票番号８０１等）と承認処理要求を受信すると、ステップＳ２１１において、該受信した伝票データの指定に対応する伝票データ８００を読み出し、ステップＳ２１２において、承認画面を作成する（後述する図１０に示す１００２ａ，１００２ｂ以外を作成）。
【００８４】
次に、ステップＳ２１３において、申請日８０２における組織情報（Ａ）を読み出し、申請者が所属する部署（所属部署８０４）に基づいて、承認経路８０６において、伝票データを次に承認処理する役割（役職）に相当する実ユーザと、否認した場合の戻り先となる役割（役職）に相当する実ユーザを特定する。次に、現在日における組織情報（Ｂ）を読み出し、申請者が所属する部署（所属部署８０４）に基づいて、承認経路８０６において、伝票データを次に承認処理する役割（役職）に相当する実ユーザ（所属／氏名等表示）と、否認した場合の戻り先となる役割（役職）に相当する実ユーザ（所属／氏名等表示）を特定する。
【００８５】
次に、ステップＳ２１４において、次の承認者が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであるか否かを判定し、同じでない（異なる）と判断した場合には、ステップＳ２１６において、該組織情報（Ａ）における次の承認者の候補と組織情報（Ｂ）における次の承認者の候補を承認画面上の次の承認予定者表示欄１００２ａに選択可能に付加し、ステップＳ２１７に進む。
【００８６】
一方、ステップＳ２１４で、次の承認者が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであると判断した場合には、該次の承認者を承認画面上の次の承認予定者表示欄１００２ａに付加し（１人のみのため選択不可能に付加）、ステップＳ２１７に進む。なお、ここでは図示していないが、承認経路８０６において次の承認者がいない場合には、そのままステップＳ２１７に進む。
【００８７】
次に、ステップＳ２１７において、否認時の戻り先が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであるか否かを判定し、同じでない（異なる）と判断した場合には、ステップＳ２１９において、該組織情報（Ａ）における否認時の戻り先の候補と組織情報（Ｂ）における否認時の戻り先の候補とを承認画面上の否認時の戻り先表示欄１００２ｂに選択可能に付加し、ステップＳ２２０に進む。
【００８８】
一方、ステップＳ２１７で、否認時の戻り先が申請日８０２における組織情報（Ａ）と現在日における組織情報（Ｂ）とで同じであると判断した場合には、ステップＳ２１８において、該否認時の戻り先を承認画面上の否認時の戻り先表示欄１００２ｂに付加し（１人のみのため選択不可能に付加）、ステップＳ２２０に進む。なお、ここでは図示していないが、承認経路８０６において、否認時の戻り先がない場合は、申請者を否認時の戻り先表示欄１００２ｂに付加し、ステップＳ２２０に進む。
【００８９】
次に、ステップＳ２２０において、作成した承認画面を承認画面の要求を行ったクライアント１０２に送信する。
【００９０】
次に、クライアント１０２から承認画面における承認又は否認の指示，次承認者，否認時の戻り先のデータ，コメント等を受信すると、ステップＳ２２１において、受信した指示が承認であるか否かを判定し、承認であると判断した場合には、ステップＳ２２２において、現承認者の情報と承認結果（承認「１」）を伝票データ内の承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃにそれぞれ格納して伝票データを伝票データＤＢ１０１５に保存（更新）し、ステップＳ２２３において、受信した次承認者に承認待ちデータがある旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。なお、ここでは図示していないが、次承認者がいない場合には、申請者に申請した伝票データが承認された旨（伝票番号，伝票名称も含む）の通知を行い、該伝票データを図示しない承認済みＤＢに移動させるものとする。
【００９１】
一方、ステップＳ２２１で、受信した指示が承認であると判断した場合には、ステップＳ２２４において、現承認者の情報と承認結果（否認「−１」）を伝票データ内の承認ユーザ名（ＩＤ）８０６ｂ，承認結果８０６ｃにそれぞれ格納して伝票データを伝票データＤＢ１０１５に保存（更新）し、ステップＳ２２５において、否認時の戻り先に否認された戻りデータがある旨（伝票番号，伝票名称も含む）を通知し、処理を終了する。
【００９２】
なお、図示していないが、（クライアント１０２側のユーザにより図１０に示すキャンセルキー１００６が押下され）クライアント１０２から送信されるキャンセル通知を受信した場合には、そのまま処理を終了するものとする。また、ステップＳ２１１〜２２５の処理が正常終了した場合には、クライアント１０２に対して伝票の申請終了通知を送信し、正常に終了しなかった場合には、クライアント１０２に対してエラー通知を送信するように構成してもよい。
【００９３】
また、このフローチャートでは図示しないが、クライアント１０２からキャンセルされた旨の通知が送信された場合には、伝票データＤＢ１０１５を更新することなく、そのまま処理を終了するものとする。
【００９４】
なお、図８，図９のフローチャートでは、サーバ１０１側で、該認証画面にサーバ１０１側で特定した複数の「次承認予定者」と複数の「否認時の戻り先」と選択可能に付加した認証画面を生成してクライアント１０２に送信し、クライアント１０２側で表示させる構成について説明したが、サーバ１０１側で特定した複数の「次承認予定者」と複数の「否認時の戻り先」の情報をクライアント１０２に送信し、クライアント１０２側のアプリケーション等でサーバ１０１より受信した情報に基づいて複数の「次承認予定者」と複数の「否認時の戻り先」とを選択可能に付加した認証画面を作成表示させるように構成してもよい。
【００９５】
図１０は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける承認面の一例を示す模式図であり、承認処理時にクライアント１０２のＣＲＴ３１０に表示される。
【００９６】
図において、１００１は申請者データ表示エリアで、伝票データ８００内の申請日８０２，申請者８０３，所属部署８０４等が表示される。
【００９７】
１００２は次承認者及び否認時の戻り先選択エリアで、次の承認予定者の所属／氏名等を表示する次の承認予定者表示欄１００２ａ，否認時の戻り先の所属／氏名等を表示する否認時の戻り先表示欄１００２ｂから構成される。
【００９８】
申請日での組織情報から、申請者が所属する部署を基に、伝票データを自分の次に承認処理する役割（役職）に相当する実ユーザ（Ｎｅｘｔ−１）と、否認した場合の戻り先となる実ユーザ（Ｂａｃｋ−１）を特定し、さらに、承認処理を行なっている現在日での組織情報から、申請者が所属する部署を基に、伝票データを自分の次に承認処理する役割（役職）に相当する実ユーザ（Ｎｅｘｔ−２）と、否認した場合の戻り先となる実ユーザ（Ｂａｃｋ−２）を特定し、次の承認予定者表示欄１００２ａには、次の承認候補者であるＮｅｘｔ−１とＮｅｘｔ−２をＰＤ３１２等により選択できるユーザＩ／Ｆにて表示する。なお、Ｎｅｘｔ−１とＮｅｘｔ−２が同一人物である場合には選択の必要がないため、単に次の承認予定実ユーザを表示するのみとなる。また、否認時の戻り先表示欄１００２ｂには、戻り先候補者であるＢａｃｋ−１とＢａｃｋ−２をＰＤ３１２等により選択できるユーザＩ／Ｆにて表示する。なお、Ｂａｃｋ−１とＢａｃｋ−２が同一人物である場合には選択の必要がないため、単に戻り先実ユーザを表示するのみとなる。
【００９９】
１００３は伝票内容表示欄で、伝票内容としての伝票名称８０５，伝票の入力データ８０７が表示されるとともに、前の承認者又は否認者等により入力されたコメント８０８が入力者の部署／氏名とともに表示される。１００７はコメント入力欄で、新規に任意のコメントをＫＢ３０９等で入力することができる。
【０１００】
１００４は否認ボタンで、伝票内容を否認する場合にＰＤ３１２により指示する。１００５は承認ボタンで、伝票内容を承認する場合にＰＤ３１２により指示する。１００６はキャンセルボタンで、承認処理を中止する場合にＰＤ３１２により指示する。また、キャンセル通知がサーバ１０１に送信される。
【０１０１】
以上説明したように、現承認者は、クライアント１０２の画面（ＣＲＴ３１０）に表示された承認画面により、伝票の内容を確認し、承認する場合であれば、その伝票の決裁に相応しい次の承認実ユーザを次の承認予定者表示欄１００２ａで選択し、承認ボタン１００５を指示する。また、否認する場合であれば、その伝票の戻り先に相応しい実ユーザを否認時の戻り先表示欄１００２ｂにより選択し、否認ボタン１００４を指示する。
【０１０２】
これらの現承認者からの指示に従い、サーバ１０１は、承認または否認の結果を伝票データに書き出し、次の処理担当となる承認実ユーザまたは戻り先実ユーザに承認処理または否認処理が必要な伝票データの到来を通知する。
【０１０３】
図１１は、本発明のワークフローサーバ及びクライアントを適用可能なワークフローシステムにおける承認者候補の遷移の一例を示す図である。
【０１０４】
図に示すように、伝票データの申請後に組織変更があった場合でも、各承認者は、伝票の性質等を考慮して、組織変更前の承認予定者又は組織変更後の承認予定者のいずれかを選択して伝票を渡すことができる。
【０１０５】
以上に示すように、本実施形態のワークフローシステムの組織情報は、構成要素に「適用日」を含むことにより、適用日の異なる複数の組織情報を持つことができ、組織変更前の組織情報をワークフローシステムに残すことができる。
【０１０６】
また、本実施形態のワークフローシステムの伝票情報は、構成要素に「承認経路情報を特定するインデックス」を持ち、伝票種に応じた承認経路情報（役割（役職）の羅列によって順路を定義される）を関連付けておくものである。
【０１０７】
さらに、本実施形態のワークフローシステムの伝票データは、構成要素に「申請日」を持つことにより、申請した時点の日付を保持しておくことができる。また、この「申請日」と上記「適用日付組織情報」により、申請時点での組織情報を特定することができ、申請者の所属に応じた「次承認者」を実ユーザ名で特定することができる。
【０１０８】
また、本実施形態のワークフローシステムでは、承認画面に、承認する場合の「次承認実ユーザ名」と、否認する場合の「戻り先実ユーザ名」を表示し、その時点（承認画面表示時点）の組織情報による「次承認実ユーザ」（「戻り先実ユーザ」）と、申請日付での組織情報による「次承認実ユーザ」（「戻り先実ユーザ」）が異なる場合には、それらの候補者の中から「次承認実ユーザ」（「戻り先実ユーザ名」）を選択できるようにする。
【０１０９】
そして、承認画面の操作者は、「次承認実ユーザ名」または「戻り先実ユーザ名」を必要に応じて変更し、承認／否認を行い、承認又は否認された伝票データは、選択された次承認者／戻り先の承認待ちデータとなるものとする。
【０１１０】
以上の構成により、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と現時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、組織変更時の伝票データの取り扱いに自由度が増し、現実に即した対応が可能となる。
【０１１１】
また、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができる。
【０１１２】
さらに、組織情報内に適用日を含むことにより、システムの管理者は、組織変更に先立って新しい情報を事前登録しておくことが可能となる。
【０１１３】
〔第２実施形態〕
上記第１実施形態では、申請時点での組織情報と現時点（承認画面表示時点）での組織情報のいずれかで適切な承認者を伝票データ毎に選択する構成について説明したが、申請時点から現時点（承認画面表示時点）までに適用された全ての組織情報のいずれかで適切な承認者を伝票データ毎に選択可能に構成してもよい。
【０１１４】
本発明は上記実施形態に限定されるものではなく、本発明の趣旨に基づき種々の変形（各実施形態の有機的な組み合わせを含む）が可能であり、それらを本発明の範囲から排除するものではない。
【０１１５】
以下、図１２，図１３に示すメモリマップを参照して本発明に係るワークフローサーバ及びクライアントを適用可能なワークフローシステムで読み出し可能なデータ処理プログラムの構成について説明する。
【０１１６】
図１２は、本発明に係るクライアント（クライアント１０２）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１１７】
図１３は、本発明に係るワークフローサーバ（サーバ１０１）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【０１１８】
なお、特に図示しないが、記録媒体に記憶されるプログラム群を管理する情報、例えばバージョン情報，作成者等も記憶され、かつ、プログラム読み出し側のＯＳ等に依存する情報、例えばプログラムを識別表示するアイコン等も記憶される場合もある。
【０１１９】
さらに、各種プログラムに従属するデータも上記ディレクトリに管理されている。また、インストールするプログラムやデータが圧縮されている場合に、解凍するプログラム等も記憶される場合もある。
【０１２０】
本実施形態における図７，図８，図９に示す機能が外部からインストールされるプログラムによって、ホストコンピュータにより遂行されていてもよい。そして、その場合、ＣＤ−ＲＯＭやフラッシュメモリやＦＤ等の記録媒体により、あるいはネットワークを介して外部の記録媒体から、プログラムを含む情報群を出力装置に供給される場合でも本発明は適用されるものである。
【０１２１】
以上のように、前述した実施形態の機能を実現するソフトウエアのプログラムコードを記録した記録媒体を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記録媒体に格納されたプログラムコードを読出し実行することによっても、本発明の目的が達成されることは言うまでもない。
【０１２２】
この場合、記録媒体から読み出されたプログラムコード自体が本発明の新規な機能を実現することになり、そのプログラムコードを記憶した記録媒体は本発明を構成することになる。
【０１２３】
プログラムコードを供給するための記録媒体としては、例えば、フレキシブルディスク，ハードディスク，光ディスク，光磁気ディスク，ＣＤ−ＲＯＭ，ＣＤ−Ｒ，ＤＶＤ−ＲＯＭ，磁気テープ，不揮発性のメモリカード，ＲＯＭ，ＥＥＰＲＯＭ，シリコンディスク等を用いることができる。
【０１２４】
また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているＯＳ（オペレーティングシステム）等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２５】
さらに、記録媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張ボードやコンピュータに接続された機能拡張ユニットに備わるメモリに書き込まれた後、そのプログラムコードの指示に基づき、その機能拡張ボードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２６】
また、本発明は、複数の機器から構成されるシステムに適用しても、１つの機器からなる装置に適用してもよい。また、本発明は、システムあるいは装置にプログラムを供給することによって達成される場合にも適応できることは言うまでもない。この場合、本発明を達成するためのソフトウエアによって表されるプログラムを格納した記録媒体を該システムあるいは装置に読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１２７】
さらに、本発明を達成するためのソフトウエアによって表されるプログラムをネットワーク上のデータベースから通信プログラムによりダウンロードして読み出すことによって、そのシステムあるいは装置が、本発明の効果を享受することが可能となる。
【０１２８】
【発明の効果】
以上説明したように、本発明によれば、クライアントからの承認要求に応じて、ワークフローサーバに登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定し、該特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させるので、伝票データの申請が行われた後に組織変更があった場合でも、申請時点での組織と伝票申請時点での組織のいずれかで適切な承認者を伝票データ毎に選択でき、管理者の負担を増大することなく、組織変更時の伝票データの取り扱いに自由度を増し、現実に即した対応を可能にするとともに、システム上で制約された範囲で承認者を決定するため、ユーザが無秩序に承認経路を変更してしまうことを防止することができ、さらに、システムの管理者は、実際の組織変更に先立って新しい組織情報を事前登録しておくことができる等の効果を奏する。
【図面の簡単な説明】
【図１】本発明の第１実施形態を示す電子決裁サーバ及び情報処理装置を適用可能なワークフローシステム（電子決裁システム）の構成の一例を示すブロック図である。
【図２】図１に示したサーバの構成を示すブロック図である。
【図３】図１に示したクライアントの構成を示すブロック図である。
【図４】図１に示した人事情報ＤＢ内のデータ構成の一例を示す図である。
【図５】図１に示した伝票情報ＤＢ，承認経路情報ＤＢ内のデータ構成及び関係を示す図である。
【図６】図１に示した伝票データＤＢ，組織情報ＤＢ内のデータ構成及び関係を示す図である。
【図７】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第１の制御処理手順の一例を示すフローチャートである。
【図８】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図９】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける第２の制御処理手順の一例を示すフローチャートである。
【図１０】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける承認面の一例を示す模式図である。
【図１１】本発明の電子決裁サーバ及び情報処理装置を適用可能なワークフローシステムにおける承認者候補の遷移の一例を示す図である。
【図１２】本発明に係る情報処理装置（クライアント）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【図１３】本発明に係る情報処理装置（サーバ）で読み出し可能な各種データ処理プログラムを格納する記録媒体のメモリマップを説明する図である。
【符号の説明】
１０１ ワークフローサーバ
１０２ａ〜１０２ｃ ワークフロークライアント
１０３ ネットワーク
１０１１ 人事情報ＤＢ
１０１２ 組織情報ＤＢ
１０１３ 伝票情報ＤＢ
１０１４ 承認経路情報ＤＢ
１０１５ 伝票データＤＢ
Claims (12)
- 所定の通信媒体を介して複数のクライアントと通信可能なワークフローサーバにおいて、
組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、
承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段と、
前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段と、
前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段と、
を有することを特徴とするワークフローサーバ。 - 前記第１の特定手段は、申請日における組織情報より特定される次承認者と前記承認要求時における組織情報より特定される次承認者とが異なる場合には、それぞれを承認時の次承認予定者として特定することを特徴とする請求項１記載のワークフローサーバ。
- 前記第１の選択手段は、前記第１の特定手段により複数の次承認予定者が特定されている場合には、クライアントに送信する承認画面上で前記複数の次承認予定者からいずれかを選択させることを特徴とする請求項１又は２記載のワークフローサーバ。
- 前記第１の選択手段により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知手段を設けたことを特徴とする請求項１乃至３のいずれか１項に記載のワークフローサーバ。
- 役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に複数記憶可能な第３の記憶手段と、
前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成手段と、
を有することを特徴とする請求項１乃至４のいずれか１項に記載のワークフローサーバ。 - 前記生成手段により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第２の特定手段と、
前記第２の特定手段により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第２の通知手段と、
を設けたことを特徴とする請求項５記載のワークフローサーバ。 - 組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段とを有するワークフローサーバと、複数のクライアントとが所定の通信媒体を介して通信可能なワークフローシステムの制御方法において、
前記ワークフローサーバの第１の特定手段が、前記いずれかのクライアントからの承認要求に応じて、前記ワークフローサーバの前記第２の記憶手段に登録されている伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定工程と、
前記ワークフローサーバの第１の選択手段が、前記第１の特定工程で特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択工程と、
を含むことを特徴とするワークフローシステムの制御方法。 - 前記ワークフローサーバの第１の通知手段が、前記第１の選択工程により選択された次承認者に対して承認を行う伝票データが存在する旨を通知する第１の通知工程を更に含むことを特徴とする請求項７記載のワークフローシステムの制御方法。
- 前記ワークフローサーバが役割名により定義される承認経路情報を該承認経路情報を特定するためのＩＤ情報毎に記憶する第３の記憶手段を設けており、
前記ワークフローサーバの生成手段が、前記クライアントから指定される承認内容と前記承認経路情報を特定するためのＩＤ情報に基づいて、前記伝票データを生成し、前記第２の記憶手段に格納する生成工程を更に含むことを特徴とする請求項７又は８記載のワークフローシステムの制御方法。 - 前記ワークフローサーバの第２の特定手段が、前記生成工程により生成された伝票データの先頭の承認者を、申請日での組織情報に基づいて特定する第２の特定工程と、
前記ワークフローサーバの第２の通知手段が、前記第２の特定工程により特定された先頭の承認者に対して承認すべき伝票データが存在する旨を通知する第２の通知工程と、
を更に含むことを特徴とする請求項９記載のワークフローシステムの制御方法。 - 所定の通信媒体を介して複数のクライアントと通信可能なワークフローサーバで実行可能な制御プログラムであって、
前記ワークフローサーバを、
組織における役割名と該役割名に対応するユーザ名を定義する組織情報を適用日毎に複数記憶可能な第１の記憶手段と、
承認内容，役割名により定義される承認経路情報，申請日を含む伝票データを複数記憶可能な第２の記憶手段と、
前記いずれかのクライアントからの承認要求に応じて、前記第２の記憶手段に記憶される伝票データの次承認予定者を、申請日での組織情報及び前記承認要求時点での組織情報に基づいて複数特定可能な第１の特定手段と、
前記第１の特定手段により特定される複数の次承認予定者を前記クライアントに通知し、承認時に前記複数の次承認予定者からいずれかを次承認者として選択させる第１の選択手段と
して機能させることを特徴とする制御プログラム。 - 請求項１１に記載された制御プログラムをコンピュータが読み取り可能に記憶した記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002341906A JP4183491B2 (ja) | 2002-11-26 | 2002-11-26 | ワークフローサーバおよびワークフローシステムの制御方法およびプログラムおよび記録媒体 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002341906A JP4183491B2 (ja) | 2002-11-26 | 2002-11-26 | ワークフローサーバおよびワークフローシステムの制御方法およびプログラムおよび記録媒体 |
Related Child Applications (2)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2008200952A Division JP4642097B2 (ja) | 2008-08-04 | 2008-08-04 | ワークフローサーバおよびワークフローサーバの制御方法およびプログラムおよび記録媒体 |
| JP2008200951A Division JP4633149B2 (ja) | 2008-08-04 | 2008-08-04 | ワークフローサーバ、ワークフローサーバの制御方法、及び制御プログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004178144A JP2004178144A (ja) | 2004-06-24 |
| JP4183491B2 true JP4183491B2 (ja) | 2008-11-19 |
Family
ID=32704108
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002341906A Expired - Fee Related JP4183491B2 (ja) | 2002-11-26 | 2002-11-26 | ワークフローサーバおよびワークフローシステムの制御方法およびプログラムおよび記録媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP4183491B2 (ja) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2006195812A (ja) * | 2005-01-14 | 2006-07-27 | Ricoh Co Ltd | ワークフロー管理装置、ワークフロー管理方法、ワークフロー管理プログラム及び記録媒体 |
| JP4572702B2 (ja) * | 2005-02-25 | 2010-11-04 | 富士通株式会社 | 電子文書承認プログラム、電子文書承認方法、及び電子文書承認装置 |
| JP4643707B2 (ja) * | 2005-05-23 | 2011-03-02 | エスエーピー・ガバナンス・リスク・アンド・コンプライアンス・インコーポレーテッド | アクセス・エンフォーサー |
| JP2006338140A (ja) * | 2005-05-31 | 2006-12-14 | Anritsu Engineering Kk | ワークフロー処理プログラム |
| JP2009140415A (ja) * | 2007-12-10 | 2009-06-25 | Obic Co Ltd | ワークフローシステム |
| JP5708715B2 (ja) * | 2013-06-19 | 2015-04-30 | キヤノンマーケティングジャパン株式会社 | ワークフロー管理サーバおよびワークフロー管理サーバの制御方法およびプログラムおよび記録媒体 |
| US9450970B2 (en) * | 2013-08-12 | 2016-09-20 | Wal-Mart Stores, Inc. | Automatic blocking of bad actors across a network |
-
2002
- 2002-11-26 JP JP2002341906A patent/JP4183491B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2004178144A (ja) | 2004-06-24 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US11057388B2 (en) | Method and computer program product for creating enterprise management systems | |
| US6954737B2 (en) | Method and apparatus for work management for facility maintenance | |
| JP4903408B2 (ja) | 組織参照データ及び資格システム | |
| JP5025850B2 (ja) | クロスアプリケーションタイムシート | |
| US7917417B2 (en) | System and method for organizational and personal portfolio | |
| US9037537B2 (en) | Automatic redaction of content for alternate reviewers in document workflow solutions | |
| JP2007156678A (ja) | ワークフローシステムおよび滞留電子文書処理方法 | |
| JP4292342B2 (ja) | 電子承認システムにおける承認ルート決定方法及びプログラム | |
| JP4183491B2 (ja) | ワークフローサーバおよびワークフローシステムの制御方法およびプログラムおよび記録媒体 | |
| JP4628086B2 (ja) | ワークフローシステム、閲覧制限方法、プログラムおよび記録媒体 | |
| JP4250419B2 (ja) | 採用処理システム、プログラム及び記録媒体 | |
| JP2002083098A (ja) | 目標管理システム | |
| JP4633149B2 (ja) | ワークフローサーバ、ワークフローサーバの制御方法、及び制御プログラム | |
| US6799183B2 (en) | Operation assistance method and system and recording medium for storing operation assistance method | |
| JP4642097B2 (ja) | ワークフローサーバおよびワークフローサーバの制御方法およびプログラムおよび記録媒体 | |
| JP2003331095A (ja) | Ｄｂ管理によるワークフロー（申請承認業務）システム | |
| JP4887735B2 (ja) | 情報処理装置、情報処理システム及びプログラム | |
| JPH11250152A (ja) | 電子承認システムおよび電子承認システムのためのプログラムを記録した記録媒体 | |
| JP4628048B2 (ja) | ワークフローサーバおよびワークフロー制御方法およびプログラムおよび記録媒体 | |
| JP2001290925A (ja) | 承認システム、承認方法、コンピュータ読み取り可能なプログラム記憶媒体 | |
| JP2005202920A (ja) | ワークフローシステム及びワークフローシステムの管理方法 | |
| JP2005018389A (ja) | 業務管理装置及び方法並びに業務管理プログラム | |
| JP2002041741A (ja) | ビジネスプロセス管理システム | |
| JP2021117730A (ja) | 情報処理プログラム、情報処理方法、情報処理装置、情報処理システム | |
| Olukoya | SEMPLE (Self Employment Makes People Lives Easier) A platform to promote self-employment of people while providing avenues for people to get full-time employment in Ghana |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20051128 |
|
| RD03 | Notification of appointment of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7423 Effective date: 20080403 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20080527 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080603 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080804 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20080902 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20080902 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110912 Year of fee payment: 3 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120912 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130912 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130912 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20140912 Year of fee payment: 6 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R360 | Written notification for declining of transfer of rights |
Free format text: JAPANESE INTERMEDIATE CODE: R360 |
|
| R370 | Written measure of declining of transfer procedure |
Free format text: JAPANESE INTERMEDIATE CODE: R370 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313111 |
|
| S531 | Written request for registration of change of domicile |
Free format text: JAPANESE INTERMEDIATE CODE: R313531 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |