본문 바로가기

SAP CO/깊숙한 개념

가격단위 vs. 원가계산 로트크기

SAP 자재 마스터를 살펴보면 가격단위(Price Unit)란 필드와 원가계산 로트크기(Costing Lot Size)란 필드가 있다. 이 필드의 정확한 의미를 아는가? 이게 의외로 헷갈리는 개념인데 모르고 잘못 세팅하면 원가 왜곡을 일으키기도 한다.

 

T-CODE: MM03(자재 마스터 조회), 원가계산 2탭
T-CODE: MM03(자재 마스터 조회), 원가계산 1탭

위 그림을 보면 자재 마스터에서 가격 단위란 필드와 원가계산 로트크기라는 필드를 각각 확인할 수 있다. 일단 답부터 말해보자면

 

 

이렇다. 가격 단위라는 명칭이 혹시나 판매가격과 관련 있을 것이라 오해할 수도 있는데, 그렇지는 않다. 자재 단가에 대한 단위라고 보면 된다. 원가계산 로트크기는 원가계산 시 사용하는 단위가 맞긴 한데, 그중에서도 원가 추정(Cost estimate) 시 사용하는 단위다. 실제 원가계산의 단위는 아니다.

 

원가계산 로트크기의 정의(F1 Help)

 

일반적으로 원가계산 로트크기를 큰 숫자로 해야 단수 차이가 줄어든다고들 한다. 운영이나 프로젝트 시에는 가격단위와 원가계산 로트크기를 항상 같은 숫자로 지정하도록 룰을 정하는 경우도 많다.

 

여기까지의 내용은 사실 구글링을 해봐도 쉽게 알 수 있긴 하다. 그런데, "왜 그럴까?"라는 의문이 생기진 않는가? 나는 그게 궁금했다. 지금부터 그 이유를 격파해보도록 하자.

 


 

1. 생산 자재의 원가계산 로트크기는 생산 로트 단위와 동일한 자릿수여야 한다. 

 

직접 시스템을 통해 테스트를 해보자. 위 그림에서처럼 원가계산 로트크기가 '1'인 상황을 가정해본다.

 

T-CODE: CK13N(자재 표준원가 조회)

위 그림에서 자재 BC30020(초콜릿 덩어리)의 원가계산 로트크기는 1이며, 액티비티 ACT001(노무시간)의 수량은 0.720H이다. 총액은 12,883원으로 계산되어 있다. 액티비티 가격은 어디에서 가져왔을까?

 

T-CODE: KP27(코스트센터별 액티비티 가격 조회)

 

여기서 가져온다. 액티비티 가격은 T-CODE: KP27이나 T-CODE: KSBT를 통해서 확인할 수 있다.

 

액티비티 가격이 저장되는 테이블은 COST이다.

 

위 그림처럼 액티비티 가격은 '가격 단위'를 갖고 있다. 178,935라는 가격은 가격 단위인 10H에 대한 단위인 것이다. 1H에 대한 가격은 17,893.5가 된다. 위 원가 추정에서 초콜릿 덩어리를 1개(=원가계산 로트크기) 생산하기 위해 투입되는 액티비티 수량은 0.72H였다. 그렇다면 계산은 다음과 같은 방식으로 이뤄진다.

 

복잡해 보이는가? 액티비티 가격에 수량을 곱하고, 원가계산 로트크기만큼 불려준 다음, 생산수량을 곱해주는 방식이다.

 

위 산식 대로 숫자를 대입해보면 이렇다.

 

이해되시려나? 이런 산식으로 액티비티 금액이 산출된다. 위 금액은 원가계산 로트크기인 1개 단위에 대한 원가 추정 값이다. 자, 그러면 여기서 한 가지 가정을 더 해보자. 생산 수량이 200개라면? 먼저 엑셀로 계산해보자.

 

위 그림처럼 2,576,664원이 나온다. 그러면 시스템으로도 같은 결과가 나오는지 확인해볼까?

 

T-CODE: CK13N에서 원가기준을 '사용자 엔트리'로 선택하고 수량을 200으로 입력. 의외로 이거 모르시는 분들 있더라

 

이렇게 수량을 200으로 하고 조회해보면

 

 

 

놀랍게도 값이 다르다. 왜?? 사실은 이런 식으로 계산되기 때문이다.

 

반올림이다, 반올림...

 

액티비티 가격이 "원화"이기 때문에 소수점 0자리에서 반올림되었기 때문이다. 소수점 2자리 통화였다면 2자리에서 반올림된다. 따라서 엑셀을 다음과 같이 고치면 값이 일치한다.

 

문제는 바로 ROUND

뭐가 문젠가? 178,935의 액티비티 가격이 가격 단위 10을 만나서 17,893.5로 소수점이 생겨버렸고, 그 숫자가 반올림되어 버린 것이다. 또, 액티비티 수량인 0.72를 곱하면서 다시 소수점 2자리가 추가되어 버렸다. 이 문제를 해결하려면 어떻게 하면 될까?

 

원가계산 로트크기를 '소수점 2자리를 다시 정수로 돌려줄 수'로 하면 된다. 즉 100으로 하면 된다.

 

이번에는 엑셀과 시스템을 모두 수정해서 비교해보자.

 

T-CODE: MM02 자재 마스터에서 원가계산 로트크기를 변경한다.

 

 

자, 지금까지 확인해본 바에 따르면 원가계산 로트크기가 [ 액티비티 가격단위, 액티비티 수량 ]보다 작으면 단수 차이를 발생시킨다. 즉, 원가계산 로트크기는 최소한 액티비티 가격단위보단 커야 하는 것이라고 생각해볼 수 있다.

 

그런데 이게 완전한 답은 아니다. 알아야 할 게 하나 더 있다.

 

월중 백플러시나 직접 Confirmation을 통해 액티비티 금액이 들어올 때는 위와 다른 산식을 적용받는다는 점이다.

 

 

이 때는 이런 산식을 적용 받는다. 먼저 액티비티 수량을 정해놓고 가격을 곱하는 방식이기 때문이다.

 

T-CODE: S_ALR_87012993에서 더블 클릭해서 조회

 

즉 월중 액티비티 금액이 들어올 때는 원가계산 로트크기는 안 쓴단 의미다. 이제 서두에서 말했던 "원가계산 로트크기는 원가 '추정' 시 사용되는 단위"라는 말의 뜻이 이해되는가? 원가계산 로트크기는 사전원가 추정 시에는 사용되지만, 실제원가 계산 시에는 사용되지 않는다.

 

따라서 이런 식으로 잘못 계산된 채로 두고 결산을 수행하면, 엉뚱한 금액이 차이 금액으로 표시되게 된다.

 

T-CODE: KKS2(차이계산)

이 차이를 분석할 수 있겠는가? 시스템에서는 단순히 가격차이라고만 나타난다. 우리는 이 사례를 직접 만들어 봤기 때문에 이게 단수 차이라는 걸 알지만, 실제 업무 상에서는 그걸 구분해낼 수 있겠는가?

 

그러긴 어렵다. 따라서 애초부터 기준정보를 잘 관리하는 게 답이다.

 

표준원가 계산 시와 생산 Confirmation 시의 산식이 다르기 때문에 둘 간의 단수차이 문제는 계속 남게 된다. 그렇다면 둘을 일치화시키는 가장 좋은 방법은 무엇일까?

 

그림을 잘 보면 반올림이 들어가는 산식에 값이 다른 건 둘 뿐이다.

 

위 그림을 잘 보면 반올림이 들어가는 산식에 값이 다른 건 둘 뿐이다. 원가계산 로트크기와 생산수량이다. 즉 이 둘의 자릿수만 맞추면 모든 게 해결된다. 비록 원가계산 로트크기가 액티비티 가격단위나 라우팅 수량보다 작은 자릿수를 써서 단수가 발생한다 하더라도, 생산 Confrimation 시에도 동일한 단수가 발생하기 때문에 둘 사이에 차이는 사라지게 된다.

 

따라서 

원가계산 로트크기가 [ 액티비티 가격단위, 액티비티 수량 ]보다 작으면 단수 차이를 발생시킨다. 하지만, 실제 단수차이 데이터가 발생하지 않게 하려면 원가계산 로트크기를 생산로트단위와 일치시켜야 한다.

 

여기까지 이해됐으면 자재의 가격단위도 이와 마찬가지라고 생각을 진전시켜보자.

 


 

2. 구매자재의 원가계산 로트크기는 [ 구매 기준수량 단위 ]와 동일한 자릿수여야 한다.

 

이번에는 이 초콜릿 덩어리에 투입되는 원자재를 생각해보자. 이 경우에는 아래와 같은 산식으로 계산된다.

 

그런데 이런 경우를 테스트하기 위해 자재 마스터에서 가격단위와 원가계산 로트크기를 바꾸려고 하면...

 

SAP가 당연히 바보는 아니다. Validation을 걸어놨다.

Validation이 걸려 있다. 액티비티는 입력 화면에서 자재코드와 연결고리를 찾을 수 없기 때문에 Validation을 걸지 못했지만, 자재코드는 가격단위와 원가계산 로트크기를 하나의 화면에서 관리하므로 이렇게 잘못 입력되지 않게끔 해놨다.

 

그럼 걱정 없는 걸까? 자재 마스터 내에서 Validation만 잘 되면? 그렇지는 않다.

 

이러면 어떨까. 이 원자재가 실제 구매할 때는 100개 단위로 구매하기로 계약했다면?

 

T-CODE: ME21N(구매오더 생성)

 

위 그림처럼 거래의 실질상 해당 100개당 가격으로 구매하도록 되어 있다면? 이런 경우라면 원가계산 로트크기를 1개로 했을 때 반올림되어 500,078 ÷ 100 = 5,001이 되어버린다.

 

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

 

따라서 이대로 입고하면 잘못된 가격단위/로트크기 때문에 차이금액이 발생한다. 위 그림에서 보는 것처럼 100개를 입고했는데 예비평가와 실제값 간의 차이로 22원이 발생했다.

 

T-CODE: FB01(전표 조회)에서도 차이금액을 확인할 수 있다.

이 차이금액 22원을 분석할 수 있겠는가? 표준가격인 500,100보다 22원 싸게 구매했으니 구매부서의 성과로 봐야 하나? 단순히 로트크기의 차이 때문에 표준이 잘못 설정된 것인데도??

 

엄밀히 말하면 이 부분은 구매부분의 Lot Size Variance로 봐야 하나, 현재 SAP 스탠다드상 이걸 구분해낼 수 있는 툴은 없는 걸로 안다.

 

따라서 원자재의 가격단위와 원가계산 로트크기는 구매계약 시 기준수량과 일치시키는 것이 가장 합리적이다. 위 사례에서 구매계약 시 기준수량이 100개였으므로, 자재 마스터의 가격단위와 원가계산 로트크기도 100으로 바꿔주면 되겠다.

 

 

[2021.12.02 추가] 구매정보레코드의 스케일값과 고려하는 것도 필요하다

아래 "jeonghun lee" 님의 댓글을 보고 추가. 앞서 구매계약 시 기준수량이라고는 했지만 부족했던 부분이 있었다. 구매에서 기준수량에 따라 단가를 다르게 받는 경우가 있는데 이럴 때 어떤 기준수량을 원가계산에서 쓸지에 따라 원가계산 로트크기도 달라진다. 예를 들어보자.

 

T-CODE: ME12(구매정보레코드 변경)

 

위 그림에서 자재 BC10020(우유)의 경우 기본가격은 1KG에 1,200원이지만, 상단의 "스케일" 버튼을 클릭해보면

 

T-CODE: ME12(구매정보레코드 변경) 조건유형의 스케일값

 

이렇게 스케일 수량에 따라 단가를 다르게 계약했다고 해보자. 이 상태에서 표준원가 추정을 하면 어떤 가격을 가져오게 될까?

 

T-CODE: CK11N(표준원가 추정)

 

이처럼 원가계산 로트크기의 단위인 1,000을 스케일 수량으로 하여 가격 정보를 가져온다. 따라서 구매 기준수량 단위를 가져오되, 여러 스케일 수량 단위가 있는 상황이라면 그 중에서 표준원가에 가장 적합한 기준수량 단위를 선택하는 것이 합리적이다.

 

 

 


3. 결론

 

이제 정리해보면 다음과 같은 골든룰이 나온다.

 

 

이 별 거 아닌 거 같은 원가계산 로트크기를 결정하기 위해서 생산과 구매의 기준 수량 단위를 파악해야 하는 것이다. 이렇게 해야 차이분석 시 단수차이로 인한 금액을 다른 차이로 오인하지 않게 된다.

 

나도 이걸 뜯어보기 전까지는 이게 이렇게나 신경 써야 할 건지 몰랐다.

 

물론 비즈니스 상황에 따라 중요성이 그다지 높지 않을 수도 있다. 회사 규모, 생산 방식에 따라 다르겠지만 금액효과가 매우 작을 수도 있고...

 

또 특정 자재(SKU)의 생산 로트 단위나 구매 기준수량 단위가 여러 개일 경우, 어쩔 수 없이 단수 차이는 생긴다. 그러니 그냥 쉽게 일괄 10,000 단위 정도로 입력해두는 게 오히려 편할지도 모르겠다. 다만 이 경우에도 구매정보레코드의 스케일 수량별 단가전략을 참고해서 합리적인 단위를 설정하는 게 좋겠다.