학습 일지

SAP에서 Class의 Method나 Function Module 혹은 Subroutine( Perform )

을 작성하다보면 모두 파라미터를 주고받는 방식으로 작성하게 된다.

이때 Pass by Value와 Pass by Reference의 차이점을 알아보자.

Pass by Value

Pass by Value는 실제 파라미터를 보낼 때 복사본을 만들어서 사용한다고 보면 된다.

프로시저가 호출되면 파라미터와 반환 값이 초기화 된다.

입력 파라미터는 호출 시 실제 파라미터 값을 받지만,  반환 될 때 초기화가 되기에 

Return을 사용할 경우에 값을 전달 받을 수 있다.

즉, 매개변수가 Method나 Function Module 혹은 Subroutine( Perform ) 안에서 변화가 된다고 해도

복사된 입력 파라미터에만 영향을 미치기 때문에 기존 실제 파라미터에는 영향을 주지 않는다.

이렇기 때문에 Pass by Value는 대용량 데이터를 처리할 경우 메모리와 시간이 많이 들 수 있는 단점이 있다.

Pass by Reference

Pass by Reference는 실제 파라미터를 보낼 때 Reference ( Pointer ) 를 포함하여 보낸다고 보면 된다.

프로시저에 전달되고 실제 파라미터와 함께 작동하는 경우다.

즉, 매개변수가 Method나 Function Module 혹은 Subroutine( Perform ) 안에서 변화가 된다면

실제 파라미터값도 동일하게 변경된다.

그렇기에 Pass by Value에 비해 대용량 데이터 처리를 할 경우 퍼포먼스 측면에서는 확실 히 더 좋은 장점이 있다.

다만, Pass by Reference는 실제 데이터 값을 변경시키기 때문에 증간에 결과가 변경될 수 있어

잠재적은 부작용을 일으킬 수 가 있어서 주의가 필요하다.

Perform 문을 구성할 때 Using / Changing / Tables 를 사용하는데 먼저 이것부터 이해하고 예시를 보겠습니다.

Using은 값을 던져주는 것이고,

Changing은 값을 던지고 받아오는 것,

Tables는 Table을 넘겨서 받아오는 것으로 이해하면 쉽다.

자 그러면 Using과 Changing을 먼저 이해해보도록 하자.

다음과 같이 작성을 하고 실행을 해보면 다음과 같은 결과가 나온다.

Using과 Changing은 결국 값을 변환시키고 내뱉는다. 

즉 Pass by Reference 로 실행이 되는 것이다. 

사실 Using과 Chaning은 차이 없이 값이 변경되어 나오기 때문에 차이가 없고 똑같은 기능이다.

하지만 Value라는 값으로 감싸주면 두개의 기능이 차이가 생긴다.

같은 코드에 Value 구문을 추가해서 실행을 시켜보자.

Using은 초기 파라미터 값이 변경되어 나오지 않은 반면 Changing은 변경되어 나온다.

이부분에서 왜 Using과 Changing 구문이 나눠지는지 알 수 있는 부분이다.

Using은 Value구문을 쓰면 Pass by Value가 되고

Chaning은 쓰나 안쓰나 Pass by Reference가 되는 것이다.

명시적인 표현으로 구분을 하기 위해서는 Using구문에서는 value를 사용하여 Pass by Value로 사용하고

Pass by Reference로 사용하려면 Changing 구문을 사용하는게 맞는 것 같다.

자 그러면 참조변수로 설정 되어있는 값에 대해서는 어떻게 변경되는지도 확인을 해봐야

좀 더 깊게 이해를 한다고 생각한다.

하나는 Value로 하나는 New로 변수가 아닌 Structure 타입으로 생성을 해보자.

디버깅을 태워보면 Value와 New의 차이점을 볼 수 있다.

Value는 Structure타입으로 생성을 해주고 New는 해당 Structure를 Reference 변수로 생성을 한다.

그렇기에 addr_ref2는 -> 동적 개체 할당 기호를 사용하여 접근을 해야한다. 

그러면 생성된 2개의 값을 Using value를 사용하여 Pass by Value로 보내본다.

그리고 실행을 해보면 결과는 다음과 같다.

참조변수로 생성된 값은 Perform문을 통하여 Pass by Value로 보낸다고 해도

Subroutine 내에서 값이 변경되면 파라미터가 변하기 때문에 Using Value가 먹히지 않는 것을 알 수 있다.

이렇게 Pass by Value 와 Pass by Reference 차이를 알아봤다.

Class의 Method나 Function Module 혹은 Subroutine( Perform ) 작성할 때 

어떤 값을 value로 할지 reference로 할지 생각하자.

Tax코드는 세금코드다. 세금에는 국가에 내는 국세와 지방 자치 단체에 내는 지방세가 있다.

세금 중 특히 부가가치세는 고객과 구매처를 통한 모든 채권/채무 거래에 발생한다.

그래서 채권/채무 전표에는 부가가치세가 기표되어 처리된다.

부가가치세는 국세의 일부로 국세청의 세무서에 신고를 해야 하기에 전표 입력시에

세무서가 설정된 조직단위인 Business Place 가 반드시 입력되어야 한다.

해당 IMG경로에서 세무서를 설정할 수 있으며,

이렇게 설정된 세무서는 Define Business Place 에서 Business Place 와 Assign된다.

이렇게 연결을 해주면 전표 입력 시 Business Place만 입력하면 자동으로 세무서 정보가 들어가고

이 Business Place 값을 이용하여 월말에 세무신고 작업을 할 수 있다.

또한, 물동부분에서 자동으로 넘어오는 전표인 경우에는 Business Place를 입력할 수 없다.

그래서 물동에서 사용되는 Plant(플랜트)에 company code 와 Business Place를

연결해놓으면 Plant 정보만으로 company code와 business place정보를 자동으로 가져온다.

하나의 기업에는 여러 개 Business Place가 등록되어 사용될 수 있다.

그 중 대표 Business Place가 있을 수 있으며 이 정보는 Company code 설정화면에서 설정할 수 있다.

해당 IMG 경로에서 Global Parameters 들어가서 위에

Additional Data 버튼을 누르면 Head Office business place 설정이 가능하다.

Section Code

급여 및 소득 지불해야 할 원천세에는 소득세와 주민세가 포함된다.

소득세는 국세이기에 business place가 등록되어야 하지만,

주민세는 지방세이므로 지역관청이 등록되어야 한다.

세무서 및 지역관청 정보가 등록 되어야 하는데

이는 Section Code로 등록이 되어 사용된다.

해당 IMG 경로에서 지역관청을 설정하고 이 지역관청을 section code에 등록해야 한다.

이렇게 하면 Section Code에 Business Place와 지역관청을 모두 Assign할 수 있다.

Tax Procedure

매입과 매출전표에서 여러가지 세금 중 꼭 반영되어야 할 세금이 부가가치세다.

부가가치세는 국가마다 차이가 있기에 국가별로 세금을 계산하기 위한

기본이 되는 절차를 생성해야 하는데 이것이 바로 Tax Procedure다.

SAP에서는 기본적으로 사용할 수 있는 국가별 Tax Procedure을 제공하고 있다.

위 IMG 경로에서 국가별 설정되어 있는 것을 확인할 수 있다.

'TAXKR' Tax Procedure가 국가 'KR'에 연동된 것을 알 수 있다.

이렇게 제공된 Tax Procedure을 사용할 수 있으며,

필요하다면, 새로운 Tax Procedure를 만들고 새로 만든 것을 국가 코드별로 Assign 할 수 있다.

기본적으로는 하나의 국가코드에는 하나의 Tax Procedure만 연결하여 사용 가능하다.

위 화면은 TAXKR의 Control Data화면이다.

Condition Type은 세금계산 시 Rate(퍼센트율), Commercial(사사오입)

혹은 Round up(항상 올림), Round Down(항상 내림) 중

하나의 값으로 할 것인지 등에 대하여 설정 할 수 있다.

그 중 BASB는 세금계산에서 기본 Base가 되는 금액이다.

'KROT'는 Output Tax(매출부가세)로 위의 그림 보면 From Step : 100으로 설정되어 있는데,

이는 Step '100' 인 'BASB' 금액을 기준으로 계산한다는 의미다.

Account Key는 해당 IMG 경로에서 설정 가능하다.

Tax Type을 Output / Input / Additional / Not relevant to tax 인지 설정 할 수 있다.

또한, 별도의 세금라인이 자동으로 생성(Posting indic.)되게 할 것인지,

불공제(Not deductible) 처리를 해야 하는지 설정 가능하다.

불공제는 전표에서 별도의 세금라인은 생기지 않고, 매출이나 채무 항목내에 세금이 포함되어 있는 것을 말한다.

부가세 신고대상이지만 별도의 부가세 라인은 생기지 않는다.

전표에는 보이지 않지만 신고를 위한 세금 레코드는 별도로 만들어져서 저장되어진다.

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다. 

생성되어 있는 재무전표를 변경하고 싶을 때,

어떤 필드를 변경할 수 있을지의 변경규칙을 설정할 수 있다.

전표 헤더의 필드와 라인항목에 대한 설정이 가능 하다.

Header부분은 변경할 수 있는 필드가 제한되어 있다.

해당 필드들에 대해 설정을 할 수 있으나, 실제 전표 헤더 수정가능한 필드는

Header Text 와 Reference 두개 필드라고 보면 된다.

전표 헤더 필드에 대한 통제는 Account Type별이나 Special G/L의 Trans. Type별

그리고 Company Code별로 설정이 가능하지만,

위에 세팅한 것처럼 모든 타입에 대하여 다 변경 가능하도록 설정한다.

전표 라인항목도 헤더부분과 마찬가지로 Account Type, Trans. Type, Company Code 별로 설정할 수 있다.

Text필드를 제외한 대부분의 필드들을 변경하기 위해서는 아래 조건에서 가능한 경우가 대다수다.

1. 전기기간(Posting Period)이 열려 있다.
2. 라인아이템이 반제(Clearing)되거나 역분개(Reverse)되지 않아야 한다.
3.  관련된 Credit Memo Invoice가 없어야 한다.
4.  Down Payment로부터 관련된 Credit Memo가 없어야 한다.

Reverse and Negative Posting

SAP에서 이미 생성된 재무전표는 물리적으로 삭제나 중요필드 변경이 불가능하다.

금액을 변경하거나 전표를 취소하려면 차변과 대변이 서로 반대되는 역분개(Reverse)전표 방식으로 처리를 해야한다.

전표 역분개 방법은 Normal Reverse Posting 방식과 Negative Reverse Posting 방식이 있다.

1) Normal Reverse Posting

역분개된 계정의 금액이 반대편으로 나타나서 각 차변과 대변에 금액이 그대로 남아 있으며

단순 합계잔액만이 0으로 표시되는 방식이다. (차/대변에 동일한 금액이 남아 있음)

2) Negative Reverse Posting

발생한 차/대변 항목에 마이너스로 해당 금액을 표기하는 방식이다.

차변이나 대변이나 모두 각각 금액이 0원으로 표기되고, 잔액도 0원으로 표기되어

역분개 금액이 보이지 않는 방식이다.

이러한 방식은 역분개된 금액이 과대 계상되어 보이지 않으므로 실제로 대부분 Negative 방식을 사용한다.

Reverse된 전표번호에 Additional Data를 누르면 Negative 체크 여부로 어떻게 처리되었는지 알 수 있다.

Negative Reverse Posting을 하기위해서는 3곳에서 설정이 필요하다.

첫번째는 Company Code에서 허용하도록 설정.

해당 IMG 경로를 통해 Negative Posting을 허용 할 수 있다.

Negative Postings Permitted 필드 체크를 하면 해당 Company Code에서 Negative Posting이 가능하다.

두번째는 Reason Code에 Negative Posting 허용 설정

역분개 T-Code : FB08에 들어가보면 Reversal Reason을 필수 값으로 입력하게 되어있다.

해당 설정은 위 IMG 경로 Define Reasons for Reversal에서 처리 가능하다.

Reversal Reason 코드에서 Negative Posting 필드를 체크하면 Negative Posting이 가능하다.

Alternative Posting Allowed 설정은 이전 전기기간으로의 Posting을 허용할 것인지에 대한 체크다.

체크되어 있지 않다면 당월로만 역분개가 가능하다. (체크 된 경우 이전월로도 역분개 가능)

세번째는 전표타입(Document Type)에서 설정해야한다.

4장에서 Document Type 설정에서 Negative Posting Permitted 필드 부분 체크여부에 대해 설명 했다.

정리하면, Negative Reverse Posting을 하기위해서는 아래 3가지가 필요하다.

1) Company Code에 Negative Posting 관련 부분 설정

2) Reason Code에 Negative Posting 필드 체크 여부

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다.  

Fiscal Year는 회계 결산기간 설정하는 회계 연도를 의미한다.
 

국가에 따라 1년을 회계연도로 하는 방법이 다르다.

1) Calendar Year = Fiscal Year.

우리나라와 같이 회계연도를 매년 1월1일부터 12월31일까지

달력월이 Fiscal Year의 Period와 동일한 경우다.

2) Calendar Year <> Fiscal Year.

일본, 영국 같은 경우 당해 년도 4월부터 내년 3월인 4~3월제를 사용한다.

실제 달력상 년도와 SAP Posting Period(전기기간)의 Fiscal Year가 같지 않은 경우다.

SAP에서는 최대 16Period까지 설정하여 사용할 수 있다.

13~16 Period는 Special Period라고 불리는데, 주로 IFRS 조정 혹은 연말결산 등을 위하여 사용된다.

13~16Period에 전표를 입력할 수 있는 것은 실제 Posting Date가 마지막 월인 경우에만 가능하다.

위 경로에서 Fiscal Year를 설정할 수 있다.

표준 Fiscal Year는 SAP에서 설정한 값이 있으므로 보통 Special Period가 있는 K1~K4를 주로 사용한다.

이러한 Fiscal Year Variant를 Company Code에 Assign하는 설정은 위 IMG경로에

Assign Company Code to a Fiscal Year Variant에서 설정 할 수 있다.

이렇게 설정된 Period를 기준으로 결산을 위한 전기기간 마감작업이나 계정잔액 조회 시 Period별로 조회가 가능하다.

Posting Period

전기기간을 Posting Period별로 통제할 수 있다.

즉, 재무 결산담당자가 사용자의 특정시점 전표입력을 막고 결산작업을 수행하는 도구로 사용 가능하다.

먼저, Posting Period통제를 위한 Variant를 생성해야 한다.

해당 경로에서 Define Variants for Open Posting Periods를 실행하여

통제를 위한 Variant를 생성한다.

그 후 Open and Close Posting Periods를 실행하여 실제 전기기간을 입력하고

Assign Variants to Company Code를 실행 후 Company Code와 연결하여 적용한다.

Open and Close Posting Periods 화면

실제 전기기간을 입력하는 화면을 보면 Account Type이 있는데

A(Asset), D(Customer), K(Vendor), M(Material), S(G/L Account) 등으로 구분하여 각 타입에 대한 범위를 관리할 수 있다.

Account Type이 '+'인 경우 모든 Account Type에 대해 일괄로 적용하겠다는 것이다. (우선순위)

통제 가능한 Period 범위가 3개가 있다. (보통 Period2 까지 사용한다)

통제가 필요한 경우,

 Authorization Group 에 미리 Authorization을 관리하는 Object인 F_BKPF_BUP의 권한 생성 후,

해당 경리부서의 결산담당자의 사용자 아이디에 위에 만든 Authorization Group을 연결한다.

 그 후 , 위 AuGr필드에 해당 Authorization Group 코드 값을 넣어주면, 해당 권한을 가지는 사용자는

Period1, Period2, Period3 모든 기간에 대하여 전표입력이 가능하고,

AuGr에 해당하지 않는 일반 사용자는 Period2에 대해서 입력이 가능하다.

해당 경로에서 특수한 필드에 대해서 입력을 통제 할 수 있다.

모든 필드에 대하여 통제를 할 수 있는 것은 아니고,

Company ID, Business Area, Profit Center 등 지정된 필드에 대해서만 통제 가능하다.

Posting Authorization ( Tolerance Group )

해당 설정은 국내에서는 잘 사용하지 않는 기능이다.

위 경로에서 Company Code별로 Tolerance Group을 생성하고,

그 생성한 Tolerance Group을 Assign User/Tolerance Groups에서 해당 유저와 연결해주면 된다.

이렇게 하면 특정 사용자에게 전표 입력 시 입력가능 한 총 금액 or Open Item 당 사용가능 금액 등 통제할 수 있다.

Default Values for Accounting Editing Options

전표처리 시 자주 사용하는 필드에 Default Values(기본 값)을 설정해주는 방법으로 T-Code : FB00에서 세팅할 수 있다.

해당 설정은 사용자 개인에 한하여 저장되고 사용된다.

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다.  

이번에 소개할 Event Handler는 DATA_CHANGED다. 

이것은 ALV가 수정모드일 때 데이터가 변경되면 감지해서 이벤트가 발생하게 하는 핸들러다.

로컬 이벤트 핸들러 클래스에 data_changed 이벤트를 구성해주고

1편에서 했던 방법과 똑같이 Set Handler에 handle_data_changed를 설정해주고 해당 구문에 

Break-point를 줘서 ALV의 값을 변경해보자.

빈값이 었던 4번째 라인에 로컬 클래스를 KRW를 입력하고 엔터를 치면 해당 클래스에 디버깅이 타게된다.

해당 이벤트를 타는 것을 알 수 있다.

이후에 PERFORM문에 로직을 작성하면 된다.

로직을 작성할때는 er_data_changed 오브젝트에 들어가보며 mt_mod_cells항목이 있는데 

그 항목이 수정되어있는 라인들의 정보다.

LOOP AT po_data_changed->mt_mod_cells INTO ls_mod_cells. 

수정한 라인의 위치 값 정보를 가지고 로직을 작성 할 수 있다.

다음은 DOBBLE_CLICK 이벤트와 HOTSPOT CLICK 이벤트 가 있는데 두 기능은 비슷하다.

더블클릭은 말그대로 더블클릭했을 때 이벤트가 발생하는거고 핫스팟 클릭은 한번 클릭했을 때 이벤트가 발생하는

이벤트 핸들러라고 생각하면 이해가 쉽다.

더블클릭과 핫스팟 클릭을 구성하고 Set Hanlder까지 구성 후 ALV 실행해서 ALV필드를 클릭해보겠습니다.

더블클릭하면 디버깅이 다편서 몇번째 라인, 어떤 필드를 선택해서 더블클릭했는지 정보를 받아오면서 

이벤트 트리거가 발생합니다.

하지만, 한번 클릭하는  hot spot click은 이벤트 트리거를 안타는데

핫스팟을 설정하려면 다음과 같은 설정이 추가로 필요합니다.

필드카달로그 구성하는 곳에서 원하는 필드에 hotspot 설정을 다음과 같이 해줘야합니다.

Flight Date에 핫스팟 설정을 해주고 ALV를 실행해보면 

해당 필드값에 밑줄이 생기면서 핫스팟 대상임을 표시해 준다.

밑줄이 있는 필드에 한번 클릭을 하게되면 Hotspot 이벤트 트리거가 발생하면서 

해당 로우와 컬럼의 정보를 받아오는 것을 알 수 있습니다.

위 화면의 정보를 가지고 로직을 작성하면 된다.

Exchange Type

동일한 환율이라도 현찰 살 때와 팔 때 그리고 송금 전신환으로 보낼 때 와 받을 때 등 여러가지 Activity 별로 필요한

환율타입을 여러 종류를 만들어 등록 관리하여 사용한다.

기본적으로 환율타입 'M' (Standard transaction at average rate)을 정하여 모든 환율의 기본 표준으로 정하고,

필요시에 환율타입을 추가로 만들어 관리할 수 있다.

환율 타입은 위 경로에서 설정 할 수 있다.

기본적으로 'M' 타입은 필수타입으로 반드시 관리를 해야 하며, 이외 타입은 필요에 따라 여러가지 만들어 사용하면 된다.

위 화면에서 Inv 필드는 자동으로 환율을 Invert할 것인지 여부를 체크하는 필드다.

이 필드에 체크를 했을 경우, KRW : USD 환율 값을 등록 한 경우,

USD : KRW를 등록하지 않아도 자동으로 USD : KRW 환율 값을 반대로 자동 환산 해준다.

위 경로에서 국가코드 설정 시 사용할 환율타입을 설정해 놓아야 해당 국가에 대한 전표처리가 가능하다.

Exchange Rate

Exchange Rate는 국가별로 매일 달라지는 환율 값이다.

환율 값을 위 경로에서 입력할 수 있다.

Direct quotation방식과 Indirect quotation 방식이 있다.

Direct quotation 방식 : 1EUR = 0.94USD

Indirect quotation 방식 : 0.94USD = 1EUR

Direct 방식은 다른 통화를 '1'로 보고 Indirect 방식은 Local Currency를 1로 보는 방식이다.

환율 타입별로 매일 환율 값을 수작업 하는 것은 쉬운일이 아니기에 

대규모 회사에서는 외환은행과 EDI(Electronic Data Interface)를 구현하여,

매일 일정한 오전시간에 자동으로 외한은행에서 제공하는 국가에 대한 다양한 환율 값을 자동으로 구현한다.

Translation Ratios

외환은행 환율 고시 정보를 보면 엔화 같은 경우엔 (100)이라는 표시가 있다.

이것은 Translation Ratios 값으로 우리나라의 통화와 비교할 때 1원이 아니라 100원 기준으로 표시한다는 의미다.

Ex) 100원 = 884.25엔

시스템에도 Translation Ratio를 위 경로에서 할 수 있다.

Translation Ratio가 100:1 이므로 환율 값을 입력할 때 100JPY기준으로 환율 값을 입력해야 한다.

기본적으로 1:1 설정이 많지만, 일본이나 베트남 등 특수 국가들은 다른 값을 설정하여 사용하게 된다.

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다.  

Currency는 통화코드로 전표 입력 시 자국내 통화코드(Local Currency) 를 사용하지만,

경우에 따라 외화코드(Foreign Currency) 사용하는 경우도 존재한다.

Currency 설정 IMG경로는 위 화면과 같다.

다음과 같이 국제표준기구(ISO) 코드를 SAP 표준시스템에서 등록 되어있다.

동일한 ISO코드를 사용하는 두개 이상의 Currency Code를 등록한다면 우선적으로 대표되는

Currency Code에 Primary 필드를 체크한다.

Company Code(회사코드)에는 최대 3개 Currency를 설정하여 관리할 수 있다.

위 경로에 들어가보면

회사코드(company Code)별 FI Currency 3개 설정할 수 있고,

1st local currency는 필수 지정값으로 모든 Company Code에 대하여 무조건 설정이 되어야한다.

2nd, 3rd local currency는 선택사항으로 관리 된다.

전표 조회창에서 Display Currency 버튼을 누르면 어떤 Currency별로 조회할 지 선택가능.

Source Currency Type 은 2nd, 3rd local currency로 환산하여 저장할 경우

환산대상을 전표입력 시 넣은 Transaction currency를 기준으로 할 것인지,

아니면 1st local currency를 기준으로 할 것인지 결정하는 필드다.

('00' = Document currency, '10' = Local currency )

Transltn Date Type (Type of Translation Date) 필드는 환산시에 기준이 되는 일자를 전표의 어느 일자 기준으로 할 것인지 결정하는 필드다.

보통은 전표에 입력한 환산일(Translation date)를 기준으로 하지만 증빙일이나, 전기일로 설정할 수 있다.

Currency Type

Currency Type은 SAP에서 지정한 통화타입으로 용도에 따라 사용하거나,

FI와 CO모듈간에 Interface 등을 사용하는 경우에 두 모듈사이 금액을 변환하는데 주로 사용된다.

40(Hard Currency)에 대해 설명을 하자면,

한국에서 심한 인플레이션이 발생하여 1월에는 1$의 통화가치가 834원이었는데,

점점 원화가치가 떨어져 12월에는 1$의 통화가치가 10000원이 되었다고 가정을 해보자.

연말 기준으로 1년치의 매출금액을 더하면 총 120,000원이다.

12월 환율기준 1$에 10,000원이므로 연간 매출액을 USD로 반환하면 12$로 표시될 수 있다.

그러나 실제로 월별로 환율을 미리 적용하여 표시한 2nd Local Currency 로 하면

이렇게 각각의 발생시점에 통화 환율변환 하는지 혹은 연말에 모아서 연말 총 금액에 대하여 환율 반환할지에 따라

2nd Local Currency 별로 큰 금액차이가 발생할 수 있다.

이때 외부국가의 시각에서는 78$가 더 객관적이고 신빙성이 있다.

이렇게 인플레이션이 심한 국가에서 실질적인 현재가치를 파악하고 싶을 때

2nd Local Currency로 Hard Currency를 사용할 수 있다.

Group Currency는 여러 국가에 회사를 가진 Group일 경우에 동일한 화폐단위로 재무제표를 보기 위해서 사용되며,

Index-based Currency는 인플레이션이 아니더라도 외부의 보고목적으로 해당 목적에 적합한 기준통화를 정하고

그 기준통화로 재무제표 고시를 하기 위하여 사용된다.

해당 글은 ' 알기쉽게 정리한 SAP FI' 책을 통해 스스로 공부하면서 정리한 내용이다.  

CL_GUI_ALV_GRID인 클래스 인데, T-code: SE24에 들어가서 해당 클래스 검색해보면

다음과 같은 항목이 보일텐데 Event 탭에 들어가서 어떠한 Event Handler가 있는지 확인 할 수 있다.

이중에서 가장 많이 사용되고 알아두면 좋을만한 것들에 대해서 알아보자.

1. ALV를 구성할 때 작동하는 Event인 Toolbar에 대해서 알아보자.

Toolbar는 ALV에 대해서 작동하는 toolbar 버튼을 구성해주는 Event Handler라고 보면 된다.

버튼을 구성하면 빨간박스 위치에 생성된다.

사용하는 방법은 다음과 같다.

하기와 같이 로컬 클래스 이벤트 핸들러를 정의해주고 로컬 클래스에 대해 생성자를 만들어 준 후 

내가 원하는 이벤트 핸들러를 하나씩 추가하면 된다.

로컬 클래스를 작성한 이후에 해당 클래스를 New구문을 통해 생성해주고,

해당 ALV Gird에 event modified 변수를 넘겨줘서 edit_event에 등록을 시켜주고 

작성한 handle_toolbar를 set handler에 설정해주면 이벤트가 동작한다.

handle_toolbar에 break-point를 찍어서 돌려보면 화면이 생성되는 시점에서 이벤트 트리거가 발생한다.

handle_toolbar에 있는 alv_handle_toolbar 퍼폼문을 다음과 같이 작성하면 된다.

function 명 , Icon여부, button명 등 설정을 해주고 실행하면 

아래 그림과 같이 ALV 버튼이 생성된다.

버튼을 생성했으면 해당 버튼에 대한 기능을 추가해줘야 하는데 이 이벤트는

USER_COMMAND 이벤트 핸들러를 사용하면 작동 시킬 수 있다.

handle_command 로직을 추가하고 핸들러도 추가해주고

PERFORM문 로직을 작성하면 된다.

해당 function은 위에 toolbar를 구성할 떄 작성해 두었던 function명을 입력해주면 해당 로직을 타게된다.