본문 바로가기

SAP CO/깊숙한 개념

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

 

이번 글은 지난 글 『실제 액티비티 갱신 - 오더 vs. 자재원장』에서 이어진다.

 

2021.11.20 - [SAP CO/깊숙한 개념] - 실제 액티비티 갱신 - 오더 vs. 자재원장

 

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

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

ckm3.tistory.com

 

이 글에 "SAPIENT" 님께서 T-CODE: CKMLQS 리포트의 한계점을 언급해주셨는데, 그와 관련한 내용을 더듬어 알아보고 쓴다.

 

SAPIENT 님의 댓글. 경험 많으신 고수분들이 방문해주시는 덕분에 많이 배우고 있습니다.

 

지난 글을 잠깐 요약해서 얘기해보자. CO에서 자재원장과 실제원가계산을 활성화하면서 실제 액티비티의 갱신 방법을 선택할 수 있는데, 오더에 갱신하는 방법과 자재원장에 갱신하는 방법 두 가지가 있었다.

 

우리 현실에서는 대부분 T-CODE: CON2를 통해 실제 액티비티를 오더에 갱신하는 방법을 사용하고 있다. 대신 자재원장에 갱신하는 방법을 사용했을 경우의 장점으로는 T-CODE: CKMLQS 리포트를 온전히 활용할 수 있단 점이 있다.

 

그런데 T-CODE: CKMLQS 리포트는 충분히 활용할 만한 가치가 있는 걸까? 이걸 함께 알아보자.

 

 


 

1. 이전 기간에 생산 완성된 항목이 투입됐을 경우 세부 내역이 열리지 않는다.

이건 어찌 보면 당연한 건데, 이전 기간에 생산완성된 반제품의 경우 세부 내역이 열리지 않는다. 이 리포트의 조회 조건은 1개월 단위로만 입력할 수 있기 때문이다. 따라서 이전 기간에 생산완성된 항목은 당월에 세부내역을 볼 수 없다.

 

T-CODE: CKM3(자재원장 조회) 상단의 '평가된 수량구조 표시' 클릭

 

위 그림에서 보는 것처럼 '양산형 짐(GM)_Body'를 생산하기 위해 반제품 '짐 암스'와 '짐 레그'가 투입되었지만, 각 반제품의 하위 폴더는 열리지 않는다. '짐 암스'와 '짐 레그'는 전월에 생산 완성되어 재고로 있던 걸 투입한 것이기 때문이다.

 

T-CODE: CKM3(자재원장 조회) 12월의 ARM

 

위 그림에서 보면 12월에 '짐 암스'가 생산을 위해 투입되었지만, 이 반제품은 이미 이전 기간에 완성되어 재고로 보유하고 있던 것이므로 12월의 평가된 수량구조를 봐도 하위 폴더가 열리지 않는다.

 

T-CODE: CKM3(자재원장 조회) 11월의 ARM

 

물론 생산된 기간인 11월로 조회해보면 폴더가 열리긴 한다.

 

그럼 "이 11월의 생산 데이터를 하위 폴더로 열리게 하면 되지 않나?"라고 생각해볼 수도 있을 것 같다. 나도 처음엔 그 생각이 먼저 머리에 들어왔었다. 그렇지만 다시 생각해보자. "재고효과"라는 게 존재하는 이상 그게 맞는 정보일까?

 

이 ARM이란 반제품이 11월 생산분뿐만 아니라 1~10월 여러 기간에 걸쳐 생산한 재고가 쌓여 있는 상황을 생각해보자. 그렇다면 각 기간의 제조원가는 모두 다를 텐데 12월 소비 시점의 원가는 그중 어떤 원가인지 특정할 수 있을까? 우리가 개별법을 쓰지 않는 이상은 알 수 없다.

 

(그런데 이런 상호교환 가능한 대량의 재고자산 항목에 대한 개별법은 대부분 현실적으로도 불가능하고, 회계기준에서도 인정하지 않는다. K-IFRS 1002:24 참조) 

 

따라서 이전 기간에 생산된 반제품의 상세 내역은 표시할 수 없는 게 당연하다.

 

여기서 한 걸음 더 나아가 생각해보자. 당월 생산된 반제품의 경우 상세 내역이 표시되긴 하는데 이것도 과연 맞는 정보일까? 

 

 


 

2. 조달 유형이 여러 가지인 반제품 투입 시 어떤 게 투입됐다고 봐야 할까?

 

T-CODE: CKM3(자재원장 조회) 조달 유형이 여러 가지인 경우 투입은 어떤 거라고 봐야할까?

 

위 그림에서처럼 당월의 조달 유형이 외부 조달, 내부 생산 두 가지인 반제품일 경우를 보자. 이때 상위 제품의 생산을 위해 투입된 1개는 어디서 나왔다고 봐야 할까? SAP에서 재고자산의 평가방식을 "다중레벨(3), 표준원가(S)"로 선택한 경우라면 월 단위 총평균법이기 때문에 딱 어느 하나라고 지정할 수는 없다.

 

그럼에도 상위제품의 원가구조 리포트를 보면

 

T-CODE: CKM3(자재원장 조회) 상위제품의 결산 전 모습

 

이렇게 내부 생산한 반제품이 투입됐다는 가정에 따라 표시된다. 이걸 과연 맞다고 볼 수 있을까?

 

결산까지 한 이후라면 어떨까?

 

 

T-CODE: CKM3(자재원장 조회) 상위제품의 결산 후 모습

 

결산 후에는 하위 폴더의 항목이 내부 생산일 경우만으로 표기되긴 하지만, 상위의 합계가 다른 금액으로 표시된다. 왜 그럴까? 사실 이것도 당연한데

 

그림이 잘 안 보이시면 클릭해서 확대해 보시기 바랍니다.

 

 

이렇게 실제 투입한 금액과 맞춰주기 위해서 그렇다. 하위 폴더의 항목은 내부 생산에 대한 금액 하나만 보여주지만, 상위 합계에서는 총평균법에 따라 구성된 자재의 예비평가, 차이, 실제값을 보여준다.

 

 


 

3. 오더에서 정산된 금액은 표시되지 않는다.

 

오더 정산으로 인해 자산화된 금액은 표시되지 않는다.

 

위 그림에서 보는 것처럼 오더 정산으로 들어온 금액은 표시되지 않는다. 이 리포트가 자재와 액티비티로만 구성되었기 때문에 오더 정산으로 들어온 금액은 어떤 액티비티에 포함되는지 알기 어렵기 때문인 것 같다. 그러니 이렇게 표시했다고 이해는 되지만... 그래도 아쉽긴 하다. 꼭 자재와 액티비티로만 구성해야 했었나?

 

아무튼 이렇다 보니 아래 노드의 합산 값이 상위 항목의 값과 일치하지 않는다.

 

 


 

4. 차변/대변 메모(T-CODE: MR22)도 표시되지 않는다.

오더 정산일 때와 마찬가지로 해당 자재에 대해 차변/대변 메모를 통해 자산화된 금액도 표시되지 않는다.

 

차변/대변 메모로 인해 자산화된 금액은 표시되지 않는다.

 

위 그림에서 보는 것처럼 하위 반제품에서 추가로 자산화된 금액인 400,000이 따로 항목으로 표시되지 않는다. 그저 합계 레벨에서만 일치될 뿐이다.

 

 

 


 

5. 전월 재공으로부터 넘어온 금액은 그래도 잘 표시된다.

재공품 재평가를 사용했을 경우 전 기간의 재공으로부터 넘어온 금액은 그래도 잘 표시된다. 이거는 한계점은 아니고 좋은 점이다. 그래도 특징적인 부분이라 정리해본다.

 

T-CODE: CKMLCP를 통해 결산을 수행하기 전과 후의 모습

 

위 그림을 보면 결산 전에는 전월 재공으로부터 넘어온 하위 반제품, 액티비티가 표시되지 않다가, 결산 후에는 별도 표시되고 있다.

 

 


 

6. 결론

결국 T-CODE: CKMLQS(평가된 수량 구조) 리포트는 해당 제품의 "대략적인 실제 BOM과 액티비티 수량 구조"를 보여줄 뿐이다. 실제 값이 일치하게 만드는 것은 제약사항을 두지 않는 이상 논리적으로도 어렵다고 본다.

 

이에 대한 내용을 SCN wiki에도 "Humberto Ordosgoitia"란 분이 적어놨다.

 

https://wiki.scn.sap.com/wiki/display/ERPFI/Actual+Quantity+Structure

 

Actual Quantity Structure - ERP Financials - Community Wiki

The transaction CKMLQS or the valuated quantity structure (multilevel) in CKM3 provides a help to understand the multilevel price differences but not the total price. The complete build-up of the price is explained by CKM3. CKMLQS has been designed to disp

wiki.scn.sap.com

 

결국 이 리포트는 대략적인 구조를 보여주는 오버뷰에 불과하고, 보다 깊이 있는 분석을 위해서는 다른 리포트도 함께 봐서 보완하거나 또는 별도 리포트를 구현할 수밖에 없을 것 같다.

 

한편으로 이 리포트의 효용성 그 자체도 검토가 필요할 것 같은데 그건 천천히 더 고민해봐야겠다.