JP7272534B1 - 支給計算システム - Google Patents

Abstract

【課題】交通費の支給金額に変動が生じた場合に、支給対象者に支給する給与支給金額を計算する給与支給計算処理の一部である交通費の支給金額又は交通費に応じて変動する支給金額を計算する処理を給与支給計算処理の実行タイミングより前に実行する支給計算システムを提供する。【解決手段】各サーバ及び複数の社員端末がインターネット１９９に、接続されるネットワークシステムにおいて、通勤交通費算出サーバ１００は、交通費の支給金額に変動が生じたと判定した場合に、バッチサーバ１５０で実行されるタスクスケジューラに、交通費に応じて変動する支給金額に係る給与連携基礎データの作成処理を実行する給与連携バッチ処理プログラムの実行タスクのタスクスケジュールを登録する。バッチサーバ１５０は、タスクスケジューラに登録されたタスクスケジュールで給与連携バッチ処理プログラムを実行する。【選択図】図１

Description

特許法第３０条第２項適用 令和３年７月１２日：ウェブサイト ｈｔｔｐｓ：／／ｗｗｗ．ｂａｉ．ｃｏ．ｊｐ／ｎｅｗｓ／％ｅ９％８０％９ａ％ｅ５％８ｂ％ａ４％ｅ７％ａｅ％ａ１％ｅ７％９０％８６ａｒｖｏ％ｅ３％８１％ａｅ％ｅ６％８ｆ％９０％ｅ４％ｂｅ％９ｂ％ｅ３％８２％９２％ｅ９％９６％８ｂ％ｅ５％ａ７％８ｂ％ｅ３％８１％９７％ｅ３％８１％ｂ％ｅ３％８１％９７％ｅ３％８１％９ｆ％ｅｆ％ｂｃ％８１／、ｈｔｔｐｓ：／／ｗｗｗ．ｂａｉ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔ／ｔｓｕｋｉｎａｒｖｏ／、ｈｔｔｐｓ：／／ａｒｖｏ－ｔｓｕｋｉｎ．ｃｏｍ／ＸＸＸＸＸ（ＸＸＸＸＸは顧客ごとに異なる）、ｈｔｔｐｓ：／／ｐｒ－ｆｒｅｅ．ｊｐ／２０２１／３４７６７／、ｈｔｔｐ：／／ｗｗｗ．ｄｉｒｅｃｔｐｒｅｓｓ．ｊｐ／ｐｒ０００４０１９１．ｈｔｍｌ；令和３年１１月２８日、２９日：秋田ＩＣＴフェア２０２１に出展

本発明は、支給対象者の給与支給金額の計算を支援する支給計算システムに関する。

従来、通勤交通費の新規発生、経路変更、打ち切り等による変更時に、通勤手当の算出及び給与への連携を行う技術として、例えば、特許文献１記載の技術が知られている。
特許文献１記載の技術は、通勤交通費の新規発生、経路変更、打ち切り等の申請があると給与システムと連携して給与の交通費支給額を算出する技術であって、会社の通勤手当の支給基準や算出方法に関する定義を作成し、通勤交通費の申請データが入力されると通勤手当定義に基づいて申請データを通勤手当データに変換し、給与の交通費支給額を精算する場合は通勤手当データを計算し直す更新処理を行う。

特開２０１６－１９２２０１号公報

しかしながら、特許文献１記載の技術にあっては、通勤交通費等の交通費の支給金額に変動があっても、給与との連携処理は月に１回又は変更時のみ月に複数回行うように構成されており、即時の対応が難しかった。
そこで、本発明は、このような従来の技術の有する未解決の課題に着目してなされたものであって、交通費の支給金額に変動が生じた場合に、支給対象者に支給する給与支給金額を計算する給与支給計算処理の一部である交通費の支給金額又は交通費に応じて変動する支給金額を計算する処理を給与支給計算処理の実行タイミングより前に実行する支給計算システムを提供することを目的としている。

〔発明１〕 上記目的を達成するために、発明１の支給計算システムは、支給対象者への給与支給金額のうち交通費の支給金額又は当該交通費に応じて変動する支給金額を計算する第１計算処理、当該支給対象者への給与支給金額のうち他の支給金額を計算する第２計算処理、並びに前記第１計算処理及び前記第２計算処理の処理結果に基づいて給与支給金額を計算する第３計算処理からなる給与支給計算処理のうち前記第１計算処理の一部又は全部を当該給与支給計算処理の実行タイミングよりも前に実行し又は実行の設定を行い、前記給与支給計算処理は、前記第１～第３計算処理のうち未計算のものを実行する支給計算システムであって、前記交通費の支給金額に変動が生じたことを判定する判定手段と、前記判定手段で変動が生じたと判定した場合に、変動に係る前記第１計算処理を実行し又は実行の設定を行う第１計算処理実行手段とを備える。

このような構成であれば、判定手段により、第１計算処理に係る交通費の支給金額に変動が生じたことが判定されると、第１計算処理実行手段により、変動に係る第１計算処理の一部又は全部が実行されるか又は第１計算処理の一部又は全部の実行の設定が行われる。
ここで、第１計算処理の実行の設定が行われるとは、例えば、第１計算処理が他のシステムで実行される場合に、実行に必要な情報及び実行時期等を他のシステムに対して設定する処理となる。

また、本システムは、単一の装置、端末その他の機器として実現するようにしてもよいし、複数の装置、端末その他の機器を通信可能に接続したネットワークシステムとして実現するようにしてもよい。後者の場合、各構成要素は、それぞれ通信可能に接続されていれば、複数の機器等のうちいずれに属していてもよい。
〔発明２〕 さらに、発明２の支給計算システムは、発明１の支給計算システムにおいて、前記判定手段は、前記支給対象者が通勤で利用する通勤経路の情報を含む通勤経路情報の申請処理によって当該支給対象者の前記交通費の支給金額が発生し若しくは変更された場合、又は支給計算業務の担当者による入力装置を介した入力により前記支給金額が変更された場合に、前記交通費の支給金額に変動が生じたと判定する。

このような構成であれば、判定手段により、支給対象者が通勤で利用する通勤経路の情報を含む通勤経路情報の申請処理によって当該支給対象者の交通費の支給金額が新規に発生し若しくは変更された場合、又は支給計算業務の担当者による入力装置を介した入力により支給金額が変更された場合に、第１計算処理に係る交通費の支給金額に変動が生じたと判定される。
〔発明３〕 さらに、発明３の支給計算システムは、発明１又は２の支給計算システムにおいて、前記判定手段は、前記交通費の支給金額に関する支給情報を記憶する支給情報記憶手段に記憶された前記支給情報に変更が生じた場合に、前記交通費の支給金額に変動が生じたと判定する。

このような構成であれば、判定手段により、交通費の支給金額に関する支給情報を記憶する支給情報記憶手段に記憶された支給情報に変更が生じた場合に、前記交通費の支給金額に変動が生じたと判定される。
〔発明４〕 さらに、発明４の支給計算システムは、発明１又は２の支給計算システムにおいて、前記第１計算処理実行手段は、前記第１計算処理を実行するバッチ処理プログラムの実行スケジュールを設定する実行スケジュール設定部と、当該実行スケジュール設定部で設定した実行スケジュールで前記バッチ処理プログラムを実行するバッチ処理プログラム実行部とを有する。

このような構成であれば、第１計算処理実行手段は、判定手段で変動が生じたと判定されると、実行スケジュール設定部により、第１計算処理を実行するバッチ処理プログラムの実行スケジュールが設定され、バッチ処理プログラム実行部により、実行スケジュール設定部で設定した実行スケジュールでバッチ処理プログラムが実行される。

以上説明したように、発明１の支給計算システムによれば、交通費の支給金額に変動が生じたときに、該当の支給対象者の交通費の支給金額又は当該交通費に応じて変動する支給金額を再計算することができるので、全支給対象者の分を一括で計算するよりも給与支給計算処理に係る負荷を軽減することができる。
さらに、発明２の支給計算システムによれば、通勤経路情報の申請による交通費の支給金額の変動に加えて、支給計算業務の担当者による入力装置を介した入力により交通費に係る支給金額が変更された場合も事前対応が可能であり、給与支給計算処理の負荷をより軽減することができる。

さらに、発明３の支給計算システムによれば、支給情報記憶手段に記憶された支給情報に変更が生じた場合に交通費に係る支給金額に変動が生じたと判定するようにしたので、給与支給計算処理にかかる負荷をより確実に軽減することができる。
さらに、発明４の支給計算システムによれば、バッチ処理プログラムの実行スケジュールを設定して、自動でバッチ処理プログラムを実行して第１計算処理を実行することができるので、給与支給計算処理にかかる負荷をより軽減することができる。

本実施の形態に係るネットワークシステムの構成を示すブロック図である。 通勤交通費算出サーバ１００のハードウェア構成を示す図である。 （ａ）～（ｅ）は、企業マスタテーブル４００、勤務先マスタテーブル４０２、社員情報マスタテーブル４０４、社員別経路情報テーブル４０６及び社員別支給情報テーブル４０８のデータ構造を示す図である。 （ａ）～（ｅ）は、社員別日割支給情報テーブル４１０、部署情報テーブル４１２、システム環境情報テーブル４１４、バッチジョブ定義情報テーブル４１６及びタスクスケジューラ情報テーブル４１８のデータ構造を示す図である。 通勤経路情報新規申請処理を示すフローチャートである。 支給情報追加・修正処理を示すフローチャートである。 社員情報一覧画面５００を示す図である。 経路一覧画面８００を示す図である。 支給情報一覧画面８０１を示す図である。 交通費給与連携基礎データ作成タスク登録処理を示すフローチャートである。 交通費の支給金額に変動が生じる例を説明する図である。 給与連携バッチ処理プログラム実行処理を示すフローチャートである。 バッチサーバ１５０におけるタスクスケジューラによるバッチ処理メインプログラムの実行処理の流れを示す図である。

〔構成〕
以下、本発明の実施の形態を説明する。図１乃至図１３は、本実施の形態を示す図である。
まず、本実施の形態の構成を説明する。
図１は、本実施の形態に係るネットワークシステムの構成を示すブロック図である。
インターネット１９９には、図１に示すように、交通費の算出及び交通費に係る給与支給金額の算出を支援するサービス（以下、「交通費給与連携支援サービス」と称す）を提供する通勤交通費算出サーバ１００と、交通費に係る給与支給金額を算出するための各種基礎データの更新処理を実行するバッチサーバ１５０と、通勤交通費算出サーバ１００及びバッチサーバ１５０で利用される各種テーブル情報を管理するデータベースサーバ１７０と、交通費給与連携支援サービスを利用する企業の社員ごとに設置された社員端末２００とが接続されている。

〔通勤交通費算出サーバ１００のハードウェア構成〕
次に、通勤交通費算出サーバ１００の構成を説明する。
図２は、通勤交通費算出サーバ１００のハードウェア構成を示す図である。
通勤交通費算出サーバ１００は、図２に示すように、制御プログラムに基づいて演算及びシステム全体を制御するＣＰＵ（Central Processing Unit）３０と、所定領域に予めＣＰＵ３０の制御プログラム等を格納しているＲＯＭ（Read Only Memory）３２と、ＲＯＭ３２等から読み出したデータやＣＰＵ３０の演算過程で必要な演算結果を格納するためのＲＡＭ（Random Access Memory）３４と、外部装置に対してデータの入出力を媒介するＩ／Ｆ（InterFace）３８とで構成されており、これらは、データを転送するための信号線であるバス３９で相互に且つデータ授受可能に接続されている。

Ｉ／Ｆ３８には、外部装置として、ヒューマンインターフェースとしてデータの入力が可能なキーボードやマウス等からなる入力装置４０と、データやテーブル等をファイルとして格納する記憶装置４２と、画像信号に基づいて画面を表示する表示装置４４と、インターネット１９９に接続するための信号線とが接続されている。
〔バッチサーバ１５０及びデータベースサーバ１７０のハードウェア構成〕
次に、バッチサーバ１５０及びデータベースサーバ１７０の構成を説明する。

バッチサーバ１５０及びデータベースサーバ１７０は、上記通勤交通費算出サーバ１００と同様のハードウェア構成を有している。
〔社員端末２００のハードウェア構成〕
社員端末２００は、上記通勤交通費算出サーバ１００のような据え置き型を想定した端末、または、スマートフォン、タブレットなどの携帯型の端末から構成されている。前者の場合、そのハードウェア構成は、上記通勤交通費算出サーバ１００と同様となる。一方、後者の場合、そのハードウェア構成は、ＣＰＵと、アプリケーションソフトなどのプログラムやプログラムを実行するためのデータ等を格納しているＲＯＭと、ＲＯＭ等から読み出したデータやＣＰＵの演算過程で必要な演算結果を格納するためのＲＡＭと、付属の各種装置に対してデータの入出力を媒介するＩ／Ｆとで構成されている。これらは、データを転送するための信号線で相互に且つデータ授受可能に接続されている。

Ｉ／Ｆには、付属の各種装置として、データ入力が可能で且つ画像信号に基づいて画面を表示可能なタッチパネル式の表示入力装置、記憶装置、無線通信装置、ビデオカメラ等が接続されている。
〔各種テーブルについて〕
次に、データベースサーバ１７０の記憶装置７０に記憶されている各種テーブルについて説明する。
図３（ａ）～（ｅ）は、企業マスタテーブル４００、勤務先マスタテーブル４０２、社員情報マスタテーブル４０４、社員別経路情報テーブル４０６及び社員別支給情報テーブル４０８のデータ構造を示す図である。

記憶装置７０には、図３（ａ）～（ｅ）に示すように、企業情報を登録する企業マスタテーブル４００と、企業ごとの勤務先の情報を登録する勤務先マスタテーブル４０２と、社員情報を登録する社員情報マスタテーブル４０４と、社員ごとの通勤経路の情報を登録する社員別経路情報テーブル４０６と、社員ごとの通勤交通費の支給情報を登録する社員別支給情報テーブル４０８とが記憶されている。
企業マスタテーブル４００には、図３（ａ）に示すように、企業ＩＤ及び適用開始日の組合せごとに１つのレコードが登録されている。各レコードは、企業ＩＤ、企業名、申請制御区分、社員グループ区分情報、適用開始日、適用終了日、最終更新日、最終更新者、その他の情報からなる主要情報が登録されている。

ここで、企業ＩＤは、企業を識別するための情報であり、例えば、企業ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、申請制御区分は、企業に属する従業員からの申請受付可否を設定する情報であり、社員グループ区分情報は、支給社員グループ、その他の社員グループの職系、事務所、所属等の区分を示す情報である。
勤務先マスタテーブル４０２は、図３（ｂ）に示すように、企業ＩＤ、勤務先ＩＤ及び適用開始日の組合せごとに１つのレコードが登録されている。各レコードは、企業ＩＤ、勤務先ＩＤ、勤務先名、通勤先住所、カレンダＩＤ、始業時刻、終業時刻、燃料単価種別ＩＤ、地図情報、適用開始日、適用終了日、最終更新日、最終更新者、その他の情報からなる主要情報が登録されている。

ここで、勤務先ＩＤは、勤務先を識別するための情報であり、例えば、勤務先ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、カレンダＩＤは、企業ごとに設定された勤務先の営業日と休日とが記されたカレンダを識別するための情報であり、例えば、カレンダの種類ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、燃料単価種別ＩＤは、企業ごとに設定された燃料の単価種別を識別するための情報であり、例えば、単価種別ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。なお、燃料単価種別としては、ガソリン（レギュラー）、ガソリン（ハイオク）、ディーゼル（軽油）などの燃料ごとの単価種別と、ＥＶ（電気自動車）、ＰＨＶ（プラグインハイブリッド電気自動車）、ＦＣＶ（燃料電池自動車）などのエコ自動車の種類ごとの単価種別がある。また、地図情報は、勤務先の最寄り駅の情報である。

社員情報マスタテーブル４０４には、図３（ｃ）に示すように、企業ＩＤ、社員ＩＤ及び適用開始日の組合せごとに１つのレコードが登録されている。各レコードは、企業ＩＤ、社員ＩＤ、社員名、社員名（カナ）、社員郵便番号（自宅）、社員住所（自宅）、電話番号、メールアドレス、勤務先ＩＤ、勤務先名、所属部署ＩＤ、所属部署名、従業員区分、支給ルールＩＤ、パスワード、権限レベル、地図情報、適用開始日、適用終了日、最終更新日、最終更新者、その他の情報を含む主要情報が登録されている。

ここで、所属部署ＩＤは、社員の所属する部署を識別するための情報であり、例えば、所属部署ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。従業員区分は、正社員、パートなどを区分する情報であり、権限レベルは、人事権限、上位者権限及び社員権限のうちのいずれかを示す情報である。人事権限は、本システムの通勤費業務に関する全ての機能を利用することができる権限であり、上位者権限は、通勤経路の申請および申請内容の承認作業のみをすることができる権限であり、社員権限は、通勤経路の申請のみをすることができる権限である。また、地図情報は、社員の自宅の最寄り駅の情報である。

社員別経路情報テーブル４０６には、図３（ｄ）に示すように、企業ＩＤ、社員ＩＤ及び経路ＩＤの組合せごとに１つのレコードが登録されている。各レコードは、企業ＩＤ、社員ＩＤ、乗物ＩＤ、経路方向種別、社員最寄り駅、経路ＩＤ、経路、経路利用期間、１ヵ月金額、３ヵ月金額、６ヵ月金額、１２ヵ月金額、片道金額、片道距離、片道時間、乗換回数、経路基準日、適用開始日、適用終了日、最終更新日、最終更新者、その他の情報を含む主要情報が登録されている。

ここで、経路方向種別は、通勤手段の利用方向を示す情報であり往路、復路又は往復の情報となる。また、経路ＩＤは、通勤経路を識別するための情報であり、例えば、通勤経路ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、経路は、自宅から勤務先までの経路であり、例えば、通勤手段が鉄道であれば、「自宅→徒歩→最寄り駅（自宅）→途中駅→最寄り駅（勤務先）→徒歩→勤務先」となり、例えば、通勤手段が自動車であれば、「自宅→自動車→勤務先」となる。また、１ヵ月金額、３ヵ月金額、６ヵ月金額及び１２ヵ月金額は、設定した通勤手段及び経路方向種別の１、３、６及び１２ヵ月の通勤交通費の金額であり、経路基準日は、通勤経路が有効となる基準日である。

社員別支給情報テーブル４０８は、図３（ｅ）に示すように、企業ＩＤ、社員ＩＤ、経路ＩＤ及び支給ＩＤの組合せごとに１つのレコードが登録されている。各レコードは、企業ＩＤ、社員ＩＤ、経路ＩＤ、支給ＩＤ、開始日、終了日、支給日、支払方法、支給対象期間、支給対象月数、支給／控除額、自己負担額、種別、期間、備考、解約日、支払詳細情報、定期月数、定期枚数、支給金額、支給金額合計、自己負担額合計、その他の情報を含む主要情報が登録されている。

ここで、支給ＩＤは、支給情報を一意に特定するための情報であり、例えば、支給情報ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、支払方法は、例えば、給与に組み込み、銀行口座への振り込み、現物（現金）支給などの通勤交通費の支払方法を示す情報であり、支給対象月数及び定期月数は、１ヵ月、３ヵ月、６ヵ月及び１２ヵ月のいずれかとなる。また、支払詳細情報は、継続支給の対象であるか否か、支給サイクル固定の対象であるか否か、運賃改定処理対象であるか否かを示す情報である。

図４（ａ）～（ｅ）は、社員別日割支給情報テーブル４１０、部署情報テーブル４１２、システム環境情報テーブル４１４、バッチジョブ定義情報テーブル４１６及びタスクスケジューラ情報テーブル４１８のデータ構造を示す図である。
記憶装置７０には、図４（ａ）～（ｅ）に示すように、社員ごとの日割通勤交通費の支給情報を登録する社員別日割支給情報テーブル４１０と、所属部署ごとの承認者及び代理申請者の情報を登録する部署情報テーブル４１２とが記憶されている。加えて、バッチサーバのＩＰアドレス等のシステム環境情報を登録するシステム環境情報テーブル４１４と、バッチ処理プログラムの物理ファイル名の情報等を含むバッチジョブの定義情報を登録するバッチジョブ定義情報テーブル４１６と、タスクスケジューラに登録したタスクを実行するための情報を登録するタスクスケジューラ情報テーブル４１８とが記憶されている。

社員別日割支給情報テーブル４１０は、図４（ａ）に示すように、企業ＩＤ、社員ＩＤ、経路ＩＤ、支給ＩＤ及び日割ＩＤの組合せごとに１つのレコードが登録されている。各レコードは、社員ＩＤ、企業ＩＤ、経路ＩＤ、開始日、終了日、支給日、支払方法、日割支給対象期間、支給対象日数、利用方向種別（片道／往復）、日数、支給金額、支給金額合計、その他の情報を含む主要情報が登録されている。
ここで、日割ＩＤは、日割情報を一意に特定するための情報であり、例えば、日割情報ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、日割支給対象期間は、通勤交通費を日割で計算する対象期間を示す情報であり、支給対象日数は、支給対象期間のうち通勤交通費を日割りで支払う日数の情報であり、利用方向種別（片道／往復）は、支給対象期間に利用した経路方向種別を示す情報である。また、支払詳細情報は、運賃改定処理対象であるか否かを示す情報である。

部署情報テーブル４１２は、図４（ｂ）に示すように、所属部署ごと且つ企業ごとに１つのレコードが登録されている。各レコードは、所属部署ＩＤ、企業ＩＤ、承認者ＩＤ、代理申請者ＩＤ、適用開始日、適用終了日、最終更新日、最終更新者、その他の情報を含む主要情報が登録されている。
ここで、承認者ＩＤは、所属部署ＩＤに対応する所属部署に所属する社員の通勤経路の申請について承認を行う権限を有する上司権限を有する社員の社員ＩＤであり、代理申請者ＩＤは、同じ所属部署に所属する他の社員について通勤経路の申請を代理で行うことができる権限を有する社員の社員ＩＤである。

システム環境情報テーブル４１４は、図４（ｃ）に示すように、バッチサーバＩＰアドレス、バッチサーバユーザＩＤ、バッチサーバユーザＩＤパスワード、パケット名、実費用パケット名、その他の情報を含む主要情報が登録されている。
ここで、バッチサーバユーザＩＤは、バッチサーバ１５０にアクセスするユーザを識別するための情報であり、例えば、ユーザごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、パケット名は、給与連携基礎データの作成で使用するパケット名であり、実費用パケット名は、実費処理で使用するパケット名である。

バッチジョブ定義情報テーブル４１６は、図４（ｄ）に示すように、テナント番号、バッチ処理ＩＤ、バッチ名称、バッチパス、バッチ物理ファイル名、その他の情報を含む主要情報が登録されている。
ここで、テナント番号は、給与連携基礎データの作成処理等のバッチ処理を実行するテナントの番号である。また、バッチ処理ＩＤは、バッチ処理の種類を識別するための情報であり、例えば、バッチ処理の種類ごとに固有の番号（例えば数字のみ、文字や数字の組み合わせ）などから構成される。また、バッチパスは、バッチ処理プログラムを保存している物理パス（バッチサーバ１５０側）であり、バッチ処理物理ファイル名は、バッチ処理プログラムの物理ファイル名である。

タスクスケジューラ情報テーブル４１８は、図４（ｅ）に示すように、テナント番号、バッチ処理ＩＤ及びタスクＩＤの組合せごとに１つのレコードが登録されている。各レコードは、テナント番号、バッチ処理ＩＤ、バッチ処理パス、パラメータ情報、タスクＩＤ、ステータス、実行フラグ、その他の情報を含む主要情報が登録されている。
ここで、バッチ処理パスは、バッチ処理を統括するバッチ処理メインプログラムの物理ファイル名（フルパス）を示す情報であり、パラメータ情報は、バッチ処理で読み込むパラメータ情報である。例えば、給与連携基礎データの作成を行うバッチ処理（以下、「給与連携バッチ処理」と称す）であれば、交通費の支給金額に変動が生じた支給情報を一意に識別するための情報であり、企業ＩＤ、社員ＩＤ、支給ＩＤ（日割支給情報の場合は日割ＩＤも）等を含む情報となる。

なお、図示省略するが、記憶装置４２には、上記テーブル以外にも、交通費を算出するための各種定義データ等が登録されたテーブル、交通費を給与と連携するための各種基礎データが登録されたテーブルなどが記憶されている。基礎データテーブルとしては、具体的に、給与基礎データテーブル、課税基礎データテーブル、社会保険基礎データテーブル及び雇用保険基礎データテーブル等がある。
ここで、給与基礎データは、通勤手当の支給金額のデータであり、課税基礎データは、通勤手当の支給金額に対する課税額のデータであり、社会保険基礎データは、通勤手当の支給金額に対する社会保険の保険金額のデータであり、雇用保険基礎データは、通勤手当の支給金額に対する雇用保険の保険金額のデータである。

〔動作〕
次に、本実施の形態の動作を説明する。
〔通勤経路情報新規申請処理〕
次に、社員が通勤経路情報を新規に申請する場合の通勤交通費算出サーバ１００の動作について説明する。
図５は、通勤経路情報新規申請処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図５のフローチャートに示す通勤経路情報新規申請処理を実行する。
通勤経路情報新規申請処理は、ＣＰＵ３０において実行されると、図５に示すように、まず、ステップＳ１００に移行する。

ステップＳ１００では、社員端末からの新規申請要求を受信したか否かを判定し、受信したと判定した場合（ＹＥＳ）は、ステップＳ１０２に移行し、そうでないと判定した場合（ＮＯ）は、受信するまで判定処理を繰り返す。
ここで、通勤経路情報の新規申請は、例えば、新入社員が初めて通勤経路情報を登録する場合、又は引っ越しをして通勤経路が変わった場合などに行われる。
ステップＳ１０２に移行した場合は、申請情報入力処理を実行して、ステップＳ１０４に移行する。

申請情報入力処理では、入力画面を介して、通勤手段（乗物ＩＤ）、申請理由、自宅住所、経路方向種別等の通勤経路情報を入力することができるようになっている。経路方向種別は、「往路」、「復路」、「往復」の３つのうちから１つを選択することができるようになっている。すなわち、往路しか利用しない場合、復路しか利用しない場合、往路と復路とで通勤経路が異なる場合などに、往路、復路で個別に通勤経路情報を設定できるようになっている。

ステップＳ１０４では、社員端末２００からの登録申請を受信したか否かを判定し、受信したと判定した場合（ＹＥＳ）は、ステップＳ１０６に移行し、そうでないと判定した場合（ＮＯ）は、ステップＳ１１０に移行する。
ステップＳ１０６に移行した場合は、社員情報マスタテーブル４０４から、申請者の所属部署の情報（所属部署ＩＤ）を取得するとともに、部署情報テーブル４１２から、取得した所属部署ＩＤに対応する承認先情報（承認権限を有する社員の社員ＩＤ）を取得して、ステップＳ１０８に移行する。

ここで、所属部署ＩＤは、ワークフロー専用の識別情報であり、異なる複数の実組織間で所属社員が同一の所属部署ＩＤを有するように設定することが可能である。例えば、実組織である総務部に所属する社員Ａ～Ｄと、実組織である営業部に所属する社員Ｆ～Ｉに対して、同一の所属部署ＩＤである「Ｂ１」を設定することができる。なお、実組織については、社員情報マスタテーブル４０４の社員グループＩＤにて登録される。
また、例えば、社員Ａ及びＦは上司権限を有する社員であるとして、ワークフローにおける承認権限が与えられているとする。また、社員Ｅは一般社員であり、代理申請権限が与えられているとする。ここで、承認権限は、ワークフローにおいて同じ所属部署（例えばＢ１）に所属する所属社員の申請内容を承認する権限であり、代理申請権限は、人事部以外の社員が他の所属社員の申請を代理で行う権限である。すなわち、承認権限を有する社員Ａ及びＦは、同じ所属部署Ｂ１の社員Ｂ～Ｅ及びＧ～Ｉの申請に対して承認を行うことが可能となっている。また、代理申請権限を有する社員Ｅは、同じ所属部署Ｂ１の社員Ａ～Ｄ及びＦ～Ｉの申請処理を代理で行うことが可能となっている。

これにより、実組織が異なっていても、部署情報テーブル４２０で定義された同一の所属部署ＩＤで管理されている場合、実組織をまたいだ承認処理及び代理申請処理が可能となっている。すなわち、アメーバ状の承認ルートを構築することができるようになっている。
ステップＳ１０８では、取得した承認先情報に基づいて承認ルートを構築する。その後、構築した承認ルートに基づいてルート先の各承認者宛てに申請情報の承認要求を送信して、一連の処理を終了し、元の処理に復帰する。

例えば、所属部署Ｂ１に所属する一般社員（Ａ及びＦ以外）が通勤経路の申請を行った場合の承認先は、社員Ａ及びＦの双方となり、承認後の点検先は、例えば、所属部署Ｂ１を担当している人事社員Ｊ～Ｌの３人となる。なお、人事社員は、どの部署に対しても点検を行う権限を有している。
すなわち、承認ルートは、まず「社員Ａ及びＦ」となり、社員Ａが先に承認後は「社員Ａ→人事社員Ｊ～Ｌ」となる。一方、社員Ｆが先に承認後は、「社員Ｆ→人事社員Ｊ～Ｌ」となる。すなわち、承認は社員Ａ及びＦのいずれか一方が行えばよく双方共の承認は必要ない。また、承認後の点検は、所属部署Ｂ１を担当している人事社員Ｊ～Ｌの３人となり、点検についても人事社員Ｊ～Ｌのうちのいずれか一人が行えばよい。

このようにして、承認及び点検が行われ申請が許可されることで申請情報が、社員経路情報テーブル４０６、社員別支給情報テーブル４０８及び社員別日割支給情報テーブル４１０に登録される。すなわち、新たな通勤経路が登録されることによって、社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０に記憶された支給情報又は日割支給情報に通勤交通費の支給金額が変わる変動が生じる。
一方、ステップＳ１０４において、登録申請を受信せずにステップＳ１１０に移行した場合は、社員端末２００からのキャンセル要求を受信したか否かを判定し、受信したと判定した場合（ＹＥＳ）は、一連の処理を終了して元の処理に復帰し、そうでないと判定した場合（ＮＯ）は、ステップＳ１０４に移行する。

〔支給情報追加・修正処理〕
次に、人事社員が、社員別支給情報テーブル４０８及び社員別日割支給情報テーブル４１０に登録された支給情報の追加及び修正を行う場合の動作を説明する。
図６は、支給情報追加・修正処理を示すフローチャートであり、図７は、社員情報一覧画面５００を示す図であり、図８は、経路一覧画面８００を示す図であり、図９は、支給情報一覧画面８０１を示す図である。
ここで、通勤費給与連携サービスの提供ページに人事権限を有するアカウントでログインすると、人事権限を有する社員（以下、「人事社員」と称す）の社員端末２００の表示装置には、サービスのトップページが表示される。このトップページには、図示省略するが、「申請」「社員情報」「業務マスタ」などのメインメニューボタンが表示されている。なお、図示省略するが、これらメインメニューボタンは常に画面上部に表示されており、トップページ以外のページからでも選択することが可能となっている。そして、人事権限を有する社員が、社員端末２００を介して「社員情報」のメニューボタンを選択（マウスによる押下又は指によるタッチ等を）することで、表示装置には、図７に示す社員情報一覧画面５００が表示される。ここで、人事社員は、交通費に係る給与支給金額の計算に係る業務を行う権限を有している。

支給情報追加・修正処理は、社員情報一覧画面５００において追加又は修正対象の社員を選択し、経路一覧ボタン５１を選択したあとに表示される経路一覧画面８００において実行される処理である。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図６のフローチャートに示す支給情報追加・修正処理を実行する。
支給情報追加・修正処理は、ＣＰＵ３０において実行されると、図６に示すように、まず、ステップＳ２００に移行する。

ステップＳ２００では、社員端末２００からの情報に基づいて、経路一覧画面８００に表示された選択社員の通勤経路一覧から選択された通勤経路について、経路の修正ボタン８０が選択されたか否かを判定する。そして、選択されたと判定した場合（ＹＥＳ）は、支給情報一覧画面８０１の画面情報を社員端末２００に送信して、ステップＳ２０２に移行し、そうでないと判定した場合（ＮＯ）は、選択されるまで判定処理を繰り返す。
すなわち、図８に示す経路一覧画面８００にて経路の修正ボタン８０が選択された場合は、社員端末２００の表示装置に、図９に示す支給情報一覧画面８０１が表示される。

図６に戻って、ステップＳ２０２に移行した場合は、社員端末２００からの情報に基づいて、支給情報一覧画面８０１にて、追加ボタン８２が選択されたか否かを判定する。そして、選択されたと判定した場合（ＹＥＳ）は、支給情報設定画面の画面情報を社員端末２００に送信して、ステップＳ２０４に移行し、そうでないと判定した場合（ＮＯ）は、ステップＳ２０６に移行する。
すなわち、図９に示す支給情報一覧画面８０１にて、日割支給情報が選択された状態で修正ボタン８３が選択された場合は、社員端末２００の表示画面に、日割支給情報設定画面（図示略）が表示される。なお、図示省略するが、定期の支給情報が選択された状態で修正ボタン８３が選択された場合は、日割支給情報設定画面とは異なる定期の支給情報について追加設定できる画面が表示され、何も選択していない状態で追加ボタン８２が選択された場合は、定期と日割の両方の支給情報を追加設定できる画面が表示される。

図６に戻って、ステップＳ２０４に移行した場合は、支給情報追加処理を実行して、一連の処理を終了して元の処理に復帰する。
ここでは、支給情報追加処理として、日割支給情報設定画面において、人事社員が入力した情報に基づいて、支給情報を追加する場合の処理について説明する。
人事社員は、社員端末２００を介して、日割支給情報設定画面にて必要な情報を入力する。具体的に、日割支給対象期間、支給対象日数、利用方向種別（片道／往復）を入力する。日割支給情報は、例えば、入社日が中途半端な日で、月の途中から出勤するような場合に、その月の出勤日だけ通勤交通費を日割で支給するような場合に設定される情報である。または、例えば感染症の蔓延などによって在宅勤務を行う必要があり、週に２日だけ出勤するといった場合に出勤日だけ通勤交通費を日割で支給するような場合に設定される情報である。従って、日割対象の期間を日割支給対象期間として設定する。

ここで、利用方向種別は、往路と復路で同じ通勤経路を利用したのであれば往復を選択し、往路と復路とで異なる通勤経路を利用した又は片道のみ利用したのであれば片道を選択する。これにより、支給対象期間の各日付に対して共通して往復又は片道が設定される。また、同じ通勤経路で片道だけ利用した日と、往復で利用した日とが混在する場合は片道又は往復のいずれかを選択後に日付ごとに個別に利用方向種別を設定することができる。

また、日割支給情報の入力後に、日割支給情報設定画面に表示されたＯＫボタン（図示略）が選択されることで日割支給情報の入力が完了したと判定して、図９に示す支給情報一覧画面８０１に戻る。そして、支給情報一覧画面８０１には、新たに入力された日割支給情報が一覧に追加され、右下の確定ボタンが選択されることで、新たな日割支給情報が、社員別日割支給情報テーブル４１０に追加される。すなわち、日割支給情報の新規追加によって交通費の支給金額に変動が生じる。

一方、ステップＳ２０２で、追加ボタン８１が選択されずにステップＳ２０６に移行した場合は、社員端末２００からの情報に基づいて、支給情報一覧画面８０１にて、選択支給情報について修正ボタン８３が選択されたか否かを判定する。そして、選択されたと判定した場合（ＹＥＳ）は、支給情報設定画面の画面情報を社員端末２００に送信して、ステップＳ２０８に移行し、そうでないと判定した場合（ＮＯ）は、ステップＳ２１０に移行する。

すなわち、図９に示す支給情報一覧画面８０１にて、既に登録されている日割支給情報が選択された状態で修正ボタン８３が選択された場合は、社員端末２００の表示画面に、日割支給情報設定画面が既に情報が入力された状態で表示される。
ステップＳ２０８に移行した場合は、支給情報修正処理を実行して、一連の処理を終了し元の処理に復帰する。
ここで、支給情報修正処理は、日割支給情報設定画面にて既に入力された情報を修正する処理であり、支給情報追加処理と比較して、新たに情報を入力するか既に入力された情報を変更（修正）するかの違いのみで同様の処理となるので説明を省略する。また、日割支給情報が修正されることによって社員別日割支給情報テーブル４１０に記憶された日割支給情報に通勤交通費の支給金額が変わる変動が生じる。

また、ステップＳ２０６において、修正ボタン８３が選択されずにステップＳ２１０に移行した場合は、追加ボタン８２及び修正ボタン８３を除く他のボタンが選択されたか否かを判定する。そして、他のボタンが選択されたと判定した場合（ＹＥＳ）は、他のボタンに対応する画面の画面情報を社員端末２００に送信して、ステップＳ２１２に移行し、そうでないと判定した場合（ＮＯ）は、ステップＳ２０２に移行する。
ステップＳ２１２に移行した場合は、選択された他のボタンに対応する処理を実行して、一連の処理を終了し元の処理に復帰する。

他のボタンとしては、図９に示すように、解約ボタン、削除ボタン、確定ボタン及びキャンセルボタンがある。解約ボタンが選択された場合は定期の解約処理が実行され、削除ボタンが選択された場合は選択支給情報の削除処理が実行され、キャンセルボタンが選択された場合は、経路の修正がキャンセルされて経路一覧画面８００に戻る処理が実行される。
〔給与連携基礎データ作成タスク登録処理〕
次に、交通費の支給金額に変動が生じたことを契機に、バッチサーバ１５０に対して給与連携基礎データ作成タスクの登録を行う場合の通勤交通費算出サーバ１００の動作について説明する。

図１０は、給与連携基礎データ作成タスク登録処理を示すフローチャートである。
ＣＰＵ３０は、ＲＯＭ３２の所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１０のフローチャートに示す給与連携基礎データ作成タスク登録処理を実行する。
給与連携基礎データ作成タスク登録処理は、ＣＰＵ３０において実行されると、図１０に示すように、まず、ステップＳ３００に移行する。
ステップＳ３００では、社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０の支給情報が変動したか否かを判定する。そして、変動したと判定した場合（ＹＥＳ）は、ステップＳ３０２に移行し、そうでないと判定した場合（ＮＯ）は、変動が生じるまで判定処理を繰り返す。

図１１は、交通費の支給金額に変動が生じる例を説明する図である。
図１１に示すように、社員による通勤経路の新規申請があってこの申請について上司の承認及び人事部の承認（許可）が得られた場合に、新規に申請された通勤経路に応じた支給情報が生成されて、それが社員別支給情報テーブル４０８に登録される。同様に、人事社員によって代理で通勤経路の新規申請があった場合も、申請された通勤経路に応じた支給情報が生成されて、それが社員別支給情報テーブル４０８に登録される。このような場合に、支給情報に支給金額が変わる変動があったか否かを判定する。

また、人事社員の月次処理によって、例えば、通勤交通費を日割りで支給する計算が行われた場合に社員別日割支給情報テーブル４１０の登録内容に支給金額が変わる変動が生じるため、この変動を支給金額の変動と判定する。
また、運賃改定によって、既に支給されている支給額との間に差額が生じる場合にもその差額の支給によって社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０の支給情報に支給金額が変わる変動が生じるため、この変動を支給金額の変動と判定する。また、日割支給額の登録、運賃改定による差額の補填処理が完了後に、給与データの給与連携システムへの出力処理が行われ、その後、先取りで次回の給与連携基礎データを作成する処理が行われる。このとき日割支給や運賃改定等によって先取りで作成した給与連携基礎データに変動が生じる場合は、この場合も社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０の支給情報に支給金額が変わる変動が生じるため、支給金額の変動が生じていると判定する。

ステップＳ３０２に移行した場合は、支給金額が変動した支給情報に係るパラメータをチェックして、ステップＳ３０４に移行する。
ここで、チェックするパラメータとしては、給与連携バッチ処理を実行するテナントの番号、企業ＩＤ、給与連携バッチ処理プログラムのＩＤ（以下、「給与連携バッチ処理ＩＤ」と称す）、ステップＳ３００で支給金額が変わる変動があったと判定した支給情報を識別する情報を含む。
ステップＳ３０４では、記憶装置４２に記憶されたバッチジョブ定義情報テーブル４１６から、バッチ処理メインプログラムの物理ファイル名（フルパス）を取得して、ステップＳ３０６に移行する。

ここで、バッチ処理メインプログラムは、給与連携バッチ処理等の各種バッチ処理を統括制御するプログラムであり、バッチ処理メインプログラムの実行時に設定するパラメータの内容によって実行されるバッチ処理が制御される。
ステップＳ３０６では、記憶装置４２に記憶されたシステムの環境情報テーブル４１４から、バッチサーバ１５０のＩＰアドレス、ログインユーザＩＤ及びパスワードを取得して、ステップＳ３０８に移行する。

ステップＳ３０８では、ステップＳ３０６で取得した情報に基づいて、バッチサーバ１５０にログインして、セッションを確立する。その後、ステップＳ３１０に移行する。
ステップＳ３１０では、タスクスケジューラによるタスクの実行条件を作成して、ステップＳ３１２に移行する。
ここで、タスクの実行条件は、支給金額に変動が生じたことを判定したことを契機に、可能な限り早いタイミングで給与連携バッチ処理を実行するために、例えば、バッチサーバ１５０との間のラグを考慮して、バッチサーバ１５０のシステム日付の２分後にタスクを実行するといった実行条件を作成する。

また、通勤交通費算出サーバ１００及びバッチサーバ１５０は、これらのオペレーティングシステム（ＯＳ）にタスクスケジューラが搭載されている。
タスクスケジューラは、コンピュータプログラムの実行制御システムの一つで、利用者が指定したスケジュールや条件に基づいてプログラムの起動や終了を行い、実行状態や実行結果を記録して報告するものである。これにより、ＯＳ上での特定のコマンドや実行ファイルの起動や終了などをスケジュールに基づいて自動実行することができる。

ステップＳ３１２では、タスクのアクションを作成して、ステップＳ３１４に移行する。
ここで、タスクのアクションは、実行プログラムと、引数（パラメータ）とによって構成される。
具体的に、実行プログラムは、バッチ処理メインプログラムとなり、パラメータは、テナント番号、給与連携バッチ処理ＩＤ及びタスク名となる。ここで、タスク名は、タスクスケジューラに登録するタスク名となる。
ステップＳ３１４では、タスク完了後のアクションに対する削除設定を作成して、ステップＳ３１６に移行する。ここで、支給金額に変動が生じた場合の給与連携基礎データの作成処理は、変動が生じたときにすぐに行われる処理であり、定期的に繰り返し行われる処理では無いためタスク完了後にアクションを削除する設定を作成する。具体的に、タスクが再度実行するようにスケジュールされていない場合に削除されるまでの時間を設定する。

ステップＳ３１６では、タスクスケジューラのインスタンスを作成して、ステップＳ３１８に移行する。
すなわち、タスクスケジューラで実行するバッチ処理メインプログラム（給与連携バッチ処理）のインスタンスを作成する。すなわち、バッチ処理メインプログラム、パラメータなどを、バッチサーバ１５０のメインメモリ上に展開して処理・実行できる状態にする。
ここで、給与連携バッチ処理は、交通費の支給金額が変動したと判定後に、他の給与計算システムに交通費に係る支給金額及び他の支給金額に係るデータを出力する前に実行する必要がある。そのため、給与連携バッチ処理は、支給金額に変動が生じたと判定後に速やかに実行されることが望ましい。

また、タスクスケジューラでは、インスタンス単位で処理が実行され、複数のインスタンスを並列して実行することができるようになっている。
ステップＳ３１８では、ステップＳ３１０～Ｓ３１６で作成した各種情報をタスクスケジューラに登録して、ステップＳ３２０に移行する。
すなわち、テナント番号、企業ＩＤ、給与連携バッチ処理ＩＤ、タスクスケジュール(年月日時分)、実行ユーザ等の情報が登録される。
ステップＳ３２０では、バッチサーバ１５０とのセッションを破棄して、ステップＳ３２２に移行する。

ステップＳ３２２では、タスクスケジューラ情報テーブル４１８に、タスクスケジューラに登録したタスクの実行に必要な情報であるタスクスケジューラ情報を登録して、一連の処理を終了し元の処理に復帰する。具体的に、テナント番号、バッチ処理ＩＤ（給与連携バッチ処理ＩＤ）、バッチ処理パス、パラメータ情報（支給情報を識別する情報）、タスクＩＤ（タスク名）、ステータス、実行フラグ、その他の情報をタスクスケジューラ情報テーブル４１８に登録する。

なお、上記ステップＳ３０８～Ｓ３２０の処理は、例えば、ＯＳに搭載されたコマンドラインインターフェース（例えば、ＯＳがWindowsの場合に「Windows PowerShell（登録商標）」）を用いて自動で行われる処理となる。
〔給与連携バッチ処理プログラム実行処理〕
給与連携バッチ処理プログラム実行処理は、バッチサーバ１５０において、タスクスケジューラによって実行される処理となる。
図１２は、給与連携バッチ処理プログラム実行処理を示すフローチャートである。また、図１３は、バッチサーバ１５０におけるタスクスケジューラによるバッチ処理メインプログラムの実行処理の流れを示す図である。

バッチサーバ１５０のＣＰＵは、ＲＯＭの所定領域に格納されている所定のプログラムを起動させ、そのプログラムに従って、図１２のフローチャートに示す給与連携バッチ処理プログラム実行処理を実行する。
給与連携バッチ処理プログラム実行処理は、ＣＰＵにおいて実行されると、図１２に示すように、まず、ステップＳ４００に移行する。
ステップＳ４００では、登録されたタスクの実行時刻になったか否かを判定し、実行時刻になったと判定した場合（ＹＥＳ）は、ステップＳ４０２に移行し、そうでないと判定した場合（ＮＯ）は、実行時刻になるまで判定処理を繰り返す。

ここでは、図１３に示すように、登録してからシステム日付の２分後にバッチ処理メインプログラムが実行するようにタスクスケジュールがタスクスケジューラに登録されているため、登録から２分後に実行時刻となる。
ステップＳ４０２に移行した場合は、タスクスケジューラに登録されたパラメータをチェックして、ステップＳ４０４に移行する。ここで、パラメータは、テナント番号、給与連携バッチ処理ＩＤ及びタスク名（タスクＩＤ）となる。

ステップＳ４０４では、タスクスケジューラ情報テーブル４１８から、ステップＳ４０２でチェックしたパラメータに対応するタスクの実行に必要なパラメータ情報を取得して、ステップＳ４０６に移行する。
具体的に、図１３に示すように、パラメータ情報として、実行するタスクのテナント番号、バッチ処理ＩＤ（給与連携バッチ処理ＩＤ）及びタスクＩＤに対応するパラメータ情報（支給情報の識別情報）を取得する。
ステップＳ４０６では、タスクスケジューラに登録された各種情報及びステップＳ４０４で取得したパラメータ情報に基づいてバッチ処理メインプログラムが実行され、給与連携バッチ処理プログラムが実行される。その後、ステップＳ４０８に移行する。

すなわち、バッチ処理メインプログラムは、給与連携バッチ処理ＩＤに対応する給与連携バッチ処理プログラム（モジュール）を、例えばバッチサーバ１５０の記憶装置に記憶されたバッチ処理業務モジュールライブラリ（図示略）から読み出す。そして、読み出した給与連携バッチ処理プログラムを実行する。
給与連携バッチ処理プログラムが実行されると、図１３に示すように、ステップＳ４０４で取得したパラメータ情報に対応する支給情報の変動内容を元に、給与基礎データ、課税基礎データ、社会保険基礎データ及び雇用保険基礎データの各計算値を再計算して、各種基礎データテーブルに登録されている各種基礎データの計算値を再計算後のデータに更新する。

ここで、交通費に係る給与支給金額を計算する給与支給計算処理には、社員に支給する支給金額のうち交通費の支給金額及び交通費に応じて変動する支給金額を計算する第１計算処理がある。加えて、給与支給計算処理には、他の支給金額（例えば残業代等）を計算する第２計算処理がある。さらに、第１計算処理及び第２計算処理の処理結果に基づいて給与支給金額を計算する第３計算処理がある。なお、第２計算処理及び第３計算処理は、例えば、他の給与計算システムにて行われる処理となる。給与連携バッチ処理では、給与支給計算処理の一部である第１計算処理が実行される。

また、給与支給計算処理では、交通費に係る給与支給金額を計算する場合に、所定期間ごとに（交通費の支給月ごと（例えば、１ヵ月ごと、３ヵ月ごと等））に交通費に係る給与支給金額の計算処理が行われる。そのため、給与連携バッチ処理プログラムの実行は、前回の交通費支給月の給与支給計算処理の実行後から、今回の給与支給計算処理の実行タイミングの前までの期間内に行われる。また、交通費支給月の給与支給計算処理では、第１計算処理、第２計算処理及び第３計算処理のうち未計算の計算処理が行われる。

ステップＳ４０８では、タスク完了後のタスクスケジューラ情報をタスクスケジューラ情報テーブル４１８から削除して、一連の処理を終了し元の処理に復帰する。
〔実施の形態の効果〕
次に、本実施の形態の効果を説明する。
本実施の形態では、交通費の支給金額に変動が生じる支給情報の変更があったと判定されたときに、給与支給計算処理のうち、交通費が影響を与える給与支給金額の計算に係る給与連携基礎データ（給与基礎データ、課税基礎データ、社会保険基礎データ及び雇用保険基礎データ）の計算値について計算又は再計算する処理を実行するようにした。

具体的に、通勤交通費算出サーバ１００から、バッチサーバ１５０にて実行されるタスクスケジューラに、給与連携基礎データを作成（計算又は再計算）する給与連携バッチ処理プログラムを実行するタスクスケジュールを登録する。このとき、通信ラグ等を考慮してタスクスケジュールの登録からバッチサーバ１５０のシステム時刻の２分後にタスクを実行するようにスケジュールを組み、登録から比較的短い時間で給与連携バッチ処理プログラムを実行するようにした。

このような構成であれば、交通費の支給金額が変動した場合の第１計算処理を、事前に且つバッチ処理プログラムによって自動で行うことができるので、給与支給計算処理にかかる負荷を軽減することができる。特に、交通費に係る支給金額が変動した場合に、変動に係る支給対象者の交通費の支給金額又は交通費に応じて変動する支給金額を再計算することができるので、全支給対象者の分を一括で計算するよりも給与支給計算処理に係る負荷を軽減することができる。
さらに、本実施の形態では、社員又は代理申請者（人事社員含む）が通勤経路情報の申請又は代理申請を行って、この申請が上司社員及び人事社員に承認され、対象社員の支給情報が初めて社員別支給情報テーブル４０８に登録された場合に、交通費の支給金額に変動が生じたと判定するようにした。加えて、通勤経路情報の申請が承認されて社員別支給情報テーブル４０８に登録された支給情報が変更された場合に、交通費の支給金額に変動が生じたと判定するようにした。

さらに、人事社員の月次処理によって、日割支給情報が社員別日割支給情報テーブル４１０に新規に登録された場合に、交通費の支給金額に変動が生じたと判定するようにした。なおさらに、人事社員の月次処理によって、社員別日割支給情報テーブル４１０に登録された既存の日割支給情報に変更があった場合に、交通費の支給金額に変動が生じたと判定するようにした。
さらにまた、人事社員の月次処理によって、鉄道会社やバス会社等の運賃改定により、改定後の料金に対応する支給金額と既に支給した支給金額との間に差額が生じた場合に、差額を支給するために社員別日割支給情報テーブル４１０に新規に日割支給情報が登録されるか又は既に登録された既存の日割支給情報が変更される。この場合も、交通費の支給金額に変動が生じたと判定するようにした。

また、人事社員の月次処理によって、交通費の支給金額に変動が生じた給与連携基礎データの確定後（給与連携システムへと出力後）に、先取りして作成された次回の給与連携基礎データにも変更が生じるため、この場合も支給金額に変動が生じたと判定するようにした。
このような構成であれば、通勤経路情報の申請以外でも、日割支給、運賃改定等の他の理由で交通費の支給金額に変動が生じた場合も事前対応が可能であり、給与支給計算処理の負荷をより軽減することができる。また、社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０への支給情報又は日割支給情報の登録をもって交通費の支給金額に変動が生じたと判定するようにしたので、支給金額の変動の有無をより確実に判定することができる。

〔対応関係〕
本実施の形態において、ステップＳ３００は、発明１乃至４の判定手段に対応し、ステップＳ３０２～Ｓ３１０、Ｓ４００～Ｓ４０８は、発明１及び４の第１計算処理実行手段に対応し、記憶装置４２は、発明３の支給情報記憶手段に対応している。
〔変形例〕
なお、上記実施の形態においては、社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０に支給情報又は日割支給情報が新規に登録されたときに、交通費の支給金額に変動が生じたと判定する構成とした。加えて、社員別支給情報テーブル４０８又は社員別日割支給情報テーブル４１０に登録された支給情報又は日割支給情報が変更された場合に交通費の支給金額に変動が生じたと判定する構成とした。この構成に限らず、例えば、通勤経路情報が申請され、その申請が承認された場合に、支給金額に変動が生じたと判定する構成とするなど他の構成としてもよい。

また、上記実施の形態及びその変形例においては、ネットワークシステムとして実現したが、これに限らず、単一の装置又はアプリケーションとして実現することもできる。
また、上記実施の形態及びその変形例においては、給与連携基礎データの計算処理をバッチサーバ１５０でタスクスケジューラにより実行する構成としたが、この構成に限らない。例えば、タスクスケジューラを用いずに行う構成、通勤交通費算出サーバ１００で実行する構成とするなど他の構成としてもよい。

また、上記実施の形態及びその変形例においては、インターネット１９９からなるネットワークシステムに適用した場合について説明したが、これに限らず、例えば、インターネット１９９と同一方式により通信を行ういわゆるイントラネットに適用してもよい。もちろん、インターネット１９９と同一方式により通信を行うネットワークに限らず、任意の通信方式のネットワークに適用することができる。
また、上記実施の形態及びその変形例において、図５、図６、図１０及び図１２のフローチャートに示す処理を実行するにあたってはいずれも、ＲＯＭに予め格納されているプログラムを実行する場合について説明したが、これに限らず、これらの手順を示したプログラムが記憶された記憶媒体から、そのプログラムをＲＡＭに読み込んで実行するようにしてもよい。

１００…通勤交通費算出サーバ、 １５０…バッチサーバ、 １７０…データベースサーバ、 ２００…社員端末、 ３０…ＣＰＵ、 ３２…ＲＯＭ、 ３４…ＲＡＭ、 ３８…Ｉ／Ｆ、 ３９…バス、 ４０…入力装置、 ４２…記憶装置、 ４４…表示装置、 １９９…インターネット、 ４００…企業マスタテーブル、 ４０２…勤務先マスタテーブル、 ４０４…社員情報マスタテーブル、 ４０６…社員別経路情報テーブル、 ４０８…社員別支給情報テーブル、 ４１０…社員別日割支給情報テーブル、 ４１２…部署情報テーブル、 ４１４…システム環境情報テーブル、 ４１６…バッチジョブ定義情報テーブル、 ４１８…タスクスケジューラ情報テーブル

Claims (3)

1. 支給対象者への給与支給金額のうち交通費の支給金額又は当該交通費に応じて変動する支給金額を計算する第１計算処理、当該支給対象者への給与支給金額のうち他の支給金額を計算する第２計算処理、並びに前記第１計算処理及び前記第２計算処理の処理結果に基づいて給与支給金額を計算する第３計算処理からなる給与支給計算処理のうち前記第１計算処理の一部又は全部を当該給与支給計算処理の実行タイミングよりも前に実行するための実行の設定を行い、前記給与支給計算処理は、前記第１～第３計算処理のうち未計算のものを実行する支給計算システムであって、
   前記交通費の支給金額に変動が生じたことを判定する判定手段と、
   前記判定手段で変動が生じたと判定するごとに、変動が生じたと判定された前記交通費の支給金額に係る前記第１計算処理の実行の設定を行う第１計算処理実行手段と、を備え、
   バッチサーバと通信可能に接続され、
   前記第１計算処理実行手段は、前記第１計算処理を実行するバッチ処理プログラムを前記バッチサーバに実行させるための実行スケジュールを設定する実行スケジュール設定部と、当該実行スケジュール設定部で設定した前記実行スケジュールの設定情報を前記バッチサーバに送信する設定情報送信部と、を備え、
   前記バッチサーバは、前記設定情報送信部が送信した前記設定情報を受信したことに応じて、変動に係る前記支給情報を識別するための識別情報を含む前記バッチ処理プログラムの実行に必要なタスク実行情報を記憶するタスク実行情報記憶手段の当該設定情報に対応する前記タスク実行情報に基づいて、当該設定情報に対応する実行スケジュールで前記バッチ処理プログラムを実行するバッチ処理プログラム実行部を備え、
   前記実行スケジュール設定部は、前記実行スケジュールとして、前記バッチサーバでの前記バッチ処理プログラムの実行時刻を設定可能に構成されており、当該実行時刻として前記設定情報の送信後から前記バッチサーバとの通信ラグを考慮した所定時間後の時刻を設定することを特徴とする支給計算システム。
2. 請求項１において、
   前記判定手段は、前記交通費の支給金額に関する支給情報を記憶する支給情報記憶手段に記憶された前記支給情報に変更が生じた場合に、前記交通費の支給金額に変動が生じたと判定することを特徴とする支給計算システム。
3. 請求項２において、
   前記判定手段は、支給計算業務の担当者による入力装置を介した入力により前記支給情報記憶手段に新たな前記支給情報が記憶された場合若しくは前記支給情報記憶手段に記憶された前記支給情報が変更された場合に、前記交通費の支給金額に変動が生じたと判定することを特徴とする支給計算システム。

Images