본문 바로가기

SAP CO/기본 개념

Direct vs. Indirect Activity Allocation (1)

 

 

뭐가 Direct고 뭐가 Indirect라는 얘기일까?

 

 

 

내가 이 용어를 처음 접한 건 SAP 아카데미 교육 자료였다. Activity Allocation의 개념과 예시가 그려져 있었는데 그림을 아무리 열심히 들여다봐도 도무지 어디에 쓰이는 건지 알 수 없었다. 대충은 감이 오지만 이게 실제 업무에서도 쓰는 건가? 우리 회사 어딘가에 이걸 쓰는 게 있나? 없는 것 같은데? 혼란스러웠다.

 

시간이 지나서 생산의 Confirmation은 알게 되었고 더 시간이 지나서 REM의 백플러시도 알게 되었는데도 그게 바로 Direct Activity Allocation인지는 연결시켜 생각해보지 못했다.

 

Indirect Activitiy Allocation도 내가 써보질 않았으니 그냥 SAP 책에서나 나오고 별로 효용성은 없는 건 줄 알았다. 공부하면서 한두 번 정도는 테스트해봤지만 개념도 잘 안 들어오고 그냥 별로 안 쓰는 건가보다...하고 막연하게만 생각했었다.

 

여러분들은 어떠신지? 이번 기회에 함께 알아보자.

 

우선 액티비티 타입의 기본 개념이 필요한 분은 아래 글부터 읽고 오시길

 

2021.11.03 - [SAP CO/기본 개념] - SAP의 액티비티 타입

 

SAP의 액티비티 타입

SAP의 액티비티 타입이란 코스트센터에서 수행하는 업무활동이다. 어렵게 생각할 것 없이 그냥 "업무활동"이라고 보면 된다. 사무직인 나의 일상업무 활동을 생각해보면 그냥 '문서작업 활동', '

ckm3.tistory.com

 

 


 

1. Direct Activity Allocation - 범주 1

 

액티비티 유형 범주 1

 

Direct Activity Allocation은 액티비티를 수행한 센더와 리시버가 명확하여 직접 지정할 수 있는 방식이다. 대표적으로 다음과 같은 T-CODE를 통해 수행한다.

 

 

  • T-CODE: KB21N - 직접 액티비티 배부 입력  
  • T-CODE: CO11N - 생산 확정(Discrete Manufacturing 환경)
  • T-CODE: COR6N - 생산 확정(Process Manufacturing 환경)
  • T-CODE: MFBF - 액티비티 백플러시(Repetitive Manufacturing 환경)

KB21N은 CO에서 단독적으로 사용하는 티코드이고 나머지는 생산에서 넘어오는 티코드이다. 각각 발생하는 원천은 다르지만 CO 입장에서는 결국 KB21N과 동일한 형태로 값이 전달된다고 보면 된다.

 

그럼 예시를 통해 확인해보자.

 

T-CODE: KB21N(직접 액티비티 배부 입력)

 

 

위 그림처럼 특정 작업에 투입한 코스트센터, 액티비티, 수량값이 모두 명확하게 입력해야 한다. 우리 예시에서는 컨설팅 프로젝트라는 내부오더에 컨설팅 시간이 40시간 투입되었다고 해보자.

 

T-CODE: FB03(전표 조회)

 

그럼 관련 전표가 생기는데 센더 코스트센터 대변과 리시버 코스트센터 차변에 액티비티, 2차 원가요소, 금액, 수량이 기록된다.  

 

여기서 유의할 점은 액티비티 배부 전표는 그 이름에 '배부'가 붙듯이 기업 내부에서 발생하는 관리회계 전표라는 점이다. 증빙이 필요한 재무회계 전표가 아니다. 따라서 이게 실제 지급된 금액은 아니란 뜻도 된다.

 

다시 말해 우리가 컨설팅 시간으로 40시간을 입력하고 계획가격인 시간당 400,000원이 적용되어 총 16,000,000원의 전표가 생겼지만 이게 실제 비용은 아니란 얘기다. 시간당 400,000원은 계약 단가가 아니다. 월중에 액티비티 수행 시간에 따라 비용을 배부할 '배부율'에 불과하다.

 

 

액티비티 가격은 실제로 계약한 단가가 아니다.

 

 

처음 CO를 공부했을 때는 이렇게 생각을 못했었다. 액티비티 가격이란 게 실제 액티비티별로 발생할 금액 가격을 예측해서 만든 거라는 막연한 생각만 했었다. 또 어설프게 원가회계를 공부하면서 직접노무비란 개념과 혼동이 생기다보니 액티비티 가격이 곧 시급이라는 착각을 하기도 했었다. 임률이란 말을 접하면서 더 헷갈리기도 했다.

 

실제로 지급한 금액은 세금 포함 22,000,000원이다. (CO가 테스트하면 늘 이렇게 현금빵으로 해서 FI가 싫어한다 ㅋㅋㅋ)

 

 


 

2. 실제 가격 재평가 - 리시버가 오더일 때

액티비티 가격은 실제 계약 단가가 아니기 때문에 실제 지급한 금액과 차이가 생길 수밖에 없다.

 

T-CODE: S_ALR_87013611(코스트센터 실제/계획/차이 조회)

 

위 그림을 보면 미리 예정된 계획 액티비티 단가와 실제 시간을 곱한 액티비티는 코스트센터의 대변으로 기록되었고, 실제 발생비용인 지급수수료는 코스트센터 차변으로 기록되었다. 차이금액은 4,000,000원이 남은 상태다.

 

월말 결산 시점에는 이 차이 금액에 대한 조정전기가 추가로 필요해지게 된다. 이 때 수행하는 차이조정전기를 SAP에서는 재평가(Revaluation)라고 한다.

 

재평가 방법은 다음과 같은 순서로 진행된다.

 

차이금액 재평가 방법
0. (optional) 차이 계산(T-CODE: KSS1)

1. 실제 액티비티 분할(T-CODE: KSS2)

2. 실제 액티비티 가격 계산(T-CODE: KSII) ← 리시버가 코스트센터인 경우 실제가격 재평가가 동시에 수행

3-1. 실제 가격 재평가(T-CODE: KON1) (리시버가 오더인 경우)

3-2. 실제 가격 재평가(T-CODE: CJN1) (리시버가 WBS요소인 경우)

 

우리 지금 예시에서는 리시버가 오더인 경우이므로 실제 액티비티 가격 계산(T-CODE: KSII) 수행 후 실제 가격 재평가 T-CODE인 KON1을 따로 돌려줘야 한다.

 

 

T-CODE: KON1(실제가격으로 재평가: 오더)

 

이렇게 재평가를 하게 되면  

 

T-CODE: KSB5(관리회계 전표 조회) S/4HANA 버전이므로 FI 전표도 물론 동시에 생기지만, 이번엔 관리회계 전표로 캡쳐해봤다.

 

이런 식으로 역시 센더 대변 리시버 차변 전표가 생긴다.

 

 

코스트센터 리포트에서 확인해보면 차변에 쌓였던 실제 비용이 컨설팅 시간으로 배부되어 잔액이 0이 되었음을 알 수 있다. 이제 이 금액은 모두 리시버인 오더의 차변으로 이동했다고 보면 된다.

 

 

 


 

3. 실제 가격 재평가 - 리시버가 코스트센터일 때

리시버가 코스트센터일 때 재평가는 가격 계산과 동시에 발생한다. T-CODE: KSII를 통해 수행하면 된다.

 

T-CODE: KSII(실제 가격 계산)

 

T-CODE: KSB1(코스트센터 개별항목 조회)

 

재평가 처리한 결과를 보면 차이금액이 비즈니스 트랜잭션 'KSII'로 입력되었다. 코스트센터를 통한 재평가는 T-CODE: KSII만으로 작업이 끝나고, 오더나 프로젝트처럼 추가 프로그램을 실행할 필요가 없다.

 

그런데 이 리시버가 코스트센터일 경우의 가격계산과 재평가 방법을 세팅할 수 있는 IMG를 아는가?

 

바로 계획 버전 설정이다.

 

T-CODE: OKEQ(계획 버전 설정)

 

계획 버전의 관리회계영역/회계연도별 설정을 보면 '가격계산' 탭에 재평가 방법에 대한 세팅이 있다. 각각의 의미는 다음과 같다.

 

0 - 재평가하지 마십시오: KSII 수행 시 가격계산만 수행하고 재평가는 수행 안 함

1 - 자기 거래: KSII 수행 시 비즈니스 트랜잭션 'KSII'로 재평가 개별항목이 생성

2 - 최초 비즈니스 거래: 최초 발생한 비즈니스 트랜잭션과 동일한 코드로 재평가 개별항목이 생성

 

이 세팅은 바로 위 캡쳐도 그렇고 아마도 대부분 1번 '자기 거래'를 하시리라고 본다.

 

이 기회에 2번을 골랐을 경우의 예시를 보여드리겠다.

 

T-CODE: KSB1(코스트센터 개별항목 조회)

 

개별항목이 추가로 생기는 건 맞지만, 비즈니스 트랜잭션 코드가 최초 거래와 동일한 코드로 찍히는 점이 다르다. 이렇게 되면 CO 총계 리코드에서는 재평가 전과 재평가 후 금액을 구분해서 볼 수 없게 된다.

 

TABLE: COSS(CO 내부 전기 조회 테이블)

 

이렇게 달라진다. 사실 이게 이 정도로 디테일하게 볼 거까진 아니라고 본다. 웬만하면 그냥 1번 고르면 된다.

 

그런데 굳이 이번 글에서 언급하는 이유는 예전에 이것때문에 고통 받는 동료를 봐서다.

 

 


 

4. 생산 확정(Confirmation)도 Direct Activity Allocation이다.

PP의 생산확정을 통해서도 직접 액티비티 배부가 이뤄진다.

 

T-CODE: CO11N(Discrete Manufacturing 환경에서 생산 확정)

 

T-CODE: COR6N(Process Manufacturing 환경에서 생산 확정)

 

T-CODE: MFBF(Repetitive Manufacturing 환경에서 백플러시)

 

이렇게 생산 환경마다 Direct Activity Allocation이 들어오는 방식이 다른데, CO 입장에서는 결국 T-CODE: KB21N으로 입력한 것과 동일한 전표가 생긴다고 보면 된다.

 

 

생산확정으로 Direct Activitiy Allocation 전표가 생성된 모습

 

백플러시로 생산확정으로 Direct Activitiy Allocation 전표가 생성된 모습

 

 

즉, CO 입장에서 PP의 생산확정이나 백플러시는 Direct Activity Allocation의 한 방법이라 볼 수 있다.

 

실제 비즈니스 상황에서는 생산확정만 하고 결산까지 끝내기도 하고, 생산확정 후 추가로 CO 단독적으로 T-CODE: KB21N(또는 그에 준하는 CBO 프로그램)을 통해 Direct Activity Allocation을 하기도 한다.

 

반복제조환경에서는 백플러시로 생산입고량에 맞춰 역산해서 액티비티 수량을 입력하므로, 월말에 보정할 일이 생기곤 하는데 이럴 때 쓰는 예가 대표적이다.

 

(근데 KB21N이나 MFBF나 둘다 BAPI가 있으므로 이것도 구현할 때 CO가 할지 PP가 할지 고민되는 부분이다. 개인적으로 표준값키에 대한 주도권(?)을 가져간 쪽이 해줘야 한다고 생각하는데 여러분들 생각은 어떠신지?) 

 

 


 

5. 중간 맺음말

이번 글에서 Direct와 Indirect Activity Allocation을 모두 다루려고 했는데 글이 너무 길어져버렸다. 다음 글에서 Indirect Activity Allocation의 두 가지 유형(범주 2, 범주 3)에 대해서 더 다뤄보자.