실제 액티비티 갱신 - 오더 vs. 자재원장

 

T-CODE: CKM3(자재원장 조회)에서 상단의 버튼을 클릭하거나 T-CODE: CKMLQS로 조회

 

T-CODE: CKMLQS를 쓰시는지? 생산된 제품, 반제품의 실제 BOM 구조에 수량과 금액을 함께 보여주는 화면이다. 투입된 자재뿐만 아니라 투입된 액티비티까지 보여주는 게 장점인 화면이다.

 

그런데 위 그림을 잘 보면 투입된 자재에 대한 금액은 잘 표시되지만, 투입된 액티비티에 대한 금액은 표준으로만 표시되고 있다. 왜 그렇지? 처음엔 뭐 이런 반쪽짜리 화면이 다 있나 생각했었다.

 

왜 이럴까?

 

SAP의 표준 기능상 액티비티의 가격 갱신을 자재원장이 아닌 오더로 해서 그렇다.

 

이전 글인 『Direct vs. Indirect Activity Allocation (1)』에서 봤던 것처럼, 액티비티의 실제가격 재평가는 센더인 코스트센터와 리시버인 CO Object로 이뤄진다.

 

다시 잠깐만 설명해보자면

 

월중에 생산오더에 대한 액티비티 금액은 Confirmation이나 Backflush를 통해 확정된 "실제 액티비티 수량 × 계획 액티비티 단가"로 센더인 코스트센터의 대변, 리시버인 오더의 차변에 기표된다. 이를 Direct Activity Allocation이라고 했다.

 

그러다가 센더인 코스트센터 차변에 실제 발생비용이 기표되면 "실제 발생비용 ÷ 실제 액티비티 수량"으로 "실제 액티비티 단가"를 계산한다. 이렇게 계산된 액티비티 단가로 재배부를 하면 앞서 배부했던 금액과 차이가 생기는데

 

 

 

이런 식으로 차이금액이 계산되어 센더와 리시버에 배부된다. 이 때 T-CODE: CON2를 통해서 처리하며 이게 끝나게 되면 센더인 코스트센터의 차변과 대변 잔액은 0이 되어 마감된다.

 

이후 오더에 쌓인 금액은 재료비는 표준원가, 가공비는 실제원가인 상태가 되며 이는 정산(T-CODE: CO88)이란 작업을 통해 자재원장에 기표된다. 이 시점에서 센더는 오더가 되며 오더의 차변과 대변 잔액은 0이 되어 마감된다.

 

정산된 가공비의 차이금액은 다시 자재원장으로 넘어온다. 다시 말해보면

 

 

코스트센터 → 오더 → 자재원장

 

 

이런 순서로 넘어온 셈이다. 이후에 T-CODE: CKMLCP를 통해 자재원장 결산까지 돌리게 되면 재료비와 가공비의 차이금액이 투입된 구조에 따라 분할 전달되어 모든 자재가 실제원가로 계산되어 마무리된다.

 

이게 기본구조인데 여기서 오더를 생략하고 자재원장으로 바로 가공비를 재평가할 수 있는 방법이 있다.

 

 

코스트센터 → ( 오더 ) → 자재원장

 

 

이렇게 중간 과정인 오더에 재평가하는 단계가 사라지고 바로 코스트센터가 센더, 자재원장이 리시버가 되는 방식이다. 과연 어떻게 하는 걸까? 지금부터 살펴보자.

 

 

---

 

1. 관련 IMG 세팅 방법

(1) 실제원가 계산 활성화 시 액티비티 갱신 방법 정의

 

우선 T-CODE: SPRO를 입력하고 아래 IMG 경로로 들어간다.

 

IMG: 관리회계 → 제품 원가 관리회계 → 실제 원가계산/자재 원장 → 실제 원가계산 → 실제 원가계산 활성화

 

실제원가계산을 활성화하고 ActAct 필드의 값을 '2'로 선택

 

실제원가계산을 활성화하면서 액티비티에 대한 옵션을 설정할 수 있다. 여기서 2번을 선택하면 된다. 우리가 맨처음 봤던 화면은 1번을 선택했을 경우였다. 각각의 차이를 설명해보면

 

 

• 0번: 액티비티 갱신이 자재원장에서 아예 이뤄지지 않는다. T-CODE: CKMLQS로 조회해봐도 투입된 자재만 BOM 형태로 표시되지 액티비티는 표시되지 않는다.
• 1번: 액티비티 갱신이 자재원장에서 이뤄지긴 하지만, 실제 액티비티는 갱신되지 않고 계획 액티비티만 갱신된다. T-CODE: CKMLQS로 조회해보면 액티비티도 표시는 되지만 계획금액만 나온다.
• 2번: 액티비티 갱신이 실제와 계획 모두 자재원장에서 이뤄진다.

우리가 사용할 방법은 2번이다.

 

 

(2) 액티비티 재평가 시 사용할 계정 정의

 

T-CODE: CON2를 사용해 센더인 코스트센터와 리시버 오더로 차이금액을 재평가할 때는 별도 계정 정의가 필요하지 않았다. 센더와 리시버 모두 동일한 계정을 사용하면 되기 때문이었다.

 

하지만 지금처럼 차이금액을 센더 코스트센터, 리시버 자재원장으로 할 경우에는 자재원장에서 사용하는 계정으로 바꾸어 줄 필요가 있기 때문에 별도 설정이 필요하다. T-CODE: OBYC로 간다.

 

T-CODE: OBYC(자동계정지정) 여기서 우리가 설정할 거래키는 GBB-AUI와 PRL이다.

 

GBB-AUI에 대한 세팅

 

GBB-AUI는 코스트센터 대변에 전기될 계정이다. 코스트센터에 입력될 계정이므로 1차 원가요소로 지정해야 한다. 이전 글인 『SAP CO의 원가요소란 무엇인가?』를 보면 기억하실 텐데 SAP에서 원가요소란 반드시 CO 오브젝트 지정이 필요한 수익/비용 계정이다.

 

PRL에 대한 세팅

 

PRL은 GBB-AUI와 짝을 맞춰 차변으로 전기될 계정이다. 그런데 이건 리시버가 CO Object가 아닌 자재원장이다. 따라서 원가요소로 생성하면 안 된다. 일반 수익/비용 계정으로 지정해야 한다.

 

 

이렇게 하면 세팅은 끝난다.

 

 

---

 

2. 결산 시 처리 결과

결산 때 T-CODE: CON2를 돌리지 않는다. 만약 무시하고 돌리게 되면 아래와 같은 에러 메시지가 발생한다.

 

T-CODE: KON1, KON2, CON2, MFN1 등으로 실제가격재평가를 했을 경우

 

따라서 이 단계는 스킵하고 바로 오더정산, 자재원장정산을 하면 된다.

 

그리고 자재원장결산(T-CODE: CKMLCP)까지 수행한 결과는...

 

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

 

위 그림처럼 GBB-AUI로 설정한 계정으로 대변 전기된다.

 

그럼 이 금액은 어떻게 배부됐는가? T-CODE: CKM3A로 가보자.

 

 

T-CODE: CKM3A(액티비티 소비 분석)

 

코스트센터/액티비티에 따라 각 자재에 투입된 액티비티 수량이 얼마인지, 계획 단가는 얼마였는지, 실제값은 얼마이며 재평가로 배부될 차이금액은 얼마인지 보여준다.

 

위 그림을 잘 보면, 해당 코스트센터에서 전체 소비한 액티비티의 총 수량은 1.35시간이었고, 이게 반제품 ARM, BODY, HEAD, LEG에 각각 얼마만큼 시간이 소요되었는지 표시된다.

 

실제값은 24,600,000인데 이는 코스트센터 차변에 쌓인 금액과 동일하다. 캡쳐를 보여드리자면

 

T-CODE: S_ALR_87013611과 T-CODE: CKM3A의 비교

 

이렇다. 금액이 아주 잘 일치한다. 그리고 자재원장 결산전표를 보면

 

FB03(전표 조회)

 

이런 식으로 배부가 되었다. 코스트센터 대변에 기표된 금액은 PRL이란 금액으로 일단 모이고, PRL에 모인 금액을 다시 PRY로 각 자재에 뿌려주는 방식이다.

 

이해를 돕기 위해 그림으로 그려보자면

 

 

이런 식으로 처리된 거라고 볼 수 있다. 센더 코스트센터로 24,107,999원이 기표되고 상대계정으로 자재원장에 PRL 거래키로 같은 금액이 기표된 후, 다시 그 금액이 자재코드 HEAD, ARM, BODY, LEG에 뿌려진다.

 

그럼 해당 자재의 자재원장을 보면 어떻게 되어 있을까? 자재코드 HEAD를 살펴보자.

 

 

T-CODE: CKM3(자재원장 조회)

 

이렇게 된다. 액티비티에 대한 차이금액이 오더 정산 시가 아니라 자재원장 결산 시에 들어온다. 이렇게 했을 때의 장점이 또 있는데

 

T-CODE: CKM3(자재원장 조회)

 

액티비티 차이금액에 대해 코스트 컴포넌트 분할까지 볼 수 있단 점이다. Primary Cost Component Split을 사용할 경우 하나의 액티비티에 여러 코스트 컴포넌트를 연결할 수 있는데 그럴 때의 금액 분할이 어떤지도 보여준다.

 

위 그림에서 ACT004의 경우 동력비라는 액티비티는 하나지만, 코스트 컴포넌트는 전력비, 가스비, 용수/폐수비로 분할되어 있음을 볼 수 있다.

 

그렇다면 BOM 구조로는 어떻게 표현될까?

 

T-CODE: CKM3(자재원장 조회)에서 상단의 버튼을 클릭하거나 T-CODE: CKMLQS로 조회

 

이 경우에는 차이금액이 제대로 반영된다. 이 리포트를 이제야 제대로 활용할 수 있게 된다.

 

 

---

 

3. 결론

실제 액티비티 가격을 자재원장에서 업데이트하는 방식에 대한 SAP 공식 커멘트를 찾고 싶었는데 도무지 안 보였다. SCN에서 Ajay라는 사람이 Actual Costing에서는 이 방식이 추천된다고는 하는데 그게 SAP가 오피셜로 하는 말도 아니고...

 

새로 나온 『Material Ledger in SAP S/4HANA』라는 책에서 이 방식을 기본으로 설명하고 있긴 한데 그렇다고 그게 꼭 정답인 건 아닐 테고.

 

그럼 장/단점이 뭘까? 직접 생각해보면

 

[장점]

1. 실제가격 재평가를 위해 T-CODE: CON2를 굳이 수행할 필요가 없다. T-CODE: CKMLCP에서 한 방에 처리

2. T-CODE: CKM3A, CKMLQS 등 자재원장 리포트를 온전히 활용할 수 있다.

 

[단점]

1. T-CODE: CON2를 수행할 필요가 없다는 건, 그 시점까지의 문제를 미리 파악할 수 없다는 뜻도 된다. T-CODE: CKMLCP를 돌릴 시점이 되어서야 결산 시 문제점을 파악하게 되면, 안 그래도 느린 T-CODE: CKMLCP 때문에 결산 일정에 지장을 초래할 수 있다.

2. 실제가격 재평가로 인해 발생하는 단수차이를 제조원가에 반영할 방법이 사라진다. T-CODE: CON2를 수행하고 남는 단수차이는 다시 오더로 배부하는 방식을 쓸 수 있지만, 이 방식을 쓸 경우에는 T-CODE: CKMLCP가 수행되면서 자재원장 자체가 닫히기 때문에 다시 제조원가 반영할 방법이 사라진다.

3. 액티비티 가격의 월중 변경이 불가능하다. 굳이 하려면 SAP NOTE: 2189173 - How to consider the changed plan activity price in KP26 during new confirmation postings when Material Ledger is active?에 나오는 프로그램으로 재설정이 가능하지만, 이것도 이미 앞서 발생한 Confirmation이나 Backflush를 취소한 이후에나 가능하다.

 

 

단점 1번은 T-CODE: CKMLCP를 수행하기 전에 액티비티 분할, 가격계산에 문제가 없는지 미리 점검할 수 있는 절차나 리포트를 만들어두면 해결할 수 있다.

 

단점 2번은 단수차이에 대해 전액 당기 비용화하거나 차월 제조원가로 넘기는 방법 밖엔 없다.

 

단점 3번은 사실 굳이 단점이 아닐 수도 있다. 표준원가에서 설정한 계획가격대로 일정하게 유지시켜주는 거니까.

 

(그렇지만 S/4HANA에서는 표준원가를 월중에도 변경/릴리즈하는 게 가능한데, 표준원가는 월중 변경이 가능하면서 왜 액티비티 가격은 월중 변경이 안 되나?는 의문이 좀 들긴 한다)

 

그리고 좀 어렵게지만, 1번 방식이든 2번 방식이든 그냥 T-CODE: CKM3A나 CKMLQS를 다 활용할 수 있게 해주면 안 되겠니? SAP여...

 

다음 글에서는 T-CODE: CKMLQS의 한계점에 대해서 작성해보았다.

 

2021.12.07 - [SAP CO/깊숙한 개념] - T-CODE: CKMLQS(평가된 수량 구조) 리포트의 한계점

T-CODE: CKMLQS(평가된 수량 구조) 리포트의 한계점