JP7182737B1 - 申請制御装置、申請制御方法、及び、申請制御プログラム - Google Patents

Abstract

【課題】複数申請を一括して行うことを可能とする。【解決手段】取得部が、実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する。データ生成部は、取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶する。承認要求部は、社員毎に纏められた案件データの一括承認要求を行う。変更制御部は、一括承認要求により承認が得られた際に、起票テーブルに記憶されている承認未申請のデータを実テーブルに移行して実テーブルを変更し、一括承認要求により承認が得られなかった場合は、案件データの申請状態情報及び起票テーブルに記憶されている承認未申請のデータの申請状態情報を申請却下に変更する。【選択図】図２３

Description

本発明は、申請制御装置、申請制御方法、及び、申請制御プログラムに関する。

今日において、例えば企業等では、社内で行われている各種申請又は稟議等の業務手続きを電子化（デジタル化）したワークフローシステムが導入されている。各種申請に関する先行技術としては、特許文献１（特開２０２１－１２４８７８号公報）に、会社等の管理者が、管理者に管理される従業者等の複数の被管理者に関し電子申請手続を手続先へオンラインにより行うため、被管理者に関するデータのファイルを取得し収容する電子申請補助システムが開示されている。

この電子申請補助システムは、申請データ収容部と、管理テーブル収容部と、システム制御部と、キー生成部とを備える。そして、暗号化するキー生成の要素データを収容する管理テーブルとは別の申請データ収容部へ、申請関連データのファイルを収容するファイル別収容部を形成し、要素データから生成するキー自体を、ファイル別収容部を特定する唯一の手段とする。これにより、高い機密性を確保した申請関連データのファイルの置き場、すなわち、申請関連データのファイルの受け渡し場所を提供する。

特開２０２１－１２４８７８号公報

しかし、従来のワークフローシステム等の申請システムにおいては、複数の申請を一括して行うことは、困難となっていた。

本発明は、上述の課題に鑑みてなされたものであり、複数の申請を一括して行うことを可能とした申請制御装置、申請制御方法、及び、申請制御プログラムの提供を目的とする。

上述の課題を解決し、目的を達成するために、本発明に係る申請制御装置は、実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する取得部と、取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶するデータ生成部と、社員毎に纏められた案件データの一括承認要求を行う承認要求部と、一括承認要求により承認が得られた際に、各カテゴリの起票テーブルに記憶されている承認未申請のデータを、対応するカテゴリの実テーブルに移行して実テーブルのデータ構成を変更し、一括承認要求により承認が得られなかった場合は、案件データの申請状態情報及び起票テーブルに記憶されている承認未申請のデータの申請状態情報を、共に申請却下の申請状態情報に変更する変更制御部と、を有する。

また、上述の課題を解決し、目的を達成するために、本発明に係る申請制御方法は、取得部が、実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する取得ステップと、データ生成部が、取得ステップで取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶するデータ生成ステップと、承認要求部が、社員毎に纏められた案件データの一括承認要求を行う承認要求ステップと、変更制御部が、一括承認要求により承認が得られた際に、各カテゴリの起票テーブルに記憶されている承認未申請のデータを、対応するカテゴリの実テーブルに移行して実テーブルのデータ構成を変更し、一括承認要求により承認が得られなかった場合は、案件データの申請状態情報及び起票テーブルに記憶されている承認未申請のデータの申請状態情報を、共に申請却下の申請状態情報に変更する変更制御ステップと、を有する。

また、上述の課題を解決し、目的を達成するために、本発明に係る申請制御プログラムは、コンピュータを、実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する取得部と、取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶するデータ生成部と、社員毎に纏められた案件データの一括承認要求を行う承認要求部と、一括承認要求により承認が得られた際に、各カテゴリの起票テーブルに記憶されている承認未申請のデータを、対応するカテゴリの実テーブルに移行して実テーブルのデータ構成を変更し、一括承認要求により承認が得られなかった場合は、案件データの申請状態情報及び起票テーブルに記憶されている承認未申請のデータの申請状態情報を、共に申請却下の申請状態情報に変更する変更制御部として機能させること、を特徴とする。

本発明によれば、複数の申請を一括して行うことができるという効果を奏する。

図１は、実施の形態の申請制御システムのシステム構成を示す図である。 図２は、実施の形態の申請制御システムに対して比較例となる申請制御システムのデータベースに対するデータの更新形態を示す図である。 図３は、実施の形態の申請制御システムにおけるシステム動作の概要を示す図である。 図４は、データの更新の際に参照される管理者設定マスタに対する承認者の設定を説明するための図である。 図５は、管理者設定マスタに登録される部署又はユーザの各種情報が、他のマスタから取得されて管理者設定マスタに登録される様子を示す図である。 図６は、データの更新の際に参照される申請種別カテゴリ割付マスタに対する、承認を必要とするテーブルの設定を説明するための図である。 図７は、申請種別カテゴリ割付マスタに、申請種別及びカテゴリ（テーブル）が関連付けされて登録される様子を示す図である。 図８は、実施の形態の申請制御装置におけるデータの更新動作を説明するためのフローチャートである。 図９は、東京本社の東京人事部の社員により、住所の登録申請が行われた場合における、実テーブルの更新動作を示す図である。 図１０は、関西支社の関西総務部の社員により、住所の登録申請を行われた場合における、起票テーブルに対する仮登録動作を示す図である。 図１１は、関西支社の関西総務部の社員により、前職情報の登録申請を行われた場合における、実テーブルの更新動作を示す図である。 図１２は、データの更新に承認者の承認が不要な管理者により、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタに、申請されたデータのカテゴリが登録されていない場合における、申請制御装置の動作をまとめて示す図である。 図１３は、データの更新に承認者の承認が必要なユーザにより、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタに、申請されたデータのカテゴリが登録されている場合における、申請制御装置の動作をまとめて示す図である。 図１４は、実施の形態の申請制御システムに対して比較例となる申請制御システムの申請形態を示す図である。 図１５は、実施の形態の申請制御システムにおける申請制御装置の一括申請動作の流れを示すフローチャートである。 図１６は、各カテゴリの起票テーブルから承認未申請データが取得される様子を示す図である。 図１７は、社員情報申請画面の一例を示す図である。 図１８は、案件テーブルの生成動作を説明するための図である。 図１９は、各カテゴリの起票テーブルに記憶されている承認申請前の起票データの一例を示す図である。 図２０は、各カテゴリの起票テーブルに記憶されている承認申請後の案件データ及び起票データの一例を示す図である。 図２１は、申請内容を示す申請内容データの一例を示す図である。 図２２は、未承認一覧選択画面に基づく、申請の承認及び却下を説明するための図である。 図２３は、申請の承認時及び却下時における、各テーブルの更新動作を説明するための図である。 図２４は、申請の承認時におけるデータのデータ形態を示す図である。 図２５は、申請の却下時におけるデータのデータ形態を示す図である。 図２６は、却下された申請の修正動作を説明するための図である。 図２７は、申請の破棄及び修正時における、各テーブルの更新動作を説明するための図である。 図２８は、申請が破棄された際の案件データ及び承認未申請データ（起票データ）を示す図である。 図２９は、申請が修正された際の案件データ及び承認未申請データ（起票データ）を示す図である。 図３０は、申請の再申請を説明するための図である。 図３１は、申請されたデータが実テーブルに記憶されるまでの間は、照会不可となる不都合を説明するための図である。 図３２は、申請されたデータのリアルタイムの照会動作を説明するための図である。 図３３は、実施の形態の申請制御装置におけるデータの追加に関するジョブの流れを示す図である。 図３４は、実施の形態の申請制御装置におけるデータの修正に関するジョブの流れを示す図である。 図３５は、実施の形態の申請制御装置におけるデータの削除に関するジョブの流れを示す図である。 図３６は、データの追加時における実データ、案件テーブル、起票データに対する更新動作を示す図である。 図３７は、データの修正時における実データ、案件テーブル、起票データに対する更新動作を示す図である。 図３８は、データの削除時における実データ、案件テーブル、起票データに対する更新動作を示す図である。

以下、本発明を適用した実施の形態となる申請制御システムを、図面に基づいて詳細に説明する。なお、本実施形態により本発明が限定されるものではない。また、「更新」の概念は、データの登録の他、修正、追加、削除等の、データベースのデータ構成を変更させる全ての行為を含む広義の概念である。

（システム構成）
図１は、実施の形態の申請制御システムのシステム構成を示す図である。この図１に示すように、申請制御システムは、申請制御装置１、申請端末装置９及び承認端末装置１０を、ネットワーク８を介して相互に接続して構成されている。ネットワーク８としては、例えばインターネット等の広域網、又は、ＬＡＮ（Local Area Network）等のプライベート網を用いることができる。

申請端末装置９は、データベースに対するデータの更新の申請を行うユーザが操作する端末装置である。承認端末装置１０は、申請端末装置９から申請されたデータの更新の承認を行う承認者の端末装置である。申請制御装置１は、端末装置９からデータの更新の申請を受け付け、承認者により、承認端末装置１０を介して更新等の承認が得られた際に、申請されたデータのデータベースに対する更新を行う。なお、この例では、申請制御装置１、申請端末装置９及び承認端末装置１０を、それぞれ物理的に異なる装置として説明するが、いずれか２つ又は全部を、一つの端末装置としてもよい。

申請制御装置１、申請端末装置９及び承認端末装置１０としては、デスクトップ型のパーソナルコンピュータ装置の他、ノート型のパーソナルコンピュータ装置又はタブレット型のパーソナルコンピュータ装置を用いることができる。また、申請制御装置１、申請端末装置９及び承認端末装置１０としては、ＰＤＡ（Personal Digital Assistants）装置又はスマートフォン等携帯型情報処理装置を用いることができる。

（申請制御装置のハードウェア構成）
申請制御装置１は、図１に示すように、記憶部２、制御部３、通信インターフェース部４及び入出力インターフェース部５を備えている。

入出力インターフェース部５には、入力装置６及び出力装置７が接続されている。出力装置７としては、モニタ装置（家庭用テレビを含む）等の表示部を用いることができる。

入力装置６としては、キーボード装置及びマウス装置、及びマイクロホン装置の他、マウス装置と協働してポインティングデバイス機能を実現するモニタ装置を用いることができる。

記憶部２としては、例えばＲＯＭ（Read Only Memory）、ＲＡＭ（Random Access Memory）、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）等の記憶装置を用いることができる。記憶部２には、管理者設定マスタ１１、申請種別カテゴリ割付マスタ１２、組織マスタ１３、部署マスタ１４、ユーザマスタ１５、実テーブル１６、起票テーブル１７、及び、申請種別グループマスタ１８が記憶されている。また、記憶部２には、申請種別マスタ１９、コードマスタ２０、社員情報カテゴリマスタ２１、案件テーブル２２、及び、申請制御プログラムが記憶されている。また、記憶部２には、承認申請の内容を印刷又は表示するための申請内容データが記憶される。

管理者設定マスタ１１には、申請されたデータのデータベースに対する更新の承認権限のあるユーザ又は部署が記憶されている。申請種別カテゴリ割付マスタ１２には、更新の申請種別、及び、更新に承認者の承認が必要となるデータ種別（カテゴリ）が記憶されている。組織マスタ１３には、組織コード及び組織名等が記憶されている。部署マスタ１４には、部署コード、その部署が属する組織の組織コード、部署名等が記憶されている。ユーザマスタ１５には、ユーザ識別番号（ユーザＩＤ）、パスワード及びユーザ名等が記憶されている。

申請種別グループマスタ１８には、申請種別グループＩＤ及び申請種別グループ名等が記憶されている。申請種別マスタ１９には、申請種別コード、申請種別名、及び、申請種別グループコードが記憶されている。コードマスタ２０には、種別、コード値、及び、テーブル名が記憶されている。社員情報カテゴリマスタ２１には、カテゴリグループＩＤ、カテゴリＩＤ、カテゴリ名、表示フラグ、及び、表示順等が記憶されている。

実テーブル１６は、実データベースの一例であり、本登録されたデータの記憶領域である。実テーブル１６は、例えば「基本」のカテゴリのデータが記憶されるテーブル、「住所」のカテゴリのデータが記憶されるテーブル、「家族」のカテゴリのデータが記憶されるテーブル等のように、カテゴリ別の記憶領域（テーブル）を備えている。換言すると、実テーブル１６は、各カテゴリに対応してそれぞれ設けられている。申請されたデータは、対応するカテゴリの実テーブル１６に記憶される（図３の各カテゴリの実テーブル１６ａ～１６ｚを参照）。

起票テーブル１７は、起票データベースの一例であり、実テーブル１６に対して更新前のデータが、一時的に記憶される記憶領域となっている。申請制御装置１は、申請されたデータを、この起票テーブル１７に一旦記憶し、承認者の承認が得られた際に、起動テーブル１７から実テーブル１６にデータを移行し、実テーブル１６のデータ構成を更新する。これにより、承認者により承認が得られた正確なデータで、実テーブル１６のデータ構成を更新可能となっている。なお、起票テーブル１７も、実テーブル１６と同じ複数のカテゴリのテーブルで構成されている（図３の各カテゴリの起票テーブル１７ａ～１７ｚを参照）。

（更新制御装置の機能構成）
次に、申請制御装置１の制御部３は、記憶部２に記憶されている申請制御プログラムを実行することで、マスタ設定部３１、取得部３２、権限判別部３３、承認要否判別部３４、記憶制御部３５、表示制御部３６、通信制御部３７、及び、データ生成部３８として機能する。

マスタ設定部３１は、管理者設定マスタ１１及び申請種別カテゴリ割付マスタ１２等に対する各種データの設定を行う。取得部３２は、申請端末装置９を介して申請者から申請されたデータ等を取得する。権限判別部３３は、データの申請を行った申請者の、実テーブル１６に対するデータの更新の権限の有無を判別する。承認要否判別部３４は、データの更新が申請されているカテゴリのテーブルは、データの更新に承認者の承認を必要とするテーブルであるか否かを判別する。

記憶制御部３５は、変更制御部の一例であり、承認者により承認前のデータを、起票テーブル１７に一旦記憶しておき、承認後に、実テーブル１６に移行して記憶する。表示制御部３６は、管理者設定マスタ１１及び申請種別カテゴリ割付マスタ１２等に対する各種データの設定画面を出力装置７に表示する。通信制御部３７は、申請端末装置９及び承認端末装置１０と通信を行う。通信制御部３７は、申請端末装置９から、実テーブル１６のデータ構成の更新に関するデータを受信する。また、通信制御部３７は、承認端末装置１０と通信を行い、実テーブル１６のデータ構成の更新の承認を得る。

また、取得部３２は、起票テーブル１７に記憶されている承認未申請のデータを取得する。表示制御部３６は、取得された承認未申請のデータを表示部の一例である出力装置７に一覧表示する。

データ生成部３８は、一覧表示された承認未申請のデータのうち、選択された承認未申請のデータを、社員毎に纏めて固有の案件識別情報（案件Ｇｕｉｄ）を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成する。通信制御部３７は、承認要求部の一例として機能し、社員毎に纏められた案件データを、承認者の承認端末装置１０に対して一括送信して承認要求を行う。

（比較例の更新形態）
図２は、実施の形態の申請制御システムに対して比較例となる申請制御システムのデータベースに対するデータの更新形態を示す図である。この図２において、東京人事部の社員Ａ、及び、関西支社の社員Ｇは、共にデータベースに対するデータの更新の権限を有するユーザである。この図２に示すように、比較例となる申請制御システムの場合、データベースに対するデータの更新の権限があれば、データベースに対して自由にアクセスしてデータの更新を行うことが可能であった。

このため、例えば関西支社等の拠点担当者（＝権限の無い社員Ｇ）により申請された社員情報等のデータが、精査が行われないまま、実データとしてデータベースに登録され、誤ったデータであっても、そのまま人事のデータとして使用される不都合を生じていた。

人事諸届という申請から、ある特定の情報（家族情報又は住所情報等）は、社員本人で精査することができるが、関西支社等の拠点からの社員情報は、直接入力、又は、ファイルを受け入れての入力のうち、どちらかの入力形態で入力されるため、承認者が精査することは困難であった。

また、仮に、データベースのデータが正しいデータに修正されたとしても、データを変更する権限を有するユーザであれば、後から再度書き換えることも可能であった。

（実施の形態のシステム概要）
このようなことから、データベースに対するデータの更新を行う場合、実施の形態の申請制御システムでは、承認者により精査された正確なデータで、データベースのデータ構成を更新するようになっている。

図３は、実施の形態の申請制御システムにおけるシステム動作の概要を示す図である。この図３に示すように実施の形態の申請制御システムの申請制御装置１は、データの更新が申請された場合、管理者設定マスタ１１を参照して、申請を行ったユーザが、データベースに対する更新権限を有するユーザであるか否かを判別する。また、更新が申請されているデータを記憶するテーブルが、承認者の承認を必要とするテーブルであるか否かを判別する。

申請を行ったユーザが、データベースに対する更新権限を有するユーザである場合、申請されたデータを実テーブル１６に対して更新する。また、更新が申請されているデータを記憶するテーブルが、承認者の承認を必要とするテーブルではない場合、申請されたデータを実テーブル１６に対して更新する。

これに対して、申請を行ったユーザが、データベースに対する更新権限を有するユーザではない場合、申請されたデータを起票テーブル１７に一旦記憶する。また、更新が申請されているデータを記憶するテーブルが、承認者の承認を必要とするテーブルである場合、申請されたデータを起票テーブル１７に、一旦記憶する。

申請制御装置１は、申請されたデータを起票テーブル１７に一旦記憶した場合、承認端末装置１０に対して、申請されているデータの更新の承認申請を行う（図３の社員情報申請に相当）。承認者は、承認申請されたデータの更新の承認又は却下を決定し、承認端末装置１０を介して申請制御装置１に通知する。

申請制御装置１は、承認端末装置１０を介して承認されたデータのみを、起票テーブル１７から実テーブル１６に移行して、実テーブル１６のデータ構成を更新する。申請制御装置１は、承認者により承認されなかったデータは、起票テーブル１７から破棄（消去）し、実テーブル１６に対する更新を拒否（却下）する。これにより、承認者により承認されたデータのみを用いて、実テーブル１６のデータ構成を更新できる。

（管理者設定マスタの構成）
次に、図４は、実テーブル１６の更新の際に参照される管理者設定マスタ１１に対する承認者の設定を説明するための図である。一例ではあるが、管理者設定マスタ１１に対する設定は、図４（ａ）に示す東京本社側で行う。管理者設定マスタ１１に登録されたユーザ又は部署のユーザが、「管理者の承認なしで実データの更新権限を有するユーザ又は部署のユーザとなる。図４（ａ）及び図４（ｂ）の例は、「管理者の承認なしで実データの更新権限を有する「部署」として、東京人事部が、管理者設定マスタ１１に設定された例である。この場合、東京人事部の社員Ａ及び社員Ｂが、管理者の承認なしで実データの更新権限を有する。また、図４（ａ）及び図４（ｂ）の例は、「管理者の承認なしで実データの更新権限を有する「ユーザ」として、東京総務部の社員Ｃが、管理者設定マスタ１１に設定された例である。この場合、東京総務部の社員Ｃが、管理者の承認なしで実データの更新権限を有する。

業務オペレータ等により、管理者設定マスタ１１に対する承認者の設定が指定されると、表示制御部３６は、図４（ｂ）に示す管理者設定画面を出力装置７に表示する。業務オペレータは、この管理者設定画面を介して、承認者とする部署又はユーザを設定操作する。

図４（ｂ）の例は、行の上段のレコードが、承認権限のある「部署」が設定されていることを示している。すなわち、この上段のレコードは、２０２１年１２月１日に、東京人事部の部署に対して承認権限が設定されたことを示している。また、図４（ｂ）の例は、行の下段のレコードが、承認権限のある「ユーザ」が設定されていることを示している。すなわち、この下段のレコードは、ユーザＩＤが「ＵｓｅｒＩｄＣ」の「社員Ｃ」に対して、承認権限が設定されたことを示している。このように、管理者マスタ１１には、選択的に承認権限が付与された部署又はユーザを示す情報が記憶（設定）される。

図５は、管理者設定マスタ１１に登録される部署又はユーザの各種情報が、他のマスタから取得されて管理者設定マスタ１１に登録される様子を示す図である。この図５に示すように、上述の東京人事部の社員等から承認者とする部署が指定されると、マスタ設定部３１は、図５（ａ）に示す組織マスタ１３から組織コード及び組織改定日時を取得すると共に、図５（ｂ）に示すように部署マスタ１４から組織コード、組織改定日時、及び、部署コードを取得し、図５（ｃ）に示すように管理者設定マスタ１１に設定（登録）する。同様に、上述の東京人事部の社員等から承認者とするユーザが指定されると、マスタ設定部３１は、図５（ｄ）に示すようにユーザマスタ１５からユーザＩＤを取得し、図５（ｃ）に示すように管理者設定マスタ１１に設定（登録）する。

（申請種別カテゴリ割付マスタの設定）
次に、図６は、データの更新の際に参照される申請種別カテゴリ割付マスタ１２に対する、承認を必要とするテーブルの設定を説明するための図である。業務オペレータ等により、申請種別カテゴリ割付マスタ１２に対する承認を必要とするテーブルの設定が指定されると、表示制御部３６は、図６（ｂ）又は図６（ｃ）に示す申請種別・社員情報カテゴリ割付画面を出力装置７に表示する。業務オペレータは、この申請種別・社員情報カテゴリ割付画面を介して、承認を必要とする各テーブル（カテゴリ名）及び申請種別を関連付ける設定操作を行う。

図６（ｂ）の例は、申請種別コードが「ＣＤ１０１０」の「社員属性」の申請種別に対して、「基本」、「住所」、「家族」、「学歴」及び「帰省先」のカテゴリの各テーブルが、承認を必要とするテーブルとして設定された例である。また、図６（ｃ）の例は、申請種別コードが「ＣＤ１０２０」の「社会保険関連」の申請種別に対して、異なるカテゴリの各テーブルが、承認を必要とするテーブルとして設定された例である。すなわち、図６（ｃ）の例は、申請種別コードが「ＣＤ１０２０」の「社会保険関連」の申請種別に対して、「基本」、「家族」、「社会保険」及び「税表区分」のカテゴリの各テーブルが、承認を必要とするテーブルとして設定された例である。

図６（ａ）は、各申請種別の承認ルートの一例を示している。すなわち、図６（ａ）に点線で示す承認ルートＡは、申請種別コードが「ＣＤ１０１０」の社員属性の承認ルートを示している。例えば横浜支社の横浜総務部の社員Ｆ、及び、関西支社の社員Ｇによる社員属性のデータの更新は、東京人事部の社員Ａの最終承認を得るようになっている。

また、図６（ａ）に実線で示す承認ルートＢは、申請種別コードが「ＣＤ１０２０」の社員保険関連の承認ルートを示している。例えば、横浜支社の横浜総務部の社員Ｅ、及び、関西支社の社員Ｇによる社員保険関連のデータの更新は、東京総務部の社員Ｄの承認を得た後に、社員Ｃの最終承認を得るようになっている。

図７は、申請種別カテゴリ割付マスタ１２に、申請種別及びカテゴリ（テーブル）が関連付けされて登録される様子を示す図である。マスタ設定部３１は、図７（ａ）に示す申請種別グループマスタ１８及び図７（ｂ）に示す申請種別マスタ１９を参照して例えば「ＣＤ１０１０」等の申請種別コードを取得し、図７（ｃ）に示すように申請種別カテゴリ割付マスタ１２に設定（登録）する。

また、マスタ設定部３１は、図７（ｄ）に示すコードマスタ２０を参照することでテーブル名を取得し、図７（ｅ）に示す社員情報カテゴリマスタ２１を参照することで、カテゴリグループＩＤ、カテゴリＩＤ及び表示順を取得して、図７（ｃ）に示すように、申請種別カテゴリ割付マスタ１２に設定（登録）する。これにより、申請種別及びカテゴリ（テーブル）を関連付けして申請種別カテゴリ割付マスタ１２に登録することができる。

（データ更新動作）
次に、図８のフローチャートを用いて、申請制御装置１におけるデータの更新動作を説明する。制御部３は、記憶部２に記憶されている申請制御プログラムに基づいて、この図８のフローチャートに示す各処理を実行する。まず、ステップＳ１では、通信制御部３７が、申請端末装置９からネットワーク８を介して送信された、更新申請を行うデータを、通信インターフェース部４を介して受信し、取得部３２が、受信されたデータを取得する。

次に、取得されたデータには、申請を行っているユーザの部署情報、ユーザＩＤ、及び、申請種別を示す申請種別コードが付されている。このため、ステップＳ２では、権限判別部３３が、ステップＳ１で取得されたデータに付されているユーザの部署情報及びユーザＩＤに基づいて、図５（ｃ）に示す管理者設定マスタ１１を参照する。そして、取得されたデータに付されているユーザの部署情報又はユーザＩＤのうち、少なくとも一方が、管理者設定マスタ１１に登録されているか否かを判別する。

取得されたデータに付されているユーザの部署情報又はユーザＩＤのうち、少なくとも一方が、管理者設定マスタ１１に登録されているということは（ステップＳ２：Ｙｅｓ）、現在、申請を行っているユーザは、更新権限を有するユーザであることを示している。この場合、処理がステップＳ３に進み、記憶制御部３５が、申請されているデータのカテゴリに対応する実テーブル１６に対して、申請されたデータの更新を行う。

これに対して、取得されたデータに付されているユーザの部署情報又はユーザＩＤのうち、少なくとも一方が、管理者設定マスタ１１に登録されていないということは（ステップＳ２：Ｎｏ）、現在、申請を行っているユーザは、更新権限の無いユーザであることを示している。この場合、処理がステップＳ４に進み、記憶制御部３５が、申請されているデータのカテゴリに対応する起票テーブル１７に対して、申請されたデータを一旦記憶する（仮登録）。

通信制御部３７は、起票テーブル１７に対して、申請されたデータが記憶されると、承認端末装置１０と通信を行い、承認者に対して、現在、申請されているデータの更新の承認要求を行う。ステップＳ５では、記憶制御部３５が、承認者によりデータの更新が承認されたか否かを判別する。

承認者により、データの更新が承認された場合（ステップＳ５；Ｙｅｓ）、記憶制御部３５は、ステップＳ３において、現在、起票テーブル１７に一時的に記憶されているデータを、申請されているデータのカテゴリに対応する実テーブル１６に移行して更新を行う。これにより、承認者により承認された後のデータを、実テーブル１６に更新できるため、実テーブル１６のデータ構成を、正確なデータを用いて更新可能とすることができる。

これに対して、データの更新が、承認者により却下された場合（ステップＳ５；Ｎｏ）、ステップＳ６において、却下の処理が行われる。この却下の処理としては、例えば起票テーブル１７に一時的に記憶しているデータを記憶制御部３５が消去して、通信制御部３７が、申請を行ったユーザの申請端末装置９に対して、更新が承認されず、却下されたことを示すエラーメッセージを送信する。これにより、承認者により承認されなかったデータが実テーブル１６に更新される不都合を未然に防止でき、実テーブル１６のデータ構成を、正確なデータで更新可能とすることができる。

一方、ステップＳ２では、承認要否判別部３４が、現在、申請されているデータを更新するテーブルは、権限の無いユーザでも、更新が可能なテーブルに対するデータであるか否かを判別する。

すなわち、実施の形態の申請制御装置１の場合、申請されたデータは、そのデータのカテゴリと同じカテゴリの実テーブル１６に更新される。このため、承認要否判別部３４は、申請されたデータのカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されているか否かを判別する。

申請されたデータのカテゴリが、申請種別カテゴリ割付マスタ１２に登録されていないということは（ステップＳ２：Ｙｅｓ）、申請されたデータを更新しようとしている実テーブル１６は、データの更新に承認者の承認が不要であることを意味する。

このため、申請されたデータのカテゴリが、申請種別カテゴリ割付マスタ１２に登録されていない場合、記憶制御部３５は、ステップＳ３において、申請されたデータを、対応するカテゴリの実テーブル１６に更新する。

これに対して、申請されたデータのカテゴリが、申請種別カテゴリ割付マスタ１２に登録されているということは（ステップＳ２：Ｎｏ）、申請されたデータを更新しようとしている実テーブル１６は、データの更新に承認者の承認が必要であることを意味する。このため、記憶制御部３５は、ステップＳ４において、申請されているデータのカテゴリに対応する起票テーブル１７に、申請されたデータを一旦記憶する（仮登録）。

なお、テーブルとカテゴリは別の意味合いだが、実施の形態の申請制御装置１では、社員情報の登録の際に、属性をカテゴリとして分けて入力しており、１カテゴリ＝１テーブルとなることから、テーブル＝カテゴリの意味合いで説明を行う。

通信制御部３７は、起票テーブル１７に対して、申請されたデータが記憶されると、承認端末装置１０と通信を行い、承認者に対して、現在、申請されているデータの更新の承認要求を行う。ステップＳ５では、記憶制御部３５が、この承認者により、データの更新が承認されたか否かを判別する。承認者により、データの更新が承認された場合（ステップＳ５；Ｙｅｓ）、記憶制御部３５は、ステップＳ３において、現在、起票テーブル１７に一時的に記憶されているデータを、申請されているデータのカテゴリに対応する実テーブル１６に移行して更新を行う。これにより、承認者により承認された後のデータを実テーブル１６に更新できるため、実テーブル１６に対して正確なデータを更新可能とすることができる。

これに対して、データの更新が、承認者により却下された場合（ステップＳ５；Ｎｏ）、ステップＳ６において、却下の処理が行われる。この却下の処理としては、例えば起票テーブル１７に一時的に記憶しているデータを記憶制御部３５が消去して、通信制御部３７が、申請を行ったユーザの申請端末装置９に対して、更新が承認されず、却下されたことを示すエラーメッセージを送信する。これにより、承認者により承認されなかったデータが実テーブル１６に更新される不都合を未然に防止でき、実テーブル１６に対して正確なデータを更新可能とすることができる。

（更新の具体例）
図９は、東京本社の東京人事部の社員Ａにより、住所の登録申請が行われた場合の例である。図９（ａ）に示す東京本社の東京人事部は、図４を用いて説明したように、承認を行う部署として管理者設定マスタ１１に設定されている。このため、東京本社の東京人事部の社員Ａは、承認者としての権限を有する。このため、社員Ａにより、図９（ｂ）に示すように社員情報管理画面を介して住所の登録が申請された場合、他の承認者の承認を得ることなく、住所のカテゴリの実テーブル１６に、申請された住所のデータが登録される。

これに対して、図１０は、関西支社の関西総務部の社員Ｇにより、住所の登録申請が行われた場合の例である。図１０（ａ）に示す関西支社の関西総務部の社員Ｇは、図４を用いて説明したように、管理者として管理者設定マスタ１１に設定されていない。このため、承認要否判別部３４は、図１０（ｂ）に示すように社員情報管理画面を介して申請されたデータの「住所」のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されているか否かを判別する。

申請されたデータの住所のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されている場合、住所のカテゴリのデータを更新する実テーブル１６は、データの更新に承認者の承認を必要とする。このため、記憶制御部３５が、社員Ｇから申請された住所のデータを、図１０（ｃ）に示すように、住所のカテゴリの起票テーブル１７に、一旦記憶する。この起票テーブル１７に記憶された住所のデータは、承認者の承認後に、住所のカテゴリの実テーブル１６に移行され更新される。

図１１は、関西支社の関西総務部の社員Ｇにより、前職情報の登録申請が行われた場合の例である。図１１（ａ）に示す関西支社の関西総務部の社員Ｇは、図４を用いて説明したように、管理者として管理者設定マスタ１１に設定されていない。このため、承認要否判別部３４は、図１１（ｂ）に示すように社員情報管理画面を介して申請されたデータの「前職情報」のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されているか否かを判別する。

申請されたデータの前職情報のカテゴリが、図７（ｃ）に示した申請種別カテゴリ割付マスタ１２に登録されていない場合、前職情報のカテゴリのデータを更新する実テーブル１６は、データの更新に承認者の承認が不要となる。このため、記憶制御部３５が、社員Ｇから申請された前職情報のデータを、図１１（ｃ）に示すように、前職情報のカテゴリの実テーブル１６に更新する。

（管理者による申請又はカテゴリ未登録の場合の動作）
図１２は、データの更新に承認者の承認が不要な管理者により、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタ１２に、申請されたデータのカテゴリが登録されていない場合における、申請制御装置１の動作をまとめて示す図である。この場合、新規登録が申請されたデータは、図１２（ａ）に示すように、起票テーブル１７に一時的に記憶されることなく、直接、実テーブル１６に登録される。また、「修正」も同様であり、図１２（ｂ）に示すように、実テーブル１６に記憶されているデータを、自由に修正することができる。また、「削除」も同様であり、図１２（ｃ）に示すように、実テーブル１６に記憶されているデータを、自由に削除することができる。

（管理者以外のユーザによる申請又はカテゴリが登録されている場合の動作）
図１３は、データの更新に承認者の承認が必要なユーザにより、データの新規登録、修正、及び、削除が申請された場合、又は、申請種別カテゴリ割付マスタ１２に、申請されたデータのカテゴリが登録されている場合における、申請制御装置１の動作をまとめて示す図である。この場合、新規登録が申請されたデータは、図１３（ａ）に示すように、起票テーブル１７に一時的に記憶される。そして、承認者の承認が得られた際に、起票テーブル１７から実テーブル１６に移行され登録される。

また、「修正」も同様であり、図１３（ｂ）に示すように、修正に用いられるデータは、起票テーブル１７に一時的に記憶される。そして、承認者の承認が得られた際に、起票テーブル１７から実テーブル１６に移行され、所望のデータの修正が行われる。また、「削除」も同様であり、図１３（ｃ）に示すように、削除に用いられるデータは、起票テーブル１７に一時的に記憶される。そして、承認者の承認が得られた際に、起票テーブル１７から実テーブル１６に移行され所望のデータの削除が行われる。

（比較例の申請形態）
次に、図１４に、実施の形態の申請制御システムに対して比較例となる申請制御システムの申請形態を示す。この図１４に示すように、比較例となる申請制御システムの場合、例えば人事諸届のように、申請種別(家族異動届、結婚届、住所変更届、改姓改名届等）によっては、関西支社等の拠点担当者（社員Ｇ）であっても、図１４に実線のルートで示すように、特定のテーブルに対する申請を本人が行うことができる。しかし、図１４に点線のルートで示すように、拠点担当者（社員Ｇ）が、様々な社員の属性情報を、任意に組み合わせて一括して申請することは困難であった。

（実施の形態の申請制御装置の一括申請動作）
これに対して、実施の形態の申請制御システムは、複数の申請を任意に組み合わせ、一括して行うことが可能となっている。図１５は、このような申請制御システムにおける申請制御装置１の一括申請動作の流れを示すフローチャートである。まず、実テーブル１６を更新する際に承認者の承認を必要とするデータは、上述のように、そのデータの種別に対応するカテゴリの起票テーブル１７に一旦記憶される。ステップＳ１１において、取得部３２が、各カテゴリの起票テーブル１７に一旦記憶されているデータに、承認未申請データが存在するか否かを判別する。

各カテゴリの起票テーブル１７に承認未申請データが存在する場合（ステップＳ１1：Ｙｅｓ）、取得部３２は、各カテゴリの起票テーブル１７に存在する承認未申請データをそれぞれ取得する（ステップＳ１２）。そして、表示制御部３６が、取得された承認未申請データを社員情報申請画面に一覧表示する（ステップＳ１３）。

具体的には、図１７（ａ）に示す関西支社の社員Ｇにより社員情報の申請操作が行われると、表示制御部３６は、図１７（ｂ）に例示する社員情報申請画面を出力装置７に表示する。関西支社の社員Ｇは、この社員情報申請画面で「抽出条件」を設定することで、所望の属性の承認未申請データを選択して一覧表示することができる。

図１７（ｂ）は、申請種別が「ＣＤ１０１０」の社員属性の承認未申請データの抽出を指定した例である。この場合、取得部３２は、図１６に示す申請種別カテゴリ割付マスタ１２で示される、申請種別コードが「ＣＤ１０１０」の承認未申請データを、「社員基本」、「住所」、「家族」及び「前職」等の各カテゴリの起票テーブル１７ａ～１７ｄ・・・から取得する。

なお、図１６の例は、「社員基本」の起票テーブル１７ａに、承認未申請データが存在しないことを示している。この場合、取得部３２は、「社員基本」のカテゴリの起票テーブル１７から、申請種別が「ＣＤ１０１０」の社員属性の承認未申請データは取得しない（取得できない）。また、申請種別コードとして「ＣＤ１０１０」が指定された場合、図１６に示す「ＣＤ１０２０」の申請種別コードの承認未申請データは、抽出が指定された承認未申請データではない。このため、取得部３２は、各カテゴリの起票テーブル１７ａ～１７ｄ・・・から、「ＣＤ１０２０」の申請種別コードの承認未申請データは取得しない。

このように、取得部３２により、指定した申請種別の承認未申請データが取得されると、表示制御部３６は、図１７に示すように、処理日時、処理内容、社員コード、氏名、カテゴリ及び案件内容情報を含む承認未申請データを一覧表示する。また、表示制御部３６は、所望の承認未申請データを選択するためのチェックボックスを、各承認未申請データに隣接させて表示する。関西支社の社員Ｇは、一覧表示された各承認未申請データのうち、チェックボックスに対してチェックを入力操作することで、承認を一括申請する承認未申請データを選択する（申請選択操作）。

図１５のフローチャートのステップＳ１４では、データ生成部３８が、このような承認選択操作の有無を監視している。申請選択操作が無い場合、ステップＳ１８で社員情報申請画面の表示終了操作を検出したタイミングで（ステップＳ１８：Ｙｅｓ）、この図１５のフローチャートの全処理が終了となる。

これに対して、未申請一覧の中から承認申請を行う承認未申請データが選択され、図１７（ｂ）の社員情報申請画面に表示された申請ボタン５０が操作されると（ステップＳ１４：Ｙｅｓ）、データ生成部３８は、選択された承認未申請データの社員毎に、申請状態を管理するための案件データを生成する（ステップＳ１５）。

具体的には、図１７（ｂ）の例の場合、社員コードが「００００１」で氏名が「山田太郎」の「住所」及び「家族」のカテゴリの承認未申請データが選択された例である。この場合、記憶制御部３５は、図１８（ａ）に示すように、社員コードが「００００１」の社員用の案件テーブル２２ａを記憶部２に生成し、この案件テーブル２２ａに、データ生成部３８により生成された、社員コードが「００００１」の社員の「住所」及び「家族」の各カテゴリの承認未申請データの申請状態を示す案件データを記憶する。

同様に、図１７（ｂ）の例の場合、社員コードが「００００２」で氏名が「鈴木一」の「学歴」のカテゴリの承認未申請データが選択された例である。この場合、記憶制御部３５は、図１８（ｂ）に示すように、社員コードが「００００２」の社員用の案件テーブル２２ｂを記憶部２に生成し、この案件テーブル２２ｂに、データ生成部３８により生成された、社員コードが「００００２」の社員の「学歴」のカテゴリの承認未申請データの申請状態を示す案件データを記憶する。

このように、案件テーブル２２に案件データを記憶することで、実テーブル１６に対する更新の承認を一括申請することができる（ステップＳ１６）。この承認申請により、承認者により承認が得られた場合、上述のように、起票テーブル１７に記憶されている起票データに基づいて、実テーブル１６のデータ構成が更新される。または、承認者により承認が得られなかった場合は、上述のように実テーブル１６のデータ構成の更新は却下される。

もう少し詳しく実テーブル１６の更新動作を説明すると、図１９は、各カテゴリの起票テーブル１７に記憶されている承認申請前の承認未申請データ（起票データ）の一例を示す図である。このうち、図１９（ａ）は、社員コードが「００００１」の社員の「住所」のカテゴリの起票テーブル１７ｂに記憶されている起票データを示している。また、図１９（ｂ）は、社員コードが「００００１」の社員の「家族」のカテゴリの起票テーブル１７ｃに記憶されている起票データを示している。また、図１９（ｃ）は、社員コードが「００００２」の社員の「学歴」のカテゴリの起票テーブル１７に記憶されている起票データを示している。

この図１９（ａ）～図１９（ｃ）から分かるように、各カテゴリの起票テーブル１７に記憶されている起票データは、案件データに対して付される固有番号である案件Ｇｕｉｄ、キーＧｕｉｄ、申請処理区分、申請状態、社員コード、及び、社員ＳＥＱ等を含んで構成されている。承認申請前においては、案件データの生成前であるため、各起票データの案件Ｇｕｉｄには「ＡＬＬ０」のデータが付され、また、申請情報としては「０：未申請」の申請状態情報が付される。

図２０は、承認申請後の案件データ、及び、起票テーブル１７に記憶されている各社員の起票データを示している。このうち、図２０（ｂ）は、社員コードが「００００１」の社員の「住所」のカテゴリの起票データを示し、図２０（ｃ）は、社員コードが同じ「００００１」の社員の「家族」のカテゴリの起票データを示している。

図２０（ａ）の上段の行のレコードは、この社員コードが「００００１」の社員用の案件データを示している。承認申請が行われると、データ生成部３８は、図２０（ａ）の上段の行のレコードに示すように「ＢＢＢＢ１（Ｇｕｉｄ）」等の固有の案件Ｇｕｉｄを案件データに付す。また、データ生成部３８は、承認申請前において、図１９（ａ）及び図１９（ｂ）に示すように「０：未申請」の申請状態情報を、承認申請後においては、図２０（ａ）、図２０（ｂ）及び図２０（ｃ）に示すように、「１０：申請中」等のように案件データ及び起票データの申請状態情報を更新する。

同様に、図２０（ｄ）は、社員コードが「００００２」の社員の「学歴」のカテゴリの起票データを示している。図２０（ａ）の下段の行のレコードは、この社員コードが「００００２」の社員用の案件データを示している。承認申請が行われると、データ生成部３８は、図２０（ａ）の下段の行のレコードに示すように「ＣＣＣＣ２（Ｇｕｉｄ）」等の固有の案件Ｇｕｉｄを案件データに付す。

また、データ生成部３８は、承認申請前において、図１９（ｃ）に示すように「０：未申請」としていた申請状態情報を、承認申請後においては、図２０（ａ）の下段のレコード及び図２０（ｄ）に示すように、「１０：申請中」等のように案件データ及び起票データの申請状態情報を更新する。

このような承認申請により、承認者により承認されると、起票テーブル１７に記憶されている起票データに基づいて、実テーブル１６のデータ構造が更新されることは、上述のとおりである。

（申請内容データの生成）
次に、上述の承認申請が行われると、データ生成部３８は、図１５のフローチャートのステップＳ１７において、申請内容を印刷又は表示するための申請内容データを生成する。図２１は、生成された申請内容データを用紙に印刷した例を示す図である。この図２１の例は、社員コードが「００００１」の「山田太郎」が、「住所」のカテゴリの追加申請を行い、「家族」の修正の申請を行ったことを示している。このような申請内容データを生成することで、申請者は申請内容の確認を行うことができる。

（申請データの承認及び却下）
次に、申請データの承認動作及び却下動作を説明する。例えば、図２２（ａ）に示すように、東京人事部の社員Ａ（最終承認者）により、上述のように起票テーブル１７から取得された、図２２（ｂ）に示す承認未申請データが検討されたとする。そして、最終承認者である社員Ａにより、図２２（ｂ）の一覧の上段の列の明細（レコード）である、「コード００００１の住所及び家族のカテゴリの承認未申請データが承認されたとする。また、最終承認者である社員Ａにより、図２２（ｂ）の一覧の下段の列の明細（レコード）である、「コード００００２の学歴のカテゴリの承認未申請データの承認は却下されたとする。

なお、承認者は、承認未申請データの承認又は却下を行う場合、未承認一覧選択画面の「承認」のチェックボックス又は「却下」のチェックボックスのいずれかにチェックを入れるように、入力装置６を入力操作する。

また、図２２（ｂ）に示す未承認一覧選択画面において、出力ボタン６０が操作されると、図２１を用いて説明したように、申請内容の印刷又は表示が行われる。また、図２２（ｂ）に示す未承認一覧選択画面において、詳細ボタン６１が操作されると、通信制御部３６が、図１１（ｂ）に示したような社員管理画面を表示して変更内容を表示する。

図２３は、承認未申請データの承認が行われた場合、及び、却下された場合における案件テーブル２２，実テーブル１６及び起票テーブル１７に対するデータ形態（データ構成）の変更制御を説明するための模式図である。このうち、図２３（ａ）は、承認未申請データの承認された場合の例である。承認未申請データが承認されると、変更制御部の一例である記憶制御部３５は、図２４（ａ）に示すように、案件テーブル２２の案件データの申請状態を「５０：完了」に変更する。また、記憶制御部３５は、図２３（ａ）に示すように、承認された承認未申請データのカテゴリである、例えば「住所」のカテゴリ及び「家族」のカテゴリの起票テーブル１７ｂ、１７ｃから、それぞれ承認未申請データのレコードを削除する。そして、記憶制御部３５は、承認された「住所」のカテゴリ及び「家族」のカテゴリの承認未申請データを、「住所」のカテゴリ及び「家族」のカテゴリの実テーブル１６ｂ、１６ｃに書き込む。

すなわち、この例で説明すると、図２４（ｂ）に示すように、承認された「住所」のカテゴリの承認未申請データは起票テーブル１７ｂから削除され、図２４（ｃ）に示すように「住所」のカテゴリの実テーブル１６ｂに記憶される（レコード追加）。同様に、図２４（ｄ）に示すように、承認された「家族」のカテゴリの承認未申請データは起票テーブル１７ｃから削除され、図２４（ｅ）に示すように「家族」のカテゴリの実テーブル１６ｂに記憶される（レコード更新）。

これに対して、図２３（ｂ）は、承認未申請データが却下された場合の例である。承認未申請データが却下されると、記憶制御部３５は、図２５（ａ）に示すように、案件テーブル２２の案件データの申請状態を「３０：却下」に変更する。また、記憶制御部３５は、図２３（ｂ）に示すように、却下された承認未申請データのカテゴリである、例えば「学歴」のカテゴリの起票テーブル１７ｆに記憶されている承認未申請データの申請状態を、図２５（ｂ）に示すように「３０：却下」に更新する。これにより、実テーブル１６ｆに対して、却下されてデータが書き込まれる不都合を防止できる。

（却下又は引戻された起票データの破棄又は修正）
次に、例えば図２６（ａ）に示す関西支社の関西総務部の社員Ｇの申請が却下又は引戻されたとすると、この社員Ｇは、却下又は引戻された申請の破棄を行う。または、社員Ｇは、却下又は引戻された申請を修正して、再申請を行う。

却下又は引戻された申請の破棄が行われると、記憶制御部３５は、図２７（ａ）に示すように、案件テーブル２２に記憶されている、破棄された承認未申請データの案件データの申請状態を「破棄」に更新すると共に、破棄された例えば「学歴」のカテゴリの承認未申請データを、「学歴」のカテゴリの起票テーブル１７ｆから削除する。図２８（ａ）は、破棄された承認未申請データの案件データの申請状態が、「６０：破棄」に更新された様子を示す図である。また、図２８（ｂ）は、学歴のカテゴリの起票テーブル１７ｆから、破棄された承認未申請データのレコードが削除された様子を示す図である。

一方、破棄された申請の再申請を行う場合、社員Ｇは、図２６（ｂ）に示すように、社員情報申請画面の「却下・引戻一覧」を選択し、却下又は引戻された申請の一覧を表示する。社員Ｇは、却下又は引戻された申請の一覧の中から所望の申請を選択して修正を行い、再申請を行う。

すなわち、申請の修正の場合、記憶制御部３５は、図２７（ｂ）に示すように案件テーブル２２の案件データを「破棄」とし、修正される例えば「学歴」のカテゴリの起票テーブル１７ｆのデータの申請状態を「未申請」に変更する。図２９（ａ）は、修正の場合の、案件データを示しており、この図２９（ａ）に示すように記憶制御部３５は、案件データの先生状態を「６０：破棄」とする。また、これと共に、記憶制御部３５は、図２９（ｂ）に示すように、例えば「学歴」のカテゴリの、過去に申請して引戻されたデータの案件Ｇｕｉｄｅを「ＡＬＬ０」の初期状態に戻すと共に、申請状態を「０：未申請」に戻す。これにより、過去に申請して引戻されたデータの再申請が可能となる。

再申請が可能となると、社員Ｇは、図３０（ａ）に示すように、社員情報管理画面から、再申請を行う例えば「学歴」のカテゴリを選択して所定の項目に所定のデータを再入力する。そして、図３０（ｂ）に示すように、未申請一覧として表示される、再入力した「学歴」のカテゴリのデータに基づいて再申請を行う。これにより、記憶制御部３５により、再申請された「学歴」のカテゴリのデータが承認未申請データとして起票テーブル１７ｆに記憶され、承認申請され、承認された際に、「学歴」のカテゴリの実テーブル１６ｆに記憶される。

（データの照会機能）
ここで、例えば図３１（ａ）に示すように、関西支社の関西営業部の鈴木一社員が住所訂正届の申請を行ったとする。そして、この申請は、関西総務部の社員Ｇの承認後に、東京本社の東京人事部の社員Ａの最終承認が必要となることとする。東京人事部の社員Ａの最終承認が得られることで、図３１（ｂ）に示す起票テーブル１７の承認未申請データ（起票データ）が、図３１（ｃ）に示すように実テーブル１６に記憶されて照会可能となる。このため、申請から最終承認が得られるまでの間は、鈴木一社員の新居の住所を照会することができず、申請から照会可能となるまでの間のタイムラグにより、業務に支障が出る恐れがある。

このため、実施の形態の申請制御装置１の表示制御部３６は、図３２（ａ）に示すように、東京人事部の社員Ａ又は関西支社の社員Ｇ等からデータの照会があり、図３２（ｄ）に示すように、起票テーブル１７に起票データである承認未申請データ又は承認中データが存在する場合は、表示制御部３６は、図３２（ｂ）に示す状態名称表示欄７０に、図３３～図３５を用いて後述する、例えば「修正（未申請）」等の、申請処理区分又は申請状態に応じた状態名称を表示する。これにより、社員情報管理を照会している担当者は、表示している各カテゴリの実データ又は起票データの区別だけでなく、申請の状態も判断できる。また、表示制御部３６は、承認未申請データ等の起票データが起票テーブル１７に記憶されていない場合は、実テーブル１６から図３２（ｃ）に示すような実データを読み出し、これを図３２（ｂ）に示すように表示する。これにより、申請から最終承認までの間も、データの照会を可能とすることができ、業務に支障が出る不都合を防止できる。

（データの追加に関するジョブの流れ）
次に、図３３に、このような実施の形態の申請制御装置１におけるデータの追加に関するジョブの流れを示す。この図３３に示すように、追加～最終承認までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを追加→「社員情報申請」にて起票データの申請→「未承認一覧」にて起票データの承認→「未承認一覧」にて起票データの最終承認との流れとなる。

また、追加～最終承認までのジョブの流れの間において、拠点担当者は、データ追加の段階では、該当データの編集が可能（追加（未申請）と表示）であり、申請中は、該当データの編集が不可（追加（申請中）と表示）となっている。また、拠点担当者は、最終承認前の承認の段階では、該当データの編集が不可（追加（承認中と表示）であり、最終承認の段階では、該当データの編集が可能となっている。

これに対して、本部の管理者は、データ追加の段階では、該当データの編集が不可（追加（未申請）と表示）であり、申請中も、該当データの編集は不可（追加（申請中）と表示）となっている。また、本部の管理者は、最終承認前の承認の段階では、該当データの編集が不可（追加（承認中）と表示）であり、最終承認の段階では、該当データの編集が可能となっている。

また、図３３に示すように、追加～却下・破棄までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを追加→「社員情報申請」にて起票データの申請→「未承認一覧」にて起票データの却下→「社員情報申請」にて起票データの破棄との流れとなる。

また、この追加～却下・破棄までのジョブの流れの間、拠点担当者は、データ追加の段階では、該当データの編集が可能（追加（未申請）と表示）であり、申請中は、該当データの編集が不可（追加（申請中）と表示）となっている。また、拠点担当者は、却下の段階では、該当データの編集が不可（追加（却下）と表示）であり、破棄の段階では、該当データの参照は不可で新規にデータの追加は可能となっている。

これに対して、本部の管理者は、データ追加の段階では、該当データの編集が不可（追加（未申請）と表示）であり、申請中も、該当データの編集は不可（追加（申請中）と表示）となっている。また、本部の管理者は、却下の段階では、該当データの編集が不可（追加（却下）と表示）であり、破棄の段階では、該当データの参照は不可であるが、新規のデータの追加は可能となっている。

また、図３３に示すように、追加～引戻・破棄までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを追加→「社員情報申請」にて起票データの申請→「申請一覧」にて起票データの引戻→「社員情報申請」にて起票データの破棄との流れとなる。

また、この追加～引戻・破棄までのジョブの流れの間、拠点担当者は、データ追加の段階では、該当データの編集が可能（追加（未申請）と表示）であり、申請中は、該当データの編集が不可（追加（申請中）と表示）となっている。また、拠点担当者は、引戻の段階では、該当データの編集が不可（追加（引戻）と表示）であり、破棄の段階では、該当データの参照は不可で新規にデータの追加は可能となっている。

これに対して、本部の管理者は、データ追加の段階では、該当データの編集が不可（追加（未申請）と表示）であり、申請中も、該当データの編集は不可（追加（申請中）と表示）となっている。また、本部の管理者は、引戻の段階では、該当データの編集が不可（追加（引戻）と表示）であり、破棄の段階では、該当データの参照は不可であるが、新規のデータの追加は可能となっている。

（データの修正に関するジョブの流れ）
次に、図３４に、このような実施の形態の申請制御装置１におけるデータの修正に関するジョブの流れを示す。この図３４に示すように、修正～最終承認までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを修正→「社員情報申請」にて起票データの申請→「未承認一覧」にて起票データの承認→「未承認一覧」にて起票データの最終承認との流れとなる。

また、修正～最終承認までのジョブの流れの間において、拠点担当者は、データ修正の段階では、該当データの編集が可能（修正（未申請）と表示）であり、申請中は、該当データの編集が不可（修正（申請中）と表示）となっている。また、拠点担当者は、最終承認前の承認の段階では、該当データの編集が不可（修正（承認中）と表示）であり、最終承認の段階では、該当データの編集が可能となっている。

これに対して、本部の管理者は、データ修正の段階では、該当データの編集が不可（修正（未申請）と表示）であり、申請中も、該当データの編集は不可（修正（申請中）と表示）となっている。また、本部の管理者は、最終承認前の承認の段階では、該当データの編集が不可（修正（承認中）と表示）であり、最終承認の段階では、該当データの編集が可能となっている。

また、図３４に示すように、修正～却下・破棄までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを修正→「社員情報申請」にて起票データの申請→「未承認一覧」にて起票データの却下→「社員情報申請」にて起票データの破棄との流れとなる。

また、この修正～却下・破棄までのジョブの流れの間、拠点担当者は、データ修正の段階では、該当データの編集が可能（修正（未申請）と表示）であり、申請中は、該当データの編集が不可（修正（申請中）と表示）となっている。また、拠点担当者は、却下の段階では、該当データの編集が不可（修正（却下）と表示）であり、破棄の段階では、該当データの編集が可能（データ内容は修正前の内容）となっている。

これに対して、本部の管理者は、データ修正の段階では、該当データの編集が不可（修正（未申請）と表示）であり、申請中も、該当データの編集は不可（修正（申請中）と表示）となっている。また、本部の管理者は、却下の段階では、該当データの編集が不可（修正（却下）と表示）であり、破棄の段階では、該当データの編集が可能（データ内容は修正前の内容）となっている。

また、図３４に示すように、修正～引戻・破棄までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを修正→「社員情報申請」にて起票データの申請→「申請一覧」にて起票データの引戻→「社員情報申請」にて起票データの破棄との流れとなる。

また、この修正～引戻・破棄までのジョブの流れの間、拠点担当者は、データ修正の段階では、該当データの編集が可能（修正（未申請）と表示）であり、申請中は、該当データの編集が不可（修正（申請中）と表示）となっている。また、拠点担当者は、引戻の段階では、該当データの編集が不可（修正（引戻）と表示）であり、破棄の段階では、該当データの編集は可能（データ内容は修正前の内容）となっている。

これに対して、本部の管理者は、データ修正の段階では、該当データの編集が不可（修正（未申請）と表示）であり、申請中も、該当データの編集は不可（修正（申請中）と表示）となっている。また、本部の管理者は、引戻の段階では、該当データの編集が不可（修正（引戻）と表示）であり、破棄の段階では、該当データの編集は可能（データ内容は修正前の内容）となっている。

（データの削除に関するジョブの流れ）
次に、図３５に、このような実施の形態の申請制御装置１におけるデータの削除に関するジョブの流れを示す。この図３５に示すように、削除～最終承認までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを削除→「社員情報申請」にて起票データの申請→「未承認一覧」にて起票データの承認→「未承認一覧」にて起票データの最終承認との流れとなる。

また、削除～最終承認までのジョブの流れの間において、拠点担当者は、データ削除の段階では、該当データの編集が不可（削除（未申請）と表示）であり、申請中も、該当データの編集は不可（削除（申請中）と表示）となっている。また、拠点担当者は、最終承認前の承認の段階では、該当データの編集は不可（削除（承認中）と表示）であり、最終承認の段階では、該当データの参照が不可で、新規データの追加は可能となっている。

これに対して、本部の管理者は、データ削除の段階では、該当データの編集が不可（削除（未申請）と表示）であり、申請中も、該当データの編集は不可（削除（申請中）と表示）となっている。また、本部の管理者は、最終承認前の承認の段階では、該当データの編集が不可（削除（承認中）と表示）であり、最終承認の段階では、該当データの参照が不可で、新規データの追加は可能となっている。

また、図３５に示すように、削除～却下・破棄までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを削除→「社員情報申請」にて起票データの申請→「未承認一覧」にて起票データの却下→「社員情報申請」にて起票データの破棄との流れとなる。

また、この削除～却下・破棄までのジョブの流れの間、拠点担当者は、データ削除の段階では、該当データの編集が不可（削除（未申請）と表示）であり、申請中も、該当データの編集は不可（削除（申請中）と表示）となっている。また、拠点担当者は、却下の段階では、該当データの編集が不可（削除（却下）と表示）であり、破棄の段階では、該当データの編集が可能（データ内容は削除前の内容）となっている。

これに対して、本部の管理者は、データ削除の段階では、該当データの編集が不可（削除（未申請）と表示）であり、申請中も、該当データの編集は不可（削除（申請中）と表示）となっている。また、本部の管理者は、却下の段階では、該当データの編集が不可（削除（却下）と表示）であり、破棄の段階では、該当データの編集が可能（データ内容は削除前の内容）となっている。

また、図３５に示すように、削除～引戻・破棄までのジョブの流れとしては、関西支社等の拠点の社員が「社員情報管理」にてデータを削除→「社員情報申請」にて起票データの申請→「申請一覧」にて起票データの引戻→「社員情報申請」にて起票データの破棄との流れとなる。

また、この削除～引戻・破棄までのジョブの流れの間、拠点担当者は、データ削除の段階では、該当データの編集が不可（削除（未申請）と表示）であり、申請中も、該当データの編集が不可（削除（申請中）と表示）となっている。また、拠点担当者は、引戻の段階では、該当データの編集が不可（削除（引戻）と表示）であり、破棄の段階では、該当データの編集は可能（データ内容は削除前の内容）となっている。

これに対して、本部の管理者は、データ削除の段階では、該当データの編集が不可（削除（未申請）と表示）であり、申請中も、該当データの編集は不可（削除（申請中）と表示）となっている。また、本部の管理者は、引戻の段階では、該当データの編集が不可（削除（引戻）と表示）であり、破棄の段階では、該当データの編集は可能（データ内容は削除前の内容）となっている。

（データの追加時におけるデータ更新動作）
次に、図３６に、データの追加時における実データ、案件テーブル２２、起票データに対する更新動作を示す。まず、追加～最終承認までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータを追加する場合、
・実データにはレコードの追加は行わず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する(申請処理区分１：追加／申請状態０：未申請）。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）及び申請状態（１０：申請中）を更新する。

また、「未承認一覧」にて起票データの承認を行う場合、
・案件テーブル２２の申請状態（２０：承認中）を更新し、
・起票データの申請状態（２０：承認中）を更新する。

また、「未承認一覧」にて起票データの最終承認を行う場合、
・実データに起票データのレコード内容から追加を行い、
・起票データのレコードを削除し、
・案件テーブル２２の申請状態（５０：完了）を更新する。

次に、追加～却下・破棄までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータの追加を行う場合、
・実データにはレコードの追加は行わず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する(申請処理区分１：追加／申請状態０：未申請）。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）、及び、申請状態（１０：申請中）を更新する。

また、「未承認一覧」にて起票データを却下する場合、
・案件テーブル２２の申請状態（３０：却下）を更新し、
・起票データの申請状態（３０：却下）を更新する。

また、「社員情報申請」にて起票データの破棄する場合、
・案件テーブル２２の申請状態（６０：破棄）を更新し、
・起票データのレコードを削除する。

次に、追加～引戻・破棄までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータを追加する場合、
・実データにはレコードの追加は行わず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する（申請処理区分１：追加／申請状態０：未申請）。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）、及び、申請状態（１０：申請中）を更新する。

また、「申請一覧」にて起票データの引戻を行う場合、
・案件テーブル２２の申請状態（４０：引戻）を更新し、
・起票データの申請状態（４０：引戻）を更新する。

また、「社員情報申請」にて起票データを破棄する場合、
・案件テーブル２２の申請状態（６０：破棄）を更新し、
・起票データのレコードを削除する。

（データの修正時におけるデータ更新動作）
次に、図３７に、データの修正時における実データ、案件テーブル２２、起票データに対する更新動作を示す。まず、修正～最終承認までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータを修正する場合、
・実データにはレコードの更新は行わず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する(申請処理区分２：修正／申請状態０：未申請）。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）及び申請状態（１０：申請中）を更新する。

また、「未承認一覧」にて起票データの承認を行う場合、
・案件テーブル２２の申請状態（２０：承認中）を更新し、
・起票データの申請状態（２０：承認中）を更新する。

また、「未承認一覧」にて起票データの最終承認を行う場合、
・実データに起票データのレコード内容から更新を行い、
・起票データのレコードを削除し、
・案件テーブル２２の申請状態（５０：完了）を更新する。

次に、修正～却下・破棄までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータの修正を行う場合、
・実データにはレコードの更新は行わず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する(申請処理区分２：修正／申請状態０：未申請）。

なお、未申請の同一キーの起票データが存在した場合は、起票テーブル１７を更新する。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）、及び、申請状態（１０：申請中）を更新する。

また、「未承認一覧」にて起票データを却下する場合、
・案件テーブル２２の申請状態（３０：却下）を更新し、
・起票データの申請状態（３０：却下）を更新する。

また、「社員情報申請」にて起票データの破棄する場合、
・案件テーブル２２の申請状態（６０：破棄）を更新し、
・起票データのレコードを削除する。

次に、修正～引戻・破棄までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータを修正する場合、
・実データにはレコードの更新は行わず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する（申請処理区分２：修正／申請状態０：未申請）。

なお、未申請の同一キーの起票データが存在した場合は、起票テーブル１７を更新する。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）、及び、申請状態（１０：申請中）を更新する。

また、「申請一覧」にて起票データの引戻を行う場合、
・案件テーブル２２の申請状態（４０：引戻）を更新し、
・起票データの申請状態（４０：引戻）を更新する。

また、「社員情報申請」にて起票データを破棄する場合、
・案件テーブル２２の申請状態（６０：破棄）を更新し、
・起票データのレコードを削除する。

（データの削除時におけるデータ更新動作）
次に、図３８に、データの削除時における実データ、案件テーブル２２、起票データに対する更新動作を示す。まず、削除～最終承認までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータを削除する場合、
・実データのレコードは削除せず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する(申請処理区分３：削除／申請状態０：未申請）。

なお、未申請の同一キーの起票データが存在した場合は、起票テーブル１７を更新する。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２紐づけのキー）及び申請状態（１０：申請中）を更新する。

また、「未承認一覧」にて起票データの承認を行う場合、
・案件テーブル２２の申請状態（２０：承認中）を更新し、
・起票データの申請状態（２０：承認中）を更新する。

また、「未承認一覧」にて起票データの最終承認を行う場合、
・実データに対してレコードの削除を行い、
・起票データのレコードを削除し、
・案件テーブル２２の申請状態（５０：完了）を更新する。

次に、削除～却下・破棄までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータの削除を行う場合、
・実データのレコードは削除せず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する(申請処理区分３：削除／申請状態０：未申請）。

なお、未申請の同一キーの起票データが存在した場合は、起票テーブル１７を更新する。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）、及び、申請状態（１０：申請中）を更新する。

また、「未承認一覧」にて起票データを却下する場合、
・案件テーブル２２の申請状態（３０：却下）を更新し、
・起票データの申請状態（３０：却下）を更新する。

また、「社員情報申請」にて起票データの破棄する場合、
・案件テーブル２２の申請状態（６０：破棄）を更新し、
・起票データのレコードを削除する。

次に、削除～引戻・破棄までのジョブに対する、実データ、案件テーブル２２、起票データの更新動作としては、「社員情報管理」にてデータを削除する場合、
・実データのレコードは削除せず、
・案件テーブル２２にも申請前なのでレコードの追加は行わず、
・起票データにレコードを追加する（申請処理区分３：削除／申請状態０：未申請）。

なお、未申請の同一キーの起票データが存在した場合は、起票テーブル１７を更新する。

また、「社員情報申請」にて起票データの申請を行う場合、
・案件テーブル２２にレコードを追加し、
・起票データの案件Ｇｕｉｄ（案件テーブル２２の紐づけのキー）、及び、申請状態（１０：申請中）を更新する。

また、「申請一覧」にて起票データの引戻を行う場合、
・案件テーブル２２の申請状態（４０：引戻）を更新し、
・起票データの申請状態（４０：引戻）を更新する。

また、「社員情報申請」にて起票データを破棄する場合、
・案件テーブル２２の申請状態（６０：破棄）を更新し、
・起票データのレコードを削除する。

（実施の形態の効果）
以上の説明から明らかなように、実施の形態の申請制御装置１は、申請種別に複数のテーブル（カテゴリ）を自由に組み合わせて関連付けることで、複数の属性情報の申請を一括して行うことができる。これにより、例えば拠点担当者が、各社員の属性情報を任意に組み合わせて一括して申請することを可能とすることができる。

また、テーブル(カテゴリ）単位に申請可否を設定できるため、例えば考課情報は上長の承認ルート、住所又は家族情報は人事部の承認ルート等のように、社員の属性情報単位毎に承認ルートを設定でき、申請から承認までをスムーズに行うことができる。

また、データの照会要求があった際に、起票テーブル１７に起票データである承認未申請データ又は承認中データが存在する場合は、この起票テーブル１７の承認未申請データ又は承認中データを表示し、起票テーブル１７に承認未申請データ又は承認中データが存在しない場合は、実テーブル１６の実データを表示する。これにより、申請が最終承認されるまで、最新の社員情報を、拠点及び本部で照会不可となる不都合を防止でき、業務に支障が出る不都合を防止できる。

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

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

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

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

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

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

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

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

また、この申請制御装置１の申請制御プログラムは、申請制御装置１に対して任意のネットワークを介して接続された他のサーバ装置に記憶されていてもよく、必要に応じてその全部又は一部をダウンロードすることも可能である。

また、本実施形態で説明した処理を実行するための申請制御プログラムを、一時的でないコンピュータ読み取り可能な記録媒体に格納してもよく、また、プログラム製品として構成することもできる。ここで、この「記録媒体」とは、メモリーカード、ＵＳＢ（Universal Serial Bus）メモリ、ＳＤ（Secure Digital）カード、フレキシブルディスク、光磁気ディスク、ＲＯＭ、ＥＰＲＯＭ（Erasable Programmable Read Only Memory）、ＥＥＰＲＯＭ（登録商標）（Electrically Erasable and Programmable Read Only Memory）、ＣＤ－ＲＯＭ（Compact Disk Read Only Memory）、ＭＯ（Magneto-Optical Disk）、ＤＶＤ（Digital Versatile Disk）、及び、Blu-ray（登録商標） Disc等の任意の「可搬用の物理媒体」を含むものとする。

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

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

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

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

本発明は、例えばワークフローシステムを用いた各種申請業務等に有用である。

１ 申請制御装置
２ 記憶部
３ 制御部
４ 通信インターフェース部
５ 入出力インターフェース部
６ 入力装置
７ 出力装置
８ ネットワーク
９ 申請端末装置
１０ 承認端末装置
１１ 管理者設定マスタ
１２ 申請種別カテゴリ割付マスタ
１３ 組織マスタ
１４ 部署マスタ
１５ ユーザマスタ
１６ 実テーブル
１７ 起票テーブル
１８ 申請種別グループマスタ
１９ 申請種別マスタ
２０ コードマスタ
２１ 社員情報カテゴリマスタ
２２ 案件テーブル
３１ マスタ設定部
３２ 取得部
３３ 権限判別部
３４ 承認要否判別部
３５ 記憶制御部
３６ 表示制御部
３７ 通信制御部
３８ データ生成部
５０ 申請ボタン
７０ 状態名称表示欄

Claims (7)

1. 実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、前記データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する取得部と、
   取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶するデータ生成部と、
   社員毎に纏められた前記案件データの一括承認要求を行う承認要求部と、
   前記一括承認要求により承認が得られた際に、各前記カテゴリの起票テーブルに記憶されている前記承認未申請のデータを、対応するカテゴリの前記実テーブルに移行して前記実テーブルのデータ構成を変更し、前記一括承認要求により承認が得られなかった場合は、前記案件データの前記申請状態情報及び前記起票テーブルに記憶されている前記承認未申請のデータの申請状態情報を、共に申請却下の申請状態情報に変更する変更制御部と、
   を有する申請制御装置。
2. 前記変更制御部は、前記一括承認要求により承認が得られなかった場合、前記案件テーブルの前記案件データの前記申請状態情報を、前記案件データの破棄を示す申請状態情報に変更すると共に、前記起票テーブルに記憶されている、承認が得られなかったデータを前記起票テーブルから削除すること、
   を特徴とする請求項１に記載の申請制御装置。
3. 前記変更制御部は、前記一括承認要求により承認が得られなかった場合、前記案件テーブルの前記案件データの前記申請状態情報を、前記案件データを破棄することを示す破棄の申請状態情報に変更すると共に、前記起票テーブルに記憶されている、承認が得られなかったデータの申請状態情報を、データの修正及び再度の申請を可能とする未申請に変更すること、
   を特徴とする請求項１又は請求項２に記載の申請制御装置。
4. 更新又は照会が申請されたデータが前記起票テーブルに記憶されている場合は、前記起票テーブルから更新又は照会が申請されたデータを読み出して表示部に表示し、更新又は照会が申請されたデータが前記起票テーブルに記憶されていない場合は、前記実テーブルから更新又は照会が申請されたデータを読み出して表示部に表示する表示制御部を、さらに備えること、
   を特徴とする請求項１から請求項３のうち、いずれか一項に記載の申請制御装置。
5. 前記表示制御部は、前記起票テーブルに記憶されているデータを表示する場合、前記起票テーブルに記憶されているデータに含まれる申請処理区分を示す申請処理区分情報及び前記申請状態情報も含めて前記データの表示を行うこと、
   を特徴とする請求項４に記載の申請制御装置。
6. 取得部が、実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、前記データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する取得ステップと、
   データ生成部が、前記取得ステップで取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶するデータ生成ステップと、
   承認要求部が、社員毎に纏められた前記案件データの一括承認要求を行う承認要求ステップと、
   変更制御部が、前記一括承認要求により承認が得られた際に、各前記カテゴリの起票テーブルに記憶されている前記承認未申請のデータを、対応するカテゴリの前記実テーブルに移行して前記実テーブルのデータ構成を変更し、前記一括承認要求により承認が得られなかった場合は、前記案件データの前記申請状態情報及び前記起票テーブルに記憶されている前記承認未申請のデータの申請状態情報を、共に申請却下の申請状態情報に変更する変更制御ステップと、
   を有する申請制御方法。
7. コンピュータを、
   実テーブルのデータ構成を変更する際に、承認者の承認を必要とするデータを記憶する、前記データの種別に対応するカテゴリ毎に設けられた一つ又は複数の起票テーブルから、承認未申請のデータを取得する取得部と、
   取得された承認未申請のデータを、社員毎に纏めて固有の案件識別情報を付加すると共に、承認の申請状態を示す申請状態情報を付加した案件データを生成して案件テーブルに記憶するデータ生成部と、
   社員毎に纏められた前記案件データの一括承認要求を行う承認要求部と、
   前記一括承認要求により承認が得られた際に、各前記カテゴリの起票テーブルに記憶されている前記承認未申請のデータを、対応するカテゴリの前記実テーブルに移行して前記実テーブルのデータ構成を変更し、前記一括承認要求により承認が得られなかった場合は、前記案件データの前記申請状態情報及び前記起票テーブルに記憶されている前記承認未申請のデータの申請状態情報を、共に申請却下の申請状態情報に変更する変更制御部として機能させること、
   を特徴とする申請制御プログラム。

Images