KR20040026194A - 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법 - Google Patents

Abstract

본 발명은 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법에 관한 것으로, 본 발명에서는 임의의 판매업체측으로부터 물품, 용역 등을 구매한 구매업체를 대상으로 하여, 일련의 구매자금 결제전용 대출(대출한도 공여)을 시행하고, 이를 근거로, 구매업체가 지불하여야할 구매대금의 일부 또는 전부가 은행 온라인망 상에서 대출금 만기일 이전에 각 판매업체들에게 대출채권금(만기일이 있는 대출채권) 형태로 선 지급될 수 있도록 유도함으로써, 구매업체-판매업체 사이에 형성되는 대금결제관계의 신속성, 신뢰성 등을 대폭 향상시킨다.

이러한 본 발명이 구현되는 경우, 구매업체-판매업체에서는 온라인 상에서, 서로의 대금결제관계를 보증 받을 수 있는 일련의 보증체계를 손쉽게 제공받을 수 있기 때문에, 결국, 본 발명이 달성되는 경우, 각 구매업체-판매업체에서는 대금결제관계의 파기에 따른 예측하지 못한 피해를 미리 피할 수 있게 된다.

Description

은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법{Method for managing a payment relation between the enterprises based on the on-line banking network}

본 발명은 기업간 대금결제 관리 방법에 관한 것으로, 좀더 상세하게는 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 은행 온라인망을 기반으로 체계적으로 구현함으로써, 판매업체 및 구매업체가 자사에 필요한 판매대금 수금과정, 구매대금 지불과정 등을 좀더 신뢰성 있게 진행시킬 수 있도록 유도할 수 있는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법에 관한 것이다.

최근, 경제 발전의 속도가 가속화되면서, 기업간의 거래 빈도수 또한 뚜렷한 증가추세를 나타내고 있으며, 이러한 기업간 거래의 증가 추세에 맞추어, 판매업체 및 구매업체 사이의 대금결제 관계 또한 중요한 사회적 이슈로 등장하고 있다.

이와 같이, 판매업체 및 구매업체 사이의 대금결제 관계가 중요한 사회적 이슈로 등장할 수밖에 없는 이유는 만약, 판매업체 및 구매업체 사이의 대금결제 관계가 신뢰성 있게 이루어지지 못하여, 개별 기업이 도산하는 경우, 국가의 기간 경제질서가 파괴되고, 그 파급효과에 의해 전체적인 사회질서가 무너지는 심각한 문제점이 야기될 수 있기 때문이다.

상술한 기업간 거래관계가 형성될 때, 통상, 일련의 물품, 용역 등을 판매한 판매업체에서는 구매업체를 대상으로, 일련의 대금청구 과정을 진행하는 것이 일반적인데, 종래의 경우, 대부분의 구매업체에서는 현금(Cash) 보다는 어음(Bill)을 대금 결제의 중요한 수단으로 선호하고 있다. 이는 대금 결제의 수단으로 어음을 활용하는 경우, 해당 구매업체에서는 전체적인 자금회전을 현금 결제에 비해, 좀더 융통성 있게 진행시킬 수 있는 이점을 손쉽게 획득할 수 있기 때문이다.

그러나, 앞서 언급한 종래의 실물어음은 일련의 "교부‥추심‥" 등의 복잡한 과정을 거쳐 발행되는 것이 일반적이기 때문에, 이 어음이 주요 결제수단으로 사용되는 경우, "구매업체 및 판매업체" 양측에서는 공히 예측하지 못한 큰 불편함을 감수할 수밖에 없게 된다. 더욱이, 이러한 실물어음은 오프라인(Off-line)상에서 유통되는 것이 일반적이기 때문에, 항상 도난, 분실 등의 위험성을 내포하고 있으며, 이를 사용하는 "구매업체 및 판매업체"에서는 항상 필요이상의 주의를 기울여야 하는 불편함을 감수할 수밖에 없게 된다.

또한, 앞서 언급한 어음은 그 발행일과 실질적인 현금 지불일이 서로 상이한 특성을 갖고 있기 때문에, 구매업체로부터 어음을 발급 받은 판매업체는 항상 "구매대금이 지불되지 못할 수도 있는 위험성"을 감수할 수밖에 없으며, 만약, 이 위험성이 현실화되어, 어음을 발생한 구매업체가 실질적인 "구매대금 지불과정"을 이행하지 못한 상태에서, 갑자기 도산하는 경우, 판매업체는 자신의 의사와 무관하게 막대한 피해를 입을 수밖에 없게 된다.

이때, 해당 판매업체가 다른 업체와 또 다른 대금결제 관계를 맺고 있는 경우, 구매업체의 도산은 다른 여러 판매업체들의 연쇄부도로 이어질 수밖에 없으며, 이를 방치하는 경우, 전체적인 경제질서가 급격히 무너지는 심각한 사회문제가 야기될 수밖에 없게 된다.

따라서, 본 발명의 목적은 임의의 판매업체측으로부터 물품, 용역 등을 구매한 구매업체를 대상으로 하여, 일련의 구매자금 결제전용 대출(대출한도 공여)을 시행하고, 이를 근거로, 구매업체가 지불하여야할 구매대금의 일부 또는 전부가 은행 온라인망 상에서 각 판매업체들에게 대출채권금(만기일이 있는 대출채권) 형태로 선 지급될 수 있도록 유도함으로써, 구매업체-판매업체 사이에 형성되는 대금결제관계의 신속성, 신뢰성 등을 대폭 향상시키는데 있다.

본 발명의 다른 목적은 구매업체에 의한 종래의 어음 사용을 미리 배제하고, 이를 통해, 판매업체 및 구매업체 사이에 형성되는 대금 결제관계의 신뢰성을 대폭 향상시킴으로써, 예측하지 못한 판매업체의 피해를 최소화시키는데 있다.

본 발명의 또 다른 목적은 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 온라인 상에서 체계적으로 구현함으로써, 판매업체 및 구매업체가온라인망을 기반으로, 자사에 필요한 판매대금 수금과정, 구매대금 지불과정을 불필요한 도난, 분실 등의 위험성 없이 좀더 손쉽게 진행시킬 수 있도록 유도하는데 있다.

본 발명의 또 다른 목적은 구매업체 및 판매업체 사이에 형성되는 대금 결제관계의 신뢰성을 향상시킴으로써, 여러 업체의 연쇄 부도에 따른 경제적인 피해를 최소화시키는데 있다.

본 발명의 또 다른 목적들은 다음의 상세한 설명과 첨부된 도면으로부터 보다 명확해질 것이다.

도 1은 본 발명이 채용된 기업간 대금결제 관계를 개념적으로 도시한 예시도.

도 2는 본 발명의 기반환경을 이루는 기업간 대금결제 관리 시스템을 개념적으로 도시한 예시도.

도 3은 본 발명의 일실시예에 따른 기업간 대금결제 관리 방법을 순차적으로 도시한 순서도.

도 4 및 도 5는 본 발명의 일실시예에 따른 구매업체측 클라이언트 및 판매업체측 클라이언트의 초기 페이지 게시상태를 개념적으로 도시한 예시도.

도 6은 본 발명의 일실시예에 따른 구매대금 결제내역 관리과정을 순차적으로 도시한 순서도.

도 7은 본 발명의 일실시예에 따른 구매업체측 클라이언트의 구매대금 결제내역 입력 가이드 페이지 게시상태를 개념적으로 도시한 예시도.

도 8은 본 발명의 일실시예에 따른 대출채권금 선 지급 신청과정을 순차적으로 도시한 순서도.

도 9는 본 발명의 일실시예에 따른 판매업체측 클라이언트의 대출채권금 선 지급 신청내역 입력 가이드 페이지 게시상태를 개념적으로 도시한 예시도.

도 10은 본 발명의 일실시예에 따른 대출금 회수과정을 순차적으로 도시한 순서도.

도 11a 및 도 11b는 본 발명의 일실시예에 따른 구매업체측 지정계좌의 입금상태를 개념적으로 도시한 예시도.

도 11c 및 도 11d는 본 발명의 일실시예에 따른 판매업체측의 대출채권금 수급상황을 개념적으로 도시한 예시도.

상기와 같은 목적을 달성하기 위하여 본 발명에서는 은행 온라인망에 소속된 대금결제 관리 서버가 해당 은행과 구매대금 결제전용 대출을 약정한 구매업체측에 의해 관리되는 구매업체측 클라이언트 및 이 구매업체측과 거래관계에 있는 판매업체측에 의해 관리되는 판매업체측 클라이언트를 대상으로 진행하는 과정으로 이루어지는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법을 개시한다.

이러한 본 발명의 체제 하에서, 대금결제 관리 서버는 구매업체측 클라이언트 또는 판매업체측 클라이언트 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생하였는가의 여부를 판단하는 단계와, 구매업체측 클라이언트 또는 판매업체측 클라이언트 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생한 경우, 해당 클라이언트를 통해 접속 중인 업체의 등록여부를 판단하는 단계와, 해당 업체가 등록업체인 것으로 판단되는 경우, 해당 등록업체가 일련의 대출절차를 미리 밟은 구매업체인가의 여부를 판단하는 단계와, 해당 등록업체가 대출절차를 미리 밟은 구매업체로 판단되는 경우, 일련의 구매업체용 초기 페이지를 생성하고, 생성이 완료된 구매업체용 초기 페이지를 구매업체측 클라이언트로 전송하는 단계와, 구매업체측 클라이언트로부터 일련의 구매대금 결제내역 관리 이벤트가 발생하였는가의 여부를 판단하는 단계와, 구매업체측 클라이언트로부터 일련의 구매대금 결제내역 관리 이벤트가 발생한 경우, 구매업체측 클라이언트로부터 전송되는 구매대금 결제내역 정보를 참조하여, 구매업체측의 구매대금 결제내역을 관리하는 단계를 시계열적으로 진행한다.

이하, 첨부된 도면을 참조하여, 본 발명에 따른 기업간 대금결제 관리 시스템 및 이를 이용한 기업간 대금결제 관리 방법을 좀더 상세히 설명하면 다음과 같다.

도 1에 도시된 바와 같이, 본 발명의 기반환경을 이루는 기업간 대금결제 관리 시스템(100)은 구매업체(400) 및 다수의 판매업체들(500) 사이의 대금 결제관계를 신뢰성 있게 관리 할 수 있는 특정 금융기관, 예컨대, 은행(300)의 전산 온라인망에 소속된다.

이때, 본 발명의 기업간 대금결제 관리 시스템(100)을 보유한 은행(300)측에서는 본 발명에 의한 서비스가 본격적으로 실시되기 이전에, 미리 구매업체(400)측과, 일정 한도 및 만기일을 갖는 "구매대금 결제전용 대출금 약정"을 미리 체결함으로써, 본 발명에 의한 기업간 대금결제 관리 방법이 안정적으로 시행될 수 있는 기반환경을 마련한다. 물론, 이러한 구매대금 결제전용 대출금의 전체적인 한도는일반 대출금의 경우와 마찬가지로, 각 구매업체(400)의 신용도에 따라, 다양한 변형을 이룰 수 있다.

이러한 기반환경이 갖추어진 상태에서, 구매업체(400)는 앞의 구매대금 결제전용 대출금을 토대로 하여, 일련의 전자어음(Electrical bill)을 발행함으로써, 판매업체측으로부터 자사가 원하는 상품을 판매업체(500)들로부터 구매할 수 있게 된다. 이 경우, 각 구매업체(400)와 거래관계를 맺은 판매업체(500)측은 전자어음에 상응하는 대출채권을 획득할 수 있게 된다.

추후, 구매업체(400)는 시스템(100)측으로, "자사가 판매업체(500)측에 지불하여야할 구매대금을 각 대출금 한도 내에서, 판매업체(500)측에 대신 지급해달라"는 주문을 할 수 있으며, 결국, 각 구매업체(400)측에서는 해당 대출금을 "판매업체(500)측으로부터 구매한 상품의 구매대금을 결제하는 용도"로 활용할 수 있다.

이때, 은행(101)측에서는 대출금을 지원 받은 구매업체(400)와 별도의 구매업체 약정, 예컨대, "구매대금 결제전용 대출금 약정"을 미리 체결함과 아울러, 판매업체(500)측과 별도의 판매대금 지급대행을 위한 약정, 예컨대, "연지급 결제 약정"을 미리 체결함으로써, 본 발명이 구현될 수 있는 법적인 근거를 마련한다.

이 상태에서, 구매업체(400)를 대상으로 하는 일련의 서비스가 원활하게 제공되기 위해서는 앞서 언급한 "구매대금 결제전용 대출금 약정" 사항이 시스템(100)측에 미리 저장되어 있어야 하며, 이와 동일하게, 판매업체(500)를 대상으로 하는 일련의 서비스가 원활하게 제공되기 위해서는 앞서 언급한 "연지급 결제 약정" 사항이 시스템(100)측에 미리 저장되어 있어야 한다. 물론, 이러한 각 약정을 미리 체결하지 않은 구매업체(400), 판매업체(500) 등은 등록된 업체로 인증 받을 수 없으며, 결국, 본 발명에 의한 일련의 서비스를 향유할 수 없다.

이러한 본 발명의 체제 하에서, 도 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), 일련의 구매업체(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)는 임의의구매업체측 클라이언트(1), 판매업체측 클라이언트(2) 등과 예컨대, 인터페이스 모듈(20)을 매개로 인터페이스 한다.

이 경우, 임의의 구매업체측 클라이언트(1)와, 판매업체(500)측 클라이언트(2)는 일련의 은행 온라인망, 예컨대, 인터넷망, 인터넷 뱅킹망, 자동응답 통신망(Automatic Response System communication network), 부가가치통신망(VAN:Value Added Network), 공중전화망(PSTN:Public Switched Telephone Network) 등을 이용하여 본 발명의 기업간 대금결제 관리 시스템(100)에 접속한다.

이 상태에서, 대금결제 관리 서버(10)는 인증모듈(30), 구매대금 결제내역 관리모듈(40), 운영정보 관리 모듈(50) 등을 매개로, D/B 관리 서버(70)를 체계적으로 제어하여, 상술한 인증정보, 구매대금 결제내역 정보, 대출채권금 선 지급 정보, 운영정보, 등록정보 등의 저장 및 추출 여부를 결정하는 역할을 수행한다.

이와 함께, 대금결제 관리 서버(10)는 상술한 구매업체측 클라이언트(1) 및 판매업체측 클라이언트(2)로부터 일련의 구매대금 결제내역 관리 이벤트 및 대출채권금 선 지급 신청 이벤트가 발생하는 경우, 상술한 인증정보, 구매대금 결제내역 정보, 대출채권금 선 지급 정보, 구매기업/판매기업 등록정보를 체계적으로 조합하여, 구매업체측 클라이언트(1)로부터 전송되는 구매대금 결제내역 정보를 저장·관리하는 역할을 수행함과 아울러, 구매업체(400)측이 지불하여야할 대출채권금을 판매업체(500)측에게 온라인으로 선 지급하는 역할을 수행하고, 소정 기일이 경과한 후, 구매업체(400)측에 대출해준 대출금을 온라인으로 회수하는 역할을 수행한다.

이때, 상술한 인증모듈(30)은 구매업체측 클라이어트(1), 판매업체측 클라이어트(2) 등을 통해 본 발명의 기업간 대금 결제 관리 시스템(100)에 접근하는 임의의 "구매업체(400), 판매업체(500)"의 기 등록여부를 앞의 인증정보 D/B(81)를 활용하여, 인증하는 역할을 전담하며, 구매대금 결제내역 관리모듈(40)은 구매업체측 클라이어트(1)로부터 전송되는 구매대금 결제내역 정보를 앞의 구매대금 결제내역 정보 D/B(82)를 활용하여 관리하는 역할을 전담한다.

또한, 운영정보 관리 모듈(50)은 대금결제 관리 서버(10)의 세부 운영사항을 앞의 운영정보 D/B(84), 등록정보 D/B(86) 등을 활용하여 관리하는 역할을 전담한다.

이때, 도면에 도시된 바와 같이, 계좌 관리 모듈(90)은 앞의 인증모듈(30), 구매대금 결제내역 관리모듈(40), 운영정보 관리 모듈(50) 등과 유사하게 대금결제 관리 서버(10)와 긴밀한 통신연결 관계를 형성한 상태에서, 시스템(100)측에 지정된 시스템측 지정계좌(92), 구매업체(400)측에 지정된 구매업체측 지정계좌(91), 판매업체(500)측에 지정된 판매업체측 지정계좌(93) 등을 관리하는 역할을 전담한다.

이하, 상술한 구성을 갖는 본 발명의 기업간 대금결제 관리 시스템(100)을 이용한 기업간 대금결제 관리 방법을 상세히 설명한다.

먼저, 소정의 물품, 용역 등을 구매한 구매업체(400) 또는 이 물품, 용역 등을 판매한 다수의 판매업체들(500)은 상술한 구매업체측 클라이어트(1) 및 판매업체측 클라이어트(2)를 이용하여, 본 발명의 기업간 대금결제 관리 시스템(100)에접속한다.

이러한 기반환경이 갖추어진 상태에서, 도 3에 도시된 바와 같이, 대금결제 관리 서버(10)는 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2) 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생하였는가의 여부를 판단한다(단계 S1).

이때, 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2)로부터 상술한 시스템 접속 이벤트가 발생하지 않은 것으로 판단되는 경우, 대금결제 관리 서버(10)는 플로우를 후술하는 단계 S12로 진행한다.

그러나, 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2) 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생한 경우, 대금결제 관리 서버(10)는 운영정보 관리 모듈(50)을 활용하여, 운영정보 D/B(80)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 일련의 인증 요구 메시지를 생성하고, 생성이 완료된 인증 요구 메시지를 시스템 접속 이벤트를 발생시킨 해당 클라이언트로 전송한다(단계 S2).

만약, 구매업체측 클라이언트(1)로부터 시스템 접속 이벤트가 발생한 경우, 이 인증요구 메시지는 구매업체측 클라이언트(1)로 전송되며, 반대의 경우로, 판매업체측 클라이언트(2)로부터 시스템 접속 이벤트가 발생한 경우, 이 인증요구 메시지는 판매업체측 클라이언트(2)로 전송된다.

이 경우, 예컨대, 구매업체측 클라이언트(1)는 대금결제 관리 서버(10)로부터 전송된 인증 요구 메시지를 해석하여, 이를 디스플레이 시킴으로써, 해당 구매업체(400)가 일련의 인증과정을 신속히 수행 받을 수 있도록 하며, 다른 예로, 판매업체측 클라이언트(2)는 대금결제 관리 서버(10)로부터 전송된 인증 요구 메시지를 해석하여, 이를 디스플레이 시킴으로써, 해당 판매업체(500)가 일련의 인증과정을 신속히 수행 받을 수 있도록 한다.

이 상태에서, 대금결제 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2)로부터 일련의 인증정보가 전송되었는가의 여부를 판단한다(단계 S3).

이때, 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2)로부터 별도의 인증정보가 전송되지 않은 것으로 판단되면, 대금결제 관리 서버(10)는 구매업체(400) 또는 판매업체(500)가 아직, 일련의 인증정보 입력과정을 완료하지 못한 것으로 판정하고, 플로우를 단계 S4로 진행하여, 일련의 대기상태를 유지한다.

그러나, 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2)로부터 일련의 인증정보가 전송된 것으로 판단되면, 대금결제 관리 서버(10)는 인증모듈(30)을 신속히 활용함으로써, 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2)를 통해 시스템(100)에 접속중인 구매업체(400) 또는 판매업체(500)가 기 등록된 업체인가의 여부를 판단한다(단계 S5).

이때, 시스템(100)에 접속 중인 업체가 등록된 업체가 아닌 것으로 판단되는 경우, 대금결제 관리 서버(10)는 예컨대, "귀사는 등록된 고객이 아니오니, 먼저, 등록해 주십시오" 등과 같은 내용의 등록 요구 메시지를 생성하고, 생성이 완료된 등록 요구 메시지를 해당 업체측 컴퓨터로 전송하는 과정을 진행한다(단계 S6).

그러나, 시스템(10)에 접속 중인 업체가 등록된 업체로 판단되는 경우, 대금결제 관리 서버(10)는 예컨대, 운영 정보 관리 모듈(50) 등을 활용하여, 등록정보 D/B(86)에 저장된 해당업체의 등록정보를 수집한 후, 해당 업체가 구매업체(400)인가 또는 판매업체(500)인가의 여부를 판단한다(단계 S7).

이때, 해당 업체가 구매업체(400)로 판단되는 경우, 대금결제 관리 서버(10)는 해당 구매업체의 등록정보가 반영된 일련의 구매업체용 초기 페이지를 생성하고, 생성이 완료된 구매업체용 초기 페이지를 구매업체측 클라이언트(1)로 전송한다(단게 S8).

이 경우, 구매업체측 클라이언트(1)는 이 구매업체용 초기 페이지(501)를 신속히 해석하여, 이를 도 4에 도시된 바와 같이 디스플레이 시킴으로써, 구매업체(400)에 의한 일련의 구매대금 결제내역 관리 과정이 원활하게 진행될 수 있는 기반환경을 제공한다.

여기서, 구매대금 결제내역은 은행(300)측과 일련의 대출금 약정을 체결한 구매기업(400)이 "어떠한 판매기업(500)에 대하여, 어떠한 물품(용역)의 구매대금을 언제 얼마로 지급할 것인가"를 표시하는 내역을 일컫는다.

이때, 도 4에 도시된 바와 같이, 구매업체측 클라이언트(1)의 구매업체용 초기 페이지(501)에는 예컨대, 구매대금 결제내역 전송 항목(502), 구매대금 결제내역 전송현황 조회 항목(503), 지급내역 조회 항목(504), 연체내역 조회 항목(505), 처리결과 조회 항목(506) 등이 구비되며, 구매업체(400)에서는 앞의 각 항목들을 선택적으로 클릭함으로써, 해당 항목을 실시간 확인/설정할 수 있다. 물론, 이러한각 항목들은 상황에 따라 다양한 변형을 이룰 수 있다.

한편, 앞의 과정에서, 해당 업체가 판매업체(500)로 판단되는 경우, 대금결제 관리 서버(10)는 해당 판매업체의 등록정보가 반영된 일련의 판매업체용 초기 페이지를 생성하고, 생성이 완료된 판매업체용 초기 페이지를 판매업체측 클라이언트(2)로 전송한다(단게 S10).

이 경우, 판매업체측 클라이언트(2)는 이 판매업체용 초기 페이지(507)를 신속히 해석하여, 이를 도 5에 도시된 바와 같이 디스플레이 시킴으로써, 판매업체(500)에 의한 일련의 대출채권금 선 지급 신청 과정이 원활하게 진행될 수 있는 기반환경을 제공한다.

이때, 도 5에 도시된 바와 같이, 판매업체측 클라이언트(2)의 판매업체용 초기 페이지(507)에는 예컨대, 대출채권금 선 지급 신청내역 조회 항목(508), 판매내역 조회 항목(509) 등이 구비되며, 판매업체(500)에서는 앞의 구매업체(400)의 경우와 유사하게, 각 항목들을 선택적으로 클릭함으로써, 해당 항목을 실시간 확인/설정할 수 있다. 물론, 이러한 각 항목들 또한 상황에 따라 다양한 변형을 이룰 수 있다.

이 상황에서, 판매업체(500)에서는 예컨대, 대출채권금 선 지급 신청 항목(610)을 선택하여, 일련의 대출채권금 선 지급 신청 정보를 생성할 수 있는 바, 이 경우, 대출채권금 선 지급 신청 정보는 일련의 물품, 용역 등을 판매한 판매기업(500)이 "대출금을 담보로, 해당 물품, 용역 등의 구매대금을 결제한 구매기업(400)"과 연계된 은행(300)을 대상으로 대출금의 만기일 이전에 자사 대출채권금의 선 지급을 요청하는 정보를 의미하며, 본 발명의 시스템(100)은 이러한 "대출채권금 선 지급 정보"를 토대로, 구매업체(400)가 구매한 물품(용역)에 상응하는 일정액의 대출채권금을 구매업체(400)를 대신하여, 예컨대, 대출금 만기일까지의 이자를 차감한 상태로, 미리 선 지급하게 되고, 결국, 판매업체(500)는 자신이 판매한 물품, 용역 등의 판매대금을 미리 수금할 수 있게 된다.

다른 한편, 상술한 과정을 통해, 구매업체측 클라이언트(1)에 일련의 구매업체용 초기 페이지(501)가 게시된 상태에서, 대금결제 관리 서버(10)는 해당 구매업체측 클라이언트(1)로부터 일련의 구매대금 결제내역 관리 이벤트가 발생하였는가의 여부를 판단한다(단계 S9).

이때, 구매업체측 클라이언트(1)로부터 별도의 구매대금 결제내역 관리 이벤트가 발생하지 않은 것으로 판단되면, 대금결제 관리 서버(10)는 플로우를 단계 S9a로 진행하여, 일련의 대기 상태를 유지한다.

그러나, 구매업체(400)측에서, 예컨대, 구매업체용 초기 페이지(501)의 구매대금 결제내역 전송 항목(502)을 클릭하여, 구매업체측 클라이언트(1)로부터 일련의 구매대금 결제내역 관리 이벤트가 발생한 경우, 대금결제 관리 서버(10)는 구매업체측 클라이언트(1)로부터 전송되는 구매대금 결제내역 정보를 참조하여, 일련의 구매대금 결제내역 관리 과정을 신속하게 진행하게 된다(단계 S100).

이와 유사하게, 대금결제 관리 서버는 판매업체측 클라이언트(2)에 일련의 판매업체용 초기 페이지(507)가 게시된 상태에서, 해당 판매업체측 클라이언트(2)로부터 일련의 대출채권금 선 지급 신청 이벤트가 발생하였는가의 여부를판단한다(단계 S11).

이때, 판매업체측 클라이언트(2)로부터 별도의 대출채권금 선 지급 신청 이벤트가 발생하지 않은 것으로 판단되면, 대금결제 관리 서버(10)는 플로우를 단계 S11a로 진행하여, 일련의 대기 상태를 유지한다.

그러나, 판매업체(400)측에서, 예컨대, 판매업체용 초기 페이지(507)의 대출채권금 선 지급 신청 항목(610)을 클릭하여, 판매업체측 클라이언트(2)로부터 일련의 대출채권금 선 지급 신청 이벤트가 발생한 경우, 대금결제 관리 서버(10)는 판매업체측 클라이언트(2)로부터 전송되는 대출채권금 선 지급 정보를 참조하여, 일련의 대출채권금 선 지급 과정을 신속히 진행하게 된다(단계 S200).

먼저, 상술한 구매대금 결제내역 관리 과정(단계 S100)을 상세히 설명한다.

앞서 언급한 바와 같이, 구매업체(400)측에서, 구매대금 결제내역의 전송을 선택한 상황 하에서, 도 6에 도시된 바와 같이, 우선, 대금결제 관리 서버(10)는 운영정보 관리 모듈(50)을 활용하여, 구매업체(400)측의 구매대금 결제내역 입력과정을 가이드 하기 위한 일련의 구매대금 결제내역 입력 가이드 페이지를 생성하고, 생성이 완료된 구매대금 결제내역 입력 가이드 페이지를 인터페이스 모듈(20)을 매개로 하여, 구매업체측 클라이언트(1)로 전송하는 과정을 진행한다(단계 S101).

이 경우, 구매업체측 클라이언트(1)는 대금결제 관리 서버(10)로부터 전송되는 구매대금 결제내역 입력 가이드 페이지(611)를 신속히 해석하여, 이를 도 7에 도시된 바와 같이, 디스플레이 시킴으로써, 구매업체(400)가 일련의 구매대금 결제내역 정보를 생성할 수 있는 안정적인 기반환경을 제공받도록 한다.

이 상태에서, 대금결제 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 구매업체측 클라이언트(1)로부터 일련의 구매대금 결제내역 정보가 전송되었는가의 여부를 판단한다(단계 S102).

이때, 구매업체(400)측에서, 아직, 구매대금 결제내역 정보입력과정을 완료하지 않아, 구매업체측 클라이언트(1)로부터 일련의 구매대금 결제내역 정보가 전송되지 않은 것으로 판단되면, 대금결제 관리 서버(10)는 플로우를 단계 S103으로 진행하여, 일련의 대기 상태를 유지한다.

그러나, 구매업체(400)측에서, 구매대금 결제내역 정보 입력과정을 모두 완료하고, 예컨대, 전송 항목(612)을 클릭하여, 구매업체측 클라이언트(1)로부터 일련의 구매대금 결제내역 정보가 전송된 것으로 판단되면, 대금결제 관리 서버(10)는 이 구매대금 결제내역 정보의 타당성 여부, 예컨대, 구매대금 결제내역 정보에 기록된 지급대상 금액이 기 지정된 대출 한도 금액 이내인가, 구매대금 결제내역 정보에 기록된 지급대상 판매업체가 등록된 판매업체인가 등의 여부를 판단한다(단계 S104).

이때, 구매대금 결제내역 정보에 기록된 지급대상 금액이 기 지정된 대출 한도 금액을 초과하거나, 구매대금 결제내역 정보에 기록된 지급대상 판매업체가 등록된 판매업체가 아닌 것으로 판단되는 경우, 대금결제 관리 서버(10)는 일련의 오류 메시지를 구매업체측 클라이언트(1)로 전송하는 과정을 진행한다(단계 S105).

이 경우, 대금결제 관리 서버(10)는 운영정보 관리 모듈(50)을 활용하여, 운영정보 D/B(84)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를활용하여, 예컨대, "선택하신 금액이 대출 한도 금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 구매업체측 클라이언트(1)로 전송한다.

그러나, 구매대금 결제내역 정보에 기록된 지급대상 금액이 기 지정된 대출 한도 금액 이내의 금액이고, 구매대금 결제내역 정보에 기록된 지급대상 판매업체가 등록된 판매업체로 판단되어, 해당 구매대금 결제내역 정보의 타당성이 인정되는 경우, 대금결제 관리 서버(10)는 해당 구매대금 결제내역 정보를 수집·저장하는 과정을 진행한다(단계 S106).

이 경우, 대금결제 관리 서버(10)는 구매업체측 클라이언트(1)로부터 전송된 구매대금 결제내역 정보를 구매대금 결제내역 관리모듈(40)로 전달하게 되며, 구매대금 결제내역 관리모듈(40)은 이러한 구매대금 결제내역 정보가 전달되는 즉시, 이를 D/B 관리 서버(70)로 전달함으로써, 해당 구매대금 결제내역 정보가 예컨대, 구매대금 결제내역 정보 D/B(82)에 안정적으로 수집·저장될 수 있도록 한다.

다음으로, 상술한 대출채권금 선 지급 과정(단계 S200)을 상세히 설명한다.

앞서 언급한 바와 같이, 판매업체(500)측에서, 대출채권금의 선 지급을 신청한 상황 하에서, 도 8에 도시된 바와 같이, 우선, 대금결제 관리 서버(10)는 운영정보 관리 모듈(50)을 활용하여, 판매업체(500)측의 대출채권금 선 지급 신청내역 입력과정을 가이드 하기 위한 일련의 대출채권금 선 지급 신청내역 입력 가이드 페이지를 생성하고, 생성이 완료된 대출채권금 선 지급 신청내역 입력 가이드 페이지를 인터페이스 모듈(20)을 매개로 하여, 판매업체측 클라이언트(2)로 전송하는 과정을 진행한다(단계 S201).

이 경우, 판매업체측 클라이언트(2)는 대금결제 관리 서버(10)로부터 전송되는 대출채권금 선 지급 신청내역 입력 가이드 페이지(613)을 신속히 해석하여, 이를 도 9에 도시된 바와 같이 디스플레이 시킴으로써, 판매업체(500)가 일련의 대출채권금 선 지급 신청 과정을 신속하게 진행시킬 수 있는 안정적인 기반환경을 제공받도록 한다.

이 상태에서, 대금결제 관리 서버(10)는 인터페이스 모듈(20)을 지속적으로 체크함으로써, 판매업체측 클라이언트(2)로부터 일련의 대출채권금 선 지급 신청정보가 전송되었는가의 여부를 판단한다(단계 S202).

이때, 판매업체측(500)에서, 아직, 대출채권금 선 지급 신청내역 입력과정을 완료하지 않아, 판매업체측 클라이언트(2)로부터 일련의 대출채권금 선 지급 신청정보가 전송되지 않은 것으포 판단되면, 대금결제 관리 서버(10)는 플로우를 단계 S203으로 진행하여, 일련의 대기 상태를 유지한다.

그러나, 판매업체(500)측에서, 대출채권금 선 지급 신청내역 입력과정을 모두 완료하고, 예컨대, 전송 항목(614)을 클릭하여, 판매업체측 클라이언트(2)로부터 일련의 대출채권금 선 지급 신청정보가 전송된 것으로 판단되면, 대금결제 관리 서버는 그 즉시, 대출채권금 선 지급 신청정보의 타당성 여부, 예컨대, 대출채권금 선 지급 신청정보에 기록된 선 지급 신청금액이 판매업체의 판매금액 이내인가의 여부를 판단한다(단계 S204).

이때, 대출채권금 선 지급 신청정보에 기록된 선 지급 신청금액이 판매업체의 판매금액을 초과하는 경우, 대금결제 관리 서버(10)는 일련의 오류 메시지를 판매업체측 클라이언트(2)로 전송하는 과정을 진행한다(단계 S205).

이 경우, 대금결제 관리 서버(10)는 운영정보 관리 모듈(50)을 활용하여, 운영정보 D/B(84)에 저장되어 있던 일련의 운영정보를 추출 받은 후, 이 운영정보를 활용하여, 예컨대, "신청하신 금액이 판매금액을 초과합니다. 다시 한번 시도해 주십시오‥" 등과 같은 일련의 오류 메시지를 생성하고, 생성이 완료된 오류 메시지를 판매업체측 클라이언트(2)로 전송한다.

그러나, 대출채권금 선 지급 신청정보에 기록된 선 지급 신청금액이 판매금액 이내인 경우, 대금결제 관리 서버(10)는 미리 정해진 소정의 이자를 제(Exclusion)하고, 판매업체(500)의 물품(용역)에 상응하는 일련의 대출채권금을 구매업체(400)를 대신하여, 판매업체(500)측에게 미리 선 지급하는 과정을 진행한다(단계 S206,S207).

이 경우, 대금결제 관리 서버(10)는 계좌 관리 모듈(90)로 "이자를 제하고 대출채권금을 선 지급할 것"을 지시하게 되며, 계좌 관리 모듈(90)은 이러한 지시 이벤트가 발생하는 즉시, 이자가 차감된 일정액의 현금을 예컨대, 시스템측 지정계좌(92)로부터 판매업체측 지정계좌(93)로 입금시키게 되고, 결국, 구매업체(400)를 대상으로 일련의 물품, 용역 등을 판매한 판매업체(500)는 "자사에서 판매한 물품, 용역" 등에 상응하는 일련의 대출채권금을 온라인 상에서 대출금 만기일 이전에 손쉽게 선 입금 받을 수 있게 된다.

추후, 대금결제 관리 서버(10)는 운영정보 관리모듈(50)을 매개로, D/B 관리서버(70)를 제어함으로써, 판매업체(500)를 대상으로 하는 대출채권금 선 지급 정보가 예컨대, 대출채권금 선 지급 정보 D/B(83)에 안정적으로 저장될 수 있도록 한다.

이때, 경우에 따라서, 시스템(100)측에서는 판매업체측 클라이언트(2)로 세금계산서 정보의 등록을 요청하는 프로세스를 추가로 진행시킬 수도 있다.

한편, 상술한 도 3에 도시된 바와 같이, 본 발명의 체제 하에서, 구매대금 결제내역 관리 과정(단계 S100), 대출채권금 선 지급 과정(단계 S200) 등이 선택적으로 마무리되면, 대금결제 관리 서버(10)는 운영정보 관리모듈(50)을 활용하여, 등록정보 D/B(85)에 저장된 구매업체(400)측의 대출금 정보를 추출하고, 이 대출금 정보를 체크하여, 각 구매업체(400)측의 대출 건들 중, 당일 만기일 건이 있는가의 여부를 판단한다(단계 S12).

이때, 각 구매업체(400)측의 대출 건들 중, 당일 만기일 건이 있는 경우, 대금결제 관리 서버는 해당 구매업체(400)측의 지정계좌(91)를 체크하여, 대출금을 회수하는 단계를 진행한다(단계 S300).

먼저, 도 10에 도시된 바와 같이, 대금결제 관리 서버(10)는 계좌 관리 모듈(90)을 제어하여, 당일 만기일 건에 해당하는 대출을 받은 구매업체(400)측의 지정계좌(91)를 면밀히 체크한다(단계 S301).

이러한 체크과정이 완료된 후, 대금결제 관리 서버(10)는 당일 만기일 건에 해당하는 대출을 받은 구매업체(400)측의 지정계좌 입금액이 해당 구매업체(400)의 대출금 이상인가의 여부를 판단한다(단계 S302).

이때, 도 11a에 도시된 바와 같이, 해당 구매업체(400)의 대출금이 300이고, 구매업체(400)측 지정계좌 입금액이 200이어서, 구매업체(400)측의 지정계좌 입금액이 해당 구매업체(400)의 대출금 미만인 것으로 판단되면, 대금결제 관리 서버(10)는 그 즉시, 계좌 관리 모듈(90)을 활용하여, 구매업체(400)측 지정계좌(91)에 입금되어 있던 200을 시스템(100)측 지정계좌(92)로 회수함과 아울러, 은행(300)측과 대출금 차주 관계에 있는 해당 구매업체(400)를 그 차액, 즉, 100만큼 연체 처리하는 과정을 진행한다(단계 S303).

이 경우, 대금결제 관리 서버(10)는 운영정보 관리모듈(50)로 "해당 구매업체(400)를 연체 처리하라"는 메시지를 전달하게 되며, 운영정보 관리모듈(50)은 이러한 메시지가 전달되는 즉시, 등록정보 D/B(85)에 저장되어 있는 해당 구매업체(400)의 등록정보를 변경시킴으로써, 이후, 해당 구매업체(400)가 연체업체로 분류·관리될 수 있도록 한다.

물론, 앞의 과정을 통해, 구매업체(400)가 연체업체로 분류·관리된다 하더라도, 시스템(100)측에서는 판매기업(500)측에 대출금에 대한 변제요청을 하지 않는다.

그러나, 도 11b에 도시된 바와 같이, 해당 구매업체(400)의 대출금이 250이고, 구매업체(400)측 지정계좌 입금액이 300이어서, 구매업체(400)측의 지정계좌 입금액이 해당 구매업체(400)의 대출금 이상인 것으로 판단되면, 대금결제 관리 서버(10)는 그 즉시, 계좌 관리 모듈(90)을 활용하여, 구매업체(400)측의 보유 대금, 예컨대, 300 중 250을 구매업체측 지정계좌(91)로부터 시스템측 지정계좌(92)로 입금시키게 되고, 결국, 은행(300)은 상술한 구매업체측과 약정한 대출금을 손쉽게 회수할 수 있게 된다.

한편, 앞서 언급한 과정을 통해, 대출금의 회수가 일단락 되면, 대금결제 관리 서버(10)는 그 즉시, 운영정보 관리모듈(50)을 활용하여, 예컨대, 구매대금 결제내역 정보 D/B(82), 대출채권금 선 지급 정보 D/B(83), 등록정보 D/B(85) 등에 저장되어 있던 구매대금 결제내역 정보, 대출채권금 선 지급 정보, 등록정보 등을 체크하고, 이를 통해, 당일 만기일 건에 해당하는 대출을 받은 구매업체(400)측과 거래관계를 맺은 판매업체(500)측이 수급해야할 대출채권금을 파악한다. 이러한 파악과정이 완료되면, 대금결제 관리 서버(10)는 그 즉시, 계좌 관리 모듈(90)을 활용하여, 해당 미 수급 대출채권금을 예컨대, 이자를 제한 상태로, 판매업체측의 지정계좌(93)에 선택적으로 입금하는 과정을 진행한다(단계 S305). 이 경우, 판매업체측의 지정계좌(93)로 입금되는 대출채권금은 해당 판매업체(500)가 앞서 언급한 단계 S200을 통해, 대출채권금을 선 지급 받았는가, 그렇지 않았는가의 여부에 따라, 전액이 될 수도 있고 부분 액이 될 수도 있다.

예를 들어, 도 11c에 도시된 바와 같이, 당일 만기일 건에 해당하는 대출을 받은 구매업체(400)측과 거래관계를 맺은 특정 판매업체(500)의 물품(용역) 판매액이 100이고, 이 판매업체(500)가 단계 S200을 통해 대출채권금의 일부, 예컨대, 50을 선 지급 받은 것으로 파악되는 경우, 대금결제 관리 서버(10)는 그 즉시, 계좌 관리 모듈(90)을 활용하여, 해당 판매업체(500)의 미 수급 잔여 대출채권금, 예컨대, 50을 예컨대, 이자를 제한 상태로, 시스템측 지정계좌(92)로부터 해당 판매업체측의 지정계좌(93)로 선택·입금하는 과정을 진행하게 되며, 결국, 대출금 만기일 이전에 대출채권금을 할인 받은 해당 판매업체(500)는 "할인 대출채권금"을 제외한 자사가 판매한 물품, 용역 등에 대한 나머지 판매대금 잔액을 모두 수금할 수 있게 된다.

다른 예로, 도 11d에 도시된 바와 같이, 당일 만기일 건에 해당하는 대출을 받은 구매업체(400)측과 거래관계를 맺은 특정 판매업체(500)의 물품(용역) 판매액이 100이고, 이 판매업체(500)가 앞서 언급한 단계 S200을 아예 밟지 않은 것으로 파악되는 경우, 대금결제 관리 서버(10)는 그 즉시, 계좌 관리 모듈(90)을 활용하여, 해당 판매업체(500)의 미 수급 대출채권금 전액, 예컨대, 100을 예컨대, 이자를 제한 상태로, 시스템측 지정계좌(92)로부터 해당 판매업체측의 지정계좌(93)로 선택·입금하는 과정을 진행하게 되며, 결국, 대출금 만기일 이전에 대출채권금을 할인 받지 않은 해당 판매업체(500)는 자사가 판매한 물품, 용역 등에 대한 판매대금 전액을 모두 수금할 수 있게 된다.

이후, 대금결제 관리 서버(10)는 구매업체측 클라이언트(1) 또는 판매업체측 클라이언트(2) 등으로부터 일련의 구매대금 결제내역 관리 이벤트, 대출채권금 선 지급 신청 이벤트 등이 발생될 때마다, 상술한 인증모듈(30), 구매대금 결제내역 관리모듈(40), 운영정보 관리모듈(50), 계좌 관리 모듈(90) 등을 긴밀하게 연계시켜, 일련의 구매대금 결제내역 관리 과정, 대출채권금 선 지급 관리 과정 등을 체계적으로 진행시킴으로써, 임의의 구매업체, 판매업체 등이 은행 온라인망을 기반으로 하여, 신뢰성 있는 대금결제 관계를 손쉽게 형성할 수 있도록 한다.

이상에서 상세히 설명한 바와 같이, 본 발명에서는 임의의 판매업체측으로부터 물품, 용역 등을 구매한 구매업체를 대상으로 하여, 일련의 구매자금 결제전용 대출(대출한도 공여)을 시행하고, 이를 근거로, 구매업체가 지불하여야할 구매대금의 일부 또는 전부가 은행 온라인망 상에서 각 판매업체들에게 대출채권금(만기일이 있는 대출채권) 형태로 선 지급될 수 있도록 유도함으로써, 구매업체-판매업체 사이에 형성되는 대금결제관계의 신속성 및 신뢰성을 대폭 향상시킬 수 있다.

또한, 본 발명에서는 구매업체에 의한 종래의 어음 사용을 미리 배제시키고, 이를 통해, 판매업체 및 구매업체 사이에 형성되는 대금 결제관계의 신뢰성을 대폭 향상시킴으로써, 예측하지 못한 판매업체의 피해를 최소화시킬 수 있다.

또한, 본 발명에서는 판매업체 및 구매업체 사이에 진행되는 전체적인 대금 결제과정을 온라인 상에서 체계적으로 구현함으로써, 판매업체 및 구매업체가 온라인 상에서, 자사에 필요한 판매대금 수금과정, 구매대금 지불과정을 좀더 손쉽게 진행시킬 수 있도록 유도할 수 있다.

또한, 본 발명에서는 구매업체 및 판매업체 사이에 형성되는 대금 결제관계의 신뢰성을 향상시킴으로써, 여러 업체의 연쇄 부도에 따른 경제적인 피해를 최소화시킬 수 있다.

앞에서, 본 발명의 특정한 실시예가 설명되고 도시되었지만 본 발명이 당업자에 의해 다양하게 변형되어 실시될 가능성이 있는 것은 자명한 일이다.

이와 같은 변형된 실시예들은 본 발명의 기술적사상이나 관점으로부터 개별적으로 이해되어서는 안되며 이와 같은 변형된 실시예들은 본 발명의 첨부된 특허청구의 범위안에 속한다 해야 할 것이다.

Claims (7)

1. 은행 온라인망에 소속된 대금결제 관리 서버가 상기 은행과 구매대금 결제전용 대출을 약정한 구매업체측에 의해 관리되는 구매업체측 클라이언트 및 상기 구매업체측과 거래관계에 있는 판매업체측에 의해 관리되는 판매업체측 클라이언트를 대상으로 진행하는 과정으로 이루어지며,

   상기 구매업체측 클라이언트 또는 판매업체측 클라이언트 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생하였는가의 여부를 판단하는 단계와;

   상기 구매업체측 클라이언트 또는 판매업체측 클라이언트 중의 어느 하나로부터 일련의 시스템 접속 이벤트가 발생한 경우, 해당 클라이언트를 통해 접속 중인 업체의 등록여부를 판단하는 단계와;

   해당 업체가 등록업체인 것으로 판단되는 경우, 해당 등록업체가 일련의 대출절차를 미리 밟은 구매업체인가의 여부를 판단하는 단계와;

   해당 등록업체가 상기 대출절차를 미리 밟은 구매업체로 판단되는 경우, 일련의 구매업체용 초기 페이지를 생성하고, 생성이 완료된 상기 구매업체용 초기 페이지를 상기 구매업체측 클라이언트로 전송하는 단계와;

   상기 구매업체측 클라이언트로부터 일련의 구매대금 결제내역 관리 이벤트가 발생하였는가의 여부를 판단하는 단계와;

   상기 구매업체측 클라이언트로부터 일련의 구매대금 결제내역 관리 이벤트가 발생한 경우, 상기 구매업체측 클라이언트로부터 전송되는 구매대금 결제내역 정보를 참조하여, 구매업체측의 구매대금 결제내역을 관리하는 단계를 포함하는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.
2. 제 1 항에 있어서, 상기 구매업체측의 구매대금 결제내역을 관리하는 단계는 상기 구매대금 결제내역의 입력을 가이드 하기 위한 일련의 구매대금 결제내역 입력 가이드 페이지를 생성하고, 생성이 완료된 상기 구매대금 결제내역 입력 가이드 페이지를 상기 구매업체측 클라이언트로 전송하는 단계와;

   상기 구매업체측 클라이언트로부터 상기 구매대금 결제내역 입력 가이드 페이지에 대응되는 구매대금 결제내역 정보가 전송되었는가의 여부를 판단하는 단계와;

   상기 구매업체측 클라이언트로부터 상기 구매대금 결제내역 정보가 전송된 경우, 해당 구매대금 결제내역 정보의 타당성 여부를 판단하는 단계와;

   상기 구매대금 결제내역 정보의 타당성이 인정되는 경우, 해당 구매대금 결제내역 정보를 수집·저장하는 단계를 포함하는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.
3. 제 1 항에 있어서, 해당 등록업체가 판매업체로 판단되는 경우, 일련의 판매업체용 초기 페이지를 생성하고, 생성이 완료된 판매업체용 초기 페이지를 상기 판매업체측 클라이언트로 전송하는 단계와;

   상기 판매업체측 클라이언트로부터 일련의 대출채권금 선 지급 신청 이벤트가 발생하였는가의 여부를 판단하는 단계와;

   상기 판매업체측 클라이언트로부터 상기 대출채권금 선 지급 신청 이벤트가 발생한 경우, 상기 판매업체측 클라이언트로부터 전송되는 대출채권금 선 지급 신청 정보를 참조하여, 해당 판매업체로 대출채권금을 선 지급하는 단계를 더 포함하는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.
4. 제 3 항에 있어서, 상기 판매업체로 대출채권금을 선 지급하는 단계는 대출채권금 선 지급 신청 내역의 입력을 가이드 하기 위한 일련의 대출채권금 선 지급 신청내역 입력 가이드 페이지를 생성한 후, 생성이 완료된 대출채권금 선 지급 신청내역 입력 가이드 페이지를 상기 판매업체측 클라이언트로 전송하는 단계와;

   상기 판매업체측 클라이언트로부터 상기 대출채권금 선 지급 신청내역 입력 가이드 페이지에 대응되는 일련의 대출채권금 선 지급 신청 정보가 전송되었는가의 여부를 판단하는 단계와;

   상기 판매업체측 클라이언트로부터 상기 대출채권금 선 지급 신청 정보가 전송된 경우, 해당 대출채권금 선 지급 신청 정보의 타당성 여부를 판단하는 단계와;

   상기 대출채권금 선 지급 신청 정보의 타당성이 인정되는 경우, 소정의 이자를 제(Exclusion)하고, 해당 선 지급 신청금액을 지급하는 단계를 포함하는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.
5. 제 1 항에 있어서, 상기 구매업체측의 대출 건들 중, 당일 만기일 건이 있는가의 여부를 판단하는 단계와;

   상기 구매업체측의 대출 건들 중, 당일 만기일 건이 있는 경우, 해당 구매업체측의 지정계좌를 체크하여, 대출금을 회수하는 단계가 더 진행되는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.
6. 제 5 항에 있어서, 상기 대출금을 회수하는 단계는 상기 구매업체측의 지정계좌에 미리 입급되어 있는 금액이 해당 구매업체측의 대출금 이상인가의 여부를 판단하는 단계와;

   상기 구매업체측의 지정계좌에 미리 입금되어 있는 금액이 해당 구매업체측의 대출금 이상인 경우, 대출금을 회수하고, 상기 구매업체측의 지정계좌에 미리 입금되어 있는 금액이 구매업체측의 대출금 미만인 경우, 해당 구매업체를 연체 처리하는 단계를 포함하는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.
7. 제 6 항에 있어서, 판매업체측이 대출채권금을 선 지급 받았는가의 여부에 따라, 대출채권금의 일부 또는 전부를 이자를 제한 상태로, 판매업체측의 지정계좌에 선택적으로 입금하는 단계가 더 진행되는 것을 특징으로 하는 은행 온라인망을 기반으로 하는 기업간 대금결제 관리 방법.