(57)【要約】      （修正有）【課題】業務管理システムとワークフローシステムを連携させた統合業務システムを提供する。【解決手段】申請データの申請状況を管理・記憶する申請状況管理テーブル５と、申請中の申請データを記憶する未承認データテーブル６と、承認された申請データを記憶する承認データテーブル７と、申請データに基づいて承認ルートを示す特定情報をワークフローシステムに渡す申請処理手段１１と、承認権限者からの承認・否決を受け取ってワークフローシステムに渡し、その結果に基づいて未承認データテーブル６の申請データを移動させる承認処理手段１２と、を有しており、ワークフローシステムは、申請データそのものは保持せずに申請データの管理を行うジョブ管理テーブル１５と、申請制御手段１６と、特定情報に基づいて新たな申請データが登録されたことの通知を承認ルートに従って実行し、その結果を業務管理システムに渡す承認制御手段１７とを有する。【選択図】図１
2008310773.tif 000002
【特許請求の範囲】
【請求項１】
申請者、承認権限者が操作する各クライアント端末からのデータ入力を受け付ける業務管理システムと、ワークフローシステムとを有する統合業務システムであって、
前記業務管理システムは、
最終承認されていない申請データを記憶する未承認データテーブルと、
前記申請データを受け付けると、前記ワークフローシステムに、前記ワークフローで生成され管理されるジョブ連番の要求を行い、該ジョブ連番を受け取る申請処理手段と、
前記申請データの承認状態を、前記取得したジョブ連番を用いて管理・記憶する申請状況管理テーブルと、
前記申請データに関する承認または否決の情報を前記承認権限者が操作するクライアント端末から受け取って前記ワークフローシステムに渡し、前記ワークフローシステムから、最終承認者による最終承認またはいずれかの承認権限者からの否決の情報を受け取る承認処理手段と、
最終承認済の申請データを記憶する承認データテーブルと、を有しており、
前記ワークフローシステムは、
前記業務管理システムから要求を受けとることで前記ジョブ連番を生成して該ジョブ連番を前記業務管理システムに渡す申請制御手段と、
前記業務管理システムで受け付けた申請データそのものは保持せずに前記ジョブ連番に対応する承認状態を管理するジョブ管理テーブルと、
予め登録された承認ルートに従って前記業務管理システムから前記承認または否決の情報を受け取り、最終承認者による最終承認またはいずれかの承認権限者から否決の情報を受け取ると、該情報を前記業務管理システムに渡す承認制御手段と、を有する
ことを特徴とする統合業務システム。
【請求項２】
申請者、承認権限者が操作する各クライアント端末からのデータ入力を受け付ける業務管理システムと、ワークフローシステムとを有する統合業務システムであって、
前記業務管理システムは、
前記申請者が操作する前記クライアント端末から受け付けた申請データの申請状況を、前記ワークフローシステムで該申請データを特定するジョブ連番を用いて管理・記憶する申請状況管理テーブルと、
前記申請中の申請データを記憶する未承認データテーブルと、
申請が承認された申請データを承認済みデータとして記憶する承認データテーブルと、
前記クライアント端末から申請データを受け付けると、該申請データに基づいてその承認ルートを示す特定情報を判定して前記特定情報を前記ワークフローシステムに渡すことで、前記ワークフローシステムから前記ジョブ連番を受け取り、前記申請状況管理テーブルに格納する申請処理手段と、
前記申請データに関する承認または否決の情報を前記承認権限者が操作するクライアント端末から受け取り、その情報を前記ワークフローシステムに渡す承認処理手段と、を有しており、
前記ワークフローシステムは、
ワークフローシステムにおいて前記業務管理システムで受け付けた申請データについて、該申請データそのものは保持せずにワークフローシステム側で前記ジョブ連番と前記特定情報により管理するジョブ管理テーブルと、
前記特定情報を受け取ることにより前記ジョブ連番を生成して前記ジョブ管理テーブルに格納すると共に、該ジョブ連番を前記業務管理システムに渡すことにより、前記申請データそのものは保持せずに前記申請データの管理を行う申請制御手段と、
前記ジョブ管理テーブルに新たなジョブ連番が格納された後または承認の情報を前記業務管理システムから受け取った後に、新たな申請データが登録されたことの通知を承認ルートに従って実行し、前記承認権限者による前記申請データに対する承認または否決の情報を前記業務管理システムから受け取り、最終承認者による最終承認またはいずれかの承認権限者から否決を受け取ると、それを示す処理完了通知を前記業務管理システムに渡す承認制御手段と、を有しており、
前記承認処理手段は、
前記ワークフローシステムから処理完了通知を受け取ると、最終承認の場合には、前記未承認データテーブルに格納した申請データを前記承認データテーブルに格納すると共に、前記未承認データテーブルの申請データを削除する、
ことを特徴とする統合業務システム。
【請求項３】
申請者、承認権限者が操作する各クライアント端末からのデータ入力を受け付ける業務管理システムと、ワークフローシステムとを有する統合業務システムであって、
前記業務管理システムは、
前記申請者が操作する前記クライアント端末から受け付けた申請データの申請状況を、前記業務管理システムで申請データを特定する処理連番と、前記ワークフローシステムで該申請データを特定するジョブ連番とを用いて管理・記憶する申請状況管理テーブルと、
前記申請中の申請データを記憶する未承認データテーブルと、
申請が承認された申請データを承認済みデータとして記憶する承認データテーブルと、
前記クライアント端末から受け付けた申請データに関する申請処理を実行する申請処理手段と、
前記申請データに関する承認・否決処理を実行する承認処理手段と、を有しており、
前記ワークフローシステムは、
ワークフローシステムにおいて前記業務管理システムで受け付けた申請データについて、該申請データそのものは保持せずにワークフローシステム側で前記ジョブ連番と前記特定情報により管理するジョブ管理テーブルと、
前記特定情報を前記業務管理システムから受け取ると、前記申請データに対する前記ジョブ連番を生成すると共に、該ジョブ連番と該特定情報とを前記ジョブ管理テーブルに格納し、前記生成した該ジョブ連番を前記業務管理システムに渡す申請制御手段と、
前記ジョブ管理テーブルに新たなジョブ連番が格納された後または承認の情報を前記業務管理システムから受け取った後に、新たな申請データが登録されたことの通知を承認ルートに従って実行し、前記承認権限者による前記申請データに対する承認または否決の情報を前記業務管理システムから受け取り、最終承認者による最終承認またはいずれかの承認権限者から否決を受け取ると、それを示す情報と前記ジョブ連番とを含む処理完了通知を前記業務管理システムに渡す承認制御手段と、を有しており、
前記申請処理手段は、
前記申請者が操作する前記クライアント端末から申請データを受け付け、前記申請データに対する前記処理連番を生成し、前記未承認データテーブルに該申請データと該処理連番とを格納すると共に、前記ワークフローシステムにおける承認ルートを示す特定情報を該申請データに基づいて判定し、該特定情報を前記ワークフローシステムに渡すことによって、前記ワークフローシステムから前記ジョブ連番を受け取って前記処理連番に対応づけて申請状況管理テーブルに格納し、
前記承認処理手段は、
前記承認権限者が操作する前記クライアント端末から前記申請データに対する承認を示す承認データまたは否決を示す否決データを受け取り、承認または否決を含む情報を前記ワークフローシステムに渡し、前記ワークフローシステムから前記処理完了通知を受け取ると、該処理通知に含まれるジョブ連番に基づいて前記申請状況管理テーブルを参照することで、対応する処理連番を特定し、
最終承認の処理完了通知の場合には、前記未承認データテーブルに格納する該処理連番に対応する申請データを前記承認データテーブルに格納すると共に、前記未承認データテーブルの該申請データを削除し、
否決の処理完了通知の場合には、前記未承認データテーブルの該処理連番に対応する申請データを削除する、
ことを特徴とする統合業務システム。
【請求項４】
前記業務管理システムは、更に、
前記承認データテーブルに承認済みデータを格納した後に、該承認済みデータに対する変更申請処理を行う変更申請処理手段、を有しており、
前記変更申請処理手段は、
前記申請者が操作する前記クライアント端末から変更後の申請データを受け付け、前記変更後の申請データを前記業務管理システムで特定する処理連番を生成し、前記未承認データテーブルに該変更後の申請データと該処理連番と、前記承認データテーブルに格納する変更前の申請データと該処理連番とをそれぞれ格納すると共に、前記ワークフローシステムにおける承認ルートを示す特定情報を該変更後の申請データに基づいて判定し、該特定情報を前記ワークフローシステムに渡すことによって、前記ワークフローシステムから前記ジョブ連番を受け取って前記処理連番と共に申請状況管理テーブルに格納し、
前記承認処理手段は、
前記承認権限者が操作する前記クライアント端末から前記変更後の申請データに対する承認データまたは否決データを受け取り、承認または否決を含む情報を前記ワークフローシステムに渡し、前記ワークフローシステムから処理完了通知を受け取り、該処理通知に含まれるジョブ連番に基づいて前記申請状況管理テーブルを参照することで、対応する処理連番を特定し、
最終承認の処理完了通知の場合には、前記未承認データテーブルに格納する該処理連番に対応する変更後の申請データを前記承認データテーブルに格納すると共に、前記未承認データテーブルの該変更後の申請データと変更前の申請データを共に削除し、
否決の処理完了通知の場合には、前記未承認データテーブルの該変更後の申請データと変更前の申請データを共に削除する、
ことを特徴とする請求項３に記載の統合業務システム。
【請求項５】
前記業務管理システムは、更に、
前記変更申請処理における承認権限者のクライアント端末から実績出力の処理要求を受け付けると、前記未承認データテーブルに格納している変更前の申請データと、変更後の申請データとを参照することにより、前記変更前の申請データを承認した場合の仮の実績を算出する実績出力処理手段、
を有することを特徴とする請求項４に記載の統合業務システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、企業などの組織において業務を遂行するための統合業務システムに関する。更に詳細には、業務に関するデータを記憶・管理する業務管理システムと、業務に関する申請、回覧、承認等を行うワークフローシステムを連携させた統合業務システムに関する。
【背景技術】
【０００２】
昨今、ビジネスに対するコンプライアンスが重視されており、それに伴い、企業でもその業務に関する内部統制の実現が求められている。業務に関する内部統制機能をどのように企業活動に組み込むかについては様々な対応があり得る。その方法の一つとして、人事、給与、財務会計、販売、購買等の業務に関するデータをサーバで記憶、管理する業務管理システムや、業務に関する申請、回覧、承認等を管理するワークフローシステムを導入している企業では、それらのシステムを活用して内部統制機能を実現することが望まれている。
【０００３】
そこで内部統制機能の一環として、業務管理システムとワークフローシステムとを連携することが検討されており、その連携の一つとして、ワークフローシステム側で処理した承認済みデータを業務管理システムに登録する方法が、下記非特許文献１に記載のように、知られている。
【０００４】
また下記特許文献１では、承認機能を有する伝票入力システムが開示されており、当該システムを利用することによっても、実質的に上記の連携を実現することができる。
【０００５】
【特許文献１】特開平１０−３１７０６号公報
【０００６】
【非特許文献１】都築電気株式会社、”IntrameriT Workflow 会計情報連携オプション”、[online]、インターネット＜http://www.intramerit.com/seihin/workflow/option/kaikei/kaikei.html＞
【発明の開示】
【発明が解決しようとする課題】
【０００７】
上記非特許文献１に記載のシステムを用いた場合、ワークフローシステムと業務管理システムの双方でデータを備えており、ワークフローシステムから業務管理システムへの一方向の処理が行われるだけなので、例えば、一度承認が行われた申請について、再度、その内容を修正したい場合には、業務管理システムに登録された承認済みのデータ（例えば伝票データやマスタデータ）を直接修正することはできず、修正内容を反映させた申請を新規に行い、それと併せて帳票の重複を解消するため以前の承認済みデータを削除しなければならない。
【０００８】
このような作業は煩雑であると共に、承認済みデータの削除のタイミングによっては正確な実績（承認済みデータの集計）が把握できない可能性があり、改善が求められている。
【０００９】
また上記特許文献１に記載のシステムは、単に伝票入力から伝票承認までの業務を電子化し、伝票入力権限や伝票承認権限を持つ利用者の場合には、伝票入力完了と同時に承認を行うことができるようにするものであり、業務管理システムとワークフローシステムの連携に関する課題、すなわち、業務管理システムとワークフローシステムの双方で同じようなデータを備えていること、及び新たな修正した申請が行われた場合に、未承認のデータに基づいた実績を見ることができない、といった課題を解決するものではない。
【課題を解決するための手段】
【００１０】
本発明者は上記問題点に鑑み、業務管理システムとワークフローシステムの連携にかかる課題、すなわち、業務管理システムとワークフローシステムの双方で同じようなデータを備えていること、及び新たな修正した申請が行われた場合に、未承認のデータに基づいた実績を見ることができない、といった課題を解決する統合業務システムを発明した。
【００１１】
請求項１の発明は、申請者、承認権限者が操作する各クライアント端末からのデータ入力を受け付ける業務管理システムと、ワークフローシステムとを有する統合業務システムであって、前記業務管理システムは、最終承認されていない申請データを記憶する未承認データテーブルと、前記申請データを受け付けると、前記ワークフローシステムに、前記ワークフローで生成され管理されるジョブ連番の要求を行い、該ジョブ連番を受け取る申請処理手段と、前記申請データの承認状態を、前記取得したジョブ連番を用いて管理・記憶する申請状況管理テーブルと、前記申請データに関する承認または否決の情報を前記承認権限者が操作するクライアント端末から受け取って前記ワークフローシステムに渡し、前記ワークフローシステムから、最終承認者による最終承認またはいずれかの承認権限者からの否決の情報を受け取る承認処理手段と、最終承認済の申請データを記憶する承認データテーブルと、を有しており、前記ワークフローシステムは、前記業務管理システムから要求を受けとることで前記ジョブ連番を生成して該ジョブ連番を前記業務管理システムに渡す申請制御手段と、前記業務管理システムで受け付けた申請データそのものは保持せずに前記ジョブ連番に対応する承認状態を管理するジョブ管理テーブルと、予め登録された承認ルートに従って前記業務管理システムから前記承認または否決の情報を受け取り、最終承認者による最終承認またはいずれかの承認権限者から否決の情報を受け取ると、該情報を前記業務管理システムに渡す承認制御手段と、を有する統合業務システムである。
【００１２】
本発明のように構成することで、申請データそのものはワークフローシステムに渡さずに、ワークフローシステムにおける処理を実行することはできる。すなわち申請者、承認権限者はいずれも申請データそのものは業務管理システムを用いることで参照し、ワークフローシステムからはその通知と、承認ルートの管理をしているに過ぎない。そのため、従来のようにワークフローシステムにおいて申請データの管理を行わずに、業務管理システムで一元化して申請データそのものを管理しているので、仮に申請データの変更等が行われる場合であっても、業務管理システムとワークフローシステムの双方の申請データの変更を行わずにすむ。
【００１３】
請求項２の発明は、申請者、承認権限者が操作する各クライアント端末からのデータ入力を受け付ける業務管理システムと、ワークフローシステムとを有する統合業務システムであって、前記業務管理システムは、前記申請者が操作する前記クライアント端末から受け付けた申請データの申請状況を、前記ワークフローシステムで該申請データを特定するジョブ連番を用いて管理・記憶する申請状況管理テーブルと、前記申請中の申請データを記憶する未承認データテーブルと、申請が承認された申請データを承認済みデータとして記憶する承認データテーブルと、前記クライアント端末から申請データを受け付けると、該申請データに基づいてその承認ルートを示す特定情報を判定して前記特定情報を前記ワークフローシステムに渡すことで、前記ワークフローシステムから前記ジョブ連番を受け取り、前記申請状況管理テーブルに格納する申請処理手段と、前記申請データに関する承認または否決の情報を前記承認権限者が操作するクライアント端末から受け取り、その情報を前記ワークフローシステムに渡す承認処理手段と、を有しており、前記ワークフローシステムは、ワークフローシステムにおいて前記業務管理システムで受け付けた申請データについて、該申請データそのものは保持せずにワークフローシステム側で前記ジョブ連番と前記特定情報により管理するジョブ管理テーブルと、前記特定情報を受け取ることにより前記ジョブ連番を生成して前記ジョブ管理テーブルに格納すると共に、該ジョブ連番を前記業務管理システムに渡すことにより、前記申請データそのものは保持せずに前記申請データの管理を行う申請制御手段と、前記ジョブ管理テーブルに新たなジョブ連番が格納された後または承認の情報を前記業務管理システムから受け取った後に、新たな申請データが登録されたことの通知を承認ルートに従って実行し、前記承認権限者による前記申請データに対する承認または否決の情報を前記業務管理システムから受け取り、最終承認者による最終承認またはいずれかの承認権限者から否決を受け取ると、それを示す処理完了通知を前記業務管理システムに渡す承認制御手段と、を有しており、前記承認処理手段は、前記ワークフローシステムから処理完了通知を受け取ると、最終承認の場合には、前記未承認データテーブルに格納した申請データを前記承認データテーブルに格納すると共に、前記未承認データテーブルの申請データを削除する、統合業務システムである。
【００１４】
本発明のように構成することで、上述の発明と同様の技術的効果を得ることができる。
【００１５】
請求項３の発明は、申請者、承認権限者が操作する各クライアント端末からのデータ入力を受け付ける業務管理システムと、ワークフローシステムとを有する統合業務システムであって、前記業務管理システムは、前記申請者が操作する前記クライアント端末から受け付けた申請データの申請状況を、前記業務管理システムで申請データを特定する処理連番と、前記ワークフローシステムで該申請データを特定するジョブ連番とを用いて管理・記憶する申請状況管理テーブルと、前記申請中の申請データを記憶する未承認データテーブルと、申請が承認された申請データを承認済みデータとして記憶する承認データテーブルと、前記クライアント端末から受け付けた申請データに関する申請処理を実行する申請処理手段と、前記申請データに関する承認・否決処理を実行する承認処理手段と、を有しており、前記ワークフローシステムは、ワークフローシステムにおいて前記業務管理システムで受け付けた申請データについて、該申請データそのものは保持せずにワークフローシステム側で前記ジョブ連番と前記特定情報により管理するジョブ管理テーブルと、前記特定情報を前記業務管理システムから受け取ると、前記申請データに対する前記ジョブ連番を生成すると共に、該ジョブ連番と該特定情報とを前記ジョブ管理テーブルに格納し、前記生成した該ジョブ連番を前記業務管理システムに渡す申請制御手段と、前記ジョブ管理テーブルに新たなジョブ連番が格納された後または承認の情報を前記業務管理システムから受け取った後に、新たな申請データが登録されたことの通知を承認ルートに従って実行し、前記承認権限者による前記申請データに対する承認または否決の情報を前記業務管理システムから受け取り、最終承認者による最終承認またはいずれかの承認権限者から否決を受け取ると、それを示す情報と前記ジョブ連番とを含む処理完了通知を前記業務管理システムに渡す承認制御手段と、を有しており、前記申請処理手段は、前記申請者が操作する前記クライアント端末から申請データを受け付け、前記申請データに対する前記処理連番を生成し、前記未承認データテーブルに該申請データと該処理連番とを格納すると共に、前記ワークフローシステムにおける承認ルートを示す特定情報を該申請データに基づいて判定し、該特定情報を前記ワークフローシステムに渡すことによって、前記ワークフローシステムから前記ジョブ連番を受け取って前記処理連番に対応づけて申請状況管理テーブルに格納し、前記承認処理手段は、前記承認権限者が操作する前記クライアント端末から前記申請データに対する承認を示す承認データまたは否決を示す否決データを受け取り、承認または否決を含む情報を前記ワークフローシステムに渡し、前記ワークフローシステムから前記処理完了通知を受け取ると、該処理通知に含まれるジョブ連番に基づいて前記申請状況管理テーブルを参照することで、対応する処理連番を特定し、最終承認の処理完了通知の場合には、前記未承認データテーブルに格納する該処理連番に対応する申請データを前記承認データテーブルに格納すると共に、前記未承認データテーブルの該申請データを削除し、否決の処理完了通知の場合には、前記未承認データテーブルの該処理連番に対応する申請データを削除する、統合業務システムである。
【００１６】
本発明のように構成することで、上述の発明と同様の技術的効果を得ることができる。
【００１７】
請求項４の発明において、前記業務管理システムは、更に、前記承認データテーブルに承認済みデータを格納した後に、該承認済みデータに対する変更申請処理を行う変更申請処理手段、を有しており、前記変更申請処理手段は、前記申請者が操作する前記クライアント端末から変更後の申請データを受け付け、前記変更後の申請データを前記業務管理システムで特定する処理連番を生成し、前記未承認データテーブルに該変更後の申請データと該処理連番と、前記承認データテーブルに格納する変更前の申請データと該処理連番とをそれぞれ格納すると共に、前記ワークフローシステムにおける承認ルートを示す特定情報を該変更後の申請データに基づいて判定し、該特定情報を前記ワークフローシステムに渡すことによって、前記ワークフローシステムから前記ジョブ連番を受け取って前記処理連番と共に申請状況管理テーブルに格納し、前記承認処理手段は、前記承認権限者が操作する前記クライアント端末から前記変更後の申請データに対する承認データまたは否決データを受け取り、承認または否決を含む情報を前記ワークフローシステムに渡し、前記ワークフローシステムから処理完了通知を受け取り、該処理通知に含まれるジョブ連番に基づいて前記申請状況管理テーブルを参照することで、対応する処理連番を特定し、最終承認の処理完了通知の場合には、前記未承認データテーブルに格納する該処理連番に対応する変更後の申請データを前記承認データテーブルに格納すると共に、前記未承認データテーブルの該変更後の申請データと変更前の申請データを共に削除し、否決の処理完了通知の場合には、前記未承認データテーブルの該変更後の申請データと変更前の申請データを共に削除する、統合業務システムである。
【００１８】
本発明のように構成することで、一度承認した申請データであっても容易に変更申請を行うことができる。すなわち、申請データそのものは業務管理システムで一元化して管理しているので、ワークフローシステムとの同期をとる必要がない。そのため従来のように、変更申請をしたことにより、業務管理システムで承認している申請データと、ワークフローシステムで承認している申請データとが異なる、といった事態を防ぐことができる。
【００１９】
請求項５の発明において、前記業務管理システムは、更に、前記変更申請処理における承認権限者のクライアント端末から実績出力の処理要求を受け付けると、前記未承認データテーブルに格納している変更前の申請データと、変更後の申請データとを参照することにより、前記変更前の申請データを承認した場合の仮の実績を算出する実績出力処理手段、を有する統合業務システムである。
【００２０】
本発明のように構成することで、仮に変更後の申請データで承認した場合の実績データ（仮の実績データ）を算出することができる。これは未承認データテーブルに、承認済みの申請データ（変更前の申請データ）と、変更後の申請データとの双方を格納しているからである。これによって、変更申請を承認したら実績としてどれだけ変化するのかを、承認権限者が比較した上で承認、否決の判断を行うことが可能となる。
【発明の効果】
【００２１】
本発明の統合業務システムによって、業務に関するデータは業務管理システムのみで取り扱い、ワークフローシステムでは管理しない構成となる。そのため、従来のように業務管理システムとワークフローシステムの双方でデータ管理しなくてすむので、データ修正等の際に煩雑さを解消することができる。また、新たな修正した申請が行われた場合に、未承認のデータに基づいた実績を見ることができるので、承認権限者が新たな修正した申請の際に、その申請を仮に承認したら従来とどのように変わるのか、の変化を把握した上で承認・否決の行為を行うことが可能となる。
【発明を実施するための最良の形態】
【００２２】
本発明の統合業務システム１の概念図を図１に示す。
【００２３】
本発明の統合業務システム１は、企業などの組織における業務を遂行するためのコンピュータシステムであって、業務に関するデータを記憶・管理する業務管理システム３と、業務に関する申請、その申請の回覧、承認等の管理を行うワークフローシステム４とを有する。また業務管理システム３とワークフローシステム４との間はデータの送受信が可能である。
【００２４】
また統合業務システム１は、ネットワークを介して、業務に関する申請を行う申請者が利用するコンピュータ端末（申請者端末）や、その申請の承認権限者が利用するコンピュータ端末（承認者端末）（申請者端末や承認者端末を総称して「クライアント端末２」という）とデータの送受信が可能である。
【００２５】
業務管理システム３は、業務管理システム３の各機能を実現するウェブサーバやアプリケーションサーバと、データの記憶を行うデータベースサーバとを有することが好ましいが、このシステム構成には限定されない。
【００２６】
またワークフローシステム４も同様に、ワークフローシステム４の各機能を実現するウェブサーバやアプリケーションサーバと、データの記憶を行うデータベースサーバとを有することが好ましいが、このシステム構成には限定されない。
【００２７】
なお本発明のクライアント端末２は、基本的には業務管理システム３との間でデータの入力処理、出力処理を行う。またワークフローシステム４は、クライアント端末２から所定の通知を受けるものの、データの入力処理は行わないことが好ましい。
【００２８】
業務管理システム３は、企業等の業務遂行にあたり必要な業務ソフトウェアとこのソフトウェアを実行するハードウェアとから構成されるコンピュータシステムであり、例えば会計管理システム、販売・購買管理システム、人事・給与管理システム、顧客管理（ＣＲＭ（Customer Relationship Management））システム、営業支援システム（ＳＦＡ（Sales Force Automation））などがある。またこれらの各システムがモジュールとしてリアルタイムに連携し、データを一括管理する態様であってもよい。
【００２９】
業務管理システム３は、申請状況管理テーブル５と未承認データテーブル６と承認データテーブル７と否決・取り下げデータテーブル８と申請処理手段１１と承認処理手段１２と変更申請処理手段１３と実績出力処理手段１４と入力処理手段９と出力処理手段１０とを有する。
【００３０】
申請状況管理テーブル５は、業務について行った何らかの申請やその承認状況（未申請、申請中、承認中、最終承認済、否決など）を格納するテーブルであり、後述のワークフローシステム４のジョブと関連づけられている。この関連づけは、例えばワークフローシステム４が生成し、そのジョブ管理テーブル１５に格納するジョブ連番を、申請状況管理テーブル５で上記情報と共に保持することで行う。
【００３１】
申請状況管理テーブル５には、１レコードに種別（例えば伝票種別、マスタ種別などを示す）、申請区分（例えば新規申請か、変更申請か、削除申請か等を示す）、処理連番（処理連番とは、データを特定するための識別情報（連続の番号であることが好ましいが、それに限定されず、番号でなくても、また連続でなくてもよい）であり、データが登録された際に付与される）、承認状態（未申請か、申請中か、承認済みか等を示す）、ジョブ連番（ワークフローシステム４側で生成される識別情報（連続の番号であることが好ましいが、それに限定されず、番号でなくても、また連続でなくてもよい）であって業務管理システム３側から申請があった際に生成される）、申請者（登録されているデータを申請した者）が含まれることが好ましい。さらに日時、登録者（データを登録した者）、承認者（申請を承認した者）、否決者（申請を否決した者）などが含まれていても良い。
【００３２】
未承認データテーブル６は、申請された申請データのうち、未承認データ（承認されていない伝票データ、マスタデータ等）を格納するテーブルである。未承認データテーブル６には、１レコードに、区分（変更前データか、変更後データかなどを示す）、処理連番、データ内容（例えば債務明細伝票であれば、支払先、金額、借方、貸方データを、受発注伝票であれば、得意先、商品、受注数、売上済数、得意先マスタであれば、得意先名、住所、電話番号、担当者名などを示す）が含まれることが好ましい。
【００３３】
承認データテーブル７は、申請された申請データのうち、承認データ（最終承認された申請データ）を格納するテーブルである。承認データテーブル７には、１レコードに、処理連番、データ内容（未承認データテーブルのデータ内容と同様）が含まれることが好ましい。承認データテーブル７は通常の業務管理システム３における業務データテーブルと同一である。
【００３４】
否決・取り下げデータテーブル８は、申請された申請データのうち、否決・取り下げデータ（否決、取り下げされたデータ）を格納するテーブルである。否決・取り下げデータテーブル８には、１レコードに、処理連番、データ内容（未承認データテーブルのデータ内容と同様）が含まれることが好ましい。
【００３５】
入力処理手段９は、クライアント端末２でユーザ（クライアント端末２の操作者）が入力し、業務管理システム３に送信したデータを受信し、そのデータをほかの各手段に渡す。
【００３６】
出力処理手段１０は、業務管理システム３で処理されたデータをクライアント端末２で表示するための画面データを生成し、それをクライアント端末２に送信する。
【００３７】
申請処理手段１１は、後述するワークフローシステム４の申請制御手段１６を用いて業務にかかるデータの申請に関する処理を行う。すなわち、クライアント端末２から新たな申請データ（この状態では未承認なので未承認データとなる）を受け付けると、それを未承認データテーブル６に格納する。そして所定の条件を満たすことによって、未承認データである申請データに基づいて、その申請データに関連する情報（申請データ関連情報）をワークフローシステム４に渡す。ワークフローシステム４からは、未承認データである申請データにおける申請状況の情報を受け取り、それに基づいて申請状況管理テーブル５を更新することで、申請状況の管理を行う。
【００３８】
つまり、本発明において、業務管理システム３は、ワークフローシステム４に申請データ自体を送信することはなく、申請データを特定する情報を用いることによりワークフローシステム４を、いわば申請承認エンジンとして利用する。
【００３９】
承認処理手段１２は、承認に関する処理と否決に関する処理を行う。すなわち、承認処理手段１２は、ユーザが使用するクライアント端末２から承認したことを示す承認データ、または否決したことを示す否決データを入力処理手段９を介して受け取り、承認データ・否決データに関する情報をワークフローシステム４の承認制御手段１７に渡す。ワークフローシステム４からは、ワークフローシステム４側で当該申請データを管理する番号（ジョブ連番など）を受け取り、当該ジョブ連番について、「承認済」または「否決」を申請状況管理テーブル５に登録する。また最終承認された場合には、未承認データテーブル６に格納している申請データ（申請データのうち、最終承認が行われていない承認待ちのデータ）を承認データテーブル７に格納し、未承認データテーブル６の当該申請データは削除する。また否決・取り下げされた場合には、未承認データテーブル６に格納している申請データ（申請データのうち、最終承認が行われていない承認待ちのデータ）を否決・取り下げデータテーブル８に格納し、未承認データテーブル６の当該申請データは削除する。
【００４０】
変更申請処理手段１３は、最終承認された申請データ（承認済みデータ）の変更、すなわち承認データテーブル７に格納している承認済みデータの変更（修正または削除）に関する処理を行う。
【００４１】
実績出力処理手段１４は、承認済データまたは未承認データの集計出力に関する処理を行う。未承認のデータがあるときは、承認分のデータと未承認分のデータを分けて集計して表示することが好ましい。ユーザの選択により承認データのみ又は未承認データのみを表示するようにしてもよい。
【００４２】
ワークフローシステム４は、業務における様々な申請や承認処理をネットワークを介して電子的に行うことで、各種申請が申請者から承認者へ自動的に通知され、次々に承認ルートを経ていくコンピュータシステムである。
【００４３】
ワークフローシステム４は、ジョブ管理テーブル１５と申請制御手段１６と承認制御手段１７とを有する。また、ワークフローシステム４では、通常のワークフローシステム４が有する様々な機能やデータテーブルなどを備えていてもよい。なお、ワークフローシステム４は、クライアント端末２から通常のワークフローとしても利用できる。
【００４４】
ジョブ管理テーブル１５は、業務管理システム３から送信される申請データ関連情報に対応して申請制御手段１６が生成したジョブ連番を、格納するテーブルである。
【００４５】
申請制御手段１６は、申請データ関連情報を業務管理システム３から受け取り、それに対応したジョブ連番を生成すると共に、ジョブ管理テーブル１５にそのジョブ連番を格納させる手段である。
【００４６】
承認制御手段１７は、ワークフローシステム４側における承認処理または否決処理を行う手段である。例えば、申請データ関連情報がジョブ管理テーブル１５に格納された場合、所定の順番（通常は予め定められた承認順番の下位のものから順番に）で承認者側端末（クライアント端末２）に新たな申請が行われたことの通知を送信する。また、承認者側端末（クライアント端末２）から承認の通知を受信すると、次の上位の承認者側端末（クライアント端末２）に対して新たな申請が行われたことの通知を送信する。さらに、最終承認者が利用する承認者側端末（クライアント端末２）から承認の通知を受信すると、業務管理システム３の承認処理手段１２に承認に関する情報（例えばジョブ連番、承認情報）を送信する。あるいは、承認者側端末から否決の通知を受信すると、業務管理システム３の承認処理手段１２に否決に関する情報（例えばジョブ連番、否決情報）を送信する。
【００４７】
なお承認処理の承認順番は、所定のデータテーブル（ステージ設定テーブル等）にその順番を申請の種類（フォーム）毎に予め記録しておき、それを参照することによって承認の順番を特定する。また申請データに対して承認を行った者を示すフラグを設け、そのフラグを順次更新することで、承認の段階を管理することが出来る。このような承認の回覧等は公知のワークフローシステム４の機能を用いることが出来る。
【実施例１】
【００４８】
次に本発明の統合業務システム１における処理プロセスの一例を図２乃至図４のフローチャート、図１の概念図を用いて説明する。図２は申請処理を示すフローチャートであり、図３は承認・否決処理を示すフローチャートであり、図４は変更申請処理を示すフローチャートである。
【００４９】
以下の処理プロセスの説明では、まず新規のデータを申請する申請処理が行われ、それに対する承認・否決の処理が行われ、更にその後、その承認された申請データ（承認データ）に対する変更申請の処理が行われ、その承認作業中に未承認データの実績出力処理が行われる場合を説明する。
【００５０】
申請処理の処理プロセスを図２のフローチャートを用いて説明する。
【００５１】
まず何らかのデータの申請処理を行いたいユーザ（この場合は申請者）は、クライアント端末２（この場合は申請者端末）を操作して、申請処理を開始する画面を起動する。そして所定の操作により、申請するデータ（申請データ）等の入力を行う。
【００５２】
この申請データは、クライアント端末２から業務管理システム３に送信され、業務管理システム３の入力手段を介して申請処理手段１１で受け付ける。なおこの際の申請データは、未承認のデータであることから未承認データでもある。申請処理手段１１で受け付けた未承認データである申請データは、申請処理手段１１が未承認データテーブル６に格納する（Ｓ１００）。またこの際に、申請処理手段１１は、申請状況管理テーブル５に、受け付けた申請データの申請状況を管理するために、当該申請があったことを示す情報、すなわち、処理連番、申請区分、ユーザＩＤなどを格納する。処理連番は、申請データを受け付けることによって自動的に付与されてもよい。
【００５３】
これによって新たな申請が業務管理システム３に登録されることとなる。
【００５４】
次に、所定のタイミングで、申請処理手段１１は入力処理手段９を介して、申請者が利用するクライアント端末２（この場合は申請者端末）から、未処理である申請データの抽出条件を受け取り、この抽出条件に基づいて申請状況管理テーブル５を参照し、抽出条件に合致する、未処理の申請データを未承認データテーブル６から抽出する（Ｓ１１０）。この際の抽出条件には様々なものがあるが、例えば未承認データテーブル６に申請データを格納する際に、すでに申請処理が開始されたものであるか否かを示すフラグをつけ、そのフラグが立っている場合には申請処理を開始済み、ない場合には申請処理が未処理であることで、判定してもよい。すなわち当該フラグの有無を抽出条件として検索すればよい。
【００５５】
以上のようにして未処理の申請データを未承認データテーブル６から抽出すると、抽出した未処理の申請データを用いて、未処理のデータ一覧画面を生成し、出力処理手段１０を介して、クライアント端末２（この場合は申請者端末）に送信する（Ｓ１２０）。クライアント端末２（この場合は申請者端末）ではこの一覧画面を表示し、ユーザ（申請者）により、申請処理を開始する申請データの選択が行われる。申請処理手段１１は、ここで選択された申請処理を開始する申請データの選択の情報を入力処理手段９を介してクライアント端末２（この場合は申請者端末）で受け付ける（Ｓ１３０）。
【００５６】
申請処理手段１１は、受け付けた申請処理を開始する未処理の申請データに関する情報（申請データ関連情報）を、ワークフローシステム４に渡す（Ｓ１４０）。なお申請処理手段１１が生成する申請データ関連情報としては、例えば申請者のユーザＩＤ、フォーム番号（フォーム番号とはワークフローシステム４が管理する申請フォーム（例えば得意先マスタ申請フォーム、売上伝票申請フォーム等）を特定する番号であり、承認ルートも特定する番号）を、ワークフローシステム４に渡す。なおこのフォーム番号は、申請データの受付の際にあわせて、当該申請データの処理の種類を示す処理種別の情報を受け付けており、処理種別とフォーム番号とを対応づけて格納するフォーム設定テーブル（図５（ｃ））を参照することにより特定できる。
【００５７】
ワークフローシステム４の申請制御手段１６は、申請データ関連情報を業務管理システム３の申請処理手段１１から受け取り（Ｓ１５０）、当該申請データ関連情報に対応するジョブ連番を生成し、そのジョブ連番を受け取った申請データ関連情報と共にジョブ管理テーブル１５に格納する（Ｓ１６０）。ここでジョブ連番は、受け付けた申請データ関連情報を識別する情報である。好ましくは数字により連番で採番されることが好ましいが、数字以外の文字などで採番されていてもよいし、連番でなくてもよい。
【００５８】
申請制御手段１６で申請データ関連情報とジョブ連番とをジョブ管理テーブル１５に格納後、申請データ関連情報におけるフォーム番号から承認ルートを判定し（この際の承認ルートは、ワークフローシステム４に備えられた、上述のステージ設定テーブルなどを参照する）、受け取った申請データ関連情報におけるユーザＩＤと承認ルートのユーザＩＤとを比較して、承認状態、現在の承認権限者を判定する。なおこの現在の承認権限者は、承認ルートにおける最初の承認権限者になる。
【００５９】
そして判定した承認状態（一般的には「申請中」となる）、現在の承認権限者をジョブ管理テーブル１５に申請制御手段１６は格納し、申請制御手段１６は、ジョブ連番と承認状態とを業務管理システム３に渡す。この通知が申請を受理した（申請処理が開始された）ことを示す申請受理通知となる（Ｓ１７０）。
【００６０】
ワークフローシステム４から申請受理通知を受け取った業務管理システム３の申請処理手段１１は、Ｓ１４０でワークフローシステム４に渡した申請データ関連情報に対応づけて、ジョブ連番と承認状態を申請受理通知に基づいて申請状況管理テーブル５に格納する（Ｓ１８０）。従って、申請状況管理テーブル５に「申請中」が登録されることとなる。
【００６１】
Ｓ１００からＳ１８０の処理を具体例を用いて説明する。なお以下の具体例においては、仕訳伝票を登録する場合を説明する。
【００６２】
例えばユーザ（申請者：ユーザＩＤ「００００１」）は、クライアント端末２で所定の操作を行うことにより、メニューから「仕訳伝票登録」を行う画面を選択し、新規に申請するデータ（申請データ）を入力する（伝票種別「仕訳」、申請区分「新規」、ユーザＩＤ「００００１」、入力データ「○○○○○」、・・・）。この際のデータとしては、例えば金額、科目コード、日付、伝票種別などがある。
【００６３】
この未処理の申請データを受け取った申請処理手段１１は、当該処理を識別するための処理連番を生成し、その処理連番と受け取った申請データとを対応づけて申請状況管理テーブル５に格納する。またこの際に、申請処理手段１１は、申請状況管理テーブル５に、受け付けた申請データの申請状況を管理するために、当該申請があったことを示す情報、すなわち、処理連番、申請区分、ユーザＩＤなどを格納する。この時点ではジョブ連番、承認状態はいずれも情報がないので空欄となる。
【００６４】
以上の状態の未承認テーブルを模式的に示す概念図を図５（ａ）に、申請状況管理テーブル５を模式的に示す概念図を図５（ｂ）に示す。
【００６５】
ユーザが所定の操作を行うことにより、未承認データテーブル６から、未処理の申請データが抽出される。この場合には未承認データテーブル６には先ほどの一つのデータしか入っていないので、当該データが抽出され、クライアント端末２に送信される。そしてそのデータが選択されたことを申請処理手段１１で受け付ける。
【００６６】
これを受け付けると、当該申請データに対応する申請データ関連情報として、ユーザＩＤとフォーム番号とを申請処理手段１１がワークフローシステム４に渡す。なおフォーム番号は、上述の通り、承認ルートを示す情報であるが、業務管理システム３に別途備えているフォーム設定テーブル（図５（ｃ））に、処理種別（例えば伝票種別など）と対応づけて格納している。従って、申請データの登録の際に併せて受け取っている処理種別（伝票種別など）に基づいて、当該フォーム設定テーブルを参照することで、フォーム番号を特定することができる。フォーム設定テーブルの一例を図５（ｃ）に示す。
【００６７】
従って、この場合、申請データ関連情報として、ユーザＩＤ「００００１」、フォーム番号「１」が業務管理システム３からワークフローシステム４に渡されることとなる。
【００６８】
ワークフローシステム４は申請データ関連情報を受け取ると、それに対応するジョブ連番を生成する。例えばジョブ連番として「１」を生成する。生成したジョブ連番「１」と、申請データ関連情報、すなわちユーザＩＤ「００００１」、フォーム番号「１」とをジョブ管理テーブル１５に格納する。そしてステージ設定テーブルを参照することでフォーム番号から承認ルートを判定し、受け取った申請データ関連情報におけるユーザＩＤ「００００１」と承認ルートのユーザＩＤ（ここでは、ユーザＡのユーザＩＤ）とを比較して、承認状態、現在の承認権限者を判定する。
【００６９】
そして判定した承認状態として「申請中」、承認権限者を「Ａ」としてジョブ管理テーブル１５に申請制御手段１６が格納すると共に、ジョブ連番「１」と承認状態「申請中」の情報を申請制御手段１６は、業務管理システム３に渡す。
【００７０】
この状態のジョブ管理テーブル１５を模式的に示す概念図が図６であり、ステージ設定テーブルの一例を図７に示す。
【００７１】
このようにしてジョブ連番と承認状態の情報をワークフローシステム４から受け取った業務管理システム３の申請処理手段１１は、それらを当該申請データの申請情報管理テーブルに格納する。この状態を模式的に示す未承認データテーブル６を図８（ａ）に、申請状況管理テーブル５を図８（ｂ）に示す。
【００７２】
以上のようにして、Ｓ１００からＳ１８０の申請処理が行える。
【００７３】
次に、上述のようにして申請された申請データに対する承認・否決処理を図３のフローチャートを用いて説明する。
【００７４】
上述のようにして、ワークフローシステム４のジョブ管理テーブル１５に新たな申請データ関連情報が格納されると、そのフォーム番号に対応した承認ルート（ステージ設定テーブルに格納された情報）の最初の承認権限者に対して承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【００７５】
この通知を受け取った最初の承認権限者は、そのクライアント端末２（この場合は承認者端末）で所定の操作を行うことによって、当該承認待ちの申請データを取得する要求をクライアント端末２から業務管理システム３に送信する。
【００７６】
この要求を受け付けると、承認処理手段１２は、ワークフローシステム４に当該取得要求を渡し、それを受け付けたワークフローシステム４の承認制御手段１７が、ジョブ管理テーブル１５を参照することによって、当該承認権限者の承認待ちとなっている申請データの各ジョブ連番を、ジョブ管理テーブル１５から抽出し、そのジョブ連番を承認制御手段１７が業務管理システム３に渡す。
【００７７】
このジョブ連番をワークフローシステム４から受け取った承認処理手段１２は、当該ジョブ連番に基づいて、申請状況管理テーブル５、未承認データテーブル６を参照することで、承認待ちとなっている申請データを抽出し（Ｓ２００）、承認待ちとなっている申請データの一覧画面を生成して出力処理手段１０を介して、それをクライアント端末２に送信する（Ｓ２１０）。なおこの一覧画面では、承認待ちの件の抽出のみではなく、承認済みの件の抽出ができるようにしてもよい。
【００７８】
最初の承認権限者であるユーザは、そのクライアント端末２（この場合は承認者端末）に表示された一覧画面から、承認または否決対象とする申請データ（承認待ちとなっている申請データ）を選択すると、それが業務管理システム３の承認処理手段１２に送信される。それに対して、「承認」（承認データ）または「否決」（否決データ）を入力する。
【００７９】
ここで承認権限者であるユーザがクライアント端末２（この場合は承認者端末）で入力した承認を示す承認データ、否決を示す否決データは、クライアント端末２から業務管理システム３に送信され（Ｓ２２０）、それを業務管理システム３の承認処理手段１２で受け取る。なおこの際には、承認・否決の対象となった申請データを識別する情報（ジョブ連番など）があわせて送信されている。
【００８０】
承認処理手段１２で承認データまたは否決データを入力処理手段９を介して受け取ると、申請状況管理テーブル５を参照して、この承認、否決データに関する情報（承認・否決データ関連情報、例えばユーザＩＤ、ジョブ連番、承認または否決を示す情報（これは承認データ、否決データに基づいて生成できる。また承認データ、否決データそのものでもよい））を、ワークフローシステム４の承認制御手段１７に渡す（Ｓ２３０）。
【００８１】
承認・否決データ関連情報を業務管理システム３から受け取ったワークフローシステム４の承認制御手段１７は、それが承認を示す情報を含んでいれば、当該ステージ設定テーブルのフォーム番号に基づいて次の承認権限者を判定して、ジョブ管理テーブル１５における現在承認者の欄を、当該判定した次の承認権限者で更新する。
【００８２】
そして当該次の承認権限者に対して、承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【００８３】
この通知を受け取った次の承認権限者に対しても、同様の処理、すなわちＳ２００かＳ２４０までの処理が繰り返される。これを最終承認者から承認を示す情報を受け取るまで反復する（Ｓ２５０）。そして最終承認者から承認を示す情報を受け取ると、承認制御手段１７は、ジョブ管理テーブル１５の承認状態を「承認済み」に更新する（Ｓ２６０）。また、承認制御手段１７は、ユーザＩＤ、ジョブ連番、承認（承認状態を示す情報）を処理完了通知として業務管理システム３に渡す（Ｓ２７０）。なお最終承認者であることは、上述のステージ設定テーブルの承認ルートにおいて、最後の承認権限者であるかどうかを判定することで判定可能である。
【００８４】
なお承認権限者のいずれかにおいて、否決を示す情報を承認・否決データ関連情報で含んでいる場合には、承認制御手段１７は、ジョブ管理テーブル１５の承認状態を「否決」に更新する（Ｓ２６０）。また、承認制御手段１７は、ユーザＩＤ、ジョブ連番、否決（承認状態を示す情報）を処理完了通知として業務管理システム３に渡し（Ｓ２７０）、反復処理が中断される。
【００８５】
ワークフローシステム４から処理完了通知を受け取った業務管理手段の承認処理手段１２は、その処理完了通知に基づいて、承認の場合の処理、または否決の場合の処理を実行する（Ｓ２８０）。
【００８６】
処理完了通知に承認状態を示す情報として「承認」が含まれている場合には、承認処理手段１２は、当該ユーザＩＤとジョブ連番とに基づいて、申請状況管理テーブル５の当該ユーザＩＤとジョブ連番とに対応する承認状態を「承認済」に更新する（Ｓ２９０）。そして、未承認データテーブル６に格納していた当該申請データ（未承認データである申請データ）を、申請状況管理テーブル５の処理連番に基づいて抽出し、それを承認データテーブル７に格納する（Ｓ３００）。
【００８７】
一方、処理完了通知に承認状態を示す情報として「否決」が含まれている場合には、承認処理手段１２は、当該ユーザＩＤとジョブ連番とに基づいて、申請状況管理テーブル５の当該ユーザＩＤとジョブ連番とに対応する承認状態を「否決」に更新する（Ｓ３１０）。そして、未承認データテーブル６に格納していた当該申請データ（未承認データである申請データ）を、申請状況管理テーブル５の処理連番に基づいて抽出し、それを否決・取り下げデータテーブル８に格納する（Ｓ３２０）。
【００８８】
このようにして承認データテーブル７または否決・取り下げデータテーブル８に格納した、未承認データテーブル６に格納していた申請データを、未承認データテーブル６から削除する（Ｓ３３０）。
【００８９】
以上のような処理を行うことで、Ｓ１００乃至Ｓ１８０で申請処理された申請データに対する承認・否決処理が行える。
【００９０】
この承認・否決処理（Ｓ２００乃至Ｓ３３０の処理）を、上述の具体例を用いて説明する。
【００９１】
上述のようにして、ワークフローシステム４のジョブ管理テーブル１５にジョブ連番「１」の新たな申請データ関連情報が格納されると、そのフォーム番号「１」に対応した承認ルート（ステージ設定テーブルに格納された情報）の最初の承認権限者Ａ（ユーザＩＤ「００００２」とする）に対して承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【００９２】
この通知を受け取った最初の承認権限者Ａは、そのクライアント端末２（この場合は承認者端末）で所定の操作を行うことによって、当該承認待ちの申請データを取得する要求をクライアント端末２から業務管理システム３に送信する。
【００９３】
この要求を受け付けると、承認処理手段１２は、ワークフローシステム４に当該取得要求を渡し、それを受け付けたワークフローシステム４の承認制御手段１７が、ジョブ管理テーブル１５を参照することによって、当該承認権限者の承認待ちとなっている申請データのジョブ連番として「１」をジョブ管理テーブル１５から抽出し、そのジョブ連番「１」を承認制御手段１７が業務管理システム３に渡す。
【００９４】
このジョブ連番「１」をワークフローシステム４から受け取った承認処理手段１２は、当該ジョブ連番「１」に基づいて、申請状況管理テーブル５、未承認データテーブル６を参照することで、承認待ちとなっている申請データを抽出し（Ｓ２００）、承認待ちとなっている申請データの一覧画面を生成して出力処理手段１０を介して、それをクライアント端末２に送信する（Ｓ２１０）。
【００９５】
最初の承認権限者であるユーザＡは、そのクライアント端末２に表示された一覧画面では、承認または否決対象とする申請データ（承認待ちとなっている申請データ）はジョブ連番１のデータだけであるので、それを選択すると、それが業務管理システム３の承認処理手段１２に送信される。それに対して、「承認」（承認データ）または「否決」（否決データ）を入力する。ここでは「承認」を入力したとする。
【００９６】
そうすると承認権限者であるユーザＡがクライアント端末２で入力した承認を示す承認データは、クライアント端末２から業務管理システム３に送信され（Ｓ２２０）、それを業務管理システム３の承認処理手段１２で受け取る。
【００９７】
承認処理手段１２で承認データを入力処理手段９を介して受け取ると、申請状況管理テーブル５を参照して、承認・否決データ関連情報として、ユーザＩＤ「００００２」、ジョブ連番「１」、承認を示す情報をワークフローシステム４の承認制御手段１７に渡す。
【００９８】
承認・否決データ関連情報を業務管理システム３から受け取ったワークフローシステム４の承認制御手段１７は、それが承認を示す情報を含んでいれば、当該ステージ設定テーブルのフォーム番号に基づいて次の承認権限者Ｂを判定して、ジョブ管理テーブル１５における現在承認者の欄を、承認権限者Ａから当該判定した次の承認権限者Ｂで更新する。この状態のジョブ管理テーブル１５を模式的に示す概念図が図９（ａ）である。
【００９９】
そして当該次の承認権限者Ｂに対して、承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０１００】
この通知を受け取った次の承認権限者Ｂに対しても、同様の処理、すなわちＳ２００かＳ２４０までの処理が繰り返され、最終の承認権限者Ｃまで同様な処理が繰り返される。ここではすべての承認権限者Ｃで「承認」を示す情報を含む承認・否定データ関連情報を受け取ったとする。
【０１０１】
そうすると、最終承認者Ｃの「承認」を示す情報を含む承認・否定データ関連情報を受け取ると、承認制御手段１７は、ジョブ管理テーブル１５の承認状態を「承認済み」に更新する（Ｓ２６０）。この状態のジョブ管理テーブル１５を模式的に示す概念図が図９（ｂ）である。
【０１０２】
そして承認制御手段１７は、ユーザＩＤ「００００１」、ジョブ連番「１」、「承認済」を処理完了通知として業務管理システム３に渡す。
【０１０３】
ワークフローシステム４から処理完了通知を受け取った業務管理手段の承認処理手段１２は、その処理完了通知から承認または否決を示す情報の判定をすると（Ｓ２８０）、「承認」を示す情報を含んでいるので、承認処理手段１２は、当該ユーザＩＤ「００００１」とジョブ連番「１」とに基づいて、申請状況管理テーブル５の当該ユーザＩＤ「００００１」とジョブ連番「１」とに対応する承認状態を「承認済」に更新する（Ｓ２９０）。そして、未承認データテーブル６に格納していた当該申請データ（未承認データである申請データ）を、申請状況管理テーブル５の処理連番「１」に基づいて抽出し、それを承認データテーブル７に格納する（Ｓ３００）。
【０１０４】
このようにして承認データテーブル７に格納した、未承認データテーブル６に格納していた申請データ（処理連番「１」の申請データ）を、未承認データテーブル６から削除する（Ｓ３３０）。
【０１０５】
この状態の未承認データテーブル６を模式的に示す概念図を図１０（ａ）に、申請状況管理テーブル５を模式的に示す概念図を図１０（ｂ）に、承認データテーブル７を模式的に示す概念図を図１０（ｃ）に示す。
【０１０６】
以上のようにして、Ｓ２００からＳ３３０の申請処理が行える。
【０１０７】
次に、上述のようにして承認された申請データ（承認データ）を変更する変更申請の処理を図４のフローチャートを用いて説明する。
【０１０８】
承認済みデータの変更申請処理を行うユーザ（この場合は申請者）は、クライアント端末２（この場合は申請者端末）を操作して、変更申請処理を開始する画面を起動する。そして所定の操作により、承認済みデータの取得要求をクライアント端末２（この場合は申請者端末）から業務管理システム３に送信する。この際に修正対象となる承認済みデータを抽出できるように、抽出条件も合わせて送信している。
【０１０９】
変更申請処理手段１３は、入力処理手段９を介してクライアント端末２から承認済みデータの抽出条件を受け取り、この抽出条件に基づいて申請状況管理テーブル５を参照し、抽出条件に合致する承認済みデータを承認データテーブル７から抽出する（Ｓ４００）。そして、抽出した承認済みデータから承認済みデータ一覧画面データを生成し、出力処理手段１０を介してクライアント端末２に送信する（Ｓ４１０）。
【０１１０】
クライアント端末２（この場合は申請者端末）ではこの一覧画面を表示し、ユーザ（申請者）により、変更申請処理を開始する承認済みデータの選択が行われる。またこの際に、承認済みデータを変更した後のデータ（変更後データ）の入力を行う。そして、変更申請処理手段１３は、ここで選択した変更申請処理を開始する承認済みデータの選択の情報と変更後データを入力処理手段９を介してクライアント端末２（この場合は申請者端末）で受け付ける（Ｓ４２０）。
【０１１１】
変更申請処理手段１３は、受け付けた変更申請処理を開始する承認済みデータを承認データテーブル７から抽出し、変更前データとして未承認データテーブル６に格納し、それと共に、クライアント端末２から受け付けた変更後データを変更後データとして未承認データテーブル６に格納する（Ｓ４３０）。従って、この時点では変更前データと変更後データの２つのデータが未承認データテーブル６に登録されていることとなる。なお変更後データが削除の場合には、変更後データは「空（ＮＵＬＬ）」となる。
【０１１２】
またこの際に、変更申請処理手段１３は、申請状況管理テーブル５に、受け付けたデータの申請状況を管理するために、当該申請があったことを示す情報、すなわち、処理連番、申請区分、ユーザＩＤなどを格納する。
【０１１３】
変更申請処理手段１３は、これらの変更するデータに関する情報、例えばユーザＩＤ、フォーム番号を、変更関連データとしてワークフローシステム４に渡す（Ｓ４４０）。
【０１１４】
業務管理システム３から変更関連データを受け取ったワークフローシステム４の申請制御手段１６は、上述の図２のフローチャートと同様の処理、すなわち新規の申請処理と同様の処理を実行することで、当該変更関連データに対するジョブ連番を生成し、フォーム番号から承認ルートを判定し、取得したユーザＩＤと承認ルートのユーザＩＤとを比較して、承認状態、現在承認者を判定する。
【０１１５】
なおこの処理は図２のフローチャートの説明と同様であるので省略する（Ｓ４５０乃至Ｓ４７０）。
【０１１６】
以上のようにしてワークフローシステム４から申請受理通知を受け取った業務管理システム３の変更申請処理手段１３は、Ｓ４４０でワークフローシステム４に渡した変更関連データに対応づけて、ジョブ連番と承認状態を申請受理通知に基づいて申請状況管理テーブル５に格納する（Ｓ４８０）。
【０１１７】
この変更申請処理（Ｓ４００乃至Ｓ４８０の処理）を、上述の具体例を用いて説明する。
【０１１８】
承認済みデータの変更申請処理を行うユーザ（ユーザＩＤ「０００１０」）は、クライアント端末２を操作して、変更申請処理を開始する「承認済み伝票修正」の画面を起動する。そして所定の操作により、承認済み伝票である承認済みデータの取得要求をクライアント端末２から業務管理システム３に送信する。この際に変更対象となる承認済みデータを抽出できるように、抽出条件（例えば日付など）も合わせて送信している。
【０１１９】
変更申請処理手段１３は、入力処理手段９を介してクライアント端末２から承認済みデータの抽出条件を受け取り、この抽出条件に基づいて申請状況管理テーブル５を参照し、抽出条件に合致する承認済み伝票の承認済みデータを承認データテーブル７から抽出する（Ｓ４００）。そして、抽出した承認済みデータから承認済みデータ一覧画面データを生成し、出力処理手段１０を介してクライアント端末２に送信する（Ｓ４１０）。
【０１２０】
クライアント端末２ではこの一覧画面を表示し、ユーザ（ユーザＩＤ「０００１０」）により、変更申請処理を開始する承認済みデータの選択が行われる。またこの際に、承認済みデータを変更した後のデータ（変更後データ）の入力を行う。ここでは、処理連番「１」の伝票の金額を「○○○○」から「■■■■」に変更したとする。そして、変更申請処理手段１３は、ここで選択した変更申請処理を開始する承認済みデータの選択の情報（例えば処理連番「１」）と変更後データ（金額「■■■■」）を入力処理手段９を介してクライアント端末２（この場合は申請者端末）で受け付ける（Ｓ４２０）。
【０１２１】
変更申請処理手段１３は、受け付けた変更申請処理を開始する承認済みデータを承認データテーブル７から抽出し、変更前データとして未承認データテーブル６に格納し、それと共に、クライアント端末２から受け付けた変更後データを未承認データテーブル６に格納する（Ｓ４３０）。この状態の未承認データテーブル６を模式的に示す概念図が図１１（ａ）である。
【０１２２】
またこの際に、変更申請処理手段１３は、申請状況管理テーブル５に、受け付けたデータの申請状況を管理するために、当該申請があったことを示す情報、すなわち、処理連番「１」、申請区分「修正」、ユーザＩＤ「０００１０」などを格納する。この状態の申請状況管理テーブル５を模式的に示す概念図が図１１（ｂ）である。
【０１２３】
またこの時点における承認データテーブル７を模式的に示す概念図が図１１（ｃ）である。
【０１２４】
変更申請処理手段１３は、ユーザＩＤ「０００１０」、フォーム番号「１」を、変更関連データとしてワークフローシステム４に渡す（Ｓ４４０）。
【０１２５】
業務管理システム３から変更関連データを受け取ったワークフローシステム４の申請制御手段１６は、上述の図２のフローチャートと同様の処理、すなわち新規の申請処理と同様の処理を実行することで、当該変更関連データに対するジョブ連番「２」を生成し、フォーム番号から承認ルートを判定し、取得したユーザＩＤ「０００１０」と承認ルートのユーザＩＤ（承認権限者ＡのユーザＩＤ）とを比較して、承認状態、現在承認者を判定し、ジョブ管理テーブル１５に格納する。この状態のジョブ管理テーブル１５を模式的に示す図が図１２である。
【０１２６】
なおこの処理は図２のフローチャートの説明と同様であるので省略する（Ｓ４５０乃至Ｓ４７０）。
【０１２７】
以上のようにしてワークフローシステム４から申請受理通知を受け取った業務管理システム３の変更申請処理手段１３は、Ｓ４４０でワークフローシステム４に渡した変更関連データに対応づけて、ジョブ連番「２」と承認状態「申請中」を申請受理通知に基づいて申請状況管理テーブル５に格納する（Ｓ４８０）。この状態を模式的に示す未承認データテーブル６を図１３（ａ）に、申請状況管理テーブル５を図１３（ｂ）に、承認データテーブル７を図１３（ｃ）に示す。
【０１２８】
以上のようにしてワークフローシステム４のジョブ管理テーブル１５に新たな変更後データ関連情報が格納されると、そのフォーム番号に対応した承認ルート（ステージ設定テーブルに格納された情報）の最初の承認権限者に対して承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０１２９】
これによって、上述の図３に示すフローチャートと同様の承認・否決処理が実行される。変更申請処理に対する処理プロセスを示すフローチャートを図１４に示す。なお図１４におけるＳ５００からＳ５８０は、図３のＳ２００からＳ２８０と同様であるので、説明を省略する。なお図１４の場合では変更関連データ、承認待ちの申請データが、承認済みの変更後のデータである。
【０１３０】
Ｓ５８０以降の処理を説明する。
【０１３１】
ワークフローシステム４から処理完了通知を受け取った業務管理手段の承認処理手段１２は、その処理完了通知に基づいて、承認の場合の処理、または否決の場合の処理を実行する（Ｓ５８０）。
【０１３２】
処理完了通知に承認状態を示す情報として「承認」が含まれている場合には、承認処理手段１２は、当該ユーザＩＤとジョブ連番とに基づいて、申請状況管理テーブル５の当該ユーザＩＤとジョブ連番とに対応する承認状態を「承認済」に更新する（Ｓ５９０）。そして、承認データテーブル７から、未承認データテーブル６に格納している変更前の承認済みデータと同一の承認済みデータを削除する（Ｓ６００）。そして未承認データテーブル６に格納していた、変更後データを、申請状況管理テーブル５の処理連番に基づいて抽出し、それを承認データテーブル７に格納する（Ｓ６１０）。
【０１３３】
そして未承認データテーブル６に格納していた、変更前データ（変更前の承認済みデータ）と、変更後データとを未承認データテーブル６から削除する（Ｓ６２０）。
【０１３４】
一方、処理完了通知に承認状態を示す情報として「否決」が含まれている場合には、承認処理手段１２は、当該ユーザＩＤとジョブ連番とに基づいて、申請状況管理テーブル５の当該ユーザＩＤとジョブ連番とに対応する承認状態を「否決」に更新する（Ｓ６３０）。そして未承認データテーブル６に格納していた、変更前データと、変更後データとを未承認データテーブル６から削除する（Ｓ６４０）。
【０１３５】
また変更前データと、変更後データとを、申請状況管理テーブル５の処理連番に基づいて抽出し、否決・取り下げデータテーブル８に格納する（Ｓ６５０）。
【０１３６】
以上のような処理を行うことで、Ｓ４００乃至Ｓ４８０で変更申請処理されたデータに対する承認・否決処理が行える。
【０１３７】
この承認・否決処理（Ｓ５００乃至Ｓ６５０の処理）を、上述の具体例を用いて説明する。
【０１３８】
上述のようにして、ワークフローシステム４のジョブ管理テーブル１５にジョブ連番「２」の変更後データ関連情報が格納されると、そのフォーム番号「１」に対応した承認ルート（ステージ設定テーブルに格納された情報）の最初の承認権限者Ａ（ユーザＩＤ「００００２」）に対して承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０１３９】
この通知を受け取った最初の承認権限者Ａは、そのクライアント端末２で所定の操作を行うことによって、当該承認待ちのデータを取得する要求をクライアント端末２から業務管理システム３に送信する。
【０１４０】
この要求を受け付けると、承認処理手段１２は、ワークフローシステム４に当該取得要求を渡し、それを受け付けたワークフローシステム４の承認制御手段１７が、ジョブ管理テーブル１５を参照することによって、当該承認権限者の承認待ちとなっているデータのジョブ連番として「２」をジョブ管理テーブル１５から抽出し、そのジョブ連番「２」を承認制御手段１７が業務管理システム３に渡す。
【０１４１】
このジョブ連番「２」をワークフローシステム４から受け取った承認処理手段１２は、当該ジョブ連番「２」に基づいて、申請状況管理テーブル５、未承認データテーブル６を参照することで、承認待ちとなっているデータ（変更前データ、変更後データ）を抽出し（Ｓ５００）、承認待ちとなっているデータの一覧画面を生成して出力処理手段１０を介して、それをクライアント端末２に送信する（Ｓ５１０）。
【０１４２】
最初の承認権限者であるユーザＡは、そのクライアント端末２に表示された一覧画面では、承認または否決対象とするデータ（承認待ちとなっているデータ）はジョブ連番２のデータだけであるので、それを選択すると、それが業務管理システム３の承認処理手段１２に送信される。それに対して、「承認」（承認データ）または「否決」（否決データ）を入力する。ここでは「承認」を入力したとする。
【０１４３】
そうすると承認権限者であるユーザＡがクライアント端末２で入力した承認を示す承認データは、クライアント端末２から業務管理システム３に送信され（Ｓ５２０）、それを業務管理システム３の承認処理手段１２で受け取る。
【０１４４】
承認処理手段１２で承認データを入力処理手段９を介して受け取ると、申請状況管理テーブル５を参照して、承認・否決データ関連情報として、ユーザＩＤ「００００２」、ジョブ連番「２」、承認を示す情報をワークフローシステム４の承認制御手段１７に渡す。
【０１４５】
承認・否決データ関連情報を業務管理システム３から受け取ったワークフローシステム４の承認制御手段１７は、それが承認を示す情報を含んでいれば、当該ステージ設定テーブルのフォーム番号に基づいて次の承認権限者Ｂを判定して、ジョブ管理テーブル１５における現在承認者の欄を、承認権限者Ａから当該判定した次の承認権限者Ｂで更新する。この状態のジョブ管理テーブル１５を模式的に示す概念図が図１５（ａ）である。
【０１４６】
そして当該次の承認権限者Ｂに対して、承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０１４７】
この通知を受け取った次の承認権限者Ｂに対しても、同様の処理、すなわちＳ５００かＳ５４０までの処理が繰り返され、最終の承認権限者Ｃまで同様な処理が繰り返される。ここではすべての承認権限者Ｃで「承認」を示す情報を含む承認・否定データ関連情報を受け取ったとする。
【０１４８】
そうすると、最終承認者Ｃの「承認」を示す情報を含む承認・否定データ関連情報を受け取ると、承認制御手段１７は、ジョブ管理テーブル１５の承認状態を「承認済み」に更新する（Ｓ５６０）。この状態のジョブ管理テーブル１５を模式的に示す概念図が図１５（ｂ）である。
【０１４９】
そして承認制御手段１７は、ユーザＩＤ「０００１０」、ジョブ連番「２」、「承認済」を処理完了通知として業務管理システム３に渡す。
【０１５０】
ワークフローシステム４から処理完了通知を受け取った業務管理手段の承認処理手段１２は、その処理完了通知から承認または否決を示す情報の判定をすると（Ｓ５８０）、「承認」を示す情報を含んでいるので、承認処理手段１２は、当該ユーザＩＤ「０００１０」とジョブ連番「２」とに基づいて、申請状況管理テーブル５の当該ユーザＩＤ「０００１０」とジョブ連番「２」とに対応する承認状態を「承認済」に更新する（Ｓ５９０）。
【０１５１】
そして、承認データテーブル７から、未承認データテーブル６に格納している変更前データと同一の承認済みデータ（承認済みの申請データ）を削除する（Ｓ６００）。そして未承認データテーブル６に格納していた、変更後データを、申請状況管理テーブル５の処理連番「１」に基づいて抽出し、それを承認データテーブル７に格納する（Ｓ６２０）。
【０１５２】
そして未承認データテーブル６に格納していた、変更前データと、変更後データとを未承認データテーブル６から削除する（Ｓ６２０）。
【０１５３】
この状態の未承認データテーブル６を模式的に示す概念図を図１６（ａ）に、申請状況管理テーブル５を模式的に示す概念図を図１６（ｂ）に、承認データテーブル７を模式的に示す概念図を図１６（ｃ）に示す。なお図１６では削除をわかりやすくするために、上述とは異なり、削除するデータを二重線で示しているが、実際には各テーブルから削除されている。
【０１５４】
以上のようにして、Ｓ５００からＳ６５０の申請処理が行える。
【０１５５】
なお上述の承認・否決処理において、承認権限者が、変更後データで承認を行った場合、先に承認した申請データではなく、変更後データで承認した場合には実績がどれだけになるのかを知った上で、承認・否決を決定したい場合がある。その場合、承認権限者は、クライアント端末２（この場合は承認者端末）で所定の操作を行うことで、実績出力の要求をクライアント端末２から業務管理システム３に送信する。なおこの要求の際には、変更前データと変更後データとを特定する情報もあわせて送信されていることが好ましい。
【０１５６】
その要求を受け取った実績出力処理手段１４は、未承認データテーブル６と承認データテーブル７とを参照することにより、以下の方法により実績を算出する。
【０１５７】
すなわち、
「承認データテーブル７の金額の合計」−「未承認データテーブル６の取消区分が「変更前」の金額の合計」＋「未承認データテーブル６の取消区分が「変更後」の金額の合計」
を算出する。すなわち承認済の金額の合計を承認データテーブル７を参照することにより算出し、その値から、未承認データテーブル６に格納している「変更前」の承認済みデータの金額の合計を減算し、未承認データテーブル６に格納している「変更後」の変更後データの金額の合計をその値に加算することにより算出する。
【０１５８】
例えば上記例において金額「○○○○」が「１００００」、金額「■■■■」が「２００００」の場合、
「承認データテーブル７の金額の合計」−「未承認データテーブル６の取消区分が「変更前」の金額の合計」＋「未承認データテーブル６の取消区分が「変更後」の金額の合計」は、
１００００−１００００＋２００００＝２００００
となり、変更後データで承認をした場合には、実績として「２００００」となることを実績出力処理手段１４はクライアント端末２に送信する。
【０１５９】
なお承認済みデータ（変更前データ）の実績を算出する場合には、「承認データテーブル７の金額の合計」を実績出力処理手段１４が算出し、それをクライアント端末２に送信すればよい。すなわち上述の場合では「１００００」が承認済みデータの実績として算出できる。
【０１６０】
このように、承認済みデータ（変更前データ）の実績と、変更後データで承認した場合の仮の実績を実績出力処理手段１４が算出することによって、それらを比較した上で、承認権限者が承認、否決の判断を行うことができるようになる。
【実施例２】
【０１６１】
第２の実施例として、Ｓ２００からＳ３３０のようにして承認された申請データ（承認済みデータ）を削除する削除申請処理及びその承認・否決処理の具体例を説明する。なお以下の説明では、各テーブルは、Ｓ３３０の終了状態であるとする。
【０１６２】
承認済みデータの削除申請処理を行うユーザ（ユーザＩＤ「０００１０」）は、クライアント端末２を操作して、削除申請処理を開始する「承認済み伝票削除」の画面を起動する。そして所定の操作により、承認済み伝票である承認済みデータの取得要求をクライアント端末２から業務管理システム３に送信する。この際に削除対象となる承認済みデータを抽出できるように、抽出条件（例えば日付など）も合わせて送信している
【０１６３】
変更申請処理手段１３は、入力処理手段９を介してクライアント端末２から承認済みデータの抽出条件を受け取り、この抽出条件に基づいて申請状況管理テーブル５を参照し、抽出条件に合致する承認済み伝票の承認済みデータを承認データテーブル７から抽出する。そして、抽出した承認済みデータから承認済みデータ一覧画面データを生成し、出力処理手段１０を介してクライアント端末２に送信する。
【０１６４】
クライアント端末２ではこの一覧画面を表示し、ユーザ（ユーザＩＤ「０００１０」）により、削除申請処理を開始する承認済みデータの選択が行われる。この際には、処理連番「１」の仕訳伝票を削除するとする。そして変更申請処理手段１３は、ここで選択した削除申請処理を開始する承認済みデータの選択の情報（例えば処理連番「１」）とユーザＩＤ「０００１０」と申請区分「削除」を入力処理手段９を介してクライアント端末２（この場合は申請者端末）で受け付ける。
【０１６５】
変更申請処理手段１３は、受け付けた削除申請処理を開始する承認済みデータを承認データテーブル７から抽出し、変更前データとして未承認データテーブル６に格納する。上述の承認済みデータの変更申請処理の場合には、変更前データのほかに、変更後データも未承認データテーブル６に格納していたが、今回の処理は削除申請処理なので、変更後データは未承認データテーブル６に格納されない。この状態の未承認データテーブル６を模式的に示す概念図が図１７（ａ）である。
【０１６６】
またこの際に、変更申請処理手段１３は、申請状況管理テーブル５に、受け付けたデータの申請状況を管理するために、当該申請があったことを示す情報、すなわち、処理連番「１」、申請区分「削除」、ユーザＩＤ「０００１０」などを格納する。この状態の申請状況管理テーブル５を模式的に示す概念図が図１７（ｂ）である。
【０１６７】
またこの時点における承認データテーブル７を模式的に示す概念図が図１７（ｃ）である。
【０１６８】
変更申請処理手段１３は、ユーザＩＤ「０００１０」、フォーム番号「１」を、変更関連データとしてワークフローシステム４に渡す。
【０１６９】
業務管理システム３から変更関連データを受け取ったワークフローシステム４の申請制御手段１６は、上述の図２のフローチャートと同様の処理、すなわち新規の申請処理と同様の処理を実行することで、当該変更関連データに対するジョブ連番「２」を生成し、フォーム番号から承認ルートを判定し、取得したユーザＩＤ「０００１０」と承認ルートのユーザＩＤ（承認権限者ＡのユーザＩＤ）とを比較して、承認状態、現在承認者を判定し、ジョブ管理テーブル１５に格納する。この状態のジョブ管理テーブル１５を模式的に示す図が図１８である。
【０１７０】
なおこの処理は図２のフローチャートの説明と同様であるので省略する。
【０１７１】
以上のようにしてワークフローシステム４から申請受理通知を受け取った業務管理システム３の変更申請処理手段１３は、ワークフローシステム４に渡した変更関連データに対応づけて、ジョブ連番「２」と承認状態「申請中」を申請受理通知に基づいて申請状況管理テーブル５に格納する。この状態を模式的に示す未承認データテーブル６を図１９（ａ）に、申請状況管理テーブル５を図１９（ｂ）に、承認データテーブル７を図１９（ｃ）に示す。
【０１７２】
上述のようにして、ワークフローシステム４のジョブ管理テーブル１５にジョブ連番「２」の変更後データ関連情報が格納されると、そのフォーム番号「１」に対応した承認ルート（ステージ設定テーブルに格納された情報）の最初の承認権限者Ａ（ユーザＩＤ「００００２」）に対して承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０１７３】
この通知を受け取った最初の承認権限者Ａは、そのクライアント端末２で所定の操作を行うことによって、当該承認待ちのデータを取得する要求をクライアント端末２から業務管理システム３に送信する。
【０１７４】
この要求を受け付けると、承認処理手段１２は、ワークフローシステム４に当該取得要求を渡し、それを受け付けたワークフローシステム４の承認制御手段１７が、ジョブ管理テーブル１５を参照することによって、当該承認権限者の承認待ちとなっているデータのジョブ連番として「２」をジョブ管理テーブル１５から抽出し、そのジョブ連番「２」を承認制御手段１７が業務管理システム３に渡す。
【０１７５】
このジョブ連番「２」をワークフローシステム４から受け取った承認処理手段１２は、当該ジョブ連番「２」に基づいて、申請状況管理テーブル５、未承認データテーブル６を参照することで、承認待ちとなっているデータ（変更前の承認済みデータ）を抽出し、承認待ちとなっているデータの一覧画面を生成して出力処理手段１０を介して、それをクライアント端末２に送信する。
【０１７６】
最初の承認権限者であるユーザＡは、そのクライアント端末２に表示された一覧画面では、承認または否決対象とするデータ（承認待ちとなっているデータ）はジョブ連番２のデータだけであるので、それを選択すると、それが業務管理システム３の承認処理手段１２に送信される。それに対して、「承認」（承認データ）または「否決」（否決データ）を入力する。ここでは「承認」を入力したとする。
【０１７７】
そうすると承認権限者であるユーザＡがクライアント端末２で入力した承認を示す承認データは、クライアント端末２から業務管理システム３に送信され、それを業務管理システム３の承認処理手段１２で受け取る。
【０１７８】
承認処理手段１２で承認データを入力処理手段９を介して受け取ると、申請状況管理テーブル５を参照して、承認・否決データ関連情報として、ユーザＩＤ「００００２」、ジョブ連番「２」、承認を示す情報をワークフローシステム４の承認制御手段１７に渡す。
【０１７９】
承認・否決データ関連情報を業務管理システム３から受け取ったワークフローシステム４の承認制御手段１７は、それが承認を示す情報を含んでいれば、当該ステージ設定テーブルのフォーム番号に基づいて次の承認権限者Ｂを判定して、ジョブ管理テーブル１５における現在承認者の欄を、承認権限者Ａから当該判定した次の承認権限者Ｂで更新する。この状態のジョブ管理テーブル１５を模式的に示す概念図が図２０（ａ）である。
【０１８０】
そして当該次の承認権限者Ｂに対して、承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０１８１】
この通知を受け取った次の承認権限者Ｂに対しても、同様の処理が繰り返され、最終の承認権限者Ｃまで同様な処理が繰り返される。ここではすべての承認権限者Ｃで「承認」を示す情報を含む承認・否定データ関連情報を受け取ったとする。
【０１８２】
そうすると、最終承認者Ｃの「承認」を示す情報を含む承認・否定データ関連情報を受け取ると、承認制御手段１７は、ジョブ管理テーブル１５の承認状態を「承認済み」に更新する。この状態のジョブ管理テーブル１５を模式的に示す概念図が図２０（ｂ）である。
【０１８３】
そして承認制御手段１７は、ユーザＩＤ「０００１０」、ジョブ連番「２」、「承認済」を処理完了通知として業務管理システム３に渡す。
【０１８４】
ワークフローシステム４から処理完了通知を受け取った業務管理手段の承認処理手段１２は、その処理完了通知から承認または否決を示す情報の判定をすると、「承認」を示す情報を含んでいるので、承認処理手段１２は、当該ユーザＩＤ「０００１０」とジョブ連番「２」とに基づいて、申請状況管理テーブル５の当該ユーザＩＤ「０００１０」とジョブ連番「２」とに対応する承認状態を「承認済」に更新する。
【０１８５】
そして、承認データテーブル７から、未承認データテーブル６に格納している変更前の承認済みデータと同一の承認済みデータを削除する。
【０１８６】
そして未承認データテーブル６に格納していた、変更前の承認済みデータを未承認データテーブル６から削除する。
【０１８７】
この状態の未承認データテーブル６を模式的に示す概念図を図２１（ａ）に、申請状況管理テーブル５を模式的に示す概念図を図２１（ｂ）に、承認データテーブル７を模式的に示す概念図を図２１（ｃ）に示す。なお図２１では削除をわかりやすくするために、上述とは異なり、削除するデータを二重線で示しているが、実際には各テーブルから削除されている。
【実施例３】
【０１８８】
第３の実施例として、Ｓ２００からＳ３３０のようにして承認されたマスタを変更する変更申請処理を行う場合の具体例を説明する。なお以下の説明では、各テーブルは、Ｓ３３０の終了状態であるとする。なお本実施例では承認済みのマスタに対する変更申請処理を行う場合となる。
【０１８９】
承認済みのマスタにおけるデータの変更申請処理を行うユーザ（ユーザＩＤ「０００１０」）は、クライアント端末２を操作して、変更申請処理を開始する「承認済みマスタ修正」の画面を起動する。そして所定の操作により、承認済みデータの取得要求をクライアント端末２から業務管理システム３に送信する。この際に変更対象となる承認済みデータを抽出できるように、抽出条件（例えば日付など）も合わせて送信している。
【０１９０】
変更申請処理手段１３は、入力処理手段９を介してクライアント端末２から承認済みデータの抽出条件を受け取り、この抽出条件に基づいて申請状況管理テーブル５を参照し、抽出条件に合致する承認済みデータを承認データテーブル７から抽出する。そして、抽出した承認済みデータから承認済みデータ一覧画面データを生成し、出力処理手段１０を介してクライアント端末２に送信する。
【０１９１】
クライアント端末２ではこの一覧画面を表示し、ユーザ（ユーザＩＤ「０００１０」）により、変更申請処理を開始する承認済みデータの選択が行われる。またこの際に、承認済みデータを変更した後のデータ（変更後データ）の入力を行う。ここでは、得意先マスタの得意先コード「１」の得意先名を「○○○○」から「■■■■」に変更したとする。そして、変更申請処理手段１３は、ここで選択した変更申請処理を開始する承認済みデータの選択の情報（例えば得意先コード「１」）と変更後データ（得意先名「■■■■」）を入力処理手段９を介してクライアント端末２（この場合は申請者端末）で受け付ける。
【０１９２】
変更申請処理手段１３は、受け付けた変更申請処理を開始する承認済みデータを承認データテーブル７から抽出し、変更前データとして未承認データテーブル６に格納し、それと共に、クライアント端末２から受け付けた変更後データを未承認データテーブル６に格納する。この状態の未承認データテーブル６を模式的に示す概念図が図２２（ａ）である。
【０１９３】
またこの際に、変更申請処理手段１３は、申請状況管理テーブル５に、受け付けたデータの申請状況を管理するために、当該申請があったことを示す情報、すなわち、得意先コード「１」、申請区分「修正」、ユーザＩＤ「０００１０」などを格納する。この状態の申請状況管理テーブル５を模式的に示す概念図が図２２（ｂ）である。
【０１９４】
またこの時点における承認データテーブル７を模式的に示す概念図が図２２（ｃ）であり、フォーム設定テーブルの一例を模式的に示す概念図が図２２（ｄ）である。
【０１９５】
変更申請処理手段１３は、ユーザＩＤ「０００１０」、フォーム番号「１」を、変更関連データとしてワークフローシステム４に渡す。
【０１９６】
業務管理システム３から変更関連データを受け取ったワークフローシステム４の申請制御手段１６は、上述の図２のフローチャートと同様の処理、すなわち新規の申請処理と同様の処理を実行することで、当該変更関連データに対するジョブ連番「２」を生成し、フォーム番号から承認ルートを判定し、取得したユーザＩＤ「０００１０」と承認ルートのユーザＩＤ（承認権限者ＡのユーザＩＤ）とを比較して、承認状態、現在承認者を判定し、ジョブ管理テーブル１５に格納する。この状態のジョブ管理テーブル１５を模式的に示す図が図２３である。
【０１９７】
なおこの処理は図２のフローチャートの説明と同様であるので省略する。
【０１９８】
以上のようにしてワークフローシステム４から申請受理通知を受け取った業務管理システム３の変更申請処理手段１３は、ワークフローシステム４に渡した変更関連データに対応づけて、ジョブ連番「２」と承認状態「申請中」を申請受理通知に基づいて申請状況管理テーブル５に格納する。この状態を模式的に示す未承認データテーブル６を図２４（ａ）に、申請状況管理テーブル５を図２４（ｂ）に、承認データテーブル７を図２４（ｃ）に示す。
【０１９９】
上述のようにして、ワークフローシステム４のジョブ管理テーブル１５にジョブ連番「２」の変更後データ関連情報が格納されると、そのフォーム番号「１」に対応した承認ルート（ステージ設定テーブルに格納された情報）の最初の承認権限者Ａ（ユーザＩＤ「００００２」）に対して承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０２００】
この通知を受け取った最初の承認権限者Ａは、そのクライアント端末２で所定の操作を行うことによって、当該承認待ちのデータを取得する要求をクライアント端末２から業務管理システム３に送信する。
【０２０１】
この要求を受け付けると、承認処理手段１２は、ワークフローシステム４に当該取得要求を渡し、それを受け付けたワークフローシステム４の承認制御手段１７が、ジョブ管理テーブル１５を参照することによって、当該承認権限者の承認待ちとなっているデータのジョブ連番として「２」をジョブ管理テーブル１５から抽出し、そのジョブ連番「２」を承認制御手段１７が業務管理システム３に渡す。
【０２０２】
このジョブ連番「２」をワークフローシステム４から受け取った承認処理手段１２は、当該ジョブ連番「２」に基づいて、申請状況管理テーブル５、未承認データテーブル６を参照することで、承認待ちとなっているデータ（変更前の承認済みマスタ、変更後のマスタ）を抽出し、承認待ちとなっているデータの一覧画面を生成して出力処理手段１０を介して、それをクライアント端末２に送信する。
【０２０３】
最初の承認権限者であるユーザＡは、そのクライアント端末２に表示された一覧画面では、承認または否決対象とするマスタのデータ（承認待ちとなっているデータ）はジョブ連番２のデータだけであるので、それを選択すると、それが業務管理システム３の承認処理手段１２に送信される。それに対して、「承認」（承認データ）または「否決」（否決データ）を入力する。ここでは「承認」を入力したとする。
【０２０４】
そうすると承認権限者であるユーザＡがクライアント端末２で入力した承認を示す承認データは、クライアント端末２から業務管理システム３に送信され、それを業務管理システム３の承認処理手段１２で受け取る。
【０２０５】
承認処理手段１２で承認データを入力処理手段９を介して受け取ると、申請状況管理テーブル５を参照して、承認・否決データ関連情報として、ユーザＩＤ「００００２」、ジョブ連番「２」、承認を示す情報をワークフローシステム４の承認制御手段１７に渡す。
【０２０６】
承認・否決データ関連情報を業務管理システム３から受け取ったワークフローシステム４の承認制御手段１７は、それが承認を示す情報を含んでいれば、当該ステージ設定テーブルのフォーム番号に基づいて次の承認権限者Ｂを判定して、ジョブ管理テーブル１５における現在承認者の欄を、承認権限者Ａから当該判定した次の承認権限者Ｂで更新する。この状態のジョブ管理テーブル１５を模式的に示す概念図が図２５（ａ）である。
【０２０７】
そして当該次の承認権限者Ｂに対して、承認待ちの申請データがあることを示す承認待ち通知をワークフローシステム４の承認制御手段１７が送信する。
【０２０８】
この通知を受け取った次の承認権限者Ｂに対しても、同様の処理が繰り返され、最終の承認権限者Ｃまで同様な処理が繰り返される。ここではすべての承認権限者Ｃで「承認」を示す情報を含む承認・否定データ関連情報を受け取ったとする。
【０２０９】
そうすると、最終承認者Ｃの「承認」を示す情報を含む承認・否定データ関連情報を受け取ると、承認制御手段１７は、ジョブ管理テーブル１５の承認状態を「承認済み」に更新する。この状態のジョブ管理テーブル１５を模式的に示す概念図が図２５（ｂ）である。
【０２１０】
そして承認制御手段１７は、ユーザＩＤ「０００１０」、ジョブ連番「２」、「承認済」を処理完了通知として業務管理システム３に渡す。
【０２１１】
ワークフローシステム４から処理完了通知を受け取った業務管理手段の承認処理手段１２は、その処理完了通知から承認または否決を示す情報の判定をすると、「承認」を示す情報を含んでいるので、承認処理手段１２は、当該ユーザＩＤ「０００１０」とジョブ連番「２」とに基づいて、申請状況管理テーブル５の当該ユーザＩＤ「０００１０」とジョブ連番「２」とに対応する承認状態を「承認済」に更新する。
【０２１２】
そして、今回は承認済みマスタが処理対象となっていることから、未承認データテーブル６の変更前のデータと変更後のデータを比較し、相違する項目のデータを抽出する。そうすると得意先名が異なることを判定できるので、取消区分が「変更後」であるデータの相違する項目、すなわち得意先名を抽出し、承認済みデータテーブルのデータにおいて、対応する項目、すなわち得意先名を書き換える。その後、未承認データテーブル６の変更前のデータと変更後のデータとを削除する。
【０２１３】
この状態の未承認データテーブル６を模式的に示す概念図を図２６（ａ）に、申請状況管理テーブル５を模式的に示す概念図を図２６（ｂ）に、承認データテーブル７を模式的に示す概念図を図２６（ｃ）に示す。なお図２６では削除をわかりやすくするために、上述とは異なり、削除するデータを二重線で示しているが、実際には各テーブルから削除されている。
【０２１４】
なお本実施例では単なるデータに対する処理ではなく、マスタに対する処理である。マスタではこのような申請・承認途中での項目の変更があり得るが、本実施例の方法を用いることによって、マスタデータを削除せず、変更した項目のみを書き換えるようにしているため、そのような正当な変更状態を保持することが可能となる。
【産業上の利用可能性】
【０２１５】
本発明の統合業務システム１によって、業務に関するデータは業務管理システム３のみで取り扱い、ワークフローシステム４では管理しない構成となるので、従来のように業務管理システム３とワークフローシステム４の双方でデータ管理しなくてすむこととなる。そのため、データ修正等の際に煩雑さを解消することができる。また、新たな修正した申請が行われた場合に、未承認のデータに基づいた実績を見ることができるので、承認権限者が新たな修正した申請の際に、その申請を仮に承認したら従来とどのように変わるのか、の変化を把握した上で承認・否決の行為を行うことが可能となる。
【図面の簡単な説明】
【０２１６】
【図１】本発明の統合業務システム１のシステム構成の全体を示す概念図である。
【図２】申請処理の一例を示すフローチャートである。
【図３】承認・否決処理の一例を示すフローチャートである。
【図４】変更申請処理の一例を示すフローチャートである。
【図５】申請処理における未承認データテーブル６、申請状況管理テーブル５、フォーム設定テーブルの一例を示す概念図である。
【図６】申請処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図７】ステージ設定テーブルの一例を示す概念図である。
【図８】申請処理における未承認データテーブル６、申請状況管理テーブル５の一例を示す概念図である。
【図９】承認・否決処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図１０】承認・否決処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図１１】変更申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図１２】変更申請処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図１３】変更申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図１４】変更申請時の承認・否決処理の一例を示すフローチャートである。
【図１５】変更申請時の承認・否決処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図１６】変更申請時の承認・否決処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図１７】実施例２の削除申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図１８】実施例２の削除申請処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図１９】実施例２の削除申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図２０】実施例２の削除申請時の承認・否決処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図２１】実施例２の削除申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図２２】実施例３の承認済みマスタの変更申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７、フォーム設定テーブルの一例を示す概念図である。
【図２３】実施例３の承認済みマスタの変更申請処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図２４】実施例３の承認済みマスタの変更申請処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【図２５】実施例３の承認済みマスタの変更申請時の承認・否決処理におけるジョブ管理テーブル１５の一例を示す概念図である。
【図２６】実施例３の承認済みマスタの変更申請時の承認・否決処理における未承認データテーブル６、申請状況管理テーブル５、承認データテーブル７の一例を示す概念図である。
【符号の説明】
【０２１７】
１：統合業務システム
２：クライアント端末
３：業務管理システム
４：ワークフローシステム
５：申請状況管理テーブル
６：未承認データテーブル
７：承認データテーブル
８：否決・取り下げデータテーブル
９：入力処理手段
１０：出力処理手段
１１：申請処理手段
１２：承認処理手段
１３：変更申請処理手段
１４：実績出力処理手段
１５：ジョブ管理テーブル
１６：申請制御手段
１７：承認制御手段
【図１】
2008310773.tif 000003
【図２】
2008310773.tif 000004
【図３】
2008310773.tif 000005
【図４】
2008310773.tif 000006
【図５】
2008310773.tif 000007
【図６】
2008310773.tif 000008
【図７】
2008310773.tif 000009
【図８】
2008310773.tif 000010
【図９】
2008310773.tif 000011
【図１０】
2008310773.tif 000012
【図１１】
2008310773.tif 000013
【図１２】
2008310773.tif 000014
【図１３】
2008310773.tif 000015
【図１４】
2008310773.tif 000016
【図１５】
2008310773.tif 000017
【図１６】
2008310773.tif 000018
【図１７】
2008310773.tif 000019
【図１８】
2008310773.tif 000020
【図１９】
2008310773.tif 000021
【図２０】
2008310773.tif 000022
【図２１】
2008310773.tif 000023
【図２２】
2008310773.tif 000024
【図２３】
2008310773.tif 000025
【図２４】
2008310773.tif 000026
【図２５】
2008310773.tif 000027
【図２６】
2008310773.tif 000028