SAP 수출 컨테이너 적재·분할 선적 다차원 분석 리포트 — 비어 있는 컨테이너 공간의 운임까지 계획 대비로 읽는 수출 물류비 분석

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

수출 물류 회의의 질문은 늘 비슷합니다. 컨테이너를 얼마나 채워 보냈나, 분할 선적으로 운임이 얼마나 더 들었나, 계획보다 물류비가 늘었다면 어디서 늘었나. 지금 이 답은 판매오더(VA03) · 납품(VL03N) · 청구(VF03) 화면과 포워더 자료, 엑셀로 흩어져 있어 매달 숫자를 모아 맞추는 데 시간이 듭니다.

이 앱은 청구 문서 품목을 컨테이너 적재 관점으로 한 번 읽어 큐브로 만들고, 같은 큐브에서 표 · 차트 · 요약 · 드릴스루 · 계획 대비 · 요인분해를 모두 그립니다. 축을 바꿔도 서버를 다시 부르지 않고, 칸을 누르면 그 금액을 만든 선적 문서 라인이 열려 “어느 숫자가 맞나” 하는 회의를 줄입니다. 이 글의 모든 숫자는 가상의 검증용 샘플이며 요율 · 컨테이너 용적 · 임계값은 가정값입니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 계획보다 1,608백만원 늘어난 물류비의 요인

검증용 샘플에서 총 물류비는 계획 19,735백만원, 실적 21,343백만원으로 총차이가 +1,608백만원(+8.1%) 였습니다. 합계만 보면 “물류비가 늘었다”에서 끝납니다. 아홉 요인으로 가르자 가장 큰 몫은 미계획 선적(+1,005백만원), 그 다음이 적재율(+454백만원) 이었습니다. 컨테이너 적재율은 66.77% 로 계획의 68.63% 보다 낮았고, 같은 화물을 실으려 컨테이너가 더 쓰였다는 뜻입니다. 반대로 계획했지만 실행되지 않은 선적은 −342백만원으로 차이를 줄였습니다.

요인 전체는 미계획 선적 +1,005 · 적재율 +454 · 컨테이너당 운임 +216 · 선적 건수 +136 · 건당 화물량 +73 · 분할 선적 비율 +45 · 분할 건당 추가비 +11 · 서류비 +11 · 계획 미이행 −342(백만원) 이며, 원 단위로는 요인 합계가 총차이 1,608,098,559원과 정확히 같습니다. 선적항으로 보면 부산항 +701, 인천항 +536, 광양항 +240, 평택 · 당진항 +163, 울산항 −32백만원이고, 컨테이너 유형으로는 20피트 일반이 +1,499백만원으로 가장 큽니다. 비어 있는 공간에 쓴 운임(미적재 공간 운임)은 6,787백만원으로 계획 5,922백만원보다 865백만원 많았습니다. 이 숫자는 원인을 확정하지 않으며, 어디를 먼저 점검할지와 어떤 사유를 남길지를 정하는 단서입니다.

분해에는 조건을 걸었습니다. 요인 합계와 총차이가 1원이라도 어긋나면 화면이 오류로 표시합니다. 같은 조합이 계획과 실적 한쪽에만 있으면 억지로 나누지 않고 미계획 선적 · 계획 미이행으로 따로 세웁니다. 회의에서 “이 숫자 맞아?”라는 질문에 바로 답할 수 있다는 뜻입니다.

도입하면 달라지는 것

• 회의의 주제 — “어느 리포트 숫자가 맞나”가 아니라 “어느 선적항 · 어느 컨테이너에서 계획이 벌어졌나”를 이야기합니다.
• 분석 준비 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 화면 캡처가 줄어듭니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 매달 같은 설명을 처음부터 다시 하지 않습니다.
• 놓치지 않는 점검 — 화면을 열지 않은 날에도 규칙에 걸린 항목은 받을 역할의 대기함에 올라갑니다.

이런 회사에 맞습니다

컨테이너 단위로 수출하며 선적항 · 컨테이너 유형 · 인코텀즈가 여러 갈래인 제조 · 유통 회사, 분할 선적과 미적재 공간 때문에 운임이 계획과 벌어지는 일이 잦은 수출 · 물류 담당 조직, 그리고 수출 물류비를 월 단위로 계획과 견주어 경영진에 설명해야 하는 경영지원 조직에 맞습니다. 거래 통화가 여러 개여도 통화별로 나누어 대사합니다.

실행 화면

사용 방법

1. 조회조건 입력 — 회사코드(필수, 기본 1000)와 시작 · 종료 기간(필수, 기본 2026-01 ~ 2026-09)을 정합니다. 비교 기준은 계획 버전으로 고정돼 있어 바꿀 수 없습니다.
2. 조회 — 조회 버튼은 조회조건 영역의 오른쪽 끝에 있고 입력칸에서 Enter 를 눌러도 됩니다. 조회는 큐브를 한 번 읽는 동작이며 이후 축을 바꿔도 다시 읽지 않습니다.
3. 요약 확인 — “집계 N건 · 원천 N줄”으로 읽은 규모를 보고, 역할(CEO · CFO · 영업 책임자 · 물류 책임자)을 바꿔 앞세우는 지표를 확인합니다.
4. 축과 항목 정하기 — 레이아웃 보드에서 차원 칩을 끌어 행 · 열 · 쓰지 않는 차원 칸에 놓습니다. 행은 최대 3단계, 열은 최대 2단계입니다.
5. 표 읽기 — 행의 화살표로 아래 차원으로 내려가고, 기준 대비를 켜면 칸마다 계획 · 차이 · 증감률이 붙습니다.
6. 필터 — 필터 버튼 줄에서 차원 값을 여러 개 고릅니다. 같은 차원 안은 or, 차원 사이는 and 입니다.
7. 칸 · 행 클릭 상세 — 칸을 누르면 원천 문서 라인이 열립니다. 차이가 난 행에서는 변동 사유 버튼으로 사유를 남깁니다.
8. 분석 도구 — 상단 버튼은 레이아웃 → AI 분석 → AI 에이전트 → 기간별 요약 → CSV 순서입니다. 보고서(PowerPoint)는 AI 분석 창에서 내려받습니다.
9. 내보내기 — 지금 표의 행 · 열 · 항목 그대로 CSV 로 저장합니다.
10. 자동 조회 — 기본 레이아웃에 자동 조회를 지정해 두면 화면을 여는 순간 조회된 채 시작합니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤로 만들고, 금액과 판정은 서비스가 계산합니다. 화면은 서비스가 준 숫자를 합산하고 배치만 합니다.

처음 열었을 때 — 조회 전에도 틀이 먼저 보입니다

조회조건 · 레이아웃 보드 · 피벗 틀은 조회 전부터 보입니다. 조회 한 번으로 큐브를 읽고 나면 축을 바꿔도 서버를 다시 부르지 않습니다.

회사코드와 시작·종료 기간만 정하면 되고, 기본값은 회사코드 1000 · 2026-01 ~ 2026-09 입니다. 쓰지 않는 차원 9개가 왼쪽 칸에, 행 축에는 제품 그룹 › 선적항이 올라 있습니다. 아직 조회 전이라 표는 비어 있고 안내 문구만 보입니다. 조회 버튼은 조회조건 영역의 오른쪽 끝에 있고 Enter 로도 조회됩니다.

집계 1,246건(원천 5,335줄)을 한 번 읽어 표 · 오른쪽 차트 · 상단 지표 4개를 그립니다. 총 물류비는 21,343백만원, 물류비율은 청구액 대비 1.59%, 미적재 공간 운임은 6,787백만원입니다. 각 숫자 아래 작은 글씨는 계획 값과 대비입니다. 빨간 숫자는 계획보다 비용이 늘어난 쪽입니다.

선적항을 열 축으로 옮긴 모습입니다. 총합은 그대로이고 열 머리글만 부산항 · 인천항 · 광양항으로 바뀝니다. 이 동작은 네트워크 요청이 0건이며 브라우저에 올라온 큐브를 다시 묶는 것입니다. 열 축에 차원이 있으면 분석 항목은 첫 항목만 열에 펼쳐 보입니다.

표와 차트에 더 많은 공간을 주고 싶을 때 머리 영역을 접습니다. 접힌 줄에는 회사코드 · 기간 · 행 · 열 · 항목 수가 남아 지금 보고 있는 범위를 잊지 않게 합니다. 다시 펼치면 조건이 그대로 있습니다.

경영 요약 — 역할이 바뀌면 보는 숫자가 바뀝니다

역할 4개(CEO · CFO · 영업 책임자 · 물류 책임자)를 고르면 앞세우는 지표와 쪼개 보는 차원이 함께 바뀝니다.

CEO 는 물류비가 수출 채산에 주는 부담을 봅니다. 총 물류비 · 물류비율 · 미적재 공간 운임 · 청구액 네 개가 상단에 나오고 표는 제품 그룹 › 선적항으로 쪼개집니다. 역할을 바꿔도 다시 조회하지 않습니다.

CFO 는 월별로 비용이 어느 달에 늘었는지를 계획과 견줍니다. 총 물류비 · 적재 공간 운임 · 분할 선적 추가비 · 물류비율이 지표로 올라오고 행 축은 선적월입니다.

영업 책임자는 어느 국가와 고객에게 보낼 때 물류비가 큰지를 봅니다. 선적 1건당 물류비 · 물류비율 · 선적 건수가 같이 나와 단가 협상이나 인코텀즈 조건을 점검할 근거가 됩니다.

물류 책임자는 빈 공간에 운임을 쓰는 구간을 찾습니다. 미적재 공간 운임 · 컨테이너 적재율 · 분할 선적 비율 · 화물 1㎥당 해상 운임이 지표이고, 표는 선적항 › 컨테이너 유형입니다. 적재율 66.77% 는 컨테이너 용적 중 화물이 차지한 비율입니다.

축 전환과 범위 — 컨테이너 유형 · 선적항 · 고객을 끌어다 놓습니다

행 3단계 · 열 2단계, 차원 값 다중 선택, 표와 차트의 너비 조절까지 모두 브라우저 안에서 처리합니다.

컨테이너 유형과 선적항을 열 2단계로 올리고 제품 그룹 · 고객을 행으로 둔 조합입니다. 열 조합은 36개까지만 허용하고, 넘는 조합은 추가 단계에서 막고 안내합니다. 행을 펼치면 아래 차원으로 내려가고 차트도 같이 바뀝니다.

시간 외 차원마다 값을 여러 개 고를 수 있고, 한 차원 안에서는 or, 차원 사이에서는 and 로 묶입니다. 큐브에 실제로 있는 값만 올라오며 각 값에 원천 라인 수가 붙어 있습니다. 고르면 서버 재조회 없이 바로 반영됩니다.

선택한 필터는 필터 버튼 옆 괄호 숫자로 남아 어떤 범위를 보고 있는지 알 수 있습니다. 총계 · 차트 · 요약 지표가 같은 범위로 다시 계산됩니다. 필터를 풀면 전체 범위로 돌아옵니다.

표와 차트 사이 손잡이를 끌면 차트가 넓어집니다. 정한 너비는 이 브라우저에 기억되고, 화면이 좁아지면 차트가 표 아래로 내려갑니다.

칸에서 선적 문서까지 — 숫자의 출처를 바로 봅니다

표의 칸 하나는 원천 문서 라인의 합입니다. 칸을 누르면 그 라인이 열리고 합계가 맞는지 확인합니다.

표의 칸을 누르면 그 금액을 만든 원천 문서 라인이 열립니다. 첫 칸 기준으로 전체 합계 21,343백만원이 원천 5,335줄의 합계와 일치한다는 줄이 위에 뜨고, 질의 조건도 함께 보입니다. 기본 500줄씩 읽고 더 보기로 이어서 읽습니다.

기간별 요약은 선택한 범위를 월 단위로 묶은 표입니다. 선적 건수 · 청구액 · 적재 공간 운임 · 미적재 공간 운임 · 분할 선적 추가비 · 서류비 · 총 물류비와 계획 값이 한 줄에 있어 어느 달에서 차이가 났는지 먼저 찾을 때 씁니다.

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

적재율 · 물류비율 같은 값은 문서에 쌓이지 않으므로 식으로 정의해 두고 표에서 계산합니다.

전기되지 않는 비율과 단가를 계산항목으로 정의해 두었습니다. 분석 항목에서 고르면 표와 차트에 같은 방식으로 나타나고 소계와 총계도 식대로 다시 계산됩니다. 비율은 항목끼리 더하지 않고 분자 · 분모를 먼저 더한 뒤 나눕니다.

단계 보기는 계산 항목들을 위에서 아래로 한 줄씩 펼쳐 보는 방식입니다. 총 물류비가 적재 공간 운임 · 미적재 공간 운임 · 분할 선적 추가비 · 서류비로 어떻게 이루어지는지 한눈에 읽을 수 있습니다.

계획 대비 차이 — 같은 표가 물류비 회의 자료가 됩니다

계획과 실적을 한 칸에 놓고, 차이를 요인으로 나누고, 사유를 남깁니다.

기준 대비를 켜면 칸마다 실적 아래에 계획 · 차이 · 증감률이 붙습니다. 색은 비용에 준 영향 방향 기준이고, 금액 차이 150만원과 비율 5% 를 둘 다 넘을 때만 칠합니다. 하나만 넘으면 색 없이 숫자만 둡니다. 행 앞의 문서 아이콘은 변동 사유 입력 버튼입니다.

차이가 난 행에 사유 구분과 내용을 적습니다. 키는 조회 범위와 행 경로라서 같은 범위를 다시 열면 사유가 그대로 나오고 CSV 와 AI 근거 표에도 실립니다. 적은 사유는 이미 설명된 차이로 보고 AI 분석에서는 건너뜁니다.

총차이 1,608백만원을 선적 건수 · 건당 화물량 · 적재율 · 컨테이너당 운임 · 분할 선적 비율 · 분할 건당 추가비 · 서류비 · 미계획 선적 · 계획 미이행 아홉 요인으로 나눕니다. 미계획 선적이 +1,005백만원으로 가장 크고 계획 미이행은 −342백만원입니다. 아래 검산 줄에 요인 합계와 총차이가 같음을 매번 보여 줍니다.

AI 분석과 보고서 — 같은 숫자를 읽고 설명합니다

AI 는 서비스가 계산한 숫자를 읽기만 합니다. 근거 표를 펼쳐 확인하고 보고서로 내려받습니다.

AI 분석은 지금 화면의 범위(기간 · 필터 · 역할)를 서비스에 보내 요약과 핵심 발견을 받아 옵니다. 기본은 규칙 기반 해설이며 모델 연결은 서비스 설정 한 곳으로만 켜고 기본은 꺼져 있습니다. 숫자는 서비스가 계산한 값만 쓰고 원인은 단정하지 않고 점검 필요 항목으로 적습니다.

근거 표 펼치기를 누르면 해설에 쓴 숫자가 행으로 나옵니다. 이미 사유가 적힌 행은 건너뛴 사실이 함께 표시됩니다. 같은 창의 보고서 버튼은 현재 범위의 표와 차트가 든 PowerPoint 파일을 브라우저에서 만들어 내려받습니다.

AI 에이전트 — 감시 규칙과 대기함

규칙에 걸린 항목을 받을 역할의 대기함에 올리고, 실행 기록을 남깁니다.

감시 규칙 5개가 있습니다. 총 물류비 계획 차이 금액 · 물류비율 상한 · 미적재 공간 운임 비중 상한 · 컨테이너 적재율 하한 · 분할 선적 추가비 금액이며, 임계값과 사용 여부를 화면에서 바꿀 수 있습니다. 임계값은 검증용 샘플 분포에서 정한 가정값입니다.

지금 실행하면 규칙에 해당한 항목이 역할별 대기함에 보고로 올라옵니다. 보고에는 대상 행 경로와 금액이 있고 역할로 걸러 볼 수 있습니다. 운영에서는 이 실행을 SM36 배치나 cron 에 연결하는 방식으로 이어 갑니다.

실행 기록에는 시각 · 호출 주체(사용자 · 화면 타이머 · 배치) · 결과 · 발견 건수가 남습니다. 같은 날 두 번째 실행은 서버가 하루 한 번 제한으로 건너뜀 처리하고 사유와 첫 실행 번호를 기록합니다. 걸린 항목이 없어도 활동 기록은 남습니다.

레이아웃 저장과 복원

자주 쓰는 구성을 이름 붙여 저장하고, 기본 레이아웃은 열자마자 조회까지 마칩니다.

지금 상태를 이름 붙여 저장합니다. 기본 레이아웃으로 지정하고 자동 조회를 켜면 다음에 열 때 조회까지 끝낸 상태로 시작합니다. 이름 바꾸기 · 삭제는 관리 창에서 합니다.

화면을 새로 열었는데 저장해 둔 월간 회의용 레이아웃이 선택돼 있고 표와 차트가 이미 그려져 있습니다. 저장은 서비스에 기록되므로 새로 고침 뒤에도 남습니다.

좁은 화면과 한계 — 표를 반쯤 그리지 않습니다

화면이 좁아지면 차트를 아래로 쌓고, 범위가 너무 크면 좁히라고 안내합니다.

좁은 화면에서는 조회조건이 한 줄씩 쌓이고 상단 버튼은 아이콘만 남습니다. 차트는 표 아래로 내려가 가로 스크롤 없이 읽을 수 있습니다.

고객을 열 축에 더해 열 조합이 60개가 되는 경우입니다. 반쯤 그린 표를 보여 주지 않고 최대 36개를 넘는다는 안내를 띄우며 열 차원을 줄이도록 합니다. 행 노드가 500개를 넘는 조합도 같은 방식으로 막습니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 큐브(차원 조합별 집계)와 계획을 한 번 읽습니다. 이후에는 아래 순서로 처리되며, 축을 바꾸면 2단계부터 다시 돌고 서버는 부르지 않습니다.

1. 큐브 읽기 — 회사코드 · 기간으로 큐브와 계획을 읽습니다.
2. 필터 적용 — 차원 값 필터(or · and)를 브라우저에서 적용합니다.
3. 묶기 — 레이아웃 보드의 행 · 열 축대로 트리를 만들고 소계 · 총계를 계산합니다. 비율은 분자 · 분모를 먼저 더합니다.
4. 그리기 — 같은 트리를 표와 SVG 차트로 그립니다.
5. 칸을 누르면 — 그 칸의 차원 값 전부를 조건으로 원천 라인을 500줄씩 읽고, 칸 금액과 원천 합계를 대조합니다.
6. 요인분해 · 해설 · 에이전트 — 서비스의 펑션을 불러 서비스가 계산한 값을 받아 옵니다.

칸 색칠 · 검산 · 감시 판정 로직

금액과 비율은 서비스가 계산하고 화면은 합산과 배치만 합니다. 아래 규칙은 판정 조건 → 결과 상태 → 사용자 조치 순서이며 임계값은 검증용 샘플에서 정한 가정값입니다.

산출식과 대사식

요인분해는 같은 조합(선적월 · 선적항 · 컨테이너 유형 · 제품 그룹 · 고객 · 인코텀즈)의 실적과 계획을 맞춰 위 식에서 한 요인씩 바꾸어 계산합니다. 계획에 없던 조합의 실적은 미계획 선적, 실적이 없는 조합의 계획은 계획 미이행(음수)으로 모읍니다. 외화(미국 달러 · 유로 · 일본 엔 · 중국 위안) 청구액은 통화별로 따로 대사하고 서로 더하지 않으며, 환율은 샘플의 가정값입니다.

조회조건

결과 컬럼

차원은 선적월 · 분기 · 선적항 · 컨테이너 유형 · 제품 그룹 · 사업부 · 고객 · 수출 국가 · 지역 · 결제 통화 · 인코텀즈 11개입니다.

좁은 화면에서 달라지는 것

파일 구성

(앱 폴더)
├─ index.html · Component.js · manifest.json
├─ controller/  BaseController.js · Main.controller.js
├─ view/        Main.view.xml · fragments/ (조회 · 사유 · AI · 에이전트 · 레이아웃 · 필터 대화상자)
├─ model/       cube.js(피벗) · chart.js(SVG 차트) · pptx.js(보고서) · layout.js · formatter.js · ErrorHandler.js
├─ css/ · i18n/
├─ odata/       metadata.xml · service.js · engine.js · json/ (엔티티셋별 데이터)
├─ media/       소개 영상 · 포스터 · 자막 목차
└─ readme.html

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 그래서 운영으로 옮긴 뒤에도 기존 표준 리포트를 없앨 필요가 없고, 법정 · 감사 · 신고 대응에 쓰던 화면은 그대로 둔 채 이 앱을 분석과 월간 회의용으로 병행합니다.

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

T-code 별 연계 지점

정리하면 이 앱 결과의 숫자가 의심스러울 때는 칸 → 원천 라인 → 문서 번호 → 해당 표준 T-code 순서로 내려가고, 표준 화면의 값을 이 앱에서 다시 보려면 같은 문서의 청구일 · 고객 · 선적항으로 조회 범위를 좁힙니다.

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

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

분석 지표 정의

CDS 구성 — 뷰 · 코드 · 운영 작업까지

아래 코드는 운영 시스템에 옮길 때의 출발점으로 쓰는 스케치입니다. 표준 데이터 구조(청구 · 판매오더 · 납품 문서)를 그대로 읽고, 회사마다 달라지는 지점은 “확인 필요”로 표시했습니다.

뷰 레이어 구성

① 컨테이너 유형 기준 테이블 — 적재율의 분모를 정하는 곳

적재율은 “화물 용적 ÷ 적재 가능 용적”이고, 분모는 컨테이너 유형이 정합니다. 20피트 · 40피트 · 하이큐브의 용적을 뷰 안에 숫자로 박아 두면 기준이 바뀔 때마다 뷰를 고쳐 이송해야 하므로 테이블로 뺍니다. 샘플은 28 · 58 · 68㎥ 가정값이며, 운영에서는 회사가 정한 사용 가능 용적을 넣습니다.

@EndUserText.label : '수출 컨테이너 유형 기준'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexl_cntmap {
  " ─────────────────────────────────────────────────────────────
  "  ZEXL_CNTMAP — 컨테이너 유형별 적재 가능 용적(㎥) · 기준 중량
  "  이렇게 나눈 이유: 용적은 회사가 정하는 값이라 코드가 아니라 데이터로 둔다.
  " ─────────────────────────────────────────────────────────────
  key client    : abap.clnt not null;
  key cont_type : abap.char(4) not null;     " 20GP · 40GP · 40HC
  descr         : abap.char(40);
  cap_cbm       : abap.dec(7,2);             " 적재 가능 용적(㎥)
  cap_kg        : abap.dec(9,0);             " 기준 중량(kg)
  valid_from    : abap.dats;
}

② 선적 품목 뷰 — 라인마다 적재율과 운임을 파생하는 기본 뷰

모든 집계는 이 뷰의 한 줄(청구 품목)에서 출발합니다. 청구 헤더 · 품목, 판매오더, 납품 품목을 연결하고 컨테이너 유형 기준표를 붙여 라인마다 적재 가능 용적과 적재율을 만듭니다. 선적항 · 선적일 · 분할 여부를 어느 필드에서 가져올지는 회사 구성에 따르므로 주석에 확인 필요로 남겼습니다.

@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 선적 품목(적재 관점)'
@ObjectModel.usageType: { serviceQuality: #X, sizeCategory: #XXL, dataClass: #TRANSACTIONAL }
define view entity ZI_ExportLoadItem
  as select from vbrp
    inner join   vbrk on vbrk.vbeln = vbrp.vbeln
    left outer join zexl_cntmap as _cnt on _cnt.cont_type = vbrp.zz_cont_type   " 확장 필드 — 확인 필요
{
  " ─────────────────────────────────────────────────────────────
  "  ZI_ExportLoadItem — 청구 품목 한 줄 = 선적 한 줄
  "  이렇게 나눈 이유: 큐브 · 계획 · 쿼리가 모두 같은 라인에서 출발해야 합계가 갈라지지 않는다.
  " ─────────────────────────────────────────────────────────────
  key vbrp.vbeln                      as BillDoc,
  key vbrp.posnr                      as Item,
      vbrk.fkdat                      as BillDate,
      vbrk.kunag                      as Customer,
      vbrk.inco1                      as Incoterms,
      vbrp.matkl                      as ProdGroup,
      vbrp.aubel                      as SoDoc,
      vbrk.waerk                      as Currency,
      @Semantics.amount.currencyCode: 'Currency'
      vbrp.netwr                      as FcValue,
      @Semantics.quantity.unitOfMeasure: 'VolUnit'
      vbrp.volum                      as Cbm,
      vbrp.voleh                      as VolUnit,
      vbrp.zz_port                    as Port,          " 선적항 — 출하지점/경유지 중 택일, 확인 필요
      vbrp.zz_cont_n                  as ContN,         " 사용 컨테이너 수
      _cnt.cap_cbm * vbrp.zz_cont_n   as CapCbm,        " 적재 가능 용적
      case when _cnt.cap_cbm * vbrp.zz_cont_n > 0
           then cast( vbrp.volum as abap.dec(15,3) )
                / ( _cnt.cap_cbm * vbrp.zz_cont_n )
           else cast( 0 as abap.dec(15,3) ) end   as LoadRate
}
where vbrk.fkart = 'F2'        " 청구 유형 — 수출 청구 유형은 회사 정함, 확인 필요

③ 차원 뷰 — 선적항 · 컨테이너 유형의 값과 텍스트

레이아웃 보드와 필터가 보여 주는 값 목록은 차원 뷰가 줍니다. 값과 텍스트를 한 곳에서 내려 주면 화면의 값 도움말, 큐브의 그룹 기준, 쿼리의 필터가 같은 목록을 바라봅니다.

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 컨테이너 유형(차원)'
@Search.searchable: true
@ObjectModel.dataCategory: #VALUE_HELP
define view entity ZI_ExportContType
  as select from zexl_cntmap
{
  " ─────────────────────────────────────────────────────────────
  "  ZI_ExportContType — 컨테이너 유형 차원 + 텍스트
  "  이렇게 나눈 이유: 화면 값 목록 · 큐브 그룹 · 쿼리 필터가 같은 목록을 쓰게 한다.
  " ─────────────────────────────────────────────────────────────
  @ObjectModel.text.element: ['ContTypeText']
  @Search.defaultSearchElement: true
  key cont_type  as ContType,
      @Semantics.text: true
      descr      as ContTypeText,
      cap_cbm    as CapCbm
}

④ 큐브 — 차원 조합별 합계와 통화 환산

큐브는 선적 품목을 선적월 · 선적항 · 컨테이너 유형 · 제품 그룹 · 고객 · 인코텀즈로 묶은 합계입니다. 화면은 이 합계를 한 번 읽어 와 브라우저에서 다시 묶습니다. 외화 청구액은 환율 유형과 환산 시점을 명시해 원화로 바꾸고, 통화별 대사를 위해 원래 통화 금액도 같이 둡니다. 비율은 합산하지 않고 분자 · 분모를 따로 둡니다.

@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '수출 컨테이너 적재 큐브'
define view entity ZI_ExportLoadCube
  as select from ZI_ExportLoadItem
{
  " ─────────────────────────────────────────────────────────────
  "  ZI_ExportLoadCube — 차원 조합별 합계(실적)
  "  이렇게 나눈 이유: 화면이 한 번에 읽는 단위를 작게(수천 건 → 수백 건) 만든다.
  " ─────────────────────────────────────────────────────────────
  key substring( BillDate, 1, 6 )   as Period,
  key Port,
  key ContType,
  key ProdGroup,
  key Customer,
  key Incoterms,
      @Semantics.currencyCode: true
      cast( 'KRW' as abap.cuky )    as TargetCurrency,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'TargetCurrency'
      currency_conversion( amount => FcValue, source_currency => Currency,
         target_currency => cast( 'KRW' as abap.cuky ),
         exchange_rate_date => BillDate, exchange_rate_type => 'M',
         error_handling => 'SET_TO_NULL' )         as GrossKrw,
      @Aggregation.default: #SUM
      Cbm                           as CargoCbm,
      @Aggregation.default: #SUM
      CapCbm                        as CapacityCbm,
      @Aggregation.default: #SUM
      ContN                         as Containers,
      @Aggregation.default: #SUM
      cast( 1 as abap.int4 )        as Lines
}
group by substring( BillDate, 1, 6 ), Port, ContType, ProdGroup, Customer, Incoterms

⑤ 계획 뷰 — 실적과 같은 차원 조합으로 맞춘 비교 기준

계획과 실적을 한 칸에서 견주려면 계획이 실적과 같은 차원 조합으로 놓여 있어야 합니다. 계획의 원천(구매 · 판매 계획 테이블, 별도 업로드 테이블 등)은 회사마다 달라 여기서는 계획 테이블을 두는 형태로 스케치했습니다. 버전 컬럼으로 여러 계획을 보관할 수 있습니다.

@AccessControl.authorizationCheck: #CHECK
@Analytics.dataCategory: #CUBE
@EndUserText.label: '수출 물류비 계획'
define view entity ZI_ExportLoadPlan
  as select from zexl_plan
{
  " ─────────────────────────────────────────────────────────────
  "  ZI_ExportLoadPlan — 버전별 계획 값(실적 큐브와 같은 차원 조합)
  "  이렇게 나눈 이유: 실적과 계획이 같은 축이어야 차이 · 요인분해가 성립한다.
  " ─────────────────────────────────────────────────────────────
  key version     as Version,
  key period      as Period,
  key port        as Port,
  key cont_type   as ContType,
  key prod_group  as ProdGroup,
  key customer    as Customer,
  key incoterms   as Incoterms,
      @Semantics.currencyCode: true
      currency    as Currency,
      @Aggregation.default: #SUM
      @Semantics.amount.currencyCode: 'Currency'
      plan_freight as PlanFreight,
      @Aggregation.default: #SUM
      plan_cargo_cbm as PlanCargoCbm,
      @Aggregation.default: #SUM
      plan_containers as PlanContainers
}

⑥ 분석 쿼리 — 화면이 읽는 하나의 입구

분석 쿼리는 큐브를 화면에 내놓는 입구입니다. 필수 필터(회사코드 · 기간)를 걸어 대용량에서 전체를 읽지 않게 하고, 어느 필드가 행 · 열 · 측정값 후보인지 알립니다. 계산항목(물류비율 등)은 쿼리의 계산 필드로도 정의할 수 있지만, 이 앱은 소계 · 총계에서 다시 계산하려고 식을 서비스 데이터로 내립니다.

@AccessControl.authorizationCheck: #CHECK
@Analytics.query: true
@EndUserText.label: '수출 컨테이너 적재 분석'
@VDM.viewType: #CONSUMPTION
define view entity ZC_ExportLoadQuery
  as select from ZI_ExportLoadCube
{
  " ─────────────────────────────────────────────────────────────
  "  ZC_ExportLoadQuery — 분석 도구와 화면이 읽는 입구
  "  이렇게 나눈 이유: 필수 필터와 화면 주석을 큐브가 아닌 소비 계층에 둔다.
  " ─────────────────────────────────────────────────────────────
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
  @UI.selectionField: [{ position: 10 }]
  key Period,
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.valueHelpDefinition: [{ entity: { name: 'ZI_ExportContType', element: 'ContType' } }]
  @UI.selectionField: [{ position: 20 }]
  key ContType,
  @AnalyticsDetails.query.axis: #ROWS
  key Port,
  @AnalyticsDetails.query.axis: #COLUMNS
  @UI.lineItem: [{ position: 10, label: '총 물류비(원)' }]
  GrossKrw,
  @AnalyticsDetails.query.axis: #COLUMNS
  @UI.lineItem: [{ position: 20, label: '화물 용적(㎥)' }]
  CargoCbm,
  @AnalyticsDetails.query.axis: #COLUMNS
  @UI.lineItem: [{ position: 30, label: '적재 가능 용적(㎥)' }]
  CapacityCbm
}

⑦ 접근 제어(DCL) — 합계로 남의 숫자가 새지 않게

집계 뷰에 권한을 걸지 않고 드릴스루 라인에만 걸면, 전사 합계에서 자기 몫을 빼는 방식으로 남의 숫자를 알 수 있습니다. 그래서 권한은 큐브 이전 단계인 기본 뷰에 겁니다. 아래는 판매 조직 단위 표준 권한 객체를 쓰는 형태이며, 회사의 권한 설계에 맞게 필드를 늘립니다.

@EndUserText.label: '수출 선적 품목 접근 제어'
@MappingRole: true
define role ZI_ExportLoadItem {
  grant select on ZI_ExportLoadItem
    where ( VKORG ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
  " ZI_ExportLoadCube · ZC_ExportLoadQuery 는 이 뷰를 거쳐 읽으므로
  " 같은 조건이 집계에도 적용된다. VKORG 필드를 뷰에 노출하는 수정이 필요하면
  " 기본 뷰에 vbrk.vkorg 를 추가한다(확인 필요).
}

⑧ 서비스 정의와 바인딩 — 화면이 부르는 주소

화면은 OData V2 서비스 하나만 바라봅니다. 서비스 정의에 쿼리와 차원 뷰를 노출하고, 서비스 바인딩을 OData V2 UI 로 게시하면 서비스 주소가 생깁니다. 운영 전환은 이 주소를 화면의 manifest 에 넣는 것으로 끝납니다. 변동 사유 · 레이아웃 · 감시 대기함처럼 쓰는 대상은 RAP 관리형 엔터티로 따로 둡니다.

@EndUserText.label: '수출 컨테이너 적재 분석 서비스'
define service ZUI_ExportLoadAnalysis {
  expose ZC_ExportLoadQuery   as CubeSet;
  expose ZI_ExportLoadPlan    as PlanSet;
  expose ZI_ExportContType    as ContTypeSet;
  " 변동 사유 · 레이아웃 · 규칙 · 대기함은 RAP 관리형 엔터티로 노출한다.
}
" 서비스 바인딩: OData V2 - UI 로 만든 뒤 게시한다.
" 게시 확인: 서비스 카탈로그 활성화 후 서비스 주소를 화면 설정에 넣는다.

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 정하지 않으면 막히는 순서대로 적었습니다.

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

검증용 샘플 전수에 대해 대사식을 돌렸고 차이는 모두 0건이며 의도적 예외는 없습니다. 도입 포인트의 사례와 같은 숫자입니다.

대사식 20종(첫 다섯 줄의 합 12 + 2 + 1 + 1 + 4)은 모두 차이 0이고, 차원별 소계 43건과 원천 라인 5,335줄의 항등식도 차이 0입니다. 화면 쪽은 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 원천 합계가 같은지를 실제 브라우저로 따로 확인했습니다.

운영 데이터로 갈 때

청구 문서가 수천만 건이 되면 집계 위치가 가장 먼저 중요해집니다. 큐브는 데이터베이스에서 집계하고 화면은 집계 결과만 읽습니다. 회사코드와 기간은 필수 조건으로 두어 전체를 읽지 않게 하고, 필요하면 월 단위 사전 집계 뷰를 둡니다. 인덱스는 청구일 · 판매 조직 · 고객 중심으로 점검하고, 드릴스루는 500줄씩 이어 읽습니다. 응답 시간 기준과 최대 조회 기간은 도입 시 함께 정합니다.

자주 묻는 질문

도입을 검토하시는 분들이 가장 자주 물으시는 질문을 숫자와 산식 · 화면과 사용 · 분석 기능 · 도입과 운영 순으로 모았습니다.

숫자와 산식

화면과 사용

분석 기능

도입과 운영