JP6349450B1 - 給与受取システム、給与受取方法、及びプログラム - Google Patents

Abstract

【課題】従業者が給与に基づく所定の支払金額を、必要なときに手軽に受け取ることができ、しかも雇用者側の金銭的、作業的な負担を低減して、より使い勝手のよい給与受取システムを提供する。【解決手段】給与受取システム１は、給与受取装置１０と、企業端末２０と、従業員端末３０とを備えて構成される。給与受取装置１０は、従業者から申請金額を含む給与受取の申請を受け付けるリクエスト処理部１０２と、従業者の労働時間の累計データ及び給与単価に基づいて従業者の給与受取の申請可能金額を算出する申請可能金額算出部１０３と、雇用者ごとに設定された月間の想定立替金額、申請可能金額及び申請金額に基づいて、支払金額を算出する支払金額算出部１０４と、支払金額を従業者の口座に振り込むための振込みデータを作成する振込データテーブル作成部１０６と、を備えて構成される。【選択図】図３

Description

本発明は、給与受取システム、給与受取方法、及びプログラムに関する。

既に提供した労働についての労働の対価を、任意の時点で従業者が受け取ることを可能にする給与前払システムが知られている（例えば、特許文献１参照）。この特許文献１に記載の給与前払いシステムでは、従業者の日給データを日ごとに作成し、所定の開始日から前払いの申請日までの期間における累計データを算出しておき、累計データから既に前払いされた金額データの累計データを減算することで、利用可能金額を算出し、雇用者の口座から申請金額を引き落として従業者の口座に振り込んでいる。

特許第４３９５４１３号公報

しかしながら、従来技術では、雇用者が前払いのためにまとまった金額を用意する必要があり、負担が大きかった。また、日給データを算出しておくなどの手間もあった。

本発明は、上記の事情に鑑みて為されたもので、従業者が給与に基づく所定の支払金額を、必要なときに手軽に受け取ることができ、しかも雇用者側の金銭的、作業的な負担を低減して、より使い勝手のよい給与受取システム、給与受取方法、及びプログラムを提供することを可能とするものである。

上記の目的を達成するため、本願に係る給与受取システムは、従業者から申請金額を含む給与受取の申請を受け付ける申請処理部と、前記従業者の労働時間の累計データ、給与単価及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出部と、雇用者ごとに設定された限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出部と、前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成部と、を備え、前記従業者の給与の少なくとも一部を、前記雇用者に代わって立て替えて支払うことを特徴とする。

また、本願に係る給与受取処理は、従業者から申請金額を含む給与受取の申請を受け付ける申請処理工程と、従業者の労働時間の累計データ、給与単価及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出工程と、雇用者ごとに設定された限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出工程と、前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成工程と、を有し、前記従業者の給与の少なくとも一部を、前記雇用者に代わって立て替えて支払うことを特徴とする。

また、本願に係るプログラムは、コンピュータを、従業者から申請金額を含む給与受取の申請を受け付ける申請処理手段、従業者の労働時間の累計データ、給与単価及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出手段、雇用者ごとに設定された限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出手段、前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成手段として機能させるためのプログラムである。

本発明によれば、従業者が給与に基づく所定の支払金額を、必要なときに手軽に受け取ることができ、しかも雇用者側の金銭的、作業的な負担を低減して、より使い勝手のよい給与受取システム、給与受取方法、及びプログラムを提供することができる。

本発明の一実施形態に係る給与受取システムの構成例を示す概略図である。 図１に示す給与受取システムのハードウェア構成例を示す図であり、（ａ）は給与受取装置のハードウェア構成例を示し、（ｂ）は企業端末と従業員端末がＰＣである場合のハードウェア構成例を示し、（ｃ）は業務端末と従業員端末がスマートフォンである場合のハードウェア構成例を示す。 図１に示す給与受取システムの機能構成例を示すブロック図である。 企業コードテーブルのデータ構造の一例を示す図である。 給与パターンテーブルのデータ構造の一例を示す図である。 従業員テーブルのデータ構造の一例を示す図である。 累計データテーブルのデータ構造の一例を示す図である。 リクエストテーブルのデータ構造の一例を示す図である。 振込テーブルのデータ構造の一例を示す図である。 天引きデータテーブルのデータ構造の一例を示す図である。 本実施形態に係る給与受取システムにおいて、給与パターンデータ更新処理の流れの一例を示すシーケンス図である。 本実施形態に係る給与受取システムにおいて、給与受取の申請処理の流れの一例を示すシーケンス図である。 本実施形態に係る給与受取システムにおいて、利用履歴の確認処理及び給与受取申請の取消処理の流れの一例を示すシーケンス図である。 本実施形態に係る給与受取システムにおいて、振込み処理の流れの一例を示すシーケンス図である。 本実施形態に係る給与受取システムにおいて、天引きデータテーブル作成処理の流れの一例を示すシーケンス図である。 企業端末の表示部に表示される画面例であり、（ａ）はログイン画面を、（ｂ）は給与パターン変更初期画面を、（ｃ）は給与パターン詳細画面を示す。 従業員端末の表示部に表示される画面例であり、（ａ）はログイン画面を、（ｂ）はパスワード変更画面を示す。 従業員端末の表示部に表示される画面例であり、（ａ）は申請トップ画面を、（ｂ）は振込先口座一覧画面を、（ｃ）は申請金額入力画面を、（ｄ）は振込金額確認画面を、（ｅ）は振込口座指定画面を、（ｆ）は申請内容確認画面を、（ｇ）は受付完了画面を示す。 従業員端末の表示部に表示される画面例であり、（ａ）は申請トップ画面を、（ｂ）は利用履歴画面を、（ｃ）は申請取消確認画面を、（ｄ）は取消受付完了画面を示す。 前払い申請ＯＫ期間とＮＧ期間とを説明するための説明図である。

以下に、本願に係る給与受取システムの一実施形態について、図面を参照しながら説明する。図１は、本実施形態に掛かる給与受取システム１の構成例を示す図である。なお、本明細書でいう「給与受取」とは、従業者が給与に基づく所定の支払金額を、給与支払日前の任意の時点で受け取ることを意味する。支払金額には、従業者が既に提供した労働の対価、給与に基づく前払金や仮払金も含まれる。図１に示すように、本実施形態に係る給与受取システム１は、給与受取システム１による給与受取サービスを提供する提供者（以下、「ホスト」という）に備えられる給与受取装置１０と、給与受取サービスに加入した雇用者である複数の企業に備えられる情報端末としての企業端末２０，２０，・・・と、各企業の労働者（従業者）である従業員が保有する情報端末としての従業員端末３０，３０,・・・とを備えて構成される。

上記給与受取装置１０、企業端末２０、従業員端末３０は、通信ネットワーク２を介して互いに接続されている。さらに、給与受取装置１０は、通信ネットワーク３を介して、銀行などの給与の振込先の金融機関の振込システム５０，５０，・・・に接続されている。

通信ネットワーク２には、例えばインターネットを使用することができ、通信ネットワーク２に接続されるＰＣや携帯端末相互間で送受信されるデータを伝送する。一方、通信ネットワーク３は、セキュリティの関係上、金融機関の振込システム５０との専用通信回線や閉じたネットワークを使用することが望ましい。また、企業端末２０と給与受取装置１０との接続は、インターネットでもよいが、専用通信回線や閉じたネットワークであってもよく、セキュリティを高めることができる。

以下では、ホストがクレジット会社であると想定して給与受取システム１の詳細を説明するが、ホストがクレジット会社に限定されるものではなく、クレジット会社以外の信販会社であってもよい。また、ホストが信販会社に限定されることもなく、例えば、各種銀行、保険会社、証券会社、ノンバンクなどの金融機関であってもよい。

給与受取装置１０として、本実施形態では、サーバ用パーソナルコンピュータ（ＰＣ）を用いているが、ＰＣに限定されることはなく、汎用大型コンピュータ（メインフレーム）等を用いることもできる。サーバ用ＰＣは、クラウドコンピューティングサービスを利用したものであってもよいし、自社のサーバ用ＰＣであってもよい。また、本実施形態では、給与受取装置１０を１台のサーバ用ＰＣで構成しているが、提供する給与受取サービスの規模や使用目的等に応じて、複数台のサーバ用ＰＣで構成してもよい。また、給与受取装置１０は、表示部としてのモニタや出力部としてのプリンタなども備え、給与受取システム１の作動時、保守点検時などの各種情報の表示や出力などを行うことができる。

企業端末２０、従業員端末３０は、モニタやプリンタ、通信機器などを備えた公知のデスクトップ型、ノートブック型、タブレット型のＰＣ等を使用することができる。これらがＰＣに限定されることはなく、スマートフォン、携帯電話、その他の通信ネットワーク２に接続可能で、画像等の表示機能やデータの入力機能を備えている機器を用いることができる。

次に、図２を用いて給与受取装置１０、企業端末２０、従業員端末３０のハードウェア構成例を説明する。図２（ａ）に示すように、給与受取装置１０は、ＣＰＵ１１、ＲＯＭ１２、ＲＡＭ１３、ハードディスク装置やフラッシュメモリ等からなる不揮発性ストレージ１４、有線又は無線で通信ネットワーク２，３に接続するための通信Ｉ／Ｆ１５、外部記憶媒体１６、データベース１７等を主に備えて構成される。これらの構成要素は、バス１８によって電気的に接続され、ＣＰＵ１１と各部との間でデータの送受信ができるようになっている。

ＲＯＭ１２や不揮発性ストレージ１４には、給与受取装置１０において使用される各種プログラムやデータが記憶されている。ＣＰＵ１１はマイクロプロセッサ等からなり、ＲＡＭ１３をワークエリアとして、ＲＯＭ１２や不揮発性ストレージ１４からオペレーティングシステムや各種プログラムを読み出して実行することで、給与受取装置１０全体の動作を制御する。

外部記憶媒体１６としては、例えばＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤ−ＲＯＭ、ＤＶＤ−ＲＷ、フレキシブルディスク等の記憶媒体を使用することができる。外部記憶媒体１６には、例えば給与受取プログラムを記憶しておき、ＣＰＵ１１が給与受取プログラムを読み出してＲＡＭ１３に展開することにより、給与受取プログラムを実行する構成とすることができる。

データベース１７は、給与受取装置１０が使用する各種テーブルを記憶する記憶装置（記憶部）である。データベース１７としては、クラウドプロバイダ等で提供される大容量ストレージサービス等を用いることができる。

企業端末２０及び従業員端末３０がＰＣである場合、これらは図２（ｂ）に示すように、ＣＰＵ２１、ＲＰＭ２２、ＲＡＭ２３、不揮発性ストレージ２４、通信Ｉ／Ｆ２５、外部記憶媒体２６、液晶ディスプレイ等からなる表示部２７、キーボードやマウス、タッチパネル等からなる入力部２８等を備えて構成される。これらの構成要素は、バス２９によって電気的に接続され、ＣＰＵ２１と各部との間でデータの送受信ができるようになっている。

ＣＰＵ２１は、マイクロプロセッサ等からなり、ＲＡＭ２３をワークエリアとして、ＲＯＭ２２、不揮発性ストレージ２４、外部記憶媒体２６に記憶されるオペレーティングシステムやその他のプログラムを読み出し、実行することにより、企業端末２０及び従業員端末３０の各部を制御する。

企業端末２０及び従業員端末３０がスマートフォンである場合、これらは、図２（ｃ）に示すように、ＣＰＵ３１、ＲＯＭ３２、ＲＡＭ３３、不揮発性ストレージ３４、データ読み出し又は書き込みを行うＥＥＰＲＯＭ３５、被写体を撮像するカメラ３６、電子磁気コンパスやジャイロコンパス、加速度センサ等の各種センサ３７、現在日時情報を出力するＲＴＣ（Real Time Clock）３８、マイク３９、スピーカ４０、アンテナ４１、基地局との通信や無線ＬＡＮ通信、Ｗｉ−Ｆｉ等の近距離無線通信を行う通信Ｉ／Ｆ４２、液晶ディスプレイ等の表示部４３、液晶ディスプレイ上に搭載されたタッチパネルや操作ボタン等からなる入力部４４等を備えて構成される。これらの構成要素は、バス４５によって電気的に接続され、ＣＰＵ３１と各部との間でデータの送受信ができるようになっている。

ＣＰＵ３１は、マイクロプロセッサ等からなり、ＲＡＭ３３をワークエリアとして、ＲＯＭ３２、不揮発性ストレージ３４に記憶されるオペレーティングシステムやその他のプログラムを読み出し、実行することにより、企業端末２０及び従業員端末３０の各部を制御する。

企業端末２０及び従業員端末３０は、汎用のブラウザ等を用いて通信ネットワーク２経由で給与受取装置１０にアクセスすることで、企業端末２０及び従業員端末３０側での給与受取処理を実行することができる。または、企業端末２０及び従業員端末３０に、専用の給与受取のアプリケーションプログラム（アプリ）をインストールし、当該アプリを起動することで、企業端末２０及び従業員端末３０側での給与受取プログラムを実行するようにすることもできる。

次に、本実施形態の給与受取システム１の機能を、図３の機能ブロック図を用いて説明する。以下では、給与受取装置１０の機能について主に説明する。

図３に示すように、給与受取装置１０は、機能的には、給与受取装置１０全体の動作を制御する制御部１００と、記憶部としてのデータベース１７を備えて構成される。制御部１００は、給与パターン更新部１０１、リクエスト処理部１０２、申請可能金額算出部１０３、支払金額算出部１０４、振込テーブル作成部１０５、天引きデータテーブル作成部１０６、通知部１０７として機能する。また、制御部１００は、給与受取システム１全体の動作を管理する管理部としても機能する。

データベース１７には、図４Ａ〜図４Ｇに示すような企業テーブルＴ１、給与パターンテーブルＴ２、従業員テーブルＴ３、累計データテーブルＴ４、リクエストテーブルＴ５、振込テーブルＴ６、天引きデータテーブルＴ７が記憶されている。

図４Ａは、企業テーブルＴ１の一例であり、給与受取サービスに加入した企業の各種データが、企業コードごとに記憶されている。企業テーブルＴ１へのデータの入力は、企業の給与受取サービスへの加入の際に、ホスト側で行う。企業テーブルＴ１には、企業を識別するための「企業コード」、「企業名（漢字）」、「企業名（カナ）」、給与受取システム１にアクセスするための「ログインＩＤ」、「パスワード」、「業種」、「従業員数」、「利用率」、「利用単価」、「想定立替金額」、「立替合計金額」などが記憶されている。なお、企業テーブルＴ１に設定されるデータが、これらに限定されるものではなく、他のデータを記憶することもできる。また、ここで挙げたデータをすべて設定する必要もない。給与受取システム１の仕様、導入する企業の形態や規模に応じて、必要なデータを適宜設定することができる。以降で説明する他のテーブルＴ２〜Ｔ７についても同様である。

「ログインＩＤ」、「パスワード」は、企業端末２０から企業が変更することもできるようになっている。変更の指示を受けると、企業テーブルＴ１が更新される。「立替合計金額」は、各企業の各従業員が既に受取った給与の当月の合計金額が記憶される。

「想定立替金額」は、雇用者ごとの月間の総立替金額（総受取金額）の限度額である。「想定立替金額」は、例えば、「従業員数」、「利用率」及び「利用単価」を用いて下記の計算式によって算出される。

想定立替金額（円） ＝ 従業員数（人）×利用率（％）×利用単価（円）

上記式を用いて、例えば図４Ａの「株式会社Ａ」では、従業員数１，０００人×利用率２０％×利用単価５万円＝１，０００万円が想定立替金額となる。「利用率」及び「利用単価」は、係数であり、業種、企業の規模や経営状態や実績、ホストでの過去の経験等を考慮して、ホスト側で予め設定しておくことができる。「従業員数」、「利用率」、「利用単価」は、更新できるようにして、「想定立替金額」を再計算して記憶するようにしてもよい。

ホスト側では、計算式によって算出した想定立替金額に対して与信判断を行い、与信判断の結果に応じて最終的な想定立替金額を設定するが、これに限定されるものではない。上記計算式などを用いて予め想定立替金額を算出し、これに対して与信判断した最終的な想定立替金額を、企業テーブルＴ１に記憶しておくこともできる。この場合、従業員数、利用率、利用単価を記憶する必要はなく、記憶容量を少なくすることができる。給与受取システム１は、給与に基づく所定の支払金額を、任意の時点で従業員が受け取るシステムであるという性質上、給与以上の金額の受取はできない仕組みになっている。しかしながら、一企業内（一雇用者）での給与受取サービスの利用が過剰になるのを抑制するため、想定立替金額（限度額）を設定しているものである。

図４Ｂは、給与パターンテーブルＴ２の一例であり、企業コードに対応付けられて、当該企業の雇用区分ごとの各種データが記憶されている。すなわち、本実施形態では、雇用区分ごとに、勤怠サイクル、給与支払日、前払上限率等を設定することができ、これらに基づいて受取日や受取額を、従来よりも自由に設定することができ、より利便性のよい給与受取サービスを提供することができる。

給与パターンテーブルＴ２へのデータの入力は、基本的には企業の給与受取サービスへの加入の際にホスト側で行うが、雇用者側でも企業端末２０から更新できるようになっている。

給与パターンテーブルＴ２には、「雇用区分コード」、「雇用区分名」、「給与区分」、「月間支払回数」、「日割り計算日数」、「前払上限率」、「振込口座１変更可否」、「振込口座２変更可否」、「振込口座３変更可否」、「勤務期間」、「天引きデータ締日」、「振込手数料１」、「振込手数料２」などが記憶されている。

「雇用区分コード」及び「雇用区分名」、は、雇用者ごとに予め決められた雇用区分を表すコードとその名称である。図４Ｂの例では、２０：正社員、５０：契約社員、６０：嘱託社員、９０：アルバイトが設定されているが、これらに限定されることはなく、更に多くの雇用区分を設定することができる。また、例えば正社員でも、総合職、専門職など、より細分化した雇用区分を設定することもできる。

「給与区分」は、給与の支払い形態を示し、例えば、月給、週給、日給などが設定される。「月間支払回数」は、一か月中の給与の支払い回数を示し、例えば、月給であれば１回（２回の場合もあり）、週給であれば４回などが設定される。「日割り計算日数」は、給与区分が月給時の日割り計算用の日数を示す。「前払上限率」は、給与総額の合計の中から、前払いで受取ることのできる限度の割合を百分率（％）で表したものである。

通常、給与には税金や保険料の控除があり、控除分は給与であっても用途が予め決まっている部分であるので、当該控除分を従業員に現金として支払うことは望ましくない。なお、給与総額から予め控除金額を減算しておいてもよいが、給与は日数の経過とともに増えるものであるため、給与総額の少ない月初めに給与受取申請（以下、「前払い申請」という。）をした場合、給与総額が控除額を下回り、給与の受取が全くできなくなることがある。そこで「前払上限率」を設け、税金や保険料の控除の余力を残しつつ、月初めであっても給与の少なくとも一部を受取ることができるようにしている。

「振込口座１変更可否」、「振込口座２変更可否」、「振込口座３変更可否」は、各振込口座データを従業員が変更できるか否かが設定される。本実施形態では、通常の給与の振込口座（振込口座１）の他に、２つの口座（振込口座２、３）を指定することができる。給与の振込口座である振込口座１を、従業員が勝手に変更できないようにするため、「振込口座１変更可否」には「否」が記憶されている。振込口座２、３については、従業員が自由に設定や変更ができるように「振込口座２変更可否」、「振込口座３変更可否」に「可」としてもよいし、一方のみ「可」としてもよく、企業の事情等に応じて自由に設定することができる。

「天引きデータ締日」には、給与受取の申請の締日が記憶されている。企業側では、給与受取サービスでホストが従業員に支払った支払合計金額を、給与から天引きして振込口座に振り込んでいる。勤怠サイクル締日から給与支払日までの期間が短い場合、支払合計金額を天引きするための雇用者側での処理を容易とするためには、勤怠サイクル締日よりも前に支払合計金額を知ることが望ましい。そのため、本実施形態では、給与パターンテーブルＴ３に、雇用区分ごとに勤怠サイクル締日よりも数日早い日付を、天引きデータ締日として予め記憶している。給与受取装置１０は、この天引きデータ締日に、勤怠サイクル開始日から天引きデータ締日までに支払った従業員ごとの支払合計金額を、雇用者に報告している。

「振込手数料１」、「振込手数料２」は、給与受取装置１０が従業員の振込口座に給与を振り込む際の振込手数料が記憶される。本実施形態では、振込手数料の記憶領域を２つ設けているが、これに限定されることはなく、１つのみ設けることもできるし、３つ以上設けることもできる。振込手数料の記憶領域を２以上設けておけば、例えば、振込額に応じて振込手数料を変えることなどができる。

図４Ｃは、従業員テーブルＴ３の一例であり、企業ごとに、企業コードに対応付けられて、当該企業に所属する従業員データが予め記憶されている。従業員テーブルＴ３には、「企業コード」、従業員を識別するための「従業員コード」、従業員が給与受取システム１にアクセスするための「ログインＩＤ」及び「パスワード」、従業員の「氏名（漢字）」及び「氏名（カナ）」、「雇用区分」、「振込先１」、「振込先２」、「振込先３」、時給単価ごとの「時給」、「税金区分」、「保険区分」、「メールアドレス」などが記憶されている。従業員テーブルＴ３へのデータの入力も、基本的にはホスト側で行うが、「ログインＩＤ」及び「パスワード」、所定の「振込先」は、従業員が従業員端末３０から、変更や登録ができるようになっている。

「雇用区分」には、各従業員の雇用区分名（又は雇用区分コードでもよい）が記憶され、給与パターンテーブルＴ２と対応づけられている。本実施形態では、従業員は、最大３つの振込先口座を登録できるようになっている。また、振込口座には、中央銀行や地方銀行、ネット銀行など、いわゆる銀行と呼ばれるものだけでなく、ゆうちょ銀行の口座も指定することができる。「振込先１」、「振込先２」、「振込先３」には、３つの振込先の金融機関の「金融機関番号」、「支店番号」、「種別」、「口座番号」、「口座名義」といった、振込みに必要なデータが記憶されている。

「振込先１」には、給与の振込先の口座データが予め記憶されている。「振込先１」に関しては、従業員が変更できないようにするため、給与パターンテーブルＴ２の各雇用区分の振込口座変更可否が「否」となっている。「振込先２」、「振込先３」は、予め所定の振込先を記憶しておいてもよいし、空欄（ＮＵＬＬ）としておき、後から登録できるようにしてもよい。この場合、給与パターンテーブルＴ２の振込口座変更可否を「可」としておくことで、「振込先２」、「振込先３」を従業員が変更したり、新たに登録又は削除したりするのを許可することができる。

「時給」には、従業員ごとの時給単価が記憶されている。この時給単価は、少なくとも１つあればよいが、本実施形態では、複数の時給単価が記憶できるようにしている。例えば、時給単価１には、月給を時給に換算した金額を記憶し、時給単価２、３、４，・・・には残業時、深夜残業時、休日出勤時、・・・の時給単価を記憶することができる。企業ごとに、労働時間帯や業種、職種等に応じた適宜の時給単価を記憶することができる。

「税金区分」と「保険区分」は、税金と保険料をそれぞれ支払金額から控除するか否かのフラグが記憶されている。一般的には、税金や保険料が天引きされて給与が振り込まれるため、前払い金額が多いと、税金や保険料を天引きできなくなる。そのため、支払金額を決める際に、税金や保険料などの控除額を考慮する場合は、従業員テーブルＴ３に「税金区分」と「保険区分」を設けることが望ましい。この場合、例えば、予めデータベース１７に記憶された税金額テーブルや保険料テーブルを参照することで、従業員の税金や保険料を算出することができる。

「メールアドレス」には、従業員の電子メールアドレスが記憶されている。この電子メールアドレスに対して、給与受取の申請が受付けられたときの受付内容（申請番号、振込予定日など）の通知メールが送信される。また、申請が受付けられない場合や、振込みエラーとなった場合にも、この電子メールアドレスに対してエラーの通知メールが送信される。この他にも、申請取消が受付けられたときの通知メールや、お知らせメールなどを送信することもできる。

図４Ｄは、累計データテーブルＴ４の一例であり、企業コード及び従業員コードごとに、当該企業コード及び従業員コードに対応付けられて、各従業員の当月の労働時間の累計データが時給単価ごとに記憶されている。この累計データテーブルＴ４へ入力するデータは、例えば、企業側から毎日の就業時間終了後にバッチデータとして送信されてくるものであってもよい。また、企業側の勤怠システムと連携させ、勤怠システムから給与受取装置１０にリアルタイムに送信される勤怠データを、リアルタイムで累計データテーブルＴ４に記憶させるものであってもよい。

図４Ｅは、リクエストテーブルＴ５の一例であり、企業コード及び従業員コードごとに、当該企業コード及び従業員コードに対応付けられて、各従業員からの給与受取の申請（リクエスト）、申請取消の履歴データが記憶される。リクエストテーブルＴ５には、従業員からの新たなリクエストが受け付けられるたびに、新たなカラムが作成されてリクエストデータが記憶されていく。

リクエストテーブルＴ５には、「企業コード」及び「従業員コード」に対応して、申請ごとに「申請データ」（カラム）が作成されて記憶される。リクエストテーブルＴ５には、申請ごとに「申請日」、「申請金額」、「振込金額」、「振込手数料」、「申請番号」、「振込先」、「振込日」、「申請状況フラグ」などが記憶される。

「申請日」には、リクエスト（申請）があった日付が記憶される。「申請金額」には、従業員が申請した希望の金額が記憶される。「振込金額」には、実際に振り込まれる支払金額が記憶される。「振込手数料」には、振込手数料が記憶される。「申請番号」には、申請を識別する番号が自動的に付与されて記憶される。「振込先」には、申請した従業員が指定した振込先が記憶される。「振込日」には、振込予定日が記憶される。「申請状況フラグ」は、振込み状況を識別するためのフラグである。「１」は申請中、すなわち申請を受付けたことを示し、「２」は申請が取消されたことを示す。「３」は振込み中、すなわち金融機関に振込みデータを記載した振込テーブルＴ６の送信が完了したことを示す。また、「４」は振込エラー又は振込エラーが確定したことを示す。「５」は振込みが完了したことを示す。また、振込み完了後に、振込金額を給与から天引きすることが確定し、ホストが立替えた当該振込金額をホストから雇用者に請求済みのときに「５」を記憶するようにしてもよい。

図４Ｆは、振込テーブルＴ６の一例であり、給与の振込みに関するデータが記憶される。振込テーブルＴ６は、給与受取の申請が受付けられ、金融機関の振込システム５０に振込みデータを送信するときに作成される。振込テーブルＴ６には、振込元の金融機関データ、すなわちホストの口座データが「振込元金融機関番号」、「振込元支店番号」、「振込元預金種別」、「振込元口座番号」、「振込元口座名義」として記憶され、従業員からの指定により従業員テーブルＴ３から取得した従業員口座データが「振込先金融機関番号」、「振込先支店番号」、「振込先預金種別」、「振込先口座番号」、「振込先口座名義」として記憶されるとともに、「振込金額」と「振込指定日」が記憶される。

図４Ｇは、天引きデータテーブルＴ７の一例であり、「企業コード」、「従業員コード」に対応づけられて、各従業員が勤怠サイクルの開始日から、天引きデータ締日までに従業員に支払った金額の合計（「支払合計金額」）が記憶される。

次に、制御部１００の各部の機能の概要を説明する。給与パターン更新部１０１は、企業端末２０から入力される給与パターンの変更データを受付け、データベース１７の給与パターンテーブルＴ２を更新する機能を有している。また、給与パターン更新部１０１は、企業端末２０に対して、その表示部２７に画像を表示するためのデータを送信する画像生成部としての機能や、ログインＩＤとパスワードに基づいて、企業端末２０からのアクセスを許可するか否かを認証する認証部としての機能も有している。

リクエスト処理部１０２は、従業員端末３０からの給与受取に関する申請（リクエスト）を受け付け、リクエストテーブルＴ５に記憶する機能を有している。給与受取に関する申請としては、給与受取の申請、取消の申請、利用履歴確認の申請などが挙げられる。

また、リクエスト処理部１０２は、従業員端末３０に対して、その表示部２７に画像を表示するためのデータを送信する画像生成部としての機能や、ログインＩＤとパスワードに基づいて、従業員端末３０からのアクセスを許可するか否かを認証する認証部としての機能も有している。

また、リクエスト処理部１０２は、天引きデータ締日から勤怠サイクル締日まで、給与受取の申請を受付けないように制御する機能も有している。前述したように、本実施形態では、給与振込みの雇用者側での処理を容易とするため、勤怠サイクル締日よりも前の天引きデータ締日に、各従業員の支払合計額を算出し、雇用者に報告している。しかし、天引きデータ締日から勤怠サイクル締日の間に、給与受取の申請があると、当月分の給与からの天引き処理に間に合わず、次月に天引きする必要があるなど、処理が複雑となってしまう。そのため、本実施形態では、天引きデータ締日から勤怠サイクル締日までの間、前払い申請ができないようにリクエスト処理部１０２が制御している。

また、リクエスト処理部１０２は、各金融機関の営業日カレンダーを記憶しておき、このカレンダーに応じて、前払い申請ができる期間（以下、「前払い申請ＯＫ期間」という。）と、できない期間（以下、「前払い申請ＮＧ期間」という。）とを決定している。図１０に、前払い申請ＯＫ期間とＮＧ期間とを説明するための説明図を示す。この図１０の例では、当該従業員の雇用区分に対する勤怠サイクルが１６日（from：勤怠サイクル開始）〜翌月１５日（to：勤怠サイクル締日）となっている。また、雇用者で天引きデータを必要とする期限が翌月１１日であることから、給与パターンテーブルＴ２の天引きデータ締日は、期限前日の１０日が設定されている。より詳細には本実施形態では、１０日の午前１１時を期限とし、１１時までの給与受取の申請は受付けるが、１１時以降の申請は受付けないようにしている。１１時は、バッチ処理によって天引きデータテーブルＴ７が作成される時間である。

ここで、図１０に示すように、天引きデータ締日の１０日が日曜であった場合、その直前の営業日の８日を、天引きデータ締日としている。したがって、この月は勤怠サイクル開始の１６日から８日の１１時までが前払い申請ＯＫ期間となり、８日の１１時から勤怠サイクル締日の１５日までは、前払い申請ＮＧ期間となる。次回の１０日は平日であるので、次月は１６日から１０日の１１時までが、前払い申請ＯＫ期間となり、１０日の１１時以降から１５日までが前払い申請ＮＧ期間となる。

申請可能金額算出部１０３は、従業員が給与受取（前払い）を申請できる申請可能金額を算出する機能を有している。申請可能金額算出部１０３は、従業員テーブルＴ３の時給単価及び累計データテーブルＴ４の労働時間に基づいて、現在までの労働に対する対価を算出する。申請可能金額算出部１０３は、算出した現在までの労働に対する対価に、給与パターンテーブルＴ２から取得した「前払上限率」を乗算し、得られた金額からリクエストテーブルＴ５から取得した支払済み金額の合計金額を減算し、申請可能金額を算出する。

支払金額算出部１０４は、申請可能金額算出部１０３で算出した申請可能金額と、従業員が申請した申請金額と、企業テーブルＴ１の立替合計金額及び想定立替金額（限度額）とに基づいて、支払金額（振込金額）を算出する。すなわち、申請金額が申請可能金額以下であって、申請金額と立替合計金額との合計が想定立替金額（限度額）以下である場合は、申請金額を支払金額とする。これに対して、申請金額が申請可能金額を超過した場合は、申請金額から超過金額を減算した金額を支払金額とする。また、支払金額算出部１０４は、この支払金額に応じた手数料を、支払金額から減算し、最終的な支払金額とする。また、申請金額と立替合計金額との合計が想定立替金額（限度額）を超過する場合は、アラート表示（警告）する。

振込テーブル作成部１０５は、振込先口座や振込金額を指定して、金融機関の振込システム５０に送信する振込テーブルＴ６を作成する機能を有している。なお、本実施形態では、振込先口座としてゆうちょ銀行の口座も指定することができる。銀行の場合は、支店番号が３桁で、口座番号が７桁（全銀形式）であるため、銀行口座を指定された場合は、そのまま従業員テーブルＴ３の「振込先１」、「振込先２」、「振込先３」に記憶している。

これに対して、ゆうちょ銀行は、支点番号が５桁で口座番号が８桁（記号番号形式）になっている。そのため、全銀形式で振込手続きを行う場合、ゆうちょ銀行の支店番号と口座番号とを全銀形式の番号体系に変換する必要がある。企業によっては、ゆうちょ銀行の支店番号と口座番号とを記号番号形式のまま保持している場合と、全銀形式の番号体系に変換して保持している場合と、記号番号形式ではあるが、全銀形式の支店番号３桁、口座番号８桁に対応させて、一部の数字を切り捨てて保持している場合とがある。

本実施形態の給与受取システム１では、企業が保有している形式のままで従業員テーブルＴ３の振込口座にデータを記憶できるようにしている。そして、振込テーブル作成部１０５に記憶された振込口座データの形式に応じて、適宜変換して振込テーブルＴ６を作成するものとしている。したがって、雇用者側で変換などの手間を行う必要がなく、雇用者側の利便性を向上させることができる。

具体的には、振込テーブル作成部１０５は、ゆうちょ銀行の口座番号の記号番号形式の場合と一部の数字を切り捨てている場合は、全銀形式に変換して、振込テーブルＴ６を作成する。一方、全銀形式の場合は、変換することなく振込テーブルＴ６を作成する。

天引きデータテーブル作成部１０６は、給与パターンテーブルＴ２の天引きデータ締日に応じて、各雇用者の従業員ごとに、給与受取の合計金額（天引き額）を算出し、雇用者ごとの天引きデータテーブルＴ７を作成する機能を有している。この天引きデータテーブルＴ７は、天引きデータ締日にホストから各雇用者に提供される。

なお、天引きデータテーブルＴ７は、バッチファイルとして提供してもよいし、容量が小さい場合は電子メールに添付して提供してもよい。また、雇用者が企業端末２０から給与受取装置１０にアクセスすることで、天引きデータテーブルＴ７の閲覧、印刷、ダウンロードなどを行うことができるようにしてもよい。また、企業の勤怠システムと連携させて提供してもよい。

通知部１０７は、リクエスト処理部１０２などからの指示に応じて、従業員端末３０に、電子メールを送信する機能を有している。電子メールの内容としては、給与受取の申請の受付け通知、振込みエラー通知などが挙げられる。通知部１０７は、企業コード及び従業員コードに対応して、従業員テーブルＴ３から従業員の電子メールアドレスを取得し、通知内容に応じた電子メールを作成して送信する。

以下、上述のような構成の本実施形態に係る給与受取システム１によって実行される給与受取処理（給与受取方法、給与受取サービス）の流れの一例について、図面を参照しながら説明する。給与受取処理は、給与パターンデータ更新処理、給与受取の申請処理、利用履歴の確認処理、給与受取申請の取消処理、振込み処理、天引きデータテーブル作成処理などの処理を含んでいる。

まず、企業側で給与パターンデータを更新する際の給与パターンデータ更新処理について、図５Ａのシーケンス図及び図６の画面例を参照しながら説明する。まず、ステップＳ１００において、雇用者は企業端末２０のブラウザ又はアプリを立ち上げて、給与受取装置１０にアクセスする。例えば、企業端末２０で、給与受取装置１０に割り当てられたＵＲＬを直接に又はアプリで指定することで、給与受取装置１０にアクセスする。

企業端末２０からのアクセスは、給与パターン更新部１０１に通知される。この通知を受信した給与パターン更新部１０１は、企業端末２０に対してログイン画面の表示に必要なデータを送信して、図６（ａ）に示すようなログイン画面６０を表示部２７に表示させる（ステップＳ１０１）。このログイン画面６０で、雇用者はログインＩＤとパスワードを入力することができる（ステップＳ１０２）。なお、ログインＩＤは、予め決められた任意のものであってもよいし、電子メールアドレスや、企業コードなどであってもよい。

ログイン画面６０から入力されたログインＩＤとパスワードは、給与パターン更新部１０１に送信される。給与パターン更新部１０１は、入力されたログインＩＤとパスワードの組み合わせが、企業テーブルＴ１に存在するか否かを判定する（ステップＳ１０３）。存在しないと判定した場合は（ステップＳ１０３の判定がＮＯ）、企業端末２０に対してエラーを通知する。このエラー通知を受信すると、企業端末２０は、ステップＳ１０２に戻り、雇用者に対してログイン処理を再度行わせることができる。

ステップＳ１０３で、存在すると判定した場合は、ログインが成功したとして次のステップＳ１０４に進む。このステップＳ１０４では、給与パターン変更部１０１が、企業コードをキーとして給与パターンテーブルＴ２から当該雇用者の給与パターンデータを読み出す。そして、給与パターン変更初期画面６１を表示するためのデータを企業端末２０に送信し、図６（ｂ）に示すような給与パターン変更初期画面６１を表示部２７に表示させる。

給与パターン変更初期画面６１には、「雇用区分コード」、「雇用区分名」、「給与区分」の一覧が表示される。雇用者は、変更したい雇用区分の「詳細」をマウス等で押下して選択することで、選択された雇用区分が給与パターン変更部１０１に送信される（ステップＳ１０５）。例えば、図６（ｂ）の例では、「正社員」が選択された。

給与パターン受付部１０１は、選択された雇用区分をキーとして、給与パターンテーブルＴ２から詳細なデータを取得する。取得したデータを送信することで、図６（ｃ）に示すような給与パターン詳細画面６２を表示部２７に表示させる（ステップＳ１０６）。この給与パターン詳細画面６２には、「雇用区分コード」、「雇用区分名」、「月間支払回数」などの給与パターンデータが表示される。雇用者は、給与パターン詳細画面６２上で、変更したい項目のデータを入力（更新）する（ステップＳ１０７）。

変更された給与パターンデータは、企業端末２０から給与パターン更新変更部１０１に送信される。給与パターン更新部１０１は、受信した給与パターンデータで給与パターンテーブルＴ２を更新する（ステップＳ１０８）。

なお、給与パターン変更初期画面６１に、雇用区分の追加ボタンや削除ボタンを設けて、雇用者が雇用区分の追加や削除が行えるようにしてもよい。具体的には、給与パターン変更初期画面６１上で、追加ボタンを押下することで、給与パターン詳細画面６２に移動し、雇用者は新たな雇用区分コードと、これに対応する給与パターンデータを入力できるようにする。この入力を受けて、給与パターン更新部１０１は、追加された雇用区分の給与パターンデータを、給与パターンテーブルＴ２に追加する。また、給与パターン変更初期画面６１上でいずれかの雇用区分を選択し、削除ボタンを押下することで削除指定できるようにする。この指定を受けて、給与パターン更新部１０１は当該雇用区分の給与パターンデータを給与パターンテーブルＴ２から削除する。

次に、従業員が給与の受取をリクエスト（申請）する際の給与受取の申請処理の一例を、図５Ｂのシーケンス図及び図７の画面例を参照しながら説明する。まず、ステップＳ２００において、従業員は従業員端末３０のブラウザ又はアプリを立ち上げて、給与受取装置１０にアクセスする。例えば、従業員端末３０で、給与受取装置１０に割り当てられたＵＲＬを直接に又はアプリで指定することで、給与受取装置１０にアクセスする。

従業員端末３０からのアクセスは、リクエスト処理部１０２に通知される。この通知を受信したリクエスト処理部１０２は、従業員端末３０に対してログイン画面を表示するために必要なデータを送信して、図７（ａ）のようなログイン画面７０を表示部２７に表示させる（Ｓ２０１）。このログイン画面６０において、従業員はログインＩＤとパスワードを入力することができる（ステップＳ２０２）。ログインＩＤは、予め決められた任意のものであってもよいし、電子メールアドレスであってもよいし、企業コードと従業員コードの組み合わせなどであってもよい。

また、一度ログインが成功した後は、同じ従業員端末３０からの次回アクセス時にはステップＳ２０１、Ｓ２０２の処理をスキップして、ログインの認証を行うことなく、ステップＳ２０３に進み、給与受取処理を実行してもよい。

また、画面に表示されたメニューバーｍ１から、パスワードの変更処理を選択できるようにしてもよい。この選択の指示を受け付けると、リクエスト処理部１０２が、表示部２７に図７（ｂ）に示すパスワード変更画面７１を表示させる。従業員は、このパスワード変更画面７１から新たなパスワードを入力することができる。パスワード変更画面７１から入力された新たなパスワードは、リクエスト処理部１０２によって、有効性のチェックが行われ、有効と判断されたときは従業員テーブルＴ３に記憶されるが、無効と判断されたときは記憶されない。パスワードの変更又は無効の通知メールが、通知部１０７によって従業員テーブルＴ３に記憶された電子メールアドレスに通知される。

ログイン画面７０から入力されたログインＩＤとパスワードは、リクエスト処理部１０２に送信される。リクエスト処理部１０２は、入力されたログインＩＤとパスワードの組み合わせが、従業員テーブルＴ３に存在するか否かを判定し（ステップＳ２０３）、存在しないと判定した場合は（ステップＳ２０３の判定がＮＯ）、従業員端末３０に対してエラーを通知する。このエラー通知を受信すると、従業員端末３０は、ステップＳ２０２に戻り、従業員に対してログイン処理を再度行わせることができる。

ステップＳ２０３で、存在すると判定した場合は、ログインが成功したとして次のステップＳ２０４へ進み、申請日が申請ＯＫ期間内か否かを判定する。前払い申請ＮＧ期間（ステップＳ２０４の判定がＮＯ）の場合は、給与受取の申請ができないため、処理を終了する。このとき、従業員端末３０に、給与受取の申請ができない期間である旨のメッセージを表示してもよい。

前払い申請ＯＫ期間（ステップＳ２０４の判定がＹＥＳ）の場合は、ステップＳ２０５へ進む。このステップＳ２０５では、リクエスト処理部１０２が、図８（ａ）のように、お知らせなどが表示された申請トップ画面７２を、表示部２７に表示させる。

この申請トップ画面７２では、従業員が申請手続きを行うだけでなく、振込先口座の確認、登録、更新を行うことができる。この場合、従業員が、申請トップ画面７２のメニューバーｍ１において、「振込先口座の確認、登録、更新」を選択する（ステップＳ２０６）。この選択を受けて、リクエスト処理部１０２は、従業員テーブルＴ３から３つの振込先口座のデータを取得して、表示部２７に、図８（ｂ）に示すような振込先口座一覧画面７３を表示させる（ステップＳ２０７）。このとき、給与パターンテーブルＴ２の各口座の振込口座変更可否の内容を確認し、可の場合は、当該口座の欄に、削除、変更、登録のアイコンを表示する。

この振込先口座一覧画面７３を視認することで、従業員は振込先口座を確認することができる。また、図８（ｂ）の例では、企業指定口座が「振込先１」に表示され、変更不可となっている。また、振込先２、３は従業員が自由に入力でき、振込先２については、既に登録がされた口座の内容が表示され、削除ボタン又は変更ボタンの押下により、削除と変更ができるようになっている。また、振込先３は、未登録であり、登録ボタンの押下により登録ができるようになっている。

振込先口座一覧画面７３で削除が選択されたときは、リクエスト処理部１０２は、従業員テーブルＴ３から当該振込先のデータを削除する。振込先口座一覧画面７３で更新又は登録が選択されたときは、リクエスト処理部１０２は、適宜の更新・登録画面を表示する。従業員は、この画面から口座の更新や登録を行うことができる。口座の更新、登録が実行された際には、リクエスト処理部１０２は、従業員テーブルＴ３の口座を更新する（ステップＳ２０８）。

一方、従業員が給与受取を申請する場合、申請トップ画面７２で、「申請する」を押下することで、申請の実行指示がリクエスト処理部１０２に通知される（ステップＳ２０９）、これを受付けたリクエスト処理部１０２の指示により、申請可能金額算出部１０３が、当該従業員が受取ることのできる申請可能金額を算出する（ステップＳ２１０）。具体的には、申請可能金額算出部１０３は、企業コードと従業員コードに基づいて、従業員テーブルＴ３及び累計データテーブルＴ４から当該従業員のデータを取得する。そして、現在までの労働時間を累計した累計データに時給単価を乗算し、現在までの給与金額を算出する。時給単価が複数設定されている場合は、それぞれの乗算結果を合計することによって、現在までの給与金額を算出する。

次に、申請可能金額算出部１０３は、従業員テーブルＴ３から取得した雇用区分をキーとして、給与パターンテーブルＴ２から「前払上限率」を取得する。この「前払上限率」を、上記で算出した現在までの給与金額に乗算して「申請可能金額」を算出する。このとき、乗算後の金額を、所定の桁数（百円単位や千円単位）で切り捨て或いは四捨五入等してもよい。このように「給与金額」に「前払上限率」を乗算することで、「給与金額」全部が「申請可能金額」となることがなく、税金や保険料の控除額まで従業員に支払ってしまうのを抑制することができる。

また、申請可能金額算出部１０３は、当月において既に前払い申請があった場合は、支払い済みの金額（既払金額）を上記申請可能金額から減算する。具体的には、リクエストテーブルＴ５を参照して、申請状況フラグが「１」（申請中）、「３」（振込み中）、又は「５」（振込完了）のものを抽出し、これらの「振込金額」を合計して既払金額を算出し、上記申請可能金額から減算して、最終的な申請可能金額とする。以下に、計算式の一例を挙げる。

申請可能金額(円) ＝ 労働時間累計データ（ｈ） × 時給単価（円） × 前払上限率 − 既払金額（円）

なお、上記申請可能金額の算出手順は、一例であり、これに限定されることはない。算出手順の他の例として、「給与金額」から予め前払い申請があった合計金額を減算し、算出された金額に所定の「前払上限率」を乗算し、この乗算後の金額を申請可能金額とすることもできる。

そして、リクエスト処理部１０２は、算出された申請可能金額を従業員端末３０に送信し、図８（ｃ）に示すように、申請金額入力画面７４を表示部２７に表示させる（ステップＳ２１１）。この申請金額入力画面７４には、申請可能金額、金額指定アイコン、申請金額入力欄等が表示される。従業員は、この申請金額入力欄に、希望の申請金額を入力する（ステップＳ２１１）。このとき、金額指定アイコンの押下によって、千円単位、５千円単位で金額を入力することもできるし、テンキー等から直接に金額を入力することができる。また、全額ボタンの押下によって、全額をワンタッチ入力することもできる。希望の申請金額を入力して従業員が「次へ」を押下することで、希望の申請金額がリクエスト処理部１０２に通知される。

この申請金額の入力を受けて、支払金額算出部１０４が支払金額（振込金額）を算出する（ステップＳ２１３）。まず、支払金額算出部１０４は、申請金額が申請可能金額以下である場合は、申請金額を支払金額とし、申請金額が申請可能金額を超過する場合は、申請可能金額を支払金額とする。これにより、申請金額が申請可能金額を超過していても、申請が受付けられ、従業者は少なくとも申請可能金額分は給与を受取ることができる。

次に、企業テーブルＴ１から取得した立替合計金額に、支払金額を加算する。この加算した金額が、想定立替金額（限度額）を超過する場合は、企業名等とともに超過した旨を給与受取装置１０のモニタ等にアラート表示（警告）する。これにより、ホスト側で所定の企業全体での給与の支払金額が想定立替金額（限度額）に達したことを知ることができる。また、ホストから企業側に限度額に達したことを伝えて注意を促すこともできる。

なお、支払金額の算出の異なる例として、企業テーブルＴ１から取得した立替合計金額に、支払金額を加算した金額が、想定立替金額（限度額）を超過する場合は、この超過金額を減算した金額を最終的な支払金額とすることもできる。これにより、企業全体での給与の支払金額が過度に多くなるのを抑制することができる。

そして、最終的な支払金額から、支払金額に応じた手数料（給与パターンテーブルＴ２から取得）を減算し、手数料差引後振込金額を算出する。リクエスト処理部１０２は、この手数料差引後振込金額を送信し、図８（ｄ）に示すような振込金額確認画面７５を、表示部２７に表示させる（ステップＳ２１４）。

従業員が、この振込金額確認画面７５上で「次へ」を押下して、振込金額を確定させると（ステップＳ２１５）、リクエスト処理部１０２は、図８（ｅ）に示すような振込先口座指定画面７６を表示部２７に表示させる（ステップＳ２１６）。従業員は、振込先口座指定画面７６のプルダウンリストから、振込先口座を選択し、「次へ」を押下することで、振込先口座が確定する（ステップＳ２１７）。なお、振込先口座指定画面７６で、「戻る」を押下することで、申請金額入力画面７４に戻り、申請金額の再入力を行うこともできる。

この振込先口座の確定を受けて、リクエスト処理部１０２は、図８（ｆ）に示すような申請内容確認画面７７を表示部２７に表示させる（ステップＳ２１８）この申請内容確認画面７７の内容で申請を確定させる場合は、従業員は「確定する」を押下する（ステップＳ２１９）。また、申請内容確認画面７７上で「戻る」を押下すれば、振込先口座指定画面７６に戻ることができる。

「確定する」が押下されると、リクエスト処理部１０２は、図８（ｇ）に示すように、振込日（予定日）と申請番号が表示された受付完了画面７８を表示部２７に表示する（ステップＳ２２０）。振込日は、申請日、申請時間及び金融機関の振込システム５０へ振込データを送信するタイミングに応じて、各営業期間の営業日カレンダーを参照して決定する。例えば、金融機関５０に当日振込みを申請できる最終時刻を予め決めておき、最終時刻までに、給与受取の申請があった場合には、申請日を振込日とする。また、最終時刻を超過した場合、申請日が金融機関の休日である場合には、申請日の翌日を振込日とする。さらにこれらの振込日が金融機関の休日である場合は、翌営業日を振込日とする。このように、本実施形態の給与受取システム１では、従業員からの給与受取の申請受付けは、前払い申請ＮＧ期間でない限りは、土日や祝祭日など、金融機関の休日でも行って、振込みを予約することができる。

次いで、リクエスト処理部１０２は、確定した申請に基づいて、リクエストテーブルＴ５に新たなカラム（レコード）を作成する（ステップＳ２２１）。この場合において、リクエストテーブルＴ５の当該新たなカラムの「申請日」には、申請時点の日付が記憶されるが、天引きデータテーブルＴ７作成のバッチ処理の都合上、日付だけでなく時刻も記憶することが望ましい。「申請金額」には従業員が入力した申請金額が記憶され、「振込金額」には手数料等を差し引いて確定した最終的な支払金額が記憶される。「振込先」には、従業員に指定された振込口座の名称（「振込先口座１」など）又は識別子が記憶され、「振込日」は、先に決定した振込日の予定日が記憶される。「申請状況フラグ」には、「１」（申請中）が記憶される。リクエスト処理部１０２は、これらのデータと、企業コード及び従業員コードとを対応付けてリクエストテーブルＴ５に記憶する。

次にリクエスト処理部１０２は、通知部１０７に対し、申請が承認されたことを従業員に通知するための電子メールを送信するように指示する。この指示を受けた通知部１０７は、申請日、申請番号、振込金額、振込日、承認された旨の内容などを記載した受付完了メールを作成し、従業員テーブルＴ３から取得した電子メールアドレスに送信する（ステップＳ２２２）。この電子メールを確認することで、従業員は自らが行った給料受取の申請が承認されたことを知ることができる。

なお、本実施形態では、給与受取装置１０で申請を自動的に承認するようにしているが、他の異なる実施形態として、雇用者が承認処理を行うようにすることもできる。この場合、企業テーブルＴ１に、雇用者が承認するか否かの承認フラグを記憶しておく。この承認フラグがオンになっているとき、リクエストテーブルＴ５の作成時に、リクエストテーブルＴ５にも、承認処理を行う旨を記憶する。すなわちリクエストテーブルＴ５の承認フラグをオンにする。そして、企業端末２０から当該企業のリクエストテーブルＴ５をアクセスできるようにして、承認するかしないかを入力できるようにする。例えば、雇用者は、申請を承認する場合は承認フラグに「１」を記憶し、承認しない場合は「２」を記憶する。給与受取装置１０では、この承認結果を記載した電子メールを従業員に送信するようにしてもよい。

次に、給与受取サービスの利用履歴の確認処理と、給与受取申請の取消処理の一例について、図５Ｃのシーケンス図及び図９の画面例を参照しながら説明する。

従業員は、給与受取装置１０にアクセスした状態で、図９（ａ）に示す申請トップ画面７２において、メニューバーｍ１によって利用履歴確認を選択する（ステップＳ２５０）。この選択を受けて、リクエスト処理部１０２は、リクエストテーブルＴ５から、当該従業員の当月のリクエストデータを取得し、振込金額をすべて加算して、今月の利用金額を算出する（ステップＳ２５１）。そして、この今月の利用金額と、リクエストテーブルＴ５のデータを従業員端末３０に送信し、その表示部２７に図９（ｂ）に示すような利用履歴確認画面７９を表示させる（ステップＳ２５２）。この利用履歴確認画面７９には、今月の利用金額と、過去の申請の履歴データ（例えば、過去１年分、過去２年分など）が表示される。また、申請状況フラグに応じたステータスも表示されるため、従業員は振込みが完了したか、振込みエラーとなったかなどを確認することができる。

この履歴データの中から、例えば申請状況が「振込中」など、振込みが完了していない所定の給与受取の申請を取消すことができる。この取消しを行うため、従業員が利用履歴確認画面７９中の「申し込みを取り消す」を押下すると、申請の取消指示がリクエスト処理部１０２に送信される（ステップＳ２５３）。

この申請の取消指示を受けて、リクエスト処理部１０２は、図９（ｃ）に示すような申請取消確認画面８０を表示部２７に表示させる（ステップＳ２５４）。従業員は、この申請取消確認画面８０の内容を確認し、取消を確定させる場合は、「申請取消」を押下して、取消を確定させる（ステップＳ２５５）。この指示を受けて、リクエスト処理部１０２は、図９（ｄ）に示すような取消受付完了画面８１を表示する（ステップＳ２５６）。従業員は、この取消受付完了画面８１を視認することで、申請が取消されたことを確認することができる。なお、申請取消は、利用履歴確認画面７９を表示することでも確認することができる。また、通知部１０７に指示して申請取消の受付けメールを送信してもよい。

また、リクエスト処理部１０２は、振込テーブルＴ６から当該申請の振込データを削除し（ステップＳ２５７）、リクエストテーブルＴ５の「申請状況フラグ」に「２」（取消）を書込む（ステップＳ２５８）。これにより、申請の取消しが確定する。

次に、承認された給与受取の申請に従って、従業員の口座に対して振込みを行う際の振込み処理の一例について、図５Ｄのシーケンス図を参照しながら説明する。なお、金融機関の振込システム５０の動作は、各金融機関によって異なり、それぞれの仕様に応じた動作が行われる。

まず振込テーブル作成部１０５は、リクエストテーブルＴ５を参照して、図４Ｆに示す振込テーブルＴ６を作成する（ステップＳ３００）。このとき、自動認証の場合は、支払いが完了していないすべての申請について、振込テーブルＴ６を作成するが、雇用者での承認を行う場合は、承認フラグが「１」、つまり承認済みとなっている申請について、振込テーブルＴ６を作成する。

振込テーブルＴ６の「振込元金融機関番号」、「振込元支店番号」、「振込元預金種別」、「振込元口座番号」、「振込元口座名義」には、本実施形態では、ホストの口座に関するデータを記憶する。「振込先金融機関番号」、「振込先支店番号」、「振込先預金種別」、「振込先口座番号」、「振込先口座名義」には、リクエストテーブルＴ５の企業コード及び従業員コード並びに振込先に基づいて、従業員テーブルＴ３から取得した、当該従業員の振込先データを記憶する。また、「振込金額」及び「振込指定日」には、リクエストテーブルＴ５の振込金額と振込指定日をそれぞれ記憶する。

作成された振込テーブルＴ６は、所定のタイミングで振込先の金融機関の振込システム５０に送信される。この送信が完了すると、振込テーブル作成部１０５は、リクエストテーブルＴ５の申請状況フラグに「３」（振込中）を書込む（ステップＳ３０２）。振込テーブルＴ６を受信した振込システム５０では、公知の振込処理により、指定された振込日と口座に従って、指定された振込金額を振込む（ステップＳ３０３）。

また、振込テーブル作成部１０５は、振込みが成功したか否かを監視する機能も備えている。すなわち、振込テーブルＴ６の送信後に、振込テーブル作成部１０５は、所定時間ごとに金融機関の振込システム５０にアクセスして、振込ステータスを確認する（ステップＳ３０４）。

振込システム５０は、リクエスト処理部１０２に対して振込ステータスを送信する（ステップＳ３０５）。この振込ステータスを受信すると、リクエスト処理部１０２は、エラーがあるレコードがあるか判定する（ステップＳ３０６）。エラーがあると判定されたレコードに対応する申請に関しては、リクエストテーブルＴ５の申請状況フラグに「４」（振込エラー）を書込む（ステップＳ３０７）。

次いで、リクエスト処理部１０２は、通知部１０７に対し、振込みエラーとなったこと従業員に通知するための電子メールを送信するように指示する。この指示を受けた通知部１０７は、振込みエラーとなった旨を記載した電子メールを作成し、従業員コードの電子メールアドレスに送信する（ステップＳ３０８）。この電子メールを確認することで、従業員は給与の振込みがエラーとなったことを知ることができる。より詳細な情報を知りたいときは、従業員は、利用履歴確認画面７９を確認すればよい。なお、電子メールにエラーとなった申請の申請日、申請番号、振込金額などを記載するようにしてもよく、従業員が利用履歴確認画面７９を確認しなくても、詳細を知ることができる。一方、エラーのないレコードに対応する申請については、申請状況フラグに「５」（振込完了）を書込む（ステップＳ３０９）。

以上の処理により、従業員は給与の前払いを受けることができる。また、ホストが立替えて従業員の口座に給与を振込むので、雇用者は給与支払日前に従業員に対して給与を支払う必要がない。そのため、雇用者の口座にまとまった金額を確保しておく必要もないし、残高不足等による振込みエラーなども回避できる。

次に、天引きデータテーブルＴ７の作成処理の流れの一例について、図５Ｅのシーケンス図及び図１０の説明図を参照しながら説明する。給与受取装置１０において、天引きデータテーブル作成部１０６は、給与パターンテーブルＴ２から「勤務期間」（勤怠サイクル）と、「天引きデータ締日」を取得し、各金融機関の営業日カレンダーに基づいて、当月の天引きデータ締日を決定する（ステップＳ４００）。つまり、天引きデータ締日が金融機関の休日であれば、その前の金融機関営業日を天引きデータ締日とする。

天引きデータ締日の午前１１時になると、バッチ処理によって、天引きデータテーブル作成部１０６が、天引きデータテーブルＴ７の作成を開始する。まず、リクエストテーブルＴ５から、企業コード及び従業員ごとに、リクエストデータを取得する（ステップＳ４０１）。そして、申請状況フラグが「５」（振込完了）のリクエストデータを検出し、従業員ごとに振込金額と振込手数料とを合計し、支払合計金額を算出し、天引きデータテーブルＴ７を作成する（ステップＳ４０２）。このとき、エラーや取消以外のもの、つまり申請状況フラグが「１」（申請中）、「３」（振込中）の振込み予定のリクエストデータの振込金額と振込手数料を支払合計金額に加算してもよい。天引きデータテーブルＴ７は、各雇用者に提供される。

雇用者は、各従業員の給与計算をするときに、税金や保険料などとともに、天引きデータテーブルＴ７に基づいて各従業員の給与から支払金額の合計金額を減算する（ステップＳ４０３）。減算後の金額を給与支払日に所定の振込み口座へ振り込んで給与の支払を行う（ステップＳ４０４）。これにより、従業員は残りの給与を受取ることができる。また、雇用者は、各従業員の給与から減算した金額、すなわちホストが立替えた立替金額と給与受取システム１の使用料を、ホストの口座に振り込んで、ホストへの支払いを行う（Ｓ４０５）。雇用者は、給与から差し引いた金額をホストに支払えばよいので、雇用者に負債などが発生することがない。ホストへの支払いは、振込みに限定されることはなく、自動引き落としなどでもよい。

以上、本実施形態の給与受取システム１によれば、従業者の給与の少なくとも一部を、雇用者に代わってホストが立て替えて支払うので、雇用者は給与支払日前に従業者に対して給与を支払う必要がなく、雇用者の負債となることもない。そのため、雇用者の口座にまとまった金額を確保しておく必要がなく、雇用者の負担を軽減することができる。

また、従業員の一日の労働時間の累計データと、予め設定された給与単価に基づいて従業者の申請可能金額を算出し、雇用者ごとに設定された月間の想定立替金額（限度額）、算出された申請可能金額及び申請金額に基づいて、支払金額を算出している。そのため、雇用者が日給データを算出する手間などを省くことができる。また、申請金額が申請可能金額よりも多い場合でも、従業者は申請可能金額を超えない範囲で給与を受取ることができるとともに、過大な受取りを抑制することができる。また、雇用者ごとに限度額が設定されおり、この限度額を超えた場合は、アラート表示（警告）することで、雇用者全体での給与の受取金額が過度になるのを防ぐことができる。

また、本実施形態の給与受取システム１による給与受取方法は、従業者から申請金額を含む給与受取の申請を受け付ける工程と、従業者の労働時間の累計データ、給与単価及び既に支払った金額に基づいて従業者の給与受取の申請可能金額を算出する工程と、雇用者ごとに設定された限度額、申請可能金額及び申請金額に基づいて、支払金額を算出する工程と、支払金額を従業者の口座に振り込むための振込みデータを作成する工程と、を有している。

また、本実施形態の給与受取システム１で実行されるプログラムは、コンピュータを、従業者から申請金額を含む給与受取の申請を受け付ける手段と、従業者の労働時間の累計データ、給与単価及び既に支払った金額に基づいて従業者の給与受取の申請可能金額を算出する手段と、雇用者ごとに設定された限度額、申請可能金額及び申請金額に基づいて、支払金額を算出する手段と、支払金額を従業者の口座に振り込むための振込みデータを作成する手段として機能させるためのプログラムである。

したがって、従業者が給与に基づく所定の支払金額を、必要なときに手軽に受け取ることができ、しかも雇用者側の金銭的、作業的な負担を低減して、より使い勝手のよい給与受取システム１、給与受取方法、及びプログラムを提供することができる。

また、申請可能金額算出部１０３は、従業者の雇用区分に応じて設定された勤怠サイクルの開始日から給与受取の申請日までの労働時間の累計データに雇用区分に応じて設定された給与単価を乗算し、得られた金額に雇用区分に応じて設定された前払上限率を乗算し、得られた金額から既に支払った金額を減算して申請可能金額を算出している。この構成により、従業者の過度な給与の受取りを抑制して、例えば、税金や保険料などの控除額を天引きできる金額を確保しておくことができる。

また、本実施形態では、支払金額算出部１０４は、申請金額が申請可能金額以下である場合は、当該申請金額を支払金額とし、申請金額が申請可能金額を超過する場合は、申請可能金額を支払金額としている。この構成により、従業者は少なくとも申請可能金額分は給与を受取ることができる。さらに、支払金額と、従業者が所属する雇用者全体で既に利用した合計金額との加算額が、想定立替金額（限度額）を超過する場合は、アラート表示（警告）している。よって、当該雇用者全体での給与の受取金額が想定立替金額（限度額）に達したことを知ることができる。

また、想定立替金額（限度額）は、雇用者の従業者数に、所定の利用率と、所定の利用単価とを乗算した金額としている。そのため、雇用者ごとに、その業種、企業の規模や経営状態や実績に応じて、さらにはホストでの過去の経験等を考慮して、利用率や利用単価を自由に設定することができ、利便性を向上させることができる。

また、振込データテーブル作成部１０５は、複数の口座データの中から、従業者に指定された口座データを振込テーブルＴ６に設定している。そのため、従業者は、給与支払口座だけでなく、受取った給与の使用目的などに応じて、所望の口座へ振込みを指定することができる。その結果、例えば、給与支払口座から他の口座へ振り替える手間や、振替手数料が発生することなどを防ぐことができる。

また、リクエスト処理部１０２は、従業者からの利用履歴の表示申請に応じて、申請金額、申請日、振込日を含む申請データを従業員端末３０の表示部２７に表示して従業者に提示するとともに、従業者から給与受取の取消申請を受け付けるように構成されている。そして、振込テーブル作成部１０５は、申請取消がされていない給与受取の申請に対して、振込テーブルＴ６を作成するように構成されている。そのため、従業者は、給与受取の履歴を自由に閲覧して、前払いを申請するか否かを決めたり、今後の家計プランの参考にしたりすることができる。また、申請を取消すことで、給与の受取り過ぎなどを防止することもできる。

また、天引きデータテーブル作成部１０６が、従業者の勤怠サイクル開始から、勤怠サイクル締日よりも所定日数前の天引きデータ締日までに振り込まれた申請金額の合計金額を算出している。この合計金額は、速やかに雇用者に提供される。そのため、雇用者が、給与から天引きするための各従業者の給与受取の総額を、給与計算の前に知ることができ、給与計算に係る処理を円滑かつ迅速に行うことができる。

また、リクエスト処理部１０２は、天引きデータ締日から勤怠サイクル締日までの間は、従業者の給与受取の申請を受付けないようにしている。これにより、申請金額の合計金額を給与から天引きして給与計算を完了した後に、天引きすべき金額が発生することがなく、振込給与の再計算の手間や、次月に持ち越して天引きする手間などを省き、雇用者の負担をより軽減することができる。

以上、本発明の実施形態を図面により詳述してきたが、上記各実施形態は本発明の例示にしか過ぎないものであり、本発明は上記各実施形態の構成にのみ限定されるものではない。本発明の要旨を逸脱しない範囲の設計の変更等があっても、本発明に含まれることは勿論である。

例えば、上記実施形態では、ホストが給与を立て替えて従業員に支払っている。すなわち、ホストの口座から従業員の口座に給与を振込んでいる。しかし、ホストによる立替えに限定されることはなく、雇用者の口座から従業員の口座に振込むシステムとすることもできる。この場合、企業テーブルＴ１に、雇用者の引き落とし口座を記憶しておき、振込テーブルＴ６を作成するときに、「振込元」に雇用者の口座に関するデータを記憶する。これにより、ホストが雇用者に立替金額の支払いを請求したり、立替金額を雇用者の口座から引き落としたりする手間を省くことができる。

また、他の異なる実施形態として、従業者から申請金額を含む給与受取の申請を受け付ける申請処理部と、従業者の労働時間の累計データ、前記従業者の雇用区分に応じて設定された給与単価及び既に支払った金額に基づいて従業者の給与受取の申請可能金額を算出する申請可能金額算出部と、申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出部と、支払金額及び従業者の口座データを含む振込みデータを作成する振込データ作成部と、を備えた給与前払システムとすることもできる。

このような給与受取システムでは、従業者が給与に基づく所定の支払金額を、必要なときに手軽に受け取ることができ、しかも雇用者側の金銭的、作業的な負担を低減して、より使い勝手のよい給与受取システムを提供することができる。さらに、雇用区分に応じて、給与単価などを設定できるため多様な雇用形態を有する雇用者の要求に応じた給与受取システムを提供することができる。この給与受取システムの場合、従業者が前払いで受取る金額を、ホストが立て替えて支払い、後に雇用者に請求する態様とすることもできるし、雇用者の口座から直接に引き落とす態様とすることもでき、振込元は問わない。

さらに異なる実施形態の給与受取システムとして、従業者から申請金額を含む給与受取の申請を受け付ける申請処理部と、従業者の労働時間の累計データ、従業者の雇用区分に応じて設定された給与単価及び既に支払った金額に基づいて従業者の給与受取の申請可能金額を算出する申請可能金額算出部と、雇用者ごとに設定された限度額、申請可能金額及び申請金額に基づいて、支払金額を算出する支払金額算出部と、支払金額及び従業者の口座データを含む振込みデータを作成する振込データ作成部と、を備え、従業者の給与の少なくとも一部を、雇用者に代わって立て替えて支払うものであってもよい。

このような給与受取システムでは、従業者が給与に基づく所定の支払金額を、必要なときに手軽に受け取ることができ、しかも雇用者側の金銭的、作業的な負担を低減して、より使い勝手のよい給与受取システムを提供することができる。さらに、雇用区分に応じて、給与単価などを設定できるため多様な雇用形態を有する雇用者の要求に応じることができるとともに、雇用者の口座にまとまった金額を確保しておく必要がなく、雇用者の負担を軽減することができる。

１ 給与受取システム １０ 給与受取装置 １００ 制御部
１０２ リクエスト処理部（申請処理部） １０３ 申請可能金額算出部
１０４ 支払金額算出部 １０５ 振込テーブル作成部（振込データ作成部）
１０６ 天引きデータテーブル作成部（天引きデータ作成部）

Claims (12)

1. 従業者が有する情報端末と、前記情報端末とネットワークを介して接続されて給与受取サービスの提供元に設置される給与受取装置と、を備え、
   前記給与受取装置が、
   前記情報端末から申請金額を含む給与受取の申請を受け付ける申請処理部と、
   前記従業者の労働時間の累計データ、給与単価及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出部と、
   雇用者の従業者数に前記雇用者ごとに設定された給与受取サービスの利用率及び利用単価を乗算して得られた限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出部と、
   前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成部と、を備え、
   前記従業者の給与の少なくとも一部を、前記雇用者に代わって立て替えて支払うことを特徴とする給与受取システム。
2. 従業者が有する情報端末と、前記情報端末とネットワークを介して接続されて給与受取サービスの提供元に設置される給与受取装置と、を備え、
   前記給与受取装置が、
   前記情報端末から申請金額を含む給与受取の申請を受け付ける申請処理部と、
   前記従業者の労働時間の累計データ、前記従業者の雇用区分に応じて設定された給与単価、前記雇用区分に応じて設定された前払上限率及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出部と、
   前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出部と、
   前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成部と、を備えたことを特徴とする給与受取システム。
3. 従業者が有する情報端末と、前記情報端末とネットワークを介して接続されて給与受取サービスの提供元に設置される給与受取装置と、を備え、
   前記給与受取装置が、
   前記情報端末から申請金額を含む給与受取の申請を受け付ける申請処理部と、
   前記従業者の労働時間の累計データ、前記従業者の雇用区分に応じて設定された給与単価、前記雇用区分に応じて設定された前払上限率及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出部と、
   雇用者の従業者数に前記雇用者ごとに設定された給与受取サービスの利用率及び利用単価を乗算して得られた限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出部と、
   前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成部と、を備え、
   前記従業者の給与の少なくとも一部を、前記雇用者に代わって立て替えて支払うことを特徴とする給与受取システム。
4. 前記申請可能金額算出部は、前記雇用区分に応じて設定された勤怠サイクルの開始日から前記給与受取の申請日までの労働時間の累計データに前記雇用区分に応じて設定された給与単価を乗算し、得られた金額に前記雇用区分に応じて設定された前記前払上限率を乗算し、得られた金額から既に支払った金額を減算して前記申請可能金額を算出することを特徴とする請求項２又は３に記載の給与受取システム。
5. 前記支払金額算出部は、前記申請金額が前記申請可能金額以下である場合は、当該申請金額を前記支払金額とし、前記申請金額が前記申請可能金額を超過する場合は、前記申請可能金額を前記支払金額とし、前記支払金額と、前記従業者が所属する前記雇用者全体で既に利用した合計金額との加算額が、前記限度額を超過する場合は、当該雇用者の立替合計金額が前記限度額を超過したと警告することを特徴とする請求項１又は３に記載の給与受取システム。
6. 前記限度額の算出に用いる前記利用率及び前記利用単価は、前記雇用者の業種、規模、経営状態、実績、過去の経験又はその他に基づいて前記給与受取サービスの提供元によって予め決められていることを特徴とする請求項１、３、５のいずれか一項に記載の給与受取システム。
7. 前記振込データ作成部は、複数の口座データの中から、前記従業者に指定された前記口座データを前記振込みデータに設定するように構成され、前記申請処理部は、前記情報端末からの複数の前記口座データの確認、登録、更新又は削除の指示を受付け、当該指示に基づいて、前記口座データの提示、登録、更新又は削除を実行するように構成されたことを特徴とする請求項１〜６のいずれか一項に記載の給与受取システム。
8. 前記申請処理部は、前記従業者からの利用履歴の表示申請に応じて、前記申請金額、申請日、振込日を含む申請データを前記従業者に提示するとともに、前記従業者から前記給与受取の取消申請を受け付けるように構成され、
   前記振込データ作成部は、申請取消がされていない給与受取の申請に対して、前記振込みデータを作成するように構成されたことを特徴とする請求項１〜７のいずれか一項に記載の給与受取システム。
9. 前記従業者の勤怠サイクル開始から、勤怠サイクル締日よりも所定日数前の天引きデータ締日までに振り込まれた前記申請金額の合計金額を算出する天引きデータ作成部を備えたことを特徴とする請求項１〜８のいずれか一項に記載の給与受取システム。
10. 前記申請処理部は、前記天引きデータ締日から勤怠サイクル締日までの間は、前記従業者の給与受取の申請を受付けないように構成されたことを特徴とする請求項９に記載の給与受取システム。
11. 従業者が有する情報端末と、前記情報端末とネットワークを介して接続されて給与受取サービスの提供元に設置される給与受取装置と、を備えた給与受取システムで行われる給与受取方法であって、
    前記給与受取装置が、
    前記情報端末から申請金額を含む給与受取の申請を受け付ける申請処理工程と、
    前記従業者の労働時間の累計データ、前記従業者の雇用区分に応じて設定された給与単価、前記雇用区分に応じて設定された前払上限率及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出工程と、
    雇用者の従業者数に前記雇用者ごとに設定された給与受取サービスの利用率及び利用単価を乗算して得られた限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出工程と、
    前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成工程と、を行うことで、
    前記従業者の給与の少なくとも一部を、前記雇用者に代わって立て替えて支払うことを特徴とする給与受取方法。
12. コンピュータを、
    従業者から申請金額を含む給与受取の申請を受け付ける申請処理手段、
    前記従業者の労働時間の累計データ、前記従業者の雇用区分に応じて設定された給与単価、前記雇用区分に応じて設定された前払上限率及び既に支払った金額に基づいて前記従業者の給与受取の申請可能金額を算出する申請可能金額算出手段、
    雇用者の従業者数に前記雇用者ごとに設定された給与受取サービスの利用率及び利用単価を乗算して得られた限度額、前記申請可能金額及び前記申請金額に基づいて、支払金額を算出する支払金額算出手段、
    前記支払金額及び前記従業者の口座データを含む振込みデータを作成する振込データ作成手段として機能させるためのプログラム。