[go: up one dir, main page]
More Web Proxy on the site http://driver.im/

KR20010088377A - 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 - Google Patents

기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 Download PDF

Info

Publication number
KR20010088377A
KR20010088377A KR1020010011094A KR20010011094A KR20010088377A KR 20010088377 A KR20010088377 A KR 20010088377A KR 1020010011094 A KR1020010011094 A KR 1020010011094A KR 20010011094 A KR20010011094 A KR 20010011094A KR 20010088377 A KR20010088377 A KR 20010088377A
Authority
KR
South Korea
Prior art keywords
credit card
payment
series
company
purchaser
Prior art date
Application number
KR1020010011094A
Other languages
English (en)
Other versions
KR100435854B1 (ko
Inventor
임동륜
Original Assignee
라응찬
주식회사 신한은행
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 라응찬, 주식회사 신한은행 filed Critical 라응찬
Priority to KR10-2001-0011094A priority Critical patent/KR100435854B1/ko
Priority to CN01809192A priority patent/CN1427975A/zh
Priority to EP01912547A priority patent/EP1269372A4/en
Priority to PCT/KR2001/000369 priority patent/WO2001067331A1/en
Priority to AU41237/01A priority patent/AU4123701A/en
Priority to US10/220,765 priority patent/US20030041024A1/en
Priority to JP2001069364A priority patent/JP2001266025A/ja
Publication of KR20010088377A publication Critical patent/KR20010088377A/ko
Application granted granted Critical
Publication of KR100435854B1 publication Critical patent/KR100435854B1/ko

Links

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/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
    • 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
    • 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

기업간 대금결제 관리 시스템 및 이를 이용한 기업간 대금결제 관리 방법{System and method for managing a payment relation between the enterprises}
본 발명은 기업간 대금결제 관리 시스템에 관한 것으로, 좀더 상세하게는 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 은행 온라인망을 기반으로 체계적으로 구현함으로써, 판매업체 및 구매업체가 자사에 필요한 판매대금 수금과정, 구매대금 지불과정 등을 오프라인(Off-line)상의 불편함 없이, 좀더 편리하게 진행시킬 수 있도록 유도할 수 있는 기업간 대금결제 관리 시스템에 관한것이다. 더욱이, 본 발명은 이러한 기업간 대금결제 관리 시스템을 이용한 기업간 대금결제 관리 방법에 관한 것이다.
최근, 경제 발전의 속도가 가속화되면서, 기업간의 거래 빈도수 또한 뚜렷한 증가추세를 나타내고 있으며, 이러한 기업간 거래의 증가 추세에 맞추어, 기업간 대금결제관계 또한 점차 복잡해지는 양상을 띠고 있다.
이와 같은 기업간 거래관계가 형성될 때, 통상, 일련의 물품, 용역 등을 판매한 판매업체에서는 구매업체를 대상으로, 일련의 대금 청구과정을 진행하는 것이 일반적인 바, 종래의 경우, 대부분의 구매업체에서는 현금(Cash) 보다는 외상거래, 어음(Bill) 등을 대금 결제의 중요한 수단으로 선호하고 있다. 이는 대금 결제의 수단으로 외상거래, 어음 등을 활용하는 경우, 해당 구매업체에서는 전체적인 자금회전을 현금 결제에 비해, 좀더 융통성 있게 진행시킬 수 있는 이점을 손쉽게 획득할 수 있기 때문이다.
그러나, 이와 같은 종래의 외상거래, 어음 등은 그 결제절차가 매우 복잡하기 때문에, 이 외상거래, 어음 등이 주요 결제수단으로 사용되는 경우, "구매업체 및 판매업체" 양측에서는 공히 전체적인 대금결제과정이 불필요하게 복잡해지는 큰 불편함을 감수할 수밖에 없게 된다.
또한, 이러한 실물어음은 오프라인(Off-line)상에서 유통되는 것이 일반적이기 때문에, 항상 도난, 분실 등의 위험성을 내포하고 있으며, 이를 사용하는 "구매업체 및 판매업체"에서는 항상 필요 이상의 주의를 기울여야 하는 불편함을 감수할 수밖에 없게 된다.
만약, 앞의 어음 결제과정이 "하나의 판매업체 대(Versus) 다수의 구매업체"와 같은 관계 하에서, 진행되는 경우, 상술한 어음결제의 폐해는 더욱 심각해질 수밖에 없게 된다.
따라서, 본 발명의 목적은 판매업체 및 구매업체 사이에 진행되는 전체적인 대금결제과정을 은행 온라인망을 기반으로 체계적으로 구현함으로써, 판매업체 및 구매업체가 자사에 필요한 판매대금 수금과정, 구매대금 지불과정 등을 외상거래, 어음사용 등을 활용하지 않고서도, 좀더 손쉽게 진행시킬 수 있도록 유도하는데 있다.
본 발명의 다른 목적은 판매업체 및 구매업체 사이의 전체적인 대금결제과정을 온라인화 함으로써, 예컨대, "복잡한 구매대금 결제절차", "도난, 분실의 위험성" 등과 같은 오프라인 대금결제의 단점을 최소화시키는데 있다.
본 발명의 또 다른 목적은 구매업체에 의한 종래의 외상거래, 어음사용 등을 미리 배제하고, 이를 통해, 판매업체 및 구매업체 사이에 형성되는 대금 결제관계의 신뢰성을 대폭 향상시키는데 있다.
본 발명의 또 다른 목적은 구매업체 및 판매업체 사이의 결제대금 수금/지급 과정을 온라인화 하고, 이를 통해, 전체적인 대금결제 프로세스의 단순화를 유도함으로써, 해당 기업의 경쟁력을 극대화시키는데 있다.
본 발명의 또 다른 목적들은 다음의 상세한 설명과 첨부된 도면으로부터 보다 명확해질 것이다.
도 1은 본 발명이 채용된 기업간 대금결제관계를 개념적으로 도시한 제 1 예시도.
도 2는 본 발명이 채용된 기업간 대금결제관계를 개념적으로 도시한 제 2 예시도.
도 3은 본 발명에 따른 기업간 대금결제 관리 시스템을 개념적으로 도시한 예시도.
도 4는 본 발명의 일 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 5 내지 도 7은 본 발명의 일 실시예에 따른 판매업체측 통신 클라이언트 및 구매업체측 통신 클라이언트의 페이지 게시상태를 개념적으로 도시한 예시도,
도 8은 본 발명의 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 9 및 도 10은 본 발명의 다른 실시예에 따른 판매업체측 통신 클라이언트의 페이지 게시상태를 개념적으로 도시한 예시도.
도 11은 본 발명의 또 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 12는 본 발명의 또 다른 실시예에 따른 판매업체측 통신 클라이언트의 페이지 게시상태를 개념적으로 도시한 예시도.
도 13은 본 발명의 또 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 14 및 도 15는 본 발명의 또 다른 실시예에 따른 구매업체측 통신 클라이언트의 페이지 게시상태를 개념적으로 도시한 예시도.
도 16은 본 발명의 또 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 17a 내지 도 17d는 본 발명의 또 다른 실시예에 따른 구매업체측 지정계좌의 금액 입금상태를 개념적으로 도시한 예시도.
상기와 같은 목적을 달성하기 위하여 본 발명에서는 D/B 블록, D/B 관리 서버, 대금 관리 서버의 조합으로 이루어진 기업간 대금결제 관리 시스템을 개시한다. 이 경우, D/B 블록에는 일련의 인증정보가 저장된 인증정보 데이터 베이스(D/B:Data Base; 이하, "D/B"라 칭함), 일련의 판매대금 수금 명세표 정보가 저장된 판매대금 수금 명세표 정보 D/B, 일련의 신용카드 매출액 선 지급 정보가 저장된 신용카드 매출액 선 지급 정보 D/B, 일련의 판매업체/구매업체 등록정보가 저장된 등록정보 D/B 등이 구비된다.
이때, D/B 블록은 앞서 언급한 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매업체/구매업체 등록정보 등을 상술한 D/B 블록의 필요 영역에 선택적으로 저장하거나, 이 D/B 블록의 필요 영역으로부터 앞의 각 정보들을 선택적으로 추출하는 역할을 수행한다.
여기서, 상술한 대금 관리 서버는 앞의 D/B 관리 서버와 일련의 통신관계를 형성한 상태로, 상술한 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매업체/구매업체 등록정보 등의 저장 및 추출 여부를 결정하는 역할을 수행한다.
이와 함께, 대금 관리 서버는 임의의 판매업체측 통신 클라이언트 및 구매업체측 통신 클라이언트와 은행 온라인망을 통해 인터페이스한 상태에서, 판매업체측 통신 클라이언트 또는 구매업체측 통신 클라이언트로부터 일련의 판매대금 수금관리 이벤트 또는 구매대금 지불관리 이벤트가 발생하는 경우, 앞의 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매기업/구매기업 등록정보를 체계적으로 조합하여, 해당 판매기업 및 구매기업 사이의 대금결제관계를 상술한 은행 온라인망을 기반으로 총괄·관리하는 역할을 수행한다.
이하, 첨부된 도면을 참조하여, 본 발명에 따른 기업간 대금결제 관리 시스템 및 이를 이용한 기업간 대금결제 관리 방법을 좀더 상세히 설명하면 다음과 같다.
도 1에 도시된 바와 같이, 본 발명에 따른 기업간 대금결제 관리 시스템(100)은 판매업체(400) 및 다수의 구매업체들(500) 사이의 대금 결제관계를 신뢰성 있게 관리 할 수 있는 특정 금융기관, 예컨대, 은행(300)의 전산 온라인망에 소속된다.
이때, 도 2에 도시된 바와 같이, 본 발명의 기업간 대금결제 관리 시스템(100)을 보유한 은행(300)측에서는 본 발명에 의한 서비스가 본격적으로 실시되기 이전에, 미리 특정 구매업체(500), 예컨대, 구매업체 A(501), 구매업체 B(502) 등에 한도 1000, 한도 500 등을 갖는 신용카드를 발급하거나, 예컨대, 구매업체 C(503), 구매업체 D(504) 등에 한도 1000, 한도 500 등을 갖는 구매대금 결제전용 대출을 실시함으로써, 본 발명에 의한 기업간 대금결제 관리 방법이 안정적으로 시행될 수 있는 기반환경을 마련한다.
이 경우, 은행(300)측에서는 판매업체(400)측과 별도의 판매업체 약정, 예컨대, "판매대금 결제에 대한 약정", "신용카드 가맹점 특약" 등을 미리 체결함과 아울러, 구매업체(500)측과 별도의 구매업체 약정, 예컨대, "신용카드 발급 약정", "구매대금 결제용 한도 대출 약정" 등을 미리 체결함으로써, 본 발명이 구현될 수 있는 법적인 근거를 마련한다.
이때, 판매업체(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)는 단순히, 각종 데이터들을 저장·출력하는 역할만을 수행하는 것이 아니라, 각종 데이터들을 중복됨 없이 가장 신속한 시간 내에 효율적으로 관리하는 지능적인 역할도 동시에 수행한다.
이때, 도면에 도시된 바와 같이, 상술한 대금 관리 서버(10)는 임의의 판매업체(400)측 통신 클라이언트(1), 다수의 구매업체(500)측 통신 클라이언트들(2)과 예컨대, 인터페이스 모듈(20)을 매개로 인터페이스 한다.
이 경우, 임의의 판매업체(400)측 통신 클라이언트(1), 예컨대, "판매업체측 컴퓨터(1a)", "판매업체측 유/무선 전화기(1b)" 등과, 구매업체(500)측 통신 클라이언트들(2), 예컨대, "구매업체측 컴퓨터(2a)", "구매업체측 유/무선 전화기(2b)" 등은 일련의 은행 온라인망, 예컨대, 유/무선 인터넷망, 자동응답 통신망(Automatic Response System communication network), 부가가치통신망(VAN:Value Added Network), 공중전화망(PSTN:Public Switched Telephone Network) 등을 이용하여 본 발명의 기업간 대금결제 관리 시스템(100)에 접속한다.
이 상태에서, 대금 관리 서버(10)는 인증모듈(30), 판매대금 수금 명세표 관리 모듈(40), 선 지급금 회수 관리 모듈(50), 운영정보 관리 모듈(60) 등을 매개로, D/B 관리 서버(70)를 체계적으로 제어하여, 상술한 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 운영정보, 등록정보 등의 저장 및 추출 여부를 결정하는 역할을 수행한다.
이와 함께, 대금 관리 서버(10)는 상술한 판매업체측 통신 클라이언트(1) 또는 구매업체측 통신 클라이언트(2)로부터 일련의 판매대금 수금관리 이벤트 또는 구매대금 지불관리 이벤트가 발생하는 경우, 앞의 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매기업(400)/구매기업(500) 등록정보를 체계적으로 조합하여, 해당 판매기업(400) 및 구매기업들(400) 사이의 대금결제관계를 상술한 은행 온라인망을 기반으로 총괄적으로 관리하는 역할을 수행한다.
이때, 상술한 인증모듈(30)은 판매업체측 통신 클라이언트(1), 구매업체측 통신 클라이언트(2) 등을 통해 본 발명의 기업간 대금 결제 관리 시스템(100)에 접근하는 임의의 "판매업체(400), 구매업체(500)"의 기 등록여부를 앞의 인증정보 D/B(81)를 활용하여, 인증하는 역할을 전담하며, 판매대금 수금 명세표 관리 모듈(40)은 판매업체측 통신 클라이언트(1)로부터 전송되는 판매대금 수금 명세표를 앞의 판매대금 수금 명세표 정보 D/B(82)를 활용하여 관리하는 역할을 전담한다.
또한, 선 지급금 회수 관리 모듈(50)은 시스템(100)측이 판매업체측에 선 지급한 선 지급금, 예컨대, 신용카드 매출액 선 지급금을 앞의 신용카드 매출액 선 지급 정보 D/B(83)를 활용하여 관리하는 역할을 전담하며, 운영정보 관리 모듈(60)은 대금 관리 서버(10)의 세부 운영사항을 앞의 운영정보 D/B(85), 등록정보D/B(86) 등을 활용하여 관리하는 역할을 전담한다.
이때, 도면에 도시된 바와 같이, 계좌 관리 모듈(90)은 앞의 인증모듈(30), 판매대금 수금 명세표 관리 모듈(40), 선 지급금 회수 관리 모듈(50), 운영정보 관리 모듈(60) 등과 유사하게 대금 관리 서버(10)와 긴밀한 통신연결 관계를 형성하는 바, 이 상태에서, 계좌 관리 모듈(90)은 시스템(100)측에 지정된 시스템측 지정계좌(92), 판매업체(400)측에 지정된 판매업체측 지정계좌(91), 구매업체(500)측에 지정된 구매업체측 지정계좌(93) 등을 총괄적으로 관리하는 역할을 전담한다.
이하, 상술한 구성을 갖는 본 발명의 기업간 대금결제 관리 시스템(100)을 이용한 기업간 대금결제 관리 방법을 상세히 설명한다.
먼저, 소정의 상품, 용역 등을 판매한 판매업체(400) 또는 이 판매업체(400)로부터 상품, 용역 등을 구매한 다수의 구매업체들(500)은 상술한 판매업체측 통신 클라이언트(1), 예컨대, 판매업체측 컴퓨터(1a)와, 구매업체측 통신 클라이언트(2), 예컨대, 구매업체측 컴퓨터(2a)를 이용하여, 본 발명의 기업간 대금결제 관리 시스템(100)에 접속한다. 물론, 해당 판매업체(400), 구매업체(500) 등은 판매업체측 컴퓨터(1a), 구매업체측 컴퓨터(2a) 이외의 다른 통신 클라이언트, 예컨대, 판매업체측 유/무선 통신기(1b), 구매업체측 유/무선 통신기(2b) 등을 선택하여, 본 발명의 기업간 대금결제 관리 시스템(100)에 접속하여도 무방하다.
만약, 해당 판매업체(400), 구매업체(500) 등이 판매업체측 유/무선 통신기(1b), 구매업체측 유/무선 통신기(2b) 등을 선택하여, 일련의 접속과정을 진행하는 경우, 통신 중계국(200)은 이 판매업체측 유/무선 통신기(1b), 구매업체측유/무선 통신기(2b) 등으로부터 출력되는 데이터를 시스템측(100)의 인터페이스 모듈(20)로 전달하거나, 시스템(100)측의 인터페이스 모듈(20)로부터 출력되는 데이터를 판매업체측 유/무선 통신기(1b), 구매업체측 유/무선 통신기(2b) 등으로 전달하는 역할을 수행한다.
이러한 기반환경이 갖추어진 상태에서, 도 4에 도시된 바와 같이, 대금 관리 서버(10)는 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a) 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생하였는가의 여부를 판단한다(단계 S1).
이때, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a)로부터 상술한 시스템 접속 이벤트가 발생하지 않은 것으로 판단되는 경우, 대금 관리 서버(10)는 플로우를 후술하는 단계 S15로 진행한다.
그러나, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a) 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생한 경우, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 운영정보 D/B(80)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 일련의 인증 요구 메시지를 생성하고, 생성이 완료된 인증 요구 메시지를 시스템 접속 이벤트를 발생시킨 해당 컴퓨터로 전송한다(단계 S2).
만약, 구매업체측 컴퓨터(1a)로부터 시스템 접속 이벤트가 발생한 경우, 이 인증요구 메시지는 구매업체측 컴퓨터(1a)로 전송되며, 반대의 경우로, 판매업체측 컴퓨터(2a)로부터 시스템 접속 이벤트가 발생한 경우, 이 인증요구 메시지는 판매업체측 컴퓨터(2a)로 전송된다.
이 경우, 해당 컴퓨터, 예컨대, 구매업체측 컴퓨터(1a)는 대금 관리 서버(10)로부터 전송된 인증 요구 메시지를 해석하여, 이를 디스플레이 시킴으로써, 해당 판매업체(400)가 일련의 인증과정을 신속히 수행 받을 수 있도록 하며, 다른 예로, 판매업체측 컴퓨터(2a)는 대금 관리 서버(10)로부터 전송된 인증 요구 메시지를 해석하여, 이를 디스플레이 시킴으로써, 해당 구매업체(500)가 일련의 인증과정을 신속히 수행 받을 수 있도록 한다.
이 상태에서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(1b)로부터 일련의 인증정보가 전송되었는가의 여부를 판단한다(단계 S3).
이때, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a)로부터 별도의 인증정보가 전송되지 않은 것으로 판단되면, 대금 관리 서버(10)는 구매업체(1a) 또는 판매업체(2a)가 아직, 일련의 인증정보 입력과정을 완료하지 못한 것으로 판정하고, 플로우를 단계 S4로 진행하여, 일련의 대기상태를 유지한다.
그러나, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a)로부터 일련의 인증정보가 전송된 것으로 판단되면, 대금 관리 서버(10)는 인증모듈(30)을 신속히 활용함으로써, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a)를 통해 시스템(100)에 접속중인 관리업체, 예컨대, 판매업체(400) 또는 구매업체(500)가 기 등록된 관리업체인가의 여부를 판단한다(단계 S5).
이때, 시스템(100)에 접속 중인 관리업체가 기 등록된 관리업체가 아닌 것으로 판단되는 경우, 대금 관리 서버(10)는 예컨대, "귀사는 등록된 고객이 아니오니, 먼저, 등록해 주십시오" 등과 같은 내용의 등록 요구 메시지를 생성하고, 생성이 완료된 등록 요구 메시지를 해당 관리업체측 컴퓨터로 전송하는 과정을 진행한다(단계 S6).
그러나, 시스템(10)에 접속 중인 관리업체가 등록된 관리업체로 판단되는 경우, 대금 관리 서버(10)는 일련의 메인 페이지를 생성하고, 생성이 완료된 메인 페이지를 해당 관리업체측 컴퓨터, 예컨대, 판매업체측 컴퓨터(1a) 또는 구매업체측 컴퓨터(2a)로 전송한다(단계 S7).
이 경우, 해당 관리업체측 컴퓨터는 시스템(100)측으로부터 전송되는 메인 페이지(601)를 신속히 해석하여, 이를 도 5에 도시된 바와 같이, 디스플레이 시킴으로써, 판매업체(400) 또는 구매업체(500)에 의한 일련의 기업간 대금결제 과정이 원활하게 진행될 수 있는 기반환경을 제공한다.
한편, 앞서 언급한 과정을 통해, 관리업체측 컴퓨터, 예컨대, 판매업체측 컴퓨터(1a) 또는 구매업체측 컴퓨터(2a)에 일련의 메인 페이지(601)가 게시된 상태에서, 대금 관리 서버(10)는 해당 관리업체측 컴퓨터로부터 일련의 대금결제 이용 이벤트가 발생하였는가의 여부를 판단한다(단계 S8).
이때, 해당 관리업체측 컴퓨터로부터 별도의 대금결제 이용 이벤트가 발생하지 않은 것으로 판단되면, 대금 관리 서버는 플로우를 후술하는 단계 S15로 진행한다.
그러나, 판매업체(400) 또는 구매업체(500)측에서, 예컨대, 메인 페이지(601)의 "대금결제 관리 시스템 항목(602)"을 클릭하여, 판매업체측컴퓨터(1a) 또는 구매업체측 컴퓨터(2a)로부터 일련의 대금결제 이용 이벤트가 발생한 것으로 판단되는 경우, 대금 관리 서버(10)는 예컨대, 운영 정보 관리 모듈(60) 등을 활용하여, 등록정보 D/B(86)에 저장된 해당 관리업체의 등록정보를 수집한 후, 해당 관리업체가 판매업체(400)인가 또는 구매업체(500)인가의 여부를 판단한다(단계 S9,S10).
이때, 해당 관리업체가 판매업체(400)로 판단되는 경우, 대금 관리 서버(10)는 해당 판매업체(400)의 등록정보가 반영된 일련의 판매업체용 초기 페이지를 생성하고, 생성이 완료된 판매업체용 초기 페이지를 판매업체측 컴퓨터(1a)로 전송하는 과정을 진행한다(단게 S12).
이 경우, 판매업체측 컴퓨터(1a)는 시스템(100)측으로부터 전송되는 해당 판매업체용 초기 페이지(603)를 신속히 해석하여, 이를 도 6에 도시된 바와 같이 디스플레이 시킴으로써, 판매업체(400)에 의한 일련의 판매대금 수금과정이 원활하게 진행될 수 있는 기반환경을 제공한다.
여기서, 도면에 도시된 바와 같이, 판매업체용 초기 페이지(603)에는 예컨대, 매출채권 명세표 전송 항목(604), 신용카드 매출표 전송 항목(605), 신용카드 매출표 선 지급 신청 항목(606), 전송내역 조회 항목(608), 수금 내역 조회 항목(609), 처리결과 조회 항목(610) 등이 구비되며, 판매업체(400)에서는 앞의 각 항목들을 선택적으로 클릭함으로써, 해당 항목들을 실시간으로 확인/설정할 수 있다. 물론, 이러한 각 항목들은 상황에 따라 다양한 변형을 이룰 수 있다.
이때, 후술하는 신용카드 매출표 전송 후, 일련의 신용카드 매출액 선 지급과정을 통해 자금을 운용하고자 하는 판매업체(400)에서는 예컨대, 판매업체용 초기 페이지(603)의 신용카드 매출표 선 지급 신청 항목(606)을 선택하여, 일련의 신용카드 매출표 선 지급 신청 정보를 생성할 수 있다.
이러한 신용카드 매출표 선 지급 신청 정보는 일련의 물품, 용역 등을 판매한 판매기업(400)이 예컨대, "기업전용 신용카드를 이용하여, 해당 물품, 용역 등의 구매대금을 결제한 구매기업(500)"과 연계된 은행(300)을 대상으로 하여, "신용카드 결제대금의 선 지급을 요청하는 정보"를 의미하며, 금융기관, 예컨대, 은행(300)은 이러한 "신용카드 매출표 선 지급 정보"를 토대로, 일련의 "신용카드 결제대금"을 구매업체(500)를 대신하여, 판매업체(400)에게 미리 선 지급하게 되고, 결국, 판매업체(400)에서는 자사가 판매한 물품, 용역 등의 판매대금을 미리 수금할 수 있게 된다.
한편, 상술한 과정을 통해, 판매업체측 컴퓨터(1a)에 일련의 판매업체용 초기 페이지(603)가 게시된 상태에서, 대금 관리 서버(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에서, 해당 관리업체가 판매업체(400)가 아닌, 구매업체(500)로 판단되는 경우, 대금 관리 서버(10)는 해당 구매업체(500)의 등록정보가 반영된 일련의 구매업체용 초기 페이지를 생성하고, 생성이 완료된 구매업체용 초기 페이지를 구매업체측 컴퓨터(2a)로 전송하는 과정을 진행한다(단계 S11).
이 경우, 구매업체측 컴퓨터(2a)는 시스템(100)측으로부터 전송되는 해당 구매업체용 초기 페이지(611)를 신속히 해석하여, 이를 도 7에 도시된 바와 같이, 디스플레이 시킴으로써, 구매업체(500)에 의한 일련의 구매대금 관리 과정이 원활하게 진행될 수 있는 기반환경을 제공한다.
여기서, 도면에 도시된 바와 같이, 구매업체용 초기 페이지(611)에는 예컨대, 구매내역 조회 항목(612), 신용카드 구매대금 선 입금 항목(613) 등이 구비되는 바, 구매업체(500)에서는 앞의 각 항목들을 선택적으로 클릭함으로써, 해당 항목을 실시간으로 확인/설정할 수 있다. 물론, 이러한 각 항목들은 앞의 판매업체용 초기 페이지(603)의 경우와 유사하게, 상황에 따라 다양한 변형을 이룰 수 있다.
이때, 구매업체(500)에서는 예컨대, 구매업체용 초기 페이지(611)의 신용카드 구매대금 선 입금 항목(613)을 선택하여, 일련의 신용카드 구매대금 선 입금 정보를 생성할 수 있는 바, 이러한 신용카드 구매대금 선 입금 정보는 신용카드를 이용하여, 판매업체(400)로부터 일련의 물품, 용역 등을 구매한 구매기업(400)이 "자사의 신용카드 구매대금을 결제일 이전에 미리 입금하는 내용을 기록한 정보"를 의미하며, 본 발명의 시스템(100)은 이러한 "신용카드 구매대금 선 입금 정보"를 토대로, 일련의 "신용카드 결제대금"을 구매업체(500)가 지정한 특정 계좌로부터 이체시킴으로써, 구매업체(500)가 자사의 의사에 따라, 결제일 이전 시점에서도, 일련의 신용카드 결제대금을 안정적으로 선 결제할 수 있도록 유도한다.
상술한 과정을 통해, 구매업체측 컴퓨터(2a)에 일련의 구매업체용 초기 페이지(611)가 게시된 상태에서, 대금 관리 서버(10)는 해당 구매업체측 컴퓨터(2a)로부터 일련의 구매대금 관리 이벤트가 발생하였는가의 여부를 판단한다(단계 S16).
이때, 구매업체측 컴퓨터(2a)로부터 별도의 구매대금 관리 이벤트가 발생하지 않은 것으로 판단되면, 대금 관리 서버(10)는 플로우를 후술하는 단계 S17로 진행한다.
그러나, 구매업체(500)측에서, 예컨대, 구매업체용 초기 페이지(611)의 구매내역 조회 항목(612), 신용카드 구매대금 선 입금 항목(613) 등을 클릭하여, 구매업체측 컴퓨터(2a)로부터 일련의 구매대금 관리 이벤트가 발생한 것으로 판단되는 경우, 대금 관리 서버(10)는 해당 구매업체측 컴퓨터(2a)로부터 전송되는 구매대금 관리 정보를 참조하여, 일련의 구매대금 관리 과정을 신속하게 진행하게 된다(단계 S300).
이하, 앞서 언급한 판매대금 수금 명세표 관리 과정(단계 S100), 신용카드 매출액 선 지급 과정(단계 S200), 구매대금 관리 과정(단계 S300) 등을 상세히 설명한다.
먼저, 상술한 판매대금 수금 명세표 관리 과정(단계 S100)을 상세히 설명한다.
도 8에 도시된 바와 같이, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 판매업체측 컴퓨터(1a)로부터 일련의 신용카드 매출표 전송 이벤트가 발생하였는가의 여부를 판단한다(단계 S101).
이때, 판매업체(400)측에서 초기 페이지(603)의 매출채권 명세표 전송항목(604)을 클릭하여, 판매업체측 컴퓨터(1a)로부터 신용카드 매출표 전송 이벤트 대신에, 일련의 매출채권 명세표 전송 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 매출채권 내역 입력 페이지를 생성하고, 생성이 완료된 매출채권 내역 입력 페이지를 인터페이스 모듈(20)을 매개로 하여, 판매업체측 컴퓨터(1a)로 전송한다(단계 S102).
이 경우, 판매업체측 컴퓨터(1a)는 대금 관리 서버(10)로부터 전송되는 매출채권 내역 입력 페이지(614)를 신속히 해석하여, 이를 도 9에 도시된 바와 같이, 디스플레이 시킴으로써, 판매업체(400)가 일련의 매출채권 명세표 정보를 생성할 수 있는 안정적인 기반환경을 제공받도록 한다.
이 상태에서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 판매업체측 컴퓨터(1a)로부터 일련의 매출채권 명세표 정보가 전송되었는가의 여부를 판단한다(단계 S103).
이때, 판매업체(400)측에서, 아직, 매출채권 명세표 내역 입력과정을 완료하지 않아, 판매업체측 컴퓨터(1a)로부터 일련의 매출채권 명세표 정보가 전송되지 않은 것으로 판단되면, 대금 관리 서버(10)는 플로우를 단계 S104로 진행하여, 일련의 대기 상태를 유지한다.
그러나, 판매업체(400)측에서, 매출채권 명세표 내역 입력과정을 모두 완료하고, 예컨대, 전송 항목(617)을 클릭하여, 판매업체측 컴퓨터(1a)로부터 일련의 매출채권 명세표 정보가 전송된 것으로 판단되면, 대금 관리 서버(10)는 이 매출채권 명세표 정보의 요건만족 여부, 예컨대, 매출채권 명세표 정보에 기록된 매출채권 수금대상 금액이 구매업체(500)별 대출 한도 금액 이내인가, 구매업체측의 지정계좌(93)에 인출가능 잔액이 있는가, 매출채권 명세표 정보에 기록된 수금대상 구매업체(500)가 기 등록된 구매업체(500)인가 등의 여부를 판단한다(단계 S105).
이때, 매출채권 명세표 정보에 기록된 매출채권 수금대상 금액이 구매업체(500)별 대출 한도 금액을 초과하거나, 구매업체측의 지정계좌(93)에 인출가능 잔액이 없거나, 매출채권 명세표 정보에 기록된 수금대상 구매업체(500)가 기 등록된 구매업체(500)가 아닌 것으로 판단되는 경우, 대금 관리 서버(10)는 일련의 오류 메시지를 판매업체측 컴퓨터(1a)로 전송하는 과정을 진행한다(단계 S106).
이 경우, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 운영정보 D/B(84)에 저장되어 있던 일련의 운영정보를 추출한 후, 이 운영정보를 활용하여, 예컨대, "선택하신 금액이 구매업체의 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 판매업체측 컴퓨터(1a)로 전송한다.
그러나, 매출채권 명세표 정보에 기록된 매출채권 수금대상 금액이 구매업체(500)별 대출 한도 금액 이내의 금액이고, 구매업체측의 지정계좌(93)에 인출가능 잔액이 충분히 있으며, 매출채권 명세표 정보에 기록된 수금대상 구매업체(500)가 기 등록된 구매업체(500)로 판단되어, 해당 매출채권 명세표 정보의 요건이 모두 만족되는 것으로 판단되는 경우, 대금 관리 서버(10)는 해당 매출채권 명세표 정보를 수집·저장하는 과정 및 매출채권 명세표에 기록된 수금대상 매출채권액을 구매업체측 지정계좌(93)로부터 판매업체측 지정계좌로 계좌이체 하는 과정 등을 진행한다(단계 S107, S107a).
이 경우, 먼저, 대금 관리 서버(10)는 판매업체측 컴퓨터(1a)로부터 전송된 매출채권 명세표 정보를 판매대금 수금 명세표 관리 모듈(40)로 전달하게 되며, 판매대금 수금 명세표 관리 모듈(40)은 이러한 매출채권 명세표 정보가 전달되는 즉시, 이를 D/B 관리 서버(70)로 전달함으로써, 해당 매출채권 명세표 정보가 예컨대, 판매대금 수금 명세표 정보 D/B(82)에 안정적으로 수집·저장될 수 있도록 한다.
이어서, 대금 관리 서버(10)는 계좌 관리 모듈(90)을 제어하여, 구매업체측의 지정계좌(93)에 기 입금되어 있는 "구매대금 결제전용 대출금"을 판매업체측의 지정계좌(91)로 이체시킴으로써, 판매업체(400) 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있도록 유도하게 된다.
한편, 앞서 언급한 단계 S101에서, 판매업체(400)가 초기 페이지(603)의 신용카드 매출표 전송 항목(605)을 클릭하여, 판매업체측 컴퓨터(1a)로부터 일련의 신용카드 매출표 전송 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 신용카드 매출표 내역 입력 페이지를 생성하고, 생성이 완료된 신용카드 매출표 내역 입력 페이지를 인터페이스 모듈(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(84)에 저장되어 있던 일련의 운영정보를 추출한 후, 이 운영정보를 활용하여, 예컨대, "선택하신 금액이 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 판매업체측 컴퓨터(1a)로 전송한다.
그러나, 신용카드 매출표 정보에 기록된 신용카드 수금대상 금액이 판매업체별 한도, 구매업체별 부채한도 이내의 금액이고, 신용카드 매출표 정보에 기록된 수금대상 구매업체(500)가 기 등록된 구매업체(500)로 판단되어, 해당 신용카드 매출표 정보의 요건이 모두 만족되는 것으로 판단되는 경우, 대금 관리 서버(10)는 해당 신용카드 매출표 정보를 수집·저장하는 과정을 진행한다(단계 S107).
이 경우, 대금 관리 서버(10)는 판매업체측 컴퓨터(1a)로부터 전송된 신용카드 매출표 정보를 판매대금 수금 명세표 관리 모듈(40)로 전달하게 되며, 판매대금 수금 명세표 관리 모듈(40)은 이러한 신용카드 매출표 정보가 전달되는 즉시, 이를 D/B 관리 서버(70)로 전달함으로써, 해당 신용카드 매출표 정보가 예컨대, 판매대금 수금 명세표 정보 D/B(82)에 안정적으로 수집·저장될 수 있도록 한다.
다음으로, 앞서 언급한 신용카드 매출액 선 지급 과정(단계 S200)을 상세히 설명한다.
앞의 단계 S14를 통해, "판매업체(400)측에 의한 일련의 신용카드 매출액 선 지급 신청 이벤트"가 발생한 것으로 판단되면, 도 11에 도시된 바와 같이, 대금 관리 서버(10)는 먼저, 운영정보 관리 모듈(60)을 활용하여, 일련의 신용카드 매출액 선 지급 신청내역 입력 페이지를 생성한 후, 생성이 완료된 신용카드 매출액 선 지급 신청내역 입력 페이지를 인터페이스 모듈(20)을 매개로 하여, 판매업체측 컴퓨터(1a)로 전송한다(단계 S201).
이 경우, 판매업체측 컴퓨터(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)에 저장되어 있던 일련의 운영정보를 추출한 후, 이 운영정보를 활용하여, 예컨대, "신청하신 금액이 채권 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 판매업체측 컴퓨터(1a)로 전송한다.
그러나, 신용카드 매출액 선 지급 신청 정보에 기록된 신용카드 매출액 선지급 신청 금액이 기 지정된 채권 잔액 한도 이내의 금액인 경우, 대금 관리 서버(10)는 일련의 "신용카드 매출 신청액"을 구매업체(500)를 대신하여, 판매업체(400)측에게 미리 선 지급하는 과정을 진행한다(단계 S207).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 "신용카드 매출 신청액"의 선 지급을 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 일정액의 현금을 예컨대, 시스템측 지정계좌(92)로부터 판매업체측 지정계좌(93)로 입금시키게 되고, 결국, 구매업체(500)를 대상으로 일련의 물품, 용역 등을 판매한 판매업체(400)는 "자사에서 판매한 물품, 용역" 등에 상응하는 일련의 "신용카드 매출 신청액"을 온라인 상에서 손쉽게 선 입금 받을 수 있게 된다.
다음으로, 상술한 구매대금 관리 과정(단계 S300)을 상세히 설명한다.
먼저, 도 13에 도시된 바와 같이, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 컴퓨터(2a)로부터 일련의 구매내역 조회 이벤트가 발생하였는가의 여부를 판단한다(단계 S401).
이때, 구매업체측 컴퓨터(2a)로부터 별도의 구매내역 조회 이벤트가 발생하지 않은 것으로 판단되면, 대금 관리 서버는 플로우를 후술하는 단계 S403으로 진행한다.
그러나, 구매업체(500)측에서 구매업체용 초기 페이지(611)의 구매내역 조회 항목(612)을 클릭하여, 구매업체측 컴퓨터(2a)로부터 일련의 구매내역 조회 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 구매내역 리스트를 생성하고, 생성이 완료된 구매내역 리스트를 인터페이스 모듈(20)을 매개로 하여, 구매업체측 컴퓨터(2a)로 전송한다(단계 S402).
이 경우, 구매업체측 컴퓨터(2a)는 대금 관리 서버(10)로부터 전송되는 구매내역 리스트(622)를 신속히 해석하여, 이를 도 14에 도시된 바와 같이, 디스플레이 시킴으로써, 구매업체(500)가 예컨대, "구매물품, 결제기일, 결제금액" 등과 같은 자사의 구매내역을 좀더 손쉽게 확인할 수 있는 안정적인 기반환경을 제공받을 수 있도록 한다.
계속해서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 컴퓨터(2a)로부터 일련의 신용카드 구매대금 선 입금 이벤트가 발생하였는가의 여부를 판단한다(단계 S403).
이때, 구매업체측 컴퓨터(2a)로부터 별도의 신용카드 구매대금 선 입금 이벤트가 발생하지 않은 것으로 판단되면, 대금 관리 서버는 플로우를 종료한다.
그러나, 구매업체(500)측에서, 구매업체용 초기 페이지(611)의 신용카드 구매대금 선 입금 항목(613)을 클릭하여, 구매업체측 컴퓨터(2a)로부터 일련의 신용카드 구매대금 선 입급 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 신용카드 구매대금 선 입금 내역 입력 페이지를 생성한 후, 생성이 완료된 신용카드 구매대금 선 입금 내역 입력 페이지를 인터페이스 모듈(20)을 매개로 하여, 구매업체측 컴퓨터(2a)로 전송한다(단계 S404).
이 경우, 구매업체측 컴퓨터(2a)는 대금 관리 서버(10)로부터 전송되는 신용카드 구매대금 선 입금 내역 입력 페이지(623)를 신속히 해석하여, 이를 도 15에도시된 바와 같이, 디스플레이 시킴으로써, 구매업체(500)가 일련의 신용카드 구매대금을 미리 입금할 수 있는 안정적인 기반환경을 제공받을 수 있도록 한다.
이 상태에서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 컴퓨터(2a)로부터 일련의 신용카드 구매대금 선 입금 정보가 전송되었는가의 여부를 판단한다(단계 S405).
이때, 구매업체(500)측에서, 아직, 신용카드 구매대금 선 입금 내역 입력과정을 완료하지 않아, 구매업체측 컴퓨터(2a)로부터 일련의 신용카드 구매대금 선 입금 정보가 전송되지 않은 것으로 판단되면, 대금 관리 서버(10)는 플로우를 단계 S406으로 진행하여, 일련의 대기 상태를 유지한다.
그러나, 구매업체(500)측에서, 신용카드 구매대금 선 입금 내역 입력과정을 모두 완료하고, 예컨대, 전송 항목(624)을 클릭하여, 구매업체측 컴퓨터로부터 일련의 신용카드 구매대금 선 입금 정보가 전송된 것으로 판단되면, 대금 관리 서버(10)는 그 즉시, 앞의 신용카드 구매대금 선 입금 정보를 토대로, 해당 신용카드 구매대금을 선 입금 처리하는 과정을 진행한다(단계 S407).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 "신용카드 구매대금"의 선 입금을 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 일정액의 현금을 예컨대, 구매업체(500)가 지정한 특정 계좌로부터 판매업체측 지정계좌(91)로 이체시키게 되고, 결국, 판매업체(400)로부터 일련의 물품, 용역 등을 구매한 구매업체(500)에서는 결제일 이전 시점에서도, 자사의 의사에 따라, 신용카드 선 결제 과정을 안정적으로 진행시킬 수 있는 이점을 획득할 수 있게된다.
한편, 상술한 도 4에 도시된 바와 같이, 앞의 신용카드 매출액 선 지급 과정(단계 S200)이 마무리되면, 대금 관리 서버(10)는 판매대금 수금 명세표 관리 모듈(40)을 활용하여, 판매대금 수금 명세표 정보 D/B(82)에 저장된 판매대금 수금 명세표 정보, 예컨대, 신용카드 매출표 정보를 추출하고, 이 신용카드 매출표 정보를 체크하여, 해당 신용카드 매출표 중, 당일 결제일인 신용카드 매출 건이 있는가의 여부를 판단한다(단계 S15).
이때, 판매대금 수금 명세표 정보 D/B(82)에 저장되어 있는 신용카드 매출표 중, 당일 결제일인 신용카드 매출 건이 없는 경우, 대금 관리 서버(10)는 플로우를 종료한다.
그러나, 판매대금 수금 명세표 정보 D/B(82)에 저장되어 있는 신용카드 매출표 중, 당일 결제일인 신용카드 매출 건이 있는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(93)를 체크하여, 당일 결제일인 신용카드 매출 건에 관계된 신용카드 구매대금 결제과정을 신속히 진행한다(단계 S500).
먼저, 도 16에 도시된 바와 같이, 대금 관리 서버(10)는 계좌 관리 모듈(90)을 제어하여, 당일 결제일인 신용카드 매출 건에 관계된 구매업체(500)측의 지정계좌(91)를 면밀히 체크한다(단계 S501).
계속해서, 대금 관리 서버(10)는 당일 결제일인 신용카드 매출 건이 앞의 단계 S207의 진행에 의해 발생된 "선 지급 건"을 회수하는 "선 지급 회수 대상 건"인가의 여부를 판단한다(단계 S502).
이때, 당일 결제일인 신용카드 매출 건에 관계된 판매업체(400)가 앞의 경우와 같은 일련의 "신용카드 매출액 선 지급 과정"을 진행 받지 않은 일반 판매업체(400)이어서, 당일 결제일인 신용카드 매출 건이 앞의 경우와 같은 "선 지급 회수 대상 건"이 아닌 "일반 회수 대상 건"인 것으로 판단되는 경우, 대금 관리 서버(10)는 일련의 "일반 대상 건 처리과정"을 신속히 진행한다(단계 S520).
먼저, 대금 관리 서버(10)는 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 "구매업체(500)측의 신용카드 구매대금" 이상인가의 여부를 판단한다(단계 S521).
이때, 도 17a에 도시된 바와 같이, 구매업체(500)측의 신용카드 구매대금이 1000인데 반해, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 500 이어서, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 구매업체(500)측의 신용카드 구매대금 미만인 것으로 판단되는 경우, 대금 관리 서버(10)는 판매업체(400)측이 수금하여야 할 구매업체(500)측의 신용카드 구매대금 1000을 구매업체(500)측 대신 판매업체(400)측에 대납해 준다(단계 S522).
이러한 대납과정이 완료되는 즉시, 대금 관리 서버(10)는 구매업체측의 지정계좌(93)에 기 입금되어 있던 500을 회수함과 아울러, 은행(300)측과 신용카드 차주 관계에 있는 해당 구매업체(500)를 그 차액, 즉, 500만큼 연체 처리하는 과정을 진행한다(단계 S523).
이 경우, 대금 관리 서버(10)는 운영 모듈(60)로 "해당 구매업체(500)를 연체 처리하라"는 메시지를 전달하게 되며, 운영 모듈(30)은 이러한 메시지가 전달되는 즉시, 등록정보 D/B(85)에 저장되어 있는 해당 구매업체(500)의 등록정보를 변경시킴으로써, 이후, 해당 구매업체(400)가 연체업체로 분류·관리될 수 있도록 한다.
그러나, 도 17b에 도시된 바와 같이, 구매업체(500)측의 신용카드 구매대금이 1000인데 반해, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 2000 이어서, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 구매업체(500)측의 신용카드 구매대금 이상인 것으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측(500)의 신용카드 구매대금을 정상적으로 회수하는 과정을 진행한다(단계 S524).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액의 회수를 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 구매업체(500)측의 보유 대금, 예컨대, 2000 중 1000을 구매업체측 지정계좌(93)로부터 판매업체측 지정계좌(91)로 입금시키게 되고, 결국, 판매업체(400)는 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있게 된다.
한편, 앞의 단계 S502에서, 당일 결제일인 신용카드 매출 건에 관계된 판매업체(400)가 앞의 경우와 같은 일련의 "신용카드 매출액 선 지급 과정"을 진행 받은 판매업체(400)이어서, 당일 결제일인 신용카드 매출 건이 앞의 경우와 같은 "선 지급 회수 대상 건"인 것으로 판단되는 경우, 대금 관리 서버(10)는 선 지급금 회수 관리 모듈(50)을 통해, 신용카드 매출액 선 지급 정보를 추출한 후, 이 신용카드 매출액 선 지급 정보를 활용하여, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 "신용카드 매출표 선 지급액" 이상인가의 여부를 판단한다(단계 S503).
이때, 도 17c에 도시된 바와 같이, 신용카드 매출표 선 지급액이 800인데 반해, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 500 이어서, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 신용카드 매출표 선 지급액 미만인 것으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(93)에 기 입금되어 있는 500을 회수함과 아울러, 은행(300)측과 신용카드 차주 관계에 있는 해당 구매업체(500)를 그 차액, 즉, 300만큼 연체 처리하는 과정을 진행한다(단계 S504,S505).
이 경우, 대금 관리 서버(10)는 운영 모듈(60)로 "해당 판매업체(400)를 연체 처리하라"는 메시지를 전달하게 되며, 운영 모듈(30)은 이러한 메시지가 전달되는 즉시, 등록정보 D/B(85)에 저장되어 있는 해당 구매업체(500)의 등록정보를 변경시킴으로써, 이후, 해당 구매업체(500)가 연체업체로 분류·관리될 수 있도록 한다.
그러나, 도 17d에 도시된 바와 같이, 신용카드 매출표 선 지급액이 800인데 반해, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 2000 이어서, 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액이 신용카드 매출표 선 지급액 이상인 것으로 판단되는 경우, 대금 관리 서버(10)는 은행(300)측이 선 지급한 "신용카드 매출표 선 지급액"을 정상적으로 회수하는 과정을 진행한다(단계 S506).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계좌(93)에 기 입금되어 있는 금액의 회수를 지시하게 되며, 계좌 관리 모듈(90)은이러한 지시 이벤트가 발생하는 즉시, 구매업체(500)측의 보유 대금, 예컨대, 2000 중 800을 구매업체측 지정계좌(93)로부터 시스템측 지정계좌(92)로 입금시키게 되고, 결국, 은행(300)은 상술한 "신용카드 매출액 선 지급과정"을 통해 선 지급한 대금을 손쉽게 회수할 수 있게 된다.
상술한 과정을 통해, "신용카드 매출표 선 지급액"의 회수과정이 마무리되면, 대금 관리 서버(10)는 구매업체(500)측의 보유대금 중, 앞의 "신용카드 매출표 선 지급액"을 차감한 나머지 적정 잔여액을 판매업체측 지정계좌(91)로 입금시키는 과정을 진행한다(단계 S507).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계좌(93)에 기 입금되어 있는 나머지 적정 금액의 이체를 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 구매업체(500)측의 나머지 보유 대금, 예컨대, 1200 중 "판매업체(400)의 잔여 채권 금액"인 200 만큼을 구매업체측 지정계좌(93)로부터 판매업체측 지정계좌(91)로 입금시키게 되고, 결국, 구매업체(400)는 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있게 된다.
이후, 대금 관리 서버(10)는 판매업체측 통신 클라이언트(1) 또는 구매업체측 통신 클라이언트(2) 등으로부터 일련의 판매대금 관리 이벤트, 구매대금 관리 이벤트 등이 발생될 때마다, 상술한 인증모듈(30), 판매대금 수금 명세표 관리모듈(40), 선 지급금 회수 관리 모듈(50), 운영정보 관리모듈(60), 계좌 관리모듈(90) 등을 긴밀하게 연계시켜, 일련의 판매대금 수금 관리 과정, 구매대금 지불 관리 과정 등을 체계적으로 진행시킴으로써, 임의의 판매업체(400), 구매업체(500) 등이 은행 온라인망을 기반으로 하여, 신뢰성 있는 대금결제 관계를 손쉽게 형성할 수 있도록 한다.
이상에서 상세히 설명한 바와 같이, 본 발명에서는 판매업체 및 구매업체 사이에 진행되는 전체적인 대금결제과정을 은행 온라인망을 기반으로 체계적으로 구현함으로써, 판매업체 및 구매업체가 자사에 필요한 판매대금 수금과정, 구매대금 지불과정 등을 외상거래, 어음사용 등을 활용하지 않고서도, 좀더 손쉽게 진행시킬 수 있도록 유도한다.
이러한 본 발명의 경우, 판매업체 및 구매업체 사이의 전체적인 대금결제과정이 온라인화 되기 때문에, 본 발명이 구현되는 경우, 판매업체 및 구매업체에서는 예컨대, "복잡한 구매대금 결제절차", "도난, 분실의 위험성" 등과 같은 오프라인 대금결제의 불편이 최소화되는 효과를 손쉽게 획득할 수 있다.
또한, 본 발명이 달성되는 경우, 구매업체에 의한 종래의 외상거래, 어음 사용 등이 미리 배제되기 때문에, 본 발명이 구현되는 경우, 판매업체 및 구매업체에서는 양자 사이에 형성되는 대금결제관계의 신뢰성이 대폭 향상되는 효과를 손쉽게 획득할 수 있다.
앞에서, 본 발명의 특정한 실시예가 설명되고 도시되었지만 본 발명이 당업자에 의해 다양하게 변형되어 실시될 가능성이 있는 것은 자명한 일이다.
이와 같은 변형된 실시예들은 본 발명의 기술적사상이나 관점으로부터 개별적으로 이해되어서는 안되며 이와 같은 변형된 실시예들은 본 발명의 첨부된 특허청구의 범위안에 속한다 해야 할 것이다.

Claims (14)

  1. 일련의 인증정보가 저장된 인증정보 D/B(Data Base), 일련의 판매대금 수금 명세표 정보가 저장된 판매대금 수금 명세표 정보 D/B, 일련의 신용카드 매출액 선 지급 정보가 저장된 신용카드 매출액 선 지급 정보 D/B, 일련의 판매기업/구매기업 등록정보가 저장된 등록정보 D/B를 구비한 D/B 블록과;
    상기 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매기업/구매기업 등록정보를 상기 D/B 블록의 필요영역에 선택적으로 저장하거나, 상기 D/B 블록의 필요 영역으로부터 선택적으로 추출하는 D/B 관리 서버와;
    상기 D/B 관리 서버와 일련의 통신관계를 형성한 상태에서, 상기 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매기업/구매기업 등록정보의 저장 및 추출 여부를 결정하며, 임의의 판매업체측 통신 클라이언트 및 구매업체측 통신 클라이언트와 은행 온라인망을 통해 인터페이스하고, 상기 판매업체측 통신 클라이언트 또는 구매업체측 통신 클라이언트로부터 일련의 판매대금 수금관리 이벤트 또는 구매대금 지불관리 이벤트가 발생하는 경우, 상기 인증정보, 판매대금 수금 명세표 정보, 신용카드 매출액 선 지급 정보, 판매기업/구매기업 등록정보를 체계적으로 조합하여, 해당 판매기업 및 구매기업 사이의 대금결제관계를 상기 은행 온라인망을 기반으로 총괄·관리하는 대금 관리 서버를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 시스템.
  2. 제 1 항에 있어서, 상기 은행 온라인망은 인터넷망, 자동응답 통신망(Automatic Response System communication network), 부가가치통신망(VAN:Value Added Network), 공중전화망(PSTN:Public Switched Telephone Network) 중의 어느 하나인 것을 특징으로 하는 기업간 대금결제 관리 시스템.
  3. 제 1 항에 있어서, 상기 대금 관리 서버는 상기 판매업체측 통신 클라이언트로부터 전송되는 소정의 판매대금 수금 명세표를 전담 관리하는 판매대금 수금 명세표 관리모듈과 일련의 통신관계를 더 형성하는 것을 특징으로 하는 기업간 대금결제 관리 시스템.
  4. 제 1 항에 있어서, 상기 대금 관리 서버는 상기 구매업체측으로부터 회수하여야할 소정의 신용카드 매출액 선 지급금을 전담 관리하는 선 지급금 회수 관리모듈과 일련의 통신관계를 더 형성하는 것을 특징으로 하는 기업간 대금결제 관리 시스템.
  5. 제 1 항에 있어서, 상기 대금 관리 서버는 상기 판매업체측에 지정된 판매업체측 지정계좌 및 상기 구매업체측에 지정된 구매업체측 지정계좌를 전담 관리하는 계좌 관리모듈과 일련의 통신관계를 더 형성하는 것을 특징으로 하는 기업간 대금결제 관리 시스템.
  6. 관리업체의 인증이 완료된 임의의 통신 클라이언트로부터 일련의 대금결제 이용 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 통신 클라이언트로부터 일련의 대금결제 이용 이벤트가 발생한 경우, 해당 통신 클라이언트를 관리하는 관리업체가 판매업체인가의 여부를 판단하는 단계와;
    해당 통신 클라이언트를 관리하는 관리업체가 판매업체로 판단되는 경우, 일련의 판매업체용 초기 페이지를 생성하고, 생성이 완료된 판매업체용 초기 페이지를 해당 판매업체측 통신 클라이언트로 전송하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 일련의 판매대금 수금 명세표 관리 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 일련의 판매대금 수금 명세표 관리 이벤트가 발생한 경우, 상기 판매업체측 통신 클라이언트로부터 전송되는 판매대금 수금 명세표를 참조하여, 일련의 판매대금 수금 명세표 관리 과정을 진행하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 일련의 신용카드 매출액 선 지급 신청 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 일련의 신용카드 매출액 선 지급 신청 이벤트가 발생한 경우, 상기 판매업체측 통신 클라이언트로부터 전송되는 신용카드 매출액 선 지급 신청 정보를 참조하여, 일련의 신용카드 매출 신청액 선 지급과정을 진행하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  7. 제 6 항에 있어서, 상기 판매대금 수금 명세표 관리 과정을 진행하는 단계는 상기 판매업체측 통신 클라이언트로부터 일련의 신용카드 매출표 전송 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출표 전송 이벤트가 발생한 경우, 해당 신용카드 매출 내역을 입력할 수 있는 일련의 신용카드 매출 내역 입력 페이지를 상기 판매업체측 통신 클라이언트로 전송하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출 내역 입력 페이지에 대응되는 일련의 신용카드 매출표 정보가 전송되었는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출 내역 입력 페이지에 대응되는 일련의 신용카드 매출표 정보가 전송된 경우, 해당 신용카드 매출표 정보가 기 지정된 일련의 요건을 만족하는가의 여부를 판단하는 단계와;
    상기 신용카드 매출표 정보가 기 지정된 일련의 요건을 만족하는 경우, 상기 신용카드 매출표 정보를 수집·저장하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  8. 제 7 항에 있어서, 상기 판매업체측 통신 클라이언트로부터 일련의 신용카드 매출표 전송 이벤트가 발생하지 않은 경우, 소정의 매출채권 내역을 입력할 수 있는 일련의 매출채권 내역 입력 페이지를 상기 판매업체측 통신 클라이언트로 전송하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 매출채권 내역 입력 페이지에 대응되는 일련의 매출채권 명세표 정보가 전송되었는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 매출채권 내역 입력 페이지에 대응되는 일련의 매출채권 명세표 정보가 전송된 경우, 해당 매출채권 명세표 정보가 기 지정된 일련의 요건을 만족하는가의 여부를 판단하는 단계와;
    상기 매출채권 명세표 정보가 기 지정된 일련의 요건을 만족하는 경우, 상기 매출채권 명세표 정보를 수집·저장함과 아울러, 판매업체가 보유한 매출채권액을 구매업체측 계좌로부터 판매업체측 계좌로 이체시키는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  9. 제 6 항에 있어서, 상기 신용카드 매출액 선 지급 과정을 진행하는 단계는 소정의 신용카드 매출액 선 지급 신청 내역을 입력할 수 있는 일련의 신용카드 매출액 선 지급 신청 내역 입력 페이지를 상기 판매업체측 통신 클라이언트로 전송하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출액 선 지급 신청 내역 입력 페이지에 대응되는 일련의 신용카드 매출액 선 지급 신청 정보가 전송되었는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출액 선 지급 신청내역 입력 페이지에 대응되는 일련의 신용카드 매출액 선 지급 신청 정보가 전송된 경우, 해당 신용카드 매출액 선 지급 신청 정보에 기록된 선 지급 신청액이 상기 판매업체측이 보유한 채권잔액 이내인가의 여부를 판단하는 단계와;
    해당 신용카드 매출액 선 지급 신청 정보에 기록된 선 지급 신청액이 상기 판매업체측이 보유한 채권잔액 이내인 경우, 해당 선 지급 신청액을 상기 판매업체측에 선 지급하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  10. 제 6 항에 있어서, 해당 통신 클라이언트를 관리하는 관리업체가 판매업체가 아닌 구매업체로 판단되는 경우, 일련의 구매업체용 초기 페이지를 생성하고, 생성이 완료된 구매업체용 초기 페이지를 해당 구매업체측 통신 클라이언트로 전송하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 일련의 구매대금 관리 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 일련의 구매대금 관리 이벤트가 발생한 경우, 상기 구매업체측 통신 클라이언트로부터 전송되는 구매대금 관리 정보를 참조하여, 일련의 구매대금 관리 과정을 진행하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  11. 제 10 항에 있어서, 상기 구매대금 관리 과정을 진행하는 단계는 상기 구매업체측 통신 클라이언트로부터 일련의 구매내역 조회 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 일련의 구매내역 조회 이벤트가 발생한 경우, 상기 구매업체측이 구매한 내역을 수집하여, 일련의 구매내역 리스트를 생성하고, 생성이 완료된 구매내역 리스트를 상기 구매업체측 통신 클라이언트로 전송하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 일련의 신용카드 구매대금 선 입금 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 상기 신용카드 구매대금 선 입금 이벤트가 발생한 경우, 소정의 신용카드 구매대금 선 입금 내역을 입력할 수 있는 일련의 신용카드 구매대금 선 입금 내역 입력 페이지를 상기 구매업체측 통신 클라이언트로 전송하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 상기 신용카드 구매대금 선 입금 내역 입력 페이지에 대응되는 일련의 신용카드 구매대금 선 입금 정보가 전송되었는가의 여부를 판단하는 단계와;
    상기 구매업체측 통신 클라이언트로부터 상기 신용카드 구매대금 선 입금 내역 입력 페이지에 대응되는 일련의 신용카드 구매대금 선 입금 정보가 전송된 경우, 상기 신용카드 구매대금 선 입금 정보를 토대로, 해당 신용카드 구매대금을 선 입금 처리하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  12. 제 6 항에 있어서, 상기 신용카드 매출액 선 지급 과정을 진행하는 단계 후에, 상기 신용카드 매출표 중, 당일 결제일인 신용카드 매출 건이 있는가의 여부를 판단하는 단계와;
    상기 신용카드 매출표 중, 당일 결제일인 신용카드 매출 건이 있는 경우, 상기 당일 결제일인 신용카드 매출 건에 관계된 해당 구매업체측의 지정계좌를 체크하여, 일련의 신용카드 구매대금 결제과정을 관리하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  13. 제 12 항에 있어서, 상기 신용카드 구매대금 결제과정을 관리하는 단계는 상기 당일 결제일 신용카드 매출 건이 선 지급 회수 대상 건인가의 여부를 판단하는 단계와;
    상기 당일 결제일 신용카드 매출 건이 선 지급 회수 대상 건인 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 신용카드 매출표 선 지급액 이상인가의 여부를 판단하는 단계와;
    상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 신용카드 매출표 선 지급액 이상인 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액으로부터 상기 신용카드 매출표 선 지급액을 회수하고, 상기 신용카드 매출표 선 지급액을 차감한 나머지 적정 잔여액을 판매업체측 지정계좌에 입금하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  14. 제 13 항에 있어서, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 상기 신용카드 매출표 선 지급액 미만인 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 잔여액을 회수함과 아울러, 상기 구매업체를 연체 처리하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
KR10-2001-0011094A 2000-03-10 2001-03-05 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 KR100435854B1 (ko)

Priority Applications (7)

Application Number Priority Date Filing Date Title
KR10-2001-0011094A KR100435854B1 (ko) 2000-03-10 2001-03-05 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
CN01809192A CN1427975A (zh) 2000-03-10 2001-03-09 用于管理公司间结算的系统及其方法
EP01912547A EP1269372A4 (en) 2000-03-10 2001-03-09 SYSTEM AND METHOD FOR SETTLEMENT MANAGEMENT BETWEEN COMPANIES
PCT/KR2001/000369 WO2001067331A1 (en) 2000-03-10 2001-03-09 A system for managing inter-company settlement and the method therefor
AU41237/01A AU4123701A (en) 2000-03-10 2001-03-09 A system for managing inter-company settlement and the method therefor
US10/220,765 US20030041024A1 (en) 2000-03-10 2001-03-09 System for managing inter-company settlement and the method therefor
JP2001069364A JP2001266025A (ja) 2000-03-10 2001-03-12 代金決済管理システム及び代金決済管理方法

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
KR20000012000 2000-03-10
KR1020000012000 2000-03-10
KR10-2001-0011094A KR100435854B1 (ko) 2000-03-10 2001-03-05 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법

Publications (2)

Publication Number Publication Date
KR20010088377A true KR20010088377A (ko) 2001-09-26
KR100435854B1 KR100435854B1 (ko) 2004-06-12

Family

ID=26637428

Family Applications (1)

Application Number Title Priority Date Filing Date
KR10-2001-0011094A KR100435854B1 (ko) 2000-03-10 2001-03-05 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법

Country Status (7)

Country Link
US (1) US20030041024A1 (ko)
EP (1) EP1269372A4 (ko)
JP (1) JP2001266025A (ko)
KR (1) KR100435854B1 (ko)
CN (1) CN1427975A (ko)
AU (1) AU4123701A (ko)
WO (1) WO2001067331A1 (ko)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010099419A (ko) * 2001-09-26 2001-11-09 김형태 기업간 대금결제 시스템
KR100684967B1 (ko) * 2004-08-04 2007-02-20 전달용 판매 대금 결제 서비스 제공 방법 및 시스템

Families Citing this family (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
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
US20070265874A1 (en) * 2006-05-15 2007-11-15 Accenture Global Services Gmbh Systems, applications and products in data processing for partner determination
US8041613B2 (en) * 2006-05-15 2011-10-18 Accenture Global Services Limited Systems, applications and products in data processing for cross dock
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)

* 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
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 オンライン決済装置

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20010099419A (ko) * 2001-09-26 2001-11-09 김형태 기업간 대금결제 시스템
KR100684967B1 (ko) * 2004-08-04 2007-02-20 전달용 판매 대금 결제 서비스 제공 방법 및 시스템

Also Published As

Publication number Publication date
EP1269372A1 (en) 2003-01-02
AU4123701A (en) 2001-09-17
KR100435854B1 (ko) 2004-06-12
CN1427975A (zh) 2003-07-02
WO2001067331A1 (en) 2001-09-13
EP1269372A4 (en) 2004-07-28
US20030041024A1 (en) 2003-02-27
JP2001266025A (ja) 2001-09-28

Similar Documents

Publication Publication Date Title
EP0791202B1 (en) Computerized payment system for purchasing information products by electronic transfer on the internet
KR100542386B1 (ko) 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
US8286861B2 (en) Cash payment for remote transactions
US20070005467A1 (en) System and method for carrying out a financial transaction
US20080162348A1 (en) Electronic-Purse Transaction Method and System
KR20020006625A (ko) 중간계정을 이용하는 전자 지불 시스템
JP2002530757A5 (ko)
EA010957B1 (ru) Предварительно оплаченная платежная карточка, которая может немедленно дистанционно пополняться с помощью купона
KR100435854B1 (ko) 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
JP2001243400A (ja) 関連口座を用いた口座管理システム
KR20000059133A (ko) 온라인 및 오프라인 거래보호를 위한 지불유보 현금카드시스템
KR102596699B1 (ko) 가상화폐 결제를 위한 가상계좌를 사용시 즉시 카드결제가 가능한 결제처리방법
JP2002207952A (ja) 仮受金管理システム、および、仮受金管理方法
KR102597020B1 (ko) 가상화폐 결제를 위한 가상계좌를 사용시 즉시 현금결제가 가능한 결제처리방법
CA2592534C (en) Computerized payment system for purchasing information products by electronic transfer on the internet
CA2199942C (en) Computerized payment system for purchasing information products by electronic transfer on the internet
KR20010096567A (ko) 온/오프라인상에서의 자금 대출 시스템 및 그 운용방법
JP2001297282A (ja) 決済管理システム
JP2001195528A (ja) 決済システムおよび決済処理方法
KR20180001980A (ko) 공용 가상 계좌 서비스를 이용한 금융 데이터 처리 방법 및 그 장치
AU696475C (en) Computerized payment system for purchasing information products by electronic transfer on the internet
KR20030051572A (ko) 유무선통합 밴시스템의 신용 결제와 결제 대행 중계방법
KR20040026194A (ko) 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법
KR20180112634A (ko) 금융서비스 제공 방법 및 장치, 그리고 이에 적용되는 컴퓨터 프로그램 및 기록매체
JP2002074194A (ja) 通信販売代金決済システム

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E701 Decision to grant or registration of patent right
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130418

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20140502

Year of fee payment: 11

FPAY Annual fee payment

Payment date: 20160325

Year of fee payment: 13

FPAY Annual fee payment

Payment date: 20170329

Year of fee payment: 14

FPAY Annual fee payment

Payment date: 20180328

Year of fee payment: 15

FPAY Annual fee payment

Payment date: 20190403

Year of fee payment: 16