KR101003708B1

KR101003708B1 - 회계 시스템

Info

Publication number: KR101003708B1
Application number: KR1020047021350A
Authority: KR
Inventors: 머레이피터노엘
Original assignee: 피엔 앤드 에이제이 머레이 피티와이 리미티드
Priority date: 2002-06-27
Filing date: 2003-06-27
Publication date: 2010-12-23
Also published as: WO2004003796A1; NZ537157A; CA2490550A1; US7848969B2; US20050246250A1; JP2005531073A; AUPS322202A0; KR20050016908A; EP1516268A1; CN1675645A; EP1516268A4; CA2490550C

Abstract

미리 구성된 클라이언트 모듈들을 갖는 회계 시스템을 개시한다. 상기 모듈 각각은 거래 기록들과, 저장 매체에 저장된 미리-할당된 거래 카테고리 코드들과, 거래 기록과 연관시키기 위한 미리-할당된 카테고리 코드를 선택하기 위한 코드 선택기들과, 거래 기록들이 연관되어야 하는 클라이언트 미리 결정된 계정의 선택에 대한 계정들의 클라이언트 차트를 입력하기 위한 인터페이스 형태들(interface forms)을 갖는다. 각각의 계정은 미리 할당된 고유한 계정 식별 및 클라이언트 규정된 계정 디스크립션을 포함한다. 각각의 카테고리 코드는 과세 또는 비과세 및, 지출 또는 수입 거래 형태로서 미리 명시된다. 상기 시스템은 세금들을 갖는 각각의 카테고리 코드들과 연관된 프롬프트들을 통해 거래 기록들의 세금들에 연관된 정보를 얻고, 거래의 세금들을 할당하기 위해 입력된 정보를 추출한다.

회계 시스템, 계정 식별, 계정 디스크립션, GST, 거래 카테고리 코드, 계정의 클라이언트 차트, 회계 리포트, BAS, 캐시북 모듈, 발생 모듈

Description

회계 시스템{An accounting system}

본 발명은 거래들(transactions)을 처리하기 위한 회계 시스템에 관한 것이다.

수년 동안, 중소 기업(SME)의 오퍼레이터들은 거래 기록들에 대한 수동 부기(manual bookkeeping) 작업을 실행하였다. 거래 기록들을 포함하는 장부들(books)은 계정 스테이트먼트들(accounts statements) 및 세금 신고(tax returns)를 준비하기 위해 오퍼레이터들의 회계사들에게 주어졌다.

세법의 최근 변화들, 특히 상품 및 서비스 세금(Goods and Services Tax(GST)을 수반하는 임의의 거래에 있어 GST을 징수하고 주기적인 기업 활동 스테이트먼트들(Business Activities Statements)(BAS)을 제출하도록 회사들에 요구하는 상품 및 서비스 세금(GST)의 도입은 수동 부기 작업들을 매우 복잡하게 만들었다. 결과적으로, SME 오퍼레이터들은, 일반적으로, 거래 기록들을 입력하는 컴퓨터화된 회계 시스템의 이용에 의존하였고, 이에 의해, 기록들은 그들 회계사들 및 세금 기관에 대한 리포트들을 작성하도록 처리될 수 있었다.

컴퓨터화된 회계 시스템을 효과적으로 이용하고, 회계사들 및 세금 기관에 수용 가능한 계정 리포트들(accounts reports)을 작성하기 위하여, 오퍼레이터들은 기본적인 컴퓨터 기술들뿐만 아니라, 그들 사업에 적당한 세금들 및 그들 회계 응용 소프트웨어에 이용되는 절차들 및 회계 용어들도 학습해야만 한다.

또한, 응용 소프트웨어는 개별 SME 오퍼레이터들의 회계 실행에 적합하도록 구성되어야 한다. 이는, 그들 사업들에 적당한 세금 옵션들과 회계 절차들을 이용하는 응용 소프트웨어를 구성하기 위하여 회계 실행 및 세법에 있어 필요한 지식을 습득해야 함을 의미한다.

응용 소프트웨어는 일반적인 사용을 위한 것이고, 거래들에 대한 공통 회계 용어들을 사용한다. 결과적으로, SME 오퍼레이터들은 그들이 수동 부기 체계에 채택되었던 거래 항목 디스크립션들(transaction item descriptions)을 더 이상 이용할 수 없다. 이는 SME 오퍼레이터들이 익숙하지 않은 새로운 회계 용어들과 익숙하기 위한 시간을 소비해야 하는 대부분의 SME 오퍼레이터들에게는 주요 단점으로 나타난다. 거래 기록들을 입력하기 위해 익숙하지 않은 용어들을 이용할 때 거래 엔트리 에러들이 종종 발생한다. 이러한 에러들은 추적하거나 교정하는데 매우 어렵게 될 수 있다.

상품 및 서비스 세금(GST)의 도입에 의해, 컴퓨터화된 회계 시스템은 SME 오퍼레이터들에게는 GST에 대한 징수 대행자로서 이제 동작해야 하므로 보다 복잡하게 된다. BAS를 생성하는 회계 시스템을 설정하기 위하여, SME 오퍼레이터들은 GST 및 다른 세금들을 수반하는 상품 및 서비스들의 적당한 세금들을 포함한 응용 소프트웨어를 구성해야 한다. 이들 요구사항들은 SME 오퍼레이터들에게 무거운 부담이 된다. 부가적으로, 그들 중 다수는 어느 거래 항목들이 GST를 수반하고 그렇지 않은지를 판정하기 위한 충분한 지식을 필요한 지식을 갖지 못한다. 또한, 그들은 BAS에서 GST, Pay As You Go(PAYG) 공제(Withholding) 및 PAYG 분할 불입(Installments)를 정확하게 기록하기 위하여 거래들을 할당하는 필요한 지식을 갖지 못한다.

주기적으로, 입력된 거래 기록들은 은행 기록들과 일치되어야 한다. 이러한 일치 처리는 SME 오퍼레이터들에 의해 일반적으로 이해되지 않고, 시간 소비적이다.

알려진 컴퓨터화된 회계 시스템은 계정 리포트들만을 처리하기 위한 것이다. 관리에 관련된 기능들을 수행하기 위한 거래 기록들로부터 얻을 수 있는 정보를 이용하는 것이 바람직할 것이다.

본 발명의 목적은 상술한 종래의 단점들 중의 하나 이상을 특정 레벨로 감소시키거나 경감하기 위한 것이다.

따라서, 일 양태에서, 본 발명은 클라이언트에 의해 이용하기 위한 적어도 하나의 클라이언트 모듈 포함하는 회계 시스템에 관한 것이다. 적어도 하나의 클라이언트 모듈은 거래 기록들을 입력하기 위한 거래 엔트리 수단과, 저장 매체에 저장되어 있는 미리 할당된 거래 카테고리 코드들과, 상기 거래 엔트리 수단을 통해 입력될 거래 기록과 관련시키기 위해 미리 할당된 카테고리 코드를 선택하기 위한 수단과, 상기 거래 기록이 관련되어야 하는 계정의 선택에 대한 계정들의 클라이언트 차트를 포함하고, 상기 계정은 상기 클라이언트에 의해 지명된 적어도 하나의 무역 형태의 계정에 따라 상기 클라이언트에 의해 미리 결정된다. 상기 계정들 각각은 상기 클라이언트에 의해 규정되거나 상기 적어도 하나의 무역 형태로 무역업자들에 의해 일반적으로 채택되는 계정 디스크립션(account description) 및 미리-할당된 고유한 계정 식별을 포함하고, 상기 카테고리 코드들 각각은 과세 또는 비과세 및, 지출 또는 수입 거래 형태로서 미리 지정된다.

따라서, 다른 양태에서, 본 발명은 클라이언트에 의한 이용을 위한 적어도 하나의 클라이언트 모듈을 포함하는 회계 시스템에 관한 것이다. 적어도 하나의 클라이언트 모듈은 거래 기록들을 입력하기 위한 거래 엔트리 수단과, 거래 기록들의 세금들(tax liabilities)에 관련된 정보를 취득하기 위한 수단을 포함한다. 상기 정보 취득 수단은 세금들을 갖는 복수의 거래 카테고리 코드들 각각과 연관된 하나 이상의 프롬프트들(prompts)을 갖고, 상기 카테고리 코드의 하나가 입력될 거래로 지명될 때 세금들과 관련된 정보를 입력하기 위한 관련된 하나 이상의 프롬프트들을 제공하고, 거래의 세금을 할당하기 위해 입력된 정보를 추출하도록 배열된다.

바람직하게, 상기 하나 이상의 프롬프트들은 지정된 위치(들)에 상기 관련된 세금 정보를 입력하도록 클라이언트에 대한 하나 이상의 유도 질문들의 형태이고, 적어도 하나의 클라이언트 모듈은 상기 지정된 위치(들)에서 입력된 정보를 추출하고, 상기 지정된 위치(들)로부터 상기 또는 각각 추출된 정보에 대해 지정된 세금 결정 절차를 적용하도록 배열된다.

적어도 하나의 클라이언트 모듈은 회계 리포트들을 생성하기 위해 입력된 거래 기록들을 액세스하도록 배열된 리포트 생성 수단을 갖는 것이 바람직하다. 보다 바람직하게는, 상기 리포트 생성 수단은 생성을 위한 다수의 회계 리포트들 중 어느 하나를 선택하는 리포트 선택 배열(report selection arrangement)을 포함한다.

오히려, 상기 과세된 카테고리 코드들 중 적어도 하나는 회계 리포트들 중 하나인 과세 리포트에 대한 과세 세그먼트들에 미리-할당된다. 보다 바람직하게는, 상기 과세 리포트는 상품 및 서비스 세금(GST)에 따른 기업 활동들의 스테이트먼트들(BAS)이 된다. 가변 세금 할당을 갖는 과세된 카테고리 코드가 입력되는 경우에, 할당될 총액을 지정하기 위한 적당한 프롬프트들을 갖는 윈도우가 그 총액의 입력을 제공하는 것이 바람직하다.

상기 적어도 하나의 무역 형태는 사업의 임의의 부류에 관련된 상품 및/또는 서비스들의 제공을 포함하는 무역 활동들을 포함할 수 있다. 사업 부류들의 예들은 회계 사무, 하드웨어 소매 및 도매, 전기 상품 및 수선 서비스들, 연관류 제조 공급(plumbing supplies) 및 서비스, 건강에 대한 상품 및 서비스들, 기계 수선 서비스, 운송 상품 등이다.

또한, 카테고리 코드들은 급료에 대한 카테고리를 포함하고, 이러한 급료 카테고리는 계정의 상기 클라이언트 차트에 급료 계정과 연관되는 것이 바람직하다. 따라서, 본 발명에 따른 시스템은 급료 지불 패키지(payroll package)로서 또한 기능을 한다.

상기 시스템은 거래 기록들을 저장하기 위한 저장 수단을 가질 수 있고, 통신 네트워크를 통해 은행 스테이트먼트 기록들(bank statement records)을 액세스하도록 배열된다. 상기 적어도 하나의 클라이언트 모듈은 상기 은행 스테이트먼트 기록들과 상기 저장된 거래 기록들을 일치시키는 일치 수단을 포함할 수 있다.

바람직하게, 상기 시스템은 회계 리포트들 및 관리 리포트들을 생성하기 위한 적어도 하나의 클라이언트 모듈로부터 전송된 거래 기록들을 액세스하도록 배열되는 리포트 생성 수단을 갖는 적어도 하나의 어드바이저 모듈(adviser module)을 포함한다.

보다 바람직하게는, 상기 리포트 생성 수단은 생성을 위한 다수의 회계 및 관리 리포트들 중 어느 하나를 선택하기 위한 리포트 선택 배열을 포함한다.

상기 시스템은 상기 적어도 하나의 클라이어트 모듈을 관리하기 위한 관리 모듈을 또한 포함하고, 상기 관리 모듈과 상기 적어도 하나의 클라이언트 모듈은 통신 네트워크를 통해 통신하도록 배열된다. 상기 관리 모듈은 계정들의 클라이언트 차트가 추출되는 계정들의 마스터 차트와, 사용자 결정에 따라 계정들의 상기 마스터 차트를 생성하기 위한 차트 생성 수단을 포함한다. 계정들의 상기 클라이언트 차트는 내부의 계정 식별들 및 계정 디스크립션들이 변경될 수 없도록 고정되는 것이 바람직하다.

또한, 상기 관리 모듈은 사용자에 의해 지정될 때 거래 코드들을 생성하기 위한 거래 코드 생성 수단을 갖는 것이 바람직하다.

상기 시스템은 관리 모듈과 통신하는데 있어 다수의 클라이언트 모듈들을 가질 수 있다, 클라이언트 모듈들 각각은 고유한 클라이언트 레퍼런스를 갖고, 관리 모듈을 통해 매도 주문들 및/또는 구매 주문들을 전송할 수 있도록 채택된다. 상기 매도 주문들 및/또는 구매 주문들 각각은 구매 클라이언트 모듈의 클라이언트 레퍼런스와 공급자 클라이언트 모듈의 클라이언트 레퍼런스를 포함한다. 상기 관리 모듈은 구매 클라이언트로부터의 구매 주문을 공급자 클라이언트 모듈로 전송하고, 이어서 수신된 인보이스(invoice)를 공급자 클라이언트 모듈로부터 구매 클라이언트 모듈로 전송하는 클라이언트 레퍼런스들을 이용하도록 배열된 조정 장치(coordination)를 가질 수 있다. 또한, 인보이스의 지불은, 상기 인보이스가 결제되었음을 조정 장치가 기록할 수 있도록 관리 모듈을 통해 전송되는 것이 바람직하다.

따라서, 본 발명의 시스템은 공급자들과 구매자들 사이의 거래 정보를 저장할 수 있다. 그러므로, 조정 장치는 거래들에 대한 재고들(stocks)이 미리 결정된 레벨들 이하로 될 때 구매 주문들을 자동화하도록 배열될 수 있다.

바람직하게, 상기 또는 각각의 상기 클라이언트 모듈은 연관된 클라이언트(들)의 거래 기록들이 원격으로 액세스될 수 있도록 관리 모듈과 통신 상태에 있도록 또한 배열된 어드바이저 모듈과 결합되는 것이 바람직하다.

상기 적어도 하나의 클라이언트 모듈은 캐시북(cashbook) 또는 발생(accrual) 모듈 또는 조합된 현금 출납부 및 발생 모듈, 급료 모듈이나 판매 시점 모듈(a point of sale module), 또는 둘 이상의 상기 모듈들의 임의 조합이 될 수 있다.

본 발명이 쉽게 이해될 수 있고, 실제의 효과를 나타내기 위하여, 본 발명의 실시예들을 제한하지 않는 첨부된 도면들을 참조하여 이하에 설명한다.

도 1은 본 발명에 따른 회계 시스템의 한 실시예를 도시한 개략도.

도 2a 및 도 2b는 도 1의 시스템에 대한 캐시북 모듈을 구성하는 데 단계들을 도시한 흐름도.

도 3a 및 도 3b는 도 1의 시스템에서 클라이언트 데이터베이스들의 위치파악 절차를 개략적으로 도시한 도면.

도 4a 내지 도 4b는 납입 및 수신을 입력하기 위한 인터페이스 형태들을 도시한 도면.

도 4c는 도 4a 및 내지 4b에 도시된 인터페이스 형태들로 입력된 거래정보를 갖는 거래 테이블의 일례를 도시한 도면.

도 5a 내지 5c는 클라이언트 모듈을 작성하는 데 있어 단계들의 흐름도.

도 5d 내지 도 5q는 클라이언트 모듈들을 작성 및 유지하기 위한 인터페이스 형태들을 도시한 도면.

도 5r은 계정들에 대해 이용 가능한 헤더들을 리스트한 리포트를 도시한 도면.

도 5s는 선택된 계정들의 리포트를 도시한 도면.

도 6은 계정 파일들을 작성 및 유지하는데 있어 조작 단계들을 도시한 도면.

도 6a는 스크립트 매니저(script manager)의 조작 단계들을 도시한 도면.

도 6b 내지 도 6f는 도 6에 도시된 단계들에 대한 일부 인터페이스를 도시한 도면.

도 7a는 클라이언트 모듈에서 클라이언트 검증 절차를 도시한 도면.

도 7b는 지불 엔트리(Payment Entry) 및 수신 엔트리(Receipt Entry)에서 단계들의 흐름도.

도 7c는 수신 엔트리 옵션에 대한 정보를 제공하기 위해 사용자를 프롬프팅(prompting)하는 절차들의 예들을 도시한 도면.

도 7d는 지불 엔트리에 대한 정보를 제공하기 위해 사용자를 프롬프팅하는 절차들의 예를 도시한 도면.

도 7e 및 도 7f는 계정 일치(accounts reconciliation)에서 단계들을 도시한 도면.

도 8a는 수신 엔트리에 대한 인터페이스 형태를 도시한 도면.

도 8b는 지불 엔트리에 대한 인터페이스 형태를 도시한 도면.

도 8c 내지 8s는 수신 엔트리 및 지불 엔트리 및, 계정 일치에 대한 정보를 입력하기 위한 프롬프트들을 갖는 인터페이스 형태들을 도시한 도면.

도 8t 내지 도 8y는 이용될 수 있는 리포트들의 일부 예들을 도시한 도면.

도 9a는 일반적인 원장에 대한 메인 인터페이스의 일례를 도시한 도면.

도 9b는 일반적인 원장에 이용될 수 있는 옵션들의 흐름도.

도 9c는 일반적인 원장에 대한 GST 컴포넌트들을 처리하는 단계들을 도시한 도면.

도 9d 내지 도 9f는 일반적인 원장 리포트들의 일부의 예들을 도시한 도면.

도 10은 관리 모듈을 통해 구매자 주문 및 공급자 인보이스의 온라인 전송을 위한 단계들을 도시한 흐름도.

도 10a는 표준 비용 처리에서 단계들을 도시한 도면.

도 10b는 계정 발생 시스템의 일 실시예의 개요를 도시한 도면.

도 10c 내지 도 10f는 발생 시스템의 채무자 관련된 오퍼레이션들에 대한 절차를 도시한 도면.

도 10g는 구매 주문에 대한 절차를 도시한 도면.

도 10h는 크레디트 지불에 대한 절차를 도시한 도면.

도 10i 내지 도 10n은 판매 시스템의 확장된 포인트에 대한 절차들을 도시한 도면.

도면들을 참고하는데 처음 도 1을 참조하면, 본 발명의 일 실시예에 따른 계정 시스템(10)을 도시한다. 시스템(10)은 컴퓨터들 상에서 동작하는 다수의 클라이언트 모듈들(12), 다수의 어드바이저 모듈(13), 도 33에 도시된 것과 같이 배열될 수 있는 서버 컴퓨터 시스템(14)에서 동작하는 관리 모듈(14)을 갖는다. 서버 시스템(14) 및 관리 유닛(16)은 로컬 지역 네트워크로 접속된다. 클라이언트 모듈(12)은 인터넷(18)을 포함하는 월드 와이드 웹(World Wide Web)을 통해 서버 시스템(14)에 접속된다. 알 수 있는 것처럼, 일부 어드바이저 모듈(13)은 네트워크된 컴퓨터들의 그룹으로 형성될 수 있다.

어드바이저 모듈들(13)은 클라이언트 모듈(12)을 구성하기 위해 정보를 서버 시스템(14)에 전송하고, 연관된 클라이언트 모듈(12)의 거래 정보를 검색하기 위해 서버 시스템(14)을 액세스할 수 있다.

전형적으로, 클라이언트 모듈들(12) 각각은 캐시북 모듈을 포함하고, 클라이언트 모듈(12)의 어드바이저 모듈(130)은 클라이언트에 적당한 회계 절차들 및 세금 옵션들을 조언하는 전문 회계사에 의해 관리된다. 또한, 어드바이저 모듈들(13) 각각에는 클라이언트가 친숙한 계정 디스크립션들이 제공될 수 있다. 관리 모듈(14)이 클라이언트 모듈(12)을 구성 또는 편집하도록 요청하기 위해, 회계사는 클라이언트 계정 요구사항들을 관리 모듈(14)에 전송하도록 어드바이저 모듈(13)을 이용할 수 있다. 계정들의 마스터 차트를 설정하기 위해 제공된 정보는 계정에 적용되는 임의 전용 백분율(private percentage)을 포함하게 될 것이고, 만일 그렇다면, 어느 원장 계정에 전용 부분들이 할당되어야 하는 지를 포함할 것이다. 또한, 회계사는 다음과 같은 응용 가능한 경우를 조언할 것이다.

현금 또는 발생 BAS 리포팅

소규모 음식 소매 상인 백분율

유력한 장기적인 상업 수용

2001년 5월 23일 이전에 구매된 새로운 모터 자동차

2000년 7월 1일 이전에 고용 구매 시작

2001년 5월 23일 이전에 새로운 모터 자동차 고용 구매

미리 결정된 GST 상태의 상세(예를 들어, 자산 임대)

은행 일치(Bank reconciliation)

회계사에 의해 제공된 계정 요구들은 클라이언트에 대한 계정들의 마스터 차트를 설정하는데 이용된다. 계정들의 마스터 차트로부터, 클라이언트에 의해 이용을 위한 계정들은 계정들의 사용자 차트를 생성하기 위해 식별된다.

클라이언트가 회계사를 이용하지 않으면, 그/그녀는 계정들의 사용자 차트를 구성하는데 필요한 정보를 제공하거나, 또는 사업 활동(business activities)의 무역 형태를 단순히 지명할 수 있고, 관리 모듈(14)은 동일한 무역 형태에서 대부분의 사업들 중 공지된 계정 구성들에 기초한 계정들의 디폴트 사용자 차트를 자동으로 구성할 것이다.

도 2a는 클라이언트 모듈(12)의 구성을 원하는 클라이언트, 어드바이저(이 경우 회계사) 모듈(13)과 관리 모듈(16)사이의 정보 흐름을 도시한다. 알 수 있듯이, 클라이언트와 회계사는 클라이언트의 계정 요구사항들에 관한 정보를 교환하고, 그에 따라, 회계사는 그 클라이언트에 대한 일반적인 저널을 작성하기 위한 저널 관리 유닛(20)을 이용한다. 이러한 관점에서, 클라이언트는 요청자(22) 및/또는 스크립터(24)를 이용함으로써 그/그녀에 친숙한 계정들의 그/그녀 자신 디스크립션들(descriptions)을 제공할 수 있다.

그 다음에, 회계사는 클라이언트에 친숙한 계정 디스크립션들을 갖는 계정들의 클라이언트 차트에 대해 구성될 계정의 마스터 차트로부터 적당한 계정들을 선택하기 위해 어드바이저 모듈(13)의 요청자 유닛(22)을 이용한다. 계정으로부터의 요청을 수신할 때 관리 모듈(14)은 계정들의 클라이언트 차트에 대한 클라이언트 데이터 베이스를 작성하고, 클라이언트에 친숙한 계정 디스크립션들을 갖는 계정들의 클라이언트 차트를 이용하여 클라이언트 모듈(12)을 구성한다. 따라서, 인도되었을 때, 클라이언트는 클라이언트 모듈(12)을 구성하고 계정들의 세금들을 결정하는 수고스럽고 에러가 발생하기 쉬운 작업들이 없이 클라이언트 모듈(12)을 간단히 설치 및 이용할 수 있다. 또한, 클라이언트 모듈(12)은 월드 와이드 웹(WWW)(18)과 같은 통신 네트워크를 통해 관리 모듈(14)과 통신하도록 설정될 수 있다.

클라이언트 모듈(12)은 계정들의 클라이언트 차트에서 임의 계정의 디스크립션을 편집하기 위한 요청을 초기화하기 위한 스크립터 유닛(24)을 갖는다. 편집에 대한 요청은 관리 모듈(14)에 직접 전송되거나(어드바이저 모듈(13)이 클라이언트 모듈(12)에 링크되지 않은 경우), 계정을 편집하기 위해 관리 모듈(14)로 진행하기 이전에 어드바이저 모듈(13)에서 등록하기 하기 위한 어드바이저 모듈(13)에 전송된다.

도 2b에 있어서, 클라이언트 모듈(12), 어드바이저 모듈 및 관리 모듈(14)은 관리 모듈(14)이 클라이언트 모듈(12) 또는 어드바이저 모듈(13)로부터 임의 요청에 직접 응답할 수 있도록 WWW(18)을 포함하는 통신 네트워크를 통해 통신하도록 배열된다.

도 3a는 계정 기록들(accounts records)이 저장되는 관리 모듈(16)의 서버 컴퓨터의 위치를 파악하기 위해 클라이언트 모듈(12)에 대한 절차를 도시한다. 시스템(10)은 네트워크된 모듈(12 및 13)로 하여금 관리 모듈(14)의 서버 컴퓨터에 대한 원격 절차 호출들(RPC)을 하도록 하는 통신 서비스를 이용한다. RPC의 이용들은 사용자들 및 데이터베이스들을 열거하고, 관리 모듈(14) 및/또는 관리 데이터 베이스로부터의 정보를 포함하는, 클라이언트 데이터베이스를 통해 이용될 수 없는 다른 정보를 액세스하는 것을 포함할 수 있다. 또한, RPC는, 민감한 정보가 네트워크를 통해 결코 전송될 수 없도록, 잠재적으로 민감한 데이터베이스 또는 다른 동작들을 서버로 허용하고, 클라이언트 모듈들(12) 및 어드바이저 모듈들(13)로부터 멀리 한다.

RPC는 HTTP 또는 통신을 위한 SSL를 통한 HTTP를 이용하고, 그 서버 종점(Server endpoint)에 대한 모호한 포트를 이용한다. 클라이언트들은 _eclatrpc._tcp.eclat.net.au에 대한 DNS SRV(Service Location) 룩업들(lookups)을 사용함으로써 상기 종점의 어드레스 및 포트를 결정할 수 있다.

관리 모듈(16) 상에 그 계정들 기록들의 위치를 파악하기 위하여, 클라이언트 모듈(12)은 다음과 같이 실행한다.

1. 클라이언트 모듈명 입력(예를 들어, Barry's Big Bins는 barrysbigbins가 될 수 있다). 이는 IDB명(IDB Name)으로서 지칭된다.

2. IDB명(IDB Name)을 시스템 도메인명(Domain Name)에 부가(예를 들어, barrysbigbins.eclat.net.au.). 이는 IDB DNS명(IDB Name)으로서 지칭된다.

3. RFC 이용하여, 시스템(10)은 접속을 위한 가능한 서버들의 리스트를 결정하도록 시도한다. 특히, _database._tcp.barrysbigbins.eclat.net.au와 같은 기록은 도 3a에 도시된 것처럼, 유효 계정 서버들을 지정하는 하나 이상의 어드레스 기록들을 리턴해야 한다.

4. 그 다음, 클라이언트는 IDB명(IDB Name)을 사용하는 그 기록들을 액세스하기 위해 데이터베이스 서버(Database Server)를 선택 및 접속할 수 있다.

이때, 클라이언트 모듈(12)은 그 계정들의 기록들의 위치를 파악하기 위해 관리 모듈(14)에 접속시키는데 필요한 정보를 모두 갖는다. 클라이언트는 다음과 같은 방식으로 관리 모듈(14)의 서버에 접속시킬 수 있다.

5. 클라이언트는 호스트명들(Hostnames), IP 어드레스들(IP Addresses), 및 적당한 서버들의 포트들(Ports of Suitable Servers)을 검색한다(이 정보는 DNS SRV Queries-Above로부터 복귀).

6. SRV 회답으로부터 가중(weighting) 및 우선권(priority) 체크. 최저 우선권 및 가중에 의해 서버를 선택. 다중 서버들이 동일한 우선권에 의해 복귀되면, 가중(예를 들어, 클러스터)은 그들 기록들 중 하나를 랜덤하게 선택한다. 단지 하나의 기록이 복귀되면, 그것을 이용해야 한다.

7. 클라이언트는 IP 어드레스/포트(Address/Port) 쌍에 적당한 접속을 형성한다.

8. 접속이 확립되면, 클라이언트는 그들 시스템 증명서들(SYSTEM credentials)을 이용하여 증명해야 한다(MUST).

어드바이저 모듈(13)은 계정에 대해서 1 이상의 클라이언트 데이터베이스들을 제어할 수 있다. 결과적으로, 모듈(13)은 액세스하는 모든 데이터 베이스들을 열거해야하고, 계정이 특정 데이터베이스를 선택하도록 할 수 있다.

절차 단계들의 다음의 세트는 계정이 클라이언트 데이터베이스들을 어떻게 열거하는 지를 설명한다.

1. FRC 및 DNS Name를 사용, _eclatpc._tcp.eclat.net.au를 사용하여, 잠재적인 RPC 서버들의 리스트가 발견될 수 있다.

2. 클라이언트는 RPC 서버들의 리스트로부터 1 서버를 선택한다. 이러한 선택은 우선화 또는 가중화될 수 있다.

3. 클라이언트는 RPC 서버에 대한 요청한다(ie ._eclat_bin/catalogList/?).

4. RPC Backend Server는 요청을 처리하고 응답을 확립한다.

5. 클라이언트는 응답을 수신하고, 도 3b에 도시된 것처럼 응답을 바로 처리 또는 분석할 수 있다.

각각의 클라이언트 모듈(12)은 다음 거래 필드들에 의해 거래 데이터베이스를 갖는다.

각각의 클라이언트 모듈(12)은 또한 다음 계정의 필드들을 갖는 계정의 클라 이언트 차트를 갖는다.

시스템(10)은 거래 카테고리들을 식별하기 위한 계정 카테고리 코드들을 이용한다. 본 실시예에 있어서, 다음의 카테고리 코드들을 이용한다.

아래에 된 것은 판매원(butcher)을 위한 계정들의 클라이언트 차트 및 계정들의 마스터 차트에서 일부 계정들의 예들이다.

판매 트레이드에 대한 계정들에 대한 마스터 차트

판매원을 위한 계정의 클라이언트 차트-판매 트레이드

도 4는 E05 카테고리 코드 거래에 대한 계정의 클라이언트 디스크립션을 이용하는 한 예를 도시한다. 총액 필드에서 제 1 로우가 선택될 때, 클라이언트 모듈(12)은 도 4에 도시된 것과 같은 관련된 거래의 상세들을 검색 및 도시한다. 도 4b는 제 2 로우에서 량의 상세들을 도시한다.

각각의 클라이언트 모듈(12)은 거래의 세금들을 계산하는 적당한 과세 방식(tax formula)을 적용한다.

각각의 클라이언트 모듈(12)은 선택된 거래들의 거래 리포트들을 생성하도록 배열된다. 도 4의 거래들을 이용하면, 모듈(12)은 도 4c에 도시된 것과 같은 리포트를 생성할 수 있다.

도 5는 아래에 도시된 관련된 필드들을 이용하는 클라이언트 모듈(12)의 클라이언트 데이터베이스를 작성하기 위한 요청자 유닛(22)에 적용된 단계들을 도시한다.

일반적인 클라이언트 정보

AS 변수들(AS Variables)

패키지에 포함하는 모듈들(Modules to Include In Package)

단계 3 필드들

엔티티 컴포넌트들(Entity Components)

파트너 필드들(Partner Fields)

단계 6 필드들(섹션 1)

일치 상세들(Reconciliation Details)

단계 9 필드들(의뢰)

이 메일 설정들(Email Settings)

부록 E-계정 편집 필드들

계정 편집 필드들

단계 6 필드(섹션 2)

새로운 계정 상세들-헤더 정보

새로운 계정 상세들-전용 부분들

계정 설정 필드들

계정 선택 필드들

설정 형태에 이용된 계정 코드들

요청기 유닛(22)의 단계들은 도 5a 내지 도 5q에 보다 상세하게 설명되어 있다. 도 5r은 사용 가능한 계정들 리포트의 예의 일부를 도시하고, 도 5s는 선택된 계정 리포트의 예의 일부를 도시한다.

도 6은 클라이언트 데이터베이스를 작성 및 관리와, 요청기 유닛(22)으로부터의 요청들에 대한 응답에 있어 관리 모듈(14)에 의해 취해진 단계들을 도시한다. 따라서, 관리 모듈(14)은 단계 26을 통해 관찰 또는 유지하기 위한 현존하는 클라이언트 데이터베이스에 대한 옵션, 단계 28을 통해 새로운 클라이언트 모듈들을 작성하고 클라이언트 계정 데이터베이스들을 유지하기 위한 등록된 어드바이저(회계사)에 대한 옵션과, 단계 30 및 32를 통해 요청자 유닛(22)으로부터의 요청에 대한 응답시에 새로운 클라이언트 모듈(12)을 작성하는 옵션을 제공한다. 모든 옵션들에 있어서, 스크립트 단계(34)가 입력되어, 관리 모듈(14)은 단계 26에서 명칭된 현존하는 계정 파일을 여는 태스크들을 실행하고, 단계 30 및 32에서 요청기 유닛(22)에 의해 요청될 때 새로운 클라이언트 계정들을 작성하기 위한 것이다.

새로운 클라이언트 계정 파일을 작성할 때, 관리 모듈(14)은 새로운 파일에 대한 계정 상세들이 요청으로 제공된 것인지의 여부를 체크하고, 그렇지 않으면, 요청으로 특정된 무역 형태가 존재하는지의 여부를 체크한다. 계정 상세들이 존재하면, 모듈(14)은 새로운 파일로 편입을 위해 제공된 계정 상세들로부터 관련된 정보를 추출한다. 계정 상세들이 제공되지 않고, 특정 무역 형태가 존재하지 않으면, 모듈(14)은 새로운 파일로 편입을 위해 무역 형태에 대한 디폴트 계정 상세들을 선택한다. 계정 상세들이나 무역 형태가 제공되지 않은 경우에, 모듈(14)은 요청된 정보에 대해 요청기에 알려준다.

스크립트 관리 단계 36은 도 6a에 설명된 것과 같은 계정 파일 유지 태스크를 수행하도록 입력된다. 다음 계정 필드들 중 어느 한 필드는 단계들 38 내지 46에 설명된 것과 같이 부가, 편집 또는 삭제될 수 있다.

계정 필드들

설정-계정 변경 필드들

단계 48에 있어서, 계정 상세에 관련된 부가적인 정보는 입력될 적당한 상세의 이용자에 알리기 위하여 제공된다. 도 6d는 부가적인 정보의 예들을 도시한다.

단계 50에 있어서, 도 6에 도시된 것과 같은 인터페이스는 클라이언트 모듈에 대한 클라이언트 상세들을 입력하기 위해 이용된다. 아래는 클라이언트 상세들의 일부이다.

오너 상세들 섹션(Owner Details Section)

회사 상세들(Company Details)

회계사 상세들(Accountant Details)

단계 52는 회계사가 새로운 클라이언트 모듈(12)을 설정하고 계정 상세들을 탬플릿 데이터베이스에 부가할 수 있도록 허용하며, 계정 상세들 중 어느 하나는 단계들 54 내지 58에 설명된 것과 같은 전용으로 선언 및 편집될 수 있다.

단계 60은 아래에 도시된 일치 엔트리들(reconciliation entries)을 유지하기 위한 것이다.

일치-메인 엔트리(Reconciliation-Main Entry)

일치-서브 엔트리(Reconciliation-Sub Entry)

계정 필드들에서 그룹 식별 필드는 다음들 중 어느 하나가 될 수 있다.

그룹 ID들

계정 코드들은 계정 필드들에서 "Code Ex"로서 식별된 다음 확장자들을 갖는다.

계정 코드들

디버깅 처리는 클라이언트에 전달하기 위해 패키지화 이전에 클라이언트 모듈(12)을 디버깅 및 테스트하는데 이용된다.

클라이언트가 새로운 클라이언트 모듈(12)을 수신할 때, 컴퓨터에 설치할 수 있으며, 모듈(12)은 통상적으로 계정들을 설정하고 종래 기술에서 공통인 세금을 할당할 필요가 없는 이용을 위해 준비된다. 또한, 계정 디스크립션들이 그와 친숙한 것들일 때 새로운 계정 용어들을 학습할 필요가 없다.

캐시북 모듈과 같은 클라이언트 모듈(12)이 동작하도록 설정될 때, 모듈(12)은 안전 체크 절차가 상기 클라이언트에 대해 디스에이블되지 않는 한 도 7a에 도시된 것과 같은 단계들로 안전 체크를 실행한다. 클라이언트가 연속으로 허용된다면, 메인 인터페이스는 동작 옵션들 중 어느 하나의 선택을 위해 제공된다. 예들 들어, "수취 엔트리" 및 "지불 엔트리" 옵션들이 선택될 때는 도 8a 및 도 8b에 도시된 것과 같은 인터페이스들을 제공하게 된다. 모듈(12)은 클라이언트 또는 회계사(어드바이저) 모드 중 한 모드로 동작될 수 있다. 클라이언트 모드가 동작된다면, 클라이언트 모드에서 동작될 때, 모듈(12)은 이용을 위해 로컬 계정 데이터베이스 파일을 열고, 플래그가 체크될 때 갱신 동작을 실행하기 위하여 차액 갱신 플래그를 열기 위해 체크된다.

도 7b는 도 8a 및 도 8b에 각각 도시된 것과 같은 "지불 엔트리" 또는 "수취 엔트리" 모두에 대한 동작 단계들을 도시한다. "수취 엔트리"에서 동작할 때, 프롬프트들의 한 세트는 거래의 세금을 계산하기 위하여 적당한 정보를 제공하도록 클라이언트에 대한 도 8c에 도시된 것들과 같이 나타난다. 도 7c는 프롬프트들 중 일부에 대한 단계들을 도시한다. 프롬프트들에 대한 코드들은 모두 계정 코드들의 I 코드들에 기초한다. 수취 프롬프트들의 실시예는 다음과 같다.

수취 질문들(Receipt Questions)

ABN을 제공하지 않기 위한 총액 공제(Amount withheld for failing to provide ABN)(도 8d)

세금 파일 번호를 제공하지 않기 위한 총액 공제(도 8e)

세금 정보(도 8e)

장기간 상업 수용(Long-term Commercial Accommodation)(도 8f)

도 7은 "지불 엔트리"에 대한 프롬프트들의 일부를 도시하고, 지불 프롬프트들에 대한 인터페이스의 예는 도 8g에 도시되어 있다. 지불 프롬프트들에 대한 코드들은 모두 계정 코드들의 E 코드들에 기초함을 주목한다. 지불 프롬프트들의 실시예들은 다음과 같다.

지불 질문들(Pay Questions)

총량 공제(도 8h)

자동차 상세들(도 8i)

인지세를 포함한 지불(도 8j)

항공료 지출(도 8k)

세금 인수(Taxed Acquisition)(도 8l)

대부금 상세(Loan Details)(도 8m)

고용 구매 상세들(Hire Purchase Details)(도 8N)

총임금(도 8ho)

무상 계약(Voluntary Agreement)(도 8p)

명목상 지불된 모든 GST를 갖는 할부(Instalment with all GST Paid up Front)(도 8q)

지금, 은행 일치 동작을 위한 인터페이스를 도시한 도 8r을 참조한다. 일치 동작에 대한 단계들은 도 7e 및 도7f에 도시되어 있다.

클라이언트 모듈(12)은 리포트 동작을 하고, 클라이언트는 디스플레이 또는 프린트될 다수의 리포트들 중 어느 하나를 선택할 수 있다. 도 8c는 리포트 또는 지불들을 디스플레이하는 모듈(12)을 구성하기 위한 인터페이스의 실시예를 도시한다. 알 수 있듯이, 클라이언트는 소스 계정을 선택할 수 있고 리포트에 대한 주간들의 리포트를 지명한다. 적용될 수 있는 경우에, 리포트는 매장이나 지점의 지불 거래 활동들에 제한될 수 있다. 도 8t는 지불 리포트의 부분들을 도시한 예이다. 다른 예들은 Pay As Yoy Go(PAYG) 리포트에 대한 도 8u, 개요 리포트에 대한 도 8v, GST 감사 리포트에 대한 도 9w, BAS 스테이트먼트 리포트에 대한 도 8x 및, 계정들 차액 리포트에 대한 도 8y가 있다.

시스템(10)은 각각의 어드바이저 회계사 모듈(13)에 대한 일반적인 원장 유닛(20)을 갖는다. 원장 유닛은 도 9a에 도시된 것과 같은 메인 인터페이스를 갖는다. 원장 메인 인터페이스의 동작 단계들은 도 9b에 도시되어 있다. 메인 인터페이스는 단계 80 및 82에 도시된 것과 같은 선택된 저널 엔트리를 편집하기 위한 회계사에 대한 저널 편집 옵션을 갖는다. 단계 84에서 저널 리포트 옵션은 저널 엔트리들의 상세들을 도 9d에 도시된 것과 같이 기록되도록 허용한다. 도9e는 단계 96 옵션을 선택함으로써 생성된 GST 감사 리포트를 도시한다. 도 9e에 도시된 계정 공개 차액 리포트들(account opening balance reports)은 단계 88을 통해 생성된다. 삭제 기능(90)은 현재의 저널 엔트리를 삭제하기 위해 제공된다.

도 10은, 관리 모듈(16)이 또는 거래 코디네이터(transaction coordinator)가 되고, 거래들에 대한 클라이언트 모듈(12)을 또한 이용하는 알려진 공급자들로부터 공급되도록 제품들에 대한 주문들을 원하는 클라이언트들의 클라이언트 모듈(12)로부터 구매 주문들을 전송하도록 배열되는 경우에, 시스템(10)의 실시예를 도시한다. 구매 주문들을 수신할 때 공급자들은 그 구매 주문들을 판매 주문들로 변환한 후에, 창고들에서 주문된 제품들을 얻거나 제품 주문들을 배치하기 위한 단계들을 취한다. 그후, 배달 및 운송은 제품들의 배달을 위해 준비된다. 또한, 인보이스들은 생성되고, 코디네이터(14)에 전송된다. 제품들을 주문한 클라이언트들이 최종적으로 제품들을 수신한 때, 코디네이터(14)에 플래그(flag)하고, 재고품 목록(inventory)에 제품을 포함시킨다. 적시에, 송금액은 공급자들에 지불하기 위해 발생 코디네이터(accrual coordinator)(14)에 전송될 것이다.

도 10a는 표준 비용들과 제품의 실제 비용들 사이의 변동들을 체킹하기 위하여 도 10에 도시된 시스템(10)의 클라이언트 (캐시북) 모듈(12)에 의해 이용되는 표준 비용 처리를 도시한다.

도 10b는 시스템(10)의 발생 배열(accrual arrangement)의 개략 흐름도이다. 알 수 있듯이, 사용자는 소비자 리스트, 재고품 목록, 리포트들 및 거래들에 관련된 동작들 중 어느 하나를 선택할 수 있다. 거래 동작이 선택될 때, 클라이언트 모듈(12)은 채무자들에 관련된 인보이스 생성, 대변 전표(credit note) 생성 및 지불들에 대한 동작들을 실행할 수 있다.

도 10c는 주문된 제품들에 대한 인보이스 생성 동작에 대한 동작 단계들을 도시한다. "인보이스 작성(create Invoice)" 선택을 수신할 때 인보이스 생성 동작은 인보이스 작성에 대한 소비자가 선택될 수 있는 인터페이스를 디스플레이한다. 그후, 소비자에 의해 주문된 제품들은 그들 단위 가격이 있는 제품 리스트로부터 선택된다. 또한, 상기 소비자에 대한 임의의 할인 배열(discount arrangement)이 검색된다. 이때, 모듈(12)은 제품들에 대해 지불 가능한 GST를 추출하고, 소비자 리스트로부터 배달 주소를 결정한다. 주문된 제품들이 해외 목적지인 경우에, GST는 적용되지 않는다. 이때, 일반적인 원장은 판매 정가(net sale value)로 갱신되고, 적용 가능한 경우에는 GST 및 할인이 배분된다. 이후, 판매 비용들은 인보이스된 값들을 모듈(12)에 대해 유보하기 이전에 일반적인 원장 및 재고품 목록에 분개(post)한다.

도 10d는 채무자 지불 동작의 단계들을 도시한다.

도 10e는 채무자 대변 전표 동작의 단계들을 도시한다. 이들 단계들은 제품이 반환될 때 재고품 목록을 조정, 갱신하고, 가격 및 품질을 조정하기 위한 인보이스를 선택 및 디스플레이하는 것을 포함한다. 또한, 일반적인 원장은 판매의 비용들, GST 및 판매 정가에 대해 조정된다. 해외 목적지들에 대해서는 수출 주문들이 재할당된다. 상품들이 지역 배달인 경우에, GST는 데빗 노트를 출력하기 이전에 재조정된다.

도 10f는 채무자 판매 주문 동작에서 단계들을 도시한다. 이 동작은 오퍼레이터가 주문을 행하는 소비자를 선택하고, 지정된 방법 및 날짜까지 배달을 위해 제품들 및 수량을 선택할 수 있도록 허용한다. 이 시스템은 주문된 제품들의 유용 성을 체크한다. 유용 가능한 경우에, 발송을 위한 배달 서류가 뒤따르는 제품 선정 리스트(products pick list)가 작성된다.

도 10g는 구매 주문 동작의 단계들을 도시한다.

도 10h는 채권자 지불 동작의 단계들을 도시한다.

도 10i는 확장된 판매 포인트로서 이용을 위해 배열된 시스템(10)의 실시예를 도시한다. 알 수 있듯이, 시스템(10)은 소비자들로서 기능을 하고 일부 공급자들로서 기능을 하는 일부 클라이언트 모듈(12)을 갖는다. 소비자 모듈(12)이 구매를 실행하는데 이용될 때, 클라이언트는 도 10g에 도시된 주문에 대한 제품들을 선택한다. 이 소비자 모듈은 도 10l에서 단계들에 의해 도시된 것처럼 작성된 소비자 글로벌 식별자로 구매 주문을 확립하기 위해 선택된 제품들을 처리한다. 구매 주문은 도 10j에 도시된 처리를 위한 관리 모듈(14)에 전송된다. 모듈(14)은 구매 주문으로부터 관련된 정보를 추출하고, 그 주문으로 확인된 공급자 모듈(12)로 주문을 전송한다. 주문을 수신할 때 공급자 모듈(12)은 그 주문을 판매 주문으로 변환하고, 도 10f에 도시된 것을 처리한다. 이후에, 세금 인보이스가 발생되고, 관리 모듈(14)에 전송된다. 이 인보이스는 공급자 글로벌 신원(supplier's global identity)을 포함한다.

관리 모듈(14)은 인보이스로부터 관련된 상세들을 추출하고, 이를 소비자에 전송하기 위해 소비자 모듈(12)의 위치를 파악한다. 도 10k 참조.

소비자 모듈(120은 인보이스를 수신할 때, 구매 주문과의 일치를 위한 체킹 단계를 실행한다. 구매된 제품들의 GST 상세들은 일반적인 원장을 갱신하기 위하여 제품 리스트로부터 추출된다.

도 10m에 도시된 것처럼, 공급자 모듈(12) 중 어느 하나는 제품 유용성 리스트를 확립하고, 도 10n에 도시된 것처럼 소비자 모듈(12)에 의해 액세스하는 방식으로 그를 처리하기 위한 관리 모듈(14)로 상기 리스트를 전송한다.

상기는 본 발명의 예시된 예를 통해 설명되었지만, 다음 특허 청구 범위에 기재된 것과 같은 본 발명의 넓은 범위 및 정신으로부터 벗어남이 없이 본 기술 분야에 숙련된 사람에 의해 많은 변경안들 및 수정안이 있을 수 있음이 명백하다.

Claims

회계 시스템(accounting system)으로서,

복수의 클라이언트 모듈들,

상기 복수의 클라이언트 모듈들을 관리하기 위한 관리 모듈, 및

상기 복수의 클라이언트 모듈들과 연관된 적어도 하나의 어드바이저 모듈을 포함하고,

상기 관리 모듈은 관리 컴퓨터 서버에 인스톨되도록 적응되고, 각각의 클라이언트 모듈은 구성 정보에 대응하여 동작하도록 상기 관리 모듈에 의해 구성되고, 상기 관리 컴퓨터 서버에서 떨어진 클라이언트 컴퓨터 유닛에 인스톨 되도록 생성되고,

상기 관리 모듈, 상기 복수의 클라이언트 모듈들 및 상기 적어도 하나의 어드바이저 모듈은 통신 네트워크를 통해서 통신하도록 배열되고,

상기 관리 모듈은

i) 상기 적어도 하나의 어드바이저 모듈 및 사용자 중 적어도 하나로부터 요청받은 클라이언트 모듈을 구성하기 위해 계정들 구성 정보를 수신하도록 배열되고, 지명된 경우에 상기 요청받은 클라이언트 모듈을 어드바이저 모듈에 연관시키도록 배열되는 요청 수단,

ii) 상기 사용자 및 어드바이저 모듈을 위해, 지명된 계정에 연관된 계정 디스크립션 및 상기 지명된 계정 내의 계정들 항목에 연관된 디스크립션을 작성 및 편집하도록 배열되는 스크립팅 수단,

iii) 상기 요청하는 어드바이저 모듈 및 상기 사용자 중 적어도 하나에 의해 지명된 엔티티(entity) 타입 카테고리 및 비지니스 타입 카테고리와 연관된 프롬프트(prompt) 메시지들을 상기 요청하는 어드바이저 모듈 및 요청하는 클라이언트 컴퓨터 유닛 상에 표시하도록 배열되고, 상기 구성 정보에 포함되도록 상기 프롬프트 메시지들에 제공된 정보를 추출하도록 배열되는 정보 취득 수단,

iv) 상기 구성 정보에 포함된 엔티티 타입 카테고리 및 비지니스 타입 카테고리와 정합하는 클라이언트 계정들을 추출하는 계정들의 마스터 차트, 및

v) 추출된 계정들에 따른 계정들의 적어도 하나의 클라이언트 차트로 구성된 상기 요구된 클라이언트 모듈을 생성하기 위한 계정들 생성 수단을 포함하고;

상기 복수의 클라이언트 모듈 각각은 거래 기록들을 입력하기 위한 거래 입력 수단, 저장 매체에 저장되어 있는 미리 할당된 거래 카테고리 코드들, 상기 거래 입력 수단을 통해 입력될 거래 기록과 연관시키기 위해 미리 할당된 카테고리 코드를 선택하기 위한 수단, 및 상기 거래 기록이 연관되어야 하는 계정의 선택을 위한 계정들의 적어도 하나의 클라이언트 차트을 포함하고,

상기 계정들은 거래를 위한 세금 옵션들 중 적어도 하나를 고려하여 상기 프롬프트 메시지에 제공된 상기 정보 및 상기 구성 정보에서 미리 지명된 상기 엔티티 타입 카테고리 및 상기 비지니스 타입 카테고리의 계정들에 따라 상기 프롬프트 메시지에 제공된 상기 정보에 의해 미리 결정되고,

상기 계정들 각각은 미리-할당된 고유한 계정 식별(account identification) 및 상기 어드바이저 모듈과 상기 사용자 중 적어도 하나에 의해 규정되고 엔티티 타입 카테고리 및 비지니스 타입 카테고리와 매칭되는 무역업자들에 의해 일반적으로 채택되는 계정 디스크립션(account description)을 포함하고,

상기 카테고리 코드들 각각은 과세(taxed)와 비과세(non-taxed) 중 하나 및, 지출과 수입 거래 형태 중 하나로서 미리 명시되고,

상기 관리 모듈은 공급자 데이터베이스를 포함하고,

상기 공급자 데이터 베이스는 특정 제품 타입들의 공급자로서 지명되고, 임의의 클라이언트 모듈을 위해, 제품 타입의 공급자를 선택하기 위한 상기 공급자 데이터베이스에 엑세스하는 클라이언트 모듈을 포함하고,

상기 공급자 데이터 베이스는 공급자 클라이언트 모듈을 선택하면서, 선택된 공급자 클라이언트 모듈의 제품들 리스트를 표시하도록 배열되고,

상기 관리 모듈은 구입 클라이언트 모듈과 공급자 클라이언트 모듈 사이의 거래 활동을 조정(coordinating)하도록 배열되는 조정 유닛(coordination unit)을 포함하고,

각각의 클라이언트 모듈은 고유한 클라이언트 레퍼런스가 할당되고, 공급자 클라이언트 모듈의 제품 각각은 상기 공급자 클라이언트 모듈의 상기 클라이언트 레퍼런스에 연관된 제품 레퍼런스를 가지고,

각각의 클라이언트 모듈은 상기 관리 모듈의 상기 공급자 데이터 베이스에 엑세스 하고 선택된 공급자 클라이언트 모듈의 적어도 하나의 제품을 선택하도록 적응되고, 상기 조정 유닛을 통해 상기 선택된 공급자 클라이언트 모듈로 상기 선택된 제품을 위한 구입 주문을 전송하도록 적응되고,

상기 구입 주문은 상기 구입 클라이언트 모듈의 상기 클라이언트 레퍼런스, 상기 공급자 클라이언트 모듈의 상기 클라이언트 레퍼런스 및 상기 선택된 제품의 상기 제품 레퍼런스를 포함하고,

상기 공급자 클라이언트 모듈은 판매 주문으로의 통합을 위해 상기 클라이언트 및 제품 레퍼런스들을 추출하도록 적용되는, 회계 시스템.
삭제
제 1 항에 있어서,

상기 비지니스 타입 카테고리는 사업의 임의 클래스에 연관된 상품들 또는 서비스들의 제공과 연관되는 무역 활동들(trading activities)을 포함하는, 회계 시스템.
제 1 항에 있어서,

각각의 클라이언트 모듈은 상기 거래 기록들의 세금들(tax liabilities)에 연관된 정보를 취득하기 위한 수단을 포함하고,

상기 정보 취득 수단은 세금들을 갖는 복수의 거래 카테고리 코드들 각각과 연관된 적어도 하나의 프롬프트(prompt)를 갖고,

상기 카테고리 코드 중의 하나가 입력될 거래로 지명될 때 세금들에 연관된 정보를 입력하기 위해 상기 연관된 적어도 하나의 프롬프트를 표시하고, 상기 거래의 세금들 할당하기 위해 상기 입력된 정보를 추출하도록 배열되는, 회계 시스템.
제 4 항에 있어서,

상기 적어도 하나의 프롬프트는 지정된 위치(들)에 상기 연관된 세금 정보를 입력하도록 클라이언트를 프롬프팅하기 위한 적어도 하나의 유도 질문의 형태이고,

상기 클라이언트 모듈은 상기 지정된 위치(들)에서 상기 입력된 정보를 추출하고, 상기 지정된 위치에서의 상기 추출된 정보 또는 상기 지정된 위치들에서의 각각의 추출된 정보에 대해 특정한 세금 결정 절차를 적용하도록 배열되는, 회계 시스템.
제 1 항에 있어서,

상기 클라이언트 모듈은 회계 리포트들을 생성하기 위해 상기 입력된 거래 기록들을 액세스하도록 배열된 리포트 생성 수단을 갖는, 회계 시스템.
제 6 항에 있어서,

상기 리포트 생성 수단은 생성을 위한 다수의 회계 리포트들 중 어느 하나를 선택하기 위한 리포트 선택 배열(report selection arrangement)을 포함하는, 회계 시스템.
제 6 항에 있어서,

상기 과세된 카테고리 코드들 중 적어도 하나는 상기 회계 리포트들 중 하나가 되는, 과세 리포트(taxation report)에 대한 과세 세그먼트들(taxation segments)에 미리 할당되는, 회계 시스템.
제 8 항에 있어서,

상기 과세 리포트는 상품 및 서비스 세금(the Goods and Services Tax)(GST)에 따른 기업 활동 스테이트먼트(Business Activity Statement)(BAS)인, 회계 시스템.
제 1 항에 있어서,

가변 세금 할당을 갖는 과세된 카테고리 코드가 입력되는 경우에, 할당될 총액(amounts)을 지정하기 위한 프롬프트들을 갖는 윈도우가 상기 총액을 입력하기 위해 표시되는, 회계 시스템.
제 10 항에 있어서,

상기 카테고리 코드는 상기 계정들의 클라이언트 차트내의 임금 계정(wage account)과 연관되는, 회계 시스템.
제 1 항에 있어서,

상기 거래 기록들을 저장하기 위한 저장 수단을 더 포함하고, 통신 네트워크를 통해 은행 스테이트먼트 기록들(bank statement records)을 액세스하도록 배열되는, 회계 시스템.
제 12 항에 있어서,

상기 클라이언트 모듈은 상기 저장된 거래 기록들을 상기 은행 스테이트먼트 기록들로 일치시키는 일치 수단(reconciliation means)을 포함하는, 회계 시스템.
제 1 항에 있어서,

상기 어드바이저 모듈은 회계 리포트들 및 관리 리포트들을 생성하기 위한 연관된 클라이언트 모듈로부터 전송된 거래 기록들을 액세스하도록 배열되는 리포트 생성 수단을 가지는, 회계 시스템.
제 14 항에 있어서,

상기 리포트 생성 수단은 생성을 위한 다수의 회계 및 관리 리포트들 중 어느 하나를 선택하기 위한 리포트 선택 배열을 포함하는, 회계 시스템.
제 1 항에 있어서,

계정들의 상기 클라이언트 차트는 내부의 상기 계정 식별들 및 상기 계정 디스크립션들이 사용자에 의해 변경될 수 없도록 고정되는, 회계 시스템.
제 1 항에 있어서,

상기 관리 모듈은 사용자에 의해 명시되는 것처럼 거래 코드들을 생성하기 위한 거래 코드 생성 수단을 포함하는, 회계 시스템.
삭제
제 1 항에 있어서,

상기 조정 유닛은, 이어서, 상기 판매 주문을 위한 수신된 인보이스(invoice)를 상기 공급자 클라이언트 모듈로부터 구매 클라이언트 모듈로 전송하기 위해 상기 클라이언트 레퍼런스를 사용하도록 배열되는, 회계 시스템.
제 19 항에 있어서,

상기 인보이스의 지불 기록은 상기 관리 모듈을 통해 전송되어, 상기 조정 유닛은 상기 인보이스가 결제된 기록을 상기 공급자 클라이언트 모듈과 통신하는, 회계 시스템.
제 20 항에 있어서,

저장 수단은 공급자들과 구매자들 사이의 거래 정보를 저장하도록 배열되고,

상기 조정 유닛은 거래들에 대한 재고들(stocks)이 미리 결정된 레벨들 이하로 될 때 구매 주문들을 자동화하도록 배열되는, 회계 시스템.
제 1 항에 있어서,

상기 복수의 클라이언트 모듈들 각각은 상기 적어도 하나의 어드바이저 모듈과 연관되어,

연관된 클라이언트(들)에 저장된 상기 거래 기록들이 원격으로 액세스될 수 있는, 회계 시스템.
제 1 항에 있어서,

상기 클라이언트 모듈은 캐시북 모듈(cashbook module), 발생 모듈(accrual module), 조합된 캐시북 및 발생 모듈, 급료 모듈(payroll module), 판매 포인트 모듈(a point of sale module), 및 상기 모듈들의 둘 이상의 임의의 조합 중 어느 하나인, 회계 시스템.