【発明の詳細な説明】 【０００１】 【発明の属する技術分野】本発明は、企業間取引に利用される債権債務処理システム、その方法、そのプログラム及びそのプログラムが記録された記録媒体に関する。 【０００２】 【従来の技術】近年にあっては、企業間での金銭取引で発生する債権及び債務を集中管理するために、管理会社等により企業企業間取引センタシステムが運用されている。 【０００３】図１４は、従来の企業間取引センタシステム１００による管理運用を示す図である。 企業間取引センタシステム１００は、予め決められた計算期間において、債権額（売掛金）及び債務額（買掛金）を記録する。 そして、当該計算期間後に金額を相殺して企業の経理システムに連絡する。 【０００４】例えば、図１４のように、Ａ社が、Ｂ社に５００円、Ｃ社に４００円、Ｄ社に３００円の請求を行い、Ｂ社から８００円、Ｃ社から３００円、Ｄ社から４
００円の請求を受けたとする。 これらは、企業間取引センタシステム１００に記録される。 そして、例えば、計算期間終了後の月末には、企業間取引センタシステム１
００は、Ａ社のＢ社に対する債務額を３００円、Ｃ社に対する債権額を１００円、Ｄ社に対する債務額を１００
円と計算する。 【０００５】企業間取引センタシステム１００は、同様の計算を全ての企業についても行う。 そして、相手企業ごとの債権額または債務額を企業に通知する。 【０００６】したがって、企業間取引センタシステム１
００を利用する企業は、通知された金額を相手企業に支払う、あるいは支払いを受けるだけでよく、その結果、
社内の人的あるいは計算機資源を節約することができた。 【０００７】 【発明が解決しようとする課題】しかしながら、企業間取引センタシステム１００は、債権額及び債務額を、相手企業ごとに計算し通知するので、多数の企業を相手にする場合は、支払いや支払いの確認に多大な労力を要することになる。 特に昨今においては、中間業者を省いた直接取引により相手企業数が多くなる傾向にあり、このため、企業の労力を軽減したいとの要望が強くなってきている。 【０００８】そこで本発明は、上記の従来の課題に鑑みてなされたものであり、その目的とするところは、金銭取引の主体である企業等における労力を軽減できる債権債務処理システム、その方法、そのプログラム及びそのプログラムが記録された記録媒体を提供することにある。 【０００９】 【課題を解決するための手段】上記従来の課題を解決するために、請求項１の本発明は、３以上の取引の主体のいずれかが他のいずれかの主体を相手として取引を行うときに利用されるコンピュータシステムである債権債務処理システムであって、前記取引ごとの債権額または債務額が取引の主体に関連づけて逐次記録されるデータベースと、前記３以上の主体のそれぞれの予め設定された計算期間における債権額または債務額を求める手段であって、当該主体のそれぞれが当該計算期間に行った取引により前記データベースに記録された債権額及び債務額を取引の相手にかかわらず集計及び相殺して求める債権債務処理手段とを備える債権債務処理システムをもって解決手段とする。 【００１０】請求項２の本発明は、前記取引で生じる債権額及び債務額をネットワークを介して取得するとともに前記求めた債権額または債務額をネットワークを介して予め定められた提供先に提供することを特徴とする請求項１記載の債権債務処理システムをもって解決手段とする。 【００１１】請求項３の本発明は、前記債権債務処理手段は、前記データベースに記録される債権額及び債務額のそれぞれを取引の度に累積し、前記計算期間の経過後に当該累積した債権額及び債務額を相殺することを特徴とする請求項１または２記載の債権債務処理システムをもって解決手段とする。 【００１２】請求項４の本発明は、前記計算期間として、予め定められた取引に限り適用されるものと、当該取引以外に適用されるものととが設定されているときに、どの計算期間を適用するかを取引に対応づけて記録しておいた上で、当該計算期間のそれぞれについての債権額または債務額を求めるように構成されたことを特徴とする請求項１ないし３のいずれかに記載の債権債務処理システムをもって解決手段とする。 【００１３】請求項５の本発明は、さらに相手ごとの債権額または債務額を求めるように構成されたことを特徴とする請求項１ないし４のいずれかに記載の債権債務処理システムをもって解決手段とする。 【００１４】請求項６の本発明は、金銭取引を行う３以上の主体のいずれかが他のいずれかの主体を相手として取引を行うときに該取引で生じる債権額及び債務額が取引の主体に関連づけて逐次データベースに記録されるときの債権債務処理方法であって、前記３以上の主体のそれぞれの予め設定された計算期間における債権額または債務額を、当該主体のそれぞれが当該計算期間に行った取引により前記データベースに記録された債権額及び債務額を取引の相手にかかわらず集計及び相殺して求める債権債務処理手順を備える債権債務処理方法をもって解決手段とする。 【００１５】請求項７の本発明は、前記データベースに記録される債権額及び債務額のそれぞれを取引の度に累積し、前記計算期間の経過後に当該累積した債権額及び債務額を相殺することを特徴とする請求項６記載の債権債務処理方法をもって解決手段とする。 【００１６】請求項８の本発明は、前記計算期間として、予め定められた取引に限り適用されるものと、当該取引以外に適用されるものととが設定されているときに、どの計算期間を適用するかを取引に対応づけて記録しておいた上で、当該計算期間のそれぞれについての債権額及び債務額を求めることを特徴とする請求項６または７記載の債権債務処理方法をもって解決手段とする。 【００１７】請求項９の本発明は、金銭取引を行う３以上の主体のいずれかが他のいずれかの主体を相手として取引を行うときに該取引で生じる債権額及び債務額が取引の主体に関連づけて逐次データベースに記録されるときに実行される債権債務処理プログラムであって、前記３以上の主体のそれぞれの予め設定された計算期間における債権額または債務額を、当該主体のそれぞれが当該計算期間に行った取引により前記データベースに記録された債権額及び債務額を取引の相手にかかわらず集計及び相殺して求める債権債務処理手順を備える債権債務処理プログラムをもって解決手段とする。 【００１８】請求項１０の本発明は、金銭取引を行う３
以上の主体のいずれかが他のいずれかの主体を相手として取引を行うときに該取引で生じる債権額及び債務額が取引の主体に関連づけて逐次データベースに記録されるときに実行される債権債務処理プログラムが記録された記録媒体であって、前記３以上の主体のそれぞれの予め設定された計算期間における債権額または債務額を、当該主体のそれぞれが当該計算期間に行った取引により前記データベースに記録された債権額及び債務額を取引の相手にかかわらず集計及び相殺して求める債権債務処理手順を備える債権債務処理プログラムが記録された記録媒体をもって解決手段とする。 【００１９】 【発明の実施の形態】以下、本発明の実施の形態を図面を参照して説明する。 図１は、本発明の実施の形態に係る企業間取引センタシステム１の構成及び利用形態を示す図である。 企業間取引センタシステム１は、３以上の企業のいずれかが他の企業を相手として取引を行うときに利用されて、企業間の取引を網羅的に把握するとともに、資金ネッテイングのキャッシュフローの効率化を図るコンピュータシステムである。 企業間取引センタシステム１は、ネットワークを介して、企業側に構築されるシステム（企業側システムという）２に接続される。 企業間取引センタシステム１は、Ｉ／Ｆ部１１と、処理部１２と、ファイル転送管理データベースＤＢ１と、契約情報データベースＤＢ２と、請求支払情報データベースＤＢ３と、決済スケジュール管理データベースＤＢ４
と、債権債務累積データベースＤＢ５と、ネッティング結果データベースＤＢ６とを備える。 【００２０】Ｉ／Ｆ部１１は、企業側システム２と交信するためのファイル送受信部１１１を備える。 処理部１
２は、債権債務処理手段に相当するものであり、予め外部記憶装置などに格納された債権債務処理プログラムを実行することにより具現化される。 【００２１】処理部１２は、企業間取引センタシステム１を利用する企業（参加企業という）から送信される契約情報を契約情報データベースＤＢ２に格納する契約情報取込部１２１、請求元から送信される請求金額等や支払元から送信される支払金額等を請求支払情報データベースＤＢ３に格納する請求支払情報取込部１２２、契約内容や請求金額を通知するための通知情報を作成する通知情報作成部１２３、各種スケジュールが格納される決済スケジュール管理部１２４、定例ネッティング結果を作成する定例ネッティング結果作成部１２５、及び随時ネッティング結果を作成する随時ネッティング結果作成部１２６から構成される。 【００２２】企業側システム２には、企業独自の会計システム、契約システム、請求システム、購買システムが稼働しているが、本実施の形態では、企業側システム２
に外部インタフェースサブシステムを設けることにより、企業間取引センタシステム１が統一された形式の情報を企業側システムと交信できるようになっている。 【００２３】図２は、本実施の形態の概要を示す図である。 企業間取引センタシステム１は、企業間取引センタシステム１００のように、参加企業の相手企業ごとの債権額又は債務額を集計し連絡するのではなく、例えば、
１ヶ月といった所定の計算期間における取引によって、
各参加企業が債権会社に位置づけられるか債務会社に位置づけられるかを決定し、債権会社には債権額を、債務会社には債務額を連絡するようになっている。 債権会社は、債権額を共通の口座から入金でき、一方、債務会社は、債務額を当該共通の口座に支払わなければならない。 【００２４】図３は、本実施の形態に適用されるスケジュールを示す図である。 本実施の形態では、債権額または債務額を確定することをネッティングといい、ネッティングが行われる日をネッティング日という。 また、債権額または債務額をネッティング額という。 図３では、
ネッティング日を▲で示す。 特に毎月１５日というように定められたネッティング日を定例ネッティング日といい、当該定例ネッティング日に固定されることなく、例えば、毎月６日、１６日、２６日といったように自由に設定できるネッティング日を随時ネッティング日という。 【００２５】ネッティング日に対して支払日が設定される。 図３では、△で示す。 例えば、毎月１５日の定例ネッティング日に対しては、翌月の１４日が支払日となる。 随時ネッティング日に対しては、例えば、７営業日後の日を支払日としてもよい。 【００２６】定例ネッティングについては、定例ネッティング日の翌日から次の定例ネッティング日までが、債権及び債務の計算期間となる。 一方、随時ネッティングについては、随時ネッティング日までの期間が、債権及び債務の計算期間となる。 本実施の形態では、かかる計算期間にあっては、請求金額及び支払金額（請求された金額）を積み上げ（累積し）、その後にネッティングを行う。 【００２７】図４（ａ）は、ファイル転送管理データベースＤＢ１の構成を示す図である。 ファイル転送管理データベースＤＢ１は、企業名、送信ファイル名、送信状態、受信ファイル名及び受信状態を設定できるようになっている。 ファイル転送管理データベースＤＢ１に企業名と送信ファイル名を設定し、送信状態を「送信可能」
に設定すれば、ファイル送受信部１１１が、当該企業名で特定される企業側システム２に対し、当該送信ファイル名を有するファイルを、ｆｔｐプロトコルで送信するようになっている。 【００２８】また、ファイル転送管理データベースＤＢ
１に企業名と受信ファイル名を設定し、受信状態を「受信可能」に設定すれば、ファイル送受信部１１１が、当該企業名で特定される企業側システム２から当該受信ファイル名を有するファイルをｆｔｐプロトコルで受信するようになっている。 【００２９】図４（ｂ）は、決済スケジュール管理データベースＤＢ４のレコードの構成を示す図である。 決済スケジュール管理データベースＤＢ４のレコードには、
ネッティング日及び支払日、並びに定例か随時かを識別するための識別子である定例随時識別を設定でき、このようなレコードを蓄積することにより図３に示すような日程を管理するようになっている。 【００３０】図５は、契約情報データベースＤＢ２、請求支払情報データベースＤＢ３、債権債務累積データベースＤＢ５及びネッティング結果データベースＤＢ６のレコードの構成と関連を示す図である。 実線は、データベース同士の関連づけにおけるキーとなるフィールドを示す。 点線矢印は、矢印の先にあるフィールドの値が、
矢印の元にあるフィールドの値によって求められることを示す。 【００３１】契約情報データベースＤＢ２は、２企業間でなされた１つの取引契約に対応するレコードに当該契約に関わる事項、つまり、契約を識別する契約登録番号、契約件名、契約期間、受注会社及び発注会社を設定できるようにしたデータベースである。 【００３２】請求支払情報データベースＤＢ３は、１回の金銭取引に対応するレコードに当該取引の請求及び支払いに関わる事項を設定できるようにしたデータベースである。 具体的にレコードには、請求会社、該請求会社が当該請求に付与する請求番号、請求金額、この請求に対し支払いを行う支払会社、該支払会社が当該支払いに付与する支払番号、支払金額が設定される。 また、取引の基となる契約を示す契約登録番号や役務提供期間が設定される。 また、債権や債務の積上日や、定例随時識別、ネッティング日、随時ネッティング日に対する支払日である随時支払日が設定される。 【００３３】債権債務累積データベースＤＢ５は、計算期間において１企業が１相手企業に対して請求した金額の合計と、請求された金額の合計とを設定できるようにしたレコードからなるデータベースである。 具体的には、企業名及び相手企業名、ネッティング日と当該ネッティングに対応する定例随時識別、並びに前記した各金額の合計が設定される。 【００３４】ネッティング結果データベースＤＢ６は、
１企業の１定例ネッティング日における債務額または債権額を設定するためのレコードからなるデータベースである。 具体的にレコードには、企業名および定例ネッティング日、並びに前記した債権額または債務額が設定される。 【００３５】さて、企業は先ず、企業間取引センタシステム１の管理会社との間で企業間取引センタシステム１
が提供するサービスを受けるための登録を行い、さらに、２企業間で、企業間取引センタシステム１を介した取引を行うための契約をかわす。 【００３６】図６は、企業間での契約時の処理を示すシーケンス図である。 例えば、受注側の企業の企業側システム２（図６では受注企業２）から、契約件名、契約期間、受注会社及び発注会社を含む契約情報が送信されると、この契約情報をファイル送受信部１１１が受信する（ステップＳ１）。 そして、契約情報取込部１２１が、
この契約情報に契約登録番号を付与し、契約情報データベースＤＢ２に格納する（ステップＳ２）。 通知情報作成部１２３は、契約情報の受信及び格納により、当該契約情報を通知するための情報である通知情報を作成し（ステップＳ３）、電子メールで、発注側の企業側システム２（図６では発注企業２）に送信する（ステップＳ
４）。 これとともに、契約情報自体も発注側の企業側システム２に送信される。 【００３７】発注側の企業側システム２からは、契約についての確認が通知される。 ファイル送受信部１１１
が、この通知を受信する（ステップＳ５）と、契約情報取込部１２１が、受信した情報を確認情報として格納し（ステップＳ６）、通知情報作成部１２３が、この確認情報を基にした通知情報を作成する（ステップＳ７）。
そして、ファイル送受信部１１１が、この通知情報を受注側の企業側システム２に電子メールで送信する（ステップＳ８）。 【００３８】企業間取引センタシステム１にあっては、
このような２企業間の契約が、多数組なされるが、企業間取引センタシステム１はまた、その管理会社のコンピュータからネットワークを介して投入されるネッティング日や支払日、つまりスケジュールを格納する。 なお、
かかる投入は契約前に行っても勿論よい。 【００３９】図７は、ネッティングスケジュール投入時の処理を示すシーケンス図である。 企業間取引センタシステム１を管理する管理会社のコンピュータ３（図７では管理会社３）から、定例随時識別、ネッティング日及び支払い日からなるネッティングスケジュールが、企業間取引センタシステム１に投入される（ステップＳ１
１）と、先ず決済スケジュール管理部１２４は、決済スケジュール管理データベースＤＢ４に登録済みスケジュールを表示装置に表示する（ステップＳ１２）。 【００４０】企業間取引センタシステム１のオペレータからの必要に応じた指示により、決済スケジュール管理部１２４は、スケジュールの追加変更を行う（ステップＳ１３）。 そして、登録変更内容に矛盾等（例えば、支払日がネッティング日に先行している等）が無いかをチェックし（ステップＳ１４）、チェックが済んだスケジュール（レコードの内容）を決済スケジュール管理データベースＤＢ４へ格納する（ステップＳ１５）。 【００４１】このようにして、スケジュールが企業間取引センタシステム１に設定されると、企業間での個々の金銭取引が可能となる。 【００４２】図８は、企業間での取引時の処理を示すシーケンス図である。 例えば、受注側の企業の企業側システム２（図８では受注企業２）から、契約登録番号、役務提供期間、請求会社、請求番号、支払会社、定例随時識別を含む請求情報（随時ネッティングすべき取引については随時支払日が加わる）が送信されると、この請求情報をファイル送受信部１１１が受信する（ステップＳ
２１）。 そして、請求支払情報取込部１２２が、この請求情報を、請求支払情報データベースＤＢ３のレコードとして格納する（ステップＳ２２）。 【００４３】通知情報作成部１２３は、請求情報の受信格納により、当該請求があった旨を通知するための通知情報を作成し（ステップＳ２３）、電子メールで、発注側の企業側システム２（図８では発注企業２）に送信する（ステップＳ２４）。 これとともに、請求情報自体も発注側の企業側システム２に送信される。 【００４４】発注側の企業側システム２から、請求を認める、つまり支払いを行ってもよい旨の確認として送信される支払番号と支払金額とを、ファイル送受信部１１
１が受信する（ステップＳ２５）と、請求支払情報取込部１２２が、これを確認情報として、請求情報を格納したレコードに格納する（ステップＳ２６）。 そして、通知情報作成部１２３が、この確認情報を基に通知情報を作成する（ステップＳ２７）。 そして、ファイル送受信部１１１が、この通知情報を、受注側の企業側システム２（図８では受注企業２）に、電子メールで送信する（ステップＳ２８）。 【００４５】このような処理により、請求支払情報データベースＤＢ３には、取引に対応したレコードが蓄積されていく。 なお、蓄積される請求金額と支払金額は、その決済が済むまでは、債権額及び債務額である。 【００４６】さて、このような処理は、企業側からの要求に応じて行う処理であるが、企業間取引センタシステム１にあっては、自らが以下の処理を行う。 【００４７】図９は、定例債権債務の積上の処理を示すフローチャートである。 定例ネッティング結果作成部１
２５は、以下の処理を、定例ネッティングの計算期間である１ヶ月よりも短い周期で、例えば、毎日の同一時刻に行う。 【００４８】先ず、定例ネッティング結果作成部１２５
は、請求支払情報データベースＤＢ３から、債権債務積上日及び随時支払日が共に設定されていないレコード（請求支払情報）を検索する（ステップＳ３１）。 次に、決済スケジュール管理データベースＤＢ４を参照して、最も早く到来する定例ネッテイング日を取得する（ステップＳ３２）。 【００４９】これ以降は、検索したレコードごとに処理を行う。 なお、処理対象であるレコードを処理対象レコードという。 先ず全てのレコードを処理したかを判定する（ステップＳ３３）。 ステップＳ３３でＮＯと判定されたときは、ステップＳ３４へと進む。 【００５０】ステップＳ３４では、債権債務累積データベースＤＢ５のレコードの中から、ステップＳ３２で取得したネッテイング日、処理対象レコードの請求会社及び支払会社が、ネッティング日、企業名及び相手企業名に一致し、かつ定例随時識別が定例であるものを検索し、この検索されたレコードの請求金額計に、処理対象レコードの請求金額を加算する。 なお、該当するレコードが検索されなかったときは、レコードを作成し、企業名等を設定してから金額を設定する。 【００５１】続くステップＳ３５では、債権債務累積データベースＤＢ５のレコードの中から、取得したネッテイング日、処理対象レコードの支払会社及び請求会社が、ネッティング日、企業名及び相手企業名に一致し、
かつ定例随時識別が定例であるものを検索し、この検索されたレコードの支払金額計に、処理対象レコードの支払金額を加算する。 なお、該当するレコードが検索されなかったときは、レコードを作成し、企業名等を設定してから加算する。 【００５２】続くステップＳ３６では、処理対象レコードの債権債務積上日には現在の日付を、定例随時識別には定例を、ネッテイング日には取得したネッテイング日を設定する。 【００５３】そして、ステップＳ３３へ戻る。 ステップＳ３３でＹＥＳと判定されたとき、つまり処理対象レコードを全て処理したときは、定例ネッティング結果作成部１２５は、定例債権債務の積上を終える。 【００５４】企業間取引センタシステム１は、このような債権債務の積上を、随時ネッティングされるべき取引についても行う。 【００５５】図１０は、随時債権債務の積上の処理を示すフローチャートである。 随時ネッティング結果作成部１２６は、以下の処理を、例えば、毎日の同一時刻に行う。 先ず、請求支払情報データベースＤＢ３から、債権債務積上日が設定されてなく、かつ随時支払日が設定されているレコードを検索する（ステップＳ４１）。 【００５６】これ以降は、検索したレコードごとに処理を行う。 なお、処理対象であるレコードを処理対象レコードという。 先ず全てのレコードを処理したかを判定する（ステップＳ４２）。 ステップＳ４２でＮＯと判定されたときは、ステップＳ４３へと進む。 【００５７】ステップＳ４３では、決済スケジュール管理データベースＤＢ４のレコードの中から、処理対象レコードの随時支払日が、支払い日に一致し、かつ定例随時識別が随時に設定されているものを検索し、この検索されたレコードのネッティング日を取得する（ステップＳ４３）。 【００５８】続くステップＳ４４では、債権債務累積データベースＤＢ５のレコードの中から、ステップＳ４３
で取得したネッテイング日、処理対象レコードの請求会社及び支払会社が、ネッティング日、企業名及び相手企業名に一致し、かつ定例随時識別が随時であるものを検索し、この検索されたレコードの請求金額計に、処理対象レコードの請求金額を加算する。 なお、該当するレコードが検索されなかったときは、レコードを作成し、企業名等を設定してから金額を設定する。 【００５９】続くステップＳ４５では、債権債務累積データベースＤＢ５のレコードの中から、取得したネッテイング日、処理対象レコードの支払会社及び請求会社が、ネッティング日、企業名及び相手企業名に一致し、
かつ定例随時識別が随時であるものを検索し、この検索されたレコードの支払金額計に、処理対象レコードの支払金額を加算する。 なお、該当するレコードが検索されなかったときは、レコードを作成し、企業名等を設定してから金額を設定する。 【００６０】続くステップＳ４６では、処理対象レコードの債権債務積上日にはシステム日付を、定例随時識別には随時を、ネッテイング日には取得したネッテイング日を設定する。 【００６１】そして、ステップＳ４２へ戻る。 ステップＳ４２でＹＥＳと判定されたとき、つまり処理対象レコードを全て処理したときは、随時ネッティング結果作成部１２６は、随時債権債務の積上を終える。 【００６２】図１１は、定例ネッティング結果の作成処理を示すフローチャートである。 定例ネッティング結果作成部１２５は、以下の処理を、例えば、毎日の同一時刻に行う。 【００６３】先ず、決済スケジュール管理データベースＤＢ４のレコードの中から、定例随時識別が定例に設定されているものを選択し、このレコードのネッティング日が現在の日付であるか否かを判定する（ステップＳ５
１）。 ここで、ＹＥＳと判定されたときは、ステップＳ
５２へと進む。 【００６４】ステップＳ５２以降は、１企業ごとに処理を行うが、先ず全企業分処理したかを判定する（ステップＳ５２）。 ＮＯと判定されたときは、ステップＳ５３
へ進む。 【００６５】ステップＳ５３では、先ず、債権債務累積データベースＤＢ５のレコードの中から、処理対象の企業名が企業名に設定され、ネッティング日が現在の日付であり、かつ定例随時識別が定例であるレコードを全て選択する。 そして、これらレコードの請求金額計を集計する。 また、支払金額計を集計する。 つまり、取引の相手企業に関係なく集計を行うのである。 【００６６】そして、ステップＳ５４では、集計された請求金額計から、集計された支払金額計を減じる、つまり相殺することにより、債権額または債務額、つまりネッティング額を確定する。 当該計算により得た値がプラスの場合は債権額とし、マイナスの場合は債務額として確定する。 なお、定例ネッティング結果作成部１２５
は、ネッティング結果データベースＤＢ６に新たなレコードを生成し、当該ネッティング日、当該処理対象の企業名、確定した債権額または債務額をそのレコードに設定する。 【００６７】次に、ステップＳ５５では、当該処理対象企業宛のネッティング結果ファイルを作成する。 定例ネッティング結果作成部１２５は、ネッティング結果ファイルに、その企業が請求した総請求額、支払うべき総支払額、確定した債権額または債務額、相手会社別の請求額及び支払額の合計を含ませる。 【００６８】そして、ステップＳ５２へと戻る。 ステップＳ５２でＹＥＳと判定されたときは、ステップＳ５６
へ進む。 【００６９】ステップＳ５６では、ネッティング結果データベースＤＢ６に基づき、管理会社宛のネッティング結果ファイルを作成する。 定例ネッティング結果作成部１２５は、ネッティング結果ファイルに、企業別の債権額または債務額を含ませる。 そして、ステップＳ５７では、送信準備として、ファイル転送管理データベースＤ
Ｂ１の送信状態を送信可能にし、送信ファイル名にネッティング結果ファイル名を設定して、処理を終了させる。 なお、ステップＳ５１でＮＯと判定されたときは、
そのネッティング日については、処理が不要であるので、当該処理を終了させる。 【００７０】図１２は、随時ネッティング結果の作成処理を示すフローチャートである。 随時ネッティング結果作成部１２６は、以下の処理を、例えば、毎日の同一時刻に行う。 【００７１】先ず、決済スケジュール管理データベースＤＢ４の、定例随時識別が随時に設定されているレコードを選択し、このレコードのネッティング日が現在の日付であるか否かを判定する（ステップＳ６１）。 ここで、ＹＥＳと判定されたときは、ステップＳ６２へと進む。 【００７２】ステップＳ６２以降は、１企業ごとに処理を行うが、先ず全企業分処理したかを判定する（ステップＳ６２）。 ＮＯと判定されたときは、ステップＳ６３
へ進む。 【００７３】ステップＳ６３以降は、１企業の相手企業ごとに処理を行う。 先ず、ステップＳ６３でネッティング額を確定する。 【００７４】つまり、先ず、債権債務累積データベースＤＢ５のレコードの中から、処理対象の企業名が企業名に設定され、処理対象の相手企業名が相手企業名に設定され、ネッティング日が現在の日付であり、かつ定例随時識別が随時であるレコードを全て選択する。 そして、
これらレコードの請求金額計を集計する。 また、支払金額計を集計する。 そして、前者から後者を差し引く、つまり相殺することで、相手企業についてのネッティング額を確定するのである。 【００７５】なお、随時ネッティング結果作成部１２６
は、ネッティング結果データベースＤＢ６に新たなレコードを生成し、当該ネッティング日、当該処理対象の企業名、確定した債権額または債務額をレコードに設定する。 【００７６】続くステップＳ６４では、相手企業分を全て処理したかを判定する。 ここでＮＯと判定されたときは、ステップＳ６３へ戻り、さらに別の相手企業についてネッティング額を確定する。 【００７７】ステップＳ６４でＹＥＳと判定されたときは、ステップＳ６５へ進み、当該企業宛のネッティング結果ファイルを作成する。 随時ネッティング結果作成部１２６は、このネッティング結果ファイルに、相手会社別の請求金額計、相手会社別の支払金額計、相手会社別のネッティング額を含める。 そして、ステップＳ６２へ戻り、ここで、ＹＥＳと判定されたときは、ステップＳ
６６へと進む。 【００７８】そして、ステップＳ６６では、送信準備として、ファイル転送管理データベースＤＢ１の送信状態を送信可能にし、送信ファイル名にネッティング結果ファイル名を設定して、処理を終了させる。 なお、ステップＳ６１でＮＯと判定されたときは、そのネッティング日については、処理が不要であるので、当該処理を終了させる。 【００７９】そして、図１３に示すように、定例ネッティング結果の作成（ステップＳ７１）において、送信準備された定例ネッティング結果（ファイル）が、ステップＳ７２及びＳ７３で、管理会社のコンピュータ３（図１３では管理会社３）と、参加企業の企業側システム２
（図１３では参加企業２）の双方に送信される。 また、
随時ネッティング結果の作成（ステップＳ８１）において送信準備された随時ネッティング結果（ファイル）
が、ステップＳ８２で、参加企業の企業側システム２に送信される。 【００８０】なお、上記説明した処理を実行する本発明に係る債権債務処理プログラムは、半導体メモリ、磁気ディスク、光ディスク、光磁気ディスク、磁気テープなどのコンピュータ読み取り可能な記録媒体に記録したり、インターネットなどの通信網を介して伝送させて、
広く流通させることができる。 【００８１】 【発明の効果】以上説明したように、本発明によれば、
３以上の主体のそれぞれの予め設定された計算期間における債権額または債務額を、当該主体のそれぞれが当該計算期間に行った取引により記録された債権額及び債務額を取引の相手にかかわらず集計及び相殺して求めるようにしたので、取引の主体である企業等は、多くの相手と取引する場合であっても、少ない労力で決済が行える。

【図面の簡単な説明】 【図１】本発明の実施の形態に係る企業間取引センタシステム１の構成及び利用形態を示す図である。 【図２】本実施の形態の概要を示す図である。 【図３】本実施の形態に適用されるスケジュールを示す図である。 【図４】図４（ａ）は、ファイル転送管理データベースＤＢ１の構成を示す図である。 図４（ｂ）は、決済スケジュール管理データベースＤＢ４のレコードの構成を示す図である。 【図５】契約情報データベースＤＢ２、請求支払情報データベースＤＢ３、債権債務累積データベースＤＢ５及びネッティング結果データベースＤＢ６のレコードの構成と関連を示す図である。 【図６】企業間での契約時の処理を示すシーケンス図である。 【図７】ネッティングスケジュール投入時の処理を示すシーケンス図である。 【図８】企業間での取引時の処理を示すシーケンス図である。 【図９】定例債権債務の積上の処理を示すフローチャートである。 【図１０】随時債権債務の積上の処理を示すフローチャートである。 【図１１】定例ネッティング結果の作成処理を示すフローチャートである。 【図１２】随時ネッティング結果の作成処理を示すフローチャートである。 【図１３】ネッティング結果の送信の様子を示すフローチャートである。 【図１４】従来の企業間取引センタシステム１００による管理運用を示す図である。 【符号の説明】 １ 企業間取引センタシステム２ 企業側システム３ 管理会社のコンピュータ１１ Ｉ／Ｆ部１２ 処理部１１１ ファイル送受信部１２１ 契約情報取込部１２２ 請求支払情報取込部１２３ 通知情報作成部１２４ 決済スケジュール管理部１２５ 定例ネッティング結果作成部１２６ 随時ネッティング結果作成部ＤＢ１ ファイル転送管理データベースＤＢ２ 契約情報データベースＤＢ３ 請求支払情報データベースＤＢ４ 決済スケジュール管理データベースＤＢ５ 債権債務累積データベースＤＢ６ ネッティング結果データベース

───────────────────────────────────────────────────── フロントページの続き (72)発明者 森川 澄夫 東京都新宿区西新宿三丁目20番２号 エ ヌ・ティ・ティ・ビジネスアソシエ株式会 社内(72)発明者 横田 浩二 東京都新宿区西新宿三丁目20番２号 エ ヌ・ティ・ティ・ビジネスアソシエ株式会 社内(72)発明者 大屋 浩一 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コムウェア株式会社内(72)発明者 東 達也 東京都港区港南一丁目９番１号 エヌ・テ ィ・ティ・コムウェア株式会社内