JP7499808B2 - 情報処理装置、情報処理方法およびプログラム - Google Patents

Description

本発明は、電子記録債権の自動発行および早期発行のための、発生記録請求を生成して電子債権記録機関に送信する情報処理装置、情報処理方法およびプログラムに関する。

電子記録債権は、従来の手形や売掛債権等に取って代わる金銭債権であり、近年、その利用が急拡大している。電子記録債権の発行者は、各金融機関が用意したＷｅｂサイトにおいて期間と金額を設定して随時、電子記録債権の発生記録請求を電子債権記録機関に対して行っている。電子債権記録機関は、記録原簿を備えており、発生記録請求に応じてその内容を記録原簿に電子記録することにより、電子記録債権を発生させている。

従来、バイヤーがサプライヤーに対して商品を発注し、サプライヤーが納期までにその商品を納品し、その後、バイヤーは、納品物に対する検収作業完了後、各金融機関のＷｅｂサイトで必要な情報を入力することによって発生記録請求を電子債権記録機関に送っていた。従来は、検収作業や発生記録請求を送信するための入力作業に時間がかかっており、かつ検収完了から入力作業までの間も企業によっては多くの時間がかかっていた。

電子記録債権の導入により、従来の手形等に比べて、事務負担が軽減され、コスト削減も図れるようになってきたが、電子記録債権の利用者の間では電子記録債権を早期資金化することによって資金繰り改善したいというニーズも高まってきている。例えば、創業間もない企業や急な運転資金を必要とする企業などの間では、従来よりも早期資金化のニーズが高まってきている。早期資金化のニーズに応える仕組みとして特許文献１の停止条件付き電子記録債権に関するスキームが知られている。

特許第６１４０９０９号公報

特許文献１には、電子記録債権の発行者側のリスクを低減させた上で電子記録債権を早期発行させるスキームが開示されているが、このスキームは特定の電子記録債権および記録機関に利用が限定されている点で使い勝手が良くなかった。また、引用文献１のスキームでは、電子記録債権の早期発行のために必要情報を入力する等の事務処理を行う必要があり、電子記録債権を自動発行できるスキームではなかった。

従来、電子記録債権の発行者は、納品物に対する検収を終えた後、各金融機関が用意したＷｅｂサイトにおいて期間と金額を設定して随時、電子記録債権の発生記録請求を行わなければならなかった。そのため、検収完了と電子記録債権の発生記録請求が自動連携されていないことから検収完了後、発生記録請求を送信するまでに時間がかかっており、また、複数の事務手続きやオペレーションが必要であったため、人手が介在することによる人的ミス発生のリスクは避けられなかった。

本発明は、このような課題を解決するためになされたものであり、電子記録債権の自動発行および早期発行のための、発生記録請求を生成して電子債権記録機関に送信する情報処理装置、情報処理方法およびプログラムを提供することを目的とする。

上記の課題を解決するために、本発明に係る情報処理装置は、
外部ネットワークと通信するための通信部、記憶部、および制御部を備え、
前記制御部は、
取引商品に対する検収情報を債権者装置から前記通信部を介して受信し、前記検収情報に基づいて前記記憶部の受発注データを更新するステップと、
前記検収情報に基づいて前記記憶部の受発注データが更新されたことに応答して、前記受発注データに含まれる債権者ＩＤおよび債務者ＩＤのそれぞれに関連付けられる債権者情報および債務者情報を前記記憶部のユーザマスタから取得し、および前記受発注データに含まれる発注情報および前記検収情報に基づいて債権金額を算出するステップと、
取得した前記債権者情報、前記債務者情報、算出した前記債権金額に基づいて発生記録請求データを生成し、記録機関システムに送信するステップと
を実行する。

本発明は、プラットフォームに蓄積されている受発注情報を基に電子記録債権の発生記録請求データを自動的に生成して記録機関システムに送信することができるので、電子記録債権の発行者の事務作業を削減できるとともに、人的ミス発生のリスクを低減することができるようになる。

本発明は、特定の情報や条件を電子記録債権に付加する処理を行うことなく、電子記録債権の記録機関システムに発生記録請求データを、自動的にかつ従来よりも早期に送信することができるので、一般的な電子記録債権の発行時に利用可能な汎用的な仕組みとして多くの利用者の資金調達の効率化に資する手段となり得る。

本明細書において開示される実施形態の詳細な理解は、添付図面に関連して例示される以下の説明から得ることができる。
情報処理装置１０を含むシステム全体の構成図である。 情報処理装置１０のシステム構成図である。 ユーザマスタ１０６のデータ構造の一例を説明する図である。 商品マスタ１０７のデータ構造の一例を説明する図である。 受発注データ１０８のデータ構造の一例を説明する図である。 発生記録請求データ１０９のデータ構造の一例を説明する図である。 早期割引率テーブル１１０のデータ構造の一例を説明する図である。 本発明に係る第１の実施形態の処理を説明するフロー図である。 本発明に係る第２の実施形態の処理を説明するフロー図である。 本発明に係る第３の実施形態の処理を説明するフロー図である。 本発明に係る第４の実施形態の処理を説明するフロー図である。 本発明に係る第５の実施形態の処理を説明するフロー図である。

（全体構成）
図１は、本発明に係る情報処理装置１０を含むシステム全体の構成図である。図１に示すように、情報処理装置１０は、サプライヤー装置１１、バイヤー装置１２、記録機関システム１３、および金融機関サーバ１４と相互に通信可能に接続される。図１では説明のために、サプライヤー装置１１、バイヤー装置１２、記録機関システム１３、および金融機関サーバ１４は、１つだけしか示されていないが、これらは複数存在し得る。

情報処理装置１０は、本明細書で説明するような受発注プラットフォームをサプライヤー装置１１およびバイヤー装置１２に提供する。具体的に言えば、情報処理装置１０は、受発注システムのアプリケーションを介して、サプライヤー（債権者）とバイヤー（債務者）の間の受発注、納品および決済に関する受発注データを処理して格納するとともに、受発注データをサプライヤー装置１１およびバイヤー装置１２にブロードキャストする。格納された受発注データは、ブロックチェーンを構成するデータとなる。受発注データは、サプライヤー装置１１およびバイヤー装置１２以外の任意の装置やサーバにブロードキャストされてもよい。

情報処理装置１０は、受発注データを使用して電子記録債権の発生記録請求データを生成して格納するとともに、記録機関システム１３に発生記録請求データを送信する。より詳細に言えば、情報処理装置１０は、本明細書で説明するような様々なタイミングで、予めユーザから貸与されていた電子記録債権の発行のためのログインＩＤおよびパスワードを利用して記録機関システム１３にログインを行い、ブロックチェーン上に格納されている受発注データの債権金額やユーザ情報を使用して電子記録債権の発行のための発生記録請求データを記録機関システム１３に送信することができる。

情報処理装置１０は、サプライヤー装置１１および／またはバイヤー装置１２から決済に関する情報を受信し、格納することができる。情報処理装置１０は、電子記録債権の発生記録請求データを生成する際に、決済に関する情報を利用することができる。

情報処理装置１０は、サプライヤーの口座を有する金融機関の金融機関サーバ１４に、保証金に相当する金額をサプライヤーの口座からプラットフォーム運営会社の口座に資金移動する依頼を送信することができる。情報処理装置１０は、サプライヤーの口座を有する金融機関の金融機関サーバ１４に、保証金の全額または一部をプラットフォーム運営会社の口座からサプライヤーの口座に資金移動する依頼を送信することができる。また、情報処理装置１０は、サプライヤーに返還されなかった保証金の残額をプラットフォーム運営会社の口座からバイヤーの口座に資金移動する依頼を送信することもできる。

サプライヤーは、情報処理装置１０によって提供される受発注プラットフォームを利用することができ、取り扱う商品等を発注者であるバイヤーに納品し、電子記録債権を介して代金を受領することができる。サプライヤー装置１１は、サプライヤー（債権者）によって使用される装置であり、例えば、パーソナルコンピュータ（ＰＣ）、スマートフォンやタブレット端末などの通信機能を備えたコンピュータとすることもでき、またはサーバとクライアント端末の組み合わせとすることもできるが、特定の装置に限定されることはない。

サプライヤー装置１１は、受発注プラットフォームを介して、受注データを受信し、当該受注に対する確認処理を行い、および後述するその他必要な情報を入力する装置である。確認処理された結果および入力情報は情報処理装置１０に送信されて処理される。サプライヤー装置１１は、情報処理装置１０によってブロードキャストされた受発注データを格納することができる。受発注データは、ブロックチェーンを構成するデータとなる。

バイヤーは、情報処理装置１０によって提供される受発注プラットフォームを利用することができ、必要な商品等を受注者であるサプライヤーに発注して納品を受け、納品物の検収を行い、電子記録債権を介して代金を支払うことができる。バイヤー装置１２は、バイヤー（債務者）によって使用される装置であり、例えば、パーソナルコンピュータ（ＰＣ）、スマートフォンやタブレット端末などの通信機能を備えたコンピュータとすることもでき、またはサーバとクライアント端末の組み合わせとすることもできるが、特定の装置に限定されることはない。

バイヤー装置１２は、受発注プラットフォームを介して、発注データを入力して送信し、サプライヤーによって確認処理された結果情報やその他の情報を受信する装置である。入力された発注データは、情報処理装置１０に送信されて処理される。バイヤー装置１２は、情報処理装置１０によってブロードキャストされた受発注データを格納することができる。受発注データは、ブロックチェーンを構成するデータとなる。

記録機関システム１３は、電子記録債権法に基づく電子債権記録機関のシステムであり、情報処理装置１０から発生記録請求および譲渡記録請求などの請求データを受信したことに応答して電子記録債権の発生記録および譲渡記録などを記録原簿に記録する。記録機関システム１３は、ある電子記録債権の支払期日が到来するとその電子記録債権に関連付けられる金融機関の金融機関サーバ１４と通信を行って債務者口座から債権者口座への口座間送金決済を行い、支払等記録を記録原簿に記録する。

金融機関サーバ１４は、記録機関システム１３から口座間送金決済の指示を受信したことに応答して債務者口座から債権者口座への口座間送金決済を行う。金融機関サーバ１４は、保証金に相当する金額をサプライヤーの口座からプラットフォーム運営会社の口座に資金移動する依頼を受信したことに応答して資金移動処理を行い、保証金の全額または一部をプラットフォーム運営会社の口座からサプライヤーの口座に資金移動する依頼を受信したことに応答して資金移動処理を行うことができる。また、金融機関サーバ１４は、サプライヤーに返還されなかった保証金の残額をプラットフォーム運営会社の口座からバイヤーの口座に資金移動する依頼を受信したことに応答して資金移動処理を行うこともできる。上述したように、金融機関サーバ１４は、複数存在することが可能であり、資金移動の依頼は、送金元の口座を有する金融機関に対して行われる。

（システム構成）
図２は、本発明に係る情報処理装置１０のシステム構成図である。情報処理装置１０は、一般的なコンピュータと同様に、バス１２０などによって相互に接続された制御部１０１、主記憶部１０２、補助記憶部１０３、インターフェース（ＩＦ）部１０４、および出力部１０５を備える。情報処理装置１０は、補助記憶部１０３内にファイル／データベースなどの記憶手段の形式で、ユーザマスタ１０６、商品マスタ１０７、受発注データ１０８、発生記録請求データ１０９、および早期割引率テーブル１１０を備える。

制御部１０１は、中央処理装置（ＣＰＵ）とも呼ばれ、情報処理装置１０の各構成要素の制御やデータの演算を行い、また、補助記憶部１０３に格納されている各種プログラムを主記憶部１０２に読み出して実行できる。主記憶部１０２は、メインメモリとも呼ばれ、受信した各種データ、コンピュータ実行可能な命令および当該命令による演算処理後のデータなどを記憶できる。補助記憶部１０３は、ハードディスク（ＨＤＤ）などに代表される記憶装置であり、データやプログラムを長期的に保存する際に使用される。

図２の実施形態は、制御部１０１、主記憶部１０２および補助記憶部１０３を同一のコンピュータ内に設ける実施形態について説明するが、他の実施形態として、情報処理装置１０は、制御部１０１、主記憶部１０２および補助記憶部１０３を複数個使用することにより、複数のコンピュータによる並列分散処理を実現するように構成することもできる。また、他の実施形態として、情報処理装置１０のための複数のサーバを設置し、複数サーバが一つの補助記憶部１０３を共有する実施形態にすることも可能である。

ＩＦ部１０４は、他のシステムや装置との間でデータを送受信する際のインターフェースの役割を果たし、また、システムオペレータから各種コマンドや入力データ（各種マスタ、テーブルなど）を受け付けるインターフェースを提供する。出力部１０５は、処理されたデータを表示する表示画面や当該データを印刷するための印刷手段などを提供する。

なお、制御部１０１、主記憶部１０２、補助記憶部１０３、ＩＦ部１０４および出力部１０５と同様な機能の構成要素は、サプライヤー装置１１、バイヤー装置１２、記録機関システム１３、および金融機関サーバ１４にも存在するが、本明細書ではこれらについての詳細な説明を省略する。

ユーザマスタ１０６は、情報処理装置１０によって提供される受発注プラットフォームを利用するユーザの情報を格納する。図３は、本発明の一実施形態に係るユーザマスタ１０６のデータ構造の一例を説明する図である。ユーザマスタ１０６は、ユーザＩＤ３０１、ユーザ情報３０２、および決済口座３０３を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことが可能である。

ユーザＩＤ３０１は、受発注プラットフォームを利用するサプライヤーやバイヤーなどのユーザを識別する識別子である。ユーザ情報３０２は、ユーザに関連付けられる情報、例えば、ユーザの名称、所在地、連絡先などの情報を含むが、本明細書に示した情報に限定されることはない。決済口座３０３は、受発注プラットフォームを利用するユーザが電子記録債権を利用する際の決済口座の情報を示す。

図２に戻って説明すると、商品マスタ１０７は、各ユーザに関連付けられる商品の情報を格納する。図４は、本発明の一実施形態に係る商品マスタ１０７のデータ構造の一例を説明する図である。商品マスタ１０７は、ユーザＩＤ３０１、商品ＩＤ４０１、商品情報４０２、および温室効果ガス排出量４０３を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことが可能である。

商品ＩＤ４０１は、ユーザ（例えば、サプライヤー）に関連付けられる商品を識別する識別子である。商品情報４０２は、商品に関連付けられる情報、例えば、商品名、単価、容量、ケース当たり個数などの情報を含むが、本明細書に示した情報に限定されることはない。温室効果ガス排出量４０３は、一単位の商品を完成するまでに排出される温室効果ガス（例えば、二酸化炭素（ＣＯ２）など）の排出量を示す情報である。温室効果ガス排出量４０３の値は、外部機関によって調査された結果情報であってもよい、ユーザが調査した結果情報であってもよい。

再び図２に戻って説明すると、受発注データ１０８は、サプライヤーとバイヤーの間で行われる取引に関連する情報を格納する。図５は、本発明の一実施形態に係る受発注データ１０８のデータ構造の一例を説明する図である。受発注データ１０８は、取引ＩＤ５０１、商品ＩＤ４０１、発注者ＩＤ５０２、発注情報５０３、検収情報５０４、受注者ＩＤ５０５、受注情報５０６、納品年月日５０７、取引結果５０８、保証金情報５０９、温室効果ガス排出量５１０、および電子記録債権発行タイミング５１１を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことが可能である。

取引ＩＤ５０１は、サプライヤーとバイヤーの間で行われる取引を識別する識別子である。商品ＩＤ４０１は、取引対象となる商品を識別する識別子である。発注者ＩＤ５０２は、発注者であるユーザ（バイヤー）を識別する識別子であり、ユーザＩＤ３０１がセットされる。発注情報５０３は、発注した商品の名称、発注数、納期、単価などの情報を示す。検収情報５０４は、発注者によって行われた検収結果の情報、例えば、発注通りの納品が行われた、納期に遅れたが発注数通りの納品が行われた（遅延）、納期は守られたが発注数よりも少ない数量の納品しかできなかった（欠品）、などの納品情報、不良品率情報、および検収完了日の情報を含むが、本明細書に示した情報の例に限定されることはない。なお、不良品率情報は、実際に納入された数量に基づいて計算されてもよいし、または予定されていた納入数量に基づいて計算されてもよい。後者の場合は、何らかの理由で欠品となった数量も不良品であるとして計算する場合である。

受注者ＩＤ５０５は、受注者であるユーザ（サプライヤー）を識別する識別子であり、ユーザＩＤ３０１がセットされる。受注情報５０６は、サプライヤーが発注情報を確認したという情報などを示す。納品年月日５０７は、実際の納品日を示す。取引結果５０８は、当該取引の結果情報、例えば、サプライヤー装置１１および／またはバイヤー装置１２から受信した、口座間送金決済に関する情報を含むことができる。口座間送金決済に関する情報は、例えば、債権金額通りの決済が行われた（弁済）、決済が完全にあるいは条件付きで行われなかった（債務不履行：履行不能、履行遅滞、不完全履行）などの情報を含むことができる。

保証金情報５０９は、予め定められた基準に従って算出された保証金の額を示す。保証金は、サプライヤーの口座からプラットフォーム運営会社の口座に資金移動され、不良品等がゼロであれば全額返還され、それ以外の場合不良品の割合に応じて返還額が決まるようになる。温室効果ガス排出量５１０は、当該取引で排出される温室効果ガスの排出総量（商品一単位当たりの排出量×納入数）を示す。電子記録債権発行タイミング５１１は、電子記録債権を予め割引した上で早期発行するタイミング（納品後の所定日数経過時）を示す。

再び図２に戻って説明すると、発生記録請求データ１０９は、記録機関システム１３に送信される発生記録請求の情報を格納する。図６は、本発明の一実施形態に係る発生記録請求データ１０９のデータ構造の一例を説明する図である。発生記録請求データ１０９は、取引ＩＤ５０１、債務者情報６０１、債権者情報６０２、債権金額６０３、支払期日６０４、および備考６０５を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことが可能である。

取引ＩＤ５０１は、サプライヤーとバイヤーの間で行われる取引を識別する識別子である。債務者情報６０１は、債務者であるバイヤーの名称、住所、決済口座の情報などを示す。債権者情報６０２は、債権者であるサプライヤーの名称、住所、決済口座の情報などを示す。債権金額６０３は、当該取引における債権金額（支払金額）を示す。支払期日６０４は、電子記録債権の口座間決済が行われる日を示す。支払期日６０４は、具体的な日付がセットされていないブランク（Ｎｕｌｌ値）であってもよい。備考６０５は、電子記録債権に関する補足情報、例えば、電子記録債権に金融機関による買戻し請求権が付与されている、などの補足情報を示すことができる。備考６０５は、ブランク（Ｎｕｌｌ値）であってもよい。

再び図２に戻って説明すると、早期割引率テーブル１１０は、サプライヤー（受注者）とバイヤー（発注者）の間で予め定められた電子記録債権の早期割引率の情報を示す。図７は、本発明の一実施形態に係る早期割引率テーブル１１０のデータ構造の一例を説明する図である。早期割引率テーブル１１０は、商品ＩＤ４０１、発注者ＩＤ５０２、受注者ＩＤ５０５、通常検収期間７０１、電子記録債権発行タイミング７０２、および割引率７０３を含むことができるが、これらのデータ項目に限定されることはなく他のデータ項目も含むことが可能である。

商品ＩＤ４０１は、電子記録債権の早期割引の対象となる商品を識別する識別子である。発注者ＩＤ５０２は、発注者であるユーザ（バイヤー）を識別する識別子であり、受注者ＩＤ５０５は、受注者であるユーザ（サプライヤー）を識別する識別子であり、それぞれ、ユーザＩＤ３０１がセットされる。通常検収期間７０１は、発注者（バイヤー）と受注者（サプライヤー）の間で取引される商品についての納品時から検収完了までに通常かかる期間（例えば、１５日間）を示す。電子記録債権発行タイミング７０２は、電子記録債権を発行するタイミング（例えば、納品の５日後、受注承認の３０日後など）を示し、割引率７０３は、当該タイミングで電子記録債権を発行する場合の割引率（例えば、満額の９０％など）を示す。

（電子記録債権の自動発行および早期発行の処理フロー）
以下、図８～図１２を参照しながら、電子記録債権の自動発行および早期発行のための、発生記録請求を生成して電子債権記録機関に送信する第１の実施形態～第５の実施形態の処理フローを説明する。これらの処理フローの前提として、サプライヤーおよびバイヤーは、情報処理装置１０によって提供される受発注プラットフォームを利用するユーザであり、サプライヤー装置１１およびバイヤー装置１２は、情報処理装置１０に対する認証処理が成功裏に完了しており、アクセス可能な状態であるものとする。

また、第１の実施形態～第５の実施形態では、情報処理装置１０は、本明細書で説明するような様々なタイミングで、予めユーザから貸与されていた電子記録債権の発行のためのログインＩＤおよびパスワードを利用して記録機関システム１３にログインを行い、ブロックチェーン上に格納されている受発注データの債権金額やユーザ情報などの情報を使用して電子記録債権の発行のための発生記録請求データを生成して記録機関システム１３に送信するものとする。

（第１の実施形態）
図８は、情報処理装置１０によって行われる受発注処理、電子記録債権の発生記録請求、および決済情報受信までの第１の実施形態の処理を説明するフロー図である。

Ｓ８０１にて、情報処理装置１０は、バイヤー装置１２から、ある商品についての発注情報、すなわち、商品ＩＤ４０１、バイヤー（発注者）に関連付けられるユーザＩＤ３０１、サプライヤー（受注者）に関連付けられるユーザＩＤ３０１、発注数、単価、納期、および金額などの情報を受信する。情報処理装置１０は、取引ＩＤ５０１を生成し、受信した発注情報に基づいて、商品ＩＤ４０１、発注者ＩＤ５０２、発注情報５０３、および受注者ＩＤ５０５を受発注データ１０８にセットして受発注データを生成する。情報処理装置１０は、受発注データが生成されたことに応答して、受注者ＩＤ５０５に関連付けられるユーザのサプライヤー装置１１に対して発注があった旨を通知する。

Ｓ８０２にて、サプライヤーは、Ｓ８０１の発注内容を確認し、受注承認したことを示す情報をサプライヤー装置１１に入力する。情報処理装置１０は、取引ＩＤ５０１に関連付けられた、受注承認したことを示す情報をサプライヤー装置１１から受信する。情報処理装置１０は、受注承認情報を受信したことに応答して、受発注データ１０８に格納されている対応する受発注データの受注情報５０６を更新する。

Ｓ８０３にて、サプライヤーがバイヤーに当該商品を納品すると、情報処理装置１０は、納品情報、すなわち、納品年月日の情報をサプライヤー装置１１から受信し、受発注データ１０８の対応する受発注データの納品年月日５０７を更新する。

Ｓ８０４にて、バイヤーが納品された商品を検収し終えると、バイヤーは、検収情報をバイヤー装置１２に入力する。情報処理装置１０は、検収情報、例えば、発注通りの納品が行われた、納期に遅れたが発注数通りの納品が行われた、納期は守られたが発注数よりも少ない数量の納品しかできなかった、などの納品情報、不良品率情報、および検収完了日の情報をバイヤー装置１２から受信し、受発注データ１０８の対応する受発注データの検収情報５０４を更新する。

Ｓ８０５にて、情報処理装置１０は、検収情報５０４の更新が行われたことに応答して、発注者ＩＤ５０２および受注者ＩＤ５０５を使用してユーザマスタ１０６に問い合わせを行い、バイヤーおよびサプライヤーのそれぞれのユーザ情報３０２および決済口座３０３の情報を取得する。情報処理装置１０は、発注情報５０３および検収情報５０４に格納されている情報に基づいて債権金額を算出する。

情報処理装置１０は、検収情報５０４の更新が行われた受発注データの取引ＩＤを取引ＩＤ５０１とし、取得したバイヤーの情報を債務者情報６０１とし、取得したサプライヤーの情報を債権者情報６０２とし、算出した債権金額を債権金額６０３とし、予め定められた支払期間から算出した支払期日を支払期日６０４として、発生記録請求データを生成し、生成した発生記録請求データを記録機関システム１３に送信するとともに、当該発生記録請求データを発生記録請求データ１０９に格納する。

Ｓ８０６にて、情報処理装置１０は、電子記録債権に関して実行された口座間送金決済に関する情報をサプライヤー装置１１および／またはバイヤー装置１２から受信する。口座間送金決済に関する情報は、例えば、債権金額通りの決済が行われた（弁済）、決済が完全にあるいは条件付きで行われなかった（債務不履行：履行不能、履行遅滞、不完全履行）などの情報を含むことができる。

従来技術のフローでは、検収が完了してから電子記録債権の発生記録請求を行うまでに社内での手続きを行い、各金融機関が用意したＷｅｂサイトにおいて期間と金額を設定するなど煩雑な手続きが存在していたため、サプライヤーが資金を回収するまでに相応の時間を要してしまい、また、人手が介在するために人的ミスが発生するリスクは避けられなかった。

第１の実施形態では、受発注プラットフォームと記録機関システム１３が自動連携されており、検収が行われるとすぐに電子記録債権の発生記録請求が記録機関システム１３に送信されるため、サプライヤーは資金回収までの期間を大幅に短縮することができ、かつ人的ミスによるトラブルは極力減らすことができるようになる。

（第２の実施形態）
図９は、情報処理装置１０によって行われる受発注処理、電子記録債権の発生記録請求、および決済情報受信までの第２の実施形態の処理を説明するフロー図である。第２の実施形態は、同一のサプライヤーとバイヤーの間の同一商品の過去の取引において、検収および決済に関して問題がなかった場合、第１の実施形態とは異なり、検収完了を待たずに電子記録債権の発生記録請求を行えることを示す。

第２の実施形態では、図８を参照しながら説明した第１の実施形態のＳ８０１～Ｓ８０３の処理と同様の処理が行われる。

Ｓ９０１にて、情報処理装置１０は、受発注データ１０８の対応する受発注データの納品年月日５０７が更新されたことに応答して、更新された受発注データの商品ＩＤ４０１、発注者ＩＤ５０２、および受注者ＩＤ５０５に基づいて受発注データ１０８に問い合わせを行い、過去取引の受発注データを取得する。情報処理装置１０は、取得された過去取引の受発注データの検収情報５０４および取引結果５０８の情報に基づいて、過去取引において問題があったかどうかを判定する。問題があったかどうかは、検収情報５０４に含まれている納品情報と不良品率情報、および取引結果５０８に含まれている口座間送金決済に関する情報に基づいて判定される。

Ｓ９０１の判定処理において問題があったと判定された場合にはＳ８０４に処理が進む。その後、図８を参照しながら説明した第１の実施形態のＳ８０４～Ｓ８０６の処理と同様の処理が行われる。すなわち、第２の実施形態において、同一のサプライヤーとバイヤーの間の同一商品の過去の取引において、検収および決済に関して問題があった場合には第１の実施形態と同じ処理が行われる。

一方、Ｓ９０１の判定処理において問題がなかったと判定された場合にはＳ９０２に処理が進む。Ｓ９０２にて、情報処理装置１０は、Ｓ８０３の処理において更新された受発注データの発注者ＩＤ５０２および受注者ＩＤ５０５を使用してユーザマスタ１０６に問い合わせを行い、バイヤーおよびサプライヤーのそれぞれのユーザ情報３０２および決済口座３０３の情報を取得する。情報処理装置１０は、発注情報５０３に格納されている情報（例えば、発注数と単価）に基づいて債権金額を算出する。

第２の実施形態において、発注情報５０３に格納されている情報（例えば、発注数と単価）のみに基づいて債権金額を算出するのは、同一のサプライヤーとバイヤーの間の同一商品の過去の取引において、検収および決済に関して問題がなかったため、今回の取引においても問題なく納品されている（不良品率が閾値以下）とみなすからである。

情報処理装置１０は、Ｓ８０３の処理において更新された受発注データの取引ＩＤを取引ＩＤ５０１とし、取得したバイヤーの情報を債務者情報６０１とし、取得したサプライヤーの情報を債権者情報６０２とし、算出した債権金額を債権金額６０３とし、予め定められた支払期間から算出した支払期日を支払期日６０４として、発生記録請求データを生成し、生成した発生記録請求データを記録機関システム１３に送信するとともに、当該発生記録請求データを発生記録請求データ１０９に格納する。

Ｓ９０２の処理が完了した後、図８を参照しながら説明した第１の実施形態のＳ８０４、Ｓ８０６の処理と同様の処理が行われる。

第２の実施形態では、同一のサプライヤーとバイヤーの間の同一商品の過去の取引において、検収および決済に関して問題がなかった場合、検収完了を待たずに電子記録債権の発生記録請求を行えるため、従来技術や第１の実施形態のフローよりも早期に電子記録債権の発生記録請求を行うことができるようになる。第２の実施形態は、同一のサプライヤーとバイヤーの間で行われる同一商品の継続的な取引であって、かつ今まで検収や決済が問題なく行われており、不良品発生率も予め定められた閾値以下に収まっている場合には、検収の完了を待たずとも電子記録債権を発生させても問題ないケースを説明している。

第２の実施形態では、受発注プラットフォームと記録機関システム１３が自動連携されており、納品が行われるとすぐに電子記録債権の発生記録請求が記録機関システム１３に送信されるため、サプライヤーは資金回収までの期間を第１の実施形態よりも大幅に短縮することができ、かつ人的ミスによるトラブルを極力減らすことができるようになる。

（第３の実施形態）
図１０は、情報処理装置１０によって行われる受発注処理、電子記録債権の発生記録請求、および決済情報受信までの第３の実施形態の処理を説明するフロー図である。第３の実施形態は、サプライヤーとバイヤーの間で予め定められた早期割引率に基づいて、検収完了前の指定されたタイミング（例えば、納品後〇日、受注承認後〇日）で電子記録債権の発生記録請求を行えることを示す。

Ｓ１００１にて、情報処理装置１０は、バイヤー装置１２から、ある商品についての発注情報、すなわち、商品ＩＤ４０１、バイヤー（発注者）に関連付けられるユーザＩＤ３０１、サプライヤー（受注者）に関連付けられるユーザＩＤ３０１、発注数、単価、納期、および金額などの情報を受信する。情報処理装置１０は、取引ＩＤ５０１を生成し、受信した発注情報に基づいて、商品ＩＤ４０１、発注者ＩＤ５０２、発注情報５０３、および受注者ＩＤ５０５を受発注データ１０８にセットして受発注データを生成する。情報処理装置１０は、受発注データが生成されたことに応答して、受注者ＩＤ５０５に関連付けられるユーザのサプライヤー装置１１に対して発注があった旨を通知する。

Ｓ１００２にて、サプライヤーは、Ｓ１００１の発注内容を確認し、電子記録債権発行タイミングおよび受注承認したことを示す情報をサプライヤー装置１１に入力する。情報処理装置１０は、取引ＩＤ５０１に関連付けられた、電子記録債権発行タイミングおよび受注承認したことを示す情報をサプライヤー装置１１から受信する。情報処理装置１０は、電子記録債権発行タイミングおよび受注承認情報を受信したことに応答して、受発注データ１０８に格納されている対応する受発注データの受注情報５０６および電子記録債権発行タイミング５１１を更新する。電子記録債権発行タイミング５１１は、納品年月日の〇日後といった情報を示し得る。

Ｓ１００３にて、サプライヤーがバイヤーに当該商品を納品すると、情報処理装置１０は、納品情報、すなわち、納品年月日の情報をサプライヤー装置１１から受信し、受発注データ１０８の対応する受発注データの納品年月日５０７を更新する。本発明の一実施形態では、情報処理装置１０は、納品処理の際に、電子記録債権発行タイミングの情報を受信して対応する受発注データの電子記録債権発行タイミング５１１を更新するように構成されてもよい。

Ｓ１００４にて、情報処理装置１０は、納品年月日５０７が更新された受発注データの商品ＩＤ４０１、発注者ＩＤ５０２、受注者ＩＤ５０５、および電子記録債権発行タイミング５１１に基づいて早期割引率テーブル１１０に問い合わせを行い、割引率７０３の値を取得する。この処理により、サプライヤー（受注者）とバイヤー（発注者）の間で予め定められた電子記録債権の早期割引率のうち、サプライヤーが指定した電子記録債権発行タイミングの早期割引率が取得される。

Ｓ１００５にて、情報処理装置１０は、割引率７０３の値の取得に応答して、発注者ＩＤ５０２および受注者ＩＤ５０５を使用してユーザマスタ１０６に問い合わせを行い、バイヤーおよびサプライヤーのそれぞれのユーザ情報３０２および決済口座３０３の情報を取得する。情報処理装置１０は、発注情報５０３に格納されている情報（例えば、発注数と単価）と割引率７０３の値とに基づいて債権金額を算出する。

情報処理装置１０は、Ｓ１００４にて納品年月日５０７が更新された受発注データの取引ＩＤを取引ＩＤ５０１とし、取得したバイヤーの情報を債務者情報６０１とし、取得したサプライヤーの情報を債権者情報６０２とし、算出した債権金額を債権金額６０３とし、予め定められた支払期間から算出した支払期日を支払期日６０４として、発生記録請求データを生成し、生成した発生記録請求データを記録機関システム１３に送信するとともに、当該発生記録請求データを発生記録請求データ１０９に格納する。

Ｓ１００６にて、バイヤーが納品された商品を検収し終えると、バイヤーは、検収情報をバイヤー装置１２に入力する。情報処理装置１０は、検収情報、例えば、発注通りの納品が行われた、納期に遅れたが発注数通りの納品が行われた、納期は守られたが発注数よりも少ない数量の納品しかできなかった、などの納品情報、不良品率情報、および検収完了日の情報をバイヤー装置１２から受信し、受発注データ１０８の対応する受発注データの検収情報５０４を更新する。

Ｓ１００７にて、情報処理装置１０は、電子記録債権に関して実行された口座間送金決済に関する情報をサプライヤー装置１１および／またはバイヤー装置１２から受信する。口座間送金決済に関する情報は、例えば、債権金額通りの決済が行われた（弁済）、決済が完全にあるいは条件付きで行われなかった（債務不履行：履行不能、履行遅滞、不完全履行）などの情報を含むことができる。

上記では、図１０を参照しながら、納品後の指定タイミングで発生記録請求を行う実施形態を説明したが、第３の実施形態はこれに限定されず、納品前かつ受注承認後の指定タイミング（例えば、受注承認後〇日）で発生記録請求を行うようにしてもよい。かかる場合、電子記録債権発行タイミング５１１は、受注承認年月日の〇日後といった情報を示し得る。Ｓ１００３にて説明した動作は、Ｓ１００４およびＳ１００５の動作の後に行われる。

第３の実施形態では、サプライヤーとバイヤーの間で予め定められた早期割引率に基づいて、受注承認後や納品後などの検収完了前の指定タイミングで電子記録債権の発生記録請求を行えるため、従来技術や第１、第２の実施形態のフローよりも早期に電子記録債権の発生記録請求を行うことができるようになる。第３の実施形態は、サプライヤーが指定したタイミングで電子記録債権の割引を行うことが可能であるケースを説明している。なお、第３の実施形態で設定する割引率は、電子記録債権が通常通り発行された場合に任意の金融機関で割引してもらうよりも有利な割引率であってもよい。

第３の実施形態では、受発注プラットフォームと記録機関システム１３が自動連携されており、サプライヤーの指定タイミングで割引済みの電子記録債権の発生記録請求が記録機関システム１３に送信されるため、サプライヤーは回収資金が減ったとしても資金回収までの期間を大幅に短縮することができ、かつ人的ミスによるトラブルを極力減らすことができるようになる。また、サプライヤーは、後日、任意の金融機関で電子記録債権の割引を申し込む必要がなくなる。

（第４の実施形態）
図１１は、情報処理装置１０によって行われる受発注処理、電子記録債権の発生記録請求、および決済情報受信までの第４の実施形態の処理を説明するフロー図である。第４の実施形態は、同一のサプライヤーとバイヤーの間の同一商品の過去の取引における納品リスク（例えば、納期、数量、品質などの点におけるリスク）に基づいて自動的に保証金を計算して、保証金をサプライヤーの口座からプラットフォーム運営会社の口座に資金移動するとともに電子記録債権を早期発行し、検収結果に基づいて、保証金の全額または一部をサプライヤーに返還することを示す。

Ｓ１１０１にて、情報処理装置１０は、バイヤー装置１２から、ある商品についての発注情報、すなわち、商品ＩＤ４０１、バイヤー（発注者）に関連付けられるユーザＩＤ３０１、サプライヤー（受注者）に関連付けられるユーザＩＤ３０１、発注数、単価、納期、および金額などの情報を受信する。情報処理装置１０は、取引ＩＤ５０１を生成し、受信した発注情報に基づいて、商品ＩＤ４０１、発注者ＩＤ５０２、発注情報５０３、および受注者ＩＤ５０５を受発注データ１０８にセットして受発注データを生成する。情報処理装置１０は、受発注データが生成されたことに応答して、受注者ＩＤ５０５に関連付けられるユーザのサプライヤー装置１１に対して発注があった旨を通知する。

Ｓ１１０２にて、サプライヤーは、Ｓ１１０１の発注内容を確認し、保証金取引を希望する情報と受注承認したことを示す情報をサプライヤー装置１１に入力する。情報処理装置１０は、取引ＩＤ５０１に関連付けられた、保証金取引を希望する情報と受注承認したことを示す情報をサプライヤー装置１１から受信する。情報処理装置１０は、受注承認情報を受信したことに応答して、受発注データ１０８に格納されている対応する受発注データの受注情報５０６を更新する。

Ｓ１１０３にて、情報処理装置１０は、保証金取引を希望する情報を受信したことに応答して、更新された受発注データの商品ＩＤ４０１、発注者ＩＤ５０２、および受注者ＩＤ５０５に基づいて受発注データ１０８に問い合わせを行い、過去取引の受発注データを取得する。情報処理装置１０は、取得された過去取引の受発注データの検収情報５０４に含まれている納品情報と不良品率情報に基づいて、サプライヤーの納品リスクを判定する。納品リスクは、過去取引における欠品発生率や不良品率などの情報に基づいて予め定められた複数の閾値に基づいて判定される。例えば、納品リスクは、リスク小～リスク大を示す複数の段階で示されてもよく、それぞれの段階に応じて保証金の割合が決定されてよい。

情報処理装置１０は、判定されたサプライヤーの納品リスクに基づいて、保証金の割合を決定し、発注情報５０３に格納されている発注数および単価の情報と保証金の割合から保証金の額を算出し、保証金情報５０９に格納する。

情報処理装置１０は、受注者ＩＤ５０５に基づいてユーザマスタ１０６に問い合わせを行い、サプライヤーの決済口座３０３の情報を取得し、サプライヤーの口座からプラットフォーム運営会社の口座に算出した保証金の金額を資金移動する依頼電文をサプライヤーの口座が存在する金融機関の金融機関サーバ１４に送信する。金融機関サーバ１４は、依頼電文に従ってサプライヤーの口座からプラットフォーム運営会社の口座に算出した保証金の金額を資金移動する。

Ｓ１１０４にて、情報処理装置１０は、保証金の額を算出したことに応答して、発注者ＩＤ５０２および受注者ＩＤ５０５を使用してユーザマスタ１０６に問い合わせを行い、バイヤーおよびサプライヤーのそれぞれのユーザ情報３０２および決済口座３０３の情報を取得する。情報処理装置１０は、発注情報５０３に格納されている発注数および単価の情報に基づいて債権金額を算出する。

情報処理装置１０は、Ｓ１１０４にて保証金の額が算出された受発注データの取引ＩＤを取引ＩＤ５０１とし、取得したバイヤーの情報を債務者情報６０１とし、取得したサプライヤーの情報を債権者情報６０２とし、算出した債権金額を債権金額６０３とし、予め定められた支払期間から算出した支払期日を支払期日６０４として、発生記録請求データを生成し、生成した発生記録請求データを記録機関システム１３に送信するとともに、当該発生記録請求データを発生記録請求データ１０９に格納する。

Ｓ１１０５にて、サプライヤーがバイヤーに当該商品を納品すると、情報処理装置１０は、納品情報、すなわち、納品年月日の情報をサプライヤー装置１１から受信し、受発注データ１０８の対応する受発注データの納品年月日５０７を更新する。本発明の一実施形態では、情報処理装置１０は、Ｓ１１０３およびＳ１１０４の処理を納品処理の後に実行するように構成されてもよい。

Ｓ１１０６にて、バイヤーが納品された商品を検収し終えると、バイヤーは、検収情報をバイヤー装置１２に入力する。情報処理装置１０は、検収情報、例えば、発注通りの納品が行われた、納期に遅れたが発注数通りの納品が行われた（遅延）、納期は守られたが発注数よりも少ない数量の納品しかできなかった（欠品）、などの納品情報、不良品率情報、および検収完了日の情報をバイヤー装置１２から受信し、受発注データ１０８の対応する受発注データの検収情報５０４を更新する。

Ｓ１１０７にて、情報処理装置１０は、Ｓ１１０６にて受信した不良品率情報と、例えば、表１のような保証金返還割合テーブルによって予め定められた基準に基づいて保証金返還割合を決定する。表１の保証金返還割合テーブルの内容は、サプライヤーとバイヤーの間で取引される商品ごとに定められてよい。

情報処理装置１０は、保証金情報５０９に格納されている保証金の額と、決定された保証金返還割合とに基づいて保証金返還額を算出する。情報処理装置１０は、受注者ＩＤ５０５に基づいてユーザマスタ１０６に問い合わせを行い、サプライヤーの決済口座３０３の情報を取得し、プラットフォーム運営会社の口座からサプライヤーの口座に保証金返還額を資金移動する依頼電文をプラットフォーム運営会社の口座が存在する金融機関の金融機関サーバ１４に送信する。金融機関サーバ１４は、依頼電文に従ってプラットフォーム運営会社の口座からサプライヤーの口座に保証金返還額を資金移動する。

情報処理装置１０は、保証金情報５０９に格納されている保証金の額と、算出された保証金返還額に差異がある、すなわち、保証金残額がある場合、発注者ＩＤ５０２に基づいてユーザマスタ１０６に問い合わせを行い、バイヤーの決済口座３０３の情報を取得し、プラットフォーム運営会社の口座からバイヤーの口座に保証金残額を資金移動する依頼電文をプラットフォーム運営会社の口座が存在する金融機関の金融機関サーバ１４に送信する。金融機関サーバ１４は、依頼電文に従ってプラットフォーム運営会社の口座からバイヤーの口座に保証金残額を資金移動する。

Ｓ１１０８にて、情報処理装置１０は、電子記録債権に関して実行された口座間送金決済に関する情報をサプライヤー装置１１および／またはバイヤー装置１２から受信する。口座間送金決済に関する情報は、例えば、債権金額通りの決済が行われた（弁済）、決済が完全にあるいは条件付きで行われなかった（債務不履行：履行不能、履行遅滞、不完全履行）などの情報を含むことができる。

第４の実施形態では、同一のサプライヤーとバイヤーの間の同一商品の過去の取引における納品リスク（例えば、納期、数量、品質などの点におけるリスク）を算出して自動的に保証金を計算して預り金として確保しておくため、不良品率に応じてバイヤーに補填がなされるようになる。第４の実施形態では、バイヤーに対する補填のスキームが存在するため、納品の前あるいは納品の直後に電子記録債権の発生記録請求を行ったとしてもバイヤー側のリスクを抑えることができ、従来技術や第１の実施形態のフローよりも早期に、かつ安全性を高めた電子記録債権の発生記録請求を行うことができるようになる。

第４の実施形態では、受発注プラットフォームと記録機関システム１３が自動連携されており、納品の前あるいは納品の直後に電子記録債権の発生記録請求が記録機関システム１３に送信されるため、バイヤー側は保証金により取引リスクを抑えることができ、サプライヤー側は資金回収までの期間を第１の実施形態よりも大幅に短縮することができ、かつ人的ミスによるトラブルを極力減らすことができるようになる。

（第５の実施形態）
図１２は、情報処理装置１０によって行われる受発注処理、電子記録債権の発生記録請求、および決済情報受信までの第５の実施形態の処理を説明するフロー図である。第５の実施形態は、取引対象となる商品等ごとに予め設定された温室効果ガスの排出量に応じて、早期発行する電子記録債権の債権金額を可変にするスキームを示す。第５の実施形態は、温室効果ガスの排出量が閾値よりも多い場合には電子記録債権の早期発行を認めない、または一部しか早期発行を認めないスキームを示す。

Ｓ１２０１にて、情報処理装置１０は、バイヤー装置１２から、ある商品についての発注情報、すなわち、商品ＩＤ４０１、バイヤー（発注者）に関連付けられるユーザＩＤ３０１、サプライヤー（受注者）に関連付けられるユーザＩＤ３０１、発注数、単価、納期、および単価などの情報を受信する。情報処理装置１０は、取引ＩＤ５０１を生成し、受信した発注情報に基づいて、商品ＩＤ４０１、発注者ＩＤ５０２、発注情報５０３、および受注者ＩＤ５０５を受発注データ１０８にセットして受発注データを生成する。情報処理装置１０は、受発注データが生成されたことに応答して、受注者ＩＤ５０５に関連付けられるユーザのサプライヤー装置１１に対して発注があった旨を通知する。

Ｓ１２０２にて、サプライヤーは、Ｓ１２０１の発注内容を確認し、受注承認したことを示す情報をサプライヤー装置１１に入力する。情報処理装置１０は、取引ＩＤ５０１に関連付けられた、受注承認したことを示す情報をサプライヤー装置１１から受信する。情報処理装置１０は、受注承認情報を受信したことに応答して、商品マスタ１０７に問い合わせを行い、商品ＩＤ４０１に関連付けられる温室効果ガス排出量４０３の値を取得し、発注数量に基づいて今回の取引で発生する温室効果ガス排出総量を計算して、受発注データ１０８に格納されている対応する受発注データの受注情報５０６および温室効果ガス排出量５１０を更新する。

Ｓ１２０３にて、情報処理装置１０は、受発注データ１０８に格納されている対応する受発注データの温室効果ガス排出量５１０が更新されたことに応答して、更新された受発注データの温室効果ガス排出量５１０の値（排出総量）が予め定められた閾値以下であるかどうかを判定する。閾値は、商品ごとの特性、納入数量に応じて複数の閾値が用意されてよい。温室効果ガス排出量５１０の値が予め定められた閾値以下である場合には、Ｓ１２０４に処理が進み、電子記録債権の早期発行を行うことができる。一方、温室効果ガス排出量５１０の値が予め定められた閾値よりも大きい場合には、第１の実施形態で説明したＳ８０３～Ｓ８０６の処理が行われる。

Ｓ１２０４にて、情報処理装置１０は、温室効果ガス排出量５１０の値が予め定められた閾値以下であると判定したことに応答して、発注者ＩＤ５０２および受注者ＩＤ５０５を使用してユーザマスタ１０６に問い合わせを行い、バイヤーおよびサプライヤーのそれぞれのユーザ情報３０２および決済口座３０３の情報を取得する。情報処理装置１０は、発注情報５０３に格納されている発注数および単価の情報に基づいて債権金額を算出する。本発明の一実施形態では、情報処理装置１０は、温室効果ガス排出量５１０の値に応じて債権金額を段階的に可変させることができる。これは、温室効果ガス排出効果が高い商品ほどサプライヤーが受け取る債権金額が満額近くなり（すなわち、早期発行しても割引されない）、逆に、温室効果ガス排出効果が低い商品ほどサプライヤーが受け取る債権金額が割引されて低くなることを示す。

情報処理装置１０は、温室効果ガス排出量５１０が更新された受発注データの取引ＩＤを取引ＩＤ５０１とし、取得したバイヤーの情報を債務者情報６０１とし、取得したサプライヤーの情報を債権者情報６０２とし、算出した債権金額を債権金額６０３とし、予め定められた支払期間から算出した支払期日を支払期日６０４として、発生記録請求データを生成し、生成した発生記録請求データを記録機関システム１３に送信するとともに、当該発生記録請求データを発生記録請求データ１０９に格納する。

Ｓ１２０５にて、サプライヤーがバイヤーに当該商品を納品すると、情報処理装置１０は、納品情報、すなわち、納品年月日の情報をサプライヤー装置１１から受信し、受発注データ１０８の対応する受発注データの納品年月日５０７を更新する。本発明の一実施形態では、情報処理装置１０は、Ｓ１２０４の処理を納品処理の後に実行するように構成されてもよく、その場合には、債権金額の可変の程度を上述したものとは変更してもよい。

Ｓ１２０６にて、バイヤーが納品された商品を検収し終えると、バイヤーは、検収情報をバイヤー装置１２に入力する。情報処理装置１０は、検収情報、例えば、発注通りの納品が行われた、納期に遅れたが発注数通りの納品が行われた（遅延）、納期は守られたが発注数よりも少ない数量の納品しかできなかった（欠品）、などの納品情報、不良品率情報、および検収完了日の情報をバイヤー装置１２から受信し、受発注データ１０８の対応する受発注データの検収情報５０４を更新する。

Ｓ１２０７にて、情報処理装置１０は、電子記録債権に関して実行された口座間送金決済に関する情報をサプライヤー装置１１および／またはバイヤー装置１２から受信する。口座間送金決済に関する情報は、例えば、債権金額通りの決済が行われた（弁済）、決済が完全にあるいは条件付きで行われなかった（債務不履行：履行不能、履行遅滞、不完全履行）などの情報を含むことができる。

本発明の一実施形態では、Ｓ１２０３の判定処理にて複数の閾値を用いることにより、電子記録債権の早期発行を債権金額の全額で行う場合、電子記録債権の早期発行を債権金額の一部金額で行う場合、および早期発行を行わない場合に分けることも可能である。

第５の実施形態では、取引対象となる商品の温室効果ガス排出量に応じて、電子記録債権の早期発行および／または債権金額の段階的可変を可能とすることができる。第５の実施形態では、温室効果ガス排出効果が閾値よりも高い商品では電子記録債権の早期発行ができるため、従来技術や第１の実施形態のフローよりも早期に、かつ安全性を高めた電子記録債権の発生記録請求を行うことができるようになる。

第５の実施形態では、受発注プラットフォームと記録機関システム１３が自動連携されており、納品の前に電子記録債権の発生記録請求が記録機関システム１３に送信されるため、サプライヤー側は資金回収までの期間を第１の実施形態よりも大幅に短縮することができ、かつ人的ミスによるトラブルを極力減らすことができるようになる。

（まとめ）
従来技術では検収完了から電子記録債権発行までに相応の期間がかかっていたが、本発明では受発注情報を蓄積したプラットフォームと電子記録債権の記録機関とを自動連携することにより、納品前、納品後または検収終了直後の任意のタイミングで自動的に発生記録請求データを生成して送信することができるようになる。これにより、債務者（バイヤー）は、従来よりも早期に電子記録債権の受取が可能となり、債権者（サプライヤー）は資金効率の改善が可能になる。また、電子記録債権の発行者（債務者）は、従来行っていた検収後の締め作業や電子記録債権の発行作業の事務を大幅に削減することができるようになる。

従来、債権者（サプライヤー）が行っていた割引申込に係る事務作業についても、本発明では、最初から割引利用した電子記録債権を発行することができるようになるため、資金効率の改善に繋がるばかりでなく、事務作業の削減にも役立つ。

以上、例示的な実施形態を参照しながら本発明の原理を説明したが、本発明の要旨を逸脱することなく、構成および細部において変更する様々な実施形態を実現可能であることを当業者は理解するだろう。すなわち、本発明は、例えば、システム、装置、方法、プログラムもしくは記憶媒体等としての実施態様をとることが可能である。

１０ 情報処理装置
１１ サプライヤー装置
１２ バイヤー装置
１３ 記録機関システム
１４ 金融機関サーバ
１０１ 制御部
１０２ 主記憶部
１０３ 補助記憶部
１０４ インターフェース（ＩＦ）部
１０５ 出力部
１０６ ユーザマスタ
１０７ 商品マスタ
１０８ 受発注データ
１０９ 発生記録請求データ
１１０ 早期割引率テーブル

Claims (7)

1. 電子記録債権の自動発行および早期発行のために構成される情報処理装置であって、
   外部ネットワークと通信するための通信部、記憶部、および制御部を備え、
   前記制御部は、
   取引商品に対する検収情報を債権者装置から前記通信部を介して受信し、前記検収情報に基づいて前記記憶部の受発注データを更新するステップと、
   前記検収情報に基づいて前記記憶部の受発注データが更新されたことに応答して、前記受発注データに含まれる債権者ＩＤおよび債務者ＩＤのそれぞれに関連付けられる債権者情報および債務者情報を前記記憶部のユーザマスタから取得し、および前記受発注データに含まれる発注情報および前記検収情報に基づいて債権金額を算出するステップと、
   前記検収情報に基づいて前記記憶部の受発注データが更新されたことに応答して取得した前記債権者情報、前記債務者情報、算出した前記債権金額に基づいて発生記録請求データを生成し、検収完了後に記録機関システムにおいて前記発生記録請求データに関連付けられる電子記録債権を生成するために、前記生成した発生記録請求データを前記記録機関システムに送信するステップと
   を実行する情報処理装置。
2. 前記検収情報は、不良品率情報を含み、
   前記債権金額は、前記不良品率情報に基づいて算出される、
   請求項１の情報処理装置。
3. 前記検収情報は、納品情報をさらに含み、
   前記納品情報は、
   発注通りの納品が行われたこと、
   納期に遅れたが発注数通りの納品が行われたこと、または
   納期は守られたが発注数よりも少ない数量の納品しかできなかったこと
   を示す、請求項２の情報処理装置。
4. 電子記録債権の自動発行および早期発行のために構成される情報処理装置によって実行される情報処理方法であって、
   前記情報処理装置は、外部ネットワークと通信するための通信部、記憶部、および制御部を備え、前記情報処理方法は、
   前記制御部が、取引商品に対する検収情報を第１の装置から前記通信部を介して受信し、前記検収情報に基づいて前記記憶部の受発注データを更新するステップと、
   前記制御部が、前記検収情報に基づいて前記記憶部の受発注データが更新されたことに応答して、前記受発注データに含まれる債権者ＩＤおよび債務者ＩＤのそれぞれに関連付けられる債権者情報および債務者情報を前記記憶部のユーザマスタから取得し、および前記受発注データに含まれる発注情報および前記検収情報に基づいて債権金額を算出するステップと、
   前記制御部が、前記検収情報に基づいて前記記憶部の受発注データが更新されたことに応答して取得した前記債権者情報、前記債務者情報、算出した前記債権金額に基づいて発生記録請求データを生成し、検収完了後に記録機関システムにおいて前記発生記録請求データに関連付けられる電子記録債権を生成するために、前記生成した発生記録請求データを前記記録機関システムに送信するステップと
   を備える情報処理方法。
5. 前記検収情報は、不良品率情報を含み、
   前記債権金額は、前記不良品率情報に基づいて算出される、
   請求項４の情報処理方法。
6. 前記検収情報は、納品情報をさらに含み、
   前記納品情報は、
   発注通りの納品が行われたこと、
   納期に遅れたが発注数通りの納品が行われたこと、または
   納期は守られたが発注数よりも少ない数量の納品しかできなかったこと
   を示す、請求項５の情報処理方法。
7. 請求項４乃至６いずれか一項に記載の方法をコンピュータに実行させるためのプログラム。

Images