JP7437594B1 - 決済システム - Google Patents

決済システム Download PDF

Info

Publication number
JP7437594B1
JP7437594B1 JP2023063036A JP2023063036A JP7437594B1 JP 7437594 B1 JP7437594 B1 JP 7437594B1 JP 2023063036 A JP2023063036 A JP 2023063036A JP 2023063036 A JP2023063036 A JP 2023063036A JP 7437594 B1 JP7437594 B1 JP 7437594B1
Authority
JP
Japan
Prior art keywords
payment
employee
payment method
employees
information
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2023063036A
Other languages
English (en)
Other versions
JP2024149263A (ja
Inventor
泰夫 西澤
Original Assignee
エヌ・エス・システム株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by エヌ・エス・システム株式会社 filed Critical エヌ・エス・システム株式会社
Priority to JP2023063036A priority Critical patent/JP7437594B1/ja
Application granted granted Critical
Publication of JP7437594B1 publication Critical patent/JP7437594B1/ja
Publication of JP2024149263A publication Critical patent/JP2024149263A/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

【課題】多種多様な従業員の雇用カテゴリーに応じて、一つの企業内における食堂や売店での決済方法が設定可能な決済システムを提供すること。【解決手段】各従業員が、QRコードを食堂等に設置されたレジ等に提示すると、決済手段が、DBからその従業員の決済方法を取得し、当該決済方法により購入した商品等の決済を行うよう制御する。各従業員の決済方法は、雇用カテゴリーに応じて設定される。クラウド人事データベースと連携した共通の決済手段を用いることで、企業内の食堂や売店などの共有の場所において、多様な雇用カテゴリーに関わらず全従業員が同一の決済手段により決済を行うことが可能となる。全従業員が同一の決済手段を用いて決済を行った購買行動のデータは企業内で全て緻密に把握し保存することができる為、データの保管や応用等のデータの利活用を自由自在に行うことが可能であり、データ価値を高めることができる。【選択図】図2

Description

本発明は、多様化した従業員に適応した食堂等に用いられる決済システムに関する。本発明は、ある一つの企業などの組織において働く人々の働き方が多様化する状況において、そうした組織内での食堂や売店などの共用の場所において、多様化する従業員の複数種類の雇用形態にも関わらず、その組織内だけで通用するように特別に工夫して創造され準備された決済手段を共通して用いることで、買い物やサービスを受けることができることを可能にする決済システムに関する発明である。
ある一つの企業などの組織における食堂や売店などの共有の場所で使える決済手段としては、次のものが知られていて広く使われている。
[1-1]現金決済
POSレジで有人にて対応するものが長年用いられている。
[1-2]電子マネー (交通系、流通系など)
POSレジで電子マネーのリーダーがあり、ここに電子マネーをかざすことで自動的に決済される仕組みを用いている。
[1-3]電子マネー(スマホでのQR決済タイプ)
POSレジでQRコード(登録商標)を読み取るリーダーがあり、ここにスマホ上のQR決済専用のアプリをかざすことで、QRコードと連動して決済される電子マネーを用いた決済システムがある。
[1-4]クレジットカード決済
POSレジにクレジットカード決済のリーダーがあり、ここにクレジットカードを差し込むことによってクレジットカードセンターと与信に関する承認を経た後に決済される仕組みがある。
上記の決済手段は、有人と無人のものの双方があり、最近は無人の決済の仕組みが普及しつつある。
上記の決済手段は、企業などの一つの限られた組織内でのみ使われるものではなく、そうした組織の外でも広く世間一般の店や、交通施設や、サービス施設などのリアルの場面のみならず、インターネットショップなどのECサイト等でも幅広く利用される決済手段である。
また、上記に決済手段に加えて、企業などの一つの限られた組織内でのみ利用できる決済手段があり、例えば、次のものがある。
[1-5]券売機
特に企業の食堂等の空間での売買行為には、券売機での精算が頻繁に行われている。
[1-6]独自ICカード決済
ある企業内でのみ使えるIC決済カードが用いられることも多い。多くの場合、ICチャージ機という機械があり、この機械を用いてこのICカードに現金価値を事前にチャージすることが必要である。
[1-7]社員証での決済
ある企業内でのみ使える社員証で、企業内にある食堂や売店といった色々な場所で決済できるケースが多くある。社員証をリーダーにかざすことで決済でき、月末に給与からの引落し、いわゆる給与控除を可能とする仕組みである。
これらの決済システムが企業などの特定の組織における食堂や売店といった共通の場所で、広く一般的に用いられている。
こうした決済手段の多様性と共に、企業のような一つの組織体においては、その企業で働き、仕事に従事する人間(従業員)が年々、多様性を深めていく傾向がある。即ち、一つの企業では、次のような多様な種類、多様な雇用形態に属する人間(従業員)が、一つの物理的なオフィスや工場等の職場で働くことが増えている。
以下のような、多種多様な雇用形態の従業員が、企業などの組織において同時に同じオフィスや工場などの空間で一緒に協調して働くことが一般的となっており、今後こうした多様性はより一層発展することが予見されている。
[2-1]正社員
[2-2]契約社員 (例えば、1年ごとの雇用契約に基づく社員)
[2-3]パート (時間給等による雇用)
[2-4]派遣社員 (派遣会社から派遣)
[2-5]出向社員(短期間)
[2-6]出向社員(長期間)
[2-7]子会社社員
子会社のステイタスのまま、物理的に親会社等の職場で働くケース。出役という呼び方もある。
[2-8]下請けからの社員
下請会社の社員のステイタスのまま、物理的に親会社等の職場で働くケース。出役という呼び方もある。
[2-9]グループ会社社員
親会社でも子会社でもないが、兄弟会社とも言うべきグループ会社の社員がそのままのステイタスで、当該会社のオフィスで働くケース。
[2-10]外資の親会社社員
親会社が外資系の場合で、その日本法人において、親会社のステイタスのまま働くケース。
[2-11]出張者
上記の[2-9]以外にも、グローバルな企業において、グループ会社から出張者として当該会社のオフィスでケース。
こうした非常に複雑な多種多様な雇用形態の従業員が、一つの組織で働き、かつ企業等では、ある一つのオフィスや工場などの職場で物理的に同時に協力して働くケースが増えている。このようにまさに社員のステイタスは益々複雑に「多様化」しており、こうした大きな多様性を持つ従業員たちを包摂する形で職場を運営して、組織としての企業を運営しているケースが増えている。
このように、多様性を持つ従業員が共通して利用する社員食堂や売店での決済は、そうした従業員の多様性に適切に対応した形で設計され、運営される必要がある。なお、本明細書では、上述した従業員の多種多様な雇用形態を、例えば、上記の[2-1]から[2-11]のような形態に分類し、このように分類された雇用形態を「雇用カテゴリー」と称することとする。もちろん、上述の雇用形態は一例に過ぎず、他にも様々な雇用形態が存在しうるため、それぞれ実際の雇用形態に基づいて雇用カテゴリーが設定されることになる。
また、「雇用カテゴリー」は、上記のような雇用形態にかぎらず、例えば、従業員の会社、部署、役職、勤続年数、勤務地、通勤距離、住所等、従業員の様々な属性を加えた要素によって分類可能である。また、上述した多種多様な雇用形態や他の従業員属性等は、より小さな概念、またはより大きな概念で分類し、当該概念により分類された雇用カテゴリーを構築することもできる。またさらに、上記の[2-1]から[2-11]のような雇用形態や他の従業員属性等を、別の観点で異なる分類に再編して、その分類に応じた雇用カテゴリーを形成することもできる。
下記の特許文献1には、商品に付与されたICタグに記憶された商品情報をICタグリーダーで読み取り、読み取り結果に応じて、電子マネーでの自動決済を行う自動決済装置が開示されている。
特開2011-186698号公報
しかしながら、上述した特許文献1の自動決済装置をはじめとする従来の決済システムには、それぞれの決済手段について、次のような問題点がある。
[3-1]現金決済
現金は非常に衛生上、問題がある。特に新型コロナウィルスによるパンデミックで世界中が被害を被った後、紙幣やコインでの現金決済が衛生上、汚いと言わざるを得ず、これによる決済を企業などの組織内部での食堂や売店で使うことを忌避すべき流れが鮮明となっている。また、大勢の従業員がある限定された時間帯で食堂や売店で集中して売買する際に、現金決済を行うことは、一件ずつの処理時間が長く非常に非効率であり、処理速度がより速い決済手段が求められている。有人のレジでの現金決済は通常、処理速度が電子マネー等に比べて極めて遅い為、行列ができる傾向があり、例えば食堂においては人が多く並ぶ行列ができる傾向が大きく、非効率であるうえ、人の滞留の密度が濃くなり感染症対策等では、極めて不衛生な状態となる。また待ち時間が長くなる傾向にあり、企業等の生産性の観点から非常に非効率な決済方法と言える。
[3-2]電子マネー(交通系、流通系など)
電子マネーは上記[3-1]の問題に関しては、衛生上問題ある現金を扱わないという点および、非接触での決済処理となる為、処理速度は極めて速くなる為、その点では問題解決になっている。しかし、一つの組織において電子マネーだけでの決済を強いることになると、電子マネーはほぼ事前にチャージしていないと決済が可能とならない為、事前の資金負担を強いることになる。さらには、従業員のうち正社員と非正規社員がいる場合において、正社員は社員証で決済できるが、非正規社員は社員証ではなく電子マネーでの決済にするというように社員の雇用カテゴリーにおいて、使える決済手段をも区別した場合においては、正社員は後払い決済で処理するのに対して、非正規社員には事前に資金負担を強いて、事前に電子マネーにチャージしてから食堂や売店での決済をせざるを得ないという差が生じることになり、非正規社員には不平等な決済を強いることになる。つまり、正社員は事前チャージしなくて決済できるのに、非正規社員は逆に事前チャージが必要な決済をしないといけないという不平等な立場に置かれていることになる。
さらに、電子マネーは決済データが全て電子マネー事業者にダイレクトにいくことから、食堂や売店の運営者、さらにはそうした食堂や売店を包摂している企業などの一つの組織体がそうした決済データを入手することは不可能となる。たとえば、企業においては従業員が食堂や売店で何を購入しているかというデータを時系列的にとったり、そうしたデータをさらに加工して2次利用したり、経営に活かしたりすることが不可能となるという問題がある。これから将来にわたり、データをとって有効活用することは企業のような組織体では非常に重要となることから、こうしたデータをとることができないことは今後さらにデータが価値を持つ時代においては問題であるといえる。
[3-3]電子マネー(スマホでのQR決済タイプ)
この決済手段も近年スマホが普及して、ほぼ全ての従業員が持っていることから、スマホでQR決済を行うことは、従業員への利便性を提供することに繋がっているが、しかし、上記[3-2]と同様に、全く同じ問題を本質的に内包しているといえる。しかも、近年スマートフォン(スマホ)は非常に発展しており、高精度のカメラや通信機能を持つことから、企業内への持ち込みを限定する動き、あるいは禁止する動きもあり、そうした場合、企業内における食堂や売店という場所で、スマホを基本とした決済手段のみを主たる決済手段として用意することは、実際に利用する従業員にとっては不便ということになる。
[3-4]クレジットカード決済
もし、正社員は社員証での給与引落を行う一方、非正規社員はクレジットカードでの決済を行わないといけないという差別化を行った場合は、どちらも後払いという点では、事前チャージを必要とする電子マネーよりは良いともいえる。しかし、通常クレジットカードによる決済では、クレジットカードの与信状態を決済の都度、承認するプロセスが必要となることから、決済処理にかかる処理スピードは明らかに社員証や通常のICカードよりも遅いという欠点を持っている。従って、たとえば企業内の食堂や売店などにおいて、正社員が社員証で購買や喫食できるのに対して、非正規社員はクレジットカードでの決済ということになった場合は、前者がスピード速い決済を利用できるのに対して、後者はスピードの遅いクレジットカードでの決済で我慢せざるをえず、その点ではやはり差別化があると言わざるを得ない。
さらに、クレジットカード決済においても、電子マネー決済と同様に、決済データが全てクレジットカード決済事業者にダイレクトにいくことから、食堂や売店の運営者、さらにはそうした食堂や売店を包摂している企業などの一つの組織体がそうした決済データを入手することは不可能となる。たとえば、企業においては従業員が食堂や売店で何を購入しているかというデータを時系列的にとったり、そうしたデータをさらに加工して2次利用したり、経営に活かしたりすることが不可能となるという問題がある。これから将来にわたり、データをとって有効活用することは企業のような組織体では非常に重要となることから、こうしたデータをとることができないことは今後さらにデータが価値を持つ時代においては問題であるといえる。
[3-5]券売機
券売機は、現金を用いて券を買うので、有人レジで必要なレジ打ちの人間が不要で済むというメリットはあるが、券売機にたまる現金を毎日処理しないといけない。つまり、例えば日本の場合では毎日午後3時までに券売機にたまった現金を取引銀行に持ち込まないといけないという業務が日々発生する。これは非常に面倒くさく前時代的な業務が必要ということを意味している。また、こうした券売機では非常に多くの現金を処理しないといけないこと、発券するという物理的な処理が都度必要であることから、故障やトラブルが頻繁にあるという現状がある。
[3-6]独自ICカード決済
その企業内だけで試用できる独自のICカードを用意して、企業内の食堂や売店等で従業員がそのICカードで決済できる仕組みは広く用いられている。ところが、このICカードは、ICチャージ機という専用の機械に行き、現金を同チャージ機に投入してICカードに現金価値をチャージしないといけない。そうすることで初めてこのICカードは価値を持ち、その価値をもって食堂や売店で購買やサービスに対する価値に対して支払いを実行する、即ち決済することで利用することができる。しかし、[3-5]の券売機で説明したように、日々にICチャージ機にたまる現金を日々に処理する必要があるが、これは日々大変な労力を必要として非常に手間がかかる。また、ICチャージ機で非常に多くの現金を処理しないといけないことから、故障や紙幣が詰まるなどのトラブルや故障が頻繁にあるという現状がある。
[3-7]社員証での決済
企業等の特定の組織では、企業や組織に所属する従業員だけが使える社員証を用いて、社員食堂や売店での決済を行える仕組みを用意することが多い。社員証で決済を行い、給与から引き落とす(給与控除)する仕組みである。給与が月末に支払われえる場合、実質的に後払いでの決済サービスを従業員に提供していることになる。
この場合、現金を扱うことがなくなり、上述した[3-5]、[3-6]での問題点はなくなる。また、電子マネーでの事前のチャージもなくて済むようになる。さらにクレジットカードにおける処理の遅さという問題なに対しても、対応できることになる。しかし、上述したように、企業などの一つの組織で働く従業員は非常に多種多様な雇用カテゴリーの従業員で構成されており、社員証での決済は、この雇用カテゴリーの内、正社員のみとする場合も多い。あるいは一部の契約社員などにも正社員と同様に社員証を用いた決済を許容する場合もあるが、現状においては、正社員のような正規社員のみ社員証での決済を許容し、それ以外の非正規社員については、社員証での決済による後払いを特に認めていないというケースが多く、非正規社員は現金決済や、電子マネーでの決済というように決済手段を差別化するケースが多くある。これは今後さらに一層、企業などの組織内で進んでいくと思われる複雑で多様化していく雇用カテゴリーに対して、正社員とそれ以外の非正規社員の間の差別的な取扱いが継続されるという問題を抱えていくことを意味している。
本発明は、上記のような点に鑑みてなされたものであり、多種多様な従業員の雇用カテゴリーに応じて、一つの組織における食堂や売店での決済方法が設定可能な決済システムを提供することを目的とする。
また、本発明の目的は、例えば、正社員、非正規社員といった異なる雇用カテゴリーの従業員に対して、双方とも、同じ概念の決済方法で(例えば、後払い決済といった特定の決済方法で)決済を行うことが可能な決済システムを提供することにある。
また、本発明の目的は、支払いや事前チャージ等において現金を扱わずに決済が可能であり、さらに、クレジットカードや既存の電子マネー等を直接的に用いずに決済が可能な決済システムを提供することにある。
上記目的を達成するため、本発明は、以下の決済システムを提供する。
本発明の第1の実施態様に係る発明は、下記の構成を有する。
商品等(例えば、料理や物品のほか、従業員に対する役務(サービス)も含む)を購入するために従業員が提供した従業員情報(例えば、従業員ID)を受け付ける受付手段(例えば、図3に示す受付手段11)と、
前記商品等の金額と、前記従業員情報とに基づいた決済を行う決済手段(例えば、図3に示す決済手段12)と、
前記従業員情報に対応付けて決済方法を記憶する決済方法記憶手段(例えば、図4(B)に示す決済方法記憶手段13)と、を備え、
前記決済手段は、前記決済方法記憶手段を参照して前記従業員情報に対応する決済方法を把握し、前記把握した決済方法を用いて、前記商品等の金額の決済を行い、
前記決済方法は、前記従業員情報に対応する従業員が属する雇用カテゴリー(例えば、図4(A)に示す人事データベースに記憶される雇用カテゴリーであって、各従業員の雇用形態等に基づいて決定され当該従業員に対応付けられる分類)に応じて設定されることを特徴とする決済システム(例えば、決済システム1や決済システム1’)。
本発明の第2の実施態様に係る発明は、第1の実施態様において下記の構成を有する。
前記決済方法として、従業員が購入する前記商品等に係る当該従業員による支払いを、前記商品等の決済後に行う、後払い決済を設定することが可能であり(例えば、正社員では、給与控除、非正規社員では一括銀行引落)、
前記決済手段は、把握した決済方法が前記後払い決済である場合、前記受付手段が、前記商品等を前記従業員に提供することが可能な提供可能状態(例えば、決済完了のメッセージを表示し、レシートを発行した状態)となるように制御する。
本発明の第3の実施態様に係る発明は、第2の実施態様において下記の構成を有する。
前記決済方法として前記後払い決済が設定されている場合、決済方法ごと、雇用カテゴリーごと、または個別の従業員ごとに、所定期間において購入可能な商品等の合計金額の上限を設定可能であり(例えば、図4(A)の人事データベースや図4(B)の決済方法記憶手段13に上限金額が記憶される)、
前記決済手段は、把握した決済方法が前記後払い決済である場合であって、購入する前記商品等の金額によって前記合計金額が前記上限を超える場合は、前記受付手段が、前記商品等を前記従業員に提供することができない提供不能状態となるように制御する(上限エラーのメッセージを表示した状態)。
本発明の第4の実施態様に係る発明は、第1の実施態様において下記の構成を有する。
第1雇用カテゴリーに属する従業員(例えば、正社員)に対して第1決済方法(例えば、給与控除を行う後払い決済)を設定可能とし、かつ、第2雇用カテゴリーに属する従業員(例えば、非正規社員)に対して第2決済方法(例えば、銀行引落を行う後払い決済)を設定可能とするように構成され、
前記第1決済方法と前記第2決済方法はいずれも、従業員が購入する前記商品等に係る当該従業員による支払いを、前記商品等の決済後に行う、後払い決済であり、
前記決済手段は、
把握した決済方法が前記第1決済方法である場合に、前記第1雇用カテゴリーに属する従業員が購入する前記商品等について、前記第1決済方法による後払い決済を行う(例えば、給与支払いのタイミングで給与控除を行う)よう制御し、
把握した決済方法が前記第2決済方法である場合に、前記第2雇用カテゴリーに属する従業員が購入する前記商品等について、前記第1決済方法とは異なる前記第2決済方法による後払い決済を行う(例えば、所定のタイミングで従業員の銀行口座から一括で引落を行う)よう制御する。
本発明の第5の実施態様に係る発明は、第4の実施態様において下記の構成を有する。
前記第1決済方法による後払い決済は、前記従業員に給与が支払われる場合に、購入した商品等の金額に基づく額を当該給与から差し引く決済方法であり、
前記第2決済方法による後払い決済は、購入した商品等の金額に基づく額を、前記第2決済方法において設定された支払い方法で支払う(例えば、月末等のタイミングで銀行口座から引き落とされる、または、発行された請求書に基づいて金融機関で支払う等)決済方法である。
本発明の第6の実施態様に係る発明は、第1の実施態様において下記の構成を有する。
前記雇用カテゴリーごとに、対応する決済方法の候補をそれぞれ提示可能であり、
前記従業員は、自身の雇用カテゴリーに応じて提示された決済方法の候補のなかから、一の決済方法を選択し設定することができる(例えば、図7~図9に示した、決済システム1’の構成)。
本発明の第7の実施態様に係る発明は、第1の実施態様において下記の構成を有する。
更に、前記商品等の購入に係る購入情報を記憶する購入情報記憶手段(例えば、図4(C)の購入履歴テーブル)と、
前記従業員のコンピュータ装置からの要求に応じて、前記購入情報記憶手段に記憶されている購入情報に基づく情報を、前記コンピュータ装置に提供する情報提供手段と、を備え、
前記購入情報に基づく情報には、前記従業員が食堂で購入した商品の購入履歴に基づく喫食履歴、または前記従業員が売店で購入した商品の購入履歴に基づく物品購買履歴が含まれる。
本発明の第8の実施態様に係る発明は、第1の実施態様において下記の構成を有する。
更に、前記商品等の購入に係る購入情報を記憶する購入情報記憶手段(例えば、図4(C)の購入履歴テーブル)と、
所定のコンピュータ装置(例えば、従業員を雇用する組織のコンピュータ)からの要求に応じて、前記購入情報記憶手段に記憶されている購入情報に基づく情報を、前記コンピュータ装置に提供する情報提供手段と、を備え、
前記情報提供手段は、前記コンピュータ装置に前記購入情報に基づく情報を提供し、
前記コンピュータ装置に提供される情報は、所定のアプリケーションによる編集が可能な形態(例えば、CSV,XML,JSONといったファイル形式)である。
本発明によれば、特定の企業などの組織において、非常に多種多様な雇用カテゴリーからなる従業員が全員同じ一つの決済方法(例えば、QRコード決済)を用いるが、クラウド人事データベースの中に各々の雇用カテゴリー、各々の従業員に適用される決済手段が記録されていることによって、一つの決済方法(例えば、QRコード決済)を用いるのにも関わらず各々の従業員ごとに異なる決済方式が適用されることが可能となる。この点が本発明の核心部分である。
また、本発明によれば、多種多様な従業員の雇用カテゴリーに応じて、一つの企業(組織)における食堂や売店での決済方法を設定することができる。
また、本発明によれば、正社員、非正規社員といった異なる雇用カテゴリーの従業員に対して、双方とも、同じ概念の決済方法で(例えば、QRコードを用いた後払い決済といった特定の決済手段で)決済を行うことが可能となり、当該決済において正社員と非正規社員とが、同様の決済方法をもちいることができ、非正規社員が大きな不利益や不便を被ることがなくなる。
また、本発明の目的は、支払いや事前チャージ等において現金を扱わずに決済が可能となり、さらに、クレジットカードや既存の電子マネーを直接的に用いずに決済が可能となり、結果的に、POSレジ等で迅速な支払処理が可能となり、また、支払いの際の取引データ等を取得することができる。
本発明により、以下に記述するような産業上の利用可能性があり、様々な問題を解決することができる。
現金決済を排除することが可能となる。すなわち、企業や特定の組織内における食堂での喫食や売店の物品購入において、一種類のQRコード決済手段で決済を可能にすることにより、現金での精算を排除することができる。
上述した[3-1]のように、現金は非常に衛生上、問題があり。特に新型コロナウィルスによるパンデミックで世界中が被害を被った後、紙幣やコインでの現金決済が衛生上、汚いと言わざるを得ず、これによる決済を企業などの組織内部での食堂や売店で使うことを忌避すべき流れが鮮明となっている。特に、多数の従業員が飲食を行う食堂においては、現金での決済は衛生上非常に問題であることは明らかで、本発明により現金決済を限られた空間から排除することは、衛生上でも非常に意義がある。
また、大勢の従業員がある限定された時間帯で食堂や売店で集中して売買する際に、現金決済を行うことは、一件ずつの処理時間が長く非常に非効率であり、処理速度がより速い決済手段が求められている。有人のレジでの現金決済は通常、処理速度が電子マネー等に比べて極めて遅い為、行列ができ、例えば食堂においては人が多く並ぶ行列ができる傾向が大きく、非効率であるうえ、人の滞留の密度がこくなり感染症対策等では、極めて不衛生な状態となる。
本発明により、所属する雇用カテゴリーに関わらず全従業員に対して、同一のQRコード決済による決済手段を提供していることは、現金決済に伴う処理速度の遅さという問題を解決することになり、企業、オフィスでの労働生産性が非常に上がることにつながる。
電子マネーは上記の[3-2]の問題に関しては、衛生上問題ある現金を扱わないという点および、非接触での決済処理となる為、処理速度は極めて速くなる為、その点では問題解決になっている。しかし、一つの組織において電子マネーだけでの決済を強いることになると、電子マネーはほぼ事前にチャージしていないとならない為、事前の資金負担を強いることになる。さらには、従業員のうち正社員と非正規社員がいる場合において、正社員は社員証で決済できるが、非正規社員は社員証ではなく電子マネーでの決済として区別した場合においては、正社員は後払いでの決済で処理するのに対して、非正規社員には事前に資金負担を強いて、事前に電子マネーにチャージしてから食堂や売店での決済を強いることになる為、不平等な決済を強いることになる。つまり、正社員は事前チャージしなくて決済できるのに、非正規社員は逆に事前チャージが必要な決済をしないといけないという不平等な立場に置いていることになるが、本発明により企業内で同一の決済手段として一つのQRコード決済手段を用意することは、このような正社員と非正規社員との決済手段の違いを解消しており、飽く迄も食堂や売店といった購買行動における決済手段という限られた範囲ではあるが、雇用カテゴリーに応じた非対称性な取扱いの差があることに対して、正社員、非正規社員という区別をなくした共通の決済インフラを提供することができる。
特に「社員食堂」という場所においては、毎日従業員が生きる活力を得るために食べる場所であり、生きていくうえで欠かせない場所であることから、この場所での決済手段に差がある状態を放置していることは、従業員の毎日食べる機会において、多様化された雇用形態のままに差別的な対応があるという環境を維持しているということになる為、当該企業が本当に真の意味で、働き方において真のDiversification(多様性)や、多様性の包摂(Inclusion)、さらには、働き方において従業員の真の幸せを目指すWell-Beingを心がけている企業なのかどうかが真に問われることになる。逆に言うと、本発明は、働き方において真のDiversification(多様性)や、多様性の包摂(Inclusion)、さらには、働き方において従業員の真の幸せを目指すWell-Beingに資するものであるといえる。
さらに、電子マネーやクレジットカード決済は決済データが全て電子マネー事業者やクレジットカード決済事業者にダイレクトにいくことから、食堂や売店の運営者、さらにはそうした食堂や売店を包摂している企業などの一つの組織体がそうした決済データを入手することは不可能となる。たとえば、企業においては従業員が食堂や売店で何を購入しているかというデータを時系列的にとったり、そうしたデータをさらに加工して2次利用したり、経営に活かしたりすることは不可能となるという問題がある。これから将来にわたり、データをとって有効活用することは企業のような組織体では非常に重要となることから、こうしたデータをとることができないことは非常に問題であるといえる。
しかしながら、本発明においては、独自決済であり、かつクラウド人事データベースにおいて全ての従業員の全ての決済データが記録、格納されることから、各々の従業員が売店で何をいつ購買するか、あるいは社員食堂において何をいつ喫食したかというデータをとることができる。例えば、喫食については、近年従業員の健康について配慮する経営、健康経営や従業員の心身の健康を大切に考えてそれに対して適切な対策をしていくWell-Being(ウェルビーング)の考え方が大切であるという認識が広く普及しつつある。
従業員にとっては一日で主に昼食をとるだけにしか過ぎない社員食堂ではあるものの、しかし、例えば塩分量の多い食事メニューを毎日とると体に影響があることなどから、企業として、どの従業員が何をいつ食べているのかについてデータをとっていくことが大切になっており、企業によってはそうしたデータを取って時系列的に把握する動きもある。
またこうしたデータを取ることは、企業の総務人事部にとって重要ということにとどまらず、従業員自身が自分自身の喫食履歴を把握することも可能とするため、非常に重要になりつつある。電子マネーの場合、たとえばスイカ等の交通系電子マネーで喫食した場合、自分がなにをいつ喫食したかというデータを取ることが簡単にできるようにはなっていない。つまり、スイカ側の提供しているプログラムにおいて、喫食履歴だけに絞った構造になっていないため、結局どこをどのように観れば自分自身がスイカを用いて、当該の社員食堂で何をいつ食べたのかがすぐにわかるような機能になっていない。一方、本発明では、総務人事部がクラウド人事データベースにアクセスすれば、各々の従業員の喫食履歴や購買履歴は一目瞭然であることに加えて、各従業員も自分自身のスマホから当該のクラウド人事データベースにアクセスすることで自分自身の喫食履歴や購買履歴が一目瞭然でわかる。
さらに、同じクラウド人事データベースの中で個々人の喫食履歴に重ね合わせる形で、食堂事業者のメニュー情報を取入れることも可能であり、同事業者の栄養士の介在があった場合、各々の従業員が日々喫食した栄養データを時系列的にとることも可能となる。
電子マネーの場合は、電子マネー事業者には色々なデータがたまるが、例えば社員食堂を設営している企業においても、その人事総務部が当該データを保有することもできないし、各々の企業の従業員が当該データを閲覧することもほぼ不可能ということになっており、将来「健康経営」を重要視した経営を行っていこうとして当該データを有効活用しようと思っても、電子マネー事業者にデータが存在する状態では、当該データの有効活用はできない。当該データの有効活用という意義においても、本発明の寄与する部分は大きい。
上述の[3-4]のように、正社員は社員証での給与引落を行う一方、非正規社員はクレジットカードでの決済を行わないといけないという差別化を行った場合は、どちらも後払いという点では、事前チャージを必要とする電子マネーよりは良いともいえる。しかし、通常クレジットカードによる決済では、クレジットカードの与信状態を決済の都度、承認するプロセスが必要となることから、決済処理にかかる処理スピードは明らかに社員証や通常のICカードよりも遅いという欠点を持っている。従って、たとえば企業内の食堂や売店などにおいて、正社員が社員証で購買や喫食できるのに対して、非正規社員はクレジットカードでの決済ということになった場合は、前者がスピード速い決済を利用できるのに対して、後者はスピードの遅いクレジットカードでの決済で我慢せざるをえず、その点ではやはり差別化があると言わざるを得ない。
かかる状況において、本発明では、正社員と非正規社員の決済が同一の方法で行われえることから、両者に対する差別的な対応はなくなり、両者に共通する決済手段を提供することになり、多様化する雇用形態に関わらない共通の決済インフラを提供できることになる。
また、クレジットカードでも電子マネーと同様に、企業にとっては自社の社員食堂に関することなのにも関わらず、もしもクレジットカード決済で従業員が決済した場合は、喫食履歴等のデータは全てクレジットカード会社のものとなり、企業自身がこうしたデータを保有することは不可能となる。
本発明を用いることで、企業は自社の食堂や売店において自社の従業員が行う購買や喫食に関わるデータを企業自身が保有することができる。今後、健康経営やWell-Beingの取組みを深化していく場合に、企業自らがデータを保有できることは大きな利便性を有することになる。
上述の[3-5]のように、券売機は現金を用いて券を買うので、有人レジで必要な人が不要で済むというメリットはあるが、券売機にたまる現金を毎日処理しないといけない。つまり、日本場合では毎日午後3時までに券売機にたまった現金を取引銀行に持ち込まないといけないという業務が日々発生する。これは面倒くさく前時代的な業務が必要ということを意味している。また、こうした券売機では非常に多くの現金を処理しないといけないこと、発券するという物理的な処理が都度必要であることから、故障やトラブルが頻繁にあるという現状がある。しかるに、本発明の決済手段を用いれば、券売機は不要となり、脱現金化(脱キャッシュ)を実現できる上に、上記の券売機に伴う問題の解決に資する。
上述の[3-6]のように、その企業内だけで試用できる独自のICカードを用意して、企業内の食堂や売店等で従業員がそのICカードで決済できる仕組みは広く用いられている。ところが、このICカードは、ICチャージ機という専用の機械に行き、現金を同チャージ機に投入してICカードに現金価値をチャージしないといけない。そうすることで初めてこのICカードは価値を持ち、その価値をもって食堂や売店で購買やサービスの価値に対して支払いを実行する、即ち決済することで利用することができる。しかし、日々にICチャージ機にたまる現金を日々に処理する必要があるが、これは日々大変な労力を必要として非常に手間がかかる。
また、ICチャージ機で非常に多くの現金を処理しないといけないことから、故障や紙幣が詰まるなどのトラブルや故障が頻繁にあるという現状がある。しかるに本発明においては、事前のチャージが不要となり、原則として全て後払いを実現することが可能となる。事前チャージを不要とすることは非常に画期的であり、従業員は事前に当該のICカードに事前にチャージすることなく、企業内の社員食堂において喫食や売店での購買を享受することができて、これは事前チャージを要するICカードに比べてはるかに利便性を提供するものである。
また、企業によっては、正社員は社員証での後払い決済が可能だが、非正規社員はICカード決済にて支払うというような対応をとっているところが現時点相当に多いが、本発明の決済システムを導入することによって、正社員も非正規社員も社員食堂や企業内の売店で、同じ決済手段で決済できることになり、企業内の複数カテゴリーにわたる多様性に富んだ社員層に対して共通な決済インフラを用意することができる。
上述の[3-7]のように、企業等の特定の組織では、企業や組織に所属する従業員だけが使える社員証を用いて、社員食堂や売店での決済を行える仕組みを用意することが多い。社員証で決済を行い、給与から引き落とす(給与控除)する仕組みである。給与が月末に支払われえる場合、実質的に後払いでの決済サービスを従業員に提供していることになる。
この場合、現金を扱うことがなくなり、上述した[3-5]、[3-6]での問題点はなくなる。また、電子マネーでの事前のチャージもなくて済むようになる。さらにクレジットカードにおける処理の遅さという問題なに対しても、対応できることになる。しかし、上記2で述べたように、企業などの一つの組織で働く従業員は非常に複雑なカテゴリーの従業員で構成されており、社員証での決済は、このカテゴリーの内、正社員のみとする場合も多い。あるいは一部の契約社員などにも正社員と同様に社員証を用いた決済を許容する場合もあるが、現状においては、正社員のみ社員証での決済を許容し、それ以外の非正規社員については、社員証での決済による後払いを特に認めていないというケースが多く、非正規社員は現金決済や、電子マネーでの決済というように決済手段を差別化するケースが多くある。
つまり、多くの企業では、正社員は社員証での後払い決済が可能だが、非正規社員は事前チャージを必要とするICカード決済にて支払うというような対応をとっているところが現時点相当に多いが、本発明の決済システムを導入することによって、正社員も非正規社員も社員食堂や企業内の売店で、同じ決済手段で決済できることになり、企業内の複数カテゴリーにわたる多様性に富んだ社員層に対して共通な決済インフラを用意することができる。
このように本発明は現在の企業内の社員食堂や売店における喫食や購買という行為に対して、企業で益々増える複雑で多様な雇用カテゴリーで働く多くの従業員に対して、共通で便利な決済手段を提供することができる。さらに、本発明を用いることによってはじめて、多くの従業員が行う企業内の社員食堂や売店といった場所での喫食や購買という行為について、そのデータを時々刻々と自在にとることが可能となり、当該データを自由自在に「見える化」することが可能となる。
本発明によって「見える化」されたデータは、企業の人事担当者が自由自在に見ることも可能となり、また上手に加工することで、当該データから価値を引き出すことも可能となる。さらに、この「見える化」されたデータは、従業員が自らクラウドにアクセスすることで、自らのPCやスマホから自由自在に見ることを可能とする。
このような利便性、新規性を有する本発明は、企業で増える多様化する働き方に関わらず、全ての従業員に対して、社内の施設における決済という面において、共通で便利な決済インフラを提供し、決済手段を提供し、データ活用インフラを提供することに繋がっており、広義の働き方改革、多様性の確保・包摂、多様性への配慮につながっているインフラを提供するという意義を持っている。
本発明の決済システムにおけるユーザ登録の流れを示す図である。 本発明の決済システムにおける利用者精算からのデータの流れを示す図である。 本発明の一実施形態に係る決済システムの構成を示すブロック図である。 本発明の一実施形態に係る決済システムで利用されるデータ項目の例を示す図である。 本発明の一実施形態に係る決済システムにおけるスマホの表示画面の例を示す図である。 本発明の一実施形態に係る決済システムにおけるスマホの表示画面の例を示す図である。 本発明の別の実施形態に係る決済システムで利用されるデータ項目の例を示す図である。 本発明の別の実施形態に係る決済システムにおけるスマホの表示画面の例を示す図である。 本発明の別の実施形態に係る決済システムにおけるスマホの表示画面の例を示す図である。
図1、及び図2を参照して、本発明の決済システム(Diversified Payment System)における処理の概要を説明する。
図1は、本発明の決済システムにおける「ユーザ登録の流れ」を示している。ここで、本発明の決済システムのユーザは多種多様な雇用カテゴリーに属する従業員であり、各自スマートフォン(以下、「スマホ」と称する)を有している。各従業員(Empl1~Empl5、・・・)のスマホは、それぞれ、スマホ(スマホ1~スマホ5、・・・)であるが、このようなスマホの代わりに、PC等(パーソナルコンピュータ等)の他のITツールであってもよい。
各従業員(Empl1~Empl5、・・・)は、ある一つの企業で働く従業員であるが、就業の仕方、雇用契約の内容に応じて色々な雇用カテゴリーに分かれて所属していることを想定している。図1の例では、Empl1は正社員とし、Empl2~Empl5は非正規社員とし、例えば、パートや、業務委託契約に基づく他社からの出向社員だったり、嘱託社員だったり色々な雇用カテゴリーに所属することを想定している。
これら従業員(Empl1~Empl5、・・・)は、企業内で自分自身のスマホで、企業や組織内の食堂や売店で物品の購入をしたり喫食したりして、スマホのディスプレイに表示されるQRコードを用いたQRコード決済により精算を行う。スマホを持っていない、もしくはスマホを使えない環境の場合は、当該QRコードをプリンタで紙に印字して、その紙に印字されたQRコードを用いることで、当該企業内部のオフィスや工場等の食堂や売店における喫食や購買において決済を行うことができる。
図1では、各従業員のスマホに対して、例えば、当該企業の人事総務部の管理者(Adm1)からQRコード1が配信されて、これを各人のスマホに各々表示して、各企業での食堂や売店で決済することができる。もしもスマホを持っていない場合や、スマホを企業内で使用不可能な場合においては、当該従業員に対して配信されるQRコード1をプリンタで紙に印字して、この紙に印字されたQRコードを決済時に、例えば、POSレジのコードリーダー等に読み取らせることで決済することが可能となる。
各従業員は自分自身のスマホから、図1に示すような事業者クラウドにアクセスして、決められたルールでログインすることによって、クラウド人事データベースの中のアクセス可能な記憶領域にアクセスすることが許され、そこで、例えば、決済方法の指定を含むユーザ登録を行い、また、自分自身に関するデータや、自分自身が企業内の食堂や売店で喫食したり物品の購入をしたりしたときの決済に関する履歴データ等を見ることができる。
図1には、一企業が本発明の決済システムを導入し、各従業員がユーザ登録を行うまでの手順が示されており、ここでは、それらの手順を順に説明していく。
最初に、例えば、図1に示す一企業が本発明の決済システムの利用を開始する場合、事業者クラウド(すなわち、複数の企業が、インターネット等のネットワークを介してアクセス可能なネットワークリソース)に配置されたクラウド人事データベースを含むデータに関し、その企業に対応付けられた領域やデータが設定され、そこで、その企業の事業所コードが付番される(図1の(1))。
次に、企業の人事総務部の管理者(Adm1)は、企業が有する人事データベースから従業員のデータをクラウド人事データベースに登録し、そのときに、各従業員の雇用カテゴリーを設定する(図1の(2))。
この雇用カテゴリーは、上記のように、例えば、雇用形態(上記の[2-1]から[2-11]のような雇用形態)や、従業員の会社、部署、役職、勤務年数等に基づく分類とすることができる。企業の人事総務部の管理者(Adm1)から事業者クラウドには、例えば、従業員を識別する従業員IDと雇用カテゴリーを識別する雇用カテゴリーIDが送信され、事業者クラウドのクラウド人事データベースには、これらのデータが記憶される。
なお、企業の人事総務部の管理者(Adm1)は、雇用カテゴリーIDではなく、雇用カテゴリーに応じて判定された、その従業員により選択可能な決済方法、または選択可能な決済方法のグループを示すデータを、クラウド人事データベースに送信するようにしてもよい。
また、企業の人事総務部の管理者(Adm1)は、本発明の決済システムの利用を開始する際に、基本的には、その決済システムで食堂や売店を利用する可能性のある従業員全員の設定を行うが、従業員の増減に応じて、クラウド人事データベースから、従業員IDとこれに対応するデータを削除、または追加する必要がある。また、企業の人事総務部の管理者(Adm1)は、従業員の雇用カテゴリーが変化した場合に、クラウド人事データベースの雇用カテゴリーIDを変更する。
次に、企業の人事総務部の管理者(Adm1)は、各従業員にQRコード1を送信する(図1の(3))。
QRコード1は、例えば、メール、特定のスマホ用アプリ(スマホ上で実行されるアプリケーション)、印刷物等、様々な形態で従業員に提供される。また、このときに、例えば、パスワードなども同時に提供される。各従業員は、QRコード1とパスワードを用いて自身のスマホやその他のITツールでWEBアクセスを行うことで、事業者クラウド上の各自の専用ページを表示させることができる(図1の(4))。
また、事業者クラウドにアクセスした従業員には、例えば、アクセスした順にクラウドIDが発行され、このクラウドIDが、クラウド人事データベースにおいて、従業員ID対応付けて記憶される。専用ページは、その従業員にのみ表示される専用のページであり、例えば、QRコード1に組み込まれたURL等の情報によりユニークに指定されていてもよいし、QRコード1に組み込まれた共通のURL情報とパスワードによりユニークに指定されてもよい。
従業員は、表示した専用ページにおいて、食堂や売店を利用した場合の決済方法を指定し、その決済方法に必要な決済情報、及びその他の情報を入力してユーザ登録を行う(図1の(5))。
専用ページでは、クラウド人事データベースに記憶された雇用カテゴリーIDに応じて、対応する決済方法、または決済方法のグループが表示され、従業員は、自身の雇用カテゴリーに応じて表示されているその決済方法から、1つの決済方法を選択し、登録する。従業員に選択された決済方法や、入力された決済情報、その他の情報は、クラウド人事データベースに記憶される。
また、専用ページでは、従業員が食堂や売店で購入した商品等の一覧、決済履歴を閲覧することができ、さらに、食堂で購入した商品に関しては、注文履歴、塩分、カロリー、糖質等、喫食に関する様々な情報を表示させることができる。
このようなユーザ登録は、図1に示すように、正社員、非正規社員の区別なく(雇用カテゴリーに関わらず)、同様の手順で行うことができる。図1では、正社員(Empl1)がスマホ1を用いて、給与控除を行う決済方法を選択し、非正規社員(Empl2)がスマホ2を用いて、それ以外の決済方法を選択している。
また、図1に示すように、雇用カテゴリー1に属する社員(Empl3)がスマホ3を用いて同様の手順でユーザ登録を行い、雇用カテゴリー2に属する社員(Empl4)がスマホ4を用いて同様の手順でユーザ登録を行い、雇用カテゴリー3に属する社員(Empl5)がスマホ5を用いて同様の手順でユーザ登録を行っている。
次に、事業者クラウドから、クラウド人事データベースに記憶された決済方法や決済情報が、従業員IDに対応付けて企業の人事総務部に送信される(図1の(6))。これによって、企業の人事総務部の管理者(Adm1)は、その従業員がどの決済方法を最終的に選択したかを把握することができる。
また、企業の人事総務部の管理者(Adm1)から事業者クラウドに対して、割引サービスやキャンペーンの通知情報が必要に応じて送信される(図1の(7))。割引サービスの通知は、例えば、決済方法として給与控除を選択した従業員に対して所定の割引を行う旨の通知であり、キャンペーン通知は、例えば、特定の決済方法を選択した従業員、または決済方法を選択した(ユーザ登録をした)すべての従業員に対してポイントを付与する旨の通知である。これらの通知は、例えば、ユーザ登録する際の専用ページや、QRコード1を表示させるスマホのアプリの表示画面、QRコード1等を読み取った際のPOSレジの表示画面等に表示される。
図2は、本発明の決済システムにおける「利用者精算からのデータの流れ」を示している。
企業などの組織におけるオフィスや工場などの空間にある食堂や売店を従業員が喫食もしくは物品の購買という形で利用する。その際の支払いに自分自身のスマホの画面に表示されたQRコード1を提示するか、もしくは自分自身に配信されたQRコード1をあらかじめプリンタで紙に印字しておき、この紙に印字されたQRコード1を提示することによって精算を行う。例えば、上述した食堂の食堂精算システムや、売店1の売店精算システム1、売店2の売店精算システム2等のPOSレジといった精算機に接続されたQRコードリーダーに、QRコード1をかざして読み取らせることで決済を行う。
なお、この例では、図1に示した、ユーザ登録のために用いられるQRコード1が、そのまま商品等の精算に用いられるが、ユーザ登録の結果、QRコード1とは別に発行され、スマホの画面に表示可能な(または、紙に印字される)別のQRコード等を用いて当該精算を行うこともできる。
図2に示す食堂精算システム、売店精算システム1、売店精算システム2等は、精算しようとしている従業員がQRコード1による決済を行うにあたり、その資格があるかどうか等をチェックする機能を有する。また、食堂精算システム、売店精算システム1、売店精算システム2等の中には、従業員の与信情報を記録することも可能である。このような与信情報により、決済しようとしている金額と従業員の与信枠を比較して、決済可能かどうかを判断する。決済が可能な場合、以下のプロセスで決済を行うことになるが、不可能と判断された場合は、システムのPOSレジ等の表示部において「決済不可能」あるいは「拒絶」といった表示を行い、それ以降の決済プロセスを行わないように制御する。
食堂精算システム、売店精算システム1、売店精算システム2等を利用し、そこで決済を行った場合(図2の(1))、その決済データをクラウド上のクラウド人事データベースに送信する(図2の(2))。クラウド人事データべースでは、当該従業員が決済を行った金額、対象の購買した品目(喫食した食事)、日付時刻の詳細なデータ等を記録することができる。
例えば、喫食した食事の場合、提携している食堂運営業者等から当該の食事内容の栄養素、カロリー数、塩分量などの多種多様なデータを受信し、記憶している場合には、これらの受信データから把握される、従業員の食事関連データも当該の従業員が喫食した食事内容を裏付けるデータとして格納したり、紐づけたり、参照したりすることが可能であり、当該食事関連データの構成は自在に設計されうる。
同様に、購入する物品に関する多種多様なデータも、必要に応じて格納したり、参照することが可能である。
事業者クラウドのクラウド人事データベースに送信された各従業員の決済データは、例えば、各々の従業員がユーザ登録において設定した決済方法に応じた「決済プログラム」により処理される。なお、各従業員の決済方法が、雇用カテゴリーに1対1に対応している場合は、「決済プログラム」を、各従業員が属している雇用カテゴリーに応じて決定し、起動させることができる。
例えば、決済方法が、雇用カテゴリーに1対1に対応している場合であって、クラウド人事データベースにアクセスすることで、決済を行った従業員の雇用カテゴリーが「正社員」であると判断された場合、正社員である従業員(Empl1)の決済については、雇用カテゴリーが「正社員」である場合に実行される「決済プログラム」が実行される。この場合の決済プログラムは、決済方法=「給与控除」(給与からの天引き)に係る決済処理を実行し、図2の(3)-1のように、従業員(Empl1)が決済を行った従業員ID、決済金額、購入内容等を含む決済データを、給与控除の為に、企業の人事総務部の人事データベース(給与システム)に送信し、そこで、その決済金額を、毎月末の給与処理における給与控除額として利用する。
また、クラウド人事データベースにおいて、当該の決済を行った従業員が、正社員ではなく非正規社員であると判断された場合、各々の従業員が属する雇用カテゴリーに規定されている決済手段に応じて、決済金額、決済内容等を含む決済データを当該の決済処理を実行する事業者へ送信する(図2の(3)―2)。
決済データを受信した事業者は、クラウド人事データベースから渡された各々の従業員の情報(例えば、銀行口座、クレジットカード番号、名義人等)を参照し、そこで、その従業員に関して登録されている決済手段に応じて、当該決済データに基づいた決済処理を行う。
例えば、非正規社員である従業員(Empl2)は、食堂を利用して決済を行っており(図2の(1))、この従業員(Empl2)について、月末に銀行口座から一括で引き落としを行うという決済方法が、クラウド人事データベースに登録されているものとする。この場合、決済方法=「一括銀行引落」に係る決済処理を行う決済プログラムを実行し、事業者に対して決済データを送信し(図2の(3)-2)、これを受信した事業者は、引落代行会社(または銀行)に対して、当該従業員からの委託を受けて当該銀行口座から、決済金額に基づいて求められた所定金額の引落を指示し実行する(図2の(4)-1)。
また、このとき、事業者は、自身の決済代行手数料や、引落代行会社の引落代行手数料等の手数料を企業の人事総務部あてに請求する(図2の(4)-2)。ただし、こうした、委託による後払い決済を実行する事業者等の手数料を、どの組織がどのタイミングで負担するかについては、様々な方法を考えることができ、上述した態様に限定されるものではない。
また、上記のような、「一括銀行引落」の決済方法等が設定されている場合、食堂や売店での決済が完了してから、月末に銀行口座から決済金額の引き落としがあるまで、基本的には回収リスクが生じていることになる。この例では、このような回収リスクは、直接的には、引落代行会社や事業者が負担し、最終的には、企業側が負担するものとしている。例えば、従業員の銀行口座からの引き落としが不能であった場合に、当該企業により、決済代金相当額が、引落代行会社や事業者に支払われる。
なお、上記のような回収リスクを回避するために、従業員の所属企業に請求を行ったり、従業員から所定の担保(例えば、支払前の報酬等)を取るように構成することも可能である。
また、非正規社員である従業員(Empl3)は、食堂と売店1を利用して決済を行っており(図2の(1))、この従業員(Empl3)について、クレジットカード払いを行うという決済方法が、クラウド人事データベースに登録されているものとする。この場合、決済方法=「クレジットカード払い」に係る決済処理を行う決済プログラムを実行し、事業者に対して決済データを送信し(図2の(3)-2)、これを受信した事業者は、従業員(Empl3)からの委託に基づいて、クレジットカード決済業者である決済代行会社2に対して指示を行い、決済を実行する(図2の(4)-1)。
また、このとき、事業者は、自身の決済代行手数料や、決済代行会社2のクレジットカード決済手数料等の手数料を企業の人事総務部あてに請求する(図2の(4)-2)。ただし、こうした、委託による決済を実行する事業者等の手数料を、どの組織がどのタイミングで負担するかについては、様々な方法を考えることができ、上述した態様に限定されるものではない。
このほか、非正規社員である従業員(Empl4、Empl5)はそれぞれ、売店2を利用して決済を行っており(図2の(1))、これらの従業員(Empl4、Empl5)は、電子マネーやクレジットカード払いを行うという決済方法が、クラウド人事データベースに登録されているものとする。この場合も上記と同様に、各決済方法に対応した決済プログラムを実行し、事業者に対して決済データを送信し(図2の(3)-2)、これを受信した事業者は、従業員(Empl4、Empl5)からの委託に基づいて、電子マネー決済業者やクレジットカード決済業者である決済代行会社3、4に対して指示を行い、決済を実行する(図2の(4)-1)。
なお、本実施形態では、従業員(Empl2)について、決済方法=「一括銀行引落」に係る決済処理を行うことで後払い決済を実現しているが、非正規社員で設定可能な後払い決済の方法は、こうした「一括銀行引落」には限定されない。例えば、上述した従業員(Empl3)のように、決済方法=「クレジットカード払い」を設定することで後払い決済を実現することもできる。この場合、従業員は、当該決済方法で設定されている支払い方法で決済金額に基づく金額を支払う(例えば、利用月の翌月末に、所定の銀行口座から引落がおこなわれる)。
また、所定の後払い決済事業者によって立替が行われ、決済後に従業員に対して請求書が発行されるといった決済方法を設定することができる(例えば、決済方法=「決済事業者A」)。この場合、従業員は、当該決済方法で設定されている支払い方法、すなわち、発行された請求書に基づいて、当該従業員が、任意の払込方法(金融機関での振込やクレジットカードの利用等)で別途、請求金額の払込・精算を行う。
このような様々な後払い決済の方法は、雇用カテゴリーに応じて特定のものを選択可能とすることもできるし、雇用カテゴリーに関わらずすべての後払い決済を設定できるようにするこもできる。
また、図2には示していないが、非正規社員である従業員が、食堂や売店に対して決済を行う場合、例えば、デビットカードや事前にチャージが必要な事前チャージ型電子マネー等を用いた決済方法を設定可能である。この場合、デビットカードでの決済であれば、そのデビットカードの会社(例えばクレジット会社)が、即座に、従業員の銀行口座から決済金額を引き落とし、事前チャージ型電子マネーでの決済であれば、従業員のスマホやチャージ機等の操作により、決済より前に、従業員の資金によるチャージが行われる。このように、本発明の決済システム1では、後払い決済だけでなく、デビットカード等を用いた「即時決済」や、事前チャージ型電子マネー等を用いた「先払い決済」を設定することが可能である。また、このような即時決済や先払い決済は、特定の雇用カテゴリーにおいて設定可能とすることもできるし(例えば、非正規社員にみに設定可能とし)、また、雇用カテゴリーの如何にかかわらず設定可能とすることもできる。
このように、特定の企業などの組織において、正社員や非常に多種多様な雇用カテゴリーからなる非正規社員によって構成されている従業員が全員同じ一つのQRコード決済を用いるが、クラウド人事データベースの中に各々の雇用カテゴリー、各々の従業員に適用される決済手段が記録されていることによって、一つのQRコード決済を用いるのにも関わらず、各々の従業員ごとに異なる決済方式を適用することが可能となる。
なお、図1、図2では、ユーザ登録や商品の購入(決済)の際に、スマホに表示されたQRコード1が用いられているが、このような態様は一例に過ぎず、スマホやQRコード以外を利用することもできる。例えば、スマホにQRコード以外のコードを表示させたり、スマホやICカードに記憶された情報を、NFC機能によって読み取るようにしてもよい。また、スマホ以外の媒体にQRコードを表示・記憶させたり、スマホ以外の媒体にQRコード以外のバーコード等のコードを表示・記憶させたりするといった、他の様々な方法を利用可能である。
次に、図3~図6を参照して、本発明の一実施形態に係る決済システムについて、より具体的なシステム構成とともに説明する。
図3に示す本発明の決済システム1は、受付手段11、決済手段12、及び決済方法記憶手段13を備えている。受付手段11は、例えば、図2で説明したPOSレジ等の精算装置に対応し、決済手段12は、図2で説明した決済プログラムを実行する(事業者クラウド上の)コンピュータ(CPU)に対応する。また、本発明の決済システム1は、図1、図2で説明したクラウド人事データベースを含み、決済方法記憶手段13は、このクラウド人事データベースの一部(決済方法テーブル)に対応する。
なお、本発明の決済システム1は、一の企業(組織)に関連する食堂や売店といった施設での商品の購入で決済を行う場合に利用される。ここで、商品は、食堂で提供される料理や、売店で販売される物品等である。また、決済の対象は、こうした商品だけでなく、当該企業に関連する施設でサービス(例えば、従業員に対して施される役務)の対価を支払う場合にも利用されうる。
受付手段11は、例えば、POSレジなどの装置であり、食堂や売店といった施設に配置される。受付手段11では、多種多様な雇用カテゴリーに属する従業員が購入する商品等(商品や役務)の金額が入力され、その合計金額(決済金額)が、各従業員に設定されている決済方法により決済される。
上述した受付手段11は、商品等の金額を入力する場合、従来のレジのイメージで、スタッフがその商品等の金額を個別に手入力することもできるし、その商品等に貼付されたコード(例えば、バーコードや2次元コード等)をバーコードリーダやカメラで読み取って入力することもできる。なお、食堂において料理が提供される場合は、料理の皿や他の入れ物などにコードが貼付されうる。また、コードを読み取って金額を入力する場合、スタッフを配置せずに、購入者である従業員自身が、商品等のコードを、バーコードリーダやカメラで読み取らせるようにしてもよい。
また、商品等に、RFID等の無線通信で読み取りが可能なRFタグ等が貼付されている場合は、スタッフがその商品等を所定のリーダー(例えば、短距離無線通信リーダーであるRFタグリーダーやNFCリーダー等)にかざして、金額を読み取ることができる。また、この場合に、スタッフを配置せずに、購入者である従業員自身が、商品等を所定位置に配置することで、所定のリーダーが自動的に金額を読み取る構成としてもよい。
受付手段11では、従業員が購入する商品等の合計金額を算出すると、例えば、その合計金額をディスプレイ等の表示装置に表示して提示する。ここで、従業員は、決済を行うために、従業員情報(例えば、従業員を識別するための従業員ID)を受付手段11に提供する。
従業員情報は、図3に示すように、例えば、従業員のスマホのディスプレイに、アプリ等によって表示されたQRコード、入構証に印刷されたQRコード、スマホ・入構証以外の他の媒体(例えば、印刷媒体)に表示されたQRコード等に埋め込まれ、受付手段11のカメラやバーコードリーダで読み取られる。決済手段12は、受付手段11から決済データ(従業員情報と決済金額)を受信すると、この従業員情報に対応する決済方法で決済を実行する。決済が正常に終了した場合に、受付手段11に決済の完了が通知され、この通知を受信した受付手段11は、ディスプレイ等に決済完了のメッセージを表示し、必要に応じてレシート等を発行する。
本発明の決済システム1では、図1、図2に示したように、多種多様な雇用カテゴリーの従業員に対して、同じ方法で、対応するQRコードを発行し、こうして発行されたQRコードを、図3に示すように、スマホ、入構証、他の媒体等に表示させる。そして、各従業員は、自身の雇用カテゴリーに関わらず、同じ購入動作で、それらのQRコードを用いて食堂や売店における決済が可能である。
なお、従業員情報を提供するためにQRコード以外の方法を利用することができる。例えば、図3に示すように、従業員が決済において提示するQRコードの代わりに、スマホやICカードに記憶された従業員情報を、NFC機能によって(例えば、受付手段11のNFCリーダ等によって)読み取るようにしてもよい。その他、バーコードや他のコードを用いたり、他の記録媒体に記録された情報を用いるなど、様々な方法で受付手段11に従業員情報が提供されうる。
決済手段12は、受付手段11から決済データ(従業員情報と決済金額)を受信すると、決済方法記憶手段13にアクセスし、受信した従業員情報に対応する情報を取得する。決済方法記憶手段13の例は、図4(B)に示されているが、この例では、受信した従業員情報(従業員ID)に対応する、決済方法、及び決済情報が取得される。なお、決済情報には、上限金額と支払元情報(例えば、銀行の口座番号やクレジットカード番号等)が含まれる。
次に、決済手段12は、受信した従業員情報に対応する決済方法に応じた決済プログラムを実行する。そこで、決済プログラムは、クラウド人事データベースに記憶されている購入履歴テーブル(図4(C)参照)を参照して、今月の購入金額の合計を計算し、その購入金額の合計と、決済方法記憶手段13から取得した上限金額とを比較し、購入金額の合計が上限金額を超えている場合は、当該決済処理を中止し、上限金額の超過により決済不能である旨を受付手段11に通知する。受付手段11は、この通知を受信すると、ディスプレイ等に決済不能(上限エラー)のメッセージを表示し、そこで、購入しようとする従業員に対象商品等を提供することができない提供不能状態となる。
その他、従業員情報が決済方法記憶手段13に記憶されていなかったり(例えば、ユーザ登録がされていない場合等)、従業員情報に対応するデータに所定のフラグがセットされているような場合(例えば、退職した場合や、支払い不能状態が続いて人事総務部から排除されている場合等)は、上記と同様に決済不能とし、所定のメッセージを受付手段11に送信する。
一方、上限金額の制限をクリアした場合であって、受信した従業員情報に対応する決済方法によって決済が行われた場合、決済手段12は、決済が正常に完了したことを受付手段11に通知する。受付手段11は、この通知を受信すると、ディスプレイ等に決済完了のメッセージを表示し、そこで、購入しようとする従業員に対象商品等を提供することが可能な提供可能状態となり、必要に応じて、レシート等を発行する。
このとき、受信した従業員情報に対応する決済方法が、例えば、正社員の決済方法A(=給与控除)である場合、その決済方法に応じた決済プログラムが決済手段12で実行され、従業員情報(従業員ID=ID1)と決済金額を含む決済データを、事業者1(例えば、図2の企業の人事総務部)が管理する人事データベース(給与システム)に送信する。事業者1は、決済データを受信すると、当該給与システムにおいて、従業員ごとに決済金額を累積し、給与計算の基準日において、累積された決済金額(例えば、1ヶ月の累積金額)を給与から控除し(天引きし)、控除後の給与を従業員の銀行口座等に振り込む。このような手順により、正社員に関する後払い決済が行われる。
なお、上記のように、正社員である従業員は、基本的に累積された決済金額に相当する額が給与から控除されることにより、実質的な支払いを行うこととなるが、控除額は、例えば、ポイントや補助金等に基づく減算額により、累積された決済金額より小さな額となることもある。逆に、所定の手数料や利息等に基づく加算額を加味して、累積された決済金額より大きな額となる可能性もある。また、後述するように、所定期間内における決済の上限金額を設けることができるが、上限金額の判定においては、上記のような減算額や加算額を考慮するか否かを適宜決定することができる。
また、例えば、受信した従業員情報に対応する決済方法が、例えば、非正規社員の決済方法B(=一括銀行引落)である場合、その決済方法に応じた決済プログラムが決済手段12で実行され、従業員情報(従業員ID=ID2)と決済金額を含む決済データを、事業者2(例えば、図2の事業者)の立替システムに送信する。事業者2の立替システムは、決済金額を提供することによって当該決済を完了させ、従業員ごとに、決済金額を蓄積する。このような手順により、非正規社員に関する後払い決済が行われる。
ここで、「後払い決済」は、受付手段11において商品等を購入した場合に、決済自体は完了しているが、従業員の立場からするとその商品の支払いが行われていないという決済方法である。すなわち、上述した正社員の決済方法A(=給与控除)の場合は、基本的には、事業者1(すなわち、従業員が雇用されている企業)が立替払いをしていることになる。
一方、上述した非正規社員の決済方法B(=一括銀行引落)の場合は、第三者である事業者2が立替払いをしている。なお、決済方法Bのような決済方法は、例えば、BNPL(Buy Now,Pay Later)という決済サービスとして普及し始めているものである。この決済方法は、「今買って、後で支払う」というサービスであり、消費者が商品等を購入した際に、その場で全額支払うのではなく、月末または翌月末といった所定タイミングにおいて、当該消費者が一括払い(または分割払い)を行うという後払い決済であり、原則として消費者に手数料は課されない。
この例では、その後、事業者2が、毎月末といったタイミングで、各従業員に立て替えた決済金額(蓄積された決済金額)を、従業員が指定した銀行口座から一括で引き落とすように、引落代行会社に依頼し、引落代行会社の引落システムは、この依頼に応じて、従業員の銀行口座等から、立て替えた決済金額を引き落とす。ここで、事業者2は、例えば、後払い決済に係る手数料や、引落代行会社の引落代行手数料等の手数料を事業者1(非正規社員を雇用する企業の人事総務部)あてに請求する。また、図2に関連して説明したように、こうした、後払い決済を実行する事業者2の手数料を、どの組織がどのタイミングで負担するかについては、様々な方法をとることができる。
なお、上記のように、非正規社員である従業員は、基本的に累積された決済金額に相当する額が、当該従業員の銀行口座等から引き落とされることにより、実質的な支払いを行うこととなるが、引落額は、例えば、ポイントや補助金等に基づく減算額により、累積された決済金額より小さな額となることもある。逆に、所定の手数料や利息等に基づく加算額を加味して、累積された決済金額より大きな額となる可能性もある。また、後述するように、所定期間内における決済の上限金額を設けることができるが、上限金額の判定においては、上記のような減算額や加算額を考慮するか否かを適宜決定することができる。
図4は、図3で示した本発明の決済システム1で利用されるデータの項目を例示したものである。図4に示すデータは、データベース、テーブル、記憶手段等、それぞれ異なる表現で記載されているが、それぞれ複数の項目を有するデータレコードを複数記憶しているという意味では差がなく、また、それぞれ、所定のコンピュータ装置のハードディスクや不揮発性メモリに記憶される。
図4(A)に示す人事データベースは、事業者1(企業の人事総務部)の内部で運営・管理されるデータベースであり、当該企業に関わる従業員の属性や給与に関する情報、及び雇用カテゴリーが、従業員ごとに記憶されている。なお、本発明の決済システム1で決済を行う際の(月間の)上限金額を、この人事データベースに記憶しておくこともでき、このように記憶することによって、上限金額を、雇用カテゴリー単位ではなく、それぞれ従業員ごとに設定することができ、より緻密な雇用カテゴリーの管理が可能となる。例えば、役職、勤務年数、給与の額等によって、上限金額を変動させることができる。なお、上限金額は、ここでは、月間での上限金額を定義しているが、これに限られるものではなく、所定の期間における上限金額を定義できる(以下の上限金額について同じ)。
また、この人事データベースは、機密性が高いために、事業者クラウド等には配置されず、事業者1によって厳重に管理される。この人事データベースのうち、従業員IDや、雇用カテゴリーに応じて設定される決済方法が、事業者クラウドにコピーされ、後述の決済方法記憶手段13(決済方法テーブル)に記憶される。
図4(B)に示す決済方法記憶手段13は、従業員ごとに決済方法を対応付けて記憶した決済方法テーブルであり、この例では、図4(A)の人事データベースで把握される従業員の雇用カテゴリーに応じて、1対1で決済方法が設定される。例えば、図3で示したように、従業員の雇用カテゴリーが正社員である場合、決済方法は、決済方法A(給与控除)に設定され、従業員の雇用カテゴリーが非正規社員である場合、決済方法は、決済方法B(一括銀行引落)に設定される。また、決済方法記憶手段13では、設定された決済方法に関する情報を従業員ごとに決済情報として記憶する。
決済情報は、例えば、上限金額や支払元情報を含んでいる。上限金額は、本発明の決済システム1で決済を行う際の(月間の)上限金額であり、この例では、決済方法ごとに固定的な額が設定される。支払元情報は、例えば、決済方法が、決済方法B(一括銀行引落)である場合に、後で一括引落がされる従業員の銀行口座の情報が記憶される。また、クレジットカード決済を用いる場合はクレジットカード番号等の情報が記憶され、電子マネーによる決済を用いる場合は、電マネー種別、電子マネー識別ID等の情報が記憶される。
図4(C)に示す購入履歴テーブルは、従業員ごとに、商品等の購入日時、購入金額等を累積的に記憶する。図3で説明したように、決済手段12は、この購入履歴テーブルを参照して、従業員の今月の決済金額を把握し、その月間での累積の決済金額が上限金額を超えていないか否かをチェックする。
図5、図6には、従業員が本発明の決済システム1を利用する場合のユーザ登録で、自身のスマホに表示されるユーザ登録画面の例が示されている。例えば、図1で説明したように、企業の人事総務部(図3では事業者1)から提供されたQRコードを用いて事業者クラウドのWEBサーバ等にアクセスし、そこで、従業員のスマホに、図5や図6のようなユーザ登録画面が表示される。
図5は、従業員の雇用カテゴリーが正社員の場合であって、その正社員の決済方法が、決済方法A(=給与控除)に固定的に設定されている場合に示されるユーザ登録画面である。ここで、正社員である従業員が、決済方法として給与控除を設定する場合は、月間の上限金額の案内を確認した後で「決定」ボタンをタッチすると、従業員のスマホに表示された元のQRコード、または、新たに事業者クラウド等から提供されたQRコードを用いて受付手段11に対して従業員情報が提供され、設定した決済方法(給与控除)により、商品等の購入が可能になる。この決済方法は、給与日に給与控除がされると考えれば、実質的に後払い決済ということができる。QRコードは、受付手段11に対して、スマホのアプリで表示されることによって提供されたり、他の様々な態様で提供されうる(図3の従業員情報提供態様を参照)。また、この例では、QRコードを用いて従業員情報を提供しているが、他の様々な手段を利用することができる(図3の従業員情報提供態様を参照)。
一方、このユーザ登録画面で、「戻る」ボタンをタッチした場合は、決済方法の設定が行われず、QRコードを用いた決済を行うことができない。
図6(A)は、従業員の雇用カテゴリーが非正規社員の場合であって、その非正規社員の決済方法が、決済方法B(=一括銀行引落)に固定的に設定されている場合に示されるユーザ登録画面である。ここで、非正規社員である従業員が、決済方法として一括銀行引落を設定する場合は「次へ」ボタンをタッチすると、スマホの画面が図6(B)の決済情報入力画面に遷移する。
図6(B)の決済情報入力画面では、決済方法B(=一括銀行引落)に必要な従業員の情報を入力する。この場合、決済金額を後日、一括で銀行口座から引き落とすため、銀行口座を特定するための情報(銀行名、支店名、口座番号)を入力する。入力後、月間の上限金額の案内を確認して「決定」ボタンをタッチすると、従業員のスマホに表示された元のQRコード、または、新たに事業者クラウド等から提供されたQRコードを用いて受付手段11に対して従業員情報が提供され、設定した決済方法(一括銀行引落)により、商品等の購入が可能になる。この決済方法は、後日、銀行口座から一括で引落がされる、典型的な後払い決済である。
次に、図7~図9を参照して、本発明の別の決済システム1’について説明する。図3~図6を参照して説明した決済システム1では、雇用カテゴリーに応じて、対応する1つの決済方法を設定するようにした。すなわち、従業員の雇用カテゴリーが正社員の場合に、決済方法として決済方法A(給与控除)を設定し、従業員の雇用カテゴリーが非正規社員の場合に、決済方法として決済方法B(一括銀行引落)を設定した。
しかしながら、決済システム1’では、1つの雇用カテゴリーに応じて複数の決済方法を選択可能とし、そのなかから従業員が1つの決済方法を選択して設定する構成になっている。また、雇用カテゴリーも決済システム1と比べて細分化されており、この例では、特定の条件を満たす正社員の雇用カテゴリーを「12」とし、特定の条件を満たす非正規社員の雇用カテゴリーを「22」としている。
決済システム1’では、事業者クラウドに、図4(B)で説明した決済方法記憶手段13、図4(C)で説明した購入履歴テーブルの他に、図7(A)に示す雇用カテゴリーテーブルが配置される。なお、企業の人事総務部(図3では事業者1)には、図4(A)に示す人事データベースと同様のものが配置される。
図7(A)に示す雇用カテゴリーテーブルは、従業員ごとに、雇用カテゴリーを対応付けたテーブルである。また、事業者クラウドに、図7(B)に示す雇用カテゴリー・決済方法対応テーブルが配置される。雇用カテゴリー・決済方法対応テーブルは、雇用カテゴリーごとに、設定可能な決済方法(決済方法1、決済方法2、決済方法3、決済方法4、・・・)が定義される。また、この例では、雇用カテゴリーごとに上限金額が設定される。
図8、図9には、従業員が本発明の決済システム1’を利用するためのユーザ登録で、自身のスマホに表示されるユーザ登録画面の例が示されている。例えば、図1で説明したように、企業の人事総務部(図3では事業者1)から提供されたQRコードを用いて事業者クラウドにアクセスし、そこで、従業員のスマホに、図8や図9のようなユーザ登録画面が表示される。
図8(A)のユーザ登録画面には、従業員の雇用カテゴリーが「12」の場合に、その雇用カテゴリーで選択可能な決済方法が、プルダウンメニューにより選択可能に示されている。このようなプルダウンメニューは、上述した図7(A)の雇用カテゴリーテーブルと図7(B)の雇用カテゴリー・決済方法対応テーブルを参照することにより展開可能となる。
この例では、決済システム1とは異なり、雇用カテゴリーが正社員のなかでさらに分類されており、雇用カテゴリー=「12」は、例えば、A社の正社員で、A1部所属、役職が係長、勤続年数7年といった条件の従業員に付されるカテゴリーである。
ここで、雇用カテゴリー=「12」である従業員が、決済方法として給与控除を選択して、「次へ」ボタンをタッチすると、スマホの画面が図8(B)の確認画面に遷移する。なお、図8(A)のユーザ登録画面のプルダウンメニューでは、後払い決済として、給与控除と一括銀行引落が選択可能となっている。
確認画面では、選択した決済方法、月間の上限金額が表示され、ここで、「決定」ボタンをタッチすると、従業員のスマホに表示された元のQRコード、または、新たに事業者クラウドから提供されたQRコードを用いて受付手段11に対して従業員情報が提供され、設定した決済方法(給与控除)により、商品等の購入が可能になる。なお、この例では、従業員が給与控除を選択しており、この場合に、従業員が入力する追加の決済情報がないので、図8(B)の確認画面では、入力項目はない。
こうして従業員により指定された決済方法が、図4(B)に示す決済方法記憶手段13に記憶され、決済手段12において決済方法を決定する場合に参照される。
一方、この確認画面で、「戻る」ボタンをタッチした場合は、決済方法の設定が行われず、QRコードを用いた決済を行うことができない。
図9(A)のユーザ登録画面には、従業員の雇用カテゴリーが「22」の場合に、その雇用カテゴリーで選択可能な決済方法が、プルダウンメニューにより選択可能に示されている。このようなプルダウンメニューは、上述した図7(A)の雇用カテゴリーテーブルと図7(B)の雇用カテゴリー・決済方法対応テーブルを参照することにより展開可能となる。
この例では、決済システム1とは異なり、雇用カテゴリーが非正規社員のなかでさらに分類されており、雇用カテゴリー=「22」は、例えば、A社のグループ会社であるAA社のアルバイトで、AA1部所属、役職なし、勤続年数22年といった条件の従業員に付されるカテゴリーである。
ここで、雇用カテゴリー=「22」である従業員が、決済方法としてクレジットカード決済を選択して、「次へ」ボタンをタッチすると、スマホの画面が図9(B)の決済情報入力画面に遷移する。
図9(B)の決済情報入力画面では、クレジットカード決済に必要な従業員の情報を入力する。この場合、決済金額を請求するための情報(クレジットカードの名義人、クレジットカード番号、有効期限)を入力する。なお、クレジットカードでは、クレジットカード会社によって与信管理が行われるが、決済システム1’では、クレジットカード決済の場合でも、上限金額を管理するように構成することができる。入力後、月間の上限金額の案内を確認して「決定」ボタンをタッチすると、従業員のスマホに表示された元のQRコード、または新たに事業者クラウドから提供されたQRコードを用いて受付手段11に対して従業員情報が提供され、設定した決済方法(クレジットカード決済)により、商品等の購入が可能になる。
こうして従業員により指定された決済方法と決済情報(支払元情報)が、図4(B)に示す決済方法記憶手段13に記憶され、決済手段12において決済を実行する場合に参照される。
一方、この決済情報入力画面で、「戻る」ボタンをタッチした場合は、決済方法の設定が行われず、QRコードを用いた決済を行うことができない。
雇用カテゴリー「12」の従業員に係る図8(A)のユーザ登録画面や、雇用カテゴリー「22」に係る図9(A)のユーザ登録画面では、クレジットカードによる決済方法も選択可能であり、この場合も実質的には「後払い決済」となる。しかしながら、クレジットカードを持たない(または持つことができない)従業員も存在し、また、クレジットカードの処理スピードの問題やクレジットカード会社の手数料の問題もあり、本発明では、このクレジットカードによる決済方法を、決済方法における選択肢の1つという位置づけで採用することに意味がある。
また、○○payといったコード決済も決済方法として選択可能であり、この決済方法も、例えば、クレジットカードによるチャージを行えば、実質的には「後払い決済」となる。しかしながら、スマホやクレジットカードを持たない(または持つことができない)従業員も存在し、また、事前にチャージを行う煩雑さやクレジットカード会社の手数料の問題もあり、本発明では、このコード決済による決済方法を、決済方法における選択肢の1つという位置づけで採用することに意味がある。
なお、決済システム1’では、図8、図9に示すように、正社員である従業員、及び非正規社員である従業員のそれぞれにおいて、決済方法=「一括銀行引落」に係る決済処理を設定可能であるが、この他に、「クレジットカード」や「○○pay」等も選択可能であり、設定可能な後払い決済の方法は様々である(図8、図9参照)。
また、このほか、例えば、所定の後払い決済事業者によって立替が行われ、決済後に従業員に発行されるといった決済方法を設定することができる(例えば、決済方法=「決済事業者A」)。この場合、従業員は、当該決済方法で設定されている支払い方法、すなわち、発行された請求書に基づいて、当該従業員が、任意の払込方法(金融機関での振込やクレジットカードの利用等)で別途、請求金額の払込・精算を行う。
また、このような様々な後払い決済の方法は、雇用カテゴリーに応じて特定のものを選択可能とすることもできるし、雇用カテゴリーに関わらずすべての後払い決済を設定できるようにするこもできる。
また、決済システム1’では、非正規社員である従業員は、「後払い決済」以外の決済方法も設定する事ができる。例えば、デビットカードや事前にチャージが必要な事前チャージ型電子マネー等を用いた決済方法を設定可能である。この場合、デビットカードでの決済であれば、そのデビットカードの会社(例えばクレジット会社)が、即座に、従業員の銀行口座から決済金額を引き落とし、事前チャージ型電子マネーでの決済であれば、従業員のスマホやチャージ機等の操作により、決済より前に、従業員の資金によるチャージが行われる。このように、本発明の決済システム1’では、後払い決済だけでなく、デビットカード等を用いた「即時決済」や、事前チャージ型電子マネー等を用いた「先払い決済」を設定することが可能である。また、このような即時決済や先払い決済は、特定の雇用カテゴリーにおいて設定可能とすることもできるし(例えば、非正規社員にみに設定可能とし)、また、雇用カテゴリーの如何にかかわらず設定可能とすることもできる。
なお、従業員の雇用カテゴリーが途中で変わった場合、企業の人事総務部(図3の事業者1)が図4(A)の人事データベースで雇用カテゴリーを更新する。決済システム1では、その更新に同期して、図4(B)の決済方法記憶手段13の決済方法が、新たな雇用カテゴリーに対応する決済方法に更新される。この場合、従業員は、再度、変更された決済方法に対してユーザ登録をし直す必要があり、企業の人事総務部から、当該従業員のスマホ等に、再登録が必要である旨の案内が送信される。ただし、雇用カテゴリーの変更に伴った決済方法の変更がない場合は、再登録を不要とすることもできる。
決済システム1’において、従業員の雇用カテゴリーが変化すると、図7(A)の雇用カテゴリーテーブルが更新され、さらに、その雇用カテゴリーに対応して選択可能な決済方法が変化する可能性がある。この場合、ここまで利用してきた決済方法が、雇用カテゴリーの変更に伴って利用できなくなった場合は、その旨、企業の人事総務部から、当該従業員のスマホ等に案内を送付し、再登録を行う必要がある。ただし、雇用カテゴリーの変更があっても、これまでの決済方法がそのまま利用できる場合は、再登録を不要とすることもできる。また、雇用カテゴリーの変更により、新たな決済方法が選択可能になった場合は、その旨の通知がスマホ等に送付され、従業員は、任意で再登録を行うことができる。
従来の電子マネーやクレジットカードでの決済では、購入に関する購入情報はすべて電子マネー事業者やクレジットカード事業者にダイレクトに送信され、売店を包摂している企業などの一つの組織体がそうした決済データを入手することは不可能であったが、決済システム1’では、クラウド人事データベースに記憶されている購入履歴テーブル(図4(C)参照)に、従業員が食堂や売店で購入した情報(喫食履歴、物品購買履歴)が記録され、各従業員が、いつどのような商品を購入したかを把握することができる。このような本発明の効果は、上述した決済システム1でも同様である。
これにより、決済システム1’では、クラウド人事データベースに記憶されている購入履歴テーブル(図4(C)参照)にアクセスすることによって、各々の従業員の購入履歴を把握することができる。例えば、決済システム1’は、情報提供手段(例えば、事業者クラウドに配置されたサーバ等)を有し、この情報提供手段は、従業員のコンピュータ装置(例えば、スマホ)等から、購入履歴のデータ取得要求を受信すると、購入履歴テーブルに記憶されている購入履歴や決済に関する情報を、従業員のスマホ等に送信するよう制御する。従業員は、スマホに送信された情報によって、自分自身が食堂で購入した商品(料理)の購入履歴に基づく喫食履歴や、当該従業員が売店で購入した商品の購入履歴に基づく物品購買履歴を容易に把握することができる。
また、決済システム1’の情報提供手段(例えば、事業者クラウドに配置されたサーバ等)は、従業員を雇用する企業や、他の組織(例えば、データ分析企業等の第三者組織)のコンピュータ装置(例えば、当該企業に配置されているサーバ等)に、購入履歴テーブルに記憶されている購入履歴や決済に関する情報を提供する。情報提供手段は、上記のコンピュータ装置から受信した検索条件に応じて、その検索条件を満たす情報のみを提供するようにしてもよい。
例えば、上記の情報提供手段は、企業のコンピュータ装置等から検索条件を受信すると、その検索条件を満たす情報を、購入履歴テーブルに記憶されている購入履歴や決済に関する情報から検索し、それらを、企業のコンピュータ装置等に送信するよう制御する。
企業のコンピュータ装置等に提供される情報は、例えば、CSV、XML、JSONといった形式のファイルであり、柔軟な利用が可能である。例えば、様々なアプリケーションにより、これらの情報を取捨選択したり、編集したりすることができる。また、所定のディスプレイ装置に表示させたり、プリンタで印刷したりすることもできる。またさらに、様々なアプリケーションによって、例えば、決済金額といったデータの演算や、他のデータベースのデータとの比較や連携を行うなど、様々にこのデータを利用することができる。
ここまで、図3~図9を参照して、2つの決済システムについて説明したが、これらは一例に過ぎず、他の様々な構成により、本発明の決済システムを実現することができる。
また、本発明の決済システムでは、事業者クラウド上にデータベースを構築して、多種多様な雇用カテゴリーの従業員によるユーザ登録を可能とし、一企業(組織)のなかで食堂や売店を連携して運営することができるが、例えば、A社のグループ(A社、及びA社と関連する企業を含むグループ)と、A社とは関係のないB社のグループを、互いに相手のデータにアクセスができない状態を厳格に維持しつつ、並行して運営することもできる。なお、そのような場合に、個人や企業が特定されないように、各企業を横断して収集した所定のデータ(ビッグデータ)を、各企業に提供したり、そのデータの分析を行ったりすることができる。
こうして収集されたデータにより、例えば、食堂におけるメニューのトレンドや、栄養素の摂取状況等を効果的に把握することができる。
また、本発明の決済システムの決済手段12では、雇用カテゴリー別の決済プログラムに応じて、各々の雇用カテゴリーに応じて、事前に定められ記録されている各種の決済を実行することが可能となっており、たとえば、正社員は給与引落しとなり、ある雇用カテゴリーの従業員は、月末の銀行口座からの引き通しでの決済処理となり、ある雇用カテゴリーの従業員は事前に登録してあるクレジットカードでの決済処理となるなど、事前に自在に設定してある決済手段を、当該従業員の雇用カテゴリーに応じて選択して実行することができる。
また、クラウド人事データベースは、各々の従業員に対して行った決済の詳細を記録する機能を有しており、カテゴリー別決済プログラムが起動して実際の決済を行った結果を、都度詳細に記録することができる。
図1や図2に示す、一の企業(組織)の人事総務部は、クラウド人事データベースにアクセスすることで、従業員がどのような決済を行ったかについて詳細に知ることが可能となる。さらに、従業員が、許可された事前のルールに従って、ログインすることで、当該クラウド人事データベースの自分自身のデータを見ることが可能であり、自分自身の購買履歴や食堂での喫食履歴を閲覧することができる。
事業者クラウドにアクセスしてデータの送受信、及び決済プログラムの実行制御等を行うクラウドシステムは、一の企業(組織)の人事総務部が、従業員が日々行う決済行為に伴う購買や喫食行為の履歴データを含むデータを、自在に加工して様々な形で「見える化」を行うことを可能にする。また、クラウドシステムは、その企業自身の目的の為に加工することも可能であり、または、従業員が自分自身で見ることを目的とした「見える化」を設定する場合もあり、各々の目的に応じた「見える化」を可能とする。
1、1’ 決済システム
11 受付手段
12 決済手段
13 決済方法記憶手段

Claims (8)

  1. 商品等を購入するために従業員が提供した従業員情報を受け付ける受付手段と、
    前記商品等の金額と、前記従業員情報とに基づいた決済を行う決済手段と、
    前記従業員情報に対応付けて決済方法を記憶する決済方法記憶手段と、を備え、
    前記決済手段は、前記決済方法記憶手段を参照して前記従業員情報に対応する決済方法を把握し、前記把握した決済方法を用いて、前記商品等の金額の決済を行い、
    前記決済方法は、前記従業員情報に対応する従業員が属する雇用カテゴリーに応じて設定されることを特徴とする決済システム。
  2. 前記決済方法として、従業員が購入する前記商品等に係る当該従業員による支払いを、前記商品等の決済後に行う、後払い決済を設定することが可能であり、
    前記決済手段は、把握した決済方法が前記後払い決済である場合、前記受付手段が、前記商品等を前記従業員に提供することが可能な提供可能状態となるように制御することを特徴とする、請求項1に記載の決済システム。
  3. 前記決済方法として前記後払い決済が設定されている場合、決済方法ごと、雇用カテゴリーごと、または個別の従業員ごとに、所定期間において購入可能な商品等の合計金額の上限を設定可能であり、
    前記決済手段は、把握した決済方法が前記後払い決済である場合であって、購入する前記商品等の金額によって前記合計金額が前記上限を超える場合は、前記受付手段が、前記商品等を前記従業員に提供することができない提供不能状態となるように制御することを特徴とする、請求項2に記載の決済システム。
  4. 第1雇用カテゴリーに属する従業員に対して第1決済方法を設定可能とし、かつ、第2雇用カテゴリーに属する従業員に対して第2決済方法を設定可能とするように構成され、
    前記第1決済方法と前記第2決済方法はいずれも、従業員が購入する前記商品等に係る当該従業員による支払いを、前記商品等の決済後に行う、後払い決済であり、
    前記決済手段は、
    把握した決済方法が前記第1決済方法である場合に、前記第1雇用カテゴリーに属する従業員が購入する前記商品等について、前記第1決済方法による後払い決済を行うよう制御し、
    把握した決済方法が前記第2決済方法である場合に、前記第2雇用カテゴリーに属する従業員が購入する前記商品等について、前記第1決済方法とは異なる前記第2決済方法による後払い決済を行うよう制御することを特徴とする、請求項1に記載の決済システム。
  5. 前記第1決済方法による後払い決済は、前記従業員に給与が支払われる場合に、購入した商品等の金額に基づく額を当該給与から差し引く決済方法であり、
    前記第2決済方法による後払い決済は、購入した商品等の金額に基づく額を、前記第2決済方法において設定された支払い方法で支払う決済方法であることを特徴とする、請求項4に記載の決済システム。
  6. 前記雇用カテゴリーごとに、対応する決済方法の候補をそれぞれ提示可能であり、
    前記従業員は、自身の雇用カテゴリーに応じて提示された決済方法の候補のなかから、一の決済方法を選択し設定することができることを特徴とする、請求項1に記載の決済システム。
  7. 更に、前記商品等の購入に係る購入情報を記憶する購入情報記憶手段と、
    前記従業員のコンピュータ装置からの要求に応じて、前記購入情報記憶手段に記憶されている購入情報に基づく情報を、前記コンピュータ装置に提供する情報提供手段と、を備え、
    前記購入情報に基づく情報には、前記従業員が食堂で購入した商品の購入履歴に基づく喫食履歴、または前記従業員が売店で購入した商品の購入履歴に基づく物品購買履歴が含まれることを特徴とする、請求項1に記載の決済システム。
  8. 更に、前記商品等の購入に係る購入情報を記憶する購入情報記憶手段と、
    所定のコンピュータ装置からの要求に応じて、前記購入情報記憶手段に記憶されている購入情報に基づく情報を、前記コンピュータ装置に提供する情報提供手段と、を備え、
    前記情報提供手段は、前記コンピュータ装置に前記購入情報に基づく情報を提供し、
    前記コンピュータ装置に提供される情報は、所定のアプリケーションによる編集が可能な形態であることを特徴とする、請求項1に記載の決済システム。
JP2023063036A 2023-04-07 2023-04-07 決済システム Active JP7437594B1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2023063036A JP7437594B1 (ja) 2023-04-07 2023-04-07 決済システム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2023063036A JP7437594B1 (ja) 2023-04-07 2023-04-07 決済システム

Publications (2)

Publication Number Publication Date
JP7437594B1 true JP7437594B1 (ja) 2024-02-26
JP2024149263A JP2024149263A (ja) 2024-10-18

Family

ID=90011379

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2023063036A Active JP7437594B1 (ja) 2023-04-07 2023-04-07 決済システム

Country Status (1)

Country Link
JP (1) JP7437594B1 (ja)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003091686A (ja) 2001-09-19 2003-03-28 Comalliance Kk 社内販売提供システム
JP2005284461A (ja) 2004-03-29 2005-10-13 Nomura Research Institute Ltd 持株会事務処理システム
JP2006215836A (ja) 2005-02-03 2006-08-17 Matsushita Electric Ind Co Ltd 社内販売システム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2003091686A (ja) 2001-09-19 2003-03-28 Comalliance Kk 社内販売提供システム
JP2005284461A (ja) 2004-03-29 2005-10-13 Nomura Research Institute Ltd 持株会事務処理システム
JP2006215836A (ja) 2005-02-03 2006-08-17 Matsushita Electric Ind Co Ltd 社内販売システム

Also Published As

Publication number Publication date
JP2024149263A (ja) 2024-10-18

Similar Documents

Publication Publication Date Title
US20090299865A1 (en) Method and system for making and managing purchases
RU113391U1 (ru) Интерактивная касса самообслуживания
JP6416721B2 (ja) 免税処理システム、情報処理装置及びそのプログラム
WO2000021009A1 (en) Method and system for receiving and processing donations out of the change due from a purchase
JP5357454B2 (ja) 精算管理装置、精算装置、精算管理方法および精算管理プログラム
JP2009176121A (ja) 経営管理システム
WO2017212339A1 (en) System and method of communicating requests and responses using a communications network
JP6896805B2 (ja) 販売システム、携帯端末、ストアコンピュータ
JP7437594B1 (ja) 決済システム
JP6329111B2 (ja) 商品データ処理装置、及びプログラム
JP2016126754A (ja) 税差額払い戻しシステム及び税差額払い戻し方法
JP2016126437A (ja) 税差額払い戻しシステムおよび税差額払い戻し方法
JP2004145877A (ja) 情報処理システム、情報処理方法、情報処理プログラム及び記録媒体
JP2009059294A (ja) 店舗現金管理システム
JP7393497B2 (ja) 免税処理システム、情報処理装置及びそのプログラム
JP7540061B2 (ja) 免税処理システム及び精算装置
JP7534502B2 (ja) 商品データ処理装置、プログラム
JP6661726B2 (ja) 免税処理システム、情報処理装置及びそのプログラム
JP2002117219A (ja) 家計簿作成システム
JP6905113B2 (ja) 記憶装置及びそのプログラム
JP2002133168A (ja) 取引システム及び取引方法
JP6905112B2 (ja) 免税処理システム、情報処理装置及びそのプログラム
JP6797264B2 (ja) 商品データ処理装置、プログラム、及び商品データ処理方法
US20240289870A1 (en) Re-order and buying management system for specialty retailers
JP6661725B2 (ja) 免税処理システム、情報処理装置及びそのプログラム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20230407

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240115

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240118

R150 Certificate of patent or registration of utility model

Ref document number: 7437594

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150