JP7461317B2 - 債権流通システムおよび債権流通方法 - Google Patents

Description

本発明は、債権流通システムおよび債権流通方法に関する。

昨今、製品を受注してから請求代金の受取りまでに多くの日数を費やす企業が多くある。これは一般的な商習慣として、月末締、翌月支払い等が行われているためであり、製品の生産過程において多額の資金が急遽必要となった場合、中小企業、資金面に余裕のない企業、不動産等の担保のない企業などの場合、銀行等の金融機関からの資金の借り受けが難しい場合がある。このような点に鑑み、例えば、特許文献１には、停止条件付き（抗弁付き）電子記録債権の譲渡担保差入れを管理する技術が開示されている。

ＷＯ２０１７／０３８６９６号公報

上記特許文献１では、あくまで融資を申し込む納入側の企業と発注側の企業との間で生じた受発注により債権を発生させることが前提となっているため、これらの当事者間で受発注が発生する前の状態では融資を受けることができない。

そこで、本発明は、当事者間で受発注が発生する前の状態でも融資を受けることが可能な技術を提供することを目的とする。

上記課題を解決し、目的を達成するために、本発明にかかる債権流通システムは、コンピュータが管理する債権流通システムであって、バイヤとサプライヤとにより行われた受発注履歴を示す受発注情報を記憶した受発注データベースと、前記受発注情報を読み出して、債権売却時に価格が確定していない債権である未確定債権の申請者であるサプライヤを起点とした、所定のサイクルにおける１または複数のサプライチェーンストリームが生成可能か否かを判定することにより、前記未確定債権を発生させるか否かを判定する未確定債権発生可否判定部と、前記未確定債権を発生させると判定した場合に、前記１または複数のサプライチェーンストリームをまとめたサプライチェーンネットワークにおいて、始点となるバイヤからサプライヤに発注されるルートの分岐数に基づいて、前記申請者であるサプライヤに対する資金化可能額を算出する資金化可能範囲判定部と、を有することを特徴とする債権流通システムとして構成される。

本発明によれば、当事者間で受発注が発生する前の状態でも融資を受けることができる。

本実施例における債権流通システム１０００の構成例を示す図である。 コンピュータ概略を示す図である。 債権管理システムおよび受発注履歴管理システムの機能的な構成の一例を示す図である。 受発注ＤＢの一例を示す図である。 未確定債権ＤＢの構成の一例を示す図である。 確定債権ＤＢの構成の一例を示す図である。 資金化履歴ＤＢの構成の一例を示す図である。 受注サイクルＤＢの構成の一例を示す図である。 債権流通システムで行われるメイン処理の処理手順を示すフローチャートである。 ＳＣストリーム検索処理の処理手順の一例を示すフローチャートである。 未確定債権発生可否判定部が生成したＳＣストリームの例を示す図である。 資金化算出処理の処理手順の一例を示すフローチャートである。 図１２に示した処理で資金化可能範囲となる資金化金額の算出例を説明するための図である。 サプライヤ端末の表示装置に表示される判定結果の例を示す図である。

以下、図面を参照して本発明の実施形態を説明する。以下の記載および図面は、本発明を説明するための例示であって、説明の明確化のため、適宜、省略および簡略化がなされている。本発明は、他の種々の形態でも実施する事が可能である。特に限定しない限り、各構成要素は単数でも複数でも構わない。

図面において示す各構成要素の位置、大きさ、形状、範囲などは、発明の理解を容易にするため、実際の位置、大きさ、形状、範囲などを表していない場合がある。このため、本発明は、必ずしも、図面に開示された位置、大きさ、形状、範囲などに限定されない。

以下の説明では、「データベース」、「テーブル」、「リスト」等の表現にて各種情報を説明することがあるが、各種情報は、これら以外のデータ構造で表現されていてもよい。データ構造に依存しないことを示すために「ＸＸテーブル」、「ＸＸリスト」等を「ＸＸ情報」と呼ぶことがある。識別情報について説明する際に、「識別情報」、「識別子」、「名」、「ＩＤ」、「番号」等の表現を用いた場合、これらについてはお互いに置換が可能である。

同一あるいは同様な機能を有する構成要素が複数ある場合には、同一の符号に異なる添字を付して説明する場合がある。ただし、これらの複数の構成要素を区別する必要がない場合には、添字を省略して説明する場合がある。

また、以下の説明では、プログラムを実行して行う処理を説明する場合があるが、プログラムは、プロセッサ（例えばＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）、ＧＰＵ（Ｇｒａｐｈｉｃｓ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ））によって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）および／またはインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主体がプロセッサとされてもよい。同様に、プログラムを実行して行う処理の主体が、プロセッサを有するコントローラ、装置、システム、計算機、ノードであってもよい。プログラムを実行して行う処理の主体は、演算部であれば良く、特定の処理を行う専用回路（例えばＦＰＧＡ（Ｆｉｅｌｄ－Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）やＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ））を含んでいてもよい。

プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサと配布対象のプログラムを記憶する記憶資源を含み、プログラム配布サーバのプロセッサが配布対象のプログラムを他の計算機に配布してもよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。

図１は、本実施例における債権流通システム１０００の構成例を示す図である。図１に示すように、債権流通システム１０００は、債権管理システム１００と、サプライヤ端末２００と、バイヤ端末３００と、受発注履歴管理システム４００とを有し、これらが一般的なネットワークＮを介して接続されている。

債権管理システム１００は、サプライチェーンに関する情報から未確定債権を発生させ、発生させた当該未確定債権に基づく資金化申請の可否を提示し、資金化を支援するためのシステムである。未確定債権とは、債権売却時に価格が確定していない債権であり、例えば、売掛発生前に発行され、将来的に価格が決まる未確定の債権が挙げられる。通常の債権売却では、金額が確定した確定債権を電子記録債権として金融機関に譲渡することで資金を得ることができるが、本実施例では、製品や部品、材料等の取引対象を発注する最初の段階から未確定債権として電子記録債権を発生させる。これにより、受注時点において金融の対象とすることを可能とし、更に、受注時から停止条件付きの電子記録債権を取り扱えるようになる。

「未確定債権」による資金調達は、金融機関等が提供する融資サービスの中でもＡＢＬ（Asset Based Lending）とＰＯ（Purchase Order）ファイナンスの間に位置するものであると定義することができる。ＡＢＬとは、動産/債権担保融資の事で、顧客の保有する在庫や売掛債権などの流動資産を担保して融資を行うものである。ＰＯファイナンスとは、注文書を担保に融資を受ける仕組みで、近年の電子記録債権の台頭とＥＤＩの連携によって普及が進められている。掛け取引を慣習とする多くの企業間では、受注後に請求書等の情報から売掛を手形化し、それを金融機関や消費者金融に割引（資金化）してもらうことによって資金調達を行う方法が有る。近年はその売掛手形が電子化され、電子記録債権として割引（債権譲渡融資）や、ファクタリング（債権売却）を行うことによって資金を確保している。未確定債権との違いを明示化する為、請求金額やその価格が確定していて割引対象である債権を「確定債権」とする。

しかしながら、従来の資金調達方法では、資金力のない企業は恒常的に受注が見込めるにも関わらず、発注情報や請求書が無ければ資金を調達できず運転資金が得られないまま黒字倒産しかねないという課題が有る。この課題を鑑み、以下では、恒常的に受注が見込めるサプライチェーン上に位置するサプライヤ企業が資金調達したい時、そのサプライヤ企業に直接受注がなくても、所属しているサプライチェーンの上流で受発注が発生したことを検知した場合に未確定債権を発生させることによって、資金調達の利便性を向上させることができる。金融機関では、融資を希望する中小企業を１社ずつ審査するのではなく、サプライチェーンの活動実績を利用して融資を実現することで、融資処理業務の効率向上を図ることができる。また、未確定債権という形で、仮にでも担保を設定しておくことができるため、償還を行う際の作業効率化を見込むことができる。

以下具体的に説明するが、本実施例における債権管理システム１００では、サプライチェーンの上流で発生した受発注情報から下流企業への受発注の発生を予測し、その予測結果を用いて未確定債権の発生可否を判断する。したがって、サプライチェーンの活動実態に即した未確定債権の発行可否を提示することができるようになる。債権管理システム１００の具体的な構成や債権管理システム１００で行われる具体的な処理については後述する。

サプライヤ端末２００は、バイヤ企業から注文を受けるサプライヤ企業に設けられた端末である。サプライヤ企業には、未確定債権の発生を申請し、当該未確定債権を売却して資金を得たい企業が含まれる。

バイヤ端末３００は、将来的にサプライヤ企業に発注を行う企業に設けられた端末である。バイヤ企業には、未確定債権の設定時に、期日までに上記資金を払う債務を負う債務者として、仮に設定される仮債務者となる企業が含まれる。

受発注履歴管理システム４００は、サプライヤ企業とバイヤ企業との間における受発注とその履歴を管理するシステムである。

金融機関端末５００は、上記未確定債権を買取る銀行等の金融機関や債権買取企業に設けられた端末である。金融機関端末５００は、個人投資家が有する端末であってもよい。

図１に示したこれらのシステムや端末は、例えば、図２（コンピュータ概略図）に示すような、ＣＰＵ１６０１と、メモリ１６０２と、ＨＤＤ(Ｈａｒｄ Ｄｉｓｋ Ｄｒｉｖｅ)等の外部記憶装置１６０３と、ＣＤ(Ｃｏｍｐａｃｔ Ｄｉｓｋ)やＵＳＢメモリ等の可搬性を有する記憶媒体１６０８に対して情報を読み書きする読書装置１６０７と、キーボードやマウス等の入力装置１６０６と、ディスプレイ等の出力装置１６０５と、通信ネットワークに接続するためのＮＩＣ(Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ)等の通信装置１６０４と、これらを連結するシステムバス等の内部通信線(システムバスという)１６０９と、を備えた一般的なコンピュータ１６００により実現できる。

各システムや装置に記憶され、あるいは処理に用いられる様々なデータは、ＣＰＵ１６０１がメモリ１６０２または外部記憶装置１６０３から読み出して利用することにより実現可能である。また、各システムや装置が有する各機能部（例えば、受発注履歴管理システム４００の受発注管理部４０１、債権管理システム１００のサプライチェーン分析部１０１、未確定債権発生可否判定部１０２、資金化可能範囲判定部１０３、未確定債権生成部１０４、残高確認部１０５、確定債権生成部１０６、資金化履歴管理部１０７）は、ＣＰＵ１６０１が外部記憶装置１６０３に記憶されている所定のプログラムをメモリ１６０２にロードして実行することにより実現可能である。

上述した所定のプログラムは、読書装置１６０７を介して記憶媒体１６０８から、あるいは、通信装置１６０４を介してネットワークから、外部記憶装置１６０３に記憶(ダウンロード)され、それから、メモリ１６０２上にロードされて、ＣＰＵ１６０１により実行されるようにしてもよい。また、読書装置１６０７を介して、記憶媒体１６０８から、あるいは通信装置１６０４を介してネットワークから、メモリ１６０２上に直接ロードされ、ＣＰＵ１６０１により実行されるようにしてもよい。

以下では、債権管理システム１００や受発注履歴管理システム４００が、ある１つのコンピュータにより構成される場合を例示するが、これらの機能の全部または一部が、クラウドのような１または複数のコンピュータに分散して設けられ、ネットワークを介して互いに通信することにより同様の機能を実現してもよい。

図３は、債権管理システム１００および受発注履歴管理システム４００の機能的な構成の一例を示す図である。図３では、図１に示したサプライヤ端末２００、バイヤ端末３００については省略している。まず、受発注履歴管理システム４００について説明する。

図３に示すように、受発注履歴管理システム４００は、受発注管理部４０１と、受発注データベース（以下、ＤＢ）４０２とを有している。受発注履歴管理システム４００は、サプライヤ企業とバイヤ企業との間における受発注および過去の受発注履歴を管理するシステムである。

受発注管理部４０１は、バイヤ企業によるサプライヤ企業への発注、サプライヤ企業におけるバイヤ企業からの受注を管理する。具体的には、受発注管理部４０１は、バイヤ端末３００から発注された発注情報と、サプライヤ端末２００が受注した受注情報とを対応付けた受発注情報を、受発注ＤＢ４０２に格納し、蓄積する。

図４は、受発注ＤＢ４０２の一例を示す図である。受発注ＤＢ４０２は、サプライヤ企業とバイヤ企業との間の受発注情報を記憶したデータベースである。図４に示すように、受発注ＤＢ４０２には、時系列に、製品や部品、材料等の取引対象の注文日と、注文を識別するための注文番号と、上記取引対象の発注者（バイヤ企業）と、上記取引対象の受注者（サプライヤ企業）と、受発注の金額とが対応付けて記憶されている。これらの項目は、受発注管理部４０１が、様々な形式で行われる企業間の受発注情報の中から抽出して格納される。図４では、例えば、８月１９日に、注文番号０４１で識別される、バイヤ企業Ｂ１は、サプライヤ企業Ａに対して金額２０００円の発注を行っている（言い換えると、サプライヤ企業Ａは、バイヤ企業Ｂ１から金額２０００円の受注を受けている）ことがわかる。図４で示されている受注日サイクルとは、あるバイヤ企業とあるサプライヤ企業との間で行われる受発注のサイクルである。受注日サイクルの具体的な説明については後述する。続いて、図３に戻り、債権管理システム１００について説明する。

図３に示すように、債権管理システム１００は、サプライチェーン分析部１０１と、未確定債権発生可否判定部１０２と、資金化可能範囲判定部１０３と、未確定債権生成部１０４と、残高確認部１０５と、確定債権生成部１０６と、資金化履歴管理部１０７と、未確定債権ＤＢ１０８と、確定債権ＤＢ１０９と、資金化履歴ＤＢ１１０と、受注サイクルＤＢ１１１とを有している。債権管理システム１００は、主に、受発注履歴管理システム４００の受発注ＤＢ４０２に格納されている受発注情報から得られるサプライチェーンストリームおよびサプライチェーンネットワーク（以下、それぞれ、ＳＣストリーム、ＳＣネットワーク）を用いて未確定債権の発生可否を判定し、発生可能と判定した未確定債権に基づく資金化可能金額を算出し、ユーザに提示する。

ＳＣストリームは、未確定債権に基づく資金化の申請者であるサプライヤ企業からみて直接的に受発注があるバイヤ企業のほか、さらに、当該バイヤ企業からみて直接的に受発注がある上位バイヤ企業（すなわち、上記サプライヤ企業からみて間接的に受発注があるバイヤ企業）…、のように、上記サプライヤ企業と直接的および間接的に受発注関係にある企業を繋げていった商流である。また、ＳＣネットワークは、ＳＣネットワークを構成するそれぞれのＳＣストリームの始点となる最上位のバイヤ企業からみて直接的に受発注があるサプライヤ企業のほか、さらに、当該サプライヤ企業からみて直接的に受発注がある下位サプライヤ企業（すなわち、上記バイヤ企業からみて間接的に受発注があるサプライヤ企業）…、のように、上記バイヤ企業と直接的および間接的に受発注関係にある企業を繋げていったネットワークである。上記始点となる最上位のバイヤ企業は、未確定債権に基づく資金化の申請者であるサプライヤ企業が属するＳＣストリームの上流に位置するバイヤ企業の中で、当該サプライヤ企業が最後に受注した日時を含む受注日サイクルよりも後の受注日サイクルに発注しているバイヤ企業であって、ＳＣストリーム上でサプライヤ企業から時間的に最も近い企業、と言い換えてもよい。

サプライチェーン分析部１０１は、未確定債権に基づく資金化の申請者であるサプライヤ端末２００からの処理要求に従って、受発注ＤＢ４０２に格納されている受発注情報を読み出して、未確定債権に基づいて資金化するための各種処理の実行指示等を行う。サプライチェーン分析部１０１が行う具体的な処理については、フローチャート（図９等）を用いて後述する。

未確定債権発生可否判定部１０２は、サプライチェーン分析部１００１が上記受発注情報を読み出すと、ＳＣストリームを生成し、ＳＣネットワークを定義する処理等を行う。未確定債権発生可否判定部１０２が行う具体的な処理については、フローチャート（図１０等）を用いて後述する。

資金化可能範囲判定部１０３は、未確定債権に基づく資金化の申請者であるサプライヤ企業が属するＳＣストリームの上流で受発注があるバイヤ企業があると判定された場合に、上記サプライヤ企業がバイヤ企業から過去に受注した金額と、当該バイヤ企業による上記サプライヤ企業への発注割合とにより定められる、未確定債権に基づく資金化可能範囲を算出する等の処理を行う。資金化可能範囲判定部１０３が行う具体的な処理については、フローチャート（図１２等）を用いて後述する。

未確定債権生成部１０４は、資金化可能範囲判定部１０３により資金化可能範囲が算出されると、その内容をサプライヤ端末２００に提示し、未確定債権ＤＢに登録する。未確定債権生成部１０４が行う具体的な処理については、フローチャート（図９等）を用いて後述する。

残高確認部１０５は、金融機関端末５００から、資金化履歴ＤＢ１１０に登録されている仮債務者についての資金化金額を資金化した旨の通知を受けると、資金化履歴ＤＢ１１０と確定債権ＤＢ１０９とを参照し、仮債務者から確定債務者となったバイヤ企業の確定債権金額から、未確定債権化され資金化済の金額を差し引き、確定債権の残高を算出し、確定債権ＤＢ１０９に登録する。残高確認部１０５が行う具体的な処理については、フローチャート（図９等）を用いて後述する。

確定債権生成部１０６は、資金化履歴ＤＢ１１０に格納されている債権者ごとに資金化金額を算出し、確定債権ＤＢ１０９の確定債権金額に登録する。確定債権生成部１０６が行う具体的な処理については、フローチャート（図９等）を用いて後述する。

資金化履歴管理部１０７は、サプライヤ企業が未確定債権に基づいて資金化を申請した金融機関の金融機関端末５００から、実際に資金化可能であると判断された資金化金額を受信すると、その資金化金額を含む資金化に関する情報を、資金化履歴情報として資金化履歴ＤＢ１１０に登録する。資金化履歴管理部１０７が行う具体的な処理については、フローチャート（図９等）を用いて後述する。

未確定債権ＤＢ１０８は、発生させた未確定債権に関する情報を蓄積するデータベースである。未確定債権ＤＢ１０８の具体的な構成については図５を用いて後述する。

確定債権ＤＢ１０９は、仮債務者から確定債務者となったバイヤ企業の確定債権金額や残高を含む確定債権に関する情報を蓄積するデータベースである。確定債権ＤＢ１０９の具体的な構成については図６を用いて後述する。

資金化履歴ＤＢ１１０は、未確定債権を資金化した履歴に関する資金化履歴情報を蓄積するデータベースである。資金化履歴ＤＢ１１０の具体的な構成については図７を用いて後述する。

受注サイクルＤＢ１１１は、注文の受注サイクルを格納したデータベースである。受注サイクルＤＢ１１１の具体的な構成については図８を用いて後述する。

図５は、未確定債権ＤＢ１０８の構成の一例を示す図である。図５に示すように、未確定債権ＤＢ１０８は、未確定債権を識別するための債権番号と、当該債権番号で識別される未確定債権の発生日と、当該未確定債権の消滅期限と、当該未確定債権の仮債務者と、当該未確定債権の債権者と、当該未確定債権の金額と、当該未確定債権の金額のうち資金化可能と判定された資金化可能額とが対応付けて記憶されている。図５では、例えば、債権番号１０１０１で識別される未確定債権は、資金化申請者であるサプライヤ企業Ａを債権者として、当該サプライヤ企業Ａと受発注関係があるバイヤ企業Ｂ１を仮債務者として設定され、未確定債権として２０００円の金額が設定されていることを示している。この金額は、当該サプライヤ企業Ａと受発注関係があるバイヤ企業Ｂ１との受発注履歴に基づいて定められる。また、当該金額に対して、後述する処理において資金化可能と判定された金額が１５００円であるとして設定されている。また、当該サプライヤ企業Ａに未確定債権の資金化候補を提示するための判定結果を表示した画面上で選択された日である８月２２日が、当該未確定債権の発生日として設定される。消滅期限は、受注サイクルＤＢ１１に記憶される受注日サイクルに基づいて定められる（例えば、受注日サイクルの終期である９月１９日）。

図６は、確定債権ＤＢ１０９の構成の一例を示す図である。図６に示すように、確定債権ＤＢ１０９は、確定債権を識別するための確定債権番号と、当該確定債権番号で識別される確定債権の発生日と、当該確定債権のもととなった注文を識別するための注文番号と、当該確定債権の金額と、当該確定債権の債権者と、当該確定債権の確定債務者と、当該確定債権の金額から上記資金化可能額を差し引いた金額である残高とが対応付けて記憶されている。図６では、例えば、確定債権番号２０１０１で識別される確定債権は、資金化申請者であるサプライヤ企業Ａを当該確定債権の債権者として、未確定債権から実際に資金化された資金化金額の合算値である２０００円が設定されている。また、未確定債権が資金化されたことにより確定債権となるため、未確定債権の消滅期限と同日である９月１９日に、発生日が設定されている。また、資金化された未確定債権を発生させる元となった受発注情報に含まれる注文番号が「０４３」として設定されている。さらに、仮債務者として設定されていたバイヤ企業Ｂ１の未確定債権が確定債権となったため、確定債務者として当該バイヤ企業Ｂ１が設定され、未だ確定していない未確定債権についての資金化金額が残高５００円として算出され、設定されている。

図７は、資金化履歴ＤＢ１１０の構成の一例を示す図である。図７に示すように、資金化履歴ＤＢ１１０は、資金化済みの未確定債権を識別するための資金化済未確定債権番号と、当該資金化済未確定債権番号で識別される未確定債権を資金化した資金化日と、当該未確定債権の消滅期限と、当該未確定債権を資金化した資金化金額と、当該未確定債権の債権者（および振込先情報）と、当該未確定債権の仮債務者とが対応付けて記憶されている。図７では、例えば、資金化済未確定債権番号１０１０１により識別される未確定債権は、８月３０日に、資金化申請者であるサプライヤ企業Ａによる申請に従って金融機関の金融機関端末５００により実際に資金化され、その旨の通知を受けたことを示している。また、当該未確定債権は、未確定債権ＤＢ１０８と同様、受注サイクルＤＢ１１に記憶される受注日サイクルに基づいて定められる９月１９日が消滅期限であることを示している。また、資金化申請に対して実際に資金化された金額は１５００円であり、債権者は申請者であるサプライヤ企業Ａ、仮債務者はＢ１として設定されている。振込先情報は、金融機関により設定される。

図８は、受注サイクルＤＢ１１１の構成の一例を示す図である。図８に示すように、受注サイクルＤＢ１１１は、受注サイクルを識別するためのサイクル管理番号と、当該サイクル管理番号で識別される受注サイクル（受注日サイクル）と、当該受注サイクルで発注する発注者および受注者と、当該発注および受注の金額とが対応付けて記憶されている。図８では、例えば、サイクル管理番号「１１」で識別される受注日サイクルは、バイヤ企業Ｅ１、サプライヤ企業Ｄ１とした金額１００００円の受発注の受注日サイクルであり、毎月２０日を１つのサイクルとしている。これらの項目はあらかじめ設定されているものとするが、受発注ＤＢ４０２を所定のタイミング（例えば、毎月末）で解析する等して、受注日サイクルの変更などを反映させてもよい。

続いて、債権流通システム１０００で行われる処理について説明する。図９は、債権流通システム１０００で行われるメイン処理の処理手順を示すフローチャートである。債権管理システム１００のサプライチェーン分析部１０１は、資金化申請者であるサプライヤ企業のサプライヤ端末２００から、未確定債権の生成・登録依頼を含む処理要求を受信する（Ｓ９０１）。

サプライチェーン分析部１０１は、上記サプライヤ端末２００から受信した処理要求に従って、受発注ＤＢ４０２に格納されている受発注情報を読み出す。処理要求には、当該サプライヤ企業の企業名等の識別情報が含まれる。サプライチェーン分析部１０１は、未確定債権発生可否判定部１０２に、処理要求したサプライヤ企業を始点とした上流の受発注情報を含むＳＣストリームを検索するＳＣストリーム検索処理を実行する指示をする（Ｓ９０２）。ＳＣストリーム検索処理の具体的な処理については後述する。

続いて、未確定債権発生可否判定部１０２は、上記ＳＣストリームで受発注があるバイヤ企業があるか否かを判定し（Ｓ９０３）、上記ＳＣストリームで受発注があるバイヤ企業がないと判定した場合（Ｓ９０３；Ｎｏ）、当該サプライヤ企業について未確定債権を発生させることができない旨を、サプライヤ端末２００に送信する（Ｓ９０４）。未確定債権を発生させることができない場合とは、例えば、未確定債権の発生を依頼したサプライヤ企業が、バイヤ企業と受発注がない場合、未確定債権の発生を依頼したタイミングでは始点となるバイヤ企業を特定できていない場合等である。

サプライチェーン分析部１０１は、上記ＳＣストリームで受発注があるバイヤ企業があると判定した場合（Ｓ９０３；Ｙｅｓ）、資金化可能範囲判定部１０３に、始点となるバイヤ企業から下流の受発注情報を含むＳＣネットワークを検索し、未確定債権に基づく資金化可能範囲および発注割合を算出する資金化算出処理を実行する指示をする（Ｓ９０５）。資金化算出処理の具体的な処理については後述する。

続いて、資金化可能範囲判定部１０３は、受発注情報から得られる過去の取引の金額に、Ｓ９０５で算出した資金化可能範囲および発注割合を適用し、Ｓ９０５で生成依頼された未確定債権に基づく資金化可能額を算出する（Ｓ９０６）。当該ステップの処理についても、資金化算出処理とともに後述する。

未確定債権生成部１０４は、Ｓ９０６までの処理が行われると、Ｓ９０１で処理要求したサプライヤ企業のサプライヤ端末２００に、未確定債権の資金化候補とその内容を示す判定結果を送信し、サプライヤ端末２００は、図示しないディスプレイ等の表示装置に、当該判定結果を表示する（Ｓ９０７）。判定結果を示す画面例については、図１４を用いて後述する。続いて、未確定債権生成部１０４は、上記判定結果が送信されたサプライヤ端末２００から選択された未確定債権に関する債権情報を、未確定債権ＤＢ１０８に登録する（Ｓ９０８）。

資金化履歴管理部１０７は、上記サプライヤ企業により、上記選択された未確定債権に関する債権情報に基づいて資金化を申請した金融機関の金融機関端末５００から、実際に資金化の申請が通った資金化金額、資金化日、仮債務者を含む資金化に関する情報を受信する。資金化履歴管理部１０７は、未確定債権ＤＢ１０８を参照して、受信した当該資金化に関する情報を、資金化履歴情報として資金化履歴ＤＢ１１０に登録する（Ｓ９０９）。

資金化した履歴に関する情報が資金化履歴ＤＢ１１０に登録されると、確定債権生成部１０６は、登録された資金化履歴ＤＢ１１０と、未確定債権ＤＢ１０８とを参照して、債権者ごとに、資金化履歴ＤＢ１１０に登録された資金化金額を算出し、当該債権者についての確定債権金額として、確定債権ＤＢ１０９に登録する（Ｓ９１０）。

そして、残高確認部１０５は、確定債権金額が登録されると、資金化履歴ＤＢ１１０を参照し、既に資金化された未確定債権の資金化金額を、Ｓ９１０で登録した確定債権金額から差し引いた金額を、残高として確定債権ＤＢ１０９に登録する。このとき、残高確認部１０５は、資金化履歴ＤＢ１１０に登録された仮債務者のなかから、資金化した仮債務者を除いた債務者を確定債務者として確定債権ＤＢ１０９に登録する（Ｓ９１１）。以上の処理により、図９に示した処理が終了する。

続いて、Ｓ９０２のＳＣストリーム検索処理について説明する。図１０は、ＳＣストリーム検索処理の処理手順の一例を示すフローチャートである。

図１０に示すように、未確定債権発生可否判定部１０２は、Ｓ９０２で読み出された受発注情報の中から、処理要求したサプライヤ企業（資金化申請者）が受注した履歴があるバイヤ企業を特定し、特定した当該バイヤ企業を含む受発注情報をリストアップする（Ｓ１００１）。

未確定債権発生可否判定部１０２は、上記受発注情報が抽出できたか否か、すなわちリストが空であるか否かを判定し（Ｓ１００２）、上記受発注情報が抽出できなかったと判定した場合（Ｓ１００２；Ｎｏ）、処理要求したサプライヤ企業がバイヤ企業からの受注実績がなく、ＳＣストリームに基づく未確定債権を発生させることができないと判断し、その旨を出力する（Ｓ１００３）。

一方、未確定債権発生可否判定部１０２は、上記受発注情報が抽出できたと判定した場合（Ｓ１００２；Ｙｅｓ）、Ｓ１００４～Ｓ１００９までの各処理を、リストアップした受発注情報に含まれるすべてのバイヤ企業について行う。

未確定債権発生可否判定部１０２は、リストアップした受発注情報と受注サイクルＤＢ１１１とから、バイヤ企業とサプライヤ企業の間の受注日サイクルを取得する（Ｓ１００５）。例えば、図４では、資金化申請者であるサプライヤ企業Ａはバイヤ企業Ｂ１およびＢ２から受注を受けており、図８では、サプライヤ企業Ａとバイヤ企業Ｂ１との間の受発日サイクルは毎月１９日（金額２０００円）、サプライヤ企業Ａとバイヤ企業Ｂ２との間の受発日サイクルは毎月１８日（金額２０００円）であることがわかる。

未確定債権発生可否判定部１０２は、受注日サイクルを取得したバイヤ企業がサプライヤ企業となり、当該受注日サイクル内で受注を受けている上流のバイヤ企業を特定し、特定した当該上流のバイヤ企業から受注を受けているか否かを判定する（Ｓ１００６）。例えば、バイヤ企業Ｂ１は、受注日サイクル内で上流のバイヤ企業Ｃ２から２０００円の受注を８月１５日に受けている。また、バイヤ企業Ｂ２は、受注日サイクル内で上流のバイヤ企業Ｃ２から２０００円の受注を８月１３日に受けている。したがって、この場合は、未確定債権発生可否判定部１０２は、受注日サイクルを取得したバイヤ企業が上流のバイヤ企業から受注を受けていると判定する（Ｓ１００６；Ｙｅｓ）。

未確定債権発生可否判定部１０２は、受注日サイクルを取得したバイヤ企業が上流のバイヤ企業から受注を受けていると判定した場合（Ｓ１００６；Ｙｅｓ）、そのバイヤ企業をサプライヤ企業とした受発注情報を、Ｓ９０１で読み出された受発注情報の中から読み出し、Ｓ１００１でリストアップしたリストに追加する（Ｓ１００８）。例えば、バイヤ企業Ｂ１がサプライヤ企業となって上流のバイヤ企業Ｃ１から８月１５日に受けた受発注情報を、Ｓ１００１でリストアップしたリストに追加する。同様に、バイヤ企業Ｂ２がサプライヤ企業となって上流のバイヤ企業Ｃ２から８月１３日に受けた受発注情報を、Ｓ１００１でリストアップしたリストに追加する。

未確定債権発生可否判定部１０２は、Ｓ１００８でこれらの受発注情報をＳ１００１でリストアップしたリストに追加すると、Ｓ１００５に戻り、以降の処理を繰り返す。例えば、Ｓ１００５において、資金化申請者であるサプライヤ企業Ａとバイヤ企業Ｂ１との間の受発日サイクル（毎月１９日）を取得し、さらにＳ１００６において、Ｓ１００８でリストに追加したバイヤ企業がサプライヤ企業となり、当該受注日サイクル内でさらに上流のバイヤ企業から受注を受けているか否かを判定する。例えば、バイヤ企業Ｃ１は、受注日サイクル内で上流のバイヤ企業Ｄ１から５０００円の受注を８月１１日に受けている。また、バイヤ企業Ｃ２は、受注日サイクル内で上流のバイヤ企業Ｄ１から５０００円の受注を８月１０日に受けている。さらに、バイヤ企業Ｃ２は、受注日サイクル内で上流のバイヤ企業Ｄ２から５０００円の受注を８月５日に受けている。したがって、この場合は、未確定債権発生可否判定部１０２は、上流のバイヤ企業さらに上流のバイヤ企業から受注を受けていると判定する（Ｓ１００６；Ｙｅｓ）。

未確定債権発生可否判定部１０２は、受注日サイクルを取得したバイヤ企業がさらに上流のバイヤ企業から受注を受けていると判定した場合（Ｓ１００６；Ｙｅｓ）、そのバイヤ企業をサプライヤ企業とした受発注情報を、Ｓ９０２で読み出された受発注情報の中から読み出し、Ｓ１００１でリストアップしたリストに追加する（Ｓ１００８）。例えば、バイヤ企業Ｃ１がサプライヤ企業となってさらに上流のバイヤ企業Ｄ１から８月１１日に受けた受発注情報を、Ｓ１００１でリストアップしたリストに追加する。同様に、バイヤ企業Ｃ２がサプライヤ企業となって上流のバイヤ企業Ｄ１から８月１０日に受けた受発注情報と、バイヤ企業Ｃ２がサプライヤ企業となって上流のバイヤ企業Ｄ２から８月５日に受けた受発注情報とを、Ｓ１００８で追加したリストにさらに追加する。そして、Ｓ１００５に戻り、以降の処理を繰り返す。

このように、未確定債権発生可否判定部１０２は、資金化申請者であるサプライヤ企業Ａと直接的に受発注関係にあるバイヤ企業Ｂ１およびバイヤ企業Ｂ２との間の受発日サイクル（この例では毎月１９日と毎月１８日のうち、より長い受注日サイクルである毎月１９日）以内で、サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業をリストアップする。

そして、未確定債権発生可否判定部１０２は、受注日サイクルを取得したバイヤ企業がさらに上流のバイヤ企業から受注を受けていないと判定した場合（Ｓ１００６；Ｎｏ）、当該受注日サイクル内でさらに上流のバイヤ企業は存在しないと判断し、その時点でリストアップされた受発注情報を読み出してＳＣストリームを生成し、ＳＣネットワークを定義する（Ｓ１００７、Ｓ１０１０）。例えば、未確定債権発生可否判定部１０２は、全てのバイヤ企業について、最後のＳ１００４～Ｓ１００９の繰り返しにおいてリストに追加された受発注情報に含まれるサプライヤ企業を最上位とし、資金化申請者であるサプライヤ企業Ａを最下位とするＳＣストリームを生成する。

このように、本実施例では、未確定債権発生可否判定部１０２は、起点となるサプライヤ企業と直接受発注があるバイヤ企業を特定する第１の特定処理（例えば、Ｓ１００１の処理）を行い、さらに、当該第１の特定処理で特定したバイヤ企業をサプライヤ企業として受発注がある上流のバイヤ企業を特定する第２の特定処理（例えば、Ｓ１００４～Ｓ１００９の処理）を行い、当該第２の特定処理を所定のサイクル（例えば、受注サイクルＤＢ１１１に記憶された受注日サイクル）内で繰り返し行うことにより、サプライチェーンストリームを生成する。したがって、資金化申請者であるサプライヤ企業が直接受注するバイヤ企業との間の受注日サイクルに応じて、未確定債権を資金化するためのサプライチェーンストリームを生成することができる。

図１１は、未確定債権発生可否判定部１０２が生成したＳＣストリームの例を示す図である。図１１では、図４に示した受発注ＤＢ４０２に格納されている受発注情報のうち、資金化申請者であるサプライヤ企業Ａとバイヤ企業Ｂ１との間の受発日サイクル（図８では毎月１９日）におけるＳＣストリームを示している。図１１に示すように、未確定債権発生可否判定部１０２は、図１０に示した処理を行うことにより、（１）未確定債権の申請者であるサプライヤ企業Ａを起点として、当該サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業Ｂ１、Ｃ１、Ｄ１から構成されるＳＣストリーム、（２）上記サプライヤ企業Ａを起点として、当該サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業Ｂ１、Ｃ２、Ｄ１から構成されるＳＣストリーム、（３）上記サプライヤ企業Ａを起点として、当該サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業Ｂ１、Ｃ２、Ｄ２から構成されるＳＣストリーム、（４）上記サプライヤ企業Ａを起点として、当該サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業Ｂ２、Ｃ２、Ｄ１から構成されるＳＣストリーム、（５）上記サプライヤ企業Ａを起点として、当該サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業Ｂ２、Ｃ２、Ｄ２から構成されるＳＣストリーム、（６）上記サプライヤ企業Ａを起点として、当該サプライヤ企業Ａと直接的または間接的に受発注があるバイヤ企業Ｂ２、Ｃ３、Ｄ２から構成されるＳＣストリーム、の計６つのＳＣストリームを生成する。そして、未確定債権発生可否判定部１０２は、資金化申請者であるサプライヤ企業Ａとバイヤ企業Ｂ１との間の受発日サイクル（毎月１９日）内で生成されたこれらのＳＣストリームをまとめて１つのＳＣネットワークとして定義する。

続いて、Ｓ９０５の資金化算出処理について説明する。図１２は、資金化算出処理の処理手順の一例を示すフローチャートである。以下では、ある１つの始点となるバイヤ企業について説明しているが、複数の始点となるバイヤ企業がある場合は、その各々について図１２の処理が行われる。

まず、資金化可能範囲判定部１０３は、始点となるバイヤ企業の発注先となるサプライヤ企業を、図１０でリストアップした受発注情報のリストの中から特定し、特定した当該サプライヤ企業を含む受発注情報をリストアップする（Ｓ１２０１）。本例では、図１０でリストアップした受発注情報のリストを用いたが、受発注ＤＢ４０２に格納されている受発注情報を用いてもよい。資金化可能範囲判定部１０３は、例えば、始点となるバイヤ企業Ｄ１からの発注ルートの分岐はサプライヤ企業Ｃ１、Ｃ２であるため、これらをリストアップする。

続いて、資金化可能範囲判定部１０３は、リストアップしたサプライヤ企業の数をカウントする（Ｓ１２０２）。例えば、資金化可能範囲判定部１０３は、発注ルートの分岐数は「２」であり、リストアップしたサプライヤ企業はＣ１、Ｃ２の２つであるため、サプライヤ企業の数を「２」とカウントする。

資金化可能範囲判定部１０３は、カウントしたサプライヤ企業の数に基づいて、バイヤ企業からの発注割合を算出する（Ｓ１２０３）。例えば、資金化可能範囲判定部１０３は、Ｓ１２０２ではサプライヤ企業の数を「２」とカウントしたため、発注割合を１／２ずつであると算出する。当該発注割合については、サプライヤ企業の事業規模や受注規模、受注頻度、市場リスク等の情報を外部のシステムからネットワークＮを介して取得し、当該取得した情報を用いて発注割合を按分して定めてもよい。

さらに、資金化可能範囲判定部１０３は、Ｓ１２０１でリストアップしたサプライヤ企業に、資金化申請者であるサプライヤ企業Ａが含まれているか否かを判定する（Ｓ１２０４）。資金化可能範囲判定部１０３は、Ｓ１２０１でリストアップしたサプライヤ企業に、資金化申請者であるサプライヤ企業Ａが含まれていないと判定した場合（Ｓ１２０４；Ｎｏ）、Ｓ１２０１でリストアップしたサプライヤ企業のそれぞれについて、さらに発注先となるサプライヤ企業を、図１０でリストアップした受発注情報のリストの中からリストアップし（Ｓ１２０５）、Ｓ１２０２に戻る。

Ｓ１２０２に戻ると、資金化可能範囲判定部１０３は、新たにＳ１２０５でリストアップしたサプライヤ企業の数をカウントし（Ｓ１２０２）、Ｓ１２０３において上記のように発注割合を算出する。資金化可能範囲判定部１０３は、これらの処理を、Ｓ１２０１でリストアップしたサプライヤ企業に、資金化申請者であるサプライヤ企業Ａが含まれていると判定するまで（Ｓ１２０４；Ｙｅｓ）、繰り返す。

資金化可能範囲判定部１０３は、Ｓ１２０１またはＳ１２０５でリストアップしたサプライヤ企業に、資金化申請者であるサプライヤ企業Ａが含まれていると判定した場合（Ｓ１２０４；Ｙｅｓ）、図１２に示す処理を終了する。

図１３は、図１２に示した処理で資金化可能範囲となる資金化金額の算出例を説明するための図である。図１３では、資金化申請者であるサプライヤ企業Ａは、バイヤ企業Ｂ１、Ｂ２から受注を受けており、受発注情報では、受注金額は、それぞれ２０００円であることがわかる。ここでは、バイヤ企業Ｄ１を始点としたＳＣネットワークを処理の対象とし、図１０の処理で生成したＳＣストリームにおいて、バイヤ企業Ｄ１を始点とするＳＣネットワークでは、当該バイヤ企業Ｄ１はサプライヤ企業Ｃ１、Ｃ２に発注していることがわかる。したがって、資金化可能範囲判定部１０３は、サプライヤ企業Ｃ１、Ｃ２が当該バイヤ企業Ｄ１から受注する確率である発注割合は１／２であるとして資金化可能範囲を設定する。

これと同様の考え方で、例えば、サプライヤ企業Ｃ１はサプライヤ企業Ｂ１に対するバイヤ企業であるため、当該バイヤ企業Ｃ１はサプライヤ企業Ｂ１以外への発注はない。このため、資金化可能範囲判定部１０３は、サプライヤ企業Ｂ１が当該バイヤ企業Ｃ１から受注する確率である発注割合は１／１であるとして資金化可能範囲を設定する。以下、資金化可能範囲判定部１０３は、資金化申請者であるサプライヤ企業Ａに到達するまで、同様の方法で発注割合を算出する。この例では、始点となるバイヤ企業Ｄ１からサプライヤ企業Ｂ１が受注する確率は、１／２×１／１（Ｄ１→Ｃ１→Ｂ１）と、１／２→１／２（Ｄ１→Ｃ２→Ｂ１）との和として表すことができる。したがって、資金化可能範囲判定部１０３は、上記サプライヤ企業Ａがバイヤ企業Ｂ１から受注する金額（２０００円）の３／４である１５００円（１０００円＋５００円）を資金化可能額とする。

これと同様の考え方で、始点となるバイヤ企業Ｄ１からサプライヤ企業Ｂ２が受注する確率は、１／２×１／２（Ｄ１→Ｃ２→Ｂ２）として表すことができる。したがって、資金化可能範囲判定部１０３は、上記サプライヤ企業Ａがバイヤ企業Ｂ２から受注する金額（２０００円）の１／４である５００円を資金化可能額とする。このように、資金化可能範囲および発注割合を算出し、資金化可能額を定めることにより、未確定債権に対する評価を、資金化申請者であるサプライヤ企業Ａの受発注実績に応じて適切に行うことができる。

このように、本実施例では、資金化可能範囲判定部１０３は、サプライチェーンネットワークの始点となるバイヤ企業と直接受発注があるサプライヤ企業を特定する第３の特定処理（例えば、Ｓ１２０１の処理）を行い、さらに、当該第３の特定処理で特定したサプライヤ企業をバイヤ企業として受発注がある下流のサプライヤ企業を特定する第４の特定処理（例えば、Ｓ１２０２～Ｓ１２０５の処理）を行い、当該第４の特定処理を資金化申請者であるサプライヤ企業に達するまで繰り返し行うことにより、資金化可能額を算出する。したがって、直接的であるか間接的であるかを問わず、資金化申請者であるサプライヤ企業の上流のバイヤ企業との過去の受発注の実績に基づいて、資金化可能額を算出できる。

資金化可能範囲判定部１０３が、Ｓ９０６において未確定債権に基づく資金化可能額を算出すると、サプライチェーン分析部１０１は、Ｓ９０２で処理要求したサプライヤ企業のサプライヤ端末２００に、未確定債権の資金化候補とその内容を示す判定結果を送信し、サプライヤ端末２００の表示装置に、当該判定結果を表示する。

図１４は、サプライヤ端末２００の表示装置に表示される判定結果の例を示す図である。図１４に示すように、サプライチェーン分析部１０１は、発生する未確定債権に対して直接的に受注関係があるバイヤ企業である仮債務者と、当該仮債務者から受注する予定金額（過去の受発注実績に基づいて定められる金額）と、上記発注割合と、上記資金化可能額とが対応付けた判定結果を出力する。図１４では、これまで説明したバイヤ企業Ｂ１、Ｂ２のほかに、これらと同様に発注割合や資金化可能額が算出された複数のバイヤ企業について、一覧形式で表示されている。当該判定結果では、どの未確定債権に基づいて資金化するかを選択するための資金化選択欄が、これらの情報に対応付けられている。したがって、資金化申請者であるサプライヤ企業Ａの担当者は、サプライヤ端末２００の表示装置に表示されている判定結果の中から選択した所望の未確定債権に基づいて資金化を申請することができる。図１４では、未確定債権を資金化する仮債務者として、バイヤ企業Ｂ１、Ｂ２のほかに、バイヤ企業Ｄ、Ｅ、Ｆが選択されていることがわかる。そして、Ｓ９０８で説明したように、未確定債権生成部１０４は、選択されたこれらの情報を、未確定債権に関する債権情報として、未確定債権ＤＢ１０８に登録する。その後、図９のＳ９０９～Ｓ９１１で説明したように、確定債権発生時には、資金化履歴ＤＢを参照して、残高分が確定債権としてされることとなる。

このように、本実施例では、コンピュータが管理する債権流通システム１０００において、バイヤ企業とサプライヤ企業とにより行われた受発注履歴を示す受発注情報を記憶した受発注ＤＢ４０２と、当該受発注情報を読み出して、債権売却時に価格が確定していない債権である未確定債権の申請者であるサプライヤ企業（例えば、サプライヤ企業Ａ）を起点とした、所定のサイクル（例えば、受注サイクルＤＢ１１１に記憶された受注日サイクル）における１または複数のサプライチェーンストリームが生成可能か否かを判定することにより、未確定債権を発生させるか否かを判定する未確定債権発生可否判定部１０２と、未確定債権を発生させると判定した場合に、１または複数のサプライチェーンストリームをまとめたサプライチェーンネットワークにおいて、始点となるバイヤ企業からサプライヤ企業に発注されるルートの分岐数に基づいて、上記申請者であるサプライヤ企業に対する資金化可能額を算出する資金化可能範囲判定部１０３と、を有するので、当事者間で実際に受発注が発生する前の状態でも融資を受けることができる。また、債権買取企業や金融機関、投資家にとっては、融資を行うか否かの判断を企業ごとで実施しなくてよくなるため、従来より多くの融資案件に対応できる。サプライチェーン上の発注機会の増減が可視化されるため、金融機関が投資先企業を容易に見つけることが可能となる。さらに、サプライチェーンを構成する様々な情報を考慮して、未確定債権の発行可否を判断できる。また、サプライチェーンにおける上流の受発注情報の発生を検知して、未確定債権の資金化でき、融資対象となる受発注とその支払いに充てる確定債権との紐づけを自動化できるようになる。

また、本実施例では、上述したようなサプライチェーン上の受発注履歴と受発注発生情報を利用して、あるバイヤ企業が売掛債権を発生させるより前に資金調達を行いたいサプライヤ企業が未確定債権を生成し、その未確定債権を金融機関に譲渡もしくは売却することによって資金調達を行うことが可能となる。そして、バイヤ企業の後日支払いによって未確定債権が消滅することを管理することができる。

１０００ 債権流通システム
１００ 債権管理システム
２００ サプライヤ端末
３００ バイヤ端末
４００ 受発注履歴管理システム
４０１ 受発注管理部
４０２ 受発注データベース
１０１ サプライチェーン分析部
１０２ 未確定債権発生可否判定部
１０３ 資金化可能範囲判定部
１０４ 未確定債権生成部
１０５ 残高確認部
１０６ 確定債権生成部
１０７ 資金化履歴管理部
１０８ 未確定債権ＤＢ
１０９ 確定債権ＤＢ
１１０ 資金化履歴ＤＢ
１１１ 受注サイクルＤＢ
Ｎ ネットワーク

Claims (6)

1. コンピュータが管理する債権流通システムであって、
   バイヤとサプライヤとにより行われた受発注履歴を示す受発注情報を記憶した受発注データベースと、
   前記受発注情報を読み出して、債権売却時に価格が確定していない債権である未確定債権の申請者であるサプライヤを起点とした、所定のサイクルにおける１または複数のサプライチェーンストリームが生成可能か否かを判定することにより、前記未確定債権を発生させるか否かを判定する未確定債権発生可否判定部と、
   前記未確定債権を発生させると判定した場合に、前記１または複数のサプライチェーンストリームをまとめたサプライチェーンネットワークにおいて、始点となるバイヤからサプライヤに発注されるルートの分岐数に基づいて、前記申請者であるサプライヤに対する資金化可能額を算出する資金化可能範囲判定部と、
   を有することを特徴とする債権流通システム。
2. 前記未確定債権発生可否判定部は、起点となるサプライヤと直接受発注があるバイヤを特定する第１の特定処理を行い、さらに、当該第１の特定処理で特定したバイヤをサプライヤとして受発注がある上流のバイヤを特定する第２の特定処理を行い、当該第２の特定処理を前記所定のサイクル内で繰り返し行うことにより、前記サプライチェーンストリームを生成する、
   ことを特徴とする請求項１に記載の債権流通システム。
3. 前記資金化可能範囲判定部は、前記サプライチェーンネットワークの始点となるバイヤと直接受発注があるサプライヤを特定する第３の特定処理を行い、さらに、当該第３の特定処理で特定したサプライヤをバイヤとして受発注がある下流のサプライヤを特定する第４の特定処理を行い、当該第４の特定処理を前記申請者であるサプライヤに達するまで繰り返し行うことにより、前記資金化可能額を算出する、
   ことを特徴とする請求項１に記載の債権流通システム。
4. コンピュータが管理する債権流通システムで行われる債権流通方法であって、
   未確定債権発生可否判定部が、受発注データベースに格納された、バイヤとサプライヤとにより行われた受発注履歴を示す受発注情報を読み出して、債権売却時に価格が確定していない債権である未確定債権の申請者であるサプライヤを起点とした、所定のサイクルにおける１または複数のサプライチェーンストリームが生成可能か否かを判定することにより、前記未確定債権を発生させるか否かを判定し、
   資金化可能範囲判定部が、前記未確定債権を発生させると判定した場合に、前記１または複数のサプライチェーンストリームをまとめたサプライチェーンネットワークにおいて、始点となるバイヤからサプライヤに発注されるルートの分岐数に基づいて、前記申請者であるサプライヤに対する資金化可能額を算出する、
   を有することを特徴とする債権流通方法。
5. 前記未確定債権発生可否判定部は、起点となるサプライヤと直接受発注があるバイヤを特定する第１の特定処理を行い、さらに、当該第１の特定処理で特定したバイヤをサプライヤとして受発注がある上流のバイヤを特定する第２の特定処理を行い、当該第２の特定処理を前記所定のサイクル内で繰り返し行うことにより、前記サプライチェーンストリームを生成する、
   ことを特徴とする請求項４に記載の債権流通方法。
6. 前記資金化可能範囲判定部は、前記サプライチェーンネットワークの始点となるバイヤと直接受発注があるサプライヤを特定する第３の特定処理を行い、さらに、当該第３の特定処理で特定したサプライヤをバイヤとして受発注がある下流のサプライヤを特定する第４の特定処理を行い、当該第４の特定処理を前記申請者であるサプライヤに達するまで繰り返し行うことにより、前記資金化可能額を算出する、
   ことを特徴とする請求項４に記載の債権流通方法。

Images