(57)【要約】  【課題】  修正時の承認手続きを簡略化する。  【解決手段】  修正データを受けると、サーバは承認基準マスタに設定されている承認不要条件と比較して、再承認が必要か否か判断する（ステップＳ７３）。再承認不要条件に合致する場合には、履歴に追記し（ステップＳ９１）、再承認不要の通知画面が生成され、送信対象とされる（ステップＳ９３）。これが送信されると、被承認端末はこれを表示する。再承認不要条件に合致する場合には、承認処理（ステップＳ７５）を行わないことにより、些細な修正であれば、修正時の承認手続きが簡略化できる。  【選択図】  図１３
2005242796.tif 000002
【特許請求の範囲】
【請求項１】
被承認端末と承認端末と処理サーバとを備えた承認処理システムであって、
Ａ）前記処理サーバは、以下のａ１）〜ａ６）を備え、
ａ１）データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信する問い合わせ手段、
ａ２）前記問い合わせデータに対する返答を前記承認端末から受け取る返答受領手段、
ａ３）前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理手段、
ａ４）前記申請データについて、再承認要となる許容差分を記憶する許容差分記憶手段、
ａ５）与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段に記憶する再承認要否判断手段、
ａ６）前記被承認端末からの要求を受けると、その被承認端末に承認済み画面を送信する送信手段、
Ｂ）前記被承認端末は、操作者がデータ識別子が付与された申請データを入力すると、前記サーバに与え、前記サーバの前記送信手段に前記承認済み画面を送信させる要求を与え、
Ｃ）前記承認端末は、前記サーバから問い合わせデータが与えられると、これを表示し、操作者が返答を入力すると、これをサーバに返答すること、
を特徴とする承認処理システム。
【請求項２】
被承認端末および承認端末とネットワーク接続される承認処理サーバであって、
ａ１）データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信する問い合わせ手段、
ａ２）前記問い合わせデータに対する返答を前記承認端末から受け取る返答受領手段、
ａ３）前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理手段、
ａ４）前記申請データについて、再承認要となる許容差分を記憶する許容差分記憶手段、
ａ５）与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段に記憶する再承認要否判断手段、
を備えたことを特徴とする承認処理サーバ。
【請求項３】
請求項２の承認処理サーバにおいて、
前記申請データは、複数の項目で構成されており、
前記許容差分記憶手段は、前記許容差分を項目ごとに記憶しており、
前記再承認要否判断手段は、前記許容差分が設定されている全項目について、前記与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分を越えない場合には再承認不要データとして前記既承認データ記憶手段に記憶すること、
を特徴とするもの。
【請求項４】
請求項２の承認処理サーバにおいて、
前記ネットワーク接続される承認端末は複数であり、
前記問い合わせ手段は、各承認端末ごとに承認が必要か否を決定するための承認要否判断基準データおよびその問い合わせ順を記憶しており、与えられた申請データについて前記承認要否判断基準データに基づき、承認が必要な承認端末を決定して、前記問い合わせ順に承認端末に問い合わせデータを送信する承認処理サーバであって、
与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、
前記再承認要否判断手段は、前記与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えている場合には、前記承認を行った承認端末の承認要否判断基準データと前記与えられた申請データとを比較し、再度の承認が必要な承認端末を決定し、
前記問い合わせ手段は、前記承認要否判断基準データにかかわらず、前記再度の承認が必要と判断された承認端末に前記問い合わせデータを送信すること、
を特徴とするもの。
【請求項５】
被承認端末および承認端末とネットワーク接続される承認処理サーバであって、
データ識別子が付与された申請データであって前記被承認端末から金額を含む申請データが与えられると、前記承認端末に問い合わせデータとして送信する問い合わせ手段、
前記問い合わせデータに対する返答を前記承認端末から受け取る返答受領手段、
前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理手段、
申請データについて、再承認要となる許容差分を記憶する許容差分記憶手段、
を備えた承認処理サーバにおいて、
新たに与えられた申請データが、既に承認済みの承認済みデータの修正であるか否か判断し、修正である場合には、前記与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段に記憶する再承認要否判断手段、
を備えたことを特徴とする承認処理サーバ。
【請求項６】
請求項２の承認処理サーバにおいて、
前記再承認要否判断手段は、新たに与えられた申請データのデータ識別子と一致するデータ識別子の申請データについて、再承認不要データとしての記憶が存在する場合でも、前記許容差分を越えていないかの判断は、一旦承認された既承認申請データと比較すること、
を特徴とするもの。
【請求項７】
被承認端末および承認端末と承認処理サーバをネットワーク接続した承認処理方法であって、
前記承認処理サーバは、以下の処理を実行すること、
Ａ）少なくとも金額を含み、データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信し、
Ｂ）前記承認端末から前記問い合わせデータに対する返答を受け取ると、前記返答の内容が承認済みであるか否か判断し、
Ｃ）承認済みである場合には、前記被承認端末からの要求を受け、または要求無しに、その被承認端末に承認済み画面を送信し、
Ｄ）前記申請データについて、再承認要となる許容差分を記憶しており、与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、前記与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には再承認不要データとして記憶する、
を特徴とする承認処理方法。
【請求項８】
コンピュータを被承認端末および承認端末とネットワーク接続される承認処理サーバとして機能させるためのプログラムであって、以下のステップを備えたこと、
Ａ）少なくとも金額を含み、データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信するステップ、
Ｂ）前記承認端末から前記問い合わせデータに対する返答を受け取ると、前記返答の内容が承認済みであるか否か判断するステップ、
Ｃ）承認済みである場合には、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理ステップ、
Ｄ）前記申請データについて、再承認要となる許容差分を記憶しており、与えられた申請データのデータ識別子と一致するデータ識別子の既承認済みの既承認データが前記既承認データ記憶手段に記憶されている場合には、前記与えられたこの申請データと既に既承認申請データとの差分が、前記記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には再承認不要データとして記憶する再承認要否判断ステップ、
を特徴とするコンピュータ可読のプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、コンピュータを用いた電子承認装置に関し、特に、承認手続きの簡略化に関する。
【背景技術】
【０００２】
特許文献１には、稟議書をネットワーク上で回覧して承認をする際の回覧順序を予め決めておき、全て回覧者の承認が与えられた場合にはこれを承認する電子決裁装置が開示されている。
【０００３】
【特許文献１】特開２００２−２４４９９号
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、かかる装置では、ある条件で全回覧者に回覧し、最終的に承認された場合でも、その後の交渉によって変更条件が提示される場合があるという問題があった。たとえば、Ａ社から、あるコンピュータシステムｘを１０００万で受注する件について、全回覧者に承認がなされたとして、その後、Ａ社から購入条件の変更申し出がなされる場合がある。
【０００５】
このような場合、上記装置においては、全ての案件について再承認のために回付がなされるので、承認を行う側にとってはほんの少しの変更であるような場合でも、再度、承認手続きが必要となり、煩雑である。
【０００６】
かかる問題は、購入条件の金額の変更だけではなく、取引における条件一般においても、同様に問題となる。
【０００７】
この発明は、取引における取引条件の再承認処理を迅速に処理する取引条件承認方法および、かかる方法を実現するための装置を提供することを目的とする。
【課題を解決するための手段】
【０００８】
１）本発明にかかる承認処理システムは、被承認端末と承認端末と処理サーバとを備えた承認処理システムであって、前記処理サーバは、以下のａ１）〜ａ６）を備えている。ａ１）データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信する問い合わせ手段、ａ２）前記問い合わせデータに対する返答を前記承認端末から受け取る返答受領手段、ａ３）前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理手段、ａ４）前記申請データについて、再承認要となる許容差分を記憶する許容差分記憶手段、ａ５）与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段に記憶する再承認要否判断手段、ａ６）前記被承認端末からの要求を受けると、その被承認端末に承認済み画面を送信する送信手段。また、前記被承認端末は、操作者がデータ識別子が付与された申請データを入力すると、前記サーバに与え、前記サーバの前記送信手段に前記承認済み画面を送信させる要求を与える。また、前記承認端末は、前記サーバから問い合わせデータが与えられると、これを表示し、操作者が返答を入力すると、これをサーバに返答する。
【０００９】
このように、与えられたこの申請データと既に既承認申請データとの差分が前記許容差分を越えない場合には再承認不要データとして処理することにより、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを判断することができる。したがって、これを被承認端末から閲覧することにより、些細な変更である場合には、再承認処理をとることなく、迅速に承認をえることができる。
【００１０】
２）本発明にかかる承認処理サーバは、被承認端末および承認端末とネットワーク接続される承認処理サーバであって、ａ１）データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信する問い合わせ手段、ａ２）前記問い合わせデータに対する返答を前記承認端末から受け取る返答受領手段、ａ３）前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理手段、ａ４）前記申請データについて、再承認要となる許容差分を記憶する許容差分記憶手段、ａ５）与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段に記憶する再承認要否判断手段を備えている。
【００１１】
このように、与えられたこの申請データと既に既承認申請データとの差分が前記許容差分を越えない場合には再承認不要データとして処理することにより、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを判断することができる。したがって、これを被承認端末から閲覧することにより、些細な変更である場合には、再承認処理をとることなく、迅速に承認をえることができる。
【００１２】
３）本発明にかかる承認処理サーバは、前記申請データは、複数の項目で構成されており、前記許容差分記憶手段は、前記許容差分を項目ごとに記憶しており、前記再承認要否判断手段は、前記許容差分が設定されている全項目について、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分を越えない場合には再承認不要データとして前記既承認データ記憶手段に記憶する。したがって、複数の項目で公正された申請データについて、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを判断することができる。
【００１３】
４）本発明にかかる承認処理サーバは、前記ネットワーク接続される承認端末は複数であり、前記問い合わせ手段は、各承認端末ごとに承認が必要か否を決定するための承認要否判断基準データおよびその問い合わせ順を記憶しており、与えられた申請データについて前記承認要否判断基準データに基づき、承認が必要な承認端末を決定して、前記問い合わせ順に承認端末に問い合わせデータを送信する承認処理サーバであって、与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、前記再承認要否判断手段は、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えている場合には、前記承認を行った承認端末の承認要否判断基準データと前記与えられた申請データとを比較し、再度の承認が必要な承認端末を決定し、前記問い合わせ手段は、前記承認要否判断基準データにかかわらず、前記再度の承認が必要と判断された承認端末に前記問い合わせデータを送信する。したがって、承認端末が複数ある場合でも、前記承認要否判断基準データおよびその問い合わせ順にもとづいて、順次承認処理が可能であり、また、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを判断することができる。
【００１４】
５）本発明にかかる承認処理サーバは、被承認端末および承認端末とネットワーク接続される承認処理サーバであって、Ａ）データ識別子が付与された申請データであって前記被承認端末から金額を含む申請データが与えられると、前記承認端末に問い合わせデータとして送信する問い合わせ手段、Ｂ）前記問い合わせデータに対する返答を前記承認端末から受け取る返答受領手段、Ｃ）前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理手段、Ｄ）申請データについて、再承認要となる許容差分を記憶する許容差分記憶手段、Ｅ）新たに与えられた申請データが、既に承認済みの承認済みデータの修正であるか否か判断し、修正である場合には、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段に記憶する再承認要否判断手段を備えている。
【００１５】
このように、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分を越えない場合には承認済みとして処理することにより、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを判断することができる。したがって、これを被承認端末から閲覧することにより、些細な変更である場合には、再承認処理をとることなく、迅速に承認をえることができる。
【００１６】
６）本発明にかかる承認処理サーバにおいては、前記再承認要否判断手段は、新たに与えられた申請データのデータ識別子と一致するデータ識別子の申請データについて、再承認不要データとしての記憶が存在する場合でも、前記許容差分を越えていないかの判断は、一旦承認された既承認申請データと比較する。このように、再承認不要データとしての記憶が存在しても、前記許容差分の比較は既承認データとおこなうことにより、累積的な差分が存在する場合でも、前記許容差分を越えると、再承認処理をおこなうことができる。
【００１７】
７）本発明にかかる承認処理方法は、被承認端末および承認端末と承認処理サーバをネットワーク接続した承認処理方法であって、前記承認処理サーバは、以下の処理を実行する。Ａ）データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信し、Ｂ）前記承認端末から前記問い合わせデータに対する返答を受け取ると、前記返答の内容が承認済みであるか否か判断し、Ｃ）承認済みである場合には、前記被承認端末からの要求を受け、または要求無しに、その被承認端末に承認済み画面を送信し、Ｄ）前記申請データについて、再承認要となる許容差分を記憶しており、与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、与えられたこの申請データと既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には再承認不要データとして記憶する。
【００１８】
このように、与えられたこの申請データと既に既承認申請データとの差分が前記許容差分を越えない場合には再承認不要データとして処理することにより、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを前記被承認端末に報知することができる。
【００１９】
８）本発明にかかるプログラムは、コンピュータを、被承認端末および承認端末とネットワーク接続される承認処理サーバとして機能させるためのプログラムであって、以下のステップを備えている。Ａ）少なくとも金額を含み、データ識別子が付与された申請データが前記被承認端末から与えられると、前記承認端末に問い合わせデータとして送信するステップ、Ｂ）前記承認端末から前記問い合わせデータに対する返答を受け取ると、前記返答の内容が承認済みであるか否か判断するステップ、Ｃ）承認済みである場合には、前記被承認端末が閲覧ができる状態で既承認データ記憶手段に記憶する既承認データ処理ステップ、Ｄ）前記申請データについて、再承認要となる許容差分を記憶しており、与えられた申請データのデータ識別子と一致するデータ識別子の既承認済みの既承認データが前記既承認データ記憶手段に記憶されている場合には、前記与えられた申請データについて、このデータ識別子が一致する既承認申請データとの差分が、前記記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には再承認不要データとして記憶する再承認要否判断ステップ。
【００２０】
このように、申請データと既に承認済みの承認済みデータとの差分が前記許容差分を越えない場合には再承認不要として処理することにより、一旦承認済みの前記既承認データに基づいて、再承認が不要か否かを判断することができる。したがって、これを被承認端末から閲覧することにより、些細な変更である場合には、再承認処理をとることなく、迅速に承認をえることができる。
【００２１】
なお、本明細書において「データ識別子」とは、申請データを他の申請データと区別する識別子であり、実施形態では、件名番号が該当する。また、「申請データ」とは、実施形態では、被承認端末から与えられる申請対象の件名データが該当する。また、「与えられたこの申請データと既に既承認申請データとの差分」とは、与えられたこの申請データが既に既承認申請データとの関係で、どのような差分が存在するかを表すものであればどのようなものであってもよく、実施形態では、受注金額修正幅、粗利率および他社仕入率の修正幅が該当する。
【発明を実施するための最良の形態】
【００２２】
１．機能ブロック図の説明
本発明の一実施形態を図面に基づいて説明する。
【００２３】
承認処理システム１は、複数の被承認端末（承認要求者端末）２ａ〜２ｎと複数の承認端末３ａ〜３ｎ（承認者端末）とサーバコンピュータ（以下サーバという）４とを備えている。サーバ４は、問い合わせ手段５、返答受領手段７、既承認データ処理手段９、既承認データ記憶手段１１、許容差分記憶手段１３、再承認要否判断手段１５および送信手段１７を備えている。
【００２４】
問い合わせ手段５は、データ識別子が付与された申請データであって被承認端末２ａ〜２ｎから金額を含む申請データが与えられると、承認端末３ａ〜３ｎに問い合わせデータとして送信する。返答受領手段７は、前記問い合わせデータに対する返答を前記承認端末から受け取る。既承認データ処理手段９は、前記返答の内容が承認済みである場合には、前記申請データを既承認データとして、問い合わせをした被承認端末が閲覧ができる状態で既承認データ記憶手段１１に記憶する。許容差分記憶手段１３は前記申請データについて、再承認要となる許容差分を記憶する。再承認要否判断手段１５は、与えられた申請データのデータ識別子と一致するデータ識別子が、前記既承認データ記憶手段に存在する場合には、新たに与えられた申請データについて、既に既承認申請データとの差分が、前記許容差分記憶手段に記憶されている許容差分を越えていないかを判断し、前記許容差分を越えない場合には前記問い合わせ手段にこの申請データを与えることなく再承認不要データとして前記既承認データ記憶手段１１に記憶する。
【００２５】
送信手段１７は、被承認端末からの要求を受け、または要求無しに、その被承認端末に承認済み画面を送信する。
【００２６】
２．サーバのハードウェア構成
図１に示すサーバのハードウェア構成について、図２を用いて説明する。図２は、サーバ４をＣＰＵを用いて構成したハードウェア構成の一例である。
【００２７】
サーバ４は、ＣＰＵ２３、メモリ２７、ハードディスク２６、モニタ３０、ＣＤＤ（ＣＤＲＯＭドライブ）２５、入力デバイス２８、通信ボード３２およびバスライン２９を備えている。ＣＰＵ２３は、ハードディスク２６に記憶された各プログラムにしたがいバスライン２９を介して、各部を制御する。なお、オペレーティングシステムとしては、例えば、Ｌｉｎｕｘ（商標）等を採用すればよい。
【００２８】
ハードディスク２６には、オペレーティングプログラム（ＯＳ）２６o、承認プログラム２６ｋ、マスタファイル２６ｍ、および履歴データ２６rを記憶する。
【００２９】
マスターファイル２６mには、図３〜図６に示す回付パターンマスター、回付基準マスター、承認基準マスター、件名マスターなどの各種のマスターファイルが記憶されている。
【００３０】
回付パターンマスターには、回付先を決定するための基準が記憶されている。この場合、図３に示すように、件名の形態が「請負」か「物品」かで、回付ルートが異なる。なお、本実施形態において、「物品」とはエアコン１００台というような物品のみの取引をいい、「請負」とはエアコン１００台という物品のみの取引に加えて、これを据え付ける工事を含めた請負工事が付加された取引をいう。したがって件名の形態が「物品」の場合には、エンジニアリング担当は回付先にはしていない。
【００３１】
回付基準マスターには各承認端末ごとに、承認が必要な条件を記憶している。これは、回付ルートに該当する承認端末であっても、金額や粗利率などの値によっては、承認を必要としない場合もありうるからである。このマスターに基づいて承認が必要な承認端末と判断されれば、当該承認端末には後述する承認要求がなされる。この実施形態では、各部所ごとに受注金額と粗利率と他社仕入れ率とを記憶しておき、これらのいずれかが許容条件を越える場合には、承認必要の端末であると判断するようにした。具体的には、たとえば、図４において、「営業チームリーダー」や「経理担当」は、受注金額が５０万円なので、少額の場合でも回付されることとなる。これに対して、「営業ジェネラルマネージャー」については、受注金額１０００万円以上か、粗利率８％以下か、または他社仕入率３０％以上のいずれかに該当する場合にだけ、回付先として設定される。
【００３２】
承認基準マスターには、全ての承認端末について共通の条件であり、最初の承認の際に承認が必要か否かの条件、および、一旦承認がなされた案件について修正がなされた場合に、所定の許容値を越えない程度であれば、再承認を行わないと判断するための条件として用いられる。本実施形態においては、図５に示すように、承認基準マスターには６つの項目を採用した。また、この例では、最初の承認の際には、項目「受注金額」、「粗利率」、「他社仕入率」が判断基準として用いられ、再承認の場合には、項目「受注金額修正幅」、「粗利率修正幅」、「他社仕入率修正幅」を判断基準として用いた。具体的な判断については後述する。
【００３３】
件名マスターには、図６に示すように、件名ごとに、件名番号、件名名称、件名形態、顧客ＩＤ等が記憶されている。
【００３４】
図２に示す承認プログラム２６ｋ、履歴データ２６ｒについては後述する。
【００３５】
なお、上記プログラムは、ＣＤＤ２５を介して、プログラムが記憶されたＣＤＲＯＭ２５ａから読み出されてハードディスク２６にインストールされたものである。なお、ＣＤＲＯＭ以外に、フレキシブルディスク（ＦＤ）、ＩＣカード等のプログラムをコンピュータ可読の記録媒体から、ハードディスクにインストールさせるようにしてもよい。さらに、通信回線を用いてダウンロードするようにしてもよい。
【００３６】
本実施形態においては、プログラムをＣＤＲＯＭからハードディスク２６にインストールさせることにより、ＣＤＲＯＭに記憶させたプログラムを間接的にコンピュータに実行させるようにしている。しかし、これに限定されることなく、ＣＤＲＯＭに記憶させたプログラムをＣＤＤ２５から直接的に実行するようにしてもよい。なお、コンピュータによって、実行可能なプログラムとしては、そのままのインストールするだけで直接実行可能なものはもちろん、一旦他の形態等に変換が必要なもの（例えば、データ圧縮されているものを、解凍する等）、さらには、他のモジュール部分と組合して実行可能なものも含む。
【００３７】
３．端末のハードウェア構成
図１に示す被承認端末のハードウェア構成について図７を用いて説明する。被承認端末は、サーバ４とハードウェア構成はほぼ同じである。また、ハードディスク１２６には、ブラウザプログラム１２６bを有する。承認端末のハードウェア構成は被承認端末とほぼ同様であるので、説明は省略する。
【００３８】
４．フローチャート
つぎに、被承認端末と承認端末とサーバ４間における承認処理について図８を用いて説明する。以下では、被承認端末２ａの操作者である「ユーザ１」が、件名形態「請負件名」、件名番号「００１」、件名形態「請負件名」、件名名称「××○」、顧客ＩＤ「○○×」との顧客との間で、受注金額「1,000,000円」、粗利率「10％」、他社仕入率「20％」で一旦承認され、その後、条件が変更される場合について説明する。また、被承認端末と承認端末では、それぞれ、ブラウザプログラムが起動しているものとする。
【００３９】
操作者は、被承認端末２ａにて新規入力画面を要求する（図８ステップＳ１）。被承認端末２ａは、サーバ４に、新規入力画面要求を送信する（ステップＳ３）。サーバ４はかかる要求を受けて、件名登録の画面を送信する（ステップＳ５）。なお、件名登録の画面については、予め生成して記憶しておけばよい。
【００４０】
被承認端末２ａは受信した画面データを表示する（ステップＳ７）。被承認端末２ａの操作者は、かかる画面にて、件名番号、名称、顧客ＩＤ、顧客名称、受注金額、粗利率、および他社仕入率などを入力し（ステップＳ９）、画面上に表示された登録ボタンを入力デバイスでクリックすると、被承認端末２ａは、入力されたデータを送信する（ステップＳ１１）。ここでは、件名形態「請負件名」、履歴「一時受注」、件名番号「００１」、件名名称「××○」、顧客ＩＤ「○○×」、受注金額「1,000,000円」、粗利率「10％」、他社仕入率「20％」が入力されたものとする。
【００４１】
サーバ４は、与えられたデータを記憶する。この場合、件名番号「００１」、件名形態「請負件名」、件名名称「××○」、顧客ＩＤ「○○×」、申請者「ユーザ１」、申請日「2002/07/08」が件名マスタに、件名番号「００１」、件名形態「請負件名」、履歴「一時受注」、受注金額「1,000,000円」、粗利率「10％」、他社仕入率「20％」が履歴データに記憶される。記憶後の件名マスタのデータ構造を図６に、記憶後の履歴データのデータ構造を図９Ａにそれぞれ示す。この場合、申請について何ら処理がなされていないのでサーバ４は申請状態は「申請中」として記憶する。
【００４２】
サーバ４は、与えられたデータに基づき、承認基準マスタを参照して承認処理が必要か否か判断する（ステップＳ１３）。
【００４３】
承認基準マスターには、既に説明したように、所定の許容値を越えない程度であれば、承認を不要とするための条件が記憶されている。本実施形態においては、申請データが、図５に示す３つの項目、「受注金額」、「粗利率」および「他社仕入れ率」について、範囲内である場合には、承認を不要と判断し、いずれかでも範囲を超える場合には承認必要と判断するようにした。この場合、与えられた申請データは、「受注金額」、「粗利率」および「他社仕入れ率」が、それぞれ、「１００万円」、「１０％」、「２０％」である。したがって、受注金額、他社仕入率が、図５に示す許容囲を超えている。これにより、サーバ４は承認必要と判断し、承認処理をおこなう（ステップＳ１４）。
【００４４】
承認処理の詳細を図１０を用いて説明する。サーバは、回付パターンマスタを参照して、回付パターンを決定する（図１０ステップＳ３１）。本実施形態においては、件名形態によって２種類としている。この場合、件名形態は「請負件名」であるので、回付先候補としては、営業チームリーダ→営業ジェネラルマネージャー→エンジニアリング→経理担当→経理チームリーダ→事業場長が特定される。
【００４５】
つぎに、サーバは回付基準マスタを参照して、回付先を決定する（図１０ステップＳ３３）。具体的には、決定された回付先候補のうち、回付すべきか否かを決定する回付基準と、与えられたデータを比較して、回付する必要がない場合を除き、回付先とする。たとえば、この例では、受注金額「1,000,000円」、粗利率「10％」、他社仕入率「20％」である（図４参照）。営業チームリーダは、受注金額５０万円以上か、または、粗利率10％以下か、他社仕入率20％以上のいずれかである場合には、回付対象とするようにしている。したがって、この場合、回付先とする。同様にして、エンジニアリング、および経理担当が回付先とされ、営業ジェネラルマネージャー、経理チームリーダおよび事業場長については基準を超えていないので、回付先とされない。サーバ４は、処理番号ｉを初期化し（ステップＳ３５）、ｉ番目の承認者に要承認案件があることを通知する（ステップＳ３７）。本実施形態においては、各承認者の端末のメニュー画面にて、承認要求案件があることを示すポップアップ表示をおこない各承認者に報知し、各承認者がかかるポップアップ表示を選択すると、図１１に示すような画面を表示するようにした。
【００４６】
ｉ番目の承認端末（この場合、営業チームリーダの端末）では、かかる通知を受けて、営業チームリーダが承認案件のデータを要求する命令を入力する（ステップＳ３９）。この場合、領域６１を選択すると、この承認端末はサーバへ問いあわせ命令を送信する（図１０ステップＳ４１）。
【００４７】
サーバ４は、承認用データに基づいて、画面を生成し、生成した画面データを送信する（ステップＳ４３）。具体的には、件名マスターおよび履歴データから、件名番号「００１」、件名形態「請負件名」、件名名称「××○」、顧客ＩＤ「○○×」、履歴「一次受注」、受注金額「1,000,000円」、粗利率「10％」、他社仕入率「20％」を抽出して、図１２に示すような画面を生成して、営業チームリーダの承認端末に送信する。かかる画面については共通する部分（枠など）は予め生成しておき、変動する部分のみ、値を入力し画面を生成すればよい。
【００４８】
営業チームリーダの承認端末は、かかる画面データを受けて、表示する（図１０ステップＳ４５）。営業チームリーダは、これを見て、申請について承認する場合には承認ボタン５５を、承認しない場合には否認ボタン５７をクリックする（ステップＳ４７）。承認端末は、入力されたボタンに対応するデータをサーバ４に送信する（ステップＳ４９）。
【００４９】
サーバ４はこれを受けて、承認を承認する「承認」で返信された場合には、ｉ番目の承認端末が最終承認端末（決裁端末）であるか否か判断する（ステップＳ５３）。最終であるか否かは、ステップＳ３３にて決定した回付先の最終回付先かに基づいて判断すればよい。
【００５０】
この場合、最終承認端末ではないので、処理番号ｉをインクリメントし（ステップＳ５５）、つぎの承認者に対して、ステップＳ３７以下の処理を行う。
【００５１】
これを繰り返し最終承認端末まで承認を得ると、ステップＳ５３からステップＳ５７に進み、全て承認済みとされる（ステップＳ５７）。
【００５２】
また、いずれかの承認端末から否認が与えられると、ステップＳ５１からステップＳ５９に進み、申請は否認とされる（ステップＳ５９）。これによりサーバ４における承認処理は終了する。
【００５３】
サーバ４は、申請について全て承認済みか否か判断し（図８ステップＳ１５）、承認済みの場合は、申請状態として承認済みであることを履歴データに追記する（ステップＳ２１）。かかる処理後における履歴データのデータ構造を図９Ｂに示す。
【００５４】
サーバ４は承認があったことを示す承認画面を生成し、送信対象とし（図８ステップＳ２３）、これを送信する（ステップＳ２５）。被承認端末ではこの承認画面を表示する（ステップＳ２７）。
【００５５】
また、サーバ４は、図８ステップＳ１５にて、申請について否認であると判断した場合は、申請に対して承認不可であることを履歴データに追記する（ステップＳ１７）。サーバ４は否認があることを示す否認画面を生成し、送信対象とし（ステップＳ１９）、これを送信する（ステップＳ２５）。被承認端末ではこの否認画面を表示する（ステップＳ２７）。
【００５６】
このようにして、承認処理が終了する。
【００５７】
なお、図８ステップＳ１３にて、承認不要と判断した場合には、サーバ４は、承認不要であることを示す通知画面を生成し、送信対象とし（図８ステップＳ２４）、これを送信する（ステップＳ２５）。被承認端末ではこの承認不要画面が表示される（ステップＳ２６）。
【００５８】
つぎに、一旦承認がなされたあと、一部修正された場合の処理について、図１３を用いて説明する。以下では、件名番号「００１」について、受注金額「1,050,000円」、粗利率「9.5％」に変更される場合について説明する。
【００５９】
被承認端末２ａは件名番号「００１」の件名について、データを修正する画面である修正画面を要求する命令を与える（図１３ステップＳ６１）。被承認端末２ａは、サーバ４に、修正画面要求を送信する（ステップＳ６３）。サーバ４はかかる要求を受けて、図１４に示すような件名修正の画面を生成して送信する（ステップ６５）。被承認端末２ａは受信した画面データを表示する（ステップＳ６７）。
【００６０】
被承認端末２ａの操作者は修正データとして受注金額「1,050,000円」、粗利率「9.5％」を入力し、登録ボタン５９をクリックする（ステップＳ６９）。これにより、サーバ４は、件名番号「００１」の申請について、修正データとして受注金額「1,050,000円」、粗利率「9.5％」を記憶し（ステップＳ７２）、承認基準マスタを参照して、再承認が必要か否か判断する（ステップＳ７３）。
【００６１】
承認基準マスターには、既に説明したように、所定の許容値を越えない程度であれば、再承認を行わないと判断するための条件が記憶されている。この場合、図５に示す３つの項目（修正幅）の許容値以内の修正であれば、再承認のための回付がなされない。
【００６２】
この場合、項目「受注金額修正幅」、「粗利率修正幅」および「他社仕入れ率修正幅」については、修正データと履歴データとの差分を演算することにより判断することができる。具体的には、項目「受注金額修正幅」、「粗利率修正幅」および「他社仕入れ率修正幅」は、それぞれ、「５万円」、「０．５％」、「０％」である。したがって、いずれも図５に示す許容値内である。これにより、サーバ４は再承認不要と判断し、履歴データの承認の申請状態は再承認不要として履歴データに追記する（ステップＳ９１）。かかる処理後における履歴データのデータ構造を図９Ｃに示す。サーバ４は、再承認不要であることを示す通知画面を生成し、送信対象とし（図１３ステップＳ９３）、これを送信する（ステップＳ８３）。被承認端末ではこの承認画面が表示される（ステップＳ８９）。
【００６３】
つぎに、再度一部修正された場合の処理について図１３を用いて説明する。以下では、件名番号「００１」について、受注金額「1,120,000円」に変更される場合について説明する。
【００６４】
被承認端末２ａは件名番号「００１」の件名について、データを修正する画面である修正画面を要求する命令を与える（図１３ステップＳ６１）。被承認端末２ａは、サーバ４に、修正画面要求を送信する（ステップＳ６３）。サーバ４はかかる要求を受けて、件名修正の画面を生成して送信する（ステップ６５）。被承認端末２ａは受信した画面データを表示する（ステップＳ６７）。
【００６５】
被承認端末２ａの操作者は修正データとして受注金額「1,120,000円」を入力し、登録ボタンをクリックする（ステップＳ６９）。これにより、サーバ４は、件名番号「００１」の申請について、修正データとして受注金額「1,120,000円」を記憶する（ステップＳ７２）。この場合、入力のない項目については現在の値がそのまま引き継がれる。かかる処理後における履歴データのデータ構造を図９Ｃに示す。
【００６６】
サーバ４は、承認基準マスタを参照して、再承認が必要か否か判断する（図１３ステップＳ７３）。この場合、項目「受注金額修正幅」、「粗利率修正幅」および「他社仕入れ率修正幅」は、再承認不要のデータではなく、承認済みのデータとの差分を演算する。具体的には、受注金額は１１２万円−１００万円＝１２万円が「受注金額修正幅」となり、「粗利率修正幅」は、０．５％となる。図５に示す承認基準マスタでは、受注修正幅は１０万なので、これを越えていると判断し、承認処理をおこなう（ステップＳ７５）。
【００６７】
承認処理については既に説明したので説明は省略する。ここでは、全承認権限者がこの申請について承認したとする。サーバ４は、申請中の承認が承認済みであることを履歴データに追記する（ステップＳ７９）かかる処理後における履歴データのデータ構造を図９Ｄに示す。
【００６８】
つぎに、サーバ４は、承認があったことを示す承認画面を生成し、送信対象とし（ステップＳ８１）、これを送信する（ステップＳ８３）。被承認端末ではこの承認画面を表示する（ステップＳ８９）。
【００６９】
本実施形態においては、最初の承認の際には、回付先候補について、絶対値で回付先とするか否か決定し、一旦承認がなされた案件について、修正があった場合には、修正後の条件が既に承認した条件との相対割合に基づいて、再承認処理が必要か否かを判断している。したがって、一旦承認した条件からある範囲の変化しかない場合には再承認処理が不要となる。
【００７０】
なお、ステップＳ７７にて承認がなされなかった場合、少なくとも１の回付先が非承認であった場合、これを履歴に追加し（ステップＳ８５）、非承認画面を生成して送信対象とする（ステップＳ８７）。ＣＰＵはこれを送信し（ステップＳ８３）、被承認端末ではこの承認画面が表示される（ステップＳ８９）。
【００７１】
このように、本実施形態においては、各項目について、既に承認された値との差分データに基づいて、再承認が必要か否かを判断するようにした。したがって、一旦承認済みのデータに基づいて、再承認が不要か否かを判断することができる。したがって、これを被承認端末から閲覧することにより、些細な変更である場合には、再承認処理をとることなく、迅速に処理を進めることができる。
【００７２】
また、前記差分を演算するのは、履歴として再承認不要データが存在する場合でも、再承認不要データではなく既承認データである。このように、あくまでも、既承認データとの差分を演算することにより、累積的な変更であっても、設定されている許容値を超えた場合には、承認処理をすることができる。
【００７３】
また、再承認が必要か否かを判断については、既承認値との差分データで行い、いずれの端末を回付先とするかについては、新たに与えられた申請値の値を用いている。このように、再承認必要か否かの判断基準を相対値で、必要な場合の回付先の判断基準を絶対値でおこなうことにより、多面的な条件設定が可能となる。
【００７４】
５．他の実施形態
上記実施形態においては、被承認端末および承認端末で表示される画面を、サーバで全て生成して、被承認端末および承認端末ではかかる画面データを受け取り、ブラウザプログラムで表示するようにした。しかし、これに限定されず、被承認端末および承認端末に専用プログラムを記憶させておき、専用プログラムに対して、サーバからデータを送り、これに基づいて表示させる画面を生成するようにしてもよい。
【００７５】
また、再承認が不要な場合の条件として、受注金額とその修正幅、粗利率とその修正幅、および他社仕入率とその修正幅を採用したが、これに限定されるわけではない。
【００７６】
また、本実施形態においては、差分値として、一旦承認が成立した場合の値との差分を採用したが、一旦承認が成立した場合の値と相対的な差分が分かるものであればどのようなものであってもよく、たとえば、一旦承認が成立した場合の値における割合それ自体であってもよい。この場合、たとえば、粗利率であれば、変更後承認が不要な粗利率の割合を記憶しておけばよい。
【００７７】
また、本実施形態においては、粗利率および他社仕入率を申請者が入力するようにしたが、別途必要な部品の個数などから自動的に粗利益を演算して、受注金額との関係で粗利率を演算させてもよい。他社仕入率についても同様である。
【００７８】
本実施形態においては、各承認者への報知は、メニュー画面におけるポップアップ表示を用いたが、これに限定されず、たとえば、各承認者に対して、承認要求案件があることを示すメールを送信するようにしてもよい。そして、かかるメール中に図１１に示すような画像ファイルが記憶されたＵＲＬを記述しておけばよい。
【００７９】
上記実施形態においては、最初の承認の際には、項目「受注金額」、「粗利率」、「他社仕入率」を、再承認の場合には、項目「受注金額修正幅」、「粗利率修正幅」、「他社仕入率修正幅」を判断基準として用いた。しかし、再承認の際にも、前記修正幅だけでなく、修正後の値である「受注金額」、「粗利率」、「他社仕入率」を、判断基準として採用するようにしてもよい。
【００８０】
また、なお、上記実施形態においては、１回目（既承認データがない場合）も、承認基準マスタ（図５参照）を用いるようにしたが、１回目は、かかるマスターを用いることなく、かならず、承認処理をおこなう用にしてもよい。
【００８１】
なお、上記実施形態においては、修正時に変更のない項目については入力しないようにしたが、変更がない項目であっても、入力させるようにしてもよい。
【００８２】
また、本実施形態においては、一旦承認された値との相対的な差分だけで再承認が必要か否かを判断するようにしたが、各条件における絶対値も再承認必要か否かの条件としてもよい。これにより、より詳細な条件設定が可能となる。
【００８３】
また、本実施形態においては、回付先が複数ある場合について説明したが、承認担当者が１つである場合も同様に適用することができる。
【００８４】
本実施形態においては、図１に示す機能を実現する為に、ＣＰＵを用い、ソフトウェアによってこれを実現している。しかし、その一部もしくは全てを、ロジック回路等のハードウェアによって実現してもよい。
【００８５】
なお、プログラムの一部の処理をオペレーティングシステム（ＯＳ）にさせるようにしてもよい。
【図面の簡単な説明】
【００８６】
【図１】本発明にかかるシステムの機能ブロック図である。
【図２】図２に示すサーバ４をＣＰＵを用いて実現したハードウエア構成の一例を示す図である。
【図３】回付パターンマスターのデータ構造を示す。
【図４】回付基準マスターのデータ構造を示す。
【図５】承認基準マスターのデータ構造を示す。
【図６】被承認端末をＣＰＵを用いて実現したハードウエア構成の一例を示す図である。
【図７】件名マスターのデータ構造を示す。
【図８】被承認端末とサーバ４との間の承認処理のフローチャートである。
【図９】履歴データのデータ構造を示す。
【図１０】サーバと承認端末との間の承認処理のフローチャートである。
【図１１】要承認案件があることを通知する画面の一例である。
【図１２】承認／非承認画面の一例である。
【図１３】集成時における、被承認端末とサーバ４との間の承認処理のフローチャートである。
【図１４】集成画面の一例である。
【符号の説明】
【００８７】
２３・・・ＣＰＵ
２７・・・メモリ
１２３・・・ＣＰＵ
１２７・・・メモリ
【図１】
2005242796.tif 000003
【図２】
2005242796.tif 000004
【図３】
2005242796.tif 000005
【図４】
2005242796.tif 000006
【図５】
2005242796.tif 000007
【図６】
2005242796.tif 000008
【図７】
2005242796.tif 000009
【図８】
2005242796.tif 000010
【図９】
2005242796.tif 000011
【図１０】
2005242796.tif 000012
【図１１】
2005242796.tif 000013
【図１２】
2005242796.tif 000014
【図１３】
2005242796.tif 000015
【図１４】
2005242796.tif 000016