JP4305926B2 - 生鮮ファクタリングシステム - Google Patents

Description

本発明は、毎日の商品取引で生じた売掛債権に基づき、買い手による実際の支払いが行われるより前に、債権支払会社が先払いを行うための方法等に関する。特に、野菜・果物のような青果物、花、苗木、鮮魚、鶏肉のようなチルドで扱われる生肉等の、日単位や週単位で商品価値が大きく変化する生鮮商品の毎日の比較的小口の取引において先払いを可能にするのに適し、かつ債権支払会社にとって過払い等が生じにくい、安全な取引を可能にする方法等に関する。

最近、銀行手形の割引と同じようにして、商品取引で生じた比較的大口の売掛債権に基づき、買い手による実際の支払いが行われるより前に、個別に先払いを行ういわゆるファクタリングが行われるようになってきた。債権者は、ファクタリングを行う債権支払会社に対し、先払いを希望する売掛債権を個別に特定して先払い依頼する。その際、債権支払会社の債権回収に伴うリスクを低減するために、売掛債権の内容が確定している必要がある。依頼を受けた債権支払い会社は、売掛債権ごとに債権譲渡を受け、引き替えにファクタリング手数料を差し引いた額を債権者に先払いする。これにより、債権者は、手数料を負担するものの、債権回収の時期が早くなって資金繰りが楽になるメリットがある。

ファクタリングを行うためのシステム例としては、介護保険制度に対応した新しい資金調達方法を可能にすることを目的として、介護事業者の有する介護報酬債権（売掛債権）に所定の掛け目（７〜８割）を乗じてこれを上限額として前払いし、しかるのち期日に債務者から支払いが行われた際にその額に応じて未払い分を支払って精算するシステムが開示されている（特許文献１参照）。

ところで、一般の工業製品等とは異なり、生鮮商品は腐敗等による傷みが生じやすく日単位や週単位という短期間で商品価値が大きく変動する。そのため、生鮮商品の生産者は、生産物の収穫期における天候状況、行事日程や市場価格等を考慮しながら市場に出荷する生産物の数量を決め、生鮮商品の市場流通における卸業者や仲卸業者等は、小売店（量販店）からの毎日の注文に応じて、各地に散在する生産者等が出荷できる数量の生産物をできるだけ集積して、要求された数量と品質とを確保するようにしている。

つまり、毎日の商品の出荷に伴い、生産者や中間流通業者には比較的小口の売掛債権が多数発生し、その額は季節や日付や天候等により様々に変動する。また、商品が輸送中に痛んでしまったり、品質が注文と異なっていたりすることも珍しくなく、出荷時の債権額が検収後に変更されることも日常茶飯事である。さらに、通常の支払い処理がなされる時点では、多くの場合に商品はすでに廃棄または消費されて消滅しており、事後的に売掛債権額を検証するのは困難である。

ここで、債権譲渡前には買い手と売り手の間で売掛債権額が確定しておらず、将来的に確定する商品の取引を支援するシステム等が開示されている。具体的には、取引される商品の暫定取引額に基づいて売掛債権の評価額を決定し、買い手と売り手の事後の合意により商品の実取引額が確定したときに取引額を買い手または売り手から連絡してもらい、それに基づいて実取引額と評価額との差分金額を算出し、差分金額を売り手に対する今後の売掛債権の買取り又は融資に用いるシステムが開示されている（特許文献２参照）。

しかし、このシステムでは、売り手の満足を得るためには評価額を暫定取引額にできるだけ近づける必要がある一方、評価額が実取引額を超えて高すぎた場合には過払いとなってしまうおそれがある。また、債権支払いを行う会社には事後的に連絡された債権額を検証する手段が無いため、先払い金の詐取等を目的とする悪意の依頼者を排除するのが困難である。そのため、債権支払会社に多大なリスクが生じてしまう。

実際、生鮮商品の生産者や中間流通業者の規模は、一年を通じて数回程度しか取引がない零細な個人から、毎日継続的に大量の取引がある大規模な法人まで様々であり、その信用度も多様であるから、債権支払会社は大きなリスクにさらされることになる。

つまり、生鮮商品の流通では、毎日多様な比較的小口の売掛債権が多数発生し、関係する個人や法人の取引回数や信用度が様々であり、さらに債権額の確定が商品寿命に比して遅いうえ、債権額が確定したあとに確定額を検証することが実際上困難であるという特有の事情がある。そのため、債権支払会社が生鮮商品の売掛債権の先払いを行うと、売り手による先払い金の詐取等が意図された場合に、債権の焦げ付き等の発生が生じやすく、しかも事後的に物による検証が不能なため、リスクが大きすぎるという問題点があった。
特開２００２−５６１９９号公報 特開２００３−９１６５６号公報

本発明は、生鮮商品の商品寿命が短い商品のファクタリングを可能にし、先払い金の詐取等の問題が生じるおそれが小さくて、債権支払会社の先払いリスクを低減できる方法、ファクタリングシステムまたはそのためのサーバーを提供することを課題とする。

発明の第１は、商品売掛債権に基づいて前記商品の売り手に対する先払い処理を行うための方法であって、サーバーが前記売り手から前記商品の出荷情報を受信するステップと、前記サーバーが前記商品の買い手から前記商品の受領情報を受信するステップと、前記サーバーが前記出荷情報と前記受領情報とを照合するステップと、前記照合により前記出荷情報と前記受領情報とが合致した場合に前記サーバーが先払い金額を演算するステップと、前記サーバーが前記演算された先払い金額を含む先払い命令を送信するステップとを含むことを特徴とする方法である。

ここで、前記照合により前記出荷情報と前記受領情報とが合致しない場合に、前記サーバーが前記出荷情報または前記受領情報を出力するステップを含むことは好ましい。また、前記サーバーが先払い金額を演算するにあたり、あらかじめ定められた先払い率を用いることは好ましい。また、前記サーバーが前記買い手から前記商品の支払い情報を受信するステップと、前記サーバーが前記受領情報から構成された請求情報と前記支払い情報とを照合するステップと、前記請求情報と前記支払い情報とが合致した場合に、前記サーバーが、前記請求情報に含まれる請求金額と当該請求情報に対応する先払い金額とを用いて後払い金額を演算するステップと、前記サーバーが前記演算された後払い金額を含む後払い命令を送信するステップとを含むことは好ましい。また、前記サーバーが１または２以上の前記受領情報から前記買い手への請求金額を演算するステップと、前記サーバーが前記演算された請求金額を含む請求情報を前記買い手に送信するステップとを含むことは好ましい。また、前記の先払い命令が、あらかじめ定めた日数間に受信した１または２以上の出荷情報に係わる売掛債権に対する先払いをまとめたものであることは好ましい。また、前記商品が、短期間に商品価値が変動する生鮮商品であることは好ましい。また、生鮮商品が青果物であることは好ましい。

発明の第２は、商品売掛債権に基づいて前記商品の売り手に対する先払い処理を行うためのサーバーであって、前記売り手から前記商品の出荷情報を受信する手段と、前記商品の買い手から前記商品の受領情報を受信する手段と、前記出荷情報と前記受領情報とを照合する手段と、前記照合により前記出荷情報と前記受領情報とが合致した場合に先払い金額を演算する手段と、前記演算された先払い金額を含む先払い命令を送信する手段とを備えたことを特徴とするサーバーである。

発明の第３は、商品売掛債権に基づいて前記商品の売り手に対する先払い処理を行うためのサーバであって、商品売り手端末と商品買い手端末と商品債権支払会社端末との通信手段と、前記商品売り手端末から受信した１または２以上の出荷情報を格納する出荷テーブルと、前記商品買い手端末から受信した１または２以上の受領情報を格納する受領テーブルと、あらかじめ定められたスケジュールに基づき、前記出荷テーブルからあらかじめ定められた日数間に受信した前記出荷情報を読み出し、前記読み出された出荷情報に対応する受領情報を前記受領テーブルから検索し、前記読み出された出荷情報と前記検索された受領情報とを照合する手段と、前記照合により前記出荷情報と前記受領情報とが合致した場合に先払い金額を演算する手段と、前記演算された先払い金額を含む先払い命令を前記商品債権支払会社端末に送信する手段とを備えたことを特徴とするサーバーである。

発明の第４は、商品売り手端末と、商品買い手端末と、商品債権支払会社端末とが、上記のサーバーと通信可能に接続されていることを特徴とするファクタリングシステムである。

生鮮商品の、商品寿命が短い商品のファクタリングが可能になり、生産者や中間流通業者にとって短期間での債権回収が可能になる。また、先払い金の詐取等が生じる可能性が小さく、債権支払会社の事業リスクが低減できる。

以下、本発明の実施例を図面を参照しながら説明する。まず、図１と図２は、本発明の方法を実施する場合の具体的処理例を時間軸に沿って示したものである。図１は先払い処理例を示したものであり、図２は後払い処理例を示したものである。なお、ファクタリングシステム内の情報の移動は実線の矢印で示し、システム外の商品等の移動は破線の矢印で示した。まず、これらを用いて全体の概要を説明する。いずれも登場するのは商品の売り手１と買い手３、ファクタリング処理を行うサーバー５と、売掛債権の先払いを行う債権支払会社６である。なお、売り手１、買い手３、債権支払会社６には、電話回線、ＬＡＮまたはインターネット等の通信手段を介して、サーバー５と通信可能に接続されたそれぞれの端末２、４、７が備えられ、これらでファクタリングシステムが構成されている（図３）。

図１では、買い手と売り手の間に４月１日以降に発生した取引を例として、先払いのために行われる処理を上から下に時系列に従って並べている。なお、理解を容易にするために、買い手と売り手が共に単数の例で説明するが、実際には買い手と売り手は共に複数である。

まず、４月１日付けで買い手が売り手に対して、どの商品をどれだけの個数買うかを発注し、合わせて発注番号を連絡する。この発注は、サーバー５と端末２、４を介して行うのが好ましいが（Ａ１、Ａ２）、発注番号を明示して買い手が売り手に直接連絡するのでも良い。すると、売り手は、商品を用意して翌４月２日付けで商品を買い手に出荷Ａ３を行い、出荷伝票に従って商品を出荷した旨を売り手端末２に入力し、端末２は通信回線を介してサーバー５に出荷情報Ａ５を送信する。出荷情報には、発注番号、売り手、買い手、納品店舗名称、納品日、商品名、単価、取扱単位、出荷個数、出荷日付、出荷金額等が含まれている。出荷情報を受信したサーバー５は、出荷情報を所定のテーブルに格納する。

売り手１から出荷された商品は、当日のうちに買い手３に到着し、直ちに黒丸で示された検収が行われて、出荷情報が記載されて買い手受領印が押印された受領伝票及び、受領伝票に対応する納品伝票が発行される。押印された受領伝票は随時売り手１に戻される（Ａ４）。買い手３は、その日か翌日には買い手端末４に商品を受領した旨を納品伝票に従って入力し、買い手端末４は、通信回線を介してサーバー５に受領情報Ａ６を送信する。受領情報Ａ６を受信したサーバー５は、受領情報Ａ６を所定のテーブルに格納する。

同様にして、４月２日付けでも発注がなされて４月３日に出荷・受領がなされ、以下同様にして取引が繰り返される。このようにして４月１日から５日までの５日間分の取引が行われる。すると、４月８日にはこの５日間に行われた取引について売り手１への先払い処理が行われる。４月５日から８日まで間隔を空けているのは、多くの場合、受領情報が必ずしも受領後直ちには送られず、時間をおいて五月雨式にバラバラに送られてくることから、できるだけ多くの受領情報を受信した後に照合処理を行うためである。なお、売り手１が買い手３以外の複数の買い手との間に、同じ期間のうちに１または２以上の取引がある場合も、それらの取引が先払い対象である限り、買い手３との取引と同様にしてまとめて先払い処理される。また、５日間で先払い処理する場合を例として説明しているが、この期間は、売り手の希望や商品の性質に応じて適宜定めればよい。

先払い処理は、以下のようにして行う。まず、サーバー５が４月１日から５日までの５日間のうちに売り手端末４から受信した出荷情報を所定のテーブルから読み出し、続いて、各出荷情報に出荷伝票番号が対応する受領情報を、受領情報を集積した所定のテーブルから検索して読み出す。続いて、サーバー５は各出荷情報とそれに対応する受領情報とを照合する。照合は、納品日、納品店舗名称、伝票番号、合計金額に関して行われ、これらが合致するか否かで判断する。いずれも合致する場合には正しく取引がなされたと判断できるから、先払い可能とする。いずれかが合致しない場合は取引内容の確認が必要であるから、その出荷情報または受領情報はサーバー５のプリンタからプリントアウトされ、実際の受領伝票との照合作業が手作業で行われる。

サーバー５は、５日間の出荷伝票の全部について照合処理が終了したら、それらの合計金額を演算し、続いて、債権支払会社の所定の手数料を減じてから、所定の先払い率が乗じて実際の先払い金額を演算する。先払い率を乗じるのは、買い手への納品後の店舗陳列段階になって商品に不良品が発見され、売掛債権額が変動する場合があることを考慮したものである。先払い率は、売り手の商品種ごとの過去の実績に基づいて、あらかじめ定めておけばよい。

このようにして先払い金額が定められると、サーバー５は、債権支払会社６の端末７に対して、先払いの対象者である売り手１に対して前記の金額の先払いを行えとの先払い命令Ａ８を送信する。先払い命令には、命令送信日、先払い指定日（例えば、４月５日から５日後の４／１０）、先払い対象者、支払口座、先払い金額等が含まれている。先払い命令Ａ８を端末７で受信した債権支払会社６は、先払い指定日である４月１０付けで、売り手の口座に対して先払い処理Ａ９を行う。先払い処理Ａ９は、売り手の商品取引が継続的に行われている限り、あらかじめ定められた日数、例えば５日ごとに行われることになる。

このようにして、出荷情報と受領情報とを照合して、照合済みの取引に関してのみ先払い処理を行うので、売り手の不正な操作等が例えなされたとしても先払い金の詐取等は困難となる。また、商品の評価額等を定める必要がないので、先払い処理が簡単で過払いも生じにくい。そのため、債権支払会社の先払い処理に伴うリスクが大幅に軽減される。また、比較的小口の毎日の取引で発生する売掛債権を複数日分まとめてから先払い処理されるので、売り手にとっても債権回収の事務処理が軽減され、かつある程度まとまった金額が定期的に得られるため、売り手の満足が得られやすい。

従来、受領伝票や納品書は、例えば一ヶ月間の取引を締めた後に支払い等のための事務処理を行う際に、取引金額等を確認するために用いられるだけであり、商品の輸送を行った配送業者が受領伝票を買い手から入手しても、配送業者はそれを一枚ごとに売り手に返送することは行わず、何日分かの伝票が溜まった後にまとめて返送するというのが普通であった。そのため、これらの伝票類を活用して先払い処理するなどと言うことは従来考えられなかった。ここでは、出荷伝票と受領伝票とを情報の裏付けとして用い、それぞれの伝票に対応する出荷情報と受領情報とを買い手と売り手の端末からそれぞれ入力させてサーバーで逐一照合することにより、先払い処理に伴うトラブルの発生を可能な限り防止できるようになった。

ところで、出荷受領照合のタイミングは、上記のように５日分をまとめて行っても良いし、毎日、前日以前に受信して未照合の受領情報に関して行うようにしても良い。この場合、照合済みの受領情報には照合済みのフラグを立てて、先払い処理の際に照合済みフラグの立っている受領情報を検索するようにすればよい。さらには、受領情報を受信するたびに随時、出荷受領照合を行うのでも良い。

続いて、図２について説明する。図２は、後払い処理の時系列に沿った流れを図１と同様にして示した図である。後払い処理とは、買い手の債務支払いを確認した後に行う精算処理である。買い手の支払いは、多くの場合、月末締めの翌月１５日支払いや月末支払い等であるから、このあとに後払い処理がなされる。ここでは１５日支払いの例で説明する。

後払い処理を行うのは、先払いだけで売掛債権額の全額が支払われるわけではないこと、また、サーバーによる照合処理の結果、何らかの不一致があった場合も原則として先払いはなされないことなどから、支払いがなされた分に関しての精算を行うためである。このようにすることで、複数の取引が合算されて処理されるものの、各取引の精算が後払いで完結するから事後的な確認作業も簡単になる。

後払い処理は、以下のようにして行う。まず、買い手端末４が、月初め（図２では５／１）に先月分の受領情報を売り手ごとに集計して月末締め処理を行う。サーバー５が、一定期間内の複数の受領情報を売り手ごとにまとめた支払い請求のための請求情報を買い手端末４に送信している場合は、受信した請求情報を集計するのが良い。次いで、支払日（図２では５／１５）に、買い手３は、債権支払会社の口座に対して先月中に購入した商品の代金を支払い（Ａ１０）、買い手端末４は、支払済み情報Ａ１１をサーバー５に送信する。支払い済み情報Ａ１１には、支払日、支払金額、買い手、支払い対象となった１または２以上の出荷伝票番号が含まれる。サーバー５は、買い手端末４から支払い済み情報Ａ１１を受信すると、所定のテーブルに格納する。

さらに、サーバー５は、売り手１が希望する後払いスケジュールに従って、精算のための後払い処理を開始する。図２は、支払い済み情報Ａ１１受信後の５月１８日に後払い処理を行っている例である。サーバー５は、売り手１の一定期間の出荷情報のうち、後払い処理がなされていないものを検索し、買い手の支払いがなされていることを確認した後で、先払い金額と手数料とを減じて後払い金額を演算する。続いて、対象期間内に後払い対象となる複数の取引がある場合は、それらの後払い金額を合計して、債権支払会社６の端末７に対して売り手１への後払い命令Ａ１２を送信する。後払い命令には、命令送信日、後払い指定日（例えば５／２０）、後払い対象者、支払口座、後払い金額等が含まれている。後払いの内容は所定のテーブルに格納される。

債権支払会社６の端末７が後払い命令Ａ１２を受信すると、債権支払会社６は、後払い命令に従って、指定日に売り手１の指定口座に対して後払い金額の支払いを行う。これで対象となった１または２以上の取引の精算処理が終了する。

なお、上記の流れには、サーバー５のプリンタ４３から支払い等に不適格とされた情報が、プリンタ４３からプリントアウトされるステップが複数箇所存在している。大多数の取引は、サーバー５により適格と判断されて自動処理される一方、不適格とされた情報に関しては、随時サーバーサイドの人間がアナログ的に対処して、買い手と売り手が合意した情報をサーバーに修正入力可能にしている。

このようにして、出荷情報と受領情報との照合を元にして短期で次々と先払い処理を行い、その後、買い手の実支払いを元にして残額の後払い処理を行う。先払いの元となる出荷情報と受領情報には、それぞれ出荷伝票と押印された受領伝票の裏付けがあるから、仮に商品内容や金額等の入力間違いなどの問題が生じたとしても、事後的に正しい内容を確定することができる。その際、そのような比較的少数の不適格情報に係わる取引に関しては、サーバーによる自動処理から弾きだして別途に対処可能としている。これらのため、先払い金の過払いや詐取等が生じにくく、債権支払会社にとって先払い処理のリスクが比較的小さい範囲に留まる。また、生鮮商品の取引のごとき比較的小口で多数行われる取引に対応して的確に先払い処理を行うことができるから、売り手は、債権回収の事務処理が煩雑になることなく、比較的短期で債権回収することが可能になる。

次に、図３は、図１、２とは観点を変えて、１回の商品取引の発注から支払い完了までだけに着目することで単純化し、売り手１、買い手３、サーバー５及び債権支払会社６間の情報及び商品等の移動の概略を示した図である。ファクタリングシステムは、サーバー５が、売り手端末２と買い手端末４と債権支払会社端末７とに通信可能に接続されて構成されている。なお、図１、２と同様に、ファクタリングシステム内の情報の移動を実線の矢印で示し、システム外の商品等の移動を破線の矢印で示している。また、図３では簡単のために売り手と買い手とがそれぞれ単数で示しているが、実際はいずれも複数である。

買い手端末４が商品の発注情報Ａ１をサーバー５に送信すると、サーバー５は発注情報を所定のテーブルに格納すると共に、売り手端末２に対して発注情報Ａ２として送信する。発注情報Ａ２を受信した売り手１は、注文された商品を用意して納品伝票と共に買い手３に対して発送する（Ａ３）。さらに出荷した旨の出荷情報Ａ５が売り手端末２からサーバー５へ送信される。サーバー５は、出荷情報Ａ５を受信すると所定のテーブルに格納する。商品が買い手の指定した店舗等に到着すると、買い手３により検収印が押印された受領伝票が発行され、受領伝票は適宜売り手１に返送される（Ａ４）。また、商品を受領した旨の受領情報Ａ６が買い手端末４からサーバー５に送信される。サーバー５は、受領情報Ａ６を受信すると所定のテーブルに格納する。

サーバー５は、売り手１が希望する先払いスケジュールに従って、先に受信した出荷情報と受領情報とを照合し、両者が合致する場合に先払い金額を演算し、債権支払会社端末７に対して、売り手１に先払い金額を支払えとの先払い命令Ａ８を送信する。両者が合致しない場合は先払い命令Ａ８は送信されない。先払い命令Ａ８を端末７で受信した債権支払会社６は、売り手１の指定口座に先払い金額を支払う（Ａ９）。

また、サーバー５は、受領情報Ａ６に基づいて、買い手３の支払いスケジュールに合わせて買い手端末４に対して商品代金を支払えとの請求情報Ａ７を送信し、合わせて請求情報Ａ７を所定のテーブルに格納する。請求情報Ａ７を端末４で受信して買い手３は、請求情報Ａ７に従って債権支払会社６に商品代金を支払う（Ａ１０）。合わせて買い手端末４から代金の支払い済み情報Ａ１１が、サーバー５に送信される。サーバー５は支払い済み情報Ａ１１を受信すると所定のテーブルに格納する。サーバー５は、買い手３の支払いスケジュールにより、買い手３に対する請求情報Ａ７と支払い済み情報Ａ１１とを照合し、両者が合致した場合に、買い手の支払いが完了した旨を所定のテーブルに格納する。

サーバー５は、売り手１が希望する後払いスケジュールに従って、買い手３の代金支払いが完了していることを確認したのち、代金から先払い金額等を減じて後払い金額を演算し、売り手３に対して後払い金額を支払えとの後払い命令Ａ１２を債権支払会社端末７に送信する。後払い命令Ａ１２を端末７が受信すると、債権支払会社６は、後払い金額を売り手１の口座に支払う。これで、１回の商品取引に関する処理が完了する。

このように、出荷情報、受領情報を初めとする各種の情報が、ファクタリングシステムを介して、売り手１、買い手３、債権支払会社６にそれぞれ流されるので、サーバー５で全部の情報を一元的に管理できる。また、受領伝票等の伝票の裏付けがとれる情報を入力するようにしているため、出荷情報と受領情報、請求情報と支払い済み情報をそれぞれ照合することが可能となる。これらのため、債権支払会社の過払いや先払い金の詐取等のトラブルが生じにくい。つまり債権支払会社の先払いリスクが低減される。

次に、図４は、ファクタリングシステムのサーバー５を制御面から見た概略構成を示した図である。サーバー５は、各種データ類、テーブル類及びコンピュータプログラムを格納した複数のハードディスクから構成される記憶部２０と、ＣＰＵとＲＡＭとから構成され、記憶部２０から読み出されたコンピュータプログラムやデータを用いてデータ処理を行う処理部１０と、サーバー５を通信回線に接続する通信インターフェイス４０と、キーボードやマウス等の入力装置４１と、液晶ディスプレイやＣＲＴのごときディスプレイ４２と、情報を紙出力するプリンタ４３とが、図示されない必要なインターフェイスを介するなどして、共通バスで接続されている。

サーバー５の記憶部２０には、図４に記載されたような売り手情報テーブル２１や後払い記録テーブル３４等の各種のテーブルと、サーバー５を動作させるコンピュータプログラム類、ディスプレイ表示のためのプログラム類、その他の必要なデータ類が格納されている。また、処理部１０では、必要なプログラム等をＲＡＭに読み込むことで、サーバー５に、端末から送信される各情報を受け付けて所定のテーブルに格納させるための情報入力受付機能を発揮させる情報受付部１１、サーバー５に各種処理に関するスケジュール管理機能を発揮させるスケジュール管理部１２等（以下の処理部に関しても同様）の、それぞれの機能を発揮させるための図４に図示された各処理部１３〜１６を備える。

まず、記憶部２０のテーブル類について説明する。まず、売り手情報テーブル２１は、ファクタリングシステムにとって、商品を売る立場の者（売り手）を特定するためのテーブルであり、この例を図５に示す。売り手としては、例えば、青果物の生産農家、各地の農業協同組合、仲卸業者等が該当する。売り手情報テーブル２１には、売り手名称や売り手コード等の他、売り手が先払い処理を受けることができる売り手であるか否か、また先払い処理を受けられるとして、売り手が希望する先払い条件、例えば、先払い開始日、先払い間隔（何日ごとに先払いを受けたいか。）及び、売り手が希望する後払い条件、例えば、後払い処理の締め日や後払い日のデータを含む。

このように、売り手ごとに異なる先払いや後払いの条件を希望する場合であっても、あらかじめ売り手情報テーブル等にそれらの条件を登録しておくことができ、それらに基づいた柔軟な先払い処理等を行うことができる。そのため、売り手は、支払い側の一方的な都合に振り回されることなく、柔軟に資金調達することが可能となる。

売り手口座テーブル２２は、売り手ごとに用意されたテーブルであり、この例を図６に示す。このテーブルには、商品の出荷や先払いや後払い等の取引日ごとに、それらの取引種別、各取引によって発生した債権額、売り手に支払われた金額、取引日の２４時における売り手の債権の合計残額のデータが格納されている。この売り手口座テーブル２２は、出荷や支払い等が生じたごとにデータが格納され、債権残額のデータは、商品出荷により新たな債権が発生した場合はその債権額だけ増加し、支払いによって債権が消滅した場合は、その支払額及び支払いの手数料及び消費税分だけ減少する。このような売り手口座テーブルを設けることにより、毎日の比較的小口の商品取引が複数発生し、一定の日数ごとにその間の取引に関してまとめて先払いが行われ、かつその後にまとめて定期的に後払い精算が行われるような複雑な取引形態であっても、売り手ごとに商品と対応した収支が明確にできるから、支払い漏れや請求漏れが生じた場合にチェックが容易で、直ちに問題箇所を見つけ出すことが可能になる。

買い手情報テーブル２３は、ファクタリングシステムにとって、商品を買う立場の者（買い手）を特定するためのテーブルであり、この例を図７に示す。買い手としては、例えば、百貨店、コンビニ、スーパー等の小売り量販店、生産者に対する仲卸業者等が該当する。買い手情報テーブル２３には、買い手名称等の買い手を特定するデータの他、商品を配送する買い手の店舗名称、店舗コード、さらに買い手の支払い条件、例えば、支払いの締め日、各月の支払日等のデータが格納されている。

商品情報テーブル２４は、取扱商品ごとに、商品名称、コード、産地、梱包単位、梱包数、品質、熟度等のデータを格納し、商品を特定すると共に商品取引に必要な梱包単位のデータを格納したテーブルである。なお、取扱商品は特に限定されないが、好ましい商品は、日単位や週単位長くとも月単位で品質が変化する生鮮商品であり、具体的には、野菜や果物のような青果物、花、苗木、鮮魚、または鶏肉のようなチルドで扱われる生肉等である。これらのごとき商品のファクタリング処理において、債権支払会社のリスクが高くなることによる。最も好ましい取扱商品は、品質変化速度が大きい青果物である。

発注記録テーブル２５は、サーバー５が受信した発注情報Ａ１を格納したテーブルであり、買い手ごとに設けられている。発注記録テーブルの例を図８に示す。このテーブルは、発注伝票番号ごとに、発注日、売り手名称、納入希望日、納入希望店舗名称、１または２以上の商品名とコード、商品の個数、商品の単価、商品ごとの金額、合計金額等の発注伝票に記載される情報が格納されている。

出荷記録テーブル２６は、サーバー５が受信した出荷情報Ａ５を格納したテーブルであり、売り手ごとに設けられている。出荷記録テーブルの例を図９に示す。このテーブルは、売り手の出荷伝票に含まれる情報、出荷伝票番号、出荷日、発注伝票番号、納品日、買い手名称、納入店舗名称、商品名称、個数、単価、出荷合計金額等と同等な情報を格納している。さらに、このテーブルは、サーバー５での処理に必要なフラグの有無も格納している。具体的には、当該出荷により発生した債権に対する先払いが終了していることを意味する先払い済みフラグの有無、同様に後払いが終了していることを意味する後払いフラグの有無等を格納している。このように、出荷伝票に記載されている情報と同等の情報をサーバー５が出荷とほぼ同時に入手・格納しているので、過払いや請求漏れなどのトラブルが生じた場合に、実際の伝票類と対比するなどして、事後的に取引の内容を確認することができる。

受領記録テーブル２７は、サーバー５が受信した受領情報Ａ６を格納したテーブルであり、買い手ごとに設けられている。受領記録テーブルの例を図１０に示す。このテーブルは、買い手が押印した受領伝票に含まれる受領情報と同等な情報に加え、サーバー５での処理に必要なフラグの有無も格納している。具体的には、当該受領により発生した債務に対する支払い請求がなされていることを意味する請求済みフラグの有無、同様に買い手が代金支払いしたことを意味する支払い済みフラグの有無等を格納している。このように、買い手が押印した受領伝票と同等の情報をサーバー５が、実際の商品の受領からそれほど遅れずに入手・格納しているので、過払いや請求漏れなどのトラブルが生じた場合に、実際の伝票類と対比するなどして、事後的に取引の内容を確認することができる。

出荷受領照合結果テーブル２８は、サーバー５の先払い処理部１３による出荷情報Ａ５と、それに対応する受領情報Ａ６との照合結果とを格納するテーブルである。このテーブルの例を図１１に示す。このテーブルは、出荷伝票番号ごとに買い手名称、納入店舗コード照合結果、納品日照合結果、合計金額照合結果、先払い可否の判定結果を格納している。各照合結果は、サーバー５における出荷情報と受領情報との照合処理の結果、各々が一致したか否かを格納し、先払い可否は、全部の照合結果が一致したか否かに基づいて、先払い可否の判断結果を格納している。このように多数の商品取引が行われる場合であっても、それらの一つ一つについて逐一、出荷と受領の照合結果を格納するようにしているので、複数の取引に対してまとめて先払いを行う場合も、銀行手形一つ一つに対する割引処理と同等程度の確実さで先払い処理が行える。

先払い率情報テーブル２９は、売り手情報テーブルの先払い可否欄のデータが「可」となっている売り手についての先払い率を定めたテーブルである。先払い率は、商品の出荷により発生した債権額から先払い手数料や消費税を除いた残額のうち、実際に売り手に先払いする割合を意味する。先払い率は、低すぎると売り手に対する先払い金額が減少して売り手の満足が得られにくくなり、高すぎると債権支払会社にとって過払いのリスクが増大する。先払い率は、売り手の前年度の取引実績や返品実績、売り手の信用度等に基づいてあらかじめ定めておけばよい。先払い率をあらかじめ定めておくことにより、出荷後の腐敗や品質違い等のために商品の返品や廃棄等が生じて債権額が減少した場合の、債権支払会社の先払いにおける過払いリスクを低減させることができる。なお、売り手の取扱商品の一部が非常に高価であるとか、取扱数が極端に少ないなどのリスク要因となる特殊な事情がある場合は、さらに、取扱商品ごとに先払い率を設定しても良い。

先払い記録テーブル３０は、サーバー５の先払い処理部１３が買い手に対する先払い命令Ａ８を送信するたびに、その内容を格納したテーブルである。先払い記録テーブル３０の例を図１２に示す。このテーブルは、先払い対象となる売り手名称、先払いの原因である１または２以上の出荷伝票番号、先払い手数料、消費税額、先払いする予定日を指定した先払い日、先払いする合計金額等のデータを格納している。

請求記録テーブル３１は、サーバー５の請求処理部１４が、買い手に対する支払い請求である請求情報Ａ７を送信するたびに、その内容を格納したテーブルである。このテーブルの例を図１３に示す。このテーブルは、買い手名称、請求日、合計請求金額、対象となる１または２以上の出荷伝票番号等のデータを格納している。

買い手支払記録テーブル３２は、サーバー５が支払い済み情報Ａ１１を受信するたびに、その内容を格納したテーブルである。このテーブルの例を図１４に示す。このテーブルは、請求番号、買い手名称、支払日、合計支払金額、支払い対象となった１または２以上の出荷伝票番号等のデータを格納している。

請求入金照合結果テーブル３３は、サーバー５の入金照合処理部１５が、請求情報Ａ７とそれに対応する支払い済み情報Ａ１１とを照合した結果を、請求ごとに格納したテーブルである。このテーブルの例を図１５に示す。このテーブルは、請求番号、買い手名称、支払金額から請求金額を差し引いた差額、この差額がゼロであるか否かにより、請求金額と支払金額とが合致するか否かが判断された照合結果等のデータを格納している。

後払い記録テーブル３４は、サーバー５の後払い処理部１６が買い手に対する後払い命令Ａ１２を送信するたびに、その内容を格納したテーブルである。後払い記録テーブル３４の例を図１６に示す。このテーブルは、後払い対象となる売り手名称、後払いの原因である１または２以上の出荷伝票番号、後払いする予定日を指定した後払い日、後払いする合計金額等のデータを格納している。

次に、サーバー５の処理部１０について、適宜フローチャートも引用しながら説明する。まず、情報入力受付部１１について説明する。情報入力受付部１１は、サーバー５が端末２、４、７から受信した各情報を、それらの情報に各々対応した所定のテーブルに格納する機能を主として実現している。情報入力受付部１１は、サーバー５が買い手端末２から発注情報Ａ１を受信すると、受信の順番で発注記録テーブル２５に格納し、同じ内容の発注情報Ａ２を売り手端末２に送信する。また、サーバー５が売り手端末２から出荷情報Ａ５を受信すると、その売り手についての出荷記録テーブル２６に受信の順番で格納する。また、買い手端末４から受領情報Ａ６を受信すると、その買い手についての受領記録テーブル２７に受信の順番で格納する。また、買い手端末４から支払い済み情報Ａ１１を受信すると、その買い手についての買い手支払記録テーブル３２に受信の順番で格納する。このように、情報入力受付部１１が、サーバー５の受信した各情報をいったん所定のテーブルに格納するので、買い手や売り手の希望するスケジュールに従って、後述する各処理を行うことが可能になる。

スケジュール管理部１２は、先払い、請求、入金照合、後払いの各処理に関して、売り手または買い手の希望に基づいて、サーバー５における各処理を開始する日時を管理する機能を実現している。スケジュール管理部１２とテーブル類や他の処理部との関係の概略を、図１７にブロック図で示した。

まず、スケジュール管理部１２は、ある売り手に関して、売り手情報テーブル２１の先払い可否欄が「可」の場合に、売り手情報テーブル２１に格納された先払い間隔のデータと、売り手口座テーブル２２に格納された最近の先払い実施日とから次の先払い日を演算する。そして、次の先払い日に到達したら、先払い処理部１３に対し、その売り手に対する先払い処理を開始するように命令する。この処理を先払い可の全部の売り手に関して行う。このようにすることで、売り手が希望するスケジュールに合わせ、かつ複数の取引をまとめて適宜先払い処理を行うことが可能になる。つまり、売り手ごとに異なるスケジュールにより、複数の取引をまとめて先払いを行うことが可能になる。

また、スケジュール管理部１２は、ある買い手に関して、買い手情報テーブル２３に格納された支払い締め日の一定日数前になると、請求処理部１４に対し、その買い手に対する請求処理を開始するように命令する。この処理を全部の買い手に関して随時行う。また、スケジュール管理部１２は、ある買い手に関して、買い手情報テーブル２３に格納された支払日が経過した後に、入金照合処理部１５に対し、その買い手からの支払い済み情報を請求情報と照合する入金照合処理を行うように命令する。この処理を全部の買い手に関して随時行う。なお、ここの一定日数は、買い手の事務処理が可能な範囲でできるだけ短い日数とするのが好ましい。

また、スケジュール管理部１２は、ある売り手に関して、売り手情報テーブル２１に格納された売り手の後払い希望日である毎月の後払い日のデータを用い、その後払い日の一定日数前に到達した場合に、後払い処理部１６に対し、その売り手に対する後払い処理を開始するように命令する。この処理を全部の売り手に関して随時行う。このようにすることで、売り手が希望するスケジュールに合わせた後払い処理が可能となり、かつ複数の取引をまとめて適宜後払い処理を行うことが可能になる。なお、ここの一定日数は、債権支払会社の事務処理が可能な範囲でできるだけ短くするのが好ましい。

先払い処理部１３は、買い手が代金支払いを行う前の、商品の出荷から比較的短期間のうちに、売り手への商品代金の一部の先払い処理を行う機能を実現する。先払い処理部１３とテーブル類や他の処理部等との関係の概略を、図１８のブロック図に示した。また、先払い処理部１３でなされる処理の概略フローを図１９のフローチャートに示した。これら図１８、１９を用いて先払い処理部１３においてなされる処理について説明する。

スケジュール管理部１２から、ある買い手を特定して先払い処理命令が送られると、先払い処理部１３が処理を開始する。まず、処理日から先払い間隔に合わせた一定日数遡った範囲のうちで、かつ先払い済みフラグが付されていない条件で出荷記録テーブル２６を検索し、該当する出荷伝票番号を特定する。ここでは、検索でヒットした出荷伝票番号がｎ個あったとする。このｎ個の出荷伝票番号で特定される出荷記録を一時記憶に読み込む（Ｓ１０ステップ）。ｎ個のうちの先頭の１個を選び（ｉ＝１）、ｉがｎ＋１に到達したか否か（ｎ個の全部について処理がなされたか否か）を判断する（Ｓ２０ステップ）。

ｉがｎ＋１に到達していない場合は、フローはＳ２０ステップから右に分岐し、この出荷伝票番号に対応する受領伝票番号を、受領記録テーブル２７を検索して特定する（Ｓ２１ステップ）。対応する受領伝票番号が特定された場合は、フローはＳ２１ステップから下に分岐して、受領伝票番号で特定された受領記録を一時記憶に読み出し、続いて、この受領記録と、出荷伝票番号で特定された出荷記録とを照合する（Ｓ２２ステップ）。照合は、納品日、納品店舗名称、伝票番号、合計金額を照合キーとして行われ、これらが全部合致した場合に「一致」と判断され、この場合は正しく取引が成立していると考えられる。続いて、フローはＳ２２ステップから下に分岐し、この照合結果が出荷受領照合結果テーブル２８に格納されて（Ｓ２３ステップ）、次の出荷伝票番号に処理が移り（ｉ＝ｉ＋１）、Ｓ２０ステップに戻る。

一方、Ｓ２１ステップで、対象の出荷伝票番号に対応する受領伝票番号が特定されなかった場合は、取引が成立していない可能性があるため、フローはＳ２１ステップから右に分岐して、対象の出荷伝票番号では対応する受領伝票番号が特定されなかった旨のデータを一覧表Ａファイルに蓄積し（Ｓ３０ステップ）、次の出荷伝票番号に処理が移る（ｉ＝ｉ＋１）。

また、Ｓ２２ステップで、上記の照合キーの何れかが合致しない場合は、取引内容の確認が必要であるから、「不一致」と判断されてフローは右に分岐し、照合結果を出荷受領照合結果テーブル２８に格納し（Ｓ４０ステップ）、対象の出荷伝票番号の出荷記録は、対応する受領記録と不一致であった旨のデータを一覧表Ｂファイルに蓄積し（Ｓ４１ステップ）、次の出荷伝票番号に処理が移り（ｉ＝ｉ＋１）、Ｓ２０ステップに戻る。

このようにして、Ｓ２１ステップからＳ４１ステップまでを繰り返して、ｎ個の出荷伝票番号の全部に関して照合が終了すると、Ｓ２０ステップではｉ＝ｎ＋１となり、ここから下に分岐して合計先払い金額が演算される（Ｓ５０ステップ）。合計先払い金額の演算は、出荷受領照合が「一致」となった１または２以上の出荷記録が正しく成立した取引の記録と考えられるから、これらの出荷合計金額を合算し、これから先払い手数料及び消費税を減じた実債権額が求められる。続いて、先払い率情報テーブル２９から先払い対象の買い手の先払い率データが読み出され、先に求められた実債権額に先払い率が乗ぜられて、先払い金額が決定される。

続いて、債権支払会社端末７に対して、買い手に上で決定された先払い金額を支払えとの命令が通信インターフェイス４０を介して送信され（Ｓ５１ステップ）、さらに、この先払い命令の内容が先払い情報テーブル３０と売り手口座テーブル２２とに格納され、合わせて出荷記録テーブル２６の該当欄に先払い済みフラグが立てられる（Ｓ５２ステップ）。最後に、先に蓄積された一覧表ＡとＢとがプリンタ４３から出力されて（Ｓ５３ステップ）、先払い処理部１３における処理が終了する。

なお、一覧表ＡとＢは、出荷記録に対応する受領記録が無い場合と、出荷記録に対応する受領記録はあるが、その照合キーが完全一致ではない場合である。これらは例外的な場合ではあるが、取引が不成立か、若しくはその内容が確定していないために債権支払会社にとってのリスクとなる可能性がある。一覧表ＡとＢに記載された取引に関しては、一覧表に従ってアナログ的に人間が対応し、伝票とデータとの対比や売り手と買い手との交渉を行って債権額を確定し、テーブルのデータを修正するなどして対応すればよい。

このようにして、一定期間の間に発生した１または２以上の取引に対してまとめて先払い処理がなされるので、生鮮商品の取引のような比較的小口の取引が毎日多数行われるような場合に適用することが可能となる。また、ファクタリングシステムのサーバーが、実際に発行される伝票類に対応するデータを随時入手・格納しているので、商品寿命が短期間で買い手の支払いがなされる前に商品が消滅してしまうような生鮮商品の取引でも、問題が生じた後に正しい取引データが何であったかを検証することが可能となる。これらの結果、様々な信用度の生産者や量販店等が関係する取引においても、先払い金の過払いや詐取などのおそれが減少し、債権支払会社が多大なリスクを負担しなくとも安全に先払い処理を行うことが可能となる。

請求処理部１４は、買い手端末４から送信され受領記録テーブル２７に格納された受領記録に基づいて、買い手端末４に対して代金支払い請求を送信する機能を実現する。請求処理部１４とテーブル類や他の処理部等との関係の概略を、図２０のブロック図に示した。請求処理部１４は、スケジュール管理部１２から買い手を特定した請求処理の開始命令を受けると、まず買い手情報テーブル２３を用いて、その買い手について今回の請求対象となる期間を特定し、続いて、受領記録テーブル２７を検索して、請求対象期間内で請求済みフラグが無い受領記録を特定する。これらが未だ買い手への代金請求がなされていない取引だからである。続いて、検索された受領記録を用いて請求情報Ａ７を形成し、通信回線を介して買い手端末４に送信する。最後に送信された請求情報Ａ７を請求記録テーブル３１に格納し、受領記録テーブル２７の該当欄に請求済みフラグを立てて処理を終了する。これをすべての買い手に対して随時行う。

入金照合処理部１５は、買い手への請求記録とそれに対応する買い手支払い記録とを照合し、両者が合致するか否かを判断する機能を実現する。入金照合処理部１５とテーブル類や他の処理部等との関係の概略を、図２１のブロック図に示した。また、入金照合処理部１５でなされる処理の概略フローを図２２のフローチャートに示した。これら図２１、２２を用いて入金照合処理部１５においてなされる処理について説明する。

スケジュール管理部１２から、買い手を特定して請求入金照合処理を行えとの命令を受けると、入金照合処理部１５は、請求日が一定範囲内にあるその買い手に対する請求記録を請求記録テーブル３１から検索し、検索された請求記録（ｍ個とする）を一時記憶に読み出す（Ｓ６０ステップ）。次に、ｍ個の請求記録から先頭の１個を選択し（ｊ＝１）、続いて、ｊがｍ＋１に到達したか否か（ｍ個の全部について処理がなされたか否か）を判断する（Ｓ６１ステップ）。

ｊがｍ＋１に到達していない場合は、フローはＳ６１ステップから右に分岐して、ｊ番目の請求記録に対応する買い手支払記録を、買い手支払い記録テーブル３２から検索する（Ｓ６２ステップ）。対応する買い手支払い記録が特定された場合は、フローはＳ６２ステップから下に分岐し、請求記録とそれに対応する買い手支払い記録とを照合する（Ｓ６３ステップ）。照合キーは、請求日、請求番号、買い手コード、合計支払額と合計請求金額、としている。これらの全部が合致する場合に、請求記録と買い手支払い記録とが「一致」すると判断する。いずれかが合致しない場合は、「不一致」と判断する。両者が一致する場合は、フローはＳ６３ステップから下に分岐して、照合結果を請求入金照合結果テーブル３３に格納し、また、受領記録テーブル２７の該当欄に支払い済みフラグを立てる。続いて、次の請求記録を選択し（ｊ＝ｊ＋１）、Ｓ６１ステップに戻る。

一方、Ｓ６２ステップにおいて、ｊ番目の請求記録に対応する買い手支払い記録が特定されない場合は、フローは右に分岐して、その請求記録及び、それに対応する買い手支払い記録が特定されない旨の情報を一覧表Ｃファイルに蓄積し（Ｓ７３ステップ）、次の請求記録に移る（ｊ＝ｊ＋１）。

また、Ｓ６３ステップにおいて、「不一致」と判断された場合にはフローは右に分岐して、不一致であった旨の照合結果を請求入金照合結果テーブル３３に格納し、また、当該請求記録と買い手支払い記録とを不一致である旨と一緒に一覧表Ｄファイルに蓄積する。続いて、次の請求記録を選択し（ｊ＝ｊ＋１）、Ｓ６１ステップに戻る。

Ｓ６１ステップで、ｊがｍ＋１に到達している場合は、ｍ個の請求記録の全部について照合が終了しているので、フローはＳ６１ステップから下に分岐して、一覧表ＣとＤとをプリンタ４３から紙出力して（Ｓ９０ステップ）、照合処理を終了する。入金照合処理部１５は、以上の処理をすべての買い手に対して随時行う。

なお、一覧表ＣとＤに関しては、一覧表ＡとＢの場合と同じように例外的な場合であり、一覧表Ａ、Ｂの処理と同様に、人間が一覧表を見ながらアナログ的に対処して、伝票類及び買い手や売り手の入力データの確認、データの修正入力等を行うことができる。

後払い処理部１６は、取引ごとに生じる債権の精算処理を行い、買い手に対し先払いだけでは不足する債権の残額を後払いする機能を実現する。後払い処理部１６とテーブル類や他の処理部等との関係の概略を、図２３のブロック図に示した。また、後払い処理部１６で実行される処理の概略フローを図２４のフローチャートに示した。これら図２３、２４を用いて後払い処理部１６においてなされる処理について説明する。

まず、後払い処理部１６は、スケジュール管理部１２から売り手を特定して後払い処理を行えとの命令を受けて後払い処理を開始する。後払い処理部１６は、命令の後払い対象期間内で、かつ後払い済みフラグが無いという条件で、売り手の出荷記録テーブルを検索し、該当する出荷記録を特定して（ｐ個とする）、一時記憶に読み込む（Ｓ１００ステップ）。このような出荷記録が、先払いの有無にかかわらず後払いの対象になるからである。このｐ個のうちの先頭の１個を選び（ｋ＝１）、ｋがｐ＋１に到達したか否か（ｐ個の全部について処理がなされたか否か）を判断する（Ｓ１１０ステップ）。

ｋがｐ＋１に到達していない場合は、フローはＳ１１０ステップから右に分岐し、この出荷記録に対応する買い手支払い記録を、買い手支払い記録テーブル３２を検索して特定する（Ｓ１１１ステップ）。対応する買い手支払い記録が特定された場合は、取引が成立していると判断して、フローはＳ１１１ステップから下に分岐して特定された買い手支払い記録を一時記憶に読み出す。続いて、この出荷記録について請求入金照合結果テーブル３３を検索して、該当する出荷記録の照合結果欄が「一致」となっているか否かを判断する（Ｓ１１２ステップ）。「一致」となっていた場合は、買い手から正しく支払いがなされているから、フローは下に分岐して次の出荷記録の処理に移り（ｋ＝ｋ＋１）、Ｓ１１０ステップに戻る。

一方、Ｓ１１１ステップにおいて、対応する買い手支払い記録が特定されない場合は、取引が成立していない可能性があるので、フローは右に分岐して、買い手支払記録が特定されない旨と対象の出荷記録とを一覧表Ｅファイルに蓄積する（Ｓ１２０ステップ）。続いて、次の出荷記録の処理に移り（ｋ＝ｋ＋１）、Ｓ１１０ステップに戻る。

また、Ｓ１１２ステップにおいて、「不一致」であった場合は、取引の内容確認が必要なので、その旨と対象である出荷記録と買い手支払い記録とが、やはり一覧表Ｅファイルに蓄積される。続いて、同様に次の出荷記録の処理に移り（ｋ＝ｋ＋１）、Ｓ１１０ステップに戻る。

このようにして、Ｓ１１１ステップからＳ１２０ステップまでを繰り返し、ｐ個の出荷記録の全部に関して処理が終了すると、Ｓ１１０ステップでｋ＝ｐ＋１となり、フローはＳ１１０ステップから下に分岐する。このようにして、ｐこの出荷記録のうち、対応する買い手支払い記録が存在する出荷記録が特定され、かつ請求入金照合結果テーブル３３のの照合結果欄が「一致」となっている出荷記録を後払い対象とする。その他は後払い対象から外す。

続いて、後払い対象とならない出荷記録が一覧表Ｅがプリンタから紙出力され（Ｓ１３０ステップ）、修正入力可能状態に移行する。これは、一覧表Ｅに記載されている取引の内容を後払い前に人間が確認して修正入力可能な状態とすることで、できるだけ売り手への後払い対象となる出荷記録を増やして、売り手への支払い処理を完結させるためである。必要な修正入力がなされ、または修正入力されずに続行入力がなされて（Ｓ１３１ステップ）、次のＳ１３２ステップに移行する。

Ｓ１３２〜１３３ステップでは、後払い金額が演算される。まず、後払い対象となる出荷記録のうちで、先払いが行われていたものの先払い金額と先払い手数料とを先払い記録テーブル３０から検索し、これらの検索された先払い金額を合計して合計先払い金額を演算し、同様に先払い手数料を合計して合計先払い手数料を演算する（Ｓ１３２ステップ）。次に、後払い対象となる出荷記録の出荷金額を合計して合計出荷金額を演算し、この合計出荷金額から上記の合計先払い金額と合計先払い手数料と、さらに消費税を含む後払い手数料とを減じて、得られた金額を今回の後払い金額とする（Ｓ１３３ステップ）。このようにすることで、複数の出荷記録に複数回の先払いが含まれている場合でも、問題なく後払い金額が確定できる。

次に、後払い処理部１６が、確定された後払い金額を売り手に対して支払えとの命令を債権支払会社端末７に対して送信し（Ｓ１３４ステップ）、送信された後払い命令の内容を後払い記録テーブル３４に格納し、また、後払いの内容を売り手口座テーブル２２に格納し、さらに出荷記録テーブル２６の該当欄に後払い済みフラグを立てて（Ｓ１３５ステップ）、後払い処理が終了する。

このようにして後払い処理を随時行うので、複数回の取引に対して複数回の先払いがなされるような複雑な取引形態の場合でも、出荷記録ごとに漏れなく精算がなされる。しかも、取引内容が必ずしも明確でない取引に対しては、別途の対処が可能であるから、後払いでも過払いが生じる可能性が小さい。

以上、本発明の方法及びファクタリングシステムの中心であるサーバー５の記憶部及び処理部の機能に関して説明してきたが、本発明は、これらの方法や機能をサーバーとなるコンピュータに実行または実現させるためのプログラムととらえることもできる。プログラムはコンピューターが読み取り可能な記録媒体に格納してもよい。ここで記録媒体とは、フレキシブルディスク、光磁気ディクス、ＲＯＭ、ＣＤ−ＲＯＭ等の可搬媒体、コンピュータシステムに内蔵されるハードディスク等の記録装置のことを言う。また、プログラムは、任意に分割し、分割したものをそれぞれに記憶媒体に格納してもよい。

また、サーバー５に通信可能に接続して用いられる各端末２、４、７は、サーバー５でなされる処理に対応して、サーバー５から送信される画面情報による画面表示と、表示画面に対して必要な入力操作が可能であれば良く、例えば、通常のパーソナルコンピュータやワークステーションを用いて常法に従って構成することができ、特に制限されない。通信回線はＬＡＮやＷＡＮのごとき専用線でもよいし、インターネットを利用しても良い。さらに、通信は常時接続であっても良いし、必要時だけ随時接続するのでもよい。

以上、本発明の実施形態を図面を参照して詳述してきたが、本発明は上記の具体的構成には限定されず、この発明の思想を逸脱しない範囲での変型も本発明に含まれる。例えば、各テーブル類のデータの持ち方や各処理部における処理の順序等は、各種の変型が可能である。また、先払い期間が５日ごとの例で説明したが、売り手の都合に合わせて随時定めればよい。また、上記では、先払いのための照合において複数の商品が含まれている場合に、それらの合計金額だけで照合しているが、各商品ごとの金額に関しても照合するようにしても良い。

また、不適格な出荷記録等をプリンタから紙出力するようにしているが、関係する端末にその旨のデータを送信し、各端末からの応答を待ってサーバーサイドで処理するようにしても良い。発注情報はサーバー５を経由しても良いし経由しなくとも良い。ただし、サーバー５を経由するようにすると、関係する情報の全部をサーバー５で一元管理できるため好ましい。また、請求情報は受領情報だけに基づいて生成しているが、出荷情報を参照するようにしても良い。また、支払い済み情報Ａ１１は、買い手端末からサーバー５に送信するようにしているが、支払いを受けた債権支払会社端末から受信するようにしても良い。

商品取引及びそれに基づく先払い処理を時系列に従って説明する図である 後払い処理を時系列に従って説明する図である。 一つの商品取引とその支払い処理とを取り出して、その全体を説明するブロック図である。 サーバーを制御面からみた概略構成を示したブロック図である。 売り手情報テーブルの例を示した概念図である。 売り手口座テーブルの例を示した概念図である。 買い手情報テーブルの例を示した概念図である。 発注記録テーブルの例を示した概念図である。 出荷記録テーブルの例を示した概念図である。 受領記録テーブルの例を示した概念図である。 出荷受領照合結果テーブルの例を示した概念図である。 先払い記録テーブルの例を示した概念図である。 請求記録テーブルの例を示した概念図である。 買い手支払い記録テーブルの例を示した概念図である。 請求入金照合結果テーブルの例を示した概念図である。 後払い記録テーブルの例を示した概念図である。 スケジュール管理部のテーブル類及び他の処理部等との関係を示したブロック図である。 先払い処理部のテーブル類及び他の処理部等との関係を示したブロック図である。 先払い処理部における処理の概略フローを示したフローチャートである。 請求処理部のテーブル類及び他の処理部等との関係を示したブロック図である。 請求入金照合処理部のテーブル類及び他の処理部等との関係を示したブロック図である。 請求入金照合処理部における処理の概略フローを示したフローチャートである。 後払い処理部のテーブル類及び他の処理部等との関係を示したブロック図である。 後払い処理部における処理の概略フローを示したフローチャートである。

Claims (7)

1. 商品売掛債権に基づいて前記商品の売り手に対する先払い処理を行うための方法であって、前記商品は青果物であり、かつ前記売掛債権は債権額が未確定のものであり、サーバーが前記売り手から前記商品の出荷伝票に従って入力された出荷情報を受信するステップと、前記サーバーが前記商品の買い手から前記商品の納品伝票に従って入力された受領情報を受信するステップと、前記サーバーが前記出荷情報と前記受領情報とを、納品日、納品店舗名称、伝票番号、合計金額を照合キーとして照合するステップと、前記照合により前記出荷情報と前記受領情報とが合致した場合に前記サーバーが前記合計金額にあらかじめ定められた先払い率を乗じて先払い金額を演算するステップと、前記サーバーが前記演算された先払い金額を含む先払い命令を送信するステップと、前記サーバーが前記受領情報から前記買い手への請求金額を前記合計金額を用いて演算するステップと、前記サーバーが前記演算された請求金額を含む請求情報を前記買い手に送信するステップと、前記サーバーが前記買い手から前記商品の支払い情報を受信するステップと、前記サーバーが前記請求情報と前記支払い情報とを、請求日、請求番号、買い手コード、合計金額を照合キーとして照合するステップと、前記請求情報と前記支払い情報とが合致した場合に、前記サーバーが、前記請求情報に含まれる請求金額と当該請求情報に対応する先払い金額とを用いて後払い金額を演算するステップと、前記サーバーが前記演算された後払い金額を含む後払い命令を送信するステップとを含み、１回の前記後払い命令が送信されたあと、次の後払い命令が送信されるまでの期間に、複数回の前記先払い命令が送信されることを特徴とする方法。
2. 前記照合により前記出荷情報と前記受領情報とが合致しない場合に、前記サーバーが前記出荷情報または前記受領情報を出力するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記の先払い命令に含まれる先払い金額が、あらかじめ定めた日数間に受信し、上記照合によりいずれかの前記受領情報と合致した１または２以上の出荷情報に係わる売掛債権から演算された先払い金額を合計したものであることを特徴とする請求項１又は２に記載の方法。
4. 前記の先払い命令の送信が、前記出荷情報の受信に関する前記のあらかじめ定められた日数が経過したあと、さらに一定日数が経過した後に行われることを特徴とする請求項３に記載の方法。
5. 前記の後払い命令があらかじめ定められた期間ごとに送信され、かつ当該後払い命令に関してあらかじめ定められた期間が、前記の先払い命令に関してあらかじめ定められた期間より長いことを特徴とする請求項１から４のいずれかに記載の方法。
6. 商品売掛債権に基づいて前記商品の売り手に対する先払い処理を行うためのサーバーであって、前記商品は短期間に商品価値が変動する生鮮商品であり、かつ前記売掛債権は債権額が未確定のものであり、前記売り手から前記商品の出荷伝票に従って入力された出荷情報を受信する手段と、前記商品の買い手から前記商品の納品伝票に従って入力された受領情報を受信する手段と、前記出荷情報と前記受領情報とを、納品日、納品店舗名称、伝票番号、合計金額を照合キーとして照合する手段と、前記照合により前記出荷情報と前記受領情報とが合致した場合に前記合計金額にあらかじめ定められた先払い率を乗じて先払い金額を演算する手段と、前記演算された先払い金額を含む先払い命令を送信する手段と、前記サーバーが前記受領情報から前記買い手への請求金額を前記合計金額を用いて演算する手段と、前記サーバーが前記演算された請求金額を含む請求情報を前記買い手に送信する手段と、前記サーバーが前記買い手から前記商品の支払い情報を受信する手段と、前記サーバーが前記請求情報と前記支払い情報とを、請求日、請求番号、買い手コード、合計金額を照合キーとして照合する手段と、前記請求情報と前記支払い情報とが合致した場合に、前記サーバーが、前記請求情報に含まれる請求金額と当該請求情報に対応する先払い金額とを用いて後払い金額を演算する手段と、前記サーバーが前記演算された後払い金額を含む後払い命令を送信する手段とを含み、１回の前記後払い命令が送信されたあと、次の後払い命令が送信されるまでの期間に、複数回の前記先払い命令が送信されることを特徴とするサーバー。
7. 商品売り手端末と、商品買い手端末と、商品債権支払会社端末とが、請求項６に記載のサーバーと通信可能に接続されていることを特徴とするファクタリングシステム。

Images