SAP 수입 착지원가 다차원 분석 — 예정 대비 차이를 일곱 요인으로 가르고 B/L 라인까지 내려가는 수입 원가 화면

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

수입 담당과 자금 담당이 마감 때마다 받는 질문은 비슷합니다. 이번 달 착지원가가 예정보다 왜 올랐는지, 환율 때문인지 단가 때문인지 운임 때문인지, 그 숫자를 만든 B/L 이 어느 것인지입니다. 지금은 구매오더 조회(ME23N), 입고(MIGO · MB51), 송장 검증(MIRO · MIR4), 비용 전표(FB03)를 차례로 열고 여기에 운임 · 관세 · 통관 자료를 엑셀로 붙여 맞춥니다. 화면마다 보는 축이 달라 합계가 어긋나면 어느 쪽이 맞는지부터 따지게 됩니다.

이 앱은 그 자리를 이어 붙입니다. B/L 품목 라인을 물품 대가 · 운임 · 관세 · 보험·통관·하역 큐브로 묶어 같은 숫자를 여러 축으로 보고, 칸을 누르면 그 칸을 만든 B/L 라인으로 내려가며, 예정과 실적의 총차이를 일곱 요인으로 가르고 합이 맞는지 매번 검산합니다. IAS 2 재고자산(K-IFRS 제1002호)이 요구하는 취득원가 구성 — 매입가에 운임 · 관세 같은 취득 부대비용을 더하는 구조 — 을 조회와 점검 관점에서 볼 수 있게 했을 뿐, 회계처리나 세무 판단은 하지 않습니다.

핵심 포인트 일곱 가지

사례로 보는 효과

이 샘플 범위(2026.04~2026.09, 가정값 기반 검증용 샘플 데이터)에서 착지원가는 예정 3조 4,773.09억원, 실적 3조 6,397.05억원으로 1,623.95억원(+4.7%) 높았습니다. 총차이만으로는 원인을 알 수 없지만 일곱 요인으로 가르면 순서가 보입니다.

일곱 요인의 합은 총차이와 같고(반올림 차이 제외) 화면의 검산 행이 0원으로 확인합니다. 이 숫자가 어느 B/L 에서 났는지는 칸을 눌러 라인으로 내려가 확인합니다. 모두 검증용 샘플 데이터이며, 요인의 크기는 치환 순서의 영향을 받으므로 해석은 점검 필요 수준으로 읽습니다.

도입하면 달라지는 것

• 마감 준비 — 차이 표 · 요인분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 캡처 붙여넣기가 줄어듭니다.
• 회의의 주제 — "어느 숫자가 맞나" 대신 "이 요인을 어떻게 할 것인가" 를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 되풀이하지 않습니다.
• 놓치는 날이 없는 점검 — 사람이 열지 않아도 규칙에 걸린 항목이 담당 역할의 대기함에 올라갑니다.

이런 회사에 맞습니다

외화 원자재 · 부품을 수입하는 제조 · 유통 회사로, 공급사가 여러 곳이고 통화가 둘 이상이며, 운임 · 관세 · 통관 비용이 별도 전표로 쌓이는 곳에 맞습니다. 수입 구매팀 · 물류팀 · 자금팀 · 원가회계팀이 같은 숫자를 서로 다른 화면과 엑셀로 맞추고 있다면 효과가 큽니다. 반대로 수입 건수가 적고 통화가 하나라면 표준 화면과 엑셀로도 충분할 수 있습니다.

실행 화면 — 검증용 샘플 데이터로 찍은 34종

화면은 모두 검증용 샘플 데이터(가상 공급사 12곳 · 자재 14종 · 6개월)로 실제 브라우저에서 찍었습니다. 거래처 · B/L 번호 · 환율 · 요율은 가정값이며, 화면에 나오는 이름과 번호는 실제 거래와 관계가 없습니다. 이 글은 처음 열었을 때부터 좁은 화면까지 사용 순서대로 보여 줍니다.

사용 방법

1. 조회조건 — 회사코드(필수)와 시작·종료 기간(입고월)을 정합니다. 차원 값은 선택이며 비우면 전체입니다.
2. 조회 — 조회 버튼을 누르거나 입력칸에서 Enter 를 누릅니다. 큐브는 한 번만 읽습니다.
3. 요약 확인 — 임원 요약에서 역할을 바꿔 앞세우는 지표를 바꿉니다. 다시 조회하지 않습니다.
4. 탭 · 축 이동 — 칩을 행 축 · 열 축으로 끌어다 놓거나 화살표 버튼으로 옮기고, 비교를 "예정 대비" 나 "요인 워터폴" 로 바꿉니다.
5. 행 · 셀 클릭 상세 — 행을 펼치고, 숫자 칸을 누르면 그 칸을 만든 B/L 품목 라인이 열립니다. 차이가 큰 행에는 사유를 적습니다.
6. 내보내기 — 피벗과 드릴스루 목록은 CSV 로, AI 분석 결과는 파워포인트 보고서로 내려받습니다. 자주 쓰는 구성은 레이아웃으로 저장합니다.

무엇으로 만들었나

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

화면을 열면 조회조건 · 분석 축 · 임원 요약 · 차트와 피벗이 제자리에 서 있습니다. 조회 전에도 값만 비어 있을 뿐 틀은 그대로라, 처음 여는 사람도 무엇을 고르면 무엇이 채워지는지 먼저 봅니다. 샘플 기본 범위는 회사 1000, 2026.04~2026.09 입니다.

차원 목록과 측정값 정의는 조회조건과 상관없는 목록이라 화면을 열 때 먼저 읽습니다. 그래서 축을 미리 짜 두고 조회할 수 있습니다. 조회 버튼은 조회조건 영역 오른쪽 끝에 있고, 입력칸에서 Enter 를 눌러도 같습니다.

큐브(차원 조합별 집계)는 이때 한 번만 읽습니다. 기본 배치는 행 축 공급사 › 통화, 열 축 입고월입니다. 오른쪽 차트는 표와 같은 데이터를 그린 것이라 표를 읽기 전에 모양부터 눈에 들어옵니다.

조회조건은 회사코드(필수)와 기간, 그리고 차원별 값 선택입니다. 차원 값을 비우면 전체를 뜻합니다. 보드의 칩은 끌어다 놓거나 칩의 화살표 버튼으로 옮길 수 있습니다.

칩을 행 축(최대 3단계)이나 열 축(최대 2단계)에 놓으면 표와 차트가 함께 바뀝니다. 큐브를 이미 읽어 두었기 때문에 요청은 나가지 않습니다. 합계는 어느 축으로 묶어도 같아야 합니다.

축을 짜는 동안에는 펼쳐 두고, 숫자를 들여다볼 때는 접어 둡니다. 접어도 현재 조회 범위와 축 요약은 한 줄로 남아 어떤 조건인지 잃어버리지 않습니다.

경영 요약 — 역할을 바꾸면 앞세우는 숫자가 바뀝니다

같은 큐브를 CFO · 구매 · 물류 · 자금 책임자의 눈으로 다르게 요약합니다. 역할을 바꿔도 다시 조회하지 않고, 앞세우는 지표와 쪼개 보는 차원만 달라집니다.

착지원가 3,639,704.5 백만원, 예정 3,477,309.1 백만원, 차이 +162,395.5 백만원이 맨 앞에 옵니다. 수령 플랜트별로 예정을 넘긴 순서가 아래에 놓이고, 줄어든 쪽이 없으면 "해당 없음" 으로 적습니다. 금액 단위는 백만원이며 화면에서 바꿀 수 있습니다.

구매 책임자 보기는 공급사 기준으로 물품 대가(원화)를 봅니다. 물품 대가 3,432,249.2 백만원(예정 대비 +154,028.5), 관세 142,445.3 백만원, 관세 부담률 4.15% 가 앞에 오고, 아래에 공급사별로 예정을 넘긴 순서가 나옵니다.

물류 책임자 보기는 운송수단 기준으로 운임을 봅니다. 운임 56,174.1 백만원(예정 대비 +1,713.2)이 앞에 오고, 벌크 · 컨테이너 · 항공 순으로 예정을 넘긴 크기가 아래에 나옵니다.

자금 책임자 보기는 통화 기준입니다. 위안 · 달러 · 유로 · 엔 순으로 물품 대가가 예정을 넘긴 크기를 보입니다. 환율 요인은 시점과 환율 유형에 따라 달라지므로 해석은 점검 필요 수준으로 읽습니다.

축 전환과 범위 — 보고 싶은 만큼만 좁힙니다

공급사 · 원산지 · 수령 플랜트 · 운송수단 · 입항지 · 통화 · 인코텀즈 · 자재그룹 · 자재 같은 열한 개 차원을 마음대로 조합합니다. 값 선택은 차원 안에서는 "또는", 차원끼리는 "그리고" 로 묶입니다.

단계가 늘어나도 큐브에서 다시 묶을 뿐이라 응답이 늦어지지 않습니다. 차원 수에는 상한(행 3 · 열 2)이 있고, 넘기려 하면 안내가 뜹니다.

공급사 세 곳과 통화 두 개처럼 골라 담으면 표 위 조건 요약이 바뀝니다. 값 목록은 차원 값 엔티티에서 읽으며, 각 값 옆에 해당 B/L 품목 라인 수가 붙어 있습니다.

합계도 좁힌 범위의 합으로 바뀝니다. 범위를 풀면 처음 합계로 돌아오므로, 좁히는 것은 계산이 아니라 걸러 보기입니다.

공급사 행을 펼치면 통화별 행이 나오고, 각 열은 입고월입니다. 차트도 펼친 행 기준으로 다시 그려집니다. 붉은 숫자는 이 범위에서 점검할 만한 칸입니다.

넓은 표를 볼 때는 차트를 줄이고, 모양이 중요할 때는 차트를 키웁니다. 조절한 너비는 그 브라우저에 남아 다음에 열어도 이어집니다.

칸에서 B/L 까지 — 숫자를 만든 원천 라인을 바로 봅니다

피벗의 숫자 칸을 누르면 그 칸을 만든 B/L 품목 라인이 열립니다. 칸의 값과 읽어 온 라인의 합이 같은지도 그 자리에서 표시합니다.

대화상자 머리에는 칸의 값과 읽은 라인의 합이 나란히 있고, 같으면 녹색 확인 표시가 붙습니다. 라인이 많으면 "71 / 71건 읽음" 처럼 읽은 건수를 알려 줍니다. CSV 로 내려받을 수도 있습니다.

칸마다 조건이 다르므로 열리는 라인이 달라집니다. 조건은 행의 차원 경로와 열 조합이 그대로 조회 조건이 됩니다.

검산 패널은 측정값마다 큐브 합과 라인 합과 차이를 적습니다. 샘플에서는 전부 0 입니다. 차이가 생기면 확인 필요로 표시하고 범위나 단위부터 확인하게 합니다.

계산항목 — 부대비용률처럼 식으로 만든 열

측정값을 더하고 나누어 만든 계산항목을 표 열로 놓을 수 있습니다. 식은 서비스가 정의하고 화면은 같은 식을 칸마다 적용합니다.

선택할 수 있는 계산항목은 부대비용 합계 · 부대비용률 · 착지원가 계산 · 톤당 착지원가 · 관세 부담률 다섯 가지입니다. 부대비용률은 (운임+관세+보험·통관·하역)÷물품 대가×100 입니다. 환급 가능한 수입 부가가치세는 취득원가에 넣지 않으므로 이 식에서 빠져 있고, 회사 기준에 맞는지는 확인 필요입니다. 수량이 0 이면 톤당 값은 표시하지 않습니다.

예정 대비 차이 — 같은 표가 원가 점검 리포트가 됩니다

비교 기준을 "예정" 으로 바꾸면 칸마다 실적 · 예정 · 차이 · 증감률이 붙습니다. 금액과 비율 임계를 둘 다 넘는 칸만 색이 칠해지고, 착지원가가 늘어난 방향은 붉게 표시해 점검 필요 신호로 씁니다.

예정은 구매오더 조건(외화 단가 · 환율 · 요율)으로 계산한 기준 값입니다. 모든 가정은 검증용 샘플 데이터의 가정값입니다. 비교를 바꿔도 다시 조회하지 않습니다.

피벗의 색은 금액과 증감률이 모두 임계 이상일 때만 입힙니다. 줄어든 방향으로 임계를 넘으면 초록으로 표시해 단가나 환율 반영이 맞는지 확인 필요로 알려 줍니다. 워터폴은 예정 조건에서 실적 조건으로 한 가지씩 바꿔 가며 같은 식으로 다시 계산하는 순차 치환이라 합이 총차이와 정확히 같고, 맨 위 "검산: 요인 합 − 총차이 = 0원" 이 매번 표시됩니다. 요인의 크기는 순서의 영향을 받으므로 해석은 점검 필요 수준입니다.

사유의 키는 축 배치가 아니라 조회 범위와 행 경로입니다. 그래서 축을 바꾸거나 행을 다시 펼쳐도 같은 행이면 사유가 따라옵니다.

사유는 서비스의 사유 엔티티셋에 쌓이므로 화면을 닫아도 남습니다. 다음 달에 같은 범위를 열면 지난달 사유가 보입니다.

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

AI 분석은 지금 보고 있는 범위를 읽어 줍니다. 금액과 비율은 서비스가 큐브에서 계산해 근거로 넘기고, 모델은 그 숫자를 읽어 설명만 합니다. 모델을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다.

해설 문장마다 어느 행(경로)과 어느 금액에서 나왔는지 근거가 따라붙습니다. 기본은 규칙 기반이며 모델 연결은 서비스 설정에서만 켭니다.

해설에 적힌 숫자를 이 표에서 그대로 확인할 수 있습니다. 표와 차트를 담은 파워포인트 보고서(표지 · 요약 · 핵심 발견 · 차트 · 표 · 근거)도 이 화면에서 내려받습니다.

AI 에이전트 — 규칙이 곧 받을 사람

감시 규칙 다섯 개가 임계값과 받을 역할을 함께 들고 있습니다. 규칙에 걸리면 대기함에 역할별 보고가 올라가고, 하루에 한 번만 도는 제한과 활동 기록이 서버에 남습니다.

규칙마다 대상 역할(CFO · 자금 · 물류 · 구매)과 임계값, 사용 스위치가 있고 화면에서 고쳐 저장합니다. 화면을 열어 둔 동안 한 시간마다 실행하는 스위치가 맨 위에 있습니다(기본 꺼짐).

각 보고는 제목 · 받을 역할 · 근거 금액을 갖고, 받은 사람이 사유를 확인합니다. 보고는 판단이 아니라 점검 요청입니다.

실행하면 대기함에 새 보고가 올라가고 활동 기록에 실행 행이 남습니다. 판정과 기록은 화면이 아니라 서비스에 있어, 사람이 자리에 없을 때는 배치가 같은 호출을 할 수 있습니다.

하루 한 번 제한도 서버 기록이 판정합니다. 화면에서 여러 번 눌러도 같은 날 같은 보고가 쌓이지 않습니다.

호출한 주체(사용자 · 배치)와 시각, 결과 상태가 한 줄씩 쌓입니다. 감사에서 자동 점검이 실제로 돌았는지 보여 줄 때 씁니다.

레이아웃 저장과 복원 — 자주 쓰는 구성을 이름으로

짜 둔 축과 표시 항목을 이름을 붙여 저장하고, 기본 레이아웃과 자동 조회로 지정할 수 있습니다.

기본 레이아웃으로 지정하면 열 때 그 배치로 시작하고, 자동 조회를 켜면 열자마자 조회된 상태입니다. 저장 값은 서비스의 레이아웃 엔티티셋에 남습니다.

부서마다 자주 보는 축이 다르므로 레이아웃을 여러 개 두고 골라 씁니다. 복원 확인은 새로 고침 뒤 같은 배치가 나오는지로 봤습니다.

좁은 화면과 한계 — 휴대폰에서도 같은 리포트

창이 좁으면 차트를 감추지 않고 표 아래로 내려 같은 리포트를 봅니다. 한계는 한계대로 화면에 알려 줍니다.

가로 스크롤 없이 조회조건 · 요약 · 표가 위에서 아래로 놓입니다. 표가 폭을 넘으면 표 영역 안에서 가로로 움직입니다.

차트는 표 아래로 내려오고, 버튼은 손가락으로 누르기 쉬운 크기로 유지됩니다. 상세 대화상자도 화면 폭에 맞춰 열립니다.

행은 3단계, 열은 2단계까지입니다. 넘기려 하면 토스트로 한도를 알려 주고 배치는 바뀌지 않습니다. 열 축 한도 경고 문구는 운영 환경에서 확인 필요로 남겨 둡니다.

화면 뒤에서 일어나는 일

화면이 서비스를 부르는 때를 단계로 풀면 아래와 같습니다. 조회는 큐브를 한 번 읽는 것이 전부이고, 축을 바꿔도 서버를 다시 부르지 않습니다.

판정 조건 → 결과 상태 → 사용자 조치

요인분해 처리 단계와 대사식

1. 예정 조건(외화 단가 · 환율 · 요율 · 수량)에서 시작해 한 가지씩 실적 조건으로 바꿔 가며 같은 식으로 착지원가를 다시 계산합니다.
2. 바꿀 때마다 늘어난 착지원가가 그 요인의 몫입니다. 순서는 물량 → 외화 단가 → 환율 → 운임 → 관세율 → 보험·통관·하역 → 미계획 입고입니다.
3. 착지원가 = 물품 대가 + 운임 + 관세 + 보험·통관·하역, 부대비용률 = 부대비용 합계 ÷ 물품 대가 × 100.
4. 대사식: 큐브 칸 합 = 같은 조건의 B/L 품목 라인 합, 일곱 요인의 합 = 총차이(검산 행).

요인의 크기는 치환 순서의 영향을 받으므로, 해석은 점검 필요 수준으로 읽고 순서가 달라지면 크기가 달라질 수 있음을 알고 보아야 합니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

폭이 600px 보다 좁으면 조회조건 · 요약 · 표가 위에서 아래로 쌓이고, 차트는 표 아래로 내려옵니다. 큰 피벗은 표 영역 안에서만 가로로 움직이며 페이지 전체에는 가로 스크롤이 생기지 않습니다. 대화상자도 화면 폭에 맞춰 열립니다.

파일 구성

index.html · Component.js · manifest.json
controller/   화면 제어 (Main · 공통 BaseController)
view/         Main 뷰 · 조각 뷰(AI 분석 · 에이전트 · 드릴스루 · 레이아웃 · 사유)
model/        큐브 재집계 · 차트 · 레이아웃 · 서식 · 보고서(pptx) 생성 · 오류 처리
css/ · i18n/  스타일 · 문구
odata/        서비스 정의 · 구현 · 샘플 데이터 (모델 구성 수준으로만 소개)

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

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회 · 검증 관점을 더해 확장합니다. 표준 데이터 구조를 그대로 이어받아 같은 테이블 · 같은 필드를 읽습니다.

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

T-code 별 연계 지점

오가는 방법 — 이 앱에서 의심스러운 칸을 눌러 B/L 라인을 열고, 라인의 구매오더 · 입고 문서 · 송장 · 비용 전표를 위 표준 T-code 로 원천 확인합니다. 반대로 표준 화면에서 본 금액은 이 앱에서 같은 공급사 · 입고월 칸을 열어 다시 봅니다. 표준에 남겨 둘 일 — 원가 확정 · 전기 · 법정 · 공시 · 세무 신고 대응은 표준에 남기고, 운영 전환 때 기존 표준 리포트를 없앨 필요는 없습니다. 둘을 나란히 두고 대사하며 쓰는 것이 기본입니다.

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

S/4HANA 의 표준 분석 쿼리와 Fiori 분석 앱, Analysis for Office 는 표준 데이터 모델 위에서 재고 · 구매 · 자금 관점을 폭넓게 다루는 도구입니다. 이 화면은 그것들을 대체하는 것이 아니라, 수입 착지원가라는 한 주제에서 차원을 자유롭게 바꾸고 예정과의 차이를 요인으로 가르는 자리를 더합니다. 운영 환경의 표준 CDS 분석 쿼리나 Fiori 앱 중 쓸 수 있는 것이 있는지는 확인 필요이며, 확인하지 못한 앱 이름은 적지 않았습니다.

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

분석 지표 정의

CDS 구성 — 코드와 운영에서 할 일

아래 CDS 는 실제로 만들 구조를 보이는 설계 코드입니다. 표준 뷰 이름은 환경마다 달라 원천 테이블 기준으로 적었고, 실제 필드 연결과 표준 CDS 뷰 사용 여부는 확인 필요입니다.

뷰 레이어 구성

① 비용 구분 매핑 테이블 — 무엇이 운임이고 무엇이 관세인가

부대비용을 어느 조건 유형 · 계정이 어느 비용 구분인지 데이터로 두는 곳입니다. 여기서 착지원가의 구성이 결정되고, 운영에서 가장 먼저 합의해야 하는 표입니다.

" ───────────────────────────────────────────────────────────────
" ZIMP_COSTMAP — 수입 부대비용 구분 매핑 (DDIC 투명 테이블)
" 역할  : 구매 조건 유형 · 비용 전표 계정 → 비용 구분(운임/관세/기타)
" 왜    : 분류는 회사마다 다르고 자주 바뀌므로 코드에 박지 않는다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수입 부대비용 구분 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_costmap {
  key client    : abap.clnt not null;
  key cost_src  : abap.char(1) not null;   " C=구매 조건 유형, A=비용 전표 계정
  key cost_key  : abap.char(10) not null;  " 조건 유형 또는 계정 번호
  cost_class    : abap.char(3) not null;   " FRT 운임 · DTY 관세 · OTH 보험/통관/하역
  alloc_basis   : abap.char(1);            " 배부 기준 Q 수량 · V 금액 · W 중량 (확인 필요)
  valid_from    : abap.dats;
}

② B/L 품목 라인 뷰 — 모든 집계의 바닥

구매오더 품목 · 입고 문서 · 송장 · 비용 전표를 B/L 품목 한 줄로 모읍니다. 드릴스루가 읽는 곳이며 큐브는 이 뷰만 바라봅니다. 표준 뷰 이름은 환경마다 달라 원천 테이블 기준으로 적었고, 실제 연결 필드는 확인 필요입니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImportLandedItem — B/L 품목 한 줄 (문서 흐름 뷰)
" 역할  : EKPO · MSEG · 비용 전표 → 품목 단위 착지원가 구성
" 왜    : 큐브 · 드릴스루가 같은 바닥을 보게 해 합계를 일치시킨다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 B/L 품목 라인'
define view entity ZI_ImportLandedItem
  as select from ekpo as po
    inner join   mseg as gr on  gr.ebeln = po.ebeln
                            and gr.ebelp = po.ebelp
                            and gr.bwart = '101'
{
  key po.ebeln                      as PurchaseOrder,
  key po.ebelp                      as PurchaseOrderItem,
  key gr.mblnr                      as MaterialDocument,
  po.werks                          as Plant,
  po.matnr                          as Material,
  po.matkl                          as MaterialGroup,
      @Semantics.quantity.unitOfMeasure : 'BaseUnit'
  gr.menge                          as Quantity,
  gr.meins                          as BaseUnit,
      @Semantics.amount.currencyCode : 'DocCurrency'
  cast( gr.dmbtr as abap.curr(23,2) ) as GoodsAmountLocal,
  gr.waers                          as DocCurrency
  // 운임·관세·부대비용은 ZIMP_COSTMAP 으로 분류한 비용 전표를 association 으로 붙임(생략)
}

③ 큐브 뷰 — 집계가 일어나는 단 한 곳

차원 조합별 물품 대가 · 운임 · 관세 · 기타를 합산합니다. 환산(통화)과 합산 위치를 여기에 고정해야 분석 쿼리가 몇 개가 되어도 합계가 같습니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImportLandedCube — 차원 조합별 착지원가 집계
" 역할  : 품목 라인을 공급사 · 월 · 통화 · 자재 단위로 합산
" 왜    : 집계 위치를 하나로 고정해 합계 불일치를 막는다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@ObjectModel.usageType : { serviceQuality : #D, sizeCategory : #XL, dataClass : #TRANSACTIONAL }
@EndUserText.label : '수입 착지원가 큐브'
define view entity ZI_ImportLandedCube
  as select from ZI_ImportLandedItem as it
{
  key it.Plant,
  key it.Material,
  key it.PostingMonth,
  key it.DocCurrency,
      @Semantics.amount.currencyCode : 'DocCurrency'
      @DefaultAggregation : #SUM
      sum( it.GoodsAmountLocal )                         as GoodsAmount,
      @DefaultAggregation : #SUM
      sum( case it.CostClass when 'FRT' then it.CostAmount else 0 end ) as FreightAmount,
      @DefaultAggregation : #SUM
      sum( case it.CostClass when 'DTY' then it.CostAmount else 0 end ) as DutyAmount,
      @DefaultAggregation : #SUM
      sum( case it.CostClass when 'OTH' then it.CostAmount else 0 end ) as OtherAmount,
      @DefaultAggregation : #SUM
      sum( it.Quantity )                                 as Quantity
}
group by it.Plant, it.Material, it.PostingMonth, it.DocCurrency

④ 예정 큐브 — 같은 차원의 비교 기준

실적 큐브와 같은 차원 키로 예정 값을 만듭니다. 키가 같아야 칸마다 차이가 계산됩니다. 예정이 없는 라인은 미계획 입고 요인으로 따로 분리하는 근거가 됩니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImportPlanCube — 예정 착지원가 (구매오더 조건 기준)
" 역할  : 구매오더 예정 조건으로 계산한 예정 착지원가를 같은 키로 집계
" 왜    : 실적 큐브와 키가 같아야 칸 단위 차이가 나온다
" ───────────────────────────────────────────────────────────────
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수입 예정 착지원가 큐브'
define view entity ZI_ImportPlanCube
  as select from ZI_ImportPlanItem as pl
{
  key pl.Plant,
  key pl.Material,
  key pl.PostingMonth,
  key pl.DocCurrency,
      @DefaultAggregation : #SUM
      sum( pl.PlanGoodsAmount )  as PlanGoodsAmount,
      @DefaultAggregation : #SUM
      sum( pl.PlanFreight )      as PlanFreight,
      @DefaultAggregation : #SUM
      sum( pl.PlanDuty )         as PlanDuty
}
group by pl.Plant, pl.Material, pl.PostingMonth, pl.DocCurrency

⑤ 분석 쿼리 — 화면이 읽는 소비 층

필터와 표시 항목, 계산항목(부대비용률)을 선언합니다. 화면의 조회조건과 이 쿼리의 필터가 짝을 이룹니다.

" ───────────────────────────────────────────────────────────────
" ZC_ImportLandedCostQuery — 분석 쿼리(소비 층)
" 역할  : 큐브 위에 필터 · 표시 항목 · 계산항목을 선언
" 왜    : 화면 조건이 바뀌어도 큐브는 건드리지 않는다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '수입 착지원가 다차원 분석'
define view entity ZC_ImportLandedCostQuery
  as select from ZI_ImportLandedCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, mandatory : true }
  key Plant,
  @AnalyticsDetails.query.axis : #ROWS
  key Material,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Consumption.filter.selectionType : #INTERVAL
  key PostingMonth,
  @Consumption.filter.hidden : true
  key DocCurrency,
  @AnalyticsDetails.query.axis : #COLUMNS
  GoodsAmount,
  FreightAmount,
  DutyAmount,
  OtherAmount,
  @AnalyticsDetails.query.formula : '(FreightAmount + DutyAmount + OtherAmount) / GoodsAmount * 100'
  @EndUserText.label : '부대비용률(%)'
  cast( 0 as abap.dec(9,2) ) as AdditionalCostRate
}

⑥ 접근 제어 — 합계로 새지 않게 집계 단계에서

회사코드 · 플랜트 권한은 드릴스루에만 걸면 안 됩니다. 합계에서 자기 몫을 빼면 남의 숫자가 드러나기 때문입니다. 집계 뷰에서 같은 조건으로 막습니다.

" ───────────────────────────────────────────────────────────────
" ZC_ImportLandedCostQuery — 접근 제어(DCL)
" 역할  : 플랜트 권한 객체(M_BEST_WRK 계열)로 조회 제한 (객체명 확인 필요)
" 왜    : 드릴스루만 막으면 합계 − 자기 몫 으로 남의 숫자가 보인다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수입 착지원가 접근 제어'
@MappingRole : true
define role ZC_ImportLandedCostQuery {
  grant select on ZC_ImportLandedCostQuery
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑦ 서비스 정의와 바인딩 — 화면이 부르는 입구

쿼리를 OData V2 서비스로 노출합니다. 운영에서는 이 서비스를 활성화(/IWFND/MAINT_SERVICE)하고, 화면 매니페스트의 서비스 주소를 이 서비스로 바꿉니다.

" ───────────────────────────────────────────────────────────────
" ZUI_ImportLandedCost — Service Definition / Binding
" 역할  : 쿼리 · 큐브 · 품목 라인을 OData 로 노출
" 왜    : 화면은 서비스 주소만 알면 되고 CDS 구조는 몰라도 된다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수입 착지원가 서비스'
define service ZUI_ImportLandedCost {
  expose ZC_ImportLandedCostQuery as LandedCostQuery;
  expose ZI_ImportLandedItem      as LandedItem;
  expose ZI_ImportPlanCube        as PlanCube;
}
" Service Binding: ZUI_ImportLandedCost_V2  (바인딩 유형 OData V2 - UI)
" 게시 후 서비스 활성화는 /IWFND/MAINT_SERVICE 에서 확인

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래 열한 가지는 코딩이 아니라 합의이고, 정하지 않으면 첫 회의에서 막히는 것들입니다.

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

예정 3조 4,773.09억원과 실적 3조 6,397.05억원의 차이 1,623.95억원을 가른 위 사례와 같은 데이터에서 대사식을 전수로 돌렸습니다.

의도적 예외 — 예정이 없는 입고 라인 50개(착지원가 26,101,728,865원)는 미계획 입고 요인으로 따로 세웠고 위 차이 건수와 별개입니다. 모두 검증용 샘플 데이터 기준입니다.

운영 데이터로 갈 때

운영 데이터는 B/L 품목 라인이 수천만 건까지 갈 수 있습니다. 이때는 큐브 집계를 화면이 아니라 CDS(또는 HANA 쪽)에서 하고, 회사코드와 기간을 필수 파라미터로 고정해 읽는 범위를 좁히며, 조회 키 필드에 인덱스를 두고, 큐브를 한 번 읽어 재집계하는 현재 방식이 감당할 행 수(차원 조합 수만~수십만)를 응답 시간 기준으로 정합니다. 상한을 넘으면 기간을 나누어 읽거나 사전 집계 테이블을 두는 선택을 합니다. 구체 수치는 운영 환경에서 측정해 정해야 하며 현재는 확인 필요입니다.

자주 묻는 질문

궁금해하시는 질문을 주제별 네 묶음으로 나눠 적었습니다. 모든 숫자는 검증용 샘플 데이터 기준입니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영