BPC와 Group Reporting, 연결 엔진은 무엇이 다른가 ③ 데이터 모델
연재: SAP BPC vs Group Reporting 연결 엔진 비교 (3/5) ① 비교의 틀 · ② 아키텍처 · ③ 데이터 모델 · ④ 프로세스 · ⑤ 시사점과 용어 대응표
지난 회차에서는 BPC가 ERP 밖의 BW에, GR이 S/4HANA 안에 있다는 아키텍처 차이를 살펴봤습니다. 이번 회차에서는 그 차이가 데이터 모델, 즉 연결 데이터를 무엇으로 어떻게 표현하는지에 어떤 영향을 주는지 일곱 가지 측면에서 정리합니다.
1. 모델링 철학: 유연성 대 표준화
BPC는 사용자 정의 Dimension 기반의 유연성 모델이고, GR은 사전 정의된 Master Data 기반의 표준화 모델입니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
모델 구성 주체 | 컨설턴트가 Dimension 구성과 Model을 직접 설계 | SAP가 정의한 데이터 모델(ACDOCU 필드)에 값을 설정 |
분석 축 추가 | Dimension·Property를 추가해 고객별로 확장 | 사전 정의된 추가 특성 중 선택해 활성화 |
고객 간 차이 | 같은 BPC라도 고객마다 모델 구조가 다름 | 고객이 달라도 핵심 구조는 동일 |
설계 품질 | 모델 설계자의 역량에 크게 좌우 | 표준 구조로 일정 수준이 보장되나, 표준 밖 요구는 확장이 필요 |
BPC 경험자가 GR을 볼 때: 'Dimension을 하나 더 만들자'는 해법이 GR에는 없습니다. 요구를 사전 정의된 객체(Subitem, 추가 특성 등)에 어떻게 담을지부터 판단해야 합니다.
GR 경험자가 BPC를 볼 때: BPC는 고객마다 모델 구조가 다릅니다. 표준 지식으로 접근하기보다 해당 고객의 Dimension 설계와 Property부터 파악해야 합니다.
2. Dimension과 Master Data 매핑: 어디까지 대응되는가
두 엔진의 핵심 객체는 대부분 서로 대응됩니다. 하지만 어느 한쪽에만 있는 개념이 양방향으로 존재하고, 이것이 설계 오해의 주요 원인이 됩니다.
BPC Dimension | GR 대응 객체 | 대응 수준 | 차이와 주의점 |
|---|---|---|---|
Entity | Consolidation Unit | 1:1 | 회사와 연계되는 연결 단위 |
Scope (연결 그룹) | Consolidation Group | 1:1 | GR은 그룹 구조와 편입·제외 기간을 마스터로 관리 |
Account | FS Item | 1:1 | GR은 FS Item 속성(유형, Subitem Category)이 로직을 결정 |
Flow | Subitem (Subitem Category) | 부분 | BPC는 사용자 정의, GR은 범주로 FS Item에 묶임 |
IntCo | Partner Unit | 1:1 | GR은 파트너 단위 필드로 거래 상대를 식별 |
Category | Version | 부분 | GR Version은 환산·데이터 소스 등 특수 버전 설정을 포함 |
Time | Fiscal Year / Period | 1:1 | GR은 Periodic 저장으로 기간 연속성을 강제 |
RptCurrency | Local / Group / Transaction 금액 필드 | 구조 차이 | BPC는 Dimension 멤버, GR은 같은 행의 별도 금액 필드 |
AuditTrail | Document Type + Posting Level | 구조 차이 | GR은 통제 규칙을 포함 |
사용자 정의 Dimension | 사전 정의 추가 특성 | 대응 없음 | 양쪽에 서로 대응되지 않는 축이 존재 |
BPC 경험자가 GR을 볼 때: Flow와 AuditTrail을 정의하던 방식으로 Subitem Category와 Document Type을 자유롭게 만들면 안 됩니다. 둘 다 연결 로직과 통제에 직접 연결되어 있습니다.
GR 경험자가 BPC를 볼 때: BPC의 RptCurrency와 AuditTrail은 Dimension 멤버입니다. GR처럼 금액 필드나 통제 규칙으로 해석하면 조회 결과를 잘못 읽게 됩니다.
3. 저장 방식: YTD 대 Periodic
GR은 Flexible Upload에서 YTD 누적 입력을 지원합니다. 따라서 BPC에서 익숙한 입력 방식은 그대로 유지할 수 있습니다. 하지만 저장은 Periodic이어서 기간 연속성이 구조적으로 강제됩니다.
간단한 예로 차이를 보겠습니다. 어떤 계정의 1~3월 누적 금액이 100, 250, 330이라고 하겠습니다.
구분 | 1월 | 2월 | 3월 |
|---|---|---|---|
BPC (YTD 저장) | YTD 100 | YTD 250 | YTD 330 |
GR (Periodic 저장) | 증감 +100 | 증감 +150 | 증감 +80 |
BPC에서는 각 기간의 값이 서로 독립적입니다. 3월 값을 고쳐도 1월과 2월에는 영향이 없고, 특정 기간만 단독으로 결산하거나 다시 작성할 수 있습니다. GR에서는 YTD를 조회할 때 기간 증감을 누적해서 계산하므로, 당기 결과가 전기까지의 누적 잔액에 의존합니다.
BPC는 Model별로 YTD와 Periodic 중 저장 방식을 선택할 수 있습니다. 이 글은 연결 모델에서 많이 쓰는 YTD 저장 모델을 기준으로 설명합니다.
BPC 경험자가 GR을 볼 때: 분기 보고 법인이나 기중 편입 법인처럼 기간을 건너뛰던 결산은 GR에서 누적 잔액 이관과 기간 운영 방식을 다시 설계해야 합니다.
GR 경험자가 BPC를 볼 때: BPC는 기간이 독립적으로 저장되므로 전기 수정이 당기 기초에 자동으로 반영되지 않습니다. 기초 잔액이 맞는지는 이월 절차로 확인해야 합니다. 이 내용은 다음 회차에서 자세히 다룹니다.
4. Audit Trail 대 Posting Level: 출처 구분인가, 통제 규칙인가
BPC의 AuditTrail은 데이터 출처를 구분하는 Dimension입니다. 반면 GR의 Document Type과 Posting Level은 연결 단계와 통제 규칙 자체를 정의합니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
구분 기준 | AuditTrail 멤버로 입력·조정·제거 출처를 구분 | Posting Level로 연결 단계를 구분 (보고 데이터, 내부거래 제거, 투자자본 상계 등) |
정의 주체 | 멤버와 계층을 고객이 자유롭게 정의 | Posting Level은 SAP가 정의하고, Document Type은 고객이 정의하되 Posting Level에 귀속 |
통제 기능 | 멤버 자체에는 통제 기능이 없음. 통제는 Business Rule, Journal, Work Status가 담당 | Document Type이 차대 균형 검사, 자동 역분개, 번호 범위 등 통제 속성을 가짐 |
조회 활용 | AuditTrail 계층으로 단계별 금액 조회 | Posting Level과 Document Type으로 연결 단계별 금액 조회 |
BPC 경험자가 GR을 볼 때: AuditTrail 멤버를 나누던 기준으로 Document Type을 늘리면 안 됩니다. Document Type은 Posting Level과 통제 속성이 함께 묶인 설정입니다.
GR 경험자가 BPC를 볼 때: BPC AuditTrail 자체에는 통제 기능이 없습니다. 수기 조정의 차대 균형이나 승인 통제는 Journal과 Work Status 설정에서 따로 확인해야 합니다.
5. 지분 모델: 지분율과 투자 이벤트 이력
두 엔진 모두 표준 기능은 특정 시점의 지분율만 관리합니다. 취득, 추가 취득, 처분 같은 투자 이벤트의 이력은 별도의 확장 모델에 둬야 합니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
표준 지분 데이터 | Ownership Model에 POWN, PCON, PCTRL, METHOD를 기간별로 관리 | 그룹 구조(Ownership)의 투자·지분율과 그룹별 연결 방법을 관리 |
지분 계산 | Ownership Manager가 직·간접 지분율 계산 | Rule Based CoI에서 그룹 지분율 계산에 사용 |
투자 이벤트 이력 | 표준 없음. 별도 투자자본 이력 Model과 커스텀 로직으로 관리 | 표준 없음. 커스텀 테이블(Z 테이블 또는 CBO)과 RAP로 관리 |
이력 없이 처리할 때 | 지분 변동 금액을 수기로 입력·조정 | 외부에서 이력을 관리하고 Activity Code·Subitem으로 업로드 (Activity Based CoI. Public Cloud에서는 티켓 요청 시 사용 가능) |
참고로 GR Public Cloud에서는 Rule Based CoI가 표준 방식으로 기본 제공되고, Activity Based CoI를 쓰려면 별도로 요청해야 합니다.
BPC 경험자가 GR을 볼 때: Ownership Manager처럼 지분 데이터를 한곳에서 관리한다고 기대하면 안 됩니다. GR에서는 지분율은 그룹 구조에, 이력은 확장 영역에 나뉘어 있습니다.
GR 경험자가 BPC를 볼 때: BPC의 Ownership Model은 기간별 지분율의 스냅샷입니다. 취득·처분 이력은 고객별 커스텀 Model에서 찾아야 합니다.
6. 통화와 환산 모델
환산 규칙이 BPC의 Rate Model과 FX Business Rule에서 GR의 Exchange Rate Type과 Translation Method 구성으로 바뀝니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
환율 저장 | 별도 Rate Model에 환율 유형(AVG, END, HIST 등)별로 저장 | S/4HANA 환율 테이블의 Exchange Rate Type 사용 (원장과 공용) |
환산 규칙 | Currency Translation Business Rule에서 계정 유형·Flow별 환율 지정 | Translation Method에서 FS Item·Subitem 선택별 환율 유형과 환산차 처리 지정 |
결과 저장 | RptCurrency Dimension의 통화별 멤버로 별도 행 저장 | 같은 행의 그룹 통화 금액 필드에 저장. 환산차는 지정된 FS Item·Subitem으로 전기 |
실행 | Consolidation Monitor 또는 DM Package | Data Monitor의 Currency Translation Task |
BPC 경험자가 GR을 볼 때: Rate Model을 따로 관리하던 방식과 달리, GR의 환율은 원장과 같은 환율 테이블을 공유합니다. 연결 전용 환율이 필요하다면 별도의 환율 유형으로 구분해야 합니다.
GR 경험자가 BPC를 볼 때: BPC의 환산 결과는 통화별 멤버로 저장됩니다. 그룹 통화 금액을 조회할 때는 RptCurrency 멤버를 정확히 지정해야 합니다.
7. 확장성: 분석 축을 어떻게 늘리는가
BPC는 Dimension과 Property를 자유롭게 추가할 수 있습니다. GR은 사전 정의된 추가 특성의 범위 안에서 분석 축을 늘립니다.
비교 항목 | BPC (Standard) | GR (Public Cloud) |
|---|---|---|
분석 축 추가 | 새 Dimension을 만들어 Model에 추가 | 사전 정의된 추가 특성(Profit Center, Segment, Customer Group 등) 중 선택해 활성화 |
분류 속성 | Property를 추가해 보고와 로직에 활용 | 분류는 주로 계층구조로 처리. 속성 확장 범위는 릴리스별로 확인 필요 |
변경 비용 | Dimension 추가 시 기존 Model, Script, 보고서에 미치는 영향 검토 필요 | 활성화 범위 안의 변경은 설정 수준. 범위 밖 요구는 확장 개발 |
값의 원천 | 추가 Dimension 값은 적재 로직에서 매핑 | 통합 법인은 원장(ACDOCA)의 같은 필드에서 연계 |
BPC 경험자가 GR을 볼 때: 요구가 생길 때마다 Dimension을 추가하던 방식은 쓸 수 없습니다. 설계 초기에 추가 특성의 범위와 원장 필드 값을 함께 확정해야 합니다.
GR 경험자가 BPC를 볼 때: BPC 고객별 Dimension 값은 원장에 없는 값일 수 있습니다. 그 값이 어디서 왔는지(적재 매핑인지, 수기 입력인지)를 먼저 확인해야 합니다.
이번 회차 정리
BPC는 컨설턴트가 모델을 설계하고, GR은 SAP가 정의한 모델에 값을 설정합니다.
1:1로 대응되지 않는 Flow, Category, RptCurrency, AuditTrail이 설계 오해가 가장 많이 생기는 구간입니다.
저장 방식(YTD 대 Periodic)은 단절 결산의 가능 여부와 기초 잔액 관리 방식을 결정합니다.
투자 이벤트 이력은 두 엔진 모두 표준 범위 밖에 있습니다.
다음 회차에서는 이 데이터 모델 위에서 실제 연결결산이 어떤 프로세스로 진행되는지 살펴보겠습니다.
참고 자료