Drunken Lion

FI 용어 정리 1/3 본문

SAP/FI

FI 용어 정리 1/3

DrkLion 2007. 10. 29. 10:40

Account (계정)

전통적으로 계정 (Account) 이라고 하면 경리 (재무회계) 에서 기표가 이루어지는 대상이 되는 계정과목 또는 계정코드를 의미한다. 그러나 SAP 에서는 Account 개념을 보다 확장하여 사용하고 있으므로 주의를 요한다. SAP 에서는 다음과 같이 Account 다섯 가지의 유형으로 구분하고 있으며, 이러한 유형구분을 Account Type 이라고 한다.

Account Type

M G/L 계정 (전통적인 계정과목/계정코드)

D

Customer (판매거래처, 기존의 거래처코드)

K

Vendor (구매거래처, 기존의 거래처코드)

A

Asset (고정자산 번호, 기존의 자산번호)

M

Material (재고자산(자재)번호)

이렇게 Account 개념범위를 확장한 것은 계정과목 중심의 총계정원장 (General Ledger) 상의 금액과 거래처나 고정자산 번호, 자재번호 중심의 보조부 (Sub-ledger) 상의 금액을 일치시키고, 물류프로세스의 재무회계와의 통합성을 가능하게 하기 위해서 이다.

, 전통적으로 AR (매출채권), AP (매입채무), 고정자산등과 관련된 회계전표를 기표하는 경우 해당 계정코드를 지정하고 금액을 입력한 , 거래처나 고정자산 관련 정보를 전표상의 관리항목으로 관리하는 방식을 택하고 있는 데에 반하여, SAP 해당 Customer, Vendor, Asset 번호를 마치 기존의 계정코드인 것처럼 기표를 하면, 연결이 되는 계정코드(SAP G/L Account) 자동으로 결정되는 방식으로 되어 있다.

 

 

Account Assignment (계정지정)

거래가 어떤 계정에 전기될 것인지를 명시하는 .

추가계정 지정참조

 

 

Account Group (계정그룹)

마스터 레코드 입력을 제어하는 속성들의 요약으로 마스터 레코드는 하나의 계정 그룹에 지정되어야 한다. 계정그룹에 따라 마스터 레코드에 어떠한 Data 필요한지가 결정되면 마스터 레코드의 번호가 정해진다.

 

 

Account Management (계정의 관리)

계정은 관리방식에 따라 미결관리 (Open Item Management) 하는 계정과 미결관리를 하지 않는 (Non-Open Item Management) 계정으로 나눌 있다. 미결관리를 하게 되면 계정에 기표 건별 항목들은 반드시 반제처리 (Clearing) 의해서 미결상태가 정리 (Cleared) 된다. 현금이나 예금과 같은 계정은 업무상으로 미결관리의 의미가 없거나 불가능하므로 미결관리를 하지 않는 계정으로 설정하게 된다.

Customer Vendor 경우에는 선택여부에 관계없이 시스템적으로 무조건 미결관리를 하는 것으로 설계되어 있으며, G/L 계정의 경우에만 미결관리여부를 선택할 있다. Asset 경우에는 명시적이지 않으나 미결관리를 하는 개념이며, Material 경우에는 그렇지 않다.

한편, 계정을 조회하는 경우 잔액조회 뿐만이 아니라, 기표 건별로 조회를 하는 경우도 있는 , 이러한 선택사항을 Line Item Display 라고 한다. 따라서 예금계정의 경우 미결관리는 하지 않으나 건별 조회는 가능하도록 설정 (G/L계정 마스터에서) 있다. 일반적으로 거의 모든 계정에 대해 건별 조회가 가능하도록 하는데, 경우 정보조회에 편리한 반면 DB Space 많이 차지한다는 단점을 가진다.

Account Reconciliation (계정조정)

회계가 GAAP (General Accepted Accounting Principle) 어긋나지 않도록 이루어 지는가를 결정하는 절차. G/L 계정 잔액이 전기 거래의 총합과 비교된다. 고객계정의 잔액과 구매처 계정잔액이 각각 채권잔액,채무잔액 전기된 거래와 비교된다.

 

 

Account Type (계정유형)

하나의 계정이 어떤 회계 영역에 속하는지를 알려 주는 키로서 예를 들면 Asset(고정자산), Customer (고객), Vender (구매처), Mat (자재 ), G/L 등이 있다. 동일한 계정번호가 서로 다른 계정 유형에 사용될 있으므로 계정을 파악하기 위해서는 계정번호와 계정유형이 모두 필요하다.

 

 

 

Accounting Principle (기표원칙)

SAP Customer, Vendor, Asset 등의 보조부관련 계정을 중심으로 기표하면, 시스템이 자동으로 General Ledger Sub-ledger 동시에 금액을 반영하는 구조로 되어 있으며, 이를 Accounting Principle 이라고 부르기도 한다. Accounting Principle 하에서는 총계정원장과 보조부가 원천적으로 금액이 다를 수가 없으므로, 결산 많은 시간을 차지하는 Reconciliation 작업이 필요 없게 된다. 이러한 기표방식은 물류와의 통합상황을 가정하면 장점을 가진다. 판매, 구매, 재고관리 등의 업무처리 시에는 거래처 (Customer, Vendor) 자재번호를 중심으로 거래처리를 하고 이를 기준으로 재무회계전표가 생성될 사전에 정한 G/L 계정으로 자동기표가 생성되게 된다.

참고로 외상매출금, 외상매입금 거래처와 관련된 계정들은 사전에 Customer Vendor Master Record 정의된 계정으로 자동결정 되며, 이를 Reconciliation Account 라고 부른다. 고정자산의 경우에는 Asset Class 경유하여 사전에 정의된 고정자산과 관련된 여러 계정 (건물, 감가충당금, 고정자산 처분손실 ) 자동으로 정해지도록 되어 있으며, 자재 (Material) 관련하여서는 별도의 Customizing 작업에 의해 관련 G/L 계정들이 자동 결정된다.

 

 

Accounting Transaction (회계거래)

다른 EDP 거래들과는 대조적으로 SAP 거래는 항상 Document Header (거래 표제부) 최소 2개의 Line Item (개별항목) 으로 구성된다.

차변 값과 대변 값은 동일해야 하며 회계거래를 전기 시스템은 계정 잔액을 갱신한다. 회계거래는 사업거래를 시스템에 기록한다.

 

 

Additional Account Assignment (추가 계정 지정)

계정번호, 금액, 전기키 이외에 필요에 따라 선택적으로 입력되는 개별 항목과 관련된 모든 추가 Data 예를 들면 대금지급조건, 지급방식, 코스트센터 등이 추가 Data 해당된다.

 

 

Allocation Concept (할당개념)

계정의 개별 항목들이 화면 출력될 분류되는 방식

유사어: Sorting Concept(분류개념)

 

 

Authorization

실제로 시스템이 사용되는 상태에서는 사용자의 직급 또는 속한 부서등에 따라 시스템상에서 접근할 있는 정보나 거래 처리를 제한 필요가 있다. 이러한 SAP R/3 시스템에의 접근 권한을 통칭하여 Authorization 이라고 한다. SAP 표준으로 제공하고 있는 기능 Configuration 활용하여 Authorization 체계를 구성할 있으며, 이것이 필요한 경우에는 일부 시스템을 수정할 필요가 있게 된다.

 

 

Balance (계정잔액)

계정에 전기 .대변이나 전표의 /대변의 차액

잔액은 대변금액이 차변 금액보다 많을 경우에는 "대변잔액" 으로 차변이 대변 금액보다 많을 경우에는 "차변잔액" 으로 불린다.

 

 

Balance Audit Trail (계정잔액 감사 증적)

회계년도 기간이나 여러 기간 동안에 어떤 계정의 모든 거래내역을 기록한 . 잔액 감사 증적은 기초의 잔액과 기말까지 계정에 전기 차변과 대변 엔트리를 보여 준다.

 

 

Balance Verification (잔액검증)

회계전표가 정확히 입력되었는지를 확인하는 절차. 차변과 대변의 금액이 반드시 같아야 한다.

 

 

Bill-to party

납품한 제품 또는 서비스에 대한 송장을 수령하는 사람 또는 회사.

 

 

B/S Adjustment (대차대조표조정)

대차대조표를 작성하기 전에 준비를 한다.

특별히 준비해야 사항은

- 외화로 전기 채권, 채무, 고정자산 금액을 환산하여 조정

- 조정계정이 바뀔 경우 채권과 채무를 조정

- 대변 잔액을 가진 고객계정 차변잔액을 가진 구매처 계정을 조정

- 잔여 일수에 따라 채권과 채무를 분류하기 위해 조정

 

 

Cash Discount (현금할인)

일정기일까지 대금이 지급될 경우 예정 대금액으로부터 공제되는 .

 

 

Cash Management and Forecast (현금관리와 예측)

여유 현금과 현금 소요량에 대한 중단기 계획

유사어: 현금관리 위치

 

 

CBO Modification

SAP 표준으로 제공하고 있는 기능이나 프로세스가 회사의 실정에 비추어 부족하거나 적합 하다고 판단이 되는 경우에는 일부 기능을 개발하거나 표준 기능/프로세스를 변경하는 경우가 있다.

CBO (Customer Bolt-On) Enhancement 라고 불리기도 하는데, SAP R/3 표준기능, 테이블들에 영향을 미치지 않는 상태에서 추가 기능을 개발하는 것을 말한다. 추가적인 Report 개발은 일반적으로 CBO 라고 표현하지 않는다. Modification SAP 표준기능을 직접 변경하는 것으로서, 기술적으로는 Source code 표준 Table 필드를 변경하는 작업을 말한다.

일반적으로 SAP 사는 Modification 권고하지 않는데, 이유는 SAP 전체적인 기술구조에 대한 명확한 이해가 없는 상태에서 표준 Source Code 테이블을 건드리는 작업이 예기치 못한 다른 영향을 미칠 수도 있기 때문이다. 또한 Modification 내용은 Version Up 반영이 되지 않으므로 이를 계속적으로 유지 보수 해야 하는 부담도 회사가 감수해야 한다.

 

 

Change Document (변경전표)

마스터 레코드, Table, Transaction 등의 변경 Data 담고 있는 기록

 

 

Chart of Account (계정과목일람표)

총계정원장 계정의 모든 마스터 레코드를 체계적으로 정리해 놓은 목록으로 동일한 계정과목 일람표를 여러 개의 회사코드가 사용할 있다.

계정과목일람표에는 모든 총계정원장계정과 계정번호, 계정과목명, 관리정보가 들어 있다. 하나의 Client 여러 개의 계정과목일람표를 정의 있다. 회사코드는 반드시 계정과목일람표를 지정하여야 한다.

 

 

Chart of Accounts (계정과목표)

회사의 경리 (또는 재무회계) 시스템에서 기표가 이루어지는 계정과목/계정코드 들을 모은 것을 일반적으로 Chart of Accounts (COA) 라고 하는데, SAP 에서도 동일한 의미로 사용하고 있다. 다만 정확하게 표현하면 G/L Account 들의 묶음이라고 있는데, G/L Account 구체적인 의미는 다음에 살펴 보기로 한다.

SAP Customizing 하는 경우 CoCd (회사코드) 정의하면서, 회사가 어떤 COA 사용할 것인가를 정의하도록 되어 있다. 하나의 시스템을 여러 회사가 공유하는 경우, 이상의 회사가 같은 COA 사용하는 것으로 정의할 있다. , COA CoCd 관계는 1 : N 이다. 이런 이유로 SAP FI 조직구조를 설명하는 경우 COA CoCd 상단에 표시하는 경우가 있는데, 이는 COA CoCd 연결관계를 나타낸 것일 COA 조직코드는 아닌 것에 유의하여야 한다.

회사가 실제 기표에 사용하고 있는 COA Operative Chart of Accounts 라고 부르기도 하는데, 연결회계등의 그룹차원의 Data 집계를 위해 Operative COA 기준으로 기표 것들을 그룹계정으로 전환할 수도 있는데, 이러한 그룹계정의 묶음을 Group Chart of Accounts 라고 한다. 한편 Operative COA 이외에 나라에서 통용되는 계정들로 전환을 하는 것이 필요한 경우도 있는데, 이러한 목적의 COA Country Chart of Accounts 라고 한다.

 

 

Clearing (반제)

계정의 미결 항목들을 반제 대금처리가 끝나거나 결제된 것으로 처리하는 과정. 미결항목으로 반제 있다. 예로 고객이 송장에 대한 대금을 지불하면 해당 미결 항목을 결제된 대금으로 반제할 있다.

'SAP > FI' 카테고리의 다른 글

[FI] 자산의 해당연도 거래 금액을 가져오는 펑션  (0) 2009.09.09
FI exit 조회 및 수정 T-code  (0) 2009.07.20
Vendor 생성 / Customer 생성 T-code  (0) 2008.07.07
FI 용어 정리 3/3  (2) 2007.10.29
FI 용어 정리 2/3  (0) 2007.10.29