專利名稱：用于管理公司間的結(jié)算的系統(tǒng)及其方法
技術領域：
本發(fā)明涉及用于管理公司間的結(jié)算的系統(tǒng)。更準確地說，本發(fā)明涉及允許賣方公司和買方公司通過在銀行在線網(wǎng)絡上系統(tǒng)地執(zhí)行在買方公司和賣方公司間實施的總結(jié)算過程來更可靠地實施銷售額收取過程和購買價格付款過程的公司間的結(jié)算管理系統(tǒng)。另外，本發(fā)明涉及使用所述公司間的結(jié)算管理系統(tǒng)來管理公司間的結(jié)算的方法。
背景技術：
近來，與快速經(jīng)濟發(fā)展一致，公司間的交易量也以顯著速度相應地增長。在這些情況下，賣方公司與買方公司間的結(jié)算關系在社會中已經(jīng)成為一個重要的問題。
賣方公司和買方公司間的結(jié)算關系是一個重要的社會問題的原因如下。如果賣方公司和賣方公司間一個不可靠的結(jié)算系統(tǒng)導致各別公司破產(chǎn)，這個國家的基本經(jīng)濟秩序可能被破壞以及整個社會秩序可能受不利影響，從而導致嚴重的社會問題。
在公司間常規(guī)的交易結(jié)構中，提供商品或服務的賣方公司實施許多程序來要求買方公司支付銷售額。作為主要的支付方法，大多數(shù)買方公司喜歡用帳單來支付而不用現(xiàn)金，因為與用現(xiàn)金支付相比，如果用帳單支付的話，買方公司可更靈活地管理該資金。
因為用帳單支付涉及發(fā)行、收款等等復雜的過程，使用帳單支付作為主要支付方法的買方公司和賣方公司均必須面對一個很大的麻煩。另外，因為帳單通常脫機發(fā)送，總是存在被盜竊或丟失的風險。因此，使用帳單支付方法的買方公司和賣方公司必須采用另外的預防措施。
另外，在帳單支付方法中發(fā)行日期和支付日期是不同的。因此，接受來自買方公司的帳單的賣方公司冒買方公司破產(chǎn)不能實際支付購買價格的風險。如果這種風險變成現(xiàn)實并且發(fā)行帳單的買方公司破產(chǎn)而沒有支付購買價格，賣方公司會蒙受巨大損失。
此時，如果受損失的該賣方公司通過其他結(jié)算關系與其他公司有關，一個買方公司的破產(chǎn)可導致許多賣方公司的連鎖破產(chǎn)。如果不處理好這些問題，可導致嚴重的社會問題，巨大地損害社會的整個經(jīng)濟秩序。

發(fā)明內(nèi)容
本發(fā)明的目的是通過基于賣方公司從買方公司獲得的并作為資產(chǎn)抵押的應收帳款的權利，代表買方公司在線預付購買價格，使得買方公司與賣方公司建立結(jié)算系統(tǒng)而不發(fā)生特有的財政壓力(finanicial strains)。
本發(fā)明的另一目的是防止買方公司使用通過帳單的常規(guī)支付方法以提高在買方公司和賣方公司間形成的結(jié)算系統(tǒng)的可靠性。因此，可降低對賣方公司意外的破壞或損失。
本發(fā)明的另一目的是在在線網(wǎng)絡上系統(tǒng)地執(zhí)行在賣方公司和買方公司間實施的總的結(jié)算程序。通過在線網(wǎng)絡上這種系統(tǒng)的執(zhí)行，以便賣方公司和買方公司可方便地實施銷售額收取程序和購買價格支付程序而不會承擔被盜竊或丟失的不必要的風險。
本發(fā)明的另一目的是提高買方公司和相關賣方公司間的結(jié)算系統(tǒng)的可靠性，減少由各種公司的連鎖破產(chǎn)帶來的經(jīng)濟損失。
本發(fā)明的其他目的從下述的詳細說明和附圖將變得清楚。
為實現(xiàn)上述本發(fā)明的目的，本發(fā)明執(zhí)行由D/B單元、D/B管理服務器以及支付管理服務器組成的公司間的結(jié)算管理系統(tǒng)。所述的D/B單元包括具有許多驗證信息的驗證信息數(shù)據(jù)庫(“D/B”)、具有購買價格支出表信息的購買價格支出表信息D/B、具有許多貸款預付信息的貸款預付信息D/B、具有許多有關用信息卡預付購買價格的信息的信息卡購買價格預付信息D/B以及具有許多注冊信息的注冊信息D/B。
D/B單元有選擇地在所述D/B單元的相關字段中存儲上述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息或注冊信息等等或從D/B單元抽取所述信息。
所述支付管理服務器，在與用于通信的所述D/B管理服務器連接的狀態(tài)下，確定是否存儲或抽取所述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息等等。
另外，如果用于購買價格支出表的管理的事件以及請求銷售額支付的事件發(fā)生在買方公司和賣方公司的通信客戶機中，通過在線網(wǎng)絡與買方公司和賣方公司的所述通信客戶機連接的支付管理服務器分析所述各種信息、預付相關買方公司必段支付給賣方公司的購買價格并在預定期限后在線從買方公司收取等于預付金額的金額。
附圖的簡單說明

圖1是說明采用本發(fā)明的公司間結(jié)算關系的框圖。
圖2是說明根據(jù)本發(fā)明的公司間的結(jié)算管理系統(tǒng)的框圖。
圖3是說明根據(jù)本發(fā)明的優(yōu)選實施例的公司間結(jié)算方法的順序的流程圖。
圖4和圖5是說明根據(jù)本發(fā)明的優(yōu)選實施例的賣方公司通信客戶機和買方公司通信客戶機的最初顯示頁的框圖。
圖6是說明根據(jù)本發(fā)明的另一優(yōu)選實施例的公司間結(jié)算方法的順序的流程圖。
圖7和圖8是說明根據(jù)本發(fā)明的另一優(yōu)選實施例的用于買方公司的通信客戶機顯示的信息的框圖。
圖9是說明根據(jù)本發(fā)明的另一優(yōu)選實施例的公司間結(jié)算方法的順序的流程圖。
圖10和圖11是說明根據(jù)本發(fā)明的另一優(yōu)選實施例的用于賣方公司的通信客戶機的顯示的信息的框圖。
圖12是說明根據(jù)本發(fā)明的另一優(yōu)選實施例的公司間結(jié)算方法的順序的流程圖。
圖13a至圖13d是說明根據(jù)本發(fā)明的另一優(yōu)選實施例的買方公司的指定帳戶的結(jié)算狀況的框圖。
實現(xiàn)本發(fā)明的最佳方式現(xiàn)在將詳細地論述本發(fā)明的公司間結(jié)算管理系統(tǒng)及使用所述系統(tǒng)的方法，如附圖所示。
如圖1所示，根據(jù)本發(fā)明的公司間結(jié)算管理系統(tǒng)(100)是可靠地管理一個買方公司(400)和多個賣方公司(500)間的結(jié)算關系的金融機構如銀行(300)的計算機在線網(wǎng)絡的一部分。
如圖2所示，屬于銀行(300)的計算機在線網(wǎng)絡的本發(fā)明的公司間結(jié)算管理系統(tǒng)(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)。
所述D/B管理服務器(70)在D/B單元(80)的相關字段中有選擇地存儲所述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息、操作信息或注冊信息或從所述驗證信息D/B(81)、購買價格支出表信息D/B(82)、貸款預付信息D/B(83)、信用卡購買價格預付信息D/B(84)、操作信息D/B(85)或注冊信息D/B(86)抽取各種數(shù)據(jù)。
此時，所述D/B管理服務器(70)不僅存儲或抽取各種數(shù)據(jù)而且實施有效地管理各種數(shù)據(jù)而在最可能短的時間內(nèi)沒有冗余的智能功能。
如附圖所示，所述支付管理服務器(10)通過一設備如接口模塊(20)與買方公司(400)的通信客戶機(1)和賣方公司的通信客戶機(2)連接。
更準確地說，買方公司(400)的通信客戶機(1)如買方公司的計算機(1a)和買方公司的有線/無線電話(1b)以及賣方公司(500)的通信客戶機(2)如賣方公司的計算機(2a)和賣方公司的有線/無線電話(2b)通過銀行在線網(wǎng)絡如有線/無線互聯(lián)網(wǎng)、自動應答系統(tǒng)通信網(wǎng)絡、增值網(wǎng)絡或公眾交換電話網(wǎng)絡等連接到本發(fā)明的公司間結(jié)算管理系統(tǒng)(100)。
在這種情形下，支付管理服務器(10)通過驗證模塊(30)、購買價格支出表管理模塊(40)、預付收取管理模塊(50)和操作信息管理模塊(60)系統(tǒng)地控制D/B管理服務器。這樣，支付管理服務器(10)確定是否存儲或抽取某些驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息、操作信息或注冊信息。
另外，如果管理購買價格支出表的事件或要求銷售額預付的事件在所述的買方公司(400)的通信客戶機(1)或賣方公司(500)的通信客戶機(2)發(fā)生，支付管理服務器(10)系統(tǒng)地分析所述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息、操作信息以及注冊信息，并在線預付買方公司(400)必付支付給賣方公司(500)的購買價格。在過了預定限期后，所述支付管理系統(tǒng)(10)從買方公司(400)在線收取等于相關預付的金額。
所述驗證模塊(30)驗證通過買方公司(400)的通信客戶機(1)或賣方公司(500)的通信客戶機(2)訪問本發(fā)明的公司間結(jié)算管理系統(tǒng)(100)的買方公司(400)或賣方公司(500)。驗證模塊(30)通過使用所述驗證信息D/B(81)檢驗注冊來實施所述驗證功能。通過使用所述購買價格支出表信息D/B(82)，購買價格支出表管理模塊(40)管理買方公司(400)的通信客戶機(1)傳送的購買價格支出表。
因此，通過利用所述貸款預付信息D/B(83)和信用卡購買價格預付D/B(84)，預收管理模塊(50)管理對賣方公司所做的預付。使用所述操作信息D/B(85)和注冊信息D/B(86)，操作信息管理模塊(60)管理支付管理服務器(10)的詳細的操作事件。
此時，如附圖所示，帳戶管理模塊(90)緊連支付管理服務器(10)，所述的驗證模塊(30)、購買價格支出表管理模塊(40)、預收管理模塊(50)以及操作信息管理模塊(60)相似地連接到支付管理服務器(10)。在與支付管理服務器(10)通信連接的情況下，帳戶管理服務器(90)管理該系統(tǒng)(100)的指定帳戶(92)、買方公司(400)的指定帳戶(91)以及賣方公司(500)的指定帳戶(93)。
現(xiàn)在，詳細地說明根據(jù)本發(fā)明的使用上述公司間結(jié)算管理系統(tǒng)(100)的公司間結(jié)算管理方法。
首先，購買某些商品或服務的買方公司(400)和出售這些商品或服務的賣方公司(500)通過所述的買方公司(400)的通信客戶機(1)如買方公司的計算機(1a)和通過所述的賣方公司(500)的通信客戶機(2)如賣方公司的計算機(2a)訪問本發(fā)明的公司間結(jié)算管理系統(tǒng)(100)。當然，買方公司(400)和賣方公司(500)也可使用除計算機(1a或2a)外的各種通信客戶機。例如，可選擇買方公司的有線/無線通信設備(1b)或賣方公司的有線/無線通信設備(2b)來訪問公司間的結(jié)算管理系統(tǒng)(100)。
如果買方公司(400)或賣方公司(500)選擇有線/無線通信設備(1b或2b)來訪問本發(fā)明的系統(tǒng)，通信中繼站(200)將數(shù)據(jù)從買方公司的有線/無線通信設備(1b)或賣方公司的有線/無線通信設備(2b)傳送到接口模塊(20)，反之亦然。
當所述環(huán)境適當時，如圖3所示，支付管理服務器(10)確定是否有來自買方公司的計算機(1a)或賣方公司計算機(2a)的一系統(tǒng)訪問事件(步驟S1)。
如果沒有來自買方公司的計算機(1a)或賣方公司計算機(2a)的系統(tǒng)訪問事件，支付管理服務器(10)進入執(zhí)行步驟S11，如下所述。
然而，如果存在來自買方公司的計算機(1a)或賣方公司計算機(2a)的系統(tǒng)訪問事件，支付管理服務器(10)通過使用操作信息管理模塊(60)從操作信息D/B(80)抽取相關操作信息。然后，使用這些操作信息，支付管理服務器(10)產(chǎn)生驗證請求信息并將所生成的驗證請求信息發(fā)送給發(fā)布系統(tǒng)訪問事件的相關計算機(步驟S2)。
如果系統(tǒng)訪問事件自買方公司的計算機(1a)產(chǎn)生，這些驗證請求信息將被發(fā)送給買方公司的計算機(1a)。相反，如果賣方公司的計算機(2a)發(fā)布系統(tǒng)訪問事件，則驗證請求信息將被發(fā)送給賣方公司的計算機(2a)。
然后，相關計算機如買方公司的計算機(1a)或賣方公司的計算機(2a)解釋由支付管理服務器(10)發(fā)送的驗證請求信息并顯示這些信息，以使相關買方公司(400)或賣方公司(500)可迅速地獲得該險證。
支付管理服務器(10)連續(xù)地與接口模塊(20)檢驗以確定買方公司計算機(1a)或賣方公司計算機(2a)是否發(fā)送請求的驗證信息(步驟S3)。
如果確定買方公司計算機(1a)或賣方公司計算機(2a)未發(fā)送驗證信息，支付管理服務器(10)認為相關計算機還未完成驗證信息的輸入并進入步驟S4來等待驗證信息。
相反，如果確定買方公司計算機(1a)或賣方公司計算機(2a)已經(jīng)發(fā)送驗證信息，支付管理服務器(10)立即與驗證模塊(30)聯(lián)系以確定通過相關買方公司計算機(1a)或賣方公司計算機(2a)目前連接到系統(tǒng)(100)的買方公司(400)或賣方公司(500)是否已經(jīng)向系統(tǒng)注冊(步驟S5)。
此時，為被驗證為一個注冊的公司，買方公司(400)必須執(zhí)行與銀行(300)的一個單獨的買方公司協(xié)議。這種協(xié)議可以是如一個特定協(xié)議或一信用卡發(fā)行協(xié)議。另外，與這個協(xié)議有關的信息必須被記錄在驗證信息D/B(81)中。為使賣方公司(500)被驗證為一注冊公司，該賣方公司(500)必須執(zhí)行與銀行(300)的單獨的賣方公司協(xié)議，所述協(xié)議可是如貸款協(xié)議或信用卡成員公司的協(xié)議。相關信息也必須被記錄在驗證信息D/B(81)中。任何不能滿足上述條件的買方公司(400)或賣方公司(500)不會被驗證為一注冊公司并因此不能享受通過本發(fā)明提供的服務。
如果確定訪問系統(tǒng)(100)的公司不是一個注冊公司，支付管理服務器(10)產(chǎn)生一個注冊請求信息并將該注冊請求信息發(fā)送給相關公司的計算機(步驟S6)。該信息可表述為如“你不是一個注冊的客戶，請先注冊?！毕喾矗绻L問系統(tǒng)(100)的公司被確定是一注冊公司，使用操作信息管理模塊(60)，支付管理服務器(10)從注冊信息D/B(86)收集與公司有關的相關登記信息，然后確定所連的公司是買方公司(400)還是賣方公司(500)(步驟S7)。
如果該公司被確定是一買方公司(400)，支付管理服務器(10)為買方公司產(chǎn)生一個反映相關買方公司注冊信息的初始頁。當完成該初始頁時，支付管理服務器(10)將該初始頁發(fā)送給買方公司的計算機(步驟S8)。
然后買方公司計算機(1a)立即解釋發(fā)送的初始頁(601)并顯示該頁，如圖4所示，使得買方公司能方便地實施購買價格支出表的管理。
如果訪問系統(tǒng)(100)的公司被確定是賣方公司(500)，支付管理服務器(10)為賣方公司產(chǎn)生反映相關賣方公司注冊信息的一初始頁。當完成該初始頁時，支付管理服務器(10)將該初始頁發(fā)送給賣方公司計算機(2a)(步驟S6a)。
在該事件中，賣方公司計算機(2a)立即解釋被指定用于賣方公司的所述初始頁并顯示該頁，如圖5所示。因此，賣方公司(500)能方便地實施請求銷售額預付的步驟。
此時，購買價格支出表表示陳列買方公司(400)對所購買的商品或服務付給賣方公司(500)的支付款的報表。如果買方公司(400)發(fā)送一“應收帳款報表”作為購買價格支出表，這表示購買價格通過應收帳款已經(jīng)支付。如果買方公司(400)發(fā)送一“信用卡報表”作為購買價格支出表，這表示購買價格已經(jīng)由公司信用卡支付。所述公司信用卡是銀行(300)使用本發(fā)明的結(jié)算管理系統(tǒng)(100)發(fā)行給已經(jīng)簽訂“信用卡發(fā)行協(xié)議”的買方公司(400)的特殊卡。
如圖4所示，買方公司計算機(1a)的初始頁(601)包含以下項“發(fā)送信用卡報表”(602a)；“查看發(fā)送的信用卡報表”(603a)；“發(fā)送應收帳款報表”(602b)；“查看發(fā)送的應收帳款報表”(603b)；“查看付款明細”(604)；“查看延期付款明細”(605)；以及“查看處理結(jié)果”(606)。買方公司(400)通過點擊頁上的相關項實時確認或設置任何所述項。所述項可根據(jù)改變的情況被改變。
如圖5所示，賣方公司計算機(2a)的初始頁(607)包含以下項“查看銷售額預付的請求”(608)；“查看銷售明細”(609)；“貸款請求”(610a)；以及“信用卡購買請求”(610b)。賣方公司(500)通過點擊頁上的相關項來實時確認或調(diào)整任何所述項。當然，所述項也可根據(jù)情況改變而改變。
例如，賣方公司(500)通過選擇該項，貸款請求(610a)產(chǎn)生與貸款請求有關的信息。與貸款請求有關的信息表示請求出售某些商品或提供某些服務的賣方公司(500)發(fā)送給與買方公司(400)聯(lián)系的銀行(300)“通過應收帳款支付商品或服務的購買價格”的銷售額預付的信息。本發(fā)明的系統(tǒng)(100)基于所述“與貸款請求有關的信息”代表買方公司(400)預付請求的貸款額。因此，賣方公司(500)也預先收取由賣方公司提供的商品和服務的銷售額。
另外，賣方公司(500)可選擇項-信用卡購買請求(610b)并產(chǎn)生有關用信用卡購買的請求的信息。這樣，有關信用卡購買請求的信息表示請求出售某些商品或提供某些服務的賣方公司(500)發(fā)送給與買方公司(400)聯(lián)系的銀行(300)“使用公司信用卡支付商品或服務的購買價格”的銷售額預付的信息。本發(fā)明的系統(tǒng)(100)基于所述“有關信用卡購買的請求的信息”代表買方公司(400)預付信用卡購買價格。因此，賣方公司(500)可預先收取由賣方公司提供的商品或服務的銷售額。
另一方面，在買方計算機(1a)上顯示用于買方公司的初始頁(601)的情況下，支付管理服務器(10)確定在所述買方公司計算機(1a)中是否發(fā)生用于管理購買價格支出表的事件(步驟S9)。
如果確定在買方公司計算機(1a)沒有用于管理購買價格支出表的事件，支付管理服務器(10)進入步驟S9a并保持“等待”狀態(tài)。
相反，如果買方公司(400)點擊項“發(fā)送應收帳款報表“(602b)”或“發(fā)送信用卡報表”(602a)從而在買方公司計算機(1a)發(fā)生用于管理購買價格支出表的事件，支付管理服務器(10)訪問由買方公司計算機(1a)發(fā)送的購買價格支出表信息并迅速進行實施購買價格支出表管理(步驟S100)。
同樣，在賣方公司計算機(2a)上顯示用于賣方公司(607)的初始頁的情況下，支付管理服務器確定所述賣方公司計算機(2a)是否有請求銷售額預付的事件(步驟S10)。
此時，如果確定賣方公司計算機(2a)沒有請求銷售額預付的事件，支付管理服務器(10)進入步驟S10a并保持“等待”狀態(tài)。
相反，如果賣方公司(500)點擊項-“請求貸款”(610a)或“請求信用卡購買”(610b)從而在賣方公司計算機(2a)發(fā)生用于請求銷售額預付的事件，支付管理服務器(10)訪問由賣方公司計算機(2a)發(fā)送的銷售額預付信息并迅速進行實施銷售額預付(步驟S200)。
首先，詳細描述用于管理購買價格支出表的所述步驟(步驟S100)。
如圖6所示，支付管理服務器(10)確定是否有來自買方公司計算機(1a)的發(fā)送的應收帳款報表的事件(步驟S101)。
此時，如果買方公司(400)在初始頁(601)上點擊項“發(fā)送信用卡報表”(602a)并相應地確定用于發(fā)送信用卡報表的事件已經(jīng)發(fā)生而不是用于發(fā)送應帳帳款報表的事件，支付管理服務器(10)使用操作信息管理模塊(60)產(chǎn)生用于輸入有關信用卡購買的明細的信息。當結(jié)束該頁時，支付管理服務器通過接口模塊(20)發(fā)送用于輸入有關信用卡購買的明細的完成頁給買方公司計算機(1a)(步驟S102)。
然后買方公司計算機(1a)迅速解釋用于輸入有關信用卡購買的明細的信息并顯示它，如圖7所示，提供穩(wěn)定環(huán)境，其中買方公司(400)可創(chuàng)建有關信用卡購買的信息。
在這一階段，支付管理服務器(10)繼續(xù)與接口模塊(20)核對并確定買方公司計算機(1a)是否已經(jīng)發(fā)送有關信用卡購買的信息(步驟S103)。
如果買方公司(400)還沒有輸入有關信用卡購買的明細從而如果買方公司計算機(1a)還沒有發(fā)送有關信用卡購買的信息，支付管理服務器(10)進入步驟S104并保持等待狀態(tài)。
相反，如果買方公司完成有關信用卡購買的明細輸入并點擊“發(fā)送”項(612)并因此確定買方公司計算機(1a)已經(jīng)發(fā)送有關信用卡購買的信息，支付管理服務器(10)確定有關信用卡購買的所述信息是否可接受。例如，確定記錄在所述信息中作為應付金額的金額是否在信用保證金額范圍內(nèi)以及記錄在所述信息中作為應收公司的賣方公司是否是注冊的賣方公司等等(步驟S105)。
此時，如果在所述信息中記錄的金額超過信用保證金額的范圍或如果記錄作為應收公司的賣方公司不是注冊的賣方公司，支付管理服務器(10)進入到實施向買方公司計算機(1a)發(fā)送一錯誤信息的步驟(步驟S106)。
在該事件中，支付管理服務器(10)使用操作信息管理模塊(60)抽取存儲在操作信息D/B(85)中的某些操作信息。然后，使用這些操作信息，支付管理服務器(10)生成如“輸入的金額超過你的信用保證金額的范圍。請重試”的一條錯誤信息。生成的錯誤信息被發(fā)送到買方公司計算機(1a)。
相反，如果記錄在有關信用卡購買的信息中的金額未超過信用卡的預定信用范圍并且如果被記錄作為應收公司的賣方公司被確定是一注冊賣方公司，有關信用卡購買的所述信息被認為是可接受的。因此，支付管理服務器(10)進行收集和存儲有關信用卡購買的所述信息(步驟S107)。
支付管理服務器(10)發(fā)送由買方公司計算機(1a)發(fā)送的有關信用卡購買的信息給購買價格支付報表管理模塊(40)。在接收到有關信用卡購買的信息時，購買價格支出表管理模塊(40)立即發(fā)送所述信息給D/B管理服務器(70)。這樣，有關信用卡購買的信息被收集和存儲在購買價格支出表信息D/B(82)中。
另一方面，在所述步驟S101中，如果買方公司在初始頁(601)上點擊“發(fā)送應收帳款報表”項(602b)并且如果因此確定發(fā)送應收帳款報表的事件已經(jīng)發(fā)生，支付管理服務器(10)使用操作信息管理模塊(60)產(chǎn)生用于輸入相關應收帳款的明細的信息。然后支付管理服務器(10)通過接口模塊(20)發(fā)送用于輸入應收帳款的明細的完成信息給買方公司計算機(1a)。
在該事件中，買方公司計算機(1a)迅速解釋由支付管理服務器(10)發(fā)送的用于輸入應收帳款的明細(613)的信息，然后顯示該信息，如圖8所示，提供穩(wěn)定環(huán)境，其中買方公司(400)可創(chuàng)建有關應收帳款報表的信息。
在該階段，支付管理服務器(10)繼續(xù)與接口模塊(20)核對并確定買方公司計算機(1a)是否已經(jīng)發(fā)送有關應帳帳款報表的信息(步驟S109)。
如果買方公司(400)還未輸入有關應收帳款的明細，從而如果買方公司計算機(1a)還沒有發(fā)送有關應收帳款報表的信息，支付管理服務器(10)進入步驟S110并保持等待狀態(tài)。
相反，如果買方公司(400)完成有關應收帳款的明細輸入并點擊“發(fā)送”項(614)并因此確定買方公司計算機(1a)已經(jīng)發(fā)送有關應收帳款的信息，支付管理服務器(10)確定有關應收帳款的所述信息是否可接受。例如，確定記錄在所述信息中作為應付金額的的金額是否在應收帳款金額的預定限度內(nèi)以及記錄在所述信息中作為應收公司的賣方公司是否是注冊的賣方公司等等(步驟S111)。
此時，如果在所述信息中記錄的金額超過應收帳款金額的范圍或如果被記錄作為應收公司的賣方公司不是注冊的賣方公司，支付管理服務器(10)進入到實施向買方公司計算機(1a)發(fā)送一錯誤信息的步驟(步驟S112)。
在該事件中，支付管理服務器(10)使用操作信息管理模塊(60)抽取存儲在操作信息D/B(85)中的某些操作信息。因此，使用這些操作信息，支付管理服務器(10)生成如“輸入的金額超過應收帳款金額的范圍。請重試”的一條錯誤信息。生成的錯誤信息被發(fā)送到買方公司計算機(1a)。
相反，如果記錄在有關應收帳款報表的信息中的金額未超過應收帳款金額的預定范圍并且如果被記錄作為應收公司的賣方公司被確定是一注冊賣方公司，有關應收帳款報表的所述信息被認為是可接受的。因此，支付管理服務器(10)進行收集和存儲有關應收帳款報表的所述信息(步驟S113)。
支付管理服務器(10)發(fā)送由買方公司計算機(1a)發(fā)送的有關應收帳款報表的信息給購買價格報表管理模塊(40)。在接收到有關應收帳款報表的信息時，購買價格支出表管理模塊(40)立即發(fā)送所述信息給D/B管理服務器(70)。這樣，有關應收帳款報表的信息被收集和存儲在購買價格支出表信息D/B(82)中。
現(xiàn)在詳細描述購買價格預付的所述步驟(步驟S200)。
首先，如圖9所示，通過連續(xù)與接口模塊(20)核對，支付管理服務器(10)確定是否發(fā)生來自賣方公司計算機(2a)的基于應收帳款報表請求貸款的一個事件(步驟S201)。
此時，如果賣方公司(500)在初始頁(607)上點擊“信用卡購買請求(信用卡銷售額支付請求)項(610b)并因此如果確定已經(jīng)發(fā)生來自賣方公司計算機(2a)的信用卡銷售額支付的事件而不是基于應收帳款報表請求貸款的事件，支付管理服務器(10)使用操作信息管理模塊(60)生成用于輸入有關信用卡銷售的明細的信息。當完成該頁時，支付管理服務器通過接口模塊(20)發(fā)送用于輸入有關信用卡銷售的明細的完成頁給賣方公司計算機(2a)(步驟S202)。
然后賣方公司計算機(2a)迅速解釋用于輸入有關信用卡銷售(615)的明細的信息并顯示它，如圖10所示，提供穩(wěn)定環(huán)境，其中賣方公司可創(chuàng)建有關信用卡銷售的信息。
在該階段，支付管理服務器(10)繼續(xù)與接口模塊(20)核對并確定賣方公司計算機(2a)是否發(fā)送有關信用卡銷售的信息(步驟S203)。
如果賣方公司(500)還未輸入有關信用卡銷售的明細，從而如果賣方公司計算機(2a)還未發(fā)送有關信用卡銷售的信息，支付管理服務器(10)進入步驟S204并保持等待狀態(tài)。
相反，如果賣方公司(500)完成有關信用卡銷售的明細輸入并點擊“發(fā)送”項(616)并因此確定賣方公司計算機(2a)已經(jīng)發(fā)送有關信用卡銷售的信息，支付管理服務器(10)確定在所述有關信用卡銷售的信息中記錄的作為應付金額的金額是否未超過預定信用范圍余額(步驟S205)。
此時，如果在所述信息中記錄的金額超過信用范圍余額，支付管理服務器(10)進入實施向賣方公司計算機(2a)發(fā)送一條錯誤消息的步驟(步驟S206)。
在該事件中，支付管理服務器(10)使用操作信息管理模塊(60)來抽取存儲在操作信息D/B(85)中的某些操作信息。然后，使用這些操作信息，支付管理服務器(10)生成諸如“輸入的金額超過信用范圍余額，請重試”的一條錯誤消息。所生成的錯誤消息被發(fā)送給賣方公司計算機(2a)。
相反，如果在有關信用卡銷售的信息中記錄的金額未超過信用范圍余額，支付管理服務器(10)代表買方公司(400)向賣方公司(500)進行“信用卡銷售額”的預付。
在該事件中，支付管理服務器(10)指示帳戶管理模塊(90)完成“信用卡銷售額”的預付。在接收到這種指示時，帳戶管理模塊(90)立即從系統(tǒng)的指定帳戶(92)傳送特定現(xiàn)金額給賣方公司的指定帳戶(93)。因此，向買方公司(400)出售商品或提供服務的賣方公司(500)可在線方便地接收對于“提供的商品或服務”的“信用卡銷售額”的預付。
另一方面，在所述步驟S201中，如果賣方公司(500)在初始頁(607)上點擊“貸款請求”項(610a)并因此如果確定已經(jīng)發(fā)生來自賣方公司計算機(2a)的基于應收帳款報表請求貸款的事件，支付管理服務器(10)使用操作信息管理模塊(60)生成用于輸入貸款請求的明細的消息。然后支付管理服務器通過接口模塊(20)發(fā)送用于輸入貸款請求的明細的完成頁給賣方公司計算機(2a)(步驟S208)。
在這種情況下，賣方公司計算機(2a)迅速解釋由支付管理服務器發(fā)送的用于輸入貸款請求(617)的明細的消息并顯示該消息，如圖11所示，提供穩(wěn)定環(huán)境，其中賣方公司(500)可迅速處理貸款請求。
在該階段，支付管理服務器(10)繼續(xù)與接口模塊(20)核對并確定賣方公司計算機(2a)是否發(fā)送有關貸款請求的信息(步驟S203)。
如果賣方公司(500)還未輸入有關貸款請求的明細，從而如果賣方公司計算機(2a)還未發(fā)送有關貸款請求的信息，支付管理服務器(10)進入步驟S210并保持等待狀態(tài)。
相反，如果賣方公司(500)完成有關貸款請求的明細輸入并點擊“發(fā)送”項并因此確定賣方公司計算機(2a)已經(jīng)發(fā)送有關貸款請求的信息，支付管理服務器(10)確定在所述信息中記錄的作為貸款金額的金額是否在貸方結(jié)余的預定范圍內(nèi)(步驟S205)。
此時，如果在所述信息中記錄的請求貸款金額超過貸方結(jié)余的預定范圍，支付管理服務器(10)進入實施向賣方公司計算機(2a)發(fā)送一條錯誤消息的步驟(步驟S212)。
在該情況下，支付管理服務器(10)使用操作信息管理模塊(60)來抽取存儲在操作信息D/B(85)中的某些操作信息。然后，使用這些操作信息，支付管理服務器(10)生成諸如“輸入的金額超過貸方結(jié)余范圍，請重試”的一條錯誤消息。所生成的錯誤消息被發(fā)送給賣方公司計算機(2a)。
相反，如果在有關貸款請求的信息中記錄的請求的貸款金額未超過貸方結(jié)余的預定范圍，支付管理服務器(10)代表買方公司(400)向賣方公司(500)進行“貸款金額”的預付。
在該事件中，支付管理服務器(10)指示帳戶管理模塊(90)進行“貸款金額”的預付。在接收到這種指示時，帳戶管理模塊(90)從系統(tǒng)的指定帳戶(92)傳送特定現(xiàn)金額給賣方公司的指定帳戶(93)。因此，向買方公司(400)出售商品或提供服務的賣方公司(500)對于“提供的商品或服務”可在線方便地接收“貸款銷售額”的預付。
另一方面，如圖3所示，當完成用于銷售額的預付的所述步驟(步驟S200)時，支付管理服務器(10)使用購買價格支出表管理模塊(40)來抽取存儲在購買價格支出表信息D/B(82)中的購買價格支出表信息。然后支付管理服務器(10)預覽所述購買價格支出表信息以確定購買價格支出表是否包含當天到期的任何項(步驟11)。
如果購買價格報表有任何當天到期的項，支付管理服務器(10)與買方公司(400)的指定帳戶(91)核對以迅速支付買方公司的相關購買價格(步驟S300)。
首先，如圖12所示，支付管理服務器(10)控制帳戶管理模塊(90)并詳細分析發(fā)布當天到期的購買價格報表的買方公司(90)的指定帳戶(91)(步驟S301)。
然后支付管理服務器(10)進入確定當天到期的項是否服從“預收”，其中根據(jù)步驟S207和S213所做的預付的過程被集中(步驟S301a)。
此時，如果與當天到期的項有關的相關賣方公司(500)是未進行“要求銷售額預付”的一般賣方公司(500)并因此確定當天到期的項不服從“預收”但服從“一般處理(ordinary process)”，支付管理服務器(10)立即進行實施“一般處理”(步驟S301b)。相關領域的技術人員容易理解用于支付的一般處理。因此，我們省略圖12中所示的一般處理的詳細說明。
首先，支付管理服務器(10)確定服從一般處理的所述項是否是應收帳款報表內(nèi)的項。
如果服從一般處理的所述項被確定不屬于在應收帳款報表內(nèi)的項，支付管理服務器(10)認為服從一般處理的所述項是信用卡購買報表內(nèi)的項。然后，支付管理服務器(10)核對在買方公司的指定帳戶(91)中存儲的金額是否不少于“信用卡購買金額”。
如果在買方公司的指定帳戶(91)中存儲的金額低于“信用卡購買金額”，支付管理服務器(10)掛起是違約銀行(300)的信用卡債務人的買方公司(400)。同時，代表買方公司，支付管理服務器(10)向賣方公司(500)支付賣方公司(500)有權享有的“信用卡購買金額”。
相反，如果確定在買方公司的指定帳戶(91)中存儲的金額等于或大于“信用卡購買金額”，支付管理服務器(10)從買方公司的指定帳戶(91)發(fā)送相應金額給賣方公司(500)的指定帳戶(93)。因此，賣方公(500)接收對所提供的商品或服務的銷售額。
另一方面，如果服從一般處理的項被確定是“應收帳款報表”內(nèi)的項，支付管理服務器(10)核對在買方公司指定帳戶(91)中存儲的金額是否不低于“在應收帳款報表上的金額”。
此時，如果在買方公司指定帳戶(91)中存儲的金額低于“應收帳款報表上的金額”，支付管理服務器(10)中止此過程流。
相反，如果在買方公司指定帳戶(91)中存儲的金額等于或大于“應收帳款報表上的金額”，支付管理服務器(10)從買方公司指定帳戶(91)發(fā)送相應金額給賣方公司(500)指定帳戶(93)。因此，賣方公司(500)獲得它所提供的商品或服務的銷售額。
在所述步驟S301a中，如果當天到期的項被確定是服從預付收取的項，支付管理服務器(10)確定服從預付收取的所述項是否被從用于在步驟S213中實施的“貸款預付”的買方公司(400)收取(步驟S302)。
如果被確定當天到期的項不是“貸款預收項”，支付管理服務器(10)認為將從用于在步驟S207中實施的用于“信用卡購買預付金額”的買方公司(400)收取“服從預收項”將被收取。因此，支付管理服務器(10)通過預收管理模塊(50)抽取信用卡購買價格預付信息。然后，使用所述信用卡購買價格預付信息，支付管理服務器確定在買方公司指定帳戶(91)中存儲的金額是否不低于“信用卡購買預付金額”(步驟S303)。
此時，如圖13a所示，如果信用卡購買預付的金額是200以及在買方公司指定帳戶(91)中存儲的金額100(低于“信用卡購買預付的金額”)，因此確定在買方公司指定帳戶(91)中存儲的金額低于“信用卡購買預付金額”，支付管理服務器(10)收取在買方公司指定帳戶(91)中存儲的金額100，與此同時，對所述金額差100，掛起(hold)違約的銀行(300)的債務人的相應買方公司(400)(步驟S304)。
在此情況下，支付管理服務器(10)發(fā)送“掛起違約買方公司(400)”的消息發(fā)送給操作模塊(60)。在接收到所述消息時，操作模塊立即改變在注冊信息D/B(86)中存儲的有關所述買方公司的注冊信息。然后，所述買方公司(400)作為一違約公司被特性化和管理。
相反，如圖13b所示，如果信用卡購買預付的金額是50以及在買方公司指定帳戶(91)中存儲的金額為120，那么確定在買方公司指定帳戶(91)中存儲的金額大于“信用卡購買預付“，支付管理服務器(10)進行處理由銀行(300)所做的”信用卡購買預付金額“的收取(步驟S305)。
在此情況下，支付管理服務器(10)指示帳戶管理模塊(90)從在買方公司指定帳戶(91)中存儲的金額收取相應金額。在發(fā)生所述指示事件時，帳戶管理模塊(90)立即從買方公司指定帳戶(91)發(fā)送相應金額(如120中的50)給系統(tǒng)指定帳戶(92)。因此，銀行(300)可方便地收取在“信用卡購買預付步驟”中預付的金額。
一旦通過上述步驟完成“信用卡購買預付金額”的收取，支付管理服務器(10)進行從買方公司資金向賣方公司指定帳戶(93)的轉(zhuǎn)移減去所述“信用卡購買預付金額”后應付給賣方公司的銷售額的差額(步驟S309)。
在該事件中，支付管理服務器(10)指示帳戶管理模塊(90)從買方公司指定帳戶(91)轉(zhuǎn)移所述相應余額。在發(fā)生所述指示事件時，帳戶管理模塊(90)立即從具有剩余資金70的買方公司(400)的指定帳戶(91)向賣方公司指定帳戶(93)轉(zhuǎn)移“賣方公司(500)銷售額的余額”50。因此，賣方公司(500)接收用于它所提供的商品或服務的全部銷售額。
相反，在所述步驟S302中，如果“服從預收項”被確定是一“服從基于應收帳款報表的貸款預收項”，支付管理服務器(10)通過預收管理模塊(50)抽取貸款預付信息。然后，使用所述貸款預付信息，支付管理服務器(10)確定買方公司指定帳戶(91)中存儲的金額是否不低于貸款預付金額(步驟S306)。
此時，如圖13C所示，如果貸款預付金額是200以及在買方公司指定帳戶(91)中存儲的金額為100，從而確定買方公司指定帳戶(91)中存儲的金額小于“貸款預付金額”，支付管理服務器(10)收集在買方公司指定帳戶(91)中存儲的金額100，與此同時，對于所述金額差100，掛起是違約的銀行(300)的債務人的相應賣方公司(500)(步驟S307)。
在此情況下，支付管理服務器(10)向操作模塊(60)發(fā)送“掛起違約的賣方公司(400)”的消息。在收到所述消息時，操作模塊立即改變存儲在注冊信息D/B(86)中的與所述賣方公司(500)有關的注冊信息。然后，所述賣方公司(500)作為違約公司被特性化和管理。
相反，如圖13d所示，如果貸款預付金額是50以及在買方公司指定帳戶(91)中存儲的金額是120，并因此確定在買方公司指定帳戶(91)中存儲的金額大于“貸款預付金額”，支付管理服務器(10)進行由銀行(300)所做的“貸款預付金額”的收取(步驟S308)。
在此情況下，支付管理服務器(10)指示帳戶管理模塊(90)從買方公司指定帳戶(91)中存儲的金額收取相應金額。在發(fā)生所述指示事件時，帳戶管理模塊(90)立即將相應金額(如120中的50)從買方公司指定帳戶(91)發(fā)送到系統(tǒng)指定帳戶(92)。因此，銀行(300)可方便地收取在“貸款預付步驟”中預付的金額。
一旦通過上述步驟完成“貸款預付金額”的收取，支付管理服務器(10)進行從買方公司資金向賣方公司指定帳戶(93)轉(zhuǎn)移在減去所述“貸款預付金額”后應付給賣方公司的銷售額的差額。
在該事件中，支付管理服務器(10)指示帳戶管理模塊(90)從買方公司指定帳戶(91)轉(zhuǎn)移所述相應余額。在發(fā)生所述指示事件時，帳戶管理模塊(90)立即從具有剩余資金70的買方公司(400)指定帳戶發(fā)送“賣方公司(500)銷售額余額”，在這種情況下為50給賣方公司指定帳戶(93)。因此，賣方公司(500)獲得它所提供的商品或服務的全部銷售額。
因此，每當在買方公司通信客戶機(1)或賣方公司通信客戶機(2)發(fā)生購買價格支出表管理的事件或請求銷售額預付的事件，支付管理服務器(10)協(xié)調(diào)所述驗證模塊(30)、購買價格支出表管理模塊(40)、預收管理模塊(50)、操作信息管理模塊(60)以及帳戶管理模塊(90)以便用于購買價格支出表管理的步驟以及用于銷售額預付管理的步驟可系統(tǒng)地被處理。結(jié)果，買方公司和賣方公司基于銀行在線網(wǎng)絡可建立可靠的結(jié)算關系。
如上面詳細說明，本發(fā)明基于賣方公司從買方公司獲得并作為擔保提供的對應收帳款的權利，通過代表買方公司在線預付購買價格，允許買方公司與賣方公司建立可靠結(jié)算關系而不導致特有的財政壓力。
本發(fā)明也排除買方公司使用傳統(tǒng)的帳單支付方法，從而提高在買方公司和賣方公司間形成的結(jié)算系統(tǒng)的可靠性。因此，減少對賣方公司意外的損害或損失。
而且，本發(fā)明在在線網(wǎng)絡上系統(tǒng)地實現(xiàn)在賣方公司和賣方公司間實施的整個結(jié)算過程。通過在線網(wǎng)絡上這種系統(tǒng)的實施，其目的是賣方公司和買方公司可方便地實施銷售額收取過程和購買價格支付過程而不承受被盜竊或丟失的風險。
另外，本發(fā)明提高買方公司和賣方公司間結(jié)算系統(tǒng)的可靠性，減少由各種公司連鎖破產(chǎn)而帶來的經(jīng)濟損失。
本發(fā)明的優(yōu)選實施例在上面已經(jīng)特別地解釋和說明。然而，對相關領域的技術人員來說本發(fā)明可用各種方式改變并相應地實施是很顯然的。
這種改變的實施方式不必被理解為在技術方面脫離本發(fā)明并且被認為是包含在本發(fā)明的權利要求的范圍內(nèi)。
權利要求
1.一種公司間的結(jié)算管理系統(tǒng)，包括D/B單元，具有包含驗證信息的驗證信息數(shù)據(jù)庫(“D/B”)、包含購買價格支出表信息的購買價格支出表信息D/B、包含貸款預付信息的貸款預付信息D/B、包含有關用信用卡的購買價格預付信息的信用卡購買價格預付信息D/B以及包含有關相應買方公司和賣方公司的注冊信息的注冊信息D/B；D/B管理服務器，在所述D/B單元的相應字段中有選擇地存儲所述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息或注冊信息，或從所述D/B單元抽取相應信息；支付管理服務器，處于與所述D/B管理服務器連接用于通信的狀態(tài)下，確定是否存儲或抽取與相應的買方公司和賣方公司有關的所述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息以及注冊信息；通過銀行在線網(wǎng)絡與買方公司和賣方公司的通信客戶機連接；以及如果在買方公司和賣方公司的通信客戶機中發(fā)生用于管理購買價格支出表的事件以及請求購買價格預付的事件，分析與買方公司和賣方公司有關的所述驗證信息、購買價格支出表信息、貸款預付信息、信用卡購買價格預付信息、注冊信息，預付相應的買方公司必須支付給賣方公司的購買價格并在預定期限過后在線從買方公司收取等于所述預付金額的金額。
2.如權利要求1所述的公司間的結(jié)算管理系統(tǒng)，其中所述銀行在線網(wǎng)絡是互聯(lián)網(wǎng)、自動應答系統(tǒng)通信網(wǎng)絡、增值網(wǎng)絡或公眾交換電話網(wǎng)絡中的任何一種網(wǎng)絡。
3.如權利要求1所述的公司間的結(jié)算管理系統(tǒng)，其中所述支付管理服務器進一步與專門負責管理從所述買方公司通信客戶機發(fā)送的購買價格支出表的購買價格支出表管理模塊建立通信關系。
4.如權利要求1所述的公司間的結(jié)算管理系統(tǒng)，其中所述支付管理服務器進一步與專門負責管理從所述買方公司收取的預付金額的預收管理模塊建立通信關系。
5.如權利要求1所述的公司間的結(jié)算管理系統(tǒng)，其中所述支付管理服務器進一步與專門負責管理所述買方公司和賣方公司的指定帳戶的帳戶管理模塊建立通信關系。
6.一種公司間的結(jié)算管理方法，包括步驟確定是否在買方公司通信客戶機或賣方公司通信客戶機發(fā)生系統(tǒng)訪問事件；如果在買方公司通信客戶機或賣方公司通信客戶機發(fā)生系統(tǒng)訪問事件，通過連接的客戶機，確定所連接的公司是否是一注冊公司；如果所述連接的公司被確定是一注冊公司，確定所述注冊公司是否是買方公司；如果所述注冊公司被確定是一買方公司，為買方公司生成一初始頁并將用于買方公司的該完成的初始頁發(fā)送到所述買方公司的通信客戶機；確定在所述買方公司通信客戶機是否發(fā)生用于管理購買價格支出表的事件；以及如果在所述買方公司通信客戶機發(fā)生用于管理購買價格支出表的事件，訪問從所述買方公司通信客戶機發(fā)送的購買價格支出表信息并實施用于管理購買價格支出表的一系列步驟。
7.如權利要求6所述的公司間的結(jié)算管理方法，其中所述用于管理購買價格支出表的步驟包括以下步驟確定是否在所述買方公司的通信客戶機發(fā)生應收帳款報表發(fā)送的事件；如果在所述買方公司通信客戶機發(fā)生應收帳款報表發(fā)送事件，將用于與相關應收帳款有關的明細輸入的應收帳款信息輸入消息發(fā)送給所述買方公司通信客戶機；確定是否已經(jīng)從所述買方公司通信客戶機發(fā)送與所述應收帳款信息輸入消息一致的應收帳款信息；如果所述買方公司通信客戶機已經(jīng)發(fā)送與所述應收帳款信息輸入消息一致的應收帳款信息，確定與應收帳款報表有關的輸入信息是否可接受；以及如果所述輸入應收帳款信息被確定是可接受的，收集和存儲從所述買方公司通信客戶機發(fā)送的應收帳款報表信息。
8.如權利要求7所述的公司間的結(jié)算管理方法，進一步包括步驟如果所述事件不是應收帳款報表傳送，向所述買方公司通信客戶機發(fā)送用于與所述買方公司信用卡購買有關的明細輸入的信用卡購買報表輸入消息；確定所述買方公司通信客戶機是否已經(jīng)發(fā)送與所述信用卡購買報表輸入消息一致的信用卡購買信息；如果所述買方公司通信客戶機已經(jīng)發(fā)送與所述信用卡購買報表輸入消息一致的信用卡購買信息，確定與信用卡購買有關的輸入信息是否可接受；以及如果所述輸入的信用卡購買信息被確定是可接受的，收集和存儲由所述買方公司通信客戶機發(fā)送的信用卡購買報表信息。
9.如權利要求6所述的公司間的結(jié)算管理方法，進一步包括步驟如果相關公司被確定是一賣方公司，為賣方公司生成一初始頁并向所述賣方公司的通信客戶機發(fā)送用于賣方公司的完成的初始頁；確定是否已經(jīng)發(fā)生來自所述賣方公司通信客戶機的請求銷售額預付的事件；以及如果已經(jīng)發(fā)生來自所述賣方公司通信客戶機的請求銷售額預付的事件，訪問由所述賣方公司通信客戶機發(fā)送的銷售額預付請求信息并實施用于銷售額預付的一系列步驟。
10.如權利要求9所述的公司間的結(jié)算管理方法，其中銷售額預付的所述步驟包括以下步驟確定是否已經(jīng)發(fā)生來自所述賣方公司的通信客戶機的基于應收帳款報表的貸款請求的事件；如果已經(jīng)發(fā)生來自所述賣方公司的通信客戶機的基于應收帳款報表的貸款請求的事件，向所述賣方公司通信客戶機發(fā)送用于與貸款請求有關的明細輸入的貸款請求信息輸入消息；確定所述賣方公司通信客戶機是否已經(jīng)發(fā)送與所述貸款請求信息輸入消息一致的貸款請求信息；如果所述賣方公司通信客戶機已經(jīng)發(fā)送與所述貸款請求信息輸入消息一致的貸款請求信息，確定在所述貸款請求信息中記錄的請求的貸款金額是否未超過預定貸方結(jié)余；以及如果在所述貸款請求信息中記錄的請求的貸款金額未超過預定貸方結(jié)余，實施一系列步驟來完成所述請求的貸款金額的預付。
11.如權利要求10所述的公司間的結(jié)算管理方法，進一步包括步驟如果所述事件不是用于貸款請求，向所述賣方公司通信客戶機發(fā)送用于與所述賣方公司信用卡銷售有關的明細輸入的信用卡報表輸入消息；確定所述賣方公司通信客戶機是否已經(jīng)發(fā)送與所述信用卡銷售報表輸入消息一致的信用卡銷售信息；如果所述賣方公司通信客戶機已經(jīng)發(fā)送與所述信用卡銷售報表輸入消息一致的信用卡銷售信息，確定在所述信用卡銷售信息中記錄的信用卡銷售金額是否未超過預定貸方結(jié)余；以及如果在所述信用卡銷售信息中記錄的信用卡銷售金額未超過預定貸方結(jié)余，實施一系列步驟來完成預付請求的信用卡銷售金額。
12.如權利要求10所述的公司間的結(jié)算管理方法，在實施用于管理購買價格支出表的所述步驟后，進一步包括步驟確定在購買價格支出表中是否存在任何當天到期的項；以及如果在購買價格支出表中存在任何當天到期的項，核對發(fā)布所述購買價格支出表的買方公司的指定帳戶并實施用于管理購買價格結(jié)算的一系列步驟。
13.如權利要求12所述的公司間的結(jié)算管理方法，其中用于管理購買價格結(jié)算的所述步驟包括步驟確定當天到期的所述項是否服從預收；如果所述到期項服從預收，確定服從預收的所述項是否是服從基于應收帳款報表的貸款預付的收取的項；如果所述到期項服從基于應收帳款報表的貸款預付的收取，確定在所述買方公司指定帳戶存儲的金額是否不低于貸款預付的金額；以及如果在所述買方公司指定帳戶存儲的金額不低于貸款預付的金額，從所述買方公司指定帳戶存儲的金額收取所述貸款預付金額并在扣除所述貸款預付金額后在賣方公司指定帳戶中存儲購買價格的相應余額。
14.如權利要求13所述的公司間的結(jié)算管理方法，進一步包括如果所述買方公司指定帳戶金額低于所述貸款預付的金額，宣布所述賣方公司違約的步驟。
15.如權利要求13所述的公司間的結(jié)算管理方法，進一步包括步驟如果服從預收的所述項不是服從基于應收帳款報表的貸款預付的再收取的項，確定在所述買方公司指定帳戶中存儲的金額是否不低于信用卡購買價格預付的金額；如果在所述買方公司指定帳戶中存儲的所述金額不低于信用卡購買價格預付的金額，從所述買方公司指定帳戶存儲的金額中收取所述信用卡購買價格預付金額以及在賣方公司指定帳戶中扣除所述信用卡購買價格預付金額后存儲購買價格的相應余額。
16.如權利要求15所述的公司間的結(jié)算管理方法，進一步包括如果所述買方公司指定帳戶金額低于所述信用卡購買價格預付的金額，宣布所述買方公司違約的步驟。
全文摘要
本發(fā)明涉及用于管理公司間結(jié)算的系統(tǒng)及其方法。無論何時在買方通信客戶機或賣方通信客戶機中發(fā)生用于管理購買價格支付的細節(jié)或用于請求購買價格預付等的事件,本發(fā)明協(xié)調(diào)價格管理服務器、驗證模塊、用于管理購買價格支付的細節(jié)的模塊、用于管理管理預付款項的恢復以及帳戶管理模塊以便有系統(tǒng)地執(zhí)行管理購買價格支付的細節(jié)的步驟以及管理購買價格的預付的步驟等。因此,本發(fā)明允許不同的買方和賣方公司使用在線網(wǎng)絡在他們間形成可靠的結(jié)算關系。根據(jù)本發(fā)明,買方公司必須支付的購買價格通過銀行在線網(wǎng)絡被預付。因此,買方公司可方便地與賣方公司建立結(jié)算關系而不發(fā)生另外的費用。最終,本發(fā)明大大地增加買方公司和賣方公司間的結(jié)算系統(tǒng)的可靠性并因此減少由任何公司的連鎖破產(chǎn)導致的經(jīng)濟損失。
文檔編號G06Q30/04GK1423783SQ01808075
公開日2003年6月11日 申請日期2001年2月14日 優(yōu)先權日2000年2月15日
發(fā)明者任棟侖 申請人:株式會社新韓銀行