수출 제품 믹스 공헌이익 다차원 분석 리포트 — 계획 대비 차이를 물량·믹스·환율 요인으로 가르는 수출 수익성 점검

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

수출 담당과 관리회계 담당이 계획 대비 실적을 볼 때 묻는 질문은 늘 같습니다. 계획 대비 공헌이익이 얼마나 벗어났나, 어느 국가·고객·제품에서 났나, 물량 때문인가 환율 때문인가 비용 때문인가. 지금은 이 답이 청구 문서 조회, 고객 항목 조회, 수익성 분석 보고서, 그리고 밤새 만든 엑셀에 흩어져 있습니다. 이 화면은 같은 수출 청구 데이터를 한 큐브에 모아 세 질문을 한 화면에서 답하도록 이어 붙입니다.

표준 화면(VA03 · VL03N · VF03 · FBL5N · KE30)은 각자 맡은 문서와 항목을 정확히 보여 줍니다. 다만 “제품 믹스가 바뀌어서인지, 환율이 움직여서인지”를 한 번에 가르는 자리는 표준 화면 사이에 있습니다. 이 앱은 표준 실행은 SAP 표준 T-code 에 그대로 두고, 그 사이를 조회·검증 관점으로 메웁니다. 판단은 숫자를 단정하지 않고 점검 필요 · 확인 필요로 남깁니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 계획보다 잘 나온 숫자 안에 있는 것

검증용 샘플 데이터(2026년 1월~9월 수출 청구 3,294줄, 고객 14·제품 12·국가 8·통화 4)에서 공헌이익은 계획 3,159백만원, 실적 3,288백만원으로 총차이 +128백만원이 나왔습니다. 합계만 보면 계획을 웃돈 달입니다. 여덟 요인으로 가르자 모양이 달라집니다.

환율(+169)과 미계획(+105)을 빼면 나머지 여섯 요인의 합은 −146백만원입니다. 즉 “계획보다 128 잘 나왔다”는 숫자 안에는 비용 쪽에서 계획보다 덜 남은 몫이 들어 있습니다. 원인을 단정하지 않고 변동비·운임보험 단가를 점검해야 할 자리를 금액 순으로 올려 주는 것이 이 화면의 역할입니다. 요인 합계가 총차이와 같은지는 화면이 매번 검산하며, 이 샘플의 대사 검사 68건은 모두 차이 0건입니다(요인 합계는 원 단위 반올림 0.01원).

도입하면 달라지는 것

• 회의의 주제 — “어느 숫자가 맞나” 가 아니라 “변동비와 운임을 어떻게 볼 것인가” 로 옮겨 갑니다.
• 보고 준비 — 차이 표·요인분해·사유·보고서가 한 화면에서 나와 엑셀 취합과 캡처가 줄어듭니다.
• 다음 조회로 이어지는 기록 — 사유와 레이아웃이 남아 같은 설명을 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 아무도 화면을 열지 않아도 규칙에 걸린 항목이 받을 역할의 대기함에 올라옵니다.

이런 회사에 맞습니다

외화로 수출 청구를 내고 판매 계획을 제품·고객 단위로 세우는 제조·유통 회사에 맞습니다. 수출 국가가 여럿이고 통화가 둘 이상이라 환율 효과를 따로 읽어야 하며, 인코텀즈에 따라 운임·보험료가 매출 대비 비율로 크게 달라지는 곳일수록 효과가 큽니다. 수출 영업, 물류, 관리회계(또는 경영지원) 담당이 같은 숫자를 놓고 이야기해야 하는 조직, 그리고 월 단위로 계획 대비 점검 회의를 여는 조직을 염두에 두었습니다. 반대로 내수 위주이거나 계획을 제품 단위로 세우지 않는 회사는 계획 원천부터 정해야 합니다.

실행 화면

사용 방법

1. 조회조건 입력 — 필수는 회사코드와 시작·종료 기간입니다(기본값 1000, 2026-01 ~ 2026-09). 계획 기준은 판매 계획 v1 로 고정이고, 저장된 레이아웃 선택은 선택 사항입니다.
2. 조회 — 조회 단추는 조회조건 영역 오른쪽 끝에 있고, 회사코드 칸에서 Enter 키를 눌러도 같은 조회가 됩니다. 조회 전에도 레이아웃 보드와 피벗 틀이 먼저 보입니다. 기본 레이아웃에 자동 조회를 지정하면 화면을 열 때 조회된 채로 시작합니다.
3. 요약 확인 — 표 위의 역할별 요약에서 경영자 · 재무 책임자 · 영업 책임자 · 물류 책임자를 바꾸면 앞세우는 지표 네 개와 쪼개 보는 차원이 함께 바뀝니다. 다시 조회하지 않습니다.
4. 탭·축 이동 — 레이아웃 보드의 차원 단추를 쓰지 않는 차원 · 행 · 열 칸으로 끌어다 놓습니다. 행은 3단계, 열은 2단계까지이며, 브라우저가 가진 큐브를 바로 다시 묶습니다. 차원 필터 단추에서는 값을 여러 개 고릅니다.
5. 행·셀 클릭 상세 — 행의 화살표로 하위 차원까지 내려가고, 금액 칸을 누르면 그 금액을 만든 청구 문서 라인이 열립니다. 위쪽 기간별 요약 단추는 월별 요약을 보여 줍니다.
6. 분석 항목과 계획 대비 — 공헌이익·공헌이익률 같은 계산항목을 고르고, 계획 대비 스위치를 켜면 칸마다 실적 · 계획 · 차이 · 증감률이 붙습니다. 차이가 난 행에서 사유를 남기고, 차트의 차이 분해 탭에서 워터폴과 검산 줄을 봅니다.
7. AI 분석·에이전트 — 위쪽 AI 분석에서 현재 범위의 해설과 근거 표를 읽고, AI 에이전트에서 감시 규칙 · 받은 보고 · 실행 기록 탭을 오가며 실행합니다.
8. 내보내기 — AI 분석 창의 보고서 단추로 PowerPoint 보고서를, 위쪽 CSV 단추로 현재 표(사유 포함)를 내려받습니다. 레이아웃 메뉴에서는 현재 배치를 이름 붙여 저장합니다.

무엇으로 만들었나

화면은 OpenUI5 표준 컨트롤과 직접 그린 SVG 차트로 짰고, 데이터는 OData V2 서비스 하나에서 읽습니다. 서비스 쪽에서 판정하는 일과 브라우저가 맡는 일을 아래처럼 나눴습니다.

앱 정보

실제 브라우저에서 검증용 샘플 데이터로 찍은 화면 33종을 순서대로 싣습니다. 그림을 누르면 크게 볼 수 있고, 화면마다 무엇을 하는 자리인지 아래에 적었습니다. 숫자는 모두 같은 자료에서 나온 것이라 화면끼리 맞춰 보셔도 됩니다.

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

처음 열었을 때에는 아직 서비스를 부르지 않은 상태에서도 화면의 뼈대가 보입니다. 조회 직후 한 화면에 표 · 차트 · 요약이 함께 뜹니다.

회사코드 · 시작·종료 기간 · 계획 기준 · 저장된 레이아웃과 그 아래 레이아웃 보드가 조회 전에도 먼저 뜹니다. 조회 단추는 조회조건 영역 오른쪽 끝에 있고, 회사코드 칸에서 Enter 키를 눌러도 같은 조회가 됩니다. 기본 배치는 행 지역 › 국가이며 열은 비어 있습니다.

조회 한 번으로 큐브 738건(원천 청구 3,294줄)을 읽어 표 · 차트 · 역할 요약을 그립니다. 경영자 요약은 매출 12,660백만원 · 공헌이익 3,288백만원 · 공헌이익률 26.0%를 앞세우고 각 값 아래에 계획과 대비를 붙입니다. 표 왼쪽 화살표로 지역 아래 국가를 펼치면 차트도 함께 바뀝니다.

차원 단추를 끌어다 세 칸 사이에서 옮깁니다. 행은 3단계, 열은 2단계까지 쌓이고 단추 안쪽 지우기로 축을 뺄 수 있습니다. 어느 칸으로 옮겨도 서비스를 다시 부르지 않고 브라우저가 가진 큐브를 다시 묶습니다.

행 지역 › 국가 › 제품그룹에 열 인코텀즈로 바꾼 모습입니다. 열에는 CIF · DAP · FOB 가 나란히 서고 오른쪽 끝에 합계가 붙습니다. 어떤 배치에서도 총합은 3,288백만원으로 같아야 하며 이 값이 갈라지는지를 배치 6가지로 시험했습니다.

조회 조건 영역을 접으면 회사 · 기간 · 행·열 구성 · 항목 · 계획 대비 여부 · 필터 수가 한 줄에 남고 표와 차트가 화면을 더 씁니다. 다시 펼치면 조건이 그대로 있습니다.

경영 요약 — 역할 네 개

같은 큐브를 역할마다 다른 눈으로 읽습니다. 역할을 바꿔도 다시 조회하지 않고 앞세우는 지표와 쪼개 보는 차원만 바뀝니다.

경영자 역할은 매출 · 공헌이익 · 공헌이익률 · EA당 공헌이익을 계획과 나란히 보여 줍니다. 숫자 아래 계획 값과 대비(예: 104.1%)가 붙어 계획 대비 위치를 바로 읽습니다.

재무 책임자는 제품그룹 › 제품으로 내려가며 공헌이익과 변동비 · 운임보험수수료를 봅니다. 제품그룹별 공헌이익률이 18.7%(산업용 소재)에서 31.2%(전자부품)까지 벌어지는 것이 표와 차트에서 한 번에 보입니다.

영업 책임자는 국가 › 고객 순으로 매출 · 공헌이익 · 수량 · 평균 판매단가를 봅니다. 국가별 공헌이익률이 21.5%(아랍에미리트)에서 31.6%(멕시코)까지 갈리는 모습이 보입니다.

물류 책임자는 인코텀즈 › 국가별 운임·보험료와 수수료를 봅니다. 전체 운임·보험·수수료는 752백만원으로 매출의 5.9%이고, DAP 의 비율이 9.1%로 가장 높습니다. 비용이 늘면 빨강으로 보이도록 영향 방향을 따로 정해 두었습니다.

축 전환과 범위 — 열 2단계 · 다중 선택 · 차트 폭

축을 겹치고 값을 골라 범위를 좁히는 화면입니다. 모든 조작은 브라우저 안에서 일어나고 서비스를 다시 부르지 않습니다.

열에 분기와 인코텀즈를 올려 열 조합 10개를 만든 모습입니다. 열 조합이 36개를 넘는 배치는 추가를 막고, 그 한도 안에서 표를 가로로 읽습니다. 오른쪽 차트는 열 축이 있으면 묶음 막대로 바뀝니다.

차원 필터 단추를 누르면 값 목록이 열립니다. 값마다 이름과 코드, 원천 라인 수가 보이고 여러 개를 고를 수 있으며 큐브에 있는 값만 올라옵니다. 같은 차원 안에서는 또는, 다른 차원끼리는 그리고로 결합합니다.

국가에서 일본과 미국만 고른 결과입니다. 필터 단추에 선택 수(2)가 붙고 요약 · 표 · 차트가 선택 범위로 바뀝니다. 공헌이익 합계 1,131백만원은 큐브에서 두 국가 값을 직접 더한 것과 같습니다.

표와 차트 사이 손잡이를 끌면 차트 너비가 바뀌고, 브라우저가 그 값을 기억해 다음에도 같은 비율로 엽니다. 좁은 화면에서는 손잡이 대신 차트가 표 아래로 내려갑니다.

칸에서 원천 문서까지 — 드릴스루 · 문서 라인 · 기간별 요약

피벗의 숫자를 의심할 때 화면을 옮기지 않고 그 금액을 만든 청구 문서 라인까지 내려갑니다.

전체 합계 공헌이익 칸을 눌러 연 창입니다. 머리에 셀 값 3,288 = 원천 합계 3,288(원천 3,294줄) 일치가 표시되고 바로 아래에 이 목록을 만든 조회 조건이 그대로 보입니다. 기본 500행씩 보여 주고 더 보기로 넘깁니다.

아랍에미리트 칸의 문서 라인 273줄입니다. 청구 번호 · 품목 · 선적일 · 청구일 · 수주번호 · 고객 · 국가 · 제품 · 제품그룹 · 인코텀즈가 한 줄씩 나오고 셀 값 250 = 원천 합계 250 이 일치합니다. 이 번호로 표준 청구 문서 조회 화면에서 원본을 찾습니다.

월별 라인 수 · 수량 · 매출 · 변동비 · 운임·보험료 · 수수료 · 공헌이익 · 공헌이익률을 한 표로 보여 줍니다. 합계 행의 3,294줄 · 매출 12,660 · 공헌이익 3,288 · 25.97%는 큐브 합계와 같고, 이 표는 서비스가 원천 라인을 직접 합산한 값입니다.

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

매출에서 공헌이익까지는 한 줄로 전기되는 값이 아니라 계산 단계입니다. 서비스가 식으로 정의한 단계를 행이나 열로 세웁니다.

분석 항목을 계산항목으로 두고 보기 방식을 단계 보기로 바꾸면 계산 단계가 위에서부터 행으로 펼쳐지고 열에는 국가가 놓입니다. 단계마다 어느 값에서 이익이 줄어드는지 한 번에 읽습니다.

계산항목 세 개를 열로 세운 표입니다. 제품그룹별 EA당 공헌이익이 3,936원(포장재)에서 21,485원(전자부품)까지 벌어지는 것이 보입니다. 식은 서비스의 계산항목 정의에 있고 화면은 식을 풀어 합산만 합니다.

기준 대비 차이 — 차이 모드 · 변동 사유 · 워터폴 · 요인분해

계획 대비 스위치 하나로 같은 표가 차이 리포트가 됩니다. 색이 칠한 칸만 골라 원인을 쪼개 보고 사유를 남깁니다.

칸마다 실적 아래에 계획 · 차이 · 증감률이 작게 붙습니다. 일본은 공헌이익 331백만원으로 계획 402보다 71백만원(−17.7%) 낮아 빨강입니다. 임계는 금액 1천만원과 비율 5%(비율 항목은 0.5퍼센트포인트)이며 둘 중 하나만 넘으면 색을 칠하지 않습니다.

차이가 난 행의 사유 단추를 누르면 사유 구분과 내용을 적는 창이 열립니다. 조회 범위와 행 경로(여기서는 중국)가 키로 저장되어 축을 바꿔도 같은 행에 따라오고, 저장한 사유는 CSV 와 AI 분석 근거에도 실립니다. 예시 사유는 검증용 샘플 문장입니다.

차이 분해 탭의 워터폴입니다. 계획 3,159에서 시작해 물량 +17 · 믹스 −15 · 외화 단가 −17 · 환율 +169 · 변동비 −96 · 운임·보험 −31 · 수수료 −4 · 미계획 +105 를 거쳐 실적 3,288에 닿습니다. 초록은 공헌이익을 늘린 요인, 빨강은 줄인 요인입니다.

워터폴 아래 검산 줄은 요인을 모두 더한 값과 총차이가 같은지를 매번 계산해 보여 줍니다. 두 값의 오차는 −0.01원으로 원 단위 반올림에서 나옵니다. 합이 맞지 않으면 이 줄이 먼저 알려 줍니다.

AI 분석과 보고서 — 숫자는 서비스가, 글은 해설이

AI 는 숫자를 만들지 않습니다. 서비스가 계산한 값을 읽어 문장으로 정리하고 근거를 펼쳐 보여 줍니다.

이 화면은 모델을 연결하지 않은 규칙 기반 해설입니다. 총차이 128백만원 가운데 환율(169백만원)의 영향이 가장 크다고 읽고 원인은 단정하지 않으며, 계획을 웃돈 인코텀즈(FOB +83 · DAP +35 백만원)를 주요 발견으로 올립니다. 하단 보고서 단추로 PowerPoint 보고서를 내려받습니다.

근거 수치를 펼치면 해설이 읽은 실적 · 계획 공헌이익, 매출, 차이, 등록된 사유가 표로 나옵니다. 숫자는 서비스가 계산한 값이고 해설은 그 값을 옮긴 문장입니다. 이미 사유가 적힌 차이는 해설에서 건너뜁니다.

AI 에이전트 — 규칙 · 대기함 · 활동 기록

사람이 화면을 열지 않아도 규칙에 걸린 항목을 받을 역할에게 올리는 감시입니다. 실행은 서비스가 하고 하루 한 번 제한도 서비스가 판정합니다.

감시 규칙 다섯 개가 기준값 · 점검 주기 · 받을 역할 · 사용 여부와 함께 보입니다. 기준값은 화면에서 바꿔 저장하며 사용 스위치로 규칙을 끌 수 있습니다.

규칙에 걸린 항목이 받을 역할별 보고로 쌓인 대기함입니다. 역할 필터로 영업 책임자나 재무 책임자 몫만 볼 수 있고, 첫 실행에서 아홉 건이 올라왔습니다. 모든 문장은 점검 필요 · 확인 필요로 끝나 원인을 단정하지 않습니다.

실행 기록 탭입니다. 첫 실행은 아홉 건을 올린 것으로, 같은 날 두 번째 실행은 하루 한 번 제한으로 건너뛴 것으로 남습니다. 걸린 것이 없어도, 건너뛰어도 활동 기록이 남고 호출 주체(사람 · 화면 타이머 · 배치)가 함께 적힙니다.

레이아웃 저장과 복원

자주 쓰는 배치를 이름 붙여 저장하고, 기본 + 자동 조회로 지정하면 화면을 열 때 조회된 채로 시작합니다.

저장 창에서 이름을 적고 기본 레이아웃 · 열 때 자동 조회를 고릅니다. 아래에 저장될 내용(행 · 열 · 기간 · 항목 · 계획 대비)을 미리 보여 줍니다.

저장한 레이아웃의 기본 지정과 자동 조회를 바꾸고, 적용 · 이름 바꾸기 · 삭제를 합니다. 여러 사람이 쓰는 환경에서는 사용자별로 목록이 나뉩니다.

기본 + 자동 조회로 저장한 레이아웃은 화면을 새로 열면 조회된 상태로 시작합니다. 행 국가 › 제품그룹, 계획 대비 켬, 차이 분해 탭까지 복원된 모습입니다.

좁은 화면과 한계

휴대폰 폭에서는 차트가 표 아래로 쌓이고, 한 번에 그릴 수 있는 조합에는 상한이 있습니다.

폭 390px 에서는 조회조건 · 레이아웃 보드 · 분석 항목이 한 열로 쌓입니다. 조회 단추는 조회조건 영역 끝에 그대로 있습니다.

표를 지난 다음 차트가 이어서 나옵니다. 차트 폭 손잡이는 이 폭에서는 쓰지 않습니다.

행 조합이 500개(여기서는 1,573개)를 넘거나 열 조합이 36개(여기서는 96개)를 넘으면 표를 그리지 않고 행 · 열 차원을 줄이거나 필터를 걸라는 안내를 띄웁니다. 오해를 부르는 일부만 그린 표를 만들지 않기 위한 장치입니다.

화면 뒤에서 일어나는 일

축을 바꾸는 일과 문서로 내려가는 일은 서로 다른 경로를 씁니다.

차이 모드의 색 판정

색은 금액의 부호가 아니라 공헌이익에 준 영향 방향으로 칠합니다. 비용이 계획보다 덜 나가면 차이는 음수지만 이익에는 보탬이라 초록입니다.

8요인분해의 산식

실적과 계획이 모두 있는 칸(기간·고객·제품·인코텀즈 조합)마다 아래 식으로 계산해 더합니다. 합이 총차이와 같도록 식을 닫아 두었고, 화면은 합계와 총차이의 차이를 검산 줄로 매번 보여 줍니다.

실적 없이 계획만 있는 칸은 계획 공헌이익과 물량 요인만큼을 믹스 요인에서 되돌려 합이 맞도록 처리합니다. 원인을 단정하지 않고 점검할 요인과 금액만 제시합니다.

AI 에이전트 감시 규칙

실행은 하루 한 번만 허용되며(서비스가 판정), 걸린 항목이 없어도 활동 기록이 남습니다. 운영에서는 배치 작업이 같은 실행 펑션을 부르도록 연결하면 됩니다.

산출·대사식

조회조건

날짜 조건은 datetime'2026-06-01T00:00:00' 형태로 쓰고, 페이지는 $top · $skip · $inlinecount=allpages 로 넘깁니다.

결과 컬럼

좁은 화면에서 달라지는 것

폭 390px 같은 휴대폰 화면에서는 조회조건 · 레이아웃 보드 · 분석 항목이 한 열로 쌓이고, 차트는 표 오른쪽이 아니라 표 아래로 내려옵니다. 표와 차트 사이의 폭 손잡이는 이 폭에서 쓰지 않습니다. 표는 가로로 밀어 읽고, 조회 단추는 조회조건 영역 끝에 그대로 있습니다. 또한 행 조합이 500개, 열 조합이 36개를 넘는 배치는 어느 폭에서나 일부만 그린 표 대신 범위를 좁히라는 안내를 띄웁니다.

파일 구성

index.html · Component.js · manifest.json · readme.html
controller/   Main.controller.js · BaseController.js
view/         Main.view.xml · fragments/ (대화상자 조각)
model/        cube.js(피벗) · chart.js(SVG 차트) · pptx.js(PowerPoint 보고서) · layout.js · formatter.js · ErrorHandler.js
css/          style.css
i18n/         i18n.properties · i18n_ko.properties
odata/        engine.js · service.js · metadata.xml · json/ (집합별 샘플 데이터)
media/        소개 영상 · 포스터 · 재생 지점 자막

SAP 표준 기능 확장 포인트

이 화면은 표준 T-code 를 대체하지 않습니다. 표준 실행은 SAP 표준 T-code 가 담당하고, 이 화면은 같은 수출 청구 데이터를 조회·검증 관점으로 묶어 확장합니다.

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

T-code 별 연계 지점

기존 리포트를 없애야 하나요? 없애지 않습니다. 법정·감사·세무 신고 대응은 표준 화면과 표준 리포트에 그대로 남기고, 이 화면은 월 단위 점검 회의에서 계획 대비 차이를 설명하는 용도로 나란히 씁니다. 두 화면의 합계가 어긋나면 어느 쪽이 틀렸다고 단정하지 말고 위 대사 지점부터 확인 필요로 놓고 맞춰 갑니다.

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

S/4HANA 는 CDS 뷰 위에 분석 쿼리를 올려 Fiori 분석 앱과 Analysis for Office 로 읽는 구조를 갖고 있습니다. 이 앱의 CDS 구성(아래 CDS 구성 절)은 같은 분석 쿼리 층에 올라가는 것이라, 운영에서는 같은 큐브와 쿼리를 표준 분석 도구가 읽고 이 화면이 끌어다 놓기·드릴스루·요인분해·AI 분석을 더하는 식으로 나란히 쓸 수 있습니다. 판매·수익성 영역의 표준 분석 앱 이름과 제공 여부는 릴리스마다 달라 이 글에서는 이름을 적지 않으며, 도입 시 확인 필요 항목입니다.

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

분석 지표 정의

CDS 구성

이 샘플의 화면은 청구 3,294줄을 큐브 738건으로 묶어 브라우저가 들고 있습니다. 데모라서 되는 일이고, 운영 데이터에서는 그렇게 하지 않습니다. 운영으로 올릴 때 가장 먼저 하는 일은 집계를 CDS 로 내리는 것입니다. 아래는 그때 만드는 뷰의 층 구성과 코드입니다.

코드는 스케치입니다. 필드 이름과 표준 뷰 이름은 릴리스·환경에 따라 다르므로 그대로 붙여 넣기 전에 실제 이름을 확인해야 합니다. 확인이 필요한 자리는 주석에 적어 두었습니다. 표준 CDS 뷰는 이름을 단정하지 않고 원천 테이블 기준으로 적었습니다.

뷰 레이어 구성

① 매핑 테이블 — 현업이 늘리는 묶음

분석용 묶음(국가→지역, 제품→제품그룹)은 마스터에 없습니다. 이 테이블 한 장이 그 묶음을 맡고, 정하지 않으면 그룹 합계가 기존 보고서와 맞지 않습니다. 매핑이 없는 값은 아래 차원 뷰에서 UNMAPPED 로 남겨 합계에서 사라지지 않게 합니다.

// ─────────────────────────────────────────────────────────────
// ZEXPMIX_MAP : 국가→지역, 자재→제품그룹 매핑 (기준)
// 하는 일 : 마스터에 없는 "분석용 묶음"을 현업이 직접 관리하는 테이블
// 이렇게 나눈 이유 : 새 국가·제품이 생길 때마다 뷰를 고치면 전송이 필요하다.
//   테이블이면 현업이 행만 추가한다. (국가·자재 마스터 필드는 확인 필요)
// ─────────────────────────────────────────────────────────────
@EndUserText.label : '수출 분석 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zexpmix_map {
  key client   : abap.clnt not null;
  key map_type : abap.char(1) not null;     // C=국가→지역, M=제품→제품그룹
  key map_key  : abap.char(18) not null;    // 국가코드 또는 자재번호
  map_value    : abap.char(10);             // 지역 또는 제품그룹 코드
  map_text     : abap.char(40);
}

② 기준 뷰 — 청구 품목 한 줄

여기서 결정되는 것은 "어떤 청구를 수출 실적으로 볼 것인가"입니다. 취소 문서 제외와 수출 청구 유형 한정 조건이 이 뷰의 where 에 들어가고, 이 조건이 달라지면 이후 모든 숫자가 달라지므로 운영에서 가장 먼저 합의합니다.

// ─────────────────────────────────────────────────────────────
// ZI_ExpMixBillItem : 청구 품목 한 줄 (기준 뷰)
// 하는 일 : VBRK/VBRP 를 품목 단위로 평평하게 만들고 외화·환율·수량을 그대로 둔다
// 이렇게 나눈 이유 : 이 뷰 하나만 문서 구조를 알게 하고 위의 뷰는 평평한 줄만 본다.
// 확인 필요 : 취소 문서 제외 조건(FKSTO), 운임·수수료 조건 유형 코드
// ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory: [#NONE]
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 청구 품목'
define view entity ZI_ExpMixBillItem
  as select from vbrp
    inner join   vbrk on vbrk.vbeln = vbrp.vbeln
{
  key vbrk.gjahr                         as FiscalYear,
  key vbrp.vbeln                         as BillDoc,
  key vbrp.posnr                         as Item,
      vbrk.bukrs                         as CompanyCode,
      vbrk.kunrg                         as Customer,
      vbrk.fkdat                         as BillDate,
      vbrk.waerk                         as DocCurrency,
      vbrk.kurrf                         as ExchRate,
      vbrp.matnr                         as Material,
      vbrp.aubel                         as SalesOrder,
      vbrp.spart                         as Division,
      @Semantics.quantity.unitOfMeasure: 'Unit'
      vbrp.fkimg                         as BillQty,
      vbrp.vrkme                         as Unit,
      @Semantics.amount.currencyCode: 'DocCurrency'
      vbrp.netwr                         as NetAmount,
      @Semantics.amount.currencyCode: 'DocCurrency'
      vbrp.wavwr                         as CostAmount
}
where vbrk.fksto = ''

③ 차원 뷰 — 국가·지역·제품그룹·기간

고객에서 국가를, 국가와 자재에서 묶음을 붙입니다. left outer join 과 coalesce 로 매핑이 빠진 행도 버리지 않는 것이 요점입니다. 기간 문자열을 여기서 만들어 두면 큐브와 계획이 같은 키 모양을 갖습니다.

// ─────────────────────────────────────────────────────────────
// ZI_ExpMixDim : 차원 뷰 (고객→국가→지역, 자재→제품그룹)
// 하는 일 : 청구 품목에 분석 차원을 붙인다. 매핑이 없으면 "미분류" 로 남긴다.
// 이렇게 나눈 이유 : 큐브에서 join 을 한 번만 걸고, 값 도움말과 텍스트가 이 뷰를 본다.
// ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: '수출 분석 차원'
define view entity ZI_ExpMixDim
  as select from ZI_ExpMixBillItem as b
    left outer join kna1            as c on c.kunnr = b.Customer
    left outer join zexpmix_map     as r on  r.map_type = 'C'
                                         and r.map_key  = c.land1
    left outer join zexpmix_map     as g on  g.map_type = 'M'
                                         and g.map_key  = b.Material
{
  key b.FiscalYear,
  key b.BillDoc,
  key b.Item,
      b.CompanyCode,
      b.Customer,
      c.land1                                     as Country,
      coalesce( r.map_value, 'UNMAPPED' )         as Region,
      coalesce( g.map_value, 'UNMAPPED' )         as ProdGroup,
      b.Material                                  as Product,
      concat( left( cast( b.BillDate as abap.char(8) ), 4 ),
        concat( '-', substring( cast( b.BillDate as abap.char(8) ), 5, 2 ) ) ) as Period
}

④ 실적 큐브 — 합산과 원화 환산

화면이 브라우저에서 하던 합산을 DB 로 내리는 뷰입니다. 원화 환산을 이 뷰 한 곳에서만 하므로 환율 유형·시점을 바꿔도 다른 뷰는 건드리지 않습니다. 운임·보험료와 수수료는 가격 조건 조인으로 같은 방식으로 합산하며 조건 유형 코드는 확인 필요입니다.

// ─────────────────────────────────────────────────────────────
// ZI_ExpMixCube : 실적 큐브 — 기간·고객·제품·인코텀즈 단위로 합산
// 하는 일 : 화면이 브라우저에서 묶던 일을 DB 로 내린다. 원화 환산도 여기서 한 번만 한다.
// 이렇게 나눈 이유 : 환산 규칙(환율 유형·시점)이 이 뷰 한 곳에만 있어야 숫자가 갈라지지 않는다.
// 확인 필요 : 인코텀즈 필드(헤더 INCO1), 환산 방식(문서 환율 × 금액 vs 환산 함수)
// ─────────────────────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@ObjectModel.usageType: { serviceQuality: #D, sizeCategory: #XXL, dataClass: #TRANSACTIONAL }
@EndUserText.label: '수출 실적 큐브'
define view entity ZI_ExpMixCube
  as select from ZI_ExpMixDim as d
    inner join   ZI_ExpMixBillItem as b
      on  b.FiscalYear = d.FiscalYear and b.BillDoc = d.BillDoc and b.Item = d.Item
    inner join   vbrk as h on h.vbeln = b.BillDoc
{
  key d.CompanyCode,
  key d.Period,
  key d.Customer,
  key d.Product,
  key h.inco1                                  as Incoterms,
      d.Country,
      d.Region,
      d.ProdGroup,
      @Semantics.currencyCode: true
      cast( 'KRW' as abap.cuky )               as Currency,
      @Aggregation.default: #SUM
      count(*)                                 as Lines,
      @Aggregation.default: #SUM
      cast( sum( b.BillQty ) as abap.dec(15,3) ) as Qty,
      @Semantics.amount.currencyCode: 'Currency'
      @Aggregation.default: #SUM
      cast( sum( b.NetAmount * b.ExchRate ) as abap.curr(23,2) ) as Sales,
      @Semantics.amount.currencyCode: 'Currency'
      @Aggregation.default: #SUM
      cast( sum( b.CostAmount ) as abap.curr(23,2) )             as VarCost
      // 운임·보험료, 수수료는 가격 조건(PRCD_ELEMENTS) 조인으로 같은 방식으로 합산 (조건 유형 확인 필요)
}
group by d.CompanyCode, d.Period, d.Customer, d.Product, h.inco1,
         d.Country, d.Region, d.ProdGroup

⑤ 계획 큐브 — 실적과 같은 키 모양

계획의 키가 실적과 어긋나면 요인분해에서 모두 미계획과 계획 없음으로 갈립니다. 계획 원천(어느 테이블, 어느 버전, 수량이 있는지)은 도입 전에 확정할 항목입니다.

// ─────────────────────────────────────────────────────────────
// ZI_ExpMixPlan : 판매 계획 큐브 — 실적 큐브와 같은 키 모양
// 하는 일 : 계획 데이터를 실적과 같은 차원 조합으로 맞춘다.
// 이렇게 나눈 이유 : 키가 어긋나면 계획이 실적 옆에 붙지 않고 "미계획" 으로 따로 뜬다.
// 확인 필요 : 계획 원천(판매 계획 테이블 또는 계획 버전), 수량 보유 여부
// ─────────────────────────────────────────────────────────────
@Analytics.dataCategory: #CUBE
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 판매 계획 큐브'
define view entity ZI_ExpMixPlan
  as select from zexpmix_plan as p
{
  key p.bukrs     as CompanyCode,
  key p.version   as Version,
  key p.period    as Period,
  key p.customer  as Customer,
  key p.product   as Product,
  key p.incoterms as Incoterms,
      @Aggregation.default: #SUM
      p.qty       as Qty,
      @Semantics.amount.currencyCode: 'Currency'
      @Aggregation.default: #SUM
      p.sales     as Sales,
      @Semantics.amount.currencyCode: 'Currency'
      @Aggregation.default: #SUM
      p.var_cost  as VarCost,
      p.currency  as Currency
}

⑥ 분석 쿼리 — 서비스가 노출하는 모양

필터 중 필수로 둘 것(회사코드, 기간)과 기본 행·열 배치, 공헌이익 계산식을 정의합니다. 계산식을 쿼리에 두면 표준 분석 도구와 이 화면이 같은 식을 씁니다.

// ─────────────────────────────────────────────────────────────
// ZC_ExpMixQuery : 분석 쿼리 — 기본 행·열 배치와 계산 측정값
// 하는 일 : 서비스가 노출할 필터와 기본 배치, 공헌이익·공헌이익률 계산 정의
// 이렇게 나눈 이유 : 표준 분석 도구가 이 쿼리를 그대로 읽는다. 계산식은 여기 한 곳에서만 정의한다.
// ─────────────────────────────────────────────────────────────
@Analytics.query: true
@AccessControl.authorizationCheck: #CHECK
@EndUserText.label: '수출 제품 믹스 공헌이익'
@UI.chart: [{ qualifier: 'Mix', chartType: #COLUMN_STACKED,
              dimensions: ['Country'], measures: ['Contribution'] }]
define view entity ZC_ExpMixQuery
  as select from ZI_ExpMixCube
{
  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #RANGE, multipleSelections: true, mandatory: true }
  key CompanyCode,

  @AnalyticsDetails.query.axis: #ROWS
  @Consumption.filter: { selectionType: #INTERVAL, mandatory: true }
  key Period,

  @AnalyticsDetails.query.axis: #COLUMNS
  @Consumption.filter.selectionType: #SINGLE
  key Incoterms,

  Country, Region, ProdGroup, Customer, Product,

  @AnalyticsDetails.query.axis: #COLUMNS
  Sales,
  VarCost,
  @AnalyticsDetails.query.formula: 'Sales - VarCost'
  @EndUserText.label: '공헌이익'
  Contribution
}

⑦ 접근 제어 — 집계에 거는 권한

대용량 집계 뷰에서는 권한이 집계 뒤에 걸리면 합계에서 빼는 방식으로 남의 숫자가 드러날 수 있습니다. 그래서 쿼리가 읽는 자리에 접근 제어를 겁니다.

// ─────────────────────────────────────────────────────────────
// ZC_ExpMixQuery : 접근 제어 (DCL)
// 하는 일 : 회사코드·영업조직 단위로 읽을 수 있는 행을 제한한다.
// 이렇게 나눈 이유 : 집계를 읽는 자리에 걸어야 합계에서 빼는 방식으로 남의 숫자가 새지 않는다.
// 확인 필요 : 회사 권한 객체 외에 영업조직 권한을 쓸지 여부
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '수출 공헌이익 접근 제어'
@MappingRole: true
define role ZC_ExpMixQuery {
  grant select on ZC_ExpMixQuery
    where ( CompanyCode ) = aspect pfcg_auth( F_VBRK_BUK, BUKRS, ACTVT = '03' );
}

⑧ 서비스 정의 — 화면이 부르는 계약

화면은 이름 붙인 집합과 펑션만 압니다. 뷰 이름이 바뀌어도 서비스 정의에서 노출 이름을 유지하면 화면은 바뀌지 않습니다. 게시는 서비스 바인딩이나 게이트웨이 서비스 활성화로 하고, 화면의 서비스 주소만 교체합니다.

// ─────────────────────────────────────────────────────────────
// 서비스 정의와 바인딩 : 화면이 부르는 OData V2 서비스
// 하는 일 : 쿼리와 계획 큐브를 노출하고 OData V2 로 게시한다.
// 이렇게 나눈 이유 : 화면은 서비스 계약(엔티티셋·펑션)만 알고, 뷰 이름은 모른다.
// 확인 필요 : 게시는 Service Binding(OData V2 - UI) 또는 /IWFND/MAINT_SERVICE 활성화
// ─────────────────────────────────────────────────────────────
@EndUserText.label: '수출 제품 믹스 서비스'
define service ZUI_ExpMixSrv {
  expose ZC_ExpMixQuery as CubeSet;
  expose ZI_ExpMixPlan  as PlanSet;
  expose ZI_ExpMixDim   as ItemSet;
}

⑨ 요인분해 뷰 — 같은 키로 만나는 칸

실적과 계획이 같은 키로 만나는 칸에서 8요인을 계산하는 자리입니다. 전체 수량비를 쓰는 믹스 요인은 상위 집계가 필요해 단계를 나누어 구현하며, 구현 방식(CDS 함수·RAP 함수·ABAP 클래스)은 확인 필요입니다.

// ─────────────────────────────────────────────────────────────
// 요인분해 계산 (사용자 정의 CDS 함수 또는 RAP 함수 — 구현 방식은 확인 필요)
// 하는 일 : 실적·계획이 같은 키로 만나는 칸마다 8요인을 계산해 합산한다.
// 이렇게 나눈 이유 : 화면·AI 해설·보고서가 같은 분해 결과를 쓰도록 계산을 서비스 한 곳에 둔다.
// ─────────────────────────────────────────────────────────────
define view entity ZI_ExpMixVariance
  as select from ZI_ExpMixCube  as a
    inner join   ZI_ExpMixPlan  as p
      on  p.CompanyCode = a.CompanyCode and p.Period = a.Period
      and p.Customer = a.Customer and p.Product = a.Product and p.Incoterms = a.Incoterms
{
  key a.CompanyCode, key a.Period, key a.Customer, key a.Product, key a.Incoterms,
      // 물량 요인 = (실적 수량 합 ÷ 계획 수량 합 − 1) × 계획 공헌이익  (전체 합 기준 계산은 상위 뷰)
      a.Qty                                          as ActualQty,
      p.Qty                                          as PlanQty,
      ( a.Sales - a.VarCost )                        as ActualContribution,
      ( p.Sales - p.VarCost )                        as PlanContribution
}

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다. 아래를 정하지 않고 뷰부터 만들면 첫 대사 회의에서 막힙니다.

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

사례에서 본 숫자(계획 3,159 → 실적 3,288, 총차이 +128)는 아래 대사식 전수 검사를 통과한 값입니다.

검사 68건 모두 차이 0건(요인 합계는 원 단위 반올림 0.01원). 계획 없는 실적 조합 22건과 실적 없는 계획 조합 17건은 미계획·믹스 요인 점검용으로 일부러 둔 예외입니다. 화면 쪽은 실제 브라우저에서 기능 15개 점검을 따로 돌려 모두 통과했습니다.

운영 데이터로 갈 때

수출 청구가 연 수십만 줄, 문서 흐름까지 수천만 건이 되면 지금의 "큐브 전체를 읽어 브라우저에서 묶는" 방식은 막힙니다. 먼저 집계 위치를 DB(큐브 뷰)로 내리고, 기간과 회사코드를 필수 파라미터로 둬 전 기간 조회를 막습니다. 드릴스루는 칸의 차원 값과 기간을 모두 조건으로 걸어 문서 라인을 쪽 단위로 읽고(기본 500행), 청구일과 고객 기준 인덱스 또는 사전 집계 테이블을 둡니다. 응답 시간 기준(예: 조회 몇 초 이내)은 도입 전에 정하고, 화면의 행 500개·열 36개 상한은 운영에서도 그대로 둡니다.

자주 묻는 질문

도입 상담과 데모에서 나올 만한 질문을 네 묶음으로 나눠 적었습니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영