特開 2023-93954 稟議申請確認装置、稟議申請確認方法および稟議申請確認プログラム

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公開特許公報(A)

(11)【公開番号】P2023093954

(43)【公開日】2023-07-05

(54)【発明の名称】稟議申請確認装置、稟議申請確認方法および稟議申請確認プログラム

(51)【国際特許分類】

   G06Q 10/0633 20230101AFI20230628BHJP

【ＦＩ】

G06Q10/06 324

【審査請求】未請求

【請求項の数】7

【出願形態】ＯＬ

(21)【出願番号】P 2021209108

(22)【出願日】2021-12-23

(71)【出願人】

【識別番号】398040527

【氏名又は名称】株式会社オービック

(74)【代理人】

【識別番号】110002147

【氏名又は名称】弁理士法人酒井国際特許事務所

(72)【発明者】

【氏名】河原 宏俊

(72)【発明者】

【氏名】松林 憲一

(72)【発明者】

【氏名】上野 剛光

【テーマコード（参考）】

5L049

【Ｆターム（参考）】

5L049AA07

(57)【要約】      （修正有）

【課題】システム上に伝票を登録する場合に、取引毎に稟議申請の要否の確認作業の効率化を図ることができる稟議申請確認装置、稟議申請確認方法及び稟議申請確認プログラムを提供する。
【解決手段】稟議申請確認装置１００において、取得部１０２ａは、モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額及び伝票粗利金額を含む入力情報を取得する。判定部１０２ｂは、稟議申請条件マスタおよび取引別ワークフロー種別マスタを参照し、入力情報における伝票売上金額および伝票粗利金額の少なくとも一方が閾値以上であるか否かを判定する。表示制御部１０２ｃは、伝票売上金額および伝票粗利金額の少なくとも一方が閾値以上である場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージをモニタに表示させる。
【選択図】図１

【特許請求の範囲】

【請求項1】

制御部を備える稟議申請確認装置であって、
事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けた稟議申請条件マスタと、
データ区分および取引区分毎に、比較対象のワークフロー申請種別を対応付けた取引別ワークフロー種別マスタと、
にアクセス可能であり、
前記制御部は、
モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額および伝票粗利金額を含む入力情報を取得する取得部と、
前記稟議申請条件マスタおよび前記取引別ワークフロー種別マスタを参照し、前記入力情報における前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であるか否かを判定する判定部と、
前記判定部が前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であると判定した場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージを前記モニタに表示させる表示制御部と、
を備えること、
を特徴とする稟議申請確認装置。

【請求項2】

請求項１に記載の稟議申請確認装置であって、
前記ワークフロー申請番号毎に、前記ワークフロー申請種別と、申請事業所、申請内容および承認ステータスを対応付けたワークフロー申請データにさらにアクセス可能であり、
前記判定部は、
前記ワークフロー申請データを参照し、入力される前記ワークフロー申請番号に基づいて、前記ワークフロー申請種別、前記申請事業所および前記承認ステータスの各々が正しいか否かを判定する、
稟議申請確認装置。

【請求項3】

請求項２に記載の稟議申請確認装置であって、
前記表示制御部は、
前記判定部によって前記ワークフロー申請種別、前記申請事業所および前記承認ステータスのいずれか一つ以上が正しくないと判定された場合、前記ワークフロー申請種別、前記申請事業所および前記承認ステータスのいずれか一つ以上の入力が正しくないとことを示す警告を前記モニタに表示させる、
稟議申請確認装置。

【請求項4】

請求項１～３のいずれか一つに記載の稟議申請確認装置であって、
前記稟議申請条件マスタは、
前記判定時の動作として、前記ワークフロー申請番号の未入力の状態で前記入力情報に応じた伝票を起票して登録する動作と、前記ワークフロー申請番号を入力させて前記ワークフロー申請番号に応じた確認を行った後に前記入力情報に応じた伝票を起票して登録する動作と、を示す申請チェック要否フラグをさらに含み、
前記表示制御部は、
前記申請チェック要否フラグの状態に応じて、前記ワークフロー申請番号の入力を指示する指示信号の入力を受け付ける第１のアイコンおよび前記ワークフロー申請番号の未入力の状態で起票する指示信号の入力を受け付ける第２のアイコンを前記モニタに表示させる、
稟議申請確認装置。

【請求項5】

請求項１～４のいずれか一つに記載の稟議申請確認装置であって、
前記制御部は、
前記判定部によって前記伝票売上金額および前記伝票粗利金額が前記閾値以上でないと判定された場合、前記入力情報に応じた伝票を起票して登録する登録部をさらに備える、
稟議申請確認装置。

【請求項6】

制御部を備える稟議申請確認装置で実行される稟議申請確認方法であって、
事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けた稟議申請条件マスタと、
データ区分および取引区分毎に、比較対象のワークフロー申請種別を対応付けた取引別ワークフロー種別マスタと、
にアクセス可能であり、
前記制御部で実行される、
モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額および伝票粗利金額を含む入力情報を取得する取得ステップと、
前記稟議申請条件マスタおよび前記取引別ワークフロー種別マスタを参照し、前記入力情報における前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であるか否かを判定する判定ステップと、
前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であると判定された場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージを前記モニタに表示させる表示制御ステップと、
を含むこと、
を特徴とする稟議申請確認方法。

【請求項7】

制御部を備える稟議申請確認装置で実行される稟議申請確認プログラムであって、
事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けた稟議申請条件マスタと、
データ区分および取引区分毎に、比較対象のワークフロー申請種別を対応付けた取引別ワークフロー種別マスタと、
にアクセス可能であり、
前記制御部で実行されるための、
モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額および伝票粗利金額を含む入力情報を取得する取得ステップと、
前記稟議申請条件マスタおよび前記取引別ワークフロー種別マスタを参照し、前記入力情報における前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であるか否かを判定する判定ステップと、
前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であると判定された場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージを前記モニタに表示させる表示制御ステップと、
を含むこと、
を特徴とする稟議申請確認プログラム。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、稟議申請確認装置、稟議申請確認方法および稟議申請確認プログラムに関する。

【背景技術】

【0002】

特許文献１には、購買申請のあった申請データの稟議内容で承認を得るための承認処理を行い、最終承認の得られた申請データの稟議内容に基づいて発注した商品の入荷があると検品を行う稟議ワークフロー発注装置に関する技術が開示されている。

【先行技術文献】

【特許文献】

【0003】

【特許文献1】特許第６８９３５７０号公報

【発明の概要】

【発明が解決しようとする課題】

【0004】

ところで、システム上に伝票を登録する場合には、取引の内容によっては予め稟議申請を起票して承認を得る必要がある場合がある。しかしながら、稟議申請は、基幹システム外で行われていることが多いうえ、全ての取引で必要となることがない。

【0005】

このため、システム上に伝票を登録するユーザは、登録した伝票が正しく稟議申請が行われている伝票であるか否かの確認作業を行わなければならず、確認作業が非常に煩雑なものとなるという問題点があった。

【0006】

本発明は、上記に鑑みてなされたものであって、システム上に伝票を登録する場合に、取引毎に稟議申請の要否の確認作業の効率化を図ることができる稟議申請確認装置、稟議申請確認方法および稟議申請確認プログラムを提供することを目的とする。

【課題を解決するための手段】

【0007】

上述した課題を解決し、目的を達成するために、本発明に係る稟議申請確認装置は、制御部を備える稟議申請確認装置であって、事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けた稟議申請条件マスタと、データ区分および取引区分毎に、比較対象のワークフロー申請種別を対応付けた取引別ワークフロー種別マスタと、にアクセス可能であり、前記制御部は、モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額および伝票粗利金額を含む入力情報を取得する取得部と、前記稟議申請条件マスタおよび前記取引別ワークフロー種別マスタを参照し、前記入力情報における前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であるか否かを判定する判定部と、前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上である場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージを前記モニタに表示させる表示制御部と、を備えること、を特徴とする。

【0008】

また、本発明に係る稟議申請確認方法は、制御部を備える稟議申請確認装置で実行される稟議申請確認方法であって、事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けた稟議申請条件マスタと、データ区分および取引区分毎に、比較対象のワークフロー申請種別を対応付けた取引別ワークフロー種別マスタと、にアクセス可能であり、前記制御部は、モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額および伝票粗利金額を含む入力情報を取得する取得ステップと、前記稟議申請条件マスタおよび前記取引別ワークフロー種別マスタを参照し、前記入力情報における前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であるか否かを判定する判定ステップと、前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上である場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージを前記モニタに表示させる表示制御ステップと、を含むこと、を特徴とする。

【0009】

また、本発明に係る稟議申請確認プログラムは、制御部を備える稟議申請確認装置で実行される稟議申請確認プログラムであって、事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けた稟議申請条件マスタと、データ区分および取引区分毎に、比較対象のワークフロー申請種別を対応付けた取引別ワークフロー種別マスタと、にアクセス可能であり、前記制御部は、モニタに表示される入力画面において入力される事業者、取引区分、伝票売上金額および伝票粗利金額を含む入力情報を取得する取得ステップと、前記稟議申請条件マスタおよび前記取引別ワークフロー種別マスタを参照し、前記入力情報における前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上であるか否かを判定する判定ステップと、前記伝票売上金額および前記伝票粗利金額の少なくとも一方が前記閾値以上である場合、ワークフローにおいて稟議申請を行った際のワークフロー申請番号の入力を促すメッセージを前記モニタに表示させる表示制御ステップと、を含むこと、を特徴とする。

【発明の効果】

【0010】

本発明によれば、システム上に伝票を登録する場合に、取引毎に稟議申請の要否の確認作業の効率化を図ることができるという効果を奏する。

【図面の簡単な説明】

【0011】

【図1】図１は、実施形態に係る稟議申請確認装置の構成の一例を示すブロック図での概要を示す模式図である。

【図2】図２は、実施形態に係る稟議申請確認装置の記憶部が記憶する稟議申請条件マスタにおける稟議申請条件マスタテーブルの一例を示す図である。

【図3】図３は、実施形態に係る稟議申請確認装置の記憶部が記憶する取引別ＷＦ種別マスタにおける取引別ＷＦ種別テーブルの一例を示す図である。

【図4】図４は、実施形態に係る稟議申請確認装置の記憶部が記憶するＷＦ申請データにおけるＷＦ申請データテーブルの一例を示す図である。

【図5】図５は、実施形態に係る稟議申請確認装置が実行する処理のデータ遷移の概要を示す図である。

【図6】図６は、実施形態に係る稟議申請確認装置が実行する処理の概要を示すフローチャートである。

【図7】図７は、実施形態に係る稟議申請確認装置が備えるモニタが表示する入力画面の一例を示す図である。

【図8】図８は、実施形態に係る稟議申請確認装置が備えるモニタが表示する受注入力画面にユーザが入力した入力後の状態を示す図である。

【図9】図９は、実施形態に係る稟議申請確認装置の表示制御部がモニタに表示させるメッセージの一例を示す図である。

【図10】図１０は、実施形態に係る稟議申請確認装置の表示制御部がモニタに表示させるメッセージの別の一例を示す図である。

【図11】図１１は、ＷＦ申請番号が入力された状態の一例を示す図である。

【図12】図１２は、別のＷＦ申請番号が入力された状態の一例を示す図である。

【図13】図１３は、稟議申請における経費入力の概要を説明する図である。

【図14】図１４は、稟議申請における経費入力の概要を説明する図である。

【発明を実施するための形態】

【0012】

以下に、本発明に係る稟議申請確認装置、債権管理方法および債権管理プログラムの実施形態を、図面に基づいて詳細に説明する。なお、本実施形態により本発明が限定されるものではない。

【0013】

［１．構成］
本実施形態に係る稟議申請確認装置の構成の一例について、図１等を参照して説明する。図１は、稟議申請確認装置の構成の一例を示すブロック図での概要を示す模式図である。

【0014】

図１に示す稟議申請確認装置１００は、市販のデスクトップ型パーソナルコンピュータである。なお、稟議申請確認装置１００は、デスクトップ型パーソナルコンピュータのような据置型情報処理装置に限らず、市販されているノート型パーソナルコンピュータ、ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）、スマートフォン、タブレット型パーソナルコンピュータなどの携帯型情報処理装置であってもよい。

【0015】

稟議申請確認装置１００は、制御部１０２と、通信インターフェース部１０４と、記憶部１０６と、入出力インターフェース部１０８と、を備えている。稟議申請確認装置１００が備えている各部は、任意の通信路を介して通信可能に接続されている。

【0016】

通信インターフェース部１０４は、ルータ等の通信装置および専用線等の有線または無線の通信回線を介して、稟議申請確認装置１００をネットワーク３００に通信可能に接続する。通信インターフェース部１０４は、他の装置と、通信回線と、を介してデータを通信する機能を有する。ここで、ネットワーク３００は、稟議申請確認装置１００と、サーバ２００と、を相互に通信可能に接続する機能を有し、例えばインターネットやＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）等である。なお、記憶部１０６に格納されるデータは、例えばサーバ２００に格納されてもよい。

【0017】

入出力インターフェース部１０８には、入力装置１１２と、出力装置１１４と、が接続されている。出力装置１１４には、モニタ（家庭用テレビを含む）の他、スピーカやプリンタを用いることができる。入力装置１１２には、キーボード、マウス、およびマイクの他、マウスと協働してポインティングデバイス機能を実現するモニタを用いることができる。なお、以下では、出力装置１１４をモニタ１１４とし、入力装置１１２をキーボード１１２またはマウス１１２として記載する場合がある。

【0018】

記憶部１０６には、各種のデータベース、テーブルおよびファイルなどが格納される。記憶部１０６には、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）と協働してＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）に命令を与えて各種処理を行うためのコンピュータプログラムが記憶される。記憶部１０６として、例えば、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）・ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）等のメモリ装置、ハードディスクのような固定ディスク装置、フレキシブルディスク、および光ディスク等を用いることができる。記憶部１０６は、稟議申請条件マスタ１０６ａと、取引別ワークフロー種別マスタ１０６ｂ（以下、単に「取引別ＷＦ種別マスタ１０６ｂ」という）と、ワークフロー申請データ１０６ｃ（以下、単に「ＷＦ申請データ１０６ｃ」という）と、を記憶している。

【0019】

稟議申請条件マスタ１０６ａは、事業所、データ区分および取引区分毎に、申請される稟議の判定対象の項目、判定時の動作および閾値を対応付けて記憶する。

【0020】

図２は、稟議申請条件マスタ１０６ａにおける稟議申請条件マスタテーブルの一例を示す図である。図２に示す稟議申請条件マスタテーブルＴ１には、事業所、データ区分および取引区分毎に、行ＮＯと、対象項目と、申請チェック要否フラグ（以下、単に「申請チェック要否ＦＬＧ」という）と、閾値と、を対応付けて記憶されている。

【0021】

具体的には、稟議申請条件マスタテーブルＴ１の１行目には、事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」に、行ＮＯ「１」と、対応項目「０：伝票金額」、申請チェック要否ＦＬＧ「１：警告」、チェック符号「０：正」および閾値「５，０００，０００」を対応付けて記憶されている。ここで、行ＮＯとは、後述する入力画面において申請内容を確認する行の位置を示す。また、申請チェック要否ＦＬＧにおける警告とは、後述する受注申請、経費申請および発注申請においてワークフロー申請番号（以下、単に「ＷＦ申請番号」という）の入力の要否を示す。さらに、申請チェック要否ＦＬＧにおける「１：警告」は、ＷＦ申請番号の未入力を容認することを示すものである。さらに、申請チェック要否ＦＬＧにおける「０：エラー」は、ＷＦ申請番号の入力を必須とすることを示すものである。

【0022】

取引別ＷＦ種別マスタ１０６ｂは、データ区分および取引区分毎に、比較対象のＷＦ申請種別を対応付けて記憶する。

【0023】

図３は、取引別ＷＦ種別マスタ１０６ｂにおける取引別ＷＦ種別テーブルの一例を示す図である。図３に示す取引別ＷＦ種別マスタテーブルＴ２には、データ区分および取引区分毎に、比較対象のＷＦ申請種別を対応付けて記憶されている。

【0024】

具体的には、取引別ＷＦ種別マスタテーブルＴ２の１行目には、データ区分「２０：受注」および取引区分「１：倉出受注」に、比較対象のＷＦ申請種別「Ｊ２０」を対応付けて記憶されている。

【0025】

ＷＦ申請データ１０６ｃは、ＷＦ申請番号毎に、ＷＦ申請種別と、申請事業所、申請内容および承認ステータスを対応付けて記憶されている。

【0026】

図４は、ＷＦ申請データ１０６ｃにおけるＷＦ申請データテーブルの一例を示す図である。図４に示すＷＦ申請データテーブルＴ３には、ＷＦ申請番号毎に、ＷＦ申請種別と、申請事業所と、申請内容と、承認ステータス（承認済または未承認）と、を対応付けて記憶されている。

【0027】

具体的には、ＷＦ申請データテーブルＴ３の１行目には、申請番号「ＷＦ０００００１」に、申請種別「Ｊ２０」と、申請事業所「東京」と、申請内容「ＡＢ工業向け 売上５，５００（千円）予定」と、承認ステータス「承認済」と、を対応付けて記憶されている。

【0028】

図１に戻り、稟議申請確認装置１００の構成の説明を続ける。
制御部１０２は、稟議申請確認装置１００を統括的に制御するＣＰＵ等である。制御部１０２は、ＯＳ等の制御プログラム・各種の処理手順等を規定したプログラム・所要データなどを格納するための内部メモリを有し、格納されているこれらのプログラムに基づいて種々の情報処理を実行する。制御部１０２は、取得部１０２ａと、判定部１０２ｂと、表示制御部１０２ｃと、登録部１０２ｄと、を備える。

【0029】

取得部１０２ａは、取得部１０２ａは、モニタ１１４が表示する入力画面においてユーザが入力装置１１２を操作して入力した入力情報を取得する。

【0030】

判定部１０２ｂは、稟議申請条件マスタ１０６ａおよび取引別ＷＦ種別マスタ１０６ｂを参照し、取得部１０２ａが取得した入力情報に含まれる事業所、データ区分および取引区分に基づいて、伝票売上金額および伝票粗利金額の少なくとも一方が閾値以上であるか否かを判定する。

【0031】

表示制御部１０２ｃは、判定部１０２ｂによって伝票売上金額および伝票粗利金額の少なくとも一方が稟議申請条件マスタ１０６ａにおける事業所、データ区分および取引区分に応じた閾値以上であると判定した場合、ＷＦにおいて稟議申請を行った際のＷＦ申請番号の入力を促すメッセージをモニタ１１４に表示させる。また、表示制御部１０２ｃは、表示制御部１０２ｃは、稟議申請条件マスタテーブルＴ１を参照し、申請チェック要否ＦＬＧに応じたメッセージをモニタ１１４に表示させる。

【0032】

登録部１０２ｄは、登録部１０２ｄは、モニタ１１４が表示する入力画面において入力された内容に応じて伝票の起票を行い、この起票した伝票を登録する。

【0033】

［２．稟議申請確認装置１００におけるデータ遷移の概要］
次に、稟議申請確認装置１００が実行する処理の概要について説明する。図５は、稟議申請確認装置１００が実行する処理のデータ遷移の概要を示す図である。

【0034】

図５に示すように、まず、ユーザは、入力装置１１２を操作し、後述するモニタ１１４に表示される入力画面の各種項目に入力することによって稟議申請（受注、発注および経費）を行い（ステップＳ１）、ＷＦ申請を行う（ステップＳ２）。

【0035】

続いて、ユーザの上長や経理管理者は、入力装置１１２を操作し、稟議申請されたＷＦに対して承認を行う（ステップＳ３）。この場合、稟議申請確認装置１００は、承認された稟議申請されたＷＦデータをＷＦ申請データ１０６ｃに格納して記憶する。

【0036】

その後、稟議申請確認装置１００は、稟議申請条件マスタ１０６ａ、取引別ＷＦ種別マスタ１０６ｂおよびＷＦ申請データ１０６ｃを参照し、後述するモニタ１１４に表示される入力画面の各種項目に対してユーザが入力装置１１２を用いて入力した稟議申請に対する確認判定を行って伝票を起案して伝票登録を行う（ステップＳ４）。なお、詳細な稟議申請における伝票登録については、後述する。これにより、ユーザは、システム上に伝票を登録する場合であっても、取引毎に稟議申請の要否の確認作業の効率化を図ることができる。

【0037】

［３．稟議申請確認装置１００が実行する処理］
次に、稟議申請確認装置１００が実行する処理について説明する。図６は、稟議申請確認装置１００が実行する処理の概要を示すフローチャートである。なお、以下においては、稟議申請確認装置１００が稟議申請における受注の処理の一例について説明する。

【0038】

図６に示すように、まず、表示制御部１０２ｃは、入力画面をモニタ１１４に表示させる（ステップＳ１０１）。

【0039】

図７は、モニタ１１４が表示する入力画面の一例を示す図である。なお、図７では、入力画面における受注入力画面について説明する。

【0040】

図７に示すように、受注入力画面Ｐ１には、事業所テキスト入力ボックスＢ１と、受注日テキスト入力ボックスＢ２と、得意先テキスト入力ボックスＢ３と、取引区分テキスト入力ボックスＢ４と、ＷＦ申請番号テキスト入力ボックスＢ５と、受注商品テキスト入力テーブルＴ１０と、が含まれる。

【0041】

ユーザは、入力装置１１２を操作することによって、各テキスト入力ボックスおよび受注商品テキスト入力テーブルＴ１０にテキスト等を入力する。この場合、表示制御部１０２ｃは、図示しない事業所マスタ、得意先マスタ、取引区分マスタおよび商品マスタを参照し、各テキスト入力ボックスに入力さえたテキストに応じた事業所、得意先、取引区分および商品を表示する。

【0042】

図６に戻り、ステップＳ１０２以降の説明を続ける。
ステップＳ１０２において、取得部１０２ａは、受注入力画面Ｐ１においてユーザが入力装置１１２を操作して入力した入力情報を取得する。図８は、受注入力画面Ｐ１にユーザが入力した入力後の状態を示す図である。図８に示すように、取得部１０２ａは、各テキスト入力ボックス、受注商品テキスト入力テーブルＴ１０および受注商品テキスト入力テーブルＴ１０に入力された入力結果（売上金額の合計額）に基づく伝票売上金額Ｋ１「５，５００，０００」および伝票粗利金額Ｋ２「１，７００，０００」を入力情報として取得する。

【0043】

続いて、判定部１０２ｂは、稟議申請条件マスタ１０６ａおよび取引別ＷＦ種別マスタ１０６ｂを参照し、取得部１０２ａが取得した入力情報に含まれる事業所、データ区分および取引区分に基づいて、伝票売上金額および伝票粗利金額の少なくとも一方が閾値を超過しているか否かを判定する（ステップＳ１０３）。具体的には、判定部１０２ｂは、図２に示した稟議申請条件マスタテーブルＴ１を参照し、図８に示す入力情報に含まれる事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」の場合、伝票売上金額が閾値以上（５，０００，０００）であるか否かを判定する。即ち、判定部１０２ｂは、図８に示す入力情報に含まれる事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」の場合において、伝票売上金額のとき、稟議申請条件マスタテーブルＴ１におけるチェック符号が「０：正」のため、対象金額である伝票売上金額が閾値以上であるか否かを判定する（対象金額＞閾値）。この場合、判定部１０２ｂは、対象金額である伝票売上金額が閾値以上であると判定する。さらに、判定部１０２ｂは、図２に示した稟議申請条件マスタテーブルＴ１を参照し、図８に示す入力情報に含まれる事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」の場合、伝票粗利金額が閾値以上（－５００，０００）であるか否かを判定する。即ち、図８に示す入力情報に含まれる事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」の場合において、伝票粗利金額のとき、稟議申請条件マスタテーブルＴ１におけるチェック符号が「１：負」のため、対象金額である伝票粗利金額が閾値を超えているか否かを判定する（対象金額＜閾値）。この場合、判定部１０２ｄは、対象金額である伝票粗利金額が閾値を超えていないと判定する。判定部１０２ｂによって伝票売上金額および伝票粗利金額の少なくとも一方が閾値以上であると判定された場合（ステップＳ１０３：Ｙｅｓ）、稟議申請確認装置１００は、後述するステップＳ１０４へ移行する。これに対して、判定部１０２ｂによって伝票売上金額および伝票粗利金額が閾値以上でないと判定された場合（ステップＳ１０３：Ｎｏ）、稟議申請確認装置１００は、後述するステップＳ１０９へ移行する。

【0044】

ステップＳ１０４において、表示制御部１０２ｃは、稟議申請条件マスタテーブルＴ１を参照し、申請チェック要否ＦＬＧに応じたメッセージをモニタ１１４に表示させる。

【0045】

図９は、表示制御部１０２ｃがモニタ１１４に表示させるメッセージの一例を示す図である。図１０は、表示制御部１０２ｃがモニタ１１４に表示させるメッセージの別の一例を示す図である。なお、図９では、申請チェック要否ＦＬＧが「１：警告」の場合に表示されるメッセージの一例を示す図である。さらに、図１０では、申請チェック要否ＦＬＧが「２：エラー」の場合に表示されるメッセージの一例を示す図である。なお、以下では、申請チェック要否ＦＬＧが「１：警告」の場合について説明する。

【0046】

図９に示すように、メッセージ画面Ｍ１には、ＷＦ申請番号の入力を促すメッセージＭ１１と、ＷＦ申請番号の入力を承諾する指示信号の入力を受け付けるアイコンＡ１（「はい」）と、ＷＦ申請番号の入力を拒否する指示信号の入力を受け付けるアイコンＡ２（「いいえ」）と、が含まれる。

【0047】

図６に戻り、ステップＳ１０５以降の説明を続ける。
ステップＳ１０５において、判定部１０２ｂは、アイコンＡ１が押下されたか否かを判定する（ステップＳ１０５）。判定部１０２ｂによってアイコンＡ１が押下されたと判定された場合（ステップＳ１０５：Ｙｅｓ）、稟議申請確認装置１００は、後述するステップＳ１０６へ移行する。これに対して、判定部１０２ｂによってアイコンＡ１が押下されていないと判定された場合（ステップＳ１０５：Ｎｏ）、稟議申請確認装置１００は、後述するステップＳ１１１へ移行する。

【0048】

ステップＳ１０６において、判定部１０２ｂは、ユーザが入力装置１１２を操作することによって、ＷＦ申請番号が入力されたか否かを判定する。判定部１０２ｂによってＷＦ申請番号が入力されたと判定された場合（ステップＳ１０６：Ｙｅｓ）、稟議申請確認装置１００は、後述するステップＳ１０７へ移行する。これに対して、判定部１０２ｂによってＷＦ申請番号が入力されていないと判定された場合（ステップＳ１０６：Ｎｏ）、判定部１０２ｂは、ＷＦ申請番号が入力されるまで、この判定を繰り返す。

【0049】

ステップＳ１０７において、判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、ＷＦ申請データ１０６ｃのＷＦ申請番号および入力されたＷＦ申請番号が一致するか否かを判定する。判定部１０２ｂによってＷＦ申請データ１０６ｃのＷＦ申請番号および入力されたＷＦ申請番号が一致すると判定された場合（ステップＳ１０７：Ｙｅｓ）、稟議申請確認装置１００は、後述するステップＳ１０９へ移行する。これに対して、判定部１０２ｂによってＷＦ申請データ１０６ｃのＷＦ申請番号および入力されたＷＦ申請番号が一致しないと判定された場合（ステップＳ１０７：Ｎｏ）、稟議申請確認装置１００は、後述するステップＳ１０８へ移行する。

【0050】

ここで、判定部１０２ｂによるＷＦ申請番の判定方法について説明する。図１１は、ＷＦ申請番号が入力された状態の一例を示す図である。図１１に示すように、判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、取得部１０２ａが取得した入力情報に含まれる事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」およびＷＦ申請番号「ＷＦ０００００３」に基づいて、事業所整合確認判定、承認済確認判定および申請種別確認判定を行う。

【0051】

まず、判定部１０２ｂが行う事業所整合確認判定について説明する。判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、ユーザが入力装置１１２を用いて入力したＷＦ申請番号に基づいて、受注入力画面Ｐ１における事業所と、ＷＦ申請データ１０６ｃの事業所チェック（１００：東京）とが一致するか否かを判定する事業所整合確認判定を行う。具体的には、図１１に示す場合、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００３」に基づいて、伝票計上（受注入力画面Ｐ１）の事業所（１００：東京）と、ＷＦ申請データ１０６ｃの事業所チェック（１００：東京）とが一致するか否かを判定する。このとき、判定部１０２ｂは、伝票計上の事業所（１００：東京）とＷＦ申請データ１０６ｃの事業所チェック（１００：東京）とが一致すると判定する。

【0052】

次に、判定部１０２ｂが行う承認済確認判定について説明する。判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、ユーザが入力装置１１２を用いて入力したＷＦ申請番号が承認済であるか否かの承認済確認判定を行う。具体的には、図１１に示す場合、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００３」に基づいて、ＷＦ申請データ１０６ｃの承認ステータスを確認することによって承認済であるか否かを判定する。このとき、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００３」が承認済であると判定する。

【0053】

最後、判定部１０２ｂが行う申請種別確認判定について説明する。判定部１０２ｂは、ＷＦ申請データ１０６ｃおよび取引別ＷＦ種別マスタ１０６ｂを参照し、ユーザが入力装置１１２を用いて入力したＷＦ申請番号および取引区分に対応するＷＦ申請種別が正しいか否かの確認判定を行う。具体的には、図１１に示す場合、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００３」および取引区分「１：倉出受注」のとき、ＷＦ申請データ１０６ｃにおける申請種別が「Ｈ２０」であるため、ＷＦ申請種別が異なると判定する。この結果、判定部１０２ｂは、ＷＦ申請種別が異常であると判定する。即ち、判定部１０２ｂは、ＷＦ申請データ１０６ｃのＷＦ申請番号および入力されたＷＦ申請番号が一致しないと判定する。

【0054】

図１２は、別のＷＦ申請番号が入力された状態の一例を示す図である。図１２に示すように、判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、取得部１０２ａが取得した入力情報に含まれる事業所「１００：東京」、データ区分「２０：受注」および取引区分「１：倉出受注」およびＷＦ申請番号「ＷＦ０００００１」に基づいて、事業所整合確認判定、承認済確認判定および申請種別確認判定を行う。

【0055】

まず、判定部１０２ｂが行う事業所整合確認判定について説明する。判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、ユーザが入力装置１１２を用いて入力したＷＦ申請番号に基づいて、受注入力画面Ｐ１における事業所と、ＷＦ申請データ１０６ｃの事業所チェック（１００：東京）とが一致するか否かを判定する事業所整合確認判定を行う。具体的には、図１１に示す場合、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００１」に基づいて、伝票計上（受注入力画面Ｐ１）の事業所（１００：東京）と、ＷＦ申請データ１０６ｃの事業所チェック（１００：東京）とが一致するか否かを判定する。このとき、判定部１０２ｂは、伝票計上の事業所（１００：東京）とＷＦ申請データ１０６ｃの事業所チェック（１００：東京）とが一致すると判定する。

【0056】

次に、判定部１０２ｂが行う承認済確認判定について説明する。判定部１０２ｂは、ＷＦ申請データ１０６ｃを参照し、ユーザが入力装置１１２を用いて入力したＷＦ申請番号が承認済であるか否かの承認済確認判定を行う。具体的には、図１１に示す場合、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００１」に基づいて、ＷＦ申請データ１０６ｃの承認ステータスを確認することによって承認済であるか否かを判定する。このとき、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００１」が承認済であると判定する。

【0057】

最後、判定部１０２ｂが行う申請種別確認判定について説明する。判定部１０２ｂは、ＷＦ申請データ１０６ｃおよび取引別ＷＦ種別マスタ１０６ｂを参照し、ユーザが入力装置１１２を用いて入力したＷＦ申請番号および取引区分に対応するＷＦ申請種別が正しいか否かの確認判定を行う。具体的には、図１１に示す場合、判定部１０２ｂは、ＷＦ申請番号「ＷＦ０００００１」および取引区分「１：倉出受注」のとき、ＷＦ申請データ１０６ｃにおけるＷＦ申請種別が「Ｊ２０」であるため、ＷＦ申請種別が一致すると判定する。この結果、判定部１０２ｂは、事業所、承認ステータスおよびＷＦ申請番号が正常であると判定する。即ち、判定部１０２ｂは、ＷＦ申請データ１０６ｃのＷＦ申請番号および入力されたＷＦ申請番号が一致すると判定する。

【0058】

このように、ユーザは、稟議申請確認装置１００上に伝票を登録する場合に、取引毎に稟議申請の要否の確認作業の効率化を図ることができる。

【0059】

図６に戻り、ステップＳ１０８以降の説明を続ける。
ステップＳ１０８において、表示制御部１０２ｃは、入力したＷＦ申請番号がＷＦ申請データ１０６ｃで承認済みのＷＦ申請番号と異なる旨の警告をモニタ１１４に表示させる。この場合、表示制御部１０２ｃは、申請種別が異なる旨の警告をモニタ１１４に表示させてもよい。例えば、表示制御部１０２ｃは、正しい申請種別またはＷＦ申請番号の入力を促すメッセージをモニタ１１４に表示させる。これにより、ユーザは、受注入力画面Ｐ１に入力したＷＦ申請番号または申請種別が間違っていることを把握することができる。ステップＳ１０８の後、稟議申請確認装置１００は、上述したステップＳ１０４へ戻る。

【0060】

ステップＳ１０９において、登録部１０２ｄは、受注入力画面Ｐ１において入力された内容に応じて伝票の起票を行う。

【0061】

続いて、登録部１０２ｄは、起票した伝票を登録する（ステップＳ１１０）。ステップＳ１１０の後、稟議申請確認装置１００は、本処理を終了する。

【0062】

ステップＳ１１１において、判定部１０２ｂは、アイコンＡ２が押下されたか否かを判定する。判定部１０２ｂによってアイコンＡ２が押下されたと判定された場合（ステップＳ１１１：Ｙｅｓ）、稟議申請確認装置１００は、後述するステップＳ１１２へ移行する。これに対して、判定部１０２ｂによってアイコンＡ２が押下されていないと判定された場合（ステップＳ１１１：Ｎｏ）、稟議申請確認装置１００は、上述したステップＳ１０４へ戻る。

【0063】

ステップＳ１１２において、判定部１０２ｂは、申請チェック要否ＦＬＧが警告（１：警告）であるか否かを判定する。判定部１０２ｂによって申請チェック要否ＦＬＧが警告であると判定された場合（ステップＳ１１２：Ｙｅｓ）、稟議申請確認装置１００は、ステップＳ１０９へ移行する。この場合、稟議申請確認装置１００は、ＷＦ申請番号が未入力であっても、ＷＦ申請番号が不要のため、登録部１０２ｄが起票し、かつ、登録を行う。これに対して、判定部１０２ｂによって申請チェック要否ＦＬＧが警告でないと判定された場合（ステップＳ１１２：Ｎｏ）、稟議申請確認装置１００は、上述したステップＳ１０４へ戻る。

【0064】

［４．稟議申請における経費入力］
次に、稟議申請における経費入力の場合について説明する。図１３および図１４は、稟議申請における経費入力の概要を説明する図である。図１３および図１４において、経費入力画面Ｐ２には、事業所テキスト入力ボックスＢ１１と、計上日テキスト入力ボックスＢ１２と、仕入先テキスト入力ボックスＢ１３と、経費テキスト入力テーブルＴ１１と、が含まれる。

【0065】

図１３および図１４の経費入力画面Ｐ２に示すように、ユーザは、入力装置１１２を操作することによって、各テキスト入力ボックスおよび経費テキスト入力テーブルＴ１１にテキスト等を入力する。具体的には、経費入力画面Ｐ２には、事業所テキスト入力ボックスＢ１１に「１００」、計上日テキスト入力ボックスＢ１２に「２０１８／０４／０１」と、仕入先テキスト入力ボックスＢ１３に「ＳＲ００１」が入力される。さらに、経費入力画面Ｐ２の経費テキスト入力テーブルＴ１１には、取引区分、費目、ＷＦ申請番号および金額が入力されている。具体的には、経費テキスト入力テーブルＴ１１の１行目には、取引区分「１」（研究開発費）、費目「Ｈ００１」（研究費）、ＷＦ申請番号「ＷＦ０００００４」（研究開発費 ＡＡカラー 新色開発）および金額「６００，０００」が入力されている。さらに、経費テキスト入力テーブルＴ１１の２行目には、取引区分「２」（経費）、費目「Ｈ００２」（セミナー関連）、ＷＦ申請番号「ＷＦ０００００５」（ＡＡ業界向け セミナー 会場）および金額「２００，０００」が入力されている。

【0066】

図１３および図１４に示す場合、稟議申請確認装置１００は、上述した受注の処理と同様の処理を行う。以下においては、稟議申請確認装置１００は、図１３において、経費テキスト入力テーブルＴ１１の１行目に入力された内容に対して行う処理について説明後、図１４において、経費テキスト入力テーブルＴ１１の２行目に入力された内容に対して行う処理について説明する。

【0067】

まず、稟議申請確認装置１００が図１３の経費テキスト入力テーブルＴ１１の１行目に入力された内容に対して行う処理について説明する。図１３に示すように、取得部１０２ａは、経費入力画面Ｐ２に入力された入力情報を取得する。具体的には、取得部１０２ａは、事業所テキスト入力ボックスＢ１１、計上日テキスト入力ボックスＢ１２、仕入先テキスト入力ボックスＢ１３および経費テキスト入力テーブルＴ１１の１行目に入力された内容を入力情報として取得する。

【0068】

その後、判定部１０２ｂは、事業所、データ区分および取引区分毎に、稟議申請の要否を判定する。具体的には、判定部１０２ｂは、稟議申請条件マスタ１０６ａを参照し、ＷＦ申請番号の要否を判定する。図１３に示す場合、判定部１０２ｂは、事業者「１００：東京」、データ区分「８０：経費」および取引区分「１：研究開発費」であり、閾値「５００，０００」に対して、金額が「６００，０００」のため、ＷＦ申請番号の入力を必要と判定する。

【0069】

続いて、判定部１０２ｂは、データ区分および取引区分毎に確認するＷＦ申請種別を判定する。具体的には、判定部１０２ｂは、取引別ＷＦ種別マスタ１０６ｂを参照し、データ区分および取引区分毎に確認するＷＦ申請種別を判定する。図１３に示す場合、判定部１０２ｂは、データ区分「８０」および取引区分「１：研究開発費」のため、取引別ＷＦ種別マスタ１０６ｂからＷＦ申請種別「Ｋ８０」を取得する。即ち、研究開発費では、ＷＦ申請種別が「Ｋ８０」である必要がある。

【0070】

その後、判定部１０２ｂは、ＷＦ申請番号における事業者、申請種別および承認ステータスの確認判定を行う。図１３に示す場合、判定部１０２ｂは、ＷＦ申請データ１０６ｃおよび取引別ＷＦ種別マスタ１０６ｂを参照し、ＷＦ申請番号「ＷＦ０００００４」における申請事業所の事業者制御確認判定、ＷＦ申請種別の申請種別確認判定および承認ステータスの承認済み確認判定を行う。この場合、判定部１０２ｂは、申請事業所「東京」、ＷＦ申請種別「Ｋ８０」および承認ステータス「承認済」のため、入力が正常であると判定する。この場合、登録部１０２ｄは、経費入力画面Ｐ２の経費テキスト入力テーブルＴ１１の１行目に入力された内容に応じた伝票の起票を行い、伝票の登録を行う。

【0071】

次に、稟議申請確認装置１００が図１４の経費テキスト入力テーブルＴ１１の２行目に入力された内容に対して行う処理について説明する。図１４に示すように、取得部１０２ａは、経費入力画面Ｐ２に入力された入力情報を取得する。具体的には、取得部１０２ａは、事業所テキスト入力ボックスＢ１１、計上日テキスト入力ボックスＢ１２、仕入先テキスト入力ボックスＢ１３および経費テキスト入力テーブルＴ１１の２行目に入力された内容を入力情報として取得する。

【0072】

その後、判定部１０２ｂは、事業所、データ区分および取引区分毎に、稟議申請の要否を判定する。具体的には、判定部１０２ｂは、稟議申請条件マスタ１０６ａを参照し、ＷＦ申請番号の要否を判定する。図１４に示す場合、判定部１０２ｂは、事業者「１００：東京」、データ区分「８０：経費」および取引区分「２：経費」であり、閾値「２００，０００」に対して、金額が「１００，０００」のため、ＷＦ申請番号の入力を必要と判定する。

【0073】

続いて、判定部１０２ｂは、データ区分および取引区分毎に確認するＷＦ申請種別を判定する。具体的には、判定部１０２ｂは、取引別ＷＦ種別マスタ１０６ｂを参照し、データ区分および取引区分毎に確認するＷＦ申請種別を判定する。図１４に示す場合、判定部１０２ｂは、データ区分「８０」および取引区分「２：経費」のため、取引別ＷＦ種別マスタ１０６ｂからＷＦ申請種別「Ｋ８１」を取得する。即ち、研究開発費では、ＷＦ申請種別が「Ｋ８１」である必要がある。

【0074】

その後、判定部１０２ｂは、ＷＦ申請番号における事業者、申請種別および承認ステータスの確認判定を行う。図１３に示す場合、判定部１０２ｂは、ＷＦ申請データ１０６ｃおよび取引別ＷＦ種別マスタ１０６ｂを参照し、ＷＦ申請番号「ＷＦ０００００５」における申請事業所の事業者制御確認判定、ＷＦ申請種別の申請種別確認判定および承認ステータスの承認済み確認判定を行う。この場合、判定部１０２ｂは、申請事業所「東京」、ＷＦ申請種別「Ｋ８１」が正常であるが、承認ステータス「未承認済」のため、異常であると判定する。このとき、表示制御部１０２ｃは、ＷＦ申請番号が未承認である旨の警告をモニタ１１４に表示させる。これにより、ユーザは、稟議申請したＷＦが未承認であることを把握することができる。

【0075】

以上説明した実施形態によれば、表示制御部１０２ｃが判定部１０２ｂによって伝票売上金額および伝票粗利金額の少なくとも一方が稟議申請条件マスタ１０６ａにおける事業所、データ区分および取引区分に応じた閾値以上であると判定した場合、ＷＦにおいて稟議申請を行った際のＷＦ申請番号の入力を促すメッセージをモニタ１１４に表示させる。これにより、システム上に伝票を登録する場合に、取引毎に稟議申請の要否の確認作業の効率化を図ることができる。

【0076】

また、実施形態によれば、判定部１０２ｂがＷＦ申請データ１０６ｃを参照し、入力されるＷＦ申請番号に基づいて、ＷＦ申請種別、申請事業所および承認ステータスの各々が正しいか否かを判定するため、稟議申請の要否の確認作業の効率化を図ることができる。

【0077】

また、実施形態によれば、表示制御部１０２ｃは、稟議申請条件マスタテーブルＴ１を参照し、申請チェック要否ＦＬＧに応じたメッセージをモニタ１１４に表示させるため、ＷＦ申請番号が必要ない稟議申請に対して、効率化を図ることができる。

【0078】

また、実施形態によれば、登録部１０２ｄが判定部１０２ｂによって伝票売上金額および伝票粗利金額が閾値以上でないと判定された場合、入力情報に応じた伝票を起票して登録するため、稟議申請の要否の確認作業の効率化を図ることができる。

【0079】

［５．国連が主導する持続可能な開発目標（ＳＤＧｓ）への貢献］
本実施形態により、業務効率化や企業の適切な経営判断を推進することに寄与することができるので、ＳＤＧｓの目標８および９に貢献することが可能となる。

【0080】

また、本実施形態により、廃棄ロス削減や、ペーパレス・電子化を推進することに寄与することができるので、ＳＤＧｓの目標１２、１３および１５に貢献することが可能となる。

【0081】

また、本実施形態により、統制、ガバナンス強化に寄与することができるので、ＳＤＧｓの目標１６に貢献することが可能となる。

【0082】

［６．他の実施形態］
本発明は、上述した実施形態以外にも、特許請求の範囲に記載した技術的思想の範囲内において種々の異なる実施形態にて実施されてよいものである。

【0083】

例えば、実施形態において説明した各処理のうち、自動的に行われるものとして説明した処理の全部または一部を手動的に行うこともでき、あるいは、手動的に行われるものとして説明した処理の全部または一部を公知の方法で自動的に行うこともできる。

【0084】

また、本明細書中や図面中で示した処理手順、制御手順、具体的名称、各処理の登録データや検索条件等のパラメーターを含む情報、画面例、データベース構成については、特記する場合を除いて任意に変更することができる。

【0085】

また、稟議申請確認装置１００に関して、図示の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。

【0086】

例えば、稟議申請確認装置１００が備える処理機能、特に制御部にて行われる各処理機能については、その全部または任意の一部を、ＣＰＵおよび当該ＣＰＵにて解釈実行されるプログラムにて実現してもよく、また、ワイヤードロジックによるハードウェアとして実現してもよい。なお、プログラムは、本実施形態で説明した処理を情報処理装置に実行させるためのプログラム化された命令を含む一時的でないコンピュータ読み取り可能な記憶媒体に記憶されており、必要に応じて稟議申請確認装置１００に機械的に読み取られる。すなわち、ＲＯＭまたはＨＤＤ（Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ）などの記憶部などには、ＯＳと協働してＣＰＵに命令を与え、各種処理を行うためのコンピュータプログラムが記憶されている。このコンピュータプログラムは、ＲＡＭにロードされることによって実行され、ＣＰＵと協働して制御部を構成する。

【0087】

また、このコンピュータプログラムは、稟議申請確認装置１００に対して任意のネットワークを介して接続されたアプリケーションプログラムサーバに記憶されていてもよく、必要に応じてその全部または一部をダウンロードすることも可能である。

【0088】

また、本実施形態で説明した処理を実行するためのプログラムを、一時的でないコンピュータ読み取り可能な記憶媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記憶媒体」とは、メモリーカード、ＵＳＢ（Ｕｎｉｖｅｒｓａｌ Ｓｅｒｉａｌ Ｂｕｓ）メモリ、ＳＤ（Ｓｅｃｕｒｅ Ｄｉｇｉｔａｌ）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Ｅｒａｓａｂｌｅ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＥＥＰＲＯＭ（登録商標）（Ｅｌｅｃｔｒｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＣＤ－ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｋ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔｏ－Ｏｐｔｉｃａｌ ｄｉｓｋ）、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、および、Ｂｌｕ－ｒａｙ（登録商標） Ｄｉｓｃ等の任意の「可搬用の物理媒体」を含むものとする。

【0089】

また、「プログラム」とは、任意の言語または記述方法にて記述されたデータ処理方法であり、ソースコードまたはバイナリコード等の形式を問わない。なお、「プログラム」は必ずしも単一的に構成されるものに限られず、複数のモジュールやライブラリとして分散構成されるものや、ＯＳに代表される別個のプログラムと協働してその機能を達成するものをも含む。なお、実施形態に示した各装置において記憶媒体を読み取るための具体的な構成および読み取り手順ならびに読み取り後のインストール手順等については、周知の構成や手順を用いることができる。

【0090】

記憶部に格納される各種のデータベース等は、ＲＡＭ、ＲＯＭ等のメモリ装置、ハードディスク等の固定ディスク装置、フレキシブルディスク、および、光ディスク等のストレージ手段であり、各種処理やウェブサイト提供に用いる各種のプログラム、テーブル、データベース、および、ウェブページ用ファイル等を格納する。

【0091】

また、稟議申請確認装置１００は、既知のパーソナルコンピュータまたはワークステーション等の情報処理装置として構成してもよく、また、任意の周辺装置が接続された当該情報処理装置として構成してもよい。また、稟議申請確認装置１００は、当該装置に本実施形態で説明した処理を実現させるソフトウェア（プログラムまたはデータ等を含む）を実装することにより実現してもよい。

【0092】

さらに、装置の分散・統合の具体的形態は図示するものに限られず、その全部または一部を、各種の付加等に応じてまたは機能負荷に応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。すなわち、上述した実施形態を任意に組み合わせて実施してもよく、実施形態を選択的に実施してもよい。

【産業上の利用可能性】

【0093】

本発明は、システムでの内部統制要件のある企業、特に化学業界や商社業界等において有用である。

【符号の説明】

【0094】

１００ 稟議申請確認装置
１０２ 制御部
１０２ａ 取得部
１０２ｂ 判定部
１０２ｃ 表示制御部
１０２ｄ 登録部
１０４ 通信インターフェース部
１０６ 記憶部
１０６ａ 稟議申請条件マスタ
１０６ｂ 取引別ワークフロー種別マスタ
１０６ｃ ワークフロー申請データ
１０８ 入出力インターフェース部
１１２ 入力装置
１１４ 出力装置
２００ サーバ
３００ ネットワーク

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【図7】

【図8】

【図9】

【図10】

【図11】

【図12】

【図13】

【図14】