JP2001283115A - 企業間代金決済管理システム及びこれらを用いた企業間代金決済管理方法 - Google Patents

企業間代金決済管理システム及びこれらを用いた企業間代金決済管理方法

Info

Publication number
JP2001283115A
JP2001283115A JP2001038848A JP2001038848A JP2001283115A JP 2001283115 A JP2001283115 A JP 2001283115A JP 2001038848 A JP2001038848 A JP 2001038848A JP 2001038848 A JP2001038848 A JP 2001038848A JP 2001283115 A JP2001283115 A JP 2001283115A
Authority
JP
Japan
Prior art keywords
entity
sales
payment
information
series
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2001038848A
Other languages
English (en)
Inventor
Dong Lyun Yim
ドン リュン イム,
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SHINHAN BANK
Original Assignee
SHINHAN BANK
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SHINHAN BANK filed Critical SHINHAN BANK
Publication of JP2001283115A publication Critical patent/JP2001283115A/ja
Pending legal-status Critical Current

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02Banking, e.g. interest calculation or account maintenance
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00Payment architectures, schemes or protocols
    • G06Q20/08Payment architectures
    • G06Q20/10Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102Bill distribution or payments

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Economics (AREA)
  • Strategic Management (AREA)
  • Development Economics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (AREA)
  • Technology Law (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

(57)【要約】 【課題】 企業間取引の増加趨勢に合わせて、販売業体
および購買業体間の代金決済関係が重大な社会的問題に
なっている。 【解決手段】 購買業体側通信クライアントまたは販売
業体側通信クライアントから購買代金支払明細表管理イ
ベント、販売代金先支給申請イベント等が発生される毎
に、代金管理サ−バ−、認証モジュ−ル、購買代金支払
い明細表管理モジュ−ル、先支給金回収管理モジュ−
ル、口座管理モジュ−ル等を緊密に連繋させ、一連の購
買代金支払明細表管理過程、販売代金先支給管理過程等
を体系的に進行させることにより、任意の購買業体、販
売業体等がオンライン網を基盤に、信頼性ある代金決済
関係を容易に形成できるように誘導する。

Description

【発明の詳細な説明】
【0001】
【発明の属する技術分野】本発明は企業間代金決済管理
システムに関し、さらに詳しくは、販売業体及び購買業
体の間に行われる全体的な代金決済過程を銀行オンライ
ン網を基にして体系的に具現することにより、販売業体
及び購買業体が自社に必要な販売代金収金過程、購買代
金支払過程等をさらに信頼性を持って進行させることが
できるように誘導できる企業間代金決済管理システムに
関するものである。さらに、本発明はこのような企業間
代金決済管理システムを用いた企業間代金決済管理方法
に関するものである。
【0002】
【従来の技術】最近、経済発展の速度が加速化されるに
つれて、企業間取り引きの頻度数また著しい増加趨勢を
現わしており、このような企業間取り引きの増加趨勢に
合わせて、販売業体及び購買業体間の代金決済関係が重
大な社会的イッシュになりつつある。
【0003】このように販売業体及び購買業体間の代金
決済関係が重大な社会的イッシュになりつつある理由は
例えば、販売業体及び購買業体間の代金決済関係が信頼
性を有して成されていないため個別企業が倒産する場
合、国家の基幹経済秩序が破壊され、その波及効果によ
り全体的な社会秩序が崩れる深刻な問題点が惹起される
こともできるためである。
【0004】上述した企業間取り引きが形成される際、
通常、一連の品物、用役などを販売した販売業体では購
買業体を対象に、一連の代金請求過程を進行するのが一
般的であるが、従来の場合、大部分の購買業体では現金
(Cash)より手形(Bill)を代金決済の重要な手段として好
んでいる。これは代金決済手段として手形を活用する場
合、該購買業体では全体的な資金回転を現金決済に比べ
て、さらに融通が効くように行わせる利点を容易に獲得
できるためである。
【0005】しかしながら、前述した従来の実物手形は
一連の“交付‥取りたて‥”等の複雑な過程を経て発行
されるのが一般的であるため、この手形が主要決済手段
で使われる場合、“購買業体及び販売業体”両側では共
に予測できない多くの不便さを甘受せざるを得ない。さ
らに、このような実物手形はオフライン(Off-line)上で
流通されるのが一般的なので、常時に盗難、紛失等を内
包しており、これらを使う“購買業体及び販売業体”で
は常に必要以上の注意を傾けなければならない不便さを
甘受せざるをえないようになる。
【0006】また、前述した手形はその発行日と実質的
な現金支払日が互いに相違な特性を有しているので、購
買業体から手形を発給された販売業体は常時"購買代金
が支払われないこともありうる危険性"を甘受するしか
ないし、もし、この危険性が現実化されて、手形を発行
した購買業体が実質的な"購買代金支払過程"を履行しな
かった状態で、急に倒産する場合、販売業体は自分の意
志とは関係なく莫大な被害を被るようになる。
【0007】この際、該販売業体が異なる業体とまた異
なる代金決済関係を結んでいる場合、購買業体の倒産は
異なる多くの販売業体の連鎖不渡りに繋がるようにな
り、これらを放置する場合、全体的な経済秩序が急激に
崩れる深刻な社会問題が惹起されるようになる。
【0008】
【発明が解決しようとする課題】従って、本発明の目的
は銀行オンライン網を基盤に、販売業体が購買業体を相
手に取得した将来の売出債権を販売業体から譲渡され
て、これらを担保にして購買業体が支払うべき購買代金
をオンライン上で予め先支給してあげることにより、該
購買業体が販売業体を対象にする一連の代金決済関係を
さほど資金負担なしに、さらに容易に形成することがで
きるように誘導することにある。
【0009】本発明のもう一つの目的は購買業体による
従来の手形使用を予め排除し、これらを通じて、販売業
体及び購買業体間に形成される代金決済関係の信頼性を
大幅向上させることにより、予測できなかった販売業体
の被害を最小化させることにある。
【0010】本発明のもう一つの目的は販売業体及び購
買業体の間に行われている全体的な代金決済過程をオン
ライン上で体系的に具現することにより、販売業体及び
購買業体がオンライン網を基盤にして、自社に必要な販
売代金収金過程、購買代金支払過程を不必要な盗難、紛
失などの危険性なしにさらに容易に進行させることが出
来るように誘導することにある。
【0011】本発明のもう一つの目的は購買業体及び販
売業体の間に形成される代金決済関係の信頼性を向上さ
せることにより、多くの業体の連鎖不渡りによる経済的
被害を最小化させることにある。
【0012】本発明のもう一つの目的は次の詳細な説明
と添付された図面からより明確になるであろう。
【0013】
【課題を解決するための手段】上記のような目的を達成
するために本発明ではD/Bブロック、D/B管理サ−バ−、
代金管理サ−バ−の組み合いで成された企業間代金決済
管理システムを開示する。この場合、D/Bブロックでは
一連の認証情報が貯蔵されたデ−タベ−ス(D/B:Data Ba
se;以下、"D/B"と呼ぶ)、一連の購買代金支払明細表情
報が貯蔵された購買代金支払明細表情報 D/B、一連の貸
出金先支給情報が貯蔵された貸出金先支給情報 D/B、一
連の信用カ−ド売出表買入代金先支給情報が貯蔵された
信用カ−ド売出表買入代金先支給情報 D/B、一連の登録
情報が貯蔵された登録情報が D/Bが備えられる。
【0014】この際、D/Bブロックは前に言及した認証
情報、購買代金支払明細表情報、貸出金先支給情報、信
用カ−ド売出表買入代金先支給情報、登録情報等を上記
D/Bブロックの必要領域に選択的に貯蔵するか、または
この D/Bブロックの必要領域から上述したそれぞれの情
報を選択的に取り出す役割を遂行する。
【0015】ここで、上述した代金管理サ−バ−は上の
D/B管理サ−バ−と一連の通信関係を形成した状態で、
上述した認証情報、購買代金支払明細表情報、貸出金先
支給情報、信用カ−ド売出表買入代金先支給情報等の貯
蔵及び抽出与否を決定する役割を遂行する。
【0016】これとともに、代金管理サ−バ−は任意の
購買業体側通信クライアント及び販売業体側通信クライ
アントと銀行オンライン網を通じてインタ−フェ−スし
た状態で、購買業体側通信クライアント及び販売業体側
通信クライアントにより一連の購買代金支払い明細表管
理イベント及び販売代金先支給申請イベントが発生する
場合、上述した種々の情報を体系的に組み合って、購買
業体側が支払うべき購買代金を販売業体側にオンライン
に先支給するとともに、所定期日が経ってから、該先支
給金に当たる金額を購買業体からオンラインに回収する
役割を遂行する。
【0017】
【発明の実施の形態】以下、添付された図面を参照し
て、本発明による企業間代金決済管理システム及びこれ
らを用いた企業間代金決済管理方法をさらに詳しく説明
すると次の通りである。
【0018】図1に示したように、本発明による企業間
代金決済管理システム(100)は購買業体(400)及び多数の
販売業体(500)間の代金決済関係を信頼性を有して管理
できる特定金融機関、例えば、銀行(300)の電算オンラ
イン網に属される。
【0019】ここで、図2に示したように、銀行(300)
の電算オンライン網に属された本発明の企業間代金決済
管理システム(100)は大きく、D/Bブロック(80)、D/B管
理サ−バ−(70)、代金管理サ−バ−(10)等の組み合いで
成されている。この場合、前の D/Bブロック(80)には一
連の認証情報が貯蔵された認証情報D/B(81) 、一連の購
買代金支払明細表情報が貯蔵された購買代金支払明細表
情報 D/B(82)、一連の貸出金先支給情報が貯蔵された貸
出金先支給情報 D/B(83)、一連の信用カ−ド売出表買入
代金先支給情報が貯蔵された信用カ−ド売出表買入代金
先支給情報 D/B(84)、一連の運営情報が貯蔵された運営
情報 D/B(85)、一連の購買業体(400)/販売業体(500)関
連登録情報が貯蔵された登録情報D/B(86)等が配置され
る。
【0020】この際、前に言及したD/B管理サ−バ−(7
0)は上述した認証情報、購買代金支払明細表情報、販売
代金収金明細表情報、貸出申請情報、信用カ−ド売出表
買入申請情報、売出債権譲渡担保情報、運営情報、登録
情報等を D/Bブロック(80)の必要領域に選択的に貯蔵す
るか、または前の認証情報D/B(81) 、購買代金支払明細
表情報 D/B(82)、販売代金収金明細表情報 D/B(83)、信
用カ−ド売出表買入代金先支給情報 D/B (84)、運営情
報D/B(85)、登録情報D/B(86)等から上述したそれぞれの
デ−タを選択的に出力する役割を行う。
【0021】この場合、D/B管理サ−バ−(70)はただ種
々のデ−タを貯蔵、出力する役割を遂行するだけでな
く、種々のデ−タは重複されることなく一番迅速な時間
内に効率的に管理する知能的な役割を同時に遂行する。
【0022】この際、図面に示したように、上述した代
金管理サ−バ−(10)は任意の購買業体(400)側通信クラ
イアント(1),販売業体(500)側通信クライアント(2)等と
例えば、インタ−フェ−スモジュ−ル(20)を媒介にイン
タ−フェ−スする。
【0023】この場合、任意の購買業体(400)側通信ク
ライアント(1), 例えば、"購買業体側コンピュ−タ−(1
a)"、"購買業体側有/無線電話機(1b)"等と、販売業体
(500)側通信クライアント(2)、例えば、"販売業体側コ
ンピュ−タ−(2a)"、"販売業体側有無線電話機 (2b)"等
は一連の銀行オンライン網、例えば、インタ−ネット
網、自動応答通信網(Automatic Response System Commu
nication Network), 付加価値通信網(VAN: Value Added
Network), 公衆電話網(PSTN: Public Switched Teleph
one Network)等を用いて本發明の企業間代金決済管理シ
ステム(100)に接続する。
【0024】この状態で、 代金管理サ−バ−(10)は認
証モジュ−ル(30)、購買代金支払明細表管理モジュ−ル
(40)、先支給金回収管理モジュ−ル(50)、運営情報管理
モジュ−ル(60)等を媒介にD/B管理サ−バ−(70)を体系
的に制御して、上述した認証情報、購買代金支払明細表
情報、貸出金先支給情報、信用カ−ド売出表買入代金先
支給情報、運営情報等の貯蔵及び取り出し与否を決定す
る役割を遂行する 。
【0025】これと共に、代金管理サ−バ−(10)は上述
した購買業体(400)側通信クライアント(1)及び販売業体
(500)側通信クライアント(2)から一連の購買代金支払明
細表管理イベント及び販売代金先支給申請イベントが発
生する場合、上述した認証情報、購買代金支払明細表情
報、貸出金先支給情報、信用カ−ド売出表買入代金先支
給情報 、運営情報、登録情報等を体系的に組み合っ
て、購買業体(400)側が支払うべき購買代金を販売業体
(500)側にオンラインで先支給するとともに、所定期日
が経ってから、該先支給金に相当する金額を購買業体(4
00)側からオンラインで回収する役割を遂行する。
【0026】この際、上述した認証モジュ−ル(30)は購
買業体(400)側通信クライアント(1)、販売業体(500)側
通信クライアント(2)等を通じて本発明の企業間代金決
済管理システム(100)に接近する任意の" 購買業体(40
0)、販売業体(500)"の既登録与否を前の認証情報D/B(8
1)を活用して認証する役割を専担し、購買代金支払明細
表管理モジュ−ル(40)は購買業体(400)側通信クライア
ント(1)から伝送される購買代金支払い明細表を上の購
買代金支払明細表情報 D/B(82)を活用して管理する役割
を専担する。
【0027】なお、先支給金回収管理モジュ−ル(50)
は、システム(100)側が販売業体側に先支給した先支給
金を前述の貸出金先支給情報 D/B(83) 、信用カ−ド売
出表買入代金先支給情報 D/B(84) 情報等を活用して管
理する役割を専担し、運営情報管理モジュ−ル(60)は代
金管理サ−バ−(10)の細部運営事項を前の運営情報 D/B
(85)等を活用して管理する役割を専担する。
【0028】この際、図面に示したように、口座管理モ
ジュ−ル(90)は上の認証モジュ−ル(30)、購買代金支払
明細表管理モジュ−ル(40)、先支給金回収管理モジュ−
ル(50)、運営情報管理モジュ−ル(60)等と類似に代金管
理サ−バ−(10)と緊密な通信連結関係を形成した状態
で、システム(100)側に指定されたシステム側指定口座
(92)、購買業体(400)側に指定された購買業体側指定口
座(91)、販売業体(500)側に指定された販売業体側指定
口座(93)等を管理する役割を専担する。
【0029】以下、上述した構成を有する本発明の企業
間代金決済管理システム(100)を用いた企業間代金決済
管理方法を詳細に説明する。
【0030】先に、所定の商品、用役等を購買した購買
業体(400) またはこれらの商品、用役等を販売した多数
の販売業体(500)は、上述した購買業体(400)側通信クラ
イアント(1), 例えば、購買業体側コンピュ−タ−(1a)
と、 販売業体(500)側通信クライアント(2)、例えば、
販売業体側コンピュ−タ−(2a)を用いて、本発明の企業
間代金決済管理システム(100)に接続する。勿論、該購
買業体(400)、販売業体(500)等は購買業体側コンピュ−
タ−(1a)、販売業体側コンピュ−タ−(2a)以外の異なる
通信クライアント、例えば、購買業体側有/無線通信機
(1b)、販売業体側有/無線通信機 (2b)等を選択して、
本発明の企業間代金決済管理システム(100)に接続して
もよい。
【0031】もし、該購買業体(400)、販売業体(500)等
が購買業体側有/無線通信機(1b)、販売業体側有/無線
通信機 (2b)等を選択して、一連の接続過程を行ってい
る際に、通信中継局(200)はこれらの購買業体側有/無
線通信機(1b)、販売業体側有/無線通信機 (2b)から出
力されるデ−タをシステム側(100)のインタ−フェ−ス
モジュ−ル(20)に伝達するか、またはシステム側(100)
のインタ−フェ−スモジュ−ル(20)から出力されるデ−
タを購買業体側有無線通信機(1b)、販売業体側有無線通
信機 (2b)等に伝達する役割を遂行する。
【0032】このような基盤環境が揃えられた状態で、
図3に示したように、代金管理サ−バ−(10)は、購買業
体側コンピュ−タ−(1a)または販売業体側コンピュ−タ
−(2a)のうちのいずれかの一つから一連のシステム接続
イベントが発生したかの与否を判断する(段階S1)。
【0033】この際、購買業体側コンピュ−タ−(1a)ま
たは販売業体側コンピュ−タ−(2a)から上述したシステ
ム接続イベントが発生しなかったことに判断される場
合、代金管理サ−バ−(10)はフロ−を後述する段階S11
に進行する。
【0034】しかし、購買業体側コンピュ−タ−(1a)ま
たは販売業体側コンピュ−タ−(2a)のうちのいずれの一
つから一連のシステム接続イベントが発生した場合、代
金管理サ−バ−(10)は運営情報管理モジュ−ル(60)を活
用して、運営情報D/B(80)に貯蔵されている一連の運営
情報を取り出されてから、この運営情報を活用して、一
連の認証要求メッセ−ジを生成し、生成の完了した認証
要求メッセ−ジをシステム接続イベントを発生させた該
コンピュ−タ−に伝送する(段階S2)。
【0035】もし、購買業体側コンピュ−タ−(1a)から
システム接続イベントが発生した場合、これらの認証要
求メッセ−ジは購買業体側コンピュ−タ−(1a)に伝送さ
れ、かつ販売業体側コンピュ−タ−(2a)からシステム接
続イベントが発生した場合、これらの認証要求メッセ−
ジは販売業体側コンピュ−タ−(2a)に伝送される。
【0036】この場合、該コンピュ−タ−、例えば、購
買業体側コンピュ−タ−(1a)は代金管理サ−バ−(10)か
ら伝送された認証要求メッセ−ジを解釈して、これらを
ディスプレ−させることにより、該購買業体(400)が一
連の認証過程を速やかに行われてもらうようにし、一
方、販売業体側コンピュ−タ−(2a)は代金管理サ−バ−
(10)から伝送された認証要求メッセ−ジを解釈して、こ
れらをディスプレ−させることにより、該販売業体(50
0)が一連の認証過程を速やかに行われてもらうようにす
る。
【0037】この状態で、代金管理サ−バ−(10)はイン
タ−フェ−スモジュ−ル(20)を持続的にチェクすること
により、購買業体側コンピュ−タ−(1a)または販売業体
側コンピュ−タ−(2a)から一連の認証情報が伝送された
かの与否を判断する(段階S3)。
【0038】この際、購買業体側コンピュ−タ−(1a)ま
たは販売業体側コンピュ−タ−(2a)から別途の認証情報
が伝送されなかったことに判断すると、代金管理サ−バ
−(10)は購買業体側コンピュ−タ−(1a)または販売業体
側コンピュ−タ−(2a)がまだ、一連の認証情報入力過程
を完了しなかったことに判定し、フロ−を段階S4に進行
して、一連の待機状態を維持する。
【0039】しかしながら、購買業体側コンピュ−タ−
(1a)または販売業体側コンピュ−タ−(2a)から一連の認
証情報が伝送されたことに判断されると代金管理サ−バ
−(10)は認証モジュ−ル(30)を迅速に活用することによ
り、購買業体側コンピュ−タ−(1a)または販売業体側コ
ンピュ−タ−(2a)を通じて企業間代金決済管理システム
(100)に接続中である購買業体(400)または販売業体(50
0)が既登録された業体であるかの与否を判断する(段階
S5)。
【0040】ここで、購買業体(400)が既登録された業
体で認証をしてもらうためには 銀行(300)側と別途の購
買業体約定、例えば、"協約書約定"、"信用カ−ド發給
約定"等を予め締結し、それらの情報が認証情報D/B(81)
に予め記録しておかないとだめであり、販売業体(500)
が既登録された業体として認証してもらうためには銀行
(300)側と別途の販売業体約定、例えば、"貸出約定"、"
信用カ−ド加盟店特約"等を締結し、それらの情報が購
買業体(400)と同じく、認証情報D/B(81)に前もって記録
しておかないとだめである。勿論、これらの条件を先決
しなかった購買業体(400)、販売業体(500)等は登録され
た業体として認証してもらうことが出来なくて、結局、
本発明による一連のサ−ビスが享有することができな
い。
【0041】この際、システム(100)に接続中である業
体が登録されてないことに判断される場合、代金管理サ
−バ−(10)は例えば、"貴社は登録されたお客様でない
ので、予め登録して下さい"等との内容の登録要求メッ
セ−ジを生成し、生成の完了した登録要求メッセ−ジを
該業体側コンピュ−タ−に伝送する過程を進行する(段
階S6)。
【0042】しかし、システム(100)に接続中である業
体が登録された業体に判断される場合、代金管理サ−バ
−(10)は例えば、運営情報管理モジュ−ル(60)等を活用
して、登録情報D/B(86)に貯蔵された該業体の登録情報
を収集した後、該業体が購買業体(400)であるかまたは
販売業体(500)であるかの与否を判断する(段階S7)。
【0043】この際、該業体が購買業体(400)に判断さ
れる場合、代金管理サ−バ−(10)は該購買業体が反映さ
れた一連の購買業体用初期ペ−ジを生成し、生成の完了
した購買業体用初期ペ−ジを購買業体側コンピュ−タ−
に伝送する(段階S8)。
【0044】この場合、購買業体側コンピュ−タ−(1
a)はこの購買業体用初期ペ−ジ (601)を速やかに解釈
し、これを図4に示したようにディスフレ−させること
により、購買業体(400)による一連の購買代金支払明細
表管理過程が円滑に進行されることのできる基盤環境を
提供する。
【0045】しかし、該業体が販売業体(500)に判断さ
れる場合、代金管理サ−バ−(10)は該販売業体の登録情
報が反映された一連の販売業体用初期ペ−ジを生成し、
生成の完了した販売業体用初期ペ−ジを販売業体側コン
ピュ−タ−(2a)に伝送する(段階S6a)。
【0046】この場合、販売業体側コンピュ−タ−(2a)
はこの販売業体用初期ペ−ジ (607)を速やかに 解釈
し、これを図5に示したようにディスフレ−させること
により、 販売業体(500)による一連の販売代金先支給申
請過程が円滑に進行されることのできる基盤環境を提供
する。
【0047】ここで、購買代金支払い明細表は所定の商
品、用役等を購買した購買企業が該商品、用役等を販売
した販売業体(500)を対象にある種類の決済過程を進行
したかを表わす明細表を指し示すのであるが、もし、購
買業体(400)がこの購買代金支払い明細表として、例え
ば、" 売出債券明細表"を伝送する場合、これは" 売出
債券を通じて購買代金を決済した"とのことを意味し、
購買代金支払明細表として、例えば、" 信用カ−ド売出
表"を伝送する場合、これは"企業 専用信用カ−ドを用
いて購買代金を決済した"とのことを意味する。この
際、 企業専用カ−ドは本發明の企業間代金決済管理シ
ステム(100)を備えた銀行(300)が前述の"信用カ−ド発
給約定"を先決した購買業体(400)を対象に特別に発給し
たカ−ドである。
【0048】この際、図5に示したように、購買業体側
コンピュ−タ−(1a)の購買業体用初期ペ−ジ(601)には
例えば、信用カ−ド売出表伝送項目(602a)、信用カ−ド
売出表伝送内訳照会項目(603a)、売出債券明細表伝送項
目(602b)、売出債券明細表伝送内訳照会項目(603b)、支
給内訳照会項目(604)、延滞内訳照会項目(605)、処理結
果照会項目(606)等が備えて、購買業体(400)では前述の
それぞれの項目は選択的にクリックすることにより、該
項目を実時間確認/設定することができる。勿論、これ
らのそれぞれの項目は状況によって多様に変形を成すこ
とができる。
【0049】なお、図6に示したように、販売業体側コ
ンピュ−タ−(2a)の販売業体用初期ペ−ジ(607)には例
えば、販売代金先支給申請内訳照会項目(608)、販売
内訳照会項目 (609)、貸出申請項目(610a)、信用カ−ド
売出表買入申請項目(610b)等が備えられ、販売業体(50
0)では前述の購買業体(400)の場合と類似に、それぞれ
の項目を選択的にクリックすることにより、該項目を実
時間確認/設定することができる。勿論、このようなそ
れぞれの項目はまた状況によって多様な変形を成すこと
ができる。
【0050】この際、販売業体(500)では例えば、貸出
申請項目(610a)を選択して、一連の貸出申請情報を生成
することができるのであるが、この場合、貸出申請情報
は一連の品物、用役等を販売した販売業体(500)が"売出
債券を通じて、該品物、用役等の購買代金を決済した"
購買業体(400)と連繋された銀行(300)を対象に伝送する
販売代金先支給申請情報を意味し、本発明のシステム(1
00)はこのような"貸出申請情報"に基づいて、一定額の
貸出金を購買業体(400)に変わって、予め先支給するこ
とになり、結局、販売業体(500)は自分の販売した品
物、用役等の販売代金を前もって収金できるようにな
る。
【0051】また、販売業体(500)では例えば、信用カ
−ド売出表買入申請項目(610b)を選択して、一連の信用
カ−ド売出表買入申請情報を生成することができるので
あるが、この場合、信用カ−ド売出表買入申請情報は一
連の品物、用役等を販売した販売業体(500)が"企業専用
信用カ−ドを用いて、該品物、用役等の購買代金を決済
した" 購買業体(400)と連繋された銀行(300)を対象に伝
送する販売代金先支給申請情報を意味し、本発明のシス
テム(100)はこのような"信用カ−ド売出表買入申請情
報"に基づいて、信用カ−ド売出表買入代金を購買業体
(400)に変わって、予め先支給することになり、結局、
自分の販売した品物、用役等の販売代金を前もって収金
できるようになる。
【0052】一方、上述した過程を通じて、購買業体側
コンピュ−タ−(1a)に一連の購買業体用初期ペ−ジ(60
1)が掲示された状態で、代金管理サ−バ−(10)は、該、
購買業体側コンピュ−タ−(1a)から一連の購買代金支払
明細表管理イベントが発生したかの与否を判断する(段
階S9)。
【0053】この際、購買業体側コンピュ−タ−(1a)か
ら別途の購買代金支払明細表管理イベントが発生しなか
ったことに判断されると、代金管理サ−バ−(10)は、フ
ロ−段階(S9a)に進行して、一連の待機状態を維持す
る。
【0054】しかし、購買業体(400)側では、例えば、
初期ペ−ジ(601)の売出債券明細表伝送項目(602b)、信
用カ−ド売出表伝送項目(602a)等をクリックして、購買
業体側コンピュ−タ−(1a)から一連の購買代金支払明細
表管理イベントが発生した場合、代金管理サ−バ−(10)
は購買業体側コンピュ−タ−(1a)から伝送される購買代
金支払明細表情報を参照して、一連の購買代金支払明細
表管理過程を速やかに行うことになる(段階S100)。
【0055】これと類似に、代金管理サ−バ−(10)は販
売業体側コンピュ−タ−(2a) 一連の販売業体用初期ペ
−ジ(601, 610)が掲示された状態で、該販売業体側コン
ピュ−タ−(2a)から一連の販売代金先支給イベントが発
生したかの与否を判断する(段階S10)。
【0056】この際、販売業体側コンピュ−タ−(2a)か
ら、別途の販売代金支払明細表管理イベントが発生しな
かったことに判断されると、代金管理サ−バ−(10)は、
フロ−を段階(S9a)に進行して、一連の待機状態を維持
する。
【0057】しかし、販売業体(500)側で、例えば、販
売業体用初期ペ−ジ(607)の貸出申請項目(610a)、信用
カ−ド売出表買入申請項目(610)等をクリックして、販
売業体側コンピュ−タ−(2a)から一連の販売代金先支給
申請イベントが発生した場合、代金管理サ−バ−は販売
業体側コンピュ−タ−(2a)から伝送される販売代金先支
給情報を参照して、一連の販売代金先支給過程を速やか
に進行させるようになる(段階S200)。
【0058】まず、上述した購買代金支払明細表管理過
程(段階S100)を詳細に説明する。
【0059】図6に示したように、代金管理サ−バ−(1
0)は購買業体側コンピュ−タ−(1a)から一連の売出債券
明細表伝送イベントが発生したかの与否を判断する(段
階S101)。
【0060】この際、購買業体(400)側から、初期ペ−
ジ(601)の信用カ−ド売出表伝送項目(602a)等をクリッ
クして、購買業体側コンピュ−タ−(1a)から売出債券明
細表伝送イベントの変わりに、一連の信用カ−ド売出表
伝送イベントが発生したことに判断されると、代金管理
サ−バ−は運営情報管理モジュ−ル(60)を活用して、一
連の信用カ−ド売出表内訳入力メッセ−ジを生成し、生
成の完了した信用カ−ド売出表内訳入力メッセ−ジをイ
ンタ−フェ−スモジュ−ル(20)を媒介にして、購買業体
側コンピュ−タ−(1a)に伝送する(段階S102)。
【0061】この場合、購買業体側コンピュ−タ−(1a)
は代金管理サ−バ−(10)から伝送される信用カ−ド売出
内訳入力メッセ−ジ(611)を速やかに解釈し、これらを
図7に示したように、ディスプレ−させることにより、
購買業体(400)が一連の信用カ−ド売出表情報を生成す
ることのできる安定的な基盤環境を提供されるようにす
る。
【0062】この状態で、代金管理サ−バ−(10)はイン
タ−フェ−スモジュ−ル(20)を持続的にチェックするこ
とにより、購買業体側コンピュ−タ−(1a)から一連の信
用カ−ド売出表情報が伝送されたかの与否を判断する(S
103)。
【0063】この際、購買業体(400)側で、まだ、信用
カ−ド売出表内訳入力過程を完了しなったため、購買業
体側コンピュタ−(1a)から一連の信用カ−ド売出表情報
が伝送されてないことに判断されると代金管理サ−バ−
(10)はフロ−を段階S104に進行して、一連の待機状態を
維持する。
【0064】しかし、購買業体(400)側で、信用カ−ド
売出表内訳入力過程をすべて完了し、例えば、伝送項目
(612)をクリックして、購買業体側コンピュタ−(1a)か
ら一連の信用カ−ド売出表情報が伝送されたことに判断
されると代金管理サ−バ−(10)はこの信用カ−ド売出表
情報の妥当性与否、例えば、信用カ−ド売出表情報に記
録された信用カ−ド支給対象金額が既指定された信用カ
−ド限度金額以内であるか、なお信用カ−ド売出表情報
に記録された支給対象販売業体が登録された販売業体で
あるか等の与否を判断する(段階S105)。
【0065】この際、信用カ−ド売出表情報に記録され
た信用カ−ド支給対象金額が既指定された信用カ−ド限
度金額を超えるとか、なお、信用カ−ド売出表情報に記
録された支給対象販売業体が登録された販売業体でない
ことに判断される場合、代金管理サ−バ−(10)は一連の
誤謬メッセ−ジを購買業体側コンピュタ−(1a)に伝送す
る過程を進行する(段階 S106)。
【0066】この場合、代金管理サ−バ−(10)は運営情
報管理モジュ−ル(60)を活用して、運営情報D/B(85)に
貯蔵されていた一連の運営情報を取り出してから、この
運営情報を活用して、例えば、"選択した金額が信用カ
−ド金額を超過します。もう一度試して下さい‥"等の
ような一連の誤謬メッセ−ジを生成し、生成の完了した
誤謬メッセ−ジを購買業体側コンピュタ−(1a)に伝送す
る。
【0067】しかし、信用カ−ド売出表情報に記録され
た信用カ−ド支給対象金額が既指定された信用カ−ド限
度金額以内で、なお、信用カ−ド売出表情報に記録され
た支給対象販売業体が登録された販売業体に判断され、
該信用カ−ド売出表情報の妥当性が認められる場合、代
金管理サ−バ−(10)は該信用カ−ド売出表情報を収集、
貯蔵する過程を進行する(段階S107)。
【0068】この場合、代金管理サ−バ−(10)は購買業
体側コンピュタ−(1a)から伝送された信用カ−ド売出表
情報を購買代金支払明細表管理モジュ−ル(40)に伝達す
ることになり、購買代金支払明細表管理モジュ−ル(40)
はこのような信用カ−ド売出表情報が伝達される即時、
これらをD/B管理サ−バ−(70)に伝達することにより、
該信用カ−ド売出表情報が例えば、購買代金支払明細表
情報D/B(82)に安定的に収集、貯蔵できるようにする。
【0069】一方、前述した段階S101で、購買業体(40
0)が初期ペ−ジ(601)の売出債券明細表伝送項目(602b)
をクリックして、購買業体側コンピュタ−(1a)から一連
の売出債券明細表伝送イベントが発生したことに判断さ
れると、代金管理サ−バ−(10)は運営情報管理モジュ−
ル(60)を活用して、一連の売出債券内訳入力メッセ−ジ
を生成し、生成の完了した売出債券内訳入力メッセ−ジ
をインタ−フェ−スモジュ−ル(20)を媒介にして購買業
体側コンピュタ−(1a)に伝送する(段階S108)。
【0070】この場合、購買業体側コンピュタ−(1a)は
代金管理サ−バ−(10)から伝送される売出債券内訳入力
メッセ−ジ(613)を速やかに 解釈し、これらを図 8に
示したように、ディスプレ−させることにより、購買業
体(400)が一連の売出債券明細表情報を生成することの
できる安定的な基盤環境を提供されるようにする。
【0071】この状態で、代金管理サ−バ−(10)はイン
タ−フェ−スモジュ−ル(20)を 持続的にチェックする
ことにより、購買業体側コンピュ−タ−(1a)から一連の
売出債券明細表情報が伝送されたかの与否を判断する
(段階S109)。
【0072】この際、購買業体(400)側では、まだ、売
出債券明細表内訳入力過程を完了しなかったため、購買
業体側コンピュ−タ−(1a)から一連の売出債券明細表情
報が伝送されてないことに判断されると、代金管理サ−
バ−(10)はフロ−を 段階S110に進行して、一連の待機
状態を維持する。
【0073】しかし、購買業体(400)側で、売出債券明
細表内訳入力過程をすべて完了して、例えば、伝送項目
(614)をクリックして、購買業体側コンピュ−タ−(1a)
から一連の売出債券明細表情報が伝送されたことに判断
されると、代金管理サ−バ−(10)はこの売出債券明細表
情報の妥当性与否、例えば、売出債券明細表情報に記録
された売出債券支給対象金額が既指定された売出債券限
度金額以内であるか、なお、売出債券明細表情報に記録
された支給対象販売業体が登録された販売業体であるか
の与否を判断する(段階S111)。
【0074】この際、売出債券明細表情報に記録された
売出債券支給対象金額が既指定された売出債券限度金額
を超えるとか、売出債券明細表情報に記録された支給対
象販売業体が登録された販売業体でないことに判断され
る場合、代金管理サ−バ−(10)は一連の誤謬メッセ−ジ
を購買業体側コンピュタ−(1a)に伝送する過程を進行す
る(S112)。
【0075】この場合、代金管理サ−バ−(10)は運営情
報管理モジュ−ル(60)を活用して運営情報D/B(85)に貯
蔵されていた一連の運営情報を取り出してから、この運
営情報を活用して、例えば、"選択した金額が売出債券
限度金額を超過します。もう一度試して下さい‥"等の
ような一連の誤謬メッセ−ジを生成し、生成の完了した
誤謬メッセ−ジを購買業体側コンピュタ−(1a)に伝送す
る。
【0076】しかし、売出債券明細表情報に記録された
売出債券支給対象金額が既指定された売出債券限度金額
以内の金額で、売出債券明細表情報に記録された支給対
象販売業体が既登録された販売業体に判断されて、該売
出債券明細表の妥 性が認められる場合、代金管理サ−
バ−(10)は該売出債券明細表情報を収集、貯蔵する過程
を進行する(段階 S113)。
【0077】この場合、代金管理サ−バ−(10)は購買業
体側コンピュタ−(1a)から伝送された売出債券明細表情
報を購買代金支払明細表管理モジュ−ル(40)に伝達する
ことになり、購買代金支払明細表管理モジュ−ル(40)は
このような 売出債券明細表情報が伝達される即時、こ
れらをD/B管理サ−バ−(70)に伝達することにより、該
売出債券明細表情報が例えば、購買代金支払明細表情報
D/B(82)に安定的に収集、貯蔵されることができるよう
にする。
【0078】次に、上述した販売代金先支給過程(段階
S200)を詳細に説明する。
【0079】図9に示したように、まず、代金管理サ−
バ−(10)はインタ−フェ−スモジュ−ル(20)を持続的に
チェックすることにより、販売業体側コンピュ−タ−(2
a)から売出債券明細書による一連の貸出申請イベントが
発生したかの与否を判断する(段階S201)。
【0080】この際、 販売業体(500)側で、例えば、初
期ペ−ジ(607)の信用カ−ド売出表買入申請項目(610)を
クリックして、販売業体側コンピュ−タ−(2a)から 売
出債券明細表による貸出申請イベント変わりに、一連の
信用カ−ド売出表買入申請イベントが発生したことに判
断されると、代金管理サ−バ−(10)は運営情報管理モジ
ュ−ル(60)を活用して 一連の信用カ−ド売出表買入申
請内訳入力メッセ−ジを生成し、生成の完了した信用カ
−ド売出表買入申請内訳入力メッセ−ジをインタ−フェ
−スモジュ−ル(20)を媒介にして販売業体側コンピュタ
−(2a)に伝送する(段階S202)。
【0081】この場合、販売業体側コンピュタ−(2a)は
代金管理サ−バ−(10)から伝送される信用カ−ド売出表
買入申請内訳入力メッセ−ジ(615)を速やかに解釈し、
これらを図10に示したように、ディスプレ−させること
により、販売業体(500)が一連の信用カ−ド売出表買入
申請過程を速やかに進行させることのできる安定的な基
盤環境を提供されるようにする。
【0082】この状態で、代金管理サ−バ−(10)はイン
タ−フェ−スモジュ−ル(20)を 持続的にチェックする
ことにより、販売業体側コンピュ−タ−(2a)から一連の
信用カ−ド売出表買入申請情報が伝送されたかの与否を
判断する(段階S203)。
【0083】この際、販売業体(500)側では、まだ、信
用カ−ド売出表買入申請内訳入力過程を完了しなかった
ため、販売業体側コンピュ−タ−(2a)から一連の信用カ
−ド売出表買入申請情報が伝送されてないことに判断さ
れると、代金管理サ−バ−(10)はフロ−を段階S204に進
行して、一連の待機状態を維持する。
【0084】しかし、販売業体(500)側で、信用カ−ド
売出表買入申請内訳入力過程をすべて完了して、例え
ば、伝送項目(616)をクリックして販売業体側コンピュ
−タ−(2a)から一連の信用カ−ド売出表買入申請情報が
伝送されたことに判断されると、代金管理サ−バ−(10)
は信用カ−ド売出表買入申請情報に記録された信用カ−
ド売出表買入申請た金額が既指定された債券残額限度以
内であるかの与否を判断する(段階S205)。
【0085】この際、信用カ−ド売出表買入申請情報に
記録された信用カ−ド売出表買入申請金額が既指定され
た債券残額を超える場合、代金管理サ−バ−(10)は一連
の誤謬メッセ−ジを販売業体側コンピュ−タ−(2a)に伝
送する過程を進行する(S206)。
【0086】この場合、代金管理サ−バ−(10)は運営情
報管理モジュ−ル(60)を活用して運営情報D/B(85)に貯
蔵されていた一連の運営情報を取り出してから、この運
営情報を活用して、例えば、"申請した金額が債券限度
金額を超えています。もう一度試して下さい‥"等のよ
うな一連の誤謬メッセ−ジを生成し、生成の完了した誤
謬メッセ−ジを販売業体側コンピュ−タ−(2a)に伝送す
る。
【0087】しかし、信用カ−ド売出表買入申請情報に
記録された信用カ−ド売出表買入申請金額が既指定され
た債券残額限度内の金額である場合、代金管理サ−バ−
(10)は一連の“信用カ−ド売出表買入代金”を購買業体
(400)に変わって、販売業体(500)側に予め先支給する過
程を進行する(段階 S207)。
【0088】この場合、代金管理サ−バ−(10)は口座管
理モジュ−ル(90)に“信用カ−ド売出表買入代金”の先
支給を指示することになり、口座管理モジュ−ル(90)
はこのような指示イベントが発生するや否や、一定額の
現金を例えば、システム側指定口座(92)から販売業体側
指定口座(93) に入金させるようになり、結局 購買業体
(400)を対象に一連の品物、用役等を販売した販売業体
(500)は“自社で販売した品物、用役”等に相応する一
連“信用カ−ド売出表買入代金”をオンライン上で容易
に先入金されることができるようになる。
【0089】一方、前述した段階S201で、販売業体(50
0)が初期ペ−ジ(607)の貸出申請項目(610a)をクリック
して、販売業体側コンピュ−タ−(2a)から売出債券明細
表による一連の貸出申請イベントが発生したことに判断
されると、代金管理サ−バ−(10)は運営情報管理モジュ
−ル(60)を活用して、一連の貸出申請内訳入力メッセ−
ジを生成し、生成の完了した貸出申請内訳入力メッセ−
ジをインタ−フェ−スモジュ−ル(20)を媒介にして販売
業体側コンピュタ−(2a)に伝送する(段階S208)。
【0090】この場合、販売業体側コンピュタ−(2a)は
代金管理サ−バ−(10)から伝送される貸出申請内訳入力
メッセ−ジ(617)を速やかに解釈し、これらを図11に示
したように、ディスプレ−させることにより、販売業体
(500)が一連の貸出申請過程を速やかに進行させること
のできる安定的な基盤環境を提供されるようにする。
【0091】この状態で、代金管理サ−バ−(10)はイン
タ−フェ−スモジュ−ル(20)を 持続的にチェックする
ことにより、販売業体側コンピュ−タ−(2a)から一連の
貸出申請情報が伝送されたかの与否を判断する(段階S2
09)。
【0092】この際、販売業体(500)側では、まだ、貸
出申請内訳入力過程を完了しなかったため、販売業体側
コンピュ−タ−(2a)から一連の貸出申請情報が伝送され
てないことに判断されると、代金管理サ−バ−(10)はフ
ロ−を段階S210に進行して、一連の待機状態を維持す
る。
【0093】しかし、販売業体(500)側で、貸出申請内
訳入力過程をすべて完了して、例えば、伝送項目をクリ
ックして販売業体側コンピュ−タ−(2a)から一連の貸出
申請情報が伝送されたことに判断されると、代金管理サ
−バ−(10)は貸出申請情報に記録された貸出金額が既指
定された債券残額限度内であるかの与否を判断する(段
階S211)。
【0094】この際、貸出申請情報に記録された貸出申
請金額が既指定された債券残額を超える場合、代金管理
サ−バ−(10)は一連の誤謬メッセ−ジを販売業体側コン
ピュ−タ−(2a)に伝送する過程を進行する(S212)。
【0095】この場合、代金管理サ−バ−(10)は運営情
報管理モジュ−ル(60)を活用して運営情報D/B(85)に貯
蔵されていた一連の運営情報を取り出されてから、この
運営情報を活用して、例えば、"申請した金額が債券限
度金額を超えています。もう一度試して下さい‥"等の
ような一連の誤謬メッセ−ジを生成し、生成の完了した
誤謬メッセ−ジを販売業体側コンピュ−タ−(2a)に伝送
する。
【0096】しかし、貸出申請情報に記録された貸出申
請金額が既指定された債券残額限度内の金額である場
合、代金管理サ−バ−(10)は一連の“貸出金”を購買業
体(400)に変わって、販売業体(500)側に予め先支給する
過程を進行する(段階 S213)。
【0097】この場合、代金管理サ−バ−(10)は口座管
理モジュ−ル(90)に“貸出金”の先支給を指示すること
になり、口座管理モジュ−ル(90) はこのような指示イ
ベントが発生するや否や、一定額の現金を例えば、シス
テム側指定口座(92)から販売業体側指定口座(93)に入金
させるようになり、結局 購買業体(400)を対象に一連の
品物、用役等を販売した販売業体(500)は“自社で販売
した品物、用役”等に相応する一連の“貸出金”をオン
ライン上で容易に先入金されることができるようにな
る。
【0098】一方、上述した図3に示したように、前述
の販売代金先支給過程(段階S200)終了されると、代金
管理サ−バ−(10)は購買代金支払明細表管理モジュ−ル
(40)を活用して、購買代金支払明細表情報D/B(82)に貯
蔵された購買代金支払明細表情報をチェックして、該購
買代金支払明細表のうち、当日満期日の件があるかの与
否を判断する(段階11)。
【0099】この際、購買代金支払明細表のうち、当日
満期日の件がある場合、購買業体(400)側の指定口座(9
1)をチェックして、該購買業体の購買資金を決済する過
程を速やかに進行する(段階S300)。
【0100】まず、図12に示したように、代金管理サ−
バ−(10)は口座管理モジュ−ル(90)を制御して、当日満
期日の件に該当する購買代金支払明細表を発行した購買
業体(400)側の指定口座(91)を綿密にチェック(段階S30
1)。
【0101】次に、代金管理サ−バ−(10)は当日満期日
の件の前術の段階 S207, S213等の進行により発生され
た“先支給の件”を回収する“先支給回収対象の件”で
あるかの与否を判断する(段階S301a)。
【0102】この際、当日満期日の件に摘示された販売
業体(500)は前術の場合のような一連の“販売代金先支
給過程”を進行しなかった一般販売業体(500)であたっ
たため、当日満期日の件が前の場合のような“先支給回
収対象の件”でない“一般対象件処理過程”であること
に判断される場合、代金管理サ−バ−(10)は一連の“一
般対象の件”を迅速に進行する(S301b)。参考に、これ
ら一般対象件の処理過程は別途の図面なしにも、当業者
に容易に理解できるので、前の図12ではこれを詳細に示
さなかった。
【0103】まず、代金管理サ−バ−(10)は該一般対象
の件が売出債券明細表対象の件であるかの与否を判断す
る。
【0104】この際、該一般対象の件が売出債券明細表
対象の件でないことに判断される場合、代金管理サ−バ
−(10)は該一般対象の件が“信用カ−ド売出表対象の
件”であることに判定し、購買業体側の指定口座(91)に
既入金されていた金額が“信用カ−ド売出表買入代金
額”以上であるかの与否をもう一度判断する。
【0105】ここで、購買業体側の指定口座(91)に既入
金されていた金額が“信用カ−ド売出表買入代金額”未
満であることに判断される場合、代金管理サ−バ−(10)
は銀行(300)側と信用カ−ド借主関係にある該購買業体
(400)を延滞処理するとともに、販売業体(500)側が収金
すべき“信用カ−ド売出表買入代金額”を購買業体側の
変わりに販売業体(500)に支給してあげる。
【0106】しかし、購買業体側の指定口座(91)に既入
金されていた金額が“信用カ−ド売出表買入代金額”以
上であることに判断される場合、代金管理サ−バ−(10)
は購買業体側の指定口座(91)に既入金されていた適正残
余額を販売業体(500)側指定口座(93)に入金させる過程
を進行するようになり、結局、販売業体(500)は自社が
販売した品物、用役等の販売代金がすべて集金できるよ
うになる。
【0107】一方、前述の“ 該一般対象の件”が“売
出債券明細表対象の件”であるかの与否を判断する段階
で、該一般対象の件が“売出債券明細表対象の件”で判
断される場合、代金管理サ−バ−(10)は購買業体側の指
定口座(91)に既入金されていた金額が“売出債券明細金
額”であるかの与否をもう一度判断する。 この
際、購買業体側の指定口座(91)に既入金されていた金額
が“売出債券明細金額”未満であることに判断される
と、代金管理サ−バ−(10)はフロ−を終了する。
【0108】しかし、購買業体側の指定口座(91)に既入
金されていた金額が“売出債券明細金額”以上であるこ
とに判断される場合、代金管理サ−バ−(10)は購買業体
側の指定口座(91)に既入金されていた適正残余額を該販
売業体(500)側指定口座(93)に入金させる過程を進行す
るようになり、結局、販売業体(500)は自社が販売した
品物、用役等の販売代金がすべて集金できるようにな
る。
【0109】一方、前の段階S301aで、当日満期日の件
が前術の場合のような先支給回収対象の件であることに
判断される場合、代金管理サ−バ−(10)は該“先支給回
収対象の件”が前の段階S213により進行された“貸出金
先支給代金”を 購買業体(400)から回収する件であるか
の与否を判断する(段階S302)。
【0110】この際、“当日満期日の件”が“貸出金先
支給代金回収対象の件”でないことに判断される場合、
代金管理サ−バ−は該“先支給回収対象の件”が前の段
階S207により進行された“信用カ−ド売出表買入代金先
支給代金”を購買業体(400)から回収する件であること
に判断して、先支給金回収管理モジュ−ル(50)を通じて
信用カ−ド売出表買入代金先支給情報を取り出して、こ
の信用カ−ド売出表買入代金先支給情報を活用して、購
買業体側の指定口座(91)に既入金されていた金額が“信
用カ−ド売出表買入代金先支給金額”以上であるかの与
否を判断する(段階303)その際、図13aに示したよう
に、信用カ−ド売出表買入代金先支給金額が200なの
に、購買業体側の指定口座(91)に既入金されていた金額
が 100であるため、購買業体側の指定口座(91)に既入金
されていた金額が“信用カ−ド売出表買入代金先支給金
額”未満であることに判断される場合、代金管理サ−バ
−(10)は購買業体側の指定口座(91)に既入金されている
100を回収するとともに、銀行(300)側と借主関係にある
該購買業体(400)をその差額、即ち、100だけを延滞処理
する過程を進行する(段階S304)。
【0111】この場合、代金管理サ−バ−(10)は運営情
報管理モジュ−ル(60)に“該購買業体(400)を延滞処理
して下さい”とのメッセ−ジを伝達するようになり、運
営モジュ−ル(30)はこれらのメッセ−ジを伝達するや否
や、登録情報D/B(86)に貯蔵されている該購買業体(400)
の登録情報を変更させることにより、以後、 該購買業
体(400)が延滞業体で分類、管理されることが出来るよ
うにする。
【0112】しかし、図13bに示したように、信用カ−
ド売出表買入代金先支給金額が 50であるが、購買業体
側の指定口座(91)に既入金されていた金額が 120である
ため、購買業体側の指定口座(91)に既入金されていた金
額が“信用カ−ド売出表買入代金先支給金額”以上であ
ることに判断される場合、代金管理サ−バ−(10)は銀行
(300)側の先支給した“信用カ−ド売出表買入代金先支
給金額”を正常的に回収する過程を進行する(段階S30
5)。
【0113】この場合、代金管理サ−バ−(10)は口座管
理モジュ−ル(90)に購買業体側の指定口座(91)に既入金
されている金額の回収を指示するようになり、口座管理
モジュ−ル(90)はこのような指示イベントが発生するや
否や、購買業体(400)側の保有資金、例えば、120のうち
50を 購買業体側の指定口座(91)からシステム側指定口
座(92)に入金させるようになり、結局、銀行(300)側は
上述した“信用カ−ド売出表買入代金先支給金額”を通
じて先支給した代金を容易に回収できるようになる。
【0114】上述した過程を通じて、“信用カ−ド売出
表買入代金先支給金額”の回収過程が終了されると代金
管理サ−バ−(10)は購買業体(400)側の保有資金のう
ち、前の“信用カ−ド売出表買入代金先支給金額”を差
し引きした残りの適正残余額を販売業体側指定口座(93)
に入金させる過程を進行する(段階S309)。
【0115】この場合、 代金管理サ−バ−(10)は口座
管理モジュ−ル(90)に購買業体側の指定口座(91)に既入
金されている残りの適正金額の移替を指示するようにな
り、口座管理モジュ−ル(90)はこのような指示イベント
が発生するや否や、購買業体(400)側の残りの保有資
金、例えば、70のうち“ 販売業体(500)の残余債券金
額”である50だけを購買業体側の指定口座(91)から販売
業体側指定口座(93)に入金させるようになり、結局、販
売業体(500)は自社が販売した品物、用役等の販売代金
がすべて集金できるようになる。
【0116】一方、前の段階S302で、“先支給回収対象
の件”が“売出債券明細表による貸出金先支給代金回収
対象の件”であることに判断される場合、代金管理サ−
バ−(10)は先支給金回収管理モジュ−ル(50)を通じて、
貸出金先支給情報を取り出してから、これら貸出金先支
給情報を活用して、購買業体側の指定口座(91)に既入金
されている金額が貸出金先支給金額以上であるかの与否
を判断する(段階S306)。
【0117】この際、図13c に示したように、貸出金先
支給金額が200なのに、購買業体側の指定口座(91)に既
入金されていた金額が 100であるため、購買業体側の指
定口座(91)に既入金されていた金額が“貸出金先支給金
額”未満であることに判断される場合、代金管理サ−バ
−(10)は購買業体側の指定口座(91)に既入金されている
100を回収するとともに、銀行(300)側と借主関係にある
該販売業体(500)をその差額、即ち、100だけを延滞処理
する過程を進行する(段階S307)。
【0118】この場合、代金管理サ−バ−(10)は運営情
報管理モジュ−ル(60)に“該販売業体(500)を延滞して
下さい”とのメッセ−ジを伝達するようになり、運営情
報管理モジュ−ル(60)はこのようなメッセ−ジが伝達さ
れるや否や、登録情報D/B(86)に貯蔵されている該販売
業体(500)の登録情報を変更させることにより、以後、
該販売業体(500)が延滞業体で分類、管理されることが
出来るようにする。
【0119】しかし、図13dに示したように、貸出金先
支給金額が 50であるが、購買業体側の指定口座(91)に
既入金されている金額が 120であるため、購買業体側の
指定口座(91)に既入金されていた金額が“貸出金先支給
金額”以上であることに判断される場合、代金管理サ−
バ−(10)は銀行(300)側の先支給した“貸出金先支給金
額”を回収する過程を進行する(段階S308)。
【0120】この場合、代金管理サ−バ−(10)は口座管
理モジュ−ル(90)に購買業体側の指定口座(91)に既入金
されている金額の回収を指示するようになり、口座管理
モジュ−ル(90)はこのような指示イベントが発生するや
否や、購買業体(400)側の保有代金、例えば、120のうち
50を購買業体側の指定口座(91)からシステム側指定口座
(92)に入金させるようになり、結局、銀行(300)側は上
述した“貸出金先支給過程”を通じて先支給した代金を
容易に回収できるようになる。
【0121】上述した過程を通じて、“貸出金先支給金
額”の回収過程が終了されると代金管理サ−バ−(10)は
購買業体(400)側の保有代金のうち、前の“貸出金先支
給金額”を差し引きした残りの適正残余額を販売業体側
指定口座(93)に入金させる過程を進行する(段階S30
9)。
【0122】この場合、代金管理サ−バ−(10)は口座管
理モジュ−ル(90)に購買業体側の指定口座(91)に既入金
されている残りの金額の移替を指示するようになり、口
座管理モジュ−ル(90)はこのような指示イベントが発生
するや否や、購買業体(400)側の残りの保有代金、例え
ば、70のうち“ 販売業体(500)の残余債券金額”である
50だけを購買業体側指定口座(91)から販売業体側指定口
座(93)に入金させるようになり、結局、販売業体(500)
は自社が販売した品物、用役等の販売代金がすべて集金
できるようになる。
【0123】以後、代金管理サ−バ−(10)は購買業体側
の通信クライアント(1)または販売業体側通信クライア
ント(2)等から一連の購買代金支払明細表管理イベン
ト、販売代金先支給申請イベント等が発生される毎に、
上述した認証モジュ−ル(30)、購買代金支払明細表管理
モジュ−ル(40)、先支給金回収管理モジュ−ル(50)、運
営情報管理モジュ−ル(60)、口座管理モジュ−ル(90)等
を緊密に連繋させ、一連の購買代金支払明細表管理過
程、販売代金先支給管理過程等を体系的に進行させるこ
とにより、任意の購買業体、販売業体等が銀行オンライ
ン網を基盤にして、信頼性ある代金決済関係を容易に形
成できるようにする。
【0124】
【発明の効果】以上、詳細に説明したように、本発明で
は銀行オンライン網を基盤にして、販売業体が購買業体
を相手に取得した将来の売出債権を販売業体から譲渡さ
れて、これらを担保にして購買業体が支払うべき購買代
金をオンライン上で予め先支給してあげることにより、
該購買業体が販売業体を対象にする一連の代金決済関係
をさほど資金負担なしに、さらに容易に形成することが
できるように誘導することができる。。
【0125】また、本発明では購買業体による従来の手
形使用を予め排除し、これらを通じて、販売業体及び購
買業体間に形成される代金決済関係の信頼性を大幅向上
させることにより、予測できなかった販売業体の被害を
最小化させることができる。
【0126】また、本発明では販売業体及び購買業体の
間に行われている全体的な代金決済過程をオンライン上
で体系的に具現することにより、販売業体及び購買業体
がオンライン上で、自社に必要な販売代金収金過程、購
買代金支払過程をさらに容易に進行させることが出来る
ように誘導することができる。
【0127】なお、本発明では購買業体及び販売業体の
間に形成される代金決済関係の信頼性を向上させること
により、多くの業体の連鎖不渡りによる経済的被害を最
小化させることができる。
【0128】上で、本発明の特定の実施例が説明され、
かつ図示されたが本発明の当業者により多様に変形され
て実施される可能性があることは自明なことであろう。
【0129】このように変形された実施例は本発明の技
術的思想や観点から個別的に理解されてはだめであり、
このような変形された実施例は本発明に添付された特許
請求の範囲内に属すると言えよう。
【図面の簡単な説明】
【図1】図1は、本発明が採用された企業間代金決済関
係を概念的に図示した例示図である。
【図2】図2は、本発明による企業間代金決済管理シス
テムを概念的に示した例示図である。
【図3】図3は、本発明の一実施例による企業間代金決
済管理方法を順次的に示した順序図である。
【図4】図4は、本発明の一実施例による購買業体側通
信クライアント及び販売業体側通信クライアントの初期
ペ−ジ掲示状態を概念的に示した例示図である。
【図5】図5は、本発明の一実施例による購買業体側通
信クライアント及び販売業体側通信クライアントの初期
ペ−ジ掲示状態を概念的に示した例示図である。
【図6】図6は、本発明のもう一つの実施例による企業
間代金決済管理方法を順次的に示した順序図である。
【図7】図7は、本発明のもう一つの実施例による購買
業体側通信クライアントのメッセ−ジ掲示状態を概念的
に示した例示図である。
【図8】図8は、本発明のもう一つの実施例による購買
業体側通信クライアントのメッセ−ジ掲示状態を概念的
に示した例示図である。
【図9】図9は、本発明のもう一つの実施例による企業
間代金決済管理方法を順次的に示した順序図である。
【図10】図10は、本発明のもう一つの実施例による
販売業体側通信クライアントのメッセ−ジ掲示状態を概
念的に示した例示図である。
【図11】図11は、本発明のもう一つの実施例による
販売業体側通信クライアントのメッセ−ジ掲示状態を概
念的に示した例示図である。
【図12】図12は、本発明のもう一つの実施例による
企業間代金決済管理方法を順次的に示した順序図であ
る。
【図13】図13a乃至13dは、本発明のもう一つの
実施例による購買業体側指定座の金額入金状態を概念的
に示した例示図である。
【符号の説明】
10…代金管理サーバー 20…インターフェースモジュール 30…認証モジュール 40…購買代金支払明細表管理モジュール 50…先支給回収管理モジュール 60…運営情報管理モジュール 70…D/B管理サーバー 80…運営情報D/B 90…口座管理モジュール 100…企業間代金決済管理システム 400…購買業体 500…販売業体
───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.7 識別記号 FI テーマコート゛(参考) G06F 17/60 314 G06F 17/60 314 332 332

Claims (16)

    【特許請求の範囲】
  1. 【請求項1】一連の認証情報が貯蔵されたデ−タベ−ス
    (D/B:Data Base)、一連の購買代金支払明細表情報が
    貯蔵された購買代金支払明細表情報D/B 、一連の貸出金
    先支給情報が貯蔵された貸出金先支給情報D/B、一連の
    信用カ−ド売出表買入代金先支給情報が貯蔵されている
    信用カ−ド売出表買入代金先支給情報D/B 、一連の購買
    企業/販売企業登録情報が貯蔵された登録情報D/Bを備
    えたD/Bブロックと;上記の認証情報、購買代金支払明
    細表情報、貸出金先支給情報、信用カ−ド売出表買入代
    金先支給情報、購買企業/販売企業登録情報を上記D/B
    ブロックの必要領域に選択的に貯蔵するか、または上記
    D/Bブロックの必要領域から選択的に抽出する D/B管理
    サ−バ−と;上記の D/B管理サ−バ−と一連の通信関係
    を形成した状態で、上記の認証情報、購買代金支払明細
    表情報、貸出金先支給情報、信用カ−ド売出表買入代金
    先支給情報、購買企業/販売企業登録情報の貯蔵及び抽
    出与否を決定し、任意の購買業体側通信クライアント及
    び販売業体側通信クライアントと銀行オンライン網を通
    じてインタ−フェ−スし、上記の購買業体側通信クライ
    アント及び販売業体側通信クライアントにより一連の購
    買代金支払明細表管理イベント及び販売代金先支給申請
    イベントが発生する場合、上記の認証情報、購買代金支
    払明細表情報、貸出金先支給情報、信用カ−ド売出表買
    入代金先支給情報、購買企業/販売企業登録情報を体系
    的に組み合って、上記の購買業体側が支払うべき購買代
    金を上記の販売業体側にオンラインで先支給するととも
    に、所定期日が経ってから、該先支給金に相当する金額
    を上記の購買業体からオンラインで回収する代金管理サ
    −バ−を含めることを特徴とする企業間代金決済管理シ
    ステム。
  2. 【請求項2】 請求項1において、上記の銀行オンライ
    ン網は、インタ−ネット網、自動応答通信網(Automatic
    Response System Communication Network),付加価値通
    信網(VAN: Value Added Network), 公衆電話網(PSTN: P
    ublic Switched Telephone Network)のうち、いずれの
    一つであることを特徴とする企業間の代金決済管理シス
    テム。
  3. 【請求項3】 請求項1において、上記の代金管理サ−
    バ−は上記の購買業体側通信クライアントから伝送され
    る購買代金支払明細表を専担管理する購買代金支払明細
    表管理モジュ−ルと一連の通信関係をさらに形成するこ
    とを特徴とする企業間代金決済管理システム。
  4. 【請求項4】 請求項1において、上記の代金管理サ−
    バ−は上記の購買業体側から回収すべき先支給金を専担
    管理する先支給金回収管理モジュ−ルと一連の通信関係
    をさらに形成することを特徴とする企業間代金決済管理
    システム。
  5. 【請求項5】 請求項1において、上記の代金管理サ−
    バ−は上記の購買業体側に指定された購買業体側指定口
    座及び上記の販売業体側に指定された販売業体側指定口
    座を専担管理する口座管理モジュ−ルと一連の通信関係
    をさらに形成することを特徴とする企業間の代金決済管
    理システム。
  6. 【請求項6】 任意の購買業体側通信クライアントまた
    は販売業体側通信クライアントのうち、いずれの一つか
    ら一連のシステム接続イベントが発生したかの与否を判
    断する段階と;上記の購買業体側通信クライアントまた
    は販売業体側通信クライアントのうち、いずれの一つか
    ら一連のシステム接続イベントが発生した場合、該クラ
    イアントを通じて接続中である業体の登録与否を判断す
    る段階と;該業体が登録業体であることに判断される場
    合、該登録業体が購買業体であるかの与否を判断する段
    階と;該登録業体が購買業体に判断される場合、一連の
    購買業体用初期ペ−ジを生成し、生成の完了した上記の
    購買業体用初期ペ−ジを上記の購買業体側通信クライア
    ントに伝送する段階と;上記の購買業体側通信クライア
    ントから一連の購買代金支払明細表管理イベントが発生
    したかの与否を判断する段階と;上記の購買業体側通信
    クライアントから一連の購買代金支払明細表管理イベン
    トが発生した場合、上記の購買業体側通信クライアント
    から伝送される購買代金支払明細表情報を参照して、一
    連の購買代金支払明細表管理過程を進行する段階を含め
    ることを特徴とする企業間の代金決済管理システム。
  7. 【請求項7】 請求項6において、上記の購買代金支払
    明細表管理過程を進行する段階は上記の購買業体側通信
    クライアントから一連の売出債券明細表伝送イベントが
    発生したかの与否を判断する段階と;上記の購買業体側
    通信クライアントから一連の売出債券明細表伝送イベン
    トが発生した場合、該売出債券内訳を入力することがで
    きる一連の売出債券内訳入力メッセ−ジを上記の購買業
    体側通信クライアントに伝送する段階と;上記の購買業
    体側通信クライアントから上記の売出債券内訳入力メッ
    セ−ジに対応される一連の売出債券明細表情報が伝送さ
    れたかの与否を判断する段階と;上記の購買業体側通信
    クライアントから上記の売出債券内訳入力メッセ−ジに
    対応される一連の売出債券明細表情報が伝送された場
    合、該売出債券明細表情報の妥当性与否を判断する段階
    と;上記の売出債券明細表情報の妥当性が認められる場
    合、上記の購買業体側通信クライアントから伝送された
    売出債券明細表情報を収集・貯蔵する段階を含めること
    を特徴とする企業間の代金決済管理方法。
  8. 【請求項8】 請求項7において、上記の売出債券明細
    表伝送イベントが発生しなかった場合、上記の購買業体
    側の信用カ−ド売出表内訳を入力できる一連の信用カ−
    ド売出表内訳入力メッセ−ジを上記の購買業体側通信ク
    ライアントに伝送する段階と;上記の購買業体側通信ク
    ライアントから上記の信用カ−ド売出表内訳入力メッセ
    −ジに対応される一連の信用カ−ド売出表情報が伝送さ
    れたかの与否を判断する段階と;上記の購買業体側通信
    クライアントから上記の信用カ−ド売出表内訳入力メッ
    セ−ジに対応される一連の信用カ−ド売出表情報が伝送
    された場合、該 信用カ−ド売出表情報の妥当性与否を
    判断する段階と;上記の信用カ−ド売出表情報の妥当性
    が認められる場合、上記の購買業体側通信クライアント
    から伝送された信用カ−ド売出表情報を収集・貯蔵する
    段階がさらに進行されることを特徴とする企業間の代金
    決済管理システム。
  9. 【請求項9】 請求項6において、該業体が販売業体に
    判断される場合、一連の販売業体用初期ペ−ジを生成
    し、生成の完了した上記の販売業体用初期ペ−ジを上記
    の販売業体側通信クライアントに伝送する段階と;上記
    の販売業体側通信クライアントから一連の販売代金先支
    給申請イベントが発生したかの与否を判断する段階と;
    上記の販売業体側通信クライアントから一連の販売代金
    先支給申請イベントが発生した場合、上記の販売業体側
    通信クライアントから伝送される販売代金先支給申請情
    報を参照して、一連の販売代金先支給過程をさらに進行
    する段階がさらに進行されることを特徴とする企業間の
    代金決済管理方法。
  10. 【請求項10】 請求項9において、上記の販売代金先
    支給過程を進行する段階は上記の 販売業体側通信クラ
    イアントから売出債券明細表による一連の貸出申請イベ
    ントが発生したかの与否を判断する段階と;上記の販売
    業体側通信クライアントから売出債券明細表による一連
    の貸出申請イベントが発生した場合、該貸出申請内訳を
    入力できる一連の貸出申請内訳入力メッセ−ジを上記の
    販売業体側通信クライアントに伝送する段階と;上記の
    販売業体側通信クライアントから上記の貸出申請内訳入
    力メッセ−ジに対応される貸出申請情報が伝送されたか
    の与否を判断する段階と;上記の販売業体側通信クライ
    アントから、上記の貸出申請内訳入力メッセ−ジに対応
    される貸出申請情報が伝送された場合、上記の貸出申請
    情報に記録された貸出申請金額が既指定された債券残額
    以内であるかの与否を判断する段階と;上記の貸出申請
    情報に記録された貸出申請金額が既指定された債券残額
    以内である場合、該貸出申請金額を先支給する段階を含
    めることを特徴とする企業間の代金決済管理方法。
  11. 【請求項11】 請求項10において、上記の貸出申請
    イベントが発生しなかった場合、販売業体側の信用カ−
    ド売出表買入申請内訳を入力できる一連の信用カ−ド売
    出表買入申請内訳入力メッセ−ジを上記の販売業体側通
    信クライアントに伝送する段階と;上記の販売業体側通
    信クライアントから上記の信用カ−ド売出表買入申請内
    訳入力メッセ−ジに対応される信用カ−ド売出表買入申
    請情報が伝送されたかの与否を判断する段階と;上記の
    販売業体側通信クライアントから、上記の信用カ−ド売
    出表買入申請内訳入力メッセ−ジに対応される信用カ−
    ド売出表買入申請情報が伝送された場合、上記の信用カ
    −ド売出表買入申請情報に記録された信用カ−ド売出表
    買入申請金額が既指定された債券残額以内であるかの与
    否を判断する段階と;上記の信用カ−ド売出表買入申請
    情報に記録された信用カ−ド売出表買入申請金額が既指
    定された債券残額以内である場合、該信用カ−ド売出表
    買入申請金額を先支給する段階がさらに進行されること
    を特徴とする企業間の代金決済管理方法。
  12. 【請求項12】 請求項6において、上記の購買代金支
    払明細表管理過程を進行する段階後に、上記の購買代金
    支払明細表のうち、当日満期日の件があるかの与否を判
    断する段階と;上記の購買代金支払明細表のうち、当日
    満期日の件がある場合、上記の当日満期日の件の購買代
    金支払明細表を発給した該購買業体側の指定口座をチェ
    ックして、一連の購買資金決済過程を管理する段階がさ
    らに進行されることを特徴とする企業間代金決済管理方
    法。
  13. 【請求項13】 請求項12において、上記の購買資金
    決済過程を管理する段階は上記の当日満期日の件が先支
    給回収対象の件であるかの与否を判断する段階と;上記
    の当日満期日の件が先支給回収対象の件である場合、該
    先支給回収対象の件が売出債券明細表による貸出金先支
    給代金回収対象の件であるかの与否を判断する段階と;
    上記の先支給回収対象の件が上記の貸出金先支給代金回
    収対象の件である場合、上記の購買業体側の指定口座に
    既入金されている金額が貸出金先支給金額以上であるか
    の与否を判断する段階と;上記の購買業体側の指定口座
    に既入金されている金額が貸出金先支給金額以上である
    で場合、上記の購買業体側の指定口座に既入金されてい
    る金額 から貸出金先支給金額を回収し、上記の貸出金
    先支給金額を差し引いた残りの適正残余額を販売業体側
    の指定口座に入金する段階を含めることを特徴とする企
    業間代金決済管理方法。
  14. 【請求項14】 請求項13において、上記の購買業体
    側の指定口座に既入金されている金額が上記の貸出金先
    支給金額未満であるで場合、上記の販売業体を延滞処理
    する段階がさらに進行されることを特徴とする企業間代
    金決済管理方法。
  15. 【請求項15】 請求項13において、上記の先支給回
    収対象の件が売出債券明細表による貸出金先支給代金回
    収対象の件でない場合、上記の購買業体側の指定口座に
    既入金されている金額が信用カ−ド売出表買入代金先支
    給金額以上であるかの与否を判断する段階と;上記の購
    買業体側の指定口座に既入金されている金額が信用カ−
    ド売出表買入代金先支給金額以上であるで場合、上記の
    購買業体側の指定口座に既入金されている金額から信用
    カ−ド売出表買入代金先支給金額を回収し、上記の信用
    カ−ド売出表買入代金先支給金額を差し引いた残りの適
    正残余額を販売業体側の指定口座に入金する段階がさら
    に進行されることを特徴とする企業間代金決済管理方
    法。
  16. 【請求項16】 請求項15において、上記の購買業体
    側の指定口座に既入金されている金額が上記の信用カ−
    ド売出表買入代金先支給金額未満であるで場合、上記の
    購買業体を延滞処理する段階がさらに進行されることを
    特徴とする企業間代金決済管理方法。
JP2001038848A 2000-02-15 2001-02-15 企業間代金決済管理システム及びこれらを用いた企業間代金決済管理方法 Pending JP2001283115A (ja)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
KR20000007057 2000-02-15
KR2001-6687 2001-02-12
KR1020010006687A KR100542386B1 (ko) 2000-02-15 2001-02-12 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
KR2000-7057 2001-02-12

Publications (1)

Publication Number Publication Date
JP2001283115A true JP2001283115A (ja) 2001-10-12

Family

ID=26637104

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2001038848A Pending JP2001283115A (ja) 2000-02-15 2001-02-15 企業間代金決済管理システム及びこれらを用いた企業間代金決済管理方法

Country Status (7)

Country Link
US (1) US20030014362A1 (ja)
EP (1) EP1257932A1 (ja)
JP (1) JP2001283115A (ja)
KR (1) KR100542386B1 (ja)
CN (1) CN1423783A (ja)
AU (1) AU3613401A (ja)
WO (1) WO2001061532A1 (ja)

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5405704B2 (ja) * 1999-06-18 2014-02-05 イーチャージ コーポレーション 仮想支払アカウントを用いてインターネットワークを介して商品、サービス及びコンテンツを注文する方法及び装置
KR20010099419A (ko) * 2001-09-26 2001-11-09 김형태 기업간 대금결제 시스템
KR20020030047A (ko) * 2002-02-27 2002-04-22 김기태 기업간 대금결제 선 지급 관리 방법
KR20030077250A (ko) * 2002-03-25 2003-10-01 오스크엔터테인먼트(주) 인터넷 전자상거래업체에대한 OPA(OnlinePayment-in-Advance)시스템을 이용한 선지급 결제시스템및 그 방법
US20040039609A1 (en) * 2002-08-22 2004-02-26 Sarah Burkitt System and method for payment of insurance premiums for vessels
KR20040026194A (ko) * 2002-09-23 2004-03-30 주식회사 신한은행 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법
CA2852974C (en) * 2003-09-11 2017-06-27 Theranos, Inc. Medical device for analyte monitoring and drug delivery
KR100684967B1 (ko) * 2004-08-04 2007-02-20 전달용 판매 대금 결제 서비스 제공 방법 및 시스템
US7635594B2 (en) 2005-05-09 2009-12-22 Theranos, Inc. Point-of-care fluidic systems and uses thereof
WO2007102632A1 (en) * 2006-03-07 2007-09-13 I-Bliss Co., Ltd System and method for electronic financial payment using esp
US11287421B2 (en) 2006-03-24 2022-03-29 Labrador Diagnostics Llc Systems and methods of sample processing and fluid control in a fluidic system
US8741230B2 (en) * 2006-03-24 2014-06-03 Theranos, Inc. Systems and methods of sample processing and fluid control in a fluidic system
US8007999B2 (en) 2006-05-10 2011-08-30 Theranos, Inc. Real-time detection of influenza virus
US20080113391A1 (en) 2006-11-14 2008-05-15 Ian Gibbons Detection and quantification of analytes in bodily fluids
US8158430B1 (en) 2007-08-06 2012-04-17 Theranos, Inc. Systems and methods of fluidic sample processing
AU2009220033B1 (en) 2009-04-16 2010-07-01 Westpac Banking Corporation Dynamic Prepayment Risk Management
US8862448B2 (en) 2009-10-19 2014-10-14 Theranos, Inc. Integrated health data capture and analysis system
KR101173651B1 (ko) 2011-10-11 2012-08-13 김경록 주식전환권리가 부여되는 예금/적금 및 이를 통합관리하기위한 뱅킹시스템 및 그 제어방법
US9792451B2 (en) 2011-12-09 2017-10-17 Echarge2 Corporation System and methods for using cipher objects to protect data
KR101491469B1 (ko) * 2012-06-13 2015-02-10 엠앤서비스 주식회사 오픈 마켓에서의 매출채권 기반의 대출 서비스 시스템 및 방법
KR101790985B1 (ko) 2015-03-18 2017-10-27 윤영배 위험회피 보증을 담보로 한 신용카드 매출채권의 매입 및 대금의 선지급을 이용한 금융 서비스 거래 방법
US11386409B2 (en) 2016-03-04 2022-07-12 Sertintyone Corporation Systems and methods for media codecs and containers

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1196262A (ja) * 1997-09-25 1999-04-09 The Asahi Bank Ltd 売掛債権の流動化処理システム

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4994964A (en) * 1987-04-16 1991-02-19 L & C Family Partnership Transaction tracking data processing system
US5504677A (en) * 1992-10-15 1996-04-02 Pollin; Robert E. Automated payment system
US5465206B1 (en) * 1993-11-01 1998-04-21 Visa Int Service Ass Electronic bill pay system
US5799087A (en) * 1994-04-28 1998-08-25 Citibank, N.A. Electronic-monetary system
US5732400A (en) * 1995-01-04 1998-03-24 Citibank N.A. System and method for a risk-based purchase of goods
US5677955A (en) * 1995-04-07 1997-10-14 Financial Services Technology Consortium Electronic funds transfer instruments
US5671280A (en) * 1995-08-30 1997-09-23 Citibank, N.A. System and method for commercial payments using trusted agents
US5983208A (en) * 1996-06-17 1999-11-09 Verifone, Inc. System, method and article of manufacture for handling transaction results in a gateway payment architecture utilizing a multichannel, extensible, flexible architecture
JP4300257B2 (ja) * 1997-01-27 2009-07-22 裕典 若山 電子決済システム
US6085168A (en) * 1997-02-06 2000-07-04 Fujitsu Limited Electronic commerce settlement system
US6006207A (en) * 1998-04-17 1999-12-21 Mumick; Ravneet Kaur System and method for loan prepayment discounts
KR100328577B1 (ko) * 1999-04-16 2002-03-14 김용훈 물품대금 결제방법
KR19990084123A (ko) * 1999-09-15 1999-12-06 손성배 인터넷 전자상점을 통하여 회원업체의 영업, 구매업무를대행하고 부수하여 금융, 물류, 정보를 제공하는통합물류회사 운영.

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1196262A (ja) * 1997-09-25 1999-04-09 The Asahi Bank Ltd 売掛債権の流動化処理システム

Also Published As

Publication number Publication date
EP1257932A1 (en) 2002-11-20
CN1423783A (zh) 2003-06-11
US20030014362A1 (en) 2003-01-16
KR20010082133A (ko) 2001-08-29
KR100542386B1 (ko) 2006-01-10
AU3613401A (en) 2001-08-27
WO2001061532A1 (en) 2001-08-23

Similar Documents

Publication Publication Date Title
AU2006247518B2 (en) Money transfer cards, systems and methods
US8083133B2 (en) System and method for accounting for activation of stored value cards
EP0791202B1 (en) Computerized payment system for purchasing information products by electronic transfer on the internet
US7783539B2 (en) Derivative currency-exchange transactions
AU2006247911B2 (en) In-lane money transfer systems and methods
JP2001283115A (ja) 企業間代金決済管理システム及びこれらを用いた企業間代金決済管理方法
KR100432430B1 (ko) 전자증권을 이용한 전자지불 시스템 및 그 방법
US20030144935A1 (en) Methods and systems for processing, accounting, and administration of stored value cards
EP0949596A2 (en) Method and system to perform electronic value exchange and settlement among heterogeneous payment schemes with heterogeneous currencies
US20090254484A1 (en) Anon virtual prepaid internet shopping card
KR20080074039A (ko) 청구인과 연계된 결제카드를 이용한 입금방법 및 시스템
JP2001306750A (ja) くじ販売システム、及びその方法
KR100435854B1 (ko) 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
JPH10187830A (ja) 商品売買又は役務の提供に関する金銭支払い及び商品引渡し又は役務の提供判別システム及び方法及びプログラムを記録した記録媒体
US20030041022A1 (en) Electronic money instrument
KR20210121819A (ko) 해외직구 온라인 결제 시스템 및 이를 이용한 방법
KR20000059133A (ko) 온라인 및 오프라인 거래보호를 위한 지불유보 현금카드시스템
CA2592534C (en) Computerized payment system for purchasing information products by electronic transfer on the internet
JP2001297282A (ja) 決済管理システム
KR20030050147A (ko) 구매 전용 카드를 이용한 결제 방법 및 시스템
JP2002123781A (ja) 通信販売における注文・支払同時決済システム
AU696475C (en) Computerized payment system for purchasing information products by electronic transfer on the internet
KR20040026194A (ko) 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법
KR20030083122A (ko) 실시간 전자 상거래 정산 서비스 제공 시스템 및 그 방법
KR20020089996A (ko) 기업간 전자결제 관리 방법

Legal Events

Date Code Title Description
A02 Decision of refusal

Free format text: JAPANESE INTERMEDIATE CODE: A02

Effective date: 20040511