CN1423783A - 用于管理公司间的结算的系统及其方法 - Google Patents

用于管理公司间的结算的系统及其方法 Download PDF

Info

Publication number
CN1423783A
CN1423783A CN01808075A CN01808075A CN1423783A CN 1423783 A CN1423783 A CN 1423783A CN 01808075 A CN01808075 A CN 01808075A CN 01808075 A CN01808075 A CN 01808075A CN 1423783 A CN1423783 A CN 1423783A
Authority
CN
China
Prior art keywords
company
information
account
credit card
seller
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
CN01808075A
Other languages
English (en)
Inventor
任栋仑
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 CN1423783A publication Critical patent/CN1423783A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION 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/00—Payment architectures, schemes or protocols
    • G06Q20/08—Payment architectures
    • G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
    • G06Q20/102—Bill distribution or payments

Abstract

本发明涉及用于管理公司间结算的系统及其方法。无论何时在买方通信客户机或卖方通信客户机中发生用于管理购买价格支付的细节或用于请求购买价格预付等的事件,本发明协调价格管理服务器、验证模块、用于管理购买价格支付的细节的模块、用于管理管理预付款项的恢复以及帐户管理模块以便有系统地执行管理购买价格支付的细节的步骤以及管理购买价格的预付的步骤等。因此,本发明允许不同的买方和卖方公司使用在线网络在他们间形成可靠的结算关系。根据本发明,买方公司必须支付的购买价格通过银行在线网络被预付。因此,买方公司可方便地与卖方公司建立结算关系而不发生另外的费用。最终,本发明大大地增加买方公司和卖方公司间的结算系统的可靠性并因此减少由任何公司的连锁破产导致的经济损失。

Description

用于管理公司间的结算的系统及其方法
技术领域
本发明涉及用于管理公司间的结算的系统。更准确地说，本发明涉及允许卖方公司和买方公司通过在银行在线网络上系统地执行在买方公司和卖方公司间实施的总结算过程来更可靠地实施销售额收取过程和购买价格付款过程的公司间的结算管理系统。另外，本发明涉及使用所述公司间的结算管理系统来管理公司间的结算的方法。
技术背景
近来，与快速经济发展一致，公司间的交易量也以显著速度相应地增长。在这些情况下，卖方公司与买方公司间的结算关系在社会中已经成为一个重要的问题。
卖方公司和买方公司间的结算关系是一个重要的社会问题的原因如下。如果卖方公司和卖方公司间一个不可靠的结算系统导致各别公司破产，这个国家的基本经济秩序可能被破坏以及整个社会秩序可能受不利影响，从而导致严重的社会问题。
在公司间常规的交易结构中，提供商品或服务的卖方公司实施许多程序来要求买方公司支付销售额。作为主要的支付方法，大多数买方公司喜欢用帐单来支付而不用现金，因为与用现金支付相比，如果用帐单支付的话，买方公司可更灵活地管理该资金。
因为用帐单支付涉及发行、收款等等复杂的过程，使用帐单支付作为主要支付方法的买方公司和卖方公司均必须面对一个很大的麻烦。另外，因为帐单通常脱机发送，总是存在被盗窃或丢失的风险。因此，使用帐单支付方法的买方公司和卖方公司必须采用另外的预防措施。
另外，在帐单支付方法中发行日期和支付日期是不同的。因此，接受来自买方公司的帐单的卖方公司冒买方公司破产不能实际支付购买价格的风险。如果这种风险变成现实并且发行帐单的买方公司破产而没有支付购买价格，卖方公司会蒙受巨大损失。
此时，如果受损失的该卖方公司通过其他结算关系与其他公司有关，一个买方公司的破产可导致许多卖方公司的连锁破产。如果不处理好这些问题，可导致严重的社会问题，巨大地损害社会的整个经济秩序。
发明内容
本发明的目的是通过基于卖方公司从买方公司获得的并作为资产抵押的应收帐款的权利，代表买方公司在线预付购买价格，使得买方公司与卖方公司建立结算系统而不发生特有的财政压力(finanicial strains)。
本发明的另一目的是防止买方公司使用通过帐单的常规支付方法以提高在买方公司和卖方公司间形成的结算系统的可靠性。因此，可降低对卖方公司意外的破坏或损失。
本发明的另一目的是在在线网络上系统地执行在卖方公司和买方公司间实施的总的结算程序。通过在线网络上这种系统的执行，以便卖方公司和买方公司可方便地实施销售额收取程序和购买价格支付程序而不会承担被盗窃或丢失的不必要的风险。
本发明的另一目的是提高买方公司和相关卖方公司间的结算系统的可靠性，减少由各种公司的连锁破产带来的经济损失。
本发明的其他目的从下述的详细说明和附图将变得清楚。
为实现上述本发明的目的，本发明执行由D/B单元、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是说明根据本发明的优选实施例的卖方公司通信客户机和买方公司通信客户机的最初显示页的框图。
图6是说明根据本发明的另一优选实施例的公司间结算方法的顺序的流程图。
图7和图8是说明根据本发明的另一优选实施例的用于买方公司的通信客户机显示的信息的框图。
图9是说明根据本发明的另一优选实施例的公司间结算方法的顺序的流程图。
图10和图11是说明根据本发明的另一优选实施例的用于卖方公司的通信客户机的显示的信息的框图。
图12是说明根据本发明的另一优选实施例的公司间结算方法的顺序的流程图。
图13a至图13d是说明根据本发明的另一优选实施例的买方公司的指定帐户的结算状况的框图。
实现本发明的最佳方式
现在将详细地论述本发明的公司间结算管理系统及使用所述系统的方法，如附图所示。
如图1所示，根据本发明的公司间结算管理系统(100)是可靠地管理一个买方公司(400)和多个卖方公司(500)间的结算关系的金融机构如银行(300)的计算机在线网络的一部分。
如图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)。
所述D/B管理服务器(70)在D/B单元(80)的相关字段中有选择地存储所述验证信息、购买价格支出表信息、贷款预付信息、信用卡购买价格预付信息、操作信息或注册信息或从所述验证信息D/B(81)、购买价格支出表信息D/B(82)、贷款预付信息D/B(83)、信用卡购买价格预付信息D/B(84)、操作信息D/B(85)或注册信息D/B(86)抽取各种数据。
此时，所述D/B管理服务器(70)不仅存储或抽取各种数据而且实施有效地管理各种数据而在最可能短的时间内没有冗余的智能功能。
如附图所示，所述支付管理服务器(10)通过一设备如接口模块(20)与买方公司(400)的通信客户机(1)和卖方公司的通信客户机(2)连接。
更准确地说，买方公司(400)的通信客户机(1)如买方公司的计算机(1a)和买方公司的有线/无线电话(1b)以及卖方公司(500)的通信客户机(2)如卖方公司的计算机(2a)和卖方公司的有线/无线电话(2b)通过银行在线网络如有线/无线互联网、自动应答系统通信网络、增值网络或公众交换电话网络等连接到本发明的公司间结算管理系统(100)。
在这种情形下，支付管理服务器(10)通过验证模块(30)、购买价格支出表管理模块(40)、预付收取管理模块(50)和操作信息管理模块(60)系统地控制D/B管理服务器。这样，支付管理服务器(10)确定是否存储或抽取某些验证信息、购买价格支出表信息、贷款预付信息、信用卡购买价格预付信息、操作信息或注册信息。
另外，如果管理购买价格支出表的事件或要求销售额预付的事件在所述的买方公司(400)的通信客户机(1)或卖方公司(500)的通信客户机(2)发生，支付管理服务器(10)系统地分析所述验证信息、购买价格支出表信息、贷款预付信息、信用卡购买价格预付信息、操作信息以及注册信息，并在线预付买方公司(400)必付支付给卖方公司(500)的购买价格。在过了预定限期后，所述支付管理系统(10)从买方公司(400)在线收取等于相关预付的金额。
所述验证模块(30)验证通过买方公司(400)的通信客户机(1)或卖方公司(500)的通信客户机(2)访问本发明的公司间结算管理系统(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)管理该系统(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)，反之亦然。
当所述环境适当时，如图3所示，支付管理服务器(10)确定是否有来自买方公司的计算机(1a)或卖方公司计算机(2a)的一系统访问事件(步骤S1)。
如果没有来自买方公司的计算机(1a)或卖方公司计算机(2a)的系统访问事件，支付管理服务器(10)进入执行步骤S11，如下所述。
然而，如果存在来自买方公司的计算机(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)。
此时，为被验证为一个注册的公司，买方公司(400)必须执行与银行(300)的一个单独的买方公司协议。这种协议可以是如一个特定协议或一信用卡发行协议。另外，与这个协议有关的信息必须被记录在验证信息D/B(81)中。为使卖方公司(500)被验证为一注册公司，该卖方公司(500)必须执行与银行(300)的单独的卖方公司协议，所述协议可是如贷款协议或信用卡成员公司的协议。相关信息也必须被记录在验证信息D/B(81)中。任何不能满足上述条件的买方公司(400)或卖方公司(500)不会被验证为一注册公司并因此不能享受通过本发明提供的服务。
如果确定访问系统(100)的公司不是一个注册公司，支付管理服务器(10)产生一个注册请求信息并将该注册请求信息发送给相关公司的计算机(步骤S6)。该信息可表述为如“你不是一个注册的客户，请先注册。”
相反，如果访问系统(100)的公司被确定是一注册公司，使用操作信息管理模块(60)，支付管理服务器(10)从注册信息D/B(86)收集与公司有关的相关登记信息，然后确定所连的公司是买方公司(400)还是卖方公司(500)(步骤S7)。
如果该公司被确定是一买方公司(400)，支付管理服务器(10)为买方公司产生一个反映相关买方公司注册信息的初始页。当完成该初始页时，支付管理服务器(10)将该初始页发送给买方公司的计算机(步骤S8)。
然后买方公司计算机(1a)立即解释发送的初始页(601)并显示该页，如图4所示，使得买方公司能方便地实施购买价格支出表的管理。
如果访问系统(100)的公司被确定是卖方公司(500)，支付管理服务器(10)为卖方公司产生反映相关卖方公司注册信息的一初始页。当完成该初始页时，支付管理服务器(10)将该初始页发送给卖方公司计算机(2a)(步骤S6a)。
在该事件中，卖方公司计算机(2a)立即解释被指定用于卖方公司的所述初始页并显示该页，如图5所示。因此，卖方公司(500)能方便地实施请求销售额预付的步骤。
此时，购买价格支出表表示陈列买方公司(400)对所购买的商品或服务付给卖方公司(500)的支付款的报表。如果买方公司(400)发送一“应收帐款报表”作为购买价格支出表，这表示购买价格通过应收帐款已经支付。如果买方公司(400)发送一“信用卡报表”作为购买价格支出表，这表示购买价格已经由公司信用卡支付。所述公司信用卡是银行(300)使用本发明的结算管理系统(100)发行给已经签订“信用卡发行协议”的买方公司(400)的特殊卡。
如图4所示，买方公司计算机(1a)的初始页(601)包含以下项：“发送信用卡报表”(602a)；“查看发送的信用卡报表”(603a)；“发送应收帐款报表”(602b)；“查看发送的应收帐款报表”(603b)；“查看付款明细”(604)；“查看延期付款明细”(605)；以及“查看处理结果”(606)。买方公司(400)通过点击页上的相关项实时确认或设置任何所述项。所述项可根据改变的情况被改变。
如图5所示，卖方公司计算机(2a)的初始页(607)包含以下项：“查看销售额预付的请求”(608)；“查看销售明细”(609)；“贷款请求”(610a)；以及“信用卡购买请求”(610b)。卖方公司(500)通过点击页上的相关项来实时确认或调整任何所述项。当然，所述项也可根据情况改变而改变。
例如，卖方公司(500)通过选择该项，贷款请求(610a)产生与贷款请求有关的信息。与贷款请求有关的信息表示请求出售某些商品或提供某些服务的卖方公司(500)发送给与买方公司(400)联系的银行(300)“通过应收帐款支付商品或服务的购买价格”的销售额预付的信息。本发明的系统(100)基于所述“与贷款请求有关的信息”代表买方公司(400)预付请求的贷款额。因此，卖方公司(500)也预先收取由卖方公司提供的商品和服务的销售额。
另外，卖方公司(500)可选择项-信用卡购买请求(610b)并产生有关用信用卡购买的请求的信息。这样，有关信用卡购买请求的信息表示请求出售某些商品或提供某些服务的卖方公司(500)发送给与买方公司(400)联系的银行(300)“使用公司信用卡支付商品或服务的购买价格”的销售额预付的信息。本发明的系统(100)基于所述“有关信用卡购买的请求的信息”代表买方公司(400)预付信用卡购买价格。因此，卖方公司(500)可预先收取由卖方公司提供的商品或服务的销售额。
另一方面，在买方计算机(1a)上显示用于买方公司的初始页(601)的情况下，支付管理服务器(10)确定在所述买方公司计算机(1a)中是否发生用于管理购买价格支出表的事件(步骤S9)。
如果确定在买方公司计算机(1a)没有用于管理购买价格支出表的事件，支付管理服务器(10)进入步骤S9a并保持“等待”状态。
相反，如果买方公司(400)点击项“发送应收帐款报表“(602b)”或“发送信用卡报表”(602a)从而在买方公司计算机(1a)发生用于管理购买价格支出表的事件，支付管理服务器(10)访问由买方公司计算机(1a)发送的购买价格支出表信息并迅速进行实施购买价格支出表管理(步骤S100)。
同样，在卖方公司计算机(2a)上显示用于卖方公司(607)的初始页的情况下，支付管理服务器确定所述卖方公司计算机(2a)是否有请求销售额预付的事件(步骤S10)。
此时，如果确定卖方公司计算机(2a)没有请求销售额预付的事件，支付管理服务器(10)进入步骤S10a并保持“等待”状态。
相反，如果卖方公司(500)点击项-“请求贷款”(610a)或“请求信用卡购买”(610b)从而在卖方公司计算机(2a)发生用于请求销售额预付的事件，支付管理服务器(10)访问由卖方公司计算机(2a)发送的销售额预付信息并迅速进行实施销售额预付(步骤S200)。
首先，详细描述用于管理购买价格支出表的所述步骤(步骤S100)。
如图6所示，支付管理服务器(10)确定是否有来自买方公司计算机(1a)的发送的应收帐款报表的事件(步骤S101)。
此时，如果买方公司(400)在初始页(601)上点击项“发送信用卡报表”(602a)并相应地确定用于发送信用卡报表的事件已经发生而不是用于发送应帐帐款报表的事件，支付管理服务器(10)使用操作信息管理模块(60)产生用于输入有关信用卡购买的明细的信息。当结束该页时，支付管理服务器通过接口模块(20)发送用于输入有关信用卡购买的明细的完成页给买方公司计算机(1a)(步骤S102)。
然后买方公司计算机(1a)迅速解释用于输入有关信用卡购买的明细的信息并显示它，如图7所示，提供稳定环境，其中买方公司(400)可创建有关信用卡购买的信息。
在这一阶段，支付管理服务器(10)继续与接口模块(20)核对并确定买方公司计算机(1a)是否已经发送有关信用卡购买的信息(步骤S103)。
如果买方公司(400)还没有输入有关信用卡购买的明细从而如果买方公司计算机(1a)还没有发送有关信用卡购买的信息，支付管理服务器(10)进入步骤S104并保持等待状态。
相反，如果买方公司完成有关信用卡购买的明细输入并点击“发送”项(612)并因此确定买方公司计算机(1a)已经发送有关信用卡购买的信息，支付管理服务器(10)确定有关信用卡购买的所述信息是否可接受。例如，确定记录在所述信息中作为应付金额的金额是否在信用保证金额范围内以及记录在所述信息中作为应收公司的卖方公司是否是注册的卖方公司等等(步骤S105)。
此时，如果在所述信息中记录的金额超过信用保证金额的范围或如果记录作为应收公司的卖方公司不是注册的卖方公司，支付管理服务器(10)进入到实施向买方公司计算机(1a)发送一错误信息的步骤(步骤S106)。
在该事件中，支付管理服务器(10)使用操作信息管理模块(60)抽取存储在操作信息D/B(85)中的某些操作信息。然后，使用这些操作信息，支付管理服务器(10)生成如“输入的金额超过你的信用保证金额的范围。请重试”的一条错误信息。生成的错误信息被发送到买方公司计算机(1a)。
相反，如果记录在有关信用卡购买的信息中的金额未超过信用卡的预定信用范围并且如果被记录作为应收公司的卖方公司被确定是一注册卖方公司，有关信用卡购买的所述信息被认为是可接受的。因此，支付管理服务器(10)进行收集和存储有关信用卡购买的所述信息(步骤S107)。
支付管理服务器(10)发送由买方公司计算机(1a)发送的有关信用卡购买的信息给购买价格支付报表管理模块(40)。在接收到有关信用卡购买的信息时，购买价格支出表管理模块(40)立即发送所述信息给D/B管理服务器(70)。这样，有关信用卡购买的信息被收集和存储在购买价格支出表信息D/B(82)中。
另一方面，在所述步骤S101中，如果买方公司在初始页(601)上点击“发送应收帐款报表”项(602b)并且如果因此确定发送应收帐款报表的事件已经发生，支付管理服务器(10)使用操作信息管理模块(60)产生用于输入相关应收帐款的明细的信息。然后支付管理服务器(10)通过接口模块(20)发送用于输入应收帐款的明细的完成信息给买方公司计算机(1a)。
在该事件中，买方公司计算机(1a)迅速解释由支付管理服务器(10)发送的用于输入应收帐款的明细(613)的信息，然后显示该信息，如图8所示，提供稳定环境，其中买方公司(400)可创建有关应收帐款报表的信息。
在该阶段，支付管理服务器(10)继续与接口模块(20)核对并确定买方公司计算机(1a)是否已经发送有关应帐帐款报表的信息(步骤S109)。
如果买方公司(400)还未输入有关应收帐款的明细，从而如果买方公司计算机(1a)还没有发送有关应收帐款报表的信息，支付管理服务器(10)进入步骤S110并保持等待状态。
相反，如果买方公司(400)完成有关应收帐款的明细输入并点击“发送”项(614)并因此确定买方公司计算机(1a)已经发送有关应收帐款的信息，支付管理服务器(10)确定有关应收帐款的所述信息是否可接受。例如，确定记录在所述信息中作为应付金额的的金额是否在应收帐款金额的预定限度内以及记录在所述信息中作为应收公司的卖方公司是否是注册的卖方公司等等(步骤S111)。
此时，如果在所述信息中记录的金额超过应收帐款金额的范围或如果被记录作为应收公司的卖方公司不是注册的卖方公司，支付管理服务器(10)进入到实施向买方公司计算机(1a)发送一错误信息的步骤(步骤S112)。
在该事件中，支付管理服务器(10)使用操作信息管理模块(60)抽取存储在操作信息D/B(85)中的某些操作信息。因此，使用这些操作信息，支付管理服务器(10)生成如“输入的金额超过应收帐款金额的范围。请重试”的一条错误信息。生成的错误信息被发送到买方公司计算机(1a)。
相反，如果记录在有关应收帐款报表的信息中的金额未超过应收帐款金额的预定范围并且如果被记录作为应收公司的卖方公司被确定是一注册卖方公司，有关应收帐款报表的所述信息被认为是可接受的。因此，支付管理服务器(10)进行收集和存储有关应收帐款报表的所述信息(步骤S113)。
支付管理服务器(10)发送由买方公司计算机(1a)发送的有关应收帐款报表的信息给购买价格报表管理模块(40)。在接收到有关应收帐款报表的信息时，购买价格支出表管理模块(40)立即发送所述信息给D/B管理服务器(70)。这样，有关应收帐款报表的信息被收集和存储在购买价格支出表信息D/B(82)中。
现在详细描述购买价格预付的所述步骤(步骤S200)。
首先，如图9所示，通过连续与接口模块(20)核对，支付管理服务器(10)确定是否发生来自卖方公司计算机(2a)的基于应收帐款报表请求贷款的一个事件(步骤S201)。
此时，如果卖方公司(500)在初始页(607)上点击“信用卡购买请求(信用卡销售额支付请求)项(610b)并因此如果确定已经发生来自卖方公司计算机(2a)的信用卡销售额支付的事件而不是基于应收帐款报表请求贷款的事件，支付管理服务器(10)使用操作信息管理模块(60)生成用于输入有关信用卡销售的明细的信息。当完成该页时，支付管理服务器通过接口模块(20)发送用于输入有关信用卡销售的明细的完成页给卖方公司计算机(2a)(步骤S202)。
然后卖方公司计算机(2a)迅速解释用于输入有关信用卡销售(615)的明细的信息并显示它，如图10所示，提供稳定环境，其中卖方公司可创建有关信用卡销售的信息。
在该阶段，支付管理服务器(10)继续与接口模块(20)核对并确定卖方公司计算机(2a)是否发送有关信用卡销售的信息(步骤S203)。
如果卖方公司(500)还未输入有关信用卡销售的明细，从而如果卖方公司计算机(2a)还未发送有关信用卡销售的信息，支付管理服务器(10)进入步骤S204并保持等待状态。
相反，如果卖方公司(500)完成有关信用卡销售的明细输入并点击“发送”项(616)并因此确定卖方公司计算机(2a)已经发送有关信用卡销售的信息，支付管理服务器(10)确定在所述有关信用卡销售的信息中记录的作为应付金额的金额是否未超过预定信用范围余额(步骤S205)。
此时，如果在所述信息中记录的金额超过信用范围余额，支付管理服务器(10)进入实施向卖方公司计算机(2a)发送一条错误消息的步骤(步骤S206)。
在该事件中，支付管理服务器(10)使用操作信息管理模块(60)来抽取存储在操作信息D/B(85)中的某些操作信息。然后，使用这些操作信息，支付管理服务器(10)生成诸如“输入的金额超过信用范围余额，请重试”的一条错误消息。所生成的错误消息被发送给卖方公司计算机(2a)。
相反，如果在有关信用卡销售的信息中记录的金额未超过信用范围余额，支付管理服务器(10)代表买方公司(400)向卖方公司(500)进行“信用卡销售额”的预付。
在该事件中，支付管理服务器(10)指示帐户管理模块(90)完成“信用卡销售额”的预付。在接收到这种指示时，帐户管理模块(90)立即从系统的指定帐户(92)传送特定现金额给卖方公司的指定帐户(93)。因此，向买方公司(400)出售商品或提供服务的卖方公司(500)可在线方便地接收对于“提供的商品或服务”的“信用卡销售额”的预付。
另一方面，在所述步骤S201中，如果卖方公司(500)在初始页(607)上点击“贷款请求”项(610a)并因此如果确定已经发生来自卖方公司计算机(2a)的基于应收帐款报表请求贷款的事件，支付管理服务器(10)使用操作信息管理模块(60)生成用于输入贷款请求的明细的消息。然后支付管理服务器通过接口模块(20)发送用于输入贷款请求的明细的完成页给卖方公司计算机(2a)(步骤S208)。
在这种情况下，卖方公司计算机(2a)迅速解释由支付管理服务器发送的用于输入贷款请求(617)的明细的消息并显示该消息，如图11所示，提供稳定环境，其中卖方公司(500)可迅速处理贷款请求。
在该阶段，支付管理服务器(10)继续与接口模块(20)核对并确定卖方公司计算机(2a)是否发送有关贷款请求的信息(步骤S203)。
如果卖方公司(500)还未输入有关贷款请求的明细，从而如果卖方公司计算机(2a)还未发送有关贷款请求的信息，支付管理服务器(10)进入步骤S210并保持等待状态。
相反，如果卖方公司(500)完成有关贷款请求的明细输入并点击“发送”项并因此确定卖方公司计算机(2a)已经发送有关贷款请求的信息，支付管理服务器(10)确定在所述信息中记录的作为贷款金额的金额是否在贷方结余的预定范围内(步骤S205)。
此时，如果在所述信息中记录的请求贷款金额超过贷方结余的预定范围，支付管理服务器(10)进入实施向卖方公司计算机(2a)发送一条错误消息的步骤(步骤S212)。
在该情况下，支付管理服务器(10)使用操作信息管理模块(60)来抽取存储在操作信息D/B(85)中的某些操作信息。然后，使用这些操作信息，支付管理服务器(10)生成诸如“输入的金额超过贷方结余范围，请重试”的一条错误消息。所生成的错误消息被发送给卖方公司计算机(2a)。
相反，如果在有关贷款请求的信息中记录的请求的贷款金额未超过贷方结余的预定范围，支付管理服务器(10)代表买方公司(400)向卖方公司(500)进行“贷款金额”的预付。
在该事件中，支付管理服务器(10)指示帐户管理模块(90)进行“贷款金额”的预付。在接收到这种指示时，帐户管理模块(90)从系统的指定帐户(92)传送特定现金额给卖方公司的指定帐户(93)。因此，向买方公司(400)出售商品或提供服务的卖方公司(500)对于“提供的商品或服务”可在线方便地接收“贷款销售额”的预付。
另一方面，如图3所示，当完成用于销售额的预付的所述步骤(步骤S200)时，支付管理服务器(10)使用购买价格支出表管理模块(40)来抽取存储在购买价格支出表信息D/B(82)中的购买价格支出表信息。然后支付管理服务器(10)预览所述购买价格支出表信息以确定购买价格支出表是否包含当天到期的任何项(步骤11)。
如果购买价格报表有任何当天到期的项，支付管理服务器(10)与买方公司(400)的指定帐户(91)核对以迅速支付买方公司的相关购买价格(步骤S300)。
首先，如图12所示，支付管理服务器(10)控制帐户管理模块(90)并详细分析发布当天到期的购买价格报表的买方公司(90)的指定帐户(91)(步骤S301)。
然后支付管理服务器(10)进入确定当天到期的项是否服从“预收”，其中根据步骤S207和S213所做的预付的过程被集中(步骤S301a)。
此时，如果与当天到期的项有关的相关卖方公司(500)是未进行“要求销售额预付”的一般卖方公司(500)并因此确定当天到期的项不服从“预收”但服从“一般处理(ordinary process)”，支付管理服务器(10)立即进行实施“一般处理”(步骤S301b)。相关领域的技术人员容易理解用于支付的一般处理。因此，我们省略图12中所示的一般处理的详细说明。
首先，支付管理服务器(10)确定服从一般处理的所述项是否是应收帐款报表内的项。
如果服从一般处理的所述项被确定不属于在应收帐款报表内的项，支付管理服务器(10)认为服从一般处理的所述项是信用卡购买报表内的项。然后，支付管理服务器(10)核对在买方公司的指定帐户(91)中存储的金额是否不少于“信用卡购买金额”。
如果在买方公司的指定帐户(91)中存储的金额低于“信用卡购买金额”，支付管理服务器(10)挂起是违约银行(300)的信用卡债务人的买方公司(400)。同时，代表买方公司，支付管理服务器(10)向卖方公司(500)支付卖方公司(500)有权享有的“信用卡购买金额”。
相反，如果确定在买方公司的指定帐户(91)中存储的金额等于或大于“信用卡购买金额”，支付管理服务器(10)从买方公司的指定帐户(91)发送相应金额给卖方公司(500)的指定帐户(93)。因此，卖方公(500)接收对所提供的商品或服务的销售额。
另一方面，如果服从一般处理的项被确定是“应收帐款报表”内的项，支付管理服务器(10)核对在买方公司指定帐户(91)中存储的金额是否不低于“在应收帐款报表上的金额”。
此时，如果在买方公司指定帐户(91)中存储的金额低于“应收帐款报表上的金额”，支付管理服务器(10)中止此过程流。
相反，如果在买方公司指定帐户(91)中存储的金额等于或大于“应收帐款报表上的金额”，支付管理服务器(10)从买方公司指定帐户(91)发送相应金额给卖方公司(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)发送“挂起违约买方公司(400)”的消息发送给操作模块(60)。在接收到所述消息时，操作模块立即改变在注册信息D/B(86)中存储的有关所述买方公司的注册信息。然后，所述买方公司(400)作为一违约公司被特性化和管理。
相反，如图13b所示，如果信用卡购买预付的金额是50以及在买方公司指定帐户(91)中存储的金额为120，那么确定在买方公司指定帐户(91)中存储的金额大于“信用卡购买预付“，支付管理服务器(10)进行处理由银行(300)所做的”信用卡购买预付金额“的收取(步骤S305)。
在此情况下，支付管理服务器(10)指示帐户管理模块(90)从在买方公司指定帐户(91)中存储的金额收取相应金额。在发生所述指示事件时，帐户管理模块(90)立即从买方公司指定帐户(91)发送相应金额(如120中的50)给系统指定帐户(92)。因此，银行(300)可方便地收取在“信用卡购买预付步骤”中预付的金额。
一旦通过上述步骤完成“信用卡购买预付金额”的收取，支付管理服务器(10)进行从买方公司资金向卖方公司指定帐户(93)的转移减去所述“信用卡购买预付金额”后应付给卖方公司的销售额的差额(步骤S309)。
在该事件中，支付管理服务器(10)指示帐户管理模块(90)从买方公司指定帐户(91)转移所述相应余额。在发生所述指示事件时，帐户管理模块(90)立即从具有剩余资金70的买方公司(400)的指定帐户(91)向卖方公司指定帐户(93)转移“卖方公司(500)销售额的余额”50。因此，卖方公司(500)接收用于它所提供的商品或服务的全部销售额。
相反，在所述步骤S302中，如果“服从预收项”被确定是一“服从基于应收帐款报表的贷款预收项”，支付管理服务器(10)通过预收管理模块(50)抽取贷款预付信息。然后，使用所述贷款预付信息，支付管理服务器(10)确定买方公司指定帐户(91)中存储的金额是否不低于贷款预付金额(步骤S306)。
此时，如图13C所示，如果贷款预付金额是200以及在买方公司指定帐户(91)中存储的金额为100，从而确定买方公司指定帐户(91)中存储的金额小于“贷款预付金额”，支付管理服务器(10)收集在买方公司指定帐户(91)中存储的金额100，与此同时，对于所述金额差100，挂起是违约的银行(300)的债务人的相应卖方公司(500)(步骤S307)。
在此情况下，支付管理服务器(10)向操作模块(60)发送“挂起违约的卖方公司(400)”的消息。在收到所述消息时，操作模块立即改变存储在注册信息D/B(86)中的与所述卖方公司(500)有关的注册信息。然后，所述卖方公司(500)作为违约公司被特性化和管理。
相反，如图13d所示，如果贷款预付金额是50以及在买方公司指定帐户(91)中存储的金额是120，并因此确定在买方公司指定帐户(91)中存储的金额大于“贷款预付金额”，支付管理服务器(10)进行由银行(300)所做的“贷款预付金额”的收取(步骤S308)。
在此情况下，支付管理服务器(10)指示帐户管理模块(90)从买方公司指定帐户(91)中存储的金额收取相应金额。在发生所述指示事件时，帐户管理模块(90)立即将相应金额(如120中的50)从买方公司指定帐户(91)发送到系统指定帐户(92)。因此，银行(300)可方便地收取在“贷款预付步骤”中预付的金额。
一旦通过上述步骤完成“贷款预付金额”的收取，支付管理服务器(10)进行从买方公司资金向卖方公司指定帐户(93)转移在减去所述“贷款预付金额”后应付给卖方公司的销售额的差额。
在该事件中，支付管理服务器(10)指示帐户管理模块(90)从买方公司指定帐户(91)转移所述相应余额。在发生所述指示事件时，帐户管理模块(90)立即从具有剩余资金70的买方公司(400)指定帐户发送“卖方公司(500)销售额余额”，在这种情况下为50给卖方公司指定帐户(93)。因此，卖方公司(500)获得它所提供的商品或服务的全部销售额。
因此，每当在买方公司通信客户机(1)或卖方公司通信客户机(2)发生购买价格支出表管理的事件或请求销售额预付的事件，支付管理服务器(10)协调所述验证模块(30)、购买价格支出表管理模块(40)、预收管理模块(50)、操作信息管理模块(60)以及帐户管理模块(90)以便用于购买价格支出表管理的步骤以及用于销售额预付管理的步骤可系统地被处理。结果，买方公司和卖方公司基于银行在线网络可建立可靠的结算关系。
如上面详细说明，本发明基于卖方公司从买方公司获得并作为担保提供的对应收帐款的权利，通过代表买方公司在线预付购买价格，允许买方公司与卖方公司建立可靠结算关系而不导致特有的财政压力。
本发明也排除买方公司使用传统的帐单支付方法，从而提高在买方公司和卖方公司间形成的结算系统的可靠性。因此，减少对卖方公司意外的损害或损失。
而且，本发明在在线网络上系统地实现在卖方公司和卖方公司间实施的整个结算过程。通过在线网络上这种系统的实施，其目的是卖方公司和买方公司可方便地实施销售额收取过程和购买价格支付过程而不承受被盗窃或丢失的风险。
另外，本发明提高买方公司和卖方公司间结算系统的可靠性，减少由各种公司连锁破产而带来的经济损失。
本发明的优选实施例在上面已经特别地解释和说明。然而，对相关领域的技术人员来说本发明可用各种方式改变并相应地实施是很显然的。
这种改变的实施方式不必被理解为在技术方面脱离本发明并且被认为是包含在本发明的权利要求的范围内。

Claims (16)

1、一种公司间的结算管理系统，包括：
D/B单元，具有包含验证信息的验证信息数据库(“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、如权利要求9所述的公司间的结算管理方法，其中销售额预付的所述步骤包括以下步骤：
确定是否已经发生来自所述卖方公司的通信客户机的基于应收帐款报表的贷款请求的事件；
如果已经发生来自所述卖方公司的通信客户机的基于应收帐款报表的贷款请求的事件，向所述卖方公司通信客户机发送用于与贷款请求有关的明细输入的贷款请求信息输入消息；
确定所述卖方公司通信客户机是否已经发送与所述贷款请求信息输入消息一致的贷款请求信息；
如果所述卖方公司通信客户机已经发送与所述贷款请求信息输入消息一致的贷款请求信息，确定在所述贷款请求信息中记录的请求的贷款金额是否未超过预定贷方结余；以及
如果在所述贷款请求信息中记录的请求的贷款金额未超过预定贷方结余，实施一系列步骤来完成所述请求的贷款金额的预付。
11、如权利要求10所述的公司间的结算管理方法，进一步包括步骤：
如果所述事件不是用于贷款请求，向所述卖方公司通信客户机发送用于与所述卖方公司信用卡销售有关的明细输入的信用卡报表输入消息；
确定所述卖方公司通信客户机是否已经发送与所述信用卡销售报表输入消息一致的信用卡销售信息；
如果所述卖方公司通信客户机已经发送与所述信用卡销售报表输入消息一致的信用卡销售信息，确定在所述信用卡销售信息中记录的信用卡销售金额是否未超过预定贷方结余；以及
如果在所述信用卡销售信息中记录的信用卡销售金额未超过预定贷方结余，实施一系列步骤来完成预付请求的信用卡销售金额。
12、如权利要求10所述的公司间的结算管理方法，在实施用于管理购买价格支出表的所述步骤后，进一步包括步骤：
确定在购买价格支出表中是否存在任何当天到期的项；以及
如果在购买价格支出表中存在任何当天到期的项，核对发布所述购买价格支出表的买方公司的指定帐户并实施用于管理购买价格结算的一系列步骤。
13、如权利要求12所述的公司间的结算管理方法，其中用于管理购买价格结算的所述步骤包括步骤：
确定当天到期的所述项是否服从预收；
如果所述到期项服从预收，确定服从预收的所述项是否是服从基于应收帐款报表的贷款预付的收取的项；
如果所述到期项服从基于应收帐款报表的贷款预付的收取，确定在所述买方公司指定帐户存储的金额是否不低于贷款预付的金额；以及
如果在所述买方公司指定帐户存储的金额不低于贷款预付的金额，从所述买方公司指定帐户存储的金额收取所述贷款预付金额并在扣除所述贷款预付金额后在卖方公司指定帐户中存储购买价格的相应余额。
14、如权利要求13所述的公司间的结算管理方法，进一步包括如果所述买方公司指定帐户金额低于所述贷款预付的金额，宣布所述卖方公司违约的步骤。
15、如权利要求13所述的公司间的结算管理方法，进一步包括步骤：
如果服从预收的所述项不是服从基于应收帐款报表的贷款预付的再收取的项，确定在所述买方公司指定帐户中存储的金额是否不低于信用卡购买价格预付的金额；
如果在所述买方公司指定帐户中存储的所述金额不低于信用卡购买价格预付的金额，从所述买方公司指定帐户存储的金额中收取所述信用卡购买价格预付金额以及在卖方公司指定帐户中扣除所述信用卡购买价格预付金额后存储购买价格的相应余额。
16、如权利要求15所述的公司间的结算管理方法，进一步包括如果所述买方公司指定帐户金额低于所述信用卡购买价格预付的金额，宣布所述买方公司违约的步骤。
CN01808075A 2000-02-15 2001-02-14 用于管理公司间的结算的系统及其方法 Pending CN1423783A (zh)

Applications Claiming Priority (4)

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

Publications (1)

Publication Number Publication Date
CN1423783A true CN1423783A (zh) 2003-06-11

Family

ID=26637104

Family Applications (1)

Application Number Title Priority Date Filing Date
CN01808075A Pending CN1423783A (zh) 2000-02-15 2001-02-14 用于管理公司间的结算的系统及其方法

Country Status (7)

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

Families Citing this family (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2000079452A2 (en) * 1999-06-18 2000-12-28 Echarge Corporation Method and apparatus for ordering goods, services and content over an internetwork using a virtual payment account
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 주식회사 신한은행 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법
US7291497B2 (en) * 2003-09-11 2007-11-06 Theranos, Inc. Medical device for analyte monitoring and drug delivery
KR100684967B1 (ko) * 2004-08-04 2007-02-20 전달용 판매 대금 결제 서비스 제공 방법 및 시스템
US20060264779A1 (en) 2005-05-09 2006-11-23 Kemp Timothy M Fluidic medical devices 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 윤영배 위험회피 보증을 담보로 한 신용카드 매출채권의 매입 및 대금의 선지급을 이용한 금융 서비스 거래 방법
WO2017152037A1 (en) 2016-03-04 2017-09-08 1Usf, Inc. Systems and methods for media codecs and containers

Family Cites Families (14)

* 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
JPH1196262A (ja) * 1997-09-25 1999-04-09 The Asahi Bank Ltd 売掛債権の流動化処理システム
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 손성배 인터넷 전자상점을 통하여 회원업체의 영업, 구매업무를대행하고 부수하여 금융, 물류, 정보를 제공하는통합물류회사 운영.

Also Published As

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

Similar Documents

Publication Publication Date Title
CN1423783A (zh) 用于管理公司间的结算的系统及其方法
US10311431B2 (en) Method and apparatus for staging send transactions
US20180300811A1 (en) Method and system of exchanging and deriving economic benefit from exchanging securities
US8548877B2 (en) Expense tracking, electronic ordering, invoice presentment, and payment system and method
CN1633662A (zh) 点返还方法和设备
CN1359502A (zh) 贸易系统和方法
CN1647088A (zh) 用于通过销售点网络上的数据网络接入点购买商品和服务的系统和方法
CN1711544A (zh) 计息礼品卡机构
CN1439138A (zh) 电子交易系统和方法
CN1229492A (zh) 实现外汇自动化金融交易的方法和系统
WO2002071299A1 (en) Web based system and method for managing business to business online transactions
CN1147653A (zh) 内容销售价格计算系统及其计算方法
JP2005530281A5 (zh)
CN1387657A (zh) 价格设置方法和设备
WO2021063079A1 (zh) 电子平台供应链金融流转方法、系统、终端设备及介质
WO2013100056A1 (ja) 電子マネーサーバ、電子マネー処理方法、電子マネー処理プログラム及び電子マネー処理プログラムが記憶された記憶媒体
JPH08510579A (ja) 危機管理契約の締結と処理に関する方法及び装置
CN1427975A (zh) 用于管理公司间结算的系统及其方法
CN1451134A (zh) 股票买卖系统及股票买卖方法
CN101069208A (zh) 交易会计支付与分类系统和方法
JP2003044771A (ja) 取引システム、支払機関サーバ、取引円滑サーバ及び取引方法
CN1959725A (zh) 一种实现网上保付的系统和方法
EP1313044A1 (en) Account settling system
JP7278451B1 (ja) サービス提供システムおよびサービス提供方法
JP7162791B1 (ja) 情報処理装置、情報処理方法、およびプログラム

Legal Events

Date Code Title Description
C06 Publication
PB01 Publication
C10 Entry into substantive examination
SE01 Entry into force of request for substantive examination
C02 Deemed withdrawal of patent application after publication (patent law 2001)
WD01 Invention patent application deemed withdrawn after publication