SAP 수입 솔루션 수입 원가 경쟁력 분석 — 공급사·원산지·자재·운송수단을 끌어다 놓고 예정 원가 대비 차이의 원인까지 내려가는 화면

개발 배경 — 이 앱을 사용해야 하는 이유

수입 담당자가 매달 받는 질문은 대개 둘입니다. 이번 달 수입 원가가 왜 예정보다 올랐는가, 그리고 어느 공급사와 어느 원산지가 비싼가. 구매오더 조회(ME23N), 입고 처리(MIGO), 자재 문서 목록(MB51), 송장 검증(MIRO), 평가 차이 조정(MR11), 공급사 개별 항목(FBL1N) 같은 SAP 표준 화면은 문서 하나하나를 정확히 보여 줍니다. 하지만 공급사 × 원산지 × 자재 × 운송수단이라는 단면으로 물대와 운임·관세·부대비용을 합쳐 비교하는 일은 문서를 내려받아 엑셀로 맞추는 수작업이 됩니다.

이 화면은 선하증권 품목 라인을 큐브로 묶고, 차원을 끌어다 놓는 것만으로 같은 숫자를 여러 단면으로 보게 합니다. 칸을 누르면 그 금액을 만든 원천 라인까지 내려가고, 예정 원가와 비교하면 차이가 여섯 요인으로 나뉩니다. 이 화면은 특정 회계기준서에 묶인 화면이 아니라 수입 원가 분석이라는 업무 영역의 분석 화면이며, 아래 숫자는 모두 가상으로 만든 검증용 샘플입니다.

가장 싼 단가의 공급사가 가장 싼 공급사는 아니다

단가표에는 물대만 있습니다. 실제로 창고에 들어올 때의 원가는 운임, 보험료, 관세, 통관수수료, 하역비가 얹힌 착지원가입니다. 샘플에서 공급사별 부대비용률(부대비용÷물대)은 5.1%에서 16.0% 사이로 갈립니다. 같은 자재라도 부대비용이 큰 공급사는 물대가 낮아도 수입 원가가 높아질 수 있어서, 공급사 비교는 물대가 아니라 수입 원가와 단위원가로 해야 합니다.

이 화면은 부대비용 합계, 수입 원가, 부대비용률, 단위원가를 계산항목으로 붙여 두었고, 비율은 합산한 뒤에 계산해 소계 행에서도 맞습니다.

원산지와 운송수단이 바뀌면 같은 자재의 원가 구조가 달라진다

샘플에서 예정 대비 차이가 가장 큰 원산지는 일본(+3.44억)이고, 운송수단별 부대비용률은 해상 10.8%, 항공 10.9%, 철도·내륙 16.8%로 다릅니다. 원산지에 따라 관세 적용이 달라질 수 있고 운송수단에 따라 운임이 달라지므로, 공급사만 보는 표로는 원가가 어디서 달라졌는지 가려지지 않습니다. 행 축에 공급사 대신 원산지나 운송수단을 올려 놓기만 하면 같은 큐브가 다른 질문의 답이 됩니다.

예정과 어긋난 금액이 어느 요인에서 생겼는지 찾는 데 하루가 걸린다

샘플의 수입 원가는 133.33억으로 예정 원가 125.01억보다 +8.32억(+6.7%) 높습니다. 표준 화면은 여기까지 말해 줍니다. 이 화면은 그 차이를 물량 +1.49억, 외화 단가 +3.38억, 환율 +1.78억, 운임 +0.93억, 관세 +0.68억, 기타 부대비용 +0.06억으로 가르고, 여섯 요인의 합이 총차이와 1원도 어긋나지 않는지 매번 검산합니다. 이 샘플에서는 물량이 아니라 외화 단가와 환율이 차이의 가장 큰 몫입니다.

표를 여러 벌 만들면 합계가 갈라진다

공급사별 표, 원산지별 표, 월별 표를 따로 만들면 합계가 서로 어긋나는 일이 생기고, 어긋난 이유를 찾는 회의가 열립니다. 이 화면의 모든 표와 차트는 같은 큐브를 브라우저에서 다시 묶은 것이라 축을 바꿔도 합계가 달라지지 않습니다.

사용 방법

1. 조회 조건 — 회사코드(필수)와 시작·종료 기간을 고릅니다. 공급사·원산지·자재 같은 값 선택은 선택 사항이며 비우면 전체입니다.
2. 조회 — 조회 조건 영역 오른쪽 끝의 조회 버튼을 누르거나 입력칸에서 Enter 키를 누릅니다.
3. 요약 확인 — 역할(재무·구매·물류·자금 책임자)을 바꾸면 앞세우는 지표가 바뀝니다. 다시 조회하지 않습니다.
4. 탭·축 이동 — 사용 가능 칸의 칩을 행 축(최대 3)과 열 축(최대 2)으로 끌어다 놓거나 화살표 버튼으로 옮깁니다. 표와 차트가 바로 바뀝니다.
5. 행·셀 클릭 상세 — 행을 펼쳐 하위 차원으로 내려가고, 값 칸을 누르면 그 금액을 만든 선하증권 품목 라인이 열립니다. 칸 금액과 라인 합계가 같은지 머리 줄에 나옵니다.
6. 예정 대비 차이 — 비교를 예정 대비 차이로 바꾸면 칸마다 차이가 나오고, 행 이름을 누르면 그 범위의 요인 워터폴이 그려집니다. 사유는 사유 버튼에서 적습니다.
7. AI 분석·에이전트 — AI 분석으로 해설과 근거를 읽고, 에이전트의 규칙 임계를 고쳐 지금 실행합니다.
8. 내보내기·저장 — 피벗 표와 원천 라인은 CSV 로, 해설은 PowerPoint 보고서로 내려받고, 짜 둔 화면은 이름을 붙여 레이아웃으로 저장합니다.

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

이 화면에서 가장 비싼 질문은 이 숫자가 맞느냐입니다. 만드는 쪽에서 먼저 대사식을 세워 전수로 돌렸고, 화면 쪽은 따로 자동화로 돌려 축을 바꿔도 합계가 변하지 않는지, 칸 금액과 라인 합계가 같은지를 다시 잽니다.

의도적 예외는 0건입니다. 단일 통화로 환산한 금액만 합산하며 통화별 외화 금액은 합산하지 않습니다.

무엇으로 만들었나

실행 화면

검증용 샘플 데이터로 실제 브라우저에서 찍은 화면 32종입니다. 사용 순서대로 묶었고, 화면을 누르면 크게 볼 수 있습니다. 화면 속 공급사·자재·문서번호는 모두 가상입니다.

처음 열었을 때

화면은 조회 조건과 분석 축 선택으로 시작합니다. 조회 전에도 어떤 차원이 있는지 보입니다.

화면을 열면 조회 조건, 사용 가능한 차원 칩, 행 축과 열 축 칸이 한 줄로 이어져 있습니다. 조회 버튼은 조건 영역 오른쪽 끝에 있고 입력칸에서 Enter 키를 눌러도 같습니다. 기본값은 회사코드 1000(샘플)과 2026.01~2026.09이며, 공급사·원산지 같은 값 선택은 비워 두면 전체입니다.

축 전환과 범위

같은 큐브를 어떤 축으로 보든 합계는 같습니다. 축은 끌어다 놓고, 범위는 값을 골라 좁힙니다.

행에 공급사와 자재, 열에 회계기간을 놓으면 칸마다 물대·부대비용이 합쳐진 수입 원가가 나옵니다. 왼쪽 막대는 같은 범위의 공급사별 수입 원가이며 단위는 백만원입니다. 이 숫자는 모두 같은 큐브에서 다시 묶인 것이라 축을 바꿔도 합계가 달라지지 않습니다.

축 바꾸기 버튼을 누르면 행 축과 열 축이 서로 자리를 옮깁니다. 이미 읽어 둔 큐브를 브라우저에서 다시 묶기 때문에 응답을 기다리지 않습니다. 같은 합계를 다른 방향에서 보는 용도라 공급사끼리 월별 흐름을 나란히 비교할 때 씁니다.

행 축은 최대 3단계, 열 축은 최대 2단계까지 겹칠 수 있습니다. 열 조합은 36개, 행은 1,500개를 넘으면 범위를 좁히라는 안내가 나옵니다. 행 이름 옆 화살표로 하위 차원까지 내려가며 소계는 항상 위 행에 붙어 있습니다.

차원 이름 옆 값 선택 칸을 누르면 값 목록과 선택 상태가 한꺼번에 열립니다. 같은 차원 안에서는 또는(or), 다른 차원끼리는 그리고(and)로 묶입니다. 값 옆 라인 수를 보면 어느 공급사와 원산지에 선적이 몰려 있는지 조회 전에 짐작할 수 있습니다.

공급사와 운송수단처럼 여러 차원에서 값을 고르면 칩으로 남고, 적용을 누르면 조건에 반영됩니다. 선택 해제를 누르면 한 번에 비워 전체 범위로 돌아갑니다. 조건을 바꾼 뒤에는 조회 버튼으로 새 범위를 읽습니다.

필터를 적용하면 표와 차트의 모든 합계가 같은 범위로 줄어듭니다. 합계가 범위마다 새로 계산되므로 화면 합계와 선택 범위의 원천 라인 합계가 어긋날 자리가 없습니다. 범위 밖 행은 숨기는 것이 아니라 읽지 않습니다.

계산항목과 단계 보기

표에서 바로 쓰는 계산항목과 앞 열 대비 증감 보기를 소개합니다.

부대비용 합계, 수입 원가, 부대비용률, 단위원가가 계산항목으로 붙어 있습니다. 비율은 칸마다 나눗셈을 먼저 하지 않고 분자와 분모를 합산한 뒤에 계산합니다. 그래서 소계 행의 부대비용률이 하위 행 비율의 평균이 아니라 소계 금액에서 다시 구한 값이 됩니다.

비교를 끈 상태에서 단계 보기를 켜면 첫 열은 그대로 두고 다음 열부터 앞 열 대비 증감이 나옵니다. 차트도 열 묶음별 막대로 바뀌어 분기 사이에 갑자기 올라간 공급사를 찾을 때 씁니다. 차이 모드와 달리 색은 칠하지 않습니다.

예정 대비 차이

비교 기준을 예정 원가로 바꾸면 같은 표가 원가 차이 리포트가 됩니다. 차이는 여섯 요인으로 나뉩니다.

비교를 예정 대비 차이로 바꾸면 칸에 실적과 예정의 차이가 붙습니다. 금액 임계와 비율 임계를 둘 다 넘은 칸만 원가 증가는 붉은색, 감소는 초록색으로 칠하고 금액만 넘으면 주황색입니다. 임계는 조회 조건 영역에서 직접 고치며 기본값은 샘플을 위한 가정값입니다.

행 축을 원산지 › 공급사로 바꾸고 모두 펼침을 누르면 원산지별 차이 아래에 공급사가 펼쳐집니다. 일본, 중국, 독일처럼 원산지 단위로 예정과의 차이를 먼저 보고 어느 공급사가 그 몫을 만드는지 내려갑니다. 왼쪽 워터폴은 전체 범위의 여섯 요인이며 합이 총차이와 같은지 검산 줄이 적습니다.

행 이름을 누르면 그 범위의 예정 원가에서 실적 원가까지를 물량, 외화 단가, 환율, 운임, 관세, 기타 부대비용으로 나눈 워터폴이 그려집니다. 차트 위 검산 줄이 요인 합과 총차이의 차이를 매번 적으며 정상일 때 0원입니다. 전체 범위로 버튼으로 언제든 처음 범위로 돌아옵니다.

차이 모드에서 차트는 공급사별 차이 막대로 바뀝니다. 오른쪽으로 길수록 예정보다 원가가 늘었다는 뜻이고 왼쪽 막대는 줄어든 쪽입니다. 표에서 훑은 순서와 같은 눈으로 읽을 수 있어 회의에서 말로 설명할 때 부담이 줄어듭니다.

칸에서 원천 라인까지

숫자를 누르면 그 금액을 만든 선하증권 품목 라인이 열립니다.

피벗의 값 칸을 누르면 그 칸을 이루는 선하증권 품목 라인이 대화상자로 열립니다. 칸의 행 경로와 열 조합이 그대로 조회 조건이 되어 따로 조건을 다시 넣을 필요가 없습니다. 라인은 일정 단위로 읽으며 더 읽기와 모두 읽기, CSV 내려받기를 쓸 수 있습니다.

다른 공급사와 다른 분기의 칸을 열어도 같은 대조가 나옵니다. 이 칸은 라인 159건을 모두 읽었고 칸의 값과 읽은 라인의 합이 같아 일치로 표시됩니다. 라인을 다 읽지 않은 칸은 일부만 읽었다고 알려 주므로 더 읽기나 모두 읽기로 이어서 맞춥니다.

변동 사유

차이가 난 이유는 숫자 옆에 남겨 둡니다.

차이 모드의 사유 버튼에서 요인 구분과 내용을 적어 저장합니다. 사유는 조회 범위와 행 경로에 묶여 남기 때문에 축을 바꾸거나 트리를 다시 펼쳐도 같은 행이면 따라옵니다. 수정과 삭제도 같은 창에서 합니다.

저장한 사유가 있는 행에는 표시가 붙어 사유가 비어 있는 차이 행을 바로 가려낼 수 있습니다. 사유는 CSV와 AI 분석의 근거 표에도 함께 실립니다. 다음 달 같은 범위를 열 때 지난달 답을 메일함에서 찾을 필요가 없습니다.

경영 요약

같은 데이터를 재무·구매·물류·자금 책임자의 질문으로 나누어 읽습니다.

역할 선택에서 재무 책임자를 고르면 수입 원가 총액, 예정 대비 차이, 부대비용률 같은 지표가 앞에 오고 행 축도 그에 맞게 바뀝니다. 다시 조회하지 않고 이미 읽은 큐브를 다시 묶을 뿐입니다. 같은 숫자를 역할마다 다른 질문으로 읽는 화면입니다.

구매 책임자 역할에서는 단위원가, 물대, 수입 원가, 부대비용률이 위에 오고 자재별 단위원가의 예정 초과 상위와 절감 상위가 나란히 나옵니다. 아래 피벗은 행 축이 자재로 바뀌어 월별 단위원가 차이를 보여 줍니다. 어느 자재의 단위원가가 얼마나 올랐는지가 협상의 출발점이 됩니다.

물류 책임자 역할에서는 운임, 보험료, 부대비용률, 수량이 위에 오고 운송수단별 운임의 예정 초과 상위가 나옵니다. 아래 피벗은 행 축이 운송수단으로 바뀌어 항공·해상·철도·내륙의 월별 차이를 비교합니다. 운임이 예정보다 얼마나 올랐는지는 같은 화면의 차이 모드와 이어집니다.

자금 책임자 역할에서는 물대와 관세가 위에 오고 통화별 물대의 예정 초과 상위와 절감 상위가 나옵니다. 아래 피벗은 행 축이 통화로 바뀌어 외화별 월별 차이를 보여 줍니다. 환율 영향은 요인 워터폴의 환율 막대와 함께 읽으며 임계를 넘으면 감시 규칙에도 걸립니다.

AI 분석과 보고서

숫자는 서비스가 계산하고 모델은 설명만 합니다.

AI 분석 버튼을 누르면 지금 보고 있는 범위의 요약과 점검 대상이 문장으로 나옵니다. 금액과 비율은 서비스가 큐브에서 계산해 넘기고 문장은 그 숫자만 인용하므로 모델이 새 숫자를 만들 수 없습니다. 모델 연결을 끄면 같은 숫자의 규칙 기반 해설이 나옵니다.

해설 아래 근거 표에는 점검 대상의 건수와 예정·실적 금액이 행별로 적혀 있습니다. 문장을 읽다가 의심이 들면 근거 표의 행과 비교하면 됩니다. 근거 행을 누르면 그 행 범위로 피벗이 맞춰집니다.

PPTX 보고서 버튼은 요약, 핵심 발견, 표와 차트, 근거를 담은 파일을 브라우저 안에서 만들어 내려받게 합니다. 외부 서비스로 숫자를 보내지 않으며 화면에서 보던 범위가 그대로 문서가 됩니다. 결재용 자료를 캡처와 복사로 다시 만드는 시간이 사라집니다.

AI 에이전트

사람이 화면을 열지 않아도 감시 규칙을 돌려 보고를 올립니다.

부대비용률 상한, 환율 영향, 관세 초과, 같은 자재의 공급사 단위원가 격차, 운임 초과 다섯 규칙이 기본으로 있고 임계는 화면에서 고칩니다. 규칙마다 받을 사람의 역할이 붙어 있어 걸리면 그 사람의 눈으로 숫자를 다시 적어 보고합니다. 켜고 끄는 것도 규칙 단위입니다.

지금 실행하면 규칙에 걸린 범위가 보고로 대기함에 올라옵니다. 보고에는 받을 사람, 걸린 규칙, 근거 금액이 함께 적혀 사람이 화면을 열지 않은 날에도 놓치지 않습니다. 보고를 연 뒤 피벗으로 돌아가 같은 범위를 이어서 볼 수 있습니다.

실행 기록에는 누가 언제 어떤 결과로 실행했는지 남습니다. 같은 날 두 번째 실행은 서버가 한도로 판정하며 새 보고는 올라가지 않습니다. 제한을 화면이 아니라 서버가 판단하므로 일정 도구가 같은 문을 두드려도 결과가 같습니다.

레이아웃 저장과 복원

짜 둔 화면을 이름 붙여 저장하고 다시 불러옵니다.

레이아웃 버튼에서 현재 축 배치, 조회 조건, 표시 항목, 행 수, 접힘 상태를 이름 붙여 저장합니다. 기본 레이아웃으로 지정하면 다음에 열 때 그 배치로 시작하고 자동 조회를 켜 두면 조회된 채로 열립니다. 팀에서 자주 쓰는 보는 법을 이름으로 부를 수 있게 됩니다.

저장된 레이아웃은 목록에서 적용하고, 기본으로 지정하고, 지웁니다. 불러오면 저장 당시의 축과 조건이 그대로 복원되고 조회가 필요하면 한 번 눌러 새로 읽습니다. 레이아웃이 많아지면 이름으로 가려 쓰게 됩니다.

검산 화면과 좁은 화면

검산 영역과 휴대폰 폭에서 달라지는 점을 정리합니다.

표 아래 검산 영역을 펼치면 측정값마다 큐브 합계와 원천 라인 합계, 차이가 적혀 있습니다. 샘플 데이터에서는 일곱 항목 모두 차이가 0입니다. 운영 데이터에서 차이가 나오면 적재 범위를 먼저 점검하라는 신호입니다.

창이 좁아지면 차트를 숨기지 않고 표 아래로 내립니다. 표는 가로로 밀어 보며 첫 열은 고정되어 행 이름이 사라지지 않습니다. 소계와 차이 색은 넓은 화면과 같습니다.

터치 화면에서는 끌어다 놓기 대신 칩 옆 화살표 버튼으로 행과 열을 옮깁니다. 버튼으로 하는 이동과 끌어다 놓는 이동은 같은 코드를 지나므로 결과가 같습니다. 열 조합과 행 상한도 같은 규칙입니다.

화면 뒤에서 일어나는 일

조회 버튼을 누르면 화면은 큐브와 예정 큐브를 한 번 읽습니다. 이후 축을 바꾸는 일은 브라우저에서 다시 묶는 것이라 서버를 부르지 않고, 칸을 눌러 원천 라인을 열거나 요인 분해와 해설을 요청할 때만 서비스를 부릅니다. 금액 계산은 서비스가 하고 화면은 합산과 배치만 합니다.

1. 수입 원가(착지원가) = 물대 + 운임 + 보험료 + 관세 + 통관수수료 + 하역비
2. 부대비용 = 운임 + 보험료 + 관세 + 통관수수료 + 하역비, 부대비용률 = 부대비용 ÷ 물대 × 100
3. 단위원가 = 수입 원가 ÷ 수량
4. 대사 — 큐브 합계 = 원천 라인 합계, 예정 큐브 = 예정 라인 합계, 요인 합 = 총차이, 칸 금액 = 드릴스루 라인 합

요인 산식

항목 단위 정수 원화로 계산하고 합이 총차이와 정확히 같습니다. 물량은 실적 수량과 예정 수량의 차이에 예정 외화 단가와 예정 환율을 곱한 값이고, 외화 단가는 실적 수량에 단가 차이와 예정 환율을 곱한 값입니다. 환율은 물대 차이에서 두 항을 뺀 나머지이며 실적 환율 변화분과 반올림 차이를 담습니다. 운임과 관세는 실적에서 예정을 뺀 값이고, 보험료·통관수수료·하역비는 기타 부대비용으로 묶습니다.

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

• 차트를 숨기지 않고 표 아래로 내립니다.
• 끌어다 놓기 대신 칩 옆 화살표 버튼으로 축을 옮깁니다.
• 표는 가로로 밀어 보며 첫 열은 고정됩니다.

파일 구성

(앱 폴더)
├─ 화면 진입 파일 · 컴포넌트 · manifest
├─ 컨트롤러 · 화면 정의 · 대화상자 5개
├─ 모델 — 큐브 재집계 · 차트 · 레이아웃 · 보고서 · 서식 · 문제 안내
├─ 스타일 · 문구(i18n)
└─ OData 서비스 — 메타데이터 · 서비스 로직 · 샘플 데이터

SAP 표준 기능 확장 포인트

표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 조회·검증 관점을 더해 확장합니다. 아래는 어디까지가 표준이고 어디서부터 이 화면인지의 정리입니다.

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

T-code 별 연계 지점

운영 전환 때 기존 리포트를 없애야 하는지에 대한 답은 없애지 않는다입니다. 법정·감사·세무 신고 대응과 원천 확인은 표준 T-code 에 그대로 두고, 이 화면은 분석과 차이 설명을 맡습니다. 표준 화면 값을 이 화면에서 다시 볼 때는 같은 구매오더나 공급사로 범위를 좁히면 되고, 이 화면의 결과에서 표준으로 돌아갈 때는 칸에서 나온 구매오더 번호를 구매오더 조회에 넣으면 됩니다.

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

S/4HANA 에는 표준 CDS 분석 쿼리와 Fiori 분석 앱, Analysis for Office 같은 분석 수단이 있습니다. 이 화면은 그것들을 대체하지 않고, 고객사가 정한 차원과 요인 분해, 사유 기록, 감시 규칙을 한 화면에 묶는 자리를 맡습니다. 표준 분석 앱이 이미 구성된 고객사라면 표준 쿼리를 큐브 뷰의 원천으로 쓰고 화면만 얹는 방법도 있습니다. 어느 표준 뷰를 쓸 수 있는지는 버전에 따라 달라 확인이 필요합니다.

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

분석 지표 정의표

CDS 구성

샘플은 서비스가 읽는 JSON 으로 동작하지만, 운영 데이터로 옮길 때의 층 구조는 아래와 같습니다. 객체 이름은 예시이며 고객사의 명명 규칙에 맞춰 바꿉니다.

뷰 레이어 구성

① 매핑 · 배부 기준 테이블 — 부대비용 조건 유형을 6요소로 묶는다

수입 원가는 물대와 부대비용 다섯 요소의 합입니다. 조건 유형 코드는 회사마다 다르므로 코드를 6요소로 접는 기준을 테이블로 분리해 두면 고객사별 차이를 코드 수정 없이 데이터로 처리할 수 있습니다. 이 테이블이 비면 부대비용이 통째로 빠지므로 운영 전환에서 가장 먼저 채우는 대상입니다.

" ───────────────────────────────────────────────────────────────
" ZIMP_CHGKEY — 조건 유형 → 수입 원가 요소 매핑 (고객사가 채운다)
" 역할  : 구매오더 가격 조건 코드를 운임·보험료·관세·통관수수료·하역비로 접는다
" 이유  : 조건 유형은 회사마다 다르다. 뷰에 코드를 박으면 고객사마다 뷰를 고쳐야 한다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수입 원가 조건 매핑'
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zimp_chgkey {
  key client    : abap.clnt not null;
  key kschl     : kscha not null;          " 조건 유형 (고객사별)
  chg_element   : abap.char(8) not null;   " FREIGHT · INSURE · DUTY · CLEAR · HANDLE
  sign_factor   : abap.int1;               " 1 = 가산, 0 = 제외 (할인 조건 처리용)
}

② 기준 뷰 — 구매오더 품목을 차원과 함께 읽는다

큐브의 바닥은 구매오더 품목입니다. 공급사·자재·플랜트·통화·인코텀즈·예정 환율을 한 줄에 모아 두면 위 뷰들이 조인 없이 이 뷰만 읽습니다. 예정 원가의 근거인 수량·외화 단가·환율이 여기서 결정되므로 환율 유형과 기준일을 정하는 자리이기도 합니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImpCostBase — 수입 원가의 바닥 뷰
" 역할  : 구매오더 품목 단위로 차원(공급사·자재·플랜트·통화·인코텀즈)과 예정 값을 모은다
" 이유  : 큐브·계획 뷰가 같은 바닥을 읽어야 실적과 예정의 차원이 어긋나지 않는다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수입 원가 기준'
define view entity ZI_ImpCostBase
  as select from ekpo
    inner join ekko on ekko.ebeln = ekpo.ebeln
{
  key ekpo.ebeln                 as PurchaseOrder,
  key ekpo.ebelp                 as PurchaseOrderItem,
      ekko.lifnr                 as Supplier,
      ekpo.matnr                 as Material,
      ekpo.werks                 as Plant,
      ekko.inco1                 as Incoterms,
      ekko.waers                 as DocumentCurrency,
      ekko.wkurs                 as PlannedExchangeRate,
      @Semantics.quantity.unitOfMeasure : 'OrderUnit'
      ekpo.menge                 as OrderedQuantity,
      ekpo.meins                 as OrderUnit,
      @Semantics.amount.currencyCode : 'DocumentCurrency'
      ekpo.netpr                 as PlannedNetPrice
}

③ 차원 뷰 — 공급사 · 자재 · 플랜트 이름

차원 값은 코드만으로는 읽을 수 없습니다. 이름을 가져오는 일을 큐브에서 떼어 차원 뷰로 두면 이름 변경이 집계에 영향을 주지 않습니다. 원산지는 자재 마스터의 어느 필드를 쓸지 고객사마다 달라 확인이 필요합니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImpSupplierDim — 공급사 차원
" 역할  : 공급사 코드에 이름과 국가를 붙인다
" 이유  : 이름은 바뀔 수 있지만 집계 키는 바뀌면 안 된다 — 둘을 한 뷰에 섞지 않는다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #NOT_REQUIRED
@ObjectModel.dataCategory : #TEXT
@EndUserText.label : '공급사 차원'
define view entity ZI_ImpSupplierDim
  as select from lfa1
{
  key lifnr as Supplier,
      name1 as SupplierName,
      land1 as SupplierCountry
}

" 원산지는 자재·플랜트 단위 필드와 공급사 국가 중 무엇을 기준으로 할지 고객사가 정한다 — 확인 필요
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : '자재 차원'
define view entity ZI_ImpMaterialDim
  as select from mara
    association [0..*] to makt as _Text on _Text.matnr = $projection.Material
{
  key mara.matnr as Material,
      mara.matkl as MaterialGroup,
      _Text
}

④ 실적 큐브 — 입고 · 송장 · 조건 금액을 한 줄로

실적은 입고 수량, 송장의 물대, 조건 금액의 세 갈래에서 옵니다. 이 뷰가 세 갈래를 선하증권 품목 단위로 모아 측정값으로 만듭니다. 환율은 예정 환율과 실적 환율을 모두 들고 있어야 나중에 환율 요인을 가를 수 있습니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImpCostCube — 수입 원가 실적 큐브
" 역할  : 입고 수량 · 송장 금액 · 조건 금액을 차원과 함께 집계 가능한 형태로 둔다
" 이유  : 측정값을 합산 가능한 금액으로만 두고 비율은 쿼리에서 계산한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수입 원가 실적 큐브'
define view entity ZI_ImpCostCube
  as select from ZI_ImpCostBase as Base
    inner join   rseg on  rseg.ebeln = Base.PurchaseOrder
                      and rseg.ebelp = Base.PurchaseOrderItem
  association [0..1] to ZI_ImpSupplierDim as _Supplier
    on $projection.Supplier = _Supplier.Supplier
{
  key rseg.belnr                 as InvoiceDocument,
  key rseg.buzei                 as InvoiceItem,
      Base.Supplier,
      Base.Material,
      Base.Plant,
      Base.Incoterms,
      Base.DocumentCurrency,
      @Semantics.amount.currencyCode : 'CompanyCurrency'
      @Aggregation.default : #SUM
      cast( rseg.wrbtr * Base.PlannedExchangeRate as abap.curr(23,0) ) as GoodsAmount,
      @Aggregation.default : #SUM
      cast( rseg.menge as abap.quan(13,3) )                            as ReceivedQuantity,
      _Supplier
}

⑤ 계획 큐브 — 예정 원가를 같은 차원으로

예정 원가는 실적과 같은 차원 구조를 가져야 칸마다 차이를 뺄 수 있습니다. 예정은 구매오더 조건에서 오며 어느 버전을 기준으로 삼을지가 도입에서 가장 먼저 걸리는 질문입니다. 샘플의 예정값은 가정값입니다.

" ───────────────────────────────────────────────────────────────
" ZI_ImpCostPlanCube — 예정 원가 큐브
" 역할  : 구매오더 수량 × 예정 외화 단가 × 예정 환율로 예정 물대를 만든다
" 이유  : 실적과 같은 차원·같은 측정값이어야 칸마다 뺄셈이 된다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : '수입 원가 예정 큐브'
define view entity ZI_ImpCostPlanCube
  as select from ZI_ImpCostBase as Base
{
  key Base.PurchaseOrder,
  key Base.PurchaseOrderItem,
      Base.Supplier,
      Base.Material,
      Base.Plant,
      Base.Incoterms,
      Base.DocumentCurrency,
      @Semantics.amount.currencyCode : 'CompanyCurrency'
      @Aggregation.default : #SUM
      cast( Base.OrderedQuantity * Base.PlannedNetPrice * Base.PlannedExchangeRate
            as abap.curr(23,0) )                       as PlannedGoodsAmount,
      @Aggregation.default : #SUM
      cast( Base.OrderedQuantity as abap.quan(13,3) )  as PlannedQuantity
}

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

쿼리 뷰는 화면이 실제로 읽는 얼굴입니다. 필터로 쓸 차원, 기본 정렬, 표시 형식이 여기서 정해집니다. 비율 계산은 합산 뒤에 하도록 계산 열로 둡니다.

" ───────────────────────────────────────────────────────────────
" ZC_ImpCostQuery — 수입 원가 분석 쿼리 (Consumption)
" 역할  : 화면에 보일 차원·측정값·필터를 정한다
" 이유  : 소비 측 변경(필터·정렬)이 큐브 뷰를 건드리지 않게 한다
" ───────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : '수입 원가 분석'
define view entity ZC_ImpCostQuery
  as select from ZI_ImpCostCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, multipleSelections : true }
  Supplier,
  @AnalyticsDetails.query.axis : #ROWS
  Material,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Consumption.filter.selectionType : #INTERVAL
  PostingPeriod,
  @AnalyticsDetails.query.axis : #COLUMNS
  GoodsAmount,
  ReceivedQuantity
}

⑦ 권한 — 플랜트 단위로 집계 단계에 건다

권한은 드릴스루에만 걸면 합계에서 뺄셈으로 새어 나옵니다. 집계 단계에 플랜트 권한을 걸어 두면 남의 플랜트 숫자는 합계에도 들어오지 않습니다.

" ───────────────────────────────────────────────────────────────
" ZR_ImpCostAuth — 접근 제어 (DCL)
" 역할  : 구매 조직 권한(플랜트 단위)을 집계 단계에서 적용한다
" 이유  : 상세에만 권한을 걸면 전체 합계와 자기 몫의 차이로 남의 숫자가 드러난다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수입 원가 권한'
@MappingRole : true
define role ZR_ImpCostAuth {
  grant select on ZI_ImpCostCube
    where ( Plant ) = aspect pfcg_auth( M_BEST_WRK, WERKS, ACTVT = '03' );
}

⑧ 서비스 정의 — OData 로 내보낸다

서비스 정의와 바인딩이 화면이 읽는 OData V2 입구입니다. 화면의 manifest 에는 서비스 주소만 적혀 있어 운영 전환에서는 게시된 주소로 바꾸면 됩니다.

" ───────────────────────────────────────────────────────────────
" ZUI_ImpCost — 서비스 정의
" 역할  : 쿼리와 차원 뷰를 하나의 서비스로 묶는다
" 이유  : 화면이 서비스 하나만 바라보게 해 주소 교체를 한 곳에서 끝낸다
" ───────────────────────────────────────────────────────────────
@EndUserText.label : '수입 원가 분석 서비스'
define service ZUI_ImpCost {
  expose ZC_ImpCostQuery  as CostQuery;
  expose ZI_ImpSupplierDim as Supplier;
  expose ZI_ImpMaterialDim as Material;
}
" 바인딩: OData V2 - UI 유형으로 만들어 게시한다(서비스 활성화는 /IWFND/MAINT_SERVICE 또는 바인딩 게시).

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래는 운영 전환 전에 합의해야 하는 항목입니다.

운영 데이터로 갈 때

수입 라인이 수천만 건이면 큐브를 한 번 읽어 브라우저에서 묶는 지금 구조로는 한계가 있습니다. 집계 위치를 서비스 쪽으로 옮기고, 기간과 공급사를 필수 조건으로 두며, 큐브 뷰의 조인 키에 맞는 인덱스를 정하고, 응답 시간 기준을 도입 때 합의합니다. 화면은 서비스 주소만 알기 때문에 이 변경은 서버 쪽에서 끝납니다.

자주 묻는 질문

도입 검토 때 자주 나오는 질문 26개를 네 묶음으로 정리했습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영