SAP 수입 솔루션 — 입항 후 하역·보관·내륙운송 물류비 다차원 분석, 예정 대비 차이를 일곱 요인으로 가르는 리포트

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

수입 자재가 입항한 뒤에는 하역, 보관, 내륙 운송, 검수·반출 수수료가 차례로 붙습니다. 분기가 지나면 구매·자금·물류 담당이 같은 질문을 받습니다. "이번 분기 입항 후 물류비가 왜 예정보다 늘었나, 업체 탓인가 보관 기간 탓인가, 입항지마다 다른가?" 지금은 구매오더(ME23N), 입고(MIGO), 자재 문서(MB51), 송장 검증(MIRO), 공급업체 항목(FBL1N)을 번갈아 열어 필요한 숫자를 엑셀에 모으고, 업체별·입항지별·보관 방식별로 표를 다시 만들어 예정과 맞춥니다. 표가 늘수록 합계가 어긋날 자리도 늘고, 어긋나면 그 표를 맞추는 회의가 열립니다.

이 화면은 입항 후 물류비를 한 번 조회해 큐브로 읽고, 그 큐브를 브라우저에서 어느 축으로든 다시 묶습니다. 칸을 누르면 원천 반출 라인으로 내려가고, 비교를 예정으로 바꾸면 총차이가 반출 물량·하역 단가·보관 요율·보관 일수·운송 단가·수수료·미계획 입항 일곱 요인으로 나뉩니다. 이 글의 관련 기준서는 없고(-), 대상 영역은 수입 입항 후 물류비입니다. 특정 기준서의 시행 시기에 매인 화면이 아니라, 지금의 방식을 한 화면으로 모으는 분석 도구입니다.

핵심 포인트 여덟 가지

사례로 보는 효과 — 총차이 +928.3 백만원의 가장 큰 몫은 미계획 입항

샘플 기준 입항 후 물류비 실적은 5,515.9 백만원, 예정은 4,587.6 백만원으로 총차이가 +928.3 백만원(+20.2%)입니다. 표준 리포트만으로도 "예정보다 늘었다" 까지는 알 수 있습니다. 일곱 요인으로 가르면 미계획 입항 +396.6(총차이의 약 43%), 보관 일수 +232.9(약 25%), 운송 단가 +131.2(약 14%) 순으로 나옵니다. 그 다음은 보관 요율 +60.7, 하역 단가 +58.6, 반출 물량 +46.3, 수수료 +1.9입니다.

읽는 순서가 바뀝니다. "업체 단가가 올랐나" 를 먼저 따지기 전에, 예정에 없던 입항이 큰 몫을 차지한다는 사실과 보관 일수가 두 번째라는 사실이 같은 화면에서 보입니다. 요인 합과 총차이의 검산은 원 단위로 0원이고, 백만원 표시의 합(928.2)이 928.3과 0.1 어긋나 보이는 것은 반올림 때문입니다. 샘플의 예정은 가정값이므로 이 비중이 실제 고객사의 모습은 아닙니다. 화면이 어떤 식으로 질문을 바꿔 주는지 보여 주는 사례입니다.

도입하면 달라지는 것

• 분기 마감 전 물류비 점검 — 표·요인분해·사유·보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 회의의 주제 — "어느 표가 맞나" 가 아니라 "보관 일수를 어떻게 줄일까" 를 이야기합니다.
• 다음 기간으로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치지 않는 점검 — 아무도 화면을 열지 않아도 규칙에 걸린 항목이 대기함에 올라옵니다.

이런 회사에 맞습니다

수입 자재를 정기적으로 들여오고 입항 후 하역·보관·내륙운송을 여러 업체에 나눠 맡기는 제조·유통 회사. 입항지·보관 방식·운송 거리 구간별로 비용을 다시 묶어 보는 구매·물류·자금 담당 조직. AI 해설을 쓰고 싶지만 숫자의 출처를 통제해야 하는 경영지원 조직. 수입 비중이 높고 입항지·업체·보관 방식이 여러 개일수록, 통화가 여러 개이거나 부대비용 조건 유형이 많을수록 한 화면으로 모으는 효과가 큽니다. 반대로 입항 건수가 적고 업체가 한두 곳이면 표준 화면과 엑셀로도 충분할 수 있습니다.

실행 화면

사용 방법

1. 조회조건 입력 — 회사코드(필수), 시작 기간·종료 기간(필수, 입항월 기준)을 정합니다. 기본값은 회사코드 1000, 2026.04~2026.09이고 차원 값은 선택입니다.
2. 조회 — 조회조건 영역 오른쪽 끝의 조회 버튼을 누르거나 Enter 를 칩니다. 큐브와 예정을 한 번 읽어 표와 차트가 같이 그려집니다.
3. 요약 확인 — 임원 요약에서 역할(CFO · 구매 책임자 · 자금 책임자 · 물류 책임자)을 고르면 앞세우는 지표가 바뀝니다. 지표 아래 값은 예정과 차이입니다.
4. 탭·축 이동 — 분석 축 보드에서 차원 칩을 행 축(최대 3)·열 축(최대 2)으로 끌어다 놓거나 칩의 화살표 버튼으로 옮깁니다. 표시 항목·금액 단위·비교(실적만 / 예정 대비)도 여기서 바꿉니다.
5. 행·칸 클릭 상세 — 행의 펼침 화살표로 하위 차원으로 내려가고, 금액 칸을 누르면 그 칸의 원천 반출 라인이 열립니다. 차이 모드에서 행 이름을 누르면 그 행 범위로 요인분해가 다시 계산됩니다.
6. 차이·사유 — 비교를 예정 대비로 바꾸면 실적·예정·차이·차이율이 나오고, 차이 난 행의 사유 링크로 사유 구분과 내용을 적습니다.
7. 분석·보고 — 상단 AI 분석(해설·근거 표·PowerPoint 보고서)과 AI 에이전트(규칙·대기함·실행 기록)를 엽니다.
8. 내보내기 — 피벗 도구 줄의 CSV 는 현재 표를, 드릴스루 창의 CSV 는 읽은 원천 라인을 내려받습니다.
9. 레이아웃 저장 — 상단 레이아웃 버튼으로 현재 상태를 이름 붙여 저장하고 기본·자동 조회를 지정합니다.

무엇으로 만들었나

화면은 OpenUI5(sap_horizon 테마)로 만들었고, 서비스 쪽은 OData V2 계약을 따릅니다. 서비스는 차원·큐브·예정·원천 라인·레이아웃·변동 사유·감시 규칙 같은 엔티티셋 16개와 요인분해·해설·에이전트 실행 펑션 3개로 나뉩니다. 이 구성을 운영의 CDS 서비스로 바꿀 때 화면 코드는 그대로 두고 서비스 주소만 바꾸는 것이 목표입니다.

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

조회 버튼을 누르기 전에도 조회조건, 레이아웃 보드, 피벗 틀이 먼저 보입니다. 조회하면 큐브를 한 번 읽어 표와 차트가 같이 그려지고, 머리 영역은 접어서 요약 한 줄만 남길 수 있습니다.

회사코드 1000과 2026.04~2026.09가 기본값이며 조회 버튼은 조회조건 영역 오른쪽 끝에 있습니다. 조회 전에는 칸 수가 0으로 표시됩니다.

조회하면 큐브를 한 번 읽어 운송·보관 업체 × 보관 방식 행과 입항월 열로 표가 그려지고 왼쪽에 업체별 막대 차트가 붙습니다. 칸 수 1,677은 큐브에서 묶인 조합 수이고, 상단 검산 줄은 큐브 합계와 원천 라인 합계의 차이 0을 보여 줍니다.

서버를 다시 부르지 않았고 총합은 그대로입니다. 차트는 열 축이 있어 묶음 막대로 바뀝니다.

조회조건, 분석 축, 임원 요약을 접으면 요약 한 줄만 남고 표와 차트가 화면 대부분을 씁니다. 접힘 상태는 레이아웃에 함께 저장됩니다.

경영 요약 — 역할을 바꾸면 보는 지표가 바뀝니다

같은 조회 결과를 두고 역할 네 가지(CFO · 구매 책임자 · 자금 책임자 · 물류 책임자)를 바꾸면 앞세우는 지표와 쪼개 보는 차원이 함께 바뀝니다. 다시 조회하지 않습니다.

물류비 5,515.9 백만원은 예정 4,587.6 대비 +928.3입니다. 붉은 숫자는 비용이 예정보다 늘어난 방향입니다.

구매 책임자는 반출 지연율, 평균 보관 일수를 앞세우고 공급사별로 예정 초과 상위를 봅니다. 지연율 48.51%는 반출 라인 3,028건 중 예정 반출일을 넘긴 1,469건의 비율입니다.

자금 책임자는 물류비 합계와 보관료 비중, 입방미터당 하역비를 앞세우고 업체별 비용을 봅니다. 지급 예정 금액을 업체 단위로 가늠할 때 쓰는 관점입니다.

물류 책임자는 평균 보관 일수와 운송비 비중을 앞세우고 입항지별로 봅니다. 보관 일수가 예정보다 길어진 입항지가 위로 올라옵니다.

축 전환과 범위 — 끌어다 놓으면 브라우저에서 바로 다시 묶입니다

차원 칩을 행 축·열 축으로 끌어다 놓거나 화살표 버튼으로 옮기면 서버를 다시 부르지 않고 브라우저에 읽어 둔 큐브를 다시 묶습니다. 행은 최대 3단계, 열은 최대 2단계이고 총합은 어떤 배치에서도 같습니다.

열에 분기와 보관 방식을 함께 놓으면 열 머리글이 두 단계 조합으로 늘어납니다. 열 조합이 36개를 넘으면 추가가 막히고 범위를 좁히라는 안내가 뜹니다.

같은 차원 안에서는 또는, 차원 사이에서는 그리고로 묶입니다. 큐브에 있는 값만 올라옵니다.

입항지에서 부산항과 인천항을 고른 상태입니다. 적용하면 같은 큐브를 브라우저에서 걸러 다시 묶으며, 조회조건 요약에 선택한 차원 수가 표시됩니다.

두 입항지만 남긴 결과입니다. 합계는 선택 범위 기준으로 다시 계산되고, 검산 줄은 큐브 전체 범위 기준으로 유지됩니다.

표와 차트 사이 손잡이를 끌어 너비를 조절합니다. 조절한 너비는 브라우저가 기억해 다음에 열 때도 같은 비율로 시작합니다.

칸에서 원천 문서까지 — 금액을 만든 반출 라인으로 내려갑니다

표의 칸을 누르면 그 금액을 만든 반출 라인(원천 문서 라인)이 열립니다. 행 경로와 열 조합이 조건이 되고, 칸의 값과 읽은 라인의 합이 같은지 머리에 표시합니다.

운송·보관 업체 K01의 2026.04 칸(196.9 백만원)을 누른 화면입니다. 칸의 값 196.9와 읽은 라인 합 196.9가 같다는 표시와 함께 101건 중 101건을 읽었다고 알려 줍니다.

라인 표에는 반출 번호, 품목, 공급사, 업체, 보관 방식, 운송 거리 구간, 보관 일수 구간, 입고 플랜트, 상태가 나옵니다. 기본 500행씩 읽고 더 읽기로 이어 봅니다.

검산 영역에는 측정값별 큐브 합계와 원천 라인 합계, 차이가 나옵니다. 아래 입항월 요약은 월별 라인 수, 반출 문서 수, 화물 가액, 물류비, 예정 물류비, 반출 지연 건수입니다.

계산항목 — 전기되지 않는 단계를 식으로 정의해 행으로 만듭니다

물류비율, 입방미터당 비용, 보관료 비중처럼 전표에 남지 않는 단계는 토큰 식으로 정의해 표시 항목으로 고릅니다. 식은 서비스가 계산하고 화면은 합산과 배치만 합니다.

표시 항목을 물류비율(%)로 바꾸면 행은 업체, 열은 분기로 같은 큐브가 비율로 다시 계산됩니다. 비율은 합산이 아니라 분자와 분모를 각각 합한 뒤 나눈 값입니다.

입방미터당 물류비를 입항지 · 자재그룹 행과 화물 형태 열로 본 화면입니다. 열 축을 세우면 계산항목도 열로 늘어납니다.

기준 대비 차이 — 예정 대비 실적이 같은 표 안에서 요인으로 나뉩니다

비교를 예정으로 바꾸면 칸마다 실적 · 예정 · 차이 · 차이율이 나타납니다. 금액과 비율 임계를 둘 다 넘는 칸만 색이 칠해지고, 총차이는 요인별 워터폴로 나뉘며 요인 합과 총차이의 검산 줄이 매번 0으로 표시됩니다.

비교를 예정으로 바꾸면 분기 열 뒤에 예정 · 실적 · 차이 · 차이율 열이 붙습니다. 금액 임계 1,000,000원과 비율 임계 10%를 둘 다 넘는 칸만 붉게 표시되어, 같은 증가라도 규모가 작으면 칠하지 않습니다.

차이 난 행의 사유 버튼을 누르면 사유 구분과 내용을 적는 창이 열립니다. 사유 구분은 물량 · 하역 단가 · 보관 요율 · 보관 일수 · 운송 단가 · 수수료 · 미계획 입항 중에서 고릅니다.

저장하면 그 행의 버튼이 사유 있음으로 바뀝니다. 키가 조회 범위와 행 경로라서 다음 기간에도 따라오며, CSV와 AI 근거에 함께 실립니다.

예정 4,587.6에서 실적 5,515.9까지를 반출 물량 +46.3, 하역 단가 +58.6, 보관 요율 +60.7, 보관 일수 +232.9, 운송 단가 +131.2, 검수·반출 수수료 +1.9, 미계획 입항 +396.6으로 이은 워터폴입니다. 요인 합 − 총차이 = 0원 검산 줄이 매번 나옵니다.

차이 모드에서 행 이름을 누르면 그 행 범위로 요인분해가 다시 계산됩니다. 범위가 좁아져도 요인 합은 그 범위의 총차이와 같습니다.

AI 분석과 보고서 — 규칙 기반 해설과 PPTX 보고서

현재 범위를 읽어 요약과 점검 대상을 문장으로 정리합니다. 기본은 규칙 기반 해설이고 숫자는 서버가 계산한 값만 씁니다. 해설에 쓴 근거 표를 펼쳐 볼 수 있고, 같은 범위의 표와 차트를 PowerPoint 보고서로 브라우저에서 만들어 내려받습니다.

맨 위 안내처럼 외부 AI 서비스를 부르지 않고 서버가 읽은 수치를 정해진 규칙으로 문장으로 옮깁니다. 이미 사유가 적힌 차이는 건너뜁니다.

해설 문장의 숫자는 모두 이 표에서 나옵니다. AI는 숫자를 만들지 않습니다.

PPTX 보고서 버튼을 누르면 현재 범위의 요약 · 점검 대상 · 워터폴 · 요인표를 담은 PowerPoint 파일을 브라우저에서 만들어 내려받습니다. 외부 라이브러리 없이 만듭니다.

AI 에이전트 — 감시 규칙 · 대기함 · 실행 기록

감시 규칙(임계값 · 받을 역할)에 걸린 항목을 받을 역할 관점의 보고로 대기함에 올립니다. 하루 한 번 제한은 서버가 판정하고, 걸린 것이 없어도 실행 기록이 남습니다.

임계값을 바꾸고 저장하면 다음 실행부터 적용됩니다. 열어 둔 동안 한 시간마다 실행하는 옵션은 기본 꺼져 있습니다.

지금 실행하면 걸린 규칙 여섯 건이 받을 역할 관점의 보고로 대기함에 올라옵니다. 각 보고에는 근거가 되는 업체 · 지표 · 임계값이 붙습니다.

같은 날 두 번째 실행은 한도에 걸려 LIMITED로 기록되고 새 보고를 올리지 않습니다. 이 판정은 서버가 합니다.

레이아웃 저장과 복원 — 기본과 자동 조회로 열면 조회된 채 시작합니다

축 · 조회조건 · 표시 항목 · 표시 행 수 · 접힘 상태를 이름 붙여 저장하고, 기본 레이아웃과 자동 조회를 지정하면 열 때 바로 조회된 상태로 시작합니다.

현재 축 · 조회조건 · 표시 항목 · 접힘 상태를 이름을 붙여 저장합니다. 기본과 자동 조회를 함께 지정할 수 있고, 목록에서 적용 · 이름 바꾸기 · 삭제를 관리합니다.

기본 + 자동 조회로 저장한 레이아웃은 화면을 새로 열면 조회가 이미 끝난 상태로 시작합니다. 저장한 축(입항지 · 자재그룹 / 분기)과 표시 항목(입방미터당 물류비)이 그대로 복원됩니다.

좁은 화면과 범위 상한 — 반쯤 그린 표 대신 안내를 띄웁니다

좁은 화면에서는 차트가 표 아래로 내려갑니다. 행·열 조합이 상한(열 36개)을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 뜹니다.

좁은 화면에서는 표가 위, 차트가 아래로 쌓이고 머리 영역 버튼은 더보기 메뉴로 접힙니다. 표는 가로로 넘겨 봅니다.

열 조합이 72개로 상한 36개를 넘으면 표를 그리지 않고 열 축을 줄이거나 차원 값을 골라 범위를 좁히라는 안내를 띄웁니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 큐브와 예정을 한 번씩 읽습니다. 이후의 축 이동·접기·펼치기·다중 선택은 브라우저에 읽어 둔 큐브를 다시 묶는 일이라 서버를 부르지 않습니다. 서버를 다시 부르는 것은 칸을 눌러 원천 라인을 읽을 때, 요인분해·해설·에이전트 같은 계산 펑션을 부를 때, 변동 사유·레이아웃을 저장할 때뿐입니다.

물류비 산식과 점검 규칙 — 판정이 아니라 점검 후보를 알려 줍니다

이 화면은 점검을 돕는 조회 도구이며 판단을 단정하지 않습니다. 아래 규칙의 결과는 모두 점검 필요·확인 필요 수준의 안내입니다.

미계획 입항은 예정(구매오더 기준 계획)에 없는 입항 라인의 물류비 전액입니다. 샘플 데이터의 예정은 가정값입니다.

입항 후 흐름과 데이터 지점, 대사식

• 원천 라인 금액 = 물량 × 단가(하역·운송), 물량 × 요율 × 일수(보관), 건당 수수료. 라인 합계 = 네 가지의 합.
• 큐브 합계 = 원천 라인 합계(측정값 · 입항월별). 차이는 검산표에 항상 표시합니다.
• 예정 큐브 합계 = 예정 라인 합계(예정에 있는 라인만).
• 계산항목 = 분자와 분모를 각각 합산한 뒤 식에 따라 계산(비율·단가는 칸마다 평균을 내지 않음).
• 요인 합 = 총차이(실적 − 예정). 같은 범위에서 매번 검산합니다.
• 드릴스루 합계 = 칸 금액.

조회조건

결과 컬럼

기능 버튼은 조회 · 초기화 · 차원 값 · 행 · 열 바꾸기 · 기본 축 · 펼치기 · 접기 · 요인 워터폴 · CSV · AI 분석 · AI 에이전트 · 레이아웃입니다. 상한을 넘는 축 조합은 표를 그리지 않고 안내를 띄웁니다.

좁은 화면에서 달라지는 것

• 차트가 표 아래로 내려가고 머리 영역 버튼은 더보기 메뉴로 접힙니다.
• 표는 가로로 넘겨 봅니다. 축 끌어다 놓기는 넓은 화면이 편하므로 좁은 화면은 읽는 용도로 둡니다.
• 행·열 조합이 상한(열 36개)을 넘으면 반쯤 그린 표 대신 범위를 좁히라는 안내가 뜹니다.

파일 구성

index.html · Component.js · manifest.json · readme.html
controller/   BaseController · Main.controller
view/         Main.view.xml · fragment/ (원천 라인 · 사유 · 레이아웃 · AI · 에이전트)
model/        ErrorHandler · chart · cube · formatter · layout · pptx
css/ · i18n/  스타일 · 한국어 문구
media/        소개 영상 · 포스터 · 재생 지점
odata/        서비스 정의 · 계산 로직 · 엔티티셋별 샘플 데이터

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

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

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

T-code 별 연계 지점

운영 전환 때 "기존 리포트를 없애야 하나" 는 질문에는 없애지 않아도 됩니다가 답입니다. 법정·감사·세무 대응은 표준 기능에 남기고, 이 화면의 값이 위 대조 지점에서 표준 화면과 맞는 것을 한 분기 이상 확인한 뒤 기존 분석용 엑셀부터 줄이는 순서를 권합니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리, Fiori 분석 앱, Analysis for Office 같은 분석 도구가 있습니다. 이 화면은 그것들을 대신하려는 것이 아니라, 입항 후 물류비라는 좁은 질문에 맞춰 예정과의 요인분해, 행에 남는 사유, 점검 에이전트를 한 화면에 모은 것입니다. 같은 질문에 답하는 표준 분석 앱이 고객사 버전에 이미 있는지는 릴리스마다 달라 확인 필요이며, 있다면 그 앱의 데이터와 이 화면의 큐브를 같은 원천에서 읽도록 맞추는 것이 좋습니다. 이 글의 CDS 구성은 구매 오더·송장·자재 문서 테이블을 직접 읽는 형태로 썼고, 쓸 수 있는 표준 CDS 뷰의 이름은 고객사 버전에서 확인해 바꾸는 것을 전제로 했습니다.

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

분석 지표 정의표

CDS 구성 — 코드와 운영 작업

화면이 읽는 샘플 서비스를 운영의 CDS 서비스로 바꾸는 방법을 정리했습니다. 아래 코드는 구조를 보여 주는 예시이며, 표준 CDS 뷰의 이름이 고객사 버전에서 확인되지 않은 부분은 원천 테이블 기준으로 썼고 확인 필요로 표시했습니다.

뷰 레이어 구성

① 조건 유형 매핑 테이블 — 어떤 청구 조건이 어느 비용 묶음인가

입항 후 물류비 분석에서 가장 먼저 정해지는 것은 코드가 아니라 매핑입니다. 송장 라인의 조건 유형(하역료·보관료·내륙 운송료·검수 수수료…)이 네 가지 비용 묶음 중 어디에 속하는지는 회사마다 다르고, 이 테이블이 그 기준입니다. 효력 시작일을 두어 매핑이 바뀌어도 과거 기간 숫자가 흔들리지 않게 합니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZIMP_CHGKEY  (입항 후 물류비 조건 유형 매핑)
"  역할  : 송장 라인의 조건 유형 → 비용 묶음(HAND/STORE/HAUL/MISC)
"  이렇게 나눈 이유 : 코드에 조건 유형을 박으면 새 부대비용이 생길 때마다
"                    뷰를 고쳐 이송해야 한다. 매핑은 데이터로 둔다.
"  확인 필요 : 조건 유형 코드 체계는 고객사 설정에 따른다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '입항 후 물류비 조건 유형 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_chgkey {
  key client     : abap.clnt not null;
  key bukrs      : bukrs not null;
  key cond_type  : abap.char(4) not null;
  key valid_from : abap.dats not null;
  cost_kind      : abap.char(5) not null;   " HAND | STORE | HAUL | MISC
  valid_to       : abap.dats;
  note           : abap.char(60);
}

② 라인 뷰 — 반출 라인 한 줄이 비용 네 가지를 갖는다

큐브의 바닥은 반출 라인입니다. 송장 라인을 매핑 테이블로 비용 묶음에 나누고, 같은 구매오더 품목의 입고·반출 이동과 이어 보관 일수를 구합니다. 이 뷰에서 정해지는 것은 "한 줄이 무엇인가" 이고, 이후 모든 합계는 이 줄의 합입니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZI_ImpHaulLine
"  역할  : 입고 라인 + 청구 라인 → 반출 라인(비용 4종 · 보관 일수)
"  이렇게 나눈 이유 : 집계(큐브)와 라인 단위 드릴스루가 같은 뷰를 읽어야
"                    칸 금액과 라인 합계가 같아진다.
"  보조 뷰 : ZI_ImpHaulMove 는 입고·반출 자재 문서 이동에서 보관 일수와
"            예정 반출일 초과 표시를 만드는 같은 모양의 뷰다.
"  확인 필요 : 청구 라인과 입고 라인의 연결 키(구매오더 이력 기준 여부)는
"              고객사의 송장 입력 방식에 따라 다르다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '입항 후 물류비 라인'
define view entity ZI_ImpHaulLine
  as select from rseg
    inner join   rbkp    on  rbkp.belnr = rseg.belnr
                         and rbkp.gjahr = rseg.gjahr
    inner join   ekpo    on  ekpo.ebeln = rseg.ebeln
                         and ekpo.ebelp = rseg.ebelp
    inner join   ekko    on  ekko.ebeln = ekpo.ebeln
    inner join   zimp_chgkey as map
                         on  map.bukrs     = rbkp.bukrs
                         and map.cond_type = rseg.cond_type
    left outer join ZI_ImpHaulMove as mv
                         on  mv.PoNo   = rseg.ebeln
                         and mv.PoItem = rseg.ebelp
{
  key rseg.belnr                    as InvoiceNo,
  key rseg.gjahr                    as InvoiceYear,
  key rseg.buzei                    as InvoiceItem,
      rbkp.bukrs                    as Bukrs,
      rbkp.budat                    as PostingDate,
      mv.StorageDays                as StorageDays,
      mv.IsLate                     as IsLate,
      ekko.lifnr                    as Supplier,
      ekpo.matkl                    as MatGrp,
      ekpo.werks                    as Plant,
      rbkp.lifnr                    as Carrier,
      map.cost_kind                 as CostKind,
      @Semantics.amount.currencyCode: 'Waers'
      rseg.wrbtr                    as Amount,
      rbkp.waers                    as Waers,
      @Semantics.quantity.unitOfMeasure: 'Meins'
      rseg.menge                    as Qty,
      rseg.meins                    as Meins
}
where map.valid_from <= rbkp.budat
  and ( map.valid_to is null or map.valid_to >= rbkp.budat )

③ 차원 뷰 — 업체와 입항지에 이름을 붙인다

큐브가 가진 것은 코드뿐이므로 화면에 보이는 이름은 차원 뷰의 텍스트 연결에서 옵니다. 운송·보관 업체는 공급업체 마스터에서, 입항지·보관 방식·운송 거리 구간은 고객사가 정하는 매핑 테이블에서 옵니다. 이 값은 표준 필드에 없어서 확인 필요 항목으로 도입 때 출처를 정합니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZI_ImpHaulCarrier
"  역할  : 운송·보관 업체 차원(코드 + 이름)
"  이렇게 나눈 이유 : 이름 조인을 큐브 안에서 하면 집계 비용이 커진다.
"                    차원 뷰로 빼서 association 으로만 잇는다.
"  확인 필요 : 입항지·보관 방식·운송 거리 구간 차원은 확장 필드 또는
"              매핑 테이블이 출처다. 같은 모양의 차원 뷰를 하나씩 둔다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #DIMENSION
@ObjectModel.representativeKey: 'Carrier'
@EndUserText.label: '운송·보관 업체'
define view entity ZI_ImpHaulCarrier
  as select from lfa1
{
      @ObjectModel.text.element: ['CarrierName']
  key lifnr as Carrier,
      @Semantics.text: true
      name1 as CarrierName
}

④ 큐브 — 비용 4종과 반출 지연·보관 일수를 한 줄에

큐브는 라인을 차원 조합으로 더한 뷰입니다. 하역·보관·운송·수수료를 case 로 갈라 합산하고, 반출 지연 건수와 보관 일수까지 같이 둡니다. 화면의 물류비율·입방미터당 물류비는 여기서 비율로 만들지 않고 분자와 분모를 따로 내려 화면이 합산한 뒤 나눕니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZI_ImpHaulCube
"  역할  : 입항월 × 업체 × 입항지 × 자재그룹 … 별 비용 4종 합계
"  이렇게 나눈 이유 : 비율·단가를 큐브에서 만들면 칸마다 평균이 되어
"                    합계와 어긋난다. 합산 가능한 값만 둔다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@EndUserText.label: '입항 후 물류비 큐브'
@VDM.viewType: #COMPOSITE
define view entity ZI_ImpHaulCube
  as select from ZI_ImpHaulLine as l
  association [0..1] to ZI_ImpHaulCarrier as _Carrier
              on $projection.Carrier = _Carrier.Carrier
{
  key l.Bukrs,
  key substring( l.PostingDate, 1, 6 )          as Period,
  key l.Carrier,
  key l.Supplier,
  key l.MatGrp,
  key l.Plant,
      @Semantics.amount.currencyCode: 'Waers'
      @DefaultAggregation: #SUM
      sum( case l.CostKind when 'HAND'  then l.Amount else 0 end )  as HandAmt,
      @Semantics.amount.currencyCode: 'Waers'
      @DefaultAggregation: #SUM
      sum( case l.CostKind when 'STORE' then l.Amount else 0 end )  as StoreAmt,
      @Semantics.amount.currencyCode: 'Waers'
      @DefaultAggregation: #SUM
      sum( case l.CostKind when 'HAUL'  then l.Amount else 0 end )  as HaulAmt,
      @Semantics.amount.currencyCode: 'Waers'
      @DefaultAggregation: #SUM
      sum( case l.CostKind when 'MISC'  then l.Amount else 0 end )  as MiscAmt,
      @DefaultAggregation: #SUM
      sum( cast( l.StorageDays as abap.int4 ) )                      as StorageDays,
      @DefaultAggregation: #SUM
      sum( case when l.IsLate = 'X' then 1 else 0 end )              as LateCount,
      l.Waers,
      _Carrier
}
group by l.Bukrs, substring( l.PostingDate, 1, 6 ), l.Carrier, l.Supplier,
         l.MatGrp, l.Plant, l.Waers

⑤ 예정 뷰 — 같은 차원 조합에 예정 금액을 얹는다

예정은 전표에서 나오지 않는 유일한 자료입니다. 구매오더 조건에서 예정 물량·단가·보관 일수를 읽어 같은 차원 조합으로 집계합니다. 예정에 없는 입항 라인은 이 뷰에 행이 없으므로 화면이 "미계획 입항" 요인으로 따로 세웁니다. 예정의 원천을 무엇으로 삼을지는 도입 때 가장 먼저 합의할 항목입니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZI_ImpHaulPlan
"  역할  : 구매오더 조건 기준 예정 물류비(물량 × 예정 단가 × 예정 일수)
"  이렇게 나눈 이유 : 실적 큐브와 키를 똑같이 맞추면 차이 계산이
"                    조인 없이 같은 칸끼리의 뺄셈이 된다.
"  보조 테이블 : zimp_plancond 는 구매오더 품목별 예정 물량·단가·일수를
"                적재하는 매핑 테이블(① 과 같은 방식으로 정의).
"  확인 필요 : 예정 단가의 원천(조건 레코드, 계약 단가표)은 고객사 정책.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.dataCategory: #CUBE
@EndUserText.label: '입항 후 물류비 예정'
define view entity ZI_ImpHaulPlan
  as select from ekpo
    inner join   ekko on ekko.ebeln = ekpo.ebeln
    inner join   zimp_plancond as pc
                      on  pc.ebeln = ekpo.ebeln
                      and pc.ebelp = ekpo.ebelp
{
  key ekko.bukrs                        as Bukrs,
  key pc.plan_period                    as Period,
  key pc.carrier                        as Carrier,
  key ekko.lifnr                        as Supplier,
  key ekpo.matkl                        as MatGrp,
  key ekpo.werks                        as Plant,
      @Semantics.amount.currencyCode: 'Waers'
      @DefaultAggregation: #SUM
      sum( pc.plan_qty * pc.plan_rate * pc.plan_days )  as PlanAmt,
      ekko.waers                        as Waers
}
group by ekko.bukrs, pc.plan_period, pc.carrier, ekko.lifnr,
         ekpo.matkl, ekpo.werks, ekko.waers

⑥ 분석 쿼리 — 어떤 축을 기본으로 열 것인가

쿼리는 큐브 위에서 처음 열었을 때의 모습과 필터를 정합니다. 행에는 업체, 열에는 입항월을 두고 회사코드·기간을 필수 필터로 잡습니다. 화면에서 축을 끌어다 놓는 것은 이 기본값을 바꾸는 일이며 쿼리를 다시 만들지 않습니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZC_ImpHaulQuery
"  역할  : 기본 축 · 필수 필터 · 화면 노출 필드
"  이렇게 나눈 이유 : 큐브를 직접 노출하면 필터 없이 전체를 읽는 호출이
"                    생긴다. 쿼리에서 회사코드·기간을 필수로 잡는다.
" ───────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@Analytics.query: true
@EndUserText.label: '입항 후 물류비 분석'
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XL, dataClass: #TRANSACTIONAL }
define view entity ZC_ImpHaulQuery
  as select from ZI_ImpHaulCube
{
      @AnalyticsDetails.query.axis: #FREE
      @Consumption.filter: { selectionType: #SINGLE, mandatory: true }
  key Bukrs,
      @AnalyticsDetails.query.axis: #COLUMNS
      @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
  key Period,
      @AnalyticsDetails.query.axis: #ROWS
  key Carrier,
      @AnalyticsDetails.query.axis: #FREE
  key Supplier,
      @AnalyticsDetails.query.axis: #FREE
  key MatGrp,
      @AnalyticsDetails.query.axis: #FREE
  key Plant,
      @AnalyticsDetails.query.axis: #COLUMNS
      HandAmt,
      @AnalyticsDetails.query.axis: #COLUMNS
      StoreAmt,
      @AnalyticsDetails.query.axis: #COLUMNS
      HaulAmt,
      @AnalyticsDetails.query.axis: #COLUMNS
      MiscAmt,
      StorageDays,
      LateCount,
      Waers
}

⑦ 권한 — 집계 단계에서 플랜트 권한을 건다

권한은 드릴스루가 아니라 큐브 집계 단계에 겁니다. 드릴스루에만 걸면 전사 합계에서 허용된 몫을 빼는 방식으로 남의 플랜트 숫자를 알아낼 수 있습니다. 어떤 권한 객체와 필드를 쓸지는 고객사 역할 설계에 맞춰 확정해야 하므로 아래 예시는 확인 필요 상태의 출발점입니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZI_ImpHaulCube 용 DCL
"  역할  : 구매 오더 플랜트 권한이 있는 사용자만 해당 플랜트 행을 본다
"  이렇게 나눈 이유 : 집계 전에 행을 걸러야 합계가 새지 않는다.
"  확인 필요 : 권한 객체·필드·활동 값은 고객사 역할 설계에 맞춘다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label: '입항 후 물류비 큐브 권한'
@MappingRole: true
define role ZI_ImpHaulCube {
  grant select on ZI_ImpHaulCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

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

마지막으로 쿼리를 서비스로 노출합니다. 서비스 정의에서 무엇을 내보낼지 정하고, 바인딩에서 OData V2 로 게시합니다. 게시 후 화면의 서비스 주소만 바꾸면 샘플 서비스에서 운영 서비스로 옮겨 갑니다. 변동 사유·레이아웃처럼 화면이 쓰는 쪽 엔티티는 같은 서비스에 RAP 로 함께 둘 수 있습니다.

" ───────────────────────────────────────────────────────────────
"  이름  : ZUI_ImpHaul (서비스 정의) / ZUI_ImpHaul_O2 (바인딩)
"  역할  : 분석 쿼리를 OData V2 서비스로 노출
"  이렇게 나눈 이유 : 정의와 바인딩을 나누면 같은 정의를 V2 / V4 로
"                    따로 게시할 수 있다.
" ───────────────────────────────────────────────────────────────
@EndUserText.label: '입항 후 물류비 분석 서비스'
define service ZUI_ImpHaul {
  expose ZC_ImpHaulQuery  as ImpHaulCube;
  expose ZI_ImpHaulCarrier as Carrier;
}

" 바인딩(ADT : 서비스 바인딩 → 새로 만들기)
"   바인딩 유형 : OData V2 - UI   (분석 화면용)
"   서비스 정의 : ZUI_ImpHaul
"   게시 후 확인 : /IWFND/MAINT_SERVICE 에서 활성화 상태

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 코드를 쓰기 전에 합의해야 하는 항목입니다.

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

만드는 쪽에서 먼저 대사식을 세워 샘플 데이터를 전수로 돌린 결과입니다. 사례로 든 총차이 +928.3 백만원(928,259,249원)과 요인 합의 검산도 여기에 들어 있습니다.

의도적 예외 0건. 화면에 표시되는 합계 5,515.9 백만원(5,515,865,626원)은 검증 스크립트의 원천 라인 합계와 같고, 총차이 +928.3 백만원은 요인 합과 같습니다. 화면 쪽은 기능 15개를 따로 실행해 축 전환 때 서버 호출 0회·총합 불변, 드릴스루 칸 10개 일치, 요인분해 검산 0, 변동 사유 새로 고침 후 유지, 에이전트 두 번째 실행 LIMITED 등을 확인했습니다.

운영 데이터로 갈 때

샘플은 큐브 행 14,216개와 예정 행 12,392개라 브라우저가 한 번에 읽어 묶습니다. 운영의 반출 라인이 수백만~수천만 건이면 집계는 CDS 에서 하고 브라우저에는 이미 묶인 큐브 행만 내려보내야 합니다. 조회 기간과 회사코드는 필수 파라미터로 두고, 차원 값 필터는 쿼리 단계로 올리며, 라인 단위 드릴스루는 지금처럼 나눠 읽습니다. 매핑 테이블과 조건 유형·구매오더 품목 키에는 조회 패턴에 맞춘 인덱스를 검토해야 합니다. 응답 시간 기준은 고객사 데이터로 측정해 정할 값이라 이 글에서 숫자로 약속하지 않습니다.

자주 묻는 질문

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

도입 효과와 범위

숫자와 산식

화면과 조작

분석 기능과 AI

운영과 연결