Combined CO-PA - (5) 기술적 구조

 

마지막으로 cPA의 기술적 구조를 살펴보고자 한다.

기존의 Costing-based PA와 비교해서 많은 부분이 바뀌었다. 우선 Costing-based PA일 경우의 구조를 살펴보자.

 

 

 

 

---

 

1. Costing-based PA의 데이터 구조

 

 

Costing-Based PA의 테이블 구조

 

Costing-based PA의 경우 위 그림과 같았다.

 

CE1XXXX - 실제 개별항목 테이블

CE2XXXX - 계획 개별항목 테이블

CE3XXXX - PA 세그먼트별 계획/실제 총계 테이블(값필드만)

CE4XXXX - PA 세그먼트별 특성조합 테이블

 

여기서 XXXX란 경영단위의 코드를 의미한다. 경영단위를 만들 때마다 각각의 테이블이 따로 생긴다고 보면 된다.

 

 

경영단위와 테이블 이름

 

 

그럼 과거 ECC 시절에는 어떻게 개발했을까. 우선 CE1 테이블이나 CE2 테이블을 직접 읽는 경우는 거의 없었다. 그렇게 하면 속도가 굉장히 느렸었기 때문이다.

 

그래서 보통은 CE3 테이블과 CE4 테이블을 조인하여 리포팅을 했다. 실제로 T-CODE: KE30을 통한 조회 시에도 내부적으로 그런 식으로 쿼리를 만들었었다.

 

하지만 S/4HANA에 와서는 굳이 그런 식으로 하지 않고 CE1 테이블을 Aggregation해서 조회해도 별 무리가 없게 바뀌긴 했다.

 

 

 

 

---

 

2. Combined PA의 데이터 구조

 

cPA의 경우는 어떻게 변했을까? 아래 그림처럼 구조가 변화했다.

 

 

cPA의 테이블 구조

 

CE9KEFI_H - 헤더 테이블(실제)

CE9KEFI_IC - 계정 뷰(실제)
CE9KEFI_IQ - 수량 뷰(실제)
CE9KEFI_IV - 값필드 뷰(실제)

CE9KEFI_P_H - 헤더 테이블(계획)
CE9KEFI_P_IC - 계정 뷰(계획)
CE9KEFI_P_IQ - 수량 뷰(계획)
CE9KEFI_P_IV - 값필드 뷰(계획)

 

우선 계획과 실적 데이터의 테이블이 완전히 분리됐다.

 

그리고 더 이상 개별항목 테이블과 총계 테이블을 구분하지 않는다. S/4HANA부터는 총계 테이블은 대부분의 경우 더 이상 필요하지 않다. 필요한 경우는 CDS 뷰를 통해 구현할 수 있기 때문이다.

 

라인 아이템 레벨에서도 특성 조합과 값 테이블이 분리되었다. 이제 특성 조합 내용은 헤더 테이블을 통해 기록된다. 헤더 테이블에는 cPA 전표의 "특징" 탭과 "참조/관리" 탭의 내용이 들어간다.

 

 

헤더, 계정 뷰, 값필드 뷰, 수량 뷰

 

그 외에 계정 뷰와 수량 뷰, 값필드 뷰의 내용이 각각의 테이블에 들어간다.

 

 

헤더, 계정 뷰, 값필드 뷰, 수량 뷰의 테이블

 

 

그럼 만약에 KE30과 같은 리포트를 만드려면 어떻게 해야할까?

 

아래와 같은 방식으로 CDS 뷰를 만들면 간단하다.

 

 

PA 리포팅을 위한 CDS 뷰 예제, 소스 일부

 

 

먼저 헤더, 수량 뷰, 값필드 뷰, 계정 뷰의 집계 CDS 뷰를 만들고 각각의 헤더를 기준으로 LEFT OUTER JOIN하여 보여주는 식으로 구현하면 된다.

 

이렇게 만들고 나면 아래와 같은 방식으로 조회할 수 있다.

 

 

PA 리포팅을 위한 CDS 뷰 예제, 조회 화면

 

 

 

---

 

3. Combined PA의 BAPI, BADI

 

 

 

KEPSL_DOC_POST_EXT_KEFI: cPA 전표 생성 BAPI

KEPSL_DOCUMENT: 추가 수량 필드 계산, 통화 환산, 수량 계산 시 메시지 변환 BADI

KEPSL_FI: 레코드 유형 B에 대한 전표 생성 시 수정 BADI

KEPSL_POST_ACT: PA 전표 수정 BADI

KEPSL_SD: 레코드 유형 F에 대한 전표 생성 시 수정 BADI

KEPSL_SETTLEMENT: 레코드 유형 C에 대한 전표 생성 시 수정 BADI

 

이처럼 cPA에서는 EXIT이 다 BADI로 변경되었다. 따라서 과거에 Costing-based PA에서 사용하던 EXIT인 COPA0005는 더 이상 활용되지 않는다.

 

예를 들어 KEPSL_POST_ACT의 구현 화면을 보면 아래와 같은 식이다.

 

 

T-CODE: SE19(BAdI Builder), KEPSL_POST_ACT의 구현 모습

 

 

 

 

---

 

4. 마치며

 

짧은 글인데도 그동안 해외 출장까지 다녀오는 바람에 작성이 더욱 늦어졌다.

 

이번 프로젝트를 하면서 cPA가 구현되는 걸 봐보니 앞으로는 Costing-based PA를 사용할 환경이라면 cPA로 구현하는 게 더 좋겠다는 생각이 든다. 기존 Costing-based PA의 기능을 유지하면서도 L 타입 레코드 유형을 통한 FI vs. PA 대사의 용이성, 다양한 통화 및 평가뷰를 활용할 수 있는 점, 더 많은 BADI, CDS 뷰를 활용해 간편해진 데이터 구조 등 장점이 더 많다.

 

따라서 Account-based와 Cositng-based 중 어떤 걸 사용할 것인지는 여전히 구축 때마다 검토가 필요하지만, 만약 Costing-based를 쓰기로 의사결정했다면 더 좋은 cPA로 구현하는 게 좋을 것 같다.