SAP 수출 FTA 원산지 활용 다차원 분석 — 협정별 관세 절감을 계획 대비 여덟 요인으로 나눠 보는 한 화면

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

수출 담당과 무역팀이 월 마감 때 받는 질문은 비슷합니다. 협정을 제대로 활용했는가, 계획한 절감액 대비 얼마나 차이가 났는가, 어디서 놓쳤고 누가 무엇을 해야 하는가. 지금은 이 답이 청구 조회 화면, 관세사 회신 자료, 엑셀 취합으로 흩어져 있어 숫자를 맞추는 데 시간이 더 듭니다.

이 앱은 청구 라인을 원산지 상태(적용 · 미발급 · 기준 미충족)로 나누어 하나의 큐브로 만들고, 그 위에서 축 바꾸기 · 원천 라인 내려가기 · 계획 대비 요인 분해 · 사유 기록을 한 화면에서 합니다. 표준 실행과 신고는 SAP 표준 T-code 가 담당하고, 이 화면은 조회·점검 관점을 더해 확장합니다. 관련 기준은 협정별 원산지 결정기준이며 세율과 판정은 협정 원문과 관세사 확인이 필요합니다.

핵심 포인트 일곱 가지

사례로 보는 효과 — 계획보다 많이 벌고도 활용률에서 놓친 해

검증용 샘플 데이터에서 9개월(2026-01 ~ 09) 순 절감액은 108.5억 원으로 계획 105.6억 원보다 2.9억 원 많았습니다. 표준 리포트라면 여기서 “계획 달성”으로 끝납니다. 여덟 요인으로 가르면 다른 이야기가 보입니다.

물량이 +891을 벌어 준 덕에 총차이가 플러스로 보일 뿐, 활용률에서 1,010백만원을 놓친 해입니다. 이 가운데 증명서가 아직 없는 미발급 청구액이 만든 놓친 절감액은 3,572백만원입니다. 협정별로 보면 한-EU FTA는 +369, 한-인도 CEPA는 −186, RCEP은 −197입니다. 한-인도 CEPA는 물량이 +93 늘고도 활용률 −274 때문에 계획 아래로 내려앉았습니다. 이 숫자는 모두 검증용 샘플의 가정값이며 운영 데이터의 효과가 아닙니다.

분해에는 조건을 걸었습니다. 여덟 요인의 합이 총차이와 어긋나면 안 됩니다. 검증용 샘플에서 전체 범위와 협정 6곳, 모두 일곱 범위를 돌렸고 차이는 모두 0이었습니다.

도입하면 달라지는 것

• 월 마감 보고 준비 — 협정별 활용 표 · 요인 분해 · 사유 · 보고서가 한 화면에서 나와 엑셀 취합과 캡처 작업이 줄어듭니다.
• 회의의 주제 — “어느 자료가 맞나”보다 “어느 고객의 증명서를 먼저 받을까”를 이야기합니다.
• 다음 달로 이어지는 기록 — 사유와 배치가 남아 같은 설명을 처음부터 다시 하지 않습니다.
• 놓치는 날이 없는 점검 — 아무도 화면을 열지 않은 날에도 규칙에 걸린 항목이 받을 역할에게 올라갑니다.

이런 회사에 맞습니다

여러 FTA 협정을 함께 쓰는 수출 제조·유통 회사, 협정별·고객별 활용 현황을 엑셀과 관세사 자료로 맞추는 무역팀, 외화 매출이 여러 통화에 걸쳐 있어 환율 영향과 활용률 영향을 나눠 보고 싶은 관리 조직에 맞습니다. 협정 수가 많거나 증명서를 발급 기관과 자율 발급으로 나눠 운영할수록 효과가 큽니다.

실행 화면

사용 방법

1. 회사코드와 시작·종료 선적월을 넣습니다. 적용 협정·제품 그룹·고객 같은 차원 필터는 선택입니다. 값 목록에서 여러 개를 고를 수 있습니다.
2. 조회 단추를 누르거나 입력 칸에서 Enter 를 누릅니다.
3. 위쪽 요약 탭(CEO · CFO · 영업 책임자 · 무역 책임자)으로 보는 눈을 바꾸며 요약을 확인합니다.
4. 차원 칩을 눌러 행·열·사용 안 함으로 옮기거나 끌어다 놓습니다. 옮겨도 서비스를 다시 부르지 않습니다.
5. 표의 칸을 누르면 원천 청구 라인이 열리고, 행 이름을 누르면 오른쪽 차트가 요인 분해 폭포로 바뀝니다.
6. 기준 대비를 켜 차이를 보고 사유를 적습니다. AI 분석 창에서 PowerPoint 보고서를, 위쪽 단추로 CSV 를 내려받습니다.

무엇으로 만들었나

처음 열었을 때

처음 열면 조회 조건과 행·열 배치 보드가 먼저 보입니다. 조회를 누르면 요약, 표, 차트가 한 화면에 모입니다.

왼쪽 위 칸이 아직 행·열에 올리지 않은 차원이고, 가운데가 행, 오른쪽이 열입니다. 기본값은 행에 적용 협정과 제품 그룹이 올라 있고 열은 비어 있습니다. 조회 조건의 기간 기본값은 2026-01부터 2026-09까지이며, 비교 기준은 연초 확정 계획으로 고정돼 있습니다.

조회를 누르면 요약 카드, 표, 차트가 한꺼번에 채워집니다. 아래쪽에 "집계 947건 · 원천 5,333줄"처럼 이 화면이 읽은 큐브 행 수와 원천 줄 수가 보입니다. 표의 첫 줄은 전체 합계이고 협정은 한 단계 펼친 상태입니다.

왼쪽 위 화살표를 눌러 조회 조건을 접으면 표와 차트가 화면 대부분을 씁니다. 접힌 줄에는 회사·기간·행·열·항목·필터 수가 한 줄로 남아 지금 어떤 조건인지 잊지 않습니다. 다시 누르면 펼쳐집니다.

역할별 요약 — 같은 큐브를 네 가지 눈으로

위쪽 요약은 보는 사람(CEO · CFO · 영업 책임자 · 무역 책임자)에 따라 행 차원과 항목이 바뀝니다. 같은 큐브를 네 가지 눈으로 읽는 셈입니다.

재무 책임자 탭은 행이 선택월로 바뀌고 순 절감액, 발급·관리 비용, 비용률이 항목으로 올라옵니다. 비용률이 계획보다 높은 달을 먼저 찾을 수 있습니다. 탭을 바꿔도 조회를 다시 하지 않습니다.

영업 책임자 탭은 행이 수출 국가 › 고객이고 FTA 활용률 요인이 함께 나옵니다. 어느 국가·고객에서 활용률 손실이 났는지 한 표에서 봅니다. 금액 단위는 백만원입니다.

무역 책임자 탭은 고객 › 적용 근거 기준으로 놓친 절감액과 미발급 청구액, 발급률을 보입니다. 증명서를 아직 받지 못한 청구가 몰린 곳이 막대로 드러납니다. 놓친 절감액은 미발급 청구액에 세율차를 곱한 값입니다.

축 전환과 범위

차원은 끌어다 놓거나 칩 메뉴로 행·열·사용 안 함 사이를 옮깁니다. 값 선택으로 범위를 좁히고, 표와 차트가 같은 범위를 씁니다.

차원 이름 옆 깔때기 단추를 누르면 그 차원의 값 목록이 열립니다. 값 아래 작은 글씨는 그 값에 걸린 원천 줄 수입니다. 검색 칸으로 값을 좁힐 수 있습니다.

값을 여러 개 눌러 체크한 뒤 적용을 누릅니다. 선택 해제로 모두 비울 수 있고 취소하면 바뀌지 않습니다. 필터 단추는 고른 값이 있으면 파란색으로 바뀝니다.

중국과 독일만 남긴 결과입니다. 요약 카드와 합계가 같은 범위로 다시 계산되어 한-중 FTA 1,856, 한-EU FTA 2,381로 나뉩니다. 필터 수는 접힌 조건 줄 오른쪽에 표시됩니다.

제품 그룹 칩을 눌러 "열로 이동"을 고르면 제품 그룹이 열 방향으로 펼쳐집니다. 열에 차원이 올라가면 첫 항목만 열로 펼쳐 보인다는 안내가 뜹니다. 이 조작은 서비스 요청이 0건입니다.

고객 칩을 "행으로 이동"하면 적용 협정 아래에 고객이 한 단계 더 생깁니다. 행에는 최대 세 차원까지 올릴 수 있습니다. 각 행 앞 화살표로 한 단계씩 펼칩니다.

보기 방식을 단계 보기로 바꾸면 항목이 행으로 놓이고 행 차원은 위에서부터 한 단계씩 펼쳐집니다. 청구액에서 순 절감액까지 내려가는 흐름을 읽을 때 쓰는 보기입니다. 차원 보기로 되돌리면 이전 배치가 그대로입니다.

열에도 차원을 두 개까지 올릴 수 있어 고객과 수출 국가를 겹쳐 펼친 모습입니다. 열 조합이 상한을 넘으면 표를 그리지 않고 안내 문구를 보입니다. 열 폭은 헤더 경계로 조절합니다.

칸에서 청구 라인까지

숫자를 의심할 때 표를 닫지 않고 칸을 눌러 원천 라인으로 내려갑니다. 칸 값과 원천 합계가 같은지 화면이 직접 알려 줍니다.

표의 칸을 누르면 칸을 만든 원천 청구 라인이 열립니다. 맨 위 초록 줄이 "셀 값 3,913 = 원천 합계 3,913 (원천 1,714줄) 일치"를 알려 줍니다. 아래 줄은 청구 문서·발급 상태·증명 유형·증명서 번호 순이며 더 보기로 이어서 읽습니다.

기간별 요약은 선적월마다 라인 수, 청구액, 적용 금액, 절감액, 비용, 순 절감액, 계획과 차이, 활용률을 나란히 보입니다. 계획 활용률과 비교하면 어느 달에 벌어졌는지 보입니다. 합계 줄은 큐브 합계와 같은 값입니다.

계산항목

활용률이나 발급률처럼 합계에서 다시 계산해야 하는 값은 서비스가 정의한 식으로 계산항목이 됩니다.

분석 항목 목록에 측정값과 계산항목이 함께 있습니다. "(계산)"이 붙은 항목은 서비스가 정의한 식(활용률 = 적용 ÷ 청구 등)으로 합계 단계에서 다시 계산합니다. 항목을 체크하면 표와 차트가 바로 바뀝니다.

계획 대비 차이 — 같은 표가 마감 자료가 된다

비교 기준을 켜면 같은 표가 계획 대비 차이 리포트가 됩니다. 차이의 이유는 요인 분해와 사유 기록 두 가지로 남깁니다.

기준 대비를 켜면 각 칸 아래에 "기준 값 · 차이 · 증감률"이 붙습니다. 금액과 비율을 둘 다 넘는 차이만 초록(유리)·빨강(불리)으로 칠합니다. 계획 행이 없는 칸은 계획 미이행이 아닌 미계획 거래로 읽습니다.

사유 단추를 누르면 사유 구분(물량·단가·환율 등)과 내용을 적는 창이 열립니다. 저장하면 조회 범위와 행 경로를 키로 서비스에 기록됩니다. 새로 고침 뒤에도 같은 행에 사유 표시가 남습니다.

행을 선택하고 차이 분해 탭을 누르면 계획에서 실적까지의 폭포가 그려집니다. 아래 초록 줄은 "요인 합계 369 / 총차이 369 (오차 0.00)" 검산입니다. 막대 위 숫자는 요인별 백만원 기여입니다.

AI 분석과 보고서

AI 분석은 숫자를 만들지 않고 읽기만 합니다. 읽은 근거는 표로 펼쳐지고, 같은 내용이 PowerPoint 보고서가 됩니다.

AI 분석은 현재 범위의 숫자를 규칙으로 읽어 요약과 주요 발견을 씁니다. 발견은 차이가 큰 순서이며 이미 사유가 적힌 행은 건너뜁니다. 모델 연결은 꺼진 상태가 기본이고 "분석 방식: 규칙 기반"으로 표시됩니다.

창 아래 "근거 수치"를 펼치면 해설이 읽은 숫자가 표로 나옵니다. 해설의 금액은 모두 이 표의 값입니다. AI가 만든 숫자는 없습니다.

AI 에이전트

감시 규칙에 걸린 항목은 받을 역할의 대기함에 올라갑니다. 하루 한 번 제한과 실행 기록은 서비스가 맡습니다.

규칙 다섯 개가 지표·기준값·점검 주기·받을 역할과 함께 나열됩니다. 예를 들어 놓친 절감액 4억 원 초과는 무역 책임자에게 갑니다. 사용 여부는 규칙마다 켜고 끕니다.

지금 실행을 누르면 규칙을 점검해 보고가 대기함에 쌓입니다. 역할 선택으로 받을 사람별 보고만 모아 볼 수 있습니다. 보고에는 대상, 금액, 실행 번호가 붙습니다.

실행 기록에는 번호·시각·실행 주체(사용자·타이머·배치)·결과·발견 건수가 남습니다. 같은 날 두 번째 실행은 "하루 1회 제한으로 건너뜀"으로 기록됩니다. 걸린 항목이 없어도 기록은 남습니다.

레이아웃 저장과 복원

자주 쓰는 배치는 이름을 붙여 저장하고, 기본 지정과 자동 조회로 열 때 바로 복원합니다.

현재 행·열·항목·필터를 이름을 붙여 저장합니다. 기본 레이아웃으로 지정하면 열 때 이 배치로 시작하고, 열 때 자동 조회를 함께 켤 수 있습니다. 창 아래에 무엇이 저장되는지 요약이 보입니다.

저장한 배치를 목록에서 적용하고 이름을 바꾸거나 지웁니다. 기본과 자동 조회 표시가 한눈에 보입니다. 삭제는 확인을 한 번 더 묻습니다.

기본과 자동 조회로 저장한 배치는 새로 고침 뒤에 조회된 채로 열립니다. 비교 모드와 사유 표시도 함께 돌아옵니다. 서비스에 기록된 값이라 다른 브라우저에서도 같습니다.

좁은 화면과 한계

휴대폰 폭에서도 같은 기능을 씁니다. 차트는 표 아래로 내려갑니다.

휴대폰 폭에서는 조회 조건 칸이 위아래로 쌓이고 위쪽 단추는 아이콘만 남습니다. 조회 단추는 조건 바로 아래에 있습니다. 가로 스크롤이 생기지 않게 맞췄습니다.

요약 카드가 두 줄로 접히고 표는 가로로 밀어 볼 수 있습니다. 행 이름 칸은 고정되어 숫자를 읽는 동안 따라옵니다. 칸을 누르는 드릴스루는 그대로 됩니다.

차트는 표 아래로 내려와 같은 폭을 씁니다. 표와 차트 사이 너비 손잡이는 좁은 화면에서는 쓰지 않습니다. 선택한 행의 폭포도 같은 자리에 나옵니다.

화면 뒤에서 일어나는 일

조회를 누르면 화면은 서비스에 큐브 행(선적월 × 협정 × 제품 × 고객 × 국가 …)과 계획 행을 요청합니다. 이후 축 이동 · 접기 · 펼치기는 이미 받은 행 위에서 다시 접어 그리므로 서비스를 다시 부르지 않습니다. 필터를 바꾸면 그 범위로만 다시 부릅니다.

산출 순서는 다섯 단계입니다. ① 수출 오더·납품·청구 라인이 원천이 되고 ② 라인마다 협정과 결정기준이 붙으며 ③ 증명서의 발급 유형과 발급일이 붙고 ④ 적용 금액에 세율차를 곱해 절감액을 구한 뒤 발급·관리 비용을 빼 순 절감액이 되며 ⑤ 계획과 견주어 차이를 여덟 요인으로 나눕니다.

원산지 상태 판정과 사용자 조치

조회조건

결과 컬럼

좁은 화면에서 달라지는 것

390px 폭에서는 조회 조건이 위아래로 쌓이고 위쪽 단추는 아이콘만 남습니다. 요약 카드는 두 줄로 접히고 표는 가로로 밀어 보며, 차트는 표 아래로 내려옵니다. 표와 차트 사이 너비 손잡이는 쓰지 않습니다. 가로 스크롤은 표 안에서만 생기고 칸 클릭 · 사유 · AI 분석은 그대로 씁니다.

파일 구성

index.html · Component.js · manifest.json
controller/   화면 제어
view/         메인 화면 + 대화 상자(원천 라인 · 기간별 요약 · 사유 · 레이아웃 · AI 분석 · 에이전트)
model/        큐브 모델(축 · 항목 · 계산식) · 차트 · PowerPoint 생성
odata/        서비스 정의와 집계 로직, 데이터
media/        소개 영상
readme.html   설명서

SAP 표준 기능 확장 포인트

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

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

T-code 별 연계 지점

운영 전환 때 기존 리포트를 없앨 필요는 없습니다. 법정 신고, 감사·세관 대응, 관세사 제출 서류는 표준과 관세사 절차에 그대로 두고, 이 앱은 월 마감과 점검 회의의 분석 화면으로 병행합니다. 두 화면 숫자는 위 표의 대사 지점에서 맞춰 보며, 협정 세율과 판정은 회사와 관세사가 확인합니다.

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

S/4HANA 의 CDS 큐브 · 분석 쿼리 구조(#sec-cds 참고)를 그대로 쓰는 화면입니다. 표준 분석 앱이나 Analysis for Office 로도 같은 쿼리를 읽을 수 있고, 이 앱은 그 위에 요인 분해 · 사유 기록 · 역할별 감시 · 보고서를 얹은 형태입니다. 관세 절감을 직접 다루는 표준 Fiori 앱은 확인하지 못해 이름을 적지 않았습니다(확인 필요).

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

분석 지표 정의

CDS 구성

표준 원천(I_BillingDocumentItem · I_BillingDocument)을 읽고, 매핑 · 차원 · 큐브 · 쿼리 · 접근 제어 · 서비스로 나눕니다. 원산지 판정과 증명서 이력은 환경에 따라 원천이 달라 해당 association 은 확인 필요 자리로 표시했습니다. 아래 코드는 구성을 보이기 위한 스케치이며 필드 이름과 어노테이션은 릴리스에 맞춰 확인해야 합니다.

뷰 레이어 구성

① 협정 매핑 테이블 — 협정·결정기준을 한 곳에서 정한다

원산지 판정과 증명서 발급 이력은 고객사마다 원천이 다릅니다. 그래서 라인에 붙는 협정 코드와 협정 이름, 세율차 기준을 한 테이블에 모았습니다. 협정이 늘거나 이름이 바뀌어도 이 테이블 한 곳만 고치면 차원과 큐브가 따라옵니다. 세율은 협정 원문과 관세사 확인이 필요한 값이라 코드에 박지 않고 유효기간과 함께 이 테이블이 가집니다.

" ─────────────────────────────────────────────────────────────
" ZFTA_AGRMAP — 협정 매핑 (고객사 현업이 유지)
" 역할 : 청구 라인의 협정 코드 → 협정 이름·기본 세율차·유효기간
" 나눈 이유 : 세율은 협정·품목별로 바뀐다. 코드에 두면 이송이 필요하고,
"             테이블에 두면 현업이 유효기간만 바꿔 적는다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : 'FTA 협정 매핑'
@AbapCatalog.enhancement.category : #NOT_EXTENSIBLE
@AbapCatalog.tableCategory : #TRANSPARENT
@AbapCatalog.deliveryClass : #C
@AbapCatalog.dataMaintenance : #ALLOWED
define table zfta_agrmap {
  key client     : abap.clnt not null;
  key agreement  : abap.char(8) not null;       " KORUS · KREU · RCEP ...
  key valid_to   : abap.dats not null;
  valid_from     : abap.dats;
  agreement_name : abap.char(40);
  duty_gap       : abap.dec(7,4);               " 일반 세율 − 협정 세율 (샘플은 가정값)
  evidence_type  : abap.char(1);                " I 기관 발급 · S 자율 발급
}

② 차원 뷰 — 이름과 값을 큐브에서 떼어 둔다

차원 뷰는 코드와 이름만 가집니다. 큐브에 이름을 직접 붙이지 않고 association 으로 두기 때문에 화면의 필터 목록(값 선택 창)과 큐브가 같은 정의를 봅니다. 언어별 이름은 텍스트 뷰로 분리해 두었습니다.

" ─────────────────────────────────────────────────────────────
" ZI_FtaAgreement — 협정 차원
" 이렇게 나눈 이유 : 큐브는 코드만 들고 이름은 association 으로 읽는다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #NOT_REQUIRED
@EndUserText.label : 'FTA 협정'
@ObjectModel.resultSet.sizeCategory : #XS
@Analytics.dataCategory : #DIMENSION
@ObjectModel.representativeKey : 'Agreement'
define view entity ZI_FtaAgreement
  as select from zfta_agrmap
{
  @ObjectModel.text.element : ['AgreementName']
  key agreement      as Agreement,
  key valid_to       as ValidTo,
      valid_from     as ValidFrom,
      @Semantics.text : true
      agreement_name as AgreementName,
      duty_gap       as DutyGap,
      evidence_type  as EvidenceType
}

③ 청구 라인 뷰 — 상태를 세 칸으로 나눈다

청구 문서 품목에 협정 코드와 증명서 상태를 붙여 적용 · 미발급 · 비대상 세 칸으로 나눕니다. 세 칸의 합이 청구액이 되도록 case 로 한 번만 나누고, 이후 뷰는 이 결과만 읽습니다. 표준 청구 뷰의 필드 이름은 릴리스마다 확인이 필요하고, 원산지 결정·증명서 이력 원천은 환경에 따라 달라 아래 association 은 확인 필요 자리입니다.

" ─────────────────────────────────────────────────────────────
" ZI_FtaBillingItem — 청구 라인 + 원산지 상태
" 역할 : 청구액을 적용 / 미발급 / 비대상으로 한 번만 나눈다.
" 나눈 이유 : 큐브·계획·쿼리가 같은 분류를 쓰게 하려고.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@EndUserText.label : '수출 청구 라인 + 원산지 상태'
define view entity ZI_FtaBillingItem
  as select from I_BillingDocumentItem as Item
    inner join   I_BillingDocument     as Head
      on Head.BillingDocument = Item.BillingDocument
  association [0..1] to ZFTA_I_ORIGIN_STATUS as _Origin    " 확인 필요: 원산지 판정·증명서 이력 원천
    on  _Origin.BillingDocument     = Item.BillingDocument
    and _Origin.BillingDocumentItem = Item.BillingDocumentItem
{
  key Item.BillingDocument,
  key Item.BillingDocumentItem,
      Head.BillingDocumentDate,
      Head.SoldToParty,
      Item.TransactionCurrency,
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      Item.NetAmount                                        as Gross,
      _Origin.Agreement,
      case when _Origin.CertStatus = 'ISSUED'  then Item.NetAmount else 0 end as Applied,
      case when _Origin.CertStatus = 'PENDING' then Item.NetAmount else 0 end as Pending,
      case when _Origin.CertStatus is null
             or _Origin.CertStatus = 'INELIG'  then Item.NetAmount else 0 end as Ineligible
}

④ 실적 큐브 — 합계는 여기서만 만든다

큐브는 차원 키로 묶어 금액을 합칩니다. 수량과 금액 필드에는 통화·단위 의미를 붙이고, 활용률처럼 합계에서 다시 계산해야 하는 값은 큐브에 넣지 않고 쿼리의 계산 항목으로 둡니다. 합계가 어느 단계에서도 같게 보이는 이유가 이 구조입니다.

" ─────────────────────────────────────────────────────────────
" ZI_FtaUtilCube — 실적 큐브 (선적월 · 협정 · 제품 · 고객 · 국가)
" 역할 : 청구 라인을 차원 키로 묶어 청구액·적용·미발급·절감액·비용을 합산
" 나눈 이유 : 비율은 합계에서 다시 계산하므로 큐브에는 합산 가능한 값만 둔다.
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : 'FTA 활용 실적 큐브'
define view entity ZI_FtaUtilCube
  as select from ZI_FtaBillingItem as L
  association [0..1] to ZI_FtaAgreement as _Agreement
    on _Agreement.Agreement = L.Agreement
{
  @ObjectModel.foreignKey.association : '_Agreement'
  L.Agreement,
  L.SoldToParty,
  cast( substring( cast( L.BillingDocumentDate as abap.char(8) ), 1, 6 ) as abap.char(6) ) as ShipMonth,
  L.TransactionCurrency,
  @DefaultAggregation : #SUM
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  sum( L.Gross )      as Gross,
  @DefaultAggregation : #SUM
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  sum( L.Applied )    as Applied,
  @DefaultAggregation : #SUM
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  sum( L.Pending )    as Pending,
  @DefaultAggregation : #SUM
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  sum( L.Ineligible ) as Ineligible,
  _Agreement
}
group by L.Agreement, L.SoldToParty, L.BillingDocumentDate, L.TransactionCurrency

⑤ 계획 큐브 — 같은 차원 키, 다른 원천

계획은 청구 문서에서 나오지 않습니다. 계획 테이블을 실적과 같은 차원 키로 맞춰 두어야 계획 대비 차이와 요인 분해가 칸 단위로 맞물립니다. 샘플은 연초 확정 버전 한 벌이며, 운영에서는 계획 원천과 버전을 먼저 합의해야 합니다.

" ─────────────────────────────────────────────────────────────
" ZI_FtaUtilPlan — 계획 큐브
" 역할 : 연초 확정 계획(버전 FTA26)을 실적 큐브와 같은 키로 제공
" ─────────────────────────────────────────────────────────────
@AbapCatalog.viewEnhancementCategory : [#NONE]
@AccessControl.authorizationCheck : #CHECK
@Analytics.dataCategory : #CUBE
@EndUserText.label : 'FTA 활용 계획 큐브'
define view entity ZI_FtaUtilPlan
  as select from zfta_plan
{
  key plan_version                                   as PlanVersion,
  key agreement                                      as Agreement,
  key sold_to                                        as SoldToParty,
  key ship_month                                     as ShipMonth,
      currency                                       as TransactionCurrency,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      gross_amt                                      as Gross,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      applied_amt                                    as Applied,
      @DefaultAggregation : #SUM
      @Semantics.amount.currencyCode : 'TransactionCurrency'
      cost_amt                                       as IssueCost
}

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

화면은 이 쿼리(서비스)만 읽습니다. 필수 필터(회사·기간)와 계산 항목(활용률 · 발급률 · 순 절감액)을 여기서 정의합니다. 파라미터를 필수로 두면 수천만 건에서도 조건 없이 전체를 읽는 호출을 막을 수 있습니다.

" ─────────────────────────────────────────────────────────────
" ZC_FtaUtilQuery — 분석 쿼리
" 역할 : 필수 필터 + 계산 항목 정의. 화면(OData)은 이 쿼리만 부른다.
" ─────────────────────────────────────────────────────────────
@AccessControl.authorizationCheck : #CHECK
@Analytics.query : true
@EndUserText.label : 'FTA 활용 분석'
@UI.headerInfo : { typeName : '협정', typeNamePlural : '협정' }
define view entity ZC_FtaUtilQuery
  as select from ZI_FtaUtilCube
{
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter : { selectionType : #RANGE, mandatory : true }
  ShipMonth,
  @AnalyticsDetails.query.axis : #ROWS
  @Consumption.filter.selectionType : #SINGLE
  Agreement,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  Gross,
  @AnalyticsDetails.query.axis : #COLUMNS
  @Semantics.amount.currencyCode : 'TransactionCurrency'
  Applied,
  @AnalyticsDetails.query.axis : #COLUMNS
  @AnalyticsDetails.query.formula : 'Applied / Gross * 100'
  @EndUserText.label : 'FTA 활용률(%)'
  cast( 0 as abap.dec(7,2) ) as UtilRate,
  TransactionCurrency
}

⑦ 접근 제어 — 집계 단계에서 건다

권한을 드릴스루에만 걸면 합계에서 자기 몫을 빼서 남의 숫자를 알아낼 수 있습니다. 그래서 큐브 단계의 접근 제어로 회사·판매 조직을 걸고, 쿼리는 그 결과만 읽습니다. 권한 객체 이름과 필드는 고객사 권한 설계에 맞춰 확인이 필요합니다.

" ─────────────────────────────────────────────────────────────
" ZC_FtaUtilQuery — DCL
" 나눈 이유 : 집계 단계에서 걸어야 합계로 남의 숫자가 새지 않는다.
" ─────────────────────────────────────────────────────────────
@EndUserText.label : 'FTA 활용 분석 접근 제어'
@MappingRole : true
define role ZC_FtaUtilQuery {
  grant select on ZI_FtaUtilCube
    where ( SalesOrganization ) = aspect pfcg_auth( V_VBRK_VKO, VKORG, ACTVT = '03' );
}

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

쿼리를 OData V2 서비스로 내놓습니다. 화면은 manifest 에 적힌 서비스 주소만 알면 되므로, 운영 연결 때는 서비스 주소만 교체합니다. 게시는 게이트웨이 서비스 활성화 화면(/IWFND/MAINT_SERVICE) 또는 서비스 바인딩 게시로 합니다.

" ─────────────────────────────────────────────────────────────
" ZSD_FtaUtil — 서비스 정의
" ─────────────────────────────────────────────────────────────
@EndUserText.label : 'FTA 활용 분석 서비스'
define service ZSD_FtaUtil {
  expose ZC_FtaUtilQuery as UtilQuery;
  expose ZI_FtaAgreement as Agreement;
}

" 서비스 바인딩 : ZSB_FtaUtil_V2  (바인딩 유형 OData V2 – UI) → 게시 후 서비스 주소를 화면 manifest 에 반영

운영 시점에 해야 할 일

개발보다 정하는 일이 많습니다.

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

리포트에서 가장 비싼 질문은 “이 숫자 맞아?”입니다. 그래서 만드는 쪽에서 먼저 대사식을 세우고 전수로 돌렸습니다. 아래는 이 사례 데이터의 결과이며 위 “사례로 보는 효과”와 같은 숫자입니다.

화면 쪽은 이와 별도로 브라우저 자동화로 확인했습니다 — 축을 바꿔도 요청이 0건이고 합계가 변하지 않는지, 칸 금액과 드릴스루 합계가 같은지, 요인 합계가 총차이와 같은지입니다. 의도적 예외는 없습니다. 세율 · 환율 · 고객 · 증명서 번호는 모두 가정값이어서 실제 협정 세율과의 대조는 운영 데이터에서 따로 해야 합니다.

운영 데이터로 갈 때

청구 라인이 수천만 건이면 라인을 화면이 직접 읽을 수 없습니다. 큐브 뷰에서 선적월 · 협정 · 제품 · 고객 단위로 집계한 행만 서비스가 내보내고, 드릴스루는 칸 조건과 날짜 범위를 필수로 걸어 페이지 단위로 읽습니다. 조회 조건(회사 · 기간)을 필수 파라미터로 두어 조건 없는 전체 조회를 막고, 집계 키(선적월 · 협정 · 고객)에 맞춘 인덱스 또는 HANA 쪽 집계를 쓰며, 응답 시간 목표는 도입 때 정합니다(확인 필요). 샘플의 5,333줄 → 947행 같은 압축률은 운영에서 다르게 나옵니다.

자주 묻는 질문

도입을 검토하는 분들이 자주 묻는 질문입니다. 숫자는 모두 검증용 샘플 기준입니다.

숫자와 산식

화면과 조작

분석 기능

도입과 운영