본문 바로가기

SAP CO/깊숙한 개념

Combined CO-PA - (3) SD 판매문서와 "L" 타입

 

지난 글에 이어 이번에는 SD 판매문서로부터 PA 전표는 어떻게 생성되는지 알아보자.

 

 

 

 


 

1. 판매문서의 어떤 시점에 PA 전표가 생기는가?

 

SD의 판매 프로세스를 간단히 살펴보자. SD 전문가가 아닌 우리 수준에서 간단하게만 살펴보면 ① 판매오더 → ② 출하 문서 → ③ 대금청구의 3단계로 이뤄진다고 볼 수 있다. 각 단계에 따라 어떻게 PA 전표가 생기는가? 아래 그림을 보자.

 

 

PA의 종류에 따른 생성 시점 차이

 

 

(1) 원가중심 PA의 경우

 

① 판매 오더 시점에는 별다른 회계 전표가 생성되지 않는다. 별도 설정을 한다면 PA는 기표할 수는 있으나 그 부분은 이 글에서는 주제와 어긋나므로 나중에 알아보자.

 

② 출하 문서에 따른 출고 전기 시점에는 FI 전표가 생긴다. 회계적으로 살펴봐도 그 시점에 해당 재고자산에 대해 통제력이 이관된다면 매출원가로 비용화하는 것이 타당하다.

 

그런데 원가중심 PA의 경우 이 시점에 매출원가를 인식하지 않았다. 원가중심 PA는 매출액이 발생하는 ③ 대금 청구 시점에 매출액과 매출원가를 동시에 인식했다.

 

여기서 FI와 CO-PA의 가장 큰 차이가 생겨난다. 출고전기만 하고 대금청구는 하지 않은 상태라면? 이런 경우 FI에만 매출원가 전표가 생성되고 PA는 아무런 전표가 생기지 않았다. 이게 1차적으로 문제가 되곤 했다. 

 

또는 대금청구 시점에 PA 문서가 생기더라도 FI 전표와 금액이 다르다면? 이런 일이 안 생길 것 같지만 의외로 흔하게 생긴다. FI 문서를 만드는 시점의 재고평가방식과 PA 문서를 만드는 시점의 재고평가방식이 "기술적으로" 다르기 때문이다. 기술적으로 다르단 의미는 시스템 로직이 다르단 의미다. 전체적인 개념은 같지만 코딩이 다르다고 이해해주면 되겠다. (PA쪽 세팅이 더 유연하지만 어쨌든 차이가 발생할 여지는 생긴다)

 

따라서 이에 대응하려면 별도의 노력이 필요하다. 우선 판매출고된 내역이 모두 대금청구까지 처리됐는지 살펴봐야 한다. 그래도 다르다면 대금청구 문서로부터 발생된 매출/매출원가가 잘못된 부분은 없는지 확인해야 한다. 매출원가가 잘못된 부분이 이론상 안 생길 것 같지만 의외로 꽤 생긴다. 운영을 하다보면 종종 겪으리라 본다.

 

 

(2) 계정중심 PA의 경우

 

반면에 계정중심 PA에서는 FI 전표 그 자체가 PA 전표이기 때문에 둘 간의 차이가 생길 여지가 없다. 이 부분이 정말 강력한 장점이긴 하다. 계정중심 PA는 세팅도 간편한 주제에 이런 장점이 있다.

 

그럼 단점은 무엇일까? 과거에 단점이었던 부분은 매출원가의 코스트 컴포넌트별 분석이 안 된다는 점, 그리고 FI 전표에는 없는 판매오더의 조건 유형 데이터를 추출할 수 없다는 점이었다.

 

이 부분은 S/4HANA에 오면서 모두 극복됐다. 우선 매출원가의 코스트 컴포넌트별 분할이 된다. 판매오더의 조건 유형 데이터나 PA만의 별도 데이터는 모두 Extension Ledger를 통해 기표 가능하다. 원가중심이 손익센터 평가만 되는 반면, 여기서는 그룹평가도 가능하다. 통합원장에서부터 가능해졌기 때문이다.

 

분명 많이 강력해졌다. 그러나 그럼에도 약간의 단점은 남는데 바로 속도다. 어찌 됐든 FI 전표를 만들어야 하기 때문에 FI 전표를 만들면서 지나치는 Validation, Subsitution, BTE 등을 모두 타야 한다. 그리고 단식 부기여서 라인 아이템을 하나만 생성해야 하는 다른 PA와 달리 무조건 상대 계정도 함께 만들어줘야 한다.

 

이 때문에 CTG 사업인 K 모 회사에서는 CCA to PA 배부 시 가장 오래 걸리는 사이클은 3~4시간까지 걸린다고 한다.

 

 

(3) cPA의 경우

 

cPA의 경우는 기본적으로 원가중심일 때와 같다. 하지만 한 가지가 더 추가됐는데 바로 레코드 유형 "L"이다. 이 덕분에 출고 시점의 매출원가도 집계되고, 대금청구 시점에는 매출/매출원가가 동시에 한 번 더 집계되게 된다.

 

그리고 레코드 유형 "L" 데이터는 해당 데이터가 대금청구까지 완료되면, 대금청구 완료 지시자가 찍혀 따로 표시도 가능하다. 지금부터는 이에 대해 상세히 살펴보자.

 

 

 


 

2. 출고 시점의 "L" 타입 문서 생성

 

판매오더를 만들고 출고해보자.

 

 

T-CODE: VA01(판매오더 생성)

 

자재 BC90010(초콜릿 바)라는 걸 고객 1000002(킴 영업 스토어)라는 곳에 50,000원에 판다고 해보자. 판매오더를 만들고 이어서 출하문서를 만든다.

 

 

T-CODE: VL01N(출하문서 생성) 출고 전기 실행

 

출하 문서를 만들고 상단의 '출고 전기' 버튼을 클릭한다.

 

 

T-CODE: FB03(전표 조회) - 매출원가 전표

 

그럼 위 그림과 같은 회계전표가 생긴다. 이와 동시에 자재 문서(MM 전표)와 자재 원장 전표도 생겨, MM, FI, CO에 모두 반영된다.

 

그런데 이 때 PA 전표도 생길까? 원가중심이라면 생기지 않았겠지만 cPA라면 생긴다. 아래 그림을 보자.

 

 

T-CODE: KE23N(PA 전표 조회) - 레코드 유형 "L"의 전표 모습

 

레코드 유형 "L"의 전표는 위와 같은 모습으로 생긴다. 참조/관리 뷰에서 보면 해당 트랜잭션의 빌링까지 처리 여부도 보여지고, 참조한 MM 전표는 무엇인지도 보여준다.

 

이후 대금청구문서까지 만들게 되면 어떻게 될까.

 

 

T-CODE: VF01(대금청구문서 생성)

 

T-CODE: VF01을 통해 대금청구문서를 만들고 회계까지 릴리즈해보자.

 

 

T-CODE: FB03(전표 조회) - 매출액 전표

 

그럼 이렇게 매출액 전표가 생긴다. cPA 전표는 어떻게 될까?

 

 

T-CODE: KE23N(PA 전표 조회) - 레코드 유형 "F"의 전표 모습

 

이 때 수익과 비용이 동시에 기표된다. 이 전표의 형태는 원가중심과 크게 다르지 않다. 다른 점이 있다면 기존에 생겼던 레코드 유형 "L" 전표다. 다음과 같이 변화한다.

 

 

T-CODE: KE23N(PA 전표 조회) - 레코드 유형 "L"의 빌링 후 전표 모습

 

위 그림처럼 '청구됨' 지시자가 체크 표시되고, '청구 기간'에는 대금청구문서가 전기된 기간이 표시된다. 이로써 출고 전표의 마감 여부도 관리할 수 있다.

 

 

T-CODE: KE27(기간별 평가)

 

원가결산 이후 매출원가를 실제원가로 바꿔주는 T-CODE인 KE27을 수행할 때도, 레코드 유형 "L"을 고를 수 있다.

 

 

T-CODE: KE27(기간별 평가) - 로그 출력

 

수행 결과 화면에서도 레코드 유형 "L"에 대해서도 잘 처리됐음을 볼 수 있다.

 

 

 


 

3. "L" 타입 문서 생성을 위해 필요한 세팅은?

 

그럼 이 세팅을 하려면 어떻게 해야 할까? 약간 변칙적인 세팅이 필요하다. (IMG 메뉴 설명에는 나오는 방법이긴 하지만)

 

 

T-CODE: KEPSC09(비즈니스 트랜잭션에 PA 전송 구조 지정)

 

바로 위 그림과 같은 '비즈니스 트랜잭션에 PA 전송 구조 지정'이라는 세팅이 필요하다. 이 세팅을 통해서 원가중심과는 다른 우회 설정이 가능해진다. 

 

무슨 말인가? 기본적으로 원가중심에서는 출고 시점의 PA 전송 구조는 "FI"로 자동 지정되게 되어 있다. 여기서는 MM의 '비즈니스 트랜잭션'이라는 세부 단위를 활용하여 자재 출고 시점만을 위한 별도 PA 전송 구조를 지정할 수 있다. 위 예시에서는 "Z9"로 연결했다. 이렇게 하면 원래 PA 전송 구조 "FI"로 갈 것이, 대신 "Z9"로 우회하게 된다.

 

 

T-CODE: KEI2(PA 전송 구조 지정)

 

그리고 PA 전송 구조는 위 그림처럼 세팅한다. 이렇게 하면 "L" 타입에 대해서도 수량 필드가 전달되게 된다. 수량 필드가 전달되면 그 다음은? 바로 그 수량 필드를 이용해 원가 정보를 가져올 수 있도록 해줘야 한다.

 

 

T-CODE: KE4U(평가 전략)

 

위 수량 필드는 다시 평가 전략 설정 화면에서 지정하고, 그걸 통해 원가정보를 가져오도록 '자재 cost.'라는 항목을 체크한다. 이렇게 하면 해당 수량 필드에 대해 '코스팅 키'라고 하는 자재 원가정보를 들고오도록 할 수 있다.

 

평가 전략은 또 어떻게 지정되는가? '평가 포인트'라고 하는 데이터를 들어오는 시점마다 어떤 평가 전략을 선택할 것인지를 지정할 수 있다.

 

지정 방식이 참 복잡하기도 하다. 우선 평가 전략을 어떻게 지정하는지부터 그림을 보자.

 

 

T-CODE: KE4U(평가 전략) - 평가 전략 지정

 

위 그림이 평가 전략을 지정하는 그림이다. 평가포인트/레코드유형/계획버전의 조합에 따라 어떤 평가 전략을 지정할 것인지를 세팅한다. 그런데 cPA에서는 이 평가 전략을 보다 세세하게 지정할 수 있는 IMG가 추가됐다. 아래를 보자.

 

 

T-CODE: KE4UF(CO-PA 평가 전략 지정)

 

 

위 화면에서는 '통화 유형 및 평가뷰'까지 조건으로 추가하여 평가전략을 지정할 수 있다. 이 부분이 강력하다. 이전 글에서 봤던 것처럼 통화 유형 및 평가뷰가 단순히 환산만 되는 게 아니라 별도의 원가계산 정보까지 그대로 가져올 수 있기 때문이다.

 

이 세팅이 없었으면 아무리 자재원장이나 표준원가 정보가 Group Valuation에 대해 별도로 있다 하더라도 해당 정보를 그대로 가져올 순 없었을 것이다. 결국 환산할 수 밖에 없고 그러면 원치 않는 통화 환산에 따른 금액 차이가 발생한다.

 

 

T-CODE: KEPC(모든 특성에 원가계산 키 지정)

 

이어서 코스팅 키를 설정하는 화면이다. 여기서도 통화유형/평가뷰에 따라 달리 설정이 가능하다.

 

지금까지의 세팅은 화면 캡쳐만으로는 한눈에 이해하기 어렵다. 전체를 조망하는 그림을 그려보면 아래와 같다.

 

 

평가전략과 코스팅 키의 연관 관계

 

 

이 그림만 잘 이해하셔도 사실 다 끝났다. 이런 형태로 평가전략과 코스팅 키가 연결된다. 여기서 cPA를 위해 새로 나온 세팅인 T-CODE: KE4UF에서는 통화 유형 및 평가뷰 등 보다 복잡한 조건을 추가해서 평가 전략 키를 연결할 수 있단 점만 달라진 것뿐이다.

 

하나씩 설명해보자.

 

'평가포인트'란 PA에 데이터가 들어오시는 시점, 트리거이다. 01은 실제원가의 월중, 02는 실제원가의 월말이다. 01은 결산 프로그램이 아닌 월중 트랜잭션을 일으키는 프로그램을 통해 들어오는 것이고, 02는 결산 프로그램을 통해서 들어오는 시점이라고 이해하면 된다.

 

'레코드 유형'이란 PA의 데이터 소스를 구분해주는 구분자이다. "F"는 SD의 대금청구문서, "L"의 물류의 출고문서이다. 

 

'평가전략' 키는 PA 값필드에 값을 채워주는 방법을 정의한 키이다. 항목번호 순서에 따라 진행되며 여기서 "
자재 Cost."와 수량 필드를 지정해주면 '코스팅 키'라는 걸 찾게 된다.

 

'코스팅 키'란 특정 자재의 원가정보를 어디서 추출할 것인지 방법을 정의한 키이다. 코스팅 키도 여러 조건에 따라 다르게 선택할 수 있게 지정할 수 있다.

 

여기서 위에서 봤었던 "L" 타입 관련 세팅을 더하면 아래와 같은 그림이 된다.

 

 

레코드 유형 "L"을 연결하기 위한 평가전략과 코스팅 키의 연관 관계

 

위 그림을 말로 표현하면 이렇다.

 

"출고 시점의 비즈니스 트랜잭션인 'RMWL'을 PA 전송구조와 연결하고, PA 전송구조에서는 수량 필드와 연결한다. 그 수량필드는 다시 평가전략과 연결되어 코스팅 키를 통해 원가계산 정보를 가져오게 된다."

 

 

 


 

4. 다음 글에서는...

 

역시나 글이 길어졌다. 수량 뷰에 대한 설명을 다음으로 하고 여력이 되면 SD의 조건유형을 통해 통계 값을 추출하는 방법에 대해서도 알아보자. 그 내용 다음으로는 cPA의 테이블 구조, BAdi 등에 대해서도 알아볼 생각이다.