Non-SAP 법인 재무제표 취합을 위한 Group Reporting 애드온
머리말
지난 포스팅 “국내 연결결산 현실을 고려한 SAP Group Reporting 확장 접근”에 이어지는 첫번째 후속 포스트로 “Non-SAP 법인의 시산표 업로드” 기능을 설명 드리겠습니다.
SAP S/4HANA Group Reporting에서는 표준으로 Flexible Upload 기능을 제공합니다. 하지만 실제 프로젝트를 수행해 보면 한 가지 현실적인 제약이 있습니다. 표준 Flexible Upload 앱은 재무제표항목(FS Item) 기준으로 집계된 데이터를 업로드해야 합니다.
로컬 G/L 단위 데이터 업로드 불가
법인 내부에서 사전 집계 필요
계정 매핑 로직을 법인 측에서 수행해야 함
검증 및 오류 통제 기능 제한적
Non-SAP 법인이 다양한 ERP나 엑셀 기반으로 운영되는 환경에서는 이 요구사항이 상당한 부담이 됩니다. 바로 이 지점에서, Z Staging 기반의 통제형 인터페이스 설계가 필요합니다.
1. 왜 별도의 인터페이스가 필요한가?
표준 Flexible Upload는 “결과값 업로드”에 가깝습니다. 이미 그룹 기준으로 정제된 재무제표항목 집계 데이터가 준비되어 있어야 합니다.
그러나 현실은 다음과 같습니다.
법인별 G/L 체계 상이
연결 계정 매핑 미완료
집계 기준 불일치
오류 데이터 반복 발생
따라서 필요한 것은 단순 업로드 기능이 아니라, “로컬 G/L 데이터를 그룹 기준으로 변환·검증·통제하는 중간 레이어” 입니다.
2. 전체 설계 개요
① Non-SAP 법인
로컬 ERP 또는 엑셀 기반 시산표 생성 (G/L 단위)
② RAP 인터페이스 (Z Staging)
G/L 계정 매핑 적용
데이터 1차 적재
상태값 관리
사전 검증 수행
③ 검증 완료 데이터
재무제표항목 기준 자동 변환
집계 수행
④ Group Reporting 표준 API 전송
표준 문서 생성
SAP 표준 Validation 수행
즉, 로컬 G/L → Z Staging → FS Item 변환 → 표준 API 전송의 흐름입니다.
3. G/L 계정 매핑 관리 기능
Flexible Upload는 FS Item 기준 업로드를 요구하지만, 현실의 데이터는 G/L 기준입니다. 이를 해결하기 위해 다음 구조를 설계했습니다.
로컬 G/L ↔ 연결 계정 매핑
연결 계정 ↔ FS Item 연계
엑셀 기반 매핑 관리
매핑 누락 계정 자동 점검
이 단계에서 이미 그룹 기준으로 변환이 준비됩니다.
[재무제표 항목과 Non-SAP G/L 계정 매핑] 앱을 클릭하고 템플릿을 받은 후 G/L계정과 재무제표 항목을 매핑하고 [임포트]합니다.
4. Z Staging 1차 적재 구조
업로드한 시산표는 바로 연결 원장으로 가지 않고, 먼저 Z 테이블에 저장됩니다.
이러한 Z Staging 구조의 목적은 다음과 같습니다.
✔ 업로드 이력 관리
✔ 사용자별 책임 추적
✔ 오류 데이터 격리
✔ 재처리 통제
상태값 예시:
Uploaded
Error
Validated
Sent
이 구조는 연결결산 운영 통제 측면에서 매우 중요한 설계 요소입니다.
5. 사전 검증 프로세스
Z 영역에서 다음 검증이 수행됩니다.
① 잔액 검증
차대 합계 일치 여부
통화 합계 점검
② 계정 매핑 검증
미매핑 계정 탐지
허용되지 않은 계정 사용 여부
③ 필수 차원 검증
회사코드
기간
기타 필수 연결 차원
오류 발생 시:
오류 메시지 저장
상태값 Error 전환
수정 후 재검증 가능
이 구조가 없는 경우, 오류 데이터가 그대로 연결 원장으로 유입될 수 있습니다.
6. FS Item 기준 자동 변환 및 집계
검증이 완료된 데이터는
매핑 테이블 참조
FS Item 기준 변환
필요 시 집계 수행
과정을 거쳐 Flexible Upload가 요구하는 데이터 구조를 충족합니다.
즉, 법인에서 집계하지 않아도, 인터페이스에서 그룹 기준 집계가 수행됩니다.
7. 표준 API 전송
최종 단계에서 Group Reporting 표준 API를 호출합니다.
이 방식의 특징은 다음과 같습니다.
✔ 표준 전표 생성 로직 사용
✔ SAP 표준 Validation 수행
✔ OP / Public 동일 구조 유지
8. RAP 기반 구현의 의미
본 인터페이스는 ABAP RESTful Application Programming Model 기반으로 개발되었습니다.
이를 통해 다음 장점이 확보됩니다.
Public Cloud 대응 가능
OData 기반 확장 용이
Fiori 모니터링 UI 제공
향후 API 자동 연계 확장 가능
즉, 단순 업로드 프로그램이 아니라 확장 가능한 연결 플랫폼 컴포넌트입니다.
9. 전략적 의미
이 설계는 단순 기능 구현을 넘어 다음과 같은 확장 가능성을 갖습니다.
1️⃣ Flexible Upload의 구조적 한계 보완
FS Item 집계 부담을 인터페이스에서 흡수
2️⃣ 내부통제 강화
사전 검증 및 상태 관리 체계 확보
3️⃣ 클라우드 전환 대응
OP → Public 전환 시 재개발 최소화
4️⃣ M&A 대응력 확보
ERP 변경 없이 연결 편입 가능
결론
표준 Flexible Upload는 강력하지만 “이미 정제된 FS Item 데이터”를 전제로 합니다. 하지만, 현실의 Non-SAP 환경에서는 그 전 단계의 통제·변환·검증 구조가 반드시 필요합니다.
이번에 적용한 Z Staging + RAP + 표준 API 구조는 다음의 특징을 갖습니다.
로컬 G/L 기준 업로드 허용
자동 FS Item 변환
사전 검증 내장
상태 및 재처리 통제
OP / Public 공통 대응
이라는 특징을 갖습니다.
이는 단순 인터페이스가 아니라, “Group Reporting 운영 안정성을 확보하기 위한 실무 중심 확장 아키텍처” 라고 정의할 수 있습니다.