CN1427975A - 用于管理公司间结算的系统及其方法 - Google Patents
用于管理公司间结算的系统及其方法 Download PDFInfo
- Publication number
- CN1427975A CN1427975A CN01809192A CN01809192A CN1427975A CN 1427975 A CN1427975 A CN 1427975A CN 01809192 A CN01809192 A CN 01809192A CN 01809192 A CN01809192 A CN 01809192A CN 1427975 A CN1427975 A CN 1427975A
- Authority
- CN
- China
- Prior art keywords
- company
- credit card
- management
- seller
- communication client
- 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
Links
- 238000000034 method Methods 0.000 title abstract description 52
- 238000007726 management method Methods 0.000 claims description 228
- 238000004891 communication Methods 0.000 claims description 67
- 238000013475 authorization Methods 0.000 claims description 20
- 241000239290 Araneae Species 0.000 claims description 14
- 230000008676 import Effects 0.000 claims description 14
- 230000005540 biological transmission Effects 0.000 claims description 11
- 230000000875 corresponding effect Effects 0.000 claims description 10
- 238000012545 processing Methods 0.000 claims description 5
- 239000000284 extract Substances 0.000 claims description 4
- 238000013461 design Methods 0.000 claims description 3
- 238000012546 transfer Methods 0.000 claims description 3
- 230000002596 correlated effect Effects 0.000 claims description 2
- 238000010586 diagram Methods 0.000 description 5
- 238000012384 transportation and delivery Methods 0.000 description 2
- 241000984642 Cura Species 0.000 description 1
- 230000015572 biosynthetic process Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000007796 conventional method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 238000000605 extraction Methods 0.000 description 1
- 238000012011 method of payment Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000003449 preventive effect Effects 0.000 description 1
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
- G06Q30/00—Commerce
- G06Q30/06—Buying, selling or leasing transactions
-
- 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
-
- 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/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
-
- 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/04—Payment circuits
-
- 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
- G06Q30/00—Commerce
- G06Q30/04—Billing or invoicing
-
- 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
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Engineering & Computer Science (AREA)
- Finance (AREA)
- General Physics & Mathematics (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Marketing (AREA)
- Computer Security & Cryptography (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
本发明涉及用于管理公司间结算的系统及其方法。通过在银行在线网络上实现卖方公司和买方公司进行交易的整个结算过程,本发明允许这些卖方或买方公司方便地管理公司间结算而对于销售额的收取或购买价格支付等等不采用信用卡或票据交易。根据本发明,卖方和买方公司间的整个结算过程被在线全部实施。因此,本发明的一个实施例,对卖方和买方公司的利益来说,轻易地减少脱机结算方法如对支付价格的复杂过程或被盗或丢失的麻烦。
Description
技术领域
本发明领域涉及用于管理公司间结算的系统。特别地,本发明涉及允许卖方公司和买方公司通过系统地实施在银行在线网络上在买方公司和卖方公司间实施的全部结算过程、免却在卖方公司和买方公司间实施的脱机结算过程同时发生的不麻烦来更可靠地处理销售额收取过程以及购买价格支付过程的公司间结算管理系统。另外,本发明涉及用于使用所述公司间结算管理系统的管理公司间结算的方法。
背景技术
近来,对应于快速的经济发展,公司间的交易量也相应地以显著的速度增加。与这种公司间增长的交易一致,公司间结算关系也变得越来越复杂。
当公司间关系形成时,出售商品或服务的卖方公司通常实施某些过程来向相关的买方公司要求销售额。按照惯例,大多数买方公司宁愿信用交易或汇票付款而不愿用现金支付,因为与用现金支付相比,如果用信用交易或通过汇票来支付买方公司可更灵活地管理资金。
然而,常规的信用交易或汇票付款包括复杂的过程。因此,使用信用交易或汇票付款作为主要支付方法的买方公司和卖方公司不得不经历较大的麻烦。
另外,因为汇票通常是脱机传送,经常要冒被盗或丢失的风险。因此,使用汇票支付方法的买方公司和卖方公司必须采用另外的预防措施。
如果在单个卖方公司和多个买方公司间的关系中采用所述汇票支付的方法,汇票支付的上述缺点将变得更严重。
发明内容
本发明的目的是在银行在线网络上有系统地实现在卖方公司和买方公司间实施的全部结算过程,并因此允许买方公司和卖方公司方便地实施销售额收取过程和购买价格支付过程而不使用信用交易或汇票付款。
本发明的另一目的是通过在在线网络上在卖方公司和买方公司间实施全部结算过程来减少脱机支付(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)可确定可靠的结算关系。
如上面的详细说明,通过在银行在线网络上实现在卖方公司和买方公司间的全部结算过程,本发明允许相关卖方公司和买方公司方便地实施销售额收取过程和购买价格支付过程而不对这些过程采用信用或票据交易。
根据本发明,卖方公司和买方公司间的全部结算过程可完全在线实施。因此,对利用本发明的卖方公司和买方公司来说,本发明的一个实施例可容易地减小伴随在脱机结算方法如支付购买价格的复杂的过程以及被盗或丢失的风险等等的不方便。
另外,基于本发明的实现,可防止买方公司使用常规的信用或票据交易方法。因此,本发明的一个实施例可增强在相关卖方公司和买方公司间形成的结算关系的信赖。
本发明的优选实施例在上面已经特别说明和描述。然而,对本领域的技术人员来说本发明可用多种方式改变和实现是显而易见的。
这些改变的实现方式不能理解为在技术方面脱离本发明且应当认为包含在本发明附加的权利要求的范围内。
Claims (14)
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所述的公司间结算管理方法,进一步包括收取存入所述买方公司指定帐户中的余款以及如果存入所述买方公司指定帐户中的金额低于所述信用卡销售报表的预付款,宣布所述卖方公司拖欠。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
KR20000012000 | 2000-03-10 | ||
KR12000/2000 | 2000-03-10 | ||
KR11094/2001 | 2001-03-05 | ||
KR10-2001-0011094A KR100435854B1 (ko) | 2000-03-10 | 2001-03-05 | 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN1427975A true CN1427975A (zh) | 2003-07-02 |
Family
ID=26637428
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN01809192A Pending CN1427975A (zh) | 2000-03-10 | 2001-03-09 | 用于管理公司间结算的系统及其方法 |
Country Status (7)
Country | Link |
---|---|
US (1) | US20030041024A1 (zh) |
EP (1) | EP1269372A4 (zh) |
JP (1) | JP2001266025A (zh) |
KR (1) | KR100435854B1 (zh) |
CN (1) | CN1427975A (zh) |
AU (1) | AU4123701A (zh) |
WO (1) | WO2001067331A1 (zh) |
Families Citing this family (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
KR20010099419A (ko) * | 2001-09-26 | 2001-11-09 | 김형태 | 기업간 대금결제 시스템 |
KR100684967B1 (ko) * | 2004-08-04 | 2007-02-20 | 전달용 | 판매 대금 결제 서비스 제공 방법 및 시스템 |
US8117093B2 (en) * | 2006-05-15 | 2012-02-14 | Accenture Global Services Limited | Systems, applications and products in data processing for expedite orders |
US20070276683A1 (en) * | 2006-05-15 | 2007-11-29 | Accenture Global Services Gmbh | Systems, applications and products in data processing for inter-company pricing |
US8041613B2 (en) * | 2006-05-15 | 2011-10-18 | Accenture Global Services Limited | Systems, applications and products in data processing for cross dock |
US20070265874A1 (en) * | 2006-05-15 | 2007-11-15 | Accenture Global Services Gmbh | Systems, applications and products in data processing for partner determination |
US20070276685A1 (en) * | 2006-05-15 | 2007-11-29 | Accenture Global Services Gmbh | Systems, applications and products in data processing for end customer |
KR100968047B1 (ko) | 2010-02-22 | 2010-07-07 | 홍종열 | 어음대체결제수단을 활용한 대금지급 모니터링 및 납품대금 현금성결제 적정심사시스템 |
US20120191624A1 (en) * | 2011-01-21 | 2012-07-26 | Ousley Greg S | System for providing media management, chain of title, and data integrity |
US20130268417A1 (en) * | 2012-04-05 | 2013-10-10 | My Clear Reports, Llc | Method and apparatus for providing services and reporting of sales |
CN106971340A (zh) * | 2017-01-16 | 2017-07-21 | 平安银行股份有限公司 | 交易核算的方法及系统 |
Family Cites Families (16)
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 |
US5453601A (en) * | 1991-11-15 | 1995-09-26 | Citibank, N.A. | Electronic-monetary system |
US5504677A (en) * | 1992-10-15 | 1996-04-02 | Pollin; Robert E. | Automated payment system |
JP3354667B2 (ja) * | 1993-10-22 | 2002-12-09 | 株式会社エヌ・ティ・ティ・データ | 取引処理システムに取引実行依頼を与えるための通信方式 |
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 |
JPH10320470A (ja) * | 1997-05-21 | 1998-12-04 | N T T Data:Kk | 電子取引システム及び方法 |
JPH1196262A (ja) * | 1997-09-25 | 1999-04-09 | The Asahi Bank Ltd | 売掛債権の流動化処理システム |
JPH11175622A (ja) * | 1997-12-10 | 1999-07-02 | Keizo Nishi | 電子決済システム及び電子決済処理装置 |
US6006207A (en) * | 1998-04-17 | 1999-12-21 | Mumick; Ravneet Kaur | System and method for loan prepayment discounts |
JP2000057227A (ja) * | 1998-08-10 | 2000-02-25 | San Denshi Kk | オンライン決済装置 |
-
2001
- 2001-03-05 KR KR10-2001-0011094A patent/KR100435854B1/ko active IP Right Grant
- 2001-03-09 EP EP01912547A patent/EP1269372A4/en not_active Withdrawn
- 2001-03-09 US US10/220,765 patent/US20030041024A1/en not_active Abandoned
- 2001-03-09 AU AU41237/01A patent/AU4123701A/en not_active Abandoned
- 2001-03-09 CN CN01809192A patent/CN1427975A/zh active Pending
- 2001-03-09 WO PCT/KR2001/000369 patent/WO2001067331A1/en not_active Application Discontinuation
- 2001-03-12 JP JP2001069364A patent/JP2001266025A/ja active Pending
Also Published As
Publication number | Publication date |
---|---|
AU4123701A (en) | 2001-09-17 |
US20030041024A1 (en) | 2003-02-27 |
JP2001266025A (ja) | 2001-09-28 |
EP1269372A4 (en) | 2004-07-28 |
KR100435854B1 (ko) | 2004-06-12 |
EP1269372A1 (en) | 2003-01-02 |
WO2001067331A1 (en) | 2001-09-13 |
KR20010088377A (ko) | 2001-09-26 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US9830592B2 (en) | Method and apparatus for staging send transactions | |
CN1201609C (zh) | 通过移动电话实时远程付款和交易的系统和处理方法 | |
CN1423783A (zh) | 用于管理公司间的结算的系统及其方法 | |
CN1930591A (zh) | 多方受益的在线认证服务 | |
CN1229492A (zh) | 实现外汇自动化金融交易的方法和系统 | |
US20130132276A1 (en) | Systems and methods for providing ach transaction notification and facilitating ach transaction disputes | |
CN1539122A (zh) | 远端付费方法及系统 | |
CN1313973A (zh) | 认证付款系统 | |
CN1459759A (zh) | 金融交易的系统和方法 | |
CN1270682A (zh) | 一种通过宽域网络的零售方法 | |
CN1647088A (zh) | 用于通过销售点网络上的数据网络接入点购买商品和服务的系统和方法 | |
CN1806262A (zh) | 支付设备和方法 | |
CN1711544A (zh) | 计息礼品卡机构 | |
CN1698054A (zh) | 资金转移系统及方法 | |
MX2008002637A (es) | Metodo y sistema para remesas de efectivo utilizando una estructura bancaria entre dos paises. | |
CN1454364A (zh) | 处理因特网支付的方法与系统 | |
WO2002071299A1 (en) | Web based system and method for managing business to business online transactions | |
CN1304111A (zh) | 电子结算系统及其电子结算方法 | |
CN1427975A (zh) | 用于管理公司间结算的系统及其方法 | |
WO2013100056A1 (ja) | 電子マネーサーバ、電子マネー処理方法、電子マネー処理プログラム及び電子マネー処理プログラムが記憶された記憶媒体 | |
CN1399755A (zh) | 电子商务系统及电子商务方法 | |
USH2252H1 (en) | Integrated pre-collections system | |
US11023866B2 (en) | Systems and methods for providing ACH transaction notification and facilitating ACH transaction disputes | |
CN1835015A (zh) | 实现外汇自动化金融交易的方法和系统 | |
CN1290892A (zh) | 电子商务系统 |
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 |