JP2004178318A

JP2004178318A - 電子商取引の収納代行管理システム

Info

Publication number: JP2004178318A
Application number: JP2002344539A
Authority: JP
Inventors: Kazuo Saito; 一穂斎藤
Original assignee: PROGRESS INTERACTIVE Inc
Current assignee: PROGRESS INTERACTIVE Inc
Priority date: 2002-11-27
Filing date: 2002-11-27
Publication date: 2004-06-24

Abstract

【課題】電子商取引の収納代行管理システム
【解決手段】商取引の代金として入金先ユーザーごとに入金されるべき金額・明細を示す入金通知データを、入金元ごとに受信する入金通知受信手段と、入金通知に含まれる入金明細データを含む入金データを記憶する入金データ記憶手段と、入金先ユーザーに代行して入金されるべき金額を受領する専用口座に実際に入金された入金金額データを管理する口座金額管理手段と、入金されるべき入金データｔ実際おに入金された入金金額データとを照合し、照合結果を出力する入金金額照合手段と、照合結果に基づき確定した入金明細を含む入金報告データを生成する入金報告生成手段と、専用口座から各入金先ユーザーに送金した金額を含むデータに基づき口座金額を更新する口座金額更新手段と、専用口座から各入金先ユーザーに送金した入金通知データを生成し送信する入金通知手段とを備える。
【選択図】図１

Description

【０００１】
【発明の属する技術分野】
本発明は、電子商取引の収納代行管理システムに関する。
【０００２】
【従来の技術】
今日では、コンピュータやインターネットの利用の普及に伴い、電子商取引などが広く行われるようになっている。電子商取引のＷＥＢサイト運営者、ショッピングモールへの出店者、その他の商品・サービス・コンテンツ等の販売の対価として金銭を受領するユーザーは、その代金を受領するために、直接自分・自社の銀行口座に振り込みをしてもらったり、現金書留などを利用したりすることもできるが、ある程度の販売活動が行われるようになると、代金の収納を外部の機関を利用することがほとんどである。
たとえば、代金を購入者である一般ユーザーから直接受領する決済期間は、決済手数料などを通常差し引いて入金先ユーザーに対し入金を行う決済機関であり、具体的な一例としてはクレジットカード会社や、配送時の料金代引で決済を行う運送・配送会社、店頭での料金受領により決済を行うコンビニエンスストアなどである。この他にも、料金前払い、その他の課金方法を採用する決済機関を利用することができる。
【０００３】
クレジットカード会社による電子商取引の決済においては、ユーザーがＷＥＢサーバーにアクセスし、認証処理を経て商品を選択、購入し、決済方法としてクレジットカード決済を選択した場合には、与信などの審査を経て決済が可能であれば、受注、受注確認、出荷、配送へと進む。
配送時の料金代引で決済を行う運送・配送会社による電子商取引の決済においては、ユーザーがＷＥＢサーバーにアクセスし、認証処理を経て商品を選択、購入し、決済方法として料金代引決済を選択した場合には、受注、受注確認、出荷、配送へと進み、商品受領時に決済機関である運送・配送会社に支払いを行う。
店頭での料金受領により決済を行うコンビニエンスストアによる電子商取引の決済においては、ユーザーがＷＥＢサーバーにアクセスし、認証処理を経て商品を選択、購入し、決済方法としてコンビニエンスストア等の店頭決済を選択した場合には、決済番号などを発行し、受注、受注確認へと進み、決済番号などを示して店頭での支払が行われたことを確認し、出荷、配送が行われる。
【０００４】
このような決済代行との一例としては、たとえば特開２００１−２８３１３１「代金決済代行システム」においては、電子取引などの当事者である消費者と販売事業者双方に対し、より安全な商取引を可能とするシステムが提案されている。
消費者がインターネットのホームページで販売業者から商品を購入するにあたり、消費者が支払うべき代金を代金決済代行業者が行い、消費者から代金決済代行の申請を受けた販売事業者は代金決済代行業者に代金決済要求を行う。代金決済代行業者は、代金決済代行要求を受けた際、消費者から確実に代金回収できるか否かを、公共料金引落口座に関する情報を用いて行い、公共料金の引き落としに問題のない消費者については代金決済代行を行うことにより、最終的な代金回収は、公共料金引落口座を利用し、公共料金とともに商品代金を引き落とす、というものである。
また、特開２００１−１０９８３５「オンライン取引の収納代行システム」においては、コンビニエンスストア店舗網等を利用して、特にインターネット上の取引の決済手段として好適な代金等収納代行システムが提案されている。
ウエブサイトのサーバは顧客からの要求に応じてシステム全体について一意な識別子を含む請求裏付け情報を送信する。顧客はそれを印刷若しくは携帯情報端末の画面に表示させて請求裏付け手段とし、これを店舗に持参して呈示し同時に現金等の支払手段を行使することにより支払を行う。収納代行者、販売業者との取引データの交換はＨＴＴＰ手段を用いて行うというものである。
【０００５】
【発明が解決しようとする課題】
しかしながら、いずれの決済方法を選択した場合にも、決済会社ごとに締め日（締め日、入金日）が異なるため、電子商取引の運営者などの、最終的に代金を回収する入金先ユーザーの金融機関口座に、実際に入金される日時がまちまちであり、入金先ユーザーは逐一口座残高と入金明細を確認しなければ、どの決済機関からいつ、どれだけの入金があったのかが把握できない。
また、各決済機関ごとに決済手数料などが異なるほか、振込手数料などの取り扱いも異なることがあるため、決済会社から通知される売上報告と、それに対応する実際の入金金額とが異なることが多々あるため、一つ一つ確認をしなければならない。そのため、照合に手間がかかり、また手数料などを考慮しても照合の結果が合わないような誤りがある場合には、決済機関に連絡して確認をしなければならないなど手間がかかる。
また、代金を回収する入金先ユーザーの組織内においても、売上を管理する電子商取引（ＥＣ）の担当部署と、実際の入金を管理する経理部署とが異なるために、組織内での確認や照合を一つ一つしなければならず、手間がかかってしまう。
このような手間をなくすためには、電子商取引の運営者などの代金回収者が従来、組織内で行っていた売上報告と実際の入金の照合処理や、入金金額や残高確認などの業務自体を、代行することが必要になる。
【０００６】
そこで本発明においては、上記の様々な課題を解決し、電子商取引のＷＥＢサイトなどを運営し入金を受領する入金先ユーザーと、入金先ユーザーに対し入金を行う各種決済機関である入金元ユーザーとの間において、入金の照合や集計、入金報告などを代行することが可能なシステムを提供することを目的とする。これにより、電子商取引の運営者などの代金回収者が従来、組織内で行っていた売上報告と実際の入金の照合処理や、入金金額や残高確認などの業務自体を、代行することが可能になる。
【０００７】
【課題を解決するための手段】
上記課題を解決するため、請求項１に記載の発明においては、
入力手段、制御手段、表示手段、出力手段、記憶手段等を備えるコンピュータ等のユーザー端末において操作により情報処理が行われるシステムであって、
商取引の代金として入金先ユーザーごとに入金されるべき金額および明細を示す入金通知データを、入金元ごとに受信または入力により受領する入金通知受信手段と、
入金通知に含まれる入金明細データを含む入金先ユーザーごとかつ入金元ごとの入金データを記憶する入金データ記憶手段と、
入金先ユーザーごとに設けられ、入金先ユーザーに代行して入金されるべき金額を受領する専用口座に対応して、各入金元から実際に入金された入金金額データを管理する口座金額管理手段と、
前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、照合結果を出力する入金金額照合手段と、
照合結果に基づき確定した入金明細を含む入金金額に基づき入金報告データを生成する入金報告生成手段と、
前記の専用口座から各入金先ユーザーに送金した金額を含むデータに基づき、前記の口座金額を更新する口座金額更新手段と、
前記の専用口座から各入金先ユーザーに送金した金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する入金通知手段と、を少なくとも備える、電子商取引の収納代行管理システムであることを特徴としている。
【０００８】
また、上記課題を解決するため、請求項２に記載の発明においては、
請求項１に記載の発明において、
前記の入金通知受信手段は、クレジットカード決済、代引決済、現金決済、口座振込み決済を含む入金通知データを受領して、入金先ユーザーごとかつ入金元ごとの入金データを識別し、入金データ記憶手段に記憶するものである、電子商取引の収納代行管理システムであることを特徴としている。
【０００９】
また、上記課題を解決するため、請求項３に記載の発明においては、
請求項１または２のいずれかに記載の発明において、
前記の入金金額照合手段は、前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、所定の期日に専用口座に未入金であるデータを抽出して出力する、電子商取引の収納代行管理システムであることを特徴としている。
【００１０】
また、上記課題を解決するため、請求項４に記載の発明においては、
請求項３に記載の発明において、
所定の期日に専用口座に未入金であるか否かの判定は、あらかじめ入金元ごとの締め日および支払日を記憶する支払条件記憶手段を参照し、入金されるべき金額および明細を示す入金通知データと照合することにより行うものである、電子商取引の収納代行管理システムであることを特徴としている。
【００１１】
また、上記課題を解決するため、請求項５に記載の発明においては、
請求項１〜４のいずれかに記載の発明において、
前記の入金金額照合手段は、前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、両者のデータに不一致があった場合には該当するデータを抽出して出力する、電子商取引の収納代行管理システムであることを特徴としている。
【００１２】
また、上記課題を解決するため、請求項６に記載の発明においては、
請求項３〜５のいずれかに記載の発明において、
入金報告生成手段により生成され入金先ユーザーに送信される入金報告データには、抽出された未入金のデータまたは不一致のデータが含まれて生成され、
未入金または不一致のデータを保留にした上で、前記の専用口座から各入金先ユーザーに送金した保留の状態の金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する、電子商取引の収納代行管理システムであることを特徴としている。
【００１３】
また、上記課題を解決するため、請求項７に記載の発明においては、
請求項３〜６のいずれかに記載の発明において、
前記のシステムにはさらに、照合の結果抽出された未入金のデータまたは不一致のデータを、該当する入金元に送信する照合結果送信手段が備えられた、電子商取引の収納代行管理システムであることを特徴としている。
【００１４】
また、上記課題を解決するため、請求項８に記載の発明においては、
請求項７に記載の発明において、
照合結果に対する入金元からの回答データを、該当する入金明細に対応して記憶する回答データ記憶手段をさらに備えた、電子商取引の収納代行管理システムであることを特徴としている。
【００１５】
また、上記課題を解決するため、請求項９に記載の発明においては、
請求項８に記載の発明において、
入金報告生成手段により生成され入金先ユーザーに送信される入金報告データには、該当する入金明細に対応する回答データがさらに含まれる、電子商取引の収納代行管理システムであることを特徴としている。
【００１６】
また、上記課題を解決するため、請求項１０に記載の発明においては、
請求項３〜９のいずれかに記載の発明において、
抽出された未入金のデータまたは不一致のデータに対応して、前記の入金金額照合手段が、前記の入金されるべき入金データおよび実際に入金された入金金額データとを再度照合し、未入金または不一致が解消された場合には、実際に入金された入金金額データを更新する、電子商取引の収納代行システムであることを特徴としている。
【００１７】
また、上記課題を解決するため、請求項１１に記載の発明においては、
請求項１０に記載の発明において、
未入金または不一致が解消された場合には、実際に入金された入金金額データを更新し、未入金または不一致のデータを解消した上で、前記の専用口座から各入金先ユーザーに送金した解消後の状態の金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する、電子商取引の収納代行管理システムであることを特徴としている。
【００１８】
また、上記課題を解決するため、請求項１２に記載の発明においては、
請求項１〜１１のいずれかに記載の発明において、
前記システムにはさらに、返金指示データ記憶手段および返金指示データ送信手段が備えられ、商品の返品その他により入金元に対し返金を行う指示を入金先から受領した場合には、返金指示データを返金指示データ記憶手段に記憶するとともに、入金元に対し通知する、電子商取引の収納代行管理システムであることを特徴としている。
【００１９】
【発明の実施の形態】
以下、本発明の実施の形態について図面を参照して説明する。
本発明のシステムは、入力手段、制御手段、表示手段、出力手段、記憶手段等を備えるコンピュータ等のユーザー端末において操作により情報処理が行われるシステムである。
【００２０】
図１は、本発明のシステムの基本的な構成の一例を示すシステム構成図である。
本発明のシステムとしては、通常、パーソナルコンピュータやワークステーション、サーバー装置などのコンピュータ端末が用いられ、一般的にはサーバー装置が用いられる。
また、サーバー装置に接続されて、サーバー管理や各種情報処理のためのコンピュータ端末が備えられる。コンピュータ端末は、制御手段、記憶手段、入力手段、出力手段、表示手段などを備える。またインターネットに代表されるコンピュータネットワークに接続詞、データの送受信を行う機能を備え、ブラウザや電子メールソフトウェア、ワードプロセッサなどのアプリケーションプログラムや、オペレーティングシステム（ＯＳ）を備えることが通常の形態である。
【００２１】
本発明のシステムは、主として電子商取引のＷＥＢサイトなどを運営し、入金を受領する入金先ユーザーと、入金先ユーザーに対し入金を行う各種決済機関である入金元ユーザーとの間において、入金の照合や集計、入金報告などを代行するためのシステムである。
入金先ユーザーは、電子商取引のＷＥＢサイト運営者、ショッピングモールへの出店者、その他の商品・サービス・コンテンツ等の販売の対価として金銭を受領するユーザーである。
入金元ユーザーは、購入者である一般ユーザーから代金を受領して、決済手数料などを通常差し引いて入金先ユーザーに対し入金を行う決済機関であり、具体的な一例としてはクレジットカード会社や、配送時の料金代引で決済を行う運送・配送会社、店頭での料金受領により決済を行うコンビニエンスストアなどである。この他にも、料金前払い、その他の課金方法を採用する決済機関を含むことができる。
【００２２】
図２から図４は、これらの決済機関による決済の流れを示す図である。
図２は、クレジットカード会社による電子商取引の決済の流れを示しており、ユーザーがＷＥＢサーバーにアクセスし、認証処理を経て商品を選択、購入し、決済方法としてクレジットカード決済を選択した場合には、与信などの審査を経て決済が可能であれば、受注、受注確認、出荷、配送へと進む処理の流れを示している。
図３は、配送時の料金代引で決済を行う運送・配送会社による電子商取引の決済の流れを示しており、ユーザーがＷＥＢサーバーにアクセスし、認証処理を経て商品を選択、購入し、決済方法として料金代引決済を選択した場合には、受注、受注確認、出荷、配送へと進み、商品受領時に決済機関である運送・配送会社に支払いを行う処理の流れを示している。
図４は、店頭での料金受領により決済を行うコンビニエンスストアによる電子商取引の決済の流れを示しており、ユーザーがＷＥＢサーバーにアクセスし、認証処理を経て商品を選択、購入し、決済方法としてコンビニエンスストア等の店頭決済を選択した場合には、決済番号などを発行し、受注、受注確認へと進み、決済番号などを示して店頭での支払が行われたことを確認し、出荷、配送が行われる処理の流れを示している。
【００２３】
しかしながら、いずれの決済方法を選択した場合にも、決済会社ごとに締め日（締め日、入金日）が異なるため、入金先ユーザーの金融機関口座には実際に入金される日時がまちまちであり、入金先ユーザーは逐一口座残高と入金明細を確認しなければ、どの決済機関からいつ、どれだけの入金があったのかが把握できない。
また、各決済機関ごとに決済手数料などが異なるほか、振込手数料などの取り扱いも異なることがあるため、決済会社から通知される売上報告と、それに対応する実際の入金金額とが異なることが多々あるため、一つ一つ確認をしなければならない。そのため、照合に手間がかかり、また手数料などを考慮しても照合の結果が合わないような誤りがある場合には、決済機関に連絡して確認をしなければならないなど手間がかかる。
また、入金先ユーザーの組織内においても、売上を管理する電子商取引（ＥＣ）の担当部署と、実際の入金を管理する経理部署とが異なるために、組織内での確認や照合を一つ一つしなければならず、手間がかかってしまう。
図５は、従来の電子商取引における売上報告と入金の業務の流れを示している。
【００２４】
これに対し、図６は、本発明のシステムを利用した場合の電子商取引における売上報告と入金の業務の流れを示している。
電子商取引のＷＥＢサイトなどを運営し入金を受領する入金先ユーザーと、入金先ユーザーに対し入金を行う各種決済機関である入金元ユーザーとの間において、入金の照合や集計、入金報告などを代行するようにしたものである。
入金元ユーザーから入金される金額は、本発明のシステム運営者が照合や集計などを代行するために、直接入金先ユーザーが持っている従来の金融機関口座に入金されるのではなく、入金先ユーザーごとに設定した専用口座を設け、専用口座を本発明のシステム運営者側において管理するようにされている。照合や集計などをした後に、専用口座から本来の入金先ユーザーの金融機関口座に入金を行い、また照合、集計後の入金報告を本発明のシステムから各入金先ユーザーに対し通知する。
【００２５】
本発明のサーバーシステムに接続するために、入金先ユーザーおよび入金元湯０ザ０が備えるユーザー端末としては、通常、パーソナルコンピュータやワークステーションなどのコンピュータ端末が用いられる。この他、ユーザー端末には、インターネット等に接続可能なブラウザ機能を搭載した携帯電話をはじめとする無線通信端末、携帯情報端末や、インターネットＴＶ、ゲーム機器、テレビ会議システム、その他のネットワーク接続機能を備えた家電製品などの機器を広く含む。
コンピュータ端末は、制御手段、記憶手段、入力手段、出力手段、表示手段などを備える。またインターネットに代表されるコンピュータネットワークに接続し、データの送受信を行う機能を備え、ブラウザや電子メールソフトウェア、ワードプロセッサなどのアプリケーションプログラムや、オペレーティングシステム（ＯＳ）を備えることが通常の形態である。
【００２６】
サーバーシステムは、インターネットに代表されるネットワークに接続されて備えられ、コンピュータネットワークに接続するユーザー端末からアクセスされる。
ここでネットワークには、インターネットをはじめとして、専用線により接続されたネットワーク形態や、企業内ＬＡＮ、企業間ＬＡＮ、ＷＡＮなどの形態を広く含む。またここで用いられる通信回線の形態には、有線通信、無線通信の形態を広く含み、衛星通信や、Ｂｌｕｅｔｏｏｔｈなどを用いた形態を含む。
【００２７】
次に、本発明のサーバーシステムは、通常は、アプリケーションサーバー、データベースサーバー、認証サーバー、ＷＥＢサーバー、その他必要に応じメールサーバー、その他の各種装置により構成することができる。
これらの各サーバーは、物理的に同一の装置に設けられる形態や、物理的に複数の装置からなる形態、あるいはネットワークを介して接続される物理的に複数の装置からなる形態などを含み、機能的に同様の機能が実現されるならば、様々な形態を含む。
【００２８】
次に、本発明のシステムは、ユーザー端末からアクセスするためのコンテンツデータ及びプログラムを記憶するＷＥＢサーバーを備えている。
コンテンツデータには、ＨＴＭＬファイル、ＸＭＬファイルなどのＷＥＢ上に表示されるデータファイルや、Ｃ−ＨＴＭＬファイルなどのＷＥＢサイトにアクセス可能な携帯電話等に表示されるデータファイルなどが含まれる。
また、これらのファイルに挿入されるなどして表示又は出力される、文字データファイル、音声データファイル、画像データファイル、動画像データファイル、アニメーションデータファイル，その他の様々なコンテンツデータを記憶することができる。
【００２９】
次にサーバーの構成について説明する。
サーバーは、入金元ユーザーに関するデータを記憶するユーザー情報記憶手段を備えている。
またサーバーは、入金先ユーザーに関するデータを記憶するユーザー情報記憶手段を備えている。
図７は、ユーザー情報記憶手段に記憶される入金元ユーザーデータの一例を示す。
ユーザーＩＤ、ユーザー名、電子メールアドレスその他の連絡先、その他のデータや、ユーザー端末からサーバーにアクセスするためのパスワードなどの認証情報が記憶される。また、締め日や入金日、その他の支払条件などを記憶することが好ましい。
【００３０】
図８は、ユーザー情報記憶手段に記憶される入金先ユーザーデータの一例を示す。
ユーザーＩＤ、ユーザー名、電子メールアドレスその他の連絡先、その他のデータや、ユーザー端末からサーバーにアクセスするためのパスワードなどの認証情報が記憶される。また、入金先ユーザーごとに設定される専用口座番号を記憶することが好ましい。
【００３１】
次に、ユーザー端末からインターネット等の通信手段を介してアクセスするユーザーを認証するユーザー認証手段が備えられる。
ユーザー認証には様々な認証方法を利用することができるが、代表的な方式としては、ユーザー端末からユーザー登録を行い、本発明のシステムを利用するためのユーザーＩＤやパスワードなどが発行される形態が一般的には用いられる。
【００３２】
次にサーバーシステムは、商取引の代金として入金先ユーザーごとに入金されるべき金額および明細を示す入金通知データを、入金元ごとに受信または入力により受領する入金通知受信手段を備えている。
入金通知受信手段は、クレジットカード決済、代引決済、現金決済、口座振込み決済を含む入金通知データを、これらの決済を行う各決済機関から受領して、入金先ユーザーごとかつ入金元ごとの入金データを識別し、入金データ記憶手段に記憶するものである。
入金通知の受信方法としては、各決済機関から、電子メールその他の方法によりインターネット等を介して受信することが望ましい。その他にも、本発明のシステム管理者が各決済機関が備えるサーバーなどにアクセスして受領する方法や、受領した入金通知を本発明のシステム管理者が入力し記憶させる方法などを採用または併用してもよい。
【００３３】
次にサーバーシステムは、入金通知に含まれる入金明細データを含む入金先ユーザーごとかつ入金元ごとの入金データを記憶する入金データ記憶手段を備えている。
図９および図１０は、入金データ記憶手段に記憶されるデータの一例を示すデータ模式図である。
図９においては、どの入金元からどの入金先に対してどれだけの金額が支払われるか（あるいは支払われたか）が記憶される一例を示しており、図１９においては各入金元から各入金先に対して支払われる（あるいは支払われた）金額の内訳である明細が記憶される一例を示している。
なお、これらのデータは一例であって、入金元の決済機関ごとにそのフォーマットなども異なるため、データの形式、内容はこれらには限定されない。
図９に示すように、実際の入金日あるいは入金予定日がデータ項目としてある場合や、あるいは１か月の売上報告・売上明細などの形式の場合、あるいは実際に専用口座に対して入金が行われ、その入金報告・入金明細である場合、あるいは売上報告・売上明細として記憶されるとともに実際の入金に際してその入金報告・入金明細が別途記憶委される場合などが想定される。
【００３４】
次にサーバーシステムは、入金先ユーザーごとに設けられ、入金先ユーザーに代行して入金されるべき金額を受領する専用口座に対応して、各入金元から実際に入金された入金金額データを管理する口座金額管理手段を備えている。
図１１は、口座金額管理手段に記憶されるデータの一例を示すデータ模式図である。
口座金額管理手段に記憶されるデータは、専用口座の残高情報と、その入出金明細などである。通常の金融機関口座において、預金通帳に記帳されるようなデータである。図１１には残高情報を示しているが、さらに入出金の際の入金元、入金先、入出金日などが記録されることが望ましい。
口座金額管理手段に記憶されるデータは、好ましい一例としては、銀行などの金融機関からサーバーシステムにおいてデータを受信して、記憶するものである。
【００３５】
次にサーバーシステムは、入金されるべき入金データおよび実際に入金された入金金額データとを照合し、照合結果を出力する入金金額照合手段を備えている。
入金金額照合手段は、入金データ記憶手段に記憶されたデータと、口座金額管理手段に記憶されたデータとを照合する。
前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、両者のデータに不一致があった場合には該当するデータを抽出して出力する。
照合の方法は様々であるが、入金元ユーザーから入金先ユーザー（専用口座）へ入金されるべき金額を、入金取引ごとにリストとして表示・出力し、それに対応する口座金額管理手段に記憶された入金データを読み出して、対応する入金があった場合にはたとえばリストにチェックを入れるなどして照合する。照合の結果金額が合致した場合には、入金データ記憶手段に記憶されたデータを入金済のであることを示すデータを付加して記憶することが望ましく、また金額等に不一致があった場合には不一致を示すデータと、不一致の金額を示すデータとを付加して記憶することが望ましい。
【００３６】
また、支払条件を参照することにより、入金金額照合手段は、前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、所定の期日に専用口座に未入金であるデータを抽出して出力することができる。
好ましくは、所定の期日に専用口座に未入金であるか否かの判定は、あらかじめ入金元ごとの締め日および支払日を記憶する支払条件記憶手段を参照し、入金されるべき金額および明細を示す入金通知データと照合することにより行う。
照合の際に、入金元ごとの締め日および支払日を含む支払条件を参照し、入金元ユーザーから入金先ユーザー（専用口座）へ入金されるべき金額を、入金取引ごとにリストとして表示・出力することが望ましい。
【００３７】
次にサーバーシステムは、照合結果に基づき確定した入金明細を含む入金金額に基づき入金報告データを生成する入金報告生成手段を備えている。
照合の結果、専用口座に入金された入金データを、入金先ユーザーごとに抽出して出力するものである。
照合の結果、未入金または金額の不一致などがあった場合には、下記のような取り扱いをすることができる。
入金報告生成手段により生成され入金先ユーザーに送信される入金報告データには、抽出された未入金のデータまたは不一致のデータが含まれて生成され、未入金または不一致のデータを保留にした上で、前記の専用口座から各入金先ユーザーに送金した保留の状態の金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する。
一方、後述するように不一致を解消した後に、不一致のない入金報告として入金先ユーザーごとに入金通知データを生成し、入金先端末に送信することもできる。
【００３８】
次にサーバーシステムは、専用口座から各入金先ユーザーに送金した金額を含むデータに基づき、前記の口座金額を更新する口座金額更新手段を備えている。
専用口座に入金された金額は、本発明のシステム管理者から各入金先ユーザーの本来の金融機関口座に送金を行うので、送金をした場合には送金後の口座金額に更新を行うものである。
更新は、サーバーシステム管理者が送金をした処理により行ってもよいが、各入金先ごとの専用口座を銀行などの金融機関に設けている場合には、銀行などの金融機関からサーバーシステムにおいてデータを受信して、口座金額管理手段のデータを更新記憶すればよい。
【００３９】
次にサーバーシステムは、専用口座から各入金先ユーザーに送金した金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する入金通知手段を備えている。
実際に入金を行った通知をするものであり、前記の入金報告生成手段が生成する入金報告データと兼用することであってもよいが、入金報告と実際の入金との間にタイムラグがある場合などには別個に行うことができる。データの送信は、電子メールその他の通信方法を採用することができる。
【００４０】
次に本発明のシステムの望ましい実施形態の一例について説明する。
前記システムにはさらに、照合の結果抽出された未入金のデータまたは不一致のデータを、該当する入金元に送信する照合結果送信手段が備えられた形態を採用すれば、照合の結果の不一致を、入金元である各決済機関に対し問い合わせることができる。
照合の結果、入金元である各決済機関ごとに出力される未入金データ、金額の不一致データを、電子メールその他の方法により、各決済機関に送信する。
さらに、問い合わせをした結果、照合結果に対する入金元からの回答データを、該当する入金明細に対応して記憶する回答データ記憶手段をさらに備えることが望ましい。
回答の結果、入金日が確定した場合には、実際に入金がされれば不一致が解消する。
一方、入金日が確定しないという問題があったり、あるいは未入金や不一致には特別の理由がある場合などには、入金報告生成手段により生成され入金先ユーザーに送信される入金報告データには、該当する入金明細に対応する回答データがさらに含まれることが望ましい。
【００４１】
抽出された未入金のデータまたは不一致のデータに対応して、前記の入金金額照合手段が、前記の入金されるべき入金データおよび実際に入金された入金金額データとを再度照合し、未入金または不一致が解消された場合には、実際に入金された入金金額データを更新する。
不一致等が解消した後に本発明のシステムから入金先に対し送金を行い入金通知をする場合には、入金未入金または不一致が解消された場合には、実際に入金された入金金額データを更新し、未入金または不一致のデータを解消した上で、前記の専用口座から各入金先ユーザーに送金した解消後の状態の金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する。
【００４２】
次に本発明のシステムの別の望ましい実施形態の一例について説明する。
前記システムにはさらに、返金指示データ記憶手段および返金指示データ送信手段が備えられた形態である。商品の返品その他により入金元に対し返金を行う指示を入金先から受領した場合には、返金指示データを返金指示データ記憶手段に記憶するとともに、入金元に対し通知する。
返金に該当する金額が、既に入金元から専用口座に入金済の場合には、専用口座から入金元に対し返金してもよい。あるいは次回に入金されるべき金額から、返金指示データ記憶手段に記憶された返金金額を控除して、次回入金金額から差し引くようにしてもよい。返金に該当する金額が入金元から専用口座に未入金の場合には、次回に入金されるべき金額から、返金指示データ記憶手段に記憶された返金金額を控除して、次回入金金額から差し引くか、あるいは売上報告・売上明細自体を削除するようにしてもよい。削除をした場合にも取引記録自体は残しておくことが望ましい。
また、専用口座と入金先との間においても、既に専用口座から入金崎に入金済の場合には、入金先から専用口座に対し返金を受けてもよい。あるいは次回に送金するべき金額から、返金指示データ記憶手段に記憶された返金金額を控除して、次回送金金額から差し引くようにしてもよい。返金に該当する金額が専用口座から入金先に未入金の場合には、次回に入金されるべき金額から、返金指示データ記憶手段に記憶された返金金額を控除して、次回入金金額から差し引くか、あるいは売上報告・売上明細自体を削除するようにしてもよい。削除をした場合にも取引記録自体は残しておくことが望ましい。
【００４３】
以下、本発明の基本的な処理の流れについて説明する。
図１２から図１６は、本発明の基本的な処理の流れの一例を示すフローチャートである。なお、ここに示す処理の流れは一例であって、これらに限定されるものではなく、様々な応用や変形が可能である。
初めに、図１２を参照して、入金元の各決済機関からの入金データの受領処理について説明する。
なお、通常の代表的な形態では、売上報告の集計や入金処理などは毎月所定日に行うような形態が多く、１か月ごとなどの所定期間を単位として処理を行う。
したがって所定期間が経過するまで、以下の処理を繰り返し行い、所定期間経過後に次の期間（次の月など）の処理を同様に行う。
各クレジットカード会社や運送・配送会社、コンビニエンスストア、その他の入金元の各決済機関から、サーバーにおいて、入金データ（売上報告・売上明細等）を受領する（Ｓ１００）。受領したデータは、入金データ記憶手段に記憶し（Ｓ１０１）、同様に所定期間が経過するまでの間、入金データが蓄積されて、所定期間における入金データを入金元ごと、かつ入金先ごとに記憶される（Ｓ１０２）。
【００４４】
次に、図１３を参照して、入金先ごとに金融機関などに設けられた専用口座の金額を管理する処理について説明する。
所定期間が経過するまで、以下の処理を繰り返し行い、所定期間経過後に次の期間（次の月など）の処理を同様に行う。
専用口座が設けられた金融機関から、専用口座ごとの口座金額データ（残高・入出金明細等）を受領して（Ｓ２００）、サーバーにおいて口座金額管理手段に記憶する（Ｓ２０１）。同様に所定期間が経過するまでの間、口座金額データが蓄積されて、所定期間における実際の入金データを入金元ごと、かつ入金先ごとに記憶される（Ｓ２０２）。
【００４５】
次に図１４を参照して、各入金先からの返金指示処理について説明する。
所定期間が経過するまで、以下の処理を繰り返し行い、所定期間経過後に次の期間（次の月など）の処理を同様に行う。
電子商取引サイト運営者などの各入金先から、返金指示データ（返金先・返金金額・返金明細等）を受領して（Ｓ３００）、返金データ記憶手段に記憶する（Ｓ３０１）。返金指示を該当する決済機関に通知するために、返金指示送信手段が、該当する返金先（入金元）に送信する（Ｓ３０２）。同様に所定期間が経過するまでの間、返金データが蓄積されて、所定期間における返金データを入金元（返金先）ごと、かつ入金先（返金元）ごとに記憶される（Ｓ３０２）。
【００４６】
次に、図１５および図１６を参照して、入金照合処理について説明する。
所定期間ごとに、入金金額照合手段が、本発明の収納代行管理システムから送金を受ける電子商取引サイト運営者などの入金先ごとに、入金データ記憶手段を参照する（Ｓ４００）。入金先ごとの、所定期間における入金元からの入金データ（売上報告・売上明細等）を抽出する（Ｓ４０１）。
照合処理を選択することにより、入金金額照合手段が、入金先ごとに返金データ記憶手段を参照し（Ｓ４０２）、返金があった場合には、入金先ごとの、所定期間における入金元への返金データを抽出する（Ｓ４０３）。
次に、未入金などの判定基準となる期日などを判断するために、入金元ごとの、支払条件を参照し（Ｓ４０４）、入金元ごとの入金されるべき金額と明細（および返金されるべき金額・明細）を抽出し表示する（Ｓ４０５）。抽出されたデータは、サーバーを管理するためのコンピュータ端末などの表示手段に表示され、照合チェック欄などが設けられた一覧明細などの形態で出力・表示されることが望ましい。
【００４７】
次いで実際に入金された金額との照合処理に進み、入金金額照合手段が、口座金額管理手段を入金先ごとに参照し（Ｓ４０６）、明細行ごとに、入金されるべき金額・明細をチェック等により照合する（Ｓ４０７）。
未入金・不一致がある場合には（Ｓ４０８）、未入金・不一致があることを示すデータを、チェック等の操作により記憶する（Ｓ４０９）。また未入金または不一致の金額も記憶することが望ましい。
未入金・不一致がない場合には（Ｓ４０８）、一致（照合ＯＫ）を示すデータを、チェック等の操作により記憶する（Ｓ４１０）。
次の明細行がある場合には（Ｓ４１１）、Ｓ４０７へ戻り同様の照合処理を行う。
【００４８】
すべての明細行の照合処理が終わると、チェックをしたデータを含む入金報告データを生成し（Ｓ４１２）、入金報告データを出力する（Ｓ４１３）。入金報告データを、該当する入金先へ送信する（Ｓ４１４）。
以上の処理は、各入金先ごとに行うので、次の入金先がある場合には（Ｓ４１５）、Ｓ４００へ戻り同様の処理を繰り返す。
入金報告の送付に伴い、本発明の収納代行管理システムが代行管理する専用口座から、実際に入金先が管理する入金先の金融機関口座への入金処理を行い、入金報告とは別個に入金したことを知らせる入金通知を送付する場合には、入金通知を生成し送信する処理を行う。
【００４９】
【発明の効果】
以上詳細に説明したように、本発明によれば、電子商取引のＷＥＢサイトなどを運営し入金を受領する入金先ユーザーと、入金先ユーザーに対し入金を行う各種決済機関である入金元ユーザーとの間において、入金の照合や集計、入金報告などを代行することが可能なシステムを提供することができる。これにより、電子商取引の運営者などの代金回収者が従来、組織内で行っていた売上報告と実際の入金の照合処理や、入金金額や残高確認などの業務自体を、代行することが可能になる。
また、本発明によれば、決済会社ごとに締め日（締め日、入金日）が異なるため、電子商取引の運営者などの、最終的に代金を回収する入金先ユーザーの金融機関口座に、実際に入金される日時がまちまちであり確認をしなければならないという手間を解消し、入金先ユーザーが逐一口座残高と入金明細を確認しなくても、どの決済機関からいつ、どれだけの入金があったのかを把握することが可能になる。
さらに本発明によれば、各決済機関ごとに決済手数料などが異なるほか、振込手数料などの取り扱いも異なることがあるため、決済会社から通知される売上報告と、それに対応する実際の入金金額とが異なることが多々あるため、一つ一つ確認をしなければならないという問題を解決し、照合にかかる手間をなくし、また手数料などを考慮しても照合の結果が合わないような誤りがある場合には、決済機関に連絡して確認をしなければならないなど手間をも軽減することが可能になる。
【図面の簡単な説明】
【図１】本発明のシステムの基本的な構成の一例を示すシステム構成図である。
【図２】クレジットカード会社による電子商取引の決済の流れを示す図である。
【図３】配送時の料金代引で決済を行う運送・配送会社による電子商取引の決済の流れを示す図である。
【図４】店頭での料金受領により決済を行うコンビニエンスストアによる電子商取引の決済の流れを示す図である。
【図５】従来の電子商取引における売上報告と入金の業務の流れを示す図である。
【図６】本発明のシステムを利用した場合の電子商取引における売上報告と入金の業務の流れを示す図である。
【図７】ユーザー情報記憶手段に記憶される入金元ユーザーデータの一例を示すデータ模式図である。
【図８】ユーザー情報記憶手段に記憶される入金先ユーザーデータの一例を示すデータ模式図である。
【図９】入金データ記憶手段に記憶されるデータの一例を示すデータ模式図である。
【図１０】入金データ記憶手段に記憶されるデータの一例を示すデータ模式図である。
【図１１】口座金額管理手段に記憶されるデータの一例を示すデータ模式図である。
【図１２】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１３】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１４】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１５】本発明の基本的な処理の流れの一例を示すフローチャートである。
【図１６】本発明の基本的な処理の流れの一例を示すフローチャートである。

Claims

入力手段、制御手段、表示手段、出力手段、記憶手段等を備えるコンピュータ等のユーザー端末において操作により情報処理が行われるシステムであって、
商取引の代金として入金先ユーザーごとに入金されるべき金額および明細を示す入金通知データを、入金元ごとに受信または入力により受領する入金通知受信手段と、
入金通知に含まれる入金明細データを含む入金先ユーザーごとかつ入金元ごとの入金データを記憶する入金データ記憶手段と、
入金先ユーザーごとに設けられ、入金先ユーザーに代行して入金されるべき金額を受領する専用口座に対応して、各入金元から実際に入金された入金金額データを管理する口座金額管理手段と、
前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、照合結果を出力する入金金額照合手段と、
照合結果に基づき確定した入金明細を含む入金金額に基づき入金報告データを生成する入金報告生成手段と、
前記の専用口座から各入金先ユーザーに送金した金額を含むデータに基づき、前記の口座金額を更新する口座金額更新手段と、
前記の専用口座から各入金先ユーザーに送金した金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信する入金通知手段と、を少なくとも備えることを特徴とする、電子商取引の収納代行管理システム。
請求項１に記載の発明において、
前記の入金通知受信手段は、クレジットカード決済、代引決済、現金決済、口座振込み決済を含む入金通知データを受領して、入金先ユーザーごとかつ入金元ごとの入金データを識別し、入金データ記憶手段に記憶するものであることを特徴とする、電子商取引の収納代行管理システム。
請求項１または２のいずれかに記載の発明において、
前記の入金金額照合手段は、前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、所定の期日に専用口座に未入金であるデータを抽出して出力することを特徴とする、電子商取引の収納代行管理システム。
請求項３に記載の発明において、
所定の期日に専用口座に未入金であるか否かの判定は、あらかじめ入金元ごとの締め日および支払日を記憶する支払条件記憶手段を参照し、入金されるべき金額および明細を示す入金通知データと照合することにより行うものであることを特徴とする、電子商取引の収納代行管理システム。
請求項１〜４のいずれかに記載の発明において、
前記の入金金額照合手段は、前記の入金されるべき入金データおよび実際に入金された入金金額データとを照合し、両者のデータに不一致があった場合には該当するデータを抽出して出力することを特徴とする、電子商取引の収納代行管理システム。
請求項３〜５のいずれかに記載の発明において、
入金報告生成手段により生成され入金先ユーザーに送信される入金報告データには、抽出された未入金のデータまたは不一致のデータが含まれて生成され、
未入金または不一致のデータを保留にした上で、前記の専用口座から各入金先ユーザーに送金した保留の状態の金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信することを特徴とする、電子商取引の収納代行管理システム。
請求項３〜６のいずれかに記載の発明において、
前記のシステムにはさらに、照合の結果抽出された未入金のデータまたは不一致のデータを、該当する入金元に送信する照合結果送信手段が備えられたことを特徴とする、電子商取引の収納代行管理システム。
請求項７に記載の発明において、
照合結果に対する入金元からの回答データを、該当する入金明細に対応して記憶する回答データ記憶手段をさらに備えたことを特徴とする、電子商取引の収納代行管理システム。
請求項８に記載の発明において、
入金報告生成手段により生成され入金先ユーザーに送信される入金報告データには、該当する入金明細に対応する回答データがさらに含まれることを特徴とする、電子商取引の収納代行管理システム。
請求項３〜９のいずれかに記載の発明において、
抽出された未入金のデータまたは不一致のデータに対応して、前記の入金金額照合手段が、前記の入金されるべき入金データおよび実際に入金された入金金額データとを再度照合し、未入金または不一致が解消された場合には、実際に入金された入金金額データを更新することを特徴とする、電子商取引の収納代行システム。
請求項１０に記載の発明において、
未入金または不一致が解消された場合には、実際に入金された入金金額データを更新し、未入金または不一致のデータを解消した上で、前記の専用口座から各入金先ユーザーに送金した解消後の状態の金額を含むデータに基づき、入金先ユーザーごとに入金通知データを生成し、入金先端末に送信することを特徴とする、電子商取引の収納代行管理システム。
請求項１〜１１のいずれかに記載の発明において、
前記システムにはさらに、返金指示データ記憶手段および返金指示データ送信手段が備えられ、商品の返品その他により入金元に対し返金を行う指示を入金先から受領した場合には、返金指示データを返金指示データ記憶手段に記憶するとともに、入金元に対し通知することを特徴とする、電子商取引の収納代行管理システム。