專利名稱：用于管理公司間結算的系統及其方法
技術領域：
本發明領域涉及用于管理公司間結算的系統。特別地，本發明涉及允許賣方公司和買方公司通過系統地實施在銀行在線網絡上在買方公司和賣方公司間實施的全部結算過程、免卻在賣方公司和買方公司間實施的脫機結算過程同時發生的不麻煩來更可靠地處理銷售額收取過程以及購買價格支付過程的公司間結算管理系統。另外，本發明涉及用于使用所述公司間結算管理系統的管理公司間結算的方法。
背景技術：
近來，對應于快速的經濟發展，公司間的交易量也相應地以顯著的速度增加。與這種公司間增長的交易一致，公司間結算關系也變得越來越復雜。
當公司間關系形成時，出售商品或服務的賣方公司通常實施某些過程來向相關的買方公司要求銷售額。按照慣例，大多數買方公司寧愿信用交易或匯票付款而不愿用現金支付，因為與用現金支付相比，如果用信用交易或通過匯票來支付買方公司可更靈活地管理資金。
然而，常規的信用交易或匯票付款包括復雜的過程。因此，使用信用交易或匯票付款作為主要支付方法的買方公司和賣方公司不得不經歷較大的麻煩。
另外，因為匯票通常是脫機傳送，經常要冒被盜或丟失的風險。因此，使用匯票支付方法的買方公司和賣方公司必須采用另外的預防措施。
如果在單個賣方公司和多個買方公司間的關系中采用所述匯票支付的方法，匯票支付的上述缺點將變得更嚴重。
發明內容
本發明的目的是在銀行在線網絡上有系統地實現在賣方公司和買方公司間實施的全部結算過程，并因此允許買方公司和賣方公司方便地實施銷售額收取過程和購買價格支付過程而不使用信用交易或匯票付款。
本發明的另一目的是通過在在線網絡上在賣方公司和買方公司間實施全部結算過程來減少脫機支付(off-line payment)系統如有被盜或丟失風險的復雜的購買價格支付過程的缺點。
本發明的另一目的是阻止買方公司使用常規的支付方法如信用交易或匯票付款，并因此提高在買方公司和賣方公司間形成的結算系統的可靠性。
本發明的另一目的是在在線網絡上有系統地實現賣方公司和買方公司間實施的全部收取/支付過程。通過在在線網絡上這種系統的實現，可簡化全部結算過程并最大化采用本發明的公司的競爭性。
本發明的其他目的從下面的詳細說明和附圖將變得更清楚。
為實現本發明的上述目的，本發明提供了一種公司間結算管理系統，該系統包括一D/B單元、一D/B管理服務器以及一支付管理服務器。所述D/B單元包括具有許多驗證信息的驗證信息數據庫(“D/B”)、具有銷售額收取報表信息的銷售額收取報表信息D/B、具有信用卡銷售預付信息的信用卡銷售預付信息D/B以及具有關于有關賣方公司和賣方公司的注冊信息的注冊信息D/B。
D/B單元有選擇地在所述D/B單元的相關字段中存儲關于賣方公司和買方公司的所述驗證信息、銷售額收取報表信息、信用卡銷售預付信息或注冊信息等等或從D/B單元的必要字段抽取所述信息。
所述支付管理服務器，在與用于通信的所述D/B管理服務器連接的狀態下，確定是否存儲或抽取關于賣方公司和買方公司的所述驗證信息、銷售額收取報表信息、信用卡銷售預付信息以及注冊信息。
另外，如果用于管理銷售額收取的事件或用于管理購買價格支付的事件發生在買方公司和賣方公司的通信客戶機中，通過銀行在線網絡與買方公司和賣方公司的所述通信客戶機連接的支付管理服務器有系統地分析有關賣方公司和買方公司的所述驗證信息、銷售額收取報表信息、信用卡銷售預付信息以及注冊信息并基于所述在線銀行網絡控制和管理相關買方公司和賣方公司間的結算關系。
附圖的簡單說明
圖1是說明采用本發明的公司間的結算關系的示圖；圖2是說明采用本發明的公司間的結算關系的另一示圖；圖3是說明根據本發明的公司間結算管理系統的示圖；圖4是說明根據本發明的一優選實施例的公司間結算方法的順序的流程圖；圖5至圖7是表示根據本發明的一優選實施例的為賣方公司的通信客戶機和買方公司的通信客戶機顯示的頁面的示圖；圖8是說明根據本發明的另一優選實施例的公司間結算方法的順序的流程圖；圖9和圖10是說明根據本發明的另一優選實施例的為買方公司的通信客戶機顯示的頁面的示圖；圖11是說明根據本發明的又一優選實施例的公司間結算方法的順序的流程圖；圖12是表示根據本發明的又一優選實施例的為賣方公司的通信客戶機顯示的消息的示圖；圖13是說明根據本發明的又一優選實施例的公司間結算方法的順序的流程圖；圖14和圖15是表示根據本發明的又一優選實施例的為買方公司的通信客戶機顯示的頁面的示圖；圖16是說明根據本發明的又一優選實施例的公司間結算方法的順序的流程圖；圖17a至圖17d是說明根據本發明的又一優選實施例的買主公司的指定帳戶的結算狀態的示圖；具體實施方式
將參考附圖詳細地說明本發明的公司間結算管理系統以及使用所述系統的方法的優選的實現方式。
如圖1所示，根據本發明的公司間結算管理系統(100)是可靠地管理賣方公司(400)和多個買方公司(500)間的結算關系的金融機構如銀行(300)的計算機在線網絡的一部分。
如圖2所示，采用本發明的公司間結算系統(100)的銀行(300)必須具有在初始化全等級服務(fu11 sca1e service)前滿足的某些用于有效實現本發明的公司間結算方法的條件。換句話說，銀行(300)必須向買方公司(500)發行信用卡(如對買方公司A(501)和買方公司B(502)來說分別具有1,000和500的最大信用保證金額)或必須準予買方公司(500)用于購買價格支付的貸款(如對買方公司(503)和買方公司(504)來說分別貸款額達到1,000和500)。
此時，銀行(300)可準備該環境，其中本發明可通過執行與買方公司(500)的單獨的協議如“信用卡發行協議”或“用于購買價格支付的貸款協議”以及預先執行與賣方公司(400)的單獨的協議如“用于銷售額支付的協議”或“信用卡會員商店協議”來合法地實現。
為使通過本發明向賣方公司(400)提供有效的服務而不出現問題，系統(100)必須存儲所述“用于銷售額支付的協議”或“信用卡會員商店協議”的內容。同樣，為使向買方公司(500)提供本發明的服務而不出現問題，系統(100)必須存儲所述“信用卡發行協議”或“用于購買價格支付的貸款協議”的內容。當然，沒有執行這類協議的任何賣方公司(400)或買方公司(500)不可能被驗證為一注冊公司或因此不可能享受根據本發明可獲得的服務。
如圖3所示，屬于銀行(300)的計算機在線網絡的本發明的公司間結算管理系統(100)主要由D/B單元(80)、D/B管理服務器(70)以及支付管理服務器(10)組成。在所述D/B單元(80)中包括具有許多驗證信息的驗證信息D/B(81)、具有有關銷售額收取報表的信息的銷售額收取報表信息D/B(82)、具有關于信用卡銷售預付的信息的信用卡銷售預付信用D/B(83)、具有許多操作信息的操作信息D/B(84)以及具有關于賣方公司(400)和買方公司(500)的許多注冊信息的注冊信息D/B(85)。
所述D/B管理服務器(70)有選擇地在D/B單元(80)的相關字段中存儲所述驗證信息、銷售額收取報表信息、信用卡銷售預付信息、操作信息或注冊信息，或從所述驗證信息D/B(81)、銷售額收取報表信息D/B(82)、信用卡銷售預付信用D/B(83)、操作信息D/B(84)或注冊信息D/B(85)抽取不同的數據。
此時，所述D/B管理服務器(70)不僅存儲或抽取不同的數據而且在盡可能最短的時間內實施有效管理不同數據而不冗余的智能功能。
如圖中所示，通過一設備如接口模塊(20)，所述支付管理服務器(10)與賣方公司(400)的通信客戶機(1)以及買方公司(500)的通信客戶機(2)連接。
更準確地說，通過銀行在線網絡如有線/無線互聯網、自動應答系統通信網絡、增值網絡或公用交換電話網絡等，賣方公司(400)的通信客戶機(1)如賣方公司的計算機(1a)和賣方公司的有線/無線電話(1b)以及買方公司(500)的通信客戶機(2)如買方公司的計算機(2a)和買方公司的有線/無線電話(2b)均被連接到本發明的公司間結算管理系統(100)。
在這種情況下，通過驗證模塊(30)、銷售額收取報表管理模塊(40)、預付收取管理模塊(50)以及操作信息管理模塊(60)，支付管理服務器(10)有系統地控制D/B管理服務器(70)。這樣，支付管理服務器(10)確定存儲還是抽取某些驗證信息、銷售額收取報表信息、信用卡銷售預付信息、操作信息或注冊信息。
另外，如果在所述賣方公司(400)的通信客戶機(1)和買方公司(500)的通信客戶機(2)發生管理銷售額收取的事件或管理購買價格支付的事件，支付管理服務器(10)有系統地分析有關賣方公司(400)和賣方公司(500)的所述驗證信息、銷售額收取報表信息、信用卡銷售預付信息、操作信息或注冊信息，并基于所述銀行在線網絡實施所述賣方公司(400)和買方公司(500)間的結算關系的全部管理。
所述驗證模塊(30)驗證通過賣方公司(400)的通信客戶機(1)或買方公司(500)的通信客戶機(2)訪問本發明的公司間結算管理系統(100)的賣方公司(400)或買方公司(500)。驗證模塊(30)通過使用所述驗證信息D/B(81)核對是否已經注冊來實施所述驗證功能。通過使用所述銷售額收取報表信息D/B(82)，銷售額收取報表管理模塊(40)管理賣方公司(400)的通信客戶機(1)發送的銷售額收取報表。
另外，通過利用所述的信用卡銷售預付信息D/B(83)，預付收取管理模塊(50)管理由系統(100)所做的對賣方公司的預付。使用所述操作信息D/B(84)和注冊信息D/B(85)，操作信息管理模塊(60)管理支付管理服務器(10)的詳細的操作內容。
此時，如圖中所示，帳戶管理模塊(90)被接近地連接到支付管理服務器(10)，同時所述驗證模塊(30)、銷售額收取報表管理模塊(40)、預付收取管理模塊(50)以及操作信息管理模塊(60)也被相似地連接到支付管理服務器(10)。在用于與支付管理服務器(10)通信的連接狀態下，帳戶管理服務器(90)管理系統(100)的指定帳戶(92)、賣方公司(400)的指定帳戶(91)以及買方公司(500)的指定帳戶(93)。
現在，詳細地描述根據本發明的使用上述的公司間結算管理系統(100)的公司間結算管理方法。
首先，出售某些商品或服務的賣方公司(400)以及購買這類商品或服務的買方公司(500)通過所述賣方公司(400)的通信客戶機(1)如賣方公司的計算機(1a)和通過所述賣方公司(500)的通信客戶機(2)如賣方公司的計算機(2a)訪問本發明的公司間結算管理系統(100)。當然，賣方公司(400)和買方公司(500)也可使用除計算機(1a或2a)外的不同的通信客戶機。例如在賣方公司的有線/無線通信設備(1b)或在買方公司的有線/無線通信設備(2b)可被選擇用于訪問公司間結算管理系統(100)。
如果賣方公司(400)或買方公司(500)選擇有線/無線通信設備(1b或2b)用于訪問本發明的系統，通信中繼站(200)從賣方公司的有線/無線通信設備(1b)或買方公司的有線/無線通信設備(2b)向接口模塊(20)發送數據，或反之亦然。
當所述環境適當時，如圖4所示，支付管理服務器(10)確定是否有來自賣方公司計算機(1a)或買方公司計算機(2a)的系統訪問事件(步驟S1)。
如果沒有來自賣方公司計算機(1a)或買方公司計算機(2a)的系統訪問事件，支付管理服務器(10)進入實施如下所述的步驟S15。
然而，如果有來自賣方公司計算機(1a)或賣方公司計算機(2a)的系統訪問事件，支付管理服務器(10)通過使用操作信息管理模塊(60)從操作信息D/B(80)抽取相關的操作信息。此后，使用所述操作信息，支付管理服務器(10)生成一驗證請求消息并向發布系統訪問事件的相關的計算機發送所生成的驗證請求消息(步驟S2)。
如果系統訪問事件是由賣方公司的計算機(1a)產生，所述驗證請求消息將被發送給賣方公司計算機(1a)。相反，如果買方公司計算機(2a)發布系統訪問事件，則驗證請求消息將被發送給買方公司計算機(2a)。
然后，相關計算機如賣方公司計算機(1a)或買方公司計算機(2a)解釋從支付管理服務器(10)發送的驗證請求消息并顯示該消息以便相關的賣方公司(400)或買方公司(500)可快速地獲得該驗證。
支付管理服務器(10)連續地與接口模塊(20)核對以確定賣方公司的計算機(1a)或買方公司的計算機(2a)是否已經發送請求的驗證信息(步驟S3)。
如果確定賣方公司計算機(1a)或買方公司計算機(2a)還沒有發送驗證信息，支付管理服務器(10)認為相關計算機還沒有完成驗證信息的輸入并轉到步驟S4來等待驗證信息。
相反，如果確定賣方公司計算機(1a)或買方公司計算機(2a)已經發送驗證信息，支付管理服務器(10)立即與驗證模塊(30)聯系來確定目前通過相關賣方公司計算機(1a)或買方公司計算機(2a)連接到系統(100)的賣方公司(400)或買方公司(500)是否已經與系統注冊(步驟S5)。
如果確定訪問系統(100)的管理公司不是注冊的管理公司，支付管理服務器(10)生成一注冊請求消息并將該注冊請求消息發送給相關公司的計算機(步驟S6)。該信息可表述為如“你不是一個注冊的客戶機。請先注冊”。
相反，如果訪問系統(100)的管理公司被確定是一注冊的管理公司，支付管理服務器(10)生成一主頁并將該主頁發送給相關管理公司的計算機如賣方公司計算機(1a)或買方公司計算機(2a)(步驟S7)。
然后，管理公司的相關計算機快速解釋從系統(100)傳送的主頁(601)并顯示它，如圖5所示。因此，其中賣方公司(400)和買方公司(500)可方便地實施公司間結算過程的基本環境被建立。
另一方面，在主頁(601)在相關管理公司的計算機(賣方公司計算機(1a)或買方公司計算機(2a))中被顯示的情況下，支付管理服務器(10)確定是否有來自相關管理公司的計算機的結算事件(步驟S8)。
如果確定沒有來自相關管理公司計算機的結算事件，支付管理服務器(10)進入實施如下所述的步驟S15。
然而，如果賣方公司(400)或買方公司(500)點擊如主頁(601)上的“結算管理系統(602)”，并由此確定有來自賣方公司計算機(1a)或買方公司計算機(2a)的結算事件，使用操作信息管理模塊(60)，從注冊信息D/B(86)收集關于相關管理公司的相關注冊信息，并因此確定連接的管理公司是賣方公司(400)還是買方公司(500)(步驟S9和S10)。
如果公司被確定是一賣方公司(400)，支付管理服務器(10)為賣方公司生成反映相關賣方公司注冊信息的一初始頁。當完成該初始頁時，支付管理服務器(10)向賣方公司計算機(1a)發送該初始頁(步驟S12)。
然后賣方公司計算機(1a)立即解釋用于賣方公司的所發送的初始頁(603)并如圖6所示顯示該頁，允許賣方公司方便地實施銷售額收取過程。
此時，如圖所示，用于賣方公司的初始頁(603)包括如“發送應收帳款報表(604)”、“發送信用卡銷售報表(605)”、“信用卡銷售預付請求(606)”、“預覽發送的明細(608)”、“預覽收取明細(609)”以及“預覽處理結果(610)”等等。通過選擇和點擊相關項，賣方公司(400)可實時確認或設置相關項。當然，這些項可根據相關情況改變。
例如，在按如下所術發送信用卡銷售報表后，希望通過信用卡銷售預付過程來操作資金的賣方公司(400)可從用于賣方公司的初始頁(603)選擇項“信用卡銷售預付請求(606)”。用這種方式，可創建信用卡銷售預付請求信息。
信用卡銷售預付請求信息表示關于由出售商品或服務的賣方公司(400)向與使用公司的信用卡支付用于商品或服務的購買價格的買方公司(500)有關的銀行(300)所做的信用卡銷售額的預付的請求的信息。基于“信用卡銷售預付信息”，金融機構如銀行(300)代表買方公司(500)向賣方公司(400)預付“信用卡支付總額”。因此，賣方公司(400)可收取用于它所提供的商品或服務的銷售額。
在如上所述在賣方公司計算機(1a)上顯示用于賣方公司(400)的初始頁的情況下，支付管理服務器(10)確定是否有來自賣方公司計算機(1a)的銷售額收取報表管理事件(步驟S13)。
銷售額收取報表表示包含詳細的銷售信息如“出售商品、銷售價格、支付方式、支付日期等等”的報表。如果賣方公司(400)發送一“信用卡銷售報表”作為所述的銷售額收取報表，這表示買方公司(500)的支付方式是公司的信用卡。如果賣方公司(400)發送一“應收帳款報表”作為這種銷售額收取報表，這表示買方公司(500)是使用應收帳款作為支付方式。
此時，公司信用卡表示采用本發明的公司間結算系統(100)的銀行(300)發行給進入所述“信用卡發行協議”的買方公司(500)的一種特殊的信用卡。
此時，如果確定沒有來自賣方公司計算機(1a)的用于銷售額收取報表管理的事件，支付管理服務器進入實施如下所述的步驟S14。
然而，如果賣方公司(400)點擊用于一賣方公司的初始頁(603)上的如“發送應收帳款報表(604)”或“發送信用卡銷售報表(605)”，并因此確定有來自賣方公司計算機(1a)的用于銷售額收取報表管理的事件，支付管理服務器(10)引用從所述賣方公司計算機(1a)發送的銷售額收取報表信息并快速實施用于管理銷售額收取報表的過程(步驟S100)。
當用于管理銷售額收取報表的過程通過所述步驟S100完成時，支付管理服務器(10)確定是否有來自賣方公司計算機(1a)的用于請求信用卡銷售預付的事件(步驟S14)。
如果確定沒有來自賣方公司計算機(1a)的用于請求信用卡銷售預付的事件，支付管理服務器(10)進入實施如下所述的步驟S15。
相反，如果賣方公司(400)單擊用于賣方公司的初始頁(603)上的項如“信用卡銷售預付請求(606)”，并因此確定有來自賣方公司計算機(1a)的用于請求信用卡銷售預付的事件，支付管理服務器(10)引用從所述賣方公司計算機(1a)發送的信用卡銷售預付請求信息并快速實施用于信用卡銷售預付的步驟(步驟S200)。
另一方面，在所述步驟S10中，如果管理公司被確定為是一買方公司(500)而不是賣方公司(400)，支付管理服務器(10)生成用于買方公司反映相關買方公司注冊信息的初始頁。當完成該初始頁時，支付管理服務器(10)將該初始頁發送給買方公司計算機(2a)(步驟S11)。
買方公司計算機(2a)立即解釋為一買方公司所設計的所述初始頁(611)并如圖7所示顯示該頁面。因此，買方公司(500)可方便地實施用于購買價格管理的步驟。
如圖中所示，用于買方公司的初始頁(611)包括如“預覽購買明細(612)”、“信用卡購買額預付(613)”等等。通過選擇和點擊如上所述的項，買方公司(500)可實時地確認或設置相關項。當然，如為賣方公司設計的初始頁(603)一樣，上述項可根據相關情況改變。
此時，通過選擇初始頁(611)上的項“信用卡購買額預付(613)”，買方公司(500)可生成信用卡購買額預付信息。所述信用卡購買額預付信息表示有關在到期前由購買來自賣方公司(400)的某些商品或服務的買方公司(500)支付的某一信用卡購買額的信息。基于所述“信用卡購買額預付信息”，本發明的系統(100)從由買方公司(500)的指定的特定帳戶發送“信用卡支付額”。如此，根據買方公司(500)的意圖，在到期前可預付某些信用卡支付額。
通過如上所述的步驟，在買方公司的初始頁(611)被顯示在買方公司計算機(2a)上的情況下，支付管理服務器(10)確定是否有來自買方公司計算機(2a)的用于購買價格管理的事件(步驟S16)。
此時，如果確定沒有來自買方公司計算機(2a)的購買價格管理事件，支付管理服務器進入如下所述的步驟S17。
相反，如果買方公司(500)點擊“預覽購買明細(612)”或“信用卡購買額預付(613)”，并因此確定是否有來自買方公司計算機(2a)的用于購買價格管理的事件，支付管理服務器(10)引用買方公司的計算機(2a)發送的購買價格管理信息并快速實施用于購買價格管理的步驟(步驟S300)。
現在，詳細說明用于銷售額收取報表管理的步驟(步驟S100)、用于信用卡銷售預付的步驟(步驟S200)以及用于購買價格管理的步驟(步驟S300)。
首先，詳細說明用于銷售額收取報表管理的步驟(步驟S100)。
如圖8所示，支付管理服務器(10)通過與接收模塊(20)連續核對來確定是否有來自賣方公司計算機(1a)的用于發送信用卡銷售報表的事件(步驟S101)。
同時，如果賣方公司(400)點擊在初始頁(601)上的項“發送應收帳款報表(604)”，并因此確定用于發送應收帳款報表的事件是否發生而不是用于發送信用卡銷售報表的事件，支付管理服務器(10)使用操作信息管理模塊來生成用于輸入關于應收帳款的明細的消息。當完成該頁時，支付管理服務器通過接口模塊(20)向賣方公司計算機(1a)發送用于輸入關于應收帳款的明細的完成頁(步驟S102)。
然后賣方公司計算機(1a)迅速解釋用于輸入關于應收帳款(614)的明細的消息并如圖9所示顯示它，提供其中賣方公司(400)可創建關于應收帳款的信息的穩定環境。
在該階段，支付管理服務器(10)連續地與接口模塊(20)核對并確定賣方公司計算機(1a)是否已經發送有關應收帳款報表的信息(步驟S103)。
如果賣方公司(400)還沒有輸入關于應收帳款報表的明細并因此如果還沒有從賣方公司計算機(1a)發送有關應收帳款報表的信息，支付管理服務器(10)進入步驟S104并保持等待狀態。
相反，如果賣方公司(400)完成關于應收帳款報表的明細的輸入并點擊項“發送”(617)，并因此如果確定賣方公司計算機(1a)已經發送有關應收帳款報表的信息，支付管理服務器(10)確定所述有關應收帳款報表的信息是否是可接受的。例如，確定記錄在所述信息中的金額作為待收取的應收帳款金額是否在相關買方公司(500)的貸款限額的限度內，買方公司的指定帳戶(93)是否有可收回的一定余額以及記錄在所述信息中的買方公司(500)作為支付公司是否是一注冊的買方公司等等(步驟S105)。
此時，如果在所述信息中記錄的金額超過貸款金額的限度，如果在買方公司的指定帳戶(93)中沒有可收回的足夠余額，或如果記錄為支付公司的買方公司(500)不是一注冊的買方公司(500)，支付管理服務器(10)進入實施一步驟來向賣方公司計算機(1a)發送一錯誤消息(步驟S106)。
在這種情況下，支付管理服務器(10)使用操作信息管理模塊(60)來抽取存儲在操作信息D/B(84)中的某些操作信息。然后，使用這類操作信息，支付管理服務器(10)生成諸如“輸入的金額超出買方公司的限額，請再試”的錯誤消息。所生成的錯誤消息被發送給賣方公司計算機(1a)。
相反，如果記錄在有關應收帳款報表的信息中的金額未超出相關買方公司(500)的預定的貸款限額，如果在買方公司的指定帳戶(93)中有足夠的可收回的余額，以及如果記錄為支付公司的買方公司(500)被確定是一注冊的買方公司(500)，有關應收帳款報表的所述信息被認為是可接受的。因此，支付管理服務器(10)進入收集和存儲有關應收帳款報表的所述信息并實施步驟來從買方公司的指定帳戶(93)向賣方公司指定帳戶劃撥記錄的將收取的應收帳款的金額(步驟S107和S107a)。
首先，支付管理服務器(10)向銷售額收取報表管理模塊(40)發送來自賣方公司計算機(1a)的有關應收帳款報表的信息。基于接收的有關應收帳款報表的信息，銷售額收取報表管理模塊(40)立即向D/B管理服務器(70)發送所述信息。如此，有關應收帳款報表的信息被收集以及存儲在銷售額收取報表信息D/B(82)中。
此后，支付管理服務器(10)控制帳戶管理服務器(90)向賣方公司指定帳戶(91)發送在買方公司指定帳戶(93)中存入的“用于購買價格支付的貸款金額”。如此，賣方公司(400)可接收它所提供的商品或服務的全部銷售額。
另一方面，在所述步驟S101，如果賣方公司(400)點擊初始頁(603)上的項“發送信用卡銷售報表”并且如果因此確定用于發送信用卡銷售報表的事件已經發生，支付管理服務器(10)使用操作信息管理模塊(60)生成用于輸入信用卡銷售報表的明細的消息。然后，支付管理服務器(10)通過接口模塊(20)向賣方公司計算機(1a)發送用于輸入信用卡銷售報表的明細的完成頁(步驟S108)。
在該事件中，賣方公司計算機(1a)快速解釋由支付管理服務器(10)發送的用于輸入信用卡銷售報表的明細(616)的消息并如圖10顯示該消息，提供其中賣方公司(400)可創建有關信用卡銷售報表的信息的穩定環境。
在該階段，支付管理服務器(10)連續地與接口模塊(20)核對并確定賣方公司計算機(1a)是否已經發送有關信用卡銷售報表的信息(步驟S109)。
如果賣方公司(400)還沒有輸入關于信用卡銷售報表的明細，并因此如果確定有關信用卡銷售報表的信息還沒有從賣方公司計算機(1a)發送，支付管理服務器(10)進入步驟S110并保持等待狀態。
相反，如果賣方公司(400)完成關于信用卡銷售報表的明細的輸入并點擊項“發送(617)，并因此確定賣方公司計算機(1a)已經發送有關信用卡銷售報表的信息，支付管理服務器(10)確定所述有關信用卡銷售報表的信息是否是可接受的。例如，確定記錄在所述信息中的信用卡金額作為待收取的金額是否在賣方公司的預定限度內以及在相關買方公司的債務限額內，以及記錄在所述信息中的買方公司(500)作為支付公司是否是一注冊的買方公司(500)(步驟S111)。
此時，如果記錄在所述信息中的金額作為待收取的信用卡金額超過賣方公司的限額或相關買方公司的債務限額或如果記錄為應付公司的買方公司(500)不是一注冊的買方公司(500)，支付管理服務器(10)進入實施一步驟來向賣方公司計算機(1a)發送一錯誤消息(步驟S112)。
在這種情況下，支付管理服務器(10)使用操作信息管理模塊(60)來抽取存儲在操作信息D/B(85)中的某一操作信息。然后，使用該操作信息，支付管理服務器生成諸如“輸入金額超出限額，請再試”的錯誤消息。所生成的錯誤消息被發送到賣方公司計算機(1a)。
相反，如果記錄在有關信用卡銷售報表的信息中的金額未超過賣方公司的限額以及相關買方公司的債務限定以及如果記錄為應付公司的買方公司(500)被確定是一注冊的買方公司(500)，所述有關信用卡銷售報表的信息被認為是可接受的。因此，支付管理服務器(10)進行收集和存儲所述有關信用卡銷售報表的信息(步驟S113)。
支付管理服務器向銷售額收取報表管理模塊(40)發送從賣方公司計算機(1a)發送的有關信用卡銷售報表的信息。在接收到有關信用卡銷售報表的信息時，銷售額收取管理模塊(40)立即向D/B管理服務器(70)發送所述信息。如此，有關信用卡銷售報表的信息被收集和存儲在銷售額收取報表信息D/B(82)中。
現在，將詳細說明信用卡銷售額預付的所述步驟(步驟S200)。
首先，如果通過步驟S14確定在賣方公司(400)中已經發生用于請求信用卡銷售額預付的事件，如圖11所示，支付管理服務器(10)使用操作信息管理模塊(60)生成用于輸入關于信用卡銷售額預付請求的明細的頁面并向賣方公司計算機(1a)傳送完成的輸入頁。
在這種情況下，賣方公司計算機(1a)迅速解釋由支付管理服務器(10)發送的用于輸入信用卡銷售額預付請求的明細的消息(618)，然后如圖12所示顯示該消息，提供其中賣方公司(400)可快速地實施用于信用卡銷售額預付請求的穩定環境。
在該階段，支付管理服務器(10)連續與接口模塊(20)核對并確定賣方公司計算機(1a)是否已經發送有關信用卡銷售額預付請求的信息(步驟S202)。
如果賣方公司(400)還沒有輸入關于信用卡銷售額預付請求的明細并由此確定有關信用卡銷售額預付請求的信息是否還沒有從賣方公司計算機(1a)發送，支付管理服務器(10)進入步驟S203并保持等待狀態。
相反，如果賣方公司(400)完成關于信用卡銷售額預付請求的明細的輸入并點擊項“發送”(619)，并由此確定賣方公司計算機(1a)已經發送有關信用卡銷售額預付請求的信息，支付管理服務器(10)使用銷售額收取報表管理模塊確定所述有關信用卡銷售報表的信息是否可接受。例如，通過核對存儲在銷售額收取報表信息D/B(82)中的信用卡銷售報表，確定記錄在所述信息中的信用卡金額作為預付款是否在信用余額的預定限度內(步驟S204和S205)。
此時，如果記錄在所述信息中的金額作為預付的信用卡金額超過信用余額限額的金額，支付管理服務器(10)進入實施向賣方公司計算機(1a)發送一錯誤消息的步驟(步驟S206)。
在該事件中，支付管理服務器(10)使用操作信息管理模塊(60)抽取已經存儲在操作信息D/B(84)中的某一操作信息。然后，使用該操作信息，支付管理服務器(10)生成諸如“輸入金額超過信用限額。請再試”的錯誤消息。所生成的錯誤消息被發送給賣方公司計算機(1a)。
相反，如果記錄在有關信用卡銷售額預付請求信息的信息中的金額未超出信用余額限額，支付管理服務器(10)進入代表買方公司(500)向賣方公司(400)預付“請求的信用卡預付額”(步驟S207)。
支付管理服務器(10)指示帳戶管理模塊(90)預付“請求的信用卡預付額”。在接收到所述指示時，帳戶管理模塊(90)立即向賣方公司指定帳戶(93)發送來自系統指定帳戶(92)的相關現金額。接著，向買方公司(500)提供某些商品或服務的賣方公司(400)可方便地在線接收“請求的信用卡銷售預付額”。
現在，將詳細描述購買價格管理的所述步驟(步驟S300)。
首先，如圖13所示，支付管理服務器(10)通過連續與接口模塊(20)核對來確定是否有來自買方公司計算機(2a)的預覽購買明細的任何事件(步驟S401)。
如果確定沒有用于預覽購買明細的事件發生，支付管理服務器(10)進入實施如下所述的步驟S403。
相反，如果買方公司(10)點擊在買方公司初始頁(611)中的項“預覽購買明細(612)”并因此確定是否有來自買方公司計算機(2a)的用于預覽購買明細的事件，支付管理服務器(10)使用操作信息管理模塊(60)生成用于購買明細的清單并通過接口模塊(20)向買方公司計算機(2a)發送購買明細的完成清單(步驟S402)。
在該事件中，買方公司計算機(2a)迅速解釋由支付管理服務器(10)發送的購買明細的清單(622)，并如圖14所示顯示該消息，提供其中買方公司(500)可方便地預覽購買明細如購買商品、支付日期、支付金額等等的穩定環境。
然后，支付管理服務器(10)連續與接口模塊(20)核對并確定是否有來自買方公司計算機(2a)的用于信用卡購買價格預付的事件(步驟S403)。
如果沒有來自買方公司計算機(2a)的用于信用卡購買價格預付的事件，支付管理服務器(10)結束處理流程。
相反，如果買方公司(500)點擊項“信用卡購買價格預付(613)”并由此確定是否有來自買方公司計算機(2a)的用于信用卡購買價格預付的事件，支付管理服務器(10)使用操作信息管理模塊生成用于輸入信用卡購買價格預付的明細的頁面。然后支付管理服務器(10)通過接口模塊向買方公司計算機(2a)發送用于輸入信用卡購買價格預付的明細的完成頁(步驟S404)。
然后買方公司計算機(2a)迅速解釋由支付管理服務器(10)發送的用于輸入信用卡購買價格預付的明細的頁(623)以及如圖15所示顯示它，提供其中買方公司(500)可預付一定金額的信用卡購買價格的穩定環境。
在這種情況下，支付管理服務器(10)連續與接口模塊(20)核對來確定購買公司計算機(2a)是否已經發送信用卡購買價格預付信息(步驟S405)。
如果買方公司(500)還沒有完成用于輸入信用卡購買價格預付的明細的步驟并由此確定買方公司計算機(2a)還沒有發送信用卡購買價格預付信息，支付管理服務器(10)進入步驟S406并保持等待狀態。
相反，如果買方公司(500)完成用于輸入信用卡購買價格預付的明細的步驟并點擊項“發送(624)”，確定買方公司計算機(2a)已經發送信用卡購買價格信息。然后，支付管理服務器(10)立即進入基于所述信用卡購買價格預付信息，進行信用卡購買價格預付的步驟(步驟S407)。
在該階段，支付管理服務器(10)指示帳戶管理模塊(90)預付“信用卡購買價格”。帳戶管理模塊(90)在接收到所述指示后，立即向賣方公司指定帳戶(91)發送來自買方公司(500)指定的帳戶的相關現金額。接著，已經購買某些商品或服務的買方公司(500)可在支付到期前方便地預付一定的信用卡購買價格款。
另一方面，如圖4所示，當用于信用卡銷售額預付的步驟(步驟S200)完成時，支付管理服務器(10)通過利用銷售額收取報表管理模塊(40)從銷售額收取報表信息D/B(82)抽取銷售額收取報表信息(如信用卡銷售報表信息)。然后，支付管理服務器(10)核對所述信用卡銷售報表信息來確定信用卡銷售報表是否包含當天到期的任何信用卡銷售項(步驟S15)。
如果存儲在銷售額收取報表信息D/B(82)中的信用卡銷售報表中沒有當天到期的信用卡銷售項，支付管理服務器(10)中止處理流程。
相反，如果存儲在銷售額收取報表信息D/B(82)中的信用卡銷售報表包含當前到期的信用卡銷售項，支付管理服務器(10)核對買方公司指定帳戶(93)并迅速進入用于與當天到期的信用卡銷售項有關的信用卡購買價格結算的步驟(步驟S500)。
首先，如圖16所示，支付管理服務器(10)控制帳戶管理服務器(90)來緊密地預覽買方公司(500)的指定帳戶(91)，該買方公司與當天到期的信用卡銷售項有關(步驟S501)。
此后，支付管理服務器確定當天到期的信用卡銷售項是否屬于“預付額收取處理”，其中通過所述步驟S207實施的預付被收取(步驟S502)。
如果與當天到期的信用卡銷售項有關的賣方公司(400)是不屬于上述的“用于信用卡銷售額預付的步驟”的一普通的賣方公司(400)，當天到期的信用卡銷售項被確定不屬于“預付款收取處理”的項。然后，支付管理服務器(10)迅速實施“用于普通項處理”(步驟S520)。
首先，支付管理服務器(10)確定存入買方公司指定帳戶(93)中的金額是否不低于“買方公司(500)的信用卡購買價格”(步驟S521)。
如圖17a所示，如果買方公司(500)的信用卡購買價格是1000且存入買方公司指定帳戶(93)中的金額是500，并由此確定存入買方公司指定帳戶(93)中的金額低于買方公司(500)的信用卡購買價格，然后，支付管理服務器(10)代表買方公司(500)向賣方公司(400)支付由賣方公司(400)收取的買方公司信用卡購買價格1000(步驟S522)。
當完成所述支付時，支付管理服務器(10)收取500，該金額已經存入買方公司指定帳戶(93)中，保留作為銀行(300)的信用卡債務人的相關買方公司(500)拖欠差額500。
在該事件中，支付管理服務器(10)向操作模塊(60)發送有關“保留買方公司(500)拖欠”的消息。在接收到所述消息后，操作模塊(60)立即修改有關存儲在注冊信息D/B(85)中的相關買方公司(500)的注冊信息。因此，相關買方公司(500)被分類并作為一拖欠公司管理。
相反，如圖17b所示，如果買方公司的信用卡購買價格是1000且存入買方公司指定帳戶(93)中的金額是2000，存入買方公司指定帳戶(93)中的金額大于買方公司(500)的信用卡購買價格。那么，支付管理服務器進入用普通方式收取買方公司(500)的信用卡購買款的步驟(步驟S524)。
支付管理服務器(10)指示帳戶管理模塊(90)從買方公司指定帳戶(93)收取相關金額。在接收到所述指示后，帳戶管理模塊(90)立即向賣方公司指定帳戶(91)發送存入買方公司指定帳戶(93)中的2000中的1000。接著，賣方公司(400)可收取它所提供的商品或服務的銷售額。
另一方面，在所述步驟S502中，如果與當天到期的信用卡銷售項有關的賣方公司(400)是如上所述接收“信用卡銷售額預付”的賣方公司(400)，并由此確定當天到期的信用卡銷售項是否屬于“預付收取處理”，支付管理服務器(10)使用預付收取管理模塊(50)抽取信用卡銷售額預付信息。此后，支付管理服務器(10)確定存入買方公司指定帳戶(93)中的金額是否不低于“信用卡銷售預付款”(步驟S503)。
如圖17c所示，如果信用卡銷售預付款是800以及存入買方公司指定帳戶(93)中的金額是500，因此確定存入買方公司指定帳戶(93)中的金額低于信用卡銷售預付款。然后，支付管理服務器(10)收取存入買方公司指定帳戶(93)中的金額500，并進入實施保留作為銀行的信用卡債務人的買方公司拖欠差額300的步驟(步驟S504以及S505)。
此時，支付管理服務器(10)向操作模塊(60)發送有關“保留買方公司(500)拖欠”的消息。在接收到所述消息后，操作模塊(60)立即修改相關買方公司(500)的注冊信息。因此，買方公司被分類并按公司拖欠管理。
相反，如圖17d所示，如果信用卡銷售預付款是800且存入買方公司指定帳戶(93)中的金額是2000，因此確定存入買方公司指定帳戶(93)中的金額大于信用卡銷售預付金額。然后，支付管理服務器(10)進入實施普通收取預付的“信用卡銷售預付額”的步驟(步驟S506)。
在這種情況下，支付管理服務器(10)指示帳戶管理模塊(90)從買方公司指定帳戶(93)收取相關金額。在接收到所述指示后，帳戶管理模塊(90)立即從買方公司指定帳戶(93)向系統的指定帳戶(92)發送買方公司(500)劃撥買方公司(500)的有效資金2000中的800。這樣，銀行(300)可方便地收取在上述“用于信用卡銷售預付步驟”中支付的預付款。
只要通過上述步驟完成“信用卡銷售預付款”的收取，支付管理服務器(10)進入從買方公司(500)的資金向賣方公司指定帳戶(91)劃撥在減去所述的“信用卡銷售預付款”后應付給賣方公司的銷售額的余額(步驟S507)。
在這種情況下，支付管理服務器(10)指示帳戶管理模塊(90)從買方公司指定帳戶(93)發送所述相關余額。在發生所述指示事件后，帳戶管理模塊(90)立即從具有剩余資金1200的買方公司(500)的指定帳戶(93)向賣方公司指定帳戶(91)劃撥在此情況下“賣方公司(400)的信用額的余額”200。接著，賣方公司(400)可接收它所提供的商品或服務的完整銷售額。
此后，無論何時發生來自賣方公司通信客戶機(1)或買方公司通信客戶機(2)的用于銷售額管理或購買價格管理的事件，支付管理服務器(10)協調所述驗證模塊(30)、銷售額收取報表管理模塊(40)、預付收取管理模塊(50)、操作信息管理模塊(60)以及帳戶管理模塊(90)以便用于銷售額收取管理的步驟或用于購買價格支付管理的步驟可被有系統地實施。結果，基于銀行在線網絡，賣方公司(400)和買方公司(500)可確定可靠的結算關系。
如上面的詳細說明，通過在銀行在線網絡上實現在賣方公司和買方公司間的全部結算過程，本發明允許相關賣方公司和買方公司方便地實施銷售額收取過程和購買價格支付過程而不對這些過程采用信用或票據交易。
根據本發明，賣方公司和買方公司間的全部結算過程可完全在線實施。因此，對利用本發明的賣方公司和買方公司來說，本發明的一個實施例可容易地減小伴隨在脫機結算方法如支付購買價格的復雜的過程以及被盜或丟失的風險等等的不方便。
另外，基于本發明的實現，可防止買方公司使用常規的信用或票據交易方法。因此，本發明的一個實施例可增強在相關賣方公司和買方公司間形成的結算關系的信賴。
本發明的優選實施例在上面已經特別說明和描述。然而，對本領域的技術人員來說本發明可用多種方式改變和實現是顯而易見的。
這些改變的實現方式不能理解為在技術方面脫離本發明且應當認為包含在本發明附加的權利要求的范圍內。
權利要求
1.一種公司間結算管理系統，包括一D/B單元，具有包含認證信息的一認證信息數據庫(“D/B”)、包含銷售額收取報表信息的一銷售額收取報表信息D/B、包含有關信用卡銷售額預付的信息的一信用卡銷售額預付信息D/B、以及包含有關相關買方公司和賣方公司的注冊信息的一注冊信息D/B；一D/B管理服務器，在所述D/B單元的相關字段中有選擇地存儲有關賣方公司和買方公司的所述驗證信息、銷售額收取報表信息、信用卡銷售額預付信息或注冊信息，或從所述D/B單元抽取相關信息；一支付管理服務器在與所述D/B管理服務器連接以便通信的狀態下，確定存儲或抽取有關賣方公司和買方公司的所述驗證信息、銷售額收取報表信息、信用卡銷售額預付信息或注冊信息；通過銀行在線網絡與賣方公司和買方公司的通信客戶機連接；以及如果在一賣方公司或一買方公司的通信客戶機中發生用于銷售額收取管理的事件或用于購買價格支付管理的事件，系統地分析有關賣方公司和買方公司的所述驗證信息、銷售額收取報表信息、信用卡銷售額預付信息或注冊信息，以及因此在所述銀行在線網絡上控制和管理相關賣方公司和買方公司間的結算關系。
2.如權利要求1所述的公司間結算管理系統，其中所述銀行在線網絡是互聯網、自動應答系統通信網絡、增值網絡或公眾交換電話網絡中的任何網絡。
3.如權利要求1所述的公司間結算管理系統，其中所述支付管理服務器進一步與專門負責管理從所述賣方公司通信客戶機發送的銷售額收取報表的銷售額收取報表管理模塊建立通信關系。
4.如權利要求1所述的公司間結算管理系統，其中所述支付管理服務器進一步與專門負責管理從所述賣方公司收取的預付信用卡銷售額的預付收取管理模塊建立通信關系。
5.如權利要求1所述的公司間結算管理系統，其中所述支付管理服務器進一步與專門負責管理所述賣方公司和所述買方公司的指定帳戶的帳戶管理模塊建立通信關系。
6.一種公司間結算管理方法，包括步驟確定是否已經發生來自一管理公司的任何一個通信客戶機的結算事件，該管理公司已經被驗證；如果已經發生來自任何所述通信客戶機的結算事件，確定管理所述通信客戶機的所述管理公司是否是一賣方公司；如果管理所述通信客戶機的所述管理公司被確定是一賣方公司，生成為一賣方公司設計的初始頁并將用于一賣方公司的完成初始頁發送給所述賣方公司的通信客戶機；確定是否已經發生來自所述賣方公司通信客戶機的用于管理銷售額收取報表的事件；如果已經發生來自所述賣方公司通信客戶機的用于管理銷售額收取報表的事件，引用從所述賣方公司通信客戶機發送的銷售額收取報表并實施用于管理銷售額收取報表的一系列步驟；確定是否已經發生來自所述賣方公司通信客戶機的用于請求信用卡銷售額預付的事件；以及如果已經發生來自所述賣方公司通信客戶機的用于請求信用卡銷售額預付的事件，引用從賣方公司通信客戶機發送的信用卡銷售額預付請求信息以及實施用于預付請求的信用卡銷售額的一系列步驟。
7.如權利要求6所述的公司間結算管理方法，其中所述用于管理銷售額收取報表的步驟包括確定是否已經發生來自所述賣方公司的通信客戶機的用于發送信用卡銷售報表的事件；如果已經存在來自所述賣方公司的通信客戶機的用于發送信用卡銷售報表的事件，向所述賣方公司通信客戶機發送用于輸入關于信用卡銷售明細的信用卡銷售明細的輸入頁；確定是否已經從所述賣方公司通信客戶機發送與所述用于信用卡銷售明細的輸入頁對應的信用卡銷售報表信息；如果已經從所述賣方公司通信客戶機發送與所述用于信用卡銷售明細的輸入頁對應的信用卡銷售報表信息，確定所輸入的信用卡銷售報表信息是否滿足某些預定的條件；以及如果所述信用卡銷售報表信息滿足所述條件，收取和存儲所述信用卡銷售報表信息。
8.如權利要求7所述的公司間結算管理方法，進一步包括步驟如果所述事件不是用于發送信用卡銷售報表，向所述賣方公司通信客戶機發送用于輸入關于應收帳款的明細的應收帳款明細的輸入頁；確定是否已經從所述賣方公司通信客戶機發送與所述用于應收帳款明細的輸入頁對應的應收帳款報表信息；如果已經從所述賣方公司通信客戶機發送與所述用于應收帳款明細的輸入頁對應的應收帳款報表信息，確定輸入的應收帳款報表信息是否滿足某些預定條件；以及如果所述輸入的應收帳款報表信息滿足所述條件，收取和存儲所述應收帳款報表信息，并實施用于從買方公司帳戶向賣方公司帳戶劃撥賣方公司應收帳款的金額的步驟。
9.如權利要求6所述的公司間結算管理方法，其中所述用于預付信用卡銷售額的步驟包括步驟向所述賣方公司通信客戶機發送用于輸入關于信用卡銷售額預付請求的明細的信用卡銷售額預付請求明細的輸入頁；確定是否已經從所述賣方公司通信客戶機發送與所述用于信用卡銷售額預付請求明細的輸入頁對應的信用卡銷售額預付請求信息；如果已經從所述賣方公司通信客戶機發送與所述用于信用卡銷售額預付請求明細的輸入頁對應的信用卡銷售額預付請求報表信息，確定在所述信用卡銷售額預付請求信息中記錄的所請求的預付款是否不大于所述賣方公司的信用余額；以及如果在所述信用卡銷售額預付請求信息中記錄的所請求的預付款不大于所述賣方公司的信用余額，向所述賣方公司預付所述請求的預付款。
10.如權利要求6所述的公司間結算管理方法，進一步包括步驟如果管理所述通信客戶機的管理公司被確定是一買方公司而不是賣方公司，生成為一買方公司設計的初始頁，并向所述買方公司的通信客戶機發送用于買方公司的完成初始頁；確定是否已經發生來自所述買方公司通信客戶機的購買價格管理的事件；及如果已經發生來自所述買方公司通信客戶機的購買價格管理的事件，引用從所述買方公司通信客戶機發送的購買價格管理信息，并實施用于購買價格管理的一系列步驟。
11.如權利要求10所述的公司間結算管理方法，其中所述用于購買價格管理的步驟包括步驟確定是否已經發生來自所述買方公司通信客戶機的用于預覽購買明細的事件；如果已經存在來自所述買方公司通信客戶機的用于預覽購買明細的事件，通過收集關于所述買方公司購買的明細來生成購買明細清單，并向所述買方公司通信客戶機發送完成的購買明細清單；確定是否已經發生來自所述買方公司通信客戶機的用于信用卡購買價格預付的事件；如果已經發生來自所述買方公司通信客戶機的用于信用卡購買價格支付的事件，向所述買方公司通信客戶機發送用于輸入關于信用卡購買價格明細的信用卡購買價格預付明細的輸入頁；確定是否已經從所述買方公司通信客戶機發送與所述用于信用卡購買價格預付明細的輸入頁對應的信用卡購買價格預付信息；如果已經從所述買方公司通信客戶機發送與所述用于信用卡購買價格預付明細的輸入頁對應的信用卡購買價格預付信息，基于所述信用卡購買價格預付信息，實施用于預付信用卡購買價格的一系列步驟。
12.如權利要求6所述的公司間結算管理方法，在實施所述用于預付信用卡銷售額的步驟后，進一步包括步驟確定信用卡銷售報表是否包含當天到期的任何銷售項；以及如果信用卡銷售報表包含當天到期的一銷售項，核對與當天到期的所述信用卡銷售項有關的相關買方公司的指定帳戶并實施用于管理信用卡購買價格結算的一系列步驟。
13.如權利要求12所述的公司間結算管理方法，其中所述用于管理信用卡購買價格結算的步驟包括步驟確定當天到期的所述信用卡銷售項是否須經預付收取處理；如果當天到期的所述信用卡銷售項須經預付收取處理，確定存入所述買方公司指定帳戶的金額是否不低于信用卡銷售報表的預付款；以及如果存入所述買方公司指定帳戶的金額不低于信用卡銷售報表的預付款，從存入所述買方公司指定帳戶的金額中收取所述信用卡銷售報表的預付款并在扣除信用卡銷售報表的所述預付款后將銷售額的相應余額存入賣方公司指定帳戶。
14.如權利要求13所述的公司間結算管理方法，進一步包括收取存入所述買方公司指定帳戶中的余款以及如果存入所述買方公司指定帳戶中的金額低于所述信用卡銷售報表的預付款，宣布所述賣方公司拖欠。
全文摘要
本發明涉及用于管理公司間結算的系統及其方法。通過在銀行在線網絡上實現賣方公司和買方公司進行交易的整個結算過程，本發明允許這些賣方或買方公司方便地管理公司間結算而對于銷售額的收取或購買價格支付等等不采用信用卡或票據交易。根據本發明，賣方和買方公司間的整個結算過程被在線全部實施。因此，本發明的一個實施例，對賣方和買方公司的利益來說，輕易地減少脫機結算方法如對支付價格的復雜過程或被盜或丟失的麻煩。
文檔編號G06Q30/06GK1427975SQ01809192
公開日2003年7月2日 申請日期2001年3月9日 優先權日2000年3月10日
發明者任棟侖 申請人:株式會社新韓銀行