SAP 수출 실적 다차원 분석 — 국가·지역별 매출과 공헌이익을 한 화면에서 쪼개 보고 청구 문서까지 내려가기

개발 배경 — 이 앱을 사용해야 하는 이유

수출 담당자와 관리회계 담당자가 매달 받는 질문은 비슷합니다. 어느 나라에서 얼마를 팔았나, 운임과 보험료, 수수료를 빼고 나면 남는 돈(공헌이익)은 얼마인가, 계획과 얼마나 달랐고 왜 달랐나, 그리고 청구한 돈은 들어왔나. 지금은 이 네 질문의 답이 표준 조회 화면 · 엑셀 피벗 · 물류 자료 · 채권 화면에 흩어져 있어서, 한 번 묻고 답을 맞추는 데 반나절이 갑니다.

이 화면은 청구 문서 라인을 국가 · 지역 · 고객 · 제품 · 인코텀즈 · 통화 단위의 큐브로 한 번 묶어 두고, 같은 큐브에서 축을 끌어다 놓으며 위 네 질문에 답합니다. 숫자는 모두 서비스가 계산하고, 화면과 AI 해설은 그 숫자를 읽기만 합니다. 어느 칸이든 누르면 그 금액을 만든 청구 문서 라인이 열려 “이 숫자 맞아?”를 그 자리에서 확인할 수 있습니다.

국가별 매출은 보이는데, 남는 돈은 한참 뒤에야 알게 된다

청구 문서 조회 화면은 문서 한 건씩 보여 줍니다. 국가 단위 매출은 엑셀로 내려 모아야 하고, 운임 · 보험료 · 수수료는 가격 조건이라는 다른 자리에 있어서 매출과 따로 놓입니다. 그래서 “중국 매출은 컸는데 실제로 남은 건 얼마인가”는 월말에 별도 자료를 만들어야 답이 나옵니다.

이 화면은 매출에서 운임 · 보험료 · 수수료 · 변동원가를 뺀 공헌이익과 공헌이익률을 계산항목으로 서비스에 두고, 표의 행으로 올려 매출 바로 아래에서 읽게 합니다. 순매출과 공헌이익을 단계별로 늘어놓는 단계 보기도 있어 한 지역의 손익 사슬을 위에서 아래로 따라 읽을 수 있습니다.

같은 숫자를 지역 · 고객 · 제품 · 인코텀즈로 바꿔 보려면 리포트를 새로 만든다

지역별 보고서, 고객별 보고서, 인코텀즈별 보고서를 따로 만들면 합계가 서로 어긋나는 일이 생기고, 그때마다 “어느 보고서가 맞나”를 따지는 회의가 열립니다.

이 화면은 차원 칩을 사용 안 함 · 행 · 열 세 칸 사이로 끌어다 놓으면 브라우저가 큐브를 다시 묶습니다. 서버를 다시 부르지 않고, 축이 어떻게 바뀌어도 총합은 큐브 총합과 같습니다. 행은 세 단계, 열은 두 단계까지 쌓을 수 있습니다.

계획 대비 차이는 나는데, 왜 났는지는 회의에서 새로 찾는다

매출이 계획보다 모자랐다는 사실은 표준 리포트도 알려 줍니다. 그런데 물량이 줄었는지, 단가가 내려갔는지, 환율이 움직였는지, 운임이 올랐는지는 엑셀로 다시 분해해야 합니다.

비교 기준을 계획으로 두면 칸마다 실적 · 기준 · 차이 · 증감률이 붙고, 차트는 기준에서 실적까지를 물량 · 믹스 · 외화 단가 · 환율 · 운임보험 · 수수료 · 변동비 · 미계획 막대로 이은 워터폴로 바뀝니다. 요인의 합이 총차이와 같은지는 화면이 매번 검산해서 보여 줍니다. 차이가 난 행에는 사유를 적어 두면 조회 범위와 함께 남아 다음 달에도 따라옵니다.

청구한 돈이 들어왔는지는 다른 화면에서 본다

수출 채권은 청구 시점과 수금 시점이 멀어서, 매출이 좋아 보여도 회수가 늦으면 자금 계획이 틀어집니다. 채권 화면은 고객 단위로 따로 열어야 합니다.

이 화면의 측정값에는 수금액이 들어 있어 회수율(수금액 ÷ 매출)을 매출과 같은 표에서 국가 · 고객 단위로 봅니다. 회수율이 기준보다 낮은 고객은 CFO 앞 대기함으로 올라갑니다.

사용 방법

1. 조회조건 입력 — 회사코드(필수, 기본 1000)와 시작 · 종료 기간(필수, 기본은 데이터가 있는 전 기간)을 정합니다. 계획 버전은 기준 계획 v1 로 고정되어 있고, 저장된 레이아웃은 선택 사항입니다.
2. 조회 버튼 · Enter — 조회 버튼은 조회조건 영역 오른쪽 끝에 있고(초기화 버튼은 그 옆), 입력 필드에서 Enter 키를 눌러도 조회됩니다. 기본 + 자동 조회로 저장한 레이아웃이 있으면 화면을 여는 즉시 조회된 채로 시작합니다.
3. 요약 확인 — 역할별 요약의 지표 카드(매출 · 공헌이익 · 공헌이익률 · 회수율)와 계획 대비 값을 봅니다. 역할 단추(CEO · CFO · 영업 책임자 · 물류 책임자)를 누르면 앞세우는 지표와 쪼개 보는 차원이 바뀌며 서비스를 다시 부르지 않습니다.
4. 탭 · 축 이동 — 레이아웃 보드에서 차원 칩을 행 · 열 · 사용 안 함 사이로 끌어다 놓거나 칩 메뉴로 옮깁니다. 분석 항목과 보기 방식, 표시 행 수를 고르고 차원 필터 단추로 값을 여러 개 골라 범위를 좁힙니다. 차트 위 탭으로 항목 비교와 차이 분해를 오갑니다.
5. 행 · 셀 클릭 상세 — 표의 행을 펼쳐 하위 차원으로 내려가고, 숫자 칸을 누르면 그 금액을 만든 청구 문서 라인이 열립니다. 계획 대비를 켜면 차이가 난 행에 사유 입력 아이콘이 나타납니다.
6. 분석 · 내보내기 — AI 분석으로 요약과 근거 표를 보고 PowerPoint 보고서를 내려받습니다. 상단 CSV 단추로 현재 표를 내려받고, 레이아웃 단추로 현재 배치를 이름 붙여 저장합니다.

자동 조회는 기본 + 자동 조회로 저장한 레이아웃을 열 때만 일어나며, 그 밖에는 조회 버튼을 눌러야 서비스를 부릅니다.

숫자를 믿을 수 있는가 — 검증 결과

리포트에서 가장 비싼 질문은 “이 숫자 맞아?” 입니다. 그래서 만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸습니다. 아래는 이 사례 데이터의 결과이며, 대사식 15종 · 검사 건수 17,618건 모두 차이가 0입니다. 의도적 예외(대사 차이와 분리한 것)는 없습니다. 에이전트가 올리는 점검 필요 보고는 업무 판정이지 대사 차이가 아닙니다.

화면 쪽은 이와 별도로 브라우저 자동화로 돌려 확인했습니다 — 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 드릴스루 합계가 같은지, 요인 합계가 총차이와 같은지를 매번 다시 잽니다. 이 도구는 점검을 돕는 것이며, 최종 판단은 회사와 감사인(세무 신고는 회사와 세무 대리인 · 관세사)이 합니다.

무엇으로 만들었나

앱 정보

실행 화면

실제로 돌아가는 화면 33종을 사용 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리이고 왜 그렇게 두었는지를 아래에 적었습니다. 숫자는 모두 같은 샘플 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다. 거래처 이름과 문서번호는 모두 가상입니다.

처음 열었을 때

조회조건에서 피벗까지가 한 화면에 세로로 쌓입니다. 머리 영역은 접을 수 있어, 축을 짜는 동안에는 펼쳐 두고 숫자를 들여다볼 때는 접어 둡니다.

차원 목록과 측정값은 조회조건과 상관없는 카탈로그라 화면을 열 때 먼저 읽습니다. 그래서 축을 미리 짜 두고 조회할 수 있습니다. 회사코드는 1000, 기간은 2026-01부터 2026-09까지가 기본이며, 조회 버튼은 입력 필드들의 오른쪽 끝에 있고 Enter 키로도 조회합니다.

서비스는 조회조건 필터로 큐브를 한 번만 읽습니다. 표는 지역 아래 국가로 펼쳐지는 트리이고, 오른쪽 차트는 같은 숫자를 막대로 보여 줍니다. 위 지표 카드의 매출 104,646백만원 · 공헌이익 34,493백만원은 표의 전체 합계 행과 같은 값입니다.

세 칸은 사용 안 함 · 행 · 열입니다. 칩을 눌러 나오는 메뉴로도 같은 이동을 할 수 있어 키보드만으로 조작할 수 있습니다. 열에 차원이 올라가면 항목은 첫 번째 것만 열에 펼쳐지고 그 사실을 안내줄로 알려 줍니다.

표와 차트에 화면을 더 쓰고 싶을 때 접습니다. 접어도 조건은 그대로이며, 다시 펼치면 이어서 바꿀 수 있습니다.

경영 요약 — 역할이 바뀌면 앞세우는 숫자가 바뀐다

표 위 역할 단추는 네 가지입니다. 역할을 바꾸면 지표 카드와 쪼개 보는 차원이 함께 바뀌지만 서비스를 다시 부르지 않습니다.

카드의 작은 글씨는 계획값과 달성 비율입니다. 회수율은 계획보다 낮을 때 빨갛게 표시되어 먼저 눈에 들어옵니다. 역할은 보는 관점을 바꾸는 것이지 권한을 나누는 것이 아닙니다.

순매출은 매출에서 운임 · 보험료 · 수수료를 뺀 값입니다. 행 차원이 국가로 바뀌지만 같은 큐브를 다시 묶을 뿐이라 합계는 달라지지 않습니다.

수량은 EA 단위입니다. 고객은 가상 거래처 이름이며 실제 거래처를 쓰지 않았습니다.

물류비율은 (운임 + 보험료) ÷ 매출입니다. 인코텀즈 조건에 따라 운임과 보험료를 누가 내는지가 달라 조건별로 갈라 보는 것이 첫 단계입니다.

축 전환과 범위 — 끌어다 놓고, 골라서 좁힌다

차원 칩을 세 칸(사용 안 함 · 행 · 열) 사이로 끌어다 놓으면 브라우저가 큐브를 다시 묶습니다. 행은 세 단계, 열은 두 단계까지 쌓입니다.

열 조합이 36개를 넘으면 더 올릴 수 없고 안내만 뜹니다. 머리글이 먼저 무너지기 때문입니다. 차트는 열마다 색을 달리한 묶음 막대로 바뀝니다.

큐브에 실제로 있는 값만 올라옵니다. 같은 차원 안에서는 or, 차원끼리는 and 로 걸립니다. 검색칸으로 값을 찾을 수 있고 선택 해제 단추가 있습니다.

선택한 값들의 큐브 합계와 표 합계가 같은지를 자동 검증에 넣었습니다. 선택은 다시 열어 바꾸거나 해제할 수 있습니다.

다시 열면 같은 비율로 시작합니다. 폭이 1000px보다 좁으면 손잡이 대신 차트가 표 아래로 내려갑니다.

칸에서 원천 문서까지

표의 숫자를 누르면 그 금액을 만든 청구 문서 라인이 열립니다. 칸 금액과 문서 라인 합계가 같은지 그 자리에서 보입니다.

조건은 행 경로와 열 조합 그대로입니다. 분기처럼 문서에 없는 파생 차원은 기간 범위로 바꾸어 겁니다. 기본 500줄씩 읽고 더 보기로 이어 읽습니다.

줄별 외화 금액에 가정 환율을 곱하면 원화 매출이 됩니다. 환율은 샘플 데이터용 가정값이며 실제 고시 환율이 아닙니다.

서비스가 원천 라인을 월별로 합산한 값이고 합계 행이 맨 아래에 있습니다. 라인 수 합계는 원천 5,948줄과 같습니다.

계산항목 — 전기되지 않는 단계를 행으로

순매출·공헌이익·공헌이익률은 어느 문서에도 기록되지 않는 값입니다. 서비스가 들고 있는 식을 그대로 풀어 표의 항목으로 올립니다.

계산항목은 분석 항목에서 (계산) 표시가 붙은 것을 고릅니다. 비율 항목은 합계가 아니라 식 그대로 다시 계산되어 지역마다 올바른 비율이 나옵니다.

한 지역의 손익 사슬을 위에서 아래로 따라 읽는 보기입니다. 열에는 지역이 펼쳐지고 차트는 단계별로 묶습니다.

계획 대비 차이 — 같은 표가 월간 실적 점검표가 된다

비교 기준을 켜면 칸마다 실적·기준·차이·증감률이 붙고, 금액과 비율이 둘 다 임계를 넘는 칸만 색이 입혀집니다.

색은 금액 부호가 아니라 이익에 준 영향입니다. 금액 3천만원과 비율 5%를 둘 다 넘을 때만 칠하므로 작은 차이에 눈이 흩어지지 않습니다. 비율 항목은 1퍼센트포인트를 기준으로 합니다.

구분은 환율 · 단가 · 물량 · 물류비 · 고객 사정 · 기타입니다. 키는 조회 범위와 행 경로라서 다음 기간에도 같은 행에 따라옵니다.

요인은 물량 · 믹스 · 외화 단가 · 환율 · 운임보험 · 수수료 · 변동비 · 미계획입니다. 초록은 이익을 늘린 요인, 빨강은 줄인 요인입니다.

전체 범위에서는 요인 합계 −1,641과 총차이 −1,641이 같습니다. 같지 않으면 점검 필요 표시가 나옵니다.

AI 분석과 보고서

지금 보고 있는 범위의 숫자를 읽어 요약과 핵심 발견을 씁니다. 숫자는 서비스가 계산해 넘기고, 해설은 그 숫자를 읽기만 합니다.

분석 방식은 기본이 규칙 기반이며, 모델 연결은 서비스 설정 하나로 켭니다. 이미 사유가 적힌 항목은 건너뛰고 건너뛴 항목을 알려 줍니다.

대상별 매출 · 계획 매출 · 공헌이익 · 계획 공헌이익 · 차이 · 등록된 사유가 들어 있습니다. AI는 이 표에 없는 숫자를 만들지 않습니다.

외부 라이브러리 없이 압축 파일과 XML을 직접 지어 만들며 서버에 파일을 남기지 않습니다. 표지 · 요약 · 표 · 차트 · 워터폴 · 근거 순서입니다.

AI 에이전트 — 규칙에 걸리면 받을 역할 앞으로

감시 규칙마다 기준값과 받을 역할이 붙어 있습니다. 걸린 항목은 그 역할의 눈으로 다시 쓴 보고가 되어 대기함에 올라갑니다.

다섯 가지 규칙은 공헌이익률 하락 · 국가별 매출 계획 미달 · 환율 영향 임계 · 장기 미회수 · 운임보험 비율 상한 초과입니다. 기준값은 화면에서 바꿀 수 있습니다.

물류 책임자에게는 운임보험 비율이, CFO에게는 회수율이 올라갑니다. 역할 선택으로 대기함을 좁혀 볼 수 있고, 오늘 이미 실행했으면 하루 1회 안내가 뜹니다.

걸린 것이 없어도 기록은 남습니다. 두 번째 실행은 하루 1회 제한으로 건너뜀 처리되며, 이 판단은 화면이 아니라 서비스가 합니다.

레이아웃 저장과 복원

짜 둔 축과 조회조건을 이름 붙여 저장하고, 기본 레이아웃과 자동 조회를 지정하면 다음에 열 때 조회된 채로 시작합니다.

저장 내용은 축 · 조회조건 · 분석 항목 · 표시 행 수 · 접힘 상태입니다. 창 아래에 저장될 내용 요약이 보입니다.

기본 레이아웃은 하나만 둘 수 있습니다. 삭제는 확인을 한 번 더 묻습니다.

새로 고친 뒤에도 같은 배치와 선택값으로 시작하는지를 자동 검증에 넣었습니다.

좁은 화면과 한계

휴대폰 폭에서는 차트가 표 아래로 내려갑니다. 행과 열 조합이 상한을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 나옵니다.

손잡이는 숨겨지고 표는 가로로 스크롤됩니다. 조회조건은 접어서 숫자 영역을 먼저 보게 했습니다.

고객 · 품목 · 기간을 모두 행에 올리면 855개가 되어 이 안내가 나옵니다. 반쯤 그린 표로 오해하는 일을 막기 위해서입니다.

추가하려는 순간 막고 이유를 알려 줍니다. 열 축은 곱으로 늘어나므로 두 단계까지로 제한했습니다.

화면 뒤에서 일어나는 일

화면에 보이는 숫자는 아래 순서로 만들어집니다. 모든 식은 서비스가 계산하고 화면은 그대로 보여 줄 뿐입니다. 검증 결과는 “숫자를 믿을 수 있는가” 절에 있습니다.

판정 조건 · 결과 상태 · 사용자 조치

화면은 판정을 단정하지 않고 점검 필요 · 확인 필요로 표시합니다. 임계값은 샘플 기준이며 고객사 기준으로 바꾸는 자리는 운영 단계에서 정합니다.

조회조건

필수 조건을 비우면 조회하지 않고 안내합니다. 시작 기간이 종료 기간보다 늦으면 조회 전에 안내합니다.

결과 컬럼

좁은 화면에서 달라지는 것

폭이 1000px보다 좁아지면 표와 차트 사이 손잡이가 사라지고 차트가 표 아래로 내려갑니다. 조회조건은 접어서 숫자 영역을 먼저 보게 하고, 표는 가로로 스크롤됩니다. 행이 500개를 넘거나 열 조합이 36개를 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 나옵니다. 화면 폭을 줄여도 기능이 빠지지 않는 것이 원칙이고, 휴대폰에서 긴 표를 훑는 일은 CSV로 내려받아 보는 것이 낫습니다.

파일 구성

앱 폴더
├─ index.html · Component.js · manifest.json     진입 · 컴포넌트 · 앱 선언
├─ view/
│   ├─ Main.view.xml                              조회조건 · 요약 · 레이아웃 보드 · 표 · 차트
│   └─ fragments/                                 값 선택 · 원천 문서 · 사유 · AI · 에이전트 · 레이아웃 창
├─ controller/                                    화면 동작(BaseController · Main.controller)
├─ model/
│   ├─ cube.js        큐브를 행·열 축으로 다시 묶는 피벗
│   ├─ chart.js       직접 그린 SVG 차트(막대 · 워터폴)
│   ├─ pptx.js        PowerPoint 보고서 생성
│   ├─ layout.js · formatter.js · ErrorHandler.js
├─ css/ · i18n/                                   스타일 · 문구
└─ media/ · readme.html                           소개 영상 · 앱 설명서

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 법정 · 감사 · 신고 대응은 표준 화면과 절차를 그대로 따릅니다.

표준으로 되는 것과 안 되는 것

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 없애지 않습니다. 표준 거래와 법정 · 감사 · 세무 신고 대응용 출력은 그대로 두고, 이 화면은 월별 실적 점검과 원인 추적, 회의 자료를 만드는 자리에 얹습니다. 운영 전환 직후 몇 달은 두 화면 숫자를 같은 기준으로 맞춰 보는 대사 기간으로 두는 것을 권합니다.

S/4HANA 분석 스택과의 자리

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이미 잘 정리된 표준 분석으로 충분한 질문은 그쪽을 쓰시면 됩니다. 이 화면은 그 사이에서 수출 실적을 국가 · 지역 · 인코텀즈 축으로 자유롭게 바꿔 보고, 칸에서 원천 문서까지 내려가고, 계획 대비 차이를 요인으로 가르는 한 가지 시나리오를 한 화면으로 묶은 것입니다. 표준 분석 쿼리가 있다면 이 화면의 큐브 뷰가 그 쿼리를 읽도록 바꾸는 것도 가능하며, 어떤 표준 뷰가 이미 같은 정의를 갖고 있는지는 시스템에서 확인해야 합니다(확인 필요).

확장 포인트 — 운영에서 실제로 손대는 자리

분석 지표 정의

CDS 구성

아래 CDS 뷰는 운영 연결을 위한 스케치입니다. 샘플 서비스가 하는 일을 S/4HANA 의 CDS 뷰 · 분석 쿼리 · 접근 제어 · 서비스 정의로 옮길 때 어떻게 나누는지를 보여 주며, 실제 원천 매핑은 도입 시 확정합니다.

원천 테이블

필드 매핑

뷰 레이어 구성

① 국가 → 지역 매핑 테이블 (기준)

회사마다 지역을 묶는 방식이 다르므로 코드가 아니라 테이블에 둡니다. 이 한 곳을 고치면 큐브 전체에 반영되고, 운영 단계에서 고객사가 직접 정합니다.

" ─────────────────────────────────────────────
" zexp_regmap : 국가 → 지역 매핑 (기준 테이블)
" 역할  : 국가 코드를 수출 분석용 지역으로 묶는다.
" 나눈 이유 : 지역 분류는 회사가 정하는 값이라 뷰 코드에 넣으면
"            분류가 바뀔 때마다 전송이 필요해진다.
" ─────────────────────────────────────────────
@EndUserText.label : '국가 지역 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexp_regmap {
  key mandt   : mandt not null;
  key land1   : land1 not null;
  region      : abap.char(2) not null;
  region_text : abap.char(20);
}

② 청구 품목 기본 뷰 ZI_ExpBilling

청구 문서 헤더 · 품목 · 고객 마스터를 조인하고 외화 금액에 환율을 곱해 원화 금액을 만듭니다. 이 뷰 한 곳에서만 조인과 환산을 하므로 위의 큐브들이 같은 정의를 씁니다.

" ─────────────────────────────────────────────
" ZI_ExpBilling : 청구 품목 기본 뷰
" 역할  : 청구 헤더(vbrk) · 품목(vbrp) · 고객(kna1) · 지역 매핑을 한 줄로 펼친다.
" 나눈 이유 : 조인과 통화 환산을 한 곳에 모아 큐브와 계획이 같은 정의를 쓰게 한다.
" ─────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수출 청구 품목'
@ObjectModel.usageType.sizeCategory : #XL
define view entity ZI_ExpBilling
  as select from vbrk as h
    inner join vbrp as i on i.vbeln = h.vbeln
    inner join kna1 as c on c.kunnr = h.kunag
    left outer join zexp_regmap as m on m.land1 = c.land1
{
  key h.vbeln                              as BillingDocument,
  key i.posnr                              as BillingItem,
      h.fkdat                              as BillingDate,
      h.vkorg                              as SalesOrganization,
      h.kunag                              as Customer,
      c.land1                              as Country,
      m.region                             as Region,
      i.matnr                              as Product,
      i.matkl                              as ProductGroup,
      i.spart                              as Division,
      h.inco1                              as Incoterms,
      h.waerk                              as TransactionCurrency,
      @Semantics.quantity.unitOfMeasure : 'BaseUnit'
      i.fkimg                              as BillingQuantity,
      i.vrkme                              as BaseUnit,
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      i.netwr                              as NetAmountFc,
      h.kurrf                              as ExchangeRate,
      cast( i.netwr * h.kurrf as abap.curr( 15, 2 ) ) as NetAmountKrw,
      @Semantics.amount.currencyCode : 'CompanyCurrency'
      i.wavwr                              as CostAmount,
      h.bukrs                              as CompanyCode
}

③ 실적 큐브 ZI_ExpCountryCube

기본 뷰를 기간 · 고객 · 제품 · 인코텀즈 단위로 더합니다. 화면의 큐브 한 행에 해당하며, 측정값은 합계로 집계되도록 선언합니다. 환산과 가격 조건 합산은 기본 뷰가 끝낸 값을 그대로 읽습니다.

" ─────────────────────────────────────────────
" ZI_ExpCountryCube : 수출 실적 큐브
" 역할  : 청구 품목을 분석 차원 조합별로 더한다. 화면의 큐브 조회가 읽는 단위.
" 나눈 이유 : 축을 바꿔도 같은 집계를 쓰게 하고, 드릴스루는 기본 뷰로 내려간다.
" ─────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수출 실적 큐브'
define view entity ZI_ExpCountryCube
  as select from ZI_ExpBilling
{
  key CompanyCode,
  key cast( substring( cast( BillingDate as abap.char(8) ), 1, 6 ) as abap.char(6) ) as FiscalPeriod,
  key Customer,
  key Product,
  key Incoterms,
      Region,
      Country,
      ProductGroup,
      Division,
      SalesOrganization,
      TransactionCurrency,
      @Aggregation.default : #SUM
      sum( BillingQuantity )  as Quantity,
      @Aggregation.default : #SUM
      sum( NetAmountFc )      as SalesFc,
      @Aggregation.default : #SUM
      sum( NetAmountKrw )     as SalesKrw,
      @Aggregation.default : #SUM
      sum( CostAmount )       as VariableCost
}
group by CompanyCode, BillingDate, Customer, Product, Incoterms,
         Region, Country, ProductGroup, Division, SalesOrganization, TransactionCurrency

④ 계획 큐브 ZI_ExpPlanCube

계획 값을 실적 큐브와 같은 키로 맞춥니다. 키가 같아야 계획 대비 차이를 한 줄로 맞붙일 수 있습니다. 계획의 원천(판매 계획 · 수익성 계획 등)은 도입 시 확정이 필요한 항목입니다.

" ─────────────────────────────────────────────
" ZI_ExpPlanCube : 수출 계획 큐브 (원천은 도입 시 확정 필요)
" 역할  : 계획 값을 실적 큐브와 같은 차원 조합으로 맞춘다.
" 나눈 이유 : 같은 키여야 계획 대비 차이를 서비스에서 한 번에 맞붙일 수 있다.
" ─────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수출 계획 큐브'
define view entity ZI_ExpPlanCube
  as select from zexp_plan
{
  key bukrs     as CompanyCode,
  key version   as PlanVersion,
  key period    as FiscalPeriod,
  key kunnr     as Customer,
  key matnr     as Product,
  key inco1     as Incoterms,
      region    as Region,
      land1     as Country,
      @Aggregation.default : #SUM
      qty       as Quantity,
      @Aggregation.default : #SUM
      sales_fc  as SalesFc,
      @Aggregation.default : #SUM
      sales_krw as SalesKrw,
      @Aggregation.default : #SUM
      var_cost  as VariableCost
}

⑤ 분석 쿼리 ZC_ExpCountryQuery

큐브를 화면이 읽는 이름으로 노출하고 조회 필터를 선언합니다. 공헌이익처럼 문서에 없는 값은 계산 측정값으로 정의합니다.

" ─────────────────────────────────────────────
" ZC_ExpCountryQuery : 수출 실적 분석 쿼리
" 역할  : 화면이 읽을 이름 · 필터 · 계산 측정값을 한 곳에서 선언한다.
" 나눈 이유 : 조회조건과 계산식을 서비스 쪽에 두어 화면이 숫자를 만들지 않게 한다.
" ─────────────────────────────────────────────
@Analytics.query : true
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수출 실적 분석'
define view entity ZC_ExpCountryQuery
  as select from ZI_ExpCountryCube
{
  @Consumption.filter : { mandatory : true, selectionType : #SINGLE }
  key CompanyCode,
  @Consumption.filter : { mandatory : true, selectionType : #INTERVAL }
  @AnalyticsDetails.query.axis : #ROWS
  key FiscalPeriod,
  @AnalyticsDetails.query.axis : #ROWS
  Region,
  @AnalyticsDetails.query.axis : #ROWS
  Country,
  @Consumption.filter.selectionType : #MULTIPLE_ELEMENTS
  Customer,
  Product,
  Incoterms,
  @AnalyticsDetails.query.axis : #COLUMNS
  SalesKrw,
  @AnalyticsDetails.query.axis : #COLUMNS
  VariableCost
}

⑥ 접근 제어 ZR_ExpCountryCube

영업조직 단위로 조회 권한을 겁니다. 권한이 없는 영업조직의 행은 서비스에서 읽히지 않으므로 화면이 걸러 줄 필요가 없습니다.

" ─────────────────────────────────────────────
" ZR_ExpCountryCube : 영업조직 접근 제어 (DCL)
" 역할  : 조회 권한이 있는 영업조직의 행만 읽히게 한다.
" 나눈 이유 : 권한을 화면이 아니라 데이터 계층에서 걸어야 우회할 수 없다.
" ─────────────────────────────────────────────
@EndUserText.label : '수출 실적 큐브 접근 제어'
@MappingRole : true
define role ZR_ExpCountryCube {
  grant select on ZI_ExpCountryCube
    where ( SalesOrganization ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

⑦ 서비스 정의 ZUI_ExpCountry

분석 쿼리를 OData 서비스로 노출합니다. 이 서비스를 활성화한 뒤 앱의 서비스 선언 주소만 바꾸면 운영 데이터로 연결됩니다.

" ─────────────────────────────────────────────
" ZUI_ExpCountry : 서비스 정의
" 역할  : 분석 쿼리를 OData 서비스로 노출한다.
" 나눈 이유 : 화면은 서비스 선언 한 곳만 바라보므로 주소만 바꾸면 운영으로 연결된다.
" ─────────────────────────────────────────────
@EndUserText.label : '수출 실적 분석 서비스'
define service ZUI_ExpCountry {
  expose ZC_ExpCountryQuery as ExpCountry;
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 항목은 코딩이 아니라 합의이며, 합의가 끝나면 기술 작업은 뷰를 만들고 서비스를 게시한 뒤 앱 선언 파일의 서비스 주소를 바꾸는 일로 줄어듭니다.

운영 데이터로 갈 때

청구 문서 라인이 수천만 건이 되면 지금처럼 큐브 전체를 브라우저로 내려 묶는 구조는 맞지 않습니다. 첫째, 집계는 데이터베이스 안에서 합니다(큐브 뷰의 group by 와 분석 쿼리). 둘째, 조회 기간과 회사코드를 필수 파라미터로 두어 읽는 범위를 제한합니다. 셋째, 청구일 · 영업조직 · 고객 같은 필터 열에 맞는 인덱스나 칼럼 저장소 특성을 확인합니다. 넷째, 드릴스루는 칸 하나에 해당하는 원천 줄만 페이징해서 읽습니다. 응답 시간 기준은 사용자가 기다릴 수 있는 수준(예: 조회 몇 초, 드릴스루 1~2초)을 먼저 합의하고 그에 맞춰 집계 위치를 정합니다. 화면은 행 500개 · 열 조합 36개 상한을 두어 범위가 넓어질 때 먼저 안내하도록 해 두었습니다.

자주 묻는 질문

도입을 검토하실 때 자주 나오는 질문을 네 묶음으로 정리했습니다. 답변의 숫자는 모두 이 글의 샘플 자료 기준입니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영