SAP 수입 통관 부대비 다차원 분석 리포트 — 예정 대비 차이를 요인으로 가르고 통관 라인까지 내려가 보는 수입 원가 점검

도입 포인트 — 이 리포트를 사용해야 하는 이유

수입 담당자가 월말에 받는 질문은 대체로 한 줄입니다. “통관 부대비가 왜 예정보다 많이 나왔습니까?” 통관 부대비는 수수료, 검사비, 보관·하역비, 서류·내륙운송비가 한 덩어리로 들어와서, 합계만 봐서는 관세사 단가가 올랐는지, 검사 구분이 바뀌었는지, 보관 일수가 늘었는지, 예정에 없던 통관이 끼었는지 알 수 없습니다. 지금 방식은 구매 오더, 입고, 송장 화면(ME23N · MIGO · MIRO)과 관세사 청구서를 엑셀에서 맞붙이는 것입니다. 그 사이 차원이 하나 바뀔 때마다 표를 새로 만들어야 하고, 합계가 어긋나면 어느 쪽이 맞는지부터 다툽니다.

이 리포트는 그 자리를 메웁니다. 통관 라인을 큐브로 한 번 묶어 두고, 관세사 · 검사 구분 · 통관 신고월 · 공급사 같은 차원을 끌어다 놓는 것만으로 같은 숫자를 다른 모양으로 펼칩니다. 칸을 누르면 그 금액을 만든 통관 라인이 열리고, 예정과 실적의 차이는 여덟 가지 요인으로 나뉘어 어디부터 점검할지 보여 줍니다. 관련 기준서는 IAS 2 재고자산(K-IFRS 제1002호)으로, 통관 부대비를 재고 취득원가에 넣는 판단을 점검하는 자료로 씁니다. 문단 번호는 원문 확인 전이라 적지 않습니다.

핵심 포인트 일곱 가지

사례로 보는 효과

검증용 샘플 데이터(2026년 4월~9월, 통관 라인 3,000건)에서 통관 부대비는 실적 8.50억원, 예정 7.49억원으로 +1.01억원(+13.5%) 차이가 났습니다. 합계만 보면 “조금 많다”로 끝나지만, 여덟 요인으로 가르면 모양이 달라집니다.

가장 큰 몫은 물량이나 단가가 아니라 예정에 없던 통관(+6,190만원)이고, 그다음이 보관 일수(+2,317만원)와 통관 물량(+2,682만원)입니다. 같은 범위를 대사식으로 따져 보면 큐브 합계와 원천 라인 합계는 측정값 8개 모두 차이 0, 라인 3,000건의 부대비 합 검사도 차이 0건입니다. 그래서 “숫자가 맞는가”를 따지는 회의 대신 “예정에 없던 통관은 왜 생겼는가”를 이야기할 수 있습니다.

도입하면 달라지는 것

• 월말 점검 준비 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”가 아니라 “무엇을 확인할 것인가”로 옮겨 갑니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 화면을 열지 않아도 규칙에 걸린 항목이 대기함에 올라갑니다.

이런 회사에 맞습니다

수입 비중이 크고 관세사 · 포워더 · 보관업체를 여러 곳 쓰면서, 통관 부대비를 엑셀로 모아 월마감 때 원가에 반영하는 제조 · 유통 회사입니다. 외화 결제 통화가 여러 개이거나 통관지가 여러 곳이라 차원이 많을수록, 구매 · 물류 · 자금 · 재무 담당이 서로 다른 질문으로 같은 숫자를 볼수록 효과가 큽니다.

실행 화면

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

사용 방법

1. 조회조건 입력 — 회사코드(필수)와 시작 · 종료 통관 신고월(필수, 기본 6개월)을 확인합니다. 차원 값(관세사 · 공급사 · 출항국 · 자재그룹 · 통화 · 검사 구분 등)은 선택이며 비우면 전체입니다.
2. 조회 — 조회 버튼은 조회조건 영역 오른쪽 끝에 있습니다. 입력 칸에서 Enter 를 눌러도 조회됩니다. 열 때 자동 조회는 기본으로 지정하고 자동 조회를 켠 레이아웃에서만 일어납니다.
3. 요약 확인 — 임원 요약에서 역할(재무 · 구매 · 물류 · 자금 책임자)을 고르면 먼저 볼 지표와 예정보다 많은 곳 · 적은 곳이 나옵니다.
4. 탭 · 축 이동 — 레이아웃 보드에서 차원을 행 · 열 · 풀로 끌어 놓고, 표시 항목 · 금액 단위 · 비교 · 임계를 바꿉니다. 서버를 다시 부르지 않습니다.
5. 행 · 칸 클릭 — 행 이름은 그 범위의 요인분해를, 숫자 칸은 통관 라인 목록을 엽니다. 사유 버튼으로 차이 원인을 남깁니다.
6. 내보내기 — 표 위 CSV 로 현재 피벗을, 통관 라인 창의 CSV 로 라인 목록을 내려받습니다. AI 분석 창에서는 PPTX 보고서를 받습니다.

무엇으로 만들었나

앱 정보

처음 열었을 때 — 비어 있는 틀에서 첫 피벗까지

처음 열면 조회조건과 레이아웃 보드만 보이는 빈 틀입니다. 조회하면 피벗과 차트가 한꺼번에 나타나고, 차원을 끌어 옮기면 서버 호출 없이 표가 바뀝니다.

회사코드와 통관 신고월 범위가 기본값으로 채워져 있고, 조회 버튼은 조회조건 영역 오른쪽 끝에 있습니다. 조건 입력 칸에서 Enter 를 눌러도 조회됩니다.

숫자는 백만원 단위이며 합계 열이 맨 오른쪽에 있습니다. 표 위의 요약 영역이 접혀 있으면 펼쳐 지표를 함께 볼 수 있습니다.

차원을 끌어서 다른 영역에 놓으면 표가 바로 다시 그려집니다. 이때 서버에는 아무 요청도 가지 않으며, 총합은 어느 배치에서도 같습니다.

행은 최대 3개, 열은 최대 2개 차원까지 놓을 수 있습니다. 차원 옆 버튼으로 값을 골라 범위를 좁힐 수 있습니다.

모두 접으면 표와 차트가 화면 대부분을 차지해 많은 행을 한 번에 볼 수 있습니다. 다시 펼치면 입력한 값이 그대로 남아 있습니다.

경영 요약 — 역할마다 먼저 보는 지표가 다르다

같은 큐브를 누가 보느냐에 따라 먼저 볼 지표가 다릅니다. 역할을 고르면 행 축과 측정값이 함께 바뀌어, 재무 · 구매 · 물류 · 자금 책임자가 각자 첫 화면에서 자기 질문의 답을 봅니다.

증감은 예정과 비교한 값이며 색은 차이 모드의 임계를 따릅니다. 역할을 바꾸면 기본 행 축과 측정값이 함께 바뀝니다.

같은 큐브를 다른 질문으로 읽는 것이며 별도 조회는 일어나지 않습니다. 표의 숫자는 아래 피벗과 같은 값입니다.

보관 일수가 길어 비용이 커진 곳이 위쪽에 올라옵니다. 어느 곳이 예정보다 적게 쓰였는지도 함께 보입니다.

통화마다 환율 요인이 따로 계산되어, 환율 영향이 큰 통화를 바로 찾을 수 있습니다. 외화 금액은 원화로 환산한 값만 더합니다.

축 전환과 범위 — 같은 큐브를 다른 모양으로

행은 3단계, 열은 2단계까지 쌓을 수 있고 차원 값은 여러 개 골라 범위를 좁힙니다. 조합이 너무 많아지면 표를 그리지 않고 안내를 띄웁니다.

열 조합이 36개를 넘으면 표를 그리지 않고 안내를 띄웁니다. 행 축도 같은 방식으로 단계를 쌓습니다.

값 이름과 함께 그 값에 속한 통관 라인 수가 보입니다. 고른 값만 표와 차트, 요약, 드릴스루에 똑같이 적용됩니다.

줄어든 범위의 합계는 큐브 합계를 그 조건으로 다시 더한 값입니다. 조건은 표 위 한 줄에 요약됩니다.

차트가 필요 없으면 줄이고, 표를 넓게 보려면 반대로 끕니다. 좁은 화면에서는 차트가 표 아래로 내려갑니다.

칸에서 통관 라인까지 — 숫자의 근거를 내려가 본다

표의 숫자를 믿을 수 있는지는 칸에서 원천까지 내려가 봐야 알 수 있습니다. 칸을 누르면 통관 라인이 열리고, 칸 금액과 라인 합계가 같다는 표시가 붙습니다.

위쪽의 칸 금액과 라인 합계가 같으면 일치로 표시됩니다. 라인이 많으면 일정 단위로 나누어 읽고 전체 보기로 이어서 읽을 수 있습니다.

표준 구매·입고·송장 화면에서 같은 문서를 찾아 대조할 수 있도록 번호를 그대로 보여줍니다. CSV 로 내려받을 수 있습니다.

차이는 모두 0 이어야 하며, 어긋나면 그 월을 점검 대상으로 봅니다. 큐브를 믿어도 되는지 확인하는 마지막 장치입니다.

계산항목 — 비율과 원가를 같은 표로

측정값을 계산항목으로 바꾸면 같은 표가 비율과 원가로 읽힙니다. 소계와 합계도 각 칸의 분자 · 분모를 따로 더한 뒤 나눠서 계산합니다.

부대비율은 통관 부대비 합계를 과세가격으로 나눈 값입니다. 소계와 합계 칸도 각 칸의 분자·분모를 따로 더한 뒤 나눠서 계산합니다.

운임과 관세 같은 다른 원가 요소는 다른 화면에서 더합니다. 계산식은 계산항목 목록에서 확인할 수 있습니다.

예정 대비 차이 — 같은 표가 점검 회의 자료가 된다

비교를 예정 대비로 바꾸면 같은 표가 점검 회의 자료가 됩니다. 금액과 비율이 모두 임계를 넘을 때만 색이 입혀지고, 차이는 요인으로 쪼개지며, 이유는 행에 남습니다.

금액과 비율이 모두 임계를 넘는 칸만 빨강(예정보다 많음) 또는 초록(예정보다 적음)으로 칠합니다. 임계는 화면에서 바꿀 수 있고 기본값은 100만원과 10퍼센트입니다.

붉은 막대는 부대비를 늘린 요인, 초록 막대는 줄인 요인입니다. 막대 합과 총차이는 검산 줄에서 같은지 확인합니다.

위 화면은 한 관세사의 예정 120.4백만원에서 실적 135.6백만원까지의 요인입니다. 전체 범위로 버튼으로 돌아옵니다.

그때의 차이 금액과 비율이 함께 저장됩니다. 원인 유형은 요인분해의 요인 이름과 같습니다.

새로 고친 뒤 다시 조회해도 사유가 남아 있고, 같은 범위를 열면 다시 보입니다. 같은 행의 사유는 수정과 삭제가 가능합니다.

AI 분석과 보고서 — 규칙으로 읽고 근거를 붙인다

AI 분석은 지금 보고 있는 범위를 규칙으로 읽어 요약 · 핵심 발견 · 근거를 내놓습니다. 금액은 서비스가 계산한 값만 쓰므로 모델을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다.

모델이 연결되어 있지 않아도 규칙 기반 해설이 나오며, 모든 숫자는 서비스가 계산한 값만 씁니다. 발견 옆 버튼으로 사유 입력창을 바로 열 수 있고, 검토용 PPT 보고서를 내려받을 수 있습니다.

AI 에이전트 — 정해 둔 규칙이 먼저 찾는다

AI 에이전트는 정해 둔 규칙으로 스스로 조회해 걸린 항목을 역할별 대기함에 올립니다. 하루 한 번 제한은 화면이 아니라 서비스의 기록이 판정합니다.

임계값과 사용 여부를 바꿔 저장할 수 있습니다. 규칙은 수수료율, 긴급 통관률, 예정 초과, 요인 영향 등을 봅니다.

실행 기록에는 점검한 규칙 수와 걸린 수가 남습니다. 보고는 역할별로 나뉩니다.

실행 기록에는 완료와 제한 상태가 나란히 보입니다. 화면을 열어 둔 동안의 자동 실행도 같은 제한을 따릅니다.

레이아웃 저장과 복원 — 열자마자 내 화면

축 배치 · 측정값 · 임계 · 역할 · 조회조건을 이름 붙여 저장해 두면 다음에 열 때 그 배치로 시작합니다. 기본으로 지정하고 자동 조회를 켜면 열자마자 조회된 상태입니다.

기본으로 지정하고 자동 조회를 켤 수 있습니다. 자동 조회는 기본으로 지정한 레이아웃에서만 선택됩니다.

같은 이름으로 저장하면 덮어씁니다. 기본으로 지정한 항목은 목록에서 표시됩니다.

위 화면은 통관지별 보관·하역 비중 레이아웃입니다.

좁은 화면과 한계 — 휴대폰 폭과 범위 상한

390px 폭에서는 차트가 표 아래로 내려가 휴대폰에서도 같은 리포트를 봅니다. 열 조합 36개 · 행 노드 1,500개 상한을 넘으면 안내가 나옵니다.

열 축을 줄이거나 차원 값을 골라 범위를 좁히면 다시 그려집니다. 행은 1,500개 노드가 상한입니다.

제목은 줄어들고 AI 분석·AI 에이전트·레이아웃 버튼은 그대로 남습니다. 가로 스크롤은 표 안에만 생깁니다.

요약 영역과 드릴스루 창도 같은 방식으로 한 열이 됩니다. 기능은 넓은 화면과 같습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 큐브(차원 조합 × 측정값), 예정, 검산 자료를 한 번에 읽어 브라우저에서 피벗을 만듭니다. 이후 축을 옮기거나 값을 고르면 읽어 온 큐브를 다시 집계할 뿐 서버를 부르지 않습니다. 금액이 걸린 계산 — 요인분해, AI 해설, 에이전트 점검 — 은 서비스 한 곳에서만 하고 화면은 그 결과를 읽어 표시합니다.

통관 라인 하나의 부대비 산출

판정 규칙

요인분해 — 순차 치환

실적과 예정의 차이를 아래 순서로 한 요인씩 예정 값에서 실적 값으로 바꿔 가며 변화량을 구합니다. 마지막에 예정에 없던 통관의 부대비를 더하면 총차이와 정확히 같아지고, 화면은 이 등식을 “검산: 요인 합 − 총차이 = 0원”으로 매번 보여 줍니다.

통관 물량 → 외화 단가 → 환율 → 수수료율 → 검사 단가 → 보관 일수 → 서류·내륙 단가 → 미계획 통관

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

조회조건 · 축 보드 · 요약 · 표 · 차트가 한 열로 쌓이고 차트는 표 아래로 내려갑니다. 표는 가로로 밀어서 보고, 통관 라인 창은 화면 폭에 맞춰 열립니다. 기능은 넓은 화면과 같습니다.

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ view/ Main.view.xml · fragment/ (Drill · Reason · Ai · Agent · Layout)
├─ controller/ Main.controller.js · BaseController.js
├─ model/ cube.js · chart.js · pptx.js · layout.js · formatter.js · ErrorHandler.js
├─ i18n/ · css/
├─ odata/ (서비스 로직 · 메타데이터 · 데이터)
├─ media/ 소개 영상 · 대표 장면
└─ readme.html

SAP 표준 기능 확장 포인트

이 리포트는 SAP 표준을 대체하지 않습니다. 표준이 이미 잘하는 일은 표준에 맡기고, 표준이 끊기는 자리만 이어 붙이는 쪽으로 만들었습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다.

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

T-code 별 연계 지점

운영으로 전환해도 기존 표준 리포트를 없애야 하는 것은 아닙니다. 법정 신고, 감사 대응, 회계 처리는 표준 화면이 계속 담당하고, 이 화면은 그 앞단에서 점검 대상을 좁히는 조회 · 검증 도구로 둡니다.

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

S/4HANA 의 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정해진 분석 질문을 빠르게 답하는 데 좋습니다. 이 리포트는 그 위에서 “차원을 마음대로 옮겨 보고, 칸에서 원천까지 내려가고, 예정과의 차이를 요인으로 가르는” 탐색 쪽을 맡습니다. 같은 CDS 큐브를 서비스로 노출해 두면 표준 분석 도구와 이 화면이 같은 숫자를 봅니다. 구체적인 표준 Fiori 앱 이름은 환경마다 달라 확인 필요로 둡니다.

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

분석 지표 정의

CDS 구성

이 사례의 화면은 통관 라인 3,000건에서 만든 큐브 20,640행을 브라우저가 들고 묶습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일은 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰를 레이어 순서대로 적은 것입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스와 환경에 따라 다르므로 그대로 붙여 넣기 전에 View Browser(F2170) 로 실제 이름을 확인해야 합니다. 특히 통관 라인의 원천(통관 신고 · 허가 · 검사 정보를 SAP 어디에 두는지)은 고객사마다 달라 확인 필요로 표시했습니다.

뷰 레이어 구성

① 부대비 항목 매핑 테이블

리포트의 모든 금액이 이 표에서 갈립니다. 구매 오더 조건이나 송장의 부대비용 유형 중 어느 것을 수수료로, 어느 것을 검사비로 읽을지 정하는 자리라 운영 전환에서 가장 먼저 합의해야 하는 항목입니다. 유효기간을 둔 이유는 조건 체계가 바뀌어도 과거 숫자가 흔들리지 않게 하기 위해서입니다.

" ────────────────────────────────────────────────────────────────
"  zclr_cost_map — 조건 유형 → 통관 부대비 항목 매핑 (투명 테이블)
"  코드에 박지 않는 이유 : 조건 유형은 고객사마다 다르고 늘어난다.
" ────────────────────────────────────────────────────────────────
@EndUserText.label : '통관 부대비 항목 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C          " 고객 유지 — 전송(TR)으로 옮긴다
@AbapCatalog.dataMaintenance : #ALLOWED  " SM30 뷰를 함께 만들어 둔다
define table zclr_cost_map {
  key mandt    : mandt not null;
  key kschl    : kscha not null;         " 조건 유형 (확인 필요 — 고객사별)
  key valid_to : abap.dats not null;
  item_kind    : abap.char(4);           " FEE 수수료 · INSP 검사 · STOR 보관 · DOC 서류
  planned      : abap.char(1);           " X = 구매 오더의 예정 조건, 공백 = 송장 실적
  sort_no      : abap.int4;
}

② 통관 라인 원천 뷰

큐브와 드릴스루가 함께 읽는 한 행 = 통관 라인입니다. 통관 신고 · 허가 · 검사 정보를 어디에 두는지는 환경마다 다릅니다. 무역 모듈, 확장 필드, 외부 통관 시스템 연계 중 하나이므로 아래 zclr_decl 자리는 확인 필요 항목입니다. 구매 오더 품목과의 연결 키(번호 · 품목)만은 유지해야 ME23N 대조가 됩니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ClrDeclaration — 통관 라인 (원천)
"  zclr_decl : 통관 신고 · 허가 · 검사 정보를 담은 고객사 테이블 (확인 필요)
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '통관 라인'
@Analytics.dataCategory              : #DIMENSION
@ObjectModel.representativeKey       : 'ClearanceNo'
define view entity ZI_ClrDeclaration
  as select from zclr_decl      as Decl
  inner join     I_PurchaseOrderItem as Poi          " 뷰 이름은 릴리스 확인
    on  Poi.PurchaseOrder     = Decl.ebeln
    and Poi.PurchaseOrderItem = Decl.ebelp
{
  key Decl.clr_no                    as ClearanceNo,
  key Decl.clr_item                  as ClearanceItem,
      Decl.ebeln                     as PurchaseOrder,
      Decl.ebelp                     as PurchaseOrderItem,
      Poi.CompanyCode                as Bukrs,
      Poi.Plant                      as Werks,
      Poi.Material                   as Matnr,
      Decl.bl_no                     as BlNo,
      Decl.broker                    as Broker,        " 관세사
      Decl.insp_kind                 as InspKind,      " 전량 · 선별 · 서류 · 무검사
      Decl.customs                   as Customs,       " 통관지
      Decl.decl_date                 as DeclDate,
      Decl.recv_date                 as RecvDate,
      Decl.urgent                    as UrgentFlag,    " 긴급(야간 · 휴일)
      Decl.qty                       as Qty,
      Decl.price_fc                  as PriceFc,
      Decl.currency                  as Currency,
      Decl.rate                      as ExchRate
}

③ 실적 큐브

차원 조합마다 한 행입니다. group by 에 올린 필드가 곧 리포트에서 쓸 수 있는 차원입니다. 여기에 없는 차원은 화면에서도 쓸 수 없으므로 처음에 넉넉히 잡아 두되, 차원을 늘릴수록 행이 곱으로 늘어 집계 효과가 줄어드는 점은 감안합니다. 이 앱의 차원은 열한 가지(관세사 · 검사 구분 · 통관지 · 공급사 · 통관 신고월 · 분기 · 플랜트 · 자재그룹 · 통화 · 출항국 · 통관 방식)입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ClrActualCube — 실적 큐브
"  통관 라인의 부대비를 DB 에서 더해 올린다.
"  화면이 들고 묶던 일을 여기로 내리는 것이 운영 전환의 핵심이다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK      " ← DCL 을 반드시 붙인다
@EndUserText.label                   : '통관 부대비 큐브 (실적)'
@Analytics.dataCategory              : #CUBE
define view entity ZI_ClrActualCube
  as select from ZI_ClrDeclaration as Decl
  association [0..*] to ZI_ClrCostLine as _Cost      " 라인별 부대비 (송장 기준)
    on  _Cost.ClearanceNo   = $projection.ClearanceNo
{
  key Decl.Bukrs                                  as Bukrs,
  key left( cast( Decl.DeclDate as abap.char(8) ), 6 ) as Period,   " 통관 신고월
  key Decl.Broker                                 as Broker,
  key Decl.InspKind                               as InspKind,
  key Decl.Customs                                as Customs,
  key Decl.Werks                                  as Werks,
  key cast( 'A' as abap.char(1) )                 as RecordType,    " A 실적 / P 예정

      " ── 파생 차원 — 라인에는 없다. 큐브에서 만든다.
      concat( 'Q', cast( division( cast( substring( cast( Decl.DeclDate as abap.char(8) ), 5, 2 )
                                    as abap.int4 ) + 2, 3, 0 ) as abap.char(1) ) ) as Quarter,

      " ── 측정값
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'Waers'
      sum( _Cost.FeeAmt )                         as FeeAmt,     " 통관 수수료
      @DefaultAggregation : #SUM
      sum( _Cost.InspAmt )                        as InspAmt,    " 검사비
      @DefaultAggregation : #SUM
      sum( _Cost.StorAmt )                        as StorAmt,    " 보관·하역비
      @DefaultAggregation : #SUM
      sum( _Cost.DocAmt )                         as DocAmt,     " 서류·내륙운송비
      @DefaultAggregation : #SUM
      sum( cast( Decl.Qty as abap.dec(15,3) )
           * Decl.PriceFc * Decl.ExchRate )       as GoodsAmt,   " 과세가격
      @DefaultAggregation : #SUM
      count( * )                                  as LineCnt,

      @Semantics.currencyCode : true
      max( Decl.Currency )                        as Waers
}
group by
  Decl.Bukrs, Decl.DeclDate, Decl.Broker, Decl.InspKind, Decl.Customs, Decl.Werks

④ 예정 큐브

실적과 같은 키 모양으로 맞추는 것이 전부입니다. 예정 값을 구매 오더 조건에서 올지, 별도 계획 테이블에서 올지가 운영에서 반드시 걸리는 질문입니다. 여기가 정해지지 않으면 “예정이 왜 이 숫자냐” 가 끝나지 않습니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ClrPlanCube — 예정 큐브
"  예정 부대비 = 구매 오더 조건(planned = 'X' 로 매핑된 유형)을 같은 차원으로 집계
"  예정 기준을 정하지 않으면 차이가 흔들린다 → 운영 전환 첫 합의 항목
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '통관 부대비 큐브 (예정)'
@Analytics.dataCategory              : #CUBE
define view entity ZI_ClrPlanCube
  as select from ZI_ClrDeclaration as Decl
  association [0..*] to ZI_ClrPlanCond as _Plan      " 구매 오더 조건 (확인 필요)
    on  _Plan.PurchaseOrder     = Decl.PurchaseOrder
    and _Plan.PurchaseOrderItem = Decl.PurchaseOrderItem
{
  key Decl.Bukrs                                  as Bukrs,
  key left( cast( Decl.DeclDate as abap.char(8) ), 6 ) as Period,
  key Decl.Broker                                 as Broker,
  key Decl.InspKind                               as InspKind,
  key Decl.Customs                                as Customs,
  key Decl.Werks                                  as Werks,
  key cast( 'P' as abap.char(1) )                 as RecordType,

      @DefaultAggregation : #SUM
      sum( _Plan.FeeAmt  )                        as FeeAmt,
      @DefaultAggregation : #SUM
      sum( _Plan.InspAmt )                        as InspAmt,
      @DefaultAggregation : #SUM
      sum( _Plan.StorAmt )                        as StorAmt,
      @DefaultAggregation : #SUM
      sum( _Plan.DocAmt  )                        as DocAmt
}
group by
  Decl.Bukrs, Decl.DeclDate, Decl.Broker, Decl.InspKind, Decl.Customs, Decl.Werks

⑤ 실적 + 예정 통합 큐브

화면의 예정 대비 차이는 여기서 한 번만 정의합니다. 같은 키로 맞물린 두 큐브를 합치고, 한쪽에만 있는 키(예정에 없던 통관)도 놓치지 않도록 union 으로 합칩니다. 이 앱이 “미계획 통관” 요인을 따로 두는 이유가 이 구조입니다.

" ────────────────────────────────────────────────────────────────
"  ZI_ClrCube — 실적 + 예정 통합
"  join 이 아니라 union : 예정 없이 실적만 있는 키(미계획 통관)도 살린다.
" ────────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck    : #CHECK
@EndUserText.label                   : '통관 부대비 큐브 (통합)'
@Analytics.dataCategory              : #CUBE
define view entity ZI_ClrCube
  as select from ZI_ClrActualCube
{
  key Bukrs, key Period, key Broker, key InspKind, key Customs, key Werks, key RecordType,
      @DefaultAggregation : #SUM  FeeAmt,
      @DefaultAggregation : #SUM  InspAmt,
      @DefaultAggregation : #SUM  StorAmt,
      @DefaultAggregation : #SUM  DocAmt
}
union all
  select from ZI_ClrPlanCube
{
  key Bukrs, key Period, key Broker, key InspKind, key Customs, key Werks, key RecordType,
      FeeAmt, InspAmt, StorAmt, DocAmt
}

⑥ 분석 쿼리

행 · 열 기본 배치와 계산 측정값을 정의합니다. 표준 Fiori 분석 앱과 Analysis for Office 가 이 쿼리를 그대로 띄우므로, 이 앱을 쓰지 않는 사용자에게도 같은 숫자가 나갑니다. 부대비율 · 수수료율은 분자와 분모를 따로 더한 뒤 나누는 계산 측정값이어야 소계가 맞습니다.

" ────────────────────────────────────────────────────────────────
"  ZC_ClrCostQuery — 분석 쿼리
" ────────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label                : '통관 부대비 분석'
@Analytics.query                  : true
define view entity ZC_ClrCostQuery
  as select from ZI_ClrCube
{
  @AnalyticsDetails.query.axis : #ROWS     Broker,
  @AnalyticsDetails.query.axis : #ROWS     InspKind,
  @AnalyticsDetails.query.axis : #COLUMNS  Period,
  @Consumption.filter.selectionType : #SINGLE  Bukrs,

  @EndUserText.label : '통관 부대비'
  @AnalyticsDetails.query.axis : #COLUMNS
  FeeAmt + InspAmt + StorAmt + DocAmt                      as AddCost,

  @EndUserText.label : '수수료율(%)'
  @AnalyticsDetails.query.formula : 'FeeAmt * 100 / GoodsAmt'
  cast( 0 as abap.dec(7,3) )                               as FeeRate
}

⑦ 권한 (DCL)

권한은 집계를 읽는 자리에 겁니다. 합계에서 한 지점을 빼면 남의 숫자가 계산으로 나오기 때문입니다. 이 앱의 역할(재무 · 구매 · 물류 · 자금 책임자)은 화면의 첫 지표를 고르는 용도이고, 접근 통제는 아래 DCL 이 맡습니다.

@EndUserText.label : '통관 부대비 큐브 권한'
@MappingRole : true
define role ZI_CLRCUBE {
  grant select on ZI_ClrActualCube
    where ( Bukrs ) = aspect pfcg_auth ( M_BEST_BSA, BUKRS, ACTVT = '03' )
      and ( Werks ) = aspect pfcg_auth ( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩

큐브와 원천을 서비스로 노출합니다. 이 앱의 엔티티셋 이름(큐브 · 예정 · 통관 원천 라인 …)은 그대로 두고 데이터 원천만 바꾸는 것이 운영 전환의 목표입니다. 화면 코드가 달라지지 않는지는 서비스 메타데이터를 앞뒤로 비교해 확인합니다.

@EndUserText.label : '통관 부대비 분석 서비스'
define service ZI_ClrCostService {
  expose ZI_ClrCube        as CubeSet;
  expose ZI_ClrDeclaration as ItemSet;
  expose ZC_ClrCostQuery;
}
" 바인딩 : ZI_ClrCostService_O2 — OData V2 - UI  (ADT 에서 Publish)

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 표의 왼쪽은 대부분 코딩이 아니라 합의입니다.

운영 데이터로 갈 때 — 통관 라인이 수백만 건이면

이 사례는 통관 라인 3,000건에서 큐브 20,640행이 나옵니다. 통관 라인이 수백만 건이 되어도 큐브 행 수는 라인 건수가 아니라 차원 조합 수를 따라갑니다 — 관세사 · 검사 구분 · 통관지 · 신고월 조합만큼 늘어납니다. 그래서 집계만 DB 로 내리면 화면이 들고 있을 행 수는 크게 달라지지 않습니다.

한 가지 더. 드릴스루는 집계가 아니라 조회입니다. 칸 하나에 수십만 건이 매달려 있으면 그 창이 열리지 않으므로, 건수를 먼저 세어 보고 일정 수를 넘으면 범위를 좁히라고 말하는 편이 낫습니다. 이 앱도 열 조합이 36개를 넘으면 그리지 않고 안내만 띄웁니다.

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

검증용 샘플 데이터에서 아래 항목을 전수로 확인했습니다. 운영 데이터로 옮긴 뒤에도 같은 대사를 같은 기준으로 다시 돌립니다.

자주 묻는 질문

도입 상담과 데모에서 자주 받는 질문을 네 묶음으로 적었습니다.

숫자와 산식

화면과 사용

AI 분석과 에이전트

도입과 운영