본문 바로가기

SAP CO/깊숙한 개념

백플러시 프로파일과 예비원가

 

 

 

백플러시(Back-flush)란 무엇인가?

 

 

 

 

 

 

 

백플러시(Back-flush)란 무엇인가? SAP "기능적으로" 대답하자면 '사전에 준비한 기준정보대로 불출 처리하는 것'이라고 대답할 수 있겠다.

 

하지만 본래의 의미는 조금 다르다.

 

대량 생산 환경에서 매우 빠른 생산리드타임으로 마구마구 제품이 생산될 때, 필요한 원재료를 하나하나 투입처리하기는 힘들다. 그러니 우선 제품의 생산 실적 처리부터 하고 투입된 원재료는 '거꾸로 계산해서 한 번에' 입력하는 방식을 사용한다.

 

즉 이 '거꾸로 계산해서 한 번에'가 바로 백플러시(Back-flush)의 본래 의미라고 보면 되겠다. (SAP 피플들이 흔히 말하는 식인) 사전에 준비한 기준정보대로 불출 처리한다는 것은 그저 이 백플러시의 방법 중 하나일 뿐이다.

 

그래서 나는 굳이 가장 가까운 번역어를 찾자면 '역산(逆算)' 정도가 되지 않을까 생각한다.

 

그런데 한편으로 생각해보면 '사전에 준비한 기준정보대로 불출'이라는 게 꼭 틀린 말일까 싶기도 하다. 그거 말고 백플러시를 할 수 있는 방법이 또 있나? 떠오르는 게 없다. 결국 그놈이 그놈인 것 같긴 하다.

 

 

어쨌든 SAP를 하는 사람들 사이에서는 사전 정의한 BOM 대로 불출하는 거라고 봐도 되긴 된다. 

 

SAP PP의 반복제조(REM) 환경에서 백플러시는 총 세 가지로 구분되어 사용하는데(조립품, 구성부품, 액티비티), 이번 글에서 언급하고자 하는 것은 액티비티 백플러시이다.

 

액티비티 백플러시는 반복제조 외의 환경에서 사용하는 액티비티 확정(Activity Confirmation)과 동일한 역할을 한다. CO의 입장에서 보자면 Direct Activity Allcoation과 같다. 이에 관해서는 아래 포스팅을 참조해주세요.

 

 

2021.11.06 - [SAP CO/기본 개념] - Direct vs. Indirect Activity Allocation (1)

 

Direct vs. Indirect Activity Allocation (1)

뭐가 Direct고 뭐가 Indirect라는 얘기일까? 내가 이 용어를 처음 접한 건 SAP 아카데미 교육 자료였다. Activity Allocation의 개념과 예시가 그려져 있었는데 그림을 아무리 열심히 들여다봐도 도무지 어

ckm3.tistory.com

 

아무튼 이 반복제조 환경에서의 액티비티 백플러시는 조금 남다른 면이 있다. 바로 사전에 설정한 표준원가나 예비원가를 참조하여 수행한다는 점이다. 생산의 반복제조 프로파일이란 IMG 세팅 화면에 가보면 아래와 같은 항목이 있다.

 

 

 

IMG: 생산 > 반복 제조 > 관리 > 반복제조프로파일 정의

 

위 그림처럼 표준원가를 참조할 것인지, 예비원가를 참조할 것인지를 선택할 수 있게 되어 있다. 이 부분을 F1을 눌러서 헬프를 보면...

 

 

 

액티비티 백플러시에 대한 F1 헬프

 

위와 같다. 여기서 주목할 만한 부분은 생산버전이다. 예비원가를 사용하는 경우라면 여러 생산버전에 따라 다른 액티비티를 처리할 수 있지만, 표준원가를 사용하는 경우라면 하나의 생산버전 밖에 사용하지 못한다고 한다.

 

여기서 우리는 한걸음 더 들어가보자.

 

 

 

1. 여러 생산버전에 액티비티 백플러시가 필요한 이유

 

우선 생산버전이 다르다는 건 무엇을 뜻하는가? 생산버전이란 BOM과 라우팅의 조합이다. 여기서 우리는 액티비티를 보고 있으니 BOM은 차치하고 라우팅만 생각해봐도 된다. 라우팅이 다르다는 것은 여러 의미가 있겠지만 반복제조환경에서는 보통 작업장은 곧 생산라인이므로, 생산라인이 다른 경우라고 보면 된다.

 

다시 정리하자면, 생산버전이 다르다는 것은 액티비티 관점에서는 하나의 제품에 여러 생산라인이 있는 경우라고 보면 된다. 각 생산라인마다 설비나 작업자가 다르다면 각 라인마다 다른 가공비가 나온다고 할 수 있겠다.

 

그래서 만약 각 생산라인이 각각 다른 코스트센터로 연결된 경우라면? 액티비티 백플러시에 따른 액티비티 배부도 각각의 코스트센터에 따로 기표된다.

 

그런데 위 설명에 따르자면 예비원가는 각각의 생산버전에 대해서 원가계산이 가능하지만, 표준원가는 그렇지 않다고 한다. 그러니 각각의 생산버전에 따라 올바르게 기표하고 싶으면 예비원가를 쓰란 뜻이 된다.

 

실제로 여러 생산버전이 있는 경우에 표준원가는 하나의 생산버전으로만 생성된다. 따라서 분명 2번 라인으로 생산하여 액티비티 백플러시를 했는데도, 참조하는 게 표준원가라면 1번 라인의 코스트센터에 액티비티 배부가 되는 왜곡현상이 발생한다.

 

따라서 이런 경우라면 예비원가를 쓰는 게 일반적으로는 더 맞다고 볼 수 있다.

 

하지만 여기서 한걸음 더 가보자. 표준원가로는 정녕 방법이 없을까? 

그렇지는 않다. 바로 "조달대체"와 "혼합률"이라는 걸 활용하면 표준원가로도 생산버전별 원가를 만들어낼 수 있다. 실제로 이렇게 사용하기도 한다. 하지만 표준원가는 1달에 1회라는 릴리즈 제약이 있기 때문에 만약 하나의 제품에 생산라인이 월 2번 이상 생성되는 경우(이런 경우가 자주 있다면 그걸 반복제조라고 보기도 어려울 것 같지만...), 그런 경우라면 대응이 안 되는 문제점이 있긴 하다.

 

 

 

2. 표준원가와 예비원가의 기술적 차이점은?

 

표준원가는 월중 1회만 릴리즈가 가능하다. 예비원가는 이와 달리 월중에 여러번 생성할 수 있다.

 

그런데, 표준원가는 월중 어느 때에 릴리즈하더라도 항상 그 기간의 1일자로 릴리즈가 되는 반면, 예비원가는 해당 계산 일자로부터만 유효하다.

 

예를 들어 7월 8일인 오늘을 생각해보면, 표준원가는 오늘 생성해서 오늘 릴리즈한다고 하더라도 테이블에는 7월 1일자로 기록된다. 따라서 7월 1일 ~ 7월 7일의 기간 동안에도 백플러시는 가능하다.

 

그런데 예비원가는 오늘 생성하면 오늘 날짜로 테이블에 기록된다. 따라서 7월 8일 이후부터의 백플러시만 가능하고, 그 이전 7월 1일 ~ 7월 7일 기간 동안의 백플러시는 불가능하다.

 

 

 

TABLE: KEKO(제품원가계산 - 헤더 데이터)

 

그러니까 위 그림처럼 된다. 01번은 표준원가, 19번은 예비원가이다. 이걸 둘다 오늘 만들었지만, 각각의 지정되는 일자는 다르다. 표준원가는 7월 1일, 예비원가는 7월 8일이 된다.

 

예비원가를 참조하는 경우에는 7월 1일부터 7월 7일 사이의 전기일로는 처리할 수 없게 된다.

 

이런 경우에는 아래와 같은 에러 메시지가 나온다.

 

 

 

에러 메시지 RM078

 

그럼 이런 경우의 임시방편으로는 뭐가 있을까?

 

1번. 그냥 전기일을 7월 8일 이후로 변경하는 방법이다. 일자별로 실적을 심각하게 따지지 않는 경우라면 괜찮다고 본다.

 

2번. 해당 자재코드의 백플러시 프로파일을 잠깐만 표준원가로 바꾼다. 그리고 처리가 끝나면 다시 원복한다. 만약 생산버전별 별도 기표가 필요한 상황이라면 표준원가에 조달대체와 혼합률을 만들어서 릴리즈한다.

 

이런 정도가 있을 수 있겠다.

 

 

 

3. 마지막으로 한 가지...

 

사실 이번 글을 쓰게 된 이유는 이와 관련하여 알 수 없는 에러를 겪었던 경험 때문이다. 아까의 테이블 KEKO를 다시 보자.

 

 

 

TABLE: KEKO(제품원가계산 - 헤더 데이터)

 

예비원가의 평가변형이 보이는가? "001"로 현재 설정되어 있다. 그런데 만약 이 설정을 지금 바꾸면 어떻게 될까?

 

 

 

T-CODE: OKKN(원가계산변형 설정)

 

이 그림의 평가변형을 '001'이 아니라 다른 걸로 바꾼다면? 그렇다면 놀랍게도 백플러시 시 원가추정 결정오류가 난다.

 

이걸 몰라서 바꿨다가 에러가 났었다. SAP Support에 Case(incident)를 작성해서 물어보니까 이거 때문이라고 알려주더라. 일반적으로 평가변형은 수정할 수 없게 되어 있지만, 나는 굳이 저걸 삭제하고 다시 만드는 방법으로 변경했었기에 발생한 에러였다.

 

정말 이렇게 알 수 없는 에러가 나는 경우에는 구글링도 좋고 note 검색도 좋지만, 다 해봐서 안 되면 Case 작성이 참 빠르고 좋다. 혼자 끙끙대지말고 Case를 쓰는 게 여러모로 속 편하다.