[Group Reporting] 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 운영 안정성을 확보하기 위한 실무 중심 확장 아키텍처” 라고 정의할 수 있습니다.