수출 운송·보험 포함 매출 수익 분리 다차원 분석 — 제품 수익과 운송·보험 용역분, 월말 이연까지 한 화면에서 나누는 월마감

도입 포인트 — 이 앱을 사용해야 하는 이유

수출 담당과 회계 담당이 월말마다 마주치는 질문은 비슷합니다. CIF · CFR · CIP 조건으로 나간 청구서에서 운송 · 보험료 몫을 뺀 제품 수익은 얼마인가, 그리고 그 운송 · 보험 용역분 가운데 이번 달에 인식할 몫과 월말에 넘길 몫은 얼마인가입니다. 표준 화면으로는 판매 오더(VA03), 청구 문서(VF03), 납품(VL03N), 고객 개별 항목(FBL5N), 수익성 분석(KE30)을 번갈아 열어 엑셀에서 붙이게 되고, 그 사이에 숫자가 서로 달라지는 일이 생깁니다.

이 화면은 청구 라인을 제품 그룹 · 운송수단 · 고객 · 수출 국가 · 인코텀즈 등 차원 조합별 큐브로 묶고, 청구 총액 · 운송 · 보험 용역분 · 제품 수익 · 당월 인식분 · 월말 이연분을 같은 기준으로 보여 줍니다. 한 청구서 안에 제품과 운송 · 보험 용역이 함께 있을 때 이를 구분해 보는 관점은 IFRS 15 고객과의 계약에서 생기는 수익(K-IFRS 제1115호)의 수행의무 구분과 이행 시점 요구사항과 맞닿아 있으며, 화면은 그 집계와 점검을 돕는 도구입니다. 어느 몫을 언제 인식할지는 회사의 계약 조건과 회계정책에 달려 있으므로 최종 판단은 회사와 감사인이 합니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터(청구 라인 1,939줄, 큐브 324행, 2026년 1~9월)에서 청구 총액은 36,380백만원이고 그 가운데 운송 · 보험 용역분이 2,126백만원(용역 포함률 5.8%, 계획 5.5%)이어서 제품 수익은 34,254백만원으로 나뉩니다. 용역분은 당월 인식분 1,778백만원과 월말 이연분 348백만원으로 다시 갈립니다.

제품 수익은 연초 계획 33,392백만원보다 862백만원 많았습니다. 여섯 요인으로 나누면 매출 물량 +809가 가장 크고 미계획 거래 +679와 환율 +325가 뒤를 이으며, 계획 미이행 −698 · 외화 단가 −137 · 용역 포함률 −116이 일부를 깎았습니다. 여섯 요인의 합은 총차이 862와 오차 0으로 맞아 어디를 먼저 점검할지가 순서대로 보입니다. 큐브와 원천 라인의 대사식 20건을 전수로 돌려 차이는 0건이었습니다.

도입하면 달라지는 것

• 마감 전 점검 — 제품 수익 · 용역분 · 이연분 · 계획 차이와 요인 분해, 사유, 보고서가 한 화면에서 나와 엑셀 취합이 줄어듭니다.
• 회의의 주제 — ‘어느 숫자가 맞나’가 아니라 ‘어느 고객의 이연분을 먼저 확인할까’를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치지 않는 점검 — 운송 30일을 넘는 라인의 월말 이연분처럼 규칙에 걸린 항목이 대기함에 올라옵니다.

이런 회사에 맞습니다

CIF · CFR · CIP 처럼 운임이나 보험료가 청구 금액에 들어가는 조건으로 여러 통화 · 여러 국가에 수출하는 제조 · 유통 기업, 그리고 영업 · 물류 · 회계 부서가 같은 숫자를 서로 다른 화면에서 맞추고 있는 조직에 맞습니다. 항공과 해상처럼 운송 기간이 다른 운송수단이 섞여 있고 월말에 걸치는 선적이 많을수록 효과가 커집니다.

실행 화면

아래 화면은 검증용 샘플 데이터(가상 고객 · 가정 환율과 용역 포함률)로 실제 브라우저에서 찍은 것입니다. 금액 단위는 백만원이고, 화면 이름은 사용 순서대로 정리했습니다.

사용 방법

1. 조회조건 입력 — 회사코드(필수), 시작 · 종료 기간(필수, 기본 2026-01~2026-09)을 확인합니다. 저장해 둔 레이아웃이 있으면 고릅니다.
2. 조회 — 조회 버튼을 누르거나 입력 칸에서 Enter 를 누릅니다. 기본 레이아웃에 자동 조회를 지정했다면 화면을 열 때 이미 조회되어 있습니다.
3. 요약 확인 — 역할별 요약 탭(CEO · CFO · 영업 책임자 · 물류 책임자)에서 숫자 카드를 읽습니다.
4. 탭 · 축 이동 — 차원 칩을 행과 열로 옮기고 필터로 범위를 좁힙니다. 이 단계는 서버를 다시 부르지 않습니다.
5. 행 · 셀 클릭 상세 — 행을 누르면 차이 분해 차트가, 칸을 누르면 원천 청구 라인이 열립니다. 차이가 있는 행에는 사유를 남깁니다.
6. 내보내기 — 상단의 CSV 는 현재 표를, AI 분석 창의 보고서 버튼은 PowerPoint 보고서를 내려받습니다.

무엇으로 만들었나

1. 처음 열었을 때 — 조건 · 보드 · 피벗 틀

화면을 열면 조회 조건, 차원 칩을 놓는 레이아웃 보드, 피벗 틀이 한 화면에 보입니다. 조회 버튼을 누르면 같은 화면에서 표와 차트가 채워집니다.

회사코드 1000과 기간 2026-01~2026-09, 비교 기준(연초 확정 판매 계획)이 미리 채워져 있습니다. 차원 칩은 ‘사용 안 함’ · ‘행’ · ‘열’ 세 칸 가운데 어디에 놓였는지로 표의 모양을 정합니다. 조회 버튼은 조회 조건 영역 오른쪽 끝에 있고 입력 칸에서 Enter 를 눌러도 같습니다.

제품 수익 34,254백만원, 청구 총액 36,380, 운송 · 보험 용역분 2,126, 용역 포함률 5.8%가 기준과 함께 보입니다. 기본 배치는 제품 그룹과 운송수단이 행이고 열은 비어 있습니다. 표의 행을 펼치면 하위 차원으로 내려가고 오른쪽 차트는 같은 값을 막대로 보여 줍니다.

2. 경영 요약 — 역할마다 앞세우는 숫자가 다릅니다

역할별 요약 탭을 바꾸면 카드에 올라오는 지표와 표에서 쪼개 보는 차원이 함께 바뀝니다. 같은 큐브를 읽을 뿐이라 탭을 바꿔도 합계는 변하지 않습니다.

CFO 탭은 제품 수익, 당월 인식분, 월말 이연분처럼 마감과 직결된 지표를 먼저 보여 줍니다. 카드 아래 작은 글씨는 기준값과 대비 증감입니다. 숫자는 모두 서비스가 계산한 값이며 화면에서 다시 계산하지 않습니다.

영업 책임자 탭은 고객과 국가 단위의 용역 포함률과 계획 대비 증감을 앞세웁니다. 용역 포함률이 계획보다 높은 고객이 어디인지 바로 읽을 수 있습니다.

물류 책임자 탭은 항공과 해상처럼 운송수단별 용역분과 월말 이연분을 보여 줍니다. 해상 운송의 이연분이 훨씬 크다는 점이 한눈에 보이며, 이 차이가 이연 점검의 출발점입니다.

3. 축 전환과 범위 — 다시 조회하지 않고 다르게 묶기

차원 칩을 끌어 다른 칸에 놓거나 칩을 눌러 메뉴로 옮기면 표가 바로 다시 묶입니다. 조회 때 큐브를 한 번 읽어 두었기 때문에 서버 요청은 0건입니다.

고객 차원을 열로 옮기면 열마다 고객이 나타납니다. 이때 서버 요청은 0건이고 합계는 그대로입니다. 열에 올린 차원이 있으면 분석 항목 가운데 첫 항목만 열에 펼쳐 보이며, 이 사실은 표 위 안내 줄에 표시됩니다.

청구월을 행에 추가하면 제품 그룹 › 운송수단 › 청구월 순으로 내려갑니다. 행은 최대 3단계까지 놓을 수 있고 넘기려 하면 안내 메시지가 뜹니다.

단계 보기는 차원 대신 계산 흐름을 행으로 놓습니다. 청구 총액에서 운송 · 보험 용역분, 제품 수익, 당월 인식분, 월말 이연분, 당월 인식률까지 위에서 아래로 따라가며 제품 그룹별로 비교합니다.

차원마다 필터 버튼이 있어 값 목록에서 여러 개를 고를 수 있습니다. 같은 차원 안에서는 or, 차원 사이에서는 and 로 묶이며 큐브에 있는 값만 목록에 나옵니다.

필터를 적용하면 표 · 요약 카드 · 차트가 모두 같은 범위로 다시 계산됩니다. 머리 영역을 접으면 현재 범위가 한 줄 요약으로 남습니다.

열은 최대 2단계이고 조합이 36개를 넘으면 표를 그리지 않고 줄이라는 안내가 나옵니다. 인코텀즈 조건별로 같은 제품 그룹의 제품 수익이 어떻게 갈리는지 비교할 때 씁니다.

4. 칸에서 청구 라인까지 — 숫자의 근거 확인

표의 칸을 누르면 그 금액을 만든 원천 청구 라인이 열립니다. 숫자를 믿는 근거를 같은 화면에서 확인하는 자리입니다.

머리 줄에 ‘셀 값 36,380 = 원천 합계 36,380(원천 1,939줄) 일치’가 표시됩니다. 두 값이 다르면 점검 필요로 바뀝니다. 라인에는 청구 문서 · 청구일 · 도착 예정일 · 운송 일수 · 용역 인식 상태 · 계약 번호 · 운송수단 · 고객 · 인코텀즈가 있고 500줄씩 더 불러옵니다.

5. 기준 대비 차이 — 같은 표가 점검 회의 자료가 됩니다

기준 대비를 켜면 칸마다 실적 아래에 기준값 · 차이 · 증감률이 붙고, 요인 분해와 검산 줄이 함께 나옵니다.

제품 수익 34,254는 기준 33,392보다 862(+2.6%) 많습니다. 차이가 금액과 비율 임계를 모두 넘는 칸은 색으로 구분합니다. 오른쪽 아래 안내 줄에는 ‘요인 합계 862 / 총차이 862(오차 0.00)’가 표시됩니다.

표에서 행을 누르면 그 행의 차이만 분해됩니다. 선택한 행은 표에서 강조되고 차트 위에 이름이 칩으로 나타나며 X 로 해제합니다.

디스플레이 모듈 10,576 → 10,643(+68)을 매출 물량 +327 · 외화 단가 −76 · 환율 +115 · 용역 포함률 −27 · 미계획 거래 0 · 계획 미이행 −271로 나눈 모습입니다. 초록은 늘리는 요인, 빨강은 줄이는 요인이며 여섯 요인의 합이 총차이와 같습니다.

6. 변동 사유 — 설명이 행에 남습니다

차이가 큰 행에는 사유 버튼이 나타나고, 저장한 사유는 행 경로에 묶여 다음 조회에서도 따라옵니다.

사유 구분(매출 물량 변경 · 환율 · 기타 등)을 고르고 내용을 적습니다. 창에는 해당 행의 이름 · 기간 · 차이 금액이 함께 보여 어느 숫자에 대한 설명인지 헷갈리지 않습니다.

저장하면 행의 사유 버튼이 초록 표시로 바뀌고 같은 행을 누르면 내용을 고치거나 지울 수 있습니다. 사유는 서비스에 쓰기로 남으므로 화면을 닫아도 유지됩니다.

7. AI 분석과 보고서 — 숫자는 서비스가, 설명은 AI 가

AI 분석은 현재 범위의 요약과 주요 발견을 보여 줍니다. 모든 숫자는 서비스가 계산한 값이고 AI 는 읽기만 합니다.

요약에는 제품 수익 · 계획 · 총차이 · 용역 포함률 · 인식분과 이연분이 한 문단으로 나옵니다. 주요 발견은 계획 차이가 큰 제품 그룹부터 나열하고, 원인은 단정하지 않고 ‘확인 필요’ 항목으로만 제시합니다. 기본은 규칙 기반이며 모델 연결은 서비스 설정으로 켭니다.

창 아래 보고서 버튼을 누르면 브라우저에서 PowerPoint 를 만들어 내려받습니다. 보고서에는 요약 · 조회 결과 표 · 차트 · 워터폴 · 해설에 쓴 근거 표가 들어가며 생성한 6장 구성을 열어 확인했습니다.

8. AI 에이전트 — 사람이 열지 않아도 도는 점검

감시 규칙을 정해 두면 규칙에 걸린 항목이 받을 역할별 대기함으로 올라갑니다. 하루 한 번 제한과 실행 기록은 서비스가 맡습니다.

제품 수익 계획 차이 금액 초과(CEO), 용역 포함률 상한(CFO), 월말 이연 용역분 임계 초과와 운송 30일 초과 라인의 이연분 초과(물류 책임자), 용역 포함률 요인 손실 금액 초과(영업 책임자)가 기본 규칙입니다. 기준값은 화면에서 고칠 수 있습니다.

샘플 데이터에서 규칙 5개 가운데 15건이 걸려 대기함에 올라갔습니다. 보고마다 걸린 규칙 · 받는 역할 · 근거 금액이 있고 문장은 ‘확인 필요’ ‘점검 필요’로 끝납니다.

같은 날 다시 실행하면 서비스가 ‘하루 한 번만 실행합니다’라며 건너뛰고 그 사실도 실행 기록에 남깁니다. 화면을 여러 사람이 열어도 보고가 중복되지 않습니다.

9. 기간별 요약

청구월 단위로 큐브 합계를 한 표에 모아 보는 자리입니다.

월마다 라인 수 · 청구 총액 · 제품 수익 · 계획 · 차이 · 용역분 · 월말 이연분 · 당월 인식 수익 · 용역 포함률이 나옵니다. 합계 행의 제품 수익 34,254와 계획 33,392, 차이 862는 피벗 화면의 숫자와 같습니다.

10. 레이아웃 저장과 복원 — 매달 같은 배치를 다시 만들지 않습니다

자주 쓰는 행 · 열 배치와 분석 항목을 이름 붙여 저장하고, 기본 레이아웃과 자동 조회를 지정할 수 있습니다.

저장 대화상자 아래에 저장될 내용(행 · 열 · 기간 · 항목 수)이 미리 보입니다. 기본 레이아웃으로 지정하면 ‘열 때 자동 조회’ 선택이 활성화됩니다.

저장한 레이아웃을 목록에서 적용하거나 이름을 바꾸고 삭제합니다. 기본 지정과 자동 조회 체크가 한 줄에서 바뀝니다.

저장해 둔 배치와 다르게 칩을 옮겨 둔 모습입니다.

조회 조건의 저장된 레이아웃에서 이름을 고르면 행 · 열 배치가 저장 당시로 돌아오고 적용했다는 안내가 잠깐 나타납니다.

11. 좁은 화면과 한계

화면 너비가 좁아지면 조회 조건과 레이아웃 보드가 위아래로 쌓이고 표와 차트도 세로로 놓입니다.

390px 너비에서도 가로 스크롤 없이 조회 조건과 보드가 이어집니다. 표는 한 번에 보이는 열이 줄어들므로 열 차원은 하나만 두는 편이 읽기 좋습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 큐브 · 계획 · 사유 · 검산 네 가지를 한꺼번에 읽습니다. 그 뒤의 축 이동 · 접기 · 펴기는 브라우저에서 큐브를 다시 묶는 일이라 서버를 부르지 않습니다. 칸을 눌러 원천 라인을 열 때, 기준 대비의 요인 분해를 볼 때, AI 해설을 만들 때, 에이전트를 돌릴 때만 서비스를 다시 부릅니다.

산출과 대사 흐름

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회 조건 칸이 줄바꿈되고 레이아웃 보드의 세 칸이 위아래로 쌓입니다. 표와 차트는 세로로 나란히 놓이며, 표 너비 손잡이는 좁은 화면에서는 숨겨집니다.

파일 구성

shipsvc/
├─ index.html · Component.js · manifest.json
├─ controller/  Main · Base
├─ view/        Main.view.xml · fragments/ (드릴스루 · 사유 · AI · 에이전트 · 레이아웃 대화상자)
├─ model/       cube.js(피벗) · chart.js(SVG 차트) · pptx.js(보고서) · layout.js · formatter.js · ErrorHandler.js
├─ i18n/ · css/
├─ odata/       서비스 구현 · 메타데이터 · 샘플 데이터
├─ media/       소개 영상
└─ readme.html

SAP 표준 기능 확장 포인트 — 표준 T-code 와 어떻게 연계되는지

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 아래는 표준 화면으로 충분한 일과 이 화면이 더하는 관점을 나란히 놓은 표입니다.

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

T-code 별 연계 지점

운영으로 옮길 때 기존 표준 리포트를 없앨 필요는 없습니다. 법정 · 감사 · 세무 신고에 쓰는 숫자는 표준 화면과 전표에 남기고, 이 화면은 마감 전 점검과 차이 설명에 씁니다.

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

S/4HANA 에서는 CDS 뷰 위에 분석 쿼리를 올리고 Fiori 분석 앱이나 Analysis for Office 로 읽는 구성이 일반적입니다. 이 화면은 같은 구성의 한 자리, 곧 큐브 뷰와 분석 쿼리를 OData 서비스로 노출해 읽는 화면에 해당합니다. 표준으로 제공되는 판매 · 수익 분석 앱의 이름과 범위는 확인하지 못했으므로 여기서는 비교 대상으로 적지 않고, 도입 시 표준 앱과의 중복 여부를 확인 필요 항목으로 둡니다.

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

요구사항 매핑표

CDS 구성

운영 SAP 에서는 아래 뷰들을 쌓아 같은 큐브를 만듭니다. 객체 이름은 기능을 뜻하는 영문으로 지었고 코드는 스케치이므로 운영 적용 전 확인이 필요합니다.

뷰 레이어 구성

① 용역 포함률 기준 테이블 — ZEXSHP_RATEMAP · ZR_ExportShipSvcRateMap

인코텀즈 조건별로 청구 금액 안에 운송 · 보험 용역이 얼마나 들어 있는지를 정하는 자리입니다. 운영에서는 청구 문서의 운임 · 보험 조건 유형과 맞춰 이 값을 확정해야 화면의 용역분이 전표와 맞습니다. 샘플의 비율은 가정값입니다.

" ─────────────────────────────────────────────────────────
" ZEXSHP_RATEMAP — 인코텀즈별 용역 포함률 기준 테이블
" 역할 : 인코텀즈 → 운송 · 보험 용역 포함률
" 나눈 이유 : 조건이 바뀌어도 뷰를 고치지 않고 행만 변경
" ─────────────────────────────────────────────────────────
@EndUserText.label : 'Export shipping service rate map'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
define table zexshp_ratemap {
  key client      : abap.clnt not null;
  key incoterms   : abap.char(3) not null;   " CIF · CFR · CIP 등
  svc_rate        : abap.dec(5,2);           " 용역 포함률(%) — 샘플은 가정값
  valid_from      : abap.dats;
  valid_to        : abap.dats;
}

" 기준 조회용 뷰 — 이후 뷰는 이 뷰만 바라본다
@AccessControl.authorizationCheck : #NOT_REQUIRED
define view entity ZR_ExportShipSvcRateMap
  as select from zexshp_ratemap
{
  key incoterms  as Incoterms,
      svc_rate   as ServiceRate,
      valid_from as ValidFrom,
      valid_to   as ValidTo
}

② 청구 라인 기본 뷰 — ZI_ExportShipBilling

청구 문서 항목과 납품 일정을 한 줄로 읽습니다. 통화 필드에 @Semantics.currencyCode 를 붙여 뒤 단계의 집계에서 통화가 섞여 합산되지 않게 하고, 도착 예정일과 청구일의 차이로 운송 일수를 만듭니다.

" ─────────────────────────────────────────────────────────
" ZI_ExportShipBilling — 청구 라인 기본 뷰
" 역할 : 청구 문서 항목 · 인도 조건 · 도착 예정일을 함께 읽는다
" 나눈 이유 : 큐브와 드릴스루가 같은 라인을 공유
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : 'Export shipping - billing line'
define view entity ZI_ExportShipBilling
  as select from vbrp
    inner join   vbrk on vbrk.vbeln = vbrp.vbeln
    left outer join likp on likp.vbeln = vbrp.vgbel   " 납품 헤더(확인 필요)
{
  key vbrp.vbeln                  as BillingDocument,
  key vbrp.posnr                  as BillingItem,
      vbrk.bukrs                  as CompanyCode,
      vbrk.fkdat                  as BillingDate,
      left( vbrk.fkdat, 6 )       as BillingMonth,
      vbrk.kunag                  as Customer,
      vbrk.inco1                  as Incoterms,
      @Semantics.currencyCode: true
      vbrk.waerk                  as Currency,
      vbrp.matnr                  as Material,
      @Semantics.quantity.unitOfMeasure: 'Unit'
      vbrp.fkimg                  as BillingQuantity,
      vbrp.vrkme                  as Unit,
      @Semantics.amount.currencyCode: 'Currency'
      vbrp.netwr                  as NetAmountFc,
      likp.lfdat                  as ArrivalDate,           " 도착 예정일 — 확인 필요
      dats_days_between( vbrk.fkdat, likp.lfdat ) as TransitDays,
      @Semantics.amount.currencyCode: 'LocalCurrency'
      cast( vbrp.netwr * vbrk.kurrf as abap.curr(15,0) ) as GrossAmountLc,       " 원화 환산(환율 기준 확인 필요)
      @Semantics.amount.currencyCode: 'LocalCurrency'
      cast( 0 as abap.curr(15,0) )                       as RecognizedServiceLc  " 경과 일수 비율 계산은 운영 규칙에 따라 구현
}

③ 차원 뷰 — ZI_ExportShipCustomer

고객 · 국가 · 지역의 이름과 코드를 큐브와 분리해 둡니다. 이름이 바뀌어도 큐브를 다시 만들지 않고, 쿼리에서 텍스트 연결로 읽어 화면의 차원 값 목록이 이름과 코드를 함께 보여 줍니다.

" ─────────────────────────────────────────────────────────
" ZI_ExportShipCustomer — 고객 차원 뷰
" 역할 : 고객 코드 → 이름 · 국가 · 지역
" 나눈 이유 : 이름 변경이 큐브에 번지지 않게
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'Customer'
@EndUserText.label : 'Export shipping - customer'
define view entity ZI_ExportShipCustomer
  as select from kna1
{
  key kna1.kunnr               as Customer,
      @Semantics.text: true
      kna1.name1               as CustomerName,
      kna1.land1               as Country,
      kna1.regio               as Region
}

④ 분석 큐브 — ZC_ExportShipCube

이 앱의 숫자가 정해지는 자리입니다. 용역 포함률 기준을 붙여 용역분을 계산하고 제품 수익을 빼며, 도착 예정일까지의 경과 비율로 당월 인식분과 월말 이연분을 나눕니다. 항등식(청구 총액 − 용역분 = 제품 수익, 인식분 + 이연분 = 용역분)이 깨지지 않도록 이연분은 뺄셈으로 구합니다.

" ─────────────────────────────────────────────────────────
" ZC_ExportShipCube — 제품 수익 · 용역분 · 이연분 큐브
" 역할 : 라인을 차원 조합별로 집계하고 항등식을 지킨다
" 나눈 이유 : 분석 쿼리가 읽는 단일 집계 지점
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : 'Export shipping - cube'
define view entity ZC_ExportShipCube
  as select from ZI_ExportShipBilling as b
    left outer join ZR_ExportShipSvcRateMap as r
      on r.Incoterms = b.Incoterms
{
  key b.Customer,
  key b.Incoterms,
  key b.BillingMonth                                         as Period,
      b.CompanyCode,
      @Semantics.currencyCode: true
      cast( 'KRW' as waers )                                 as LocalCurrency,
      @DefaultAggregation: #SUM
      @Semantics.amount.currencyCode: 'LocalCurrency'
      sum( b.GrossAmountLc )                                 as GrossAmount,
      @DefaultAggregation: #SUM
      sum( cast( b.GrossAmountLc * coalesce( r.ServiceRate, 0 ) / 100 as abap.curr(15,0) ) )
                                                             as ServiceAmount,
      @DefaultAggregation: #SUM
      sum( b.GrossAmountLc )
        - sum( cast( b.GrossAmountLc * coalesce( r.ServiceRate, 0 ) / 100 as abap.curr(15,0) ) )
                                                             as GoodsRevenue,
      @DefaultAggregation: #SUM
      sum( b.RecognizedServiceLc )                           as RecognizedService,
      @DefaultAggregation: #SUM
      sum( b.GrossAmountLc * coalesce( r.ServiceRate, 0 ) / 100 )
        - sum( b.RecognizedServiceLc )                       as DeferredService
}
group by b.Customer, b.Incoterms, b.BillingMonth, b.CompanyCode

⑤ 분석 쿼리 — ZC_ExportShipQuery

화면이 읽는 필드만 노출하고, 조회 조건으로 쓰는 필드에 필수 필터와 텍스트 연결을 붙입니다. 청구월을 필수 범위로 두면 대용량에서도 합산 범위가 정해집니다.

" ─────────────────────────────────────────────────────────
" ZC_ExportShipQuery — 분석 쿼리(Consumption)
" 역할 : 화면에 노출할 필드 · 필터 · 표시 속성
" 나눈 이유 : 큐브를 직접 노출하지 않고 필요한 것만 공개
" ─────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : 'Export shipping - query'
define view entity ZC_ExportShipQuery
  as select from ZC_ExportShipCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, mandatory : true }
  key Period,
  @AnalyticsDetails.query.axis : #ROWS
  @ObjectModel.text.association : '_Customer'
  key Customer,
  @AnalyticsDetails.query.axis : #COLUMNS
  key Incoterms,
  @AnalyticsDetails.query.axis : #COLUMNS
  GrossAmount,
  ServiceAmount,
  GoodsRevenue,
  RecognizedService,
  DeferredService,
  _Customer
}

⑥ 접근 제어 — ZA_ExportShipAuth

회사코드 조회 권한을 이 역할 한 곳에서 겁니다. 권한이 없으면 행이 돌아오지 않으므로 화면에서 따로 숨길 필요가 없고, 큐브와 쿼리가 같은 역할을 공유합니다.

" ─────────────────────────────────────────────────────────
" ZA_ExportShipAuth — 접근 제어(DCL)
" 역할 : 회사코드(F_BKPF_BUK, 조회 권한) 기준으로 행을 거른다
" 나눈 이유 : 권한을 데이터 쪽 한 곳에서 관리
" ─────────────────────────────────────────────────────────
@EndUserText.label : 'Export shipping - authorization'
@MappingRole : true
define role ZA_ExportShipAuth {
  grant select on ZC_ExportShipCube
    where ( CompanyCode ) = aspect pfcg_auth( F_BKPF_BUK, BUKRS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — ZSD_ExportShip

쿼리를 OData V2 서비스로 노출하는 자리입니다. 바인딩을 게시하고 활성화한 뒤 화면 manifest.json 의 서비스 주소만 바꾸면 운영 데이터로 전환됩니다.

" ─────────────────────────────────────────────────────────
" ZSD_ExportShip — 서비스 정의
" 역할 : 쿼리와 차원 뷰를 서비스로 노출
" 나눈 이유 : 화면이 서비스 주소만 바라보게 분리
" ─────────────────────────────────────────────────────────
@EndUserText.label : 'Export shipping - service definition'
define service ZSD_ExportShip {
  expose ZC_ExportShipQuery as ShipQuery;
  expose ZI_ExportShipCustomer as Customer;
}
" 서비스 바인딩(ZSB_ExportShip_V2)은 Binding Type 'OData V2 - UI' 로 만들고 게시한다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 도입 전에 정해 두면 뒤에서 숫자를 다시 맞추는 일이 줄어드는 항목입니다.

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

합계 20건에서 차이 0건, 최대 차이 0원, 의도적 예외 0건입니다. 제품 수익 34,254 = 계획 33,392 + 862이고 요인 합 862는 오차 0입니다. 앞의 도입 포인트 ‘사례로 보는 효과’와 같은 숫자입니다.

운영 데이터로 갈 때

청구 라인이 수천만 건이면 합산은 데이터베이스에서 하고, 청구월을 필수 범위로 두어 한 번에 읽는 범위를 제한합니다. 원천 라인은 500줄씩 나눠 읽고 열 조합과 행 수에는 상한을 둡니다. 큐브 뷰에서 라인 단위 계산을 쓰는 부분은 데이터가 늘수록 비용이 커지므로, 집계 위치와 응답 시간 기준은 도입 전에 정해 두는 편이 안전합니다.

자주 묻는 질문

도입을 검토하는 분들이 자주 묻는 25가지를 주제별로 모았습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영