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

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

Info

Publication number
KR100542386B1
KR100542386B1 KR1020010006687A KR20010006687A KR100542386B1 KR 100542386 B1 KR100542386 B1 KR 100542386B1 KR 1020010006687 A KR1020010006687 A KR 1020010006687A KR 20010006687 A KR20010006687 A KR 20010006687A KR 100542386 B1 KR100542386 B1 KR 100542386B1
Authority
KR
South Korea
Prior art keywords
payment
purchaser
statement
company
information
Prior art date
Application number
KR1020010006687A
Other languages
English (en)
Other versions
KR20010082133A (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 KR1020010006687A priority Critical patent/KR100542386B1/ko
Priority to US10/203,824 priority patent/US20030014362A1/en
Priority to EP01908390A priority patent/EP1257932A1/en
Priority to CN01808075A priority patent/CN1423783A/zh
Priority to PCT/KR2001/000219 priority patent/WO2001061532A1/en
Priority to AU36134/01A priority patent/AU3613401A/en
Priority to JP2001038848A priority patent/JP2001283115A/ja
Publication of KR20010082133A publication Critical patent/KR20010082133A/ko
Application granted granted Critical
Publication of KR100542386B1 publication Critical patent/KR100542386B1/ko

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

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Engineering & Computer Science (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Economics (AREA)
  • Theoretical Computer Science (AREA)
  • Marketing (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}
도 1은 본 발명이 채용된 기업간 대금결제 관계를 개념적으로 도시한 예시도.
도 2는 본 발명에 따른 기업간 대금결제 관리 시스템을 개념적으로 도시한 예시도.
도 3은 본 발명의 일실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 4 및 도 5는 본 발명의 일실시예에 따른 구매업체측 통신 클라이언트 및 판매업체측 통신 클라이언트의 초기 페이지 게시상태를 개념적으로 도시한 예시도.
도 6은 본 발명의 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 7 및 도 8은 본 발명의 다른 실시예에 따른 구매업체측 통신 클라이언트의 메시지 게시상태를 개념적으로 도시한 예시도.
도 9는 본 발명의 또 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 10 및 도 11은 본 발명의 또 다른 실시예에 따른 판매업체측 통신 클라이언트의 메시지 게시상태를 개념적으로 도시한 예시도.
도 12는 본 발명의 또 다른 실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.
도 13a 내지 도 13d는 본 발명의 또 다른 실시예에 따른 구매업체측 지정계좌의 금액 입금상태를 개념적으로 도시한 예시도.
본 발명은 기업간 대금결제 관리 시스템에 관한 것으로, 좀더 상세하게는 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 은행 온라인망을 기반으로 체계적으로 구현함으로써, 판매업체 및 구매업체가 자사에 필요한 판매대금 수금과정, 구매대금 지불과정 등을 좀더 신뢰성 있게 진행시킬 수 있도록 유도할 수 있는 기업간 대금결제 관리 시스템에 관한 것이다. 더욱이, 본 발명은 이러한 기업간 대금결제 관리 시스템을 이용한 기업간 대금결제 관리 방법에 관한 것이다.
최근, 경제 발전의 속도가 가속화되면서, 기업간의 거래 빈도수 또한 뚜렷한 증가추세를 나타내고 있으며, 이러한 기업간 거래의 증가 추세에 맞추어, 판매업체 및 구매업체 사이의 대금결제 관계 또한 중요한 사회적 이슈로 등장하고 있다.
이와 같이, 판매업체 및 구매업체 사이의 대금결제 관계가 중요한 사회적 이 슈로 등장할 수밖에 없는 이유는 만약, 판매업체 및 구매업체 사이의 대금결제 관계가 신뢰성 있게 이루어지지 못하여, 개별 기업이 도산하는 경우, 국가의 기간 경제질서가 파괴되고, 그 파급효과에 의해 전체적인 사회질서가 무너지는 심각한 문제점이 야기될 수 있기 때문이다.
상술한 기업간 거래관계가 형성될 때, 통상, 일련의 물품, 용역 등을 판매한 판매업체에서는 구매업체를 대상으로, 일련의 대금청구 과정을 진행하는 것이 일반적인데, 종래의 경우, 대부분의 구매업체에서는 현금(Cash) 보다는 어음(Bill)을 대금 결제의 중요한 수단으로 선호하고 있다. 이는 대금 결제의 수단으로 어음을 활용하는 경우, 해당 구매업체에서는 전체적인 자금회전을 현금 결제에 비해, 좀더 융통성 있게 진행시킬 수 있는 이점을 손쉽게 획득할 수 있기 때문이다.
그러나, 앞서 언급한 종래의 실물어음은 일련의 "교부‥추심‥" 등의 복잡한 과정을 거쳐 발행되는 것이 일반적이기 때문에, 이 어음이 주요 결제수단으로 사용되는 경우, "구매업체 및 판매업체" 양측에서는 공히 예측하지 못한 큰 불편함을 감수할 수밖에 없게 된다. 더욱이, 이러한 실물어음은 오프라인(Off-line)상에서 유통되는 것이 일반적이기 때문에, 항상 도난, 분실 등의 위험성을 내포하고 있으며, 이를 사용하는 "구매업체 및 판매업체"에서는 항상 필요이상의 주의를 기울여야 하는 불편함을 감수할 수밖에 없게 된다.
또한, 앞서 언급한 어음은 그 발행일과 실질적인 현금 지불일이 서로 상이한 특성을 갖고 있기 때문에, 구매업체로부터 어음을 발급 받은 판매업체는 항상 "구매대금이 지불되지 못할 수도 있는 위험성"을 감수할 수밖에 없으며, 만약, 이 위 험성이 현실화되어, 어음을 발생한 구매업체가 실질적인 "구매대금 지불과정"을 이행하지 못한 상태에서, 갑자기 도산하는 경우, 판매업체는 자신의 의사와 무관하게 막대한 피해를 입을 수밖에 없게 된다.
이때, 해당 판매업체가 다른 업체와 또 다른 대금결제 관계를 맺고 있는 경우, 구매업체의 도산은 다른 여러 판매업체들의 연쇄부도로 이어질 수밖에 없으며, 이를 방치하는 경우, 전체적인 경제질서가 급격히 무너지는 심각한 사회문제가 야기될 수밖에 없게 된다.
따라서, 본 발명의 목적은 은행 온라인망을 기반으로, 판매업체가 구매업체를 상대로 취득한 장래의 매출채권을 판매업체로부터 양도받고, 이를 담보로, 구매업체가 지불하여야할 구매대금을 온라인 상에서 미리 선 지급해 줌으로써, 해당 구매업체가 판매업체를 대상으로 하는 일련의 대금 결제관계를 별다른 자금 부담 없이 좀더 손쉽게 형성할 수 있도록 유도하는데 있다.
본 발명의 다른 목적은 구매업체에 의한 종래의 어음 사용을 미리 배제하고, 이를 통해, 판매업체 및 구매업체 사이에 형성되는 대금 결제관계의 신뢰성을 대폭 향상시킴으로써, 예측하지 못한 판매업체의 피해를 최소화시키는데 있다.
본 발명의 또 다른 목적은 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 온라인 상에서 체계적으로 구현함으로써, 판매업체 및 구매업체가 온라인망을 기반으로, 자사에 필요한 판매대금 수금과정, 구매대금 지불과정을 불필요한 도난, 분실 등의 위험성 없이 좀더 손쉽게 진행시킬 수 있도록 유도하는데 있다.
본 발명의 또 다른 목적은 구매업체 및 판매업체 사이에 형성되는 대금 결제관계의 신뢰성을 향상시킴으로써, 여러 업체의 연쇄 부도에 따른 경제적인 피해를 최소화시키는데 있다.
본 발명의 또 다른 목적들은 다음의 상세한 설명과 첨부된 도면으로부터 보다 명확해질 것이다.
상기와 같은 목적을 달성하기 위하여 본 발명에서는 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 블록의 필요 영역으로부터 상술한 각 정보들을 선택적으로 추출하는 역할을 수행한다.
여기서, 상술한 대금 관리 서버는 앞의 D/B 관리 서버와 일련의 통신관계를 형성한 상태로, 상술한 인증정보, 구매대금 지불 명세표 정보, 대출금 선 지급 정보, 신용카드 매출표 매입대금 선 지급 정보 등의 저장 및 추출 여부를 결정하는 역할을 수행한다.
이와 함께, 대금 관리 서버는 임의의 구매업체측 통신 클라이언트 및 판매업체측 통신 클라이언트와 은행 온라인망을 통해 인터페이스한 상태에서, 구매업체측 통신 클라이언트 및 판매업체측 통신 클라이언트에 의해 일련의 구매대금 지불 명세표 관리 이벤트 및 판매대금 선 지급 신청 이벤트가 발생하는 경우, 상술한 각종 정보들을 체계적으로 조합하여, 구매업체측이 지불하여야할 구매대금을 판매업체측에 온라인으로 선 지급함과 아울러, 소정 기일이 경과한 후, 해당 선 지급금에 상당하는 금액을 구매업체측으로부터 온라인으로 회수하는 역할을 수행한다.
이하, 첨부된 도면을 참조하여, 본 발명에 따른 기업간 대금결제 관리 시스템 및 이를 이용한 기업간 대금결제 관리 방법을 좀더 상세히 설명하면 다음과 같다.
도 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)는 임의의 구매업체(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)는 상술한 구매업체(400)측 통신 클라이언트(1) 및 판매업체(500)측 통신 클라이언트(2)로부터 일련의 구매대금 지불 명세표 관리 이벤트 및 판매대금 선 지급 신청 이벤트가 발생하는 경우, 상술한 인증정보, 구매대금 지불 명세표 정보, 대출금 선 지급 정보, 신용카드 매출표 매입대금 선 지급 정보, 운영 정보, 등록정보 등을 체계적으로 조합하여, 구매업체(400)측이 지불하여야할 구매대금을 판매업체(500)측에 온라인으로 선 지급함과 아울러, 소정 기일이 경과한 후, 해당 선 지급금에 상당하는 금액을 구매업체(400)측으로부터 온라인으로 회수하는 역할을 수행한다.
이때, 상술한 인증모듈(30)은 구매업체(400)측 통신 클라이언트(1), 판매업체(500)측 통신 클라이언트(2) 등을 통해 본 발명의 기업간 대금 결제 관리 시스템(100)에 접근하는 임의의 "구매업체(400), 판매업체(500)"의 기 등록여부를 앞의 인증정보 D/B(81)를 활용하여, 인증하는 역할을 전담하며, 구매대금 지불 명세표 관리 모듈(40)은 구매업체(400)측 통신 클라이언트(1)로부터 전송되는 구매대금 지불 명세표를 앞의 구매대금 지불 명세표 정보 D/B(82)를 활용하여 관리하는 역할을 전담한다.
또한, 선 지급금 회수 관리 모듈(50)은 시스템(100)측이 판매업체측에 선 지급한 선 지급금을 앞의 대출금 선지급 정보 D/B(83), 신용카드 매출표 매입대금 선 지급 정보 D/B(84) 등을 활용하여 관리하는 역할을 전담하며, 운영정보 관리 모듈(60)은 대금 관리 서버(10)의 세부 운영사항을 앞의 운영정보 D/B(85), 등록정보 D/B(86) 등을 활용하여 관리하는 역할을 전담한다.
이때, 도면에 도시된 바와 같이, 계좌 관리 모듈(90)은 앞의 인증모듈(30), 구매대금 지불 명세표 관리 모듈(40), 선 지급금 회수 관리 모듈(50), 운영정보 관리 모듈(60) 등과 유사하게 대금 관리 서버(10)와 긴밀한 통신연결 관계를 형성한 상태에서, 시스템(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) 등으로부터 출력되는 데이터를 시스템측(100)의 인터페이스 모듈(20)로 전달하거나, 시스템(100)측의 인터페이스 모듈(20)로부터 출력되는 데이터를 구매업체측 유/무선 통신기(1b), 판매업체측 유/무선 통신기(2b) 등으로 전달하는 역할을 수행한다.
이러한 기반환경이 갖추어진 상태에서, 도 3에 도시된 바와 같이, 대금 관리 서버(10)는 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a) 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생하였는가의 여부를 판단한다(단계 S1).
이때, 구매업체측 컴퓨터(1a) 또는 판매업체측 컴퓨터(2a)로부터 상술한 시스템 접속 이벤트가 발생하지 않은 것으로 판단되는 경우, 대금 관리 서버(10)는 플로우를 후술하는 단계 S11로 진행한다.
그러나, 구매업체측 컴퓨터(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).
여기서, 구매업체(400)가 기 등록된 업체로 인증 받기 위해서는 은행(300)측과 별도의 구매업체 약정, 예컨대, "협약서 약정", "신용카드 발급 약정" 등을 미리 체결하고, 그 정보가 인증정보 D/B(81)에 미리 기록되어 있어야 하며, 판매업체(500)가 기 등록된 업체로 인증 받기 위해서는 은행(300)측과 별도의 판매업체 약정, 예컨대, "대출 약정", "신용카드 가맹점 특약" 등을 미리 체결하고, 그 정보가 구매업체(400)와 마찬가지로, 인증정보 D/B(81)에 미리 기록되어 있어야 한다. 물론, 이러한 조건을 선결하지 않은 구매업체(400), 판매업체(500) 등은 등록된 업체로 인증 받을 수 없고, 결국, 본 발명에 의한 일련의 서비스를 향유할 수 없다.
이때, 시스템(100)에 접속 중인 업체가 등록된 업체가 아닌 것으로 판단되는 경우, 대금 관리 서버(10)는 예컨대, "귀사는 등록된 고객이 아니오니, 먼저, 등록 해 주십시오" 등과 같은 내용의 등록 요구 메시지를 생성하고, 생성이 완료된 등록 요구 메시지를 해당 업체측 컴퓨터로 전송하는 과정을 진행한다(단계 S6).
그러나, 시스템(10)에 접속 중인 업체가 등록된 업체로 판단되는 경우, 대금 관리 서버(10)는 예컨대, 운영 정보 관리 모듈(60) 등을 활용하여, 등록정보 D/B(86)에 저장된 해당업체의 등록정보를 수집한 후, 해당 업체가 구매업체(400)인가 또는 판매업체(500)인가의 여부를 판단한다(단계 S7).
이때, 해당 업체가 구매업체(400)로 판단되는 경우, 대금 관리 서버(10)는 해당 구매업체의 등록정보가 반영된 일련의 구매업체용 초기 페이지를 생성하고, 생성이 완료된 구매업체용 초기 페이지를 구매업체측 컴퓨터로 전송한다(단게 S8).
이 경우, 구매업체측 컴퓨터(1a)는 이 구매업체용 초기 페이지(601)를 신속히 해석하여, 이를 도 4에 도시된 바와 같이 디스플레이 시킴으로써, 구매업체(400)에 의한 일련의 구매대금 지불 명세표 관리 과정이 원활하게 진행될 수 있는 기반환경을 제공한다.
그러나, 해당 업체가 판매업체(500)로 판단되는 경우, 대금 관리 서버(10)는 해당 판매업체의 등록정보가 반영된 일련의 판매업체용 초기 페이지를 생성하고, 생성이 완료된 판매업체용 초기 페이지를 판매업체측 컴퓨터(2a)로 전송한다(단게 S6a).
이 경우, 판매업체측 컴퓨터(2a)는 이 판매업체용 초기 페이지(607)를 신속히 해석하여, 이를 도 5에 도시된 바와 같이 디스플레이 시킴으로써, 판매업체(500)에 의한 일련의 판매대금 선 지급 신청 과정이 원활하게 진행될 수 있는 기반환경을 제공한다.
여기서, 구매대금 지불 명세표는 소정의 상품, 용역 등을 구매한 구매기업(400)이 해당 상품, 용역 등을 판매한 판매기업(500)을 대상으로 어떤 종류의 결제과정을 진행하였는가를 표시하는 명세표를 말하는 바, 만약, 구매기업(400)이 이 구매대금 지불 명세표로써, 예컨대, "매출채권 명세표"를 전송하는 경우, 이는 "매출채권을 통하여 구매대금을 결제하였다"라는 것을 의미하며, 구매대금 지불 명세표로써, 예컨대, "신용카드 매출표"를 전송하는 경우, 이는 "기업전용 신용카드를 이용하여, 구매대금을 결제하였다"라는 것을 의미한다. 이때, 기업전용 카드는 본 발명의 대금결제 관리 시스템(100)을 구비한 은행(300)이 앞의 "신용카드 발급 약정"을 선결한 구매기업(400)을 대상으로 특별히 발급한 카드이다.
이때, 도 5에 도시된 바와 같이, 구매업체측 컴퓨터(1a)의 구매업체용 초기 페이지(601)에는 예컨대, 신용카드 매출표 전송 항목(602a), 신용카드 매출표 전송내역 조회 항목(603a), 매출채권 명세표 전송 항목(602b), 매출채권 명세표 전송내역 조회 항목(603b), 지급내역 조회 항목(604), 연체내역 조회 항목(605), 처리결과 조회 항목(606) 등이 구비되며, 구매업체(400)에서는 앞의 각 항목들을 선택적으로 클릭함으로써, 해당 항목을 실시간 확인/설정할 수 있다. 물론, 이러한 각 항목들은 상황에 따라 다양한 변형을 이룰 수 있다.
또한, 도 6에 도시된 바와 같이, 판매업체측 컴퓨터(2a)의 판매업체용 초기 페이지(607)에는 예컨대, 판매대금 선 지급 신청내역 조회 항목(608), 판매내역 조 회 항목(609), 대출 신청 항목(610a), 신용카드 매출표 매입 신청 항목(610b) 등이 구비되며, 판매업체(500)에서는 앞의 구매업체(400)의 경우와 유사하게, 각 항목들을 선택적으로 클릭함으로써, 해당 항목을 실시간 확인/설정할 수 있다. 물론, 이러한 각 항목들 또한 상황에 따라 다양한 변형을 이룰 수 있다.
이때, 판매업체(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)측에서, 예컨대, 구매업체용 초기 페이지(601)의 매출채권 명세표 전송 항목(602b), 신용카드 매출표 전송 항목(602a) 등을 클릭하여, 구매업체측 컴퓨터(1a)로부터 일련의 구매대금 지불 명세표 관리 이벤트가 발생한 경우, 대금 관리 서버(10)는 구매업체측 컴퓨터(1a)로부터 전송되는 구매대금 지불 명세표 정보를 참조하여, 일련의 구매대금 지불 명세표 관리 과정을 신속하게 진행하게 된다(단계 S100).
이와 유사하게, 대금 관리 서버는 판매업체측 컴퓨터(2a)에 일련의 판매업체용 초기 페이지(601,610)가 게시된 상태에서, 해당 판매업체측 컴퓨터(2a)로부터 일련의 판매대금 선 지급 신청 이벤트가 발생하였는가의 여부를 판단한다(단계 S10).
이때, 판매업체측 컴퓨터(2a)로부터 별도의 판매대금 지불 명세표 관리 이벤트가 발생하지 않은 것으로 판단되면, 대금 관리 서버(10)는 플로우를 단계 S10a로 진행하여, 일련의 대기 상태를 유지한다.
그러나, 판매업체(500)측에서, 예컨대, 판매업체용 초기 페이지(607)의 대출 신청 항목(610a), 신용카드 매출표 매입 신청 항목(610) 등을 클릭하여, 판매업체측 컴퓨터(2a)로부터 일련의 판매대금 선 지급 신청 이벤트가 발생한 경우, 대금 관리 서버는 판매업체측 컴퓨터(2a)로부터 전송되는 판매대금 선 지급 정보를 참조하여, 일련의 판매대금 선 지급 과정을 신속히 진행하게 된다(단계 S200).
먼저, 상술한 구매대금 지불 명세표 관리 과정(단계 S100)을 상세히 설명한다.
도 6에 도시된 바와 같이, 대금 관리 서버(10)는 구매업체측 컴퓨터(1a)로부터 일련의 매출채권 명세표 전송 이벤트가 발생하였는가의 여부를 판단한다(단계 S101).
이때, 구매업체(400)측에서 초기 페이지(601)의 신용카드 매출표 전송 항목(602a)을 클릭하여, 구매업체측 컴퓨터(1a)로부터 매출채권 명세표 전송 이벤트 대신에, 일련의 신용카드 매출표 전송 이벤트가 발생한 것으로 판단되면, 대금 관리 서버는 운영정보 관리 모듈(60)을 활용하여, 일련의 신용카드 매출표 내역 입력 메시지를 생성하고, 생성이 완료된 신용카드 매출표 내역 입력 메시지를 인터페이스 모듈(20)을 매개로 하여, 구매업체측 컴퓨터(1a)로 전송한다(단계 S102).
이 경우, 구매업체측 컴퓨터(1a)는 대금 관리 서버(10)로부터 전송되는 신용카드 매출표 내역 입력 메시지(611)를 신속히 해석하여, 이를 도 7에 도시된 바와 같이, 디스플레이 시킴으로써, 구매업체(400)가 일련의 신용카드 매출표 정보를 생 성할 수 있는 안정적인 기반환경을 제공받도록 한다.
이 상태에서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 컴퓨터(1a)로부터 일련의 신용카드 매출표 정보가 전송되었는가의 여부를 판단한다(단계 S103).
이때, 구매업체(400)측에서, 아직, 신용카드 매출표 내역 입력과정을 완료하지 않아, 구매업체측 컴퓨터(1a)로부터 일련의 신용카드 매출표 정보가 전송되지 않은 것으로 판단되면, 대금 관리 서버(10)는 플로우를 단계 S104로 진행하여, 일련의 대기 상태를 유지한다.
그러나, 구매업체(400)측에서, 신용카드 매출표 내역 입력과정을 모두 완료하고, 예컨대, 전송 항목(612)을 클릭하여, 구매업체측 컴퓨터(1a)로부터 일련의 신용카드 매출표 정보가 전송된 것으로 판단되면, 대금 관리 서버(10)는 이 신용카드 매출표 정보의 타당성 여부, 예컨대, 신용카드 매출표 정보에 기록된 신용카드 지급대상 금액이 기 지정된 신용카드 한도 금액 이내인가, 신용카드 매출표 정보에 기록된 지급대상 판매업체가 등록된 판매업체인가 등의 여부를 판단한다(단계 S105).
이때, 신용카드 매출표 정보에 기록된 신용카드 지급대상 금액이 기 지정된 신용카드 한도 금액을 초과하거나, 신용카드 매출표 정보에 기록된 지급대상 판매업체가 등록된 판매업체가 아닌 것으로 판단되는 경우, 대금 관리 서버(10)는 일련의 오류 메시지를 구매업체측 컴퓨터(1a)로 전송하는 과정을 진행한다(단계 S106).
이 경우, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 운영정 보 D/B(85)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 예컨대, "선택하신 금액이 신용카드 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 구매업체측 컴퓨터(1a)로 전송한다.
그러나, 신용카드 매출표 정보에 기록된 신용카드 지급대상 금액이 기 지정된 신용카드 한도 금액 이내의 금액이고, 신용카드 매출표 정보에 기록된 지급대상 판매업체가 등록된 판매업체로 판단되어, 해당 신용카드 매출표 정보의 타당성이 인정되는 경우, 대금 관리 서버(10)는 해당 신용카드 매출표 정보를 수집·저장하는 과정을 진행한다(단계 S107).
이 경우, 대금 관리 서버(10)는 구매업체측 컴퓨터(1a)로부터 전송된 신용카드 매출표 정보를 구매대금 지불 명세표 관리 모듈(40)로 전달하게 되며, 구매대금 지불 명세표 관리 모듈(40)은 이러한 신용카드 매출표 정보가 전달되는 즉시, 이를 D/B 관리 서버(70)로 전달함으로써, 해당 신용카드 매출표 정보가 예컨대, 구매대금 지불 명세표 정보 D/B(82)에 안정적으로 수집·저장될 수 있도록 한다.
한편, 앞서 언급한 단계 S101에서, 구매업체(400)가 초기 페이지(601)의 매출채권 명세표 전송 항목(602b)을 클릭하여, 구매업체측 컴퓨터(1a)로부터 일련의 매출채권 명세표 전송 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 매출채권 내역 입력 메시지를 생성하고, 생성이 완료된 매출채권 내역 입력 메시지를 인터페이스 모듈(20)을 매개로 하여, 구매업체측 컴퓨터(1a)로 전송한다(단계 S108).
이 경우, 구매업체측 컴퓨터(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)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 예컨대, "선택하신 금액이 매출채권 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 구매업체측 컴퓨터(1a)로 전송한다.
그러나, 매출채권 명세표 정보에 기록된 매출채권 지급대상 금액이 기 지정된 매출채권 한도 금액 이내의 금액이고, 매출채권 명세표 정보에 기록된 지급대상 판매업체가 기 등록된 판매업체로 판단되어, 해당 매출채권 명세표의 타당성이 인정되는 경우, 대금 관리 서버(10)는 해당 매출채권 명세표 정보를 수집·저장하는 과정을 진행한다(단계 S113).
이 경우, 대금 관리 서버(10)는 구매업체측 컴퓨터(1a)로부터 전송된 매출채권 명세표 정보를 구매대금 지불 명세표 관리 모듈(40)로 전달하게 되며, 구매대금 지불 명세표 관리 모듈(40)은 이러한 매출채권 명세표 정보가 전달되는 즉시, 이를 D/B 관리 서버(70)로 전달함으로써, 해당 매출채권 명세표 정보가 예컨대, 구매대금 지불 명세표 정보 D/B(82)에 안정적으로 수집·저장될 수 있도록 한다.
다음으로, 상술한 판매대금 선 지급 과정(단계 S200)을 상세히 설명한다.
도 9에 도시된 바와 같이, 먼저, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 판매업체측 컴퓨터(2a)로부터 매출채권 명세표에 의 한 일련의 대출 신청 이벤트가 발생하였는가의 여부를 판단한다(단계 S201).
이때, 판매업체(500)측에서, 초기 페이지(607)의 신용카드 매출표 매입 신청 항목(610)을 클릭하여, 판매업체측 컴퓨터(2a)로부터 매출채권 명세표에 의한 대출 신청 이벤트 대신에, 일련의 신용카드 매출표 매입 신청 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 신용카드 매출표 매입신청 내역 입력 메시지를 생성하고, 생성이 완료된 신용카드 매출표 매입신청 내역 입력 메시지를 인터페이스 모듈(20)을 매개로 하여, 판매업체측 컴퓨터(2a)로 전송한다(단계 S202).
이 경우, 판매업체측 컴퓨터(2a)는 대금 관리 서버(10)로부터 전송되는 신용카드 매출표 매입신청 내역 입력 메시지(615)를 신속히 해석하여, 이를 도 10에 도시된 바와 같이, 디스플레이 시킴으로써, 판매업체(500)가 일련의 신용카드 매출표 매입신청 과정을 신속하게 진행시킬 수 있는 안정적인 기반환경을 제공받도록 한다.
이 상태에서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 판매업체측 컴퓨터(2a)로부터 일련의 신용카드 매출표 매입신청 정보가 전송되었는가의 여부를 판단한다(단계 S203).
이때, 판매업체측(500)에서, 아직, 신용카드 매출표 매입신청 내역 입력과정을 완료하지 않아, 판매업체측 컴퓨터(2a)로부터 일련의 신용카드 매출표 매입신청 정보가 전송되지 않은 것으포 판단되면, 대금 관리 서버(10)는 플로우를 단계 S204로 진행하여, 일련의 대기 상태를 유지한다.
그러나, 판매업체(500)측에서, 신용카드 매출표 매입신청 내역 입력과정을 모두 완료하고, 예컨대, 전송 항목(616)을 클릭하여, 판매업체측 컴퓨터(2a)로부터 일련의 신용카드 매출표 매입신청 정보가 전송된 것으로 판단되면, 대금 관리 서버는 신용카드 매출표 매입신청 정보에 기록된 신용카드 매출표 매입신청 금액이 기 지정된 채권 잔액 한도 이내인가의 여부를 판단한다(단계 S205).
이때, 신용카드 매출표 매입신청 정보에 기록된 신용카드 매출표 매입신청 금액이 기 지정된 채권 잔액을 초과하는 경우, 대금 관리 서버(10)는 일련의 오류 메시지를 판매업체측 컴퓨터(2a)로 전송하는 과정을 진행한다(단계 S206).
이 경우, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 운영정보 D/B(85)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 예컨대, "신청하신 금액이 채권 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 판매업체측 컴퓨터(2a)로 전송한다.
그러나, 신용카드 매출표 매입신청 정보에 기록된 신용카드 매출표 매입신청 금액이 기 지정된 채권 잔액 한도 이내의 금액인 경우, 대금 관리 서버(10)는 일련의 "신용카드 매출표 매입 대금"을 구매업체(400)를 대신하여, 판매업체(500)측에게 미리 선 지급하는 과정을 진행한다(단계 S207).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 "신용카드 매출표 매입 대금"의 선 지급을 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 일정액의 현금을 예컨대, 시스템측 지정계좌(92)로부터 판매업체측 지정계좌(93)로 입금시키게 되고, 결국, 구매업체(400)를 대상으로 일련의 물품, 용역 등을 판매한 판매업체(500)는 "자사에서 판매한 물품, 용역" 등에 상응하는 일련의 "신용카드 매출표 매입 대금"을 온라인 상에서 손쉽게 선 입금 받을 수 있게 된다.
한편, 앞서 언급한 단계 S201에서, 판매업체(500)가 초기 페이지(607)의 대출 신청 항목(610a)을 클릭하여, 판매업체측 컴퓨터(2a)로부터 매출채권 명세표에 의한 일련의 대출 신청 이벤트가 발생한 것으로 판단되면, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 일련의 대출 신청 내역 입력 메시지를 생성하고, 생성이 완료된 대출 신청 내역 입력 메시지를 인터페이스 모듈(20)을 매개로 하여, 판매업체측 컴퓨터(2a)로 전송한다(단계 S208).
이 경우, 판매업체측 컴퓨터(2a)는 대금 관리 서버(10)로부터 전송되는 대출 신청 내역 입력 메시지(617)를 신속히 해석하여, 이를 도 11에 도시된 바와 같이, 디스플레이 시킴으로써, 판매업체(500)가 일련의 대출 신청 과정을 신속하게 진행시킬 수 있는 안정적인 기반환경을 제공받도록 한다.
이 상태에서, 대금 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 판매업체측 컴퓨터(2a)로부터 일련의 대출 신청 정보가 전송되었는가의 여부를 판단한다(단계 S209).
이때, 판매업체(500)측에서, 아직, 대출 신청 내역 입력과정을 완료하지 않아, 판매업체측 컴퓨터(2a)로부터 일련의 대출 신청 정보가 전송되지 않은 것으로 판단되면, 대금 관리 서버(10)는 플로우를 단계 S210으로 진행하여, 일련의 대기 상태를 유지한다.
그러나, 판매업체(500)측에서, 대출 신청 내역 입력과정을 모두 완료하고, 예컨대, 전송 항목을 클릭하여, 판매업체측 컴퓨터(2a)로부터 일련의 대출 신청 정보가 전송된 것으로 판단되면, 대금 관리 서버(10)는 대출 신청 정보에 기록된 대출 신청 금액이 기 지정된 채권 잔액 한도 이내인가의 여부를 판단한다(단계 S211).
이때, 대출 신청 정보에 기록된 대출 신청 금액이 기 지정된 채권 잔액을 초과하는 경우, 대금 관리 서버(10)는 일련의 오류 메시지를 판매업체측 컴퓨터(2a)로 전송하는 과정을 진행한다(단계 S212).
이 경우, 대금 관리 서버(10)는 운영정보 관리 모듈(60)을 활용하여, 운영정보 D/B(85)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 예컨대, "신청하신 금액이 채권 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 판매업체측 컴퓨터(2a)로 전송한다.
그러나, 대출 신청 정보에 기록된 대출 신청 금액이 기 지정된 채권 잔액 한도 이내의 금액인 경우, 대금 관리 서버는 일련의 "대출금"을 구매업체(400)를 대신하여, 판매업체(500)측에게 미리 선 지급하는 과정을 진행한다(단계 S213).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 "대출금"의 선 지급을 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 일정액의 현금을 예컨대, 시스템측 지정계좌(92)로부터 판매업체측 지정계좌(93)로 입 금시키게 되고, 결국, 구매업체(400)를 대상으로 일련의 물품, 용역 등을 판매한 판매업체(500)는 "자사에서 판매한 물품, 용역" 등에 상응하는 일련의 "대출금"을 온라인 상에서 손쉽게 선 입금 받을 수 있게 된다.
한편, 상술한 도 3에 도시된 바와 같이, 앞의 판매대금 선 지급 과정(단계 S200)이 마무리되면, 대금 관리 서버(10)는 구매대금 지불 명세표 관리 모듈(40)을 활용하여, 구매대금 지불 명세표 정보 D/B(82)에 저장된 구매대금 지불 명세표 정보를 추출하고, 이 구매대금 지불 명세표 정보를 체크하여, 해당 구매대금 지불 명세표 중, 당일 만기일 건이 있는가의 여부를 판단한다(단계 11).
이때, 구매대금 지불 명세표 중, 당일 만기일 건이 있는 경우, 대금 관리 서버(10)는 구매업체(400)측의 지정계좌(91)를 체크하여, 해당 구매업체의 구매자금을 결제하는 과정을 신속히 진행한다(단계 S300).
먼저, 도 12에 도시된 바와 같이, 대금 관리 서버(10)는 계좌 관리 모듈(90)을 제어하여, 당일 만기일 건에 해당하는 구매대금 지불 명세표를 발행한 구매업체(400)측의 지정계좌(91)를 면밀히 체크한다(단계 S301).
계속해서, 대금 관리 서버(10)는 당일 만기일 건이 앞의 단계 S207, S213 등의 진행에 의해 발생된 "선 지급 건"을 회수하는 "선 지급 회수 대상 건"인가의 여부를 판단한다(단계 S301a).
이때, 당일 만기일 건에 적시된 판매업체(500)가 앞의 경우와 같은 일련의 "판매대금 선 지급 신청 과정"을 진행하지 않은 일반 판매업체(500)여서, 당일 만기일 건이 앞의 경우와 같은 "선 지급 회수 대상 건"이 아닌 "일반 대상 건"인 것으 로 판단되는 경우, 대금 관리 서버(10)는 일련의 "일반 대상 건 처리 과정"을 신속히 진행한다(S301b). 참고로, 이러한 일반 대상 건 처리과정은 별도의 도면 없이도, 당업자에게 손쉽게 이해될 수 있기 때문에, 앞의 도 12에는 이를 상세히 도시하지 않았다.
먼저, 대금 관리 서버(10)는 해당 일반 대상 건이 매출채권 명세표 대상 건인가의 여부를 판단한다.
이때, 해당 일반 대상 건이 매출채권 명세표 대상 건이 아닌 것으로 판단되는 경우, 대금 관리 서버(10)는 해당 일반 대상 건이 "신용카드 매출표 대상 건"인 것으로 판정하고, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "신용카드 매출표 매입대금액" 이상인가의 여부를 재차 판단한다.
여기서, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "신용카드 매출표 매입대금액" 미만인 것으로 판단되는 경우, 대금 관리 서버(10)는 은행(300)측과 신용카드 차주 관계에 있는 해당 구매업체(400)를 연체 처리함과 아울러, 판매업체(500)측이 수금하여야할 "신용카드 매출표 매입대금액"을 구매업체측 대신 판매업체(500)측에 지급하여 준다.
그러나, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "신용카드 매출표 매입대금액" 이상인 것으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(91)에 기 입금되어 있는 적정 잔여액을 해당 판매업체(500)측 지정계좌(93)로 입금시키는 과정을 진행하게 되며, 결국, 판매업체(500)는 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있게 된다.
한편, 앞의 "해당 일반 대상 건"이 "매출채권 명세표 대상 건"인가의 여부를 판단하는 단계에서, 해당 일반 대상 건이 "매출채권 명세표 대상 건"으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "매출채권 명세 금액" 이상인가의 여부를 재차 판단한다.
이때, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "매출채권 명세 금액" 미만인 것으로 판단되는 경우, 대금 관리 서버(10)는 플로우를 종료한다.
그러나, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "매출채권 금액" 이상인 것으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(91)에 기 입금되어 있는 적정 잔여액을 해당 판매업체(500)측 지정계좌(93)로 입금시키는 과정을 진행하게 되며, 결국, 판매업체(500)는 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있게 된다.
한편, 앞의 단계 S301a에서, 당일 만기일 건이 앞의 경우와 같은 선 지급 회수 대상 건인 것으로 판단되는 경우, 대금 관리 서버(10)는 해당 "선 지급 회수 대상 건"이 앞의 단계 S213에 의해 진행된 "대출금 선 지급 대금"을 구매업체(400)로부터 회수하는 건인가의 여부를 판단한다(단계 S302).
이때, "당일 만기일 건"이 "대출금 선 지급 대금 회수 대상 건"이 아닌 것으로 판단되는 경우, 대금 관리 서버는 해당 "선 지급 회수 대상 건"이 앞의 단계 S207에 의해 진행된 "신용카드 매출표 매입 대금 선 지급 대금"을 구매업체(400)로부터 회수하는 건인 것으로 판단하고, 선 지급금 회수 관리 모듈(50)을 통해, 신용카드 매출표 매입대금 선 지급 정보를 추출한 후, 이 신용카드 매출표 매입대금 선 지급 정보를 활용하여, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "신용카드 매출표 매입대금 선 지급 금액" 이상인가의 여부를 판단한다(단계 S303).
이때, 도 13a에 도시된 바와 같이, 신용카드 매출표 매입대금 선 지급 금액이 200인데 반해, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 100 이어서, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "신용카드 매출표 매입대금 선 지급 금액" 미만인 것으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(91)에 기 입금되어 있는 100을 회수함과 아울러, 은행(300)측과 신용카드 차주 관계에 있는 해당 구매업체(400)를 그 차액, 즉, 100만큼 연체 처리하는 과정을 진행한다(단계 S304).
이 경우, 대금 관리 서버(10)는 운영 모듈(60)로 "해당 구매업체(400)를 연체 처리하라"는 메시지를 전달하게 되며, 운영 모듈(30)은 이러한 메시지가 전달되는 즉시, 등록정보 D/B(86)에 저장되어 있는 해당 구매업체(400)의 등록정보를 변경시킴으로써, 이후, 해당 구매업체(400)가 연체업체로 분류·관리될 수 있도록 한다.
그러나, 도 13b에 도시된 바와 같이, 신용카드 매출표 매입대금 선 지급 금액이 50인데 반해, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 120이어서, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "신용카드 매출표 매입대금 선 지급 금액" 이상인 것으로 판단되는 경우, 대금 관리 서버(10)는 은행(300)측이 선 지급한 "신용카드 매출표 매입대금 선 지급 금액"을 정상적으로 회수하는 과정을 진행한다(단계 S305).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액의 회수를 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 구매업체(400)측의 보유 대금, 예컨대, 120 중 50을 구매업체측 지정계좌(91)로부터 시스템측 지정계좌(92)로 입금시키게 되고, 결국, 은행(300)은 상술한 "신용카드 매출표 매입대금 선 지급과정"을 통해 선 지급한 대금을 손쉽게 회수할 수 있게 된다.
상술한 과정을 통해, "신용카드 매출표 매입대금 선 지급 금액"의 회수과정이 마무리되면, 대금 관리 서버(10)는 구매업체(400)측의 보유대금 중, 앞의 "신용카드 매출표 매입대금 선 지급 금액"을 차감한 나머지 적정 잔여액을 판매업체측 지정계좌(93)로 입금시키는 과정을 진행한다(단계 S309).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계좌(91)에 기 입금되어 있는 나머지 적정 금액의 이체를 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 구매업체(400)측의 나머지 보유 대금, 예컨대, 70 중 "판매업체(500)의 잔여 채권 금액"인 50 만큼을 구매업체측 지정계좌(91)로부터 판매업체측 지정계좌(93)로 입금시키게 되고, 결국, 판매업체(500)는 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있게 된다.
한편, 앞의 단계 S302에서, "선 지급 회수 대상 건"이 "매출채권 명세표에 의한 대출금 선 지급 대금 회수 대상 건"인 것으로 판단되는 경우, 대금 관리 서버(10)는 선 지급금 회수 관리 모듈(50)을 통해, 대출금 선 지급 정보를 추출한 후, 이 대출금 선 지급 정보를 활용하여, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 대출금 선 지급 금액 이상인가의 여부를 판단한다(단계 S306).
이때, 도 13c에 도시된 바와 같이, 대출금 선 지급 금액이 200인데 반해, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 100 이어서, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "대출금 선 지급 금액" 미만인 것으로 판단되는 경우, 대금 관리 서버(10)는 구매업체측의 지정계좌(91)에 기 입금되어 있는 100을 회수함과 아울러, 은행(300)측과 대출금 차주 관계에 있는 해당 판매업체(500)를 그 차액, 즉, 100만큼 연체 처리하는 과정을 진행한다(단계 S307).
이 경우, 대금 관리 서버(10)는 운영 모듈(60)로 "해당 판매업체(500)를 연체 처리하라"는 메시지를 전달하게 되며, 운영 모듈(60)은 이러한 메시지가 전달되는 즉시, 운영정보 D/B(86)에 저장되어 있는 해당 판매업체(500)의 등록정보를 변경시킴으로써, 이후, 해당 판매업체(500)가 연체업체로 분류·관리될 수 있도록 한다.
그러나, 도 13d에 도시된 바와 같이, 대출금 선 지급 금액이 50인데 반해, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 120이어서, 구매업체측의 지정계좌(91)에 기 입금되어 있는 금액이 "대출금 선 지급 금액" 이상인 것으로 판단되는 경우, 대금 관리 서버(10)는 은행(300)측이 선 지급한 "대출금 선 지급 금액"을 회수하는 과정을 진행한다(단계 S308).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계 좌(91)에 기 입금되어 있는 금액의 회수를 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 구매업체(400)측의 보유 대금, 예컨대, 120 중 50을 구매업체측 지정계좌(91)로부터 시스템측 지정계좌(92)로 입금시키게 되고, 결국, 은행(300)은 상술한 "대출금 선 지급과정"을 통해 선 지급한 대금을 손쉽게 회수할 수 있게 된다.
상술한 과정을 통해, "대출금 선 지급 금액"의 회수과정이 마무리되면, 대금 관리 서버(10)는 구매업체(400)측의 보유대금 중, 앞의 "대출금 선 지급 금액"을 차감한 나머지 적정 잔여액을 판매업체측 지정계좌(93)로 입금시키는 과정을 진행한다(단계 S309).
이 경우, 대금 관리 서버(10)는 계좌 관리 모듈(90)로 구매업체측의 지정계좌(90)에 기 입금되어 있는 나머지 금액의 이체를 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 구매업체(400)측의 나머지 보유 대금, 예컨대, 70 중 "판매업체(500)의 잔여 채권 금액"인 50만큼을 구매업체측 지정계좌(91)로부터 판매업체측 지정계좌(93)로 입금시키게 되고, 결국, 판매업체는 자사가 판매한 물품, 용역 등에 대한 판매대금을 모두 수금할 수 있게 된다.
이후, 대금 관리 서버(10)는 구매업체측 통신 클라이언트(1) 또는 판매업체측 통신 클라이언트(2) 등으로부터 일련의 구매대금 지불 명세표 관리 이벤트, 판매대금 선 지급 신청 이벤트 등이 발생될 때마다, 상술한 인증모듈(30), 구매대금 지불 명세표 관리모듈(40), 선 지급금 회수 관리 모듈(50), 운영정보 관리모듈(60), 계좌 관리모듈(90) 등을 긴밀하게 연계시켜, 일련의 구매대금 지불 명세표 관리 과정, 판매대금 선 지급 관리 과정 등을 체계적으로 진행시킴으로써, 임의의 구매업체, 판매업체 등이 은행 온라인망을 기반으로 하여, 신뢰성 있는 대금결제 관계를 손쉽게 형성할 수 있도록 한다.
이상에서 상세히 설명한 바와 같이, 본 발명에서는 은행 온라인망을 기반으로, 판매업체가 구매업체를 상대로 취득한 장래의 매출채권을 판매업체로부터 양도받고, 이를 담보로, 구매업체가 지불하여야할 구매대금을 온라인 상에서 미리 선 지급해 줌으로써, 해당 구매업체가 판매업체를 대상으로 하는 일련의 대금 결제관계를 별다른 자금 부담 없이 좀더 손쉽게 형성할 수 있도록 유도할 수 있다.
또한, 본 발명에서는 구매업체에 의한 종래의 어음 사용을 미리 배제시키고, 이를 통해, 판매업체 및 구매업체 사이에 형성되는 대금 결제관계의 신뢰성을 대폭 향상시킴으로써, 예측하지 못한 판매업체의 피해를 최소화시킬 수 있다.
또한, 본 발명에서는 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 온라인 상에서 체계적으로 구현함으로써, 판매업체 및 구매업체가 온라인 상에서, 자사에 필요한 판매대금 수금과정, 구매대금 지불과정을 좀더 손쉽게 진행시킬 수 있도록 유도할 수 있다.
또한, 본 발명에서는 구매업체 및 판매업체 사이에 형성되는 대금 결제관계의 신뢰성을 향상시킴으로써, 여러 업체의 연쇄 부도에 따른 경제적인 피해를 최소화시킬 수 있다.
앞에서, 본 발명의 특정한 실시예가 설명되고 도시되었지만 본 발명이 당업 자에 의해 다양하게 변형되어 실시될 가능성이 있는 것은 자명한 일이다.
이와 같은 변형된 실시예들은 본 발명의 기술적사상이나 관점으로부터 개별적으로 이해되어서는 안되며 이와 같은 변형된 실시예들은 본 발명의 첨부된 특허청구의 범위안에 속한다 해야 할 것이다.

Claims (16)

  1. 일련의 인증정보가 저장된 인증정보 D/B(Data Base), 일련의 구매대금 지불 명세표 정보가 저장된 구매대금 지불 명세표 정보 D/B, 일련의 대출금 선 지급 정보가 저장된 대출금 선지급 정보 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. 제 9 항에 있어서, 상기 판매대금 선 지급 과정을 진행하는 단계는 상기 판매업체측 통신 클라이언트로부터 매출채권 명세표에 의한 일련의 대출 신청 이벤트가 발생하였는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 매출채권 명세표에 의한 일련의 대출 신청 이벤트가 발생한 경우, 해당 대출 신청 내역을 입력할 수 있는 일련의 대출 신청 내역 입력 메시지를 상기 판매업체측 통신 클라이언트로 전송하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 대출 신청 내역 입력 메시지에 대응되는 대출 신청 정보가 전송되었는가의 여부를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 대출 신청 내역 입력 메시지에 대응되는 대출 신청 정보가 전송된 경우, 상기 대출 신청 정보에 기록된 대출 신청금액이 기 지정된 채권 잔액 이내인가의 여부를 판단하는 단계와;
    상기 대출 신청 정보에 기록된 대출 신청금액이 기 지정된 채권 잔액 이내인 경우, 해당 대출 신청금액을 선 지급하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  11. 제 10 항에 있어서, 상기 대출 신청 이벤트가 발생하지 않은 경우, 판매업체측의 신용카드 매출표 매입신청 내역을 입력할 수 있는 일련의 신용카드 매출표 매입신청 내역 입력 메시지를 상기 판매업체측 통신 클라이언트로 전송하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출표 매입신청 내역 입력 메시지에 대응되는 신용카드 매출표 매입신청 정보가 전송되었는가의 여부 를 판단하는 단계와;
    상기 판매업체측 통신 클라이언트로부터 상기 신용카드 매출표 매입신청 내역 입력 메시지에 대응되는 신용카드 매출표 매입신청 정보가 전송된 경우, 상기 신용카드 매출표 매입신청 정보에 기록된 신용카드 매출표 매입신청 금액이 기 지정된 채권 잔액 이내인가의 여부를 판단하는 단계와;
    상기 신용카드 매출표 매입신청 정보에 기록된 신용카드 매출표 매입신청 금액이 기 지정된 채권 잔액 이내인 경우, 해당 신용카드 매출표 매입 신청금액을 선 지급하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  12. 제 6 항에 있어서, 상기 구매대금 지불 명세표 관리 과정을 진행하는 단계 후에, 상기 구매대금 지불 명세표 중, 당일 만기일 건이 있는가의 여부를 판단하는 단계와;
    상기 구매대금 지불 명세표 중, 당일 만기일 건이 있는 경우, 상기 당일 만기일 건의 구매대금 지불 명세표를 발급한 해당 구매업체측의 지정계좌를 체크하여, 일련의 구매자금 결제과정을 관리하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  13. 제 12 항에 있어서, 상기 구매자금 결제과정을 관리하는 단계는 상기 당일 만기일 건이 선 지급 회수 대상 건인가의 여부를 판단하는 단계와;
    상기 당일 만기일 건이 선 지급 회수 대상 건인 경우, 해당 선 지급 회수 대 상 건이 매출채권 명세표에 의한 대출금 선 지급 대금 회수 대상 건인가의 여부를 판단하는 단계와;
    상기 선 지급 회수 대상 건이 상기 대출금 선 지급 대금 회수 대상 건인 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 대출금 선 지급 금액 이상인가의 여부를 판단하는 단계와:
    상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 대출금 선 지급 금액 이상인 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액으로부터 상기 대출금 선 지급 금액을 회수하고, 상기 대출금 선 지급 금액을 차감한 나머지 적정 잔여액을 판매업체측 지정계좌에 입금하는 단계를 포함하는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  14. 제 13 항에 있어서, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 상기 대출금 선 지급 금액 미만인 경우, 상기 판매업체를 연체 처리하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  15. 제 13 항에 있어서, 상기 선 지급 회수 대상 건이 매출채권 명세표에 의한 대출금 선 지급 대금 회수 대상 건이 아닌 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 신용카드 매출표 매입대금 선 지급 금액 이상인가의 여부를 판단하는 단계와;
    상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 신용카드 매출표 매 입대금 선 지급 금액 이상인 경우, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액으로부터 상기 신용카드 매출표 매입대금 선 지급 금액을 회수하고, 상기 신용카드 매출표 매입대금 선 지급 금액을 차감한 나머지 적정 잔여액을 판매업체측 지정계좌에 입금하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
  16. 제 15 항에 있어서, 상기 구매업체측의 지정계좌에 기 입금되어 있는 금액이 상기 신용카드 매출표 매입대금 선 지급 금액 미만인 경우, 상기 구매업체를 연체 처리하는 단계가 더 진행되는 것을 특징으로 하는 기업간 대금결제 관리 방법.
KR1020010006687A 2000-02-15 2001-02-12 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법 KR100542386B1 (ko)

Priority Applications (7)

Application Number Priority Date Filing Date Title
KR1020010006687A KR100542386B1 (ko) 2000-02-15 2001-02-12 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
US10/203,824 US20030014362A1 (en) 2000-02-15 2001-02-14 System for managing inter-company settlement and the method therefor
EP01908390A EP1257932A1 (en) 2000-02-15 2001-02-14 A system for managing inter-company settlement and the method therefor
CN01808075A CN1423783A (zh) 2000-02-15 2001-02-14 用于管理公司间的结算的系统及其方法
PCT/KR2001/000219 WO2001061532A1 (en) 2000-02-15 2001-02-14 A system for managing inter-company settlement and the method therefor
AU36134/01A AU3613401A (en) 2000-02-15 2001-02-14 A system for managing inter-company settlement and the method therefor
JP2001038848A JP2001283115A (ja) 2000-02-15 2001-02-15 企業間代金決済管理システム及びこれらを用いた企業間代金決済管理方法

Applications Claiming Priority (3)

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

Publications (2)

Publication Number Publication Date
KR20010082133A KR20010082133A (ko) 2001-08-29
KR100542386B1 true KR100542386B1 (ko) 2006-01-10

Family

ID=26637104

Family Applications (1)

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

Country Status (7)

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

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101173651B1 (ko) 2011-10-11 2012-08-13 김경록 주식전환권리가 부여되는 예금/적금 및 이를 통합관리하기위한 뱅킹시스템 및 그 제어방법

Families Citing this family (21)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
NZ516669A (en) * 1999-06-18 2004-07-30 Echarge Corp Method 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 주식회사 신한은행 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법
ES2374563T3 (es) * 2003-09-11 2012-02-17 Theranos, Inc. Dispositivo médico para la monitorización de analitos y la administración de fármacos.
KR100684967B1 (ko) * 2004-08-04 2007-02-20 전달용 판매 대금 결제 서비스 제공 방법 및 시스템
CN101535499B (zh) * 2005-05-09 2017-04-19 赛拉诺斯股份有限公司 点护理流体系统及其应用
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
AU2010308329B2 (en) 2009-10-19 2016-10-13 Labrador Diagnostics Llc Integrated health data capture and analysis system
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

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR960706141A (ko) * 1993-11-01 1996-11-08 베네트 알. 카츠 전자 어음 지불시스템(electronic bill pay system)
US5671280A (en) * 1995-08-30 1997-09-23 Citibank, N.A. System and method for commercial payments using trusted agents
JPH10207956A (ja) * 1997-01-27 1998-08-07 Hironori Wakayama 電子決済システム
US5920629A (en) * 1994-04-28 1999-07-06 Citibank, N.A. Electronic-monetary system
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
KR19990084123A (ko) * 1999-09-15 1999-12-06 손성배 인터넷 전자상점을 통하여 회원업체의 영업, 구매업무를대행하고 부수하여 금융, 물류, 정보를 제공하는통합물류회사 운영.
KR20000066430A (ko) * 1999-04-16 2000-11-15 김용훈 물품대금 결제방법

Family Cites Families (7)

* 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
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
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

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR960706141A (ko) * 1993-11-01 1996-11-08 베네트 알. 카츠 전자 어음 지불시스템(electronic bill pay system)
US5920629A (en) * 1994-04-28 1999-07-06 Citibank, N.A. Electronic-monetary system
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
JPH10207956A (ja) * 1997-01-27 1998-08-07 Hironori Wakayama 電子決済システム
KR20000066430A (ko) * 1999-04-16 2000-11-15 김용훈 물품대금 결제방법
KR19990084123A (ko) * 1999-09-15 1999-12-06 손성배 인터넷 전자상점을 통하여 회원업체의 영업, 구매업무를대행하고 부수하여 금융, 물류, 정보를 제공하는통합물류회사 운영.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101173651B1 (ko) 2011-10-11 2012-08-13 김경록 주식전환권리가 부여되는 예금/적금 및 이를 통합관리하기위한 뱅킹시스템 및 그 제어방법

Also Published As

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

Similar Documents

Publication Publication Date Title
KR100542386B1 (ko) 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
EP0791202B1 (en) Computerized payment system for purchasing information products by electronic transfer on the internet
US7328844B2 (en) Point-of-transaction machine with improved versatility and related method
US7783539B2 (en) Derivative currency-exchange transactions
US6994251B2 (en) Cash payment for remote transactions
US20070005467A1 (en) System and method for carrying out a financial transaction
US20030212796A1 (en) Loadable debit card system and method
US8286861B2 (en) Cash payment for remote transactions
US20050182720A1 (en) Online payment system and method
US20090327133A1 (en) Secure mechanism and system for processing financial transactions
US20030061156A1 (en) Instant settlement system and method for credit card member stores
JP2002530757A5 (ko)
KR20020006625A (ko) 중간계정을 이용하는 전자 지불 시스템
US20080195497A1 (en) Unit-Based Prepaid Presentation Instrument Accounts And Methods
EA010957B1 (ru) Предварительно оплаченная платежная карточка, которая может немедленно дистанционно пополняться с помощью купона
KR100435854B1 (ko) 기업간 대금결제 관리 시스템 및 이를 이용한 기업간대금결제 관리 방법
KR100394527B1 (ko) 부가가치통신망을 이용한 전자 지불방법
JP2001297282A (ja) 決済管理システム
CA2592534C (en) Computerized payment system for purchasing information products by electronic transfer on the internet
WO2016028167A1 (en) A method and apparatus for facilitating payments
KR20040026194A (ko) 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법
KR100474189B1 (ko) 기업간 전자결제 관리 방법
JP2002074194A (ja) 通信販売代金決済システム
JP2002099863A (ja) 料金決済方法
GB2412777A (en) Electronic voucher system using mobile phones

Legal Events

Date Code Title Description
A201 Request for examination
E902 Notification of reason for refusal
E902 Notification of reason for refusal
E601 Decision to refuse application
J201 Request for trial against refusal decision
J301 Trial decision

Free format text: TRIAL DECISION FOR APPEAL AGAINST DECISION TO DECLINE REFUSAL REQUESTED 20040713

Effective date: 20051130

S901 Examination by remand of revocation
GRNO Decision to grant (after opposition)
GRNT Written decision to grant
FPAY Annual fee payment

Payment date: 20130103

Year of fee payment: 8

FPAY Annual fee payment

Payment date: 20140103

Year of fee payment: 9

FPAY Annual fee payment

Payment date: 20150105

Year of fee payment: 10

FPAY Annual fee payment

Payment date: 20151223

Year of fee payment: 11

FPAY Annual fee payment

Payment date: 20171220

Year of fee payment: 13

FPAY Annual fee payment

Payment date: 20190104

Year of fee payment: 14

FPAY Annual fee payment

Payment date: 20200102

Year of fee payment: 15