(57)【要約】【課題】  生鮮商品の取引のような比較的小口の取引がほぼ毎日多数なされる業態に適して、先払い処理の事務作業にかかる手間とコストを低減でき、かつ先払いに伴うトラブルが生じにくい方法等を提供する。【解決手段】  サーバーが、商品の複数の売掛債権に基づいて商品売り手に対する先払い処理を行う方法であって、スケジュール管理手段が、あらかじめ定められた短周期のスケジュールに従って定期的に先払い処理の開始を先払い処理手段に命令するステップと、先払い処理手段が、短周期の一つにおいて発生した１または２以上の売掛債権を、売掛債権テーブルを検索して特定するステップと、特定された売掛債権に係わる先払い金額の合計を演算するステップと、合計の先払い金額を含む先払い命令を出力するステップとを含む。【選択図】  図３
2007025849.tif 000002
【特許請求の範囲】
【請求項１】
サーバーが、商品の複数の売掛債権に基づいて前記商品の売り手に対する先払い処理を行うための方法であって、スケジュール管理手段が、あらかじめ定められた短周期のスケジュールに従って定期的に先払い処理の開始を先払い処理手段に命令するステップと、前記先払い処理手段が、前記先払い命令に従って、前記短周期の一つにおいて発生した１または２以上の売掛債権を、複数の売掛債権情報が格納された売掛債権テーブルを検索して特定するステップと、前記先払い処理手段が、前記特定された売掛債権に係わる先払い金額の合計を演算するステップと、前記先払い処理手段が、前記合計の先払い金額を含む先払い命令を出力するステップとを含んでなることを特徴とする方法。
【請求項２】
さらに、前記スケジュール管理手段が、あらかじめ定められた長周期のスケジュールに従って定期的に後払い処理の開始を後払い処理手段に命令するステップを含み、前記後払い処理手段が、前記後払い命令に従って、前記長周期の一つにおいて発生した１または２以上の売掛債権を前記売掛債権テーブルを検索して特定するステップと、前記後払い処理手段が、前記特定された売掛債権から当該売掛債権に係わる先払い金額を減じて後払い金額の合計を演算するステップと、前記後払い処理手段が、前記合計の後払い金額を含む後払い命令を出力するステップとを含んでなることを特徴とする請求項１に記載の方法。
【請求項３】
さらに、前記スケジュール管理手段が、前記商品の買い手があらかじめ定めた債務支払いスケジュールに従って定期的に買い手支払い確認処理の開始を入金照合処理手段に命令するステップと、前記スケジュール管理手段が、あらかじめ定められた長周期のスケジュールに従って定期的に後払い処理の開始を後払い処理手段に命令するステップと、
前記入金照合処理手段が、前記確認処理の開始命令に従って、あらかじめ定めた期間内の前記売掛債権情報に対応する買い手支払い情報を、複数の買い手支払い情報が格納された買い手支払いテーブルを検索して特定するステップと、前記入金照合処理手段が、前記売掛債権情報と前記特定された買い手支払い情報とを照合するステップと、
前記後払い処理手段が、前記後払い処理開始命令に従って、前記長周期の一つにおいて発生した１または２以上の売掛債権を前記売掛債権テーブルを検索するステップと、前記後払い処理手段が、前記検索された売掛債権のうち、前記照合の結果が合致と判定された１または２以上の売掛債権を特定するステップと、前記後払い処理手段が、当該特定された売掛債権に係わる先払い金額を減じて後払い金額の合計を演算するステップと、前記後払い処理手段が、前記演算された合計金額を含む後払い命令を出力するステップとを含んでなることを特徴とする請求項１に記載の方法。
【請求項４】
前記短周期が日数単位または週単位であり、前記長周期が月単位であることを特徴とする請求項２または３に記載の方法。
【請求項５】
さらに、情報受付手段が、前記売り手端末から前記商品の複数の出荷情報を随時受信して出荷情報テーブルに格納するステップと、前記情報受付手段が、前記商品の買い手端末から前記商品の複数の受領情報を受信して受領情報テーブルに格納するステップと、前記先払い処理手段が、前記出荷情報と当該出荷情報に対応する前記受領情報とを読み出して照合し、前記出荷情報と前記対応受領情報とが合致した場合に、前記出荷情報または前記対応受領情報を前記売掛債権テーブルに格納するステップとを含むことを特徴とする請求項１から４のいずれかに記載の方法。
【請求項６】
前記商品が、短期間に商品価値が変動する生鮮商品であることを特徴とする請求項１から５のいずれかに記載の方法。
【請求項７】
前記生鮮商品が青果物であることを特徴とする請求項１から６のいずれかに記載の方法。
【請求項８】
商品の複数の売掛債権に基づいて前記商品の売り手に対する先払い処理を行うためのサーバーであって、あらかじめ定められた短周期のスケジュールに従って定期的に先払い処理の開始を先払い処理手段に命令するスケジュール管理手段と、前記先払い命令に従って先払い処理を実行する先払い処理手段とを備え、前記先払い処理手段は、前記短周期の一つにおいて発生した１または２以上の売掛債権を、複数の売掛債権情報が格納された売掛債権テーブルを検索して特定する手段と、前記特定された売掛債権に係わる先払い金額の合計を演算する手段と、前記合計の先払い金額を含む先払い命令を出力する手段とを備えてなるものであることを特徴とするサーバー。
【請求項９】
商品売り手端末と商品買い手端末と商品債権支払会社端末とが、請求項８に記載のサーバーと通信可能に接続されていることを特徴とするファクタリングシステム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、商品取引で生じた売掛債権に基づき、買い手による実際の支払いが行われるより前に、債権支払会社が先払いを行うための方法等に関する。特に、毎日、比較的小口の多数の取引が行われる業態において、先払い及び精算を連続的かつ安全に行うのに適した方法等に関する。
【背景技術】
【０００２】
最近、手形割引と同じようにして、商品取引で生じた比較的大口の売掛債権に基づき、買い手による実際の支払いが行われるより前に、個別に先払いを行ういわゆるファクタリングが行われるようになってきた。債権者は、ファクタリングを行う債権支払会社に対し、先払いを希望する売掛債権を個別に特定して先払い依頼する。その際、債権支払会社の債権回収に伴うリスクを低減するために、手形同様に売掛債権の内容が確定している必要がある。依頼を受けた債権支払い会社は、売掛債権ごとに債権譲渡を受け、引き替えにファクタリング手数料を差し引いた額を債権者に先払いする。これにより、債権者は、手数料を負担するものの、債権回収の時期が早くなって資金繰りが楽になるメリットがある。
【０００３】
ファクタリングを行うためのシステム例としては、介護保険制度に対応した新しい資金調達方法を可能にすることを目的として、介護事業者の有する介護報酬債権（売掛債権）ごとに所定の掛け目（７〜８割）を乗じてこれを上限額として前払いし、しかるのち期日に債務者から支払いが行われた際にその額に応じて未払い分を支払うようにして、債権ごとに個別に精算するシステムが開示されている（特許文献１参照）。このシステムでは、介護報酬債権の一つ一つを手形と同様に個別に取扱って、先払いの申し込み時にレセプトの写し等に従って先払いを行い、しかるのち買い手の支払いスケジュールに従って後払いを行っている。
【０００４】
ところで、個々の商品取引は比較的少額であるが、毎日多数の取引が行われるような業態では、一つ一つの売掛債権が比較的小口でしかも多数発生する。例えば、野菜や果物のような青果物、花、苗木等のごとき生鮮商品では、熟化や腐敗等により日や週という短い単位で商品価値が大きく変動する。そのため、生鮮商品の生産者は、生産物の収穫期における天候状況、行事日程や市場価格等を考慮しながら市場に出荷する生産物の数量を日ごとに定め、卸業者や仲卸業者等は、小売店（量販店）からの毎日の注文に応じて、各地に散在する生産者等が出荷できる数量の生産物をできるだけ集積して、要求された商品の数量と品質とを確保するようにしている。つまり、比較的小口の商品取引が毎日多数行われる必要がある。そのため、手形と同様な支払いの事務処理を行おうとすると、多大な事務処理の手間とコストを要することになる。
【０００５】
さらに、生鮮商品は輸送時の打撲等による商品の傷みが生じやすいうえ、生産者の都合により納品された商品の品質が注文と異なっていることもあり、出荷時の債権額が検収後に変更されることも珍しくない。さらに、通常の支払いの事務処理がなされる時点では、多くの場合に商品はすでに廃棄または消費されて消滅しており、事後的に売掛債権額を検証するのは困難である。これらのため、このような業態における個々の売掛債権と手形とでは、その確実さに大きな差異がある。
【０００６】
すなわち、上記のような業態において手形割引と同様にしてファクタリングを行おうとすると、毎日の取引の多さに伴う事務作業が繁雑であり、個々の取引の金額がしばしば変更されるために債権額が不確実であり、商品が短期間で変質または消滅してしまうことによる事後的な確認が困難である等の問題点があり、ファクタリングを行う債権支払会社は多大な作業コストと回収リスクを負うことになってしまう。さらには、季節により商品が交代するから、各商品の生産者との取引が継続的に有るとは限らず、支払残や過払いが生じた場合に精算が遅れることになりかねない。また、取引のない期間中に生産者の信用状態が変化することもあり、この点でも債権支払会社にリスクが生じやすい。
【０００７】
ここで、債権譲渡前には買い手と売り手の間で売掛債権額が確定しておらず、将来的に確定する商品の取引を支援するシステム等も開示されている。具体的には、取引される商品の暫定取引額に基づいて売掛債権の評価額を決定し、買い手と売り手の事後の合意により商品の実取引額が確定したときに取引額を買い手または売り手から連絡してもらい、いずれかに基づいて実取引額と評価額との差分金額を算出し、差分金額を売り手に対する今後の売掛債権の買取り又は融資に用いるシステムが開示されている（特許文献２参照）。
【０００８】
このシステムでも個々の売掛債権は、原則として手形と同様に各別に取り扱われており、債権支払会社の負う作業コストと回収リスクの問題は解消されない。さらに、評価額と実取引額との差額が生じた場合に、その差額は、その後に適当な取引や融資がなされるまで精算されないままであり、精算された場合でもいずれの取引等で精算されたかがわかりにくくトラブルになりやすい。特に多数の取引が錯綜する上記の生鮮商品取引のような業態では問題を生じやすい。また、連絡された実取引額が正しいか否かを事後的に検証することもできないから、売り手等による先払い金の詐取等が意図された場合に、それを防止するのは困難である。
【特許文献１】特開２００２−５６１９９号公報
【特許文献２】特開２００３−９１６５６号公報
【発明の開示】
【発明が解決しようとする課題】
【０００９】
本発明は、生鮮商品の取引のような比較的小口の取引がほぼ毎日多数なされる業態に適して、先払い処理の事務作業にかかる手間とコストを低減でき、かつ先払いに伴うトラブルが生じにくい方法、ファクタリングシステムまたはそのためのサーバーを提供することを課題とする。好ましくは、上記のごとき業態において、ファクタリングを行う債権支払会社が負担すべきリスクが低減される方法等を提供することを課題とする。
【課題を解決するための手段】
【００１０】
本発明の第１は、サーバーが、商品の複数の売掛債権に基づいて前記商品の売り手に対する先払い処理を行うための方法であって、スケジュール管理手段が、あらかじめ定められた短周期のスケジュールに従って定期的に先払い処理の開始を先払い処理手段に命令するステップと、前記先払い処理手段が、前記先払い命令に従って、前記短周期の一つにおいて発生した１または２以上の売掛債権を、複数の売掛債権情報が格納された売掛債権テーブルを検索して特定するステップと、前記先払い処理手段が、前記特定された売掛債権に係わる先払い金額の合計を演算するステップと、前記先払い処理手段が、前記合計の先払い金額を含む先払い命令を出力するステップとを含んでなることを特徴とする方法である。
【００１１】
ここで、さらに、前記スケジュール管理手段が、あらかじめ定められた長周期のスケジュールに従って定期的に後払い処理の開始を後払い処理手段に命令するステップを含み、前記後払い処理手段が、前記後払い命令に従って、前記長周期の一つにおいて発生した１または２以上の売掛債権を前記売掛債権テーブルを検索して特定するステップと、前記後払い処理手段が、前記特定された売掛債権から当該売掛債権に係わる先払い金額を減じて後払い金額の合計を演算するステップと、前記後払い処理手段が、前記合計の後払い金額を含む後払い命令を出力するステップとを含んでなることは好ましい。
【００１２】
また、さらに、前記スケジュール管理手段が、前記商品の買い手があらかじめ定めた債務支払いスケジュールに従って定期的に買い手支払い確認処理の開始を入金照合処理手段に命令するステップと、前記スケジュール管理手段が、あらかじめ定められた長周期のスケジュールに従って定期的に後払い処理の開始を後払い処理手段に命令するステップと、前記入金照合処理手段が、前記確認処理の開始命令に従って、あらかじめ定めた期間内の前記売掛債権情報に対応する買い手支払い情報を、複数の買い手支払い情報が格納された買い手支払いテーブルを検索して特定するステップと、前記入金照合処理手段が、前記売掛債権情報と前記特定された買い手支払い情報とを照合するステップと、前記後払い処理手段が、前記後払い処理開始命令に従って、前記長周期の一つにおいて発生した１または２以上の売掛債権を前記売掛債権テーブルを検索するステップと、前記後払い処理手段が、前記検索された売掛債権のうち、前記照合の結果が合致と判定された１または２以上の売掛債権を特定するステップと、前記後払い処理手段が、当該特定された売掛債権に係わる先払い金額を減じて後払い金額の合計を演算するステップと、前記後払い処理手段が、前記演算された合計金額を含む後払い命令を出力するステップとを含んでなることは好ましい。
【００１３】
また、前記短周期が日数単位または週単位であり、前記長周期が月単位であることは好ましい。また、さらに、情報受付手段が、前記売り手端末から前記商品の複数の出荷情報を随時受信して出荷情報テーブルに格納するステップと、前記情報受付手段が、前記商品の買い手端末から前記商品の複数の受領情報を受信して受領情報テーブルに格納するステップと、前記先払い処理手段が、前記出荷情報と当該出荷情報に対応する前記受領情報とを読み出して照合し、前記出荷情報と前記対応受領情報とが合致した場合に、前記出荷情報または前記対応受領情報を前記売掛債権テーブルに格納するステップとを含むことは好ましい。また、前記商品が、短期間に商品価値が変動する生鮮商品であることは好ましい。また、生鮮商品が青果物であることは好ましい。
【００１４】
発明の第２は、商品の複数の売掛債権に基づいて前記商品の売り手に対する先払い処理を行うためのサーバーであって、あらかじめ定められた短周期のスケジュールに従って定期的に先払い処理の開始を先払い処理手段に命令するスケジュール管理手段と、前記先払い命令に従って先払い処理を実行する先払い処理手段とを備え、前記先払い処理手段は、前記短周期の一つにおいて発生した１または２以上の売掛債権を、複数の売掛債権情報が格納された売掛債権テーブルを検索して特定する手段と、前記特定された売掛債権に係わる先払い金額の合計を演算する手段と、前記合計の先払い金額を含む先払い命令を出力する手段とを備えてなるものであることを特徴とするサーバーである。
【００１５】
発明の第３は、商品売り手端末と商品買い手端末と商品債権支払会社端末とが、上記のサーバーと通信可能に接続されていることを特徴とするファクタリングシステムである。
【発明の効果】
【００１６】
生鮮商品の取引のような比較的小口の取引がほぼ毎日多数なされる業態に適して、債権支払会社に多大な事務処理の手間やコストを発生させることなく、多数の売掛債権に対して連続的に、かつ確実なファクタリングが行える。
【発明を実施するための最良の形態】
【００１７】
以下、本発明の実施例を図面を参照しながら説明する。まず、図１と図２は、本発明の方法を実施する場合の具体的処理を時間軸に沿って示したものである。図１は先払い処理を示したものであり、図２は後払い処理を示したものである。なお、ファクタリングシステム内の情報の移動は実線の矢印で示し、システム外の商品等の移動は破線の矢印で示した。まず、これらを用いて全体の概要を説明する。いずれも登場するのは商品の売り手１と買い手３、ファクタリング処理を行うサーバー５と、売掛債権の先払いを行う債権支払会社６である。なお、売り手１、買い手３、債権支払会社６には、電話回線、ＬＡＮまたはインターネット等の通信手段を介して、サーバー５と通信可能に接続されたそれぞれの端末２、４、７が備えられ、これらでファクタリングシステムが構成されている（図４）。
【００１８】
図１では、買い手と売り手の間に４月１日以降に発生した取引を例として、先払いのために行われる処理を上から下に時系列に従って並べている。なお、理解を容易にするため、買い手と売り手が共に単数の例で示しているが、実際には買い手と売り手は共に複数である。
【００１９】
まず、４月１日付けで買い手が売り手に対して、どの商品をどれだけの個数買うかを発注し、合わせて発注番号を連絡する。この発注は、サーバー５と端末２、４を介して行うのが好ましいが（Ａ１、Ａ２）、発注番号を明示して買い手が売り手に何らかの手段で直接連絡しても良い。すると、売り手は、該当する商品を用意して翌４月２日付けで買い手に対して出荷Ａ３を行い、出荷伝票に従って商品を出荷した旨が売り手端末２に入力され、売り手端末２は通信回線を介してサーバー５に出荷情報Ａ５を送信する。出荷情報には、発注番号、売り手、買い手、納品店舗名称、納品日、商品名、単価、取扱単位、出荷個数、出荷日付、出荷金額等が含まれている。出荷情報を受信したサーバー５は、出荷情報を所定のテーブルに格納する。
【００２０】
売り手１から出荷された商品は、この例では当日のうちに買い手３に到着し、直ちに黒丸で示された検収が行われて、出荷情報が記載されて買い手受領印が押印された受領伝票及び、受領伝票に対応する納品伝票が発行される。押印された受領伝票は随時売り手１に戻される（Ａ４）。買い手３により、この例ではその日に、買い手端末４に商品を受領した旨が納品伝票に従って入力され、買い手端末４は、通信回線を介してサーバー５に受領情報Ａ６を送信する。受領情報Ａ６を受信したサーバー５は、受領情報Ａ６を所定のテーブルに格納する。
【００２１】
同様にして、４月２日付けでも発注がなされて４月３日に出荷・受領がなされ、以下同様にして、ほぼ毎日のように商品取引が繰り返される。このようにして４月１日から５日までの５日間分の取引が行われる。すると、４月８日にはこの５日間に成立した取引について、まとめて売り手１への先払い処理が行われる。４月５日から８日まで間隔を空けているのは、受領情報が必ずしも受領後直ちに送られるとは限らず、多くの場合、時間をおいて五月雨式にバラバラに送られてくることから、できるだけ多くの受領情報を受信した後に照合処理を行うためである。なお、売り手１が買い手３以外の複数の買い手との間に、同じ期間のうちに１または２以上の取引がある場合も、それらの取引が先払い対象である限り、買い手３との取引と同様にしてまとめて売り手１ら対して先払い処理される。このように、あらかじめ定めた期間のうちに発生した商品取引に関して、まとめて先払い処理を行うので、サーバー処理及び売り手の事務処理の負担が軽減される。
【００２２】
先払い処理は、以下のようにして行う。まず、サーバー５が４月１日から５日までの５日間のうちに売り手端末４から随時受信した出荷情報を所定のテーブルから読み出し、続いて、各出荷情報に出荷伝票番号が対応する受領情報を、受領情報を集積した所定のテーブルから検索して読み出す。続いて、サーバー５は各出荷情報とそれに対応する受領情報とを照合する。照合は、納品日、納品店舗名称、伝票番号、合計金額に関して行われ、これらが合致するか否かで判断する。いずれも合致する場合には正しく取引がなされたと判断できるから、先払い可能とする。このように、出荷情報と受領情報とを随時蓄積して、各出荷情報とそれに対応する受領情報とを逐一照合するので、先払い金の過払いや詐取などが生じるおそれが小さい。なお、いずれかが合致しない場合は取引内容の確認が必要であり、その出荷情報と受領情報はサーバー５のプリンタからプリントアウトされて、実際の受領伝票との照合作業を手作業等で行うことができる。
【００２３】
サーバー５は、５日間の出荷伝票の全部について照合処理が終了したら、合致したものについての合計金額を演算し、続いて、債権支払会社の所定の手数料を減じてから、所定の先払い率が乗じて実際の先払い金額を演算する。先払い率を乗じるのは、買い手への納品後の店舗陳列段階になって商品に不良品が発見され、売掛債権額がさらに変動する場合があることを考慮したものである。先払い率は、売り手ごとまたは売り手の商品ごとの過去の実績に基づいて、あらかじめ定めておけばよい。
【００２４】
このようにして先払い金額が定められると、サーバー５は、債権支払会社６の端末７に対して、先払いの対象者である売り手１に対して前記の金額の先払いを行えとの先払い命令Ａ８を送信する。先払い命令には、命令送信日、先払い指定日（例えば５日後の４／１０）、先払い対象者、支払口座、先払い金額等が含まれている。先払い命令Ａ８を端末７で受信した債権支払会社６は、先払い指定日である４月１０付けで、売り手の口座に対して先払い処理Ａ９を行う。先払い処理Ａ９は、売り手の商品取引が継続的に行われている限り、あらかじめ定められた日数、例えば５日ごとに連続的に行われることになる。
【００２５】
この５日間が先払いが行われる短周期の例となる。短周期は、売り手ごとに先払い処理が繰り返される周期であり、通常の毎月末に行われる支払いより短い数日から２週間程度の範囲であらかじめ定める。売り手は、先払いによりある程度まとまった金額を入手でき、かつ先払いを受けるための事務処理が煩雑にならない程度の適当な好ましい期間を選び、サーバー５の所定のテーブルにあらかじめ登録しておけばよい。従って、短周期は、数日から十数日程度の任意の日数を単位とするか、または週を単位として毎週先払いが行われる等のようにすればよい。
【００２６】
その際、出荷情報と受領情報とを照合して、照合済みの取引に関してのみ先払い処理を行うことで、売り手の不正な操作等が例えなされたとしても、先払い金の詐取等が困難になり、手形割引のように債権一つ一つに対して厳格な取扱をせずともある程度の確実さを担保することが可能となる。また、出荷伝票と受領伝票とを、出荷情報と受領情報の裏付けとして用いることができるから、事後的に取引内容を確認することが可能となり、先払い処理に伴うトラブルの発生を可能な限り防止できる。さらに商品の評価額等を定める必要がないので、先払い処理が簡単で過払いも生じにくい。そのため、債権支払会社の先払い処理に伴うリスクが大幅に軽減される。
【００２７】
このように、手形割引の場合の割引依頼日のような個々の売掛債権ごとに定まる日に基づいて個別に先払い事務処理を行うのではなく、あらかじめ定めた一定期間（短周期）ごとに自律的に処理を行い、その間に発生した複数の売掛債権に対してまとめて先払い処理を行う。そして、この先払い処理を短周期ごとに繰り返し行うことで、連続的または定期的に処理を行う。これにより、生鮮商品取引のような比較的小口の債権がほぼ毎日発生するような業態においても、先払いに伴う支払い側及び売り手側の事務処理負担を軽減することができる。
【００２８】
ところで、出荷受領照合のタイミングは、上記のように５日分をまとめて行っても良いし、毎日、前日以前に受信した未照合の受領情報に関して行うようにしても良い。この場合、照合済みの受領情報には照合済みのフラグを立てて、先払い処理の際に照合済みフラグの立っている受領情報を検索するようにすればよい。さらには、受領情報を受信するたびに随時、出荷受領照合を行うのでも良い。
【００２９】
続いて、図２について説明する。図２は、後払い処理の時系列に沿った流れを図１と同様にして示した図である。後払い処理とは、買い手の債務支払いを確認した後に行う売掛債権の精算処理である。買い手の支払いは、多くの場合、月末締めの翌月１５日支払いや月末支払い等であるから、このあとに後払い処理を行うのがよい。ここでは１５日支払いの例で説明する。
【００３０】
後払い処理を行うのは、先払いだけで売掛債権額の全額が支払われるわけではないこと、また、サーバーによる照合処理の結果、何らかの不一致があった場合も原則として先払いはなされないことなどから、支払いがなされた分に関しての精算を行うのが好ましいためである。このようにすることで、複数の取引が合算されて処理されるものの、各取引の精算が後払いで完結するから、事後的な確認作業も簡単になる。また、後払いは、上で説明した短周期よりも長い長周期で繰り返して行う。この長周期は、買い手の大多数の支払いサイクルに対応して月単位とするのが好ましい。つまり、毎月、売り手ごとに定めた日に後払い処理を行うように定めておくのがよい。売り手の要望等により、より長い周期とするのは任意である。ここでは１月を長周期とする例で説明する。
【００３１】
後払い処理は、この例では以下のようにして行っている。まず、買い手端末４が、月初め（図２では５／１）になると先月分の受領情報を売り手ごとに集計して月末締め処理を行う。サーバー５が、一定期間内の複数の受領情報を売り手ごとにまとめた支払い請求のための請求情報を買い手端末４に送信している場合は、受信した請求情報を集計するのが良い。次いで、支払日（図２では５／１５）に、買い手３は、債権支払会社の口座に対して先月中に購入した商品の代金を支払い（Ａ１０）、買い手端末４は、支払済み情報Ａ１１をサーバー５に送信する。支払い済み情報Ａ１１には、支払日、支払金額、買い手、支払い対象となった１または２以上の出荷伝票番号が含まれる。サーバー５は、買い手端末４から支払い済み情報Ａ１１を受信すると、所定のテーブルに格納する。
【００３２】
その後、サーバー５は、売り手１が希望する後払いスケジュールに従って、精算のための後払い処理を開始する。図２は、支払い済み情報Ａ１１受信後の５月１８日に後払い処理を行っている例である。サーバー５は、売り手１の一定期間の出荷情報のうち、後払い処理がなされていないものを検索し、買い手の支払いがなされていることを確認した後で、先払い金額と手数料とを減じて後払い金額を演算する。続いて、対象期間内に後払い対象となる複数の売り手の取引がある場合は、それらの後払い金額を合計して手数料などを減じて合計後払い金額を演算してから、債権支払会社６の端末７に対して売り手１への後払い命令Ａ１２を送信する。後払い命令には、命令送信日、後払い指定日（例えば５／２０）、後払い対象者、支払口座情報、合計後払い金額等が含まれている。後払いの内容は所定のテーブルに格納される。
【００３３】
債権支払会社６の端末７が後払い命令Ａ１２を受信すると、債権支払会社６は、後払い命令に従って、指定日に売り手１の指定口座に対して後払い金額の支払いを行う。これで対象となった１または２以上の取引の精算処理が終了する。
【００３４】
なお、上記の流れには、サーバー５のプリンタ４３から支払い等に不適格とされた情報が、プリンタ４３からプリントアウトされるステップが複数箇所存在している。大多数の取引は、サーバー５により適格と判断されて自動処理される一方、不適格とされた情報に関しては、随時サーバーサイドの人間がアナログ的に対処して、買い手と売り手が合意した情報をサーバーに修正入力すればよい。
【００３５】
このようにして、出荷情報と受領情報との照合を元にして、複数の売掛債権をまとめて、短周期で次々と繰り返し先払い処理を行い、その後、買い手の実支払いがなされた後に、売掛債権の残額の後払い処理を長周期で繰り返し行う。このようにすることで、生鮮商品の取引のごとき比較的小口で多数行われる取引に対応可能となり、先払い側や売り手側の事務処理の手間やコストを増大させることなく、的確に先払い処理を行うことが可能になる。
【００３６】
その際、先払いの根拠となる出荷情報と受領情報には、それぞれ出荷伝票と押印された受領伝票の裏付けがあるから、仮に商品内容や金額等の入力間違いなどの問題が生じたとしても、事後的に正しい内容を確定することができる。また、比較的少数の不適格情報に係わる取引に関しては、サーバーによる自動処理から弾きだして別途に対処可能とすることで、先払い金の過払いや詐取等が生じにくく、債権支払会社にとって先払い処理のリスクを比較的小さい範囲に留めることが可能になる。
【００３７】
図３は、三ヶ月間（４月〜６月）を例として、買い手２から債権支払会社６への代金支払いＡ１０（太い矢印）と、債権支払会社６から売り手１への先払いＡ９（細い矢印）と、債権支払会社６から売り手１への後払いＡ１３（中太の矢印）の、時間的な関係を示した図である。先払いＡ９が、買い手の代金支払いＡ１０前に１週間程度の短周期で次々と連続的に行われており、各月の１５日に買い手の先月分の代金支払いＡ１０がなされると、その直後に後払いＡ１３がなされている。その結果、後払いＡ１３は、買い手の支払いパターンに合わせた長周期でなされていることがわかる。なお、図３では、後払いＡ１３が先払いＡ９と異なるタイミングで（異日）行われるように示されているが、同日であっても良いのは言うまでもない。返品などのために後払いで過払いが生じる場合には、後払いを先払いと同日に行うようにするのが好ましい。同日の先払いで過払い分を直ちに相殺できるからである。
【００３８】
次に、図４は、図１〜３とは観点を変えて時間軸をなくし、１回の商品取引の発注から支払い完了までの全部に着目することで、売り手１、買い手３、サーバー５及び債権支払会社６間の情報及び商品等の移動の概略を示した図である。ファクタリングシステムは、サーバー５が、売り手端末２と買い手端末４と債権支払会社端末７とに通信可能に接続されて構成されている。なお、図１、２と同様に、ファクタリングシステム内の情報の移動を実線の矢印で示し、システム外の商品等の移動を破線の矢印で示している。また、図４では簡単のために売り手と買い手とがそれぞれ単数で示しているが、実際はいずれも複数である。
【００３９】
買い手端末４が商品の発注情報Ａ１をサーバー５に送信すると、サーバー５は発注情報を所定のテーブルに格納すると共に、売り手端末２に対して発注情報Ａ２として送信する。発注情報Ａ２を受信した売り手１は、注文された商品を用意して納品伝票と共に買い手３に対して発送する（Ａ３）。さらに出荷した旨の出荷情報Ａ５が売り手端末２からサーバー５へ送信される。サーバー５は、出荷情報Ａ５を受信すると所定のテーブルに格納する。商品が買い手の指定した店舗等に到着すると、買い手３により検収印が押印された受領伝票が発行され、受領伝票は適宜売り手１に返送される（Ａ４）。また、商品を受領した旨の受領情報Ａ６が買い手端末４からサーバー５に送信される。サーバー５は、受領情報Ａ６を受信すると所定のテーブルに格納する。
【００４０】
サーバー５は、売り手１が希望する先払いスケジュールに従って、先に受信した出荷情報と受領情報とを照合し、両者が合致する場合に先払い金額を演算し、債権支払会社端末７に対して、売り手１に先払い金額を支払えとの先払い命令Ａ８を送信する。両者が合致しない場合は先払い命令Ａ８は送信されない。先払い命令Ａ８を端末７で受信した債権支払会社６は、売り手１の指定口座に先払い金額を支払う（Ａ９）。
【００４１】
また、サーバー５は、受領情報Ａ６に基づいて、買い手３の支払いスケジュールに合わせて買い手端末４に対して商品代金を支払えとの請求情報Ａ７を送信し、合わせて請求情報Ａ７を所定のテーブルに格納する。請求情報Ａ７を端末４で受信して買い手３は、請求情報Ａ７に従って債権支払会社６に商品代金を支払う（Ａ１０）。合わせて買い手端末４から代金の支払い済み情報Ａ１１が、サーバー５に送信される。サーバー５は支払い済み情報Ａ１１を受信すると所定のテーブルに格納する。サーバー５は、買い手３の支払いスケジュールにより、買い手３に対する請求情報Ａ７と支払い済み情報Ａ１１とを照合し、両者が合致した場合に、買い手の支払いが完了した旨を所定のテーブルに格納する。
【００４２】
サーバー５は、売り手１が希望する後払いスケジュールに従って、買い手３の代金支払いが完了していることを確認したのち、代金から先払い金額等を減じて後払い金額を演算し、売り手３に対して後払い金額を支払えとの後払い命令Ａ１２を債権支払会社端末７に送信する。後払い命令Ａ１２を端末７が受信すると、債権支払会社６は、後払い金額を売り手１の口座に支払う。これで、１回の商品取引に関する処理が完了する。
【００４３】
このように、出荷情報、受領情報を初めとする各種の情報が、ファクタリングシステムを介して、売り手１、買い手３、債権支払会社６にそれぞれ流されると、サーバー５で全部の情報を一元的に管理できる。また、受領伝票等の伝票の裏付けがとれる情報を入力するようにしているため、出荷情報と受領情報、請求情報と支払い済み情報をそれぞれ照合することが可能となる。これらのため、債権支払会社の過払いや先払い金の詐取等のトラブルが生じにくい。つまり債権支払会社の先払いリスクが低減される。
【００４４】
次に、図５は、ファクタリングシステムのサーバー５を制御面から見た概略構成を示した図である。サーバー５は、各種データ類、テーブル類及びコンピュータプログラムを格納した複数のハードディスクから構成される記憶部２０と、ＣＰＵとＲＡＭとから構成され、記憶部２０から読み出されたコンピュータプログラムやデータを用いてデータ処理を行う処理部１０と、サーバー５を通信回線に接続する通信インターフェイス４０と、キーボードやマウス等の入力装置４１と、液晶ディスプレイやＣＲＴのごときディスプレイ４２と、情報を紙出力するプリンタ４３とが、図示されない必要なインターフェイスを介するなどして、共通バスで接続されている。
【００４５】
サーバー５の記憶部２０には、図５に記載されたような売り手情報テーブル２１や後払い記録テーブル３４等の各種のテーブルと、サーバー５を動作させるコンピュータプログラム類、ディスプレイ表示のためのプログラム類、その他の必要なデータ類が格納されている。また、処理部１０では、必要なプログラム等をＲＡＭに読み込むことで、サーバー５に、端末から送信される各情報を受け付けて所定のテーブルに格納させるための情報入力受付機能を発揮させる情報受付部１１、サーバー５に各種処理に関するスケジュール管理機能を発揮させるスケジュール管理部１２等（以下の処理部に関しても同様）の、それぞれの機能を発揮させるための図５に図示された各処理部１３〜１６を備える。
【００４６】
まず、記憶部２０のテーブル類について説明する。まず、売り手情報テーブル２１は、ファクタリングシステムにとって、商品を売る立場の者（売り手）を特定するためのテーブルであり、この例を図６に示す。売り手としては、例えば、青果物の生産農家、各地の農業協同組合、仲卸業者等が該当する。売り手情報テーブル２１には、売り手名称や売り手コード等の他、売り手が先払い処理を受けることができる売り手であるか否か、また先払い処理を受けられるとして、売り手が希望する先払い条件、例えば、先払い開始日、先払い間隔（何日ごとに先払いを受けたいか。）を含む。ここにいう先払い間隔が上記で説明した短周期に該当し、先払い開始日が最初に短周期をスタートする日を特定する。さらに、売り手が希望する後払い条件、例えば、長周期を１月とした場合の後払い処理の毎月の締め日や後払い日のデータ、または長周期の開始日と長周期の間隔日数のデータ等を含む。
【００４７】
このように、売り手ごとに異なる先払いや後払いの条件を希望する場合であっても、あらかじめ売り手情報テーブル等にそれらの条件を登録しておくことができ、それらに基づいた柔軟な先払い処理等を行うことができる。そのため、売り手は、先払い側や買い手側の一方的な都合に振り回されることなく、柔軟に資金調達することが可能となる。
【００４８】
売り手口座テーブル２２は、売り手ごとに用意されたテーブルであり、この例を図７に示す。このテーブルには、商品の出荷や先払いや後払い等の取引日ごとに、それらの取引種別、各取引によって発生した債権額、売り手に支払われた金額、取引日の２４時における売り手の債権の合計残額のデータが格納されている。この売り手口座テーブル２２は、出荷や支払い等が生じるごとにデータが格納され、債権残額のデータは、商品出荷により新たな債権が発生した場合はその債権額だけ増加し、支払いによって債権が消滅した場合は、その支払額及び支払いの手数料及び消費税分だけ減少する。このような売り手口座テーブルを設けることにより、毎日の比較的小口の商品取引が複数発生し、一定の日数ごとにその間の取引に関してまとめて先払いが行われ、かつその後にまとめて定期的に後払い精算が行われるような複雑な取引形態であっても、売り手ごとに商品と対応した収支が明確にできるから、支払い漏れや請求漏れが生じた場合にチェックが容易で、直ちに問題箇所を発見することが可能になる。
【００４９】
買い手情報テーブル２３は、ファクタリングシステムにとって、商品を買う立場の者（買い手）を特定するためのテーブルであり、この例を図８に示す。買い手としては、例えば、百貨店、コンビニ、スーパー等の小売り量販店、生産者に対する仲卸業者等が該当する。買い手情報テーブル２３には、買い手名称等の買い手を特定するデータの他、商品を配送する買い手の店舗名称、各買い手の店舗データを格納したテーブルを特定する店舗テーブルコード、さらに買い手の支払い条件、例えば、支払いの締め日、各月の支払日等のデータが格納されている。
【００５０】
商品情報テーブル２４は、商品ごとに、商品名称、コード、産地、梱包単位、梱包数、品質、熟度等のデータを格納し、商品を特定すると共に商品取引に必要な梱包単位のデータを格納したテーブルである。なお、取扱商品は特に限定されないが、好ましい商品は、日単位や週単位長くとも月単位で品質が変化する生鮮商品であり、具体的には、野菜や果物のような青果物、花、苗木、鮮魚、または鶏肉のようなチルドで扱われる生肉等である。これらのごとき商品のファクタリング処理において、債権支払会社のリスクが高くなることによる。最も好ましい取扱商品は、品質変化速度が大きい青果物である。
【００５１】
発注記録テーブル２５は、サーバー５が受信した発注情報Ａ１を随時格納したテーブルであり、買い手ごとに設けられている。発注記録テーブルの例を図９に示す。このテーブルは、発注伝票番号ごとに、発注日、売り手名称、納入希望日、納入希望店舗名称、１または２以上の商品名とコード、商品の個数、商品の単価、商品ごとの金額、合計金額等の発注伝票に記載される情報が格納されている。
【００５２】
出荷記録テーブル２６は、サーバー５が受信した出荷情報Ａ５を随時格納したテーブルであり、売り手ごとに設けられている。出荷記録テーブルの例を図１０に示す。このテーブルは、売り手の出荷伝票に含まれる情報、出荷伝票番号、出荷日、発注伝票番号、納品日、買い手名称、納入店舗名称、商品名称、個数、単価、出荷合計金額等と同等な情報を格納している。さらに、このテーブルは、サーバー５での処理に必要なフラグの有無も格納している。具体的には、当該出荷により発生した債権に対する先払いが終了していることを意味する先払い済みフラグの有無、同様に後払いが終了していることを意味する後払いフラグの有無等を格納している。このように、出荷伝票に記載されている情報と同等の情報をサーバー５が出荷とほぼ同時に入手・格納しているので、過払いや請求漏れなどのトラブルが生じた場合に、実際の伝票類と対比するなどして、事後的に取引の内容を確認することができる。
【００５３】
受領記録テーブル２７は、サーバー５が受信した受領情報Ａ６を随時格納したテーブルであり、買い手ごとに設けられている。受領記録テーブルの例を図１１に示す。このテーブルは、買い手が押印した受領伝票に含まれる受領情報と同等な情報に加え、サーバー５での処理に必要なフラグの有無も格納している。具体的には、当該受領により発生した債務に対する支払い請求がなされていることを意味する請求済みフラグの有無、同様に買い手が代金支払いしたことを意味する支払い済みフラグの有無等を格納している。このように、買い手が押印した受領伝票と同等の情報をサーバー５が、実際の商品の受領からそれほど遅れずに入手・格納しているので、過払いや請求漏れなどのトラブルが生じた場合に、実際の伝票類と対比するなどして、事後的に取引の内容を確認することができる。
【００５４】
出荷受領照合結果テーブル２８は、サーバー５の先払い処理部１３による出荷情報Ａ５と、それに対応する受領情報Ａ６との照合結果とを格納するテーブルである。このテーブルの例を図１２に示す。このテーブルは、出荷伝票番号ごとに買い手名称、納入店舗コード照合結果、納品日照合結果、合計金額照合結果、先払い可否の判定結果を格納している。各照合結果は、サーバー５における出荷情報と受領情報との照合処理の結果、各々が一致したか否かを格納し、先払い可否は、全部の照合結果が一致したか否かに基づいて、先払い可否の判断結果を格納している。このように多数の商品取引が行われる場合であっても、それらの一つ一つについて逐一、出荷と受領の照合結果を格納するようにしているので、複数の取引に対してまとめて先払いを行う場合も、銀行手形一つ一つに対する割引処理と同等程度の確実さで先払い処理が行える。
【００５５】
先払い率情報テーブル２９は、売り手情報テーブルの先払い可否欄のデータが「可」となっている売り手についての先払い率を定めたテーブルである。先払い率は、商品の出荷により発生した債権額から先払い手数料や消費税を除いた残額のうち、実際に売り手に先払いする割合を意味する。先払い率は、低すぎると売り手に対する先払い金額が減少して売り手の満足が得られにくくなり、高すぎると債権支払会社にとって過払いのリスクが増大する。先払い率は、売り手の前年度の取引実績や返品実績、売り手の信用度等に基づいてあらかじめ定めておけばよい。先払い率をあらかじめ定めておくことにより、出荷後の腐敗や品質違い等のために商品の返品や廃棄等が生じて債権額が減少した場合の、債権支払会社の先払いにおける過払いリスクを低減させることができる。なお、売り手の取扱商品の一部が非常に高価であるとか、取扱数が極端に少ないなどのリスク要因となる特殊な事情がある場合は、さらに、取扱商品ごとに先払い率を設定しても良い。
【００５６】
先払い記録テーブル３０は、サーバー５の先払い処理部１３が買い手に対する先払い命令Ａ８を送信するたびに、その内容を格納したテーブルである。先払い記録テーブル３０の例を図１３に示す。このテーブルは、先払い対象となる売り手名称、先払いの原因である１または２以上の出荷伝票番号、先払い手数料、消費税額、先払いする予定日を指定した先払い日、先払いする合計金額等のデータを格納している。
【００５７】
請求記録テーブル３１は、サーバー５の請求処理部１４が、買い手に対する支払い請求である請求情報Ａ７を送信するたびに、その内容を格納したテーブルである。このテーブルの例を図１４に示す。このテーブルは、買い手名称、請求日、合計請求金額、対象となる１または２以上の出荷伝票番号等のデータを格納している。
【００５８】
買い手支払記録テーブル３２は、サーバー５が支払い済み情報Ａ１１を受信するたびに、その内容を格納したテーブルである。このテーブルの例を図１５に示す。このテーブルは、請求番号、買い手名称、支払日、合計支払金額、支払い対象となった１または２以上の出荷伝票番号等のデータを格納している。
【００５９】
請求入金照合結果テーブル３３は、サーバー５の入金照合処理部１５が、請求情報Ａ７とそれに対応する支払い済み情報Ａ１１とを照合した結果を、請求ごとに格納したテーブルである。このテーブルの例を図１６に示す。このテーブルは、請求番号、買い手名称、支払金額から請求金額を差し引いた差額、この差額がゼロであるか否かにより、請求金額と支払金額とが合致するか否かが判断された照合結果等のデータを格納している。
【００６０】
後払い記録テーブル３４は、サーバー５の後払い処理部１６が買い手に対する後払い命令Ａ１２を送信するたびに、その内容を格納したテーブルである。後払い記録テーブル３４の例を図１７に示す。このテーブルは、後払い対象となる売り手名称、後払いの原因である１または２以上の出荷伝票番号、後払いする予定日を指定した後払い日、後払いする合計金額等のデータを格納している。
【００６１】
次に、サーバー５の処理部１０について、適宜フローチャートも引用しながら説明する。まず、情報入力受付部１１について説明する。情報入力受付部１１は、サーバー５が端末２、４、７から受信した各情報を、それらの情報に各々対応した所定のテーブルに格納する機能を主として実現している。情報入力受付部１１は、サーバー５が買い手端末２から発注情報Ａ１を受信すると、受信の順番で発注記録テーブル２５に随時格納し、同じ内容の発注情報Ａ２を売り手端末２に送信する。また、サーバー５が売り手端末２から出荷情報Ａ５を受信すると、その売り手についての出荷記録テーブル２６に受信の順番で随時格納する。また、買い手端末４から受領情報Ａ６を受信すると、その買い手についての受領記録テーブル２７に受信の順番で随時格納する。また、買い手端末４から支払い済み情報Ａ１１を受信すると、その買い手についての買い手支払記録テーブル３２に受信の順番で随時格納する。このように、情報入力受付部１１が、サーバー５の受信した各情報をいったん所定のテーブルに格納しておくので、買い手や売り手の希望するスケジュールに従って、後述する各処理を行うことが可能になる。
【００６２】
スケジュール管理部１２は、先払い、請求、入金照合、後払いの各処理に関して、売り手または買い手の希望に基づいて、サーバー５における各処理を開始する日時を管理する機能を実現している。スケジュール管理部１２とテーブル類や他の処理部との関係の概略を、図１８にブロック図で示した。
【００６３】
まず、スケジュール管理部１２は、ある売り手に関して、売り手情報テーブル２１の先払い可否欄が「可」の場合に、売り手情報テーブル２１に格納された先払い間隔のデータと、売り手口座テーブル２２に格納された最近の先払い実施日とから次の先払い日を演算する。そして、次の先払い日に到達したら、先払い処理部１３に対し、その売り手に対する先払い処理を開始するように命令する。この処理を先払い可の全部の売り手に関して行う。このようにすることで、売り手が希望するスケジュールに合わせ、かつ複数の取引をまとめて適宜先払い処理を行うことが可能になる。つまり、売り手ごとに異なるスケジュールにより、複数の取引をまとめて先払いを行うことが可能になる。
【００６４】
また、スケジュール管理部１２は、ある買い手に関して、買い手情報テーブル２３に格納された支払い締め日の一定日数前に、請求処理部１４に対し、その買い手に対する請求処理を開始するように命令する。この処理を全部の買い手に関して随時行う。また、スケジュール管理部１２は、ある買い手に関して、買い手情報テーブル２３に格納された支払日が経過した後に、入金照合処理部１５に対し、その買い手からの支払い済み情報を請求情報と照合する入金照合処理を行うように命令する。この処理を全部の買い手に関して随時行う。なお、ここの一定日数は、買い手の事務処理が可能な範囲でできるだけ短い日数とするのが好ましい。
【００６５】
また、スケジュール管理部１２は、ある売り手に関して、売り手情報テーブル２１に格納された売り手の後払い希望日である毎月の後払い日のデータを用い、その後払い日の一定日数前に到達した場合に、後払い処理部１６に対し、その売り手に対する後払い処理を開始するように命令する。この処理を全部の売り手に関して随時行う。このようにすることで、売り手が希望するスケジュールに合わせた後払い処理が可能となり、かつ複数の取引をまとめて適宜後払い処理を行うことが可能になる。なお、ここの一定日数は、債権支払会社の事務処理が可能な範囲でできるだけ短くするのが好ましい。
【００６６】
スケジュール管理部１２における概略処理のフローチャートを図１９に示した。図１９（１）は、買い手について行う処理のフローチャートであり、（２）は、売り手について行う処理のフローチャートである。これらのフローチャートの処理は毎日実行される。まず、（１）のフローチャートにより買い手について行う処理を実行し、該当する請求処理及び照合処理が完了した後で、（２）のフローチャートにより売り手について行う処理を実行し、該当する先払い処理と後払い処理を実行する。買い手の支払いを確認した上で、後払い処理を実行することで、できるだけ早いタイミングで売掛債権の精算を行うためである。
【００６７】
図１９（１）は、買い手情報テーブルにおける先頭の買い手を特定し（ｇ＝１）、サーバーの内部クロックにより特定される処理当日が、その買い手に関する請求処理日または照合処理日に該当するか否かを判断し（Ｓ２、Ｓ４）、該当する場合に、買い手（ｇ）を特定した請求処理開始または照合処理開始を各処理部に命令する（Ｓ３、Ｓ５）。この処理を全部の買い手（ｓ人とする）に関して行って終了する。
【００６８】
図１９（２）は、売り手情報テーブルにおける先頭の売り手を特定し（ｈ＝１）、サーバーの内部クロックにより特定される処理当日が、その売り手に関する先払い処理日または後払い処理日に該当するか否かを判断し（Ｓ１２、Ｓ１４）、該当する場合に、売り手（ｈ）を特定した先払い処理開始または後払い処理開始を各処理部に命令する（Ｓ１３、Ｓ１５）。この処理を全部の売り手（ｔ人とする）に関して行って終了する。
【００６９】
このように、スケジュール管理部１２は、個々の売掛債権の先払い依頼日と直接の関係なく、サーバーの内部クロックとテーブルデータとから自律的に先払い処理等の各処理の開始を命令する。これにより、あらかじめ定めた各期間中に発生した複数の売掛債権等について、まとめて各処理部の処理が行われる。そのため、支払会社や売り手の事務処理の手間やコストが増大することなく、多数の売掛債権について連続的または定期的に先払いなどの処理を行うことが可能になる。
【００７０】
先払い処理部１３は、買い手が代金支払いを行う前の、商品の出荷から比較的短期間のうちに、売り手への商品代金の一部の先払い処理を行う機能を実現する。先払い処理部１３とテーブル類や他の処理部等との関係の概略を、図２０のブロック図に示した。また、先払い処理部１３でなされる処理の概略フローを図２１のフローチャートに示した。これら図２０、２１を用いて先払い処理部１３においてなされる処理について説明する。
【００７１】
スケジュール管理部１２から、ある買い手を特定して先払い処理命令が送られると、先払い処理部１３が処理を開始する。まず、処理日から先払いの短周期に合わせた一定日数遡った範囲のうちで、かつ先払い済みフラグが付されていない条件で出荷記録テーブル２６を検索し、該当する出荷伝票番号を特定する。ここでは、検索でヒットした出荷伝票番号がｎ個あったとする。このｎ個の出荷伝票番号で特定される出荷記録を一時記憶に読み込む（Ｓ２０ステップ）。ｎ個のうちの先頭の１個を選び（ｉ＝１）、ｉがｎ＋１に到達したか否か（ｎ個の全部について処理がなされたか否か）を判断する（Ｓ２１ステップ）。
【００７２】
ｉがｎ＋１に到達していない場合は、フローはＳ２１ステップから右に分岐し、この出荷伝票番号に対応する受領伝票番号を、受領記録テーブル２７を検索して特定する（Ｓ２１ステップ）。対応する受領伝票番号が特定された場合は、フローはＳ２１ステップから下に分岐して、受領伝票番号で特定された受領記録を一時記憶に読み出し、続いて、この受領記録と、出荷伝票番号で特定された出荷記録とを照合する（Ｓ２２ステップ）。照合は、納品日、納品店舗名称、伝票番号、合計金額を照合キーとして行われ、これらが全部合致した場合に「一致」と判断される。この場合、正しく取引が成立していると考えられることによる。続いて、フローはＳ２２ステップから下に分岐し、この照合結果が出荷受領照合結果テーブル２８に格納されて（Ｓ２３ステップ）、次の出荷伝票番号に処理が移り（ｉ＝ｉ＋１）、Ｓ２１ステップに戻る。
【００７３】
一方、Ｓ２１ステップで、対象の出荷伝票番号に対応する受領伝票番号が特定されなかった場合は、取引が成立していない可能性があるため、フローはＳ２１ステップから右に分岐して、対象の出荷伝票番号では対応する受領伝票番号が特定されなかった旨のデータを一覧表Ａファイルに蓄積し（Ｓ３０ステップ）、次の出荷伝票番号に処理が移る（ｉ＝ｉ＋１）。
【００７４】
また、Ｓ２２ステップで、上記の照合キーの何れかが合致しない場合は、取引内容の確認が必要であるから、「不一致」と判断されてフローは右に分岐し、照合結果を出荷受領照合結果テーブル２８に格納し（Ｓ４０ステップ）、対象の出荷伝票番号の出荷記録は、対応する受領記録と不一致であった旨のデータを一覧表Ｂファイルに蓄積し（Ｓ４１ステップ）、次の出荷伝票番号に処理が移り（ｉ＝ｉ＋１）、Ｓ２１ステップに戻る。
【００７５】
このようにして、Ｓ２１ステップからＳ４１ステップまでを繰り返して、ｎ個の出荷伝票番号の全部に関して照合が終了すると、Ｓ２１ステップではｉ＝ｎ＋１となり、ここから下に分岐して合計先払い金額が演算される（Ｓ５０ステップ）。合計先払い金額の演算は、出荷受領照合が「一致」となった１または２以上の出荷記録が正しく成立した取引の記録と考えられるから、これらの出荷合計金額を合算し、これから先払い手数料及び消費税を減じた実債権額が求められる。続いて、先払い率情報テーブル２９から先払い対象の買い手の先払い率データが読み出され、先に求められた実債権額に先払い率が乗ぜられて、先払い金額が決定される。
【００７６】
続いて、債権支払会社端末７に対して、買い手に上で決定された先払い金額を支払えとの命令が通信インターフェイス４０を介して送信され（Ｓ５１ステップ）、さらに、この先払い命令の内容が先払い情報テーブル３０と売り手口座テーブル２２とに格納され、合わせて出荷記録テーブル２６の該当欄に先払い済みフラグが立てられる（Ｓ５２ステップ）。最後に、先に蓄積された一覧表ＡとＢとがプリンタ４３から出力されて（Ｓ５３ステップ）、先払い処理部１３における処理が終了する。
【００７７】
なお、一覧表ＡとＢは、出荷記録に対応する受領記録が無い場合と、出荷記録に対応する受領記録はあるが、その照合キーが完全一致ではない場合である。これらは例外的な場合ではあるが、取引が不成立か、若しくはその内容が確定していないために債権支払会社にとってのリスク要因となる可能性がある。一覧表ＡとＢに記載された取引に関しては、一覧表に従ってアナログ的に人間が対応し、伝票とデータとの対比や売り手と買い手との交渉を行って債権額を確定し、テーブルのデータを修正するなどして対応すればよい。
【００７８】
このようにして、一定期間の間に発生した１または２以上の売掛債権に対してまとめて先払い処理がなされるので、生鮮商品の取引のような比較的小口の取引が毎日多数行われるような場合でも事務処理が煩雑にならず、適用することが可能となる。また、ファクタリングシステムのサーバーが、実際に発行される伝票類に対応するデータを随時入手・格納しているので、商品寿命が短期間で買い手の支払いがなされる前に商品が消滅してしまうような生鮮商品の取引でも、問題が生じた後に正しい取引データが何であったかを検証することが可能となる。様々な信用度の生産者や量販店等が関係する取引においても、先払い金の過払いや詐取などのおそれが減少し、債権支払会社が多大なリスクを負担しなくとも安全に先払い処理を行うことが可能となる。
【００７９】
請求処理部１４は、買い手端末４から送信され受領記録テーブル２７に格納された受領記録に基づいて、買い手端末４に対して代金支払い請求を送信する機能を実現する。請求処理部１４とテーブル類や他の処理部等との関係の概略を、図２２のブロック図に示した。請求処理部１４は、スケジュール管理部１２から買い手を特定した請求処理の開始命令を受けると、まず買い手情報テーブル２３を用いて、その買い手について今回の請求対象となる期間を特定し、続いて、受領記録テーブル２７を検索して、請求対象期間内で請求済みフラグが無い受領記録を特定する。これらが未だ買い手への代金請求がなされていない取引だからである。続いて、検索された受領記録を用いて請求情報Ａ７を形成し、通信回線を介して買い手端末４に送信する。最後に送信された請求情報Ａ７を請求記録テーブル３１に格納し、受領記録テーブル２７の該当欄に請求済みフラグを立てて処理を終了する。これをすべての買い手に対して随時行う。
【００８０】
入金照合処理部１５は、買い手への請求記録とそれに対応する買い手支払い記録とを照合し、両者が合致するか否かを判断する機能を実現する。入金照合処理部１５とテーブル類や他の処理部等との関係の概略を、図２３のブロック図に示した。また、入金照合処理部１５でなされる処理の概略フローを図２４のフローチャートに示した。これら図２３、２２を用いて入金照合処理部１５においてなされる処理について説明する。
【００８１】
スケジュール管理部１２から、買い手を特定して請求入金照合処理を行えとの命令を受けると、入金照合処理部１５は、請求日が一定範囲内にあるその買い手に対する請求記録を請求記録テーブル３１から検索し、検索された請求記録（ｍ個とする）を一時記憶に読み出す（Ｓ６０ステップ）。次に、ｍ個の請求記録から先頭の１個を選択し（ｊ＝１）、続いて、ｊがｍ＋１に到達したか否か（ｍ個の全部について処理がなされたか否か）を判断する（Ｓ６１ステップ）。
【００８２】
ｊがｍ＋１に到達していない場合は、フローはＳ６１ステップから右に分岐して、ｊ番目の請求記録に対応する買い手支払記録を、買い手支払い記録テーブル３２から検索する（Ｓ６２ステップ）。対応する買い手支払い記録が特定された場合は、フローはＳ６２ステップから下に分岐し、請求記録とそれに対応する買い手支払い記録とを照合する（Ｓ６３ステップ）。照合キーは、請求日、請求番号、買い手コード、合計支払額と合計請求金額、としている。これらの全部が合致する場合に、請求記録と買い手支払い記録とが「一致」すると判断する。いずれかが合致しない場合は、「不一致」と判断する。両者が一致する場合は、フローはＳ６３ステップから下に分岐して、照合結果を請求入金照合結果テーブル３３に格納し、また、受領記録テーブル２７の該当欄に支払い済みフラグを立てる。続いて、次の請求記録を選択し（ｊ＝ｊ＋１）、Ｓ６１ステップに戻る。
【００８３】
一方、Ｓ６２ステップにおいて、ｊ番目の請求記録に対応する買い手支払い記録が特定されない場合は、フローは右に分岐して、その請求記録及び、それに対応する買い手支払い記録が特定されない旨の情報を一覧表Ｃファイルに蓄積し（Ｓ７３ステップ）、次の請求記録に移る（ｊ＝ｊ＋１）。
【００８４】
また、Ｓ６３ステップにおいて、「不一致」と判断された場合にはフローは右に分岐して、不一致であった旨の照合結果を請求入金照合結果テーブル３３に格納し、また、当該請求記録と買い手支払い記録とを不一致である旨と一緒に一覧表Ｄファイルに蓄積する。続いて、次の請求記録を選択し（ｊ＝ｊ＋１）、Ｓ６１ステップに戻る。
【００８５】
Ｓ６１ステップで、ｊがｍ＋１に到達している場合は、ｍ個の請求記録の全部について照合が終了しているので、フローはＳ６１ステップから下に分岐して、一覧表ＣとＤとをプリンタ４３から紙出力して（Ｓ９０ステップ）、照合処理を終了する。入金照合処理部１５は、以上の処理をすべての買い手に対して随時行う。
【００８６】
なお、一覧表ＣとＤに関しては、一覧表ＡとＢの場合と同じように例外的な場合であり、一覧表Ａ、Ｂの処理と同様に、人間が一覧表を見ながらアナログ的に対処して、伝票類及び買い手や売り手の入力データの確認、データの修正入力等を行うことができる。
【００８７】
後払い処理部１６は、取引ごとに生じる債権の精算処理を行い、買い手に対し先払いだけでは不足する債権の残額を後払いする機能を実現する。後払い処理部１６とテーブル類や他の処理部等との関係の概略を、図２５のブロック図に示した。また、後払い処理部１６で実行される処理の概略フローを図２６のフローチャートに示した。これら図２５、２６を用いて後払い処理部１６においてなされる処理について説明する。
【００８８】
まず、後払い処理部１６は、スケジュール管理部１２から売り手を特定して後払い処理を行えとの命令を受けて後払い処理を開始する。後払い処理部１６は、命令の後払い対象期間内で、かつ後払い済みフラグが無いという条件で、売り手の出荷記録テーブルを検索し、該当する出荷記録を特定して（ｐ個とする）、一時記憶に読み込む（Ｓ１００ステップ）。このような出荷記録が、先払いの有無にかかわらず後払いの対象になるからである。このｐ個のうちの先頭の１個を選び（ｋ＝１）、ｋがｐ＋１に到達したか否か（ｐ個の全部について処理がなされたか否か）を判断する（Ｓ１１０ステップ）。
【００８９】
ｋがｐ＋１に到達していない場合は、フローはＳ１１０ステップから右に分岐し、この出荷記録に対応する買い手支払い記録を、買い手支払い記録テーブル３２を検索して特定する（Ｓ１１１ステップ）。対応する買い手支払い記録が特定された場合は、取引が成立していると判断して、フローはＳ１１１ステップから下に分岐して特定された買い手支払い記録を一時記憶に読み出す。続いて、この出荷記録について請求入金照合結果テーブル３３を検索して、該当する出荷記録の照合結果欄が「一致」となっているか否かを判断する（Ｓ１１２ステップ）。「一致」となっていた場合は、買い手から正しく支払いがなされているから、フローは下に分岐して次の出荷記録の処理に移り（ｋ＝ｋ＋１）、Ｓ１１０ステップに戻る。
【００９０】
一方、Ｓ１１１ステップにおいて、対応する買い手支払い記録が特定されない場合は、取引が成立していない可能性があるので、フローは右に分岐して、買い手支払記録が特定されない旨と対象の出荷記録とを一覧表Ｅファイルに蓄積する（Ｓ１２０ステップ）。続いて、次の出荷記録の処理に移り（ｋ＝ｋ＋１）、Ｓ１１０ステップに戻る。
【００９１】
また、Ｓ１１２ステップにおいて、「不一致」であった場合は、取引の内容確認が必要なので、その旨と対象である出荷記録と買い手支払い記録とが、やはり一覧表Ｅファイルに蓄積される。続いて、同様に次の出荷記録の処理に移り（ｋ＝ｋ＋１）、Ｓ１１０ステップに戻る。
【００９２】
このようにして、Ｓ１１１ステップからＳ１２０ステップまでを繰り返し、ｐ個の出荷記録の全部に関して処理が終了すると、Ｓ１１０ステップでｋ＝ｐ＋１となり、フローはＳ１１０ステップから下に分岐する。このようにして、ｐこの出荷記録のうち、対応する買い手支払い記録が存在する出荷記録が特定され、かつ請求入金照合結果テーブル３３のの照合結果欄が「一致」となっている出荷記録を後払い対象とする。その他は後払い対象から外す。
【００９３】
続いて、後払い対象とならない出荷記録が一覧表Ｅがプリンタから紙出力され（Ｓ１３０ステップ）、修正入力可能状態に移行する。これは、一覧表Ｅに記載されている取引の内容を後払い前に人間が確認して修正入力可能な状態とすることで、できるだけ売り手への後払い対象となる出荷記録を増やして、売り手への支払い処理を完結させるためである。必要な修正入力がなされ、または修正入力されずに続行入力がなされて（Ｓ１３１ステップ）、次のＳ１３２ステップに移行する。
【００９４】
Ｓ１３２〜１３３ステップでは、後払い金額が演算される。まず、後払い対象となる出荷記録のうちで、先払いが行われていたものの先払い金額と先払い手数料とを先払い記録テーブル３０から検索し、これらの検索された先払い金額を合計して合計先払い金額を演算し、同様に先払い手数料を合計して合計先払い手数料を演算する（Ｓ１３２ステップ）。次に、後払い対象となる出荷記録の出荷金額を合計して合計出荷金額を演算し、この合計出荷金額から上記の合計先払い金額と合計先払い手数料と、さらに消費税を含む後払い手数料とを減じて、得られた金額を今回の後払い金額とする（Ｓ１３３ステップ）。このようにすることで、複数の出荷記録に複数回の先払いが含まれている場合でも、問題なく後払い金額が確定できる。
【００９５】
次に、後払い処理部１６が、確定された後払い金額を売り手に対して支払えとの命令を債権支払会社端末７に対して送信し（Ｓ１３４ステップ）、送信された後払い命令の内容を後払い記録テーブル３４に格納し、また、後払いの内容を売り手口座テーブル２２に格納し、さらに出荷記録テーブル２６の該当欄に後払い済みフラグを立てて（Ｓ１３５ステップ）、後払い処理が終了する。
【００９６】
このようにして後払い処理を随時行うので、複数回の取引に対して複数回の先払いがなされるような複雑な取引形態の場合でも、出荷記録ごとに漏れなく精算がなされる。しかも、取引内容が必ずしも明確でない取引に対しては、別途の対処が可能であるから、後払いでも過払いが生じる可能性が小さい。
【００９７】
以上、本発明の方法及びファクタリングシステムの中心であるサーバー５の記憶部及び処理部の機能に関して説明してきたが、本発明は、これらの方法や機能をサーバーとなるコンピュータに実行または実現させるためのプログラムと捕らえることもできる。プログラムはコンピューターが読み取り可能な記録媒体に格納してもよい。ここで記録媒体とは、フレキシブルディスク、光磁気ディクス、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記録装置のことを言う。また、プログラムは、任意に分割し、分割したものをそれぞれ記憶媒体に格納してもよい。
【００９８】
また、サーバー５に接続可能にして用いられる各端末２、４、７は、サーバー５でなされる処理に対応して、サーバー５から送信される画面情報による画面表示と、表示画面に対して必要な入力操作が可能であれば良く、例えば、通常のパーソナルコンピュータやワークステーションなどを用いて常法に従って構成することができ、特に制限されない。通信回線はＬＡＮやＷＡＮのごとき専用線でもよいし、インターネットを利用しても良い。さらに、通信は常時接続であっても良いし、必要時だけ随時接続するのでもよい。
【００９９】
以上、本発明の実施形態を図面を参照して詳述してきたが、本発明は上記の具体的構成には限定されず、この発明の思想を逸脱しない範囲での変型も本発明に含まれる。例えば、各テーブル類のデータの持ち方や各処理部における処理の順序等は、各種の変型が可能である。例えば、売り手への支払いスケジュールを規定する短周期や長周期に関するデータは、売り手情報テーブルに他の情報と一緒に格納するのではなく、短周期に関するデータだけを格納したテーブルや、長周期に関するデータだけを集めたテーブルを用意して用いても良い。
【０１００】
また、上記では、各処理部を、内部クロックに従って統括するスケジュール管理手段を用いる例で説明したが、処理部ごとに個別にスケジュール管理手段を有していても良い。また、上記では、短周期が５日という１種類の間隔に固定された例で説明したが、実質的に短い周期で先払いが繰り返されるものであればよく、間隔が１種類である必要はない。例えば、１カ月の間に先払いを行う日を１日、１０日、１５日、２５日というように、それぞれの日の間隔が９日間、５日間、１０日間と３種類に異なるように定めて先払いを行っても良い。この場合、２５日から１日までの間隔は月によって異なるが、このようにしても良い。要は、売り手が望む先払いスケジュールで、買い手の通常の１回の支払いの間に複数回の先払いが行えるように定めればよい。
【０１０１】
後払いについても同様であり、長周期を上記のように１カ月として毎月決まった日に後払いをするのでも良いし、２ヶ月に一度行うのでも良い。また、１カ月と１カ月半の間隔を交互に用いるようにしても良い。要は、長周期は、原則、主な買い手の支払いパターンに合わせて定め、短周期は売り手が希望する短い期間となるように定めればよい。
【０１０２】
また、上記では、先払いのための照合において複数の商品が含まれている場合に、それらの合計金額だけで照合しているが、各商品ごとの金額に関しても照合するようにしても良い。
【０１０３】
また、不適格な出荷記録等をプリンタから紙出力するようにしているが、関係する端末にその旨のデータを送信し、各端末からの応答を待ってサーバーサイドで処理するようにしても良い。発注情報はサーバー５を経由しても良いし経由しなくとも良い。ただし、サーバー５を経由するようにすると、関係する情報の全部をサーバー５で一元管理できるため好ましい。また、請求情報は受領情報だけに基づいて生成しているが、出荷情報を参照するようにしても良い。また、支払い済み情報Ａ１１は、買い手端末からサーバー５に送信するようにしているが、支払いを受けた債権支払会社端末から受信するようにしても良い。
【０１０４】
また、上記では生鮮商品の生鮮商品の取引に適用する例で説明しているが、小口の多数の取引が毎日行われる業態であればよく、必ずしも生鮮商品には限定されない。例えば、コンビニエンスストアに弁当類やおにぎりのような加工食品等をほぼ毎日少しずつ配送する場合や、カンバン方式で運営されている製造ラインに、必要な機械部品類をほぼ毎日少数ずつ配送する場合等に用いることもできる。
【図面の簡単な説明】
【０１０５】
【図１】商品取引及びそれに基づく先払い処理を時系列に従って説明する図である
【図２】後払い処理を時系列に沿って説明する図である。
【図３】三ヶ月程度の期間における買い手支払い、先払い、後払いがなされるパターンを示した模式図である。
【図４】一つの商品取引とその支払い処理とを取り出して、その全体を説明するブロック図である。
【図５】サーバーを制御面からみた概略構成を示したブロック図である。
【図６】売り手情報テーブルの例を示した概念図である。
【図７】売り手口座テーブルの例を示した概念図である。
【図８】買い手情報テーブルの例を示した概念図である。
【図９】発注記録テーブルの例を示した概念図である。
【図１０】出荷記録テーブルの例を示した概念図である。
【図１１】受領記録テーブルの例を示した概念図である。
【図１２】出荷受領照合結果テーブルの例を示した概念図である。
【図１３】先払い記録テーブルの例を示した概念図である。
【図１４】請求記録テーブルの例を示した概念図である。
【図１５】買い手支払い記録テーブルの例を示した概念図である。
【図１６】請求入金照合結果テーブルの例を示した概念図である。
【図１７】後払い記録テーブルの例を示した概念図である。
【図１８】スケジュール管理部のテーブル類及び他の処理部等との関係を示したブロック図である。
【図１９】スケジュール管理部における処理のフローの概略を示したフローチャートである。
【図２０】先払い処理部のテーブル類及び他の処理部等との関係を示したブロック図である。
【図２１】先払い処理部における処理の概略フローを示したフローチャートである。
【図２２】請求処理部のテーブル類及び他の処理部等との関係を示したブロック図である。
【図２３】請求入金照合処理部のテーブル類及び他の処理部等との関係を示したブロック図である。
【図２４】請求入金照合処理部における処理の概略フローを示したフローチャートである。
【図２５】後払い処理部のテーブル類及び他の処理部等との関係を示したブロック図である。
【図２６】後払い処理部における処理の概略フローを示したフローチャートである。
【図１】
2007025849.tif 000003
【図２】
2007025849.tif 000004
【図３】
2007025849.tif 000005
【図４】
2007025849.tif 000006
【図５】
2007025849.tif 000007
【図６】
2007025849.tif 000008
【図７】
2007025849.tif 000009
【図８】
2007025849.tif 000010
【図９】
2007025849.tif 000011
【図１０】
2007025849.tif 000012
【図１１】
2007025849.tif 000013
【図１２】
2007025849.tif 000014
【図１３】
2007025849.tif 000015
【図１４】
2007025849.tif 000016
【図１５】
2007025849.tif 000017
【図１６】
2007025849.tif 000018
【図１７】
2007025849.tif 000019
【図１８】
2007025849.tif 000020
【図１９】
2007025849.tif 000021
【図２０】
2007025849.tif 000022
【図２１】
2007025849.tif 000023
【図２２】
2007025849.tif 000024
【図２３】
2007025849.tif 000025
【図２４】
2007025849.tif 000026
【図２５】
2007025849.tif 000027
【図２６】
2007025849.tif 000028