SAP 수입 인코텀즈 조건별 부담 비용 다차원 분석 — 같은 입고도 조건에 따라 달라지는 착지원가를 한 화면에서 쪼개 보는 리포트

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

수입 원가 회의의 질문은 늘 비슷합니다. 이번 달 착지원가가 예정보다 왜 올랐나, 어느 공급사의 어느 조건에서 올랐나, 누가 무엇을 확인해야 하나. 인코텀즈가 EXW 이면 운임·보험료·통관을 구매자가 지고, DAP 이면 도착지까지 공급사가 집니다. 같은 자재라도 조건이 바뀌면 단가와 부대비용이 서로 반대로 움직여 물대만 봐서는 원가 차이를 읽을 수 없습니다. 지금은 구매 오더 조회(ME23N), 입고 문서(MIGO · MB51), 송장 정산(MIRO · MR11)과 엑셀 취합, 포워더·관세사 정산 자료를 사람이 맞춰 이 답을 만듭니다.

이 앱은 입고 라인을 인코텀즈·공급사·원산지·자재그룹·플랜트·결제 통화·운송수단·입항지·입고월 축으로 묶은 큐브 하나에 얹고, 사용자가 축을 끌어다 놓으며 착지원가를 돌려 봅니다. 관련 기준서는 재고자산의 취득원가 구성 요소를 다루는 IAS 2 재고자산(K-IFRS 제1002호)입니다. 어느 부대비용을 원가에 넣을지의 판단은 회사와 감사인의 몫이고, 이 화면은 구성 요소를 나눠 보고 차이를 점검하도록 돕는 도구입니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 6,810백만원 차이는 어디서 났나

검증용 샘플 데이터(가상, 3,000개 입고 라인)에서 조회 기간 2026년 4월~9월의 착지원가는 266,553.7백만원으로 예정 259,743.7백만원보다 6,810.0백만원 많았습니다. 표준 리포트도 여기까지는 말해 줍니다. 이 앱은 그 다음을 답합니다. 여덟 요인으로 가르자 가장 큰 몫은 예정에 없던 입고 건(미계획) +2,881.2, 다음이 환율 +1,967.2, 외화 단가 +1,158.6, 관세율 +852.0 순이었고 물량은 오히려 −657.6 이었습니다. 여덟 요인의 합 6,810.0 은 총차이와 같고, 화면은 매번 요인 합 − 총차이 = 0 검산 줄을 보여 줍니다.

대사도 같은 숫자로 맞춰 봅니다. 큐브 합계와 입고 라인 합계는 측정값 7종 모두 차이 0, 입고 라인 3,000건의 착지원가는 물대+운임+보험료+관세+통관·하역비와 3,000건 모두 같았습니다. 샘플의 관세율·운임 단가는 가정값입니다.

도입하면 달라지는 것

• 원가 회의 준비 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나오므로 엑셀 취합과 캡처 작업이 줄어듭니다.
• 회의의 주제 — “어느 숫자가 맞나”보다 “어느 조건을 바꿀까”를 이야기합니다.
• 구매와 물류의 대화 — 인코텀즈를 바꿨을 때 단가 쪽과 부대비용 쪽이 어떻게 움직였는지를 같은 표에서 봅니다.
• 다음 기간으로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 처음부터 다시 하지 않습니다.

이런 회사에 맞습니다

수입 비중이 커서 여러 나라 공급사와 서로 다른 인코텀즈로 거래하고, 운임·보험료·관세·통관비가 착지원가에서 무시하지 못하는 제조·유통 회사에 맞습니다. 구매·물류·원가 담당이 같은 숫자를 서로 다른 화면에서 맞추느라 시간을 쓰는 조직, 결제 통화가 여러 개라 환율 영향을 따로 떼어 보고 싶은 자금 담당에게도 쓸모가 있습니다.

실행 화면

사용 방법

1. 조회 조건 입력 — 회사코드(필수)와 시작·종료 기간(필수)을 고르고, 필요하면 “차원 값”으로 공급사·인코텀즈 등을 좁힙니다(선택).
2. 조회 — 조회 조건 영역 오른쪽 끝의 “조회” 버튼이나 입력칸의 Enter 키로 조회합니다. 조회 전에도 조회 조건 · 레이아웃 보드 · 피벗 틀은 먼저 보입니다. 기본 + 자동 조회로 저장한 레이아웃이 있으면 열 때 바로 조회합니다.
3. 요약 확인 — 역할(CFO · 구매 책임자 · 물류 책임자 · 자금 책임자)을 바꿔 앞세우는 지표를 바꿉니다. 다시 조회하지 않습니다.
4. 축 · 탭 이동 — 칩을 끌어 행 축 · 열 축에 놓거나 칩의 화살표 버튼으로 옮깁니다. 표시 항목 · 금액 단위 · 비교를 바꾸면 같은 큐브에서 다시 묶입니다.
5. 칸 · 행 클릭 상세 — 값 칸을 누르면 입고 라인이 열리고, 비교 모드에서 행 이름을 누르면 그 행만 요인으로 쪼갭니다. 사유 버튼으로 변동 사유를 남깁니다.
6. 내보내기 — 피벗 머리의 CSV 버튼은 현재 피벗을, 드릴스루 창의 CSV 는 읽은 라인을 내려받습니다. AI 분석 창에서는 PowerPoint 보고서를 받습니다.

무엇으로 만들었나

처음 열었을 때 — 조회 전부터 틀이 보인다

첫 화면은 비어 있지 않습니다. 조회 조건, 끌어다 놓는 레이아웃 보드, 피벗 틀이 먼저 보이고 조회를 누르면 같은 틀이 값으로 채워집니다.

회사코드와 기간 범위(기본 2026.04~2026.09)가 들어 있고 “조회” 버튼은 조회 조건 영역 오른쪽 끝에 있습니다. 아직 서버를 부르지 않았으므로 피벗은 비어 있습니다. 입력칸에서 Enter 를 눌러도 조회됩니다.

칩을 칸 사이로 끌거나 칩의 화살표 버튼으로 옮깁니다. 기본 배치는 행 축 인코텀즈 › 공급사, 열 축 입고월입니다. 행 축이 세 단계를 넘으면 더 놓을 수 없다는 안내가 뜹니다.

화물대금(물대) 252,432.0백만원, 착지원가 266,553.7백만원 같은 숫자가 나옵니다. 피벗은 칸의 숫자를, 차트는 같은 범위를 막대로 보여 줍니다. 기본 표시 항목은 착지원가입니다.

보고용으로 피벗과 차트만 크게 보고 싶을 때 씁니다. 접어도 조회 조건 요약(회사 · 기간 · 선택한 차원 값 수)은 머리줄에 남습니다.

경영 요약 — 자리마다 다른 첫 화면

같은 큐브라도 구매, 물류, 자금, 원가 담당이 먼저 보고 싶은 숫자는 다릅니다. 역할을 바꾸면 앞세우는 지표와 쪼개 보는 차원이 함께 바뀌고, 다시 조회하지 않습니다.

착지원가 266,553.7백만원이 예정 259,743.7백만원보다 6,810.0백만원 많다는 숫자가 맨 앞에 옵니다. 빨강은 비용이 늘어난 쪽입니다.

전체 부대비용률은 5.59%로 예정 5.05%보다 0.54%p 높고, 조건 변경률은 16.27%입니다. 어느 공급사가 조건을 바꿔 보냈는지 바로 좁혀 볼 수 있습니다.

항공 · 해상 FCL · 해상 LCL 가운데 어느 수단에서 구매자 부담 운임이 예정보다 늘었는지 봅니다.

통화별 환율 영향은 차이 모드의 환율 요인에서 이어서 확인합니다.

축 전환과 범위 — 끌어다 놓기

축을 바꾸는 일에는 서버 호출이 없습니다. 조회 때 받아 둔 큐브를 브라우저가 행 · 열 축대로 다시 묶고, 총합은 어떤 축 배치에서도 같습니다. 착지원가 · 부대비용 합계 · 부대비용률 같은 계산항목은 표시 항목 목록에서 고르며, 식은 서비스의 계산항목 정의에서 옵니다.

차원 칩을 옮긴 직후의 피벗입니다. 샘플에서 여섯 가지 축 배치를 번갈아 바꿔 봐도 서버 요청은 0건이었고 물대 총합은 252,432,029,903원으로 같았습니다.

행 이름 왼쪽의 화살표로 펼치고 접습니다. 열 조합이 36개를 넘으면 앞의 36개만 보이고 안내가 뜹니다.

같은 차원 안에서는 또는, 차원 사이는 그리고로 묶입니다. 선택한 차원 수는 조회 조건 머리줄에 요약됩니다.

행이 많아지면 표시 행 수를 조절합니다. 열 조합이 36개, 행이 1,500개를 넘으면 그 상한까지만 그리고 범위를 좁히라는 안내가 뜹니다.

표시 항목은 입고 건수 · 물대 · 운임 · 보험료 · 관세 · 통관·하역비 · 조건 변경 건수와 계산항목입니다. 바꿔도 서버를 부르지 않습니다.

차트는 외부 라이브러리 없이 직접 그린 SVG 입니다. 좁은 화면에서는 표 아래로 내려갑니다.

칸에서 입고 라인까지 — 드릴스루

칸의 숫자를 의심할 때마다 다른 화면을 열 필요가 없습니다. 칸을 누르면 행 경로와 열 조합을 조건으로 그 금액을 만든 원천 라인이 열립니다.

기본 500행씩 읽고 더 읽기 · 모두 읽기로 이어갑니다. 모두 읽으면 라인 합계가 칸 금액과 같은지 맞춰 보고 결과를 표시합니다. 샘플에서는 칸 세 개 모두 칸 금액 = 라인 합계였습니다. 기간별 요약 탭에서는 월별 물대 · 부대비용 · 착지원가 · 조건 변경 건수를 봅니다.

예정 대비 차이 — 색칠, 사유, 워터폴, 요인분해

비교 기준을 “예정 대비 차이”로 바꾸면 칸마다 실적 · 예정 · 차이 · 증감률이 나옵니다. 색은 금액과 비율 임계를 둘 다 넘을 때만 칠하고, 비용이 늘면 빨강, 줄면 초록입니다.

기본 임계는 금액 1,000,000원, 비율 10%입니다. 한쪽만 넘은 칸은 칠하지 않으므로 작은 금액의 큰 비율이나 큰 금액의 작은 비율에 휘둘리지 않습니다.

임계는 화면에서 바로 바꾸고 레이아웃에 함께 저장됩니다.

사유는 조회 범위와 행 경로를 키로 저장되어 축을 바꿔도, 다음 기간 조회에서도 그 행에 따라옵니다. 사유 구분은 물량 · 외화 단가 · 환율 · 부담 조건 · 운송 단가 · 관세율 · 통관 단가 · 미계획입니다.

259,743.7 → 물량 −657.6 → 외화 단가 +1,158.6 → 환율 +1,967.2 → 부담 조건 +264.5 → 운송 단가 +339.8 → 관세율 +852.0 → 통관·하역 단가 +4.3 → 미계획 +2,881.2 → 266,553.7(단위 백만원). 요인 합 − 총차이 = 0 이 매번 표시됩니다.

전체가 아니라 특정 인코텀즈나 공급사에서 어느 요인이 컸는지 봅니다. 범위가 바뀌어도 검산 줄은 0 이어야 합니다.

AI 분석과 보고서 — 숫자는 서비스가, 설명은 읽기만

AI 분석은 현재 범위를 서비스의 해설 펑션으로 읽어 요약과 핵심 발견을 씁니다. 기본은 외부 호출이 없는 규칙 기반이고, 모델 연결은 서비스 설정 하나로 켜는 구조이며 기본은 꺼져 있습니다. 숫자를 만들지 않고 이미 사유가 적힌 차이는 건너뜁니다.

요약 한 문단과 핵심 발견 여덟 건, 근거 표 여덟 줄이 나옵니다. 핵심 발견의 각 줄은 “점검 필요” 수준으로 쓰고 원인을 단정하지 않습니다.

서버에 파일을 남기지 않습니다. 받은 파일은 PowerPoint 에서 열리는지 점검했습니다.

AI 에이전트 — 사람이 열지 않아도

감시 규칙 여섯 개(공급사 부대비용률 상한, 조건 변경률 상한, 착지원가 예정 초과, 관세율 · 운송 단가 · 환율 요인 영향 임계)가 걸리면 받을 역할 관점의 보고가 대기함에 올라갑니다. 실행은 서비스 펑션이고 하루 한 번 제한은 서버가 판정합니다.

임계값은 화면에서 바꾸고 저장합니다. 운영 배치 연결(SM36 · cron)은 설명만 두었고 샘플은 화면 타이머로 시험합니다.

첫 실행은 걸린 규칙 6건을 대기함에 올렸고, 두 번째는 “오늘은 이미 실행했습니다”로 판정되어 새 보고를 올리지 않았습니다. 활동 기록에는 호출 주체(사람 · 화면 타이머 · 배치)가 남습니다.

레이아웃 저장과 복원

축 · 조회 조건 · 표시 항목 · 임계 · 표시 행 수 · 접힘 상태를 이름을 붙여 저장합니다. 기본으로 지정하고 자동 조회를 켜면 열 때 조회된 채로 시작합니다.

저장한 레이아웃은 이름 바꾸기와 삭제로 관리합니다.

샘플에서 새로 고침 뒤 행 축이 저장한 배치(공급사 › 인코텀즈)로 돌아왔고 피벗이 조회된 채였습니다.

좁은 화면과 한계

좁은 화면에서는 차트를 표 아래로 쌓고 머리 영역을 접어 쓰도록 했습니다.

조회 조건이 세로로 쌓이고 레이아웃 보드의 칩이 줄을 바꿉니다.

화면 뒤에서 일어나는 일

축을 바꾸는 일과 칸에서 입고 라인으로 내려가는 일은 서로 다른 경로를 씁니다.

드릴스루 조건은 and 로 이어집니다. 셀이 속한 행 경로의 차원값과 열 조합의 차원값을 모두 eq 로 걸고, 기간은 시작과 끝을 한 묶음으로 보냅니다. 시작과 끝을 따로 필터로 넣으면 같은 필드끼리 or 로 묶여 범위가 무시되기 때문입니다.

ItemSet?$filter=Bukrs eq '1000' and Incoterms eq 'FOB' and Supplier eq 'S04'
       and (Period ge '202604' and Period le '202609')
  &$orderby=LtNo,ItemNo&$top=500&$skip=0&$inlinecount=allpages

차이 판정 — 조건, 결과 상태, 사용자 조치

처리 단계와 대사식

1. 착지원가 = 물대(원화 환산) + 구매자 부담 운임 + 구매자 부담 보험료 + 관세 + 통관·하역비
2. 부대비용 합계 = 운임 + 보험료 + 관세 + 통관·하역비, 부대비용률 = 부대비용 ÷ 물대 × 100
3. 조건 변경률 = 예정 인코텀즈와 실제 인코텀즈가 다른 건수 ÷ 입고 건수 × 100
4. 큐브 합계 = 원천 라인 합계(측정값별 검산)
5. 칸 값 = 그 칸의 드릴스루 라인 합계
6. 요인 합 = 실적 − 예정(총차이), 요인은 순차 대입으로 구함

샘플의 관세율 · 운임 단가 · 보험료율은 가정값이며 실제 세율과 시행 조건으로 확인한 값이 아닙니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

차트가 표 오른쪽에서 표 아래로 내려가고, 표와 차트 사이의 너비 손잡이는 쓰지 않습니다. 조회 조건과 레이아웃 보드는 세로로 쌓입니다.

파일 구성

incoterm/
├─ index.html · Component.js · manifest.json
├─ controller/  Main.controller.js · BaseController.js
├─ view/        Main.view.xml · fragment/(드릴스루 · 사유 · AI · 에이전트 · 레이아웃)
├─ model/       cube.js · chart.js · pptx.js · layout.js · formatter.js · ErrorHandler.js
├─ css/ · i18n/
└─ odata/       서비스 정의 · 서비스 로직 · 계산 모듈 · 샘플 데이터

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 어느 쪽이 무엇을 맡는지 나란히 놓으면 아래와 같습니다.

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

T-code 별 연계 지점

표준에 남겨 둘 일. 입고 · 송장 전기, 원가 요소의 계정 처리, 관세 신고와 세무 · 감사 대응은 표준 거래에 그대로 둡니다. 운영 전환 시에도 기존 표준 리포트를 없앨 필요는 없고, 이 화면은 그 위에서 조건별 · 요인별로 읽는 관점을 더합니다.

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

S/4HANA 의 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 정해진 질문에 답하는 데 강합니다. 이 앱은 같은 원천 위에 사용자가 축을 직접 돌리는 큐브 경험을 얹습니다. 운영에서는 아래 CDS 구성처럼 집계를 CDS 큐브로 내리고, 화면은 그 서비스를 읽도록 연결합니다. 확인하지 못한 표준 Fiori 앱의 이름은 적지 않았습니다.

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

분석 지표 정의

CDS 구성

이 사례의 화면은 샘플 입고 라인 3,000건을 서비스가 큐브로 묶어 주고 브라우저가 다시 묶습니다. 운영에서는 집계를 CDS 로 내립니다. 아래는 그때 만드는 객체를 역할 순서대로 적은 스케치입니다. 필드 이름과 조건은 실제 환경에서 확인해야 하며 “확인 필요”로 표시한 자리가 그렇습니다.

뷰 레이어 구성

① 부담 매핑 테이블 — 조건이 무엇을 구매자에게 맡기는지

인코텀즈 해석은 회사마다 다르고 시간이 지나면 바뀝니다. 가장 먼저 정하는 것이 이 매핑이고, 값으로 두면 이후 모든 뷰가 이 값을 따라갑니다.

" ─── ① 인코텀즈별 구매자 부담 매핑 ─────────────────────────────
" 이름   : ZIMP_INCOMAP (고객사 맞춤 테이블)
" 역할   : 인코텀즈 하나가 운임 · 보험료 · 통관 중 무엇을 구매자에게 맡기는지 정한다
" 이렇게 : 조건의 해석이 회사마다 다르다. 코드에 if 로 박지 않고 값으로 둔다
@EndUserText.label : '인코텀즈별 구매자 부담 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
define table zimp_incomap {
  key client   : abap.clnt not null;
  key inco1    : inco1 not null;       " 인코텀즈(확인 필요: 사용하는 코드 범위)
      frt_buyer : abap.char(1);        " 'X' 이면 운임을 구매자가 부담
      ins_buyer : abap.char(1);        " 'X' 이면 보험료를 구매자가 부담
      clr_buyer : abap.char(1);        " 'X' 이면 수입 통관 · 하역을 구매자가 부담
}

② 입고 라인 기준 뷰 — 모든 숫자가 거치는 라인

큐브와 드릴스루가 같은 뷰를 읽어야 “칸 금액 = 드릴스루 합계”가 성립합니다. 입고 이동 유형 · 평가 구분 같은 필터는 회사 기준으로 확인이 필요한 자리입니다.

" ─── ② 입고 라인 기준 뷰 ─────────────────────────────────────
" 이름   : ZI_ImportReceiptLine
" 역할   : 발주(EKKO · EKPO) · 입고(MSEG) 를 입고 라인 한 줄로 만든다
" 이렇게 : 큐브와 드릴스루가 같은 라인을 읽어야 칸 금액 = 라인 합계가 성립한다
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '입고 라인 기준'
@ObjectModel.usageType : { serviceQuality : #C, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
define view entity ZI_ImportReceiptLine
  as select from mseg
    inner join ekpo on ekpo.ebeln = mseg.ebeln and ekpo.ebelp = mseg.ebelp
    inner join ekko on ekko.ebeln = ekpo.ebeln
    left outer join zimp_incomap as map on map.inco1 = ekko.inco1
{
  key mseg.mblnr, key mseg.mjahr, key mseg.zeile,
  mseg.budat_mkpf     as PostingDate,
  ekko.lifnr          as Supplier,
  ekko.inco1          as Incoterms,
  ekpo.werks          as Plant,
  ekpo.matkl          as MaterialGroup,
  ekpo.matnr          as Material,
  mseg.menge          as Quantity,
  @Semantics.amount.currencyCode : 'LocalCurrency'
  mseg.dmbtr          as CargoAmount,
  mseg.waers          as LocalCurrency,
  map.frt_buyer       as FreightBuyer,
  map.ins_buyer       as InsuranceBuyer
}
where mseg.bwart = '101'              " 입고(이동 유형은 회사 기준으로 확인 필요)

③ 차원 뷰 — 이름과 코드가 함께 보이는 값 목록

차원 값에는 코드와 이름이 함께 필요합니다. 텍스트 어노테이션으로 이름의 원천을 한 곳에 둡니다.

" ─── ③ 차원 뷰 ───────────────────────────────────────────────
" 이름   : ZI_IncotermDim
" 역할   : 인코텀즈 값과 이름. 화면의 차원 값 목록과 값 이름의 원천
@AbapCatalog.viewEnhancementCategory : [#NONE]
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'Incoterms'
@EndUserText.label : '인코텀즈 차원'
define view entity ZI_IncotermDim
  as select from tinc as t
    left outer join tinct as tx on tx.inco1 = t.inco1 and tx.spras = $session.system_language
{
  @ObjectModel.text.element : ['IncotermsName']
  key t.inco1  as Incoterms,
  @Semantics.text : true
  tx.bezei     as IncotermsName
}

④ 큐브 뷰 — 화면이 한 번 읽는 집계

입고월 · 공급사 · 인코텀즈 등 조합별로 합산합니다. 큐브 행이 너무 커지면 브라우저에서 묶는 방식이 한계에 닿으므로 조합을 어디까지 둘지 정하는 것이 중요합니다.

" ─── ④ 큐브 뷰 ───────────────────────────────────────────────
" 이름   : ZI_ImportCostCube
" 역할   : 입고월 × 공급사 × 인코텀즈 × … 조합으로 원가 요소를 집계
" 이렇게 : 화면은 이 집계를 한 번 읽고 브라우저에서 다시 묶는다. 큐브 행은 수천~수만 행에 머물러야 한다
@AbapCatalog.viewEnhancementCategory : [#NONE]
@Analytics.dataCategory : #CUBE
@ObjectModel.usageType.serviceQuality : #D
@EndUserText.label : '수입 원가 큐브'
define view entity ZI_ImportCostCube
  as select from ZI_ImportReceiptLine as l
  association [0..1] to ZI_IncotermDim as _Inco on $projection.Incoterms = _Inco.Incoterms
{
  @Semantics.calendar.yearMonth : true
  cast( substring( l.PostingDate, 1, 6 ) as abap.numc(6) ) as Period,
  l.Supplier, l.Incoterms, l.Plant, l.MaterialGroup, l.Material,
  @Aggregation.default : #SUM
  cast( count(*) as abap.int4 )                         as LineCount,
  @Aggregation.default : #SUM
  @Semantics.amount.currencyCode : 'LocalCurrency'
  sum( l.CargoAmount )                                  as CargoAmount,
  l.LocalCurrency,
  _Inco
}
group by substring( l.PostingDate, 1, 6 ), l.Supplier, l.Incoterms, l.Plant,
         l.MaterialGroup, l.Material, l.LocalCurrency
" 운임 · 보험료 · 관세 · 통관비는 원가 전표 라인에서 같은 키로 합산해 붙인다(조건 유형은 확인 필요)

⑤ 예정 기준 뷰 — 같은 키의 비교 값

차이 요인분해는 실적과 예정이 같은 키여야 가능합니다. 예정 값을 발주 시점 이력에서 가져오는 방법은 고객사 환경에서 확인해야 합니다.

" ─── ⑤ 예정 기준 뷰 ───────────────────────────────────────────
" 이름   : ZI_ImportCostPlan
" 역할   : 발주 시점의 인코텀즈 · 단가 · 환율로 다시 계산한 값을 큐브와 같은 키로 둔다
" 이렇게 : 같은 키여야 실적과 칸 단위로 맞붙여 차이와 요인을 구할 수 있다
@Analytics.dataCategory : #FACT
@EndUserText.label : '수입 원가 예정 기준'
define view entity ZI_ImportCostPlan
  as select from ZI_ImportReceiptLine as l
{
  cast( substring( l.PostingDate, 1, 6 ) as abap.numc(6) ) as Period,
  l.Supplier, l.Plant, l.MaterialGroup, l.Material,
  cast( 'PLAN' as abap.char(8) )                       as Version,
  @Semantics.amount.currencyCode : 'LocalCurrency'
  sum( l.CargoAmount )                                 as PlanCargoAmount,   " 발주 시점 조건 기준 값으로 교체(확인 필요)
  l.LocalCurrency
}
group by substring( l.PostingDate, 1, 6 ), l.Supplier, l.Plant, l.MaterialGroup, l.Material, l.LocalCurrency

⑥ 분석 쿼리 — 노출 필드와 필터

소비 쪽 어노테이션은 큐브와 분리해 둡니다. 필터 필수 지정으로 조회 기간 없는 전체 읽기를 막습니다.

" ─── ⑥ 분석 쿼리 ─────────────────────────────────────────────
" 이름   : ZC_ImportCostQuery
" 역할   : 화면에 노출할 필드 · 필터를 정한다
@EndUserText.label : '수입 원가 분석 쿼리'
@Analytics.query : true
@VDM.viewType : #CONSUMPTION
define view entity ZC_ImportCostQuery
  as select from ZI_ImportCostCube
{
  @AnalyticsDetails.query.axis : #ROWS
  Incoterms,
  @AnalyticsDetails.query.axis : #ROWS
  Supplier,
  @AnalyticsDetails.query.axis : #COLUMNS
  Period,
  @Consumption.filter : { selectionType : #INTERVAL, mandatory : true }
  Period as PeriodFilter,
  @AnalyticsDetails.query.axis : #COLUMNS
  CargoAmount
}

⑦ 권한 정의 — 집계 단계에 건다

권한이 없는 사람에게 전사 합계는 보이고 드릴스루만 막히면, 두 숫자의 차이로 남의 값을 알아낼 수 있습니다. 그래서 큐브 쪽에 건 권한이어야 합니다.

" ─── ⑦ 권한 정의 ─────────────────────────────────────────────
" 이름   : ZC_ImportCostQuery 용 DCL
" 역할   : 플랜트 권한이 없는 사람에게는 그 플랜트의 집계도 보이지 않게 한다
" 이렇게 : 드릴스루에만 걸면 합계 − 보이는 합으로 남의 숫자를 알아낼 수 있다. 집계 단계에 건다
@EndUserText.label : '수입 원가 권한'
@MappingRole : true
define role ZC_ImportCostQuery {
  grant select on ZC_ImportCostQuery
    where ( Plant ) = aspect pfcg_auth( M_MSEG_WWA, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의와 바인딩 — 화면과의 접점

OData V2 로 게시한 서비스 주소를 앱 매니페스트의 서비스 주소로 바꾸면 화면은 같은 엔티티셋 이름으로 읽습니다.

" ─── ⑧ 서비스 정의 · 바인딩 ───────────────────────────────────
" 이름   : ZUI_IMPORT_COST (서비스 정의) → OData V2 바인딩
@EndUserText.label : '수입 원가 서비스'
define service ZUI_IMPORT_COST {
  expose ZC_ImportCostQuery as CubeSet;
  expose ZI_ImportCostPlan  as PlanSet;
  expose ZI_IncotermDim     as DimValueSet;
}
" 바인딩 유형 OData V2 – UI 로 게시 → 서비스 주소를 앱의 manifest 에 지정

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

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

가상 샘플(입고 라인 3,000건 → 큐브 14,140행)을 전수로 대사했습니다. 사례의 숫자와 같은 데이터입니다.

의도적 예외는 0건입니다. 화면의 소계(물대 252,432.0백만원)는 검증 스크립트의 합계 252,432,029,903원과 같습니다.

운영 데이터로 갈 때

데모 구조는 큐브를 브라우저가 한 번 읽어 묶는 방식이라 큐브 행이 수만 행을 넘으면 첫 조회와 메모리가 먼저 부담됩니다. 입고 라인이 수천만 건인 환경에서는 집계를 CDS 큐브에서 하고, 조회 기간 · 회사코드를 필수 파라미터로 두며, 차원 조합을 업무에 필요한 만큼으로 줄입니다. 인덱스와 응답 시간 기준은 대상 시스템에서 측정해 정해야 하며, 이 글의 샘플로는 확인한 값이 없습니다.

자주 묻는 질문

자주 받는 질문을 숫자와 산식, 화면과 조작, 분석 기능, 도입과 운영으로 묶었습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영